TECHNICAL FIELD

The present disclosure relates generally to communications, and more particularly, to wireless communications and related wireless devices and network nodes.

BACKGROUND

The next generation (NG) architecture comprises a NG-RAN including a set of 5G/NG base stations (gNBs) connected to the 5G core network (5GC) through the NG. A gNB can support frequency division duplex (FDD) mode, time division duplex (TDD) mode, or dual mode operation. The gNBs can be interconnected through a logical interface, Xn. A gNB may include a Central Unit, (gNB-)CU, and one or a plurality of Distributed Units, (gNB-)DUs.

The current 5G Radio Access Network (NG-RAN) architecture as e.g. described in TS 38.401 is illustrated in FIG. 1.

A CU may be regarded as a logical node or unit that includes a (first) subset gNB functions, such as Transfer of user data, Mobility control, Radio access network sharing, Positioning, Session Management. The CU controls the operation of DUs over a front-haul (Fs) interface.

A DU may be regarded as logical node or unit that includes a (second) subset of the gNB functions, depending on a chosen (functional) split between the first subset and second subset of gNB functions. Its operation is controlled by the CU.

A gNB-CU connects to gNB-DUs each via a Fl interface. One gNB-DU may be connected to only one gNB-CU, but a gNB-CU may control one or a plurality of gNB-DUs.

NG, Xn, and Fl may be regarded as logical interfaces (i.e. as providing interconnection of logical nodes, wherein a logical node encompasses a set of functions e.g. as defined in appropriate standard documents). For NG-RAN, the NG and Xn-C interfaces for a gNB can include a gNB-CU and gNB-DUs, and the NG and Xn-C interfaces can terminate in the gNB- CU. For EN (E-UTRAN)-DC, Sl-U, and X2-C interfaces for a gNB including a gNB-CU and gNB-DUs, can terminate in the gNB-CU. The gNB-CU and connected gNB-DUs may only be visible to other gNBs and the 5GC as a gNB. The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, including the NG-RAN logical nodes and interfaces between them, can be defined as part of the RNL. Lor each NG-RAN interface (NG, Xn, Ll) the related TNL protocol and the functionality can be specified. The TNL can provide services for user plane transport and signaling transport. In NG-Flex configuration, each gNB can be connected to all AMFs within an AMF Region. The AMF Region is e.g. described in 3GPP TS 23.501 (version 15.1.0).

As e.g. described in TS 38470 (version 15.0.0), the Fl interface provides means for interconnecting a gNB-CU and a gNB-DU of a gNB within an NG-RAN, or for

interconnecting a gNB-CU and a gNB-DU of an en-gNB (E-UTRAN/NR NB) within an E- UTRAN.

As described in TS 38470, Fl may be open and support the exchange of signaling information between endpoints. The Fl interface may support data transmission to respective endpoints. The Fl interface may be a point-to-point interface between endpoints. In some examples, a point-to-point logical interface can be feasible in the absence of a physical direct connection between the endpoints. The Fl interface can support control plane and user plane separation.

The Fl interface can separate Radio Network Fayer (RNF) and Transport Network Fayer (TNF). The Fl interface can enable exchange of UE associated information and non-UE associated information. The Fl interface can be defined to be future proof to fulfil different new requirements, support new services, and provide new functions. One gNB-CU and set of gNB-DUs can be visible to other logical nodes as a gNB. The gNB can terminate X2, Xn,

NG and Sl-U interfaces. The gNB-CU may be separated in a control plane (CP) and a user plane (UP).

Fig. 2 depicts the interface protocol structure for the Fl user plane. The first five layers may be regarded to form the Transport Network layer with the GTP-U (GPRS Tunneling Protocol User plane) layer on top and UDP, IP, data link layer and physical layer below. The Transport network layer defines procedures for establishing physical connections between the corresponding nodes, whereas the Radio Network Fayer (depicted on top of the GTP-U) defines procedures related to the interaction of this nodes.

With a base station (gNB) implemented using separate central and distributed units, appropriate coordination between central and distributed units may be useful.

One problem with existing solutions is about handling transmission time delays. While determining the Round Trip Time (RTT) may be determined in such system may be performed without establishing a common time base or reference for the different nodes, e.g. by sending a data unit containing a poll from the transmitting node to the receiving node which then responds by sending a data unit in reply appropriately tagged as the response to the poll, it may be difficult to perform separate measurements of the uplink, UL, and downlink, DL, contributions to the total RTT.

For RTT, the local time reference in the transmitting node can be used both to determine the transmission and reception time. However, when the one-way delay (UL and/or DL) is measured, separate time references are used in the transmitting node to determine the transmission time while and in the receiving node to determine the reception time. Only If both these time references are synchronized, the measurement of each one-way delay will be accurate Otherwise, the delay measurement will be erroneous in proportion to the (unknown) time difference between the time references in the transmitting and receiving nodes.

Unless an accurate common time reference is available such as through a Global Positioning System (GPS) receiver, the clocks of the different nodes may be synchronized by exchanging appropriate synchronization messages. However, synchronizing clocks in a variable delay packet network can be problematic since also packets sent to synchronize the clocks experience variable delay and consequently it is difficult to accomplish.

There exist several protocols, such as the Network Time Protocol, NTP, to mitigate the effects of variable network latency. NTP may maintain a time synchronization to within tens of milliseconds over the public Internet and may achieve better than one millisecond accuracy in local area networks under ideal conditions. For a higher level of accuracy, the Precision Time Protocol (PTP) may be used. In a local area networks, PTP may achieve a clock accuracy in the sub-microsecond range, making it suitable for measurement and control systems. The PTP may be regarded as to fill a niche not well served by either of the two dominant protocols, NTP and GPS.

SUMMARY

It is an object of the present invention to improve an operation of functionally split base stations comprising a central unit and one or a plurality of distributed units.

This object is achieved by the independent claims. Advantageous embodiments are described in the dependent claims and by the following description.

According to some embodiments, a method is provided to handle transmission delays in a radio access network involving a plurality of nodes or units. By way of example and being considered mainly in the following, the plurality of units or nodes are a (gNB) Central Unit (CU) and one or a plurality of (gNB) Distributed units (DUs) comprised by a gNB. Therein, suitable information (metrics) is being sent from one unit to another unit to determine delay characteristics between the units. Information of the delay characteristics gathered at one unit may further be provided to the other unit.

In an embodiment, a method in a central unit, CU, of a base station, gNB (or eNB), is performed to determine a time delay to one or a plurality of distributed units, DUs, wherein the CU provides an interface to a core radio network, CN, and the DUs provides each a radio interface to one or a plurality of UEs, comprising:

• transmitting a (first) time information indicative of a packet transmission time at the CU to a first DU,

• receiving a first DL transmission delay information associated to the time information from first DU,

• transmitting a second time information indicative of a packet transmission time at the CU to a second DU, and

• receiving a second DL transmission delay information associated to the time information from second DU,

• wherein the action is based on the first and the second DL transmission delay information.

In an embodiment, a method in a distributed unit, DU, of a base station, gNB (or eNB), is performed to determine a time delay to a CU, wherein the CU provides an interface to a core radio network, CN, and the DU provides a radio interface to one or a plurality of UEs, comprising:

• receiving a time information indicative of a packet transmission time at the CU to the DU,

• determining and transmitting a DL transmission delay information associated to the time information to the CU.

In an embodiment, a CU (of a base station) is provided configured to perform:

• transmitting a (first) time information indicative of a packet transmission time at the CU to a first DU,

• receiving a first DL transmission delay information associated to the time information from first DU,

• transmitting a second time information indicative of a packet transmission time at the CU to a second DU, and • receiving a second DL transmission delay information associated to the time information from second DU,

• wherein the action is based on the first and the second DL transmission delay information.

In an embodiment, a DU(of a base station) is provided configured to perform:

• receiving a time information indicative of a packet transmission time at the CU to the DU,

• determining and transmitting a DL transmission delay information associated to the time information to the CU.

In an embodiment a UE is provided to support the gNB to determine the transmission delay information.

BRIEF DESCRIPTION OF THE DESCRIPTION OF THE DRAWINGS

Fig. 1 schematically illustrates 5G network comprising an NG RAN and a 5G core network; Fig. 2 schematically illustrates exemplary user plane protocol being used in the NG RAN;

Fig. 3 schematically illustrates a gNB of the NG RAN comprising a central unit, CU and two distributed units (DUs);

Fig. 4 schematically illustrates an exemplary PDU information element of the user plane protocol;

Fig. 5 shows a sequence of steps being performed between a CU and a DU for determining transmission delays;

Fig. 6 schematically illustrates a block diagram of a DU;

Fig. 7 schematically illustrates a block diagram of a CU;

Fig. 8 schematically illustrates a block diagram of a UE;

Fig. 9 schematically illustrates a telecommunication network connected via an intermediate network to a host computer;

Fig. 10 is a generalized block diagram of a host computer communicating via a base station with a user equipment over a partially wireless connection; and

Figures 11 to 14 are flowcharts illustrating methods implemented in a communication system including a host computer, a base station and a user equipment. DETAILED DESCRIPTION

The solution outlined in the following outlines suitable metrics to be sent from one node or unit to another node or unit, e.g. from a DU and to a CU and/or vice versa, to determine delay characteristics between the units and how to convey this information between said units.

In an embodiment, this information in conveyed via in-band signaling in a NR user plane data frame as outlined in following.

In the following it may be assumed that the clocks in both nodes are synchronized to a targeted level of accuracy using one of the above-mentioned methods, e.g. NTP, PTP, GPS or some other method. Once a sufficient level of time synchronization has been achieved, each frame sent in the uplink or the downlink can be timestamped with the transmission time. In a similar fashion as for synchronization, there are many different schemes for timestamping a data packet such as the timestamp information element contained in the Internet Control Message Protocol (ICMP) or the Unix time (also known as POSIX time or UNIX Epoch time).

An advantage of embodiments described is to provide a possibility to determine separate uplink and downlink delay characteristics between the CU and the DU, to convey this information e.g. via the NR user plane in-band signaling in the sense of 3GPP standard TS 38.425 NR User plane specification (version 15.0.0), and/or to perform actions based on the delay information, e.g. performing actions in case of certain links between a CU and one or a plurality of DUs not fulfilling certain (predefined) Quality of Service requirements, e.g. VoIP delay requirements, or for determining load balancing or admission and congestion decisions.

Delay statistics that can determine not only RTT but also separate UL and DL delay characteristics may form important tools for managing Network Services and for Operations and Management (O&M) systems. Since the measurement functionality described herein may be applied on individual frames, both an actual UL and DL delay can be determined as well as statistics over time (or bin type measurements), where delay statistics can be gathered to determine a statistical distribution over time.

Embodiments allow also to determine a radio network end-to-end delay (e.g. between a User Equipment, UE and a CU of the gNB).

Such delay information may also support decisions on radio link configuration. For example, if a UE is configured with dual connectivity via two DUs, e.g. DU1 and DU2, both connected to the same CU, the information exchanged would allow the CU to evaluate the delay characteristics of both (Fl) links CU-DU1 and CU-DU2. In case a disparity between the CU- DU1 and CU-DU2 delays, it may take actions to provide equivalence between both connections (as dual connectivity brings the most advantages if the delay between CU and DUs is equivalent).

Generally, if the links CU-DU1 and CU-DU2 are subject to different delays the gNB (e.g. the CU of the gNB) may take appropriate actions.

In embodiments, one or a plurality of the following actions may be performed:

• schedule traffic only via such (communication or radio) leg that is subject to the

shortest CU-DU delay.

• remove the leg(s) subject to higher delay;

• replace a leg with a high CU-DU delay with another with shorter CU-DU delay, (e.g. with a CU-DU delay comparable with the one experienced over the existing legs for the UE);

• reconfigure QoS Flows to DRB (data radio bearer) mapping e.g. by removing QoS Flows with a low packet delay budget from a DRB served by a DU subject to high CU-DU delay;

• if the UF delay is increasing; reconfiguring the UE and the involved DU(s) to have UF traffic flow only via legs with short delays, e.g. via the leg with the best UF DU-CU delay.

QoS flow to DRB (re)mapping may be regarded as the operation that the RAN (gNB) changes the mapping relation between a QoS flow and a DRB, i.e., a QoS flow is reconfigured to be carried on a different DRB. Regularly, such remapping may take place when the gNB wants to move a QoS flow in the default DRB to a dedicated DRB. Moreover, the present DRB for a QoS flow may become unavailable due to the change of radio environment including handover. Further, the gNB may adjust DRB allocation to better cope with the current traffic conditions.

Fig. 3 shows a gNB 3320 with a CU 7000 being exemplarily connected to two DU’s, first DU 6100 and second DU 6200. Each of the units may be equipped with a GTP-U layer functionality. The user plane traffic is sent via the Fl-U interface as NR user plane frames according to 3GPP standard TS.38.425. In the following, embodiments are described to exchange delay information between CU and DUs by means of of Fl NR (in-band) user plane frames. A person skilled in the art will realize that the invention goes well beyond the example of involving an NR gNB-DU and gNB-CU (Fl interface). Embodiments described herein apply to any radio nodes communicating via a user plane, UP, protocol similar to or equal to the one defined in TS 38.425. Examples of nodes communicating via such protocols are an LTE eNB and an NR gNB or two LTE eNBs (X2 inteface), or two NR gNBs (Xn inteface), or an LTE eNB-CU and an LTE eNB-DU.

In an embodiment, a first unit, e.g. CU 7000 sends a timestamped data packet, e.g. a PDU as defined in Fig. 4, to a second unit, e.g. to first DU 6100. Such timestamp may be indicative of a transmission time of the data packet (e.g. a time of a transmission of the GTP-U protocol layer to the lower layer). The second (receiving) unit may determine a transmission delay between the two units based on a common time reference of both units. Such procedure may be performed in both directions, e.g. from DU to CU and from CU to DU. The transmission delay(s) may be stored (each) locally (on DU and CU) or sent to (each) the other node.

For determining the DL delay, each of a plurality of DUs (e.g. first DU 6100 and second DU 6200) will receive the information comprising a timestamp at which the received DL data packet (PDU) was transmitted by the CU. With this information each DU can determine the DL CU-DU delay e.g. by timestamping the arrival of the DL PDU. Thus, each DU may determine a difference between the arrival time at the DU and the transmission time at the CU (arrival timestamp - transmission Timestamp).

A similar procedure may be repeated for UL. Consequently, the delay in both directions, e.g. the downlink and the uplink delay can be determined separately and may e.g. be used to determine a gNB RTT delay. Alternatively or additionally, separate UL and DL delays (also being referred to as one way delays) may be kept and used for taking actions as discussed above. In such case each receiving unit conveys such delay information back to the transmitting unit.

In an embodiment, timestamp and delay information is conveyed by means of a data packet frame structure (type of frame) comprising a field for time information:

If sending the timestamp, the time stamp data is inserted into the field for time information. If sending back the FI delay information the same type of frame may be used, but instead of the timestamp, the transmission delay data is inserted into the field for time information.

According to Fig. 4, this field is being referred to as“Timestamp information”. In an embodiment, the common time reference is established by means of synchronizing the CU clock and DU clock(s).

An example of a POSIX Time timestamp (with a granularity of milliseconds) is

1519823360000, which corresponds to 02/28/18 14:09:20. Consequently, a millisecond resolution using PT requires 41 bits or 41/8=5.1 i.e. a minimum of 6 octets.

In an embodiment, the CU 7000 and the one or plurality of DUs 6100, 6200 each comprise a delay measurement function, e.g. a CU delay measurement function residing in the CU 7000 and a DU delay measurement function residing in the first DU 6100. These use the timestamp information from the transmitting node and compare this with the local time reference in the receiving node to determine the corresponding one-way delay, e.g. a downlink data packet is timestamped in the CU which allows the DU to determine the DL delay. For example, if the DU receives a timestamp per DL PDU from the CU, the DU can generate a delay feedback information and send it to the CU. This will allow the CU to determine the DL CU-DU delay. At the same time the DU will also be aware of DL CU-DU delay. The DL delay can then both be stored and accessible locally in the DU and also conveyed back to the CU by utilizing any of the protocols connecting the CU and DU, e.g. the NR user plane protocol as defined in 3GPP TS 38.425, as being described in more detail below.

Fig. 5 shows exemplary steps of determining the (Fl) DL and UL delay information.

In a first step Sl, (gNB-)CU 7000 and (first gNB-)DU 6100 may perform clock

synchronization to obtain a common time base.

In a second step S2, CU 7000 sends a CU transmission time stamp to DU 6100.

In a third step S3, DU 6100 determines the CU-DU (or DL) transmission delay based on the received CU transmission time stamp information and the current time of a clock

implemented in or controlled by DU 6100 (DU clock).

In a fourth step S4, DU 6100 may transmit the DL transmission delay information to CU 7000.

In a fifth step S5, DU 6100 sends a DU transmission time stamp to CU 7000.

In a sixth step S6, CU 7000 determines the DU-CU (or UL) transmission delay based on the received DU transmission time stamp information and the current time of a clock

implemented in or controlled by CU 7000 (CU clock). In a seventh step S7, CU 7000 may transmit the UL transmission delay information to DU 6100.

In further steps not shown here, CU or DU may take further actions

In another embodiment, two or more DUs 6100, 6200 are involved in the UE-gNB

communication. Bay way of example, the first DU 6100 (DU1) and the second DU 6200 (DU2) as depicted in Fig. 3 are involved. The CU determines the DL delay information for CU-DU1 and CU-DU2 based on each a time stamp received from DU 1 and DU2.

Based on these timestamps, the CU may determine a first DL delay DL1 between CU and DU1 and a second DL delay DL2 between CU and DU2.

The CU may further determine which delay is shorter. If the CU determines that DL1 is shorter that DL2, it may schedule traffic only via such leg comprising DU 1. It may remove the leg to the UE via DU2.

If the UE is currently served by DU2, it may replace the leg over DU2 by a leg over DU 1.

In a further embodiment, an end-to-end (e2e) packet delay is determined, i.e. determining a time it takes for a packet that is generated at the UE to reach the gNB-CU, and vice versa (from gNB-CU to UE).

Whereas there may exist radio network methods to calculate a packet delay from the UE to the gNB-DU (and vice versa), the end-to-end measurement (user equipment - gNB-CU, and vice versa) is determined based on the Fl delays (DU-CU delay and CU-DU delay also being referred to as (Fl) UL and (Fl) DL delay respectively). When determining the e2e delay, additionally a processing time at both the gNB-CU and gNB-DU may be taken into account.

In an embodiment thereto, the CU 7000 and DU nodes 6100, 6200 exchange a time stamp information as well as a packet age information. An example of packet age information for the uplink (DU to CU) is the time it takes from packet creation in the UE until the packet is ready to be transmitted over the Fl interface. An example of packet age information in the downlink (CU to DU) is the time it takes from packet reception at the CU (from Core

Network) until the packet is ready to be transmitted over the Fl interface. By conveying timestamp and packet age information, the receiving node can calculate not only the radio link delay but also the end to end packet delay (e.g. as packet age + link delay).

Thereto, the UE may convey packet generation information to the one or the plurality of DUs. The one or the plurality of DUs determines the packet age information and sends this information in addition to the timestamp information to the CU. This information may be conveyed in an additional information element (e.g. with the same PDU type with the age data inserted into the timestamp information field).

In the following, exemplary NR user plane frame structure is described for conveying timestamp and delay information

In one embodiment, in order to convey the information elements listed below it is proposed that a new PDU type is added to section 5.5.2 of TS 38.425. In this document, PDU Types 0 and 1 are already used and the new PDU Type Latency Information may for example use the next available PDU Type which is 2. As an example, by utilizing the 4 bits after the PDU Type field, 16 different types Latency Information can be defined. Alternatively, the field that specifies the Latency Information may be of different sizes, if needed. The size of the different Latency Information can either be predetermined and fixed or in another

embodiment one of the octets in the frame contains a Length Indicator as in the figure 3 example below. It may also be beneficial to add an octet following the Latency Information that determines a subtype of the information contained in the LI. A person skilled in the art recognizes that figure 3 below is only an example embodiment and that other combinations of data fields can also be used to convey the timestamp and latency related information.

One other alternative for the UL is to use the DL DATA DELIVERY STATUS (PDU Type 1) as defined in reference 1 section 5.5.2.2. using the Cause report flag and Cause value for signaling latency related information and alternatively by defining a new DD flag for the DL DATA DELIVERY STATUS (PDU Type 1) and in this way convey the information elements defined below.

Yet other alternatives are to utilize reserved or spare bits or other“PDU Type” values and subfields. In addition, a person skilled in the art also recognizes that there are other alternative embodiments as well such as utilizing currently unused values of the GTP-U“Next Extension Header” field.

In another embodiment of this invention a new PDU Type may be defined in a more generic way and be used for UL Data traffic. Such PDU Type may carry the latency information from DU to CU. Namely, such PDU Type may contain the timestamp for the transmission of UL PDUs, i.e. the timestamp set by the DU at the time an UL PDU is transmitted. The new PDU may also contain the DL delay calculated by the DU by means of receiving DL PDU transmission timestamps from the CU.

For the delivery of the DL PDU transmission timestamp a possible mechanism is to include such timestamp information in the PDU Type 0 for DL data. Similarly, the PDU Type 0 may be used to convey to the DU the UL delay estimated by the CU upon reception of the UL PDU transmission timestamp.

One alternative method to send UL PDU transmission timestamp and DL estimated delay from DU to CU is via the PDU Type 1, also known as DDDS. Given that the DDDS is not sent at every UL PDU one possible way to use such PDU Type is to communicate the UL PDU Transmission timestamp of the PDU transmitted with the DDDS and to communicate the average DL delay monitored at the DU from the time of delivery of the last DDDS.

Namely, the DDDS can be used to signal an average DL delay to the CU.

Some of exemplary fields are described in more detail:

PDU Type: This field is already defined in TS 38.425 and currently two values are used: 0 which indicates DL user data and 1 which indicates DL delivery data. A new value, e.g. 2 could be used to indicate that the PDU contains the information outlined in this invention disclosure.

Latency Information: This field indicates if the data contained pertains to delay, timestamp information or some other information type.

Latency Information Subtype: The latency subtype is used to indicate what type of timestamp or delay information is contained in the PDU, e.g. if the data pertains to the UL or DL, if it is in timestamp information, e.g. Unix time (also known as POSIX time or UNIX Epoch time) or Internet Control Message Protocol (ICMP), estimated uplink latency or estimated downlink latency etc. for different time periods, e.g. per ls, lOs, 1 min, lh, session average etc.

LI bit: The LI bit is used to indicate the presence of a length indicator in the following octet.

Length Indicator: This field is used to indicate length of the PDU in case this is not predetermined.

Spare: The spare field is as defined in TS38.425 and is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions. Fig. 4 shows an exemplary PDU information element that may be added to current 3GPP document TS 38.425, version 15.0.0. In such amendment, Fig. 3 may form Figure 5.2.2.X sub-titled with“Latency Information (PDU Type 2)”.

With a field numbering referring to the section numbering in TS 38.425, the added part may read as follows:

Begin of TS 38.425 addition:

5.5.3 Coding of information elements in frames

5.5.3.1 PDU Type

Description: The PDU Type indicates the structure of the NR user plane frame. The field takes the value of the PDU Type it identifies; i.e. "0" for PDU Type 0. The PDU type is in bit 4 to bit 7 in the first octet of the frame.

Value range: {0=DL USER DATA, l=DL DATA DELIVERY STATUS, 2=LATENCY

INFORMATION, 3-l5=reserved for future PDU type extensions}

Field length: 4 bits

It should be noted that the latency information may be conveyed in any available PDU Type sent from any 5G/NR node to another, either in UL or DL, and PDU type 2 is just an example. Further, as another non-limiting example, the latency information PDU could be sent from a gNB-DU to a gNB-CU or from a gNB-DU to an LTE eNB or from an LTE eNB to a gNB- CU.

5.5.3.X Latency Information

Description: This field defines the sub type to the LATENCY INFORMATION Type defined in section 5.5.3.1.

Value range: {0=TIMESTAMP INFORMATION, l=UPLINK LATENCY INFORMATION,

2=DOWNLINK LATENCY INFORMATION . X-l5=reserved for future Latency

Information extensions}

Value range: (0-15).

Length: 4 bits.

5.5.3.Y Latency Information Subtype Description: This field defines the sub type to the LATENCY INFORMATION PDU Type defined in section 5.5.3.1.

Value range:

{For Fatency Information^; 0= SEND TIMESTAMPED FRAME, 1= UNIX (POSIX) FORMAT, 2= INTERNET CONTROL MESSAGE (ICMP) FORMAT, 3= UNIX (POSIX) FORMAT&PACKET AGE, 4= INTERNET CONTROL MESSAGE (ICMP)

FORMAT &PACKET AGE . X-l5=reserved for future Latency Information Subtype extensions}

{For Latency Information^; 0= LATENCY ESTIMATE 1 S AVERAGE, 1= LATENCY

ESTIMATE 10 S AVERAGE, 3= LATENCY ESTIMATE AVERAGE OF SESSION . X- l5=reserved for future Latency Information Subtype extensions }

{For Latency Information=2; 0= LATENCY ESTIMATE 1 S AVERAGE, 1= LATENCY

ESTIMATE 10 S AVERAGE, 3= LATENCY ESTIMATE AVERAGE OF SESSION . X- l5=reserved for future Latency Information Subtype extensions }

Value range: (0-15).

Field Length: 4 bits.

5.5.3.2 Spare

Description: The spare field is set to "0" by the sender and should not be interpreted by the receiver. This field is reserved for later versions.

Value range: (0-2n-l).

Field Length: n bits.

5.5.3.Z Length Indicator presence

Description: This parameter indicates if there is an octet containing a frame length indicator following the frame header.

Value range: {0=No length indicator octet present, 1= Length indicator octet present}.

Field length: 1 bit.

5.5.3.24 Spare extension

Description: The spare extension field shall not be sent. The receiver should be capable of receiving a spare extension. The spare extension should not be interpreted by the receiver, since in later versions of the present document additional new fields might be added in place of the spare extension. The spare extension can be an integer number of octets carrying new fields or additional information; the maximum length of the spare extension field (m) depends on the PDU type.

Value range: 0-2m*8- 1.

Field Length: 0-m octets. For the PDU Types defined in the present document m=4.

End of TS 38.425 addition.

Fig. 6 is a block diagram illustrating a gNB distributed unit DU node 6100 or 6200 according to some embodiments disclosed herein. In the following, by way of example (first) DU node 6100 is described. As shown, DU node 6100 may include processor 603 coupled with transceiver 601, network interface 605, and memory 607. Transceiver 601 may include one or more of a cellular radio access network (RAN) interface (also referred to as a RAN transceiver) and/or another wireless network communication interface. DU node 6100 can thus provide wireless communication over one or more radio links with one or more mobile communication devices. Network interface 605 may provide communication with other network nodes/devices such as an gNB central unit CU node (e.g., CU node, gNB-CU, etc.), for example, over an Fl interface. Processor 603 (also referred to as a processor circuit or processing circuitry) may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor). Processor 603 may be configured to execute computer program instructions from functional modules in memory 607 (also referred to as a memory circuit or memory circuitry), described below as a computer readable medium, to perform some or all of the operations and methods that are described herein for one or more of the embodiments. Moreover, processor 603 may be defined to include memory so that separate memory 607 may not be required.

As discussed herein, operations of DU node 6100 may be performed by processor 603, network interface 605, and/or transceiver 601. For example, processor 603 may control transceiver 601 to transmit downlink communications through transceiver 601 over a radio interface to one or more UEs and/or to receive uplink communications through transceiver 601 from one or more UEs over a radio interface. Similarly, processor 603 may control network interface 605 to transmit communications through network interface 605 to one or more other network nodes (e.g., to a CU node) and/or to receive communications through network interface 605 from one or more other network nodes (e.g., a CU node). Moreover, modules may be stored in memory 607, and these modules may provide instructions so that when instructions of a module are executed by processor 603, processor 603 performs respective operations (e.g., operations discussed below with respect to Example

Embodiments).

The DU node 6100 and 6200 may be collocared in one physical node or may each constitute separate physical nodes.

Similarly, one ore a plurality of DU nodes 6100 and 6200 may be collocated with CU node 7000 in one physical node, or may each constitute separate physical nodes.

Fig. 7 is a block diagram illustrating a gNB central unit CU node 7000 according to some embodiments disclosed herein. As shown, CU node 7000 may include processor 703 coupled with network interface 701 and memory 705. Network interface 701 may provide

communication with other network nodes/devices such as a plurality of DU nodes, for example, over respective Fl interfaces. Processor 703 (also referred to as a processor circuit or processing circuitry) may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor and/or digital signal processor). Processor 703 may be configured to execute computer program instructions from functional modules in memory 705 (also referred to as a memory circuit or memory circuitry), described below as a computer readable medium, to perform some or all of the operations and methods that are described herein for one or more of the embodiments. Moreover, processor 703 may be defined to include memory so that separate memory 705 may not be required.

As discussed herein, operations of CU node 7000 may be performed by processor 703 and/or network interface 701. For example, processor 703 may control network interface 701 to transmit communications through network interface 701 to one or more other network nodes (e.g., to one or more DU nodes) and/or to receive communications through network interface 701 from one or more other network nodes (e.g., one or more DU nodes). Moreover, modules may be stored in memory 705, and these modules may provide instructions so that when instructions of a module are executed by processor 703, processor 703 performs respective operations (e.g., operations discussed below with respect to Example Embodiments). Not shown here, CU node 700 may have a further network interface on a core NR network as discussed above.

Fig. 8 is a block diagram illustrating elements of a wireless device UE 3330 (also referred to as a wireless terminal, a wireless communication device, a wireless communication terminal, user equipment, UE, a user equipment node/terminal/device, etc.) configured to provide wireless communication according to embodiments of inventive concepts. As shown, wireless device UE may include an antenna 3336, and a transceiver circuit 3337 (also referred to as radio interface) including a transmitter and a receiver configured to provide uplink and downlink radio communications with a base station (gNB) of a wireless communication network (also referred to as a radio access network RAN). Wireless device UE may also include a processor circuit 3338 (also referred to as processing circuitry) coupled to the transceiver circuit, and a memory circuit 3335 (also referred to as memory) coupled to the processor circuit. The memory circuit 3335 may include computer readable program code that when executed by the processor circuit 3338 causes the processor circuit to perform operations according to embodiments disclosed herein. According to other embodiments, processor circuit 3338 may be defined to include memory so that a separate memory circuit is not required. Wireless device UE may also include an interface (such as a user interface) coupled with processor 3338, and/or wireless device UE may be an IoT and/or MTC device.

As discussed herein, operations of wireless device UE may be performed by processor 3338 and/or transceiver 3337. For example, processor 3338 may control transceiver 3337 to transmit uplink communications through transceiver 3337 over a radio interface to a base station of a wireless communication network (e.g., a gNB base station including a gNB-CU and one or more gNB-DUs) and/or to receive downlink communications through transceiver 3337 from a base station (e.g., a gNB base station including a gNB-CU and one or more gNB- DUs) of the wireless communication network over a radio interface. Moreover, modules may be stored in memory 3335, and these modules may provide instructions so that when instructions of a module are executed by processor 3338, processor 3338 performs respective operations (e.g., operations discussed below with respect to Example Embodiments).

The invention may be especially beneficial in a cloud implementation (or virtualized environment), where the physical placement of the network nodes may not be transparent or may be at least partially unknown. Moreover, the physical placement of DU’s and CU’s may vary and the number of intermediate nodes may vary as well. As a consequence of this, the UL and DL delay characteristics will also show significant variations depending on configuration and distances; it may be beneficial to continuously measure the delay contributions of the UL and DL.

With reference to Fig. 9, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3GPP-type cellular network, which comprises an access network 3211, such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 32l3a, 32l3b, 32l3c. Each base station 32l2a, 32l2b, 32l2c is connectable to the core network 3214 over a wired or wireless connection 3215. A first user equipment (UE) 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 32l2c. A second UE 3292 in coverage area 32l3a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

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

The communication system of Fig. 9 as a whole enables connectivity between one of the connected UEs 3291, 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink

communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 10. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the

communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311, which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The base station 3320 may comprise a CU 7000 and one or a plurality of DUs 6000. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig. 10) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig. 10) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non-human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 10 may be identical to the host computer 3230, one of the base stations 32l2a, 32l2b, 32l2c and one of the UEs 3291, 3292 of Fig. 9, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 10 and independently, the surrounding network topology may be that of Fig. 9.

In Fig. 10, the OTT connection 3350 has been drawn abstractly to illustrate the

communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network). The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure.

One or more of the various embodiments improve the performance of OTT services provided to the UE 3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the latency or power consumption and thereby provide benefits such as better responsiveness, extended battery lifetime.

A measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311, 3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and

functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency and the like. The measurements may be implemented in that the software 3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 11 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 12 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs 9 and. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 9 and 10. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.