Radio link control accumulation mode for new radio

Abstract

A user equipment (UE) configured to receive a first cumulative acknowledgement (ACK) from a protocol stack of the UE at a first time, store the first cumulative ACK in a queue, receive a second cumulative ACK from the protocol stack at a second time, wherein the second time occurs after the first time, store the second cumulative ACK in the queue, discard the first cumulative ACK from the queue based on the second cumulative ACK received after the first cumulative ACK, and encapsulate the second cumulative ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air.

Description

TECHNICAL FIELD

[0001] The present application relates generally to wireless communications, and more specifically to radio link control accumulation mode for new radio. BACKGROUND

[0002] Cumulative acknowledgement (ACK) generally refers to a type of automatic repeat request (ARQ) feedback in which a recently generated ACK indicates receipt of all data up to a sequence number indicated by the ACK. Various types of applications, such as but not limited to transmission control protocol (TCP) applications, can be configured with cumulative ACK. It has been recognized that fifth generation (5G) new radio (NR) can benefit from implementing a radio control link (RLC) mode of operation configured for cumulative ACK feedback. SUMMARY

[0003] Some example embodiments relate to a processor of a user equipment (UE) configured to perform operations. The operations include receiving a first cumulative acknowledgement (ACK) from a protocol stack of the UE at a first time, storing the first cumulative ACK in a queue, receiving a second cumulative ACK from the protocol stack at a second time, wherein the second time occurs after the first time, storing the second cumulative ACK in the queue, discarding the first cumulative ACK from the queue based on the second cumulative ACK being received after the first cumulative ACK, and encapsulating the second cumulative ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air.

[0004] Other example embodiments relate to a user equipment (UE) having a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform operations. The operations include receiving a first cumulative acknowledgement (ACK) from a protocol stack of the UE at a first time, storing the first cumulative ACK in a queue, receiving a second cumulative ACK from the protocol stack at a second time, wherein the second time occurs after the first time, storing the second cumulative ACK in the queue, discarding the first cumulative ACK from the queue based on the second cumulative ACK being received after the first cumulative ACK, and encapsulating the second cumulative ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air.

[0005] Still further example embodiments are directed to a processor of a user equipment (UE) configured to perform operations. The operations include identifying, at a TCP layer of the UE, a first transmission control protocol (TCP) acknowledgement (ACK); storing the first TCP ACK in a buffer, wherein a timer is started in response to the storing; identifying, at a second time, a second TCP ACK from the TCP layer, wherein the second time occurs after a first time and before an expiration of the timer; discarding, based on a time of identifying the second TCP ACK, the first TCP ACK from the buffer; and encapsulating the second TCP ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air.

[0006] Still further example embodiments are directed to a user equipment (UE) having a transceiver configured to communicate with a network and a processor communicatively coupled to the transceiver and configured to perform operations. The operations include identifying, at a TCP layer of the UE, a first transmission control protocol (TCP) acknowledgement (ACK); storing the first TCP ACK in a buffer, wherein a timer is started in response to the storing; identifying, at a second time, a second TCP ACK from the TCP layer, wherein the second time occurs after a first time and before an expiration of the timer; discarding, based on a time of identifying the second TCP ACK, the first TCP ACK from the buffer; and encapsulating the second TCP ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air. BRIEF DESCRIPTION OF DRAWINGS

[0007] Figure 1 An example network arrangement is shown in accordance with various example embodiments.

[0008] Figure 2 An example user equipment (UE) is shown in accordance with various example embodiments.

[0009] Figure 3 An example base station is shown in accordance with various example embodiments.

[0010] Figure 4 Examples of radio link control (RLC) cumulative mode (CM) operation are shown in accordance with various example embodiments.

[0011] Figure 5 Examples of RLC CM operation with a single transmission control protocol (TCP) flow and modem flushing are shown in accordance with various example embodiments.

[0012] Figure 6Examples of RLC CM operation with multiple TCP flows and modem flush are shown in accordance with various example embodiments.

[0013] Figure 7 Examples of RLC CM operation with a single TCP flow and TCP flush are shown in accordance with various example embodiments.

[0014] Figure 8 Examples of RLC CM operation with multiple TCP flows and TCP flush are shown in accordance with various example embodiments. DETAILED DESCRIPTION

[0015] The example embodiments can be further understood with reference to the following description and related drawings, wherein like elements are referred to with like reference numerals. The example embodiments introduce a Radio Link Control (RLC) Cumulative Mode (CM) for Fifth Generation (5G) New Radio (NR). As will be described in greater detail below, the RLC CM is configured for cumulative acknowledgement (ACK) feedback. The term "cumulative ACK" generally refers to a type of automatic repeat request (ARQ) feedback in which a most recently generated ACK indicates successful receipt of all data up to the sequence number indicated by the ACK. When utilizing cumulative ACK feedback, it can not be necessary for each ACK to be successfully transmitted for the corresponding communication protocol to function adequately. The RLC CM utilizes this aspect of cumulative ACK feedback to provide performance benefits at both the RLC transmitting and RLC receiving nodes.

[0016] Those skilled in the art will appreciate that RLC refers to a layer 2 radio link protocol that can be used for over-the-air communications. For example, a user equipment (UE) can generate ARQ feedback (e.g., ACK, NACK, etc.) and then encapsulate the ARQ feedback as a RLC packet data unit (PDU) for over-the-air transmission. However, any reference to a UE generating ARQ feedback is provided for illustrative purposes only. The example embodiments can be utilized by any appropriate type of device that is configured to transmit ARQ feedback encapsulated as a RLC PDU over-the-air to another node.

[0017] The 3GPP RLC protocol can be used by various different types of applications to transmit information and / or data over-the-air. For example, as described above, ACKs generated in accordance with a first communication protocol can be transmitted over-the-air using a second different communication protocol (e.g., RLC). In some cases, the first communication protocol can not need to receive each ACK for the communication protocol to function because the first communication protocol can utilize cumulative ACK feedback. However, conventional 5G NR 3GPP data path protocols such as RLC Acknowledged Mode (AM), RLC Unacknowledged Mode (UM), RLC Transparent Mode (TM) do not utilize this type of feedback.

[0018] The Transmission Control Protocol is one example of a communication protocol that can be configured with cumulative ACK feedback. Those skilled in the art will appreciate that TCP applications typically use RLC AM. Before describing exemplary techniques for RLC CM in detail, the following provides a discussion of why it can be beneficial to use RLC CM for TCP ACKs instead of RLC AM. However, exemplary embodiments are not limited to TCP ACKs. Other applications, such as but not limited to Real-Time Transport Control Protocol (RTCP), Ultra-Reliable Low-Latency (URLLC), and Vehicle-to-Everything (V2X) aspects can utilize cumulative ACK feedback. Exemplary embodiments can apply to any type of application and / or communication protocol that is configured with cumulative ACK feedback, which can be encapsulated as an RLC PDU. Cumulative ACK feedback can be encapsulated, for example, on a per-flow identity (id), per-TCP flow, and / or the like.

[0019] TCP refers to one of the transport layer communication protocols encompassed by the Internet Protocol Suite. As noted above, in regular cases, TCP applications typically use RLC AM, which is designed to transmit each upper layer service data unit (SDU). Thus, in RLC AM, a UE can be configured to transmit each TCP ACK.

[0020] Enhanced Mobile Broadband (eMBB) applications can require high throughput, and thus can generate a relatively large number of TCP ACKs. For example, TCP ACKs generated in response to a 20 Giga bits per second (Gbps) eMBB flow can use up to 100 Mega bits per second (Mbps) of bandwidth. When utilizing RLC AM, each TCP ACK can be encapsulated into various 3GPP headers (e.g., Packet Data Convergence Protocol (PDCP), RLC, and / or the like) and transmitted over the air. If a TCP ACK is lost and / or there is a channel error, the 3GPP lower layers can ensure that the TCP ACK is retransmitted, and can even consume more bandwidth. Processing ACKs at this scale can place strain on power and / or processing resources. Thus, transmitting TCP ACKs using RLC AM can negatively impact air resources, UE processing resources, and / or network processing resources.

[0021] While exemplary embodiments can provide benefits to TCP communications, as noted above, exemplary embodiments are not limited to TCP ACKs. Exemplary embodiments can apply to any cumulative ACK feedback that can be encapsulated as an RLC PDU and transmitted over the air.

[0022] Exemplary embodiments introduce an RLC CM that includes various exemplary techniques for generating cumulative ACK feedback and transmitting the cumulative ACK feedback via the RLC layer. To provide an example of one exemplary technique, the RLC CM can utilize a last-in, first-out (LIFO) approach in which the most recently generated ACKs are transmitted over the air with respect to a set of ACKs, while other ACKs can be discarded. Each of the exemplary techniques described herein can be used with other currently implemented RLC protocols, future implementations of RLC protocols, or independently of other RLC protocols. Additionally, reference to the term RLC CM is provided for illustrative purposes only. Different entities can refer to similar concepts by different names.

[0023] Figure 1 An exemplary network arrangement 100 is shown in accordance with various exemplary embodiments. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will appreciate that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet, desktop computer, smart phone, phablet, embedded device, wearable device, Internet of Things (IoT) device, etc. It will also be appreciated that a practical network arrangement can include any number of UEs used by any number of users. Thus, only an example with a single UE 110 is provided for illustrative purposes.

[0024] The UE 110 can be configured to communicate with one or more networks. In the example of the network arrangement 100, the network with which the UE 110 can wirelessly communicate is a 5G NR radio access network (RAN) 120. However, the UE 110 can also communicate with other types of networks (e.g., a 5G cloud RAN, a next generation RAN (NG-RAN), a long term evolution (LTE) RAN, a traditional cellular network, a WLAN, etc.), and the UE 110 can also communicate with networks through a wired connection. With respect to exemplary embodiments, the UE 110 can establish a connection with the 5G NR RAN 120. Thus, the UE 110 can have a 5G NR chipset to communicate with the 5G NR RAN 120.

[0025] The 5G NR RAN 120 can be part of a cellular network that can be deployed by a network operator (e.g., Verizon, AT&T, T-Mobile, etc.). The 5G NR RAN 120 may, for example, include nodes, cells, or base stations (e.g., node Bs, eNode Bs, HeNBs, eNBS, gNBs, gNode Bs, macrocell base stations, microcell base stations, small cell base stations, femtocell base stations, etc.) that are configured to transmit and receive communication traffic from UEs equipped with appropriate cellular chipsets.

[0026] Those skilled in the art will appreciate that any relevant procedures can be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a particular cellular provider at which UE 110 and / or its user has agreement and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 can transmit corresponding credential information in order to associate with 5G NR-RAN 120. More specifically, UE 110 can associate with a particular base station (e.g., a next generation NodeB (gNB) 120A, for example).

[0027] Network arrangement 100 also includes a cellular core network 130, the Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. Cellular core network 130 can be viewed as an interconnected set of components that manage the operation and traffic of a cellular network. It can include an Evolved Packet Core (EPC) and / or a 5G Core (5GC). Cellular core network 130 also manages traffic that flows between the cellular network and the Internet 140. IMS 150 can generally be described as an architecture for delivering multimedia services to UE 110 using IP protocols. IMS 150 can communicate with cellular core network 130 and the Internet 140 to provide multimedia services to UE 110. Network services backbone 160 communicates with the Internet 140 and cellular core network 130, either directly or indirectly. Network services backbone 160 can generally be described as a set of components (e.g., servers, network storage arrangements, etc.) that implement a suite of services that can be used to extend the functionality of UE 110 in communicating with various networks.

[0028] Figure 2 An exemplary UE 110 according to various exemplary embodiments is shown. UE 110 will be described with reference to network arrangement 100 of Figure 1 UE 110 can include a processor 205, a memory arrangement 210, a display device 215, an input / output (I / O) device 220, a transceiver 225, and other components 230. Other components 230 can include, for example, an audio input device, an audio output device, a power source, a data acquisition device, a port for electrically connecting UE 110 to other electronic devices, etc.

[0029] Processor 205 can be configured to execute a number of engines of UE 110. For example, the engines can include a TCP engine 235 and an RLC CM engine 240. TCP engine 235 can perform various operations related to TCP-based communications, such as, but not limited to, generating TCP ACKs. RLC CM engine 240 can be configured to perform various operations related to RLC CM, such as, but not limited to, establishing bearers, encapsulating RLC PDUs, and managing queues / buffers.

[0030] The engines 235, 240 referenced above are provided for illustrative purposes only as applications (e.g., programs) executed by the processor 205. The functionality associated with the engines 235, 240 can also be represented as separate combined components of the UE 110, or can be modular components coupled to the UE 110, e.g., integrated circuits with or without firmware. For example, the integrated circuits can include input circuitry for receiving signals and processing circuitry for processing signals and other information. The engines can also be embodied as one application or as separate multiple applications. Moreover, in some UEs, the functionality described with respect to the processor 205 is split between two or more processors, such as a baseband processor and an application processor. The example embodiments can be implemented in any of these or other configurations of the UE.

[0031] The memory arrangement 210 can be a hardware component configured to store data related to operations performed by the UE 110. The display device 215 can be a hardware component configured to display data to a user, while the I / O device 220 can be a hardware component that enables a user to make inputs. The display device 215 and the I / O device 220 can be separate components or can be integrated together, such as a touchscreen. The transceiver 225 can be a hardware component configured to establish a connection with the 5G NR-RAN 120, a LTE-RAN (not shown), a legacy RAN (not shown), a WLAN (not shown), etc. Thus, the transceiver 225 can operate on multiple different frequencies or channels (e.g., a set of contiguous frequencies).

[0032] Figure 3 An example base station 300 is shown in accordance with various example embodiments. The base station 300 can represent a gNB 120A or any other type of access node with which the UE 110 can establish a connection and manage network operations.

[0033] The base station 300 can include a processor 305, a memory arrangement 310, an input / output (I / O) device 315, a transceiver 320, and other components 325. These other components 325 can include, for example, an audio input device, an audio output device, a battery, a data acquisition device, a port for electrically connecting the base station 300 to other electronic devices, etc.

[0034] The processor 305 can be configured to execute a number of engines of the base station 105. For example, the engines can include an RLC-CM engine 330. The RLC CM engine 330 can perform various operations related to the RLC CM, such as, but not limited to, establishing a bearer, identifying ACKs encapsulated as RLC PDUs, discarding RLC PDUs, and providing ACKs further downstream (e.g., the Internet 140, etc.).

[0035] The engine 330 described above is exemplary only as an application (e.g., program) executed by the processor 305. The functionality associated with the engine 330 can also be represented as a separate integrated component of the base station 300, or can be a modular component coupled to the base station 300, e.g., an integrated circuit with or without firmware. For example, the integrated circuit can include input circuitry for receiving signals and processing circuitry for processing signals and other information. Further, in some base stations, the functionality described with respect to the processor 305 is split among multiple processors (e.g., a baseband processor, an application processor, etc.). The exemplary embodiments can be implemented in any of these or other configurations of the base station.

[0036] The memory arrangement 310 can be a hardware component configured to store data related to operations performed by the base station 300. The I / O device 315 can be a hardware component or port that enables a user to interact with the base station 105. The transceiver 320 can be a hardware component configured to exchange data with the UE 110 and any other UEs in the network arrangement 100. The transceiver 320 can operate on various different frequencies or channels (e.g., a set of contiguous frequencies). Thus, the transceiver 320 can include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0037] Various exemplary techniques for RLC CM are described with respect to signaling exchanges in which the gNB 120A transmits multiple packets to the UE 110. In response, ARQ feedback is generated by the UE 110 (e.g., TCP engine 235) including one or more cumulative ACKs. One of the ACKs can then be encapsulated as an RLC PDU and transmitted over the air to the gNB 120A. However, any reference to cumulative ACK feedback generated by the UE 110 is provided for illustrative purposes only. RLC CM can be used for downlink communications and / or uplink communications.

[0038] Additionally, various examples are described with respect to TCP. However, the exemplary embodiments are not limited to TCP or TCP ACKs, and can apply to any appropriate type of cumulative ACK feedback. The following description provides an overview of TCP communications in the context of the network arrangement 100. Following this general overview, specific examples of various exemplary techniques are provided. Figure 1

[0039] ​Initially, consider a scenario in which a TCP client runs on UE 110 and connects to a remote server hosted on the Internet 140. The connection between the client and the remote server can be facilitated through a 5G NR network (e.g., gNB 120A, 5g NR-RAN 120, core network 130, etc.). The TCP client can be configured to use RLC CM, and thus, a bearer can be established between UE 110 and gNB 120A that is configured to transmit TCP ACKs encapsulated as RLC PDUs from UE 110 to gNB 120A.

[0040] The gNB 120A can receive a TCP packet from the remote server hosted on the Internet 140 that is intended for UE 110. The TCP packet can then be encapsulated by at least the RLC header to generate one or more RLC PDUs that are transmitted over the air to UE 110. How the TCP packet travels from the remote server to gNB 120A and the manner in which they are processed for over-the-air transmission is outside the scope of the example embodiments. Rather, the example embodiments are concerned with generating and transmitting ACKs.

[0041] At UE 110, the RLC PDUs are processed and the TCP data encapsulated by the RLC PDUs is provided to the TCP client. In this example, assume that the TCP data encapsulated by the RLC PDUs is successfully received. In response, UE 110 can generate a set of TCP ACKs. In some embodiments, only one TCP ACK from the set of TCP ACKs can be provided to the RLC layer, while the other TCP ACKs are discarded before the RLC layer. In other embodiments, the set of TCP ACKs can be provided to the RLC layer. However, only the most recently generated TCP ACK from the set of TCP ACKs can be encapsulated as a RLC PDU, and the other TCP ACKs from the set of TCP ACKs can be discarded at the RLC layer.

[0042] Figure 4 An example 400 of RLC CM operation is shown in accordance with various example embodiments. Example 400 is described with respect to a single TCP flow. Below, examples 500 and 600 are described with respect to multiple TCP flows. Figures 6-8 Specific examples are provided with respect to RLC CM and multiple TCP flows.

[0043] Example 400 illustrates an RLC CM bearer 405 configured as a dedicated radio bearer for transmitting the cumulative ACKs encapsulated as RLC PDUs from the UE 110 to the gNB 120A (or any other appropriate RLC node). The RLC CM bearer 405 can be configured by the network at the RAN layer using one or more radio resource control (RRC) messages. The RLC CM bearer also provides a mechanism for handling this dedicated radio bearer / logical channel and the medium access control (MAC) layer separately.

[0044] The TCP engine 235 generates four cumulative ACKs 401-404, which are then placed in a queue 410. The RLC CM can utilize a LIFO approach, where the most recently generated cumulative ACK is transmitted, and the other cumulative ACKs are discarded. To provide an example, the UE 110 (e.g., RLC CM engine 240) can execute a timer. When the timer expires, the UE 110 can be triggered to transmit the most recently generated ACK (e.g., ACK 404) stored in the queue 410 on the RLC CM bearer 405 and discard the other cumulative ACKs (e.g., ACKs 401-403) stored in the queue 410. The operation of this timer is illustrated in example 400 by the dashed timer start 420 and timer end 425. This example serves as an overview of how the RLC CM can be configured to manage the TCP ACKs generated by the TCP engine 235. Specific examples of using modem flushing to manage the TCP ACKs are provided below with respect to Figure 5 and Figure 6 Specific examples of using TCP flushing to manage the TCP ACKs are provided below with respect to Figure 7 and Figure 8 Specific examples of using TCP flushing to manage the TCP ACKs are provided below with respect to

[0045] In some embodiments, the cumulative ACKs generated by the TCP engine 235 can be tagged with metadata. The metadata can identify a particular flow ID, indicate that the cumulative ACK is not to be discarded, or include any other appropriate type of information.

[0046] As described above, in example 400, ACK 404 is selected for transmission on the RLC CM bearer 405. Prior to over-the-air transmission, ACK 404 can be configured with one or more headers 415, such as a service data adaptation protocol (SDAP) header, a packet data convergence protocol (PDCP) header, an RLC header, and the like. Once encapsulated as an RLC PDU, ACK 404 and the one or more headers 415 are transmitted over the RLC CM bearer 405.

[0047] In some embodiments, UE 110 can switch between RLC CM and RLC AM. For example, UE 110 can determine whether to utilize RLC CM or RLC AM based on the reliability of TCP ACK delivery. For example, if there are multiple HARQ failures or new TCP ACKs are not available within a timeout window, UE 110 can request to switch RLC CM to RLC AM until TCP ACK delivery is reliable enough.

[0048] At gNB 120A, ACK 404 and header 415 are received as RLC PDUs over RLC CM bearer 405. gNB 120A can process header 415, identify the cumulative ACK 404 and send it up to the protocol stack. In some embodiments, lossless delivery of cumulative ACKs is enabled and no ARQ is performed on older ACKs.

[0049] In some embodiments, a timer can be implemented at gNB 120A. This timer can be referred to as a“wait_timer” and is used to handle incoming TCP ACKs. For example, upon receiving a new TCP ACK before the wait_timer expires, older TCP ACKs in the queue can be discarded and the newly arrived TCP ACK can be sent up to the protocol stack. If no new TCP ACK arrives before the timer expires, an indication can be provided to UE 110 as a RLC PDU status report. In response, UE 110 can ensure that the TCP ACK carrying the most cumulative information is reliably delivered to gNB 120A. As described above, UE 110 can switch from RLC CM to RLC AM when the reliability of TCP ACK delivery is needed.

[0050] Figure 5 An example 500 of RLC CM operation with a single TCP flow and modem flush is shown in accordance with various example embodiments. Example 500 is described from the perspective of UE 110 configured with RLC CM bearer 505.

[0051] In example 500, TCP engine 235 generates cumulative ACKs 501-504. ACKs 501-504 are pushed into an active queue management (AQM) queue 510 located between the application processor (not a picture) and modem 525 (e.g., baseband processor).

[0052] The modem 525 can operate the timer 530 in association with the queue 510. When the timer 530 expires, the modem 525 discards the TCP ACKs in the queue 510 except for the TCP ACK that the TCP engine 235 recently pushed to the queue 510. In this example, the modem 525 discards the ACKs 501-503 and retains the ACK 504 based on the time at which each of the ACKs 501-504 is received at the queue 510. The modem 525 then frames the packets by adding one or more headers 515 (e.g., SDAP, PDCP, RLC, etc.) and sends the encapsulated RLC PDUs out over the RLC CM bearer 505.

[0053] Figure 6 An example 600 of RLC CM operation with multiple TCP flows and modem flushing is shown in accordance with various example embodiments. The example 600 is described from the perspective of the UE 110 configured with a RLC CM bearer 605.

[0054] In the example 600, the TCP engine 235 is configured with three different TCP flows 610-630. For modem flushing, ACKs can be tagged with metadata from the TCP stack indicating the flow ID. The flow ID allows the lower layers to distinguish ACKs from different TCP flows. In this example, the TCP engine 235 generates ACKs 611-614 for the TCP flow 610 and tags each of the ACKs 611-614 with a first flow ID 615. The TCP engine 235 generates ACKs 621-624 for the TCP flow 620 and tags each of the ACKs 621-624 with a second, different flow ID 625. The TCP engine 235 generates ACKs 631-634 for the TCP flow 630 and tags each of the ACKs 631-634 with a third, different flow ID 635.

[0055] The ACKs 611-614, 621-624, 631-634 are pushed into an AQM queue 660 located between an application processor (not shown) and a modem 645 (e.g., a baseband processor). The modem 645 operates a timer 650 associated with the queue 660. When the timer 650 expires, the modem 645 discards the TCP ACKs in the queue 660 except for the most recent TCP ACK for each TCP flow 610-630. Thus, in this example, the TCP ACKs 614, 624, and 634 are retained while the other ACKs are flushed by the modem 645. Subsequently, the modem 645 can encapsulate each of the TCP ACKs 614, 624, and 634 with one or more headers 655 (e.g., SDAP, PDCP, RLC, etc.) and transmit the encapsulated RLC PDUs over the RLC CM bearer 605.

[0056] Figure 7 An example 700 of RLC CM operation with a single TCP flow and TCP flushing is shown in accordance with various example embodiments. The example 700 is described from the perspective of a UE 110 configured with a RLC CM bearer 705.

[0057] In the example 700, the UE 110 can be configured to identify a TCP ACK at a TCP layer 702 of the UE 110. When a TCP ACK is identified, it is placed in a buffer 710 and a timer 715 is started. The duration of the timer 715 can be based on a downlink data rate. If the buffer 710 receives a new TCP ACK before the timer expires, the new TCP ACK replaces the previously received TCP ACK. Since the buffer is configured for a single TCP ACK, the example 700 shows a single TCP ACK 711.

[0058] When the timer 715 expires, the TCP ACK in the buffer 710 is encapsulated with one or more headers 712 (e.g., SDAP, PDCP, RLC, etc.) and the UE 110 transmits the encapsulated RLC PDU over the RLC CM bearer 705. At the gNB 120A, upon reception and successful de-framing, the TCP stack can use the cumulative ACK and / or TCP Selective Acknowledgment (SACK) information attached to the TCP ACK 711 to determine whether the TCP sequence numbers up to the sequence number of the TCP ACK 711 have been acknowledged by the UE 110.

[0059] In some cases, there can be multiple TCP flows, each generating its own ACK. In this example, the buffer 710 can store one TCP ACK per flow. If a new TCP ACK is received before the timer 715 expires, the new TCP ACK replaces the TCP ACK stored in the buffer associated with the same TCP flow. When the timer 715 expires, the cumulative ACK for each TCP flow can be encapsulated with the one or more headers 712 and transmitted over the RLC CM bearer 705.

[0060] Figure 8 An example 800 of RLC CM operation with multiple TCP flows and TCP flushing is shown in accordance with various example embodiments. The example 800 is described from the perspective of a UE 110 configured with RLC CM bearers 805. As will be shown below, the example 800 differs from the multiple flow example described above with respect to example 700 in that each TCP flow is configured with its own TCP buffer.

[0061] In the example 800, the TCP layer 802 is configured with three different TCP flows 810-830. Each TCP flow 810-830 is configured with a buffer 812, 822, 832. When a TCP ACK is identified at the TCP layer 802, the TCP ACK is placed in the buffer associated with its corresponding TCP flow and a timer is started. If the buffer receives a new TCP ACK before the timer expires, the new TCP ACK replaces the previously received TCP ACK. Since each buffer is configured for a single TCP ACK, the example 800 shows a single TCP ACK 811 in the buffer 812, a single TCP ACK 821 in the buffer 822, and a single TCP ACK 831 in the buffer 832. When the timer expires, the cumulative ACK is encapsulated with the one or more headers 813 and transmitted over the RLC CM bearer 805.

[0062] To eliminate the need for header processing at the device receiving the TCP ACK, the contents of the TCP ACK can be copied onto another header. In one option, a MAC control element (CE) can be configured to carry intermittent TCP overhead information, such as, but not limited to, a scheduling request (SR) / buffer status report (BSR) timer configured for high throughput cases. In a second option, the contents of the TCP ACK can be copied onto a RLC header. In this approach, the RLC header size can be extended to accommodate this feature. In a third option, a RLC and PDCP stats PDU IE can be used to inform the UE 110 whether the highest TCP sequence number was received using the metadata provided in the TCP ACK. This can ensure that packet de-framing is not needed at the time of reception.

[0063] In some embodiments, if downlink gain for uplink data transmission is also needed, the network can define this RLC CM as a new 5G Quality of Service (QoS) Identifier (5QI). The 5QI can have a throughput generated from TCP ACKs, where the packet drop rate is defined as a LIFO approach including RLC CM and a delay bound matching RLC and / or PDCP delays.

[0064] Those skilled in the art will understand that the exemplary embodiments described above can be implemented in any suitable software configuration or hardware configuration, or a combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments can include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, mobile devices with operating systems such as iOS, Android, and the like. Exemplary embodiments of the above-described methods can be embodied as a program including code lines stored on a non-transitory computer-readable storage medium, which, when compiled, can be executed on a processor or microprocessor.

[0065] While this patent application describes various combinations of various embodiments each having different features, those skilled in the art will appreciate that any feature of one embodiment can be combined with features of other embodiments or features that are not inconsistent with the operation or functioning of the devices of the disclosed embodiments or that do not alter the functioning of the described features in any manner that is inconsistent with the operation or functioning of the devices of the disclosed embodiments, in any manner not expressly disclosed.

[0066] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled in a way to minimize risk of unintentional or unauthorized access or use of the data, and every effort should be made to secure user's consent to the manner in which their personal information is collected and used.

[0067] It will be apparent to those skilled in the art that various modifications can be made to the disclosed embodiments without departing from the spirit or scope of the disclosure. Thus, it is intended that the disclosure cover the modifications and variations of this disclosure provided they come within the scope of the appended claims and their equivalents.

Claims

1. A processor of a user equipment (UE), the processor configured to perform operations comprising: receiving a first cumulative acknowledgement (ACK) from a protocol stack of the UE at a first time, wherein the first cumulative ACK corresponds to a single transmission control protocol (TCP) flow; storing the first cumulative ACK in a queue; receiving a second cumulative ACK from the protocol stack at a second time, wherein the second time occurs after the first time, wherein the second cumulative ACK corresponds to the single TCP flow; storing the second cumulative ACK in the queue; discarding the first cumulative ACK from the queue based on the second cumulative ACK being received after the first cumulative ACK; and encapsulating the second cumulative ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air, wherein the operations further comprise starting a timer, wherein the timer starts when the first cumulative ACK is stored and an end of the timer is based on a downlink data rate, wherein only one cumulative ACK per flow ID is encapsulated for a timer duration.

2. The processor of claim 1, the operations further comprising: receiving a set of cumulative ACKs corresponding to a second different TCP flow, each cumulative ACK corresponding to the second different TCP flow marked with a same flow ID.

3. The processor of claim 1, wherein the protocol stack is a transmission control protocol (TCP) protocol stack and the processor is a modem.

4. The processor of claim 1, wherein an expiration of the timer is configured to trigger the discarding.

5. The processor of claim 1, wherein contents of the second cumulative ACK are duplicated on a RLC header.

6. A user equipment (UE), the UE comprising: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations comprising: receiving a first cumulative acknowledgement (ACK) from a protocol stack of the UE at a first time, wherein the first cumulative ACK corresponds to a single transmission control protocol (TCP) flow; storing the first cumulative ACK in a queue; receiving a second cumulative ACK from the protocol stack at a second time, wherein the second time occurs after the first time, wherein the second cumulative ACK corresponds to the single TCP flow; storing the second cumulative ACK in the queue; discarding the first cumulative ACK from the queue based on the second cumulative ACK being received after the first cumulative ACK; and encapsulating the second cumulative ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air, wherein the operations further comprise starting a timer, wherein the timer starts when the first cumulative ACK is stored and an end of the timer is based on a downlink data rate, wherein only one cumulative ACK per flow ID is encapsulated for a timer duration.

7. The UE of claim 6, the operations further comprising: ​ ​ receiving a set of cumulative ACKs corresponding to a second different TCP flow, each cumulative ACK corresponding to the second different TCP flow marked with the same flow ID.

8. The UE of claim 6, wherein the protocol stack is a transmission control protocol (TCP) protocol stack and the processor is a modem.

9. The UE of claim 6, wherein an expiration of the timer is configured to trigger the discarding.

10. The UE of claim 6, wherein contents of the second cumulative ACK are copied on a RLC header.

11. A processor of a user equipment (UE), the processor configured to perform operations comprising: identifying, at a transmission control protocol (TCP) layer of the UE, a first TCP acknowledgment (ACK), wherein the first TCP ACK corresponds to a single TCP flow; storing the first TCP ACK in a buffer, wherein a timer is started in response to the storing and an end of the timer is based on a downlink data rate; identifying, at a second time, a second TCP ACK from the TCP layer, wherein the second time occurs after a first time and before an expiration of the timer, wherein the second TCP ACK corresponds to the single TCP flow; discarding, from the buffer, the first TCP ACK based on a time of identifying the second TCP ACK; and encapsulating the second TCP ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air, wherein only one cumulative ACK per flow ID is encapsulated within a timer duration.

12. The processor of claim 11, wherein a duration of the timer is based on a downlink data rate.

13. The processor of claim 11, the operations further comprising: identifying a third TCP ACK corresponding to a second different TCP flow, wherein each TCP flow is configured with a different buffer at the UE.

14. The processor of claim 11, the operations further comprising: identifying a third TCP ACK corresponding to a second different TCP flow, wherein each TCP flow is configured with a same buffer at the UE.

15. The processor of claim 11, wherein only one cumulative ACK per TCP flow is encapsulated within a timer duration.

16. The processor of claim 11, wherein the expiration of the timer is configured to trigger the encapsulating.

17. A user equipment (UE), the UE comprising: a transceiver configured to communicate with a network; and a processor communicatively coupled to the transceiver and configured to perform operations comprising: identifying, at a transmission control protocol (TCP) layer of the UE, a first TCP acknowledgment (ACK), wherein the first TCP ACK corresponds to a single TCP flow; storing the first TCP ACK in a buffer, wherein a timer is started in response to the storing and an end of the timer is based on a downlink data rate; identifying a second TCP ACK from the TCP layer at a second time, wherein the second time occurs after the first time and before an expiration of the timer, wherein the second TCP ACK corresponds to the single TCP flow; discarding the first TCP ACK from the buffer based on a time of identifying the second TCP ACK; and encapsulating the second TCP ACK to form a radio link control (RLC) packet data unit (PDU) to be transmitted over the air, wherein only one cumulative ACK per flow ID is encapsulated within a timer duration.

18. The UE of claim 17, wherein a duration of the timer is based on a downlink data rate.

19. The UE of claim 17, the operations further comprising: identifying a third TCP ACK corresponding to a second different TCP flow, wherein each TCP flow is configured with a different buffer at the UE.

20. The UE of claim 17, the operations further comprising: identifying a third TCP ACK corresponding to a second different TCP flow, wherein each TCP flow is configured with a same buffer at the UE.

21. The UE of claim 17, wherein only one cumulative ACK per TCP flow is encapsulated within a timer duration.

22. The UE of claim 17, wherein the expiration of the timer is configured to trigger the encapsulating.

Images