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), V 1.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.11a, 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 "3GPP TS 43.318". The GANC is also described in 3GPP TS 44.318: "Generic Access Network (GAN); Mobile GAN interface layer 3 specification" that is incorporated herein by reference, hereinafter "3GPP 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. In turn, the TCP connection failure may cause the UE to miss a mobile terminated voice or Short Message Service (SMS) call. For instance, the network controller may not be able to forward a paging request message for the UE from a mobile switching center (MSC) after the connection failure occurs.

[0008] A previous approach for solving the TCP connection failure problem is for the UE to detect the failure and re-establish the TCP connection when the failure is detected. For instance, when the UE initiates a mobile originated call (e.g., voice or SMS) or supplementary services call, the UE may detect that a TCP signalling channel connection has failed. In some cases, the UE receives a TCP reset when attempting to send a message to the network controller. Once the UE detects the failure, the UE initiates recovery by re-establishing the TCP signalling channel connection.

[0009] To facilitate the detection of TCP connection failure, some UEs maintain a keep- alive timer and periodically attempt to send a keep-alive message to the network controller when the timer expires. In some cases, when a UE is registered with a network controller and is in "idle mode", there may be multiple keep-alive procedures occurring between the network controller and the UE that have the effect of maintaining the TCP connection.

[0010] At the application level, when the UE registers with the network controller, the

UE may receive a keep-alive timer parameter from the network controller that indicates a time period at which the UE has to send application-level GA-RC KEEP ALIVE messages over the TCP connection. These periodic keep-alive messages are sent over the established TCP connection to the network controller. If the network controller end of the TCP has failed, the context related to the TCP connection that is kept at the network controller may be lost. When the network controller subsequently receives a TCP packet that is routed through the TCP connection, the TCP subsystem of the network controller may not recognize the TCP connection. The network controller, therefore, sends out a TCP reset message to the UE. The TCP reset, however, has the same IP address and TCP port number as the failed TCP connection and appears to the UE as a regular TCP packet. If the UE receives the TCP reset from the network controller, the UE may try to re-establish the TCP connection. The UE may further detect that the connection has failed at the IP connectivity level without receiving a TCP reset and attempt re-establishment of the TCP connection (e.g., due to a failure to receive an acknowledgement for a previously transmitted packet).

[0011] Also, at the TCP connection level, there may be a TCP keep-alive function that is enabled within the TCP subsystem of the UE. When a TCP packet has not been sent or received for a period of time, this TCP sub-system of the UE may send a TCP packet to the network controller's TCP sub-system in order to test the TCP connection. If the connection has failed or the UE receives a TCP reset from the network controller's TCP sub-system, the UE may attempt to reestablish the TCP connection. With these keep-alive procedures, the UE initiates the re- establishment of the TCP connection when the TCP connection fails or the UE receives the TCP reset from the network controller.

[0012] There are a number of shortcomings with this previous approach. For instance, with a short keep-alive timer, the UE 's battery life may be reduced as the UE attempts to send the keep-alive message in short intervals. Also, even with the short keep-alive timer, there is a chance that the UE may miss a mobile terminated or SMS call as the UE may be paged in between the short intervals. Furthermore, when the keep-alive timer is long (e.g., to save battery life), the chances of the UE missing a call becomes greater.

BRIEF SUMMARY

[0013] 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 Voiced 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.

[0014] In some embodiments, the network controller detects a connection failure to a UE that is registered with the network controller. Having detected the failure, the network controller sends a synchronization command message from the network controller to the UE. The synchronization command message is for the UE to re-establish the failed connection to the network controller. Once the failed connection is re-established, the network controller receives a synchronization information message from the UE. The network controller then updates the UE's state. For instance, the network controller may mark or indicate in some manner that the UE is synched or properly registered with the network controller.

[0015] In some embodiments, the signalling connection between the network controller and the UE is a TCP connection. Since the TCP connection has failed, the network controller sends the synchronization command message to the UE using a User Datagram Protocol (UDP) transport. The network controller sends the synchronization command message to the UE using the UDP transport by specifying a stored IP address and a predefined UDP port number. In some embodiments, the network controller uses the UDP transport solely for sending such synchronization command messages. In other words, the synchronization command message is the only "control plane" message that is sent using the UDP transport, while all other "control plane" messages are sent using the TCP transport.

[0016] A subsystem of the network controller that is responsible for supporting one or more TCP connections may cause a failure of multiple TCP connections in some cases. In some embodiments, when the network controller failure has resulted in failure of multiple signalling connections to multiple UEs, the network controller may not immediately send out the synchronization command messages to the affected UEs. Instead, the network controller may wait for a period of time and send the synchronization command to each of the affected UEs as resources become available.

[0017] In some embodiments, after detecting the signalling connection failure, the network controller may update the UE 's state and may not immediately send out the synchronization command message to the UE. Instead, the network controller waits until a paging message for the UE is received from a mobile switching center (MSC). When the network controller receives the paging message, the network controller may check the state of the UE. When the network determines that the UE is not properly synched or not properly registered with the UE, the network controller may then send out the synchronization command message to the UE. In some such embodiments, the network controller indicates in the synchronization command message that the UE is being paged by including a paging indicator information element.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] 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.

[0019] Figure 1 illustrates an Iu-mode Generic Access Network (GAN) functional architecture of some embodiments.

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

[0021] Figure 3 illustrates a protocol architecture for a VoLGA A-mode control plane in some embodiments.

[0022] Figure 4 illustrates a protocol architecture for a VoLGA Iu-mode control plane in some embodiments.

[0023] Figure 5 illustrates VoLGA registration in some embodiments.

[0024] Figure 6 illustrates a procedure for a VANC-initiated re-synchronization in some embodiments.

[0025] Figure 7 illustrates a process for recovering from a signalling connection failure.

[0026] Figure 8 illustrates a procedure for a VANC-initiated re-synchronization at paging request in some embodiments.

[0027] Figure 9 illustrates a process for recovering from a signalling connection failure at paging request.

[0028] Figure 10 illustrates a process for recovering from a signalling connection failure.

[0029] Figure 11 conceptually illustrates a computer system with which some embodiments of the invention are implemented. DETAILED DESCRIPTION

[0030] In the following detailed description, 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.

[0031] Throughout the following description, acronyms commonly used in the telecommunications industry for wireless services are utilized along with acronyms specific to the present invention. A list of acronyms used in this application is included in Section VI.

[0032] 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 Voiced 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.

[0033] In some embodiments, the network controller detects a connection failure to a UE that is registered with the network controller. Having detected the failure, the network controller sends a synchronization command message from the network controller to the UE. The synchronization command message is for the UE to re-establish the failed connection to the network controller. Once the failed connection is re-established, the network controller receives a synchronization information message from the UE. The network controller then updates the UE's state. For instance, the network controller may mark or indicate in some manner that the UE is synched or properly registered with the network controller.

[0034] In some embodiments, the signalling connection between the network controller and the UE is a TCP connection. Since the TCP connection has failed, the network controller sends the synchronization command message to the UE using a User Datagram Protocol (UDP) transport. The network controller sends the synchronization command message to the UE using the UDP transport by specifying a stored IP address and a predefined UDP port number. In some embodiments, the network controller uses the UDP transport solely for sending such synchronization command messages. In other words, the synchronization command message is the only "control plane" message that is sent using the UDP transport, while all other "control plane" messages are sent using the TCP transport.

[0035] A subsystem of the network controller that is responsible for supporting one or more TCP connections may cause a failure of multiple TCP connections in some cases. In some embodiments, when the network controller failure has resulted in failure of multiple signalling connections to multiple UEs, the network controller may not immediately send out the synchronization command messages to the affected UEs. Instead, the network controller may wait for a period of time and send the synchronization command to each of the affected UEs as resources become available.

[0036] In some embodiments, after detecting the signalling connection failure, the network controller may update the UE 's state and may not immediately send out the synchronization command message to the UE. Instead, the network controller waits until a paging message for the UE is received from a mobile switching center (MSC). When the network controller receives the paging message, the network controller may check the state of the UE. When the network determines that the UE is not properly synched or not properly registered with the UE, the network controller may then send out the synchronization command message to the UE. In some such embodiments, the network controller indicates in the synchronization command message that the UE is being paged by including a paging indicator information element.

[0037] Several more detailed embodiments of the invention are described in the sections below. Section I provides a description of several network controllers. The description in Section I is followed by a description of protocol architectures in Section II. Section III describes registrations procedures. Section IV describes several procedures for recovering from a signalling connection failure. Section V describes a computer system with which some embodiments of the invention are implemented. Finally, a list of acronyms and abbreviations used in this application is included in Section VI. I. NETWORK CONTROLLERS

A. Generic Access Network Controller (GANC)

[0038] In some embodiments, a core network interacts with a GANC as though it is a radio network controller (RNC). A generic Internet Protocol (IP) access network provides connectivity between the GANC and a UE. The GANC in some embodiments is an entity that inter-works between the Iu interfaces and a generic IP access network using control plane and user plane functionalities. The control plane functionality is utilized for call control signaling, and the user plane functionality is utilized for information transfer (e.g., voice or data). In some embodiments, the GANC has the capability to inter-work with a GSM/EDGE Radio Access Network (GERAN) A/Gb interfaces. In other embodiments, the GANC has the extended capability to inter- work with both Iu and A/Gb interfaces.

[0039] Figure 1 illustrates an Iu-mode Generic Access Network (GAN) functional architecture of some embodiments. The GAN includes one or more GANC 110 and one or more generic IP access networks 115. One or more UEs 105 (one is shown for simplicity) can be connected to the GANC 110 through a generic IP access network 115. In some embodiments, GANC 110 has the capability to appear to core network 125 as a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) Radio Network Controller (RNC). In some embodiments, the GANC has the expanded capability of supporting both the Iu and A/Gb interfaces to concurrently support both Iu-mode and A/Gb- mode UEs. As shown, GANC 110 includes a Security Gateway (SEGW) 120 that terminates secure remote access tunnels from UE 105, providing mutual authentication, encryption, and data integrity for signaling, voice, and data traffic.

[0040] The generic IP access network 115 provides connectivity between UE 105 and

GANC 110. The IP transport connection extends from GANC 110 to UE 105. A single interface, the Up interface, is defined between GANC 110 and UE 105. Functionality is added to this interface, over the UP interface in order to support the Iu-mode GAN services.

[0041] The GAN co-exists with the UTRAN and maintains interconnections with Core

Network (CN) 125 and via the standardized interfaces defined for the UTRAN. These standardized interfaces include the Iu-cs interface to MSC 130 for circuit switched services, Iu- ps interface to Serving General Packet Radio Service (GPRS) Support Node (SGSN) 135 for packet switched services, Iu-pc interface to Serving Mobile Location Center (SMLC) 150 for supporting location services, and Iu-bc interface to Cell Broadcast Center (CBC) 155 for supporting cell broadcast services. The transaction control (e.g. Connection Management, CM, and Session Management, SM) and user services are provided by the core network (e.g. the Mobile Switching Center/Visited Location Register (MSC/VLR) and the SGSN/ Gateway GPRS Support Node (GGSN)).

[0042] As shown in Figure 1, the SEGW 120 is connected to an Authentication,

Authorization, and Accounting (AAA) server 140 over the Wm interface. The AAA server 140 is used to authenticate the UE 105 when setting up a secure tunnel. Some embodiments require only a subset of the Wm functionalities for the Iu mode GAN application. In these embodiments, the GANC-SEGW supports the Wm authentication procedures.

[0043] In some embodiments, the GANC has the capability to inter-work with a

GSM/EDGE Radio Access Network (GERAN) A/Gb interfaces. The GAN co-exists with the GERAN and maintains the interconnections with the CN via standardized interfaces defined for the GERAN. These standardized interfaces include the A interface to the MSC for circuit switched services, Gb interface to the SGSN for packet switched services, Lb interface to the SMLC for supporting location services, and an interface to the CBC for supporting cell broadcast services. The transaction control (e.g. CM and SM) and user services are provided by the core network (e.g. MSC/VLR and the SGSN/GGSN).

B. VoLGA Access Network Controller (VANC)

[0044] In some embodiments, a VANC is a network controller that provides network connectivity of a UE to an existing circuit switched (CS) domain core network (CN). The VANC in some embodiments is an entity that appears as a legacy base station controller (BSC) or radio network controller (RNC) to the existing CN. The VANC may use the existing A interface (VoLGA A-mode) and/or an Iu-cs interface (VoLGA Iu-mode) for CN connectivity. In this manner, the VoLGA system may be integrated into the existing CN with no change to the CN. This allows licensed wireless system providers the ability to provide VoLGA system functionality to their users with no change to their existing CS domain core network. [0045] Figure 2 illustrates a non-roaming architecture for VoLGA using an Iu-Mode interface in some embodiments. This figure includes UE 230, Evolved-UTRAN (E-UTRAN) 235, Mobility Management Entity (MME) 240, Serving Gateway/Packet Data Network Gateway (S-GW/P-GW) 245, Policy and Charging Rules Function (PCRF) 250, VANC 205, Mobile Switching Center/Visited Location Register (MSC/VLR) 210, Iu-cs interface 215, AAA server 220, and Home Location Register (HLR) 225.

[0046] In some embodiments, VANC 205 connects to MME 240 using a Z2 interface as shown in Figure 2. MME 240 functions as the key control-node for the LTE access-network. MME 240 handles tracking and paging procedures for idle mode UE including retransmissions. MME 240 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. MME 240 authenticates the user (interacting with the home subscriber server, HSS). LTE Non- Access Stratum (NAS) signaling terminates at the MME, and the MME generates and allocates temporary identities to UEs. MME 240 checks the authorization of the UE to use a service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. MME 240 is the end point for ciphering/integrity protection for LTE NAS signaling and handles security key management. MME 240 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.

[0047] The E-UTRAN includes one or more Evolved Node Bs (eNBs or eNodeBs). The eNBs provide an air interface for the UE with each eNB covering a service region for one or more UEs. The eNB is a standard part of the Evolved-UTRAN (E-UTRAN) as specified in the 3GPP Long Term Evolution (LTE) standards (e.g., 3GPP TS 36.300: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2" that is incorporated herein by reference, hereinafter "3GPP TS 36.300").

[0048] MME 240 and S-GW/P-GW 245 are collectively referred to as an Evolved Packet

Core (EPC). The EPC is the main component of a System Architecture Evolution (SAE) architecture, which is the core network architecture of 3GPP LTE wireless communication standard (e.g., 3GPP TS 36.300). The EPC is a pure packet system. Services, like voice and SMS, are packet-switched routed and are provided by application functions that make use of the EPC services. VANC 205 operates in conjunction with the EPC and facilitates the connection of the pure packet system to the legacy CS core of a 3G system in order to provide CS services (e.g., voice service and SMS) for the UEs.

[0049] In Figure 2, VANC 205 services each of the corresponding service regions of E-

UTRAN 235. The eNB, S-GW, and P-GW support the IP connection that is required between the UE and the VANC. In this manner, a single VANC can communicatively couple multiple eNB service regions to the 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 CN.

[0050] In some embodiments, VANC 205 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.

[0051] VANC 205 of some embodiments includes circuits for receiving, transmitting, generating, and processing the various messages that cause various physical transformations within the VoLGA network, 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 core network.

[0052] As shown in Figure 2, VANC 205 is communicatively coupled to the MSC/VLR

210 using the Iu-cs interface 215 (VoLGA Iu-mode). UE 230 accesses VANC 205 through E- UTRAN 235 and EPC (MME 240 and S-GW/P-GW 245). VANC 205 appears as an Application Function to PCRF 250. In particular, MME 240 is involved in the signalling required to establish the IP connection between UE 230 and VANC 205, but the MME is not in the path of the IP data flow. In some embodiments, AAA server 220 is an optional server. Also, in some embodiments, HLR 225 may be replaced with a Home Subscriber Server (HSS) (not shown). Further, in some embodiments, VANC 205 may be connected to MSC/VLR 210 using the A interface (VoLGA A-mode).

[0053] Additional interfaces of VANC 205 may include the Rx interface to the PCRF

250, the SGi interface to the S-GW/P-GW 245, the Wm interface to the AAA server 220, and an interface (e.g., either the A or Iu-cs interface depending on which type of network connection is present) to the 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.

II. PROTOCOL ARCHITECTURES

[0054] There are two separate protocol architectures for the VoLGA and GAN systems, namely a control plane architecture and a user plane architecture. Control plane architecture covers functionality related to all aspects of network signaling and control, such as call and connection control. User plane architecture covers functionality associated with issues of user-to- user information transfer and associated controls. The following section describes the position of the TCP or UDP layer in several control protocol architectures for a VoLGA system. As will be described in detail below, in some embodiments, a VANC exchanges messages with a UE over the TCP or UDP layer in order to recover a failed signalling connection. GAN system includes similar protocol architectures as described in the above mentioned 3GPP TS 43.318 and 3GPP TS 44.318 specifications.

[0055] As mentioned above, in some embodiments, the VANC and MSC/VLR are connected using the A-interface. Figure 3 illustrates the protocol architecture for a VoLGA A- mode control plane in some embodiments. As shown, communication between UE 305 and VANC 310 uses the GA-RC/GA-CSR protocol layer 315, TCP/User Datagram Protocol (UDP) layer 320, and IPSec layer 325. As will be described in detail below, when a TCP connection fails, the VANC in some embodiments sends a synchronization command message to the UE using the UDP transport, while sending other "control plane" messages using the TCP transport.

[0056] In some embodiment, the GA-RC protocol provides a resource management protocol layer between the UE and the VANC responsible for functions that include: (1) registration with the VANC (including VoLGA mode selection, either VoLGA A-mode or VoLGA Iu-mode); (2) registration update with the VANC; (3) deregistration; and (4) application level keep-alive with the VANC. The GA-CSR protocol in some embodiments provides a resource management layer, which is equivalent to the GERAN RR and provides the functions that include: (1) setup of bearer for circuit switched (CS) traffic between the UE and VANC; (2) direct transfer of NAS messages between the UE and the core network; and (3) functions such as paging, ciphering configuration, and classmark change.

[0057] In some embodiments, the TCP/UDP layer 320 is used along with the internet protocol to send data in the form of message units between two points over a generic IP access network (e.g., broadband or the Internet). TCP will break up data into smaller packets at one end point, transmit the packets, and re-sequence the packets when they arrive at the other end point. Here, TCP keeps track of individual units of data (packets) that a message is divided into for routing. As will be described in detail below, in some embodiments, VANC 310 uses a UDP transport to send a message to a UE when a TCP connection failure is detected. IPSec layer 325 is an optional layer that establishes a secure communication path with the VANC to encrypt and provide data integrity for messages exchanged between the UE and the VANC. One of ordinary skill in the art would realize that other reliable transport connections (such as SCTP) can be used interchangeably with the TCP without deviating from the spirit and scope of the invention.

[0058] Figure 4 illustrates the protocol architecture for a VoLGA Iu-mode control plane in some embodiments. This figure is similar to Figure 3; however, the VANC 405 is connected to the MSC/VLR 410 using the Iu-cs interface. As such, the BSSAP layers of the VANC and MSC/VLR in Figure 3 are replaced by the RANAP layer and signalling transport layers in Figure 4. The SCCP and the other signalling transport layers of the A- interface in Figure 3 are replaced with the Iu-cs signalling transport layers in Figure 4. Also, as will be described in detail below, the VANC 405 sends signalling messages to the UE 420 utilizing the TCP or UDP transport protocol. In some embodiments, the VANC 405 sends a synchronization command message to the UE 420 using the UDP transport, while sending other "control plane" messages using the TCP transport.

III. REGISTRATION PROCEDURE

[0059] If a UE has successfully completed a VANC discovery procedure (i.e., has the address of a VANC), the UE may attempt VoLGA registration to the 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 5 illustrates a VoLGA registration procedure in some embodiments. Prior to registering to VoLGA, however, the UE registers with a Evolved Packet System (EPS), i.e., performs 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 3GPP TS 23.401 : "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", incorporated herein by reference and hereinafter "TS 23.401". The VoLGA registration shown in Figure 5 is, therefore, performed after the UE registration with the EPS 515.

[0060] As shown in Figure 5, UE 505 establishes (in step 1) a secure tunnel (e.g., using

IKEv2 and IPSec ESP as specified in 3GPP TS 43.318) and a TCP connection to a pre-defined port on the assigned VANC 510. Although the connection is shown as a TCP connection in Figure 5, other reliable transport connections (such as SCTP) can be used interchangeably throughout this specification wherever the use of a TCP connection is disclosed. UE 505 registers (in step 2) with VANC 510, using a register request (e.g., GA-RC REGISTER REQUEST) message. In some embodiments, the message contains: EPS Cell information (i.e. the current camping EPS cell ID); UE International Mobile Subscriber Identity (IMSI); UE Globally Unique Temporary Identity (GUTI); and GAN Classmark, including indication of support for VoLGA service.

[0061] If VANC 510 accepts the registration attempt, the VANC in some embodiments may initiate (in step 3a) the activation of a dedicated EPS bearer for the VoLGA signaling channel using the Rx interface to the PCRF, per the procedures in 3GPP 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 VANC 510 to the Policy and Charging Rules Function (PCRF) in the Access Attempt (AA)-Request message per 3GPP TS 29.214, "Policy and Charging Control over Rx Reference Point", incorporated by reference and hereinafter, "TS 29.214".

[0062] VANC 510 then responds (in step 3b) with a register accept (e.g., GA-RC

REGISTER ACCEPT) message. In some embodiments, the message includes VoLGA specific system information, including one or more of the followings: (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 VANC 510. The UE stores the list of the E-UTRAN TAs that is served by the VANC. In some embodiments, UE 505 is required to notify the VANC 510 when the UE 505 moves to a new serving E-UTRAN TA that is not in the list. The secure tunnel (optional) and TCP connection are not released and are maintained as long as UE 505 is registered to this VANC 510. If the VoLGA LAI is not the same as the stored GERAN/UTRAN LAI, the UE 505 performs, in some embodiments, the CS domain location area update procedure via the VoLGA control plane.

[0063] Alternatively, VANC 510 may reject (in step 4) the request. In this case, the

VANC responds with a register reject (e.g., GA-RC REGISTER REJECT) message indicating the reject cause. In some embodiments, the secure tunnel (optional) and TCP connection are released; the UE 505 may attempt re-discovery and re -registration under certain circumstances.

[0064] If VANC 510 wishes to redirect UE 505 to (another) VANC (not shown), the

VANC responds (in step 5) with a register redirect (e.g., GA-RC REGISTER REDIRECT) message providing the Fully Qualified Domain Name (FQDN) or IP address of the target VANC. In this case, the secure tunnel (optional) and TCP connection are released and UE 505 attempts registration on the new VANC.

IV. SIGNALLING CONNECTION FAILURE RECOVERY

[0065] 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 III. 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. [0066] The following sections describe a mechanism for a VANC to notify a UE of a signalling connection failure so that the UE can recover and re-connect to the VANC. 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).

[0067] 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

[0068] 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.

[0069] 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 3GPP TS 43.318.

B. VANC-Initiated Re-Synchronization on TCP failure detection

[0070] Figure 6 illustrates a procedure for a VANC-initiated re-synchronization in some embodiments. As shown, VANC 610 (in step 1) detects a TCP connection failure to a UE 605. For instance, VANC 610 receives a TCP reset or no TCP acknowledgement when the VANC attempts to send a message to UE 605. 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.

[0071] Once the TCP connection failure is detected, VANC 610 initiates the recovery of the TCP connection to UE 605. This ensures that UE 605 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 610 initiates the recovery by sending (in step 2) a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message to UE 605.

[0072] In some embodiments, VANC 610 sends the sync command message to the UE

605 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 610 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 610 uses a UDP transport (in step 2) in order to send the sync command message to the UE 605. VANC 610 sends the sync command message to UE 605 using the UDP transport by specifying a stored UE IP address and a pre-defined UDP port number. In some embodiments, VANC 610 uses the UDP transport solely for sending such sync command message to UE 605 when a TCP connection failure occurs.

[0073] UE 605 having received the sync command (e.g., GA-RC SYNCHRONIZATION

COMMAND) message from VANC 610 attempts to set up a TCP connection or re-establish the failed TCP connection to the VANC. As shown in Figure 6, UE 605 (in step 3) successfully reestablishes the TCP connection to the assigned VANC 610. After re-establishing the TCP connection, UE 605 (in step 4) sends a synchronization information (e.g., GA-RC SYNCHRONIZATION INFO) message (hereinafter, "sync info message") to the VANC 610 to synchronize the UE state information.

[0074] VANC 610 (in step 5) updates the UE registration status of UE 605 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").

[0075] In the procedure described above, as the VANC 610 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). As the VANC 610 initiates the TCP connection recovery, the UE 605 in some embodiments does not have to periodically send a keep-alive message at these different levels. This allows the UE 605 to save the resources that the UE would otherwise spend to test the TCP connection. Also, this recovery procedure allows both the UE 605 and the VANC 610 to proactive Iy initiate the TCP connection recovery when a TCP connection failure is detected.

[0076] Figure 7 illustrates a process 700 for recovering from a signalling connection failure. The process is performed by VANC 610 in some embodiments. As shown, process 700 detects (at 705) a TCP connection failure to a UE. Having detected the connection failure, the process then initiates the recovery of the TCP connection by sending (at 710) a sync command message to the UE with the connection failure. As mentioned above, the sync command message may be sent to the UE immediately upon detection of the connection failure. Also, the sync command message may be sent after a period of time when resources are available. In some embodiment, since a TCP connection failure occurred, the sync command message may be sent to the UE using a UDP transport specifying a stored UE IP address and a pre-defined UDP port number.

[0077] The sync command message causes the UE to attempt re-establishment of the

TCP connection. After successfully re-establishing the TCP connection, the UE sends a sync info message. Process 700 receives (at 720) the sync info message sent by the UE. The process then ends.

C. VANC-Initiated Re-Synchronization at Paging Request [0078] Figure 8 conceptually illustrates a procedure for a VANC-initiated re- synchronization at paging request in some embodiments. As shown, VANC 810 (in step 1) detects a TCP connection failure for a UE 805 For instance, VANC 810 receives a TCP reset or no TCP acknowledgement when it attempts to send a message to UE 805. The signalling connection failure may also be due to the failure of a VANC 810 subsystem that is responsible for supporting one or more TCP connections.

[0079] VANC 810 marks (in step 1) a state of the UE 805 as "inactive" or in some other appropriate designation that special handling of the UE is required if VANC 810 needs to send a message to the UE. As UE 805 (in step 2) has not detected the signalling channel failure, the UE continues to be in "idle" mode. At a later time, VANC 810 receives (in step 2) a RANAP PAGING REQUEST message (e.g., for a mobile terminated voice or SMS call) for the same UE 805 from the MSC 815.

[0080] Next, VANC 810 checks (in step 3) the state of UE 805 and finds the UE's state to be "inactive" or with another appropriate designation as described above. Having received a paging message and determined that the UE's state is inactive, VANC 810 then initiates recovery of the failed TCP connection. This ensures that UE 805 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).

[0081] As shown in Figure 8, VANC 810 initiates the recovery by sending (in step 4) a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message to the UE 805. In the sync command message, VANC 810 indicates to UE 805 that the UE is getting paged (e.g.., by using a Paging Indicator IE). Since the TCP connection has failed, VANC 810 uses a UDP transport in order to send the sync command message to UE 805. VANC 810 sends the sync command message to the UE 805 using the UDP transport by specifying a stored UE IP address and a pre-defined UDP port number. In some embodiments, VANC 810 uses the UDP transport solely for sending such sync command message to UE 805 when a TCP connection failure occurs.

[0082] UE 805 having received the sync command (e.g., GA-RC SYNCHRONIZATION

COMMAND) message from VANC 810 attempts to set up a TCP connection or re-establish the failed TCP connection to the VANC. As shown in Figure 8, UE 805 successfully re-establishes (in step 5) the TCP connection to the assigned VANC 810. UE 805 sends (in step 6) a sync info message to the VANC 810 to synchronize the UE state information. The VANC 810 updates (in step 7) the UE registration status based on the received information and resets the state of the UE 805 to "active" or another appropriate designation that the indicates UE 805 is now in the normal registered state.

[0083] Since a "paging indicator" was included in the sync command (e.g., GA-RC

SYNCHRONIZATION COMMAND) message, UE 805 moves (in step 8) into a "dedicated" mode and sends an initial direct transfer (e.g., GA-RRC INITIAL DIRECT TRANSFER) message to VANC 810. VANC 810 converts the initial direct transfer message to a RANAP message (e.g., RANAP INITIAL UE message). VANC 810 forwards (in step 9) the RANAP INITIAL UE message to MSC 815. In some embodiments, the rest of the steps involved in the call setup are similar or exactly the same as the steps specified in 3GPP TS 44.318.

[0084] In the procedure described above, as the VANC 710 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). As the VANC 710 initiates the TCP connection recovery, the UE 705 in some embodiments does not have to periodically send a keep-alive message at these different levels. This allows the UE 705 to save the resources that the UE would otherwise spend to test the TCP connection. Also, this recovery procedure allows both the UE 705 and the VANC 710 to proactive Iy initiate the TCP connection recovery when a TCP connection failure is detected.

[0085] In some embodiments, the VANC-initiated re-synchronization at paging request procedure minimizes a number of sync command messages that a VANC needs to send to UEs with connection failures. For instance, when, prior to the VANC receiving a RANAP PAGING REQUEST from the MSC for a UE, the UE initiates a mobile originated call (e.g., voice or SMS), periodic location update, or supplementary services call, the UE may (1) detect that a TCP signalling channel connection has failed (e.g., based on receipt of a TCP reset when attempting to send a message to the VANC), and (2) initiate recovery by re-establishing the TCP signalling channel connection and sending a sync info (e.g., GA-RC SYNCHRONIZATION INFO) message to the VANC. Such UE-initiated synchronization after TCP connection re-establishment is described in 3GPP TS 43.318. Hence, in procedure illustrated in Figure 8, the number of messages sent by the VANC may be minimized by the UE initiating recovery of the connection failure when the UE initiates the mobile originated call, periodic location update, or supplementary service call.

[0086] In some embodiments, upon receiving a sync info message from a UE in an

"inactive" state, a VANC may clear the "inactive" state of the UE. For instance, the VANC may update a registration status of the UE based on the received message and reset the state of the UE state as "active".

[0087] Figure 9 conceptually illustrates a process 900 for recovering from a signalling connection failure at paging request. The process is performed a VANC such as VANC 810 in some embodiments. As shown, the process detects (at 905) a TCP connection failure to a UE. Having detected the connection failure, process 900 then marks (at 910) the state of the UE with the connection failure as "inactive". As the UE has not detected the signalling channel connection failure, the UE continues to be in "idle" mode.

[0088] The process receives (at 915) a paging request (e.g., for a mobile terminated voice or SMS call) for the UE from the MSC. The process then checks (at 920) the state of the UE and determines that the UE's state is marked as "inactive". The process sends (at 925) a sync command message to UE. In some embodiment, the sync command message is sent to the UE using a previously stored UE IP address, a UDP transport, and a pre-defined UDP port number. As mentioned above, the sync command message in some embodiments indicates to the UE that the UE is getting paged (e.g.., by including a Paging Indicator IE).

[0089] The sync command message causes the UE to attempt re-establishment of the

TCP connection. After successfully re-establishing the TCP connection, the UE sends a sync info message. The process receives (at 935) the sync info message from the UE to synchronize the UE state information. The process updates (at 940) the UE registration status based on the received information. The process marks (at 945) the state of the UE as "active".

[0090] Since a "paging indicator" was included in the sync command message, the UE moves into a "dedicated" mode and sends an initial direct transfer message. The process receives (at 950) the initial direct transfer message from the UE and converts the message to a RANAP INITIAL UE message. The process sends (at 955) the RANAP INITIAL UE message to the MSC. As mentioned above, in some embodiments, the rest of the steps involved in the call setup are similar or exactly the same as that specified in 3GPP TS 44.318.

[0091] Figure 10 illustrates a process 1000 for recovering from a signalling connection failure. Process 1000 is performed by the UE 605 or 805 in some embodiments. The process starts (at 1005) when a sync command message is received from a VANC. As mentioned above, in some embodiments, the VANC may send the message in response to receiving a RANAP PAGING REQUEST message from a MSC.

[0092] Having received the sync command message, the process initiates (at 1010) a

TCP connection re-establishment. Once the TCP connection is reestablished, the process sends (at 1015) a sync info message to the VANC to synchronize a UE state information. In some embodiments, the process determines (at 1020) whether a paging indicator is included in the sync command message. When the paging indicator is not included in the sync command message, the process ends. Otherwise, when the paging indicator is included in the sync command message, the process moves UE into a "dedicated" mode and sends (at 1025) an initial direct transfer message the VANC.

D. Applicability of Connection Recovery Procedures to GAN

[0093] Sub-Sections A-C above described recovery procedures on TCP connection failure in relation to VoLGA. The recovery procedures described above are also applicable to GAN. In GAN, a GANC performs similar operations as in the VoLGA. For instance, upon detecting the TCP connection failure, a GANC may (1) immediately send a sync command (e.g., GA-RC SYNCHRONIZATION COMMAND) message to a UE, (2) wait for a period of time until resources are available and then send the sync command message to the UE, or (3) mark a signalling channel of the UE as "inactive" but not immediately send the sync command message to the UE. Rather, the GANC sends out the sync command message when the GANC receives a paging request for the UE from the MSC.

[0094] Having received the sync command message, the UE operating in GAN may initiate a TCP connection re-establishment. Since the TCP connection has failed, the GANC uses a UDP transport in order to send the sync command message to the UE. Similar to what described in relation with Figure 3 and 4 for VoLGA, in GAN the protocol architectures of the UE and the GANC include protocol layers TCP or UDP. The GANC sends the sync command message to the UE using the UDP transport by specifying a stored UE IP address and a predefined UDP port number. In some embodiments, the GANC uses the UDP transport solely for sending such sync command message to the UE when a TCP connection failure occurs. Once the TCP connection is reestablished, the UE may send a sync info (e.g., GA-RC SYNCHRONIZATION INFORMATION) message to the GANC to synchronize a UE state information. In some embodiments, when a "paging indicator" is included in the sync command message, the UE may move into a "dedicated" mode and sends an initial direct transfer message to the GANC.

[0095] Furthermore, in some embodiments, all recovery procedures described above in

Sub-Sections A-C with respect to VoLGA are applicable to the GAN by replacing "VoLGA" with "GAN" and replacing "VANC" with "GANC".

V. COMPUTER SYSTEM

[0096] Many of the above-described protocol stacks, processes, methods, and functionalities are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more computational or processing element(s) (or unit(s)) (such as processors or other computational elements like ASICs and FPGAs), the instructions 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 computational elements (e.g., UE, VANC, GANC, eNB, etc.). Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0097] In this specification, the term "software" includes 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.

[0098] Figure 11 conceptually illustrates a computer system with which some embodiments of the invention are implemented. The computer system 1100 includes a bus 1105, a processor 1110, a system memory 1115, a read-only memory 1120, a permanent storage device 1125, input devices 1130, and output devices 1135.

[0099] The bus 1105 collectively represents all system, peripheral, and chipset buses that support communication among internal devices of the computer system 1100. For instance, the bus 1105 communicatively connects the processor 1110 with the read-only memory 1120, the system memory 1115, and the permanent storage device 1125.

[00100] From these various memory units, the processor 1110 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) 1120 stores static data and instructions that are needed by the processor 1110 and other modules of the computer system. The permanent storage device 1125, 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 1100 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 1125. Some embodiments use one or more removable storage devices (flash memory card or memory stick) as the permanent storage device.

[00101] Like the permanent storage device 1125, the system memory 1115 is a read-and- write memory device. However, unlike storage device 1125, 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.

[00102] Instructions and/or data needed to perform processes of some embodiments are stored in the system memory 1115, the permanent storage device 1125, the read-only memory 1120, 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 1110 retrieves instructions to execute and data to process in order to execute the processes of some embodiments.

[00103] The bus 1105 also connects to the input and output devices 1130 and 1135. The input devices enable the user to communicate information and select commands to the computer system. The input devices 1130 include alphanumeric keyboards and cursor-controllers. The output devices 1135 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 11, bus 1105 also couples computer 1100 to a network 1165 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).

[00104] Any or all of the components of computer system 1100 may be used in conjunction with the invention. For instance, some or all components of the computer system described with regards to Figure 11 comprise some embodiments of the UE, VANC, GANC, eNB, etc. 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.

[00105] 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, read-only compact discs (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.

[00106] 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.

[00107] While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.

VI. ACRONYMS AND ABBREVIATIONS

3GPP 3 ^r Generation Partnership Project

3GPP TS 3 ^rd Generation Partnership Project Technical Specifications

AA Access Attempt

AAA Authentication, Authorization and Accounting

AMR Adaptive Multi-Rate

AP Access Point

BSC Base Station Controller

BSS Base Station Subsystem

CBC Cell Broadcast Center

CC Call Control

CM Connection Management CN Core Network

CS Circuit Switched

DTM Dual Transfer Mode

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-PSR Generic Access - Packet Switched Resources

GA-RC Generic Access - Resource Control

GA-RRC Generic Access Radio Resource Control

GERAN GSM EDGE Radio Access Network

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

GSM Global System for Mobile communications

GUTI Globally Unique Temporary Identity

GW Gateway

HLR Home Location Register

HSS Home Subscriber Server

IE Information Element

IKE Internet Key Exchange

IKEv2 IKE Version 2

IMEI International Mobile station Equipment Identity

IMS IP Multimedia Subsystem

IMSI International Mobile Subscriber Identity

IP Internet Protocol

IPSec Internet Protocol Security

IPSec ESP Internet Protocol Security Encapsulating Security Payload LAI Location Area Identity

LTE Long Term Evolution

ME Mobile Equipment

MME Mobility Management Entity

MS Mobile Station

MSC Mobile Switching Center

NAS Non-Access Stratum

PC Personal Computer

PCRF Policy and Charging Rules Function

PCS Personal Communication Services

PDN Packet Data Network

PDN-GW Packet Data Network Gateway

PLMN Public Land Mobile Network

PS Packet Switched

PSTN Public Switched Telephone Network

QCI QoS Class Identifier

QoS Quality of Service

RAM Random- Access Memory

RANAP Radio Access Network Application Part

RLC Radio Link Control

RNC Radio Network Controller

RR Resource Record

RRC Radio Resource Control

RTP Real Time Protocol

SAE System Architecture Evolution

SAI System Architecture Evolution

SGSN Serving GPRS Support Node

SMLC Serving Mobile Location Center

SM Session Management

SMS Short Message Service

S-GW Serving Gateway TA Tracking Area

TCP Transmission Control Protocol

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

VoIP Voice over Internet Protocol

VoLGA Voice over LTE via Generic Access