WO2017189176A2

WO2017189176A2 - Generic multi-access protocols for next generation multi-access networks

Info

Publication number: WO2017189176A2
Application number: PCT/US2017/025612
Authority: WO
Inventors: Jing Zhu; Nageen Himayat; Nana ZHANG
Original assignee: Intel Corporation
Priority date: 2016-04-27
Filing date: 2017-03-31
Publication date: 2017-11-02
Also published as: WO2017189176A3; CN108886723A; CN108886723B

Abstract

Technology for a User Equipment (UE) operable to support a client connection manager (CCM) to communicate over a generic multi-access (GMA) control plane protocol, and to support a client Multi-Access Data Proxy (C-MADP) to communicate over a generic multi-access (GMA) user plane protocol is disclosed. The UE can decode an initial (INIT) request (REQ) message received from a network connection manager (NCM) for capability exchange & initial configurations. The UE can encode, for transmission to the NCM, an INIT response (RSP) message. The UE can encode, for transmission to the NCM, a reconfiguration request (REQ) message, wherein the reconfiguration message includes a connection identification (ID) to identify a connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

Description

GENERIC MULTI-ACCESS PROTOCOLS FOR NEXT

GENERATION MULTI-ACCESS NETWORKS

BACKGROUND

[0001] Wireless mobile communication technology uses various standards and protocols to transmit data between a node (e.g., a transmission station) and a wireless device (e.g., a mobile device). Some wireless devices communicate using orthogonal frequency-division multiple access (OFDMA) in a downlink (DL) transmission and single carrier frequency division multiple access (SC-FDMA) in uplink (UL). Standards and protocols that use orthogonal frequency-division multiplexing (OFDM) for signal transmission include the third generation partnership project (3 GPP) long term evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard (e.g., 802.16e, 802.16m), which is commonly known to industry groups as WiMAX (Worldwide interoperability for Microwave Access), and the IEEE 802.11 standard, which is commonly known to industry groups as WiFi.

[0002] In 3GPP radio access network (RAN) LTE systems (e.g., Release 13 and earlier), the node can be a combination of Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node Bs (also commonly denoted as evolved Node Bs, enhanced Node Bs, eNodeBs, or eNBs) or a 5G New Radio gNB (next generation Node Bs), which communicate with the wireless device, known as a user equipment (UE). The downlink (DL) transmission can be a communication from the node (e.g., eNodeB, gNB) to the wireless device (e.g., UE), and the uplink (UL) transmission can be a communication from the wireless device to the node.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Features and advantages of the disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate, by way of example, features of the disclosure; and, wherein:

[0004] FIG. 1 illustrates the protocol architecture for 3 GPP R13 LTE WLAN Radio Level Integration with Internet Protocol Security (IPsec) Tunnel (LWIP) in accordance with an example; [0005] FIG. 2 illustrates the protocol architecture for 3 GPP R13 LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) in accordance with an example;

[0006] FIG. 3 depicts a proposed Generic Multi-Access (GMA) U-plane Protocol Stack in accordance with an example;

[0007] FIG. 4A depicts a Trailer-based Multi-Access Encapsulation PDU (protocol data unit) Format in accordance with an example;

[0008] FIG. 4B depicts a Generic Multi-Access comprising a series of fields in accordance with an example;

[0009] FIG. 5 depicts a Generic Multi- Access Control Plane Protocol Stack (C-plane) in accordance with an example;

[0010] FIG. 6 illustrates an example control flow of a GMA control protocol procedure depicting a series of operations flexible such that any access network can be utilized in accordance with an example;

[0011] FIG. 7 illustrates an example control flow of a GMA control protocol procedure depicting a series of operations flexible such that any access network can be utilized in accordance with an example;

[0012] FIG. 8 illustrates an example GMA control message format in accordance with an example;

[0013] FIG. 9 depicts a Generic Multi- Access User Plane Protocol Stack (U-plane) in accordance with an example;

[0014] FIG. 10 illustrates a trailer-based multi-access encapsulation packet format in accordance with an example;

[0015] FIG. 11 illustrates an LWIP DL & UL Packet Format, in accordance with an example;

[0016] FIG. 12 depicts an LWIP tunnel setup procedure flow, in accordance with an example;

[0017] FIG. 13 illustrates an LWIP Encapsulation Protocol (EP) sublayer model for downlink (DL), in accordance with an example;

[0018] FIG. 14 depicts an LWIP uplink (UL) data radio bearer (DRB) switching procedure, in accordance with an example;

[0019] FIG. 15 illustrates an LWIP Encapsulation Protocol (EP) Data Protocol Data Unit (PDU) with LWIP Trailer, in accordance with an example;

[0020] FIG. 16 depicts functionality of an apparatus of a UE configured to communicate over a generic multi-access (GMA) control plane protocol stack, in accordance with an example;

[0021] FIG. 17 depicts functionality of an apparatus of a UE configured for Generic Routing Encapsulation (GRE) based tunneling for uplink (UL) and downlink (DL) communications, in accordance with an example;

[0022] FIG. 18 depicts functionality of an apparatus of a UE configured to perform control plane based LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) uplink (UL) data radio bearer (DRB) switching, in accordance with an example;

[0023] FIG. 19 depicts functionality of an apparatus of a UE configured to provide a data radio bearer (DRB) indication with internet protocol security (IPSec) tunneling, in accordance with an example;

[0024] FIG. 20 illustrates example interfaces of baseband circuitry in accordance with an example; and

[0025] FIG. 21 illustrates a diagram of a wireless device (e.g., UE) in accordance with an example.

[0026] Reference will now be made to the exemplary embodiments illustrated, and specific language will be used herein to describe the same. It will nevertheless be understood that no limitation of the scope of the technology is thereby intended.

DETAILED DESCRIPTION

[0027] Before the present technology is disclosed and described, it is to be understood that this technology is not limited to the particular structures, process actions, or materials disclosed herein, but is extended to equivalents thereof as would be recognized by those ordinarily skilled in the relevant arts. It should also be understood that terminology employed herein is used for the purpose of describing particular examples only and is not intended to be limiting. The same reference numerals in different drawings represent the same element. Numbers provided in flow charts and processes are provided for clarity in illustrating actions and operations and do not necessarily indicate a particular order or sequence.

EXAMPLE EMBODIMENTS

[0028] An initial overview of technology embodiments is provided below and then specific technology embodiments are described in further detail later. This initial summary is intended to aid readers in understanding the technology more quickly but is not intended to identify key features or essential features of the technology nor is it intended to limit the scope of the claimed subject matter.

[0029] A new standardization effort has been initiated by the internet Engineering Task Force (IETF) to support "Multiple Access Management Services" (MAMS)¹, which share many similarities with the 3GPP R13 LTE wireless local area network (WLAN)

Integration with Internet Protocol security (IPsec) Tunnel (aka LWIP). 3GPP LWIP can be seen as an example of the MAMS framework. The main difference between the two is that the transport of control signaling in 3GPP LWIP is supported by RRC messages. While the control signaling in MAMS is delivered over the top of user-plane packets, e.g. user datagram protocol (UDP) or transmission control protocol (TCP). In terms of similarity, client connection manager (CCM) in Multiple Access Management Services (MAMS) is very much similar to radio resource control (RRC) (c-plane) at UE in LTE WLAN Integration with IPSec tunnel (LWIP); Network Connection Manager (NCM) is similar to the RRC entity at an evolved Node B (eNB); Network Multi-Access Data Proxy (N-MADP) is similar to the LWIPEP entity at eNB. In addition, the MAMS solutions can be used to support Multi-Radio Access Technology (Multi-RAT) Integration using any tunneling protocol comprising UDP, TCP, GRE, IP-in-IP, IPSec, Ethernet, and others of the like.

[0030] The proposed Generic Multi-Access Protocols for Next Generation Multi -Access Networks comprises many of the functional elements of the network reference architecture for MAMS. An example of one of the functional elements is a client. The client is the end-user device supporting connections with multiple access nodes, possibly over different access technologies.

[0031] Another functional element is an access network element. The access network element is a functional element in the network that delivers user data packets to the client via a point-to-point access link like WiFi airlink, LTE airlink, DSL.

[0032] Another functional element is a core. The core is a functional element that anchors the client's IP address used for communication with applications via the network.

[0033] Another functional element is the Network Connection Manager (NCM). The NCM is a functional entity in the client that exchanges MAMS Signaling with the Network Connection Manager and configures the multiple network paths for transport of user data.

[0034] Another functional element is a Client Connection Manager (CCM). The CCM is a functional entity in the client that exchanges MAMS Signaling with the Network Connection Manager and configures the multiple network paths for transport of user data.

[0035] Another functional element is a Network Multi-Access Data Proxy (N-MADP). The N-MADP is a functional entity in the network handles the user data traffic forwarding across multiple network paths. N-MADP is responsible for MAMS-specific u- plane functionalities in the network.

[0036] Another functional element is a Client Multi-Access Data Proxy (C-MADP). The C-MADP is a functional entity in the client handles the user data traffic forwarding across multiple network paths. C-MADP is responsible for MAMS-specific u-plane

functionalities in the client.

[0037] In one example, the multiple access convergence and encapsulation protocol layer can be introduced between the IP layer and the link layer on the user plane (u-plane). The multiple access convergence and encapsulation protocol layer can be responsible for all multi-access related operations, e.g. aggregation, reordering, sequencing, cross-RAT retransmission, bearer identification, fragmentation, concatenation, etc.

[0038] In another example, the access adaptation and tunneling protocol layer can be introduced between the IP layer and the link layer on the u-plane. The access adaptation and tunneling protocol layer can be responsible for transporting multiple access (MA) encapsulated data traffic over an individual access (link) though additional tunneling, e.g. UDP tunneling, IPSec tunneling, GRE tunneling, etc., or NAT (network address translation), or no change at all.

[0039] In another example, a new Generic Multi Access (GMA) control protocol can be introduced. The new GMA control protocol can have the capabilities to manage various multi-access operations, including discovery, capability negotiation, reconfiguration, traffic steering/aggregation, probing, etc.).

[0040] In another example embodiments of the technology are not limited to LTE and Wi-Fi, and can be compatible amongst a plurality of different networks. For example, the plurality of networks comprises but is not limited to 3G, 4G LTE Rel. 8-14, 5G, Wi-Fi, WiGig, and MultiFire.

[0041] FIG. 1 provides an exemplary model of the protocol architecture 100 for 3 GPP Release 13 LTE WLAN Integration with IPsec Tunnel (LWIP). The eNB 110 is the mobility anchor, and WLAN/3GPP link aggregation is transparent to the 3GPP core network elements (e.g. MME, S-GW, and P-GW).

[0042] In another example the UE 110 can establish an LWIP tunnel 150 with eNB 110 via WLAN 140 through LWIP-SeGW 130. IPSec may be used to protect the UE's (IP) traffic over the LWIP tunnel 150, which is transparent to WLAN 140, and does not change to the existing WLAN 140 deployment.

[0043] In additional example, traffic steering and multi-RAT radio resource management (RRM) can take place over the top of the LTE RAN u-plane protocol stack (above PDCP).

[0044] FIG. 2 provides an example illustration of encapsulation protocol 200 to support LWIP with minimal overhead and additional new capabilities, e.g. fragmentation, concatenation, aggregation (bearer splitting), local access, and/or reliable switching.

[0045] In another example, the encapsulation protocol can comprise of an IP Header for Wi-Fi 210, an IPSec encapsulation security payload (ESP) Header 220, an IP Header for LTE 230, an IP Payload for LTE 240, an LWIP Trailer 250, an IPSec ESP Trailer 260, and an IPSec ESP Auth Trailer 270.

[0046] In another embodiment, the trailer based encapsulation protocol 200 method can be extended to support generic multiple access networks, which may consist of any access technology (e.g. 3G, 4G LTE, 5G, Wi-Fi, WiGig, and MultiFire, etc.).

[0047] FIG. 3 depicts a proposed Generic Multi-Access (GMA) User-plane (U-plane) Protocol Stack 300. The GMA U-plane protocol stack can comprise an applications layer 310, a Transmission Control Protocol/User Datagram Protocol (TCP/UDP) layer 320, an anchor connection IP for Layer 1 (LI) and Layer 2 (L2) communications 330, a GMA Convergence sub layer 340, an GMA Adaptation sub layer 360; an anchor access layer 350, a delivery access IP layer 370, and a link layer 380.

[0048] In another example of the GMA U-plane Protocol Stack 300, multiple access networks can be integrated into a single end-to-end (e2e) IP connection. The e2e IP connection that can be used for interfacing with the higher transport layers can be considered to be Anchor connections. In addition, the other associating IP connections that can be used for delivering data traffic of the anchor IP connection, can be considered to be delivery connections.

[0049] In another example, a 3 GPP LTE Release 13 LWIP enabled network is shown in FIG. 1. An e2e application can be enabled to run with an LTE IP address. In such an example, the LTE network can be the anchor connection, and the Wi-Fi network can be the delivery connection.

[0050] In another embodiment, the GMA u-plane protocol of FIG. 3 can comprise the GMA convergence sub-layer and the GMA Adaptation sub-layer, between the anchor access IP layer and the multi-access link layer. The GMA Convergence sub-layer can encapsulate and decapsulate a user's data traffic, e.g. IP packet, with additional control information, e.g. sequence number, DRB ID, etc., and support multi-access convergence functions, e.g. aggregation, splitting/reordering, fragmentation, concatenation, etc. In some scenarios, encapsulation may not be used, for example when sending packet over the anchor connection.

[0051] In another example, the GMA access and adaptation sub layer can be utilized for tunneling (AAT) and transport MA encapsulated packets over individual access.

Tunneling can be configured to send the GMA encapsulated IP packet (inner) in another IP packet (outer) through IP-in-IP, UDP or IPSec tunneling. Also, a client net address translation (NAT) can be configured to change the Client IP address of the GMA encapsulated IP packet, and then send it over an access network. In addition, a no change or pass-through operation can be utilized to send the GMA encapsulated IP packet directly without any change over the anchor connection. Further, the AAT process may be configured differently depending on individual access. For example, if an access network is considered "trusted", client NAT or UDP can be used as the tunneling method;

otherwise if it is "untrusted", IPSec could be used as the tunneling method.

[0052] FIG. 4A depicts a Trailer-based Multi-Access Encapsulation PDU (protocol data unit) Format 400, wherein the PDU format comprises an IP header 410 an IP payload 420. The IP payload 420 can comprise a fragmentation of an IP packet or a plurality of IP packets, and a generic multi-access (GMA) trailer 430.

[0053] In one embodiment, the GMA trailer can comprise several if not all of the fields discussed in the proceeding paragraphs and displayed in one of several variations and orders within FIG. 4B. One example field is the Next Header 435, which can be 8 bits and comprises the IP protocol type of the first (or only) IP packet contained in the PDU.

Another example field can be the connection identification (ID) 440, comprising an unsigned integer to identify the anchor connection ID of the IP packet(s) contained in the PDU. Another example field can be a traffic class ID 445, wherein the traffic class ID can comprise a flow or class identification, such as a data radio bearer ID for a cellular connection. Another example field can be a sequence number 450, which can be 16 bits, comprising an auto incremented integer by an encapsulator to indicate order of transmission of the IP packet. Notice that Sequence Number could be counted separately for each traffic class of an anchor connection. This can further be utilized by a decapsulator to re-order the IP packets. The same sequence number could be used by all the fragments of an IP packet. Another example field can be a packet length 455, which can be 2 Bytes, comprising the first IP packet contained in the PDU. It is included only with concatenation, i.e. one PDU consist of multiple IP packets. Another example field can be a fragmentation control 460, which can be 2 bits, configured to indicate where the fragmentation packet is in the original packet. For example, the indication of the fragmentation packet can indicate a first, middle, last, or no fragmentation (e.g. 00: first; 01 : middle; 10: last; 11 : no fragmentation). In another example, the fragmentation control field can include a bit (More Fragment) flag to indicate whether the fragment in the PDU is the last fragment of an IP packet or not, and a offset field to specify the offset (in the units of fragments) of a particular fragment relative to the beginning of the original unfragmented IP packet.

[0054] In another example the IP header of the original IP, version 4 or version 6, packet can comprise one or more of several fields that can be updated by the Multi-Access Convergence protocol. One example field can be a protocol type wherein "114" can be used to indicate that the Multi-Access Convergence protocol is a "0-hop" protocol, not subject to IP routing. It also indicates the presence of the GMA trailer. Another example field of the IP header can be an IP length, wherein the IP length can be updated to add the length of "Multi -Access Trailer" and the length of any concatenated IP packet. Another example field of the IP header can be an IP checksum, wherein the IP checksum can recalculate after changing the Protocol Type and the IP length. However, if UDP tunneling is used as the tunneling method, the IP header of the original IP packet may be kept unchanged. Moreover, if a PDU contains multiple IP packets, only the first IP packet is subject to the above changes.

[0055] In another embodiment, the GMA convergence encapsulation protocol can support multiple connections simultaneously, each of which can be uniquely identified by the connection ID. It can also support multiple traffic classes or bearers for each connection.

[0056] In another embodiment, the GMA trailer format can be negotiated dynamically. Further, the NCM can send a control message using a bitmap to indicate which of the above fields should be included for each individual connection, on downlink and uplink respectively.

[0057] FIG. 5 depicts a Generic Multi-Access Control Plane Protocol Stack (C-plane). The GMA c-plane protocol stack 500, can comprise each of, the following layers: a multi access management control 510, a UDP 520, a Primary Access IP 530, a Primary Access Link 1 and Link 2 (L1/L2) 540, a GMA Adaptation sub-layer 550, a secondary access IP layer 560, and a link access layer 570. Additional layers may also be included, based on the system setup.

[0058] In another embodiment, the UDP or TCP (HTTP) can be used for delivering control messages. Here, the IP connection used for initial GMA set-up is called

"Primary", and all other connections that are added through the GMA procedure is called "Secondary". "Connection ID = 0" can be reserved for the Primary connection.

[0059] In another embodiment, as in 3GPP LTE Release 13 LWIP, LTE can be designated in LWIP as always the primary connection, and Wi-Fi can be designated as the secondary connection. Regarding the GMA protocol stack 500, the GMA protocol can be flexible in such a way that any access network can be primary connection. Accordingly, the GMA protocol stack is not limited to an LTE connection as a primary connection.

[0060] FIG. 6 illustrates an example control flow of a GMA control protocol procedure depicting a series of operations flexible such that any access network can be utilized. The GMA control procedure flow 600 comprises several operations.

[0061] In one embodiment, operation one can comprise a Client Connection Manager (CCM) 610 that periodically sends out a GMA discovery message over a primary connection to a pre-defined destination IP address and UDP port. The GMA discovery message can include a version indication, to indicate the version of the GMA control procedure.

[0062] In another embodiment, operation two can comprise a capability exchange, wherein from a GMA discovery message, NCM 620 learns the IP address and port number of the primary connection to communicate with CCM 610, and sends out the initial request (INIT-REQ) message. The INIT REQ message can include a capability bitmap of each bit indicates if the corresponding capability is supported by NCM/N- MADP 620 or not. The bit indications can include the following: Bit #0: Lossless switching; Bit #1 : Fragmentation; Bit #2: Concatenation; Bit #3 ~ 5: Multi-Link

Aggregation/Reordering Support. Further, the Multi-Aggregation/Reordering Support can be the following: 0: no aggregation; 1 : Downlink (DL) aggregation with only delivery connections but not anchor connection; 2: Uplink (UL) aggregation with anchor & delivery connections; 3: DL &UL aggregation with only delivery connections; 4: DL aggregation with anchor & delivery connections; 5: UL aggregation with anchor and delivery connections; and DL & UL aggregation with anchor and delivery connections.

[0063] Further, there are also a number of secondary connections that can be indicated in the INIT REQ message. For each secondary connection and primary connections, they can include a plurality of different indicators. One example of an indicator is a

Connection identification (ID), comprising indications of 0, 1, 2, etc., wherein 0 is always reserved for the primary connection. Another example of an indicator is a connection type, which can comprise of indicators of 0 representing Wi-Fi; 1 representing 5G; 2 representing Multi-Fire; and 3 representing LTE. Another example of an indicator is a multi-access tunneling & adaptation support Bitmap, wherein each bit represents whether the corresponding tunneling & adaptation method is supported by N-MADP when the connection functions as a delivery connection, e.g. bit #0: UDP; bit #1 : IPSec; bit #2: NAT, (0: not supported, 1 : supported). Another example of an indicator is a connection function, wherein the connection function indicates the role of the connection on the u- plane (e.g. 0: anchor only: 1 delivery only; 2 anchor or delivery). Another example indicator is an AAT end-point IP v4/v6 address, wherein the IPv4/v6 address is the IP address of the tunnel at N-MADP, wherein the N-NADP is not used if NAT is used for AAT. Another example indicator is an AAT-specific configuration, where there is a UDP port number of the tunnel at N-MADP or of within the IPSec pre-shared key.

[0064] In another embodiment, in response to the NCM's 620 sent INIT-REQ message, the CCM 610 can send out an initial response (INIT-RSP) message, including a capability bitmap wherein each bit indicates if the corresponding capability is supported by CCM/C- MADP 610 or not, and a number of secondary connections. For each secondary connection and primary connection, one or more indicators are included. An example of an indicator can be a connection ID, wherein the indications can be 0, 1, 2, etc., wherein 0 is reserved for the primary connection. Another example of an indicator can be a connection function, wherein the connection function indicates the role of the connection on the u-plane (e.g. 0: anchor only: 1 delivery only; 2 anchor or delivery). Another example of an indicator is an AAT Support Bitmap, wherein the AAT Support Bitmap is configured so that the CCM 610 should only set one bit to "1", indicating the

corresponding AAT method will be used when the connection functions as delivery , e.g. bit #0: UDP; bit #1 : IPSec; bit #3: NAT, etc. Also, the AAT method can be also supported by NCM, as indicated in the INIT-REQ message.

[0065] In another embodiment, operation 3 can comprise operations for configurations when the link is up or down. The CCM 610 can send out a Reconfiguration Request (REQ) Message to set up or release the secondary connection. The Reconfiguration REQ Message can include a reconfiguration action wherein, the reconfiguration indicates which reconfiguration action to request (0: release; 1 : setup) and a Connection ID to identify the connection for the reconfiguration.

[0066] Where the reconfiguration action indicated is "setup", the Reconfiguration REQ message can indicate the IP address of the connection, and the maximum transmission unit (MTU) size of the connection.

[0067] In response, the NCM 620 can send out a reconfiguration response (RSP) message, including a connection ID which indicates the secondary connection to reconfigure, and a reconfiguration action to request 0: release; or 1 : setup. Where the reconfiguration is "setup" the indication of "setup" will have one or more of the following indicators. An example indicator can be a DL GMA Trailer Format Bitmap, wherein each bit indicates if the corresponding trailer field is enabled or disabled for downlink. Another example indicator can be an UL GMA Trailer Format Bitmap wherein each bit in the UL GMA Trailer Format Bitmap indicates if the corresponding trailer field is enabled or disabled for uplink. Another example indicator can be a maximum GMA PDU size, wherein the maximum GMA PDU size indicates the maximum length of a GMA encapsulated PDU packet.

[0068] In another embodiment within FIG. 7, operation four can comprise an NCM 720 configured to send out a Probe-REQ message, which carries Connection ID, to indicate the corresponding connection over which the probe message should be delivered. In response, CCM 710 sends out a Probe-RSP message also carrying Connection ID. This will allow NCM 720 to measure round trip time of the connection, and decide whether to switch data traffic over to the connection.

[0069] In another embodiment, operation five can be comprised of an NCM 720 configured to send out a Switching-REQ message to steer data traffic of an anchor connection. It is also possible to send data traffic over multiple connections

simultaneously, i.e. aggregation. The switching-REQ message can comprise one or more of the following indicators. One example indicator can be a connection ID of the anchor connection to indicate IP data packets of which anchor connection are subject to the requested traffic switching operation. Another example indicator can be a connection ID of the connection for delivering DL bitmap traffic, wherein each bit representing the corresponding connection is used to deliver DL traffic or not. Another example indicator can be a connection ID of the connection for delivering UL bitmap traffic, wherein each bit representing the corresponding connection is used to deliver UL traffic or not. Another example indicator can be a DL reordering indicator, wherein the DL reordering indicator can be a bit field to indicate if reordering is enabled or not for DL traffic. If reordering is not enabled, an IP flow can't be sent over multiple connections simultaneously. Instead, multiple IP flows may be sent over different connections for the purpose of aggregation. Another example indicator can be a UL reordering indicator, wherein a bit field is configured to indicate if reordering is enabled or not for UL traffic. Another example indicator can be a last received sequence number (SN) for UL, wherein the last received SN for UL can be used to support lossless switching.

[0070] In response, the CCM 710 sends out a switching-RSP message, including

Connection ID of the IP anchor connection and Last Received SN (for DL), which can be used to support lossless switching. Lastly, NCM 720 sends out a Switching- ACK message without any additional information. Here "Switching RSP" and "Switching- Acknowledgment (ACK)" may also be used as end-marker for in-order delivering.

[0071] FIG. 8 illustrates an example GMA control message format. The GMA control message format may comprise one or more of the following fields. One example field may be a version field 810, which indicates the version of the GMA control message format. Another example field can be a message type 820, wherein the message type indicates the type of the message, e.g. discovery, INIT-REQ/RSP, etc. Another example field can be a sequence number field 830, wherein an auto-incremented integer can be configured to uniquely identify a transaction of message exchange, e.g. INIT-REQ/RSP. Another example field can be a message payload type-length-value (TLV) 840. The message payload TLV 840 can comprise a plurality of control information elements, depending on the message type.

[0072] FIG. 9 depicts a Generic Multi-Access (GMA) User Plane (U-Plane) Protocol Stack 900. The GMA U-Plane protocol stack 900 can integrate multiple access networks into a single e2e IP connection. LTE-WiFi Integration with IPSec in R13 is just one such example.

[0073] In one example two additional layers can be added for the multi-access convergence protocol after the Application layer 910, the TCP/UDP layer 920 and between the IP layer 930 and Link (Access) layer 960(a-c). These layers can comprise a multi-access encapsulation (MAE) layer 940 and an access adaptation and tunneling (AAT) layer 950. The MAE 940 is configured to encapsulate and decapsulate user's data traffic, e.g. IP packet, with additional control information, e.g. sequence number, Data Radio Bearer (DRB) ID, etc., and support multi-access convergence functions, e.g.

aggregation, reordering, fragmentation, concatenation, etc. In addition, the AAT 950 is configured to transport multi-access (MA) encapsulated packets over individual access or may vary depending on individual access configuration, while using one or more of the following methods for transport. One example method to be used for transport is tunneling, wherein the AAT layer 950 is configured to send the MA encapsulated IP packet (inner) in another IP packet (outer) through IP-in-IP, UDP, or IPSec tunneling. Another example method is a client net address translation (NAT), wherein the AAT 950 is configured to change the client IP address of the MA encapsulated IP packet, and then send it over an access network 960. Another example method is a no change, wherein the AAT 950 is configured to send the MA encapsulated IP packet directly without any change.

[0074] FIG. 10 illustrates a trailer-based multi-access encapsulation packet format. The trailer based multi-access encapsulation packet format can comprise an IP header (version 4 or version 6), an IP payload 1020, and a multi-access trailer (MAT) 1030. The MAT

1030 may consist of one or more of the following fields. One example field is a flag field, which can be 8 bits, wherein each bit represents any of the following MAT 1030 fields is present or not. Another example field is a next header field, which can be 8 bits, wherein the IP protocol type of the original IP packet is indicated. Another example field is a connection ID field, wherein the connection identification is indicated. For example,

"000" can be used to indicate a cellular connection, and "001" indicates a packet belongs to a local (Wi-Fi anchored) connection. Another example field can be a traffic class ID, which can be 5 bits, wherein a flow or class identification is indicated, such as a Data Radio Bearer ID for a cellular connection. Another example field can be a sequence number field, which can be 16 bits, wherein the sequence number is configured to be an auto-incremented integer by an encapsulator to indicate order of transmission of the IP packet. This additionally can be used by a decapsulator to re-order the packets.

[0075] In another example, the proposed multi-access encapsulation protocol can support multiple (IP) anchors/connections simultaneously, each of which can be uniquely identified by Connection ID. It can also support multiple traffic classes or bearers for each connection.

[0076] In another embodiment, the following fields of the IP header 1010 of the original IP (version 4 or version 6) packet can be updated. An IP header 1010 that can be updated is the protocol type, wherein the protocol type can be updated to "114" to indicate that the Multi -Access Convergence protocol is a "0-hop" protocol, not subject to IP routing. An IP length field can also be updated to add the length of the Multi-Access Trailer 1030.

Additionally, an IP checksum field can be updated to recalculate after changing the protocol type and IP length fields.

[0077] FIG. 11 illustrates an LWIP DL & UL Packet Format 1100. The LWIP DL & UPL Packet Format 1100 is configured to support LWIP with minimal overhead and additional new capabilities, e.g. fragmentation, concatenation, aggregation (bearer splitting), local access, reliable switching.

[0078] In another example, the LWIP DL Packet Format 1100 can comprise an IP Header for Wi-Fi 1110, an IPSec ESP Header 1120, an IP Header for LTE 1130, an IP Payload for LTE 1140, an IPSEC ESP Trailer 1150, and an IPSec ESP Auth Trailer 1160.

[0079] In another example, the LWIP UL Packet Format 1100 can comprise an IP Header for Wi-Fi 1110, an IPSec ESP Header 1120, a GRE Header 1170, an IP Header for LTE 1130, an IP Payload for LTE 1140, an IPSEC ESP Trailer 1150, and an IPSec ESP Auth Trailer 1160.

[0080] In another embodiment, the IPSec ESP Trailer 1150 and IPSec ESP Auth Trailer 1160 of the LWIP DL & UL Packet Format 1100 for DL and UL can be extended to support generic multiple access networks, which may consist of any access technology (e.g. 3G, 4G LTE, 5G, Wi-Fi, WiGig, and MultiFire, etc.).

[0081] FIG. 12 depicts an LWIP tunnel setup procedure flow. The basic principle is to configure DL and UL with the same tunneling method for both IPSec tunneling or GRE tunneling. For, IPSec tunneling, there is no impact if UE only has one UL DRB active. As such the configuration of c-plane based and u-plane based tunneling can be utilized.

Within c-plane based, the eNB will configure UE to only use the IPSec tunnel for one of its active UL DRBs at a time through the control (RRC) message. Within u-plane based, a new LWIPEP method is introduced to carry "DRB ID" without using another header (e.g. Generic Routing Encapsulation (GRE)). Currently, for GRE tunneling, there is no change or impact to UL. As such, the introduction of an enhanced LWIP Encapsulation Protocol (EP) such that the legacy GRE header will be used for DL without carrying a DRB ID will be a beneficial embodiment.

[0082] In an example embodiment, the eNB 1230 sends an

RRCConnectionReconfiguration message to a UE 1210 including the necessary parameters (GRE tunneling & IPSec transport mode configuration) to establish a GRE tunnel over WLAN 1220 and then protect the GRE tunnel with the IPSec transport mode. Additionally, if DRB's are not already configured, DRBs can be configured to utilize the GRE tunnel. The UE 1210 can then send a RRC Connection Reconfiguration Complete message to the eNB 1230, along with measurements of the WLAN 1220. The eNB 1210 can then respond with a RRC Connection Reconfiguration message, and receive a RRC Connection Reconfiguration Complete message in return from the UE 1210. An additional operation of WLAN 1220 association can take place, if the WLAN has not already been associated with the UE 1210 and eNB 1230.The UE 1210 can additionally provide a WLAN Connection Status Report, in order to confirm the association of the WLAN 1220 with the LWIP Tunnel Setup, to the eNB 1230. In response, the eNB 1230 can provide a RRC Connection Reconfiguration message to the UE 1210, where the UE 1210 can provide a RRC Connection Reconfiguration Complete message to the eNB 1230 in response.

[0083] In another embodiment, a bi-directional GRE tunnel protected with the IPSec transport mode is established between UE 1210 and eNB 1230 via the WLAN 1220 link.

[0084] FIG. 13 illustrates an LWIP Encapsulation Protocol (LWIPEP) sublayer model for downlink (DL). The model 1300 provides a simplified LWIPEP protocol for DL from an eNB to a UE. The model comprises an upper layer 1310 and a lower layer 1320. In the downlink direction, at the eNB when an LWIPEP entity receives an LWIPEP Service Data Unit (SDU) from upper layers 1310, it constructs the corresponding LWIPEP Protocol Data Unit (PDU) and it can deliver it to the lower layers 1320. Also, at the UE, when an LWIPEP entity receives an LWIPEP PDU from the lower layers 1320, it reassembles the corresponding LWIPEP SDU and it can deliver it to upper layers 1310.

[0085] In another embodiment the LWIPEP header for downlink is can also be a GRE header, the same as for uplink. In this scenario, there can be an option to refrain from indicating DRB Identify for downlink traffic so that all the GRE header fields remain unused. [0086] In another embodiment, an IPSec tunnel mode for both DL and UL can be utilized. This could provide enhancement and benefits over the GRE tunnel of using less overhead, and providing simpler UE implementation.

[0087] FIG. 14 depicts an LWIP uplink (UL) data radio bearer (DRB) switching procedure. In the proposed embodiment, in order to indicate DRB identification with the IPSec tunneling method, a c-plane based LWIP UL DRB switching procedure could be implemented.

[0088] In one embodiment the UE 1410 can have multiple UL DRBs activated, the eNB can send out a RRC Connection Reconfiguration message to indicate that only one UL DRB will be sent over the IPSec tunnel, and the remaining DRBs can be sent over the LTE link. Moreover, an eNB can indicate in the message, a DRB switching timer, or define a default value in the standard.

[0089] In another embodiment, the DRB switching timer can indicate the minimal interval between receiving the RRC Connection Reconfiguration message for switching a new DRB over to the LWIP tunnel and sending the first UL packet of the new DRB to the LWIP tunnel. The previous DRB using the LWIP tunnel can be switched back to LTE immediately upon reception of a RRC Connection Reconfiguration message. This gap allows eNB 1430 to identify which DRB a received UL packet belongs to during the switching.

[0090] In another embodiment the UE 1410 and eNB 1430 can have an IPSec tunnel setup via WLAN 1420, and the UE's 1410 first UL DRB (DRB #A) can be delivered over the IPSec tunnel. The eNB can determine if it has to deliver UE's 1410 second UL DRB (DRB #B) over Wi-Fi and move DRB #A back to LTE. The eNB 1430 can then send the RRCConnectionReconfiguration message to the UE including the indication to switch DRBs. The UE 1410 can then apply the new configuration and reply with an

RRCConnectionReconfigurationComplete message. The UE 1410 can then move DRB #A back to LTE immediately, and wait for "DRB switching timer" to start sending DRB #B over the IPSec tunnel.

[0091] In another embodiment, two additional LWIPEP methods can add the DRB identity indication without introducing a new header (e.g. GRE) in front of LWIPEP SDU (IP packet). The first method can use one of the IP header fields of LWIPEP SDU, e.g. TTL or DSCP or ToS to carry DRB ID. In the uplink direction, at the UE 1410, an LWIPEP entity can receive an LWIPEP SDU from upper layers, it can modify the LSB 5 bits of the selected IP header field (e.g. TTL or DSCP or ToS) to carry DRB ID and it can construct the corresponding LWIPEP PDU and deliver it to lower layers. At the eNB 1430, when an LWIPEP entity receives an LWIPEP PDU from lower layers, it can change the last selected 5 bits (LSB) of the selected IP header field back to its original value to resemble the corresponding LWIPEP SDU and delivers it to upper layers. The eNB 1430 can indicate to the UE 1410, using the RRC message, which field of the IP header will be used to carry DRB ID, or this field is pre-defined in 3GPP standard. In response, the UE 1410 can indicate the original value of the selected IP header during in the RRC

Connection Reconfiguration Complete for the DRBs that are configured to send over the LTE link.

[0092] In the second method, a new LWIP trailer can be added to the end of the LWIPEP SDU as indicated within FIG. 15, which illustrates an LWIP Encapsulation Protocol (EP) Data Protocol Data Unit (PDU) with LWIP Trailer. The new LWIP trailer 1520 can comprise one or more of a DRB ID, a Sequence Number, an IP Header Checksum, and a Next Header, which holds the protocol type of the LWIPEP SDU 1510 payload (IP Payload).

[0093] In another embodiment where the LWIP trailer 1520 can or cannot be added, two options can be implemented. In the first option, a new IP protocol type can be specified to indicate the new IP payload type (i.e. LWIPEP PDU (= LWIPEP SDU + LWIP Trailer). In the second option, an IP Protocol type of "114" can be specified to indicate any 0-hop protocol.

[0094] In another embodiment, the LWIPEP receiver can detect if LWIP trailer 1520 is present or not based on the IP protocol type field in the IP header of a LWIPEP PDU. In the uplink or downlink direction, at the UE or the eNB, upon an LWIPEP entity receiving an LWIPEP SDU 1510 from upper layers, it can add the LWIP trailer 1520 to construct the corresponding LWIPEP PDU. It can also set the "Protocol Type" field to 114, recalculate and update the IP length and checksum, and then deliver the LWIPEP PDU to lower layers. If the "IP header checksum" field is present in the LWIP trailer 1520, the UE or the eNB could set it to the checksum value of the original IP header. [0095] In another embodiment, at the eNB or the UE, the LWIPEP entity can receive an LWIPEP PDU from lower layers, it can check its "Protocol Type" field and determines if the LWIP trailer 1520 is present or not. If yes, it can remove the LWIP trailer 1520 to resemble the corresponding LWIPEP SDU 1510, set the "Protocol Type" of IP header to the value in the Next Header field of the LWIP trailer, recalculate and update the IP length and checksum, and then deliver it to the upper layers. If the "IP header checksum" field is present in the LWIP trailer 1520, the eNB or the UE does not have to recalculate IP header checksum, but can use the value in this field directly.

[0096] In another embodiment the LWIP activation procedure of FIG. 12 can be enhanced at operation 9 in order to enable and disable LWIPEP for the DL and UL tunnel respectively. Additionally, if DRBs have not already been configured, DRBs can be configured to utilize the IPSec tunnel.

[0097] In another embodiment, the LWIP trailer may not be used for DL traffic. But, the sequence number information in the LWIP trailer of FIG. 15, 1520, and FIG. 2, 250, may be useful for link quality measurement, and the eNB may still be configured to enable the LWIP trailer for DL traffic.

[0098] Another example provides functionality 1600 of an apparatus of a User

Equipment (UE) having a client connection manager (CCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack, as shown in FIG. 16. The apparatus of the UE can comprise of memory and one or more processors configured to decode, an initial (INIT) request (REQ) message received from a network connection manager (NCM) 1610. The apparatus of the UE can also comprise of memory and one or more processors configured to encode, for transmission to the NCM, an INIT response (RSP) message 1620. The apparatus of the UE can also comprise of memory and one or more processors configured to encode, for transmission to the NCM, a reconfiguration request (REQ) message 1630. In addition the REQ message can include a connection identification (ID) to identify a connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

[0099] In one embodiment the INIT REQ message can include one or more of a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NC. The INIT REQ message can also include a number of secondary connections. The INIT REQ message can also include a connection type. The INIT REQ message can also include an access and adaptation tunneling (AAT) support bit map. The INIT REQ message can also include a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end-point internet protocol (IP) address; or, an AAT-specific configuration.

[00100] In one embodiment the INIT REQ message can include one or more of a capability bitmap, wherein each bit in the capability bitmap indicates when a

corresponding capability is supported by the NCM. The INIT REQ message can also include one or more of the prior or a number of secondary connections. The INIT REQ message can also include on or more of the prior or an access and adaptation tunneling (AAT) support bit map. The INIT REQ message can also include on or more of the prior or a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery.

[00101] In one embodiment the reconfiguration action of setup, in a CCM reconfiguration REQ message, can include an IP address of a connection or a maximum transmission unit (MTU) size of the connection.

[00102] In another embodiment wherein the NM sends a reconfiguration message RSP message, the reconfiguration RSP message can include a connection identification (ID) to identify a secondary connection for reconfiguration. The reconfiguration RSP message can also include a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

[00103] In another embodiment there can be a reconfiguration action request of a setup in a NCM reconfiguration RSP message. The NCM reconfiguration RSP message can include a downlink (DL) GMA trailer format bitmap, wherein each bit in the DL GMA trailer indicates if a corresponding trailer field is enabled or disabled for DL. The NCM reconfiguration RSP message can also include an uplink (UL) GMA trailer format bitmap, wherein each bit in the UL GMA trailer indicates that a corresponding trailer field is enabled or disabled for uplink. The NCM reconfiguration RSP message can also include a maximum GMA protocol data unit (PDU) payload size, wherein the GMA PDU indicates the maximum payload size of a GMA encapsulated PDU.

[00104] In another embodiment, the probe REQ message sent by the NCM can include a connection ID to indicate a corresponding connection for the probe REQ message to be delivered.

[00105] In another embodiment, the CCM can be configured to encode a probe RSP message. The probe RSP message can include a connection ID to indicate a round trip calculation of a connection, and to indicate when to switch data traffic over to the connection.

[00106] In another embodiment a switching REQ message can be sent by the NCM. The switching REQ message can be sent to steer data traffic of an anchor connection, or a plurality of anchor connections simultaneously.

[00107] In another embodiment the CCM can send a switching RSP message to confirm a traffic steering operation.

[00108] In another embodiment a switching REQ message can include one or more of a connection ID of the anchor connection. The switching REQ message can also include one or more of a connection ID of a downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing a corresponding primary or a secondary connection is used to deliver DL traffic. The switching REQ message can also include one or more of a connection ID of an uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a corresponding primary or a secondary connection that is used to deliver UL traffic. The switching REQ message can also include one or more of a UL reordering indicator, wherein the UL reordering indicator is a bit field that indicates whether reordering is enabled or disabled. The switching REQ message can also include one or more of a DL reordering indicator, wherein the DL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a UL last received Sequence Number, which indicates a last received UL packet for lossless switching.

[00109] In another embodiment a switching RSP message can include one or more of a connection ID of the anchor connection or a DL last received Sequence Number (SN), which indicates a last received DL packet for lossless switching.

[00110] In another embodiment the CCM can send a switching ACK message to confirm a successful reception of the switching RSP.

[00111] Another example provides functionality 1700 of an apparatus of a User

Equipment (UE) having Generic Routing Encapsulation (GRE) based tunneling for uplink (UL) and downlink (DL) communications in an LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) operation, as illustrated in FIG. 17. The apparatus of the UE can comprise of memory and one or more processors configured to encode, for transmission to an evolved node B (eNB) a wireless local area network (WLAN) connection status report to confirm a WLAN association 1710. The apparatus of the UE can also comprise of memory and one or more processors configured to decode a radio resource control (RRC) connection reconfiguration message received from the eNB 1720. Wherein, the RRC connection reconfiguration message comprises configuration parameters for an Internet Protocol Security (IPSec) transport mode; and, configuration parameters for GRE tunneling. The apparatus of the UE can also comprise of memory and one or more processors configured to encode an RRC connection reconfiguration complete message for transmission to the eNB to establish a bidirectional GRE tunnel between the UE and the eNB for the UL and the DL over the WLAN and protect the bidirectional GRE tunnel with the IPSec transport mode 1730.

[00112] In one embodiment, the one or more processors are configured are configured to configure one or more data radio bearers (DRB) to use the GRE tunnel.

[00113] Another example provides functionality 1800 of an apparatus of a User

Equipment (UE) configured to perform control plane based LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) uplink (UL) data radio bearer (DRB) switching, as depicted in FIG. 18. The apparatus of the UE can comprise of memory and one or more processors configured to decode a radio resource control (RRC) connection

reconfiguration message received from an evolved Node B (eNB) 1810. Wherein, the RRC connection reconfiguration message comprises information for the UE to switch from a first DRB operating over an internet protocol security (IPSec) tunnel to a second DRB operating over the IPSec tunnel. The apparatus of the UE can also comprise of memory and one or more processors configured to identify a DRB switching timer value in the RRC connection re-configuration message 1820. Wherein the DRB switching timer value provides a minimal interval for the UE between receiving the RRC Connection Reconfiguration message and sending UL packets of the second DRB over the IPSec tunnel. The apparatus of the UE can also comprise of memory and one or more processors configured to encode the UL packets to send over the IPSec tunnel via the second DRB after the DRB switching timer value to enable the eNB to identify which DRB a received UL packet belongs to 1830.

[00114] In one embodiment the one or more processors are configured are configured to move the first DRB from the IPSec tunnel to a 3 GPP link with the eNB.

[00115] In one embodiment the one or more processors are configured are configured to encode, for transmission to the eNB, and RRC connection reconfiguration complete message.

[00116] Another example provides functionality 1900 of an apparatus of a User

Equipment (UE) configured to provide a data radio bearer (DRB) indication with internet protocol security (IPSec) tunneling, as shown in FIG. 19. The apparatus of the UE can comprise of memory and one or more processors configured to modify predetermined bits, in an LTE WLAN Radio Level Integration with IPsec Tunnel Encapsulation Protocol (LWIPEP) service data unit (SDU) of a selected internet protocol (IP) header field to carry a DRB identification (ID) 1910. The apparatus of the UE can also comprise of memory and one or more processors configured to construct an LWIPEP protocol data unit (PDU) from the LWIPEP SDU 1920. The apparatus of the UE can also comprise of memory and one or more processors configured to encode the LWIPEP PDU containing the DRB ID for transmission to a evolved node B (eNB) to enable the eNB to associate data packets with a selected DRB based on the DRB ID 1930.

[00117] In one embodiment the one or more processors are configured are configured to decode a radio resource control (RRC) message from the eNB indicating which field of the selected IP header is used to carry the DRB ID.

[00118] In one embodiment the field of the selected IP header can be one or more a Time to Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a Type of Service (ToS) field.

[00119] In one embodiment the one or more processors are configured to indicate an original value of the modified bits of the selected IP header in an RRC configuration complete message to enable the eNB to restore the modified bits to the original value. [00120] In one embodiment the end of the LWIPEP SDU can comprise of and LWIP trailer comprising a DRB ID, a sequence number, an IP header Checksum and a next header.

[00121] FIG. 20 illustrates example components of a device in accordance with some embodiments. In some embodiments, the device 2000 may include application circuitry 2002, baseband circuitry 2004, Radio Frequency (RF) circuitry 2006, front-end module (FEM) circuitry 2008, and one or more antennas 2010, coupled together at least as shown. The components of the illustrated device 2000 may be included a UE or a RAN node. In some embodiments, the device 2000 may include less elements (e.g., a RAN node may not utilize application circuitry 2002, and instead include a processor/controller to process IP data received from an EPC). In some embodiments, the device 2000 may include additional elements such as, for example, memory /storage, display, camera, sensor, and/or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations).

[00122] The application circuitry 2002 may include one or more application processors. For example, the application circuitry 2002 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory /storage and may be configured to execute instructions stored in the memory /storage to enable various applications and/or operating systems to run on the system. In some embodiments, processors of application circuitry 2002 may process IP data packets received from an EPC.

[00123] The baseband circuitry 2004 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 2004 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 2006 and to generate baseband signals for a transmit signal path of the RF circuitry 2006. Baseband processing circuity 2004 may interface with the application circuitry 2002 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 2006. For example, in some embodiments, the baseband circuitry 2004 may include a second generation (2G) baseband processor 2004a, third generation (3G) baseband processor 2004b, fourth generation (4G) baseband processor 2004c, and/or other baseband processor(s) 2004d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 2004 (e.g., one or more of baseband processors 2004a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 2006. In other embodiments, some or all of the functionality of baseband processors 2004a-d may be included in modules stored in the memory 2004g and executed via a Central Processing Unit (CPU) 2004e. 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 2004 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments,

encoding/decoding circuitry of the baseband circuitry 2004 may include convolution, tail- biting convolution, turbo, Viterbi, and/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.

[00124] In some embodiments, the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 2004f. The audio DSP(s) 2004f 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 2004 and the application circuitry 2002 may be implemented together such as, for example, on a system on a chip (SOC).

[00125] In some embodiments, the baseband circuitry 2004 may provide for

communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 2004 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/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 2004 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

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

[00127] In some embodiments, the RF circuitry 2006 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 2006 may include mixer circuitry 2006a, amplifier circuitry 2006b and filter circuitry 2006c. The transmit signal path of the RF circuitry 2006 may include filter circuitry 2006c and mixer circuitry 2006a. RF circuitry 2006 may also include synthesizer circuitry 2006d for synthesizing a frequency for use by the mixer circuitry 2006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 2006a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 2008 based on the synthesized frequency provided by synthesizer circuitry 2006d. The amplifier circuitry 2006b may be configured to amplify the down-converted signals and the filter circuitry 2006c 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 2004 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 2006a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

[00128] In some embodiments, the mixer circuitry 2006a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 2006d to generate RF output signals for the FEM circuitry 2008. The baseband signals may be provided by the baseband circuitry 2004 and may be filtered by filter circuitry 2006c. The filter circuitry 2006c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

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

[00130] 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 2006 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 2004 may include a digital baseband interface to communicate with the RF circuitry 2006.

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

[00132] In some embodiments, the synthesizer circuitry 2006d 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 2006d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

[00133] The synthesizer circuitry 2006d may be configured to synthesize an output frequency for use by the mixer circuitry 2006a of the RF circuitry 2006 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 2006d may be a fractional N/N+l synthesizer. [00134] 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 2004 or the applications processor 2002 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 2002.

[00135] Synthesizer circuitry 2006d of the RF circuitry 2006 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 (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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

[00137] FEM circuitry 2008 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 2010, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 2006 for further processing. FEM circuitry 2008 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 2006 for transmission by one or more of the one or more antennas 2010. [00138] In some embodiments, the FEM circuitry 2008 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 a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry

2006). The transmit signal path of the FEM circuitry 2008 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 2006), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 2010.

[00139] In some embodiments, the device 2000 comprises a plurality of power saving mechanisms. If the device 2000 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 may power down for brief intervals of time and thus save power.

[00140] If there is no data traffic activity for an extended period of time, then the device 2000 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 2000 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 cannot receive data in this state, in order to receive data, it must transition back to RRC Connected state.

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

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

[00143] FIG. 21 provides an example illustration of the wireless device, such as a user equipment (UE), a mobile station (MS), a mobile wireless device, a mobile

communication device, a tablet, a handset, or other type of wireless device. The wireless device can include one or more antennas configured to communicate with a node, macro node, low power node (LPN), or, transmission station, such as a base station (BS), an evolved Node B (eNB), a baseband processing unit (BBU), a remote radio head (RRH), a remote radio equipment (RRE), a relay station (RS), a radio equipment (RE), or other type of wireless wide area network (WWAN) access point. The wireless device can be configured to communicate using at least one wireless communication standard such as, but not limited to, 3 GPP LTE, WiMAX, High Speed Packet Access (HSPA), Bluetooth, and WiFi. The wireless device can communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless device can communicate in a wireless local area network

(WLAN), a wireless personal area network (WPAN), and/or a WWAN. The wireless device can also comprise a wireless modem. The wireless modem can comprise, for example, a wireless radio transceiver and baseband circuitry (e.g., a baseband processor). The wireless modem can, in one example, modulate signals that the wireless device transmits via the one or more antennas and demodulate signals that the wireless device receives via the one or more antennas.

[00144] FIG. 21 also provides an illustration of a microphone and one or more speakers that can be used for audio input and output from the wireless device. The display screen can be a liquid crystal display (LCD) screen, or other type of display screen such as an organic light emitting diode (OLED) display. The display screen can be configured as a touch screen. The touch screen can use capacitive, resistive, or another type of touch screen technology. An application processor and a graphics processor can be coupled to internal memory to provide processing and display capabilities. A non-volatile memory port can also be used to provide data input/output options to a user. The non-volatile memory port can also be used to expand the memory capabilities of the wireless device. A keyboard can be integrated with the wireless device or wirelessly connected to the wireless device to provide additional user input. A virtual keyboard can also be provided using the touch screen.

Examples

[00145] The following examples pertain to specific technology embodiments and point out specific features, elements, or actions that can be used or otherwise combined in achieving such embodiments.

[00146] Example 1 includes an apparatus of a User Equipment (UE) having a client connection manager (CCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack comprising: one or more processors configured to: decode, an initial (INIT) request (REQ) message received from a network connection manager (NCM); encode, for transmission to the NCM, an INIT response (RSP) message; and, encode, for transmission to the NCM, a reconfiguration request (REQ) message, wherein the reconfiguration REQ message includes: a connection identification (ID) to identify a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection; and, memory coupled to the one or more processors and configured to store the INIT REQ message received.

[00147] Example 2 includes the apparatus of the UE of example 1, wherein the INIT REQ message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; a connection type; an access and adaptation tunneling (AAT) support bit map; a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end-point internet protocol (IP) address; or, an AAT-specific configuration.

[00148] Example 3 includes the apparatus of the UE of example 1 or 2, wherein the INIT RSP message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; an access and adaptation tunneling (AAT) support bit map; or, a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery.

[00149] Example 4 includes the apparatus of the UE of example 1 or 2, wherein the reconfiguration action request of setup, in a CCM reconfiguration REQ message, includes an IP address of a connection or a maximum transmission unit (MTU) size of the connection.

[00150] Example 5 includes the apparatus of the UE of example 1 or 2, wherein the NCM sends a reconfiguration RSP message, wherein the reconfiguration RSP message includes: a connection identification (ID) to identify a secondary connection for reconfiguration; and, a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

[00151] Example 6 includes the apparatus of the UE of example 1 or 2, wherein the reconfiguration action request of the setup, in a NCM reconfiguration RSP message, includes one or more of: a downlink (DL) GMA trailer format bitmap, wherein each bit in the DL GMA trailer indicates if a corresponding trailer field is enabled or disabled for DL; an uplink (UL) GMA trailer format bitmap, wherein each bit in the UL GMA trailer indicates that a corresponding trailer field is enabled or disabled for uplink; or, a maximum GMA protocol data unit (PDU) payload size, wherein the GMA PDU indicates the maximum payload size of a GMA encapsulated PDU.

[00152] Example 7 includes the apparatus of the UE of example 1 or 2, wherein the NCM sends a probe REQ message, wherein the probe REQ message includes a connection ID to indicate a corresponding connection for the probe REQ message to be delivered.

[00153] Example 8 includes the apparatus of the UE of example 1, wherein the CCM is configured to encode a probe RSP message, wherein the probe RSP message includes a connection ID to indicate a round trip calculation of a connection, and to indicate when to switch data traffic over to the connection.

[00154] Example 9 includes the apparatus of the UE of example 1, wherein the NCM sends a switching REQ message to steer data traffic of an anchor connection, or a plurality of anchor connections simultaneously.

[00155] Example 10 includes the apparatus of the UE of example 1, wherein the CCM sends a switching RSP message to confirm a traffic steering operation.

[00156] Example 11 includes the apparatus of the UE of example 9, wherein the switching REQ message includes one or more of: a connection ID of the anchor connection; a connection ID of a downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing a corresponding primary or a secondary connection is used to deliver DL traffic; a connection ID of an uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a corresponding primary or a secondary connection that is used to deliver UL traffic; a UL reordering indicator, wherein the UL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a DL reordering indicator, wherein the DL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a UL last received Sequence Number, which indicates a last received UL packet for lossless switching.

[00157] Example 12 includes the apparatus of the UE of example 9, further comprising a switching RSP message that includes one or more of: a connection ID of the anchor connection; or, a DL last received Sequence Number (SN), which indicates a last received DL packet for lossless switching.

[00158] Example 13 includes the apparatus of the UE of example 1 or 12, wherein the CCM sends a switching ACK message to confirm a successful reception of the switching RSP.

[00159] Example 14 includes an apparatus of a node having a network connection manager (NCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack comprising: one or more processors configured to: encode, for transmission to a client connection manager (CCM) an initial (INIT) request (REQ) message; decode, an INIT response (RSP) message received from the CCM; and, decode, a reconfiguration request (REQ) message received from the CCM, wherein the reconfiguration REQ message includes: a connection identification (ID) to identify a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request from one or more of a setup or a release of a secondary connection; and, memory coupled to the one or more processors and configured to store the

reconfiguration REQ message received.

[00160] Example 15 includes the apparatus of the node of example 14, wherein the INIT REQ message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; a connection type; an access and adaptation tunneling (AAT) support bit map; a connection function to indicate a role of a connection on a u- plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end- point internet protocol (IP) address; or, an AAT-specific configuration.

[00161] Example 16 includes the apparatus of the node of example 14 or 15, wherein the INIT RSP message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; an access and adaptation tunneling (AAT) support bit map; or, a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery.

[00162] Example 17 includes the apparatus of the node of example 14 or 15, wherein the node is one or more of: an evolved node B (eNB), a g node B (gNB), a serving gateway (S-GW), or a packet data network (PDN) gateway (P-GW).

[00163] Example 18 includes an apparatus of a User Equipment (UE) configured for Generic Routing Encapsulation (GRE) based tunneling for uplink (UL) and downlink (DL) communications in an LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) operation, comprising: one or more processors configured to: encode, for transmission to an evolved node B (eNB) a wireless local area network (WLAN) connection status report to confirm a WLAN association; decode a radio resource control (RRC) connection reconfiguration message received from the eNB, wherein the RRC connection reconfiguration message comprises: configuration parameters for an Internet Protocol Security (IPSec) transport mode; configuration parameters for GRE tunneling; and, encode an RRC connection reconfiguration complete message for transmission to the eNB to establish a bidirectional GRE tunnel between the UE and the eNB for the UL and the DL over the WLAN and protect the bidirectional GRE tunnel with the IPSec transport mode; and, memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

[00164] Example 19 includes the apparatus of the UE of example 18 wherein the one or more processors are further configured to configure one or more data radio bearers (DRB) to use the GRE tunnel.

[00165] Example 20 includes an apparatus of a User Equipment (UE) configured to perform control plane based LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) uplink (UL) data radio bearer (DRB) switching, comprising: one or more processors configured to: decode a radio resource control (RRC) connection

reconfiguration message received from an evolved Node B (eNB), wherein the RRC connection reconfiguration message comprises information for the UE to switch from a first DRB operating over an internet protocol security (IPSec) tunnel to a second DRB operating over the IPSec tunnel; identify a DRB switching timer value in the RRC connection re-configuration message, wherein the DRB switching timer value provides a minimal interval for the UE between receiving the RRC Connection Reconfiguration message and sending UL packets of the second DRB over the IPSec tunnel; encode the UL packets to send over the IPSec tunnel via the second DRB after the DRB switching timer value to enable the eNB to identify which DRB a received UL packet belongs to; and, memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

[00166] Example 21 includes the apparatus of the UE of example 20, wherein the one or more processors are further configured to: move the first DRB from the IPSec tunnel to a 3 GPP link with the eNB.

[00167] Example 22 includes the apparatus of the UE of example 20, wherein the one or more processors are further configured to: encode, for transmission to the eNB, and RRC connection reconfiguration complete message.

[00168] Example 23 includes an apparatus of a User Equipment (UE) configured to provide a data radio bearer (DRB) indication with internet protocol security (IPSec) tunneling, comprising memory; and one or more processors configured to: modify predetermined bits, in an LTE WLAN Radio Level Integration with IPsec Tunnel Encapsulation Protocol (LWIPEP) service data unit (SDU) of a selected internet protocol (IP) header field to carry a DRB identification (ID); construct an LWIPEP protocol data unit (PDU) from the LWIPEP SDU; and, encode the LWIPEP PDU containing the DRB ID for transmission to a evolved node B (eNB) to enable the eNB to associate data packets with a selected DRB based on the DRB ID. [00169] Example 24 includes the apparatus of the UE of example 23, wherein the one or more processors are configured to decode a radio resource control (RRC) message from the eNB indicating which field of the selected IP header is used to carry the DRB ID.

[00170] Example 25 includes the apparatus of the UE of example 24, wherein the field of the selected IP header is one or more of a Time to Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a Type of Service (ToS) field.

[00171] Example 26 includes the apparatus of the UE of example 23 or 24, wherein the one or more processors are further configured to indicate an original value of the modified bits of the selected IP header in an RRC configuration complete message to enable the eNB to restore the modified bits to the original value.

[00172] Example 27 includes the apparatus of the UE of example 23, wherein an end of the LWIPEP SDU comprises an LWIP trailer comprising: a DRB ID; a Sequence Number; an IP Header Checksum; and, a Next Header.

[00173] Example 28 includes a generic multi-access (GMA) user-plane (U-plane) protocol stack comprising: an internet protocol (IP) layer; a GMA convergence layer, located below the IP layer, wherein the GMA convergence layer is configured to encapsulate and decapsulate user data traffic and support GMA convergence functions; a GMA adaptation layer configured to transport multiple access encapsulated packets over a selected link; and, a link access layer located below the GMA adaptation layer.

[00174] Example 29 includes the GMA U-plane protocol stack of example 28 wherein, the GMA convergence layer is configured to encapsulate and decapsulate data in a trailer- based GMA encapsulation protocol data unit (PDU) comprising: an IP header; an IP payload comprising one or more IP packets; and, a GMA trailer.

[00175] Example 30 includes the GMA U-plane protocol stack of example 29 wherein the GMA trailer includes additional control information comprising one or more of: a next header comprising an IP protocol type of an IP packet in the IP Payload of the GMA PDU; a connection identification (ID) comprising an anchor connection ID of the IP packet; a traffic class ID comprising one of a flow identification, a class identification, or a data radio bearer (DRB) identification; a sequence number comprising a transmission order of the IP packet; a packet length comprising a length of the IP packet or a length of a first IP packet included in a concatenation of IP packets; or, a fragmentation control comprising an indication where a fragmentation packet is located in the packet.

[00176] Example 31 includes the GMA U-plane protocol stack of example 29 wherein the IP header of the GMA PDU includes one or more of: a protocol type to indicate that the presence of a GMA trailer, the GMA convergence protocol is an "0-hop" protocol that is not subject to IP routing; an IP length comprising a length of the GMA trailer or a length of a concatenated IP packet; or, an IP checksum comprising a recalculation after changing the protocol type and the IP length.

[00177] Example 32 includes the GMA U-plane protocol stack of example 31 wherein the protocol type is a 114 protocol type.

[00178] Example 33 includes the GMA U-plane protocol stack of example 28 or 29 wherein the GMA adaptation layer is configured to transport the GMA encapsulated packets using one or more of: tunneling configured to send a GMA encapsulated IP packet as an inner IP packet in an additional outer IP packet using one or more of IP-in-IP tunneling, User Datagram Protocol (UDP) tunneling, or IP Security (IPSec) tunneling; client net access translation (NAT) configured to change a client IP address of the GMA encapsulated IP packet; or keep the GMA encapsulated packets unchanged.

[00179] Example 34 includes the GMA U-plane protocol stack of example 28 or 29 further comprising: an anchor access IP layer (Layer 3) configured to interface with a transport layer and the GMA convergence layer (Layer 2.5); and, an anchor/delivery access link layer (Layer 2) configured to deliver data traffic of an anchor IP connection and interface with a physical layer (Layer 2) and the GMA adaptation layer (Layer 2.5).

[00180] Example 35 includes the GMA U-plane protocol stack of example 28, wherein the U-plane protocol stack is configured to carry IP data of a client device to one or more core IP networks via multiple access networks.

[00181] Example 36 includes the GMA U-plane protocol stack of example 35, wherein the multiple access networks comprise an anchor access network and a plurality of delivery access networks.

[00182] Example 37 includes an apparatus of a User Equipment (UE) having a client connection manager (CCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack comprising: one or more processors configured to: decode, an initial (INIT) request (REQ) message received from a network connection manager (NCM); encode, for transmission to the NCM, an INIT response (RSP) message; and, encode, for transmission to the NCM, a reconfiguration request (REQ) message, wherein the reconfiguration REQ message includes: a connection identification (ID) to identify a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection; and, memory coupled to the one or more processors and configured to store the INIT REQ message received.

[00183] Example 38 includes the apparatus of the UE of example 37, wherein the INIT REQ message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; a connection type; an access and adaptation tunneling (AAT) support bit map; a connection function to indicate a role of a connection on a u- plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end- point internet protocol (IP) address; or, an AAT-specific configuration.

[00184] Example 39 includes the apparatus of the UE of example 37 or 38, wherein the INIT RSP message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections; an access and adaptation tunneling (AAT) support bit map; or, a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery.

[00185] Example 40 includes the apparatus of the UE of example 37 or 38 wherein the reconfiguration action request of setup, in a CCM reconfiguration REQ message, includes an IP address of a connection or a maximum transmission unit (MTU) size of the connection.

[00186] Example 41 includes the apparatus of the UE of example 37 or 38, wherein the NCM sends a reconfiguration RSP message, wherein the reconfiguration RSP message includes: a connection identification (ID) to identify a secondary connection for reconfiguration; and, a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

[00187] Example 42 includes the apparatus of the UE of example 37 or 38, wherein the reconfiguration action request of the setup, in a NCM reconfiguration RSP message, includes one or more of: a downlink (DL) GMA trailer format bitmap, wherein each bit in the DL GMA trailer indicates if a corresponding trailer field is enabled or disabled for DL; an uplink (UL) GMA trailer format bitmap, wherein each bit in the UL GMA trailer indicates that a corresponding trailer field is enabled or disabled for uplink; or, a maximum GMA protocol data unit (PDU) payload size, wherein the GMA PDU indicates the maximum payload size of a GMA encapsulated PDU.

[00188] Example 43 includes the apparatus of the UE of example 37 or 38, wherein the NCM sends a probe REQ message, wherein the probe REQ message includes a connection ID to indicate a corresponding connection for the probe REQ message to be delivered, and the NCM sends a switching REQ message to steer data traffic of an anchor connection, or a plurality of anchor connections simultaneously.

[00189] Example 44 includes the apparatus of the UE of example 37, wherein the CCM is configured to: encode a probe RSP message, wherein the probe RSP message includes a connection ID to indicate a round trip calculation of a connection, and to indicate when to switch data traffic over to the connection; send a switching RSP message to confirm a traffic steering operation; and, send a switching ACK message to confirm a successful reception of the switching RSP.

[00190] Example 45 includes the apparatus of the UE of example 44, wherein the switching REQ message includes one or more of: a connection ID of the anchor connection; a connection ID of a downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing a corresponding primary or a secondary connection is used to deliver DL traffic; a connection ID of an uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a corresponding primary or a secondary connection that is used to deliver UL traffic; a UL reordering indicator, wherein the UL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a DL reordering indicator, wherein the DL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a UL last received Sequence Number, which indicates a last received UL packet for lossless switching.

[00191] Example 46 includes an apparatus of a User Equipment (UE) configured to perform control plane based LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) uplink (UL) data radio bearer (DRB) switching, comprising: one or more processors configured to: decode a radio resource control (RRC) connection

[00192] Example 47 includes the apparatus of the UE of example 46, wherein the one or more processors are further configured to: move the first DRB from the IPSec tunnel to a 3GPP link with the eNB; and encode, for transmission to the eNB, and RRC connection reconfiguration complete message.

[00193] Example 48 includes an apparatus of a User Equipment (UE) configured to provide a data radio bearer (DRB) indication with internet protocol security (IPSec) tunneling, comprising memory; and one or more processors configured to: modify predetermined bits, in an LTE WLAN Radio Level Integration with IPsec Tunnel Encapsulation Protocol (LWIPEP) service data unit (SDU) of a selected internet protocol (IP) header field to carry a DRB identification (ID); construct an LWIPEP protocol data unit (PDU) from the LWIPEP SDU; and, encode the LWIPEP PDU containing the DRB ID for transmission to a evolved node B (eNB) to enable the eNB to associate data packets with a selected DRB based on the DRB ID.

[00194] Example 49 includes the apparatus of the UE of example 48, wherein the one or more processors are configured to decode a radio resource control (RRC) message from the eNB indicating which field of the selected IP header is used to carry the DRB ID, wherein the field of the selected IP header is one or more of a Time to Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a Type of Service (ToS) field. [00195] Example 50 includes the apparatus of the UE of example 48 or 49, wherein the one or more processors are further configured to indicate an original value of the modified bits of the selected IP header in an RRC configuration complete message to enable the eNB to restore the modified bits to the original value.

[00196] Example 51 includes the apparatus of the UE of example 48, wherein an end of the LWIPEP SDU comprises an LWIP trailer comprising: a DRB ID; a Sequence

Number; an IP Header Checksum; and, a Next Header.

[00197] Various techniques, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media, such as floppy diskettes, compact disc-read-only memory (CD-ROMs), hard drives, non-transitory computer readable storage medium, or any other machine-readable storage medium wherein, when the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the various techniques. In the case of program code execution on programmable computers, the computing device may include a processor, a storage medium readable by the processor (including volatile and nonvolatile memory and/or storage elements), at least one input device, and at least one output device. The volatile and non-volatile memory and/or storage elements may be a random-access memory (RAM), erasable programmable read only memory (EPROM), flash drive, optical drive, magnetic hard drive, solid state drive, or other medium for storing electronic data. The node and wireless device may also include a transceiver module (i.e., transceiver), a counter module (i.e., counter), a processing module (i.e., processor), and/or a clock module (i.e., clock) or timer module (i.e., timer). In one example, selected components of the transceiver module can be located in a cloud radio access network (C-RAN). One or more programs that may implement or utilize the various techniques described herein may use an application programming interface (API), reusable controls, and the like. Such programs may be implemented in a high level procedural or object oriented programming language to communicate with a computer system. However, the program(s) may be implemented in assembly or machine language, if desired. In any case, the language may be a compiled or interpreted language, and combined with hardware implementations.

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

[00199] It should be understood that many of the functional units described in this specification have been labeled as modules, in order to more particularly emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices or the like.

[00200] Modules may also be implemented in software for execution by various types of processors. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified module may not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

[00201] Indeed, a module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices. Similarly, operational data may be identified and illustrated herein within modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The modules may be passive or active, including agents operable to perform desired functions.

[00202] Reference throughout this specification to "an example" or "exemplary" means that a particular feature, structure, or characteristic described in connection with the example is included in at least one embodiment of the present technology. Thus, appearances of the phrases "in an example" or the word "exemplary" in various places throughout this specification are not necessarily all referring to the same embodiment.

[00203] As used herein, a plurality of items, structural elements, compositional elements, and/or materials may be presented in a common list for convenience. However, these lists should be construed as though each member of the list is individually identified as a separate and unique member. Thus, no individual member of such list should be construed as a de facto equivalent of any other member of the same list solely based on their presentation in a common group without indications to the contrary. In addition, various embodiments and example of the present technology may be referred to herein along with alternatives for the various components thereof. It is understood that such embodiments, examples, and alternatives are not to be construed as defacto equivalents of one another, but are to be considered as separate and autonomous representations of the present technology.

[00204] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided, such as examples of layouts, distances, network examples, etc., to provide a thorough understanding of embodiments of the technology. One skilled in the relevant art will recognize, however, that the technology can be practiced without one or more of the specific details, or with other methods, components, layouts, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the technology.

While the forgoing examples are illustrative of the principles of the present technology in one or more particular applications, it will be apparent to those of ordinary skill in the art that numerous modifications in form, usage and details of implementation can be made without the exercise of inventive faculty, and without departing from the principles and concepts of the technology. Accordingly, it is not intended that the technology be limited, except as by the claims set forth below.

Claims

What is claimed is:

1. An apparatus of a User Equipment (UE) having a client connection manager (CCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack comprising:

one or more processors configured to:

decode, an initial (INIT) request (REQ) message received from a network connection manager (NCM);

encode, for transmission to the NCM, an INIT response (RSP) message; and,

encode, for transmission to the NCM, a reconfiguration request (REQ) message, wherein the reconfiguration REQ message includes:

a connection identification (ID) to identify a connection for reconfiguration;

a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection; and, memory coupled to the one or more processors and configured to store the INIT REQ message received.

2. The apparatus of the UE of claim 1, wherein the INIT REQ message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections;

a connection type;

an access and adaptation tunnelling (AAT) support bit map;

a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end-point internet protocol (IP) address; or, an AAT-specific configuration. The apparatus of the UE of claim 1 or 2, wherein the INIT RSP message includes one or more of:

a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections;

an access and adaptation tunnelling (AAT) support bit map; or, a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery.

The apparatus of the UE of claim 1 or 2, wherein the reconfiguration action request of setup, in a CCM reconfiguration REQ message, includes an IP address of a connection or a maximum transmission unit (MTU) size of the connection.

The apparatus of the UE of claim 1 or 2, wherein the NCM sends a

reconfiguration RSP message, wherein the reconfiguration RSP message includes:

a connection identification (ID) to identify a secondary connection for reconfiguration; and,

a reconfiguration action to indicate which reconfiguration action to request one or more of a setup or a release of a secondary connection.

The apparatus of the UE of claim 1 or 2, wherein the reconfiguration action request of the setup, in a NCM reconfiguration RSP message, includes one or more of:

a downlink (DL) GMA trailer format bitmap, wherein each bit in the DL GMA trailer indicates if a corresponding trailer field is enabled or disabled for DL;

an uplink (UL) GMA trailer format bitmap, wherein each bit in the UL GMA trailer indicates that a corresponding trailer field is enabled or disabled for uplink; or,

a maximum GMA protocol data unit (PDU) payload size, wherein the GMA PDU indicates the maximum payload size of a GMA encapsulated PDU.

7. The apparatus of the UE of claim 1 or 2, wherein the NCM sends a probe REQ message, wherein the probe REQ message includes a connection ID to indicate a corresponding connection for the probe REQ message to be delivered.

8. The apparatus of the UE of claim 1, wherein the CCM is configured to encode a probe RSP message, wherein the probe RSP message includes a connection ID to indicate a round trip calculation of a connection, and to indicate when to switch data traffic over to the connection.

9. The apparatus of the UE of claim 1, wherein the NCM sends a switching REQ message to steer data traffic of an anchor connection, or a plurality of anchor connections simultaneously.

10. The apparatus of the UE of claim 1, wherein the CCM sends a switching RSP message to confirm a traffic steering operation.

11. The apparatus of the UE of claim 9, wherein the switching REQ message includes one or more of:

a connection ID of the anchor connection;

a connection ID of a downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing a corresponding primary or a secondary connection is used to deliver DL traffic;

a connection ID of an uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a corresponding primary or a secondary connection that is used to deliver UL traffic;

a UL reordering indicator, wherein the UL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a DL reordering indicator, wherein the DL reordering indicator is a bit field that indicates whether reordering is enabled or disabled; or, a UL last received Sequence Number, which indicates a last received UL packet for lossless switching.

12. The apparatus of the UE of claim 9, further comprising a switching RSP message that includes one or more of:

a connection ID of the anchor connection; or,

a DL last received Sequence Number (SN), which indicates a last received DL packet for lossless switching. 13. The apparatus of the UE of claim 1 or 12, wherein the CCM sends a switching

ACK message to confirm a successful reception of the switching RSP.

14. An apparatus of a node having a network connection manager (NCM) configured to communicate over a generic multi-access (GMA) control plane protocol stack comprising:

one or more processors configured to:

encode, for transmission to a client connection manager (CCM) an initial (INIT) request (REQ) message;

decode, an INIT response (RSP) message received from the CCM; and,

decode, a reconfiguration request (REQ) message received from the CCM, wherein the reconfiguration REQ message includes:

a connection identification (ID) to identify a connection for reconfiguration;

a reconfiguration action to indicate which reconfiguration action to request from one or more of a setup or a release of a secondary connection; and,

memory coupled to the one or more processors and configured to store the reconfiguration REQ message received.

15. The apparatus of the node of claim 14, wherein the INIT REQ message includes one or more of: a capability bitmap, wherein each bit in the capability bitmap indicates when a corresponding capability is supported by the NCM; a number of secondary connections;

a connection type;

an access and adaptation tunnelling (AAT) support bit map;

a connection function to indicate a role of a connection on a u-plane as one of a delivery only, an anchor only, or the anchor or the delivery; an AAT end-point internet protocol (IP) address; or, an AAT-specific configuration.

16. The apparatus of the node of claim 14 or 15, wherein the INIT RSP message includes one or more of:

17. The apparatus of the node of claim 14 or 15, wherein the node is one or more of: an evolved node B (eNB), a g node B (gNB), a serving gateway (S-GW), or a packet data network (PDN) gateway (P-GW).

18. An apparatus of a User Equipment (UE) configured for Generic Routing

Encapsulation (GRE) based tunnelling for uplink (UL) and downlink (DL) communications in an LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) operation, comprising:

one or more processors configured to:

encode, for transmission to an evolved node B (eNB) a wireless local area network (WLAN) connection status report to confirm a WLAN association; decode a radio resource control (RRC) connection reconfiguration message received from the eNB, wherein the RRC connection reconfiguration message comprises:

configuration parameters for an Internet Protocol Security (IPSec) transport mode;

configuration parameters for GRE tunnelling; and, encode an RRC connection reconfiguration complete message for transmission to the eNB to establish a bidirectional GRE tunnel between the UE and the eNB for the UL and the DL over the WLAN and protect the bidirectional GRE tunnel with the IPSec transport mode; and,

memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message. 19. The apparatus of the UE of claim 18 wherein the one or more processors are further configured to configure one or more data radio bearers (DRB) to use the GRE tunnel.

20. An apparatus of a User Equipment (UE) configured to perform control plane based LTE WLAN Radio Level Integration with IPsec Tunnel (LWIP) uplink (UL) data radio bearer (DRB) switching, comprising:

one or more processors configured to:

decode a radio resource control (RRC) connection

reconfiguration message received from an evolved Node B (eNB), wherein the RRC connection reconfiguration message comprises information for the UE to switch from a first DRB operating over an internet protocol security (IPSec) tunnel to a second DRB operating over the IPSec tunnel;

identify a DRB switching timer value in the RRC connection reconfiguration message, wherein the DRB switching timer value provides a minimal interval for the UE between receiving the RRC Connection Reconfiguration message and sending UL packets of the second DRB over the IPSec tunnel;

encode the UL packets to send over the IPSec tunnel via the second DRB after the DRB switching timer value to enable the eNB to identify which DRB a received UL packet belongs to; and, memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

21. The apparatus of the UE of claim 20, wherein the one or more processors are further configured to:

move the first DRB from the IPSec tunnel to a 3 GPP link with the eNB.

22. The apparatus of the UE of claim 20, wherein the one or more processors

further configured to:

encode, for transmission to the eNB, and RRC connection reconfiguration complete message.

23. An apparatus of a User Equipment (UE) configured to provide a data radio bearer (DRB) indication with internet protocol security (IPSec) tunnelling, comprising memory; and one or more processors configured to:

modify predetermined bits, in an LTE WLAN Radio Level Integration with IPsec Tunnel Encapsulation Protocol (LWIPEP) service data unit (SDU) of a selected internet protocol (IP) header field to carry a DRB identification (ID);

construct an LWIPEP protocol data unit (PDU) from the LWIPEP SDU; and,

encode the LWIPEP PDU containing the DRB ID for transmission to a evolved node B (eNB) to enable the eNB to associate data packets with a selected DRB based on the DRB ID.

24. The apparatus of the UE of claim 23, wherein the one or more processors are configured to decode a radio resource control (RRC) message from the eNB indicating which field of the selected IP header is used to carry the DRB ID.

25. The apparatus of the UE of claim 24, wherein the field of the selected IP header is one or more of a Time to Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a Type of Service (ToS) field.

26. The apparatus of the UE of claim 23 or 24, wherein the one or more processors are further configured to indicate an original value of the modified bits of the selected IP header in an RRC configuration complete message to enable the eNB to restore the modified bits to the original value.

27. The apparatus of the UE of claim 23, wherein an end of the LWIPEP SDU

comprises an LWIP trailer comprising:

a DRB ID;

a Sequence Number;

an IP Header Checksum; and,

a Next Header.

28. A generic multi-access (GMA) user-plane (U-plane) protocol stack comprising:

an internet protocol (IP) layer;

a GMA convergence layer, located below the IP layer, wherein the GMA convergence layer is configured to encapsulate and decapsulate user data traffic and support GMA convergence functions;

a GMA adaptation layer configured to transport multiple access encapsulated packets over a selected link; and,

a link access layer located below the GMA adaptation layer.

29. The GMA U-plane protocol stack of claim 28 wherein, the GMA convergence layer is configured to encapsulate and decapsulate data in a trailer-based GMA encapsulation protocol data unit (PDU) comprising: an IP header;

an IP payload comprising one or more IP packets; and, a GMA trailer.

30. The GMA U-plane protocol stack of claim 29 wherein the GMA trailer includes additional control information comprising one or more of:

a next header comprising an IP protocol type of an IP packet in the IP Payload of the GMA PDU;

a connection identification (ID) comprising an anchor connection ID of the IP packet;

a traffic class ID comprising one of a flow identification, a class identification, or a data radio bearer (DRB) identification;

a sequence number comprising a transmission order of the IP packet; a packet length comprising a length of the IP packet or a length of a first IP packet included in a concatenation of IP packets; or,

a fragmentation control comprising an indication where a fragmentation packet is located in the packet.

31. The GMA U-plane protocol stack of claim 29 wherein the IP header of the GMA PDU includes one or more of:

a protocol type to indicate that the presence of a GMA trailer, the GMA convergence protocol is an "0-hop" protocol that is not subject to IP routing;

an IP length comprising a length of the GMA trailer or a length of a concatenated IP packet; or,

an IP checksum comprising a recalculation after changing the protocol type and the IP length.

32. The GMA U-plane protocol stack of claim 31 wherein the protocol type i

protocol type.

33. The GMA U-plane protocol stack of claim 28 or 29 wherein the GMA adaptation layer is configured to transport the GMA encapsulated packets using one or more of:

tunnelling configured to send a GMA encapsulated IP packet as an inner IP packet in an additional outer IP packet using one or more of IP-in- IP tunnelling, User Datagram Protocol (UDP) tunnelling, or IP Security (IPSec) tunnelling;

client net access translation (NAT) configured to change a client IP address of the GMA encapsulated IP packet; or

keep the GMA encapsulated packets unchanged.

34. The GMA U-plane protocol stack of claim 28 or 29 further comprising:

an anchor access IP layer (Layer 3) configured to interface with a transport layer and the GMA convergence layer (Layer 2.5); and, an anchor/delivery access link layer (Layer 2) configured to deliver data traffic of an anchor IP connection and interface with a physical layer (Layer 2) and the GMA adaptation layer (Layer 2.5).

35. The GMA U-plane protocol stack of claim 28, wherein the U-plane protocol stack is configured to carry IP data of a client device to one or more core IP networks via multiple access networks.

36. The GMA U-plane protocol stack of claim 35, wherein the multiple access

networks comprise an anchor access network and a plurality of delivery access networks.