WO2011044363A1

WO2011044363A1 - Method and apparatus for recovering from a signalling connection failure

Info

Publication number: WO2011044363A1
Application number: PCT/US2010/051825
Authority: WO
Inventors: Michael D. Gallagher; Subhash Kodnad; Sasidhar Padmanabhuni; Vibhav Shah
Original assignee: Kineto Wireless, Inc.
Priority date: 2009-10-07
Filing date: 2010-10-07
Publication date: 2011-04-14

Abstract

Some embodiments provide a method for re-connecting a user equipment (UE) and a network controller. The method receives a register accept message from the network controller. The register accept message includes identification of the network controller. The method detects a connection failure between the UE and the network controller. The method re-connects the UE to the network controller using the identification of the network controller.

Description

METHOD AND APPARATUS FOR RECOVERING

FROM A SIGNALLING CONNECTION FAILURE

BACKGROUND

[0001] Licensed wireless systems provide mobile wireless communications to individuals using wireless transceivers. Licensed wireless systems refer to public cellular telephone systems and/or Personal Communication Services (PCS) telephone systems. Wireless transceivers or user equipments (UEs) include cellular telephones, PCS telephones, PC data cards, wireless-enabled personal digital assistants, wireless modems, and the like.

[0002] Licensed wireless systems utilize wireless signal frequencies that are licensed from governments. Large fees are paid for access to these frequencies. Expensive base station equipment is used to support communications on licensed frequencies. Base stations are typically installed approximately a mile apart from one another (e.g., cellular towers in a cellular network).

[0003] Increasing demand for high data speeds and lower packet latency has required mobile service operators to upgrade existing Universal Mobile Telecommunication System (UMTS) cellular technology. Long Term Evolution (LTE) is one such upgrade which provides improved spectral efficiency, lower costs, and improved service. The decision was made in the third generation partnership (3 GPP) standards to not continue to define and support circuit switched (CS) services in LTE (i.e., to not support the use of the existing CS call control protocol and procedures for voice calls). Instead, the expectation was that the mobile service operators would transition to the use of IP Multimedia Subsystem (IMS)- based voice service in tandem with their addition of LTE (i.e., "4G") air interface and network technology.

[0004] In some LTE systems, a network controller facilitates connection of the LTE's packet only core to the legacy CS core of a 3G system in order to provide CS services (e.g., voice service and Short Message Service or SMS) for UEs. Such network controller is often referred to as a Voice over LTE via Generic Access (VoLGA) network controller (VANC) and is described in VoLGA Forum: "VoLGA Stage 2" Technical Specification (TS), VI .7.0, (2010-06-14) that is incorporated herein by reference.

[0005] Furthermore, the use of unlicensed wireless communication systems to facilitate mobile access to landline-based networks has seen rapid growth. For example, such unlicensed wireless systems may support wireless communication based on the IEEE 802.1 la, b, or g standards (WiFi), or the Bluetooth® standard. The mobility range associated with such systems is typically on the order of 100 meters or less.

[0006] In some unlicensed wireless communication systems, a network controller communicatively couples a UE operating in an unlicensed wireless service region to a licensed wireless system via an access point (AP). Such network controller is often referred to as a Generic Access Network Controller (GANC) and is described in 3GPP TS 43.318: "Generic Access Network (GAN); Stage 2" that is incorporated herein by reference, hereinafter "TS 43.318". The GANC is also described in 3 GPP TS 44.318: "Generic Access Network (GAN); Mobile GAN interface layer 3 specification" that is incorporated herein by reference, hereinafter "TS 44.318".

[0007] A UE establishes a Transmission Control Protocol (TCP) connection with a network controller (either a VANC or a GANC) and subsequently registers with the network controller. However, a problem that may occur after the UE is registered with the network controller is that the established TCP connection may fail. The UE then attempts to reestablish the TCP connection with the network controller. Yet, more problems may arise while re-establishing the TCP connection. For example, the attempts to re-establish the TCP connection may be directed to a different network controller than the network controller with which the UE initially established the TCP connection.

BRIEF SUMMARY

[0008] Some embodiments provide novel techniques for re-establishing a failed signalling connection between a network controller and a user equipment (UE). In some embodiments, the network controller is a network controller for a Voice over Long Term Evolution (LTE) via Generic Access (VoLGA) wireless communication system. Such network controller is also called a VoLGA Network Controller (VANC). In some embodiments, the network controller is a network controller for communicatively coupling several service regions of a first communication network to a licensed wireless second communication network that includes a radio access network and a core network. Such network controller is also called a Generic Access Network Controller (GANC). This first communication network in some embodiments is an unlicensed communication network.

[0009] In some embodiments, the UE receives from the network controller a register accept message indicating the UE is permitted to access services of the network controller. The register accept message in some embodiments includes identification of the network controller. In some embodiments, the identification of the VANC includes an Internet Protocol (IP) address and/or a Fully Qualified Domain Name (FQDN) that translates to the IP address of the network controller. The UE detects a failure on the connection between the UE and the network controller with which the UE has been registered. The UE in some embodiments detects the connection failure by receiving a network reset message or a synchronization command message from the network controller. In some embodiments, the connection between the UE and the network controller is a TCP connection. Having detected the failure, the UE attempts to re-establish a connection to the network controller using the identification of the network controller in some embodiments.

[0010] Some embodiments of the present invention provide a method for UE registration for VoLGA services. The method sends a register request message from the UE to the VANC to register the UE with the VANC. The register request message includes location information that identifies an evolved packet system (EPS) cell upon which the UE has camped. The method receives a response message at the UE from the VANC. The response message indicates whether the UE is permitted to access services of the VANC. When it is determined that the UE is permitted to access the services of the VANC, the response message is a register accept message. The register accept message in some embodiments includes an identification of the VANC. In some embodiments, the identification of the VANC includes an Internet Protocol (IP) address and/or a Fully Qualified Domain Name (FQDN) that translates to the IP address of the VANC. The method in some embodiments stores the address of the VANC for future use.

[0011] The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description and the Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawing, but rather are to be defined by the appended claims, because the claimed subject matters can be embodied in other specific forms without departing from the spirit of the subject matters.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The novel features of the invention are set forth in the appended claims.

However, for purpose of explanation, several embodiments of the invention are set forth in the following figures.

[0013] Figure 1 illustrates a non-roaming architecture for VoLGA using A-Mode interface in some embodiments.

[0014] Figure 2 illustrates a non-roaming architecture for VoLGA using Iu-Mode interface in some embodiments.

[0015] Figure 3 illustrates the protocol architecture for the VoLGA control plane

(VoLGA A-mode) in some embodiments.

[0016] Figure 4 illustrates the protocol architecture for the VoLGA control plane

(VoLGA Iu-mode) in some embodiments.

[0017] Figure 5 illustrates VANC service discovery in HPLMN using DHCP in some embodiments.

[0018] Figure 6 illustrates VANC service discovery in HPLMN using DNS in some embodiments.

[0019] Figure 7 illustrates an example architecture for VoLGA in some embodiments.

[0020] Figures 8 and 9 illustrate VANC service discovery in HPLMN or VPLMN using DHCP and DNS that uses round-robin DNS in some embodiments.

[0021] Figures 10 and 11 illustrate VANC service discovery in HPLMN or VPLMN using DHCP and DNS that uses round-robin DNS and geographical information of the UE in some embodiments.

[0022] Figure 12 illustrates VoLGA service registration in some embodiments.

[0023] Figure 13 illustrates VoLGA deregistration initiated by the UE in some embodiments.

[0024] Figure 14 illustrates VoLGA deregistration initiated by the VANC in some embodiments. [0025] Figure 15 illustrates a procedure for a re-synchronization between the UE and the VANC in normal cases in some embodiments.

[0026] Figure 16 illustrates a procedure for a re-synchronization between the UE and the VANC in abnormal cases in some embodiments.

[0027] Figure 17 conceptually illustrates a process for preventing abnormal cases of a re-synchronization.

[0028] Figure 18 conceptually illustrates a computer system with which some embodiments of the invention are implemented.

DETAILED DESCRIPTION

[0029] In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.

[0030] Some embodiments provide novel techniques for re-establishing a failed signalling connection between a network controller and a user equipment (UE). In some embodiments, the network controller is a network controller for a Voice over Long Term Evolution (LTE) via Generic Access (VoLGA) wireless communication system. Such network controller is also called a VoLGA Network Controller (VANC). In some embodiments, the network controller is a network controller for communicatively coupling several service regions of a first communication network to a licensed wireless second communication network that includes a radio access network and a core network. Such network controller is also called a Generic Access Network Controller (GANC). This first communication network in some embodiments is an unlicensed communication network.

[0031] In some embodiments, the UE receives from the network controller a register accept message indicating the UE is permitted to access services of the network controller. The register accept message in some embodiments includes identification of the network controller. In some embodiments, the identification of the VANC includes an Internet Protocol (IP) address and/or a Fully Qualified Domain Name (FQDN) that translates to the IP address of the network controller. The UE detects a failure on the connection between the UE and the network controller with which the UE has been registered. The UE in some embodiments detects the connection failure by receiving a network reset message or a synchronization command message from the network controller. In some embodiments, the connection between the UE and the network controller is a TCP connection. Having detected the failure, the UE attempts to re-establish a connection to the network controller using the identification of the network controller in some embodiments.

[0032] Some embodiments of the present invention provide a method for UE registration for VoLGA services. The method sends a register request message from the UE to the VANC to register the UE with the VANC. The register request message includes location information that identifies an evolved packet system (EPS) cell upon which the UE has camped. The method receives a response message at the UE from the VANC. The response message indicates whether the UE is permitted to access services of the VANC. When it is determined that the UE is permitted to access the services of the VANC, the response message is a register accept message. The register accept message in some embodiments includes an identification of the VANC. In some embodiments, the identification of the VANC includes an Internet Protocol (IP) address and/or a Fully Qualified Domain Name (FQDN) that translates to the IP address of the VANC. The method in some embodiments stores the address of the VANC for future use.

[0033] Several more detailed embodiments of the invention are described in sections below. Section I provides a discussion of functional entities. The discussion in Section I is followed by a discussion of architecture models and reference points including non-roaming architectures in Section II. Section III discusses protocol architecture. Next, Section IV discusses procedures for VoLGA A-mode, including rove-in, rove -out. Section V describes several procedures for recovering from a signalling connection failure. Section VI discusses a computer system with which some embodiments of the invention are implemented. Finally, a list of definitions and a table of acronyms and abbreviations used in this application is included in Section VII.

I. Functional Entities

[0034] The following is a list of the required network elements and their necessary functionality for supporting VoLGA in some embodiments.

A. User Equipment (UE)

[0035] In some embodiments, the UE is a standard device operating over the licensed spectrum of a licensed wireless system provider per the procedures specified in the 3 GPP Long Term Evolution (LTE) standards (e.g., 3 GPP TS 23.401 : "GPRS enhancements for E- UTRAN access", incorporated herein by reference and hereinafter, TS 23.401) with the additional functionality described in this application.

B. eNodeB

[0036] In some embodiments, the eNodeB (also referred to as eNB or E-UTRAN

NodeB) is a standard part of the E-UTRAN, as specified in the 3GPP Long Term Evolution (LTE) standards (e.g., TS 36.300). Throughout this application eNodeB may be represented as an E-UTRAN cell (or sometimes just E-UTRAN) both in text and in the figures. C. VoLGA Access Network Controller (VANC)

[0037] The VANC is a network controller that provides network connectivity of the

UE to the existing circuit switched (CS) domain core network (CN). The VANC entity appears as a legacy base station controller (BSC) or radio network controller (RNC) to the existing CS domain CN. Specifically, the VANC uses the existing A interface (VoLGA A- mode) or Iu-cs interface (VoLGA Iu-mode) for CS domain CN connectivity. In this manner, the VoLGA system may be integrated into the existing CS domain CN with no change to the CS domain CN. This allows licensed wireless system providers the ability to provide VoLGA system functionality to their users with no change to their existing network.

[0038] As noted above, the VANC connects to the MME using the Z2 interface. In some embodiments, the VANC connects to the MME through the Sv interface as defined for SRVCC in 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC); Stage 2", incorporated herein by reference and hereinafter TS 23.216. Additional interfaces of the VANC include the Rx interface to the Policy and Charging Rules Function (PCRF), the SGi interface to the packet data network (PDN) gateway (P-GW), the Wm interface to the Authorization, Authentication, and Accounting (AAA) server, and an interface either the A or Iu-cs interface depending on which type of network connection is present, with the CS domain core network. It should be apparent to one of ordinary skill in the art that in some embodiments, other interfaces may be used instead of or in addition to the above enumerated interfaces.

[0039] In some embodiments, the VANC uses several different eNodeBs to communicate with UEs (e.g., the control plane and user plane traffic between a UE and the VANC flow through an eNode) and services each of the corresponding service regions of each of the several eNodeBs. In this manner, a single VANC can communicatively couple multiple eNodeB service regions to the CS domain CN. The VANC performs key functionalities, such as the management of the legacy UTRAN identifiers (Location Area Identifiers (LAI), Service Area Identifiers (SAI), RNC-Id, etc) towards the CS domain CN.

[0040] In some embodiments, the VANC includes various software module subcomponents and/or various hardware module sub-components that perform some of the above mentioned functionality. For example, the Security Gateway (SeGW) is a logical entity within the VANC. The SeGW provides the security functions including termination of secure access tunnels from the UE, mutual authentication, encryption and data integrity for signaling traffic. For another example, the Handover Selection Function (HOSF) is a logical entity within the VANC. The HOSF allows E-UTRAN to GERAN/UTRAN CS handover requests from the MME to be routed to the correct serving VANC.

[0041] The VANC of some embodiments includes circuits for receiving, transmitting, generating, and processing the various messages that cause various physical transformations within the VoLGA network, CS domain core network, and licensed wireless radio access network. In some embodiments, the circuits of the network controller include a processor, memory, receiver, and transceiver. These circuits perform various physical transformations on the network controller as well as other elements within the VoLGA network, licensed wireless radio access network, and CS domain core network. For example, the processor and the memory generate context identifiers that when sent to a UE using the transceiver provide the UE with a unique identifier when operating within the VoLGA network. These and other physical components of the network controller of some embodiments are described with further detail below.

[0042] In some embodiments, VANC functionality is modified from previous standards as follows. VANC Security Gateway functionality is limited to the VoLGA control plane with standard Wm interface to AAA Server for EAP-AKA authentication present. Some embodiments support VoLGA service functionality only. Some embodiments support the reception and processing of EPS-specific information (e.g., cell information) in GA-RC Register Request messages. Additionally, some embodiments support E-UTRAN to GERAN/UTRAN CS handover signaling procedures using the Z2 interface towards the MME. Some embodiments support voice bearer contra 1/establishment using the Rx interface towards the PCRF.

D. LTE Core Network

[0043] The Evolved Packet System (EPS) consists of the E-UTRAN (which includes a collection of E-NodeBs) and Evolved Packet Core (aka LTE core or System Architecture Evolution (SAE)). EPS is a pure packet system. For instance EPS does not have a voice media gateway. Services, like voice and SMS, are expected to be provided by application functions that make use of the EPS service. The relevant portions of the LTE core network required for VoLGA services are described below. 1. Mobility Management Entity (MME)

[0044] The MME functions as the key control-node for the LTE core network. It handles tracking and paging procedures for idle mode UE (User Equipment) including retransmissions. It also handles the bearer activation/deactivation process and chooses the serving gateway for a UE at the intra-LTE handover involving LTE Core Network node relocation and during the initial attach. It authenticates the user (interacting with the home subscriber server (HSS)). LTE Non-Access Stratum (NAS) signaling terminates at the MME and it generates and allocates temporary identities to UEs. The MME checks the authorization of the UE to use a service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the end point for ciphering/integrity protection for LTE NAS signaling and handles security key management. The MME supports lawful interception of signaling and provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface from the SGSN and terminating at the MME.

[0045] In some embodiments, the MME has certain 3 GPP Release 8 standard functionality plus additional behaviors. Some embodiments require some or all of the present standard functionality, including: performing the PS bearer splitting function by separating the voice PS bearer from the non- voice PS bearers (i.e., as specified in TS 23.216); handling the non-voice PS bearer handover with the target cell according to the Inter RAT handover procedure defined in TS 23.401; coordinating PS handover and CS handover procedures when both procedures are performed; and receiving "Handover VoIP bearer to CS" indication from eNodeB in S1AP Handover Required message. In some embodiments, information flow is merged with the SRVCC flow (i.e., the eNodeB provides a generic indication that the VoIP bearer should be handed over to CS).

[0046] In some embodiments, some or all of the required additional functionality to

3GPP Release 8 standard behaviors includes: receiving VoLGA information from HSS (e.g., VoLGA authorization in visited public land mobile network (VPLMN)); sending VoLGA information to eNodeB, e.g., VoLGA indication during bearer establishment (in some embodiments, this indication is not merged with the SRVCC information flow, i.e. a generic indication to eNodeB is that the VoIP bearer is subject to handover to CS, since the eNodeB would initiate PS handover of the voice bearer in the SRVCC case if the target radio access technology (RAT) supported VoIP over PS); supporting new E-UTRAN to GERAN/UTRAN CS handover signaling procedures using the S3-cs interface towards the VANC; receiving the VoLGA capability indication as part of the UE network capability in the Attach Request message (MME stores this information for VoLGA operation); initiating the VoLGA handover procedure for handover of the voice component to the target cell; and selecting the target VANC for VoLGA handover.

2. Serving Gateway (S-GW)

[0047] The Serving Gateway (S-GW) routes and forwards user data packets and acts as the mobility anchor for the user plane during inter-eNodeB handovers and between LTE and other 3GPP technologies. The S-GW terminates the DL data path and triggers paging when DL data arrives for the UE for UEs in idle state. It stores and manages UE contexts, such as parameters of the IP bearer service and network internal routing information. The S- GW performs replication of the user traffic for lawful interception. The S-GW and P-GW functions are shown as a single element in many of the diagrams in this application.

3. Packet Data Network (PDN) Gateway (P-GW)

[0048] The Packet Data Network Gateway (P-GW) provides connectivity to the UE to external packet data networks and performs policy enforcement, packet filtering for each user, charging support, lawful interception and packet screening. In some embodiments, a UE may access multiple P-GWs at single time to access different PDNs.

E. CS Domain Core Network (CN)

[0049] A person of ordinary skill in the art would realize that there are two instances of core network. One is the LTE CN that includes the MME, S-GW, P-GW, HSS, etc. (which are further described above). The other is the CS domain CN which the UE accesses via the VANC. The VANC provides network connectivity of the UE to the existing circuit switched (CS) domain CN. In some embodiments, the CS domain CN includes one or more home location registers (HLRs) and AAA servers for subscriber authentication and authorization. Once authorized, the UE may access the CS domain services of the CS domain CN through the VoLGA system. To provide such services, the CS domain CN includes a Mobile Switching Center (MSC) to provide circuit switched services (i.e., voice).

[0050] Location services are provided by the serving mobile location center (SMLC).

The cell broadcast center (CBC) provides support for cell broadcast services.

[0051] In some embodiments, the network includes full serving MSC (and VLR) functionality required for CS services per existing standards. It should be noted that throughout this application CS domain core network is often used interchangeably with MSC/VLR terminology.

F. Other Components

[0052] Described below are some of the other main components and their functionality present in some embodiments of the VoLGA architecture. The Home Location Register (HLR) is a central database that contains details of each mobile phone that is authorized to access the CS domain core network through a particular network controller. The Policy and Charging Rules Function (PCRF) is the node designated in real-time for the determination of the policy rules, i.e. verifying access permission, checking and debiting credit balances, etc., all in real-time. The Base Station Controller (BSC) is a traditional part of the GERAN and handles allocation of radio channels, receives measurements from the mobile phones, and controls inter-BTS (Base Transceiver Station) handovers. The BSC additionally provides transcoding services. The Radio Network Controller (RNC) is a governing element in the UTRAN and controls the NodeBs connected to it. Among its functions are radio resource management, some mobility management, and encryption. The AAA Server is responsible for managing authentication, authorization, and accounting services.

II. Architecture Models and Reference Points

A. Non-Roaming Architectures

[0053] In some embodiments, the mobile system operator reuses the existing CS domain entities (e.g., MSC/VLR) that control establishment of CS services under E-UTRAN coverage. This architecture applies when the user attempts to access the CS domain core network through a Home Public Land Mobile Network (HPLMN) that supports VoLGA. The VANC enables the UE to access the MSC/VLR using the generic IP connectivity provided by the EPS. In some embodiments, the VANC is connected to the MSC/VLR using either the A- interface ("VoLGA A-mode") or the Iu-cs interface ("VoLGA Iu-mode"). From the EPS point of view, the VANC is viewed, in some embodiments, as an Application Function and the "Zl" interface between the UE and the VANC is based on the Up interface defined in TS 43.318. In some embodiments, several UEs are connected to a single access point (i.e. eNodeB) or to several access points.

[0054] Figure 1 conceptually illustrates a non-roaming architecture for VoLGA using

A-Mode interface in some embodiments. This figure includes: the UE 130; the E-UTRAN 135; the MME 140; S-GW/P-GW 145; PCRF 150; the VANC 105; MSC/VLR 110; A interface 115; AAA server 120; and HLR 125. As shown, the VANC 105 is connected to the MSC/VLR 110 using the A-interface 115 ("VoLGA A-mode"). The UE 130 accesses the VANC 105 through E-UTRAN 135 and S-GW/P-GW 145 (the link, Zl, between the UE and VANC is conceptually shown as a direct line in Figure 1 for simplicity). The VANC appears as an Application Function to the PCRF 150. In some embodiments, AAA server 120 is optional and in some embodiments the HLR 125 can be replaced with a Home Subscriber Server (HSS) (not shown). Figure 2 illustrates a non-roaming architecture for VoLGA using Iu-Mode interface in some embodiments. This figure includes: the UE 230; the E-UTRAN 235; the MME 240; S-GW/P-GW 245; PCRF 250; the VANC 205; MSC/VLR 210; Iu-cs interface 215; AAA server 220; and HLR 225. Here, the VANC 205 is connected to the MSC/VLR 210 using the Iu-cs interface 215 ("VoLGA Iu-mode"). The UE 230 accesses the VANC 205 through E-UTRAN 235, MME 240, and S-GW/P-GW 245. The VANC appears as an Application Function to the PCRF 250. In some embodiments, AAA server 220 is optional and in some embodiments the HLR 225 can be replaced with a Home Subscriber Server (HSS) (not shown).

B. Reference Points

[0055] This section describes the different interfaces present in his application. The reference point between the UE and the VANC is labelled Zl . The reference point between the MME and the VANC is labelled Z2. In some embodiments, the Z2 reference point may be the same as the Sv reference point specified in TS 23.216. See "VoLGA Access Network Controller (VANC)" Section, above, for more information about interfaces.

III. Protocol Architecture

[0056] There are two separate protocol architectures for the VoLGA system: control plane architecture and user plane architecture. Each figure representing the architecture consists of layers of protocol designed to relay specific types of information. The top layers are encapsulated in the lower layers. Control plane architecture covers the functionality related to all aspects of network signaling and control, such as call and connection control. User plane architecture deals with functionality associated with issues of user-to-user information transfer and associated controls.

[0057] The protocol architecture for the VoLGA control plane (VoLGA A-mode) in some embodiments is illustrated in Figure 3 (assuming the VANC and MSC/VLR are connected using the A-interface). As shown, communication between the UE 305 and the VANC 310 uses the GA-RC/GA-CSR protocol layer 315, the TCP layer 320, and the IPSec layer 325. In some embodiments, the TCP layer 320 is used along with the internet protocol to send data in the form of message units between two points over the internet. TCP will break up data into smaller packets at one end point, transmit the packets, and resequence the packets when they arrive at the other end point. Here, it keeps track of individual units of data (packets) that a message is divided into for routing. The IPSec layer 325 establishes a secure communication path with the network controller to encrypt and provide data integrity for messages exchanged between the particular UE and the network controller.

[0058] The protocol architecture for the VoLGA control plane (VoLGA Iu-mode) in some embodiments is illustrated in Figure 4 (assuming the VANC and MSC/VLR are connected using the Iu-interface).

IV. Procedures for VoLGA A-Mode

A. Rove-In

[0059] Before a UE may access VoLGA services, it must "Rove -in" to a network that supports VoLGA functionality, which usually requires the UE to be within a certain physical proximity to the necessary equipment. "Rove-in" is the process in which the UE switches the serving RR entity for CS domain services to GA-CSR (VoLGA A-mode) or GA-RRC (VoLGA Iu-mode). When preparing to rove-in, the UE performs (1) VANC discovery, and (2) VoLGA registration.

1. VANC Discovery

[0060] VANC discovery is required when a UE attaches to EPS and desires access to

VoLGA service. The VANC discovery process consists of two parts: selection of the Packet Data Network (PDN) that the UE uses for VoLGA service (i.e. default PDN or VoLGA- specific PDN) and VANC discovery within the selected PDN.

[0061] The selection of the PDN that the UE uses for VoLGA service is based on the

UE configuration. For roaming support, the UE is provisioned with a dedicated service APN for VoLGA service (e.g., APN-VOLGA-FOO). For VoLGA service in the HPLMN, the UE may be provisioned with a dedicated service APN in some embodiments or with an indication that the default PDN be used in other embodiments. In some embodiments, the dedicated service APN for VoLGA service does not have to be consistent among operators. However, in some embodiments, each VPLMN must support translations that result in local breakout (i.e., selection of a PDN GW in the VPLMN) for its roaming partners' dedicated service APNs for VoLGA service.

[0062] In some embodiments, VANC discovery is performed after IP connectivity in the selected PDN has been established using one of the following mechanisms:

[0063] (1) in some embodiments, the UE is configured (e.g. during initial provisioning) with the fully qualified domain name (FQDN) of a VANC or its IP address. In some embodiments, if the VANC FQDN is configured, DNS is used to obtain the IP address;

[0064] (2) in some embodiments, the UE uses dynamic host configuration protocol

(DHCP) to obtain the FQDN (or IP address) of a VANC and the address of a Domain Name System (DNS) server that is capable of resolving the VANC FQDN (if VANC IP address is not provided via DHCP), as described in "VANC Discovery in HPLMN using DHCP" Section, below;

[0065] (3) in some embodiments, the UE uses DNS to obtain the VANC IP address using the procedure described in "VANC Discovery in HPLMN using DNS" Section, below;

[0066] (4) in some embodiments, the UE uses DHCP to obtain the FQDN (or IP address) of a VANC and use a DNS server that is capable of resolving the FQDN (if VANC IP address is not provided via DHCP) by using round-robin DNS over all available VANC IP addresses, as described in "VANC Discovery using DNS that uses round-robin DNS over all available VANCs" Section, below; and

[0067] (5) in some embodiments, the UE uses DHCP to obtain the FQDN (or IP address) of a VANC and use a DNS server that is capable of resolving the FQDN (if VANC IP address is not provided via DHCP) by using round-robin DNS over VANC IP addresses of geographically appropriate VANCs, as described in "VANC Discovery using DNS that uses round-robin DNS over geographically appropriate VANCs" Section, below.

[0068] In some embodiments, the DNS-based procedure is dependent on an identifier that is agreed to be used by all VoLGA operators, i.e. a unique VoLGA service name for automatic VANC discovery (e.g., "vanc-discovery"). a. VANC Discovery in HPLMN

i. VANC Discovery in HPLMN using DHCP

[0069] Figure 5 illustrates VANC service discovery in HPLMN using DHCP in some embodiments. The figure includes: UE 505; EPS 510; Default or VoLGA-specific PDN 515, which is comprised of DHCP 520; DNS server 525; and VANC 530.

[0070] As shown, the UE 505 attaches (in step 1) to EPS 510 and gains default PDN connectivity. In some embodiments, the attach procedure is as defined in TS 23.401, with the following Single-Radio Voice Call Continuity (SRVCC) functionality additions as described in TS 23.216: the UE includes the SRVCC capability indication as part of the UE Network Capability in the Attach Request message. In some embodiments, the MME stores this information for SRVCC operation (if authorized, see below). If the subscriber is authorized to use the EPS SRVCC capabilities then, in some embodiments, the HSS includes the session transfer number for SRVCC (STN-SR) and the mobile subscriber integrated services digital network (ISDN) (MSISDN) in the Insert Subscriber Data message to the MME. In some embodiments, the MME includes a "SRVCC operation possible" indication in the S1AP Initial Context Setup Request, meaning that both UE and MME are SRVCC-capable and SRVCC service is authorized.

[0071] If provisioned with a dedicated service APN for VoLGA service in the

HPLMN (e.g., APN-VOLGA-FOO), the UE 505 requests (in step 2) connectivity to the dedicated VoLGA PDN 515. In some embodiments, the HSS provides the MME with the dedicated service APN used for VoLGA service in the subscriber profile, allowing the MME to authorize access to the PDN. The UE 505 uses DHCP 520 to obtain (in steps 3 and 4) the FQDN (or IP address) of a VANC 530 and the address of a DNS server 525 that is capable of resolving the VANC FQDN (if VANC IP address is not provided via DHCP).

[0072] In some embodiments, if a VANC FQDN is returned in step 4, the UE 505 uses (in step 5) the DNS server 525 to resolve the VANC FQDN. In step 6, if DNS resolution is successful, then, in some embodiments, the UE 505 is ready to attempt registration on the selected VANC 530; if DNS resolution is unsuccessful, then the UE 505 concludes in some embodiments, that the HPLMN does not offer VoLGA service. ii. VANC Discovery in HPLMN Using DNS

[0073] Figure 6 illustrates VANC service discovery in HPLMN using DNS in some embodiments. This figure includes: UE 605, EPS 610, and Default or VoLGA-specific PDN 615, which is comprised of DNS server 620 and VANC 625.

[0074] Here, the UE 605 attaches (in step 1) to EPS 610 and gains default PDN connectivity. If provisioned with a dedicated service APN for VoLGA service in the HPLMN (e.g., APN-VOLGA-FOO), the UE 605 requests (in step 2) connectivity to the dedicated VoLGA PDN 615. (See "VANC Discovery in HPLMN Using DHCP" Section, above for additional information concerning steps 1 and 2; the steps are the same in both processes).

[0075] The UE 605 obtains (in step 3) the domain name that the UE 605 uses to resolve hostnames via DNS server 620 in the selected PDN 615 (e.g., "home-operator- pdn.com").

[0076] The UE 605 uses (in step 4) DNS server 620 to resolve the fully qualified domain name consisting of the unique VoLGA service name concatenated with the domain name (e.g., "vanc-discovery.home-operator-pdn.com"). In step 5, if DNS resolution is successful, then the UE 605 is ready to attempt registration on the selected VANC 625; if DNS resolution is unsuccessful, then the UE 605 concludes that the HPLMN does not offer VoLGA service.

b. VANC Discovery using DNS that uses round-robin DNS

[0077] In some embodiments, DNS servers use round-robin DNS to distribute traffic among the Security Gateways (SeGWs) and VANCs that can provide services to UEs. As it is well known in the art, a DNS server that uses round-robin DNS responds to DNS requests with a single IP address or a list of IP addresses of several servers that host identical services (e.g., VoLGA services, etc.). When a DNS server using round-robin DNS returns a list of IP addresses in response to each DNS query, a client which sent the DNS query usually attempts to connect to a first server specified by the first address in the list. With each DNS response, the IP address sequence in the list is permuted. As such, another client that receives another DNS response from the DNS server would connect to a second server that is different than the first server. Thus, using round-robin DNS, the DNS distributes the overall load among the servers hosting identical services.

[0078] Figure 7 illustrates an example architecture used in some embodiments. This figure includes SeGW pool 740 and VANC pools 1-4. The SeGW pool 740 includes SeGW- 1, SeGW-2, SeGW-3, and SeGW-4. Each of the four VANC pool includes two VANCs (e.g., VANC pool 1 includes VANC-1A and VANC-1B). The VANCs in a VANC pool together serve a geographical area in some embodiments. It is to be noted that the specific names used for the SeGWs and VANCs and the number of SeGWs and VANCs in each pool are examples and not a requirement to implement embodiments of the invention. The SeGWs and VANCs illustrated in this figure are further discussed below.

i. VANC Discovery using DNS that uses round-robin DNS over all available VANCs

[0079] Figure 8 illustrates an example VANC service discovery in HPLMN or

VPLMN using DHCP and DNS that uses round-robin DNS over all available VANCs in some embodiments. The figure includes: UE 705; EPS 805; Default or VoLGA-specific PDN, which is comprised of DHCP 710; DNS-t server 715; SeGW-1 720; DNS-r server 725; VANC-1A 730; and VANC -2 A 735.

[0080] As shown, the UE 705 attaches (in step 1) to EPS 805 and gains default PDN connectivity. In some embodiments, the attach procedure is as defined in TS 23.401, with the following SRVCC additions as described in TS 23.216: the UE includes the SRVCC capability indication as part of the UE Network Capability in the Attach Request message. In some embodiments, the MME stores this information for SRVCC operation (if authorized, see below). If the subscriber is authorized to use the EPS SRVCC capabilities then, in some embodiments, the HSS includes the session transfer number for SRVCC (STN-SR) and the mobile subscriber integrated services digital network (ISDN) (MSISDN) in the Insert Subscriber Data message to the MME. In some embodiments, the MME includes a "SRVCC operation possible" indication in the S1AP Initial Context Setup Request, meaning that both UE and MME are SRVCC-capable and SRVCC service is authorized.

[0081] The UE 705 requests (in step 2) connectivity to the dedicated VoLGA PDN

1515. In some embodiments, the HSS provides the MME with the dedicated service APN used for VoLGA service in the subscriber profile, allowing the MME to authorize access to the PDN. The UE 705 sends (in step 3) a DHCP query to DHCP 710 to obtain the FQDNs (or IP addresses) of a SeGW and a VANC. In response, the DHCP 710 in this example provides (in step 4) the FQDN of the SeGW pool 740, the FQDN of all VANCs in all VANC pools (i.e., VANC pools 1-4 illustrated in Figure 7), and the address of a transport DNS server (a.k.a. an "outer" DNS server) (DNS-t 715) to the UE 705. Because the UE 705 receives an FQDN instead of an IP address of a SeGW, the UE 705 sends (in step 5) a DNS query with the FQDN of the SeGW pool 740 to the DNS-t server 715 to obtain the IP address of a SeGW. Upon receiving the DNS query, the DNS-t server 715 resolves the FQDN of the SeGW pool to the IP addresses of the SeGWs in the SeGW pool 740 by using round-robin DNS. The DNS-t server 715 responds (in step 6) to the UE 715 with a list of the IP addresses of the SeGWs in the pool 740 with the IP address of the SeGW-1 as the first address in the list. As illustrated in Figure 7, the SeGW pool 740 includes SeGW-1, SeGW-2, SeGW-3, and SeGW-4.

[0082] The UE 705 selects the IP address of SeGW-1 in this example because it is the first address in the list received from the DNS-t 715. The UE 705 establishes (in step 7) a secure connection to the SeGW-1 720 and the SeGW-1 in return assigns a remote DNS server (a.k.a. an "inner" DNS server) (e.g., DNS-r 725) to the UE 705. To get an IP address of a VANC, the UE sends (in step 8) to the DNS-r server 725 a DNS query with the FQDN of the VANCs received (in step 4) from the DHCP 710. Using round-robin DNS, the DNS-r server 725 in some embodiments resolves the FQDN of the VANCs to the IP addresses of the VANCs 1A-8B regardless of which of the VANC pools that each VANC belongs to. As such, the DNS-r server distributes UEs among all the VANCs in all the VANC pools. As illustrated in Figure B, there are four VANC pools and the pools include eight VANCs in total. The DNS-r server 725 responds (in step 9) with a list of the eight IP addresses of the eight VANCs with the IP address of the VANC-IA 730 as the first address in the list.

[0083] The UE 705 selects the IP address of the VANC-IA 730 in this example because it is the first address in the list received from the DNS-r 725. The UE 705 then (in step 10) sets up a TCP connection to the VANC-IA and attempts to register with the VANC- IA 730. Upon receiving the registration attempt, the VANC-IA in some embodiments determines (in step 11) whether the UE 705 should be served in the service area of the VANC pool 1 which the VANC-IA belongs to as illustrated in Figure B or in another service area of another VANC pool (e.g., VANC pool 2). As mentioned above, the VANCs in a VANC pool serves a geographical area in some embodiments. The VANC-IA of different embodiments bases such determination differently. For example, the VANC-IA in some embodiments bases its determination on the location information provided by the UE 705. The location information in some embodiments include the UE's current location and/or the UE's IP address. The UE provides the location information to the VANC-IA when the UE establishes the TCP connection to the VANC-IA and/or when the UE attempts to register with the VANC-IA. If the VANC-IA determines (in step 11) that the UE 705 should be served in the service area of the VANC pool 1, the VANC-IA accepts (in step 12a) the registration.

[0084] If the VANC-IA determines (in step 11) that the UE 705 should be served in the service area of another VANC pool (e.g., VANC pool 2), the VANC-IA redirects (in step 12b) the UE to the VANC pool 2. In some embodiments, the VANC-IA redirects the UE to the VANC pool 2 by sending a GA-RC REDIRECT REQUEST message with the FQDN of the VANC pool 2, VANC-2-FQDN. The VANC-IA in some embodiments allows the UE to reuse the secure connection that the UE 705 established (in step 7) with the SeGW-1 if the VANC-IA determines that the SeGW-1 is appropriate for the LTE service area in which the UE is currently located. The VANC-IA makes that determination in some embodiments based on topology information, which describes the relationship between the SeGW service areas and the LTE service areas (for instance, the VANC needs to know that the current SeGW is appropriate given the LTE cell in which the UE is currently located). The VANC- IA allows the UE to reuse the secure connection by not including any SeGW address information in the GA-RC REDIRECT REQUEST message in some embodiments.

[0085] Figure 9 continues to illustrate the example VANC service discovery illustrated in Figure 8. The steps illustrated in this figure are performed only when the UE 705 is redirected (in step 12b) to the VANC pool 2. When redirected (in step 12b) to the VANC pool 2 by the VANC-IA by receiving the GA-RC REDIRECT REQUEST without any SeGW address information, the UE 705 in some embodiments reuses the secure connection it established (in step 7) with the SeGW-1. The UE 705 then sends (in step 13) to the DNS-r server 725 a DNS query with VANC-2-FQDN received (in step 12b) from the VANC-IA. Using round-robin DNS over the VANCs in the VANC pool 2, the DNS-r server 725 in some embodiments resolves the FQDN of the VANC pool 2 to the IP addresses of the VANC -2 A and VANC-2B which belong to the VANC pool 2 as illustrated in Figure B. The DNS-r server 725 responds (in step 14) to the DNS query with a list of the two IP addresses of the VANCs in the VANC pool 2 with the IP address of the VANC -2 A 735 as the first address in the list.

[0086] The UE 705 selects the IP address of the VANC -2 A 735 in this example because it is the first address in the list received from the DNS-r 725. The UE 705 then (in step 15) sets up a TCP connection to the VANC-2A and attempts to register with the VANC- 2A 735. Upon receiving the registration attempt, the VANC-2A determines (in step 16) that the UE 705 should be served in the service area of the VANC pool 2 based on the location information provided by the UE 705 in some embodiments.

[0087] By distributing UEs among all the VANCs in all the VANC pools as discussed above in this example, there may be frequent redirections for the UEs to get to a geographically appropriate VANC or a geographically appropriate VANC pool. A geographically appropriate VANC or VANC pool is the VANC or the VANC pool that serves the geographical area where the UEs are currently located.

[0088] Frequent redirections may result in delays in the connection process. The delays can be addressed by assigning a UE to a geographically appropriate VANC or VANC pool during VANC discovery in some embodiments. For instance, in the example illustrated in Figures 8 and 9, the DHCP 710 can provide (in step 4) the FQDN of the VANC pool 2 which is a geographically appropriate VANC pool. To enable the DHCP 710 to provide the FQDN of a geographically appropriate VANC pool or a geographically appropriate VANC to the UE, some embodiments provide two conditions: (1) a P-GW (not shown) divides the geographical area that the P-GW is covering into IP subnets and then assigns the UE to a subet based on the UE's current location and (2) the DHCP server is configured to provide different server address information based on the UE's IP address in some embodiments. The first condition requires P-GW support. The second condition is typical DHCP server functionality as known in the art. An example VANC discovery avoiding frequent redirections will now be discussed.

ii. VANC Discovery using DNS that uses round-robin DNS over geographically appropriate VANCs

[0089] Figure 10 illustrates an example VANC service discovery in HPLMN or

VPLMN using DHCP and DNS that uses round-robin DNS over geographically appropriate VANCs in some embodiments. The figure includes: UE 705; EPS 805; Default or VoLGA- specific PDN, which is comprised of DHCP 710; DNS-t server 715; SeGW-1 720; DNS-r server 725; VANC-1A 730; and VANC -2 A 735.

[0090] As shown, the UE 705 attaches (in step 1) to EPS 805 and gains default PDN connectivity. If provisioned with a dedicated service APN for VoLGA service in the VPLMN (e.g., APN-VOLGA-FOO), the UE 705 requests (in step 2) connectivity to the dedicated VoLGA PDN IOI5. (See "VANC Discovery using DNS that uses round-robin DNS over all available VANCs" Section, above, steps 1 and 2 for additional information concerning steps 1 and 2 here; the steps are the same in both processes).

[0091] The UE 705 sends (in step 3) a DHCP query to DHCP 710 to obtain the

FQDNs (or IP addresses) of a SeGW and a VANC. In response, the DHCP 710 in this example provides (in step 4) the FQDN of the SeGW pool 740, the FQDN of the VANC pool 2, and the address of a transport DNS server (e.g., DNS-t 715) to the UE 705. The VANC pool 2 in this example is geographically appropriate to the UE 705, i.e., the VANC-2A and the VANC-2B of the VANC pool 2 serves the geographical area where the UE is currently located.

[0092] Because the UE 705 receives an FQDN instead of an IP address of a SeGW, the UE 705 sends (in step 5) DNS query with the FQDN of the SeGW pool 740 to the DNS-t server 715 to obtain the IP address of a SeGW. Upon receiving the DNS query, the DNS-t server 715 resolves the FQDN of the SeGW pool to the IP addresses of the SeGWs in the SeGW pool 740 by using round-robin DNS. The DNS-t server 715 responds (in step 6) to the UE 715 with a list of the IP addresses of the SeGWs in the pool 740 with the IP address of the SeGW-1 as the first address in the list. As illustrated in Figure 7, the SeGW pool 740 includes SeGW-1, SeGW-2, SeGW-3, and SeGW-4.

[0093] The UE 705 selects the IP address of SeGW-1 in this example because it is the first address in the list received from the DNS-t 715. The UE 705 establishes (in step 7) a secure connection to the SeGW-1 720 and the SeGW-1 in return assigns a remote DNS server (e.g., DNS-r 725) to the UE 705. To obtain an IP address of a VANC of the VANC pool 2, the UE sends (in step 8) to the DNS-r server 725 a DNS query with the FQDN of the VANC pool 2 received (in step 4) from the DHCP 710. Using round-robin DNS over the VANCs in the VANC pool 2, the DNS-r server 725 in some embodiments resolves the FQDN of the VANC pool 2 to the IP addresses of the VANC -2 A and VANC-2B. The DNS-r server 725 in this example responds (in step 9) to the DNS query with a list of the two IP addresses of the VANCs in the VANC pool 2 with the IP address of the VANC-2A 735 as the first address in the list.

[0094] The UE 705 selects the IP address of the VANC -2 A 735 in this example because it is the first address in the list received from the DNS-r 725. The UE 705 then (in step 10) sets up a TCP connection to the VANC-2A and attempts to register with the VANC- 2 A 735. Upon receiving the registration attempt, the VANC-2A in some embodiments determines (in step 11) whether the UE 705 should be served in the service area of the VANC pool 2 to which the VANC-2A belongs as illustrated in Figure B or in another service area of another VANC pool (e.g., VANC pool 1). The VANC-2A of different embodiments bases such determination differently. For example, the VANC-2A in some embodiments bases its determination on the location information provided by the UE 705. The location information in some embodiments include the UE's current location and/or the UE's IP address. The UE provides the location information to the VANC-2A when the UE establishes the TCP connection to the VANC-2A and/or when the UE attempts to register with the VANC-2A. If the VANC -2 A determines (in step 11) that the UE 705 should be served in the service area of the VANC pool 2, the VANC-2A accepts (in step 12a) the registration. This should be the usual case in this example because the VANC pool 2, to which the VANC-2A belongs, is a geographically appropriate VANC pool as discussed above.

[0095] If the VANC -2 A determines (in step 11) that the UE 705 should be served in the service area of another VANC pool (e.g., VANC pool 1), the VANC-2A redirects (in step 12b) the UE to the VANC pool 1. In some embodiments, the VANC-2A redirects the UE to the VANC pool 1 by sending a GA-RC REDIRECT REQUEST message with the FQDN of the VANC pool 1, VANC- 1 -FQDN. The VANC -2 A in some embodiments allows the UE to reuse the secure connection that the UE 705 established (in step 7) with the SeGW-1 if the VANC-2A determines that the SeGW-1 is appropriate for the service area of the LTE in which the UE is currently located. The VANC-2A makes that determination in some embodiments based on topology information, which describes the relationship between the SeGW service areas and the LTE service areas (for instance, the VANC needs to know that the current SeGW is appropriate given the LTE cell in which the UE is currently located). The VANC-2A allows the UE to reuse the secure connection by not including any SeGW address information in the GA-RC REDIRECT REQUEST message in some embodiments.

[0096] Figure 11 continues to illustrate the example VANC service discovery illustrated in Figure 10. The steps illustrated in this figure are performed only when the UE 705 is redirected (in step 12b) to the VANC pool 1. When redirected (in step 12b) to the VANC pool 1 by the VANC -2 A by receiving the GA-RC REDIRECT REQUEST without any SeGW address information, the UE 705 in some embodiments reuses the secure connection it established (in step 7) with the SeGW-1. The UE 705 then sends (in step 13) to the DNS-r server 725 a DNS query with VANC- 1 -FQDN received (in step 12b) from the VANC-2A. Using round-robin DNS over the VANCs in the VANC pool 1, the DNS-r server 725 in some embodiments resolves with the FQDN of the VANC pool 1 to the IP addresses of the VANC-1A and VANC-1B which belong to the VANC pool 1 as illustrated in Figure B. The DNS-r server 725 responds (in step 14) to the DNS query with a list of the two IP addresses of the VANCs in the VANC pool 1 with the IP address of the VANC- 1 A 730 as the first address in the list.

[0097] The UE 705 selects the IP address of the VANC-1A 730 in this example because it is the first address in the list received from the DNS-r 725. The UE 705 then (in step 15) sets up a TCP connection to the VANC-1A and attempts to register with the VANC- 1A 730. Upon receiving the registration attempt, the VANC-1A determines (in step 11) that the UE 705 should be served in the service area of the VANC pool 1 based on the location information provided by the UE 705 in some embodiments.

2. VoLGA Registration

[0098] If the UE has successfully completed the VANC discovery procedure (i.e., has the address of a VANC), the UE may attempt VoLGA registration to be assigned a Serving VANC. The VANC may accept or reject the registration or redirect the UE to another VANC (e.g., depending on the UE's location or roaming condition). Figure 12 illustrates VoLGA registration in some embodiments. Prior to registering to VoLGA, however, the UE has to register with EPS, i.e., perform the attach procedure or the tracking area update, which informs the MME that the UE is available for receiving EPS services that require registration. These procedures are described in TS 23.401. The VoLGA registration shown in Figure 12 is, therefore, performed after the UE registration with EPS.

[0099] Here, the UE 1205 establishes (in step 1) a secure tunnel (i.e., in some embodiments using IKEv2 and IPSec ESP as specified in TS 43.318) (optional) and TCP connection to a pre-defined port on the assigned VANC 1210. Although the connection is shown as a TCP connection in Figure 12, other reliable transport connections (such as SCTP) can be used interchangeably throughout this Specification wherever the use of a TCP connection is disclosed. The UE 1205 registers (in step 2) with the VANC 1210, using the GA-RC REGISTER REQUEST message. In some embodiments, the message contains: EPS Cell information (i.e. the current camping EPS cell ID); UE IMSI; UE GUTI; and GAN Classmark, including indication of support for VoLGA service. [00100] If the VANC 1210 accepts the registration attempt it may, in some embodiments, initiate (in step 3a) the activation of a dedicated EPS bearer for the VoLGA signaling channel (QCI=5) using the Rx interface to the PCRF, per the procedures in TS 23.401 and 3GPP TS 23.203: "Policy and charging control architecture", incorporated herein by reference and hereinafter, TS 23.203. In some embodiments, the activation of the dedicated EPS bearer allows the PCRF to verify the binding between the received UE IMSI and IP address, since these parameters are provided by the VANC 1210 to the PCRF in the Access Attempt (AA)-Request message per 3GPP TS 29.214, "Policy and Charging Control over Rx Reference Point", incorporated herein by reference and hereinafter, TS 29.214. The VANC 1210 then responds (in step 3b) with a register accept message indicating acceptance of the registration. In some embodiments, the register accept message is a GA-RC REGISTER ACCEPT message.

[00101] In some embodiments, the message includes VoLGA specific system information, including one or more of the folio wings: (1) GAN Mode Indicator (A/Gb mode or Iu mode, i.e., VoLGA A-mode or Iu-mode, respectively) ; (2) location-area identification (LAI) comprising the mobile country code, mobile network code, and location area code corresponding to the VoLGA cell; (3) the GERAN (A-mode) or UTRAN (Iu-mode) cell identity identifying the cell within the location area corresponding to the VoLGA cell; (4) one or more applicable VoLGA system timer values; and (5) a list (i.e., containing one or more entries) of the E-UTRAN tracking areas (TAs) that are served by the VANC 1210. The UE stores the list of the E-UTRAN TAs that are served by the VANC. In some embodiments, the UE 1205 is required to notify the VANC 1210 when the UE 1205 moves to a new serving E-UTRAN TA that is not in the list.

[00102] In addition, the message in some embodiments includes identification of the

VANC 1210 which uniquely identifies the VANC 1210. In some embodiments, the identification includes an IP address of the VANC 1210. In other embodiments, the identification includes a FQDN which always translates to an IP address of the VANC 1210. The identification of different embodiments includes both the IP address and the FQDN.

[00103] The UE in some embodiments extracts the identification from the register accept message and stores (in step 4) the identification for future use. For example, as will be described below, the UE uses the identification included in the register accept message of some embodiments when there is a need to re-synchronize with the VANC, e.g., when the TCP connection between the UE and VANC drops. In some embodiments, the UE stores the identification in the storage of the UE (e.g., volatile storage such as RAM or non- volatile storage such as a hard disk or a solid-state drive).

[00104] The secure tunnel (optional) and TCP connection are not released and are maintained as long as the UE 1205 is registered to this VANC 1210. If the VoLGA LAI is not the same as the stored GERAN/UTRAN LAI, the UE 1205 performs, in some embodiments, the CS domain location area update procedure via the VoLGA control plane.

[00105] Alternatively, the VANC 1210 may reject (in step 5) the request. In this case, it responds with a GA-RC REGISTER REJECT message indicating the reject cause. In some embodiments, the secure tunnel (optional) and TCP connection are released; the UE 1205 may attempt re-discovery and re-registration under certain circumstances.

[00106] If the VANC 1210 wishes to redirect the UE 1205 to (another) VANC (not shown), it responds (in step 6) with a GA-RC REGISTER REDIRECT message providing the FQDN or IP address of the target VANC. In this case the secure tunnel (optional) and TCP connection are released and the UE 1205 attempts registration on the new VANC.

3. VoLGA Mode Selection

[00107] The UE transfers its VoLGA mode support to the VANC during registration procedure; in some embodiments, in the GAN Classmark IE. VoLGA mode support options are VoLGA A-mode supported, VoLGA Iu-mode supported, or both modes supported. In some embodiments, the VANC uses the received VoLGA mode support information to redirect the UE to a different VANC or a different TCP port on the current VANC. In some embodiments, the VANC also indicates the VoLGA mode to use for the current session. The following table enumerates the VoLGA mode selection procedures for the various combinations of UE and VANC VoLGA mode capabilities:

Table 1 : VoLGA Mode Selection Procedures Associated with VoLGA Registration

procedures procedures capable VANC.

UE: Proceed per

VoLGA A-mode procedures

Iu-mode only VANC: Reject VANC: Accept and VANC: Accept and

registration indicate VoLGA Iu- indicate VoLGA Iu- mode mode

UE: Handle per

registration reject UE: Proceed per UE: Proceed per procedures VoLGA Iu-mode VoLGA Iu-mode

procedures procedures

Both modes VANC: Accept and VANC: Accept and VANC: Accept and

indicate VoLGA A- indicate VoLGA Iu- indicate VoLGA Iu- mode mode mode or VoLGA A- mode*. If required,

UE: Proceed per UE: Proceed per redirect UE to VoLGA VoLGA A-mode VoLGA Iu-mode Iu-mode or VoLGA A- procedures procedures mode capable VANC.

UE: Proceed per

VoLGA Iu-mode or VoLGA A-mode procedures

* The VANC's choice of VoLGA Iu-mode versus VoLGA A-mode may be based on other information received in the VoLGA registration message from the UE, information stored in the VANC, and on operator policy.

B. Rove-Out

[00108] When a UE moves out of VANC service area it must rove -out from the

VoLGA system. "Rove-out" is the process in which the UE switches the serving RR entity for CS domain services from GA-CSR (VoLGA A-mode) or GA-RRC (VoLGA Iu-mode) to GERAN RR or UTRAN RRC. When the UE roves out, depending on prevailing circumstances, the UE may be able to deregister with the VANC.

[00109] In some embodiments, the VoLGA deregistration procedure allows the UE to explicitly inform the VANC that it is leaving VoLGA mode by sending a GA-RC DEREGISTER message to the VANC. In some embodiments, the VANC supports "implicit VoLGA deregistration"; e.g., when the TCP connection that is used for VoLGA signaling transport is abruptly lost or when the VANC receives the PS to CS Complete Acknowledge message from the MME after the UE has performed handover of the VoLGA voice bearer from EPS to GERAN without DTM support.

[00110] In some embodiments, the VANC autonomously releases the UE registration context, and sends a GA-RC DEREGISTER message to the UE. In some embodiments, the VANC implicitly deregisters the UE by closing the TCP connection with the UE. In some embodiments, the VANC deletes the stored UE context information.

[00111] Some embodiments of VoLGA deregistration can be performed via the following five steps. The UE sends (in step 1) a GA-RC DEREGISTER message to the VANC. This may occur either because the UE performs the IMSI Detach procedure illustrated in the "IMSI Detach" Section below, or the UE has completed PS handover of the VoLGA signaling bearer from EPS to GERAN/UTRAN.

[00112] The VANC receives (in step 2) the Forward Relocation Complete Ack message from the MME after the UE has performed handover of the VoLGA voice bearer from EPS to GERAN/UTRAN. In some embodiments, the VANC may wait for a period of time for the GA-RC DEREGISTER message from the UE (i.e., sent from the UE in the new GERAN/UTRAN cell if the VoLGA signaling bearer has also been handed over); on receipt of the GA-RC DEREGISTER message or timeout, the VANC initiates the release of the VoLGA signaling bearer via the Rx interface to the PCRF.

[00113] Assume (in step 3) the VANC does not receive a GA-RC KEEP ALIVE message from the UE for an extended period of time in some embodiments. This may occur if the UE is directed to move to a GERAN/UTRAN cell and PS handover is not supported (i.e., via EPS to GERAN External NACC). The PCRF signals (in step 4) the VANC (via the Rx interface) that the EPS bearer used for VoLGA signaling has been lost. The VANC decides (in step 5) to deregister the UE for some reason (e.g., OA&M related) and sends a GA-RC DEREGISTER message to the UE. In some embodiments, the VANC deletes the stored UE context information.

[00114] Figure 13 illustrates VoLGA deregistration initiated by the UE in some embodiments. As shown, the UE 1305 sends (in step 1) the GA-RC DEREGISTER message to the VANC 1310, which removes the UE context in the VANC 1310.

[00115] Figure 14 illustrates VoLGA deregistration initiated by the VANC in some embodiments. Here, the VANC 1410 sends (in step 1) the GA-RC DEREGISTER message to the UE 1405. V. SIGNALLING CONNECTION FAILURE RECOVERY

[00116] In VoLGA, LTE devices or UEs (e.g., mobile stations, PC data cards) establish a TCP connection (or other reliable transport connections such as SCTP connection) with a VANC and subsequently register with the VANC while in E-UTRAN coverage. Registration procedure in some embodiments is described above in Section IV. After registration, in some cases, a signalling connection failure may occur between the VANC and the UE. For instance, the VANC may receive a TCP reset or receive no TCP acknowledgement when the VANC attempts to send a message to the UE. Likewise, the UE may receive a TCP reset or receive no TCP acknowledgement when the UE attempts to send a message to the VANC.

[00117] The following sections describe (1) a mechanism for a VANC to notify a UE of a signaling connection failure and (2) a mechanism for a UE to recover and re-connect to a VANC when the UE detects a signaling connection failure. In some embodiments, the UE is notified when the VANC receives a paging request message for the UE from a MSC. This ensures that a UE does not miss a Mobile terminated voice or SMS call even when the UE is registered with a VANC with a long keep-alive timer (e.g., to avoid battery drain).

[00118] In the sections described below, several different terms are used to describe the modes and states of a registered UE. Specifically, when the UE receives or places a call, the UE is said to move from an "idle" mode to a "dedicated" mode. Conversely, when the UE releases the call or is waiting for a call, the UE is said to be in "idle" mode. Also, when a TCP connection failure to the UE has been detected, the VANC marks the state or context of the UE as "inactive". The VANC may also mark the state or context of the UE as "active" in a number of different instances (e.g., when the UE re-establishes the failed TCP connection, registers with the VANC). Although, the words "active" and "inactive" are used in a number of places below, one of ordinary skill in the art will realize that these words could be replaced with other words or terms without deviating from the spirit and scope of the invention. For instance, these words may be replaced with words such as "synched", "connected", "normally registered" for one mode or state and "awaiting re-sync", "disconnected", "abnormally registered" for the other mode or state (or with any other words that indicate in some manner that the UE is registered properly or improperly with the VANC, or the TCP connection failure has been detected or has not been detected). A. Connection Failure Recovery Procedures

[00119] When a VANC detects a failure of a signalling channel connection to a UE

(e.g., the VANC receives a TCP reset, receives no TCP acknowledgement when it attempts to send a message to the UE, or the VANC recovers from an internal failure of the TCP subsystem), the VANC may take on one of several different actions or procedures to recover from the connection failure. For instance:

1. The VANC may immediately send a synchronization command (e.g., GA-RC SYNCHRONIZATION COMMAND) message (hereinafter, "sync command message") to the affected UE(s).

2. The VANC may wait for a period of time until resources are available and then send a sync command message to the UE. For instance, when a VANC failure has resulted in failure of multiple signalling channels of multiple UEs, the VANC may wait for resources to become available before sending the sync command message to each of the affected UEs. In some embodiments, this procedure is for avoiding a burst of the sync command messages being sent out in the network when the TCP connection failure is due to a failure of one or multiple subsystems on the VANC. Such VANC failure could result in a burst of numerous (e.g., tens of thousands) messages being sent out in the case of procedure 1 described above.

3. The VANC may mark the signalling channel of the UE as "inactive" but not immediately send the sync command message to the UE. For instance, the VANC may send out the sync command message to the UE only when the VANC receives a RANAP PAGING REQUEST message for the UE from a MSC (e.g., for a mobile terminated voice or SMS call) and the UE is still in the "inactive" state on the VANC.

[00120] In some embodiment, the VANC uses a UE's remote IP address (i.e., the IP address used inside the IPSec tunnel) as a destination IP address (e.g., the message is routed via a UE's IPSec tunnel). Since the TCP connection has failed, the VANC uses a UDP transport (which is at the same protocol level as the TCP protocol layer) in order to send the sync command message to the UE. The VANC sends the sync command message to the UE using the UDP transport by specifying a stored UE IP address and a pre-defined UDP port number. In some embodiments, the VANC uses the UDP transport solely for sending such sync command message to the UE when a TCP connection failure occurs. While VoLGA registered, in some embodiment, the UE may (1) monitor for sync command messages received on the predefined UDP port number and, when such message is received, (2) initiate a sync information procedure (i.e., UE-initiated synchronization procedure) as described in TS 43.318.

B. Re-Synchronization on TCP failure detection - normal cases

[00121] Figure 15 illustrates a procedure for a re-synchronization between a UE and a

VANC that the UE is registered with in some embodiments. As shown, VANC 1510 (in step 1) detects a TCP connection failure to a UE 1505. For instance, VANC 1510 receives a TCP reset or no TCP acknowledgement when the VANC attempts to send a message to UE 1505. The signalling connection failure may also be due to the failure of a VANC subsystem that is responsible for supporting one or more TCP connections.

[00122] Once the TCP connection failure is detected, VANC 1510 initiates the recovery of the TCP connection to UE 1505. This ensures that UE 1505 does not miss a Mobile terminated voice or SMS call even when the UE is registered with a VANC with a long keep-alive timer (e.g., to avoid battery drain). In particular, VANC 1510 initiates the recovery by sending (in step 2) a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message to UE 1505.

[00123] In some embodiments, VANC 1510 sends the sync command message to the

UE 1505 immediately after detecting a connection failure or after waiting for a period of time until VANC resources are available. For instance, when a failure of VANC 1510 has resulted in failure of multiple signalling channels of multiple UEs, the VANC may wait for resources to become available before sending the sync command message to each of the affected UEs. Since the TCP connection has failed, VANC 1510 uses a UDP transport (in step 2) in order to send the sync command message to the UE 1505. VANC 1510 sends the sync command message to UE 1505 using the UDP transport by specifying a stored UE IP address and a predefined UDP port number. In some embodiments, VANC 1510 uses the UDP transport solely for sending such sync command message to UE 1505 when a TCP connection failure occurs.

[00124] UE 1505 detects (in step 3) the TCP connection failure by receiving the sync command message from VANC 1510 in some cases. In other cases, UE 1505 detects the TCP connection failure without receiving the sync command message. For instance, UE 1505 receives a TCP reset or no TCP acknowledgement when UE 1505 attempts to send a message to VANC 1510.

[00125] UE 1505 having detected the TCP connection failure immediately attempts to set up a TCP connection or re-establish the failed TCP connection to the VANC in some embodiments. As shown in Figure 15, UE 1505 (in step 4) successfully re-establishes the TCP connection to the assigned VANC 1510. After re-establishing the TCP connection, UE 1505 (in step 5) sends a synchronization information (e.g., GA-RC SYNCHRONIZATION INFO) message to the VANC 1510 to synchronize the UE state information.

[00126] VANC 1510 (in step 6) updates the UE registration status of UE 1505 based on the received information. In some embodiments, at the time of TCP connection failure, the VANC has previously stored (e.g., during registration) "context" information for the registered UE. For example, the VANC has stored the UE's IMSI and remote IP address. When the TCP connection failure is detected, the VANC may mark the UE context information in some manner to indicate that the TCP connection for the UE has failed or the UE is abnormally registered with the VANC. For instance, the VANC may indicate in the context information that the UE is "inactive" or "awaiting re-sync". When the sync info (e.g., GA-RC SYNCHRONIZATION INFO) message is received, the VANC updates the stored UE context information to indicate that the UE as being normally registered (e.g., no longer "inactive" or "awaiting re-sync").

[00127] In the procedure described above, when the VANC 1510 initiates the TCP connection recovery, the UE in some embodiments does not have to periodically send a keep- alive message to the VANC in order to test and re-establish the TCP connection. Performing the application level and/or TCP level keep-alive procedures take up valuable resources of the UE (e.g., UE battery resources to transmit the message, and network resources since a radio channel has to be assigned to the UE to allow message transmission). When the VANC 1510 initiates the TCP connection recovery, the UE 1505 in some embodiments does not have to periodically send a keep-alive message at these different levels. This allows the UE 1505 to save the resources that the UE would otherwise spend to test the TCP connection. Also, this recovery procedure allows both the UE 1505 and the VANC 610 to proactively initiate the TCP connection recovery when a TCP connection failure is detected. C. Re-Synchronization on TCP failure detection - abnormal cases

[00128] Figure 16 illustrates a procedure for a re-synchronization between a UE and a

VANC that the UE is registered with in some embodiments. As shown, VANC 1610 (in step 1) detects a TCP connection failure to a UE 1605. For instance, VANC 1610 receives a TCP reset or no TCP acknowledgement when the VANC attempts to send a message to UE 1605. The signalling connection failure may also be due to the failure of a VANC subsystem that is responsible for supporting one or more TCP connections.

[00129] Once the TCP connection failure is detected, VANC 1610 initiates the recovery of the TCP connection to UE 1605. This ensures that UE 1605 does not miss a Mobile terminated voice or SMS call even when the UE is registered with a VANC with a long keep-alive timer (e.g., to avoid battery drain). In particular, VANC 1610 initiates the recovery by sending (in step 2) a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message to UE 1605.

[00130] In some embodiments, VANC 1610 sends the sync command message to the

UE 1605 immediately after detecting a connection failure or after waiting for a period of time until VANC resources are available. For instance, when a failure of VANC 1610 has resulted in failure of multiple signalling channels of multiple UEs, the VANC may wait for resources to become available before sending the sync command message to each of the affected UEs. Since the TCP connection has failed, VANC 1610 uses a UDP transport (in step 2) in order to send the sync command message to the UE 1605. VANC 1610 sends the sync command message to UE 1605 using the UDP transport by specifying a stored UE IP address and a predefined UDP port number. In some embodiments, VANC 1610 uses the UDP transport solely for sending such sync command message to UE 1605 when a TCP connection failure occurs.

[00131] UE 1605 detects (in step 3) the TCP connection failure by receiving the sync command message from VANC 1610 in some cases. In other cases, UE 1605 detects the TCP connection failure without receiving the sync command message from VANC 1610. For instance, UE 1605 receives a TCP reset or no TCP acknowledgement when UE 1605 attempts to send a message to VANC 1610.

[00132] UE 1605 having detected the TCP connection failure immediately attempts to set up a TCP connection or re-establish the failed TCP connection to VANC 1610 in some embodiments. In some cases, UE 1605 has only the FQDN of VANC 1610 and needs to resolve the FQDN to an IP address. In such cases, UE 1605 uses the result of previous DNS query (i.e., the IP address of VANC 1610) if the time to live (TTL) value in the previous DNS response to the UE 1605 has not expired. However, if the TTL value has expired, UE 1605 sends (in step 4) to the DNS-r server 725 a new DNS query with the FQDN of VANC 1610 in order to obtain the IP address of VANC 1610 again.

[00133] Upon receiving the DNS query from UE 1605, the DNS-r server 725 resolves the FQDN to an IP address. The DNS server 1615 in some embodiments sends the same IP address or the same list of IP addresses that were included in the previous response to UE 1605. Then, UE 1605 will be able to re-establish the failed TCP connection to VANC 710. However, the DNS server 1615 in some cases resolves the FQDN to an IP address of a VANC (e.g., VANC 1620) other than VANC 1610. For example, the FQDN may not be unique to VANC 1610 and thus the DNS server 1615 resolves it to the IP address of VANC 1620. As another example, the FQDN may be an FQDN of a VANC pool to which VANC 1610 and VANC 1620 belong and the DNS sends a list of the IP addresses with the IP address of the VANC 1620 as the first IP address in the list (e.g., due to the round-robin DNS procedure).

[00134] When the DNS server 1615 sends (in step 5) a DNS response with the IP address of VANC 1620 (VANC IP2) or a list of IP addresses with VANC IP2 as the first IP address in the list and the IP address of the VANC 710 (VANC IP1) as the second IP address in the list. UE 1605 then uses the IP address of VANC 1620 to set up (in step 6) a new TCP connection and that results in a new TCP connection between UE 1605 and VANC 1620. UE 1605 sends (in step 7) a synchronization information (e.g., GA-RC SYNCHRONIZATION INFO) message to VANC 1620.

[00135] Upon receiving the synchronization information, VANC 1620 in this example verifies (in step 8) the UE registration context information for UE 1605 but finds no information for UE 1605 because UE 1605 is not registered with VANC 1620. VANC 1620 in some embodiments then requires UE 1620 to deregister by sending a GA-RC DEREGISTER message with Register Reject CAUSE IE value 'Force re-registration'. In some embodiments, VANC 1620 may also redirect UE 1605 to another VANC or VANC 1610.

D. A solution to prevent abnormal cases in re-synchronization

[00136] The abnormal cases of re-synchronization resulting from establishing a TCP connection with the wrong VANC as discussed above can be prevented by a UE using the IP address or FQDN of the VANC that the UE is registered with instead of using the FQDN of the VANC pool when setting up a TCP connection or re-establishing the failed TCP connection to the VANC. As described above by reference to Figure 12, a VANC in some embodiments provides its identification (e.g., an IP address and/or FQDN) in the register accept message to a UE that is registering with the VANC and requires the UE to use the identification when it is necessary to re-sync with the VANC while the UE is registered with the VANC.

[00137] Figure 17 conceptually illustrates a process 1700 for preventing abnormal cases of re-synchronization between a UE and a VANC that the UE is registered with. The process is performed by the UE such as UE 1605 in some embodiments. As shown, the process receives (at 1705) a register accept message from the VANC when registering with the VANC. The register accept message indicates that the VANC is accepting the registration of the UE with the VANC. In some embodiments, the register accept message is a GA-RC REGISTER ACCEPT message. Registering a UE with a VANC is described in detail by reference to Figure 12 above.

[00138] The register accept message in some embodiments includes identification of the VANC which identifies the VANC. In some embodiments, the identification includes an IP address of the VANC. In other embodiments, the identification includes a FQDN which translates to an IP address of the VANC. The identification of different embodiments includes both the IP address and the FQDN of the VANC.

[00139] Process 1700 (at 1705) extracts the identification from the register accept message and stores the identification for future use. For example, the process uses the information when it is necessary to re-sync with the VANC. In some embodiments, the process stores the identification in the storage of the UE (e.g., volatile storage such as RAM or non- volatile storage such as a hard disk or a solid-state drive).

[00140] Next, the process detects (at 1710) a connection failure between the UE and the VANC. In some embodiments, a TCP connection is established during registration of the UE with the VANC. In some cases, the process detects the connection failure by receiving a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message from the VANC 1610. Since the TCP connection has failed, the process receives the sync command message over a UDP transport from the VANC in some embodiments. The process in other cases detects the connection failure without receiving the sync command message from the VANC. For instance, the process receives a TCP reset or no TCP acknowledgement when the process attempts to send a message to the VANC.

[00141] Using the identification of the VANC stored (at 1705), the process attempts

(at 1720) to set up a connection or re-establish the failed connection to the VANC. When the identification includes an IP address of the VANC, the process in some embodiments uses the IP address to connect to the VANC. In these embodiments, the process does not need to send a DNS Query with a FQDN to get an IP address of the VANC and directly connects to the VANC using the identification. When the identification includes a FQDN which always translates to an IP address of the VANC in some embodiments, the process sends a DNS query to a DNS server to get an IP address of the VANC before connecting to the VANC. A FQDN can always translate to an IP address of the VANC when the FQDN is unique to the VANC. For example, when the DNS server has three records: one to resolve VANC-2- FQDN to the VANC-2a or VANC-2b in VANC pool 2, another to resolve VANC-2a-FQDN to VANC-2a, and another to resolve VANC-2b-FQDN to VANC-2b, the DNS server will always resolve VANC-2a-FQDN to VANC-2a and resolve VANC-2b-FQDN to VANC-2b.

[00142] In some embodiments, the process performs the rest of operations for resynchronization between the UE and the VANC as described above by reference to Figure 15. For example, the process re-establishes the TCP connection to the VANC. After reestablishing the TCP connection, the process sends a synchronization information (e.g., GA- RC SYNCHRONIZATION INFO) message to the VANC to synchronize the UE state information.

VI. Computer System

[00143] Many of the above-described processes, methods, functionalities, protocol stacks, etc. are implemented as software processes that are specified as a set of instructions recorded on a non-transitory computer readable storage medium (also referred to as non- transitory computer readable medium). When these instructions are executed by one or more processing units or computational elements (such as processors or other computational elements like ASICs and FPGAs), they cause the computational element(s) to perform the actions indicated in the instructions. Computer is meant in its broadest sense, and can include any electronic device with a processor (e.g., HNB and HNB-GW). Examples of computer readable media include, but are not limited to, compact disc read-only memories (CD- ROMs), flash drives, random access memory (RAM) chips, hard drives, erasable programmable read only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[00144] In this specification, the term "software" is meant to include firmware residing in read-only memory or applications stored in magnetic storage which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs when installed to operate on one or more computer systems define one or more specific machine implementations that execute and perform the operations of the software programs.

[00145] Figure 18 conceptually illustrates a computer system with which some embodiments of the invention are implemented. The computer system 1800 includes a bus 1805, a processor 1810, a system memory 1815, a read-only memory 1820, a permanent storage device 1825, input devices 1830, and output devices 1835.

[00146] The bus 1805 collectively represents all system, peripheral, and chipset buses that support communication among internal devices of the computer system 1800. For instance, the bus 1805 communicatively connects one or more processors 1810 with the readonly memory 1820, the system memory 1815, and the permanent storage device 1825.

[00147] From these various memory units, the processor 1810 retrieves instructions to execute and data to process in order to execute the processes of the invention. In some embodiments the processor comprises a Field Programmable Gate Array (FPGA), an ASIC, or various other electronic components for executing instructions. The read-only-memory (ROM) 1820 stores static data and instructions that are needed by the processor 1810 and other modules of the computer system. The permanent storage device 1825, on the other hand, is a read-and- write memory device. This device is a non- volatile memory unit that stores instruction and data even when the computer system 1800 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 1825. Some embodiments use one or more removable storage devices (flash memory card or memory stick) as the permanent storage device.

[00148] Like the permanent storage device 1825, the system memory 1815 is a read- and-write memory device. However, unlike storage device 1825, the system memory is a volatile read-and-write memory, such as a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime.

[00149] Instructions and/or data needed to perform processes of some embodiments are stored in the system memory 1815, the permanent storage device 1825, the read-only memory 1820, or any combination of the three. For example, the various memory units include instructions for processing multimedia items in accordance with some embodiments. From these various memory units, the processor 1810 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[00150] The bus 1805 also connects to the input and output devices 1830 and 1835.

The input devices enable the user to communicate information and select commands to the computer system. The input devices 1830 include alphanumeric keyboards and cursor- controllers. The output devices 1835 display images generated by the computer system. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Finally, as shown in Figure 18, bus 1805 also couples computer 1800 to a network 1865 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network ("LAN"), a wide area network ("WAN"), or an Intranet) or a network of networks (such as the Internet).

[00151] Any or all of the components of computer system 1800 may be used in conjunction with the invention. For instance, some or all components of the computer system described with regards to Figure 18 comprise some embodiments of the UE, DHCP, DNS, SeGW, VANC, MSC described above. However, one of ordinary skill in the art will appreciate that any other system configuration may also be used in conjunction with the invention or components of the invention.

[00152] Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, CD-ROM, recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual- layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable blu-ray discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processor and includes sets of instructions for performing various operations. Examples of hardware devices configured to store and execute sets of instructions include, but are not limited to application specific integrated circuits (ASICs), field programmable gate arrays (FPGA), programmable logic devices (PLDs), ROM, and RAM devices. Examples of computer programs or computer code include machine code, such as produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter. In some embodiments, the user equipment (e.g., a cellular phone), VANC, different entities in EPS, etc. include one or more of the above described computer-readable medium, memory, or storage.

[00153] As used in this specification and any claims of this application, the terms

"computer", "server", "processor", and "memory" all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms "computer readable medium" and "computer readable media" are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals. In some embodiments, the user equipment (e.g., a cellular phone), VANC, different entities in EPS, etc. include one or more of the above described processors.

[00154] It should be recognized by one of ordinary skill in the art that any or all of the components of computer system 1800 may be used in conjunction with the invention. For instance, some or all components of the computer system described with regards to Figure 18 comprise some embodiments of the UE, VANC, EPS and E-UTRAN described above. Moreover, one of ordinary skill in the art will appreciate that any other system configuration may also be used in conjunction with the invention or components of the invention. VII. Definitions, Acronyms, and Abbreviations

A. Definitions

[00155] The following is a list of definitions used in this document:

[00156] Terms from relevant 3 GPP Technical Specifications may be used in this document. A term defined in the present document takes precedence over the definition of the same term, if any, in 3 GPP TSs.

[00157] VoLGA Access Network Controller (VANC): a GAN controller (GANC) as known from 3GPP GAN that has been modified to support CS services over EPS as specified by the VoLGA forum.

[00158] VANC pool: one or more VANCs that serve the same VANC service area.

[00159] VANC service area: one or more LTE cells where the UE can be served by the same VANC. A VANC service area may or may not be aligned with EPS tracking areas.

[00160] VoLGA: short for "Voice over LTE via Generic Access" - a collective term referring to the functionality of providing CS services over EPS/LTE.

[00161] VoLGA service area: one or more LTE cells that can be served by the same MSC (pool) for VoLGA services. Note: whenever the term "MSC" is used in this document, it applies equally to MSC pools in case of A/Iu flex, and comprises MSC server + MGW in case of post-Rel-99 architecture.

[00162] VoLGA services: the collection of CS services that can be provided via

VOLGA.

B. Acronyms and Abbreviations

[00163] The following is a list of abbreviations used in this document:

3 GPP 3^r Generation Partnership Project

3GPP TS 3^rd Generation Partnership Project Technical Specifications

AA Access Attempt AAA Authentication, Authorization and Accounting

Ack Acknowledgment

AKA Authentication and Key Agreement

AP Access Point

APN Access Point Name

BSC Base Station Controller

BTS Base Transceiver Station

CBC Cell Broadcast Center

CN Core Network

CS Circuit Switched

DHCP Dynamic Host Configuration Protocol

DL Downlink

DNS Domain Name System

DTM Dual Transfer Mode

EAP Extensible Authentication Protocol

EDGE Enhanced Data Rates for GSM Evolution

EPC Evolved Packet Core

EPS Evolved Packet System

E-UTRAN Evolved UTRAN

FQDN Fully Qualified Domain Name

GAN Generic Access Network

GANC Generic Access Network Controller

GA-CSR Generic Access - Circuit Switched Resources

GA-RC Generic Access - Resource Control

GA-RRC Generic Access Radio Resource Control

GERAN GSM EDGE Radio Access Network

GPRS General Packet Radio Service

GSM Global System for Mobile communications

GUTI Globally Unique Temporary Identity

GW Gateway

HLR Home Location Register

HOSF Handover Selection Function

HPLMN Home PLMN

HSS Home Subscriber Server IE Information Element

IKE Internet Key Exchange

IKEv2 IKE Version 2

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

IP-CAN Internet Protocol Connectivity Access Network

IPSec Internet Protocol Security

IPSec ESP Internet Protocol Security Encapsulating Security Payload

LAI Location Area Identity

LTE Long Term Evolution

MGW Media Gateway

MME Mobility Management Entity

MSC Mobile Switching Center

MSISDN Mobile Subscriber ISDN

NACC Network Assisted Cell Change

NAS Non-Access Stratum

OA&M Operations, Administration, and Management

PCRF Policy and Charging Rules Function

PDN Packet Data Network

PLMN Public Land Mobile Network

PS Packet Switched

P-GW PDN Gateway

RANAP Radio Access Network Application Part

RAT Radio Access Technology

RLC Radio Link Control

RNC Radio Network Controller

RR Resource Record

RRC Radio Resource Control

SAE System Architecture Evolution

SAI Service Area Identifier

SCTP Stream Control Transmission Protocol

SEGW SEcurity GateWay

SeGW Security GateWay SGSN Serving GPRS Support Node

SMLC Serving Mobile Location Center

SMS Short Message Service

SRVCC Single-Radio Voice Call Continuity

STN-SR Session Transfer Number for SRVCC

S-GW Serving Gateway

S1AP SI (interface between EPC and E-UTRAN) Application Part

TA Tracking Area

TAU Tracking Area Update

TCP Transmission Control Protocol

TTL Time to Live

UE User Equipment

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunication System

UTRAN UMTS Terrestrial Radio Access Network

Up Up is the Interface between UE and GANC

VANC VoLGA Access Network Controller

VLR Visited Location Register

VoIP Voice over Internet Protocol

VoLGA Voice over LTE via Generic Access

VPLMN Visited Public Land Mobile Network

Claims

CLAIMS What claimed is:

1. In a Voice over Long Term Evolution (LTE) via Generic Access (VoLGA) wireless communication system comprising a VoLGA Access Network Controller (VANC) and at least one user equipments (UE), a method of re-connecting the UE to the VANC, the method comprising: receiving a register accept message from the VANC, the register accept message comprising an identification of the VANC; detecting a connection failure between the UE and the VANC; and re-connecting the UE to the VANC using the identification of the VANC.

2. The method of claim 1, wherein the identification of the VANC comprises an Internet Protocol (IP) address of the VANC.

3. The method of claim 1, wherein the identification of the VANC comprises a fully qualified domain name (FQDN) address of the VANC.

4. The method of claim 3, wherein the FQDN is unique to the VANC.

5. The method of claim 1, wherein the UE is communicatively coupled to the VANC using a transmission control protocol (TCP) connection.

6. The method of claim 5, wherein detecting a connection failure between the UE and the VANC comprises receiving a TCP Reset message from the VANC.

7. The method of claim 5, wherein detecting a connection failure between the UE and VANC comprises receiving a synchronization command message from the VANC.

8. The method of claim 7, wherein the synchronization command message comprises a GA-RC SYNCHRONIZATION COMMAND message.

9. The method of claim 7, wherein the synchronization command message is received from the VANC using User Datagram Protocol (UDP) transport.

10. The method of claim 1, wherein the address of the VANC is different than an address originally used by the UE to connect to the VANC.

11. The method of claim 1 , wherein said re-connecting is performed after the UE has registered with the VANC.

12. The method of claim 1 further comprising storing the identification in the UE.

13. In a communication system comprising a plurality of evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (E- UTRANs) communicatively coupling a User Equipment (UE) to a Voice over long term evolution (LTE) via Generic Access (VoLGA) network controller (VANC), a non-transitory computer readable medium of the VANC storing a computer program, the computer program executable by at least one processor, the computer program comprising sets of instructions for:

receiving a register accept message from the VANC, the register accept message comprising an address of the VANC; detecting the signalling connection failure between the UE and the VANC; and re-connecting the UE to the VANC using the address of the VANC.

14. The non-transitory computer readable medium of claim 13, wherein the identification of the VANC comprises an Internet Protocol (IP) address of the VANC.

15. The non-transitory computer readable medium of claim 13, wherein the identification of the VANC comprises a fully qualified domain name (FQDN) address of the VANC.

16. The non-transitory computer readable medium of claim 14, wherein the FQDN is unique to the VANC.

17. The non-transitory computer readable medium of claim 13, wherein the UE is communicatively coupled to the VANC using a transmission control protocol (TCP) connection.

18. The non-transitory computer readable medium of claim 13, wherein the address of the VANC is different than an address originally used by the UE to connect to the VANC.

19. The non-transitory computer readable medium of claim 13, wherein said reconnecting is performed after the UE has registered with the VANC.

20. The non-transitory computer readable medium of claim 13, wherein the computer program further comprises a set of instructions for storing the identification in the UE.