Systems and methods for enabling a timestamp-based packet delay measurement.

Abstract

A Track and Hold, T / H, circuit, arranged for tracking an input signal during a second phase and arranged for holding a sampled value of said input signal during a first phase, comprising an output switch arranged for providing said input signal to an output during said second phase, for providing an output signal at said output, a first bootstrapping circuit arranged for providing a first bootstrapped input signal, during said second phase, to a control terminal of said output switch, wherein said first bootstrapped input signal is a turn-on voltage for turning on said output switch bootstrapped with a measure for said input signal, a second bootstrapping circuit arranged for providing a second bootstrapped input signal, during said first phase, to said control terminal of said output switch, wherein said second bootstrapped input signal is a turn-off voltage for turning off said output switch bootstrapped with a measure for said input signal.

Description

[0001] Title

[0002] Systems and methods for enabling a timestamp-based packet delay measurement.

[0003] Technical field

[0004] The present disclosure generally relates to the field of communications, and more particularly to methods and related devices and network nodes for enabling a timestamp-based packet delay measurement.

[0005] Background

[0006] In 5G networks, Quality of Service, QoS, Monitoring is applied for packet delay measurement to support Ultra Reliable and Low Latency Communications, URLLC, services. The end-to-end, e2e, packet delay between the User Equipment, UE and PDU Session Anchor, PSA, User Plane Function, UPF, consists of a Radio, Access Network, RAN, part of uplink, UL, and downlink, DL, packet delays, and the UL / DL packet delays between the Next Generation, NG, -RAN and PSA UPF.

[0007] QoS Monitoring can be configured at various levels of granularity, such as per QoS flow per UE or per General Packet Radio Service, GPRS, Tunnelling Protocol, GTP-U, path, depending on operator configurations, third-party application requests, or PCF policy controls. The Policy Control Function, PCF, generates authorized QoS Monitoring policies based on requests from the AF and includes them in the Policy and charging control, PCC, rules provided to a Session Management Function, SMF.

[0008] The (DL) packet delays comprises delay in over-the-air interface, a delay on the gNodeB-Distributed Unit, DU, a delay on F1-User plane and a delay in the Centralized Unit Control Plane, CU-UP. For Uplink, UL, the packet delays are different. Here again it can be distributed over four packet delay measurement categories. The first is the UL Packet Data Convergence Protocol, PDCP, packet average delay, further there is an over the air interface packet delay, a delay over the F1-U, which is determined similarly to F1-U of DL, and a PDCP re-ordering delay. The packet delays should be measured per DRB per User Equipment, UE. All these measurements are average delays.

[0009] For Uplink, first is the average over-the-air packet delay in the UL per DRB per UE. This measurement is applicable for EN-DC and SA. This measurement refers to packet delay for DRBs. This measurement provides the average (arithmetic mean) time it takes to successfully receive a transport block from the time of UL transmission indicated in scheduling grant.

[0010] Most packet delay measurements are defined in terms of time of arrival of a packet at a certain point (e.g., arrival at a layer) and time of departure at another point (e.g., departure from a layer). In general, no mechanism is provided to monitor the time difference between departure and arrival. That is, individual packets must be tracked.

[0011] SMF activates UL / DL packet delay measurement between the UE and PSA UPF during PDU session establishment or modification. It sends QoS Monitoring requests to the PSA UPF via N4 and to the NG-RAN via N2 signaling, including monitoring parameters based on PCF policies or local configurations. NG-RAN measures the RAN part of UL / DL packet delays and reports results to the PSA UPF. The PSA UPF is responsible for the part of the packet delay measurement between the RAN and the UPF, combining these results with the RAN delays. If NG-RAN and PSA UPF are time-synchronized, one-way packet delay monitoring is supported; otherwise, the delay is calculated assuming symmetrical UL and DL delays.

[0012] The PSA UPF generates monitoring packets to measure delays based on frequency parameters from the SMF. These packets contain timestamps and QoS Monitoring Packet, QMP, indicators. NG-RAN processes these packets and provides timestamps and delay measurements in monitoring response packets sent back to the PSA UPF. Depending on synchronization between NG-RAN and PSA UPF, delay calculations vary, with potential inaccuracies arising in the absence of time synchronization. Redundant transmission on N3 / N9 interfaces requires the UPF and NG-RAN to monitor QoS for multiple paths, reporting delays for each path to the SMF.

[0013] However, existing technologies face several challenges in implementing accurate end-to-end delay measurements, as e2e packet delay observability is not available in current 3GPP specs. It is possible to measure RAN and CN packet delays, however with several limitations including i) Existing solutions do not track packets E2E across the 3GPP system, ii) Existing solutions deliver average delay on relatively long windows and are not able to detect rare packet delays, iii) existing solutions are too complex and typically require tracking packet across radio protocols.

[0014] Summary

[0015] It would be advantageous to achieve a method which is able to solve or alleviate at least part of the problems discussed in the background section.

[0016] In a first aspect of the disclosure, there is provided a method performed by a network node operating in a radio access network, RAN, for enabling a timestampbased packet delay measurement in downlink, the method comprising: receiving, by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference; converting, by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; inserting, by the network node, the second timestamp in a radio network packet that encapsulates and includes at least a portion of the originating network packet; and sending, by the network node, the radio network packet to a user equipment, UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received originating network packet with respect to the radio grid wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as at least the portion of the originating network packet traverses from an originating network node in the originating network to the UE.

[0017] The present disclosure allows to track packets between ingress and egress of the 3GPP system, with limited complexity and overhead in RAN. The invention removes dependency between the process for timestamp generation and the actual carrier used for timestamp message transmission, enabling accurate packet delay measurement in case of multicarrier operation, during reconfigurations and even during mobility with packet forwarding across nodes. In another aspect, there is provided a method performed by a network node operating in a radio access network, RAN, for conducting a timestamp-based packet delay measurement in the uplink, the method comprising: receiving, by the network node from a user equipment, UE, via a radio access network link interface a radio network packet that includes a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; converting, by the network node, the second timestamp into a first timestamp associated with a first timing reference; inserting, by the network node, the first timestamp in a core network packet that includes at least a portion of the radio network packet; and sending, by the network node, the core network packet to a core network node via a core network link interface, wherein the first timestamp enables the core network node to conduct an end-to-end packet delay determination of the received radio network packet with respect to the first timing reference, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses between the core network node and the UE.

[0018] In accordance with the present disclosure, the method may be applicable to the uplink as well as to the downlink.

[0019] In these scenarios, the network node in the RAN, being for example the access node, will convert the first timestamp into a second timestamp. The second timestamp may, for example, be associated with a second timing reference that is based on the radio grid. The first timestamp may be associated with a first timing reference which is different to the second timing reference.

[0020] In the appended figures, similar components and / or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label by a dash and a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.

[0021] The above and other aspects of the disclosure will be apparent from and elucidated with reference to the examples described hereinafter. Brief description of the drawings

[0022] The accompanying drawings, which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application, illustrate certain non-limiting embodiments of inventive concepts. In the drawings:

[0023] Figure 1 is a schematic diagram illustrating an example of a 5th generation (“5G”) network;

[0024] Figure 2 is a block diagram depicting specified downlink measurements in the radio access network;

[0025] Figure 3 is a block diagram depicting specified uplink measurements in the radio access network;

[0026] Figure 4 is a block diagram depicting an example end-to-end packet delay measurement;

[0027] Figure 5 is a block diagram depicting an example timestamp-based packet delay measurement conducted in the downlink in accordance with some embodiments;

[0028] Figure 6 is a block diagram depicting an example timestamp-based packet delay measurement conducted in the uplink in accordance with some embodiments;

[0029] Figure 7 is an flow chart depicting an exemplary method for conducting a timestamp-based packet delay measurement by a user equipment in the downlink in accordance with some embodiments;

[0030] Figure 8 is an flow chart depicting an exemplary method for conducting a timestamp-based packet delay measurement by a user equipment in the uplink in accordance with some embodiments;

[0031] Figure 9 is an flow chart depicting an exemplary method for conducting a timestamp-based packet delay measurement by a network node in the downlink in accordance with some embodiments;

[0032] Figure 10 is an flow chart depicting an exemplary method for conducting a timestamp-based packet delay measurement by a network node in the uplink in accordance with some embodiments; Figure 11 is a diagram illustrating the defining of a radio time reference T_{ref}A{radio} and time interval used for timestamp generation in accordance with some embodiments;

[0033] Figure 12 is a diagram illustrating the radio time reference T_{ref}A{radio} as the start of the ongoing system frame number (SFN) cycle in accordance with some embodiments;

[0034] Figure 13 is a diagram illustrating TO as the time passed since the start of the SFN cycle and measured as an integer number of OFDM symbols in accordance with some embodiments;

[0035] Figure 14 is a diagram illustrating the measurement of a same time period using two different radio time references in accordance with some embodiments;

[0036] Figure 15 is a diagram illustrating the indexing of OFDM symbols in accordance with some embodiments;

[0037] Figure 16 is a diagram illustrating the indication of the offset TO using an indexing that the user equipment depends on the subcarrier spacing (SOS) in accordance with some embodiments;

[0038] Figure 17 is a block diagram of a communication system in accordance with some embodiments;

[0039] Figure 18 is a block diagram of a user device in accordance with some embodiments;

[0040] Figure 19 is a block diagram of a network node in accordance with some embodiments; and

[0041] Figure 20 is a block diagram of a virtualization environment in accordance with some embodiments.

[0042] Detailed description

[0043] It is noted that in the description of the figures, same reference numerals refer to the same or similar components performing a same or essentially similar function. A more detailed description is made with reference to particular examples, some of which are illustrated in the appended drawings, such that the manner in which the features of the present disclosure may be understood in more detail. It is noted that the drawings only illustrate typical examples and are therefore not to be considered to limit the scope of the subject matter of the embodiments. The drawings are incorporated for facilitating an understanding of the disclosure and are thus not necessarily drawn to scale. Advantages of the subject matter as claimed will become apparent to those skilled in the art upon reading the description in conjunction with the accompanying drawings.

[0044] The ensuing description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability or configuration of the disclosure. Rather, the ensuing description of the preferred exemplary embodiment(s) will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment of the disclosure, it being understood that various changes may be made in the function and arrangement of elements, including combinations of features from different embodiments, without departing from the scope of the disclosure.

[0045] The disclosed subject matter provides a method for measuring end-to- end (E2E) one-way packet delays in a 3GPP system comprising different subsystems, such as a radio access network (RAN), a core network (CN), a user equipment (UE), which may not be accurately synchronized to each other. The disclosed subject matter includes adding timestamps to data protocol headers in packets that are communicated via the CN and RAN. The disclosed subject matter further includes translating the timing reference of one packet header into a second timing reference, such that the receiving device is able to evaluate the E2E packet delay.

[0046] Legacy solutions typically require accurate synchronization of endpoints for one-way E2E packet delay measurements, which is not always a valid assumption. When accurate synchronization cannot be assumed, only round trip time (RTT) of the communication can be evaluated.

[0047] Other legacy solutions allow for conducting a one-way packet delay measurement within RAN. However, this measurement is performed at the expense of significant complexity, which is required for correlating packets across radio layers, and at the cost of low accuracy, which is due to the uncertainty about the ACK / NACK (Acknowledgement / Negative-Acknowledgement) reception time for a given packet, as well as uncertainties in the queuing time in the UE.

[0048] In some embodiments pertaining to downlink (DL) communications, the disclosed methodology or process includes i) adding timestamps to data protocol headers in the CN, wherein the timestamps are associated to a first timing reference, ii) reading the CN timestamps in RAN and converting the timestamps into a second timestamp that is based on a second timing reference based on the radio grid (e.g., OFDM symbol index), iii) inserting and / or including the second timestamp in a radio protocol header, iv) reading the second timestamp in the UE, v) comparing the second timestamp to a local timing reference based on the RAN radio grid, and vi) obtaining the E2E packet delay. As used herein, the E2E packet delay refers to a delay corresponding to a time period that transpires as a first original data packet traverses between an originating network node and the UE.

[0049] In some embodiments pertaining to uplink (UL) communications, the disclosed methodology or process includes similar steps and / or operations as described here, but are performed in a reverse direction.

[0050] In some embodiments, the disclosed subject matter is described in the context of 5G New Radio (NR) and refers to relevant aspects of the specification. However, the principles of the present disclosure is applicable to other access technologies, including Long Term Evolution (LTE) and future 6G systems.

[0051] In some embodiments, the disclosed subject matter includes a set of methods implemented in different parts of the network that can be used to monitor packets from end-to-end within the 3GPP domain. More specifically, conducting the monitoring and measurement from an application packet’s entry point to an application packet’s exit point.

[0052] As disclosed herein, the term “application packet” is used to refer to a packet that is delivered to a 5G system for transport. The application packet originates outside the 5G system (e.g., at an application server) while its final destination is also external to the 5G system (e.g., an application running on a UE). For example, the application packet may be an Internet protocol (IP) packet carrying some application data payload (e.g., part of a video frame) or an Ethernet frame carrying some industrial payload. The present disclosure pertains to applications that require some level of performance guarantees, possibly formalized by a contract, such as a Service Level Agreement (SLA), between a service provider and the user of the service. The service may include a “connectivity / communication service” and its associated performance guarantees are likely expressed in terms of maximum allowed packet latency, minimum guaranteed throughput, and / or minimum service availability. More complex services may also be envisioned, with more articulated requirements. However, it is likely that those complex requirements eventually reduce down to connectivity service requirements as described above.

[0053] One important property of a network capable of delivering a communication service is its ability to track (i.e. , observe) its actual performance with the required accuracy, granularity, and with limited complexity and signaling overhead. Performance tracking may form the basis for assessing service performance guarantees fulfilment. As such, it is important that the endpoints of the observability match the endpoints for the guaranteed service. In the case of a mobile network, those endpoints may include ingress and / or egress endpoints of the 3GPP network. For example, the endpoints may be at the UE (and / or its application interface) on one side and at the user plane function (UPF) on the core network side. In some cases, it is also useful to track performance for a subsystem, for example for diagnostic purposes. Hence, RAN or Core Network performance observability can also be of interest.

[0054] As indicated above, the disclosed subject matter is applicable to both downlink (DL) and uplink (UL) communications, and it entails a method and apparatus for measuring packet delay between endpoints of a 3GPP network that encompasses a radio access network (RAN) and a core network (CN). Because IP packets (or other protocols) entering the 3GPP system are encapsulated into different protocols at the ingress points and egress points of the 3GPP system, it is can be difficult to measure the packet delay in an end-to-end fashion, and to allow the 3GPP system to be aware of such packet delay.

[0055] The disclosed subject matter assumes that different subsystems in the network, such as the RAN and the CN, use different timing references. For example, the CN and the gNB may be accurately synchronized to a satellite-based UTC (coordinated universal time) reference, while the UE may be synchronized to a less accurate timing reference, to a local reference, or to an external absolute timing reference that is unknown to the network. Because of this, naive timestamping of packets traversing different subsystems does not lead to accurate delay measurements in the general case.

[0056] In some embodiments, the disclosed subject matter includes i) generating and including a first timestamp, based on a first timing reference system, to a data protocol header in an application packet received by a first node / function in the 3GPP system, ii) generating a second data protocol header at an intermediate node / function of the system, that includes / carries the same timestamp from the first node / function, however wherein the timestamp is optionally reformatted and based on a second timing reference, and iii) receiving the second protocol header at a third node / function of the system and calculating the packet delay based on a time difference between a local timing reference and the timestamp carried by the second protocol header.

[0057] Figure 1 is a schematic diagram illustrating an example of a 5th generation (“5G”) network. Here, the core network 130 is arranged to communicate with the radio access network, represented by the base stations 120a and 125. The base stations 120a, 120b are arranged to wirelessly communicate with any User Equipment, UE 110.

[0058] Figure 2 is a block diagram depicting specified downlink measurements 200in the radio access network and figure 3 is a block diagram depicting specified uplink measurements 200 in the radio access network.

[0059] Figure 4 is a block diagram depicting an example 400 end-to-end packet delay measurement.

[0060] The following disclosure presents multiple aspects of realizations for uplink and downlink communications. These realizations describe embodiments of many individual aspects. However, only some of these embodiments may be found in a practical system. As used herein, the term packet may refer to a protocol data unit (PDU), a service data unit (SDU), a datagram, a frame, an IP packet, an Ethernet frame, and the like.

[0061] Downlink embodiments of the disclosed subject matter include an application packet from a data network (e.g., the Internet) arriving at the CN for transport over the 5G system. For example, Figure 5 depicts a diagram 500 of an example timestamp-based packet delay measurement conducted in the downlink in accordance with some embodiments of the disclosed subject matter. The entry point is typically a UPF 506, but the concept is applicable to other network functions (NFs) too. In the CN, a NF (e.g., a first UPF 506) is configured to obtain a timestamp T_{CN}. This first timestamp, which can reflect the point in time when the packet arrives at or is processed by UPF 506, is based on a first timing reference T_{ref}A{CN}\ (e.g.,\ based\ on\ UTC).\ The NF / UPF may then include and / or insert at least parts of the application packet into a CN packet payload, such as a GTP-U packet. Similar ideas may be applied if packet segmentation or packet concatenation are used. For example, the CN may include at least parts of the application packet into the payload of one or several CN packets, such as GTP-U packets. The NF / UPF may also include and / or insert the timestamp, T_{CN}, in one or several of the CN packet headers (i.e., as control information or signaling elements or fields), such as GTP header 516. For example, TCN may be included in the header of a CN packet; or in the header of each of the CN packets; or in the header of some of the CN packets (e.g., the first or last CN packet).

[0062] In practice, it makes sense to obtain and assign the timestamp at the entry point of the CN, but the concept presented here is applicable to other points in the CN as well. For example, if the application packet traverses through multiple UPFs (e.g., a first UPF for the Visited Public Land Mobile Network (VPLMN) and a second UPF for the Home PLMN (HPLMN) in the case of roaming), the timestamp may be added to the packet in a second UPF.

[0063] Similarly, multiple timestamps could be associated with a CN packet. For example, if the packet goes through multiple PLMNs, a timestamp may be added in the packet by a CN function (e.g., a UPF) for each of the PLNNs.

[0064] In some embodiments, the packets are transferred from the CN to the RAN over one or more corresponding interfaces (e.g., the NG-U or N3 interface). In the RAN, one node or function, such as a gNB 504 serving a UE 502 or the corresponding CU-UP, may be configured to extract the timestamp T_{CN} from the header 514 of the corresponding CN packet(s). In some embodiments, the gNB 504 is further configured to transforms T_{CN} into T_{CN}A\prime. For example, the gNB may use a second time reference T_{ref}A{radio}. In some cases, T_{ref}A{CN} and the T_{ref}A{radio} may be the same, while in other cases these two time references may be different. In some embodiments, the RAN node (e.g., gNB) may be configured to also use a different timing unit and quantization (e.g., from millisecond (ms) or nanosecond (ns) to SFN, subframe number, slot number, OFDM symbol number, and the like). The gNB may also be configured to use different resolutions for different timestamps. For example, T_{CN} may be expressed in ns and T_{CN}A\prime in ms.

[0065] In some embodiments, the RAN node (e.g., gNB) may be configured to encapsulate at least parts of the packet payload into the payload of one or more RAN data protocol packets, such as Packet Data Convergence Protocol (PDCP) or Service Data Adaptation Protocol (SDAP) packets.

[0066] In some embodiments, the RAN node (e.g., gNB) may be configured to include the timestamp T_{CN}A\prime into the header 512 of one or more of the RAN packets. For example, T_{CN}A\prime may be included in the header 512 of a RAN packet; in the header of each of the RAN packets; or in the header of some of the RAN packet (e.g., the first or last one).

[0067] In some alternate embodiments, the RAN node (e.g., gNB 504) may compute T_{cur}-T_{CN} or T_{cur}A\prime-T_{CN}A\prime to obtain a measurement of the delay experienced by the packet between the UPF 506 and the RAN, where T_{cur} and T_{cur}A\prime denote a time value according to the timing references T_{ref}A{CN} and the T_{ref}A{radio}, respectively. The time value may correspond to the time of arrival of the packet to a RAN node (e.g., a gNB) or the time when the computation is performed. The result may be processed and reported to another function or system management.

[0068] In the DL, one or more packets may be transferred from the RAN node and / or function to the UE 502 over the corresponding interfaces (e.g., the llu interface). In some embodiments, the UE is configured to i) obtain the timestamp T_{CN}A\prime carried by the header 510 of the application packet from the corresponding RAN packet(s), ii) obtain a current time value T_{UE}A\prime based on the reference T_{ref}A{radio}, and iii) compute an elapsed time value using T_{CN}A\prime and T_{UE}A\prime, e.g., T_{UE}A\prime-T_{CN}A\prime.

[0069] In some alternative embodiments, the delay measurement can optionally be further processed and possibly combined with other measurements to form a delay measurement report. The measurement report may be further signaled by the UE 502 to other functions of the 3GPP system, or to the application. Uplink embodiments of the disclosed subject matter include the UE obtaining a timestamp T_{UE}A\prime. For example, Figure 6 depicts a diagram 600 of an example timestamp-based packet delay measurement conducted in the uplink in accordance with some embodiments of the disclosed subject matter. Notably, in the UL, an application packet coming from a higher layer arrives at the UE 602 (e.g., arrives at the first or top radio layer). The UE 602 is configured to obtain a timestamp T_{UE}A\prime. Notably, this timestamp is based on a first time reference T_{ref}A{radio} (e.g., based on UTC or based on a radio time reference, such as a SFN, relative to SFN, or the like). The UE 602 may also be configured to process at least part of the application packet into one or several RAN packet payloads. In some embodiments, the RAN packet can be a SDAP packet or PDCP packet. In some embodiments, the UE 602 may associate the timestamp T_{UE}A\prime with one or several of the RAN packet and include the timestamp in the header 610 of one or more of the RAN packets.

[0070] In some embodiments, the RAN packets are transferred from the UE 602 to a RAN node (e.g., gNB 604 in Figure 6) or function over the UE via the Uu interface. As such, the RAN node or function is configured to extract the timestamp T_{UE}A\prime from the header 612 of the corresponding RAN packets. The RAN node is further configured to transform T_{UE}A\prime into T_{UE}. For example, the RAN node may use a second time reference T_{ref}A{CN}. In some cases, T_{ref}A{CN} and the T_{ref}A{radio} may be the same, but in other instances these time references may be different.

[0071] In some embodiments, the RAN node is configured to use a different unit (e.g., from ms or ns to SFN, subframe number, slot number, OFDM symbol number, etc.).

[0072] In some embodiments, the RAN node is configured to use a different resolution. For example, T_{UE} may be expressed in ns and T_{UE}A\prime in ms. In some embodiments, the RAN node (e.g., gNB 604) is configured to transform the RAN packets into one or more several CN packets. The RAN node can also associate the timestamp T_{UE}\ with one or several of the CN packets. For example, T_{UE} may be included in the header 614 of a CN packet; or in the header of each of the CN packets; or in the header of some of the CN packet(s) (e.g., the first or last one). Optionally, the RAN node may compute T_{cur}-T_{UE} or T_{cur}A\prime-T_{UE}A\prime to obtain a measurement of the delay experienced by the packet between the UE 602 and the RAN, where T_{cur} and T_{cur}A\prime denote a time value according to the references T_{ref}A{CN} and the T_{ref}A{radio}, respectively. The time value may correspond to the time of arrival of the packet to a RAN node (e.g., gNB 604) or the time when the computation is performed. The result may be processed and reported to another function or system management.

[0073] In some embodiments, the CN packets are transferred from the RAN to the CN over the corresponding interfaces (e.g., the NG-ll or N3 interface). In the CN, a NF (e.g., a first UPF 606) obtains an application packet using the corresponding CN packet(s). The UPF is also configured to obtain a timestamp T_{UE} associated with the application packet from the header 616 of the corresponding CN packet(s), and obtain a current time value T_{CN} in the reference T_{ref}A{CN}. Afterwards, the UPF may compute an elapsed time value using T_{UE} and T_{CN}, e.g., T_{CN}-T_{UE}.

[0074] In practice, it makes sense to obtain and assign the timestamp at the exit of the CN, but the concept presented here is applicable to other endpoints in the CN too. For example, if the application packet goes through multiple UPFs (e.g., a first UPF for the HPLMN and a second UPF for the VPLMN in the case of roaming), the timestamp may be added by the first UPF.

[0075] In some embodiments, the delay measurement may be further processed and possibly combined with other measurements, to form a delay measurement report. The measurement report may be further signaled to other functions of the 3GPP system, or to the application.

[0076] Uplink embodiments of the disclosed subject matter include an application packet coming from a higher layer arrives at the UE (i.e. , arrives at the first or top radio layer). In some embodiments, the UE is configured to obtain a timestamp T_{UE}A\prime. The timestamp is based on a first time reference T_{ref}A{radio} based on UTC or based on a radio time reference (e.g., a SFN, relative to SFN, etc.), similarly to the DL embodiment described above.

[0077] In some embodiments, the UE is configured to process at least part of the application packet into one or several RAN packet(s) payloads. For example, the RAN packet can be a SDAP packet or a PDCP packet. The UE is further configured to associate the timestamp T_{UE}A\prime with one or several of the RAN packet(s). In some embodiments, the RAN packet(s) are transferred from the UE to a RAN node or function over the UE via corresponding interface(s) (e.g., the Uu interface). For example, the RAN node or function may be configured to extract the timestamp T_{UE}A\prime\ from the corresponding RAN packet(s). The RAN node may also be configured to convert and / or transform T_{UE}A\prime into T_{UE}. For example, the RAN node may be configured to use a second time reference T_{ref}A{CN}. In some cases, T_{ref}A{CN} and the T_{ref}A{radio} may be the same, while in other cases the two timing references may be different. The RAN node may also use a different unit (e.g., from ms or ns to SFN, subframe number, slot number, OFDM symbol number, etc.) and / or use a different resolution. For example, T_{UE} may be expressed in ns and T_{UE}A\prime in ms.

[0078] In some embodiments, the RAN node or function is configured to transform the RAN packet(s) into one or several CN packet(s) and associate the timestamp T_{UE}\ with one or several of the CN packet(s). For example, T_{UE}\ may be included i) in the header of a CN packet, ii) in the header of each of the CN packets, and / or iii) in the header of some of the CN packet(s) (e.g., the first or last one).

[0079] Optionally, the RAN node may compute T_{cur}-T_{UE} or T_{cur}A\prime-T_{UE}A\prime to obtain a measurement of the delay experienced by the packet between the UE and the RAN, where T_{cur} and T_{cur}A\prime denote a time value according to the references T_{ref}A{CN} and the T_{ref}A{radio}, respectively. The time value may correspond to the amount of time corresponding to the arrival of the packet at a RAN node (e.g., a gNB) or the amount of time when the computation is performed. The result may be processed and reported to another function or system management.

[0080] In some embodiments, the CN packet(s) is / are transferred from the RAN to the CN over corresponding interface(s) (e.g., the NG-U or N3 interface). In the CN, a NF (e.g., the first UPF) may be configured to obtain the application packet using the corresponding CN packet(s) and / or obtain a timestamp T_{UE}\ associated with the application packet from the corresponding CN packet(s).

[0081] The NF (e.g., UPF) may also be configured to obtain a current time value T_{CN}\ in the reference T_{ref}A{CN} and computes an elapsed time value using T_{UE}\ and T_{CN}, e.g, T_{CN}-T_{UE}. In practice, it makes sense to obtain and assign the timestamp to the packet when it exits the CN, but the concept presented here is applicable to other endpoints in the CN as well. For example, if the application packet goes through multiple UPFs (e.g., a first UPF for the HPLMN and a second UPF for the VPLMN in the case of roaming), the timestamp may be added in the first UPF.

[0082] One aspect of the disclosed subject matter is that timestamps between UE and RAN may be associated to the T_{ref}A{radio} timing reference. The idea is to leverage the notion that the UE and the RAN work in a synchronous manner from a radio perspective and use a common timing reference as basis for the timestamps. Depending on application requirements and acceptable overhead, a suitable timestamp length and timing resolution can be configured. In one embodiment, the timestamp resolution is ‘K’ OFDM symbols for a reference carrier used as timing reference basis.

[0083] The present disclosure assumes that the RAN node (e.g., a gNB) is aware of both T_{ref}A{CN} and T_{ref}A{radio} timing references. To convert a timestamp from a first timing reference to a second timing reference, the RAN node is configured to implement a formula or table for converting one timing reference into the second timing reference. For example, the RAN node may be aware that OFDM symbol 0 was transmitted at UTC time TO and that OFDM symbols periodicity is Tp seconds. Hence, a timestamp of OFDM symbol index 3 would be converted into T0+3*Tp seconds in UTC time. The reverse conversion from UTC to OFDM symbol index can be implemented with similar procedure.

[0084] Although the description above focuses on “application packets” that are transported by the 5G system, the same principle is applicable for specific packets used for probing (e.g., control packets). For example, for DL communications, T_{CN} may correspond to the time when the packet is generated (e.g., at a NF in the CN) and T_{UE}A\prime corresponds to a time when the packet is processed by the UE.

[0085] For UL communications, T_{UE}A\prime may correspond to a time when the packet is generated and T_{CN} corresponds to a time when the packet is processed by the CN (e.g., by a NF). The UE may generate packets based on i) internal triggers or decisions, ii) in response to an incoming request from the NW, iii) according to a timer, iv) according to a pre-configured condition, and / or the like. The disclosed subject matter may also be applied to a specific group of packets, such as i) packets from a specific UE (e.g., according to an identifier), ii) packets belonging to a specific QoS flow, iii) PDU session or some other form of connection between CN and UE, iv) packets associated with a specific network slide (e.g., according to an identifier such as an S-NSSAI), vi) packets associated with a specific service (e.g., according to an identifier), and the like.

[0086] In some embodiments, the disclosed subject matter may be embodied as a cloud implementation. For example, the RAN and UPF can be executed as microservices over a cloud platform. Hence, part of the proposed signaling may be conducted across cloud functions.

[0087] Figure 7 illustrates a flowchart of a method 700 depicting exemplary operations for conducting a timestamp-based packet delay measurement in the DL by a UE according to one embodiment. Operations of the user equipment (UE), which may be implemented using the structure of the block diagram of Figure 18, will now be discussed with reference to the flowchart according to some embodiments. For example, one or more modules (e.g., software based algorithms or programming code) may be stored in memory 1810 of Figure 18, and these modules may provide instructions so that when the instructions of a module are executed by respective processing circuitry 1802, the UE 1800 performs respective operations of method 700. In some embodiments, memory 1810 may store the disclosed software based algorithm as one or more of application programs 1814.

[0088] In block 701 , the method 700 includes receiving, from a network node operating in a radio access network, a radio network packet via a wireless link interface, wherein the radio network packet contains at least a portion of a first original data packet originating from an originating network node and includes a first timestamp associated with a first timing reference based on a radio grid of the radio network. In some embodiments, the first original data packet includes a General Packet Radio Service Tunneling Protocol (GTP) packet. In some embodiments, the radio network packet is a Packet Data Convergence Protocol (PDCP) packet or a Service Data Adaption Protocol (SDAP) packet. In some embodiments, the originating network node is a User Plane Function (UPF) operating in a core network communicatively connected to the network node operating in the radio access network. In some embodiments, the network node operating in the radio access network is a gNB operating in the radio access network. In some embodiments, the first timing reference is based on Orthogonal Frequency Division Multiplexing (OFDM) symbol numbers and / or subframe indices.

[0089] In block 702, the method 700 includes obtaining the first timestamp from a header of the received radio network packet. In some embodiments, the timestamp has been converted by the network node operating in the radio access network from a second timestamp that is associated with a second timing reference based on Coordinated Universal Time (UTC). In some embodiments, the first timing reference and the second timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

[0090] In block 703, the method 700 includes utilizing the first timestamp to determine an end-to-end packet delay of the received radio network packet, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses between the originating network node and the UE.

[0091] In some embodiments, the first timing reference is defined via configurable rules used to generate the first timestamp. In some embodiments, the first timing reference is configured for a timestamp calculation that is aligned with a radio network period boundary for a reference carrier. In some embodiments, the first timestamp represents a time difference between a time when the packet is generated and the first timing reference. In some embodiments, the first timing reference corresponds to a system frame number, SFN, time period boundary for a reference carrier.

[0092] In other words, the present disclosure may provide a method performed by a network node operating in a radio access network, RAN, for enabling a timestampbased packet delay measurement in downlink, the method comprising: receiving, by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference; converting, by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; inserting, by the network node, the second timestamp in a radio network packet that encapsulates and includes at least a portion of the originating network packet; and sending, by the network node, the radio network packet to a user equipment, UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received originating network packet with respect to the radio grid wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as at least the portion of the originating network packet traverses between an originating network node in the originating network and the UE.

[0093] The underlying insight is that the network node will convert the first timestamp, which is referenced to a first timing reference, with a second timestamp, which is referenced to a second timing reference. This allows the UE to interpret the second timestamp and to calculate any delay in the network.

[0094] The first timestamp may, for example, be comprised by a header of a packet, for example a header of the originating network packet. The originating network packet may be a General Packet Radio Service Tunneling Protocol, GTP, packet.

[0095] The radio network packet may be a Packet Data Convergence Protocol, PDCP, packet or a Service Data Adaption Protocol, SDAP, packet.

[0096] Typically, the originating network node is a User Plane Function, UPF, operating in a core network communicatively connected to the network node operating in the radio access network.

[0097] The second timestamp may have been converted by the network node from a first timestamp that is associated with a first timing reference based on Coordinated Universal Time, UTC.

[0098] Typically, the network node is a gNB operating in the radio access network.

[0099] The first timing reference and the second timing reference may utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

[0100] In an example, the second timing reference is based on Orthogonal Frequency Division Multiplexing, OFDM, symbol numbers and / or subframe indices Figure 8 illustrates a flowchart of a method 800 depicting exemplary operations for conducting a timestamp-based packet delay measurement in the UL by the UE according to one embodiment. Operations of the UE, which may be implemented using the structure of the block diagram of Figure 18, will now be discussed with reference to the flowchart according to some embodiments. For example, one or more modules (e.g., software based algorithms or programming code) may be stored in memory 1810 of Figure 18, and these modules may provide instructions so that when the instructions of a module are executed by respective processing circuitry 1802, the UE 1800 performs respective operations of method 800. In some embodiments, memory 1810 may store the disclosed software based algorithm as one or more of application programs 1814.

[0101] In block 801 , the method 800 includes receiving, by the UE, an application packet.

[0102] In block 802, the method 800 includes deriving a first timestamp corresponding to a first timing reference based on a current radio grid time associated with the receiving of the application packet.

[0103] In block 803, the method 800 includes sending, to a network node operating in a radio access network, a radio network packet via a wireless link interface, wherein the radio network packet contains the application packet and includes the first timestamp, wherein the first timestamp is converted by the network node to a second timestamp associated with a second timing reference.

[0104] In some embodiments, the radio network packet is a PDCP packet or a SDAP packet. In some embodiments, the radio network packet is directed to a core network node that is operating in a core network and is communicatively connected to the network node operating in the radio access network. In some embodiments, the second timing reference is based on UTC. In some embodiments, the network node operating in the radio access network is a gNB operating in the radio access network. In some embodiments, the first timing reference and the second timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions. In some embodiments, the first timing reference is based on OFDM symbol numbers and / or subframe indices.

[0105] In some embodiments, the first timing reference is defined via configurable rules used to generate the first timestamp. In some embodiments, the first timing reference is configured for a timestamp calculation that is aligned with a radio network period boundary for a reference carrier. In some embodiments, the first timestamp represents a time difference between a time when the packet is generated and the first timing reference. In some embodiments, the first timing reference corresponds to a system frame number, SFN, time period boundary for a reference carrier.

[0106] In an example of the present disclosure, there is provided a method performed by a network node operating in a radio access network, RAN, for conducting a timestamp-based packet delay measurement in the uplink, the method comprising: receiving, by the network node from a user equipment (1800), UE, via a radio access network link interface a radio network packet that includes a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; converting, by the network node, the second timestamp into a first timestamp associated with a first timing reference; inserting, by the network node, the first timestamp in a core network packet that includes at least a portion of the radio network packet; and sending, by the network node, the core network packet to a core network node via a core network link interface, wherein the first timestamp enables the core network node to conduct an end-to-end packet delay determination of the received radio network packet with respect to the first timing reference, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses between the core network node and the UE.

[0107] Similar to the explanation provide din the downlink, the method may be applicable in the uplink.

[0108] The second timestamp may be comprised by the header of the radio network packet. The core network packet may be a General Packet Radio Service Tunneling Protocol, GTP, packet.

[0109] In an example, the radio network packet is a Packet Data Convergence Protocol, PDCP, packet or a Service Data Adaption Protocol, SDAP, packet.

[0110] In another example, the core network node is a User Plane Function, UPF, operating in a core network communicatively connected to the network node operating in the radio access network. The first timestamp may be converted by the network node from a second timestamp that is associated with a second timing reference based on the radio grid.

[0111] Typically, the network node is a gNB operating in the radio access network.

[0112] In an example, the second timing reference and the first timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

[0113] In a further example, the second timing reference is based on Orthogonal Frequency Division Multiplexing, OFDM, symbol numbers and / or subframe indices.

[0114] Figure 9 illustrates a flowchart of a method 900 depicting exemplary operations for conducting a timestamp-based packet delay measurement in the DL by a network node operating in a RAN according to one embodiment. Operations of the network node, which may be implemented using the structure of the block diagram of Figure 19, will now be discussed with reference to the flowchart according to some embodiments. For example, one or more modules (e.g., software based algorithms or programming code) may be stored in memory 1904 of Figure 19, and these modules may provide instructions so that when the instructions of a module are executed by respective processing circuitry 1902, the network node 1900 performs respective operations of method 900. In some embodiments, memory 1904 may store the disclosed software based algorithm as one or more of application programs.

[0115] In block 901 , the method 900 includes receiving, by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference. In some embodiments, the first timestamp is contained in the header of the originating network packet. In some embodiments, the originating network packet is a GTP packet. In some embodiments, the network node is a gNB operating in the radio access network.

[0116] In block 902, the method 900 includes converting, by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN. In some embodiments, the second timestamp has been converted by the network node from a first timestamp that is associated with a first timing reference based on UTC. In some embodiments, the first timing reference and the second timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions. In some embodiments, wherein the second timing reference is based on OFDM symbol numbers and / or subframe indices.

[0117] In block 903, the method 900 includes inserting, by the network node, the second timestamp in a header of a radio network packet that encapsulates and includes at least a portion of the originating network packet. In some embodiments, the radio network packet is a PDCP packet or a SDAP packet.

[0118] In block 904, the method 900 includes sending, by the network node, the radio network packet to a user equipment, UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received core network packet with respect to the radio grid wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as at least a portion of the originating network packet traverses between the originating network node and the UE. In some embodiments, the originating network node is a U PF operating in a core network communicatively connected to the network node operating in the radio access network.

[0119] In some embodiments, the first timing reference is defined via configurable rules used to generate the first timestamp. In some embodiments, the first timing reference is configured for a timestamp calculation that is aligned with a radio network period boundary for a reference carrier. In some embodiments, the first timestamp represents a time difference between a time when the packet is generated and the first timing reference. In some embodiments, the first timing reference corresponds to a system frame number, SFN, time period boundary for a reference carrier.

[0120] Figure 10 illustrates a flowchart of a method 1000 depicting exemplary operations for conducting a timestamp-based packet delay measurement in the UL by a network node operating in a RAN according to one embodiment. Operations of the network node, which may be implemented using the structure of the block diagram of Figure 19, will now be discussed with reference to the flowchart according to some embodiments. For example, one or more modules (e.g., software based algorithms or programming code) may be stored in memory 1904 of Figure 19, and these modules may provide instructions so that when the instructions of a module are executed by respective processing circuitry 1902, the network node 1900 performs respective operations of method 1000. In some embodiments, memory 1904 may store the disclosed software based algorithm as one or more of application programs.

[0121] In block 1001 , the method 1000 includes receiving, by the network node from a UE via a radio access network link interface a radio network packet that includes a first timestamp associated with a first timing reference that is based on a radio grid of the RAN. In some embodiments, the first timestamp is contained in the header of the radio network packet. In some embodiments, the radio network packet is a PDCP packet or a SDAP packet. In some embodiments, the network node is a gNB operating in the radio access network. In some embodiments, the first timing reference is based on OFDM symbol numbers and / or subframe indices.

[0122] In block 1002, the method 1000 includes converting, by the network node, the first timestamp into a second timestamp associated with a second timing reference. In some embodiments, the second timestamp is converted by the network node from a first timestamp that is associated with a first timing reference based on the radio grid. In some embodiments, the first timing reference and the second timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

[0123] In block 1003, the method 1000 includes inserting, by the network node, the second timestamp in a header of a core network packet that encapsulates and includes at least a portion of the radio network packet. In some embodiments, the core network packet is a GTP packet.

[0124] In block 1004, the method 1000 includes sending, by the network node, the core network packet to a core network node via a core network link interface, wherein the second timestamp enables the core network node to conduct an end-to- end packet delay determination of the received radio network packet with respect to the second timing reference, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses between the core network node and the UE. In some embodiments, the core network node is a UPF operating in a core network communicatively connected to the network node operating in the radio access network.

[0125] In some embodiments, the first timing reference is defined via configurable rules used to generate the first timestamp. In some embodiments, the first timing reference is configured for a timestamp calculation that is aligned with a radio network period boundary for a reference carrier. In some embodiments, the first timestamp represents a time difference between a time when the packet is generated and the first timing reference. In some embodiments, the first timing reference corresponds to a system frame number, SFN, time period boundary for a reference carrier.

[0126] In many cellular communication systems, radio resources are organized at PHY layer level in terms of (radio) frames. Each frame has a duration of Tframe (e.g., 10 ms in 5G NR) and includes a number of subframes (e.g., 10 in 5G NR) each with duration Tsubframe (e.g., 1 ms in 5G NR).

[0127] Each slot is divided into a number of OFDM symbols (e.g., in 5G NR, 14 OFDM symbols if normal cyclic prefix (NOP) is used, or 12 OFDM symbols if extended cyclic prefix is used (ECP)). The duration of an OFDM symbol and the corresponding cyclic prefix (CP) may be the same for all OFDM symbols or may be different for some OFDM symbols. For example, in 5G NR using SCS=15 kHz with NCP, the 1st OFDM symbol and 8th OFDM symbol in a slot have slightly longer CPs than the remaining symbols in the same slot.

[0128] In some embodiments, the radio frames are numbered using an index called the system frame number (SFN). In 5G NR, the SFN can include 1024 values (e.g., 0 to 1023). Thus, an SFN cycle comprises 1024 radio frames. The SFN cycle starts at the beginning of the first frame with the first SFN index (e.g., the frame with SFN=0 in 5G NR) and ends at the end of the frame with the last SFN index (e.g., the frame with SFN=1023 in 5G NR). Different cycles, sub-cycles, and super-cycles may be defined in a similar manner (e.g., by taking different reference starting / end points; by taking less than 1024 frames; or by taking more than 1024 frames, respectively).

[0129] In 3GPP terminology, the combination of SCS and cyclic prefix (CP) length is referred to as numerology.

[0130] As presented above, the disclosed subject matter includes a method for exploiting the available radio synchronization as a timing reference used for expressing end-to-end (E2E) delay timestamps carried by a higher radio layer (e.g., PDCP), thereby relaxing absolute synchronization requirements for the UE. The proposed timestamp indicates a time when the packet was generated in the origin node (e.g., a core NW node in the DL, or the UE in the UL) and is expressed according to a time reference that is common to both the radio transmitter and receiver nodes (e.g., SFN grid). In some embodiments, the receiver compares the timestamp in the packet to its local radio timing reference to derive the E2E packet delay.

[0131] In multi-carrier cases, a UE may use different radio numerologies and carrier time offsets on different Component Carriers (CCs) and the OFDM symbol lengths may differ. There are also handover cases where a packet generated by a node is transmitted by another radio node.

[0132] The higher radio layers in a gNB or a UE are generally unaware if (parts of) a PDCP or RLC packet will eventually be transmitted on one CC or another CC.

[0133] There are also cases where carrier aggregation (CA) is being reconfigured and it becomes even more uncertain whether a certain PDCP packet will end up being transmitted on a different CC than the one configured at the time when the timestamp based on the radio reference was generated.

[0134] In some embodiments, the disclosed subject matter provides an extension of the methodology presented above to allow for measuring E2E one-way packet delay in a 3GPP system with carrier aggregation and multiple radio numerologies. The present disclosure further pertains to different subsystems (e.g., RAN, Core network, UE, etc.) which may not be accurately synchronized to each other.

[0135] The present disclosure includes providing configurable rules for defining an radio timing reference used for timestamp generation. In its most general form, the rule comprises configuring a timing reference for timestamp calculation that is aligned with the SFN period boundary for a well-defined reference carrier. The timestamp sampling granularity may also depend on the reference carrier. In some cases, the carrier used for time reference is explicitly or implicitly signaled and it does not necessarily need to match the actual carrier used for transmitting the packet.

[0136] The disclosed subject matter includes a method for defining a radio time reference T_{ref}A{radio} and a time interval used for timestamp generation, where the timestamp represents the time difference between a given event (e.g., time at which the packet was generated) and the radio time reference. In some embodiments, the time reference T_{ref}A{radio} corresponds to the SFN time boundary for a reference carrier. The reference carrier may be explicitly signaled as part of the timestamp signaling, or it is obtained from a rule. The present disclosure provides a number of advantages of the proposed solution. Notably, the disclosed subject matter allows for the tracking of packets communicated between ingress points and egress points of the 3GPP system, with limited complexity and overhead in the RAN. The present disclosure removes dependency between the process for timestamp generation and the actual carrier used for timestamp message transmission, enabling accurate packet delay measurement in one of a multicarrier operation, during reconfigurations, and even during mobility with packet forwarding across nodes.

[0137] The present disclosure includes a method for defining an radio time reference T_{ref}A{radio} and time interval used for timestamp generation. For example, the timestamp may represent the time (i.e. , a timing offset) since the time reference. That is, if TO denotes the time offset since T_{ref}A{radio}, then the timestamp represents time TO using the time reference T_{ref}A{radio}, and T_{ref}A{radio} + TO represents the time in a different time reference (e.g. UTC). This is illustrated in diagram 1100 in Figure 11.

[0138] In some embodiments T_{ref}A{radio}corresponds to the time of the start of a specific time period of the radio resources. For example, it may correspond to the start of an SFN cycle (i.e., the starting point of a radio frame with SFN index 0) or the start of the Nth SFN cycle. Note that in this case, the radio time reference T_{ref}A{radio}\ is updated every SFN cycle. That is, once a new SFN cycle begins, T_{ref}A{radio} corresponds to the start of that SFN cycle. This is illustrated in diagram 1200 of Figure 12. Notably, the UE can be made aware of the start of a new SFN cycle in different ways including i) receiving signals and transmissions from the base station, or ii) by means of a definition that relates the SFN cycles to some external time reference. For example, the external time reference may be a UTC reference if the UE has access to UTC, e.g., from a global navigation satellite system (GNSS). However, the manner in which the UE determines the start of a new SFN cycle is not important for the present disclosure.

[0139] In some embodiments, TO corresponds to the time that has passed since T_{ref}A{radio}. For example, TO may be represented in terms of seconds, milliseconds, or in terms of some other unit such as OFDM symbols, subframes, or slots (or several of such units). The units may be predefined or configured (e.g., by means of RRC signaling), and rounded or truncated according to some explicit or implicit rule. This is illustrated in diagram 1300 of Figure 13.

[0140] The radio time reference T_{ref}A{radio} is related to a specific carrier (i.e. , the reference carrier, used for defining the time reference) and its radio frame structure. A UE may be configured to transmit or receive on multiple carriers, each of the carriers possibly defining a different radio time reference. Processing in a lower layer is typically transparent to higher layers. For example, the PDCP layer is largely unaware about details related to the carrier(s) used for transmission of a given PDCP PDU. In fact, a PDCP PDU may be transmitted over multiple carriers. Consequently, there may be some ambiguity in the definition of the radio time reference and in turn in any measurement that relies on the use of a radio time reference (e.g., to generate a timestamp). The present disclosure resolves this ambiguity, which is illustrated in diagram 1400 of Figure 14. Specifically, Figure 14 illustrates that measurement of a same time using two radio time references (e.g., from two different carriers), T_{ref,\ A}A{radio} and T_{ref,\ B}A{radio}. The time offsets from the two radio time references (e.g., TO, A and TO,B in Figure 14) are different. Notably, the same principle is applicable for transmissions using a set of frequency resources other than a carrier (e.g., a cell, a BW part, a sub-carrier, a S-SSB BW, etc.).

[0141] In the methods disclosed herein, the reference carrier may be determined independently of the carrier used for the transmission of the packet. For example, the carrier may be pre-determined using a rule (e.g., the primary carrier is used; the first configured carrier is used; etc.). The carrier may also be configured by the NW (e.g., by means of RRC signaling).

[0142] Further, the carrier may be determined by the node that generates the time stamp (e.g., the NW or the UE, for example, based on its own implementation). A corresponding indication (e.g., a carrier index and / or cell identity) may be signaled together with the timestamp. Since the reference carrier is expected to be stable over long periods of time, its signaling may occur at a larger time periodicity than the actual associated timestamp.

[0143] The present disclosure further provides examples of the use of the time reference and timestamps. For instance, the radio time reference is used to generate time stamps which are included in a packet (e.g., a data packet; a packet carrying control information; etc.). The PDCP layer is used here as an example of the layer in which a timestamp could be introduced. The present disclosure is applicable to other layers too. In some embodiments, the timestamp included in the packet includes the time offset (TO). The radio time reference T_{ref}A{radio} is known by both UE and NW.

[0144] In DL communications, the radio time reference T_{ref}A{radio}is used by the network (e.g., a gNB) to generate a timestamp that is added to a packet (e.g., a PDCP PDU) transmitted in the DL. Possible examples of the time represented by the timestamp include a timestamp that represents a specific time (TDL,1) in the DL processing (e.g., the time at which the packet arrives at / departs from a given layer; the time at which the packet is processed; etc.). Further, the timestamp included in the PDCP packet may be derived from a second timestamp added earlier to a packet by a core network node (e.g., the UPF in the CN may add a second timestamp when transmitting a packet to the gNB). For example, the gNB may generate the first timestamp (e.g., based on T_{ref}A{radio}) by converting a second timestamp (which was generated based on a different reference).

[0145] After receiving the packet, the UE uses the radio time reference T_{ref}A{radio} to compute the time elapsed since (TDL,1). For example, the UE may receive one or several transmissions from the network and processes the transmissions to recover the PDCP PDU. The UE may use the radio time reference T_{ref}A{radio} to determine the time (TDL,2) at which the PDCP PDU is available (e.g., delivered to the higher layer). The time TDL,2 may be used to compute the elapsed time TDL= TDL,2 - TDL,1 .

[0146] In UL communications, the radio time reference T_{ref}A{radio} is used by the UE to generate a timestamp that is added to a transmitted packet (e.g., a PDCP PDU). The time that the timestamp represents is not important, but possible examples include a timestamp representing a specific time (TUL,1) in the UL processing (e.g., the time at which the packet arrives at / departs from a given layer; the time at which the packet is processed; etc.)

[0147] After receiving the packet, the network (e.g., a gNB) uses the radio time reference T_{ref}A{radio} to compute the time elapsed since (TUL,1). For example, the network may receive one or several transmissions from the UE and process these transmissions to recover the PDCP PDU. Possible examples of the use of the timestamp include: i) the network may use T_{ref}A{radio} to determine the time (TUL,2) at which the PDCP PDU is available (e.g., delivered to the higher layer). It may further compute the elapsed time TDL= TDL,2 - TDL, 1 .

[0148] Notably, the timestamp (e.g., based on T_{ref}A{radio}) included in the received PDCP packet may be used to derive a second timestamp (e.g., based on a different time reference). The second timestamp may be added to a packet sent by the gNB to a core network node (e.g., to the UPF in the CN).

[0149] As described above, TO is the time offset since T_{ref}A{radio} and may be indicated in terms of some unit of time. In some embodiments, the duration of the unit may depend on some characteristic associated with the carrier. For example, on the numerology used in that carrier. Notably, in 5G NR the numerology is defined per BWP (bandwidth part) and not per carrier). For example, in 5G NR each SFN cycle comprises 1024 radio frames, each of them including 10 subframes. Each subframe contains a number of slots that depends on the subcarrier spacing and the number of OFDM symbols per slot depends on the CP duration (e.g., normal CP (NCP) or extended CP (ECP)).

[0150] It is illustrated in Figure 15 which depicts the indexing of OFDM symbols, wherein one 30 kHz slot with 14 OFDM symbols is equivalent to half a 15 kHz slot with 7 OFDM symbols. As shown in Figure 11 , for 30 kHz, integer numbers are used, while for 15 kHz, odd integers are used.

[0151] As illustrated in diagram 1600 of Figure 16, if TO indicates the number of OFDM symbols (using 30 kHz symbol duration as a reference) using the indexing in Figure 15, the same timing reference is obtained when applying offset TO = 9 irrespective of whether a 15 or 30 kHz is used in the reference carrier.

[0152] If the time offset to be signaled exceeds the signaling range of the timestamp (i.e. , overflow), ambiguity occurs in the signaling. In one example, the timestamp takes a pre-defined code to signal overflow of the allowed signaling range (e.g., all bits in the binary representation of the timestamp equal 1). The receiver recognizes the overflow code and processes the timestamp accordingly and differently from other timestamps that are not marked for overflow. For example, overflow-marked timestamps contribute with a pre-defined value in the packet delay histogram, or they are excluded from packet delay statistics calculation.

[0153] In some embodiments, the carriers that a UE may use for defining a time reference may change. For example, i) the UE may be configured with a new set of carriers (e.g., new carriers are added, some old carriers are removed), ii) the UE may change serving base station from the network (e.g., the UE may handover from a source gNB to a target gNB), and / or iii) the connection of the UE may fail and the UE may be forced to re-connect to the network (e.g., radio link failure; cell re-selection; RRC re-establishment), possibly using new carriers.

[0154] The timestamping of packets may be run independently of these operations. For example, At time T1 , a packet P1 arrives at the PDCP of a UE for UL transmission. A timestamp, generated using T_{ref,A}A{radio} associated with reference carrier A, is added to the packet. At time Tchange > T1 , carrier B becomes the reference carrier and the radio time reference becomes T_{ref,B}A{radio}. At time T2 > Tchange, a packet P2 arrives at the PDCP of a UE for UL transmission. P2 is correctly received at the gNB at time T3, whereas P1 is correctly received at the gNB at time T4, with T4>T1 (e.g., due to retransmissions of P1). Notably, the gNB would have no reliable means to know what packet was generated with which radio time reference.

[0155] In some embodiments, an identifier is used to identify that the carrier used for defining the time reference has changed or been updated. The identification may include for example: i) an ID of the carrier used to define the time reference T_{ref}A{radio}, ii) a counter that is increased every time a new carrier is used for defining a new time reference. For example, carrier A is used until time Ta for defining the timing reference T_{ref}A{radio}=T_{ref,A}A{radio} and this is indicated by a field ‘00’ transmitted with the time stamp. At time Ta, the network changes the configuration so that carrier B is used for defining the timing reference T_{ref}A{radio}=T_{ref,B}A{radio}. For new timestamps generated with the new reference, the field value is changed to ‘0T (i.e., increased by ‘T). At time Tb, the network changes the configuration so that carrier C is used for defining the timing reference T_{ref}A{radio}=T_{ref,C}A{radio}. For new timestamps generated with the new reference, the field value is changed to ‘10’ (i.e., increased by T in binary). Note that in this case, if carrier C is the same as carrier A, the value does not return to ‘00’ but changes to ‘10’.

[0156] In some embodiments, a field (e.g., a single bit) in the packet can be used to indicate that the carrier has changed. For example, the value may be set to T in the first packet after a change; or its value may be flipped (from ‘0’ to ‘T and from T to ‘0’) in the first packet after a change.

[0157] Using radio signals as time references may incur in some ambiguity depending on the relative position of the nodes. For example, if a DL signal is used for defining a common time reference between the gNB and a UE, the propagation time may result in some ambiguity. For example, if the gNB transmits a signal in the DL at time T, the signal will be received by the UE at time T’=T+Tprop, where Tprop corresponds to the propagation time between the base station and the UE. The magnitude of this ambiguity depends on the distance between base station and UE. Whether the ambiguity has an important effect on the time measurements derived from the timestamps also depends on the target accuracy. In some cases, it may be negligible and in other cases it may not.

[0158] One way to remove or reduce this ambiguity is to apply a precompensation when determining a time measurement (e.g., a timestamp or a measurement derived from a timestamp). For example, if the UE is aware of T_{prop} (or an approximate value, such as half of the timing advance that it uses when performing UL transmissions), the UE can derive the timestamp by determining the offset from T_{ref}A{radio}-T_{prop}. If the base station or UE are aware of T_{prop} (or an approximate value), base station or UE can apply the compensation when performing a calculation involving a timestamp. For example, the UE may add T_{prop} to a timestamp generated by the network, and / or the network may remove T_{prop} from a timestamp generated by the network.

[0159] In some cases (e.g., in FDD carriers), the UL and DL timings may not even be aligned at the base station. Thus, a radio time reference obtained from a DL signal but used to determine a timestamp related to an UL transmission includes an ambiguity term. The base station and / or the UE may apply compensations like the ones described above to compensate for this misalignment.

[0160] Unless the context clearly requires otherwise, throughout the description and the embodiments, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to." As used herein, the terms "connected," "coupled," or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, electromagnetic, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or," in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

[0161] These and other changes can be made to the technology in light of the following detailed description. While the description describes certain examples of the technology, and describes the best mode contemplated, no matter how detailed the description appears, the technology can be practiced in many ways. Details of the system may vary considerably in its specific implementation, while still being encompassed by the technology disclosed herein. As noted above, particular terminology used when describing certain features or aspects of the technology should not be taken to imply that the terminology is being redefined herein to be restricted to any specific characteristics, features, or aspects of the technology with which that terminology is associated. In general, the terms used in the following embodiments should not be construed to limit the technology to the specific examples disclosed in the specification, unless the Detailed Description section explicitly defines such terms. Accordingly, the actual scope of the technology encompasses not only the disclosed examples, but also all equivalent ways of practicing or implementing the technology under the embodiments.

[0162] In the description above, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of implementations of the disclosed technology. It will be apparent, however, to one skilled in the art that embodiments of the disclosed technology may be practiced without some of these specific details.

[0163] Figure 18 shows a UE 1800 in accordance with some embodiments. The UE 1800 presents additional details of some embodiments of the UE of Figure 1. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage / playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop- embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0164] Figure 19 shows a network node 1900 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e.g., O-RU, O-DU, O-CU).

[0165] Figure 20 is a block diagram illustrating a virtualization environment 2000 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 2000 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 2000 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an O-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host

[0166] Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope thereof.

Claims

CLAIMS1. A method performed by a network node (1900) operating in a radio access network, RAN, for enabling a timestamp-based packet delay measurement in downlink, the method comprising: receiving (901), by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference; converting (902), by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; inserting (903), by the network node, the second timestamp in a radio network packet that encapsulates and includes at least a portion of the originating network packet; and sending (904), by the network node, the radio network packet to a user equipment (1800), UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received originating network packet with respect to the radio grid wherein the end-to- end packet delay is a delay corresponding to a time period that transpires as at least the portion of the originating network packet traverses from an originating network node in the originating network to the UE.

2. A method in accordance with claim 1 , wherein the first timestamp is comprised in the header of the originating network packet.

3. The method in accordance with any of the previous claims, wherein the originating network packet is a General Packet Radio Service Tunneling Protocol, GTP, packet.

4. The method in accordance with any of the previous claims, wherein the radio network packet is a Packet Data Convergence Protocol, PDCP, packet or a Service Data Adaption Protocol, SDAP, packet.

5. The method in accordance with any of the previous claims, wherein the originating network node is a User Plane Function, UPF, operating in a core network communicatively connected to the network node operating in the radio access network.

6. The method in accordance with any of the previous claims, wherein the second timestamp has been converted by the network node from a first timestamp that is associated with a first timing reference based on Coordinated Universal Time, UTC.

7. The method in accordance with any of the previous claims, wherein the network node is a gNB operating in the radio access network.

8. The method in accordance with any of the previous claims, wherein the first timing reference and the second timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

9. The method in accordance with any of the previous claims, wherein the second timing reference is based on Orthogonal Frequency Division Multiplexing, OFDM, symbol numbers and / or subframe indices.

10. A network node arranged for operating in a radio access network, RAN, for enabling a timestamp-based packet delay measurement in downlink, said network node comprising: processing circuitry (1902); and at least one memory (1904) storing instructions executable by the processing circuitry to perform operations to: receiving (901), by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference; converting (902), by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN;inserting (903), by the network node, the second timestamp in a radio network packet that includes at least a portion of the originating network packet; and sending (904), by the network node, the radio network packet to a user equipment (1800), UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received originating network packet with respect to the radio grid wherein the end-to- end packet delay is a delay corresponding to a time period that transpires as at least a portion of the originating network packet traverses from an originating network node in the originating network to the UE.

11. The network node in accordance with claim 10, wherein the at least one memory stores further instruction executable by the processing circuitry to perform further operations comprising operations of any one of claims 2 to 9.

12. A computer program product comprising a non-transitory computer readable medium storing instructions executable by processing circuitry of a network node (1900), the instructions executed by the processing circuitry (1902) to perform operations comprising: receiving (901), by the network node via an originating network link interface, an originating network packet that includes a first timestamp associated with a first timing reference; converting (902), by the network node, the first timestamp into a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; inserting (903), by the network node, the second timestamp in a radio network packet that includes at least a portion of the originating network packet; and sending (904), by the network node, the radio network packet to a user equipment (1800), UE, via a wireless link interface, wherein the second timestamp enables the UE to conduct an end-to-end packet delay determination of the received originating network packet with respect to the radio grid wherein the end-to- end packet delay is a delay corresponding to a time period that transpires as at leasta portion of the originating network packet traverses from an originating network node in the originating network to the UE.

13. The computer program in accordance with claim 12, wherein the non- transitory computer readable medium storing further instruction executable by the processing circuitry of the network node, the further instructions executed by the processing circuitry to perform further operations comprising operations of any one of claims 2 - 9.

14. A method performed by a network node (1900) operating in a radio access network, RAN, for conducting a timestamp-based packet delay measurement in the uplink, the method comprising: receiving (1001), by the network node from a user equipment (1800), UE, via a radio access network link interface a radio network packet that includes a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; converting (1002), by the network node, the second timestamp into a first timestamp associated with a first timing reference; inserting (1003), by the network node, the first timestamp in a core network packet that includes at least a portion of the radio network packet; and sending (1004), by the network node, the core network packet to a core network node via a core network link interface, wherein the first timestamp enables the core network node to conduct an end-to-end packet delay determination of the received radio network packet with respect to the first timing reference, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses from the UE to the core network node.

15. The method in accordance with claim 14, wherein the second timestamp is comprised in the header of the radio network packet.

16. The method in accordance with any of the claims 14 - 15, wherein the core network packet is a General Packet Radio Service Tunneling Protocol, GTP, packet.

17. The method in accordance with any of the claims 14 - 16, wherein the radio network packet is a Packet Data Convergence Protocol, PDCP, packet or a Service Data Adaption Protocol, SDAP, packet.

18. The method in accordance with any of the claims 14 - 17, wherein the core network node is a User Plane Function, UPF, operating in a core network communicatively connected to the network node operating in the radio access network.

19. The method in accordance with any of the claims 14 - 18, wherein the first timestamp is converted by the network node from a second timestamp that is associated with a second timing reference based on the radio grid.

20. The method in accordance with any of the claims 14 - 19, wherein the network node is a gNB operating in the radio access network.21 . The method in accordance with any of the claims 14 - 19, wherein the second timing reference and the first timing reference utilize at least one of different timing units, different quantization values, and / or different timing resolutions.

22. The method in accordance with any of the claims 14 - 19, wherein the second timing reference is based on Orthogonal Frequency Division Multiplexing, OFDM, symbol numbers and / or subframe indices.

23. A network node (1900) arranged for operating in a radio access network, RAN, for enabling a timestamp-based packet delay measurement in uplink, said network node comprising: processing circuitry (1902); and at least one memory (1904) storing instructions executable by the processing circuitry to perform operations to: receiving (1001), by the network node from a user equipment (1800), UE, via a radio access network link interface a radio network packet thatincludes a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; converting (1002), by the network node, the second timestamp into a first timestamp associated with a first timing reference; inserting (1003), by the network node, the first timestamp in a core network packet that includes at least a portion of the radio network packet; and sending (1004), by the network node, the core network packet to a core network node via a core network link interface, wherein the first timestamp enables the core network node to conduct an end-to-end packet delay determination of the received radio network packet with respect to the first timing reference, wherein the end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses from the UE to the core network node.

24. The network node in accordance with claim 23, wherein the at least one memory stores further instruction executable by the processing circuitry to perform further operations comprising operations of any one of the claims 15 - 22.

25. A computer program product comprising a non-transitory computer readable medium storing instructions executable by processing circuitry (1902) of a network node (1900), the instructions executed by the processing circuitry to perform operations comprising: receiving (1001), by the network node from a user equipment (1800), UE, via a radio access network link interface a radio network packet that includes a second timestamp associated with a second timing reference that is based on a radio grid of the RAN; converting (1002), by the network node, the second timestamp into a first timestamp associated with a first timing reference; inserting (1003), by the network node, the first timestamp in a core network packet that includes at least a portion of the radio network packet; and sending (1004), by the network node, the core network packet to a core network node via a core network link interface, wherein the first timestamp enables the core network node to conduct an end-to-end packet delay determination of the received radio network packet with respect to the first timing reference, whereinthe end-to-end packet delay is a delay corresponding to a time period that transpires as the first original data packet traverses from the UE to the core network node.

26. The computer program product in accordance with claim 25, wherein the non-transitory computer readable medium storing further instruction executable by the processing circuitry of the network node, the further instructions executed by the processing circuitry to perform further operations comprising operations of any one of claims 15 - 22.

Images