Latency measurement technique

Abstract

A technique for latency measurement in radio access networks (500; 1111) is described. As to a method (300) performed by a network node (100; 900; 1112) in the radio access network (500; 1111), the method (300) comprises maintaining (302) a receiver model (102) of a radio device (200; 1191; 1192), wherein maintaining (302) the receiver model (102) comprises monitoring (303) a reception state (602) of a data packet (502) based on automatic repeat request, ARQ, feedback (504) received from the radio device (200; 1191; 1192); and determining (304), based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

Description

[0001] Telefonaktiebolaget LM Ericsson (publ)

[0002] P112614WO01

[0003] Latency Measurement Technique

[0004] Technical Field

[0005] The present disclosure relates to a technique for latency measurement in radio access networks. More specifically, and without limitation, methods and devices for determining latency and a radio device configured to enable latency determination are provided.

[0006] Background

[0007] In the field of radio communication, the Third Generation Partnership Project (3GPP) defines technical standards for fifth generation (5G) and the forthcoming sixth generation (6G) radio access technologies (RATs). These standards enhance network capabilities, enabling innovative solutions for high-speed data transfer, low-latency communication, and seamless mobility. Furthermore, the Wi-Fi Alliance is advancing RATs based on the IEEE 802.11 standard family, including IEEE 802.11ax for Wi-Fi 6 / 6E. Both contribute to an informed society and connected industry devices.

[0008] Use cases of these evolving RATs become more diverse, for example, in terms of latency requirements. This underscores the need for networks to be highly observable and steerable, so that the network fulfills the different latency requirements reliably and as power-efficiently as possible. While there are many promising concepts for network control, e.g., based on Al and cloud computing, the basis for this is the latency measurement.

[0009] However, accurately and efficiently measuring downlink packet latency in realtime remains a challenge in current systems. For example, conventional methods add to the signaling by timestamps in the downlink and frequent detailed measurement reports in the uplink.Telefonaktiebolaget LM Ericsson (publ)

[0010] P112614WO01

[0011] Summary

[0012] Accordingly, there is a need for a technique that provides dynamic downlink latency measurements without additional communication overhead.

[0013] As to a first method aspect, a method performed by a network node in a radio access network (RAN) is provided. The method comprises maintaining a receiver model of a radio device. Maintaining the receiver model comprises monitoring a reception state of a data packet based on hybrid automatic repeat request (HARQ) feedback received from the radio device. The method further comprises determining, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0014] By maintaining a receiver model that monitors the reception state of data packets based on HARQ feedback from the radio device, embodiments of the network node can accurately determine when each data packet is delivered by the radio device without requiring timestamping or additional signaling. Determining the latency as the time difference between when the data packet becomes available for transmission and when it is delivered allows for precise measurement of downlink latency. This approach leverages existing HARQ feedback mechanisms, thereby eliminating the need for extra communication overhead while ensuring accurate latency measurements necessary for time-critical applications.

[0015] The first method aspect may be implemented alone or in combination with any one of the embodiments, particularly corresponding features and steps disclosed in the context of below second method aspect.

[0016] As to a second method aspect, a method performed by a radio device connected or connectable to a radio access network (RAN) is provided. The method comprises receiving a configuration message from a network node of the radio access network (RAN). The configuration message instructs the radio device to use a cyclic redundancy check (CRC) protected uplink channel for hybrid automatic repeat request (HARQ) feedback that enables the network node to maintain a receiver model of the radio device including a reception state of the data packet within the receiver model. The method further comprises transmitting the HARQ feedbackTelefonaktiebolaget LM Ericsson (publ)

[0017] P112614WO01

[0018] using the CRC-protected uplink channel to the network node responsive to a data packet received from the network node. The HARQ feedback enables the network node to determine, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0019] By configuring a radio device for a reliable HARQ feedback, embodiments of the radio device can provide a feedback that enable the RAN to determine downlink latency without the need for further signaling overhead.

[0020] By configuring the radio device to use a CRC-protected uplink channel for HARQ feedback, the reliability of the feedback can be enhanced, ensuring accurate modeling of the reception state at the network node. When the radio device transmits HARQ feedback using the CRC-protected channel in response to receiving data packets, the network node can reliably determine the reception status of each packet. This reliable HARQ feedback allows the network node to accurately maintain the receiver model and determine the latency of data packets without additional overhead. Consequently, the method enables precise latency measurements essential for supporting time-critical services, while utilizing existing communication mechanisms effectively.

[0021] The second method aspect may be implemented alone or in combination with any one of the embodiments. The second method aspect may further comprise any feature and / or any step disclosed in the context of the first method aspect, or the feature and the step corresponding thereto, e.g., a receiver counterpart to a transmitter feature or step.

[0022] The technique may be applied in the context of 3GPP New Radio (NR) or beyond, and Wi-Fi.

[0023] For example, the technique may be implemented in accordance with a 3GPP technical specification or by changing the specification, e.g. in 3GPP Releases 19 to 21. The HARQ feedback may be configured in the first method aspect and performed in the second method aspect based on 3GPP TS 38.321, e.g. version 18.4.0. The reordering of the data packet may be modeled at the network nodeTelefonaktiebolaget LM Ericsson (publ)

[0024] P112614WO01

[0025] and performed at the radio device according to 3GPP TS 38.322, e.g., version 18.2.0.

[0026] In a Wi-Fi implementation, the feedback may be based on the Automatic Repeat Request (ARQ) for error control. Reordering of data packets may be represented by the receiver model according to Clause 10 of the IEEE 802.11ax-2021 standard, which details the Medium Access Control (MAC) sublayer.

[0027] The radio device and the network node of the RAN may be wirelessly connected in an uplink (UL) and / or a downlink (DL) through a Uu interface.

[0028] The radio device and / or the RAN may form, or may be part of, a radio network, e.g., according to the Third Generation Partnership Project (3GPP) or according to the standard family IEEE 802.11 (Wi-Fi). The first method aspect, the second method aspect and second method aspect may be performed by one or more embodiments of the RAN or the network node (e.g., a base station) and the radio device, respectively.

[0029] The RAN may comprise one or more network node (e.g., base stations), e.g., performing the first method aspect. Alternatively or in addition, the radio network may be a vehicular, ad hoc and / or mesh network comprising two or more radio devices, e.g., acting as the remote radio device and / or the relay radio device and / or the further remote radio device.

[0030] Any of the radio devices may be a 3GPP user equipment (UE) or a Wi-Fi station (STA). The radio device may be a mobile or portable station, a device for machinetype communication (MTC), a device for narrowband Internet of Things (NB-loT), Industrial loT (I loT), or a combination thereof. Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle.

[0031] Examples for the portable station include a laptop computer and a television set. Examples for the MTC device or the NB-loT or I loT device include robots, sensors and / or actuators, e.g., in manufacturing, automotive communication and home automation. The MTC device or the NB-loT or I loT device may be implemented in a manufacturing plant, household appliances and consumer electronics.

[0032] Whenever referring to the RAN, the RAN may be implemented by one or more network nodes, e.g. base stations. Each base station may encompass any stationTelefonaktiebolaget LM Ericsson (publ)

[0033] P112614WO01

[0034] that is configured to provide radio access to any of the radio devices. The base stations may also be referred to as cel I, transmission and reception point (TRP), radio access node or access point (AP). The base station and / or the relay radio device may provide a data link to a host computer providing the user data to the remote radio device or gathering user data from the remote radio device.

[0035] Examples for the base stations may include a 3G base station or Node B, 4G base station or eNodeB, a 5G base station or gNodeB, a Wi-Fi AP and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave).

[0036] The RAN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE), 3GPP New Radio (NR), and / or the forthcoming sixth generation (6G) standards.

[0037] Any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, and / or a Radio Resource Control (RRC) layer of a protocol stack for the radio communication.

[0038] Herein, referring to a protocol of a layer may also refer to the corresponding layer in the protocol stack. Vice versa, referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method.

[0039] As to another aspect, a computer program product is provided. The computer program product comprises program code portions for performing any one of the steps of the first and / or second method aspect disclosed herein when the computer program product is executed by one or more computing devices. The computer program product may be stored on a computer-readable recording medium. The computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and / or the host computer.

[0040] Alternatively, or in addition, the method may be encoded in a Field-Programmable Gate Array (FPGA) and / or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.Telefonaktiebolaget LM Ericsson (publ)

[0041] P112614WO01

[0042] As to a first device aspect, a device for determining latency is provided. The device may be configured to perform any one of the steps of the first method aspect. As to a further first device aspect, a device for determining latency is provided, which comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the device is operative to perform any one of the steps of the first method aspect.

[0043] As to a second device aspect, a device configured to enable latency determination is provided. The device may be configured to perform any one of the steps of the second method aspect. As to a further second device aspect, a device configured to enable latency determination is provided, which comprises processing circuitry (e.g., at least one processor and a memory). Said memory comprises instructions executable by said at least one processor whereby the device is operative to perform any one of the steps of the second method aspect.

[0044] As to a still further aspect a communication system including a host computer is provided. The host computer comprises a processing circuitry configured to provide user data, e.g., included in the data packet. The host computer further comprises a communication interface configured to forward the user data to a cellular network (e.g., the RAN and / or the network node) for transmission to the radio device (e.g., a UE). A processing circuitry of the cellular network is configured to execute any one of the steps of the first method aspect. The UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the second method aspect.

[0045] The communication system may further include the radio device (e.g., a UE).

[0046] Alternatively, or in addition, the cellular network may further include one or more embodiments of the network node (e.g., base stations) configured for radio communication with the UE and / or to provide a data link between the UE and the host computer using the first and / or second method aspects.

[0047] The processing circuitry of the host computer may be configured to execute a host application, thereby providing the user data and / or any host computer functionality described herein. Alternatively, or in addition, the processing circuitry of the UE may be configured to execute a client application associated with the host application.Telefonaktiebolaget LM Ericsson (publ)

[0048] P112614WO01

[0049] Any one of the devices, the radio device, the UE, the network node, the base station, the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa. Particularly, anyone of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect.

[0050] Brief Description of the Drawings

[0051] Further details of embodiments of the technique are described with reference to the enclosed drawings, wherein:

[0052] Fig. 1 shows a schematic block diagram of an embodiment of a device for latency determination;

[0053] Fig. 2 shows a schematic block diagram of an embodiment of a device configured to enable latency determination;

[0054] Fig. 3 shows a flowchart for a method of detecting latency, which method may be implementable by the device of Fig. 1;

[0055] Fig. 4 shows a flowchart for a method of enabling latency determination, which method may be implementable by the device of Fig. 2;

[0056] Fig. 5A schematically illustrates a first example of a radio network comprising embodiments of the devices of Figs. 1 and 2 performing the methods of Figs. 3 and 4, respectively;

[0057] Fig. 5B schematically illustrates a second example of a radio network comprising embodiments of the devices of Figs. 1 and 2 performing the methods of Figs. 3 and 4, respectively;

[0058] Figs. 6A to 6D schematically illustrate a sequence of signaling and processing diagrams resulting from embodiments of the devices of Figs. 1 and 2 performing the methods of Figs. 3 and 4, respectively, in radio

[0059] communication;Telefonaktiebolaget LM Ericsson (publ)

[0060] P112614WO01

[0061] Fig. 7 schematically a latency determined based on the embodiments of Figs. 6A to 6D;

[0062] Fig. 8 schematically illustrates protocol stacks of embodiments of the devices of Figs. 1 and 2, as well as their signing when performing embodiments of the methods of Figs. 3 and 4, respectively;

[0063] Fig. 9 shows a schematic block diagram of a network node embodying the device of Fig. 1;

[0064] Fig. 10 shows a schematic block diagram of a radio device embodying the device of Fig. 2; and

[0065] Fig. 11 schematically illustrates an example telecommunication network connected via an intermediate network to a host computer.

[0066] Detailed Description

[0067] In the following description, for purposes of explanation and not limitation, specific details are set forth, such as a specific network environment in order to provide a thorough understanding of the technique disclosed herein. It will be apparent to one skilled in the art that the technique may be practiced in other embodiments that depart from these specific details. Moreover, while the following embodiments are primarily described for a New Radio (NR) or 5G implementation, it is readily apparent that the technique described herein may also be implemented for any other radio communication technique, including a Wireless Local Area Network (WLAN) implementation according to the standard family IEEE 802.11, 3GPP LTE (e.g., LTE-Advanced or a related radio access technique such as MulteFire), for Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4.

[0068] Moreover, those skilled in the art will appreciate that the functions, steps, units and modules explained herein may be implemented using software functioning inTelefonaktiebolaget LM Ericsson (publ)

[0069] P112614WO01

[0070] conjunction with a programmed microprocessor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP) or a general-purpose computer, e.g., including an Advanced RISC Machine (ARM). It will also be appreciated that, while the following embodiments are primarily described in context with methods and devices, embodiments may also include computer program products as well as systems comprising at least one computer processor and memory coupled to the at least one processor, wherein the memory is encoded with one or more programs that may perform the functions and steps or implement the units and modules disclosed herein.

[0071] As to a first method aspect, a method performed by a network node in a radio access network is provided. The method comprises maintaining a receiver model of a radio device. Maintaining the receiver model comprises monitoring a reception state of a data packet based on automatic repeat request (ARQ) feedback received from the radio device. The method further comprises determining, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0072] Embodiments of the method enable the network node to accurately determine the downlink (DL) latency of data packets without the need for additional communication overhead such as timestamps or reporting of the time of data packet delivery. By maintaining the reception state of data packets based on their (H)ARQ feedback within the receiver model, the network node can track the reception state of data packets at the radio device and determine their latency values, thus enhancing observability of network performance for time-critical services.

[0073] In any aspect, the ARQ feedback may be a hybrid ARQ (HARQ) feedback.

[0074] The method may be such that the data packet may be a protocol data unit (PDU) of a packet data convergence protocol (PDCP), or a PDU of a service data adaptation protocol (SDAP). Alternatively or additionally, the delivery time of the data packet may be the time the data packet is delivered by a PDCP layer or an SDAP layer of the radio device according to the receiver model.Telefonaktiebolaget LM Ericsson (publ)

[0075] P112614WO01

[0076] For example, the data packet may be a protocol data unit (PDU) of a packet data convergence protocol (PDCP), or a PDU of a service data adaptation protocol (SDAP).

[0077] Alternatively or additionally, the delivery time of the data packet may be the time the data packet is delivered by a PDCP layer or an SDAP layer of the radio device according to the receiver model.

[0078] The latency may be determined per SDAP PDU or per PDCP PDU.

[0079] The receiver model may comprise a monitored state of reception per transport block based on the ARQ feedback for a combination of an ARQ process identifier (PID) and a sequence number (SN) associated with the data packet.

[0080] The SN may be a sequence number of a Radio Link Control (RLC) layer.

[0081] By monitoring the reception state per transport block using ARQ process identifiers and sequence numbers, the network node can precisely track which transport blocks have been successfully received by the radio device. This granularity improves the accuracy of the receiver model and, consequently, the latency determination.

[0082] Maintaining the receiver model may comprise maintaining a mapping between data packets and a combination of a ARQ process identifier (PID) for each transport block and a sequence number (SN) associated with the respective one of the data packets. By maintaining the mapping between data packets and their associated ARQ processes, the network node can accurately associate received ARQ feedback with the corresponding data packets. This mapping may be used for determining the reception state and / or the delivery state of each data packet and determining its latency.

[0083] Maintaining the receiver model may further comprise deriving the reception state of the data packet based on the monitored reception state of each transport block associated with the data packet.

[0084] By deriving the reception state of each data packet from the reception states of its associated one or more transport blocks, the network node can determine when an entire data packet has been successfully received at the radio device. To this end, maintaining the receiver model may comprise a concatenation and / or aTelefonaktiebolaget LM Ericsson (publ)

[0085] P112614WO01

[0086] segmentation which may occur for the data packet at the PDCP layer or the RLC layer.

[0087] Maintaining the receiver model may further comprise maintaining a mapping between the PDCP PDU (e.g., being the data packet or comprising the data packet in its PDCP service data unit, PDCP SDU) and one or more RLC PDUs or one or more MAC PDUs (e.g., corresponding to the one or more RLC PDUs) or one or more transport blocks (e.g., corresponding to the one or more MAC PDUs or the one or more RLC PDUs) that comprise the PDCP PDU.

[0088] Thus, maintaining the receiver model allows the network node to correctly determine the latency of the data packet by reproducing the radio device's decision logic at the network node, optionally further depending on the successful reception of further data packets that are earlier than the data packet according to the SN associated with the data packet.

[0089] Maintaining the receiver model may comprise maintaining radio schedules of at least one of the transport blocks and the ARQ feedback.

[0090] Schedules for the radio transmission of the MAC PDUs (or the corresponding transport blocks) in the downlink and / or the ARQ feedback in the uplink may be maintained (e.g., tracked by the receiver model) at the network node. Accordingly, the network node knows (e.g., retroactively upon receiving the ARQ feedback) when (i.e., the time instances) the MAC PDUs are successfully received.

[0091] Furthermore, the network node may derive when the PDCP PDUs are successfully received (i.e., delivered, e.g. after reassembly of all received MAC PDUs that correspond to PDCP PDU).

[0092] Determining the latency may comprise determining the time the data packet is delivered by the radio device based on a transmission time of a last transport block required for the delivering of the data packet.

[0093] Setting the reception time to the transmission time of the last required transport block may (e.g., retroactively upon receiving the positive acknowledgment in the ARQ feedback) provide an excellent estimate of when the radio device completes reception of the data packet. This approach simplifies latency calculation by using transmission times known at the network node.Telefonaktiebolaget LM Ericsson (publ)

[0094] P112614WO01

[0095] Determining the latency may further comprise accounting for a transmission delay between the transmission time of the last transport block and the delivery time of the data packet at the radio device, wherein the delay may comprise at least one of a processing time for decoding the transport block at a physical layer of the radio device and / or for reassembling the transport blocks associated with the data packet at a radio link control (RLC) layer of the radio device, and a radio propagation delay of a radio propagation of the transport block to the radio device.

[0096] For example, the delay may comprise a processing time for decoding the transport block at a physical layer of the radio device and / or for reassembling the transport blocks associated with the data packet at a radio link control (RLC) layer of the radio device. Alternatively or additionally, the delay may comprise a radio propagation delay of a radio propagation of the transport block to the radio device.

[0097] Accounting for processing delays such as decoding time and propagation delay refines the latency measurement, can make it more accurate by considering additional time required for the radio device to process and receive the data packet after transmission.

[0098] The data packet may be delivered by the radio device according to the receiver model to layers higher than a radio protocol stack for radio access to the radio access network.

[0099] Maintaining the receiver model may comprise monitoring the reception state of each data packet in a sequence of data packets based on the ARQ. feedback received from the radio device.

[0100] In-sequence delivery may be configured for the radio device or a radio bearer used by the data packet.

[0101] The receiver model may comprise a reordering delay of the delivering of the data packet at the radio device after receiving the data packet at the radio device until an earlier data packet has been received and delivered according to the insequence delivery.Telefonaktiebolaget LM Ericsson (publ)

[0102] P112614WO01

[0103] The receiver model may comprise a reordering delay of the delivering of the data packet at the radio device until a reordering timer expires while waiting for receiving an earlier data packet not received and delivered according to the insequence delivery.

[0104] The receiver model may comprise a delay for buffering the data packet at the radio device after correctly (i.e., successfully) receiving the data packet until either a reordering timer expires or all previous data packets are also correctly received. Thus the time the data packet is delivered by the radio device (which is the end time considered for the determining of the latency) is later than (i.e., delayed after) a time the data packet is received at the radio device as receiver.

[0105] The reception state of the data packet may refer to a state of reception of the data packet at the radio device, which may differ from a state of delivery of the data packet, i.e., the delivering of the data packet by the radio device. The maintaining of the receiver model may further comprise inferring the delivery state of the data packet based on the reception state of the data packet and earlier data packets according to the SN.

[0106] The receiver model may comprise receiver buffering (e.g., at the RLC layer or the PDCP layer), e.g., due to the configured in-sequence delivery. The in-sequence delivery may necessitate to wait for successful reception of all earlier data packets (e.g., PDCP PDUs) or alternative the expiry of the reordering timer.

[0107] Maintaining the receiver model may comprise a reordering procedure of the radio device to infer a reordering delay of data packet reordering by the radio device, optionally at a packet data convergence protocol (PDCP) layer of the radio device, wherein the reordering delay may add to the delivery time of the data packet. Alternatively or additionally, determining the latency may comprise inferring a reordering delay for the data packet based on the reception state of earlier data packets delivered in sequence.

[0108] For example, maintaining the receiver model may comprise a reordering procedure of the radio device to infer a reordering delay of data packet reordering by the radio device, optionally at a packet data convergence protocol (PDCP) layer of the radio device, wherein the reordering delay may add to the delivery time of the data packet. Alternatively or additionally, determining the latency mayTelefonaktiebolaget LM Ericsson (publ)

[0109] P112614WO01

[0110] comprise inferring a reordering delay for the data packet based on the reception state of earlier data packets delivered in sequence.

[0111] By replicating the radio device's reordering procedure, optionally including any reordering timers, the network node can estimate additional delays caused by out-of-order delivery and reordering at the radio device, further enhancing the accuracy of the latency determination.

[0112] The time the data packet becomes available for transmission at the network node may be a time the data packet is provided to a service data adaptation protocol (SDAP) layer or to a packet data convergence protocol (PDCP) layer, or is provided by an SDAP layer or by a PDCP layer, or a time the data packet becomes queued at a radio link control (RLC) layer of the network node. For example, the time the data packet becomes available for transmission at the network node may be a time the data packet is provided to a service data adaptation protocol (SDAP) layer. For example, the time the data packet becomes available for transmission at the network node may be a time the data packet is provided to a packet data convergence protocol (PDCP) layer. For example, the time the data packet becomes available for transmission at the network node may be a time the data packet is provided by an SDAP layer. For example, the time the data packet becomes available for transmission at the network node may be a time the data packet is provided by a PDCP layer. For example, the time the data packet becomes available for transmission at the network node may be a time the data packet becomes queued at a radio link control (RLC) layer of the network node.

[0113] Defining the starting point of latency measurement at the PDCP or RLC layer can provide a clear and consistent reference time within the network node's protocol stack, facilitating precise latency calculation at the network node and / or according to the receiver model.

[0114] The ARQ feedback may be received from the radio device on a cyclic redundancy check (CRC) protected uplink channel.

[0115] Receiving ARQ feedback on a CRC-protected uplink channel ensures the reliability of the feedback. This reliability is critical to the accuracy of the receiver model, as it prevents false acknowledgements that could otherwise lead to incorrect latency calculations.Telefonaktiebolaget LM Ericsson (publ)

[0116] P112614WO01

[0117] The cyclic redundancy check (CRC) protected uplink channel may be a scheduled uplink shared channel.

[0118] Using a scheduled uplink shared channel (e.g., PUSCH) for ARQ feedback allows the network node to know the exact timing of transmissions of the ARQ feedback for updating the status (e.g., the reception state and / or the delivery state) of the receiver model.

[0119] The method may further comprise at least one of scheduling the radio device depending on the determined latency, and reconfiguring the radio device depending on the determined latency.

[0120] For example, the method may further comprise scheduling the radio device depending on the determined latency. Alternatively or additionally, the method may further comprise reconfiguring the radio device depending on the determined latency.

[0121] The network node may use the determined latency for scheduling the radio device. The network node may schedule the radio device responsive to the determined latency. Alternatively or in addition, the method may comprise a closed control loop, wherein the determined latency (e.g., determined in real-time) is used for future (e.g., subsequent) scheduling, e.g., for scheduling assignments in the downlink from the network node to the radio device. For example, the network node may subtract the determined latency from a packet delay budget (PDB) when scheduling a further data packet (e.g., one or more transport blocks for the further data packet). Accordingly, the further data packet may be delivered by radio device within its PDB.

[0122] As to a second method aspect, a method performed by a radio device connected or connectable to a radio access network (RAN) is provided. The method comprises receiving a configuration message from a network node of the RAN. The configuration message instructs the radio device to use a cyclic redundancy check (CRC) protected uplink channel for an automatic repeat request (ARQ) feedback that enables the network node to maintain a receiver model of the radio device including a reception state of the data packet within the receiver model. The method further comprises, responsive to a data packet received from the network node, transmitting the ARQ feedback using the CRC-protected uplink channel to the network node. The ARQ feedback enables the network node to determine,Telefonaktiebolaget LM Ericsson (publ)

[0123] P112614WO01

[0124] based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0125] The method may further comprise the features and steps of any one of the embodiments of the first aspect, or a feature or step at the radio device corresponding to the features and steps at the network node.

[0126] As to a first device aspect, a network node comprising memory operable to store instructions and processing circuitry operable to execute the instructions is provided. The network node is operable to maintain a receiver model of a radio device. Maintaining the receiver model comprises monitoring a reception state of a data packet based on automatic repeat request (ARQ) feedback received from the radio device. The network node is further operable to determine, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0127] The network node may further be operable to perform any one of the steps of any one of the embodiments of the first method aspect.

[0128] As to a variant of the first device aspect, a network node of a radio access network is provided. The network node is configured to maintain a receiver model of a radio device. Maintaining the receiver model comprises monitoring a reception state of a data packet based on automatic repeat request (ARQ) feedback received from the radio device. The network node is further configured to determine, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0129] As to a second device aspect, a radio device comprising memory operable to store instructions and processing circuitry operable to execute the instructions is provided. The radio device is operable to receive a configuration message from a network node of a radio access network (RAN). The configuration messageTelefonaktiebolaget LM Ericsson (publ)

[0130] P112614WO01

[0131] instructs the radio device to use a cyclic redundancy check (CRC) protected uplink channel for an automatic repeat request (ARQ) feedback that enables the network node to maintain a receiver model of the radio device including a reception state of the data packet within the receiver model. The radio device is further operable to, responsive to a data packet received from the network node, transmit the ARQ feedback using the CRC-protected uplink channel to the network node. The ARQ feedback enables the network node to determine, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0132] The radio device may further be operable to perform the steps of any one of the embodiments of the second method aspect.

[0133] As to a variant of the second device aspect, a radio device is provided. The radio device is configured to receive a configuration message from a network node of a radio access network (RAN). The configuration message instructs the radio device to use a cyclic redundancy check (CRC) protected uplink channel for an automatic repeat request (ARQ) feedback that enables the network node to maintain a receiver model of the radio device including a reception state of the data packet within the receiver model. The radio device is further configured to, responsive to a data packet received from the network node, transmit the ARQ feedback using the CRC-protected uplink channel to the network node. The ARQ feedback enables the network node to determine, based on the receiver model, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0134] As to a further device aspect, a communication system including at least one of the radio device, the network node, and a host computer is provided. The host computer comprises processing circuitry configured to provide user data. The host computer further comprises a communication interface configured to forward user data to a cellular or ad hoc radio network for transmission to a radio device. The radio network comprises a radio interface and processing circuitry, and the processing circuitry is configured to execute the steps of any one of the first method aspect.Telefonaktiebolaget LM Ericsson (publ)

[0135] P112614WO01

[0136] Fig. 1 schematically illustrates a block diagram of an embodiment of a device for determining latency of one or more data packets according to the first aspect or embodiment 1. The device is generically referred to by reference sign 100.

[0137] The device 100 comprises a receiver model module 102 that maintains a receiver model of a radio device based on hybrid automatic repeat request (HARQ) feedback received from a radio device.

[0138] The device 100 further comprises a latency determination module 104 that determines a latency of a data packet as a time difference between a time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the radio device according to the receiver model.

[0139] Any of the modules of the device 100 may be implemented by units configured to provide the corresponding functionality.

[0140] The device 100 may also be referred to as, or may be embodied by, the network node (or briefly: NN). The network node 100 and the radio device may be in direct radio communication, e.g., at least for receiving HARQ feedback from the radio device and maintaining the receiver model based on the feedback. The radio device may be embodied by the below-mentioned device 200.

[0141] Fig. 2 schematically illustrates a block diagram of an embodiment of a device configured to enable latency determination, e.g. according to the second aspect or embodiment 18. The device is generically referred to by reference sign 200.

[0142] The device 200 comprises a configuration reception module 202 that receives a configuration message from a network node of a radio access network (RAN). The configuration message instructs the device 200 to use a cyclic redundancy check (CRC) protected uplink channel for a hybrid automatic repeat request (HARQ) feedback.

[0143] The device 200 further comprises a feedback transmission module 204 that transmits the HARQ feedback using the CRC-protected uplink channel to the network node. The HARQ feedback enables the network node to determine, based on a receiver model, a latency of a data packet as a time difference between aTelefonaktiebolaget LM Ericsson (publ)

[0144] P112614WO01

[0145] time the data packet becomes available for transmission at the network node and a time the data packet is delivered by the device 200 according to the receiver model.

[0146] Any of the modules of the device 200 may be implemented by units configured to provide the corresponding functionality.

[0147] The device 200 may also be referred to as, or may be embodied by, the radio device (or briefly: UE). The radio device 200 and the network node 100 may be in direct radio communication, e.g., at least for receiving the configuration message from the network node 100 and transmitting the HARQ feedback 504 to the network node. The network node may be embodied by the above-mentioned device 100.

[0148] Fig. 3 shows an example flowchart for a method 300 performed by a network node 100 in a radio access network (RAN).

[0149] A step 302 of the method 300 maintains a receiver model 102 of a radio device 200. The maintaining of the receiver model 102 comprises monitoring a reception state of a data packet based on hybrid automatic repeat request (HARQ) feedback received from the radio device 200.

[0150] In a step 304 of the method 300, a latency of the data packet is determined based on the receiver model 102. The latency is determined as a time difference between a time the data packet becomes available for transmission at the network node 100 and a time the data packet is delivered by the radio device 200 according to the receiver model 102.

[0151] The method 300 may be performed by the network node 100. For example, the modules 102 and 104 may perform the steps 302 and 304, respectively.

[0152] Fig.4 shows an example flowchart for a method 400 performed by a radio device 200 connected or connectable to a radio access network (RAN).

[0153] In a step 402 of the method 400, the radio device 200 receives a configuration message from a (e.g., serving) network node 100 of the RAN. The configuration message instructs the radio device 200 to use a cyclic redundancy check (CRC)Telefonaktiebolaget LM Ericsson (publ)

[0154] P112614WO01

[0155] protected uplink channel for a hybrid automatic repeat request (HARQ) feedback. This feedback enables the network node 100 to maintain a receiver model 102 of the radio device 200, including a reception state of a data packet within the receiver model 102.

[0156] A step 404 of the method 400 is responsive to the data packet received from the network node 100. The radio device 200 transmits the HARQ feedback using the CRC-protected uplink channel to the network node 100 in the step 404. The HARQ feedback enables the network node 100 to determine, based on the receiver model 102, a latency of the data packet as a time difference between a time the data packet becomes available for transmission at the network node 100 and a time the data packet is delivered by the radio device 200 according to the receiver model 102.

[0157] In any aspect, the technique may be applied to uplink (UL), downlink (DL) or direct communications between radio devices, e.g., device-to-device (D2D) communications or sidelink (SL) communications.

[0158] Each of the device 100 and device 200 may be a radio device or a network node (e.g., a base station). Herein, any radio device may be a mobile or portable station and / or any radio device wirelessly connectable to a base station or the RAN, or to another radio device. For example, the radio device may be a user equipment (UE), a device for machine-type communication (MTC) or a device for (e.g., Industrial or narrowband) Internet of Things (loT). Moreover, two or more radio devices may be configured to wirelessly connect to each other, e.g., in an ad hoc radio network or via a 3GPP SL connection. Furthermore, any base station may be a station providing radio access, may be part of the RAN and / or may be a node connected to the RAN for controlling the radio access. For example, the base station may be an access point, for example a Wi-Fi access point.

[0159] Fig. 5A shows a first example of a radio access network 500 comprising at least one embodiment of the network node 100 serving at least one embodiment of the radio device 100 in at least one cell 101 of the network node 100.

[0160] In Fig. 5A, the RAN 500 is depicted, indicating interaction between various components involved in latency determination. A network node 100 serves as a central component, facilitating communication within the cell 101 of the RAN 500.Telefonaktiebolaget LM Ericsson (publ)

[0161] P112614WO01

[0162] The network node 100 is responsible for transmitting a data packet 502 and receiving HARQ feedback 504 thereon, as part of the latency measurement method 300.

[0163] A radio device 200, e.g. a user equipment (UE), radio-communicates with the network node 100 according to the method 400. The radio device receives data packets 502 from the network node 100 and provides HARQ feedback 504 through a CRC-protected uplink channel. This feedback enables the network node 100 to maintain a receiver model 102 and determine a latency for said data packet accurately without additional signaling overhead.

[0164] In Fig. 5A, the radio device 200 is depicted in direct communication with the network node 100. The network node transmits data packets 502 to the radio device and receives HARQ feedback 504, allowing the network node to assess the reception state of each data packet and calculate the corresponding latency.

[0165] Fig. 5B includes an assisting radio device 200, which can facilitate communication between a target radio device and the network node 100. In this scenario, data packets 502 and HARQ feedback 504 are relayed through the assisting radio device, enhancing coverage and reliability. This arrangement ensures that even when direct communication is challenging or the radio device 200 is outside of the cell 101 of the network node 100, latency determination remains efficient and accurate.

[0166] Figs. 6A to 6D illustrates a sequence of steps according to embodiments of the interacting methods 300 and 400.

[0167] A radio device 200 interacts with a network node 100 to facilitate accurate downlink latency measurement. The network node 100 incorporates a receiver model 102, integral to the process, by which the network node 100 tracks data packet reception and delivery states at the radio device 200. The radio device 200 utilizes hybrid automatic repeat request (HARQ) feedback 504 to communicate its reception state to the network node 100, enabling precise latency determination 304.

[0168] A sequence begins in Fig. 6A, when a data packet 502 is transmitted from the network node 100 to the radio device 200. The data packet 502 is split intoTelefonaktiebolaget LM Ericsson (publ)

[0169] P112614WO01

[0170] transport blocks (TBs) 503 identified by process IDs (PID) and sequence numbers (SN). The radio device 200 attempts to decode these TBs 503, with the decoding process monitored by the network node's receiver model 102.

[0171] If the cyclic redundancy check (CRC) at the radio device 200 fails, as illustrated by the crossed box within the radio device 100 of Fig. 6A, a HARQ NACK feedback 504 (for negative acknowledgment) is generated and sent back to the network node. Prior to reception of the HARQ feedback 504, the monitoring 303 network node 100 does not know the state 603 of reception for said TB 503.

[0172] Fig. 6B shows the continuation of this process, where the network node 100 receives the NACK feedback 504, indicating the TB 503 was not correctly received. It is at that time that the TB reception state 603 is set at the receiver model 102 of the network node 100. While this update is after the failure at the radio device 200, the network node 100 can unambiguously associate the transmission time of the TB 503. So the timing is also accurately tracked by the receiver model 102.

[0173] The network node 100 retransmits (optionally using a different redundancy version) the TB 503 with the same PID and SN to enable successful reception. The receiver model 102 monitors 303 this activity, updating the reception state 603 to track retransmissions.

[0174] In Fig. 6C, upon receiving a retransmitted transport block 503, the radio device 200 successfully decodes it. This successful decoding is confirmed by a CRC pass, and an ACK HARQ feedback 504 is sent to the network node 100. The network node 100 updates the TB reception state 603 according to the successful reception in the receiver model 102 according to the monitoring step 303 to reflect that the TB 503 (not yet the complete data packet 504) has been correctly received.

[0175] Fig. 6D concludes the sequence with the successful assembly of the data packet 502 at the radio device 200. The network node 100, upon receiving the ACK feedback 504 for the last TB 503 of the data packet 502, updates 303' the reception state 602 at the receiver model 102 to indicate the data packet 502 has been fully reassembled. This allows the network node to accurately calculate the downlink latency, considering both the transmission times and, potentially, any reordering delays in case there were data packets to be reassembled and delivered earlier in the sequence defined by the SNs of data packets.Telefonaktiebolaget LM Ericsson (publ)

[0176] P112614WO01

[0177] Thus, the reception model 102 at the network node 100, updated by the HARQ feedback from the radio device 200 (preferably with reliability enhanced by using CRC-protected channels) facilitates precise latency determination without additional signaling overhead.

[0178] Fig. 7 illustrates the step 304 of determining downlink latency 700 according to an embodiment of the method 300 in a radio access network (RAN).

[0179] The Fig. 7 may be a result of the methods 400 and 300 performed by the embodiments of the radio device 200 and the network node 100, respectively, according to Figs. 6A to 6D.

[0180] The network node 100 and the radio device 200 interact through a series of steps to achieve precise latency measurement without additional signaling overhead. The method begins with the transmission of a data packet 502 from the network node 100 to the radio device 200, which may be divided into transport blocks 503 identified by HARQ process identifiers (PID) and sequence numbers (SN).

[0181] The network node 100 maintains a receiver model 102 that monitors 303 the reception state of each transport block (TB). The reception state of the data packet 502 is derived from the reception state of each transport block (TB) carrying a portion of the data packet 502. In case of in-sequence delivery, the delivery state of the data packet 502 may significantly deviate from the reception state of the data packet 502 due to a reordering delay, which is inferred from the reception state of all data packets that are earlier than the data packet 502 according to their SN.

[0182] When the first transport block (PID 1, SN 1) is sent, the radio device 200 attempts decoding, resulting in a CRC failure. This failure triggers a HARQ negative acknowledgment (NACK) feedback 504 sent back to the network node 100. The NACK is part of the control plane signaling, ensuring the network node 100 is aware of the decoding failure.

[0183] Upon receiving the NACK, the network node 100 retransmits the TB 503, optionally with a different redundancy version, while the receiver model 102 updates the state to reflect the ongoing activity. This monitoring 303 ensures thatTelefonaktiebolaget LM Ericsson (publ)

[0184] P112614WO01

[0185] retransmissions are tracked and associated with the correct data packet 502, maintaining a record of transmission events.

[0186] When the radio device 200 successfully decodes the retransmitted TB 503, it sends a HARQ. acknowledgment (ACK) feedback 504 to the network node 100. This feedback enables the network node 100 to update the receiver model 102, confirming successful reception of the TB 503. The network node 100 uses this information to determine 304 the latency by considering the transmission time 706 of the last required transport block.

[0187] Optionally, the process includes accounting for additional delays, such as processing time 708 for decoding and / or reordering at the radio device 200. These processing delays refine the latency measurement, providing a comprehensive view of the time required for the data packet 502 to be fully reassembled and delivered (e.g. by the PDCP layer at reference sign 804a, or by the SDAP at reference sign 804b in Fig. 8) by the radio device 200. Hence, the embodiments enable precise latency determination, e.g. facilitating dependable communication for time-critical services without incurring extra signaling costs.

[0188] A variant of any embodiment may rely on existing feedback 504, e.g. a 3GPP or IEEE 802.11 (radio) ARQ. protocol for an embedded latency measurement. The technique may be applied to 5G and / or 6G mobile communication and / or ultrareliable low-latency communication (URLLC). Embodiments of the technique enable latency measurements and / or observability, e.g. for Network Reliability Availability and Resilience (NRAR).

[0189] Embodiments of this technique are potential technical components of advanced 5G and 6G networks, which are described herein, without limitation, utilizing existing definitions and descriptions according to 5G specifications.

[0190] Any embodiment may use (e.g., existing 5G) user-plane protocols. By way of example, a 5G user-plane architecture and protocols are described with reference to Fig. 8.

[0191] For concreteness, and not limitation, herein below the radio device 200 is referred to as a UE, and the network node 200 is referred to as a gNB.Telefonaktiebolaget LM Ericsson (publ)

[0192] P112614WO01

[0193] In Fig. 8, a UE 200 is connected over a radio interface (e.g., as indicated at reference signs 902 and 1002 in Figs. 9 and 10, respectively, e.g. 3GPP's Uu interface) with a gNB 100 of a radio access network (RAN) 500.

[0194] The gNB 100 may be separated into distributed unit (DU) and centralized unit (CU), connected via an Fl interface.

[0195] The gNB 100 is connected to a core network (CN) including a user-plane function (UPF). Typically, IP or Ethernet data is transported via UE-gNB-UPF or vice versa.

[0196] The RAN protocol stack between UE 200 and gNB 100 includes the Service Data Adaptation Protocol (SDAP) protocol, for handling mapping of QoS flows as established by the UPF to data radio bearers (DRBs) as established by the gNB 100.

[0197] The protocol data convergence protocol (PDCP) is among others responsible for encryption / integrity protection and handover forwarding and retransmission. For handovers between gNBs 100 the Xn interface is employed.

[0198] The radio link control (RLC) layer is (among others) responsible for segmentation of higher layer PDCP or IP data to fitting the transport blocks (TBs) available for the lower layer radio transmission. Also, retransmissions are based on automated repeat request (ARQ) in acknowledged mode of RLC.

[0199] The MAC protocol stands for medium access control and supports scheduling of transmissions over the air, and entails the hybrid automated repeat request (HARQ) protocol.

[0200] The physical layer (PHY) handles, e.g., modulation and coding, and the actual physical transmission.

[0201] The HARQ protocol, for the example of downlink data transfer, provides feedback 504 received, for example via the uplink physical layer control channel (e.g., physical uplink control channel, PUCCH), transmitted at certain preconfigured occasions. In some situations, this feedback message may be error prone, and false positive receptions are possible, e.g. in 5G radio access technology. A negative acknowledgement of a reception (NACK) may be flipped to be received as aTelefonaktiebolaget LM Ericsson (publ)

[0202] P112614WO01

[0203] positive acknowledgement (ACK), for example. This may be avoided using a CRC-protected channel.

[0204] Any embodiment may be configured to support or control dependable communication and / or to enable observability.

[0205] For critical applications (i.e., use cases or services), it is important to be able to obtain dependable communication. A critical application, has a critical Key Performance Indicators (KPI, e.g. throughput or latency) for which a minimum performance level is required in order for the application to work correctly. Many critical applications are time-critical, which means that there is a maximum delay that can be accepted by the application in order to work sufficiently well. For example, in a networked control application, like motion control of a mobile robot or remote-controlled vehicle, the control may become unstable or dysfunctional if the latency exceeds the required maximum latency value. From the application perspective the network becomes unavailable at times when the minimum performance level (e.g. in terms of maximum tolerable latency) is not achieved any more.

[0206] High levels of availability are typically expected by critical applications (and may be requested, e.g. via a service level agreement) - for example, an application may require that a latency does not exceed 10 ms latency with an availability of 99.9999 %.

[0207] For dependable communication, the RAN 500 must be able to observe or monitor the KPI performance, at least for a critical KPI with a minimum performance level, that is delivered to the application, and must take means to assure that a promised service performance is met at the adequate level.

[0208] Embodiments enable observability of achieved performance metrics of the communications system (e.g., the RAN 500), which is an important feature for 5G advanced and 6G radio access technology, e.g. in order to be able to provide proof of fulfillment of service contracts specifying such performance metrics or to predict achievable service performance and activate service assurance actions if needed.Telefonaktiebolaget LM Ericsson (publ)

[0209] P112614WO01

[0210] One important metric is the downlink packet latency in the RAN 500. I.e., the time between ingress of a data packet in the RAN 500 and delivery (e.g., at 804a or 804b), optionally including its buffering time in the gNB 100, processing times, transmission time over the radio path, and / or further processing and potential packet reordering delays in the receiving UE 200.

[0211] Independent or in combination with any embodiment disclosed herein, a device is provided to measure the downlink packet latency accurately and thus to be able to draw conclusions from their accurate downlink packet latency distribution.

[0212] Alternatively or in addition, a gNB method 300 (and accordingly a UE method 400 for latency measurement comprises at least one of the following steps:

[0213] - gNB 100 keeps track of packet latency before a data packet is radiotransmitted, e.g. including a buffering time.

[0214] - gNB keeps track of a mapping of which packets (e.g. by PDCP or RLC sequence number) or segments of the packet (RLC segments, RLC sequence number and segmentation offset) are transmitted to a UE 200 via which HARQ process and at which time.

[0215] - Optionally, a reliable HARQ feedback protocol is employed, based on HARQ feedback that is scheduled in an UL data channel, e.g. physical uplink shared channel (PUSCH), and for which thus transmission times are known by the gNB 100.

[0216] - gNB 100 can calculate 304 the downlink packet latency 700 of a data packet when receiving the positive HARQ feedback (ACK) for the HARQ process the data packet was included in (or the multiple HARQ processes the packet was segmented to). gNB 100 considers therein also potential reordering delays in the receiving UE 200 based on calculating packet reception times of packets with subsequent sequence numbers.

[0217] Alternatively or in addition, a method 300 may comprise downlink packet latency measurements based on reliable scheduled HARQ feedback, i.e. by gNB 100 calculating latency considering at least one of:

[0218] - packet buffer,

[0219] - transmission,Telefonaktiebolaget LM Ericsson (publ)

[0220] P112614WO01

[0221] decoding and

[0222] reassembly / reordering delay

[0223] The gNB 100 may determine the reception time based on the received scheduled HARQ feedback, and optionally further determining reassembly / reordering delays by calculating such reception times for multiple to be reassembled / reordered packets and maintaining a mapping from packet sequence numbers to HARQ processes.

[0224] Any of the above embodiments may be implemented according to the following detailed embodiment and / or using the receiver model 102 schematically illustrated in Fig. 8.

[0225] As part of this function, the gNB 100 may maintain 302 (e.g., track) downlink packet queueing delays, keep track of the mapping of packets to downlink HARQ transmissions, HARQ transmission timings, as well as HARQ feedback timings.

[0226] Moreover, the gNB 100 keeps a replicated state of the reordering timer of the UE 200 based on the calculated and estimated HARQ receptions and included packets. Based on this stored information, the gNB 100 is able to determine (e.g., compute or estimate) the downlink latency for each data packet 502.

[0227] The latency determined by the method 300 may comprise at least one of the following substeps and definition for a latency measurement manager function.

[0228] Preprocessing and buffering time:

[0229] For downlink transmission, when a packet e.g. IP packet or Ethernet packet becomes available at the gNB 100 for transmission, it is in typical implementation pre-processed, i.e. it is assigned a PDCP sequence number (SN), and further RLC / MAC-subheaders are pre-calculated, the data packet 502 is encrypted and may be integrity protected. The pre-processed packet 502 is then stored to a downlink transmission buffer, which may be assumed to be present at the RLC layer, as illustrated in Fig. 8.

[0230] Downlink latency measurements may refer to L2 ingress to egress latency, i.e. the latency calculation may consider as the starting point when the data packet 502 becomes available for pre-processing. Assuming on the other hand that theTelefonaktiebolaget LM Ericsson (publ)

[0231] P112614WO01

[0232] pre-processing does not take considerable amount of time, the starting point may be considered when the data packet 502 is put to the transmission buffer, i.e. after pre-processing. Preferably, the device 100 or the model 102 (as a latency measurement manager function) records the time when the data packet 502 arrived and / or is put into the transmit buffer and may associate this timestamp with an identifier for this packet, e.g. the assigned PDCP SN.

[0233] Transmission time:

[0234] When a packet is transmitted from the gNB 100 with the downlink HARQ protocol (in MAC), the device 100 or the model 102 (as a latency measurement manager function) stores this timestamp associated with the SN and the HARQ process (identified by ID and / or transmission time) used.

[0235] Reception time:

[0236] The gNB 100, for legacy downlink HARQ, expects feedback for the HARQ process at certain points in time, i.e. defined by the PUCCH HARQ feedback transmission timing. If the concept of reliable downlink HARQ feedback is utilized, where downlink HARQ feedback is scheduled by the gNB on PUSCH, the feedback can be considered reliable, i.e. false-positives cannot happen since a CRC check is included in the PUSCH transmission.

[0237] For latency measurements, the gNB 100 must know when the HARQ transmission was successfully decoded in the UE 200, and this knowledge can be obtained by considering to which DL HARQ reception time a positive HARQ feedback 504 refers to. For reliable DL HARQ feedback, a HARQ ACK cannot be a false positive, therefore the latency cannot be underestimated. Since reliable DL HARQ feedback 504 is scheduled, the gNB 100 should schedule the DL HARQ feedback 504 for the earliest available time in the UE 200 after processing the DL HARQ transmission 503, and may repeat this for potentially needed DL HARQ retransmissions 503. The device 100 or the model 102 (as a latency measurement manager function) records for each data packet 502, when the DL HARQ transmission was successfully received in the UE 200. For the case of segmentation, i.e. a packet is split into multiple HARQ transmissions 503, the gNB 100 should remember the time 706 when the last HARQ transmission 503 orTelefonaktiebolaget LM Ericsson (publ)

[0238] P112614WO01

[0239] retransmission 503 carrying segments of that data packet 502 is received, i.e. when the data packet 502 was reassembled in the UE 200.

[0240] Reordering time:

[0241] When out of order delivery is configured in the receiver, the successful HARQ reception time (after decoding, and potential reassembly of segments) can be considered the L2 egress time for the packet.

[0242] When reordering before delivery is configured in the receiver, the original order of PDCP SNs needs to be established before delivery, unless the reordering timer expires. The reordering timer is started for a missing SN in the receiver, and stopped when the SN gap is closed. The latency measurement manager in the gNB must keep track of the reordering behavior in the UE to calculate when a packet is delivered 804a or 804b by the UE 200, i.e. its L2 egress time after reordering.

[0243] Therefore, the device 100 or the model 102 (as a latency measurement manager function) should replicate a reordering timer of the UE 200, i.e. consider it started, stopped, expiring for the calculated packets HARQ reception times from the previous step.

[0244] With the above, the device 100 or model 102 (as the latency measurement manager function) is able to determine 304 (e.g., calculate) the L2 egress time for each data packet 502. Together with the stored information about the L2 ingress time of the packet, the gNB 200 can calculate the packet latency 700, i.e. the L2 downlink delay (egress time 704 - ingress time 702).

[0245] Any embodiment may be implemented along the lines of the following example of a sequence of events (which may be combined with or may extend the sequence of the Figs. 6A to 6D).

[0246] TO: A first and a second data packet 502 arrives in a buffer of the gNB 100.

[0247] Tl: A first segment of the first packet 502 with assigned SN 1 is transmitted in HARQ process 1.Telefonaktiebolaget LM Ericsson (publ)

[0248] P112614WO01

[0249] The gNB 200 schedules HARQ feedback 504 for this process at a first possible feedback occasion i.e. Tlfbafter the reception and decoding of the HARQ process in the UE 200 at Tlrx(e.g., T1 plus a known propagation and / or processing delay requirement).

[0250] T2: A second segment of the first packet 502 with assigned SN 1 is transmitted in HARQ process 2.

[0251] The gNB 100 schedules HARQ feedback for this process at a first possible feedback occasion, i.e. T2fbafter the reception and decoding of the HARQ process in the UE 200 at T2rx(e.g., T2 + a known propagation and / or processing delay requirement).

[0252] T3: The second packet (entirely) with assigned SN 2 is transmitted in HARQ process 3.

[0253] The gNB 100 schedules HARQ feedback for this process at a first possible feedback occasion, i.e. T3fbafter the reception and decoding of the HARQ process in the UE 200 at T3rx(e.g., T3 + a known propagation and / or processing delay requirement).

[0254] Tl+RTT: An ACK 504 is received for HARQ process 1, the gNB 100 knows that the first segment of the first packet was received in the UE 200 at Tlrx. However, the packet delay is not calculated yet, as the gNB 100 knows that the second segment of the first packet with sequence number 1 is still not received.

[0255] T2+RTT: A NACK is received for HARQ process 2, the gNB 100 schedules a retransmission and schedules HARQ feedback for this retransmission at (T2+RTT)fbafter the UE 200 may have received the retransmission at (T2+RTT)rx

[0256] T3+RTT The ACK is received for HARQ process 3, the gNB knows that the second packet was received at T3rx. However in case that in-order delivery is configured for the radio bearer, the gNB 100 waits for reordering with the so far not received complete data packet 502 with SN 1, since the second packet 502 with SN 2 it is known not yet to be delivered in theTelefonaktiebolaget LM Ericsson (publ)

[0257] P112614WO01

[0258] receiving UE 200 while earlier packets are not yet delivered, or only after an in-order delivery time (i.e. a reordering timer).

[0259] T2+2RTT: As ACK 504 is received for HARQ process 2, the gNB 100 knows that the second segment of the first packet was received at (T2+2RTT)rx, the gNB 100 can now determine 304 (e.g., calculate) the packet delays. It knows that the first packet 502 was reassembled at this point with reception of all its segments and delivered 804a or 804b. It further knows that the subsequent packet was then also reordered and delivered as well. The reassembly and delivery processing delays are assumed to be negligible in particular in comparison to all other delays (buffer, transmission, processing for decoding).

[0260] The latency for both the first and second packet in this example is thus

[0261] latency = (T2+2RTT)rx- TO.

[0262] Note that herein "Tm+nRTT" is not a formula for computing timings but a symbol for an event, namely the network node 100 updating the receiver model 102 according to the monitoring steps 303 or 303' based on the n-th HARQ feedback after the transmission Tm. The associated timing is known by the network node 100 due to its record of transmission times, optionally with the addition of a timing advance (TA) known for the radio device 200 as a result of the latest randomaccess procedure of the radio device 200.

[0263] Any embodiment may be applicable to UE and gNB of a RAN, e.g., according to, or by changing pertinent standard document: 3GPP TS 38.322, e.g., version 18.2.0.

[0264] Some embodiments can be implemented without changes or additions to any standard at both UE and network node.

[0265] Some embodiments enable energy improvements, e.g. at a level of the node equipment (e.g., the RAN 500) and network level (e.g., the network 1110).

[0266] As indicated above, the ingress time 702 and egress time 704 may be determined by arrival and delivery (e.g., 804a or 804b), respectively at different layers, e.g. the highest radio layer or the PDCP layer or the SDAP layer.Telefonaktiebolaget LM Ericsson (publ)

[0267] P112614WO01

[0268] If the latency 700 is determined based on PDCP protocol, the starting time may be when, at the transmitter 100, a data packet 502 is received by PDCP from the higher layer protocol (i.e. SDAP). So the "time the data packet becomes available" may refer to when the PDCP transmitter receives this packet from the higher layer SDAP for transmission.

[0269] The data packet 502 may be a PDCP PDU, which is then transmitted to the PDCP receiver at the radio device 200.

[0270] The time 704, when the data packet 502 is delivered 804a, is when all parts of the PDCP PDU have been received, provided there is no re-ordering needed, and the data packet is delivered 8044a by PDCP to the next higher layer (i.e. SDAP).

[0271] Similarly, the latency 700 may be determined at the SDAP layer. The higher layer data packet 502, to be transported via SDAP, may be an IP or an Ethernet data packet. This is received from the UPF of the CN within a GPRS tunneling protocol (GTP). When the data packet 502 arrives at the gNB 100, it is taken out of the GTP (e.g., GTP header is removed), and is passed on to the SDAP. This may be the moment the timer starts, i.e., the time 702.

[0272] The SDAP PDU 502 is transmitted to the receiver 200 (and thereby potentially chopped up into smaller portions). When the entire SDAP PDU 502 is received at the receiver, the SDAP layer delivers 808b the data packet 502 to the next higher layer (e.g., Ethernet or IP).

[0273] So the delivery time 704 may be the time when the data packet 502 is delivered by the SDAP layer at the receiver 200 to the next higher layer.

[0274] Fig. 9 shows a schematic block diagram for an embodiment of the device 100. The device 100 comprises processing circuitry, e.g., one or more processors 904 for performing the method 300 and memory 906 coupled to the processors 904. For example, the memory 906 may be encoded with instructions that implement at least one of the modules 102 and 104.

[0275] The one or more processors 904 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signalTelefonaktiebolaget LM Ericsson (publ)

[0276] P112614WO01

[0277] processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the device 100, such as the memory 906, network node functionality. For example, the one or more processors 904 may execute instructions stored in the memory 906. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 100 being configured to perform the action.

[0278] As schematically illustrated in Fig. 9, the device 100 may be embodied by a network node 900, e.g., functioning as a centralized unit (CU) or distributed unit (DU) of a gNode B or 6G network node. The network node 900 comprises a radio interface 902 coupled to the device 100 for radio communication with one or more receiving stations, e.g., functioning as a radio device (e.g., UE).

[0279] Fig. 10 shows a schematic block diagram for an embodiment of the device 200. The device 200 comprises processing circuitry, e.g., one or more processors 1004 for performing the method 400 and memory 1006 coupled to the processors 1004. For example, the memory 1006 may be encoded with instructions that implement at least one of the modules 202 and 204.

[0280] The one or more processors 1004 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and / or encoded logic operable to provide, either alone or in conjunction with other components of the device 200, such as the memory 1006, receiver functionality. For example, the one or more processors 1004 may execute instructions stored in the memory 1006. Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein. The expression "the device being operative to perform an action" may denote the device 200 being configured to perform the action.

[0281] As schematically illustrated in Fig. 10, the device 200 may be embodied by a radio device 1000, e.g., functioning as a UE. The radio device 1000 comprises a radioTelefonaktiebolaget LM Ericsson (publ)

[0282] P112614WO01

[0283] interface 1002 coupled to the device 200 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or gNB.

[0284] With reference to Fig. 11, in accordance with an embodiment, a communication system 1100 includes a telecommunication network 1110, such as a 3GPP-type cellular network, which comprises an access network 1111, such as a radio access network, and a core network 1114. The access network 1111 comprises a plurality of base stations 1112a, 1112b, 1112c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1113a, 1113b, 1113c. Each base station 1112a, 1112b, 1112c is connectable to the core network 1114 over a wired or wireless connection 1115. A first user equipment (UE) 1191 located in coverage area 1113c is configured to wirelessly connect to, or be paged by, the corresponding base station 1112c. A second UE 1192 in coverage area 1113a is wirelessly connectable to the corresponding base station 1112a. While a plurality of UEs 1191, 1192 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1112.

[0285] Any of the base stations 1112 may embody the device 100. Any of the UEs 1191, 1192 may embody the device 200.

[0286] The telecommunication network 1110 is itself connected to a host computer 1130, which may be embodied in the hardware and / or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 1130 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 1121, 1122 between the telecommunication network 1110 and the host computer 1130 may extend directly from the core network 1114 to the host computer 1130 or may go via an optional intermediate network 1120. The intermediate network 1120 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1120, if any, may be a backbone network or the Internet; in particular, the intermediate network 1120 may comprise two or more sub-networks (not shown).

[0287] The communication system 1100 of Fig. 11 as a whole enables connectivity between one of the connected UEs 1191, 1192 and the host computer 1130. TheTelefonaktiebolaget LM Ericsson (publ)

[0288] P112614WO01

[0289] connectivity may be described as an over-the-top (OTT) connection 1150. The host computer 1130 and the connected UEs 1191, 1192 are configured to communicate data and / or signaling via the OTT connection 1150, using the access network 1111, the core network 1114, any intermediate network 1120 and possible further infrastructure (not shown) as intermediaries. The OTT connection 1150 may be transparent in the sense that the participating communication devices through which the OTT connection 1150 passes are unaware of routing of uplink and downlink communications. For example, a base station 1112 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1130 to be forwarded (e.g., handed over) to a connected UE 1191. Similarly, the base station 1112 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1191 towards the host computer 1130.

[0290] By virtue of the method 400 being performed by any one of the UEs 1191 or 1192 and / or the method 300 being performed by any one of the base stations 1112, the performance or range of the OTT connection 1150 can be improved, e.g., in terms of increased throughput and / or reduced latency. More specifically, the host computer 1130 may indicate to the base stations 100, 900, or 1112 or to the RAN 500, 1111 (e.g., on an application layer) a QoS of the traffic, e.g. the latency requirement to be monitored according to the subject technique.

[0291] As has become apparent from above description, at least some embodiments of the technique allow for downlink packet latency determination, which was cumbersome to measure accurately in the prior art.

[0292] Same or further embodiments can avoid including packet timestamps in each and every packet, synchronizing network node (e.g., gNB) and radio device (e.g., UE) according to known reference time, measuring the latency based on current time and included timestamp for the packets in the radio device, and then reporting the measured delay to the network node. Embodiments do not need such a non-negligible overhead.

[0293] Furthermore, some embodiments use acknowledgements of the HARQ protocol of transmissions including the data packet, because the HARQ feedback is reliable by CRC-protection and / or scheduling, whereas conventional feedback was error-prone.Telefonaktiebolaget LM Ericsson (publ)

[0294] P112614WO01

[0295] Thus, at least some embodiments of the network node and the radio device enable accurate downlink latency measurements without the need for timestamps.

[0296] Many advantages of the disclosed embodiments will be fully understood from the foregoing description, and it will be apparent that various changes may be made in the form, construction and arrangement of the units and devices without departing from the scope of the disclosed embodiments and / or without sacrificing all of their advantages. Since the disclosed embodiments may be varied in many ways, it will be recognized that the disclosed embodiments are exemplary and non-limiting in scope.

Claims

Telefonaktiebolaget LM Ericsson (publ)P112614WO01Claims1. A method (300) performed by a network node (100; 900; 1112) in a radio access network (500; 1111), the method (300) comprising:maintaining (302) a receiver model (102) of a radio device (200; 1191;1192), wherein maintaining (302) the receiver model (102) comprises monitoring (303) a reception state (602) of a data packet (502) based on automatic repeat request, ARQ, feedback (504) received from the radio device (200; 1191; 1192); anddetermining (304), based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

2. The method (300) of embodiment 1, wherein the data packet (502) is a protocol data unit, PDU, of a packet data convergence protocol, PDCP, or a PDU of a service data adaptation protocol, SDAP; and / orwherein the delivery time (704) of the data packet (502) is the time the data packet (502) is delivered (804a; 804b) by a PDCP layer or an SDAP layer of the radio device (200; 1191; 1192) according to the receiver model (102).

3. The method (300) of embodiment 1 or 2, wherein the receiver model (102) comprises a monitored (303) state (603) of reception per transport block (503) based on the ARQ feedback (504) for a combination of ARQ process identifier, PID, and sequence number, SN, associated with the data packet (502).

4. The method (300) of embodiment 3, wherein maintaining (302) the receiver model (102) further comprises deriving (303') the reception state (602) of the data38Telefonaktiebolaget LM Ericsson (publ)P112614WO01packet (502) based on the monitored (303) reception state (603) of each transport block (503) associated with the data packet (502).

5. The method (300) of embodiment 3 or 4, wherein the maintaining (302) of the receiver model (102) comprises maintaining radio schedules of at least one of the transport blocks (503) and the ARQ. feedback (504).

6. The method (300) of any one of embodiments 1 to 5, wherein determining (304) the latency (700) comprises determining the time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) based on a transmission time (706) of a last transport block (503) required for the delivering (804a; 804b) of the data packet (502).

7. The method (300) of any one of embodiments 1 to 6, wherein determining (304) the latency (700) further comprises accounting for a transmission delay between the transmission time (706) of the last transport block (503) and delivery time (704) of the data packet (502) at the radio device (200; 1191; 1192), wherein the delay comprises at least one of:a processing time (708) for decoding the transport block (503) at a physical layer of the radio device (200; 1191; 1192) and / or for reassembling the transport blocks (503) associated with the data packet (502) at a radio link control, RLC, layer of the radio device (200; 1191; 1192); anda radio propagation delay of a radio propagation of the transport block (503) to the radio device (200; 1191; 1192).

8. The method (300) of any one of embodiments 1 to 7, wherein the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102) to layers higher than a radio protocol stack for radio access to the RAN (500; 1111).

9. The method (300) of any one of embodiments 1 to 8, wherein the maintaining (302) of the receiver model (102) comprises monitoring (303) the reception state (602) of each data packet (502) in a sequence of data packets (502)Telefonaktiebolaget LM Ericsson (publ)P112614WO01based on the ARQ. feedback (504) received from the radio device (200; 1191;1192).

10. The method (300) of any one of embodiments 1 to 9, wherein in-sequence delivery (804a; 804b) is configured for the radio device (200; 1191; 1192) or a radio bearer used by the data packet (502).

11. The method (300) of embodiment 10, wherein the receiver model (102) comprises a reordering delay of the delivering (804a; 804b) of the data packet (502) at the radio device (200; 1191; 1192) after receiving (802a; 802b) the data packet (502) at the radio device (200; 1191; 1192) until an earlier data packet has been received and delivered according to the in-sequence delivery (804a; 804b).

12. The method (300) of embodiment 10 or 11, wherein the receiver model (102) comprises a reordering delay of the delivering (804a; 804b) of the data packet (502) at the radio device (200; 1191; 1192) until a reordering timer expires while waiting for receiving an earlier data packet not received and delivered according to the in-sequence delivery (804a; 804b).

13. The method (300) of any one of embodiments 1 to 12, wherein the maintaining (302) of the receiver model (102) comprises a reordering procedure of the radio device (200; 1191; 1192) to infer a reordering delay of data packet reordering by the radio device (200; 1191; 1192), optionally at a PDCP layer of the radio device (200; 1191; 1192), the reordering delay adding to the delivery time (704) of the data packet (502); and / orwherein the determining (304) of the latency (700) comprises inferring a reordering delay for the data packet (502) based on the reception state of earlier data packets delivered (804a; 804b) in sequence.

14. The method (300) of any one of embodiments 1 to 13, wherein the time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) is a time the data packet (502) is provided to a Service Data Adaptation Protocol, SDAP, layer or to a packet data convergence protocol, PDCP, layer, or is provided by an SDAP layer or by a PDCP layer or a time the data40Telefonaktiebolaget LM Ericsson (publ)P112614WO01packet (502) becomes queued at a radio link control, RLC, layer of the network node (100; 900; 1112).

15. The method (300) of any one of embodiments 1 to 14, wherein the ARQ feedback (504) is received from the radio device (200; 1191; 1192) on a cyclic redundancy check, CRC, protected uplink channel.

16. The method (300) of embodiment 15, wherein the CRC-protected uplink channel is a scheduled uplink shared channel.

17. The method (300) of any one of embodiments 1 to 16, further comprising at least one of:scheduling the radio device (200; 1191; 1192) depending on the determined (304) latency (700); andreconfiguring the radio device (200; 1191; 1192) depending on the determined (304) latency (700).

18. A method (400) performed by radio device (200; 1191; 1192) connected or connectable to a radio access network, RAN (500; 1111), the method (400) comprising:receiving (402) a configuration message from a network node (100; 900; 1112) of the RAN (500; 1111), wherein the configuration message instructs the radio device (200; 1191; 1192) to use a cyclic redundancy check, CRC, protected uplink channel for an automatic repeat request, ARQ, feedback (504) that enables the network node (100; 900; 1112) to maintain a receiver model (102) of the radio device (200; 1191; 1192) including a reception state (602) of the data packet (502) within the receiver model (102); andresponsive to a data packet (502) received from the network node (100; 900; 1112), transmitting (404) the ARQ feedback (504) using the CRC-protected uplink channel to the network node (100; 900; 1112), wherein the ARQ feedback (504) enables the network node (100; 900; 1112) to determine, based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission atTelefonaktiebolaget LM Ericsson (publ)P112614WO01the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

19. The method (400) of embodiment 18, further comprising the features and steps of any one of embodiments 2 to 17 or a feature or step at the radio device (200; 1191; 1192) corresponding to the features and steps at the network node (100; 900; 1112).

20. A computer program product comprising program code portions for performing the steps of any one of the claims 1 to 17 and / or 18 or 19 when the computer program product is executed on one or more computing devices (1104; 1204), optionally stored on a computer-readable recording medium (1106; 1206).

21. A network node (100; 900; 1112) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node (100; 900; 1112) is operable to:maintain a receiver model (102) of a radio device (200; 1191; 1192), wherein maintaining the receiver model (102) comprises monitoring a reception state (602) of a data packet (502) based on automatic repeat request, ARQ, feedback (504) received from the radio device (200; 1191; 1192); and determine, based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

22. The network node (100; 900; 1112) of claim 21, further operable to perform any one of the steps of any one of claims 2 to 17.Telefonaktiebolaget LM Ericsson (publ)P112614WO0123. A network node (100; 900; 1112) of a radio access network (500; 1111), configured tomaintain a receiver model (102) of a radio device (200; 1191; 1192), wherein maintaining the receiver model (102) comprises monitoring a reception state (602) of a data packet (502) based on automatic repeat request, ARQ, feedback (504) received from the radio device (200; 1191; 1192); and determine, based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

24. The network node (100; 900; 1112) of claim 23, further configured to perform the steps of any one of claim 2 to 17.

25. A radio device (200; 1191; 1192) comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the radio device (200; 1191; 1192) is operable to:receive a configuration message from a network node (100; 900; 1112) of a RAN (500; 1111), wherein the configuration message instructs the radio device (200; 1191; 1192) to use a cyclic redundancy check, CRC, protected uplink channel for an automatic repeat request, ARQ, feedback (504) that enables the network node (100; 900; 1112) to maintain a receiver model (102) of the radio device (200; 1191; 1192) including a reception state (602) of the data packet (502) within the receiver model (102); andresponsive to a data packet (502) received from the network node (100; 900; 1112), transmit the ARQ feedback (504) using the CRC-protected uplink channel to the network node (100; 900; 1112), wherein the ARQ feedback (504) enables the network node (100; 900; 1112) to determine, based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is43Telefonaktiebolaget LM Ericsson (publ)P112614WO01delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

26. The radio device (200; 1191; 1192) of claim 25, further operable to perform the steps of any one of claims 18 to 19.

1. A radio device (200; 1191; 1192), configured to:receive a configuration message from a network node (100; 900; 1112) of a RAN (500; 1111), wherein the configuration message instructs the radio device (200; 1191; 1192) to use a cyclic redundancy check, CRC, protected uplink channel for an automatic repeat request, ARQ, feedback (504) that enables the network node (100; 900; 1112) to maintain a receiver model (102) of the radio device (200; 1191; 1192) including a reception state (602) of the data packet (502) within the receiver model (102); andresponsive to a data packet (502) received from the network node (100; 900; 1112), transmit the ARQ feedback (504) using the CRC-protected uplink channel to the network node (100; 900; 1112), wherein the ARQ feedback (504) enables the network node (100; 900; 1112) to determine, based on the receiver model (102), a latency (700) of the data packet (502) as a time difference between a time (702) the data packet (502) becomes available for transmission at the network node (100; 900; 1112) and a time (704) the data packet (502) is delivered (804a; 804b) by the radio device (200; 1191; 1192) according to the receiver model (102).

28. The radio device (200; 1191; 1192) of claim 1 , further configured to perform the steps of any one of claims 18 to 19.44Telefonaktiebolaget LM Ericsson (publ)P112614WO0129. A communication system (1100) including a host computer (1130) comprising:processing circuitry configured to provide user data; anda communication interface (1122) configured to forward user data to a cellular or ad hoc radio network (500; 1110) for transmission to a radio device (200; 1191; 1192) wherein the radio network (500; 1110) comprises a radio interface (100; 902; 1112) and processing circuitry (904), the processing circuitry (904) being configured to execute the steps of any one of claims 1 to 17.45

Images