WO2018057473A1

WO2018057473A1 - Support for session continuity and control plane signaling in multi-radio access technology environments

Info

Publication number: WO2018057473A1
Application number: PCT/US2017/052111
Authority: WO
Inventors: Jing Zhu
Original assignee: Intel Corporation
Priority date: 2016-09-22
Filing date: 2017-09-18
Publication date: 2018-03-29

Abstract

A Local Access Gateway (LA-GW) may be used to establish an IPSec tunnel over a network, such as the Internet, through an LTE link. When a UE moves out of coverage of WiFi and/or its current serving base station, the UE can continue a Local Access session through the IPSec tunnel. In another embodiment, a UE-based LWIP flow control mechanism communicates control messages (e.g., LWIP status reports) over an LWIP tunnel using a WiFi link. Control packets (e.g., packets carrying the LWIP status report) may be identified based on an Internet Protocol (IP) and/or port number that is used for the control packets.

Description

SUPPORT FOR SESSION CONTINUITY AND CONTROL

PLANE SIGNALING IN MULTI-RADIO ACCESS TECHNOLOGY ENVIRONMENTS

RELATED APPLICATIONS

The present application claims the benefit of U.S. Provisional Patent Application No.

62/398,206, which was filed on September 22, 2016 and U.S. Provisional Patent Application No. 62/401,025, which was filed on September 28, 2016, the contents of which are hereby incorporated by reference as though fully set forth herein.

BACKGROUND

Wireless cellular telecommunication networks include Radio Access Networks (RANs) that enable User Equipment (UE), such as smartphones, tablet computers, laptop computers, etc., to connect to a core network. An example of a wireless telecommunications network may include an Evolved Packet System (EPS) that operates based on 3rd Generation Partnership Project (3GPP) Communication Standards. In a cellular network, UEs typically communicate with base stations using channels corresponding to a licensed spectrum of radio frequencies (e.g., a spectrum of radio frequencies designated for cellular network communications).

More recently, technologies have been implemented to enable unlicensed spectrum to be used to assist or to supplement the network connectivity provided via the licensed spectrum. One such technology is "Long Term Evolution (LTE) Wireless Local Area Network (WLAN) integration with Internet Protocol Security Tunnel (IPSec)" (LWIP). LWIP may enable WiFi RANs (i.e., unlicensed spectrum RANs) to be more optimally integrated into an LTE Access network. In particular, LWIP may be used to provide load balancing between LTE and WiFi through IP level switching or aggregation just above the Packet Data Convergence Protocol (PDCP) layer.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments described herein will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals may designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Fig. 1 is a diagram illustrating an example system in which systems and/or methods described herein may be implemented;

Fig. 2 is a diagram illustrating an example architecture relating to LWIP

communications; Fig. 3 is a flow chart illustrating an example process for communicating flow control messages over an LWIP tunnel;

Fig. 4 is a signal diagram illustrating RRC signaling for an example setup procedure;

Fig. 5A is a diagram illustrating a protocol stack for LWIP encapsulation protocol (LWIPEP) communications;

Fig. 5B is a diagram illustrating a protocol stack for an LWIP tunnel that does not use LWIPEP;

Fig. 6 is a diagram illustrating an example architecture of a RAN-based LTE/WiFi integration (LWIP or LTE-WLAN aggregation (LWA)) to support Local Access;

Fig. 7 is diagram illustrating an example network in which a Local Access Gateway (LA- GW) is used to support session continuity;

Fig. 8 is a diagram illustrating an example of a user plane protocol stack for the architecture shown in Fig. 6;

Fig. 9 is a diagram illustrating an example packet format for an enhanced RAN-based Local Access (RLA) user plane packet (e.g., a packet format for the architecture shown in Fig.

6);

Fig. 10 is a signal diagram illustrating RRC signaling for an example setup procedure for enhanced RAN-based Local Access (RLA) communications;

Fig. 11 illustrates example components of a device in accordance with some

embodiments;

Fig. 12 illustrates example interfaces of baseband circuitry in accordance with some embodiments; and

Fig. 13 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The following detailed description refers to the accompanying drawings. The same reference numbers in different drawings may identify the same or similar elements. It is to be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents. Traffic flow control refers to managing the rate (or other parameter) of data transmission between two nodes. Flow control in LWIP may potentially be implemented as network-based flow control or UE-based flow control. In network-based flow control, WLAN network elements, e.g. Wi-Fi Access Point/Controller, may report periodically about the WLAN queue status or the packets (e.g., the sequence number) that have been successfully transmitted to the UE. In UE-based flow control, the UE may report periodically, back to the base station, about the packets that have been received successfully by the UE (e.g., as a status report message). The UE-based flow control approach may have no impact on the WLAN, therefore support a legacy deployment with no infrastructure change. Since LWIP is typically used in legacy WLAN situations, the LWIP flow control may be UE-based.

In some embodiments, a UE-based LWIP flow control mechanism communicates control messages (e.g., LWIP status reports) over an LWIP tunnel using a WiFi link. Control packets (e.g., packets carrying the LWIP status report) may be identified based on an Internet Protocol (IP) and/or port number that is used for the control packets.

In other embodiments, a Local Access Gateway (LA-GW) may be used to establish an

IPSec tunnel over a network, such as the Internet, through an LTE link. When a UE moves out of coverage of WiFi and/or its current serving base station, the UE can continue its Local Access session through the IPSec tunnel.

Fig. 1 is a diagram illustrating an example system 100 in which systems and/or methods described herein may be implemented. As illustrated, system 100 may include a

telecommunications network in which LTE cellular and WLAN (e.g., WiFi) RANs co-exist. The telecommunications network may thus be a multi-radio access technology environment (i.e., the network includes multiple, different RANs).

LWIP may be used to provide transparent aggregation of the LTE/WLAN radio links. As shown in Fig. 1, UE 110 may connect to cellular network 120 via either an LTE cellular link or, through WLAN 115, via a WiFi-based radio link (e.g., using unlicensed WiFi spectrum). Other devices, such as a non-cellular device 112 (e.g., a tablet computer) may continue to use WLAN 115 to connect to an external network, such as packet data network (PDN) 150 (e.g., the

Internet). The use of LWIP may not impact the operation of non-cellular device 112 and WLAN 115. The link aggregation of the LTE/WLAN links may be transparent to core elements of cellular network 120 (i.e., to Mobility Management Entity (MME) 142, Serving Gateway (SGW) 144, Home Subscriber Server (HSS) 146, and packet data network gateway (PGW) 148).

WLAN 115 may represent one or more access devices, such as WiFi access point(s). WLAN 115 may be connected to PDN 150. Communication sessions with non-cellular devices, such as non-cellular device 112, may be routed via WLAN 115 to PDN 150. WLAN 115 may also be connected to base stations of cellular network 120, such as Evolved NodeB (eNB) 135.

UE 110 may include a portable computing and communication device, such as a personal digital assistant (PDA), a smart phone, a cellular phone, a laptop computer with connectivity to the wireless telecommunications network, a tablet computer, etc. UE 110 may also include a computing and communication device that may be worn by a user (also referred to as a wearable device) such as a watch, a fitness band, a necklace, glasses, an eyeglass, a ring, a belt, a headset, or another type of wearable device. UE 110 may also include radio circuitry capable of connecting to both cellular network 120 and WLAN 115. Non-cellular device 112 may represent a computing and communication device capable of connecting to WLAN 115.

eNBs 135 may implement the RAN of cellular network 120. eNBs 135 may provide the air (radio) interface for wireless connections with UEs 110. The core portion of cellular network 120 may be an IP -based network. The core portion may include a number of network devices, including MME 142, SGW 144, HSS 146, and PGW 148. Through the core portion, UEs 110 may communicate with an external network, such as PDN 150. LWIP may be implemented in a manner such that the WLAN 115 is effectively hidden from the core network.

eNBs 135 may each include one or more network devices that receive, process, and/or transmit traffic destined for and/or received from UE 110 (e.g., via the air interface). eNBs 135 may include antennas and other logic necessary to wirelessly communicate with UEs 110. eNBs 135 may additionally communicate with other network devices in the core portion of cellular network 120. Although referred to as an "eNB," eNB 135 may generally represent any base station and/or RAN node that is implemented in a cellular network as a network device designed to wirelessly communicate with UEs.

MME 142 may include one or more computation and communication devices that act as a control node for eNBs 135 and/or other devices that provide the air interface for the wireless telecommunications network. For example, MME 142 may perform operations to register UEs 110 with the cellular network, to establish user plane bearer channels (e.g., traffic flows), to hand off UE 110 to different eNBs 135, MME, or another network, and/or to perform other operations. MME 142 may perform policing operations on traffic destined for and/or received from UEs 110.

SGW 144 may aggregate traffic received from one or more eNBs 135 and may send the aggregated traffic to an external network or device via PGW 148. Additionally, SGW 144 may aggregate traffic received from one or more PGWs 148 and may send the aggregated traffic to one or more eNBs 135. SGW 144 may operate as an anchor for the user plane during inter-eNB handovers and as an anchor for mobility between different telecommunication networks. HSS 146 may include one or more devices that may manage, update, and/or store, in a memory associated with HSS 146, profile information associated with a subscriber (e.g., a subscriber associated with UE 110). The profile information may identify applications and/or services that are permitted for and/or accessible by the subscriber; a Mobile Directory Number (MDN) associated with the subscriber; bandwidth or data rate thresholds associated with the applications and/or services; and/or other information. The subscriber may be associated with UE 110. Additionally, or alternatively, HSS 146 may perform authentication, authorization, and/or accounting operations associated with the subscriber and/or a communication session with UE 110.

PGW 148 may include one or more network devices that may aggregate traffic received from one or more SGWs 144, and may send the aggregated traffic to an external network. PGW 148 may also, or alternatively, receive traffic from the external network and may send the traffic toward UE 110 (via SGW 144 and/or eNB 135).

PDN 150 may include one or more packet networks, such as an Internet Protocol (IP) based packet network. PDN 150 may include a wide area network (WAN), a local area network (LAN), and/or combinations of WANs and LANs. PDN 150 may be or include, for example, the Internet.

A number of communication interfaces, between the various components of the core portion of cellular network 120, are illustrated in Fig. 1. The communication interfaces may include 3GPP standardized interfaces. As illustrated, the interfaces may include: an Sl-U interface between eNB 135 and SGW 144, an Sl-MME interface between eNB 135 and MME 142, an S6a interface between MME 142 and HSS 146, and an S5/S8 interface between SGW 144 and PGW 148.

The quantity of devices and/or networks, illustrated in Fig. 1, is provided for explanatory purposes only. In practice, there may be additional devices and/or networks; fewer devices and/or networks; different devices and/or networks; or differently arranged devices and/or networks than illustrated in Fig. 1. Alternatively, or additionally, one or more of the devices of system 100 may perform one or more functions described as being performed by another one or more of the devices of system 100.

Fig. 2 is a diagram illustrating an example architecture relating to LWIP

communications. In particular, communication layers associated with UE 110 and eNB 135 are illustrated. In LWIP, eNB 135 may act as the mobility anchor for the communications, and the management of the LTE cellular and WLAN links may be transparent to the cellular core network (e.g., transparent to MME 142, SGW 144, HSS 146, PGW 148, etc.). As shown in Fig. 2, the communication stack for control plane traffic (e.g., over the Sl- MME interface), through e B 135, may include Radio Resource Control (RRC) layer 202, Packet Data Convergence Protocol (PDCP) layer 204, Radio Link Control (RLC) layer 206, Media Access Control (MAC) layer 208, and Physical (PHY) layer 210. The corresponding communication stack for the control plane traffic, at UE 110, may include PHY layer 212, MAC layer 214, RLC layer 216, PDCP layer 218, RRC layer 220, and Non- Access Stratum (NAS) layer 222. The control plane traffic may particularly include RRC messages and NAS messages.

The communication stack for the LTE cellular user plane traffic, through eNB 135, may include IP layer 230, PDCP layer 232, RLC layer 234, MAC layer 236, and PHY layer 238. The corresponding communication stack for the user plane traffic, at UE 110, may include PHY layer 212, MAC layer 214, RLC layer 240, PDCP layer 242, and IP layer 244. The final destination for the user plane traffic may be UE applications, illustrated as app/higher layer component 246 in Fig. 2. Alternatively, user plane traffic, received over the cellular link, may be transmitted via WLAN 115. In UE 110, a WLAN PHY layer 260 and WLAN MAC layer 265 may additionally be implemented to provide an interface to WLAN 115.

As mentioned, through LWIP, user plane data may be transmitted, between eNB 135 and UE 110, using either the LTE cellular user plane link (Sl-U), or the WLAN (e.g., WiFi based) link. To use the WLAN link, LWIP Encapsulation Protocol (LWIPEP) components 250 and 251 may be implemented, such as within IP layers 230 and 244, respectively. The user plane data may be transmitted over the WLAN link using IPSec tunnels as an "LWIP Tunnel". For instance, user plane IP packets, for the data radio bearer (DRBs) that would normally be used for the cellular LTE link, may be encapsulated and transmitted through the IPSec tunnel and via a WLAN link. LWIP Security Gateway (LWIP-SeGW) 255, which may be implemented within eNB 135 or outside of eNB 135, may manage the IPSec tunnels. On the WLAN side of LWIP gateway 255, a public IP address 270, which may be provided by eNB 135, may be presented to the WLAN. A private IP address 272, used for the cellular core network, may be presented to the eNB-side of LWIP gateway 255.

In operation, for the architecture shown in Fig. 2, UE 110 may establish a LWIP tunnel (i.e., an IPSec tunnel encapsulating IP packets from DRBs) with eNB 135 via WLAN 115 and through LWIP-SeGW 255. This architecture may be transparent to the deployment of the WLAN (i.e., no changes may be required to WLAN 115). Additionally, traffic steering, link aggregation, and multi-Radio Access Technology (RAT) radio resource management may take place over the top of the cellular LTE user plane protocol stack (above PDCP). WLAN/3GPP link aggregation may be transparent to the 3GPP core network elements (e.g., transparent to the operation of MME 142, SGW 144, HSS 146, and PGW 148). As previously mentioned, a UE-based LWIP flow control mechanism is described herein in which control messages (e.g., LWIP status reports) are delivered over an LWIP tunnel using a WiFi link.

Fig. 3 is a flow chart illustrating an example process 300 for communicating flow control messages over an LWIP tunnel.

Process 300 may include exchanging, via the LTE link, LWIP control IP addresses and port numbers that are to be used to communicate control messages over the LWIP tunnel (block 310). In one implementation, the LWIP control IP addresses and port numbers may be exchanged using the RRC cellular radio link between eNB 135 and UE 110. The LWIP control IP addresses and port numbers may include a particular eNB IP address and port number that is selected by eNB 135 to be used for the control messages. The eNB IP address and port number may be transmitted to UE 110. Additionally, UE 110 may select a unique port number that is to be used, by the UE, for the control messages. This selected port number may be communicated to eNB 135. The exchange of the IP addresses and port numbers may be performed during initial setup of the LWIP tunnel.

Process 300 may further include forming the LWIP tunnel, via the WLAN, between UE 110 and eNB 135 (block 320). The LWIP tunnel may be used to send both control traffic and user plane traffic.

Process 300 may further include identifying control messages, that are transmitted via the LWIP tunnel, based on the IP addresses and port numbers (block 330). For example, a control message sent from UE 110 to eNB 135 may be associated with a source address pair and a destination address pair. Source address pair may include: the LTE IP address of the UE and a control message port number selected by the UE. Similarly, the destination address pair may include: the LWIP control IP address of the eNB and a control message port number. eNB 145 may identify the message as a control message based on the source control message port number of the UE. A control message sent from eNB 135 to UE 110 may similarly be associated with a source address pair and a destination address pair, where the source address pair may include the

LWIP control IP address of the eNB and the control message port number of the eNB, and the destination address pair may include the LTE IP address of the UE and the control message port number of the UE.

In one implementation, the control messages may be transmitted as User Data Protocol

(UDP) packets. In this implementation, the port numbers selected by the eNB and UE may correspond to UDP port values.

In some implementations, the concepts discussed above can be used to communicate LWIP control messages over the LTE link. In this situation, the UE may have two different UDP connections, associated with different UDP port numbers, for the LWIP control messages. One of the UDP port numbers may be used when sending control messages over the LWIP tunnel, and the other may be used when sending LWIP control messages over the LTE link.

An example setup procedure for an LWIP tunnel (e.g., blocks 310 and 320 of Fig. 3) will next be described with reference to Fig. 4. Fig. 4 is a signal diagram illustrating RRC signaling of an example setup procedure for the LWIP tunnel.

The signal diagram in Fig. 4 may be based on the existing LWIP tunnel setup procedure to support local access. For instance, communications 405-435 may be based on the existing LWIP tunnel setup procedure. These communications may include e B 135 initially

transmitting a "RRCConnectionReconfiguration" message (at 405) to UE 110, which may responds with a "RRCConnectionReconfigurationComplete" message (at 410). UE 110 may record measurements relating to the quality of the WLAN connection, such as the received signal strength. UE 110 may transmit a message reporting the WLAN measurements (at 415, "WLAN Measurements"). eNB 135 may potentially reconfigure the connection based on the measurement report (at 420 and 425, "RRCConnectionReconfiguration" and

"RRCConnectionReconfigurationComplete"). UE 110 may connect/associate to WLAN 115 (at 430) and, in response to the connection with WLAN 115, report the connection to eNB 135 (at 435, "WLANConnectionStatusReport").

eNB 135 may send an additional "RRCConnectionReconfiguration" message, which may include the parameters necessary to establish an IPSec tunnel over WLAN and may include configuration information for the data bearers that are to use the IPSec tunnel (at 440).

Additionally, the "RRCConnectionReconfiguration" message may include the LWIP control IP address and UDP port number that are to be used by the UE to send control messages, over the LWIP tunnel. The control messages may be sent using UDP.

If UE 110 supports local access, the UE may respond by sending the

"RRCConnectionReconfigurationComplete" message, including a parameter that includes the local IP address (e.g., the WiFi IP address that was assigned by the WLAN) of UE 110 (at 445). The message may also include a UDP port number, such as a UDP port number selected by UE 110, that the UE will use for sending control messages over the LWIP tunnel (i.e., the source port number for UDP packets sent by UE 110).

Based on the configuration information exchanged in messages 405-445, the LWIP tunnel may be established, over the WLAN, between UE 110 and eNB 135 (at 450, "LWIP Tunnel between UE and eNB via WLAN").

The LWIP Encapsulation Protocol (LWIPEP) is a protocol for encapsulating data over the LWIP tunnel. In some situations, it may be desirable to use LWIPEP to communicate data, such as user plane data, between UE 110 and eNB 135. Alternatively, the LWIP tunnel may be used without using LWIPEP.

Fig. 5A is a diagram illustrating a protocol stack 500 for LWIPEP communications. As shown, protocol stack 500 may include LWIP data (control or data packets) layer 505, UDP (or Transmission Control Protocol (TCP)) layer 510, LTE IP layer 515, LWIPEP layer 520, IPSec (LWIP Tunnel) layer 525, and WLAN IP layer 530. In protocol stack 500, the top layer (LWIP data layer 505) represents the innermost layer of encapsulated data and the bottom layer (WLAN IP layer 530) represents the outer layer of encapsulated data. For example, an LWIP data or control packet (layer 505) may be encapsulated as payload data within a UDP packet (layer 510), which may be encapsulated as payload data within the LTE IP layer 515, and so on, through the outermost layer (WLAN IP layer 530).

Consistent with aspects described herein, with protocol stack 500, one technique for indicating whether a particular packet is a control packet or a user data packet (in addition to or as an alternative to using a particular IP address and port number) may include using a particular bit, in a data radio bearer (DRB) identifier (ID) field of the LWIPEP header (or trailer). The DRB ID field may be a field in the LWIPEP layer 520 of protocol stack 500. In some implementations, a single bit may be used to indicate whether the packet is a control packet or a user data packet. Alternatively, multiple bits may be used. Alternatively or additionally, instead of using bits from the DRB ID field, a new field (e.g., the "C/U" field) may be defined to indicate whether the packet is a control packet for user data packet.

Fig. 5B is a diagram illustrating a protocol stack 550 for an LWIP tunnel that does not use LWIPEP. As shown, protocol stack 550 may include LWIP data (control or data packets) layer 555, UDP (or TCP) layer 560, LTE IP layer 565, IPSec (LWIP Tunnel) layer 570, and WLAN IP layer 575. As with protocol stack 500, with protocol stack 550, the top layer (LWIP data layer 555) represents the innermost layer of encapsulated data and the bottom layer (WLAN IP layer 575) represents the outer layer of encapsulated data. With protocol stack 550, whether a packet (i.e., the packet of layer 555) is a control packet or user data packet may be determined based on the IP address and port value for the source and/or destination fields of layer 560. For example, for a control message sent from UE 110 to eNB 135, eNB 135 may determine that the packet represents a control message based on the source UDP port of the packet in layer 560.

A transport mechanism to deliver control data via an LWIP tunnel, particularly including techniques for identifying the control data, was described above. The control data can include packets transmitted from UE 110 to eNB 135. Alternatively or additionally, control data can be transmitted from eNB 135 to UE 110. For example, eNB 135 may transmit probe messages, to UE 110, to gauge the quality of the WLAN link. The probe messages may be transmitted as control packets over the LWIP tunnel. As another example, UE 110 may transmit LWIP status report messages to eNB 135. Status report messages may be used to implement flow control for data transmitted via the WLAN.

In one implementation, the status report messages may include, for each of a number of DRBs that are included in the status report: an identifier of the DRB (DRB ID); an indication of a first missing sequence number (FMS); an indication of a number of missing packet data units (PDUs); and an indication of the highest received sequence number on the WLAN. In some situations, the sequence number and may be implemented on a per-UE basis instead of a per- DRB basis. In this situation, the DRB ID may be omitted. In this case, the status report may be similar to a status report in LWA (3GPP Release 13 LTE Wi-Fi Aggregation).

The LWIP tunnel, as discussed above, may allow for a WLAN RAN to supplement the cellular RAN. LWIP-SeGW 255 was described as terminating the LWIP tunnel. A Local Access (LA) Gateway (LA-GW) will next be described to assist in providing access to local services to UEs 110. The term "local services" will be described herein as referring to services provided via the WLAN and will be referred to as "Local Access (LA)" herein. The LA-GW may be implemented as part of the same or different hardware device as LWIP-SeGW 255, and may thus be implemented as part of eNB 135 or as a separate device. For clarity, in the description that follows, with reference to Figs. 6-10, the LA-GW node will be referred to as being independent of LWIP-SeGW 255.

Fig. 6 is a diagram illustrating an example architecture of a RAN-based LTE/WiFi integration (LWIP or LWA) to support Local Access. With the architecture of Fig. 6, the fact that UE 110 has a local connection established over WiFi is leveraged to support Local Access and eliminate or minimize core network support. Local Access, as implemented using the techniques described herein, will be referred to as enhanced RAN-based Local Access.

Additionally, as will be described in more detail below, a Local Access Adaptation Protocol (LAAP), which is based on LWIP, may be used to support Local Access.

Many of the blocks illustrated in Fig. 6 are identical to those illustrated in Fig. 2, and thus, for brevity, will not be described again. As shown in Fig. 6, however, the communication stack for the LTE cellular user plane traffic, through eNB 135, may include IP layer 230, which may include Local Access Adaptation Protocol (LAAP) layer 650. The communication stack for the LTE cellular user plane traffic, through UE 110, may similarly include IP layer 244, which may include LAAP layer 651. LAAP layers 650 and 6510 may operate to identify and differentiate Local Access traffic that is transported with non-Local Access user traffic (e.g., legacy LTE RAN "Internet" traffic). As is further shown in Fig. 6, LA-GW 670 may include a computing node, which may be implemented within eNB 135 or outside of eNB 135, and may manage Local Access traffic. LA- GW 670, as will be described in more detail below, may operate to support session continuity when UE 110 moves out of the coverage area of the currently serviced eNB. In general, LA-GW 670 may operate to establish an IPsec tunnel with UE 110 over a wide area network (e.g., the Internet) through the LTE link of the UE. By establishing the IPSec tunnel over the LTE link instead of WiFi, when UE 110 moves out of the coverage of WiFi and/or out of coverage of the current serving eNB, UE 110 can continue its "Local Access" session over the IPSec tunnel through LA-GW 670.

Fig. 7 is diagram illustrating an example network in which LA-GW 670 is used to support session continuity. As shown, UE 110 may connect, using radio interfaces, with either eNB 135 or WLAN 115 (e.g., via a local WiFi Access Point). A number of possible routes are available for UE 110 to obtain Local Access services from WLAN 115. When available, UE 110 may directly connect to WLAN 115 (e.g., via a WiFi link) ("Local Access over WiFi", link 740). Alternatively, UE 110 may connect via eNB 135 and LA-GW 670 ("Local Access over LTE RAN", link 735). In this situation, LA-GW 670 may act as a gateway to WLAN 115. This link may correspond to the "user plane" sessions shown in Figs. 2 and 6. Although eNB 135 is involved in the link , user traffic may be directly routed from eNB to LA-GW 670, and thus the core portion of the cellular network may not be impacted. This type of link may be particularly applicable when eNB 135 is implemented as a small cell within a premises. In this situation, UE 110 may obtain Local Access over WiFi when available and may use Local Access over the LTE RAN when WiFi is not available. Local Access over LTE RAN may thus be used, for example, to fill in coverage gaps in WiFi coverage at the premises.

As is further shown in Fig. 7, UE 110 may also maintain a link 730, to LA-GW 670, via Enhanced Packet Core 710 and Internet 720 ("Local Access over Internet via IPSec Tunnel", link 730). EPC 710 may represent the core (non-RAN portion) of cellular network 120. EPC 710 may include, for example, MME 142, SGW 144, and PGW 148. Internet 720 may represent a public network such as the Internet. Link 730 may be implemented as an IPSec tunnel that traverses eNB 135, EPC 710 (e.g., SGW 144 and PGW 148), and Internet 720. The IPSec tunnel may terminate at LA-GW 670, at a public IP ("Public IP") address that is obtained by LA-GW

670. LA-GW 670 may correspondingly forward local access traffic for WLAN 115.

In normal operation, UE 110 may establish link 730 but may not use link 730 as long as either link 735 or 740 is available. In situations in which both links 735 and 740 are not available, such as when UE 110 is handed over to an eNB that is not connected to LA-GW 670, UE 110 may begin to use link 740. Session continuity may thus be maintained. Fig. 8 is a diagram illustrating an example of a user plane protocol stack 800 for the architecture shown in Fig. 6. As shown, protocol stack 800 may include local applications layer 810, TCP/UDP layer 815, Local WiFi IP layer 820, WiFi Media Access Control (MAC) layer 825, LAAP layer 830, Network Address Translation (NAT) layer 835, IPSec layer 840, LTE IP layer 845, WiFi Physical (PHY) layer 850, and LTE L1/L2 (PDCP/RLC/MAC/PHY) layer 855.

Local applications layer 810 may represent the communication layer corresponding to local applications associated with WLAN 115. TCP/UDP layer 815 may represent the transport layer that may implement TCP and/or UDP communications. Local IP layer 820 may represent the layer that includes the WiFi IP address of the corresponding Local Application. Layers 810, 815, and 820 may be common to each of links 730, 735, and 740.

WiFi MAC layer 825 may be the media access layer that is used for Local Access over WiFi (link 740). Similarly, WiFi PHY layer 850 may be the physical access layer for Local Access over WiFi.

LAAP layer 830 and NAT layer 835 may provide the communication services for Local Access over LTE RAN (link 735). LAAP layer 830, IPSec layer 840, and LTE IP layer 845 may provide communication services for Local Access over Internet with IPSec Tunnel (link 730). In this manner, local IP traffic, when transmitted in links 730 or 735, can be sent over the local access IPSec tunnel (link 730) or through the LTE RAN with NAT (link 735). The physical communication layer for communications 730 and 735 may be implemented using the LTE physical layer (e.g., PDCP/RLC/MAC/PHY, as shown in Fig. 2).

Fig. 9 is a diagram illustrating an example packet format for an enhanced RAN-based Local Access (RLA) user plane packet (e.g., a packet format for the architecture shown in Fig. 6). In the packet of Fig. 9, an LAAP trailer may carry additional control information to support fragmentation or concatenation.

As shown in Fig. 9, an LTE packet that encapsulates a WiFi payload may include the standard fields IP header (LTE) 905, IP header (WiFi) 915, and IP payload (WiFi) 920. For link 730 and 735, LAAP trailer 925 may be added to the packet to carry information, such as sequence information, used to support fragmentation and concatenation. For link 730, IPSec Encapsulation Security Payload (ESP) 910, IPSec ESP Trailer 930, and IPSec ESP

Authentication Trailer (935) may be additionally added. That is, the IP header may encapsulate the IP header 915 and payload 920. The ESP header and trailer may contain security parameters that can be used to encrypt the payload. The IPSec ESP Authentication Trailer may include authentication data, such as a digital signature. An example setup procedure for the enhanced RAN-based Local Access setup procedure will next be described with reference to Fig. 10. Fig. 10 is a signal diagram illustrating RRC signaling for an example setup procedure.

The signal diagram in Fig. 10 may be based on the existing LWIP tunnel setup procedure to support local access. For instance, communications 1005-1035 may be based on the existing LWIP tunnel setup procedure. These communications may include eNB 135 initially

transmitting a "RRCConnectionReconfiguration" message (at 1005) to UE 110, which may respond with a "RRCConnectionReconfigurationComplete" message (at 1010). UE 110 may record measurements relating to the quality of the WLAN link , such as the received signal strength. UE 110 may transmit a message reporting the WLAN measurements (at 1015, "WLAN Measurements"). eNB 135 may potentially reconfigure the link based on the measurement report (at 1020 and 1025, "RRCConnectionReconfiguration" and

"RRCConnectionReconfigurationComplete"). UE 110 may connect/associate to WLAN 115 (at 1030) and, in response to the connection with WLAN 115, report the connection to eNB 135 (at 1035, "WLANConnectionStatusReport").

eNB 135 may send an additional "RRCConnectionReconfiguration" message, which may include parameters to indicate support, by eNB 135, of the enhanced RAN-based Local Access, as well as the public IP address, of LA-GW 670, used to terminate the IPSec tunnel for link 730 (at 1040).

If UE 110 supports enhanced RAN-based Local Access, the UE may respond by sending the "RRCConnectionReconfigurationComplete" message, including a parameter that includes the local WiFi IP address of UE 110 (at 1045).

In operation, after Local Access is setup (e.g., as discussed with respect to Fig. 10) , UE may 110 may send or receive Local Access traffic directly over the LTE RAN (link 735) or directly over WiFi (link 740). In one embodiment, UE 110 may preferentially transmit Local Access traffic directly over WiFi, when a connection is available, and may transmit Local Access traffic over the LTE RAN to supplement the WiFi connection or when the WiFi connection is not available. UE 110 may transmit Local Access traffic over the Internet IPSec tunnel (link 730), when neither link 735 or 740 are available (e.g., when UE 110 travels outside of the range of a local network and is only able to obtain network connectivity via macro base station connectivity).

In some implementations, if session continuity is required or desired for Local Access, UE 110 may establish an IPSec tunnel to LA-GW 670, over the Internet, through its LTE connection using the public IP address of LA-GW 670. The IPSec tunnel may be established before link 730 is needed (e.g., while UE 110 is using link 735 or 740 for Local Access). If link 735 or 740 is subsequently lost, UE 110 may switch to using the previously established Internet IPSec tunnel (link 730), and may maintain session continuity. To implement the switch to link 730 and maintain session continuity, e B 135 may send an RRCConnectionReconfiguration message to UE 110, indicating uplink local access should be sent via the local access IPSec tunnel. This may be performed when an inter-cell handover is triggered. eNB 135 may also indicate to LA-GW 670 that downlink local access traffic should be sent via the IPSec tunnel.

In some implementations, UE 110 may send a RRC message to eNB 135 for moving both uplink and downlink local access traffic to the LTE connection when the WiFi connection is lost. In this case, UE should keep its local IP network interface up even if WiFi is

disconnected. After all the Local Access sessions have ended, UE 110 or LA-GW 670 may tear down the Local Access IPSec tunnel.

Although the above description was made with respect to 3 GPP LWIP framework, the concepts described above may also apply to Multiple Access Management Service (MAMS) standards of the Internet Engineering Task Force (IETF), which share many similarities with the 3 GPP LWIP framework. 3 GPP LWIP may be seen as an example of MAMS framework. The main difference may be that the transport of control signaling in 3GPP LWIP is supported by RRC messages. While the control signaling in MAMS may be delivered over the top of user- plane packets, e.g. UDP or TCP. In terms of similarity, CCM in MAMS can be much similar to LWIPEP (u-plane) and RRC (c-plane) at UE in LWIP.

As used herein, the term "circuitry," "processing circuitry," or "logic" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules. In some embodiments, circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.

Fig. 11 illustrates example components of a device 1100 in accordance with some embodiments. In some embodiments, the device 1100 may include application circuitry 1102, baseband circuitry 1104, Radio Frequency (RF) circuitry 1106, front-end module (FEM) circuitry 1108, one or more antennas 1110, and power management circuitry (PMC) 1112 coupled together at least as shown. The components of the illustrated device 1100 may be included in a UE or a RAN node. In some embodiments, the device 1100 may include less elements (e.g., a RAN node may not utilize application circuitry 1102, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 1100 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

The application circuitry 1102 may include one or more application processors. For example, the application circuitry 1102 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various

applications or operating systems to run on the device 1100. In some embodiments, processors of application circuitry 1102 may process IP data packets received from an EPC.

The baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1104 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1106 and to generate baseband signals for a transmit signal path of the RF circuitry 1106. Baseband processing circuity 1104 may interface with the application circuitry 1102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1106. For example, in some embodiments, the baseband circuitry 1104 may include a third generation (3G) baseband processor 1104 A, a fourth generation (4G) baseband processor 1104B, a fifth generation (5G) baseband processor 1104C, or other baseband processor(s) 1104D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). The baseband circuitry 1104 (e.g., one or more of baseband processors 1104A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1106. In other embodiments, some or all of the functionality of baseband processors 1104A-D may be included in modules stored in the memory 1104G and executed via a Central Processing Unit (CPU) 1104E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1104 may include

Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1104 may include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry 1104 may include one or more audio digital signal processor(s) (DSP) 1104F. The audio DSP(s) 1104F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1104 and the application circuitry 1102 may be implemented together such as, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1104 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1104 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 1104 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 1106 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1106 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1106 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1108 and provide baseband signals to the baseband circuitry 1104. RF circuitry 1106 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1104 and provide RF output signals to the FEM circuitry 1108 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1106 may include mixer circuitry 1106a, amplifier circuitry 1106b and filter circuitry 1106c. In some

embodiments, the transmit signal path of the RF circuitry 1106 may include filter circuitry 1106c and mixer circuitry 1106a. RF circuitry 1106 may also include synthesizer circuitry

1106d for synthesizing a frequency for use by the mixer circuitry 1106a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1106a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry

1108 based on the synthesized frequency provided by synthesizer circuitry 1106d. The amplifier circuitry 1106b may be configured to amplify the down-converted signals and the filter circuitry 1106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1104 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1106a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1106a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1106d to generate RF output signals for the FEM circuitry 1108. The baseband signals may be provided by the baseband circuitry 1104 and may be filtered by filter circuitry 1106c.

In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1104 may include a digital baseband interface to communicate with the RF circuitry 1106.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 1106d may be a fractional -N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 1106d may be configured to synthesize an output frequency for use by the mixer circuitry 1106a of the RF circuitry 1106 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1106d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1104 or the applications processor 1102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 1102.

Synthesizer circuitry 1106d of the RF circuitry 1106 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 1106d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 1106 may include an IQ/polar converter.

FEM circuitry 1108 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1110, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry

1106 for further processing. FEM circuitry 1108 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1106 for transmission by one or more of the one or more antennas 1110. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1106, solely in the FEM 1108, or in both the RF circuitry 1106 and the FEM 1108.

In some embodiments, the FEM circuitry 1108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1106). The transmit signal path of the FEM circuitry 1108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1110).

In some embodiments, the PMC 1112 may manage power provided to the baseband circuitry 1104. In particular, the PMC 1112 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1112 may often be included when the device 1100 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 1112 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While Fig. 11 shows the PMC 1112 coupled only with the baseband circuitry 1104. However, in other embodiments, the PMC 11 12 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1102, RF circuitry 1106, or FEM 1108.

In some embodiments, the PMC 1112 may control, or otherwise be part of, various power saving mechanisms of the device 1100. For example, if the device 1100 is in an

RRC Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1100 may power down for brief intervals of time and thus save power.

If there is no data traffic activity for an extended period of time, then the device 1100 may transition off to an RRC Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1100 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1100 may not receive data in this state, in order to receive data, it must transition back to RRC Connected state.

An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours). During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

Processors of the application circuitry 1102 and processors of the baseband circuitry 1104 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1104, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1104 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers). As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer, described in further detail below. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node, described in further detail below.

Fig. 12 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 1104 of Fig. 11 may comprise processors 1104A-1104E and a memory 1104G utilized by said processors. Each of the processors 1104A-1104E may include a memory interface, 1204A-1204E, respectively, to send/receive data to/from the memory 1104G.

The baseband circuitry 1104 may further include one or more interfaces to

communicatively couple to other circuitries/devices, such as a memory interface 1212 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1104), an application circuitry interface 1214 (e.g., an interface to send/receive data to/from the application circuitry 1102 of Fig. 11), an RF circuitry interface 1216 (e.g., an interface to send/receive data to/from RF circuitry 1106 of Fig. 11), a wireless hardware connectivity interface 1218 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (e.g., Bluetooth® Low Energy), WiFi® components, and other communication components), and a power management interface 1220 (e.g., an interface to send/receive power or control signals to/from the PMC 1112.

Fig. 13 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium

(e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 13 shows a diagrammatic representation of hardware resources 1300 including one or more processors (or processor cores) 1310, one or more memory/storage devices 1320, and one or more communication resources 1330, each of which may be communicatively coupled via a bus 1340. For embodiments where node virtualization (e.g., FV) is utilized, a hypervisor 1302 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1300

The processors 1310 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, a processor 1312 and a processor 1314.

The memory/storage devices 1320 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1320 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random-access memory

(DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

The communication resources 1330 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1304 or one or more databases 1306 via a network 1308. For example, the communication resources 1330 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), WiFi® components, and other communication components.

Instructions 1350 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1310 to perform any one or more of the methodologies discussed herein. The instructions 1350 may reside, completely or partially, within at least one of the processors 1310 (e.g., within the processor's cache memory), the memory/storage devices 1320, or any suitable combination thereof. Furthermore, any portion of the instructions 1350 may be transferred to the hardware resources 1300 from any

combination of the peripheral devices 1304 or the databases 1306. Accordingly, the memory of processors 1310, the memory/ storage devices 1320, the peripheral devices 1304, and the databases 1306 are examples of computer-readable and machine-readable media.

A number of examples, relating to implementations of the techniques described above, will next be given.

In a first example, an apparatus for User Equipment (UE) may comprise: an interface to radio frequency (RF) circuitry; and one or more processors that are controlled to: establish a first link, via the interface to the RF circuitry, for local access to services of a wireless local area network (WLAN), the first link being established as either: a direct link to the WLAN, or a link to the WLAN, through a base station of a cellular network, but not through a core portion of the cellular network; establish a second link, via the interface to the RF circuitry, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network; and switch an ongoing traffic session, to the WLAN, using the IPSec tunnel, when the first link is unavailable.

In example 2, the subject matter of example 1, wherein session continuity is maintained when switching the ongoing traffic session.

In example 3, the subject matter of example 1, or any of the preceding examples, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

In example 4, the subject matter of example 1, 2, or 3, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station and via Radio Resource Control (RRC) signaling, an indication from the base station that the second link is supported.

In example 5, the subject matter of example 1, 2, or 3, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station and via Radio Resource Control (RRC) signaling, an IP address used to terminate the IPSec tunnel.

In example 6, the subject matter of example 1, 2, or 3, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: provide, to the base station, an IP address and port number, used by the UE, for transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

In example 7, the subject matter of example 6, or any of the preceding examples, wherein the control messages include an LWIP status report control message.

In example 8, the subject matter of example 7, or any of the preceding examples, wherein the status report includes, for each Data Radio Bearer (DRB): an identifier of the DRB, and information relating to missing packet data units associated with the identified DRB.

In example 9, the subject matter of example 1, 2, or 3, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station, an IP address and port number to use when transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

In a tenth example, a computer-readable medium containing program instructions for causing one or more processors, associated with User Equipment (UE) operable with a cellular communications network, to: establish a first link, for local access to services of a wireless local area network (WLAN), the first link being established as either: a direct link to the WLAN, or a link to the WLAN, through a base station of a cellular network, but not through a core portion of the cellular network; establish a second link, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network; switch an ongoing traffic session, to the WLAN, using the IPSec tunnel, when the first link is unavailable.

In example 11, the subject matter of example 10, or any of the preceding examples, wherein session continuity is maintained when switching the ongoing traffic session.

In example 12, the subject matter of example 10, or any of the preceding examples, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

In example 13, the subject matter of example 10, 11, or 12, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station and via Radio Resource Control (RRC) signaling, an indication from the base station that the second link is supported.

In example 14, the subject matter of example 10, 11, or 12, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station and via Radio Resource Control (RRC) signaling, an IP address used to terminate the IPSec tunnel.

In example 15, the subject matter of example 10, 11, or 12, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: provide, to the base station, an IP address and port number, used by the UE, for transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

In example 16, the subject matter of example 15, or any of the preceding examples, wherein the control messages include an LWIP status report control message.

In example 17, the subject matter of example 16, or any of the preceding examples, wherein the status report includes, for each Data Radio Bearer (DRB): an identifier of the DRB, and information relating to missing packet data units associated with the identified DRB.

In example 18, the subject matter of example 10, 11, or 12, or any of the preceding examples, wherein the one or more processors are further to execute the processing instructions to: receive, from the base station, an IP address and port number to use when transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

In a 19^th example, a computer-readable medium may contain program instructions for causing one or more processors, associated with a gateway node for a communications network, to: provide, via an interface to a base station of a cellular network, an Internet Protocol (IP) address to the base station, the IP address being a public IP address of the gateway node for a public wide area network; terminate an IP Security Tunnel (IPSec) tunnel, based on the IP address, formed over the public wide area network, the IPSec tunnel being formed with User Equipment (UE) and the IPSec tunnel traversing the base station; and forward traffic, via an interface to the wireless local area network (WLAN), and that was received over the IPSec tunnel and from the UE, to the WLAN.

In example 20, the subject matter of example 19, or any of the preceding examples, wherein the IPSec tunnel is a first link, and wherein the programming instructions are further to cause the gateway node to: implement a second link, to the UE, through the interface to the base station and as a Long Term Evolution (LTE) Radio Access Network (RAN) link to the UE that does not use the public wide area network; and forward traffic, via the interface to the WLAN, and that was received over the second link and from the UE, to the WLAN.

In example 21, the subject matter of example 19 or 20, or any of the preceding examples, wherein the traffic is local access traffic associated with the WLAN.

In example 22, the subject matter of example 19 or 20, or any of the preceding examples, wherein the public wide area network includes the Internet.

In example 23, the subject matter of example 20, or any of the preceding examples, wherein the programming instructions are further to cause the gateway node to: maintain session continuity for traffic switching from the second link to the first link.

In a 24^th example, a gateway node for a communications network may comprise means for providing, via an interface to a base station of a cellular network, an Internet Protocol (IP) address to the base station, the IP address being a public IP address of the gateway node for a public wide area network; means for terminating an IP Security Tunnel (IPSec) tunnel, based on the IP address, formed over the public wide area network, the IPSec tunnel being formed with User Equipment (UE) and the IPSec tunnel traversing the base station; and means for forwarding traffic, via an interface to the wireless local area network (WLAN), and that was received over the IPSec tunnel and from the UE, to the WLAN.

In example 25, the subject matter of example 24, or any of the preceding examples, wherein the IPSec tunnel is a first link, and wherein the gateway node further comprises: means for implementing a second link, to the UE, through the interface to the base station and as a

Long Term Evolution (LTE) Radio Access Network (RAN) link to the UE that does not use the public wide area network; and means for forwarding traffic, via the interface to the WLAN, and that was received over the second link and from the UE, to the WLAN.

In example 26, the subject matter of examples 24 or 25, or any of the preceding examples, wherein the traffic is local access traffic associated with the WLAN.

In example 27, the subject matter of examples 24 or 25, or any of the preceding examples, wherein the public wide area network includes the Internet.

In a 28^th example, a method, implemented by User Equipment (UE) associated with a cellular communications network, may comprise: establishing a first link, for local access to services of a wireless local area network (WLAN), the first link being established as either: a direct link to the WLAN, or a link to the WLAN, through a base station of a cellular network, but not through a core portion of the cellular network; establishing a second link, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network; and switching an ongoing traffic session, to the WLAN, using the IPSec tunnel, when the first link is unavailable.

In example 29, the subject matter of example 28, or any of the preceding examples, wherein session continuity is maintained when switching the ongoing traffic session.

In example 30, the subject matter of example 28, or any of the preceding examples, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

In example 31, the subject matter of example 28, 29, or 30, or any of the preceding examples, further comprising: receiving, from the base station and via Radio Resource Control (RRC) signaling, an indication from the base station that the second link is supported.

In example 32, the subject matter of example 28, 29, or 30, or any of the preceding examples, further comprising: receiving, from the base station and via Radio Resource Control (RRC) signaling, an IP address used to terminate the IPSec tunnel.

In example 33, the subject matter of example 28, 29, or 30, or any of the preceding examples, further comprising: providing, to the base station, an IP address and port number, used by the UE, for transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

In example 34, the subject matter of example 33, or any of the preceding examples, wherein the control messages include an LWIP status report control message.

In example 35, the subject matter of example 34, or any of the preceding examples, wherein the status report includes, for each Data Radio Bearer (DRB): an identifier of the DRB, and information relating to missing packet data units associated with the identified DRB.

In a 36^nd example, an apparatus for a User Equipment (UE) device may comprise: means for establishing a first link, for local access to services of a wireless local area network

(WLAN), the first link being established as either: a direct link to the WLAN, or a link to the WLAN, through a base station of a cellular network, but not through a core portion of the cellular network; means for establishing a second link, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network; and means for switching an ongoing traffic session, to the WLAN, using the IPSec tunnel, when the first link is unavailable.

In example 37, the subject matter of example 36, or any of the preceding examples, wherein session continuity is maintained when switching the ongoing traffic session.

In example 38, the subject matter of example 36, or any of the preceding examples, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

In the preceding specification, various embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.

For example, while series of signals and/or operations have been described with regard to Figs. 3, 4, and 10, the order of the signals/operations may be modified in other

implementations. Further, non-dependent signals may be performed in parallel.

It will be apparent that example aspects, as described above, may be implemented in many different forms of software, firmware, and hardware in the implementations illustrated in the figures. The actual software code or specialized control hardware used to implement these aspects should not be construed as limiting. Thus, the operation and behavior of the aspects were described without reference to the specific software code— it being understood that software and control hardware could be designed to implement the aspects based on the description herein.

Even though particular combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to be limiting. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification.

No element, act, or instruction used in the present application should be construed as critical or essential unless explicitly described as such. An instance of the use of the term "and," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Similarly, an instance of the use of the term "or," as used herein, does not necessarily preclude the interpretation that the phrase "and/or" was intended in that instance. Also, as used herein, the article "a" is intended to include one or more items, and may be used interchangeably with the phrase "one or more." Where only one item is intended, the terms "one," "single," "only," or similar language is used.

Claims

WHAT IS CLAIMED IS:

1. An apparatus for a User Equipment (UE) comprising:

an interface to radio frequency (RF) circuitry; and

one or more processors that are controlled to:

establish a first link, via the interface to the RF circuitry, for local access to services of a wireless local area network (WLAN), the first link being established as either:

a direct link to the WLAN, or

a link to the WLAN, through a base station of a cellular network, but not through a core portion of the cellular network;

establish a second link, via the interface to the RF circuitry, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network; and

switch an ongoing traffic session, to the WLAN, using the IPSec tunnel, when the first link is unavailable.

2. The apparatus of claim 1, wherein session continuity is maintained when switching the ongoing traffic session.

3. The apparatus of claim 1, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

4. The apparatus of claim 1, 2, or 3, wherein the one or more processors are further to execute the processing instructions to:

receive, from the base station and via Radio Resource Control (RRC) signaling, an indication from the base station that the second link is supported.

5. The apparatus of claim 1, 2, or 3, wherein the one or more processors are further to execute the processing instructions to:

receive, from the base station and via Radio Resource Control (RRC) signaling, an IP address used to terminate the IPSec tunnel.

6. The apparatus of claim 1, 2, or 3, wherein the one or more processors are further to execute the processing instructions to: provide, to the base station, an IP address and port number, used by the UE, for transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

7. The apparatus of claim 6, wherein the control messages include an LWIP status report control message.

8. The apparatus of claim 7, wherein the status report includes, for each Data Radio Bearer (DRB):

an identifier of the DRB, and

information relating to missing packet data units associated with the identified DRB.

9. The apparatus of claim 1, 2, or 3, wherein the one or more processors are further to execute the processing instructions to:

receive, from the base station, an IP address and port number to use when transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

10. A computer-readable medium containing program instructions for causing one or more processors, associated with User Equipment (UE) operable with a cellular communications network, to:

establish a first link, for local access to services of a wireless local area network

(WLAN), the first link being established as either:

a direct link to the WLAN, or

establish a second link, for local access to services of the WLAN, the second link being established as an Internet Protocol (IP) Security (IPSec) tunnel formed with the base station, the core portion of the cellular network, and a public wide area network;

11. The computer-readable medium of claim 10, wherein session continuity is maintained when switching the ongoing traffic session.

12. The computer-readable medium of claim 10, wherein the switching of the ongoing traffic session is performed as part of a handover operation to a second base station that is not associated with the WLAN.

13. The computer-readable medium of claim 10, 11, or 12, wherein the one or more processors are further to execute the processing instructions to:

14. The computer-readable medium of claim 10, 11, or 12, wherein the one or more processors are further to execute the processing instructions to:

15. The computer-readable medium of claim 10, 11, or 12, wherein the one or more processors are further to execute the processing instructions to:

provide, to the base station, an IP address and port number, used by the UE, for transmitting control messages over a Long Term Evolution (LTE) WLAN IPSec (LWIP) tunnel.

16. The computer-readable medium of claim 15, wherein the control messages include an LWIP status report control message.

17. The computer-readable medium of claim 16, wherein the status report includes, for each Data Radio Bearer (DRB):

an identifier of the DRB, and

18. The computer-readable medium of claim 10, 11, or 12, wherein the one or more processors are further to execute the processing instructions to:

19. A computer-readable medium containing program instructions for causing one or more processors, associated with a gateway node for a communications network, to: provide, via an interface to a base station of a cellular network, an Internet Protocol (IP) address to the base station, the IP address being a public IP address of the gateway node for a public wide area network;

terminate an IP Security Tunnel (IPSec) tunnel, based on the IP address, formed over the public wide area network, the IPSec tunnel being formed with User Equipment (UE) and the IPSec tunnel traversing the base station; and

forward traffic, via an interface to the wireless local area network (WLAN), and that was received over the IPSec tunnel and from the UE, to the WLAN.

20. The computer-readable medium of claim 19, wherein the IPSec tunnel is a first link, and wherein the program instructions are further to cause the gateway node to:

implement a second link, to the UE, through the interface to the base station and as a Long Term Evolution (LTE) Radio Access Network (RAN) link to the UE that does not use the public wide area network; and

forward traffic, via the interface to the WLAN, and that was received over the second link and from the UE, to the WLAN.

21. The computer-readable medium of claim 19 or 20, wherein the traffic is local access traffic associated with the WLAN.

22. The computer-readable medium of claim 19 or 20, wherein the public wide area network includes the Internet.

23. The computer-readable medium of claim 20, wherein the programming instructions are further to cause the gateway node to:

maintain session continuity for traffic switching from the second link to the first link.