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

The present invention relates to a point-to-multipoint communication system. In particular, the present invention relates to devices and methods for enabling group communication services using standard Internet protocols in existing communication systems.

Point-to-multipoint communication systems are typically used to provide central location in a system and communication between multiple users. For example, a transmission system using Land Mobile Radios (LMRs) is a truck, to communicate planned information between a central transmission center and one or more corresponding fleet vehicles. It has been used in taxis, buses, and other vehicles. Communication may be directed to a specific vehicle in the fleet, or to all vehicles at the same time.

Another example of a point-to-multipoint communication system is a wireless push-to-talk system. These systems allow groups of individuals, each having a wireless communication device to communicate with other members of the group. Typically, push-to-talk systems rely on a single frequency, the channel provided on which communication is received by the wireless communication device. In most systems, only one member at a time will be able to send information to other members. However, it is possible for all members to hear the provided broadcast channel for receiving communications from one member transmitting. Members wishing to send to other members of the system typically request access by pressing a push-to-talk button on their respective communication device, which allows the user to access the provided channel alone. Is sent.

Push-to-talk systems are typically used in outdoor settings where people, or groups of members, want to communicate with each other in a "point-to-multipoint" fashion. Examples of push-to-talk systems are used to include workgroup communications, security communications, construction site communications, and local military communications. A group of people who want to communicate with each other is usually known as a "net", and each member of the net is sometimes referred to as a "net member".

In a typical push-to-talk system, the provided channel, sometimes referred to as a broadcast channel, is used to simultaneously transmit communication from one member to multiple other members of the net. The provided channels can include one channel or frequency, or a group of individual channels governed by a controller for simulating one channel. In any case, only one member can transmit voice and / or data communication to other member users at any given time. If another member attempts to transmit on the broadcast channel while another member is transmitting, there will be interference between the two competing communications and the communications being received by the other net member will be It will come down to being confusing.

In the current wireless communication system, in order to implement the push-to-talk communication system, a large amount of modification to the core facility is usually required.

Aside from the high cost combined with current wireless point-to-multipoint communication systems, communications are generally limited to members operating very close to each other using the same or similar technologies. There is. In other words, point-to-multipoint communications include other communications networks or technologies such as the Public Switched Telephone Network (PSTN), data networks such as the Internet, or Global Star satellite communications systems. It does not extend to satellite communication systems.

Therefore, the present invention is a push-to-talk communication device for participating in a group communication net. The group communication net includes an interface between a control and a push-to-talk communication device for controlling the group communication net. The processing device converts the information signal into packet data suitable for transmission to the distributed network. The processing device may also have identification information, and updates the identification information when the current identification information is to be changed or is about to be changed. The processor then sends the new identification information to the controller. The push-to-talk device also includes a transmitter for transmitting packet data to the control via the first channel. The receiver receives the packet data via the second channel from the control. Push-to-talk devices also include a user-activated mechanism for performing transmission when the user of the communication device wishes to transmit packet data to its control.

In one embodiment, the communication device is a wireless communication device. The communication device may further include a memory for storing the packet data until the control is ready to receive the packet data. Memory is used to minimize the user's perceived wait time. The processor may also include dynamically configurable priority levels. Therefore, the priority level is whether or not the communication device has the authority to obtain the communication right over other communication devices so that the communication device can interrupt the transmission of the communication device having the lower priority level. To determine. In addition, the processor may receive information from the controls on the group communication net, such as who is on the net, how many are on the net, and where their users are located.

The communication device can also operate in safe mode. The processing device may also contain identification information. The processing device updates the identification information when the current identification information has to be changed or is about to be changed, and sends the new identification information to the control.

The group communication net can also be in hibernation mode. Activation of the user activation mechanism encourages the control to take the communication net out of hibernation mode.

The communication device contacts the communication manager. The communication manager includes a first node for establishing a first channel with a first communication device. At least one second node establishes at least one second channel with at least one second communication device. The channels that connect a communication device to a control or communication manager include a Signal Initiation Protocol (SIP) channel, a media signal channel, and a media traffic channel. A control, also known as a communication manager, electrically connects a first node to at least one second node. The control also includes a database module. The database module contains identification information for each communication device in the group. The control can be dynamically configured such that any one communication device in the group can send packet data to other communication devices in the group via its respective channel. In one embodiment, the packet data includes time-sensitive information. In another embodiment, at least one of the communication devices is a wireless communication device.

The controller further includes a core module and a net, i.e. an MCU module. The core module and its net module are connected to the distributed network. The core module establishes an identity for each communication device and redirects information from the communication device to the net module. The net module handles and controls the information transmitted between groups of communication devices. In one embodiment, the database module is part of the core module. The core module also includes a billing log module. The billing log module stores the time course of activity between communication devices.

The net module also includes a local log module. The local log module stores the time course of activity between communication devices and transfers the compiled course to the billing log module. The controls also include top-level servers. The top-level server sends and receives packet data from the communication device. Packet data includes information such as identification data about the communication device, location data of the communication device, and control data for establishing, modifying, or terminating group communication.

The controller further includes a first timer that measures the first elapsed time. If none of the communication devices have sent information to the control before the lapse of time, the control sends a message to each communication device to enter hibernation mode. The controller also includes a second timer that measures the second elapsed time. If none of the communication devices have sent information to the control within a preset time, the control will determine if the communication device wants to remain active. A message is sent to each communication device for the purpose of eliciting a response from.

The control also includes an arbitrator for assigning priority levels to each communication device. The priority level determines the hierarchy of transmission privileges of the communication device so that the communication device with the higher priority level can interrupt the transmission of the communication device with the lower priority level. Priority level assignments can be set dynamically.

The control further includes a buffer memory that stores the packet data until the communication device is ready to receive the packet data. Buffer memory is used to minimize the user's perceived wait time.

Communication devices can operate within the same net, even though they operate within different communication backbones, including, but not limited to, CDMA, TDMA, and GSM®.

Therefore, providing end-to-end voice communication using the Internet Protocol is a feature and advantage of the present invention.

Providing wireless end-to-end voice communication using the Internet Protocol is another feature and advantage of the present invention.

It is another feature and advantage of the present invention to provide wireless push-to-talk communication to a group of participants transmitting voice as packet data using the Internet Protocol.

It is another feature and advantage of the present invention to provide a push-to-talk system on an existing communication backbone without the need to modify the existing underlying communications backbone.

It is another feature and advantage of the present invention to be able to send and receive voice data to and from a group of wired or wireless communication devices using the Internet Protocol.

Providing a hibernate mode for an inactive push-to-talk net is another feature and advantage of the present invention.

Providing a communication manager to control and control one or more push-to-talk nets is another feature and advantage of the present invention.

Providing a media control unit provided for a particular push-to-talk net is another feature and advantage of the present invention.

It is another feature and advantage of the present invention to provide complete duplication in packet data.

Providing a signaling channel to set up and maintain a push-to-talk net is another feature and advantage of the present invention.

Providing voice security in Internet Protocol transmission is another feature and advantage of the present invention.

Providing a detailed time course of processing within a push-to-talk net is another feature and advantage of the present invention.

Granting access priority over other users of Push-to-Talk Net and giving mediation that allows one or more users the primary authority to send voice or data It is another feature and advantage of the present invention.

Minimizing the perceived wait time for users of push-to-talk nets is another feature and advantage of the present invention.

Allowing the communication device to drop data frames in order to minimize the wait time is another feature and advantage of the present invention.

It is another feature and advantage of the present invention that the communication device is allowed an anticipatory permission on the request in order to minimize the wait time.

It is another feature and advantage of the present invention that any user buffers audio data until a given user is ready to receive the data.

Allowing a user to multicast over one forward channel to multiple listeners is another feature and advantage of the present invention.

It is another feature and advantage of the present invention to allow a communication device to recognize and report that its identification address is to be changed or is about to be changed.

Encouraging the user to determine if the user is an active part of the push-to-talk net is another feature and advantage of the present invention.

Allowing the user to switch between multiple push-to-talk nets is another feature and advantage of the present invention.

Allowing the user to dynamically determine the members of a given push-to-talk net is another feature and advantage of the present invention.

It is another feature and advantage of the present invention to give the user a list of potential push-to-talk nets that the user may combine.

It is another feature and advantage of the present invention to give a user geographical and other user-specific information about other users of Push-to-Talk Net.

<figref num="1">Figure 1 illustrates an internet broadcasting system.</figref><figref num="2">Figure 2 illustrates the NBS net and how communication devices interact with Communication Manager (CM) 104.</figref><figref num="3">FIG. 3 illustrates a functional block diagram of the CM.</figref><figref num="4">FIG. 4 illustrates an example of the NBS SIP signal protocol stack.</figref><figref num="5">Figure 5 illustrates the NBS media signal protocol stack.</figref><figref num="6">FIG. 6 illustrates a real-time protocol voice media protocol stack.</figref><figref num="7">Figure 7 illustrates the UDP audio media protocol stack.</figref><figref num="8">Figure 8 illustrates the media traffic protocol stack.</figref><figref num="9">Figure 9 illustrates the DNS client protocol stack.</figref><figref num="10">Figure 10 illustrates the high-level features of the CD Group Service Module 500.</figref><figref num="11">FIG. 11 illustrates SIP call signaling 350.</figref><figref num="12">FIG. 12 illustrates a media signaling message sequence.</figref><figref num="13">FIG. 13 illustrates a sequence of media signaling messages for hibernation.</figref><figref num="14">FIG. 14 illustrates a sequence of NBS media signaling messages.</figref><figref num="15">FIG. 15 illustrates a state diagram of the CM104.</figref><figref num="16">FIG. 16 illustrates a state diagram of the CD352.</figref>

Detailed explanation

The features and advantages of the present invention will become more apparent in the context of the drawings from the detailed description described below. Similar reference numerals are found to be the same throughout the drawings.

The Net Broadcast Service (NBS) system allows Internet Protocol (IP) communication devices to participate in group voice and data conferencing. NBS is essentially a voice over IP (VoIP) application. Voice communication is transmitted from the talker endpoint communication device to one or more listeners by encapsulating voice frames in IP datagrams. Data with audio may also be transmitted in this way. The NBS system is a U.S. patent application of Attorney Docket No. 000212, filed March 3, 2000, entitled "Methods and Devices for Providing Group Communication Services in Existing Communication Systems." A US patented application serial with serial number 09 / 518,985 and agent processing number 000211, submitted March 3, 2000, entitled "Methods and Devices for Participating in Group Communication Services in Existing Communication Systems". It is described in numbers 09 / 518,776, and they are expressly incorporated into this patent by reference.

FIG. 1 illustrates a functional block diagram of the group communication system 10. The group communication system 10 is also known as a push-to-talk system, a net broadcasting service (NBS), a dispatch system, or a point-to-multipoint communication system. A limiting characteristic of such an NBS system is that, typically, only one user can send information to other users at any given time. In NBS10, groups of communication device users, individually known as net members, communicate with each other using the communication devices assigned to each net member.

The term "net" refers to a group of communication device users who are authorized to communicate with each other. A central database typically contains information that identifies each particular member of the net. One or more nets may operate within the same communication system. For example, the first net may be defined as having 10 members. And the second net may be defined as having 20 members. The 10 members of the first net can communicate with each other. But usually not for members of the second net. In other situations, members of different nets can monitor communication between members of one or more nets, but can only send information to members in their own net. Is.

The net operates on existing communication systems without the need for partial changes to existing mission-critical facilities. Therefore, net controls and users can send and receive packet information in code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, and global systems for mobile communications (GSM®). )), Satellite communication systems such as Globalstar or Iradium, or any system such as various other systems that operate using the Internet Protocol (IP). Will.

Net members communicate with each other using the assigned communication devices, designated as Communication Devices (CDs) 12, 14, 16, and 17. CDs 12, 14, 16 and 17 include wireless phones on earth, wired phones with push-to-talk capabilities, satellite phones with push-to-talk capabilities, wireless video cameras, still cameras, music recorders or players, etc. It can be a wired or wireless communication device such as an audio device, laptop or desktop computer, a paging device, or any combination of these. For example, CD12 may include a wireless earth telephone with a video camera and display. In addition, each CD may be capable of transmitting and receiving information in either safe or unsafe (clear) mode.

Through the discussion below, references to each CD may be represented by wireless push-to-talk telephones. However, it should be understood that references to CDs are not intended to be limited to this, as other communication devices capable of transmitting and receiving packet information according to the Internet Protocol (IP) May be included.

In the NBS system 10 of FIG. 2, transmission privileges are typically defined as allowing one user to transmit information to other net members at any given time. The send privilege is granted or denied to the requesting net member when the request is received, depending on whether the send privilege is currently assigned to another net member. The process of allowing and denying a request to send is known as mediation. Other mediation schemes evaluate factors such as the priority level assigned to each CD in determining whether the requesting net member is granted transmission privileges.

To participate in NBS system 10, each of CDs 12, 14, 16 and 17 has the ability to request transmission privileges from the control or communication manager (CM) 18. The CM18 usually controls the real-time and administrative operations of the net. CM is any form of computer-type device that has at least one processor and memory. In one embodiment, CM is Sun Workstation Netra T1®.

CM18 keeps a list of defined nets defined as either clear or safe. A transition between clear and safe is usually unacceptable. The secure net relies on the cryptography provided by individual CDs to provide protection against authentication and eavesdropping. Encryption for a secure net is performed on an ent-to-end basis, which means that encryption and decryption are done on each CD. CM18 generally operates without knowledge of security algorithms, keys, or policies.

The CM18 controls remotely through the communication system service provider, the net member, or both, assuming that the authentication is given by the service provider. The CM18 may receive the net definition via the external management interface 226. A net member may request administrative activity via a management net function via its service provider or a defined system such as Member Operations Security Manager (SM) 20 that conforms to the CM18 management interface. CM18 can authenticate any party attempting to establish or modify the net against high-grade commercial standards.

The SM20 is a selectable component of the NBS System 10 that performs related tasks to support key management, user authentication, and secure nets. Single group communication systems may interact with one or more SM20s. SM20 is usually not involved in net activation or real-time control of the net, including PTT arbitration. The SM20 may have management capabilities to automate management functions that match the CM18 interface. The SM20 may also have the ability to act as a data endpoint for the purpose of joining the net, broadcasting net keys, or simply monitoring net traffic.

In one embodiment, the means of requesting transmission privileges from a CD includes a push-to-talk (PTT) key or switch. If a user in NBS10 wishes to send information to another net member, the push-to-talk switch on that person's CD will be pressed and CM18 will send a request to gain transmission privileges. To do. If no other net member has been assigned transmit privileges at that time, the requesting user will be granted transmit privileges and will be able to hear, hear, or tactile via the CD. Will be reported. After the requesting user has been granted send privileges, information may then be sent from that user to other net members.

In one embodiment of the invention, each radio net member establishes forward and reverse links with one or more base stations 22 or, in some circumstances, satellite gateways 24. Base station 22 is used to describe the communication channel from base station 22 or satellite gateway 24 to the CD. The satellite gateway 24 is used to describe the communication channel from the CD to base station 22 or gateway 24. Voice and / or data is converted into data packets using a CD. The data packet is suitable for a particular distributed network 26 through which communication to other users is taking place. In one embodiment, the distributed network 26 is the Internet. In other embodiments, the provided forward channels are established within each communication system (ie, earth and satellite communication systems) to broadcast information from each net member to another net member. Will be done. Each net member receives on the channel provided with communication from other net members. In yet another embodiment, the provided reverse link is established within each communication system to transmit information to CM18. Finally, a combination of these methods may be used. For example, one method establishes a forward broadcast channel provided, but requires wireless CDs to transmit information to CD18 over the individual reverse links assigned to each CD. May be doing.

If the first net member wants to send information to other members of the net, the first net member requests send privileges by pressing the push-to-talk key on that person's CD. To do. It then generates a formatted request for transmission to the distributed network 26. For CDs 12, 14, and 16, the request is transmitted wirelessly to one or more base stations 22. The Mobile Exchange Center (MSC) 28 is a well-known inter-working function for processing data packets containing requests between the MSC 28 and the distributed network 26. Includes function) (IWF). For CD16, the request is sent via satellite to satellite gateway 24. For CD17, the request is sent to the Public Switched Telephone Network (PSTN) 30, where it goes to Modem Bank 32. Modem bank 32 receives the request and feeds it to the distributed network 26. The 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, it does not need to be geographically close to the net participants.

If the send privilege request is received by CM18 and no other member currently holds the send privilege, the CM18 is requesting a message notifying that the send privilege is granted. Send to members. Audio, visible, or other information from the first net member can be sent to CM18, where it uses one of the transmission paths just described for the other net member. May be sent. In one embodiment, CM18 then gives information to the net member by copying the information and sending each copy to the net member. If a single broadcast channel is used, the information needs to be copied only once for each broadcast channel used.

In an alternative embodiment, the CM18 merges into the MSC28 so that data packets from supporting base stations are delivered directly to the CM18 without being delivered over the distributed network 26. Has been done. In this embodiment, the CM18 is still connected to network 26, which is distributed so that other communication systems and devices can participate in group communications.

CM18 stores one or more databases to control information about individual net members, as well as for each defined net. For example, for each net member, the database is the user's name, account number, phone number, or dial number combined with the member's CD, the mobile identification number assigned to the CD, and the member is active. Current member status on the net, such as whether you are on the net, a priority code to determine how outgoing privileges are assigned, a data phone number combined with a CD, an IP combined with a CD It may contain information such as an address and an indication of which net members are authorized to communicate with. Other relevant forms of information may also be stored by the database for each net member.

As part of the NBS backbone, the Communications Manager (CM) forms connections with each communications terminal to form a single talk group or net. CM includes various basic capabilities in hardware and software that can be configured in different ways to adapt different applications. In general, CMs are not only relative control of net state, but also (NBS) net, push-to-talk (PTT) request arbitration, maintenance and distribution of net members and registration lists, call setup and tier of required CDMA systems. Gives the ability to control real-time, administrative, and reliable behavior of tear-down and network resources.

NBS Net may be in a standalone deployable cellular system, or in a large multi-site configuration. For large configurations, multiple CMs may be geographically deployed to form a single integrated system, each acting as a plug-in module into an existing cellular backbone. To do.

In this way, the new features introduced by NBS Net are available to cellular users without the need for modification to existing cellular backbone facilities.

The function of CM is to store a list of defined NBS nets. Each net definition is a list of members, including net identifiers, telephone numbers or other identifying information, user priority information, and other general administrative information. The net is statically defined as either clear or secure. And the transition between clear and safe is not allowed. Secure NBS nets typically use media cryptography to provide protection against authentication and eavesdropping. Media encryption for a secure net is performed on an end-to-end basis, which means that encryption and decryption are occurring within the communication device. CM works without any knowledge of cryptographic algorithms, keys, or policies.

The CM receives the net definition through an external management interface. Customers may request administrative activities via their service provider or through a management net feature such as a customer operation security manager that conforms to the CM management interface via a defined system. CM certifies to any party trying to establish or modify the net with high-grade commercial standards.

Prior to a detailed description of one embodiment of the invention, the invention is not limited in its application to the details of the configuration and the arrangement of components as demonstrated by the following description or description in the drawings. That should be understood. Other embodiments are possible and the present invention can be accomplished in a variety of ways. Also, the expressions and terminology used herein are for illustration purposes only and should not be considered limiting.

Figure 2 illustrates how NBS Net 100 and communication devices interact with CM104. Multiple CMs 104 may be deployed towards the large scale NBS Net 100 as desired. In FIG. 2, the communication device 108, or CD 108, has permission to transmit media over the net. In this case, the CD108, known as a talker, transmits media over the channel. If CD108 is designated as a talker, the remaining net participants do not have permission for communication devices 112 and 116 (or CD112 and CD116) to send media to the net. Therefore, CD112 and CD116 are designated as listeners. If CD116 is designated as a talker, then CD108 and CD112 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, including Session Initiation Protocol (SIP) channel 120, NBS media signal channel 124, and media traffic channel 128. Session Initiation Protocol (SIP) Channel 120, and NBS Media Signal Channel 124, are used by either CD108, 112, and 116 whenever bandwidth allows, regardless of whether they are designated as talkers or listeners. May be done. SIP is an Internet Engineering Task Force (IP) that defines an application layer protocol that describes the control mechanism for establishing, modifying, and terminating multimedia sessions running on the Internet Protocol (IP). IETF). SIP determines the method for registering and locating users, the mechanism for defining user capabilities and describing media parameters, user availability, call setup, and call handling. By supporting this mechanism, it provides a general solution to call signaling problems for Internet telephone applications.

SIP channel 120 is used to start and end the participation of CDs in net 100. Freely, Session Descriptive Protocol (SDP) signals may also be used within SIP channel 120. When CD participation in the NBS net is set up using SIP channel 120, real-time call control and signaling between CD and CM104 is done using NBS media signal channel 124. In particular, among other tasks, NBS Media Signal Channel 124 provides push-to-talk requests and openness, mediation between conflicting requests, or floor control, announcements of start and end of information transmission, control of net outages, etc. Used to handle end-of-track connectivity, net state requests and exchanges, notifications and error messages. The NBS Media Signaling Channel 124 protocol minimizes the most common message lengths, understands responses, and simplifies the task of responding to requests, while maintaining adaptability for future enhancements. The protocol of NBS media signaling channel 124 also allows the request to be retransmitted without adversely affecting the protocol state.

Signal traffic on media channel 124 may be further divided into two types: call setup and control signaling, which inherently includes SIP invitation requests, and media signaling, which originally includes real-time floor control requests and associated asynchronous messages. Media traffic on media traffic channel 128 includes real-time point-to-multipoint audio and / or data broadcasting. Both messaging categories have unique functional qualities. In addition, each CD may submit a request to a Domain Name Service (DNS) client to facilitate the mapping of a fully stated DNS hostname to an Internet network address.

NBS call setup and call control signaling are performed according to SIP semantics. SIP may be transported using either the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). In a preferred embodiment, each CD uses UDP to perform SIP-based signaling functions, as shown in FIG. Each CM also expects to receive all SIP signaling via UDP. Real-time signaling occurs on CMs and their respective CDs via a dynamic UDP / IP interface. Other signaling may be done instead, using SIP, between CM and CD via a fixed (static) TCP / IP interface.

Figure 3 shows the module and physical make-up of CM104. The CM 104 includes a CM core module or complex 204, at least one net module, or media control units (MCU) 208 and 212, DNS server 216, redirect server 220, and management workstation 224. CM Core Complex 204 provides Java®-acceptable management capabilities for web browsers. One or more DNS servers 216 may also be included within the CM core complex 204. The CM core complex 204 further includes a CM node 228 and a database server 232. The CM104 is separable into at least two parts, the CM core complex 204 and each MCU node 208. After the initial connection to the CM core complex 204, the net is driven by MCU node 208. The MCU node 208 sends and receives information from the CM core complex 204, if necessary. The separability of the CM core complex 204 takes into account the versatility of the net being operated by the provided MCU node 208 once a particular net has been established. This allows the CM core complex 204 to provide an initial connection with other potential nets, regardless of the form of communication structure in which the nets want to operate. The CM core complex 204 may also be repositioned from the MCU node 208. For example, one single CM core complex 204 may be located in the central part of the United States. And multiple MCU nodes 208 may be located in rural areas to operate the net from that given area. As such, the CM core complex 204 may deliver the user to a particular MCU node 208 based on the user's location. Information may also be given to a user or group of users based on location, such as location-based broadcasting, command, or landmark identification.

CM node 228 provides centralized functionality combined with NBS net. CM node 228 includes session initiation protocol user agent server (SIP UAS) server 236, CM manager 240, central billing log 244, and management server 248. SIP UAS server 236 supports user requests for netlists and processes SIP byte messages for nets. When the SIP byte message 229 is received from the communication device, the net assigns the communication device to the appropriate MCU node 208 and directs the communication device to the MCU node 208.

CM Manager 240 monitors the status of all MCU nodes in the net and assigns net execution to a given MCU node, such as MCU node 208. CM Manager 240 creates and deletes nets, defines new ones, deletes existing users, adds and removes them as net members, and various operating parameters on a user, net, or CM wide basis. Handles management functions related to net management, including coordinating.

Central billing log 244 stores time and identification information for billing purposes. The central billing log receives billing log information from the local log server 260 on MCU node 208. Detailed log information of each user is stored on the net, such as which communication device is active, how long, where, when, and how long each CD is a talker or listener. Will be done. The management server 248 supports the management workstation 224 through the net state interface 280 to retrieve state information and initiate database management and system control functions.

The CM runs both the SIP user agent server 236 and the SIP MCU server 252. To support NBS, each CD runs a SIP user agent client. The CM receives the incoming SIP connection on the advertised node or port. When a connection occurs, SIP server 236 receives and processes the request according to the SIP call signaling convention. The SIP server 236 can handle multiple call signaling connections in parallel.

To store network resources, the CD can open a UDP connection with its SIP server 236 after the connection has successfully (or unsuccessfully) combined with NBS Net 100. UDP connections may later be reinstated to send additional SIP call signaling requests (eg, leaving the net or switching to another net).

Figure 4 shows NBS An example of the SIP signaling protocol stack 300 is shown. A stack is a collection of protocol layers that perform network communication. The protocol combined with each layer communicates with the layers immediately above or below it. And assume support for the lower layers. Since UDP is an unreliable, unconnected transport, application-level reliability can be selected to ensure reliable communication. And that is achieved by execution by the SIP compliant endpoint. SIP call signaling 302, typically on UDP stream 304, is encapsulated within IP protocol 306. No special formatting is required. SIP call signaling IP packet 306 is exchanged with, for example, a CDMA cellular-based CD encapsulated in point-to-point protocol (PPP) frame 308, or a dial-up PSTN-based CD. Will be done. Therefore, no special formatting is required. Also, SIP call signaling PPP frame 308 is exchanged between CDs based on CDMA cellular, and the base station is encapsulated within Radio Link Protocol (RLP) 310. For dial-up PSTN-based users, a suitable modem standard such as V.32bis or V.90 may replace RLP310. In either case, no special treatment is usually required and no error-free physical link is assumed.

Figure 5 shows the NBS media signaling protocol stack 312 using UDP datagram 304 over IP306 to transport voice and data traffic. NBS media signaling 314 is layered on UDP / IP traffic 306 and processed in a manner similar to that described in Figure 4.

FIG. 6 shows the real-time, voice media protocol stack 320. In this embodiment, the vocoder payload data 322 is layered on top of Real Time Protocol (RTP) 324. RTP324 is then layered on top of UDP304 and IP306. In a selectable embodiment, the compressed real-time protocol (CRTP) header compression 330 is used at the application layer to further encapsulate media traffic with the RTP 324. Header compression techniques may apply to all UDP / IP inbound and outbound UDP / IP traffic shown in Figure 4-9 as appropriate. Media signaling requests and responses are encapsulated within UDP datagrams. When available, CRTF header compression may be applied to reduce the strong 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 Figures 4, 5 and 7-9, CRTP320 compresses layers between UDP 304 and PPP 308, and containing them.

In operation, each CD dynamically selects a UDP port with the intention of listening to NBS media signaling requests on it when attempting to combine with the net, and it delivers. Communicate its port number to SIP server 236 as part of your SIP invitation. The net CM media signaling destination address (including the UDP port number) is stated in the net session description delivered as part of the response to a successful SIP byte request to the CD. Otherwise, the SIP signaling address and media signaling destination address are net-specific and may change when the CD is connected to the net. Multiple nets hosted by the same CM usually operate independently and do not distribute media signaling or media traffic ports. However, it is expected that multiple nets may distribute media signaling and media traffic ports.

With reference to FIG. 6, voice traffic is encapsulated within RTP / UDP 324 or UDP payload 304 by grouping into one or more vocoder frames. Using RTP324 with the enabled CRTP330 is used to minimize end-to-end media latency and provide collaborative workability with IP telephony applications and services. In either case, when the CD dynamically selects a UDP that expects to receive media traffic on it and attempts to connect the port number to SIP server 236 with the net. Will notify you as part of the SIP invitation to deliver.

The net vocabulary and transport encapsulation protocols are described in the session descriptive response to a successful SIP invitation request from SIP server 236, as well as the media traffic destination address (including UDP port number). Like the media signaling address of the net, the media traffic destination address is net-specific and may vary between the stages of the CD associated with the net.

Typically, as shown in FIG. 6, voice traffic is encapsulated at the application layer with an RTP 324 that divides each UDP datagram 304 into an RTP header 324 and a vocabulary payload 322. FIG. 7 shows the UDP audio media protocol stack 332. Voice traffic may typically be purely encapsulated rather than RTP-encapsulated using UDP datagram 304 if CRTP header compression 330 is not available or is not supported by net members. Absent. Figure 8 shows the media traffic protocol stack 334. Media traffic protocol stack 334 is used for net participants that are not application-level RTP encapsulation. Data 336 is encapsulated within UDP datagram 304.

The structure of UDP payload 304 follows the definition given for the corresponding RTP payload 324 without the RTP header field. The decision to encapsulate the media directly in UDP 304 is set by the net administrator 248 and notified by the net session notification. In addition to audio media, NBS Net may also support arbitrary data broadcasting. If the net supports data broadcasting channels, the SIP server 236 will notify the media format in the net's SIP session description when the CD officially joins the net.

Figure 9 shows the DNS client protocol stack 338. Each CD contains the ability to decompose Internet domain names into Internet addresses using the Domain Name Service (DNS) protocol 340. The CD acts as a DNS client. As shown in Figure 9, the CD uses UDP 326 to encapsulate the DNS 340 request. In order for the CD to decompose the DNS host name, the CD must be prepared with the IP network address of DNS server 216, as shown in Figure 3. The DNS address is also freely configurable by the CD service provider and the user.

In addition to audio media, the net may also support arbitrary data broadcasting such as secure net rekeys, emails, data files, etc. If the net supports data broadcasting channels, the CM will notify the media format in the net's SIP session description when the CD officially connects to the net. Like traditional media broadcasts, general data broadcasts operate on RLP in one embodiment (ie, the corresponding physical layer). However, it is generally considered a more unreliable transport.

The CD includes the ability to decompose Internet area names into Internet addresses, as defined in RFC1034, using the area name service protocol. Instead, the CD acts as a DNS client or resolver, as described in RFC1035.

The CD is pre-programmed with the IP network address of the DNS server so that the CD decomposes the DNS host name. The DNS address can also be set by the CD service provider and freely by the user.

The CM104 may be freely configured to act as a DNS server 216. It (CD104) may use TCP as a transport protocol to respond to DNS requests from entities outside the area, but for the purposes of responding to requests that occur with the CD, SIP server 236 Also, according to FIG. 8, UDP 304 is used to encapsulate the DNS message.

NBS also benefits from the development of cellular multicast channels. These channels generally allow one transmitting station to have N listening stations directly on one forward channel without the need for N separate reruns of transmitted data. Allows you to address to. The presence of cellular multicast channels represents a change to the NBS media stack, which is inherently below the IP network layer. To benefit from the efficiency provided by cellular multicast channels, net media signaling and traffic destination addresses are traditional IP multicast channels, and CM-generated media signaling and traffic broadcasting are multicast broadcasts. Each CD-generated media signaling, traffic broadcast, and SIP signaling remains as point-to-point communication.

The Radio Link Protocol (RLP) 310, shown in Figure 4-9, has been modified in each CD to minimize the latency experienced when a link layer (RLP frame) is missing. May be. Such modifications are free and neither TCP nor UDP 304 assume a trusted network (IP) or link layer service, so they do not necessarily affect the operation of the application layer protocol transport.

Changes in the RLP310 fix are possible. For example, the RLP310 prompts the remote end to send multiple copies of the lost RLP310 frame after the initial RLP timeout, and improves the chances of a successful RLP310 recovery. May be modified to send multiple messages such as NAK responses. The RLP310 also allows missing RLP310 frames to be pushed to higher levels in the protocol stack to never send a NAK response (after the RLP timeout expires) and to cause errors. , May be fixed. All TCP-based application-level protocols use TCP's error recovery feature to perform regular recovery. Traffic that relies on UDP 304 for transport has already countered the potential for loss.

Returning to the reference in Figure 2, once the CD has established participation in NBS Net 100 using SIP channel 120, the CD is from Net 100 on media traffic channel 128, on the CD's specific media port. , Ready to send and receive media. If the CD gains floor control via media signaling, as in the case of CD108 in Figure 2, the CD sends the media to the destination network and transport address, as shown in the session description for Net 100. To do. The CD decodes the media received at its media port according to the vocoder and media formats defined in the session description for net 100 received in the byte response when the CD is combined with net 100. The CD encodes and encapsulates the media sent to Net 100 according to the vocabulary and media format defined in the Net 100 session description received in the Inbyte Response when the CD is combined with Net 100. ..

Each CD participating in the net is received from SIP server 236 of CM104, and from the session description approved during the SIP call setup, the destination network and transport address for each media channel are determined, and within net 100. Used to address the corresponding media sent to. Each CD provides a packet data connection to the CM. Changes in CD execution for this interface may be made to optimize NBS characteristics. Changes to the core facility side of this interface are usually not required. The CD may be free to support most NBS activities using QuickNet Connect (QNC), as described later.

For delivery to the service provider, CM Manager 240 makes basic administrative settings before supporting NBS activity. Initial settings include basic system settings such as assigning a password to an operating system level account for root level system management and configuring the CM Manager 240 network interface for normal operation on the local radio infrastructure network. There is.

Once CM104 is set, general net management can be performed. Net management functions are performed through HTML or other network interfaces formed on TCO / IP. The management workstation 224 interacts with the CM core complex 204 using a traditional World Wide Web (WWW) browser. Management can be done locally or remotely (anywhere on the Internet, or via dial-up). However, the lower transport route for management access is typically TCP / IP. Also, multiple (at least 3) simultaneous management connections are allowed.

In connecting to the CM Core Complex 204 for net management purposes, the management workstation 224 successfully authenticates itself to ensure that its own certified management behavior is accepted. The level of access has been adjusted. For example, an authorized net member may connect directly to the CM's management interface (248) to modify a particular net membership list. More general administrative privileges are generally stored for a particular administrative account. For the sake of clarity, management behavior is usually separated into those that deal specifically with user definitions and those that define nets. The user definition includes information such as the user name, unique CD cellular system identifier, CD phone number, and user email address. A unique user identifier is defined as one that will pass through the CD and be used to uniquely identify the user in the signaling message. The net definition contains information such as net address, net hang time, private dispatch timeout, and member list. The net member list contains information such as a list of member records containing individual user identifiers and priority levels. Numbers with the lowest level of priority typically have listen-only privileges.

CM administrator 248 may monitor the current state of the net for which they have administrative privileges. In particular, CM administrator 248 may determine the current list of net participants as well as monitor the state of the net (active, inactive, hibernate, wake up, etc.). Whenever the net is active, CM Administrator 248 may also monitor the current Talker's identity. Additional statistics and conditions, such as current session length, total talk time, and average number of registrants, may also be available to administrators through the management interface.

The management server 248 interface includes at least two network nodes or ports. One is a TCO / IP-based, current Java®-acceptable, hypertext transfer protocol interface that supports managed access via a web browser. The second is the NBS specific command lime interface (CLI) based on TCP / IP.

Management Server 248 uses Internet-readable media such as Hypertext Markup Language (HTML) syntax to provide one or more formatted pages available to common web browsers via the HTTP web server interface. Create all management functions with. At least one admin page may contain a reference to the extended Java® Appret. Some administrative functions may be freely performed through HTTP GET and POST commands issued by web browsers using the current HTACCESS authentication mechanism. The supported management features are usually a subset of those supported by the CLI interface.

The HTTP interface may be used to deliver Java® applets to web browsers. The applet may then rely on the management server 248 CLI interface to provide additional management capabilities to the user via the web browser interface. Potential management workstation 224 connecting to the management server 248 CLI interface is authenticated prior to being granted access to the CLI interface. In a preferred embodiment, the CLI interface is reachable to a well-known fixed TCP port address and can manage multiple CLI sessions at the same time.

Database server 232 is responsible for net information and parameters, net user information, state information combined with MCUs 208 and 212, and storage of CM node 228. Database server 232 also supplies this information to the rest of CM104, such as SIP server 236 and other modules that require such information. The database server 232 stores a database that captures information that supports the NBS net function, including the NBS net database part and the NBS user database part. Information that supports administrative functions and privileges may be stored in either database, or in a third functionally separate database. The database server may be further divided into a user part and a net part.

The CLI interface supports management functions such as CLI create user / net, delate user / net, modify user / net, list / show user, list / show net, status and help. The Create User feature allows Administration Server 248 to create new users in the user portion of the database, including defining all user record fields. The derate user feature allows management server 248 to clear existing user records in the user portion of database 232. The Modify User feature allows Management Server 248 to modify existing user records in the user portion of database 232, including modifying all record fields for a particular user. Tolerate.

The Create Net feature allows Management Server 248 to create a new net in the user portion of database 232, including defining all net definition parameters. The derate net feature allows management server 248 to clear the current net in the user portion of database 232. The Modify Net feature allows Management Server 248 to modify the current net in the user portion of database 232, including modifying all net definition parameters for a particular net. The list user function allows Management Server 248 to display all users by user name, dial number, and user identifier in the user portion of database 232.

The list net function allows the management server 248 to display all nets in the net portion of database 232 by net address and net identifier. The show user feature allows Management Server 248 to show all fields for a particular user identified by the user's user identifier. The shownet feature allows the management server 248 to show all fields for a particular net identified by the net identifier or net address of the net. The status feature allows Management Server 248 to ask specific nets for static status reporting. The status feature may also allow Management Server 248 to ask questions for real-time (updated) reporting. In particular, the status feature checks the list of current net participants, current talkers, the presence or absence of media traffic, and any and all media signaling messages sent or received by CM. The help feature allows Administration Server 248 to ask questions, including usage and syntax, for a brief human-readable summary of each supported CLI command.

The NBS user portion of database 232 keeps track of individual users of NBS. The user records contained within database 232 may or may not necessarily be members of the net, as defined in the net portion of database 232 of the CM.

Each record in the user portion of database 232 includes username, user identification, vocoder list, dial number, user format, CRTP support, CD user address, and CD pretty good privacy. prinacy) (PGP) Included in areas such as public keys. A vocoder list is a list of vocoders supported by the subscriber's CD. The list may include vocoders that are not supported by NBS. The dial number is the dial number of the subscriber's CD. This field is empty or null for the average Internet user. The user format is a format field that describes whether the user is a CDMA cellular or a general Internet user. Users connecting via PSTN dial-up are considered general Internet users. CRTP support is a flag that the CD supports when connecting and indicates whether it has attempted to negotiate CRTP header compression over PPP. This flag is valid for cellular as well as PSTN-based users. The CD user address is a globally unique user address for CDs. A CD known to be addressed by multiple users will have multiple participants in the user portion of database 232. The PGP public key is a key combined with a CD user address.

The NBS net database defines a combination of nets known to CM. The net portion of database 232 also displays the defined members of each net. It is a user who requests a bond from a net and may become a participant. Each record in the net portion of database 232 contains various fields. The field contains a net identifier, which is a unique integer that confirms the net in the CM environment. The field also contains a net address, which is a net address compatible with the net SIP. A list of net owners and users who are not blank is verified by a user identifier that has administrative privileges (defined separately) on the net. The net safety status is also a field for flags that indicate whether the net is clear or safe.

The field also includes a mediation plan, which is a unique value confirming the mediation plan used to resolve PTT mediation conflicts between net participants. The net vocoder describes a field that has its own value confirming the standard vocoder shown in the net's notified session description. Defined members of the net have vocoders listed in their list of supported vocoders. The PTT failsafe timeout is the maximum number of seconds a net participant may send media to the net before the CM revokes control of the floor with a PTX negative message. The hang time timeout value is the maximum number of seconds that a net CM may stay idle before it will put it into hibernation. The PTX pause response timeout value is the maximum number of seconds the CM waits after determining that a paused net floor can be allowed before sending a PTX grant response to the requesting CD. The wakeup timeout value is the maximum number of seconds a CM will wait for a net participant to respond to an AYT "wake up" message before allowing an unresolved PTT request. The raterizer timeout value is for the CD to respond to the CM's AYT "wakeup" message before the CM will remove the unresponsive CD from the list of active participants on the net. This is the maximum number of seconds that the CM waits for. The AYT timeout value is the maximum number of seconds the CM waits for the CD to respond to the CM's AYT message before the CM removes the CD from the list of active participants on the net. A media channel list is a list of media channels containing payload criteria for the net (the net represents the media channel that transports at least one audio).

The net membership list defines a combination of users who join the net as participants and may request the combined net specific privileges. Each entry into the list contains fields such as the user identifier, which is the user's unique identifier displayed in the CM's user database 232. The field also contains the user net priority level, which is the user priority level that should be used by the net PTT arbitration algorithm when resolving PTT conflicts. A priority level of zero indicates that the user has only listen privileges and will never be allowed control of the net. The field may also contain a user authentication list detailing the authentication privileges that the user has over the net, if any. Privileges may include the ability to add participants to the net membership list, edit or modify it, and modify other net parameters.

Each CD stores a database, also known as a group list, that identifies known nets that the CD may request to join. Each participant in the CD database contains fields such as net address, net security advisory flag, net traffic encryption key, and hibernate baby sit timer. The net address is the official SIP net address of the net that the CD uses to request that it join the net as an active participant. The net security advisory flag is cleared, distributed by the CM's SIP server 236 into a list of available nets or user combinations to indicate nets that are defined to carry Type VI secure media traffic. / Safety advisory flag. A net traffic encryption key is a traffic encryption key used to encrypt and decrypt all media traffic for a Type IV secure net. The dormant baby sit timer has a length of interval of seconds. When the CD is in hibernation / idle state while transitioning to the combined state, wait while making sure that the packet data call remains valid and the base station has not unilaterally dropped the connection. There will be.

MCU node 208 includes MCU 252, MCU node manager 256 and local log server 260. MCU nodes 208 and 212 may also freely include an additional MCU264. The MCU node 212 is substantially the same as the MCU node 208. For purposes of explanation, only MCU node 208 is discussed here. The MCU252 is responsible for controlling a single active net. The MCU supports SIP, media signaling, and media interfaces for the net. And it gives a function combined with the normal operation of the net. Each MCU node 208 may have a pool of MCUs252 that may be directed to properly control the net. Each MCU252 prepares the MCU management interface 268 to support features such as start, stop, and status reporting.

The MCU node manager 256 monitors the operation of the MCU node 208 and controls the operation of each MCU 252 on the MCU node 256. The MCU node manager 256 also provides an external interface 272 to the CM core complex 204 to allow startup and / or shutdown, net allocation to nodes, and distribution of status information.

The local log server 260 records all log events for MCU node 208 locally. The local log server 260 also responds to requests from the central log server 244 via its log event interface 276. The request involves uploading a certain event class, or priority. To prevent event loss, messages are stored on the local log server 260 until approval is received by the central billing log server 244.

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

Each CD stores a list of nets, or group lists, that internally represents a known combination of nets to which the CD can participate. The list is non-volatile, but may be updated when needed through either interaction with CM104 or interaction by the user. Users can also determine who and how many users are active or inactive in the net. The NBS group list stored internally by the CD is functionally similar to the list of names and dial numbers stored in the phone book and used to facilitate voice services. .. The NBS group list may be integrated with the phone's current phone book. In either case, the action of selecting a net from the group list commands the phone to attempt to join with the selected net.

In order to participate in a particular NBS net, each CD first requires the CM to add itself to the list of active net participants for the particular net. Therefore, first each CD knows or can be taught the net address of any net that wants to participate. In addition, each CD first knows or can be configured for the address of the top-level SIP server 236 to which SIP requests may be sent.

The net address may be supplied or communicated by the CD in several different ways. For example, in one embodiment, the CD may first be given the address of a top-level SIP server that gives the current list of known or missing nets on which the CD can participate. The CD may also be given a group list that defines at least one net address of which the CD is a member. The CD may later send a request to the top-level SIP server 236 to update its group list. If there is no explicit NBS supply to the CD, the user may be given a top-level SIP server 236 and a net address to enter the CD interactively before using NBS. .. The user may also interactively enter an additional net address to the group list already given with the participants. Such a setup step is similar to entering a personal name and phone number in a traditional phone book.

The user may enter the new address interactively into the CD group list, but the corresponding net and top-level SIP server 236 are rather present and the user must have the CD successfully join the net. It should be noted that it is required to be displayed as a member of the net.

The CD may also be given the IP network address of the original Domain Name Service Server (DNS) 216 to which the CD can send DNS questions. Typically, the address of DNS server 216, operating on a CDMA cellular carrier, is given. The CD may also be given the IP network address of an alternative DNS server.

To support SIP authentication, the CD may be given its own PGP user id and private key that can be used to sign SIP processing when requested by CM104. The PGP user id can also be used as a CD user address for general SIP processing.

Figure 10 illustrates the high-level features of the CD Group Service Module 500. Normally, the group service module is initialized to the default idle state 504 when the CD is powered on. From idle state 504, the CD may move to another state that allows active participation in the NBS net.

Users may wish to temporarily deter NBS services through menu options within the CD user interface. If the user has a deterred NBS service, the group service module defaults to the deterred state 508 when the CD is powered on. When defeated, the CD does not attempt to automatically bind to any NBS net. In addition, the CD does not perform any NBS-specific SIP processing (the CD may store or perform registrations for other SIP processing for other IP-based telephony applications within the CD). ..

Freely, the group service may be completely hidden from the user by giving the group service in the CD to the unequipped state 512. The unequipped state group service is deterred, where the equipped state enables the group service. Once unequipped, the CD requires administrative preparation to enable group services. When the group service is not equipped, the NBS group service function and related user interface characteristics are not available to the user.

The CD may support over-the-air provisioning to provide NBS group services. If the CD group list contains more than one net address, the only one net address may be recognized as the default net 514. If a net address is selected, the CD will attempt to automatically transition from idle 504 by attempting to combine with this selected net shortly after the CD is powered on.

When the CD is connected, the CD will go from quiet state 516 to listen state 520, talk state 524, and hibernate state 528, based on where it is in the push-to-talk system, as described in Figure 16. And rotate.

NBS relies on call signaling syntax, and semantics, to notify the available net addresses, as defined by SIP, thereby providing a mechanism by which individual CDs can officially join or leave the net. I have to. The CM104, along with other functional entities, provides the user and net portion of the top-level SIP server 236, one or more multipoint control units (MCUs) 252 and combined SIP user agent servers, and the management database 232. Including. The top-level SIP server 236 acts as a gathering point for joining known systems. Each MCU252 performs media signaling and media traffic exchange for one or more nets. Database 232 stores and provides known user, management, and net address definitions, and may serve multiple CM installations or be accessed remotely.

Each CD is provided with a list of net addresses and one or more top-level SIP server 236 addresses. If the group list is empty, the user may define existing net addresses in an interactive manner. If the top-level SIP server 236 is not defined, the user may define the address of the top-level SIP server 236 in an interactive manner. Once the address of the top-level SIP server 236 is known, the CD may request an updated list of available nets to a predefined SIP destination by generating using the SIP INVITE method. I don't know.

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

After the net is selected, the CD attempts to join the net by using the SIP INVITE method to define the net address as the invitation destination and send the request to the top-level SIP server 236. Top-level server 236 attempts to map the net address to a known destination, and hopefully redirects the CD to the corresponding MCU252 SIP user agent server. If no mapping is obtained, the invitation usually fails.

Typically, the destination SIP user agent server on the MCU252 verifies that the CD is a member of the selected net and responds to the invitation, incorporating a description of the media traffic and signaling parameters used to join the net. .. The destination SIP user agent server of MCU252 also has some error conditions, such as if it is not possible to verify the CD as a legitimate member of the net, or an error that interferes with normal net operation. If so, it may respond with an error. If the invitation is accepted, the CD will approve the response through a message such as the SIP ACK method. It should be noted that other transient response codes that indicate the progress of the call may also be received by the CD while the invitation is being processed.

The CD is tasked with updating the group list for any net combinations that may participate in it. The user may instruct the CD to question database 232 of CM104 in order to receive updates to its group list, even when no net address is selected. If the CD determines that it has been added or removed from the net, the CD will display the appropriate message to the user (eg, "added to group X"), and / Or stimulate as much as possible for user interaction. If the CD is determined not to be a member of any net, this will be communicated to the user as well. The CD may automatically merge the new net address into its group list, but may inspire the user before removing the disqualified net address from the group list.

Generally, in the group list of CDs, nets that are not more than 1 may be confirmed as being selected at one time. The default net may be selected first, or the user may select the net from the group list.

The MCU252, CM SIP user agent server response, which corresponds to the INVITE request for integration with the net, is embedded in the net media, as well as other net parameters (such as media payload format descriptors). And includes real-time media signaling destination addresses. Once confirmed, the CD simply displays feedback to the user, indicates whether the user has listen-only priority, and enables group service functionality. If CM104 determines that the CD is not a member of the selected net, or that an error or other exceptional condition has occurred, SIP server 252 responds with a corresponding erroneous response. When such registration is rejected, the CD simply displays the corresponding error message, and the group service function remains idle. If the net is not selected, the group service on the CD will remain idle.

As part of activating group services, the CD initializes and opens its RTP media traffic channel 128 and isolated NBS media signaling channel 124 for the CM destination address given in the successful invitation response. Once these channels have been initialized, the group service is activated on CD108, and it has the ability to request permission to receive voice traffic from the net and send voice traffic to the net. Transition to service quiet state 516.

As the group service is activated, the CD 108 monitors its media traffic 128 and its signaling channel 124 to the CM. Audio data received on media traffic channel 128 is decoded and given using the CD108 far-field speaker or ear-piece accessory according to the current user settings. CD108 displays the current speaker identity when confirmed through real-time media signaling 124. If confirmation of the current speaker is not available, the CD108 will display the currently selected net name when it is listed in the group list. CD108 also tabulates media traffic statistics (eg, total time spent talking, listening, and monitoring, estimated lost media traffic received packets), and features these using menu options. May be made available to users. While receiving traffic from the net, the CD108 returns to the quiet state when voice traffic stops and transitions to the group service listen state 520.

At any time, the user may request permission to speak to the net by pressing the PTT button and the CD108 signaling the CM104 (especially the MCU252) using a floor control request. The PTT button may be any form of activation command that includes, but is not limited to, pressing a key, or key sequence, voice activation, switch, toggle device, or dial. The MCU252 responds by either allowing or denying the request. If the CD has a listen-only priority, such as CD112 (which means that the CD has zero priority in the selected net), the request is denied. If denied, the CD112 alerts the user with an erroneous sound and displays an appropriate error or descriptive message. Then, it returns to the quiet state 516. The CD claims that the PTT may be released and pushed again before attempting other floor control requests. If allowed, the CD112 enters the group service talk state 524 and signals the user, for example, with a simple audible sound, and begins sending voice traffic to the CM104 for as long as the PTT is keyed. The CM104 may asynchronously signal the CD112 that it is losing control of the floor (while it is PTT keyed). Upon receiving this signal, the CD112 abandons the transmission of voice traffic and alerts the user with an erroneous tone until the PTT is released. At that point, it returns to the quiet state 516. Otherwise, once the PTT is released, the CD112 signals the CM104 that it has opened the floor and will return to the quiet state 516.

The user may switch to a different net by selecting another net from the group list whenever the group service in CD108 is in quiet state 516, listen state 520, or hibernate state 528. When a new net is selected, CD108 signals CM104 to remove it (CD108) from the current net using the SIP call setup mechanism. Then follow similar steps to combine with the new net there. If the process of connecting to the new net fails, the CD108 is no longer a member of any net, and the group services in the CD108 return to idle 504.

If CM104 determines that CD108 requesting a particular net floor is the only registered member of the net in question, CM104 denies the floor control request and erroneous messages such as lonely user error. Signal. The CD108 then displays it to the user. The net can exist with only one registered member, but without at least two registered members, the net cannot send voice traffic.

The NBS application is based on two different application-level protocols, the Session Initiation Protocol (SIP) call signaling described for Figure 11, and the NBS media signaling described for Figure 12-14. SIP is used exclusively for call signaling and call setup. Media signaling carries PTT requests (Figure 12), controls net outages (Figure 13), and resolves PTT arbitration conflicts (Figure 14).

SIP call signaling 350 is shown in FIG. The session initiation protocol uses CM104's SIP server interface 236 to provide NBS with application layer control (signaling) for discovering, joining, and departing NBS nets. To connect to the net, the CD352 will byte the net 100 by name to join the call via the top-level SIP server 236. To leave the net 100, the CD352 sends a corresponding "goodbye" to the net.

The CD352 uses DNS216 to determine the IP address of the top-level SIP server 236 to decompose the prepared first or second SIP server address into Internet network addresses, if necessary. As a free alternative approach, the SIP Convention states that the CD352 asks DNS216 about the service record combined with the NBS host system domain portion of the net address, and contacts SIP server 236 at the returned address. Tolerate.

By default, the CD352 attempts to contact SIP server 236 using the default SIP port. Otherwise, the alternate port information is determined via DNS216. Prior to attempting to join the net, the CD352 may use the SIP INVITE method to make a call to request an updated list of available nets.

For example, a wirelessly connected CD352 wants to be assigned an IP address and determine the current list of available nets. This opens a UDP / IP connection to the SIP server port and raises a request. Requests to get an updated list of nets are directed to special destinations. When appropriate, the CD352 also includes additional application-specific headers confirming the CDMA networks and systems from which the CD352, which is based on the CDMA cellular, is serviced.

The CD352 may also include a header to indicate that the CD352 expects the SIP server 236 to understand and support the NBS service. Any value distributed by the header may also be used by CD352 to signal the type of NBS service that a particular version of Server 236 or CD352 expects Server 236 to support. it can.

CM's top-level SIP server 236 may use a SIP redirection mechanism to redirect an byte request 356 to a destination specifically defined for reception in response to a request for net information. Upon receiving such a redirection, the CD352 acknowledges (ACKs) response 357 and resends the request to the redirected destination.

The CD352 may need to determine the appropriate SIP contact point through the DNS mechanism for the redirected address. To simplify this process for CD352, Server 236 can use Internet network addresses to clearly define redirect destinations. Once the INVITE message 354 requesting a list of nets has been successfully received and accepted by server 236, server 236 delivers INVITE request response 356.

INVITE request response 356 contains, in its contents, a list of records that define the combination of nets that CD352 may subsequently join. Server 236 asks net database 232 about the net displaying the requesting CD352 as a defined member in order to form a response 356 to INVITE request 354. The net is identified within the scope of the application that defines the recording format, including the official net address of the net.

Server 236 may not be able to respond successfully to CD352 for a variety of reasons. In such situations, server 236 delivers the appropriate SIP status code instead of INVITE response 356. The CD352 is prepared to accept and determine such status codes, taking appropriate action in the event of any serious error (such as an error message appearing on the CD352 user interface display). Should be. Server 236 may also be the beginning of a successful INVITE response 356 with a status response of information indicating the progress of registration. CD352 may accept and determine the status code of the information that triggers a successful registration.

The CD352 requests that the SIP INVITE request 358 be joined to the net by being generated by the CM manager 240 via the server 252. If CD352 does not have an open UDP / IP connection to SIP server 252, it (CD) will open a new UDP / IP connection to the SIP server port.

The CD352 is prepared to be redirected by the top-level SIP server 236 and reissues the request to the redirected destination if necessary. CM's top-level SIP server 236 redirects any incoming INVITE requests as appropriate for the MCU's SIP server 252, which is currently combined with the net in question. CD352 may be redirected more than once.

INVITE request 358 may include (as message content) a description of the media source from which the CD352 originated, assuming the invitation was successful. If included, the description is included as the message content and is described using field construction.

Session Description is delivered in a format compatible with Session Description Protocol (SDP). After the SDP version (v) is defined, the session description will be mandatory. origin) (o) Includes description. The CD352 may use any convenient mechanism for selecting values for session identifiers and session versions. Giving an estimate of the current time is one possible way to define a session identifier. The connection data (c) is sorted by defining the network format, address format, and connection address. The CD352 thereby uses the IP address it (CD) classifies (or relies on) media traffic as a connection address. CD352 uses the name part of the net address of the net as the session name (s). CD352 defines the lifetime (t) of a session, preferably in Network Time Protocol (NTP) format, by giving an optimal estimate of the start or current time, and that the session is unrestricted (0). Is shown. The media format (m) description defines the media format, source port, transport protocol, and payload format that the CD352 intends to use for sending to the net. Finally, the session description uses a definition in the form attribute (a) to indicate that the CD352 expects the session to act as an NBS conference. Before accepting the invitation, server 236 should make sure that it is indeed a reliable NBS net address to be byteed into the address.

Server 236 issues an INVITE response 360 to indicate a successful invitation and to specifically notify CD352 that it (CD) has been added to the list of participants for the embedded net. to deliver.

The successful INVITE response 360 contains a first session description for the embedded net, which describes a format with supported media traffic ports and SDP syntax. The session description includes a connection (c) description that defines the network address to which all media signaling and traffic should be sent. The media destination network address of the net does not have to be the same as the network address of the SIP user agent server, which is decomposed from the net address of the net using DNS.

The session description shows all media and destination media ports. The session description also includes an identifier assigned to the CD352 by the MCU252 for the purpose of identifying media signaling messages sent by the CD352 as part of its continued participation in the net . The value of this identifier is unique among all active participants on a given net and should therefore be dynamically generated. The CD352 does not need to store this identifier during successful SIP invitations.

The session description may also include an NBS protocol version announcement that indicates the level of revision that media signaling on the net will stick to. Such an announcement may be made by extending the value of the formal attribute field or defining a new attribute whose value is the protocol version number.

After receiving a successful INVITE response, the CD352 confirms the invitation by sending a SIP acknowledgment (ACK) request 362 back to the SIP user agent server 252 of the net MCU. After sending an ACK request 362, the CD352 may close its TCP connection with the SIP server. Prior to the ACK request 362 being sent, the CD352 initializes its media signaling and traffic ports according to the session description delivered in the INVITE response 362.

In response to the successful INVITE response 360, the CD352 officially goes to the net by sending a SIP BYE message 364 to the user agent server 252 on the net at any time after the CD352 sends the SIP ACK message 362. May end participation. Prior to sending BYE message 364, CD352 may need to open a TCP connection to user agent server 252. BYE message 364 is approved by CM in BYE response message 366. Once BYE response message 366 is approved, CD352 will close its UDP connection with user agent server 252. Prior to approving BYE response message 366, user agent server 252 removes CD352 from the list of active participants on the net shown.

In general, the CD352 SIP user agent client will use the OPTIONS method to question the capabilities of the SIP server. In particular, the CD352 would want to ask any SIP destination to determine if the destination would provide NBS call signaling support.

CD352 may wish to abandon pending INVITE request 358 prior to receiving INVITE response 360 and sending approval 362. In such situations, the CD352 may use SIP CANCEL (not shown) to gently abandon the call. Both the top-level SIP redirect server 236 and the CM SIP user agent server 252 support the CANCEL method.

For example, CD352 may use the CANCEL method to abandon an ongoing INVITE message 358. Possibly, before the INVITE message 358 ends, the user decides to start a voice service call and presses send. In such situations, rather than waiting for INVITE response 360 to finish and immediately sending BYE message 364, the CD352 easily and immediately cancels INVITE message 358, and the voice service required. May move on to the start of the call.

After CD108 successfully negotiates to join the current membership of NBS Net using SIP, all real-time call control is exchanged between each CD352 and MCUSIP server 252, point-to-point application level media signaling messages. It is done through.

Media signaling messages are transported using the protocol stack shown in Figure 4 and according to the sequence shown in Figure 12. FIG. 12 shows the media signaling message sequence 368. The PTT request message 370 is sent by the CD352 to the SIP user agent server 252 of the MCU node 208, and signals the user's wishes to the broadcast media to the net by normal voice. Normally, PTT request message 370 is sent each time the CD352 push-to-talk button is pressed to display a floor control request. In addition, the PTT release message is sent by the CD352 to the SIP user agent server 252 to indicate the normal release of the "floor" when the user releases the CD352 push-to-talk button.

PTT messages include fields such as opcode, id, src, and reserved. The opcode field defines whether the PTT message is a floor control request or an open message. The id field gives a unique message identifier that allows consecutive PTT releases and PTX messages to refer to a particular PTT request. The id should be unique within a particular CD352 registration session. The src field independently confirms the CD352 that sends the PTT request 370 to the SIP user agent server 252. The reserved field reserves space in PTT message 370 for future capabilities.

CD352 expects to receive at least one PTX response message 372 for each of the PTT requests 370 sent. If the PTY response 372 is not received during the predetermined timeout period, the CD352 retransmits the PTT message 370 using the same PTTid, assuming that the PTT request 370 was lost during the migration.

If PTX response message 372 is never received from SIP user agent server 252 within a predetermined number of retransmissions, CD352 assumes that SIP user agent server 252 is no longer reachable and NBS. Go into idle mode and display the error condition to the user. In a preferred embodiment, the CD352 uses different PTT ids for request and release messages.

PTX message 372 is sent by SIP user agent server 252 to CD352 to approve and respond to the previous PTT request 370, as well as for signal asynchronous floor control events. The SIP user agent server 252 uses PTX message 372 to respond to PTT floor control requests or releases. PTX message 372 contains information such as whether the referenced floor control request was approved or denied. When responding to PTT Floor Control Open 370, PTX message 372 is used to indicate receipt confirmation only. The SIP user agent server 252 also terminates PTX approval (ie, times out) in order to asynchronously deny the previously approved floor control request (when the higher priority CD352 raises the floor control request). Alternatively, the floor of the net may use PTX message 372 (where some other event occurs, requesting control to be revoked).

PTX message 372 contains fields such as opcode, id, action, status, and expires. The opcode field defines whether PTX message 372 is a synchronized response to an open PTT request, or if it is an asynchronous message indicating an error or preferred arbitration conflict. The id field refers to a previously received PTT request. The action field indicates whether PTX message 372 is approved, denied, revoked, or confirming control over the floor of the net. The status field provides additional information that describes the behavior of PTX, especially if PTX message 372 is denied, revoked, or unable to respond to a previous PTT request. The status field allows high priority talkers to be authorized to control the net, or CD352 not to be listed as a net participant, and to submit media signaling requests to the net for that purpose. May indicate no. The expires field gives the maximum interval, all in seconds, that is allowed for the CD352 that control of the net floor is receiving. The SIP user agent server 252 starts the timer from the moment it sends the PTX message 372, not when the CD352 starts sending media traffic. The value of the expires field is a configurable net parameter.

CD352 does not explicitly approve the receipt of PTX message response 372. Instead, if the transmitted PTX message response 372 is lost, the CD352PTT retransmission timer expires, and the CD352 resends its PTT request 370. The retransmitted PTT370 has the same id as the lost PTX response 372, so the SIP user agent server 252 treats the retransmitted PTT message request 372 as a detached push-to-talk request event. Rather, it responds by resending the lost PTX message response 370.

The PTA message 374 is sent by the SIP user agent server 252 to notify each CD352 currently participating in the net of confirmation of the source of undetermined media traffic. PTA message 374 is also used to officially signal the end of the talk-spurt.

PTA message 374 includes fields such as opcode, talker, and reserved. The opcode field indicates whether PTA message 374 signals permission (or release) to (or by) CD352 as confirmed by the floor talker. The talker field checks for CD352, which is the source of media traffic to the net, until the next PTA message 374 is sent. The reserved field reserves space in the PTA message for future capabilities.

The CD352 for which the PTT floor control request 370 was successful may or may not have received the PTA message 374 informing it that it has control of the floor. The message may have arrived before or after receiving the corresponding PTX response 372, as UDP does not necessarily protect the array of datagrams. However, the SIP user agent server 252 sends the PTA announcement 374 (in the case of a PTA-approved announcement) before it anticipates the start of media transfer. The requesting CD352 ignores the PTA message received, notifying that it is under floor control, and to determine if media transmission to the net can begin. , It is recommended to rely only on receiving the PTX approval message response 374.

The you are there AYT message 404 (Figure 13) is sent by the SIP user agent server 252 to individual CD352s to see if the CD352 in question is reachable using IP. A collection of AYT messages 404 may also be sent to a group of net participants to signal that the net is no longer in hibernation mode.

AYT message 404 contains fields such as opcode, id, and reserved. The opcode field indicates whether the CD352 is still reachable, or if the SIP user agent server 252 is using AYT message 404 traffic to take the combined CDMA cellular traffic channel of the net out of hibernation mode. Indicates whether MCU node 208 is sending an AYT message 404 to determine. The id field gives a unique message identifier that allows consecutive I am here IAH response messages 408 to reference a particular AYT request message 404. The id may contain a timestamp reference to generate a wait time evaluation. The reserved field reserves space in the AYT message 404 for future capabilities.

The CD352 may or may not be in hibernation mode when the AYT message 404 is sent. In all cases, the CD352 responds to the received AYT message 404 with an IAH response message 408.

The SIP user agent server 252 assumes that the CD352 normally responds with an IAH response 408 and responds to an AYT message 404. If the IAH response 408 is not received within a reasonable timeout, the SIP user agent server 252 sends a new AYT message 404 with a new id. If no response to the AYT message 404 is received from the CD352 after a configurable number of retransmissions, the CD352 is assumed to be unreachable, and the SIP user agent server 252 makes it a net participant. Remove from the current list of. Future media signaling messages from the removed CD352 will be ignored (or will result in an erroneous response) until the CD352 successfully rejoins the net.

The IAH message 408 is sent by the CD 352 to the SIP user agent server 252 to approve the receipt of the previously sent AYT message 404. IAH message 408 contains fields such as id, src, and reserved. The id field refers to a previously received AYT message 404 approved by CD352. The src field independently identifies the CD352 that sends the IAH message 408 response to the SIP user agent server 252. The reserved field reserves space in IAH message 408 for any ability.

SIP user agent server 252 assumes that CD352 approves all received AYT messages 404 with a single IAH response message 408. If the referenced AYT message 404 is sent to ensure that the CD352 stays connected to the NBS quiet state, which is passively monitoring and signaling NBS media traffic, the SIP user. Agent server 252 records the time of IAH reception 408 for future reference.

Since SIP user agent server 252 is responsible for defining the value of the id field, SIP user agent server 252 may use id to determine and track whether a particular CD352 remains reachable. ..

A ZZZ or sleep message (shown as reference digit 412 in Figure 13) is sent to the CD352 by the SIP user agent server 252 to help the CD352 release its radio resources and enter hibernate mode. Be sent out. The CD352 may choose to ignore this message (especially if it also supports other packet applications).

ZZZ messages include fields such as id and reserved. The id field gives the CD352 a unique message identifier that allows it to be separated among multiple recipients of the ZZZ message. The reserved field reserves space in the ZZZ message for free or future capabilities.

CD352 does not approve the reception of ZZZ messages. Error recovery is usually not attempted if the ZZZ message is lost. To protect against the loss of ZZZ messages, SIP user agent server 252 may send multiple copies of the same ZZZ message to individual CD352s. The SIP user agent server 252 ensures that a copy of the same sleep message is sent within a defined interval, and the CD352 has the first sleep message (with a new id), but its wireless link is released. It waits for a period longer than the time received before the transition to hibernation by this interval.

As shown in FIG. 15, ASK message 382 is sent by CD352 as question 384 to SIP user agent server 252 to confirm connectivity with SIP user agent server 252. ASK Message 382 also allows CD352 to decide whether to stay listed as a net participant. The CD352 may confirm its participation after a service interruption or other period in which connectivity with the SIP user agent server 252 may be temporarily lost.

ASK message 382 contains fields such as id, src, and reserved. The id field gives a unique non-zero message identifier that allows consecutive FYI response messages to reference a particular ASK request message. The src field independently identifies the CD352 that sends the ASK message 382 request to the SIP user agent server 252. The reserved field reserves space in ASK message 382 for free or future capabilities.

CD352 assumes that the SIP user agent server 252 responds to the received ASK message 38 with an FYI response message 386. If the FYI response 386 is not received during the predetermined timeout period, the CD352 sends a new ASK message 382 with the new id. If no response to ASK message 382 is received from SIP user agent server 252 after a configurable number of retransmissions, SIP user agent server 252 is assumed to be unreachable, and CD352 is a group service idle. Move to the state.

FYI message 386 is sent to CD352 by SIP user agent server 252, or asynchronously by SIP user agent server 252, to authorize the receipt of the previously sent ASK message 382. Sent to communicate.

FYI message 386 includes fields such as opcode, action, atatus, id, and reserved. The opcode field defines whether FYI message 386 is a synchronous response to an unresolved ASK request 382, or perhaps an asynchronous message with exceptional conditions. The action field should be defined as FYI message 386 confirming net participation, telling CD352 that it has been administratively dropped from the net member list, or some other definition. Indicates that the function is being performed. The status field provides additional information describing FYI response 386, especially if FYI message 386 indicates that CD352 is not a net participant or member. The id field refers to ASK message 382, where the previously received CD352 has been approved. The reserved field reserves space in the IAH message for any or future capabilities.

CD352 normally does not approve the receipt of FYI message 386. If the synchronous FYI message 386 response is lost, the CD352 sends out a new ASK message 382 request. Since the CD352 does not require an asynchronous FYI message 386 response, in a preferred embodiment the SIP user agent server 252 makes at least three staggered transmissions for any asynchronous message 386 response.

The participating CD352 signals the user's desire to broadcast media over the net by issuing a PTT message request 376 to the SIP user agent server 252. The SIP user agent server 252 responds to PTT request 376 with a PTX message response 378, which may either approve or deny the request. If the request is approved, the PTA announcement message 380 will be broadcast to all online participants. The requesting CD352 user interface may indicate to the user that permission to talk to the net is allowed when the allowing PTX message response 378 is received. The CD352 normally broadcasts media traffic until the user signals the end of the talk spurt by releasing the PTT button and at that point generating a PTT release message 376 to the SIP user agent server 252. The SIP user agent server 252 responds with a PTX confirmation message 378 and broadcasts an announcement to all net participants indicating the end of the talk spurt.

When any CD352 has a net floor (right to talk), the net is said to be active, otherwise the net is inactive. If the net is inactive for a period of time that exceeds the net hang time, the SIP user agent server 252 individually signals all registered mobile stations to open their radio traffic channels to the net. May be put in hibernation mode. Connections to allow other traffic to bring floor control requests or nets out of hibernation mode relatively quickly are preserved. Net members may ignore the "let's pause" message. SIP user agent server 252 does not explicitly or implicitly track the hibernation of individual net members.

As shown in FIG. 15, the SIP user agent server 252 will "wake up" the net and exit hibernation mode 618 when a successful floor control request 704 is received during the hibernation period. .. As soon as the floor control request 704 is granted, the SIP user agent server 252 signals each registered CD352 by requesting there (AYT) message 716 on the media-signaling channel. Then, the internal wake-up timer 724 is started. Each CD352 authorizes the SIP user agent server 252 to receive AYT message 716 if it wishes to stay registered on the net. Freely, the dormant CD352 may buffer media traffic 740 from the time the user presses PTT until the CD352 traffic channel is (re) connected. The SIP user agent server 252 receives media traffic 740 from the CD352 during a call, including any member whose wakeup timer 724 has exceeded the wakeup timeout and has not yet responded to AYT request 716 at that time. , May buffer until it starts forwarding media traffic to each registered CD352. Therefore, both the CD352 and the MCU node 208 have the ability to buffer the data until the recipient is ready to receive the buffered information. In one embodiment, the data portion is stored in both the CD352 and the MCU node 208.

The SIP user agent server 252 periodically retransmits AYT request 716 to any registered CD352 that has not approved receipt of AYT request 716. Once the wakeup timer 724 exceeds the second longer late-riser timeout, the SIP user agent server 252 unregisters any member CD352 whose AYT approval is unresolved and shuts down the wakeup timer 724. Will do. SIP user agent server 252 ignores duplicate AYT requests.

If the CD352 attempts to join the currently dormant net, the SIP user agent server 252 processes the request normally and then signals the CD352 to dormant. The signaled CD352 may ignore the instruction to pause.

During the period of inactivity of the extended net, NBS allows packet data service calls to be in hibernation / idle state 528 (see Figure 11). The SIP user agent server 252 facilitates the transition into and out of the hibernate / idle state 528 by independently controlling a similar hibernate concept for each NBS net 100.

FIG. 13 illustrates a sequence of media signaling messages with respect to pause 400 between CD352 and SIP user agent server 252. Generally, the message is sent to all CDs in the net to pause based on the control signal sent from the CM based on the timer of each CD. As such, the resources allocated to the net may be released and used for other users. On a configurable schedule, the SIP user agent server 252 sends a message request (AYT) 404 to each CD352 to see if the quiet CD352 remains reachable. In this way, the CM104 stores a centralized polling of current users of the net and its state. It also allows individual CDs to dynamically join or leave the net. The CD352 responds to the AYT request 404 with a message response (IAH) 408. AYT message 404s are not necessarily broadcast on each CD352 at the same time. The SIP user agent server 252 may stagger the sending of AYT to each net participant to avoid receiving the simultaneous flood of IAH message responses 408.

After the net has been idle long enough to end the net's configurable hang time, the SIP user agent server 252 broadcasts a ZZZ request message 412 to each net participant. Correspondingly, each CD352 may release its radio resources and enter hibernation mode. Net participants do not necessarily have to respond to ZZZ request message 412.

Successful PTT request 416 with CD352 takes the net out of hibernation mode. In one embodiment, a predetermined number of user limits is needed to take the net out of hibernation. Prior to granting the request by PTX message 420, the SIP user agent server 252 sends an AYT message request 424 to each CD352 to help the previously participating CD352s come out of hibernation. This is done if the CD352 chooses to release radio resources in response to ZZZ message 412 and to make sure that the participating CD352 is still reachable. In other embodiments, after a configurable but fixed delay, defined as a PTX pause response timer. The SIP user agent server 252 sends a PTX authorization message response 420 to the requesting CD352. Once the second wakeup timer expires (its value is usually not less than the PTX hibernate response timer), the SIP user agent server 252 notifies all net participants of the talker via PTA message 428. , And may start transferring media.

The MCU node 208 is tasked with receiving incoming data packets from the transmitting CD352 and sending a copy of the received data packets to other members of the net to which the transmitting CD352 belongs. When each data packet is received by MCU node 208, it is stored in memory (not shown). The sending CD352 may be confirmed by asking the data packet. In one embodiment, the IP address displaying the transmitting CD is included in each data packet as a method of identification.

After the sending CD352 is confirmed, the MCU node manager 256 displays a list of net members belonging to the net combined with a particular MCU node 208 in local memory (each MCU typically has only one net). (Assigned to) to collect from. The destination address is combined with each active net member, that is, the net member registered on MCU node 208 in local memory. In one embodiment, the destination address is an IP address. The MCU node manager 256 then makes a copy of the original data packet, except when the destination address identified in the data packet is modified to reflect the destination address of the first net member. The MCU208 then creates a second copied data packet for the second net member. This process continues until the original data packet is copied and sent to all of the active net members identified in local memory. Playout of any buffered media (play) During the out) period, CM104 treats the net as active, even if the busy CD352 has the floor open. Therefore, CM104 does not allow the CD352 to interrupt the playout of the buffered media unless the interrupting CD352 has a higher priority than the source of the buffered media.

The SIP user agent server 252 may receive an IAH message response 432 for an extended interval after the net is taken out of hibernation mode, and the SIP user agent server 252 has an undetermined PTT request 416. It should be noted that we do not wait for all net participants to respond before allowing. Delayed respondents whose IAH response 432 arrives after the PTX authorization message response 420 will remain listed as net participants and sent. However, it may not receive all initial media traffic and signaling. After a third large (and configurable) delay, any CD352 that is not responding to AYT request 424 is generally assumed to be no longer reachable and is removed from the list of active participants' nets.

FIG. 14 shows a sequence of NBS media signaling messages 440 exemplifying that the higher priority CD444 is interrupting the lower priority CD442 by controlling the floor of the net.

First, the lower priority CD442 submits the PTT message request 446, which is allowed by the SIP user agent server 252, to the SIP user agent server 252. The SIP user agent server 252 notifies that the CD442 has control of the net floor.

While the lower priority CD442 is transmitting MS media 443, the second CD444 attempts to interrupt the SIP user agent server 252 by sending a PTT message request 448 to the same net. The SIP user agent server 252 determines that the second CD444 has a higher priority than the CD442 in the call, and immediately sends an asynchronous PTX negative message 450 to it (CD442) to net. Revokes control of the floor from CD442 during a call. The SIP user agent server 252 then grants PTT request 448 for the higher priority CD444 with a normal PTT grant message response 452, and notifies that the higher priority CD444 has control of the net floor. To do.

If the SIP user agent server 252 determines that the interrupting CD444 does not have a higher priority, the SIP user agent server 252 immediately rejects the PTT request 448 with a PTX message response 452. Distributing media 456 from the busy CD to net participants continues uninterrupted.

Although the priority assigned to a particular CD is a fixed value defined in the database stored by SIP User Agent Server 252, SIP User Agent Server 252 is the best, as shown here. Other arbitration algorithms may be used that do not always allow floors for requesting participants with priority. The PTT arbitration algorithm used to arbitrate conflicts can be set individually on a net-by-net basis.

At a minimum, SIP user agent server 252 supports an arbitration policy that allows only the current talker to be interrupted if the CD has a priority level above the current talker's priority level. A CD with the lowest priority can listen to media traffic, but never gains control of the net floor.

Figures 15 and 16 describe the operation of CM104 and CD352, respectively, under various conditions. The CM104 stores an in-activity timer for each net, i.e. a hangtime timer 620. When the inactivity timer 620 reaches a configurable value, the timer triggers the CM104 to put the net into hibernation 618 by broadcasting a media signaling message 696 to all net participants. Upon receipt of the message, the participating CD352 may open its traffic channel and enter hibernate / idle 844. Alternatively, the CD352 may ignore the message and remain connected to the 820. In particular, net participants such as dial-up PSTN users who are not running on the channel should ignore media signaling messages.

The net hang time timer 620 will not advance while the PTX authorization message response 632 is in effect. The timer 620 is set to zero when the PTX authorization message 632 is sent and remains zero until the PTX authorization 632 expires or the CD352 releases floor 872 of the net. Once the floor is freed, the hang time timer advances until the next PTX authorization message response 632 is sent.

If the participating CD352 goes into hibernation / idle 844, packet data destined for the CD352 arrives at the CD352MA Cellular backbone or generates data that the CD352 should send using the packet data service. Until either of, it stays in a dormant state. In the former case, it may be triggered by the traffic sent by CM104 (908) to CD352. In the latter case, it may be triggered by a user pressing a PTT button requesting permission to broadcast to the net. Other triggers not related to NBS are also possible.

The net itself remains dormant until one or more participants trigger the transmission of PTT request 704. If CM104 determines that it can allow PTT request message 704 (including performing any necessary mediation to handle multiple requests), it will, for each displayed net participant, Send request 716 to trigger a transition out of hibernate / idle state 844. Triggers may or may not be required for any particular CD352. But each CD352 nevertheless responds to the request. In this situation, when the net is transitioning out of hibernation 618, the CM104 will send the first PTX grant response message 756 with a fixed but configurable delay, the PTX dormant response timer 728 ends. Refrain until you do. After timer 728 has its default value typically zero, CM104 sends PTX permission 756 as usual. However, CM104 continues to refrain from transferring media to the net until the end of the second related timer, the net wakeup timer 724. Both timers reset when the CM104 determines that a dormant net floor can be allowed. The value of the wake-up timer 724 must not be less than the value of the PTX pause response timer 728. After the wake-up timer 724 has expired, the CM104 begins to forward media and media signaling, and traffic flows normally. Both timers can be set on a net-by-net basis.

If CM104 determines that it cannot allow PTT request 704, it immediately signals the requesting CD352 according to PTX negative message 708 and the net continues to pause.

CD352 in hibernate / idle state 844 has some other service interruptions that result in a system change, change service option, or that (CD352) never receives and responds to AYT "Wake Up" message 908. May require experience. The CM104 stores a third longer timer that resets along with the wakeup and PTX pause response timers. This longer, raterizer timer (not shown) can also be set on a net-by-net basis. After the raterizer timer expires, any CD352 that has not received an IAH response 916 to its AYT wakeup message 908 is removed from the list of active participants' nets by CM104. Any thus removed CD352 is re-registered on CM104's SIP server 236 to become a net participant again.

Due to the potential delay associated with the CD352 moving out of the hibernate / idle state 844 and into a connected state, both the CD352 and CM104 are voice buffered to reduce the transmission delays perceived by the user. May do.

Typically, the CD352 user interface signals the user through a visible or audible mechanism at least two milestones in the processing of the PTT key press. First, the CD352 signals that it is detecting a PTT keypress. Later, the CD352 signals that it is receiving the CM104's PTX message response 868. If the PTX message response 868 grants permission to broadcast media, the CD352 user interface gives the user an indication that he or she may initiate a call on the net. Otherwise, the CD352 user interface will indicate that permission to talk to the net (856) has been denied.

If the net is not hibernated, the waiting time between sending a PTT request message and the corresponding PTX response message is relatively small, and the user gets used to being authorized to make a call shortly after the PTT button is pressed. .. However, when the net is dormant, a relatively sufficient delay may separate the transmission of PTT request 852 from the reception of the corresponding PTX message 856 or 868. The delay will occur because the CD352 will be opening its traffic channel. It then experiences a delay when reestablishing the packet data service. The delay also occurs because the CM104 waits for the PTX message response 856 or 868 to be sent until the end of the net wakeup time. In this situation, CD352 may optimistically assume that CM104 eventually responds with PTX authorization response 868, and the user is authorized for PTT request 876. To allow the user to start a call "early", the CD352 internally buffers the audio until a PTX request arrives or all available internal buffer space is exhausted.

If a PTX message response arrives and the request is granted, the CD352 may begin transmitting (buffered) audio, and operation proceeds normally. If a PTX message response arrives and the request is denied, the CD352 signals the user that permission to talk to the net has been denied. This slow negation may appear to be a priority conflict, as the user has already started the call. In such situations, special care is taken to avoid unnecessary embarrassment of the user. The CM104 sends PTX Negative Message 856 as soon as possible to limit the length of time a user may call, under the assumption that undecided PTT requests will eventually be granted. Signal.

If the PTX message does not arrive until all available internal buffer space is exhausted, the CD352 may signal the user to stop the call (856), mimicking the PTX negative message 856. Absent. If the CD352 does not have the ability to reestablish the service, it may also need to take other erroneous actions at this point and inform the user accordingly.

Instead, if by this time the packet data service has been reestablished, the CD352 may begin sending voice media to the CM104 in this situation without prior reception for the PTX authorization message response 868. Absent.

While waiting for the wake-up timer to expire, the CM104 buffers any audio media from the CD352 that is sending the pending PTT request 852 received on the net media channel, and eventually the corresponding PTX allowance. Send response 868. Once the wake-up timer expires, the CM104 sends a PTX authorization response 868 to the requesting CD352, broadcasts the PTA announcement online, and begins broadcasting the buffered audio media. If the CM104's internal voice buffer is exhausted before the wakeup timer expires, the CM104 immediately sends a PTX negative message 856 to the requesting CD352. The processing of the buffered audio is undefined, but the CM104 may send the contents of the audio buffer to the net after the wake-up timer has expired. Once the wake-up timer ends, the net operation proceeds normally.

The size of the audio media buffer in the CD352 is chosen based on the maximum time expected for the transition from IS-707.5 hibernate / idle state 844 to IS-707.5 coupled state 812. Similarly, the size of the media buffer in CM104 should be chosen based on the (maximum) value of net wakeup time specified in CM104's net database 232.

A more complete description of the state of CM104 is as follows. The CM104 executes the NBS media signaling state diagram 600 shown in FIG. 15 for each example of the net. CM104 is initialized to idle state 604 when the net is created. The net remains idle 604 unless the net participation request PTT608 allows control of the floor 612 and the net is dormant 618. The CM104 resets the hang time timer 620 to zero when entering idle 604. The CM104 transitions from idle state 604 to allowed state 612 when a PTT request 608 from a net participant is received. The CM104 shifts from the idle state 604 to the hibernation state 624 when the hang time timer ends.

The CM104 transitions from allowed state 612 to idle state 604 and sends a PTX negative 626 response to the requesting CD352 if the arbitration algorithm denies control of the floor to the requesting CD352. .. The CM104 transitions from permission state 612 to announcement state 628 and sends a PTX permission response 632 if the mediation allows the requesting (or interrupting) CD352 to control the floor. After sending the PTX authorization response 632, the CM104 considers the requesting (or interrupting) CD352 to be the current talker on the net. Immediately after entering the announcement state 628, the CM104 transitions from the announcement state 628 to the talk state 636 and sends a PTA message 640 notifying all net participants of the new talker. The current talker remains in talk state 636 for as long as possible unless a PTT request 644 or open message 648 is received from a net participant, and the net failsafe timer 652 is not terminated. The CM104 resets the net failsafe timer 652 when it enters talk state 636. While in talk state 636, CM104 broadcasts media from the current talker on the net to the net.

The CM104 transitions from the talk state 636 to the arbitration state 656 when the PTT request message 644 is received from the net participant. The CM104 shifts from the talk state 636 to the release confirmation state 660 when the PTT release message 648 is received from the CD352 having control of the net floor. The CM104 shifts from the talk state 636 to the failsafe recovery state 664 when the failsafe timer 652 ends. The user is typically given a total of the time remaining before the failsafe timer expires. The CM104 broadcasts media traffic received from the current talker on the net to the net while it (CM) remains in talk state 636. If the net media buffer is not empty, the CM104 broadcasts media traffic to the net while continuing to buffer the media received from the current talker on the net.

While in talk state 636, CM104 transitions to arbitration state 656 as a result of receiving PTT request message 644. CD352 generating PTT request message 644 is known as the interrupting participant. If the interrupting participant and the current talker are the same, CM104's PTX permission message 668 is lost, and the current talker is resending its PTT request 644. If the interrupting participant and the current talker on the net are the same, the CM104 shifts from the arbitration state 656 to the talk state 636 and sends a PTX permission message 668 to the interrupting participant. The CM104 applies the arbitration algorithm to the current talker on the net if the interrupting participant and the current talker on the net are different, and the interrupting participant immediately enters arbitration state 656. ..

The CM104 transitions from arbitration state 656 to talk state 636 and sends a PTX negative message 672 to the interrupting participant if the arbitration algorithm decides to agree with the current talker. The CM104 transitions from arbitration state 656 to allowed state 612 and sends a PTX interrupt message 676 to the current talker on the net if the arbitration algorithm decides to agree with the interrupting participant. The CM104 shifts from the open confirmation state 660 to the open announcement state 680, and immediately sends the PTX confirmation message 684 to the current talker when the open announcement state 680 is entered.

The CM104 transitions from failsafe recovery state 664 to open announcement state 680, and sends a PTX negative message 688 to the current talker as soon as it enters failsafe recovery state 664. The CM104 transitions from the open announcement state 680 to the idle state 604 and, upon entering the open announcement state 680, sends a PTA open announcement 692 to all net participants. The CM104 transitions from hibernation 624 to hibernation 618, and as soon as it enters hibernation 624, sends a ZZZ message 696 to all net participants informing them that the net is dormant. To do. The net state machine remains dormant 618 unless net participants request control of the floor. The CM104 transitions from hibernation 618 to wake-up 706 when a PTT request 704 from a net participant is received.

The CM104 transitions from wake-up state 706 to hibernation 618 and sends a PTX negative response 708 to the requesting CD352 if the arbitration algorithm denies control of the requesting CD352 floor. Since the net is dormant, this can only happen if the requesting CD352 has listen-only privileges. CM104 transitions from wake-up state 706 to wake-up pending state 712 and sends AYT wake-up request 716 to all net participants if mediation allows the requesting CD352 to control the floor. To do. After sending the AYT Wake Up Request 716, CM104 considers the requesting CD352 to be a pending talker on the net.

The CM104 remains in the wakeup pending state 712 for as long as possible unless the PTT request message 720 is received from the net participant, the wakeup timer 724 is not terminated, and the PTX pause response timer 728 is terminated. The CM104 resets the wakeup timer 724 and the PTX pause response timer 728 when entering the wakeup pending state 712. The CM104 transitions from the wake-up pending state 712 to the dormant arbitration state 732 when the PTT request message 720 is received from the CD352, which is different from the net pending talker. The CM104 shifts from the wake-up pending state 712 to the buffered authorization state 740 when the PTX pause response timer 728 ends.

As soon as the CM104 enters the dormant arbitration state 732, it applies the arbitration algorithm to the net pending talkers and interrupting participants. If the arbitration algorithm determines that it is in favor of the pending talker, the CM104 transitions from the dormant arbitration state 732 to the wakeup pending state 712 and sends a PTX negative message 744 to the aborted participant. If the arbitration algorithm determines that the arbitration algorithm is in favor of the interrupting participant, the CM104 transitions from the dormant arbitration state 732 to the wakeup pending state 712, sends a PTX negative message 744 to the pending talker, and The interrupting participant is considered to be the new pending talker on the net.

As soon as the CM104 enters the hibernate state 736, it transitions from the hibernate state 736 to the announcement state 628 and sends a PTX permit response 748 to the pending talker on the net. As soon as the CM104 enters the buffered permission state 740, it transitions from the buffered permission state 740 to the buffering state 752 and sends a PTX permission response 756 to the pending talker on the net. The net state machine remains in the buffered state 752 for as long as possible unless the wakeup timer 724 has expired. While in buffering state 752, the CM104 buffers any media traffic received from the net's pending talker.

The CM104 shifts from the buffering state 752 to the announcement state 628 when the wakeup timer 724 ends. The CM104 buffers any media traffic received from the net pending talker into the net media buffer while it remains in the buffered state 752. The CM104 responds to any media signaling request containing worthless or reserved field values by sending an ERR response 760 in error state 764 to the CD352 that sent the message, and so on. If not, ignore the request.

The CD352 executes the NBS media signaling status diagram 800 shown in FIG. 16 whenever the user is online. The CD352 initializes to the startup state 804 by sending a SIP ACK message 808 to the CM104 after the CD352 accepts the net session description. CD352 transitions from startup state 804 to startup waiting state 812, and sends ASK request message 816 to CM104 immediately upon entering startup state 812.

The CD352 stays in the listening state 820 for as long as possible when the user does not press the push-to-talk button 824, the PTA message 828 is not received from the CM104, and the sleep ZZZ message 832 is not received from the CM104. The CD352 transitions from the listening state 820 to the floor request state 836 when the user presses the push-to-talk button 824. When the PTA message 828 is received from the CM104, the CD352 shifts from the listening state 820 to the talker announcement state 840. The CD352 transitions from the listening state 820 to the dormant idle state 844 when the sleep ZZZ message 832 is received from the (832) CM104. As soon as the CD352 enters the floor request state 836, it transitions from the floor request state 836 to the floor wait state 848 and sends a PTT permission request 852 to the CM104.

The CD352 stays in the floor wait state 848 for as long as possible if no PTX response message 856 is received from CM104 and the PTT abandonment timer 860 has not expired. The CD352 resets the PTT abandonment timer 860 and the PTT retransmission timer (not shown) when entering the floor wait state 848. The CD352 transitions from floor wait state 848 to talk state 864 when a PTX permit 868 response message is received from CM104, and alerts the user that the user is in control of the net floor. .. The CD352 transitions from the floor wait state 848 to the floor lost state 872 when the PTX negative message 856 is received from the CM104. The CD352 remains in the floor wait state 848 and retransmits the same PTT request 876 to the CM104 after the PTT retransmission timer has expired. The CD352 shifts from the floor waiting state 848 to the listening state 820 after the PTT abandonment timer 860 ends. If the user releases the push-to-talk button 884, the CD352 shifts from the talk state 864 to the floor open state 880 while still waiting for the PTX response.

The CD352 stays in talk state 864 for as long as possible unless the PTX interrupt message 888 is received from CM104 and the user has not released the push-to-talk button 884. The CD352 transitions from the talk state 864 to the floor lost state 872 when the PTX interrupt response message 888 is received from the CM104. When the user releases the push-to-talk button, the CD352 shifts from the talk state 864 to the floor open state 880. The CD352 remains in talk state 864 when the PTX authorization response message 868 is received from CM104. CD532 transitions from floor lost state 872 to listening state 820 as soon as it enters floor lost state 872, and gives user 892 a message indicating that control of the net floor is lost. Alarm.

The CD352 transitions from the floor open state 880 to the open wait state 896, and sends a PTT open request 900 to the CM104 as soon as it enters the floor request state 836. The CD352 stays in the open wait state 896 for as long as possible if the PTX acknowledgment message 904 is not received from the CM104 and the PTT abandonment timer 860 has not expired. The CD352 resets its PTT abandonment timer 860 and PTT retransmission timer when it enters open wait state 896. The PTT retransmission timer is activated each time there is a PTT request or release.

The CD352 transitions from the open wait state 896 to the listen state 820 when the PTX acknowledgment message 904 is received from the CM104. The CD352 stays in the release waiting state 896 and retransmits the same PTT release request 900 to the CM104 after the PTT retransmission timer ends. The CD352 shifts from the release waiting state 896 to the listening state 820 after the PTT abandonment timer 860 ends.

The CD352 transitions from the talker announcement state 840 to the listen state 820 and notifies the talker as soon as it enters the talker announcement state 840. The announcement can indicate that the new talker has floor control, the current talker has the floor open, or no talker currently has floor control.

The CD352 stays in a dormant idle state 844 for as long as possible when the AYT request message 908 is not received from the CM104 and the user does not press the push-to-talk key 824. The CD352 transitions from the dormant idle state 844 to the dormant wakeup state 912 when the AYT request message 908 is received from the CM104. The CD352 transitions from a dormant idle state 844 to a floor request state 836 when the user presses the push-to-talk key 824.

CD352 discards any sleep ZZZ message 916 received while in dormant idle 844. As soon as the CD352 enters the dormant wakeup state, it transitions from the dormant wakeup state 912 to the listening state 820 and sends an IAH response message 916 to the CM104.

When an AYT ping request 920 received from CM104 is received during any state other than the hibernate idle state 844, the CD352 saves its current state and temporarily responds to the IAH. Go to state 924, create IAH response message 928, send to CM104, and return to the previous state. The CM104 sends an ERR response 932 to the CD352 when it receives a media signaling error and enters error state 936, such as a strange request using an invalid or reserved field value.

When receiving the ERR response 932 received from the CM104 during any state, the CD352 alerts the user that an error has occurred, disables the CD352 (940), and any suitable. SIP signaling is performed to gently terminate participation in the net (944).

When the CD352 is in one of the hibernate 844s, the CD352 still receives hibernating net participants and receives point-to-point voice service calls via other IS-707 service options. May do. After the voice service call is terminated, the CD352 returns to IS-707.5 hibernate / idle 844.

However, if the net goes out of hibernation 844 while the CD352 chooses to receive a point-to-point voice service option call, the CD352 misses the AYT "wake up" message request 908. And it may be removed from the list of active participants. In such a situation, the CD352 may determine the status of its participants by sending an ASK request 382 to the CM104. Once the CD352 is removed from the list of active participants' nets, the CD352 re-registers using the CM104's SIP server to rejoin the net.

The CD352 allows users to make and receive current PSTN point-to-point calls as well as participate in group service discussions. The CD352 may work internally in one of several modes, but the CD352 is in a different operating mode environment where the user wants to be clearly navigating. , Avoid limiting to certain functions. Therefore, seamless reception between group services and the establishment of point-to-point voice service calls are enabled and activated.

The CD352 is intended to set up a point-to-point voice service or secure point-to-point packet voice calls at any time, whether the group service is active or not, unless the CD352 acts as a talker at the same time. May be used for. If the CD352 is registered as a member of the net, the CD352 will not be registered from the net. If the selected point-to-point call is placed via the voice service option, the CD352 terminates the data service. Once the point-to-point call is completed, the CD352 is clearly capable of packet data service and will be registered as a member of the current selected net.

The CD352 may be used to receive PSTN or secure point-to-point packet voice calls, while group services are enabled within the limits imposed by the cellular backbone. If the CD352 binds to the net, and the selected net is active, the CD352 looks busy for the incoming PSTN call, and the call is given proper busy processing by the cellular backbone. If the selected net is quiet, but the net hang time 620 is not over, the call will also be given normal busy processing by the Cellular backbone. However, if the hang time 620 of the selected net has expired, the net is put into hibernation mode 618, and the CD352 releases its radio resources, and the call cannot be busy processed by the backbone facility. The CD352 can then be paged to start receiving incoming calls.

While the voice service call is active, the CD352 cannot receive any NBS net traffic. After the voice service call is complete, the CD352 may be required to rejoin the net as it may have missed one or more AYT requests 716. Whenever the CD352 looks busy for an incoming voice service call, the caller will have whatever busy processing defined for the CD352 being called (forwarding the call, voice mail, etc.). Based on that, the cellular facility redirects as expected. The user is free to configure the CD352 to disable the reception of incoming point-to-point calls during the period when the net is selected and the CD352 is registered as a member.

The CD352 also detects if its IP network address must or is about to change over time. If the CD352 is on the net when the address change occurs, the CD352 will INVITE itself to the net again, as discussed for Figure 11.

For example, a moving CD352 may switch between cellular systems or cellular networks and, as a result, negotiate a new IP network address. Alternatively, the CD352 may experience a service interruption or drop a packet data service option call for some reason and when establishing a service assigned a new IP network address. If the CD352 did not join the net during the address change and reconnect to the selected net in a timely manner, the CM104 would eventually terminate its membership and select the CD352. Remove from list for net. CD352 is removed from the list of active net participants if it does not eventually respond to a series of media signaling AYT request messages 716.

In the absence of the IS-707.5 Packet Data Service option, NBS may operate on existing and generally available Quicknet Connection (QNC) packet services. However, QNC does not currently support hibernation. Therefore, application-level messages such as "let's pause" may be ignored by the CD352 running on NBS on QNC.

QNC provides a protocol stack similar to the protocol stack provided by IS-707.5. The CD352 may be configured using QNC rather than IS-707.5 to negotiate packet connections. Then, if the QNC service is available, treat the connection as a packet data service option connection without hibernation, or freely as CRTP header compression support.

Under mobile IP, the CD352 connects to the network with agents outside the area that assign care of addresses to mobile stations. The noticed address is temporary, but it is a legitimate address to which the IP datagram will be directed from anywhere on the Internet. The mobile station uses the awareness address to connect with its home agent and convey the mobile station's current awareness address to it. After confirming the identity of the mobile station, the home agent then sends a packet destined for the mobile station's permanent home address (a good internet shipping mechanism delivers it directly to the home agent or to the home agent's network). Send the mobile station's notice address to the mobile station that is using it.

NBS can operate on mobile IP, but mobile IP may have a potentially negative impact on end-to-end latency and the perceived voice quality of NBS media traffic and signaling. Absent. It may be especially important if the CD352 uses its permanent address to connect to the net and the home agent is located far from the CM104 and CD352 in the sense of network topology. In such cases, media traffic can be routed freely over the public Internet, or other service networks of valuable quality that would not have been required if mobile IP had not been used. May. To avoid this, it is preferable for the CD352 to access the NBS service using its awareness address and, if the awareness address has changed, a recombination net.

Both SIP call signaling and PGP public key cryptography use their own CD352 user id or similar unique identifier. User database 232 defines an internal user identifier that may be transferred to and used by CD352 in media signaling requests. The CD352 user id address should preferably not contain any private data whose public disclosure would undermine the existing cellular infrastructure authentication mechanism.

The CD352 user address is used as a header in SIP registration and invitation. And it may be used to form other parts of the required SIP syntax. The user address is also the input for generating the personal PGP key used to authenticate the SIP request. The CD352 user interface allows the user to view the user address. The CD352 user interface allows users to change their user address with the risk of potentially interrupting their ability to access NBS or satisfy SIP authentication requirements.

To protect against constant denial of service attacks and prevent disguise of the CD352, the CM104 may be free to require that the CD352 authenticate itself prior to registering or connecting to the net. I don't know. Authentication is performed at the application level, which may be at the network or cellular backbone level and is irrelevant for other authentication methods. CD352 authentication also runs and works independently of the concepts and data structures that support encrypted NBS nets.

In particular, CM104 may require the CD352 to include an "authentication" header along with its SIP request. The authentication header allows SIP messages to be signed by CD352 using the PGP public key cryptographic signature.

Public-key cryptography generates public and personal keys from a private private key, typically known only to the cryptographic device (CD352 in this case). The personal key combined with the private key is required to sign the message. However, only the public key can be used to verify the signature of the signed message. Therefore, to support SIP authentication, each CD352 is provided with as much personal secret and personal key as possible, which is never shared. For that, the CD352 may need to authenticate itself, each CM104 must know the public key for the CD352. Since the public key is not secret, it may be stored by CM104, stored as part of the user portion of database 232, or accessed via a common public key server on the Internet.

The CM104 may require CD352 authentication at the server, net, or user level. At the server level, CM104 requires all clients connecting to CM104's SIP server 236 (see Figure 3) to deny all unauthenticated requests and give them an authentication certificate. When server-level authentication is possible, only clients whose identity (ie, the client's public key) is previously known to CM104 may use the server efficiently. Server-level authentication can protect CM104SIP's server 236 from many relatively easy service denial attacks.

The CM104 may protect one or more nets that it (CM104) controls through authentication, while the other nets may abandon it "unprotected". If the CD352 attempts to INVITE itself to a protected net, the CM104's SIP server 236 rejects the request if the CD352 cannot be authenticated by the CM104.

The CM104 may also use authentication to ensure that the CD352 (or generally any SIP user agent client) does not attempt to disguise itself as another CD352. And for that, they may deny services to justify net participants or passively monitor the media channels of the net. If CM104 requires that a particular CD352 should be authenticated, CM104 is the client connecting as CD352 unless the client's SIP request is confirmed by CM104 and contains a PGP signature. Will not accept any SIP requests from. At the user level, authentication may be set on a per-user basis. (That is, one user may require authentication before while CM104 allows other users to remain unauthenticated.)

Once the CD352 user address is defined, the PGP personal key will be administratively prepared in or created by the CD352. Personal keys do not need to be stored externally. However, the combined public key can be installed in the user portion of database 232 of any SIP server that normally requires CD352 authentication.

In one embodiment, the first NBS CD352, or net participant platform, is a cellular handset based on the CD352MA. Since NBS is built on top of IP and IP transport protocols, any IP-acceptable platform with connectivity to CM104 is potentially NBS. Will work as a CD352. Therefore, dial-up users may connect to the CM104 via the PSTN via an existing IP terminal server operated by an Internet Service Provider (ISP) as shown in Figure 1. The terminal server acts as a bridge between the PSTN and the LAN supporting core. A terminal server includes a bank of modems, a server, and one or more network interfaces that provide a connection point for high speed PSTN modems. Each server has the ability to host one and several independent PPP sessions for each connected modem user. The server also acts as a router sending IP packets to each of the individual PPP interfaces and to any active LAN interface. Each CM104 contains an integrated (or externally deployed) commercial off-the-shelf terminal server.

The dial-up terminal server supports and includes the ability to negotiate CRTP header compression on its PPP session. Similarly, the PPP stack used by dial-up clients also includes and attempts to use CRTP. However, due to the additional bandwidth available on high-speed modems, for dial-up based users, the inability to negotiate CRTP header compression inevitably means that the net uses RTP-based payload standards. Will not force you to avoid.

If the terminal server is located on the internal LAN of the CD352NA service provider, and therefore in the sense of network topology, close to the service provider's CM104, the dial-up user will find that the route between the ISP's terminal server and CM104 is public. Crossing parts of the Internet would avoid issuing quality of service (requiring), which may contribute to high end-to-end latency. Since PSTN-based modems do not support a hibernate concept similar to that (pause concept) typically performed by IS-707.5, dial-up based net participants will not receive any dialup based net participants received from CM104. It will also ignore sleep messages. User database 232 keeps track of whether the connecting user is cellular or land-based, but this capability has already been given. Therefore, the CM104 may or may not send sleep or other media signaling messages to dial-up users.

NBS service areas are designed to be integrated to allow both users to move around between service areas, as well as to combine with equivalent nets defined within separate service areas. Peer-to-peer communication between multiple CM104s takes the form of SIP server redirection, exchange of user and net database records, and additional messages specific to integrated NBS services.

In one integrated NBS service embodiment, it may be desirable to allow any CM104 to assume ownership of the net. Therefore, the behavior of the net is not specific to a particular CM104 or MCU node 208. The choice of CM104 may be dynamically determined based on factors such as proximity to the majority of net participants and the quality of service available on the service provider's internal system network. Similarly, any SIP redirect server 236 has the ability to redirect any CD352 to the SIP user agent server of the appropriate MCU and / or, if necessary, forward the CD352 to another SIP redirect server.

In one integrated NBS service embodiment, the net address of the net has meaning through the NBS system. As a result, one or more top-level SIP servers 236 are tasked with redirecting INVITE requests and distributing net participants to the appropriate MCU nodes 208. Top-level SIP server 236 may distribute common users and net databases 232, giving them similar functionality and redirect decisions at different network collection points. As a result, CD352-initiated invitation redirection provides an important and definitive layer of abstraction that allows multiple CM104 installations to be integrated into a single uniform NBS service.

In the integrated NBS service, the system was vaguely named the combined MCU252 combination (MCU cluster), including its SIP user agent server, by copying the functionality provided by the MCU node manager 256. ) To scale. A single database 232 and management interface 248 are distributed by all elements of the system.

The process by which the CD352 is thereby connected to the net in such an integrated system is substantially similar to the process used for the system involved in the installation of a single CM104. The CD352 first sends all SIP requests to the top-level (now global) SIP redirect server 236. The redirect server 236 redirects the requesting CD352 via the SIP mechanism to the appropriate destination. For INVITE requests to join the net, the destination is the SIP user agent server 252 combined with MCU node 208, which has the current mission to the net in question. For INVITE requesting the current list available for CD352, the destination is any user agent capable of responding to the request.

Separately, the redirect server 236 may exchange additional messages with the MCU252 via interapplication messaging and using execution specific protocols and / or messaging conventions. As in the case of non-integration, special startup behavior may be required to ensure that the redirect server 236 may determine the destination for each legitimate byte request it is receiving. I don't know. One embodiment has a SIP registration that resides on top-level redirect server 236. The top-level server may also ask the system database and attempt to map each invitation request to the net definition contained therein.

The CD352 may provide encrypted internet broadcast communications. At the net user's discretion, audio and data transmitted to a particular net may be encrypted on the transmitting CD352 and decrypted by all other CDs on the net. Encryption is end-to-end, that is, from CD to another (CD). Net communications are typically encrypted by a commercial encryption algorithm coupled within an NBS-acceptable CD. The choice of whether the CD352 treats the net as encrypted or unencrypted is up to the net user. It does not require the involvement of CM104.

Users may choose, according to net-by-net criteria, how they (the user) choose whether traffic sent / received on the net should be encrypted / decrypted. Users are given the ability to enter cryptographic keys, for example for the net using a telephone keypad. As a result, the user has the ability to engage in encrypted communication with other users of the net who have opted for encryption freedom for the net and also use the same encryption key.

The user may or may not be able to encrypt the net traffic for any net key that the user puts in the CD352 at any time. Media traffic may be encrypted symmetrically by the use of symmetric keys (traffic encryption keys, or TEKs) distributed by net users. Net traffic encryption keys may be generated offline by a net user or net administrator, where they may be securely distributed to net participants who have manually locked their respective communication devices. The key is used for media traffic on a particular net until a new key is generated to replace the old net TEK and distributed to net users.

CD352 is notified by a message received from CM104 that it is a member of a particular net. The net administrator for a particular net may set a recommendation flag to indicate that the net is intended to be encrypted. This display is usually advisory and does not necessarily imply that communications on the net are actually encrypted. The CD352 user interface allows the user to indicate any net as an encrypted net, regardless of whether it is received by the encrypted advisory flag CM104 for the net, and the user can net TEK from CD352. Allows you to enter.

CD352 may enforce minimum and maximum key lengths. In addition to the key, the CD352 may provide a means for the key checksum to be entered. And if given, it checks the checksum for the entered key. If no checksum is entered, the CD352 will calculate the checksum and make it available for display to the user. The CD352 does not necessarily display the key on the CD352 display after the first key is inserted.

Once successfully entered the keyed net, media transmissions on the net are encrypted with that particular key, and all traffic received on that particular key is used with that particular key. It is decrypted. Encrypted traffic allows the CD352 to synchronize with the encryption / decryption process, slow synchronization (synchronization for transmissions already in progress), and the same traffic encryption key for sender and receiver. Includes additional headers that allow you to make sure you are using. If the CD352 receives encrypted traffic (detected by the presence of a crypto header) on a net that is not designated as encrypted, the CD352 will receive the encrypted traffic. Show the user that it is, and do not output traffic (mute audio or compress data output). Similarly, if the CD352 receives unencrypted media traffic on a net that is encrypted against it, or if the traffic is not properly encrypted (for example,). (Maybe the keys don't match), the CD352 alerts the user and silences the traffic.

The key for an encrypted net may simply be a random (binary) number. In general, keys can be generated by one party in the net, or an administrator to that net, and can be securely distributed to net participants. Since the key distribution policy is currently left for net users, it is a potential source of net security compromises. Therefore, it is recommended that the net encryption key be distributed to the net participants using secure means such as PGP encrypted email. Security Manager 20 (Figure 1) also provides a central storage location for common net keys. Other methods, such as standard telephone calls or face-to-face meetings, are also possible. The key may also be automatically distributed to the CDs using the PGP private key embedded in the communication device for SIP authentication.

The above description of the preferred embodiment allows any person skilled in the art to create and use the present invention. The various changes to these examples are readily apparent to skilled people in the industry, and the general principles presented individually are applicable to other examples without the use of creative abilities. is there. Therefore, the present invention is not intended to be limited to the examples presented herein, but to follow the broadest perspective consistent with the disclosed principles and new features.

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