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

ES 2 396 683 T3

DESCRIPTION

Communication device and its corresponding procedure to provide security in a group communication network

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 a method, a computer-readable medium, and a communication device for providing security in a group communication network.

II. Description of Related Art

Point-to-multipoint communication systems have been used to provide communications, in general, between a central location and multiple users of the system. For example, dispatch systems using Terrestrial Mobile Radios (LMR) have been used in trucks, taxis, buses and other vehicles, in order to communicate planning information between a central dispatch center and one or more corresponding vehicles in the fleet. Communications can be targeted 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 having a wireless communication device, to communicate with other members of the group. Typically, a push-to-talk type system relies on a single, or dedicated, frequency 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 only broadcasting member. 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 settings, where a group of people, or members, require communication with each other in a "point-to-multipoint" manner. 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".

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 single channel. In any event, only one member can transmit voice and / or data communications to the other member users at any given time. If another member tries to transmit on the broadcast channel while another member is transmitting, interference will occur between the two competing communications, resulting in unintelligible communications being received by the other network members.

US Patent No. 5,402,491 discloses a method for providing limited secure services in secure trunk communication systems.

Summary of the invention

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

In addition to the high costs associated with current point-to-multipoint communication systems, in general, communications are confined to members operating in relatively close proximity to 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.

According to the present invention, a method for providing security in a group communication network, according to claim 1, and a communication device, according to claim 7. A computer-readable medium, according to claim 6, is also provided. embodiments of the invention are defined in dependent claims 2 to 5.

ES 2 396 683 T3

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 the like reference characters identify correspondingly in their entirety, and in the which:

FIG. 1 illustrates a network broadcast system.

FIG. 2 illustrates an NBS 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 real-time protocol voice media protocol stack.

FIG. 7 illustrates a UDP voice media protocol stack.

FIG. 8 illustrates a stack of media traffic protocols.

FIG. 9 illustrates a DNS client protocol stack.

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

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 with respect to torpor.

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 the CD 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 IP (VoIP) application. Voice communication is transmitted from a talker endpoint 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, entitled "Procedure and Apparatus for Providing Group Communication Services in an Existing Communication System", filed March 3, 2000, File No. 000212, and US Patent Application Serial No. 09 / 518,776, entitled "Procedure and Apparatus for Participating in Group Communication Services in an Existing Communication System", filed March 3, 2000, File No. 000211, and are specifically incorporated by reference herein.

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 broadcast service (NBS), a dispatch system, or a point-to-multipoint communication system. A defining characteristic of such an NBS system is that, in general, 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 are capable of monitoring communications between members of more than one network, but are only capable of transmitting information to members within their own network.

ES 2 396 683 T3

The network works on top of an existing communications system, without requiring significant changes to the existing infrastructure. Thus, a controller and users in a network can operate in 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 Time Division Multiple Access (TDMA), a Global System for Mobile Communications (GSM) system, satellite communication systems such as Globalstar ™ or Iradium ™, or a wide variety of other systems.

The network members communicate with each other using an assigned communication device, shown as communication devices (CD) 12, 14, 16, and 17. 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 type, wireless video cameras, fixed cameras, audio devices such as music players or recorders, laptop or desktop computers, 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 unsecured (open) mode. Throughout the following discussion, reference to an individual CD may be expressed as a push-to-talk type cordless telephone. However, it should be understood that reference to a CD is not intended to be limited in such a way, and may encompass other communication devices that have the ability to transmit and receive packet information in accordance with 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 the requesting network members, 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 in 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 controller or a communications 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 Netra T1 ™ Workstation.

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 prevent snooping. Encryption for secure networks is implemented in an end-to-end mode, which means that encryption and decryption takes place within each CD. The CM 18 generally operates without knowledge of algorithms, keys, or security policies.

The CM 18 manages remotely through 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-operated security manager (SM) 20, which is compliant with a management interface. of CM 18. CM 18 can authenticate, to high-grade commercial standards, any participant attempting to establish or modify a network.

The SM 20 is an optional component of the NBS system 10 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 generally does not engage in real-time control of a network, including network activation or PTT arbitration (Press To talk). The SM 20 may have management capabilities compatible with an interface of the CM 18, 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 from a CD comprises a push-to-talk (PTT) 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, sending a request to obtain the transmission privilege from 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 an audible, visual, or tactile alert via the CD. After the requesting user has been granted the transmission privilege, the information can then be transmitted from that user to the other network members.

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

ES 2 396 683 T3 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 a gateway 24. 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 can 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 be to establish a dedicated forward broadcast channel, but require 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 inter-operation function (IWF) for processing data packets, including the request between the MSC 18 and the distributed network 26. For the CD 16, the request is transmitted by satellite to satellite gateway 24. For CD 17, the request is transmitted to the Public Switched Telephone Network (PSTN) 30, and 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 is not necessary for the network participants.

If no other member currently retains the transmitting privilege when the request for the 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 only needs to be duplicated once for each broadcast channel in use.

In an alternative embodiment, the CM 18 is built into the MSC 28, so that data packets from the supporting base stations are routed directly to the CM 18 without being routed over the distributed network 26. In this embodiment, the CM 18 is still connected to the distributed network 26, so that other communication systems and devices can participate in a 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 username, account number, phone number, or dial number, associated with the member's CD, an assigned Mobile Identification Number to the CD, the current member's network status, 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 data 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 related types of information can also be stored by the database regarding each network member.

As part of the NBS infrastructure, the communication manager (CM) forms individual communication terminal connections to form a chat group, or network. The CM comprises a wide variety of hardware and software functional capabilities that are configurable in different ways to accommodate different applications. Overall, CM provides the ability to manage network authenticity, administrative, and real-time operations (NBS), push-to-talk (PTT) request arbitration, maintenance, and network distribution. network membership and enrollment lists, call establishment and decommissioning of the necessary CDMA network and system resources, as well as overall control of network health.

The NBS network can be within a stand-alone deployable 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 functions as a plug-in module in the existing cellular infrastructure. Thus, the new features introduced by the NBS networks are available to cellular users without requiring modifications to the existing cellular infrastructure.

One role of the CM is to maintain a list of defined NBS networks. Each network definition includes a

ES 2 396 683 T3 network identifier, a member list, including telephone numbers or other identification information, user priority information, and other generic management information. Networks are statically defined as 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 snooping. Media encryption for secure networks is implemented in end-to-end mode, 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 customer-operated security manager that is compliant with the CM management interface. The CM authenticates to high-grade business standards for any participant 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 they are carried out in various ways. Furthermore, the phraseology and terminology used herein is understood to be for the purpose of description and should not be construed as limiting.

FIG. 2 illustrates an NBS network 100 and how communication devices interact with a CM 104. Multiple CMs 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 112 and CD 116) are not allowed to stream media to the network. Consequently, CD 112 and CD 116 are designated as listeners. If CD 116 is designated as the speaker, CD 108 and CD 112 are designated as listeners, and so on.

As described above, each CD 108, 112, and 116 is connected to the 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 anyone. of CDs 108, 112 and 116. SIP is an application layer protocol defined by the Internet Engineering Task Force (IETF), which 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, mechanisms to determine user availability, call establishment and call management.

SIP channel 120 is used to initiate and end participation of a CD within network 100. Optionally, a Session Description Protocol (SDP) signal may also be used within SIP channel 120. When SIP participation within an NBS network is established using SIP channel 120; real-time call control and signaling between the CD and CM 104 takes place using the NBS media signaling channel 124. Specifically, among other tasks, the NBS media signaling channel 124 is used to handle push-to-talk requests and releases, arbitrate between conflicting requests, or for shift control, to announce the start and end of transmission information, manage network dormancy, trace endpoint connectivity, request and exchange network status, notification and error messages. The NBS 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, which mainly consists of requests and acknowledgments of SIP invitations, and media signaling, which is mainly composed of by real-time shift control requests and related asynchronous messages. Media traffic on media traffic channel 128 is comprised of real-time point-to-multipoint speech and / or data broadcasts. Both categories of messaging have unique functional attributes. In addition, each CD can issue Domain Name Service (DNS) client requests to facilitate the mapping of fully qualified DNS host names to Internet network addresses.

NBS call setup and call control signaling is carried out according to SIP semantics. Although SIP can be transported using the well-known User Datagram Protocol (UDP), or

ES 2 396 683 T3 or Transmission Control Protocol (TCP), in a preferred embodiment, each CD performs the signaling functions based on SIP using UDP, as illustrated in Fig. 4. In addition, each CM waits receive all signaling requests from SIP using UDP. Real-time signaling occurs through dynamic UDP / IP interfaces on the CM and 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 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 CM Central Complex 204 provides manageability to a Java ™ enabled Web browser. One or more DNS servers 216 may also be included in the central CM complex 204. 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 initial connection to CM core complex 204, a network is operated by MCU node 208. MCU node 208 sends and receives information, as needed, from CM hub 204. The separability of the CM core complex 204 allows for versatility, in that once a specific network is established, the network is operated by a dedicated MCU node 208. This allows the central complex 204 of the CM to provide initial connections to other potential networks, regardless of the type of communication structure in which the network wishes to operate. In addition, the central complex 204 of the CM may be geographically offset from the node 208 of the MCU. 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 regionally located to operate 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, information may be provided to a user, or group of users, based on location, such as broadcast, instructions, or identification of milestones based on location.

CM node 228 provides centralized functionality associated with NBS networks. The CM node 228 comprises a server 236, Session Initiation Protocol User Agent (SIP UAS) server, and CM manager 240, a central billing registry 244, and a management server 248. Server 236, SIP UAS, supports user requests for network lists and handles SIP invitation 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 MCU data nodes, such as MCU node 208. The CM administrator 240 manages administrative functions pertaining to network administration, including creating and deleting networks, defining new users and deleting existing users, adding and removing users as network members, and adjustment of various operating parameters in a user, network or CM-wide environment.

The central billing register 244 maintains time and identification information for billing purposes. The central billing registry receives billing registration information from a local registration 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, initiate database administration and system 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 a publicly known 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 network 100. The UDP connection can later be answered 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 implements network communication. The protocol associated with each layer communicates with the layers immediately above and below it, and supports the underlying layers. Because UDP is a less reliable connectionless transport, application-level reliability is preferable to ensure robust communication, which is achieved by implementing SIP-compliant endpoints. In general, SIP call signaling 302 on UDP flows 304 is encapsulated within the IP 306 protocol.

ES 2 396 683 T3 requires no special formatting. 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-to-point (PPP) frames. ). Consequently, no special formatting is required. In addition, SIP call signaling PPP 308 frames exchanged between a CDMA cellular base CD and a base station are encapsulated within a 310 radio link protocol (RLP). For PSTN-based users For telephone connection, a suitable modem standard, such as V.32bis or V.90, can replace the 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, carrying voice and data traffic, using UDP datagrams 304 over IP 306. NBS media signaling 314 is arranged as a layer on top of traffic 306 of the UDP / IP, and is managed in a similar way with respect to the description of Fig. 4

FIG. 6 illustrates a real-time protocol 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, Compressed Real Time Protocol (CRTP) overhead compression 330 is used to further encapsulate media traffic using RTP 322 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, inclusive.

In operation, each CD dynamically selects a UDP port on which it intends to listen for media signaling requests from the NBS 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 CM media signaling destination address (including the UDP port number) is described in the network session description delivered as part of a successful SIP INVITE response to the CD. Unlike SIP signaling addresses, media signaling destination addresses are network specific and can change between examples 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 RTP / UDP payload 324 or a UDP payload 304. 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 (which includes the UDP port number), are described in the session description response to a successful invitation request from the SIP from SIP server 236. Like the media signaling addresses of a network, the destination addresses of media traffic are network specific and can change between examples of a CD joining a network.

Typically, as shown in FIG. 6, voice traffic is encapsulated at the application layer using 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 only UDP datagrams 304, without any 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 reflects the definition given for a corresponding RTP payload 324, without the RTP header fields. The decision to encapsulate the 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 advertises the media type in the network's SIP session description when a CD is formally added to the network.

FIG. 9 illustrates a DNS client protocol stack 338. Each CD includes the ability to resolve names of

ES 2 396 683 T3 Internet domain in Internet addresses, using a 340 protocol of the Domain Name Service (DNS). The CD functions as a DNS client. The CD encapsulates the 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 network address of the server IP 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 a secure network key repeat, 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 regarded as 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 1034 document. Alternatively, the CD functions as a client or agent of DNS resolution, as described in RFC 1035.

In order for the CD to resolve DNS host names, the CD is pre-programmed with the IP network address 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 foreign 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 Fig. 8.

The NBS also takes advantage of the development of a cellular multicast channel. Such a channel generally allows a transmitting station to address N listening stations directly over a direct channel, without the need for N separate 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 signaling and media traffic destination addresses of a network are conventional IP multicast channels, and the signaling broadcasts and media traffic originating from the CM are multicast broadcasts. Each signaling broadcast and media traffic originating from a CD is preserved as point-to-point communications.

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

A wide variety of RLP 310 modification strategies are possible. For example, the RLP 310 can be modified to send multiple messages, such as NAK responses, after an initial RLP timeout, thus incentivizing the remote end to transmit multiple copies. of the lost frame of RLP 310, and improving the chances of a successful recovery of RLP 310. RLP 310 can also be modified to never send NAK responses (after the RLP timer expires) and allow RLP 310 lost frames to force higher levels of the protocol stack to generate errors. All TCP-based application layer protocols are routinely recovered using TCP's error recovery mechanisms. Traffic that relies on UDP 304 for transport already struggles with the potential for loss.

Referring again to Fig. 2, once the CD establishes participation within the NBS network 100 using the SIP channel 120, the CD is ready to send and receive media from the network 100 on 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 the received media at its media ports, according to the defined vocoder and media format in the session description of network 100 received in an invitation response when the CD was added to network 100. The CD encodes and encapsulates media sent to network 100 according to the vocoder and media format defined in the network 100 session description received in an invitation response when the CD was added to 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 the call setup of the SIP, and uses it to address 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 on the infrastructure side of this

ES 2 396 683 T3 interfaces are not needed in general. The CD can optionally support most NBS activities using Quick Network Connect (QNC), as further described herein.

After handover to a service provider, the CM administrator 240 goes through the basic administrative setup before supporting NBS activities. Initial configuration involves basic system configuration, such as assigning passwords to accounts at the operating system level, for root-level system administration, and configuring the CM Manager 240 network interfaces for proper operation on the system. wireless local infrastructure network.

Once the CM 104 is configured, general network management can take place. Network administration functions take place through an HTML or other network interface, built on top of TCP / IP. The administration workstation 224 interacts with the central CM complex 204 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) simultaneous management connections are allowed.

When connecting to the central CM complex 204 for network administration purposes, the administrator workstation 224 is successfully authenticated to ensure that only authorized administrative actions are accepted. Different levels of access are assimilated; for example, authorized network members can connect directly to the CM administrative interface (248) to modify specific lists of network members. The more generic administrative privileges are generally reserved for specific administrative accounts. For clarity, administrative actions are generally separated into those that specifically deal with 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 suspend time, the private dispatch timeout, and the member list. A network member list 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 web browser equipped with Java ™. The second is an NBS-specific Command Line Interface (CLI), based on TCP / IP.

The administration server 248 carries all of the 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 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 can be carried out, optionally, through HTTP GET and POST commands, issued by the Web browser, using conventional HTACCESS authorization mechanisms. The administrative functions supported are generally a subset of those 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. Network. Before being granted access to the CLI interface, a potential administration workstation 224, which connects 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.

The 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. The database server 232 also 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

ES 2 396 683 T3 information that supports the activities of the NBS network, including a part of the NBS network database and a part of the NBS user database. The information that supports the activities and administration privileges can be stored in any of the databases, or in a third, functionally different database. The database server can be further subdivided into a user part and a network part.

The CLI interface supports administrative functions such as create user / network, delete user / network, modify user / network, list / show user, list / show network, status, and CLI help. The Create User function allows the administration server 248 to create new users in the users part of the database, even specifying all the fields of user records. The Delete User function allows the administration server 248 to delete existing user records in the user part of the database 232. The Modify User function allows the administration server 248 to modify existing user records in the user part of the database 232, even to modify all fields of the record for a specific user.

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

The List Networks function enables the management server 248 to list all networks, by network address and network identifier, in the networks portion of the database 232. The Show User function allows the administration server 248 to display all the fields for a specific user identified by the user's user ID. The Show Network function allows the management server 248 to display all fields for a specific network identified by the network identifier or network address of the 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 real-time (updated) reports. 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 command with CLI support, including the usage and description of the syntax.

The NBS Users 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 network defined in the CM networking portion of the database 232.

Each record in the users part of the database 232 is composed of fields such as user name, user identification, vocoder list, dial number, user type, CRTP support, CD user address and the Pretty Good Privacy (PGP) public key. The vocoder list is a list of vocoders that are supported by the subscriber's CD. The list may include vocoders that are 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 connecting through the PSTN dial-up connection are considered generic Internet users. CRTP support is an indicator that indicates whether or not the CD supports, and tries or not to negotiate CRTP Header Compression over PPP when connecting. This flag is valid for cell-based 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 users 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 networks 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 networking portion of the database 232 is comprised of 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, is / are identified by user IDs who 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 arbitration conflicts of the PTT function between network participants. The network vocoder

ES 2 396 683 T3 describes a field with a unique value that identifies the standard vocoder shown in the published session description of the network. Defined members of the network have this vocoder listed in their supported vocoder list. The PTT function failsafe timeout is the maximum number of seconds that a network participant can transmit media to the network before the CM takes control of the turn with a PTX deny message. The sleep timeout value is the maximum number of seconds that the network can remain idle before the CM puts it into the sleep state. The PTX Sleep 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 timeout value is the maximum number of seconds that the CM waits for network participants to respond to the AYT “wake-up” message before granting a pending request for the PTT feature. The sleeper 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 list of active participants in the net. The AYT timeout value 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 list of active participants on the network. 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 network membership list defines the set of users who can request to join the network as participants and the associated network-specific 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 network's PTT arbitration algorithm 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 sleep candle timer. The network address is the formal network address of the network's SIP that the CD uses to request to join the network as an active participant. The Network security advisory flag is the open / secure network 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 of 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 sleep candle timer is the length of the interval, in seconds, that the CD will wait, when in the Sleeping / Idle state, before transitioning to the Connected state, confirming that the packet data call is still valid and that the base station has not unilaterally cut the connection.

MCU node 208 comprises MCU 252, MCU node manager 256, and local registry server 260. MCU node 208 and 212 may optionally also comprise an additional MCU 264. MCU node 212 is essentially the same as 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 can have a pool of MCUs 252 that can be instructed 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 to allow startup and / or shutdown, assign a network to the node, and share status information.

Local log server 260 logs all log events for MCU node 208 locally. The local registry server 260 also responds to requests from the central registry server 244, via its registry event interface 276. Requests include loading certain event classes or priorities. In order to prevent event loss, 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 requests for SRV records. The DNS server 216 can be located anywhere on the network. In one embodiment, the DNS server 216 is part of the central complex 204 of the CM.

Each CD maintains a network list, or group list, which internally represents the set of known networks

ES 2 396 683 T3 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 is also able to 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 phone book and used to provide voice services. The NBS group list can be integrated into the conventional phone book of the telephone. In either case, the act of selecting a network from the list of groups 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 be added to the list of active network participants for a specific network. Thus, each CD is initially aware of, or is able to learn, the network address of any networks in which it wishes to participate. Furthermore, each CD initially knows, or is capable of being configured with, the address of a top-level SIP server 236, to which SIP requests can be sent.

Network addresses can be enlisted, or learned from a CD in a number of different ways. For example, in one embodiment, the CD may be initially provided with the address of a known or default top-level SIP server 236 that provides a current list of networks in which the CD may participate. The CD can also be endowed with a group list, 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 NBS allocation has taken place for the CD, the user may be provided with a top-level SIP server 236 and a network address to interactively access the CD prior to using the NBS. The user can also interactively enter network addresses to a group list that has already been provided with entries. 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 into the group list on the CD, the corresponding network and top-level SIP server 236 are preferably already in stock and the user needs to be listed as a member of the network so that the CD can successfully participate in the network.

The CD can also be provided with the IP network address of the Domain Name Service (DNS) server 216, to which the CD can send DNS queries. Typically, the address of the DNS server 216 operated by a CDMA cellular carrier is registered. The CD can also be provided with the IP network address of an alternate DNS server.

In order to support SIP authentication, the CD may be provided with a unique PGP user identifier and a secret key that it can use to sign SIP transactions when requested by CM 104. The user identifier of 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. Normally, the group services module is initialized in an idle state 504 by default when the CD is turned 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 CD user interface. If the user has disabled NBS services, the group services module, by default, goes to a disabled state 508 when the CD is turned on. When disabled, the CD does not attempt to automatically join any NBS network. Also, the CD does not perform any NBS-specific SIP transactions (the CD may keep records or perform other SIP transactions for other IP-based telephony applications that reside within the CD).

Optionally, group services can be totally hidden from the user, registering group services within the CD in an unequipped state 512. The unequipped state disables group services, where 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 related user interface features are not available to the user.

The CD can support the over-the-air crew 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 automatically attempts to transition from idle state 504, attempting to join this selected network shortly after the CD is turned on.

When the CD is connected, the CD cycles from a 516 idle state, a listening 520 state, a 524 state

ES 2 396 683 T3 of talk 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 provide mechanisms by which an individual CD can formally join or leave networks. The CM 104, along with other functional entities, includes the top-level SIP server 236, one or more multipoint control units (MCUs) 252 and associated SIP user agent servers, and the user and user parts. management database 232 networks. 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 definitions of users, administration and network addresses, and can serve multiple installations of the CM or support access remotely.

Each CD is provided with a list of network addresses, and one or more top-level SIP server 236 addresses. 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 for a pre-defined SIP destination.

The top-level SIP server 236 can redirect the request to an internal destination or respond to it directly. The INVITE response to 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. Top-level server 236 attempts to map the network address to a known destination and, if successful, redirects the CD to the corresponding SIP user agent server in MCU 252. If no correlation is available, the invitation generally fails.

Typically, the destination SIP user agent server of the MCU 252 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 in the network, 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 operation. normal network. If the invitation is accepted, the CD acknowledges receipt of the response through a message, such as the SIP ACK procedure. Note that other transient response codes indicating call progress may also be received by the CD while the invitation is being processed.

The CD is responsible for updating its list of groups for 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 an appropriate message to the user (eg: “Added to group X ') and / or possibly a request for 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 addresses of networks in which they have lost their membership in the group list.

In general, 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 initially selected, or the user can select a network from the group list.

The MCU 252 CM SIP user agent server response to an INVITE request to join a network includes, as embedded content, the network's real-time media and media signaling destination addresses, as well as as other network parameters (such as descriptors of the media payload format). Once confirmed, the CD briefly displays the response to the user, indicates whether the user has listen-only privileges, and enables the group services features. 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 a record is rejected, the CD briefly displays a corresponding error message and the group service functions go idle. If no network is selected, group services within the CD remain idle.

As part of activating group services, the CD initializes and opens its RTP media traffic channel 128 and individual NBS media signaling channel 124 for the CM destination addresses provided in

ES 2 396 683 T3 a successful invitation response. Once these channels have been initialized, group services are activated on 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 voice traffic to the network. net.

With group services active, the CD 108 monitors its media traffic 128 and signaling channels 124 towards the CM. Voice data received on media traffic channel 128 is decoded and displayed using a CD far field speaker 108 or an earpiece 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 signaling 124. If the identity of the current speaker is not available, the CD 108 displays the name of the current selected network as listed in the group list. The CD 108 can also tabulate media traffic statistics (e.g., total time spent chatting, listening, and monitoring, and estimated packet loss from receiving media traffic) and make them available to the user as a diagnostic, using an option. from the menu. While 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, the press of a key or key sequence, 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 explanatory message, and returns to the idle state 516. The CD insists that the PTT be released and pressed again before attempting another request for shift control. If granted, the CD 112 enters the group services talk state 524, signals the user, for example, with a short audible chirp, and begins transmitting voice traffic to the CM 104 as long as the PTT is depressed. CM 104 can asynchronously signal CD 112 (while PTT is depressed) 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 is released, at which point it returns to the idle state 516. Otherwise, once the PTT has been 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 group list whenever 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 one is selected network, 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 new network onboarding process fails, CD 108 is no longer a member of any network and group services within CD 108 revert to idle state 504.

If the CM 104 determines that the CD 108 requesting the turn of a specific network is the only registered member of the network in question, the 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 there may be a network 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 protocols at the application level: 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 setup. Media signaling carries PTT requests (Fig. 12), manages network dormancy (Fig. 13) and resolves PTT arbitration disputes (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 the server interface 236. of the SIP of the CM 104. To join a network, a CD 352 invites the network 100, by name, to participate in a call, through the top-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 addresses provided, of the primary or secondary SIP server, to Internet network addresses, if necessary. As an optional alternative approach, SIP conventions allow CD 352 to query DNS 216 for service records associated with the NBS host domains 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 alternate port information is determined through DNS 216. Before attempting to join a network, CD 352 can make a call using the SIP INVITE procedure to request an updated list of available networks.

ES 2 396 683 T3

For example, the CD 352 that has invoked an over-the-air connection has been assigned an IP address, and wants 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 directed 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 cell-based 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 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 top-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 a 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 the CD 352, the server 236 can specify the redirection destination by 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 an INVITE request response 356.

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

Server 236 may be unable to successfully respond to CD 352, for a variety of reasons. In such circumstances, the server 236 delivers an appropriate SIP status code in place of the INVITE response 356. 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 extend a successful INVITE response 356 with informational status responses indicating the progress of the records. The CD 352 can accept and interpret informational status codes that prolong successful registrations.

The CD 352 requests to join a network by issuing a SIP INVITE request 358 to the CM administrator 240, 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 one. UDP / IP connection to SIP server port.

The CD 352 is ready to be redirected by the top-level SIP server 236 and re-issue the request to the redirected destination, if necessary. The CM top-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 with the CD 352, assuming the invitation is successful. If included, the description is included as message content and 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 source description (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 type of network, the type of address and the connection address. The CD 352 uses the IP address with which it labels the media (or source) traffic as the connection address. The CD 352 uses the name portion of the network address of the network as the session name (s). CD 352 specifies the lifetime (t) of the session by providing its best estimate of the current time start, preferably in Network Time Protocol (NTP) format, and indicates that the session is unlimited (0). The description of the media format (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 operated as an NBS conference. The server 236 should confirm that the invitation address is indeed a valid NBS network address before granting the invitation.

ES 2 396 683 T3

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

A successful INVITE 360 response includes the primary session description for the invited network, which describes the ports and formats of the supported media traffic, 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 successful SIP invites.

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

After receiving a successful INVITE response, the CD 352 confirms the invitation by sending a SIP acknowledgment (ACK) request 362 back 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 signaling ports and media traffic, according to the session description delivered in the INVITE response 360.

At any time after the CD 352 has transmitted the SIP ACK message 362, in response to a successful INVITE response 360, the CD 352 can formally terminate its participation in the network by sending a SIP 364 GOODBYE message to the server 252 network user agent. Before sending the 364 GOODBYE message, the CD 352 may need to open a TCP connection to the user agent server 252. The message 364 GOODBYE is acknowledged as received by the CM with a response message 366 to GOODBYE. Once the GOODBYE response message 366 is acknowledged as received, the CD 352 can close its UDP connection with the 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 CD 352 SIP user agent client can use the OPTIONS procedure to query the capabilities of a SIP server. In particular, the CD 352 may wish to query an arbitrary SIP destination to determine whether or not the destination provides NBS call signaling support.

The CD 352 may wish to abort an INVITE request 358 before receiving the INVITE response 360 ​​and sending the acknowledgment 362. In such circumstances, the CD 352 may use a SIP CANCEL (not shown) procedure to politely abort the call. Both the top-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 ongoing 358 INVITE message, if the user decides to place a voice services call and presses the send key before the 358 INVITE message is completed. In such a circumstance, instead of waiting for the INVITE response 360 ​​to complete and immediately sending the message 364 GOODBYE, the CD 352 can simply CANCEL the INVITE message 358 immediately and proceed to make the requested voice services call.

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

Media signaling messages are transported using the protocol stack illustrated in Fig. 4, and according to 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 signals 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, source, and a reserved one. The

ES 2 396 683 T3 opcode field defines whether the PTT message is a shift control request or a shift release message. The identifier field provides a unique message identifier to allow subsequent PTT and PTX release messages to refer to 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 PTX response message 372 for each PTT request 370 transmitted. If a PTS response 372 is not received within a predetermined time-out period, the CD 352 assumes that the PTT request 370 was lost in transit and retransmits the PTT message 370 using the same PTT identifier.

If a PTX reply 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 reachable, performs the transition 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 message 372 to respond to a request or release of the PTT shift control. The PTX message 372 includes information such as whether the referred shift control request was granted or denied. In responding to a PTT shift control release 370, the PTX message 372 is used to indicate only acknowledgment. SIP user agent server 252 can also use PTX message 372 to asynchronously deny a previously granted shift control request (when a higher priority CD 352 issues a shift control request, the PTX grant expires ( that is, its timer expires), or some other event occurs that requires that control of the network turn be revoked).

The PTX message 372 comprises fields such as opcode, identifier, action, status, and expires. The opcode field defines whether PTX message 372 is a synchronous response to 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 message 372 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 message 372 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 therefore is not allowed to forward media signaling requests for the network . The expire field represents the maximum duration, in whole seconds, that control of the network turn is granted to the receiving CD 352. The SIP user agent server 252 starts its timer from the time it sends the response to the PTX message 372 not when the 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 of the PTX message. Instead, if the transmitted PTX message response 372 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, instead of handling the retransmitted request 372 of the PTT message. as a non-push-to-talk request event.

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

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

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

ES 2 396 683 T3

A 404 AYT "are you there?" (Fig. 13) is sent by the 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 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 if the SIP user agent server 252 is using the 404 AYT message traffic to output the messages. associated CDMA cellular traffic channels of the sleeper 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, the CD 352 responds to a received AYT message 404 with an IAH response message 408.

The SIP user agent server 252 assumes that the CD 352 generally responds to a 404 AYT message with a 408 IAH response. If an IAH response 408 is not received within a reasonable expiration time, the SIP user agent server 252 transmits a new AYT message 408 with a new identifier. If, after a configurable number of retransmissions, a response to message 408 AYT is not received from the CD 352, the CD 352 is assumed to be inaccessible and the SIP user agent server 252 removes it from the current list of participants network. Future media signaling messages from the deleted CD 352 will be ignored (or will generate an error response) until the CD 352 successfully rejoins the network.

IAH message 408 is sent by CD 352 to SIP user agent server 252 to acknowledge receipt of a previously sent AYT message 404. The IAH message 408 comprises fields such as identifier, source, and reserved. The identifier field refers to a previously received AYT message 408 of which the CD 352 is acknowledging. The source field uniquely identifies the CD 352 that sends the response IAH message 408 to the SIP user agent server 252. The reserved field reserves space in the 408 IAH message for future capabilities.

The SIP user agent server 252 assumes that the CD 352 acknowledges all received AYT messages 408 with a reply IAH message 408. If the aforementioned 408 AYT message 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 takes note of the time. of the 408 IAH message for future reference.

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 sleep message (illustrated in Fig. 13 with reference number 412) is sent by the SIP user agent server 252 to the CD 352 to stimulate the CD 352 to release its resources over the air and enter the network. sleeping mode. The CD 352 may choose to ignore this message (especially if it is simultaneously 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 differentiate 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. Failure recovery is generally not attempted if the ZZZ message is lost. To guard against the loss of a ZZZ message, the SIP user agent server 252 can 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 sleep message are sent within a defined interval, and the CD 352 waits for a period longer than this interval from the moment the first message is received. sleep (with a new identifier), before releasing its 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. The ASK 382 message also allows CD 352 to determine whether or not CD 352 remains listed as a network participant. The CD 352 may confirm its participation after a service disruption or other period where it may have temporarily lost connectivity with the SIP user agent server 252.

ES 2 396 683 T3

The 382 ASK message comprises fields such as identifier, source, and reserved. The identifier field provides a unique non-null message identifier, to allow a subsequent FYI 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 382 ASK message for optional or future capabilities.

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

Message 386 FYI is sent by SIP user agent server 252 to CD 352 to acknowledge receipt of a previously sent 382 ASK message, or is sent asynchronously by SIP user agent server 252 to inform CD 352 of an 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 382 ASK request, or whether it is an asynchronous message indicating an exceptional condition. The action field indicates whether the FYI message 386 is confirming the network participation, 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 explaining the 386 FYI response, particularly 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 that the CD 352 is acknowledging. The value of the identifier field is undefined for asynchronous FYI responses. The reserved field reserves space in the 408 IAH message for optional or future capabilities.

The CD 352 does not generally acknowledge responses to the 386 FYI message. If a response to the 386 FYI message has been lost, the CD 352 sends a new request for the 382 ASK message. Because the Cd 352 does not request asynchronous responses to the 386 FYI message, in a preferred embodiment the SIP user agent server 252 makes at least three staggered transmissions of any asynchronous response to the 386 FYI message.

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 that 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 of the grant message PTX is received. The CD 352 normally broadcasts media traffic until the user releases the PTT button, at which point they signal the end of the chat burst by broadcasting a PTT release message 376 to the SIP user agent server 252. The SIP user agent server 252 responds with a PTX acknowledgment message 378 and broadcasts an announcement signifying the end of the chat burst to all network participants.

When any DC 352 has the turn (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 suspend time, 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 over time. the 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 dormant" messages. The SIP user agent server 252 does not track, explicitly or implicitly, the dormancy state 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 616 when a successful shift control request 704 is received during sleep. As soon as the turn control request 704 has been granted, the SIP user agent server 252 will signal each registered CD 352 requesting the response 716 of Are you there? (AYT) over the media signaling channel and will initiate an internal wake-up 724. Each CD 352 acknowledges the AYT response 716 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 key, until the CD 352's traffic channel is (re) connected. The SIP user agent server 252 can temporarily store the media traffic 740 received from the speaker CD 352 until the wake-up clock 724 exceeds the wake-up timeout, at which point it begins to forward media traffic to each CD 352. registered - even to any members who have not yet responded to the 716 AYT request. Thus, both the CD 352 and the MCU node 208 have the ability to temporarily store data until the recipient is ready to receive the information.

ES 2 396 683 T3 temporarily stored. In one embodiment, portions of the 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 wake-up 724 has passed a second longer lag time-out, SIP user agent server 252 will terminate any CD 352 members whose AYT acknowledgment is pending and stop wake-up 724. The SIP user agent server 252 ignores duplicate responses from the AYT.

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

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

FIG. 13 illustrates the sequence of media signaling messages regarding dormancy 400 between CD 352 and 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. In this way, the resources allocated to the network are released and can be used for other users. In a configurable schedule, the SIP user agent server 252 sends a message request (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. The CD 352 responds to the AYT request 404 with a message response (IAH) 408. The 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, to avoid receiving a flood of simultaneous IAH message responses 408.

After the network has been idle long enough for the configurable network suspend time 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 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 needed to respond to bring the network out of dormancy. Before granting the request with a PTX message 420, the SIP user agent server 252 sends each CD 352 an AYT message request 424 to force each previously participating CD 352 out of sleep. This is done if CD 352 chose to release its resources over the air in response to message 412 ZZZ, and to confirm that participating CD 352 still remains accessible. In another embodiment, after a configurable but fixed delay, defined as the PTX dormancy response timer, the SIP user agent server 252 transmits the response 420 of the PTX grant message to the requesting CD 352. After a second wake-up timer expires (the value of which is generally no less than that of the PTX slumber response timer), the SIP user agent server 252 announces the speaker, via message 428 PTA, to all participants of the the network, and you can start forwarding 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 performing identification.

After the transmitting CD 352 is identified, the MCU node manager 256 extracts a list of network members, belonging to the network associated with the specific MCU node 208, from local memory (each MCU is usually assigned to only one net). A destination address is associated with each active network member, that is, the network members 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. Then, MCU 208 creates a second duplicate data packet, directed to the second network member. This process continues until the original data packet has been duplicated and sent to all identified active network members in local memory. During playback of any buffered media, the CM 104 treats the network as active, even if the CD 352

ES 2 396 683 T3 speaker has released the turn. Thus, the CM 104 does not allow a CD 352 to interrupt playback of the buffered media unless the interrupting CD 352 has higher priority than the source of the buffered 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 expect all network participants respond before granting pending PTT request 416. Delayed responders, whose IAH response 432 arrives after the PTX grant message response 420 is transmitted, remain listed as network participants, but may not receive all initial traffic signaling and traffic. Any CD 352 that does not respond to the 424 AYT request after a third longer (and configurable) delay is assumed to be no longer accessible and removed from the list of active network participants.

FIG. 14 illustrates a sequence of NBS media signaling messages 440 showing a higher priority CD 442 interrupting a lower priority CD 444 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 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 PTX grant message response 452 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 PTX message response 454 and continues to distribute media 456 from the CD speaker to the 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 individually configured on a network by network basis.

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 shift.

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 suspend time timer 620. When the idle timer 620 reaches a configurable prescribed value, the timer triggers the CM 104 to put the network into a sleep state 616, broadcasting a media signaling message 696 to all network participants. Upon receiving the message, a participating CD 352 may clear its traffic channel and enter a sleeping / idle state 844, or CD 352 may ignore the message and remain in a connected state 820. In particular, network participants that not working on a channel, such as PSTN dial-up users, they should ignore media signaling messages.

The network suspend time timer 620 does not advance for as long as a PTX grant message response 632 is in effect. Timer 620 is reset to zero when PTX grant message 632 is transmitted and remains at zero until PTX grant 632 expires or CD 352 clears turn 872 from the network. Once the turn is cleared, the time-out timer advances until the next PTX grant message response 632 is transmitted.

If a participating CD 352 enters sleep / idle state 844, it remains dormant until packet data addressed to CD 352 reaches the CD 352 Multiple Access cellular infrastructure or CD 352 generates data to send using data service in packages. The first case can be triggered by traffic sent to CD 352 by CM 104 (908). The second case can be activated by pressing the user the PTT button to request permission to broadcast 824 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 (which includes performing any necessary arbitration to deal with multiple requests), it sends a request 716 to each listed network participant

ES 2 396 683 T3 to trigger a transition out of the sleep / idle state 844. For any specific CD 352, the trigger 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 616, the CM 104 refrains from sending the initial PTS grant response message 756 until a fixed but configurable delay expires, the dormant response timer 728 of PTX. After timer 728, which defaults to zero, expires, CM 104 sends PTX grant 756 as usual. However, CM 104 continues to refrain from forwarding media to the network until a related second timer, network wake-up 724, expires. Both timers are reset when the CM 104 determines that the sleeper network's turn can be granted. The value of the wake-up 724 should not be less than the value of the PTX slumber response timer 728. After the alarm clock 724 has expired, the CM 104 begins to forward the media and traffic flow normally. Both timers are configurable network by 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 Sleepy / 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 908 AYT message to “wake up”. The Cm 104 maintains a third longer timer that is also reset with the PTX slumber response timer and alarm clock. This longer lazy timer (not shown) is also configurable on a network-by-network basis. After the lingering timer expires, any CD 352 whose 916 IAH response to the 908 AYT wake-up message has not been received is removed from the list of active network participants by the CM 104. Any CD 352 removed thereby returns. to register with the SIP server 236 of the CM 104 in order to once again become a network participant.

Due to the potential delays associated with transitioning a CD 352 out of 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, via visual or auditory mechanisms, at least two milestones in the processing of a PTT keystroke. First, the CD 352 signals that it has detected a PTT key press. The CD 352 then signals that it has received the 868 response 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 holding down the PTT button. However, when the network is dormant, a relatively significant delay can separate the transmission of the 852 request 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 has expired before sending the 856 or 868 response of the PTX message. In this circumstance, the CD 352 may hopefully assume that the CM 104 will eventually respond with a PTX grant response 868 and signal to the user that the PTT request 876 has been granted. To allow the user to start speaking "early", the CD 352 temporarily stores the voice internally, until either the PTX request arrives or consumes all available internal temporary storage space.

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 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 appear to be 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 temporary storage space is consumed, the CD 352 can simulate a PTX denial 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 another error action at this point and inform the user accordingly. Alternatively, if the packet data service is restored at this time, the CD 352, in this situation, may begin transmitting voice media to the CM 104 without prior receipt of a response 868 to the PTX grant message.

While waiting for the alarm clock to expire, the CM 104 temporarily stores any voice media received by the

ES 2 396 683 T3 media channels of a network from the CD 352 that has sent the pending PTT request 852, and eventually sends a corresponding PTX grant response 868. After the wake-up time 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 buffered voice media. If the CM 104's internal voice buffer is consumed before the wake-up time 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 can transmit the contents of its speech buffer to the network after the alarm clock has expired. Once the alarm clock has expired, network operation continues 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 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 idle state 604 as long as no network participant requests PTT 608 or is granted turn control (612) and the network is not dormant (616). CM 104 resets suspend time timer 620 to zero 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 the idle state 604 to the dormant state 624 when the time-out timer expires.

CM 104 transitions from grant state 612 to idle state 604 and sends a denial response 626 from PTX 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 after 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. The user is typically 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 while remaining in the talk state 636. If the network media buffer is not empty, the CM 104 continues to buffer the received media from the current network speaker while broadcasting the 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 participant and the current speaker are identical, the PTX grant message 668 was lost and the current speaker is resending their PTT request 644. The CM 104 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 participant a PTX deny message 672 if the arbitration algorithm pronounces in favor of the current speaker. CM 104 transitions from arbitration state 656 to grant state 612 and sends a PTX interrupt message 676 to the current network speaker 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 recovery state 664 to the failsafe announcement state 680.

ES 2 396 683 T3 release and sends a PTX denial message 688 to the current speaker immediately upon entering the failsafe recovery 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 the dormant state 624 to the dormant state 616 and sends a ZZZ message 696 announcing that the network has entered dormancy to all network participants immediately upon entering the dormant state 616. The network state machine remains in sleep state 616 as long as no network participant requests turn control. The CM 104 transitions from the sleeping state 616 to the wakeful state 700 when a PTT request 704 is received from a network participant.

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

The CM 104 remains in the awake pending state 712 as long as no PTT request message 720 is received from a network participant, an alarm clock 724 has not expired, and the PTX sleep response timer 728 has not expired. The CM 104 resets the alarm clock 724 and the PTX slumber response timer 728 upon entering the awake pending state 712. The CM 104 transitions from the awake pending state 712 to the sleep-arbitration 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 awake-pending state 712 to a sleep-grant state 736 when the network wake-up 724 expires. The CM 104 transitions from the awake pending state 712 to a temporarily stored grant state 740 when the PTX slumber 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 sleeping-arbitration state 732 to the awake-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 sleeping-arbitration state 732 to the awake pending state 712, sends the pending speaker the PTX denial message 744, and considers the interrupting party to be the new pending speaker from the network if the algorithm of 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 buffered grant state 740 to a buffered state 752 and sends a PTX grant response 756 to the network pending speaker immediately upon entering the buffered grant state 740. The network state machine remains in the buffer state 752 as long as the alarm clock 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 announcement state 628 when the alarm clock 724 expires. The CM 104 temporarily stores all media traffic received from the speaker pending from the network in the network media buffer while remain in temporary storage 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 otherwise ignores the request.

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 to a boot state 804 after CD 352 accepts the session description from the network by sending a SIP ACK message 808 to CM 104. The CD 352 transitions from the boot state 804 to a boot-wait state 812 and sends an ASK request message 816 to the CM 104 immediately upon entering the boot state 812.

The CD 352 remains in a listening state 820 as long as the user does not press the push-to-talk button 824, no PTA message 828 is received from the CM 104, and no 832 ZZZ message is 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 832 ZZZ message is received

ES 2 396 683 T3 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 state 836 shift request.

The CD 352 remains in the wait-for-turn state 848 as long as no PTX response message 856 is received from the 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) after 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 PTX grant response message 868 is received from the CM 104. The CD 352 transitions from the wait-for-turn state 848 to a turn-lost state 872 when the PTX deny message 856 is received from the CM 104. The CD 352 remains in the wait-for-turn state 848 and relays an identical PTT request 876 to the CM 104 after its PTT Retransmission Timer expires. The CD 352 transitions from the wait-for-turn state 848 to the listening state 820 after its PTT Abort Timer 860 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 awaiting a response from PTX.

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 shift lost state 872 to the listening state 820 and alerts the user 892 with a message indicating that control of the network shift has been lost immediately upon entering the shift lost 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 confirm 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 after 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 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. The CD transitions from awaiting release state 896 to listening state 820 after its 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 can indicate that a new speaker is in control of the turn, that the current speaker has released the turn, or that no speaker is currently in 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 sleep 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.

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

Upon receipt of a 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 politely terminate its participation in the network (944).

ES 2 396 683 T3

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

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

The CD 352 allows the user to originate and receive point-to-point calls from the conventional PSTN, as well as participate in group service discussions. Although the CD 352 may function internally in one of several modes, the CD 352 avoids restricting certain functionality within the context of the various operating modes that are required of the user to explicitly navigate. Thus, 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 secure point-to-point packet voice calls at any time, whether group services are active or not, as long as the CD 352 is not operating simultaneously. like a speaker. If CD 352 has registered as a member of a network, CD 352 is unsubscribed 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 has been completed, the CD 352 can transparently enable packet data service and re-register as a member of the currently selected network.

The CD 352 can be used to receive secure point-to-point packet voice calls, or from the PSTN, while group services are enabled, within the limitations imposed by the cellular infrastructure. If CD 352 joins a network, and the selected network is active, CD 352 appears busy for an incoming call from the PSTN and the call is given proper occupancy treatment by the cellular infrastructure. If the selected network is idle but the network suspend time 620 has not expired, the call is also given normal occupancy treatment by the cellular infrastructure. However, if the suspend time 620 of the selected network has expired, the network has been put into sleep mode 616, and the CD 352 has released its resources over the air, the call may not be given occupancy treatment by of the infrastructure and the CD 352 can be paged to initiate the 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 AYT requests. Whenever the CD 352 appears busy for an incoming voice services call, the caller is redirected based on whatever busy treatment has been defined for the called CD 352 (such as call forwarding, voicemail , etc.) by cellular infrastructure, as expected. A user can optionally configure the CD 352 to disable the reception of incoming point-to-point calls as long as a network is selected and the CD 352 is registered 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 INVITES itself to the network, as discussed with respect to Fig. 11.

For example, a roaming CD 352 can switch cellular systems or cellular networks and thereby negotiate a new IP network address. Or, the CD 352 may experience a service disruption or drop the packet data service option call for any reason and, after service is restored, 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.

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

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 the IS-707.5 standard and, if the

ES 2 396 683 T3

QNC is available, treats the connection as a packet data service option connection with no dormancy, or optionally without CRTP header compression support.

Under Mobile IP, the CD 352 connects to the network using a foreign agent, which assigns the mobile an address of the wing-attention-of type. The to-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 to-care-of address to contact your domestic agent and inform them of the current address of the mobile, of the to-care-of type. After confirming the identity of the mobile, the home agent sends packets addressed to the permanent home address of the mobile (which normal Internet routing mechanisms deliver to the home agent directly or to the home agent's network), to the mobile using the mobile address. mobile of the type-to-attention-of.

Although NBS can operate over Mobile IP, Mobile IP can potentially adversely affect end-to-end latency and perceived voice quality of NBS media traffic and signaling. This may be of particular importance if the CD 352 joins a network using its permanent address and the home agent is located far away, in the sense of a network topology, from the CM 104 and the CD 352. In such a case, the media traffic can optionally be routed over the public Internet or other networks of varying quality of service, which may not have been required if the Mobile IP was not used. To avoid this, it is preferable for the CD 352 to access NBS services using its at-attention-of type address and rejoin the networks when its at-attention-of type address changes.

Both SIP call signaling and PGP public key encryption use a unique CD 352 user identifier, or similar unique identifier. The user database 232 defines an internal user identifier, which can be referred to, and used by, the 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 existing authentication mechanisms of the 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 PGP public 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 prevent CD 352 from being tampered with, CM 104 may optionally request that CD 352 authenticate itself before registering or joining a network. Authorization is done at the application level, regardless of other authorization schemes that may exist at the network or cellular infrastructure level. CD 3532 authorization is also implemented, and works, regardless of 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 allows the SIP message to be signed by CD 352 using PGP public key cryptography signatures.

Public key cryptography generates a public and private key from a private secret, usually known only to the encryptor (in this case, the CD 352). The private key, in combination with the secret, is required to sign a message, but the public key alone can be used to verify a signature of a signed message. Thus, to support SIP authorization, each CD 352 is preferably provided with a private secret and a private key, which are never shared. Each CM 104 to which the CD 352 may need to authorize itself 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's SIP server (see FIG. 3) to provide authorization credentials, rejecting all requests that are not authorized. When server-level authorization is enabled, only clients whose identities (ie, a client's public key) are previously known to CM 104 can effectively use the server. Authorization at the server level can protect CM 104 SIP server 236 from many relatively easy denial of service attacks.

A CM 104 can protect one or more networks that it manages through authorization, but leave other networks "unprotected". If CD 352 tries to INVITE itself to a secured network, CM 104's SIP server 236 rejects the request, unless CD 352 can be authorized by CM 104.

ES 2 396 683 T3

Additionally, CM 104 can use authorization to ensure that CD 352 (or any SIP user agent client in general) does not attempt to disguise itself as another CD 352 and thereby deny service to legitimate network participants or passively monitor channels. media on a network. If the CM 104 requires that a specific CD 352 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 on a user-by-user basis (ie, the CM 104 can require certain users to be authenticated first, while allowing other users to remain unauthenticated).

The PGP public key can be administratively endowed, 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 users part of the database 232 of any SIP server that requires authentication of the CD 352.

In one embodiment, the primary NBS CD 352, or network participant platform, is a cellular handset based on Multiple Access on the CD 352. Because the NBS is built on top of the IP and IP transport protocols, Any IP-enabled platform with connectivity to the CM 104 can potentially serve as an NBS CD 352. Consequently, dial-up users can connect to the CM 104 via the PSTN, through existing IP terminal servers operated by Internet Service Providers (ISPs), as illustrated in Fig. 1. The Terminal server acts as a bridge between the PSTN and a LAN that supports IP. The terminal server comprises a bank of modems, which provide 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 interface on the LAN. The CM 104 includes a commercial terminal server out of the box (or deployed in conjunction with an external one).

The dial-up terminal server supports and includes the ability to negotiate CRTP Header Compression over its 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 over high-speed modems, the inability of a dial-up user to negotiate CRTP Header Compression may not necessarily force a network to avoid using payload-based specifications. on the RTP.

If the terminal server is located in the internal LAN of a Multiple Access service provider of a CD 352 and therefore close, in a network topology sense, to the service provider's CM 104, the users of the Dial-up connection 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 do not typically support a concept of torpor similar to that implemented by the IS-707.5 standard, dial-up based network participants ignore all sleep messages received from the CM 104. Although the user database 232 tracks whether a connecting user is cellular or terrestrial based, this facility is provided as well. Consequently, the CM 104 may or may not send sleeping messages or other media signaling messages to users of the network. telephonic conection.

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

In an integrated service implementation of the NBS, it may be preferable to allow any CM 104 to assume ownership of a network. Thus, the operation of a network is not specific to a particular CM 104 or 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 able to redirect any CD 352 to the appropriate MCU's SIP user agent server, and / or, if necessary, forward the CD 352 to another redirect server on the YEP.

In an integrated implementation of NBS services, the network address of a network makes sense throughout the entire length of the NBS system. As a result, one or more top-level SIP servers 236 are responsible for redirecting INVITE requests and distributing network participants to nodes 208 of the appropriate MCU. Top-level SIP servers 236 can share a common user and network database 232, providing similar functionality and redirection decisions at different network rendezvous points. As a result, redirection of invites originating from 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 396 683 T3

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

The process by which a CD 352 is incorporated into a network in such an integrated 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 the server 236 SIP redirect top level (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, redirection server 236 can exchange additional messages with MCU 252 via inter-application messaging, using implementation-specific protocols and / or messaging 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 every legitimate INVITE request it receives. One embodiment has the existing SIP records on the top-level redirect server 236. In addition, the top-level server can query the system database and try to associate each invitation request with a network definition contained therein.

The CD 352 can offer broadcast encrypted network communications. At the option 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 capable CD. The choice of whether a CD 352 treats a network as encrypted or unencrypted is left to the discretion of the network users; 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 on 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. The user is therefore 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 by 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 on a specific network, until new keys are generated and distributed to network users, to replace the old TEK on the network.

CD 352 is notified that it is a member of a specific network via 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 allow the user to enter the TEK of the network from the CD 352, regardless of whether or not an encrypted advisory indicator for the network has been received. by CM 104.

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

Once a key is successfully entered for a given network, media transmissions on the network are encrypted using that specific key, and all traffic received by the network is decrypted using that specific key. Encrypted traffic includes additional headers that allow the CD 352 to synchronize the encryption / decryption process, to allow 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 encryption headers) on a network that it has 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 on a network for 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 to the user and

ES 2 396 683 T3 mutes the traffic.

The key for an encrypted network can simply be a random (binary) number. In general, the key is generated by a participant on a network, or an administrator for that network, and distributed securely to the participants on the network. Since the key distribution policy is currently left to network users, it is a potential source of compromise of network security. Therefore, it is recommended that the network encryption key be distributed using secure means, such as encrypted email from PGP, to network participants. The security manager 20 (FIG. 1) also provides a central repository for common network keys. Other procedures are also possible, such as a standard phone call or a face-to-face meeting. Keys can also be automatically distributed to CDs, using an embedded secret key from PGP in a communication device for SIP authentication.

The preceding description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. The various modifications of these embodiments will be immediately apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of inventiveness. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is to be granted the widest scope consistent with the novel principles and features disclosed herein.

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