A method and an apparatus for adding a new member to an active group call in a group communication network.

(54) Title: A METHOD AND A DEVICE FOR ADDING A NEW MEMBER TO AN ACTIVE GROUP CALL IN A GROUP COMMUNICATIONS NETWORK.

(54) Title: A METHOD AND AN APPARATUS FOR ADDING A NEW MEMBER TO AN ACTIVE GROUP CALL IN A GROUP COMMUNICATION NETWORK.

(57) Summary

A method and apparatus are provided for adding a member to an active call on a group communications network to receive a list of members from a user and send a request to a server to add the list of members to the call of active group. The method and apparatus are further provided to announce to each member in the list of members that they are being added to the group call, receive acknowledgment from a member who wishes to participate in the group call, and advance media to the member. The method and apparatus also provide a significant reduction in current total latency wake-up time and latency when exchanging group call signaling even when mobiles are asleep and no traffic channels are active.

(57) Abstract

A method and apparatus for adding a member to an active cali in a group communication network provides for receiving a member list from a user and sending a request to a server to add the member list to the active group cali. The method and apparatus further provides for announcing each member in the member list that they are being added to the group cali, receiving acknowledgment from a member who wishes to particípate in the group cali, and forwarding media to the member. The method and apparatus also provides for a significant reduction in the actual total dormancy wakeup time and latency by exchanging group cali signaling even when mobiles are dormant and no traffic channel is active.

<img file="MXPA04007859A_D0001.tif" />

(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) (43) International Publication Date (10) International Publication Number

August 2003 (08/21/2003) PCT WO 03/069928 Al (51) International Patent Classification⁷: H04Q 7/28,

H04M 3/56 (21) International Application Number: PCT / USO3 / O463O (22) International Filing Date: 12 February 2003 (12.02.2003) (25) Filing Language: English (26) Publication Language: English (30) Priority Data :

10 / 076,941 14 February 2002 (02/14/2002) US (71) Applicant: QUALCOMM INCORPORATED [US / USJ; 5775 Morehouse Drive, San Diego, CA 92121 (US).

(72) Inventors: CROCKETT, Douglas M .; 4576 44fh Street, San Diego, CA 92115 (US). ROSEN, Eric C .; 611 Calle Paula, Solana Beach, CA 92075 (US). MAGGENTI, Mark, 2480 Cordero Road, Del Mar, CA 92014 (US).

(74) Agents: WADSWORTH, Philip R. et al .; QUALCOMM Incorporated, 5775 Morehouse Drive, San Diego, CA 92121 (US). ~ (81) Designated States (national): ΛΕ, AG, AL, AM, ΑΊ ', AU, AZ, BA, BB, BG, BR, BY. BZ, CA, CU, CN, CO, CR, CU, CZ, DE, DK, DM, DZ, EC, EE, ES, FI, GB, GD, GE, GH, GM, JíR, 11U, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, OM, PII, PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, TJ, TM, TN, TR, 'ΓΓ, TZ, UA, UG, UZ, VC, VN, YU, ZA , ZM, ZW.

(84) Designated States (regional): ARIPO patent (Gil, GM, KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, FR, GB, GR, HU, 1E, IT, LU, MC, NL, PT, SE, SI, SK, TR), OAP1 patent (BF. BJ, CF, CG, Cl, CM, GA, GN, GQ, GW, ML, MR, NE, SN, TD, TG) .

Published:

- with international search repon - befare the expiration of the lime limit for amending the claims and lo be republished in the event of receipl of amendmenls

[Conlinued on next page] (54) Title: A METHOD AND AN APPARATUS FOR ADD1NG A NEW MEMBER TO AN ACTIVE GROUP CALL IN A GROUP

COMMUNICATION NETWORK wo 03/069928 Al IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIISIIIIIIIIIII

<img file="MXPA04007859A_D0002.tif" />

CLIENT

SELECTS CALL ¹ FROM CALL HJSTORY ¹¹⁰² AND PRESSES PTT

YOU AREBEING ADDED TO THE GROUP

OTHER PARTIC1PA.NTS TALK SPURT

REGIONAL DISPATCHER

REGIONAL MCU

1104

- ^ GROUPCALL REQUEST (VIA SDB) ~~

CALL IN PROGRESS (VIASDB)

1108

GROUP IS RUNNING

ADD USER

1110

ANNOUNCE GROUP CALL

<img file="MXPA04007859A_D0003.tif" />

ACKNOWLEDGE

<img file="MXPA04007859A_D0004.tif" />

HALF

1112

<img file="MXPA04007859A_D0005.tif" />

(57) Abstract: A method and apparatus for adding a metnber to an active cali in a group communication network provides íor receiving a member list from a user and sending a request to a server to add the member list to the active group cali. The method and apparatus fu rther provides for announcing each member in the member list that they are being added lo the group cali, receiving acknowledgment from a member who wishes to particípale in the group cali, and forwarding media to the member. The method and apparatus also provides for a significant rcduction in the actual total dormaney wakeup lime and lateney by exchanging group cali signaling even when mobiles are dormant and no trafile channel is active.

WO 03/069928 Al ΗΙ ·· ΒΙΠΙΜ

For two-letler codes and other abbreviations, refer to the Guidance Notes on Codes and Abbreviations appearing at the beginning of each regular issue of the PCT Gazette.

<img file="MXPA04007859A_D0006.tif" />

A METHOD AND APPARATUS FOR ADDING A NEW MEMBER TO AN ACTIVE GROUP CALL IN A GROUP COMMUNICATIONS NETWORK

FIELD OF THE INVENTION

The present invention relates to point-to-multi-point communication systems. More specifically, the present invention relates to a method and apparatus for adding 10 new members to an active group call in a group communication network.

BACKGROUND OF THE INVENTION

A wireless class of service 15 intended for fast, efficient, one-to-one or one-to-many (group) communication has existed in various forms for many years. In general, these services have been half duplex, where a user presses a push-to-talk (PTT) button on their telephone / radio to initiate a chat. Pressing the button to key your radio, in some implementations, or in a moderated system, where communications occur through a server of some kind, indicates the user's request for the ground. If floor, or speaker permission is granted, then the user generally speaks for a few seconds, after which he releases his PTT button, and other speakers 5 may request floor. Communication is generally from one speaker to a group of listeners, but can be one-to-one. This service has traditionally been used in applications where one person, a dispatcher, needs to communicate to a group of people, such as field service personnel or taxi drivers, which is where the dispatch name for the service comes from.

Similar services have been offered over the Internet and are generally known as voice chat. These services are typically implemented as personal computer applications that send vocoder frames in packet Internet Protocol (IP), that is, Voice over IP (VoIP) service, to a central group chat server, or possibly client to customer in a point-to-point service.

A key feature of these

- 3 services is that communication is fast and spontaneous, generally initiated by simply pressing a PTT button, without going through a typical dial and ring sequence. Communication in this type of service is generally very short, with individual chatter pulses generally on the order of several seconds, and conversations lasting possibly a minute or less.

The time delay between when the user requests the floor and when he receives a positive or negative confirmation from the server that has the floor and can start speaking, which is known as the PTT latency, is a critical parameter for the systems of half duplex group communications. As mentioned previously, dispatch systems place a priority on short, fast conversations, which makes the service less efficient if the PTT latency is extended.

Existing group communication infrastructures provide limited opportunities to significantly reduce PTT latency, that is, the current PTT latency may not possibly be reduced below the time required to re-establish traffic channels within dormant packet data sessions. Furthermore, the loudspeaker and listener traffic channels are formed in series, because the only mechanism available to start waking up a sleeping group is to wait for the loudspeaker traffic channel to re-establish in order to signal to the server. Currently, there is no mechanism to send mobile-originated user signaling data on anything other than a traffic channel - a limitation that requires that traffic channels be re-established before any communication between clients and the server can take place.

Therefore, there is a need for mechanisms to reduce both the apparent PTT latency experienced by the speaker and the total time required to re-establish traffic channels to engage mobile without negatively impacting system capacity, customer battery life. , or other resources.

In an office model, the

I

- Communication between endpoints takes place in virtual groups where the voice of a speaker is transmitted to one or more listeners. A single instance of this type of communication is commonly referred to as a dispatch call or simply a call. A call is an instantiation of a group, which defines the characteristics of the call and is, in essence, a list of members with some associated information, such as a group name or group identification. A member list is a list of one or more users who are invited to participate in the call.

There is a need for a dispatch model to support both the chat room model and the ad-hoc model of group call services. In the Chat room model, groups are pre-defined, which can be stored on the dispatch server. However, in the ad-hoc model, groups can be defined and / or modified in real time.

BRIEF DESCRIPTION OF THE INVENTION

The described modalities provide a novel and improved method in a device

I

- 6 communications to add a member to a group call active on a group communications network, which includes receiving a list of members from a user and sending a request to a server to add the list of members to the call active group.

In another aspect of the invention, a computer-readable medium in a communication device incorporates a method for adding a member to an active group call in a group communication network, the method including the aforementioned steps.

In another aspect of the invention, a communication device for adding a member to an active group call in a group communication network includes means for receiving a list of members from a user and means for sending a request to a server at order to add the member list to the active group call.

In another aspect of the invention, a communication device for adding a member to an active group call on a network!

The group communication 7 includes a receiver, a transmitter, and a processor communicatively coupled with the receiver and the transmitter. The processor is capable of receiving a member list from a user and sending a request to a server to add the member list to the active group call. In one aspect, the communication device is a push-to-talk (PTT) device.

The described modes also provide a novel and server-enhanced method of adding a member to an active group call on a group communications network, including the steps to receive a request to add a list of members to a group call. Active group and add the member list to the active group call. In one aspect, the method further includes announcing to each member in the list of members that they are being added to the group call.

In another aspect of the invention, a computer-readable medium on a server incorporates a method for adding a member to an active group call in a group communications network, the method including the aforementioned steps.

In another aspect of the invention, a server for adding a member to an active group call in a group communications network includes means for receiving a request to add a list of members of an active group call and means for adding the list. of members to the active group call. In one aspect, the server further includes means for announcing to each member in the list of members that they are being added to the group call.

In another aspect of the invention, a server for adding a member to an active group call in a group communications network includes a receiver, a transmitter, and a processor communicatively coupled to the receiver and transmitter. The processor is capable of receiving a request to add a list of members to an active group call and to add the list of members to the active group call. In one aspect, the processor is also capable of announcing to each member in the list of members that they are being added to the group call.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become apparent from the following detailed description set forth below when taken in conjunction with the drawings in which similar reference characters are correspondingly identified throughout and where:

Figure 1 illustrates a group communication system;

Figure 2 illustrates how various applications interact with each other;

<td></td><td>The</td><td>Figure 3</td><td>illustrates</td><td>a</td><td>process</td><td>of</td>

<td>record</td><td>of</td><td>Username</td><td>by way</td><td>of</td><td>example</td><td>of</td>

<td>agreement</td><td>with</td><td colspan="2">a modality;</td><td></td><td></td><td></td>

<td></td><td>The</td><td>Figure 4</td><td>illustrates</td><td>a</td><td>process</td><td>of</td>

local, intra-regional call configuration, by way of example, according to a modality;

Figure 5 illustrates an exemplary remote intra-regional call setup process in accordance with one embodiment;

Figure 6 illustrates an exemplary local, inter-regional call setup process in accordance with one embodiment;

Figure 7 illustrates an exemplary remote inter-regional call setup process according to one embodiment;

Figure 8 illustrates an exemplary process for abandoning a group call in accordance with one embodiment;

Figure 9 illustrates an exemplary process for terminating a group call in accordance with one mode;

Figure 10 illustrates an exemplary process for sending an alert for a group call according to one modality;

Figure 11 illustrates an exemplary process for late joining a group call in accordance with one embodiment;

Figure 12 illustrates an exemplary process for pre-emptying a speaker in accordance with one embodiment;

Figure 13 illustrates an exemplary process for adding new members to an active group call according to one embodiment;

Figure 14 illustrates an exemplary process for removing participants from a group call according to one mode;

Figure 15 illustrates an exemplary process for deleting a user record in accordance with one embodiment;

Figure 16 illustrates how various communication devices interact with a communication manager in accordance with one embodiment;

Figure 17 illustrates buffering means in a communication manager part according to one embodiment; Y

Figure 18 illustrates buffering means on the client side according to one embodiment.

_ _ __ _ _ ___ _ _ ' * DETAILED DESCRIPTION OF THE INVENTION

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

Figure 1 illustrates an exemplary functional block diagram of a group communication system 100. The group communication system 100 is also known as a push-to-talk (PTT) system, a network broadcast service (NBS), a dispatch system, or a point-to-multi-point communication system. In one embodiment, the group communications system 100 includes application server components, such as dispatchers, location servers, media control unit (MCU) complexes, usage log servers, and Internet Protocol (IP) clients. ) (wireless and / or wired devices with IP connectivity). The application server components can be deployed in either a centralized deployment or a regionalized deployment, based on the functionality of the component. The centralized deployment may include a local dispatcher (HD) 102, a local location server (HLS) 104, and a user / group database 106. These components can be centrally located in the service provider's network and can be accessible by regional deployments. The 15 centralized components can be used to locate tracked users and to initiate inter-regional group calls. A regionalized deployment 108, 110 may include a regional location server (RLS) 20 112, a regional dispatcher (RD) 114, a regional media control unit (MCU) complex 116, and a regional usage registration server ( ULS) 118.

Regional deployments can be distributed on the service provider's network

I

- 14 to ensure network delays associated with call setup are kept to a minimum, for purposes of satisfying the instant response requirement. Spreading the call load across regionalized systems also ensures that suitable scalability schemes can be developed to support a large number of users. The regionalized application server components provide user registration, intra-regional call settings, and initiation and sending of alerts for users who are registered in the region.

The group communication devices (clients) 120, 122, which may be deployed on a cdma2000 handset, for example, request a packet data session using a conventional data service option and use this session to record its address from IP with the application server and perform group call initiations. In one embodiment, the application server components 108, 110 connect to the service provider's packet data service nodes (PDSNs). Clients 120 and 122, after requesting a packet data session from the wireless infrastructure, have IP connectivity to application server components 108, 110 via PSDNs.

After power-up, clients 120, 122 can request a packet data session using the data service option. As part of establishing the packet data session, the client is assigned an IP address. At this time, the client also receives the address of a Domain Name Service (DNS) server 124. Client 120, 122 queries DNS server 124, for example, using a service record lookup (SRV), to find the address of RLS 112. After locating RLS 112, client 120, 122 can perform a registration , notify the application server of your location information, for example, IP address. Registration can be done using an IP protocol, such as Session Initiation Protocol (SIP) over User Datagram Protocol (UDP). The client IP address 120, 122 can be used to contact the client when the user is invited to a group call.

In one embodiment, after registration is complete, the customer can perform another DNS SRV record query to find the address of the regional dispatcher 114. The customer contacts the regional dispatcher anytime the user requests to start a call or send an alert. The interface between the regional dispatcher 114 and the client 120, 124 may be the signaling protocol over UDP.

Once a group call is established, the client 120, 114, and the MCU complex 116 exchange media and signaling messages. In one embodiment, the media can be sent between the call parties and the MCU complex 116 using a real time protocol (RTP) over UDP. The signaling messages can also be signaling protocol over UDP. These protocols and the functionality they provide are described later.

!

- 17 Components

The group communication system 100 may include the IP endpoints that contain the client software and the regionalized and centralized server components that are required to offer the group communication service. Group communications clients and application server components are described in more detail in the following sections.

Customers

The group communications client 120, 122 may run at any IP endpoint that has access to the appropriate vocoder (s). IP endpoints can include applications that run on a wireless system, for example, cdma2000, an application development platform, for example, a binary runtime environment for wireless computers (BREW), and personal computers.

The client can include a software application, which can be developed using BREW, and interfaces to mobile station modem (MSM) software, which can be downloaded to the client that contains the BREW environment. BREW is a platform that allows developers to create applications that can operate on client communication devices. BREW provides a layer of isolation to the application developer, enabling direct contactless application development in MSM software and original equipment manufacturer (OEM) software. This allows applications to develop rapidly and evolve independently of MSM and / or OEM software. It also enables applications to be downloaded to any device that contains the BREW environment. As shown in Figure 2, customer group communications applications software 202 can run in parallel with other applications 204, 206, 208, 210. Although these services can be offered directly through the OEM 212 and MSM 214 interfaces, BREW provides isolates from application modifications to these layers.

I

This allows OEM 212 and MSM 214 to evolve separately from data applications 202, 204 206, 208, 210.

In order for the client to operate effectively on a personal computer, the personal computer may include access to a compatible vocoder, access to sound drivers, and IP connectivity to application servers.

Location Server

In one embodiment, the location server (LS) can accept and / or maintain user location information, for example, the network-level IP address, the user's physical location, such as longitude and latitude, and / or packet zone identifier, that is, a system identifier transmitted over the air on common forward channels which identifies the range of the PDSN that is providing the packet data service for that sector. In one embodiment, the LS may include a component that processes records from clients and supplies user location information to

I

- 20 other applications, such as instant messages, using a SIP interface.

The LS may include two functional elements, the regional location server (RLS) 112 and the local location server (HLS) 104. The RLS 112 may be deployed on a region-by-region basis and the HLS 104 may be centralized. The details of these elements and their functions are described below.

Regional Location Server

The RLS 112 can process and maintain records from customers located within its region. In one embodiment, RLS 112 is a conventional SIP-based LS, with associated storage for user location information. As part of maintaining the record entries, the RLS 112 can check the expiration date, expiration fields, for each record. The RLS ensures that expired entries are removed, and both the regional dispatcher (RD) and the HLS are notified of the removed entries.

- 21 As described above, clients can perform an IP registration in order to notify the application server of their location. Clients can keep their records for the duration of their availability to the group communications service. Clients can perform re-registrations when the client's IP address changes and when the registration is about to expire.

When the customer registers or re-registers, the RLS 112 can notify its associated RD 114. This RD 114 allows user data to be pre-loaded in preparation for call setup requests, thus reducing call setup time. RD 114 can hide user location information, eliminating the need for RD 114 to contact RLS to retrieve user location information during call setup.

RLS 112 can notify RD 114 in the event that user location information is updated or deleted from RLS 112. This ensures that RLS 112 and RD 114 remain in sync with the most recent information about registered users within region of.

The RLS 112 may also periodically update the HLS 104 with the location information of registered users. In the event that RLS 112 sends a record to HLS 104 for a user who already has a valid record in another region, the HLS can resolve the conflict.

Local Location Server

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

If the HLS 104 is a centralized component and the RLSs communicate with it, the HLS can resolve multiple records in different regions for tracking users. The HLS 104 can receive registration information from each of the RLSs. If the HLS 104 receives multiple records for the same user, the HLS 104 may keep the most recent record and request deletion of the stale record (s) for the user from the RLSs. This in turn can activate the removal of hidden information for that RD 114 user associated with the RLS that contains the old record.

Dispatcher

The dispatcher can facilitate call setup by locating users and assigning group calls to complex 116 of medium control units (MCUs). The dispatcher is the server component that is key to meeting the requirement for instant access. To ensure lower call setup times, the dispatcher can include two functional elements with similar structure and functionality, but have different deployment strategies. These two elements, the regional dispatcher (RD) 114 and the local dispatcher (HD) 102, are described in detail in the following sections.

4

Regional Dispatcher

RD 114 can be the initial point of contact for call setup requests and alert requests. RD 114 may preload user information when it receives an indication from RLS 112 that a user has registered. Along with user information, RD 114 can hide information about group calls, which are being made in the system. RD 114 can use hidden information for users and groups during call setup to keep setup time to a minimum, ie, no database query is required.

In one embodiment, the group information buffered by the RD includes the list of group members and the address of the MCU complex 116 in which the group is running. The RD 114 can maintain the MCU address and member list for the life of the call. This helps RD 114 to quickly determine if an incoming call request contains a group definition, which is identical to

- 25 one that has an associated call already running on the system, allowing the RD to respond quickly to call setup requests and confidentially grant or deny the ground request in response.

RD 114 can grant or deny the request for ground control. RD 114 may decide whether to request MCU complex 116 to add the user to the call as a late join participant or to start a new call with the associated member list.

During the call setup request procedure, RD 114 may use the hidden user information to retrieve location information for the users specified in the call setup request. If a user cannot be located, RD 114 can ask HD 102 to locate the user. In one embodiment, if at least one or more target users are located, the RD 114 continues with the call setup. After the targets have been located, the

RD 114 can decide which MCU the call should be assigned to. This determination can be based on the IP addresses of the users in the group, including the originator.

RD 114 can handle alert requests similar to call requests. In one embodiment, the alert request is assigned to the local MCU complex 116 for processing, regardless of the location of the targets.

In one embodiment, the information in the RD buffer can be periodically written to a reliable storage mechanism so that it can be recovered in the event of failure. After recovery from RD failure, the user and group information that was written to the trusted store mechanism can be re-loaded into the buffer and the RD proceeds to validate the hidden information in conjunction with the configuration requests for Incoming call in processing.

In one embodiment, RD 114 loads user data into the local buffer after each notification of login.

I

- 27 user coming from RLS 112. By eliminating the need to perform several database queries in call setup time, RD 114 significantly reduces the amount of time it takes to validate and respond to call setup requests or alert requests.

RD 114 can access user / group database 106 during call setup 10 to expand pre-defined group addresses, if present in request, to individual user lists and, if necessary, translate alternate identifiers of users or groups, eg 15 phone numbers, chat IDs, to canonical address (es).

Local Dispatcher

The local dispatcher (HD) 102 can track the location information of registered users. The HD may contain location information for users who have registered with the RLS 112.

As described above, each

RLS 112 can notify its associated RD 114 each

I

- 28 time a user registration, re-registration, deregistration, or expiration of user registration occurs RD 114 can use this information to load or release user information in its local buffer. Each RD 114 can update the HD 102 with the user location information. Because the HD 102 receives updates from RD 114, the HD 114 can help you find users who are geographically dispersed in different regions. RD 114 can request help from HD 102 when it receives a request from a user who is not registered in the region, that is, not in the RD buffer of user information.

DNS server

In one embodiment, the group communication system 100 may use the service provider's DNS server 124 to provide the location information for the RLS 112 and RD 114 to clients. This information can be configured after each regional deployment and is regularly updated to ensure its accuracy.

In one embodiment, each client learns the DNS server address by negotiating Internet Protocol Control Protocol (IPCP) during Point-to-Point Protocol (PPP) session establishment, when it asks for a data session from package. The DNS server 124 can be advertised in this manner on a region-by-region basis. This allows the client to transition from region to region and communicate with the DNS server 124 in the same region as the client. DNS server 124 is deployed on a region-by-region basis, in conjunction with each PDSN. In one embodiment, the DNS server 124 can be updated with each RD 124 and RLS that is serving the PDSN with which the DNS server 124 is associated.

In one embodiment, the mechanism used to locate the appropriate RD 114 and RLS 112 is based on a combination of DNS and SIP addressing. The DNS Service Record (SRV) query can be performed based on the &lt;domain&gt; portion of the SIP URI under which the server is registered.

I

- 30 client. The SRV registration request may include the protocol or service, which the requester is trying to find. For example, in the case of trying to locate the RLS 112, the client can request a registration service in the DNS SRV registration query. The DNS response can include one or more valid network and port addresses for the server, which provides the requested service. DNS server 124 can be used for load balancing between servers offering the same service by allowing DNS server 124 to cycle between multiple servers when it returns responses to client requests.

User / Group Database

In one embodiment, the user / group database 106 is the central repository for user and group information. For each user, the database can include information such as user address, preemptive right classification, authentication information, user contact information, and intercept flag!

- 31 legal, which indicates if the user is under surveillance. The database can also include pre-defined group definitions, which are lists of users and an associated group name, for the Chat room model of dispatch services. Each group can be uniquely identified by the group address, for example. The customer can 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 list of associated members from the user / group database 106 when it receives a group call setup request with a pre-defined group in it.

Media Control Unit Complex

The media control unit (MCU) complex may include media control guests (MCH) and the media control unit (MCU). The MCH can host and manage multiple MCU processes. Each MCU can handle real-time signaling and media processing for a single call.

I

- 32 Functions that the MCU performs for a call may include:

• Manage call assignments from RD 114 • Send load and status information to MCH • Send call initiation information to clients • Process incoming call signaling from clients, such as PTT requests * Ensure signaling messages are delivered to clients reliably • Respond and distribute media for one-to-many calls • Provide media translation using the appropriate transcoder for one-to-many mixed vocoder calls • Monitor activity number of calls and initiate call termination based on media stream idle • Produce usage information for usage log server (ULS) 118 • Advance signaling media and information to the appropriate legal interception point when requested.

The MCU can process alert requests from RD 114, send alert notifications to the client, and await acknowledgments from clients. After receiving the target acknowledgments, the MCU releases any resources allocated to the alert transaction. At this time, the MCU can handle other assignments. calls or alert requests.

User Registration Server

ULS 118 can exist in each region and can co-locate with MCU complex 116. The ULS 118 can collect usage events 20 from MCU complex 116 for each call or alert processing, format them into a usage data record (UDR), and then store these UDRs in a sequence of UDR files. UDRs for calls can contain information regarding individual calls including the participant list and participant usage totals. The UDR for alerts can contain information indicating the originator of the alert and the target users to whom the alert was sent. UDR files can be collected by the service provider for analysis. billing, and can be removed after a fixed amount of time.

The ULS 118 can write only one UDR per call instance at the end of each call. The ULS 118 can also write a single UDR for each time an alert request is processed. UDRs written by ULS 118 may contain the following information:

• Call instance identifier or alert instance identifier • MCU identifier, which also implies call location. At the start of the call, an appropriate MCU can be selected based on the registered location of all proposed participants. The location of the MCU may or may not be in the same region as the originator.

• Initial time of the call or alert • Final time of the call or alert • Originate user name and / or identifier • Originate user IP address • For each participant, user name, user address, user IP address , cumulative participation time, which can be zero for alerts, and the total number of seconds the participant held the ground, which can be zero for alerts.

In one embodiment, a single UDR is issued for each call, which can represent the total collection of chat segments during the call. If UDR event logging is required on a chat segment basis, it can be implemented at the expense of additional processing load, file I / O, and disk space requirements.

The group communication system 100 performs several similar functions with

- 36 object of operating group services. User experience related functions include registration, call initiation, call termination, dispatch alerts, late join, chat arbitration, add users, remove members, unregister, forward, and authentication. The functions pertaining to the preparation and operation of the system include administration and provisioning, scalability, and reliability. These features are described in detail in the following sections.

Registry

In a wireless communication system, for example the CDMA system, registration is the process by which a mobile station makes its location known to the wireless system infrastructure. This location information can include the geographic area where the mobile station is located and the identification of the base station that is serving the mobile station, which can be used to aid in the efficient use of location calling and tracking channels. access.

In one embodiment, the user location information is the IP address of the client, regardless of whether or not the client is connected via wireless or wired services. An example IP protocol that allows IP applications to locate clients based on their IP address is the Session Initiation Protocol (SIP). Among other functions, SIP provides methods for clients to register their IP address and other location information with a SIP server component. In addition, SIP provides methods for IP applications interested in finding clients to query the same SIP server for location information, such as the client's IP address.

Registration may include the process of an IP client communicating with a SIP server component to report and maintain its location information, for example, IP address. The server component of SIP that provides this functionality is the local server. The method by which a client notifies the location server of its location or changes in its location is the SIP REGISTER method.

In one embodiment, clients register their location information with a regional location server. Other IP-based applications, such as instant messaging, can take advantage of the knowledge of each client's IP address available on a location server. An external service or the customer can perform the registration. Figure 3 illustrates an exemplary call flow to perform the registration function.

After power-up 302, the client can request a packet data session and start the process to register its IP address with the RLS 112. In order to perform the registration, the client can perform an SRV registration query 304 of DNS to determine the RLS address. Once the address of the RLS 306 has been retrieved, the customer can register its location information, for example, using a SIP registration message 308. The RLS can authenticate 310 the user and issue a response 312 to the client. The RLS can notify the regional 314 dispatcher that the user has registered, and the regional dispatcher can use this information to pre-load the user's associated data record in order to facilitate faster response time during call setup. At this point, the customer can be contacted with an invitation to participate in a group call. In one embodiment, clients may need to register in order to receive a group call, regardless of the type of data connectivity they have, that is, wireless or wired.

Records can have an expiration field associated with them, which indicates how long the customer's record information can be considered valid. In order to guarantee that the client is always reached by IP, the client can be aware of the expiration of his registration and perform a re-registration before the moment of execution. Records can

- 40 also become invalid or stale due to other circumstances, such as when the client's IP address is changed or the data connection between the client and the location server is damaged. Customers can be aware of the status of their data connectivity and if their IP address has changed.

After the initial registration is complete, a client can allow its packet data session to sleep, which can free up the dedicated traffic channel. The client can monitor their packet data session to ensure that it remains valid during extended latency periods. Conditions that can affect the validity of the session include moving an area with a different packet zone ID, experiencing a blackout or loss of service, and accepting and / or placing a PSTN call. The client's IP address may change and the client may be required to re-establish data connectivity to the infrastructure. When the client re-establishes its packet data session, it receives a new IP address.

The new IP address

- 41 needs to communicate with the location server to ensure that the customer's location information is accurate. This can be done by performing a re-registration.

A wired client that communicates with the location server through a firewall may need to keep open through the firewall by periodically echoing the location server. This is done when re-registering.

Group Call Initiation

After registration is complete, user can make or receive calls. Before the start of the first call after power-up, the customer can perform a DNS SRV record query to find the location of the regional dispatcher. This can be done as part of the startup process.

A group is associated with an originator, the user who initiated the group configuration, and a member list, which contains the target user or users. The member list can contain one or more users, one or more pre-defined groups, or a combination of the two. If the member list contains only one user, the call initiated using that member list is commonly referred to as a private call. If the member list contains any pre-defined groups, the regional dispatcher can expand the pre-defined groups into a list of one or more target users, for example, by replacing the predefined group identifier in the original member list, with the associated member list of the predefined group. After the pre-defined groups have been expanded, the resulting member list can contain only target user names. At this point, the regional dispatcher tries to locate the target users in the member list, for example, by scanning the regional dispatcher's buffer of user information. If the targets are located within the regional dispatcher's buffer, group members can register within the same region as the regional dispatcher.

This type of group call is labeled as an intra-regional call. If there are users who could not locate the regional dispatcher, the regional dispatcher can request assistance from the local dispatcher to locate the users. The call associated with a group that contains members from two or more regions is referred to as an interregional call.

After the regional dispatcher has determined whether the call is intra-regional or inter-regional, it can initiate the process to determine which media control unit (MCU) can host the call. For intra-regional calls, the regional dispatcher can assign the call to an MCU located in the same region as the regional dispatcher, if there are MCU resources available in that region. The resulting call that uses this type of call setup is referred to as a locally hosted call, or a local call. For inter-regional calls, the regional dispatcher may have a selection to assign the call to an MCU within the same region or in a remote or foreign region. The regional dispatcher can take this

I

- 44 decision based on the user's location information to find the optimal path of travel for the IP packets containing media and signaling. If a majority of users are located in a particular region, the call can be assigned to that region. If users are evenly spread across all regions, the call can be assigned to one of 10 regions containing the target users.

If the inter-regional call is assigned to an MCU in a different region then the region in which the regional dispatcher resides, the call is referred to as a remote or remotely hosted call. The regional dispatcher may have knowledge of the network topology and / or connectivity between the MCUs and the PDSNs they are serving and can use this knowledge to make a better call allocation decision.

Intra-regional calls

The group communication system 100 can be deployed to ensure that the majority of calls are intra-regional.

- 45 Intra-regional calls can eliminate the need for communication between regional dispatcher 114 and local dispatcher 102 at the time of call setup. The need for communication between regions can also be eliminated when the targets are in the same region and the call is hosted locally, as is the case for most intra-regional calls. The following sections describe call flows, timing calculations, and messaging channels for intra-regional calls.

Initiate a Local Call

Figure 4 illustrates an example message flow for initiating a local group call. The user can select 402 one or more target users, one or more pre-defined groups, or a combination of the two or can depress the push-to-talk (PTT) button. The client can send a 404 request to the regional dispatcher in order to set up the group call, regardless of whether the mobile station has a dedicated traffic channel or not, as shown

- 46 will be described in more detail below. After the request is sent, if the mobile station's packet data session is dormant, the client can initiate the process to re-establish dedicated traffic channels and prepare the packet data session for media activity. The customer can buffer the voice input received from the originator for a period of time.

When the regional dispatcher receives the request, it can expand the predefined groups, which can be specified in the request, into the target user member lists. The regional dispatcher can then retrieve 406 the location information of the target users. At this point, the regional dispatcher will also determine if the group is already running on the system. Figure 4 shows a scenario in which the group is not running. The late join call scenario, which is described later herein, illustrates the case in which the group is already running.

After the regional dispatcher

- 47 locates at least one of the target users, the regional dispatcher can send a 408 response back to the customer indicating the group call that is configured. At this point, the client can optimistically grant 410 the originator's request to speak and begin buffering 412 its media.

The regional dispatcher can use the locations of the target users to determine the region in which the call can be assigned. If the target users are determined to be in the same region as the regional dispatcher, as in Figure 4, the regional dispatcher can assign the call to a regional MCU. The MCU can send announcements 414 to the entire group indicating that the call is starting. For target users, ad delivery can trigger their packet data sessions to get out of latency and re-establish their traffic channels.

After the client has received the call announcement from the MCU and the traffic channel of the mobile station has been re-established, the client can forward 416 the stored media

- 48 intermediate to the MCU. The MCU can buffer 418 the received media from the originator. In one embodiment, the MCU may buffer the media until the target response threshold is met or exceeded. The target response threshold is an indication of the number of target responses requested in order to proceed with the media delivery. The threshold can be a configurable parameter. Once the threshold is met, the MCU responds and advances 420 the media to the target users who have responded 422 to the announcement for the call.

Short Data Burst Messaging

Instant response is related to the response time it takes for the application server to respond to a call setup request. The goal in responding to any PTT request, including any request for group call setup, is to consistently respond to the request within a predetermined period of time, for example, one second or less. In many cases, when a user requests to set up a group call, the user's packet data session is dormant and there is no dedicated traffic channel. Re-establishing dedicated traffic channels can take considerable time. Hence, communication to the application server can be carried out by other means.

In order to ensure that the group communication system meets the instant response, small IP datagrams can be sent at any time in any direction, i.e. mobile origin or mobile termination, regardless of the state of the packet data session . In one embodiment, the IP datagrams may be sent in the form of a short data burst message (SDB). In situations when the packet data session is dormant, the SDB message will be sent on the overload channels. When dedicated traffic channel connectivity is present, the SDB message is sent on the traffic channel.

Referring to FIG. 4, the group call setup request 404 can be sent via an SDB message. 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 the SDB messages may allow the group communication system 100 to meet the goal of instant response.

To complete the group call setup process, the MCU can send call announcements to the users in the member list, including the originator. These call announcements can be sent through dedicated traffic channels. In most cases, the group member's packet data sessions are dormant, that is, no dedicated traffic channel is established. This means that the MCU may have to forward the call announcement message on an aggressive reliability schedule until all members' traffic channels have been re-established and the members have acknowledged the message or the reliability timer expires. Send

I

- 51 the call announcement aggressively ensures that the media buffers in the client and the MCU are kept to a minimum. The client can send buffered media as soon as its traffic channel is up and receives a call announcement containing the MCU's contact information. The MCU can respond and forward buffered media as soon as the target response threshold is met or exceeded. This means that the faster the targets receive the call announcement and respond to it, the faster this threshold can be met, then the faster the MCU can stop buffering and start sending media.

The call announcement to the originator can also be sent via SDB. This provides two benefits. First, since the call announcement contains MCU contact information, the group call client can start sending buffered media to the MCU as soon as the mobile station's traffic channel is re-established, which can reduce the

- 52 RAM requirements in the mobile station to retain the buffered media. Second, if the originator decides to abort the call or release the ground, which can happen before the traffic channel is re-established, when the call announcement comes in via SDB, the client can notify the MCU with that information. The impacts to send the call announcement to the originator using SDB 10 is an increase in the load on the common channels and a requirement for the MCU to give special treatment to the call announcement message from the originator.

Initiate a Remote Call

Intra-regional calls can be hosted locally if all members are located within the same region. The regional dispatcher may assign an intra-regional call to a remote region due to local resources being overloaded or unavailable. In such cases, the media and signaling may experience additional latency and errors due to 25 extended communication paths between the

- 53 PDSN of the user and the remote MCU. Figure 5 illustrates an example call setup for a remote, intra-regional call.

Initiating an intra-regional call on a remote guest is similar to the call setup scenario described in connection with Figure 4, with the exception of assigning the call from the regional dispatcher to an MCU. After the regional dispatcher has retrieved the location of the group members, it can determine the MCU to which the call can be assigned. The regional dispatcher can make this decision based on the location information of the users, load and availability of the MCUs. In an intra-regional call, users can be located in the same region, therefore, the regional dispatcher can check the load and availability of the MCU complex in the local region. If the regional dispatcher receives an indication that the local MCU complex is overloaded or temporarily experiencing operational failures, then it can assign the call to a remote MCU. In one embodiment, the MCUs can be replicas of

I

- 54 identical functionality with the exception of call setup; therefore, the remote MCU can handle the call similar to the local MCU.

Inter-regional calls

The group call system 100 may be designed to allow a user to communicate with any other user regardless of their physical location or proximity to one another. The group call system 100 can be deployed to limit the number of calls that are inter-regional, since inter-regional calls require communications between the regional dispatcher and the local dispatcher at the time of call setup. The call assignment can be for an MCU that is a remote region from one or more of the call parties. The following sections describe example call flows, timing calculations, and messaging schemes for interregional calls.

I

- 55 Initiating a Local Call

Figure 6 illustrates an example message flow for initiating a locally hosted group call. The call setup for a local, inter-regional call is similar to the call setup for a local, intra-regional call, as described in connection with Figure 4, with the exception of the process in which the regional dispatcher retrieves the location information for target users. In one embodiment, the regional dispatcher tries to locate the target users within its buffer. If some users are not found in the buffer, the regional dispatcher can request assistance from the local dispatcher in order to locate the users. The local dispatcher can contain user location information for users who have made IP registrations using the regional location server. As previously described, the regional location server can notify its associated regional dispatcher each time a user registration occurs. Every dispatcher

- 56 regional can notify the regional dispatcher of user records. This allows the local dispatcher to help the regional dispatchers to find the users that are geographically distributed in the different regions.

Initiate a Remote Call

Figure 7 illustrates an example configuration for a remote, interregional call. Initiating an interregional call on a remote guest is similar to the call setup scenario, as described in connection with Figure 4, with the exception of assigning the call from the regional dispatcher to an MCU. After the regional dispatcher (RD) 114 retrieves the location of the group members, the MCU can determine which call it can be assigned to. RD 114 can make this decision based on information about the user's location, load, and availability of the MCUs. Using the locations of the group members, the RD tries to find the optimal path of travel for the IP packets they contain

I

- 57 media and signaling, over the service provider's network, for a majority of members. If a majority of users are located in a particular region, the call can be assigned to that region. If the users are evenly distributed across the regions, the call can be assigned to one of the regions that contain the target users.

Group Call Termination

A group call can end for two reasons: all participants have requested to leave the call or all 15 participants have stopped talking for a pre-defined period of time, called a timeout. Each participant can choose to end participation in the call before the planned end of the call. If all participants drop the call, the MCU can terminate the call and release all resources allocated to it. If everyone except one participant drops the call, the MCU can notify the participant, referred to as the lone user. The lone user has the option of immediately abandoning the call or waiting for the time-out timer to expire, which can activate the MCU in order to disband the call.

The MCU can terminate the call after the time-out timer expires. The MCU can track each talk pulse and set a timer after the end of a talk pulse. This timer is referred to as the time-out timer and can track the duration of silence, that is, no chat or media stream activity, on the call. If the call remains silent for the duration of the time-out, which can be configured by the service provider, the MCU can assume that the participants are no longer interested in the call, and thus terminate the call.

User Initiated Call Termination

Figure 8 illustrates an example scenario in which a user has chosen to terminate participation in a call

- 59 group. The scenario graphically represents the flow of messages to terminate user engagement. When the user chooses 802 to terminate participation in the group call, the client can send 804 a request to the MCU to remove the user from the call. The MCU can remove 806 the user from the call and notify the client 808 that the user has been removed 810.

Server Initiated Call Termination

Figure 9 illustrates an exemplary message flow that occurs when the time-out timer expires and the MCU terminates the group call. After the expiration of the time-out timer 902, the MCU may send 904 to the participants a notification that the call is ending. Each customer who receives an end of call notification can reply 906 with an acknowledgment. After receiving the acknowledgments, the MCU may notify the RD 908 that the call has ended and may release the resources that were allocated to the call.

- 60 Send an Alert

The alert mechanism can be used to notify target users that the other user, the alert originator, has expressed a wish to engage them in a group call. The alert mechanism can contain a text message that allows the originator to specify the subject of the call, the desired time of the call, or any other personalized text message. Figure 10 illustrates an example 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 the two, and may indicate that an alert may be sent. The client can send 1004 a request to the RD to send alerts to the target users specified in the request. When the RD receives 1006 the request, it can expand the pre-defined groups specified in the request into the target user member lists, and the RD can retrieve the location information of the target users. After the RD has located at least one of the target users, the RD can send a 1008 response back to the client. The RD may assign 1010 the alert request to an MCU in order to issue alert messages 1012 to the target users.

As seen in Figure 10, the alert request can be sent via short data burst (SDB). Sending alerts using SDB messages allows the packet data sessions of the parties involved to remain dormant. The alert notification contains the information necessary to allow the target users to set up group calls with the originator and the rest of the target users, for example, by selecting the alert notification and pressing the PTT. When this occurs, the group call setup proceeds in a manner similar to the call setup scenario described in connection with Figure 4.

Late Union

A group call setup request is considered a late join, if it is determined that the list of members, which can be specified in the call setup request, is identical to one associated with a call already in progress in the system. This situation can occur in one of two ways. First, the user can create a list of members identical to the one that already has a call associated with him, for example, by selecting 10 the same user (s) and / or group (s) and depressing the button of PTT. Second, the user can select a call, which is still running on the system, from the call history list and by depressing the PTT. In either case, the RD can detect that the call the user has requested to start is already in progress, and treat the user as a late join.

Figure 11 illustrates an example late join 20 case in which you can select a call from the call history list. The user may select 1102 a call from the call history list and press the PTT button.

The client can 1104 send a request to the RD to start the group call. The RD can determine the call that is already running 1106 and sends a response 1108 to the client that the user is being added to a call in progress. If the call is already running, the user may not be granted ground because a current call participant may already be holding ground by the time the backward user is ready to receive media, that is, the data session of the call. packet comes out of latency. The RD may request 1110 from the MCU that is hosting the call in order to add the late join user to the group. The MCU adds the user and 1112 sends an advertisement to the user that contains the MCU's contact information. After the late join user traffic channel is re-established, the media stream within the call can be transmitted to the user. At this point, the late join user can attempt to request the privilege to speak.

The late join scenario is similar to the scenario for initiating a new group call as described in connection with Figure 4. The differentiating factor is that the late join user is denied the floor in response to the request to configure initial group call.

Speaker Arbitration

In one embodiment, each group call user is assigned a speaker preemption rating, which determines what level of rights the user has when requesting privileges to grab ground and begin speaking. After the group call is set up, the MCU may be responsible for monitoring the floor and determining if a participant requesting the floor can be allowed to speak. The MCU can perform speaker arbitration when two or more call parties are competing for control of the floor for a particular group.

Figure 12 illustrates the example events that can occur during an arbitration process. The arbitration scheme used in this scenario allows User B's right of first refusal when User A requests the floor. User B has ground control, that is, User B is speaking, when User A requests permission to speak by pressing 1202 the PTT button. The client can send 1204 a message to the MCU requesting permission to speak. The MCU may perform speaker arbitration 1206 and determine that user B may have the preemptive right and the floor is granted to user A. In order to ensure a suspension in the media stream, that is, user B can stop talking before user A's media is transmitted, the MCU first sends 1208 a message to the client for user B, indicating that the ground has been preempted by another user, and then sends 1210 a response that grants the ground to user A.

Add Users to an Active Group Call

The group communication system 100 allows a group call participant to add new users to a group call in progress. This is done by the call party selecting one or more ί

- 66 target users, one or more predefined groups, or a combination of the two, and indicating that the participant would like to add the targets to the group call the participant is currently in. Figure 13 illustrates the events that occur when new goals are added to a group call that is in progress. The call participant may select 1302 one or more target users, one or more groups, or a combination of the two to be added to the call. The client can send 1304 a message to the RD requesting that the specified target users be added to the group call in progress, which can be specified in the request. When the RD receives the request, it can expand the pre-defined groups, specified in the request, into lists of target user members. The RD can then retrieve 1306 the location information of the target users. After the RD has been located in at least one of the target users, the RD may send 1308 a response back to the client indicating that the targets are being

- 67 adding to the call. The RD may send 1310 a request to the MCU to add the specified users to the call. The MCU can send 1312 call announcements to the new targets, which can begin the process of bringing their packet data sessions out of latency. Announcements can be delivered on a reliability schedule to ensure the targets get the message. After the traffic channels of the targets are re-established, the targets can send 1314 acknowledgments to the MCU. Additional targets may be included 1316 in the media and signaling communications that are occurring on the call.

Remove Members from an Active Group Call

The group communication system 100 allows a group call participant to remove members from an active group. In one embodiment, this can be done by a call party selecting one or more target parties and indicating that they should be removed from the group call. Figure 14 illustrates exemplary events that can occur when participants are removed from a group call in progress. The group call participant may select 1402 one or more target participants to be removed from the call. The client may send 1404 a message to the RD, requesting that the targets, which can be specified in the message, be removed from the group call. When the RD receives the request, it can retrieve 1406 the location information of the target and can send 1408 a response back to the client indicating that the targets are being removed. The RD may send 1410 a request to the MCU to remove the targets from the call. The MCU can send 1412 messages to the targets, which can be specified in the delete request, indicating that they are being removed from the call. Targets can send 1,414 acknowledgments to the MCU.

Unregister

When contacted by any other user, the IR application server does not want to be applications or uses the user's IP address to contact the user, the unregister function can be performed. The unregister function removes the user's IP address and other contact information from the RLS and frees up any resources allocated on behalf of the user. Figure 15 illustrates how the RLS user registration is de-registered as a result of the mobile station shutting down, according to one embodiment. The client may receive 1502 an indication that the mobile station, in which the client resides, is being powered down. As part of the shutdown process, the client can send a message 1504 to the RLS, indicating that the user's location information should be removed. The RLS can authenticate 1506 the request to ensure that it comes from a valid source. After successful authentication, the RLS can notify the client 1508 of a successful indication, and can notify the RD about 1510 deletion of the user. The RD can remove the user's data records from its buffer and can free up any resources that may have been allocated to the user. In

I

In the event of failure to unregister, 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, the group communication system 100 supports both the chat room model and the ad-hoc model. In the chat room model, the groups are predefined, which can be stored on the dispatch server. Pre-defined groups can be public, implying that the group has an open membership list, that is, any dispatch user is a potential participant. In the chat room model, the call is initiated when the first person chooses to join the room by chat, and the call remains running, with server resources assigned to the call, regardless of chat activity, for an amount default time, which can be set by the service provider. Users specifically request to join and leave these types of calls. During chat idle periods, each call is placed into a group sleep state, such as

I

- 71 will be described below, until a user requests permission to speak.

In the ad-hoc model, groups can be defined in real time and have a closed 5-member list associated with them. A closed member list may specify which users are allowed to participate in the group, it may not be available to users outside of the closed member list, and it may only exist for the life of the call.

Ad-hoc group definitions may not be stored anywhere else; they can be used to set up the call and release after the call has ended.

An ad-hoc group can be formed when a source user selects one or more target users and generates a request, which is sent to a server in order to initiate the call. Target users can be notified that they have been included in a group and can automatically join the associated call, that is, no user action is required.

When an ad-hoc call becomes idle,

- 72 application servers can wear down the call and release the resources allocated to it, including the group definition used to initiate the call.

When operating in the chat room model, in the group communications system 100, a group of communications device users, individually known as network members, communicate with each other using a communications device assigned to each member. network. The term network denotes a group of communications device users authorized to communicate with one another.

In one embodiment, a central database may contain information that identifies the members of each particular network. More than one network can operate on the same communication system. For example, a first network can be defined as having ten members and a second network can be defined as having twenty members. The ten members of the first network can communicate with each other, but may not communicate with the members of the second network. In another embodiment, members of different networks are capable of monitoring communications between members of more than one network, but are only capable of transmitting information within their own network.

A network can operate over an existing communications system, without requiring substantial changes to the existing infrastructure. Consequently, a controller and users on a network can operate on any system capable of transmitting and receiving packet information using Internet protocol (IP), such as a Code Division Multiple Access (CDMA) system, an Access System Time Division Multiple (TDMA), a Global System for Mobile Communications (GSM), satellite communications systems such as Globalstar ™ or Iridium ™, or a variety of other systems.

The network members can communicate with each other using an assigned communication device, shown as communication devices (CDs) 120 and 122. CDs 120 and 122 can be wired or wireless communication devices such as landline cordless phones, wired phones that have push-to-talk capabilities, satellite phones equipped with push-to-talk functionality, wireless video cameras, fixed cameras, audio devices such as music recorders or players, laptops or desktops, paging devices, or any combination thereof. For example, the CD 120 can compress a cordless land phone that has a camera and video display. Furthermore, each CD may be able to send and receive information in any secure mode, or an unsecured mode (of course). By the following description, reference to an individual CD infers a wireless push-to-talk telephone. However, it should be understood that the reference to a CD is not intended to be limited to such, and may contemplate other communication devices that have the ability to transmit and receive packet information in accordance with the Internet Protocol (IP).

In the communication system 100 of

- 75 group, a broadcast privilege generally allows a single user to broadcast information to other network members at any one time. The transmission privilege is granted or denied to a requesting network member, depending on whether or not the transmission privilege is currently assigned to another network member when the request is received. The process for granting and denying transmission requests is known as arbitration. Arbitration schemes can evaluate factors such as priority levels assigned to each CD, the number of unsuccessful attempts to obtain transmission privilege, the length of time a network member has maintained the transmission privilege, or other factors. , determining whether a requesting network member is granted the broadcast privilege.

In order to participate in system 100, each of CDs 120 and 122 may have the ability to request transmission privilege from a controller or MCU 116. The MCU

116 You can manage the real-time and administrative operation of the groups. The MCU is

II

- 76 any type of computer type device that has at least one processor and memory. MCU 116 may operate remotely via a communication system service provider, members, or both, assuming authorization is provided by the service provider. MCU 116 may receive group definitions through an external management interface. Group members can request administrative actions through the service provider or manage network functions through defined systems, such as a member-operated security manager (SM) that conforms to an MCU management interface. MCU 116 can authenticate the party attempting to establish or modify a network.

The SM can perform key management, user authentication, and related tasks to support security networks. A single group communication system can interact with one or more SMs. The SM may not be involved in real-time control of a network, including network activation or PTT arbitration. SM may have capabilities

I

- 77 - .

Supported management tools with the MCU interface to automate management functions. The SM may also be capable of acting as a data endpoint for the purpose of participating in a network, transmitting network keys, or simply monitoring network traffic.

In one embodiment, the means for requesting transmission privilege from an MCU comprises a push-to-talk (PTT) key or switch. When a user in system 100 wishes to transmit information to the other members, the user can depress the push-to-talk switch located on his CD, send a ground control request to obtain the transmitting privilege from MCU 116. If no other network member is currently assigned the transmission privilege, the requesting user may be granted the transmission privilege and the user can be notified by an audible, visual, or tactile alert via the CD. After the requesting user has been granted the transmitting privilege, then the information can be transmitted from that user to the other member.

In one embodiment of the present invention, each wireless network member establishes a forward link and a reverse link with one or more base stations 126, or alternatively with a satellite network access, as the case may be. Voice and / or data can be converted into data packets, using a CD, for example, which are suitable for a particular converted network 128 whereby communications to other users can take place. In one embodiment, the distributed network 128 is the Internet.

In one embodiment, a dedicated forward channel is established in each communication system, ie, a terrestrial communication system and a satellite communication system, to transmit information from each network member to the other network members. Each network member can receive communications from the other network members over the dedicated channel. In another embodiment, a dedicated reverse link is established in each communication system to transmit information to MCU 116. In one

I

- 79 mode, a combination of the above schemes can be used. For example, one scheme may involve establishing a dedicated forward transmission channel but requiring wireless CDs to transmit information to MCU 116 on a dedicated reverse link assigned to each CD.

When a first network member wishes to transmit information to other network members, the first network member can request the broadcast privilege by pressing a push-to-talk key on their CD, which generates a broadcast-formatted request over the phone. distributed network 128. In the case of CDs 120 and 122, the request can be transmitted over the air to one or more base stations 126.. A mobile switching center (MSC) 130, which may include a well-known networking function (IWF), packet data service node (PDSN), or packet control function (PCF), to process the data packets that can exist between BS 126 and distributed network 128. The request can be transmitted over the public switched telephone network (PSTN) to a bank of modems, which |

- 80 can receive the request and provide it to the distributed network 128. A terminal can monitor the traffic of the system 100 through its connection to the distributed network 128.

If no other member currently holds the transmitting privilege, when MCU 116 receives a request for transmitting privilege, MCU 116 may transmit a message to the requesting network member, notifying it that the transmitting privilege has been granted. Audio, visual, or other information from the first network member can then be transmitted to the other network members by sending the information to MCU 116, using one of the recently transmitted transmission paths. In one embodiment, MCU 116 then provides the information to the other network members by duplicating the information and sending each duplicate to the other network members. If a single transmission channel is used, the information only needs to be duplicated once for each transmission channel in use.

In an alternate mode, the MCU

116 is incorporated into the MSC 130 so that the data packets from the base stations are addressed directly to the MCU 116 without being addressed in the distributed network 128. In this mode, the MCU 116 is still connected to the distributed network 128 so that all other communication systems and devices can participate in group communication. In yet another embodiment, MCU 116 may be incorporated into the PDSN or PCF modules of MSC 130.

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

In one embodiment, the CD can form connections with individual communication terminals to form a talk group, or network. The MCU can comprise a variety of functional capabilities in hardware and software that are configurable in different ways to accommodate different applications. The MCU can provide the ability to manage real-time, administrative, and network authenticity operations, push-to-talk (PTT) request arbitration, and network membership distribution and registration lists, call setup, and required communication wear and tear. eg CDMA, system and network resources, as well as general network health monitoring.

Networks can be within a separate deployable cellular system, or a large multi-site configuration. In the case of a large configuration, multiple MCUs can be geographically deployed to form a single integrated system, each operating as a module added to the existing cellular infrastructure. As such, the new features introduced by the networks are available to cellular users without requiring modification to the existing cellular infrastructure.

The MCU can 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 generic management information. Networks can be statistically defined as clear or secure, and transitions between clear and secure may not be allowed. A secure network typically uses media encryption to provide authentication and protection against illegal listeners. Media encryption for secure networks is implemented on an end-to-end basis, implying that encryption and decryption can take place within the communications device. The MCU can operate without the knowledge of algorithms, keys, or security policies.

Figure 16 illustrates an exemplary cluster 1600 to show how communications devices 1602, 1604, and 1606 interact with an MCU 1608. Multiple MCUs can be deployed as desired for large-scale clusters. In Figure 16, the CD 1602 is allowed to stream media to the other members of the group. In this case, the CD 1602 is known as the speaker and transmits media on one channel. When CD 1602 is designated as the speaker, the remaining participants, CD 1604 and CD 1606, may not have permission to stream media to the group. Accordingly, CD 1604 and CD 1606 are designated as listeners.

As previously described, the

CDs 1602, 1604, and 1606 connect to the MCU

1608 , using at least one channel. In one embodiment, the channel is divided into separate channels comprising a media initiation protocol (SIP) channel 1610, a media signaling channel 1612, and a media traffic channel 1614. SIP channel 1610 and media signaling channel 1612 can be used any time bandwidth allows by any of CDs 1602, 1604, and 1606, regardless of being designated a speaker or listener. SIP is an application layer protocol defined by the Internet Design Task Force (IETF) that describes control mechanisms for establishing, modifying, and terminating multimedia sessions that operate over Internet Protocol (IP). SIP provides a general solution to call signaling problems for Internet telephony applications by supporting mechanisms that register and locate users, mechanisms which define user capabilities and describe media parameters, and mechanisms to determine the availability of the user, call settings, and call handling.

In one embodiment, SIP channel 1610 is used to begin and end participation of a CD within group 1600. A session description protocol signal

II

- 86 (SDP) can also be used within SIP channel 1610. When CD participation within the group is configured, for example using SIP channel 1610, real-time call control and signaling between the CD and MCU takes place, for example using media signaling channel 1612 by NBS. In one embodiment, media signaling channel 1612 is used to handle push-to-talk requests and releases, arbitrate between conflicting requests, or ground control, announce the start and end of information transmission, manage network latency , trace endpoint connectivity, request and exchange network status, and report any error messages. The channel 1612 media signaling protocol minimizes the duration of most common messages, and simplifies the task of interpreting responses and responding to requests while maintaining flexibility for future enhancements. The media signaling channel 1612 protocol also allows requests to be forwarded without adversely affecting the protocol state.

In one embodiment, the signaling traffic on media signaling channel 1612 includes call setup and control signaling, which may consist of session invitation requests and acknowledgments, and media signaling, which may comprise requests for real-time ground control and related asynchronous messages. The media traffic on media traffic channel 1614 may comprise point-to-multi-point real-time voice and / or data transmissions. Both categories of messaging have unique functional attributes. Additionally, each CD can issue domain name service (DNS) client requests to facilitate mapping of fully qualified DNS guest names to Internet network addresses.

In one embodiment, the call setup and call control signaling is done in accordance with SIP semantics. Although SIP can be transported using either the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), in one embodiment, each CD performs SIP-based signaling functions using UDP. Also, each CM can expect to receive SIP signaling requests over UDP. Real-time signaling can occur through the dynamic UDP / IP interface on the CM and each CD. Other signaling can take place over a fixed TCP / IP interface between the CM and the CD using SIP, for example.

Latericia from PTT

In one mode, when the packet data service is active, resources in the infrastructure, for example, base station transceiver subsystem (BTS), base station controller (BSC), networking (IWF) , and the radio link are actively assigned to the mobile station (MS). In an IP-based VoIP dispatch service, although there is an active conversation in progress between the group participants, the packet data connection for each user remains active. However, after a period of inactivity, that is, waiting time, in

I

- 89 group communications user traffic channels can transition to sleep state.

The transition to sleep state conserves system capacity, reduces service cost and battery drain, and makes the user available to receive incoming conventional voice calls. For example, when the user is on an active packet data call, they will generally consider incoming voice calls busy. If the user's packet data call is in a dormant state, the user may be able to receive incoming voice calls. For these reasons, it is desirable to transition the packet data call to the dormant state after periods of packet data inactivity.

Although packet data calls are active, even if no data packets are exchanged, radio frequency (RF) energy can still be transmitted by mobile phones, despite a low level, to maintain synchronization and control power with the base station. These

- 90 transmissions can significantly drain the power of the phone. However, in the sleep state, the phone may not make any RF transmission. To conserve phone power and extend battery life, the standby time can be set for the phone to transition to sleep mode after extended periods of no data transmission.

Although the packet data service is active for all users, PTT requests, which can be IP datagrams sent between the MS and the dispatch server, have very low latency. However, if channel users have previously transitioned to sleep, the PTT latency can be much longer. During the packet data latency, the status information associated with the packet data session can be maintained , including the mobile IP address. However, state information associated with layers below PPP, such as physical traffic layers, can be released and / or de-assigned.

In some infrastructures, to wake up a dormant data connection, the traffic channel must be reallocated, resources must be reallocated, and the radio link protocol (RLP) layer must be reinitialized. The effect of this is that after a talk group has not spoken for a while, when a user presses their PTT button to request the ground, the PTT latency during the first talk pulse is generally much longer during the pulses. subsequent talks. Although this is relatively rare, it can affect the usefulness of the service and should be minimized.

To reduce PTT latency, in one mode, group call signaling, such as ground control requests, ground control responses, and latency wake-up messages, can be transmitted on some common available channels, without wait for dedicated traffic channels to be re-established. Such common channels may always be available, regardless of the state of the mobiles, and may not require to be requested and reassigned each time a

I

- 92 user wants to start a group call. Therefore, group call signaling can be exchanged even when mobiles are dormant, which can provide a means to re-establish dedicated traffic channels for speaker and listener mobiles in parallel.

In one embodiment, the calling mobile can send a ground control request to the wireless infrastructure over some common reverse available channels, such as the reverse access channel and the reverse enhanced access channel. The calling mobile may also receive a response to the ground control request on some available common forward channels, such as the forward paging call channel and forward common control channel. In one embodiment, the sleeping listener mobiles may receive latency wake-up messages on some common forward channels available, such as the paging call forward channel and the common forward control channel.

I

- 93 Short Data Burst Call Signaling Messages

In one embodiment, a significant reduction in wake-up time from current total latency and the speaker's perceived PTT latency can be achieved through the use of short data burst messages (SDB), as provided in the Standards. of the TIA / EIA / IS-2000 for cdma2 0 00 Spread Spectrum Systems, hereinafter referred to as the cdma2000 standard, for example. In one embodiment, the SDB messages can be sent on either dedicated physical channels, such as the fundamental forward channel (FCH) or the dedicated common control channel (F-DCCH), or common physical channels, such as the broadcast channel. Reverse Access (R-ACH), Reverse Enhanced Access Channel (R-EACH), Forward Common Control Channel (F-CCCH), or Paging Call Channel (PCH). SDB messages can be transported by Radio Burst Protocol (RBP), which maps the messages onto an appropriate and available physical layer channel. Because SDB messages can carry arbitrary IP traffic as they can be sent

I

- 94 over common physical channels, SDB messages provide a mechanism for exchanging group call signaling when a calling customer mobile does not have dedicated traffic channels.

Mobile Originated Call Signaling Messages

In one embodiment, the media signaling messages can carry IP datagrams over the reverse link or the mobile originated link. A mobile client station can point out the MCU quickly anytime the user requests the ground and a dedicated reverse traffic channel is not immediately available. Assuming that the client mobile station has released all dedicated traffic channels, the client mobile station can immediately forward the request for ground control over a common reverse channel of a wireless infrastructure, which can transmit the request to the MCU. For example, either the reverse access channel or the reverse enhanced access channel can be used to

I

- 95 send such messages when a dedicated reverse channel is not available. In one embodiment, the client mobile station may transmit a ground request message to the

MCU as an SDB Message.

Referring to Figure 4, in one embodiment, the client MS may send the PTT ground request 404 on a reverse common channel, such as the access channel or enhanced access channel 10, before attempting to re-establish its talk channel. dedicated traffic. In one embodiment, the client MS can send the PTT ground request 4 04 in an SDB message regardless of which channel is used.

The client MS may then begin to re-establish its dedicated traffic channel, for example, by performing service option re-origin 33, for example. The client MS may also begin radio link protocol (RLP) synchronization. In one embodiment, the client MS can re-establish its dedicated traffic channel and advantageously synchronize RLP in parallel with the sending of the PTT ground request 404.

Therefore, the use of available reverse common channels and / or SDB feature for signal ground control requests to the CM, when a mobile station does not have active dedicated traffic channels, reduces the total time required to wake up mobiles. participants. Although the speaking client may not receive confirmation that their ground request has been granted until the speaker's forward traffic channel is re-established, the ability to quickly signal the CM to begin waking up participating listeners reduces overall latency.

Referring to Figure 4, the wireless infrastructure may send the PTT ground control request 404 to pack the packet data service node (PDSN) and then to the MCU. In one embodiment, after receiving the request for ground control, the MCU may arbitrate the request, burst media signaling wake-up messages (triggers) to a group of target participants (listeners), and / or trigger the re-establishment of the traffic channels 414 of the participants (listeners). If the MCU grants the PTT ground request, the MCU may send the PTT ground grant 408 to the client MS. In one embodiment, the RD may send the PTT ground grant 408 to the client MS on an available forward common channel, such as the forward paging call channel and the forward common control channel, if the channel of dedicated customer traffic is not yet reestablished. In one embodiment, the infrastructure can send the PTT ground grant 4 08 to the client MS in the form of an SDB regardless of which channel is used.

In one embodiment, the MCU may wait for the latency response timer to expire before responding to the PTT ground control request. If the group's latency response timer is set to zero, the CM can immediately respond to the ground control request. In one embodiment, if the client MS has completed re-establishing its traffic channel and RLP synchronization, the client MS can flow media 416, which can be buffered 412 in the client MS, at the same time. MCU.

I

- 98 Network Originated Call Signaling Messages

In one embodiment, after receiving the request for ground control, the MCU can broadcast media signaling wake-up messages in bursts to a group of target participants (listeners) and trigger the re-establishment of the participants' traffic channels (listeners). ). If the group's latency response timer is set to zero, the MCU can immediately respond to the request for ground control. In one embodiment, if the loudspeaker has started to re-establish its traffic channel immediately after sending the PTT request, the caller and listener traffic channels can advantageously be re-established in parallel.

Referring to Figure 4, after the MCU receives the PTT ground control request, the MCU can send wake-up triggers 414 directed to the target listeners. The MCU can determine if a packet data session exists for the target mobile, and forwards the trigger packet to the appropriate infrastructure element, eg, a base station. The infrastructure can locate each individual target MS to begin re-establishing its dedicated traffic channel. The target MS may later re-establish its dedicated traffic channel, eg, by performing service option re-origin 33, for example. The target MS may also begin radio link protocol (RLP) synchronization. In one embodiment, the target MSs can re-establish their dedicated traffic channels and synchronize their RLPs advantageously in parallel with the same functions that are performed by the client MS.

In one embodiment, after a target MS has completed re-establishing its dedicated traffic channel and synchronizing its RLP, the target MS can send the wake-up response 422 to the MCU, indicating that the target MS is ready to receive media. . The MCU may send a loudspeaker advertisement to the client MS before streaming the media 420, which has been buffered 418 in the MCU, to the target MS.

- 100 In one embodiment, the MCU may send wake-up trigger 414 to a target listener on some available common forward channels, such as forward paging call channel and forward common control channel, while not yet reestablishing them. traffic channels of target listeners. In one embodiment, the MCU may send wake-up trigger 414 to the target listener as an SDB, regardless of which channel is used. If the PTT ground control request is sent on the reverse common channel of the speaker as an SDB message and the target group latency response timer is set to zero on the MCU, the current PTT latency on the Talking can be reduced to the time required to send an SDB request message on the reverse link followed by an SDB response message on the forward link.

Network Interphases for Call Signaling Messages

To determine what specific network originated traffic, for example, the payload of

101

SDB, is sent for an idle mobile station without dedicated traffic channels, some policy or infrastructure interface can be implemented to distinguish such specific traffic from other traffic.

In a first embodiment, IP datagrams can be filtered based on their sizes, since SDB messages can carry a limited user payload. IP datagrams smaller than a predetermined size limit can be sent as an SDB message, if they are destined for a mobile without dedicated traffic channels. The group communication system can use such filters, since the application floor request response message is quite small, eg 34 bytes including the IP headers.

In a second embodiment, an infrastructure provider can define an IP-based service to encapsulate IP traffic destined for delivery to a mobile station. An IP server with knowledge of this service can transmit small IPs, for example UDP, datagrams, appropriately

- 102 ♦ encapsulated with IP headers, to this ^s service to supply a mobile phone suspected of not having a dedicated traffic channel. Group communication systems can use this service to signal to the infrastructure that the ground request response message can be delivered to the requesting client MS in the form of an SDB, for example. Coordination of SDB traffic with pending location calls or service origin requests is also important to ensure a fast and reliable supply of user traffic.

In a third mode, an IP server can transmit special IP, for example UDP, datagrams with IP headers for delivery to a mobile suspected of not having a dedicated traffic channel. The IP server can tag the IP datagrams, for example, by designating a special value in the IP header, to instruct the infrastructure to supply the IP datagrams to the client MS. Group communications systems can use this

103 service in order to instruct the infrastructure to supply the requesting client MS with the requesting client MS in the form of an SDB, for example. In a third embodiment, a UDP or TCP port range can be reserved to supply specific IP datagrams, eg SDB messages.

Origin and Service Location Call 10 Started on Mobile

In one embodiment, a client can send the ground control request 404, which can be in the form of an SDB, immediately followed by a service source request for the wireless infrastructure, eg CDMA, to quickly re-establish their channels. of traffic. However, if the latency response timer is set small, the RD can respond to the request for ground control quickly and transmit a response 408 back to the client. If this response reaches the infrastructure during the initial phases of the service origin transaction, the infrastructure observes that the speaker MS does not

- 104 has no active traffic channel and may attempt to locate the response to the speaker MS. However, this locate call action may abort the service origin transaction already in progress. In one embodiment, the speaker MS can respond to the paging call, ensuring that the ground control response message is sent to the speaker, and requesting the source of service again, but an unnecessary delay is experienced when re-establishing the channel. traffic traffic from the speaker as a result of the original service origin attempt aborted.

In a first embodiment, to avoid the condition of competition between the service origin process and the location call, the RD can be configured not to respond immediately to the request 404 for ground control. Accordingly, the latency response timer can be set so that the MCU transmits the response 408 to the speaker MS after the service origin process is completed.

In a second modality, the PDSN, which receives the response 4 08, and the

I

- 105 mobile switching (MSC), which responds to the speaker's service origin request, are coordinated. That is, if the PDSN determines that a packet data service origin process for the speaking MS is already in progress when the 408 response reaches the infrastructure, the MSC may defer the paging call to the speaking MS. . The PDSN can hide the response and send it on the talking mobile forward traffic channel once the service origination process is complete. Alternatively, the MSC can send the response to the speaking MS as an SDB message if the service origin process is still in progress.

In a third embodiment, the speaker MS can avoid the race condition by not issuing a service origin request until after the speaker MS has received a response to the request for ground control. In one embodiment, since the speaker MS has no active dedicated traffic channel, the MCU can send the response to the speaker MS on some common forward channels available,

106 such as forward paging call channel and forward common control channel. In one embodiment, the MCU can send the response to the speaker MS in the form of an SDB. The Speaker MS can rely on the ground control response generated by the RD to activate its traffic channel wake-up, in the same way that wake-up requests sent by the MCU trigger the traffic channel wake-up for the listener mobiles. The race condition is avoided as the potential for simultaneous origin of mobile initiated service and mobile network initiated paging call is avoided.

Hide Network Initiated Packet Data Triggers

The IP datagram, including the wake-up trigger 414, that arrives in the wireless infrastructure, for example, CDMA, and that is destined for a listener mobile that does not have dedicated traffic channels can be lost, either by the network in general or by the wireless infrastructure specifically.

107

In one embodiment, the wake-up trigger 414 sent to the listener mobile is aggressively retransmitted according to a defined schedule until the listeners respond or the group's wake-up timer expires. For example, wake-up trigger 414 can be resent every 500 ms. However, retransmitting wake-up triggers 414 at this rate can result in a maximum delay of up to 500 ms, or an average delay of 250 ms, from the moment the listener's traffic channel is re-established to the moment the next wake-up trigger destined for that listener reaches the infrastructure.

In one embodiment, the infrastructure or other entity in the network can hide the wake-up trigger 414 sent by the MCU, and send it to a target MS as soon as the target MS has re-established its traffic channel. This eliminates the need for retransmission of the wake-up request by the MCU, and reduces the total latency wake-up time. Set the wake-up trigger 414, as opposed to retransmitting it at the rate of 500 ms, for

108 For example, you can remove a 500 ms spend delay from the total latency wake-up time.

Placement in Media Buffer

In one embodiment, the user may be allowed to start speaking after the user has requested ground control, buffering the media before the dedicated channels between the client and listeners are re-established. By buffering the speaker's voice, the system allows the speaker to speak before the listeners' traffic channels have been fully re-established. This allows the speaker to start speaking earlier, reducing its apparent PTT latency. Since listeners do not experience PTT latency, their experience is not affected, that is, PTT latency varies from speaker to other parts of the system. The speaker may wait long enough to receive a response from a listener to its first talk impulse, but as mentioned earlier, it already waits for the response to its first impulse to speak.

109 talk to take more than the response to subsequent talk urges that occur while engaging in an active conversation. Buffering the first speaker talk pulse can be done in the MCU part or in the MS part.

Put the MCU part in Buffer

In one embodiment, the MCU can buffer the first talk pulse from the speaker. After a user has pressed their PTT button and the user's traffic channels have been re-established, they may be allowed to communicate with the MCU. At this time, since the listener traffic channels are not yet formed, the MCU buffers 418 the speaker's voice for future transmission to the target listeners. MCU buffering can reduce the apparent PTT latency seen by the speaker in the approximate time it takes to build the speaker's traffic channel. Figure 17 shows the buffering in the MCU part according to

110 a modality, as described below:

(1) No call in progress, originator and target traffic channels are dormant.

(2) Users press the PTT button. The server receives a configured group call request from the client.

(3) The floor is granted to the user after the client receives a configuration-in-progress response from the server or after a configurable delay (1 second) and begins to buffer them. user media.

(4) The server begins the target packet data traffic channel reestablishment process (5) The server sends a group call announcement message to the client via SDB.

I

- 111 - (6) Client successfully re-establishes traffic channel, begins to send buffered media to server.

(7) The client flows the media to the server (8) The traffic channels of the targets have been re-established (the target response threshold is met).

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

(10) The client finishes making the media flow to the server, requests the release of the floor by the server.

(11) The server sends ground release acknowledgments to the client.

Placement in Intermediate Memory of the Client's part

In one mode, where a shorter apparent latency is desired, the speaker can be allowed to start speaking before even

112 have your traffic channel re-established. Since the client MS is not yet in communication with the MCU, the signal for the speaker to start speaking is carried out by the client MS. If the loudspeaker is allowed to speak before the loudspeaker traffic channel is re-established, the client MS may buffer 412 the voice. As communication with the CM has not yet been established, permission to speak is optimistically given. Figure 18 shows the buffering of the client part according to one modality, as described below:

(1) No call in progress, originator traffic channel is dormant.

(2) The user presses the PTT button. The client sends a configuration group call request to the server using SDB.

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

- 113 - (4) The floor is granted to the user after the client receives a configuration-in-progress response from the server or after a configurable delay (1 second) and begins to buffer the user media.

(5) Client receives group call announcement message from server via SDB.

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

(7) Client streams buffered media to server.

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

(9) The client finishes making the buffered media flow to the server, requests the release of the floor by the server.

I

- 114 - (10) The client receives recognition of the soil release from the server.

In one embodiment, both MCU buffering 418 and client-side buffering 412 can operate concurrently. Buffering the client part can allow the apparent PTT latency to be small. In one embodiment, the client MS may buffer media in order to control the apparent PTT latency experienced by the user. The combination of mobile originated SDB and customer-side media buffering can reduce delays associated with re-established active traffic channels.

Therefore, the described modalities are provided for a dispatch model that supports at least two types of dispatch calls: the chat room model and the ad-hoc model. In the chat room model, groups are pre-defined, which can be

115 be stored on the dispatch server. However, in the ad-hoc model, groups can be defined and / or modified in real time.

The disclosed modes also provide a significant reduction in current total latency wake-up time and PTT latency by exchanging group call signaling even when mobiles are asleep and no traffic channel is active. The method and apparatus are provided for exchanging group call signaling through the use of short data burst message (SDB) signaling. The method and apparatus are provided for re-establishing dedicated traffic channels for the speaker phone and the sleeping listener phones advantageously in parallel.

In another embodiment, the sleeping wake-up latency in a group communications network can be reduced by hiding network-initiated wake-up triggers destined for target listeners, and sending a wake-up trigger to a target mobile station as soon as the station mobile beech

I

- 116 re-established its traffic channel.

In another embodiment, the simultaneous service origin and paging call is avoided in a mobile operating in a group communications network 5 by transmitting a response to a ground control request after the originating process is completed. service. In one embodiment, the response to the ground control request may be in the form of SDB if the service origin process is not complete. In another embodiment, the service origin process for the source communication device is initiated after transmitting the response to the source communication device.

117