Abstract:
Voice communication between a mobile station and a packet-based voice communication system is handled. A communication interface for mobile station access to a telecommunication network over a public data network according to a first protocol is emulated at a gateway system. Communications pass between the gateway and the packet-based voice communication system according to a second protocol. Control communication information passing between the mobile station and the packet-based voice communication system is converted.

Description:
BACKGROUND 
       [0001]    This description relates to data conversion. 
         [0002]    Unlicensed Mobile Access (UMA) technology provides access to GSM and GPRS mobile services over unlicensed spectrum technologies, including Bluetooth and 802.11. By deploying UMA technology, service providers can enable subscribers to roam and handover between cellular networks and public and private unlicensed wireless networks using dual-mode mobile handsets. 
         [0003]    Referring to  FIG. 1 , network protocols transport legacy GSM/GPRS voice/data bearer and signaling traffic between a UMA mobile station (MS)  100  and a GSM/GPRS mobile network  102 . In some examples, the mobile station  100  connects to a base transceiver station  116  to transmit traffic to the mobile network  102  through a private network  114 . In some examples, the mobile station  100  connects to an access point  110  to transmit the traffic inside a secured IP tunnel (IPSec)  104  across a public data network (e.g., Internet)  106 . A UMA Network Controller (UNC)  108  acts as the Base Station Controller (BSC) for MS  100  from the point of view of the mobile network  102 . The UNC  108  terminates the IPSec tunnels from MS  100  and presents the GSM/GPRS voice/data bearer and signaling to a Mobile Switching Center in the core mobile network  102 . This allows traditional/legacy GSM/GPRS networks to treat UMA mobile devices as regular GSM/GPRS mobile devices. An access point  110 , such as a standard wireless router, or computer, carries traffic using unlicensed spectrum technologies from MS  100  to IPSec  104 , through which the traffic is transmitted across IP network  106  to UNC  108 . 
         [0004]    The protocols that control the calls and manage the mobility in UMA are based on legacy circuit-switched GSM and packet-switched GPRS. The IP network  106  is only used as a means to transport the legacy protocols between the mobile devices and the networks. Voice/data bearer and signaling traffic are still processed by and traverse through the legacy GSM/GPRS network elements, which are not architected to take full advantage of the higher bandwidths made possible by the unlicensed spectrum technologies. 
         [0005]    An IMS, or IP Multimedia Subsystem, is an element in a Third Generation (3G) network architecture that merges cellular networks and the Internet. IMS allows a user to access internet services, such as accessing web pages, reading emails, watching a movie, or taking part in a videoconference, using a 3G hand-held device. 
         [0006]    Although IMS is not yet widely available, IP PBX and IP Centrex provide Voice-over-IP communications and support traditional private branch office and centrex voice features as well as services over IP networks. 
         [0007]    The protocols that control calls and manage mobility in IMS are based on SIP (Session Initiation Protocol). IP PBX and IP Centrex are also based on SIP and other IP-based protocols. SIP was specified by the IETF as a protocol to establish and manage multimedia sessions over IP networks, and follows a client-server model used by many protocols developed by the IETF. It requires a SIP Client running in the end user mobile device interacting with Application Servers in the IMS. To access IMS services, IP PBX and IP Centrex from UMA mobile devices, the UMA mobile device runs a SIP Client. 
       SUMMARY 
       [0008]    In general, in one aspect, voice communication between a mobile station and a packet-based voice communication system is handled. A communication interface for mobile station access to a telecommunication network over a public data network according to a first protocol is emulated at a gateway system. Communications pass between the gateway and the packet-based voice communication system according to a second protocol. Control communication information passing between the mobile station and the packet-based voice communication system is converted. 
         [0009]    Implementations may include one or more of the following features. The packet-based voice communication system is an IP Centrex. The packet-based voice communication system is an IP PBX. The packet-based voice communication system is an IMS-based telecommunication system. The first protocol is UMA. The second protocol is SIP. Converting the control communication includes translating between a GSM and/or GPRS messages and SIP messages. 
         [0010]    In general, in one aspect, a data network service is accessed from a mobile terminal. A gateway is provided for converting control communications received from the mobile terminal from a first protocol to a second protocol, where the second protocol is compatible with the service. 
         [0011]    Implementations may include one or more of the following features. The mobile terminal accesses the data network service over a wireless telecommunication network. The mobile terminal is a UMA terminal. 
         [0012]    Commercial UMA mobile devices will soon be available in volume. The solutions described herein enable a UMA user to access IMS services, IP PBX and IP Centrex without any changes to the infrastructure of the device, as an SIP client is not required on the UMA device. Deployment of IMS is accelerated by taking advantage of UMA dual-mode phones. UMA mobile devices can access IMS and IP PBX/Centrex services, without any change to the UMA handsets, or any change to GSM and IMS/SIP services or protocols. 
         [0013]    The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. 
     
     
       DESCRIPTION 
         [0014]      FIGS. 1 ,  2 , and  3  show networks. 
           [0015]      FIG. 4  and  FIG. 5  show protocol architectures 
           [0016]      FIG. 6  and  FIG. 7  show flow charts. 
       
    
    
       [0017]    The following terms are used in this description:
   AS Application Server   BSC Base Station Controller   CAMEL Customized Applications for Mobile network Enhanced Logic   CSCF Call/Session Control Function   DHCP Dynamic Host Configuration Protocol   GMSC Gateway MSC   GPRS General Packet Radio Service   GSM Global System for Mobile communications   HLR Home Location Register   IMS IP Multimedia System   IMS AS IP Multimedia System Application Server   IP Sec Secured IP tunnel   MGW Media Gateway   MSC Mobile service Switching Centre   MS Mobile Station   NCG Network Convergence Gateway   PLMN Public Land Mobile Network   PSTN Public Switched Telephone Network   RTP Real Time Protocol (used for VoIP media)   SIP Session Initiation Prtocol (used for VoIP signaling)   STP SS7 Network Signal Transfer Point   UDP User Datagram protocol   UMA Unlicensed Mobile Access   VLR Visitor Location Register   VMSC Visited MSC   VPLMN Visited PLMN   
 
         [0044]    We describe a UMA-to-SIP convergence (USC) gateway that bridges communication between UMA mobile devices and other communication systems including, for example, IMS based wireless networks and IP PBX/Centrex services. By using such a UMA-to-SIP gateway, the mobile devices can participate in SIP-based communication session without using a SIP client that is hosted in the mobile devices. 
         [0045]    Referring to  FIG. 2 , a USC Gateway  200  communicates with the UMA mobile station (MS)  100  such that, from the point of view of the MS  100 , the USC Gateway  200  functions as a standard UMA Network Controller (UNC), and therefore standard UMA functionality hosted in the mobile device is suitable for communication with the USC Gateway  200 . In particular, the MS  100  connects to an access point  110  and obtains an IP address from a Dynamic Host Configuration Protocol (DHCP) server  207  to communicate with the Internet  106  over an access router  209 . MS  100  interacts with a USC Gateway  200  that follows UMA specific protocols and is compliant to UMA specifications that govern UMA mobile device to UNC interface interactions. The USC Gateway  200  interacts with SIP-based communication systems, such as an IP PBX or IP Centrex system  203 , through a Network Convergence Gateway (NCG)  202  as if it were functioning as an SIP User Agent from the point of view of such systems. 
         [0046]    USC Gateway  200  can also can establish traditional network connections with a PSTN network  204  or a standard mobile network  206 . The connections are established using standard methods, through an IP Network  208 . In some examples, USC  200  connects to a Softswitch &amp; Media Gateway  210  to transmit data to a standard PSTN phone  214  over a PSTN network  212 . In some example, USC  200  connects to a signaling gateway  216  through NCG  202  to transmit data over an SS7 Network Signal Transfer Point (STP) server  218  in the mobile network  206 . The STP server  218  has access to a Short Message Service Center (SMSC) server  220 , a Home Location Register (HLR) server  222 , and an MSC  224 . 
         [0047]    Referring to  FIG. 3 , USC Gateway  200  interacts with MS  100  on one end and with an IMS network  300  on the other side. In this network architecture, an NCG device is not required for traffic routing. 
         [0048]    Again, from the point of view of the IMS network  300 , the USC Gateway  200  behaves like a SIP User Agent (SIP Client) on behalf of MS  100 . It translates and converts legacy GSM circuit-switched interactions with MS  100  into IP-based SIP and IMS compliant protocols used in IMS and IP PBX/Centrex services. USC  200  can communicate with an IMS Call Session Control Function (CSCF) server  302 , an IMS Application Server (AS)  306 , and a VCCF server  304  in the IMS network  300 . To IMS AS  306  and IP PBX/Centrex  203 , UMA mobile device appear just like any other SIP/IMS client. 
         [0049]    System and protocol architectures of the USC Gateway are shows in  FIG. 4  and  FIG. 5 . Referring to  FIG. 4 , a MS  100  has protocol modules  400 ,  402 ,  404 ,  406 ,  408 ,  410 ,  412 , and  414  containing control data. Modules  412  and  414  provide data to peer communication modules  416  and  418  within the standard access point  110 . The module  418  processes data from unlicensed lower layers to access layers  420  and provides the data to protocol modules  422  and  424  in the IP network  106 . The IP Network  106  forwards the data to peer protocol modules  438  and  440  in the USC  200 . Protocol modules  400 ,  402 ,  404 ,  406 ,  408 , and  410  also forward data to peer protocol modules  426 ,  428 ,  430 ,  432 ,  434 , and  436  in the USC  200 . The USC  200  processes data in modules  426 ,  428 , and  430  and rebundles the data as SIP in protocol module  442 . The USC  200  processes data in modules  432 ,  434 , and  436  and rebundles the data as TCP/UDP in protocol module  444 . The USC  200  forwards the data in protocol modules  442 ,  444 ,  445 , and  448  to modules  450 ,  452 ,  454 , and  456  in the CSCF server  302  to be forwarded through the IMS network  300 . 
         [0050]    Referring to  FIG. 5 , a MS  100  has protocol modules  500 ,  502 ,  504 ,  506 ,  508 , and  510  containing voice bearer data. Modules  508  and  510  provide data to peer communication modules  512  and  514  within the standard access point  110 . Data in module  514  is processed from unlicensed lower layers to access layers  516 . The access point  110  provides the data in modules  512  and  516  to protocol modules  518  and  520  in the IP network  106 . The IP Network  106  forwards the data to peer protocol modules  532  and  534  in the USC  200 . Protocol modules  500 ,  502 ,  504 , and  506  also forward data to peer protocol modules  524 ,  526 ,  528 , and  530  in the USC  200 . The USC  200  processes GERAN codec data in module  524  into other codec data  536 . The USC  200  processes data in modules  526 ,  528 , and  530  and rebundles the data as RTP/UDP in protocol module  538 . Protocol module  522  assists with transcoding if necessary. The USC  200  forwards the data in protocol modules  536 ,  538 ,  540 , and  542  to modules  536 ,  538 ,  540  and  542  in the IMS application server  306  to be forwarded through the IMS network  300 . 
         [0051]    Referring to  FIG. 6 , supplementary services such as three-way calling can be implemented for a UMA mobile station  100 . This technique allows for more sophisticated call flows to implement scenarios in which a dedicated IMS Conference Call Application Server  306  or an IP PBX/IP Centrex  203  performs the conference call management and control. Such an IMS Conference Call Application Server would reside in the IMS domain as shown as “IMS AS” in  FIG. 3 . The IP PBX/IP Centrex case would be as shown in  FIG. 2 . In both the IMS and IP PBX/IP Centrex cases, the USC Gateway converts legacy GSM protocols (e.g., sending star codes over legacy GSM communication channel) into SIP/IMS compliant protocol messages, inter-working with IMS and IP PBX/IP Centrex. 
         [0052]    In some examples, a UMA mobile station (MS)  100  dials a telephone number to call a first party  650  (Step  600 ). The USC Gateway  200  receives the dialed number and sends an SIP invite to the appropriate Media Gateway (MGW)  210  (Step  602 ), which forwards the invite on to a PSTN  212  (Step  603 ). The PSTN  212  sends an alert to the first party  650  (Step  604 ), who then answers the call (Step  605 ). The PSTN  212  returns an ANM message to the MGW  210  (Step  606 ), which forwards a SIP OK message back to USC Gateway  200  (Step  608 ). USC Gateway sends a “Call Answered” message back to MS  100  (Step  610 ) and sets up the call with the first party as a UMA conversation (Step  612 ). The conversation segment between MGW  210  and MS 2   650  is initiated as a voice conversation using standard techniques (Step  614 ). 
         [0053]    While on the active call with the first party, the subscriber  115  can initiate three-way calling by inviting another third party  652  to join the call. In some examples, the subscriber dials a star code (e.g., “*3”) to indicate that he wishes to initiate three-way calling, followed by a telephone number (e.g., “781 111 5678”) for the third party  652  (Step  616 ). In some examples, the USC Gateway  200  does the call bridging and voice media stream mixing to set up the three-way calling. The USC Gateway  200  uses standard techniques to initiate the call with the third party  652 , sending an SIP invite to the appropriate MGW  210  (Step  618 ), who sends an IAM message to the appropriate PSTN  212  (Step  619 ), which sends an alert to the third party  652  (Step  620 ). The third party  652  answers (Step  621 ), and the PSTN  212  sends an ANM message back to the MGW  210  (Step  622 ). MGW  210  sends an SIP OK message back to the USC Gateway  200  (Step  624 ). USC Gateway  200  then mixes all three call legs among the parties and sends a “Call Answered” message back to MS  100  (Step  626 ). The call leg between the third party  652  and MGW  210  is set up as a Voice Conversation ( 628 ), while the call leg between MS  100  and MW  210  is a UMA conversation (Step  630 ). 
         [0054]    Referring to  FIG. 7 , a UMA Handset  100  can act as an IP PBX Extension Phone for Mobile PBX Services. In some examples, the USC Gateway  200  makes the UMA handset into a mobile IP PBX extension phone. By simply configuring different dialing plans in the USC Gateway, digits dialed on UMA handsets can be recognized as office extensions and be forwarded to IP PBX/IP Centrex for processing. 
         [0055]    In some examples, the extension “301” is dialed from the UMA MS  100  (Step  702 ). The USC Gateway  200  recognizes this as a valid extension dialing plan and forwards the call to an IP PBX  202  as a “SIP INVITE to extension  301 ” (Step  704 ). A remote office desktop IP phone  700  rings (Step  706 ). An SIP message that the phone is ringing is forward from the IP phone  700  to the IP PBX  202  (Step  708  to the USC Gateway  200  (Step  710 ) to MS  100  (Step  712 ). The third party answers the IP phone  700 , which sends an SIP OK message to IP PBX  202  (Step  714 ), which forwards the OK message to USC Gateway  200  (Step  716 ), which sends a “Call Answered” message to MS  100  (Step  718 ). A UMA Voice Conversation is initiated between MS  100  and IP phone  700  (Step  720 ). 
         [0056]    Without the USC Gateway acting (or proxying) as a SIP User Agent on behalf of the UMA Handset, complicated network setups are required to implement such as Mobile PBX service. Typical implementations use mechanisms such as CAMEL to trigger or force call routing to force-route the dial digits (“301”) into the IP PBX or IP Centrex. 
         [0057]    The approach described here requires no CAMEL triggers, no force-call routing, no change to UMA handset; no special software to download, and no change to UMA, GSM, IP PBX/Centrex protocols &amp; networks. Mobile service providers only need to deploy the USC Gateway in their network to rollout Mobile/Wireless IP PBX service with UMA handsets. 
         [0058]    Accordingly, other embodiments are within the scope of the following claims.