CN108886723B - Universal multiple access protocol for next generation multiple access networks - Google Patents

Abstract

Techniques are disclosed for a User Equipment (UE) operable to support a Client Connection Manager (CCM) to communicate over a universal multiple access (GMA) control plane protocol and to support a client multiple access data broker (C-MADP) to communicate over a Generic Multiple Access (GMA) user plane protocol. The UE may decode an initial (INIT) Request (REQ) message received from a Network Connection Manager (NCM) for capability exchange and initial configuration. The UE may encode an INIT Response (RSP) message for transmission to the NCM. The UE may encode a reconfiguration Request (REQ) message for transmission to the NCM, wherein the reconfiguration message includes: a connection Identification (ID) for identifying a connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

Description

Universal multiple access protocol for next generation multiple access networks

Background

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 the Downlink (DL) transmission and single carrier frequency division multiple access (SC-FDMA) in the Uplink (UL). Standards and protocols for signal transmission using Orthogonal Frequency Division Multiplexing (OFDM) include the third generation partnership project (3GPP) Long Term Evolution (LTE), the Institute of Electrical and Electronics Engineers (IEEE)802.16 standards (e.g., 802.16e, 802.16m), commonly referred to in the industry as Worldwide Interoperability for Microwave Access (WiMAX), and the IEEE 802.11 standard, commonly referred to in the industry as WiFi.

In 3GPP Radio Access Network (RAN) LTE systems (e.g., release 13 and earlier), the node may be a combination of an evolved universal terrestrial radio access network (E-UTRAN) node B (also commonly denoted as evolved node B, enhanced node B, eNodeB, or eNB) or a 5G new radio gbb (next generation node B) that communicates with a wireless device known as User Equipment (UE). Downlink (DL) transmissions may be communications from a node (e.g., eNodeB, gNB) to a wireless device (e.g., UE), and Uplink (UL) transmissions may be communications from the wireless device to the node.

Drawings

The features and advantages of the present disclosure will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the features of the disclosure; and wherein:

fig. 1 illustrates a protocol architecture for LTE WLAN radio level integration (LWIP) with internet protocol security (IPsec) tunnel for 3GPP R13 according to an example;

fig. 2 illustrates a protocol architecture for LTE WLAN radio level integration (LWIP) with IPsec tunnel for 3GPP R13 according to an example;

FIG. 3 depicts a proposed Generalized Multiple Access (GMA) U-plane protocol stack according to an example;

fig. 4A depicts a trailer-based multiple access encapsulation Protocol Data Unit (PDU) format according to an example;

FIG. 4B depicts a general multiple access including a series of fields, according to an example;

fig. 5 depicts a universal multiple access control plane protocol stack (C-plane) according to an example;

figure 6 illustrates an example control flow of a GMA control protocol process according to an example, depicting a flexible series of operations that enable any access network to be used;

figure 7 illustrates an example control flow of a GMA control protocol process according to an example, depicting a flexible series of operations that enable any access network to be used;

FIG. 8 illustrates an example GMA control message format according to an example;

fig. 9 depicts a universal multiple access user plane protocol stack (U-plane) according to an example;

fig. 10 illustrates a tail-based multiple access encapsulation packet format according to an example;

FIG. 11 illustrates LWIP DL and UL packet formats, according to an example;

FIG. 12 depicts an LWIP tunnel setup process flow, according to an example;

fig. 13 illustrates a LWIP Encapsulation Protocol (EP) sublayer model for the Downlink (DL) according to an example;

fig. 14 depicts a LWIP Uplink (UL) Data Radio Bearer (DRB) handover procedure, according to an example;

fig. 15 illustrates an LWIP Encapsulation Protocol (EP) data Protocol Data Unit (PDU) with an LWIP tail, according to an example;

fig. 16 depicts functionality of an apparatus of a UE configured to communicate over a General Multiple Access (GMA) control plane protocol stack, according to an example;

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, according to an example;

fig. 18 depicts functionality of an apparatus of a UE configured to perform a control plane based LTE WLAN radio level integration with IPsec tunnel (LWIP) Uplink (UL) Data Radio Bearer (DRB) handover, according to an example;

fig. 19 depicts functionality of an apparatus of a UE configured to provide Data Radio Bearer (DRB) indication with internet protocol security (IPSec) tunneling according to an example;

fig. 20 illustrates an example interface of a baseband circuit according to an example; and

fig. 21 shows a diagram of a wireless device (e.g., UE) according to an example.

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

Before the present technology is disclosed and described, it is to be understood that the technology is not limited to the particular structures, process acts, or materials disclosed herein, but extends to equivalents thereof as will be recognized by those of ordinary skill in the relevant art. It is also to be understood that the terminology employed herein is for the purpose of describing particular examples only and is not intended to be limiting. Like reference symbols in the various drawings indicate like elements. The numerals provided in the flowcharts and processes are provided for clarity of explanation of the acts and operations and do not necessarily indicate a particular order or sequence.

Example embodiments

An initial overview of technical embodiments is provided below, followed by a further detailed description of specific technical embodiments below. This preliminary summary is intended to aid the reader in understanding the present technology more quickly, but is not intended to identify key features or essential features of the present technology, nor is it intended to limit the scope of the claimed subject matter.

The Internet Engineering Task Force (IETF) has initiated new standardization efforts to support "multiple access management services" (MAMS), which has many similarities to LTE Wireless Local Area Network (WLAN) integration (also known as LWIP) with internet protocol security (IPsec) tunneling by 3GPP R13. The 3GPP LWIP can be seen as an example of the MAMS framework. The main difference between the two is that RRC messages support the transmission of control signaling in 3GPP LWIP. While the control signaling in MAMS is carried on top of user plane packets, e.g., User Datagram Protocol (UDP) or Transmission Control Protocol (TCP). In terms of similarity, the Client Connection Manager (CCM) in the Multiple Access Management Service (MAMS) is very similar to the Radio Resource Control (RRC) (c-plane) at the UE in LTE WLAN Integration (LWIP) with IPSec tunnel; the Network Connection Manager (NCM) is similar to the RRC entity at the evolved node b (enb); the network multiple access data proxy (N-MADP) is similar to the LWIPEP entity at the eNB. Furthermore, the MAMS solution can be used to support multi-radio access technology (multi-RAT) integration using any tunneling protocol, including UDP, TCP, GRE, IP-in-IP, IPSec, Ethernet, etc.

The proposed universal multiple access protocol for next generation multiple access networks includes many functional elements of the network reference architecture for MAMS. An example of one of the functional elements is a client. A client is an end-user device that supports connections (possibly through different access technologies) with multiple access nodes.

Another functional element is an access network element. An access network element is a functional element in the network that transmits user data packets to clients over point-to-point access links such as WiFi air links, LTE air links, DSL, and the like.

Another functional element is a core. A core is a functional element that anchors the IP address of a client for communicating with an application over a network.

Another functional element is a Network Connection Manager (NCM). The NCM is a functional entity in the client that exchanges MAMS signaling with the network connection manager and configures multiple network paths for transporting user data.

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 multiple network paths for transporting user data.

Another functional element is a network multiple access data proxy (N-MADP). N-MADP is a functional entity in a network that handles the forwarding of user data traffic across multiple network paths. The N-MADP is responsible for MAMS-specific u-plane functions in the network.

Another functional element is a client multiple access data proxy (C-MADP). The C-MADP is a functional entity in the client that handles user data traffic forwarding across multiple network paths. The C-MADP is responsible for the MAMS-specific u-plane functions in the client.

In one example, a multiple access convergence and encapsulation protocol layer may be introduced between the link layer and the IP layer on the user plane (u-plane). The multiple access aggregation and encapsulation protocol layer may be responsible for all multiple access related operations, such as aggregation, reordering, ordering, retransmission across RATs, bearer identification, fragmentation, concatenation (collocation), and the like.

In another example, an access adaptation and tunneling (tunneling) protocol layer may be introduced between the link layer and the IP layer on the u-plane. The access adaptation and tunneling protocol layer may be responsible for transporting Multiple Access (MA) encapsulated data traffic over a separate access (link) by additional tunneling (e.g., UDP tunneling, IPSec tunneling, GRE tunneling, etc.) or Network Address Translation (NAT), or without any change.

In another example, a new general-purpose multiple access (GMA) control protocol may be introduced. The new GMA control protocol may have the capability to manage various multiple access operations including discovery, capability negotiation, reconfiguration, traffic steering/aggregation, probing, etc.

In another example, embodiments of the present technology are not limited to LTE and Wi-Fi, and may be compatible between multiple different networks. For example, the plurality of networks include, but are not limited to, 3G, 4G LTE Rel.8-14, 5G, Wi-Fi, WiGig, and MultiFire.

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

In another example, the UE 120 may establish an LWIP tunnel 150 with the eNB 110 through the LWIP-SeGW 130 via the WLAN 140. IPSec can be used to protect UE (IP) traffic on the LWIP tunnel 150, is transparent to the WLAN 140, and does not change to existing WLAN 140 deployments.

In further examples, traffic steering (traffic steering) and multi-RAT Radio Resource Management (RRM) may occur at the top of the LTE RAN u-plane protocol stack (above the PDCP).

Fig. 2 provides an example illustration of an encapsulation protocol 200 for supporting LWIP with minimal overhead and additional new functionality (e.g., segmentation, concatenation, aggregation (bearer splitting), local access, and/or reliable handover).

In another example, the encapsulation protocol may include 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 LTE240, an LWIP trailer 250, an IPSec ESP trailer 260, and an IPSec ESP Auth trailer 270.

In another embodiment, the tail-based encapsulation protocol 200 approach may be extended to support a universal multiple access network, which may include any access technology (e.g., 3G, 4G LTE, 5G, Wi-Fi, WiGig, and MultiFire, etc.).

Fig. 3 depicts a proposed universal multiple access (GMA) user plane (U-plane) protocol stack 300. The GMA U plane protocol stack may include an application layer 310, a transmission control protocol/user datagram protocol (TCP/UDP) layer 320, anchor connection IP for layer 1(L1) and layer 2(L2) communications 330, a GMA convergence sublayer 340, a GMA adaptation sublayer 360, an anchor access layer 350, a transfer access IP layer 370, and a link layer 380.

In another example of GMA U-plane protocol stack 300, multiple access networks may be integrated into a single end-to-end (e2e) IP connection. An e2e IP connection that may be used to interface with a higher transport layer may be considered an anchor connection. Further, other associated IP connections that may be used to carry data traffic of the anchor IP connection may be considered to be a pass-through connection.

In another example, fig. 1 illustrates a 3GPP LTE release 13LWIP enabled network. The e2e application may be enabled to run using LTE IP addresses. In such an example, the LTE network may be an anchor connection and the Wi-Fi network may be a pass-through connection.

In another embodiment, the GMA u plane protocol of fig. 3 may include a GMA convergence sublayer and a GMA adaptation sublayer between the anchor access IP layer and the multiple access link layer. The GMA convergence sublayer may encapsulate and decapsulate user's data traffic (e.g., IP packets with additional control information (e.g., sequence numbers, DRB IDs, etc.) and support multiple access convergence functions, e.g., aggregation, splitting/reordering, fragmentation, concatenation, etc. In some scenarios, encapsulation may not be used, for example, when packets are sent over an anchor connection.

In another example, the GMA access and adaptation sublayer may be used for tunneling (AAT) and transport of MA encapsulated packets over a single access. Tunneling may be configured to send a GMA-encapsulated IP packet (inner) in another IP packet (outer) by IP-in-IP, UDP, or IPSec tunneling. Additionally, client Network Address Translation (NAT) may be configured to change the client IP address of the GMA encapsulated IP packet, which is then sent over the access network. Furthermore, GMA encapsulated IP packets may be sent directly using a no change or pass-through (pass-through) operation without any changes to the anchor connection. Furthermore, the AAT procedure may be configured differently according to individual accesses. For example, if the access network is considered "trusted," the client NAT or UDP may be used as a tunneling method; otherwise, if it is "untrusted," IPSec can be used as a tunneling method.

Fig. 4A depicts a tail-based multiple access encapsulation Protocol Data Unit (PDU) format 400, wherein the PDU format includes an IP header 410 and an IP payload 420. The IP payload 420 may include a fragment of an IP packet or multiple IP packets and a Generic Multiple Access (GMA) trailer 430.

In one embodiment, the GMA tail may include several (if not all) of the fields discussed in the preceding paragraphs and shown in one of several variations and sequences within fig. 4B. One example field is a next header 435, which may be 8 bits and includes the IP protocol type of the first (or only) IP packet contained in the PDU. Another example field may be a connection Identification (ID)440, which includes an unsigned integer to identify an anchor connection ID of the IP packet(s) contained in the PDU. Another example field may be a traffic class ID 445, where the traffic class ID may include a flow or class identification, such as a data radio bearer ID for a cellular connection. Another example field may be a sequence number 450, which may be 16 bits, including an auto-incrementing integer for the encapsulator to indicate the transmission order of the IP packets. Note that the sequence number may be counted separately for each traffic class of the anchor connection. This may be further used by the decapsulator to reorder the IP packets. All segments of an IP packet may use the same sequence number. Another example field may be packet length 455, which may be 2 bytes, including the first IP packet contained in the PDU. It is only included in a concatenated manner, i.e. one PDU includes a plurality of IP packets. Another example field may be a fragmentation control 460, which may be 2 bits, configured to indicate where the fragmented packet is in the original packet. For example, the indication of a segment grouping may indicate a first, middle, last, or no segment (e.g., 00: first; 01: middle; 10: last; 11: no segment). In another example, the fragmentation control field can include a bit (more fragments) flag to indicate whether a fragment in the PDU is the last fragment of an IP packet, and an offset field to specify the offset (in fragments) of a particular fragment from the beginning of the original unfragmented IP packet.

In another example, the IP header, packet of the original IP (version 4 or version 6) may include one or more of several fields that may be updated by the multiple access convergence protocol. One example field may be a protocol type, where "114" may be used to indicate that the multiple access convergence protocol is a "0-hop" protocol, not constrained by IP routing. It also indicates the presence of a GMA tail. Another example field of an IP header may be an IP length, where the IP length may be updated to add the length of the "multiple access trailer" and the length of any concatenated IP packets. Another example field of an IP header may be an IP checksum, where the IP checksum may be recalculated after changing the protocol type and IP length. Then, if UDP tunneling is used as the tunneling method, the IP header of the original IP packet may remain unchanged. Furthermore, if the PDU contains a plurality of IP packets, only the first IP packet is subjected to the above change.

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

In another embodiment, the GMA tail format may be dynamically negotiated. Further, the NCM may use a bitmap to send control messages to indicate which of the above-described fields should be included for each individual connection on the downlink and uplink, respectively.

Fig. 5 depicts a general multiple access control plane protocol stack (C-plane). GMA c plane protocol stack 500 may include each of the following layers: multiple access management control 510, UDP 520, primary access IP530, primary access link 1 and link 2(L1/L2)540, GMA adaptation sublayer 550, secondary access IP layer 560, and link access layer 570. Additional layers may also be included based on system settings.

In another embodiment, UDP or tcp (http) may be used to communicate the control messages. The IP connection used for the initial GMA setup is referred to herein as the "primary" and all other connections added by the GMA process are referred to as "secondary". The "connection ID ═ 0" may be reserved for the primary connection.

In another embodiment, as in 3GPP LTE release 13LWIP, LTE may always be designated as a primary connection in LWIP and Wi-Fi may be designated as a secondary connection. With respect to GMA protocol stack 500, the GMA protocol may be flexible such that any access network may be the primary connection. Thus, the GMA protocol stack is not limited to LTE connections as the primary connection.

Fig. 6 illustrates an example control flow of a GMA control protocol process, which depicts a flexible series of operations that make any access network available. The GMA control process flow 600 includes several operations.

In one embodiment, operation 1 may include a Client Connection Manager (CCM)610 periodically sending GMA discovery messages over a primary connection to a predefined destination IP address and UDP port. The GMA discovery message may include a version indication to indicate the version of the GMA controlled process.

In another embodiment, operation 2 may include a capability exchange in which the NCM 620 learns the IP address and port number of the primary connection from the GMA discovery message to communicate with the CCM 610 and issues an initial request (INIT-REQ) message. The INIT REQ message may include a capability bitmap per bit indicating whether the NCM/N-MADP 620 supports the corresponding capability. The bit indication may include the following: bit # 0: lossless switching; bit # 1: segmenting; bit # 2: cascading; bit # 3-5: multilink aggregation/reordering support. Furthermore, the multiple aggregation/reordering support may be the following: 0: no polymerization; 1: downlink (DL) aggregation with only transfer connections but no anchor connections; 2: uplink (UL) aggregation with anchor and transfer connections; 3: DL and UL aggregation with transfer connection only; 4: DL aggregation with anchor and transport connections; 5: UL aggregation with anchor and transfer connections; and DL and UL aggregation with anchor and transport connections.

In addition, there are many auxiliary connections that may be indicated in the INIT REQ message. For each secondary connection and primary connection, they may include a number of different indicators. One example of an indicator is a connection Identification (ID) that includes an indication of 0, 1, 2, etc., where 0 is always reserved for the primary connection. Another example of an indicator is a connection type, which may include: indicator 0 representing Wi-Fi; indicator 1 representing 5G; an indicator 2 representing a Multi-Fire; and indicator 3 representing LTE. Another example of an indicator is a multiple access tunneling and adaptation support bitmap, where each bit indicates whether the N-MADP supports the corresponding tunneling and adaptation method when the connection is used as a transit connection, e.g., bit # 0: UD; bit # 1: IPSec; bit # 2: NAT, (0: unsupported, 1: supported). Another example of an indicator is a connection function, where the connection function indicates the role of the connection on the u-plane (e.g., 0: anchor only; 1, pass only; 2, anchor or pass). Another example indicator is an AAT endpoint IPv4/v6 address, where the IPv4/v6 address is the IP address of the tunnel at N-MADP, where N-NADP is not used if NAT is used for AAT. Another example indicator is an AAT-specific configuration where the UDP port number of the tunnel is present at the N-MADP or within the IPSec pre-shared key.

In another embodiment, in response to NCM 620 sending the INIT-REQ message, CCM 610 may issue an initial response (INIT-RSP) message that includes a capability bitmap and a plurality of secondary connections, where each bit indicates whether CCM/C-MADP 610 supports the corresponding capability. For each secondary connection and primary connection, one or more indicators are included. An example of an indicator may be a connection ID, where the indication may be 0, 1, 2, etc., where 0 is reserved for the primary connection. Another example of an indicator may be a connection function, where the connection function indicates the role of the connection on the u-plane (e.g., 0: anchor only; 1, pass only; 2, anchor or pass). Another example of an indicator is an AAT support bitmap, where the AAT support bitmap is configured such that CCM 610 should only set one bit to "1," indicating that when a connection is used as a pass, the corresponding AAT method will be used, e.g., bit # 0: UDP; bit # 1: IPSec; bit # 3: NAT, and the like. In addition, the NCM may also support AAT methods, as indicated in the INIT-REQ message.

In another embodiment, operation 3 may include an operation of configuring when the link is an uplink or a downlink. CCM 610 may issue a reconfiguration Request (REQ) message to establish or release a secondary connection. The reconfiguration REQ message may include a reconfiguration action and a connection ID identifying the connection for reconfiguration, where the reconfiguration indicates which reconfiguration action (0: release; 1: establishment) is requested.

In the case where the indicated reconfiguration action is "setup," the reconfiguration REQ message may indicate the IP address of the connection, as well as the Maximum Transmission Unit (MTU) size of the connection.

In response, NCM 620 may issue a reconfiguration Response (RSP) message that includes a connection ID indicating the secondary connection to be reconfigured, and request 0: releasing; or 1: an established reconfiguration action. In the case where the reconfiguration is "setup", the indication of "setup" will have one or more of the following indicators. An example indicator may be a DL GMA tail format bitmap, where each bit indicates whether a corresponding tail field is enabled or disabled for the downlink. Another example indicator may be an UL GMA tail format bitmap, where each bit in the UL GMA tail format bitmap indicates whether a corresponding tail field is enabled or disabled for the uplink. Another example indicator may be a maximum GMA PDU size, where the maximum GMA PDU size indicates the maximum length of a GMA encapsulated PDU packet.

In another embodiment in fig. 7, operation 4 may include the NCM 720 configured to issue a probe REQ message carrying a connection ID to indicate over which respective connection the probe message should be delivered. In response CCM 710 issues a probe RSP message that also carries the connection ID. This would allow the NCM 720 to measure the round trip time of the connection and decide whether to switch data traffic to the connection.

In another embodiment, operation 5 may include the NCM 720 configured to issue a handover REQ message to steer data traffic of the anchor connection. Data traffic may also be sent simultaneously over multiple connections, i.e., aggregated. The handover REQ message may include one or more of the following indicators. One example indicator may be the connection ID of the anchor connection to indicate which anchor connection's IP data packets are subject to the requested traffic switching operation. Another example indicator may be a connection ID for a connection that is used to convey DL bitmap traffic, where each bit representing the respective connection is used, or not used, to convey DL traffic. Another example indicator may be a connection ID for a connection that conveys UL bitmap traffic, where each bit representing the respective connection is or is not used to convey UL traffic. Another example indicator may be a DL reordering indicator, where the DL reordering indicator may be a bit field indicating whether reordering is enabled for DL traffic. If reordering is not enabled, the IP flow cannot be sent over multiple connections simultaneously. Instead, multiple IP flows may be sent over different connections for aggregation purposes. Another example indicator may be a UL reordering indicator, where a bit field is configured to indicate whether reordering is enabled for UL traffic. Another example indicator may be a last received Sequence Number (SN) of the UL, where the last received SN of the UL may be used to support lossless handover.

In response CCM 710 issues a handover RSP message including the connection ID of the IP anchor connection and the last received SN (for DL) that can be used to support lossless handover. Finally, NCM 720 issues a handover ACK message without any additional information. Here, "handover RSP" and "handover Acknowledgement (ACK)" may also be used as end markers for in-order delivery.

Fig. 8 shows an example GMA control message format. The GMA control message format may include one or more of the following fields. One example field may be a version field 810 that indicates the version of the GMA control message format. Another example field may be a message type 820, where the message type indicates the type of message, e.g., discovery, INIT-REQ/RSP, etc. Another example field may be a sequence number field 830, where an auto-increment integer may be configured to uniquely identify a transaction of a message exchange, e.g., INIT-REQ/RSP. Another example field may be a message payload type-length-value (TLV) 840. The message payload TLV 840 may include a number of control information elements, depending on the message type.

Fig. 9 depicts a General Multiple Access (GMA) user plane (U-plane) protocol stack 900. GMA U-plane protocol stack 900 may integrate multiple access networks into a single e2e IP connection. LTE-WiFi integration with IPSec in R13 is one such example.

In one example, two additional layers may be added for the multiple access convergence protocol after the application layer 910, the TCP/UDP layer 920, and between the IP layer 930 and the link (access) layers 960 (a-c). These layers may include a Multiple Access Encapsulation (MAE) layer 940 and an Access Adaptation and Tunneling (AAT) layer 950. MAE 940 is configured to encapsulate and decapsulate data traffic (e.g., IP packets) for users with additional control information (e.g., sequence numbers, Data Radio Bearer (DRB) IDs, etc.) and support multiple access convergence functions, e.g., aggregation, reordering, fragmentation, concatenation, etc. Further, the AAT 950 is configured to transmit Multiple Access (MA) -encapsulated packets through separate accesses, or may vary according to individual access configurations while using one or more of the following methods for transmission. One example method for transport is tunneling, where AAT layer 950 is configured to send the MA-encapsulated IP packet (inner) in another IP packet (outer) by IP-in-IP, UDP, or IPSec tunneling. Another example approach is client Network Address Translation (NAT), where the AAT 950 is configured to change the client IP address of MA-encapsulated IP packets, which are then sent over the access network 960. Another example approach is no change, where the AAT 950 is configured to send MA encapsulated IP packets directly without any change.

Fig. 10 shows a tail-based multiple access encapsulation packet format. The trailer-based multiple access encapsulation packet format may include an IP header (version 4 or version 6), an IP payload 1020, and a Multiple Access Trailer (MAT) 1030. The MAT 1030 may contain one or more of the following fields. One example field is a flag field, which may be 8 bits, where each bit indicates whether any of the following MAT 1030 fields are present. Another example field is a next header field, which may be 8 bits, where the IP protocol type of the original IP packet is indicated. Another example field is a connection ID field, where connection identification is indicated. For example, "000" may be used to indicate a cellular connection and "001" indicates that the packet belongs to a local (Wi-Fi anchored) connection. Another example field may be a traffic class ID, which may be 5 bits, where a flow or class identification is indicated, e.g., a data radio bearer ID for a cellular connection. Another example field may be a sequence number field, which may be 16 bits, where the sequence number is configured as an auto-incrementing integer for the encapsulator to indicate the order of transmission of the IP packets. This may also be used by the decapsulator to reorder the packets.

In another example, the proposed multicast encapsulation protocol may simultaneously support multiple (IP) anchors/connections, each of which may be uniquely identified by a connection ID. It may also support multiple traffic classes or bearers for each connection.

In another embodiment, the following fields of the IP header 1010 of the original IP (version 4 or version 6) packet may be updated. The protocol type of the IP header 1010 may be updated, wherein the protocol type may be updated to "114" to indicate that the multiple access convergence protocol is a "0 hop" protocol, not constrained by IP routing. The IP length field may also be updated to add the length of the multiple access tail 1030. In addition, after changing the protocol type and IP length fields, the IP checksum field may be updated for recalculation.

Fig. 11 shows LWIP DL and UL packet formats 1100. The LWIP DL and UL packet formats 1100 are configured to support LWIP with minimal overhead and additional new functionality (e.g., segmentation, concatenation, aggregation (bearer separation), local access, reliable handover).

In another example, the LWIP DL packet format 1100 may include 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.

In another example, the LWIP UL packet format 1100 may include 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.

In another embodiment, the IPSec ESP trailer 1150 and IPSec ESP Auth trailer 1160 of the LWIP DL and UL packet formats 1100 for DL and UL may be extended to support a universal multiple access network, which may include any access technology (e.g., 3G, 4G LTE, 5G, Wi-Fi, WiGig, MultiFire, etc.).

Fig. 12 depicts an LWIP tunnel establishment process flow. The basic principle is to configure the DL and UL using the same tunneling method for both IPSec tunneling or GRE tunneling. For IPSec tunneling, there is no impact if the UE has only one active UL DRB. In this way, c-plane and u-plane based tunneling configurations may be utilized. In the c-plane based case, the eNB will configure the UE to use IPSec tunneling only one of the UL DRBs for its activity at a time through control (RRC) messages. In the u-plane based case, a new LWIPEP method is introduced to carry the "DRB ID" without using another header (e.g., Generic Routing Encapsulation (GRE)). Currently, for GRE tunneling, there is no change or impact on the UL. Therefore, it would be an advantageous embodiment to introduce an enhanced LWIP Encapsulation Protocol (EP) such that a conventional GRE header would be used for the DL without carrying a DRB ID.

In an example embodiment, the eNB 1230 sends an RRC connection reconfiguration (RRCConnectionReconfiguration) message including the necessary parameters (GRE tunneling and IPSec transport mode configuration) to the UE 1210 to establish a GRE tunnel over the WLAN 1220 and then protect the GRE tunnel in IPSec transport mode. Further, if a DRB has not been configured, the DRB can be configured to use GRE tunneling. The UE 1210 may then send an RRC Connection Reconfiguration Complete (RRC Connection Reconfiguration Complete) message and measurements of the WLAN 1220 to the eNB 1230. The eNB 1210 may then respond with an RRC connection reconfiguration message and receive an RRC connection reconfiguration complete message from the UE 1210. Additional operations for WLAN 1220 association may occur if the WLAN is not already associated with the UE 1210 and eNB 1230. The UE 1210 may also provide a WLAN Connection Status Report (WLAN Connection Status Report) to the eNB 1230 to confirm the association of the WLAN 1220 with the LWIP tunnel establishment. In response, the eNB 1230 may provide an RRC connection reconfiguration message to the UE 1210, wherein in response, the UE 1210 may provide an RRC connection reconfiguration complete message to the eNB 1230.

In another embodiment, a bidirectional GRE tunnel protected with IPSec transport mode is established between the UE 1210 and the eNB 1230 via a WLAN 1220 link.

Fig. 13 shows the LWIP encapsulation protocol (LWIPEP) sublayer model for the Downlink (DL). Model 1300 provides a simplified LWIPEP protocol for the DL from the eNB to the UE. The model includes an upper layer 1310 and a lower layer 1320. In the downlink direction, at the eNB, when the LWIPEP entity receives a LWIPEP Service Data Unit (SDU) from the upper layer 1310, it constructs a corresponding LWIPEP Protocol Data Unit (PDU) and it can pass it to the lower layer 1320. Further, at the UE, when the LWIPEP entity receives LWIPEP PDUs from the lower layer 1320, it reassembles the corresponding LWIPEP SDU and it can pass it to the upper layer 1310.

In another embodiment, the LWIPEP header for the downlink may also be a GRE header, which is the same as the uplink. In this case, one can choose to avoid indicating DRB identification for downlink traffic so that all GRE header fields remain unused.

In another embodiment, IPSec tunnel mode for both DL and UL may be employed. This may provide enhancements and benefits compared to GRE tunnels using less overhead, and provide simpler UE implementations.

Fig. 14 depicts a LWIP Uplink (UL) Data Radio Bearer (DRB) handover procedure. In the proposed embodiment, to indicate DRB identity with IPSec tunneling method, a c-plane based LWIP UL DRB handover procedure can be implemented.

In one embodiment, the UE 1410 may activate multiple UL DRBs, the eNB may issue an RRC connection reconfiguration message to indicate that only one UL DRB will be sent over the IPSec tunnel, and the remaining DRBs may be sent over the LTE link. Further, the eNB may indicate the DRB handover timer in a message or define a default value in the standard.

In another embodiment, the DRB handover timer may indicate a minimum interval between receiving an RRC connection reconfiguration message for handing over the new DRB to the LWIP tunnel and transmitting the first UL packet of the new DRB to the LWIP tunnel. Upon receiving the RRC connection reconfiguration message, the previous DRB using the LWIP tunnel can be immediately handed back to LTE. This gap allows the eNB 1430 to identify to which DRB the received UL packet belongs during handover.

In another embodiment, the UE 1410 and the eNB 1430 may establish an IPSec tunnel via the WLAN 1420, and the first UL DRB (DRB # a) of the UE 1410 may be transferred through the IPSec tunnel. The eNB may determine whether it has to deliver the UE 1410 a second UL DRB (DRB # B) over Wi-Fi and move DRB # a back to LTE. Then, the eNB 1430 may transmit an RRC connection reconfiguration message including an indication to handover the DRB to the UE. The UE 1410 may then apply the new configuration and reply with an RRC connection reconfiguration complete message. Then, the UE 1410 can immediately move the DRB # a back to LTE and wait for a "DRB handover timer" to start sending the DRB # B through the IPSec tunnel.

In another embodiment, two additional LWIPEP methods may add DRB identification indications without introducing a new header (e.g., GRE) in front of the LWIPEP SDU (IP packet). The first method may use one of the IP header fields (e.g., TTL or DSCP or ToS) of the LWIPEP SDU to carry the DRB ID. In the uplink direction, at the UE 1410, the LWIPEP entity may receive a LWIPEP SDU from the upper layer, it may modify the LSB 5 bits of the selected IP header field (e.g., TTL or DSCP or ToS) to carry the DRB ID, it may construct and deliver the corresponding LWIPEP PDU to the lower layer. At eNB 1430, when the LWIPEP entity receives LWIPEP PDUs from the lower layer, it can change the last selected 5 bits (LSBs) of the selected IP header field back to its original value to reassemble the corresponding LWIPEP SDU and deliver it to the upper layer. The eNB 1430 may use an RRC message to indicate to the UE 1410 which field of the IP header will be used to carry the DRB ID, or this field is predefined in the 3GPP standard. In response, the UE 1410 may indicate an original value of the selected IP header during RRC connection reconfiguration complete for a DRB configured to transmit over the LTE link.

In a second approach, a new LWIP tail may be added to the end of the LWIP SDU, as shown in fig. 15, fig. 15 showing an LWIP Encapsulation Protocol (EP) data Protocol Data Unit (PDU) with an LWIP tail. The new LWIP trailer 1520 may include one or more of a DRB ID, a sequence number, an IP header checksum, and a next header that holds the protocol type of the LWIPEP SDU 1510 payload (IP payload).

In another embodiment, where an LWIP tail 1520 may or may not be added, two options may be implemented. In a first option, a new IP protocol type may be specified to indicate a new IP payload type (i.e. LWIPEP PDU (═ LWIPEP SDU + LWIP trailer) — in a second option, IP protocol type "114" may be specified to indicate any 0-hop protocol.

In another embodiment, the LWIPEP receiver may detect the presence of the LWIP trailer 1520 based on an IP protocol type field in the IP header of the LWIPEP PDU. In the uplink or downlink direction, at the UE or eNB, when the LWIPEP entity receives the LWIPEP SDU 1510 from the upper layers, it may add an LWIP tail 1520 to construct the corresponding LWIPEP PDU. It may also set the "protocol type" field to 114, recalculate and update the IP length and checksum, and then pass the LWIPEP PDU to the lower layer. If the "IP header checksum" field is present in the LWIP trailer 1520, the UE or eNB may set it to the value of the checksum of the original IP header.

In another embodiment, at the eNB or UE, the LWIPEP entity may receive LWIPEP PDUs from the lower layer, which may check its "protocol type" field and determine if an LWIP trailer 1520 exists. If so, it may remove the LWIP trailer 1520 to reassemble the corresponding LWIPEP SDU 1510, set the "protocol type" of the IP header to the value in the next header field of the LWIP trailer, recalculate and update the IP length and checksum, and then pass it to the upper layer. If an "IP header checksum" field is present in the LWIP trailer 1520, the eNB or the UE does not have to recalculate the IP header checksum, but can use the value in this field directly.

In another embodiment, the LWIP activation process of fig. 12 may be enhanced at operation 9 to enable and disable LWIPEP for DL and UL tunnels, respectively. Further, if a DRB has not been configured, the DRB may be configured to use IPSec tunnel.

In another embodiment, the LWIP tail may not be used for DL traffic. However, the sequence number information in the LWIP tail 1520 of fig. 15 and the LWIP tail 250 of fig. 2 may be useful for link quality measurements, and the eNB may still be configured to enable the LWIP tail for DL traffic.

Another example provides functionality 1600 of an apparatus of a User Equipment (UE) having a Client Connection Manager (CCM) configured to communicate over a universal multiple access (GMA) control plane protocol stack, as shown in fig. 16. The apparatus of the UE may include memory and one or more processors configured to decode an initial (INIT) Request (REQ) message 1610 received from a Network Connection Manager (NCM). The apparatus of the UE may also include memory and one or more processors configured to encode an INIT Response (RSP) message 1620 for transmission to the NCM. The apparatus of the UE may also include memory and one or more processors configured to encode a reconfiguration Request (REQ) message 1630 for transmission to the NCM. Further, the REQ message may include: a connection Identification (ID) to identify a connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

In one embodiment, the INIT REQ message may include one or more of a capability bitmap, where each bit in the capability bitmap indicates when the NC supports the corresponding capability. The initreq message may also include a plurality of auxiliary connections. The initreq message may also include the connection type. The INIT REQ message may also include an Access and Adaptation Tunnel (AAT) support bitmap. The initreq message may also include: a connection function to indicate a role connected on the u-plane as one of: only delivery, only anchor, or anchor or delivery; an AAT endpoint Internet Protocol (IP) address; or AAT specific configuration.

In one embodiment, the INIT REQ message may include one or more of a capability bitmap, where each bit in the capability bitmap indicates when the NCM supports the corresponding capability. The initreq message may also include the existing content (the prior) or one or more of a plurality of auxiliary connections. The INIT REQ message may also include one or more of existing content or Access and Adaptation Tunneling (AAT) support bitmaps. The initreq message may also include one or more of existing content or connectivity functions, wherein a connectivity function indicates a role of connectivity on the u-plane as one of: only delivery, only anchor, or anchor or delivery.

In one embodiment, in the CCM reconfiguration REQ message, the reconfiguration action establishment may include the IP address of the connection or the Maximum Transmission Unit (MTU) size of the connection.

In another embodiment, where the NM sends a reconfiguration message RSP message, the reconfiguration RSP message may include a connection Identification (ID) for identifying the secondary connection used for the reconfiguration. The reconfiguration RSP message may also include a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

In another embodiment, there may be an established reconfiguration action request in the NCM reconfiguration RSP message. The NCM reconfiguration RSP message may include a Downlink (DL) GMA tail format bitmap, where each bit in the DL GMA tail indicates whether the corresponding tail field is enabled or disabled for the DL. The NCM reconfiguration RSP message may also include an Uplink (UL) GMA tail format bitmap, where each bit in the UL GMA tail indicates whether the corresponding tail field is enabled or disabled for the uplink. The NCM reconfiguration RSP message may also include a maximum GMA Protocol Data Unit (PDU) payload size, where the GMA PDU indicates the maximum payload size of the GMA encapsulated PDU.

In another embodiment, the probe REQ message sent by the NCM may include a connection ID to indicate the corresponding connection for the probe REQ message to be communicated.

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

In another embodiment, the handover REQ message may be sent by the NCM. The handover REQ message may be sent to steer data traffic for one anchor connection or multiple anchor connections simultaneously.

In another embodiment, the CCM may send a switch RSP message to confirm traffic steering operations.

In another embodiment, the handover REQ message may include one or more of the connection IDs of the anchor connections. The handover REQ message may also include one or more of the connection IDs of the Downlink (DL) bitmap connections, where each bit of the DL bitmap connection representing the respective primary or secondary connection is used to convey DL traffic. The handover REQ message may also include one or more of the connection IDs of an Uplink (UL) bitmap connection, where each bit of the UL bitmap connection represents a respective primary or secondary connection for conveying UL traffic. The handover REQ message may also include one or more of UL reordering indicators, which are bit fields indicating whether reordering is enabled or disabled. The handover REQ message may also include one or more of a DL reordering indicator, which is a bit field indicating whether reordering is enabled or disabled, or a UL last received sequence number, which indicates the last received UL packet for a lossless handover.

In another embodiment, the handover RSP message may include one or more of a connection ID of the anchor connection or a DL last received Sequence Number (SN) indicating a last received DL packet for a lossless handover.

In another embodiment, the CCM may send a handover ACK message to acknowledge successful receipt of the handover RSP.

Another example provides functionality 1700 of an apparatus of a User Equipment (UE) with Generic Routing Encapsulation (GRE) based tunneling for Uplink (UL) and Downlink (DL) communications in LTE WLAN radio level integration (LWIP) operation with IPsec tunneling, as shown in fig. 17. An apparatus of a UE may include memory and one or more processors configured to encode a Wireless Local Area Network (WLAN) connection status report for transmission to an evolved node b (enb) to confirm a WLAN association (1710). The apparatus of the UE may also include 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 includes configuration parameters for an Internet protocol Security (IPSec) transmission mode; and configuration parameters for GRE tunneling. The apparatus of the UE may also include 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 for UL and DL between the UE and the eNB over the WLAN and to protect the bidirectional GRE tunnel using IPSec transmission mode (1730).

In one embodiment, the one or more processors are configured to configure one or more Data Radio Bearers (DRBs) to use GRE tunneling.

Another example provides functionality 1800 of an apparatus of a User Equipment (UE) configured to perform a control plane based LTE WLAN radio level integration with IPsec tunnel (LWIP) Uplink (UL) Data Radio Bearer (DRB) handover, as shown in fig. 18. The apparatus of the UE may include memory and one or more processors configured to decode a Radio Resource Control (RRC) connection reconfiguration message (1810) received from an evolved node b (enb). Wherein the RRC connection reconfiguration message includes information for the UE to switch from a first DRB operating on an Internet protocol security (IPSec) tunnel to a second DRB operating on an IPSec tunnel. The apparatus of the UE may also include memory and one or more processors configured to identify a DRB handover timer value in the RRC connection reconfiguration message (1820). Wherein the DRB handover timer value provides the UE with a minimum separation between receiving the RRC connection reconfiguration message and transmitting the UL packet of the second DRB through the IPSec tunnel. The apparatus of the UE may also include memory and one or more processors configured to encode the UL packet for transmission over the IPSec tunnel via the second DRB after the DRB handover timer value to enable the eNB to identify to which DRB the received UL packet belongs (1830).

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

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

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 may include memory and one or more processors configured to modify predetermined bits in selected Internet Protocol (IP) header fields to carry a DRB Identification (ID) in an LTE WLAN radio level integrated encapsulation protocol (LWIPEP) Service Data Unit (SDU) with IPsec tunnel (1910). The apparatus of the UE may also include memory and one or more processors configured to construct a LWIPEP Protocol Data Unit (PDU) from the LWIPEP SDU (1920). The apparatus of the UE may also include memory and one or more processors configured to encode, for transmission to an evolved node b (eNB), an LWIPEP PDU containing a DRB ID to enable the eNB to associate the data packet with the selected DRB based on the DRB ID (1930).

In one embodiment, 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.

In one embodiment, the fields of the selected IP header may be one or more of a Time To Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a type of service (ToS) field.

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.

In one embodiment, the end of the LWIPEP SDU may include an LWIP trailer including a DRB ID, a sequence number, an IP header checksum, and a next header.

FIG. 20 illustrates example components of a device according to some embodiments. In some embodiments, 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, which may be coupled together at least as shown. The illustrated components of the apparatus 2000 may be included in a UE or RAN node. In some embodiments, the apparatus 2000 may include fewer elements (e.g., the RAN node may not employ the application circuitry 2002, but rather includes a processor/controller to process IP data received from the EPC). In some embodiments, device 2000 may include additional elements, such as memory/storage, a display, a camera, sensors, and/or input/output (I/O) interfaces. In other embodiments, the components described below may be included in more than one device (e.g., the circuitry may be included separately in more than one device for a cloud RAN (C-RAN) implementation).

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 special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be operably coupled to and/or may include memory/storage and may be configured to execute instructions stored in the memory/storage to cause various applications and/or operating systems to run on the system. In some embodiments, the processor of the application circuitry 2002 may process IP data packets received from the EPC.

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 the receive signal path of the RF circuitry 2006 and to generate baseband signals for the transmit signal path of the RF circuitry 2006. Baseband processing circuitry 2004 may interact with the application circuitry 2002 for generating and processing baseband signals and for controlling the operation of the RF circuitry 2006. For example, in some embodiments, the baseband circuitry 2004 may include a second generation (2G) baseband processor 2004a, a third generation (3G) baseband processor 2004b, a fourth generation (4G) baseband processor 2004c, and other baseband processor(s) 2004d for other existing, developing, or future generations (e.g., fifth generation (5G), sixth generation (6G), etc.). Baseband circuitry 2004 (e.g., at least one of baseband processors 2004 a-d) may handle various radio control functions that enable communication with one or more radio networks through RF circuitry 2006. In other embodiments, some or all of the functionality of the baseband processors 2004a-d may be included in modules stored in the memory 2004g and executed via a Central Processing Unit (CPU)2004 e. The radio control functions may include, but are not limited to: signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 2004 may include Fast Fourier Transform (FFT), precoding, and constellation mapping/demapping functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 2004 may include convolution, tail-biting convolution, turbo, viterbi, and Low Density Parity Check (LDPC) encoder/decoder functions, other functions, and combinations thereof. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples and may include other suitable functions.

In some embodiments, the baseband circuitry may include one or more audio Digital Signal Processors (DSPs) 2004 f. The audio DSP(s) 2004f may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. The components of the baseband circuitry may be suitably combined in a single chip or a single chipset, or suitably arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuitry 2004 and the application circuitry 2002 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, baseband circuitry 2004 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 2004 may support communication with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) and/or other Wireless Metropolitan Area Networks (WMANs), Wireless Local Area Networks (WLANs), Wireless Personal Area Networks (WPANs). In some embodiments, the baseband circuitry 2004 is configured to support radio communications of more than one wireless protocol, which embodiments may be referred to as multi-mode baseband circuitry.

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

In some embodiments, RF circuitry 2006 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 2006 can include mixer circuitry 2006a, amplifier circuitry 2006b, and filter circuitry 2006 c. The transmit signal path of the RF circuitry 2006 can include filter circuitry 2006 and mixer circuitry 2006 a. The RF circuitry 2006 can also include synthesizer circuitry 2006d to synthesize frequencies for use by the mixer circuitry 2006a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuit 2006a of the receive signal path may be configured to down-convert RF signals received from the FEM circuit 2008 based on a synthesized frequency provided by the synthesizer circuit 2006 d. The amplifier circuit 2006b may be configured to amplify the downconverted signal, and the filter circuit 2006c may be a Low Pass Filter (LPF) or a Band Pass Filter (BPF) configured to remove unwanted signals from the downconverted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 2004 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some embodiments, mixer circuit 2006a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this respect.

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

In some embodiments, mixer circuit 2006a of the receive signal path and mixer circuit 2006a of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion or up-conversion, respectively. In some embodiments, the mixer circuit 2006a of the receive signal path and the mixer circuit 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, mixer circuit 2006a of the receive signal path and mixer circuit 2006a of the transmit signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, mixer circuit 2006a of the receive signal path and mixer circuit 2006a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative 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 for communicating with the RF circuitry 2006.

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

In some embodiments, synthesizer circuit 2006d may include one or more of a fractional-N synthesizer or a fractional-N/N +1 synthesizer, although the scope of embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuit 2006d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

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

In some embodiments, the frequency input may be provided by a Voltage Controlled Oscillator (VCO), but this is not required. The divider control input may be provided by baseband circuitry 2004 or application processor 2002, depending on the desired output frequency. In some embodiments, the divider control input (e.g., N) may be determined from a look-up table based on the channel indicated by the application circuit 2002.

Synthesizer circuit 2006d of RF circuit 2006 can include a frequency divider, a Delay Locked Loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the divider may be a Dual Mode Divider (DMD) and the phase accumulator may comprise a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide an input signal by N or N +1 (e.g., based on a carry) to provide a fractional division ratio. In some example embodiments, a 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 decompose the VCO period into at most Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this manner, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuit 2006d can be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency, etc.) and used in conjunction with a quadrature generator and divider circuit to generate multiple signals at the carrier frequency having multiple phases that are different from one another. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuitry 2006 may include an IQ/polarity converter.

FEM circuitry 2008 may include a receive signal path that may include circuitry configured to manipulate RF signals received from one or more antennas 2010, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 2006 for further processing. The FEM circuitry 2008 may also include a transmit signal path that may include circuitry configured to amplify signals provided for transmission by the RF circuitry 2006 for transmission by one or more of the one or more antennas 2010.

In some embodiments, 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 the received RF signal and provide the amplified received RF signal 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) configured to amplify an input RF signal (e.g., provided by the RF circuitry 2006), and may include one or more filters to generate an RF signal for subsequent transmission (e.g., by one or more of the one or more antennas 2010).

In some embodiments, the apparatus 2000 includes multiple power saving mechanisms. If the device 2000 is in an RRC Connected (RRC _ Connected) state, where it is still Connected to the RAN node, since it expects to receive traffic very fast, it may enter a state called discontinuous reception mode (DRX) after a period of inactivity. During this state, the device may be shut down for brief intervals of time, thereby saving power.

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

The additional power saving mode also allows the device to be unavailable to the network for periods of time longer than the paging interval (from a few seconds to a few hours). During this time, the device is completely unable to connect to the network and may be completely powered off. Any data sent during this time causes a large delay and it is assumed that the delay is acceptable.

The processor of the application circuitry 2002 and the processor of the baseband circuitry 2004 may be configured to execute elements of one or more instances of a protocol stack. For example, the processor of the baseband circuitry 2004 (alone or in combination) may be configured to perform layer 3, layer 2, and/or layer 1 functions, while the processor of the application circuitry 2004 may utilize data (e.g., packet data) received from these layers and also perform layer 4 functions (e.g., Transmission Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, layer 3 may include a Radio Resource Control (RRC) layer, described in further detail below. As mentioned herein, layer 2 may include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, as will be described in further detail below. As mentioned herein, layer 1 may comprise the Physical (PHY) layer of the UE/RAN node, as will be described in further detail below.

Fig. 21 provides an example illustration of a wireless device, such as a User Equipment (UE), Mobile Station (MS), mobile wireless device, mobile communication device, tablet, handheld device, or other type of wireless device. A wireless device may 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), evolved node b (enb), baseband processing unit (BBU), Remote Radio Head (RRH), Remote Radio Equipment (RRE), Relay Station (RS), Radio Equipment (RE), or other type of Wireless Wide Area Network (WWAN) access point. The wireless device may be configured to communicate using at least one wireless communication standard, such as, but not limited to, 3GPP LTE, WiMAX, High Speed Packet Access (HSPA), bluetooth, and WiFi. Wireless devices may communicate using separate antennas for each wireless communication standard or shared antennas for multiple wireless communication standards. The wireless devices may communicate in a Wireless Local Area Network (WLAN), a Wireless Personal Area Network (WPAN), and/or a WWAN. The wireless device may also include a wireless modem. The wireless modem may include, for example, a wireless radio transceiver and baseband circuitry (e.g., a baseband processor). In one example, a wireless modem can modulate signals transmitted by a wireless device via one or more antennas and demodulate signals received by the wireless device via one or more antennas.

Fig. 21 also provides an illustration of a microphone and one or more speakers that may be used for audio input and output from the wireless device. The display screen may be a Liquid Crystal Display (LCD) screen or other type of display screen, for example, an Organic Light Emitting Diode (OLED) display. The display screen may be configured as a touch screen. The touch screen may use capacitive, resistive, or other types of touch screen technology. The application processor and the graphics processor may be coupled to internal memory to provide processing and display capabilities. The non-volatile memory port may also be used to provide data input/output options to a user. The non-volatile memory port may also be used to expand the memory capabilities of the wireless device. The keyboard may be integrated with or wirelessly connected to the wireless device to provide additional user input. A touch screen may also be used to provide a virtual keyboard.

Examples of the invention

The following examples relate to particular technology embodiments and indicate particular features, elements or acts that may be used or otherwise combined in implementing the embodiments.

Example 1 includes an apparatus of a User Equipment (UE) having a Client Connection Manager (CCM) configured to communicate over a universal multiple access (GMA) control plane protocol stack, comprising: one or more processors configured to: decoding an initial (INIT) Request (REQ) message received from a Network Connection Manager (NCM); encoding an INIT Response (RSP) message for transmission to the NCM; and encoding a reconfiguration Request (REQ) message for transmission to the NCM, wherein the reconfiguration REQ message comprises: a connection Identification (ID) for identifying a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request from one or more of establishing the secondary connection or releasing the secondary connection; and a memory coupled to the one or more processors and configured to store the received INIT REQ message.

Example 2 includes the apparatus of the UE of example 1, wherein the INIT REQ message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; a connection type; an Access and Adaptation Tunneling (AAT) support bitmap; a connection function to indicate a role connected on the u-plane as one of: only delivery, only anchor, or anchor or delivery; an AAT endpoint Internet Protocol (IP) address; alternatively, AAT-specific configuration.

Example 3 includes the apparatus of the UE of example 1 or 2, wherein the INIT RSP message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; an Access and Adaptation Tunneling (AAT) support bitmap; or, a connection function for indicating a role connected on the u-plane as one of the following: only delivery, only anchor, or anchor or delivery.

Example 4 includes the apparatus of the UE of example 1 or 2, wherein, in the CCM reconfiguration REQ message, the reconfiguration action request establishment includes an IP address of the connection or a Maximum Transmission Unit (MTU) size of the connection.

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 comprises: a connection Identification (ID) for identifying an auxiliary connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

Example 6 includes the apparatus of the UE of example 1 or 2, wherein, in the NCM reconfiguration RSP message, the reconfiguration action request establishment comprises one or more of: a Downlink (DL) GMA tail format bitmap, wherein each bit in the DL GMA tail indicates whether a respective tail field is enabled or disabled for DL; an Uplink (UL) GMA tail format bitmap, wherein each bit in the UL GMA tail indicates whether a respective tail field is enabled or disabled for uplink; alternatively, a maximum GMA Protocol Data Unit (PDU) payload size, wherein the GMA PDU indicates a maximum payload size of a GMA encapsulated PDU.

Example 7 includes the apparatus of the UE of example 1 or 2, wherein the NCM transmits the probe REQ message, wherein the probe REQ message includes a connection ID to indicate a corresponding connection for the probe REQ message to be communicated.

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

Example 9 includes the apparatus of the UE of example 1, wherein the NCM sends the handover REQ message to direct data traffic for one anchor connection, or to direct data traffic for multiple anchor connections simultaneously.

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

Example 11 includes the apparatus of the UE of example 9, wherein the handover REQ message includes one or more of: a connection ID of the anchor connection; a connection ID for a Downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing the respective primary or secondary connection is used to convey DL traffic; a connection ID of an Uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a respective primary or secondary connection for conveying UL traffic; a UL reordering indicator, wherein the UL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or, a DL reordering indicator, wherein the DL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or, a UL last received sequence number indicating a last received UL packet for a lossless handover.

Example 12 includes the apparatus of the UE of example 9, further comprising: a handover RSP message comprising one or more of: a connection ID of the anchor connection; or, a DL last received Sequence Number (SN) indicating a last received DL packet for lossless handover.

Example 13 includes the apparatus of the UE of example 1 or 12, wherein the CCM sends a handover ACK message to confirm successful receipt of the handover RSP.

Example 14 includes an apparatus of a node having a Network Connection Manager (NCM) configured to communicate over a universal multiple access (GMA) control plane protocol stack, comprising: one or more processors configured to: encoding an initial (INIT) Request (REQ) message for transmission to a Client Connection Manager (CCM); decoding 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 comprises: a connection Identification (ID) for identifying a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request from one or more of establishing the secondary connection or releasing the secondary connection; and a memory coupled to the one or more processors and configured to store the received reconfiguration REQ message.

Example 15 includes the apparatus of the node of example 14, wherein the INIT REQ message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; a connection type; an Access and Adaptation Tunneling (AAT) support bitmap; a connection function to indicate a role connected on the u-plane as one of: only delivery, only anchor, or anchor or delivery; an AAT endpoint Internet Protocol (IP) address; alternatively, AAT-specific configuration.

Example 16 includes the apparatus of the node of examples 14 or 15, wherein the INIT RSP message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; an Access and Adaptation Tunneling (AAT) support bitmap; or, a connection function for indicating a role connected on the u-plane as one of the following: only delivery, only anchor, or anchor or delivery.

Example 17 includes the apparatus of the node of examples 14 or 15, wherein the node is one or more of: evolved node B (eNB), gNodeB (gNB), serving gateway (S-GW), or Packet Data Network (PDN) gateway (P-GW).

Example 18 includes an apparatus of a User Equipment (UE) configured for Generic Routing Encapsulation (GRE) -based tunneling of Uplink (UL) and Downlink (DL) communications in an LTE WLAN radio level integration (LWIP) operation with IPsec tunneling, comprising: one or more processors configured to: encoding a Wireless Local Area Network (WLAN) connection status report for transmission to an evolved node B (eNB) to confirm a WLAN association; decoding a Radio Resource Control (RRC) connection reconfiguration message received from the eNB, wherein the RRC connection reconfiguration message comprises: configuration parameters for internet protocol security (IPSec) transmission mode; and configuration parameters for GRE tunneling; and encoding an RRC connection reconfiguration complete message for transmission to the eNB to establish a bidirectional GRE tunnel for UL and DL between the UE and the eNB over the WLAN and to protect the bidirectional GRE tunnel using IPSec transmission mode; and a memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

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 (DRBs) to use GRE tunneling.

Example 20 includes an apparatus of a User Equipment (UE) configured to perform a control plane based LTE WLAN radio level integration with IPsec tunnel (LWIP) Uplink (UL) Data Radio Bearer (DRB) handover, comprising: one or more processors configured to: decoding a Radio Resource Control (RRC) connection reconfiguration message received from an evolved node B (eNB), wherein the RRC connection reconfiguration message includes information for the UE to switch from a first DRB operating on an Internet protocol security (IPSec) tunnel to a second DRB operating on an IPSec tunnel; identifying a DRB handover timer value in the RRC connection reconfiguration message, wherein the DRB handover timer value provides the UE with a minimum separation between receiving the RRC connection reconfiguration message and sending a UL packet of the second DRB over the IPSec tunnel; encoding the UL packet for transmission through the IPSec tunnel via the second DRB after the DRB handover timer value to enable the eNB to identify to which DRB the received UL packet belongs; and a memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

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 the 3GPP link with the eNB.

Example 22 includes the apparatus of the UE of example 20, wherein the one or more processors are further configured to: an RRC connection reconfiguration complete message for transmission to the eNB is encoded.

Example 23 includes an apparatus configured to provide a User Equipment (UE) with a Data Radio Bearer (DRB) indication of internet protocol security (IPSec) tunneling, comprising a memory; and one or more processors configured to: modifying predetermined bits in selected Internet Protocol (IP) header fields to carry a DRB Identification (ID) in an LTE WLAN radio integrated encapsulation protocol (LWIPEP) Service Data Unit (SDU) with IPsec tunnel; constructing an LWIPEP Protocol Data Unit (PDU) from the LWIPEP SDU; and encoding the LWIPEP PDU including the DRB ID for transmission to an evolved node b (eNB) to enable the eNB to associate the data packet with the selected DRB based on the DRB ID.

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.

Example 25 includes the apparatus of the UE of example 24, wherein the fields of the selected IP header are one or more of: a Time To Live (TTL) field, a Differentiated Services Code Point (DSCP) field, or a type of service (ToS) field.

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

Example 27 includes the apparatus of the UE of example 23, wherein the end of the LWIPEP SDU comprises an LWIP tail with: DRB ID, sequence number, IP header checksum, and next header.

Example 28 includes a General Multiple 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 functionality; a GMA adaptation layer configured to transmit the plurality of access encapsulation packets over the selected link; and a link access layer located below the GMA adaptation layer.

Example 29 includes the GMA U plane protocol stack of example 28, wherein the GMA aggregation layer is configured to encapsulate and decapsulate data in a tail-based GMA encapsulation Protocol Data Unit (PDU), comprising: an IP header; an IP payload comprising one or more IP packets; and a GMA tail.

Example 30 includes the GMA U plane protocol stack of example 29, wherein the GMA tail includes additional control information including one or more of: a next header comprising an IP protocol type of the IP packet in the IP payload of the GMA PDU; a connection Identification (ID) including 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 store bearer (DRB) identification; sequence numbers, including the transmission order of the IP packets; a packet length including a length of the IP packet or a length of a first IP packet included in the concatenation of IP packets; or, a segmentation control, including an indication of where the segmented packet is located in the packet.

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: the protocol type is used for indicating that a GMA tail exists, and the GMA convergence protocol is a '0-hop' protocol which is not limited by IP routing; IP length, including the length of the GMA trailer or the length of the concatenated IP packets; alternatively, the IP checksum, includes a recalculation after changing the protocol type and IP length.

Example 32 includes the GMA U plane protocol stack of example 31, wherein the protocol type is a 114 protocol type.

Example 33 includes the GMA U plane protocol stack of example 28 or 29, wherein the GMA adaptation layer is configured to transmit the GMA encapsulation packet using one or more of: a tunnel configured to transmit the GMA-encapsulated IP packet as an inner IP packet of additional outer IP packets using one or more of an IP-in-IP tunnel, a User Datagram Protocol (UDP) tunnel, or an IP security (IPSec) tunnel; a client Network Access Translation (NAT) configured to change a client IP address of the GMA encapsulated IP packet; or leave the GMA encapsulated packet unchanged.

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 a GMA convergence layer (layer 2.5); and an anchor/transport access link layer (layer 2) configured to transport data traffic of the anchor IP connection and to interface with the physical layer (layer 2) and the GMA adaptation layer (layer 2.5).

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 the client device to one or more core IP networks via the plurality of access networks.

Example 36 includes the GMA U plane protocol stack of example 35, wherein the plurality of access networks comprises an anchor access network and a plurality of transit access networks.

Example 37 includes an apparatus of a User Equipment (UE) having a Client Connection Manager (CCM) configured to communicate over a General Multiple Access (GMA) control plane protocol stack, comprising: one or more processors configured to: decoding an initial (INIT) Request (REQ) message received from a Network Connection Manager (NCM); encoding an INIT Response (RSP) message for transmission to the NCM; and encoding a reconfiguration Request (REQ) message for transmission to the NCM, wherein the reconfiguration REQ message comprises: a connection Identification (ID) for identifying a connection for reconfiguration; a reconfiguration action to indicate which reconfiguration action to request from one or more of establishing the secondary connection or releasing the secondary connection; and a memory coupled to the one or more processors and configured to store the received INIT REQ message.

Example 38 includes the apparatus of the UE of example 37, wherein the INIT REQ message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; a connection type; an Access and Adaptation Tunnel (AAT) support bitmap; a connection function to indicate a role connected on the u-plane as one of: only delivery, only anchor, or anchor or delivery; an AAT endpoint Internet Protocol (IP) address; alternatively, AAT-specific configuration.

Example 39 includes the apparatus of the UE of example 37 or 38, wherein the INIT RSP message includes one or more of: a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability; a plurality of auxiliary connections; an Access and Adaptation Tunnel (AAT) support bitmap; or, a connection function for indicating a role connected on the u-plane as one of the following: only delivery, only anchor, or anchor or delivery.

Example 40 includes the apparatus of the UE of example 37 or 38, wherein, in the CCM reconfiguration REQ message, the reconfiguration action request establishment includes an IP address of the connection or a Maximum Transmission Unit (MTU) size of the connection.

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 comprises: a connection Identification (ID) for identifying an auxiliary connection for reconfiguration; and a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

Example 42 includes the apparatus of the UE of example 37 or 38, wherein, in the NCM reconfiguration RSP message, the reconfiguration action request establishment comprises one or more of: a Downlink (DL) GMA tail format bitmap, wherein each bit in the DL GMA tail indicates whether a respective tail field is enabled or disabled for DL; an Uplink (UL) GMA tail format bitmap, wherein each bit in the UL GMA tail indicates whether a respective tail field is enabled or disabled for the uplink; alternatively, a maximum GMA Protocol Data Unit (PDU) payload size, wherein the GMA PDU indicates a maximum payload size of a GMA encapsulated PDU.

Example 43 includes the apparatus of the UE of example 37 or 38, wherein the NCM sends the probe REQ message, wherein the probe REQ message includes a connection ID to indicate a corresponding connection for the probe REQ message to be communicated, and the NCM sends the handover REQ message to direct data traffic of one anchor connection, or of multiple anchor connections simultaneously.

Example 44 includes the apparatus of the UE of example 37, wherein the CCM is configured to: encoding a probing RSP message, wherein the probing RSP message includes a connection ID indicating a round trip calculation for the connection and indicating when to switch data traffic to the connection; sending a switch RSP message to confirm traffic steering operations; and sending a handover ACK message to acknowledge successful receipt of the handover RSP.

Example 45 includes the apparatus of the UE of example 44, wherein the handover REQ message includes one or more of: a connection ID of the anchor connection; a connection ID for a Downlink (DL) bitmap connection, wherein each bit of the DL bitmap connection representing the respective primary or secondary connection is used to convey DL traffic; a connection ID of an Uplink (UL) bitmap connection, wherein each bit of the UL bitmap connection represents a respective primary or secondary connection for conveying UL traffic; a UL reordering indicator, wherein the UL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or, a DL reordering indicator, wherein the DL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or, a UL last received sequence number indicating a last received UL packet for a lossless handover.

Example 46 includes an apparatus of a User Equipment (UE) configured to perform a control plane based LTE WLAN radio level integration with IPsec tunnel (LWIP) Uplink (UL) Data Radio Bearer (DRB) handover, comprising: one or more processors configured to: decoding a Radio Resource Control (RRC) connection reconfiguration message received from an evolved node B (eNB), wherein the RRC connection reconfiguration message includes information for the UE to switch from a first DRB operating on an Internet protocol security (IPSec) tunnel to a second DRB operating on an IPSec tunnel; identifying a DRB handover timer value in the RRC connection reconfiguration message, wherein the DRB handover timer value provides the UE with a minimum separation between receiving the RRC connection reconfiguration message and sending a UL packet of the second DRB over the IPSec tunnel; encoding the UL packet for transmission through the IPSec tunnel via the second DRB after the DRB handover timer value to enable the eNB to identify to which DRB the received UL packet belongs; and a memory coupled to the one or more processors and configured to store the RRC connection reconfiguration message.

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

Example 48 includes an apparatus of a User Equipment (UE) configured to provide a Data Radio Bearer (DRB) indication with an internet protocol security (IPSec) tunnel, comprising a memory; and one or more processors configured to: modifying predetermined bits in selected Internet Protocol (IP) header fields to carry a DRB Identification (ID) in an LTE WLAN radio integrated encapsulation protocol (LWIPEP) Service Data Unit (SDU) with IPsec tunnel; constructing an LWIPEP Protocol Data Unit (PDU) from the LWIPEP SDU; and encoding the LWIPEP PDU including the DRB ID for transmission to an evolved node b (eNB) to enable the eNB to associate the data packet with the selected DRB based on the DRB ID.

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.

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 the RRC configuration complete message to enable the eNB to restore the modified bits to the original value.

Example 51 includes the apparatus of the UE of example 48, wherein an end of the LWIPEP SDU comprises an LWIP tail with: DRB ID, sequence number, IP header checksum, and next header.

The various techniques, or some 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 memories (CD-ROMs), hard drives, non-transitory computer-readable storage media, 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 can include a processor, a storage medium readable by the processor (including volatile and non-volatile 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 Random Access Memory (RAM), erasable programmable read-only memory (EPROM), flash drives, optical drives, magnetic hard drives, solid state drives, or other media for storing electronic data. The nodes and wireless devices 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 may 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) can 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.

As used herein, the term "circuitry" may refer to 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; or may be part of the above. In some embodiments, the circuitry may be implemented in, or functions associated with, one or more software or firmware modules. In some embodiments, the circuitry may comprise logic operable, at least in part, in hardware.

It should be appreciated 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 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.

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 need 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.

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. A module may be passive or active, including an agent operable to perform a desired function.

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, the appearances of the phrase "in an example" or the word "illustrative" in various places throughout this specification are not necessarily all referring to the same embodiment.

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, the mere fact that no individual member of such list is based on their presence in a common group, without indications to the contrary, is to be construed as a de facto equivalent of any other member of the same list. Furthermore, various embodiments and examples of the present technology may be referred to herein along with alternatives for their various components. It is understood that such embodiments, examples, and alternatives are not to be construed as actual equivalents of each other, but are to be considered as separate and autonomous representations of the present technology.

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 present 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, arrangements, and so forth. 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 above examples illustrate 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 many modifications in form, usage and details of implementation can be made without the exercise of the inventive faculty and without departing from the principles and concepts of the technology. Accordingly, the technology is not intended to be limited except by the appended claims.

Claims (17)

1. An apparatus of a User Equipment (UE) having a Client Connection Manager (CCM) configured to communicate over a universal multiple access (GMA) control plane protocol stack, the apparatus of the UE comprising:

one or more processors configured to:

decoding an initial INIT request REQ message received from a network connection manager NCM;

encoding an INIT response RSP message for transmission to the NCM; and

encoding a reconfiguration request, REQ, message for transmission to the NCM, wherein the reconfiguration REQ message comprises:

a connection identification ID for identifying a connection for reconfiguration;

a reconfiguration action to indicate which reconfiguration action to request from one or more of establishing the secondary connection or releasing the secondary connection; and

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

2. The apparatus of the UE of claim 1, wherein the INIT REQ message comprises one or more of:

a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability;

a plurality of auxiliary connections;

a connection type;

accessing and adapting a tunneling AAT support bitmap;

a connection function to indicate a role connected on the u-plane as one of:

only delivery, only anchor, or anchor or delivery;

AAT endpoint internet protocol, IP, address; or

AAT specific configuration.

3. The apparatus of the UE of claim 1 or 2, wherein the INIT RSP message comprises one or more of:

a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability;

a plurality of auxiliary connections;

accessing and adapting a tunneling AAT support bitmap; or

A connection function to indicate a role connected on the u-plane as one of:

only delivery, only anchor, or anchor or delivery.

4. The apparatus of the UE of claim 1 or 2, wherein in the CCM reconfiguration REQ message, the reconfiguration action request establishment comprises the IP address of the connection or the maximum transmission unit, MTU, size of the connection.

5. The apparatus of the UE of claim 1 or 2, wherein the NCM transmits a reconfiguration RSP message, wherein the reconfiguration RSP message comprises:

a connection identification ID for identifying an auxiliary connection for reconfiguration; and

a reconfiguration action to indicate which reconfiguration action is requested from one or more of establishing the secondary connection or releasing the secondary connection.

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

a downlink DL GMA tail format bitmap, wherein each bit in the DL GMA tail indicates whether a respective tail field is enabled or disabled for DL;

an uplink UL GMA tail format bitmap, wherein each bit in the UL GMA tail indicates whether a respective tail field is enabled or disabled for uplink; or

A maximum GMA Protocol Data Unit (PDU) payload size, wherein the GMA PDU indicates a maximum payload size of a GMA encapsulated PDU.

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

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

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

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

11. The apparatus of the UE of claim 9, wherein the handover REQ message comprises 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 the corresponding primary or secondary connection is used to convey DL traffic;

a connection ID for an uplink UL bitmap connection, wherein each bit of the UL bitmap connection represents a respective primary or secondary connection for conveying UL traffic;

a UL reordering indicator, wherein the UL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or

A DL reordering indicator, wherein the DL reordering indicator is a bit field indicating whether reordering is enabled or disabled; or

UL last received sequence number indicating the last received UL packet for lossless handover.

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

a connection ID of the anchor connection; or

DL last received sequence number, SN, indicating the last received DL packet for lossless handover.

13. The apparatus of the UE of claim 1 or 12, wherein the CCM sends a handover ACK message to acknowledge successful receipt of the handover RSP.

14. An apparatus of a node having a network connection manager, NCM, configured to communicate over a universal multiple access, GMA, control plane protocol stack, the apparatus comprising:

one or more processors configured to:

encoding an initial INIT request REQ message for transmission to the client connection manager CCM;

decoding an INIT response RSP message received from the CCM; and

decoding a reconfiguration request, REQ, message received from the CCM, wherein the reconfiguration REQ message comprises:

a connection identification ID for identifying a connection for reconfiguration;

a reconfiguration action to indicate which reconfiguration action to request from one or more of establishing the secondary connection or releasing the secondary connection; and

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

15. The apparatus of the node of claim 14, wherein the INIT REQ message comprises one or more of:

a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability;

a plurality of auxiliary connections;

a connection type;

accessing and adapting a tunneling AAT support bitmap;

a connection function to indicate a role connected on the u-plane as one of:

only delivery, only anchor, or anchor or delivery;

AAT endpoint internet protocol, IP, address; or

AAT specific configuration.

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

a capabilities bitmap, wherein each bit in the capabilities bitmap indicates when the NCM supports a respective capability;

a plurality of auxiliary connections;

accessing and adapting a tunneling AAT support bitmap; or

A connection function to indicate a role connected on the u-plane as one of:

only delivery, only anchor, or anchor or delivery.

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

Images