System and method for providing group communication services

ES 2 320 731 T3

DESCRIPTION

System and procedure for providing group communication services.

Background of the invention

I. Field of the invention

The system and method for providing group communication services refers generally to point-to-multipoint communication systems and more particularly to a method and apparatus for providing group communication services.

II. Description of Related Art

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

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

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

In a typical push-to-talk system, a dedicated channel, sometimes referred to as a broadcast channel, is used to transmit communications from one member to multiple other members of the network simultaneously. Generally, only one member can transmit voice information to other member users at any given time. If another member tries to transmit on the broadcast channel while another member is transmitting, interference will occur between the two competing communications, causing unintelligible communications to be received by the other members of the network.

To implement a push-to-talk communication system in a conventional wireless communication system, expensive infrastructure modifications are necessary. Currently, there is today at least one push-to-talk communication system that allows point-to-multipoint communications to take place by undertaking such modifications. An example of such a system has been designed by Motorola Incorporated of Schaumburg, Illinois, and marketed as the Nextel Direct Connect service.^®, offered by Nextel Communications of Reston, Virginia.

Aside from the cost problem associated with current point-to-multipoint wireless communication systems, communications are generally restricted to members operating relatively close to each other using the same communication technology. In other words, point-to-multipoint communications do not extend from a CDMA communication system, for example, to other communication networks or technologies, such as a GSM communication system, a public switched telephone network (PSTN), a network of data, such as the Internet, or to a satellite communication system such as the GlobalStar ™ satellite communication system.

International Patent Publication No. WO99 / ​​63773 discloses a dynamic allocation of radio resources in a packet-switched communication system.

International Patent Publication No. WO97 / 28658 discloses a method and apparatus for providing a private communication system in a public switched telephone network.

International Patent Publication No. WO97 / 47149 discloses a method and apparatus for conserving energy of a remote unit in a dispatch system.

ES 2 320 731 T3

These obstacles to providing group communication services are overcome by various embodiments of the system and method for providing group communication services as described in this document.

Summary of the invention

In one embodiment, as set forth in the appended claims, the system and method for providing group communication services is implemented within an existing CDMA wireless communication system.

Point-to-multipoint communications are enabled in one embodiment of the system and method to provide group communication services by converting audio, video, and real-time data (collectively referred to herein as media), into data packets in a communication device. (CD). Data packets can be produced according to data protocols, for example, the well-known Internet protocol TCP / IP. The media is transmitted using an air interface, or by other means, depending on what type of communication device is used, to a data network, typically the Internet.

A communications manager (CM) enables data packets from the data network to be distributed to various network members of each defined network. Therefore, adding the CM to a standard communication system makes group communications quickly possible. The CM is a device that acts as a configurable switch, connecting communications from one user to one or more of the other users defined as a network. The CM is a data device, which means that it sends and receives data packets, as defined by the particular data network to which it is connected. In one embodiment, the CM is directly connected to the Internet, allowing data packets to be routed between the CM and ultimately the CDs.

The CM allows users other than those of the wireless communication system to participate in group communications. For example, an audio-capable desktop computer located in an office or home could participate in group communications with one or more users of a terrestrial wireless communication system. Alternatively, or in addition, users of a satellite communication system may participate in group calls with members of the terrestrial wireless system, desktop computer users, or both. Information between these various communication devices, i.e. cordless phones, landlines, satellite phones, pagers, laptop or desktop computers, digital cameras, camcorders, etc., is transmitted between network members over the network of data, coordinated by the CM.

An advantage of the system and method of providing group communication services over conventional wireless group communication systems is the ability to quickly and economically implement group communication services in a wireless communication service. For example, a CDMA wireless communication system conforming to the IS-95 standard can support group communications simply by adding the CM and compatible point-to-multipoint communication devices. Another advantage of the system and method of providing group communication services is the ability for group communications to extend beyond the traditional limits of traditional wireless group communication systems. Using the system and method to provide group communication services, users of a CDMA wireless communication system can establish group communication with users of different communication devices and technologies.

Brief description of the drawings

The features, objects, and advantages of the system and method for providing group communication services will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like reference characters correspondingly identify along of all of them and in which:

Fig. 1 is an illustration of a typical prior art wireless communication system unable to implement group communications;

Fig. 2 illustrates a group communication system of one embodiment of the system and method for providing group communication services in functional block diagram format;

Fig. 3 illustrates the operating protocols used in the group communication system of Fig. 2;

Fig. 4 illustrates a typical communication device used in the group communication of Fig. 2;

Fig. 5 is a state diagram illustrating the various operating states of the communication device of Fig. 4;

Fig. 6 is a functional block diagram of a communication management used in the group communication system of Fig. 2;

Fig. 7 illustrates an interaction between the communication device of Fig. 4 and the communication manager of Fig. 6 when the communication device of Fig. 4 attempts to join a network;

Fig. 8 illustrates an interaction between the communication device of Fig. 4 and the communication manager of Fig. 6 when a push-to-talk switch located on the communication device of Fig. 4 is actuated;

Fig. 9 illustrates an interaction between the communication device of Fig. 4 and the communication manager of Fig. 6 to establish and exit a latency period;

Fig. 10 illustrates an interaction between a first communication device, a second communication device, and the communication manager of Fig. 6 during a revocation of a talker privilege;

Fig. 11 is a functional block diagram of an interaction of a first communication manager and a second communication manager;

FIG. 12 is an illustration of a state vector used in one embodiment of the system and method for providing group communication services;

Fig. 13 is an illustration of a cipher sync portion of an initial RTP payload as used in conjunction with the state vector of Fig. 13; and Fig. 14 is a functional block diagram illustrating the generation of a sync check word.

Detailed description of the preferred embodiments

The system and method for providing group communication services uses a communication device (CD) capable of generating data packets suitable for transmission over a data network such as the Internet. The data packets are transmitted to a data network, and are then delivered to a communications manager (CM) connected to the data network. The CM processes the data packets from a first CD and distributes the data packets in real time to at least one other CD that is a member of the same predefined network as the first CD. The CM acts as a configurable switch capable of routing communications from any member of the network to other members of the network defined by the network.

Although the teachings of the system and method for providing group communication services are described with respect to a CDMA wireless communication system, it should be understood that the system and method for providing group communication services can be used with any wireless communication system including wireless communication systems. GSM, AMPS systems, TDMA systems, and satellite communication systems, as well as other communication systems. Furthermore, the system and method for providing group communication services is not limited to wireless communication systems. It can be used with landlines, pagers, laptop or desktop computers, digital cameras, camcorders, etc. Furthermore, it should be understood that the system and procedure for providing group communication services is applicable to both real-time data, such as audio and video data (including voice data), and time-independent data, such as computer files, email , and so on.

FIG. 1 is an illustration of a typical prior art wireless communication system 100 unable to implement group communications, otherwise known as point-to-multipoint communications, or push-to-talk communications. The CDs 102, 104, 106 represent three of a large number of cordless telephones scattered over a small geographic area served by the communication system 100. The CDs 102, 104, 106 transmit and receive communication signals from base stations 108, 110, generally depending on their proximity to each base station. In a typical wireless communication system, there are many base stations in use to support the large number of active CDs in the communication system 100.

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

Group communications are not generally possible using the communication system of Fig. 1. However, teleconferences between multiple users in the wireless communication system can be achieved if special circuitry is employed within the MSC 112 to allow such teleconferences to be made. teleconferences. For example, landline phone 116 may be able to communicate with CDs 102 and 104 simultaneously in a conference call. A teleconference differs from group communications in that teleconferences are generally non-arbitrated, that is, the users of the teleconference can speak simultaneously, and be heard by all other users of the teleconference. The result in this situation is generally a confusing speech for each user, due to the multiple conversations that are simultaneously broadcast to each user. A well known device for conducting such a teleconference is a conference bridge.

ES 2 320 731 T3

Overview

An embodiment of the system and procedure for providing group communication services is illustrated in FIG. 2 in functional block diagram format. Group communication system 200, otherwise known as a push-to-talk system, a network broadcast system, a dispatch system, or a point-to-multipoint communication system is shown. A defining characteristic of such a communication system is that generally only one user can transmit information to other users at any given time. In group communication system 200, a group of communication device users, individually known as members of the network, communicate with each other using a communication device assigned to each member of the network.

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

Members of the network communicate with each other using an assigned communication device, shown as communication devices (CDs) 202, 204, 206, 208, and 210. In the present example, CDs 202, 204, and 206 are cordless telephones. terrestrial, the CD 208 is a landline phone equipped with push-to-talk capability, and the CD 210 is a satellite phone also equipped with push-to-talk functionality. In other embodiments, the various CDs may comprise wireless camcorders, still cameras, audio devices such as music players or recorders, laptop or desktop computers, or paging devices. In another embodiment, at least one CD comprises a combination of the just described embodiments. For example, the CD 202 could comprise a cordless land telephone equipped with a video camera and display. Furthermore, each CD may be able to send and receive information in either a secure mode, or a non-secure (free) mode. Throughout the following discussion, the reference to an individual CD may be expressed as CD 202. However, it should be understood that the reference to CD 202 is not intended to limit the discussion to a landline wireless telephone. In general, the discussions regarding CD 202 will apply equally to other types of CDs as well.

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

To participate in group communications, each of the CDs 202, 204, 206, 208 and 210 is equipped with a means to request transmission privilege from a communications manager (CM) 218, as explained in more detail below. . The CM 218 manages the real-time and administrative operation of the networks, including arbitration of PTT requests, maintenance, and distribution of lists of membership to the network and registration, call establishment and disconnection necessary resources of the system and the network, as well as a general control of the state of the network.

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

The CM 218 is designed to be remotely managed by a communication system service provider, network members, or both, assuming authorization is provided by the service provider. The CM 218 can receive network definitions through an external management interface 226. Members of the network can request administrative actions through their service provider or manage network functions through defined systems, such as a security manager (SM) operated by a 228 member that fits a CM management interface 218. The CM 218 can authenticate against high-quality business standards any party attempting to establish or modify a network.

The SM 228 is an optional component of system 200 that performs key management (ie, distribution of encryption keys to network members), user authentication, and related tasks to support secure networks. A single group communication system can interact with one or more SMs. The SM 228 is generally not involved in real-time control of a network, including network activation or PTT arbitration. The SM 228 may have management capabilities compatible with a CM 218 interface to automate management functions. The SM 218 may also be capable of acting as a data endpoint for the purpose of participating in a network, to broadcast network keys, or simply to monitor network traffic.

ES 2 320 731 T3

In one embodiment, the means for requesting the transmission privilege comprises a push-to-talk (PTT) key or switch. When a user of the communication system 200 wishes to transmit information to other members of the network, the push-to-talk switch located on his CD is pressed, sending a request to obtain the transmission privilege from the communication manager 218. If no other member of the network is currently assigned the broadcast privilege, the requesting user is granted the broadcast privilege and is notified by an audible, visual, or tactile alert via the CD. After the requesting user has been granted the transmission privilege, then information about that user can be transmitted to the other members of the network.

In one embodiment of the system and method for providing group communication services, each member of the wireless network establishes a forward link and a reverse link with one or more base stations 216 or the satellite-gateway 212, as the case may be. The first is used to describe a communication channel from a base station 216 or satellite-gateway 214 to a CD, the second is used to describe a communication channel from a CD to a base station 216 or the gateway 212. Voice and / or the data is converted into data packets using a CD, the data packets being suitable for the particular data network 214 through which communications to other users take place. In one embodiment, the data network 214 is the Internet. In another embodiment, a dedicated forwarding channel is established in each communication system (ie, a terrestrial communication system and a satellite communication system) to broadcast information from each member of the network to the other members of the network. Each member of the network receives communications from other members of the network through the dedicated channel. In yet another embodiment, a dedicated reverse link is established in each communication system to transmit information to the CM 218. Finally, a combination of the above schemes can be used, for example, establishing a dedicated forwarding broadcast channel but requiring that Wireless CDs transmit information to CM 218 over an individual reverse link assigned to each CD.

When a first member of the network wishes to transmit information to other members of the network, the first member of the network requests the transmission privilege by pressing a push-to-talk key on his CD, which generates a request formatted for transmission over the network. data 214. In the case of CDs 202, 204 and 206, the request is transmitted over the air to one or more base stations 216. The MSC comprises 220 comprises a well-known interworking function (IWF) (not shown) for processing data packets, including the request, between the MSC 220 and the data network 214. For the CD 210, the request is transmitted by satellite to the satellite-gateway 212. For the CD 208, the request is transmitted to the public switched telephone network (PSTN) 222, then to the modem bank 224. The modem bank 224 receives the request and provides it to the data network 214.

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

In an alternative embodiment, CM 218 is embedded within MSC 220 so that data packets from support base stations are routed directly to CM 218 without being routed over data network 214. In this embodiment, CM 218 it is still connected to data network 214 so that other communication systems and devices can participate in group communication.

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

Detailed description

The interfaces to the system are grouped into functional and physical interfaces. The physical interfaces are not unique to the group communication system 200 and are comprised of an existing wireless air interface, wireless service options, and commercial data networking standards. Upper layer functional interfaces, especially at the application layer, are unique to the group communication service.

At the application level, the system and method for providing group communication services operates over three Internet-based protocols in one embodiment, as shown in Fig. 3. Of course, in the alternative other protocols could be used, or a number different protocols. Communications between the CM218, and CDs 202, 208, and 210 occur within these protocols. CDs find, join, leave and learn about various networks using a first protocol, known as the Session Initiation Protocol (SIP), which is a well-known signaling protocol used in the telecommunications industry. The second protocol,

ES 2 320 731 T3 shown in Fig. 3 as NBS Media Signaling, is used to manage network arbitration and latency in real time, as explained later in this document. Audio, including voice, video, or data (collectively referred to herein as media), is delivered separately by means of a third protocol, shown in Fig. 3 as media traffic. In the example of Fig. 3, CD 202 currently "has the turn," that is, the streaming privilege, or permission to stream media to the network. A "shift control" request is a request for broadcast privilege. While CD 202 has streaming privilege, the remaining members of the network, shown on the right, are designated as listeners and consequently are not allowed to stream media to the network. Generally, any CD can send media signaling or SIP signaling traffic at any time, regardless of whether it has the transmission privilege.

In one embodiment, CM 218 includes modem bank 224 that interfaces with PSTN 222. In another embodiment, modem bank 224 is located separately from CM 218. The CDs that interface with the CM 218 through this interface establish an IP connection with the CM 218 using the well-known point-to-point protocol (PPP), or optionally, any other equivalent link layer protocol, running over one of several standard dial-up modem protocols available.

In one embodiment, each of the CDs 202, 204, and 206 provide a packet data connection to the CM 218 in accordance with the IP packet data service option IS-707.5. IS-707.5 is a well-known interim standard that describes packet data services in a CDMA communication system. Changes can be made to this interface to optimize group communication performance. No changes on the infrastructure side of this interface are desired, except an implicit requirement for RTP / UDP / IP header compression at the base stations to support media broadcasting using RTP (real-time protocol).

Alternatively, CDs 202, 204, and 206 could support most group communication activities using Quick Net Connect (QNC) and IS-707.4, as described below.

The CM 218 communicates with CDs participating in group communication via group communication and transport application layer protocols. These communications include application signaling (PTT transmission privilege requests, network registration, etc.) as well as real-time voice media packet streams distributed by the CM 218. All real-time media is distributed over interfaces. Dynamic RTP / UDP / IP on CM 218 and CDs. If no CRTP header compression (a well known header compression technique) is available, the real-time media is directly encapsulated within UDP / IP packets, or datagrams. All real-time signaling occurs over dynamic UDP / IP interfaces on the CM 218 and CDs. Other signaling can take place over a predefined data protocol interface, such as TCP / IP, between the CM 218 and the CDs using the well-known Session Initiation Protocol (SIP), an application-level call signaling protocol designed to support Internet telephony.

The CM 218 provides an external user interface to communicate with external users using the same group communication and transport application layer interfaces used to interact with the CD 208, except that these protocols will work over IP / PPP and modem connection. switched line connection.

The CM 218 provides a management interface which is an application level protocol that provides administrative access of a CM user, network, and management database and associated parameters using Hypertext Markup Language (HTML) semantics. In one embodiment, the interface works over TCP / IP. There may also be a second network interface that supports administrative functions. This second administrative interface supports the bulk of real-time transfers of administrative information, including membership lists and network status reports, to Java or similar client administrative applications.

The Sm 228 communicates with CDs using a key exchange protocol that works over TCP / IP.

One embodiment of the system and method for providing group communication services operates by standard air interface IP packet data services, eg, as defined in the IS-707 standard, and conventional IP. A registered CD traffic channel is allocated while a network is active, that is, media is being transmitted between members. Each network is defined and identified by its name, which when combined with the address of a host system, defines a destination address that can be expressed in the form of a SIP URL. As previously mentioned, SIP (Session Initiation Protocol) is a well-defined signaling protocol used to control configuration and control signaling between CDs and the CM 218. So, a SIP URL can be defined as:

sip: <net> @ <nbsdomain>

where net indicates the name of a network defined in the context of a group communication system indicated by nbsdomain. A network name is an alphanumeric label that uniquely identifies the network within the communication system. The nbsdomain is a virtual system domain (or subdomain) that defines an address space in which each network address on the network resides. The nbsdomain, as well as the names of all the networks available on the system, are defined through administration actions based on the privileged CM 218.

ES 2 320 731 T3

For example, the localpolice network defined within a domain nbs.acme.com would have a corresponding network address of:

sip: localpolice@nbs.acme.com

A group communication system domain includes a high-level SIP redirection server that maintains SIP registrations for the domain and acts as the initial meeting point for all SIP signaling. The top-level server can be made up of multiple servers that act as a single logical entity and share a common data set to provide reliability and scalability guarantees. In addition, a group communication system domain may include a logically separate high-level SIP (redirect) server. This is to ensure that each CD maintains an Internet network address of both a primary and secondary top-level SIP server.

FIG. 4 illustrates CD 202 as used in one embodiment of the system and method for providing group communication services. More details of CD 202 can be found in US patent application Ser. pending processing number 09 / 518,776, entitled "METHOD AND APPARATUS FOR PARTICIPATING IN A GROUP COMMUNICATION SERVICE IN AN EXISTING COMMUNICATION SYSTEM", filed on March 3, 2000, granted to the assignee of the system and procedure to provide group communication services, and is incorporated herein by reference. In this embodiment, CD 202 is a cordless telephone capable of converting media, typically human voice, into data packets suitable for transmission over data network 214, such as the Internet. It should be understood that many of the features incorporated into the CD 202, as shown in Fig. 4, can also be implemented in any communication device, and that the CD 202 is not intended to be limited to a cordless telephone as shown in Fig. Four. The CD 202 typically comprises an antenna 400, a display 410, keys 420, a speaker 430, an earpiece 440, and an optional push-to-talk (PTT) switch 450. The display 410 and keys 420 are collectively referred to herein. as a user interface. In an alternative embodiment, the CD 202 may use one of the existing keys 420 as a push-to-talk switch when in push-to-talk communications mode instead of using a dedicated push-to-talk switch 450.

The CD 202 may also be equipped to transmit and receive data communications by integration with any data processing device such as a fixed or portable computer system, a position reporting system, or a meter reading system. The CD 202 can be interfaced with such a data generating device using an interface cable, which has one end of the interface cable connected to the data processing device and the other end connected to a communication port (not shown) on the CD 202. . Alternatively, the necessary internal components of the CD can be integrated into the data processing device to form a single unit suitable for transmitting and receiving data and / or voice communications in one integrated package. In either case, CD 202 can be used to transmit data from the data generating device to one or more members of the network, or to one or more non-network members, or a combination of both.

The CD 202 is generally capable of communicating using one or more modes of operation or "service options." However, it should be understood that none of the embodiments of the system and method for providing group communication services is based on a communication device having multiple communication modes. A first service option is used to make standard audio calls from CD 202 to base station 216. The voice service mode is used to make typical point-to-point telephone calls using the given technology of the associated communication system. For example, the voice service option for CD 202 refers to point-to-point audio communications using the IS-95A standard, a well-known CDMA telecommunications standard promulgated by the Telecommunications Industry Association. The voice service option for the CD 208 refers to a standard point-to-point telephone call using the PSTN 222 to connect to another cordless or landline telephone.

A second service option is defined as a data service option, which can furthermore be divided into at least three types of data services; packet data service, asynchronous data service, and synchronous data service. In a CDMA communication system, an asynchronous data service is described by the IS-707.5 standard, while a synchronous data service is described by the IS-707.4 standard. The various data service options are alternatively implemented using techniques applicable to various other types of communication systems, such as GSM systems.

Any type of data service allows CD 202 to communicate with MSC 220 using data protocols, rather than transmitting information using the traditional voice service mode. As previously explained, the MSC 220 contains an IWF that routes data packets between the CD 202 and the CM 218. The CD 202 contains circuitry that accepts information such as audio, video, and data, and converts the information into data packets in accordance with a data network protocol such as the well-known TCP / IP protocol.

When used in voice service mode, a network member uses keys 420 to enter data into CD 202, the data typically comprising an identification number, such as a telephone number, of a second communication device that belongs to a person with whom the user wishes to communicate. Keys 420 are also used in conjunction with display 410 to choose various communication options. For instance,

ES 2 320 731 T3 if a member wishes to enter the packet data service option to join a particular network, keys 420 can be used to select one of several possible networks using a menu of options that can be viewed from screen 410 The CD 202 internally maintains a network list representing the set of known networks that CD 202 can participate in. Alternatively, CD 202 maintains a list of all possible networks, whether CD 202 may participate or not. The list can be updated as needed during interactions with the CM 218. The list maintained by the CD 202 is in function analogous to a phone book feature, which is a list of names and dial numbers that are typically kept in a standard cordless phone. The network list may be integrated with the phone book feature such that the act of selecting a network from the network list instructs the CD 202 to attempt to join the selected network.

Networks can be designated as secure or free networks. Free networks are networks that do not employ over-the-air security guarantees, such as encryption, while secure networks have provisions to provide encryption. Secure networks are described later in this document.

To participate in a specific network, CD 202 initially requests that CM 218 add CD 202 to a list of connected network participants for the desired network. The term "connected" means those users who have registered with the CM 218 and are receiving at least communications that occur on a network. Consequently, CD 202 will initially know or be able to learn the network address of any network in which it wishes to participate. In addition, the CD 202 will initially know or may be configured with the address of a top-level server to which SIP requests can be sent.

In one embodiment, CD 202 is pre-programmed with the address of a known or predetermined high-level SIP server that can provide a current list of networks that CD 202 is authorized to participate in. Alternatively, CD 202 may be pre-programmed with a group list, which defines at least one network address in which CD 202 is a member. The CD 202 can then send a request to the top-level SIP server to update its group list. In another alternative embodiment, CD 202 does not contain preprogrammed SIP addresses or group list information. In this embodiment, a user is provided with a network and high-level SIP server address to interactively enter this information into the CD 202 using keys 420. The user can also enter additional network addresses into a list of groups that already It has been programmed with tickets. This embodiment is analogous to entering personal names and dial numbers in a conventional wireless telephone telephone book.

In one embodiment, CD 202 is also pre-programmed with the IP network address of a primary domain name service (DNS) server, to which CD 202 can send DNS queries. Typically, the address of a DNS server operated by a CDMA mobile phone company will be preprogrammed. CD 202 may also be pre-programmed with the IP network address of an alternate DNS server.

To support SIP authentication, the CD 202 can use security measures such as Pretty Good Privacy (PGP). The CD 202 is pre-programmed with a unique and secret PGP user identity key that you can use to sign SIP transactions when requested by the CM 218. The PGP user identity can also be used as the user address for the CD 202 for SIP transactions. generic, such as INVITE messages.

CD database

Generally, each CD maintains a database to store information regarding group communications. For example, a list of networks that the CD can join is stored in the database, known as a group list. The CD database includes the following fields:

1. Network address

The formal SIP network address of the network that a CD uses to request to join the network as an active participant.

2. Network security warning mark

The free / secure network warning flag distributed by the CM 218 SIP server in its list of available networks or set by the user to indicate that a network is defined to carry secure media traffic.

3. Network traffic encryption key

The traffic encryption key used to encrypt and decrypt all media traffic for secure networks.

Four. Latency reconnect timer

The length of the interval, in seconds, that a CD will wait when in the dormant state between transitioning to the connected state and confirming that a data call is still valid and the connection has not been unilaterally dropped by the base station.

ES 2 320 731 T3

Find and join networks

CD 202 can join or leave networks using Session Initiation Protocol (SIP) defined call signaling. Each CD 202 is provided with a list of network addresses, and one or more top-level SIP server addresses. If the group list is empty, the user can interactively specify the address of an existing network. If no top-level SIP server is defined, the user can interactively specify the address of a top-level SIP server.

Once the top-level SIP server address is known, the CD 202 can request an updated list of networks available to it by making a call using the SIP "INVITE" command to a predefined SIP destination. The top-level SIP server can redirect the request to an internal destination or respond to it directly. The INVITE response to this call includes the current list of networks available for CD 202. CD 202 uses this list to update its internal group list.

After a network has been selected, CD 202 attempts to join the network via the SIP INVITE procedure by specifying the network address as the invitation destination and sending the request to the top-level SIP server. The top-level SIP server attempts to associate the network address with a known destination and, if successful, redirects CD 202 to the destination of the corresponding SIP user agent server associated with the multipoint control unit (MCU) currently assigned to the network, which is a part of the CM 215 responsible for managing network traffic. If no correlation is available, the invitation fails.

Typically, the destination SIP user agent server confirms that CD 202 is authorized to participate in the selected network and responds to the invitation, incorporating a description of the media traffic and signaling parameters to be used to participate in the network. in the content of your answer. CM 218 may also respond with an error if it is unable to confirm CD 202 as a legitimate member of the network or if some other error condition arises, such as a failure that precludes normal network operation. If the invitation is accepted, the CD 202 acknowledges receipt of the response through an "ACK" command from the SIP. Note that other transient response codes indicating call progress may also be received by CD 202 while the invitation is being processed.

The CD 202 is responsible for updating its group list to the set of networks in which it can participate. The user can instruct CD 202 to query CM 218, even if no network address is selected, for the purpose of receiving updates to their group list. If CD 202 determines that it has been added to or removed from a network, it will briefly display an appropriate message to the user (eg, "Added to WELDERS group") and / or possibly cause user interaction. If CD 202 determines that it is not a member of any network, it will inform the user as well. The CD 202 can automatically incorporate new network addresses into its group list but can warn the user before deleting network addresses from the group list.

At any given time, no more than one network can be selected in the group list on the CD. Initially a default network can be selected or the user can select a network from the group list.

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

Active group communications

Fig. 5 is a diagram illustrating the various states in which a CD may reside during operation. Of course, other configurations are possible. It should be understood that the states shown in Fig. 5 are applicable to any CD, with the exception that the latency state, defined below, generally does not apply to CDs that do not communicate using data services.

Upon power-up, a CD enters the idle state 500, which allows at least one service option, such as the voice service option, although the CD 202 could alternatively operate on any desired service option. After joining a network, a CD initializes and opens its Real Time Protocol (RTP) media traffic channel and a separate group media signaling channel to the CM 218 destination addresses provided in a response. of successful invitation. Once these channels have been initialized, group services are activated on a CD, and it enters the group service silent state 502 with the ability to receive media traffic from the network and request permission to send voice traffic.

ES 2 320 731 T3

With group services active, a CD monitors its signaling and media traffic channels for the CM 218. Voice data received on the media channel is decoded and presented using speaker 430 or handset 440, depending on the configuration of current user. A CD can display the identity of the current speaker, identified through real-time media signage. If the identity of the current speaker is not available, a CD can display the name of the current selected network as listed in the group list. A CD can also tabulate media traffic statistics (for example, total time spent talking, listening, and monitoring, estimated packet loss from receiving media traffic) and make these available to the user as a diagnostic via an option. menu. While receiving traffic from the network, a CD transitions to group services listening state 504, returning to silent state 502 when voice traffic stops.

At any time, the user can request permission to speak to the network by pressing the PTT button and having a CD signal the CM 218 (specifically, the network MCU) with a turn control request. The CM 218 responds by granting or denying the request. If a CD only has listening privileges (that is, a CD has a priority level of zero within the selected network), the request will be denied. If denied, a CD can alert the user with an error tone, display a suitable error or explanatory message, or both, and return to the silent state 502. In one embodiment, a CD will insist that the PTT switch 450 be released. and press again before attempting another shift control request. If granted, a CD enters the group services talk state 506, signals the user with a short audible tone, and begins transmitting media traffic to the CM 218 as long as the PTT switch 450 is depressed. At any time, CM 218 can tell DC 202 that it has lost control of the turn. Upon receipt of such a signal, the CD 202 will suspend the transmission of media traffic and alert the user with an error tone until the PTT switch 450 is released, at which point it returns to the silent state 502. If not, a Once the PTT switch 450 is released, the CD 202 indicates to the CM 218 that it has given up the turn and returns to the silent state 502.

A user can switch to a different network by selecting another network from the group list as long as the group services within CD 202 are in silent state 502, listening state 504, or dormant state 508, described below. When a new network is selected, CD 202 will instruct CD 218 to remove it from the current network through SIP call setup mechanisms and then follow the procedures outlined above to join the new network. If the new network join procedure fails, CD 202 is no longer a member of any network and the group services within CD 202 return to the idle state 500.

If CM 218 discovers that CD 202 requesting a particular network's turn is the only registered member of the network in question, it will deny the request for turn control and indicate an indication that CD 202 is the only member of the network. registered network, called lone user error, which the CD 202 will display to the user. Although a network may exist with only one registered member, a network will generally not relay media traffic unless there are at least two registered members.

When any CD has a network's turn, the network is said to be active; if not, it is inactive. If a network is idle for a time that exceeds a predetermined period of time, called the network sleep time, the CM 218 can put the network into dormant mode 208 by individually instructing all registered CDs to release their traffic channels by over-the-air as described by the IS-707.5 standard, or whatever over-the-air data service is used. Sufficient state is maintained to allow a request for shift control or other traffic to bring the network out of dormant mode 508 relatively quickly. Members of the network can ignore the "go dormant" message. The CM 218 does not explicitly or implicitly track the latency status of individual network members.

Typically, the CM 218 will "wake up" a network and bring the network out of dormant mode 508 when a successful turn control request is received during the latency. As soon as the shift control request has been granted, the CM 218 will signal a registered CD requesting a "are you there?" Response. (AYT) over the media signaling channel and will start an internal wake-up timer. In one embodiment, each CD is required to acknowledge receipt from the AYT to the CM 218 if it wishes to remain registered on the network. Optionally, a dormant CD 202 can buffer media traffic from the time the user presses the PTT switch 450 until a traffic channel assigned to CD 202 is (re) connected. The CM 218 can buffer media traffic received from the talking CD 202 until the wake-up timer exceeds a wake-up timeout, at which point it will begin sending media traffic to each registered CD including, in a realization any member that has not yet responded to AYT's request. The CM 218 will periodically relay AYT requests to any registered CDs that do not receive AYT acknowledgment. Once the wake-up timer has exceeded a second longer period of time called the "sleeper" timeout, the CM 218 will unregister any member CDs whose AYT acknowledgment is pending and stop the wake-up timer. The CM 218 ignores duplicate AYT responses.

If a CD attempts to join a network that is currently dormant, CM 218 will process the request normally and then instruct CD 202 to go dormant. The indicated CD can ignore the command to go to dormancy.

ES 2 320 731 T3

Interaction with end-to-end services

CD 202 allows the user to originate and receive conventional PSTN point-to-point calls as well as participate in group communications. Typically, CD 202 will support at least one group communication application and one or more point-to-point applications. Accordingly, one embodiment of the system and method for providing group communication services enables uninterrupted reception and making of point-to-point voice service calls while group services are enabled and activated.

The CD 202 can be used to place a secure point-to-point voice data or point-to-point voice service call at any time, whether group services are active or not, as long as the CD 202 is not simultaneously acting as a talker. . if CD 202 has registered as a member of a network, CD 202 must unregister with the network when a point-to-point call is made. If the selected point-to-point call will be made via a voice service option, the CD 202 will also terminate data services. Once the point-to-point call has been completed , CD 202 can transparently enable data services and re-register as a member of the currently selected network.

CD 202 can be used to receive secure point-to-point or PSTN data / voice calls while group services are enabled, within the limitations imposed by the particular air interface cellular infrastructure. If CD 202 has joined a network, and the selected network is active, CD 202 will appear busy for an incoming PSTN call and the call will be given the appropriate busy treatment by the cellular air interface infrastructure. If the selected network is silent but the network suspend time has not expired, the call will also be treated as normal busy by the cellular air interface infrastructure. However, if the suspend time of the selected network has expired, and the network has been put into dormant mode, and the CD 202 has released its over-the-air resources, the call cannot be treated as busy by party. of the infrastructure and the CD 202 can be paged to initiate the reception of the incoming call.

In one embodiment, while a voice services call is active, CD 202 is unable to receive any network traffic. After a voice services call has been completed, the CD 202 may be required to join or rejoin the network as it may have missed one or more AYT requests.

Whenever CD 202 appears busy to an incoming voice services call, the caller will be redirected based on whether busy treatment has been defined for the called CD (call forwarding, voicemail) over the cellular infrastructure, as expected.

A user can optionally configure CD 202 to disable receiving incoming point-to-point calls while a network is selected and CD 202 is registered as a member.

Communications Manager

Fig. 6 illustrates a functional block diagram of the CM 218. More details of the CM 218 can be found in copending US patent application number 09 / 518,662 entitled "METHOD AND APPARATUS FOR ENABLING GROUP COMMUNICATION SERVICES IN AN EXISTING COMMUNICATION SYSTEM ”, filed March 3, 2000, assigned to the assignee of the system and procedure for providing group communication services, and is incorporated by reference into this document. The CM 218 supports at least three external logical interfaces which, in one embodiment, are all IP-based, and which can all have multiple instances operating simultaneously. A SIP interface is provided by user agent server 600. Real-time media control and signaling are supported by one or more media control units (MCUs) 602. The management functions are supported by a combination of CLI and HTTP servers, shown in Fig. 6 as the management interface 604.

Internally, MCUs 602 may be managed by a control function that assigns MCU 602 to networks and SIP invitations to MCUs. Local memory 606 stores information related to individual network members (referred to herein as the user database) and information related to various networks (referred to herein as the network database). External access to local memory 606 is controlled through administrative interface 604.

No assumption is made as to whether the CM 218 is implemented as a single physical entity, or multiple entities connected by a high speed internal communication path. It may be deemed necessary, for example, to dedicate special purpose hardware to handle real-time media switching loads, or to use a physically separate database engine to host local memory 606. Also, the high-level SIP redirect server 610 and global database 612 may be separate from the media or administrative functions and implemented as a separate entity.

In one embodiment, the CM 218 comprises a SUN workstation, model NETRA T1. However, in an alternative embodiment, the CM 218 could be implemented in any hardware configuration, including discrete components, one or more ASICs, other computer systems, computer architectures, state machines, and the like, and various combinations thereof. . Furthermore, the CM 218 could be implemented in software or firmware, as is apparent to one of ordinary skill in the relevant art.

ES 2 320 731 T3

Both the high-level SIP redirection server 610 and the SIP user agent server 600 associated with the MCUs require access to system-defined network and user information. Specifically, the top-level SIP redirect server 610 can query the global database 612 or it can be given explicit SIP records to redirect incoming INVITE requests to a corresponding appropriate destination (in most cases, the server of user agent 600). Similarly, SIP user agent server 600 requires access to local memory 606 to authenticate users, confirm user access to networks, and define network session descriptions.

Local memory 606 receives user and network information from global database 612 when an MCU is assigned to a network by redirection server 610. After information has been provided to local memory 606, it can be provided to administrative interface 604 , user agent server 600, and / or MCU control 608 as needed.

MCU 608 control monitors the operation of individual MCUs, such as controlling power on and / or off, assigning a network to an MCU 602, and sharing status information between local memory 606 and various CDs and / or administrative interface 604 MCU 602 is typically a digital signal processing device capable of executing a set of program instructions stored in memory, such as ROM.

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

After the transmitting CD has been identified, the MCU control 608 retrieves from the local memory 606 a list of network members belonging to the network associated with the particular MCU 602 (each MCU is assigned to only one network). A destination address is associated with each active network member, ie, network members that are currently registered with MCU 602, in local memory 606. In one embodiment, the destination address is an IP address. The MCU control 608 then creates a duplicate of the original data packet, except that the destination address identified within the data packet is modified to reflect the destination address of the first member of the network. Next, MCU control 608 creates a second duplicate data packet, addressed to the second member of the network. This procedure continues until the original data packet has been duplicated and sent to all active network members identified in local memory 606.

PSTN user interface

As previously discussed, the CD 202 comprises a cordless telephone in one embodiment. However, as many of the system and method embodiments for providing group communication services use IP and extensive IP transport protocols, any IP-capable platform with connectivity to the CM 218 can potentially serve as a CD.

Consequently, dial-up connection users (i.e. a user operating a device that communicates primarily through the PSTn) can connect to the CM 218 through existing IP terminal servers managed by Internet service providers. (ISP). An IP terminal server acts as a bridge between the PSTN and a local area network (LAN) that supports IP. It is made up of a modem bank, which provides a connection point for PSTN modems, a server, and one or more network interfaces. The server is capable of hosting multiple independent PPP sessions, one for each connected modem user. The server also acts as a router, routing IP packets between each of the individual PPP interfaces and any active LAN interfaces. In one embodiment an integrated IP terminal server is used and in another embodiment an external IP terminal server is used. Both types of servers are readily available commercially.

The switched line connection terminal server ideally supports the ability to negotiate CRTP header compression throughout a PPP session. Similarly, the PPP stack used by the dial-up client must also include and attempt to use CRTP. However, due to the additional bandwidth available by high-speed modems, the inability for a line-switched connection-based user to negotiate CRTP header compression may not necessarily force a network to avoid using payload-based specifications. in RTP.

If the terminal server is located on an internal LAN of the cellular service provider, and therefore close, in a network topology sense, to the CM 218 of the service provider, switched line connection users can avoid quality problems that can contribute to high end-to-end latency if the path between the ISP's terminal server and the CM 218 traverses a portion of the Internet.

PSTN-based network participants follow similar SIP registration procedures as outlined for wireless users, join networks in a similar manner, adhere to a similar media signaling protocol, and encapsulate packets within RTP or UDP based on the network session description and according to the payload specifications previously described.

ES 2 320 731 T3

As PSTN-based modems generally do not support a latency concept similar to the one described above, participants in the dial-up connection-based network generally ignore any deactivation messages received from the CM 218.

CM databases

In one embodiment, the CM 218 maintains at least two different databases that capture information that supports network activities: a network database and a user database, both stored in local memory 606 and / or the global database 612. Information supporting activities and administration privileges can be stored in any database, or a third, functionally distinct database.

User database

The user database tracks individual users of the group communication system. The user records contained within the CM database may or may not necessarily be members of networks defined in the CM networks database 218.

Each record in the user database comprises one or more fields to store pertinent data corresponding to each CD. In one embodiment, each record comprises a username field, a user identifier 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 different fields can also be used. Of course, in other embodiments, each record may comprise different information from that described above.

The username field identifies a formal name associated with a particular CD 202, such as "Jane Doe." The user identifier field is a unique code that further identifies the user, such as "17882". The vocoder list field identifies a list of vocoders supported by the CD 202 associated with the user. The list may include speech coders not supported by the group communication system. The dial number field identifies the dial number assigned to the CD 202 assigned to the user. This field is empty, or null, for generic Internet users, that is, for CDs that do not support standard voice services. A user type field indicates whether the user is a cellular user or a generic Internet user. In one embodiment, users who connect to the CM 218 via the switched line connection PSTN are considered generic Internet users. The CD user address field identifies a unique user address for CD 202. A CD known by multiple user addresses will generally have multiple corresponding entries in the user database. The CD PGP public key field stores a PGP public key associated with the user address of the CD 202. Alternatively, other types of keys may be stored in this field.

Network database

The network database defines a set of networks known to the CM 218. The network database also lists the defined members of each network - those users who can request to join and become participants in a network. Each record in a network database comprises one or more fields to store pertinent data corresponding to each network. In one embodiment, each record comprises at least a network identifier field, a network address field, a network owners field, a network security field, an arbitration scheme field, an encoder field voice network, a PTT failsafe field, a sleep time timeout field, a PTX latency response timeout field, a wake-up timeout field, a sleepyhead timeout, an AYT timeout field, a media channels field, and a network membership field. Additional fields may be added, or multiple fields may not be required, depending on the characteristics and capabilities of a particular application. Each field is described as follows.

The network identifier field comprises a unique identification code, which identifies particular networks within the context of the CM 218. The network address field comprises a SIP-compatible network address of the corresponding network. The network owners field comprises a list of users, identified by user identifiers, who have administrative privileges for the corresponding network. The network security status field comprises an indication of whether the corresponding network is free or secure. In an alternative embodiment, this field could identify various levels of security, such as none, classified, and secret. The arbitration scheme field comprises a unique value that identifies an arbitration scheme used to resolve PTT arbitration conflicts between network participants. The network vocoder field comprises a value that identifies a standard vocoder displayed in the advertised network session description. Members of the network that incorporate such a vocoder on CD 202 will have this vocoder listed in their list of supported vocoders. The PTT failsafe field comprises a maximum time that a network participant can transmit media to the network before the CM 218 revokes the talker privilege. The suspend time timeout field comprises a maximum time that the network can remain idle before the CM 218 puts it into the dormant state. The PTX latency response timeout field comprises a maximum time that the CM 218 will wait after determining that a latent network talker privilege can be granted before transmitting a PTX message to a requesting CD. The wake-up time-out field comprises a maximum time that the CM 218 will wait for the network participants to

ES 2 320 731 T3 respond to an AYT "wake up" message before granting a pending PTT request. The sleeper timeout field comprises a maximum time that the CM 218 will wait for a CD to respond to the CM 218 AYT “wake up” message before the Cm 218 removes the unresponsive CD from the participant list. network assets. The AYT timeout field comprises a maximum time that the CM 218 will wait for a CD to respond to an AYT “wake up” message before the CM 218 removes the CD 202 from the list of active network participants. . The media channel list field comprises a list of media channels, including payload specifications, for the network. Each network will generally list at least one media channel that carries voice. Secure networks can list a second data channel. The network membership field comprises a list of defined network members and associated network specific privileges.

As discussed earlier, the network membership field defines a set of users who can request to join the network as participants. Each entry in this field can comprise additional information that corresponds to each member of the network, such as a priority level, and an authorization list. Other information can also be defined for each member. The priority level is generally used by a network PTT arbitration algorithm to resolve PTT conflicts. A priority level can be defined to allow listen-only privileges. The authorization list defines authorization privileges, if any, that a user has for the network. Privileges may include the ability to add, edit, or modify entries in a network share list and the ability to modify other network parameters.

Network management

CM management interface

In one embodiment of the system and method for providing group communication services, the CM 218 includes a separate management interface 604 through which the CM 218 can be administered and real-time status reports obtained regarding the operation of the CM. Other variations are possible. Management interface 604 is comprised of two network ports, a TCP / IP-based Hypertext Transfer Protocol (HTTP) interface that supports administrative access through a conventional Java-enabled web browser, and a line interface TCP / IP-based group communication specific commands (CLI).

Administrative functions are supported through a TCP / IP-based CLI. Before being granted access to the CLI, a potential administrator connecting to the CLI interface of the CM 218 will be authenticated, using well-known techniques.

The CLI is capable of supporting various administrative functions, such as creating a new user record in a user database, deleting an existing user record, and modifying an existing user record. Other functionalities may include the ability to create new networks in the user database, delete existing networks, and modify existing networks. Other additional features may include the ability for an administrator to list all users by username, dial-in number, user identifier, as well as other criteria, the ability to list all networks, by network address and network identifier, in the networking database, the ability for an administrator to display all fields for a specific user record, and the ability for the administrator to display all fields for a specific network identified by the network's network identifier or network address. The CLI may further include the ability for an administrator to view a static status report for a specific network, or an individual network member. This function can also allow the administrator to consult real-time (updated) reports and, in particular, allow the administrator to identify the current list of network participants, the current speaker, the presence or absence of media traffic, and identify any media signaling messages sent or received by the CM 218.

In one embodiment, the CM 218 makes administrative functions available to a generic web browser via an HTTP web server interface with one or more pages formatted using hypertext markup language (HTML) syntax. At least one of the administrative pages can include a reference to an embedded Java applet.

Some administrative functions can be optionally performed by HTTP GET and POST commands issued by the web browser using conventional HTACCESS authorization mechanisms. The administrative functions supported are a subset of those supported by the CM 218 CLI interface.

The HTTP interface can be used to deliver a Java applet to the web browser. The applet can then be based on the CM 218 CLI interface to provide additional administrative functionality to the user through a web browser interface.

The CM 218 manages and is the focus of all administrative functions related to the administration of the network, including the creation and elimination of networks; define new users and delete existing users; add and delete users as members of the network; and adjust various operating parameters across a broad user, network, or CM base.

Upon delivery to a cellular service provider, or others, the CM 218 requires basic administrative configuration before it can be used to support group communication activities. The initial configuration re

ES 2 320 731 T3 dear involves basic system configuration: assigning passwords to operating system level accounts for system administration at the root level and configuring the CM 218 network interfaces for proper operation on a local wireless infrastructure network.

Once the CM 218 is configured, general network management can take place. In one embodiment, the network management functions take place through an HTML interface or other network interface built on top of TCP / IP. Administrators interact with the CM using a conventional World Wide Web (WWW) browser. Administration can take place locally or remotely (anywhere on the Internet, or over a switched line connection). However, in one embodiment, the underlying transport path for administrative access is TCP / IP. Multiple (two or more) simultaneous management connections are allowed.

After connecting to the CM 218 for the purpose of network administration, the administrator will generally authenticate to ensure that only authorized administrative actions are accepted. Different levels of access are allowed; for example, authorized network members can connect directly to the CM 218 administrative interface to modify specific network membership lists, but more generic administrative privileges are reserved for specific administrative accounts. For clarity, administrative actions are separated into those that deal specifically with user definitions and those that define networks. A user definition can include a user name, unique CD cellular system identifier, CD telephone number, and user email address. CM 218 will also internally define a unique user identifier that can be passed to CD 202 and used to uniquely identify the user in signaling messages. A network definition can include a network address, network suspend time, private forwarding timeout, and member list. A network member list is made up of a list of member records, individually containing a user identifier and priority level. A member with the lowest priority level generally has only listening privileges.

CM administrators can monitor the current status of networks for which they have administrative privileges. In particular, administrators can determine the current list of network participants as well as monitor the status of the network (active, inactive, dormant, waking, etc.). As long as the network is active, the administrator can also monitor the identity of the current speaker. Additional statistics and statuses, such as the current session duration, total talk time of an individual user or a network, the last time a member of the particular network had the broadcast privilege, average number of registrants, etc., too they may be available to administrators through administrative interface 604.

The CD 202 can also support the concept of a "private call" - a half-duplex point-to-point call by the caller who presses a push-to-talk button that is accepted without the called party's phone ringing, as occurs. in a traditional full duplex point-to-point call.

Network protocols

The operation of an embodiment of the system and method for providing group communication services can be described and defined at two levels that generally operate independently of each other. The lower level is described here, comprising a physical, link, network, and transport layer. The upper level, comprising group communication and related application-level protocols, is described later in this document.

One embodiment of the system and method for providing group communication services operates over standard Internet and related protocol stacks, such as that provided by the IS-707.5 Packet Data Service Option in a CDMA communication system. Of course, other embodiments could alternatively use a data service applicable to the particular type of communication system being used, such as a GSM communication system. Various embodiments of the system and procedure for providing group communication services can also operate according to V32.bis, V.90 or similar PSTN modem standards, or be used entirely within the public Internet, independent of any segment of the IS- standard. 707.5.

Most communication network traffic can be described as signaling or media traffic. Signaling traffic can also be differentiated into two distinct categories: call setup and control signaling, which is mainly made up of SIP invitation requests and acknowledgments, and media signaling, which mainly comprises real-time turn control requests. and related asynchronous messages. Media traffic comprises real-time point-to-multipoint data or voice broadcasts.

Signaling protocols

Group communication call establishment and call control signaling are performed in accordance with the well-known Session Initiation Protocol (SIP), although any signaling protocol can be used in the alternative. Although SIP can be carried using User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), CD 202 performs all SIP-based signaling functions using UDP in one embodiment and CM 218 expects to receive all SIP signaling requests over UDP.

ES 2 320 731 T3

In one embodiment, the CM 218 implements both a SIP user agent server and a SIP redirect server. To support group communications, CD 202 implements a SIP user agent client. The CM works by listening for incoming SIP connections on an advertised port, in one embodiment, UDP port 5060. When a connection occurs, the SIP server receives and processes requests according to SIP call signaling conventions. The server is capable of processing multiple call signaling connections in parallel.

To conserve network resources, CD 202 can release its UDP connection to the SIP server after it has successfully (or unsuccessfully) joined a network. The UDP connection can then be re-established to send additional SIP call signaling requests (for example, to leave a network or switch to another network).

Because UDP provides unreliable connectionless transport, application-level reliability guarantees are necessary to ensure robust communication. These guarantees are implemented by SIP compliant endpoints, ie, CDs in communication system 200. SIP call signaling UDP flows are encapsulated within a data network protocol, such as IP. No special formatting is required. SIP call signaling IP packets exchanged between a wireless communication-based CD or a line-switched PSTN communication-based CD 208 are encapsulated within PPP. Again, no special formatting is required.

In one embodiment, SIP call signaling PPP frames exchanged between a cellular-based CD 202 and a base station 216 are encapsulated within Radio Link Protocol (RLP), a well-known wireless protocol for transmitting data over the air. . For line-switched PSTN-based CDs, an appropriate modem standard, such as V.32bis or V.90, replaces RLP. In either case, no special handling is required and an error-free physical link is not required.

In one embodiment, group media signaling, as well as voice and data traffic, are transported using UDP / IP datagrams. When CRTP header compression is available, media traffic can be further encapsulated using RTP at the application layer and header compression techniques applied as appropriate to incoming UDP / IP and outgoing 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 on which it tries to listen for group media signaling requests and communicates the port number to CM 219 as part of the SIP invitation it delivers when it tries to join a network.

A network CM media signaling destination address (including UDP port number) is described in the network session description delivered as part of a successful SIP INVITE request response. Unlike SIP signaling addresses, media signaling destination addresses are network specific and can change between instances of CD 202 joining a network.

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

Media traffic (voice)

Voice traffic from CD 202 is encapsulated by grouping one or more data frames representing voice information within an RTP / UDP or UDP payload. In one embodiment, the data frames comprise frames generated by a vocoder within CD 202. The use of RTP with CRTP enabled is recommended to minimize end-to-end media latency and provide interoperability with future IP telephony applications and services. . In either case, CD 202 dynamically selects the UDP port on which it expects to receive media traffic and communicates the port number to CM 218 as part of the SIP invitation it delivers when it attempts to join a network.

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

Typically, media traffic is encapsulated on CD 202 using RTP, which segments each UDP datagram into an RTP header and payload. Voice traffic can optionally be purely encapsulated using UDP, without RTP encapsulation, typically when CRTP header compression is not available or is not supported by a network member. The structure of the UDP payload follows the definition given by a corresponding RTP payload, without the RTP header fields.

ES 2 320 731 T3

The decision to encapsulate media directly in UDP is generally configured by the network administrator and announced by the network session advertisement.

Media (data) traffic

In addition to voice media, networks can also support arbitrary data broadcasts, such as secure network key change, email, data files, etc. If a network supports a data broadcast channel, CM 218 will advertise the media type in the network's SIP session description when CD 202 formally joins the network. Like traditional media broadcasts, generic data broadcasts work over RLP in one embodiment (or a corresponding physical layer) but are considered unreliable transports.

In one embodiment, CD 202 includes the ability to resolve Internet domain names to Internet addresses using Domain Name Service Protocol (DNS), as defined in the RFC 1034 standard. Alternatively, CD 202 works alone. as a DNS client or resolver, as described in the RFC 1035 standard.

For CD 202 to resolve DNS host names, CD 202 is preprogrammed with the IP network address of a DNS server. The DNS address must also be configurable by the CD 202 service provider and optionally by the user.

The CM 218 can optionally be configured to act as a DNS server, as described in the RFC 1035 standard. Although it can respond to dN requests from outside entities using TCP as the transport protocol, the CM 218 also encapsulates DNS messages using UDP.

Cellular multicast channel extension

The various embodiments of the system and method for providing group communication services have been designed to take advantage of the development of a cellular multicast channel, if available. Such a channel generically allows a transmitting station to address multiple listening stations, or CDs, directly, without the need for multiple separate rebroadcasts of the transmitted data.

To take advantage of the efficiencies provided by a cellular multicast channel, the traffic destination and media signaling addresses of a network would be conventional IP multicast channels, and all media traffic and signaling broadcasts originating from the CM could become multicast broadcasts. Signaling broadcasts and media traffic originating from CD, and SIP signaling would likely remain point-to-point communications.

RLP modifications

Radio Link Protocol (RLP) can be modified within CD 202 to minimize latency experienced when link layer loss (RLP frame) occurs. Such modifications are optional and do not explicitly affect the operation of the application layer protocol transport since neither TCP nor UDP take over a trusted network (IP) service or link layer service.

A variety of RLP modification strategies are possible. The RLP can be modified to send multiple negative acknowledgment responses (NAKs) after an initial RLP timeout, thus causing the remote end to transmit multiple copies of the lost RLP frame and improving the chances of a successful RLP recovery. .

The RLP can also be modified to never send a NAK (after the RLP timeout expires) and to allow interrupted RLP frames to force higher levels of the protocol stack to generate errors. Any TCP-based application-level protocol will routinely recover through TCP's error recovery mechanisms.

CRTP header compression

Nominally, in RTP encapsulated media traffic, the RTP header has 12 bytes of supplemental information, the UDP header has 8 bytes of supplemental information, and the IP header has 20 bytes of supplemental information, for a total of 40 bytes of supplemental network and transport protocol information. This extra information can be prohibitive to transport small RTP encapsulated payloads over existing cellular channels and even some line switched PSTN channels.

Various embodiments of the system and method for providing group communication services assume the availability of transparent mechanisms to compress the header fields of IP / UDP / RTP datagrams to reduce bandwidth requirements over the air. A specification for IP / UDP / RTP header compression within PPP (or similar link layer framing protocols) has been accepted as standard within the Internet Engineering Working Group (IETF). This specification describes a procedure, commonly known as CRTP Header Compression, to compress header fields

ES 2 320 731 T3 of IP / UDP / RTP datagrams over point-to-point networks at two bytes (if UDP checksums are not preserved, or four bytes if UDP checksums are preserved). CRTP employs three basic strategies to compress the header fields of IP, UDP, and RTP:

1. Header fields that remain constant for the duration of the RTP session are sent once at the beginning of the session and are never transmitted again.

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

3. Header fields that almost always change in constant increment are differentially encoded using second-order differences. The constant increment is transmitted and stored, and updated only when the field changes by an unexpected increment.

Therefore, CRTP assumes that both ends of the compressed link maintain a shared set of information or context for each RTP session, including the full IP, UP, and RTP headers (including constant fields), first-order differences for fields that typically change in constant increment, and other related information.

Infrastructure support

When operating over cellular CDMA infrastructure, one implementation of the system and procedure to provide group communication services requires the existence of data services, such as the packet data service option outlined in the IS-707.5 standard for the transport of traffic from signage and media. Furthermore, one embodiment of the system and method for providing group communication services makes use of a latent mode to allow point-to-point voice service calls to be received during extended periods of network broadcast inactivity. If the packet data service option of the IS-707.5 standard is not available, another embodiment allows implementation using a service known as Quick Net Connect (QNC) and the IS-707.4 standard.

QNC provides a protocol stack identical to that provided by the IS-707.5 standard, although the QNC infrastructure is unlikely to support CRTP header compression. The CD 202 can be configured to negotiate a packet connection using QNC instead of the IS-707.5 standard, and, if QNC service is available, treat the connection as a packet data service option connection.

Dynamic IP (record)

In one embodiment, CD 202 can detect the fact that its IP network address has to or is going to be changed. If CD 202 is participating in a network when the address change occurs, CD 202 rejoins the network by invoking the SIP INVITE command, as described below.

The IP network address of CD 202 can change for at least two reasons. A roaming CD may change cellular systems or cellular networks, and it may be required to negotiate a new IP network address. Or the CD 202 may experience a service outage or data service option call drop for any reason and, after service is restored, it may be assigned a new IP network address. If CD 202 is participating in a network during a network change and does not rejoin the selected network in a timely manner, CM 218 will eventually expire its membership and remove CD 202 from the list for the selected network. Cd 202 is removed from the active network participant list if it ultimately fails to respond to a series of media signaling AYT request messages, as described below.

IP mobility support

The RFC 2002 standard describes an IETF standards tracking protocol, commonly known as Mobile IP, that enables the transparent routing of IP datagrams to mobile Internet nodes. One embodiment of the system and method for providing group communication services allows for transparent operation over Mobile IP, with little or no modifications to the application or its associated protocol stacks. Like SIP, Mobile IP includes a registration mechanism to locate mobile host systems within the overall network. Unlike SIP, the Mobile IP registration mechanism works at the network layer and is necessarily tied directly to IP-level addressing schemes. SIP registration occurs at the application layer and is defined independently of the addressing details at the network level.

Under Mobile IP, a mobile host system (ie, CD 202) connects to the network via a foreign agent, which assigns CD 202 a "custodian" address. The escrow address is a temporary but legal address that IP datagrams can be directed to from anywhere on the Internet. CD 202 uses the escrow address to contact your local agent and inform them of the current escrow address for CD 202. After confirming the identity of CD 202, the home agent then tunnels packets addressed to the permanent local address of CD 202 (normal Internet routing mechanisms that will deliver the home agent directly or to the home agent's network) to the CD 202 using the CD 202 custody address.

ES 2 320 731 T3

Although, in one embodiment, the system and method for providing group communication services may operate over Mobile IP, Mobile IP can adversely affect the end-to-end latency and perceived voice quality of media traffic and signaling if the CD 202 joins a network using its permanent address and the home agent is located far away, in a network topology sense, from the CM 218 and CD 202. In such a case, the media traffic may have to be routed over the public Internet or other service networks of varying quality, which may not have been required if Mobile IP was not used. To avoid this, in most cases, it is preferable for the CD 202 to access network broadcast services using its custodian address and join the networks when its custodial address changes.

Group communication app

The group communication application is based on two different application-level protocols: Session Initiation Protocol (SIP) and network broadcast media signaling. SIP is used for call signaling and call establishment. Media signaling handles PTT requests, resolves PTT arbitration conflicts, and manages network latency.

SIP call signaling

The session initiation protocol, as defined in the RFC 2543 standard, provides application layer control (signaling) of the group communication system to discover, join and leave networks using a SIP server interface on the CM 218 To join a network, the Cd 202 invites the network, by name, to participate in a call, through the high-level SIP server. To leave a network, CD 202 sends a corresponding "good bye" to the network. A normal anticipated sequence of SIP call signaling messages exchanged between a CD and the CM 218 is shown in Fig. 7.

CD 202 determines the IP address of the top-level SIP server using DNS to resolve the primary and secondary addresses of the provisioned SIP server into Internet network addresses, if necessary. As an optional alternative approach, SIP conventions allow CD 202 to query DNS service records associated with the system domain portion of the network address and contact the SIP server at the returned address (es).

Before attempting to join a network, CD 202 may make a call using the SIP INVITE procedure to request an updated list of available networks. For example, a CD indicated by a mobile identification number, or dialing number, MS6199726921 that has returned a connection over the air using the packet data service option of the IS 707.5 standard and has been assigned an IP address From 192.168.172.25, you want to determine your current list of available networks by querying a top-level SIP server with a DNS address of sip.acme.com. As shown in Fig. 7, at time 1, CD 202 would open a UDP / IP connection to the SIP server port at sip.acme.com and issue a request similar to the following:

INVITE sip: nets@nbs.acme.com SIP / 2.0

Via STP / 2.0 / UDP 192.168.172.25

From: <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 INVITE

Content-Length: 0

The request for an updated list of networks is directed to a special destination, in this case, sip: nets@nbs.acme.com. Where appropriate, the CD 202 may also include additional application-specific headers that identify the network and system from which a cellular communication-based CD is being served. The following are sample headers that contain this information:

X-CDMA-System: 0x7BCF

X-CDMA-Network: 0xE289

CD 202 may also include a SIP Require header to indicate that CD 202 expects the SIP server to understand and support group communication services. The option value distributed with the REQUIRE header can also be used by the CD 202 to inform the CM 218 of a specific version or type of group communication services that the CD 202 expects the CM 218 to support. A header is shown below. shows:

Require: acme.bravo.nbs

ES 2 320 731 T3

As shown in Fig. 7, at time 2, the CM 218's high-level SIP server can redirect the request, using SIP redirection mechanisms, to a specifically defined destination to receive and respond to requests for network information. Upon receiving such redirection, CD 202 will acknowledge the response at time 3, and will forward the INVITE request to the redirected destination, as shown at time 4. Here is a sample SIP redirect response:

SIP / 2.0 302 Moved temporarily

From: <sip: MS61999726921@nbs.acme.com>

To: <sip: nets@nbs.acme.com>

Call-ID: 123@192.168.172.25.acme.com

Contact: sip: nets@nbs.acme.com

CSeq: 1 INVITE

In the example above, CD 202 would have to determine the appropriate SIP point of contact for the redirected address, sip: nbs@nets.acme.com, through DNS mechanisms (as previously discussed). To simplify this procedure for the CD 202, the CM 218 can explicitly specify the redirection destination using its Internet network address.

Once the INVITE requesting a network list is successfully received and accepted by CM 218, CM 218 would deliver an INVITE request response at time 5, similar to the following:

SIP / 2.0 200 OK

From: <sip: MS6199726921@nbs.acme.com>

To: <sip: nets@nbs.acme.com>

Call-ID: 123@192.168.172.25.acme.com

CSeq: 1 INVITE

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 response to the INVITE request would generally include in its content a list of records that define the set of networks with which the CD 202 can later join. The CM 218 requests from its network database the networks that list the requesting CD as a defined member to form the response to the INVITE request.

Networks are identified within the content using an application-defined record format that includes the formal network address of the network. Networks can be listed in any order. In the example, the format of the sample content of the INVITE response is described by the application content type / x-acme-nbsgrouplist. One possible definition of this content is a series of records, one record per line, each of which complies with the syntax:

<record-typ> [<field> ... <field>] where the first character of each record defines the record type and is followed by one or more field values, with the number of expected field values ​​determined implicitly by the type of record. In the example, three group definition records (G) are included, with each record containing a network address as well as an indication of the number and type of media channels defined for each network. Other content definitions are possible.

ES 2 320 731 T3

CM 218 may be unable to respond successfully to CD 202 for various reasons. In such circumstances, the CM 218 will deliver an appropriate SIP status code in place of the INVITE response shown above. CD 202 must be ready to accept and interpret such status codes, taking the appropriate action (such as displaying an error message on the user interface screen of CD 202) in the event of any fatal error. For example, a SIP server that does not recognize or support the qualcomm.bravo.nbs requirement might respond as follows:

SIP / 2.0 420 Bad Extension

Unsupported: acme.bravo.nbs

The CM 218 can also prolong a successful INVITE response with informational status responses that indicate the progress of the records, such as:

SIP / 2.0 100 Trying

The CD 202 is generally capable of accepting and interpreting such informational status codes that prolong successful registrations.

INVITE (join a network)

In one embodiment, CD 202 requests to join a network by issuing a SIP INVITE request to the network manager CM, shown in Fig. 7 at time 7. If CD 202 does not have an open UDP / IP connection to the server SIP will open a new UDP / IP connection to the SIP server port.

For example, CD 202 could try to join the ACME network by issuing a SIP invite similar to the following:

INVITE sip: acme@nbs.qualcomm.com SIP / 2.0

Via SIP / 2.0 / TCP 192.168.172.25

From: <sip: MS6199726921@nbs.qualcomm.com>

To: acme <sip: acme@nbs.qualcomm.com>

Subject: Join

Call-ID: 421b2-314159@192.168.172.25.qualcomm.com

Content-Type: application / sdp

Cseq: 1 INVITE

Content-Length: 128 v = 0 o = -3115132610 3201 INIP4 192.168.172.25 s = acme c = INIP4 192.168.172.25 t = 311532610 0 m = audio 5200 RTP / AVP 12 a = type: nbs

As before, CD 202 must be ready to be redirected by the top-level SIP server and reissue the INVITE request to the redirected destination. The CM 218's top-level SIP server must redirect any incoming INVITE requests as appropriate to the MCU currently associated with the network in question. CD 202 can be redirected more than once.

ES 2 320 731 T3

The INVITE request may include a description of the media sources that will originate with CD 202, assuming the invitation is successful. If included, the description can be included as message content and described using SIP Content-Type and Content-Length field constructs.

In the example above, CD 202 is announcing that it will be the source of a single audio session formatted using the RTP / AVP PureVoice ™ payload profile. The session description is delivered in a format that is compatible with the Session Description Protocol (SDP) defined by the RFC 2327 standard. After defining the SDP version (v), the session description includes a mandatory source description (o); In the example, a session identifier, 3115132610, and a session version, 3201, are chosen randomly so that the combination of the session identifier, the version, and the network type and address, IN IP4, and the address, 192. 168.172.25, forms a globally unique identifier for the session. The CD 202 may use any convenient mechanism to choose the values ​​for the session identifier and the session version. Providing an estimate of the current time is one possible way to define the session identifier.

The connection data (c) is specified by defining the type of network, IN; type of address. IP4; and connection address, 192.168.172.25. The CD 202 uses the IP address with which it will label the media traffic (or the source) as the connection address. The CD 202 uses the name portion of the network address of the network as the session name (s), in this case, acme.

CD 202 specifies the duration (t) of the session by providing its best estimate of the current or start time, 311532610, in Network Time Protocol (NTP) format, and indicates that the session is unlimited, 0.

The media format description (m) defines the type of media, audio; the port of origin, 5200; the transport protocol, RTP / AVP; and the payload format, 12, that the CD 202 intends to use to transmit to the network. The RTP / AVP payload profile assigns a payload type of 12 to represent audio encoded using the PureVoice ™ voice encoder, developed by the system assignee and procedure to provide group communication services.

Finally, the session description uses an attribute type definition (a) to indicate that the CD 202 expects the session to be handled as a group communication. The CM 218 must confirm that the invited To: address is in fact a valid network address before it grants the invitation.

To indicate a successful invitation, and specifically inform CD 202 that it has been added to the participant list for the invited network, CM 218 delivers an INVITE response at time 8 similar to the following:

SIP / 2.0 200 OK

Via SIP / 2.0 / UDP 192.168.172.25

From: <sip: acme@nbs.qualcomm.com>

To: acme <sip: acme@nbs.qualcomm.com>

Call-ID: 421b2-314159@192.168.172.25.qualcomm.com

CSeq: 1 INVITE

Content-Type: application / sdp

Content-Length: 179 v = 0 o = -3115132611274512 IN IP4 192.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 INVITE response refers to the invitation previously received, in one embodiment, by Caller-Id.

ES 2 320 731 T3

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

The session description describes all the target media ports and media. In the example, three media channels are defined for the network. The former supports encoded audio using a type 12 payload as defined in the RTP / AVP media profile (ie, QuALCOMM PureVoice ™). The second defines a generic data channel encoded using a dynamic payload type (in the example, payload type 100) using a format defined by a specific group media profile. Currently, there are two specific group communication media formats: X-NBS-GVRS, which describes audio encoded using the Globalstar Variable Rate Speech (GVRS) voice coder using the RTP payload format, and X-NBS-MELP, which describes audio encoded using the standard MELP vocoder using the RTP payload format.

If a network has been configured to transport media purely within UDP (generally necessary to support infrastructure that does not implement CRTP), the SDP media advertisement fields use a UDP / NBS transport and dynamic payload types for all media. An encoding name of X-NBS-QCELP is used to describe audio encoded using the QUALCOMM PureVoice ™ voice encoder. Similarly, the encoding names X-NBS-GVRS and X-NBS-MELP respectively describe GVRS audio and MELP audio media channels encapsulated directly within UDP.

The audio media formats used in the network session description may conflict with the formats suggested by CD 202 in its initial INVITE request. CD 202 will use the media formats defined by the network session description for all traffic intended to be broadcast to the network.

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

The session description also typically includes an SRC identifier assigned to CD 202 by the MCU for the purpose of identifying media signaling messages transmitted by CD 202 as part of its subsequent participation in the network. The value of this identifier must be unique among all active participants in a given network and therefore must be dynamically generated.

The session description may also include a group communication protocol version announcement indicating the revision level that the network media signaling will comply with. Such an advertisement could be implemented by expanding the value of the type attribute field or by defining a new attribute, eg revision of gc, whose value is the protocol version number.

Acknowledgment of receipt (ACK)

In one embodiment, after receiving a successful INVITE response, CD 202 confirms the invitation by sending a SIP acknowledgment request back to the network MCU's SIP user agent server, shown in Fig. 7 as the Time 9. After the sample exchange shown in Fig. 7, an acknowledgment request similar to the following would be transmitted:

ACK sip: nbs.qualcomm.com; transport = tcp SIP / 2.0

Via SIP / 2.0 / TCP 192.168.172.25

From: <sip: MS6199726921@nbs.qualcomm.com>

To: condor <sip: acme@nbs.qualcomm.com>

Call-ID: 421b2-314159@192.168.172.25.qualcomm.com

CSeq: 1 ACK

After transmitting the acknowledgment request, the CD 202 can close its TCP connection with the SIP server. Before the acknowledgment is transmitted, CD 202 must initialize its signaling ports and media traffic according to the session description delivered in the INVITE response from CM 218.

ES 2 320 731 T3

End of session participation (BYE)

In one embodiment, at any time after CD 202 has transmitted a SIP acknowledgment message in response to a successful INVITE response, CD 202 can formally terminate its participation in the network by sending a BYE SIP message to the agent server. network SIP user number, shown in Fig. 7 at time 10. Before sending the BYE, CD 202 may have to open a TCP connection to CM 218.

In one embodiment, a BYE message transmitted by CD 202 complies with the following form:

BYE sip: acme@nbs.qualcomm.com SIP / 2.0

Via SIP / 2.0 / TCP 192.168.172.25

From: <sip: MS6199726921@nbs.qualcomm.com>

To: condor <sip: acme@nbs.qualcomm.com>

Call-ID: 421b2-314159@192.168.172.25.qualcomm.com

CSeq: 2 BYE

Note that BYE uses the same Call-ID but a new CSeq with respect to the previous exchange of SIP messages.

The CM 218 acknowledges the BYE with a BYE response, shown in Fig. 7 at time 11, and similar to:

SIP / 2.0 200 OK

Via SIP / 2.0 / TCP nbs.qualcomm.com

From: <sip: MS6199726921@nbs.qualcomm.com>

To: condor <sip: acme@nbs.qualcomm.com>

Call-ID: 421b2-314159@192.168.172.25.qualcomm.com

CSeq: 2 BYE

Once the BYE is acknowledged, the CD 202 may close its UDP connection with the CM 218. Before acknowledging the BYE, the CM 218 will remove the CD 202 from the list of active participants on the indicated network.

Choices

In general, CD 202 can use the OPTIONS procedure to query the capabilities of a SIP server. In particular, CD 202 may wish to query an arbitrary SIP destination to determine if the destination provides support for NBS call signaling.

Cancel

CD 202 may wish to cancel a pending INVITE request before receiving the INVITE response and sending the acknowledgment. In such circumstances, the CD 202 may use the CANCEL SIP procedure to politely cancel the call. Both the CM 218 high-level SIP redirection server and the SIP user agent server must support the CANCEL procedure.

For example, CD 202 may use the CANCEL procedure to cancel an INVITE in progress if the user decides to make a voice services call and presses send before the INVITE is complete. In such a circumstance, instead of waiting for the INVITE to complete and immediately sending a BYE, the CD 202 can simply CANCEL the INVITE immediately and proceed to make the requested voice services call.

Group media signage

After CD 202 has successfully negotiated membership in a network using SIP, real-time call control takes place via point-to-point application level media signaling messages exchanged between each CD and the network MCU. The following types of group media signaling messages are defined in accordance with one embodiment.

ES 2 320 731 T3

PTT

A push-to-talk (PTT) request message is sent by CD 202 to CM 218 and indicates a user's desire to broadcast media, typically voice, to the network. Typically, a PTT request message is sent each time the PTT switch 450 on the CD 202 is activated. In addition, a PTT release message is sent over the CD 202 to the CM 218 to indicate a release of the PTT switch. 450.

The PTT message comprises several fields that contain various information used to grant or assign the transmission privilege. In one embodiment, a first field is used to designate whether the PTT message is a request for talker privilege or an assignment of talker privilege. A second field is used to identify which CD has sent the PTT message. A third field is used to provide a unique message identifier to allow subsequent PTT and PTX release messages (defined later) to refer to a specific PTT request. The identifier must be unique within the recording session of a particular CD.

In one embodiment, CD 202 expects to receive at least one PTX response message for each transmitted PTT request. If a PTX response is not received within a predetermined time, the CD 202 assumes that the PTT was lost in transit and retransmits a second PTT message using the same PTT message identifier in the third field. The predetermined time can be for a fixed length of time or it can be dynamically altered, depending on system conditions. For example, the default time could be relatively short (one or two seconds) if the network is not dormant. In this case, the CM 218 should be able to respond relatively quickly to the PTT message. If the network has entered dormant mode, the timeout should be extended to accommodate the additional time required to return to the active state.

In one embodiment, if a PTX response message is not received from the CM 218 within a reasonable number of retransmissions, the CD 202 assumes that the CM 218 can no longer be contacted, goes into the idle state, and indicates an error condition. to user.

PTX

A PTX message is sent by the CM 218 to a first CD 202 to acknowledge and respond to a previous PTT request from the first CD 202, as well as to indicate various arbitration events. The CM 218 uses the PTX message to respond to a PTT message, including both requests and release. The PTX message includes information as to whether the referred PTT request message was granted or denied. When responding to a PTT release message, the PTX message is used to indicate receipt confirmation. The CM 218 can also use the PTX message to deny a previously granted PTT request message (if a higher priority CD issues a PTT request message, the broadcast privilege expires (i.e. expires), or occurs some other event that requires the transmission privilege to be revoked).

In one embodiment, the PTX message comprises several fields used to convey information to a PTT message. A first field is defined that indicates if the PTX message is a synchronous response to a pending PTT request, or if it is an asynchronous message that indicates a priority arbitration error or conflict. And second field refers to a previously received PTT request. A third field indicates whether the PTX message is granting, denying, revoking, or confirming the transmission privilege. A fourth field provides additional information that explains the PTX action, particularly in cases where the PTX message denies, revokes, or cannot fulfill a previous PTT request. This field may indicate that a higher priority talker has been granted broadcast privilege, or that CD 202 is not on the network participant list and therefore is not allowed to submit media signaling requests for network. A fifth field represents the maximum time duration for which the broadcast privilege is valid. The CM 218 starts a timer from when the PTX message is transmitted. In another embodiment, the timer starts when CD 202 begins to send media traffic. The value of this field can be a fixed parameter, or it can be variable, depending on various parameters, such as the amount of network traffic, the number of active network users, and so on.

CD 202 may or may not acknowledge receipt of the PTX message. If the response to the transmitted PTX message is lost, a CD 202 PTT retransmission timer will expire and CD 202 may retransmit your PTT request.

PTA

A PTA message is sent by the CM 218 to each CD currently participating in a network to announce the identity of the source of the pending media traffic. A PTA message is also used to formally announce a release of broadcast privilege. The PTA message comprises a field that indicates whether the PTA message is announcing the grant (or denial) of the transmission privilege. In addition, other indications are possible within this field, such as revoking or confirming the transmission privilege. A second field identifies the particular CD 202 that will originate the media traffic for the network until the next PTA message is sent.

ES 2 320 731 T3

The CD 202, whose PTT turn control request was successful, may or may not receive a PTA message announcing that it has been granted the speaking privilege. The message can arrive before or after it receives the corresponding PTX response, since some data protocols, such as UDP, do not necessarily preserve datagram ordering. Consequently, the requesting CD may choose to ignore any received PTA messages announcing that it has been granted talker privilege and rely solely on the receipt of a response from the PTX grant message to determine if it can begin streaming media to the network. .

In one embodiment, PTA announcement messages are not acknowledged. PTA messages are neither detected nor retransmitted. A CD that does not receive a PTA announcement may be unable to visualize the identity of the speaker from the subsequent speaker. However, in another embodiment using RTP encapsulated media, a source destination field is used that uniquely identifies the sender. A CD can cache the correspondence between previous PTA announcements and media streams and make use of this information to identify RTP encapsulated media streams using the source destination field if a PTA announcement message is not received. corresponding during a particular conversation period.

AYT

The CM 218 will occasionally interrogate an individual CD on a network to confirm that the CD in question can connect using data protocols. The interrogation message is known as an “Are you there?” Message, or AYT. Multiple AYT messages can also be sent to a group of network participants, for example, to alert network participants that a network is no longer in dormant mode.

An AYT may be sent to determine if the CD 202 can still connect via data protocols or if the CM 218 wishes to take the associated cellular traffic channels on the network out of dormancy. An AYT message may comprise a unique message identifier to allow a subsequent IAH response message (defined below) to refer to a specific AYT request message. The unique message identifier can include a timestamp reference to generate latency estimates. Note that AYT messages are not necessarily broadcast to each CD at the same time. The CM 218 may stagger the sending of AYT messages to each participant in the network to avoid receiving a flood of responses to simultaneous IAH messages.

CD 202 may or may not be in dormant mode when sending an AYT message. Generally, CD 202 responds to a received AYT message with an IAH response message. In one embodiment, if an IAH response is not received from CM 218 within a reasonable waiting time, CM 218 transmits a new AYT message with a new unique message identifier. If, after a configurable number of retransmissions, no response to the AYT is received from CD 202, CD 202 is assumed to be unreachable and CM 218 removes it from the current list of network participants. Future media signaling messages from the removed CD will be ignored (or will generate an error response) until CD 202 successfully rejoins the network as described above. In another embodiment, CD 202 does not have to rejoin the network.

IAH

CD 202 acknowledges receipt of an AYT message with a response known as the "I'm here" response, or IAH. In one embodiment, an IAH message comprises an identification field that specifies which previously received AYT message the CD 202 is acknowledging. An IAH message also comprises information that uniquely identifies the CD 202 that sends the IAH message.

CM 218 assumes that CD 202 will acknowledge receipt of any AYT message received with an IAH response message. If the alluded AYT message was sent to confirm that a CD remains connected in a silent state, that is, passively monitoring network media traffic and signaling, the CM 218 notes the time of IAH reception for future reference.

ZZZ

If the CM 218 realizes that there has been no network activity on the network for a predetermined time, or in another embodiment, with individual network members, it will send a "deactivation" message, or ZZZ message, to one or more CDs to encourage them to release an associated airborne resource and enter the dormant state. Each CD can choose to ignore this message, for example when it is currently supporting other packet applications. In one embodiment, a deactivation message comprises an identification code that corresponds to the CM 218 that sends the deactivation message for CDs to differentiate between multiple receptions of the deactivation message.

In one embodiment, CD 202 does not acknowledge receipt of the deactivation message and error recovery is not attempted if the deactivation message is lost. To protect against the loss of a deactivation message, the CM 218 can send multiple copies of the same deactivation message to an individual CD or to an entire network. The CM 218 will ensure that all copies of the same deactivation message are sent within a defined interval, and the CD 202 must wait for a period of time longer than this interval from the moment the first deactivation message is received. deactivation before releasing its link over the air and going to dormancy.

ES 2 320 731 T3

ASK

Occasionally, CD 202 will send a message to CM 218 to confirm connectivity to CM 218 as well as allow CD 202 to determine if CD 202 remains on the network participant list. This message is known as an "ASK" message. The CD 202 may wish to confirm its participation after an outage or other period in which it may have temporarily lost connectivity with the CM 218. In one embodiment, the ASK message comprises a unique message identifier to allow the subsequent FYI response message (described below) to refer to a specific ASK request message. The SK message further comprises an identification code that uniquely identifies the particular CD 202 that sends the ASK message to the CM 218.

CD 202 assumes that CM 218 will respond to a received ASK message with an FYI response message. If an FYI response is not received within a reasonable wait time, CD 202 transmits a new ASK message with a new unique message identifier. If, after a configurable number of retransmissions, no response to the ASK is received from CM 218, CM 218 is assumed to be unreachable and CD 202 goes into the idle state.

FYI

In response to an ASK message from CD 202, CM 218 sends a message to CD 202 to acknowledge receipt of a previously sent ASK message or the ASK message is sent by CM 218 to inform CD 202 of an exceptional condition. This message is known as the "FYI" message. In one embodiment, the FYI message comprises a field that defines whether the FYI message is a response to a pending ASK request, or whether it is a message indicating an exceptional condition. The FYI further comprises a field that indicates whether the FYI message is confirming participation in the network, informing CD 202 that it has been administratively deleted from the list of network members, or performing some other predefined function. Furthermore, the FYI message comprises a status field that provides additional information explaining the FYI action, particularly in cases where the FYI message indicates that the CD 202 is not a participant or member of the network. The FYI message may further comprise an identification field that refers to a previously received ASK message from which the CD 202 is acknowledging.

In one embodiment, CD 202 does not acknowledge the responses to the FYI message. If a response to the FYI message is lost, the CD 202 will send a new ASK message request after a predetermined period of time has elapsed since the previous ASK message was sent.

Media signaling message stream

FIG. 8 depicts a sequence of group media signaling messages exchanged between a single CD 202 and a network management MCU. The messages are transmitted in the order shown.

At time 1, an active CD 202 sends a PTT request to CM 218, indicating a user's desire to broadcast media to the network by issuing a PTT message request. In response to the PTT request, at time 2, the CM 218 responds with a PTX message response to the requesting CD 202 which may grant or deny the request. If the request is granted, at time 3 a PTA announcement message is sent to network participants. In addition, a second PTX message response may then be sent if the user continues to broadcast beyond the network PTT timeout or if a higher priority user issues a PTT request while CD 202 is broadcasting.

The CD 202 normally broadcasts media traffic until the user releases the PTT switch 450, at which point it indicates the end of the talk period by broadcasting a PTT release message to the CM 218, shown in Fig. 9 at the time. 4. The CM 218 responds with a confirmation message from PTX at time 5 and at time 6 broadcasts an announcement expressing the end of the talk period to network participants.

Latency

During periods of prolonged network inactivity, one embodiment of the system and method for providing group communication services allows a data service call to be made in the dormant state. The CM 218 facilitates transitions to and out of latency by independently managing a similar latency concept for each network.

The CM 218 maintains a first timer, called the inactivity timer 614, to measure a network suspend time, defined as a period of time in which no member of a network is transmitting information to the other members of the network. When idle timer 614 reaches a configurable predetermined value, it triggers CM 218 to put a network into a dormant state by broadcasting a media disabled signaling message to network participants. In another embodiment, an individual idle timer 614 is maintained for each member of a network, and after a configurable predetermined period of time, the idle timer triggers the CM 218 to put each member into the dormant state, one by one, sending a deactivation message to members as their individual inactivity timers expire.

ES 2 320 731 T3

Upon receipt of the deactivation message, an active CD can release its traffic channel and enter the dormant state, according to the particular data transmission protocol in use, such as the IS-707.5 standard in a CDMA communication system. Alternatively, the CD can ignore the deactivation message and remain in a connected state. Network participants that are not operating on a data channel capable of clearing the channel, such as dial-up PSTN users, should ignore media-off signaling messages.

In one embodiment, the idle timer 614 is reset when a PTX message is transmitted and remains zero until the transmit privilege expires or the CD 202 releases the transmit privilege. Once the transmit privilege is released, the inactivity timer 614 advances until the next PTX message is transmitted.

Reactivation time

If a participating CD enters the dormant state, it will generally remain dormant until data addressed to CD 202 reaches the cellular infrastructure for wireless transmission to CD 202, or CD 202 generates data to be sent. The first case can be triggered by traffic sent to CD 202 by CM 218. The second case can be triggered by the user pressing the PTT switch 450 to request permission to broadcast to the network. Other activations not related to group communications are also possible.

The network itself will remain dormant until one or more members activate the transmission of a PTT request. If the CM 218 determines that it can grant the PTT request message (i.e., the PTX message) (including performing any arbitration necessary to handle multiple requests) it will send an AYT request to each listed network participant to trigger a transition out of latency. For any specific CD, activation may or may not be necessary (ie, not necessary for a requesting CD), but, in one embodiment, each CD responds to AYT as described above.

In one embodiment, when a network is coming out of dormancy, the CM 218 will refrain from sending an initial PTX message until a second configurable timer, called the PTX 616 latency response timer, expires. After this timer expires, CM 218 will send a PTS grant message as usual. However, the CM 218 will refrain from sending media to the network until a third timer, called the network wake-up timer 618, expires. Any media received from a transmitting CD during this time will be stored in a buffer 622 within the CM 218. In one embodiment, both timers are reset when CM 218 determines that the transmit privilege can be granted. In another embodiment, the wake-up timer 618 is reset when the PTX grant is transmitted. In yet another embodiment, the wake-up timer 618 is reset when media is received by the CM 218 after the PTX grant has been transmitted. The value of the wake-up timer 618 is generally greater than the value of the PTX latency response timer 616. After wake-up timer 618 has expired, Cm 218 begins sending media and media signaling from buffer 622, if any media has been received during the wake-up time period. Both timers are generally configurable at the network level.

In one embodiment, rather than relying solely on wake-up timer 618 to determine when to start transmitting media stored in buffer 622, a configurable threshold number of responses to AYT messages is used to determine when enough members of the network are present. network to begin streaming media traffic from buffer 622. For example, in a network that has 10 active (registered) members, the threshold number of responses can be equal to 7, which means that as soon as 7 IAH responses are received to the 9 AYT messages (an AYT is not sent to the member requesting broadcast privilege), any media stored within buffer 622 will be broadcast to all 7 members.

If the CM 218 determines that it cannot grant a PTT request while the network is dormant, it indicates so to the requesting CD accordingly and the network remains dormant.

Sleepers

A CD that has entered the dormant state may require a system change, change service options, or experience some other service disorder that causes it to not receive and respond to an AYT message. The CM 218 maintains a fourth timer, known as the "sleeper" timer 620, which is also reset with the PTX wake-up and latency response timers. This sleeper timer is generally configurable at the network level as well. After the sleeper timer 620 expires, a CD whose IAH response to the AYT wake-up message has not been received is removed from the list of active network participants by the CM 218. In one embodiment, any of such deleted CDs are re-registered with the SIP server of the CM 218 to become a network participant again.

ES 2 320 731 T3

Voice Buffering

Due to the delays associated with moving a CD out of the dormant state to the connected state, the CD 202 and / or the CM 218 can perform voice buffering to attenuate the transition delay perceived by the user.

Typically, a user interface of the CD 202 will indicate to the user, by visual or audible mechanisms, two milestones in the processing of a PTT request. First, the CD 202 indicates that it has detected a press of the PTT key. The CD 202 then indicates that it has received a PTX message response from CM 218. If the PTX message response grants permission to broadcast media, the user interface of CD 202 provides an indication that the user can begin speaking to the network. . If not, the user interface of CD 202 indicates that the user has been denied permission to speak to the network. When the network is not dormant, the latency between the transmission of the PTT request message and the receipt of the corresponding PTX response message is small, and the user will get used to being granted permission to speak soon after the button is pressed. PTT button.

However, when the network is dormant, a significant delay can separate the transmission of the PTT request and the reception of the corresponding PTX, due to the fact that the CD 202 may have cleared its traffic channel and will experience a delay when re-establishing the data services (for example, restoration of over-the-air resources). It also adds to the delay that the other latent network members must reestablish the traffic channels after the CM 218 receives a PTT request. Accordingly, to allow the user to start speaking with minimal delay after sending a PTT request, a simulated transmission privilege grant is generated by CD 202, using well-known techniques, and provided to the user, generally by audible means. The simulated broadcast privilege is similar to a real broadcast privilege grant, in that the user generally cannot distinguish between the two. The simulated broadcast grant allows the user to start speaking almost immediately after a PTT request is generated. The CD 202 is capable of buffering the user's voice in an internal media buffer until an actual transmission privilege grant is received, or until the available space in the internal memory is consumed.

If the response to the PTX message arrives granting talker privileges, the CD 202 can begin transmitting the buffered voice and the operation proceeds normally, although with a slightly longer end-to-end latency between network users during the time. current conversation period.

If the response to a PTX message arrives denying the PTT request, the CD 202 will indicate to the user that permission to speak to the network has been denied. At this time, any voice information stored in the internal media buffer can be erased.

If talker privilege is granted, but the PTX message does not arrive before all available internal memory space is consumed, the CD 202 can simulate a PTX denial and instruct the user to stop speaking. If the CD 202 has failed to restore service, it may also have to take other error action at this point and inform the user accordingly. Alternatively, if at this time a data services connection has been re-established, in this situation CD 202 may begin transmitting voice media to CM 218 without prior receipt of a PTX message.

While waiting for the wake-up timer to expire, the CM 218 may be able to buffer any media received over the media channels of a network from a CD 202 to which a PTX grant of the transmit privilege has been sent. The received media is stored in buffer 622 within CM 218. Once the wake-up timer expires, the CM 218 broadcasts a PTA advertisement to the network, and begins broadcasting the media stored in the buffer 622. If the buffer 622 of the CM 218 is consumed before the timer expires Upon wake-up, the CM 218 transmits a PTX denial to the requesting CD. Media stored in buffer 622 can be transmitted to the network after the wake-up timer has expired. Once the wake-up timer has expired, network operation continues normally.

During the transmission of any buffered media from buffer 622, the CM 218 will treat the network as active, even though the speaking CD has released the talker privilege. Accordingly, the CM 218 generally will not allow a CD to interrupt the transmission of buffered media unless the interrupting CD has higher priority than the source of the buffered media.

The size of the internal media buffer on the CD 202 can be chosen based on the maximum expected time to go into the connected state from the idle state. Similarly, the size of the buffer 622 in the CM 218 should be chosen based on the (maximum) value of the network wake-up timer specified in the network database of the CM 218.

ES 2 320 731 T3

Interaction with point-to-point calls

While a CD has entered the dormant state, the CD 202 may receive point-to-point voice service calls via a choice of voice or other data services, but remains a participant in one or more dormant networks. After the end of the call for point-to-point voice services or other data services, the CD 202 will generally return to the dormant state.

However, if the network goes out of dormant mode while a CD has chosen to receive a point-to-point voice services option call or another data services call, the CD 202 will likely miss an AYT "wake up" message request and consequently it will be removed from the list of active network participants. In such cases, CD 202 may determine its participant status by sending CM 218 an ASK request after terminating the point-to-point call.

In general, once a CD has been removed from the list of active participants on a network, it is required to re-register with the CM 218's SIP server to participate in the network again.

Under normal circumstances, a CD that has negotiated itself in the dormant state can expect a base station to maintain the state associated with the dormant data call for up to 24 hours before dropping the call. However, when base station resources are scarce, some base stations are allowed to drop the call after only 10 minutes of latency - and to do so without explicitly informing CD 202. Such behavior on the part of the base station can directly result in the user inadvertently missing significant or important portions of a network's media traffic, as the CD 202 will remain dormant until he (or the user) takes action. , such as pressing the PTT switch 450. Consequently, in such situations, the CD 202 will only discover that the data call was interrupted after it attempts to take the call out of latency. As a result, CD 202 cannot assume that a base station will reconnect a data call in the dormant state when network activity resumes if the data call has been dormant for longer than the maximum allowed latency, in the present example, 10 minutes.

In most cases, CD 202 cannot prevent the base station from interrupting a latent data call. However, CD 202 can confirm that a latent call has not been interrupted by periodically switching to the connected state, and forcing some over-the-air data activity to occur. Using this procedure, the CD 202 can quickly learn if and when a call was interrupted 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 response. Alternatively, CD 202 may transmit an ASK media signaling request to CM 218 and wait for the expected FYI response. In either case, if the transition to the connected state is successful, the CD 202 has confirmed that the call is still valid and can return to the dormant state. The second procedure also allows CD 202 to confirm that CM 218 still considers it a member of the selected network.

Performing this check allows CD 202 to ensure that it can detect when and if a latent data call is interrupted by the base station within a reasonable time after the interruption occurs. Since the base station will generally not interrupt a data call that has been dormant for a period of less than 10 minutes, the CD 202 will generally not perform this check until at least 10 minutes have expired since the CD 202 last passed the call. latency. The time to send such a check can be a predetermined fixed value, or it can be configured by a user via the user interface.

Latency signaling

FIG. 9 depicts a sequence of group media signaling messages exchanged between a single CD 202 and the network management MCU to illustrate latency. The messages are transmitted in the order shown.

After the network has been idle long enough for the configurable network suspend time to expire, the CM 218 issues a deactivation request message to the network participants, as shown in step 1. In In response, each CD can release its over-the-air resources and enter dormant mode, freeing up its air interface resources. Generally, this means that MSC 118 and base station (s) 216 suspend the communication channel associated with a latent CD, while maintaining various settings to allow a relatively fast connection to the communication channel. Note that, in one embodiment, the network participants do not respond to the deactivation request message.

A successful PTT request by a CD will bring the network out of dormant mode, shown in Fig. 9 as time 2 (it should be understood that other events will bring the network out of dormancy. For example, a network administrator may have to contact one or more members of the network by sending a message to the CM 218 for transmission to the one or more intended members of the network The CM 218 may provide a separate procedure to bring the network out of latency. For example, if no PTT requests are received after a significant period of time has elapsed, the CM 218 can autonomously send an AYT message to network participants to see which CDs are still responding to the messages. Other possibilities of pulling a network out of latency are also possible).

ES 2 320 731 T3

Before granting the PTT request with a PTX message at time 5, the CM 218 will send an AYT message request to the other members of the requesting CD's network (time 3), forcing each previously participating CD to exit the latency if over-the-air resources were released in response to the deactivation message, and to confirm that CDs can still be contacted via data protocols. At time 5, after a configurable period of time, defined herein as the PTX latency response time, the CM 218 transmits a PTX message, granting the transmitting privilege to the requesting CD. The PTX latency response time offers CDs an opportunity to re-establish a communication channel and send an IAH message (time 4), alerting the CM 218 that they can still be contacted. This allows CDs to receive communications from the requesting PTT once the PTX grant has been issued.

Once the PTX grant has been received by the requesting CD, it can start transmitting media to CM 218. CM 218 can refrain from sending media to other network members until wake-up timer 618 expires. This is done CM 218 stored the media in a buffer 622 within CM 218, or in an internal media buffer within CD 202. The wake-up timer value is generally greater than the PTX latency response timer value. After wake-up timer 618 has expired, CM 218 begins sending media and media signaling from buffer 622, or internal media buffer, if information has been stored during the wake-up time period. If no information was transmitted during this time, any media received from the CD that has the transmission privilege is sent directly to the other members of the network.

Ideally, the PTX latency response timer is reset so that a quick response can be made in response to the PTT request. The wake-up timer allows the CDs time to reestablish a communication channel while the requesting PTT is transmitting media to the CM 218. After the wake-up timer expires, the CM 218 announces the talker by broadcasting a PTA message at time 6 to the network participants and any media stored within the buffer can be sent to the other members of the network. If no buffering has occurred prior to the expiration of the wake-up timer, the media is sent to the other members of the network as received by the CM 218 from the talker.

Note that the CM 218 may receive responses to IAH messages for an extended interval after the network is brought out of dormancy mode and that the CM 218 may not wait for all network participants to respond before granting the pending PTT request. . The last responders whose IAH response arrives after the PTX message response is transmitted will remain on the list as network participants, but may not receive all initial media traffic and signaling. Any CD that does not respond to the AYT request after a configurable period of time is assumed to be no longer reachable and is removed from the list of active network participants.

PTT arbitration signaling

Fig. 10 depicts a sequence of group media signaling messages demonstrating a higher priority CD interrupting a lower priority CD having talker privilege.

At time 1, a lower priority CD submits a PTT message request to CM 218 that is granted by CM 218 at time 2. CM 218 announces that CD 202 has talker privilege by broadcasting a PTA message to the members of the network at the moment 3.

While the lower priority CD is transmitting media, a second CD attempts to interrupt by sending CM 218 a PTT message request at time 4 for the same network. The CM 218 determines that the second CD has higher priority than the speaking CD and therefore revokes the speaking privilege of the speaking CD by sending it a PTX revocation message at time 5. The CM 218 then grants the PTT request to the highest priority CD with a normal PTX message response at time 6 and announces that the highest priority CD has talker privilege by sending a PTA message to the network members. at time 7.

If the CM 218 determines that the interrupting CD has no higher priority than the first CD, the CM 218 rejects the PTT request with a PTX message response and continues to distribute media from the speaking CD to network participants.

Although the priority assigned to a particular CD is typically a fixed value defined in a database maintained by the CM 218, the CM 218 may use other arbitration algorithms that do not always necessarily grant the speaker privilege to the highest priority requesting participant. , as represented here. The PTT arbitration algorithm used to arbitrate conflicts can be individually configured at the network level.

CD user addressing

Both SIP call signaling and PGP public key encryption require the existence of a unique user identifier or similar identifier to uniquely identify CD 202. The CM 218 user database defines an internal user identifier (which can be sent to and used by CD 202 in media signaling requests), but this user identifier may not necessarily be appropriate as an address.

ES 2 320 731 T3 single CD user tion. The user identifier address of the CD 202 must also not contain any secrets or private data whose public disclosure could compromise existing cellular infrastructure authentication mechanisms.

As long as the user address of CD 202 satisfies these basic restrictions, many reasonable definitions are acceptable. Assuming that each CD is also assigned a unique dial number, a possible definition could be based on the syntax

MS <DN> @nbs. <Domain-service provider>

where <DN> indicates the dialing number of the CD 202 and <service provider-domain> is the fully qualified domain name associated with the IP network of a service provider. Using this definition,

MS6199726921@nbs.qualcomm.com could be assigned to the user address for a CD with dial number 619-972-6921. Note that this form also allows a CD to be assigned multiple unique user addresses, at the service provider level.

A more general CD user address might take the form <username> @ <domain>

where <username> is a unique user-definable string within a specific <domain> and <domain> is an arbitrary Internet DNS domain. For example, alice.smith@users.wirelessknowledge.com could be the user address for CD 202 of a user, Alice Smith.

The CD 202 user address is used in the FROM headers in SIP registration and invitation, and can be used to form other parts of the required SIP syntax. The user address can also be used as input to the generation of a private PGP key used to authenticate SIP requests.

The user interface of CD 202 may allow the user to view and / or modify the user address.

CD authentication

To guard against certain denial of service attacks and prevent impersonating the CD, the CM 218 will optionally require that the CD 202 authenticate itself before registering or joining a network. Authorization can be done at the application level, independent of other authorization schemes that may exist in the network or cellular infrastructure level. In one embodiment, CD authorization is also implemented, and operates independently of concepts and data structures that support encrypted (secure) networks.

In particular, CM 218 may require CD 202 to include an OK header with SIP requests. The AUTHORIZATION header allows a SIP message to be signed by CD 202 using PGP public key cryptography signatures.

Public key cryptography generates a public and private key from a private secret known only to the encryptor, in this case CD 202. The private key, in combination with the secret, is required to sign a message, but can use the public key alone to verify the signature of a signed message. Therefore, to support SIP authorization, each CD can be supplied with a private secret and a private key, which are normally never shared. It is generally required that each CM 218 that a CD may have to authorize itself to know the public key of CD 202. Since the public key is not secret, it can be stored as part of the user database maintained by the CM 218. , or it can be accessed through generic public key servers on the Internet.

The CM 218 may require CD authorization at the server, network, or user level. At the server level, the CM 218 will require CDs connecting to the CM 218's SIP server to provide authorization credentials, rejecting requests that are not authorized. When server-level authorization is enabled, only CDs whose identities (ie, a public key on the CD) are previously known to the CM 218 can effectively use the server. Server-level authorization can protect the CM 218's SIP server from many relatively easy denial-of-service attacks.

ES 2 320 731 T3

The CM 218 can protect one or more networks that it manages by authorization, but leave other networks unprotected. If a CD tries to INVITE itself to a secured network, the CM 218 SIP server will generally reject the request unless CD 202 can be authorized by CM 218.

Finally, the CM 218 can use authorization to make sure that a CD (or any user agent client in general) does not attempt to impersonate another CD and thereby deny service to legitimate network participants or passively monitor data. media channels on a network. If the CM 218 requires a specific CD to be authorized, the CM 218 will generally not accept SIP requests from a connecting client like CD 202 unless the client's SIP requests include additional authentication, such as a PGP signature that can be verified. by the CM 218. Authentication can be configured at the user level. In this case, the CM 218 may require certain users to be authenticated before joining a network while allowing other users to join without being authenticated.

The PGP private key can be administratively supplied within or created by CD 202, once the user address of CD 202 has been defined. The private key does not have to be stored externally, but the associated public key can be loaded 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 system and method for providing group communication services is deployed as an isolated service, with a CM 218 operating completely independently within a specific geographic region or service area. However, it should be understood that the at least one embodiment of the system and method for providing group communication services is also capable of extending group communication services beyond the local geographic area. This is accomplished by deploying CMs in multiple communication networks, including GSM, TDMA and CDMA cellular networks, in satellite communication systems, such as Globalstar ™ and Iridium ™, and corporate intranets using local area networks or wide area networks. .

Communication between CMs of different systems takes place using SIP server redirects, exchange of user database and network database records, and additional messages between CMs to facilitate an integrated NBS service.

In an integrated group communication service, it may be preferable to allow any CM to take ownership of a network, and therefore not to tie the operation of a network tightly to a specific CM 218 or MCU 602. Instead, the choice of CM could be determined dynamically, based on proximity to the majority of network participants (determined using available position location techniques), the quality of service available in an inter-system network of the service provider. , and other factors. Likewise, any SIP redirect server on the CM must be able to redirect any CDs to the appropriate SIP user agent server on the MCU, and / or, if necessary, send the CDs to another SIP redirect server.

In an integrated system, the network address of a network has meaning throughout the group communication system. As a result, one or more high-level SIP servers are responsible for redirecting INVITE requests and distributing network participants to MCUs. These high-end SIP servers must share a common network and user database, providing identical functionality and redirection decisions at different network meeting points. As a result, CD-originated invitation redirection provides an important and critical layer of abstraction for multiple CM installations to be integrated into a single, homogeneous group communication service.

An integrated group communication system is shown in Fig. 11. In this example, the CM 1100 supports a terrestrial cellular communication network and the CM 1101 supports a satellite communication network. In an integrated group communication service, the system scales by duplicating the functionality provided by the MCU controller 612, its associated set of MCUs 602, known as a MCU pool 1104, and the associated SIP user agent server 600 . A single database 1106 and communication interface 1108 are shared by multiple CMs in the system. Communication between functional entities is not shown.

The procedure by which a CD joins a network in such an embedded system is similar to that used in a system comprising a single CM installation. The CD 202 initially sends SIP requests to the high-level (now global) SIP redirect server 1110. The SIP redirect server 1110 redirects, via signaling mechanisms such as SIP, the requesting CD to the appropriate destination. In the case of an INVITE request to join a network, the destination is the SIP user agent server 600 associated with the MCU with current responsibility for the network in question. In the case of an INVITE requesting a current list of available networks from CD 202, the destination can generally be any user agent capable of responding to the request.

Separately, the redirect server 1110 can exchange additional messages with the cluster of MCUs 1104 through inter-application messaging using known implementation-specific protocols and / or messaging conventions.

ES 2 320 731 T3

As in the non-integrated case, a special commissioning action is required to ensure that the redirection server 1110 can determine a destination for the INVITE requests it receives. One possible implementation would require SIP registrations to exist on redirect server 1110. It is also possible to require the redirect server 1110 to query the global database 1106 and attempt to associate each invitation request with a network definition contained therein.

Business security

In one embodiment, encrypted group communications are possible as an optional feature. At the option of network users, voice and data transmitted over a particular network can be encrypted on the transmitting CD, and decrypted by all other CDs on the network. Encryption is end-to-end, that is, from a first CD to a second CD. Communications from CDs are generally encrypted by a commercial encryption algorithm that is built into the CD. In one embodiment, the choice of whether a CD treats a network as encrypted or unencrypted is at the discretion of the users of the network - normally, no involvement is required from the CM 218.

Users can select whether they would prefer communications to be encrypted on a network-by-network basis. In one embodiment, a user is given the ability to enter an encryption key for a network using the user interface. The user will thus be able to establish encrypted communications with other users on the network who have also selected the encryption option for that network and who are also using the same encryption key.

Generally, the user can enable or disable encryption of network traffic at any time.

In one embodiment, media traffic is symmetrically encrypted using a symmetric key, otherwise known as a traffic encryption key, or TEK, that is shared by other users on the network. Generally, there is no key agreement algorithm, for example the well known Diffie-Hellman algorithm, for network users. Network traffic encryption keys are generated offline by a network user or network administrator and then securely distributed to network participants who manually enter the keys on their respective phones. This key is used for all media traffic on a particular network, until new keys are generated and distributed to network users to replace the previous network TEK.

Encryption selection

As explained above, CD 202 is notified when it becomes a member of a particular network via messages received from CM 218. The network administrator for a specific network may put an informational flag indicating that the network traffic it must be encrypted. This indication is informational only and does not authoritatively indicate that communications over the network are actually encrypted.

The user interface of the CD 202 will allow a user to designate any network as an encrypted network, and will allow the user to enter the network TEK, regardless of whether an encrypted informational mark for the network has been received from the CM 218.

CDs can enforce minimum and maximum key lengths. The CDs may provide means for a key checksum to be entered in conjunction with the key, and if provided, to check the checksum against the entered key. If the checksum is not entered, the phone calculates the checksum and makes it available for display to the user. CDs will generally not display the key on the phone screen after the initial key entry.

Once a key has been successfully entered for a given network, media transmissions over this network will be encrypted using this key, and traffic received by this network will be decrypted using the key. The encrypted traffic will include additional headers that allow the phone to synchronize the encryption / decryption procedure, to allow subsequent synchronization (synchronization with a transmission already in progress), and to confirm that the sender and receiver are using identical traffic encryption keys. If the CD receives encrypted traffic (detected by the presence of the encryption headers) by a network that it has not designated as encrypted, the CD will indicate to the user that it is receiving encrypted traffic, and will not generate traffic, for example, it will mute the audio, or it will suppress the data output. Likewise, if the CD receives media traffic that is not encrypted by a network for which it is configured to encrypt, or if the traffic is not correctly decrypted (for example, if the keys are incompatible), the phone will alert the user and silence the traffic. .

Key generation and distribution

The key for an encrypted network is generally a random binary number. In general, this key will be generated by a part of a network, or an administrator for that network, and will be distributed securely to the network participants. As the key distribution policy is currently left to network users and is external to the CM 218, it is a potential source of network security compromise. A preferred method of key distribution is through secure means, such as through PGP encrypted email to network participants. Other procedures are also possible - by phone call or face-to-face meeting, or by automatic distribution, making use of a PGP secret key that is generally embedded in each CD for SIP authentication.

ES 2 320 731 T3

The entity responsible for generating a key for a secure network must select an arbitrary random number of sufficient length to ensure the necessary level of security. This key can then be converted to a decimal number, containing digits in the range 0 to 9, for user input on the CD 202. The CD 202 then converts the decimal number to a binary number, and uses the binary number as the encryption key. To enter the equivalent of a 112-bit key, for example, the user would have to enter a 34-digit decimal number. The CD is generally capable of detecting a "bad" key, such as a key that comprises all zeros, all ones, or alternating ones and zeros.

In one embodiment, encrypted networks will use "counter mode" encryption. This involves electronic codebook (ECB) encryption of a counter known as the state variable, or state vector (SV), and applying the logical exclusive OR operation to the output with a block of plaintext bits. The value of the counter is incremented and the procedure is repeated for each block of plain text. The encryption algorithm used in one embodiment is Triple-DES with two keys (E mode₁D₂AND₁), used in counter mode. The width of the codebook is 64 bits. Other encryption algorithms are also possible.

In one embodiment, the length of the encryption key is set at 112 bits. If a user enters insufficient decimal digits to produce a 112-bit binary key, a fixed pattern is attached to the user's input to produce a 112-bit binary number. In one embodiment, the 56 least significant bits will be used as the first DES encryption key (E₁). The 56 most significant bits will be used as the second DES key (D₂). Of course, other variations are possible.

The organization of the state vector (SV) is shown in Fig. 12. In one embodiment, the state vector is made up of the following fields:

• 16-bit sender identifier field 1200;

This field is used to help ensure the uniqueness of the cryptographic SV among users.

For the group communication service, the sender identifier must be a unique number for all users of a particular TEK (for example, unique for an encrypted network). The sender identifier will be chosen randomly by CD 202 when a key is entered into the telephone for a particular network. Alternatively, users may have the option of entering a known unique random value. The sender identifier is generally network specific, and does not change while using the TEK.

• 4-bit application identifier field 1202:

This field is used to identify an encryption stream used for different and possibly simultaneous applications such as voice, data, or incoming call signaling.

• 44-bit status counter field 1204:

This field is subdivided into the following subfields:

- 2-bit implicit component 1206:

This field is normally never sent (hence "implicit"), but is used to maintain SV uniqueness whenever multiple codebooks are needed to encrypt (or decrypt) a data frame. This counter can be thought of as a data frame codebook counter, resetting itself on each new data frame, counting the codebooks used per data frame.

_- 14-bit short duration component 1208:

This field is sent periodically (within an RTP payload) and serves as a data frame counter.

For the group communication service, the entire field is sent once for each transmitted packet (which may include one or more data frames). This field can be thought of as a data frame counter, since it is incremented by one for each data frame, regardless of the number codebooks required per data frame.

_- 28-bit long-life component 1210:

This field constitutes the "higher order" bits of a 42-bit counter made up of long-duration and short-duration components.

During a transmission, this field is automatically incremented by one whenever the short-lived component "resets the counter." The initial value of the long-duration component is chosen randomly when a new key is entered. The long duration component is incremented each time the short duration component resets the counter. The long duration component resets the counter to all zeros if it reaches the all ones state.

ES 2 320 731 T3

Initialization and uniqueness of the SV

There is no requirement for the initialization of the lower 44 bits of the state vector (other than the implicit two-bit field, which is reset for each data frame). However, the transmitter is required to ensure the uniqueness of the state vector (SV) throughout the duration of the traffic key. The duration of a traffic key can be an arbitrary (but finite) time. The sender identifier field 1200 helps ensure that SVs are unique among a group of users on the network. The default bits are initialized to "00" and are used in sequential order as a codebook counter within a data frame. This capability is applicable for data frames that are longer than a single codebook.

Since there is no central authority for assigning sender identifiers, the uniqueness of sender identifiers among network users cannot be absolutely guaranteed. The sender identifier is usually set randomly when a new key is entered. It remains constant for the duration of that key's use. In the unlikely event that more than one participant on a network is using the same sender identifier, Sv uniqueness can still exist if the long-lived and short-lived components between users are unique.

Application identifier 1202 is used to distinguish between encryption streams generated from different applications.

State vector maintenance

Transmitter

For each data frame supplied to the encryption device, the transmitter ensures the uniqueness of the state vector for the duration of the traffic key. This is accomplished by incrementing the existing short-lived component after the use of the state vector in an encryption operation (ie, after encryption of a single data frame). The implicit component is initially reset, and incremented for each successive codebook generated to encrypt a data frame. If the short duration component reaches its maximum value during the call, the transmitter sets the short duration component to zero, and increases the long duration component.

Receiver

For data frames supplied to the encryption device at a receiver, an associated state counter will be determined prior to decryption. Implicit and short-lived components are extracted from the RTP payload if used and provided to the decryption device along with the data to be decrypted. If the short duration component reaches its maximum value during the call, the decryption device increments the long duration component to maintain synchronization. The decryptor will also follow the periodic reception of parts of the state vector incorporated into the stream to facilitate the last entry. If for some reason there is a mismatch, the decryptor will use the retrieved value periodically to update the relevant parts of the state vector for decryption.

Encryption Synchronization Maintenance

Synchronization between transmitter and receiver must be maintained. Generally, each data frame encryption begins with a new codebook. That is, there is no attempt to save codebook bits from one frame to the next. If more codebook bits are generated than needed for encryption, the remaining bits are discarded after encrypting the data frame. The receiver must follow the identical procedure to stay in sync.

State vector synchronization is maintained by periodically transmitting portions of the SV as dictated by the application. Encryption timing information is sent within an RTP payload using an appropriate RTP payload profile. The encryption sync portion of the initial RTP payload is made up of the short-lived component (14 bits), the sender identifier (16 bits), the application identifier (4 bits), and the long-lived component (28 bits), as shown in Fig. 13.

Successive RTP payloads update the short-lived component and the application identifier based on the payload, while the remaining fields (including the long-lived component) are sent six bits by six bits, on a cyclical basis, to provide the "last entry" as required for group communications. Since there are 44 bits to be sent periodically (28 long-term + 16 sender identifier), it will take 44/6 or eight packets to accumulate these components from periodic transmissions. In addition, a predefined signal, such as two all-ones (111111) transmissions, must be included between each cycle of the periodic transmissions (eight periodic transmission packets + two marks) as the start of the frame mark. The value of the long duration component transmitted in a sequence of eight frames is the value that was valid in the first frame mark at the beginning of the transmission (this contemplates the case where the long duration component is in the process of restarting the counter).

ES 2 320 731 T3

If RTP is not used (for example, if CRTP header compression is not available), information identical to that described above must be inserted into the "application header" of a UDP packet stream. For simplicity, the procedures used to transmit and maintain encryption synchronization should be similar to those used when RTP is present.

Keys checksum

In one embodiment, CD 202 will calculate a checksum on the entered traffic encryption keys. Checksums can be used to verify that the correct key has been entered, or they can be exchanged (verbally or via email, for example) between users to verify that users are using the same TEK for a particular network. Knowledge of the checksum should not allow the user to determine the value of the key.

The CD 202 will calculate the checksum for any key entered, and this is generally available for display to the user. As an option, the checksum can be entered with the key. If the user enters a checksum, the CD 202 must not accept the key unless the entered checksum matches the checksum calculated by the CD.

Synchronization check

A transmitting CD will generally periodically include a sync check word in an encrypted transmission. In one embodiment, the sync check word is the result of encrypting a known constant value, using the current TEK of the network, and the current encryption sync state variable of the network, then truncating the result to a portion, as the least significant 16 bits, as shown in Fig.

14. The 16-bit sync check word is transmitted in the 16-bit sync check header field of the RTP payload.

The sync check field is periodically included in the transmitted stream to allow the last input / sync in a transmission already in progress (ie, a receiver has lost transmission of the entire state variable at the beginning of the transmission). The sync check field is periodically transmitted, in one embodiment, at least once per second.

Encryption of the sync check word uses a value from the short-lived component of the encryption sync state variable, just like encryption of a standard data frame. If a sync check word is included in a transmitted RTP frame, the first value of the state variable is used to encrypt / decrypt the sync check word, and payload encryption / decryption begins with the subsequent value .

The constant value used in the sync check word generation procedure is entered together with the TEK of the network. In one embodiment, the constant is 64 bits long, equal in length to a codebook. The constant value can be attached to the key and entered as a decimal string of length one. A delimiter can be used to separate the key and the sync check constant. The checksum will be calculated on the key and the sync checksum.

The previous description of the preferred embodiments is provided to enable any person skilled in the art to make or use the system and method to provide group communication services. The various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of inventiveness. Therefore, the intention of the system and method for providing group communication services is not to be limited to the embodiments shown herein, but is to be in accordance with the broadest scope consistent with the claims.