Abstract:
A method and system wherein a Voice over LTE via Generic Access (VoLGA) Access Network Controller (VANC)1 upon receiving a REGISTER and REGISTER UPDATE message from the UE1 notifies a Hand Over Selection Function node (HOSF) that a user equipment (UE) is registered in the VANC. This will only be done if the HOSF has not theretofore been notified.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority from U.S. Provisional Patent Application No. 61/105,623 filed Oct. 15, 2008 entitled MOBILITY SOLUTION SELECTION FOR VOICE OVER EPS; U.S. Provisional Patent Application No. 61/140,393 filed Dec. 23, 2008 entitled HANDOVER ROUTING IN CS-OVER-LTE-VIA-GAN SOLUTIONS; and U.S. Provisional Patent Application No. 61/150,041, filed Feb. 5, 2009 entitled VOICE OVER LTE VIA GENERIC ACCESS (VoLGA) ACCESS NETWORK CONTROLLER (VANC) SELECTION FOR HANDOVER (HO), each of which are hereby incorporated herein by this reference and considered a part hereof as if included herein in their entirety. 
     
    
     TECHNICAL FIELD 
       [0002]    The invention relates to the field of wireless telecommunications. 
       BACKGROUND 
       [0003]    As used herein, the following abbreviations shall have the following meanings: 
         [0004]    3GPP Third Generation Partnership Project 
         [0005]    ACM Address Complete Message 
         [0006]    BSS Base Station Subsystem 
         [0007]    CAMEL Customized Applications for Mobile networks Enhanced Logic 
         [0008]    CDMA Code Division Multiple Access 
         [0009]    CS Circuit Switched 
         [0010]    DTM/PSHO Dual Transfer Mode/Packet Switched Handover 
         [0011]    EPS Evolved Packet System 
         [0012]    E-UTRAN Evolved-UTRAN 
         [0013]    FQDN Fully Qualified Domain Name 
         [0014]    GAN Generic Access Network 
         [0015]    GANC GAN Controller 
         [0016]    GBR Guaranteed Bit Rate 
         [0017]    GERAN GSM EDGE Radio Access Network 
         [0018]    GSM Global System for Mobile Communications 
         [0019]    GW Gateway 
         [0020]    HLR Home Location Register 
         [0021]    HO Handover 
         [0022]    HSS Home Subscriber Server 
         [0023]    IMS IP Multimedia Subsystem 
         [0024]    IAM Initial Address Message 
         [0025]    IMSI International Mobile Subscriber Identity 
         [0026]    IP Internet Protocol 
         [0027]    ISDN Integrated Services Digital Network 
         [0028]    ISUP ISDN User Part 
         [0029]    LTE Long Term Evolution 
         [0030]    MGW Media Gateway 
         [0031]    MM Mobility Management 
         [0032]    MME Mobility Management Entity 
         [0033]    MMTel Multimedia Telephony 
         [0034]    MSC Mobile Switching Center 
         [0035]    MSISDN Mobile Station International Subscriber Directory Number 
         [0036]    Non-GBR Non-Guaranteed Bit Rate 
         [0037]    O&amp;M Operations and Maintenance 
         [0038]    PS Packet Switched 
         [0039]    QCI QoS Class Identifier 
         [0040]    RAN Radio Access Network 
         [0041]    SDP Session Description Protocol 
         [0042]    SES Send End Signal 
         [0043]    SGSN Serving GPRS Support Node 
         [0044]    SRVCC Single Radio Voice Call Continuity 
         [0045]    STN-SR Station Transfer Number for SRVCC 
         [0046]    TAU Tracking Area Update 
         [0047]    UE User equipment 
         [0048]    UMTS Universal Mobile Telecommunications System 
         [0049]    UNI User Network Interface 
         [0050]    UTRAN UMTS Radio Access Network 
         [0051]    VANC VoLGA Access Network Controller 
         [0052]    VCC Voice Call Continuity 
         [0053]    VoIP Voice over Internet Protocol 
         [0054]    VoLGA Voice Over LTE via Generic Access 
         [0055]    WCDMA Wideband CDMA 
         [0056]    The 3rd Generation Partnership Project (3GPP) is a collaboration among groups of telecommunications associations, to make a globally applicable third generation (3G) mobile phone system specification within the scope of the International Mobile Telecommunications-2000 project of the International Telecommunication Union (ITU). 3GPP specifications are based on evolved Global System for Mobile Communications (GSM) specifications. 3GPP standardization encompasses Radio, Core Network and Service architecture. The project was established in December 1998. 
         [0057]    The 3GPP Specification provides different methods to support a voice service via Evolved Packet System (EPS). One is Internet Protocol (IP) Multi-media Subsystem (IMS) Multimedia Telephony (MMTel) which may be required to use Single Radio Voice Call Continuity (SRVCC) if there are no Voice over Internet Protocol (VoIP) over Packet Switched (PS) radio bearers in the wide area network. SRVCC supports IMS Voice with a mechanism to move the GSM, Wideband Code Division Multiple Access (WCDMA) or cdma2000 1×RTT access and support voice service using a Circuit Switched (CS) bearer rather than a packet bearer which is the primary choice for an IMS based voice service. 
         [0058]    Another method to support a voice service via EPS is CS fallback wherein the user has access to the voice service while being connected to the Long Term Evolution (LTE) access, but the voice service is provided by an access that has (native) support for a CS voice service, i.e. GSM, WCDMA, or cdma2000 1×RTT. Furthermore, there are industry initiatives to improve CS fallback by re-using some of the SRVCC mechanisms. However, re-using standardized methods provided by 3GPP may create conflicts among the different methods. 
         [0059]    There are a number of disadvantages with each of these methods. The service level of IMS has not reached the level of functionality that is present in the CS network currently. CS fallback does not use LTE radio resources for the CS service, and requires longer call setup time than that of conventional CS networks. 
         [0060]    To remedy these disadvantages, several methods of operating the CS service over LTE have been proposed. One of these methods re-uses Generic Access Network (GAN) architecture. GAN allows the CS services to be operated over a generic IP access and internet, e.g. provided over a WLAN. To support handover, the terminal is assumed to use two (2) radios, one for the macro network and one for the IP access network. Such is not the case when applied in LTE. In that situation, only one radio is assumed, as only one RAT can be used at one instance in time. To operate, as noted above, mechanisms from SRVCC are re-used. 
         [0061]    A forum, Voice over LTE via Generic Access (VoLGA) has formed to specify how to make traditional GSM/Universal Mobile Telecommunications System (UMTS) CS services available to User Equipment (UE) accessing the EPS network via LTE. The VoLGA service resembles the 3GPP GAN. GAN provides a controller node, the GAN controller (GANC), inserted between the IP access network (i.e., the EPS) and the 3GPP core network. The GAN provides an overlay access between the terminal and the CS core without requiring specific enhancements or support in the network it traverses. This provides a terminal with a “virtual” connection to the core network. The terminal and network thus reuse most of the existing mechanisms, deployment and operational aspects of the network. GAN services and objectives are reused in VoLGA wherever beneficial. 
         [0062]    For VoLGA, all signalling and user plane traffic is fully transparent to the EPS access network on the User Network Interface (UNI). This means that the EPS regards all VoLGA traffic as normal user plane traffic occurring over suitable EPS bearers. It also implies that the UE must attach to the EPS first before any VoLGA traffic can occur. VoLGA specific support may be added to the EPS if required to ensure a complete solution. 
         [0063]    An important distinction between VoLGA services and GAN services exists. VoLGA only supports access to CS services, not PS services. Unlike GAN, VoLGA does not support packet access to the 2G/3G Serving GPRS Support Node (SGSN). Instead, PS services are provided to the VoLGA enabled UE by directly employing the EPS system without any additional entities or functions related to VoLGA, other than the capability for combined Handover (HO) of voice, FAX, data, etc., and non-voice packet bearers. There is no impact on the PS service delivery onto the EPS UE from VoLGA.  FIG. 1  shows the proposed architecture  100  for VoLGA at present including the VoLGA Access Network Controller (VANC)  101  as further explained herein. As noted hereinbefore, there are disadvantages to re-using SRVCC mechanisms. HOs from LTE to 2G/3G for VoLGA based on using SRVCC procedures are described below. To accomplish this, the network must in some way handle coexistence as described elsewhere in the art and is outside the scope of this application. Once it is determined known that a HO is for VoLGA, the VANC  101  where the UE  102  is registered must be found. The VANC  101  that is conventionally selected is based on the Tracking Area ID and load balancing algorithms. Mobility Management Entity (MME)  103  only uses target cell identity to select a HO peer. The data present in the HO signaling is not helpful to any other peer, for example a Hand Over Selection Function (HOSF) to select the correct VANC  101 . 
         [0064]    To address this issue, a number of proposed contributions have been made in VoLGA forum. All of the contributions include methods to inform the MME to which VANC a potential HO should be targeted. A problem arises however as such methods affect the MME, and hence, the MME of 3GPP release 8 cannot be used. 
         [0065]    To further explain the context of the invention, reference is made to  FIG. 2 , which is the SRVCC architecture for the Evolved UTRAN (E-UTRAN) to 3GPP UMTS Radio Access Network (UTRAN)/GSM EDGE Radio Access Network (GERAN) and  FIG. 3  is a call flow diagram  300  for SRVCC from E-UTRAN to GERAN without Dual Transfer Mode/Packet Switched Handover (DTM/PSHO) support. 
         [0066]    As seen in  FIG. 3 : 
         [0067]    Step  301 . Based on UE measurement reports the source E-UTRAN decides to trigger an SRVCC handover to GERAN. 
         [0068]    Step  302 . Source E-UTRAN sends Handover Required (Target ID, Source to Target Transparent Container) message to the source MME. The E-UTRAN also indicates to the MME that this is an SRVCC handover operation. 
         [0069]    Step  303 . Based on the QoS Class Identifier (QCI) associated with the voice bearer (QCI 1) and the SRVCC handover indication, the source MME splits the voice bearer from the non voice bearers and initiates the PS-CS handover procedure for the voice bearer only towards Mobile Switching Center (MSC) Server. 
         [0070]    Step  304 . The MME sends a Forward Relocation Request (Station Transfer Number for SRVCC (STN-SR), Mobile Station International Subscriber Directory Number (MSISDN), Source to Target Transparent Container, Mobility Management (MM) Context) message to the MSC Server. The MSC server is selected based on the Target ID received in the Handover Required message. The MME received STN-SR and MSISDN from the HSS as part of the subscription profile downloaded during the E-UTRAN attach procedure. The MM Context contains security related information. CS security key is derived by the MME from the E-UTRAN/EPS domain key as defined in TS 33.401. The CS Security key is sent in the MM Context. 
         [0071]    Step  305 . The MSC Server interworks the PS-CS handover request with a CS inter-MSC handover request by sending a Prepare Handover Request message to the target MSC. 
         [0072]    Step  306 . The Target MSC performs resource allocation with the target BSS by exchanging Handover Request/Acknowledge messages. 
         [0073]    Step  307 . Target MSC sends a Prepare Handover Response message to the MSC Server. 
         [0074]    Step  308 . The establishment of circuit connection between the target MSC and the Media Gateway (MGW) associated with the MSC Server e.g. using the ISDN User Part (ISUP) Initial Address Message (IAM) and Address Complete Message (ACM) messages. 
         [0075]    Step  309 . The MSC Server initiates the Session Transfer by using the STN-SR e.g. by sending an ISUP IAM (STN-SR) message towards the IMS. Standard IMS Service Continuity procedures are applied for execution of the Session Transfer, see TS 23.292 and TS 23.237. During the execution of the Session Transfer procedure the remote end is updated with the Session Description Protocol (SDP) of the CS access leg. The downlink flow of VoIP packets is switched towards the CS access leg at this point. 
         [0076]    NOTE 1: If the MSC Server is using an ISUP interface, then the initiation of the session transfer may fail if the subscriber profile including Customized Applications for Mobile networks Enhance Logic (CAMEL) triggers is not available prior handover (see clause 7.3.2.1 in TS 23.292). 
         [0077]    Step  310 . MSC Server sends a Forward Relocation Response (Target to Source Transparent Container) message to the source MME. Source MME knows that at the end of the PS-CS handover the non-Guaranteed Bit Rate (non-GBR) bearers should be preserved. 
         [0078]    Step  311   a.  Source MME sends a Handover Command (Target to Source Transparent Container) message to the source E-UTRAN. The message includes information about the voice component only. 
         [0079]    Step  312 . Source E-UTRAN sends a Handover from E-UTRAN Command message to the UE. 
         [0080]    Step  313 . Handover Detection at the target Base Station Subsystem (BSS). 
         [0081]    Step  313   a.  The UE starts the Suspend procedure specified in TS 23.060 [10], clause 16.2.1.1.2. This triggers the Target SGSN to send a Suspend Request message to the Source MME. The MME returns a Suspend Response to the Target SGSN, which contains the MM and PDP contexts of the UE. The MME also starts the preservation of non-GBR bearers and the deactivation of the voice bearer. 
         [0082]    Step  314 . Target BSS sends a Handover Complete message to the target MSC. 
         [0083]    Step  315 . Target MSC sends a Send End Signal (SES) HO complete message to the MSC Server. 
         [0084]    Step  316 . Completion of the establishment of the circuit connection between the MSC and the MGW associated with the MSC Server is completed e.g. with the target MSC sending ISUP Answer message to the MSC Server. 
         [0085]    Step  317 . MSC Server sends a Forward Relocation Complete message to the source MME, informing it that the UE has arrived on the target side. Source MME acknowledges the information by sending a Forward Relocation Complete Acknowledge message to the MSC Server. 
         [0086]    Step  318 . MSC Server may perform a MAP Update Location to the Home Subscriber Server/Home Location Register (HSS/HLR) if needed. This may be needed for MSC Server to receive GSM Supplementary Service information and routing of mobile terminating calls properly in certain configuration. This Update Location is not initiated by the UE. 
         [0087]    After the CS voice call is terminated and if the UE is still in GERAN, then (as specified in TS 23.060) the UE shall resume PS services by sending a Routing Area Update Request message to the SGSN. The Update Type depends on the mode of operation of the GERAN network, e.g. in mode I a Combined RA/LA Update is used and in mode II or III Routing Area Update is used. 
       SUMMARY 
       [0088]    The following presents a summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an exhaustive overview of the invention. It is not intended to identify key or critical elements of the invention or to delineate the scope of the invention. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is discussed later. 
         [0089]    In Applicant&#39;s co-pending application, U.S. Ser. No. 61/105,623, applicant discloses an apparatus and method that has not impact on MME. In such application, a Hand over Selection Function (HOSF) node, which could be a separate entity or included in MME or VANC is disclosed. The invention builds upon, and improves the HOSF of that application. A HOSF comprises a microprocessor circuit and associated memories with busses coupling them that configured to perform the steps described herein. The VANC is a microprocessor controller circuit and associated memories and busses coupling them that are configured to perform the steps described herein. 
         [0090]    In the invention, the VANC, upon receiving REGISTER and REGISTER UPDATE messages from the UE, notifies a HOSF that a UE is registered in said VANC. This will only be done if the HOSF has not theretofore been notified. It is assumed that the UE performs a REGISTER UPDATE at every Tracking Area Update (TAU), including at TAUs that occur during HO. If there are several HOSFs, the VANC will either inform every HOSF or it will select one or a few HOSF(s) based on the Tracking Area in which the UE resides within. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0091]    In the following section, the invention will be described with reference to exemplary embodiments illustrated in the figures, in which: 
           [0092]      FIG. 1  illustrates the proposed architecture for VoLGA at present for the invention; 
           [0093]      FIG. 2  illustrates the SRVCC architecture for E-UTRAN to 3GPP UTRAN/GERAN; 
           [0094]      FIG. 3  is a call flow for SRVCC from E-UTRAN to GERAN without DTM/PSHO support; 
           [0095]      FIG. 4  illustrates the elements of an embodiment of the invention; 
           [0096]      FIG. 5  illustrates the elements of another embodiment of the invention; And 
           [0097]      FIGS. 6A and 6B  are flow charts further illustrating the steps of the embodiment. 
       
    
    
     DETAILED DESCRIPTION 
       [0098]    As used herein, a HOSF is a microprocessor circuit and associated memories with busses coupling them that configured to perform the steps described herein. The VANC is a microprocessor controller circuit and associated memories and busses coupling them that are configured to perform the steps described herein. 
         [0099]    Referring to  FIG. 4 , an embodiment of the invention is shown. As seen therein, an LTE Attachment or TAU will trigger UE  401  to start the REGISTER or REGISTER UPDATE procedure. The UE  401  may not start the REGISTER or REGISTER UPDATE procedures during an active call. The VANC  402  will upon receiving the REGISTER or REGISTER UPDATE check if a plurality of HOSFs  403   a - n  (shown as HOSF 1-3), have been informed before that the UE  401  is registered to the VANC  402 . If not, the VANC  402  will send data with the VANC name/address and International Mobile Subscriber Identity (IMSI) of the UE  401 , all in parallel, to the plurality of HOSFs  403   a - n  in the network. The addresses of each of the plurality of the HOSFs are provisioned via Operations and Maintenance (O&amp;M) activity. The addresses could either be IP addresses or Fully Qualified Domain Names (FQDNs). Each of the plurality of HOSFs acknowledge the request with a response. 
         [0100]    The method of the first embodiment are the steps of triggering, by an LTE Attachment or TAU, a UE  401  to start the REGISTER or REGISTER UPDATE procedure, provided the UE  401  may not start the REGISTER or REGISTER UPDATE procedures during an active call; then checking, by the VANC  402 , upon receiving the REGISTER or REGISTER UPDATE, if a plurality of HOSFs  403 A,  403 B,  403 C, have theretofore been notified that the UE  401  is registered to the VANC  402 . If not, then the next step is sending, by the VANC  402 , data with the VANC name/address and IMSI of the UE  401 , all in parallel, to the plurality of HOSFs  403 A,  403 B,  403 C in the network. To accomplish this step, the step also includes provisioning the addresses of each of the plurality of the HOSFs via O&amp;M activity. In such case, the addresses could either be IP addresses or FQDNs. The final step is acknowledging, by each of the plurality of HOSFs, the request with a response. 
         [0101]      FIG. 5  illustrates another embodiment  500  of the invention. As seen therein, an LTE Attachment or Tracking Area Update (TAU) will trigger the UE  501  to start the registration/registration update procedure. The UE  501  will start the registration update procedures during an active call, thus at every HO, if there is a TAU, the registration update procedures will start. The VANC  502  will, upon receiving a REGISTER and REGISTER UPDATE, select a HOSF  503  based on the TA ID received. Note that the TA will have 2G/3G neighbors that an eNB will select for HO targets. The VANC  502  will then check if the selected HOSF  503  has been theretofore notified that UE  501  is registered to said VANC  502 . If not so notified, VANC  502  will send a signal with the VANC name/address and IMSI of the UE  501  to the selected HOSF  503 . The address of the HOSFs in the network and the TA 2G/3G neighboring cell relation are pre-provisioned via O&amp;M activity. The addresses could either be IP addresses or FQDNs. The HOSFs then acknowledge the request with a response. 
         [0102]    The handover procedures are then performed as in the IMS based solution without database as disclosed in Applicant&#39;s co-pending patent application U.S. Ser. No. 61/105,623. As disclosed therein, at HO to 2G/3G, the MME will, based on target cell, select a HOSF (instead of an MSC as in SRVCC), then the HOSF will determine at which VANC the UE is registered, and forward the HO signaling to that VANC. The HOSE does this based on the IMSI received in the first phase as disclosed therein. All HO signaling will pass the HOSF for this HO. 
         [0103]    Referring to  FIG. 6A , the method starts at step  601 A. At step  602 A, the REGISTER or REGISTER UPDATE is received at the VANC. At step  603 A, the VANC will select a HOSE based on received TA and configured data. At step  604 A, it will check if the HOSF has already been informed about the UE&#39;s whereabouts, via its IMSI. If so, the VANC will not contact the selected HOSF, and the method will stop at step  606 A, otherwise, at step  605 A, the VANC will signal the HOSF to inform that the UE is registered within this VANC. 
         [0104]    Referring to  FIG. 6B , the method starts at step  601 B. At step  602 B, the REGISTER or REGISTER UPDATE is received at the VANC. At step  603 B, the VANC will select a number of HOSFs based on received TA and configured data. At step  604 B, it will check if these HOSFs have already been informed about the UE&#39;s whereabouts, via its IMSI. If so, the VANC will not contact the selected HOSFs and the method will stop at step  606 B, otherwise, at step  605 B, the VANC will signals to all the selected HOSFs in parallel to inform that the UE is registered within this VANC. 
         [0105]    The invention may be realized in hardware, software, or a combination of hardware and software. The invention may be realized in a centralized fashion in at least one computer system, or in a distributed fashion where different elements are spread across several interconnected computer systems. Any kind of computer system or other apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software may be a general-purpose computer system with a computer program that, when being loaded and executed, controls the computer system such that it carries out the methods described herein. 
         [0106]    The invention may also be embedded in a computer program product, which comprises all the features enabling the implementation of the methods described herein, and which when loaded in a computer system is able to carry out these methods. Computer program in the present context means any expression, in any language, code or notation, of a set of instructions intended to cause a system having an information processing capability to perform a particular function either directly or after either or both of the following: a) conversion to another language, code or notation; b) reproduction in a different material form. 
         [0107]    While the invention has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.