System and method for providing group communication services

Background of the invention

I. Field of invention Systems and methods for providing group communication services generally relate to point-to-multipoint communication systems, and in particular to methods and devices for providing group communication services.

II. Explanation of related technologies Point-to-multipoint communication systems have long been commonly used to provide communication between a central location and a large number of users of the system. For example, a dispatch system using the Ground Mobile Radio (LMR) is used in trucks, taxis, buses, and other vehicles to communicate schedule information between the central dispatch center and one or more corresponding vehicles. ing. Communication is directed to a specific vehicle among all vehicles, or to all vehicles at the same time.

Another example of a point-to-multipoint communication system is a wireless PushTalk system. Such systems allow a group of individuals, each with a wireless phone, to communicate with other members of the group. In general, PushTalk systems rely on a single frequency, a dedicated channel, through which communication is received by the wireless phone. In many systems, only one member sends information to other members at a time. However, all members can listen to the dedicated broadcast channel and receive communications from a single member transmitting. A member attempting to send to other members of the system generally sends an access request by pressing a PushTalk button on each communication device, which allows only access to a dedicated transmit channel.

PushTalk systems are commonly used in outdoor settings, where they require geographically different groups of people, or just members, to communicate with each other in a "point-to-multipoint" manner. Examples of PushTalk system use include workgroup communications, security communications, construction site communications, and local military communications. A group of people who request communication with each other is usually known as a "net", and each member of the net is sometimes referred to as a "net member".

A typical PushTalk system uses a dedicated channel, sometimes referred to as a broadcast channel, to send communication from one member to multiple other members of the net at the same time. Generally, at any given time, only one member sends audio information to other member users. If another member attempts to transmit through that broadcast channel while another member is transmitting, there will be interference between the two competing communications and the communication being received by the other net member will not be understood. become.

In order to realize the PushTalk communication system in the conventional wireless communication system, an expensive modification is required for the infrastructure. Currently, there is at least one wireless PushTalk communication system that enables point-to-multipoint communication by undergoing such modifications. An example of such a system is planned by Motorola Incorporated in Schomberg, Illinois, marketed as the Nextel Direct Connect service, and provided by Nextel Communications in Reston, Virginia. ..

In addition to the cost issues associated with current wireless point-to-multipoint communication systems, communication is generally limited to members operating relatively close to each other using the same communication technology. In other words, point-to-multipoint communication can be from a CDMA communication system to another communication network or technology, such as a GSM communication system, to a public switched telephone network (PSTN), to a data network such as the Internet, or to a Global Star satellite. It does not extend to satellite communication systems such as communication systems.

These obstacles to providing group communication services are overcome by various embodiments of the systems and methods of providing group communication services described herein.

In one embodiment, the systems and methods of providing group communication services are implemented within existing CDMA wireless communication systems.

Point-to-multipoint communication is one of the systems and methods of providing group communication services by converting real-time audio, video and data (collectively referred to here as media) in a communication device (CD) into data packets. It is possible in the embodiment. Data packets are generated according to data protocols such as the well-known TCP / IP Internet Protocol. Media is transmitted to the data network, typically to the Internet, using air interfaces or by other means, depending on what type of communication device is used.

The communication manager (CM) enables data packets from the data network to be distributed to various net members of each specified net. Therefore, the addition of CM to the standard communication system makes group communication immediately possible. A CM is a device that functions as a configurable switch that connects communications from one user to one or more other users defined as the net. A CM is a data device, which means sending and receiving data packets defined by the particular data network to which the CM is connected. In one embodiment, the CM is directly connected to the Internet, allowing data packets to be routed between the CM and finally the CD.

CM allows users other than users in the wireless communication system to participate in group communication. For example, an audio-capable desktop computer located in an office or home can participate in group communication with one or more users of a terrestrial wireless communication system. Alternatively or additionally, users of the satellite communication system can participate in group calls with members of terrestrial wireless systems, desktop users, or both. Information between these various communication devices, such as wireless phones, wireline phones, satellite phones, paging devices, portable or desktop computers, digital cameras, camcorders, etc., is transmitted between net members through a data network coordinated by CM. Will be done.

One advantage of systems and methods of providing group communication services through traditional wireless group communication systems is the ability to deliver group communication services quickly and inexpensively in wireless communication services. For example, an IS-95 compliant CDMA wireless communication system can support group communication by simply adding a CM and a point-to-multipoint compatible communication device. Another advantage of systems and methods of providing group communication services is the ability of group communication to extend beyond the traditional boundaries of traditional wireless group communication systems. Using systems and methods that provide group communication services, users of CDMA wireless communication systems can participate in group communication with users of different communication devices and technologies.

The characteristics, objectives and effects of systems and methods of providing group communication services will be further clarified from the detailed description described below, along with drawings that identify the correspondence of the same reference characters throughout. <figref num="1">FIG. 1 is a diagram of a typical conventional wireless communication system in which group communication cannot be realized.</figref><figref num="2">FIG. 2 illustrates a group communication system of one embodiment of a system and method of providing group communication services in a functional block diagram format.</figref><figref num="3">FIG. 3 illustrates the operating protocol used in the group communication system of FIG.</figref><figref num="4">FIG. 4 illustrates a typical communication device used in the group communication of FIG.</figref><figref num="5">FIG. 5 is a state diagram illustrating various operating states of the communication device of FIG.</figref><figref num="6">FIG. 6 is a functional block diagram of the communication manager used in the group communication system of FIG.</figref><figref num="7">FIG. 7 illustrates the dialogue between the communication device of FIG. 4 and the communication manager of FIG. 6 when the communication device of FIG. 4 tries to join the net.</figref><figref num="8">FIG. 8 illustrates the dialogue between the communication device of FIG. 4 and the communication manager of FIG. 6 when the PushTalk switch located in the communication device of FIG. 4 is operating.</figref><figref num="9">FIG. 9 illustrates the interaction between the communication device of FIG. 4 and the communication manager of FIG. 6 to establish and exit the hibernation period.</figref><figref num="10">FIG. 10 illustrates the dialogue between the first communication device, the second communication device, and the communication manager of FIG. 6 while the speaker privilege is being revoked.</figref><figref num="11">FIG. 11 is a functional block diagram of the integration of the first communication manager and the second communication manager.</figref><figref num="12">FIG. 12 is a diagram of state vectors used in one embodiment of a system and method of providing group communication services.</figref><figref num="13">FIG. 13 is a diagram of the cryptographically synchronized portion of the initial RTP payload used with the state vector of FIG.</figref><figref num="14">FIG. 14 is a functional block diagram illustrating the generation of synchronous checkwords.</figref>

Detailed description of preferred embodiments

Systems and methods that provide group communication services use communication devices (CDs) that can generate data packets suitable for transmission over a data network such as the Internet. The data packet is sent to the data network and provided to the communication manager (CM) connected to the data network. The CM processes the data packets from the first CD and delivers the data packets to at least one other CD in real time, which is a member of the same predefined net as the first CD. The CM acts as a configurable switch and can route communications from any net member to other net members defined by the net.

While the teaching of systems and devices that provide group communication services describes wireless CDMA communication systems, any system and method that provides group communication services can be any wireless communication, including GSM systems, AMPS systems, TDMA systems and satellite communication systems. It should be understood that the system can be used with other communication systems. Furthermore, the systems and methods of providing group communication services are not limited to wireless communication systems. Systems and methods of providing group communication services can be used with wireline telephones, paging devices, portable or desktop computers, digital cameras, video cameras, and the like. In addition, the systems and methods that provide group communication services should be applicable to both real-time data such as audio and video data (including audio data) and time-independent data such as computer files, email, etc. Should be understood.

FIG. 1 is a diagram of a typical prior art wireless communication system 100, in which group communication, otherwise known as point-to-multipoint communication, or pushtalk communication cannot be realized. CDs 102, 104, and 106 represent three of the vast number of wireless phones that are distributed over a small geographic area handled by communication system 100. CDs 102, 104, and 106 generally transmit and receive signals to and from base stations 108 and 110 depending on their proximity to each base station. In a typical wireless communication system, there are many base stations used to support a large number of active CDs in communication system 100.

Base stations 108 and 110 are connected to a mobile switching center (MSC) 112. The MSC112 provides the wireless communication system with various functions, such as providing system control for base stations 108 and 110. In addition, the MSC112 provides switching and interface circuitry between base stations 108 and 110 and the public switched telephone network (PSTN) 114.

Group communication is generally not possible using the communication system in Figure 1. However, conference calls between multiple users in a wireless communication system can be achieved if special circuits can be used within the MSC112 to enable such conference calls. For example, the wireless telephone 116 can communicate simultaneously with the CDs 102 and 104 in a conference call. Conference calls are different from group communications, where conference calls are generally not arbitrated, that is, conference call users speak at the same time and are heard by all other conference call users. The result in this situation is generally a voice that is inaudible to each user because multiple conversations are broadcast to each user at the same time. A well-known device for achieving this type of conference call is a conference bridge.

General overview One embodiment of a system and method of providing group communication services is illustrated in the functional block diagram format of FIG. What is shown is the group communication system 200, or is known as a pushtalk system, a net broadcast system, a dispatch system, or a point-to-multipoint communication system. A defined characteristic of such a communication system is that, in general, only one user transmits information to another user at an arbitrary predetermined time. In the group communication system 200, a group of communication device users, individually known as net members, communicate with each other using communication devices assigned to each net member.

The term "net" means a group of communication device users who are certified to communicate with each other. In general, a central database contains information that identifies each particular net member. More than one net may work in 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 generally cannot communicate with the members of the second net. In other situations, members of different nets can monitor communication between members of more than one net, but can only send information to members in their own net.

Net members communicate with each other using the assigned communication devices designated as Communication Devices (CDs) 202, 204, 206, 208 and 210. In this example, CD202, 204 and 206 are terrestrial wireless telephones, CD208 is a wireline telephone with PushTalk capability, and CD210 is a satellite telephone with PushTalk capability. In other embodiments, the various CDs may include an audio device such as a wireless video camera, still camera, music recorder or player, a rattop or desktop computer, or a paging device. In other embodiments, at least one CD comprises a combination of embodiments just described. For example, the CD202 can include a wireless landline telephone with a video camera and display. Further, each CD may be able to send and receive information in either a safe mode or an unsafe (clear) mode. Throughout the description below, references to individual CDs may be expressed as CD202. However, it should be understood that the reference to CD202 is not intended to be limited to the discussion of landline phones. In general, the description of CD202 applies equally to other types of CDs.

The group communication system of FIG. 2 defines an exclusive transmit privilege, which generally allows only one user to transmit information to other net members at any given time. This send privilege is granted or denied to the requesting net member, depending on whether the send privilege is currently assigned to another net member when the request is received. The process of allowing and denying send requests is known as arbitration. Other arbitration schemes evaluate factors such as the priority level assigned to each CD in deciding whether the requesting net member is granted transmission privileges.

To participate in group communications, CD 202, 204, 206, 208 and 210 each have means of requesting transmission privileges from Communications Manager (CM) 218, described in more detail below. CM218 manages real-time administration behavior of the net. This includes overall control of net status, as well as PTT request arbitration, maintenance, net membership and registration list delivery, call setup and teardown of required system and network resources.

The CM218 maintains a list of regulatory nets, defined as either clear or secure, and a transition between clear and secure is generally not allowed. Security Net relies on the encryption provided by the CD to provide protection against authentication and eavesdropping. Encryption for secure nets is implemented on an end-to-end basis, which means that encryption and decryption occur within each CD. The CM218 generally works without knowledge of security algorithms, keys, or policies.

The CM218 is designed to be managed remotely by a communication system service provider, netmembers, or both, assuming that authentication is provided by the service provider. The CM218 may receive net provisions through the external administration interface 226. Net members may request administrate actions through their service provider, or administrate net functionality through a defined system such as Member Behavior Security Manager (SM) 228, which is compatible with the CM218 administration interface. The CM218 can certify against high-grade commercial standards in which any party attempts to establish or modify the net.

The SM228 is an optional component of System 200 that performs related tasks to support key management (ie, delivery of encryption keys to net members), user authentication, and secure nets. A single group communication system may interact with one or more SMs. SM228 is generally not involved in real-time control of the net, including net activation or PTT arbitration. The SM228 has administrative capabilities compatible with the CM218 interface and may automate administrative functions. The SM218 may be able to join the net, broadcast the net key, or simply act as a data endpoint to monitor net traffic.

In one embodiment, the means for requesting transmission privileges include a PushTalk (PTT) key or switch. When a user in the communication system 200 tries to send information to another net member, when the push talk switch located on the user's CD is pressed, the communication manager 218 sends a request to acquire transmission privilege. Will be done. If no other net member is currently assigned send privileges, the requesting user will be granted send privileges and will be notified via a CD with audible, visible, or tactile alerts. Information is sent from the requesting user to other net members after the sending privilege has been granted.

In one embodiment of a system and method of providing group communication services, each wireless net member optionally establishes forward and reverse links with one or more base stations 216 or satellite gateways 212. The former is used to describe the communication channel from base station 216 or satellite gateway 212 to CD, and the latter is used to describe the communication channel from CD to base station 216 or gateway 212. Voice and / or data is converted to a data packet using a CD, which is suitable for a particular data network 214, through which communication to other users occurs. In one embodiment, the data network 214 is the Internet. In other embodiments, dedicated forward channels are established in each communication system (ie, terrestrial and satellite communication systems) to broadcast information from each net member to another net member. Each net member receives communication from other net members through a dedicated channel. In yet another embodiment, a dedicated reverse link is established in each communication system to transmit information to the CM218. Finally, a combination of the above schemes may be used to establish, for example, a dedicated forward broadcast channel, but the wireless CD may be required to send information to the CM218 over the individual reverse links assigned to each CD. ..

When the first net member wants to send information to other members of the net, the first net member requests send privilege by pressing the PushTalk key on his CD, which is sent over data network 214. Generate a formatted request to do so. In the case of CD202, 204 and 206, the request is transmitted wirelessly to one or more base stations 216. The MSC220 comprises a well-known (not shown) interworking function (IWF) for processing data packets, including requests, between the MSC220 and the data network 214. For CD210, the request is sent through satellite to satellite gateway 212. For CD208, the request is sent to the Public Switched Telephone Network (PSTN) 222 and then to Modem Bank 224. The modem bang 224 receives the request and provides it to the data network 214.

If no other member currently holds the send privilege when the send privilege request is received by CM218, the CM218 sends a message to the requesting net member, indicating that the send privilege has been granted. Notice. Audio, visual, or other information from the first net member may be sent to other net members by sending the information to CM218 using one of the transmission paths just described. In one embodiment, the CM 218 replicates the information and provides the information to the net member by transmitting each copy to the net member. If a single broadcast channel is used, the information needs to be replicated only once for each broadcast channel used.

In an alternative embodiment, the CM218 is embedded in the MSC220 so that data packets from the support base station are routed directly to the CM218 without being routed to the data network 214. In this embodiment, the CM 218 is still connected to the data network 214 so that other communication systems and devices can participate in group communication.

In one embodiment, CM218 maintains one or more databases with individual net members to manage information related to each regulatory net. For example, for each net member, one database contains the username, account number, phone number or dial number associated with the member's CD, the mobile identification number assigned to the CD, and the member actively joining the net. Current member status on the net, such as whether or not, the preferred code that determines how sending privileges are assigned, the data phone number associated with the CD, the IP address associated with the CD, and the member for which net. May include an indication of whether it has been authorized to communicate. Other related types of information may also be stored in the database for each net member.

Detailed explanation Interfaces to the system are grouped into functional and physical interfaces. The physical interface is not specific to the group communication system 200 and consists of existing wireless air interfaces, wireless service options, and commercial data network standards. Functional interfaces at higher layers, especially those at the application layer, are specific to group communication services.

At the application level, systems and methods that provide group communication services operate against three Internet-based protocols in one embodiment shown in FIG. Of course, other protocols, or different numbers of protocols, can be used in alternative embodiments. Communication between CM218 and CD202, 208 and 210 occurs within these protocols. CDs discover, join, leave, and learn about various nets using a first protocol known as Session Initiation Protocol (SIP). This session initiation protocol is a well-known signaling protocol used in the telecommunications industry. As NBS media signaling, the second protocol shown in Figure 3 is used to manage real-time net arbitration and hibernation. This will be explained later. Audio, including audio, video, or data (collectively referred to here as media), is delivered individually as media traffic through a third protocol shown in FIG. In the example of Figure 3, the CD202 currently "has a floor", that is, has transmission privileges, or permission to send media to the net. A "floor control" request is a request for transmission privileges. While CD202 retains send privileges, the remaining net members shown on the right are designated as listeners and do not have the corresponding permission to send media to the net. In general, any CD can transmit media signaling or SIP signaling traffic at any time, with or without transmission privileges.

In one embodiment, CM218 includes modem bank 224, which interfaces with PSTN222. In another embodiment, the modem bank 224 is located away from the CM218. CDs that interface to CM218 through this interface can run against the well-known Point-to-Point Protocol (PPP), or optionally one of several standard dial-up modem protocols available. Establish an IP connection to the CM218 using the equivalent link layer protocol.

In one embodiment, the CD202, 204 and 206, respectively, provide a data packet connection to the CM218 according to the IS-707.5 IP packet data service option. IS-707.5 is a well-known interim standard that describes packet data services in CDMA communication systems. This change to the Internet may be made to optimize group communication performance. Changes to the infrastructure side of this interface are undesirable, except for potential requirements for RTP / UDP / IP header compression at base stations to support media broadcasts using RTP (Real Time Transport Protocol).

Alternatively, CD202, 204 and 206 can support most group communication activities using QuickNet Connect (QNC) and IS-707.4, as described below.

The CM218 communicates with CDs participating in group communication through transport and group communication application layer protocols. These communications include real-time voice media packet streams delivered by CM218, along with application signaling (PTT transmission privilege request, net registration, etc.). All real-time media is delivered through the dynamic RTP / UDP / IP interface on CM218 and CD. If CRTP header compression (a well-known header compression technique) is not available, real-time media is encapsulated directly within a UDP / IP packet or datagram. All real-time signaling occurs through the dynamic UDP / IP interface on CM218 and CD. Other signaling, such as TCP / IP between CM218 and CD, uses the well-known Session Initiation Protocol (SIP), an application-level call signaling protocol designed to support Internet telephony. It may occur through a predetermined data protocol interface.

The CM218 provides an external user interface for communicating with external users using the same transport and group communication application layer interfaces used to interact with the CD208. However, these protocols do not work through IP / PPP and dial-up modem connections.

The CM218 provides an administration interface, which is an application-level protocol that uses hypertext markup language (HTML) semantics to provide administration access to CM users, net and administration databases and related parameters. In one embodiment, the interface works for TCP / IP. There may also be a second network interface that supports the administration function. This second administration interface supports most of the real-time transmission of administration information, including membership lists and network status reports, to Java or similar client administration applications.

The SM228 communicates with the CD using a rekeying protocol that operates over TCP / IP.

One embodiment of a system and method of providing group communication services operates through standard air interface IP packet data services, such as those specified in IS-707, and traditional IP. One traffic channel is assigned to each registered CD while the net is active, that is, while media is being transmitted between members. Each net is defined and identified by its name. This name specifies the destination address when combined with the host system address, which can be expressed in the form of a SIP URL. As mentioned earlier, SIP (Session Initiation Protocol) is a well-known signaling protocol used to control setup and signaling between CD and CM218. SIP The URL can be specified as sip: &lt;net&gt; @ &lt;nbsdomain&gt;. Here, net indicates the name of the net specified in the situation of the group communication system indicated by nbsdomain. The net name is an alphanumeric tag, which uniquely identifies the net in the communication system. nbsdomain is a virtual system domain (or subdomain) that defines the address space in which the net address of each net resides. Along with nbsdomain, the names of all nets available on the system are defined through privileged CM218-based administration actions.

For example, the net localpolice defined within the domain nbs.acme.com has the corresponding net address of sip: localpolice@nbs.acme.com.

The group communication system domain includes top-level SIP redirect servers. This server maintains SIP registration for the domain and acts as an initial rendezvous point for all SIP signaling. Top-level servers may consist of multiple servers that act as a single logical entity and share a common dataset to provide guarantees of reliability and scalability. In addition, the group communication system domain may include a logically independent top-level SIP (redirect) server. This is to ensure that each CD maintains the Internet network address of both the primary and secondary top-level SIP servers.

FIG. 4 illustrates the CD202 used in one embodiment of a system and method of providing group communication services. Further details of CD202 can be found in the reserved U.S. Patent Application No. 09 / 518,776, entitled "Methods and Devices for Participating in Group Communication Services in Existing Communication Systems," filed March 3, 2000. This US patent application may be assigned to the assignee of the system and method of providing group communications services and is incorporated herein by reference. In this embodiment, the CD202 is a wireless telephone capable of converting media, typically human voice, into data packets suitable for transmission through a data network 214 such as the Internet. Many features built into the CD202, such as those shown in FIG. 4, may be realized in any communication device, the CD202 is intended to be limited to the wireless telephones shown in FIG. You should understand that it is not what you are doing. The CD202 typically has an antenna 400, a display 410, a key 420, a speaker 430, earphones 440, and an optional PushTalk (PTT) switch 450. The display 410 and the key 420 are collectively referred to herein as the user interface. In an alternative embodiment, the CD202 may use one of the existing keys 420 as the pushtalk switch when communicating in pushtalk mode, instead of using the dedicated pushtalk switch 450.

The CD202 may also be provided to send and receive data communications by integrating with any data processing device such as a portable or fixed computer system, location reporting system, or meter reading system. The CD202 may interface with such a data generator using an interface cable. One end of the interface cable is connected to the data processor and the other end is connected to the communication port (not shown) on the CD202. Alternatively, the required internal components of the CD may be integrated into a data processor to form a single unit suitable for transmitting and receiving data and / or voice communications in an integrated package. In either case, the CD202 can be used to send data from the data generator to one or more net members, to one or more non-net members, or a combination thereof.

The CD202 can generally communicate using one or more modes of operation or "service options". However, it should be understood that any embodiment of the system and method of providing group communication services does not depend on a communication device having multiple communication modes. Make a standard audio call from CD202 to base station 216 using the first service option. A typical point-to-point telephone call is made using the voice service mode and using the predetermined technology of the related communication system. For example, the voice service option for CD202 is related to point-to-point audio communication using IS-95A. IS-95A is a well-known CDMA communication standard published by the China Communication Industry Association. The voice service option for the CD208 is related to standard point-to-point telephone calls that use the PSTN222 to connect to other wireless or wireline telephones.

The second service option is specified as a data service option. It can be further subdivided into at least three types of data services. That is, it can be divided into packet data service, asynchronous data service and synchronous data service. In CDMA communication systems, asynchronous data services are described by IS-707.5, while synchronous data services are described by IS-707.4. Various data service options are alternative realized using technologies applicable to other different types of communication systems, such as GSM systems.

Both types of data services use a data protocol to allow the CD202 to communicate with the MSC220, rather than transmitting information using traditional voice service modes. As mentioned above, MSC220 includes IWF. This IWF routes data packets between CD202 and CM218. The CD202 includes a circuit that accepts information such as audio, video, and data and converts this information into data packets according to a data network protocol such as the well-known TCP / IP protocol.

When used in voice service mode, net members use key 420 to enter data into CD202. The data generally has an identification number, such as the telephone number of a second communication device, owned by the person with whom the user wants to communicate. The key 420 is used with the display 410 to select various communication options. For example, if a member enters a packet data service option and wants to join a particular net, use the menu of options visible on display 410 and select one of several possible nets. Key 420 for this may be used. CD202 keeps a list of nets inside. This list of nets represents a set of known nets to which CD202 can participate. Alternatively, the CD202 may also maintain a list of all possible nets, whether or not the CD202 can participate. The list may be updated as needed during the interaction with CM218. The list held by the CD202 is similar to the functionality of the phone book mechanism, which is a list of names and dialed numbers typically held on a standard wireless telephone. The list of nets can be integrated with the phone book mechanism, which allows the action of selecting a net from the netlist to instruct CD202 to attempt to join the selected net.

The net may be designated as either safe or clear net. Clearnet is a net that does not employ wireless eavesdropping security guarantees such as encryption, while secure net is equipped with equipment that provides encryption. The safety net will be described later.

To join a particular net, CD202 initially requires that CM218 add the CD202 to the list of connected net participants for the intended net. The term "connected" means a user who has registered with CM218 and is at least receiving communications that occur on the net. Thus, the CD202 can initially know or learn the net address of any net that the CD202 wants to participate in. In addition, the CD202 initially knows the address of the top-level server to which the SIP request can be sent, or can be configured with this address.

In one embodiment, the CD202 is pre-programmed with the address of a known or default top-level SIP server, which server provides the current list of nets that the CD202 is authenticated to join. Can be done. Alternatively, the CD202 may be preprogrammed with a group list that specifies at least one net address of which the CD202 is a member. CD202 can then send a request to the top-level server SIP to update its group list. In an alternative embodiment, the CD202 does not include pre-programmed SIP address or group list information. In this embodiment, the user is provided with a top-level SIP server and net address, and key 420 is used to enter this information into CD202 through dialogue. The user can also enter additional net addresses in the group list. An entry has already been programmed for this net address. This embodiment is similar to entering an individual's name and dial number into the phone book of a conventional wireless telephone.

In one embodiment, the CD202 is pre-programmed with the IP network address of a major Domain Name Service (DNS) server. CD202 can send DNS questions to this DNS server. Generally, the address of a DNS server operated by a CDMA cellular carrier is pre-programmed. The CD202 may also be pre-programmed with the IP network address of the alternate DNS server.

To support SIP authentication, the CD202 can use secure measures such as Pretty Good Privacy (PGP). The CD202 is pre-programmed with a unique PGP user ID and private key, which can be used by the CD202 to sign SIP transactions when requested by CM218. The PGP user ID can also be used as a CD202 user address for common SIP transactions such as solicitation messages.

CD database Generally, each CD holds a database that stores information related to group communication. For example, a database stores a list of nets on which a CD can participate, known as a group list. A CD database can store up to 25 entries or more.

In one embodiment, each entry in the CD database contains the following fields: 1. Net address The official SIP net address of the net, used to require the CD to join the net as an active participant. 2. Net Security Advisory Flag A clear / secret advisory flag to indicate that the CM218 SIP server delivers on the list of available nets or that the user has specified the nets to carry secret media traffic. Set. 3. Net traffic encryption key A traffic encryption key used to encrypt and decrypt all media traffic for secret nets. 4. Hibernate reconnection timer The period of seconds that the CD waits after transitioning to the connected state until the data call remains active and the base station is in hibernation until it confirms that the connection has not been unilaterally interrupted. Length of.

Search and participate in the net By using call signaling specified by Session Initiation Protocol (SIP), the CD202 can join and leave the net. Each CD202 is provided with a net address and a list of one or more top-level SIP server addresses. If the group list is empty, the user can identify the address of an existing net through dialogue. If the top-level SIP server is not specified, the user can identify the address of the top-level SIP server through dialogue.

Once the top-level SIP server address is known, the CD202 may request a list of available net updates by making a call to a predetermined SIP destination using the SIP "solicitation" command. The top-level SIP server may redirect the request to an internal destination or respond to the request directly. The solicitation response to this call includes the current list of nets available to CD202. CD202 uses this list to update the internal group list.

After the net is selected, CD202 attempts to join the net through the SIP solicitation method by identifying the net address as a solicitation destination and sending a request to a top-level SIP server. The top-level server attempts to map the net address to a known destination, and if successful, redirects the CD202 to the corresponding SIP user agent server destination. This destination is associated with the branch control unit (MCU) currently applied to the net, which is part of the CM218, which is responsible for managing net traffic. If the mapping fails, the solicitation will fail.

Normally, the destination SIP user agent server confirms that the CD202 has been authenticated to join the selected net and responds to the solicitation. This response embeds a description of the media traffic and signaling parameters used to join the net. If CD202 cannot be identified as a legitimate member of the net, or if some other error condition occurs, such as a failure that prevents normal net operation, CM218 may reply with an error. If the solicitation is accepted, CD202 acknowledges the response through the SIP ACK command. It should be noted that while the solicitation is being processed, other temporary answer codes indicating the progress of the call can also be received by the CD202.

CD202 serves to update its group list for a set of nets that it can participate in. The user can have the CD202 query the CM218 to receive updates to the CD202's group list, even if no net address is selected. If the CD202 determines that it has been added to or removed from the net, the CD202 will briefly display an appropriate message to the user (eg, added to the "Group" Welders "(WELDERS)". "), And / or perhaps prompt user interaction. If CD202 determines that it is not a member of any net, CD202 will notify the user of a similar notification. CD202 will automatically add to its group list. The net address may be fetched, but the user may be prompted and then the net address that has lost membership may be removed from the group list.

Only one net in the group list of CDs can be selected at any given time. The default net may be initially selected, but the user may select the net from the group list.

CM218's SIP user agent server response to a solicitation request to join the net will include the signaling destination address of the net media and real-time media as embedded content, as well as other net parameters (eg, media payload format descriptors). Is included. Once confirmed, the CD202 will display feedback to the user for a short period of time. This feedback indicates whether the user has listening-only privileges and enables group service functionality. If CM218 determines that CD202 is not a member of the selected net, or if an error or other exceptional situation occurs, CM218 will return a corresponding error response. If such registration is rejected, the CD202 will briefly display the corresponding error message and the group service function will remain in a standby state.

Active group communication FIG. 5 is a diagram showing some states in which a CD may exist during operation. Of course, other configurations are possible. It is understood that the state shown in Figure 5 is applicable to any CD, with the exception that the hibernate state specified below does not generally apply to CDs that do not communicate using data services. It must be.

When powered on, the CD goes into standby 500. In this state, at least one service option, such as a voice service option, is possible, but instead the CD202 can operate with any desired service option. After joining the net, the CD initializes and opens its Real-Time Protocol (RTP) media traffic channel and a separate group communication media signaling channel to the CM218 destination address provided in a normal solicitation response. When these channels are initialized, the group service is started on the CD, and the CD can receive media traffic from the net and request permission to send voice traffic, the group service silence state. Enter 502.

With the group service active, the CD monitors its own media traffic and signaling channels to the CM218. Audio data received on the media channel is decoded and provided using speaker 430 or earpiece 440 according to the current user configuration. The CD can display the identification information of the current speaker, which is identified through real-time media signaling. If the current speaker's identity is not available, the CD may display the name of the selected current net listed in the group list. The CD also creates a statistical table of media traffic (eg, total elapsed time for conversation, listening, and monitoring, estimated loss of media traffic received packets), and menu options make these available to users as diagnostics. May be good. While receiving traffic from the net, the CD transitions to group service listening state 504 and returns to silence 502 when voice traffic ceases.

At any time, the user can request that the CD be allowed to talk to the net by pressing the PTT button and signaling the floor control request to the CM218 (particularly the net MCU). CM218 responds by allowing or denying the request. If the CD has listening-only privileges (ie, the CD has a priority level of zero within the selected net), the request is rejected. If rejected, the CD may alert the user with an error tone, display one or both of the appropriate error and explanatory messages, and return to silence 502. In one embodiment, the CD directs the PTT switch 450 to be released and then pressed again to attempt another floor control request. If the request is granted, the CD enters group service conversation state 506, signals the user with a short audible tone, and begins sending media traffic to CM218 as long as the PTT switch 450 is pressed. At any time, CM218 may signal CD202 that it has lost control of the floor. Upon receiving such a signal, the CD202 stops transmitting media traffic and warns the user of an error until the PTT switch 450 is disengaged. At this point, CD202 returns to silence 502. Alternatively, when the PTT switch 450 is released, the CD202 signals CM218 that it has released the floor and returned to silence 502.

Whether the group service in CD202 is in silence 502, listening 504, or hibernation 508 as described below, users can move to a different net by selecting another net from the group list. You can switch. When a new net is selected, the CD202 signals CM218 to remove it from the current net through the SIP call setup mechanism and joins the new net according to the above procedure. If the procedure to join the new net fails, CD202 is no longer a member of any net and the group service in CD202 returns to standby state 500.

If CM218 determines that the CD202 requesting a floor of a particular net is the only registered member of that net, the CM218 rejects the floor control request and the CD202 is the only registered net, called a lonely user error. Signal a display indicating that you are a member. This error is displayed to the user by CD202. The net exists with only one registered member, but the net generally does not relay media traffic unless there are at least two registered members.

When any CD has a net floor, the net is said to be active, otherwise the net is inactive. If the net is inactive for a period of time that exceeds a predetermined time interval called the net hang time, CM218 puts the net into hibernation mode 208 by signaling all registered CDs individually, IS- Release the radio traffic channel described by 707.5 or any radio data service used. Sufficient condition is maintained so that floor control requests or other traffic can recover the net from hibernate mode 508 relatively quickly. Net members may ignore the "pause" message. CM218 does not explicitly or implicitly track the hibernation of individual net members.

Generally, when a normal floor control request is received during hibernation, the CM218 "wakes up" the net and recovers from hibernation mode 508. As soon as the floor control request is granted, the CM218 signals each registered CD and initiates an internal wake-up timer by requesting an "AYT" response through the media signaling channel. In one embodiment, each CD is required to confirm receipt of AYT to CM218 if it wants to remain registered on the net. Optionally, the hibernate CD202 may buffer media traffic from the time the user presses the PTT switch 450 until the traffic channel applied to the CD202 is (re) connected. The CM218 can buffer media traffic received from the talking CD202 until the wakeup timer exceeds the wakeup timeout, at which point each registered CD (in one embodiment, still responds to AYT requests). Start forwarding media traffic to (including any member that is not). The CM218 periodically resends the AYT request to any registered CD that has not been confirmed to receive AYT. When the wake-up timer exceeds a second longer time interval called the "late riser" timeout, the CM218 unregisters any member CD that is not processing the AYT confirmation and stops the wake-up timer. CM218 ignores duplicate AYT responses.

When the CD attempts to join the currently dormant net, CM218 processes the request normally and then signals CD202 to dormant. The signaled CD may ignore the pause instruction.

Dialogue with point-to-point services The CD202 allows users to initiate and receive traditional PSTN point-to-point calls, similar to joining a group communication. CD202 generally supports at least group communication applications and one or more point-to-point applications. Therefore, one embodiment of a system and method of providing a group communication service can seamlessly receive and make a point-to-point voice service call while the group service is available and activated. To do so.

The CD202 can be used to make point-to-point voice services or secret point-to-point voice data calls at any time, regardless of whether the group service is active or not, as long as the CD202 does not act as a speaker at the same time. .. If the CD202 is registered as a member of the net, the CD202 must be unregistered from the net when making point-to-point calls. If the selected point-to-point call is made through the voice service option, the CD202 may also terminate the data service. Once the point-to-point call is complete, the CD202 will enable the data service to be transparent and can be re-registered as a member of the currently selected net.

While group service is possible, the CD202 may be used to receive PSTN or secret point-to-point data / voice calls, within the limits imposed by a particular air interface cellular infrastructure. If the CD202 is on the net and the selected net is active, the CD202 will indicate to the incoming PSTN call that it is busy, and this call will be properly busy processed by the Air Interface Cellular Infrastructure. If the selected net is silent, but the net hang time is not over, this call will also be normally busy processed by the air interface cellular infrastructure. However, if the selected net hang time has expired, the net is in hibernation mode, and the CD202 is freeing its radio resources, the call will not be busy processed by the infrastructure. , CD202 may be paged to start receiving incoming calls.

In one embodiment, the CD202 cannot receive any net traffic while the voice service call is active. The CD202 may be required to (re) join the net after the voice service call is completed, as it may have missed one or more AYT requests.

Whenever CD202 indicates busy for an incoming voice service call, the caller is requested, based on the busy processing specified by the cellular infrastructure for incoming CDs (call redirection or voicemail). Is redirected.

When the net is selected and CD202 is registered as a member, the user can optionally configure CD202 to prevent incoming point-to-point calls from being received.

Communication manager FIG. 6 shows a functional block diagram of the CM218. Further details of CM218, entitled "Methods and Devices for Enabling Group Communication Services in Existing Communication Systems," are pending US Patent Application No. 90 / 518,622, filed March 3, 2000. It is taken over by the transferees of the systems and methods that provide the group communication system and is incorporated herein by reference. The CM218 supports at least three logical external interfaces, and in one embodiment, they are all IP-based and may have multiple instances, all operating at the same time. The SIP interface is provided by the SIP User Agent Server 600. Real-time media signaling and control is supported by one or more media control units (MCU) 602. The administration function is supported by a combination of CLI and HTTP server and is shown in Figure 6 as the administration interface 604.

Internally, the MCU602 is managed by a control function, which applies the MCU602 to the net and the SIP solicitation to the MCU. Local memory 606 stores information about individual net members (referred to here as a user database) and information about various nets (referred here as a net database). External access to local memory 606 is controlled through administration interface 604.

We do not assume that the CM218 is configured as a single physical entity or several entities connected via a fast internal communication path. For example, it may be necessary to dedicate special purpose hardware to handle real-time media switching loads, or to use a physically separate database engine to manage local memory 606. Similarly, the top-level SIP redirection server 610 and global database 612 may be separated from media or administration functions and configured as independent entities.

In one embodiment, CM218 has a SUN workstation model NETRA T1. However, in alternative embodiments, the CM218 may be configured with any hardware configuration, including discrete components, one or more ASICs, other computing systems, computer architectures, and state machines, as well as a variety of these. Including combinations. In addition, it will be apparent to those skilled in the art concerned that the CM218 may consist of software or firmware.

Both the top-level SIP redirect server 610 and the SIP user agent server 600 associated with the MCU require access to system-specified user and net information. In particular, the top-level SIP redirect server 610 either queries the global database 612 or makes an explicit SIP registration to redirect incoming solicitation requests to the corresponding appropriate destination (often the user agent server 600). Either is possible. Similarly, the SIP user agent server 600 accesses the local memory 606 to authenticate the user, confirm the user's access to the net, and request that the session description of the net be specified.

As the MCU is applied to the net by the redirect server 610, the local memory 606 receives user and net information from the global database 612. After the information is provided to local memory 606, this user and net information is provided to the administration interface 604, user agent server 600, and / or MCU control 608 as needed.

MCU control 608 monitors the operation of individual MCUs. Individual actions include controlling startup and / or shutdown, applying the net to MCU602, sharing status information between local memory 606 and various CDs and / or administration interfaces 604. The MCU602 is generally a digital signal processing device capable of executing a set of program instructions stored in a memory such as ROM.

The MCU602 is responsible for receiving incoming data packets from the transmitting CD and transmitting duplicate copies of the received data packets to other members of the net to which the transmitting CD belongs. As each data packet is received by the MCU 602, it is stored in memory (not shown). The sending CD can be identified by examining the data packet. In one embodiment, each data packet contains an IP address that represents the CD being transmitted for identification purposes.

After the transmit CD is identified, MCU Control 608 retrieves a list of net members belonging to the net associated with a particular MCU 602 from local memory 606 (each MCU applies to only one net). The destination address is associated with each active net member, that is, the net member currently registered in local memory 606 by MCU602. In one embodiment, the destination address is an IP address. MCU Control 608 then creates a duplicate of the original data packet, except that the destination address identified in the data packet is modified to affect the destination address of the first net member. The MCU control 608 then creates a second duplicate data packet addressed to the second net member. This process continues until the original data packet is replicated and sent to all active net members identified in local memory 606.

PSTN user interface As mentioned above, the CD202 includes a wireless telephone in one embodiment. However, many of the embodiments of systems and methods that provide group communication services use extended IP and IP transfer protocols, so any IP-capable platform with a connection to CM218 could potentially be as a CD. Can work.

Thus, dial-up users (ie, users who operate devices that communicate primarily through the PSTN) may connect to the CM218 through an existing IP terminal server operated by an Internet Service Provider (ISP). The IP Terminal Server acts as a bridge between the PSTN and a local area network (LAN) that supports IP. An IP terminal server consists of a bank of modems, which provides a point of connection for PSTN modems, servers, and one or more network interfaces. The server can host multiple independent PPP sessions, one for each connected modem user. The server also acts as a router, which routes IP packets between each of the individual PPP interfaces and any active LAN interface. An integrated IP terminal server is used in one embodiment and an external IP terminal server is used in the alternative embodiment. Both server types are commercially readily available.

Ideally, the dial-up terminal server should support the ability to negotiate CRTP header compression throughout the PPP session. Similarly, the PPP stack used by dialup clients also contains CRTP and the use of CRTP must be attempted. However, the inability of dial-up-based users to negotiate CRTP header compression due to the additional bandwidth available through high-speed modems does not necessarily force the net to avoid using RTP-based payload specifications. It's not a thing.

If the terminal server is located on the cellular service provider's internal LAN, and therefore is close to the service provider's CM218 in the sense of network topology, the dial-up user is between the ISP's terminal server and the CM218. In between, you can avoid quality of service issues that contribute to high end-to-end latency when the path goes through a portion of the Internet.

PSTN-based net participants join the net in a similar manner, following the same SIP registration procedure outlined for wireless users, complying with similar media signaling protocols, and based on net session descriptions. , And encapsulate the packet within RTP or UDP according to the payload specifications described above.

Since PSTN-based modems generally do not support the concept of hibernation as described above, dial-up-based net participants generally ignore any sleep messages received from the CM218.

CM database In one embodiment, CM218 maintains at least two separate databases, a net database and a user database. Both of these databases acquire information that supports net activity, stored in local memory 606 and / or global database 612. Information that supports administration activities and privileges may be stored in either database or in a functionally separate third database.

User database The user database keeps track of individual users in the group communication system. The user record contained in the CM database may or may not be a member of the net specified in the CM218 net database.

Each record in the user database has one or more fields that store the relevant data for each CD. In one embodiment, each record has a username field, a user ID field, a vocoder list field, a dial number field, a user type field, a CD user address, and a CD PGP public key. One or more other fields may also be used. Of course, in other embodiments, each record may have information different from that disclosed above.

The username field identifies a formal name such as "Jane Doe" associated with a particular CD202. The user ID field is a unique code such as "17882" that further identifies the user. The vocoder list field identifies the list of vocoders supported by the CD202 associated with the user. This list may include vocoders that are not supported by the group communication system. The dial number field identifies the dial number applied to the CD202 applied to the user. This field is blank or null for Internet users, i.e. CDs that do not support standard voice services. The user type field indicates whether the user is a cellular user or a general Internet user. In one embodiment, a user connected to the CM218 via PSTN dial-up is considered a general Internet user. The CD user address field identifies a unique user address for CD202. A CD known by multiple user addresses generally has multiple corresponding entries in the user database. The CD PGP public key field stores the PGP public key associated with the CD202 user address. Alternatively, other types of keys can be stored in this field.

Net database The net database defines a set of known nets for CM218. The net database also lists the defined members of each net who are users who request participation and become participants in the net. Each record in the net database has one or more fields that store the relevant data corresponding to each net. In one embodiment, each record has at least one net identifier field, net address field, net owner field, net security field, arbitration scheme field, net bocoder field, PTT failsafe field, hang time timeout field, PTX pause. It has a response timeout field, a wakeup timeout field, a raterizer timeout field, an AYT timeout field, a media channel field, and a net membership field. More fields may be added, or the number of fields does not necessarily depend on the characteristics and functionality of a particular application. Each field is described below.

The net identifier field has a unique identification code that identifies a particular net within the context of CM218. The net address field has the SIP compatible net address of the corresponding net. The net owner field has a list of users identified by the user identifier, and this user has administrative privileges on the corresponding net. The net security status field has an indication of whether the corresponding net is clear or confidential. In alternative embodiments, this field can identify different levels of security, such as none, confidentiality, and secrecy. The arbitration scheme field has a unique value that identifies the arbitration scheme used to resolve PTT arbitration conflicts between net participants. The net vocoder field has a value that identifies the standard vocoder indicated in the advertised session description on the net. Net members incorporating such vocoders into CD202 have vocoders listed in their list of supported vocoders. The PTT failsafe field has the maximum amount of time a net participant can send media to the net until the CM218 revokes the speaker privilege. The hang time timeout field has the maximum amount of time the net can remain in standby until the CM218 hibernates the net. The PTX pause response timeout field has the maximum amount of time CM218 waits between granting the pause net speaker privilege and sending a PTX message to the requesting CD. The wakeup timeout field has the maximum amount of time CM218 waits for a net participant to respond to an AYT "wakeup" message before allowing an outstanding PTT request. The raterizer timeout field causes CM218 to remove unresponsive CDs from the list of active participants on the net. By, the CM218 has the longest time to wait for the CD to respond to the CM218's AYT "wakeup" message. The AYT timeout field has the maximum time CM218 waits for the CD to respond to the AYT "wake up" message before CM218 removes CD202 from the list of active participants on the net. The media channel list field contains a list of media channels for the net, including payload specifications. Each net generally lists at least one media channel that carries audio. The secret net can list a second data channel. The net membership field has a list of defined members of the net and associated net-specific privileges.

As mentioned above, the membership field of the net defines a set of users who can make a request to join the net as a participant. Each entry in this field may have additional information and an authentication list for each net member, such as priority level. Other information may be specified for each member as well. Priority levels are commonly used by the net's PTT arbitration algorithm to resolve PTT conflicts. Priority levels may be specified to allow listening-only privileges. The authentication list specifies the authentication privilege if the user has the authentication privilege to the net. Privileges may include the ability to add, edit, and modify entries to the net membership list, as well as the ability to modify other net parameters.

Net administration CM administration interface In one embodiment of a system and method of providing group communication services, the CM218 includes an independent administration interface 604 through which the CM218 is managed to obtain real-time status reports on the operation of the CM. .. Other variants are possible. The administration interface 604 consists of two network ports, the TCP / IP-based Hypertext Transfer Protocol (HTTP) interface, which supports administration access through a traditional Java® Capable Web Browser, and TCP. / IP-based group communication specific command line interface (CLI).

Administration features are supported through a TCP / IP-based CLI. Prior to granting access to the CLI, well-known technology is used to authenticate potential administrators connecting to the CM218's CLI interface.

The CLI can be contacted on a well-known fixed TCP port address and can manage multiple CLI sessions at the same time.

The CLI can support several administration features. This feature includes creating new user records in the user database, deleting existing user records, and modifying existing user records. Other features may include the ability to create new nets in the user database, delete existing nets, and modify existing nets. Yet other features include the ability for the administrator to list all users by username, dial number, user identifier, as well as other criteria, and list all nets in the net database by net address and net identifier. It can include features, the ability for an administrator to display all fields for a particular user record, and the ability for an administrator to display all fields for a particular net identified by a net identifier or net address of the net. The CLI may also include the ability for administrators to query static status reports for specific nets or individual net members. This feature allows administrators to query real-time (updated) reports, especially for the current list of net participants, current speakers, the presence or absence of media traffic, and any media signaling messages sent or received by CM218. , Become identifiable.

In one embodiment, the CM218 utilizes an administration function by a common web browser via an HTTP web server interface with one or more pages formatted using hypertext markup description (HTML) syntax. It can be so. At least one of the administration pages may contain a reference to the embedded Java applet.

Some administration functions may be optionally performed through HTTP GET and POST commands issued by web browsers using the traditional HTACCESS authentication mechanism. The supported administration features are a subset of those supported by the CM218 CLI interface.

The HTTP interface can be used to deliver Java applets to web browsers. The applet can rely on the CM218's CLI interface to provide users with additional administrative functionality through a web browser interface.

CM218 manages and concentrates on all administration functions related to net administration. This administration feature includes creating and deleting nets, defining new users and deleting existing users, adding and deleting users as net members, and adjusting various operating parameters on a user, net or CM wide basis. Is included.

When delivered to a cellular or other service provider, the CM218 requires a basic administration configuration before it can be used to support group communication activities. The requested initial configuration includes the basic system configuration. The underlying system configuration includes applying passwords to operating system-level accounts for root-level system administration and configuring the CM218 network interface for proper operation on the local wireless infrastructure network. ..

Once CM218 is configured, general net administration will be performed. In one embodiment, the net administration function is done through other network interfaces built with HTML or TCP / IP. Administrators interact with CM218 using a traditional World Wide Web (WWW) browser. Administration can be done locally or remotely (anywhere on the Internet or via dial-up). However, in one embodiment, the basic transmission path for administration access is TCP / IP. Multiple (two or more) simultaneous administration connections are also possible.

When connecting to CM218 for net administration, the administrator generally authenticates himself and ensures that only authenticated administration actions are accepted. Different levels of access are possible, for example, an authenticated net member can connect directly to the CM218's administration interface to modify a particular net membership list, but the more general administration privileges are: Reserved for a specific administration account. For the sake of clarity, the administration actions are divided into those that specially process user definitions and those that define the net. The user definition may include a username, a unique CD cellular system identifier, a CD phone number, and the user's email address. The CM218 also internally specifies a unique user identifier that may be passed to the CD202 and uniquely identifies the user in a signaling message. The net definition may include a net address, a net hang time, a private dispatch timeout, and a member list. The net member list consists of a list of member records, which individually include the user identifier and priority level. Members with the lowest priority level generally have listening-only privileges.

The CM administrator can monitor the current status of nets with administration privileges. In particular, the administrator can monitor the state of the net (active, inactive, hibernate, wake up, etc.) as well as determine the current list of net participants. Administrators can also monitor the identity of the current speaker whenever the net is active. Additional statistics and status, such as the length of the current session, the total talk time of an individual user or net, the last time a particular net member held send privileges, the average number of registrants, etc. It may be available to the administrator through the administration interface 604.

The CD202 can also support the concept of "private calling". This is a half-double point-to-point call, made by the caller pressing the PushTalk button. This is accepted without ringing the ringing phone that would occur in a traditional full-duplex point-to-point call.

Network protocol The operation of one embodiment of a system and method of providing group communication services can be described and specified at two levels. The two levels generally operate independently of each other. Low levels with physical, link, network, and transport layers are described here. High-level with group communication and related application-level protocols will be discussed earlier.

One embodiment of a system and method of providing group communication services operates through the standard Internet and associated protocol stacks. For example, in a CDMA communication system, it is provided by the IS-705.5 packet data service option. Of course, other embodiments may instead utilize data services adaptable to the particular type of communication system used, such as the GSM communication system. Various embodiments of systems and methods of providing group communication services can also operate through V.32bis, V.90, or similar PSTN modem standards, independent of any IS-707.5 segment. It can be used completely inside the public Internet.

Most group communication network traffic can be described as either signaling or media traffic. Signaling traffic is further divided into two different categories. It is a media signaling with call setup and control signaling consisting primarily of SIP solicitation requests and receipt confirmations, and primarily real-time floor control requests and associated asynchronous messages. Media traffic has real-time point-to-multipoint voice or data broadcasts.

Signaling protocol Group communication Call settings and call control signaling are performed according to the well-known Session Initiation Protocol (SIP), but any signaling protocol may be used instead. While SIP is transmitted using either User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), CD202 provides all SIP-based signaling capabilities that use UDP in one embodiment. Executed, CM218 requires all SIP signaling requests to be received via UDP.

In one embodiment, the CM218 configures both a SIP user agent server and a SIP redirect server. To support group communication, the CD202 configures a SIP user agent client. The CM218 operates by listening to incoming SIP connections on the advertised port (in one embodiment, UDP port 5060). When a connection occurs, the SIP server receives the request and processes it according to the SIP call signaling rules. The server can handle multiple call signaling connections in parallel.

To save network resources, the CD202 can disconnect the UDP connection with the SIP server after successfully joining (or failing) the net. The UDP connection is then reinstated and can send additional SIP call signaling requests (eg, leave the net or switch to another net).

Since UDP provides unreliable connectionless transmission, application-level reliability assurance is needed to ensure strong communication. These guarantees are realized by a SIP compliant endpoint, namely a CD in communication system 200. The SIP call signaling UDP stream is encapsulated within a data network protocol such as IP. No special formatting is required. SIP call signaling IP packets exchanged between wireless-based CDs or dial-up PSTN-based CD208s are encapsulated within PPP. Again, no special formatting is required.

In one embodiment, the SIP call signaling PPP frame exchanged between the cellular-based CD202 and base station 216 is encapsulated within the Radio Link Protocol (RLP). This RLP is a well-known wireless protocol that transmits data wirelessly. For dial-up PSTN-based CDs, a suitable modem standard such as V.32bis or V.90 will replace RLP. In all cases, no special action is required and no error-free physical link is required.

In one embodiment, group communication media signaling is transmitted using UDP / IP datagrams, as well as voice and data traffic. When CRTP header compression is available, media traffic is further encapsulated using RTP at the application layer, and header compression techniques are appropriately applied to UDP / IP inbound and outbound UDP / IP traffic.

Media signaling requests and responses are encapsulated within UDP datagrams. When available, CRTP header compression can be applied to reduce the impact of sending uncompressed UDP / IP headers.

Each CD dynamically selects a UDP port. The CD attempts to listen to group communication media signaling requests on this UDP port and communicates this port number to CM218 as part of the SIP solicitation. It will be delivered when you try to join the net.

The net CM media signaling destination address (including the UDP port number) is described in the net session description, which is delivered as part of the response to a successful SIP solicitation request. Unlike SIP signaling addresses, media signaling destination addresses are net-specific and may vary between net-joined instances of CD202.

In one embodiment, multiple nets hosted by the same CM operate independently and do not share media signaling or media traffic ports.

Media traffic (voice) Voice traffic from CD202 is encapsulated within an RTP / UDP or UDP payload by grouping one or more data frames that represent voice information. In one embodiment, the data frame has a vocoder-generated frame located on the CD202. The use of CRTP-enabled RTP is recommended to reduce end-to-end media latency and provide interoperability for future IP telephony applications and services. In each case, the CD202 dynamically selects the UDP port. With this UDP port, the CD202 predicts that it will receive media traffic and communicates the port number to CM218 as part of the SIP solicitation delivered by the CD202 when attempting to join the net.

The CM218 describes the net vocabulary and transmission encapsulation protocol in a session description response to a successful SIP solicitation request, as well as its own 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 can vary between instances of CD202 participating in the net.

Voice traffic is typically encapsulated in CD202 using RTP. RTP separates each UDP datagram into RTP headers and payloads. Voice traffic may be optionally encapsulated simply using UDP, without RTP encapsulation, when CRTP header compression is generally not available or supported by net members. The structure of the UDP payload follows the rules given for the corresponding RTP payload, without the RTP header fields.

The decision to encapsulate the media directly into UDP is typically made up of net administrators and advertised by net session announcements.

Media traffic (data) In addition to audio media, the net can also support arbitrary data broadcasts. For example, secret net rekeys, emails, data files, etc. If the net supports data broadcast channels, CM218 will advertise the media type in the net's SIP session description when the CD202 officially joins the net. In one embodiment, like traditional media broadcasts, general data broadcasts operate through RLP (or the corresponding physical layer), but are considered unreliable transmissions.

In one embodiment, the CD202 includes the ability to translate Internet domain names into Internet addresses using the Domain Name Service (DNS) protocol specified in RFC1034. Instead, the CD202 acts only as a DNS client or converter as described in RFC1035.

In order for the CD202 to translate the DNS host name, the CD202 is pre-programmed with the IP network address of the DNS server. The DNS address must also be configured by the CD202 service provider and optionally by the user.

The CM218 may optionally be configured to act as a DNS server, as described in RFC1035. DNS servers can respond to DNS requests from external entities using TCP as the forwarding protocol, but CM218 also encapsulates DNS messages using UDP.

Extension to cellular multicast channels Various embodiments of systems and methods of providing group communication services have been designed to take advantage of the development of cellular multicast channels, if available. Such channels generally allow a transmitting station to address multiple listening stations, or CDs, directly without the need for multiple separate rebroadcasts of transmitted data.

To take advantage of the benefits provided by cellular multicast channels, net media signaling and `traffic destination addresses will be traditional IP multicast channels, and all media signaling and traffic broadcasts originating from CM will be multicast broadcasts. Media signaling, traffic broadcasting, and SIP signaling originating from CDs are likely to remain as point-to-point communications.

RLP fix The Radio Link Protocol (RLP) is modified within CD202 to reduce the latency that occurs when link layer (RLP frame) loss occurs. Such modifications are optional and do not explicitly affect the transmission behavior of the application layer protocol. Neither TCP nor UDP envisions a trusted network (IP) or link-layer service.

Various RLP modifications are possible. The RLP can be modified to send multiple negative acknowledgment (NAK) responses after the initial RLP timeout. This prompts the remote end to send multiple copies of the lost RLP frame, improving the chances of a normal RLP recovery.

You may never send a NAK (after the RLP timeout expires) and modify the RLP so that dropped RLP frames cause errors in the higher level protocol stack. Any TCP-based application-level protocol can be easily recovered through TCP's error recovery mechanism.

CRTP header compression Typically, in RTP encapsulated media traffic, the RTP header occupies 12 bytes of overhead, the UDP header occupies 8 bytes of overhead, and the IP header occupies 20 bytes of overhead, for a total of 40 bytes of network and transport protocol. It's overhead. This overhead can be too large to carry a small RTP-encapsulated payload through existing cellular and even some dial-up PSTN channels.

Various embodiments of systems and methods of providing group communication services compress the header fields of IP / UDP / RTP datagrams to reduce radio bandwidth requirements, assuming the availability of transparent mechanisms. The IP / UDP / RTP header compression specification inside PPP (or similar link layer framing protocol) is accepted as a standard within the Internet Engineering Task Force (IETF). This specification puts the header field of an IP / UDP / RTP datagram, commonly known as CRTP header compression, in 2 bytes for a point-to-point network (if the UDP checksum is not held; the UDP checksum is). Describe how to compress to 4 bytes if retained). CRTP employs three basic methods of compressing IP, UDP and RTP header fields. 1. Header fields that are constant throughout the duration of the RTP session are sent once at the beginning of the session and never again.

2. Header fields change slowly or small increments are differentially encoded.

3. Header fields that change almost always in constant increments are differentially encoded using the second-order difference. Constant increments are sent and stored and updated only when the field changes in unexpected increments.

CRTP thus assumes that both ends of the compressed link hold a shared set of information or circumstances about each RTP session. This includes full IP, UDP, RTP headers (including constant fields), first-order differences for fields that typically change in constant increments, and other relevant information.

Infrastructure support When operating through a cellular CDMA infrastructure, one embodiment of a system and method of providing group communication services, such as the packet data service option outlined in IS-707.5, for signaling and transmission of media traffic. , Request the existence of data services. In addition, one embodiment of a system and method of providing group communication services utilizes hibernation mode to ensure that point-to-point voice service calls are received during an extended period of net broadcast inactivity. .. If the IS-707.5 Packet Data Service option is not available, an alternative embodiment can be achieved using a service known as Quicknet Connection (QNC) and IS-707.4.

QNC provides the same protocol stack provided by IS-707.5, but the QNC infrastructure rarely supports CRTP header compression. The CD202 may be configured to use QNC instead of IS-707.5 to negotiate packet connections and, if QNC service is available, treat the connection as a packet data service option connection.

Dynamic IP (registration) In one embodiment, the CD202 can detect the fact that its IP network address has changed or is about to change. If the CD202 is on the net when the address change occurs, the CD202 will rejoin the net by calling the SIP solicitation command described below.

The IP network address of CD202 changes for at least two reasons. Roaming CDs are required to switch between cellular systems or networks and negotiate new IP network addresses. Alternatively, the CD202 may experience a service disruption for some reason or drop a call with a data service option and will be assigned a new IP network address when reconfiguring the service. If CD202 joins the net at the time of address change and does not rejoin the selected net in a timely manner, CM218 will eventually terminate its membership and list about the selected net. Remove CD202 from. If CD202 eventually does not respond to a series of media signaling AYT request messages, it is removed from the list of active net participants, as described below.

IP mobility support RFC2002 describes the IETF Standards Stack Protocol (commonly known as Mobile IP), which allows IP datagrams to be transparently routed to mobile Internet nodes. One embodiment of a system and method of providing group communication services allows it to operate transparently to mobile IP without minor or modification to the application or its associated protocol stack. Like SIP, mobile IP includes a registration mechanism that positions mobile hosts within the entire network. Unlike SIP, the mobile IP registration mechanism operates at the network layer and is always directly coupled to the IP level addressing scheme. SIP registration occurs at the application layer and is specified independently of the details of network-level addressing.

Under mobile IP, the mobile host (ie CD202) connects to the network via an external agent. The external agent applies CD202 to the "aware" address. The awareness address is a temporary but legitimate address, whereas you can address IP datagrams from anywhere on the Internet. The CD202 uses the awareness address to contact its home agent and conveys the current awareness address of the CD202. After verifying the identification information of the CD202, the home agent tunnels the packet addressed to the permanent home address of the CD202 to the CD202 using the awareness address of the CD202 (usually the Internet routing loop mechanism uses this permanent home address). Deliver directly to the home agent or to the home agent's network).

In one embodiment, systems and methods that provide group communication services can operate through mobile IP. However, if the CD202 joins the net using its own permanent address and the home agent is far away from the CM218 and CD202 in the sense of network topology, the mobile IP will have end-to-end latency and media traffic and signaling. May adversely affect the perceived voice quality of. In such cases, media traffic may need to be routed through the public internet or other variable quality service networks. This would not have been needed without mobile IP. To avoid this, it is often preferred that the CD202 use its own notice address to access the net broadcast service and rejoin the net when that notice address changes.

Group communication application Group communication applications are based on two different application level protocols. It is Session Initiation Protocol (SIP) and Net Broadcast Media Signaling. SIP is used for call signaling and call configuration. Media signaling communicates PTT requests, resolves PTT arbitration conflicts, and manages net outages.

SIP call signaling The Session Initiation Protocol specified in RFC2543 provides group communication system application layer control (signaling) for discovering, joining, and leaving the net using the SIP server interface on CM218. To join the net, CD202 solicits the net by name and joins the call through a top-level SIP server. To leave the net, CD202 sends a corresponding "good buy" to the net. The normally expected sequence of SIP call signaling messages exchanged between CD and CM218 is shown in Figure 7.

The CD202 uses DNS to determine the IP address of the top-level SIP server and, if necessary, translates the provided primary or secondary SIP server address to an Internet network address. As an optional alternative approach, SIP rules allow the CD202 to query the DNS service records associated with the system domain portion of the net address and contact the SIP server with the returned address.

Before attempting to join the net, CD202 can make a call using the SIP solicitation method and request an updated list of available nets. For example, the CD indicated by the mobile identification number or dial number MS6199726921 wants to determine the current list of available nets by querying a top-level SIP server with a DNS address of sip.acme.com. This mobile identification number or dial number has been applied to the IP address 192.168.172.25 by establishing a wireless connection using the IS-707.5 Packet Data Service option. As shown in Time 1 of Figure 7, CD202 opens a UDP / IP connection to the SIP server port on sip.acme.com and makes the following request: Solicitation sip: nets@nbs. acme. com SIP / 2.0 Via SIP / 2.0 / UDP 192.168.172.25 Source: sip: MS6199726921 @ nbs. Acme. com To: sip: nets@nbs. acme. com Location: sip: 192.168.172.25: 5062 Call ID: 123 @ 192. 168. 172.25. Acme. Com Case: 1 Solicitation Content length: 0 The request to get the net update list is addressed to a special destination, in this case sip: nets@nbs.acme.com. If appropriate, CD202 may also include additional application-specific headers that identify the network and system to which the cellular-based CD is servicing. A sample header containing this information is shown below.

X-CDMA-System: 0x7BCF X-CDMA-Network: 0xE289 The CD202 also includes a SIP request header, which can indicate that the CD202 requires the SIP server to understand and support group communication services. The value of the option delivered with the request header is used by CD202 to inform CM218 of the particular version or type of group communication service that CD202 expects CM218 to support. The sample header is shown below. Request: acme. Bravo. nbs As shown in Time 2 of FIG. 7, the CM218 top-level SIP server can use the SIP redirection mechanism to redirect requests to the destination. This destination is specifically specified to receive and respond to requests for net information. Upon receiving such a redirection, the CD202 ACKs the response at time 3 and resends the solicitation request to the redirected destination, as indicated by time 4. The sample SIP redirection response is as follows. SIP / 2.0 302 Temporarily moved Source: sip: MS6199726921 @ nbs. Acme. Com To: sip: nets@nbs. acme. com Call ID: 1238192. 168. 172.25. Acme. Com Contact: sip: nets @ nbs. Acme. com CSeq: 1 Solicitation In the above example, the CD202 would need to determine the appropriate SIP contact point for the address (sip: nbs@nets.acme.com) redirected through the DNS mechanism (described above). To simplify this process for CD202, CM218 may use its Internet network address to explicitly identify the redirect destination.

If the solicitation requesting the list on the net is successfully received and accepted by CM218, CM218 must deliver the following solicitation request response at time 5. SIP / 2.0 200 OK Source: sip: MS6199726921 @ nbs. Acme. Com To: sip: nets@nbs. acme. com Call ID: 123 @ 192. 168.172.25. Acme. Com CSeq: 1 Solicitation Content type: Application / nbs Content length: 71 G bravo @ nbs. acme. com S 2 audio data G dc @ nbs. acme. Com C 1 Audio G techapps @ nbs. Acme. com C 1 audio The solicitation request response should generally include a list of records whose content defines the set of nets that CD202 may later join. CM218 queries its net database for the net, listing the requesting CD as a defined member, and creates a response to the solicitation request.

The net is identified within the content using an application-specified recording format that includes the official net address of the net. The nets may be listed in any order. In this example, the format of the solicitation response sample content is described by the content type in the application / X-acme-nbs group list. One possible definition for this content is a series of records, one record per line, each conforming to the syntax below. &lt;Recording type&gt; [&lt;Field&gt; ... &lt;Field&gt;] Here, the first symbol in each record defines the type of record, followed by one or more field values. The number of expected field values is potentially determined by the type of recording. This example contains three group-specified records (G), each of which contains a net address as well as a display of the number and type of media channels specified for each net. .. Other provisions for content are also possible.

The CM218 may not respond successfully to the CD202 for a variety of reasons. In such a situation, CM218 will deliver the appropriate SIP status code instead of the solicitation response described above. The CD202 must be prepared to accept and interpret such status codes, and in the event of any fatal error, take appropriate action (eg, display an error message on the CD202's user interface display, etc.) ) Must be taken. For example, a SIP server that does not recognize or support the qualcomm.bravo.nbs request can respond as follows: SIP / 2.0 420 Inappropriate extension Not supported: acme. bravo. nbs The CM218 can also initiate a normal solicitation response with an information status response that indicates the progress of registration, such as:

SIP / 2.0 100 trial CD202 can generally accept and interpret such information status codes that initiate a successful registration.

Solicitation (participation in the net) In one embodiment, the CD202 requires the net management CM to join the net by making a SIP solicitation request, as shown by time 7 in FIG. If the CD202 does not have an open UDP / IP connection to the SIP server, the CD202 opens a new UDP / IP connection to the SIP server port.

For example, CD202 can attempt to participate in ACME Net by issuing the following SIP solicitations. Solicitation sip: acme @ nbs. Qualcomm. Com SIP / 2.0 Via SIP / 2.0 / TCP 192.168.172.25 Source &lt;sip: MS6199726921 @ nbs. Qualcomm. Com&gt; To: acme &lt;sip: acme@nbs. qualcomm. com&gt; Subject: Participation Call ID: 421b2-314159 @ 192. 168.172.25. Qualcomm. Com Content type: Application / sdp Cseq: 1 Solicitation Content length: 128 v = 0 o = --3115132610 3201 IN IP4 192. 168. 172. twenty five s = acme c = IN IP4U192. 168.172.25 t = 311532610 0 m = Audio 5200 RTP / AVP 12 a = type: nbs As mentioned above, the CD202 must be redirected by the top-level SIP server and prepared to reissue the solicitation request to the redirected destination. The CM218's top-level SIP server must properly redirect any incoming solicitation requests to the MCUs currently associated with the target net. CD202 may be redirected more than once.

Assuming a successful solicitation, the solicitation request may include a description of the media source, which is produced by CD202. If included, the description is included as message content and is described using the standard SIP content type and content length field configuration.

In the example above, the CD202 is RTP / AVP PureVoice.^TMIt advertises that it will source a single audio session formatted using a payload profile. The session description is delivered in a Session Description Protocol (SDP) compatible format specified by RFC2327. After specifying the SDP version (v), the session description includes a mandatory source (o) description. In this example, the random session identifier 3115132610 and session version 3201 are selected. As such, the combination of session identifier, version, network and address type IN IP4, and address 192.168.172.25 constitutes a globally unique identifier for the session. The CD202 may utilize any convenient mechanism for selecting values for the session identifier and session version. Providing an estimate of the current time is one possible way to specify a session identifier.

Connection data (c) is specified by specifying network type IN, address type IP4, and connection address 192.168.172.25. The CD202 uses an IP address to label (or source) media traffic as a connection address. CD202 uses the name part of the net address of the net as the session name, and in this example, acme.

CD202 identifies the session lifetime (t) by providing the best estimate of the start time or current time 311532610 in Network Time Protocol (NTP) format and indicates that the session is infinite (0).

The media format (m) description specifies media types such as audio, source port 5200, transfer protocol RTP / AVP, and payload format 12, which are intended to be used by the CD202 to transmit to the net. There is. The RTP / AVP payload profile maps 12 payload types to PureVoice^TMRepresents audio encoded using a vocoder. This vocoder was developed by the assignee of the system and method of providing group communication services.

Finally, the session description uses attribute (a) type specification to indicate that the CD202 requires the session to operate as a group communication. CM218 must ensure that the solicited destination address is indeed a valid net address before allowing the solicitation.

CM218 will deliver the following solicitation response at time 8 to show a successful solicitation and specifically inform CD202 that it has been added to the list of participants on the solicited net. SIP / 2.0 200 OK Via SIP / 2.0 / UDP 192. 168. 172. 25 Source: &lt;sip: MS6199726921 @ nbs. Qualcomm. Com&gt; To: acme &lt;sip: acme@nbs. qualcomm. com&gt; Call ID: 421b2-314159 @ 192. 168.172.25. Qualcomm. Com CSeq: 1 Solicitation Content type: Application / sdp Content length: 179 v = 0 o = --3115132612 74512 IN IP4U192. 168.156.18 s = acme a = type: nbs c = IN IP4 192. 168. 156. 18 m = Audio 8422 RTP / AVP 12 m = Control 8420 UDP / NBS The solicitation response refers to a previously received solicitation, in one embodiment, the caller's ID.

A successful solicitation response includes a primary session description for the solicited net, which describes the supported media traffic ports and formats using SDP syntax. This syntax is a well-known syntax used with SIP. The session description includes a connection (o) description, which specifies the network address to which all media signaling and traffic should be sent (192.168.156.18 in this example). The net media destination network address is not necessarily the same as the network address of the SIP user agent server translated using DNS from the net net address.

The session description describes all media and destination media ports. In this example, three media channels are defined for the net. The first is the RTP / AVP media profile (ie, QUALCOMM PureVoice)^TM) Supports encoded audio using a type 12 payload as specified in. The second defines a common data channel encoded using the dynamic payload type (payload type 100 in this example) using the format specified by the group communication specific media profile. Currently, there are two group communication specific media formats. They are X-NBS-GVRS and X-NBS-MELP. The former describes audio encoded using a Globalstar Variable Rate Speech (GVRS) vocoder that uses the RTP payload format. The latter describes audio encoded using the MELP vocoder standard with the RTP payload format.

If the net is configured to carry media entirely within UDP (generally requiring support for infrastructure that does not configure CRTP), the SDP media announcement field is UDP / NBS and all media. Use dynamic payload type transmission for. The encoding name of X-NBS-QCELP is QUALCOMM PureVoice.^TMUsed to describe audio encoded using a vocoder. Similarly, the X-NBS-GVRS and X-NBS-MELP encoding names describe the GVRS audio and MELP audio media channels encapsulated directly within UDP, respectively.

The media format for audio used in net session descriptions may conflict with the format proposed by CD202 in its initial solicitation request. The CD202 uses the media format specified for all traffic by the session description on the net. It is intended to be broadcast to the net.

The third media channel describes a UDP encapsulated group communication specific media signaling channel.

The session description also generally includes the SRC identifier applied to the CD202 by the MCU to identify the media signaling messages sent by the CD202 as part of subsequent participation in the net. The value of this identifier must be unique among all active participants on a given net and therefore must be dynamically generated.

The session description also includes a group communication protocol version announcement that indicates the revised level to which the net media signaling complies. Such announcements may be achieved by expanding the value of the type attribute field or by specifying a new attribute. This new attribute is, for example, gc-revised, and this value is the protocol version number.

ACK In one embodiment, after receiving a normal solicitation response, the CD202 confirms the solicitation by returning a SIP ACK request to the SIP user agent server of the net MCU, as shown at time 9 in FIG. After the sample exchange shown in FIG. 7, the following ACK request is sent.

ACK sip: nbs. qualcomm. com; Transfer = tcp SIP / 2.0 Via SIP / 2.0 / TCP 192.168.172.25 Source: &lt;sip: MS6199726921 @ nbs. Qualcomm. Com&gt; To: condor &lt;sip: acme@nbs. qualcomm. com&gt; Call ID: 421b2-314159 @ 192. 168.172.25. Qualcomm. Com CSeq: 1 ACK After sending the ACK request, the CD202 may close its TCP connection with the SIP server. Before the ACK is sent, the CD202 must initialize its media signaling and traffic ports according to the session description delivered in the CM218 solicitation response.

BYE In one embodiment, at any time after the CD202 sends a SIP ACK message in response to a normal solicitation response, a SIP BYE message is sent to the net SIP user agent server, as shown at time 10 in FIG. CD202 may officially terminate its participation in the net by sending. Before sending BYE, CD202 may have to open a TCP connection to CM218.

In one embodiment, the BYE message sent by CD202 follows the form below.

BYE sip: acme @ nbs. Qualcomm. Com SIP / 2.0 Via SIP / 2.0 / TCP 192.168.172.25 Source: &lt;sip: MS6199726921 @ nbs. Qualcomm. Com&gt; To: condor &lt;sip: acme@nbs. qualcomm. com&gt; Call ID: 421b2-314159 @ 192. 168.172.25. Qualcomm. Com CSeq: 2 BYE BYE uses the same call ID as the previous exchange of SIP messages, but a new CSeq. For BYE, the following reception confirmation is made in the BYE response by CM218 (Fig. 7, time 11). SIP / 2.0 200 OK Via SIP / 2.0 / TCP nbs. Qualcomm. Com Source: &lt;sip: MS6199726921 @ nbs. Qualcomm. com&gt; To: condor &lt;sip: acme@nbs. qualcomm. com&gt; Call ID: 421b2-314159 @ 192. 168. 172.25. Qualcomm. Com CSeq: 2 BYE Once BYE is confirmed, CD202 can close the UDP connection with CM218. Prior to confirming receipt to BYE, CM218 removes CD202 from the displayed list of active participants on the net.

option In general, the CD202 can use an optional method to query the functionality of the SIP server. In particular, the CD202 may want to query any SIP destination to determine if this destination provides NBS call signaling support.

Cancel Prior to receiving the solicitation response and sending the receipt confirmation, CD202 may wish to discontinue the solicitation request in reservation. In such a situation, the CD202 can use the SIP cancellation method to properly cancel the call. Both the CM218 top-level SIP redirect server and the SIP user agent server must support the cancellation method.

For example, if the user makes a voice service communication and decides to press send before the solicitation is complete, the CD202 may use a cancel method to cancel the ongoing solicitation. In such situations, instead of waiting for the solicitation to end and sending the BYE immediately, the CD202 may simply cancel the solicitation and proceed to make the requested voice service communication. it can.

Group communication Specific media signaling After the CD202 has a successfully negotiated entry to the current membership of the net using SIP, real-time call control is exchanged between each CD and the net MCU, a point-to-point application. This is done through level media signaling messages. The following group communication media signaling message types are defined according to one embodiment.

PTT The PushTalk (PTT) request message is sent by CD202 to CM218, signaling the user's desire to broadcast media, typically voice, to the net. Normally, a PTT request message is sent each time the PTT switch 450 is booted on the CD202. In addition, a PTT release message is sent by CD202 to CM218, indicating the release of PTT switch 450.

PTT messages have a number of fields that contain a variety of information used to grant or release transmission privileges. In one embodiment, the first field is used by the PTT message to specify either a request for speaker privileges or a release of speaker privileges. The second field is used to identify which CD sent the PTT message. The third field is used to allow later PTT release and PTX messages (defined below) to provide a unique message identifier for referencing a particular PTT request. The identifier must be unique within the registration session for a particular CD.

In one embodiment, the CD202 requires that at least one PTX response message be received for each outgoing PTT request. If the PTX response is not received within a predetermined time, the CD202 will assume that the PTT was lost during transmission and in the third field a second PTT message with the same PTT message identifier. Is retransmitted. The predetermined time may relate to a fixed time period width or may be dynamically changed according to the system situation. For example, if the net is not dormant, the predetermined time may be a relatively short period width (1 to 2 seconds). In this case, the CM218 must be able to respond to PTT messages relatively quickly. If the net is in hibernation mode, the timeout must be extended to adjust for the additional time required to return to active state.

In one embodiment, if no PTX response message is received from the CM218 within a reasonable number of retransmissions, the CD202 goes idle, assuming the CM218 is no longer reachable, and an error situation. Is displayed to the user.

PTX The PTX message is sent by CM218 to the first CD202, signaling various arbitration events and confirming and responding to the receipt of previous PTT requests from the first CD202. CM218 responds to PTT messages using PTX messages. This includes both request and release. The PTX message contains information about whether the referenced PTT release message was allowed or denied. When responding to a PTT open message, the PTX message is used to indicate receipt confirmation. The CM218 can also use PTX messages to reject previously allowed PTT request messages (if a higher priority CD issues a PTT request message, or if the send privilege expires (ie, times out). Or if any other event occurs that requires the send privilege to be revoked).

In one embodiment, the PTX message has multiple fields that convey information to the PTT message. The first field is specified to indicate whether the PTX message is a synchronous response to an outstanding PTT request or an asynchronous message indicating an error or priority arbitration conflict. The second field refers to previously received PTT requests. The third field indicates whether the PTX message allows, denies, revokes, or confirms send privileges. The fourth field provides additional information that describes the PTX operation, especially if the PTX message was rejected, canceled, or inoperable with respect to the previous PTT request. This field either allows a higher priority speaker to send privileges, or CD202 is not listed as a net participant and is therefore not allowed to send media signaling requests to the net. Can be shown. The fifth field represents the maximum time period for which the send privilege is valid. The CM218 starts the timer when the PTX message is sent. In an alternative embodiment, the timer is started when the CD202 starts transmitting media traffic. The value of this field may be a fixed parameter, but it may also be a variable that changes with various parameters, such as the amount of net traffic, the number of active net users, and so on.

The CD202 may or may not confirm receipt of the PTX message. If the transmit PTX message response is lost, the CD202's PTT retransmission timer expires and the CD202 can retransmit its own PTT request.

PTA The PTA message is sent by CM218 to each CD currently participating in the net, announcing the sender's identity of the reserved media traffic. PTA messages are also used to officially announce the release of sending privileges. The PTA message has a field that indicates whether the PTA message announces the grant (or denial) of the sending privilege. In addition, other indications such as revocation or confirmation of transmission privileges may be included within this field. The second field identifies a particular CD202. This CD202 will source media traffic to the net until the next PTA message is sent.

The CD202 with a successful PTT floor control request may or may not receive a PTA message announcing that speaker privileges have been granted. The message may arrive before or after receiving the corresponding PTX response. This is because some data protocols, such as UDP, do not necessarily maintain the order of the datagrams. Therefore, the requesting CD will only send media to the net by ignoring any incoming PTA message announcing that it grants speaker privileges and by receiving a PTX authorization message response. You may choose to decide if you can get started.

In one embodiment, the PTA announcement message is not acknowledged. Lost PTA messages are neither detected nor resent. CDs that do not receive PTA announcements may not be able to display the speaker identification of subsequent speakers. However, in alternative embodiments that utilize RTP encapsulated media, a source destination field is used to uniquely identify the sender. The CD caches the mapping between the previous PTA announcement and the media stream and leverages this information in the source destination field if the corresponding PTA announcement message is not received during a particular conversation time. Can identify the RTP encapsulated media stream.

AYT The CM218 may poll individual CDs on the net to ensure that the CDs can be contacted using the data protocol. Polling messages are known as "Ayouzea?", Or AYT messages. Multiple AYT messages may also be sent to a group of net participants, for example, to warn net participants that the net is no longer in hibernation.

The AYT may be sent to determine if the CD202 is still contactable via the data protocol or if the CM218 wants the associated cellular traffic channel on the net to recover from hibernation. AYT messages have a unique message identifier that allows subsequent IAH response messages (discussed below) to refer to a particular AYT request message. The unique message identifier can include a timestamp reference to generate an estimate of latency. The AYT message is not necessarily broadcast to each CD at the same time. The CM218 can stagger the transmission of AYT messages to each net participant to avoid receiving a flood of simultaneous IAH message responses.

The CD202 may or may not be in hibernation mode when the AYT message is sent. Generally, the CD202 responds to the received AYT message with an IAH response message. In one embodiment, if the IAH response is not received by the CM218 within a reasonable timeout range, the CM218 sends a new AYT message with a new unique message identifier. If no response to AYT from CD202 is received after a set number of retransmissions, CD202 is assumed to be unreachable and CM218 removes this CD202 from the current list of net participants. Further media signaling messages from the deleted CD will be ignored (or generate an error response) until the CD202 successfully rejoins the net as described above. In an alternative embodiment, the CD202 does not need to rejoin the net.

IAH The CD202 acknowledges the AYT message with an "I Am Here" response, a response known as the IAH. In one embodiment, the IAH message has an identification field that identifies for which previously received AYT message the CD202 has confirmed receipt. The IAH message also has information that uniquely identifies the CD202 that sends the IAH message.

The CM218 assumes that the CD202 confirms receipt of any received AYT message with an IAH response message. If the CD remains connected in silence, that is, a referenced AYT message is sent to ensure that it is passively monitoring net media traffic and signaling, the CM218 will , Record the time of IAH reception for future reference.

ZZZ If CM218 determines that no net activity on the net, or in alternative embodiments, activity for individual net members, has occurred within a predetermined time, the CM218 will have a "sleep" message, ie. Send a ZZZ message to one or more CDs, prompting them to free the associated radio resources and enter hibernation mode. Each CD may choose to ignore this message, for example if it supports other packet applications at the same time. In one embodiment, the sleep message has an identification code corresponding to the CM218 that sends the sleep message to the CD to distinguish between multiple receipts of the sleep message.

In one embodiment, if the sleep message is lost, the CD202 does not confirm receipt of the sleep message and no error recovery is attempted. To prevent the sleep message from being lost, the CM218 may send multiple copies of the same sleep message to individual CDs or the entire net. The CM218 ensures that all copies of the same sleep message are sent within a defined time interval, and the CD202 releases its radio link and goes into hibernation after the first message is received. You must wait longer than this time interval until.

ASK In some cases, the CD202 sends a message to the CM218 to allow the CD202 to check the connection with the CM218 and determine if the CD202 remains listed as a net participant. This message is known as the "ASK" message. The CD202 may want to confirm its participation after a service interruption or other period during which the CD202 temporarily loses connectivity with the CM218. In one embodiment, the ASK message has a unique message identifier that allows subsequent FYI response messages (discussed below) to refer to a particular ASK request message. The ASK message further has an identification code that uniquely identifies the particular CD202 that sends the ASK message to the CM218.

CD202 assumes that CM218 responds to an incoming ASK message with an FYI response message. If the FYI response is not received within a reasonable timeout, CD202 sends a new ASK message with a new unique message identifier. If no response to ASK from CM218 is received after a set number of retransmissions, CM218 is assumed to be unreachable and CD202 goes idle.

FYI In response to the ASK message from the CD202, the CM218 either sends a message to the CD202 to confirm receipt of the previously sent ASK message, or an ASK message by the CM218 to notify the CD202 of an exceptional situation. Is sent. This message is known as the "FYI" message. In one embodiment, the FYI message has a field that specifies whether the FYI message is a response to an unprocessed ASK request or a message indicating an exceptional situation. Whether the FYI confirms net participation and administratively notifies CD202 that the FYI message has been removed from the net member list, or is performing some other predetermined function. It also has an additional field indicating whether or not. In addition, the FYI message has a status field that provides additional information describing the FYI action, especially if the FYI message indicates that the CD202 is neither a net participant nor a member. The FYI message may further have an identification field that references a previously received ASK message that the CD202 has confirmed receipt.

In one embodiment, the CD202 does not send an acknowledgment of the FYI message response. If the FYI message response is lost, the CD202 sends a new ASK message request after a predetermined amount of time has passed since the previous ASK message was sent.

Media signaling message sequence Figure 8 shows a sequence of group communication media signaling messages exchanged between a single CD202 and a net-managed MCU. The messages are sent in the order shown.

At time 1, the active CD202 sends a PTT request to CM218. This indicates that the user wants the media to be broadcast to the net by making a PTT message request. In response to the PTT request, at time 2, CM218 responds to the requesting CD202 with a PTX message response. This response may allow or deny the request. If the request is approved, a PTA announcement message will be sent to the net participants at time 3. In addition, if a user continues to broadcast beyond the net PTT timeout, or if a higher priority user makes a PTT request while the CD202 is broadcasting, then a second PTX message response is subsequently issued. It may be transmitted.

The CD202 typically broadcasts media traffic until the user releases the PTT switch 450. At this release, CD202 signals the end of the conversation period by sending a PTT release message to CM218 (Figure 9, Time 4). At time 5, CM218 responds with a PTX confirmation message and at time 6 broadcasts an announcement notifying net participants that the conversation period is over.

Pause One embodiment of a system and method of providing group communication services during an extended net inactivity time allows data service calls to be put into hibernation. The CM218 promotes the transition to and from hibernation by independently managing the same hibernation concept for each net.

The CM218 holds a first timer called the in-activity timer 614 to measure the net hang time. This hang time is defined as a time interval during which no member of the net is sending information to other net members. When the inactivity timer 614 reaches a configurable preset value, it triggers CM218 to put the net into hibernation by broadcasting sleep media signaling messages to net participants. In an alternative embodiment, individual in-activity timers 614 are retained for each member of the net, and after a configurable preset time period, the in-activity timer triggers CM218 to trigger individual members of each member. Puts each member into hibernation one by one by sending a sleep message to the members when the inactivity timer expires.

Upon receiving the sleep message, the active CD releases its traffic channel and goes into hibernation according to a particular data transmission protocol in use, such as IS-707.5 in a CDMA communication system. Alternatively, the CD may ignore the sleep message and remain connected. Net participants, such as dial-up PSTN users, who do not work through data channels that can release the channel, must ignore sleep media signaling messages.

In one embodiment, when a PTX message is sent, the inactivity timer 614 is reset to zero and remains zero until the send privilege ends or the CD202 releases the send privilege. Once the send privilege is released, the inactivity timer 614 advances until the next PTX message is sent.

Wake up time When a participating CD goes into hibernation, whether the data addressed to the CD202 reaches the cellular infrastructure for wireless transmission to the CD202 or the CD202 produces the data to be transmitted. The CD generally remains dormant until either. In the former case, it may be triggered by the traffic sent by CM218 to CD202. In the latter case, it may be triggered by the user pressing PTT switch 450 to request permission to broadcast to the net. Other triggers not related to group communication are also possible.

The net itself remains dormant until one or more members trigger the transmission of a PTT request. If CM218 determines that a PTT request message (ie, a PTX message) can be allowed (including performing any necessary arbitration to process multiple requests), then an AYT request is made to each listed net participant. To trigger the transition from hibernation. Triggering may or may not be required for any particular CD (ie, not for the requesting CD), but in one embodiment each CD is for AYT. Respond as described above.

In one embodiment, when the net is transitioning from hibernation, the CM218 suppresses the transmission of the initial PTX message until a second configurable timer, called the PTX hibernation response timer 616, expires. When this timer expires, CM218 sends a PTX authorization message as usual. However, the CM 218 suppresses the transfer of media to the net until a third timer, called the net wake-up timer 618, expires. During this time, any media received from the transmitting CD is stored in buffer 622 in CM218. In one embodiment, both timers reset when the CM218 determines that transmission privileges can be granted. In another alternative embodiment, the wakeup timer 618 is reset when the PTX authorization is transmitted. In an alternative embodiment, the wake-up timer 618 is reset when the media is received by the CM218 after the PTX authorization has been transmitted. In another alternative embodiment, the wakeup timer 618 is reset when the PTX authorization is transmitted. The value of the wake-up timer 618 is generally greater than the value of the PTX pause response timer 616. If any media has been received within the wake-up time period after the wake-up timer 618 has expired, the CM 218 will begin transferring media and media signaling from the buffer 622. Both timers can generally be set for each net.

In one embodiment, a configurable threshold of response to an AYT message, rather than relying on the wakeup timer 618 to determine when to start transmitting buffered media stored in buffer 622. The number of times is used to determine when there are enough net members to initiate transmission of media traffic from buffer 622. For example, in a net with 10 active (registered) members, the number of response thresholds may be equal to 7. This means that as soon as 7 IAH responses are received for 9 AYT messages (AYT is not sent to members requesting send privilege), 7 any media stored in buffer 622 Means sent to a member of a person.

If CM218 determines that the PTT request cannot be granted while the net is dormant, then CM218 signals the requesting CD and the net remains dormant.

Late riser A hibernated CD experiences system changes, service option changes, or some other service interruption that prevents the CD from receiving and responding to AYT messages. The CM218 holds a fourth timer known as the "late riser" timer 620. This timer also resets along with the wake-up timer and the PTX pause response timer. This raterizer timer can also be set for each net in general. After the lateizer timer 620 has expired, CDs that have not received an IAH response to the AYT wakeup message will be removed from the list of active participants on the net by CM218. In one embodiment, any such deleted CD is required to re-register with the CM218's SIP server in order to become a net participant again.

Audio buffering Due to the delay associated with the transition of the CD from hibernate to connected, the CD202 and / or CM218 can perform voice buffering to reduce the transition delay perceived by the user.

Typically, the CD202 user interface signals the user two milestones in processing PTT requests through a visual or audio mechanism. First, the CD202 signals that the PTT key has been pressed. The CD202 then signals that it has received the CM218 PTX message response. If the PTX message response grants permission to broadcast the media, the CD202 user interface provides an indication that the user can start talking to the net. Alternatively, the CD202 user interface indicates that the user has been denied permission to talk to the net. When the net is not dormant, the latency between sending a PTT request message and receiving a corresponding PTX response message is low, and users are gradually accustomed to being granted permission to speak briefly after the PTT button is pressed. Let's go.

However, the CD202 may have opened its own traffic channel, and when the net is down due to the fact that it encounters delays in reestablishing data services (eg, reestablishing radio resources). , A significant delay may separate the transmission of PTT requests from the reception of the corresponding PTX. In addition to the delay, other dormant net members must reestablish the traffic channel after the CM218 receives the PTT request. Therefore, in order to allow the user to start speaking with minimal delay after sending a PTT request, a pseudo-send privilege grant is generated by the CD202 using well-known techniques and is generally audio means. Provided to the user by. Pseudo-send privileges are similar to granting real-send privileges, so users generally cannot distinguish between the two. Pseudo-send permission allows the user to start speaking almost as soon as a PTT request is generated. The CD202 can buffer the user's voice in the internal media buffer until the actual transmit privilege is received or all available space in the internal memory is used up.

If a PTX message response that allows speaker privileges arrives, the CD202 will start sending buffered voice during the current conversation, even if there is some long end-to-end latency between net users. The operation can proceed as usual.

When a PTX message response denying a PTT request arrives, CD202 signals the user that permission to speak to the net has been denied. At this time, arbitrary audio information stored in the internal media buffer may be erased.

If the PTX message has not arrived before the speaker privilege is granted but all available internal memory space is used up, the CD202 will imitate the PTX denial and stop talking to the user. Signal. If CD202 fails to reestablish service, it may need to take other error actions here and notify the user accordingly. Alternatively, if the data service connection has been reestablished by this time, the CD202 in this situation can begin transmitting voice media to the CM218 without receiving a previous PTX message.

While waiting for the wake-up timer to end, the CM218 can buffer any media received from the CD202 on the net media channel. The PTX permission of the transmission privilege is transmitted to this CD202. The received media is stored in buffer 622 in CM218. When the wake-up timer expires, CM218 sends a PTA announcement to the net and begins broadcasting the buffered media stored in buffer 622. If the CM218 buffer 622 is fully used before the wakeup timer expires, the CM218 sends a PTX rejection to the requesting CD. The buffered media stored in the buffer 622 may be sent to the net after the wake-up timer has expired. When the wake-up timer expires, the net operation is performed normally.

The CM218 treats the net as active, even if the talking CD releases speaker privileges while any buffered media is transmitted from buffer 622. Therefore, the CM218 generally prevents a CD from interrupting transmission of buffered media unless the suspended CD has a higher priority than the source of the buffered media.

The size of the internal media buffer in the CD202 can be chosen based on the longest time expected to transition from idle to connected. Similarly, the size of buffer 622 in CM218 must be chosen based on the (maximum) value of the wakeup timer of the net identified in CM218's net database.

Dialogue with point-to-point calls While the CD is in hibernation, the CD202 can receive point-to-point voice service calls through voice or another data service option, but still one or more hibernate nets remain in attendance. .. After a point-to-point or other data service call ends, the CD202 generally goes into hibernation.

However, if the net goes out of hibernation while the CD chooses to receive a point-to-point voice service option call or another data service call, the CD202 misses the AYT "wake up" message request, which Tends to be removed from the list of active participants on the net. In such an example, the CD202 can determine its participation status by sending an ASK request to CM218 after the point-to-point call ends.

Generally, once a CD has been removed from the list of active participants on the net, you will need to re-register with the CM218's SIP server to rejoin the net.

Under normal circumstances, a CD that has negotiated a transition to hibernation can be expected to remain associated with the hibernation data call for up to 24 hours before the base station ends the call. However, when the base station's resources are scarce and valuable, some base stations are allowed to pause for 10 minutes and then end the call, doing this without explicit notice to CD202. To do. Such actions by the base station directly result in the loss of a significant or significant portion of the net's media traffic without the user's knowledge. That's because the CD remains in hibernation mode until the CD202 (or its user) takes action, such as pressing the PTT switch 450. Thus, in such a situation, the CD202 only finds that the call has been terminated after attempting to recover the data call from hibernation. As a result, if the data call is paused for longer than the maximum pause allowed (10 minutes in this example), the base station will revert to the dormant data call when net activity resumes. CD202 cannot assume that it will connect.

In many cases, the CD202 inevitably causes the base station to terminate the hibernate data call. However, the CD202 can confirm that the hibernate call has not been terminated by periodically transitioning to a connected state and causing some radio data activity. Using this method, the CD202 can instantly know if and when the call was terminated by the base station. In one embodiment, a short series of ICMP / IP echo requests (ie, a set of pings) are sent to the base station, waiting for a reply. Alternatively, the CD202 may send an ASK media signaling request to the CM218 and wait for an expected FYI response. In either case, the CD202 confirms that the call remains active and that it is possible to return to hibernation if the transition to the connected state is successful. The latter approach also confirms that CM218 continues to consider CD202 to be a member of the selected net.

By performing this check, the CD202 can reliably detect when or whether the hibernate data call was terminated by the base station within a reasonable amount of time when the disconnection occurs. Base stations generally do not terminate data calls that are dormant for less than 10 minutes, so CD202s generally do this until at least 10 minutes have passed since the CD202 last went into hibernation. Do not perform the check. The time to send such a check may be a fixed, predetermined value, or may be configured by the user through the user interface.

Pause signaling FIG. 9 shows a sequence of group communication media signaling messages exchanged between a single CD202 and an MCU managed by the net, and illustrates hibernation. The messages are sent in the order shown.

After the net has been idle long enough for the net's configurable hang time to end, CM218 broadcasts a sleep request message to the net participants, as shown in step 1. In response, each CD can release its own radio resources and enter hibernation mode by releasing its own air interface resources. In general, this means that the MSC 118 and base station 216 disconnect the communication channel associated with the hibernate CD, while maintaining various settings to allow them to reconnect to the communication channel relatively quickly. In one embodiment, the net participant does not respond to the sleep request message.

A normal PTT request by CD restores the net from hibernation mode, as shown in time 2 of Figure 9. It must be understood that other events can also recover the net from hibernation. For example, a net administrator may need to contact one or more net members by sending a message to CM218 in order to send to one or more intended net members. The CM218 can provide an independent way to get the net out of hibernation. For example, if no PTT request is received after a significant amount of time, CM218 can voluntarily send an AYT message to net participants to determine which CD is still responding to the message. .. There are other possibilities to get the net out of hibernation.

Prior to allowing the PTT request with a Time 5 PTX message, CM218 sends the AYT message request to other members of the net of the requesting CD (Time 3). This ensures that if the radio resource is released in response to a sleep message, it will take each of the previously participating CDs out of hibernation and the CDs can still be contacted through the data protocol. At time 5, CM218 sends a PTX message after a configurable time period defined here as the PTX pause response time. This message grants send privileges to the requesting CD. PTX pause response time reestablishes the communication channel and gives the CD the opportunity to send IAH messages (time 4). It warns CM218 that these CDs are still contactable. This allows the CD to receive communications from the PTT requester once the PTX permission has been granted.

Upon receipt by the CD for which PTX authorization is requesting, this CD will begin transmitting media to CM218. Until the wake-up timer 618 expires, CM218 suppresses the transfer of media to other net members. This is done by the buffer 622 in the CM218 or the CM218 which stores the media in the internal media buffer inside the CD202. The value of the wake-up timer is generally larger than the value of the PTX pause response timer. If the information is stored within the wakeup time period, the CM218 initiates media and media signaling transfer from buffer 622 or the internal media buffer after the wakeup timer 618 has expired. If no information is transmitted within this time, any media received from the CD with transmission privileges will be transferred directly to other net members.

Ideally, the PTX pause response timer is set to zero for a quick reply in response to a PTT request. The wake-up timer allows the CD to timely reestablish the communication channel while the PTT requester is sending media to the CM218. After the wake-up timer expires, CM218 announces to the speaker by sending a PTA message to the net participants at time 6. Then, any media stored in the buffer may be transferred to another net member. If buffering was not performed prior to the end of the wake-up timer, the media will be transferred to other net members when the CM218 receives the media from the speaker.

Note that the CM218 can receive an IAH message response during the extended time after the net exits hibernation, and the CM218 will respond to all net participants before allowing the reserved PTT request. You may not wait for it. A delayed responder whose IAH response arrives after the PTX message response has been sent remains listed as a net participant, but may not receive all initial media traffic and signaling. Any CD that does not respond to the AYT request after a configurable time period is assumed to be unreachable and will be removed from the list of active participants on the net.

PTT arbitration signaling FIG. 10 shows a sequence of group communication media signaling messages indicating a higher priority CD that has speaker privileges and interrupts the lower priority CD.

At time 1, the low priority CD sends a PTT message request to CM218. This PTT message request is granted by CM218 at time 2. CM218 announces that CD202 has speaker privileges by issuing a PTA message to net members at time 3.

While the low priority CD is transmitting media, the second CD attempts to interrupt by sending a PTT message request to CM218 at time 4 to the same net. The CM218 has a higher priority than the CD on which the second CD is speaking, and therefore revokes speaker privileges from this CD by sending a PTX revocation message to the speaking CD at time 5. The CM218 then grants a PTT request to the high priority CD by a normal PTX message response at time 6 and sends a PTA message to the net member at time 7 that the high priority CD has speaker privileges. Announce by sending.

If CM218 determines that the suspended CD does not have a higher priority than the first CD, CM218 rejects the PTT request with a PTX message response and net participants from the talking CD. Continue to deliver media to.

The priority applied to a particular CD is generally a fixed value defined by the database held by CM218, but CM218 may use other arbitration algorithms. This algorithm does not always grant speaker privileges to the highest priority requesting participant, as shown here. The PTT arbitration algorithm used to arbitrate conflicts can be configured individually for each net.

CD user addressing Both SIP call signaling and PGP public key encryption require the presence of a unique user ID or similar identifier to uniquely identify the CD202. The CM218 user database specifies an internal user identifier (which may be transferred to CD202 and used by CD202 in media signaling requests). However, this user identifier does not necessarily have to be appropriate as a unique CD user address. The CD202 user ID address must also not contain any confidential or private data. This public disclosure could undermine existing cellular infrastructure authentication mechanisms.

As long as the CD202 user address meets these basic constraints, many reasonable provisions can be accepted. Given that each CD also has a unique dial number, one possible rule would be based on the syntax below.

MS &lt;DN&gt; @ nbs. &lt;Service Provider Domain&gt; Where &lt;DN&gt; indicates the dial number of the CD202 and &lt;service provider domain&gt; is a fully decorated domain name associated with the service provider's IP network. Using this definition, as a user address for a CD with dial number 619-972-6921 MS6199726921 @ nbs. Qualcomm. Com May be assigned. Note that this form also allows the CD to be applied to multiple unique user addresses for each service provider.

A more common CD user address assumes the form below. &lt;username&gt; @ &lt;domain&gt; Here, &lt;user name&gt; is a user-definable character string unique to a specific &lt;domain&gt;, and &lt;domain&gt; is an arbitrary Internet DNS domain. For example alice.smith@users.wirelessknowledge.com May be the CD202 user address of user Alice Smith.

The CD202 user address may be used in the sender's header during SIP registration and solicitation and may be used to configure other parts of the requested SIP syntax. The user address can also be used as input to generate a private PGP key used to authenticate SIP requests.

The CD202 user interface allows the user to view and / or modify the user address.

CD certification To prevent certain denial service attacks and prevent CD masquerading, CM218 may require CD202 to be certified prior to registering or joining the net. Authentication may be done at the application level, independent of other authentication schemes that may exist at the network or cellular infrastructure level. In one embodiment, CD authentication is also configured and works independently of the concepts and data structures that support an encrypted (secure) net.

In particular, CM218 may require CD202 to include an authentication header with a SIP request. The authentication header utilizes a PGP public key cryptographic signature to ensure that SIP messages are signed by CD202.

Public key encryption generates public and private keys from private secrets known only to the cryptographic device (CD202 in this case). In combination with this secret, the private key is required to sign the message, while the public key is used by itself to verify the signature of the signed message. Therefore, to support SIP authentication, each CD is provided with a private secret and a private key, which are usually never shared. Each of the CM218s that the CD may need for self-authentication is generally required to know the public key of the CD202. Since the public key is not secret, it can be stored as part of the user database held by CM218, or it may be accessed through a public key server on the Internet.

The CM218 can require CD authentication at the server, net, or user level. At the server level, CM218 requests the CD connected to the CD's CM218 SIP server to provide an authentication certificate and reject unauthenticated requests. When server-level authentication is possible, only CDs whose identifier (ie, the public key of the CD) is known to CM218 in advance can effectively use the server. Server-level authentication can protect the CM218's SIP server from many relatively easy denial of service attacks.

CM218 can protect one or more nets it manages through authentication, but may leave the other nets unprotected. When a CD attempts to solicit itself to a protected net, CM218's SIP server generally rejects the request unless CD202 is authenticated by CM218.

Finally, CM218 uses authentication to ensure that the CD (or generally any SIP user agent client) does not attempt masquerading like other CDs, and thus against legitimate net participants. Deny service or passively monitor net media channels. If the CM218 requires that a particular CD be authenticated, the CM218 will generally connect as a CD202 unless the client's SIP request has further authentication, such as a PGP signature that can be verified by the CM218. Do not accept SIP requests from clients. Authentication may be configured on a per-user basis. In this example, CM218 can allow other users to participate unauthenticated, while requiring that certain users must be authenticated before joining the net.

The PGP private key may be administratively provided within CD202 or created by CD202 once the CD202 user address is specified. The private key does not need to be stored externally, but the associated public key can be read into the user database of any SIP server that requires CD authentication.

Multiple group communication systems The above description assumes that, in at least one embodiment, the systems and methods of providing group communication services are employed as independent services, with one CM218 being completely independent and specific geographical. Operates within an area or area of service. However, it should be noted that at least one embodiment of a system and method of providing group communication services can also extend group communication services beyond the services of local geographic areas. This means that Globalstar can be applied to multiple communication networks, including GSM, TDMA, and CDMA cellular networks.^TMAnd Iridium^TMAchieved by deploying commercials on corporate intranets utilizing satellite communication systems such as, local area networks or wide area networks. ..

Communication between CMs on different systems takes advantage of SIP server redirects, exchange of user and net database records, and additional messages between CMs that facilitate integrated NBS services.

In the integrated group communication service, it is preferable to be able to assume the ownership of the net to any CD so that the operation of the net is not strictly restricted to a specific CM218 or MCU602. The choice of CM may instead be determined dynamically. This is based on the proximity of the net participants to the majority (determined using available positioning techniques), the quality of service available in the service provider's internal network of systems, and other factors. There is. Similarly, the SIP redirect server for any CM must be able to redirect any CD to the SIP user agent server for the appropriate MCU. And / or, if necessary, it should also be possible to transfer the CD to another SIP redirect server.

In this integrated system, the net address of the net has meaning across the group communication system. As a result, one or more top-level SIP servers are responsible for redirecting solicitation requests and delivering net participants to the MCU. These top-level SIP servers share a common user and net database to provide the same functionality and redirection decisions at different network rendezvous points. As a result, solicitation redirection originating from CDs provides an important and definitive layer extraction that allows multiple CM installations to be integrated into a single homogeneous group communication service.

The integrated group communication system is shown in FIG. 11. In this example, the CM1000 supports a terrestrial cellular communication network and the CM1102 supports a satellite communication network. In integrated group communication services, the system scales by repeating the functionality provided by MCU controller 612, an associated set of MCU 602, known as MCU cluster 1104, and associated SIP user agent server 600. A single database 1106 and administration interface 1108 are shared by multiple CMs in the system. Communication between functional entities is not shown.

The process by which a CD joins the net in such an integrated system is similar to the process used in a system with a single CM installation. CD202 first sends a SIP request to the top-level (now global) SIP redirect server 1110. The SIP redirect server 1110 redirects the requesting CD to the appropriate destination through a signaling mechanism such as SIP. In the case of a solicitation request to join the net, the destination is the SIP user agent server 600 associated with the MCU currently responsible for the target net. In the case of a solicitation requesting the current list of nets available to CD202, the destination may generally be any user agent capable of responding to the request.

Separately, the redirect server 1110 can exchange additional messages with the MCU cluster 1104 through application-to-application messaging utilizing known implementation-specific protocols and / or messaging rules.

If not integrated, a special startup action is required to ensure that the redirect server 1110 can determine the destination for the solicitation request received by the redirect server 1110. One possible configuration requires SIP registration to reside on redirect server 1110. The redirect server 1110 may be required to query the global database 1106 and attempt to map each solicitation request to the definition of the net contained therein.

Commercial security In one embodiment, encrypted group communication is possible as an optional feature. As an option for net users, audio and data transmitted over a particular net may be encrypted on the sending CD or decrypted by all other CDs on the net. The encryption is end-to-end, that is, from the first CD to the second CD. Communication from CDs is generally encrypted by commercial cryptographic algorithms. This algorithm is built into the CD. In one embodiment, it is the net user's discretion to choose whether to treat the net as encrypted or unencrypted, and usually no CM218 involvement is required. ..

The user can choose whether or not he prefers to encrypt the communication on a net-by-net basis. In one embodiment, the user is provided with the ability to enter an encryption key into the net using a user interface. Therefore, the user can select an encryption option for the net and participate in encrypted communication with other users of the net using the same encryption key.

In general, at any time, the user can enable encryption or display disable of net traffic.

In one embodiment, media traffic is symmetrically encrypted through the use of a symmetric key, or traffic encryption key, a key known as TEK. This key is shared by other net users. In general, for net users, there is no key agreement algorithm, such as the well-known Diffie-Hellman algorithm. Net traffic encryption keys are generated offline by a net user or net administrator and are securely delivered to net participants who manually enter the key on their respective phones. This key is used for all media traffic to a particular net until a new key is generated, delivered to the net user, and replaced with the old net TEK.

Encryption selection As mentioned above, when becoming a member of a particular net, CD202 is notified via a message received from CM218. The net administrator for a particular net can set an advisory flag to indicate that net traffic should be encrypted. This display is for advice only and does not officially indicate that communication on the Internet is actually encrypted.

The CD202 user interface allows the user to specify any net as an encrypted net, and also allows the user to enter the net regardless of whether the encrypted advisory flag for the net was received by CM218. Allows you to enter the TEK.

The CD can force the shortest and longest key lengths to be determined. The CD can provide a means for the key checksum entered with the key, and if provided, check the checksum for the entered key. If no checksum is entered, the phone calculates the checksum and makes it visible to the user. CDs generally do not show keys on the phone display after the first keystroke.

If the key is successfully entered for a given net, media transmissions on this net will be encrypted using this key and traffic received on this net will be decrypted using this key. .. Encrypted traffic contains additional headers. This allows the phone to synchronize with the encryption / decryption process, allow for delayed synchronization (synchronization for transmissions already in progress), and also ensure that the sender and receiver are using the same traffic encryption key. It can be so. If a CD receives encrypted traffic (detected by the presence of an encryption header) on a net that is not designated as encrypted, then the CD is receiving encrypted traffic. Show the user, for example, mute audio or suppress data output and do not output traffic. Similarly, on a net that is configured to be encrypted, if the CD receives unencrypted media traffic, or if the traffic is not decrypted correctly (for example, if the keys are incompatible). , The phone must alert the user and mute the traffic.

Key generation and delivery The key for an encrypted net is generally a random binary number. Generally, this key is generated by one party on the net or an administrator of this net and is securely distributed to net participants. Since the key delivery policy is currently left for net users and is outside of CM218, it is a potential source of net security compromise. The preferred method of key delivery is via secure means, such as by PGP encrypted email to net participants. Other methods are also possible, such as telephone calls, face-to-face visits, or automated delivery, which utilize the PGP private key commonly built into each CD for SIP authentication.

Entities that work to generate keys for a secure net must choose a random binary number that is long enough to guarantee the level of security required. This key is then converted to a decimal number containing the numbers 0-9 for the user to enter on CD202. The CD202 then converts this decimal number to a binary number and uses this binary number as the encryption key. To enter the number corresponding to the 112-bit key, for example, the user must enter a 34-digit decimal number. CDs can generally detect "bad" keys, such as all zeros, all ones, or alternating ones and zeros.

In one embodiment, the encrypted net utilizes "counter mode" encryption. This includes electronic codebook (ECB) encryption of counters known as state variables or state vectors (SVs) and exclusive OR processing of the output in blocks of plaintext bits. The counter value is incremented and the process is repeated for each block of plaintext. The encryption algorithm used in one embodiment is Triple DES (E) with two keys.₁D₂E₁Mode) and is used in counter mode. The codebook width is 64 bits. Other encryption algorithms are also possible.

In one embodiment, the length of the encryption key is fixed at 112 bits. If the user enters an insufficient decimal digit to create a 112-bit binary key, a fixed pattern is added to the user's input to create the 112-bit binary number. In one embodiment, the lower 56 bits are the first DES (E).₁) Used as an encryption key. The upper 56 bits are the second DES (D)₂) Used as a key. Of course, other changes are possible.

The configuration of the state vector (SV) is shown in Figure 12. In one embodiment, the state vector consists of the following fields:

16-bit sender ID field 1200: This field is used to help ensure that the cryptographic SV between users is unique. For group communication services, the sender ID must be a unique number for all users of a particular TEK (eg, unique to encrypted nets). When the key is entered into the phone for a particular net, the sender ID is randomly chosen by CD202. Alternatively, the user may have the option to enter a known and unique random value. Sender IDs are generally net-specific and do not change as long as TEK is used.

· 4-bit application ID field 1202: This field is used to identify cryptographic streams that are used for different, but perhaps concurrent applications, such as voice, data, or in-call signaling.

44-bit status counter field 1204: This field is subdivided into the following subfields: --2-bit latent component 1206: This field is usually never sent (hence this is potential), but to preserve the uniqueness of the SV whenever multiple codebooks are needed to encrypt (or decrypt) the data frame. Used for. This counter can be thought of as a data frame codebook counter, which is reset to zero on each new data frame, counting the codebook used for each data frame. - 14-bit short-term component 1208: This field is sent periodically (in the RTP payload) and acts as a data frame counter. For group communication services, the entire field is sent once for each transmitted packet (which may contain one or more data frames). This field can be thought of as a data frame counter. That's because it increments by one for each data frame, regardless of the number of codebooks required for each data frame. --28-bit long-term component 1210: This field constitutes the "higher order" bits of the 42-bit counter formed by the long-term and short-term components. Whenever a short-term component rolls over during transmission, this field is automatically incremented by one. The initial value of the long-term component is randomly selected when a new key is entered. The long-term component is incremented each time the short-term component rolls over. When the long-term component reaches the all-one state, the long-term component rolls over to all-zero.

Initialization and SV uniqueness Initialization of the low 44 bits of the state vector (other than the 2-bit latent field, which is reset to zero for each data frame) is not required. However, the transmitter is required to ensure that the state vector (SV) is unique for the life of the traffic key. The life of a traffic key is arbitrary (but finite) time. The sender ID field 1200 helps ensure that the SV is unique within a group of net users. The latent bits are initialized to "00" and used as codebook counters in the data frame in a contiguous order. This feature is applicable to data frames longer than a single codebook.

Since there is no central authority for assigning sender IDs, the uniqueness of sender IDs among net users cannot be absolutely guaranteed. When a new key is entered, the sender ID is generally set randomly. This ID remains constant for the life of the key. In the rare event that more than one participant on the net uses the same sender ID, the uniqueness of the SV is still recognized if the long-term and short-term components between its users are unique. sell.

Application ID 1202 is used to distinguish between cryptographic streams generated by different applications.

Retention of state vector Transmitter For each data frame delivered to the cryptographic device, the transmitter ensures that the state vector is unique while the traffic key is valid. This is achieved in the encryption operation by incrementing the existing short-term component following the use of the state vector (ie, after encryption of one data frame). The latent component is initially set to zero and is incremented for each successive codebook generated to encrypt the data frame. When the short-term component reaches its maximum value during a call, the transmitter sets the short-term component to zero and increments the long-term component.

Receiving machine For the data frame delivered to the decryption device of the receiver, the related status counter is determined prior to decoding. Short-term and latent components are extracted from the RTP payload when used and provided to the decryption device along with the data to be decrypted. If the short-term component reaches its maximum during a call, the decoding device increments the long-term component to maintain synchronization. The decoding device also tracks the periodic reception of a portion of the state vector embedded in the stream, facilitating delayed input. If for some reason a mismatch occurs, the decoding device periodically uses the recovered values to update the relevant part of the state vector for decoding.

Maintaining cryptographic synchronization The synchronization between the transmitter and the receiver must be maintained. In general, encryption of each data frame begins with a new codebook. That is, no attempt is made to save the codebook bits from one frame to the next. If more codebook bits are generated than required for encryption, the remaining bits are discarded after the data frame is encrypted. The receivers must be synchronized according to the same procedure.

State vector synchronization is maintained by periodically transmitting a portion of the SV as required by the application. Cryptographic synchronization information is transmitted within the RTP payload using the appropriate RTP payload profile. The cryptographically synchronized portion of the initial RTP payload consists of a short-term component (14 bits), a sender ID (16 bits), an application ID (4 bits), and a long-term component (28 bits), as shown in FIG.

Consecutive RTP payloads update the short-term component and application ID for each payload, while the remaining fields (including the long-term component) are periodically transmitted 6 bits at a time, which is required for group communication. Facilitates "delayed input". Since 44 bits are transmitted periodically (long-term 28 bits + sender ID 16 bits), 44/6 or 8 packets are used to accumulate these components from periodic transmissions. In addition, a pre-defined signal, such as the two transmissions of all 1 (111111), must be included as the start of the frame flag during each period of the periodic transmission (8 packet periodic transmission + 2). One flag). The value of the long-term component transmitted in the 8-frame sequence is the value that was valid in the first flag frame at the start of transmission (this covers the case where the long-term component is rolling over).

If RTP is not used (eg, CRTP header compression is not available), the same information as above must be included in the "application header" of the UDP packet stream. Briefly, the transmission and maintenance of cryptographic synchronization should be similar to that used when the RTP is presented.

Key checksum In one embodiment, the CD202 calculates a checksum on the input traffic encryption key. The checksum can be used to confirm that the correct key has been entered. Alternatively, it can be exchanged between users (eg, verbally or via email) to ensure that users are using the same TEK for a particular net. The checksum information must allow the user to determine the value of the key.

The CD202 calculates a checksum for any key entered, which is generally available for display to the user. The checksum may optionally be entered with a key. If the user enters a checksum, the CD202 cannot accept the key unless the entered checksum matches the checksum calculated by the CD.

Sync check The CD being transmitted generally contains a synchronous checkword periodically during the encrypted transmission. In one embodiment, the synchronization checkword uses the net's current TEK and the net's current synchronization cryptographic state variable to encrypt known constants and the results as shown in FIG. This is the result of truncating to the 16 low-order bits. The 16-bit sync checkword is sent in the 16-bit sync check header of the RTP payload.

The sync check field is periodically included in the transmit stream to provide delayed input / synchronization for transmissions that are already in progress (ie, the receiver missed the transmission of the entire state variable at the start of the transmission). to enable. Synchronous check fields are transmitted periodically, at least every second, in one embodiment.

Cryptographic checkword encryption uses one value of the short-term component of a cryptographic synchronization state variable, just like standard data frame encryption. If a synchronous checkword is included in the outgoing RTP frame, the first state variable value is used to encrypt / decrypt the synchronous checkword, and payload encryption / decryption begins with the following values:

The constant value used in the synchronous checkword generation process is entered with the net TEK. In one embodiment, the constant is 64-bit long and equal to the length of one codebook. The constant value is added to the key and entered as one long decimal sequence. A delimiter may be used to separate the key from the synchronization check constant. Checksums are calculated for keys and synchronous check constants.

The preferred embodiments described above are provided so that those skilled in the art can create and use systems and methods for providing group communication services. It will be apparent to those skilled in the art that various modifications to these embodiments will be easy, and the general principles set forth herein may be applied to other embodiments without utilizing the functions of the invention. it can. Therefore, the systems and methods of providing group communication services are not intended to be limited to the embodiments presented herein, but to be consistent with the broadest scope consistent with the principles and novel features disclosed herein. ing.