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

The present invention relates to a point-to-multipoint communication system. In particular, the present invention relates to methods and devices for adding new members to active group calls in a group communication network.

Classes of wireless services for fast, efficient, one-to-one or one-to-many (group) communications have existed in various forms for many years. Generally, these services are semi-dual, and the user presses the "push-to-talk (PTT)" button on the telephone device / radio to start talking. When communicating through some type of server, pressing a button or key on a radio in some configuration, or suitable system, indicates that the user is requesting a "floor". The user generally speaks for a few seconds when given the floor, i.e. the speaker's permission, and then releases the PTT button, allowing other speakers to request the floor. Communication is generally from one speaker to a group of recipients rather than one-to-one. This service has long been used in applications when one person, or "dispatcher," needs to communicate with a group of people, such as field service personnel or taxi drivers. The "dispatcher" is derived from the name for "dispatching (shipping)" a service.

Similar services are offered on the Internet and are commonly known as "voice chat". These services are typically voice-over-IP services that send vocoder frames in Internet protocol (IP) packets to a central group chat server, or perhaps peer-to-peer services and clients. Runs as a personal computer application sent from to the client.

An important feature of these services is that communication is initiated quickly and automatically, usually simply by pressing the PTT button, without going through the usual dialing and ringing sequence. Communication for this type of service is generally very short, with individual talk "sparts" usually on the order of a few seconds, and the duration of a "conversation" is probably less than a minute.

The time delay (known as PTT latency) between when a user requests a floor and when a user has a floor and receives an affirmative or negative confirmation from the server to start talking is half. It is an important parameter in the dual group communication system. As already mentioned, the dispatch system prioritizes short, or short conversations, and therefore increases the effectiveness of the service as the PTT latency increases.

The existing group communications infrastructure has limited opportunities to significantly reduce PTT latency. That is, the limitation is that the actual PTT latency is probably not less than the time required to reconfigure the traffic channel within a dormant packet data session. In addition, the only mechanism available to start a hibernate group is to wait for the speaker's traffic channel to be reconfigured and then signal the server, so the speaker and receiver The traffic channel with the person is configured in series. Currently, there is no mechanism for sending user signaling data generated by mobile stations other than the traffic channel, and therefore there is a restriction that communication between the client and the server becomes possible after the traffic channel is reconfigured. ..

<p> Therefore, it reconfigures the apparent PTT latency experienced by the speaker and the traffic channels of participating mobile stations without negatively impacting system capacity, client battery life, or other resources. There is a need for a mechanism to reduce both the total time required for the client.</p><p> In the dispatch model, communication between endpoints takes place within a virtual group, with the voice of one "speaker" being broadcast to one or more "receivers". An example of this type of communication is commonly referred to as a dispatch call, or simply a call. A call is a group instantiation, which is essentially a member list that defines the characteristics of the call and has some relevant information, such as a group name or group identifier. The member list is a list of one or more users invited to join the call.</p><p> There is a need for a dispatch model that supports both the chat room model and the provisional model of group call services. In the chat room model, groups are predetermined and stored on the dispatch server. However, in the interim model, groups are defined in real time, modified, or both.</p>

<p> The disclosed embodiment is a novel and improved method in a communication device for adding a member to an active group call in a group communication network, receiving a member list from a user and a member to the active group call. Provides a method that includes sending a request to add a list to the server.</p><p> In another aspect of the invention, the computer readable medium in the communication device is a method for adding members to an active group call in a group communication network, embodying a method comprising the steps described above. In another aspect of the invention, a communication device for adding a member to an active group call in a group communication network, a means for receiving a member list from a user, and a request to add a member list to the active group call. Includes means for sending to the server.</p><p> In another aspect of the invention, a communication device for adding a member to an active group call in a group communication network includes a receiver, a transmitter, and a processor that is communicatively connected to the receiver and transmitter. .. The processor can receive the member list from the user and send a request to the server to add the member list to the active group call. In one embodiment, the communication device is a push-to-talk (PTT) device.</p><p> The disclosed embodiment is a novel and improved method in a server for adding members to an active group call in a group communication network, with the step of receiving a request to add a member list from the active group call and the active. It also provides a method that includes a step to add a member list from a group. In one embodiment, the method further comprises announcing to each member in the member list that they have been added from a group call.</p><p> In another aspect of the invention, the computer readable medium in the server is a method for adding members to an active group call in a group communication network, embodying a method comprising the steps described above. In another aspect of the invention, a server for adding members to an active group call in a group communication network, a means for receiving a request to add a member list to the active group call, and an active group call. Includes means for adding member lists. In one embodiment, the server further comprises means for each member in the member list to announce that they have been added to the group call.</p><p> In another aspect of the invention, a server for adding members to an active group call in a group communication network includes a receiver, a transmitter, and a processor that is communicatively connected to the receiver and transmitter. The processor can receive a request to add a member list to an active group call and can add a member list to an active group call. In one embodiment, the processor can additionally announce to each member in the member list that they have been added to the active group call.</p>

Prior to elaborating on one embodiment of the invention, the invention is not limited in its application to the details of the configuration and arrangement of components described in the following description or shown in the drawings. You will see. It will be found that the present invention can be realized in other embodiments implemented in various ways. In addition, it will be found that the technical terms and terms used herein are for illustration purposes only and should not be considered restrictive.

FIG. 1 shows an exemplary functional block diagram of the 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, and a point-to-multipoint communication system. In one embodiment, the group communication system 100 includes a dispatcher, a location server, a media control unit (MCU) complex, a log server used, and an Internet Protocol (IP) client (a wireless device or wire connected to an IP). Includes application server components such as line devices, or both). The application server components are placed either centrally or intra-regionally, depending on the functionality of the components. Centrally located, home dispatcher (HD) 102, home location server, Includes HLS) 104, and user / group database 106. These components are centrally located within the service provider network and are accessible by intra-regional placement. The central component is used to locate the user while roaming and to initiate a group call between regions. Intraregional arrangements 108 and 110 are regional location server (RLS) 112, regional dispatcher (RD) 114, media control unit (MCU) complex 116, and regions. Includes usage log server (ULS) 118.

Intraregional placement ensures that the network delay associated with call setup is kept to a minimum in order to spread across the service provider network and satisfy instant response requests. Distributing call loads across a system divided into several areas also ensures that appropriate scalability schemes can be deployed to assist large numbers of users. The intra-region application server component is responsible for user registration, setup and management of intra-region calls, and initiation and transmission of alerts to users registered within the region.

Group communication devices (clients) 120, 122 are located, for example, on a cdma2000 handset and use standard data service options to request a packet data session and use this session to apply an IP address. Register with the server and start a group call. In one embodiment, the application server components 108, 110 are connected to the packet data service node (PDSN) of the service provider. Clients 120, 122 make IP connections with application server components 108, 110 via the PDSN when requesting a packet data session from the wireless infrastructure.

Clients 120, 122 use the data service option to request a packet data session during power-up. The client is assigned an IP address as part of setting up a packet data session. At this time, the client also receives the address of the domain name service (DNS) server 124. Clients 120, 122 query DNS server 124 to find the address of RLS112, for example by using a service record (SRV) lookup. After identifying the location of RLS112, the clients 120 and 122 register and notify the location information, for example, the IP address to the application server. Registration is a session initiation protocol, on the user datagram protocol (UDP). It is done using an IP protocol, such as SIP). The IP addresses of clients 120 and 122 are used to contact the client when the user is invited to a group call.

In one embodiment, the client looks up the SRV record in another DNS to discover the address of the intra-regional dispatcher 114 after registration is complete. The client contacts the intra-regional disperser whenever the user requests that the call be initiated or sends a warning. The interface between the intra-domain dispatcher 114 and the clients 120, 122 is a signaling protocol over UDP.

When a group call is set, clients 120, 122 and the MCU complex 116 exchange media and signaling messages. In one embodiment, the medium is sent between the call participants and the MCU complex 116 using real-time protocol (RTP) over UDP. Signaling messages are also signaling protocols over UDP. These protocols and the functions they provide will be described separately.

Component The group communication system 100 includes an IP endpoint, which includes client software, intra-regional server components, and a central server component, which are required to provide group communication services. .. Group communication client and application server components are described in more detail in the sections that follow.

client Group communication clients 120, 122 run on IP endpoints that access the appropriate vocoder. IP endpoints include wireless systems such as cdma2000, application development platforms such as the binary runtime environment for wireless (BREW), and applications running on personal computers.

The client contains software applications deployed using BREW, interfaces with mobile station modem software (MSM), and is downloaded to the client, including the BREW environment. Developers can use the BREW platform to generate applications that run on client communication devices. Application developers use BREW as a separate layer for MSM software and original equipment manufacturers, OEM) Applications can be developed without direct contact with software. This allows applications to be developed quickly and developed independently of MSM software, OEM software, or both. In addition, the application can be downloaded to any device, including the BREW environment. As shown in FIG. 2, the client group communication application software 202 runs in parallel with the other applications 204, 206, 208, and 210. These services are provided directly by the OEM212 and MSM214 interfaces, but BREW separates them from the changes made by the application at these layers. Therefore, OEM212 and MSM214 can evolve individually from data applications 202, 204, 206, 208, 210.

For the client to work effectively on the personal computer, the personal computer includes access to a compatible vocoder, access to the sound driver, and an IP connection to the application server. Location server In one embodiment, the location server (LS) receives and / or maintains the user's location information. The user's location information is broadcast and packeted in the air over, for example, a network-level IP address, the user's physical location such as longitude and latitude, and / or a packet zone identifier, ie, a forward common channel. A system identifier that identifies the range of PDSNs that supply data services to that sector. In one embodiment, the LS comprises a component that processes registration from a client and supplies user location information to other applications such as instant messaging using a SIP interface.

The LS includes two functional elements: the regional location server (RLS) 112 and the home location server (HLS) 104. RLS112 is arranged in each area, and HLS104 is located in the center. Details of these elements and functions will be described separately.

In-region location server RLS112 processes and maintains registrations from clients located within that area. In one embodiment, the RLS 112 is a standard SIP-based LS with ancillary memory for user location information. RLS112 checks the expiration date, or "expiration" range, of each registration as part of maintaining the registration entries. RLS deletes expired entries and ensures that the regional dispatcher (RD) and HLS are informed of the deleted entry.

As described above, the client performs IP registration and notifies the application server of its location. The client maintains its registration for as long as the group communication service is available. The client re-registers when the client's IP address changes and when the registration is about to expire.

When the client registers or re-registers, RLS112 notifies the associated RD114. Therefore, the RD114 can preload user data when preparing a call setup request to reduce call setup time. The RD114 caches the user's location and eliminates the need to contact the RLS during call setup to retrieve the user's location.

The RLS112 notifies the RD114 when it updates or removes the user's location information from the RLS112. Therefore, the RLS112 and RD114 are guaranteed to stay in sync with the latest information about users registered in the area. In addition, the RLS112 periodically updates the HLS104 with the location information of the registered user. When RLS112 submits to HLS104 the registration of a user who already has a valid registration in another area, HLS resolves the conflict.

Home location server The HLS104 handles queries for the user's location information. In one embodiment, the HLS 104 provides a SIP-based interface that allows other applications, such as instant messaging applications, to query the location of individual users.

When HLS104 is the central component and RLS communicates with it, HLS analyzes a number of registrations made by roaming users in different areas. The HLS104 receives registration information from each of the RLSs. When the HLS104 receives a large number of registrations for the same user, the HLS104 requires that the recent registration be maintained and the old registration for that user be removed from the RLS. It also triggers the removal of cached information about the user from the RD114 associated with the RLS containing the old registration.

dispatcher The dispatcher prompts the call setup by locating the user and assigning the group call to the media control unit (MCU) complex 116. A dispatcher is a server component that is the key to satisfying "instant access" requests. The dispatcher contains two functional elements that have similar structure and functionality but different placement schemes to guarantee a minimum call setup time. These two elements, the regional dispatcher (RD) 114 and the home dispatcher (HD) 102, will be described in detail in the sections that follow.

Intra-domain dispatcher RD114 is the first point of contact for call setup and alert requests. The RD114 preloads the user information when it receives an instruction from the RLS 112 that the user has registered. The RD114 caches information about group calls being made in the system along with user information. The RD114 uses cached information about users and groups during call setup, ie, eliminates the need to look up the database and keeps setup time to a minimum.

In one embodiment, the group information stored in the cache by the RD includes a group member list and the address of the MCU complex 116 on which the group is located. The RD114 maintains the member list and MCU address for the life of the call. This helps the RD114 quickly determine if the incoming call needs to be in the same group as the group containing the associated call already running in the system, thereby causing the RD to determine. You can respond quickly to call setup requests and confidently accept or reject "floor" requests in response.

RD114 accepts or rejects the floor control request. RD114 determines whether to require the MCU complex 116 to add the user to the call as a "delayed join" participant or to initiate a new call with the associated member list. The RD114 uses the cached user information during the processing of the call setup request to retrieve the location information of the user specified in the call setup request. If the user's location cannot be determined, the RD114 requests the HD 102 to locate the user. In one embodiment, the RD 114 continues to set up the call when at least one target user is located. The RD114 determines which MCU to assign the call to after the target user's location has been determined. This decision is based on the IP addresses of users in the group, including the caller.

The RD114 handles warning requests as well as call requests. In one embodiment, the warning request is assigned to the local MCU complex 116 for processing, regardless of the target user's location. In one embodiment, the information in the RD's cache is periodically written to a reliable memory mechanism and is therefore recovered in the event of a failure. When the RD fails, the user and group information written to the trusted memory mechanism is reloaded into the cache, and the RD is involved in processing the incoming call setup request and the cached information. Start to check.

In one embodiment, the RD 114 loads the user data into the local cache when notified by the RLS 112 of the registration of each user. By eliminating the need to look up several databases when setting up a call, the RD114 significantly reduces the time it takes to see and respond to a call setup request or warning request.

The RD114 accesses the user / group database 106 during call setup and, when in a request, extends a given group address to a list of individual users and, if necessary, on behalf of the user or group. Convert identifiers (eg phone numbers, conference IDs) to standard addresses.

Home dispatcher The home dispatcher (HD) 102 tracks the location information of registered users. HD includes the location information of the user registered in RLS112. As already mentioned, each RLS112 notifies the associated RD114 each time a user is registered, re-registered, unregistered, or the registration expires. The RD114 uses this information to load or release user information in the local cache. Each RD114 updates HD102 for user location information. Since the HD102 receives updates from the RD114, the HD102 helps detect users who are geographically dispersed across different regions. The RD114 requests assistance from the HD 102 when it receives a request for a user who is not currently registered in the area, that is, a user whose user information is not in the RD cache.

DNS server In one embodiment, the group communication system 100 uses the service provider's DNS server 124 to supply the location information of the RLS 112 and RD 114 to the client. This information is configured for each location within each region and is updated regularly to ensure its accuracy.

In one embodiment, each client requests a packet data session on a DNS server by negotiating an Internet protocol control protocol (IPCP) during the configuration of a Point-to-Point Protocol (PPP) session. Know the address. DNS server 124 is advertised region by region in this way. Therefore, the client can roam from region to region and communicate with the DNS server 124 in the same region where the client is located. The DNS server 124 is arranged together with each PDSN for each area. In one embodiment, the DNS server 124 is updated with each RD114 and RLS servicing the PDSN to which the DNS server 124 is associated.

In one embodiment, the mechanism used to locate the appropriate RD114 and RLS112 is based on a combination of DNS and SIP addressing. The lookup of the DNS service (SRV) record is based on the "&lt;domain&gt;" part of the SIP URI registered by the client. The SRV record request includes the protocol or service that the requester is trying to detect. For example, when attempting to locate the RLS112, the client requests a "registration service" in the lookup of the DNS SRV record. The DNS response contains one or more valid networks and the port address of the server providing the requested service. When using the DNS server 124 to return a response to a client request, the DNS server 124 is round-robined among a large number of servers to balance the load among the servers that provide the same service.

User / group database In one embodiment, the user / group database 106 is a central repository for user and group information. For each user, the database contains information such as user addresses, preemption ranks, credentials, user contact information, and legitimate interception flags that indicate whether the user is being monitored. The database also contains a definition of a given group for the chat room model of the dispatch service, i.e. a list of users and associated group names. Each group is uniquely identified, for example, by a group database. The client uses the group address to identify the group in the group call setup request. When the RD114 receives a group call setup request with a given group in the user / group database 106, it uses the group address to look up the associated member list from there.

Media controller complex A complex of media control units (MCH) includes a media control host (MCH) and a media control unit (MCH). The MCH hosts and manages the processing of many MCUs. Each MCU handles real-time signaling and media processing for each call. The MCU performs the following functions: -Ability to handle call assignments from RD114; -Ability to send loading and status information to MCH; -Ability to send call start information to the client; · Ability to handle in-call signaling from clients, such as PTT requests; -A function that ensures that signaling messages are reliably transmitted to clients; -Ability to duplicate and distribute media in "one-to-many" calls; The ability to convert media using the appropriate transcoder in a "one-to-many" call of a "mixed" vocoder; · Ability to monitor call activity and initiate call termination based on lack of media flow activity; Ability to generate usage information for usage log server (ULS) 118; The ability to send media and signaling information to the appropriate legal interception point when requested.

The MCU processes the warning request from RD114, sends a warning notification to the client, and waits for an acknowledgment from the client. When the MCU receives an acknowledgment from the target user, it releases the resources allocated for the warning transaction. At this time, the MCU may process other call assignments or warning requests.

Usage log server ULS118 exists within each region and is placed with the MCU complex 116. ULS118 collects usage events from the MCU complex 116 for each call or alert process, formats them into a usage data record (UDR), and stores these UDRs in a series of UDR files. The UDR of a call contains information about the individual call, including a list of participants and total participant usage. The warning UDR contains information that indicates the originator of the warning and the target user to whom the warning was sent. UDR files are collected by the service provider for billing analysis and deleted after a period of time.

ULS118 writes one UDR at the end of each call, for each instance of the call. ULS118 writes a single UDR each time a warning request is processed. The UDR written by ULS118 contains the following information: -Call instance identifier or warning instance identifier; -MCU identifier. This suggests the position of the call. When initiating a call, the appropriate MCU is selected based on the registered locations of all prospective participants. The location of the MCU may or may not be in the same area as the caller; · Call or alert start time; · Call or alert end time; · Originating user's name and / or identifier; -IP address of the source user; · For each participant, username, user address, user IP address, cumulative participation time (warning may be zero), and total time (seconds) that participant held the floor (warning is zero) May be).

In one embodiment, one UDR is issued for each call. UDR represents the total collection of talk segments during a call. For each talk segment, when logging of events to the UDR is required, this is done at the expense of further processing load requirements, file I / O requirements, and disk space requirements.

The group communication system 100 performs several different functions to perform group services. Features related to the user experience include registration, call initiation, call termination, alert sending, late subscription, speaker mediation, user addition, member removal, deregistration, addressing, and authentication. .. Functions related to system readiness and operation include management and readiness, scalability, and reliability. These features are described in detail in the sections that follow.

Registration In a wireless communication system, for example, a CDMA system, registration is the process of making the location of a mobile station known to the infrastructure of the wireless communication system. This location information includes the geographic area where the mobile station is located and the identifier of the base station servicing the mobile station and is used to aid in the efficient use of paging and access channels.

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 wireline service. An exemplary IP protocol that allows an IP application to locate a client based on its IP address is Session Initiation Protocol (SIP). Among other things, SIP provides a way for clients to register their IP addresses and other location information with SIP server components. In addition, SIP provides a way for an IP application involved in "discovering" a client to query the same SIP server component for location information such as the client's IP address.

Registration involves the process by which an IP client communicates with a SIP server component to notify and maintain its location information, eg, an IP address. The SIP server component with this functionality is the location server. The method by which the client notifies the location server of its location or changes its location is the SIP REGISTER method.

In one embodiment, the client registers its location information with the intra-region location server. Other IP-based applications, such as instant messaging, take advantage of getting information about the IP address of each client available on the location server. An external service or client may perform the registration. FIG. 3 shows an exemplary call flow for performing the registration function.

At power-up 302, the client requests a packet data session and begins the process of registering its IP address with RLS112. The client looks up the SRV record in DNS and determines the address of 304, RLS in order to perform registration. When the client searches for the RLS address, it 306, and its location information is registered, for example, by using a SIP registration message 308. RLS authenticates the user 310 and issues a response to the client 312. The RLS notifies the intra-regional dispatcher that the user is registered 314, and the intra-regional dispatcher uses this information to preload the data record related to the user and respond more quickly during call setup. To urge. At this point, the client is contacted for solicitation to join the group call. In one embodiment, the client needs to register to receive a group call, regardless of the type of data connection it makes, whether wireless or wireline.

The registration has a range of "expired" associated with it. The range of "expired" indicates the period during which the client's registration information is considered valid. To ensure that the client is always reachable by IP, the client is aware of the expiration of the registration and re-registers before it expires. Registration can also be invalidated or revoked due to other environments, such as when the client's IP address changes or when the data connection between the client and the location server is lost. The client is aware of the state of the data connection and whether the IP address has changed.

Upon completion of the initial registration, the client hibernates its packet data session and releases its dedicated traffic channel. The client monitors its packet data session to ensure that it remains active for the duration of the hibernation. Situations that affect session validity include moving to areas with different packet zone IDs, experiencing fades or loss of service, and / or making PTSN calls. The client's IP address changes and the client is required to reconfigure the data connection with the infrastructure. When the client reconfigures 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 remains accurate. This is achieved by re-registering.

Wireline clients that communicate with the location server through the firewall need to maintain a hole through the firewall by periodically "pinging" the location server. This is achieved by re-registering. Group call start The user makes or receives a call after the registration is completed. The client looks up the DNS SRV record after power-up and before initiating the first call to find the location of the dispatcher in the region. This is done as part of the startup process.

A "group" is associated with a member list that includes the caller, the user who initiated the group setup, and one or more target users. The member list includes one or more users, one or more predetermined groups, or a combination of the two. When a member list contains only one user, calls initiated using that member list are commonly referred to as private calls. When the member list contains a given group, the intraregional dispatcher replaces the identifier of the given group in the original member list with the associated member list of the given group, for example. Extends to a list of one or more target users. After expanding a given group, the generated member list will include the target username. At this point, the intra-regional dispatcher attempts to locate the target user in the member list by scanning the intra-regional dispatcher's cache for user information. When the target user is located in the cache of the intra-region dispatcher, the members of the group are registered in the same region as the intra-region dispatcher. This type of group call is classified as an "intra-regional" call. When there is a user whose location cannot be located by the intra-regional dispatcher, the intra-regional dispatcher requests assistance from the home dispatcher to locate the user. Calls associated with groups that contain members from more than one region are called "interregional" calls.

After determining whether the call is within or between regions, the intra-regional dispatcher initiates the process of determining which media controller (MCU) will host the call. In an intra-regional call, the intra-regional dispatcher assigns a call to an MCU located in the same region as the intra-regional dispatcher when the resources of the MCU are available in that region. Calls generated using this type of call setup are called "locally hosted" calls, or local calls. In inter-domain calls, intra-regional dispatchers have the option of assigning calls to MCUs within the same region or to MCUs in remote or external regions. The intra-regional dispatcher makes this decision based on the user's location information to discover the optimal travel route for IP packets, including media and signaling. When the majority of users are located within a particular area, the call is assigned to that area. When the users are evenly distributed across the regions, the call is assigned to one of the regions that contains the target user. When an inter-regional call is assigned to an MCU in a different region than the region where the intra-regional dispatcher is located, the call is called a "remotely hosted" or remote call. When intradomain dispatchers know about the network topology and / or connectivity between MCUs and the PDSNs they serve, they use this knowledge to better determine call assignments.

Intraregional call The group communication system 100 is arranged to ensure that the majority of calls are within the region. Intraregional calls eliminate the need for intraregional dispatchers 114 and home dispatchers 102 to communicate during call setup. As with most intra-regional calls, it eliminates the need to communicate between regions even when the target user is in the same region and the call is locally hosted. Subsequent sections describe call flow, timing estimation, and messaging schemes for intra-regional calls.

Start local call Figure 4 shows an exemplary message flow for initiating a local group call. The user selects one or more target users, one or more predetermined groups, or a combination of the two and presses the PushTalk (PTT) button 402. As described in detail separately, the client sends a request to set up a group call to the intra-regional dispatcher regardless of whether the mobile station has a dedicated traffic channel 404. If the mobile station's packet data session is dormant after sending the request, the client reconfigures the dedicated traffic channel and begins the process of preparing the packet data session for media activity. The client buffers the speech input received from the caller for a predetermined period of time.

When the intra-regional dispatcher receives the request, it extends the predetermined group specified in the request to the member list of the target user. The intra-domain dispatcher then retrieves the location of the target user 406. At this point, the intra-domain dispatcher determines if the group is already running in the system. Figure 4 shows a scenario where the group has not yet been executed. The late join call scenario shows the case where the group is already running and is described separately herein.

The intra-regional dispatcher locates at least one of the target users and then sends a response to the client indicating that the group call has been set up 408. At this point, the client optimistically accepts the request spoken by the caller 410, and begins buffering the medium 412.

The intra-domain dispatcher uses the target user's location to determine where the call will be allocated. As shown in Figure 4, when the target user is determined to be in the same area as the intra-regional dispatcher, the intra-regional dispatcher assigns a call to the intra-regional MCU. The MCU sends an announcement to the entire group that the call has begun 414. Sending an announcement to the target user triggers the packet data session to exit hibernation and reconfigure the traffic channel.

After the client receives the call announcement from the MCU and the mobile station's traffic channel is reconfigured, the client sends the buffered medium to the MCU 416. The MCU buffers the medium received from the originator 418. In one embodiment, the MCU buffers the medium until the "target response threshold" is met or exceeded. The target response threshold is an indicator of the amount of target response required to initiate delivery of the medium. The threshold may be a configurable parameter. When the threshold is met, the MCU duplicates the medium and sends it to the target user 420, which responds to the call announcement 422.

Messaging with short data burst Instant response is related to the response time it takes for the application server to respond to a PTT or call setup request. Responses to PTT requests, including group call setup requests, are always aimed at consistently responding to requests over a predetermined time period (eg, 1 second or less). In many cases, when a user requests to set up a group call, the user's packet data session is dormant and there is no dedicated traffic channel. Reconfiguring the dedicated traffic channel takes a considerable amount of time. Therefore, communication to the application server may be achieved by other means.

To ensure that the group communication system achieves "instant response", small IP datagrams are always sent in either direction, that is, in the direction originating from the mobile station or in the mobile station, regardless of the state of the packet data session. Send in the direction of termination. In one embodiment, the IP datagram is sent in the form of a short data burst message (SDB). In situations where the packet data session is dormant, SDB messages will be sent over the overhead channel. When a dedicated traffic channel is connected, SDB messages are sent over the traffic channel.

See Figure 4, a group call setup request is sent by an SDB message 404. The group call setup response from the application server is also sent in SDB messages 408. By sending call setup request and response messages via SDB messages, the group communication system 100 can meet the goal of "instant response".

The MCU completes the process of setting up a group call by sending a call announcement to users in the member list, including the caller. The announcement of this call is sent via a dedicated traffic channel. In most cases, group member packet data sessions are dormant, i.e. no dedicated traffic channel is configured. Therefore, the MCU must resend the call announcement message on a persistent and robust schedule until all of the member's traffic channels are reconfigured and the member acknowledges the message or the reliability timer expires. Sending call announcements aggressively encourages media buffering on the client, ensuring that the MCU is kept to a minimum. The client sends a buffered medium as soon as its traffic channel is ready and receives a call announcement containing MCU contact information. The MCU replicates and sends the buffered medium as soon as the target response threshold is met or exceeded. Therefore, if the target client receives and responds to the call announcement more quickly and this threshold is met faster, the MCU will stop buffering and begin sending media faster.

Call announcements to callers are also sent by SDB. This has two effects. First, since the call announcement contains MCU contact information, as soon as the mobile station's traffic channel is reconfigured, the group call client begins sending the buffered medium to the MCU, feeding the buffered medium. The RAM requirement of the mobile station to be held is relaxed. Second, when the call announcement arrives through the SDB, if the caller decides to drop the call or free the floor before the traffic channel is reconfigured, the client informs the MCU of that information. can do. Sending call announcements to the caller through the SDB increases the load on the common channel and requires the MCU to take special action on the caller's call announcement message.

Start remote call Calls within a region are locally hosted when all members are located within the same region. The intra-region dispatcher allocates intra-region calls to remote regions because local resources are overloaded or unavailable. In such cases, the communication path between the user's PDSN and the remote MCU is extended, which may add media and signaling latency and errors. Figure 5 shows an exemplary call setup for remote intra-regional calls.

Initiating an intra-regional call on a remote host is similar to the call setup scenario described in connection with Figure 4, except that the intra-regional disperser assigns the call to the MCU. The intra-domain dispatcher determines the MCU to which the call is assigned after searching for the location of the group members. The intra-domain dispatcher makes this decision based on the user's location, loading, and MCU availability. In an intra-regional call, the user is located within the same region, so the intra-regional dispatcher checks the loading and availability of the MCU complex within the local region. The intra-regional dispatcher assigns a call to a remote MCU when it receives an indicator that the local MCU complex is overloaded or has experienced a temporary malfunction. In one embodiment, the remote MCU processes the call in the same manner as the local MCU, because each MCU replicates the same function except for the call configuration.

Inter-region call In the group calling system 100, a user is designed to be able to communicate with other users regardless of their physical position or proximity to each other. Since interregional calls require communication between the intraregional dispatcher and the home dispatcher during the call setup time, the group communication system 100 is arranged to limit the number of interregional calls. Calls are assigned to MCUs in remote areas by one or more of the call participants. Subsequent sections describe exemplary call flow, timing estimation, and inter-region call messaging schemes.

Start local call Figure 6 shows an exemplary message flow for initiating a locally hosted group call. The local inter-regional call setup is similar to the local intra-regional call setup described in connection with Figure 4, but the local dispatcher can perform the process of retrieving the location of the target user. different. In one embodiment, the intra-regional dispatcher attempts to locate the target user in its cache. If some users are not found in the cache, the local dispatcher requests assistance from the home dispatcher to locate the users. The home dispatcher uses the location server in the area to store the user location information of the user who registered the IP. As described above, the intra-regional location server notifies the associated intra-regional dispatcher each time a user is registered. The intra-domain dispatcher notifies the home dispatcher of the user's registration. Therefore, the home dispatcher can assist the intra-regional dispatcher in detecting users who are dispersed across geographically different regions.

Start remote call Figure 7 shows an exemplary setup for remote interregional calls. Initiating an interregional call on a remote host is similar to the call setup scenario described in connection with Figure 4, except that the intraregional dispatcher assigns the call to the MCU. The intra-domain dispatcher (RD) 114 determines the MCU to which the call is assigned after searching for the location of group members. The RD114 makes this decision based on the user's location, loading, and MCU availability. The RD attempts to use the location of the group members to find the optimal route of IP packets, including media and signaling, to the majority of the members on the service provider's network. When the majority of users are located in a particular area, the call is assigned to that area. When users are evenly distributed across regions, the call is allocated to one of the regions that contains the target user.

End of group call Group calls end for two reasons. That is, when all participants are required to get out of the call, or when all participants stop speaking for a predetermined period of time (called "hang time"). Each participant may choose to stop participating in the call before the scheduled end of the call. When all participants exit the call, the MCU terminates the call and releases all resources assigned to the call. When all but one participant exits the call, the MCU notifies a participant called the "single user". The single user chooses to exit the call immediately or wait for the hang time timer to expire, which causes the MCU to trigger the call to disconnect.

The MCU terminates the call when the hang time timer expires. The MCU tracks each talk spurt and sets a timer after the talk spurt is complete. This timer, called the hang-time timer, tracks a period of silence during a call, i.e., when there is no talk or media flow activity. If the call remains silent during the hang time period configured by the service provider, the MCU concludes that the participant is no longer interested in the call and terminates the call.

User initiates call termination Figure 8 illustrates an exemplary scenario in which a user chooses to stop joining a group call. The scenario shows the flow of messages that the user stops joining. When the user chooses to stop joining the group call 802, the client sends a request to the MCU to remove the user from the call 804. The MCU removes the user from the call 806 and notifies the client that the user has been removed 808.

Server initiates call termination Figure 9 shows an exemplary message flow that occurs when the hang time timer expires and the MCU ends the group call. When the hang time timer expires 902, the MCU sends a notification to the participants that the call is over 904. Each client that receives the call termination notification responds with an acknowledgment 906. When the MCU receives an acknowledgment, it notifies the RD that the call has ended and releases the resources allocated to the call 908.

Sending a warning The warning mechanism is used to notify the target user that another user, the warning caller, wants the target user to participate in the group call. The alert mechanism includes a text message that allows the caller to specify the target of the call, the desired time of the call, or a customizable text message for another user. FIG. 10 shows an exemplary message flow that occurs when a user sends a warning.

1002 indicating that the caller selects one or more target users, one or more predetermined groups, or a combination of the two and sends a warning. The client sends a request to the RD to send a warning to the target user specified in the request 1004. When the RD receives the request, it extends the predetermined group specified in the request to the member list of the target user and searches for the location information of the target user 1006. RD sends a response to the client after locating at least one of the target users 1008. RD assigns a warning request to the MCU 1010 and broadcasts a warning message to the target user 1012.

As shown in Figure 10, the warning request is sent by a short data burst (SDB). By sending a warning with an SDB message, the packet data session of the parties involved can be left dormant. The alert notification contains the necessary information to allow the target user to set up a group call with the caller and the rest of the target user, for example by selecting the alert notification and pressing PTT. When this is done, the group call setup proceeds similar to the call setup scenario described in relation to FIG.

Late subscription A group call setup request is considered a late join if the member list specified in the call setup request is determined to be the same as the member list associated with a call that is already in progress in the system. This situation appears in one of two ways: First, the user selects, for example, the exact same member list as the member list that pre-contains the calls associated with it, for example the same user and / or group, and presses the PTT button. , Generate. Second, the user selects a call that is still running on the system from the call history list and presses PTT. In either case, the RD detects that the call requested by the user to start is already in progress and treats the user as a late join.

FIG. 11 shows an example of an exemplary late subscription in which the user selects a call from the call history list. The user selects a call from the call history list and presses the PTT button 1102. The client sends a request to the RD to initiate a group call 1104. RD determines that the call has already been executed 1106 and sends a response to the client that the user has been added to an ongoing call 1108. When the call has already been executed, the floor is already held by the current call participant, so until the late subscriber user is ready to receive the medium, i.e. the packet data session is from hibernation. The floor will not be handed over to the user until it exits. RD requires the MCU hosting the call to add late-subscribe users to the group 1110. The MCU adds the user and sends an announcement containing the MCU contact information to the user 1112. After the late subscriber user's traffic channel is reconfigured, the media flow within the call is transmitted to the user. At this time, the late-subscribe user attempts to request the privilege to speak.

The late join scenario is similar to the scenario of initiating a new group call described in connection with Figure 4. The difference is that late-subscribe users are denied the floor in response to the first group call setup request. Speaker mediation In one embodiment, the user of each group call is assigned a speaker preemption rank. It demands the privilege of gaining a "floor" and determines what level of rights the user has when starting to speak. After setting up the group call, the MCU is responsible for floor control and decides whether to allow participants requesting the floor to speak. The MCU mediates the speaker when two or more call participants are competing for control of a particular group of floors.

FIG. 12 shows an exemplary event that takes place during the arbitration process. The arbitration scheme used in this scenario allows user B to preempt when user A requests a floor. When User A requests permission to speak by pressing the PTT button 1202, User B is in control of the floor, i.e. User B is speaking. The client sends a message to the MCU requesting permission to speak 1204. The MCU arbitrates the speaker, preempts user B in 1206, and decides to transfer the floor to user A. To ensure that User A's media is transmitted after the media flow is interrupted, i.e. User B stops speaking, the MCU first states that the floor was preempted by another user. Send the following message to User B's client, 1208, and then to User A, a response to confer the floor 1210.

Adding a user to an active group call In group communication system 100, participants in a group call can add new users to an ongoing group call. This means that the call participant selects one or more target users, one or more predetermined groups, or a combination of the two, and the participant is in a group call that the participant is currently in. Achieve by indicating that you want to add target users. FIG. 13 shows an event that occurs when a new target user is added to an ongoing group call. The call participant selects one or more target users, one or more groups, or a combination of the two to be added to the call 1302. The client sends a message to the RD requesting that the specified target user be added to the ongoing group call, as specified in the request 1304. When the RD receives the request, it extends the predetermined group specified in the request to the member list of the target user. After that, RD searches for the location information of the target user 1306. After locating at least one of the target users, RD sends a response to the client indicating that the target user will be added to the call 1308. RD sends a request to the MCU to add the specified user to the call 1310. The MCU sends a call announcement to the new target user, which begins the process of returning the packet data session from hibernation 1312. Announcements are sent on a solid schedule to ensure that the target user receives the message. After reconfiguring the target user's traffic channel, the target user sends an acknowledgment to the MCU 1314. An additional target user is 1316, which is included in the media and signaling communications that take place during the call.

Removing members from active group calls In group communication system 100, participants in a group call can remove a member from an active group. In one embodiment, this is achieved by indicating that the call participants should select one or more target participants and remove them from the group call. Figure 14 shows an exemplary event that takes place when a participant is removed from an ongoing group call. Participants in a group call select one or more target participants that will be removed from the call 1402. The client sends a message to the RD requesting that the target participant specified in the message be removed from the group call 1404. When the RD receives the request, it looks up the location of the target participant in 1406 and sends a response to the client indicating that the target participant will be deleted in 1408. RD sends a request to the MCU to remove the target participant from the call 1410. The MCU sends a message to the target participants specified in the delete request indicating that they will be removed from the call 1412. Goal participants send an acknowledgment to the MCU 1414.

Unregister The deregistration function is performed when the user no longer wants to be contacted by the application server or by another IP application that contacts the user using the user's IP address. The deregistration feature removes the user's IP address and other contact information from the RLS, freeing resources allocated for the user. FIG. 15 shows how to remove a user's registration from RLS as a result of a mobile station powering down according to one embodiment. The client receives an instruction that the mobile station on which the client is located has been powered down 1502. As part of the shutdown process, the client sends a message to RLS indicating that the user's location information should be deleted 1504. RLS authenticates the request and verifies that it is from a valid source 1506. If the authentication is successful, the RLS notifies the client of the success instruction 1508 and the RD about the deletion of the user 1510. RD clears the user's data record from the cache and frees the resources allocated to the user. If the deregistration fails, the user's location information is finally removed from the RLS when the time associated with the expired range elapses.

In one embodiment, the group communication system 100 supports both the chat room model and the interim model. In the chat room model, groups are predetermined and stored on the dispatch server. A given group is public, thus suggesting that the group has an open member list, i.e. the dispatched user is a potential participant. In the chat room model, when the first person chooses to join the chat room, the call is initiated and server resources are allocated to the call for a given amount of time configured by the service provider, regardless of talk activity. If so, the call continues. The user explicitly requests to join or leave these types of calls. As described separately, during periods of no talk activity, each call goes into group hibernation until the user requests permission to speak.

In the interim model, the group is defined in real time and has a list of limited members associated with the group. The limited member list specifies which users are allowed to join the group, is invalid for users other than the limited member list, and exists only for the life of the call. The definition of the interim group is not remembered anywhere, so this definition is used to set up the call and is released after the end of the call.

An interim group is formed when an outgoing user selects one or more target users and generates a request to be sent to the server to initiate a call. Target users are notified that they are in the group and are automatically added to the associated call. That is, the user is not required to operate. When the interim call becomes inactive, the application server "hangs" the call and releases the resources allocated to it, including the definition of the group used to initiate the call.

In the group communication system 100, when operating in the chat room model, a group of users of the communication device (individual users are known as net members) uses the communication device assigned to each net member. Communicate with each other. The term "net" refers to a group of users of telecommunications equipment who are entitled to communicate with each other.

In one embodiment, the central database contains information that identifies the members of each individual net. Two or more nets operate in the same communication system. For example, the first net is defined as having 10 members and the second net is defined as having 20 members. The 10 members of the first net communicate with each other, but not with the members of the second net. In another embodiment, members of different nets can monitor communications between members of two or more nets, but only members within their own net can transmit information.

The net runs on existing communication systems without requiring substantial changes to the existing infrastructure. Therefore, controllers and users on the net can use Internet Protocol (IP) to send and receive packet information, such as Code Division Multiple Access (CDMA) systems, time division multiple access. Works with Time Division Multiple Access (TDMA) systems, Global System for Mobile Communication systems, satellite communication systems such as Globalstar or Iridium , or various other systems. To do.

Net members communicate with each other using their assigned communication devices (shown as communication devices (CDs) 120, 122). CD120 and 122 are wireline or wireless communication devices, such as terrestrial wireless telephones, wireline telephones with push talk capabilities, satellite phones with push talk capabilities, wireless video cameras, still cameras, music recorders or players. Audio equipment, laptop or desktop computer, paging equipment, or a combination thereof. For example, the CD120 includes a wireless terrestrial telephone with a video camera and display. In addition, each CD can send and receive information in either secure mode or non-secure (clear) mode. Throughout the description below, references to individual CDs suggest PushTalk phones. However, references to CDs are not intended to be restricted to it and include other communication devices capable of sending and receiving packet information according to the Internet Protocol (IP).

In the group communication system 100, in general, one user can transmit information to the remaining net members at a given time by the transmission privilege. When a request is received, the transmission privilege is either transferred or denied to the requesting net member, depending on whether the transmission privilege is currently assigned to another net member. The process of accepting and rejecting transmission requests is known as mediation. In the arbitration method, when determining whether the requesting net member is to be delegated transmission privilege, the priority level assigned to each CD, the number of failed attempts to obtain transmission privilege, and the net member having transmission privilege. Evaluate factors such as the length of time to hold, or other factors.

To participate in System 100, each of CD120 and 122 has the ability to request transmission privileges from the controller or MCU116. MCU116 handles real-time management operations for the group. An MCU is any type of computer-type device with at least one processor and memory. The MCU116 operates remotely via a communication system service provider, a member, or both, assuming rights are granted by the service provider. The MCU116 receives the group definition via an external management interface. Group members either require management by a service provider or manage net functionality by a defined system, such as a security manager (SM) on which members operate, that fits into the MCU management interface. MCU116 authenticates parties attempting to set up or modify the net.

The SM performs key processing, user authentication, and related tasks to assist secure nets. A group communication system interacts with one or more SMs. SM is not involved in real-time control of the net, including net activation or PTT arbitration. In addition, SM has management capabilities compatible with the MCU interface and automates management functions. In addition, the SM can act as a data endpoint to join the net, broadcast the net key, or simply monitor net traffic.

In one embodiment, the means of requesting transmission privileges from the MCU include a PushTalk (PTT) key or switch. When the user of the system 100 wants to transmit information to other members, he presses the push talk switch located on the CD to send a floor control request and obtains transmission privilege from the MCU 116. When no other net member is currently assigned transmission privileges, the requesting user is given transmission privileges and is notified via a CD by auditory, visual, or tactile alert. Information is transmitted from this user to other members after the requesting user has been given transmission privileges.

In one embodiment of the invention, each radio net member sets up one or more base stations 126 or, in some cases, satellite gateways and forward and reverse links. Voice and / or data are converted into data packets suitable for individual distributed networks 128 for communicating with other users, for example using CDs. In one embodiment, the distributed network 128 is the Internet.

In one embodiment, in each communication system, i.e. a terrestrial and satellite communication system, a dedicated forward channel is set up for broadcast information from each net member to another net member. Each net member receives communication from other net members through a dedicated channel. In another embodiment, in each communication system, a dedicated reverse link is set up to transmit information to the MCU116. In one embodiment, a combination of the methods described above is used. For example, one scheme sets up a dedicated forward broadcast channel, but the wireless CD must transmit information to the MCU 116 via a dedicated reverse link assigned to each CD.

The first net member, when he wants to transmit information to other members of the net, requests transmission privileges by pressing the push talk key on his CD and is formatted for transmission over distributed network 128. Generate a request. In the case of CD120 and 122, the request is transmitted in the air to one or more base stations 126. The mobile switching center (MSC) 130 is a well-known inter-working function (IFF), packet data serving node (PDSN), or packet to process data packets. It contains a packet control function (PCF) and exists between BS126 and distributed network 128. The request is a public switched telephone network, It is transmitted to the modem bank via the PSTN), which receives the request and supplies it to the distributed network 128. The terminal monitors the traffic of system 100 by connecting to the distributed network 128.

When the other member does not currently hold the transmission privilege, when the MCU116 receives the transmission privilege request, it transmits a message to the requesting net member to notify that the transmission privilege has been transferred. Auditory, visual, or other information from the first net member is transmitted to the other net member by sending the information to the MCU 116 using one of the transmission paths described above. In one embodiment, the MCU 116 supplies information to other net members by replicating the information and sending each copy to another net member. When one broadcast channel is used, the information need to be duplicated only once for each broadcast channel used.

In an alternative embodiment, the MCU116 is embedded in the MSC130 and the data packets are routed directly to the MCU116 to assist the base station, without routed over the distributed network 128. In this embodiment, the MCU 116 remains connected to the distributed network 128 so that other communication systems and devices can participate in group communications. In yet another embodiment, the MCU116 is integrated into the PDSN or PCF module of the MSC130.

In one embodiment, the MCU 116 maintains one or more databases for managing individual net members and information related to each predetermined net. For example, the database, for each net member, has a username, account number, telephone number associated with the member's CD, that is, a dial number, a mobile station identification number assigned to the CD, and the current member status on the net ( For example, whether the member is actively participating in the net), the preferred code to determine how to assign transmission privileges, the data phone number associated with the CD, the IP address associated with the CD, and the member Includes information such as indicators of which nets are allowed to communicate. Other relevant types of information are stored by the database in relation to each net member.

In one embodiment, CDs connect to individual communication terminals to form a talk group, or net. The MCU includes various functional capabilities in hardware and software that can be configured in different ways to accommodate different applications. The MCU provides real-time network management and authentication operations, mediation of PushTalk (PTT) requests, maintenance and distribution of net membership and registration lists, setup and disconnection of required communications (eg, CDMA) calls, systems and It has the ability to manage network resources as well as overall control of the net state.

The net is either a stand-alone deployable cellular system or within the configuration of a large number of sites. For large configurations, a large number of MCUs are geographically arranged to form a single integrated system, with each MCU acting as a plug-in module into the existing cellular infrastructure. Therefore, the new features introduced by the net are available to cellular users without the need to modify the existing cellular infrastructure.

The MCU maintains a given list of nets. In one embodiment, the definition of each net includes a list of members, including a net identifier, telephone number or other identifying information, user priority information, and other general management information. A net is defined as statically clear or secure, and no transition between clear and secure is allowed. Securenet generally uses media encryption to authenticate and protect against eavesdropping. Media encryption in the secure net is done end-to-end, so encryption and decryption is done in the communication device. The MCU can operate without knowing security algorithms, keys, or policies.

FIG. 16 shows an exemplary group 1600 to show how communication devices (CDs) 1602, 1604, and 1606 interact with the MCU 1608. A large number of MCUs are preferably arranged in large groups. In FIG. 16, the CD1602 can transmit the medium to other members of the group. In this case, the CD1602, known as the speaker, transmits the medium over the channel. If CD1602 is designated as the speaker, the remaining participants, namely CD1604 and CD1606, cannot transmit the medium to the group. Therefore, CD1604 and CD1606 are designated as receivers.

As already mentioned, CD1602, 1604, and 1606 are connected to MCU1608 using at least one channel. In one embodiment, the channels are divided into separate channels, including Session Initiation Protocol (SIP) channel 1610, media signaling channel 1612, and media traffic channel 1614. SIP channel 1610 and media signaling channel 1612 are used whenever bandwidth allows, regardless of whether they are designated as speakers or receivers by CD1602, 1604, and 1606. .. SIP is the Internet engineering task force, It is an application layer protocol defined by the IETF) and describes a control mechanism for setting, changing, and terminating multimedia sessions operated by the Internet Protocol (IP). The SIP determines the mechanism for registering and locating the user, the mechanism for defining the user's capabilities and describing the parameters of the medium, and the user's availability, call setup, and call processing. By assisting the mechanism for, the call-signaling problem of Internet telephone applications is largely solved.

In one embodiment, SIP channel 1610 is used to start and end CD participation within group 1600. Also, within SIP channel 1610, session description protocol, SDP) signal is used. For example, when participation of CDs in a group is set up by using SIP channel 1610, real-time control and signaling between CDs and MCUs is performed, for example, by using NBS media signaling channel 1612. .. In one embodiment, the media signaling channel 1612 handles pushtalk requests and releases, competing requests, ie floor control arbitration, information transmission start and end announcements, net hibernation management, endpoints. Used for tracking connections, requesting and exchanging net status, and notifying error messages. The protocol of media signaling channel 1612 minimizes the most common message lengths, simplifies the task of responding to requests and interpreting responses, while maintaining flexibility for future expansion. In addition, the protocol of media signaling channel 1612 allows the request to be retransmitted without adversely affecting the state of the protocol.

In one embodiment, signaling traffic on media signaling channel 1612 includes call setup and control signaling (including session solicitation requests and acknowledgments) and media signaling (real-time floor control requests and associated asynchronous messages). Includes) and includes. Media Traffic Media traffic on channel 1614 includes real-time, point-to-point, voice or data, or both broadcast communications. Both messaging categories have unique functional attributes. In addition, each CD issues a request for a Domain Name Service (DSN) client, prompting it to map a fully qualified DSN host name to an Internet network address.

In one embodiment, call setup and call control signaling is done according to SIP semantics. In one embodiment, SIP is transported using either the well-known user datagram protocol (UDP) or transmission control protocol (TCP), but each CD is UDP. Use to perform SIP-based signaling functionality. In addition, each CD expects to receive a SIP signaling request via UDP. Real-time signaling takes place over the dynamic UDP / IP interface in the CM and each CD. Other signaling is done, for example, using SIP over a fixed TCP / IP interface between the CM and the CD.

PTT waiting time In one embodiment, when the packet data service is active, the infrastructure (eg, base station transceiver subsystem (BTS), base station controller (BSC)), interworking (eg, base station transceiver subsystem (BTS)) Resources within IWF), and radiolinks) are actively allocated to mobile stations (MS). In an IP-based VoIP dispatch service, each user's packet data connection remains active when there is an active conversation between group participants. However, in group communication, after a period of inactivity, i.e., a "hang time", the user traffic channel transitions to hibernation.

The transition to hibernation saves system capacity, reduces service costs and battery drain, and allows the user to receive incoming traditional voice calls. For example, a user is usually considered "busy" for an incoming voice call when participating in an active packet data call. When the user's packet data call is dormant, the user can receive the incoming voice call. For these reasons, it is desirable to put the packet data call into hibernation after a period of inactivity in the packet data.

While the packet data call is active, radio frequency (RF) energy is still transmitted by the mobile phone, albeit at a low level, even if no packet data is being exchanged, synchronizing with the base station and Power control is maintained. These transmissions consume a considerable amount of power on the telephone. However, in hibernation, the telephone does not transmit RF. To save power on the phone and extend battery life, the hang time may be set to put the phone into hibernation mode after a long period of inactivity.

When the packet data service is active for all users, the latency of PTT requests (IP datagrams sent between the MS and the dispatch server) is very short. However, when the user channel has already transitioned to hibernation, the PTT latency will be significantly longer. During packet data hibernation, state information associated with the packet data session, including the mobile station's IP address, is maintained. However, state information associated with a layer lower than PPP (eg, a physical traffic layer) is released, unassigned, or both.

In some infrastructures, traffic channels must be reassigned, resources must be reallocated, and the radio link protocol (RLP) layer must be used to bring data connections out of hibernation. Must be reinitialized. For this reason, when the user presses the PTT button to request a floor after the talk group has not spoken for a while, the PTT wait time for the first speaker spurt is generally the next talk spurt. Much longer than. This is relatively infrequent, but it can affect the utility of the service and should be minimized.

In one embodiment, to reduce PTT latency, group call signaling, such as floor control requests, floor control responses, and invocation messages from hibernation, reconfigures a dedicated traffic channel. It is transmitted over the available common channels without waiting. Such a common channel is always available, regardless of the state of the mobile station, and does not need to be requested and reassigned each time the user wants to initiate a group call. Therefore, even when the mobile station is dormant, the group call signaling is exchanged, and in parallel, a means for reconfiguring a dedicated traffic channel to the mobile station of the speaker and the receiver is provided. ..

In one embodiment, the calling mobile station sends floor control requests to the radio infrastructure over several available reverse common channels, such as reverse access channels and reverse extended access channels. In addition, the calling mobile station receives a response to a floor control request on several available forward common channels, such as forward paging channels and forward common control channels. In one embodiment, the dormant receiver's mobile station has a message of activation from hibernation on several available forward common channels, such as forward paging channels and forward common control channels. To receive.

Short data burst call signaling message In one embodiment, the actual total time of hibernation and PTT latency recognized by the speaker is significantly reduced by using short data burst (SDB) messages. This is given, for example, to the "TIA / EIA / IS-2000 Standard for cdma2000 Spread Spectrum System" (hereinafter referred to as the "cdma2000 standard"). In one embodiment, the SDB message is a dedicated physical channel (eg, forward fundamental channel (FCH) or forward dedicated common control channel (F-DCCH)), or common physics. Channels (eg, reverse access channel, R-ACH), reverse enhanced access channel, It is sent over R-EACH), forward common control channel (F-CCCH), or paging channel (PCH). SDB messages are transported by the radio burst protocol (RBP) and mapped onto the appropriate available physical layer channels. SDB messages send arbitrary IP traffic and are sent over a common physical channel, so when the calling client's mobile station does not have a dedicated traffic channel, SDB messages are for exchanging group call signaling. Prepare a mechanism.

Call signaling messages generated by mobile stations In one embodiment, the media signaling message sends an IP datagram over a reverse link or a link generated by a mobile station. Whenever a user requests a floor and a dedicated reverse traffic channel is not immediately available, the client's mobile station immediately informs the MCU. Assuming that the client's mobile station disconnects all dedicated traffic channels, the client's mobile station immediately sends a floor control request over the reverse common channel of the wireless infrastructure, relaying the MCU. For example, when a dedicated reverse channel is not available, either the reverse access channel or the reverse extended access channel may be used to send such a message. In one embodiment, the client mobile station transmits the floor request message as an SDB message to the MCU.

Referring to FIG. 4, in one embodiment, the client MS sends a PTT floor request 404 on a reverse common channel, such as an access channel or an extended access channel, before reconfiguring the dedicated traffic channel. In one embodiment, the client MS sends a PTT floor request 404 in an SDB message, regardless of which channel is used.

For example, the client MS initiates the reconfiguration of the dedicated traffic channel, for example, by performing "regeneration of service option 33". The client MS also initiates wireless link protocol (RLP) synchronization. In one embodiment, the client MS reconfigures the dedicated traffic channel and properly synchronizes the RLP in parallel with sending the PTT floor request 404.

Therefore, when the mobile station does not have an active dedicated traffic channel, the participating mobile station by sending a floor control request to the CM using the features of the available reverse common channel and / or SDB. Reduces the total time required to launch. Until the speaker's forward traffic channel is reconfigured, the speaker's client does not receive confirmation that the floor request has been transferred, but prompts the CM to start activating the participating speaker. Can be notified and the overall waiting time is reduced.

Referring to FIG. 4, the wireless infrastructure sends a PTT floor control request 404 to the MCU via the Packet Data Supply Node (PDSN). In one embodiment, after receiving a floor control request, the MCU arbitrates the request, bursts the media signaling activation message (trigger) to the target participant (receiver), and / or the participant (receiver). Trigger to reconfigure the traffic channel of the person) 414. When the MCU transfers the PTT floor request, it sends the PTT floor transfer 408 to the client MS. In one embodiment, the PTT floor transfer 408 is provided on available forward common channels, such as forward paging channels and forward common channels, when the client's dedicated traffic channel has not yet been reconfigured. Send to client MS. In one embodiment, the infrastructure sends a PTT floor transfer 408 to the client MS, regardless of which channel is used.

In one embodiment, the MCU waits for the hibernate response timer to expire before responding to the PTT floor control request. When the group hibernate response timer is set to zero, the CM responds immediately to the floor control request. In one embodiment, when the client MS completes its traffic channel reconfiguration and RLP synchronization, it sends the medium (buffered within the client MS 412) to the MCU 416.

Network-generated call signaling messages In one embodiment, after receiving the floor control request, the MCU bursts the media signaling activation message to the target group of participants (receivers) and reconfigures the traffic channels of the participants (receivers). Trigger. When the group hibernate response timer is set to zero, the MCU immediately responds to the floor control request. In one embodiment, when the speaker begins to reconfigure the traffic channel immediately after sending the PTT request, the traffic channel between the caller and the receiver is properly reconfigured in parallel.

Referring to Figure 4, the MCU sends an activation trigger to the target speaker after receiving the PTT floor control request 414. The MCU determines whether the packet data session exists at the target mobile station and sends the trigger packet to the appropriate infrastructure element, eg, the base station. The infrastructure begins to page to each individual goal MS and reconfigure its dedicated traffic channel. Then, for example, the target MS begins to reconfigure its dedicated traffic channel, for example by performing a "regeneration of service option 33". The target MS also initiates wireless link protocol (RLP) synchronization. In one embodiment, the target MS reconfigures its dedicated traffic channel and, in parallel, properly synchronizes the RLP using the same functionality that the client MS does.

In one embodiment, the target MS sends a boot response to the MCU indicating that the target MS is ready to receive media after completing the reconfiguration of its dedicated traffic channel and the synchronization of its RLP. Send 422. The MCU sends a speaker announcement to the client MS before 420 sending the buffered 418 media in the MCU to the target MS.

In one embodiment, the MCU is on several available common forward channels, such as forward paging channels and forward common control channels, when the target speaker's traffic channel has not yet been reconfigured. 414. In one embodiment, the MCU sends the activation trigger to the target recipient in the form of an SDB, regardless of which channel is used. When a PTT floor control request is sent as an SDB message on the speaker's reverse common channel and the hibernate response timer for the target group is set to zero on the MCU, it is actually in the speaker's client. PTT latency is reduced to the time it takes to send an SDB request message on the reverse link and then send an SDB response message on the forward link.

Network interface for call signaling messages Distinguish specific traffic generated by which network, for example, the SDB payload, from other traffic to determine if it will be sent to an idle mobile station that does not have a dedicated traffic channel. Some infrastructure policies or interfaces are enforced.

In the first embodiment, the SDB message retains a restricted user payload so that the IP datagram is filtered based on its size. IP datagrams smaller than a given size limit are sent as SDB messages when sent to mobile stations that do not have a dedicated traffic channel. When the application floor request response message is very small, for example 34 bytes including the IP header, the group communication system uses such a filter.

In the second embodiment, the infrastructure vendor defines an IP-based service for encapsulating IP traffic sent to the mobile station. For this service to send to mobile stations that are suspected of not having a dedicated traffic channel, IP servers that know this service will properly encapsulate small IPs, such as UDP datagrams, along with IP headers. Send. The group communication system uses this service to indicate to the infrastructure that it sends a floor request response message, for example, in the form of an SDB, to the requesting client MS. Coordinating SDB traffic with pending page or service generation requests is also important to ensure fast and reliable transmission of user traffic.

In a third embodiment, the IP server sends a datagram of a particular IP, eg UDP, with an IP header to a mobile station that is suspected of not having a dedicated traffic channel. The IP server tags the infrastructure to send IP datagrams to the client MS, for example by indicating a specific value in the IP header. The group communication system uses this service to indicate to the infrastructure that, for example, a floor request message is transmitted in the form of an SDB to the requesting client MS. A third embodiment reserves a UDP or TCP port range to carry a particular IP datagram, eg, an SDB message.

Mobile station-initiated service generation and paging In one embodiment, the client sends a floor control request 404 in the form of an SDB, and shortly thereafter, in order to quickly reconfigure this traffic, the client sends a service generation request to the wireless (eg, CDMA) infrastructure. Send to. However, when the hibernate response timer is set to a small value, the RD responds quickly to the floor control request and transmits the response 408 to the client. When this response reaches the infrastructure during the early stages of the service generation transaction, the infrastructure notices that the speaker's MS does not have an active traffic channel and sends it to the speaker's MS. Attempt to page the response. However, this paging operation may abort the service generation transaction that is already in progress. In one embodiment, the speaker's MS responds to the page, ensuring that the floor control response message is transmitted to the speaker and requesting service generation again, but the first service generation attempt. As a result of discontinuing, you will experience an unnecessary delay when reconfiguring the sender's traffic channel.

In the first embodiment, the RD may be configured not to respond immediately to the floor control request 404 in order to avoid a race condition between the service generation process and paging. Therefore, the hibernate response timer may be adjusted so that the MCU sends response 408 to the speaker's MS after the service generation process is complete.

In a second embodiment, the PDSN that receives response 408 and the mobile exchange (MSC) that responds to the speaker's service generation request are coordinated. That is, if the PDSN determines that the packet data service generation process in the sender's MS is already in progress when response 408 reaches the infrastructure, the MSC delays the paging of the sender's MS. The PDSN caches the response and, when the service generation process is complete, sends it over the forward traffic channel of the speaker's mobile station. Instead, the MSC may send the response as an SDB message to the sender's MS while the service generation process is still in progress.

In a third embodiment, the speaker's MS avoids a race condition by not issuing a service generation request until the speaker's MS receives a response to the floor control request. In one embodiment, the speaker's MS does not have an active dedicated traffic channel, so the MCU has several available forward commons, such as forward paging channels and forward common control channels. Send a response to the speaker's MS on the channel. In one embodiment, the MCU sends the response in the form of an SDB to the speaker's MS. In the same way that the boot request sent by the MCU triggers the reactivation of the traffic channel of the receiver's mobile station, the speaker's MS relies on the floor control response generated by the RD to traffic. Trigger channel reactivation. Race conditions are avoided by avoiding the potential for mobile-initiated service generation to synchronize network-initiated mobile station paging.

Network-initiated packet data trigger caching IP datagrams containing the activation trigger 414, which reach the wireless (eg, CDMA) infrastructure and are sent to the mobile station of the receiver without a dedicated traffic channel, are generally sent by the network. Especially damaged by wireless infrastructure. In one embodiment, the activation trigger 414 sent to the receiver's mobile station is persistently retransmitted according to a predetermined schedule until the receiver's response or the group's activation timer expires. For example, the activation trigger 414 is retransmitted every 500 milliseconds. However, resending the activation trigger 414 at this rate will take up to 500 milliseconds between the time the speaker's traffic channel is reconfigured and the next activation trigger sent to that speaker reaches the infrastructure. , Or an average delay of 250 ms.

In one embodiment, the infrastructure or another entity in the network caches the activation trigger 414 sent by the MCU and sends it to the target MS as soon as the target MS sets its traffic. Therefore, it is not necessary for the MCU to resend the start request, and the total time for starting from hibernation is reduced. Caching the launch trigger 414 eliminates the delay of up to 500 ms from the total time to boot from hibernation, as opposed to resending it, for example, at a rate of 500 ms.

Media buffer In one embodiment, the user is allowed to start speaking after a floor control request by buffering the medium before the dedicated channel between the client and the receiver is reconfigured. The system buffers the speaker's speech to allow the speaker to start speaking before the speaker's traffic channel is completely reconfigured. Therefore, the sender can start speaking earlier and the apparent PTT waiting time is reduced. This experience is unaffected because the speaker does not experience PTT waiting time. That is, the PTT wait time is transferred from the speaker to the rest of the system. The speaker just waits until he receives a response to his first talk spurt from the receiver, but as already mentioned, the speaker responds to his first talk spurt, but he is active. We have already predicted that it will take longer than the response to the next talk spurt that begins while participating in a conversation. The buffering of the speaker's first talk spurt can be done on the MCU side or on the client MS side.

Buffer on the MCU side In one embodiment, the MCU buffers the speaker's first talk spurt. After the user presses the PTT button and the user's traffic channel is reconfigured, the user can communicate with the MCU. At this time, the receiver's traffic channel is not yet ready, so the MCU buffers the speaker's speech for future transmission to the target speaker 418. The buffering of the MCU reduces the apparent PTT latency determined by the speaker to the approximate time it takes to generate the speaker's traffic channel. FIG. 17 shows the buffer on the MCU side according to one embodiment and is described below: (1) There are no in-progress calls when the caller and target traffic channels are dormant; (2) The user presses the PTT button. The server receives a "group call setup" 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 floor is handed over to the user and begins to buffer the user's media; (4) The server starts the process to reconfigure the target packet data traffic channel; (5) The server sends a group call announcement message to the client via SDB; (6) The client successfully reconfigures the traffic channel and begins sending buffered media to the server; (7) The client sends the medium to the server; (8) The target traffic channel is reset (the target response threshold is met); (9) The user releases the PTT button. The client stops buffering the medium; (10) The client stops sending the buffered medium to the server and requests the server to release the floor; (11) The server sends an acknowledgment of floor release to the client.

Client-side buffer In one embodiment, when shorter apparent latency is desired, the speaker is allowed to start speaking even before his traffic channel is reconfigured. Since the client MS has not yet communicated with the MCU, it generates a signal for the speaker to start speaking. The client MS buffers the speech when the speaker is allowed to speak before the speaker's traffic channel is reconfigured 412. Permission to speak is given "optimistically" because communication with the CM has not yet been set up. FIG. 18 shows client-side buffering according to one embodiment and is described below: (1) No calls in progress when the caller's traffic channel is dormant; (2) The user presses the PTT button. The client sends a group call setup request to the server via SDB; (3) The client starts the process of reconfiguring 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 floor is handed over to the user and begins to buffer the user's media; (5) The client receives the "group call announcement" message from the server by SDB; (6) The client successfully reconfigures the traffic channel; (7) The client sends the buffered medium to the server; (8) The user releases the PTT button. The client stops buffering the medium; (9) The client stops sending the buffered medium to the server and requests the server to release the floor; (10) The client receives an acknowledgment of releasing the floor from the server.

In one embodiment, both the MCU buffer 418 and the client side buffer 412 are performed simultaneously. Client-side buffering can reduce the apparent PTT latency. In one embodiment, the client MS buffers the medium to control the apparent PTT latency experienced by the user. The combination of mobile station-generated SDB and client-side media buffer reduces the delay associated with reconfiguring the active traffic channel.

Therefore, the disclosed embodiments provide a dispatch model that supports at least two types of dispatch calls: a chat room model and a tentative model. In the chat room model, groups are predetermined and stored on the dispatch server. However, in the interim model, groups are defined and / or modified in real time.

The disclosed embodiments further add to the actual total time of activation from hibernation and waiting for PTT by exchanging group call signaling, even when the mobile station is dormant and the traffic channel is inactive. Significantly saves time. Methods and devices exchange group call signaling by using short data burst (SDB) message signaling. The method and device effectively reconfigure the dedicated traffic channels of the speaker's mobile station and the hibernated receiver's mobile station in parallel.

In another embodiment, the network initiates the activation trigger to the target speaker, and as soon as the target mobile station reconfigures the traffic channel, the activation trigger is transmitted to the target mobile station. Reduce the waiting time for startup from hibernation in a group communication network.

In another embodiment, in a group communication network, the mobile station transmits a response to the floor control request after the service generation process is completed, thereby avoiding simultaneous execution of service generation and paging. In one embodiment, the response to the floor control request may be in the form of an SDB when the service generation process is not completed. In one embodiment, after transmitting the response to the source communication device, the service generation process of the source communication device is started.

<figref num="1">The figure which shows the group communication system.</figref><figref num="2">A diagram showing how several applications interact with each other.</figref><figref num="3">The figure which shows the exemplary user registration process according to one Embodiment.</figref><figref num="4">The figure which shows the setup process of an exemplary local intra-regional call according to one embodiment.</figref><figref num="5">The figure which shows the setup process of an exemplary remote intra-regional call according to one embodiment.</figref><figref num="6">The figure which shows the setup process of an exemplary local interregional call according to one embodiment.</figref><figref num="7">The figure which shows the setup process of an exemplary remote inter-regional call according to one embodiment.</figref><figref num="8">The figure which shows the exemplary process for getting out of a group call according to one embodiment.</figref><figref num="9">The figure which shows the exemplary process for terminating a group call according to one embodiment.</figref><figref num="10">The figure which shows the exemplary process for sending a warning to a group call according to one embodiment.</figref><figref num="11">The figure which shows the exemplary process for delayed joining to a group call according to one embodiment.</figref><figref num="12">The figure which shows the exemplary process for preempting a speaker according to one embodiment.</figref><figref num="13">The figure which shows the exemplary process for adding a new member to an active group call according to one embodiment.</figref><figref num="14">The figure which shows the exemplary process for removing a participant from a group call according to one embodiment.</figref><figref num="15">FIG. 5 illustrates an exemplary process for deleting a user's registration according to one embodiment.</figref><figref num="16">The figure which shows how several communication devices interact with a communication manager according to one embodiment.</figref><figref num="17">The figure which shows that the medium is buffered on the communication manager side according to one Embodiment.</figref><figref num="18">The figure which shows that the medium is buffered on the client side according to one Embodiment.</figref>

Code description

100 ... group communication system, 108,110 ... application server component, 120,122 ... client, 128 ... distributed network, 1600 ... communication group.