WO2017213654A1 - Offloading processing from user equipment to network - Google Patents

Abstract

Embodiments of offloading TCP/IP processing from a user equipment to a network device are described. A user equipment (UE) encodes a message, from a socket/connection manager of an operating system to a RAN-based TCP offload protocol (RTOP) layer, for requesting a network device to open and run a TCP/UDP connection on the UE's behalf or to run TCP/IP processing for an existing TCP/UDP connection which has previously been opened by the UE. The UE encodes, using the RTOP layer, a request for the network device to open or run the TCP/UDP connection on the UE's behalf, the request comprising flow identification information and 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 a confirmation, received from the network device, that the TCP/UDP connection is opened or ran successfully.

Description

OFFLOADING PROCESSING FROM USER EQUIPMENT TO NETWORK

TECHNICAL FIELD

[0001] Embodiments pertain to wireless communications. Some embodiments relate to radio access network layers 2 and 3 (RAN2/RAN3) in fifth generation (5G) systems. Some embodiments relate to offloading transmission control protocol/ Internet protocol (TCP/IP) processing from a user equipment to a network infrastructure device, such as an evolved NodeB or an access point.

BACKGROUND

[0002] In a cellular or WiFi network, a user equipment (UE) may be provided to a user and may have limited processing abilities. A network infrastructure device, such as an evolved NodeB or an access point may have greater processing abilities. As the foregoing illustrates, techniques for offloading transmission control protocol/ Internet protocol (TCP/IP) processing from the user equipment to the network infrastructure device may be desirable.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIGS. 1 A-1B illustrates an example transmission control protocol/ Internet protocol (TCP/IP) protocol stack in long term evolution (LTE).

[0004] FIGS. 2A-2B illustrate an example radio access network (RAN) based TCP/IP offload protocol (RTOP) stack.

[0005] FIGS. 3 A-3B illustrate an example RTOP stack that conforms to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 Ethernet standard. [0006] FIG. 4 is a data flow diagram illustrating an example user equipment-initiated RTOP communication method.

[0007] FIG. 5 illustrates an example packet data convergence protocol

(PDCP)/ RTOP packet format.

[0008] FIG. 6 illustrates an example flow from a transmitting PDCP entity to a receiving PDCP entity.

[0009] FIG. 7 is a data flow diagram illustrating an example of evolved

NodeB based downlink RTOP flow control.

[0010] FIG. 8 is a data flow diagram illustrating an example of user equipment based evolved NodeB assisted uplink RTOP flow control.

[0011] FIG. 9 is a data flow diagram illustrating an example handover procedure.

[0012] FIG. 10 is a functional diagram of a wireless network in accordance with some embodiments.

[0013] FIG. 11 illustrates components of a communication device in accordance with some embodiments.

[0014] FIG. 12 illustrates a block diagram of a communication device in accordance with some embodiments.

[0015] FIG. 13 illustrates another block diagram of a communication device in accordance with some embodiments.

DETAILED DESCRIPTION

[0016] 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, process, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.

[0017] FIGS. 1 A-1B illustrates an example TCP/IP protocol stack in

LTE, with the u-plane illustrated in Fig. 1 A and the c-plane illustrated in FIG.

IB. [0018] As shown in FIG. 1A, in the u-plane, the UE 110A and the eNB

120 A are connected via a Uu interface. The UE 110A includes an application (Apps) layer, followed by a TCP/UDP layer, followed by an IP layer, followed by a PDCP layer, followed by a radio link control (RLC) layer, followed by a physical/ medium access control (PHY/MAC) layer. The eNB 120a includes a PDCP layer, followed by a RLC layer, followed by a PHY/MAC layer.

[0019] As shown in FIG. IB, in the c-plane, the UE 110B and the eNB

120B are connected via a Uu interface. The UE HOB includes a radio resource control (RRC) layer, followed by a PDCP layer, followed by a RLC layer, followed by a PHY/MAC layer. The eNB 120B includes a RRC layer, followed by a PDCP layer, followed by a RLC layer, followed by a PHY/MAC layer.

[0020] Fifth generation (5G) cellular radio access technology (RAT) is targeted at higher peak data rates (e.g., 10 gigabits per second (GBPS)) than long term evolution (LTE). However, in general, roughly 1 Hertz of central processing unit (CPU) processing is required to send or receive one bit per second of transmission control protocol/ Internet protocol (TCP/IP). For example, 5 GBPS of network traffic requires 5 gigahertz (GHz) of CPU processing. This implies that 2 entire cores of a 2.5 GHz multi-core processor may be required to handle the TCP/IP processing associated with 5 GBPS of TCP/IP traffic.

[0021] TCP offload engine (TOE) is used in network interface cards to offload processing of the TCP/IP stack to the network controller. It is primarily used with high-speed network interfaces, such as gigabit Ethernet and 10 Gigabit Ethernet, where processing overhead of the network stack becomes significant. TOE may be used with the next-generation (e.g., 5G) cellular network interface to reduce the CPU cycles of the application processor of a mobile device.

However, use of TOE may increase the CPU cycles of the communication processor (CP), which is still on the mobile device and, therefore, still takes resource and power from the device.

[0022] Some aspects of the subject technology address the problem in the computer/ cellular arts of reducing TCP/IP processing (and, therefore, resource and battery usage) at the user equipment (UE). According to some implementations, the solution to this problem includes a TCP/IP offload architecture along with necessary air-interface changes to offload the TCP/IP stack completely out of the UE, and to the serving evolved NodeB (eNB) or WiFi access point (AP). Some implementations support both TCP and user datagram protocol (UDP) traffic.

[0023] In this document, LTE terminology (e.g., UE, eNB, and the like) may be used to identify both nodes in the LTE network and nodes in other networks (e.g., WiFi, 5G, and the like) that may share similar logical or conceptual functionalities with the LTE nodes.

[0024] Some implementations include, as one principle of operation, letting the eNB establish a TCP or UDP connection on UE's behalf, and take care of all TCP/IP processing for the connection. As a result, the UE directly processes the raw application data or data from the socket and connection manager of an operating system of the UE.

[0025] Some TOE solutions offload TCP/IP processing from the application processor to the communication/ network processor, which is still on the UE. For instance, the TCP engine proxy solution offloads TCP

functionalities to an edge cloud. However, this solution is based on higher layer (transport or application layers from the Open Systems Interconnection (OSI) model) protocols. The TCP engine proxy solution has the limitations of:

additional UDP/IP protocol processing for tunneling, and additional

retransmission or coding for reliable packet delivery.

[0026] Some aspects of the subject technology provides, among other things, the following: offloading TCP/IP processing completely out of the UE, and to the eNB or AP; relying on the third generation partnership program (3GPP) radio access network (RAN) (LTE) protocols, such as packet data convergence protocol (PDCP) and radio link control/ automatic repeat request (RLC/ARQ) to ensure reliable and in-order packet delivery without additional overhead; transferring application data directly over the 3 GPP RAN (LTE) protocol, for example, PDCP without additional transport layer or IP layer (in OSI model) protocol processing; and supporting end-to-end (e2e) flow control by tight-cooperation between the 3 GPP RAN (LTE) stack and the TCP/IP stack. [0027] FIGS. 2A-2B illustrate an example RAN-based TCP/IP offload protocol (RTOP) stack, with the u-plane illustrated in FIG. 2A and the c-plane illustrated in FIG. 2B.

[0028] As shown in FIG. 2A, in the u-plane, the UE 21 OA is connected to the eNB 220A via a Uu interface. The UE 210A is structured similarly to the UE 110A of FIG. 1 A, with an RTOP-u layer being added adjacent to the TCP/UDP and IP layers, above the PDCP layer and below the Apps layer. The eNB 220A includes an RTOP-u layer. Below the RTOP-u layer are (1) a PDCP layer, a RLC layer, and a PHY/MAC layer, in that order, and (2) a TCP/UDP layer and an IP layer, in that order. The PDCP layer is adjacent to the TCP/UDP layer, and the IP layer is adjacent to the RLC and PHY/MAC layers.

[0029] As shown in FIG. 2B, in the c-plane, the UE 210B and the eNB

220B are connected via a Uu interface. The UE 210B is similar to the UE HOB, with a RTOP-c layer above the RRC layer. The eNB 220B is similar to the eNB 120B, with a RTOP-c layer above the RRC layer.

[0030] FIGS. 1 A- IB show the TCP/IP protocol stack in the LTE system, and FIGS. 2A-2B show the proposed RTOP stack. As shown in FIGS. 1 A- IB and 2A-2B, the proposed RTOP architecture impacts the access, and does not impact the core. As shown in FIGS. 2A-2B, a new RTOP layer is added over the top of PDCP on both UE and eNB for offloading UE' s TCP/IP processing to the eNB.

[0031] Some aspects of the subject technology include enhancing PDCP in order to interface with the new RTOP layer. In some schemes, PDCP is designed to only interface with the IP layer, as shown in FIGS. 1 A-1B.

However, as shown in FIGS. 2A-2B, in the proposed RTOP architecture, the TCP/IP stack operates on top of PDCP in a similar manner to that shown in FIGS. 1A-1B. In some cases, RTOP-u functionalities are integrated into PDCP, and RTOP-c functionalities are integrated into RRC. In these cases, a new layer (RTOP) does not need to be introduced in the cellular RAN protocol stack.

[0032] On the other hand, the proposed RTOP solution operates only after the UE is attached, and has no impact on the existing bearer (packet data network (PDN)) establishment procedure. The UE maintains its IP address allocated by the packet gateway (P-GW) as in the LTE network. [0033] Moreover, whenever UE' s active RTOP session is terminated by its serving eNB (due to any reason), the eNB transfers the state information of all the associated TCP/IP connections back to the UE so that these TCP/IP connections continue without interruption.

[0034] FIGS. 3 A-3B illustrate an example RTOP stack that conforms to the Institute of Electrical and Electronics Engineers (IEEE) 802.11 Ethernet standard, with the u-plane illustrated in FIG. 3 A and the c-plane illustrated in FIG. 3B.

[0035] As shown in FIG. 3 A, 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 is (1) a TCP/UDP layer followed by an IP layer, and (2) an RTOP-u layer, followed by a PDCP or IP layer, followed by an Ethernet layer. Below these layers is an IEEE 802.11 MAC layer, followed by an IEEE 802.11 PHY layer. The AP 330A has an RTOP-u layer. Below the RTOP-u layer are two sets of layers. The first set includes a PDCP or IP layer, followed by an Ethernet layer, followed by an IEEE 802.11 MAC layer, followed by an IEEE 802.11 PHY layer. The second set includes a TCP/UDP layer followed by an IP layer.

[0036] 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 a RTOP-c layer, followed by an IEEE 802.11 MAC layer, followed by an IEEE 802.11 PHY layer. The AP 330B has a RTOP-c layer, followed by an IEEE 802.11 MAC layer, followed by an IEEE 802.11 PHY layer.

[0037] FIGS. 3 A-3B show how to support the proposed RTOP in an IEEE 802.11/ Wi-Fi network. The RTOP u-plane traffic is transported by either 3 GPP PDCP or IP. If PDCP is used, the same PDCP enhancements to support RTOP can be used in 3GPP RAN and Wi-Fi. Alternatively, IP is used to carry RTOP directly by using the protocol type of 114 (specified for any 0-hop protocol). The RTOP c-plane traffic can be transported by IEEE 802.11 management frames.

[0038] FIG. 4 is a data flow diagram illustrating a user equipment- initiated RTOP communication method 400. As shown, the method 400 involves communication between Apps at the UE (Apps@UE) 405, RTOP at the UE (RTOP@UE) 410, RTOP at the e B (RTOP@e B) 415, and the 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 of the UE, or the eNB may be replaced with an AP or other network infrastructure device.

[0039] The method 400 begins at operation 425, where the Apps@UE

405 send, to the RTOP@UE 410, an RTOP open request (RTOP-open-REQ). The RTOP open request includes a source address, a source port, a destination IP, a destination port, and a protocol type. The RTOP@UE 410 forwards the RTOP open request, as well as the evolved packet system (EPS) bearer identifier (ID), to the RTOP@eNB 415.

[0040] The Apps@UE 405 sends a RTOP-Open-REQ message to

RTOP@UE 410 for requesting the eNB to open a TCP/IP connection or run a TCP/IP connection on UE's behalf, and RTOP@UE 410 then forwards the message to the eNB using for example RRC messages. The RTOP-Open-REQ message provides the five-tuple flow identification information (source IP address, source port, destination IP address, destination port, and protocol type) as well as the EPS Bearer ID (or Radio Bearer ID) information to identify the bearer which the flow belongs to. If the TCP (or UDP) connection is already opened by the UE, the RTOP-Open-REQ message also includes the context and state information of the connection, so that eNB can continue the TCP (or UDP) connection on the UE's behalf.

[0041] At operation 435, the RTOP@eNB 415 opens the TCP/IP connection on the UE's behalf. The eNB opens a TCP (or UDP) connection (if requested) based on the flow information provided by UE. Or, the eNB runs the TCP (or UDP) connection based on the context/ state information of the connection provided by the UE. The eNB sends the RTOP-Open-RSP message to indicate the status (success or failure) as well as a flow ID if the connection is successfully established or ran. Notice that the eNB generates the TCP/IP packets needed for the connection establishment using the flow identification information that the UE provides, and exchanges the TCP/IP packets of the flow with the core network (S-GW/P-GW 420) over the Sl-u interface. [0042] At operation 440, the Apps@UE 405 communicate with the

RTOP@UE 410 using app data transfer. The RTOP@UE 410 communicates with the RTOP@e B using app data transfer. The RTOP@e B communicates with the S-GW/P-GW using a Sl-u interface. Apps@UE 405 send uplink (UL) data directly to the RTOP@UE 410 bypassing the UE' s TCP/IP stack, and the RTOP@UE 410 forwards the UL data using PDCP to the RTOP@e B 415. The RTOP@e B 415 adds TCP/IP headers and sends the data with the TCP/IP headers out to the S-GW/P-GW 420 via the Sl-u interface. On the other hand, the eNB 415 receives downlink (DL) data via the Sl-u interface, and check its TCP/IP header to determine if the corresponding flow is a RTOP flow or not. If the corresponding flow is a RTOP flow, the eNB 415 removes the TCP/IP header, and then send data over PDCP to the RTOP@UE 410. The RTOP@UE 410 then forwards the received data to the Apps@UE 405, bypassing the UE's TCP/IP stack.

[0043] At operation 445, the Apps@UE 405 send an RTOP close request

(RTOP-close-REQ) to the RTOP@UE 410. The RTOP@UE 415 forwards the RTOP close request, together with the flow ID, to the RTOP@eNB 415. At operation 450, the RTOP@eNB 415 closes the TCP/IP connection on the UE's behalf. At operation 455, the RTOP@eNB 415 sends a RTOP close response (RTOP-close-RSP), including the flow ID, to the RTOP@UE 410. The

RTOP@UE 410 forwards the RTOP close response, including the flow ID, to the Apps@UE 405.

[0044] The Apps@UE 405 send out the RTOP-Close-REQ message to close the RTOP session. The RTOP-Close-REQ message includes the flow ID information, and also indicates whether to close the corresponding TCP (UDP) connection. In response, the eNB 415 closes the connection (if requested), and sends out the RTOP-Close-RSP message. Alternatively, the eNB closes the RTOP session itself (triggered by the remote end of the connection or other events, e.g., Handover, RRC -release), and then sends out the RTOP-Close-RSP message. If the TCP or UDP flow/ connection is still open, the eNB 415 includes the 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. [0045] After operation 455, the method 400 ends. It should be noted that the method 400 may be applied not only in a 3GPP RAN environment, but also in a non-3 GPP RAN environment, such as a Wi-Fi environment.

[0046] In some cases, PDCP is designed to support only IP traffic on the u-plane. With the new RTOP functionality, some aspects of the subject technology enhance PDCP to support non-IP traffic in the following two aspects: a PDCP packet format to deliver RTOP packet; and some PDCP functionalities, for example, header compression/ decompression, may be skipped for RTOP packets.

[0047] FIG. 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 one-bit flag to indicate whether the PDCP packet is an IP packet or a RTOP packet. The RTOP header 520 includes a one-byte (eight bit) field to indicate the flow ID. The RTOP payload 530 includes application (app) data.

[0048] Some aspects of the subject technology include adding a new bit flag in the PDCP header and indicate if the PDCP payload is IP packet or RTOP packet. Each RTOP packet has a RTOP header, in which a one-byte field is used to indicate the Flow ID of the flow to which the packet belongs.

[0049] FIG. 6 illustrates an example flow 600 from a transmitting PDCP entity 605 to a receiving PDCP entity 610 in an evolved universal mobile telecommunications system (UMTS) radio access network (E-UTRAN).

[0050] According to some schemes, the transmitting PDCP entity 605 applies sequence numbering 615 and header compression in the u-plane 620. Packets associated to a PDCP SDU receive integrity protection in the c-plane 625 and ciphering 630, and a PDCP header is added to the packets 635. Packets not associated to a PDCP service data unit (SDU) have a PDCP header added to them 635. At operation 640, the packets are transferred from the transmitting PDCP entity 605 to the receiving PDCP entity over the radio interface (Uu).

[0051] The receiving PDCP entity 610 removes the PDCP headers from the packets 645. For packets associated to a PDCP SDU, deciphering 650 and integrity verification in the c-plane 655 are applied. For packets not associated to a PDCP SDU the operations 650 and 655 are skipped. 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. According to some aspects of the subject technology, the header compression operation 620 and the header decompression operation 660 are skipped for RTOP packets (but not for IP packets).

[0052] In summary, FIG. 6 shows that the header compression/ decompression (operations 620 and 660) functionality in PDCP is skipped for the RTOP packets. Other PDCP functionalities remain the same for RTOP packet.

[0053] End-to-end (e2e) flow control is a TCP functionality. Therefore,

RTOP interacts with the TCP/IP stack and support flow control. Below, DL and UL are discussed separately, in conjunction with FIG. 7 and FIG. 8, respectively. Also, PDCP and radio link control (RLC) acknowledge mode (AM) are assumed to ensure in-order and reliable delivery.

[0054] FIG. 7 is a data flow diagram illustrating an example of evolved

NodeB based downlink RTOP flow control 700. The data flow diagram shows data flowing between the Apps@UE 405, the RTOP@UE 410, the RTOP@Enb 415, and the S-GW/P-GW 420.

[0055] At operation 705, the S-GW/P-GW 420 transmits TCP data in general packet radio service (GPRS) tunneling protocol user plane (GTP-u) to the RTOP@e B 415. The RTOP@e B 415 transmits application (app) data in PDCP/RTOP to the RTOP@UE 410. The RTOP@UE 410 transmits app data to the Apps@UE 405.

[0056] At operation 710, the RTOP@UE 410 transmits RLC/ automatic repeat request (ARQ) acknowledgement (ACK) to the RTOP@e B 415. The RTOP@e B 415 transmits TCP ACK in GTP-u to the S-GW/P-GW 420.

[0057] At operation 715, the S-GW/P-GW 420 transmits TCP data in

GTP-u to the RTOP@e B 415. The RTOP@e B 415 transmits app data in PDCP/ RTOP to the RTOP@UE 410. The RTOP@UE 410 forwards the app data to the Apps@UE 405.

[0058] At operation 720, the RTOP@UE 410 transmits RLC/ ARQ ACK to the RTOP@e B 415. The RTOP@e B 415 transmits TCP ACK in GTP-u to the S-GW/P-GW 420. [0059] As demonstrated by FIG. 7, DL flow control is done completely on the eNB side, and there is no impact to the UE. As shown in FIG. 7, the e B sends a "TCP ACK" packet out to the remote end of the TCP connection if the corresponding "TCP Data" packet has been delivered to UE successfully (based on the information from RLC/ARQ). It should be noted that that ARQ is supported in IEEE 802.1 1/Wi-Fi and, therefore, the proposed RTOP flow control mechanism is also applicable if RTOP is deployed in a Wi-Fi network.

[0060] FIG. 8 is a data flow diagram illustrating an example of user equipment based evolved NodeB assisted uplink RTOP flow control 800. The data flow diagram shows data flowing between the Apps@UE 405, the

RTOP@UE 410, the RTOP@Enb 415, and the S-GW/P-GW 420.

[0061] At operation 805, the Apps@UE 405 transmit app data to the

RTOP@UE 410. The RTOP@UE 410 transmits app data in PDCP/RTOP to the RTOP@e B 415. The RTOP@e B 415 transmits TCP data in GTP-u to the S- GW/P-GW. Similarly, at operation 810, the Apps@UE 405 transmit app data to the RTOP@UE 410. The RTOP@UE 410 transmits app data in PDCP/RTOP to the RTOP@e B 415. The RTOP@e B 415 transmits TCP data in GTP-u to the S-GW/P-GW. Similarly, at operation 815, the Apps@UE 405 transmit app data to the RTOP@UE 410. The RTOP@UE 410 transmits app data in PDCP/RTOP to the RTOP@e B 415. The RTOP@e B 415 transmits TCP data in GTP-u to the S-GW/P-GW.

[0062] At operation 820, the RTOP@e B 415 determines that there is congestion. Responsive to determining that there is congestion, at operation 825, the RTOP@e B 415 transmits an RTOP flow stop command (RTOP-Flow- Stop-Cmd), which includes the flow ID, to the RTOP@UE 410.

[0063] At operation 830, the RTOP@e B 415 determines that there is no congestion. Responsive to determining that there is no congestion, at operation 835, the RTOP@e B 415 transmits an RTOP flow start command (RTOP-Flow-Start-Cmd), which includes the flow ID, to the RTOP@UE 410.

[0064] At operation 840, similar to the operations 805-815, the

Apps@UE 405 transmit app data to the RTOP@UE 410. The RTOP@UE 410 transmits app data in PDCP/RTOP to the RTOP@e B 415. The RTOP@e B 415 transmits TCP data in GTP-u to the S-GW/P-GW. [0065] As illustrated in FIG. 8, the 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 operation, the RTOP@eNB 415 monitors how much data are waiting in the buffer for transmission to the remote end of the TCP connection to detect network congestion, and sends out the RTOP-Flow-Stop-Cmd message and the RTOP-Flow-Start-Cmd message accordingly. In a second set of operations, the RTOP@UE 410 stops receiving data from the Apps@UE 405 in response to a RTOP-Flow-Stop-Cmd message, and resumes receiving data from the Apps@UE 405 in response to a RTOP-Flow-Start-Cmd message.

[0066] When the RTOP@eNB 415 sends the RTOP close response

(RTOP-Close-RSP) response to close a RTOP session, the eNB discards all the remaining data in the buffer, and also indicates in the RTOP-Close-RSP message the amount of data that are discarded, as well as the state information of the TCP connection. As result, the UE can resume the TCP/IP connection from where the data transfer has stopped.

[0067] FIG. 9 is a data flow diagram illustrating an example handover procedure 900 involving RTOP, which may be implemented in a 3GPP cellular RAN environment. As shown, the 3 GPP cellular RAN environment includes a UE 902, a source eNB 904, a target eNB 906, a mobility management entity (MME) 908, and a serving gateway 910.

[0068] The handover (HO) procedure involves operations 912-958 described below, with enhancements of the handover procedure to support RTOP at operations 920-930.

[0069] At operation 912, the source eNB 904 transmits measurement control to the UE 902. At 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. At operation 916, UL allocation is transmitted from the source eNB 904 to the UE 902. At operation 918 measurement reports are transmitted from the UE 902 to the source eNB 904.

[0070] At operation 920, a HO decision is made at the source eNB 904.

Upon an affirmative HO decision, at operation 922, a handover request is transmitted from the source eNB 904 to the target eNB 906. At operation 924, the handover request is acknowledged, by the target eNB 906, to the source eNB 904. At operation 926, DL allocation is transmitted from the source eNB 904 to the UE 902. At operation 928, RRC connection reconfiguration is transmitted from the source eNB 904 to the UE 902. At operation 930, sequence number (SN) status is transferred from the source eNB 904 to the target eNB 906. The operations 920-930 include enhancements of the handover procedure to support RTOP.

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

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

[0073] To support RTOP, the source eNB 904 indicates during the handover request operation 922 that the UE 902 has active RTOP sessions. The source eNB 904 may also transfer the UE's RTOP context info (including the state information of the UE's RTOP-enabled TCP/UDP connections) to the target eNB 906.

[0074] If the target eNB 906 does not support RTOP for the UE, the target eNB 906 indicates this at the handover request acknowledgement operation 924, and the source eNB 904 then sends out the RTOP-Close-RSP message at the RRC connection reconfiguration operation 928 to terminate all RTOP sessions.

[0075] If the target eNB 906 supports RTOP, the source eNB 904 transfers the RTOP context info of the UE 902 (including the state information of the UE's RTOP-enabled TCP/IP sessions) at the SN status transfer operation 930 to the target eNB 906, so that these sessions may continue after handover.

[0076] FIG. 10 shows 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 to be developed. The network 1000 may comprise a radio access network (RAN) (e.g., as depicted, the E-UTRAN or evolved universal terrestrial radio access network) 1001 and core network 1020 (e.g., shown as an evolved packet core (EPC)) coupled together through an SI interface 1015. For convenience and brevity, only a portion of the core network 1020, as well as the RAN 1001, is shown in the example. The network 1000 includes the UE 1002, which may correspond to one or more of the UEs 11 OA, HOB, 21 OA, 210B, 31 OA, 310B, and 902.

[0077] The core network 1020 may include a mobility management entity (MME) 1022, serving gateway (serving GW) 1024, and packet data network gateway (PDN GW) 1026. The RAN 1001 may include evolved node Bs (eNBs) 1004 (which may operate as base stations) for communicating with user equipment (UE) 1002. The eNBs 1004 may include macro eNBs 1004a and low power (LP) eNBs 1004b. The eNBs 1004 may correspond to one or more of the eNBs 120A, 120B, 220A, 220B, 904, and 906. The MME 1022 may correspond to the MME 908. The serving gateway 1024 may correspond to the serving gateway 910. The serving gateway 1024 and the PDN GW 1026 may correspond to the S-GW/P-GW 420.

[0078] The MME 1022 may be similar in function to the control plane of legacy Serving GPRS Support Nodes (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 toward 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 point for inter-eNB handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement. The serving GW 1024 and the MME 1022 may be implemented in one physical node or separate physical nodes.

[0079] The PDN GW 1026 may terminate a SGi interface toward 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 with non-LTE access. The external PDN can be any kind of IP network, as well as an IP Multimedia Subsystem (IMS) domain. The PDN GW 1026 and the serving GW 1024 may be implemented in a single physical node or separate physical nodes.

[0080] The eNBs 1004 (macro and micro) may terminate the air interface protocol and may be the first point of contact for a UE 1002. In some

embodiments, an eNB 1004 may fulfill various logical functions for the RAN 1001 including, but not limited to, RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. In accordance with embodiments, UEs 1002 may be configured to communicate orthogonal frequency division multiplexed (OFDM) communication signals with an eNB 1004 over a multicarrier communication channel in accordance with an OFDMA communication technique. The OFDM signals may comprise a plurality of orthogonal subcarriers.

[0081] The SI interface 1015 may be the interface that separates the

RAN 1001 and the EPC 1020. It may be split into two parts: the Sl-U, which may carry traffic data between the eNBs 1004 and the serving GW 1024, and the SI -MME, which may be a signaling interface between the eNBs 1004 and the MME 1022. The X2 interface may be the interface between eNBs 1004. The X2 interface may comprise two parts, the X2-C and X2-U. The X2-C may be the control plane interface between the eNBs 1004, while the X2-U may be the user plane interface between the eNBs 1004. [0082] With cellular networks, LP cells 1004b may be typically used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with dense usage. In particular, it may be desirable to enhance the coverage of a wireless communication system using cells of different sizes, macrocells, microcells, picocells, and femtocells, to boost system performance. The cells of different sizes may operate on the same frequency band, or may operate on different frequency bands with each cell operating in a different frequency band or only cells of different sizes operating on different frequency bands. As used herein, the term LP eNB refers to any suitable relatively LP eNB for implementing a smaller cell (smaller than a macro cell) such as a femtocell, a picocell, or a microcell. Femtocell eNBs may be typically provided by a mobile network operator to its residential or enterprise customers. A femtocell may be typically the size of a residential gateway or smaller and generally connect to a broadband line. The femtocell may connect to the mobile operator's mobile network and provide extra coverage in a range of typically 30 to 50 meters. Thus, a LP eNB 1004b might be a femtocell eNB since it is coupled through the PDN GW 1026. Similarly, a picocell may be a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.), or more recently in-aircraft. A picocell eNB may generally connect through the X2 link to another eNB such as a macro eNB through its base station controller (BSC) functionality. Thus, LP eNB may be implemented with a picocell eNB since it may be coupled to a macro eNB 1004a via an X2 interface. Picocell eNBs or other LP eNBs LP eNB 1004b may incorporate some or all functionality of a macro eNB LP eNB 1004a. In some cases, this may be referred to as an access point base station or enterprise femtocell.

[0083] In some embodiments, the UE 1002 may communicate with an access point (AP) 1004c. The AP 1004c may use only the unlicensed spectrum (e.g., WiFi bands) to communicate with the UE 1002. The AP 1004c may communicate with the macro eNB 1004 A (or LP eNB 1004B) through an Xw interface. In some embodiments, the AP 1004c may communicate with the UE 1002 independent of communication between the UE 1002 and the macro eNB 1004 A. In other embodiments, the AP 1004c may be controlled by the macro e B 1004 A and use LWA, as described in more detail below.

[0084] Communication over an LTE network may be split up into 10ms frames, each of which may contain ten 1ms subframes. Each subframe of the frame, in turn, may contain two slots of 0.5ms. Each subframe may be used for uplink (UL) communications from the UE to the eNB or downlink (DL) communications 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 over a variety of frequency bands (fi and f₂). The allocation of resources in subframes used in one frequency band and may differ from those in another frequency band. Each slot of the subframe may contain 6-7 OFDM symbols, depending on the system used. In one embodiment, the subframe may contain 12 subcamers. A downlink resource grid may be used for downlink transmissions from an eNB to a UE, while an uplink resource grid may be used for uplink transmissions from a UE to an eNB or from a UE to another UE. The resource grid may be a time-frequency grid, which is the physical resource in the downlink in each slot. The smallest time-frequency unit in a 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) that describe the mapping of physical channels to resource elements and physical RBs (PRBs). A PRB may be the smallest unit of resources that can be allocated to a UE. A resource block may be 180 kHz wide in frequency and 1 slot long in time. In frequency, resource blocks may be either 12 x 15 kHz subcarriers or 24 x 7.5 kHz subcarriers wide. For most channels and signals, 12 subcarriers may be used per resource block, dependent on the system bandwidth. In Frequency Division Duplexed (FDD) mode, both the uplink and downlink frames may be 10ms and frequency (full-duplex) or time (half-duplex) separated. In Time Division Duplexed (TDD), the uplink and downlink subframes may be transmitted on the same frequency and are 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 comprise 12 (subcarriers) * 14 (symbols) =168 resource elements. [0085] Each OFDM symbol may contain a cyclic prefix (CP) which may be used to effectively eliminate Inter Symbol Interference (ISI), and a Fast Fourier Transform (FFT) period. The duration of the CP may be determined by the highest anticipated degree of delay spread. Although distortion from the preceding OFDM symbol may exist within the CP, with a CP of sufficient duration, preceding OFDM symbols do not enter the FFT period. Once the FFT period signal is received and digitized, the receiver may ignore the signal in the CP.

[0086] There may be several different physical downlink channels that are conveyed using such resource blocks, including the physical downlink control channel (PDCCH) and the physical downlink shared channel (PDSCH). Each subframe may be partitioned into the PDCCH and the PDSCH. The PDCCH may normally occupy the first two symbols of each subframe and carries, among other things, information about the transport format and resource allocations related to the PDSCH channel, as well as H-ARQ information related to the uplink shared channel. The PDSCH may carry user data and higher layer signaling to a UE and occupy the remainder of the subframe. Typically, downlink scheduling (assigning control and shared channel resource blocks to UEs within a cell) may be performed at the eNB based on channel quality information provided from the UEs to the eNB, and then the downlink resource assignment information may be sent to each UE on the PDCCH used for (assigned to) the UE. The PDCCH may contain downlink control information (DCI) in one of a number of formats that indicate to the UE how to find and decode data, transmitted on PDSCH in the same subframe, from the resource grid. The DCI format may provide details such as 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 be scrambled with a Radio Network Temporary Identifier (RNTI) that identifies the target UE for which the PDSCH is intended. Use of the UE- specific RNTI may limit decoding of the DCI format (and hence the

corresponding PDSCH) to only the intended UE.

[0087] Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. FIG. 11 illustrates components of a UE in accordance with some embodiments. At least some of the components shown may be used in an e B or MME, for example, such as the UE 1002 or eNB 1004 shown in FIG. 10. The UE 1100 and other components may be configured to use the synchronization signals as described herein. The UE 1100 may be a stationary, non-mobile device or may be a mobile device. In some embodiments, the 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 1110, 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 the eNB may contain some or all of the components shown in FIG. 11. Other of the network elements, such as the MME, may contain an interface, such as the SI interface, to communicate with the eNB over a wired connection regarding the UE.

[0088] The application or processing circuitry 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 processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.). The processors may be coupled with and/or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system.

[0089] The baseband circuitry 1104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1104 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 1106 and to generate baseband signals for a transmit signal path of the RF circuitry 1106. Baseband processing circuity 1 104 may interface with the application circuitry 1102 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1106. For example, in some embodiments, the baseband circuitry 1104 may include a second generation (2G) baseband processor 1104a, third generation (3G) baseband processor 1104b, fourth generation (4G) baseband processor 1104c, and/or other baseband processor(s) 1104d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 1104 (e.g., one or more of baseband processors 1104a-d) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1106. The radio control functions may include, but are not limited to, signal modulation/demodulation,

encoding/decoding, radio frequency shifting, etc. In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1104 may include FFT, precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the 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 functionality are not limited to these examples and may include other suitable functionality in other

embodiments.

[0090] In some embodiments, the baseband circuitry 1104 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (E-UTRAN) protocol including, for example, physical (PHY), media 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 the 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 processor(s) (DSP) 1104f. The audio DSP(s) 1104f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1104 and the application circuitry 1102 may be implemented together such as, for example, on a system on a chip (SOC). [0091] In some embodiments, the baseband circuitry 1104 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1104 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 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, the device can be configured to operate in accordance with communication standards or other protocols or standards, including Institute of Electrical and Electronic Engineers (IEEE) 802.16 wireless technology (WiMax), IEEE 802.11 wireless technology (WiFi) including IEEE 802.11 ad, which operates in the 60 GHz millimeter wave spectrum, various other wireless 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, etc. technologies either already developed or to be developed.

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

[0093] In some embodiments, the 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 1106c. The transmit signal path of the RF circuitry 1106 may include filter circuitry 1106c and mixer circuitry 1106a. RF circuitry 1106 may also include synthesizer circuitry 1106d for synthesizing a frequency 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 signals received from the FEM circuitry 1108 based on the synthesized frequency provided by synthesizer circuitry 1106d. The amplifier circuitry 1106b may be configured to amplify the down-converted signals and the filter circuitry 1106c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1104 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1106a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

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

[0095] 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 quadrature downconversion and/or upconversion 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 of the receive signal path and the mixer circuitry 1106a may be arranged for direct downconversion and/or direct upconversion, 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 super-heterodyne operation. [0096] In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 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 to communicate with the RF circuitry 1106.

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

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

[0099] The synthesizer circuitry 1106d may be configured to synthesize an output frequency for use by the mixer circuitry 1106a of the RF circuitry 1106 based on a frequency input and a divider control input. In some

embodiments, the synthesizer circuitry 1106d may be a fractional N/N+1 synthesizer.

[00100] In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1104 or the applications processor 1102 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the applications processor 1102.

[00101] Synthesizer circuitry 1106d of the RF circuitry 1106 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[00102] In some embodiments, synthesizer circuitry 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 quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fix)). In some embodiments, the RF circuitry 1106 may include an IQ/polar converter.

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

[00104] In some embodiments, the FEM circuitry 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) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1106). The transmit signal path of the FEM circuitry 1108 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1106), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1110.

[00105] In some embodiments, the UE 1100 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface as described in more detail below. 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 headset, 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, the 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 peripheral component interaction with the system. For example, the UE 1100 may include one or more of a keyboard, a keypad, a touchpad, a display, a sensor, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, one or more antennas, a graphics processor, an application processor, a speaker, a microphone, and other I/O components. The display may be an LCD or LED screen including a touch screen. The sensor may include a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit. The positioning unit may communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.

[00106] The antennas 1110 may comprise 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 multiple-input multiple-output (MTMO) embodiments, the antennas 1110 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

[00107] Although the UE 1100 is illustrated as having several separate 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, the functional elements may refer to one or more processes operating on one or more processing elements.

[00108] 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 readonly 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.

[00109] FIG. 12 is a block diagram of a communication device 1200 in accordance with some embodiments. The communication device 1200 may be a UE or eNB, for example, such as the UE 1002 or e B 1004 shown in FIG. 10. The physical layer circuitry 1202 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals. The communication device 1200 may also include medium access control layer (MAC) circuitry 1204 for controlling access to the wireless medium. The communication device 1200 may also include processing circuitry 1206, such as 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. The radio control functions may include signal modulation, encoding, decoding, radio frequency shifting, etc. For example, similar to the device shown in FIG. 2, in some embodiments, communication may be enabled with one or more of a WMAN, a WLAN, and a WPAN. In some embodiments, the communication device 1200 can be configured to operate in accordance with 3 GPP standards or other protocols or standards, including WiMax, WiFi, WiGig, GSM, EDGE, GERAN, UMTS, UTRAN, or other 3G, 3G, 4G, 5G, etc. technologies either already developed or to be developed. The communication device 1200 may include transceiver circuitry 1212 to enable communication with other external devices wirelessly and interfaces 1214 to enable wired communication with other external devices. As another example, the transceiver circuitry 1212 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.

[00110] The antennas 1201 may comprise 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 MFMO embodiments, the antennas 1201 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.

[00111] Although the communication device 1200 is illustrated as having several separate 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 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, the functional elements may refer to one or more processes operating 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. [00112] FIG. 13 illustrates another block diagram of a communication device 1300 in accordance with some embodiments. The communication device 1300 may correspond to the UE 1002 or the e B 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 capacity of a server communication device, a client communication device, or both in server-client network environments. In an example, the communication device 1300 may act as a peer communication device in peer-to-peer (P2P) (or other distributed) network environment. The communication device 1300 may be a UE, eNB, PC, a tablet PC, a STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any

communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device. Further, while only a single communication device is illustrated, the term "communication device" shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

[00113] Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms. Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner. In an example, circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module. In an example, the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations. In an example, the software may reside on a communication device readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations. [00114] Accordingly, the term "module" is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein. Considering examples in which modules are temporarily configured, each of the modules need not be instantiated at any one moment in time. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as respective different modules at different times. Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.

[00115] 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 an interlink (e.g., bus) 1308. The

communication device 1300 may further 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 an example, the display unit 1310, input device 1312 and UI navigation device 1314 may be a touch screen display. The communication device 1300 may additionally include a storage device (e.g., drive unit) 1316, a signal generation device 1318 (e.g., a speaker), a network interface device 1320, and one or more sensors 1321, such as 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 or control one or more peripheral devices (e.g., a printer, card reader, etc.).

[00116] The storage device 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 any 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, within static memory 1306, or within the hardware processor 1302 during execution thereof by the communication device 1300. In an example, one or any combination of the hardware processor 1302, the main memory 1304, the static memory 1306, or the storage device 1316 may constitute communication device readable media.

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

[00118] The term "communication device readable medium" may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 1300 and that cause the communication device 1300 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting communication device readable medium examples may include solid-state memories, and optical and magnetic media. Specific examples of communication device readable media may include: non-volatile memory, such as 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 internal hard disks and removable disks;

magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, communication device readable media may include non-transitory communication device readable media. In some examples, communication device readable media may include communication device readable media that is not a transitory propagating signal.

[00119] The instructions 1324 may further be transmitted or received over a communications network 1326 using a transmission medium via the network interface device 1320 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others. In an example, the network interface device 1320 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 1326. In an example, the network interface device 1320 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SFMO), MIMO, or multiple-input single-output (MISO) techniques. In some examples, the network interface device 1320 may wirelessly communicate using Multiple User MFMO 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 communications signals or other intangible medium to facilitate communication of such software.

[00120] The subject technology is described below in conjunction with various examples.

[00121] Example 1 is an apparatus of a user equipment (UE), the apparatus comprising: processing circuitry and memory, the processing circuitry to: encode 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, for requesting a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE; encode, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request causing the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information; access a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully; and encode, for transmission to the network infrastructure device using a wireless link layer protocol, uplink (UL) data, associated with the TCP or the UDP connection, from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack.

[00122] In Example 2, the subject matter of Example 1 optionally includes that the processing circuitry is further to access, using the RTOP layer, DL data received from the network infrastructure device; and decode the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

[00123] In Example 3, the subject matter of any of Examples 1-2 optionally includes that the processing circuitry is further to: access, after encoding the request for the network infrastructure device to open the TCP or the UDP connection, an indication that the network infrastructure device opened the TCP or the UDP connection.

[00124] In Example 4, the subject matter of any of Examples 1-2 optionally includes that the request for the network infrastructure device to open and run the TCP or the UDP connection comprises a radio resource control (RRC) message, an IEEE 802.11 management frame or a generic UDP/IP message.

[00125] In Example 5, the subject matter of any of Examples 1-2 optionally includes that the flow identification information comprises a five- tuple comprising: source IP address, source port, destination IP address, destination port, and protocol type, wherein the request further comprises an evolved packet system (EPS) bearer identifier or a radio bearer identifier if the network infrastructure device is based on Third Generation Partnership Program (3 GPP) cellular radio access technology (RAT), and wherein the request further comprise the TCP context and state information if the TCP connection is already opened. [00126] In Example 4, the subject matter of any of Examples 1-2 optionally includes that the processing circuitry is further to: encode an instruction for the network infrastructure device to close the TCP or the UDP connection, the instruction identifying the flow identification information; and receive, from the network infrastructure device, a confirmation that the TCP or the UDP connection is closed.

[00127] In Example 7, the subject matter of any of Examples 1-2 optionally includes that the processing circuitry is further to: encode an instruction for the network infrastructure device to stop RTOP operation for the flow, the instruction including the flow identification information; and access a confirmation, received from the network infrastructure device, that the RTOP operation has been stopped, the confirmation being for the UE to continue the flow itself, the confirmation including the TCP context and state information of the flow.

[00128] In Example 8, the subject matter of any of Examples 1-2 optionally includes that the processing circuitry is further to: access an indication, received from the network infrastructure device, that the RTOP operation has been stopped, and that the UE is to continue the flow itself, the indication including the TCP context and state information of the flow.

[00129] In Example 9, the subject matter of any of Examples 1-2 optionally includes that the wireless 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 specific packet is an RTOP packet rather than an IP packet.

[00130] In Example 10, the subject matter of any of Examples 1-2 optionally includes that the socket and connection manager comprises one or more applications or a process residing in the operating system for managing TCP/IP sockets and connections.

[00131] In Example 11, the subject matter of any of Examples 1-2 optionally includes the wireless link layer protocol is configured to operate in accordance with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 Ethernet or "0-Hop" Internet Protocol. [00132] In Example 12, the subject matter of any of Examples 1-2 optionally includes that an RTOP header comprises the flow identification information.

[00133] In Example 13, the subject matter of any of Examples 1-2 optionally includes that the processing circuitry comprises a baseband processor.

[00134] In Example 14, the subject matter of any of Examples 1-2 optionally includes transceiver circuitry to: transmit the request for the network infrastructure device to open and run the TCP or the UDP connection on the UE's behalf; and transmit the UL data to the network infrastructure device using PDCP; and an antenna coupled to the transceiver circuitry.

[00135] Example 15 is an apparatus of a network infrastructure device, the apparatus comprising: processing circuitry and memory; the processing circuitry to: access flow identification information received from a user equipment (UE); open a transmission control protocol (TCP) or a user datagram protocol (UDP) connection on the UE's behalf by generating TCP/ Internet Protocol (IP) packets for opening the connection using the accessed flow identification information; encode the generated TCP/IP packets for exchange with a core network over a Sl-u interface; access uplink (UL) data received from the UE using packet data convergence protocol (PDCP); add TCP/IP headers to the accessed UL data; and encode the accessed UL data with the added TCP/IP headers for transmission over the Sl-u interface.

[00136] In Example 16, the subject matter of Example 15 optionally includes that the processing circuitry is further to: access downlink (DL) data received over the Sl-u interface; determine, 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; remove, in response to determining that the corresponding flow is the RTOP flow, a TCP/IP header from the accessed DL data; and encode the accessed DL data without the TCP/IP header for transmission using PDCP to an RTOP layer at the UE.

[00137] In Example 17, the subject matter of Example 15 optionally includes that the processing circuitry is further to: determine that receipt of the accessed DL data is acknowledged at the UE; encode, upon determining that the receipt of the accessed DL data is acknowledged at the UE, a TCP

acknowledgement (ACK) packet for transmission to the core network.

[00138] In Example 18, the subject matter of Example 15 optionally includes that the processing circuitry is further to: encode a notification to the UE that the TCP or the UDP connection has been opened.

[00139] In Example 19, the subject matter of Example 15 optionally includes that the processing circuitry is further to: access a message from the UE to close the TCP or the UDP connection, the message identifying the flow identification information; close, in response to the message, the TCP or the UDP connection; and notify the UE that the TCP or the UDP connection has been closed.

[00140] In Example 20, the subject matter of Example 15 optionally includes that the processing circuitry is further to: close the TCP or the UDP connection in response to a trigger by a remote end of the TCP or the UDP connection; and notify the UE that the TCP or the UDP connection has been closed.

[00141] 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 a specific packet is an RTOP packet or an IP packet.

[00142] In Example 22, the subject matter of Example 21 optionally includes that the processing circuitry is further to: apply header

compression/decompression functionality for the specific packet if the bit flag in the PDCP header indicates that the specific packet is the IP packet; and forego applying header compression/decompression functionality for the specific packet if the bit flag in the PDCP header indicates that the specific packet is the RTOP packet.

[00143] In Example 23, the subject matter of Example 15 optionally includes that the processing circuitry is further to: monitor an amount of UL data received form the UE and waiting in a buffer for transmission over the Sl-u interface using TCP; upon detection that the amount of UL data exceeds a first threshold, notify the UE to stop receiving data from a higher layer and to stop transmitting UL data; upon detection that the amount of UL data is below a second threshold, notify the UE to re-start receiving data from the higher layer and to re-start transmitting the UL data.

[00144] In Example 24, the subject matter of Example 15 optionally includes that the processing circuitry is further to: encode an indication, to a target eNB, that the UE has an active RTOP session; determine whether the target eNB supports RTOP; encode a transfer, to the target eNB, of RTOP context information for the UE for continuation of the RTOP session at the target eNB upon determining that the target eNB supports RTOP; and encode a termination of the RTOP session with the UE upon determining that the target eNB does not support RTOP.

[00145] In Example 25, the subject matter of Example 15 optionally includes that the processing circuitry is further to: upon a termination of the RTOP session, encode a message, to the UE, that the RTOP session is terminated, the message including the flow identification information of the RTOP session and the TCP context and state information of the flow for the UE to continue the flow itself.

[00146] Example 26 is a machine-readable medium storing instructions which, when executed by processing circuitry of a user equipment (UE), cause the processing circuitry to: encode 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, for requesting a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE; encode, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request causing the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information; access a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully; and encode, for transmission to the network infrastructure device using a wireless link layer protocol, uplink (UL) data, associated with the TCP or the UDP connection, from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack.

[00147] In Example 27, the subject matter of Example 26 optionally includes that the machine-readable medium further stores instruction which, when executed by the processing circuitry, cause the processing circuitry to: access, using the RTOP layer, DL data received from the network infrastructure device; and decode the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack.

[00148] 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, for requesting a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE; means for encoding, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request causing the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information; means for accessing a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully; means for encoding, for transmission to the network infrastructure device using a wireless link layer protocol, uplink (UL) data, associated with the TCP or the UDP connection, from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack.

[00149] In Example 29, the subject matter of Example 28 optionally includes means for accessing, using the RTOP layer, DL data received from the network infrastructure device; and means for decoding the accessed RTOP data for access by the socket and connection manager while bypassing the TCP/IP stack. [00150] Although an embodiment has been described with reference to specific example embodiments, it will be evident that various modifications and changes may be made to these embodiments. Accordingly, the specification and drawings are 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 therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. This Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

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

[00152] In this document, the terms "a" or "an" are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of "at least one" or "one or more." In this document, the term "or" is used to refer to a nonexclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise indicated. In this document, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Also, in the following claims, the terms "including" and "comprising" are open-ended, that is, a system, UE, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms "first," "second," and "third," etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.

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

Claims

CLAIMS What is claimed is:

1. An apparatus of a user equipment (UE), the apparatus comprising:

processing circuitry and memory; the processing circuitry to:

encode 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 to request a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE;

encode, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request to cause the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information;

decode a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully; and encode, for transmission to the network infrastructure device using a wireless link layer protocol, uplink (UL) data, associated with the TCP or the UDP connection, from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack.

2. The apparatus of claim 1, wherein the processing circuitry is further to: access, using the RTOP layer, DL data received from the network infrastructure device; and

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

3. The apparatus of any of claims 1-2, wherein the processing circuitry is further to:

access, after encoding the request for the network infrastructure device to open the TCP or the UDP connection, an indication that the network

infrastructure device opened the TCP or the UDP connection.

4. The apparatus of any of claims 1-2, wherein the request for the network infrastructure device to open and run the TCP or the UDP connection comprises a radio resource control (RRC) message, an IEEE 802.11 management frame or a generic UDP/IP message.

5. The apparatus of any of claims 1-2, wherein the flow identification information comprises a five-tuple comprising: source IP address, source port, destination IP address, destination port, and protocol type, wherein the request further comprises an evolved packet system (EPS) bearer identifier or a radio bearer identifier if the network infrastructure device is based on Third

Generation Partnership Program (3 GPP) cellular radio access technology (RAT), and wherein the request further comprise the TCP context and state information if the TCP connection is already opened.

6. The apparatus of any of claims 1-2, wherein the processing circuitry is further to:

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

receive, from the network infrastructure device, a confirmation that the TCP or the UDP connection is closed.

7. The apparatus of any of claims 1-2, wherein the processing circuitry is further to:

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

decode a confirmation, received from the network infrastructure device, that the RTOP operation has been stopped, the confirmation being for the UE to continue the flow itself, the confirmation including the TCP context and state information of the flow.

8. The apparatus of any of claims 1-2, wherein the processing circuitry is further to:

decode an indication, received from the network infrastructure device, that the RTOP operation has been stopped, and that the UE is to continue the flow itself, the indication including the TCP context and state information of the flow.

9. The apparatus of any of claims 1-2, wherein the wireless 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 specific packet is an RTOP packet rather than an IP packet.

10. The apparatus of any of claims 1-2, wherein the socket and connection manager comprises one or more applications or a process residing in the operating system for managing TCP/IP sockets and connections.

11. The apparatus of any of claims 1-2, wherein the wireless link layer protocol is configured to operate in accordance with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 Ethernet or "0-Hop" Internet Protocol.

12. The apparatus of any of claims 1-2, wherein an RTOP header comprises the flow identification information.

13. The apparatus of any of claims 1-2, wherein the processing circuitry comprises a baseband processor.

14. The apparatus of any of claims 1-2, further comprising:

transceiver circuitry to:

transmit the request for the network infrastructure device to open and run the TCP or the UDP connection on the UE's behalf; and

transmit the UL data to the network infrastructure device using

PDCP; and

an antenna coupled to the transceiver circuitry.

15. An apparatus of a network infrastructure device, the apparatus comprising:

processing circuitry and memory;

the processing circuitry to:

decode flow identification information received from a user equipment (UE);

open a transmission control protocol (TCP) or a user datagram protocol (UDP) connection on the UE's behalf by generating TCP/ Internet Protocol (IP) packets for opening the connection using the accessed flow identification information;

encode the generated TCP/IP packets for exchange with a core network over a Sl-u interface;

decode uplink (UL) data received from the UE using packet data convergence protocol (PDCP);

add TCP/IP headers to the accessed UL data; and encode the accessed UL data with the added TCP/IP headers for transmission over the Sl-u interface.

16. The apparatus of claim 15, wherein the processing circuitry is further to: decode downlink (DL) data received over the Sl-u interface;

determine, 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;

remove, in response to determining that the corresponding flow is the RTOP flow, a TCP/IP header from the accessed DL data; and

encode the accessed DL data without the TCP/IP header for transmission using PDCP to an RTOP layer at the UE.

17. The apparatus of claim 16, wherein the processing circuitry is further to: determine that receipt of the accessed DL data is acknowledged at the

UE;

encode, upon determining that the receipt of the accessed DL data is acknowledged at the UE, a TCP acknowledgement (ACK) packet for transmission to the core network.

18. The apparatus of claim 15, wherein the processing circuitry is further to: encode a notification to the UE that the TCP or the UDP connection has been opened.

19. The apparatus of claim 15, wherein the processing circuitry is further to: decode a message from the UE to close the TCP or the UDP connection, the message identifying the flow identification information;

close, in response to the message, the TCP or the UDP connection; and notify the UE that the TCP or the UDP connection has been closed.

20. The apparatus of claim 15, wherein the processing circuitry is further to: close the TCP or the UDP connection in response to a trigger by a remote end of the TCP or the UDP connection; and

notify the UE that the TCP or the UDP connection has been closed.

21. The apparatus of claim 15, wherein the data accessed using PDCP comprises a bit flag in a PDCP header indicating whether a specific packet is an RTOP packet or an IP packet.

22. The apparatus of claim 21, wherein the processing circuitry is further to: apply header compression/decompression functionality for the specific packet if the bit flag in the PDCP header indicates that the specific packet is the IP packet; and

forego applying header compression/decompression functionality for the specific packet if the bit flag in the PDCP header indicates that the specific packet is the RTOP packet.

23. The apparatus of claim 15, wherein the processing circuitry is further to: monitor an amount of UL data received form the UE and waiting in a buffer for transmission over the S 1 -u interface using TCP;

upon detection that the amount of UL data exceeds a first threshold, notify the UE to stop receiving data from a higher layer and to stop transmitting UL data;

upon detection that the amount of UL data is below a second threshold, notify the UE to re-start receiving data from the higher layer and to re-start transmitting the UL data.

24. The apparatus of claim 15, wherein the processing circuitry is further to: encode an indication, to a target eNB, that the UE has an active RTOP session;

determine whether the target eNB supports RTOP;

encode a transfer, to the target eNB, of RTOP context information for the UE for continuation of the RTOP session at the target eNB upon determining that the target eNB supports RTOP; and

encode a termination of the RTOP session with the UE upon determining that the target eNB does not support RTOP.

25. The apparatus of claim 15, wherein the processing circuitry is further to: upon a termination of the RTOP session, encode a message, to the UE, that the RTOP session is terminated, the message including the flow

identification information of the RTOP session and the TCP context and state information of the flow for the UE to continue the flow itself.

26. A machine-readable medium storing instructions which, when executed by processing circuitry of a user equipment (UE), cause the processing circuitry to:

encode 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 to request a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE;

encode, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request to cause the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information;

decode a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully; and

encode, for transmission to the network infrastructure device using a wireless link layer protocol, uplink (UL) data, associated with the TCP or the UDP connection, from the socket and connection manager using the RTOP layer while bypassing a TCP/IP stack.

27. The machine-readable medium of claim 26, further storing instructions which, when executed by the processing circuitry, cause the processing circuitry to:

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

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

28. 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 to request a network infrastructure device to open and run a TCP or a user datagram protocol (UDP) connection on the UE's behalf or to run TCP/Internet Protocol (IP) processing for an existing TCP or UDP connection which has previously been opened by the UE;

means for encoding, using the RTOP layer, a request for the network infrastructure device to open or to run the TCP or the UDP connection on the UE's behalf, the request comprising flow identification information and TCP context information, the request to cause the network infrastructure device to open or to run the TCP or the UDP connection based on the flow identification information and the TCP context information;

means for accessing a confirmation, received from the network infrastructure device, that the TCP or the UDP connection is opened or ran successfully;

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

29. The apparatus of claim 28, further comprising:

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

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