CN116017426A - LWIP user plane interface - Google Patents

Abstract

Embodiments of the present disclosure relate to LWIP user plane interfaces. Methods, systems, and storage media for wireless communication through radio level integration (LWIP) of internet protocol security (IPsec) tunnels using Long Term Evolution (LTE)/Wireless Local Area Network (WLAN) are described. In an embodiment, the user plane interface is terminated at an evolved NodeB (eNB) and an LWIP-security gateway (LWIP-SeGW). LWIP encapsulation protocol (LWIPEP) -Protocol Data Units (PDUs) may be transmitted over a user plane interface over a single general packet radio system tunneling protocol (GTP) tunnel. Other embodiments may be described and/or claimed.

Description

LWIP user plane interface

The present application is a divisional application of the invention patent application with international application number PCT/US2017/059372, international application date 2017, 10 month 31, entry into the chinese national stage at 2019, 05 month 31, chinese national application number 201780074697.9, and the invention name "LWIP user plane interface".

RELATED APPLICATIONS

The present application claims priority from U.S. provisional application No. 62/416,532 filed on date 2016, 11, 2, and incorporated herein by reference in its entirety, in accordance with 35u.s.c. ≡119.

Technical Field

Various embodiments of the present application relate generally to the field of wireless communications, and more particularly to wireless communications using long term evolution (Long Term Evolution, LTE)/wireless local area network (Wireless Local Area Network, WLAN) over internet protocol security (Internet Protocol Security, IPsec) tunneling radio-level integration (LTE/WLAN Radio Level Integration with IPsec Tunnel, LWIP).

Background

Third generation partnership project (3 GPP) Long Term Evolution (LTE) systems may support features that allow networks to configure User Equipment (UE) with LTE and WiFi capabilities to utilize links of both networks. Two of these features include LTE-WLAN aggregation (LWA) and radio-level integration (LWIP) of LTE/WLAN through IPsec tunnels. Both LWA and LWIP may include backhaul connections between an evolved NodeB (eNB) and WLAN devices. The LWA system may use an Xw interface for this backhaul connection; however, there is some controversy as to which interface should be used for backhaul connection in LWIP or enhanced LWIP (erlip).

LWIP is similar to LWA in that both features use WiFi technology to utilize unlicensed spectrum, but there is a difference between LWIP and LWA. One difference is that LWA aggregates LTE and WiFi at the packet data convergence protocol (packet data convergence protocol, PDCP) layer, while LWIP aggregates or switches between LTE and WiFi links at the Internet Protocol (IP) layer. Because of this difference, LWA may use PDCP Protocol Data Unit (PDU) payloads to communicate data, while LWIP may use IP payloads to communicate data. Another difference is that LWA and LWIP have different system architectures. In particular, LWIP architecture is designed to utilize legacy WiFi infrastructure, while LWA may require significant enhancements to WLAN infrastructure, security capabilities, and flow control mechanisms. Yet another difference is that LWIP is able to transmit uplink data over unlicensed spectrum, while LWA is one of several schemes focused on enhancing LTE downlink capability.

One proposal for LWIP backhaul connection is to simply reuse the Xw interface for LWIP/erlwip without any substantial change. Due to the various differences between LWA and LWIP/LWIP previously described, reusing the same Xw interface for LWIP/LWIP may introduce problems such as increased UE and eNB complexity, increased signaling overhead, implementation difficulties for WiFi device manufacturers or vendors, and so forth.

Drawings

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

FIG. 1A illustrates an example system architecture of a network, in accordance with various embodiments.

Fig. 1B illustrates a radio level integration (LWIP) architecture of an example LTE/WLAN over IPsec tunnel, in accordance with various embodiments.

FIG. 2 illustrates example components of an electronic device, according to various embodiments.

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

Fig. 4 illustrates an example interface of baseband circuitry, according to some embodiments.

Fig. 5 depicts a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments.

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

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

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

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

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

Fig. 10 illustrates an example LWIP tunnel setup and data bearer configuration procedure, in accordance with various embodiments.

Fig. 11 illustrates an example WLAN resource reconfiguration process in accordance with various embodiments.

Fig. 12 illustrates an example LWIP tunnel release procedure, in accordance with various embodiments.

Fig. 13 illustrates an example process for transmitting downlink user data in accordance with various embodiments, and an example process for communicating a downlink data delivery status in accordance with various embodiments.

Fig. 14 illustrates another example process of LWIP operation, in accordance with various embodiments.

Fig. 15 illustrates another example process of LWIP operation, in accordance with various embodiments.

Fig. 16 illustrates yet another example process of LWIP operation, in accordance with various embodiments.

Detailed Description

The embodiments discussed herein relate to a user plane interface between an evolved NodeB (eNB) and an LTE/WLAN through a radio level integration (LWIP) -security gateway (SeGW) of an IPsec tunnel. The user plane interface may provide data transfer functions (uplink and downlink) and flow control services. In an embodiment, the user plane interface may terminate at the eNB and the LWIP-SeGW and may be used to communicate LWIP encapsulation protocol (LWIP Encapsulation Protocol, LWIPEP) -protocol data units (protocol data unit, PDUs) over a single general packet radio system tunneling protocol (General Packet Radio System Tunneling Protocol, GTP) bearer between the eNB and the LWIP-SeGW. Other embodiments may be described and/or claimed.

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

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

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

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

Example embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel, concurrently, or simultaneously. Further, the order of the operations may be rearranged. The process may terminate when its operations are completed, but may also have additional steps not included in the figures. The process may correspond to a method, a function, a procedure, a subroutine, etc. When a process corresponds to a function, its termination may correspond to the function returning to the function making the call and/or the main function.

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

As used herein, the term "circuitry" refers to, is part of, or includes, hardware components such as the following configured to provide the described functionality: electronic circuitry, logic circuitry, processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), application Specific Integrated Circuit (ASIC), field Programmable Device (FPD) (e.g., field Programmable Gate Array (FPGA), programmable Logic Device (PLD), complex PLD (CPLD), high-capacity PLD (hcld), structured ASIC, or programmable system-on-a-chip (SoC)), or the like. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functions.

As used herein, the term "processor circuit" may refer to, be part of, or include the following: the circuitry is capable of sequentially and automatically performing a sequence of arithmetic or logical operations; digital data is recorded, stored, and/or transmitted. The term "processor circuit" may refer to one or more application processors, one or more baseband processors, a physical Central Processing Unit (CPU), a single core processor, a dual core processor, a tri-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer executable instructions such as program code, software modules, and/or functional processes.

As used herein, the term "interface circuit" may refer to, be part of, or include circuitry that supports the exchange of information between two or more components or devices. The term "interface circuitry" may refer to one or more hardware interfaces (e.g., a bus, an input/output (I/O) interface, a peripheral component interface, a network interface card, etc.).

As used herein, the term "user equipment" or "UE" may refer to a device that has radio communication capabilities and may describe a remote user of network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with, and may sometimes be referred to hereinafter as: a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio, reconfigurable mobile device, etc. Furthermore, the term "user equipment" or "UE" may include any type of wireless/wired device, such as consumer electronics, cellular phones, smart phones, feature phones, tablet computers, wearable computer devices, personal digital assistants (personal digital assistant, PDA), desktop computers, laptop computers, in-vehicle infotainment (in-vehicle infotainment, IVI), in-vehicle entertainment (in-car entertainment, ICE) devices, dashboard (Instrument Cluster, IC), head-up display (HUD) devices, on-board diagnostics (onboard diagnostic, OBD) devices, dashboard surface mobile devices (dashtop mobile equipment, DME), mobile data terminals (mobile data terminal, MDT), electronic engine management systems (Electronic Engine Management System, EEMS), electronic/engine control units (electronic/engine control unit, ECU), electronic/engine control modules (electronic/engine control module, ECM), embedded systems, microcontrollers, control modules, engine management systems (engine management system, networking), or "smart" devices, machine-to-machine-type communication, machine-to-Machine (MTC) devices, machine-to-machine-EMS (Internet of Things ), machine-to-machine (Internet of Things ) devices, etc.

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

As used herein, the term "channel" may refer to any transmission medium, whether tangible or intangible, used to transmit data or a data stream. The term "channel" may be synonymous and/or equivalent to "communication channel," "data communication channel," "transport channel," "data transport channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," and/or any other similar term indicating a channel or medium through which data is transmitted. Furthermore, the term "link" may refer to a connection between two devices through a radio access technology (Radio Access Technology, RAT) in order to send and receive information.

Fig. 1A illustrates an architecture of a system 100 of a network, according to some embodiments. The following description is provided in connection with an example system 100 operating in conjunction with the Long Term Evolution (LTE) standard provided by the 3 rd generation partnership project (3 GPP) Technical Specification (TS). However, the example embodiments are not limited thereto and the embodiments described may be applied to other networks that benefit from the principles described herein, such as fifth generation (5G) or New Radio (NR) systems, and so forth.

The system 100 is shown to include a User Equipment (UE) 101 and a UE 102. The UEs 101 and 102 are shown as smart phones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as personal data assistants (Personal Data Assistant, PDAs), pagers, laptop computers, desktop computers, wireless handsets, or any computing device that includes a wireless communication interface.

In some embodiments, either of the UEs 101 and 102 may include an IoT UE that may include a network access layer designed for low power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies such as M2M or MTC to exchange data with MTC servers or devices via public land mobile networks (public land mobile network, PLMNs), proximity-Based services (ProSe) or device-to-device (D2D) communications, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. IoT network descriptions interconnect IoT UEs with short-term connections, which may include uniquely identifiable embedded computing devices (within the internet infrastructure). The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

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

In this example, UE 102 is shown configured to access an Access Point (AP) 106 via a connection 107. Connection 107 may comprise a logical wireless connection, such as a connection conforming to any IEEE 802.11 protocol, where AP 106 may comprise a Wireless Local Area Network (WLAN) device, such as a wireless fidelity @, for example

) And a router. In this example, the AP 106 is shown connected to the internet, rather than to the core network of the wireless system (described in more detail below). The UE 102 and the AP 106 (also referred to as "WLAN node 106", "WLAN entity 106", "WLAN 106", etc.) may use the internet protocol security (IPsec) protocol to divide packets (e.g., internet Protocol (IP)) sent over the connection 107Group) authentication and encryption. In various embodiments, UE 102 may be configured for radio level integration (LWIP) over IPsec tunnels using LTE/WLAN, where UE 102 may use WLAN radio resources (e.g., connection 107) via IPsec tunneling. IPsec tunneling may involve encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet. An example architecture for LWIP is illustrated by fig. 1B.

Referring to fig. 1B, which depicts an example LWIP architecture 100B, a ue 102 may transmit data using LWIP. The LWIP feature may allow UE 102 in the rrc_connected state to be configured by RAN node 111/112 to utilize WLAN radio resources via IPsec tunneling. In fig. 1B, like numbered items are the same or similar to those discussed elsewhere herein. As shown, the architecture 100B includes an LWIP-security gateway (LWIP-SeGW) 150 in addition to the UE 102, RAN nodes 111/112, AP 106, and MME/S-GW 121/122 previously discussed.

Connectivity between the RAN nodes 111/112 and the LWIP-SeGW 150 is provided by an interface 155, which interface 155 may include a user plane interface and a control plane interface (not shown in fig. 1B). Connectivity between the LWIP-SeGW 150 and the UE102 via the WLAN 106 may be provided by the IPsec tunnel 117. The IPsec tunnel 117 may include a connection 107 between the UE102 and the WLAN 106, and a link 157 between the WLAN 106 and the LWIP-SeGW 150. The IPsec tunnel 117 may be established after exchanging security information between the RAN nodes 111/112 and the LWIP-SeGW 150 during an LWIP addition preparation procedure, which is an Xw control plane procedure. The LWIP addition preparation process may also be used to establish LWIP bearers, which may be data bearers to be transported through the LWIP tunnel. The end-to-end (e 2 e) path between UE102 and RAN nodes 111/112 via WLAN 106 is referred to as LWIP tunnel 160.

To utilize LWIP, RAN node 111/112 may configure UE102 to transmit Uplink (UL) data using WLAN signaling (e.g., over connection 107) or using LTE signaling (e.g., over link 104). If routed via WLAN 106, all UL traffic for the data bearer may be load transferred to WLAN 106.RAN node 111/112 may use radio resource control (Radio Resource Control, RRC) signaling to configure UE102 for LWIP. For example, the RAN node 111/112 may send an rrcconnectionreconfigurationmessage to provide the necessary parameters for the UE102 to initiate establishment of an IPsec tunnel for a data radio bearer (data radio bearer, DRB) of the LTE network. When the IPsec tunnel 117 is established, the data bearer may be configured to use LWIP resources. The LWIP resources may be WLAN resources for the LWIP tunnel 160 or for use over the LWIP tunnel 160. The data bearer may be an evolved packet system (Evolved Packet System, EPS) bearer mapped to a DRB maintained on the LTE side.

When aggregation over LWIP is enabled for UL and/or Downlink (DL) data, the corresponding UL and/or DL packets and LTE signaling sent through the LWIP tunnel 160 are encapsulated using the LWIP encapsulation protocol (LWIPEP) discussed in more detail with reference to fig. 8. In this way, the RAN nodes 111/112 may not need to interpret the IP packets from the UE 102. To transport data through the LWIP tunnel 160, IP packets to be transmitted between the UE 102 and the LWIP-SeGW 150 may be encapsulated with IPsec to provide security to packets traversing the WLAN 106. The IP packets may then be transmitted between the LWIP-SeGW 150 and the RAN nodes 111/112 via the interface 155.

According to various embodiments, a single IPsec tunnel 117 is used for each UE for all data bearers configured to transmit and/or receive data over WLAN 106. The data corresponding to each IPsec tunnel 117 is transported over interface 155 over a single general packet radio service (General Packet Radio Service, GPRS) tunneling protocol (GPRS Tunneling Protocol for the user plane, GTP-U) tunnel for the user plane. Each data bearer may be configured such that traffic for that bearer may be routed over IPsec tunnel 117 in WLAN 106 in only the downlink, only the uplink, or both the uplink and the downlink. Furthermore, the signaling radio bearers (signaling radio bearer, SRB) may be carried only on LTE signaling, and the RAN node 111/112 may configure the particular bearer(s) to use the IPsec tunnel 117.

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

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

The Xw user plane protocol (L-Xw-UP) for LWIP may also be used to provision the specific UE configured with LWIP bearer options with L-Xw-UP specific Sequence Number (SN) information for user data transferred from the RAN node 111/112 to the LWIP-SeGW 150; generating and providing information for successful transmission of LWIP PDUs from the LWIP-SeGW150 and/or the WLAN106 to the UE for user data of the UE configured with the LWIP bearer option; generating and providing information of LWIP PDU not transmitted to UE; generating and providing information of a current expected buffer size at the LWIP-SeGW150 and/or the WLAN106 for transmitting user data to the UE for a particular UE configured with LWIP bearer options; information of a current minimum expected buffer size for transmitting user data to the UE for the UE configured with LWIP bearer options at the LWIP-SeGW150 and/or the WLAN106 is generated and provided. Additionally, the LWIP Xw interface 155 may be different from the LWA Xw interface at least in the following respects.

The first difference between the LWIP Xw interface 155 and the LWA Xw interface is that the end points of the LWIP Xw interface 155 are the LWIP-SeGW150 and the RAN node 111/112, rather than the WLAN Termination (WT) entity and the RAN node 111/112 as in LWA. Because of this difference, if the LWA Xw interface is to be reused for LWIP, further changes to the LWIP architecture may be required to include WTs. This may introduce further complexity to the eNB RAN node implementation.

A second difference between LWIP Xw interface 155 and LWA Xw interface is that LWA and LWIP use different payloads. Specifically, LWA uses PDCP Protocol Data Units (PDUs) while LWIP uses IP packets. The use of PDCP PDUs in LWA allows for a one-to-one mapping between PDCP PDU SNs and LWA Xw SNs. Thus, if the LWA Xw interface is to be reused for LWIP, a one-to-one mapping between PDCP PDU SN and LWA Xw SN is not possible and may require further complexity for packet reordering.

A third difference between the LWIP Xw interface 155 and the LWA Xw interface is that the flow control mechanism for the LWIP Xw interface 155 is per UE, not per bearer as is the case with LWA implementations. One reason for this difference is that LWA flow control is defined to prevent de-synchronization (de-sync) of PDCP superframe numbers (Hyper Frame Number, HFN). Since the LWIP payload includes IP packets and does not include PDCP PDUs (as is the case with LWA), the PDCP HFN desynchronization problem is less likely to occur. However, the current LWIP standard requires that any LWIP solution support legacy WLAM deployments without requiring any modification to the deployed WLAN nodes. Because per bearer flow control mechanisms will require WLAN infrastructure changes, reuse of the LWA Xw interface for LWIP implementations is not allowed.

In an embodiment, the RAN node 111/112 may be connected to the LWIP-SeGW 150 via an LWIP Xw interface 155. Although not shown in fig. 1B, the RAN node 111/112 may be connected to a plurality of LWIP-segws 150 through respective LWIP Xw interfaces 155. In some embodiments, the LWIP-SeGW 150 may be implemented in or by a separate physical entity. In other embodiments, the LWIP-SeGW 150 may be implemented as a function or logical entity within the RAN 110 or RAN nodes 111/112, e.g., by using network function virtualization, container (container), etc.

The LWIP-SeGW 150 may support a subset of WT functions and additional/alternative functions required to support LWIP. The LWIP-SeGW 150 may be placed between the RAN node 111/112 and the WLAN network for security of packets traversing the WLAN 106 and protecting the network operator network. In addition, network domain security (Network Domain Security, NDS)/IP network layer security, etc., may be utilized to protect the confidentiality and integrity of communications between the RAN node 111/112 and the LWIP-SeGW 150 over the LWIP Xw interface 155.

In addition to terminating the IPsec tunnel 117 from the UE 102, the LWIP-SeGW 150 may also perform rate limiting on the RAN nodes 111/112 and their backhaul links to enable denial of service (Denial of Service, doS) and/or distributed DoS (DDoS) protection. The UE 102 and the LWIP-SeGW 150 may perform mutual authentication during the establishment of the IPsec tunnel 117 using an authentication key derived from an Access Stratum (AS) security association. In an example, mutual authentication may be performed in phase 2 of an internet key exchange protocol version 2 (Internet Key Exchange Protocol Version, ikev 2) handshake. In this example, the RAN node 111/112 may inform the LWIP-SeGW 150 that the intended initiation of the IKEv2 handshake by the UE 102 is followed by establishment of the IPsec tunnel 117. To inform the LWIP-SeGW 150 of the intended initiation of the IKEv2 handshake, the LWIP-SeGW 150 may be informed of the initiator identifier value (Initiator identifier value, IDi) that the ue 102 will use in the IKEv2 handshake, as well as the LWIP Pre-shared Key (PSK).

The LWIP-SeGW 150 may also implement the binding of the authenticated UE 102 to its IP address and apply anti-spoofing measures on the received packets for the UE 102 external and internal IP source addresses. The LWIP-SeGW 150 may also ensure that uplink traffic sent by the UE 102 is only sent to the correct RAN node 111/112 by conveying the traffic to the GTP-U tunnel via the L-Xw-UP interface 155.

Referring back to fig. 1A, radio Access Network (RAN) 110 may include one or more access nodes that enable connections 103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BSs), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, roadside units (RSUs), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a certain geographic area (e.g., cell). RAN 110 may include one or more RAN nodes, such as macro RAN node 111, for providing macro cells and one or more RAN nodes, such as Low Power (LP) RAN node 112, for providing femto cells or pico cells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidths than macro cells).

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

According to some embodiments, UEs 101 and 102 may be configured to communicate with each other or any of RAN nodes 111 and 112 using orthogonal frequency division multiplexing (Orthogonal Frequency-Division Multiplexing, OFDM) communication signals over multicarrier communication channels in accordance with various communication techniques such as, but not limited to, orthogonal frequency division multiple access (Orthogonal Frequency-Division Multiple Access, OFDMA) communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (Single Carrier Frequency Division Multiple Access, SC-FDMA) communication techniques (e.g., for uplink and ProSe or side-road communications), although the scope of the embodiments is not limited in this respect. The OFDM signal may comprise a plurality of orthogonal subcarriers.

In some embodiments, the downlink resource grid may be used for downlink transmissions from either of RAN nodes 111 and 112 to UEs 101 and 102, while uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which is a physical resource in the downlink in each time slot. This time-frequency plane representation is a common practice of OFDM systems and thus intuitive for radio resource allocation. Each column and first row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in the radio frame. The smallest time-frequency unit in the resource grid is denoted as a resource element. Each resource grid comprises several resource blocks, which describe the mapping of specific physical channels to resource elements. Each resource block includes a set of resource elements; in the frequency domain, this may represent the minimum number of resources that are currently allocable. There are several different physical downlink channels that utilize such resource block transport.

The physical downlink shared channel (physical downlink shared channel, PDSCH) may carry user data and higher layer signaling to the UEs 101 and 102. The physical downlink control channel (physical downlink control channel, PDCCH) may carry information about transport formats and resource allocations related to the PDSCH channels, and so on. It may also inform the UEs 101 and 102 about transport format, resource allocation and H-ARQ (hybrid automatic repeat request) information related to the uplink shared channel. In general, downlink scheduling (assigning control and shared channel resource blocks to UEs 102 within a cell) may be performed at either of RAN nodes 111 and 112 based on channel quality information fed back from either of UEs 101 and 102. The downlink resource assignment information may be sent on the PDCCH for (e.g., assigned to) each of the UEs 101 and 102.

The PDCCH may use control channel elements (control channel element, CCEs) to carry control information. The PDCCH complex-valued symbols may first be organized into four tuples before being mapped to resource elements, which may then be transposed with a sub-block interleaver for rate matching. Each PDCCH may be transmitted with one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements referred to as resource element groups (resource element group, REGs). Four quadrature phase shift keying (Quadrature Phase Shift Keying, QPSK) symbols may be mapped for each REG. Depending on the size of the downlink control information (downlink control information, DCI) and channel conditions, PDCCH may be transmitted with one or more CCEs. Four or more different PDCCH formats may be defined in LTE, with different numbers of CCEs (e.g., aggregation level l=1, 2, 4, or 8).

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

RAN 110 is shown communicatively coupled to a Core Network, in this embodiment Core Network (CN) 120 (e.g., evolved packet Core (Evolved Packet Core, EPC)), via S1 interface 113. In this embodiment, the S1 interface 113 is split into two parts: an S1-U interface 114 that carries traffic data between RAN nodes 111 and 112 and a serving gateway (S-GW) 122; and an S1 mobility management entity (mobility management entity, MME) interface 115, which is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this embodiment, EPC network 120 includes MME121, S-GW 122, packet data network (Packet Data Network, PDN) gateway (P-GW) 123, and home subscriber server (home subscriber server, HSS) 124.MME 121 may be similar in function to the control plane of a legacy serving general packet radio service (General Packet Radio Service, GPRS) support node (Serving GPRS Support Node, SGSN). MME121 may manage mobility aspects in the access such as gateway selection and tracking area list management. HSS 124 may include a database for network users including subscription related information to support the handling of communication sessions by network entities. The EPC network 120 may include one or several HSS 124 depending on the number of mobile subscribers, the capacity of the devices, the organization of the network, etc. For example, HSS 124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location compliance, and so on.

S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and EPC network 120. Furthermore, S-GW 122 may be a local mobility anchor point for inter-RAN node handover and may also provide anchoring for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The P-GW123 may terminate the SGi interface towards the PDN. The P-GW123 may route data packets between the EPC network 120 and external networks, such as a network that includes an application server 130 (or application functions (application function, AF)), via an Internet Protocol (IP) interface 125. In general, the application server 130 may be an element (e.g., UMTS Packet Service (PS) domain, LTE PS data Service, etc.) that provides applications using IP bearer resources with the core network. In this embodiment, P-GW123 is shown communicatively coupled to application server 130 via IP communication interface 125. The application server 130 may also be configured to support one or more communication services (e.g., voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 101 and 102 via the EPC network 120.

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

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

The application circuitry 205 may include one or more Central Processing Unit (CPU) cores and one or more of the following: cache memory, low drop-out (LDO) voltage regulators, interrupt controllers, serial interfaces such as SPI, I2C or universal programmable serial interface modules, real Time Clock (RTC), timer-counters including interval and watchdog timers, universal input/output (I/O or IO), memory card controllers such as Secure Digital (SD)/multimedia card (MultiMediaCard, MMC), universal serial bus (Universal Serial Bus, USB) interfaces, mobile industrial processor interface (Mobile Industry Processor Interface, MIPI) interfaces and joint test access group (Joint Test Access Group, JTAG) test access ports. In some embodiments, user interface 250 may include one or more of the following: a physical or virtual button, such as a reset button; one or more indicators, such as light emitting diodes (light emitting diode, LEDs); and a display screen. As an example, the application circuitry 205 may include one or more intels

Or->

A processor; ultra-micro semiconductor (Advanced Micro Devices, AMD)/(micro-devices)>

Processor, acceleration processing unit (Accelerated Processing Unit, APU) or +.>

A processor; etc.

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

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

Memory 220 may include one or more of the following: volatile memory, including dynamic random access memory (dynamic random access memory, DRAM) and/or synchronous dynamic random access memory (synchronous dynamic random access memory, SDRAM); and non-volatile memory (nonvolatile memory, NVM), including high-speed electrically erasable memory (commonly referred to as flash memory), phase-change random access memory (phase change random access memory, PRAM), magnetoresistive random access memory (magnetoresistive random access memory, MRAM), and/or three-dimensional cross-point memory. Memory 220 may be implemented as one or more of a soldered-in packaged integrated circuit, a socket memory module, and a plug-in memory card.

The power management integrated circuit (power management integrated circuitry, PMIC) 225 may include a voltage regulator, a surge protector, a power alarm detection circuit, and one or more backup power sources such as a battery or a capacitor. The power alarm detection circuit may detect one or more of a power down (under voltage) and surge (over voltage) condition. The power tee circuit 230 may provide power drawn from the network cable to provide both power supply and data connectivity to the infrastructure equipment 200 using a single cable.

The network controller 235 may provide connectivity to the network using standard network interface protocols, such as Ethernet, GRE tunnel-based Ethernet, multiprotocol label switching (Multiprotocol Label Switching, MPLS) based Ethernet, or some other suitable protocol. Network connectivity may be provided to/from the infrastructure equipment 200 using physical connections, which may be electrical (commonly referred to as "copper interconnects"), optical, or wireless.

The positioning circuitry 245 may include circuitry to receive and decode signals transmitted by one or more navigation satellite constellations. Examples of navigation satellite constellations can include the global positioning system (global positioning system, GPS), the global navigation satellite system (Globalnaya Navigatsionnaya Sputnikovaya Sistema, GLONASS), galileo and/or beidou. The positioning circuit 245 may provide data to the application circuit 205, which may include one or more of location data or time data. The application circuit 205 may use the time data to operate in synchronization with other radio base stations.

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

The application circuitry 302 may include one or more application processors 302A. For example, application circuitry 302 may include circuitry such as, but not limited to, the following: one or more single-core or multi-core processors, microprocessors, multi-threaded processors, and ultra-low powerA press processor, an embedded processor, or other known processing element. Processor(s) 302A may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The application processor 302A may be coupled with a memory/storage 302B (also referred to as a "computer-readable medium 302B" or the like) or may include the memory/storage 302B and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 300. In some embodiments, the processor of application circuit 302 may process IP data packets received from the EPC. By way of example, application circuitry 302 may include one or more Intel

Or Core->

A processor; a series, S series, W series, etc. processors provided by apple corporation; high pass->

A processor; three stars

A processor; etc.

Memory/storage 302B may include any number of memory devices for providing a given amount of system memory. As an example, memory 302B may include a Random Access Memory (RAM) designed according to the joint electronic device engineering council (Joint Electron Devices Engineering Council, JEDEC) Double Data Rate (DDR) or low power double data rate (low power double data rate, LPDDR). In various implementations, the individual memory devices may be formed from any number of different package types, such as a single chip package (single die package, SDP), a Dual Die Package (DDP), or a quad die package (Q17P), a dual in-line memory module (dual inline memory module, DIMM) (e.g., micro DIMM or MiniDIMM) And/or any other similar memory device. To provide persistent storage of information, such as data, applications, operating systems, etc., the memory/storage 302B may include one or more mass storage devices, such as solid state disk drives (solid state disk drive, SSDD); flash memory cards, such as SD cards, microSD cards, xD picture cards, etc., and USB flash drives; on-chip memory or registers associated with the processor 302A (e.g., in a low power implementation); a micro Hard Disk Drive (HDD); from

And->

Three-dimensional cross point (3 DXPOINT) memory, and so forth.

Baseband circuitry 304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 304 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 306 and generate baseband signals for the transmit signal path of RF circuitry 306. Baseband processing circuitry 304 may interface with application circuitry 302 to generate and process baseband signals and control the operation of RF circuitry 306. For example, in some embodiments, the baseband circuitry 304 may include a third generation (3G) baseband processor 304A, a fourth generation (4G) baseband processor 304B, a fifth generation (5G) baseband processor 304C, or other baseband processor(s) 304D for other existing generations, generations in development, or generations to be developed in the future (e.g., second generation (2G), sixth generation (6G), etc.). Baseband circuitry 304 (e.g., one or more of baseband processors 304A-D) may handle various radio control functions that enable communication with one or more radio networks via RF circuitry 306. In other embodiments, some or all of the functionality of baseband processors 304A-D may be included in modules stored in memory 304G and executed via Central Processing Unit (CPU) 304E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency offset, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 304 may include Fast fourier transform (Fast-Fourier Transform, FFT), precoding, or constellation mapping/demapping functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 304 may include convolution, tail-biting convolution, turbo, viterbi, or low density parity check (Low Density Parity Check, LDPC) encoder/decoder functionality. Embodiments of the modem and encoder/decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

In some embodiments, the baseband circuitry 304 may include one or more audio digital signal processors (digital signal processor, DSP) 304F. The audio DSP(s) 304F 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, a single chipset, or in some embodiments arranged on the same circuit board. In some embodiments, some or all of the constituent components of baseband circuitry 304 and application circuitry 302 may be implemented together, for example, on a system on a chip (SOC), an integrated circuit, or a single package.

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

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

In some embodiments, the receive signal path of RF circuit 306 may include mixer circuit 306A, amplifier circuit 306B, and filter circuit 306C. In some embodiments, the transmit signal path of RF circuit 306 may include filter circuit 306C and mixer circuit 306A. RF circuitry 306 may also include synthesizer circuitry 306D for synthesizing frequencies for use by mixer circuitry 306A of the receive signal path and the transmit signal path. In some embodiments, mixer circuit 306A of the receive signal path may be configured to down-convert the RF signal received from FEM circuit 308 based on the synthesized frequency provided by synthesizer circuit 306D. The amplifier circuit 306B may be configured to amplify the down-converted signal and the filter circuit 306C may be a low-pass filter (LPF) or a band-pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to baseband circuitry 304 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, although this is not a necessary requirement. In some embodiments, mixer circuit 306A 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, mixer circuit 306A of the transmit signal path may be configured to upconvert the input baseband signal based on the synthesized frequency provided by synthesizer circuit 306D to generate an RF output signal for FEM circuit 308. The baseband signal may be provided by baseband circuitry 304 and may be filtered by filter circuitry 306C.

In some embodiments, the mixer circuit 306A of the receive signal path and the mixer circuit 306A of the transmit signal path may comprise two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some embodiments, the mixer circuit 306A of the receive signal path and the mixer circuit 306A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., hartley) image rejection. In some embodiments, the mixer circuit 306A and the mixer circuit 306A of the receive signal path may be arranged for direct down-conversion and direct up-conversion, respectively. In some embodiments, the mixer circuit 306A of the receive signal path and the mixer circuit 306A 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, RF circuit 306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits and baseband circuit 304 may include a digital baseband interface to communicate with RF circuit 306.

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

In some embodiments, synthesizer circuit 306D may be 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 306D may be an incremental sum synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

Synthesizer circuit 306D may be configured to synthesize an output frequency for use by mixer circuit 306A of RF circuit 306 based on the frequency input and the divider control input. In some embodiments, synthesizer circuit 306D may be a fractional N/N+1 synthesizer.

In some embodiments, the frequency input may be provided by a voltage controlled oscillator (voltage controlled oscillator, VCO), although this is not a necessary requirement. The divider control input may be provided by the baseband circuitry 304 or the application processor 302, 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 a channel indicated by the application processor 302.

Synthesizer circuit 306D of RF circuit 306 may include a frequency divider, a delay-locked loop (DLL), a multiplexer, and a phase accumulator. In some embodiments, the frequency divider may be a dual-mode frequency divider (dual modulus divider, DMD) and the phase accumulator may be a digital phase accumulator (digital phase accumulator, DPA). In some embodiments, the DMD may be configured to divide the 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 Nd equal phase packets, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuit 306D may be configured to generate a carrier frequency as the output frequency, while in other embodiments the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used with quadrature generator and divider circuits to generate a plurality of signals at the carrier frequency having a plurality of mutually different phases. In some embodiments, the output frequency may be an LO frequency (fLO). In some embodiments, RF circuit 306 may include an IQ/polarity converter.

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

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

In some embodiments, the PMC may manage the power provided to baseband circuitry 304. In particular, the PMC may control power supply selection, voltage scaling, battery charging, or DC-to-DC conversion. PMCs may often be included when the device 300 is capable of being battery powered, such as when the device is included in an RE, UE, or the like. PMCs can increase power conversion efficiency while providing desired implementation size and heat dissipation characteristics.

Although fig. 3 shows the PMC coupled only to baseband circuitry 304. However, in other embodiments, the PMC may additionally or alternatively be coupled with and perform similar power management operations for other components, such as, but not limited to, the application circuitry 302, the RF circuitry 306, or the FEM 308.

In some embodiments, the PMC may control or otherwise be part of various power saving mechanisms of the device 300. For example, if the device 300 is in an RRC Connected state that is still Connected to the RAN node because it is expected to receive traffic soon, it may enter a state called discontinuous reception mode (Discontinuous Reception Mode, DRX) after a period of inactivity. During this state, the apparatus 300 may be powered down for a brief interval and thereby save power.

If there is no data traffic activity for a longer period of time, the device 300 may transition to a shut down to an RRC Idle state in which it is disconnected from the network and no operations such as channel quality feedback, handover, etc. are performed. The device 300 enters a very low power state and it performs paging in which it wakes up again periodically to listen to the network and then powers down again. The device 300 may not 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 may allow the device to be unavailable to the network for periods longer than the paging interval (varying from seconds to hours). During this time, the device is completely unreachable to the network and may be completely powered down. Any data transmitted during this time suffers from a large delay and the delay is assumed to be acceptable.

The processor of the application circuit 302 and the processor of the baseband circuit 304 may be used to execute elements of one or more instances of the protocol stack. As used herein, the term "instantiation" and the like may refer to the creation of an instance, and "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. For example, the processor of baseband circuitry 304 may be used, alone or in combination, to perform layer 3, layer 2, or layer 1 functions, while the processor of baseband circuitry 304 may utilize data (e.g., packet data) received from these layers and further perform layer 4 functions (e.g., transport communication protocol (transmission communication protocol, TCP) and user datagram protocol (user datagram protocol, UDP) layers). For the purposes mentioned herein, layer 3 may include a Radio Resource Control (RRC) layer, which is described in more detail below. For the purposes mentioned herein, layer 2 may include a medium access control (medium access control, MAC) layer, a radio link control (radio link control, RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, which are described in more detail below. For the purposes mentioned herein, layer 1 may include a Physical (PHY) layer of the UE/RAN node, which is described in more detail below.

Fig. 4 illustrates an example interface of baseband circuitry, according to some embodiments. As described above, the baseband circuitry 304 of FIG. 3 may include processors 304A-304E and memory 304G utilized by the processors. Each of the processors 304A-304E may include a memory interface 304A-304E, respectively, to send and receive data to and from a memory 304G.

Baseband circuitry 304 may also include one or more interfaces to communicatively couple to other circuits/devices, such as a memory interface (e.g., an interface to send/receive data to/from memory external to baseband circuitry 304), an application circuit interface (e.g., an interface to send/receive data to/from application circuit 302 of fig. 3), an RF circuit interface (e.g., an interface to send/receive data to/from RF circuit 306 of fig. 3), a wireless hardware connectivity interface (e.g., to/from a near field communication (Near Field Communication, NFC) component),

Components (e.g. low energy consumption->

)、/>

An interface for the components and other communication components to send/receive data) and a power management interface (e.g., an interface to send/receive power or control signals to/from the PMC).

Fig. 5 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments. In an embodiment, the hardware resource 500 may be used in or as any of the elements, devices, components, etc. discussed with reference to fig. 1A, 1B, 2, 3, and 4. In particular, fig. 5 shows a diagrammatic representation of a hardware resource 500, the hardware resource 500 including one or more processors (or processor cores) 510, one or more memory/storage devices 520, and one or more communication resources 530, each of which may be communicatively coupled via a bus 540. For embodiments that utilize node virtualization (e.g., NFV, or when hardware resources 500 are used in or as core network elements or RAN nodes/elements), hypervisor 502 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize hardware resources 500.

The processor 510 (e.g., central processing unit (central processing unit, CPU), reduced instruction set computing (reduced instruction set computing, RISC) processor, complex instruction set computing (complex instruction set computing, CISC) processor, graphics processing unit (graphics processing unit, GPU), digital signal processor (digital signal processor, DSP) (e.g., baseband processor), application specific integrated circuit (application specific integrated circuit, ASIC), radio frequency integrated circuit (radio-frequency integrated circuit, RFIC), another processor, or any suitable combination of these) may include, for example, a processor 512 and a processor 514.

Memory/storage 520 may include main memory, disk storage, or any suitable combination of these. Memory/storage 520 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (dynamic random access memory, DRAM), static Random Access Memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (electrically erasable programmable read-only memory, EEPROM), flash memory, solid state memory, and/or any other type of memory device technology, such as those discussed herein.

Communication resources 530 may include an interconnect or network interface component or other suitable device to communicate with one or more peripheral devices 504 or one or more databases 506 via network 508. Communication resources 530 may include, for example, wired communication components (e.g., for coupling via a universal serial bus (Universal Serial Bus, USB), a cellular communication component, an NFC component,

Components (e.g. low energy consumption->

)，/>

Components and other communication components.

The instructions 550 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 510 to perform any one or more of the methods discussed herein. The instructions 550 may reside, completely or partially, within at least one of the processors 510 (e.g., within a cache memory of the processor), within the memory/storage device 520, or any suitable combination of these. Further, any portion of instructions 550 may be transferred from any combination of peripherals 504 or databases 506 to hardware resource 500. Thus, the memory of the processor 510, the memory/storage device 520, the peripherals 504, and the database 506 are examples of computer readable and machine readable media.

Fig. 6 is an illustration of a control plane protocol stack according to some embodiments. In this embodiment, control plane 600 is shown as a communication protocol stack between UE 101 (or UE 102), RAN node 111 (or RAN node 112), and MME 121.

PHY layer 601 may transmit or receive information used by MAC layer 602 over one or more air interfaces. PHY layer 601 may also perform link adaptation or adaptive modulation and coding (adaptive modulation and coding, AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers (e.g., RRC layer 605). PHY layer 601 may also perform error detection on the transport channel, forward error correction (forward error correction, FEC) encoding/decoding of the transport channel, modulation/demodulation of the physical channel, interleaving, rate matching, mapping onto the physical channel, and multiple-input multiple-output (Multiple Input Multiple Output, MIMO) antenna processing.

The MAC layer 602 may perform mapping between logical channels and transport channels, multiplexing MAC service data units (service data unit, SDUs) from one or more logical channels onto Transport Blocks (TBs) for delivery to a PHY via transport channels, demultiplexing MAC SDUs from Transport Blocks (TBs) delivered from a PHY via transport channels onto one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction by hybrid automatic repeat request (hybrid automatic repeat request, HARQ), and logical channel prioritization.

The RLC layer 603 may operate in a variety of modes of operation, including: transparent Mode (TM), unacknowledged Mode (Unacknowledged Mode, UM), and acknowledged Mode (Acknowledged Mode, AM). The RLC layer 603 may perform transmission of upper layer protocol data units (protocol data unit, PDUs), error correction by automatic repeat request (automatic repeat request, ARQ) for AM data transmission, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transmission. The RLC layer 603 may also perform RLC data PDU re-segmentation for AM data transfer, reorder RLC data PDUs for UM and AM data transfer, detect duplicate data for UM and AM data transfer, discard RLC SDUs for UM and AM data transfer, detect protocol errors for AM data transfer, and perform RLC re-establishment.

The PDCP layer 604 may perform header compression and decompression of IP data, maintain PDCP Sequence Numbers (SNs), perform in-order delivery of upper layer PDUs at lower layer re-establishment, eliminate duplication of lower layer SDUs at lower layer re-establishment for radio bearers mapped onto RLC AMs, encrypt and decrypt control plane data, perform integrity protection and integrity verification of control plane data, timer-based discard of control data, and perform security operations (e.g., ciphering, deciphering, integrity protection, integrity verification, etc.).

The primary services and functions of the RRC layer 605 may include broadcasting of system information (e.g., included in a master information block (Master Information Block, MIB) or a system information block (System Information Block, SIB) related to a non-access stratum (NAS)), broadcasting of system information related to an Access Stratum (AS), paging, establishment, maintenance and release of RRC connections between the UE and the E-UTRAN (e.g., RRC connection paging, RRC connection establishment, RRC connection modification and RRC connection release), establishment, configuration, maintenance and release of point-to-point radio bearers, security functions including key management, inter-radio access technology (radio access technology, RAT) mobility, and measurement configuration for UE measurement reports. The MIB and SIB may include one or more information elements (information element, IE), each of which may include an individual data field or data structure.

The UE 101 and the RAN node 111 may utilize a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including a PHY layer 601, a MAC layer 602, an RLC layer 603, a PDCP layer 604, and an RRC layer 605.

The non-access stratum (NAS) protocol 606 forms the highest level of control plane between the UE 101 and the MME 121. NAS protocol 606 supports mobility and session management procedures for UE 101 to establish and maintain IP connectivity between UE 101 and P-GW 123.

The S1 application protocol (S1-AP) layer 615 may support the functionality of the S1 interface and includes basic procedures (Elementary Procedure, EP). The EP is a unit of interaction between the RAN node 111 and the CN 120. The S1-AP layer service may include two groups: UE-associated services and non-UE-associated services. These services perform functions including, but not limited to: E-UTRAN radio access bearer (E-UTRAN Radio Access Bearer, E-RAB) management, UE capability indication, mobility, NAS signaling, RAN information management (RAN Information Management, RIM), and configuration transfer.

The Stream Control Transfer Protocol (SCTP) layer (or SCTP/IP layer) 614 may ensure reliable delivery of signaling messages between RAN node 111 and MME 121 based in part on the IP protocols supported by IP layer 613. The L2 layer 612 and the L1 layer 611 may refer to communication links (e.g., wired or wireless) used by the RAN node and MME to exchange information.

RAN node 111 and MME 121 may utilize an S1-MME interface to exchange control plane data via a protocol stack comprising L1 layer 611, L2 layer 612, IP layer 613, SCTP layer 614, and S1-AP layer 615.

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

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

An Internet Protocol (IP) layer 713 (also referred to as an "internet layer") may be used to perform packet addressing and routing functions. IP layer 713 may assign an IP address to the user data packet, for example, in any of IPv4, IPv6, or PPP formats. A General Packet Radio Service (GPRS) tunneling protocol (GTP-U) layer 704 for the user plane may be used to carry user data within the GPRS core network and between the radio access network and the core network. The transmitted user data may be packets in any of, for example, IPv4, IPv6, or PPP formats. The UDP and IP security (UDP/IP) layer 703 may provide a checksum for data integrity, for addressing port numbers for different functions at the source and destination, and encryption and authentication on selected data streams.

RAN nodes 111/112 and S-GW 122 may utilize the S1-U interface to exchange user plane data via a protocol stack comprising L1 layer 511, L2 layer 512, UDP/IP layer 703 and GTP-U layer 704. S-GW 122 and P-GW 123 may utilize an S5/S8a interface to exchange user plane data via a protocol stack comprising layer 1 (L1) layer 611, layer 2 (L2) layer 612, UDP/IP layer 703 and GTP-U layer 704. As described above with respect to FIG. 6, the NAS protocol supports mobility and session management procedures for the UEs 101/102 to establish and maintain IP connectivity between the UEs 101/102 and the P-GW 123.

Fig. 7B is an illustration of an LWIP Xw user plane protocol stack, according to some embodiments. In this embodiment, the LWIP Xw user plane (L-Xw-UP) 700B is a communication protocol that may be defined between the RAN nodes 111/112 and the LWIP-SeGW 150. Transport network layer 715 (also referred to as a "transport layer") may be built on top of IP transport and GTP-U704 may be used above UDP/IP layer 703 (including UDP layer 703a and IP layer 703 b) to carry user plane PDUs (UP-PDUs).

The L-Xw-UP 700B protocol may be used between the RAN node 111/112 and the LWIP-SeGW 150. L-Xw-UP 700B may provide for the non-guaranteed delivery of user plane PDUs, such as the lwipip PDUs discussed herein, wherein a single tunnel is utilized for all LWIP bearers associated with UE 102. The L-Xw-UP 700B protocol may use the services of the transport network layer 715 to allow flow control for user data packets transmitted over the L-Xw-UP interface 155. In an embodiment, various processor circuits (e.g., the processor of application circuit 205/302 and the processor of baseband circuit 210/304) may be used to execute elements of one or more instances of L-Xw-UP 700B, where each L-Xw-UP 700B instance is associated with an individual UE 102 only. In this way, each L-Xw-UP 700B instance may perform various LWIP functions only for its respective UE 102.

L-Xw-UP 700B can provide the following functions: configuring the specific UE102 configured with LWIP bearer options with L-Xw-UP 700B specific SN information for user data transferred from the RAN node 111/112 to the LWIP-SeGW150 (and/or WLAN 106); generating and providing information for the user data of the UE102 configured with LWIP bearer options to successfully transmit LWIPEP PDUs from the LWIP-SeGW150 (and/or WLAN 106) to the UE 102; generating and providing information of LWIPEP PDUs that are not transmitted to the UE 102; generating and providing information at the LWIP-SeGW150 (or WLAN 106) for transmitting the current expected buffer size of user data to the UE102 for the particular UE102 configured with LWIP bearer options; and generating and providing information at the LWIP-SeGW150 (or WLAN 106) for transmitting the current minimum expected buffer size of user data to the UE102 for the particular UE102 configured with LWIP bearer options.

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

In addition, UL data flows may be used to carry DL data delivery status information to RAN nodes 111/112. In some embodiments, transport layer 715 may provide flow control services for data streams. The flow control service may include controlling or managing the rate of data transfer between two nodes (e.g., the LWIP-SeGW 150 and the RAN nodes 111/112) to avoid data buffer overflow or data buffer underflow. In such an embodiment, UL data flows may be used to carry flow control feedback to RAN nodes 111/112. An example process for transmitting DL user data, communicating DL data delivery status information, and communicating flow control feedback information is illustrated by fig. 13.

IP layer 703b may support fragmentation and assembly of GTP packets and may support IPv6 and/or IPv4 address schemes. There may be one or several IP addresses in both the RAN node 111/112 and the LWIP-SeGW 150. The packet processing functions implemented by the RAN nodes 111/112 may send downstream packets corresponding to the UE 102 to the LWIP-SeGW 150 using the IP address of the LWIP-SeGW 150. The packet processing function implemented by the LWIP-SeGW 150 may send upstream packets to the RAN node 111/112 using the IP address of the RAN node 111/112, which may be received over the Xw control plane. The transport layer address notified in the Xw control plane message may be a bit string of 32 bits in case of using IPv4 addressing or a bit string of 128 bits in case of using IPv6 addressing.

The data link layer (or layer 2) 612 may include any data link protocol that meets the requirements of the upper layers and may include a logical link sub-layer and/or a MAC sub-layer (e.g., the previously discussed MAC layer 602 and/or the WLAN MAC layer 802 discussed below). The physical link layer (or layer 1) 611 may comprise any physical layer protocol that meets the requirements of the upper layers, and may comprise physical link sublayers (e.g., the previously discussed PHY layer 601 and/or the WLAN PHY layer 801 discussed below).

Fig. 8 is an illustration of an LWIP protocol architecture 800, according to some embodiments. In this example, the LWIP protocol architecture 800 is shown as a communication protocol stack between the UE 102, the WLAN 106, the LWIP-SeGW150 and the RAN nodes 111/112. Furthermore, LWIP protocol architecture 800 may utilize at least some of the same protocol layers as control plane 600 and user plane 700A, which may operate in the same manner as previously described, but with the following modifications. In addition, LWIP protocol architecture 800 also includes LWIPEP entity 810 at both UE 102 and RAN nodes 111/112, and WLAN PHY layer 801 and WLAN MAC layer 802 at UE 102.

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

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

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

As previously described, LWIP tunnel 160 may include L-Xw-UP interface 155 and IPsec tunnel 117. In an embodiment, the IPsec tunnel 117 may be a UE-specific IPsec security association tunnel established between the UE 102 and the public IP address 850 of the LWIP-SeGW150 ("public ip@850" in fig. 8) in tunnel mode. Furthermore, the RAN nodes 111/112 and/or the LWIP-SeGW150 may communicate with each other through GTP-U protocol means. This may include a GTP-U tunnel identified with the private IP address 811/812 of the RAN node 111/112 ("private IP@811/812" in FIG. 8), the TEID and UDP port number, and with the IP address (public IP@850 or another private IP address) of the LWIP-SeGW150, the TEID and UDP port number. In some implementations, the GTP-U protocol means may include an Xw RAN container GTP-U extension header. The Xw RAN container GTP-U extension header may be sent in the G-PDU over the LWIP Xw user plane interface 155 between the eNB and the LWIP-SeGW 150.

The LWIPEP entity 810 may be responsible for encapsulating IP packets according to the LWIP encapsulation protocol for transmission over the LWIP tunnel 160 and for decapsulating IP packets received over the LWIP tunnel 160. The LWIPEP entity 810 responsible for decapsulating the LWIPEP PDUs is called a LWIP receiver, and the LWIPEP entity 810 responsible for encapsulating the LWIPEP SDUs is called a LWIP transmitter. The PDUs generated by the LWIPEP entity 810 for transmission over the WLAN are referred to as "LWIP PDUs", "LWIPEP PDUs", "LWIP data PDUs", and so on.

The LWIPEP data PDU may include a LWIPEP header and a LWIPEP SDU. The LWIPEP header may be a Generic Routing Encapsulation (GRE) header specified by d.farinacci et al, "Generic Routing Encapsulation (GRE)", internet Engineering Task Force (IETF), request for comments (RFC) 2784 (2000) and/or g.dommety, "Key and Sequence Number Extensions to GRE", IETF, RFC 2890 (2000). The LWIPEP header may have a fixed size of eight bytes (if only the "key" field is included) or twelve bytes (if both the "key" and "sequence number" fields are included). The LWIPEP transmitter may assign Sequence Numbers (SNs) to all packets and may populate the "sequence number" field of the LWIPEP header with these sequence numbers. The "key" field in the LWIPEP header is filled with the associated data bearer and/or DRB identity of the associated DRB. In some embodiments, the LWIPEP transmitter may set one or more (e.g., 5) least significant bits (least significant bit, LSB) of the key field in the GRE header to the DRB identity associated with the LWIPEP SDU and the remaining most significant bits (most significant bit, MSB) to "0". The LWIPEP transmitter may populate the key field with the DRB identity associated with the load-transferred UL bearer of the UL bearer packet to be transmitted through the LWIP tunnel 160.

The LWIPEP transmitter may receive LWIPEP SDUs from upper layers (e.g., IP layer 713 and/or application layer 714), generate LWIPEP PDUs, and provide the LWIPEP PDUs to lower layers for delivery to peer LWIPEP entity 810 via LWIP tunnel 160. The LWIPEP receiver can receive LWIPEP PDUs from lower layers and reorder/reassemble the corresponding LWIPEP SDUs of the received packets according to the "sequence number" field before delivering them to higher layers.

The LWIPEP PDUs discussed herein may each be a string of bits that are byte-aligned in length (e.g., multiples of 8 bits). In fig. 9A-9C, the bit string may be represented by a table, where the most significant bit is the leftmost bit of the first row of the table, the least significant bit is the rightmost bit of the last row of the table, and more generally the bit string should be read from left to right and then in the order of reading of the rows. The bit order of each parameter field within the LWIPEP PDU is represented by the first and most significant bit of the leftmost bits and the last and least significant bit of the rightmost bits. The LWIPEP SDU is a bit string that is byte aligned in length (e.g., a multiple of 8 bits). The LWIPEP SDU is included into the LWIPEP PDU from the first bit. Only one type of LWIPEP PDU, LWIPEP data PDU, is defined. The LWIPEP PDU may be conveyed in frames having the structure shown in fig. 9A-9C.

Fig. 9A illustrates an example frame format 900A, according to various embodiments. A field having a plurality of bits within one byte has MSBs located at higher bit positions unless otherwise indicated. Furthermore, if a field spans several bytes, the MSB is located in the lower numbered byte. Frame 900A may be sent on L-Xw-UP interface 155 starting with the lowest numbered byte. Within each byte, bits may be sent according to decreasing bit positions (e.g., starting from bit position 7). The spare bits may be set to "0" by the transmitter and may not be checked by the receiver. The header portion of the frame is always an integer number of bytes. The payload portions are byte aligned (by adding "padding" when needed). The receiver may be able to remove the extra blank extension field that may be present at the end of the frame.

Fig. 9B illustrates an example frame format 900B, according to various embodiments. Frame format 900B may be a DL user data frame for conveying DL user data. Frame format 900B may be PDU type 0, with a value of "0" located in the PDU type field. The frame format 900B may be defined to allow the LWIP-SeGW 150 (or WLAN 106) to detect lost L-Xw-UP packets and be associated with the transmission of downlink LWIPEP PDUs over the Xw interface 155.

Fig. 9C illustrates an example frame format 900C, according to various embodiments. Frame format 900C may be used to convey DL data delivery status messages (discussed below). Frame format 900C may be PDU type 1. The frame format 900C may be defined to transmit feedback to allow the RAN node 111/112 to control the downlink user data flow via the LWIP-SeGW 150.

In fig. 9B-9C, the PDU type may indicate the structure of the Xw UP frame. The PDU type field in each of frame formats 900B and 900C may include a value of the PDU type it identifies (e.g., a "0" for PDU type 0 or a "1" for PDU type 1). The PDU type may be located in bits 4 through 7 of the first byte of the frame 900B or 900C. The PDU type field may have a value range of {0 = DL user data, 1 = DL data delivery status, 2-15 = reserved for future PDU type extensions }, and a field length of 4 bits. The spare field may be set to "0" by the transmitter and may not be interpreted by the receiver. This field may be reserved for later versions. This field may have a value range of (0-2 n-1), where n is a number, and a field length of n bits.

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

In fig. 9C, the lost packet report field of fig. 9C may indicate the presence of a list of lost Xw-U packets in a corresponding Xw UP frame. This field may have a value range of {0 = missing frame list not present, 1 = missing frame list present }, and a field length of 1 bit. The final frame indication field may indicate feedback regarding the in-order delivery status of the LWIPEP PDUs to the UE 102 at the LWIP-SeGW 150. This field may have a value range of {0..224-1} and a field length of 3 bytes.

The highest successful delivery Xw-U sequence number field may indicate feedback regarding the in-order transmission status of LWIP PDUs to the UE 102 at the LWIP-SeGW 150 (or WLAN 106). This field may have a value range of {0..224-1} and a field length of 3 bytes.

The desired buffer size of the UE field may indicate the desired buffer size of the particular UE 102. This field may have a value range of {0..232-1} and a field length of 4 bytes. The minimum expected buffer size of the UE field may indicate the minimum expected buffer size of a particular UE 102. This field may have a value range of {0..232-1} and a field length of 4 bytes.

The report missing Xw-U sequence number range number field may indicate the number of Xw-U sequence number ranges reported missing. This field may have a value range of {1..256}, and a field length of 1 byte. The missing Xw-U sequence number range start field may indicate the start of the Xw-U sequence number range. This field may have a value range of {0..218-1} and a field length of 3 bytes. The missing Xw-U sequence number range end field may indicate the end of the Xw-U sequence number range. This field may have a value range of {0..218-1} and a field length of 3 bytes.

Fig. 10-16 illustrate processes 1000-1600, respectively, for reserving resources for V2X SL communications, in accordance with various embodiments. For purposes of illustration, the operations of processes 1000-1600 are described as being performed by the various devices discussed with reference to fig. 1A-5. Some of processes 1000-1600 may include communication between various devices, and it should be understood that such communication may be facilitated by various circuitry described with reference to fig. 1A-5 utilizing various messages/frames, protocols, entities, layers, etc. discussed with reference to fig. 6-9C. In addition, while specific examples and sequences of operations are illustrated in fig. 10-16, the depicted sequence of operations should not be construed as limiting the scope of the embodiments in any way. Rather, the depicted operations may be reordered, broken down into additional operations, combined, and/or omitted entirely while still remaining within the spirit and scope of the present disclosure.

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

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

In an embodiment, the configuration included in rrcconnectionreconfigurations may include instructions or commands to perform WLAN measurements for one or more WLANs 106. In operation 1015, ue 102 may send WLAN measurements to RAN nodes 111/112. In operation 1020, the ran node 111/112 may send an LWIP addition request message to request the LWIP-SeGW 150 to allocate resources, including security materials, etc., for the particular UE 102. In operation 1025, if the LWIP-SeGW 150 is able to approve the tunnel request, the LWIP-SeGW 150 may respond by sending an LWIP add request Acknowledgement (ACK) message to the RAN node 111/112.

In operation 1030, the ran node 111/112 may send another RRCConnectionReconfiguration message including the WLAN mobility set to the UE 102. The WLAN mobility set may be one or more WLAN identifiers (e.g., SSID, BSSID, HESSID, etc.) in a WLAN-mobility set field or IE in a WLAN-mobility set variable or IE of the rrcconnectionreconfigurationmessage. If the WLAN 106 identifier matches all WLAN identifiers of at least one entry in the WLAN-mobility set, then the WLAN 106 may be considered to be inside the WLAN mobility set, otherwise the WLAN 106 may be considered to be outside the WLAN mobility set. In operation 1035, ue 102 may apply the new configuration and may reply by sending an RRCConnectionReconfigurationComplete message to RAN node 111/112.

In operation 1040, the ue 102 may associate with the WLAN 106, if not already associated, taking into account the WLAN mobility set. When the UE 102 receives a new or updated WLAN mobility set, the UE 102 may initiate a connection to the WLAN 106 inside the WLAN mobility set if not already connected to the WLAN 106. UE 102 may perform WLAN mobility within the WLAN mobility set (connect or reconnect to WLAN 106 within the WLAN mobility set) without any signaling to RAN nodes 111/112. Operation 1040 may also include starting WLAN status monitoring.

In operation 1045, ue 102 may send a WLAN connectionstatus report to RAN node 111/112 to confirm the WLAN association. WLAN connectionstatus report may be used to provide feedback to RAN nodes 111/112 regarding the status and operation of WLAN 106. For example, WLAN connectionstatus report may include a WLAN connection failure indication, a WLAN connection success indication, a WLAN temporary suspension indication, and/or a WLAN connection restoration indication. This report may be used to inform RAN nodes 111/112 about the status of the WLAN connection for LWIP purposes (e.g., managing LWIP tunnel 160, etc.). In some embodiments, at any point during LWIP operation when UE 102 cannot establish or continue LWIP operation, UE 102 may send a WLAN connectionstatus report message to RAN node 111/112 to indicate "WLAN connection failure". Further, when UE 102 is unable to support LWIP operation for the temporary duration, UE 102 may suspend LWIP operation by sending a first WLAN connectionstatus report message to RAN node 111/112 to indicate "WLAN temporary suspension" and may resume LWIP operation by sending a second WLAN connectionstatus report message to RAN node 111/112 to indicate "WLAN connection resume" and/or "WLAN connection success".

In operation 1050, the ran node 111/112 may send another RRCConnectionReconfiguration message to the UE 102 including the necessary parameters to establish the IPsec tunnel 117 over the WLAN 106. This rrcconnectionreconfigurationmessage may also include a configuration for the data bearer to utilize IPsec tunnel 117. For example, the RRCConnectionReconfiguration message may include an LWIP configuration IE, which may include a tunelconfiglwip field/IE containing parameters to be used to establish the LWIP tunnel 160, and an LWIP-MobilityConfig field/IE indicating a WLAN mobility set to be used for LWIP. the parameters included in tunnelConfigLWIP IE may include, for example: an IP-address parameter indicating an LWIP-SeGW IP address to be used by the UE to initiate LWIP tunnel establishment; IKE-Identity parameters indicating an IKE Identity element (IDi) to be used in an IKE authentication procedure; an LWIP-Counter parameter indicating parameters to be used by the UE 102 to calculate security keys for use in LWIP tunnel establishment; and/or other similar parameters. In addition, the rrcconnectionreconfigurationmessage may also include RadioResourceConfigDedicated IE, which may be used to set up/modify/release Radio Bearers (RBs) and may indicate a single bearer to be used for communicating data over the LWIP tunnel 160. For example, radioResourceConfigDedicated IE can include DRB-typeLWIP field/IE, lwip-UL-Aggregation field/IE, and/or lwip-DL-Aggregation field/IE in the DRB-ToAddModList IE field. DRB-TypeLWIP field/IE may indicate whether the DRB is (re) configured to use LWIP tunnel 160 in UL and DL (DRB-TypeLWIP set to a value LWIP), LWIP tunnel 160 only in DL (DRB-TypeLWIP set to a value LWIP-DL-only), LWIP tunnel 160 only in UL (DRB-TypeLWIP set to a value LWIP-UL-only), or not LWIP tunnel 160 (DRB-TypeLWIP set to a value eutran). The LWIP-UL-Aggregation field/IE and LWIP-DL-Aggregation field/IE may indicate whether LWIP is configured to utilize LWIP Aggregation in DL or UL, respectively. In operation 1055, ue 102 may apply the new configuration and may reply by sending another RRCConnectionReconfigurationComplete message to RAN node 111/112.

In operation 1060, the ue 102 may use parameters in the new RRC configuration to set up the IPsec tunnel 117 with the LWIP-SeGW 150 to complete the establishment of the LWIP tunnel 160 with the RAN node 111/112 through WLAN 106 access. RAN node 111/112 may utilize LWIP tunnel 160 by sending an rrcconnectionreconfigurationmessage to the UE to add or remove data bearers at any time after the establishment of IPsec tunnel 117.

Fig. 11 illustrates an example WLAN resource reconfiguration process 1100 in accordance with various embodiments. Process 1100 may be a process that reconfigures to remove WLAN radio resources from a data bearer. The process 1100 may begin at operation 1105, where the UE 102 and RAN nodes 111/112 set up an LWIP tunnel 160 via the WLAN 106. In operation 1110, the ue 102 is configured to receive data from the data bearer (e.g., from the RAN nodes 111/112 via the WLAN 106) over the LWIP tunnel 160. In operation 1115, the ran node 111/112 may determine that WLAN resources for the data bearer should be removed.

At operation 1120, the ran node 111/112 may send an RRCConnectionReconfiguration message to the UE 102 including the necessary parameters to remove WLAN resources for the data bearer. In operation 1125, ue 102 may apply the new configuration and may reply by sending an RRCConnectionReconfigurationComplete message to RAN node 111/112. At operation 1130, the ue 102 ceases to receive data for the data bearer over the LWIP tunnel and at operation 1135, the LWIP tunnel 160 between the ue 102 and the RAN node 111/112 via the WLAN 106 may be released. A process for releasing the LWIP tunnel 160 is illustrated by fig. 12.

Fig. 12 illustrates an example LWIP tunnel release procedure 1200 in accordance with various embodiments. Process 1200 may be a process in which RAN node 111/112 initiates LWIP tunnel 160 release. Process 1200 may begin at operation 1205 where UE 102 and RAN nodes 111/112 have established LWIP tunnel 160 via WLAN 106. In operation 1210, the ran node 111/112 may determine that the LWIP tunnel 160 should be released and initiate release of the IPsec tunnel 117 between the UE 102 and the LWIP-SeGW 150. At operation 1215, ran node 111/112 may send an RRCConnectionReconfiguration message to UE 102, which may include an indication to release LWIP tunnel 160 and/or IPsec tunnel 117. The release of the LWIP tunnel 160 initiated by the RAN node 111/112 may be a handover command, a command to transition to rrc_idle state, or some other similar indication or configuration in an RRCConnectionReconfiguration message. Upon receiving a handover command or transitioning to the rrc_idle state, the UE may autonomously release IPsec tunnel 160 configuration and use of the data bearers. At operation 1220, the ue 102 may apply the new configuration and may reply by sending an RRCConnectionReconfigurationComplete message. In operation 1235, the ran node 111/112 may transmit an LWIP-SeGW tunnel release request message to the LWIP-SeGW 150 to release the remaining resources at the LWIP-SeGW 150.

Fig. 13 illustrates an example process 1300A for transmitting downlink user data in accordance with various embodiments, and an example process 1300B for communicating a downlink data delivery status in accordance with various embodiments. The downlink user data transfer procedure 1300A may be used to provide Xw-U specific SN information when transferring DL user data carrying DL LWIP PDUs from the RAN node 111/112 to the LWIP-SeGW150 via the L-Xw-UP interface 155. The downlink data delivery status procedure 1300B may be used to provide feedback from the LWIP-SeGW150 to the RAN node 111/112 to allow the RAN node 111/112 to control downlink user data flows for the respective UE 102 via the LWIP-SeGW 150.

Referring to the procedure 1300A, in operation 1305, the ran node 111/112 may transmit DL user data to the LWIP-SeGW 150. In embodiments, DL user data may be or be included in a data frame, such as frames 900A and 900B of fig. 9A and 9B, respectively. In an embodiment, RAN nodes 111/112 may assign a continuous Xw-U SN to each transmitted Xw-U packet. In an embodiment, the RAN node 111/112 may invoke or operate the L-Xw-UP instance to utilize the downlink user data transfer procedure. According to various embodiments, an L-Xw-UP instance is associated with only a single UE 102 and the downlink user data transfer procedure 1300A may be invoked whenever user data for that particular UE 102 needs to be sent over the L-Xw-UP interface 155.

The LWIP-SeGW 150 may detect whether Xw-U packets are lost and keep track of the corresponding SNs after the LWIP-SeGW 150 declares the corresponding Xw-U packets as "lost". Further, the LWIP-SeGW 150 may transmit any remaining LWIP PDUs to the UE 102 and keep track of the highest Xw-U SN of the LWIP PDUs successfully transmitted to the UE.

Referring to the procedure 1300B, the lwip-SeGW 150 may send a DL data delivery status frame to the RAN node 111/112 in operation 1310. In an embodiment, the DL data delivery status frame may be a data frame or may be included in a data frame, such as respective frames 900A and 900C in fig. 9A and 9C. The DL data delivery status frame may also include an indication of whether the frame is the last DL status report received from the LWIP-SeGW 150 during the release of the bearer. Upon receiving such an indication (if applicable), the RAN node 111/112 may consider that no more UL data from the LWIP-SeGW 150 is expected. In some embodiments, the LWIP-SeGW 150 may also send uplink user data about the UE 102 to the RAN node 111/112 within the same GTP-U PDU along with DL data delivery status frames.

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

In response to receiving the DL data delivery status frame, the RAN node 111/112 may consider the expected buffer size indicated by the DL data delivery status frame as the amount of data expected from the LWIP-SeGW 150 that is declared. The reported expected buffer size may also be considered an instantaneous expected buffer size, independent of the buffer size indicated in the past. RAN nodes 111/112 may also be allowed to remove buffered LWIP PDUs based on feedback of successfully delivered LWIP PDUs. Further, RAN nodes 111/112 may determine various actions to take for the reported LWIP PDUs in addition to successfully delivered LWIP PDUs. After being reported to the RAN node 111/112, the LWIP-SeGW 150 may remove the corresponding Xw-U sequence number.

Referring to fig. 14, an example LWIP operational procedure 1400 is shown in accordance with various embodiments. In an embodiment, processor circuitry (e.g., baseband circuitry 210 or application circuitry 205) of RAN node 111/112 may perform various operations of process 1400, and network controller circuitry 235 (e.g., utilizing ethernet, GRE tunnel-based ethernet, MPLS-based ethernet, etc.) and/or RFEM 215 (e.g., utilizing an over-the-air (OTA) interface) may be used for various communications of process 1400.

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

In operation 1415, the processor circuit may operate the LWIPEP entity 810 to encapsulate the DL data packets to obtain DL LWIPEP PDUs. Further, the processor circuit may include DL LWIP PDUs in user data frames, such as one or more of the frames shown in fig. 9A-9B. At operation 1420, the processor circuit may send the encapsulated packets (e.g., DL LWIPEP PDUs) to the LWIP-SeGW 150 over the L-Xw-UP interface 155 for delivery to the UE 102 via the WLAN 106. Operation 1420 may correspond to process 1300A of fig. 13.

In operation 1425, the processor circuit may obtain one or more UL data packets (e.g., UL LWIP PDUs) from the LWIP-SeGW 150. In an embodiment, UL LWIP PDUs may be included in data frames, such as one or more of the frames shown in fig. 9A and 9C. In operation 1430, the processor circuit may process each of the obtained UL data packets in turn. At operation 1435, the processor circuit may operate the LWIP entity 810 to decapsulate the obtained UL LWIPEP PDU. Operation 1425 may correspond to process 1300B of fig. 13.

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

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

Referring to fig. 15, another example LWIP process 1500 is shown in accordance with various embodiments. In an embodiment, the processor circuitry (e.g., baseband circuitry 210 or application circuitry 205) of the LWIP-SeGW 150 may perform various operations of the process 1500, and the network controller circuitry 235 (e.g., utilizing ethernet, GRE tunnel-based ethernet, MPLS-based ethernet, etc.) and/or the RFEM 215 (e.g., utilizing an over-the-air (OTA) interface) may be used for various communications of the process 1500.

Process 1500 may begin at operation 1505, where the processor circuit may establish LWIP tunnel 160 as previously described. At operation 1510, the processor circuit may obtain DL LWIPEP PDUs for a bearer from the RAN nodes 111/112 over the LWIP tunnel 160 and may forward the DL LWIPEP PDUs for the bearer for delivery to the UE 102 over the LWIP tunnel 160 via the WLAN 106. At operation 1515, the processor circuit may control the storage of the highest SN of the successfully transmitted LWIPEP PDU.

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

At operation 1530, the processor circuit may determine whether a feedback event has occurred. In some embodiments, the feedback event may be detection of a missing LWIPEP PDU, expiration of a timer, or some other suitable event. If the processor circuit determines at operation 1530 that no feedback event has occurred, the processor circuit may return to operation 1510 to receive and forward the LWIPEP PDU. If the processor circuit determines that a feedback event has occurred at operation 1530, the processor circuit may proceed to operation 1535 to generate and send a feedback message to the RAN node 111/112. This may include generating a DL data delivery status message in a data frame (e.g., data frame 900C of fig. 9C) to include the missing SN, the stored highest SN, and other information previously described. After operation 1535, the process 1500 may end or repeat as needed.

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

Process 1600 may begin with operation 1605, where processor circuitry may establish LWIP tunnel 160 with RAN nodes 111/112. Operation 1605 may correspond to process 1000 of fig. 10. At operation 1610, the processor circuit may control the reception of downlink data for a bearer through the LWIP tunnel 160. At operation 1615, the processor circuit may determine whether a configuration to remove WLAN resources is received, and if the configuration has not been received, the processor circuit may continue to control the reception of LWIPEP PDUs at operation 1610. If the configuration is received, the processor circuit may proceed to operation 1620 to cease receiving DL data for the bearer over the LWIP tunnel. Operations 1615 and 1620 may correspond to operations 1120-1130 of process 1100.

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

Some non-limiting examples are provided below. The following examples pertain to further embodiments. The specific details in the examples may be used anywhere in the one or more embodiments discussed previously. All optional features of the apparatus described herein may also be implemented for one or more methods or processes, and vice versa.

Example 1 may include an apparatus to be used in an evolved NodeB "eNB," the apparatus comprising: an encapsulating means for encapsulating downlink "DL" user data packets with a radio level integrated "LWIP" encapsulation protocol "LWIPEP" of a long term evolution wireless local area network by internet protocol security tunneling to obtain DL LWIPEP protocol data units "PDUs" for transmission to an LWIP security gateway "SeGW" and for decapsulating uplink "UL" LWIP-PDUs received from the LWIP-SeGW; and communication means for transmitting DL LWIPEP-PDUs over a user plane interface between the eNB and the LWIP-SeGW, and for obtaining UL LWIPEP-PDUs over the user plane interface from the LWIP-SeGW, and wherein the UL LWIPEP-PDUs and the DL LWIPEP-PDUs are to be transmitted over the user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane, and wherein the user plane interface is to be terminated at the eNB and the SeGW.

Example 2 may include the apparatus of example 1 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single internet protocol security "IPsec tunnel between the LWIP-SeGW and an individual user equipment" UE ", wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network" WLAN ".

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

Example 4 may include the apparatus of example 2 and/or some other examples herein, further comprising: DL user plane means for invoking downlink user data transfer procedures when user data for the individual UE is to be sent through the user plane interface.

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

Example 6 may include the apparatus of example 5 and/or some other examples herein, wherein, in response to invoking the instance of the DL user data transfer procedure, the encapsulation component is to: successively assigning a sequence number to each of said user data packets; and encapsulates each of the user data packets to include the assigned sequence number.

Example 7 may include the apparatus of example 6 and/or some other examples herein, wherein: the communication means is for obtaining a DL delivery status message from the LWIP-SeGW, wherein the DL delivery status message indicates: the highest sequence number of DL LWIPEP PDUs successfully transmitted to or to the individual UE among DL LWIPEP PDUs transmitted by the eNB, the expected buffer size of the individual UE in bytes, the minimum expected buffer size of the individual UE in bytes, and the sequence number of DL LWIPEP PDUs declared as lost by the LWIP-SeGW; and the DL user plane component is for removing buffered LWIPEP-PDUs based on the highest sequence of successfully delivered user data packets; and determining one or more actions to take based on the highest sequence number, the expected buffer size, the minimum expected buffer size, or the sequence number of the missing LWIPEP PDU.

Example 8 may include the apparatus of example 2 and/or some other examples herein, wherein the communication means is to send an Radio Resource Control (RRC) connection reconfiguration message to the UE via RRC signaling, wherein the RRC connection reconfiguration message indicates UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

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

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

Example 11 may include an apparatus to be used as a radio level integrated "LWIP" security gateway "SeGW" for long term evolution wireless local area network security tunneling over internet protocol, the apparatus comprising: a processor circuit, and a network controller circuit coupled to the processor circuit, the network controller circuit: obtaining a downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data unit "PDU" over a user plane interface from an evolved NodeB "eNB" over a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane, and transmitting the DL LWIPEP-PDU over a single internet protocol security "IPsec" tunnel between the LWIP-SeGW and an individual user equipment "UE", and wherein the processor circuitry is to terminate the user plane interface and terminate the IPsec tunnel.

Example 12 may include the apparatus of example 11 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

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

Example 14 may include the apparatus of example 12 and/or some other examples herein, wherein the network control circuitry is to: obtaining an LWIP addition request message from the eNB through the user plane interface, the LWIP addition request message including a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and sending an LWIP addition request acknowledge message to the eNB over the user plane interface to confirm that the LWIP-SeGW can acknowledge the request.

Example 15 may include the apparatus of example 11 and/or some other examples herein, wherein the processor circuit is to: identifying the sequence number of an individual DL LWIEP-PDU in the DL LWIEP-PDU to be transmitted through the IPsec tunnel; and controlling storage of a sequence number having the largest value among the identified sequence numbers successfully transmitted to the individual UE or successfully delivered to the individual UE among DL LWIPEP PDUs transmitted by the eNB.

Example 16 may include the apparatus of example 15 and/or some other examples herein, wherein the processor circuit is to: detecting whether one or more DL LWIPEP PDUs are lost; determining a corresponding sequence number of the lost DL LWIPEP PDU; and controls the storage of the corresponding serial number.

Example 17 may include the apparatus of example 16 and/or some other examples herein, wherein the processor circuit is to: generating a DL delivery status message to indicate a sequence number having a maximum value, an expected buffer size of the individual UE in bytes, a minimum expected buffer value of the individual UE in bytes, and a corresponding sequence number of a missing DL LWIPEP PDU; and removes buffered DL LWIPEP-PDUs based on the sequence number with the largest value.

Example 18 may include the apparatus of example 17 and/or some other examples herein, wherein the processor circuit is to: detecting a trigger to invoke a downlink data delivery feedback procedure; and generating the DL delivery status message in response to detecting the trigger.

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

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

Example 21 may include an apparatus to be used in an evolved NodeB "eNB," the apparatus comprising: processor circuitry: integrating a "LWIP" encapsulation protocol "LWIPEP" encapsulation of downlink "DL" user data packets by a radio level of internet protocol security tunneling using a long term evolution wireless local area network to obtain DL LWIPEP protocol data units "PDUs" for transmission to an LWIP security gateway "SeGW" and decapsulating uplink "UL" LWIP-PDUs received from the LWIP-SeGW; and a network controller circuit coupled with the processor circuit, the network controller circuit to send the DL LWIPEP-PDU over a user plane interface between the eNB and LWIP-SeGW and to obtain a UL LWIPEP-PDU from the LWIP-SeGW over the user plane interface, and wherein the UL LWIPEP-PDU and the DL LWIPEP-PDU are to be transmitted over the user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for a user plane, and wherein the user plane interface is to be terminated at the eNB and the SeGW.

Example 22 may include the apparatus of example 21 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single internet protocol security "IPsec tunnel between the LWIP-SeGW and an individual user equipment" UE ", wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network" WLAN ".

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

Example 24 may include the apparatus of example 22 and/or some other examples herein, wherein the processor circuit is to: a downlink user data transfer procedure is invoked when user data for the individual UE is to be sent through the user plane interface.

Example 25 may include the apparatus of example 24 and/or some other example herein, wherein the processor circuit is to: generating an instance of a DL user plane entity to be associated with only the individual UE; and invoking an instance of the DL user plane entity to operate the downlink user data transfer procedure when user data for the individual UE is to be sent through the user plane interface.

Example 26 may include the apparatus of example 25 and/or some other examples herein, wherein, in response to invoking the instance of the DL user data transfer procedure, the processor circuit: successively assigning a sequence number to each of said user data packets; and encapsulating each of the user data packets such that the DL LWIPEP PDU includes an assigned sequence number.

Example 27 may include the apparatus of example 26 and/or some other examples herein, wherein: the processor circuit: controlling reception of a DL delivery status message from the LWIP-SeGW, wherein the DL delivery status message indicates: the highest sequence number of DL LWIPEP PDUs successfully transmitted to or to the individual UE among DL LWIPEP PDUs transmitted by the eNB, the expected buffer size of the individual UE in bytes, the minimum expected buffer size of the individual UE in bytes, and the sequence number of DL LWIPEP PDUs declared as lost by the LWIP-SeGW; removing the buffered DL LWIPEP-PDU based on the highest sequence of successfully delivered user data packets; and determining one or more actions to take based on the highest sequence number, the expected buffer size, the minimum expected buffer size, or the sequence number of the missing DL LWIPEP PDU.

Example 28 may include the apparatus of example 22 and/or some other example herein, wherein the processor circuit is to: control sends an Radio Resource Control (RRC) connection reconfiguration message to the UE via RRC signaling, wherein the RRC connection reconfiguration message indicates UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

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

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

Example 31 may include an apparatus to be used as a radio level integrated "LWIP" security gateway "SeGW" for long term evolution wireless local area network security tunneling over internet protocol, the apparatus comprising: -communication means for obtaining downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" over a single general packet radio system tunneling protocol "GTP-U" tunnel for user plane from an evolved NodeB "eNB" over a user plane interface, and transmitting said DL LWIPEP-PDUs over a single internet protocol security "IPsec" tunnel between said LWIP-SeGW and an individual user equipment "UE", and wherein said user plane interface is to be terminated at said LWIP-SeGW and said IPsec tunnel is to be terminated at said LWIP-SeGW.

Example 32 may include the apparatus of example 31 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

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

Example 34 may include the apparatus of example 32 and/or some other example herein, wherein the communication component is to: obtaining an LWIP addition request message from the eNB through the user plane interface, the LWIP addition request message including a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and sending an LWIP addition request acknowledge message to the eNB over the user plane interface to confirm that the LWIP-SeGW can acknowledge the request.

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

Example 36 may include the apparatus of example 35 and/or some other example herein, wherein: the processing component is configured to detect whether one or more DL LWIPEP PDUs are lost; and determining a corresponding sequence number of the lost DL LWIPEP PDU; and the storage means is for storing the corresponding serial number.

Example 37 may include the apparatus of example 36 and/or some other examples herein, wherein the processing component is to: detecting a trigger to invoke a downlink data delivery feedback procedure; in response to detecting the trigger, generating a DL delivery status message to indicate a sequence number having a maximum value, an expected buffer size of the individual UE in bytes, a minimum expected buffer value of the individual UE in bytes, and a corresponding sequence number of a missing DL LWIPEP PDU; and removes the buffered LWIEP-PDU based on the sequence number with the largest value.

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

Example 39 may include the apparatus of example 38 and/or some other examples herein, wherein the processing component is to generate the DL delivery status message to indicate whether the DL delivery status message is a last DL delivery status message to be sent during a procedure of releasing a bearer from the LWIP-SeGW.

Example 40 may include the apparatus of examples 31-39 and/or some other example herein, wherein the user plane interface is an Xw interface.

Example 41 may include one or more computer-readable media "CRM" comprising instructions that, when executed by one or more processors of an evolved NodeB "eNB," cause the eNB to: radio level integration "LWIP" encapsulation protocol "LWIPEP" encapsulating downlink "DL" user data packets with long term evolution wireless local area network over internet protocol security tunneling to obtain DL LWIPEP-protocol data units "PDUs" for transmission to LWIP-security gateway "SeGW"; decapsulating an uplink "UL" LWIP-PDU received from the LWIP-SeGW; controlling to transmit the DL LWIPEP-PDU through a user plane interface between the eNB and LWIP-SeGW; and controlling reception of UL LWIPEP-PDUs from the LWIP-SeGW over the user plane interface, wherein the UL LWIPEP-PDUs and the DL LWIPEP-PDUs are to be transmitted over the user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane, and wherein the user plane interface is to be terminated at the eNB and the SeGW.

Example 42 may include the one or more CRMs of example 41 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single internet protocol security "IPsec" tunnel between the LWIP-SeGW and an individual user equipment "UE", wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

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

Example 44 may include the one or more CRMs of example 42 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the eNB to: a downlink user data transfer procedure is invoked when user data for the individual UE is to be sent through the user plane interface.

Example 45 may include the one or more CRMs of example 44 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the eNB to: generating an instance of a DL user plane entity to be associated with only the individual UE; and invoking an instance of the DL user plane entity to operate the downlink user data transfer procedure when user data for the individual UE is to be sent through the user plane interface.

Example 46 may include the one or more CRMs of example 45 and/or some other examples herein, wherein, in response to invoking the instance of the DL user data transfer procedure, execution of the instructions by one or more processors causes the eNB to: successively assigning a sequence number to each of said user data packets; and encapsulating each of the user data packets such that the DL LWIPEP PDU includes an assigned sequence number.

Example 47 may include the one or more CRMs of example 46 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the eNB to: controlling reception of a DL delivery status message from the LWIP-SeGW, wherein the DL delivery status message indicates: the highest sequence number of DL LWIPEP PDUs successfully transmitted to or to the individual UE among DL LWIPEP PDUs transmitted by the eNB, the expected buffer size of the individual UE in bytes, the minimum expected buffer size of the individual UE in bytes, and the sequence number of DL LWIPEP PDUs declared as lost by the LWIP-SeGW; removing the buffered DL LWIPEP-PDU based on the highest sequence of successfully delivered user data packets; and determining one or more actions to take based on the highest sequence number, the expected buffer size, the minimum expected buffer size, or the sequence number of the missing DL LWIPEP PDU.

Example 48 may include the one or more CRMs of example 42 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the eNB to: control sends an Radio Resource Control (RRC) connection reconfiguration message to the UE via RRC signaling, wherein the RRC connection reconfiguration message indicates UL data is to be routed via the WLAN or via Long Term Evolution (LTE) signaling.

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

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

Example 51 may include one or more computer-readable media "CRM" comprising instructions that, when executed by one or more processors of a radio level integrated "LWIP" security gateway "SeGW" of a long term evolution wireless local area network through internet protocol security tunneling, cause the LWIP-SeGW to: control receiving downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" over a single general packet radio system tunneling protocol "GTP-U" tunnel for user plane from an evolved NodeB "eNB" over a user plane interface, and control transmitting the DL LWIPEP-PDUs over a single internet protocol security "IPsec" tunnel between the LWIP-SeGW and an individual user equipment "UE", and wherein the user plane interface is to be terminated at the LWIP-SeGW and the IPsec tunnel is to be terminated at the LWIP-SeGW.

Example 52 may include the one or more CRMs of example 51 and/or some other examples herein, wherein the single GTP tunnel corresponds to a single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

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

Example 54 may include the example 52 and/or the one or more CRMs of some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: obtaining an LWIP addition request message from the eNB through the user plane interface, the LWIP addition request message including a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and sending an LWIP addition request acknowledge message to the eNB over the user plane interface to confirm that the LWIP-SeGW can acknowledge the request.

Example 55 may include the one or more CRMs of example 51 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: identifying the sequence number of an individual DL LWIEP-PDU in the DL LWIEP-PDU to be transmitted through the IPsec tunnel; and controlling storage of a sequence number having the largest value among the identified sequence numbers successfully transmitted to the individual UE or successfully delivered to the individual UE among DL LWIPEP PDUs transmitted by the eNB.

Example 56 may include the one or more CRMs of example 55 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: detecting whether one or more DL LWIPEP PDUs are lost; determining a corresponding sequence number of the lost DL LWIPEP PDU; and controls the storage of the corresponding serial number.

Example 57 may include the one or more CRMs of example 56 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: generating a DL delivery status message to indicate a sequence number having a maximum value, an expected buffer size of the individual UE in bytes, a minimum expected buffer value of the individual UE in bytes, and a corresponding sequence number of a missing DL LWIPEP PDU; and removes buffered DL LWIPEP-PDUs based on the sequence number with the largest value.

Example 58 may include the one or more CRMs of example 57 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: detecting a trigger to invoke a downlink data delivery feedback procedure; and generating the DL delivery status message in response to detecting the trigger.

Example 59 may include the one or more CRMs of example 58 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the LWIP-SeGW to: the DL delivery status message is generated to indicate whether the DL delivery status message is a last DL delivery status message to be transmitted during a procedure of releasing a bearer from the LWIP-SeGW.

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

Example 61 may include an apparatus to be implemented in a user equipment "UE," the apparatus comprising: a system on a chip "SoC" comprising baseband circuitry and on-board memory circuitry, the baseband circuitry: controlling the reception of a radio resource control, RRC, message comprising parameters for setting up an internet protocol security, IPsec, tunnel with a radio level integrated, LWIP, security gateway, seGW, of a long term evolution, wireless local area network by internet protocol security tunneling; establishing the IPsec tunnel with the LWIP-SeGW by using parameters in the RRC message; and controlling the reception of downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" from an evolved NodeB "eNB" via a wireless local area network "WLAN" access point "AP", from an LWIP-SeGW, wherein the LWIPEP-PDUs are to be transmitted to the LWIP-SeGW over a user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane.

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

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

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

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

Example 66 may include an apparatus to be implemented in a user equipment "UE," the apparatus comprising: a long term evolution "LTE" circuit that controls reception of radio resource control "RRC" messages, the RRC messages comprising: a first parameter for setting up an internet protocol security "IPsec" tunnel with a radio level integration "LWIP" security gateway "SeGW" of a long term evolution wireless local area network via internet protocol security tunneling, and a second parameter for setting up an LWIP bearer to be transmitted over the IPsec tunnel; a processor circuit coupled to the LTE circuit, the processor circuit configured to control the establishment of the IPsec tunnel with the LWIP-SeGW using the first parameter; and controlling the setup of the LWIP bearer using the second parameter; and a wireless local area network, "WLAN," physical layer, "PHY," circuit coupled with the LTE circuit and the processor circuit, the WLAN PHY circuit controlling reception of downlink "DL" LWIP encapsulation protocol, "LWIPEP," protocol data units, "PDUs," from an evolved NodeB, "eNB," from an LWIP-SeGW via a WLAN access point, "AP," wherein the LWIPEP-PDUs are to be transmitted to the LWIP-SeGW over a user plane interface on a single general packet radio system tunneling protocol, "GTP-U," tunnel for the user plane.

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

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

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

Example 70 may include the apparatus of examples 66-69 and/or some other examples herein, wherein the processor circuit is to operate the LWIPEP entity to: decapsulating the DL LWIPEP-PDU; and encapsulating UL LWIPEP-PDUs to be sent to the LWIP-SeGW through the IPsec tunnel via the WLAN AP.

Example 71 may include an apparatus to be implemented in a user equipment "UE", the apparatus comprising: a long term evolution "LTE" component for receiving a radio resource control "RRC" message comprising a first parameter for setting up an internet protocol security "IPsec" tunnel with a radio level integration "LWIP" security gateway "SeGW" of a long term evolution wireless local area network through internet protocol security tunneling, and a second parameter for setting up an LWIP bearer to be transmitted over the IPsec tunnel; and a wireless local area network "WLAN" component for: establishing the IPsec tunnel with the LWIP-SeGW by utilizing the first parameter; setting up the LWIP bearer by using the second parameter; and receiving downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" from an evolved NodeB "eNB" from an LWIP-SeGW via a WLAN access point "AP", wherein the LWIPEP-PDUs are to be transmitted to the LWIP-SeGW over a user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane.

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

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

Example 74 may include the apparatus of example 71 and/or some other example herein, wherein: the LTE component is configured to receive another RRC message including another WLAN mobility set, wherein the another WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and the WLAN component is to measure signal strengths of signals broadcast by the one or more WLAN APs and to generate signal strength measurements based on the measurements.

Example 75 may include the apparatus of examples 71-74 and/or some other example herein, wherein the LTE component comprises a LWIPEP component to: decapsulating the DL LWIPEP-PDU; and encapsulating UL LWIPEP-PDUs to be sent to the LWIP-SeGW through the IPsec tunnel via the WLAN AP.

Example 76 may include one or more computer-readable media "CRM" comprising instructions that, when executed by one or more processors of a user equipment "UE", cause the UE to: controlling the reception of a radio resource control, RRC, message comprising a first parameter for setting up an internet protocol security, IPsec, tunnel with a radio level integrated, LWIP, security gateway, seGW, for internet protocol security, tunneling over an internet protocol security, with a long term evolution, wireless local area network, and a second parameter for setting up an LWIP bearer to be transmitted over the IPsec tunnel; establishing the IPsec tunnel with the LWIP-SeGW by utilizing the first parameter; setting up the LWIP bearer by using the second parameter; and controlling the reception of downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" from the evolved NodeB "eNB" via the wireless local area network "WLAN" access point "AP", wherein the LWIPEP-PDUs are to be transmitted to the LWIP-SeGW over the user plane interface on a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane.

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

Example 78 may include the one or more CRMs of example 76 and/or some other examples herein, wherein the first parameter for setting up the IPsec tunnel comprises a WLAN mobility set, wherein the WLAN mobility set comprises one or more identifiers associated with the WLAN AP, and the second parameter comprises a configuration indicating whether traffic for the LWIP bearer is to be routed through the IPsec tunnel in DL only, in uplink "UL" only, or in both UL and DL.

Example 79 may include the one or more CRMs of example 76 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the UE to: controlling reception of another RRC message including another WLAN mobility set, wherein the another WLAN mobility set indicates one or more WLAN APs including the WLAN AP; and performing signal strength measurements on signals broadcast by the one or more WLAN APs.

Example 80 may include the one or more CRMs of examples 76-79 and/or some other examples herein, wherein execution of the instructions by the one or more processors causes the UE to operate a LWIPEP entity to: decapsulating the DL LWIPEP-PDU; and encapsulating UL LWIPEP-PDUs to be sent to the LWIP-SeGW through the IPsec tunnel via the WLAN AP.

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

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

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

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

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

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

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

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

Claims (23)

1. An apparatus to be used in an evolved NodeB "eNB," the apparatus configured to:

encapsulating downlink "DL" user data packets with a long term evolution wireless local area network via radio level integration "LWIP" encapsulation protocol "LWIPEP" of internet protocol security tunneling to obtain DL LWIPEP-protocol data units "PDUs" to be sent to the LWIP-security gateway "SeGW"; and

and controlling transmission of the DL LWIPEP-PDU through a user plane interface between the eNB and the LWIP-segW.

2. The apparatus of claim 1, wherein the DL LWIPEP-PDU is to be transmitted over the user plane interface over a single general packet radio system tunneling protocol "GTP-U" tunnel for a user plane, and wherein the single GTP-U tunnel corresponds to a single internet protocol security "IPsec" tunnel between the LWIP-SeGW and an individual user equipment "UE", wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

3. The apparatus of claim 2, wherein an end-to-end path between the UE and the eNB via a WLAN access point "AP" is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

4. The apparatus of claim 2, further configured to:

a downlink user data transfer procedure is invoked when user data for the individual UE is to be sent through the user plane interface.

5. The apparatus of claim 4, further configured to:

generating an instance of a DL user plane entity to be associated with only the individual UE; and

when user data for the individual UE is to be sent through the user plane interface, an instance of the DL user plane entity is invoked to operate the downlink user data transfer procedure.

6. The apparatus of claim 5, wherein, in response to invoking the instance of the DL user data transfer procedure, the apparatus is configured to:

successively assigning a sequence number to each of said user data packets; and

each of the user data packets is encapsulated to include an assigned sequence number.

7. The apparatus of claim 6, further configured to:

controlling reception of a DL delivery status message from the LWIP-SeGW, wherein the DL delivery status message is used to indicate:

the highest sequence number of DL LWIPEP PDUs successfully transmitted to or to the individual UE among DL LWIPEP PDUs transmitted by the eNB,

The expected buffer size of the individual UEs in bytes,

a minimum expected buffer size of the individual UEs in bytes, and

a sequence number declared as a missing DL LWIPEP PDU by the LWIP-SeGW; and

removing buffered LWIPEP-PDUs based on the highest sequence of successfully delivered user data packets; and determining one or more actions to take based on the highest sequence number, the expected buffer size, the minimum expected buffer size, or the sequence number of the missing LWIPEP PDU.

8. The apparatus of any of claims 1-7, wherein the user plane interface is an Xw interface.

9. An apparatus to be used as a radio level integrated "LWIP" security gateway "SeGW" for long term evolution wireless local area network over internet protocol security tunneling, the apparatus comprising:

processor circuit

A network controller circuit coupled to the processor circuit, the network controller circuit to:

obtaining downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" from an evolved NodeB "eNB" over a user plane interface over a single general packet radio system tunneling protocol "GTP-U" tunnel for the user plane, and

The DL LWIPEP-PDU is sent over a single internet protocol security "IPsec" tunnel between the LWIP-SeGW and the individual user equipment "UE".

10. The apparatus of claim 9, wherein the single GTP tunnel corresponds to a single IPsec tunnel between the LWIP-SeGW and the individual UE, wherein the single IPsec tunnel is used for all data bearers configured to transmit or receive data over a wireless local area network "WLAN".

11. The apparatus of claim 10, wherein an end-to-end path between the UE and the eNB via a WLAN access point "AP" is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

12. The apparatus of claim 10, wherein the network control circuit is to:

obtaining an LWIP addition request message from the eNB through the user plane interface, the LWIP addition request message including a request to allocate resources for the individual UE and security material for establishing the IPsec tunnel; and

an LWIP addition request acknowledge message is sent to the eNB over the user plane interface to confirm that the LWIP-SeGW can acknowledge the request.

13. The apparatus of claim 9, wherein the processor circuit is to:

Identifying the sequence number of an individual DL LWIEP-PDU in the DL LWIEP-PDU to be transmitted through the IPsec tunnel; and

controlling storage of sequence numbers having a maximum value among the identified sequence numbers successfully transmitted to or successfully delivered to the individual UE among DL LWIPEP PDUs transmitted by the eNB.

14. The apparatus of claim 13, wherein the processor circuit is to:

detecting whether one or more DL LWIPEP PDUs are lost;

determining a corresponding sequence number of the lost DL LWIPEP PDU; and

and controlling the storage of the corresponding serial numbers.

15. The device of claim 14, wherein the processor circuit is to:

generating a DL delivery status message to indicate a sequence number having a maximum value, an expected buffer size of the individual UE in bytes, a minimum expected buffer value of the individual UE in bytes, and a corresponding sequence number of a missing DL LWIPEP PDU; and

the buffered DL LWIPEP-PDU is removed based on the sequence number with the largest value.

16. The device of claim 15, wherein the processor circuit is to:

detecting a trigger to invoke a downlink data delivery feedback procedure; and

The DL delivery status message is generated in response to detecting the trigger.

17. The apparatus of claim 16, wherein the processor circuit is configured to generate the DL delivery status message to indicate whether the DL delivery status message is a last DL delivery status message to be sent during a procedure of releasing a bearer from the LWIP-SeGW.

18. The apparatus according to any of claims 9-17, wherein the user plane interface is an Xw interface.

19. An apparatus to be implemented in a user equipment "UE", the apparatus comprising:

a long term evolution "LTE" circuit for controlling reception of a radio resource control "RRC" message, the RRC message comprising:

a first parameter, wherein the first parameter is used for setting up an internet protocol security (IPsec) tunnel with a radio level integration (LWIP) security gateway (SeGW) of the long term evolution wireless local area network through internet protocol security tunneling;

a processor circuit coupled to the LTE circuit, the processor circuit for controlling the establishment of the IPsec tunnel with the LWIP-SeGW using the first parameter, and

a wireless local area network "WLAN" physical layer "PHY" circuit coupled with the LTE circuit and the processor circuit, the WLAN PHY circuit for controlling the reception of downlink "DL" LWIP encapsulation protocol "LWIPEP" protocol data units "PDUs" from the evolved NodeB "eNB" from the LWIP-SeGW via the WLAN access point "AP".

20. The apparatus of claim 19, wherein the LWIPEP-PDU is to be communicated to the LWIP-SeGW over a user plane interface on a single general packet radio system tunneling protocol for user plane "GTP-U" tunnel, and wherein an end-to-end path between the UE and the eNB via the WLAN AP and the LWIP-SeGW is an LWIP tunnel, and the LWIP tunnel comprises the user plane interface and the IPsec tunnel.

21. The apparatus of claim 19, wherein the RRC message further comprises a second parameter for setting up an LWIP bearer to be transmitted over the IPsec tunnel, wherein the first parameter comprises a WLAN mobility set, wherein WLAN mobility set comprises one or more identifiers associated with the WLAN AP, and the second parameter comprises a configuration for indicating whether traffic for the LWIP bearer is to be routed through the IPsec tunnel in DL only, uplink "UL" only, or both UL and DL.

22. The apparatus of claim 19, wherein:

the LTE circuitry is to control reception of another RRC message including another set of WLAN mobility indicating one or more WLAN APs including the WLAN AP; and is also provided with

The WLAN PHY circuitry is to perform signal strength measurements on signals broadcast by the one or more WLAN APs.

23. The apparatus of any of claims 19-22, wherein the processor circuit is to operate a LWIPEP entity to:

decapsulating the DL LWIPEP-PDU; and

encapsulating UL LWIPEP-PDUs to be sent to the LWIP-SeGW through the IPsec tunnel via the WLAN AP.

Images