Method, computer program product and communication device for adding a user to a group call in a group communication network

A COMMUNICATION DEVICE FOR JOINING A USER TO A GROUP CALL IN A GROUP COMMUNICATION NETWORK

<b>technical field</b>

The present invention relates to a point-to-multipoint communication system. More particularly, the present invention relates to a method and apparatus for adding to a group call a user wishing to initiate a group call if a group call is in progress.

<b>background</b>

A class of wireless services intended for rapid, efficient, one-to-one or one-to-many (one-to-group) communication has existed in various forms for many years. Typically, these services have been half-duplex, where the user presses a "push-to-talk (PTT)" button on his or her phone/wireless device to initiate a call. Pressing a button to fit one's radio to a suitable system or some implementation where communication takes place via some type of server indicates a user's need for a "floor". If the floor, or talker permission, is granted, in general, the user can talk for a few seconds after releasing his PTT button, and other speakers can claim the floor. Typically, communication is from a talker to a group of listeners, but may be one-to-one. Conventionally, such a service is a service in which one person, a "dispatcher," communicates with a group of people, such as a field service personnel or taxi driver, for which the name "dispatch" comes from. used in applications that require it.

Similar services are being offered over the Internet, commonly known as "voice chat". Typically, these services send vocoder frames in Internet Protocol (IP) packets (ie, voice-over-IP (VoIP) services) to a central group chat server or peer-to-peer. Implemented as a personal computer application that the service sends from client to client.

The most important feature of these services is that, without going through the usual dialing and ringing sequence, fast and spontaneous communication is initiated, usually simply by pressing the PTT button. Typically, this type of communication is very short, such as personal "talk spurts" of about a few seconds and "talks" lasting no more than a minute.

The time delay (known as PTT latency) between when a user requests a floor and when it receives an affirmative or negative response from the server that he has the floor and can initiate a call is a half-duplex group communication It is a very important parameter in the system. As mentioned above, since the dispatch system prioritizes short and fast conversations, if the PTT latency is long, the service becomes less efficient.

The conventional group communication infrastructure provides limited circumstances to significantly reduce the PTT latency (i.e., the actual PTT latency is not reduced below the time required to re-establish the traffic channel within a dormant packet data session). ). Also, the talker and listener traffic channels occur sequentially, since the only mechanism that can initiate wakeup of the dormant group is to wait for the talker's traffic channel to be re-established to signal the server. Currently, no mechanism exists for transmitting mobile-originated user signaling data over a channel other than the traffic channel, which limits the requirement that the traffic channel be re-established before communication between the client and server can occur. do.

Accordingly, what is needed is a mechanism that reduces the apparent PTT latency experienced by a speaker and the total time required to re-establish a traffic channel to a participating mobile station without adversely affecting system capacity, client battery life, or other resources. .

In the dispatch model, communication between endpoints occurs within virtual groups in which the voice of one "speaker" is broadcast to one or more "listeners". A single instance for this type of communication is collectively referred to as a dispatch call or simply a call. A call is an instance product of a group that defines the nature of that call, and is essentially a list of members with some relevant information, such as a group name or group id. The member list is a list of one or more users who have been requested to join the call.

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

<b>Summary of the invention</b>

The disclosed embodiments provide a novel and improved method in a communication device for adding a user to a group call in a group communication network, the method comprising: receiving an indication from a user wishing to initiate a group call; and, if the group call is already in progress, sending a request to the server to add the user to the group call.

In another aspect of the present invention, a computer-readable medium in a communication device implements a method for adding a user to a group call in a group communication network, the method comprising the steps described above.

In another aspect of the invention, a communication device for adding a user to a group call in a group communication network comprises means for receiving an indication from a user wishing to initiate a group call, and if a group call is in progress, the and means for sending to the server a request to add the user to the group call.

In another aspect of the present invention, a communications apparatus for adding a user to a group call in a group communications network includes a receiver, a transmitter, and a processor communicatively coupled to the receiver and the transmitter. The processor may receive an indication from a user wishing to initiate a group call and, if a group call is in progress, send a request to the server to add the user to the group call. In one aspect, the communication device is a push-to-talk (PTT) device.

<b>Brief description of the drawing</b>

BRIEF DESCRIPTION OF THE DRAWINGS The features and advantages of the present invention will become more apparent from the detailed description given below in conjunction with the drawings, in which like reference numerals refer to like objects throughout.

1 shows a group communication system.

2 shows how several applications interact with each other.

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

4 illustrates an exemplary intra-regional call-setup process in accordance with an embodiment.

5 depicts an exemplary remote in-area call-setup process in accordance with one embodiment.

6 illustrates an exemplary local inter-regional call-setup process in accordance with an embodiment.

7 illustrates an exemplary remote inter-region call-setup process in accordance with an embodiment.

8 depicts an exemplary process for leaving a group call in accordance with one embodiment.

9 illustrates an exemplary process for terminating a group call in accordance with one embodiment.

10 illustrates an example process for sending an alert for a group call in accordance with an embodiment.

11 illustrates an example process for late joining a group call in accordance with one embodiment.

12 depicts an exemplary process for pre-empting a speaker in accordance with one embodiment.

13 illustrates an example process for adding a new member to an activation group call in accordance with one embodiment.

14 illustrates an example process for removing participants from a group call in accordance with one embodiment.

15 depicts an exemplary process for removing user registration in accordance with one embodiment.

Figure 16 illustrates a method for allowing several communication devices to interact with a communication manager according to an embodiment.

Fig. 17 shows buffering media at the communication manager side according to one embodiment.

18 illustrates buffering media at the client side according to one embodiment.

<b>details</b>

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

1 shows 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 net broadcast service (NBS), a dispatch system, or a point-to-multipoint communication system. In one embodiment, the group communication system 100 includes such as dispatchers, location servers, media control unit complexes (MCU complexes), usage log servers, and Internet Protocol (IP) clients (wireless and/or wired devices with IP connectivity). Contains application server components. Application server components may be deployed in the form of a centralized deployment or a regional deployment, based on the functionality of the component. The central deployment may include a home dispatcher (HD) 102 , a home location server (HLS) 104 , and a user/group database 106 . These components may be centrally located in the service provider's network and may be accessed by local deployment. Central components may be used to locate roaming users and initiate an inter-regional group call. The local deployments 108 , 110 may include a local location server (RLS) 112 , a local dispatcher (RD) 114 , a local media control unit (MCU) complex 116 , and a local usage log server (ULS) 118 . may be

Regional deployments may be distributed throughout the service provider's network to ensure that network delays associated with call setup are kept to a minimum, in order to meet instant-response requirements. Also, distributing the call load across several local systems ensures that a suitable scalability scheme is developed to support a large number of users. Local application server components provide user registration, intra-regional call setup and management, and alert initiation and delivery to users registered in the region.

For example, a group communication device (client) 120, 122, which may be used in a cdma2000 handset, requests a packet data session using a standard data service and uses this session to register the application server with its IP address. and perform group call initiation. In one embodiment, the application server components 108 , 110 are connected to the packet data service node (PDSN) of the service provider. When requesting a packet data session from the wireless infrastructure, clients 120 and 122 make IP connections with application server components 108 and 110 via PDSN.

Upon power-up, the client 120 , 122 may request a packet data session using the data service option. As part of the establishment of a packet data session, the client is assigned an IP address. At this time, the client also receives the address of the DNS (domain name server) server 124 . Clients 120 , 122 query DNS server 124 to find the address of RLS 112 , for example, by using a service record (SRV) lookup. After locating the RLS 112 , the clients 120 , 122 may perform registration notifying the application server of their location information (eg, IP address). Registration may be performed using an IP protocol, such as Session Initiation Protocol (SIP) over User Datagram Protocol (UDP). The IP addresses of clients 120 , 122 may be used to contact the client when users are requested in a group call.

In one embodiment, after completing registration, the client may perform another DNS SRV record lookup to find the local dispatcher's address. The client contacts the local dispatcher whenever the user requests to initiate a call and sends an alert. The interface between local dispatcher 114 and clients 120 , 122 may be a signaling protocol over UDP.

Once the group call is established, clients 120 , 122 and MCU complex 116 exchange signaling messages with the medium. In an embodiment, the medium may be transmitted between the call participants and the MCU complex 116 using Real Time Protocol (RTP) over UDP. Also, the signaling messages may be a signaling protocol over UDP. These protocols and functions they provide are described later.

<b>component</b>

The group communication system 100 may include client software necessary to provide group communication services, and IP endpoints including a local server component and a central server component. The group communication client and application server components are described in more detail in the next section.

<b>Client</b>

The group communication client 120, 122 may run on any IP endpoint accessing the appropriate vocoder(s). IP endpoints may include applications running on wireless systems (eg, cdma2000), application development platforms (eg, binary runtime environment for wireless (BREW)) and personal computers.

The client may include an interface with mobile station modem software (MSM) (which may be downloaded to the client including a BREW environment) and a software application (which may be developed using BREW). BREW is a platform that allows developers to create applications that may run on client communication devices. BREW provides an isolation layer for application developers to develop applications without direct contact with MSM software and original equipment manufacturer (OEM) software. This allows applications to be developed and evolved rapidly, independent of MSM and/or OEM software. It also allows applications to be downloaded to any device that contains a BREW environment. As shown in FIG. 2 , the client group communication application software 202 may run concurrently with other applications 204 , 206 , 208 , 210 . Although these services may be provided directly through the OEM 212 and MSM 214 interfaces, BREW provides isolation from the transformations created by applications at these layers. This allows OEM 212 and MSM 214 to evolve independently of data applications 202 , 204 , 206 , 208 , 210 .

For a client to operate efficiently on a personal computer, the personal computer may include access to a compatible vocoder, access to a sound driver, and an IP connection to an application server.

<b>location </b><b>server</b>

In one embodiment, location server (LS) provides user location information (eg, network-level IP address), physical location (eg, longitude and latitude) of the user, and/or packet zone. (ie, a system identifier that identifies the range of PDSNs that are broadcast over the air over a forward common channel and provide packet-data services for that sector). In an embodiment, the LS may include components that provide user location information to other applications, such as instant messaging, and process registrations from clients, using a SIP interface.

The LS may include two functional elements: a local location server (RLS) 112 and a home location server (HLS) 104 . The RLS 112 may be located on a regional basis, and the HLS 104 may be centrally located. Next, details about these elements and their functions are described.

<b>local location </b><b>server</b>

RLS 112 may process and maintain registrations from clients located within its region. In one embodiment, RLS 112 is a standard SIP-based LS associated with storage of user location information. As part of maintenance of registration entries, RLS 112 may check the expiration date in the "expiration" field for each registration. RLS ensures that expired entries are removed and the local dispatcher (RD) and HLS are notified of the removed entries.

As described above, the client may perform IP registration to notify the application server of its location. A client may maintain its registration while using the group communication service. A client may perform re-registration when the client's IP address changes and when its registration is about to expire.

When a client registers or re-registers, the RLS 112 may notify the relevant RD 114 . This reduces call setup time by allowing RD 114 to pre-load user data in preparation for call setup requests. RD 114 may cache the user's location information, eliminating the need for RD 114 to make an RLS contact to retrieve user location information during call setup.

RLS 112 may notify RD 114 when a user's location information is updated or removed from RLS 112 . This ensures that RLS 112 and RD 114 are kept in sync with up-to-date information about registered users within the area.

RLS 112 may also periodically update HLS 104 with location information of registered users. If RLS 112 submits registration to HLS 104 for a user who has already validly registered in another area, that HLS may solve the problem.

<b>home location </b><b>server</b>

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

If HLS 104 is a central component and RLSs communicate with the HLS, the HLS may resolve multiple registrations in different regions for roaming users. HLS 104 may receive registration information from each RLS. If HLS 104 receives multiple registrations for the same user, HLS 104 retains the most recent registration and may request removal from the RLS of the stale registration(s) for that user. This, in turn, may trigger the removal of caching information for that user from RD 114 associated with the RLS containing the stale registration.

<b>dispatcher</b><b> (Dispatcher)</b>

The dispatcher may facilitate call setup by locating the user and assigning a group call to a media control unit (MCU) complex 116 . The dispatcher is a server component that coordinates to satisfy the "instant access" requirement. In order to ensure the lowest call setup time, the dispatcher may include two functional elements with similar structure and function, but may have different arrangement methods. These two elements, the local dispatcher (RD) 114 and the home dispatcher (HD) 102 are described in detail in the next section.

<b>area </b><b>dispatcher</b>

RD 114 may be the initial point of contact for call setup requests and alert requests. RD 114 may pre-load user information when receiving an indication from RLS 112 that the user has been registered. Depending on the user information, RD 114 may cache information about group calls, running in the system. RD 114 may use caching information for users and groups during call setup to keep setup time to a minimum (ie, no database lookup may be required).

In one embodiment, the group information in which the RD is stored in the cache includes the address of the MCU complex 116 in which the group runs and the group member list. RD 114 may maintain its member list and MCU address while the call is alive. This allows the RD 114 to quickly determine whether an incoming call request contains a group definition, which is equivalent to having an associated call already running on the system, which causes the RD to quickly respond to the call setup request. response, and explicitly grant or deny a "floor" request in response.

RD 114 may grant or deny the floor-control request. RD 114 may determine whether MCU complex 226 adds the user to the call as a "late-joined" participant or requires the initiation of a new call with an associated member list.

During call-setup request processing, RD 114 may use the cached user information to retrieve location information for users specified in the call setup request. If the user cannot be located, RD 114 may request HD 102 to locate the user. In one embodiment, if one or more target users are located, RD 114 continues with call setup. After the target's location is identified, RD 114 may determine to which MCU the call should be assigned. This determination may be based on the IP addresses of users (including originators) in the group.

RD 114 may process 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 target.

In one embodiment, information in RD's cache may be periodically written to a reliable storage mechanism so that it can be restored in case of failure. Upon recovery of the RD failure, the user information and group information written to the reliable storage mechanism may be loaded back into the cache, and the RD continues to validate the cached information with processing of the incoming call setup request.

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

The RD 114 accesses the user/group database 106 during call setup and, if on demand, expands the pre-defined group address into a list of individual users and, if necessary, another identifier of the user or group. (eg, phone number, conference ID) into regular address(es).

<b>home </b><b>dispatcher</b>

A home dispatcher (HD) 102 may track location information of registered users. HD may include location information for users who have performed registration with RLS 112 .

As described above, each RLS 112 may notify an associated RD 114 whenever user registration, re-registration, un-registration, or registration expiration occurs. RD 114 may use this information to load or release user information in a local cache. Each RD 114 may update HD 102 with user location information. Because HD 102 receives updates from RD 114 , HD 102 may assist in finding users geographically distributed across different regions. RD 114 may request assistance from HD 102 when receiving a request for a user who is not currently registered within the region (ie, not in the RD cache for user information).

<b>DNS </b><b>server</b>

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

In one embodiment, when requesting a packet data session, each client discovers the address of the DNS server via Internet Protocol Control Protocol (IPCP) negotiation while a point-to-point protocol (PPP) session is established. DNS server 124 is notified on a per-region basis in this way. This allows the client to roam from one region to another and communicate with a DNS server 124 in the same region where the client is located. The DNS server 124 is arranged in units of regions together with each PDSN. In one embodiment, DNS server 124 may be updated with respective RD 114 and RLS serving the PDSN associated with that DNS server 124 .

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. DNS service (SRV) record lookup may be performed based on the "<domain>" part of the SIP URI that the client registers. The SRV record request may include the service or protocol the requestor is attempting to retrieve. For example, when attempting to locate RLS 112, a client may request a "registration service" in a DNS SRV record lookup. The DNS response may include one or more valid network and port addresses for the server providing the requested service. DNS for load balancing among servers providing the same service by having the DNS server 124 round-robin among multiple servers when returning a reply to a client request. A server 124 may be used.

<b>User/group database</b>

In one embodiment, the user/group database 106 is a central repository for user and group information. For each user, the database may include user address, pre-emption rank, authentication information, user contact information, and a lawful intercept flag indicating whether the user is being monitored. have. The database may also contain definitions of pre-defined groups, which, in the case of the dispatch service's chat-room model, are user lists and associated group names. Each group may be uniquely identified, for example, by a group address. The client may use the group address to identify the group in the group call setup request. RD 114 may use the group address to retrieve the relevant member from user/group database 106 when receiving a group call setup request with a pre-defined group.

<b>media control </b><b>unit</b><b></b><b>complex</b>

A media control unit (MCU) complex may include a media control host (MCH) and a media control unit (MCU). The MCH may host and manage multiple MCU processes. Each MCU may handle media processing and real-time signaling for a single call. The function that MCU executes for the call is:

<img file="KR100929512B1_D0001.tif" /> Handling of call assignments from RD 114

<img file="KR100929512B1_D0002.tif" /> Loading and sending of status information to the MCH

<img file="KR100929512B1_D0003.tif" /> Sending call initiation information to the client

<img file="KR100929512B1_D0004.tif" /> Processing of in-call signaling from users, such as PTT requests

<img file="KR100929512B1_D0005.tif" /> Ensuring that signaling messages are reliably delivered to clients

<img file="KR100929512B1_D0006.tif" /> Replication and distribution of media for "one-to-many" calls

<img file="KR100929512B1_D0007.tif" /> "mixed" vocoder Provides media conversion using an appropriate transcoder for "one-to-many" calls

<img file="KR100929512B1_D0008.tif" /> Monitoring of call activity and initiation of call termination based on media flow inactivity

<img file="KR100929512B1_D0009.tif" /> Generation of usage information for usage log server (ULS; 118)

<img file="KR100929512B1_D0010.tif" /> Signaling of information and forwarding of media to appropriate legal interception points, if required;

may include

The MCU may process the alert request from RD 114 , send an alert notification to the client, and wait for an acknowledgment (ACK) from the client. Upon receiving an acknowledgment from the target, the MCU releases any resources allocated to the alert transaction. At this time, the MCU may process another call assignment or warning request.

<b>usage log </b><b>server</b>

The ULS 118 may exit to any region and may be co-located with the MCU complex 116 . ULS 118 collects usage events from MCU complex 116 for each call or alert processing, formats the events into usage data records (UDRs), and stores these UDRs as a sequence of UDR files. may be A UDR for a call may include information about individual calls, including a participant list and participant usage totals. A UDR for an alert may include information indicating the originator of the alert and the target user to which the alert was sent. The UDR file may be collected by the service provider for billing analysis and may be deleted after a fixed amount of time.

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

<img file="KR100929512B1_D0011.tif" /> Call Instance Identifier or Alert Instance Identifier

<img file="KR100929512B1_D0012.tif" /> MCU identifier that also includes the call location. When initiating a call, an appropriate MCU may be selected based on the registration location of the proposed mode participant. The location of the MCU may or may not be in the same area as the sender.

<img file="KR100929512B1_D0013.tif" /> Start time of call or alert

<img file="KR100929512B1_D0014.tif" /> End time of call or warning

<img file="KR100929512B1_D0015.tif" /> Calling Username and/or Identifier

<img file="KR100929512B1_D0016.tif" /> Sending user IP address

<img file="KR100929512B1_D0017.tif" /> For each participant, username, user address, user IP address, accumulated participation time (may be zero for alerts), and total time the participant remains on the floor (zero days for alerts) may be)

may include.

In one embodiment, for each call, a single UDR representing the aggregate aggregate of call segments during that call is generated. If UDR logging is required on a per call segment basis, the logging may be implemented at the expense of additional processing load, file I/O, and disk space requirements.

The group communication system 100 performs several different functions to provide group services. Functions related to user experience include registration, call initiation, call termination, alert sending, late join, speaker moderation, user addition, member removal, deregistration, addressing, and authentication. Functions related to system provisioning and operation include management and provisioning, scalability, and reliability. The following sections describe these features in detail.

<b>Enrollment</b>

In a wireless communication system (eg, a CDMA system), registration is the process by which a mobile station announces its location to the wireless system infrastructure. This location information may include the area in which the mobile station is located and the base station ID serving the mobile station, and this information may be used to aid in efficient use of the paging channel and the access channel.

In one embodiment, the user location information is the IP address of the client, regardless of whether the client is connected via a wireless service or a wired service. An exemplary 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 a way for a client to register its IP address and other location information with a SIP server component. SIP also provides a way for IP applications interested in a "finding" client to query the same SIP server component for location information, such as the client's IP address.

Registration may involve the process of an IP client communicating with a SIP server component to hold and notify location information such as, for example, an IP address. The SIP server component that provides this functionality is the location server. A method in which a client notifies a location server of its location or a change in its location is the SIP registration method.

In one embodiment, the client registers its location information with a local location server. Other IP-based applications, such as instant messaging, may benefit from knowledge of each client's IP address available at the location server. An external service or client may perform the registration. 3 illustrates an exemplary call flow for performing a registration function.

Upon power up, the client may request a packet data session and may begin the process of registering its IP address with RLS 112 . To perform registration, the client may perform a DNS SRV record lookup 304 to determine the address of the RLS. Once the RLS address is retrieved 306 , the client may register its location information, for example, by using a SIP registration message 308 . The RLS may authenticate the user (310) and generate a response (312) to the client. The RLS may notify the local dispatcher that the user has been registered and that the local dispatcher may use this information to pre-load the user's relevant data records to facilitate faster response times during call setup ( 314). At this time, the client may be contacted with an offer to join the group call. In one embodiment, clients may have to perform registration to receive group calls, regardless of the type of data connection they have, ie, wireless or wired.

A registration may have an "expire" field associated with it and indicating how long the client's registration information can be considered valid. In order to ensure that the client is always reachable via IP, the client may be aware of the expiration of its registration, and may perform re-registration before the expiration time. Also, registrations may become invalid or out of date due to other circumstances, such as when the client's IP address changes or a data connection between the client and the location server is serviced. The client may be aware of its own data connection status or whether its IP address has been changed.

After initial registration is complete, the client may place its packet data session into a dormant state where it may release a dedicated traffic channel. A client may monitor its packet data session to ensure that it remains valid for an extended dormant period. Circumstances that may affect the validity of a session include moving to an area with a different packet zone ID, experiencing loss or fade of service, and acceptance and/or positioning of PSTN calls. The client's IP address may change, and the client may be required to re-establish a data connection to the infrastructure. When the client re-establishes its packet data session, it receives a new IP address. The new IP address must be communicated to the location server to ensure that the client's location information is kept accurate. This may be achieved by performing re-registration.

Wired clients that are delivered to a location server through a firewall may be required to keep open through the firewall by periodically "pinging" the location server. This is achieved by performing re-registration.

<b>Initiate group call</b>

After registration is complete, the user may make or receive calls. Before initiating the first call after power-up, the client may perform a DNS SRV record lookup to locate the local dispatcher. This may be done as part of a start-up process.

"Group" relates to the sender (the user who initiated the group setup), and the member list (including the target user or users). The member list may include one or more users, one or more predefined groups, or a combination thereof. If the member list contains only one user, a call initiated using that member list is collectively referred to as a private call. If the member list contains any predefined groups, the local dispatcher may replace the predefined groups by, for example, replacing the predefined group identifier in the original member list with the related member list of the predefined group. It may expand to a list of one or more target users. After the predefined groups are expanded, the member list thus created may contain only the target user name. At this time, the local dispatcher attempts to confirm the location of target users in the member list by, for example, scanning a local dispatcher cache of user information. If the target is located in the local dispatcher's cache, members of the group may be registered in the same region as the local dispatcher. This type of group call is called an "intra-regional" call. If there are users whose local dispatcher is not located, the local dispatcher may request assistance from the home dispatcher to locate the users. A call involving a group containing members from two or more regions is referred to as an "inter-regional" call.

After the local dispatcher has determined whether it is an intra-region call or an inter-region call, it may start the process of determining whether a media control unit (MCU) can host the call. In the case of an intra-region call, if there are MCU resources available in the area, the local dispatcher may allocate the call to the MCU located in the same area as the local dispatcher. Calls made using this type of call setup are referred to as "locally-hosted" calls or local calls. In the case of an inter-region call, the local dispatcher may choose to assign the call to an MCU within the same area or in a remote or external area. The local dispatcher may find the optimal travel path for the IP packet containing the medium or signaling by determining this based on the user's location information. If most of the users are located in a particular area, calls may be assigned to that area. If the users are uniformly distributed across the region, the call may be assigned to one of the regions containing the target users. If an inter-region call is assigned to an MCU in a different region (the region where the local dispatcher resides), the call is said to be "remotely-hosted" or remote call. The local dispatcher may be aware of the network topology and/or network connectivity between the serving MCU and the PDSN, and may use this knowledge to make better decisions about call assignment.

<b>Intra-regional Calls</b>

The group communication system 100 may be used to ensure that most calls are in-area. An in-area call may eliminate the need for communication between the local dispatcher 114 and the home dispatcher 102 at call setup. Also, as is the case with most intra-area calls, if the target is in the same area and the call is locally-hosted, the need for communication between areas may also be eliminated. The following sections describe call flow, timing estimation, and messaging schemes for in-area calls.

<b>Initiation of a local call</b>

4 illustrates an exemplary message flow for initiation of a local group call. The user may select one or more target users, one or more predefined groups, or a combination thereof and press a push-to-talk (PTT) button ( 402 ). The client may send a request to the local dispatcher to set up a group call ( 404 ), whether or not the mobile station has a dedicated traffic channel, as described below. After sending the request, if the mobile station's packet data session is dormant, the client may re-establish a dedicated traffic channel and initiate the process of preparing the packet data session for media activation. The client may buffer voice input received from the caller for a period of time.

When the local dispatcher receives a request, it may expand a predefined group, which may be specific to the request, into a list of target user members. The local dispatcher may then retrieve 406 location information of the target users. Also, at this point, the local dispatcher may determine whether a group is already running in the system. 4 shows a scenario when the group is not already running. A late join call scenario, which will be described later, represents a case in which the group is already running.

After the local dispatcher locates the at least one target users, the local dispatcher may send back a response to the client indicating that the group call has been set up ( 408 ). At this point, the client may positively grant 410 the sender's request to start sending and buffering 412 its media.

The area dispatcher may use the location of the target users to determine the area to which the call may be assigned. As shown in FIG. 4 , if it is determined that target users are in the same area as the local dispatcher, the local dispatcher may allocate a call to the local MCU. The MCU may send a notification to the entire group indicating that a call is starting ( 414 ). For the target user, the transmission of the notification may trigger its packet data session to come out of dormancy and re-establish the traffic channel.

After the client receives the call notification from the MCU and the mobile station's traffic channel is re-established, the client may forward the buffered medium to the MCU (416). The MCU may buffer the medium received from the sender ( 418 ). In one embodiment, the MCU may buffer the medium until it meets or exceeds a "target response threshold". The target response threshold is an indication of the amount of target response required to continue transmitting the medium. The threshold may be a configurable parameter. Once the threshold is satisfied, the MCU duplicates the medium and forwards (420) the medium to the target users who responded (422) to notification of the call.

<b>short data </b><b>burst</b><b> through </b><b>Messaging</b>

"Instant Response" relates to the response time it takes for an application server to respond to a PTT or call setup request. The purpose of a response to any PTT request, including a group call setup request, is to consistently respond to that request after a certain period of time (eg, within 1 second). In many cases, when a user requests the setup of a group call, the user's packet data session is dormant and there is no dedicated traffic channel. Re-establishment of a dedicated channel channel may take a significant amount of time. Accordingly, communication with the application server may be accomplished through other means.

In order to ensure that the group communication system satisfies an "instant response", small IP datagrams may be transmitted in any direction (i.e., mobile-originating or mobile-terminating) at any time, regardless of the packet data session state. have. In one embodiment, IP datagrams may be transmitted in the form of Short Data Burst Messages (SDB). In a situation where the packet data session is dormant, the SDB message is sent over the overhead channel. If there is a connection of a dedicated traffic channel, the SDB message is transmitted through the traffic channel.

Referring to FIG. 4 , the group call-setup request 404 may be sent via an SDB message. A group call-setup response 408 from the application server may also be sent in the SDB message. Call setup request and response messages transmitted via SDB messages may cause group communication system 100 to satisfy an "instant response" purpose.

To complete the process of setting up a group call, the MCU may send a call notification to users in the member list, including the caller. These call notifications may be transmitted over a dedicated traffic channel. In most cases, the packet data session of a group member is in a dormant state, that is, a state in which a dedicated traffic channel is not established. This means that the MCU may have to retransmit the call notification message with an aggressive reputation schedule until all members' traffic channels are re-established and the members acknowledge the message or the reputation timer expires. Aggressive transmission of call notifications ensures that the medium is buffered to the client and the MCU is kept to a minimum. The client may transmit the buffered medium as soon as its traffic channel rises and receives a call notification containing MCU contact information. The MCU may copy and forward the buffered medium as soon as it meets or exceeds the target response threshold. This means that the sooner the target receives and responds to a call notification, the sooner this threshold is met, the sooner the MCU may stop transmitting and buffering the medium.

Also, a call notification to the caller may be transmitted through the SDB. This provides two advantages. First, because the call notification contains MCU contact information, the group call client can send the buffered medium to the MCU as soon as the mobile station's traffic channel is re-established, which is the RAM for the mobile station to hold the buffered medium. requirements can be reduced. Second, when the call notification comes in through the SDB, if the caller decides to drop the call or release the floor (this may happen before the traffic channel is re-established), the client may notify the MCU of that information . The effect of sending the call notification to the caller via the SDB is to increase the load on the common channel and the requirement on the MCU to give special handling to the caller's call notification message.

<b>Initiation of a remote call</b>

An intra-region call may be locally-hosted if all members are located in the same area. The local dispatcher may allocate in-local calls to remote areas because local resources are overloaded or unavailable. In such a case, the media and signaling may experience additional latency and errors due to the extended communication path between the user's PDSN and the remote MCU. 5 illustrates an exemplary call setup for a remote in-area call.

The initiation of an intra-area call to a remote host is similar to the call-setup scenario described with respect to FIG. 4 , except for the call assignment of the local dispatcher to the MCU. After the local dispatcher retrieves the location of group members, the local dispatcher may determine the MCU to which the call can be assigned. The local dispatcher may make this determination based on the user's location information, the loading of the MCU, and the availability of the MCU. In an intra-region call, since users may be located in the same area, the local dispatcher may check the availability and loading of the MCU complex in the local area. If the local dispatcher receives an indication that the local MCU complex is overloaded or experiencing a temporary failure, the local dispatcher may assign a call to the remote MCU. In one embodiment, the remote MCU may handle the call similarly to the local MCU, as the MCU may be a duplicate of the same functionality except for call configuration.

<b>Inter-regional Calls</b>

The group call system 100 may be configured to allow one user to communicate with another user regardless of physical location or proximity to each other. The group communication system 100 may be arranged to limit a number of inter-area calls, since, upon call setup, an inter-area call requires communication between an area dispatcher and a home dispatcher. The call assignment may be an assignment from one or more call participants to an MCU in a remote area. The following section describes an example call flow, timing estimation, and messaging scheme for an inter-region call.

<b>Initiation of a local call</b>

6 illustrates an exemplary message flow for initiation of a local-hosted group call. Call setup for a local inter-area call is similar to the call setup for a local intra-area call, described with respect to FIG. 4 , except for the process in which the area dispatcher retrieves location information for target users. In one embodiment, the local dispatcher attempts to locate target users within its cache. If no users are found in the cache, the local dispatcher may request help from the home dispatcher to locate those users. The home dispatcher may include user location information about users who have performed IP registration using a local location server. As noted above, the local location server may notify the relevant local dispatcher whenever user registration occurs. Each local dispatcher may notify the home dispatcher of user registration. This allows the home dispatcher to assist local dispatchers by finding users that are geographically distributed across different regions.

<b>Initiation of a remote call</b>

7 illustrates an exemplary setup for a remote inter-region call. The initiation of an inter-region call to a remote host is similar to the call setup scenario described with respect to FIG. 4 , except for the call assignment of the local dispatcher to the MCU. After the local dispatcher (RD) 114 retrieves the location of the group members, the local dispatcher may determine the MCU to which the call may be assigned. RD 114 may make this determination based on the user's location information, the loading of the MCU, and the availability of the MCU. Using the location of the group members, the RD attempts to find the optimal travel path through the service provider's network for the IP packet, including the medium or signaling, for most members. If most of the users are located in a particular area, calls may be assigned to that area. If the users are uniformly distributed across the region, the call may be assigned to one of the regions containing the target users.

<b>End group call</b>

A group call may end for two reasons: either all participants are required to end the call, or all participants hang the call for a predefined period of time referred to as the "hang-time". Each participant may be selected to terminate participation in the call prior to the planned termination of the call. If all participants end the call, the MCU may also end the call and release all allocated resources. If all but one participant end the call, the MCU may notify a participant referred to as an "orphaned user." The orphaned user has the option to either end the call immediately or wait for the end-time timer to expire, which may trigger the MCU to release the call.

The MCU may end the call when the end-of-call-time timer expires. The MCU tracks each talk spurt, and may set a timer after the talk spurt is completed. This timer is called an end-of-call timer and may track a period of silence in a call (ie, no call or media flow activity). If the call remains silent for an end-time, which may be configured by the service provider, the MCU may assume that the participants are no longer interested in the call and end the call.

<b>End user-initiated call</b>

8 depicts an example scenario in which a user is selected to end joining a group call. The scenario shows a message flow to end the user's participation. If the user chooses to end joining the group call (802), the client may send a request to the MCU to remove the user from the call (804). The MCU may remove the user from the call ( 806 ) and notify the client 808 that the user has been removed ( 810 ).

<b>server</b><b> End of initiation call</b>

9 illustrates an exemplary message flow that occurs when the end-of-call timer expires and the MCU ends the group call. When the end-of-call timer expires ( 902 ), the MCU may send a notification to the participant that the call is ending ( 904 ). Each client receiving the call termination notification may respond 906 with an acknowledgment (ACK). Upon receiving the acknowledgment, the MCU may notify the RD that the call has ended and may release the resources allocated to the call (908).

<b>Sending an alert</b>

The alert mechanism may be used to notify target users of an expression that another user, the alert originator, wants to join the group call. The alert mechanism may include a text message that allows the caller to specify the subject of the call, the desired call time, or other user customizable text message. 10 illustrates an example message flow that occurs when a user sends an alert.

The sender may select ( 1002 ) one or more target users, one or more predefined groups, or a combination thereof, and may indicate that an alert may be sent. The client may send a request to the RD that sends an alert to the target users specified in the request. When the RD receives the request ( 1006 ), the RD may expand a predefined group, specified in the request, to the target user member list, and the RD may retrieve location information of the target users. After the RD locates the at least one target user, the RD may send a response back to the client ( 1008 ). The RD may allocate a warning request to the MCU ( 1010 ), and broadcast a warning message to target users ( 1012 ).

As noted with respect to FIG. 10 , the alert request may be transmitted via a short data burst (SDB). The sending of alerts via SDB messages causes the packet data sessions of the parties involved to remain dormant. The alert notification contains the information needed to allow the target user to set up a group call with the caller and the rest of the target users, for example by selecting the alert notification and pressing PTT. When this occurs, the group call setup proceeds similarly to the call setup scenario described with respect to FIG. 4 .

<b>Late Join</b>

If the member list that may be specified in the call setup request is the same as the member list associated with a call already in progress in the system, the group call setup request is considered a late join. This situation can occur in one of two ways: First, the user may create the same member list as they already have the associated call by selecting the exact same user(s) and/or group(s) and pressing the PTT button. Second, the user may select from the call history list a call that is still running in the system and press PTT. In all cases, the RD may detect that the call the user requested to initiate is already in progress and treat the user as a late join.

11 illustrates an example late join case in which a user may select a call from a call history list. The user may select a call from the call history list and press the PTT button ( 1102 ). The client may send a request to the RD to initiate a group call ( 1104 ). The RD may determine if the call is already running ( 1106 ) and send a response to the client that the user is adding to the ongoing call ( 1108 ). If the call is already running, the current call participant may already be holding the floor until the late joining user is ready to receive the medium (ie, when the packet data session comes out of dormancy). may not be granted the floor. The RD may require the MCU to host the call to add the late joining user to the group ( 1110 ). The MCU adds the user and sends a notification to the user including the contact information of the MCU ( 1112 ). After re-establishing the traffic channel of the late joining user, the media flow in the call may be transmitted to the user. At this time, a user who joined late may try to request a privilege for the call.

The late joining scenario is similar to the scenario for initiating a new group call described with respect to FIG. 4 . The difference is that the late joining user is denied the floor in response to the initial group call setup request.

<b>speaker adjustment</b>

In one embodiment, each group call user is assigned a user pre-emption rank that determines the level of rights that user has when claiming privileges to occupy the "floor" and initiate a call. After the group call is set up, the MCU may control the floor and may determine whether a participant requesting the floor may be allowed to call. When two or more call participants compete for floor control for a particular group, the MCU may perform speaker coordination.

12 depicts example events that may occur during an adjustment process. The coordination scheme used in this scenario allows user B to preempt when user A requests the floor. When user A requests call authorization by pressing the PTT button, user B has control of the floor (ie, user B is talking). The client may send a message to the MCU requesting a call grant ( 1204 ). The MCU may perform speaker coordination ( 1206 ) and determine whether User B can be preempted and whether User A can be granted a floor. To ensure cessation of media flow (ie, user B may stop the call before user A's media is transmitted), the MCU sends a message to the client to user B indicating that the floor has been preoccupied by another user. It first transmits 1208 and then sends a response granting the floor to user A.

<b>Addition of users to activation group call</b>

The group communication system 100 allows group call participants to add new users to an ongoing group call. This is accomplished by call participants selecting one or more target users, one or more predefined groups, or a combination thereof, and the participants indicating that they want to add the target to an existing group call. 13 illustrates an event that occurs when a new target is added to an ongoing group call. A call participant may select ( 1302 ) one or more users, one or more groups, or a combination thereof that should be added to the call. The client may send a message to the RD requesting to add specific target users to the ongoing group call ( 1304 ), which may be specific to the request. When the RD receives the request, it may expand the predefined groups specific to the request to the target user member list. The RD may then retrieve the target user's location information ( 1306 ). After the RD is located at the at least one target users, the RD may send back a response to the client indicating that the target is being added to the call ( 1308 ). The RD may send a request to the MCU to add a call to specific users ( 1310 ). The MCU may send a call notification from a new target that may initiate a process to bring its packet data session out of dormancy ( 1312 ). The notification may be sent by a reliability schedule to ensure that the target receives the message. After the target's traffic channel is re-established, the target may send an acknowledgment (ACK) to the MCU ( 1314 ). Additional targets may be included 1316 in the signaling communication and the medium that is taking place in the call.

<b>Removal of members from activation group calls</b>

The group communication system 100 allows a group-call participant to remove members from an active group. In one embodiment, this may be accomplished by the call participant selecting one or more target participants and indicating that the participants should be removed from the group call. 14 depicts an example event that may occur when participants are removed from an ongoing group call. The group-call participant may select one or more target participants to be removed from the call ( 1402 ). The client may send a message to the RD requesting to remove from the group call the target, which may be specified in the message ( 1404 ). When the RD receives the request, it may retrieve the target's location information ( 1406 ) and may send back a response to the client indicating that the target has been removed ( 1408 ). The RD may send a request to the MCU to remove the target from the call ( 1410 ). The MCU may send a message indicating that it has been removed from the call to the target, which may be specified in the remove request ( 1412 ). The target may send an acknowledgment (ACK) to the MCU ( 1414 ).

<b>deregistration</b>

A deregistration function may be performed when the user no longer wishes to be contacted by another IP application or application server that uses the user's IP address to contact the user. The deregistration function removes the user's IP address and other contact information from the RLS and frees any resources allocated on the user's behalf. 15 illustrates how user registrations are removed from RLS as a result of a powered down mobile station, in accordance with one embodiment. The client may receive an indication that the mobile station on which the client resides has been powered down ( 1502 ). As part of the shutdown process, the client may send a message to the RLS indicating that the user's location information should be removed ( 1504 ). The RLS may authenticate the request to ensure that it was generated from a valid source ( 1506 ). When authentication is successful, the RLS may notify the client of a successful indication ( 1508 ) and the RD of the removal of the user ( 1510 ). An RD may remove user data records from its cache, and may free up resources that may be allocated to users. If deregistration fails, when the time associated with the expiry field elapses, eventually the user's location information may be removed from the RLS.

In one embodiment, the group communication system 100 supports both a chat-room model and an ad-hoc model. In the chat-room model, groups that may be stored on the dispatch server are predefined. The predefined groups are public groups that indicate that the group has an open member (ie, any dispatch user is a potential participant). In a chat-room, a call is initiated when the first person accepts to join the chat-room, and regardless of call activity, for a predetermined amount of time that may be configured by the service provider, the server resources allocated to the call are freed up. and the call continues to run. In particular, users request joining and aborting these types of calls. As described above, during the call inactivity period, each call remains in the group dormant state until the user requests call authorization.

In the ad-hoc model, groups may be defined in real time and may have a closed member list associated with them. A closed member list may specify whether users will be allowed to join the group, may not be available to users outside that closed member list, and may exist only for the lifetime of the call. Ad-hoc group definitions may not be stored anywhere, and the definitions can be used to establish a call and released after the call ends.

An ad-hoc group may be formed when a caller makes a request that is sent to a server to initiate a call and selects one or more target users. Target users may be sent a notification that they have been included in the group, and may be automatically joined to the relevant call (ie, no user action may be required). When an ad-hoc call becomes inactive, the application server may "tear down" the call and free related resources, including the group definition used to initiate the call.

When operating in the chat-room model, in the group communication system 100, a group of communication device users, individually known as net members, communicate with each other using the communication device assigned to each net member. The term "net" refers to a group of communication devices that are authorized to communicate with each other.

In one embodiment, the central database may contain information identifying members of each particular net. More than one net may operate in the same communication system. For example, the first net may be defined to have 10 members, and the second net may be defined to have 20 members. The ten members of the first net can communicate with each other, but not with the members of the second net. In other embodiments, members of different nets may monitor communications between members of one or more nets, but may only transmit information to members within their own nets.

The net may operate on conventional communication systems without requiring substantial changes to the conventional infrastructure. Accordingly, the controller and users of the net may be a code division multiple access (CDMA) system, a time division multiple access (TDMA) system, a Global System for Mobile Communications (GSM) system, a satellite communication system such as Globalstar or Iridium, or various other The system may operate on any system capable of sending and receiving packet information using Internet Protocol (IP).

Net members may communicate with each other using assigned communication devices, shown as communication devices (CDs) 120 and 122 . CDs 120 and 122 are terrestrial cordless telephones, cordless telephones with push-to-talk (PTT) capability, satellite telephones with PTT capability, wireless video cameras, still cameras, audio devices such as music recorders or players, laptops or It may be a wired or wireless communication device, such as a desktop computer, a paging device, or a combination thereof. For example, CD 120 may include a wireless land phone with a video camera and a display. In addition, each CD may transmit and receive information in a secure mode or a non-secure (clear) mode. Throughout the following description, references to individual CDs refer to wireless PTT phones. It should be noted, however, that the criteria for an individual CD is not intended to be so limited, and may include other communication devices having the ability to transmit and receive packet information according to the Internet Protocol (IP).

In group communication system 100, in general, a transmit privilege allows a single user to transmit information to other net members at a given time. Transmit privileges are granted or denied to the requesting net member based on whether the transmit privileges are currently assigned to other net members when the request is received. The process of granting and rejecting transmission requests is known as arbitration. In determining whether the requesting net member is granted the transmit privilege or not, the coordination scheme is based on factors such as the priority level assigned to each CD, the number of unsuccessful attempts to obtain the transmit privilege, and the length of time the net member has the transmit privilege. factor, or other factors.

In order to participate in system 100 , each of CDs 120 and 122 may have the ability to request transmit privileges from a controller or MCU 116 . MCU 116 may manage the management operation and actual time of the group. An MCU is any type of computer-type device having at least one processor and memory. Assuming authentication is provided by the service provider, MCU 116 may operate remotely through the communication system service provider, member, or both. MCU 116 may receive the group definition through an external management interface. Group members may manage net functions through a defined system or request management actions through a service provider, such as a member-operated security manager (SM) conforming to the MCU management interface. MCU 116 may authenticate a party attempting to establish or change a net.

The SM may perform tasks related to key management, user authentication, and supporting the secure net. A single group communication system may interact with more than one SM. The SM may not be involved in real-time control of the net, including net activity or PTT coordination. The SM may have a management capability compatible with the MCU, in order to automate the management function. The SM may also serve as a data endpoint for joining a net, broadcasting a net key, or simply monitoring net traffic.

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

In one embodiment of the present invention, each wireless net member establishes forward and reverse links with one or more base stations 126 or, alternatively, with satellite gateways (if any). Voice and/or data may be converted into data packets using, for example, a CD suitable for a particular distributed network 128 in which communications with other users may occur. In one embodiment, 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 broadcast information from each net member to another net member. Each net member may receive communications from other net members via a dedicated channel. In another embodiment, a dedicated reverse link is established in each communication system to transmit information to MCU 116 . In an embodiment, a combination of the above approaches may be used. For example, one scheme may include establishing a dedicated forward broadcast channel but requiring the wireless CDs to transmit information to the MCU 116 over a dedicated reverse link assigned to each CD.

When a first net member wishes to transmit information to other members of the net, the first net member presses the PTT key on its CD which generates a formatted request for transmission over the distributed network 128 . As a result, it is possible to request transmission privileges. For CDs 120 and 122 , the request may be transmitted over the air to one or more base stations 126 . A mobile station switching center (MSC) 130, which may include a packet control function (PCF) for processing data packets, a packet data serving node (PDSN), or a well-known interworking function (IWF), is distributed with the BS 126 . It may exist between networks 128 . The request may be sent, via the Public Switched Telephone Network (PSTN), to a modem bank, which may receive the request and provide it to the distributed network 128 . The terminal may monitor the traffic of the system 100 via a connection to the distributed network 128 .

If no other member currently holds transmit privilege, when MCU 116 receives the transmit privilege request, MCU 116 may send a message to the requesting net member notifying that transmit privilege has been granted. The auditory, visual, or other information from the first net member may then be transmitted to the other net members by transmitting the information to the MCU 116 using one of the transmit paths described above. Then, in one embodiment, MCU 116 provides the information to other net members by replicating the information and sending each duplicate to the other net members. If a single broadcast channel is used, the information must be copied only once during each broadcast channel is used.

In another embodiment, MCU 116 is included in MSC 130 so that data packets from supporting base stations are routed directly to MCU 116 rather than to distributed network 128 . In this embodiment, MCU 116 is still connected to distributed network 128 so that other communication systems and devices may participate in group communication. In another embodiment, MCU 116 may be included in a PDSN module or PCF module of MSC 130 .

In one embodiment, MCU 116 maintains one or more databases that manage information related to individual net members and each defined net. For example, for each net member, the database may contain such net information as the user name, account number, telephone number or dial number associated with the member's CD, the mobile station identification number assigned to the CD, and whether the member is actively participating in the net. information such as the status of the current member in may be Also, other information of a related type may be stored by the database for each net member.

In one embodiment, the CD may establish connections with individual communication terminals to form a talkgroup or net. An MCU may include various functional capabilities in hardware and software that are configurable in different ways to accommodate different applications. MCU has the ability to manage real-time operation of the net, management operation, and authentication operation, push-to-talk (PTT) request coordination, maintenance and distribution and registration list of net membership, It may provide full control of call setup and tear-down, system and network resources, and net state.

The net may exist in a standalone deployable cellular system or in a large multi-site configuration. For large-scale configurations, multiple MCUs may be geographically deployed to form a single integrated system, each acting as a plug-in module into a conventional cellular infrastructure. As such, the novel features introduced by the net are available to cellular users without changes to the conventional cellular infrastructure.

The MCU may maintain a list of defined nets. In one embodiment, each net definition includes a list of members including a net identifier, phone number or other identifying information, user priority information, and other general management information. A net can be statically defined as clear or secure, and transitions between clear and secure are not allowed. Typically, secure nets use medium encryption to provide authentication and prevent eavesdropping. Media encryption for the secure net is implemented on an end-to-end basis, meaning that encryption and decryption may occur within the communication device. The MCU may operate without knowledge of security algorithms, keys, or policies.

16 shows an example grouping 1600 to illustrate how communication devices 1602 , 1604 , and 1606 interact with MCU 1608 . Multiple MCUs may be deployed as required for large groups. In FIG. 16 , CD 1602 authorizes transmission of the medium to other members of the group. In this case, CD 1602 is known as the speaker and transmits the medium over the channel. If CD 1602 is designated as the speaker, the remaining participants, CDs 1604 and 1606, may not authorize transmission of the medium to the group. Accordingly, CD 1604 and CD 1606 are designated as listeners.

As described above, CDs 1602 , 1604 , and 1606 are connected to MCU 1608 using at least one channel. In one embodiment, the channel is divided into separate channels including a Session Initiation Protocol (SIP) channel 1610 , a media signaling channel 1612 , and a media traffic channel 1614 . The SIP channel 1610 and the media signaling channel 1612 can be used at any time as bandwidth allowances by any CD 1602 , 1604 , and 1606 , regardless of the designated speaker or listener. SIP is an Internet Engineering Task Force (IETF) defined application layer protocol that describes a control mechanism for establishing, modifying, and terminating multimedia sessions operating over the Internet Protocol (IP). SIP supports mechanisms for registering and locating users, defining user capabilities and describing media parameters, and mechanisms for determining user availability, call setup, and call-handling, thereby enabling call- Provides general solutions to signaling problems.

In one embodiment, SIP channel 1610 is used to initiate and terminate participation in group 1600 of CDs. Session Description Protocol (SDP) signals may also be used within the SIP channel 1610 . Real-time call control and signaling between the CD and MCU takes place, for example, by using the NBS media signaling channel 1612 , when the participation of the CD in the group is set up, for example, by using the SIP channel 1610 . do. In one embodiment, the media signaling channel 1612 handles PTT requests and releases, arbitrates between opposing requests or floor control, notifies the start and end of information transmission, manages net dormancy, and endpoints It is used to track connections, request and exchange net status, and notify any error messages. The protocol of the media signaling channel 1612 minimizes the length of the most common messages and simplifies the task of interpreting responses and responding to requests while maintaining flexibility for future enhancements. Also, the protocol of the media signaling channel 1612 allows requests to be retransmitted without adversely affecting the protocol state.

In one embodiment, the signaling traffic for the media signaling channel 1612 includes call setup and control signaling, which may consist of session invitation requests and acknowledgments (ACKs), and real-time floor control requests and associated asynchronous messages. media signaling, which may consist of Media traffic for the media traffic channel 1614 may consist of real-time point-to-multipoint voice and/or data broadcasts. These two messaging categories have unique functional properties. Each CD may also generate domain name service (DNS) client requests, facilitating mapping of fully verified DNS hostnames to Internet network addresses.

In one embodiment, call setup and call control signaling are performed according to the SIP structure. Although SIP may be transmitted using the well-known User Datagram Protocol (UDP) or Transmission Control Protocol (TCP), in one embodiment, each CD uses UDP to perform SIP-based signaling functions. In addition, each CM may expect to receive a SIP signaling request through UDP. Real-time signaling may occur via a dynamic UDP/IP interface on the CM and each CD. Other signaling may occur over a fixed TCP/IP interface between the CM and the CD, for example using SIP.

<b>PTT</b><b></b><b>latency</b>

In one embodiment, when packet data service is active, resources and radio links in infrastructure such as, for example, base station transceiver subsystem (BTS), base station controller (BSC), interworking function (IWF) and the mobile station ( MS) is actively assigned. In an IP-based VoIP dispatch service, packet data connections to each user are actively maintained while there is an active conversation between group participants. However, after a period of inactivity in group communication, e.g., "hang time," user traffic channels may go into a dormant state.

Transitioning to a dormant state conserves system capacity, reduces service costs and battery consumption, and allows users to receive conventional voice calls. For example, if a user is in an active packet data call, it is generally considered "busy" for an incoming voice call. If the user's packet data call is dormant, the user may receive an incoming voice call. For this reason, it is desirable to put the packet data call to a dormant state after a period of packet data inactivity.

When data packets are not exchanged but packet data calls are active, radio frequency (RF) energy may still be transmitted, albeit at a low level, by the mobile phone to maintain synchronization with the base station and power control. Such transmissions may result in significant power consumption for the phone. However, in the dormant state, the phone may not be performing RF transmissions. In order to conserve phone power and extend battery life, after an extended period without data transmission, a call end time may be set to put the phone into sleep mode.

PTT requests, which may be IP datagrams sent between the MS and the dispatch server, have very little latency when the packet data service is active for all users. However, if the user channel is pre-switched to dormant state, the PTT latency may be much longer. During the dormant state of the packet data, state information related to the packet data session may be maintained, including the mobile IP address. However, such as the physical traffic layer, state information related to layers below the PPP may be released and/or deallocated.

In some infrastructures, in order to wake up a dormant data connection, traffic channels must be reallocated, resources reallocated, and the radio link protocol (RLP) layer must be restarted. The impact of this is that when the user presses his PTT button to request the floor after the talkgroup has not talked for a while, the PTT latency for the first utterance is generally much longer than the PTT latency for subsequent utterances. will be Although this is relatively rare, it can affect the effectiveness of the service and should be minimized.

In one embodiment, to reduce PTT latency, group call signaling, such as floor-control requests, floor-control responses, and dormant wake-up messages, over some available common channel, without waiting for a dedicated traffic channel to be re-established. It can also be transmitted through This common channel may always be available irrespective of the state of mobile stations, and may not be required and reassigned whenever a user wants to initiate a group call. Thus, group call signaling can be exchanged even when mobile stations are dormant, and may provide a means to re-establish a dedicated traffic channel for the talker and listener mobile stations in parallel.

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

<b>short data </b><b>burst</b><b> call-</b><b>signaling</b><b> message</b>

In one embodiment, for example, using a short data burst (SDB) message provided in the "TIA/EIA/IS-2000 Standards for cdma2000 Spread Spectrum Systems," herein referred to as the "cdma2000 standard," A significant reduction in overall dormant wake-up time and PTT latency perceived by the speaker may be achieved. In one embodiment, the SDB message is transmitted over dedicated physical channels, such as a Forward Basic Channel (FCH) or a Forward Dedicated Common Control Channel (F-DCCH), or a Reverse Access Channel (R-ACH), a Reverse Extended Access Channel (R- EACH), forward common control channel (F-CCCH), or paging channel (PCH). The SDB message may be transmitted by means of the Radio Burst Protocol (RBP), which maps the message onto the appropriate available physical layer channels. Because SDB messages can carry arbitrary IP traffic and may be sent over a common physical channel, SDB messages provide a mechanism for exchanging group call signaling when the calling client's mobile station does not have a dedicated traffic channel. do.

<b>Lee Dong-guk</b><b>-Outgoing call-</b><b>signaling</b><b> message</b>

In one embodiment, the media-signaling message may carry IP datagrams over a reverse link or a mobile station-originating link. Whenever a user requests a floor and a dedicated reverse traffic channel is not immediately available, the client mobile station may signal the MCU quickly. If the client mobile station has released all dedicated traffic channels, the client mobile station may immediately forward the request over the reverse common channel of the radio infrastructure, which may relay the floor-control request to the MCU. For example, when a dedicated reverse channel is not available, a reverse access channel or a reverse extended access channel may be used to transmit such a message. In one embodiment, the client mobile station may send a floor-request message as an SDB message to the MCU.

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

The client MS may then begin re-establishing its dedicated traffic channel, for example, by performing "Resend Service Option 33". The client MS may also initiate Radio Link Protocol (RLP) synchronization. In one embodiment, the client MS may re-establish its dedicated traffic channel, and it may be desirable to synchronize the RLP concurrently with the transmission of the PTT floor request 404 .

Thus, when a mobile station does not have active dedicated traffic channels, the use of the available reverse common channels and/or SDB feature to signal a floor-control request to the CM reduces the overall time required to wake up participating mobile stations. Although the speaker client may not receive an acknowledgment that its floor-request has been granted until it re-establishes the speaker's forward traffic channel, the ability to quickly signal the CM to start waking up participating listeners reduces overall latency. Reduce.

Referring to FIG. 4 , the wireless infrastructure may transmit a PTT floor-control request 404 to a packet data service node (PDSN) and then to the MCU. In one embodiment, after receiving a floor-control request, the MCU coordinates the request, bursts media signaling wake-up messages (triggers) to a group of target participants (listeners), and/or or trigger the re-establishment of the traffic channel of the participants (listeners) ( 414 ). If the MCU grants the PTT floor request, the MCU may send a PTT floor grant 408 to the client MS. In one embodiment, if the client's dedicated traffic channel has not yet been re-established, the RD will send a PTT floor grant 408 to the client MS over available forward common channels, such as a forward paging channel and a forward common control channel. may be In one embodiment, the infrastructure may send the PTT floor grant 408 in SDB form to the client MS regardless of the channel used.

In an embodiment, the MCU may wait for an expiring dormant response timer before responding to the PTT floor-control request. If the group's dormant response timer is set to zero, the CM may immediately respond to the floor-control request. In one embodiment, if the client MS has completed re-establishing its traffic channel and RLP synchronization, the client MS may stream the stream media, which may have been buffered in the client MS, to the MCU (416) .

<b>Network - Outgoing Calls -</b><b>signaling</b><b> message</b>

In one embodiment, after receiving the floor-control request, the MCU may burst media signaling wake-up messages for a group of target participants (listeners), the traffic channel of the participants (listeners) may trigger the re-establishment of If the group's sleep state response timer is set to zero, the MCU may immediately respond to the floor-control request. In one embodiment, if the talker immediately begins re-establishing his traffic channel when sending the PTT request, it may be desirable to re-establish the caller's and listener's traffic channels at the same time.

Referring to FIG. 4 , after the MCU receives a PTT floor-control request, the MCU may transmit wake-up triggers 414 directed to target listeners. The MCU may determine whether a packet-data session exists for the target mobile station and forward the trigger packet to an appropriate infrastructure element (eg, a base station). The infrastructure may page each individual target MS to begin re-establishing its own dedicated traffic channel. The target MS may then begin re-establishing its dedicated traffic channel, eg, by performing "Resend Service Option 33". The target MS may also initiate radio link protocol (RLP) synchronization. In one embodiment, target MSs may re-establish their dedicated traffic channels, and it may be desirable to synchronize RLPs concurrently with the same function performed by the client MS.

In one embodiment, after the target MS completes the re-establishment of its dedicated traffic channel and the synchronization of its RLP, the target MS sends a wakeup reply indicating that the target MS is ready to receive the medium. may transmit to the MCU (422). The MCU may send a talker announcement to the client MS before streaming media that may be buffered in the MCU to the target MS ( 420 ).

In one embodiment, while the target listener's traffic channels have not yet been re-established, the MCU may transmit the wake up trigger 414 to the target listener over any available common forward channels, such as a forward paging channel and a forward common control channel. may be In one embodiment, the MCU may transmit the wake up trigger 414 in SDB form to the target listener regardless of the channel used. If the PTT floor-control request is sent as an SDB message through the talker's reverse common channel and the target group's dormant response timer is set to zero in the MCU, then the actual PTT latency at the talker client is based on the SDB response message on the forward link. may be reduced to the time required to transmit the SDB request message on the reverse link accompanied by the

<b>call-</b><b>signaling</b><b> network interface for messages</b>

In order to determine which network-origin specific traffic (eg, SDB payload) is sent for an idle mobile station that does not have a dedicated traffic channel, any infrastructure means or interface for identifying that specific traffic from other traffic. can also be implemented.

In the first embodiment, since SDB messages may carry a limited user payload, IP datagrams may be filtered based on their size. IP datagrams smaller than a certain size limit may be transmitted as SDB messages when directed to a mobile station that does not have dedicated traffic channels. The group communication system may use such filters when the application floor-request response message is much smaller, for example, 34 bytes including the IP header.

In a second embodiment, an infrastructure vendor may define an IP-based service to encapsulate IP traffic destined for delivery to a mobile station. An IP server aware of this service may send a small IP (eg UDP, a datagram suitably encapsulated with an IP header) to this service to deliver to a mobile station that is presumed not to have a dedicated traffic channel. . The group communication system may use this service to indicate to the infrastructure that the floor-request response message is to be delivered to the requesting client MS, for example in the form of an SDB. In addition, coordination of SDB traffic with pending page or service origination requests is important to ensure fast and reliable delivery of user traffic.

In the third embodiment, the IP server may transmit a special IP (eg, UDP, datagram with an IP header) for delivery to a mobile station that is presumed not to have a dedicated traffic channel. An IP server may tag an IP datagram, for example, by specifying a special value in the IP header, to instruct the infrastructure to forward the IP datagram to the client MS. The group communication system may use this service to indicate to the infrastructure that the floor-request response message is to be delivered to the requesting client MS, for example in the form of an SDB. In a third embodiment, a UDP or TCP port range may be reserved for carrying specific IP datagrams (eg, SDB messages).

<b>Lee Dong-guk</b><b>-Initiate service sending and </b><b>paging</b>

In one embodiment, the client may be in the form of a floor-control request 404 (SDB) immediately followed with a service origination request to the wireless (eg, CDMA) infrastructure to quickly re-establish its traffic channel. ) may be transmitted. However, if the dormant response timer is set to a small value, the RD may respond quickly to the floor-control request, sending a response 408 back to the client. If this response arrives at the infrastructure during the initial phase of a service origination transaction, the infrastructure notifies the speaker MS that it does not have an active traffic channel, and attempts to page the response to the speaker MS. However, such a paging action may abort a service originating transaction that is already in progress. In one embodiment, the talker MS may respond to a page ensuring delivery of a floor-control response message to the talker and request service origination again, but as a result of aborting the original service origination attempt, the talker's traffic channel We experience unnecessary delays when re-establishing .

In the first embodiment, in order to avoid a contention condition between the service origination process and paging, the RD may be configured not to immediately respond to the floor-control request 404 . Accordingly, the dormant response timer may be adjusted such that the MCU sends a response 408 to the speaker MS after completing the service origination process.

The second embodiment coordinates the PDSN receiving the response 408 and the Mobile Station Switching Center (MSC) responding to the speaker's request to originate service. That is, when response 408 arrives at the infrastructure, if the PDSN determines that the packet-data service origination process for the talker MS is already underway, the MSC defers the talker MS's paging. The PDSN may cache the response and, once the service origination process completes, transmit the response over the forward traffic channel of the speaker mobile station. Alternatively, if the service origination process is still in progress, the MSC may send the response as an SDB message to the speaker MS.

In the third embodiment, a talker MS may avoid a contention condition by not generating a service origination request until after the talker MS receives a response to the floor-control request. In one embodiment, since the talker MS does not have an active dedicated traffic channel, the MCU may transmit its response to the talker MS over any available forward common channels, such as a forward paging channel and a forward common control channel. In one embodiment, the MCU may send the response in the form of an SDB to the speaker MS. The speaker MS may rely on the RD-generated floor-control response to trigger its own traffic channel reactivation, in the same way that wakeup requests were sent by MCU triggered traffic channel reactivation for the listener mobile station. A contention condition is avoided by preventing the possibility of simultaneous occurrence of mobile-initiated service origination and network-initiated paging of the mobile station.

<b>network-initiated </b><b>packet</b><b> data </b><b>trigger's</b><b></b><b>caching</b>

IP datagrams containing a wake-up trigger 414 destined for a listener mobile station that arrives on a wireless (eg, CDMA) infrastructure and does not have a dedicated traffic channel are generally transmitted by the network, and more specifically, by the wireless subsystem It may be lost by the structure. In one embodiment, the wake-up trigger 414 transmitted to the listener mobile station is actively retransmitted according to a defined schedule, until either the listener's response or the group's wake-up timer expires. For example, the wake up trigger 414 may be retransmitted every 500 ms. However, retransmitting the wake-up trigger 414 at this rate, from the time the listener's traffic channel is re-established to the time the next wake-up trigger towards that listener arrives at the infrastructure, can be up to 500 ms or an average of 250 ms. It may cause delays.

In one embodiment, another entity in the infrastructure or network caches the wake up trigger 414 sent by the MCU and sends the wake up trigger as soon as the target MS re-establishes its traffic channel to the target MS. can also be forwarded to This eliminates the need for retransmission of wake up requests by the CM and reduces the overall dormant wake up time. For example, as opposed to retransmitting the wake up trigger 414 at a rate of 500 ms, caching the wake up trigger 414 may remove a delay of up to 500 ms from the total dormant wake up time.

<b>media </b><b>buffering</b>

In one embodiment, the user may be allowed to start a call after the user requests floor control by buffering the medium before the dedicated channel is re-established between the client and listeners. By buffering the speaker's call, the system allows the speaker to initiate the call before completely re-establishing the listener's traffic channel. This allows the talker to start a call earlier by reducing his/her apparent PTT latency. Because the listener does not experience PTT latency, their experience is not affected (ie, PTT latency is shifted from the speaker to other parts of the system). The speaker may wait until it receives a response to its first talk spurt from the listener, but, as described above, the response to its first utterance is dependent on subsequent utterances occurring while participating in an active conversation. It is expected in advance that it will take longer than a response. Buffering the first utterance of the speaker may be performed on the MCU side or on the client MS side.

<b>MCU</b><b>side </b><b>buffering</b>

In an embodiment, the MCU may buffer the speaker's first utterance. After the user presses his PTT button and re-establishes the user's traffic channel, the user may be allowed to communicate with the MCU. At this time, since the listener's traffic channel has not yet ended, the MCU buffers the speaker's call for future transmission to the target listener. MCU buffering may reduce the apparent PTT latency that the speaker believes is an appropriate time to generate the speaker's traffic channel. As will be described later, FIG. 17 illustrates MCU-side buffering according to an embodiment. in other words,

(1) There is no call in progress, and the traffic channels of the sender and the target are dormant.

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

(3) After the client receives a "setup in progress" response from the server, or after a configurable delay (1 second), the user is granted the floor, and buffering of the user's media begins.

(4) The server initiates the process of re-establishing the target's packet data traffic channel.

(5) Server sends "Group Call Notification" message to client through SDB.

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

(7) The client streams the media to the server.

(8) The target's traffic channel is re-established (the "target response threshold" is satisfied).

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

(10) The client ends streaming of the buffered media to the server and requests the release of the floor by the server.

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

<b>client side</b><b></b><b>buffering</b>

In one embodiment, where a shorter apparent latency is desired, the initiation of a call may be allowed even before the talker re-establishes his traffic channel. Since the client MS has not yet communicated with the MCU, a signal for the speaker to initiate the call is generated by the client MS. If the talker is allowed to call before the talker's traffic channel is re-established, the client MS may buffer the call. As communication with the CM has not yet been established, approval for the call is presented as "optimistic". As described below, FIG. 18 illustrates client-side buffering according to one embodiment. in other words,

(1) There is no call in progress, and the caller's traffic channel is dormant.

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

(3) The client initiates the process of the packet data traffic channel.

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

(5) Client receives "Group Call Notification" message from server through SDB.

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

(7) The client streams the buffered media to the server.

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

(9) The client ends streaming of the buffered media to the server and requests the release of the floor by the server.

(10) The client receives an acknowledgment (ACK) of the floor release from the server.

In one embodiment, MCU buffering 418 and client-side buffering 412 may operate concurrently. Client-side buffering may shorten the apparent PTT latency. In one embodiment, the client MS may buffer the medium to control the apparent PTT latency experienced by the user. The combination of mobile-originating SDB and client-side media buffering may reduce the delay associated with re-establishment of an active traffic channel.

As such, the disclosed embodiments provide a dispatch model that supports at least two types of dispatch calls: a chat-room model and an ad-hoc model. In the chat-room model, groups that may be stored on the dispatch server are predefined. However, in an ad-hoc model, groups may be defined and/or changed in real time.

In addition, the disclosed embodiments significantly reduce the actual overall dormant wake up time and PTT latency by exchanging group call signaling even when mobile stations are dormant and the traffic channel is not active. The method and apparatus exchange group call signaling using short data burst (SDB) message signaling. Preferably, the method and apparatus simultaneously re-establish dedicated traffic channels for the speaker mobile station and the dormant listener mobile station.

In another embodiment, dormancy-wake latency in a group communication network may be reduced by caching network-initiated wake-up triggers directed at target listeners and forwarding the wake-up trigger to the target mobile station as soon as the target mobile station re-establishes its traffic channel. have.

In another embodiment, service origination and paging at mobile stations operating in a group communication network are prevented simultaneously by sending a response to the floor-control request after the service origination process is completed. In one embodiment, if the service origination process is not completed, the response to the floor-control request may be in the form of an SDB. In another embodiment, the service origination process for the source communication device is initiated after sending the response to the source communication device.