HK1078221A - A method and an apparatus for terminating a user from a group call in a group communication network - Google Patents

Description

Method and apparatus for terminating a user from a group call in a group communication network

FIELD

The present invention relates to point-to-multipoint communication systems, and more particularly to a method and apparatus for terminating a user from a group call in a group communication network.

Background

For many years, a class of wireless services for fast, efficient, one-to-one or one-to-many (group) communication exists in various forms. Typically, these services are half-duplex, in which a user presses a "push-to-talk" (PTT) button on his phone/wireless phone to begin speaking. In some implementations, pressing a key in the wireless phone, or pressing a button in a moderation system, indicates that the user requests the "floor," where communication occurs through some type of server. If the floor is granted, or the talker grants, the user typically speaks for a few seconds, after which the other talker requests the floor by releasing its PTT button. The communication is typically from one speaker to a group of listeners, but may be one-to-one. This service is traditionally used in applications where one person (such as a "dispatcher") needs to communicate with a group of people, such as a field service person or taxi driver, from which the "dispatch" name of the service originates.

Similar services are provided on the internet, commonly referred to as "voice chat". These services are typically implemented as personal computer applications that send vocoder frames to a central group chat server in Internet Protocol (IP) packets, i.e., voice over IP (VoIP) services, or possibly between clients in a peer-to-peer service.

One key feature of these services is that the communication is rapid and spontaneous, typically initiated by simply pressing the PTT button, without going through the usual dialing and ringing sequence. The communication in such services is typically short, with a single "burst" of speech typically on the order of a few seconds, and a "conversation" typically may last for one minute or less.

The time delay between the user requesting the floor and his receiving a positive or negative acknowledgement from the server that he has the floor and can start speaking is a key parameter of a half-duplex group communication system and is referred to as PTT latency. As described above, the dispatch system places priority on short, rapid sessions, which makes the service less efficient as PTT latency becomes greater.

Existing group communication infrastructures provide limited opportunities for significant PTT latency reduction, i.e., the actual PTT latency may not be reduced below the time required to re-establish traffic channels within dormant packet data sessions. Moreover, the talker and listener traffic channels are not proposed sequentially, as the only mechanism available to start waking up a dormant group is to wait for the talker's traffic channel to be re-established to inform the server. Currently, there is no mechanism to send mobile-originated user signaling data on channels other than the traffic channel — a limitation that the traffic channel needs to be re-established before any communication between the client and server occurs.

Thus, mechanisms are needed to reduce the apparent PTT latency experienced by the talker and to reduce the total time required to re-establish traffic channels to participate in the mobile station without negatively impacting system capacity, client battery life, or other resources.

In the scheduling model, communication between endpoints occurs in virtual groups, where a "talker" speech is broadcast to one or more "listeners". A single instance of such communication is commonly referred to as a dispatch call, or simply a call. A call is an instantiation of a group that defines the characteristics of a call and is essentially a member list with some relevant information, such as group name or group identification. The member list is a list of one or more users invited to participate in the call.

There is a need for a chat room model that supports both group call services and an ad hoc model thereof. In the chat-room model, groups are predefined, which can be stored on a dispatch server. However, in an ad hoc model, groups may be defined and/or modified in real-time.

Disclosure of Invention

The disclosed embodiments provide a novel and improved method in a communication device for terminating a member from a group call in a group communication network, the method comprising: receiving an indication from a user wishing to terminate participation in a group call, and sending a request to a server to cause the user to terminate from the group call.

In another aspect of the present invention, a computer readable medium in a communication device includes a method for terminating a member from a group call in a group communication network, the method comprising the steps described above.

In another aspect of the present invention, a communication device for terminating a member from a group call in a group communication network comprises: means for receiving a member-indication from a user wishing to terminate participation in a group call, and means for sending a request to a server to terminate the user from the group call.

In another aspect of the present invention, a communication device for terminating a member from a group call in a group communication network comprises: a receiver, a transmitter, and a processor communicatively coupled to the receiver and the transmitter. The processor may receive an indication from a user wishing to terminate participation in a group call and send a request to a server to cause the user to terminate from the group call. In one aspect, the communication device is a push-to-talk (PTT) device.

The disclosed embodiments also provide a novel and improved method in a server for terminating a member from a group call in a group communication network, the method comprising the steps of: the method includes receiving a request to terminate a user from a group call, terminating the user from the group call, and sending a response indicating that the user is terminated from the group call.

In another aspect of the present invention, a computer readable medium in a server includes a method for terminating a member from an active group call in a group communication network, the method comprising the steps described above.

In another aspect of the present invention, a server for terminating a member from a group call in a group communication network comprises: means for receiving a request to terminate a user from a group call, terminating a user from the group call, and sending a response indicating that a user has been terminated from the group call.

In another aspect of the present invention, a server for terminating a member from a group call in a group communication network comprises: a receiver, a transmitter, and a processor communicatively coupled to the receiver and the transmitter. The processor can receive a request to terminate a user from a group call, terminate the user from the group call, and send a response indicating that the user has been terminated from the group call.

Brief Description of Drawings

The features, nature, and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings in which like elements have like numerals wherein:

FIG. 1 illustrates a set of communication systems;

FIG. 2 illustrates how several applications interact with each other;

FIG. 3 illustrates an exemplary user registration process in accordance with one embodiment;

FIG. 4 illustrates an exemplary local, intra-area call setup procedure in accordance with one embodiment;

FIG. 5 illustrates an exemplary remote, in-zone call setup procedure in accordance with one embodiment;

FIG. 6 illustrates an exemplary local, inter-area call setup process in accordance with one embodiment;

FIG. 7 illustrates an exemplary remote, inter-area call setup process in accordance with one embodiment;

FIG. 8 illustrates an exemplary process for placing a group call according to one embodiment;

FIG. 9 illustrates an exemplary process for terminating a group call according to one embodiment;

FIG. 10 illustrates an exemplary process for sending alerts for a group call in accordance with one embodiment;

FIG. 11 illustrates an exemplary process for late joining a group call according to one embodiment;

FIG. 12 illustrates an exemplary process for preempting a speaker according to one embodiment;

FIG. 13 illustrates an exemplary process for joining a new member to an active group call according to one embodiment;

FIG. 14 illustrates an exemplary process for removing a participant from a group call according to one embodiment;

FIG. 15 illustrates an exemplary process for removing user registrations, according to one embodiment;

FIG. 16 illustrates how several communication devices interact with a communication manager according to one embodiment;

FIG. 17 illustrates buffering media at the communication manager side according to one embodiment; and

FIG. 18 illustrates buffering media at a client according to one embodiment.

Detailed Description

Before one embodiment of the invention is explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangements of components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.

Fig. 1 illustrates an exemplary functional block diagram of a group communication system 100. The group communication system 100 is also referred to as a push-to-talk (PTT) system, a Network Broadcast Service (NBS), a dispatch system, or a point-to-multipoint communication system. In one embodiment, group communication system 100 includes application server components such as a scheduler, a location server, a Media Control Unit (MCU) complex, a usage login server, and an Internet Protocol (IP) client (wireless and/or wired devices with IP connectivity). Depending on the functionality of the components, the application server components may be employed in either a centralized deployment or a regionalized deployment. The centralized deployment may include a local scheduler (HD)102, a local location server (HLS)104, and a user/group database 106. These components are centrally located in the service provider's network and are accessible through regional deployments. The centralized component may be used in locating and roaming users as well as in initiating inter-area group calls. The regionalized deployments 108, 110 may include a Regional Location Server (RLS)112, a Regional Dispatcher (RD)114, a regional Media Control Unit (MCU) complex 116, and a regional Use Logging Server (ULS) 118.

Regional deployments may be distributed in the service provider's network to ensure that network delays associated with call setup are kept to a minimum in order to meet instantaneous answer requirements. Distributing call load over several regional systems also ensures that a sufficient scalability scheme can be employed to support a large number of users. The regionalized application server component provides user registration, intra-region call setup and management, and alert origination and delivery for users who are registered in the region.

The group communication devices (clients) 120, 122 may be employed, for example, on cdma2000 handsets, and the group communication devices 120, 122 may request a packet data session using standard user service options, and use the session to register its IP address with an application server and perform group call origination. In one embodiment, the application server components 108, 110 are connected to a Packet Data Serving Node (PDSN) of a service provider. Clients 120 and 122 have IP connectivity to application server components 108, 110 through the PDSN after receiving a packet data session from the wireless infrastructure.

Upon power up, the clients 120, 122 may request packet data sessions using a data service option. As part of the packet data session establishment, the client is assigned an IP address. At this point, the client also receives the address of a Domain Name Service (DNS) server 124. Clients 120, 122 query DNS server 124, for example, by using a Service Record (SRV) lookup table, to find the address of RLS 112. After locating RLS112, clients 120, 122 may perform registration, informing the application server of its location information, such as an IP address. Registration may be performed using an IP protocol, such as Session Initiation Protocol (SIP) over User Datagram Protocol (UDP). The IP address of the client 120, 122 may be used to contact the client when inviting users to a group call.

In an embodiment, after registration is complete, the client may execute another DNS SRV record lookup table to find the address of the regional dispatcher 114. The client contacts the regional dispatcher whenever the user requests to initiate a call or send an alert. The interface between the regional dispatcher 114 and the clients 120, 124 may be a signaling protocol over UDP.

Once the group call is established, the clients 120, 114 and the MCU complex 116 exchange media and signaling messages. In one embodiment, real-time protocol (RTP) over UDP may be used to transmit media between the call participants and MCU complex 116. The signaling message may also be a signaling protocol over UDP. These protocols and the functions they provide are described below.

Assembly

The group communication network 100 may include IP endpoints that contain client software and may also include regionalized and centralized server components that are required to provide group communication services. The group communication client and application server components are described in more detail in the following sections.

Client machine

The group communication clients 120, 122 may operate on any IP endpoint that has access to an appropriate vocoder. IP endpoints may include applications running on wireless systems such as cdma2000, application development platforms such as Binary Runtime Environment for Wireless (BREW), and personal computers.

The client may include a software application developed using BREW, and an interface to mobile station Modem Software (MSM), which may be downloaded to the client containing the BREW environment. BREW is a platform that enables developers to create applications that can run on client communication devices. BREW provides an insulating layer to application developers, enabling application software to be developed without direct contact with MSM software and Original Equipment Manufacturer (OEM) software. This enables rapid development of applications and evolves independently of MSM and/or OEM software. It can also quickly download applications to any device that contains the BREW environment. As shown in FIG. 2, the client group communication application software 202 may be executed in parallel with other applications 204, 206, 208, 210. Although these services may be provided directly through the OEM 212 and MSM214 interfaces, BREW also provides isolation from modifications made by applications in these layers. This enables the OEM 212 and MSM214 to be developed separately from the data applications 202, 204, 206, 208, 210.

In order for the client to run efficiently on a personal computer, the personal computer may include access to a compatible vocoder, access to a voice driver, and an IP connection to an application server.

Location server

In one embodiment, a Location Server (LS) may accept and/or maintain user location information, such as a network layer IP address, the user's physical location, such as longitude and latitude, and/or a packet zone identification, i.e., a system identifier broadcast over the air on a forward common channel that identifies the range of PDSNs that are providing packet data services for the sector. In one embodiment, the LS may include a component that handles registrations from clients and provides user location information to other applications, such as instant messaging, using a SIP interface.

The LS may include two functional elements, a Regional Location Server (RLS)112 and a Home Location Server (HLS) 104. RLS112 can be deployed per region and HLS 104 can be centralized. The details of these elements and their functions are described below.

Regional location server

RLS112 may process and maintain registrations from clients located within its area. In one embodiment, RLS112 is a standard SIP-based LS with associated storage of subscriber location information. As part of the maintenance of the registration entry, RLS112 may check the expiration date, "expired" field for each registration. The RLS ensures that expired items are removed and both the regional scheduler (RD) and HLS are notified of the removed items.

As described above, the client may perform IP registration in order to inform the application servers about their location. Clients may maintain their registration with the group communication service for the duration of their availability. The client may perform re-registration when the client's IP address changes and when the registration is about to expire.

When a client registers or re-registers, RLS112 may notify its associated RD 114. This enables RD 114 to preload user data in preparation for a call setup request, thereby reducing call setup time. RD 114 may cache the user's location information, eliminating the need for RD 114 to contact the RLS to retrieve the user's location information during call setup.

The RLS112 may notify the RD 114 when the user location information is updated or removed from the RLS 112. This ensures that RLS112 and RD 114 remain synchronized with the latest information about users registered in the area.

The RLS112 also periodically updates the HLS 104 with the location information of the registered user. The HLS may resolve the conflict when the RLS112 submits a registration to the HLS 104 for a user who has a valid registration in another area.

Local location server

The HLS 104 may process queries for user location information. In one embodiment, the HLS 104 provides a SIP-based interface to allow other applications, such as instant messaging applications, to query location information for a particular user.

If the HLS 104 is a centralized component and the RLS is in communication with it, the HLS can resolve multiple registrations in different areas for roaming users. The HLS 104 may receive registration information from each RLS. If the HLS 104 receives multiple registrations for the same user, the HLS 104 can maintain the most current registration and request that the user's stale registration be removed from the RLS. This in turn triggers the removal of information cached for that user from RD 114 associated with the RLS containing the stale registration.

Scheduler

The scheduler may facilitate call setup by locating users and distributing group calls to the Media Control Unit (MCU) complex 116. The scheduler is a server component that is critical to meeting the "instant access" requirement. To ensure a minimum call setup time, the scheduler may comprise two functional elements with similar structure and function but with different deployment phases. These two functional elements, the regional scheduler (RD)114 and the local scheduler (HD)102, will be described in detail in the following sections.

Regional scheduler

RD 114 may be the initial point of contact for call setup requests and alert requests. RD 114 may preload the user information when it receives an indication from RLS112 that the user is registered. Together with the user information, RD 114 may cache information about group calls that are running in the system. RD 114 may use the cached information for users and groups during call setup to keep setup time to a minimum, i.e., without requiring a database lookup.

In one embodiment, the group information maintained by the RD in the cache includes a list of group members and the address of the MCU complex 116 on which the group is running on the MCU complex 116. RD 114 may maintain a member list and MCU addresses for the duration of the call. This helps RD 114 to quickly determine whether an incoming call request contains a group definition that is the same as the definition that has an associated call already running in the system. This enables the RD to quickly answer the call setup request and confidently grant or deny the "floor" request in the answer.

RD 114 may grant or deny the floor control request. The RD 114 may decide whether it will request the MCU complex 116 to join the user into the call as a "late join" participant, or to start a new call with the associated member list.

During call setup request processing, RD 114 may use the cached user information to retrieve location information for the user specified in the call setup request. If the user cannot be located, RD 114 may request HD 102 to locate the user. In one embodiment, if at least one or more target users are located, RD 114 continues the call setup. After the target user has been located, RD 114 may decide which MCU the call should be assigned to. This determination may be based on the IP addresses of the users in the group, including the originator.

RD 114 may handle alert requests similar to call requests. In one embodiment, the alert request is distributed to the native MCU complex 116 for processing regardless of the target user's location.

In one embodiment, the information in the cache of the RD may be periodically written to a reliable storage mechanism to enable recovery thereof in the event of a failure. After the RD failure recovers, the user and group information written to the reliable storage mechanism may be reloaded into the cache, and the RD continues to validate the cached information in connection with processing incoming call setup requests.

In one embodiment, RD 114 loads the user data into a local cache upon each user registration notification from RLS 112. By eliminating the need for several database lookups for call setup time, RD 114 significantly reduces the amount of time it takes to acknowledge and answer a call setup request or an alert request.

RD 114 may access user/group database 106 during call setup to extend a predefined group address (if present in the request) to a list of individual users and, if desired, translate other identifiers of the user or group, e.g., telephone number, conference identification, to canonical addresses.

Local scheduler

The local scheduler (HD)102 may track location information of registered users. The HD may contain location information of users who have performed registration with the RLS 112.

As described above, each RLS112 may notify its associated RD 114 each time a user registration, re-registration, de-registration, or registration expiration occurs. RD 114 may use this information to load or release user information in its local cache. Each RD 114 may update HD 102 with user location information. HD 114 may help find users that are geographically spread out in different areas because HD 102 receives updates from RD 114. RD 114 may request help from HD 102 upon receiving a request for a user not currently registered in its area (i.e., not in the RD cache of user information).

DNS server

In one embodiment, group communication system 100 may provide the location information of RLS112 and RD 114 to the client using DNS server 124 of the service provider. This information can be configured at each zone deployment and periodically updated to ensure its accuracy.

In one embodiment, each client learns of the DNS server's address through the Internet Protocol Control Protocol (IPCP) during a point-to-point protocol (PPP) session establishment. DNS server 124 may be informed by region in this manner. This enables the client to roam between areas and communicate with the DNS server 124 in the same area in which the client is located. DNS server 124 is deployed regionally in conjunction with individual PDSNs. In one embodiment, DNS server 124 may be updated with the respective RD 124 and RLS that are serving the PDSN associated with DNS server 124.

In one embodiment, the mechanism used to locate the appropriate RD 114 and RLS112 is based on a combination of DNS and SIP addressing. A DNS Service (SRV) record lookup may be performed based on the "< domain >" portion of the SIP URI under which the client is registered. The SRV record request may include the protocol or service that the requestor is attempting to find. For example, in the event that an attempt is made to locate RLS112, the client may request "registration service" in a DNS SRV record lookup table. The DNS reply may include one or more valid network and port addresses of the server that provided the requested service. By allowing DNS server 124 to alternate between multiple servers when returning replies to client requests, DNS server 124 may be used in load balancing between servers providing the same service.

User/group database

In one embodiment, the user/group database 106 is a central repository of user and group information. For each user, the database may include information such as user address, preemption ranking, authentication information, user contact information, and a lawful intercept flag that indicates whether the user is being monitored. The database may also include a definition of a predefined group, which is a list of users and associated group names of the chat room model of the dispatch service. Each group may be uniquely identified by, for example, a group address. The client may use the group address to identify the group in the group call setup request. The RD 14 may use the group address to retrieve the relevant member list from the user/group database 106 when it uses a group call setup request in which there is a predefined group.

Media control unit complex

A Media Control Unit (MCU) complex may include a Media Control Host (MCH) and a Media Control Unit (MCU). The MCH may host and manage multiple MCU processes. Each MCU may handle real-time signaling and media processing for a single call. The functions performed by the MCU for a call may include:

● handles call distribution from RD 114

● send load and status information to the MCH

● sending call start information to client

● handle incoming calls from clients, such as PTT requests

● ensure that signaling messages are reliably delivered to clients

● copying and distributing media for one-to-many calls

● provide media conversion for "hybrid" vocoder "one-to-many" calls using appropriate transcoders

● monitor call activity and initiate call termination based on inactivity of media flows

● generate usage information for Usage Log Server (ULS)118

● forward media and signaling information to the appropriate legal intercept point upon request.

The MCU may process the alert request from RD 114, issue an alert notification to the client, and wait until an acknowledgement from the client. Upon receiving the acknowledgement from the target, the MCU releases any resources allocated to the alarm transaction. At this point, the MCU may process other call assignments or alert requests.

Using a login server

The ULS 118 may be present in each area and located with the MCU complex 116. ULS 118 may collect usage events from MCU complex 16 for each call or alarm handling, format them into usage data records (HDR), and then save these UDRs in the order of UDR files. The UDR of a call may contain information about an individual call comprising a list of participants and the total number of participating uses. The UDR of an alert may contain information indicating the originator of the alert and the target user to whom the alert is sent. UDR files may be collected by the service provider for billing analysis and may be deleted after a fixed amount of time.

ULS 118 may write a single HDR per call instance at the end of each call. ULS 118 may also write a single UDR each time an alarm request is processed. The UDR written by ULS 118 may contain the following information:

● Call instance identifier or alarm instance identifier

● also implies the MCU identifier of the call location. At the start of the call, the appropriate MCU may be selected according to the registered locations of all the proposed participants. The location of the MCU may or may not be in the same region as the originator.

● start time of call or alarm

● end time of call or alarm

● originating username and/or identifier

● originating user IP Address

● for each participant, the user name, user address, user IP address, cumulative time of participation, which may be zero for alerts, and the total number of seconds the participant holds the floor, which may be zero for alerts.

In one embodiment, for each call issued by a single UDR, it may represent the total collection of speaking segments during the call. If a UDR event registration is required per spoken segment, the UDR event registration is achieved at the cost of additional processing load, file I/O, and disk space requirements.

The group communication system 100 performs several different functions in order to operate the group service. The functions related to the user experience include registration, call initiation, call termination, sending alerts, late join, speaker arbitration, adding users, removing members, de-registration, addressing, and authentication. Functions related to system preparation and operation include management and provisioning, scalability, and reliability. These sections are described in detail in the following sections.

Registration

In a wireless communication system, such as a CDMA system, registration is the process by which a mobile station makes its location known to the wireless system infrastructure. The location information may include the geographic area in which the mobile station is located, as well as the identity of the base station that is serving the mobile station, which may be used to help efficiently use the paging and access channels.

In one embodiment, the user location information is the client's IP address, whether the client is connected through a wireless or wired service. An exemplary IP protocol that enables IP applications to locate clients based on their IP addresses is the Session Initiation Protocol (SIP). SIP provides, among other functions, a way for clients to register their IP addresses and other location information with SIP server components. In addition, SIP provides methods that allow IP applications that are concerned with "finding" a client to query the same SIP server component for location information, such as the IP address of the client.

Registration may include the process of an IP client communicating with a SIP server to notify and maintain its location information (e.g., IP address). The SIP server component that provides this functionality is a location server. The method by which the client informs the location server of its location or a change to its location is the SIP REGISTER (SIP registration) method.

In one embodiment, clients register their location information with a regional location server. Other IP-based applications, such as instant messaging, may benefit from learning the IP address of each client available in the location server. The external service or client may perform registration. Fig. 3 illustrates an exemplary call flow for performing the registration function.

Upon power up 302, the client may request a packet data session and begin the process of registering its IP address with RLS 112. To perform registration, the client may perform a DNS SRV record lookup 304 to determine the address of the RLS. Once the RLS address 306 has been retrieved, the client registers its location information 308 by using a SIP register message. The RLS may authenticate the user 310 and issue a response 312 to the client. The RLS may inform the regional dispatcher that the user is registered 314 and the regional dispatcher may use this information to preload the user-related data records to facilitate faster answering during call setup. In this regard, the client may contact the incentive to participate in the group call. In one embodiment, clients may need to perform registration in order to receive group calls regardless of whether they possess a data connection type that is wireless or wired.

Registrations have an "expiration" field associated with them that indicates how much time the registration information of the client should be considered valid. To ensure that the client is always accessible over IP, the client is always aware of the expiration of its registration and performs a re-registration before expiration. Registration may always become invalid or stale due to other circumstances, such as when the client's IP address changes or the data connection between the client and the location server becomes bad. The client will know the status of its data connection and whether their IP address has changed.

After initial registration has been completed, the client may allow its packet data session to go dormant, which may release the dedicated traffic channel. The client may monitor its packet data sessions to ensure that it remains active for an extended period of dormancy. Conditions that may affect session validity include: move to areas with different packet zone IDs, experience fading or loss of service, and accept and/or make PSTN calls. The client's IP address may change, possibly requiring the client to reestablish a data connection to the infrastructure. When a client reestablishes its packet data session, it receives a new IP address. The new IP address needs to be communicated to the location server to ensure that the location information of the client remains accurate. This may be done by performing a re-registration.

By periodically "pinging" the location server, a wired client passing through the firewall to the location server may need to remain open through the firewall. This is done by performing a re-registration.

Group call origination

After registration is complete, the user may make or receive calls. Before the first call begins after power up, the client may perform a DNS SRV record lookup to find the location of the regional dispatcher. This may be performed as part of the start-up procedure.

A "group" is associated with an originator that initiates the group setup and a member list that contains the target users. The member list may contain one or more users, one or more predefined groups, or a combination of both. A call that starts using a member list is often referred to as a private call if the member list contains only one user. If the member list contains any predefined groups, the regional scheduler may extend the predefined groups into the list of one or more target users, for example by replacing the predefined group identifiers in the original member list with the associated member list of the predefined group. After the predefined group has been expanded, the resulting member list contains only the target username. At this point, the regional scheduler attempts to locate the target user in the member list, such as by scanning the regional scheduler cache for user information. If the target user is located in the cache of the regional scheduler, the members of the group are registered in the same region as the regional scheduler. Such group calls are labeled as "in-area" calls. If there are users that the regional scheduler cannot locate, the regional scheduler can request assistance from the local scheduler to locate the user. Calls associated with groups containing members from two or more areas are referred to as "inter-area calls".

After the regional scheduler has determined whether the call is intra-regional or inter-regional, it may begin the process of determining which Media Control Unit (MCU) may host the call. For intra-regional calls, the regional scheduler may allocate the call to an MCU located in the same region as the regional scheduler if there are MCU resources available in that region. Calls made using such call setups are referred to as "locally-hosted" calls, i.e., local calls. For inter-regional calls, the regional scheduler may have an opportunity to allocate the call to an MCU located in the same region or located in a remote or external region. The regional scheduler can make this decision based on the user's location information to find the best propagation path for IP packets containing media and signaling. If most users are located in a particular area, calls may be assigned to that area. If the users are evenly distributed over the areas, the call may be assigned to one of the areas containing the target user. If an inter-regional call is assigned to an MCU in a region other than the region in which the regional dispatcher resides, the call is referred to as a "remotely hosted" or remote call. The regional schedulers may learn the network topology and/or connections between the MCUs and PDSNs that they are serving and may use this knowledge to make better decisions about the allocation of calls.

In-zone calling

Group communication system 100 may be developed to ensure that most calls are calls within a region. Intra-regional calls would eliminate the need for communication between the regional dispatcher 114 and the local dispatcher 102 at call setup time. The need for inter-regional communication is also eliminated when the target user is in the same region and hosts the call locally, as is the case for most intra-regional calls. The following sections describe call flow, timing estimation, and messaging schemes for calls within a region.

Initiating a local call

Fig. 4 illustrates an exemplary message flow for starting a local group call. The user may select 402 one or more target users, one or more predefined groups, or a combination of both, and may press a push-to-talk (PTT) button. The client sends a request 404 to the regional dispatcher to establish the group call regardless of whether the mobile station has a dedicated traffic channel, as will be described in more detail below. After sending the request, the client may begin the process of re-establishing the dedicated traffic channel and preparing the packet data session for media activity if the mobile station's packet data session is dormant. The client will buffer the speech input received from the originator for some period of time.

When the regional dispatcher receives the request, it will extend the predefined groups, which may be specified in the request, into the list of target user members. The regional scheduler then retrieves 406 location information for the target user. In this regard, the regional scheduler can also determine whether the group is already running in the system. Fig. 4 shows a case where a group is not yet running. The late join call scenario described later herein illustrates the case where the group is already operational.

After the regional dispatcher locates at least one target user, the regional dispatcher can send a response 408 back to the client indicating that the group call has been established. At this point, the client may optimistically grant 410 a request for the originator to speak and begin buffering 412 its media.

The regional dispatcher can use the location of the target user to determine the region in which the call can be assigned. If it is determined that the target user is in the same region as the regional scheduler, the regional scheduler may assign the call to a regional MCU, as shown in FIG. 4. The MCU may issue a declaration 414 to the entire group indicating that the call is being initiated. For the target users, the transmission of the announcement triggers their packet data sessions to come out of dormancy and to reestablish their traffic channels.

After the client receives the call announcement from the MCU and the mobile station's traffic channel has been re-established, the client may forward 416 the buffered media to the MCU. The MCU may buffer 418 the media received from the originator. In an embodiment, the MCU may buffer the media until a "target response threshold" is met or exceeded. The target response threshold is an indication of a target amount of response needed to continue sending media. The threshold may be a configurable parameter. Once the threshold is met, the MCU copies the media and forwards 420 it to the target user who has responded 422 to the announcement of the call.

Message delivery over short data bursts

"instant response" refers to the response time required for an application server to respond to a PTT or call setup request. The goal of responding to any PTT request, including a group call setup request, is to consistently respond to the request within a predetermined period of time, such as one second or less. In many cases, when a user requests to establish a group call, the user's packet data session is dormant and there are no dedicated traffic channels. Re-establishing dedicated traffic channels can take considerable time. Thus, communication to the application server may be accomplished by some other means.

To ensure that the group communication system satisfies "instant response," small IP datagrams, mobile originated or mobile terminated, may be sent at any time in either direction, regardless of the state of the packet data session. In one embodiment, the IP datagrams may be sent in the form of short data burst messages (SDB). In the event that the packet data session is dormant, the SDB message will be sent over an overhead channel. When a dedicated traffic channel connection exists, the SDB message is sent over the traffic channel.

Referring to fig. 4, group call setup request 404 may be sent via SDB messages. The group call setup response 408 from the application server may also be sent in an SDB message. The call setup request and response messages sent via SDB messages enable the group communication system 100 to meet the "instant response" goal.

To complete the process of establishing a group call, the MCU may issue a call announcement to the users in the member list, including the originator. These call announcements may be sent over dedicated traffic channels. In most cases, the packet data sessions of the group members are dormant, i.e., no dedicated traffic channel is established. This means that the MCU may have to resend the call announcement message on a progressively more reliable schedule until the traffic channels of all members have been re-established and the members have acknowledged the message or the reliability timer expires. Progressively sending the call announcements ensures that the media buffering on the client and MCU is kept at a minimum level. The client may send the buffered media upon establishing its traffic channel and receiving a call announcement containing MCU contact information. The MCU may copy and forward the buffered media as long as the target response threshold is met or exceeded. This means that the faster the target user receives the call announcement and responds to it, the faster the threshold can be met, and the faster the MCU will stop buffering and start sending media.

The call announcement to the originator may also be sent via SDB. This provides two benefits. First, since the call announcement contains MCU contact information, the group call client begins sending buffered media to the MCU as soon as the mobile station's traffic channel is re-established, which reduces the RAM requirements for the mobile station to hold the buffered media. Second, if the originator decides to abandon the call or release the floor, which would occur before re-establishing the traffic channel, the client will inform the MCU with this information when the call announcement comes through the SDB. The effect of sending the call announcement to the originator through SDB is an increase in the load on the common channel and the requirement for the MCU to make special treatment for the originator's call announcement message.

Initiating a remote call

If all members are located in the same area, the in-area call can be hosted in a local manner. The regional dispatcher will assign intra-regional calls to a remote region due to local resources being overloaded or unavailable. In this case, the media and signaling may experience additional latency and errors due to the extended communication path between the user's PDSN and the remote MCU. Fig. 5 illustrates an exemplary call setup procedure for a remote, in-region call.

Initiating a call within the zone on the remote host is similar to the call setup scenario discussed in connection with fig. 4, except for the assignment of calls to the MCU by the zone scheduler. After the regional scheduler has retrieved the location of the group members, it can determine the MCU to which the call is assigned. The regional scheduler makes this decision based on the user's location information, load, and availability of the MCU. In an intra-regional call, the user will be in the same region and therefore the regional scheduler will check the load and availability of the MCU complexes in the local region. If the regional scheduler receives an indication that the local MCU complex has been overloaded or temporarily experienced an operational failure, it may assign the call to a remote MCU. In an embodiment, the MCU may be a duplicate of the same functionality, except for call configuration; thus, the remote MCU may handle the call similarly to the local MCU.

Inter-area calling

The group call system 100 may be designed to allow users to communicate with any other user, regardless of their physical location or proximity to each other. The group communication system 100 may be employed to limit the number of calls between areas because an inter-area call requires communication between the regional scheduler and the local scheduler at call setup time. Call allocation may be to MCUs located in remote areas remote from one or more call participants. The following sections describe exemplary call flow, timing estimation, and messaging schemes for inter-area calls.

Initiating a local call

Fig. 6 illustrates an exemplary message flow diagram for initiating a locally-hosted group call. Call setup for local, inter-regional calls is similar to call setup for local, intra-regional calls, which has been described in connection with fig. 4, except that the regional dispatcher retrieves local information for the target user. In one embodiment, the regional scheduler attempts to locate a target user within its cache. If some users are not found in the cache, the regional scheduler can request assistance from the local scheduler to locate the user. The local scheduler may contain user location information for users who have performed IP registration using the regional location server. As described above, the regional location server may notify its associated regional scheduler whenever user registration occurs. Each time the regional scheduler can inform the local scheduler about the user registration. This enables the local scheduler to help the regional scheduler find users that are geographically spread over different regions.

Initiating a remote call

Fig. 7 illustrates an exemplary setup process for a remote, inter-area call. Starting an inter-regional call on a remote host is similar to the call setup scenario described in connection with fig. 4, except for the allocation of calls to the MCU by the regional scheduler. After the Regional Dispatcher (RD)114 retrieves the location of the group members, it may determine the MCUs to which calls should be assigned. RD 114 may make this decision based on the user's location information, the load and availability of the MCU. By using the location of the group members, the RD attempts to find the best propagation path for IP packets containing media and signaling through the service provider's network for most members. If most users are located in a particular area, calls may be assigned to that area. If the users are evenly distributed over the area, the call may be assigned to one of the areas containing the target user.

Group call termination

The end of the group call has two reasons: either all participants have requested to leave the call or all participants have stopped speaking for a predetermined period of time, which is referred to as the "hang time". Each participant may choose to end participation in the call before the call plan end time. If all participants leave the call, the MCU will abort the call and release all resources allocated to the call. If only one participant does not leave the call, the MCU will notify that participant, called an "individual user". The individual user can choose to leave the call immediately or wait for the abort timer to expire, which triggers the MCU to dismiss the call.

The MCU may terminate the call upon expiration of the abort time timer. The MCU will track each talk burst and set a timer after the talk burst is complete. This timer is called the hang time timer and can track the duration of silence in a call, i.e., no speech or media stream activity. If the call remains quiet for the duration of the hang time, which may be configured by the service provider, the MCU assumes that the participants are no longer interested in the call and thus terminates the call.

User initiated call termination

Fig. 8 illustrates an exemplary situation in which the user has selected to end participation in the group call. This case describes a message flow for terminating user participation. When the user chooses 802 to end participation in the group call, the client may send 804 a request to the MCU requesting that the user be removed from the call. The MCU may remove 806 the user from the call and notify 808 the client that the user has been removed 810.

Server initiated call termination

Fig. 9 illustrates an exemplary message flow that occurs when the abort time timer expires and the MCU terminates the group call. Upon expiration of the hang time timer 902, the MCU may send 904 a notification to the participants that the call is about to end. Each client that receives the end-of-call notification replies 906 with an acknowledgement. Upon receiving the acknowledgement, the MCU will notify 908 the RD that the call has ended and will release the resources that were allocated to the call.

Sending an alarm

An alert mechanism may be used to notify the target user: another user (the alert originator) has expressed a desire to participate in the group call. The alert mechanism may comprise a text message that enables the originator to specify the subject of the call, the desired time of the call, or any other user-customizable text message. FIG. 10 illustrates an exemplary message flow that occurs when a user sends an alert.

The originator may select 1002 one or more target users, one or more predefined groups, or a combination of both, and may indicate that an alert has been sent. The client may send 1004 a request to the RD to send an alert to the target user specified in the request. When the RD receives 1006 the request, it may extend 1006 the predefined groups specified in the request into a member list of the target user whose location information the RF can retrieve. After the RD has located at least one target user, the RD may send a response 1008 back to the client. The RD may assign 1010 the alert request to the MCU to broadcast an alert message 1012 to the target user.

As noted in fig. 10, the alert request may be sent via a Short Data Burst (SDB). Sending alerts via SDB messages enables packet data sessions for the involved parties to remain dormant. The alert notification contains the necessary information to enable the target user to establish a group call with the originator and the remaining target users, for example by selecting the alert notification and pressing PTT. When this occurs, the group call setup continues similar to the call setup scenario discussed in connection with FIG. 4.

Post-addition of

The group call setup request is considered late-join if it is determined that the member list specified in the call setup request is the same as the member list associated with calls already in progress in the system. This situation can occur in one of two ways. First, the user may create a member list that is the same as the member list that already has an associated call, for example by selecting the exact same user and/or group and pressing the PTT button. Second, the user can select a call from the call history list and press PTT, the call still running in the system. In either case, the RD may detect that a call that the user has requested to start is already in progress and treat the user as late joining.

Fig. 11 illustrates an exemplary late-join scenario in which a user may select a call from a call history list. The user may select 1102 a call from the call history list and press the PTT button. The client may send 1104 a request to the RD to start the group call. The RD may determine that the call has been run 1106 and send a response 1108 to the client stating that the user has been joined to the ongoing call. If the call is already running, the floor may be granted to the user since the current call participant may already have the floor before the late-joining user is ready to receive media, i.e., the packet data session is taken out of dormancy. The RD may request 1110 the MCU hosting the call to join the late joining user to the group. The MCU adds the user and sends 1112 a statement to the user containing the MCU's contact information. After the traffic channel of the late joining user is re-established, the media stream within the call is sent to the user. At this point, the late-joining user may attempt to request the right to speak.

The late join scenario is similar to the scenario described in connection with fig. 4 where a new group call is started. The difference is that the late-joining user is denied the floor in response to the initial group call setup request.

Speaker arbitration

In one embodiment, each group call user is assigned a speaker preemption hierarchy that determines the level of authority that the user has when requesting the privilege to occupy the "floor" and begin speaking. After the group call is established, the MCU will be responsible for floor control and determine whether the participant requesting the floor is permitted to speak. The MCU may perform speaker arbitration when two or more call participants are competing for control of a particular group's floor.

FIG. 12 illustrates exemplary events that may occur during an arbitration process. The arbitration scheme used in this case allows deprivation of user B when user a requests the floor. When user a requests permission to talk by pressing 1202 the PTT button, user B has control of the floor, i.e., user B is talking. The client will send 1204 a message to the MCU that is requesting permission to talk. The MCU may perform speaker arbitration 1206 and determine that user B is deprived and that user a is granted the floor. To ensure a break in the media stream, i.e. that user B may stop speaking before sending user a's media, the MCU first sends 1208 a message to user B's client indicating that the floor has been preempted by another user, and then sends 1210 a response granting the floor to user a.

Joining a user to an active group call

The group communication system 100 allows group call participants to join new users into an ongoing group call. This is done by: the call participant selects one or more target users, one or more predefined groups, or a combination of both, and indicates that the participant would like to add a target to the group call in which the participant is currently located. Fig. 13 illustrates events that occur when a new target is added to an ongoing group call. The call participant may select 1302 one or more target users, one or more groups, or a combination of both that should be joined to the call. The client will send 1304 a message to the RD requesting to join the specified target user to the ongoing group call, which is specified in the request. When the RD receives the request, it may extend the predefined groups specified in the request to the list of target user members. The RD then retrieves 1306 the location information of the target user. After the RD has located at least one target user, the RD may send 1308 a response back to the client indicating that the target user is being joined to the call. The RD may send 1310 a request to the MCU to join the specified user to the call. The MCU may issue 1312 call announcements to the new targets, which may begin the process of bringing their packet data sessions out of dormancy. The declaration may be sent on a reliability schedule to ensure that the targeted user receives the message. After the traffic channel of the target user is re-established, the target user may send 1314 an acknowledgement to the MCU. Additional target users may be included in 1316 the media and signaling communications that occur in the call.

Removing members from an active group call

Group communication system 100 allows a group call participant to remove members from an active group. In one embodiment, this may be accomplished by the call participant selecting one or more target participants and indicating that they should be removed from the group call. Fig. 14 illustrates an exemplary event that may occur when a participant is removed from an ongoing group call. The group call participant may select 1402 one or more target participants that should be removed from the call. The client may send 1404 a message to the RD requesting that the target participant specified in the message be removed from the group call. When the RD receives the request, it may retrieve 1406 the location information of the target and may send 1408 a response back to the client indicating that the target is being removed. The RD sends 1410 a request to the MCU to remove the target from the call. The MCU may send 1412 a message to the targets, which may be specified in the removal request indicating that they are being removed from the call. The target may send 1414 an acknowledgement to the MCU.

Deregistration

The de-registration function may be performed when the user no longer wishes to be associated with an application server or any other IP application that uses the user's IP address to contact the user. The de-registration function removes the user's IP address and other contact information from the RLS and releases any resources allocated on behalf of the user. Fig. 15 illustrates how the user's registration is removed from the RLS as a result of the mobile station being powered down, according to one embodiment. The client may receive 1502 an indication that the mobile station on which the client resides is powered down. As part of the shutdown procedure, the client may send 1504 a message to the RLS indicating that the user's location information should be removed. The RLS can validate 1506 the request to ensure that it is from a reliable source. After successful authentication, the RLS may notify 1508 the client with an indication of success and notify 1510 RD about the user's removal. The RD may remove the user's data record from its cache and free up the resources that have been allocated to the user. Without being able to de-register, the user's location information may eventually be removed from the RLS when the time associated with the expiration field has elapsed.

In one embodiment, group communication system 100 supports both chat room and ad hoc models. In the chat-room model, groups are predefined and they can be stored in the dispatch server. The predefined group may be public, meaning that the group has an open member list, i.e. any scheduled user is a potential participant. In the chat-room model, a call is started when a first person chooses to join the chat room, and the call is kept running for a predetermined period of time, which may be configurable by the service provider, regardless of call activity, and server resources are allocated to the call. The user specifically requests to join and leave these call types. During periods of call inactivity, each call is brought into a group dormant state, as described below, until the user requests permission to speak.

In the ad hoc model, groups can be defined in real time and have a closed member list associated with them. The closed member list may specify which users are allowed to participate in the group, may not be available to users outside the closed member list, and only the duration of the call may exist. Ad hoc group definitions cannot be saved anywhere; they are used to set up the call and are released after the call is over.

An ad hoc group may be formed when an originating user selects one or more target users and generates a request that is sent to a server to initiate a call. A notification may be sent to the target users that they have been included in the group and will automatically join the associated call, i.e., without requiring any action by the user. When a particular call becomes inactive, the application server will "drop" the call and release the resources allocated to it, including the group definition used to start the call.

When operating in the chat-room model, in group communication system 100, a group of communication device users (individually referred to as network members) communicate with each other using a communication device assigned to each network member. The term "network" denotes a group of communication device users that are authorized to communicate with each other.

In one embodiment, the central database may contain information identifying the members of each particular network. More than one network may operate in the same communication system. For example, a first network may be defined by ten members and a second network may be defined by twenty members. Ten users of a first network may communicate with each other but not with members of a second network. In another embodiment, members of different networks can monitor communications between members of more than one network, but can only send information to members within their own network.

A network can operate over an existing communication system without substantial changes to the existing infrastructure. Thus, a controller and users on a network may operate in any system capable of sending and receiving packet information using the Internet Protocol (IP), such as a Code Division Multiple Access (CDMA) system, a time division multiple Access (TDM) system, a Global System for Mobile communications (GSM) system, such as a Globalstar system^TMOr Iridium^TMSuch as a satellite communication system, or a variety of other systems.

The network members may communicate with each other using assigned communication devices, illustrated as Communication Devices (CDs) 120 and 122. CDs 120 and 122 may be wired or wireless communication devices such as land-based wireless telephones, wired telephones having push-to-talk capability, satellite telephones equipped with push-to-talk functionality, wireless video cameras, still cameras, audio devices such as music recorders or players, laptop or desktop computers, paging devices, or any combination thereof. For example, the CD 120 may comprise a wireless land-based telephone having a camera and a display. Also, each CD is capable of transmitting and receiving information in either a secure mode or a non-secure (clear) mode. Throughout the following discussion, reference to a single CD refers to a wireless push-to-talk telephone. It should be understood, however, that reference to a CD is not limited thereto and includes other communication devices capable of transmitting and receiving packetized information in accordance with the Internet Protocol (IP).

In group communication system 100, the transmission privileges generally enable a single user to transmit information to other network members at a given time. The sending privilege is granted or denied to the requesting network member depending on whether the sending privilege is currently assigned to another network member at the time the request is received. The process of granting and denying transmission requests is referred to as arbitration. The arbitration mechanism may evaluate the following factors in determining whether the requesting network member is granted transmit privileges: such as a priority level assigned to each CD, a number of unsuccessful attempts to gain transmission privileges, a length of time that a network member has held transmission privileges, or other factors.

To participate in system 100, CDs 120 and 122 can each request transmit privileges from controller or MCU 116. MCU 116 will manage the real-time and administrator operations of the group. The MCU is any type of computer-type device having at least one processor and memory. MCU 116 may operate remotely through a communication system service provider, a member, or both, assuming that the service provider provides authorization. MCU 116 may receive the group definition through an external management interface. Group members may request administrator actions through their service provider or manage network functions through a defined system, such as a Security Manager (SM) operating in accordance with the members of the MCU management interface. MCU 116 may authenticate a participant attempting to establish or modify a network.

The SM may perform key management, user authentication, and related tasks to support a secure network. A single group communication system may interact with one or more SMs. SM may not be involved in the real-time control of the network, including network activation and PTT arbitration. The SM may have management capabilities compatible with the MCU interface to automate management functions. The SM can also act as a data endpoint in order to participate in the network, broadcast network keystrokes, or simply monitor network traffic.

In one embodiment, the means for requesting transmission privileges from the MCU comprises a push-to-talk (PTT) button or switch. When a user in system 100 wishes to send information to other members, the user presses a push-to-talk switch located on his or her CD to send a floor control request to obtain transmission privileges from MCU 116. If no other network member is currently assigned the sending privilege, the requesting user is granted the sending privilege and may be notified with an audible, visual, or tactile alert through the CD. After the requesting user is granted the send privilege, information is then sent from the user to the other members.

In one embodiment of the invention, each wireless network member establishes a forward link and a reverse link with one or more base stations 126, or with a satellite gateway. Voice and/or data may be converted into data packets using a CD, such as data packets appropriate for a particular distribution network 128 through which the distribution network 128 may be delivered to other users. In one embodiment, the distributed network 128 is the Internet.

In one embodiment, a dedicated forward channel is established in each of the communication systems, i.e., the terrestrial communication system and the satellite communication system, for broadcasting information from each network member to the other network members. Each network member may receive communications from other network members over a dedicated channel. In another embodiment, a dedicated reverse link is established in each communication system for transmitting information to MCU 116. In an embodiment, a combination of the above approaches may be used. For example, a scheme may include establishing a dedicated forward channel but requiring CDs to transmit information to MCU 116 over a dedicated reverse link assigned to each CD.

When a first network member wishes to send information to other members of the network, the first network member requests a send privilege by pressing a push-to-talk button on his or her CD, which results in a request formatted for sending over the distributed network 128. In the case of CDs 120 and 122, the request may be sent over the air to one or more base stations 126. Between the BS 126 and the distribution network 128, there may be a Mobile Switching Center (MSC)130, which MSC 130 may include a well-known interworking function (IWF), Packet Data Serving Node (PDSN), or Packet Control Function (PCF) for processing data packets. The request may be sent over a Public Switched Telephone Network (PSTN) to a modem bank, which may receive the request and provide it to the distribution network 128. The terminal may monitor traffic of the system 100 through its connection to the distributed network 128.

If no other member currently holds the transmit privilege, when MCU 116 receives the transmit privilege request, MCU 116 may send a message to the requesting network member informing it that the transmit privilege has been granted. Audio, video, or other information from the first network member may then be transmitted to the other network members by transmitting it to MCU 116 using one of the transmission paths just described. In one embodiment, MCU 116 provides the information to other network members by copying the information and sending each copy to the other network members. If a single broadcast channel is used, the information need only be replicated once for each broadcast channel in use.

In another embodiment, the MCU 116 is incorporated within the MSC 130 such that data packets from supporting base stations are routed directly to the MCU 116 without having to be routed to the distributed network 128. In this embodiment, MCU 116 is still connected to distributed network 128 so that other communication systems and devices may participate in group communications. In yet another embodiment, the MCU 116 may be incorporated into the PCF module of the PDSN or MSC 130.

In one embodiment, MCU 116 maintains one or more databases that are used to manage information about individual network members and about each defined network. For example, for each member of the network, the database may include information such as a username, account number, telephone number, or dial-up associated with each member's CD, a mobile identification number assigned to the CD, the status of the current member in the network, such as whether the member is currently participating in the network, a priority code for determining how transmission privileges are assigned, a telephone number associated with the CD, an IP address associated with the CD, and an indication of which network the member is authorized to communicate with. Other relevant types of information may also be maintained by the database of each network member.

In one embodiment, the CDs may form connections with individual communication terminals to form a talk group, i.e., a network. The MCU may include a variety of functions in hardware and software that may be configured in different ways to accommodate different applications. The MCU may provide the following functions: managing the real-time, administrative, and authenticity operations of the network, push-to-talk (PTT) request arbitration, maintenance and distribution of network membership and registration lists, call setup and teardown of necessary communications, such as CDMA, system and network resources, and overall control of network state.

The network may be within a separately deployable cellular system, or in a large multi-site configuration. In the case of a large configuration, multiple MCUs may be geographically deployed to form a single, integrated system, each of which operates as a plug-in module in an existing cellular infrastructure. In this way, new features introduced by the network are available to cellular users without modification to the existing cellular infrastructure.

The MCU may maintain a list of defined networks. In one embodiment, each network definition includes a network identifier, a list of members (including telephone numbers or other identifying information), user priority information, and other general management information. A network may be statically defined as open or secure, with transitions between open and secure not allowed. Secure networks typically use media encryption to provide authentication and prevent eavesdropping. Media encryption for secure networks is implemented on an end-to-end basis, meaning that encryption and decryption may occur within the communication device. The MCU may operate without learning security algorithms, keys or policies.

FIG. 16 illustrates an exemplary group 1600 for showing how communication devices 1602, 1604, and 1606 interact with the MCU 1608. Multiple MCUs may be deployed for large-scale groups as needed. In fig. 16, CD1602 is permitted to send media to other members of the group. In this case, the CD1602 is called a talker and transmits media over a channel. When CD1602 is designated as the talker, the remaining participants CD 1604 and CD 1606 do not have permission to send media to the group. Thus, CD 1604 and CD 1606 are designated as listeners.

As described above, CDs 1602, 1604, and 1606 connect to MCU 1608 using at least one channel. In one embodiment, the channel is divided into separate channels including a Session Initiation Protocol (SIP) channel 1610, a media signaling channel 1612, and a media traffic channel 1614. SIP channel 1610 and media signaling channel 1612 may be used by any of CDs 1602, 1604, and 1606 whenever bandwidth permits, whether designated as speakers or listeners. SIP is an application-layer protocol defined by the Internet Engineering Task Force (IETF) that describes control mechanisms for establishing, modifying and terminating multimedia sessions operating over the Internet Protocol (IP). The SIP protocol provides a general solution to the call signaling problem for internet telephony applications by supporting mechanisms for registering and locating users, mechanisms to define user capabilities and describe media parameters, and mechanisms for determining user availability, call setup and call processing.

In one embodiment, SIP channel 1610 is used to start and end participation of CDs within group 1600. Session Description Protocol (SDP) signals may also be used within SIP channel 1610. When participation of CDs within a group is established, such as by using SIP channel 1610, real-time call control and signaling between CDs and MCUs occurs, such as by using NBS media signaling channel 1612. In one embodiment, media signaling channel 1612 is used to handle push-to-talk requests and releases, arbitrate between conflicting requests, i.e., floor control, declare the start and end of information transfer, manage network dormancy, track endpoint connectivity, request and exchange network status, and notify any error messages. The protocol of media signaling channel 1612 minimizes the length of the most commonly used messages and simplifies the task of interpreting replies and responding to requests while preserving flexibility for future enhancements. The protocol of media signaling channel 1612 can also retransmit requests without adversely affecting protocol state.

In one embodiment, signaling traffic on media signaling channel 1612 includes call setup and control signaling, which consists of session invite requests and acknowledgements, and media signaling, which consists of real-time floor control requests and associated asynchronous messages. Media traffic on media traffic channel 1614 includes real-time point-to-multipoint voice and/or data broadcasts. Both classes of messaging classes have unique functional attributes. In addition, each CD may issue a Domain Name Service (DNS) client request to map a fully qualified DNS hostname onto an internet address.

In one embodiment, call setup and call control signaling is performed according to SIP semantics. Although SIP is transmitted using the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), in one embodiment, each CD uses UDP to perform SIP-based signaling functions. Also, each CM wishes to receive SIP signaling requests over UDP. Real-time signaling may occur over the CM and dynamic UDP/IP interfaces on the respective CDs. Other signaling may occur using SIP over a fixed TCP/IP interface between the CM and the CD.

PTT latency

In one embodiment, resources in the infrastructure, such as Base Transceiver Subsystems (BTSs), Base Station Controllers (BSCs), Interworking (IWFs), and radio links are actively allocated to a Mobile Station (MS) when a packet data service is active. In an IP-based VoIP dispatch service, the packet data connection for each user remains active despite the existence of active conversations between the group participants. However, after a period of inactivity in the group communication, i.e., a "hang time," the user traffic channel may transition to a dormant state.

Transitioning to the dormant state conserves system capacity, reduces service costs and battery drain, and makes the user available to receive incoming regular voice calls. For example, when a user is in an active packet data call, he is generally considered "busy" for receiving incoming voice calls. If the user's packet data call is dormant, the user can receive an incoming voice call. For this reason, it is desirable to transition a packet data call to a dormant state after a period of packet data inactivity.

When a packet data call is active, Radio Frequency (RF) energy is transmitted by the mobile station, albeit at a low level, even though no data packets are being exchanged, thereby maintaining synchronization and power control with the base station. These transmissions can cause significant power leakage on the phone. However, in the dormant state, the phone may not perform any RF transmission. To conserve phone power and extend battery life, the hang time may be set to transition the phone to sleep mode after an extended period of no data transmission.

Although the packet data service is active for all users, the PTT request, which is an IP datagram sent between the MS and the scheduling server, has a low latency. However, if the user channel has been transitioned to the dormant state, the PTT latency may be longer. During packet data dormancy, state information associated with the packet data session, including the mobile IP address, may be maintained. However, state information associated with layers below PPP, such as the physical traffic layer, may be released and/or deallocated.

In some infrastructures, to wake up a dormant data connection, traffic channels must be reallocated, resources must be reallocated, and the Radio Link Protocol (RLP) layer must be reinitialized. The effect of this is that when a talk group has not spoken for a while, the PTT latency of the first talk spurt is typically much longer than the PTT latency of the subsequent talk spurt when the user presses his PTT button to request the floor. While this is relatively infrequent, it can affect the utility of the service and should be minimized.

In one embodiment, to reduce PTT latency, group call signaling, such as floor control requests, floor control responses, and dormancy wakeup messages, may be sent on some available common channels without waiting for dedicated traffic channels to be re-established. Such common channels are always available regardless of the state of the mobile station and are not required to be requested and reassigned each time a user wishes to initiate a group call. Thus, group call signaling can be exchanged even when the mobile stations are dormant, which enables dedicated traffic channels to be re-established for talker and listener mobile stations in parallel.

In one embodiment, a calling mobile station may send a floor control request to the wireless infrastructure over some available reverse common channel, such as a reverse access channel and a reverse enhanced access channel. The calling mobile station may also receive a response to the floor control request on some available forward common channels, such as a forward paging channel and a forward common control channel. In one embodiment, the dormant listener mobile station may receive the dormant wake-up message on some available forward common channel (such as a forward paging channel and a forward common control channel).

Short data burst call signaling messages

In one embodiment, the substantial reduction in actual total sleep wake up latency and PTT latency observed by the speaker IS achieved by using Short Data Burst (SDB) messages provided in "TIA/EIA/IS-2000 Standards for cdma2000 Spread Spectrum Systems," which IS hereinafter referred to as the "cdma 2000 standard. In an embodiment, SDB messages may be sent over both a dedicated physical channel, such as a forward Fundamental Channel (FCH) or a forward dedicated common control channel (F-DCCH), or a common physical channel, such as a reverse access channel (R-ACH), a reverse enhanced access channel (R-EACH), a forward common control channel (F-CCCH), or a Paging Channel (PCH). SDB messages may be transported by Radio Burst Protocol (RBP), which maps the message onto appropriate and available physical layer channels. Since SDB messages may carry arbitrary IP traffic and may be sent on common physical channels, SDB messages provide a mechanism to exchange group call signaling when the mobile station of the calling client does not have any dedicated traffic channels.

Mobile station originated call signaling messages

In one embodiment, the media signaling messages may communicate IP datagrams over a reverse link or mobile-originated link. The client mobile station will quickly notify the MCU whenever the user requests the floor and the dedicated reverse traffic channel is not immediately available. Assuming that the client mobile station releases all dedicated traffic channels, the client mobile station will immediately forward the floor control request over the reverse common channel of the wireless infrastructure, which can relay the request to the MCU. For example, either the reverse access channel or the reverse enhanced access channel may be used to send such messages when a dedicated reverse channel is not available. In one embodiment, the client mobile station may send the floor request message to the MCU as an SDB message.

Referring to fig. 4, in an embodiment, a client MS may send a PTT floor request 404 over a reverse common channel, such as an access channel or an enhanced access channel, before attempting to re-establish its dedicated traffic channel. In an embodiment, the client MS may send the PTT floor request 404 in an SDB message, regardless of the channel used.

The client MS then starts re-establishing its dedicated traffic channel, for example by performing a "service option 33 re-origination". The client MS can also initiate Radio Link Protocol (RLP) synchronization. In one embodiment, the client MS may re-establish its dedicated traffic channel and preferably synchronize the RLP in parallel with sending the PTT floor request 404.

Thus, using available reverse common channels and/or SDB features to signal a floor control request to the CM when the mobile station has no active dedicated traffic channel reduces the total time required to wake up a participating mobile station. Although the speaker client may not receive confirmation that its floor request has been granted before the speaker's forward traffic channel is reestablished, being able to quickly notify the CM to begin waking up a participating listener reduces overall latency.

Referring to fig. 4, the wireless infrastructure may send a PTT floor control request 404 to a Packet Data Serving Node (PDSN) and then to the MCU. In an embodiment, upon receiving the floor control request, the MCU may arbitrate the request, burst a media signaling wake-up message (trigger) to a group of target participants (listeners), and/or trigger the reconstruction 414 of the participants' traffic channels (listeners). If the MCU grants the PTT floor request, the MCU may send a PTT floor grant 408 to the client MS. In one embodiment, if the client's dedicated traffic channel has not been re-established, the RF may send a PTT floor grant 408 to the client MS on available forward common channels, such as a forward paging channel and a forward common control channel. In an embodiment, the infrastructure may send PTT floor grant 408 in SDB form to client MS, whatever channel is used.

In one embodiment, the MCU may wait for the sleep response timer to expire before responding to the PTT floor control request. If the sleep response timer for a group is set to zero, the CM can immediately respond to the floor control request. In one embodiment, if the client MS has completed re-establishing its traffic channel and RLP synchronization, the client MS will stream 416 media to the MCU, which has been buffered 412 in the client MS.

Network originated call signaling messages

In one embodiment, upon receiving a floor control request, the MCU may burst a media signaling wake-up message to a group of target participants (listeners) and trigger the re-establishment of the participants' traffic channels (of the listeners). If the sleep response timer for the group is set to zero, the MCU will respond immediately to the floor control request. In one embodiment, if the talker has started to re-establish its traffic channel immediately after sending the PTT request, the traffic channels of the caller and listener are preferably re-established in parallel.

Referring to fig. 4, after the MCU receives the PTT floor control request, the MCU may send a wake-up trigger 414 directed to the target listener. The MCU may determine whether a packet data session exists for the target mobile station and forward the trigger packet to the appropriate infrastructure element, e.g., a base station. The infrastructure may page each individual target mobile station to begin re-establishing its dedicated traffic channel. The target mobile station may then begin re-establishing its dedicated traffic channel, for example by performing a "service option 33 re-origination". The target mobile station can also begin Radio Link Protocol (RLP) synchronization. In one embodiment, the target mobile stations may re-establish their dedicated traffic channels and synchronize their RLPs, preferably in parallel with the same functions performed by the client MS.

In one embodiment, after the target mobile station has completed re-establishing its dedicated traffic channel and synchronizing its RLPs, the target mobile station may send a wakeup reply 422 to the MCU indicating that the target mobile station is ready to receive media. The MCU may send a speaker announcement to the client mobile station MS before streaming 420 media to the target mobile station MS, which has been buffered 418 in the MCU.

In one embodiment, the MCU may send the wake-up trigger 414 to the target listener over some available common forward channels, such as the forward paging channel and the forward common control channel, when the target listener's traffic channels have not been re-established. In an embodiment, the MCU may send the wake trigger 414 to the target listener in SDM form, whatever channel is used. If the PTT floor control request is sent as an SDB message on the speaker's reverse common channel and the sleep response timer for the target group is set to zero at the MCU, the actual PTT latency at the speaker client can be reduced to the time required to send an SDB request message on the reverse link before an SDB response message on the forward link.

Network interface for call signaling messages

To determine which network-originated special traffic, e.g., SDB payloads, to send for idle mobile stations that do not have dedicated traffic channels, certain infrastructure policies or interfaces may be implemented to distinguish this special traffic from other traffic.

In a first embodiment, IP datagrams may be filtered according to their size, since SDB messages may carry limited user payload. IP datagrams smaller than a predetermined size can be sent as SDB messages if destined for a mobile station that does not have a dedicated traffic channel. A group communication system may use such a filter because the application floor request response message is small, e.g., 34 bytes including the IP header.

In a second embodiment, an infrastructure manufacturer may define an IP-based service for encapsulating IP traffic for delivery to a mobile station. An IP server that learns of the service may send a small IP, e.g., UDP, datagram, preferably encapsulated with an IP header, to the service for delivery to a mobile station suspected of not having a dedicated traffic channel. The group communication system may use the service to indicate to the infrastructure that the floor request response message may be delivered to the requesting client MS in SDB form. Coordination of SDB traffic with pending paging or service origination requests is also important to ensure fast and reliable delivery of user traffic.

In a third embodiment, the IP server may send a special IP, e.g., UDP, datagram with IP header for delivery to mobile stations suspected of not having a dedicated traffic channel. The IP server may tag the IP datagram, for example by specifying a special value in the IP header, for instructing the infrastructure to deliver the IP datagram to the client mobile station. The group communication system may use the service to indicate to the infrastructure: the floor request response message is delivered to the requesting client mobile station MS in SDB form. In a third embodiment, UDP or TCP port ranges may be reserved for the delivery of special IP datagrams, such as SDB messages.

Mobile station initiated service origination and paging

In one embodiment, the client may send a floor control request 404 in the form of an SDB immediately followed by a service origination request issued to the wireless (e.g., CDMA) infrastructure for quickly re-establishing its traffic channel. However, if the dormancy response timer is set to a small value, RD can respond quickly to the floor control request and send a response back to the client 408. If the response arrives at the infrastructure at an early stage in the service origination transaction, the infrastructure notices that the talker mobile station does not have any active traffic channel and may attempt to page the talker mobile station with the response. However, this paging action may abort the service origination transaction that is already in progress. In one embodiment, the talker mobile station may respond to the page by ensuring that a floor control response message is delivered to the talker and requesting service origination again, but may experience unnecessary delay in re-establishing the talker's traffic channel due to the suspended original service origination attempt.

In a first embodiment, to avoid race conditions between the service origination process and paging, the RD may be configured not to respond immediately to floor control request 404. Thus, the sleep response timer can be adjusted to cause the MCU to send the response 408 to the talker MS after the service origination process is completed.

In a second embodiment, the coordinating PDSN receives the response 408 and the Mobile Switching Center (MSC) responds to the talker's service origination request. That is, if the PDSN determines that the packet data service origination process for the talker mobile is already in progress when the response 408 arrives at the infrastructure, the MSC defers paging the talker mobile. The PDSN may buffer the response and send it over the talker mobile's forward traffic channel once the service origination process is complete. Alternatively, if the service origination process is still in progress, the MSC may send the response to the talker mobile as an SDB message.

In the third embodiment, the talker mobile station can avoid the race condition by not issuing a service origination request until the talker mobile station receives a response to the floor control request. In one embodiment, since the talker mobile has no active dedicated traffic channel, the MCU may send a response to the talker mobile on some available forward common channels, such as a forward paging channel and a forward common control channel. In one embodiment, the MCU may send the response to the talker ms in SDB. The talker mobile may rely on the floor control response generated by the RD to trigger its traffic channel reactivation in the same manner as the wake-up request sent by the MCU triggers the listener mobile's traffic channel reactivation. While avoiding the possibility of simultaneous mobile-initiated service origination and network-initiated mobile paging, a race condition is also avoided.

Cache network initiated packet data triggering

IP datagrams may be lost, either by the network in general or by the wireless infrastructure in particular, that include a wake-up trigger 414, the wake-up trigger 414 reaching the wireless (e.g., CDMA) infrastructure and destined for a listener's mobile station that does not have a dedicated traffic channel. In one embodiment, the wake-up trigger 414 sent to the listener's mobile station is re-sent progressively according to a defined schedule until the listener's response or the group's wake-up timer expires. For example, the wake-up trigger 414 may be retransmitted every 500 milliseconds. However, retransmitting the wake-up trigger 414 at this rate may result in a maximum delay of up to 500 milliseconds, or an average delay of 250 milliseconds, between re-establishing the listener traffic channel and the arrival of the next wake-up trigger directed to the listener at the infrastructure.

In an embodiment, the wake-up trigger 414 sent by the MCU may be buffered by the infrastructure or another entity in the network and delivered to the target mobile station 414 as soon as the target mobile station has re-established its traffic channel. This eliminates the need for the MCU to resend the wake-up request and reduces the total sleep wake-up time. In contrast to resending the wake-up trigger 414 at 500 milliseconds, caching the wake-up trigger 414 eliminates up to 500 milliseconds of delay from the total sleep wake-up time.

Media buffering

In one embodiment, by buffering the media before re-establishing the dedicated channel between the client and the listener, the user may be allowed to begin speaking after floor control is requested. By buffering the speaker's speech, the system allows the speaker to begin speaking before the listener's traffic channel is fully re-established. This allows the speaker to start speaking earlier, reducing its apparent PTT latency. Since the listeners do not experience PTT latency, their experience is not affected, i.e., PTT latency is shifted from the speaker to other parts of the system. The speaker may wait to receive a response from the listener to his first talk burst, but as mentioned above, he has desired to respond to his first talk burst for a longer time than to the subsequent talk burst that occurs when he is engaged in an active conversation. The buffering of the first talk burst of the speaker can be done either at the MCU side or at the client MS side.

Buffering at MCU terminal

In one embodiment, the MCU may buffer the first talk burst of the speaker. After the user has pressed his PTT button and has re-established the user's traffic channel, he may be allowed to communicate with the MCU. At this point, the MCU buffers 418 the speaker's voice for future transmission to the target listener, since the listener traffic channel has not yet been established. MCU buffering can reduce the apparent PTT latency noticed by the speaker to approximately the time required to set up the speaker's traffic channel. Fig. 17 shows MCU-side buffering according to an embodiment, as follows:

(1) while no call is in progress, the traffic channels of the originator and target users are dormant.

(2) The user presses the PTT button. The server receives a "set up group call" request from the client.

(3) The floor is granted to the user after the client receives a "set up in progress" response from the server or after a configurable delay (1 second) and the buffering of the user media begins.

(4) The server begins the process of re-establishing the packet data traffic channel for the target user.

(5) The server sends a "group call announcement" message to the client via SDB.

(6) The client successfully re-establishes the traffic channel and begins sending buffered media to the server.

(7) The client transmits the media stream to the server.

(8) The traffic channel of the target user has been re-established (meeting the "target response threshold").

(9) The user releases the PTT button. The client stops buffering the media.

(10) The client completes transmitting the buffered media stream to the server, requesting the server to release the floor.

(11) The server sends a floor release acknowledgement to the client.

Client buffering

In an embodiment where a short apparent latency is desired, a speaker may be allowed to begin speaking before its traffic channel is re-established. Since the client mobile station has not yet communicated with the MCU, a signal is made by the client mobile station to the speaker to begin speaking. If the speaker is allowed to speak before its traffic channel is re-established, the client mobile station may buffer 412 the speech. Because communication with the CM has not been established, "optimistically" grants permission to talk. FIG. 18 illustrates client buffering, according to one embodiment, as follows:

(1) without the call in progress, the traffic channel of the originator is dormant.

(2) The user presses the PTT button. The client sends a "set up group call" request to the server via the SDB.

(3) The client begins the process of re-establishing the packet data traffic channel.

(4) The floor is granted to the user after the client receives a "set up in progress" response from the server or after a configurable delay (1 second) and the buffering of the user media begins.

(5) The client receives a "group call announcement" message from the server through the SDB.

(6) The client successfully re-establishes the traffic channel.

(7) The client transmits the buffered media stream to the server.

(8) The user releases the PTT button. The client stops buffering the media.

(9) The client completes transmitting the buffered media stream to the server, requesting the server to release the floor.

(10) The client receives confirmation of the floor release from the server.

In an embodiment, MCU buffer 418 and client buffer 412 can operate concurrently. Client buffering can make the apparent PTT latency smaller. In one embodiment, the client mobile station may buffer media to control the apparent PTT latency experienced by the user. The combination of mobile-originated SDB and client media buffering can reduce the latency associated with re-establishing an active traffic channel.

Thus, the disclosed embodiments provide for a dispatch model that supports at least two classes of dispatch calls: chat room models and ad hoc models. In the chat-room model, groups are predefined, which can be saved on a dispatch server. However, in the ad hoc model, groups may be defined and/or modified in real time.

The disclosed embodiments also provide for: by exchanging group call signaling even when the mobile station is dormant and no traffic channel is active, there is a significant reduction in the actual total dormant wakeup and PTT latency. The method and apparatus provides for exchanging group call signaling using Short Data Burst (SDB) message signaling. The method and apparatus provides for re-establishing dedicated traffic channels for talker mobiles and dormant listener mobiles in parallel.

In another embodiment, the sleep-wake latency in a group communication network may be reduced by: the method includes caching a network-initiated wake-up trigger directed to the target listener and sending the wake-up trigger to the target mobile station once the target mobile station has re-established its traffic channel.

In another embodiment, simultaneous service origination and paging of a mobile station operating in a group communication network is avoided by sending a response to a floor control request after the service origination process is completed. In an embodiment, the response to the floor control request may be in the form of SDB if the service origination process is not complete. In another embodiment, the service origination procedure of the source communication device is initiated after the response is sent to the source communication device.

Claims (16)

1. In a communication device, a method for terminating a user from a group call in a group communication network, the method comprising:

receiving an indication from a user wishing to terminate participation in the group call; and

a request is sent to a server to terminate the user from the group call.

2. The method of claim 1, further comprising: a response is sent to the user indicating that the user has been terminated from the group call.

3. In a communication device, a computer-readable medium embodying a method for terminating a user from a group call in a group communication network, the method comprising:

receiving an indication from a user wishing to terminate participation in the group call; and

a request is sent to a server to terminate the user from the group call.

4. The computer-readable medium of claim 3, wherein the method further comprises: a response is sent to the user indicating that the user has been terminated from the group call.

5. A communication device for terminating a user from a group call in a group communication network, comprising:

means for receiving an indication from a user wishing to terminate participation in the group call; and

means for sending a request to a server to terminate the user from the group call.

6. The communication device of claim 5, further comprising: means for sending a response to the user indicating that the user has been terminated from the group call.

7. A communication device for terminating a user from a group call in a group communication network, the communication device comprising:

a receiver;

a transmitter; and

a processor communicatively coupled to the receiver and transmitter, the processor capable of:

receiving an indication from a user wishing to terminate participation in the group call; and

a request is sent to a server to terminate the user from the group call.

8. The communication device of claim 7, wherein the processor is further capable of sending a response to the user indicating that the user has been terminated from the group call.

9. In a server, a method for terminating a user from a group call in a group communication network, the method comprising:

receiving a request to terminate a user from a group call;

terminating the user from the group call; and

sending a response indicating that the user has been terminated from the group call.

10. In a server, a computer-readable medium embodying a method for terminating a user from a group call in a group communication network, the method comprising:

receiving a request to terminate a user from a group call;

terminating the user from the group call; and

sending a response indicating that the user has been terminated from the group call.

11. A server for terminating a user from a group call in a group communication network, comprising:

means for receiving a request to terminate a user from a group call;

means for terminating the user from the group call; and

means for sending a response indicating that the user has been terminated from the group call.

12. A server for terminating a user from a group call in a group communication network, the server comprising:

a receiver;

a transmitter;

a processor communicatively coupled to the receiver and transmitter, the processor capable of:

receiving a request to terminate a user from a group call;

terminating the user from the group call; and

sending a response indicating that the user has been terminated from the group call.

13. In a server, a method for terminating a group call in a group communication network, the method comprising:

determining when a predetermined period of time expires in which no media is delivered in the group call session;

declaring to each participating member in the group call that the group call is to be terminated; and

terminating the group call upon receiving an acknowledgement from each participating member in the group call.

14. In a server, a computer-readable medium embodying a method of terminating a group call in a group communication network, the method comprising:

determining when a predetermined period of time expires in which no media is delivered in the group call session;

declaring to each participating member in the group call that the group call is to be terminated; and

terminating the group call upon receiving an acknowledgement from each participating member in the group call.

15. A server for terminating a group call in a group communication network, comprising:

means for determining when a predetermined period of time expires in which no media is delivered in the group call session;

means for declaring to each participating member in the group call that the group call is to be terminated; and

means for terminating the group call upon receiving an acknowledgement from each participating member in the group call.

16. A server for terminating a user from a group call in a group communication network, the server comprising:

a receiver;

a transmitter; and

a processor communicatively coupled to the receiver and transmitter, the processor capable of:

determining when a predetermined period of time expires in which no media is delivered in the group call session;

declaring to each participating member in the group call that the group call is to be terminated; and

terminating the group call upon receiving an acknowledgement from each participating member in the group call.