CN109155786B - Apparatus and method for offloading processing from user equipment to network - Google Patents

Abstract

Embodiments are described for offloading TCP/IP processing from a user device to a network device. A User Equipment (UE) encodes a message from a socket and connection manager of an operating system to a RAN-based TCP offload protocol (RTOP) layer requesting that a network device open and run a TCP/UDP connection on behalf of the UE or run TCP/IP processing for an existing TCP/UDP connection that has been previously opened by the UE. The UE encodes, using the RTOP layer, a request for the network device to open or run a TCP/UDP connection on behalf of the UE, the request including the flow identification information and the TCP context information, the request causing the network device to open or run the TCP/UDP connection based on the flow identification information and the TCP context information. The UE decodes an acknowledgement that the TCP/UDP connection received from the network device was successfully opened or running.

Description

Apparatus and method for offloading processing from user equipment to network

Technical Field

Embodiments relate to wireless communications. Some embodiments relate to layer 2 and layer 3(RAN2/RAN3) of a radio access network in a fifth generation (5G) system. Some embodiments relate to offloading transmission control protocol/internet protocol (TCP/IP) processing from a user equipment to a network infrastructure device (e.g., an evolved node B or an access point).

Background

In a cellular network or WiFi network, User Equipment (UE) may be provided to a user and may have limited processing capabilities. Network infrastructure devices such as enodebs or access points may have greater processing capabilities. As previously described, techniques for offloading transmission control protocol/internet protocol (TCP/IP) processing from a user device to a network infrastructure device may be desirable.

Drawings

Fig. 1A-1B illustrate an example transmission control protocol/internet protocol (TCP/IP) protocol stack in Long Term Evolution (LTE).

Fig. 2A-2B illustrate examples of a Radio Access Network (RAN) based TCP/IP offload protocol (RTOP) stack.

Fig. 3A-3B illustrate an example RTOP stack that conforms to the Institute of Electrical and Electronics Engineers (IEEE)802.11 ethernet standard.

Fig. 4 is a data flow diagram illustrating an example user equipment initiated RTOP communication method.

FIG. 5 illustrates an example Packet Data Convergence Protocol (PDCP)/RTOP packet format.

Figure 6 illustrates an example flow from a transmitting PDCP entity to a receiving PDCP entity.

Fig. 7 is a data flow diagram illustrating an example of downlink RTOP flow control based on an evolved node B.

Fig. 8 is a data flow diagram illustrating an example of user equipment based enode B assisted uplink RTOP flow control.

Fig. 9 is a data flow diagram illustrating an example handover procedure.

Fig. 10 is a functional schematic diagram of a wireless network according to some embodiments.

FIG. 11 illustrates components of a communication device according to some embodiments.

Fig. 12 illustrates a block diagram of a communication device, in accordance with some embodiments.

Fig. 13 illustrates another block diagram of a communication device in accordance with some embodiments.

Detailed Description

The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, procedural, and other changes. Portions and features of some embodiments may be included in or substituted for those of others. Embodiments set forth in the claims encompass all available equivalents of those claims.

Fig. 1A to 1B show example TCP/IP protocol stacks in LTE, where fig. 1A shows the u-plane and fig. 1B shows the c-plane.

As shown in fig. 1A, in the u-plane, UE 110A and eNB 120 are connected via a Uu interface. UE 110A includes an application (Apps) layer, a next TCP/UDP layer, a next IP layer, a next PDCP layer, a next Radio Link Control (RLC) layer, and a next physical/medium access control (PHY/MAC) layer. The eNB 120a includes a PDCP layer, a next RLC layer, and a next PHY/MAC layer.

As shown in fig. 1B, in the c-plane, UE 110B and eNB 120B are connected via a Uu interface. The UE 110B includes a Radio Resource Control (RRC) layer, a next PDCP layer, a next RLC layer, and a next PHY/MAC layer. The eNB 120B includes an RRC layer, a next PDCP layer, a next RLC layer, and a next PHY/MAC layer.

Fifth generation (5G) cellular Radio Access Technology (RAT) targets higher peak data rates (e.g., 10 gigabits per second (GBPS)) than Long Term Evolution (LTE). However, in general, a Central Processing Unit (CPU) process of about 1 hz is required to transmit or receive one bit per second of transmission control protocol/internet protocol (TCP/IP). For example, 5GBPS network traffic requires 5 gigahertz (GHz) of CPU processing. This means that 2 complete cores of a 2.5GHz multi-core processor are required to handle TCP/IP processing associated with TCP/IP traffic of a 5 GBPS.

A TCP Offload Engine (TOE) is used in the network interface card to offload processing of the TCP/IP stack to the network controller. It is mainly used for high-speed network interfaces (e.g., gigabit ethernet and 10 gigabit ethernet), where the processing overhead of the network stack becomes significant. The next generation (e.g., 5G) cellular network interface may use TOE to reduce CPU cycles of an application processor of the mobile device. However, the use of the TOE increases the CPU cycles of the Communication Processor (CP) while the communication processor is still on the mobile device, and thus still consumes resources and power of the mobile device.

Some aspects of the subject technology address the problem of reducing TCP/IP processing (and resource and battery utilization) at a User Equipment (UE) in the field of computer or cellular technology. According to some embodiments, a solution to this problem includes a TCP/IP offload architecture and the necessary air interface changes to completely offload the TCP/IP stack outside the UE to the serving evolved node b (enb) or WiFi Access Point (AP). Some embodiments support both TCP traffic and User Datagram Protocol (UDP) traffic.

In this document, LTE-specific terms (e.g., UE, eNB, etc.) may be used to identify nodes in LTE networks and nodes in other networks that may share similar logical or conceptual functionality with LTE nodes.

As one principle of operation, some embodiments may include having the eNB establish a TCP or UDP connection on behalf of the UE and taking care of all TCP/IP processing for the connection. As a result, the UE directly processes raw application data or data from the socket and connection manager of the UE's operating system.

Some TOE solutions offload TCP/IP processing from the application processor to the communication/network processor (which is still on the UE). For example, TCP engine proxy solutions offload TCP functions to the edge cloud. However, this scheme is based on a higher layer (transport layer or application layer from the Open Systems Interconnection (OSI) model) protocol. The TCP engine proxy solution has the following limitations: additional retransmissions or coding for reliable packet delivery, and additional UDP/IP protocol processing for tunneling.

Some aspects of the subject technology provide the following: completely offloading TCP/IP processing outside the UE to the eNB or AP; rely on third generation partnership project (3GPP) Radio Access Network (RAN) (LTE) protocols (e.g., Packet Data Convergence Protocol (PDCP)) and radio link control/automatic repeat request (RLC/ARQ) to ensure reliable and ordered delivery of packets without additional overhead; transmitting application data directly over a 3GPP RAN (LTE) protocol (e.g., PDCP) without additional transport or IP layer (in the OSI model) protocol processing; and supporting end-to-end (e2e) flow control through tight cooperation between the 3GPP RAN (LTE) stack and the TCP/IP stack, among other things.

Fig. 2A-2B illustrate an example RAN-based TCP/IP offload protocol (RTOP) stack, where fig. 2A illustrates the u-plane and fig. 2B illustrates the c-plane.

As shown in fig. 2A, in the u-plane, UE 210A is connected to eNB220A via a Uu interface. The UE 210A is similar in structure to the UE 110A of FIG. 1A, and adds an RTOP-u layer adjacent to the TCP/UDP and IP layers, above the PDCP layer, and below the App layer. The eNB220A includes an RTOP-u layer. The RTOP-u layer is followed by (1) a PDCP layer, an RLC layer, and a PHY/MAC layer in this order, and (2) a TCP/UDP layer and an IP layer in this order. The PDCP layer is adjacent to the TCP/UDP layer, and the IP layer is adjacent to the RLC layer and the PHY/MAC layer.

As shown in fig. 2B, in the c-plane, the UE 210B and the eNB220B are connected via a Uu interface. UE 210B is similar to UE 110B, with the RTOP-c layer above the RRC layer. eNB220B is similar to eNB 120B with the RTOP-c layer above the RRC layer.

Fig. 1A to 1B illustrate a TCP/IP protocol stack in an LTE system, and fig. 2A to 2B illustrate the proposed RTOP stack. As shown in fig. 1A to 1B and fig. 2A to 2B, the proposed RTOP architecture affects access but does not affect the core. As shown in fig. 2A-2B, on both the UE and the eNB, a new RTOP layer is added above the PDCP for offloading TCP/IP processing for the UE to the eNB.

Some aspects of the subject technology include enhancing PDCP to interface with a new RTOP layer. In some aspects, the PDCP is designed to interface only with the IP layer, as shown in fig. 1A to 1B. However, as shown in fig. 2A to 2B, in the proposed RTOP architecture, the TCP/IP stack operates on the PDCP in a manner similar to that shown in fig. 1A to 1B. In some cases, the RTOP-u function is integrated in the PDCP and the RTOP-c function is integrated in the RRC. In these cases, there is no need to introduce a new layer (RTOP) in the cellular RAN protocol stack.

On the other hand, the proposed RTOP scheme operates only after the UE is attached and has no impact on the existing bearer (packet data network (PDN)) establishment procedure. As in LTE networks, the UE maintains the IP address assigned to it by the packet gateway (P-GW).

In addition, whenever a UE's active RTOP session is terminated (for any reason) by its serving eNB, the eNB transmits state information of all relevant TCP/IP connections back to the UE so that these TCP/IP connections continue without interruption.

Fig. 3A-3B illustrate an example RTOP stack compliant with the Institute of Electrical and Electronics Engineers (IEEE)802.11 ethernet standard, where fig. 3A illustrates the u-plane and fig. 3B illustrates the c-plane.

As shown in fig. 3A, in the u-plane, the UE 310A and the AP 330A are connected via a Wi-Fi network. The UE 310A has an Apps layer. Below the Apps layer are (1) a TCP/UDP layer and a next IP layer, and (2) an RTOP-u layer, a next PDCP or IP layer, and a next ethernet layer. Below these layers is the IEEE802.11MAC layer, followed by the IEEE802.11 PHY layer. The AP 330A has an RTOP-u layer. Two sets of layers underlie the RTOP-u layer. The first group includes a PDCP or IP layer, a next ethernet layer, a next IEEE802.11MAC layer, and a next IEEE802.11 PHY layer. The second group includes the TCP/UDP layer and the following IP layer.

As shown in fig. 3B, in the c-plane, the UE 310B and the AP 330B are connected via a Wi-Fi network. The UE 310B has an RTOP-c layer, a next IEEE802.11MAC layer, and a next IEEE802.11 PHY layer. The AP 330B has an RTOP-c layer, the next IEEE802.11MAC layer, and the next IEEE802.11 PHY layer.

Fig. 3A to 3B illustrate how the proposed RTOP is supported in an IEEE 802.11/Wi-Fi network. The RTOP-u plane traffic is transported over the 3GPP PDCP or IP. If PDCP is used, the same PDCP enhancements can be used in 3GPP RAN and Wi-Fi to support RTOP. Instead, protocol type 114 (specified for any 0-hop protocol) is used directly to carry the RTOP using IP. RTOP c-plane traffic may be transmitted over IEEE 802.11 management frames.

Fig. 4 is a data flow diagram illustrating a user equipment initiated RTOP communication method 400. As shown, method 400 includes communication between Apps (APP @ UE)405 at the UE, RTOP (RTOP @ UE)410 at the UE, RTOP (RTOP @ eNB)415 at the eNB, and serving gateway/packet gateway (S-GW/P-GW)) network 420. In alternative embodiments, the Apps @ UE 405 may be replaced with a socket and connection manager for the UE, or the eNB may be replaced with an AP or other network infrastructure device.

Method 400 begins at operation 425 where, at operation 425, Apps @ UE 405 sends an RTOP open request (RTOP-open-REQ) to RTOP @ UE 410. The RTOP open request includes a source address, a source port, a destination IP, a destination port, and a protocol type. RTOP @ UE410 forwards the RTOP open request and an Evolved Packet System (EPS) bearer Identifier (ID) to RTOP @ eNB 415.

Apps @ UE 405 sends to RTOP @ UE 410 an RTOP-Open-REQ message requesting the eNB to Open or run a TCP/IP connection on behalf of the UE, which RTOP @ UE 410 then forwards to the eNB using, for example, an RRC message. The RTOP-Open-REQ message provides five-tuple flow identification information (source IP address, source port, destination IP address, destination port, and protocol type) and EPS bearer ID (or radio bearer ID) information for identifying the bearer to which the flow belongs. If a TCP (or UDP) connection has been opened by the UE, the RTOP-Open-REQ message also includes context and state information of the connection, so that the eNB can continue the TCP (or UDP) connection on behalf of the UE.

In operation 435, the RTOP @ eNB 415 opens a TCP/IP connection on behalf of the UE. The eNB opens a TCP (or UDP) connection (if needed) based on the flow information provided by the UE. Alternatively, the eNB runs a TCP (or UDP) connection based on the context/state information of the connection provided by the UE. If the connection is successfully established or running, the eNB sends an RTOP-Open-RSP message indicating the status (success or failure) and the flow ID. Note that the eNB generates TCP/IP packets required for connection establishment using the flow identification information provided by the UE, and exchanges TCP/IP packets of the flow with the core network (S-GW/P-GW 420) over the S1-u interface.

At operation 440, the Apps @ UE 405 communicates with the RTOP @ UE410 using app data transmission. RTOP @ UE410 communicates with RTOP @ eNB using app data transmission. The RTOP @ eNB communicates with the S-GW/P-GW using the S1-u interface. Apps @ UE 405 sends Uplink (UL) data directly to RTOP @ UE410 bypassing the TCP/IP stack of the UE, and RTOP @ UE410 forwards the UL data to RTOP @ eNB 415 using PDCP. The RTOP @ eNB 415 adds a TCP/IP header and sends the data and TCP/IP header to the S-GW/P-GW 420 via the S1-u interface. On the other hand, the eNB 415 receives Downlink (DL) data via the S1-u interface and checks its TCP/IP header to determine whether the corresponding flow is an RTOP flow. If the corresponding flow is an RTOP flow, the eNB 415 removes the TCP/IP header and then sends the data on PDCP to the RTOP @ UE 410. RTOP @ UE410 then bypasses the TCP/IP stack of the UE and forwards the received data to Apps @ UE 405.

In operation 445, Apps @ UE 405 sends an RTOP close request (RTOP-close-REQ) to RTOP @ UE 410. RTOP @ UE 415 forwards the RTOP close request to RTOP @ eNB 415 along with the stream ID. At operation 450, the RTOP @ eNB 415 closes the TCP/IP connection on behalf of the UE. In operation 455, the RTOP @ eNB 415 sends an RTOP close-response (RTOP-close-RSP) including the stream ID to the RTOP @ UE 410. The RTOP @ UE410 forwards an RTOP close response including the stream ID to the Apps @ UE 405.

Apps @ UE 405 issues an RTOP-Close-REQ message to Close the RTOP session. The RTOP-Close-REQ message includes the stream ID information and also indicates whether to Close the corresponding tcp (udp) connection. In response, the eNB 415 closes the connection (if requested) and issues an RTOP-Close-RSP message. Alternatively, the eNB closes the RTOP session itself (triggered by the far end of the connection or other event (e.g., handover, RRC release)) and then issues an RTOP-Close-RSP message. If the TCP or UDP flow/connection is still in an open state, the eNB 415 includes context and state information of the TCP (UDP) connection in the RTOP-Close-RSP message so that the UE can continue the TCP (or UDP) connection after the RTOP session is closed.

After operation 455, the method 400 ends. It should be noted that method 400 may be used not only in a 3GPP RAN environment, but also in a non-3 GPP RAN environment (e.g., a Wi-Fi environment).

In some cases, PDCP is designed to support IP traffic on the u-plane only. With the new RTOP functionality, some aspects of the subject technology will enhance PDCP to support non-IP traffic in two ways: PDCP packet format for delivering RTOP packets; and some PDCP functions (e.g., header compression/decompression) may be skipped for RTOP packets.

Figure 5 illustrates an example PDCP/RTOP packet format 500. As shown, the packet format 500 includes a PDCP header 510, a RTOP header 520, and a RTOP payload 530. The PDCP header 510 includes a 1-bit flag indicating whether the PDCP packet is an IP packet or an RTOP packet. The RTOP header 520 includes a 1 byte (octet) field indicating the stream ID. RTOP payload 530 includes application (app) data.

Some aspects of the subject technology include adding a new bit flag in the PDCP header and indicating whether the PDCP payload is an IP packet or an RTOP packet. Each RTOP packet has an RTOP header in which a 1-byte field is used to indicate the flow ID of the flow to which the packet belongs.

Figure 6 illustrates an example flow 600 from a sending PDCP entity 605 to a receiving PDCP entity 610 in an evolved Universal Mobile Telecommunications System (UMTS) radio access network (E-UTRAN).

According to some mechanisms, the transmitting PDCP entity 605 applies sequence number (61)5 and header compression in the u-plane 620. Packets associated with PDCP SDUs receive integrity protection (625) in the c-plane and are ciphered (630), and PDCP headers are added to the packets (635). Packets not associated with a PDCP Service Data Unit (SDU) have a PDCP header added thereto (635). In operation 640, the packet is transferred from the transmitting PDCP entity 605 to the receiving PDCP entity on a radio interface (Uu).

The receiving PDCP entity 610 removes the PDCP header from the packet (645). For packets associated with PDCP SDUs, deciphering (650) and integrity verification (655) in the c-plane are applied. Operations 650 and 655 are skipped for packets not associated with PDCP SDUs. The receiving PDCP entity 610 applies header decompression in the u-plane at operation 660 and in-order delivery and duplicate detection in the u-plane at operation 665. In accordance with some aspects of the subject technology, header compression operation 620 and header decompression operation 660 are skipped for RTOP packets (but not for IP packets).

In summary, fig. 6 shows that the header compression/decompression (operations 620 and 660) function in PDCP is skipped for RTOP packets. For RTOP packets, other PDCP functions remain unchanged.

End-to-end (e2e) flow control is a TCP function. Thus, RTOP interacts with the TCP/IP stack and supports flow control. In the following, DL and UL are discussed separately in connection with fig. 7 and 8, respectively. In addition, PDCP and Radio Link Control (RLC) Acknowledged Mode (AM) are assumed to ensure in-sequence reliable delivery.

Fig. 7 is a data flow diagram illustrating an example of an enodeb-based downlink RTOP flow control 700. The data flow diagram shows the flow of data between Apps @ UE 405, RTOP @ UE 410, RTOP @ eNB 415, and S-GW/P-GW 420.

In operation 705, the S-GW/P-GW420 transmits TCP data to the RTOP @ eNB 415 in a General Packet Radio Service (GPRS) tunneling protocol user plane (GTP-u). RTOP @ eNB 415 sends application (app) data to RTOP @ UE 410 in PDCP/RTOP. RTOP @ UE 410 sends app data to Apps @ UE 405.

In operation 710, the RTOP @ UE 410 sends an RLC/automatic repeat request (ARQ) Acknowledgement (ACK) to the RTOP @ eNB 415. RTOP @ eNB 415 sends a TCP ACK to S-GW/P-GW420 in GTP-u.

In operation 715, the S-GW/P-GW420 transmits TCP data to the RTOP @ eNB 415 in GTP-u. RTOP @ eNB 415 sends app data to RTOP @ UE 410 in PDCP/RTOP. RTOP @ UE 410 forwards the app data to Apps @ UE 405.

In operation 720, the RTOP @ UE 410 sends an RLC/ARQ ACK to the RTOP @ eNB 415. RTOP @ eNB 415 sends a TCP ACK to S-GW/P-GW420 in GTP-u.

As shown in fig. 7, DL flow control is done entirely on the eNB side and has no impact on the UE. As shown in fig. 7, the eNB issues a "TCP ACK" packet to the far end of the TCP connection if the corresponding "TCP data" packet has been successfully delivered to the UE (based on information from RLC/ARQ). It should be noted that ARQ is supported in IEEE 802.11/Wi-Fi, so the proposed RTOP flow control mechanism is also available in case RTOP is used in a Wi-Fi network.

Fig. 8 is a data flow diagram illustrating an example of an user equipment based enode B assisted uplink RTOP flow control 800. The data flow diagram shows the flow of data between Apps @ UE 405, RTOP @ UE410, RTOP @ eNB 415, and S-GW/P-GW 420.

In operation 805, Apps @ UE 405 sends app data to RTOP @ UE 410. RTOP @ UE410 sends app data to RTOP @ eNB 415 in PDCP/RTOP. RTOP @ eNB 415 sends TCP data to the S-GW/P-GW in GTP-u. Similarly, app @ UE 405 sends app data to RTOP @ UE410 in operation 810. RTOP @ UE410 sends app data to RTOP @ eNB 415 in PDCP/RTOP. RTOP @ eNB 415 sends TCP data to the S-GW/P-GW in GTP-u. Similarly, Apps @ UE 405 sends app data to RTOP @ UE410 in operation 815. RTOP @ UE410 sends app data to RTOP @ eNB 415 in PDCP/RTOP. RTOP @ eNB 415 sends TCP data to the S-GW/P-GW in GTP-u.

At operation 820, RTOP @ eNB 415 determines that congestion exists. In response to determining that there is congestion, at operation 825, RTOP @ eNB 415 sends an RTOP Flow Stop command (RTOP-Flow-Stop-Cmd) to RTOP @ UE410, the command including the Flow ID.

At operation 830, RTOP @ eNB 415 determines that there is no congestion. In response to determining that there is no congestion, in operation 835, RTOP @ eNB 415 sends an RTOP Flow Start command (RTOP-Flow-Start-Cmd) including the Flow ID to RTOP @ UE 410.

At operation 840, app @ UE 405 sends app data to RTOP @ UE 410, similar to operation 805 @815. RTOP @ UE 410 sends app data to RTOP @ eNB 415 in PDCP/RTOP. RTOP @ eNB 415 sends TCP data to the S-GW/P-GW in GTP-u.

As shown in fig. 8, UL flow control is much more complex than the DL flow control of fig. 7 and involves both the eNB and the UE. In a first set of operations, RTOP @ eNB 415 monitors how much data in the buffer is waiting to be transmitted to the far end of the TCP connection to detect network congestion and issues an RTOP-Flow-Stop-Cmd message and an RTOP-Flow-Start-Cmd message accordingly. In a second set of operations, RTOP @ UE 410 stops receiving data from Apps @ UE 405 in response to the RTOP-Flow-Stop-Cmd message and resumes receiving data from Apps @ UE 405 in response to the RTOP-Flow-Start-Cmd message.

When the RTOP @ eNB 415 sends an RTOP Close response (RTOP-Close-RSP) response to Close the RTOP session, the eNB discards all remaining data in the buffer and also indicates the amount of data discarded and the status information of the TCP connection in the RTOP-Close-RSP message. Accordingly, the UE can resume the TCP/IP connection from the position where the data transmission was stopped.

Fig. 9 is a data flow diagram illustrating an example handover procedure 900 involving RTOP that may be implemented in a 3GPP cellular RAN environment. As shown, the 3GPP cellular RAN environment includes a UE902, a source eNB 904, a target eNB 906, a Mobility Management Entity (MME)908, and a serving gateway 910.

The Handover (HO) procedure includes operations 912 through 958 described below, where operations 920 through 930 are enhancements to the exchange procedure to support RTOP.

In operation 912, the source eNB 904 sends measurement control to the UE 902. In operation 914, packet data is exchanged between the UE 902 and the source eNB 904 and between the source eNB 904 and the serving gateway 910. In operation 916, an UL allocation is sent from the source eNB 904 to the UE 902. In operation 918, a measurement report is sent from the UE 902 to the source eNB 904.

At operation 920, a HO decision is made at the source eNB 904. With a positive HO decision, a handover request is sent from the source eNB 904 to the target eNB 906 at operation 922. At operation 924, the target eNB 906 acknowledges the handover request to the source eNB 904. In operation 926, a DL assignment is sent from the source eNB 904 to the UE 902. In operation 928, an RRC connection reconfiguration is sent from the source eNB 904 to the UE 902. At operation 930, a Sequence Number (SN) status is transmitted from source eNB 904 to target eNB 906. Operations 920 through 930 include an enhancement of the handover procedure to support RTOP.

At operation 932, data is forwarded from the source eNB 904 to the target eNB 906. In operation 934, synchronization information is forwarded from the UE 902 to the target eNB 906. In operation 936, UL allocation information and Tracking Area (TA) for the UE 902 is provided by the target eNB 906. In operation 938, the UE 902 notifies the target eNB 906 of the RRC connection reconfiguration complete. In operation 940, packet data is exchanged between the UE 902 and the target eNB 906. At operation 942, packet data is exchanged between target eNB 906 and serving gateway 910.

At operation 944, a path switch request is sent from the target eNB 906 to the MME 908. At operation 946, a user plane update request is sent from MME 908 to serving gateway 910. At operation 948, a endpoint flag is sent from serving gateway 910 to source eNB 904. At operation 950, packet data is sent from the serving gateway 910 to the target eNB 906. In operation 952, a endpoint marker is sent from the source eNB 904 to the target eNB 906. In operation 954, a user plane update response is sent from the serving gateway 910 to the MME 908. In operation 956, a path switch request acknowledgement (ack) is sent from the MME 908 to the target eNB 906. In operation 958, the UE context is released from the target eNB 906 to the source eNB 904.

To support RTOP, the source eNB 904 indicates that the UE 902 has an active RTOP session during the handover request operation 922. Source eNB 904 may also transmit RTOP context information for the UE (including status information for the RTOP-enabled TCP/UDP connection for the UE) to target eNB 906.

If the target eNB 906 does not support RTOP for the UE, the target eNB 906 indicates this at a handover request confirm operation 924 and the source eNB 904 then issues an RTOP-Close-RSP message to terminate all RTOP sessions at an RRC connection Reconfiguration operation 928.

If target eNB 906 supports RTOP, source eNB 904 transmits RTOP context information for UE 902 (including state information for RTOP-enabled TCP/IP sessions for the UE) to target eNB 906 at SN state transmission operation 930 so that these sessions can continue after the handover.

Fig. 10 illustrates an example of a portion of an end-to-end network architecture of a Long Term Evolution (LTE) network 1000 with various components of the network, in accordance with some embodiments. As used herein, an LTE network refers to both LTE and LTE-advanced (LTE-a) networks, as well as other versions of LTE networks that will be developed. The network 1000 may include a Radio Access Network (RAN) (e.g., E-UTRAN or evolved universal terrestrial radio access network as shown) 1001 and a core network 1020 (e.g., Evolved Packet Core (EPC) as shown) coupled together by an S1 interface 1015. For convenience and brevity, only a portion of the RAN 1001 and the core network 1020 are shown in this example. The network 1000 includes a UE 1002, which may correspond to one or more of the UEs 110A, 110B, 210A, 210B, 310A, 310B, and 902.

The core network 1020 may include a Mobility Management Entity (MME)1022, a serving gateway (serving GW)1024, and a packet data network gateway (PDN GW) 1026. RAN 1001 may include a skilled node b (enb)1004 (which may serve as a base station) for communicating with User Equipment (UE) 1002. enbs 1004 may include a macro eNB 1004a and a Low Power (LP) eNB 1004 b. eNB 1004 may correspond to one or more of enbs 120A, 120B, 220A, 220B, 904, and 906. MME 1022 may correspond to MME 908. Service gateway 1024 may correspond to service gateway 910. Serving gateway 1024 and PDN GW 1026 may correspond to S-GW/P-GW 420.

The MME 1022 may be similar in function to the control plane of a conventional Serving GPRS Support Node (SGSN). The MME 1022 may manage mobility aspects in access, such as gateway selection and tracking area list management. The serving GW 1024 may terminate the interface to the RAN 1001 and route data packets between the RAN 1001 and the core network 1020. In addition, the serving GW 1024 may be a local mobility anchor for inter-eNB handover and may also provide an anchor for inter-3 GPP mobility. Other functions may include lawful interception, billing, and some policy enforcement. The serving GW 1024 and MME 1022 may be implemented in one physical node or in different physical nodes.

The PDN GW 1026 may terminate the SGi interface to the Packet Data Network (PDN). The PDN GW 1026 may route data packets between the EPC 1020 and the external PDN, and may perform policy enforcement and charging data collection. The PDN GW 1026 may also provide an anchor point for mobility devices for non-LTE access. The external PDN may be an IP Multimedia Subsystem (IMS) domain as well as any kind of IP network. The PDN GW 1026 and serving GW 1024 may be implemented in a single physical node or in different physical nodes.

The eNB 1004 (macro and micro enbs) may terminate the air interface protocol and may be the first contact point for the UE 1002. In some embodiments, the eNB 1004 may perform various logical functions of the RAN 1001 including, but not limited to, RNCs (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. According to an embodiment, the UE 1002 may be configured to exchange Orthogonal Frequency Division Multiplexed (OFDM) communication signals with the eNB 1004 over a multicarrier communication channel in accordance with an OFDMA communication technique. The OFDM signal may include a plurality of orthogonal subcarriers.

The S1 interface 1015 may be an interface separating the RAN 1001 and the EPC 1020. The S1 interface 1015 is divided into two parts: S1-U, which may carry traffic data between the eNB 1004 and the serving GW 1024, and S1-MME, which may serve as a signaling interface between the eNB 1004 and the MME 1022. The X2 interface may be an interface between enbs 1004. The X2 interface may include two parts, X2-C and X2-U. X2-C may be a control plane interface between eNBs 1004 and X2-U may be a user plane interface between eNBs 1004.

For cellular networks, LP cell 1004b may be generally used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in heavily used areas. In particular, it is desirable to use different sized cells (macro cells, micro cells, pico cells, femto cells) to enhance the coverage of a wireless communication system to improve system performance. The different sized cells may operate on the same frequency band or may operate on different frequency bands (each cell operating in a different frequency band or only different sized cells operating on different frequency bands). As used herein, the term LP eNB refers to an eNB for implementing any relative LP for a smaller cell (than a macro cell), such as a femto cell, pico cell, or micro cell. A femto eNB may be generally provided by a mobile network operator to its home or business customer. A femto cell may generally have the size of a home gateway or smaller gateway and is generally connected to a broadband line. Femto cells may connect to the mobile operator's mobile network and provide additional coverage, typically in the range of 30 to 50 meters. Thus, LP eNB 1004b may be a femto cell eNB as it is coupled through PDN GW 1026. Similarly, a picocell may be a wireless communication system that generally covers a smaller area, such as an in-building (office, shopping mall, train station, etc.) or the nearest in-plane area. A picocell eNB may typically be connected to another eNB (through its Base Station Controller (BSC) functionality), such as a macro eNB, through an X2 link. Thus, LP eNB may be implemented with a picocell eNB as it may be coupled to a macro eNB 1004a via an X2 interface. The pico eNB or other LP eNB 1004b may fuse some or all of the functionality of the macro eNB LP eNB 1004 a. In some cases, this may be referred to as an access point base station or an enterprise femtocell.

In some embodiments, the UE 1002 may communicate with an Access Point (AP)1004 c. The AP1004c may communicate with the UE 1002 using only unlicensed spectrum (e.g., WiFi frequency bands). AP1004c may communicate with macro eNB 1004a (or LP eNB 1004B) over an Xw interface. In some embodiments, the AP1004c may communicate with the UE 1002 independently of communication between the UE 1002 and the macro eNB 1004A. In other embodiments, the AP1004c may be controlled by the macro eNB 1004A and use LWA, as described in more detail below.

Communications over an LTE network may be divided into 10ms frames, each of which may contain 10 1ms subframes. Each subframe of a frame may in turn contain two 0.5ms slots. Each subframe may be used for Uplink (UL) communication from the UE to the eNB or Downlink (DL) communication from the eNB to the UE. In one embodiment, the eNB may allocate a greater number of DL communications than UL communications in a particular frame. The eNB may schedule transmissions on the various frequency bands (f1 and f 2). The resource allocation in a subframe used in one frequency band may be different from that in another frequency band. Each slot of a subframe may contain 6 to 7 OFDM symbols, depending on the system used. In one embodiment, a subframe may contain 12 subcarriers. The downlink resource grid may be used for downlink transmissions from the eNB to the UE, while the uplink resource grid may be used for uplink transmissions from the UE to the eNB or from the UE to another UE. The resource grid may be a time-frequency grid, which is the physical resource of the downlink in each slot. The smallest time-frequency unit in the resource grid may be denoted as a Resource Element (RE). Each column and each row of the resource grid may correspond to one OFDM symbol and one OFDM subcarrier, respectively. The resource grid may contain Resource Blocks (RBs) describing the mapping of physical channels to resource elements and physical RBs (prbs). A PRB may be the smallest resource unit that may be allocated to a UE. A resource block may be 180kHz wide in frequency and 1 slot long in time. In frequency, a resource block may be 12x15 kHz subcarrier or 24x7.5 kHz subcarrier wide. For most channels and signals, 12 subcarriers may be used per resource block, depending on the system bandwidth. In Frequency Division Duplex (FDD) mode, the uplink and downlink frames may be 10ms and separated in frequency (full duplex) or time (half duplex). In a Time Division Duplex (TDD) mode, uplink and downlink subframes may be transmitted on the same frequency and multiplexed in the time domain. The duration of the resource grid 400 in the time domain corresponds to one subframe or two resource blocks. Each resource grid may include 12 (subcarriers) × 4 (symbols) ═ 168 resource elements.

Each OFDM symbol may contain a Cyclic Prefix (CP) and a Fast Fourier Transform (FFT) period, and the CP may be used to effectively cancel inter-symbol interference (ISI). The duration of the CP may be determined by the highest expected degree of delay spread. Although distortion from the previous OFDM symbol may exist in the CP, with a CP of sufficient duration, the previous OFDM symbol does not enter the FFT period. Once the FFT period signal is received and digitized, the receiver can ignore the signal in the CP.

There are several different physical downlink channels delivered using such resource blocks, including a Physical Downlink Control Channel (PDCCH) and a Physical Downlink Shared Channel (PDSCH). Each subframe may be divided into a PDCCH and a PDSCH. The PDCCH may generally occupy the first two symbols of each subframe and carry information about resource allocation and transmission format of a PDSCH channel, H-ARQ information about an uplink shared channel, and the like. The PDSCH may carry user data and higher layer signaling to the UE and occupy the remaining symbols of the subframe. In general, downlink scheduling may be performed at the eNB (assigning control and shared channel resource blocks to UEs in a cell) based on channel quality information provided to the eNB from the UEs, and then downlink resource assignment information may be sent to each UE on a PDCCH for (assigned to) the UE. The PDCCH may contain Downlink Control Information (DCI) in one of a plurality of formats that may indicate to the UE how to find and decode data transmitted on the PDSCH from the same subframe in the resource grid. The DCI format may provide details such as the number of resource blocks, resource allocation type, modulation scheme, transport block, redundancy version, coding rate, etc. Each DCI format may have a Cyclic Redundancy Code (CRC) and may be coded with a radio link temporary identifier (RNTI) that identifies the target UE for which the PDSCH is intended. The use of UE-specific RNTI may limit the decoding of DCI formats (and thus corresponding PDSCHs) to only the desired UE.

The embodiments described herein may be implemented in a system using any suitably configured hardware and/or software. Fig. 11 illustrates components of a UE according to some embodiments. At least some of the components shown in the figures may be used in an eNB or MME, e.g., implemented in UE 1002 or eNB 1004 shown in fig. 10. UE 1100 and other components may be configured to use synchronization signals as described herein. UE 1100 may be a stationary non-mobile device or may be a mobile device. In some embodiments, UE 1100 may include application circuitry 1102, baseband circuitry 1104, Radio Frequency (RF) circuitry 1106, Front End Module (FEM) circuitry 1108, and one or more antennas 110 coupled together at least as shown. At least some of the baseband circuitry 1104, RF circuitry 1106, and FEM circuitry 1108 may form a transceiver. In some embodiments, other network elements, such as enbs, may include some or all of the components shown in fig. 11. Other network elements, such as the MME, may include an interface (e.g., S1 interface) to communicate with the eNB over a wired connection with the UE.

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

The baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 1104 may include one or more baseband processors or control logic to process baseband signals received from the receive signal path of RF circuitry 1106 and to generate baseband signals for the transmit signal path of RF circuitry 1106. Baseband processing circuitry 1104 may interface with application circuitry 1102 for generating and processing baseband signals and for controlling the operation of RF circuitry 1106. For example, in some embodiments, the baseband circuitry 1104 may include a second generation (2G) baseband processor 1104a, a third generation (3G) baseband processor 1104b, a fourth generation (4G) baseband processor 1104c, and/or one or more other baseband processors 1104d for other existing generations, generations under development, or generations developed in the future (e.g., fifth generation (5G), 6G, etc.). Baseband circuitry 1104 (e.g., one or more baseband processors 1104a-d) may handle various radio control functions that enable communication with one or more radio networks via RF circuitry 1106. These radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 1104 may include FFT, precoding, and/or constellation mapping/demapping functionality. In some embodiments, the encoding/decoding circuitry of baseband circuitry 1104 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples and may include other suitable functions in other embodiments.

In some embodiments, baseband circuitry 1104 may include elements of a protocol stack, e.g., elements of an evolved universal terrestrial radio access network (E-UTRAN) protocol, including, e.g., Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and/or Radio Resource Control (RRC) elements. A Central Processing Unit (CPU)1104e of the baseband circuitry 1104 may be configured to run elements of a protocol stack for signaling of the PHY, MAC, RLC, PDCP, and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio Digital Signal Processors (DSPs) 1104 f. The audio DSP1104f may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. The components of the baseband circuitry may be suitably combined in a single chip or single chipset, or arranged on the same circuit board in some embodiments. In some embodiments, some or all of the components of baseband circuitry 1104 and application circuitry 1102 may be implemented together, for example, on a system on a chip (SOC).

In some embodiments, the baseband circuitry 1104 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 1104 may support communication with an Evolved Universal Terrestrial Radio Access Network (EUTRAN) and/or other Wireless Metropolitan Area Networks (WMANs), Wireless Local Area Networks (WLANs), Wireless Personal Area Networks (WPANs). Embodiments in which the baseband circuitry 1104 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry. In some embodiments, a device may be configured to operate in accordance with communication standards or other protocols or standards including Institute of Electrical and Electronics Engineers (IEEE)802.16 wireless technology (WiMax), IEEE 802.11 wireless technology (WiFi) including IEEE 802.11ad, which operates in the 60GHz millimeter wave spectrum, various other technologies such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Mobile Telecommunications System (UMTS), UMTS Terrestrial Radio Access Network (UTRAN), or other 2G, 3G, 4G, 5G technologies that have been or will be developed.

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

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

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

In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may comprise more than two mixers and may be arranged for quadrature down-conversion and/or up-conversion, respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., hartley image rejection). In some embodiments, the mixer circuitry 1106a and the mixer circuitry 1106a of the receive signal path may be arranged for direct down-conversion and/or direct up-conversion, respectively. In some embodiments, the mixer circuitry 1106a of the receive signal path and the mixer circuitry 1106a of the transmit signal path may be configured for superheterodyne operation.

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

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

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

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

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

Synthesizer circuit 1106d of RF circuit 1106 may include frequency dividers, Delay Locked Loops (DLLs), multiplexers, and phase accumulators. In some embodiments, the frequency divider may be a dual-mode frequency divider (DMD) and the phase accumulator may be a Digital Phase Accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by 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 divide the VCO period into Nd equal phase groups, Nd being the number of delay elements in the delay line. Thus, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

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

FEM circuitry 1108 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 1110, amplify the received signals, and provide amplified versions of the received signals to RF circuitry 1106 for further processing. FEM circuitry 1108 may also include a transmit signal path, which may include circuitry configured to amplify signals provided by RF circuitry 1106 for transmission by one or more of one or more antennas 1110.

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

In some embodiments, as described in more detail below, the UE 1100 may include additional elements such as memory/storage devices, displays, cameras, sensors, and input/output (I/O) interfaces. In some embodiments, the UE 1100 described herein may be part of a portable wireless communication device, such as a Personal Digital Assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless handset, a pager, an instant messaging device, a digital camera, an access point, a television, a medical device (e.g., a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly. In some embodiments, UE 1100 may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable interaction with peripheral components of the system. For example, the UE 1100 may include one or more of a keyboard, keypad, touchpad, display, sensor, non-volatile memory port, Universal Serial Bus (USB) port, audio jack, power supply interface, one or more antennas, graphics processor, application processor, speaker, microphone, and other I/O components. The display may be an LCD or LED screen including a touch screen. The sensors may include a gyroscope sensor, an accelerometer, a proximity sensor, a light-sensitive sensor, and a positioning unit. The positioning unit may communicate with components of a positioning network, such as Global Positioning System (GPS) satellites.

Antennas 1110 may include one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission by RF antennas. In some multiple-input multiple-output (MIMO) embodiments, antennas 1110 may be effectively separated to take advantage of spatial diversity and different channel characteristics that may result.

Although UE 1100 is shown with several different functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including Digital Signal Processors (DSPs), and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, Field Programmable Gate Arrays (FPGAs), Application Specific Integrated Circuits (ASICs), Radio Frequency Integrated Circuits (RFICs), and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, a functional element may refer to one or more processes running on one or more processing elements.

Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer). For example, a computer-readable storage device may include Read Only Memory (ROM), Random Access Memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, and other storage devices and media. Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.

Fig. 12 is a block diagram of a communication device 1200 according to some embodiments. The communication device 1200 may be a UE or an eNB, such as UE 1002 or eNB 1004 shown in fig. 10. Physical layer circuitry 1202 may perform various encoding and decoding functions, which may include forming a baseband signal for transmission and decoding a received signal. The communication device 1200 may also include a medium access control layer (MAC) circuit 1204 for controlling access to the wireless medium. The communication device 1200 may also include processing circuitry 1206 (e.g., one or more single-core or multi-core processors) and memory 1208 arranged to perform the operations described herein. The physical layer circuitry 1202, MAC circuitry 1204, and processing circuitry 1206 may handle various radio control functions that enable communication with one or more radio networks compatible with one or more radio technologies. These radio control functions may include signal modulation, encoding, decoding, radio frequency shifting, and the like. For example, similar to the devices shown in fig. 2, in some embodiments, communications may be enabled using one or more of WMAN, WLAN, and WPAN. In some embodiments, the communication device 1200 may be configured to operate in accordance with 3GPP standards or other protocols or standards including WiMax, WiFi, WiGig, GSM, EDGE, GERAN, UMTS, UTRAN, or other 3G, 4G, 5G, etc. technologies that have or will be developed. The communication device 1200 may include transceiver circuitry 1212 to enable wireless communication with other external devices and an interface 1214 to enable wired communication with other external devices. As another example, the transceiver circuitry 1212 may perform various transmit and receive functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.

The antenna 1201 may include one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals. In some MIMO embodiments, antennas 1201 may be effectively separated to take advantage of spatial diversity and different channel characteristics that may result.

Although communication device 1200 is shown with a number of different functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements (e.g., processing elements including DSPs) and/or other hardware elements. For example, some elements may comprise one or more microprocessors, DSPs, FPGAs, ASICs, RFICs, and combinations of various hardware and logic circuitry for performing at least the functions described herein. In some embodiments, a functional element may refer to one or more processes running on one or more processing elements. Embodiments may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein.

Fig. 13 illustrates another block diagram of a communication device 1300 according to some embodiments. The communications device 1300 may correspond to a UE 1002 or an eNB 1004. In alternative embodiments, the communication device 1300 may operate as a standalone device or may be connected (e.g., networked) to other communication devices. In a networked deployment, the communication device 1300 may operate in the server-client network environment with the identity of a server communication device, a client communication device, or both. In one example, the communications device 1300 may operate as a peer to peer communications device in a peer to peer (P2P) (or other distributed) network environment. The communication device 1300 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, network device, network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by the communication device. Additionally, although only one communication device is shown, the term "communication device" should also be understood to include any collection of communication devices (e.g., cloud computing, service software (SaaS), other computer cluster configurations) that individually or together execute one or more sets of instructions to perform any one or more of the methods described herein.

Examples described herein may include, or operate on, logic or multiple components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing specified operations and may be configured or arranged in some manner. In one example, the circuitry may be arranged as modules in a specified manner (e.g., internally or with respect to an external example such as another computer). In one example, one or more computer systems (e.g., a separate client or server computer system) or one or more hardware processors in whole or in part can be arranged by firmware or software (e.g., instructions, application portions, or applications) as a module that operates to perform specified operations. In one example, the software may reside on a communication device readable medium. In one example, software, when executed by underlying hardware of the module, causes the hardware to perform specified operations.

Thus, the term "module" is understood to cover a tangible entity, which may be a physical construct, a specialized configuration (e.g., hardwired), or a temporary (e.g., temporary) configuration (e.g., programmed) to operate in a specified manner or to perform some or all of any of the operations described herein. Considering the example of modules being temporarily configured, each module need not be instantiated at any one time in time. For example, when the modules include a general purpose hardware processor configured using software, the general purpose hardware processor may be configured as respective different modules at different times. The software may configure the hardware processor accordingly, e.g., to constitute a particular module at one time and another module at another time.

The communication device (e.g., computer system) 1300 may include a hardware processor 1302 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a hardware processor core, or any combination thereof), a main memory 1304, and a static memory 1306, some or all of which may communicate with each other via a link (e.g., a bus) 1308. The communication device 1300 may also include a display unit 1310, an alphanumeric input device 1312 (e.g., a keyboard), and a User Interface (UI) navigation device 1314 (e.g., a mouse). In one example, the display unit 1310, input device 1312, and UI navigation device 1314 may be touch screen displays. The communication device 1300 may additionally include a storage device (e.g., a driver unit) 1316, a signal generation device 1318 (e.g., a speaker), a network interface device 1320, and one or more sensors 1321 (e.g., a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor). The communication device 1300 may include an output controller 1328, such as a serial (e.g., Universal Serial Bus (USB)), parallel, or other wired or wireless (e.g., Infrared (IR), Near Field Communication (NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

The storage 1316 may include a communication device readable medium 1322 on which is stored one or more sets of data structures or instructions 1324 (e.g., software) embodying or utilized by one or more of the techniques or functions described herein. The instructions 1324 may also reside, completely or at least partially, within the main memory 1304 or static memory 1306, or within the hardware processor 1302 during execution thereof by the communication device 1300. In one example, one or any combination of hardware processor 1302, main memory 1304, static memory 1306, or storage device 1316 may constitute communication device readable media.

While the communication device-readable medium 1322 is illustrated as a single medium, the term "communication device-readable medium" can include one or more media (e.g., a centralized or distributed database, and/or associated caches and servers) that are configured to store the one or more instructions 1324.

The term "communication device-readable medium" can include any medium that can store, encode, or carry data structures for execution by the communication device 1300 and that cause the communication device 1300 to perform any one or more of the techniques of this disclosure, or that can store, encode, or carry data structures used by or associated with these instructions. Non-limiting examples of communication device readable media may include solid state memory, optical, and magnetic media. Specific examples of the communication device-readable medium may include nonvolatile memory, for example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices, magnetic disks such as an internal hard disk or removable disk, magneto-optical disks, Random Access Memory (RAM), and CD-ROM and DVD-ROM disks. In some examples, the communication device readable medium may include a non-transitory communication device readable medium. In some embodiments, the communication device readable medium may include a communication device readable medium that is not a transitory propagating signal.

Multiple transport protocols (e.g., frame relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP)' may also be utilized,Hypertext transfer protocol (HTTP), etc.), the instructions 1324 are transmitted or received over the communications network 1326 using a transmission medium via the network interface device 1320. Example communication networks may include a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network (e.g., referred to as a "plain old telephone network")

Of the Institute of Electrical and Electronics Engineers (IEEE)802.11 family of standards, referred to as

IEEE 802.16 family of standards, IEEE 802.15.4 family of standards, Long Term Evolution (LTE) family of standards, Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks), and the like. In one example, the network interface device 1320 may include one or more physical jacks (e.g., ethernet, coaxial cable, telephone jacks) or one or more antennas to connect to the communications network 1326. In one example, the network interface device 1320 may include multiple antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, network interface device 1320 may wirelessly communicate using multi-user MIMO techniques. The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 1300, and includes digital or analog communication signals or other intangible medium to facilitate communication of such software.

The subject technology is described below in connection with various examples.

Example 1 is an apparatus of a User Equipment (UE), the apparatus comprising: a processing circuit and a memory, the processing circuit: encoding a message from a socket and connection manager of an operating system to a Radio Access Network (RAN) -based Transmission Control Protocol (TCP) offload protocol (RTOP) layer, the message for requesting network infrastructure equipment to open and run a TCP or User Datagram Protocol (UDP) connection on behalf of the UE or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection that has been previously opened by the UE; encoding, using an RTOP layer, a request for a network infrastructure device to open or run a TCP or UDP connection on behalf of a UE, the request including flow identification information and TCP context information, the request causing the network infrastructure device to open or run the TCP or UDP connection based on the flow identification information and the TCP context information; accessing acknowledgement information that a TCP or UDP connection received from a network infrastructure device was successfully opened or run; and encoding Uplink (UL) data associated with the TCP or UDP connection for transmission from the socket and connection manager using the RTOP layer while bypassing the TCP/IP stack to the network infrastructure device using the wireless link layer protocol.

In example 2, the subject matter of example 1 optionally includes the processing circuit further to: accessing DL data received from a network infrastructure device using an RTOP layer; and decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

In example 3, the subject matter of any of examples 1 to 2 optionally includes the processing circuit to further: after encoding a request to open a TCP or UDP connection for a network infrastructure device, accessing an indication that the network infrastructure device opened a TCP or UDP connection.

In example 4, the subject matter of any of examples 1 to 2 optionally includes the request to open and run a TCP or UDP connection for the network infrastructure device to include a Radio Resource Control (RRC) message, an IEEE 802.11 management frame, or a general UDP/IP message.

In example 5, the subject matter of any of examples 1-2 can optionally include that the flow identification information includes a five-tuple including a source IP address, a source port, a destination IP address, a destination port, and a protocol type, wherein the request further includes an Evolved Packet System (EPS) bearer identifier or a radio bearer identifier if the network architecture device is based on a third generation partnership project (3GPP) cellular Radio Access Technology (RAT), and wherein the request further includes TCP context and status information if a TCP connection has been opened.

In example 6, the subject matter of any of examples 1 to 2 optionally includes the processing circuit to further: encoding an instruction to close a TCP or UDP connection for a network infrastructure device, the instruction identifying flow identification information; and receiving acknowledgement information from the network infrastructure device that the TCP or UDP connection is closed.

In example 7, the subject matter of any of examples 1 to 2 optionally includes the processing circuit to further: encoding an instruction to a network architecture device to stop a RTOP operation for a flow, the instruction including flow identification information; and accessing acknowledgement information that the RTOP operation received from the network infrastructure device has been stopped, the acknowledgement information for the UE to continue the flow itself, the acknowledgement information including TCP context and state information for the flow.

In example 8, the subject matter of any of examples 1 to 2 optionally includes the processing circuitry further to: accessing an indication that the RTOP operation received from the network infrastructure device has been stopped and the UE continues with the flow itself, the indication including TCP context and state information for the flow.

In example 9, the subject matter of any of examples 1 to 2 optionally includes that the radio link layer protocol comprises Packet Data Convergence Protocol (PDCP), and wherein the data encoded using PDCP comprises a bit flag in a PDCP header indicating that the particular packet is an RTOP packet and not an IP packet.

In example 10, the subject matter of any of examples 1-2 optionally includes the socket and connection manager comprising a process or one or more applications residing in the operating system for managing TCP/IP sockets and connections.

In example 11, the subject matter of any of examples 1 to 2 optionally includes the wireless link layer protocol being configured to operate in accordance with Institute of Electrical and Electronics Engineers (IEEE)802.11 ethernet or a "0 hop" internet protocol.

In example 12, the subject matter of any of examples 1 to 2 optionally includes the RTOP header including flow identification information.

In example 13, the subject matter of any of examples 1 to 2 optionally includes that the processing circuitry comprises a baseband processor.

In example 14, the subject matter of any of examples 1-2 optionally includes: transceiver circuitry to: sending a request for a network architecture device to open and run a TCP or UDP connection on behalf of the UE, and sending UL data to the network architecture device using PDCP; and an antenna coupled to the transceiver circuitry.

Example 15 is an apparatus of a network architecture device, the apparatus comprising processing circuitry and memory; the processing circuit: accessing flow identification information received from a User Equipment (UE); generating a Transmission Control Protocol (TCP)/Internet Protocol (IP) packet for opening a TCP or User Datagram Protocol (UDP) connection by using the accessed flow identification information, the TCP or UDP connection being opened on behalf of the UE; encoding the generated TCP/IP packet for exchange with a core network over an S1-u interface; accessing Uplink (UL) data received from a UE using a Packet Data Convergence Protocol (PDCP); adding a TCP/IP header to the accessed UL data; and encoding the accessed UL data with the TCP/IP header added for transmission over the S1-u interface.

In example 16, the subject matter of example 15 optionally includes the processing circuit to further: accessing Downlink (DL) data received on an S1-u interface; determining, based on a TCP/IP header of the DL data, that a corresponding flow of the DL data is a Radio Access Network (RAN) -based TCP offload protocol (RTOP) flow; removing the TCP/IP header from the accessed DL data in response to determining that the respective flow is an RTOP flow; and encoding the accessed DL data without TCP/IP headers for transmission to an RTOP layer at the UE using PDCP.

In example 17, the subject matter of example 15 optionally includes the processing circuit to further: determining that reception of the DL data is acknowledged at the UE; upon determining that receipt of the accessed DL data is acknowledged at the UE, a TCP Acknowledgement (ACK) packet is encoded for transmission to the core network.

In example 18, the subject matter of example 15 optionally includes the processing circuit to further: a notification that a TCP or UDP connection for the UE has been opened is encoded.

In example 19, the subject matter of example 15 optionally includes the processing circuit to further: accessing a message from the UE to close the TCP or UDP connection, the message identifying flow identification information; closing a TCP or UDP connection in response to the message; and notifying the UE that the TCP or UDP connection has been closed.

In example 20, the subject matter of example 15 optionally includes the processing circuit to further: closing the TCP or UDP connection in response to a trigger of the remote end of the TCP or UDP connection; and notifying the UE that the TCP or UDP connection has been closed.

In example 21, the subject matter of example 15 optionally includes that the data accessed using PDCP comprises a bit flag in a PDCP header indicating whether the particular packet is an RTOP packet or an IP packet.

In example 22, the subject matter of example 21 optionally includes the processing circuit to further: applying a header compression/decompression function for the specific packet in case that the bit flag in the PDCP header indicates that the specific packet is an IP packet; and in the event that the bit flag in the PDCP header indicates that the particular packet is an RTOP packet, forgoing application of the header compression/decompression function for the particular packet.

In example 23, the subject matter of example 15 optionally includes the processing circuit to further: monitoring an amount of UL data received from the UE in a buffer awaiting transmission over the S1-u interface using TCP; notifying the UE to stop receiving data from a higher layer and stop transmitting UL data when it is detected that the amount of UL data exceeds a first threshold; upon detecting that the amount of UL data is below a second threshold, the UE is notified to resume receiving data from higher layers and to resume transmitting UL data.

In example 24, the subject matter of example 15 optionally includes the processing circuit to further: encoding an indication that a UE for a target eNB has an active RTOP session; determining whether the target eNB supports RTOP; when it is determined that the target eNB supports RTOP, encoding transmission of RTOP context information of the UE for continuing an RTOP session at the target eNB; and encoding termination of the RTOP session with the UE upon determining that the target eNB does not support RTOP.

In example 25, the subject matter of example 15 optionally includes the processing circuit to further: when the RTOP session is terminated, encoding a message that the RTOP session to the UE is terminated, the message including flow identification information of the RTOP session and TCP context and state information of the flow for the UE to continue with the flow itself.

Example 26 is a machine-readable medium storing instructions that, when executed by processing circuitry of a User Equipment (UE), cause the processing circuitry to: encoding a message from a socket and connection manager of an operating system to a Radio Access Network (RAN) -based Transmission Control Protocol (TCP) offload protocol (RTOP) layer, the message for requesting network infrastructure equipment to open and run a TCP or User Datagram Protocol (UDP) connection on behalf of a UE or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection that has been previously opened by the UE; encoding, using an RTOP layer, a request for a network infrastructure device to open or run a TCP or UDP connection on behalf of a UE, the request including flow identification information and TCP context information, the request causing the network infrastructure device to open or run the TCP or UDP connection based on the flow identification information and the TCP context information; accessing acknowledgement information that a TCP or UDP connection received from a network infrastructure device was successfully opened or run; and encoding Uplink (UL) data associated with the TCP or UDP connection for transmission from the socket and connection manager using the RTOP layer while bypassing the TCP/IP stack to the network infrastructure device using the wireless link layer protocol.

In example 27, the subject matter of example 26 optionally includes the machine-readable medium further storing instructions that, when executed by the processing circuitry, cause the processing circuitry to: accessing DL data received from a network infrastructure device using an RTOP layer; and decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

Example 28 is an apparatus of a User Equipment (UE), the apparatus comprising: means for encoding a message from a socket and connection manager of an operating system to a Radio Access Network (RAN) based Transmission Control Protocol (TCP) offload protocol (RTOP) layer, the message for requesting a network infrastructure device to open and run a TCP or User Datagram Protocol (UDP) connection on behalf of the UE or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection that has been previously opened by the UE; means for encoding, using the RTOP layer, a request for a network infrastructure device to open or run a TCP or UDP connection on behalf of the UE, the request including flow identification information and TCP context information, the request causing the network infrastructure device to open or run the TCP or UDP connection based on the flow identification information and the TCP context information; means for accessing acknowledgement information that a TCP or UDP connection received from a network infrastructure device was successfully opened or run; and means for encoding Uplink (UL) data associated with the TCP or UDP connection for transmission from the socket and connection manager using the RTOP layer while bypassing the TCP/IP stack to the network infrastructure device using the wireless link layer protocol.

In example 29, the subject matter of example 28 can optionally include: means for accessing DL data received from a network infrastructure device using an RTOP layer; and means for decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

Although embodiments have been described with reference to specific example embodiments, it will be readily understood that various modifications and changes may be made to these embodiments. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings that form a part hereof show by way of illustration, and not of limitation, specific embodiments in which the subject matter may be practiced. The embodiments illustrated are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments may be utilized and derived, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The detailed description is, therefore, not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims and equivalents of their full scope.

Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the above description.

In this document, as in patent documents, the terms "a" or "an" are used to include one or more, independent of any other instances or uses of "at least one" or "one or more". In this document, unless indicated to the contrary, the term "or" is used to refer to a non-exclusive or, thus "a or B" includes "a instead of B", "B instead of a", and "a and B". In this document, the terms "including" and "in which" are used as the plain-english equivalents of the respective terms "comprising" and "wherein". In addition, in the following claims, the terms "include" and "comprise" are open-ended, i.e., a system, UE, product, composition, formulation, or process that includes other elements in addition to those listed after such term in a claim is considered to fall within the scope of that claim, and further, in the appended claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not used to impose numerical requirements on such objects.

Thus the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment.

Claims (15)

1. An apparatus of a User Equipment (UE), the apparatus comprising:

a processing circuit and a memory, the processing circuit:

encoding a message from a socket and connection manager of an operating system to a Radio Access Network (RAN) based Transmission Control Protocol (TCP) offload protocol (RTOP) layer requesting network infrastructure equipment to open and run a TCP or User Datagram Protocol (UDP) connection on behalf of the UE or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection that has been previously opened by the UE, wherein the RTOP layer is above a PDCP layer for offloading TCP/IP processing of the UE to the network infrastructure equipment;

encoding, using the RTOP layer, a request for the network infrastructure device to open or run the TCP or UDP connection on behalf of the UE, the request including flow identification information and TCP context information, the request causing the network infrastructure device to open or run the TCP or UDP connection based on the flow identification information and the TCP context information;

decoding acknowledgement information received from the network infrastructure device that the TCP or UDP connection was successfully opened or run; and

encoding Uplink (UL) data associated with the TCP or UDP connection for transmission from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack to the network infrastructure device using a wireless link layer protocol, wherein the RTOP layer of the network infrastructure device adds a TCP/IP header to the received UL data for transmission to a core network.

2. The apparatus of claim 1, wherein the processing circuit is further to:

accessing DL data received from the network infrastructure device using the RTOP layer; and

decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

3. The apparatus of claim 1, wherein the processing circuit is further to:

accessing an indication that the network infrastructure device opened the TCP or UDP connection after encoding the request to open the TCP or UDP connection for the network infrastructure device.

4. The apparatus of claim 1, wherein the request to open and run the TCP or UDP connection for the network infrastructure device comprises a Radio Resource Control (RRC) message, an IEEE 802.11 management frame, or a generic UDP/IP message.

5. The apparatus of claim 1, wherein the flow identification information comprises a five-tuple comprising a source IP address, a source port, a destination IP address, a destination port, and a protocol type, wherein the request further comprises an Evolved Packet System (EPS) bearer identifier or a radio bearer identifier if the network architecture device is based on a third generation partnership project (3GPP) cellular Radio Access Technology (RAT), and wherein the request further comprises the TCP context and state information if the TCP connection has been opened.

6. The apparatus of claim 1, wherein the processing circuit is further to:

encoding an instruction to the network infrastructure device to close the TCP or UDP connection, the instruction identifying the flow identification information; and

receiving acknowledgement information from the network infrastructure device that the TCP or UDP connection is closed.

7. The apparatus of claim 1, wherein the processing circuit is further to:

encoding an instruction for the network infrastructure device to cease an RTOP operation for the flow, the instruction including the flow identification information; and

decoding acknowledgement information received from the network infrastructure device that the RTOP connection has been stopped, the acknowledgement information for the UE to continue with the flow itself, the acknowledgement information including the TCP context and state information for the flow.

8. The apparatus of claim 1, wherein the processing circuit is further to:

decoding an indication received from the network architecture device that the RTOP operation has been stopped and that the UE continues with the flow itself, the indication comprising the TCP context and state information for the flow.

9. The apparatus of claim 1, wherein the radio link layer protocol comprises Packet Data Convergence Protocol (PDCP), and wherein the data encoded using PDCP comprises a bit flag in a PDCP header indicating that a particular packet is an RTOP packet and not an IP packet.

10. The apparatus of claim 1, wherein the socket and connection manager comprises one or more applications or processes residing in the operating system for managing TCP/IP sockets and connections.

11. The apparatus of claim 1, wherein the wireless link layer protocol is configured to operate in accordance with Institute of Electrical and Electronics Engineers (IEEE)802.11 ethernet or a "0 hop" internet protocol.

12. The apparatus of claim 1, wherein an RTOP header comprises the flow identification information.

13. The apparatus of claim 1, wherein the processing circuitry comprises a baseband processor.

14. An apparatus of a User Equipment (UE), the apparatus comprising:

means for encoding a message from a socket and connection manager of an operating system to a Radio Access Network (RAN) based Transmission Control Protocol (TCP) offload protocol (RTOP) layer requesting a network infrastructure device to open and run a TCP or User Datagram Protocol (UDP) connection on behalf of the UE or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection that has been previously opened by the UE, wherein the RTOP layer is above the PDCP layer for offloading TCP/IP processing of the UE to the network infrastructure device;

Means for encoding, using the RTOP layer, a request for the network architecture device to open or run the TCP or UDP connection on behalf of the UE, the request including flow identification information and TCP context information, the request causing the network architecture device to open or run the TCP or UDP connection based on the flow identification information and the TCP context information;

means for accessing acknowledgement information received from the network infrastructure device that the TCP or UDP connection was successfully opened or run; and

means for encoding Uplink (UL) data associated with the TCP or UDP connection for transmission from the socket and connection manager that uses the RTOP layer while bypassing a TCP/IP stack to the network infrastructure device that uses a wireless link layer protocol, wherein the RTOP layer of the network infrastructure device adds a TCP/IP header to the received UL data for transmission to a core network.

15. The apparatus of claim 14, further comprising:

means for accessing DL data received from the network infrastructure device using the RTOP layer; and

means for decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

Images