Method, system and apparatus for participating in group communication services in an existing communication system

ES 2 343 563 T3

DESCRIPTION

Procedure and apparatus for participating in group communication services in an existing communication system.

Background of the invention

I. Field of the invention

The present invention relates to point-to-multipoint communication systems. More specifically, the present invention relates to an apparatus and method for enabling group communication services using the standard Internet Protocol in an existing communication system.

II. Description of related technology

Point-to-multipoint communication systems have been used to provide communications, generally, between a central location and multiple users of the system. For example, dispatch systems, using Land Mobile Radios (LMR), have been used in trucks, taxis, buses and other vehicles, in order to communicate scheduling information between a central dispatch center and one or more corresponding vehicles in the fleet. . Communications can be directed to a specific vehicle in the fleet or to all vehicles simultaneously.

Another example of a point-to-multipoint communication system is a push-to-talk type wireless system. Such a system allows a group of individuals, each with a wireless communication device, to communicate with other members of the group. Typically, a push-to-talk type system relies on a single frequency, or dedicated channel, over which communications are received by wireless communication devices. In most systems, only one member can transmit information to the other members at a time. However, all members can listen to the dedicated broadcast channel to receive communications from the individual member who is broadcasting. Members who wish to broadcast to other members of the system typically send an access request by pressing a push-to-talk button on their respective communication device, which allows the user only access to the dedicated channel.

Push-to-talk systems are commonly used in outdoor environments, where a group of people, or members, require “point-to-multipoint” communication with each other. Examples of uses for push-to-talk systems include workgroup communications, security communications, construction site communication, and localized military communications. The group of people who require communication with each other is commonly known as a "network" with each member of the network sometimes referred to as a "network member".

UK Patent Application Publication No. GB2 290 196 discloses a procedure and system for reducing access time in trunk radio systems.

In a typical push-to-talk type system, a dedicated channel, sometimes referred to as a broadcast channel, is used to transmit communications from one member to multiple other members of the network simultaneously. The dedicated channel may comprise a single channel or frequency, or a group of individual channels managed by a controller to mimic the individual channel. In any event, only one member may transmit voice and / or data communications to the other member users at any given time. If another member attempts to transmit on the broadcast channel while another member is transmitting, interference will occur between the two competing communications, resulting in unintelligible communications received by the other network members.

Summary of the invention

In order to implement a push-to-talk type communication system in a conventional wireless communication system, costly infrastructure modifications are generally necessary.

In addition to the high costs associated with current point-to-multipoint wireless communication systems, communications are generally limited to members operating at a relatively close distance from each other, using the same or similar technology. In other words, point-to-multipoint communications do not extend to other communication networks or technologies, such as the Public Switched Telephone Network (PSTN), to data networks, such as the Internet, or to satellite communication systems, such as the GlobalStar satellite communication system.

Thus, the present invention, as set forth in the appended claims, is a push-to-talk type communication device for participating in a group communication network. The group communication network comprises a controller for managing the group communication network and an interface with the push-to-talk type communication device. A processor converts information signals into packet data, suitable for transmission over a distributed network. The processor may also have identifying information, and update

ES 2 343 563 T3 your identifying information when your current identifying information has changed, or is about to change. The processor then transmits its new identification information to the controller. The push-to-talk type device also comprises a transmitter for transmitting packet data, through a first channel, to the controller. A receiver receives packet data, through a second channel, from the controller. The push-to-talk type device also comprises a user-activated mechanism to activate the transmitter when a user of the communication device wishes to transmit packet data to said controller.

In one embodiment, the communication device is a wireless communication device. The communication device may further comprise memory for storing data in packets, until the controller is ready to receive the data in packets. Memory is used to minimize the perceived latency of a user. The processor may further comprise a dynamically configurable priority level, wherein the priority level determines whether or not the communication device has the authority to obtain transmission privilege over another communication device, such that the communication device can interrupt. the transmission of a communication device with a lower priority level. In addition, the processor can receive information from the controller regarding the group communication network, such as who is participating in the network, how many are participating in the network, and where the users are physically.

The communication device can also operate in a secure mode. The processor may further comprise identifying information. The processor updates your identifying information when your current identifying information has changed or is about to change, and transmits your new identifying information to the controller.

The group communication network is also capable of being in a dormant mode. Activation of the user-activated mechanism prompts the controller to bring the communications network out of sleep mode.

The communication device communicates with the communication manager. The communications manager comprises a first node for establishing a first channel with a first communication device. At least one second node establishes at least one second channel with at least one second communication device. The channel connecting communication devices to the controller, or communication manager, comprises a signal initiation protocol (SIP) channel, a media signaling channel, and a media traffic channel. A controller, also called a communications manager, electrically connects the first node with at least one second node. The controller further comprises a database module. The database module includes identification information for each of the communication devices in the group. The controller is dynamically configurable, such that any individual communication device in the group is capable of sending packet data on its respective channel to the other communication devices in the group. In one embodiment, the packet data contains time-sensitive information. In another embodiment, at least one of the communication devices is a wireless communication device.

The controller further comprises a central module and a network, or MCU (media control unit) module. The central module and said network module are connected to the distributed network. The central module establishes the identification of each of the communication devices and redirects the information from the communication devices to the network module. The network module manipulates and manages information transmitted between the group of communication devices. In one embodiment, the database module is a part of the core module. The central module further comprises a billing registration module. The billing log module maintains a history of activity between communication devices.

The network module further comprises a local registration module. The local log module maintains a history of the activity between the communication devices, and transfers the compiled history to the billing log module. The controller further comprises a top-level server. The top-level server sends and receives packet data from the communication devices. Packet data comprises information such as communication device identification data, communication device location data, and control data for establishing, modifying, or terminating group communications.

The controller further comprises a first timer that measures a first elapsed time period. If any of the communication devices have not transmitted information to the controller before the time period expires, the controller sends a message to each of the communication devices to enter a sleep mode. The controller further comprises a second timer that measures a second elapsed time period. If any of the communication devices have not transmitted information to the controller within a predetermined period of time, the controller sends a message to each of the communication devices, in order to elicit a response from the communication devices, to determine if the communication device wishes to remain active.

The controller further comprises an arbitrator that assigns a priority level to each of the communication devices. The priority level determines a hierarchy of transmission privileges of communication devices, such that communication devices with a higher priority level can interrupt the transmission of communication devices with a lower priority level. The priority level assignment is dynamically configurable.

ES 2 343 563 T3

The controller further comprises a temporary storage memory that stores the data in packets until the communication device is ready to receive said data in packets. Buffer memory is used to minimize a user's perceived latency. Communication devices can operate on the same network, despite operating on different communication infrastructures, including, but not limited to, CDMA (Code Division Multiple Access), TDMA (Time Division Multiple Access) and GSM (Global System of Mobile Communications).

Accordingly, it is a feature and advantage of the invention to provide end-to-end voice communications using the Internet protocol.

It is another feature and advantage of the invention to provide end-to-end wireless voice communications using the Internet protocol.

It is another feature and advantage of the invention to provide push-to-talk type wireless communications to a group of participants, transmitting voice as packet data, using the Internet protocol.

It is another feature and advantage of the invention to provide a push-to-talk type system over an existing communications infrastructure, without having to modify the existing underlying communications infrastructure.

It is another feature and advantage of the invention to allow a group of wireline or wireless communication devices to transmit and receive voice data with each other using the Internet protocol.

It is another feature and advantage of the invention to provide a sleep mode for an idle push-to-talk type network.

It is another feature and advantage of the invention to provide a communications manager, to manage and control one or more push-to-talk networks.

It is another feature and advantage of the invention to provide a dedicated media control unit for a specific push-to-talk network.

It is another feature and advantage of the invention to provide full duplexing over packet data.

It is another feature and advantage of the invention to provide a signaling channel for setting up and maintaining a push-to-talk type network.

It is another feature and advantage of the invention to provide security for voice transmissions over the Internet protocol.

It is another feature and advantage of the invention to provide a detailed history of transactions in a push-to-talk type network.

It is another feature and advantage of the invention to provide arbitration to allow one or more users to prevail over the authority to transmit voice or data with an access priority over that of other users in a push-to-talk type network.

It is another feature and advantage of the invention to minimize perceived latency for a user of a push-to-talk type network.

It is another feature and advantage of the invention to allow the communications device to drop data frames to minimize latency.

It is another feature and advantage of the invention to allow the communication device to anticipate the granting of a request in order to minimize latency.

It is another feature and advantage of the invention to temporarily store each user's voice data until a given user is ready to receive the data.

It is another feature and advantage of the invention to allow a user to multicast on a single channel direct to multiple listeners.

It is another feature and advantage of the invention to allow a communications device to recognize and report that its identification address has changed or is about to change.

It is another feature and advantage of the invention to request a user to determine if the user is still an active part of a push-to-talk type network.

ES 2 343 563 T3

It is another feature and advantage of the invention to allow a user to switch between multiple push-to-talk networks.

It is another feature and advantage of the invention to allow a user to dynamically determine the members of a given push-to-talk network.

It is another feature and advantage of the invention to provide a user with a list of potential push-to-talk networks that the user can join.

It is another feature and advantage of the invention to provide a user with geographic information, and other user specific information, about other users on the push-to-talk network.

Thus, according to a first aspect of the present invention, there is provided a communication device of the push-to-talk type, as set forth in claim 1.

According to a second aspect, there is provided a method of participating using a push-to-talk type communication device in a group communication network, as set forth in claim 14.

According to a third aspect of the present invention, a computer storage medium is provided in a push-to-talk type communication device, as set forth in claim 22.

Brief description of the drawings

The characteristics and advantages of the present invention will become more apparent from the detailed description set forth below, when considered in conjunction with the drawings, in which identical reference characters identify correspondingly in their entirety, and in which :

Fig 1 illustrates a network broadcast system.

Fig. 2 illustrates an NBS (Network Broadcast Service) network and how communication devices interact with a communication manager (CM) 104.

Fig. 3 illustrates a functional block diagram of the CM.

Fig. 4 illustrates an example of an NBS SIP signaling protocol stack.

Fig. 5 illustrates an NBS media signaling protocol stack.

FIG. 6 illustrates a voice media protocol stack of real-time protocols.

Fig. 7 illustrates a UDP (User Datagram Protocol) voice media protocol stack.

Fig. 8 illustrates a media traffic protocol stack.

Fig. 9 illustrates a DNS (Domain Name Service) client protocol stack.

FIG. 10 illustrates the high-level functionality of the group services module 500 of the communication device.

FIG. 11 illustrates SIP call signaling 350.

Fig. 12 illustrates a sequence of media signaling messages.

Fig. 13 illustrates the sequence of media signaling messages regarding idle.

Fig. 14 illustrates a sequence of NBS media signaling messages.

Fig. 15 illustrates a state diagram of the CM 104.

FIG. 16 illustrates a state diagram of communication device 352.

Detailed description of the preferred embodiments

The Network Broadcast Service (NBS) system allows Internet Protocol (IP) communication devices to participate in a group voice and data conference. NBS is primarily a Voice over and IP (VoIP) application. Voice communication is transmitted from a speaker end communication device to one or more listeners, encapsulating voice frames in IP datagrams. Voice data can also be transmitted in this way. The NBS system is described in US Patent Application Serial No. 09 / 518,985, ti

ES 2 343 563 T3 titled “Method and Apparatus for Providing Group Communication Services in an Existing Communication System”, registered on March 3, 2000, File No. 000212, and in US Patent Application Serial No. 09 / 518,776, entitled "Method and Apparatus for Participating in Group Communication Services in an Existing Communications System", registered on March 3, 2000, File No. 000211 .

FIG. 1 illustrates a functional block diagram of a group communication system 10. The group communication system 10 is also known as a push-to-talk type system, a network, a broadcast service (NBS), a dispatch system, or a point-to-multipoint communication system. A defining feature of such an NBS system is that generally only one user can transmit information to other users at any given time. In the NBS 10, a group of communication device users, individually known as network members, communicate with each other using a communication device assigned to each network member.

The term "network" indicates a group of users of communication devices authorized to communicate with each other. In general, a central database contains information that identifies the members of each specific network. More than one network can operate on the same communication system. For example, a first network can be defined with ten members and a second network can be defined with twenty members. The ten members of the first network can communicate with each other, but generally not with members of the second network. In other situations, members of different networks can monitor communications between members of more than one network, but can only transmit information to members within their own network.

The network works on top of an existing communications system, without requiring significant changes to the existing infrastructure. Thus, a controller and users on a network can operate on any system capable of transmitting and receiving information in packets using the Internet Protocol (IP), such as a Code Division Multiple Access (CDMA) system, a system of Time Division Multiple Access (TDMA), a Global System for Mobile Communications (GSM), satellite communication systems such as Globalstar ™ or Iradium ™, or a wide variety of other systems.

Members of the network communicate with each other using an assigned communication device, shown as communication devices (CD) 12, 14, 16, and 17. The CDs 12, 14, 16 and 17 can be wired or wireless communication devices, such as landline cordless phones, push-to-talk capable wireline phones, satellite phones equipped with push-to-talk functionality. -Talking, wireless video cameras, fixed cameras, audio devices such as music recorders or players, laptops or desktops, paging devices or any combination thereof. For example, the CD 12 may comprise a cordless land telephone with a video camera and a viewer. Furthermore, each CD may be able to send and receive information either in a secure mode or in an insecure (open) mode. Throughout the following discussion, the reference to an individual CD may be expressed by a push-to-talk type cordless telephone. However, it should be understood that reference to a CD is not construed as limited per se, and may encompass other communication devices that have the ability to transmit and receive information in packets under the Internet Protocol (IP).

In the NBS system 10 of FIG. 2, a transmission privilege is defined that generally allows a single user to transmit information to other network members at any given time. The transmission privilege is granted or denied to requesting members of the network, depending on whether or not the transmission privilege is currently assigned to another network member when the request is received. The process of granting and denying transmission requests is known as arbitration. Other arbitration schemes evaluate factors such as the priority levels assigned to each CD when determining whether or not to grant a requesting network member the transmission privilege.

In order to participate in the NBS system 10, each of the CDs 12, 14, 16 and 17 has the ability to request transmission privilege from a communication controller or manager (CM) 18. The CM 18 generally manages the real-time and administrative operation of the networks. The CM is any type of computer-type device with at least one processor and memory. In one embodiment, the CM is a Sun Workstation Netra T1^TM.

The CM 18 maintains a list of defined networks, defined as either open or secure. Transitions between open and safe are generally not allowed. A secure network relies on the encryption provided by individual CDs to provide authentication and protection from eavesdropping. Encryption for secure networks is implemented in end-to-end terms, which means that encryption and decryption takes place within each CD. The CM 18 generally operates without knowledge of security algorithms, keys, or policies.

The CM 18 manages remotely, through either a communication system service provider, network members, or both, assuming authorization is provided by the service provider. The CM 18 can receive network definitions through an external management interface 226. Network members can request administrative actions through their service provider or manage network functions through defined systems, such as a member-managed security manager (SM) 20, which is compliant with a CM 18 management interface. CM 18 can authenticate, to high-grade commercial standards, anyone attempting to establish or modify a network.

ES 2 343 563 T3

The SM Security Manager 20 is an optional component of the NBS 10 system that performs key management, user authentication, and related tasks to support secure networks. A single group communication system can interact with one or more SM 20. The SM 20 is generally not involved in real-time control of a network, including network activation or push-to-talk arbitration. The SM 20 may have management capabilities that support a CM 18 interface to automate management functions. The SM 20 may also be capable of acting as a data endpoint in order to participate in a network, broadcast network keys, or simply monitor network traffic.

In one embodiment, the means for requesting transmission privilege to a CD comprises a push-to-talk type key or switch. When a user on the NBS 10 wishes to transmit information to other network members, the push-to-talk switch located on his CD is pressed, which sends a request to obtain the transmission privilege of the CM 18. If no other network member is currently assigned the broadcast privilege, the requesting user is granted the broadcast privilege and is notified by means of an audible, visual or tactile alert, via the CD. After the requesting user has been assigned the transmission privilege, information can be transmitted from that user to the other network member.

In one embodiment of the present invention, each wireless network member establishes a forward link and a reverse link with one or more base stations 22, or a satellite gateway 24, as the case may be. Base station 22 is used to describe a communication channel from base station 22, or satellite gateway 24, to a CD. The satellite gateway 24 is used to describe a communication channel from a CD to a base station 22 or gateway 24. The voice and / or data are converted into data packets using a CD, the data packets being suitable for a specific distributed network 26, through which communications with other users take place. In one embodiment, the distributed network 26 is the Internet. In another embodiment, a dedicated direct channel is established in each communication system (ie, a terrestrial communication system and a satellite communication system) to broadcast information from each network member to the other network members. Each network member receives communications from other network members over the dedicated channel. In yet another embodiment, a dedicated reverse link is established in each communication system, to transmit information to the CM 18. Finally, a combination of the above schemes can be used. For example, one scheme may establish a dedicated forward broadcast channel, but requires the wireless CDs to transmit information to the CM 18 on an individual reverse link assigned to each CD.

When a first network member wishes to transmit information to other network members, the first network member requests the transmission privilege by pressing a push-to-talk key on his CD, generating a formatted request for transmission over the CD. distributed network 26. In the case of CDs 12, 14 and 16, the request is transmitted over the air to one or more base stations 22. A mobile switching center (MSC) 28 comprises a well-known interoperable function (IWF) for processing data packets, including the request, between the MSC 28 and the distributed network 26. For the CD 16, the request is transmitted via satellite to the 24 satellite gateway. For CD 17, the request is transmitted to the Public Switched Telephone Network (PSTN) 30, then to a bank 32 of modems. The modem bank 32 receives the request and provides it to the distributed network 26. An NBS terminal 34 monitors the traffic of the NBS system through its connection to the Internet 26. Since the NBS terminal 34 is connected to the Internet 26, geographic proximity to the network participants is not necessary.

If no other member currently holds the transmitting privilege when the request for transmitting privilege is received by CM 18, CM 18 transmits a message to the requesting network member, notifying them that the transmitting privilege has been granted. Audio, visual, or other information from the first network member can then be transmitted to the other network members, sending the information to CM 18, using one of the transmission paths just described. In one embodiment, the CM 18 then provides the information to the network members by duplicating the information and sending each duplicate to the network members. If a single broadcast channel is used, the information needs to be duplicated only once for each broadcast channel in use.

In an alternative embodiment, CM 18 is attached to MSC 28, such that data packets from supporting base stations are routed directly to CM 18, without being routed through distributed network 26. In this embodiment, the CM 18 is still connected to distributed network 26 so that other communication systems and devices can participate in group communication.

The CM 18 maintains one or more databases to manage information pertaining to individual network members, as well as each defined network. For example, for each network member, a database can comprise information such as the username, the account number, a telephone number, or number to dial, associated with the member's CD, an assigned Mobile Identification Number to the CD, the current status of the member on the network, such as whether or not the member is actively participating in the network, a priority code to determine how the broadcast privilege is assigned, a phone number associated with the CD, an IP address associated with the CD, and an indication of which networks the member is authorized to communicate with. Other associated types of information may also be stored by the database regarding each network member.

As part of the NBS infrastructure, the communications manager (CM) forms individual communications terminal connections to form a chat group, or network. The CM comprises a wide variety of hardware and software functional capabilities, which are configurable in different ways, to accommodate different applications. Generally, the CM provides the ability to manage real-time operations, administrative and

ES 2 343 563 T3 network authenticity (from NBS), push-to-talk (PTT) request arbitration, maintenance and distribution of network membership and registration lists, call establishment and the decommissioning of the necessary resources of the CDMA system and the network, as well as the general control of the state of the network.

The NBS network can be within a deployable autonomous cellular system, or a large multi-site configuration. In the case of a large configuration, multiple CMs can be geographically deployed to form a single integrated system, each functioning as a module grafted onto the existing cellular infrastructure. Thus, the new features introduced by the NBS networks are available to cellular users, without requiring modification of the existing cellular infrastructure.

One role of the CM is to maintain a list of defined NBS networks. Each network definition includes a network identifier, a member list, which includes telephone numbers or other identifying information, user priority information, and other generic management information. Networks are statically defined as either open or secure, and transitions between open and secure are not allowed. A secure NBS network typically uses media encryption to provide authentication and guard against eavesdropping. Media encryption for secure networks is implemented in end-to-end terms, which means that encryption and decryption takes place within the communication device. The CM works without knowledge of algorithms, keys, or security policies.

The CM receives network definitions through an external management interface. Customers can request administrative actions through their service provider, or manage network functions through defined systems, such as a user-controlled security manager, which is compliant with the CM administration interface. The CM authenticates, to high-grade commercial standards, anyone attempting to establish or modify a network.

Before an embodiment of the invention is explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and arrangement of components set forth in the following description, or illustrated in the drawings. The invention is capable of other embodiments and is carried out in various ways. Furthermore, it is understood that the phraseology and terminology used herein is for descriptive purposes, and should not be construed as limiting.

FIG. 2 illustrates an NBS network 100, and how communication devices interact with a CM 104. Multiple CM 104 can be deployed, as desired, for large scale NBS networks 100. In Fig. 2, the communication device 108, or a CD 108, is allowed to transmit media over the network. In this case, the CD 108 is known as the speaker, and transmits media on one channel. When CD 108 is designated as the speaker, the remaining network participants, communication devices 112 and 116 (or CD 116 and CD 116) are not allowed to stream media to the network. Consequently, CD 112 and CD 116 are designated listeners. If CD 116 is designated as a speaker, CD 108 and CD 112 are designated listeners, and so on.

As described above, each CD 108, 112, and 116 connects to CM 104 using at least one channel. In one embodiment, the channel is divided into separate channels comprising a Session Initiation Protocol (SIP) channel 120, an NBS media signaling channel 124, and a media traffic channel 128. Session Initiation Protocol (SIP) channel 120 and NBS media signaling channel 124 can be used at any time, as bandwidth allows, regardless of being designated as a speaker or listener, by either party. CD 108, 112 and 116. SIP is an application layer protocol, defined by the Internet Engineering Task Force (IETF), that describes control mechanisms for establishing, modifying, and terminating multimedia sessions that operate over the Internet Protocol (IP). SIP provides a general solution to call signaling problems for Internet telephony applications, supporting means to register and locate users, mechanisms that define user capabilities and describe media parameters, and mechanisms to determine availability. of users, call establishment and call management.

SIP channel 120 is used to initiate and terminate CD participation within network 100. Optionally, a Session Description Protocol (SDP) signal can also be used within SIP channel 120. When CD participation within an NBS network is configured using SIP channel 120, real-time call control and signaling between the CD and CM 104 takes place using NBS media signaling channel 124. Specifically, among other tasks, the NBS media signaling channel 124 is used to handle push-to-talk requests and ceases; arbitrate between conflicting requests, or shift control; announce the beginning and end of the transmission of information; manage network downtime, trace endpoint connectivity, and request and exchange network status, notification, and error messages. The media signaling channel 124 protocol minimizes the length of the most common messages, and simplifies the task of interpreting responses and responding to requests, while retaining flexibility for future enhancements. The NBS media signaling channel 124 protocol also allows requests to be forwarded without adversely affecting the state of the protocol.

Signaling traffic on media channel 124 can be further differentiated into two categories: call setup and control signaling, consisting primarily of requests and acknowledgments of SIP invitations, and media signaling, consisting primarily of requests. shift control at

ES 2 343 563 T3 real time and related asynchronous messages. Media traffic on media traffic channel 128 is comprised of real-time point-to-multipoint broadcasts of voice and / or data. Both categories of messaging have unique functional attributes. In addition, each CD can issue Domain Name Service (DNS) client requests to facilitate the association of fully qualified DNS host names with network addresses on the Internet.

NBS call setup and call control signaling is carried out according to SIP semantics. Although SIP can be transported using either the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), in a preferred embodiment, each CD performs SIP-based signaling functions using UDP, depending on is illustrated in Fig. 4. In addition, each CM expects to receive all SIP signaling requests over UDP: Real-time signaling takes place over the dynamic UDP / IP interfaces on the CM and on each CD. Other signaling can take place over a fixed TCP / IP interface between the CM and the CD, using SIP.

Fig. 3 illustrates the modules and the physical composition of the CM 104. The CM 104 comprises a central module or complex 204 of the CM, at least one network module, or a media control unit (MCU) 208 and 212, a DNS server 216, redirect server 220, and administration workstation 224. The central CM complex 204 provides manageability to a Java ™ -enabled network browser. One or more DNS servers 216 may also be included in the central complex 204 of the CM. The central CM complex 204 further comprises a CM node 228 and a database server 232. The CM 104 is separable into at least two parts, the central complex 204 of the CM and each node 208 of the MCU. After the initial connection to the central complex 204 of the Cm, a network is managed by the node 208 of the MCU. MCU node 208 sends and receives information as needed from CM core complex 204. The separability of the central CM complex 204 allows versatility, in that, once a specific network is established, the network is managed by a dedicated MCU node 208. This allows the central CM complex 204 to provide initial connections to other potential networks, regardless of the type of communication structure in which the network wishes to operate. Additionally, the CM core complex 204 may be geographically offset from the MCU node 208. For example, a single central CM complex 204 may be located in the central part of the United States, and a plurality of MCU nodes 208 may be located regionally to manage networks from their given region. Thus, the central complex 204 of the CM can route a user to a specific node 208 of the MCU, based on the location of the user. In addition, a user, or group of users, may be provided with location-based information, such as issuance, instructions, or identification of location-based milestones.

CM node 228 provides centralized functionality associated with NBS networks. The CM node 228 comprises a session initiation protocol (SIP UAS) user agent server 236 and a CM manager 240, a central billing register 244, and an administration server 248. The SIP UAS server 236 supports user requests for network lists and handles SIP invite messages for networks. When a SIP invite message 229 is received from a communication device, the network assigns the communication device to a suitable MCU node 208, and directs the communication device to MCU node 208.

CM manager 240 monitors the status of all MCU nodes within a network, and assigns network execution to given MCU nodes, such as MCU node 208. The CM 240 manager controls the administrative functions pertaining to network administration, including the creation and deletion of networks, the definition of new users and the deletion of old ones, the addition and removal of users as network members, and the setting of various operating parameters based on users, networks or CMs.

The central billing register 244 maintains time and identification information for billing purposes. The central billing registry receives billing registration information from a local registry server 260 of the MCU node 208. Detailed log information is kept for each user, such as which communication devices are active on the network, for how long, from where, and when and for how long each CD is a speaker or listener. The Administration Server 248 supports an interface to allow the Administration workstation 224 to retrieve status information, and initiate database administration and systems management functions through the network status interface 280.

The CM implements both the SIP user agent server 236 and a SIP MCU server 252. To support NBS, each CD implements a SIP user agent client. The CM receives incoming SIP connections on an advertised node, or port. When a connection occurs, the SIP server 236 receives and processes requests according to the SIP call signaling conventions: The SIP server 236 is capable of processing multiple call signaling connections in parallel.

To conserve network resources, the CD can release its UDP connection to the SIP server 236 after it has successfully (or unsuccessfully) joined the NBS 100 network. The UDP connection can be reinstalled later to send Additional SIP call signaling requests (for example, to leave the network or to switch to another network).

FIG. 4 illustrates an example of an NBS SIP signaling protocol stack 300. The stack is a collection of protocol layers that implement network communication. The protocol associated with each layer communicates with the layers immediately above and below it, and supports the underlying layers. Due

ES 2 343 563 T3 since UDP is less reliable connectionless transport, application level reliability is preferable, to ensure robust communication, which is achieved by implementing SIP compliant endpoints. Generally, SIP call signaling 302 on UDP flows 304 is encapsulated within the IP protocol 306. No special format is required. SIP call signaling IP packets 306 are exchanged, for example, between a CDMA cellular-based CD or a dial-up PSTN-based CD, which are encapsulated within 308 point protocol frames. ready (PPP). Consequently, no special format is required. In addition, SIP call signaling PPP frames 308, exchanged between a CDMA cell-based CD and a base station, are encapsulated within a radio link protocol (RLP) 310. For users based on the PSTN with dial-up link, a suitable modem standard, such as V.32bis or V.90, can replace RLP 310. In any case, no special handling is generally required, and a free physical link is not assumed. mistakes.

Fig. 5 illustrates an NBS media signaling protocol stack 312, which carries voice and data traffic, using UDP datagrams 304, over the IP 306 protocol. The NBS media signaling 314 is arranged as a layer on top of the UDP / IP traffic 306, and is handled similarly with respect to the description in Fig. 4.

FIG. 6 illustrates a real-time voice media protocol stack 320. In this embodiment, the vocoder payload data 322 is layered over Real Time Protocol (RTP) 324. RTP 324 is then layered over UDP 304 and IP 306. In an optional embodiment, it is employs Compressed Real-Time Protocol (CRTP) header compression 330 to further encapsulate media traffic using RTP 324 at the application layer. Header compression techniques can be applied, as appropriate, to all incoming and outgoing UDP / IP traffic illustrated in Figs. 4-9. Media signaling requests and responses are encapsulated within UDP datagrams. When available, CRTP header compression can be applied to reduce the impact of sending uncompressed UDP / IP headers. In Fig. 6, CRTP compresses RTP Layer 324, UDP Layer 304, IP Layer 306, and PPP Layer 308. In Figs. 4, 5 and 7 to 9, the CRTP 320 compresses the layers between the UDP 304 and the PPP 308, both inclusive.

In operation, each CD dynamically selects a port from the UDP, by which it intends to listen for media signaling requests from the NBS, and communicates the port number to the SIP service 236 as part of the SIP invitation that it delivers when trying to join. a network. The network CM media signaling destination address (including the UDP port number) is described in the description of the network session delivered as part of the response to the CD of a successful SIP INVITE request. Unlike SIP signaling addresses, media signaling destination addresses are network specific and can change between instances of a CD joining a network. Multiple networks hosted by the same CM generally operate independently, and do not share media signaling or media traffic ports. However, it is contemplated that multiple networks can share the media signaling and media traffic ports.

Referring to FIG. 6, voice traffic is encapsulated by grouping one or more vocoder frames into a 324 RTP / UDP or 304 UDP payload. The use of RTP 324 with CRTP 330 enabled is used to minimize end-to-end media latency, and provide interoperability with IP telephony applications and services. In either case, the CD dynamically selects the UDP port on which it expects to receive media traffic, and communicates the port number to the SIP server 236 as part of the SIP invitation it delivers when attempting to join a network.

The network vocoder and transport encapsulation protocol, as well as its destination address of the media traffic (including the UDP port number), are described in the session description response to a successful SIP invite request. , from the SIP server 236. Like network media signaling addresses, media traffic destination addresses are network specific and can change between instances of a CD joining a network.

Typically, as shown in Fig. 6, voice traffic is encapsulated in the application layer employing RTP 324, which segments each UDP datagram 304 into an RTP header 324 and vocoder payload 322. FIG. 7 illustrates a UDP voice media protocol stack 332. Voice traffic can optionally be encapsulated using exclusively UDP datagrams 304, with no RTP encapsulation, typically when CRTP header compression 330 is not available, or is not supported by a network member. FIG. 8 illustrates a stack 334 of media traffic protocols. The media traffic protocol stack 334 is used for network participants without any RTP encapsulation at the application level. Data 336 is encapsulated in UDP datagrams 304.

The structure of the UDP payload 304 follows the definition given for a corresponding RTP payload 324, without the RTP header fields. The decision to encapsulate media directly in UDP 304 is configured by the network administrator 248, and published by the network session advertisement. In addition to voice media, NBS networks can also support arbitrary data broadcasts. If a network supports a data broadcast channel, the SIP server 236 publishes the media type in the network's SIP session description when a CD formally joins the network.

FIG. 9 illustrates a DNS client protocol stack 338. Each CD includes the ability to resolve Internet domain names to Internet addresses, using a Domain Name Service 340 protocol.

ES 2 343 563 T3 (DNS). The CD functions as a DNS client. The CD encapsulates DNS 340 requests using UDP 326, as shown in Fig. 9. In order for the CD to resolve DNS host names, the CD is provided with a server IP network address 216 DNS, as shown in Fig. 3. The DNS address is also configurable by the CD service provider and, optionally, by the user.

In addition to voice media, networks can also support arbitrary data broadcasts, such as secure network key repetition, email, data files, and so on. If a network supports a data broadcast channel, the CM publishes the media type in the network's SIP session description when the CD formally joins the network. Like traditional media broadcasts, generic data broadcasts work over the RLP in one embodiment (or a corresponding physical layer), but are generally considered less reliable transports.

The CD includes the ability to resolve Internet domain names to Internet addresses, using the Domain Name Service (DNS) protocol, as defined in RFC (Request for Comments) 1034. Alternatively, the CD functions as a DNS client or resolver, as described in RFC 1035.

In order for the CD to resolve DNS host names, the CD is pre-programmed with the IP network addresses of a DNS server. The DNS address is also configurable by the CD service provider and optionally by the user.

The CM 104 can optionally be configured to act as a DNS server 216. Although it can respond to DNS requests from outside entities, using TCP as the transport protocol, in order to service CD-originated requests, the SIP server 236 also encapsulates DNS messages using UDP 304, as per the Fig. 8.

The NBS also takes advantage of the development of a cellular multicast channel. Such a channel generically allows a transmitting station to access N listening stations directly, over a direct channel, without the need for N different rebroadcasts of the transmitted data. The presence of a cellular multicast channel implies changes in the NBS media stack, mainly below the IP network layer. To take advantage of the efficiencies provided by a cellular multicast channel, the destination addresses of the signaling and media traffic of a network are conventional IP multicast channels, and the signaling and media traffic broadcasts, originating from the CM, are multicast broadcasts. Each of the signaling and media traffic broadcasts, originating from a CD, and SIP signaling, remain as point-to-point communications.

The Radio Link Protocol (RLP) 310 shown in Figs. 4 through 9 can be modified within each CD to minimize latency experienced when link layer loss (RLP frame) occurs. Such modifications are optional and do not necessarily affect the transport operation of the application layer protocols, since neither TCP nor UDP 304 assumes a reliable network (IP), or link layer service.

A variety of RLP 310 modification strategies are possible. For example, RLP 310 can be modified to send multiple messages, such as negative acknowledgment NAK responses, after an initial RLP timer expiration, thus requesting the remote end transmitting multiple copies of the lost frame from RLP 310, and improving the chances of a successful recovery from RLP 310. The RLP 310 can also be modified to never send NAK responses (after the RLP timer expires) and to support discarded frames 310 from the RLP to force the upper levels of the protocol stack to generate errors. Any application-level protocol, based on TCP, is recovered routinely, using TCP's error recovery mechanisms. Traffic that relies on UDP 304 for transport already faces the potential for loss.

Referring again to Fig. 2, once the CD establishes participation with the NBS network 100, using the SIP channel 120, the CD is ready to send and receive media from the network 100, through a specific media port. of the CD, on channel 128 of media traffic. If the CD gains turn control through media signaling, as is the case with CD 108 in Fig. 2, the CD transmits media to the destination network and transport addresses, as indicated in the session description of network 100. The CD decodes received media on its media ports, according to the vocoder and the media format defined in the session description of network 100, received in an invite response when the CD joined network 100. The CD encodes and encapsulates the media sent to the network 100, according to the vocoder and media format defined in the session description of the network 100, received in an invitation response when the CD joined the network 100.

Each CD participating in a network determines the destination network and the transport address for each media channel, from the session description received from the SIP server 236 of the CM 104, and acknowledged as received during call setup of the SIP, and uses it to access the corresponding media sent within the network 100. Each CD provides a packet data connection to the CM. Changes can be made to the CD implementation of this interface, to optimize the performance of the NBS. Changes to the infrastructure side of this interface are generally not necessary. Optionally, the CD can support most NBS activities using Quick Network Connect (QNC), as further described in this document.

ES 2 343 563 T3

Upon delivery to a service provider, the CM Manager 240 goes through the basic administrative configuration before supporting the activities of the NBS. The initial configuration involves the basic configuration of the system, such as the assignment of passwords to the accounts at the operating system level, for the administration of the system at the root level and for the configuration of the network interfaces of the CM 240 manager, for their correct operation in the local wireless infrastructure network.

Once the CM 104 is configured, general network management can take place. Network administration functions take place through an HTML interface, or another network interface, built on top of TCP / IP. The administration workstation 224 interfaces with the central complex 204 of the CM, using a conventional World Wide Web (WWW) scanner. Administration can take place locally or remotely (anywhere on the Internet, or via telephone connection). However, the underlying transport path for administrative access is typically TCP / IP. Additionally, multiple (at least three) concurrent management connections are allowed.

When connecting to the central CM complex 204 for network administration purposes, the administrator workstation 224 authenticates itself successfully, to ensure that only authorized administrative actions are accepted. Different levels of access are supported; for example, authorized members of the network can connect directly to the administrative interface (248) of the Cm to modify lists of members of specific networks. The more generic administrative privileges are generally reserved for specific administrative accounts. For clarity, administrative actions are generally divided into those that specifically address user definitions and those that define networks. A user definition comprises information such as the user name, the unique cellular system identifier of the CD, the telephone number of the CD, and the email address of the user. A unique user identifier is defined that can be passed to the CD and used to uniquely identify the user in signaling messages. A network definition comprises information such as the network address, the network timeout, the private dispatch timeout, and the member list. A list of network members comprises information such as a list of member records, which individually contain a user identifier and a priority level. A member with the lowest priority level typically has listen-only privileges.

The CM administrator 248 can monitor the current status of the networks for which he has administrative privileges. In particular, the CM administrator 248 can determine the current list of network participants, as well as monitor the status of the network (active, idle, sleeping, waking up, etc.). Anytime the network is up, the CM administrator 248 can also monitor the identity of the current speaker. Additional statistics and statuses, such as current session length, total chat time, average number of registrants, etc., can also be made available to administrators through the administrative interface.

The management server interface 248 comprises at least two network nodes, or ports. One is a TCP / IP-based HyperText Transfer Protocol (HTTP) interface, which supports administrative access through a conventional Java ™ -enabled web browser. The second is an NBS-specific Command Line Interface (CLI), based on TCP / IP.

The administration server 248 makes all administrative functions available to a generic web browser, via an HTTP web server interface with one or more pages formatted using an Internet-readable medium, such as a Web Language syntax. HyperText Markup (HTML). At least one of the administrative pages can include a reference to an embedded Java ™ applet. Some administrative functions, optionally, can be carried out through the HTTP GET and POST commands, issued by the web browser, using conventional HTACCESS authorization mechanisms. Supported administrative functions are generally a subset of those that are supported by the CLI interface.

The HTTP interface can be used to deliver a Java ™ applet to the web browser. The applet can then rely on the CLI interface of the administrative server 248 to provide additional administrative functionality to the user through a web browser interface. Before access to the CLI interface is granted, a potential administration workstation 224, connected to the CLI interface of the administrative server 248, is authenticated. In a preferred embodiment, the CLI interface is accessible on a well-known, fixed TCP port address, and is capable of simultaneously managing multiple CLI sessions.

Database server 232 is responsible for the storage of network information and parameters, network user information, and status information associated with MCUs 208 and 212, and CM node 228. Database server 232 also it serves this information to the rest of the CM 104, such as the SIP server 236 and other modules that need such information. The database server 232 maintains databases that capture information that supports the activities of the NBS network, including a database portion of the NBS network, and a portion of the NBS user database. The information that supports activities and administration privileges can be stored in any of the databases, or in a third, functionally distinct database. The database server can be further subdivided into a user portion and a network portion.

The CLI interface supports administrative functions such as user / network creation, user / network deletion, user / network modification, user enumeration / detail, network enumeration / detail, status, and help from the CLI. The Create User function allows the administration server 248 to create new users

ES 2 343 563 T3 in the user portion of the database, including the specification of all user record fields. The Delete User function allows the administration server 248 to delete existing user records in the user portion of the database 232. The Modify User function allows the administration server 248 to modify existing user records in the user portion of the database 232, including modifying all the record fields for a specific user.

The Create Network function allows the management server 248 to create new networks in the user portion of the database 232, including the specification of all network definition parameters. The Delete Network function allows the management server 248 to delete existing networks in the user portion of the database 232. The Modify Network function allows the management server 248 to modify existing networks in the user portion of the database 232, including modifying all the network definition parameters for a specific network. The Enumerate User function enables the management server 248 to list all users, by username, dial-in number, and user identifier, in the user portion of the database 232.

The Network List function allows the management server 248 to list all networks, by network address and network identifier, in the network portion of the database 232. The Show User function allows the management server 248 to display all fields for a specific user identified by the user identifier. The Show Network function allows the management server 248 to display all the fields for a specific network, identified by the network identifier or the network address of that network. The Status feature allows the management server 248 to query a static status report for a specific network. The Status function can also allow the management server 248 to view (updated) reports in real time. In particular, the status function identifies the current list of network participants, the current speaker, the presence or absence of media traffic, and identifies each and every media signaling message sent or received by the CM. . The Help function allows the management server 248 to view a brief, human-readable summary of each supported CLI command, including the usage and description of the syntax.

The NBS user portion of the database 232 tracks individual NBS users. The user records contained within the database 232 may or may not necessarily be members of the networks defined in the CM network portion of the database 232.

Each record in the user portion of the database 232 comprises fields such as the user name, the user identification, the vocoder list, the dial number, the user type, the CRTP support, the address of the user. user of the CD, and the Pretty Good Privacy (PGP) public key of the CD. The vocoder list is a list of the vocoders that are supported by the subscriber's CD. The list may include vocoders not supported by the NBS. The dial number is the dial number of the subscriber's CD. This field is empty, or null, for generic Internet users. User Type is a type field that describes whether the user is a CDMA cellular user or a generic Internet user. Users who connect using PSTN dial-up are considered generic Internet users. CRTP support is an indicator that indicates if the CD supports and tries to negotiate CRTP Header Compression over PPP when connecting. This indicator is valid for cellular users as well as PSTN-based users. The CD user address is the globally unique user address for the CD. A CD known to multiple user addresses will have multiple corresponding entries in the user portion of the database 232. The PGP public key is the key associated with the user address of the CD.

The NBS network database defines the set of networks known to the CM. The network portion of the database 232 also lists the defined members of each network; that is, those users who can request to join and become participants in a network. Each record in the network portion of the database 232 comprises a large variety of fields. The fields include a network identifier, which is a unique integer that identifies the network within the context of the CM. The fields also include a network address, which is the SIP-compliant network address of the network. The network owner (s), a nonempty list of users, are identified with user IDs that have administrative privileges (defined separately) for the network. Also, the network security status is a field for an indicator that indicates whether the network is open or secure.

The fields also include the arbitration scheme, which is a unique value that identifies the arbitration scheme used to resolve push-to-talk (PTT) arbitration conflicts between network participants. The network vocoder describes a field with a unique value that identifies the standard vocoder displayed in the published session description of the network. Defined members of the network have this vocoder listed in their supported vocoder list. The PTT system failsafe timeout is the maximum number of seconds that a network participant can transmit media to the network before the CM revokes control of the turn with a PTX deny message. The timeout value is the maximum number of seconds that the network can be idle before the CM puts it into the sleeping state. The PTX Inactivity Response timeout value is the maximum number of seconds the CM waits before determining that a sleeper network's turn can be granted before transmitting the PTX grant response to the requesting CD. The wake-up time-out value is the maximum number of seconds the CM waits for network participants to respond to the “wake-up” message AYT (Are You There?) Before granting a pending push-to-talk request. The lingering timeout value is the maximum number of seconds that the CM waits for a CD to respond to the CM's AYT “wake-up” message before the CM removes the unresponsive CD from the network list of active participants. . The temporary expiration value

ES 2 343 563 T3 of the AYT message is the maximum number of seconds that the CM waits for a CD to respond to an AYT message from the CM before the CM removes the CD from the network list of active participants. The media channel list is a list of media channels, including payload specifications, for the network (networks list at least one media channel, which carries voice).

The list of network members defines the set of users who can request to join the network as participants, and specific associated network privileges. Each entry in the list contains fields such as the user identifier, which is a unique identifier of a user listed in the CM user database 232. The fields also include the user's network priority level, which is the user's priority level to be used by the arbitration algorithm of the network's PTT system when resolving PTT conflicts. A priority level of zero indicates that the user has listen-only privileges, and can never be granted control of the network. The fields can also include a list of user authorizations, which details the authorization privileges, if any, that the user has for the network. Privileges may include the ability to add, edit, or modify network member list entries, and the ability to modify other network parameters.

Each CD maintains a database, also known as the group list, that identifies known networks that the CD can request to join. Each entry in the CD database includes fields such as the network address, the network security advisory flag, the network traffic encryption key, and the idle watchdog timer. The network address is the formal network address of the network's SIP, which the CD uses to request to join the network as an active participant. The Network security advisory flag is the open / secure status advisory flag, distributed by the CM SIP server 236 in its list of available networks, or set by the user to indicate a network defined to carry secure media traffic. Type IV. The network traffic encryption key is the traffic encryption key used to encrypt and decrypt all media traffic for secure Type IV networks. The idle watchdog timer is the length of the interval, in seconds, that the CD will wait, when in the Sleeping / Idle state, to transition to the Connected state, confirming that the packet data call remains valid and that the station base has not unilaterally cut the connection.

The MCU node 208 comprises an MCU 252, an MCU node manager 256, and the local registry server 260. The mCu node 208 and 212 may also optionally comprise an additional MCU 264. The MCU node 212 is essentially the same as the MCU node 208. For purposes of description, only MCU node 208 is discussed herein. MCU 252 is responsible for the control of a single active network. The MCU supports SIP, media signaling, and media interfaces for the network, and provides the functionality associated with normal network operation. Each MCU node 208 may have a reserve of MCU 252, which can be oriented to manage networks, as appropriate. Each MCU 252 provides an MCU management interface 268, to support functions such as start, stop, and status reporting.

The MCU node manager 256 monitors the operation of the MCU node 208 and manages the operation of each MCU 252 at its MCU node 256. The MCU node manager 256 also provides an external interface 272 to the central CM complex 204, for startup and / or shutdown, for assigning a network to the node, and for sharing status information.

Local log server 260 logs all log events locally for MCU node 208. The local log server 260 also responds to requests from the central log server 244, via its log event interface 276. Requests include downloads of certain classes or priorities of events. In order to prevent loss of events, messages are stored in local registration server 260 until an acknowledgment is received by central billing registration server 244.

The DNS server 216 provides name services to the NBS communication devices. The DNS server 216 can service service record requests (SRVs). The DNS server 216 can be located anywhere on the network. In one embodiment, the DNS server 216 is a part of the CM core complex 204.

Each CD maintains a list of networks, or a list of groups, that internally represents the set of known networks in which the CD can participate. The list is non-volatile, but can be updated as needed, either through interactions with a CM 104 or interactively by the user. The user can also determine who and how many users are either active or inactive on the network. The NBS group list maintained internally by a CD is analogous in function to the list of names and dial numbers maintained in the telephone book, and is used to facilitate voice services. The NBS group list can be integrated with the conventional phone book of the telephone. In either case, the act of selecting a network from the group list instructs the phone to attempt to join the selected network.

In order to participate in a specific NBS network, each CD initially requests that the CM add itself to the list of active network participants for a specific network. Thus, each CD is initially aware of, or capable of learning, the network address of any network in which it wishes to participate. Furthermore, each CD initially knows, or is capable of being configured with, the address of a higher-level SIP server 236, to which SIP requests can be sent.

ES 2 343 563 T3

Network addresses can be registered on, or learned by, a CD in a number of ways. For example, in one embodiment, the address of a high-level SIP server 236, known or default, may be initially registered on the CD which provides a current list of networks in which the CD can participate. A group list can also be registered on the CD, which defines at least one network address in which the CD is a member. The CD can later send a request to the top-level SIP server 236 to update its group list. In the event that no explicit registration of the NBS has taken place for the CD, the user may be provided with a high-level SIP server 236 and the network address to interactively access the CD before using the NBS. The user can also interactively enter network addresses in a list of groups in which entries have already been registered. Such a configuration step is analogous to entering personal names and dial numbers in the conventional telephone book.

Note that although users can interactively enter a network address in the group list on the CD, the corresponding network, and the top-level SIP server 236, preferably already exist, and the user needs to be registered as a member of the network so that the CD can successfully participate in the network.

The CD can also register the IP network address of the Domain Name Service (DNS) server 216, to which the CD can send DNS queries. Usually, the address of the DNS server 216, managed by a CDMA cellular carrier, is registered. On the CD you can also register the IP network address of an alternative DNS server.

To support SIP authentication, a unique PGP user ID and secret key can be registered on the CD, which you can use to sign SIP transactions when prompted by the CM 104. The user ID PGP can also be used as the CD user address for generic SIP transactions.

FIG. 10 illustrates the high-level functionality of the CD group services module 500. Typically, the group services module initializes to an idle state 504 by default when the CD is powered on. From idle state 504, the CD can transition to other states that allow it to actively participate in NBS networks.

The user may wish to temporarily disable NBS services through a menu option within the user interface of the CD. If the user has disabled NBS services, the group services module defaults to a disabled state 508 when the CD is powered on. When disabled, the CD does not automatically attempt to join any NBS network. Also, the CD does not perform any SIP-specific transactions (the CD may keep records or perform other SIP transactions for other IP-based telephony applications, which reside within the CD).

Optionally, group services can be completely hidden from the user, registering group services within the CD in an unequipped 512 state. The unequipped state disables group services, while an equipped state enables group services. Once not equipped, the DC requires an administrative discharge to equip group services. When group services are not equipped, NBS group services functionality and associated user interface features are not available to the user.

The CD can support over-the-air registrations to equip NBS group services. In the event that the group list on the CD contains more than one network address, no more than one network address can be identified as a 514 network by default. If a network address is selected, the CD attempts to automatically transition from idle state 504, attempting to join this selected network shortly after the CD is powered up.

When the CD is connected, the CD cycles through an idle state 516, a listening state 520, a talk state 524, and a sleep state 528, based on where the user is in the push-to-talk system. , as described with respect to Fig. 16.

The NBS relies on the syntax and semantics of call signaling, as defined by SIP, to publish available network addresses and to provide mechanisms by which an individual CD can formally join, or leave, networks. . The CM 104, along with other functional entities, includes the high-level SIP server 236, one or more multipoint control units (MCUs) 252 and associated SIP user agent servers, and user and network portions of the administration database 232. The top-level SIP server 236 acts as a known rendezvous point to participate in the system. Each MCU 252 performs media signaling and media traffic switching for one or more networks. The database 232 stores and provides known network address, administration, and user definitions, and can serve multiple CM installations or allow them to be accessed remotely.

Each CD is provided with a list of network addresses, and one or more high-level SIP server addresses 236. If the group list is empty, the user can interactively specify the address of an existing network. If no top-level SIP server 236 is defined, the user can interactively specify the address of a top-level SIP server 236. Once the address of the top-level SIP server 236 is known, the CD can request an updated list of networks available to it by making a call, using the SIP INVITE procedure, to a predefined SIP destination.

ES 2 343 563 T3

The top-level SIP server 236 can redirect the request to an internal destination, or respond to it directly. The INVITE response for this call includes the current list of networks available for the CD. The CD uses this list to update its internal group list.

After a network has been selected, the CD attempts to join the network using the SIP INVITE procedure, specifying the network address as the destination of the invitation, and sending the request to the top-level SIP server 236. The top-level server 236 attempts to associate the network address with a known destination and, if successful, redirects the CD to the corresponding MCU 252 SIP user agent server. If no association is available, the invitation generally fails.

Typically, the MCU 252 destination SIP user agent server confirms that the CD is a member of the selected network and responds to the invitation, embedding a description of the media traffic, and the signaling parameters to use to participate. on the web, in the content of your answer. The MCU 252 SIP user agent server may also respond with an error if it is unable to confirm the CD as a legitimate member of the network, or if some other error condition arises, such as a failure that prevents normal operation. of the network. If the invitation is accepted, the CD acknowledges receipt of the response through a message, such as in the SIP acknowledgment ACK procedure. Note that other transient response codes, indicating the progress of the call, may also be received by the CD while the invitation is being processed.

The CD is responsible for updating its list of groups with all the networks in which it can participate. The user can instruct the CD to query the CM 104 database 232, even when no network address is selected, in order to receive updates for its group list. If the CD determines that it has been added to or removed from a network, it briefly displays a suitable message to the user (eg, "Added to Group X") and / or possibly requests user interaction. If the CD determines that it is not a member of any network, it will similarly inform the user. The CD can automatically add new network addresses to its group list, but it can query the user before deleting network addresses, in which they have lost membership, from the group list.

Generally, no more than one network in a group list on a CD can be identified as selected at any one time. A default network can be selected initially, or the user can select a network from the group list.

The CM SIP user agent server of the MCU 252's response to an INVITE request to join a network includes, as embedded content, the network media and real-time media signaling destination addresses, as well as other network parameters (such as the media payload format descriptors). Once confirmed, the CD briefly displays the response to the user, indicates whether the user has listen-only privileges, and enables the group's service functions. If the CM 104 determines that the CD is not a member of the selected network, or if an error or other exceptional condition occurs, the SIP server 252 responds with a corresponding error response. When such registration is rejected, the CD briefly displays a corresponding error message and the group service functions remain idle. If no network is selected, group services within the CD remain idle.

As part of the group service activation, the CD initializes and opens its RTP media traffic channel 128, and NBS media signaling channel 124 separately, to the CM destination addresses provided in a successful response to the invitation. Once these channels have been initialized, the group services are activated on the CD 108 and it enters the group services idle state 516, with the ability to receive voice traffic from the network and request permission to send traffic from the network. voice to the network.

With group services active, the CD 108 monitors its media traffic 128 and signaling channels 124 with the CM. Voice data received on media traffic channel 128 is decoded and presented using a remote speaker from the CD 108, or a headset accessory, depending on the user's current configuration. The CD 108 displays the identity of the current speaker, as identified by the real-time media signage 124. If the identity of the current speaker is not available, the CD 108 displays the name of the currently selected network, as listed in the group list. The CD 108 can also tabulate media traffic statistics (e.g., total time spent talking, listening and monitoring, estimated packet loss received from media traffic) and make them available to the user as a diagnostic, using an option from the menu. Upon receiving traffic from the network, the CD 108 transitions to the group service listening state 520, returning to the idle state 516 when the voice traffic stops.

At any time, the user can request permission to speak to the network by pressing the PTT button and causing the CD 108 to signal the CM 104 (specifically, the MCU 252) with a turn control request. The PTT button can be any type of activation command, including, but not limited to, a key press or sequence of keys, voice activation, a switch, a toggle device, or dials. MCU 252 responds by either granting or denying the request. If the CD has listen-only privileges, such as CD 112 (that is, the CD has a zero priority level within the selected network), the request is denied. If denied, the CD 112 alerts the user with an error tone, displays an appropriate error or explanation message, and returns to the idle state 516. The CD insists that the PTT button be pressed and released again before attempting another request for shift control. If granted, the CD 112 enters the group services talk state 524, signals the user with, for example, a short audible chirp, and begins transmitting voice traffic to the CM 104 as long as the button

ES 2 343 563 T3

PTT is pressed. The CM 104 can asynchronously signal the CD 112 (while the PTT button is pressed) that it has lost control of the turn. Upon receiving such a signal, the CD 112 aborts the transmission of voice traffic and alerts the user with an error tone until the PTT button is released, at which point it returns to the idle state 516. Otherwise, once the PTT button is released, the CD 112 signals the CM 104 that it has released the turn and returns to the idle state 516.

A user can switch to a different network by selecting another network from the list of groups, as long as the group services within the CD 108 are in the idle state 516, the listening state 520, or the sleeping state 528. When a new network is selected, CD 108 signals CM 104 to remove it from the current network, via SIP call setup mechanisms, and then follows similar procedures to join the new network. If the process of joining the new network fails, CD 108 is no longer a member of any network, and group services within CD 108 revert to idle state 504.

If CM 104 determines that the CD 108 requesting the turn for a specific network is the only registered member of the network in question, CM 104 denies the request for turn control and signals an error message, such as a turn-off error. lone user, which the CD 108 displays to the user. Although a network may exist with only one registered member, a network cannot relay voice traffic unless there are at least two registered members.

The NBS application relies on two different application-level protocols: Session Initiation Protocol (SIP) call signaling, as described with respect to Fig. 11, and NBS Media Signaling, as described. described with respect to Figs. 12 to 14. SIP is used exclusively for call signaling and call establishment. Media signaling carries PTT (Push To Talk) requests (Fig. 12), manages network downtime (Fig. 13) and resolves arbitration conflicts of the PTT system (Fig. 14).

SIP call signaling 350 is illustrated in Fig. 11. The Session Initiation Protocol provides NBS application layer control (signaling) to discover, join, and leave NBS networks using interface 236 from the SIP server of the CM 104. To join a network, a CD 352 invites the network 100, by name, to participate in a call, through the high-level SIP server 236. To leave the network 100, the CD 352 sends a corresponding "goodbye" to the network.

The CD 352 determines the IP address of the top-level SIP server 236 using DNS 216 to resolve the registered addresses of the primary or secondary SIP server as Internet network addresses, if necessary. As an optional alternative approach, SIP conventions allow the CD 352 to query DNS 216 for service records associated with the NBS host domain portion of the network address, and to contact the host's server 236. SIP at the returned address (es).

By default, CD 352 attempts to contact SIP server 236 using a default SIP port, unless alternative port information is determined by DNS 216. Before attempting to join a network, CD 352 you can establish a call using the SIP INVITE procedure to request an up-to-date list of available networks.

For example, the CD 352 that has played an over-the-air connection is assigned an IP address, and you want to determine its current list of available networks. This opens a UDP / IP connection to the SIP server port and issues a request. The request for an up-to-date list of networks is sent to a special destination. Where applicable, CD 352 also includes additional, application-specific headers that identify the CDMA network and the system from which a CDMA-based cellular CD 352 is obtaining service.

The CD 352 may also include a header to indicate that the CD 352 expects the SIP server 236 to understand and support the NBS services. The option value distributed with the header can also be used by the CD 352 to inform the server 236 of a specific version or type of NBS services that the CD 352 expects the server 236 to support.

The CM high-level SIP server 236 may redirect an invitation request 356, using SIP redirection mechanisms, to a specifically defined destination for receiving and responding to requests for network information. Upon receiving such redirection, the CD 352 acknowledges (ACK) the response 357 and forwards the request to the redirected destination.

The CD 352 may need to determine the appropriate SIP point of contact for the redirected address, through DNS mechanisms. To simplify this process for CD 352, server 236 can specify the redirection destination explicitly, using its Internet network address. Once an INVITE message 354, requesting a list of networks, is successfully received and accepted by the server 236, the server 236 delivers a response 356 to the INVITE request.

The response 356 to the INVITE request includes in its content a list of registers that define the set of networks that the CD 352 can then join. Server 236 queries its network database 232 for networks that list requesting CD 352 as a defined member to form response 356 to INVITE request 354. Networks are identified within content using an application-defined record format, which includes the formal network address of the network. Networks can be listed in any order.

ES 2 343 563 T3

Server 236 may be unable to successfully respond to CD 352, for a number of reasons. In such circumstances, the server 236 delivers an appropriate SIP status code in place of the response 356 to the INVITE. The CD 352 should be ready to accept and interpret such status codes, taking appropriate action (such as displaying an error message on the CD 352 user interface display) in the event of any fatal errors. The server 236 may also precede a successful response 356 to the INVITE with status informational responses indicating the progress of the records. The CD 352 can accept and interpret informational status codes that precede successful registrations.

The CD 352 requests to join a network by issuing a SIP INVITE 358 request to the CM 240 manager, through the server 252. If the CD 352 does not have an open UDP / IP connection with the SIP server 252, it will open a new connection UDP / IP with the SIP server port.

The CD 352 is ready to be redirected by the high-level SIP server 236 and to re-issue the request to the redirected destination, if necessary. The CM high-level SIP server 236 redirects any incoming INVITE requests, as appropriate, to the MCU's SIP server 252, currently associated with the network in question. The CD 352 can be redirected more than once.

The INVITE request 358 may include a description (as message content) of the media sources, originating from CD 352, assuming the invitation is successful. If included, the description is included as message content and is described using field constructs.

The session description is delivered in a format that is compatible with the Session Description Protocol (SDP). After defining the version (v) of the SDP, the session description includes a mandatory description of the origin (o). The CD 352 may use any convenient mechanism to choose the values ​​for the session identifier and the session version. Providing an estimate of the current time is one possible way to define the session identifier. The connection data (c) is specified by defining the network type, the address type, and the connection address. The CD 352 uses the IP address with which it labels (or generates) media traffic as the connection address. The CD 352 uses the name portion of the network address of the network as the session name, or names. The CD 352 specifies the lifetime (t) of the session by providing its best estimate of the current or start time, preferably in Network Time Protocol (NTP) format, and indicates that the session is unlimited (0). The media format description (m) defines the media type, source port, transport protocol, and payload format that the CD 352 intends to use to transmit to the network. Finally, the session description uses an attribute type definition (a) to indicate that the CD 352 expects the session to be handled as an NBS conference. The server 236 should confirm that the invitation address is indeed a valid NBS network address before granting the invitation.

To indicate a successful invitation, and specifically inform the CD 352 that it has been added to the participant list for the invited network, the server 236 delivers a response 360 ​​to the INVITE.

A successful 360 response to the INVITE includes the description of the primary session for the invited network, which describes the ports and media traffic formats that are supported, using the syntax of the SDP. The session description includes a connection description (o) that defines the network address to which all signaling and media traffic should be sent. The network media destination network address of the network is not necessarily the same as the network address of the SIP user agent server, resolved using DNS from the network address of the network.

The session description describes all the target media ports and media. The session description should also include an identifier assigned to CD 352 by MCU 252, in order to identify media signaling messages transmitted by CD 352 as part of its subsequent participation in the network. The value of this identifier is unique among all active participants in a given network and therefore should be dynamically generated. CD 352 does not necessarily cache this identifier between successive SIP invites.

The session description may also include an NBS protocol version advertisement, which indicates the revision level to which the network media signaling conforms. Such an advertisement can be implemented by extending the value of the type attribute field, or by defining a new attribute, the value of which is the version number of the protocol.

After receiving a successful response to the INVITE, the CD 352 confirms the invitation by again sending a SIP acknowledgment (ACK) request 362 to the network MCU's SIP user agent server 252. After transmitting the ACK request 362, the CD 352 can close its TCP connection with the SIP server. Before the ACK request 362 is transmitted, the CD 352 initializes its traffic and media signaling ports, based on the session description delivered in the INVITE response 360.

At any time after the CD 352 has transmitted the SIP ACK 362 message, in response to a successful 360 response to the INVITE, the CD 352 can formally terminate its participation in the network by sending a SIP GOODBYE 364 message to the agent server 252. network user. Before sending the GOODBYE 364 message, the CD 352 may need to open a TCP connection with the user agent server 252. The GOODBYE message 364 is acknowledged as received by the CM with a GOODBYE response message 366. Once the receipt of the

ES 2 343 563 T3 bye-bye reply message 366, CD 352 may close its UDP connection with user agent server 252. Before acknowledging receipt of the GOODBYE response message 366, the user agent server 252 removes the CD 352 from the list of active participants on the indicated network.

In general, a SIP user agent client on the CD 352 can use the OPTIONS procedure to query the capabilities of the SIP server. In particular, the CD 352 may wish to query an arbitrary SIP destination to determine whether or not the destination provides call signaling support.

The CD 352 may wish to abort a pending INVITE request 358 before receiving the response 360 ​​to the INVITE, and sending the acknowledgment 362. In such circumstances, the Cd 352 may use a SIP CANCEL procedure (not shown) to properly abort the call. Both the high-level SIP redirect server 236 and the CM SIP user agent server 252 support the CANCEL procedure.

For example, the CD 352 may use the CANCEL procedure to abort an INVITE 358 message in progress if the user decides to place a voice services call and presses the send key before the INVITE 358 message is completed. In such a circumstance, instead of waiting for the response 360 ​​to the INVITE to immediately complete and send the GOODBYE message 364, the CD 352 can simply immediately CANCEL the INVITE message 358 and proceed to make the requested voice services call.

After the CD 108 has successfully negotiated entry to the current membership of an NBS network, using SIP, all real-time call control takes place via point-to-point application level media signaling messages exchanged between each CD 352 and network MCU SIP server 252.

Media signaling messages are transported using the protocol stack illustrated in Fig. 4, and in accordance with the sequence illustrated in Fig. 12. Fig. 12 illustrates a sequence 368 of media signaling messages. A PTT request message 370 is sent by CD 352 to SIP user agent server 252 of MCU node 208, and indicates a user's desire to broadcast media, usually voice, to the network. Typically, the PTT request message 370 is sent for each press of the CD 352 push-to-talk button, to indicate a shift control request. In addition, a PTT release message is sent by CD 352 to SIP user agent server 252 to indicate normal release of the "turn" when the user releases the CD 352 push-to-talk button.

The PTT message comprises fields such as the opcode, identifier, origin, and a reserved field. The opcode field defines whether the PTT message is a shift control request or release message. The identifier field provides a unique message identifier to allow subsequent PTT and PTX release messages to reference a specific PTT request. The identifier should be unique within the recording session of a specific CD 352. The source field uniquely identifies the CD 352 that sends the PTT request 370 to the SIP user agent server 252. The reserved field reserves space in the PTT message 370 for future capabilities.

The CD 352 expects to receive at least one PTT response message 372 (PTX) for each PTT request 370 transmitted. If a PTX response 372 is not received within a predetermined time-out period, the CD 352 assumes that the PTT request 370 was lost en route and retransmits the PTT message 370 using the same PTT identifier.

If a PTX response message 372 is never received from the SIP user agent server 252 within a predetermined number of retransmissions, the CD 352 assumes that the SIP user agent server 252 is no longer accessible, it transitions to NBS idle mode and indicates an error condition to the user. In a preferred embodiment, CD 352 uses a different PTT identifier for request and release messages.

The PTX message 372 is sent by the SIP user agent server 252 to a CD 352 to acknowledge and respond to a previous PTT request 370, as well as to signal asynchronous shift control events. The SIP user agent server 252 uses the PTX 372 message to respond to a PTT turn control request or release. The PTX 372 message includes information such as whether the referral turn control request was granted or denied. In responding to a PTT turn control release 370, the PTX message 372 is used to indicate only acknowledgment. The SIP user agent server 252 may also use the PTX 372 message to asynchronously deny a previously granted shift control request (when a higher priority CD 352 issues a shift control request, the PTX lease expires (i.e. times out), or some other event occurs that requires that control of the network turn be revoked).

The PTX 372 message comprises fields such as the opcode, identifier, action, status, and expiration. The opcode field defines whether the PTX 372 message is a synchronous response for a pending PTT request, or whether it is an asynchronous message indicating a priority arbitration error or conflict. The identifier field refers to a previously received PTT request. The action field indicates whether the PTX 372 message is granting, denying, revoking or confirming control of the network turn. The status field provides additional information that explains the action of the PTX, in particular, in cases where the PTX 372 message denies, revokes, or cannot act on the previous PTT request. The Status field may indicate that a higher priority speaker has been granted control of the network, or that the CD 352 is not listed as a network participant and thus

Therefore, it is not allowed to forward media signaling requests to the network. The expire field represents the maximum duration, in whole seconds, for which control of the network shift is granted to the receiving CD 352. The SIP user agent server 252 starts its timer from the moment it sends the PTX message 372 from answer, not when CD 352 starts sending media traffic. The value of the expire field is a configurable network parameter.

The CD 352 does not explicitly acknowledge the response 372 to the PTX message. Instead, if the response 372 of the PTX message is lost, the CD 352's PTT retransmission timer expires and the CD 352 retransmits its PTT request 370. Since the retransmitted PTT 370 has the same identifier as the lost PTX response 372, the SIP user agent server 252 responds by resending the lost response 370 of the PTX message, rather than treating the request 372 for the retransmitted PTT message as a separate event. push-to-talk request.

A PTA message 374 is sent by the SIP user agent server 252 to each CD 352 currently participating in a network to announce the identity of the origin of pending media traffic. A PTA 374 message is also used to formally announce the end of a chat streak.

The PTA 374 message comprises fields such as an opcode, a speaker, and a reserved field. The opcode field indicates whether the PTA message 374 is announcing the grant (or release) of the turn to (or by) the CD 352 identified by the speaker field. The speaker field identifies CD 352, which generates media traffic to the network until the next PTA 374 message is sent. The reserved field reserves space in the PTA 374 message for future capabilities.

The CD 352 whose PTT shift control request 370 was successful may or may not receive a PTA 374 message announcing that it has shift control. The message may arrive before or after it receives the corresponding PTX 372 response, since UDP does not necessarily preserve the ordering of the datagrams. However, the SIP user agent server 252 sends the PTA advertisement 374 before it expects to start forwarding media (in the case of a grant PTA advertisement). It is recommended that the requesting CD 352 ignore received PTA 374 messages announcing that it has gained control of the turn, and rely only on the receipt of a response 374 from the grant PTX message to determine if it can begin streaming media to the network. .

A 404 "Are you there?" AYT (Fig. 13) is sent by SIP user agent server 252 to an individual CD 352 in order to confirm that the CD 352 in question is accessible using the IP. A collection of 404 AYT messages can also be sent to a group of network participants to signal that a network is no longer in sleep mode.

The 404 AYT message comprises fields such as the operation code, identifier, and reserved. The opcode field indicates whether the MCU node 208 is sending the 404 AYT message to determine if the CD 352 is still accessible, or whether the SIP user agent server 252 is using 404 Are You There? to pull associated CDMA cellular traffic channels out of the sleep mode network. The identifier field provides a unique message identifier to allow a subsequent IAH "I'm Here" response message 408 to refer to a specific AYT request message 404. The identifier may include a timestamp reference to generate latency estimates. The reserved field reserves space in the 404 AYT message for future capacities.

CD 352 may or may not be in sleep mode when sending a 404 AYT message. In all cases, CD 352 responds to a 404 Are You There? received with a 408 IAH reply message

The SIP user agent server 252 assumes that the CD 352 generally responds to a 404 AYT message with a 408 "I'm Here" response. If an IAH 408 response is not received within a reasonable time-out, the SIP user agent server 252 transmits a new AYT 404 message with a new identifier. If, after a configurable number of retransmissions, a response to message 404 AYT is not received from CD 352, it is assumed that CD 352 is inaccessible and the SIP user agent server 252 removes it from the current list of participants from the network.

Future media signaling messages from the retired CD 352 will be ignored (or will generate an error response) until the CD 352 successfully rejoins the network. The IAH message 404 is sent by the CD 352 to the SIP user agent server 252 to acknowledge receipt of a previously sent 404 AYT message. The 408 AYT message comprises fields such as the identifier, the source, and the reserved. The identifier field refers to a previously received AYT message 404, the receipt of which is acknowledged by the CD 352. The source field uniquely identifies the CD 352 that sends the response of the IAH message 408 to the SIP user agent server 252. The reserved field reserves space in the 408 AIH message for optional capabilities.

The SIP user agent server 252 assumes that the CD 352 acknowledges receipt of all received AYT messages 404, with a reply IAH message 408. If reference AYT message 404 was sent to confirm that a CD 352 remains connected in the NBS idle state, passively monitoring NBS media traffic and signaling, the SIP user agent server 252 notes the time of the 408 IAH message received for future reference.

ES 2 343 563 T3

Since the SIP user agent server 252 is responsible for defining the value of the identifier field, the SIP user agent server 252 can use the identifier to determine and track whether a specific CD 352 remains accessible.

The ZZZ, or sleeping message (illustrated in Fig. 13 as reference number 412), is sent by SIP user agent server 252 to CD 352 to stimulate CD 352 to release its over-the-air resources and enter to sleeping mode. The CD 352 may choose to ignore this message (especially if it is concurrently supporting other package applications).

The ZZZ message comprises fields such as identifier and reserved. The identifier field provides a unique message identifier to allow the CD 352 to distinguish between multiple receptions of the ZZZ message. The reserved field reserves space in the ZZZ message for optional or future capabilities.

The CD 352 does not acknowledge the ZZZ message. Error recovery is generally not attempted if the ZZZ message is lost. To prevent the loss of a ZZZ message, the SIP user agent server 252 may send multiple copies of the same ZZZ message to an individual CD 352. The SIP user agent server 252 ensures that copies of the same sleeping message are sent within a defined interval, and the CD 352 waits for a period longer than this interval, from the moment the first sleeping message is received. (with a new identifier), before releasing your link over the air and transitioning to a dormant state.

As illustrated in FIG. 15, an ASK message 382 is sent by CD 352 as an inquiry 384 to SIP user agent server 252 to confirm connectivity to SIP user agent server 252. ASK message 382 also allows CD 352 to determine if CD 352 remains registered as a network participant. The CD 352 may confirm its participation after a service disruption, or other period in which it may have temporarily lost connectivity with the SIP user agent server 252.

ASK message 382 comprises fields such as identifier, source, and reserved. The identifier field provides a unique non-null message identifier, to allow a subsequent "For Your Information" response message to refer to a specific ASK request message. The source field uniquely identifies the CD 352 that sends the request for the ASK 382 message to the SIP user agent server 252. The reserved field reserves space in the ASK 382 message for optional or future capabilities.

The CD 352 assumes that the SIP user agent server 252 responds to a received ASK message 382 with a response message 386 "For Your Information". If a response 386 "For Your Information" is not received within a predetermined expiration period, the CD 352 transmits a new ASK message 382 with a new identifier. If, after a configurable number of retransmissions, no response to the ASK 382 message is received from the SIP user agent server 252, it is assumed that the SIP user agent server 252 is unreachable and the CD 352 transitions to the idle state of group services.

The FYI message 386 is sent by the SIP user agent server 252 to the CD 352 to acknowledge receipt of a previously sent ASK message 382, ​​or it is sent asynchronously by the SIP user agent server 252 to inform the CD 352 of a exceptional condition.

The 386 FYI message comprises fields such as operation code, action, status, identifier, and reserved. The opcode field defines whether the 386 FYI message is a synchronous response to a pending ASK 382 request, or whether it is an asynchronous message indicating an exceptional condition. The action field indicates whether the FYI message 386 is confirming participation in the network, informing the CD 352 that it has been administratively deleted from the list of network members, or performing some other function to be defined. The status field provides additional information to explain the 386 FYI message in particular, in cases where the 386 FYI message indicates that the CD 352 is not a participant or member of the network. The identifier field refers to a previously received ASK 382 message, which the CD 352 is acknowledging. The value of the identifier field is undefined for FYI asynchronous responses. The reserved field reserves space in the 408 "I'm Here" message for optional or future capabilities.

The CD 352 generally does not acknowledge receipt of responses to the 386 "For Your Information" message. If a response to the message 386 "For Your Information" is lost, the CD 352 sends a new request for the message QUESTION 382. Because the CD 352 does not request responses from the asynchronous message 386 FYI in a preferred embodiment, the server 252 SIP user makes at least three staggered transmissions of any 386 FYI response.

A participating CD 352 signals a user's desire to broadcast media to the network by issuing a request 376 for a PTT message to the SIP user agent server 252. The SIP user agent server 252 responds to the PTT request 376 with a response 378 of the PTX message, which can either grant or deny the request. If the request is granted, a PTA announcement message 380 is broadcast to all network participants. The user interface of the requesting CD 352 may indicate to the user that permission to speak to the network has been granted as soon as the response 378 of the grant PTX message is received. The CD 352 typically broadcasts media traffic until the user releases the PTT button, at which point it signals the end of the talk streak by broadcasting a message 376

ES 2 343 563 T3 release PTT to SIP user agent server 252. The SIP user agent server 252 responds with a PTX acknowledgment message 378 and broadcasts an announcement indicating the end of the talk streak to all network participants.

When any DC 352 has the turn (the right to speak) of a network, the network is said to be active; otherwise, it is inactive. If a network is idle for a time that exceeds the network timeout, the SIP user agent server 252 can put the network into sleep mode, individually signaling to all registered mobile stations to release their traffic channels. by air. A connection is maintained to allow a request for shift control, or other traffic, to bring the network out of sleep mode relatively quickly. Members of the network can ignore "Go to sleep" messages. The SIP user agent server 252 does not explicitly or implicitly track the idle status of individual members of the network.

As illustrated in FIG. 15, the SIP user agent server 252 will "wake up" a network and bring it out of sleep mode 618 when a successful shift control request 704 is received during idle. As soon as the turn control request 704 has been granted, the SIP user agent server 252 will signal each registered CD 352 requesting message 716 (AYT) over the media signaling channel, and start an internal wake-up timer 724 . Each CD 352 acknowledges the 716 AYT message to the SIP user agent server 252 if it wishes to remain registered on the network. Optionally, a sleeper CD 352 may temporarily store media traffic 740 from the time the user presses the PTT button until the CD 352's traffic channel is (re) connected. The SIP user agent server 252 may temporarily store the media traffic 740 received from the CD 352 on duty, until the wake-up timer 724 exceeds the wake-up timeout, at which point it begins to forward media traffic to every CD 352 registered, including any member who has not yet responded to the 716 Are You There? A) Yes, both the CD 352 and the MCU node 208 have the ability to temporarily store data until the recipient is ready to receive the temporarily stored information. In one embodiment, portions of data are stored on both the CD 352 and the MCU node 208.

The SIP user agent server 252 periodically relays AYT requests 716 to any registered CD 352 that has not acknowledged receipt of the AYT request 716. Once the wake-up timer 724 has passed a second, longer, lazy timeout, the SIP user agent server 252 will unregister any member CDs 352 whose Are You There? pending, and will stop the wake-up timer 724. SIP user agent server 252 ignores requests Are You There? duplicates.

If the CD 352 tries to join a network that is currently dormant, the SIP user agent server 252 processes the request normally and then signals the CD 352 to go to the dormant state. The signaled CD 352 may ignore the command to go to sleep.

During periods of extended network inactivity, the NBS supports a packet data service call being made in the sleep / idle state 528 (see FIG. 11). The SIP user agent server 252 facilitates transitions to and from the sleeping / idle state 528, independently managing a similar concept of inactivity for each NBS network 100.

FIG. 13 illustrates the sequence of media signaling messages regarding idle 400, between the CD 352 and the SIP user agent server 252. In general, a message is sent to all CDs in the network to go to sleep, based on a control signal sent from the CM, based on a timer on each CD. Thus, the resources allocated to the network are released and can be used by other users. With a configurable schedule, the SIP user agent server 252 sends a request for the message (AYT) 404 to each CD 352, in order to confirm that the CD 352 in an idle state remains accessible. Thus, the CM 104 maintains a central polling of current network users and their status. This also allows individual CDs to dynamically join or leave the network. CD 352 responds to AYT request 404 with a response to message (AYT) 408. 404 AYT messages are not necessarily broadcast to each CD 352 at the same time. The SIP user agent server 252 may stagger the sending of AYT messages 404 to each network participant, in order to avoid receiving a deluge of simultaneous IAH message responses 408.

After the network has been idle long enough for the configurable network timeout to expire, the SIP user agent server 252 broadcasts a ZZZ request message 412 to each network participant. In response, each CD 352 can release its link resources over the air and enter sleep mode. Network participants do not necessarily have to respond to the ZZZ request message 412.

A successful PTT request 416 by CD 352 brings the network out of sleep mode. In one embodiment, a predetermined threshold number of users is required to respond in order to bring the network out of inactivity. Before granting the request with a PTX message 420, the SIP user agent server 252 sends each CD 352 a request 424 for the message Are You There ?, to force each previously participating CD 352 out of idle. This is done if the CD 352 chose to release its link resources over the air in response to the ZZZ message 412, and to confirm that the participating CD 352 still remains accessible. In another embodiment, after a configurable, but fixed delay, defined as the PTX idle response timer, the SIP user agent server 252 transmits the PTX grant message response 420 to the requesting CD 352. After a second wake-up timer expires (typically no less than the response timer)

ES 2 343 563 T3 of inactivity of the PTX), the server 252 SIP user agent announces the speaker, by means of a message 428 PTA to all the participants of the network, and can begin to send media.

The MCU node 208 is responsible for receiving incoming data packets from the transmitting CD 352, and for sending duplicate copies of the received data packets to other members of the network to which the transmitting CD 352 belongs. As each data packet is received by MCU node 208, it is stored in a memory (not shown). The transmitting CD 352 can be identified by interrogating the data packet. In one embodiment, an IP address, representing the transmitting CD, is included in each data packet as a way of effecting identification.

After the transmitting CD 352 is identified, the MCU node manager 256 retrieves a list of network members, belonging to the network associated with the specific MCU node 208, from local memory (each MCU is usually assigned only to a network). A destination address is associated with each active member of the network, that is, the members of the network that are currently registered at the MCU node 208, in local memory. In one embodiment, the destination address is an IP address. The MCU node manager 256 then creates a duplicate of the original data packet, except that the destination address identified within the data packet is modified to reflect the destination address of the first network member. Next, MCU 208 creates a second duplicate data packet, addressed to the second member of the network. This process continues until the original data packet has been duplicated and sent to all active members of the network identified in local memory. During playback of any buffered media, the CM 104 treats the network as active, even if the speaker CD 352 has released the turn. Thus, the CM 104 does not allow a CD 352 to interrupt playback of temporarily stored media, unless the interrupting CD 352 has higher priority than the source of the temporarily stored media.

Note that the SIP user agent server 252 may receive IAH message responses 432 during an extended interval, after the network is brought out of sleep mode, and that the SIP user agent server 252 does not wait for all participants respond before granting the pending 416 PTT request. Late responders, whose IAH response 432 arrives after the PTX grant message response 420 is transmitted, remain registered as network participants, but may not receive all initial media traffic and signaling. Any CD 352 that does not respond to the 424 AYT request after a third higher (and configurable) delay is assumed to be no longer accessible, and is removed from the list of active network participants.

FIG. 14 illustrates a sequence of NBS media signaling messages 440, showing a higher priority CD 444 interrupting a lower priority CD 442 with network turn control.

Initially, a lower priority CD 442 forwards a request 446 for a PTT message to the SIP user agent server 252, which is granted by the SIP user agent server 252. The SIP user agent server 252 announces that the CD 442 has control of the network shift.

While the lower priority CD 442 is transmitting the media 443, a second CD 444 attempts to interrupt by sending the SIP user agent server 252 a PTT message request 448 for the same network. The SIP user agent server 252 determines that the second CD 444 has higher priority than the talker CD 442, and immediately revokes control of the network turn from the talker CD 442, sending it an asynchronous PTX deny message 450. The SIP user agent server 252 then grants the PTT request 448 to the higher priority CD 444, with a normal response 452 of the PTX grant message, and announces that the higher priority CD 444 has control of the network shift. .

If the SIP user agent server 252 determines that the interrupting CD 444 has no higher priority, the SIP user agent server 252 immediately rejects the PTT request 448 with a response 452 of the PTX message, and continues to distribute the media 456 from the speaker CD to network participants, without interruption.

Although the priority assigned to a specific CD is a fixed value defined in the database maintained by the SIP user agent server 252, the SIP user agent server 252 may use other arbitration algorithms that do not necessarily always grant the turn. to the highest priority requesting participant, as illustrated here. The PTT arbitration algorithm used to arbitrate conflicts can be configured individually for each network.

At a minimum, the SIP user agent server 252 supports an arbitration policy that allows a CD to interrupt the current speaker only if the CD has a priority level that exceeds that of the current speaker. A low-priority CD can listen to media traffic, but never gain control of the network's turn.

Figs. 15 and 16 illustrate the operation of the CM 104 and CD 352, respectively, during various states. CM 104 maintains an idle timer for each network, or timeout timer 620. When the idle timer 620 reaches a configurable prescribed value, the timer triggers CM 104 to put the network into a dormant state 618, broadcasting a media signaling message 696 to all network participants. Upon receiving the message, a participating CD 352 can release its traffic channel and enter a

ES 2 343 563 T3 sleeping / idle state 844, or the CD 352 may ignore the message and remain in a connected state 820. In particular, network participants that are not operating over a channel, such as dial-up PSTN users, should ignore media signaling messages.

The network timeout timer 620 does not advance during the time that a response 632 of the PTX grant message is in effect. Timer 620 is reset to zero when PTX grant message 632 is transmitted, and remains zero until PTX grant 632 expires or CD 352 clears network turn 872. Once the turn is released, the timeout timer advances until the next response 632 of the PTX grant message is transmitted.

If a participating CD 352 enters sleep / idle state 844, it remains dormant, either until all packet data addressed to CD 352 reaches the cellular infrastructure of the CD 352 Master Manager, or until CD 352 generates data for send, using the packet data service. The first case can be triggered by traffic sent to CD 352 by CM 104 (908). The second case can be activated by the user, pressing the PTT button to request broadcast permission to the network. Other non-NBS related activators are also possible.

The network itself remains dormant until one or more participants activate the transmission of a PTT request 704. If the CM 104 determines that it can grant the PTT request message 704 (including performing any necessary arbitration to handle the multiple requests), it sends a request 716 to each registered participant of the network, to trigger a transition out of state 844 sleeper / idle. For any specific CD 352, activation may or may not be necessary, but each CD 352 nonetheless responds to the request. In this circumstance, when a network is transitioning out of the dormant state 618, the CM 104 is inhibited from sending the initial PTX grant response message 756, until a fixed but configurable delay expires, the inactivity response timer 728 by PTX. After timer 728, the default value of which is usually zero, expires, CM 104 sends grant 756 PTX as usual. However, CM 104 continues to inhibit itself from forwarding media to the network until a second associated timer, network wake-up timer 724, expires. Both timers are reset when the CM 104 determines that the sleeper net's turn can be granted. The value of the wake-up timer 724 should not be less than the value of the PTX wake-up response timer 728. After the wake-up timer 724 has expired, the CM 104 begins to forward media, and media traffic and signaling, normally. Both timers are configurable for each network.

If the CM 104 determines that it cannot grant the PTT request 704, it immediately signals the requesting CD 352, accordingly, with a PTX denial message 708, and the network remains dormant.

A CD 352 that has entered the 844 Sleeper / Idle state may require a system change, change service options, or experience some other service disturbance that causes it to never receive or respond to the AYT 908 “wake up” message. The CM 104 maintains a third, longer timer, which is also reset with the wake-up and wake-up response timers PTX. This longer lazy timer (not shown) is also configurable for each network. After the lingering timer expires, any CD 352 whose 916 IAH response to AYT wake-up message 908 has not been received is removed from the list of active network participants by CM 104. Any such withdrawn CD 352 is to be returned. to register with the SIP server 236 of the CM 104 in order to become a participant in the network again.

Due to the potential delays associated with transitioning a CD 352 from the 844 Sleeping / Idle state to the connected state, both the CD 352 and CM 104 can perform voice buffering to mitigate perceived transition delay. by the user.

Typically, the user interface of the CD 352 signals to the user, by visual or auditory mechanisms, at least two milestones in the processing of a push of the PTT key. First, the CD 352 signals that it has detected a PTT key press. Later, the CD 352 signals that it has received the response 868 of the PTX message from the CM 104. If the 868 response of the PTX message grants permission to broadcast media, the user interface of the CD 352 provides an indication that the user can begin speaking to the network; otherwise, the user interface of the CD 352 indicates that the user has been denied permission (856) to speak to the network.

When the network is not asleep, the latency between the transmission of the PTT request message and the receipt of the corresponding PTX response message is relatively small, and the user becomes accustomed to being granted permission to speak shortly after it is pressed. the PTT button. However, when the network is dormant, a relatively significant delay can separate the transmission of the PTT request 852 and the receipt of the corresponding 856 or 868 PTX message. The delay may occur because the CD 352 may have released its traffic channel and experiences a delay in re-establishing packet data service. The delay can also occur because the CM 104 waits until the network wake-up timer has expired before sending the 856 or 868 response of the PTX message. In this circumstance, CD 352 may hopefully assume that CM 104 eventually responds with a PTX grant response 868 and signals to the user that a PTT request 876 has been granted. To allow the user to start speaking "early", the CD 352 temporarily stores the voice internally, either until the PTX request arrives, or until it consumes all available internal temporary storage space.

ES 2 343 563 T3

If the response of the PTX message arrives and the request is granted, the CD 352 can begin transmitting the voice (temporarily stored) and operation continues normally. If the response of the PTX message arrives and the request is denied, the CD 352 signals to the user that permission to speak to the network has been denied. Since the user has already started speaking, this late denial may seem like a conflict of priorities. Special care is taken, in this circumstance, to avoid unnecessarily confusing the user. The CM 104 signals the PTX denial message 856 as soon as possible, to limit the length of time the user can speak under the assumption that the pending PTT request will eventually be granted.

If the PTX message does not arrive before all available internal buffer space is consumed, the CD 352 can simulate a PTX deny message 856 and signal the user to stop talking (856). If the CD 352 has not been able to restore service, it may also need to take other action in error at this point, and inform the user accordingly. Alternatively, if packet data service is restored at this time, CD 352 may, in this situation, begin transmitting voice media to CM 104 without prior receipt of a response 868 of the PTX grant message.

While waiting for the wake-up timer to expire, the CM 104 temporarily stores any voice media received over the media channels of a network from the CD 352 that has sent the pending PTT request 852 and, eventually, sends a corresponding grant response 868 PTX. After the wake-up timer expires, the CM 104 transmits the PTX grant response 868 to the requesting CD 352, broadcasts a PTA announcement to the network, and begins broadcasting the temporarily stored voice media. If the CM 104's internal voice buffer is consumed before the wake-up timer expires, the CM 104 immediately transmits a PTX denial message 856 to the requesting CD 352. The processing of the buffered speech is undefined, but the CM 104 may transmit the contents of its speech buffer to the network after the wake-up timer has expired. Once the wake-up timer has expired, network operation proceeds normally.

The size of the voice media buffer on the CD 352 is chosen based on the maximum expected time to transition to the 812 Connected state of the IS-707.5 standard, from the 844 sleep / idle state of the IS-707.5 standard. Similarly, the size of the media buffer in the CM 104 should be chosen based on the (maximum) value of the network wake-up timer specified in the network database 232 of the CM 104.

A more complete description of the states of CM 104 follows. CM 104 implements the NBS Media Signaling state diagram 600 shown in FIG. 15 for each instance of a network. The CM 104 initializes to an idle state 604 when a network is created. The network remains in the idle state 604 as long as no PTT request 608 from network participants is granted for shift control 612, and the network is not dormant 618. CM 104 resets timeout timer 620 upon entering idle state 604. CM 104 transitions from idle state 604 to grant state 612 when a PTT request 608 is received from a network participant. The CM 104 transitions from idle state 604 to transitional sleep state 624 when the time-out timer expires.

CM 104 transitions from grant state 612 to idle state 604, and sends a deny PTX response 626 to requesting CD 352, if the arbitration algorithm denies turn control to requesting CD 352. CM 104 transitions from grant state 612 to announcement state 628, and sends a PTX grant response 632 to requesting CD 352, if arbitration grants turn control to requesting (or interrupting) CD 352. After sending the PTX grant response 632, the CM 104 considers the requesting (or interrupting) CD 352 as the current speaker on the network. CM 104 transitions from announcement state 628 to talk state 636, and sends a PTA message 640, announcing the new speaker to all network participants, immediately upon entering announcement state 628. The current speaker remains in the chat state 636 as long as no PTT request 644, or release message 648 is received from a network participant, and the network failsafe timer 652 has not expired. The CM 104 resets the network failsafe timer 652 upon entering the talk state 636. While in the talk state 636, the CM 104 broadcasts media from the current speaker on the network to the network.

The CM 104 transitions from the talk state 636 to the arbitration state 656 when the PTT request message 644 is received from a network participant. The CM 104 transitions from the talk state 636 to the release confirmation state 660 when the PTT release message 648 is received from the CD 352 with network turn control. The CM 104 transitions from the talk state 636 to the failsafe recovery state 664 when the failsafe timer 652 expires. Typically, the user is given the amount of time remaining before the failsafe timer expires. The CM 104 broadcasts the media traffic, received from the current speaker on the network, to the network as long as it remains in the talk state 636. If the network media buffer is not empty, the CM 104 continues to buffer the media received from the current network speaker, while broadcasting media traffic to the network.

The CM 104 enters the arbitration state 656 as a result of receiving the PTT request message 644 while in the talk state 636. The CD 352 that originated the PTT request message 644 is known as the interrupting party. If the interrupting party and the current speaker are identical, the CM 104's PTX grant message 668 has been lost, and the current speaker is resending their PTT request 644. CM 104

ES 2 343 563 T3 transitions from the arbitration state 656 to the talk state 636 and sends the interrupting party the PTX grant message 668 if the interrupting party and the current network speaker are identical. The CM 104 applies the arbitration algorithm to the current speaker on the network and the interrupting participant immediately upon entering the arbitration state 656, if the interrupting participant and the current speaker on the network are different.

The CM 104 transitions from the arbitration state 656 to the talk state 636, and sends the interrupting party a PTX denial message 672, if the arbitration algorithm pronounces in favor of the current speaker. The CM 104 transitions from the arbitration state 656 to the grant state 612, and sends the current network speaker a PTX interrupt message 676, if the arbitration algorithm pronounces in favor of the interrupting party. The CM 104 transitions from the release confirmation state 660 to the release announcement state 680, and sends a PTX confirmation message 684 to the current speaker immediately upon entering the release announcement state 680.

The CM 104 transitions from the failsafe state 664 to the release announcement state 680, and sends a PTX denial message 688 to the current speaker immediately upon entering the failsafe state 664. CM 104 transitions from release announcement state 680 to idle state 604, and sends a PTA release announcement 692 to all network participants immediately upon entering release announcement state 680. The CM 104 transitions from sleep state 624 to dormant state 618, and sends a 696 ZZZ message, announcing that the network has entered the dormant state, to all network participants immediately upon entering state 624 from passage to sleeper. The network state machine remains in sleep state 618 as long as no network participant requests turn control. CM 104 transitions from sleep state 618 to wake-up state 706 when a PTT request 704 is received from a network participant.

CM 104 transitions from wake-up state 706 to sleep state 618, and sends a PTX deny response 708 to requesting CD 352, if the arbitration algorithm denies turn control to requesting CD 352. Since the network is dormant, this can occur only if the requesting CD 352 has listen-only privileges. CM 104 transitions from wakeup state 706 to wakeup pending state 712, and sends AYT wakeup request 716 to all network participants, if arbitration grants turn control to requesting CD 352. After sending the AYT wake-up request 716, the CM 104 considers the requesting CD 352 as the pending speaker from the network.

The CM 104 remains in the wake-up pending state 712 as long as no PTT request message 720 is received from a network participant, a wake-up timer 724 has not expired, and the PTX inactivity response timer 728 has not expired. The CM 104 resets the wake-up timer 724 and the PTX inactivity response timer 728 upon entering the wake-up pending state 712. The CM 104 transitions from the wake-up pending state 712 to the dormant-arbitrate state 732 when the PTT request message 720 is received from a CD 352 other than the pending network speaker. The CM 104 transitions from the wake-up pending state 712 to a dormant-grant state 736 when the network wake-up timer 724 expires. The CM 104 transitions from the wake-up pending state 712 to a buffer-grant state 740 when the PTX inactivity response timer 728 expires.

The CM 104 applies the arbitration algorithm to the pending network speaker and to the participant that immediately interrupts upon entering the sleeper-arbitration state 732. The CM 104 transitions from the arbitration sleeping state 732 to the awakening pending state 712, and sends the interrupting participant a PTX denial message 744, if the arbitration algorithm rules in favor of the pending speaker. The CM 104 transitions from the sleeper-arbitration state 732 to the wake-up pending state 712, and sends the interrupting party a PTX deny message 744 if the arbitration algorithm rules in favor of the pending speaker. The CM 104 transitions from the sleeper-arbitration state 732 to the wake-up pending state 712, sends the PTX deny message 744 to the pending speaker, and considers the interrupting party to be the new pending speaker from the network, if the arbitration rules in favor of the interrupting participant.

The CM 104 transitions from the dormant-grant state 736 to the announcement state 628, and sends a PTX grant response 748 to the network pending speaker immediately upon entering the dormant-grant state 736. The CM 104 transitions from the buffer-grant state 740 to a buffer state 752, and sends a PTX grant response 756 to the network pending speaker immediately upon entering the buffer-grant state 740. The network state machine remains in the buffer state 752 as long as the wake-up timer 724 has not expired. While in buffer state 752, CM 104 buffers all media traffic received from the speaker pending from the network.

The CM 104 transitions from the buffer state 752 to the advertisement state 628 when the wake-up timer 724 expires. CM 104 temporarily stores all media traffic received from the network pending speaker in the network media buffer while it remains in buffer state 752. The CM 104 responds to any media signaling request that contains invalid or reserved field values ​​by sending an ERR response 760, in an error state 764, to the CD 352 that sent the message, and ignores the request in any case.

ES 2 343 563 T3

The CD 352 implements the NBS Media Signaling state diagram 800, shown in FIG. 16, whenever a user is participating in a network. CD 352 initializes into a boot state 804 after CD 352 accepts the session description from the network, sending a SIP acknowledgment ACK message 808 to CM 104. The CD 352 transitions from the start-up state 804 to a start-up wait state 812, and sends a QUESTION request message 816 to the CM 104, immediately upon entering the start-up state 812.

The CD 352 remains in a listening state 820 as long as the user does not press the push-to-talk 824 button, no 828 PTA messages are received from the CM 104, and no idle 832 ZZZ messages are received from the CM 104. The CD 352 transitions from the listening state 820 to a turn request state 836 when the user presses the push-to-talk button 824. CD 352 transitions from listening state 820 to speaker announcement state 840 when PTA message 828 is received from CM 104. CD 352 transitions from listening state 820 to sleeping state 844. idle when Idle message 832 ZZZ is received from CM 104. CD 352 transitions from turn request state 836 to turn wait state 848, and sends a PTT grant request 852 to CM 104 immediately upon entering turn request state 836.

CD 352 remains in the wait-for-turn state 848 as long as no PTX response message 856 is received from CM 104, and a PTT Abort timer 860 has not expired. The CD 352 resets its PTT Abort Timer 860 and a PTT Retransmission Timer (not shown) upon entering the standby 848 state. The CD 352 transitions from the wait-for-turn state 848 to a talk state 864, and alerts the user that the user has gained control of the turn from the network, when a grant response message is received. 868 PTX from CM 104. CD 352 transitions from turn wait state 848 to turn lost state 872 when PTX deny message 856 is received from CM 104. The CD 352 remains in the standby state 848, and relays an identical PTT request 876 to the CM 104 after its PTT Retransmission Timer expires. The CD 352 transmits from the wait-for-turn state 848 to the listening state 820 after its PTT Abort Timer expires. The CD 352 transitions from the talk state 864 to a turn release state 880 if the user releases the push-to-talk button 884 while still waiting for a PTX response.

The CD 352 remains in the talk state 864 as long as no PTX interrupt message 888 is received from the CM 104, and the user has not released the push-to-talk button 884. The CD 352 transitions from the talk state 864 to the lost turn state 872 when the PTX interrupt response message 888 is received from the CM 104. The CD 352 transitions from the talk state 864 to the turn release state 880 when the user releases the push-to-talk button. CD 352 remains in the talk state 864 when the PTX grant response message 868 is received from CM 104. The CD 352 transitions from the lost turn state 872 to the listening state 820, and alerts user 892 with a message indicating that control of the network turn has been lost, immediately upon entering the lost turn state 872 .

The CD 352 transitions from the turn release state 880 to a release awaiting state 896, and sends a PTT release request 900 to CM 104, immediately upon entering the turn request state 836. The CD 352 remains in the release wait state 896 as long as no PTX confirmation response message 904 is received from the CM 104, and the PTT Abort Timer 860 has not expired. The CD 352 resets its PTT Abort Timer 860 and a PTT retransmission timer upon entering the release wait state 896. The PTT retransmission timer is activated each time there is a PTT request or release.

CD 352 transitions from awaiting release state 896 to listening state 820 when the PTX confirm response message 904 is received from CM 104. CD 352 remains in awaiting release state 896, and retransmits an identical PTT release request 900 to CM 104, after its PTT Relay Timer expires. CD 352 transitions from awaiting release state 896 to listening state 820 after the PTT Abort Timer expires 860.

The CD 352 transitions from the speaker announcement state 840 to the listening state 820, and announces the speaker, immediately upon entering the speaker announcement state 840. The announcement may indicate that a new speaker has control of the turn, that the current speaker has released the turn, or that no speaker currently has control of the turn.

The CD 352 remains in the sleep-idle state 844 as long as no AYT request message 908 is received from the CM 104, and the user does not press the push-to-talk key 824. The CD 352 transitions from the sleeping-idle state 844 to the sleeping-awake state 912 when the AYT request message 908 is received from the CM 104. The CD 352 transitions from the sleep-idle state 844 to the turn request state 836 when the user presses the push-to-talk key 824.

The CD 352 discards any received idle ZZZ messages 916 while in the sleep-idle state 844. The CD 352 transitions from the sleeping-awake state 912 to the listening state 820, and sends an IAH response message 916 to the CM 104, immediately upon entering the sleeping-awake state.

ES 2 343 563 T3

Upon receipt of a Ping AYT request 920, received from CM 104 while in any state other than sleep-idle state 844, CD 352 saves its current state, temporarily transitions to response state 924 IAH builds and sends an IAH response message 928 to CM 104, and it returns to its previous state. CM 104 sends a 932 ERR response to CD 352 when it receives a media signaling error, and enters error state 936, such as in the case of a malformed request that makes use of invalid or reserved field values.

Upon receiving the 932 ERR response, received from the CM 104 while in any state, the CD 352 alerts the user that an error has occurred, disables the CD 352 (940), and performs all appropriate SIP signaling to orderly terminate their participation. on the net (944).

When the CD 352 has entered one of the dormant states (844), the CD 352 can receive calls from point-to-point voice services, using another service option of the IS-707 standard, but still remain a participant in a network. sleeping. After the voice services call is terminated, the CD 352 returns to the 844 sleep / idle state of the IS-707.5.

However, if the network exits the sleep state 844 while the CD 352 has chosen to receive a call from the point-to-point voice services option, the CD 352 may lose request 908 for the AYT “wake up” message, and be withdrawn. from the list of active participants. In such circumstances, the CD 352 may determine its participant status by sending the CM 104 a 382 QUESTION request. Once the CD 352 has been removed from the list of active participants in the network, the CD 352 re-registers with the SIP server of the CM 104, in order to participate in the network again.

The CD 352 allows the user to originate and receive conventional point-to-point calls from the PSTN, as well as participate in group service discussions. Although the CD 352 can operate internally in one of several modes, the CD 352 avoids restricting certain functionality within the context of different modes of operation, which the user is required to navigate explicitly. From here, the seamless reception and realization of point-to-point voice service calls while group services are enabled and activated.

The CD 352 can be used to make point-to-point voice service calls, or point-to-point secure packet voice calls, at any time, whether group services are active or not, as long as the CD 352 is not simultaneously acting as a speaker. If CD 352 has registered as a member of a network, CD 352 unregisters from the network. If the selected point-to-point call is made using a voice service option, the CD 352 terminates data services. Once the point-to-point call is complete, the CD 352 can transparently enable packet data service and re-register as a member of the current selected network.

The CD 352 can be used to receive secure point-to-point, or PSTN packet voice calls, while group services are enabled, within the limitations imposed by the cellular infrastructure. If the CD 352 has joined a network, and the selected network is active, the CD 352 appears busy for an incoming PSTN call, and the call is given the proper busy phone treatment by the cellular infrastructure . If the selected network is idle, but the network timeout 620 has not expired, the call is also given normal busy phone treatment by the cellular infrastructure. However, if the selected network timeout 620 has expired, the network has been put into sleep mode 618, and the CD 352 has released its link resources over the air, the call cannot be given call handling. telephone busy by the infrastructure, and the CD 352 can be paged to initiate reception of the incoming call.

While a voice services call is active, the CD 352 is unable to receive any network traffic from the NBS. After a voice services call has been completed, the CD 352 may be required to rejoin the network, as it may have missed one or more 716 requests Are You There? Anytime the CD 352 appears busy for an incoming voice services call, the caller is redirected based on whatever busy phone treatment has been defined for the called CD 352 (such as call forwarding, voicemail , etc.) by the cellular infrastructure, as expected. A user can optionally configure the CD 352 to disable the reception of incoming point-to-point calls, while a network is selected and the CD 352 registers as a member.

The CD 352 also detects if your IP network address has changed or is about to change. If the CD 352 is participating in a network when the address change occurs, the CD 352 again sends an INVITE message to the network, as discussed with respect to Fig. 11.

For example, a roaming CD 352 can switch between cellular systems or cellular networks and thus negotiate a new IP address. Either the CD 352 may experience a service disruption, or drop the packet data service option call for any reason and, upon restoration of service, be assigned a new IP network address. If CD 352 is participating in a network during an address change, and does not rejoin the selected network in a timely manner, CM 104 eventually expires its membership and removes CD 352 from the list for the selected network. The CD 352 is removed from the list of active network participants if it does not eventually respond to a series of media signaling AYT request messages 716.

ES 2 343 563 T3

In the absence of the Packet Data Service Option of the IS-707.5 standard, the NBS can work with the existing and usually available Quick Network Connect (QNC) packet service. However, the QNC does not currently support idle. Consequently, application level messages such as "go to sleep" can be ignored by a CD 352 employing the NBS by the QNC.

The QNC provides a protocol stack similar to that provided by the IS-707.5 standard. The CD 352 can be configured to negotiate a packet connection using QNC instead of IS-707.5 and, if QNC service is available, treats the connection as a non-idle packet data service option connection or optionally no CRTP header compression support.

Under Mobile IP, the CD 352 connects to the network using a third-party agent, which assigns the mobile a "Attention of" address. The "Attention of" address is a temporary, but legal, address to which IP datagrams can be directed from anywhere on the Internet. The mobile uses the "Attention of" address to contact your domestic agent and inform them of the current "Attention of" address of the mobile. After confirming the identity of the mobile, the home agent then sends the packets addressed to the mobile's permanent home address (which normal Internet routing mechanisms deliver directly to the home agent, or to the home agent's network), to the mobile. address "Attention of" of the mobile.

Although NBS can work with Mobile IP, Mobile IP can potentially adversely affect end-to-end latency, and the perceived voice quality of NBS media traffic and signaling. This can be especially significant if the CD 352 joins a network that uses its permanent address and the home agent is located far away, in a network topological sense, from the CM 104 and CD 352. In this case, the media traffic can be routed, optionally, through the public Internet, or through other networks of variable quality of service, which may not have been required if the Mobile IP has not been used. To avoid this, it is preferable that the CD 352 accesses the services of the NBS using its address to the attention of and that it rejoins the networks when it changes its address to the attention of.

Both SIP call signaling and PGP public key encryption use a unique user identifier, a similar unique identifier, from the CD 352. The user database 232 defines an internal user identifier, which can be referred to, and be used by, CD 352 in media signaling requests. The CD 352 user identifier address preferably does not contain any private data whose public disclosure could compromise the authentication mechanisms of the existing cellular infrastructure.

The CD 352 user address is used in the headers in SIP registration and invitation, and can be used to form other parts of the required SIP syntax. The user address is also an input for the generation of the private PGP key used to authenticate SIP requests. The user interface of the CD 352 allows the user to view the user address. The user interface of the CD 352 may allow the user to change the user address, at the risk of potentially disrupting the ability to access the NBS or satisfy SIP authentication requests.

To guard against certain denial-of-service attacks, and bypass CD 352 imposters, CM 104 may optionally request that CD 352 authenticate itself before registering or joining a network. Authorization takes place at the application level, independent of other authorization schemes that may exist at the network or cellular infrastructure level. CD 352 authorization is also implemented, and works, regardless of the concepts and data structures that support NBS encrypted (secure) networks.

In particular, CM 104 may request that CD 352 include an "Authorization" header with its SIP requests. The authorization header supports the SIP message to be signed by the CD 352 using PGP public key cryptography signatures.

Public key cryptography generates a public and private key from a private secret key, usually known only to the encryptor (in this case, the CD 352). The private key, in combination with the secret key, is required to sign a message, but the public key alone can be used to verify the signature of a signed message. Thus, to support the authorization of the SIP; each CD 352 is preferably provided with a private key and a secret key, which are never shared. Each CM 104, to which the CD 352 may need to be authorized, should know the public key of the CD 352. Since the public key is not secret, it can be stored as part of the user portion of the database 232 maintained by the CM 104, or accessed through generic public key servers on the Internet.

The CM 104 may require authorization from the CD 352 at the server, network, or user level. At the server level, CM 104 requires all clients connecting to CM 104 SIP server 236 (see FIG. 3) to provide authorization credentials, rejecting all requests that are not authorized. When authorization is enabled at the server level, only clients whose identities (ie, a client's public key) are previously known to CM 104 can actually use the server. Server-level authorization can protect CM 104 SIP server 236 from many relatively simple denial-of-service attacks.

ES 2 343 563 T3

A CM 104 can protect one or more networks that it manages by authorization, but leave other networks "unprotected." If the CD 352 tries to join a network protected with INVITE messages, the SIP server 236 of the CM 104 rejects the request, unless the CD 352 can be authorized by the CM 104.

In addition, the CM 104 can use authorization to ensure that the CD 352 (or any SIP user agent client, in general) does not attempt to pretend to be another CD 352 and thereby deny service to legitimate network participants or monitor passively the media channels of a network. If the CM 104 requires a specific CD 352 to be authorized, the CM 104 does not accept any SIP requests from a connecting client like the CD 352, unless the client's SIP requests include a PGP signature that can be verified by CM 104. At the user level, authentication can be configured for each user (ie, CM 104 may require certain users to be authenticated first, while allowing other users to remain unauthenticated).

The PGP private key can be administratively registered within, or created by, the CD 352, once the user address of the CD 352 is defined. The private key does not need to be stored externally, but the associated public key is generally Loadable in the user portion of the database 232 of any SIP server that requires CD 352 authentication.

In one embodiment, the primary NBS CD 352, or the network participant platform, is a cellular handset based on the CD 352 Master Manager. Because the NBS is built on top of IP and IP transport protocols, any IP capable platform, with connectivity to CM 104, can potentially serve as a NBS CD 352. Consequently, users by telephone connection can connect with the CM 104 through the PSTN, through existing IP terminal servers, managed by Internet Service Providers (ISP), as illustrated in Fig. 1. The server -terminal acts as a bridge between the PSTN and a local area LAN that supports IP. The terminal server comprises a modem bank, which provides a connection point for high speed PSTN modems, a server, and one or more network interfaces. The server is capable of hosting multiple independent PPP sessions; one for each connected modem user. The server also acts as a router, routing IP packets between each of the individual PPP interfaces and any active LAN interfaces. The CM 104 includes a commercial retail terminal server, either integrated or deployed in conjunction with an external one.

The dial-up terminal server supports and includes the ability to negotiate CRTP Header Compression for your PPP sessions. Similarly, the PPP stack used by a dial-up client also includes, and attempts to use, CRTP: However, due to the additional bandwidth available for high-speed modems, the inability for a user based on the Dial-up negotiating CRTP Header Compression may not necessarily force a network to avoid using RTP-based payload specifications.

If the terminal server is located in the internal LAN network of the service provider of the Master Administrator of a CD 352 and, therefore, close, in a topological network sense, to the CM 104 of the service provider, the users by telephone connection they can avoid quality of service issues that can contribute to high end-to-end latency if the path between the ISP's terminal server and the Cm 104 traverses a portion of the public Internet. Since PSTN-based modems typically do not support an idle concept similar to that implemented by the IS-707.5 standard, dial-up based network participants ignore any idle messages received from the CM 104 Although the user database 232 tracks whether a connected user is cellular or terrestrial based, this facility is provided in either case. Consequently, CM 104 may or may not send idle messages, or other media signaling, to dial-up users.

NBS service areas are designed to be integrated, both to allow users to roam between service areas and to join equivalent networks defined within different service areas. Peer-to-peer communications between multiple CM 104s take the form of SIP server redirects, exchange of user and network database records, and additional messages specific to an integrated NBS service.

In an integrated service embodiment of the NBS, it may be preferable to allow any CM 104 to take ownership of a network. Thus, the operation of a network is not specific to a particular CM 104, or a particular MCU node 208. The choice of CM 104 can be determined dynamically, based on factors such as proximity to the majority of network participants, and the quality of service available in a network between service provider systems. Similarly, any SIP redirect server 236 is capable of redirecting any CD 352 to the appropriate SIP user agent server, and / or, if necessary, forward the CD 352 to another SIP redirection server.

In an integrated implementation of NBS services, a network address in the network has meaning throughout the NBS system. As a result, one or more high-level SIP servers 236 are responsible for redirecting INVITE requests and distributing network participants among appropriate MCU nodes 208. The top-level SIP servers 236 can share a common user and network database 232, providing similar redirection decisions and functionality at different rendezvous points on the network. As a result, redirection of invitations originated by CD 352 provides an important, and critical, layer of abstraction that allows multiple installations of CM 104 to be integrated into a single, homogeneous NBS service.

ES 2 343 563 T3

In an integrated NBS service, the system is tuned by duplicating the functionality provided by the MCU node manager 256, its associated set of MCUs 252 (informally referred to as a "MCU Cluster"), including its SIP user agent server. . A single database 232 and the management interface 248 are shared by all elements of the system.

The process by which a CD 352 joins a network in such an embedded system is essentially the same as that used in a system comprised of a single CM 104 installation. The CD 352 initially sends all SIP requests to server 236. high-level SIP redirection (now global). The redirect server 236 redirects, via SIP mechanisms, the requesting CD 352 to the proper destination. In the case of an INVITE request to join a network, the destination is the SIP user agent server 252 associated with the MCU node 208 with current responsibility for the network in question. In the case of an INVITE requesting a current list of networks available to the CD 352, the destination is any user agent capable of responding to the request.

Separately, the redirect server 236 may exchange additional messages with the MCU 252 via inter-application messaging, using implementation-specific messaging protocols and / or conventions. As in the non-integrated case, a special boot action may be required to ensure that the redirect server 236 can determine a destination for any legitimate INVITE requests it receives. One embodiment has the SIP records existing on the high-level redirect server 236. In addition, the top-level server can query the system database and attempt to associate each invitation request with a network definition contained therein.

The CD 352 can provide encrypted networkcast communications. Depending on the choice of network users, voice and data transmitted over a specific network can be encrypted on the transmitting CD 352, and decrypted by all other CDs on the network. Encryption is end-to-end, that is, from one CD to another. Network communications are typically encrypted by a commercial encryption algorithm embedded in an NBS-enabled CD. The choice of whether a CD 352 treats a network as encrypted or decrypted is left to the users of the network; that is, the involvement of the CM 104 is not required.

Users can select, network by network, if they would prefer the traffic transmitted / received over that network to be encrypted / decrypted. The user is given the ability to enter an encryption key for the network, using, for example, the telephone key panel. In this way, the user is able to participate in encrypted communications with other users on the network, who have also selected the encryption option for that network, and who are also using the same encryption key.

The user can enable or disable encryption of network traffic for any network key that the user has entered into the CD 352 at any time. Media traffic can be symmetrically encrypted using a symmetric key (a traffic encryption key, or TEK) that is shared by network users. Encryption keys for network traffic can be generated offline by a network user, or network administrator, and then securely distributed to network participants who manually enter the keys into their respective communication devices. The key is used for media traffic over a specific network, until new keys are generated and distributed to network users to replace the old network TEK.

CD 352 is notified that it is a member of a specific network through messages received from CM 104. The network administrator for a specific network may set an advisory flag indicating that the network is intended to be encrypted. This indication is generally advisory, and does not necessarily indicate with authority that communications on the network are effectively encrypted. The user interface of the CD 352 allows a user to designate any network as an encrypted network, and allows the user to enter the next TEK from the CD 352, regardless of whether an encrypted advisory indicator for the network has been received by the CM 104.

The CD 352 can enforce minimum and maximum key lengths. The CD 352 may provide a means for a key checksum to be entered in conjunction with the key and, if provided, for the checksum to be verified against the entered key. If the checksum is not entered, the CD 352 calculates the checksum and makes it available for user viewing. The CD 352 does not necessarily display the key on the CD 352 display after the initial key entry.

Once a key is successfully entered for a given network, media streams on the network are encrypted using that specific key, and all traffic received by the network is decrypted using that specific key. The encrypted traffic includes additional headers that allow the CD 352 to synchronize the encryption / decryption process, to support late synchronization (synchronization with a transmission already in progress), and to confirm that the sender and receiver are using identical traffic encryption keys. . If a Cd 352 receives encrypted traffic (detected by the presence of the encryption headers) by a network that is not designated as encrypted, the CD 352 indicates that it is receiving encrypted traffic to the user, and does not broadcast traffic (mutes the audio or suppresses the data output). Similarly, if the CD 352 receives media traffic that is not encrypted by a network on which it is configured to encrypt, or if the traffic is not properly decrypted (for example, if the keys are incompatible), the CD 352 alerts the user and mutes the traffic.

The key for an encrypted network can simply be a random (binary) number. In general, the key can be generated by a participant in a network, or by an administrator for that network, and be distributed securely to

ES 2 343 563 T3 the network participants. Since the key distribution policy is currently left to network users, it is a potential source of network security compromise. Therefore, it is recommended that the network encryption key be distributed using secure means, such as encrypted email from PGP, to network participants. Security manager 20 (FIG. 1) also provides a central repository for common network keys. Other procedures, such as a standard phone call or face-to-face meetings, are also possible. Keys can also be automatically distributed to CDs, using a PGP secret key embedded in a communication device, for SIP authentication.

The above description of the preferred embodiments is provided to enable anyone skilled in the art to make or use the present invention. Various modifications of these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of inventiveness.

Other features and advantages of the invention are set forth in the following claims.