PATENT DOCUMENT

Publication Number: US-8428237-B1
Application Number: US-89626310-A
Country: US
Kind Code: B1

Title: Push-to-talk wireless telecommunications system utilizing a voice-over-IP network

Abstract:
System and method for enabling push-to-talk (PTT) private calls in a wireless communications network are described. One embodiment includes selecting a called party private identification for a private call by a calling party on a mobile device; pressing a PTT button on the mobile device; transmitting a SIP SUBSCRIBE including the calling and called parties private identifications to request a speech token; redirecting the SIP SUBSCRIBE to the PTT Server for purposes of removing the calling party and the called party from a multicast group; receiving an acknowledge message that includes a speech token; transmitting calling party information from the PTT Server to the called party; communicating speech packets from the calling party to the called party in a half-duplex manner; releasing the PTT button on the mobile device; transmitting a SIP SUBSCRIBE to release the speech token; and notifying the calling and called parties that the group&#39;s speech token is available.

Claims:
What is claimed is: 
     
       1. A method for push-to-talk (PTT) private calls for users in a wireless communications network, comprising:
 receiving a selection of a called party for a private call, the selection being made by a calling party on a mobile device; 
 determining a first private identification for the called party; 
 determining a second private identification for the calling party; 
 transmitting a first SIP SUBSCRIBE including the first and second private identifications to request a speech token associated with the private call; 
 redirecting the first SIP SUBSCRIBE to a PTT Server for purposes of removing the calling party and the called party from a multicast group; 
 receiving an acknowledge message that includes the speech token; 
 transmitting calling party information from the PTT Server to the called party; 
 communicating speech packets from the calling party to the called party in a half-duplex manner; 
 determining a PTT release command made on the mobile device; 
 transmitting a second SIP SUBSCRIBE to release the speech token; and 
 notifying the calling and called parties that the speech token is available. 
 
     
     
       2. The method of  claim 1 , further including using a Proxy-Require header to signal to an SIP proxy server that different parsing rules apply to PTT-related messages. 
     
     
       3. The method of  claim 1 , wherein notifying the calling party that the speech token is available includes sending a response to the second SIP SUBSCRIBE. 
     
     
       4. The method of  claim 1 , wherein notifying the called party that the speech token is available includes sending an SIP INFO. 
     
     
       5. The method of  claim 1 , wherein notifying the called party that the speech token is available includes sending an SIP NOTIFY. 
     
     
       6. The method of  claim 1 , wherein notifying the calling and called parties that the speech token is available includes multicasting to the calling and called parties a pre-stored tone from the PTT Server. 
     
     
       7. The method of  claim 1 , further including: reinstating the calling party and the called party as part of the multicast group upon termination of the private call. 
     
     
       8. The method of  claim 7 , wherein reinstating the calling and called party as part of the group includes restoring an IP address associated with a mobile device of the calling party and an IP address associated with a mobile device of the called party to the multicast group. 
     
     
       9. A method for push-to-talk (PTT) private calls for users in a wireless communications network, the method comprising:
 joining a user to a multicast group via the wireless communications network, the multicast group having a calling party further joined to the multicast group; 
 receiving an SIP request code indicating an invitation to join a private call made by the calling party; 
 detecting an acceptance by the user of the invitation to join the private call; 
 transmitting an SIP response code configured to join the user to the private call and to remove the user and the calling party from the multicast group; and 
 receiving speech packets sent from the calling party to the user in a half-duplex manner, wherein at least one of the joining, the receiving of the SIP request code, the detecting, the transmitting, and the receiving of the speech packets is performed by a mobile device. 
 
     
     
       10. The method of  claim 9 , wherein the SIP request code is an SIP SUBSCRIBE request code. 
     
     
       11. The method of  claim 9 , wherein the SIP response code is further configured to request a speech token associated with the private call. 
     
     
       12. The method of  claim 11 ,
 wherein the SIP response code includes an Event header; and 
 wherein the Event header is configured to request the speech token. 
 
     
     
       13. The method of  claim 11 ,
 wherein the SIP response code includes a body portion; and 
 wherein the body portion is configured to request the speech token. 
 
     
     
       14. The method of  claim 9 , further comprising:
 releasing the user from the private call; and 
 rejoining the user to the multicast group, 
 wherein at least one of the releasing and the rejoining is performed by the mobile device. 
 
     
     
       15. A method for push-to-talk (PTT) private calls for users in a wireless communications network, the method comprising:
 joining a calling party to a multicast group, the multicast group having a called party joined to the multicast group; 
 receiving a selection of the called party to join a private call; 
 transmitting an SIP request code to a PTT server via a wireless communications network, the SIP request code configured to specify the called party and to remove the calling party and the called party from the multicast group; 
 receiving notification of obtaining a speech token corresponding to the private call; 
 transmitting speech packets from the calling party to the called party in a half-duplex manner; and 
 transmitting a command to release the speech token, wherein one of the joining, the receiving of the selection, the transmitting of the SIP request code, the receiving of the notification, the transmitting of the speech packets, and the transmitting of the command is performed by a mobile device. 
 
     
     
       16. The method of  claim 15 , wherein the SIP request code is an SIP SUBSCRIBE request code. 
     
     
       17. The method of  claim 15 , wherein the SIP request code is further configured to request the speech token. 
     
     
       18. The method of  claim 17 ,
 wherein the SIP response code includes an Event header; and 
 wherein the Event header is configured to request the speech token. 
 
     
     
       19. The method of  claim 15 , wherein receiving notification of obtaining the speech token includes receiving a multicasted pre-stored tone from the PTT server. 
     
     
       20. The method of  claim 15 , further comprising:
 releasing the calling party from the private call; and 
 rejoining the calling party to the multicast group, 
 wherein at least one of the releasing and the rejoining is performed by the mobile device.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a divisional of U.S. patent application Ser. No. 10/137,551, which is a continuation of U.S. Ser. No. 10/028,086, filed on Dec. 21, 2001, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/268,473 filed on Feb. 12, 2001, and is related to U.S. patent application Ser. No. 10/028,091, filed Dec. 21, 2001, which claims the benefit of U.S. Provisional Patent Application Ser. No. 60/301,567 filed on Jun. 28, 2001, all of which are assigned to the assignee of the present application and are incorporated by reference in their entireties. 
    
    
     BACKGROUND OF THE INVENTION 
     The invention relates generally to a telecommunications network and, more particularly, to a method and apparatus for half-duplex communication among multiple telecommunications devices via a packet data network. 
     Currently, telecommunications networks exist that enable a telecommunications device to directly access another through a digital two-way radio feature. At least one telecommunications provider, Nextel, has been very successful providing such a network. With Nextel&#39;s system, a user can have instant access by pressing a button to reach other users on the network. 
     However, a network does not yet exist that can provide such communication to other users via a wireless packet data network. Therefore, what is needed is an invention that can provide push-to-talk to another user via a wireless packet data network. 
     SUMMARY OF THE INVENTION 
     The present invention includes a system and method for Push-to-talk (PTT) service to another user via a wireless packet data network. To this end, in one embodiment the system includes a packet data network with at least one mobile station, a radio access network, a database server, a registrar and location server, an Interactive Multimedia Server (IMS), and a PTT server that provides the PTT service to other PTT users on the packet network. 
     The IMS includes a Session Initiation Protocol (SIP) Proxy Server which may also function as a back-to-back user agent (BBUA). The SIP Registrar and Location Server is operable to store contact addresses of active mobile devices. The PTT Server is operable to function as a SIP call endpoint for each of a plurality of mobile devices wherein the plurality of mobile devices are segmented into membership groups, the PTT Server further operable to multicast a communication from one member of the group to the other members of the group. An Internet Protocol (IP) network interconnects the SIP Proxy server, the SIP Registrar and Location Server, and the PTT Server. 
     Therefore, in accordance with the previous summary, objects, features and advantages of the present invention will become apparent to one skilled in the art from the subsequent description and the appended claims taken in conjunction with the accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates an architecture of the preferred embodiment; 
         FIG. 2  illustrates an application-layer interfaces and protocols; 
         FIG. 3  illustrates another view of the architecture of the preferred embodiment; 
         FIG. 4  illustrates a logical view of the architecture of the preferred embodiment; 
         FIGS. 5-12  illustrate call flows of the preferred embodiment. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     The present invention can be described with several examples given below. It is understood, however, that the examples below are not necessarily limitations to the present invention, but are used to describe typical embodiments of operation. 
     A list of definitions is first described in order to better understand the invention. 
     Group members—the set of users who may join a group session. 
     Session—a relationship among participating group members wherein calls are enabled between the same. 
     Join—the action taken by a group member (or automatic action taken by the member&#39;s Push-to-talk client) to participate in a group session. 
     Call—a set of consecutive speech transmissions between group members participating in a session. 
     Speech transmission—an instance of half-duplex (HDX) voice communication from one session participant to one or more other session participants. 
     Speech token—an abstraction that is introduced to explain talker arbitration (i.e., to describe how one obtains the right to speak within a call). There is exactly one speech token per group. To speak, one must be granted the speech token. 
     Peer-to-peer communication model—call participants may not interrupt one another, and no participant has special privileges with respect to other participants. 
     Superior-subordinate communication model—subordinates communicate as in the peer-to-peer model, but a superior has special privileges with respect to subordinates (e.g., queued requests for speech token, ruthless pre-emption of the speech token, forcing called parties to join the group session). A superior may opt to relate in the peer-to-peer model, and not invoke his/her special privileges.
 
Public audio—audio which plays only when the recipient has opted into group calls by virtue of having joined the group.
 
Invited audio—Audio which plays only when the recipient (“invitee”) has accepted an invitation to talk.
 
Forced audio—audio which plays to the recipient regardless if the recipient opted to hear it.
 
     The following table identifies the types of groups that have been considered from the perspective of the network. Groups known only to the client have not been considered: 
     
       
         
           
               
               
            
               
                   
               
               
                 Group 
                 Type of Group 
               
            
           
           
               
               
               
               
            
               
                 Descriptors 
                 Open Group 
                 Closed Group 
                 Ad Hoc Group 
               
               
                   
               
               
                 Example 
                 PTT in a 
                 Peer-to-peer: 
                 Figures 11-12 
               
               
                   
                 public, open 
                 PTT service 
                 add some 
               
               
                   
                 chat room 
                 within a closed 
                 additional 
               
               
                   
                   
                 chat session, 
                 detail. Note 
               
               
                   
                   
                 or in a company 
                 that a 1-to-1 
               
               
                   
                   
                 context. 
                 Direct Connect 
               
               
                   
                   
                 Superior- 
                 Call is a 
               
               
                   
                   
                 subordinate: 
                 degenerate case 
               
               
                   
                   
                 dispatch 
                 of an ad-hoc 
               
               
                   
                   
                 service. 
                 group call. 
               
               
                 Membership 
                 Session 
                 Membership 
                 Lasts for 
               
               
                 persistence 
                 participation 
                 transcends 
                 exactly one 
               
               
                   
                 defines 
                 participation 
                 call 
               
               
                   
                 membership 
                 in any group 
                   
               
               
                   
                   
                 session 
                   
               
               
                 Related session 
                 Lasts as long 
                 Lasts as long 
                 Lasts for 
               
               
                 persistence 
                 as one user has 
                 as one member 
                 exactly one 
               
               
                   
                 joined the 
                 has joined the 
                 call 
               
               
                   
                 group&#39;s session 
                 group&#39;s session 
                   
               
               
                 Relationship 
                 Session may 
                 Session may 
                 Session lasts 
               
               
                 between session 
                 span multiple 
                 span multiple 
                 for one call 
               
               
                 &amp; call 
                 calls 
                 calls 
                 only 
               
               
                 Membership 
                 Any user may 
                 A group 
                 Call/alert 
               
               
                 selection 
                 opt to join the 
                 administrator 
                 originator 
               
               
                   
                 group&#39;s 
                 specifies group 
                 defines 
               
               
                   
                 session, &amp; 
                 membership 
                 membership as 
               
               
                   
                 thereby become 
                 (e.g., via 
                 part of the 
               
               
                   
                 a member 
                 provisioning 
                 call/alert; 
               
               
                   
                   
                 such in the 
                 only these may 
               
               
                   
                   
                 directory 
                 join the 
               
               
                   
                   
                 server); only 
                 session &amp; 
               
               
                   
                   
                 these may join 
                 participate in 
               
               
                   
                   
                 a group session  
                 the call. 
               
               
                 Group URL 
                 No, to prevent  
                 Configurable. 
                 Not applicable. 
               
               
                 Addressable 
                 “voice 
                 If allowed &amp; if 
                   
               
               
                 with other URLs  
                 spamming” 
                 call is placed 
                   
               
               
                 in an ad hoc 
                   
                 by non-member, 
                   
               
               
                 group 
                   
                 the caller is 
                   
               
               
                 call/alert 
                   
                 not allowed to 
                   
               
               
                   
                   
                 join any in- 
                   
               
               
                   
                   
                 progress closed 
                   
               
               
                   
                   
                 group session. 
                   
               
               
                 User 
                 Peer-to-peer 
                 Provisioned as 
                 Peer-to-peer, 
               
               
                 communication 
                   
                 either peer-to-  
                 except when all 
               
               
                 model 
                   
                 peer, or 
                 members belong 
               
               
                   
                   
                 superior- 
                 to the same 
               
               
                   
                   
                 subordinate. 
                 closed group &amp; 
               
               
                   
                   
                   
                 one participant 
               
               
                   
                   
                   
                 is a superior, 
               
               
                   
                   
                   
                 in which case 
               
               
                   
                   
                   
                 the superior- 
               
               
                   
                   
                   
                 subordinate 
               
               
                   
                   
                   
                 model may be 
               
               
                   
                   
                   
                 used. 
               
               
                   
               
            
           
         
       
     
     Given this analysis of types of groups, we now present in the table below how network functionality invoked in a given use case may vary according to the type of group that is involved, &amp; how certain use cases are specific to one or more group types. Highlighted use cases have a corresponding figure. 
                                            Network Functionality Invoked                                                                 Talker   Remove           Use Case               Contact   Arbitration   User(s)           (from       Define   Join User(s)   Members   (i.e., vie for    from   Dissolve       viewpoint of   Applicable   Group   to Group   Not Already   speech   Group   Group       end user)   Group Type   Members   Session   in Session   token)   Session   Membership               Join Group   Open   Joining   Yes, thereby   No   No   No   No               adds user   enabling                               as   public audio                               member                               Closed   No   Yes, thereby   No   No   No   No                   enabling                                   public audio                       Alert Group   Closed   No   Alerting party   Registered   No   No   No                   only, if not   members                               already in   only (e.g.                               session   those with                                   current                                   registration                                   in SIP                                   registrar).                       Ad hoc   Alerter &amp;   Alerting Party   Registered   No   No   No               all   only   members                           invitees       only                   Alert-   Closed, peer-   No   Calling party   Registered   Calling   No   No       Initiated   to-peer       only, if not   members   party vies               Group Call   model       already in   only (to   for token               (i.e., in           session, since   clear alert)   per normal               response to           called parties       arbitration               an alert)           employ                                   invited audio                           Closed,   No   Calling party,   Registered   Calling   No   No           superior in       if not already   members   party vies                   superior-       in session. If   only, either   for token                   subordinate       authorized &amp;   to clear alert   per                   model       opted, all    or to speak   selected,                           registered   to members   authorized                           group   that have   option                           members not   been placed                               already in   into forced                               session.   audio                               depending on                                   option                                   selected by                                   the caller, we                                   have either                                   “forced                                   audio” or,                                   depending on                                   whether or                                   not alerted                                   members                                   were already                                   in the group                                   at the time the                                   alert was                                   broadcast,                                   “public                                   audio” or                                   “invited                                   audio.”                           Ad hoc,   No   Calling Party   Registered   Calling   No   No           assuming       only   members   party vies                   that the ad           only (to   for token                   hoc group           clear alert)   per normal                   members do               arbitration                   not belong to                                   the same                                   closed group                                   or that, if                                   they do                                   belong to the                                   same closed                                   group, the                                   private call                                   uses the                                   peer-to-peer                                   model. If the                                   caller is a                                   superior and                                   the ad hoc                                   group call                                   targets are                                   subordinates,                                   then the                                   network                                   functionality                                   invoked                                   would be as                                   in the                                   immediately                                   preceding                                   table entry.                               Group Call   Open   No   No, as user   N/A   Calling   No   No                   must have       party vies                           previously       for token                           joined group       per normal                                   arbitration                   Closed, peer-   No   Calling party   If   Calling   No   No           to-peer       only, if not   authorized   party vies                   model       already in   &amp; opted, all   for token                           session -    registered   per normal                           “public   members   arbitration                           audio” or   not in                               “invited   session - a                               audio”,   combination                               depending of   of a call to                               whether the   those                               originator   already in                               simply wants   the group                               to speak to   session, and                               those who&#39;ve   an alert to                               already joined   those who                               the session or   have not                               the originator   already                               wishes to do   joined the                               this plus alert    group                               group   session.                               members not                                   already in                                   session. The                                   call flow                                   corresponding                                   to this table                                   entry assumes                                   that the                                   originator has                                   already joined                                   the group                                   session and                                   merely                                   wishes to                                   speak to                                   others who                                   have also                                   joined the                                   group session.                           Closed   No   Calling party,   If   Calling   No   No           (superior in       if not already   authorized   party vies                   superior-       in session. If   &amp; opted, all   for token                   subordinate       authorized &amp;   registered   per                   model)       opted, all   members   selected,                           registered   not in   authorized                           group   session -   option                           members not   “Forced                               already in   audio” and                               session, and if    alerting                               the caller so   group                               chooses,   members                               “forced   not already                               audio”.   in session                                   are mutually                                   exclusive.                                   If forced                                   audio is not                                   selected by                                   the caller,                                   then                                   members                                   already in                                   the group                                   session                                   would have                                   public audio                                   and any                                   alerted                                   members                                   would have                                   invited                                   audio.                       Private, ad   Alerter &amp;   Calling party,   If   Calling   No   No           hoc group   all   if not already   authorized   party vies                   call from   invitees   in session. If   &amp; opted, all   for token                   superior to       authorized &amp;   registered   per                   subset of       opted, all   members   selected,                   closed group       registered   not in   authorized                   members       group   session.   option                           members not   “Forced                               already in   audio” and                               session, and if    alerting                               the caller so   group                               chooses,   members                               “forced   not already                               audio”   in session                                   are mutually                                   exclusive.                                   If forced                                   audio is not                                   selected by                                   the caller,                                   then                                   members                                   already in                                   the group                                   session                                   would have                                   public audio                                   and any                                   alerted                                   members                                   would have                                   invited                                   audio.                   Talker   Open   No   No   No   Normal   No   No       Arbitration                   arbitration                   Closed, peer-   No   No   No   Normal   No   No           to-peer               arbitration                   model                                   Closed,   No   No   No   Superior   No   No           superior in               vies for                   superior-               token per                   subordinate               selected,                   model               authorized                                   option                   Ad hoc   No   No   No   Depending   No   No                           on model                                   used, either                                   normal                                   arbitration                                   or vying                                   for token                                   per                                   selected,                                   authorized                                   option               Call   Open   No   No   No   No   No   No       Participants   Closed   No   No   No   No   No   No       Stop Talking   Ad hoc   No   No   No   No   All   Yes                               removed                                   from                                   session           Leave Group   Open   No   No   No   No   User   User       As with                       removed   removed       joining a                       from   from group       group, this                       session   membership       could result   Closed   No   No   No   No   User   No       from an                       removed           explicit user                       from           action, or be                       session           automatically    Ad hoc - this   No   No   No   No   User   User       done by the   would only                   removed   removed       user&#39;s PTT   happen in the                   from   from group       client (e.g.,    peer-to-peer                   session   membership       at power-   model when                               down).   a user                                   decides to                                   leave an ad                                   hoc group                                   call before it                                   is finished.                                   Note that,                                   after the call                                   has                                   completed,                                   the network                                   will                                   automatically                                   remove all                                   members                                   from the                                   group                                   session and                                   dissolve ad                                   hoc group                                   membership.                    
Alerts
 
     An alert can be delivered only if the target has a current registration with the SIP registrar and is accessible via a 1xRTT data call. The target can either respond to the alert by one of the following means: Pushing the PTT button, which will cause a standard Push-to-talk call to be established; clear the alert, which discards the alert without a response to the originator; and store the alert which saves the alerting party&#39;s addressing information for later retrieval, and will stop audible alert tones in progress. 
     Now turning to  FIG. 1 , an embodiment of the main architecture is shown. The Home Agent (HA)  18 , part of the 1xRTT core network, provides IMS network components  48  with a single interface for communication with the mobile station&#39;s Push-to-talk client  20 . While a 1xRTT network is here depicted, the invention is applicable also to UMTS radio access and core networks. 
     The application server  26  provides SIP access/services (e.g. proxy, redirect, back-to-back user agent, authentication, etc.). Additionally, the application server  26  can run in any of the following service modes: stateless and stateful. 
     The PTT Server  34  for Push-to-talk service, manages talker arbitration, tracks active member participation in a group, and distributes received Real time Transport Protocol (RTP) voice packets to call participants. The PTT server  34  functions as a SIP back-to-back user agent (BBUA). 
     A Registrar and Location Server  36  provides for terminal registration of availability and contact locations, and for proxy retrieval of location/contact information. The associated Location Database  38  stores and manages dynamic location updates for subscribers. The Application Server  26  utilizes the JDBC interface to access data when handling sessions, although other protocols could be used to access the data. 
     A Database Server  40  provides access to the user and group database  42 . The database  42  stores all of the user profile information for the Application Server  26 , and group membership information for the PTT Server  34 . The Application  26  and PTT  34  Servers utilize JDBC to access stored information, although other protocols could be used for access. 
     Additionally, the Radio Access and Core networks is shown 46 along with the managed IP network  48  and the rest of the elements in  FIG. 1 . 
     Wireless Specific Codecs 
     For mobiles being served by a 1xRTT radio access network (RAN)  46 , optimal voice quality is obtained via use of the Enhanced Variable Rate Codec (EVRC) or Selectable Mode Vocoder (SMV), with over-the-air speech frames carrying EVRC/SMV payload but no VoIP headers. Present 3GPP2 QoS framework plans, therefore, envision use of EVRC/SMV circuit voice over the air in the All-IP Network. Accordingly, Push-to-talk clients use the EVRC/SMV vocoder when served by a 1xRTT network  46 , such that transcoding is not required between 1xRTT mobiles. Where clients do not employ the same codec, a media gateway will be needed to provide transcoding. 
     It should be noted that the above described components are logical or functional elements, where multiple functions could be provided by the same hardware platform. 
     Now turning to  FIG. 2 , the diagram depicts the application-layer interfaces and protocols in the present embodiment. For each of the interfaces, the table below explains the degree to which the interface complies with a standard. 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Interface 
                 Protocol 
                 Degree of Standards Compliance 
               
               
                   
               
             
            
               
                 Mobile 
                 Enhanced 
                 Completely standardized. For 
               
               
                 Station 20 
                 Variable Rate 
                 UMTS radio access networks, 
               
               
                 and PTT 
                 Coding 
                 other codecs would be used. 
               
               
                 Server 34 
                 (EVRC/SMV) 
                   
               
               
                   
                 Real-time 
                 EVRC/SMV variant of RTP is 
               
               
                   
                 Transport 
                 needed, but it is soon to be 
               
               
                   
                 Protocol (RTP) 
                 standardized. 
               
               
                 Mobile 
                 Compression 
                 SIP compression techniques; 
               
               
                 Station 20 
                   
                 inter-working is possible so 
               
               
                 and IMS 
                   
                 long as the mobile and IMS 
               
               
                 Proxy Server 
                   
                 employ the same algorithm. 
               
               
                 16 
                 Session 
                 Extensions to IETF-specified SIP 
               
               
                   
                 Initiated 
                 used in order to reduce over the 
               
               
                   
                 Protocol (SIP) - 
                 air Push-to-talk signaling; 
               
               
                   
                 Prime 
                 inter-working is possible where 
               
               
                   
                   
                 the mobile and IMS employ the 
               
               
                   
                   
                 same extensions. 
               
               
                   
                 Session 
                 Likely completely standardized, 
               
               
                   
                 Description 
                 once EVRC/SMV is included as a 
               
               
                   
                 Protocol (SDP) 
                 codec. 
               
               
                   
                 eXtended Markup 
                 This is transparently passed by 
               
               
                   
                 Language (XML) 
                 the IMS between the mobile 20 
               
               
                   
                   
                 and the PTT server 34. While 
               
               
                   
                   
                 standardized, both the mobile 20 
               
               
                   
                   
                 and PTT server 34 must employ 
               
               
                   
                   
                 the same Document Type 
               
               
                   
                   
                 Definition (DTD) for inter- 
               
               
                   
                   
                 working to occur. 
               
               
                 IMS Proxy 
                 SIP′ 
                 Extensions to IETF-specified SIP 
               
               
                 Server 16 
                   
                 used in order to reduce over the 
               
               
                 and PTT 
                   
                 air Push-to-talk signaling; 
               
               
                 Server 34 
                   
                 inter-working is possible where 
               
               
                   
                   
                 the PTT server 34 and IMS 16 
               
               
                   
                   
                 employ the same extensions. 
               
               
                   
                 SDP 
                 Likely completely standardized, 
               
               
                   
                   
                 once EVRC/SMV is included as a 
               
               
                   
                   
                 codec. 
               
               
                   
                 XML 
                 This is transparently passed by 
               
               
                   
                   
                 the IMS 16 between the mobile 20 
               
               
                   
                   
                 and the PTT server 34. While 
               
               
                   
                   
                 standardized, both the mobile 20 
               
               
                   
                   
                 and PTT server 34 must employ 
               
               
                   
                   
                 the same Document Type 
               
               
                   
                   
                 Definition (DTD) for inter- 
               
               
                   
                   
                 working to occur. 
               
               
                 IMS Proxy 
                 SIP 
                 Completely standardized 
               
               
                 Server 16 
                   
                   
               
               
                 and 
                   
                   
               
               
                 Registrar 36 
                   
                   
               
               
                 IMS Proxy 
                 Java Database 
                 Standardized, but both the IMS 
               
               
                 Server 16 
                 Connectivity 
                 16 and Location Server 36 must 
               
               
                 and Location 
                 (JDBC) 
                 employ the same schema for 
               
               
                 Server 36 
                   
                 inter-working to occur. Other 
               
               
                   
                   
                 protocols could also be used. 
               
               
                 IMS Proxy 
                 JDBC 
                 Standardized, but both the IMS 
               
               
                 Server 16 
                   
                 16 and Database Server 40 must 
               
               
                 and Database 
                   
                 employ the same schema for 
               
               
                 Server 40 
                   
                 successful inter-working. Other 
               
               
                   
                   
                 protocols could also be used. 
               
               
                   
               
            
           
         
       
     
     Individual target clients are addressed by means of a user-specific SIP Uniform Resources Locator (URL). However, groups of clients are addressed by one of two means: a group-specific URL may be used to join a pre-provisioned closed group or the user may specify a list of targeted, individual users&#39; SIP URLs for an ad hoc group call or alert. However, another embodiment may support use of a group-specific URL for a call or alert to a closed group. 
     Quality of Server (QoS) Requirements 
     Bandwidth requirements for the IP backbone (BBN) network would depend on the traffic model. Other network requirements are derived from the QoS requirements for transport of SIP signaling &amp; half-duplex (HDX) EVRC/SMV VoIP. QoS requirements for SIP signaling include the following: very high reliability (i.e., very low packet loss and very low packet corruption); and real-time latency. 
     For full-duplex (FDX) voice traffic, subjective voice quality studies indicate the following: packet loss rate (PLR) of more than 2% significantly affects perceived voice quality; beyond 150 ms end-to-end delay, increasing latency results in rapid deterioration of perceived voice quality; and jitter should be less than 1 ms. 
     Push-to-talk voice transport requirements can be inferred from these metrics for FDX voice traffic. For Push-to-talk&#39;s HDX voice, high reliability is likewise required. This is especially true, considering that under ideal RT conditions with forward error correction (FEC), non-RLP-protected frames incur a 2% frame error rate (FER) over the air (OTA)—one packet&#39;s EVRC/SMV voice sample would fit into a single frame—and Push-to-talk voice traffic will typically pass OTA twice. 
     Regarding end-to-end delay, the traditional latency requirement can be significantly relaxed, given both the HDX nature of speech transmissions and the time between speech transmissions required for talker arbitration. (Latency affects perceived voice quality by increasing the round-trip delay for someone to respond to a given talker.) In contrast to traditional telephony, signaling (e.g. SIP signaling) will likely have more stringent latency requirements than voice. 
     Jitter is typically removed by the endpoints by use of a jitter buffer, and in the case of the present embodiment, the PCF does this prior to sending voice packets over the air on a circuit voice link. An x-millisecond jitter buffer will remove jitter from traffic within an x-millisecond window, at the expense of adding x milliseconds of latency. Late packets arriving outside of the current window are thrown away, increasing the PLR. IP networks, especially unmanaged ones, can add 10s of milliseconds of jitter; however, given the relaxed end-to-end delay requirement relative to FDX telephony, the present jitter buffer can likely afford to be larger, since the increased delay to remove jitter would likely have less impact on perceived voice quality than jitter-induced packet loss. The bottom line for the IP network requirements is that it must support highly reliable transport of Push-to-talk traffic with real-time latency requirements, minimizing jitter as much as possible. Hence, in the present embodiment, QoS enhancements have been made, as noted below in connection with  FIG. 3 . 
     Direct Access Architecture—Logical 
     Now turning to  FIG. 3 , a more detailed view of the Push-to-talk network reference architecture is shown. In this view, the IP backbone network is treated as a trusted network; a router provides connectivity between the backbone network and the managed IP network. Additionally, the “PTT, Managed IP Network”  16  and “Managed IP Network”  48  could be one and the same. Moreover, in this embodiment, Internet and Operational Support System (OSS) connectivity is provided via the backbone network  24 . 
     Further, although  FIG. 3  is similar to  FIG. 1 , a base terminal station  50  is shown connecting the mobile station  20  to the base station controller/packet control subsystem  52 . The BSC in turn connects directly to the mobile switching center/visitor location register  54  and then the home location register  56  through an SS7 network  58 . 
     Moreover, the BSC also connects to a Packet Data Serving Node (PDSN)  60  and then to the managed IP network  48 . The authentication, authorization and access server  62  is also connected to the managed IP network  48 . 
     Specifically, in this embodiment, the MS  20  is a traditional 1xRTT mobile handset with the following enhancements: includes user interface enhancements to support Push-to-talk and directory service functionality; includes a SIP-based Push-to-talk client; and has the capability to multiplex data (including SIP signaling) and EVRC/SMV circuit voice packets onto a data call&#39;s base channel, by means of an RLP secondary service option. 
     The BTS (Base station Transceiver Subsystem)  50  includes a traditional BTS function. The Push-to-talk calls are largely transparent to the BTS  50 , as it treats them much the same as a traditional 1xRTT data call. 
     In this embodiment, the BSC&#39;s Packet Control Function (PCF)  52  is the BSC data selection function for 1xRTT data. Besides traditional BSC and PCU functionality, the PCF additionally provides the following:
         RLP secondary service option (SO) for multiplexing of EVRC/SMV circuit voice and data over the same base RF channel;   DiffServ marking for to distinguish uplink voice from data traffic;   Prioritized queuing for voice versus SIP signaling versus other data for downlink traffic, and for voice versus other data for uplink traffic;   Multiplexing of user&#39;s EVRC/SMV voice packets &amp; PPP data packets over a single GRE tunnel on the R-P interface;   Jitter buffer for downlink voice packets;   Re-sequencing of out-of-order, downlink voice packets; and   Discarding of overly aged, downlink voice packets.       

     The MSC/VLR  54  provides traditional MSC/VLR functions. Push-to-talk calls are largely transparent to the MSC/VLR  54 . It treats them much the same as any other 1xRTT data call (i.e., provides authorization &amp; authentication). 
     The HLR/AC  56  provides traditional HLR/AC functions. Push-to-talk calls are largely transparent to the HLR/AC, as they are treated much the same as any other 1xRTT data call (provides authorization &amp; authentication). 
     In this embodiment, the PDSN (Packet Data Serving Node)  60  provides traditional PDSN functionality:
         IP network connectivity for 1xRTT data calls;   Establishment of PPP links with mobile stations for data traffic;   Mobile IP (MIP) foreign agent (FA) capability, including reverse tunneling;   Interaction with the AAA server for authentication &amp; accounting purposes;   The PDSN additionally provides the following for Push-to-talk traffic;   PPP-free operation for exchange of voice packets with the PCU; VoIP gateway, stripping RTP/UDP/IP headers for downlink EVRC/SMV traffic, and adding these headers for uplink EVRC/SMV traffic;   Over-the-air header compression for UDP/IP (e.g., for SIP traffic) and TCP/IP (per evolving 3GPP2 QoS framework, this will be based on ROHC);   Multiplexing of both EVRC/SMV voice packets &amp; PPP data packets over a single GRE tunnel; and   DiffServ support—DiffServ (re)marking &amp; per-hop behavior (PHB) to distinguish uplink &amp; downlink voice, SIP, and other data packets.       

     The Authentication, Authorization, &amp; Accounting (AAA) Server  62  provides Authentication and Accounting functions for wireless data services. It supports Mobile-IP-based authentication based on user name and shared secret data, and maintains per-user packet counts for accounting purposes. 
     The Home Agent (HA)  18  registers the current point of attachment (i.e., current FA) of the mobile node, and tunnels IP packets to/from the current point of attachment. The HA  18  accepts registration requests using the Mobile IP protocol, and uses this information to update the current attachment point. Packets being sent to the mobile node&#39;s home address are intercepted and tunneled to the mobile&#39;s current location. The HA also supports reverse tunneling. 
     Finally, like the PDSN  60 , the HA  18  is a fully compliant Diffserve edge node, supplying both (re-)marking and per-hop behavior. 
     Other elements in  FIG. 3  have already been discussed in connection with  FIG. 1 . However, the following features should be additionally noted, which serve to reduce delays which could contribute to the user&#39;s perception of network responsiveness:
         SIP compression is used between the MS  20  and the IMS proxy server  26 , to reduce over-the-air transmission delays;   Over the air SIP messaging is minimized, as later depicted in  FIGS. 6-12 ;   DiffServ marking of packets at layer  3  is provided by the IMS  26  and PTT Server  34 , in order to enable differentiated treatment for voice, SIP signaling and other data;   802.1p priority is used at layer  2 , by components of the managed IP network  16 , in order to provide differentiated treatment of voice and SIP signaling.
 
Now turning to  FIG. 4 , the diagram depicts a more logical view of the network reference architecture, and shows the paths taken by SIP signaling (dotted line) and voice packets (solid line). SIP traffic (e.g. REGISTER request) goes from the MS  20  to the Registrar Server  36  through the BTS  50 , the BSC  52 , the PDSN  60 , the HA  18 , and the IMS Proxy Server  16 . A registration signal is then sent to the PTT server  34 . Similarly, the voice path from the MS  20  to the PTT Server  34  through the BTS  50 , the BSC  52 , the PDSN  60  and the HA  18 .
 
Always On
       

     For Push-to-talk users, a user&#39;s packet-data session is always in “connected-state”. Although radio-link resources do not remain allocated to an inactive user, this fact is hidden from the user. The user does not have to do anything special do bring his radio-link connection back into active state, when needed. Hence a dedicated over-the-air traffic channel is automatically allocated for the user whenever there is need to send or receive packet-data. This is known as a Dormant to Active transition. 
     Instant Response 
     When the user is in Active state, responses to the user are delayed only by RAN packet propagation delay, and network and application delays. Nominal packet round-trip delays in RAN are usually very small (−250 ms under favorable RF conditions). 
     When a user is in Dormant state, the network response cannot be instantaneous because of Dormant-Active transition. User still can get immediate feedback regarding call-progress and failures. 
     Dormant-to-Active state transition requires allocating a traffic channel to the user and RLP synchronization between the user and the PCF. Delays inherently associated with IS-2000 call-setup procedures (used for dormant-to-active transition) put a limit on the instantaneous-ness of the user experience for initiating a PTT talk-spurt. 
     Dormant Terminating Mobiles 
     If all the mobiles in a group to which a Push-to-talk call terminates are dormant, the caller will experience additional delay during which at least one of the terminating mobiles is brought into Active state. 
     Network-initiated Dormant-to-Active transitions take longer due to additional delay due to paging. 
     If at least one of the terminating mobiles is in Active state, the caller will encounter no additional delays with respect to the network response. 
     Optimization of Dormant-to-Active Transition Delay 
     Delays associated with initial talk-spurt are minimized using the following approaches: (1) for mobile originated dormant-to-active transitions, early Channel Assignment can be used to assign a mobile to traffic-channel in parallel, with network resources are being allocated and prepared for the call, thus compensates for the over-the-air delays inherent with IS2000 call-setup; (2) for quicker terminations to mobiles, use of slot-cycle-index (SCI) of zero instead of higher values of SCI which conserve battery-life but increase paging time to the mobile (e.g. typical SCI value of 2 results in mobile listening to paging channel every 5.12 seconds). Using SCI=0, results in mobile listening to paging channel every 1.28 seconds instead. This reduces call-setup time accordingly. A 1xRTT mobile operating with SCI=0 should have a battery life of ˜40 hrs with today&#39;s commercially deployed battery technology. 
     Call Flows 
     A subset of use cases is now described by way of call flows. The selected use cases include the following:
         Registering for general SIP-based services, by which the user is enabled to participate in Direct Connect service;   Joining a closed group session;   Direct Connect call by user who is already active in a closed group session, where the group uses the peer-to-peer communication model (note that, for users already active in a group session using this model, a call &amp; initial talker arbitration are identical);   Leaving a closed group session; and   Alert-initiated Direct connect call to an ad hoc group of three users. We depict both call setup, call refusal, &amp; teardown. (Note that a one-to-one Direct Connect call is a degenerate case of an ad hoc group call.)       

     While not inclusive, the use cases selected for call flows are to provide an understanding of the general approach to providing a Push-to-talk solution at the application layer. However, other embodiments may modify the architecture represented in these call flows and still remain in the spirit of the invention. 
     Mobile-to-mobile, internet-to-mobile, &amp; mobile-to-internet calls are not distinguished since the SIP-based, IP multimedia network solution should be largely independent of the underlying access network technology. Push-to-talk clients, on the other hand, must obviously be aware of the access network being used. This statement is particularly true for non-integrated or “split” terminals—e.g., a laptop (TE) with either a PCMCIA 1xRTT or 802.3 modem (MT), which would need to sense the type of modem in use &amp; send EVRC/SMV circuit voice or EVRC/SMV VoIP respectively. 
     The following design constraints/goals were imposed on the design of the call flows:
         To reduce over-the-air (OTA) transmission time for SIP signaling, and to eliminate connection oriented messaging, UDP should be used instead of TCP or SCTP for transport of signaling;   Compressed SIP/SDP messages must be exchanged with the 1xRTT access network, in order to reduce the OTA transmission time for SIP messages (the IMS proxy server will provide compression/decompression capability for downlink/uplink messages respectively);   As compression algorithms that maintain session history typically achieve better compression results than algorithms which maintain no state information, the IMS proxy server must be call-stateful rather than unstated or (transaction) stateful;   To optimize responsiveness of the Direct Connect service to the user, the number of necessary OTA SIP messages should be minimized, even at the expense of standards compliance;   The Direct Connect service solution provided in the Succession IMS network should be, to the greatest extent possible, decoupled from the 1xRTT radio access network (RAN) and core network (CN) (Such decoupling enables separate evolution of the application network and the 1xRTT RAN and CN);   A PTT server should not be allocated for a group until the first group member joins the group and thereby establishes a session with a PTT server (this constraint results in a more easily managed, robust &amp; reliable network); and   Consistent with the trend to push application-specific logic toward SIP endpoints, Direct-Connect-specific service logic should be pushed toward the terminals&#39; client software &amp; toward the PTT server, &amp; away from the SIP registrar &amp; IMS proxy server.       

     Preconditions for the call flows include the following: All depicted mobiles have already established a Mobile IP session with the home agent (HA), &amp; hence have already established a PPP session with the PDSN. They have also obtained the address of the IMS proxy server via a DNS SRV query. As our focus in this section is on the part of the Direct-Connect solution provided by the IMS network, we abstract away the transport provided by the 1xRTT CN &amp; RAN, &amp; depict direct connectivity between the MS &amp; both the PTT server for voice traffic &amp; the IMS proxy server for SIP signaling. 
     All group URLs start with a reserved substring—e.g., “group”—to enable network elements to clearly distinguish group URLs from user URLs. 
     To facilitate IMS (application server) discovery of available PTT servers, each PTT server has registered its URL as a contact for the well known, generic, PTT server, pttserver@operator.com. Each PTT server&#39;s URL&#39;s host name includes the server&#39;s IP address, to preclude subsequent DNS queries to resolve the server&#39;s address. (When a PTT server&#39;s load exceeds a provisioned threshold, it removes the registration; later, when loading falls below a provisioned threshold, the PTT server re-registers itself as a contact.) 
     Finally, we present call flows for the above selected use cases. Now turning to  FIG. 5 , a call flow is shown for a user registering with a registrar. Step 1—The user of MS 1   1  performs some action—powering up handset, activating some SIP-based service, etc.—that requires the user to register with the SIP Registrar. 
     Step 2—The MS 1  sends a compressed REGISTER request to the Succession IMS network. We assume that the MS is at home—i.e., the From header&#39;s address domain is identical with the current network domain. The To header identifies the user for which a contact is to be registered; the From header identifies the party initiating the registration. In this case, they are the same. The host part of the Contact header&#39;s SIP URL is the IP address of the mobile that has been allocated from the home agent&#39;s (HA&#39;s) subnet. 
     Step 3—Upon receipt of the REGISTER request, the IMS proxy server decompresses the SIP/SDP payload, caches the MS&#39;s IP address, and requests the user&#39;s profile from the Subscriber database. 
     Step 4—The Subscriber Database returns the profile to the IMS proxy server, which performs any necessary authentication and, given an authenticated user, performs subscriber authorization (e.g., verifies that the subscription is paid up, etc.). The IMS caches the profile for later use. 
     Step 5—The IMS proxy server relays the REGISTER request to the SIP Registrar. 
     Step 6—The SIP Registrar registers user1@&lt;MS&#39;s IP address&gt; as a contact for user1@operator.com, and returns a 200 OK to the IMS proxy server. The 200 OK message includes an Expires header, which specifies the duration of the registration. This registration must be periodically refreshed. 
     Step 7—The IMS proxy server compresses the 200 OK and forwards it to the MS. 
     Now turning to  FIG. 6 , a call flow is shown on Joining a Closed Group Session. As preconditions for this call flow, the following assumptions are made: another user (e.g., the user of MS 2 ) has already joined closed group groupID1@operator.com; and the depicted PTT server has been allocated to serve groupID1@operator.com. 
     This call flow describes how a user joins a group, &amp; may be abstracted into two stages: Steps 1-12—joining the group, by establishing a session (via the INVITE method) with the PTT Server; and Steps 13-16—registering as a contact for the user the group&#39;s SIP URL, so that any subsequent ad hoc group calls/alerts will be routed via the PTT server to the user. By such routing, acceptance of a call of this sort may result in the user leaving the original group session prior to RTP packet distribution for the new call. (Without this, the user could simultaneously receive voice packets from two different calls.) 
     At startup, the SIP Registrar established a registration of pttserver@operator.com as a contact for each provisioned, open or closed group, including groupID1@operator.com, the closed group involved in this call flow. Such registration facilitates dynamic assignment of a PTT server for a group. When the first group member joined a group—e.g., in this case the user of MS 2  joining groupID1@operator.com—the IMS proxy server queried the location server for the group&#39;s registered contact. Since the contact was the well-known, generic, PTT server URL, pttserver@operator.com, signifying that no PTT server had been assigned for the group, the IMS queried the location server for the active PTT servers that were registered as contacts for this URL, unless the IMS had already cached this information. The IMS selected one of the registered PTT servers&#39; contact URLs, and relayed the joining user&#39;s INVITE to the selected server. This PTT server, in turn, registered its URL as the preferred contact for the group. 
     Note that the conventional order of REGISTER followed by INVITE has been inverted. However, the conventional order could be followed with the consequence of longer delay before the user is enabled to participate in group calls. 
     Step 1—Explicitly via MMI at the mobile station (MS 1 ) or, alternatively, implicitly and automatically via MS power-up, the user activates the Push-to-talk client, and identifies groupID1 as the group to be joined. 
     Step 2—The SIP-based, Push-to-talk client in the MS sends a compressed INVITE request to the proxy server. The From header identifies user1@operator.com as the user&#39;s SIP URL. The To header identifies the SIP URL of the group to be joined (i.e., groupID1@operator.com). The Contact header identifies the MS&#39;s IP address in the host portion of the URL. Normally, the Contact header would provide the IP address of the user so that subsequent requests may be sent directly to the user&#39;s terminal, instead of through a series of SIP proxy servers. As the SIP compression/decompression function is allocated to the IMS proxy server, and as the compression algorithm is session-stated (in order to enable better compression results), all signaling traffic from mobiles must transit the proxy server. Record-Route &amp; Route headers are used to force subsequent SIP messages related to this session through the same IMS proxy server. The Proxy-Require header indicates that the proxy-server must support Push-to-talk-specific processing. The Session Description Protocol (SDP) body identifies the MS&#39;s IP address and RTP port number to which EVRC/SMV voice packets should be sent. 
     Step 3—Upon receipt of the INVITE request, the IMS proxy server decompresses the SIP/SDP payload, and parses the SIP/SDP headers. Finding that the Proxy-Require header necessitates support for Push-to-talk, the proxy server permits Push-to-talk-specific extensions to the SIP protocol. The IMS caches the MS&#39;s IP address, &amp; requests the user&#39;s profile from the Database Server. 
     Step 4—The Database Server returns the profile to the IMS proxy server, which performs any necessary authentication. Given an authenticated user, the proxy server performs general subscriber authorization (e.g., verifies that the subscription is paid up, etc.) and, given that the Proxy-Require indicates support for Push-to-talk, verifies that the user subscribes to some form of Push-to-talk service. The IMS caches the profile for later use. 
     Step 5—The proxy server queries the location server regarding the location of groupID1@operator.com. 
     Step 6—Within the location server, the groupID1@operator.com URL has been registered with a contact list comprised of the URL of the PTT server serving groupID1. The location server thus sends this URL in response to the proxy server. The contact URL includes the IP address of the PTT server. 
     Step 7—The proxy server caches groupID1&#39;s PTT server address, and sends a compressed 100 Trying to the MS. 
     Step 8—The proxy server then relays the INVITE request to the PTT server, replacing the Request-URI with the URL of the PTT server. The protocol exchange between the proxy server and the location server would be unnecessary if the proxy server had already cached the address of the PTT Server serving groupID1. 
     Step 9—The PTT server queries the database server for user1&#39;s groupID1 membership data, and caches this for later use. The PTT server functions as a SIP back-to-back user agent (BBUA), distributes received speech packets, and provides talker arbitration. It now modifies data structures that facilitate these functions. The PTT server adds the MS&#39;s IP address &amp; RTP port number to the “multicast group” associated with groupID1, adds the user&#39;s SIP URL to a list of users who&#39;ve joined group groupID1, establishes a mapping from the user&#39;s SIP URL to MS 1 &#39;s IP address and RTP port number, and returns a 200 OK to the IMS SIP proxy with an SDP message body specifying the PTT server&#39;s IP address &amp; groupID1&#39;s RTP port number to which the PTT-service client should send voice packets. Note that the 1x technology is presently inadequate to support IETF-specified multicasting with Class D multicast addresses. While 3GPP2 has discussed supporting IP multicasts, it is unlikely to address such in the near future. The PTT Server, therefore in this embodiment effectively “multicasts” received speech packets by replicating received packets for each group member (other than the packet originator), replacing the group-specific, unicast, destination IP address &amp; RTP port number with the individual IP address &amp; RTP port number of each member, and forwarding the modified packets to group members. Thus, “multicast group” does not here refer to an IP multicast group, but rather to an ad hoc association between both the PTT server&#39;s (unicast) IP address &amp; group-specific RTP port number and the IP addresses &amp; RTP port numbers of active group members. 
     If this is the first received INVITE for groupID1@operator.com, the PTT Server allocates a speech token, members&#39; SIP-URL list, and group-specific RTP port number, saves the association between the group and token/list/port-number, and assigns the token a status of available. In this message flow at least one other member is assumed to have already joined the group. 
     Step 10—The IMS SIP proxy compresses &amp; forwards the 200 OK to MS 1 . 
     Step 11—MS 1  decompresses the 200 OK. Via the MMI, the MS 1  advises the user that the user successfully joined groupID1. The MS also saves the PTT server&#39;s IP address &amp; the group&#39;s RTP port number from the received SDP. The user has joined group groupID1, and will now participate in any in-progress &amp; subsequent group calls. 
     Step 12—The MS sends a compressed ACK to acknowledge receipt of the 200 OK. The IMS proxy server decompresses the ACK &amp; forwards it to the PTT server. 
     Step 13—Upon receipt of the ACK, the PTT server, on behalf of the user, performs a 3rd-party registration. The PTT server sends a REGISTER request, identifying the groupID1 SIP URL as the location at which the user may be reached. (Normally, a SIP client would register on his/her own behalf. The PTT server initiates 3 rd  party registration to reduce the over-the-air messaging and consequent delay to achieve the registration.) 
     Step 14—Upon receipt of the REGISTER request, the proxy server recognizes the PTT server (identified in the From header) as a trusted entity, &amp; skips any normally performed authentication &amp; authorization. The proxy server relays the REGISTER request to the SIP Registrar. 
     Step 15—The SIP Registrar registers groupID1&#39;s URL as a contact for user1@operator.com, where the host portion of the URL includes the PTT server&#39;s IP address, and returns a 200 OK to the IMS proxy server. The 200 OK message includes an Expires header, which specifies the duration of the registration. By virtue of this registration, push-to-talk calls/alerts placed from outside the group to the user will be relayed via the PTT server to the user, so that acceptance of a call of this sort may result in the user leaving the original group session. This registration must be periodically refreshed. (This contact registration is additive with respect to prior registrations. The contact headers and parameters may be used to give the group contact higher priority than prior registrations.) 
     Step 16—The IMS proxy server relays the 200 OK to the PTT server. 
     Now turning to  FIG. 7 , a call flow is shown for a push-to-talk Call (or Talker Arbitration) for an already active group member. This call flow explains how an active group member places a group call. (An active member is one who has already joined the group session.) Note the efficiency of group call setup relative to conventional SIP-based telephony (which would require three SIP messages at a minimum exchanged with each member of the group). Having already indicated in the previous call flows the use of the Proxy-Require header, how the IMS proxy server authenticates/authorizes the user, and how the MS and the IMS proxy server compress SIP messages over the air, such details are omitted in this and subsequent call flows. Preconditions of this call flow include the following: three mobile users have already joined group groupID1, who relate per the peer-to-peer communication model; and the IMS proxy server has already cached profile &amp; location information for all three users. 
     Step 1—The user of MS 1  presses the PTT button to place a group call. Step 2—the MS 1  sends a SUBSCRIBE request to the proxy server, requesting the groupID1 speech token. The SUBSCRIBE method to request and release the speech token for a group is used. The To header identifies the group as groupID1@nextel.com; the Contact header identifies user1@nextel.com as the requestor, and also the grantee of the token in the event that it is granted. Note that the From header includes the display name, which will be ultimately be used to satisfy the requirement to display the name of the call originator. The Event header specification of speech token, with qualifying parameter of status=requested, identifies this as a speech-token request. A zero value for the Expires header signifies that a subscription should not be queued; rather, the resource status should be immediately reported. 
     Step 3—The proxy server forwards the SUBSCRIBE request to the PTT server serving groupID1. 
     Step 4—The PTT server parses the SUBSCRIBE message, and verifies that the groupID1 group is currently being served, that user1 has joined groupID1, and that user1 is authorized to speak within the group. Authorization to speak, whether or not the user has special privileges within the group, etc. is all contained in the user&#39;s membership data that was downloaded from the database server in the previous call flow. The PTT server now checks the status of the speech token that has been allocated for groupID1. If the speech-token status were already “taken”—this would occur when another user had pressed his/her MS&#39;s PTT first and had not yet released it—the PTT server would send to user1@operator.com a 200 OK that indicated this status, and would not queue the request for the speech token since the SUBSCRIBE request&#39;s Expires header indicates a subscription duration of zero. As the token is available, the PTT server saves user1@operator.com as the grantee of the groupID1 speech token, and sends to the users of MS 2  &amp; MS 3  a NOTIFY message that identifies the call originator. Associated with each open &amp; closed group is an inactivity timer. Whenever the speech token is released, the timer is (re)set to a provisioned value. If the timer expires before a new request for the group&#39;s speech token is received, then the current call is considered to have ended, and any next request for the token starts a new call. The PTT server checks whether the timer has expired upon receipt of a speech token request. If so, the PTT Server will convey the display name of the call originator to target users, and must receive at least one response (per our assumption noted in the response to R 8 ) before granting the speech token to the requestor; otherwise, to conserve system capacity, it will not convey the display name of the speaker to other group members, and will immediately provide speech token status to the requestor. The INFO method could also be used to convey the identity of the call originator. Conveying the status of the subscribed resource in the SUBSCRIBE&#39;s 200 OK is an optimization over what is specified in draft-roach-sip-subscribe-notify-03. The present embodiment disallows the Event header in the SUBSCRIBE 200 OK, specifies that the 200 OK should simply indicate acceptance of the subscription, and requires a subsequent NOTIFY request and response to convey the status of the subscribed resource. The NOTIFY method is dispensed in this call flow, and thus “optimized away” two messages over the air and thereby shortened call-setup delay. 
     Step 5—The IMS proxy relays the NOTIFY requests to MS 2  and MS 3 . The request recipients display the identity of the call originator &amp; respond with a 200 OK, which the IMS proxy server relays to the PTT server. 
     Step 6—Upon receipt of the first NOTIFY 200 OK, the PTT server sends the SUBSCRIBE 200 OK conveying “token granted” status. The alternative of having the 200 OK stimulating the MS to play a mobile-generated tone was considered, however, since in other contexts using SIP signaling to stimulate tones would adversely affect system capacity, it was decided to uniformly use RTP to convey tones from the PTT server to MSs. The PTT server also sends an RTP packet conveying the “token granted” tone to MS 1 , so that the mobile may play the tone to the user. 
     Step 7—The IMS proxy server relays the 200 OK to the user of MS 1 . 
     Step 8—The MS 1  receives both the tone-bearing RTP packet and the 200 OK. MS 1 , consequently, notifies the user (e.g., via audible tone) that he has been granted the right to speak. If the speech token were already taken (versus granted), a different audible tone would be sounded, releasing the PTT button would not result in any SIP messaging, and the user returns to Step 1 if he still wishes to obtain the right to speak. 
     Step 9—The user speaks. 
     Step 10—The MS 1  vocodes the speech using its EVRC/SMV codec, and sends voice packets to the PTT server. 
     Step 11—The PTT server receives the voice packets. For each active member of the group (other than the packet originator), the server replaces the destination IP address and port number of each packet with the member&#39;s address and RTP port number, and sends the modified packet to the member. 
     Now continuing on to  FIG. 8 , Step 12—The user releases the PTT button. 
     Step 13—The MS 1  sends a SUBSCRIBE request to the proxy server, in order to release the groupID1 speech token. 
     Step 14—The IMS proxy server forwards the request to the PTT server. 
     Step 15—The PTT server parses the SUBSCRIBE message, verifies that the groupID1 group is active and that user1@operator.com has been grantedgroupID1&#39;s speech token. Then the PTT server changes the speech-token status to “available,” sends to user1@operator.com a 200 OK that indicates “available” status for the speech token, and clears storage related to speech-token grantee identification. 
     Step 16—The PTT server also sends an RTP packet conveying “token available” status to each MS in the group session. 
     Step 17—The proxy server relays the 200 OK to MS 1 . 
     Step 18—Upon receipt of the RTP packet, which may arrive before the 200 OK in the case of MS 1 , each MS audibly notifies its user that the speech token is available. 
     Now turning to  FIG. 9 , a call flow is shown where a user leaves a closed group session. This call flow depicts a user leaving a closed group session that the user previously joined. Preconditions for this flow include the following: the IMS proxy server has already cached profile &amp; location information for the user; and the IMS proxy server has already cached the IP address of the PTT server serving the groupID1. 
     Step 1—The user indicates via the MMI that the user wishes to leave the previously joined session for group groupID1. 
     Step 2—The Push-to-talk client in MS 1  sends a BYE request, which the IMS proxy server relays to the PTT server. 
     Step 3—On behalf of the user, the PTT server sends a third-party REGISTER request with an Expires header value of zero, in order to remove MS 1 &#39;s registration of groupID1@operator.com as a contact for user1@operator.com. The IMS proxy relays the REGISTER request to the SIP Registrar. 
     Step 4—Finding the Expires header with value of zero, the SIP Registrar removes the registered contact for user1@operator.com, and returns a 200 OK to the IMS proxy server. 
     Step 5—The IMS proxy server relays the 200 OK to the PTT server. The MS will no longer be reached for ad hoc group calls via the proxy server. 
     Step 6—The PTT server effectively removes the user from the group. The server removes the MS 1 &#39;s IP address &amp; RTP port number from the set of such user tuples associated with groupID1, removes the user&#39;s SIP URL from the list of users who&#39;ve joined group groupID1, removes the mapping from the user&#39;s SIP URL to the MS&#39;s IP address, and returns a 200 OK to the SIP proxy server. If MS 1  were the only active member of groupID1, the PTT server would de-allocate the group&#39;s speech token, the group&#39;s SIP-URL member list, &amp; the group&#39;s RTP port number, and would remove the mapping from group ID to token/member-list/port-number. The user of MS 1  no longer participates in group calls. The proxy server relays the 200 OK to MS 1 . 
     Step 7—Upon receipt of the 200 OK, MS 1  indicates to the user that the user has left the groupID1 session. 
     Now turning to  FIG. 10 , a call flow is shown for an alert-initiated, push-to-talk call. The following call flow depicts an alert-initiated Direct connect call involving three users, who comprise an ad hoc group. Both a call setup and a call teardown is shown. In addition to the preconditions identified for all call flows above, this flow specifically has the following preconditions: (1) all users have registered (as exemplified in  FIG. 6 ); (2) the IMS proxy server has cached profile data and contact information for each user; (3) to expedite call setup for ad hoc group calls, each active PTT server has already registered with the Registrar a set of unique, ad hoc group URLs, with the contact for each URL being the PTT server&#39;s URL. Additionally, the host portion of the PTT server&#39;s URL includes the IP address of the PTT server, so as to eliminate the need to do a DNS query to resolve the server&#39;s address. These registrations will be needed to route all alerts/calls intended for users currently participating in an ad hoc group call to the PTT server supporting that call (in the event that a user participating in an ad hoc group call decides to join still another call, the PTT server supporting the original call must cause the user to leave the current call, lest RTP packets from both calls be delivered to the user and result in garbled speech); (4) moreover, at startup, the SIP Registrar established a permanent registration of pttserver@operator.com as a contact for the well known, generic, ad hoc group, groupadhoc@operator.com. This registration enables dynamic assignment of a PTT server for an ad hoc call. Further, the IMS proxy server has already cached the registered contacts (i.e., URLs of available PTT servers) for pttserver@operator.com. 
     The call flow may be analyzed into the following stages: Steps 1-5—alerting the target users; Steps 6-12—targeted user responds to the alert by pressing the PTT button and placing a Push-to-talk call; Step 13—another targeted user declines to participate in the call; Step 14—talker arbitration between call participants; and Step 15—the resulting ad hoc group call is torn down due to inactivity timer expiration. 
     Step 1—The user of MS 1  selects the users user2@operator.com &amp; user3@operator.com as the targets of an ad hoc group alert. 
     Step 2—The MS 1  sends an INVITE request with the To header identifying the well known, ad-hoc group name groupadhoc@operator.com. Conventional SIP restricts the To header to identifying exactly one party. To circumvent this restriction, since two parties are to be alerted, multi-part MIME is used. Multi-part Multipurpose Internet Mail Extension (MIME) is described by publicly available RFC 2046. The body of the INVITE request has two segments: SDP specification of the EVRC/SMV codec &amp; of the sending user&#39;s IP address &amp; RTP port number; XML specification of the URLs that should comprise the ad hoc group. PTT clients &amp; PTT servers must use a common Document Type Definition (DTD) to define the members of an ad hoc group. Resulting XML-based specifications of group members may include the following: a list of constituent group URLs &amp; individual users&#39; URLs (with home domain name included); identification of the group administrator (i.e., the alert originator); the administrator&#39;s preference as to whether other call participants may invite others into the group call. The From header identifies the originator&#39;s SIP URL. The Remote-Party-ID header indicates the alerting party&#39;s display name &amp; SIP URL to be presented to the target users. The Contact header identifies, in the host portion of the URL, the MS&#39;s IP address. The Date header identifies the time of the alert. Independent of the requirement to provide timestamp for alert messages, the Date header should be included in all SIP messages sent by the network to a mobile. MSs may thus detect “overly aged” SIP messages and handle them appropriately. The Subject header provides the means for the sender to convey an optional, customized alert message to the receiving users. The Require header specifies alerting of other group members not already in the session—for an ad hoc group, this is all other group members specified by XML in the message body—and inviting them to join the group session. 
     Step 3—Upon receipt of the INVITE request, the IMS proxy server finds that it has (from a previous Location Server query) already cached pttserver@operator.com as the contact for groupadhoc@operator.com. The proxy server also finds that it has cached a list of URLs of available PTT servers as the contacts for pttserver@operator.com. The IMS proxy server selects the URL of one of the available PTT servers, forwards the INVITE to that PTT server, &amp; sends a 100 Trying to MS 1 . 
     Step 4—Based on groupadhoc@operator.com in the To field, the selected PTT server recognizes this INVITE request as being related to an ad hoc group. The server selects, from among the ad hoc group URLs associated with the server, a currently unused URL—e.g., groupadhoc1@operator.com. The server then parses the XML specification of group members to obtain the list of members&#39; URLs, associates the list with groupadhoc1@operator.com, marks user1@operator.com as having joined the group, &amp; marks the other members as not having joined the group. If a group URL were specified as part of the ad hoc group, then the PTT server would query the Directory Server to obtain URLs for the constituent members of the specified group. It then allocates and associates with the group both a speech token (marked as available) &amp; an RTP port number. The PTT server creates the (empty) set of members&#39; IP addresses &amp; RTP port numbers, places user1&#39;s IP address &amp; RTP port number (from the SDP) into this set, and creates a mapping from the user&#39;s URL to this address &amp; port number. Note that the PTT server functions as a back-to-back user agent (BBUA). To each group member other than the sender of the original INVITE request, the PTT server sends (as a user agent client or UAC) an INVITE request that differs from the original only in the following respects: the To header specifies the target member&#39;s URL; the From header identifies groupadhoc1@operator.com as the alert originator; the Contact header specifies groupadhoc1&#39;s URL, with the host name portion of the URL designating the PTT server&#39;s IP address; the SDP specifies the PTT server&#39;s IP address &amp; the ad hoc group&#39;s RTP port number. 
     Step 5—The IMS proxy server relays the INVITE requests to MS 2  &amp; MS 3 , which each alerts its user regarding the invitation to participate in the ad hoc group call. For example, a user may be alerted audibly (e.g., a tone) or mechanically (e.g., vibration) of the alert, and the associated displayed alert text would include, at a minimum, the display name of user1, the timestamp from the Date header, and any Subject header text. 
     Step 6—The user of MS 2  immediately responds by pressing the PTT button, resulting in MS 2  responding to the INVITE request with a 200 OK. The 200 OK contains SDP that specifies the EVRC/SMV codec, MS 2 &#39;s IP address, and the RTP port number to be used in voice packets that may be sent to MS 2 . The Remote-Party-ID header identifies the calling party&#39;s name, “John” in this call flow. The Contact header includes the user&#39;s IP address. The Event header in the 200 OK indicates that user2@operator.com requests the speech token. The SUBSCRIBE method was previously used in conjunction with the Event header, to request the speech token for a member that has already joined the group session. For one who has not joined the group session, INVITE must be used. Per the appropriate standards, INVITE requests (&amp; INVITE 200 OK for alert-initiated calls) cannot contain the Event header, &amp; use of a subsequent SUBSCRIBE method to request the speech token violates our design constraints to minimize over-the-air messaging &amp; reduce call-setup delay. If the signaling is restricted to one SIP method only, the options are rather ad hoc in nature. One approach is to follow the lead of 3GPP (for network-initiated deregistration) &amp; warp the semantics of the Allow-Events header to signal implicit event subscription (versus the IETF semantics of the sender allowing subscription for the specified events). This approach would at least be consistent with some standard for implicit subscription. Alternatively, the Require header could be used to implicitly subscribe to the speech token, use Event header information, use the message body (e.g., place Event header therein), introduce a new Subscribe header that allows piggybacking of SUBSCRIBE semantics onto the INVITE method or wholly encapsulate the SUBSCRIBE request in the body of the INVITE request or INVITE 200 OK. Once the speech token request is signaled, a separate NOTIFY to grant the token is precluded. (3GPP uses the NOTIFY method to explicitly provide the implicitly subscribed information regarding network-initiated de-registration.) Again, options to grant the speech token include use of the Require header, Event header, the message body, or a new Notify header that piggybacks the semantics of NOTIFY onto the INVITE &amp; ACK methods. The disadvantages of using the Require header is that use of Require is typically domain specific (e.g., specific to Nextel domain), and does not lend itself well to interoperability. Use of the Event header, while optimal in maintaining consistency with its use in the SUBSCRIBE method, would likely not be approved by the IETF for inclusion in the INVITE method. Use of the message body (possibly with Event header-type text), would suffer from the same disadvantage. New headers to piggyback event-subscription semantics onto the INVITE &amp; ACK methods should be further explored, but are not hopeful that this approach will find traction in the IETF. Thus, the present embodiment opted to use the Event header both to subscribe to the speech token (in the INVITE request when the calling party requests the speech token or in the 200 OK when the alerted party requests the token), and to grant it (in 200 OK when the calling party requests the speech token, and in the ACK when the alerted party requests the speech token). A less efficient, but standards-compliant solution, would employ separate INVITE, SUBSCRIBE, and NOTIFY methods, with resulting increased call-setup delay. 
     Step 7—The IMS proxy server relays the 200 OK to the PTT server. 
     Step 8—The PTT server now performs distinct processing related to each of the three members of the ad hoc group, spawning three parallel signaling threads that start in this step, Step 10, and Step 12. For user2@operator.com, the PTT server marks user2@operator.com as having joined the group, adds the user&#39;s IP address &amp; RTP port number (from the received SDP) to the set of such maintained for members who have joined the group session, and creates a mapping from the user&#39;s URL to his/her IP address &amp; RTP port number. The PTT server sends an ACK, with the Event header indicating to MS 2  that its user has been granted the speech token, and also sends an RTP packet with the token-granted tone to MS 2 . The IMS proxy server relays the ACK to MS 2 , which notifies the speaker (e.g., via audible tone) that the user may speak. Accordingly, the user begins to speak, and the PTT server distributes the resulting voice packets to all other users who have joined the session (i.e., in this case just user 1 ). 
     Now continuing on to  FIG. 11 , Step 9—In parallel with the PTT server&#39;s ACK transmission of Step 8. The PTT server also sends a 3 rd -party registration on behalf of user2. The REGISTER request identifies groupadhoc1 as a contact for the user. The IMS proxy server relays the REGISTER request to the registrar. The registrar registers the contact, &amp; returns a 200 OK via the IMS proxy server. 
     Step 10—This step occurs in parallel with Step 8. For user1@operator.com, the PTT server (as BBUA) sends a 200 OK final response to the original INVITE request, signifying that one of the targeted users has joined the call. The Contact header identifies the allocated ad hoc group URL. The allocated ad hoc group URL would be needed in order for the originator of the alert to expand the group membership and invite others into the call. The SDP specifies the EVRC/SMV codec, the PTT server&#39;s IP address, and the group&#39;s RTP port number. The Remote-Party-ID header identifies “John,” or user2@operator.com, as the calling party. The IMS proxy server relays the 200 OK to MS 1 . MS 1  notifies the user that user2@operator.com (i.e., “John”) has been granted the speech token (the 200 OK with caller identification will generally arrive prior to any voice packets, as both must be transmitted by the PTT server to MS 1 , and the server first sends the 200 OK), and sends an ACK. The IMS proxy relays the ACK to the PTT server. 
     Step 11—In parallel with the PTT Server sending the 200 OK in Step 10. The server sends a 3 rd -party registration on behalf of user1, identifying groupadhoc1 as a contact for the user. The IMS proxy server relays the REGISTER request to the registrar, and the 200 OK from the registrar to the user. 
     Step 12—This step occurs in parallel with Step 8. To user3@operator.com, the PTT server sends a NOTIFY request that indicates that “John,” or user2@operator.com, is the calling party. The IMS proxy server relays the message to MS 3 , which clears any audible or mechanical (e.g., vibrating) alert, &amp; updates the alert display to indicate that a call is in progress. MS 3  returns a 200 OK (with the Cseq header indicating that the response is for the NOTIFY rather than for the INVITE). 
     Step 13—the User3, noting that someone else has already responded to the alert, clears the alert at his/her terminal, which sends a  603  (Decline) final response. If no targeted user had responded to the alert in any way prior to expiration of a timer in the targeted MSs&#39; Direct Connect applications, recipients of the INVITE would send a provisional response of 100 Trying, in order to prevent re-transmission of the INVITE by the PTT server. The IMS proxy server relays the response to the PTT server, and returns an ACK to MS 3 . 
     Now continuing on to  FIG. 12 , Step 14—In the meantime, talker arbitration and conversation occur between the two users in call, following the pattern of a prior call flow (that depicts the SUBSCRIBE method to release and request the speech token). The last speaker releases the speech token. 
     Step 15—Each time the speech token is released by any ad hoc group call participant, the PTT server (re)starts an inactivity timer. As the call participants have completed their conversation, the timer finally expires. The PTT server sends a BYE request to each user (via the IMS proxy server), removing them from the group session. When the users respond (via the IMS proxy server) with a 200 OK, the PTT server sends REGISTER requests to remove the registration of groupadhoc1@operator.com as a contact for the users. The IMS proxy server relays the requests to the registrar, which removes the contacts and returns 200 OKs. The IMS proxy relays these final responses to the PTT server, which dissolves the group membership, and de-allocates the group URL and associated RTP port number. To avoid certain race conditions, the group URL and associated RTP port number should be “rested” for some time before being used for another group. 
     It is understood that several modifications, changes and substitutions are intended in the foregoing disclosure and in some instances some features of the invention will be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.

Metadata:
Filing Date: 20101001
Publication Date: 20130423
Grant Date: 20130423
Priority Date: 20010212
Inventors: DENMAN ROBERT E.
PARAMESWAR SRIRAM
DERRYBERRY BARBARA
Assignee: APPLE INC
CPC Classifications: [{"code": "H04W72/30", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W72/30", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L2101/60", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L65/4038", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/4038", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/08", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/1104", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W80/10", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W76/45", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/1104", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/08", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/10", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L65/4061", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/1069", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L65/4061", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W4/10", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04W80/10", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W76/45", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 42734009