Uplink packet delay measurement and reporting

Abstract

Example embodiments of the present disclosure are directed to uplink (UL) packet delay measurement and reporting. A method comprises receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and reporting the aggregated value of the metric for the monitored QoS flow.

Description

UPLINK PACKET DELAY MEASUREMENT AND REPORTINGFIELD

[0001] Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for uplink (UL) packet delay measurement and reporting.BACKGROUND

[0002] In modern wireless communication systems, Quality of Service (QoS) monitoring involves detailed analysis of packet delays to ensure optimal network performance and meet the stringent requirements of diverse applications. A critical aspect of this process is monitoring the packet delay between the Radio Access Network (RAN) and the Core Network (CN), specifically the User Plane Function (UPF). This delay measurement captures the distribution of uplink (UL) packet delay across various network segments.SUMMARY

[0003] In a first aspect of the present disclosure, there is provided a network device. The network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to: receive, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); determine, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and report the aggregated value of the metric for the monitored QoS flow.

[0004] In a second aspect of the present disclosure, there is provided a terminal device. The terminal device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and transmit, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control ProtocolData Unit (PDU).

[0005] In a third aspect of the present disclosure, there is provided a network device. The network device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first apparatus at least to: receive a Quality of Service (QoS) configuration message indicating at least one monitored QoS flow and corresponding monitored scope; receive, from a terminal device, at least one first value of a QoS metric for the at least one monitored QoS flow transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU) ; and determine, based on the at least one first value, at least one aggregated value of the QoS metric for the at least one monitored QoS flow.

[0006] In a fourth aspect of the present disclosure, there is provided a terminal device. The terminal device comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to: in response to a determination that the terminal device is located in a Quality of Service (QoS) monitored scope, determine at least one value of a QoS metric for a monitored QoS flow; and transmit, to a network device, the at least one value of the QoS metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0007] In a fifth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and reporting the aggregated value of the metric for the monitored QoS flow.

[0008] In a sixth aspect of the present disclosure, there is provided a method. The method comprises: determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0009] In a seventh aspect of the present disclosure, there is provided a method. The method comprises: receiving a Quality of Service (QoS) configuration message indicating at least one monitored QoS flow and corresponding monitored scope; receiving, from aterminal device, at least one first value of a QoS metric for the at least one monitored QoS flow transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU) ; and determining, based on the at least one first value, at least one aggregated value of the QoS metric for the at least one monitored QoS flow.

[0010] In an eighth aspect of the present disclosure, there is provided a method. The method comprises: in response to a determination that the terminal device is located in a Quality of Service (QoS) monitored scope, determining at least one value of a QoS metric for a monitored QoS flow; and transmitting, to a network device, the at least one value of the QoS metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0011] In a ninth aspect of the present disclosure, there is provided a network device. The network device comprises means for receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); means for determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and means for reporting the aggregated value of the metric for the monitored QoS flow.

[0012] In a tenth aspect of the present disclosure, there is provided a terminal device. The terminal device comprises means for determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and means for transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0013] In an eleventh aspect of the present disclosure, there is provided a network device. The network device comprises means for receiving a Quality of Service (QoS) configuration message indicating at least one monitored QoS flow and corresponding monitored scope; means for receiving, from a terminal device, at least one first value of a QoS metric for the at least one monitored QoS flow transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU) ; and means for determining, based on the at least one first value, at least one aggregated value of the QoS metric for the at least one monitored QoS flow.

[0014] In a twelfth aspect of the present disclosure, there is provided a terminal device. The terminal device comprises means for in response to a determination that the terminaldevice is located in a Quality of Service (QoS) monitored scope, determining at least one value of a QoS metric for a monitored QoS flow; and means for transmitting, to a network device, the at least one value of the QoS metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0015] In a thirteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fifth aspect.

[0016] In a fourteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the sixth aspect.

[0017] In a fifteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the seventh aspect.

[0018] In a sixteenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the eighth aspect.

[0019] It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Some example embodiments will now be described with reference to the accompanying drawings, where:

[0021] FIG. 1 illustrates an example communication environment in which example embodiments of the present disclosure can be implemented;

[0022] FIG. 2 illustrates an example GTP-U extension header in accordance with some embodiments in the disclosure;

[0023] FIG. 3 illustrates an example an example signaling process of the inclusion of packet timestamps in accordance with some embodiments in the disclosure;

[0024] FIG. 4 illustrates an example signaling process of the inclusion of packet timestamps in accordance with some embodiments in the disclosure;

[0025] FIG. 5 illustrates example enhancements to the functionality of the PDCP Control PDU;

[0026] FIG. 6 illustrates an example signaling process of user plane-based retrieval of packet delay component DI in accordance with some embodiments in the disclosure;

[0027] FIG. 7 illustrates an example signaling process of non-UE associated Quality of Service (QoS) Monitoring Packet activation in accordance with some embodiments in the disclosure.

[0028] FIG. 8 illustrates a flowchart of a method implemented at a network device in accordance with some example embodiments of the present disclosure;

[0029] FIG. 9 illustrates a flowchart of a method implemented at a terminal device in accordance with some example embodiments of the present disclosure;

[0030] FIG. 10 illustrates a flowchart of a method implemented at a network device in accordance with some example embodiments of the present disclosure;

[0031] FIG. 11 illustrates a flowchart of a method implemented at a terminal device in accordance with some example embodiments of the present disclosure;

[0032] FIG. 12 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

[0033] FIG. 13 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

[0034] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0035] Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the onesdescribed below.

[0036] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0037] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0038] It shall be understood that although the terms “first,” “second,”..., etc. in front of noun(s) and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another and they do not limit the order of the noun(s). For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.

[0039] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0040] As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

[0041] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that theterms “comprises”, “comprising”, “has”, “having”, “includes” and / or “including”, when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0042] As used in this application, the term “circuitry” may refer to one or more or all of the following:(a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and(b) combinations of hardware circuits and software, such as (as applicable):(i) a combination of analog and / or digital hardware circuit(s) with software / firmware and(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and(c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0043] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0044] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR), Long Term Evolution (LTE), LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrow Band Internet of Things (NB-IoT) and so on.Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G), the second generation (2G), 2.5G, 2.75G, the third generation (3G), the fourth generation (4G), 4.5G, the fifth generation (5G), 5.5G, the sixth generation (6G) communication protocols, and / or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0045] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP), for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

[0046] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, musicstorage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, wireless customer-premises equipment (CPE), an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node). In the following description, the terms “terminal device”, “communication device”, “terminal”, “user equipment” and “UE” may be used interchangeably.

[0047] As used herein, the term “resource,” “transmission resource,” “resource block,” “physical resource block” (PRB), “uplink resource,” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other combination of the time, frequency, space and / or code domain resource enabling a communication, and the like. In the following, unless explicitly stated, a resource in both frequency domain and time domain will be used as an example of a transmission resource for describing some example embodiments of the present disclosure. It is noted that example embodiments of the present disclosure are equally applicable to other resources in other domains.

[0048] As used herein, the term "uplink (UL) transmission" may refer any transmission of data from a terminal device to a network device. This includes, but is not limited to, transmissions in the time domain, frequency domain, space domain, code domain, or any combination thereof. Uplink transmission may involve the use of various resources such as physical resource blocks (PRBs), subcarriers, and time slots, enabling communication from the terminal device to the network device.

[0049] As used herein, the term “downlink (DL) transmission” may refer to any transmission of data from a network device to a terminal device. This includes, but is not limited to, transmissions in the time domain, frequency domain, space domain, code domain, or any combination thereof. Downlink transmission may involve the use ofvarious resources such as physical resource blocks (PRBs), subcarriers, and time slots, enabling communication from the network device to the terminal device.

[0050] As used herein, the term “packet delay” may refer to the total time taken for a data packet to travel from its source to its destination in a communication system. This may include, but is not limited to, delays occurring due to processing, queuing, transmission, propagation, or buffering within network components, as well as over-the- air interfaces.

[0051] As used herein, the term “over-the-air interface” or “Uu interface” may refer to the wireless communication link between a terminal device and a radio access network (RAN) node, such as a base station. This interface facilitates data transmission in both uplink and downlink directions and includes, but is not limited to, the use of physical layer resources such as subcarriers, time slots, and frequency bands.

[0052] As used herein, the term “Radio Access Network (RAN)” may refer to the part of a communication system that provides the wireless interface between terminal devices and the core network. This includes, but is not limited to, network components such as base stations, distributed units (DUs), and centralized units (CUs) that handle tasks such as signal transmission, radio resource management, and data forwarding in both uplink and downlink directions.

[0053] As used herein, the term “Distributed Unit (DU)” may refer to a component of the radio access network (RAN) responsible for handling lower-layer protocols such as real-time radio processing and scheduling. The DU typically communicates with the Centralized Unit (CU) over the Fl interface and manages data exchange with terminal devices over the Uu interface.

[0054] As used herein, the term “Centralized Unit - User Plane (CU-UP)” may refer to a component of the radio access network (RAN) responsible for handling user-plane data. This includes, but is not limited to, functions such as packet forwarding, routing, and GTP-U termination. The CU-UP typically interacts with the DU over the Fl interface and the core network through interfaces like N3.

[0055] As used herein, the term “Centralized Unit - Control Plane (CU-CP)” may refer to a component of the radio access network (RAN) responsible for managing control-plane functions such as signaling, mobility management, and session setup. The CU-CPcommunicates with the core network through interfaces like N2 and coordinates with the DU and CU-UP for resource allocation and session control.

[0056] As used herein, the term “Access and Mobility Management Function (AMF)” may refer to a core network function responsible for managing access control, mobility, and session management for terminal devices. This includes, but is not limited to, tasks such as authentication, handover coordination, and interface management with the RAN through N2 and other core network functions.

[0057] As used herein, the term “User Plane Function (UPF)” may refer to a core network function responsible for handling user-plane data, including packet routing, forwarding, and quality of service (QoS) enforcement. The UPF communicates with the RAN over interfaces like N3 and interfaces with external networks to deliver data to and from terminal devices.

[0058] As used herein, the term “Data Radio Bearer (DRB)” refers to a logical channel between the UE and the network that is used to carry user data. A DRB is established for the transfer of data between the UE and the core network, and it may be configured to support various types of traffic, such as voice, video, or data services. DRBs can be mapped to different bearers, each associated with specific QoS requirements, and can operate over different transport layers, including the RAN and core network interfaces.

[0059] As used herein, the term “Packet Data Convergence Protocol (PDCP)” refers to a protocol layer in the protocol stack responsible for the header compression, encryption, and integrity protection of user data and control information in both the uplink and downlink. PDCP ensures efficient use of radio resources by reducing the size of headers and securing data. The PDCP layer operates between the Radio Link Control (RLC) layer and the Radio Resource Control (RRC) layer (for control information) and between the RLC layer and the Service Data Adaptation Protocol (SDAP) layer (for user data), and its functions include data reordering and security, robust header compression and retransmission.

[0060] As used herein, the term “Quality of Service Monitoring Packet (QMP)” refers to a packet used for monitoring the quality of service (QoS) within a communication network, particularly in relation to the performance of data transmission between network devices. QMPs are utilized to assess key performance indicators such as delay, throughput, and packet loss, among others, in both uplink and downlink directions. These packets maycarry information related to the measurement of specific QoS parameters and are typically exchanged between the user equipment (UE) and the core network or between the radio access network (RAN) and core components like the User Plane Function (UPF). QMPs play an important role in providing feedback for optimizing network performance and ensuring that service level agreements (SLAs) are met across various network conditions.

[0061] As used herein, the term “Fl Application Protocol (F1AP)” may refer to a signaling protocol used for communication between the Central Unit (CU) and Distributed Unit (DU) of a 5G base station, known as gNB. This protocol facilitates control plane signaling over the Fl interface, enabling efficient coordination between the CU and DU for tasks such as mobility management, handovers, and radio resource control. F1AP supports the exchange of messages related to the establishment, modification, and release of connections, ensuring seamless communication between the Radio Access Network (RAN) and the core network. It is involved in managing user plane data transport, signaling for bearer setups, and supporting context transfer during mobility events. The protocol ensures the proper operation of 5G networks by facilitating coordination and resource management across the RAN architecture.

[0062] FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented. In the communication environment 100, a plurality of communication devices, including a terminal device 110 and a network device 120, can communicate with each other. In the example of FIG. 1, the terminal device 110 may be a UE and the network device 120 may be a base station serving the UE. The serving area of the network device 120 may be called a cell.

[0063] It is to be understood that the number of devices and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. The communication environment 100 may include any suitable number of devices configured to implementing example embodiments of the present disclosure. Although not shown, it would be appreciated that one or more additional devices may be located in the cell, and one or more additional cells may be deployed in the communication environment 100. It is noted that although illustrated as a network device, the network device 120 may be another device than a network device. Although illustrated as a terminal device, the terminal device 110 may be another device than a terminal device.

[0064] In the following, for the purpose of illustration, some example embodiments aredescribed with the terminal device 110 operating as a UE and the network device 120 operating as a base station. However, in some example embodiments, operations described in connection with a terminal device may be implemented at a network device or other device, and operations described in connection with a network device may be implemented at a terminal device or other device.

[0065] In some example embodiments, a transmission direction from the network device 120 to the terminal device 110 is referred to as a downlink (DL), while a transmission direction from the terminal device 110 to the network device 120 is referred to as an uplink (UL). In DL, the network device 120 is a transmitting (TX) device (or a transmitter) and the terminal device 110 is a receiving (RX) device (or a receiver). In UL, the terminal device 110 is a TX device (or a transmitter) and the network device 120 is a RX device (or a receiver).

[0066] Communications in the communication environment 100 may be implemented according to any proper communication protocol(s), comprising, but not limited to, cellular communication protocols, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and / or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiple (OFDM), Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and / or any other technologies currently known or to be developed in the future.

[0067] In current communication standards, the QoS Monitoring Packet (QMP) plays an important role in providing detailed information about UL packet delays as data travels from the RAN node to the CN, specifically the UPF. This monitoring process involves measuring and analyzing the distribution of UL delays between the NG-RAN and the UE, encompassing delays contributed by both the network and the UE.

[0068] Within the NG-RAN, the delay is composed of multiple components: processing delays at the gNB Centralized Unit User Plane (CU-UP), transmission delays across the Fl-U interface, and additional delays occurring in the gNB Distributed Unit (DU). Theanalysis also includes the delay over the Uu interface, which represents the over-the-air connection between the UE and the gNB. Furthermore, the distribution accounts for the DI UL PDCP delay, introduced by the Packet Data Convergence Protocol (PDCP) layer in the UE. The gNB is tasked with performing GPRS Tunneling Protocol (GTP) PDU packet delay measurements as part of QoS monitoring.

[0069] These measurements focus on GTP PDU monitoring packets received from the UPF. During this process, the gNB records timestamps and extracts relevant information from the GTP-U header of each GTP PDU monitoring response packet. These timestamps enable accurate tracking of delay for individual packets. For example, in each monitored packet sent to the UPF, the gNB includes detailed metrics regarding aggregated uplink delay, ensuring comprehensive analysis of uplink performance.

[0070] The average packet delay in DL is the total of several delay components, each representing a specific phase of the transmission process. The first component DI is the delay in the over-the-air interface, which reflects the average time it takes for a packet to be transmitted over the wireless link between the UE and the DU. This delay is an important factor in determining the overall latency experienced by the packet during transmission. Next, the delay within the DU D2 is considered, which represents the average delay of the Radio Link Control (RLC) Service Data Units (SDUs) during their initial transmission in the downlink. This delay occurs as the packets are processed at the DU, where the lower layers of the protocol stack handle data delivery. The third component D3 involves the delay on the Fl-U interface, where GTP packets experience transmission delays as they are relayed from the CU-UP towards the CN. Finally, the delay within the CU-UP D4 represents the average delay of PDCP SDUs in the downlink, specifically for all PDCP packets processed at the CU-UP. The average packet delay in DL may be the sum of DI + D2 + D3 + D4.

[0071] For UL average packet delay, multiple components contribute to the overall delay, reflecting different stages of the transmission from the UE to the CN. The first component DI is the UL PDCP packet average delay, which represents the time spent by the PDCP layer processing packets in the uplink, measured at the CU-UP. This delay is an important part of the overall uplink latency. The second component D2.1 is the delay on the over- the-air interface, which accounts for the time packets spend in the air interface as they travel from the UE to the DU. The third delay component involves the RLC packet delay D2.2, where the RLC layer processes packets in the uplink at the DU. The fourthcomponent D2.3 is the delay on the Fl-U interface, where GTP packets experience delays as they travel from the CU-UP towards the CN. Lastly, the PDCP re-ordering delay D2.4 in the uplink is considered, which occurs when packets are reordered at the CU-UP before being forwarded. This delay arises due to the need for packets to be rearranged into the correct sequence before transmission, contributing to the overall uplink delay, which may be the sum of DI + D2.1 + D2.2 + D2.3 + D2.4.

[0072] Current approach for retrieving the DI UL packet delay component from the UE involves a configuration parameter called ul-DelayValueConfig. This configuration instructs the UE to perform the UL PDCP Packet Average Delay measurement for each DRB, ensuring that the UE calculates the delay per DRB as required. Additionally, the UE is instructed to disregard certain fields, such as reportQuantityCell and maxReportCells. The report interval for this measurement is flexible, with various predefined values available, such as { 120ms, 240ms, 480ms, 640ms, 1024ms, 2048ms, 5120ms, 10240ms, 20480ms, 40960ms, 1 minute, 6 minutes, 12 minutes, or 30 minutes}. This report interval defines how frequently the UE performs and reports the UL PDCP Packet Average Delay measurement for each DRB.

[0073] In a split-architecture, the measurement of delay components is distributed between the Distributed Unit (DU) and the Central Unit User Plane (CU-UP). For DL packet delay, components such as DI and D2 are measured in the DU, while D3 and D4 are measured in the CU-UP. Similarly, for UL packet delay, D2.1 and D2.2 are measured in the DU, whereas D2.3 and D2.4 are measured in the CU-UP. An additional consideration for UL packet delay is the DI component, which is measured in the UE. This measurement must be shared with the CU-UP to calculate the total UL packet delay.

[0074] The retrieval of the DI delay component for UL packet delay involves RRC signaling overhead. In the current approach, RRC signaling is required between the Central Unit Control Plane (CU-CP) and the UE to obtain the ZU delay measurement. The CU-CP then forwards this measurement to the CU-UP for calculating the total UL packet delay. Once the CU-UP completes the calculation, it sends the total packet delay back to the CU-CP, which ultimately relays it to the source node. This process requires coordinated signaling between two nodes, CU-CP and CU-UP, introducing complexity and potential delays in the calculation.

[0075] RRC -based collection of the DI delay component further adds overhead due tothe need for scheduling on Signaling Radio Bearer 1 (SRB1) to transmit the RRC Measurement Report to the CU-CP according to the configured UL packet delay reporting periodicity. This additional signaling traffic on SRB1 can lead to congestion, particularly during periods when other high-priority RRC signaling, such as Measurement Reports, is required. The increased signaling load during the data collection period can delay these critical operations. Therefore, alternative methods that avoid the RRC -based approach for collecting the DI delay component need to be explored.

[0076] Current approach performs the activation of the QMP functionality on a per-UE and per-QoS Flow basis using a specific flag included in the PDU Session Resource Setup Request, which also introduces significant signaling overhead, particularly in scenarios where QMP activation is required on a broader scale. For example, if QMP needs to be activated for all QoS Flows associated with a specific network slice, this process must be repeated for each QoS Flow across all UEs within the slice. Similarly, when QMP activation is required for a particular Public Land Mobile Network (PLMN), Tracking Area, or other large-scale configurations, the signaling load increases substantially. This results in inefficiencies and an added complexity, highlighting the need for more streamlined activation mechanisms in such scenarios.

[0077] RRC -based methods are suboptimal for such frequent updates, as they introduce unnecessary overhead and signaling delays. It is observed that in both split and non-split architectures, the DI UL PDCP packet average delay may be utilized by the user plane for scheduling optimizations and congestion marking. Frequent reporting of delay measurements is most efficient when performed natively within the user plane, eliminating the need for RRC layer involvement. By integrating delay reporting directly into the user plane, faster and more efficient performance may be achieved.

[0078] The core concept in the disclosure is to report the DI UL PDCP packet average delay by utilizing a native PDCP protocol control PDU for direct communication from the UE to the gNB. This is further extended to unify the calculation and reporting of the total UL Packet Delay in a split architecture to improve efficiency and accuracy. Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0079] The total UL packet delay calculation is divided across components in the split architecture, specifically between the CU-UP and DU. To facilitate this, a mechanism isproposed in the DU to include timestamps for each packet of selected bearers. The DU records the time when a packet is received from the UE and the time it is forwarded to the CU-UP. This timestamp information enables the CU-UP to accurately calculate the UL packet delay for each packet.

[0080] The CU-UP may be designed to calculate the total UL packet delay by combining the timestamp received from the DU with the time at which the packet is sent out to the Core Network (UPF). This calculation may also incorporate the delay component (DI) reported by the UE. The total UL delay calculation essentially measures the time interval from when the UL Grant is provided to the UE until the packet is transmitted over the core interface, adding the DI measurement provided by the UE to ensure completeness.

[0081] On the UE side, a user plane approach based on PDCP Control PDUs is proposed to report the DI delay component. The UE may be configured to start and stop the measurement and calculation of the average UL packet delay DI component based on instructions from the gNB. The calculated average DI delay may then be reported back to the gNB using a newly defined PDCP Control PDU, ensuring that the reporting mechanism is both efficient and tightly integrated with the user plane operations.

[0082] The CU-UP may utilize the delay components received from the DU, including D2.1, D2.2, D2.3, and D2.4, to calculate the average UL packet delay over a configured duration. The CU-UP may then combine these measurements with the DI component received from the UE to determine the total UL packet delay. This comprehensive calculation is used to optimize network performance and may optionally be reported to the CU-CP if required.

[0083] The CU-CP, in scenarios where it is configured to receive the total UL packet delay, serves as the node responsible for consolidating and managing delay metrics for further use. This architecture ensures seamless integration of delay measurements across different layers and components, providing a unified and efficient approach to QoS monitoring and reporting.

[0084] Compared to the delay component -based approach defined in the current 3 GPP method, the proposed framework offers significant advantages. By introducing a user plane-based approach for exchanging the average UL packet delay DI component via the PDCP control PDU, the signaling load on the SRB is substantially reduced. This approach aligns directly with DRB scheduling, ensuring that the delay measurement process issynchronized with actual data activity on the bearer. Since the average UL packet delay DI is only relevant when there is uplink data available at the UE, this method eliminates unnecessary signaling and optimizes resource utilization.

[0085] Moreover, access to the UL packet delay at the CU-UP allows for intelligent optimization of data flows for the bearer. For instance, by implementing appropriate ECN marking based on the observed UL delay, the end-to-end delay can be effectively controlled for applications like L4S traffic, which are highly sensitive to latency. The user plane-based approach is particularly suited for frequent reporting, as it incurs less overhead compared to the RRC -based approach, making it an efficient and scalable solution for delay monitoring and reporting.

[0086] As an elementary procedure, a new F1AP procedure that allows the CU-CP to dynamically manage the inclusion of timestamps in uplink (UL) packets for specific DRBs at the DU is proposed. This enhancement is aimed at providing precise timing information for monitoring UL packet delays. The procedure involves the CU-CP sending a specialized message to the DU to activate the timestamping functionality. The timestamp represents the exact time the data was received at the DU over the Uu interface, offering granular insights into uplink transmission timing.

[0087] In an alternative approach, the procedure for including timestamps in UL packets may be designed to eliminate the need for signaling the Data Collection Duration to the DU 120. Instead of specifying the duration beforehand, the CU-CP 140 may directly activate the timestamp inclusion functionality at the DU 120. Once the desired Data Collection Duration has elapsed, the CU-CP 140 may then send a deactivation signal to the DU 120 to stop the inclusion of timestamps. This approach provides greater flexibility and control, as the CU-CP 140 may dynamically manage the activation and deactivation of timestamp inclusion based on the operational needs.

[0088] In another alternative approach, a non-UE-associated NGAP procedure is proposed to configure QoS Monitoring in the RAN. This procedure enables the core network to manage QoS Monitoring functionalities for various scopes, such as PLMN, Slice, Node, or Tracking Area (TA), without targeting specific UEs. This approach ensures that QoS Monitoring can be dynamically activated and applied across broader contexts, which will be discussed later in connection with FIG. 7.

[0089] To support the mechanism discussed in the above, it is proposed to enhance theDU 120 functionality to allow it to include a timestamp in the GTP header for each UL RLC packet associated with specific DRB IDs. The timestamp records the exact time the data is received at the DU 120 over the Uu interface. The timestamp may be carried via the GTP-U extension header shown in FIG. 2, in which the extension header length is set to be 8 octets. A new extension header type named 'Timestamp' may be defined, e.g., as shown in Table 1.Table 1

[0090] Referring now to FIG.3, which illustrates an example signaling process of the inclusion of packet timestamps in accordance with some embodiments in the disclosure.

[0091] The CU-CP 140 sends an Activate UL Packet Timestamp Reporting Request 201 to the DU 120. This request 301 contains configuration parameters necessary for timestamping. It may specify the DRB IDs (Bearer IDs) for which the timestamping should be applied, ensuring the function is targeted and does not impact all DRBs unnecessarily. The request may also include a control flag, set to true or false, to explicitly indicate whether timestamping should be enabled or disabled. Optionally, the CU-CP 140may also include the Data Collection Duration, defining the period during which the DU 120 is required to embed timestamps in the UL packets. This duration ensures the timestamping process operates within a specific timeframe and prevents indefinite operation.

[0092] Upon receiving this request, the DU 120 processes the instructions to prepare its resources for implementing the timestamping functionality. The DU 120 may respond with an acknowledgment message 302 indicating whether it is ready to begin timestamping the UL packets as requested.

[0093] After the timestamping process is activated, the DU 120 may begin the inclusion of timestamps in the UL packets for the specified DRBs. Each timestamp represents the precise moment the data was received at the DU 120. The inclusion of timestamps continues for the duration specified by the Data Collection Duration parameter. When this duration expires, the DU 120 automatically ceases to include timestamps in the UL packets, ensuring the operation aligns with the configured time limits.

[0094] Referring now to FIG. 4, which illustrates an example signaling process of the inclusion of packet timestamps in accordance with some embodiments in the disclosure. The DU 120 may begin the inclusion of timestamps in the UL packets 401 for the specified DRBs, in response to the activation of the timestamp inclusion by the CU-UP 130. The inclusion of timestamps may be ceased after the Data Collection Duration is expired, or in response to the de-activation of the timestamp inclusion by the CU-CP 140.

[0095] As discussed, the User Plane Function (UPF) in the CU is the preferred node within the NG-RAN to aggregate the UL PDCP average packet delay, as this measurement is inherently associated with the PDCP layer, which is where the delay is tracked and measured. Because of this, the PDCP layer serves as the natural protocol for transferring the UL PDCP average packet delay from the UE to the gNB. Given the importance of this measurement in network performance, the most efficient approach to exchange the UL PDCP average packet delay is through the extension of the PDCP Control PDU, the enhancement of which is illustrated in FIG. 5. By utilizing the PDCP Control PDU format, the gNB may ensure smooth and standardized reporting of the delay component between the UE and the gNB.

[0096] The gNB may be responsible for both initiating and controlling the periodic reporting of the UL PDCP average packet delay from the UE. This process is managedthrough the PDCP Control PDU, which provides a streamlined mechanism for communication between the UE and the gNB. The PDCP Control PDU allows for the exchange of the delay measurement in a structured manner, ensuring that both the UE and gNB are synchronized regarding the timing and frequency of the reports. The reported UL PDCP average packet delay measurements may be used to calculate the total UL packet delay, which may then be sent to the CU-CP for further processing, such as providing feedback to AI / ML models that optimize network behavior. The UL PDCP average packet delay may be included in a QMP, which may then be sent to the UPF for further analysis. Overall, using the PDCP Control PDU to exchange the UL PDCP average packet delay creates an efficient, scalable, and standardized approach to delay reporting that can be seamlessly integrated into the broader QoS management framework.

[0097] To achieve this, enhancements to the functionality of the PDCP Control PDU are proposed, in which new code words have been introduced: 100, 101, and 102. These code words are specifically designed to support the activation, deactivation, and reporting of the UL PDCP average packet delay measurement, facilitating better control and management of delay-related information in the network.

[0098] Referring now to FIG. 5, which illustrates example enhancements to the functionality of the PDCP Control PDU.

[0099] As shown in FIG. 5, code word 100 may be used to trigger the activation of the UL PDCP average packet delay measurement. When this code word is included in a PDCP Control PDU, it instructs the UE to begin measuring the packet delay for uplink PDCP transmissions, ensuring that the necessary data is collected for subsequent analysis.

[0100] Code word 101 may serve the purpose of deactivating the UL PDCP average packet delay measurement. When the PDCP Control PDU includes this code word, it signals the UE to stop measuring the uplink packet delay, effectively halting the collection of delay data. This feature provides network operators with the flexibility to control when delay measurements are active, thus optimizing resources and ensuring that delay reporting only occurs when necessary.

[0101] Code word 102 may be used to facilitate the reporting of the UL PDCP average packet delay measurement. By incorporating this code word in a PDCP Control PDU, the gNB can request the UE to send the measured delay data. The report generated in response to this command may include the UL PDCP average packet delay value, which is essentialfor calculating overall network performance and can be used for further optimization of the bearer flow, QoS monitoring, and AI / ML-driven feedback in the network.

[0102] Together, these new code words enhance the PDCP Control PDU’s ability to manage delay measurements efficiently, providing a standardized method for activating, deactivating, and reporting UL PDCP average packet delay information. This, in turn, allows for better network performance monitoring and optimization. The definition of each code word may be different from discussed depending on actual configurations.

[0103] Referring now to FIG. 6, which illustrates an example signaling process of UP based retrieval of packet delay component DI in accordance with some embodiments in the disclosure.

[0104] The process begins when the CU-CP 140 receives a Next Generation Application Protocol (NGAP): PDU Session Resource Setup Request 601 from the CN, e.g., from the AMF 150. This message may include an important parameter, the QoS Monitoring Request Information Element (IE), which is set to true. This parameter may explicitly request that QoS monitoring is activated for the specific PDU session. The CU-CP may process this request and prepare to configure the necessary elements in the network to enable uplink packet delay monitoring.

[0105] Following receipt of this request, the CU-CP 140 may send an E1AP: Bearer Context Setup Request 602 to the CU-UP 130. This message contains the QoS Monitoring Request IE, also set to true, as well as the details of the PDU session and the DRB IDs for which the delay measurements are to be configured. The CU-UP 130 may receive this configuration request, interpret it, and begin setting up the mechanisms required for measuring uplink packet delay.

[0106] After the CU-UP 130 completes its setup, it may send an E1AP: Bearer Context Setup Response 603 back to the CU-CP 140. This response serves as confirmation that the CU-UP 130 is ready to proceed with the uplink packet delay measurement process. It indicates that the necessary configurations, such as enabling delay measurement mechanisms and preparing to handle timestamped data packets, have been successfully applied.

[0107] The CU-CP 140 may then instruct the DU 120 to include timestamps in uplink data packets for the specified DRB IDs. To do this, the CU-CP 140 may send an ActivateUL Packet Timestamp Reporting Request 604 to the DU 120, specifying i) the DRB IDs for which the timestamping should be applied, ii) a control flag, set to true, to explicitly indicate the enabling of the timestamping and iii) optionally the Data Collection Duration, and instructing the DU 120 to insert a timestamp, referred to as Tl, into each uplink packet. This timestamp marks the exact time at which the UL grant was scheduled for the packet on the associated bearer. The DU 120 may interpret this instruction and prepare to implement timestamp inclusion for all uplink packets associated with the configured session.

[0108] After configuring the timestamp inclusion, the DU 120 may send an Activate UL Packet Timestamp Reporting Request Response 605 back to the CU-CP 140, confirming that it has successfully activated the timestamping functionality. At this stage, the DU 120 is ready to include the Tl timestamp in the uplink packets as soon as the data flow begins.

[0109] The CU-UP 130 may send a PDCP Control PDU 606 to the UE 110. This message may activate the UE’s capability to report its internal delay component, referred to as the delay component ZU. The delay component DI represents the delay experienced by uplink packets within the UE itself, which is an essential part of the overall UL packet delay measurement.

[0110] After uplink data transmission starts for the configured DRB IDs, the DU 120 may append 607 the Tl timestamp to each UL packet. This timestamp corresponds to the time when the UL grant for the bearer was scheduled. These timestamped packets are then forwarded to the CU-UP 130, along with their respective payloads. The CU-UP 130 may record another timestamp, referred to as T2, for each UL packet. The T2 timestamp indicates the exact time at which the packet is successfully received at the CU-UP, indicated as 609. Using the recorded timestamps Tl and T2, the CU-UP 130 may calculate the UL packet delay for each packet as the difference between T2 and TL[OHl] The CU-UP 130 may continue this process for all packets transmitted during the configured Data Collection Duration. Once the data collection period ends, the CU-UP 130 may compute the average UL packet delay, referred to as Al, by averaging the individual delay values across all sampled packets.

[0112] The UE 110 may measure its delay component for the uplink packets and calculate an average delay value, denoted as DI. The UE 110 may then send 608 this DI value to the CU-UP 130 via PDCP Control PDU (e.g., using the code word 102 in FIG. 5). Uponreceiving DI, the CU-UP 130 may combine it with Al to calculate the total average UL packet delay for the session as DI + Al The CU-UP 130 may then communicate this calculated total UL packet delay to the UPF 160 via a PDU session container over the NG- U interface.

[0113] After the data collection is complete, the CU-CP 140 may initiate the termination of the timestamping and delay monitoring process. If the Data Collection Duration was predefined, the DU 120 may automatically stop including timestamps in uplink packets once the duration expires. If not, the CU-CP 140 may send a De-activate UL Packet Timestamp Reporting Request 610 to the DU 120, instructing it to cease timestamp inclusion for the configured DRB IDs.

[0114] In response to the termination request or upon expiration of the Data Collection Duration, the DU 120 may stop appending T1 timestamps to uplink packets. This action implicitly halts the uplink delay calculation process in the CU-UP 130, as timestamped data packets are no longer being received. The CU-UP 130 may also send another PDCP Control PDU 612 to the UE 110, instructing it to stop measuring and reporting the DI delay component. This message signifies the end of the UL packet delay measurement and reporting process, effectively deactivating the QoS monitoring mechanisms for the session.

[0115] Referring now to FIG. 7, which illustrates an example signaling process of non- UE associated QMP activation in accordance with some embodiments in the disclosure.

[0116] The process begins with the AMF 150 sending a QMP Activation Request 701 to the CU-CP 140. This request may specify one or more QoS flows for which QoS monitoring is required. Along with the QoS Flow ID(s), the request may also define the scope of the monitoring, which may be set to one of the following values: PLMN (Public Land Mobile Network), Slice (specific network slice), Node (particular network node), or Tracking Area (TA). These parameters may guide the RAN on how to configure and apply the QoS monitoring.

[0117] After receiving the QMP Activation Request from the AMF 150, the CU-CP 140 may initiate the activation process by forwarding 702 the request to the CU-UP 130. This message may include the QoS Flow ID(s) and the specified scope, instructing the CU-UP 130 to prepare for QoS monitoring for the relevant flows. Once the CU-UP 130 processes the request and successfully configures the necessary monitoring mechanisms, it responds with a QMP Activation Response 703, indicating OK.

[0118] The CU-CP 140 may send the same QMP Activation Request 704 to the DU 120. The DU 120, like the CU-UP 130, may process the request to activate QoS monitoring for the relevant QoS flows and based on the specified scope. After successfully completing the configuration, the DU 120 may send its own QMP Activation Response 705, also indicating OK, back to the CU-CP 140.

[0119] After the CU-CP 140 receives successful QMP Activation Responses (OK) from both the CU-UP 130 and DU 120, it may aggregate these responses and send a final QMP Activation Response 706 to the AMF, confirming that QoS monitoring has been successfully activated across the RAN.

[0120] When a UE 110 registers with the network, the RAN may evaluate whether the UE 110 meets the configured QMP criteria. These criteria include factors such as the PLMN, Slice, and Tracking Area. If the UE 110 matches the criteria, the QoS monitoring functionality may be activated not only in the RAN but also in the UE 110 itself. The monitoring includes UL packet delay measurements, which are essential for evaluating and maintaining QoS. To initiate this, the CU-CP 140 may activate the DI delay measurement by signaling the UE 110 through an RRC Reconfiguration message 707. This message includes the ULDelayValueConfig, which provides the UE 110 with the necessary configuration parameters for measuring and reporting uplink delay, e.g., via the PDCP Control PDU, as discussed in the above. Upon successfully applying the configuration, the UE 110 may respond with an RRC Reconfiguration Complete message 708, indicating that the DI measurement functionality is now active. The CU-CP 140 may instruct the CU-UP 130 about the configuration and ensure that the CU-UP 130 is prepared to receive the uplink delay measurement from the UE. Here, the CU-UP’ s role is limited to receiving the PDCP Control PDU-based reports, as the CU-CP takes full responsibility for the configuration and activation process.

[0121] Alternatively, the CU-CP 140 may first configure the UE 110 using RRC signaling. After the configuration is completed, the CU-CP 140 may communicate the necessary information to the CU-UP 130, informing it about the activated setup. The CU- UP 130 may then take responsibility for managing the interaction with the UE 110, which involves activating and receiving the uplink delay measurement from the UE 110 in response to the RRC configuration via the PDCP Control PDU.

[0122] Alternatively, the CU-UP 130 may configure the UE 110 using PDCP ControlPDU with the activation and reporting of DI measurement, and the UE 110 may then report the DI measurement via the PDCP Control PDU, similary as discussed with reference to FIG. 6.

[0123] The DU 120 may activate its own measurement mechanisms to capture relevant QoS metrics. The CU-UP 130 may also activate its monitoring processes and prepare to report the measurement data to the UPF. For UL delay measurements, the DU 120 ensures that timestamps and relevant metrics are recorded and included in the data packets sent to the CU-UP 130.

[0124] As UL packets flow through the RAN, the CU-UP 130 may aggregate and process the measurement data collected from both the UE 110 and the DU 120. These measurements may be encapsulated in QMP GTP-U packets, which include the extension header specifically designed for carrying QoS monitoring metrics. The CU-UP 130 may send these packets to the UPF 160, providing the CN with detailed QoS performance data for the monitored flows.

[0125] As discussed, the CU-UP has full visibility into UL data activity as it directly handles the processing and forwarding of packets, the integration of the QoS reporting functionality within the CU-UP is without requiring additional signaling or coordination. The integration of QoS measurements directly in the CU-UP provides significant advantages in terms of real-time responsiveness, efficient resource utilization, and end- to-end flow optimization. In contrast, relying solely on RRC-based approaches requires additional signaling and may delay the activation of critical QoS mechanisms, reducing the agility of the system in adapting to changing network conditions.

[0126] It should be pointed out embodiments in the disclosure were described with QoS metric (UL packet delay) as the example metric, however, the metric may also be Quality of Experience (QoE) metrics.

[0127] FIG. 8 shows a flowchart of an example method 800 implemented at a network device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the network device 120 in FIG. 1.

[0128] At block 810, receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data ConvergenceProtocol (PDCP) Control Protocol Data Unit (PDU).

[0129] At block 820, determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow.

[0130] At block 830, reporting the aggregated value of the metric for the monitored QoS flow.

[0131] In some example embodiments, the method 800 further comprises: transmitting, to the terminal device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

[0132] In some example embodiments, the method 800 further comprises: causing an inclusion of a timestamp in an uplink (UL) packet by a lower layer protocol, the timestamp indicating the time instance at which the UL grant was scheduled for the terminal device for which the monitored QoS flow was configured; and. determining, based on the timestamp, at least one further value of the metric for the monitored QoS flow.

[0133] In some example embodiments, the at least one further value of the metric for the monitored QoS flow is determined based on the timestamp and a further timestamp indicating the time instance at which the UL packet was received at a user plane function.

[0134] In some example embodiments, the method 800 further comprises: determining, based on the at least one further value, the aggregated value of the metric for the monitored QoS flow.

[0135] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0136] In some example embodiments, the method 800 further comprises: transmitting, to the lower layer protocol, an indication of a duration, indicating the time duration for the inclusion of the timestamp.

[0137] In some example embodiments, the method 800 further comprises: causing, the inclusion of the timestamp in the uplink packet by the lower layer protocol to cease.

[0138] In some example embodiments, the timestamp is transmitted over GPRS Tunneling Protocol - User Plane (GTP-U) packet using an extension header.

[0139] In some example embodiments, the GTP-U packet is transmitted over at least one of: the NG-U interface, the Fl-U interface or the Xn-U interface.

[0140] In some example embodiments, the metric for the monitored QoS flow is a QoS metric.

[0141] In some example embodiments, the metric for the monitored QoS flow is uplink packet delay.

[0142] In some example embodiments, the metric for the monitored QoS flow is a Quality of Experience (QoE) metric.

[0143] FIG. 9 shows a flowchart of an example method 900 implemented at a terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the terminal device 110 in FIG. 1.

[0144] At block 910, determining at least one value of a metric for a monitored Quality of Service (QoS) flow.

[0145] At block 920, transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0146] In some example embodiments, the method 900 further comprises: in response to receiving, from the network device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU, enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

[0147] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0148] In some example embodiments, the metric for the monitored QoS flow is a QoS metric.

[0149] In some example embodiments, the metric for the monitored QoS flow is uplink packet delay.

[0150] In some example embodiments, the metric for the monitored QoS flow is a Quality of Experience (QoE) metric.

[0151] FIG. 10 shows a flowchart of an example method 1000 implemented at a network device in accordance with some example embodiments of the present disclosure. For thepurpose of discussion, the method 1000 will be described from the perspective of the network device 120 in FIG. 1.

[0152] At block 1010, receiving a Quality of Service (QoS) configuration message indicating at least one monitored QoS flow and corresponding monitored scope.

[0153] At block 1020, receiving, from a terminal device, at least one first value of a QoS metric for the at least one monitored QoS flow transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0154] At block 1030, determining, based on the at least one first value, at least one aggregated value of the QoS metric for the at least one monitored QoS flow.

[0155] In some example embodiments, the method 1000 further comprises: causing an inclusion of a first timestamp in an uplink (UL) packet by a lower layer protocol, the first timestamp indicating the time instance at which a UL grant was scheduled for the terminal device for which the at least one monitored Quality of Service (QoS) flow was configured, and retrieving a second timestamp of the UL packet, the second timestamp indicating the time instance at which the UL packet was received at a user plane function; and determining, further based on the first and the second timestamp, the at least one aggregated value of the QoS metric for the monitored QoS flow.

[0156] In some example embodiments, the at least one monitored QoS flow is Data Radio Bearer (DRB) configured by a control function.

[0157] In some example embodiments, the monitored scope comprises one of the: Public Land Mobile Network (PLMN), slice, node, or Tracking Area (TA).

[0158] In some example embodiments, the terminal device is located in the monitored scope.

[0159] In some example embodiments, the QoS metric for the at least one monitored QoS flow is uplink packet delay.

[0160] In some example embodiments, the timestamp is transmitted over GPRS Tunneling Protocol - User Plane (GTP-U) packet using an extension header.

[0161] In some example embodiments, the GTP-U packet is transmitted over at least one of: the NG-U interface, the Fl-U interface or the Xn-U interface.

[0162] In some example embodiments, the QoS configuration message is received froman upper layer protocol.

[0163] FIG. 11 shows a flowchart of an example method 1100 implemented at a terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 1100 will be described from the perspective of the terminal device 110 in FIG. 1.

[0164] At block 1110, in response to a determination that the terminal device is located in a Quality of Service (QoS) monitored scope, determining at least one value of a QoS metric for a monitored QoS flow.

[0165] At block 1120, transmitting, to a network device, the at least one value of the QoS metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0166] In some example embodiments, the method 1100 further comprises: in response to receiving, from the network device, an indication to enable / disable the transmission of values of the QoS metric for the monitored QoS flow via the PDCP Control PDU, enable / disable the transmission of values of the QoS metric for the monitored QoS flow via the PDCP Control PDU.

[0167] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0168] In some example embodiments, the monitored scope comprises one of the: Public Land Mobile Network (PLMN), slice, node, or Tracking Area (TA).

[0169] In some example embodiments, the QoS metric for the monitored QoS flow is uplink packet delay.

[0170] In some example embodiments, a network device capable of performing any of the method 800 (for example, the network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The network device may be implemented as or included in the network device 120 in FIG. 1.

[0171] In some example embodiments, the network device comprises means for receiving, from a terminal device, at least one value of a metric for a monitored Qualityof Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); means for determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and means for reporting the aggregated value of the metric for the monitored QoS flow.

[0172] In some example embodiments, the network device further comprises: means for transmitting, to the terminal device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

[0173] In some example embodiments, the network device further comprises: means for causing an inclusion of a timestamp in an uplink (UL) packet by a lower layer protocol, the timestamp indicating the time instance at which the UL grant was scheduled for the terminal device for which the monitored QoS flow was configured; and. means for determining, based on the timestamp, at least one further value of the metric for the monitored QoS flow.

[0174] In some example embodiments, the at least one further value of the metric for the monitored QoS flow is determined based on the timestamp and a further timestamp indicating the time instance at which the UL packet was received at a user plane function.

[0175] In some example embodiments, the network device further comprises: means for determining, based on the at least one further value, the aggregated value of the metric for the monitored QoS flow.

[0176] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0177] In some example embodiments, the network device further comprises: means for transmitting, to the lower layer protocol, an indication of a duration, indicating the time duration for the inclusion of the timestamp.

[0178] In some example embodiments, the network device further comprises: means for causing, the inclusion of the timestamp in the uplink packet by the lower layer protocol to cease.

[0179] In some example embodiments, the timestamp is transmitted over GPRS Tunneling Protocol - User Plane (GTP-U) packet using an extension header.

[0180] In some example embodiments, the GTP-U packet is transmitted over at least oneof: the NG-U interface, the Fl-U interface or the Xn-U interface.

[0181] In some example embodiments, the metric for the monitored QoS flow is a QoS metric.

[0182] In some example embodiments, the metric for the monitored QoS flow is uplink packet delay.

[0183] In some example embodiments, the metric for the monitored QoS flow is a Quality of Experience (QoE) metric.

[0184] In some example embodiments, a terminal device capable of performing any of the method 900 (for example, the terminal device 110 in FIG. 1) may comprise means for performing the respective operations of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The terminal device may be implemented as or included in the terminal device 110 in FIG. 1.

[0185] In some example embodiments, the terminal device comprises means for determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and means for transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0186] In some example embodiments, the terminal device further comprises: means for in response to receiving, from the network device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU, enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

[0187] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0188] In some example embodiments, the metric for the monitored QoS flow is a QoS metric.

[0189] In some example embodiments, the metric for the monitored QoS flow is uplink packet delay.

[0190] In some example embodiments, the metric for the monitored QoS flow is aQuality of Experience (QoE) metric.

[0191] In some example embodiments, a network device capable of performing any of the method 1000 (for example, the network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The network device may be implemented as or included in the network device 120 in FIG. 1.

[0192] In some example embodiments, the network device comprises means for receiving a Quality of Service (QoS) configuration message indicating at least one monitored QoS flow and corresponding monitored scope; means for receiving, from a terminal device, at least one first value of a QoS metric for the at least one monitored QoS flow transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU) ; and means for determining, based on the at least one first value, at least one aggregated value of the QoS metric for the at least one monitored QoS flow.

[0193] In some example embodiments, the network device further comprises: means for causing an inclusion of a first timestamp in an uplink (UL) packet by a lower layer protocol, the first timestamp indicating the time instance at which a UL grant was scheduled for the terminal device for which the at least one monitored Quality of Service (QoS) flow was configured, and means for retrieving a second timestamp of the UL packet, the second timestamp indicating the time instance at which the UL packet was received at a user plane function; and means for determining, further based on the first and the second timestamp, the at least one aggregated value of the QoS metric for the monitored QoS flow.

[0194] In some example embodiments, the at least one monitored QoS flow is Data Radio Bearer (DRB) configured by a control function.

[0195] In some example embodiments, the monitored scope comprises one of the: Public Land Mobile Network (PLMN), slice, node, or Tracking Area (TA).

[0196] In some example embodiments, the terminal device is located in the monitored scope.

[0197] In some example embodiments, the QoS metric for the at least one monitored QoS flow is uplink packet delay.

[0198] In some example embodiments, the timestamp is transmitted over GPRS Tunneling Protocol - User Plane (GTP-U) packet using an extension header.

[0199] In some example embodiments, the GTP-U packet is transmitted over at least one of: the NG-U interface, the Fl-U interface or the Xn-U interface.

[0200] In some example embodiments, the QoS configuration message is received from an upper layer protocol.

[0201] In some example embodiments, a terminal device capable of performing any of the method 1100 (for example, the terminal device 110 in FIG. 1) may comprise means for performing the respective operations of the method 1100. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The terminal device may be implemented as or included in the terminal device 110 in FIG. 1.

[0202] In some example embodiments, the terminal device comprises means for in response to a determination that the terminal device is located in a Quality of Service (QoS) monitored scope, determining at least one value of a QoS metric for a monitored QoS flow; and means for transmitting, to a network device, the at least one value of the QoS metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

[0203] In some example embodiments, the terminal device further comprises: means for in response to receiving, from the network device, an indication to enable / disable the transmission of values of the QoS metric for the monitored QoS flow via the PDCP Control PDU, enable / disable the transmission of values of the QoS metric for the monitored QoS flow via the PDCP Control PDU.

[0204] In some example embodiments, the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

[0205] In some example embodiments, the monitored scope comprises one of the: Public Land Mobile Network (PLMN), slice, node, or Tracking Area (TA).

[0206] In some example embodiments, the QoS metric for the monitored QoS flow is uplink packet delay.

[0207] FIG. 12 is a simplified block diagram of a device 1200 that is suitable forimplementing example embodiments of the present disclosure. The device 1200 may be provided to implement a communication device, for example, the terminal device 110 or the network device 120 as shown in FIG. 1. As shown, the device 1200 includes one or more processors 1210, one or more memories 1220 coupled to the processor 1210, and one or more communication modules 1240 coupled to the processor 1210.

[0208] The communication module 1240 is for bidirectional communications. The communication module 1240 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 1240 may include at least one antenna.

[0209] The processor 1210 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1200 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0210] The memory 1220 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1224, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), an optical disk, a laser disk, and other magnetic storage and / or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 1222 and other volatile memories that will not last in the power-down duration.

[0211] A computer program 1230 includes computer executable instructions that are executed by the associated processor 1210. The instructions of the program 1230 may include instructions for performing operations / acts of some example embodiments of the present disclosure. The program 1230 may be stored in the memory, e.g., the ROM 1224. The processor 1210 may perform any suitable actions and processing by loading the program 1230 into the RAM 1222.

[0212] The example embodiments of the present disclosure may be implemented bymeans of the program 1230 so that the device 1200 may perform any process of the disclosure as discussed with reference to FIG. 2 to FIG. 12. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[0213] In some example embodiments, the program 1230 may be tangibly contained in a computer readable medium which may be included in the device 1200 (such as in the memory 1220) or other storage devices that are accessible by the device 1200. The device 1200 may load the program 1230 from the computer readable medium to the RAM 1222 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0214] FIG. 13 shows an example of the computer readable medium 1300 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1300 has the program 1230 stored thereon.

[0215] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method 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.

[0216] Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non- transitory computer readable medium. The computer program product includes computerexecutable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries,objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0217] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0218] In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[0219] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0220] Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may beadvantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment.Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

[0221] Although the present disclosure has been described in languages specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

I / We Claim:

1. A network device comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the network device at least to: receive, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); determine, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and report the aggregated value of the metric for the monitored QoS flow.

2. The network device of any of claims 1, wherein the network device is caused to: transmit, to the terminal device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

3. The network device of any of claims 1 to 2, wherein the network device is caused to: cause an inclusion of a timestamp in an uplink (UL) packet by a lower layer protocol, the timestamp indicating the time instance at which the UL grant was scheduled for the terminal device for which the monitored QoS flow was configured; and. determine, based on the timestamp, at least one further value of the metric for the monitored QoS flow.

4. The network device of any of claims 1 to 3, wherein the at least one further value of the metric for the monitored QoS flow is determined based on the timestamp and a further timestamp indicating the time instance at which the UL packet was received at a user plane function.

5. The network device of any of claims 3 to 4, wherein the network device is caused to: determine, based on the at least one further value, the aggregated value of themetric for the monitored QoS flow.

6. The network device of any of claims 1 to 5, wherein the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

7. The network device of any of claims 1 to 6, wherein the network device is caused to: transmit, to the lower layer protocol, an indication of a duration, indicating the time duration for the inclusion of the timestamp.

8. The network device of any of claims 1 to 6, wherein the network device is caused to: cause, the inclusion of the timestamp in the uplink packet by the lower layer protocol to cease.

9. The network device of any of claims 3 to 8, wherein the timestamp is transmitted over GPRS Tunneling Protocol - User Plane (GTP-U) packet using an extension header.

10. The network device of claim 9, wherein the GTP-U packet is transmitted over at least one of: the NG-U interface, the Fl-U interface or the Xn-U interface.

11. The network device of any of claims 1 to 10, wherein the metric for the monitored QoS flow is a QoS metric.

12. The network device of any claims of 1 to 11, wherein the metric for the monitored QoS flow is uplink packet delay.

13. The network device of any claims of 1 to 12, wherein the metric for the monitored QoS flow is a Quality of Experience (QoE) metric.

14. A terminal device, comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the terminal device at least to:determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and transmit, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

15. The terminal device of claim 14, wherein the terminal device is caused to: in response to receiving, from the network device, an indication to enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU, enable / disable the transmission of values of the metric for the monitored QoS flow via the PDCP Control PDU.

16. The terminal device of any of claims 14 to 15, wherein the monitored QoS flow is a Data Radio Bearer (DRB) configured by a control function.

17. The terminal device of any of claims 14 to 16, wherein the metric for the monitored QoS flow is a QoS metric.

18. The terminal device of any of claims 14 to 17, wherein the metric for the monitored QoS flow is uplink packet delay.

19. The terminal device of any of claims 14 to 18, wherein the metric for the monitored QoS flow is a Quality of Experience (QoE) metric.

20. A method comprising: receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and reporting the aggregated value of the metric for the monitored QoS flow.

21. A method comprising: determining at least one value of a metric for a monitored Quality of Service (QoS)flow; and transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

22. A network device comprising: means for receiving, from a terminal device, at least one value of a metric for a monitored Quality of Service (QoS flow) transmitted via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU); means for determining, based on the at least one value, an aggregated value of the metric for the monitored QoS flow; and means for reporting the aggregated value of the metric for the monitored QoS flow.

23. A terminal device comprising: means for determining at least one value of a metric for a monitored Quality of Service (QoS) flow; and means for transmitting, to a network device, the at least one value of the metric for the monitored QoS flow via a Packet Data Convergence Protocol (PDCP) Control Protocol Data Unit (PDU).

24. A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of claim 20 or the method of claim 21.

25. A computer program comprising instructions for causing an apparatus at least to perform the method of claim 20 or the method of claim 21.

Images