Patent Description:
Certain abbreviations that may be found in the description and/or in the Figures are herewith defined as follows:.

Latency is one of the most important Key Performance Indicators (KPIs) used to monitor quality of services perceived by end user. The services provided by E-UTRAN are based on IP blocks delivery thus from the point of view what end user perceives it is crucial to measure it as an IP latency.

One main issue at the time of this application that prevents the 3GPP community to agree on IP Latency measurement definition in DL in <NUM>, is distributed type of network when CU and DU are acting as different nodes connected via F1 interface and in addition even within CU the CP and UP may be distributed and interconnected via E1 interface.

Thus, at the time of this application there not seen to be a way to identify with such different nodes the IP blocks (bursts) in PDCP layer (CU-UP) in <NUM>. In addition, the IP latency the 3GPP is completely silent about this type of IP latency measurement in <NUM>. For example as shown in 3GPP TS <NUM> version <NUM>. <NUM> only some delay measurements related to DU monitoring like "Average delay DL air-interface chapter <NUM>. <NUM>" and "Average delay in RLC sublayer of gNB-DU chapter <NUM>. <NUM>" of 3GPP specifications are available.

Example embodiments of the invention work to address at least some of these issues.

<NPL> is a standardization discussion & decision document discussing feasibility of buffered PDCP throughput measurements.

According to a first aspect of the invention, there is provided centralized unit for a base station of a communication network, comprising:
means for communicating at least one data burst comprising at least one packet data convergence protocol protocol data unit, PDCP PDU, towards a distributed unit of the base station, wherein the communicating comprises:.

According to a second aspect of the invention, there is provided a method comprising:
communicating, by a centralized unit of a base station of a communication network, at least one data burst comprising at least one packet data convergence protocol protocol data unit, PDCP PDU, towards a distributed unit of the base station, wherein the communicating comprises:.

According to a third aspect of the invention, there is provided computer readable memory comprising program code, which when executed by a centralized unit for a base station of a communication network, causes the centralized unit to perform:
communicating at least one data burst comprising at least one packet data convergence protocol protocol data unit, PDCP PDU, towards a distributed unit of the base station, wherein the communicating comprises:.

The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent from the following detailed description with reference to the accompanying drawings, in which like reference signs are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and are not necessarily drawn to scale, in which:.

In example embodiments there is proposed at least a method and apparatus to perform identification of DL IP blocks and measuring IP latency in a DL in radio technologies including <NUM>.

A latency is one of the most important Key Performance Indicators (KPIs) used to monitor quality of services perceived by end user. The services provided by E-UTRAN are based on IP blocks delivery thus from the point of view what end user perceives it is crucial to measure it as an IP latency.

In E-UTRAN the way how to measure so called "IP Latency" per QCI in DL direction is summarized in <FIG> shows a principle of IP Latency measurement in DL as shown in chapter <NUM>. <NUM> of 3GPP TS <NUM> v16. <FIG> shows a principle of IP Latency measurement in DL using time in ms. as in item <NUM> of <FIG>. As shown in item <NUM> of <FIG> data arrives to empty DL buffer. As shown in item <NUM> of <FIG> first data is transmitted to the UE by the eNodeB. <FIG> shows indications of successful transmission buffer not empty, failed transmission (block error), successful transmission (buffer empty), and no transmission, buffer not empty due to contention. As shown in item <NUM> of <FIG> Latency_DL= ∑T_Lat_DL (s) / # samples.

As similarly indicated above one main issue that prevents the 3GPP community to agree on IP Latency measurement definition in DL in <NUM> is distributed type of network when CU and DU are acting as different nodes connected via F <NUM> interface and in addition even within CU the CP and UP may be distributed and interconnected via E1 interface. Thus, the PDCP layer located in CU-UP has no info about RLC and MAC layer that are in DU. Nor CU -UP is aware of segmentation of the PDCP PDUs into RLC PDUs in the DU and thus has no knowledge the given burst (may consists of couple of PDCP SDUs) is transmitted via one TTI or via couple of consequent TTIs. In other words said, the CU-UP is not able to identify the IP blocks (bursts) in similar way as E-UTRAN does for measurement of IP latency in DL as mentioned in the previous chapter <NUM>. To make CU-UP aware of the situation in DU would mean to transmit all relevant info on each time stamp transmission of the related TB from DU which is not feasible as it would overload completely the F1-U interface with such info.

Currently there is no way how to identify the IP blocks (bursts) in PDCP layer (CU-UP) in <NUM>. In addition, the IP latency the 3GPP is completely silent about this type of IP latency measurement in <NUM>. Within the 3GPP TS <NUM> only some delay measurements related to within DU monitoring like "Average delay DL air-interface chapter <NUM>. <NUM>" and "Average delay in RLC sublayer of gNB-DU chapter <NUM>. <NUM>" are available.

Example embodiments are intended to solve the problem via proposing at least a new method for identification of DL IP blocks (bursts) in CU-UP directly and measuring IP latency in DL.

Before describing the example embodiments in further detail reference is made to <FIG> shows a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced.

As shown in <FIG>, a user equipment (UE) <NUM> is in wireless communication with a wireless network <NUM>. A UE is a wireless, typically mobile device that can access a wireless network. The UE <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. Each of the one or more transceivers <NUM> includes a receiver Rx, <NUM> and a transmitter Tx <NUM>. The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like. The UE <NUM> may include an Block module <NUM> which is configured to perform the example embodiments of the invention as described herein. The Block module <NUM> may be implemented in hardware by itself of as part of the processors and/or the computer program code of the UE <NUM>. The Block module <NUM> comprising one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The Block module <NUM> may be implemented in hardware as Block module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The Block module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the Block module <NUM> may be implemented as Block module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. Further, it is noted that the Block modules <NUM>-<NUM> and/or <NUM>-<NUM> are optional. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured, with the one or more processors <NUM>, to cause the user equipment <NUM> to perform one or more of the operations as described herein. The UE <NUM> communicates with gNB <NUM> via a wireless link <NUM>.

The gNB <NUM> (NR/<NUM> Node B or possibly an evolved NB) is a base station (e.g., for LTE, long term evolution) that provides access by wireless devices such as the UE <NUM> to the wireless network <NUM>. The gNB <NUM> includes one or more processors <NUM>, one or more memories <NUM>, one or more network interfaces (N/W I/F(s)) <NUM>, and one or more transceivers <NUM> interconnected through one or more buses <NUM>. Each of the one or more transceivers <NUM> includes a receiver Rx <NUM> and a transmitter Tx <NUM>. The gNB <NUM> includes an Block module <NUM> which is configured to perform example embodiments of the invention as described herein. The Block module <NUM> may comprise one of or both parts <NUM>-<NUM> and/or <NUM>-<NUM>, which may be implemented in a number of ways. The Block module <NUM> may be implemented in hardware by itself or as part of the processors and/or the computer program code of the gNB <NUM>. Block module <NUM>-<NUM>, such as being implemented as part of the one or more processors <NUM>. The Block module <NUM>-<NUM> may be implemented also as an integrated circuit or through other hardware such as a programmable gate array. In another example, the Block module <NUM> may be implemented as Block module <NUM>-<NUM>, which is implemented as computer program code <NUM> and is executed by the one or more processors <NUM>. Further, it is noted that the Block modules <NUM>-<NUM> and/or <NUM>-<NUM> are optional. For instance, the one or more memories <NUM> and the computer program code <NUM> may be configured to cause, with the one or more processors <NUM>, the gNB <NUM> to perform one or more of the operations as described herein. Two or more gNB <NUM> may communicate using, e.g., link <NUM>. The link <NUM> may be wired or wireless or both and may implement, e.g., an X2 interface.

The one or more buses <NUM> may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like. For example, the one or more transceivers <NUM> may be implemented as a remote radio head (RRH) <NUM>, with the other elements of the gNB <NUM> being physically in a different location from the RRH, and the one or more buses <NUM> could be implemented in part as fiber optic cable to connect the other elements of the gNB <NUM> to the RRH <NUM>.

It is noted that description herein indicates that "cells" perform functions, but it should be clear that the gNB that forms the cell will perform the functions. The cell makes up part of a gNB. That is, there can be multiple cells per gNB.

The wireless network <NUM> may include a NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM>, which can comprise a network control element (NCE), and/or serving gateway (SGW) <NUM>, and/or MME (Mobility Management Entity) and/or SGW (Serving Gateway) functionality, and/or user data management functionality (UDM), and/or PCF (Policy Control) functionality, and/or Access and Mobility (AMF) functionality, and/or <NUM> Core functionality, and/or Session Management (SMF) functionality, Location Management Function (LMF), Location Management Component (LMC) and/or Authentication Server (AUSF) functionality and which provides connectivity with a further network, such as a telephone network and/or a data communications network (e.g., the Internet), and which is configured to perform any <NUM> and/or NR operations in addition to or instead of other standards operations at the time of this application. The NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM> is configurable to perform operations in accordance with example embodiments of the invention in any of an LTE, NR, <NUM> and/or any standards based communication technologies being performed or discussed at the time of this application.

The gNB <NUM> is coupled via a link <NUM> to the NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM>. The link <NUM> may be implemented as, e.g., an S1 interface or N2 interface. The NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM> includes one or more processors <NUM>, one or more memories <NUM>, and one or more network interfaces (N/W I/F(s)) <NUM>, interconnected through one or more buses <NUM>. The one or more memories <NUM> and the computer program code <NUM> are configured to, with the one or more processors <NUM>, cause the NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM> to perform one or more operations. In addition, the NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM>, as are the other devices, is equipped to perform operations of such as by controlling the UE <NUM> and/or gNB <NUM> for <NUM> and/or NR operations in addition to any other standards operations implemented or discussed at the time of this application.

The computer readable memories <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The computer readable memories <NUM>, <NUM>, and <NUM> may be means for performing storage functions. The processors <NUM>, <NUM>, and <NUM> may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples. The processors <NUM>, <NUM>, and <NUM> may be means for performing functions and other functions as described herein to control a network device such as the UE <NUM>, gNB <NUM>, and/or NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM> as in <FIG>.

It is noted that functionality(ies), in accordance with example embodiments, of any devices as shown in <FIG> e.g., the UE <NUM> and/or gNB <NUM> can also be implemented by other network nodes, e.g., a wireless or wired relay node (a. , integrated access and/or backhaul (IAB) node). In the IAB case, UE functionalities may be carried out by MT (mobile termination) part of the IAB node, and gNB functionalities by DU (Data Unit) part of the IAB node, respectively. These devices can be linked to the UE <NUM> as in <FIG> at least via the wireless link <NUM> and/or via the NCE/MME/SGW/UDM/PCF/AMM/SMF/LMF/LMC <NUM> using link <NUM> to Other Network(s)/Internet as in <FIG>.

Example embodiments can be divided into two parts First one deals with a method for identification of the IP blocks (bursts) in PDCP layer of the CU-UP. The start of new IP block (burst) is identified each time IP data arrived from <NUM> Core to empty gNB buffer. End of the burst is identified when the gNB buffer becomes empty again. The time interval the gNB buffer is not empty starts in the point in time IP data (first PDCP SDU) arrived to empty gNB buffer until last part of the burst (last PDCP SDU of the burst) has been sent via air interface to UE from DU. In case the IP block consists of one PDCP SDU the IP block starts when the first part of the PDCP SDU arrived to PDCP layer (CU-UP) its duration continues until the related PDCP PDU is sent via F1-U interface from CU-UP to DU and ends when last part of the PDCP SDU is sent via air interface to UE. In case the IP block consists of more than one consequent PDCP SDUs exactly the same methodology is applied for each PDCP SDU, i.e. the IP block starts when the first part of the first PDCP SDU arrived to PDCP layer (CU-UP) its duration continues until the related PDCP PDU is sent via F1-U interface from CU-UP to DU which overlaps with either the second PDCP SDU is kept in the PDCP layer or kept in the DU, etc. and ends when last part of the last PDCP SDU is sent via air interface to UE.

The key part of example embodiments is how to measure the time the PDCP PDU will spend in DU until its last part is sent via air interface which is proposed to be done as per equation <NUM> (Eq. <NUM>) below: <MAT> where PDCP PDU Volumej is the volume of I'th PDCP PDU frame sent from CU-UP to DU, and DU scheduling throughput is a scheduling throughput within DU measured as PDCP PDU volume sent from CU-UP divided with the time interval given as point in time the last part of the PDCP PDU sent via air interface minus point in time first part of the PDCP PDU sent from CU-UP to DU.

Second part of example embodiments deals with the IP latency measurement in <NUM> which is proposed to be has been sent via air interface from DU to UE minus point in time when first part of the first PDCP SDU of the IP block arrived to PDCP layer (CU-UP). To measure the time the PDCP PDU will spend in DU until its last part is sent via air interface is calculated based on Eq.<NUM> as above.

<FIG> shows principle of IP block (burst) identification in DL in an example for one DU. Principle of the IP block (burst) identification in an example is demonstrated in the <FIG>. It considers that transmission of the user data for the given bearer is done via one DU only. As shown in item <NUM> of <FIG> there is an NG Interface between <NUM> Core (Ng), as shown in item <NUM> of <FIG> there is CP-UP (control plane/user plane), and in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>). As shown in item <NUM> of <FIG> there is a burst start and in item <NUM> of <FIG> a burst end, with an indication of a burst duration in between. During this duration of <FIG> there is shown bursts between a PDCP-SDU and a PDCP-PDU of the CU-UP <NUM>, where a buffer is shown as empty and non-empty in between. Following the bursts there is reporting DU scheduling throughput per UE and bearer.

Number of DUs allocated for the user data transmission of the related bearer can be more than two in general. The method principle in each case follows the idea of identification of the time the PDCP PDU will spend in the related DU until its last part is sent via air interface as calculated based on Eq.<NUM> as above. As indicated in Eq. <NUM> this calculation is based on DU scheduling throughput which must be reported from DU to CU-UP via F1-U interface. As indicated above a massive and frequent F1-U message exchange between the DU and CU-UP is not feasible as it would overload the F1-U interface, therefore the Eq.<NUM> shall relay on averaged value of DU scheduling throughput. It is recommended to communicate DU scheduling throughput per a configurable time interval (e.g. hundreds of ms. ) from DU to CU-UP via F1-U interface The F1-U message exchange can be thus decreased to a reasonable number of messages per bearer per measurement period (<NUM> minutes as a default) considering hundreds of ms. as configured time interval.

<FIG> shows principle of IP block (burst) identification in DL in an example for transmission of user data for a given bearer is done via two DUs. As shown in item <NUM> of <FIG> there is Ng, as shown in item <NUM> of <FIG> there is CP-UP (control plane/user plane), in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>), and in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>). As shown in item <NUM> of <FIG> there is a burst start and in item <NUM> of <FIG> a burst end. During a duration between the burst start and the burst end of <FIG> there is shown bursts between a PDCP-SDU and a PDCP-PDU of the CU-UP <NUM>, where a buffer is shown as empty and non-empty in between. Following the bursts as shown in items <NUM> and <NUM> there is reporting DU scheduling throughput per UE and bearer for DU-<NUM> and DU-<NUM>.

<FIG> shows principle of IP Latency measurement in DL in an example for transmission of user data for a given bearer is done via one DU. As shown in item <NUM> of <FIG> there is Ng, as shown in item <NUM> of <FIG> there is CP-UP (control plane/user plane), in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>). As shown in item <NUM> of <FIG> there is a burst start and in item <NUM> of <FIG> a burst end. The burst start <NUM> begins when the CP-UP buffer becomes non-empty as shown in <FIG>. A time interval the CP-UP buffer is non-empty starts in the point in time IP data (first PDCP SDU) arrived to empty CP-UP buffer until the burst end <NUM> (last PDCP SDU of the burst) has been sent via air interface to UE from DU. Further, as shown with item <NUM> of <FIG> there is a dedicated item representing IP latency toward an end of the configurable time interval as discussed above and beginning at the burst start <NUM>. During a burst duration between the burst start and the burst end of <FIG> there is shown bursts between a PDCP-SDU and a PDCP-PDU of the CU-UP <NUM>, where a buffer is shown as empty and non-empty in between. Following the bursts as shown in item <NUM> of <FIG> there is reporting DU scheduling throughput per UE and bearer for DU-<NUM>.

<FIG> shows principle of IP Latency measurement in DL in an example for two DUs. A principle of the IP latency measurement for the given IP block (burst) in an example for transmission of the user data for the given bearer is done via two DUs is demonstrated in the <FIG>. As shown in item <NUM> of <FIG> there is Ng, as shown in item <NUM> of <FIG> there is CP-UP (control plane/user plane), in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>), and in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>). As shown in item <NUM> of <FIG> there is a burst start and in item <NUM> of <FIG> a burst end. Similar to <FIG> in <FIG> the burst start <NUM> begins when the CP-UP buffer becomes non-empty as shown in <FIG>. A start for a time interval the CP-UP buffer is non-empty begins at a time IP data (first PDCP SDU) arrives to empty CP-UP buffer to make it non-empty until the burst end <NUM> (last PDCP SDU of the burst) has been sent via air interface to UE from DU. Further, as shown with item <NUM> of <FIG> there is a dedicated IP latency item toward an end of the configurable time interval as discussed above and beginning at the burst start <NUM>.

During a duration between the burst start and the burst end of <FIG> there is shown bursts between a PDCP-SDU and a PDCP-PDU of the CU-UP <NUM>, where a buffer is shown as empty and non-empty in between. Following the bursts as shown in items <NUM> and <NUM> there is reporting DU scheduling throughput per UE and bearer for DU-<NUM> and DU-<NUM>.

In principle there are two alternatives how to get a DU scheduling throughput. First one is based on complete new implementation defined as PDCP PDU volume sent from CU-UP divided with the time interval given as point in time the last part of the PDCP PDU sent via air interface minus point in time first part of the PDCP PDU sent from CU-UP to DU. The DU scheduling throughput shall be provided per bearer and acting as an average throughput, i.e. covering all PDCP PDUs sent from CU-UP from the last reported value from DU to CU-UP. The second option is to reuse "Desired Data Rate" reported within the DL DATA DELIVERY STATUS (DDDS) according to chapter <NUM>. <NUM> in the 3GPP TS <NUM>. The Desired Data Rate is then defined as "the amount of PDCP PDU data desired to be received in a specific amount of time. The amount of time is <NUM> sec" according to chapter <NUM>. <NUM> of the same 3GPP spec.

In accordance with example embodiments a timer such as a PDCP PDU transmission timer" can be a timer a timer the formula is converted to and/or using when moving to implementation of embodiments as disclosed herein. In addition it is indicated at least in <FIG>, <FIG>, and <FIG> an easier way to bind the time interval obtained using the formula is to run such a timer.

It is noted that there can be non-limiting points for operations in accordance with an example embodiment as described herein. These non-limiting points are as follows:.

At a point <NUM> there is a start of each new IP block (burst) that can be identified each time IP data (first PDCP SDU) arrived from <NUM> Core to empty gNB buffer state, i.e., a state when PDCP buffer state related to CU UP is empty and no PDCP PDU transmission timer of the previous burst is running where the transmission timer is set individually for each PDCP PDU transmitted from CU UP to DU to the value given as ratio of the PDCP PDU volume and DU scheduling throughput representing amount of the volume of PDCP PDU level the DU is able to handle per one second and reported periodically from DU to CU UP.

As a point <NUM>, related to previous point <NUM>, a duration of each burst is evaluated from the point in time P data (first PDCP SDU) arrived from <NUM> Core to empty gNB buffer state which changes the buffer status to not empty until the point in time the gNB buffer status becomes empty again. Point <NUM> is related to points <NUM> and <NUM> above where at point <NUM> a sum of IP bursts is calculated during the measurement period. In a point <NUM>, related to point <NUM> above, IP latency of each new burst is given as difference of the point in time first PDCP PDU transmission timer related to the burst expired minus the point in time IP data (first PDCP SDU) of the burst arrived from <NUM> Core to empty gNB buffer state. Related to points <NUM> and <NUM> sum of IP latency of all the bursts in the measurement period is calculated. In addition, related to points <NUM>, <NUM> and <NUM> average IP latency on the measurement period is given aa ratio of the sum of IP latency of all the bursts in the measurement period and sum of IP bursts is calculated during the measurement period.

Example embodiments can focus on a Method for Identification of IP Blocks (Bursts) and IP Latency Measurement in <NUM>. IP burst is defined as series of PDCP SDUs (IP packets) and as the whole with certain duration. The identification when new burst starts and previous one ends is based on a global buffer status of the node. For example, if IP packet arrived to empty gNB buffer we evaluate is as a start of new burst, then when last part of the burst is sent in DL and there are not any other data waiting for transmission, we evaluate it as empty buffer - i.e. end of the burst.

In previous technologies like <NUM> as all the layers PDCP, RLC and MAC are part of the common physical node (eNB) there was easy to see from PDCP layer how it looks with RLC and MAC part to evaluate when the eNB buffer status get empty/not empty. In <NUM> the situation is completely different due to decentralization of the gNb node (CU-UP and DU are physically on different places). To communicate the buffer status of DU to CU UP on each PDCP PDU transmission would completely kill the F1 interface between CU UP and DU. That's why CU UP (PDCP layer) is not aware of situation within DU. This currently prevents to define measurement of number of IP burst in DL and IP latency delay as in <NUM>. That's why the related spec 3GPP TS <NUM> is silent about the IP latency measurement. A lot of discussions driven within 3GPP community but currently an easy and acceptable solution not found.

As can be given in example embodiments a start of new IP block (burst) is identified each time IP data arrived from <NUM> Core to empty gNB buffer. An end of the burst is identified when the gNB buffer becomes empty again. A base station such as a gNB buffer is not empty when either PDCP Buffer is not empty or at least one PDCP PDU not yet transmitted via air interface to UE from the DU see at least <FIG> and <FIG>.

The IP latency can be determined as basically a time interval between when a new IP packet arrives to an empty gNB buffer, till a first part transmitted via air interface from DU to UE, e.g., <FIG>. These embodiments at least make it possible to identify and to measure the number of IP bursts in DL and measure IP latency is the same way as defined in the 3GPP for <NUM> without any extra and huge amount of message exchange between the CU UP and DU.

The objective of this measurement is to measure IP DL latency for OAM performance observability or for QoS verification of MDT or for the QoS monitoring.

<FIG> shows a Table <NUM>: Definition for Average IP latency in the DL per QoS group in accordance with example embodiments.

As shown in Table <NUM> of <FIG> there is a definition of an average IP latency in the DL per QoS group. As shown in Table <NUM> of <FIG> this measurement is applicable for EN-DC and SA. This measurement refers to IP latency for DRBs. This measurement provides the average (arithmetic mean) time it takes to transmit first part of the IP block (burst) via air to UE from the time reception of the first part of the IP block (burst) in gNB. The measurement is done separately per QoS group. Detailed Definition: <MAT>, where explanations can be found in the table <NUM> of <FIG> as shown below.

<FIG> shows a Table <NUM>: Parameter description for IP Latency in the DL per QoS group in accordance with an example embodiment.

<FIG> shows a Figure illustrating operations for Principle measurement for IP Latency in the DL per QoS group in accordance with example embodiments. As shown in item <NUM> of <FIG> there is Ng, as shown in item <NUM> of <FIG> there is CP-UP (control plane/user plane), in item <NUM> of <FIG> there is a DU-<NUM> (distribution unit <NUM>). As shown in item <NUM> of <FIG> there is a burst start and in item <NUM> of <FIG> a burst end. The burst start <NUM> begins when the CP-UP buffer becomes non-empty as shown in <FIG>. A time interval the CP-UP buffer is non-empty starts in the point in time IP data (first PDCP SDU) arrived to empty CP-UP buffer until the burst end <NUM> (last PDCP SDU of the burst) has been sent via air interface to UE from DU. Further, as shown with item <NUM> of <FIG> there is a dedicated item representing IP latency toward an end of the configurable time interval as discussed above and beginning at the burst start <NUM>. During a burst duration between the burst start and the burst end of <FIG> there is shown item <NUM> indicating IP Block duration with a sent (I,QoSid). Following the bursts as shown in item <NUM> of <FIG> there is reporting DDR per UE and bearer for DU-<NUM>.

<FIG> shows at least a method in accordance with example embodiments which may be performed by an apparatus.

<FIG> illustrates operations which may be performed by a network device such as, but not limited to, a network node eNB/gNB <NUM> as in <FIG> or an eNB. As shown in step <NUM> of <FIG> there is communicating, by a network device of a communication network, at least one data burst comprising at least one data block towards an access node of the communication network, wherein the communicating comprises: as shown in step <NUM> of <FIG> determining, a buffer status of a buffer for communicating the at least one data block with the access node. As shown in step <NUM> of <FIG> there is, based on the determining, setting at least one value of at least one timer for each data block of the at least one data block, wherein said at least one timer is identifying at least one given time the buffer is reserved for each data block of said at least one data block. Then as shown in step <NUM> of <FIG> there is, based on at least said at least one given time, communicating the at least one data burst with the access node, wherein the at least one value of said at least one timer is determined based on a volume of each data block.

In accordance with the example embodiments as described in the paragraph above, there is receiving information relating to a scheduling throughput associated with a latency for communicating the at least one data block with the access node, wherein the at least one value of said at least one timer is determined based on the volume of each data block and on the information relating to the scheduling throughput.

In accordance with the example embodiments as described in the paragraphs above, wherein the network device comprises a distribution unit associated with a base station of the communication network.

In accordance with the example embodiments as described in the paragraphs above, wherein a duration of the at least one data burst is based on a point of time of a first data block of said at least one data burst to a point of time of a last data block of the at least one data block communicated with said distributed unit.

In accordance with the example embodiments as described in the paragraphs above, wherein the communicating is based on a calculated at least one value of said at least one timer for each data block.

In accordance with the example embodiments as described in the paragraphs above, wherein a latency of the at least one data burst is determined based on a difference of time when the first data block is transmitted from the distribution unit and a reception of the first data block of the at least one burst into an empty buffer of a base station.

In accordance with the example embodiments as described in the paragraphs above, wherein a latency of the at least one data burst is calculated based on a latency of the first data block of said at least one data block.

In accordance with the example embodiments as described in the paragraphs above, wherein a latency of the at least one data burst is calculated based on a first data block timer of said at least one timer.

In accordance with the example embodiments as described in the paragraphs above, wherein the latency is calculated with respect to the first data block reservation time.

In accordance with the example embodiments as described in the paragraphs above, wherein the latency is calculated with respect to the first data block timer.

In accordance with the example embodiments as described in the paragraphs above, wherein a combined latency is calculated based on a sum of latencies of the at least one data burst.

In accordance with the example embodiments as described in the paragraphs above, wherein an average latency is given as a ratio of the combined latency of the at least one data burst and a sum of the at least one data burst during a measurement period.

In accordance with the example embodiments as described in the paragraphs above, wherein a latency of the at least one data burst is based on a time it takes to transmit the first data block of the at least one data burst from a reception time of the first data block, wherein the measurement comprises: L(T, QoSid) = <MAT>.

In accordance with the example embodiments as described in the paragraphs above, wherein: L(T, QoSid) is an IP latency in a downlink per QoS group, averaged during time period T unit: <NUM>. ; TRec(I, QoSid) is an interval of time a given part of an IP block spent in in DU until it is transmitted; TSent(I,QoSid) is a point in time when a first part of a DL IP Block (Burst) is sent over air to UE; i is an i-th DL IP Block (burst) that arrives at a network node (e.g., base station) during time period T; I(T) is a total number of IP Block (Burst) in time period T; T is a time period during which measurements are performed; and QoSid is an identity of a QoS group.

In accordance with the example embodiments as described in the paragraphs above, wherein a start of each new IP block (burst) is identified when new IP block data spent in in DU is transmitted into empty buffer for a given DRB, wherein the buffer is considered as non empty if either some data are kept in the PDCP layer (CU-UP) and/or not sent from DU for the given DRB, wherein a time interval of a given part of the IP block (PDCP PDU i) spent in the DU until it is sent to UE is estimated as TPDCP PDUiDU = PDCP PDUiVolume/DDR, wherein PDCP PDUivolume is volume of the i-th PDCP PDU and DDR is the latest Desired Data Rate reported within the DL DATA DELIVERY STATUS (DDDS) from DU.

In accordance with the example embodiments as described in the paragraphs above, wherein a start of each new IP block (burst) is identified when new data arrived into empty buffer for a given DRB, wherein the buffer is considered as non empty if either some data are kept in the PDCP layer (CU UP) and/or not sent from DU to UE for the given DRB, and wherein a time interval a given part of an IP block spends in the DU until transmitted is estimated as TPDCP PDUiDU = PDCP PDUiVolume/DDR where PDCP PDUiVolurne is volume of the i-th PDCP PDU and DDR is the latest Desired Data Rate reported within the DL DATA DELIVERY STATUS (DDDS), and wherein an end of IP block (burst) is identified when last portion of the data sent over air to UE which empties the buffer for the given DRB.

In accordance with the example embodiments as described in the paragraphs above, wherein communicating the at least one data burst to the distribution unit comprises decreasing a number of the at least one data block to the distribution unit per bearer per measurement period.

In accordance with the example embodiments as described in the paragraphs above, wherein the measurement period comprises a preconfigured time interval based on hundredths or thousandths of seconds.

In accordance with the example embodiments as described in the paragraphs above, wherein the at least one data burst is received from an access and mobility management function associated with a base station of the communication network.

A non-transitory computer-readable medium (Memory(ies) <NUM> of <FIG>) storing program code (Computer Program Code <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>), the program code executed by at least one processor (Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>) to perform the operations as at least described in the paragraphs above.

In accordance with an example embodiment as described above there is an apparatus comprising: means for communicating (one or more transceivers <NUM>, Memory(ies) <NUM>, Computer Program Code <NUM> and/or Block Module <NUM>-<NUM>, and Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>), by a network device (eNB/gNB <NUM> as in <FIG>) of a communication network(Network <NUM> as in <FIG>), at least one data burst comprising at least one data block towards an access node of the communication network, wherein the communicating comprises: means for determining (one or more transceivers <NUM>, Memory(ies) <NUM>, Computer Program Code <NUM> and/or Block Module <NUM>-<NUM>, and Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>), a buffer status of a buffer for communicating the at least one data block with the access node. Based on the determining, means for setting (one or more transceivers <NUM>, Memory(ies) <NUM>, Computer Program Code <NUM> and/or Block Module <NUM>-<NUM>, and Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>) at least one value of at least one timer for each data block of the at least one data block, wherein said at least one timer is identifying at least one given time the buffer is reserved for each data block of said at least one data block; and means, based on at least said at least one given time, for communicating (one or more transceivers <NUM>, Memory(ies) <NUM>, Computer Program Code <NUM> and/or Block Module <NUM>-<NUM>, and Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>) the at least one data burst with the access node, wherein the at least one value of said at least one timer is determined based on a volume of each data block.

In the example aspect according to the paragraph above, wherein at least the means for communicating, determining, and setting comprises a non-transitory computer readable medium [Memory(ies) <NUM> as in <FIG>] encoded with a computer program [Computer Program Code <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>] executable by at least one processor [Processor(s) <NUM> and/or Block Module <NUM>-<NUM> as in <FIG>].

The method proposed in accordance with example embodiments is beneficial, because it keeps the logic of IP Latency in DL in <NUM> in the same manner as in E-UTRAN on one side and it also keeps some extra message needed for this method on F1-U interface on minimum possible level. Regarding the communication of the DU scheduling throughput as an average value per a configurable time interval (e.g. hundreds of ms. ) from DU to CU-UP via F1 -U interface and not per each burst following the logic how IP latency is defined, which is also an averaged latency, it shall not impact the precision of the obtained latency values using this method.

The method proposed in accordance with example embodiments allows to obtain quite very detailed picture of the situation inside the DU about the time stamp when the each PDCP PDU are transmitted via air interface to UE without any information on the time stamp transmitted from DU to CU UP. What may only be needed is DU scheduling throughput reported from DU to CU UP which is reported with low frequency. Last but not least is that example embodiments solves a real world issue seen as a gap in 3GPP.

Further, in accordance with example embodiments there is circuitry for performing operations in accordance with example embodiments as disclosed herein. This circuitry can include any type of circuitry including content coding circuitry, content decoding circuitry, processing circuitry, image generation circuitry, data analysis circuitry, etc.). Further, this circuitry can include discrete circuitry, application-specific integrated circuitry (ASIC), and/or field-programmable gate array circuitry (FPGA), etc. as well as a processor specifically configured by software to perform the respective function, or dual-core processors with software and corresponding digital signal processors, etc.). Additionally, there are provided necessary inputs to and outputs from the circuitry, the function performed by the circuitry and the interconnection (perhaps via the inputs and outputs) of the circuitry with other components that may include other circuitry in order to perform example embodiments as described herein.

In accordance with example embodiments of the invention as disclosed in this application this application, the "circuitry" provided can include at least one or more or all of the following:.

In accordance with example embodiments, there is adequate circuitry for performing at least novel operations as disclosed in this application, this 'circuitry' as may be used herein refers to at least the following:.

The term "circuitry" would also cover, for example and if applicable to the particular claim element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or other network device.

In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

Embodiments may be practiced in various components such as integrated circuit modules.

The word "exemplary" as may be used herein is intended to mean "serving as an example, instance, or illustration.

Claim 1:
A centralized unit for a base station of a communication network, comprising:
means for communicating (<NUM>) at least one data burst comprising at least one packet data convergence protocol protocol data unit, PDCP PDU, towards a distributed unit of the base station, wherein the communicating (<NUM>) comprises:
determining (<NUM>) a buffer status of a buffer of the centralized unit for communicating the at least one PDCP PDU with the distributed unit;
setting (<NUM>), based on the determining (<NUM>), at least one value of at least one timer for each PDCP PDU of the at least one data burst, wherein said at least one timer is at least one PDCP PDU transmission timer identifying at least one given time a buffer of the distributed unit is reserved for each PDCP PDU of said at least one data burst, wherein the at least one value of said at least one timer is determined according to: <MAT> wherein
TPDCP PDUiDU is a value of a timer associated with an i-th PDCP PDU frame sent from a user plane part of the centralized unit to the distributed unit,
PDCP PDU Volumei is a volume of the i-th PDCP PDU frame, and
DU scheduling throughput is a scheduling throughput within the distributed unit measured as PDCP PDU volume sent from the user plane part of the centralized unit divided by a time interval between sending of a first part of the PDCP PDU from the user plane part of the centralized unit to the distributed unit and sending of a last part of the PDCP PDU via an air interface of the distributed unit; and
communicating (<NUM>), based on at least said at least one given time, the at least one data burst with the distributed unit.