LWIP USER PLANE INTERFACE

RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. § 119 to U.S. Provisional Application No. 62/416,532 filed on November 2, 2016, which is hereby incorporated by reference in its entirety.

FIELD

Various embodiments of the present application generally relate to the field of wireless communications, and in particular, to wireless communications using Long Term Evolution (LTE)/Wireless Local Area Network (WLAN) Radio Level Integration with Internet Protocol Security (IPsec) Tunnel (LWIP).

BACKGROUND

Third generation partnership project (3GPP) long term evolution (LTE) systems may support features that allows a network to configure user equipment (UE) with LTE and WiFi capabilities to utilize links of both networks. Two of these features include LTE-WLAN aggregation (LWA) and LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP). Both LWA and LWIP may include a backhaul connection between an evolved NodeB (eNB) and a WLAN device. LWA systems may use an Xw interface for this back haul connection; however, there has been some dispute as to which interface should be used for the backhaul connection in LWIP or enhanced LWIP (eLWIP).

LWIP is similar to LWA in that both features use WiFi technologies to utilize unlicensed spectrum, but differences exist between LWIP and LWA. One difference is that LWA aggregates LTE and WiFi at the packet data convergence protocol (PDCP) layer, whereas LWIP aggregates or switches between LTE and WiFi links at the internet protocol (IP) layer. Because of this difference, LWA may use PDCP protocol data unit (PDU) payloads to convey data whereas LWIP may use IP payloads to convey data. Another difference is that LWA and LWIP have different system architectures. In particular, the LWIP architecture is designed to leverage legacy WiFi infrastructure, while LWA may require significant enhancements to the WLAN infrastructure, security capabilities, and flow control mechanisms. Yet another difference is that LWIP is able to send uplink data over the unlicensed spectrum, whereas LWA is one of several approaches that is focused on enhancing LTE downlink capabilities.

One proposal for the LWIP backhaul connection is simply to reuse the Xw interface for LWIP/eLWIP without any substantial changes. Due to the various differences between LWA and LWIP/eLWIP discussed previously, reusing the same Xw interface for LWIP/eLWIP may introduce issues such as increased UE and eNB complexity, increased signaling overhead, difficult implementation for WiFi equipment manufacturers or vendors, and the like.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals 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 A illustrates an example system architecture of a network, in accordance with various embodiments.

FIG. IB illustrates an example LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP) architecture in accordance with various embodiments.

FIG. 2 illustrates example components of an electronic device in accordance with various embodiments.

FIG. 3 illustrates example components of another electronic device in accordance with various embodiments.

FIG. 4 illustrates example interfaces of baseband circuitry in accordance with some embodiments.

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

FIG. 6 is an illustration of a control plane protocol stack in accordance with various embodiments.

FIG. 7A is an illustration of a user plane protocol stack in accordance with various embodiments.

FIG. 7B is an illustration of an LWIP Xw user plane protocol stack in accordance with various embodiments.

FIG. 8 is an illustration of an LWIP protocol architecture in accordance with various embodiments.

FIGS. 9A-9C illustrate example frame formats in accordance with various embodiments.

FIG. 10 shows an example LWIP tunnel setup and data bearer configuration procedure in accordance with various embodiments.

FIG. 11 shows an example WLAN resource reconfiguration procedure in accordance with various embodiments.

FIG. 12 shows an example LWIP tunnel release procedure in accordance with various embodiments.

FIG. 13 illustrates an example process for transferring downlink user data in accordance with various embodiments, and an example process for conveying a downlink data delivery status in accordance with various embodiments.

FIG. 14 illustrates another example process for LWIP operation in accordance with various embodiments.

FIG. 15 illustrates another example process for LWIP operation in accordance with various embodiments.

FIG. 16 illustrates yet another example process for LWIP operation in accordance with various embodiments.

DETAILED DESCRIPTION

Embodiments discussed herein relate to the user plane interface between an evolved NodeB (eNB) and an LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP)- security gateway (SeGW). The user plane interface may provide data transfer functionality (uplink and downlink) as well as flow control services. In embodiments, the user plane interface may terminate at an eNB and an LWIP-SeGW, and may be used to convey LWIP Encapsulation Protocol (LWIPEP)-protocol data units (PDUs) on a single General Packet Radio System Tunneling Protocol (GTP) bearer between the eNB and LWIP-SeGW. Other embodiments may be described and/or claimed.

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc., in order to provide a thorough understanding of the various aspects of the claimed invention. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the invention claimed may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the present invention with unnecessary detail.

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrase "in various embodiments," "in some embodiments," and the like are used repeatedly. The phrase generally does not refer to the same embodiments; however, it may. The terms "comprising," "having," and "including" are synonymous, unless the context dictates otherwise. The phrase "A and/or B" means (A), (B), or (A and B). The phrases "A/B" and "A or B" mean (A), (B), or (A and B), similar to the phrase "A and/or B." For the purposes of the present disclosure, the phrase "at least one of A and B" means (A), (B), or (A and B). The description may use the phrases "in an embodiment," "in embodiments," "in some embodiments," and/or "in various embodiments," which may each refer to one or more of the same or different embodiments. Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Example embodiments may be described as a process depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure(s). A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, its termination may correspond to a retum of the function to the calling function and/or the main function.

Example embodiments may be described in the general context of computer- executable instructions, such as program code, software modules, and/or functional processes, being executed by one or more of the aforementioned circuitry. The program code, software modules, and/or functional processes may include routines, programs, objects, components, data structures, etc., that perform particular tasks or implement particular data types. The program code, software modules, and/or functional processes discussed herein may be implemented using existing hardware in existing communication networks. For example, program code, software modules, and/or functional processes discussed herein may be implemented using existing hardware at existing network elements or control nodes.

As used herein, the term "circuitry" refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD), (for example, a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high- capacity PLD (HCPLD), a structured ASIC, or a programmable System on Chip (SoC)), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality.

As used herein, the term "processor circuitry" may refer to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations; recording, storing, and/or transferring digital data. The term "processor circuitry" may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.

As used herein, the term "interface circuitry" may refer to, is part of, or includes circuitry providing for the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces (for example, buses, input/output (I/O) interfaces, peripheral component interfaces, network interface cards, and/or the like).

As used herein, the term "user equipment" or "UE" may refer to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term "user equipment" or "UE" may be considered synonymous to, and may hereafter be occasionally referred to as client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device such as consumer electronics devices, cellular phones, smartphones, feature phones, tablet computers, wearable computer devices, personal digital assistants (PDAs), desktop computers, laptop computers, in-vehicle infotainment (IVI), in-car entertainment (ICE) devices, an Instrument Cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminals (MDTs), Electronic Engine Management System (EEMS), electronic/engine control units (ECUs), electronic/engine control modules (ECMs), embedded systems, microcontrollers, control modules, engine management systems (EMS), networked or "smart" appliances, machine-type communications (MTC) devices, machine- to-machine (M2M), Internet of Things (IoT) devices, and/or the like.

As used herein, the term "network element" may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, router, switch, hub, bridge, radio network controller, radio access network device, gateway, server, and/or any other like device. The term "network element" may describe a physical computing device of a wired or wireless communication network and be configured to host a virtual machine. Furthermore, the term "network element" may describe equipment that provides radio baseband functions for data and/or voice connectivity between a network and one or more users. The term "network element" may be considered synonymous to and/or referred to as a "base station." As used herein, the term "base station" may be considered synonymous to and/or referred to as a node B, an enhanced or evolved node B (eNB), next generation nodeB (gNB), a roadside unit (RSU), base transceiver station (BTS), access point, etc., and may describe equipment that provides the radio baseband functions for data and/or voice connectivity between a network and one or more users.

As used herein, the term "channel" may refer to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term "channel" may be synonymous with and/or equivalent to "communications channel," "data communications channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radiofrequency carrier," and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term "link" may refer to a connection between two devices through a Radio Access Technology (RAT) for the purpose of transmitting and receiving information.

FIG. 1 A illustrates an architecture of a system 100 of a network, in accordance with some embodiments. The following description is provided for an example system 100 that operates in conjunction with the Long Term Evolution (LTE) standard as provided by 3rd Generation Partnership Project (3GPP) technical specifications (TS). However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as Fifth Generation (5G) or New Radio (NR) systems, and the like.

The system 100 is shown to include user equipment (UE) 101 and a UE 102. The

UEs 101 and 102 are illustrated as smartphones (for example, handheld touchscreen mobile computing devices connectable to one or more cellular networks) but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the UEs 101 and 102 can comprise an IoT UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. An IoT UE can utilize technologies such as M2M or MTC for exchanging data with an MTC server or device via a public land mobile network (PLMN), Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure), with short-lived connections. The IoT UEs may execute background applications (for example, keep-alive messages, status updates, etc.) to facilitate the connections of the IoT network.

The UEs 101 and 102 may be configured to connect, for example, communicatively couple, with a radio access network (RAN)— in this embodiment, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E- UTRAN) 110. The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which comprises a physical communications interface or layer (discussed in further detail below); in this example, the connections 103 and 104 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code- division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and/or any of the other communications protocols discussed herein. In embodiments, the UEs 101 and 102 may directly exchange communication data via a ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink (SL) interface 105 and may comprise one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH), a Physical Sidelink Shared Channel (PSSCH), a Physical Sidelink Discovery Channel (PSDCH), and a Physical Sidelink Broadcast Channel (PSBCH).

In this example, the UE 102 is shown to be configured to access an access point (AP)

106 via connection 107. The connection 107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 106 may comprise a Wireless Local Area Network (WLAN) device, such as a wireless fidelity (WiFi®) router. In this example, the AP 106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further detail below). The UE 102 and AP 106 (also referred to as also referred to as "WLAN node 106", "WLAN entity 106", "WLAN 106", or the like) may use the Internet Protocol Security (IPsec) protocol to authenticate and encrypt packets (for example, internet protocol (IP) packets) sent over the connection 107. In various embodiments, the UE 102 may be configured to utilize LTE/WLAN Radio Level Integration with IPsec Tunnel (LWIP) where the UE 102 may use WLAN radio resources (for example, connection 107) via IPsec tunneling. IPsec tunneling may include encapsulating entirety of original IP packets and adding a new packet header thereby protecting the original header of the IP packets. An example architecture for LWIP is illustrated by FIG. IB.

Referring to FIG. IB, which depicts an example LWIP architecture 100B, the UE

102 may communicate data using LWIP. The LWIP feature may allow the UE 102 in the RRC C ONNECTED state to be configured by the RAN node 111/112 to utilize WLAN radio resources via IPsec tunneling. In FIG. IB, like numbered items are the same or similar as discussed elsewhere herein. As shown, architecture 100B includes an LWIP-security gateway (LWIP-SeGW) 150 in addition to the UE 102, RAN node 111/112, AP 106, and MME/S-GW 121/122 discussed previously.

Connectivity between RAN node 111/112 and LWIP-SeGW 150 is provided by an interface 155, which may include a user plane interface and a control plane interface (not shown by FIG. IB). Connectivity between the LWIP-SeGW 150 and the UE 102 via WLAN 106 may be provided by IPsec tunnel 117. The IPsec tunnel 117 may include the connection

107 between UE 102 and WLAN 106, as well as link 157 between the WLAN 106 and the LWIP-SeGW 150. The IPsec tunnel 117 may be established following the exchange of security information between the RAN node 111/112 and LWIP-SeGW 150 during an LWIP Addition Preparation procedure, which is an Xw control plane procedure. The LWIP Addition Preparation procedure may also be used to establish an LWIP bearer, which may be a data bearer to be transported over the LWIP tunnel. The end-to-end (e2e) path between the UE 102 and RAN node 111/112 via the WLAN 106 is referred to as LWIP tunnel 160.

To utilize LWIP, the RAN node 111/112 may configure the UE 102 to transmit uplink (UL) data using WLAN signaling (for example, over connection 107) or using LTE signaling (for example, over link 104). If routed via the WLAN 106, then all UL traffic of the data bearer may be offloaded to the WLAN 106. The RAN node 111/112 may use Radio Resource Control (RRC) signaling to configure the UE 102 for LWIP. For example, the RAN node 111/112 may transmit a RRCConnectionReconfiguration message to provide necessary parameters for the UE 102 to initiate the establishment of the IPSec tunnel for a data radio bearer (DRB) of the LTE network. When the IPsec tunnel 117 is established, a data bearer can be configured to use LWIP resources. The LWIP resources may be WLAN resources that are used for or over the LWIP tunnel 160. The data bearer may be an Evolved Packet System (EPS) bearer mapped to the DRB that is maintained on the LTE side.

When aggregation over LWIP is enabled for UL and/or downlink (DL) data, the corresponding UL and/or DL packets sent over the LWIP tunnel 160 and LTE signaling are encapsulated using LWIP Encapsulation Protocol (LWIPEP), which is discussed in more detail with respect to FIG. 8. In this way, the RAN node 111/112 may not need to interpret the IP packets coming from the UE 102. For communicating data through the LWIP tunnel 160, the IP packets to be transferred between the UE 102 and LWIP-SeGW 150 may be encapsulated using IPsec in order to provide security to the packets that traverse the WLAN 106. The IP packets may then be transported between the LWIP-SeGW 150 and RAN node 111/112 via the interface 155.

According to various embodiments, a single IPSec tunnel 117 is used per UE for all data bearers that are configured to send and/or receive data over WLAN 106. The data corresponding to each IPSec Tunnel 117 may be transported over the interface 155 on a single General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP- U) tunnel. Each data bearer may be configured so that traffic for that bearer can be routed over the IPsec tunnel 117 in only downlink, only uplink, or both uplink and downlink over WLAN 106. Additionally, signaling radio bearers (SRBs) may be carried over LTE signaling only, and the RAN node 111/112 may configure specific bearer(s) to use the IPsec tunnel 117.

In various embodiments, the interface 155 may be an Xs interface or an Xw interface that is different than the Xw interface used for LWA. The Xw interface used for LWA may be referred to herein as the "LWA Xw interface", and the Xw interface used for LWIP may be referred to herein as the "LWIP Xw interface", "L-Xw-UP interface", or the like. In some embodiments, the LWIP Xw interface may be referred to as an "Xs interface" or the like.

The L-Xw-UP interface 155 is used to deliver the LWIPEP PDUs between RAN node 111/112 and the LWIP-SeGW 150 using a single tunnel for all bearers configured for LWIP. The L-Xw-UP interface 155 supports flow control based on feedback from LWIP- SeGW 150. For example, the L-Xw-UP interface 155 may use an Xw user plane protocol (for example, L-Xw-UP 700B of FIG. 7B discussed infra) to provide non-guaranteed delivery of user plane PDUs using services of a transport network layer (see for example, transport network layer 715 of FIG. 7B discussed infra). The Xw user plane protocol may also use services of the transport network layer to provide flow control of user data packets transferred over the L-Xw-UP interface 155. In LWIP, the flow control of user data packets may be on a per-UE basis, and control information related to the user data flow management of each UE may be conveyed over interface 155.

The Xw user plane protocol for LWIP (L-Xw-UP) may also be used for provisioning

L-Xw-UP specific sequence number (SN) information for user data transferred from the RAN node 111/112 to the LWIP-SeGW 150 for a specific UE configured with the LWIP bearer option; generating and providing information of successful transmission towards the UE of LWIP PDUs from the LWIP-SeGW 150 and/or WLAN 106 for user data of a UE configured with the LWIP bearer option; generating and providing information of LWIP PDUs that were not transferred towards the UE; generating and providing information of the currently desired buffer size at the LWIP-SeGW 150 and/or WLAN 106 for transmitting to the UE user data for a specific UE configured with the LWIP bearer option; generating and providing information of the currently minimum desired buffer size at the LWIP-SeGW 150 and/or WLAN 106 for transmitting to the UE user data for UEs configured with the LWIP bearer option. Moreover, the LWIP Xw interface 155 may be different than the LWA Xw interface at least in the following ways.

A first difference between LWIP Xw interface 155 and the LWA Xw interface is that the termination points of the LWIP Xw interface 155 is the LWIP-SeGW 150 and the RAN node 111/112, rather than a WLAN Termination (WT) entity and the RAN node 111/112 as in LWA. Because of this difference, if the LWA Xw interface were to be reused for LWIP, then further changes to the LWIP architecture may be required in order to include the WT. This may introduce further complexity to eNB RAN node implementation.

A second difference between LWIP Xw interface 155 and the LWA Xw interface is that LWA and LWIP use different payloads. In particular, LWA uses PDCP protocol data units (PDUs) whereas LWIP uses IP packets. The use of PDCP PDUs in LWA allows a one- to-one mapping between PDCP PDU SNs and LWA Xw SNs. Therefore, if the LWA Xw interface were to be reused for LWIP, then the one-to-one mapping between PDCP PDUs SNs and LWA Xw SNs is not possible and may require further complexity for reordering packets.

A third difference between LWIP Xw interface 155 and the LWA Xw interface is that the flow control mechanisms for the LWIP Xw interface 155 is on a per-UE basis, rather than a per-bearer basis as is the case with LWA implementations. One reason for this difference is that LWA flow control is defined is to prevent PDCP Hyper Frame Number (HFN) de-synchronization (de-sync). Since LWIP payloads include IP packets and do not include PDCP PDUs (as is the case with LWA), problems with PDCP HFN de-sync are less likely to occur. Nevertheless, the current LWIP standards require that any LWIP solution support legacy WLAN deployments without any need for modifications to the deployed WLAN nodes. Because a per-bearer flow control mechanism would require WLAN infrastructure changes, reusing the LWA Xw interface for LWIP implementations is not permitted.

In embodiments, the RAN node 111/112 may be connected to LWIP-SeGW 150 via LWIP Xw interface 155. Although not shown by FIG. IB, the RAN node 111/112 may be connected to a plurality of LWIP-SeGWs 150 over corresponding LWIP Xw interfaces 155. In some embodiments, the LWIP-SeGW 150 may be implemented in or by a separate physical entity. In other embodiments, the LWIP-SeGW 150 may be implemented as a function or logical entity within the RAN 110 or RAN node 111/112, for example, by using Network Function Virtualization, containerization, or the like.

The LWIP-SeGW 150 may support a subset of WT functionality and additional/alternative functionality required to support LWIP. The LWIP-SeGW 150 may be placed between the RAN node 111/112 and the WLAN network for security of packets that traverse WLAN 106 and to protect the Network Operator network. Furthermore, communications over the LWIP Xw interface 155 between the RAN node 111/112 and the LWIP-SeGW 150 may be confidentiality and integrity protected using Network Domain Security (NDS)/IP network layer security or the like.

In addition to terminating the IPsec tunnel 117 from the UE 102, the LWIP-SeGW 150 may perform rate limitation for Denial of Service (DoS) and/or distributed DoS (DDoS) protection on the RAN node 111/112 and its backhaul links. The UE 102 and the LWIP- SeGW 150 may perform mutual authentication during establishment of the IPsec tunnel 117 using an authentication key derived from a access stratum (AS) security association. In an example, the mutual authentication may be performed in phase 2 of the Internet Key Exchange Protocol Version 2 (IKEv2) handshake. In this example, the RAN node 111/112 may inform the LWIP-SeGW 150 of the expected initiation of IKEv2 handshake by the UE 102 for subsequent establishment of the IPsec tunnel 117. To inform the LWIP-SeGW 150 of the expected initiation of IKEv2 handshake, the LWIP-SeGW 150 may be provided with an Initiator identifier value (IDi) that the UE 102 will use in the IKEv2 handshake, and a LWIP-Pre-shared Key (PSK).

The LWIP-SeGW 150 may also enforce binding of an authenticated UE 102 to its

IP address, and apply anti-spoofing measures on received packets for the UE 102 outer and inner IP source addresses. The LWIP-SeGW 150 may also ensure that uplink traffic sent by a UE 102 is only sent towards the correct RAN node 111/112 by conveying the traffic to a GTP-U tunnel over the L-Xw-UP interface 155.

Referring back to FIG. 1A, the Radio Access Network (RAN) 110 can include one or more access nodes that enable the connections 103 and 104. These access nodes (ANs) can be referred to as base stations (BSs), NodeBs, evolved NodeBs (eNBs), next Generation NodeBs (gNBs), RAN nodes, Road Side Units (RSUs), and so forth, and can comprise ground stations (for example, terrestrial access points) or satellite stations providing coverage within a geographic area (for example, a cell). The RAN 110 may include one or more RAN nodes for providing macrocells, for example, macro RAN node 111, and one or more RAN nodes for providing femtocells or picocells (for example, cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), for example, low power (LP) RAN node 112.

Any of the RAN nodes 111 and 112 can terminate the air interface protocol and can be the first point of contact for the UEs 101 and 102. In some embodiments, any of the RAN nodes 111 and 112 can fulfill various logical functions for the RAN 110 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In accordance with some embodiments, the UEs 101 and 102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 111 and 112 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique (for example, for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (for example, for uplink and ProSe or sidelink communications), although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 111 and 112 to the UEs 101 and 102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

The physical downlink shared channel (PDSCH) may carry user data and higher- layer signaling to the UEs 101 and 102. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the UEs 101 and 102 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) may be performed at any of the RAN nodes 111 and 112 based on channel quality information fed back from any of the UEs 101 and 102. The downlink resource assignment information may be sent on the PDCCH used for (for example, assigned to) each of the UEs 101 and 102.

The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub- block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs). Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (for example, aggregation level, L=l, 2, 4, or 8).

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (EPDCCH) that uses PDSCH resources for control information transmission. The EPDCCH may be transmitted using one or more enhanced the control channel elements (ECCEs). Similar to above, each ECCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (EREGs). An ECCE may have other numbers of EREGs in some situations.

The RAN 110 is shown to be communicatively coupled to a core network— in this embodiment, Core Network (CN) 120 (for example, an Evolved Packet Core (EPC)) via an SI interface 113. In this embodiment the SI interface 113 is split into two parts, the Sl-U interface 114, which carries traffic data between the RAN nodes 111 and 112 and the serving gateway (S-GW) 122, and the Sl-mobility management entity (MME) interface 115, which is a signaling interface between the RAN nodes 111 and 112 and MMEs 121.

In this embodiment, the EPC network 120 comprises the MMEs 121, the S-GW 122, the Packet Data Network (PDN) Gateway (P-GW) 123, and a home subscriber server (HSS) 124. The MMEs 121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN). The MMEs 121 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions. The EPC network 120 may comprise one or several HSSs 124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

The S-GW 122 may terminate the SI interface 113 towards the RAN 110, and routes data packets between the RAN 110 and the EPC network 120. In addition, the S-GW 122 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

The P-GW 123 may terminate an SGi interface toward a PDN. The P-GW 123 may route data packets between the EPC network 123 and e2ernal networks such as a network including the application server 130 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 125. Generally, the application server 130 may be an element offering applications that use IP bearer resources with the core network (for example, UMTS Packet Services (PS) domain, LTE PS data services, etc.). In this embodiment, the P-GW 123 is shown to be communicatively coupled to an application server 130 via an IP communications interface 125. The application server 130 can also be configured to support one or more communication services (for example, Voice-over- Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 101 and 102 via the EPC network 120.

The P-GW 123 may further be a node for policy enforcement and charging data collection. Policy and Charging Enforcement Function (PCRF) 126 is the policy and charging control element of the EPC network 120. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with an RE's Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with an RE's IP- CAN session, a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN). The PCRF 126 may be communicatively coupled to the application server 130 via the P-GW 123. The application server 130 may signal the PCRF 126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 126 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI), which commences the QoS and charging as specified by the application server 130.

FIG. 2 illustrates an example of infrastructure equipment 200 in accordance with various embodiments. The infrastructure equipment 200 may be implemented as a base station, radio head, RAN node, etc., such as the RAN nodes 111 and 112, LWIP-SeGW 150, and/or AP 106 shown and described previously. The infrastructure equipment 200 may include one or more of application circuitry 205, baseband circuitry 210, one or more radio front end modules 215, memory 220, power management circuitry 225, power tee circuitry 230, network controller 235, network interface connector 240, satellite positioning circuitry 245, and user interface 250.

Application circuitry 205 may include one or more central processing unit (CPU) cores and one or more of cache memory, low drop-out voltage regulators (LDOs), interrupt controllers, serial interfaces such as SPI, I2C or universal programmable serial interface module, real time clock (RTC), timer-counters including interval and watchdog timers, general purpose input/output (I/O or IO), memory card controllers such as Secure Digital (SD/)MultiMediaCard (MMC) or similar, Universal Serial Bus (USB) interfaces, Mobile Industry Processor Interface (MIPI) interfaces and Joint Test Access Group (JTAG) test access ports. In some embodiments, user interface 250 may include one or more of physical or virtual buttons, such as a reset button, one or more indicators such as light emitting diodes (LEDs) and a display screen. As examples, the application circuitry 205 may include one or more Intel Pentium®, Core®, or Xeon® processor(s); Advanced Micro Devices (AMD) Ryzen® processor(s), Accelerated Processing Units (APUs), or Epyc® processors; and/or the like.

The baseband circuitry 210 may be implemented, for example, as a solder-down substrate including one or more integrated circuits, a single packaged integrated circuit soldered to a main circuit board or a multi-chip module containing two or more integrated circuits. Although not shown, baseband circuitry 210 may comprise one or more digital baseband systems, which may be coupled via an interconnect subsystem to a CPU subsystem, an audio subsystem, and an interface subsystem. The digital baseband subsystems may also be coupled to a digital baseband interface and a mixed-signal baseband sub-system via another interconnect subsystem. Each of the interconnect subsystems may include a bus system, point-to-point connections, network-on-chip (NOC) structures, and/or some other suitable bus or interconnect technology, such as those discussed herein. The audio sub-system may include digital signal processing circuitry, buffer memory, program memory, speech processing accelerator circuitry, data converter circuitry such as analog-to- digital and digital-to-analog converter circuitry, analog circuitry including one or more of amplifiers and filters, and/or other like components. In an aspect of the present disclosure, baseband circuitry 210 may include protocol processing circuitry with one or more instances of control circuitry (not shown) to provide control functions for the digital baseband circuitry and/or radio frequency circuitry (for example, the radio front end modules 215).

The radio front end modules (RFEMs) 215 may comprise a millimeter wave RFEM and one or more sub-millimeter wave radio frequency integrated circuits (RFICs). In some implementations, the one or more sub-millimeter wave RFICs may be physically separated from the millimeter wave RFEM. The RFICs may include connections to one or more antennas or antenna arrays, and the RFEM may be connected to multiple antennas. In alternative implementations, both millimeter wave and sub-millimeter wave radio functions may be implemented in the same physical radio front end module 215. The RFEMs 215 may incorporate both millimeter wave antennas and sub-millimeter wave antennas.

The memory circuitry 220 may include one or more of volatile memory including dynamic random access memory (DRAM) and/or synchronous dynamic random access memory (SDRAM), and nonvolatile memory (NVM) including high-speed electrically erasable memory (commonly referred to as Flash memory), phase change random access memory (PRAM), magnetoresistive random access memory (MRAM) and/or a three- dimensional crosspoint memory. Memory circuitry 220 may be implemented as one or more of solder down packaged integrated circuits, socketed memory modules and plug-in memory cards.

The power management integrated circuitry (PMIC) 225 may include voltage regulators, surge protectors, power alarm detection circuitry, and one or more backup power sources such as a battery or capacitor. The power alarm detection circuitry may detect one or more of brown out (under-voltage) and surge (over-voltage) conditions. The power tee circuitry 230 may provide for electrical power drawn from a network cable to provide both power supply and data connectivity to the infrastructure equipment 200 using a single cable.

The network controller circuitry 235 may provide connectivity to a network using a standard network interface protocol such as Ethernet, Ethemet over GRE Tunnels, Ethemet over Multiprotocol Label Switching (MPLS), or some other suitable protocol. Network connectivity may be provided to/from the infrastructure equipment 200 using a physical connection, which may be electrical (commonly referred to as a "copper interconnect"), optical, or wireless.

The positioning circuitry 245, which may include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations. Examples of navigation satellite constellations may include the global positioning system (GPS), Globalnaya Navigatsionnaya Sputnikovaya Sistema (GLONASS), Galileo, and/or BeiDou. The positioning circuitry 245 may provide data to application circuitry 205 which may include one or more of position data or time data. Application circuitry 205 may use time data to synchronize operations with other radio base stations.

FIG. 3 illustrates example components of a device 300 in accordance with some embodiments. In embodiments, the electronic device 300 may be implemented in or by UE 101 or UE 102 of FIG. 1, and/or. In some embodiments, the device 300 may include application circuitry 302, baseband circuitry 304, Radio Frequency (RF) circuitry 306, front- end module (FEM) circuitry 308, one or more antennas 310, and power management circuitry (PMC) 312 coupled together at least as shown. The components of the illustrated device 300 may be included in a RE or a RAN node. In some embodiments, the device 300 may include less elements (for example, a RAN node may not utilize application circuitry 302, and instead include a processor/controller to process IP data received from an EPC and/or a 5GC)). In some embodiments, the device 300 may include additional elements such as, for example, network interface cards, display, camera, sensor(s), or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (for example, said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations). The components may communicate over a suitable bus technology, such as industry standard architecture (ISA); extended ISA (EISA); peripheral component interconnect (PCI); peripheral component interconnect extended (PCIx); PCI express (PCIe); a proprietary bus, for example, used in a SoC based system; an I2C interface, an SPI interface, point-to-point interfaces, a power bus, or any number of other technologies.

The application circuitry 302 may include one or more application processors 302A. For example, the application circuitry 302 may include circuitry such as, but not limited to, one or more single-core or multi-core processors, a microprocessor, a multithreaded processor, an ultra-low voltage processor, an embedded processor, or other known processing element. The processor(s) 302A may include any combination of general- purpose processors and dedicated processors (for example, graphics processors, application processors, etc.). The processors 302A may be coupled with or may include memory /storage 302B (also referred to as "computer readable media 302B" and the like) and may be configured to execute instructions stored in the memory /storage to enable various applications or operating systems to run on the device 300. In some embodiments, processors of application circuitry 302 may process IP data packets received from an EPC. As examples, the application circuitry 302 may include one or more Intel Atom® or Core M® processor(s); A series, S series, W series, etc. processor(s) provided by Apple Inc. ; Qualcomm snapdragon® processor(s); Samsung Exynos® processor(s); and/or the like.

The memory /storage 302B may comprise any number of memory devices used to provide for a given amount of system memory. As an example, the memory 302B may include random access memory (RAM) in accordance with a Joint Electron Devices Engineering Council (JEDEC) double data rate (DDR) or low power double data rate (LPDDR)-based design. In various implementations, individual memory devices may be formed of any number of different package types, such as single die package (SDP), dual die package (DDP) or quad die package (Q17P), dual inline memory modules (DIMMs) such as microDIMMs or MiniDIMMs, and/or any other like memory devices. To provide for persistent storage of information such as data, applications, operating systems and so forth, the memory /storage 302B may include one or more mass-storage devices, such as a solid state disk drive (SSDD); flash memory cards, such as SD cards, microSD cards, xD picture cards, and the like, and USB flash drives; on-die memory or registers associated with the processors 302A (for example, in low power implementations); a micro hard disk drive (HDD); three dimensional cross-point (3D XPOINT) memories from Intel® and Micron®, etc.

The baseband circuitry 304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 304 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 306 and to generate baseband signals for a transmit signal path of the RF circuitry 306. Baseband processing circuity 204 may interface with the application circuitry 302 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 306. For example, in some embodiments, the baseband circuitry 304 may include a third generation (3G) baseband processor 304A, a fourth generation (4G) baseband processor 304B, a fifth generation (5G) baseband processor 304C, or other baseband processor(s) 304D for other existing generations, generations in development or to be developed in the future (for example, second generation (2G), si2h generation (6G), etc.). The baseband circuitry 304 (for example, one or more of baseband processors 304A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 306. In other embodiments, some or all of the functionality of baseband processors 304A-D may be included in modules stored in the memory 304G and executed via a Central Processing Unit (CPU) 304E. 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 304 may include Fast-Fourier Transform (FFT), precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 304 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 304 may include one or more audio digital signal processor(s) (DSP) 304F. The audio DSP(s) 304F 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 304 and the application circuitry 302 may be implemented together such as, for example, on a system on a chip (SoC), an integrated circuit, or a single package.

In some embodiments, the baseband circuitry 304 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 304 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 304 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

In some embodiments, the receive signal path of the RF circuitry 306 may include mixer circuitry 306a, amplifier circuitry 306b and filter circuitry 306c. In some embodiments, the transmit signal path of the RF circuitry 306 may include filter circuitry 306c and mixer circuitry 306a. RF circuitry 306 may also include synthesizer circuitry 306d for synthesizing a frequency for use by the mixer circuitry 306a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 306a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 308 based on the synthesized frequency provided by synthesizer circuitry 306d. The amplifier circuitry 306b may be configured to amplify the down-converted signals and the filter circuitry 306c 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 304 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 306a 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 306a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 306d to generate RF output signals for the FEM circuitry 308. The baseband signals may be provided by the baseband circuitry 304 and may be filtered by filter circuitry 306c.

In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a 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 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (for example, Hartley image rejection). In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a 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 306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 304 may include a digital baseband interface to communicate with the RF circuitry 306.

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 306d 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 306d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 306d may be configured to synthesize an output frequency for use by the mixer circuitry 306a of the RF circuitry 306 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 306d 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 304 or the applications processor 202 depending on the desired output frequency. In some embodiments, a divider control input (for example, N) may be determined from a look-up table based on a channel indicated by the applications processor 302.

Synthesizer circuitry 306d of the RF circuitry 306 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+1 (for example, 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 306d 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 (for example, 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 306 may include an IQ/polar converter.

FEM circuitry 308 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 310, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 306 for further processing. FEM circuitry 308 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 306 for transmission by one or more of the one or more antennas 310. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 306, solely in the FEM 208, or in both the RF circuitry 306 and the FEM 208.

In some embodiments, the FEM circuitry 308 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 (for example, to the RF circuitry 306). The transmit signal path of the FEM circuitry 308 may include a power amplifier (PA) to amplify input RF signals (for example, provided by RF circuitry 306), and one or more filters to generate RF signals for subsequent transmission (for example, by one or more of the one or more antennas 310).

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

While FIG. 3 shows the PMC 312 coupled only with the baseband circuitry 304.

However, in other embodiments, the PMC 2 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 302, RF circuitry 306, or FEM 208.

In some embodiments, the PMC 312 may control, or otherwise be part of, various power saving mechanisms of the device 300. For example, if the device 300 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 300 may power down for brief intervals of time and thus save power.

If there is no data traffic activity for an e2ended period of time, then the device 300 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 300 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 300 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 302 and processors of the baseband circuitry 304 may be used to execute elements of one or more instances of a protocol stack. As used herein, the terms "instantiate", "instantiation", and the like may refer to the creation of an instance, and an "instance" may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. For example, processors of the baseband circuitry 304, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 304 may utilize data (for example, packet data) received from these layers and further execute Layer 4 functionality (for example, 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. 4 illustrates example interfaces of baseband circuitry in accordance with some embodiments. As discussed above, the baseband circuitry 304 of FIG. 3 may comprise processors 304A-304E and a memory 304G utilized by said processors. Each of the processors 304A-304E may include a memory interface, 304A-304E, respectively, to send/receive data to/from the memory 304G.

The baseband circuitry 304 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 312 (for example, an interface to send/receive data to/from memory e2ernal to the baseband circuitry 304), an application circuitry interface 314 (for example, an interface to send/receive data to/from the application circuitry 302 of FIG. 3), an RF circuitry interface 316 (for example, an interface to send/receive data to/from RF circuitry 306 of FIG. 3), a wireless hardware connectivity interface 318 (for example, an interface to send/receive data to/from Near Field Communication (NFC) components, Bluetooth® components (for example, Bluetooth® Low Energy), Wi-Fi® components, and other communication components), and a power management interface 320 (for example, an interface to send/receive power or control signals to/from the PMC 312.

FIG. 5 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (for example, a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. In embodiments, hardware resources 500 may be employed in or as any of the elements, devices, components, etc. discussed with regard to FIGS. 1A, IB, 2, 3, and 4. Specifically, FIG. 5 shows a diagrammatic representation of hardware resources 500 including one or more processors (or processor cores) 510, one or more memory /storage devices 520, and one or more communication resources 530, each of which may be communicatively coupled via a bus 540. For embodiments where node virtualization (for example, NFV, or when Hardware resources 500 employed in or as a core network element or RAN node/element) is utilized a hypervisor 502 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 500.

The processors 510 (for example, 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 512 and a processor 514.

The memory /storage devices 520 may include main memory, disk storage, or any suitable combination thereof. The memory /storage devices 520 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 readonly memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, and/or any other type of memory device technology, such as those discussed herein.

The communication resources 530 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 404 or one or more databases 503 via a network 508. For example, the communication resources 530 may include wired communication components (for example, for coupling via a Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (for example, Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

Instructions 450 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 510 to perform any one or more of the methodologies discussed herein. The instructions 550 may reside, completely or partially, within at least one of the processors 510 (for example, within the processor's cache memory), the memory /storage devices 520, or any suitable combination thereof. Furthermore, any portion of the instructions 550 may be transferred to the hardware resources 500 from any combination of the peripheral devices 504 or the databases 503. Accordingly, the memory of processors 510, the memory /storage devices 520, the peripheral devices 504, and the databases 503 are examples of computer-readable and machine- readable media.

FIG. 6 is an illustration of a control plane protocol stack in accordance with some embodiments. In this embodiment, a control plane 500 is shown as a communications protocol stack between the UE 101 (or alternatively, the UE 102), the RAN node 11 1 (or alternatively, the RAN node 112), and the MME 121.

The PHY layer 501 may transmit or receive information used by the MAC layer 502 over one or more air interfaces. The PHY layer 501 may further perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (for example, for initial synchronization and handover purposes), and other measurements used by higher layers, such as the RRC layer 505. The PHY layer 501 may still further perform error detection on the transport channels, forward error correction (FEC) coding/decoding of the transport channels, modulation/demodulation of physical channels, interleaving, rate matching, mapping onto physical channels, and Multiple Input Multiple Output (MIMO) antenna processing.

The MAC layer 502 may perform mapping between logical channels and transport channels, multiplexing of MAC service data units (SDUs) from one or more logical channels onto transport blocks (TB) to be delivered to PHY via transport channels, de-multiplexing MAC SDUs to one or more logical channels from transport blocks (TB) delivered from the PHY via transport channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.

The RLC layer 503 may operate in a plurality of modes of operation, including: Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM). The RLC layer 503 may execute transfer of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transfers, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transfers. The RLC layer 503 may also execute re-segmentation of RLC data PDUs for AM data transfers, reorder RLC data PDUs for UM and AM data transfers, detect duplicate data for UM and AM data transfers, discard RLC SDUs for UM and AM data transfers, detect protocol errors for AM data transfers, and perform RLC re-establishment.

The PDCP layer 504 may execute header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-sequence delivery of upper layer PDUs at re-establishment of lower layers, eliminate duplicates of lower layer SDUs at re- establishment of lower layers for radio bearers mapped on RLC AM, cipher and decipher control plane data, perform integrity protection and integrity verification of control plane data, control timer-based discard of data, and perform security operations (for example, ciphering, deciphering, integrity protection, integrity verification, etc.).

The main services and functions of the RRC layer 505 may include broadcast of system information (for example, included in Master Information Blocks (MIBs) or System Information Blocks (SIBs) related to the non-access stratum (NAS)), broadcast of system information related to the access stratum (AS), paging, establishment, maintenance and release of an RRC connection between the UE and E-UTRAN (for example, RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance and release of point to point Radio Bearers, security functions including key management, inter radio access technology (RAT) mobility, and measurement configuration for UE measurement reporting. Said MIBs and SIBs may comprise one or more information elements (IEs), which may each comprise individual data fields or data structures.

The UE 101 and the RAN node 111 may utilize a Uu interface (for example, an LTE- Uu interface) to exchange control plane data via a protocol stack comprising the PHY layer 501, the MAC layer 502, the RLC layer 503, the PDCP layer 504, and the RRC layer 505.

The non-access stratum (NAS) protocols 506 form the highest stratum of the control plane between the UE 101 and the MME 121. The NAS protocols 506 support the mobility of the UE 101 and the session management procedures to establish and maintain IP connectivity between the UE 101 and the P-GW 123.

The SI Application Protocol (Sl-AP) layer 515 may support the functions of the SI interface and comprise Elementary Procedures (EPs). An EP is a unit of interaction between the RAN node 111 and the CN 120. The Sl-AP layer services may comprise two groups: UE-associated services and non UE-associated services. These services perform functions including, but not limited to: E-UTRAN Radio Access Bearer (E-RAB) management, UE capability indication, mobility, NAS signaling transport, RAN Information Management (RIM), and configuration transfer.

The Stream Control Transmission Protocol (SCTP) layer (alternatively referred to as the SCTP/IP layer) 514 may ensure reliable delivery of signaling messages between the RAN node 111 and the MME 121 based, in part, on the IP protocol, supported by the IP layer 513. The L2 layer 512 and the LI layer 511 may refer to communication links (for example, wired or wireless) used by the RAN node and the MME to exchange information.

The RAN node 111 and the MME 121 may utilize an SI -MME interface to exchange control plane data via a protocol stack comprising the LI layer 511, the L2 layer 512, the IP layer 513, the SCTP layer 514, and the Sl-AP layer 515.

FIG. 7A is an illustration of a user plane protocol stack in accordance with some embodiments. In this embodiment, a user plane 700A is shown as a communications protocol stack between the UE 101 (or alternatively, the UE 102), the RAN node 111 (or alternatively, the RAN node 112), the S-GW 122, and the P-GW 123. The user plane 700 may utilize at least some of the same protocol layers as the control plane 600. For example, the UE 101 and the RAN node 111 may utilize a Uu interface (for example, an LTE-Uu interface) to exchange user plane data via a protocol stack comprising the PHY layer 601, the MAC layer 602, the RLC layer 603, the PDCP layer 604.

The application layer 714 may be a layer in which a user of the UE 101/102 interacts with software applications being executed, for example, by application circuitry 302. The application layer 614 may also provide one or more interfaces for software applications to interact with communications systems of the UE 101/102, such as the baseband circuitry 304. In some implementations the IP layer 713 and/or the application layer 714 may provide the same or similar functionality as layers 5-7, or portions thereof, of the Open Systems Interconnection (OSI) model (for example, OSI Layer 7 - the application layer, OSI Layer 6 - the presentation layer, and OSI Layer 5 - the session layer).

The Internet Protocol (IP) layer 613 (also referred to as the "Internet layer") may be used to perform packet addressing and routing functionality. The IP layer 713 may assigned IP addresses to user data packets in any of IPv4, IPv6, or PPP formats, for example. The General Packet Radio Service (GPRS) Tunneling Protocol for the user plane (GTP-U) layer 704 may be used for carrying user data within the GPRS core network and between the radio access network and the core network. The user data transported can be packets in any of IPv4, IPv6, or PPP formats, for example. The UDP and IP security (UDP/IP) layer 703 may provide checksums for data integrity, port numbers for addressing different functions at the source and destination, and encryption and authentication on the selected data flows.

The RAN node 111/112 and the S-GW 122 may utilize an Sl-U interface to exchange user plane data via a protocol stack comprising the LI layer 511, the L2 layer 512, the UDP/IP layer 703, and the GTP-U layer 704. The S-GW 122 and the P-GW 123 may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising the Layer 1 (LI) layer 611, the Layer 2 (L2) layer 612, the UDP/IP layer 703, and the GTP-U layer 704. As discussed above with respect to FIG. 6, NAS protocols support the mobility of the UE 101/102 and the session management procedures to establish and maintain IP connectivity between the UE 101/102 and the P-GW 123.

FIG. 7B is an illustration of an LWIP Xw user plane protocol stack in accordance with some embodiments. In this embodiment, an LWIP Xw user plane (L-Xw-UP) 700B is a communications protocol, which may be defined between a RAN node 111/112 and an LWIP-SeGW 150. The transport network layer 715 (also referred to as a "transport layer") may be built on IP transport, and the GTP-U 704 may be used on top of the UDP/IP layer 703 (comprising UDP layer 703a and IP layer 703b) to carry the user plane PDUs (UP- PDUs).

The L-Xw-UP 700B protocol may be used between the RAN node 111/112 and the

LWIP-SeGW 150. The L-Xw-UP 700B may provide non-guaranteed delivery of user plane PDUs such as the LWIPEP PDUs discussed herein, using a single tunnel for all LWIP bearers associated with a UE 102. The L-Xw-UP 700B protocol may use services of the transport network layer 715 to allow flow control of user data packets transferred over the L-Xw-UP interface 155. In embodiments, the various processor circuitry (for example, processors of application circuitry 205/302 and processors of the baseband circuitry 210/304) may be used to execute elements of one or more instances of the L-Xw-UP 700B, where each the L-Xw-UP 700B instance is associated with an individual UE 102 only. In this way, each L-Xw-UP 700B instance may perform various LWIP functions for its corresponding UE 102 only.

The following functions may be provided by the L-Xw-UP 700B: provisioning of L-Xw-UP 700B specific SN information for user data transferred from the RAN node 111/112 to the LWIP-SeGW 150 (and/or WLAN 106) for a specific UE 102 configured with the LWIP bearer option; generating and providing information of successful transmission towards the UE 102 of LWIPEP PDUs from LWIP-SeGW 150 (and/or WLAN 106) for user data of a UE 102 configured with the LWIP bearer option; generating and providing information of LWIPEP PDUs that were not transferred towards the UE 102; generating and providing information of a currently desired buffer size at the LWIP-SeGW 150 (or the WLAN 106) for transmitting to a UE 102 user data for a specific UE 102 configured with the LWIP bearer option; and generating and providing information of the currently minimum desired buffer size at the LWIP-SeGW 150 (or the WLAN 106) for transmitting to a UE 102 user data for a specific UE 102 configured with the LWIP bearer option.

The transport network layer 715 of the L-Xw-UP 700B may be responsible for the transfer of user data. In embodiments, the L-Xw-UP interface 155 may convey one UL data stream and one DL data stream per UE 102. The DL data stream may be used for DL user data forwarding from the RAN node 111/112 to the LWIP-SeGW 150, and the UL data stream may be used for UL user data forwarding from the LWIP-SeGW 150 to the RAN node 111/112. Each data stream may be carried on a dedicated transport bearer. The identity of a transport bearer signaled in the Radio Network Layer (RNL) control plane may comprise the IP address and the tunnel endpoint identifier (TEID) of the corresponding GTP tunnel allocated by the target node

Additionally, the UL data stream may be used for carrying DL data delivery status information to the RAN node 111/112. In some embodiments, the transport layer 715 may provide flow control services for the data streams. The flow control services may include controlling or managing the rate of data transmission between two nodes (for example, the LWIP-SeGW 150 and RAN node 111/112) to avoid data buffer overflow or data buffer underflow. In such embodiments, the UL data stream may be used for carrying flow control feedback to the RAN node 111/112. Example procedures for transferring DL user data, conveying DL data delivery status information, and conveying flow control feedback information is shown by FIG. 13.

The IP layer 703b may support fragmentation and assembly of GTP packets, and may support IPv6 and/or IPv4 address schemes. There may be one or several IP addresses in both the RAN node 111/112 and the LWIP-SeGW 150. A packet processing function implemented by the RAN node 111/112 may send downstream packets corresponding to UE 102 to the LWIP-SeGW 150 using an IP address of the LWIP-SeGW 150. A packet processing function implemented by the LWIP-SeGW 150 may send upstream packets to the RAN node 111/112 using an IP address of the RAN node 111/112, which may be received over the Xw control plane. The Transport Layer Address signaled in Xw control plane messages may be a bit string of either 32 bits where IPv4 addressing is used, or 128 bits where IPv6 addressing is used.

The data link layer (or layer 2) 612 may comprise any data link protocol that fulfils the requirements toward the upper layer, and may comprise a logical link sublayer and/or a MAC sublayer (for example, MAC layer 602 discussed previously and/or WLAN MAC layer 802 discussed infra). The physical link layer (or layer 1) 611 may comprise any physical layer protocol that fulfils the requirements toward upper layer, and may comprise a physical link sublayer (for example, PHY layer 601 discussed previously and/or WLAN PHY layer 801 discussed infra).

FIG. 8 is an illustration of an LWIP protocol architecture 800 in accordance with some embodiments. In this example, the LWIP protocol architecture 800 is shown as a communications protocol stack between a UE 102, WLAN 106, LWIP-SeGW 150, and RAN node 111/112. Additionally, the LWIP protocol architecture 800 may utilize at least some of the same protocol layers as the control plane 600 and the user plane 700, which may operate in the same manner as discussed previously, but with the following modifications. In addition, the LWIP protocol architecture 800 also includes an LWIPEP entity 810 at both the UE 102 and RAN node 111/112, and a WLAN PHY layer 801 and WLAN MAC layer 802 at the UE 102.

The WLAN MAC layer 802 and the WLAN PHY layer 801 may provide a variety of functions that support the operation of IEEE 802.11 -based WLAN. The WLAN MAC layer 802 manages and maintains communications with WLAN 106 by coordinating access to a shared communications medium (radio channel). The WLAN MAC layer 802 may also control the WLAN PHY layer 801 to perform carrier sensing, transmission, and receiving of WLAN frames. The WLAN MAC layer 802 and the WLAN PHY layer 801 may also perform various other functions as specified by one or more IEEE 802.11 specifications.

In LWIP implementations, the LTE-WLAN integration may occur using PDCP SDUs above the PDCP layer 604. The RAN node 111/112 may control activation of LWIP based on the UE 102 connectivity with a specific WLAN 106. The RRC layer 605 may control and configure respective LWIPEP entities 810. For an LWIPEP entity 810 configured at the RAN node 111/112, a peer LWIPEP entity 810 may be configured at the UE 102 and vice versa. Once LWIP is activated, the RAN node 111/112 may segregate incoming DL packets towards the UE 102 for offloading via the WLAN 106 at the LWIPEP layer 810 above PDCP 604, and the UL packets from the UE 102 may be aggregated by the RAN node 111/112 at the same logical point.

The LWIP-SeGW 150 is be placed between the RAN node 111/112 and the WLAN 106 network for security of packets that traverse WLAN 106 and to protect the operator network. This is because PDCP security is bypassed for data routed through the WLAN 106 and security of the WLAN 106 is not assumed to be adequate. The LWIP-Xw interface 155 between the RAN node 111/112 and the LWIP-SeGW 150 may be confidentiality and integrity protected by Network Domain Security for IP based protocols (NDS/IP) or using some other suitable confidentiality/integrity protocol.

As discussed previously, the LWIP tunnel 160 may comprise the L-Xw-UP interface 155 and an IPsec tunnel 117. In embodiments, the IPsec tunnel 117 may be UE-specific IPsec security association tunnel that is established between the UE 102 and a public IP address 850 ("Public IP@ 850" in FIG. 8) of the LWIP-SeGW 150 in tunnel mode. Additionally, the RAN node 111/112 and/or the LWIP-SeGW 150 may communicate with one another by GTP-U protocol means. This may include a GTP-U tunnel identified using a private IP address 811/812 ("Private IP@ 811/812" in FIG. 8), a TEID, and a UDP port number of the RAN node 111/112, and using an IP address (Public IP@ 850 or another private IP address), a TEID, and a UDP port number of the LWIP-SeGW 150. In some implementations, the GTP-U protocol means may include an Xw RAN Container GTP-U extension header. The Xw RAN Container GTP-U extension header may be transmitted in a G-PDU over the LWIP Xw user plane interface 155 between the eNB and the LWIP- SeGW 150.

The LWIP entities 810 may be responsible for encapsulating IP packets for transmission over/through the LWIP tunnel 160 and decapsulating IP packets received over the LWIP tunnel 160 according to the LWIP Encapsulation Protocol. The LWIPEP entity 810 responsible for decapsulating LWIPEP PDUs is referred to as an LWIPEP receiver, and the LWIPEP entity 810 responsible for encapsulating LWIPEP SDUs is referred to as an LWIPEP transmitter The PDUs generated by an LWIPEP entity 810 for transmission over WLAN may be referred to as an "LWIP PDU", "LWIPEP PDU", "LWIP data PDU," or the like.

An LWIPEP data PDU may comprise an LWIPEP header and an LWIPEP SDU.

The LWIPEP Header may be a Generic Routing Encapsulation (GRE) header as specified by D. Farinacci et al, "Generic Routing Encapsulation (GRE)", Internet Engineering Task Force (IETF), Request for Comments (RFC) 2784 (2000) and/or G. Dommety, "Key and Sequence Number Extensions to GRE", IETF, RFC 2890 (2000). The LWIPEP header may have a fixed size of eight bytes (if only a 'Key' field is included) or twelve bytes (if both the 'Key' and 'Sequence Number' fields are included). The LWIPEP transmitter may assign sequence numbers (SNs) to all packets and may populate the 'Sequence Number' field of the LWIPEP header with the these sequence numbers. The 'Key' field in the LWIPEP header may be populated with a DRB Identity of an associated data bearer and/or associated DRB. In some embodiments, the LWIPEP transmitter may set one or more (for example, 5) least significant bits (LSBs) of the Key field in the GRE header to a DRB Identity associated with the LWIPEP SDU and set the remaining most significant bits (MSBs) to 'Ο'. An LWIPEP transmitter may populate the Key field with a DRB identity associated with an offloaded UL bearer of UL bearer packets to be sent over the LWIP tunnel 160.

An LWIPEP transmitter may receive the LWIPEP SDUs from upper layers (for example, IP layer 713 and/or application layer 714), generate LWIPEP PDUs, and provide the LWIPEP PDUs to lower layers for delivery to the peer LWIPEP entity 810 via the LWIP Tunnel 160. An LWIPEP receiver may receive LWIPEP PDUs from lower layers, and reorder/reassemble corresponding LWIPEP SDUs of the received the packets according to the 'Sequence Number' field before delivering them to higher layers.

The LWIPEP PDUs discussed herein may each be a bit string that is byte aligned (for example, multiple of 8 bits) in length. In FIGS. 9A-9C, the bit strings are represented by tables in which the most significant bit is the leftmost bit of the first line of the table, the least significant bit is the rightmost bit on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order of the lines. The bit order of each parameter field within an LWIPEP PDU is represented with the first and most significant bit in the leftmost bit and the last and least significant bit in the rightmost bit. An LWIPEP SDU is a bit string that is byte aligned (e.g., multiple of 8 bits) in length. An LWIPEP SDU is included into an LWIPEP PDU from the first bit onward. Only one type of LWIPEP PDU is defined, which is the LWIPEP data PDU. The LWIPEP PDUs may be conveyed in a frame having a structure as shown by FIGS. 9A-9C.

FIG. 9A shows an example frame format 900A in accordance with various embodiments. Unless otherwise indicated, fields having multiple bits within an octet have the MSB located at a higher bit position. In addition, if a field spans several octets, MSBs are located in lower numbered octets. The frame 900A may be transmitted on the L-Xw-UP interface 155 starting from the lowest numbered octet. Within each octet, the bits may be sent according to decreasing bit position (for example, starting with bit position 7). Spare bits may be set to "0" by the transmitter and may not be checked by the receiver. The header part of the frame is always an integer number of octets. The payload part is octet aligned (by adding 'Padding' when needed). The receiver may be able to remove an additional spare extension field that may be present at the end of a frame.

FIG. 9B shows an example frame format 900B in accordance with various embodiments. The frame format 900B may be a DL user data frame used to convey DL user data. Frame format 900B may be a PDU type 0 where the value "0" is located in the PDU type field. Frame format 900B may be defined to allow the LWIP-SeGW 150 (or the WLAN 106) to detect lost L-Xw-UP packets and is associated with the transfer of a Downlink LWIPEP PDUs over the Xw interface 155.

FIG. 9C shows an example frame format 900B in accordance with various embodiments. The frame format 900C may be used to convey DL data delivery status messages (discussed infra). Frame format 900C may be a PDU type 1. Frame format 900C may be defined to transfer feedback to allow the RAN node 111/112 to control the downlink user data flow via the LWIP-SeGW 150.

In FIGS. 9B-9C, the PDU Type may indicate the structure of the Xw UP frame. The PDU type field in each of frame formats 900B and 900C may include the value of the PDU Type it identifies (for example, "0" for PDU Type 0 or "1" for PDU Type 1). The PDU type may be located in bit 4 to bit 7 in the first octet of the frame 900D or 900C. PDU type field may have a value range of {0=DL USER DATA, 1=DL DATA DELIVERY STATUS, 2- 15=reserved for future PDU type extensions}, and a field length of 4 bits. The spare field may be set to "0" by the sender and may not be interpreted by the receiver. This field may be reserved for later versions. This field may have a value range of (0-2n-l), and a field length of n bits, where n is a number.

The Xw-U sequence number field of FIGS. 9B-9C may indicate an Xw-U sequence number as assigned by a respective RAN node 111/112. This field may have a value range of {0..224-1 }, and a field length of 3 octets. The spare extension field may be used for later extensions of the frames 900A-900C and may not be sent. The spare extension may be used for additional new fields that might be added later. The spare extension can be an integer number of octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on the PDU type. This field may have a value range of 0- 2m*8-l, and a field length of 0-m octets. For the PDU Types defined in the present document m=4.

In FIG. 9C, the Lost packet Report field of FIG. 9C may indicate the presence of a list of lost Xw-U packets in a respective Xw UP frame. This field may have a value range of {0=Lost Frame List not present, l=Lost Frame List present}, and a field length of 1 bit. The final frame indication field may indicate feedback about the in-sequence delivery status of LWIPEP PDUs at the LWIP-SeGW 150 towards the UE 102. This field may have a value range of {0..224-1 }, and a field length of 3 octets.

The highest successfully delivered Xw-U Sequence Number field may indicate feedback about an in-sequence transmission status of LWIP PDUs at the LWIP-SeGW 150 (or WLAN 106) towards the UE 102. This field may have a value range of {0..224-1 }, and a field length of 3 octet.

The desired buffer size for the UE field may indicate the desired buffer size for a specific UE 102. This field may have a value range of {0..232-1 }, and a field length of 4 octets. The minimum desired buffer size for the UE field may indicate the minimum desired buffer size for a specific UE 102. This field may have a value range of {0..232-1 }, and a field length of 4 octets.

The number of lost Xw-U sequence number ranges reported field may indicate the number of Xw-U Sequence Number ranges reported to be lost. This field may have a value range of { 1..256}, and a field length of 1 octet. The start of lost Xw-U sequence number range field may indicates the start of an Xw-U sequence number range. This field may have a value range of {0..218-1 }, and a field length of 3 octet. The end of lost Xw-U sequence number range field may indicates the end of the Xw-U sequence number range. This field may have a value range of {0..218-1 }, and a field length of 3 octet.

FIGS. 10-16 illustrate processes 1000-1600, respectively, for reserving resources for

V2X SL communications, according to various embodiments. For illustrative purposes, the operations of processes 1000-1600 are described as being performed by the various devices discussed with regard to FIGS. 1A-5. Some of the process 1000-1600 may include communications between various devices, and it should be understood that such communications may be facilitated by the various circuitry as described with regard to FIGS. 1A-5 using the various messages/frames, protocols, entities, layers, etc. discussed with regard to FIGS. 6-9C. Moreover, while particular examples and orders of operations are illustrated in FIGS. 10-16, the depicted orders of operations should not be construed to limit the scope of the embodiments in any way. Rather, the depicted operations may be reordered, broken into additional operations, combined, and/or omitted altogether while remaining within the spirit and scope of the present disclosure.

FIG. 10 shows an example LWIP tunnel setup and data bearer configuration procedure 1000 in accordance with various embodiments. Process 1000 may begin at operation 1005 where the RAN node 111/112 transmits an RRCConnectionReconfiguration message to the UE 102 to configure the UE 102 to perform WLAN measurements for an LWIP operation. For example, the RRCConnectionReconfiguration message may include a WLAN measurement object and/or WLAN identifiers (for example, service set identifier (SSID), basic SSID (BSSID), Extended SSID (ESSID), homogenous ESSID (HESSID), or the like), WLAN carrier information, WLAN band(s) (for example, 2.4GHz, 5GHz and 60GHz), etc. The WLAN measurement reporting may be triggered using received signal strength indicators (RSSI).

At operation 1010, the UE 102 may apply the new configuration and reply by transmitting a RRCConnectionReconfigurationComplete message to the RAN node 111/112. In embodiments, the RRCConnectionReconfigurationComplete message may include a WLAN measurement report. The WLAN measurement report may comprise, for each included WLAN measurement object, RSSI and WLAN identifier, and may also contain WLAN carrier information, WLAN band, channel utilization, station count, admission capacity, backhaul rate, and an indication whether the UE is connected to the WLAN.

In embodiments, the configuration included in the RRCConnectionReconfiguration may include instructions or commands to perform WLAN measures of one or more WLANs 106. At operation 1015, the UE 102 may transmit WLAN measurements to the RAN node 111/112. At operation 1020, the RAN node 111/112 may send an LWIP Addition Request message to request the LWIP-SeGW 150 to allocate resources for a specific UE 102, including security material and the like. If the LWIP-SeGW 150 is able to admit the tunnel request, the LWIP-SeGW 150 may respond by sending an LWIP Addition Request Acknowledge (ACK) message to the RAN node 111/112.

At operation 1030, the RAN node 111/112 may transmit another RRCConnectionReconfiguration message to the UE 102 including a WLAN mobility set. The WLAN mobility set may be a set of one or more WLAN identifier(s) (e.g., SSID, BSSID, HESSID, etc.) in a wlan-MobilitySet field or IE in the VarWLAN-MobilityConfig variable or IE of the RRCConnectionReconfiguration message. The WLAN 106 may be considered to be inside the WLAN mobility set if the WLAN 106 identifiers match all WLAN identifiers of at least one entry in the wlan-MobilitySet and may be considered outside the WLAN mobility set otherwise. At operation 1035, the UE 102 may apply the new configuration and may reply be transmitting an RRCConnectionReconfigurationComplete message to the RAN node 111/112.

At operation 1040, the UE 102 may associate with the WLAN 106 in consideration of the WLAN mobility set, if not already associated. When the UE 102 receives the new or updated WLAN mobility set, the UE 102 may initiate connection to the WLAN 106 inside the WLAN mobility set, if not already connected to the WLAN 106. The UE 102 can perform WLAN mobility within the WLAN mobility set (connect or reconnect to a WLAN 106 inside the WLAN mobility set) without any signaling to the RAN node 111/112. Operation 1040 may also include starting WLAN status monitoring.

At operation 1045, the UE 102 may transmit a WLANConnectionStatusReport to the RAN node 111/112 to confirm the WLAN association. The WLANConnectionStatusReport may be used to provide feedback to the RAN node 111/112 related to the status and operation of the WLAN 106. For example, the WLANConnectionStatusReport may include a WLAN connection failure indication, a WLAN connection success indication, a WLAN temporary suspension indication, and/or a WLAN connection resumption indication. This report may be used to inform the RAN node 111/112 about the status of the WLAN connection for LWIP purposes, such as managing the LWIP tunnel 160 and the like. In some embodiments, at any point during LWIP operation the UE 102 is unable to establish or continue the LWIP operation, the UE 102 may send a WLANConnectionStatusReport message to indicate "WLAN connection failure" to the RAN node 111/112. Additionally, when the UE 102 is not able to support the LWIP operation for a temporary duration, the UE 102 may suspend the LWIP operation by sending a first WLANConnectionStatusReport message to the RAN node 111/112 to indicate "WLAN temporary suspension", and may resume the LWIP operation by sending a second WLANConnectionStatusReport message to the RAN node 111/112 to indicate "WLAN connection resumption" and/or "WLAN connection success".

At operation 1050, the RAN node 111/112 may transmit another RRCConnectionReconfiguration message to the UE 102 including the necessary parameters to establish IPSec tunnel 117 over WLAN 106. This RRCConnectionReconfiguration message may also include a configuration for a data bearer to utilize the IPsec tunnel 117. For example, the RRCConnectionReconfiguration message may include an LWIP- Configuration IE, which may include a tunnelConfigLWIP field/IE that includes the parameters to be used for establishing the LWIP tunnel 160 and an lwip-MobilityConfig field/IE that indicates a WLAN mobility set to be used for LWIP. The parameters included in the tunnelConfigLWIP IE may include, for example, an ip-address parameter to indicate the LWIP-SeGW IP Address to be used by the UE for initiating LWIP Tunnel establishment; an ike-Identity parameter to indicate the IKE Identity elements (IDi) to be used in IKE Authentication Procedures; an lwip-Counter parameter to indicate the parameter used by UE 102 for computing the security keys used in LWIP tunnel establishment; and/or other like parameters. Furthermore, the RRCConnectionReconfiguration message may also include a RadioResourceConfigDedicated IE, which may be used to setup/modify/release radio bearers (RBs) and may indicate the single bearer to be used for conveying data over the LWIP tunnel 160. For example, the RadioResourceConfigDedicated IE may include a drb-TypeLWIP field/IE, an lwip-UL- Aggregation field/IE, and/or an lwip-DL- Aggregation field/IE in an DRB-ToAddModList IE/field. The drb-TypeLWIP field/IE may indicate whether a DRB is (re)configured to use the LWIP Tunnel 160 in UL and DL (drb- TypeLWIP set to value lwip), DL only (drb-TypeLWIP set to value lwip-DL-only), UL only (drb-TypeLWIP set to value lwip-UL-only) or not to use the LWIP Tunnel 160 (drb- TypeLWIP set to value eutran). The lwip-UL-Aggregation field/IE, and the lwip-DL- Aggregation field/IE may indicate whether LWIP is configured to utilize LWIP aggregation in DL or UL, respectively. At operation 1055, the UE 102 may apply the new configuration and may reply by transmitting another RRCConnectionReconfigurationComplete message to the RAN node 111/112.

At operation 1060, the UE 102 may use the parameters in the new RRC configuration to setup the IPsec tunnel 117 with the LWIP-SeGW 150 to complete the establishment of the LWIP tunnel 160 with the RAN node 111/112 over the WLAN 106 access. The RAN node 111/112 may add or remove data bearers to utilize the LWIP tunnel 160 at any time after the establishment of the LWIP tunnel 117 by sending the RRCConnectionReconfiguration message to the UE.

FIG. 11 shows an example WLAN resource reconfiguration procedure 1100 in accordance with various embodiments. Process 1100 may be a procedure of re-configuring to remove the WLAN radio resources from the data bearer. Process 1100 may begin at operation 1105 where the UE 102 and the RAN node 111/112 have an LWIP tunnel 160 setup via WLAN 106. At operation 1110, the UE 102 is configured to receive data from a data bearer over the LWIP tunnel 160 (for example, from RAN node 111/112 via the WLAN 106). At operation 1115, the RAN node 111/112 may determine that the WLAN resources for the data bearer should be removed.

At operation 1120, the RAN node 111/112 may send the RRCConnectionReconfiguration message to the UE 102 including the necessary parameters to remove WLAN resources for the data bearer. At operation 1125, the UE 102 may apply the new configuration and may reply by transmitting a RRCConnectionReconfigurationComplete message to the RAN node 111/112. At operation 1130, the UE 102 stops receiving data for the data bearer over the LWIP tunnel, and at operation 1135, the LWIP tunnel 160 between the UE 102 and the RAN node 111/112 via the WLAN 106 may be released. A process for releasing the LWIP tunnel 160 is shown by FIG. 12.

FIG. 12 shows an example LWIP tunnel release procedure 1200 in accordance with various embodiments. The process 1200 may be a procedure of the RAN node 111/112 to initiate LWIP tunnel 160 release. Process 1200 may begin at operation 1205 where the UE 102 and the RAN node 111/112 have the LWIP tunnel 160 setup via WLAN 106. At operation 1210, the RAN node 111/112 may determine that the LWIP tunnel 160 should be released and initiates the release of the IPsec tunnel 117 between the UE 102 and LWIP- SeGW 150. At operation 1215, the RAN node 111/112 may transmit an RRCConnectionReconfiguration message to the UE 102, which may include an indication to release the LWIP tunnel 160 and/or the IPsec tunnel 117. The release of the IPsec tunnel 160 initiated by the RAN node 111/112 may be a handover command, a command to transition to the RRC IDLE state, or some other like indication or configuration in the RRCConnectionReconfiguration message. Upon receipt of the Handover Command or on transition to RRC IDLE state, the UE may autonomously release IPsec tunnel 160 configuration and the use of it by the data bearers. At operation 1220, The UE 102 may apply the new configuration and may reply by transmitting an RRCConnectionReconfigurationComplete message. At operation 1235, The RAN node 111/112 may send an LWIP-SeGW Tunnel Release Request message to the LWIP-SeGW 150 to release remaining resources at the LWIP-SeGW 150.

FIG. 13 shows an example process 1300 A for transferring downlink user data in accordance with various embodiments, and an example process 1300B for conveying a downlink data delivery status in accordance with various embodiments. The Transfer of Downlink User Data process 1300A may be used to provide Xw-U specific SN information at the transfer of the DL user data carrying a DL LWIP PDU from the RAN node 111/112 to the LWIP-SeGW 150 via the L-Xw-UP interface 155. The Downlink Data Delivery Status process 1300B may be used to provide feedback from the LWIP-SeGW 150 to the RAN node 111/112 to allow the RAN node 111/112 to control the downlink user data flow via the LWIP-SeGW 150 for the respective UE 102.

Referring to process 1300A, at operation 1305 the RAN node 111/112 may send DL user data to the LWIP-SeGW 150. In embodiments, the DL user data may be or included in a data frame, such as frames 900A and 900B of FIGS. 9A and 9B, respectively. In embodiments, the RAN node 111/112 may assign consecutive Xw-U SNs to each transferred Xw-U packet. In embodiments, the RAN node 111/112 may invoke or operate an L-Xw-UP instance to make use of the Transfer of Downlink User Data procedure. According to various embodiments, the L-Xw-UP instance is associated with a single UE 102 only, and the Transfer of Downlink User Data procedure 1300A may be invoked whenever user data for that particular UE 102 needs to be sent across the L-Xw-UP interface 155.

The LWIP-SeGW 150 may detect whether an Xw-U packet was lost and memorize the respective SN after the LWIP-SeGW 150 declares the respective Xw-U packet as being "lost". In addition, the LWIP-SeGW 150 may transfer any remaining LWIP PDUs towards the UE 102 and memorize a highest Xw-U SN of the LWIP PDU that was successfully transferred towards the UE.

Referring to process 1300B, at operation 1310 the LWIP-SeGW 150 may send DL data delivery status frame to the RAN node 111/112. In embodiments, the DL data delivery status frame may be or included in a data frame, such as the frames 900A and 900C of FIGS. 9A and 9C, respectively. The DL data delivery status frame may also include an indication of whether the frame is a last DL status report received in the course of releasing a bearer from the LWIP-SeGW 150. When receiving such indication, if applicable, the RAN node 111/112 may consider that no more UL data is to be expected from the LWIP-SeGW 150. In some embodiments, the LWIP-SeGW 150 may also transfer uplink user data for the concerned UE 102 to the RAN node 111/112 together with a DL data delivery status frame within a same GTP-U PDU.

When the LWIP-SeGW 150 decides to trigger a Feedback for Downlink Data Delivery procedure, the LWIP-SeGW 150 may report a highest Xw-U sequence number successfully transferred towards or delivered to the UE among those PDUs received from the RAN node 111/112; the desired buffer size in bytes for the concerned UE 102; the minimum desired buffer size in bytes for the UE; and the Xw-U packets that were declared as being "lost" by the LWIP-SeGW 150 and have not yet been reported to the RAN node 111/112 within the DL data delivery status frame.

In response to receipt of the DL data delivery status frame, the RAN node 111/112 may regard the desired buffer size indicated by the DL data delivery status frame as the amount of data desired from the LWIP-SeGW 150 being declared. The desired buffer size as reported may also be considered as the momentary desired buffer sizes, independent of buffer sizes indicated in the past. The RAN node 111/112 may also be allowed to remove buffered LWIP PDUs according to the feedback of successfully delivered LWIP PDUs. Furthermore, the RAN node 111/112 may determine various actions to take for LWIP PDUs reported other than successfully delivered LWIP PDUs. After being reported to the RAN node 111/112, the LWIP-SeGW 150 may remove the respective Xw-U sequence numbers.

Referring to FIG. 14, an example LWIP operation process 1400 in accordance with various embodiments, is shown. In embodiments, processor circuitry of the RAN node 111/112 (for example, baseband circuitry 210 or application circuitry 205) may perform the various operations of process 1400, and the network controller circuitry 235 (for example, using Ethernet, Ethernet over GRE Tunnel, Ethernet over MPLS, etc.) and/or an RFEM 215 (for example, using over-the-air (OTA) interfaces) may be used for the various communications of process 1400.

Process 1400 may begin at operation 1405 where the processor circuitry may establish an LWIP tunnel 160 with a UE 102 via WLAN 106. Operation 1405 may include performing process 1000 discussed previously. At operation 1410, the processor circuitry may obtain DL data for the UE 102 from the network 120. For example, referring to FIG. 1A, the DL data intended for the UE 102 may be obtained from application server 130 via P-GW 123 and S-GW 122 over a GTP-U tunnel.

At operation 1415, the processor circuitry may operate an LWIPEP entity 810 to encapsulate the DL data packets to obtain DL LWIPEP PDUs. Additionally, the processor circuitry may include the DL LWIP PDUs in a user data frame, such as one or more of the frames shown by FIGS. 9A-9B. At operation 1420, the processor circuitry may send the encapsulated packets (for example, the DL LWIPEP PDUs) to the LWIP-SeGW 150 over the L-Xw-UP interface 155 to be delivered to the UE 102 via WLAN 106. Operation 1420 may correspond to process 1300A of FIG. 13.

At operation 1425, the processor circuitry may obtain one or more UL data packets (for example, UL LWIP PDUs) from the LWIP-SeGW 150. In embodiments, the UL LWIP PDUs may be included in data frames, such as one or more of the frames shown by FIGS. 9A and 9C. At operation 1430, the processor circuitry may process each obtained UL data packet in turn. At operation 1435, the processor circuitry may operate the LWIP entity 810 to decapsulate the obtained UL LWIPEP PDU. Operation 1425 may correspond to process 1300B of FIG. 13.

At operation 1440, the processor circuitry may determine whether any of the obtained UL LWIPEP PDU is a feedback message (for example, a DL data delivery status message). If at operation 1435 the processor circuitry determines that an obtained UL LWIPEP PDU is a feedback message, the processor circuitry may proceed to operation 1450 to adjust a flow control mechanism based on feedback information included in the feedback message (for example, the number of lost Xw-U SNs, start/end of lost Xw-U SNs, desired buffer size for the UE 102, minimum desired buffer size for the UE in the DL data delivery status message). If at operation 1440 the processor circuitry determines that the obtained UL LWIPEP PDU is not a feedback message, the processor circuitry may proceed to operation 1445 to route the decapsulated UL data packet through the network. At operation 1455, the processor circuitry may loop back to operation 1430 to process a next obtained UL data packet, if any.

At operation 1460, the processor circuitry may determine whether the LWIP operation should end. In embodiments, this determination may be based on an indication from a core network node, an indication from the UE 102 and/or the WLAN 106, or some suitable trigger event. If at operation 1460 the processor circuitry determines that the LWIP operation should not end, the processor circuitry may proceed back to operation 1410 to monitor for and obtain DL data and/or UL data packets as discussed previously. If at operation 1460 the processor circuitry determines that the LWIP operation should end, the processor circuitry may proceed to operation 1465 to remove the WLAN resources and release the LWIP tunnel 160, which may correspond to processes 1100 and 1200, respectively. After performance of operation 1465, process 1400 may end or repeat as necessary.

Referring to FIG. 15, another example LWIP process 1500 in accordance with various embodiments, is shown. In embodiments, processor circuitry of the LWIP-SeGW 150 (for example, baseband circuitry 210 or application circuitry 205) may perform the various operations of process 1500, and the network controller circuitry 235 (for example, using Ethernet, Ethernet over GRE Tunnel, Ethernet over MPLS, etc.) and/or an RFEM 215 (for example, using over-the-air (OTA) interfaces) for the various communications of process 1500.

Process 1500 may begin at operation 1505 the processor circuitry may establish an

LWIP tunnel 160 as discussed previously. At operation 1510 where the processor circuitry may obtain DL LWIPEP PDUs for a bearer from a RAN node 1 11/112 over an LWIP tunnel 160, and may forward the DL LWIPEP PDUs for the bearer for delivery to the UE 102 over the LWIP tunnel 160 via the WLAN 106. At operation 1515, the processor circuitry may control storage of a highest SN of successfully transferred LWIPEP PDUs.

At operation 1520, the processor circuitry may determine whether any LWIPEP PDUs have been lost. If at operation 1520 the processor circuitry determines that one or more LWIPEP PDUs have been lost, the processor circuitry may proceed to operation 1525 to control storage of the SNs of the lost LWIPEP PDUs, and may then proceed to operation 1530 to determine if a feedback event has occurred. If at operation 1520 the processor circuitry determines that no LWIPEP PDUs have been lost, the processor circuitry may proceed to operation 1530 to determine if a feedback event has occurred.

At operation 1530, the processor circuitry may determine whether a feedback event has occurred. In some embodiments, the feedback event may be detection of a lost LWIPEP PDU, expiration of a timer, or some other suitable event. If at operation 1530, the processor circuitry determines that a feedback event has not occurred, then the processor circuitry may proceed back to operation 1510 to receive and forward LWIPEP PDUs. If at operation 1530, the processor circuitry determines that a feedback event has occurred, then the processor circuitry may proceed to operation 1535 to generate and send a feedback message to the RAN node 11 1/1 12. This may include generating a DL data delivery status message in a data frame (for example data frame 900C of FIG. 9C) include the lost SNs, stored highest SNs, and the other information discussed previously. After operation 1535, process 1500 may end or repeat as necessary.

FIG. 16 illustrates yet another example LWIP process 1600 in accordance with various embodiments. In embodiments, processor circuitry of the UE 102 (for example, baseband circuitry 304) may perform the various operations of process 1600, and the RF circuitry 306 may be used for the various communications of process 1600.

Process 1600 may begin at operation 1605 where the processor circuitry may establish an LWIP tunnel 160 with the RAN node 1 11/1 12. Operation 1605 may correspond with process 1000 of FIG. 10. At operation 1610, the processor circuitry may control receipt of downlink data for a bearer over the LWIP tunnel 160. At operation 1615, the processor circuitry may determine whether a configuration to remove the WLAN resources has been received, and if the configuration has not been received the processor circuitry may continue to control receipt of LWIPEP PDUs at operation 1610. If the configuration has been received, the processor circuitry may proceed to operation 1620 to stop receiving DL data for the bearer over the LWIP tunnel. Operations 1615 and 1620 may correspond with operations 1120-1130 of process 1100.

At operation 1625, the processor circuitry may determine whether a configuration to release the LWIP tunnel 160 has been received, and if the configuration has not been received the processor circuitry may continue to control receipt of LWIPEP PDUs at operation 1610. If the configuration has been received, the processor circuitry may proceed to operation 1630 to release the LWIP tunnel 160. Operations 1625 and 1630 may correspond with operations 1215-1225 of process 1200. After performance of operation 1630, process 1600 may end or repeat as necessary.

Some non-limiting examples are provided infra. The following examples pertain to further embodiments. Specifics in the examples may be used anywhere in one or more embodiments discussed previously. All optional features of devices described herein may also be implemented with respect to one or more methods or processes, and vice versa.

Example 1 may include an apparatus to be employed in an evolved NodeB, "eNB", the apparatus comprising: encapsulation means for encapsulating downlink, "DL", user data packets using Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Encapsulation Protocol, "LWIPEP", to obtain DL LWIPEP-protocol data units, "PDUs", to be transmitted to an LWIP-security gateway, "SeGW", and for decapsulating uplink, "UL", LWIP -PDUs received from the LWIP-SeGW; and communication means for sending the DL LWIPEP-PDUs over a user plane interface between the eNB and an LWIP-SeGW, and for obtaining UL LWIPEP- PDUs from the LWIP-SeGW over the user plane interface, and wherein the UL LWIPEP- PDUs and the DL LWIPEP-PDUs are to be transported over the user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel, and wherein the user plane interface is to terminate at the eNB and the SeGW.

Example 2 may include the apparatus of example 1 and/or some other examples herein, wherein the single GTP tunnel corresponds with a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", wherein the single IPSec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 3 may include the apparatus of example 2 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 4 may include the apparatus of example 2 and/or some other examples herein, further comprising: DL user plane means for invoking a Transfer of Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 5 may include the apparatus of example 4 and/or some other examples herein, wherein the DL user plane means is for: generating an instance of a DL user plane entity to only be associated with the individual UE; and invoking the instance of the DL user plane entity to operate the Transfer Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 6 may include the apparatus of example 5 and/or some other examples herein, wherein, in response to invocation of the instance of the Transfer of DL User Data procedure, the encapsulation means is for: consecutively assigning sequence numbers to each of the user data packets; and encapsulating each of the user data packets to include the assigned sequence numbers.

Example 7 may include the apparatus of example 6 and/or some other examples herein, wherein: the communication means is for obtaining a DL Delivery Status message from the LWIP-SeGW, wherein the DL Delivery Status message is to indicate: a highest sequence number of the DL LWIPEP PDUs successfully transferred towards or delivered to the individual UE among the DL LWIPEP PDUs sent by the eNB, a desired buffer size for the individual UE in bytes, a minimum desired buffer size for the individual UE in bytes, and sequence numbers of DL LWIPEP PDUs that were declared as being lost by the LWIP- SeGW; and the DL user plane means is for removing buffered LWIPEP-PDUs based on the highest sequence of successfully delivered user data packets; and determining one or more actions to take based on the highest sequence number, the desired buffer size, the minimum desired buffer size, or the sequence numbers of the lost LWIPEP PDUs.

Example 8 may include the apparatus of example 2 and/or some other examples herein, wherein the communication means is for transmitting a Radio Resource Control (RRC) Connection Reconfiguration message to the UE via RRC signaling, wherein the RRC Connection Reconfiguration message is to indicate that UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

Example 9 may include the apparatus of example 8 and/or some other examples herein, wherein all UL traffic of the data bearer is to be obtained from the LWIP-SeGW via the WLAN when the RRC Connection Reconfiguration message indicates that the UL data is to be routed via the WLAN AP.

Example 10 may include the apparatus of examples 1-9 and/or some other examples herein, wherein the user plane interface is an Xw interface.

Example 11 may include an apparatus to be employed as an Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", the apparatus comprising: processor circuitry; and network controller circuitry coupled with the processor circuitry, the network controller circuitry to: obtain downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel, and send the DL LWIPEP-PDUs over a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", and wherein the processor circuitry is to terminate the user plane interface and terminate the IPsec tunnel.

Example 12 may include the apparatus of example 11 and/or some other examples herein, wherein the single GTP tunnel corresponds with the single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 13 may include the apparatus of example 12 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 14 may include the apparatus of example 12 and/or some other examples herein, wherein the network control circuitry is to: obtain an LWIP Addition Request message from the eNB over the user plane interface, the an LWIP Addition Request message to include a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and send an LWIP Addition Request Acknowledgment message to the eNB over the user plane interface to confirm that LWIP-SeGW is able to admit the request. Example 15 may include the apparatus of example 1 1 and/or some other examples herein, wherein the processor circuitry is to: identify sequence numbers of individual ones of the DL LWIPEP-PDUs to be sent over the IPsec tunnel; and control storage of a sequence number having a greatest value among the identified sequence numbers successfully transferred towards or delivered to the individual UE among the DL LWIPEP PDUs sent by the eNB.

Example 16 may include the apparatus of example 15 and/or some other examples herein, wherein the processor circuitry is to: detect whether one or more DL LWIPEP PDUs are lost; determine respective sequence numbers of the lost DL LWIPEP PDUs; and control storage of the respective sequence numbers.

Example 17 may include the apparatus of example 16 and/or some other examples herein, wherein the processor circuitry is to: generate a DL Delivery Status message to indicate the sequence number having the greatest value, a desired buffer size for the individual UE in bytes, a minimum desired buffer value for the individual UE in bytes, and the respective sequence numbers of the lost DL LWIPEP PDUs; and remove buffered DL LWIPEP-PDUs based on the sequence number having the greatest value.

Example 18 may include the apparatus of example 17 and/or some other examples herein, wherein the processor circuitry is to: detect a trigger to invoke a Feedback for Downlink Data Delivery procedure; and generate the DL Delivery Status message in response to detection of the trigger.

Example 19 may include the apparatus of example 18 and/or some other examples herein, wherein the processor circuitry is to generate the DL Delivery Status message to indicate whether the DL Delivery Status message is a last DL Delivery Status message to be sent during a procedure to release a bearer from the LWIP-SeGW.

Example 20 may include the apparatus of examples 11 -19 and/or some other examples herein, wherein the user plane interface is an Xw interface.

Example 21 may include an apparatus to be employed in an evolved NodeB, "eNB", the apparatus comprising: processor circuitry to: encapsulate downlink, "DL", user data packets using Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Encapsulation Protocol, "LWIPEP", to obtain DL LWIPEP-protocol data units, "PDUs", to be transmitted to an LWIP-security gateway, "SeGW", and decapsulate uplink, "UL", LWIP-PDUs received from the LWIP- SeGW; and network controller circuitry coupled with the processor circuitry, the network controller circuitry to send the DL LWIPEP-PDUs over a user plane interface between the eNB and an LWIP-SeGW, and obtain UL LWIPEP-PDUs from the LWIP-SeGW over the user plane interface, and wherein the UL LWIPEP-PDUs and the DL LWIPEP-PDUs are to be transported over the user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel, and wherein the user plane interface is to terminate at the eNB and the SeGW.

Example 22 may include the apparatus of example 21 and/or some other examples herein and/or some other examples herein, wherein the single GTP tunnel corresponds with a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", wherein the single IPSec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 23 may include the apparatus of example 22 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 24 may include the apparatus of example 22 and/or some other examples herein, wherein the processor circuitry is to: invoke a Transfer of Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 25 may include the apparatus of example 24 and/or some other examples herein, wherein the processor circuitry is to: generate an instance of a DL user plane entity to only be associated with the individual UE; and invoke the instance of the DL user plane entity to operate the Transfer Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 26 may include the apparatus of example 25 and/or some other examples herein, wherein, in response to invocation of the instance of the Transfer of DL User Data procedure, the processor circuitry is to: consecutively assign sequence numbers to each of the user data packets; and encapsulate each of the user data packets such that the DL LWIPEP PDUs include the assigned sequence numbers.

Example 27 may include the apparatus of example 26 and/or some other examples herein, wherein the processor circuitry is to: control receipt of a DL Delivery Status message from the LWIP-SeGW, wherein the DL Delivery Status message is to indicate: a highest sequence number of the DL LWIPEP PDUs successfully transferred towards or delivered to the individual UE among the DL LWIPEP PDUs sent by the eNB, a desired buffer size for the individual UE in bytes, a minimum desired buffer size for the individual UE in bytes, and sequence numbers of DL LWIPEP PDUs that were declared as being lost by the LWIP- SeGW; remove buffered DL LWIPEP-PDUs based on the highest sequence of successfully delivered user data packets; and determine one or more actions to take based on the highest sequence number, the desired buffer size, the minimum desired buffer size, or the sequence numbers of the lost DL LWIPEP PDUs.

Example 28 may include the apparatus of example 22 and/or some other examples herein, wherein the processor circuitry is to: control transmission of a Radio Resource Control (RRC) Connection Reconfiguration message to the UE via RRC signaling, wherein the RRC Connection Reconfiguration message is to indicate that UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

Example 29 may include the apparatus of example 28 and/or some other examples herein, wherein all UL traffic of the data bearer is to be obtained from the LWIP-SeGW via the WLAN when the RRC Connection Reconfiguration message indicates that the UL data is to be routed via the WLAN AP.

Example 30 may include the apparatus of examples 21-29 and/or some other examples herein, wherein the user plane interface is an Xw interface.

Example 31 may include an apparatus to be employed as an Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", the apparatus comprising: communication means for obtaining downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel, and for sending the DL LWIPEP-PDUs over a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", and wherein the user plane interface is to terminate at the LWIP-SeGW and the IPsec tunnel is to terminate at the LWIP-SeGW.

Example 32 may include the apparatus of example 31 and/or some other examples herein, wherein the single GTP tunnel corresponds with the single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 33 may include the apparatus of example 32 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel. Example 34 may include the apparatus of example 32 and/or some other examples herein, wherein the communication means is for: obtaining an LWIP Addition Request message from the eNB over the user plane interface, the an LWIP Addition Request message to include a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and sending an LWIP Addition Request Acknowledgment message to the eNB over the user plane interface to confirm that LWIP-SeGW is able to admit the request.

Example 35 may include the apparatus of example 31 and/or some other examples herein, further comprising: processing means for identifying sequence numbers of individual ones of the DL LWIPEP-PDUs to be sent over the IPsec tunnel; and storage means for storing a sequence number having a greatest value among the identified sequence numbers successfully transferred towards or delivered to the individual UE among the LWIPEP PDUs sent by the eNB.

Example 36 may include the apparatus of example 35 and/or some other examples herein, wherein: the processing means is for detecting whether one or more DL LWIPEP PDUs are lost; and determining respective sequence numbers of the lost DL LWIPEP PDUs; and the storage means is for storing the respective sequence numbers.

Example 37 may include the apparatus of example 36 and/or some other examples herein, wherein the processing means is for: detecting a trigger to invoke a Feedback for Downlink Data Delivery procedure; generating, in response to detection of the trigger, a DL Delivery Status message to indicate the sequence number having the greatest value, a desired buffer size for the individual UE in bytes, a minimum desired buffer value for the individual UE in bytes, and the respective sequence numbers of the lost DL LWIPEP PDUs; and removing buffered LWIPEP-PDUs based on the sequence number having the greatest value.

Example 38 may include the apparatus of example 37 and/or some other examples herein, wherein the communication means is for sending the DL Delivery Status message to the eNB over the user plane interface.

Example 39 may include the apparatus of example 38 and/or some other examples herein, wherein the processing means is for generating the DL Delivery Status message to indicate whether the DL Delivery Status message is a last DL Delivery Status message to be sent during a procedure to release a bearer from the LWIP-SeGW.

Example 40 may include the apparatus of examples 31-39 and/or some other examples herein, wherein the user plane interface is an Xw interface. Example 41 may include one or more computer-readable media, "CRM", comprising instructions, which when executed by one or more processors of an evolved NodeB, "eNB", is to cause the eNB to: encapsulate downlink, "DL", user data packets using Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Encapsulation Protocol, "LWIPEP", to obtain DL LWIPEP- protocol data units, "PDUs", to be transmitted to an LWIP-security gateway, "SeGW"; decapsulate uplink, "UL", LWIP-PDUs received from the LWIP-SeGW; control transmission of the DL LWIPEP-PDUs over a user plane interface between the eNB and an LWIP-SeGW; and control receipt of UL LWIPEP-PDUs from the LWIP-SeGW over the user plane interface, wherein the UL LWIPEP-PDUs and the DL LWIPEP-PDUs are to be transported over the user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel, and wherein the user plane interface is to terminate at the eNB and the SeGW.

Example 42 may include one or more CRM of example 41 and/or some other examples herein, wherein the single GTP tunnel corresponds with a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", wherein the single IPSec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 43 may include one or more CRM of example 42 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 44 may include one or more CRM of example 42 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the eNB to: invoke a Transfer of Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 45 may include one or more CRM of example 44 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the eNB to: generate an instance of a DL user plane entity to only be associated with the individual UE; and invoke the instance of the DL user plane entity to operate the Transfer Downlink User Data procedure when user data for the individual UE is to be sent across the user plane interface.

Example 46 may include one or more CRM of example 45 and/or some other examples herein, wherein, in response to invocation of the instance of the Transfer of DL User Data procedure, execution of the instructions by one or more processors is to cause the eNB to: consecutively assign sequence numbers to each of the user data packets; and encapsulate each of the user data packets such that the DL LWIPEP PDUs include the assigned sequence numbers.

Example 47 may include one or more CRM of example 46 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the eNB to: control receipt of a DL Delivery Status message from the LWIP-SeGW, wherein the DL Delivery Status message is to indicate: a highest sequence number of the DL LWIPEP PDUs successfully transferred towards or delivered to the individual UE among the DL LWIPEP PDUs sent by the eNB, a desired buffer size for the individual UE in bytes, a minimum desired buffer size for the individual UE in bytes, and sequence numbers of DL LWIPEP PDUs that were declared as being lost by the LWIP-SeGW; remove buffered DL LWIPEP -PDUs based on the highest sequence of successfully delivered user data packets; and determine one or more actions to take based on the highest sequence number, the desired buffer size, the minimum desired buffer size, or the sequence numbers of the lost DL LWIPEP PDUs.

Example 48 may include one or more CRM of example 42 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the eNB to: control transmission of a Radio Resource Control (RRC) Connection Reconfiguration message to the UE via RRC signaling, wherein the RRC Connection Reconfiguration message is to indicate that UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

Example 49 may include one or more CRM of example 48 and/or some other examples herein, wherein all UL traffic of the data bearer is to be obtained from the LWIP- SeGW via the WLAN when the RRC Connection Reconfiguration message indicates that the UL data is to be routed via the WLAN AP.

Example 50 may include one or more CRM of examples 41-49 and/or some other examples herein, wherein the user plane interface is an Xw interface.

Example 51 may include one or more computer-readable media, "CRM", comprising instructions, which when executed by one or more processors of a Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", is to cause the LWIP-SeGW to: control receipt of downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel; and control transmission of the DL LWIPEP-PDUs over a single Internet Protocol Security, "IPsec", tunnel between the LWIP-SeGW and an individual user equipment, "UE", and wherein the user plane interface is to terminate at the LWIP-SeGW and the IPsec tunnel is to terminate at the LWIP-SeGW.

Example 52 may include one or more CRM of example 51 and/or some other examples herein, wherein the single GTP tunnel corresponds with the single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers that are configured to send or receive data over a Wireless Local Area Network, "WLAN".

Example 53 may include one or more CRM of example 52 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via an WLAN access point, "AP", is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 54 may include one or more CRM of example 52 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the LWIP-SeGW to: obtain an LWIP Addition Request message from the eNB over the user plane interface, the an LWIP Addition Request message to include a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and send an LWIP Addition Request Acknowledgment message to the eNB over the user plane interface to confirm that LWIP-SeGW is able to admit the request.

Example 55 may include one or more CRM of example 51 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the LWIP-SeGW to: identify sequence numbers of individual ones of the DL LWIPEP- PDUs to be sent over the IPsec tunnel; and control storage of a sequence number having a greatest value among the identified sequence numbers successfully transferred towards or delivered to the individual UE among the DL LWIPEP PDUs sent by the eNB.

Example 56 may include one or more CRM of example 55 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the LWIP-SeGW to: detect whether one or more DL LWIPEP PDUs are lost; determine respective sequence numbers of the lost DL LWIPEP PDUs; and control storage of the respective sequence numbers.

Example 57 may include one or more CRM of example 56 and/or some other examples herein, execution of the instructions by one or more processors is to cause the LWIP-SeGW to: generate a DL Delivery Status message to indicate the sequence number having the greatest value, a desired buffer size for the individual UE in bytes, a minimum desired buffer value for the individual UE in bytes, and the respective sequence numbers of the lost DL LWIPEP PDUs; and remove buffered DL LWIPEP-PDUs based on the sequence number having the greatest value.

Example 58 may include one or more CRM of example 57 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the LWIP-SeGW to: detect a trigger to invoke a Feedback for Downlink Data Delivery procedure; and generate the DL Delivery Status message in response to detection of the trigger.

Example 59 may include one or more CRM of example 58 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the LWIP-SeGW to: generate the DL Delivery Status message to indicate whether the DL Delivery Status message is a last DL Delivery Status message to be sent during a procedure to release a bearer from the LWIP-SeGW.

Example 60 may include one or more CRM of examples 51-59 and/or some other examples herein, wherein the user plane interface is an Xw interface.

Example 61 may include an apparatus to be implemented in a user equipment, "UE", the apparatus comprising: a System on Chip, "SoC" comprising baseband circuitry and on- board memory circuitry, the baseband circuitry to: control receipt of a radio resource control, "RRC", message including parameters to setup an Internet Protocol Security, "IPsec", tunnel with an a Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW"; establish the IPsec tunnel with the LWIP-SeGW using the parameters in the RRC message; and control receipt of downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", from LWIP-SeGW via a Wireless Local Area Network, "WLAN", access point, "AP", wherein the LWIPEP-PDUs are to be transferred to the LWIP-SeGW over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel.

Example 62 may include the apparatus of example 61 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via the WLAN AP and the LWIP-SeGW is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 63 may include the apparatus of example 61 and/or some other examples herein, wherein the parameters to setup the IPsec tunnel comprises a WLAN mobility set, wherein WLAN mobility set includes one or more identifiers associated with the WLAN AP.

Example 64 may include the apparatus of example 61 and/or some other examples herein, wherein the baseband circuitry is to: control receipt of another RRC message including another WLAN mobility set, wherein the other WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and perform signal strength measurements on signals broadcasted by the one or more WLAN APs.

Example 65 may include the apparatus of examples 61-64 and/or some other examples herein, wherein the baseband circuitry is to operate an LWIPEP entity to decapsulate the DL LWIPEP-PDUs.

Example 66 may include an apparatus to be implemented in a user equipment, "UE", the apparatus comprising: Long Term Evolution, "LTE", circuitry to control receipt of a radio resource control, "RRC", message, the RRC message including: first parameters to setup an Internet Protocol Security, "IPsec", tunnel with an a Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", and second parameters to setup an LWIP bearer to be transported over the IPsec tunnel; processor circuitry coupled with the LTE circuitry to control establishment of the IPsec tunnel with the LWIP-SeGW using the first parameters; and control setup of the LWIP bearer using the second parameters; and Wireless Local Area Network, "WLAN", physical layer, "PHY", circuitry coupled with the LTE circuitry and the processor circuitry, the WLAN PHY circuitry to control receipt of downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", from LWIP-SeGW via a WLAN access point, "AP", wherein the LWIPEP- PDUs are to be transferred to the LWIP-SeGW over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel.

Example 67 may include the apparatus of example 66 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via the WLAN AP and the LWIP-SeGW is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 68 may include the apparatus of example 66 and/or some other examples herein, wherein the first parameters comprises a WLAN mobility set, wherein WLAN mobility set includes one or more identifiers associated with the WLAN AP, and the second parameters comprise a configuration to indicate that traffic for the LWIP bearer is to be routed over the IPsec tunnel in only DL, only uplink, "UL", or both UL and DL.

Example 69 may include the apparatus of example 66 and/or some other examples herein, wherein: the LTE circuitry is to control receipt of another RRC message including another WLAN mobility set, wherein the other WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and the WLAN PHY circuitry is to perform signal strength measurements on signals broadcasted by the one or more WLAN APs.

Example 70 may include the apparatus of examples 66-69 and/or some other examples herein, wherein the processor circuitry is to operate an LWIPEP entity to: decapsulate the DL LWIPEP-PDUs; and encapsulate UL LWIPEP -PDUs to be transmitted over the IPsec tunnel to the LWIP-SeGW via the WLAN AP.

Example 71 may include an apparatus to be implemented in a user equipment, "UE", the apparatus comprising: Long Term Evolution, "LTE", means for receiving a radio resource control, "RRC", message including first parameters to setup an Internet Protocol Security, "IPsec", tunnel with an a Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", and second parameters to setup an LWIP bearer to be transported over the IPsec tunnel; and Wireless Local Area Network, "WLAN", means for: establishing the IPsec tunnel with the LWIP-SeGW using the first parameters; setting-up the LWIP bearer using the second parameters; and receiving downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", from LWIP- SeGW via a WLAN access point, "AP", wherein the LWIPEP-PDUs are to be transferred to the LWIP-SeGW over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel.

Example 72 may include the apparatus of example 71 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via the WLAN AP and the LWIP-SeGW is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 73 may include the apparatus of example 71 and/or some other examples herein, wherein the first parameters comprises a WLAN mobility set, wherein WLAN mobility set includes one or more identifiers associated with the WLAN AP, and the second parameters comprise a configuration to indicate that traffic for the LWIP bearer is to be routed over the IPsec tunnel in only DL, only uplink, "UL", or both UL and DL.

Example 74 may include the apparatus of example 71 and/or some other examples herein, wherein: the LTE means is for receiving another RRC message including another WLAN mobility set, wherein the other WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and the WLAN means is for measuring signal strength of signals broadcasted by the one or more WLAN APs and for generating signal strength measurements based on the measuring.

Example 75 may include the apparatus of examples 71-74 and/or some other examples herein, wherein the LTE means comprises LWIPEP means for: decapsulating the DL LWIPEP -PDUs; and encapsulating UL LWIPEP-PDUs to be transmitted over the IPsec tunnel to the LWIP-SeGW via the WLAN AP.

Example 76 may include one or more computer-readable media, "CRM", comprising instructions, which when executed by one or more processors of a user equipment, "UE", is to cause the UE to: control receipt of a radio resource control, "RRC", message including first parameters to setup an Internet Protocol Security, "IPsec", tunnel with an a Long Term Evolution Wireless Local Area Network Radio Level Integration with Internet Protocol Security Tunneling, "LWIP", Security Gateway "SeGW", and second parameters to setup an LWIP bearer to be transported over the IPsec tunnel; establish the IPsec tunnel with the LWIP-SeGW using the first parameters; setup the LWIP bearer using the second parameters; and control receipt of downlink, "DL", LWIP Encapsulation Protocol, "LWIPEP", protocol data units, "PDUs", from an evolved NodeB, "eNB", from LWIP-SeGW via a Wireless Local Area Network, "WLAN", access point, "AP", wherein the LWIPEP-PDUs are to be transferred to the LWIP-SeGW over a user plane interface on a single General Packet Radio System Tunneling Protocol for user plane, "GTP-U", tunnel.

Example 77 may include one or more CRM of example 76 and/or some other examples herein, wherein an end-to-end path between the UE and the eNB via the WLAN AP and the LWIP-SeGW is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

Example 78 may include one or more CRM of example 76 and/or some other examples herein, wherein the first parameters to setup the IPsec tunnel comprises a WLAN mobility set, wherein WLAN mobility set includes one or more identifiers associated with the WLAN AP, and the second parameters comprise a configuration to indicate that traffic for the LWIP bearer is to be routed over the IPsec tunnel in only DL, only uplink, "UL", or both UL and DL.

Example 79 may include one or more CRM of example 76 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the UE to: control receipt of another RRC message including another WLAN mobility set, wherein the other WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and perform signal strength measurements on signals broadcasted by the one or more WLAN APs.

Example 80 may include one or more CRM of examples 76-79 and/or some other examples herein, wherein execution of the instructions by one or more processors is to cause the UE to operate an LWIPEP entity to: decapsulate the DL LWIPEP-PDUs; and encapsulate UL LWIPEP-PDUs to be transmitted over the IPsec tunnel to the LWIP-SeGW via the WLAN AP.

Example 81 may include a method, technique, or process as described in or related to any of examples 1 -80, or portions or parts thereof.

Example 82 may include an apparatus comprising: one or more processors and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1 -80, or portions thereof.

Example 83 may include a signal as described in or related to any of examples 1-80, or portions or parts thereof.

Example 84 may include a signal in a wireless network as shown and described herein.

Example 85 may include a method of communicating in a wireless network as shown and described herein.

Example 86 may include a system for providing wireless communication as shown and described herein.

Example 87 may include a device for providing wireless communication as shown and described herein.

The foregoing description of the above examples provides illustration and description for the example embodiments disclosed herein, but the above Examples are not intended to be exhaustive or to limit the scope of the invention to the precise form disclosed. Modifications and variations are possible in light of the above teachings and/or may be acquired from practice of various implementations of the embodiments discussed herein. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments