Fast recovery from handover with out-of-order delivery

Abstract

A method for fast handover recovery of a receiving data link layer protocol entity, such as a receiving packet data convergence protocol (PDCP) entity, is provided. A method performed by a receiving data link layer protocol entity includes the step of delivering a plurality of data packets to a receiving high layer transport protocol entity. Moreover, the method comprises the step of re-delivering a selected number of last delivered data packets of the plurality of data packets to the receiving higher layer transport protocol entity a number of times during a handover process.

Description

Technical Field

[0001] The present invention relates to the field of fast recovery from handovers. In particular, the present invention relates to a receiving data link layer protocol entity and method thereof, which deliver data packets to a receiving higher-layer transport protocol entity for fast recovery from handovers. More specifically, the present invention relates to Packet Data Convergence Protocol (PDCP) delivery for fast handover recovery. Background Art

[0002] In cellular technologies such as 3rd Generation Partnership Project (3GPP) New Radio (NR), during a handover, a wireless device's radio connection to the network moves from a source cell to a target cell. The source cell can be served by a source network node, such as a source gNB, and the target cell can be served by a target network node, such as a target gNB. The wireless device can be a terminal, user equipment (UE), or similar.

[0003] Without loss of generality, the protocol operations during handover are described for the above 3GPP 5G deployment. During handover, the wireless device protocol instance and network protocol instance of each protocol layer may go through the following process:

[0004] -The radio access network (RAN) protocol layers of the wireless device, thus the physical layer (PHY), medium access control (MAC) layer and radio link control (RLC) layer may be reset.

[0005] - The Packet Data Convergence Protocol (PDCP) layer is a sublayer of the RAN protocol layer or protocol stack. It can be a sublayer of the 2nd / MAC layer according to the Open Systems Interconnection (OSI) model.

[0006] The PDCP layer of the wireless device of the mobility anchor protocol may undergo a re-establishment process that includes the following:

[0007] ■ In Unacknowledged Mode (UM), the PDCP sequence number and reordering timers may be reset. Data not yet received in flight may be lost. After the connection is established in the target cell, the unsent data may be sent. Buffer forwarding may be used in the downlink (DL) to transfer unsent data from a source network node, such as a source gNB, to a target network node, such as a target gNB. After a handover, the receiving PDCP entity for the RAN layer of the receiving node (e.g., a wireless device for DL) may perform out-of-sequence delivery of any data that may have been received prior to the handover to the receiving higher-layer transport protocol entity of the receiving node, without waiting for lost packets in PDCP sequence number order.

[0008] ■ In Acknowledged Mode (AM), the PDCP sequence numbers and reordering timers may continue, i.e., they may be maintained. After the connection is established in the target cell, in-flight data that has not yet been received and unsent data may be retransmitted. Buffer forwarding may be used for sent but unacknowledged data and unsent data from the source network node to the target network node. After handover, the receiving PDCP entity may not perform out-of-order delivery to the receiving higher-layer transport protocol entity, i.e., the receiving PDCP entity may wait until lost packets are retransmitted. In other words, the receiving PDCP entity may wait until the gap in sequence numbering is filled or at least until the reordering timer expires.

[0009] During normal PDCP operation, i.e., PDCP operation other than handover operation, the PDCP reordering timer may be used to define the maximum waiting time for outstanding packets numbered by PDCP. In this way, packets received from lower layers out of sequence, for example due to being transmitted using different HARQ processes with different transmission / retransmission delays, are reordered at PDCP and provided to higher layers in sequence.

[0010] PDCP out-of-order delivery can optionally be configured for continuous operation (especially not for handover) to achieve lower latency, more interactivity and less head-of-line blocking for services.Modern transport protocols are expected to cope well with out-of-order delivery.

[0011] Transport protocols, such as the Transmission Control Protocol (TCP), Quick UDP Internet Connections (QUIC), etc., and their congestion control algorithms must identify congestion on the transport connection so that they can adjust the number of packets in transit and avoid further congestion. This is done by observing packet reordering, that is, observing the number and time of data packets received after a lost data packet. A sending transport protocol entity of a sending node executing the transport protocol obtains this information based on an acknowledgment (ACK) received from a receiving transport protocol entity of a receiving node. For DL, the sending node can be a network node, and therefore, the sending transport protocol entity can perform the functions of a network node. The receiving node can be a wireless device, and therefore, the receiving transport protocol entity can perform the functions of a wireless device. For uplink (UL), the sending node can be a wireless device, and therefore, the sending transport protocol entity can perform the functions of a wireless device. The receiving node can be a network node, and therefore, the receiving transport protocol entity can perform the functions of a network node.

[0012] One challenge is distinguishing between congestion events related to reordering on a connection and non-congestion events. The challenge for radio protocol design is balancing achievable throughput and latency. Higher throughput is possible if available bandwidth is fully utilized, which requires the transport protocol congestion control algorithm to maintain sufficient data in transit. This requires that the reordering introduced in NR not be mistakenly interpreted as transport congestion.

[0013] This is why PDCP reordering is usually used with the disadvantage of introducing latency.Another design option is to reduce latency and thus not perform PDCP reordering, albeit at the expense of a possible reduction in the rate of the transport protocol.

[0014] When PDCP UM out-of-order delivery is configured to optimize latency during normal operation (i.e., during operations outside of a handover procedure), the transport protocol may not react optimally to handover-related losses. One reason for this is that out-of-order delivery is intended for continuous operation, and no specific out-of-order delivery is performed after a handover, i.e., the receiving PDCP entity does not have any packets in its receive queue that can be delivered to a receiving higher-layer transport protocol entity, such as a receiving transport protocol entity, at / after a handover.

[0015] In the absence of out-of-order delivery after switching to the receiving higher-level transport protocol entity, no transmission confirmation is triggered between the receiving higher-level transport protocol entity and the sending higher-level transport protocol entity (e.g., the receiving transport protocol entity and the sending transport protocol entity). The confirmation clock transport protocol, such as TCP or QUIC, stops inputting new packets into the network. The sending transport protocol entity may only attempt to retransmit the packet after the (possibly long-running) recovery timer expires. Such a possibly long-running recovery timer may generate large and unnecessary delays. In addition, the sending transport protocol entity is typically also required to set its congestion window to a very small value. As a result, subsequent transmissions (after switching) may not keep up with the speed.

[0016] This is especially the case when no further new data packets are available for transmission after the handoff. This can happen due to the bursty nature of the traffic (no further bursts shortly after the handoff) when TCP / QUIC congestion control is still in the slow start phase of the transmission, or when buffered forwarding between the source and target network nodes is not complete.

[0017] Another related scenario is that the RAN protocol itself may not handle retransmissions associated with handovers, but instead leave the retransmission of data packets lost during the handover process to transport protocols such as TCP or QUIC. Due to the acknowledgement timing and timer-based nature of these protocols, delays in the retransmission of these packets are expected. Summary of the Invention

[0018] It is an object of the present invention to provide techniques and methods for optimizing the reaction to handover related losses, in particular for achieving fast and sufficient handover recovery with respect to handover related losses.

[0019] According to some embodiments, these goals can be achieved by adjusting the protocol behavior on the data packet receiving side. The techniques and methods presented herein can combine desirable effects, such as lower latency achieved with, for example, PDCP data packet delivery, with no or minimal negative impact on throughput / latency when handover procedures occur.

[0020] According to one aspect, a method performed by a receiving data link layer protocol entity includes the steps of delivering a plurality of data packets to a receiving higher-layer transport protocol entity. Furthermore, the method includes the steps of: redelivering a selected number of last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover process.

[0021] According to another aspect, a receiving node includes a processor into which a receiving data link layer protocol entity is loadable. Execution of the receiving data link layer protocol entity by the processor causes the receiving node to deliver a plurality of data packets to a receiving higher-level transport protocol entity. Furthermore, during a handover process, the receiving node is caused to redeliver a selected number of last delivered data packets from the plurality of data packets to the receiving higher-level transport protocol entity a certain number of times.

[0022] According to another aspect, a receiving node includes a receiving data link layer protocol entity. The receiving node is configured to deliver a plurality of data packets to a receiving higher-layer transport protocol entity and to redeliver a selected number of last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover process.

[0023] According to another aspect, a computer program includes program code executed by a processor to operate a receiving data link layer protocol entity. Execution of the program code causes the receiving data link layer protocol entity to perform operations including delivering a plurality of data packets to a receiving higher-level transport protocol entity. Furthermore, the operations include redelivering a selected number of last delivered data packets from the plurality of data packets to the receiving higher-level transport protocol entity a certain number of times during a handover process.

[0024] According to another aspect, a computer program product includes a non-transitory storage medium containing program code to be executed by processing circuitry to operate a receiving data link layer protocol entity. Execution of the program code causes the receiving data link layer protocol entity to perform operations including delivering a plurality of data packets to a receiving higher-level transport protocol entity. Furthermore, the operations include redelivering a selected number of last delivered data packets from the plurality of data packets to the receiving higher-level transport protocol entity a certain number of times during a handover process.

[0025] According to another aspect, a method implemented by a host operating in a communication system further comprising a network node and a user equipment (UE) includes providing user data to the UE. Furthermore, the method includes initiating a transmission carrying the user data to the UE via a cellular network including the network node. The UE performs operations to receive the user data from the host. The operations include: delivering a plurality of data packets to a receiving higher-layer transport protocol entity; and redelivering a selected number of last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover procedure.

[0026] According to another aspect, a host configured to operate in a communication system to provide an over-the-top (OTT) service includes processing circuitry configured to provide user data. Furthermore, the host includes a network interface configured to initiate transmission of the user data to a cellular network for transmission to a user equipment (UE). The UE includes a communication interface and processing circuitry. The communication interface and processing circuitry of the UE are configured to perform operations to receive user data from the host. The operations include delivering a plurality of data packets to a receiving higher-layer transport protocol entity, and redelivering a selected number of last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover process.

[0027] According to another aspect, a method implemented by a host configured to operate in a communication system further comprising a network node and a UE includes initiating, at the host, reception of user data from the UE. The user data originates from a transmission received by the network node from the UE. The network node performs operations to receive the user data intended for the host from the UE. The operations include delivering a plurality of data packets to a receiving higher-layer transport protocol entity, and redelivering a selected number of last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover procedure.

[0028] According to another aspect, a host configured to operate in a communication system to provide an over-the-top (OTT) service includes processing circuitry configured to initiate reception of user data. Furthermore, the host includes a network interface configured to receive the user data from a network node in a cellular network. The network node has a communication interface and processing circuitry. The processing circuitry of the network node is configured to perform operations to receive user data intended for the host from a UE. The operations include delivering a plurality of data packets to a receiving higher-layer transport protocol entity, and redelivering a selected number of the last delivered data packets of the plurality of data packets to the receiving higher-layer transport protocol entity a certain number of times during a handover process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 An example of a communication system according to some embodiments is shown.

[0030] Figure 2 is a block diagram of a host computer according to various aspects described herein, which may be Figure 1 An embodiment of a host.

[0031] Figure 3 A communication diagram illustrating a host communicating with a UE via a network node over a partially wireless connection according to some embodiments.

[0032] Figure 4A Data transmission for downlink (DL) between a network node and a wireless device according to an embodiment is shown.

[0033] Figure 4B Data transmission for uplink (UL) between a network node and a wireless device according to an embodiment is shown.

[0034] Figure 5 A receiving data link layer protocol entity and a receiving higher layer transport protocol entity of a receiving node according to an embodiment are shown.

[0035] Figure 6 A sending data link layer protocol entity and a sending higher layer transport protocol entity of a sending node according to an embodiment are shown.

[0036] Figure 7 A system overview of a high-layer transport protocol entity and a data link layer protocol entity with a sending node and a receiving node according to an embodiment is shown.

[0037] Figure 8 An exemplary system overview is shown in which a transport protocol entity serves as a higher-layer transport protocol entity and a PDCP entity serves as a data link layer protocol entity of a transmitting node and a receiving node.

[0038] Figure 9An exemplary method performed by a receiving data link layer protocol entity for triggering further data packet transmission is shown.

[0039] Figure 10 An example for triggering further data transmission is shown.

[0040] Figure 11 An exemplary method performed by a system including a transmitting node and a receiving node for triggering fast handover recovery is shown.

[0041] Figure 12 An exemplary configuration of a receiving node is shown.

[0042] Figure 13 An exemplary configuration of a sending node is shown.

[0043] Figure 14 Examples are shown of corresponding hardware that can use software to implement the functions described herein.

[0044] Figure 15 Simulation results using the method described herein for fast handover recovery according to an embodiment are shown.

[0045] Figure 16 Another simulation result using the method for fast handover recovery described herein according to an embodiment is shown. DETAILED DESCRIPTION

[0046] Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as being limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0047] Generally, all terms used in this article will be interpreted according to their ordinary meaning in the relevant technical field, unless any meaning is clearly given and / or implied from the context of its use. All references to one / an / this element, equipment, component, device, step, etc. should be openly interpreted as referring to at least one instance of an element, equipment, component, device, step, etc., unless otherwise clearly stated. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless a step is clearly described as being after or before another step and / or due to some dependency, a step must necessarily be after or before another step. Any feature of any embodiment disclosed herein can be applied to any other embodiment where appropriate. Similarly, any advantage of any embodiment can be applied to any other embodiment, and vice versa. Other purposes, features and advantages of the attached embodiments will be highlighted from the following description.

[0048] Figure 1 An example of a communication system 100 is shown in accordance with some embodiments.

[0049] In the example, the communication system 100 includes a telecommunications network 102 and a core network 106. The telecommunications network 102 includes an access network 104, such as a radio access network (RAN), and the core network 106 includes one or more core network nodes 108. The access network 104 includes one or more access network nodes, such as network nodes 110a and 110b (one or more of which may be collectively referred to as network nodes 110), or any other similar 3rd Generation Partnership Protocol (3GPP) access nodes or non-3GPP access points. The network nodes 110 facilitate direct or indirect connection of user equipment (UE), for example, by connecting UEs 112a, 112b, 112c, and 112d (one or more of which may be collectively referred to as UEs 112) to the core network 106 over one or more wireless connections.

[0050] Example wireless communications over wireless connections include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Additionally, in various embodiments, the communication system 100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that may facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection. The communication system 100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0051] The UE 112 may be any of a variety of communication devices, including wireless devices that are arranged, configured, and / or operable to wirelessly communicate with the network node 110 and other communication devices. Similarly, the network node 110 is arranged, capable, configured, and / or operable to communicate directly or indirectly with the UE 112 and / or with other network nodes or devices in the telecommunications network 102 to enable and / or provide network access, such as wireless network access, and / or perform other functions, such as management, in the telecommunications network 102.

[0052] In the depicted example, core network 106 connects network node 110 to one or more hosts, such as host 116. These connections can be direct or indirect via one or more intermediate networks or devices. In other examples, the network node can be directly coupled to the host. Core network 106 includes one or more core network nodes (e.g., core network node 108) comprised of hardware and software components. The features of these components can be substantially similar to those described with respect to the UE, network node, and / or host, such that the descriptions are generally applicable to the corresponding components of core network node 108. An exemplary core network node includes functionality of one or more of the following: a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identity dehiding function (SIDF), a unified data management (UDM), a security edge protection proxy (SEPP), a network exposure function (NEF), and / or a user plane function (UPF).

[0053] The host 116 may be under the ownership or control of a service provider other than the operator or provider of the access network 104 and / or the telecommunications network 102, and may be operated by or on behalf of the service provider. The host 116 may host a variety of applications to provide one or more services. Examples of such applications include real-time and pre-recorded audio / video content, data collection services such as retrieving and compiling data about various environmental conditions detected by multiple UEs, analytical functions, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and monitoring center, or any other such functions performed by a server.

[0054] As a whole, Figure 1 The communication system 100 enables connectivity between UEs, network nodes, and hosts. In this sense, the communication system can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other suitable wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards such as LoRa and Sigfox.

[0055] In some examples, telecommunication network 102 is a cellular network that implements 3GPP standardized features. Thus, telecommunication network 102 can support network slicing to provide different logical networks to different devices connected to telecommunication network 102. For example, telecommunication network 102 can provide ultra-reliable low-latency communication (URLLC) services to some UEs while providing enhanced mobile broadband (eMBB) services to other UEs, and / or provide massive machine type communication (mMTC) / massive IoT services to yet other UEs.

[0056] In some examples, UE 112 is configured to send and / or receive information without direct human interaction. For example, when triggered by an internal or external event, or in response to a request from access network 104, the UE can be designed to send information to access network 104 on a predetermined schedule. In addition, the UE can be configured to operate in a single RAT or multi-RAT or multi-standard mode. For example, the UE can operate with any one or a combination of Wi-Fi, NR (New Radio), and LTE, i.e., be configured for multi-radio dual connectivity (MR-DC), such as new radio dual connectivity (EN-DC) of E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network).

[0057] In an example, the hub 114 communicates with the access network 104 to facilitate indirect communication between one or more UEs (e.g., UE 112c and / or 112d) and a network node (e.g., network node 110b). In some examples, the hub 114 can be a controller, a router, a content source and analysis, or any other communication device described herein with respect to the UE. For example, the hub 114 can be a broadband router that enables the UE to access the core network 106. As another example, the hub 114 can be a controller that sends commands or instructions to one or more actuators in the UE. The commands or instructions can be received from the UE, the network node 110, or received through executable code, scripts, processes, or other instructions in the hub 114. As another example, the hub 114 can be a data collector that acts as a temporary storage for UE data and, in some embodiments, can perform analysis or other processing of the data. As another example, the hub 114 can be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub 114 can retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, and the hub 114 then provides it to the UE directly, after performing local processing, and / or after adding additional local content. In another example, the hub 114 acts as a proxy server or coordinator for the UE, particularly when one or more of the UEs are low-energy IoT devices.

[0058] The hub 114 can have a constant / persistent or intermittent connection to the network node 110b. The hub 114 can also allow different communication schemes and / or scheduling between the hub 114 and the UE (e.g., UE 112c and / or 112d) and between the hub 114 and the core network 106. In other examples, the hub QQ114 is connected to the core network 106 and / or one or more UEs via a wired connection. In addition, the hub 114 can be configured to be connected to an M2M service provider and / or to another UE via a direct connection through the access network 104. In some scenarios, the UE can establish a wireless connection with the network node 110 while still being connected via a wired or wireless connection via the hub 114. In some embodiments, the hub 114 can be a dedicated hub-that is, a hub whose main function is to route communications to / from the UE from / to the network node 110b. In other embodiments, the hub 114 may be a non-dedicated hub, ie, a device operable to route communications between the UE and the network node 110b, but otherwise operable as a communications origin and / or endpoint for certain data channels.

[0059] Figure 2 is a block diagram of a host 200 according to various aspects described herein, which may be Figure 1 1. As used herein, host 200 may be or include various combinations of hardware and / or software, including processing resources in a standalone server, blade server, cloud-enabled server, distributed server, virtual machine, container, or server farm. Host 200 may provide one or more services to one or more UEs.

[0060] Host 200 includes processing circuitry 202 operatively coupled to input / output interface 206, network interface 208, power supply 210, and memory 212 via bus 204. Other components may be included in other embodiments. The features of these components may be substantially similar to those described with respect to the devices of the previous figures, so that their descriptions generally apply to the corresponding components of host 200.

[0061] Memory 212 may include one or more computer programs, including one or more host applications 214, and data 216, which may include user data, such as data generated by a UE for host 200 or data generated by host 200 for a UE. Embodiments of host 200 may utilize only a subset of the components shown, or all of them. Host application 214 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Universal Video Coding (WC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different categories, types, or implementations for UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). Host application 214 may also provide user authentication and permission checks, and may periodically report health, routing, and content availability to a central node, such as a device in or at the edge of a core network. Thus, host 200 may select and / or instruct different hosts for top-level services for a UE. The host application 214 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real Time Messaging Protocol (RTMP), Real Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), and the like.

[0062] Figure 3 A communication diagram shows a host 302 communicating with a UE 306 via a network node 304 over a partially wireless connection according to some embodiments. Figure 3 Describes the UE discussed in the previous paragraphs (such as Figure 1 UE 112a), network nodes such as Figure 1 network nodes 110a) and hosts such as Figure 1 Host 116 and / or Figure 2 An example implementation of host 200).

[0063] As with host 200, embodiments of host 302 include hardware, such as a communication interface, processing circuitry, and memory. Host 302 also includes software that is stored in or accessible by host 302 and that is executable by the processing circuitry. The software includes a host application that can be operable to provide services to a remote user, such as a UE 306 connected via an over-the-top (OTT) connection 350 extending between UE 306 and host 302. When providing services to the remote user, the host application can provide user data sent using OTT connection 350.

[0064] The network node 304 includes hardware that enables it to communicate with the host 302 and the UE 306. The connection 360 can be direct or through a core network (such as Figure 1 The core network 106) and / or one or more other intermediate networks, such as one or more public, private or managed networks. For example, the intermediate network can be a backbone network or the Internet.

[0065] UE 306 includes hardware and software that are stored in or accessible by UE 306 and that can be executed by the processing circuitry of the UE. The software includes a client application, such as a web browser or an operator-specific "app," that can be operable to provide services to a human or non-human user via UE 306 with the support of host 302. In host 302, an executing host application can communicate with an executing client application via an OTT connection 350 that terminates at UE 306 and host 302. When providing services to a user, the UE's client application can receive request data from the host application of the host and provide user data in response to the request data. The OTT connection 350 can transmit the request data and the user data. The UE's client application can interact with the user to generate user data, which is provided to the host application via the OTT connection 350.

[0066] The OTT connection 350 may extend via a connection 360 between the host 302 and the network node 304 and via a wireless connection 370 between the network node 304 and the UE 306 to provide connectivity between the host 302 and the UE 306. The connection 360 and the wireless connection 370 over which the OTT connection 350 may be provided have been drawn abstractly to illustrate communication between the host 302 and the UE 306 via the network node 304, without explicit reference to any intermediary devices and the precise routing of messages via those devices.

[0067] As an example of transmitting data via OTT connection 350, in step 308, host 302 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a specific human user interacting with UE 306. In other embodiments, the user data is associated with UE 306, which shares data with host 302 without explicit human interaction. In step 310, host 302 initiates a transmission carrying the user data to UE 306. Host 302 may initiate the transmission in response to a request sent by UE 306. The request may be caused by human interaction with UE 306 or by operation of a client application executing on UE 306. In accordance with the teachings of embodiments described throughout this disclosure, the transmission may be delivered via network node 304. Therefore, in step 312, network node 304 transmits the user data carried in the transmission initiated by host 302 to UE 306 in accordance with the teachings of embodiments described throughout this disclosure. In step 314 , UE 306 receives the user data carried in the transmission, which may be performed by a client application executing on UE 306 associated with a host application executed by host 302 .

[0068] In some examples, UE 306 executes a client application that provides user data to host 302. The user data may be provided as a reaction or response to data received from host 302. Thus, in step 316, UE 306 may provide the user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via the input / output interface of UE 306. Regarding a specific manner of providing the user data, in step 318, UE 306 initiates a transmission of the user data to host 302 via network node 304. In step 320, in accordance with the teachings of the embodiments described throughout this disclosure, network node 304 receives the user data from UE 306 and initiates a transmission of the received user data to host 302. In step 322, host 302 receives the user data carried in the transmission initiated by UE 306.

[0069] One or more of the various embodiments improve the performance of an OTT service provided to a UE 306 using an OTT connection 350, with the wireless connection 370 forming the final leg. More specifically, the teachings of these embodiments may also improve latency and throughput during a handover procedure, during which a UE 306 moves from a source network node, such as network node 304, to a target network node, thereby providing benefits such as reduced user latency and better responsiveness after the handover procedure.

[0070] In an example scenario, plant status information may be collected and analyzed by the host 302. As another example, the host 302 may process audio and video data that has been retrieved from the UE for use in creating a map. As another example, the host 302 may collect and analyze real-time data to help control vehicle congestion (e.g., controlling traffic lights). As another example, the host 302 may store surveillance videos uploaded by the UE. As another example, the host 302 may store or control access to media content such as video, audio, VR, or AR that it may broadcast, multicast, or unicast to the UE. As other examples, the host 302 may be used for energy pricing, remote control of non-time-critical electrical loads to balance power generation demand, location services, presentation services (such as compiling charts based on data collected from remote devices, etc.), or any other function that collects, retrieves, stores, analyzes, and / or transmits data.

[0071] In some examples, a measurement process may be provided for the purpose of monitoring data rate, latency, and other factors improved by one or more embodiments. Optional network functionality may also be provided for reconfiguring the OTT connection 350 between the host 302 and the UE 306 in response to changes in measurement results. The measurement process and / or network functionality for reconfiguring the OTT connection may be implemented in software and hardware on the host 302 and / or the UE 306. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection 350 passes; the sensors may participate in the measurement process by providing values ​​of the monitored quantities exemplified above, or by providing values ​​of other physical quantities from which the software can calculate or estimate the monitored quantities. Reconfiguration of the OTT connection 350 may include message formats, retransmission settings, preferred routing, and the like; reconfiguration may not require direct changes to the operation of the network node 304. Such procedures and functionality may be known and practiced in the art. In certain embodiments, the measurements may involve proprietary UE signaling that facilitates the host 302's measurement of throughput, propagation time, latency, and the like. The measurements may be implemented in software that uses the OTT connection 350 to cause messages to be sent, in particular empty or "dummy" messages, while monitoring propagation times, errors, etc.

[0072] In order to trigger a higher layer transport protocol entity or transport protocol, such as TCP or QUIC, to immediately and adequately react to handover related losses, the following operations may be performed. In this regard, handover related losses may be lost data packets lost during the handover process, for example due to a reset of RAN lower layer protocols such as RLC and MAC / HARQ.

[0073] Figure 4A1 shows data transmission in the downlink (DL) direction from a network node 410 to a wireless device 420 according to an embodiment. As explained in more detail above, the wireless device 420 can be any type of device that accesses a cellular communication network (i.e., is served by a cellular communication network) by wirelessly communicating with a network node and / or other wireless devices. Wireless communication can involve sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transmitting information over the air. The wireless device can be a wireless terminal device or UE as described with respect to the previous figures. Some examples of wireless terminal devices include, but are not limited to, terminals, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, rechargeable batteries, wearable devices, wireless endpoints, mobile stations, tablet computers, laptop computers, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless customer premises equipment (CPEs), mobile machine type communication (MTC) devices, Internet of Things (IoT) devices, vehicle-mounted wireless terminal devices, and the like. Unless otherwise specified, the term "wireless device" or "wireless terminal device" is used interchangeably with the term "UE" or "terminal" herein.

[0074] The network node 410 may be a network node as previously described with respect to the previous figures, or a radio network node of any node that is part of a radio access network of a cellular communication network. Functionally, a network node is a device capable of, configured, arranged, and / or operable to communicate directly or indirectly with a wireless device and / or with other network nodes or devices in a cellular communication network to enable and / or provide wireless access to the wireless device, and / or perform other functions (e.g., management) in the cellular communication network. A network node may be a gNodeB, a gNB, etc.

[0075] Note that the description herein focuses on 3GPP cellular communication systems and, therefore, 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems.

[0076] like Figure 4A As shown, for DL ​​transmission, the network node 410 may transmit a data packet to the wireless device 420. When the data packet is correctly and successfully completely received by the wireless device 420, the wireless device 420 may send an acknowledgment (ACK) corresponding to the correctly received data packet to the network node 410. A correctly and successfully completely received data packet may be, for example, a data packet received without error.

[0077] If data packets are lost and not received by wireless device 420, or if data packets are not correctly received by wireless device 420, wireless device 420 may refrain from sending an ACK. For example, wireless device 420 may send a non-acknowledgement (NACK) instead of an ACK, or may send neither an ACK nor a NACK, to network node 410. Thus, network node 110 may be triggered to retransmit data packets for which an ACK has not yet been received.

[0078] Figure 4B 1 shows data transmission in the uplink (UL) direction from a wireless device 420 to a network node 410 according to an embodiment. For UL transmission, the wireless device 420 may transmit a data packet to the network node 410. When a data packet is correctly and successfully received in its entirety by the network node 410, the network node 410 may send an ACK corresponding to the correctly received data packet to the wireless device 420. If the network node 410 does not receive any data packets or if the network node 410 receives a data packet with errors, the network node 410 may refrain from sending an ACK to the wireless device 420. For example, the network node 410 may send a NACK to the wireless device 420 instead of an ACK, or may send neither a NACK nor an ACK. If the wireless device 420 does not receive an ACK for a data packet, the wireless device 420 may be triggered to retransmit the data packet.

[0079] ACK and NACK feedback may be implemented by, for example, the hybrid automatic repeat request HARQ of the 5G or 6G physical layer.

[0080] Figure 5 A receiving data link layer protocol entity 520 and a receiving higher layer transport protocol entity 510 are shown for performing the functionality of the receiving side 500 of the data packet according to an embodiment.

[0081] For DL ​​transmissions, the receiving side 500 may include the wireless device 420. For UL transmissions, the receiving side 500 may include the network node 410 and / or the core network node. If the receiving side 500 includes the wireless device 420, the wireless device 420 may include a receive data link layer protocol entity 520 and a receive higher layer transport protocol entity 510, wherein the wireless device 420 may receive packets from the network in the DL transmission. Both entities 510 and 520 need not be located within a single wireless device 420, but may be located in more than one wireless device, thereby being located in different locations. For example, the wireless device 420 may be a smartwatch and a small pocket device, wherein the receive higher layer transport protocol entity 510 and the receive data link layer protocol entity 520 may be divided between the smartwatch and the small pocket device.

[0082] For network node 410, the receive data link layer protocol entity 510 and the receive higher-layer transport protocol entity 510 may reside in separate nodes. For example, a network node, such as a radio network node (e.g., a gNB), may include a receive RAN layer protocol entity and a receive data link layer protocol entity 520. In 3GPP 5G, for example, the data link layer protocol executed by receive data link layer protocol entity 520 may be PDCP. In 3GPP 6G, this protocol may be referred to differently. Network node 410 may receive packets in a UL transmission from wireless device 420. The receive higher-layer transport protocol entity may not reside in the core network, but rather outside the telecommunications network, i.e., outside the RAN or core network. For example, the receive higher-layer transport protocol entity may be executed by a server somewhere on the Internet or in a data network.

[0083] For core network nodes, the core network node may include a receiving data link layer protocol entity that can execute PDCP or any other data link layer protocol. A network node, such as a gNB, may also include a RAN layer protocol entity as a separate node. The core network node may receive packets in UL transmissions from wireless devices or network nodes such as gNBs. Similar to network nodes, the receiving higher-layer transport protocol entity may not reside in the core network, but rather outside the telecommunications network, i.e., outside the RAN or core network. For example, the receiving higher-layer transport protocol entity may be executed by a server somewhere on the Internet or in a data network.

[0084] The receiving data link layer protocol entity 520 and optionally the receiving higher layer transport protocol entity 510 may perform the functions of the respective protocol layers of the receiving side 500. In other words, the data link layer protocol entity or the higher layer transport protocol entity may represent a logical instance.

[0085] The receiving data link layer protocol entity 520 and the receiving high-level transport protocol entity 510 can each be loaded into respective hardware, which can use respective software to implement the functions of entities 510 and 520. For example, the hardware device has a processor and optionally a memory. As a logical example, the protocol entity 520 and optionally 510 can be loaded into the processor, causing the hardware device to perform the actions provided by the protocol entities 510 and 520.

[0086] Figure 14 The following illustrates an example of corresponding hardware that can use software to implement the functions described herein. Figure 14 As can be seen in FIG, optional components are shown with dashed lines. The hardware device 1400 may include a processor 1410 and an optional interface 1420 and / or memory 1430.

[0087] Compared to the reception high-layer transmission protocol entity 510 which may perform the function of a higher protocol layer of the reception side 500 , the reception data link layer protocol entity 520 may perform the function of a lower protocol layer of the reception side 500 .

[0088] For the RAN, the reception data link layer protocol entity 520 may be located in the data link layer of the reception side 500 and may perform data link layer functions. For example, the reception data link layer protocol entity 520 is a reception PDCP entity that performs the functions of the PDCP sublayer of the reception side 500.

[0089] The receiving high-level transport protocol entity 510 may be located in the transport layer of the receiving side 500 and may perform the functions of the transport layer. For example, the receiving high-level transport protocol entity 510 is a receiving transport protocol entity located in the transport layer and may use TCP or QUIC.

[0090] like Figure 5 As shown, the receiving side 500 can receive data packets sent from a sending node (not shown). As described above, the receiving side 500 can include the wireless device 420, and the sending node can be the network node 410 for DL ​​transmission. For UL transmission, the receiving side 500 can include the network node 410 and / or the core network node, and the sending node can be the wireless device 420.

[0091] Received data packets can be delivered from a lower layer to a higher layer using a corresponding receiving protocol entity. Thus, the receiving data link layer protocol entity 520 can receive data packets from a receiving lower layer protocol entity and can deliver the data packets to the receiving higher layer transport protocol entity 510. The receiving data link layer protocol entity 520 can be a receiving PDCP entity that receives data packets from a receiving RAN lower layer protocol entity. As an example of the receiving higher layer transport protocol entity 510, the receiving PDCP entity can deliver the data packets to the receiving transport protocol entity.

[0092] In response to the data packet, the receiving high-level transport protocol entity 510 can deliver an ACK to the receiving low-level protocol entity, which can then send the ACK to the sending node. These ACKs are used to confirm the correct and successful reception of the data packet. In more detail, the receiving high-level transport protocol entity 510 can deliver the ACK to the receiving data link layer protocol entity 520, which can then deliver the ACK to the receiving low-level protocol entity on the receiving side 500.

[0093] Figure 6The transmitting data link layer protocol entity 620 and the transmitting higher layer transport protocol entity 610 are shown as performing the functions of the transmitting side 600 of the communication. For DL ​​transmission, the transmitting side 600 may include the network node 410 and / or the core network node. For UL transmission, the transmitting side 600 may include the wireless device 420.

[0094] If the transmitting side 600 includes a wireless device 420, the wireless device 420 may include a transmitting data link layer protocol entity 620 and a transmitting higher layer transport protocol entity 610. Both entities 610 and 620 need not be located in a single wireless device 420, but may be located in more than one wireless device (see also the description of FIG. Figure 5 examples given).

[0095] For DL ​​transmission, the transmitting data link layer protocol entity 620 and the transmitting higher-layer transport protocol entity 610 may reside in separate nodes. For example, a network node, such as a gNB, may include a transmitting RAN layer protocol entity and a transmitting data link layer protocol entity 620. The transmitting higher-layer transport protocol entity 610 may not reside in the core network but rather outside the telecommunications network, i.e., outside the RAN or core network. For example, the transmitting higher-layer transport protocol entity 610 may be executed by a server somewhere on the Internet or a data network.

[0096] The core network node may also include a transmit data link layer protocol entity 620, which may execute PDCP or any other data link layer protocol. A network node, such as a gNB, may also include RAN layer protocol entities as a separate node. The core network node can send packets in a DL transmission to a wireless device or network node, such as a gNB. Similar to the network node, the transmit higher-layer transport protocol entity 610 may not reside in the core network, but rather outside the telecommunications network, i.e., outside the RAN or core network. For example, the transmit higher-layer transport protocol entity 610 may be executed by a server somewhere on the Internet or in a data network.

[0097] The sending data link layer protocol entity 620 and the sending high-layer transmission protocol entity 610 can execute the functions of each layer, that is, can execute the protocols of each layer.

[0098] The sending data link layer protocol entity 620 and the sending high-level transport protocol entity 610 can each be loaded into respective hardware, which can use respective software to implement the functions of the entities 610 and 620. For example, the hardware device has a processor and optionally a memory. The protocol entities 620 and 610 as logical instances are loadable so that the hardware device performs the actions provided by the protocol entities 610 and 620. Please refer to Figure 14 An example of a hardware device.

[0099] Compared to the transmitting high-layer transmission protocol entity 610 which may perform the functions of the higher layers of the transmitting side 600 , the transmitting data link layer protocol entity 620 may perform the functions of the lower layers of the transmitting side 600 .

[0100] The transmitting data link layer protocol entity 620 may perform the function of the data link layer of the transmitting side 600. For example, the transmitting data link layer protocol entity 620 is a transmitting PDCP entity that performs the function of the PDCP sublayer of the transmitting side 600.

[0101] The sending high-level transport protocol entity 610 may perform the transport layer function of the sending side 600. For example, the sending high-level transport protocol entity 610 is a sending transport protocol entity that performs the transport layer function. The sending transport protocol entity may implement TCP or QUIC.

[0102] like Figure 5 As exemplarily shown in FIG, data packets sent from the transmitting side 600 to the receiving side 500 can be delivered from a higher layer to a lower layer using corresponding transport protocol entities. Thus, the transmitting higher layer transport protocol entity 610 can deliver the data packet to the transmitting data link layer protocol entity 620, and then the transmitting data link layer protocol entity 620 can deliver the data packet to the transmitting lower layer protocol entity (not shown). Finally, the data packet is sent to the receiving side 500.

[0103] According to an embodiment in the RAN, the transmitting PDCP entity 620 may receive data packets from the transmitting transport protocol entity 610. The transmitting PDCP entity 620 may deliver the data packets to the transmitting RAN lower layer protocol entity, which may then send the data packets to the receiving side 500.

[0104] In response to the data packet being successfully and completely received by the receiving side 500, the transmitting side 600 may receive an ACK from the receiving side 500. The transmitting lower layer protocol entity may deliver the ACK to the transmitting data link layer protocol entity 620, and then the transmitting data link layer protocol entity 620 may deliver the ACK to the transmitting higher layer transport protocol entity 610 to confirm the correct and successful receipt of the data packet.

[0105] Figure 7 1 shows a system overview 700 of a high-level transport protocol entity and a data link layer protocol entity with a transmitting side 600 and a receiving side 500 according to an embodiment. Figure 5 and Figure 6 The transmitting side 600 and the receiving side 500 are described in detail.

[0106] Figure 7The interaction between entities of the sending node 600 and the receiving node 500 is exemplarily shown when the sending node 600 sends a data packet to the receiving node 500 and the receiving node 500 sends an ACK to the sending node 600 when the data packet is successfully received.

[0107] As in Figure 7 As can be seen in FIG, the sending higher-layer transport protocol entity 610 of the sending side 600 can deliver the data packet to the sending data link layer protocol entity 620. The sending data link layer protocol entity 620 can deliver the data packet to the sending lower-layer protocol entity (not shown), which can send the data packet to the receiving entity of the receiving side 500. For example, the receiving lower-layer protocol entity (not shown) can receive the data packet from the sending lower-layer protocol entity and can deliver the data packet to the receiving data link layer protocol entity 520. The receiving data link layer protocol entity 520 can deliver the data packet to the receiving higher-layer transport protocol entity 510.

[0108] In response to successfully receiving a data packet, the receiving higher-layer transport protocol entity 510 may deliver an ACK corresponding to the successfully received data packet to the receiving data link layer protocol entity 520. The receiving data link layer protocol entity 520 may deliver the ACK to the receiving lower-layer protocol entity, which may then send the ACK to the sending lower-layer protocol entity on the transmitting side 600. The sending lower-layer protocol entity may deliver the ACK to the sending data link layer protocol entity 620, which may then deliver the ACK to the sending higher-layer transport protocol entity 610. By receiving the ACK, the sending higher-layer transport protocol entity 610 may know or determine that the data packet corresponding to the ACK has been successfully received by the receiving side 500 and that there is no need to retransmit the data packet. However, if the sending higher-layer transport protocol entity 610 does not receive any ACK corresponding to the data packet, the sending higher-layer transport protocol entity 610 may assume that the data packet has been lost and may retransmit the data packet to the receiving side 500. Thus, the data packet is ensured to be successfully transmitted from the transmitting side 600 to the receiving side 500, thereby avoiding unnecessary retransmissions.

[0109] Figure 8 An exemplary system overview 800 is shown, wherein the transport protocol entity is a higher layer protocol entity and the PDCP entity is a data link layer protocol entity of the transmitting side 1000 and the receiving side 900 of the communication. The transmitting side 1000 and the receiving side 900 are similar to the Figure 5 and Figure 7 The transmitting side 600 and the receiving side 500 are described. Therefore, for the sake of simplicity, a detailed description of how data packets and ACKs are sent between the transmitting side 1000 and the receiving side 900 is omitted at this point.

[0110] like Figure 8 As exemplarily shown in FIG, the sending side 1000 may include a sending transport protocol entity 1010, which serves as the above-mentioned sending high-layer transport protocol entity. The sending transport protocol entity 1010 may execute TCP or QUIC.

[0111] Furthermore, the transmitting side 1000 may include a transmitting PDCP entity 1020 serving as the aforementioned transmitting data link layer protocol entity and a transmitting RAN lower layer protocol entity 1030. The transmitting RAN lower layer protocol entity may introduce out-of-order delivery and simultaneously introduce hybrid automatic repeat request (HARQ).

[0112] Similar to the transmitting side 1000, the receiving side 900 may include a receiving transport protocol entity 910 serving as the above-mentioned receiving higher-layer transport protocol entity. The receiving transport protocol entity 910 may implement TCP or QUIC.

[0113] In addition, the receiving side 900 may include a receiving PDCP entity 920 serving as the aforementioned receiving data link layer protocol entity. The receiving PDCP entity 920 may optionally perform reordering of received data packets. The receiving side 900 may also include a receiving RAN lower layer protocol entity 930, which may introduce out-of-order delivery with the introduction of HARQ.

[0114] For DL ​​transmissions, the transmit transport protocol entity 1010 may be located in a server, and entities 1020 and 1030 may be located in a network node, such as a gNB. Alternatively, the transmit PDCP entity 1020 may be located in a core network node, and the transmit RAN low layer protocol entity 1030 may be located in a network node. The receiving side 900 may include a single wireless device, with all entities 910, 920, and 930 integrated into the single wireless device. However, the wireless device may also include more than one device, where, for example, entity 910 may be part of a smartwatch, while entities 920 and 930 may be part of a UE or smartphone.

[0115] For UL transmissions, this is vice versa compared to DL transmissions. Transmitting side 1000 may comprise a single wireless device, with all entities 1010, 1020, and 1030 integrated into the single wireless device. However, the wireless device may also comprise more than one device, where, for example, entity 1010 may be part of a smartwatch, etc., while entities 1020 and 1030 may be part of a UE or smartphone. The receiving transport protocol entity 910 may reside in a server, and entities 920 and 930 may reside in a network node, such as a gNB. Optionally, the transmitting PDCP entity 920 may reside in a core network node, and the transmitting RAN low layer protocol entity 930 may reside in a network node.

[0116] By allowing out-of-order delivery by the PDCP entity, latency spikes may be avoided because the PDCP entity does not need to wait for all data packets and ACKs to arrive and be in order before delivering them to higher or lower layer protocol entities.

[0117] As mentioned above, the transport protocol and its congestion control algorithm, implemented by a higher-level protocol entity, must identify congestion on the transport connection in order to estimate the number of packets in transit and avoid further congestion. This is accomplished by observing packet reordering, i.e., observing the number and timing of data packets received after a lost data packet. The sending higher-level transport protocol entity implementing the transport protocol can obtain this information based on ACKs received from the receiving higher-level transport protocol entity.

[0118] However, problems may arise with the handover process, which ensures the transfer of a wireless device from a source network node serving a source cell to a target network node serving a target cell. With a handover, packets that have not yet been sent are lost. Consequently, the receiving data link layer protocol entity does not have any packets in its receive queue that it can deliver to the receiving higher-layer transport protocol entity during / after the handover. Since the receiving higher-layer transport protocol entity does not receive any data packets, it does not deliver any ACKs to the receiving lower-layer protocol entity to send to the sending higher-layer transport protocol entity. However, with congestion control, the sending higher-layer transport protocol entity waits for ACKs after lost data packets and stops sending new data packets to the network. The sending higher-layer transport protocol entity may only attempt to retransmit packets after a (potentially long-running) recovery timer expires, resulting in significant and unnecessary delays. Furthermore, the sending higher-layer transport protocol entity may set its congestion window to a very small value, so that subsequent transmissions after the handover may not keep up.

[0119] To avoid these unnecessary delays and small congestion windows, the concept is to redeliver one or several packets from the receiving data link layer protocol entity to the receiving higher-layer transport protocol entity. The receiving data link layer protocol entity and the receiving higher-layer transport protocol entity may operate for (i.e., perform) the functions of a wireless device for DL ​​transmissions, or a network device and / or core network node for UL transmissions.

[0120] Based on the redelivery of at least one packet, the receiving higher-level transport protocol entity may be triggered to react and send an ACK to the sending higher-level transport protocol entity, which in turn may trigger further data packet transmission. Thus, alternative recovery mechanisms in the transport protocol implementation, such as connection probing and delayed ACK transmission (which incur overhead if frequent and delay if infrequent), are avoided.

[0121] Figure 9 An exemplary method performed by a receiving data link layer protocol entity for triggering further data packet transmission is shown. The method may be triggered when no retransmission of lost data associated with the handover is foreseen (e.g., no PDCP-like protocol) and / or no buffered forwarding from the source network node to the target network node during the handover in the RAN. Optional steps are shown with dashed lines.

[0122] For further details on the receiving data link layer protocol entity, for the sake of simplicity, reference is made to the explanation given above. The receiving data link layer protocol entity may be a receiving PDCP entity for the RAN layer. The receiving PDCP entity may be loadable into hardware and may use corresponding software to perform the functions of the PDCP sublayer.

[0123] like Figure 9 As shown, the receiving data link layer protocol entity can deliver (S910) multiple data packets to the receiving high-level transport protocol entity. For a detailed description of the receiving high-level transport protocol entity, we refer to the explanation given above. The receiving high-level transport protocol entity can be a receiving transport protocol entity for the RAN protocol layer. The receiving transport protocol entity can use TCP or QUIC. The receiving transport protocol entity can be loaded into hardware, which can use corresponding software to perform the functions of the transport layer. For example, the receiving transport protocol entity is part of a mobile network, which can be an in-network TCP or QUIC entity or a proxy entity, for example, located in the core network or as part of the Internet, a host, a server, etc.

[0124] Furthermore, the receiving data link layer protocol entity may redeliver (S930) a selected number of the last delivered data packets from the plurality of data packets to the receiving higher layer transport protocol entity a certain number of times during the handover process. The selected number of the last delivered data packets may be predetermined or preselected before the handover process is performed. The expression "during the handover process" may be understood as "part of the handover process."

[0125] Optionally, the receiving data link layer protocol entity may store (S920) a selected number of the last delivered data packets before redelivering them to the higher-level transport protocol entity. The last delivered data packet may be the data packet that was last delivered to the receiving higher-level transport protocol entity in time among the plurality of data packets. The receiving data link layer protocol entity may use a storage entity for storing, saving, or memorizing the data packets. The storage entity may be a memory that is part of the receiving node or an entity separate from the receiving node.

[0126] In other words, the concept is to trigger a reaction—i.e., a transport protocol reaction—by duplicating a previously delivered data packet from a receiving data link layer protocol entity (e.g., a receiving PDCP entity in a RAN) to trigger a receiving higher-layer transport protocol entity to send an ACK. A selected number of the last delivered data packets can be handled by a wireless device, such as a UE or terminal, for downlink transmission, or by a network node, such as a gNB, and / or a core network node, for uplink transmission. In other words, the receiving data link layer protocol entity and the receiving higher-layer transport protocol entity can perform the functions of a wireless device, a network node, and / or a core network node.

[0127] Figure 10 An example for triggering further data transmission is shown. Figure 10 As exemplarily shown in FIG, the receiving data link layer protocol entity may receive data packets 1, 2, and 3 (DPI, DP2, and DP3) within time t before the switching process. These DPI, DP2, and DP3 may be delivered to the receiving higher layer transport protocol entity.

[0128] However, during the handover process, it is possible that the receiving data link layer protocol entity no longer receives further data packets, so typically no data packets can be delivered to the receiving higher layer transport protocol entity.

[0129] However, in order to still trigger a reaction of the receiving higher-layer transport protocol entity during the handover process and thus a further data transmission by the sending higher-layer transport protocol entity, the receiving data link layer protocol entity may perform storage of a selected number X of the last delivered data packets out of the plurality of data packets DPI, DP2 and DP3 that have been delivered to the receiving higher-layer transport protocol entity. Thus, the receiving data link layer protocol entity is able to remember or save the X last delivered data packets.

[0130] exist Figure 10 In

[15] , the selected number X of the last transmitted data packet is set to 1. Therefore, the receiving data link layer protocol entity can perform storage of the last delivered data packet DP3. However, X can be any positive integer. When multiple TCP flows are multiplexed in the PDCP buffer, it may be advantageous to have X > 1. For example, when the selected number X is set to 2, the receiving data link layer protocol entity can perform storage of the last two delivered data packets DP2 and DP3.

[0131] During the handover, the receiving data link layer protocol entity may redeliver these stored (i.e., remembered or saved) X data packets to the receiving higher-layer transport protocol entity a certain number of times Y. Here, Y is set to 3, but Y can be set to any positive integer. Y>1 may be beneficial to avoid ACK loss. In addition, if there is a timer running in TCP, Y>1 may be beneficial, which can prevent data retransmission when Y=1. When X=1 and Y=3, as Figure 10 As shown in the example, DP3 is redelivered three times to the receiving higher-layer transport protocol entity.

[0132] By redelivering a selected number of last delivered data packets a certain number of times during the handover process, the transmission of duplicate ACKs from the receiving higher-level transport protocol entity to the sending higher-level transport protocol entity is triggered. When the receiving higher-level transport protocol entity obtains data packets below the upper window boundary again (i.e., obtains duplicate data packets), the receiving higher-level transport protocol entity immediately sends a duplicate ACK even if the delayed ACK timer is running, because the repeatedly received data packets are considered to be reordered. In addition, the receiving higher-level transport protocol entity can send a duplicate ACK immediately because it assumes that the data packet loss has been identified. In other words, before the delayed ACK timer expires, the receiving higher-level transport protocol entity can send a duplicate ACK in response to the redelivered selected number of last delivered data packets, thereby achieving rapid and immediate recovery from the handover process.

[0133] In contrast to Selective ACK (SACK), a Duplicate ACK can trigger, at the sending higher-layer transport protocol entity, the retransmission of all data packets for which the sending higher-layer transport protocol entity has not yet received an ACK. In other words, when the sending higher-layer transport protocol entity receives a Duplicate ACK, it can retransmit all data packets that have not yet been (selectively) acknowledged by the receiving higher-layer transport protocol entity, even for gaps between selectively acknowledged data packets, and even for data packets above low transmit (Tx) boundaries that have never been (selectively) acknowledged or for which no higher ACK has been received before.

[0134] Furthermore, by receiving duplicate ACKs instead of selective ACKs, the sending higher-layer transport protocol entity may interpret the duplicate ACKs as data packet loss due to congestion and may immediately reduce the congestion window. Thus, duplicate ACKs may trigger a reduction in the congestion window at the sending higher-layer transport protocol entity.

[0135] Thus, fast and immediate handover recovery in the event of handover-related losses is ensured, and low latency is achieved without negatively impacting throughput and / or latency during the handover process. Furthermore, alternative recovery mechanisms in transport protocol implementations, such as connectivity probing and delayed acknowledgment transmission, are avoided.

[0136] According to one embodiment, a duplicate ACK can trigger a retransmission of a data packet at the sending higher-layer transport protocol entity only if the data packet was sent at least a certain RACK round-trip time (RTT) delay before the most recent ACK (RACK). The RACK RTT delay threshold is adaptive and can be set appropriately. By waiting for a certain RACK RTT delay threshold before sending a data packet, the sending higher-layer transport protocol entity is ensured to eliminate interference from potential reordering.

[0137] According to another embodiment, the receiving data link layer protocol entity can spread out the redelivery of a selected number of the last delivered data packets in time, for example, with 5 milliseconds between deliveries. Thus, by spreading out the redeliveries and introducing a delay between the redeliveries, for example, with a 5 ms delay between repeated deliveries, it is ensured that retransmissions will be triggered regardless of the RACK, and in particular regardless of the RACK reordering latency. This embodiment is not limited to 5 ms, and any other time value for spreading out the redeliveries in time can be selected to ensure triggering of retransmissions.

[0138] A receiving data link layer protocol entity may deliver multiple data packets to a receiving higher-level transport protocol entity out of order, or may deliver multiple data packets to a receiving higher-level transport protocol entity in an ordered manner. Out-of-order delivery may be performed to ensure continuous operation, lower latency, increased interactivity, and reduced head-of-line blocking. For in-order delivery, the receiving data link layer protocol entity may redeliver a selected number of the last delivered packets if the receiving data link layer protocol entity does not forward during a handoff.

[0139] For example, when PDCP out-of-order continuation operation is configured, the receiving PDCP entity may be configured to perform storage, i.e., may be configured to remember or save the last X delivered data packets. During handover, the receiving PDCP entity may be configured to redeliver these X packets Y times to the receiving higher-layer transport protocol entity. Upon receiving ACKs for these duplicate delivered data packets, the transport protocol implemented by the transmitting side of the communication may be expected to immediately react to the retransmission of the lost intermediate data packets (which were lost during the handover process).

[0140] The receiving data link layer protocol entity may suppress buffer forwarding during the handover process. For example, for in-order delivery, if the receiving data link layer protocol entity suppresses buffer forwarding from the source network node to the target network node during the handover process, the receiving data link layer protocol entity may perform redelivery.

[0141] The receiving data link layer protocol entity can be in unacknowledged mode (UM) or acknowledged mode (AM). For example, in AM, the receiving data link layer protocol entity can suppress buffer forwarding during the handover process. In UM, retransmission of lost data packets in PDCP is not possible.

[0142] According to one embodiment, the receiving data link layer protocol entity may be a receiving PDCP entity that may perform storage of a selected number of the last delivered data packets and / or may redeliver a selected number of the last delivered data packets during a handover, for example as part of a PDCP re-establishment procedure, when the handover is completed, or when a connection to a target cell is established. Completion of the handover may be considered the last step of the handover procedure. In other words, the storage and / or redelivery may be performed during the PDCP re-establishment procedure, i.e., at the end of the handover procedure, when the handover procedure is completed, or when the target cell is established. The PDCP re-establishment procedure may be triggered upon a handover.

[0143] For example, for downlink transmissions, the receiving PDCP entity may perform the functionality of a wireless device that performs retransmissions during a PDCP re-establishment procedure, upon completion of a handover procedure, or upon target cell establishment.

[0144] As described above, the receiving data link layer protocol entity can perform various layer functions of the wireless device. Furthermore, the receiving higher-layer transport protocol entity can perform higher-layer functions of the wireless device. Therefore, the receiving data link layer protocol entity and the receiving higher-layer transport protocol entity perform functions of the wireless device, i.e., operate within the wireless device.

[0145] For uplink transmission, the receiving data link layer protocol entity can perform the corresponding layer functions of the network node and / or core network node. Furthermore, the receiving higher-layer transport protocol entity can perform the higher-layer functions of the network node and / or core network node. Thus, the receiving data link layer protocol entity and the receiving higher-layer transport protocol entity perform the functions of the network device and / or core network node, i.e., operate within the network device and / or core network node. The receiving data link layer protocol entity that performs the aforementioned redelivery can perform the functions of the source network node or the destination network node.

[0146] When the above-mentioned receiving data link layer protocol entity operates in the source network node, i.e., performs the functions of the source network node such as the source gNB, the receiving data link layer protocol entity may perform redelivery, for example, when a handover is triggered for the wireless device, such as when a handover command is sent, or when the target network node indicates that the handover is successful.

[0147] Alternatively, the receiving data link layer protocol entity may operate in the target network node and may perform redelivery after receiving a selected number of last delivered data packets from the source network node. For example, the receiving data link layer protocol entity of the target network node may redeliver the data packets to the receiving higher-level transport protocol entity of the target network node, which requires the receiving data link layer protocol entity of the source network node to forward the stored selected number of last delivered data packets to the receiving data link layer protocol entity of the target network node.

[0148] Figure 11 An example method for triggering fast handover recovery, performed by a system including a transmitting node on the transmitting side and a receiving node on the receiving side, is shown. For the sake of simplicity, a detailed description of the transmitting and receiving sides is omitted at this point, and reference is made to the explanations given above. Optional steps are shown with dashed lines.

[0149] The sending node may send multiple data packets to the receiving node, and the receiving node responds to the successful receipt of the multiple data packets by sending an ACK to the sending node.

[0150] The sending node may use a sending data link layer protocol entity and a sending higher layer transport protocol entity. The sending data link layer protocol entity may be a sending PDCP entity, and the sending higher layer transport protocol entity may be a sending transport protocol entity, as explained above.

[0151] The receiving node may use a receiving data link layer protocol entity and a receiving higher layer transport protocol entity. The receiving data link layer protocol entity may be a receiving PDCP entity, and the receiving higher layer transport protocol entity may be a receiving transport protocol entity, as explained above.

[0152] like Figure 11 As exemplarily shown in FIG, a sending node may send (S1110) a plurality of data packets to a receiving node. The plurality of data packets may be received by the receiving node (S1120).

[0153] The receiving node, in particular the receiving data link layer protocol entity, may deliver (S1130) a plurality of the plurality of data packets to the receiving higher layer transport protocol entity.

[0154] Furthermore, the receiving data link layer protocol entity re-delivers (S1150) a selected number of last delivered data packets to the receiving higher layer transport protocol entity a certain number of times during the handover process.

[0155] Optionally, the receiving data link layer protocol entity may store (S1140) a selected number of last delivered data packets before redelivering them.For example, a storage entity such as a memory may be used which stores a selected number of last delivered data packets.

[0156] As described above, the receiving higher-level transport protocol entity on the receiving side can send a duplicate ACK to the sending side, particularly the sending higher-level transport protocol entity, in response to the re-delivered selected number of last delivered data packets before the delayed ACK timer expires. The sending higher-level transport protocol entity can retransmit data packets whose ACKs have not yet been received by the sending higher-level transport protocol entity to the receiving side. Thus, fast handover recovery is achieved.

[0157] Figure 12 Shown is an exemplary configuration of a receiving node 1200. The receiving node 1200 may be a wireless device for receiving DL transmissions from the network, or a network node and / or core network node for receiving UL transmissions from a wireless device.

[0158] The receiving node 1200 may include a processing unit 1210 and a communication interface. For example, the receiving node 1200 includes a transmitting unit 1220 and a receiving unit 1230 for communicating with the transmitting node. The receiving node 1200 may also include a memory, which may also be referred to as a storage unit or storage entity (not shown). The processing unit 1210 may be a processing circuit (which may also be referred to as a control circuit) and may also be referred to as a processor. Any module or unit of the receiving node 1200 may be implemented in the processing unit 1210 and / or executed by the processing unit 1210, in particular as a module in the processor 1410. For example, the receiving data link layer protocol entity may be loadable into the processor 1410.

[0159] If the receiving node 1200 is a wireless device such as a UE or a terminal, the reception data link layer protocol entity and the higher layer transmission protocol entity may be loadable into the processor 1410 .

[0160] If the receiving node 1200 is a network node such as a gNB or a core network node, the receiving data link layer protocol entity may be loadable to the processor 1410. The higher-layer transport protocol entity may not be loaded into the processor 1410, but may be loaded into a server or host outside the telecommunications network (RAN or core network), for example, loaded into a server somewhere in the Internet or a data network.

[0161] Transmitting unit 1220 and receiving unit 1230 may be radio circuits that provide receiving and transmitting or transceiving functionality, such as one or more transmitters and / or receivers and / or transceivers, wherein the radio circuits are connected or connectable to processing unit 1210. Antenna circuitry (not shown) of receiving node 1200 may be connected or connectable to the radio circuits to collect or transmit and / or amplify signals. For example, receiving unit 1230 may be used to receive data packets sent by a transmitting node. Transmitting unit 1220 may be configured to send an ACK (selective and / or repeated ACK) to the transmitting node. Receiving node 1200 may be adapted to perform any of the above-described methods.

[0162] Figure 13 Shown is an exemplary configuration of a transmitting node 1300. The transmitting node 1300 may be a wireless device for transmitting UL transmissions to a network, or a network node and / or a core network node for transmitting DL transmissions to wireless devices.

[0163] The sending node 1300 may include a processing unit 1310 and a communication interface. For example, the sending node 1300 includes a sending unit 1320 and a receiving unit 1330 for communicating with the receiving node. The sending node 1300 may further include a memory, which may also be referred to as a storage unit or storage entity (not shown). The processing unit 1310 may be a processing circuit (which may also be referred to as a control circuit) and may also be referred to as a processor. Any module or unit of the sending node 1300 may be implemented in the processing unit 1310 and / or executed by the processing unit 1310, in particular as a module in the processing unit 1310. For example, a sending data link layer protocol entity may be loadable into the processing unit 1310.

[0164] If the transmitting node 1300 is a wireless device such as a UE or a terminal, the transmitting data link layer protocol entity and the higher layer transmission protocol entity may be loadable into the processing unit 1310 .

[0165] If the transmitting node 1300 is a network node such as a gNB or a core network node, the transmitting data link layer protocol entity may be loadable into the processing unit 1310. The higher-layer transport protocol entity may not be loaded into the processing unit 1310, but may be loaded into a server or host outside the telecommunications network (RAN or core network), for example, loaded into a server somewhere in the Internet or a data network.

[0166] The transmitting unit 1320 and the receiving unit 1330 may be radio circuits that provide receiving and transmitting or transceiving functions, such as one or more transmitters and / or receivers and / or transceivers, wherein the radio circuits are connected or connectable to the processing unit 1310. Antenna circuitry (not shown) of the transmitting node 1300 may be connected or connectable to the radio circuits to collect or transmit and / or amplify signals. For example, the transmitting unit 1320 may be used to transmit data packets. The receiving unit 1320 may be configured to receive ACKs (selective and / or repeated ACKs) from the receiving node. The transmitting node 1300 may be adapted to perform any of the methods described above.

[0167] The sending node and receiving node described here can also be implemented as hardware devices 1400, such as Figure 14 As shown in the example.

[0168] Figure 15 Figure 2 shows simulation results using the method for fast handover recovery described herein according to an embodiment. Figure 15 , the target bit rate for a 10 MB file download on a 100 Mbit / s channel with HARQ and a 10% block error rate (BLER) target is shown over time t in ms.

[0169] The umooo line shows the results of PDCP unacknowledged mode with out-of-order delivery.

[0170] The umoooDeliverAgain0-3 lines show the results of the PDCP unacknowledged mode with out-of-order delivery, where no data packets are lost and buffer forwarding is performed. Repeated delivery of the last downlink TCP data packet is performed in the receiving PDCP entity (three times after the handover). Since the same results as the baseline (umooo line) are achieved in this case, the umooo line and the umoooDeliverAgain0-3 lines are shown in Figure 2. Figure 15 overlap each other in the graph.

[0171] The umoooNoHoForward line shows the results of PDCP unacknowledged mode with out-of-order delivery but no handover buffer forwarding.

[0172] Lines umoooNoHoForwardDeliverAgain0-3 show the results of PDCP unacknowledged mode with out-of-order delivery but no handover buffer forwarding. Here, the above-described method for storing and redelivering a selected number of last delivered data packets Y times during a handover procedure is performed, where Y is set to 3.

[0173] from Figure 15It can be seen that even without performing buffer forwarding, good performance can still be achieved when performing the method described herein for storing and redelivering a selected number of the last delivered data packets Y times. This can be seen when comparing the umoooNoHoForward line and the umoooNoHoForwardDeliverAgain0-3 line. The umoooNoHoForwardDeliverAgain0-3 line shows improved results compared to the umoooNoHoForward line.

[0174] Figure 16 Another simulation result using the method described in this article for fast switching recovery is shown. Figure 15 The same setup, showing a handover during the slow start phase of a TCP download. By performing the above method without buffer forwarding during the handover, it can be seen that nearly identical results can be achieved as with buffer forwarding, as seen in the umoooNoHoForwardDeliveryAgain0-3 line, which is close to the umooo baseline and umoooDeliverAgain0-3 lines. The umoooNoHoForward line highlights the poorer performance achieved without either buffer forwarding or the above method.

[0175] therefore, Figure 15 and 16 It is shown that when the above method is performed in a receiving data link layer protocol entity, ie when duplicate ACKs are triggered by storing and redelivering a selected number of last delivered data packets a certain number of times, very good performance and fast handover recovery can be achieved.

[0176] In the foregoing, methods and techniques have been provided for receiving data link layer protocol entities (e.g., receiving PDCP entities) such that, when continuous (PDCP) out-of-order or in-order operation is configured, the transport protocol will immediately and adequately react to handover-related losses. Thus, by adjusting RAN protocol behavior at, for example, PDCP, fast handover recovery is achieved.

[0177] Also generally contemplated is a computer program product comprising instructions, particularly when executed on a processing and / or control circuit, adapted to cause the processing and / or control circuit to perform and / or control any of the methods described herein with respect to a receiving / transmitting data link layer protocol entity, a receiving / transmitting higher layer transport protocol entity, a wireless device, and a network node. Furthermore, a carrier medium arrangement is contemplated for carrying and / or storing a computer program product as described herein.

[0178] It will be apparent to those skilled in the art that various modifications and variations can be made in the substance and method of the invention, as well as in the structure of the invention, without departing from the scope or spirit of the invention.

[0179] The present invention has been described in conjunction with specific embodiments and examples, which are illustrative and not restrictive in all aspects. It will be appreciated by those skilled in the art that many different combinations of hardware, software and / or firmware will be suitable for practicing the present invention.

[0180] Furthermore, other embodiments of the present invention will become apparent to those skilled in the art upon consideration of the detailed description and practice of the invention disclosed herein. The detailed description and examples are to be considered as exemplary only. For this reason, it should be understood that inventive aspects lie in less than all features of a single aforementioned disclosed implementation or configuration. Therefore, the true scope and spirit of the present invention are indicated by the appended claims.

Claims

1. A method performed by a receiving data link layer protocol entity (520), comprising the following steps: delivering (S910) a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are re-delivered (S930) to a receiving higher layer transport protocol entity (510) a certain number of times.

2. The method according to claim 1, further comprising: The selected number of last delivered data packets are stored (S920).

3. The method according to claim 1 or 2, wherein The receiving data link layer protocol entity (520) delivers the plurality of data packets to the receiving higher-level transport protocol entity (510) in an out-of-order manner or in an ordered manner, wherein, for the ordered delivery, the receiving data link layer protocol entity (520) redelivers a selected number of last delivered packets if the receiving data link layer protocol entity (520) suppresses buffer forwarding during switching.

4. The method according to any one of claims 1 to 3, wherein The receiving data link layer protocol entity (520) is in unacknowledged mode UM or acknowledged mode AM.

5. The method according to any one of claims 1 to 4, wherein The receiving data link layer protocol entity (520) suppresses buffer forwarding during the handover process.

6. The method according to any one of claims 1 to 5, wherein The redelivery of the selected number of last delivered data packets is spread out in time.

7. The method according to any one of claims 1 to 6, wherein The receiving data link layer protocol entity (520) is a receiving packet data convergence protocol (PDCP) entity (920) for a radio access network RAN ​​layer.

8. The method of claim 7, wherein the receiving PDCP entity (920) redelivers a selected number of last delivered data packets during a PDCP re-establishment procedure, or upon completion of a handover procedure, or upon target cell establishment.

9. The method according to any one of claims 1 to 8, wherein The receiving high-level transport protocol entity (510) is a receiving transport protocol entity (510) for the RAN protocol layer, and the receiving transport protocol entity (510) optionally uses the Transmission Control Protocol TCP or the Quick UDP Internet Connection QUIC.

10. The method according to any one of claims 1 to 9, wherein For uplink transmissions, the receiving data link layer protocol entity (520) operates in a source network node (110, 304, 410) and redelivers a selected number of last delivered data packets when a handover procedure is triggered for the wireless device (112, 306, 420) or when a target network node (110, 304, 410) indicates a successful handover.

11. The method according to any one of claims 1 to 9, wherein For uplink transmissions, the receiving data link layer protocol entity (520) operates in a target network node (110, 304, 410) and redelivers a selected number of last delivered data packets after the target network node (110, 304, 410) receives the selected number of last delivered data packets from a source network node (110, 304, 410).

12. The method according to any one of claims 1 to 9, wherein For downlink transmissions, the receiving data link layer protocol entity (520) operates in the wireless device (112, 306, 420).

13. A receiving node (1400), comprising a processor (1410) into which a receiving data link layer protocol entity (520) is loadable, whereby execution of the receiving data link layer protocol entity (520) by the processor (1410) causes the receiving node (1400): delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); and During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

14. The receiving node (1400) of claim 13, wherein the receiving node (1400) is further caused to: The selected number of last delivered data packets are stored.

15. The receiving node (1400) according to claim 13 or 14, wherein The receiving node (1400) is caused to deliver the plurality of data packets to the receiving higher layer transport protocol entity (510) out of order or in an ordered manner, wherein, for the ordered delivery, the receiving node (1400) is caused to redeliver a selected number of last delivered packets if the receiving data link layer protocol entity suppresses buffer forwarding during the switching.

16. The receiving node (1400) according to any one of claims 13 to 15, wherein The receiving data link layer protocol entity (520) is in unacknowledged mode UM or acknowledged mode AM.

17. The receiving node (1400) according to any one of claims 13 to 16, wherein The receiving node (1400) is caused to suppress buffer forwarding during the handover process.

18. The receiving node (1400) according to any one of claims 13 to 17, wherein The receiving node (1400) is caused to spread the redelivery of the selected number of last delivered data packets over time.

19. The receiving node (1400) according to any one of claims 13 to 18, wherein the receiving data link layer protocol entity (520) is a receiving Packet Data Convergence Protocol (PDCP) entity (920) for a Radio Access Network (RAN) layer.

20. The receiving node (1400) of claim 19, wherein the receiving PDCP entity (920) is caused to redeliver a selected number of last delivered data packets during a PDCP re-establishment procedure, or upon completion of a handover procedure, or upon target cell establishment.

21. The receiving node (1400) according to any one of claims 13 to 20, wherein: The receiving high-level transport protocol entity (510) is a receiving transport protocol entity (910) for the RAN protocol layer, and the receiving transport protocol entity (910) optionally uses the Transmission Control Protocol TCP or the Quick UDP Internet Connection QUIC.

22. The receiving node (1400) according to any one of claims 13 to 21, wherein For uplink transmissions, the receiving data link layer protocol entity (520) operates in a source network node (110, 304, 410) and is caused to redeliver a selected number of last delivered data packets when a handover procedure is triggered for the wireless device (112, 306, 420) or when a target network node (110, 304, 410) indicates a successful handover.

23. The receiving node (1400) according to any one of claims 12 to 21, wherein For uplink transmissions, the receiving data link layer protocol entity (520) operates in a target network node (110, 304, 410) and redelivers a selected number of last delivered data packets after the target network node (110, 304, 410) receives the selected number of last delivered data packets from a source network node (110, 304, 410).

24. The receiving node (1400) according to any one of claims 13 to 21, wherein For downlink transmission, the receive higher layer transmission protocol entity (510) may be loaded into the processor and the receive data link layer protocol entity (520) may operate in the wireless device (112, 306, 420).

25. A receiving node (1400), comprising a receiving data link layer protocol entity (520), and configured to: delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); and A selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times during a handover process.

26. The receiving node (1400) of claim 25, wherein: The receiving node (1400) is configured to perform the method according to claims 2 to 12.

27. A computer program comprising program code for execution by a processor to operate a receiving data link layer protocol entity (520), whereby execution of the program code causes the receiving data link layer protocol entity (520) to perform operations comprising: delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

28. A computer program product comprising a non-transitory storage medium, the non-transitory storage medium comprising program code to be executed by a processing circuit to operate a receiving data link layer protocol entity, whereby execution of the program code causes the receiving data link layer protocol entity (520) to perform operations comprising: delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets are redelivered to the receiving higher layer transport protocol entity (510) a certain number of times.

29. A method implemented by a host (116, 200, 302) operating in a communication system, the communication system further comprising a network node (110, 304, 410) and a user equipment (UE) (112, 306, 420), the method comprising: Providing user data to the UE (112, 306, 420); as well as Initiating a transmission carrying the user data to the UE (112, 306, 420) via a cellular network including the network node (110, 304, 410), wherein the UE (112, 306, 420) performs the following operations to receive the user data from the host (116, 200, 302): delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

30. The method of claim 29, further comprising: At the host (116, 200, 302), a host application associated with a client application executing on the UE (112, 306, 420) is executed to receive the user data from the UE (112, 306, 420).

31. The method of claim 30, further comprising: sending, at the host (116, 200, 302), input data to the client application executing on the UE (112, 306, 420), the input data being provided by executing the host application, The user data is provided by the client application in response to the input data from the host application.

32. A host (116, 200, 302) configured to operate in a communication system to provide an over-the-top (OTT) service, the host (116, 200, 302) comprising: processing circuitry configured to provide user data; as well as A network interface configured to initiate transmission of user data to a cellular network for transmission to a user equipment (UE) (112, 306, 420), wherein the UE (112, 306, 420) includes a communication interface and processing circuitry, the communication interface and processing circuitry of the UE (112, 306, 420) being configured to perform the following operations to receive the user data from the host (116, 200, 302): delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

33. The host (116, 200, 302) of claim 32, wherein: The cellular network further comprises a network node (110, 304, 410) configured to communicate with the UE (112, 306, 420) to transmit the user data from the host (116, 200, 302) to the UE (112, 306, 420).

34. The host (116, 200, 302) of claim 32 or 33, wherein: The processing circuitry of the host (116, 200, 302) is configured to execute a host application to provide user data; and The host application is configured to interact with a client application executing on the UE (112, 306, 420), the client application being associated with the host application.

35. A method implemented by a host (116, 200, 302) configured to operate in a communication system, the communication system further comprising a network node (110, 304, 410) and a user equipment (UE) (112, 306, 420), the method comprising: At the host (116, 200, 302), reception of user data from the UE (112, 306, 420) is initiated, the user data originating from a transmission already received by the network node (110, 304, 410) from the UE (112, 306, 420), wherein the network node (110, 304, 410) performs the following operations to receive user data from the UE (112, 306, 420) for the host (116, 200, 302): delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

36. The method of claim 35, further comprising: At the network node (110, 304, 410), the received user data is sent to the host (116, 200, 302).

37. A host (116, 200, 302) configured to operate in a communication system to provide an over-the-top (OTT) service, the host (116, 200, 302) comprising: processing circuitry configured to initiate receipt of user data; as well as A network interface configured to receive the user data from a network node (110, 304, 410) in a cellular network, the network node (110, 304, 410) having a communication interface and processing circuitry, the processing circuitry of the network node (110, 304, 410) being configured to perform the following operations to receive the user data from the UE (112, 306, 420) for the host (116, 200, 302): delivering a plurality of data packets to a receiving higher layer transport protocol entity (510); as well as During the handover process, a selected number of last delivered data packets of the plurality of data packets are redelivered to the receiving higher layer transport protocol entity (510) a number of times.

38. The host (116, 200, 302) of claim 37, wherein: The processing circuit of the host (116, 200, 302) is configured to execute a host application to provide the user data; as well as The host application is configured to interact with a client application executing on the UE (112, 306, 420), the client application being associated with the host application.

39. The host (116, 200, 302) of claim 37 or 38, wherein the initiating receipt of user data comprises requesting the user data.

Images