Configurable granularity for measuring and reporting transmission latency in wireless networks - Patents.com

Abstract

The present disclosure relates generally to wireless communication systems and methods, and in particular to monitoring and reporting of uplink and downlink data transmission latencies according to configurable timing and data granularity. Various example implementations disclosed herein provide mechanisms for the network side of a wireless network system to flexibly configure monitoring, measuring, calculating, and reporting of information related to downlink and uplink data transmission latencies among various network nodes, devices, and entities, and in coordination between the control plane and user plane of the wireless network.

Description

[Technical field]

[0001] Technical Field The present disclosure relates generally to wireless communication systems and methods, and more particularly to monitoring and reporting uplink and downlink data transmission delays according to configurable timing and data granularity. [Background technology]

[0002] background Data transmission between a wireless terminal and a core network in a wireless communication system may depend on both an over-the-air wireless communication interface between the wireless terminal and a radio access network node, and one or more communication interfaces between the radio access network node and the core network. The end-to-end time delay or latency (these two terms are used interchangeably in this disclosure) for such data transmission constitutes an important performance indicator of a wireless communication system, especially for Ultra-Reliable Low Latency Communication (URLLC) applications. Effective monitoring and reporting of such end-to-end communication delays facilitates diagnosis and improvement of wireless network transmission capabilities. Summary of the Invention [Means for solving the problem]

[0003] overview The present disclosure relates generally to wireless communication systems and methods, and in particular to monitoring and reporting of uplink and downlink data transmission delays according to configurable timing and data granularity. Various exemplary implementations disclosed herein provide mechanisms for the network side of a wireless network system to flexibly configure monitoring, measuring, calculating, and reporting of information related to downlink and uplink data transmission latency among various network nodes, devices, and entities, and in coordination between the control plane and user plane of the wireless network. The disclosed implementations provide configurable network latency segmentation schemes, as well as configurable timing, data or data flow granularity, content, and formats for monitoring / measuring / calculating / reporting of associated latency information. Thus, various network devices or nodes are coordinated under adaptive configurations by the network to efficiently monitor, measure, calculate, and report latency information adapted to the needs of a particular application and a particular data communication session. A dedicated protocol data unit (PDU) is also designed and constructed for reporting latency information in the user plane.

[0004] In some example implementations, a method is disclosed for provisioning a data transmission delay between a wireless terminal device and a core network by a radio access network node of a wireless network. The method may include receiving a transmission delay configuration from the core network, the transmission delay configuration specifying at least one of a transmission delay provisioning segmentation scheme from a plurality of segmentation schemes or a monitoring / reporting configuration for data transmission delay from a plurality of monitoring / reporting configurations. The method may further include transmitting at least a portion of the transmission delay configuration to the wireless terminal device, receiving a transmission delay information item from the wireless terminal device during a data transmission session between the core network and the wireless terminal device, and generating and transmitting a report according to the transmission delay configuration based on the transmission delay information item to the core network.

[0005] In the above implementations, the transmission delay provisioning segmentation scheme may include one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

[0006] In any of the above implementations, the monitoring / reporting configuration includes at least one of a reporting timing configuration, a reporting granularity configuration, or a data packet transmission timestamp scheme.

[0007] In any of the above implementations, the reporting timing configuration indicates a reporting frequency or a reporting time period.

[0008] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as at least one of an average data packet delay, a per-packet delay, a packet delay distribution, or packet delay distributed information.

[0009] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a packet delay distribution, the packet delay distribution being included in an uplink protocol data unit (PDU) session frame including a first field indicating a number of delay ranges and a plurality of blocks of fields, each block of fields including a number of packets having a latency value that falls within one of the delay ranges.

[0010] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as packet delay distribution information, the packet delay distribution information being included in an uplink protocol data unit (PDU) session frame, the uplink PDU session frame including a first field for identifying the packet delay distribution equation, a second field for indicating a number of parameters associated with the packet delay distribution equation, and a block of fields including a value of the number of parameters.

[0011] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay, the per-packet delay being included in an uplink protocol data unit (PDU) session frame, the PDU session frame including a first field indicating a number of per-packet delay samples and a plurality of second fields each including a per-packet delay sample.

[0012] In any of the above implementations, the data packet transmission timestamp scheme indicates one of including a transmission timestamp in a data packet header or including a transmission timestamp in a packet data convergence protocol header.

[0013] In any of the above implementations, the data transmission delay is associated with the user plane of the wireless network.

[0014] In any of the above implementations, the data transmission delay includes a downlink user plane data transmission delay.

[0015] In any of the above implementations, the method further includes relaying at least one downlink data packet from the core network to the wireless terminal device, wherein the transmission delay information item associated with the at least one downlink data packet includes end-to-end downlink transmission delay information or RAN part downlink transmission delay information associated with the at least one downlink data packet received from the wireless terminal device in a control plane of the radio access network node and calculated by the wireless terminal device.

[0016] In any of the above implementations, the transmission delay information item is received in the control plane of the radio access network node as part of a Radio Resource Control (RRC) measurement report.

[0017] In any of the above implementations, generating and transmitting the report to the core network includes inserting the report into a NG Application Protocol (NGAP) message and transmitting the NGAP message to the core network in a control plane.

[0018] In any of the above implementations, generating and transmitting the report to the core network includes inserting the report into an E1 Application Protocol (E1AP) message in a control plane and transmitting the E1AP message to a user plane of the radio access network node, extracting the report from the E1AP message and inserting the report into a PDU session information PDU in the user plane of the radio access network node, and transmitting the PDU session information PDU to the core network in the user plane.

[0019] In any of the above implementations, the data transmission delay includes an uplink user plane data transmission delay.

[0020] In any of the above implementations, the transmission delay information item received from the wireless terminal device includes timestamp information of at least one uplink data packet transmitted from the wireless terminal device.

[0021] In any of the above implementations, the timestamp information of the at least one uplink data packet transmitted from the wireless terminal device is included in a header of the at least one uplink data packet.

[0022] In any of the above implementations, the transmission delay provisioning segmentation scheme includes an end-to-end delay scheme, and generating and transmitting a report to the core network in accordance with the transmission delay configuration includes relaying the timestamp information to the core network for the core network to calculate the data transmission delay.

[0023] In any of the above implementations, the transmission delay provisioning segmentation scheme includes a RAN partial delay scheme, and generating and transmitting a report to the core network according to the transmission delay configuration includes calculating RAN partial delay information associated with at least one uplink data packet in a user plane of the radio access network node, transmitting the RAN partial delay information to a control plane of the radio access network node, and transmitting the RAN partial delay information in the control plane to the core network via an NGAP message.

[0024] In any of the above implementations, the transmission delay provisioning segmentation scheme includes a RAN partial delay scheme, and generating and transmitting a report to the core network according to the transmission delay configuration includes calculating RAN partial delay information associated with at least one uplink data packet in a user plane of the radio access network node, and transmitting the RAN partial delay information to the core network to the core network in the user plane via an uplink PDU session information PDU.

[0025] In some other implementations, a method is disclosed for monitoring / reporting a data transmission delay between the wireless terminal device and a core network in a wireless network by a wireless terminal device. The method may include receiving a transmission delay configuration from a control plane of a radio access network node, the transmission delay configuration specifying at least one of a transmission delay provisioning segmentation scheme from a plurality of segmentation schemes or a monitoring / reporting configuration for data transmission delay from a plurality of monitoring / reporting configurations. The method may further include transmitting a transmission delay information item to the radio access network node during a data transmission session between the core network and the wireless terminal device according to the transmission delay configuration.

[0026] In the above implementation, the transmission delay provisioning segmentation scheme includes one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

[0027] In any of the above implementations, the monitoring / reporting configuration includes at least one of a reporting timing configuration, a reporting granularity configuration, or a data packet transmission timestamp scheme.

[0028] In any of the above implementations, the reporting timing configuration indicates a reporting frequency or a reporting time period.

[0029] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as at least one of an average data packet delay, a per-packet delay, a packet delay distribution, or packet delay distributed information.

[0030] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a packet delay distribution, the packet delay distribution being included in an uplink protocol data unit (PDU) session frame including a first field indicating a number of delay ranges and a plurality of blocks of fields, each block of fields including a number of packets having a delay value that falls within one of the delay ranges.

[0031] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as packet delay distribution information, the packet delay distribution information being included in an uplink protocol data unit (PDU) session frame, the uplink PDU session frame including a first field for identifying the packet delay distribution equation, a second field for indicating a number of parameters associated with the packet delay distribution equation, and a block of fields including a value of the number of parameters.

[0032] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay, the per-packet delay being included in an uplink protocol data unit (PDU) session frame, the uplink PDU session frame including a first field indicating a number of per-packet delay samples and a plurality of second fields each including a per-packet delay sample.

[0033] In any of the above implementations, the data packet transmission timestamp scheme indicates one of including a transmission timestamp in a data packet header or including a transmission timestamp in a packet data convergence protocol header.

[0034] In any of the above implementations, the data transmission delay is associated with the user plane of the wireless network.

[0035] In any of the above implementations, the data transmission delay includes a downlink user plane data transmission delay.

[0036] In any of the above implementations, the method further includes obtaining reception timestamp information of the at least one downlink data packet, and generating a transmission delay information item by calculating end-to-end downlink transmission delay information or RAN part downlink transmission delay information associated with the at least one downlink data packet according to the reception timestamp information and the transmission delay configuration, wherein the transmission delay information item is transmitted to a control plane of the radio access network node.

[0037] In any of the above implementations, the transmission delay information item is transmitted as part of a Radio Resource Control (RRC) measurement report.

[0038] In any of the above implementations, the data transmission delay includes an uplink user plane data transmission delay.

[0039] In any of the above implementations, the transmission delay information item includes timestamp information of at least one uplink data packet transmitted from the wireless terminal device.

[0040] In any of the above implementations, the timestamp information of the at least one uplink data packet transmitted from the wireless terminal device is included in a header of the at least one uplink data packet.

[0041] In yet some other implementations, a method is disclosed for provisioning a data transmission delay between a wireless terminal device and the core network by a core network node of a wireless network. The method may include transmitting a transmission delay configuration to the radio access network node, where the transmission delay configuration specifies at least one of a transmission delay provisioning segmentation scheme from a plurality of segmentation schemes or a monitoring / reporting configuration for the data transmission delay from a plurality of monitoring / reporting configurations. The method may further include receiving a transmission delay information item from the radio access network node during a data transmission session between the core network node and the wireless terminal device, where the transmission delay information item is generated by the radio access network node or the wireless terminal device according to the transmission delay configuration.

[0042] In the above implementation, the transmission delay provisioning segmentation scheme includes one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

[0043] In any of the above implementations, the monitoring / reporting configuration includes at least one of a reporting timing configuration, a reporting granularity configuration, or a data packet transmission timestamp scheme.

[0044] In any of the above implementations, the reporting timing configuration indicates a reporting frequency or a reporting time period.

[0045] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as at least one of an average data packet delay, a per-packet delay, a packet delay distribution, or packet delay distributed information.

[0046] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a packet delay distribution, the packet delay distribution being included in an uplink protocol data unit (PDU) session frame including a first field indicating a number of delay ranges and a plurality of blocks of fields, each block of fields including a number of packets having a delay value that falls within one of the delay ranges.

[0047] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as packet delay distribution information, the packet delay distribution information being included in an uplink protocol data unit (PDU) session frame, the uplink PDU session frame including a first field for identifying the packet delay distribution equation, a second field for indicating a number of parameters associated with the packet delay distribution equation, and a block of fields including a value of the number of parameters.

[0048] In any of the above implementations, the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay, the per-packet delay being included in an uplink protocol data unit (PDU) session frame, the uplink PDU session frame including a first field indicating a number of per-packet delay samples and a plurality of second fields each including a per-packet delay sample.

[0049] In any of the above implementations, the data packet transmission timestamp scheme indicates one of including a transmission timestamp in a data packet header or including a transmission timestamp in a packet data convergence protocol header.

[0050] In any of the above implementations, the data transmission delay is associated with the user plane of the wireless network.

[0051] In any of the above implementations, the data transmission delay includes a downlink user plane data transmission delay.

[0052] In any of the above implementations, the transmission delay information item includes end-to-end downlink transmission delay information or RAN part downlink transmission delay information received from a radio access network node and calculated by the wireless terminal device and associated with at least one downlink data packet relayed by the radio access network node.

[0053] In any of the above implementations, the transmission delay information item is received from a control plane of a radio access network node in a NG Application Protocol (NGAP) message.

[0054] In any of the above implementations, the transmission delay information item is received from the user plane of the radio access network node as a header in a PDU session information PDU.

[0055] In any of the above implementations, the transmission delay information item includes RAN portion downlink transmission delay information, and the method further includes calculating end-to-end downlink transmission delay information based on the transmission delay information item and core-to-access transmission delay information associated with the at least one downlink data packet.

[0056] In any of the above implementations, the transmission delay provisioning segmentation scheme includes an end-to-end delay scheme, and the transmission delay information item includes timestamp information for transmitting at least one uplink data packet from the wireless terminal device.

[0057] In any of the above implementations, the transmission delay provisioning segmentation scheme includes a RAN partial delay scheme, and the transmission delay information item includes RAN partial delay information calculated by the radio access network node.

[0058] In any of the above implementations, the transmission delay information item is received in an NGAP message from a control plane of a radio access network node.

[0059] In any of the above implementations, the transmission delay information item is received in a PDU session information PDU from a user plane of the radio access network node.

[0060] In some other implementations, a wireless device is disclosed that includes a processor and a memory. The processor may be configured to read computer code from the memory to perform any one of the methods described above.

[0061] In yet some other implementations, a computer program product is disclosed that includes a non-transitory computer-readable program medium having computer code stored thereon that, when executed by a processor, can cause the processor to perform any one of the methods described above.

[0062] The above embodiments, as well as other aspects and alternatives of their implementations, are described in more detail in the following drawings, description, and claims. [Brief description of the drawings]

[0063] [Figure 1] FIG. 1 illustrates an exemplary wireless communication network comprising a radio access network, a core network, and a data network.

[0064] [Diagram 2] FIG. 2 illustrates an exemplary radio access network including multiple mobile stations or UEs and radio access network nodes communicating with each other via an over-the-air radio communication interface.

[0065] [Diagram 3]FIG. 3 shows a split architecture for separating a radio access network node into a central unit (CU) and one or more distributed units (DU).

[0066] [Figure 4] FIG. 4 illustrates various network functions of an exemplary core network.

[0067] [Diagram 5] FIG. 5 illustrates various network functions of an exemplary 5G core network.

[0068] [Figure 6] FIG. 6 shows an example flow for configuring QoS flows with QoS latency monitoring and reporting in a core network, an access network, and a wireless terminal.

[0069] [Figure 7] FIG. 7 shows an example flow for configurable downlink end-to-end latency monitoring, measurement, calculation, and reporting.

[0070] [Figure 8] FIG. 8 shows an example flow for configurable uplink end-to-end latency monitoring, measurement, calculation, and reporting.

[0071] [Figure 9] FIG. 9 shows an example flow for configurable downlink RAN ​​partial latency monitoring, measurement, calculation, and reporting.

[0072] [Figure 10] FIG. 10 shows an example flow for configurable uplink RAN ​​partial latency monitoring, measurement, calculation, and reporting. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0073] Detailed Description Techniques and examples of implementations and / or embodiments described in this disclosure can be used to facilitate configuration, monitoring, and reporting of data transmission delays in wireless communication network systems. The term "exemplary" is used to mean "an example of" and is not intended to mean an ideal or preferred example, implementation, or embodiment unless otherwise specified. Section headers are used in this disclosure to facilitate understanding of the disclosed implementations and are not intended to limit the disclosed techniques in a section to only the corresponding section. The disclosed implementations may be further embodied in various different forms, and thus, it is intended that the scope of the present disclosure or claimed subject matter not be construed as being limited to any of the embodiments described below. The various implementations may be embodied as methods, devices, components, systems, or non-transitory computer-readable media. Thus, embodiments of the present disclosure may take the form of, for example, hardware, software, firmware, or any combination thereof.

[0074] The present disclosure is particularly directed to monitoring and reporting of uplink and downlink data transmission delays according to configurable timing and data granularity. Various exemplary implementations disclosed herein provide mechanisms for the network side of a wireless network system to flexibly configure monitoring, measuring, calculating, and reporting of information related to downlink and uplink data transmission latency among various network nodes, devices, and entities, and in coordination between the control plane and user plane of the wireless network. The disclosed implementations provide configurable network latency segmentation schemes, as well as configurable timing, data or data flow granularity, content, and formats for monitoring / measuring / calculating / reporting related latency information. Thus, various network devices or nodes are coordinated under adaptive configurations by the network to efficiently monitor, measure, calculate, and report latency information adapted to the needs of a particular application and a particular data communication session. A dedicated protocol data unit (PDU) is also designed and constructed for reporting latency information in the user plane.

[0075] Wireless Network Overview An exemplary wireless communication network shown as 100 in FIG. 1 may include wireless terminal devices or user equipment (UE) 110, 111, and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102 may include, for example, access networks 120 and 121, and a core network 130. The carrier network 110 may be configured to transport voice, data, and other information (collectively referred to as data traffic) among the UEs 110, 111, and 112, between the UEs and the service applications 140, or between the UEs and other data networks 150. The access networks 120 and 121 may be configured as various radio access network nodes (WANNs, alternatively referred to as base stations) for interacting with the UEs on one side of a communication session and the core network 130 on the other side. The core network 130 may include various network nodes configured to control the communication sessions and perform network access management and traffic routing. The service applications 140 may be hosted by various application servers located outside but connected to the core network 130. Similarly, other data networks 150 may also be connected to the core network 130.

[0076] In the wireless communication network of 100 in FIG. 1, UEs may communicate with each other via radio access networks. For example, UEs 110 and 112 may be connected to and communicate via the same access network 120. UEs may communicate with each other via both access networks and core networks. For example, UE 110 may be connected to access network 120, while UE 111 may be connected to access network 121, and thus UE 110 and UE 111 may communicate with each other via access networks 120 and 121, as well as core network 130. UEs may further communicate with service applications 140 and data network 150 via core network 130. Additionally, UEs may directly communicate with each other via sidelink communication, as indicated by 113.

[0077] FIG. 2 further illustrates an example system diagram of the radio access network 120 including a WANN 202 serving the UEs 110 and 112 via an over-the-air interface 204. The radio transmission resources for the over-the-air interface 204 include a combination of frequency, time, and space resources. Each of the UEs 110 and 112 may be a mobile or fixed terminal device installed with a mobile access unit, such as a SIM / USIM module, for accessing the wireless communication network 100. Each of the UEs 110 and 112 may be implemented as a terminal device including, but not limited to, a mobile phone, a smartphone, a tablet, a laptop computer, a vehicle mounted communication device, a roadside communication device, a sensor device, a smart appliance (such as a television, refrigerator, oven, etc.), or other device capable of wirelessly communicating over a network. As illustrated in FIG. 2, each of the UEs, such as the UE 112, may include a transceiver circuit 206 coupled to one or more antennas 208 for effecting wireless communication with the WANN 120 or another UE, such as the UE 110. The transceiver circuitry 206 may also be coupled to a processor 210, which may also be coupled to a memory 212 or other storage device. The memory 212 may be temporary or non-transitory and may store computer instructions or code that, when read and executed by the processor 210, cause the processor 210 to perform various ones of the methods described herein.

[0078] Similarly, the WANN 120 may include base stations or other wireless network access points that may wirelessly communicate with one or more UEs via the over the air interface 204 and communicate with the core network 130. For example, the WANN 120 may be implemented in the form of, without limitation, a 2G base station, a 3G Node B, an LTE eNB, a 4G LTE base station, a 5G NR base station, a 5G central unit base station, or a 5G distributed unit base station. Each of these types of WANNs may be configured to perform a corresponding set of wireless network functions. The WANN 202 may include a transceiver circuit 214 coupled to one or more antennas 216, which may include various forms of antenna towers 218, to facilitate wireless communication with the UEs 110 and 112. The transceiver circuit 214 may be coupled to one or more processors 220, which may be further coupled to a memory 222 or other storage device. The memory 222 may be temporary or non-transitory and may store therein instructions or code that, when read and executed by the one or more processors 220, cause the one or more processors 220 to implement various functions of the WANN 120 described herein.

[0079] Data packets in a radio access network such as the example illustrated in FIG. 2 may be transmitted as protocol data units (PDUs). The data contained therein may be packaged as PDUs at various network layers wrapped in nested and / or hierarchical protocol headers. The PDUs may be communicated between a transmitting device or transmitting end (these two terms are used interchangeably) and a receiving device or receiving end (these two terms are also used interchangeably) when a connection (e.g., a Radio Link Control (RRC) connection) is established between the transmitting end and the receiving end. Either the transmitting device or the receiving device may be either a wireless terminal device such as devices 110 and 120 in FIG. 2 or a radio access network node such as node 202 in FIG. 2. Each device may be both a transmitting device and a receiving device for bidirectional communication.

[0080] As shown in FIG. 3, one or more base stations 202 of the WANN 120 may include multiple separate access network nodes, for example in the form of a central unit (CU) 302 and at least one distributed unit (DU) 304 and 306. For example, in a 5G network, the base station may be implemented as a gNB. Correspondingly, the gNB 202 may functionally and / or physically include a gNB-CU 302 and one or more gNB-DUs 304 and 306. For example, the CU may be configured to provide support for the higher layers of communication protocols such as Service Data Adaptation Protocol (SDAP), Packet Data Convergence Protocol (PDCP), and Radio Resource Control (RRC), while the DU may be configured to provide support for the lower layers of the protocol stack, such as Radio Link Control (RLC), Medium Access Control (MAC), and physical layers.

[0081] In some other implementations, the CU 302 may be further divided into two separate functional or physical entities referred to as the CU-CP (Control Plane Unit of the gNB-CU), which hosts the RRC entities, and the CU-UP (User Plane Unit of the CU), which hosts the SDAP and PDCP entities. Such a separation of the user plane and the control plane at the higher protocol layers (CU layer) in the base station may provide improved flexibility in the deployment of the access network.

[0082] In some implementations, as shown in FIG. 3, the CU 302 may be connected with the DU1 304 and the DU2 306 via various F1 interfaces. For example, the F1 interfaces may further include an F1-C interface and an F1-U interface that may be used to carry control plane information and usage plane information, respectively. The F1-C interface may be used, for example, between the DU and the CU-CP portion of the CU 302, and the F1-U interface may be used between the DU and the CU-UP portion of the CU 302. The gNB 202 may be connected to the core network 130, for example, via an NG interface. If the gNB is separated as a CU and a DU, the NG connection to the core network may be implemented between the CU 302 and the core network, as shown in FIG. 3. As further shown in FIG. 3, the UE may be connected to the core network 130 via the WANN 120 via a radio interface.

[0083] As further shown at 320 and 330 in FIG. 3, each of the DUs may serve UEs via one or more cells. Each cell is associated with a coverage area. These cells may alternatively be referred to as serving cells. The coverage areas between cells may overlap. Each UE may be in active communication with at least one cell, but may be potentially connected or connectable to two or more cells. In the example of FIG. 3, UE1, UE2, and UE3 may be served by cell 1 320 of DU1, while UE4 and UE5 are served by cell 2 330 of DU1. In some implementations, a UE may be served by two or more cells simultaneously. Each of the UEs may be mobile, and signal strength and quality from various cells at the UE may depend on the UE location. In some embodiments, the CU may be a gNB central unit (gNB-CU) and the DU may be a gNB distributed unit (gNB-DU). The various implementations described below are provided in the context of 5G cellular wireless networks, however, the underlying principles described herein are applicable to other types of radio access networks, including other generations of cellular networks, including, but not limited to, Wi-Fi, Bluetooth®, ZigBee®, and WiMax networks.

[0084] In some example implementations, the cells shown in FIG. 3 may alternatively be referred to as serving cells. The serving cells may be grouped into serving cell groups (CGs). The serving cell groups may be either Master CGs (MCGs) or Secondary CGs (SCGs). Within each type of cell group, there may be one primary cell and one or more secondary cells. For example, a primary cell in an MSG may be referred to as a PCell, while a primary cell in an SCG may be referred to as a PScell. The secondary cells in either an MCG or an SCG may all be referred to as SCells. The primary cells, including the PCell and the PScell, may collectively be referred to as an SpCell. All these cells may be referred to as serving cells or cells. The terms "cell" and "serving cell" may be used interchangeably in a general manner unless otherwise distinguished. The term "serving cell" may refer to a cell that is serving, will serve, or may serve a UE. In other words, a "serving cell" may not currently be serving a UE. Although the various embodiments described below may often refer to one of the above serving cell types, the basic principles apply to all types of serving cells in both types of serving cell groups.

[0085] FIG. 4 illustrates an example division of network functions within the core network 130. While only a single instance of a network node for some functions is illustrated in FIG. 4, one skilled in the art will appreciate that each of these network functions may be instantiated as multiple instances or network nodes distributed throughout the core network 130. Additionally, each network node within the core network 130 may support one or more of the illustrated core network functions. As illustrated in FIG. 4, the core network 130 may include, but is not limited to, an access management network node (AMNN) 430, a session management network node (SMNN) 440, a data routing network node (DRNN) 450, a policy control network node (PCNN) 420, and an application data management network node (ADMNN) 410.

[0086] The access management network node 430 communicates with the access network 120, the session management network node 442, and the policy control network node 420 via communication interfaces 122, 432, and 424, respectively, and may be responsible for registration, authentication, and provisioning of access by UEs to the core network 130, as well as allocation of session management network nodes 440 to support specific UE communication needs. The session management network nodes 440 allocated by the access management network node 430 may then be responsible for allocation of data routing network nodes 450 to support specific UE communication needs, and may control these allocated data routing network nodes 450 via communication interface 446. Alternatively, or additionally, in some implementations, the data routing network nodes 450 may be directly allocated by the access management network node 430 via interface 434 and controlled by the session management network node 442 via communication interface 446. Access and session routing policies applicable to the UE may be managed by a policy control network node 420 which communicates the policies to an access management network node 430 and a session management network node 440 via communication interfaces 424 and 422, respectively. Signaling and data exchange between various types of network nodes over the various communication interfaces illustrated by the various connecting lines in Figure 4 may be carried by signaling or data messages according to a predetermined type of format or protocol.

[0087] To support a particular end-to-end communication task requested by a UE, a communication session may be established to support a data traffic pipeline for transporting the particular end-to-end communication data traffic. As shown by 470 in FIG. 4, the carrier network portion of the data traffic pipeline may involve one or more network nodes in the access network 120 and a set of data routing network nodes 452, 454, and 456 in the core network 130, as selected and controlled by a set of session management network nodes 442 and 444, which may be selected and controlled by an access management network node 430 responsible for establishing and managing the communication session. The data traffic is routed through communication interfaces such as 124, 458, and 459 between the UE at one end of the data traffic pipeline, the carrier network portion of the data traffic pipeline (including the set of network nodes in the access network 120 and the selected data routing network nodes 452, 454, and 456 in the core network 130), and the other end of the data traffic pipeline including, for example, another UE, an application server 140, or another data network 150.

[0088] The application server 140 may further communicate other configuration and control information to the core network 130. The information communicated to the core network 130 may be referred to as application data. Such application data may be processed and managed by a specific type of network node referred to as an application data management network node (ADMNN) 410 in FIG. 4. The application data may be communicated in messages from the application server 140 to the application data management network node 410 via the communication interface 414, for example. Alternatively, the application server 140 may access the application data management network node 410 using an open API provided by the core network 130. Although FIG. 4 shows only a single application server, those skilled in the art will understand that in an actual implementation, the core network 130 may support multiple service applications of different types.

[0089] In some specific implementations, FIG. 5 illustrates that the wireless communication network 500 may include the UE 110, the application server 140, the data network 150, and a carrier network including the RAN 520 and the core network 502. Corresponding to the more general description of FIG. 4 above, a specific implementation of the core network 502 may include an application function (AF) 514, a network exposure function (NEF) 512, and a unified data repository (UDR) function 510. These three types of network nodes may serve together as the application data management network node 410 of FIG. 4. The core network 502 may further include an access and mobility management function (AMF) 530 and a session management function (SMF or I-SMF, indicating an intermediate SMF) 544 and 542. The AMF and SMF serve as the access management network node (AMNN) 430 and the session management network node (SMNN) 440 of FIG. 4, respectively. The AMF 530 and SMFs 544 and 542 may obtain communication policy information from separate Access / Mobility Management Policy Control Function (AM PCF) 520 and Session Management Policy Control Function (SM PCF) 522, respectively. The AM PCF 520 and SM PCF 522 serve as Policy Control Network Node (PCNN) 420 in FIG.

[0090] As further shown in Figure 5, the SMF and I-SMF 522 and 544 each control one or more User Plane Functions (UPFs) 552. The RAN 520 and one or more UPFs 552 may be assigned by the core network and may form the carrier network portion of a data traffic pipeline (or data traffic path) for a particular communication session. The UPFs 552 may serve as the Data Routing Network Node (DRNN) 450 of Figure 4.

[0091] The various network nodes or network functions in Figure 5 use signaling or data messages that follow a certain type of format or protocol to communicate signaling information and data over various communication interfaces as indicated by the various connecting lines in Figure 5. For example, several example communication interfaces as defined in the 5th Generation New Radio Wireless Communications Specification may be used within the communications network 500 between the various network nodes as indicated by the labels along the connecting lines in Figure 5, including an N1 interface between the UE 110 and the AMF 530 via the RAN 520, an N2 interface between the RAN 520 and the AMF 530, an N3 interface between the RAN 520 and the UPF 550, an N4 interface between the SMF 542 / 544 and the UPF 552, an N11 interface between the AMF 530 and the I-SMF 542, and an N16a interface between the I-SMF 542 and the SMF 544.

[0092] Data Transmission End-to-End Latency The end-to-end latency / delay of data transmission in the wireless communication system described above represents the amount of time it takes for a source device to communicate and reach its destination. For uplink communication, the source device may be a wireless terminal or UE and the destination may be a UPF network node in the core network described above. Similarly, for downlink communication, the source device may be a UPF network node and the destination may be a wireless terminal device or UE.

[0093] In a communication network, end-to-end communications may be established as data communication sessions (alternatively referred to as data sessions or communication sessions). Each data session may include the transmission of data of different types, characteristics, and transmission requirements. Thus, a data session may be configured to include multiple data flows, where each data flow includes data having similar transmission characteristics and / or associated with similar transmission quality requirements. The transmission of each of these data flows may be controlled and configured based on its transmission characteristics / requirements. For example, the allocation of communication resources by the communication network to a data flow may be based on the transmission characteristics / requirements of the data flow.

[0094] Such transmission characteristics / requirements of a data flow may be used to determine a set of transmission parameters collectively referred to as the transmission profile of the data flow. The configuration of the transmission of the data flow (such as communication resource allocation) may be based on such transmission profile. The data flow may be referred to as a Quality of Service (QoS) flow and may be characterized by a set of QoS parameters configurable by the network. The data in each of the QoS flows may be transmitted as data packets. The term data packet may be used to refer to the minimum granularity of the data units transmitted on either the uplink or downlink. The transmission of data succeeds or fails at the data packet level. The term data as referred to in this disclosure is used in a general sense to include both user data and control information transmitted as data packets. The data packets in a QoS flow, or more generally in a data communication session, may be associated with an order such that the received data packets can be assembled to recover the original data in the correct sequence.

[0095] Transmission of data packets is typically associated with transmission latencies or delays associated with over-the-air radio interfaces and other wired or wireless interfaces between various network nodes as described above. Some implementations of data transmission, such as 5G Ultra-Reliable Low Latency Communications (URLLC) applications, are intended to provide services with stringent requirements for data transmission latency and service availability. Thus, 5G mobile networks supporting URLLC must provide low latency with minimal packet loss or out-of-order packet arrival. For example, some URLLC services may require that end-to-end communication latency is in the range of 0.5 ms to 50 ms on the application layer. In another specific example, a maximum latency (or radio latency) in the air interface may be further specified. For some 5G URLLC services, it may be required that such radio interface latency not exceed 1 ms.

[0096] Therefore, monitoring, measuring, and reporting network latency for both uplink and downlink data transmissions is important. For example, such latency information can be used to perform network diagnostics and devise modifications to improve wireless network performance. In another example, such latency information can be used to adjust resource allocations and QoS parameters within and among data flows, data communication sessions, and among different users to balance and optimize the overall performance of the network.

[0097] In some implementations, the network latency monitoring, measurement, and reporting may itself be configurable. Such configuration may be included, for example, within a network control message carrying QoS parameters. Such data transmission latency monitoring, measurement, and reporting configuration may be provided to various network nodes prior to or during the establishment of a data communication session or data flow. The various network nodes may then act accordingly during the communication session to cooperatively support network data transmission latency monitoring and reporting.

[0098] Such monitoring / reporting configurations may be designed to provide flexibility by the network to specify the levels, segmentation, granularity of data or data flows, timing, format, and other aspects of the various network nodes involved in a communication session to monitor, calculate, and / or report information related to network communication latency in either the uplink (UL) or downlink (DL) direction.

[0099] In particular, to ensure low end-to-end delay for URLLC, 5G networks need to support performance measurement definition related to UL / DL packet delay for 5G networks. Unlike traditional latency monitoring and measurement, end-to-end UL / DL packet delay needs to be measured for QoS flows per 5G Flow Quality Indicator (5QI) between UPF and UE (UE to UPF delay). Such end-to-end UL / DL packet delay between UE and UPF can be measured separately, or by measuring two segmented delays and adding the two segmented delays together, where the two segmented delays are UL / DL packet delay between UPF and RAN (UPF to RAN delay) and UL / DL packet delay between UE and RAN (UE to RAN delay, or radio interface delay).

[0100] The various exemplary implementations below provide improved network latency monitoring, measurement, and reporting capabilities over existing techniques. In particular, current techniques lack support for the following requirements: ● Direct UE to UPF delay measurement is not supported. Current technology only supports separate measurement of UPF to RAN and UE to RAN delays, and then adds these two delays for the UE to UPF delay. Such an approach increases processing time and burden on network nodes and UEs, especially for applications where only end-to-end delay is of interest. ●Current technologies do not support per-QoS flow delay measurements and only provide average delay / latency at the Data Radio Bearer (DRB) level, which may be of insufficient granularity for some applications. - Current technology does not support monitoring, measuring, and reporting network latency at the data packet level. ● Current technology does not provide various packet-level delay statistics such as packet-level delay distribution beyond the average delay at the DRB level. ● Current technology does not utilize any CU split between the control plane unit and the user plane unit.

[0101] Various exemplary implementations disclosed herein provide mechanisms for the network side of a wireless network system to flexibly configure monitoring, measuring, calculating, and reporting of information related to downlink and uplink data transmission latency among various network nodes, devices, and entities, and in coordination between the control plane and user plane of the wireless network. The disclosed implementations provide configurable network latency segmentation schemes, as well as configurable timing, data or data flow granularity, content, and formats for monitoring / measuring / calculating / reporting related latency information. Thus, various network devices or nodes are coordinated under adaptive configurations by the network to efficiently monitor, measure, calculate, and report latency information adapted to the needs of a particular application and a particular data communication session. A dedicated protocol data unit (PDU) is also designed and constructed for reporting latency information in the user plane.

[0102] Network latency monitoring, measurement, calculation and reporting configuration In some example implementations, an adaptive and flexible configuration for monitoring, measuring, calculating, and reporting information regarding network latency may be determined by the network side of a wireless communication network. For example, the configuration may be determined by a core network entity / function or node. The configuration information may be distributed to various network nodes via various control / data messages and various network interfaces.

[0103] In a specific, non-limiting example, such configuration information may be included as part of a QoS parameter set. In this way, configuration may be provided at a QoS flow level. In other words, for a particular user communication session, each of the separate QoS flows may be separately configured with respect to monitoring, measuring, calculating, and reporting network latency. Thus, such configuration may be part of a QoS profile. The QoS profiles may be predefined, each associated with a set of network latency configuration parameters, among other QoS parameters. The QoS profiles may be indexed and signaled using a QoS index. Alternatively, the network latency configuration parameters may be explicitly included in the QoS configuration message.

[0104] In some example implementations, network latency configuration parameters may include, but are not limited to, the following: [Table 1]

[0105] As shown in the above example, the network may configure two types of delay measurements for QoS flows, including RAN partial delay measurement (delay between the NG-RAN (gNB) and the UE) and end-to-end (E2E) delay (delay between the UPF of the CN (core network) and the UE) measurement.

[0106] As further illustrated by the above examples, for each QoS flow, a QoS latency configuration can be defined within the QoS parameters, where the QoS latency configuration includes at least one of the following parameters: A selection indication or flag to indicate whether RAN partial latency (e.g. latency between NG-RAN (gNB) and UE) or E2E latency (e.g. latency between UPF of CN (Core Network) and UE) is configured to be measured. This flat provides the flexibility for the system to decide according to a specific application or QoS whether only E2E latency is of interest or also finer granularity in terms of segmented latency (e.g. radio interface latency) alternatively or in addition to E2E latency. A reporting frequency or time period to indicate the reporting frequency or time period of the UL / DL RAN part or E2E delay measurements (note that if the E2E delay method is selected, the UL E2E delay may be calculated in the CN and the RAN only needs to report DL E2E delay measurements). The reporting period may be specified as an absolute time length, for example in seconds. Alternatively, an index in a set of predefined indexes may be used to indicate the reporting time period. Each of the indexes may correspond to a particular reporting period, which may be predefined. Alternatively, a reporting frequency may be specified. The reporting frequency may be the inverse of the reporting period. A timestamp type to indicate which type of timestamp is used when needed. For example, the type of timestamp may include including a timestamp in the IP header (i.e., in the header of each data packet) or including a timestamp in the PDCP header or information field. The IP header timestamp scheme refers to inserting a timestamp in the Internet Protocol (IP) header of an IP packet associated with the QoS flow, while the PDCP timestamp scheme refers to inserting a timestamp in the PDCP header or information field of a PDCP protocol data unit (PDU) associated with the QoS flow. A timestamp so included indicates the time a packet is transmitted from or arrives at a PDCP entity and may be used by a recipient network device or node of the timestamp to derive or calculate uplink or downlink latency along with other timing information. ·Reporting granularity to indicate the reporting type of the results / information of the monitored or measured latency information. As an example, the granularity type may indicate whether reporting should be done at a per packet level, per QoS flow level, per packet statistic level, etc. For example, the granularity type may include one of packet average, per packet, distribution range / histogram, distribution formula, etc. The reporting granularity parameter may indicate which of these predefined granularity schemes should be used for the particular QoS flow configured. Such a parameter may be included within the QoS parameter set as an index or enumerated value corresponding to the predefined granularity configuration. For example, if an "average" type is indicated, the NG-RAN (gNB) may report the average latency result of all packet samples for a particular period (e.g., the reporting time period described above). If a "per packet" type is indicated, the NG-RAN (gNB) may report all latency / latency results of all packet samples for the reporting time period as a list. If a "distribution range" type is indicated, the NG-RAN (gNB) may report a detailed delay distribution of all packet samples during the reporting time period, for example as a histogram showing the number of packets for each of multiple latency ranges. If a "distribution formula" type is indicated, the NG-RAN (gNB) may report a parameterized mathematical distribution formula of all packet samples during the reporting time period. Rather than a numerical histogram, the report may instead indicate the formula in a set of distribution formulas that is being used to describe the packet-level latency distribution (using a predefined set of formulas and indices of these formulas) and the values ​​of the measured / derived parameters associated with the indicated formula.

[0107] Configuration process for latency monitoring, measurement, calculation, and reporting parameters Various parameters for monitoring, measuring, calculating, and reporting configuration of data transmission latency may be provided from the core network side for each QoS flow. An exemplary procedure is shown in FIG. 6 and described in further detail below.

[0108] Specifically, Figure 6 shows a flow diagram for configuring QoS flows with QoS network latency monitoring, measurement, calculation, and reporting parameters in a core network, an access network, and a UE. Although specific references to 5G network terminology may be used in Figure 6, no such limitations are intended in the following description, and the underlying principles disclosed below apply broadly to other wireless communication systems.

[0109] As shown in FIG. 6, in step 1, the CN may send a message, e.g., an Initial Context Setup Request message or a PDU Session Setup / Modification Request message, to an access network, e.g., a gNB (as explained above, to the gNB-CU-CP in case of a CP / UP split of the gNB), to request allocation / modification of resources for one or more PDU sessions, per QoS flow in the PDU session. As explained above, the QoS monitoring configuration determined by the network for QoS may optionally be included in the QoS parameters set in the message. Such a message may be sent, for example, as a NG Application Protocol (NGAP) in the control plane. Thus, such a message may be received by the control plane of the access network. As shown in FIG. 6, such a message is received by the gNB-CU-CP in case of a functional and / or physical split of CP and UP functions in the access network.

[0110] In step 2, the access network, e.g., gNB-CU-CP, sends a message, e.g., Bearer Context Setup / Modification Request message, to the user plane of the access network, e.g., gNB-CU-UP in case of CP-UP split, to request allocation / modification of resources of one or more PDU sessions for each QoS flow in the PDU session. QoS monitoring configuration may optionally be included in the QoS parameters in the message. As an example, such a message may be implemented as an E1 message.

[0111] In step 3, the access network node, e.g., gNB-CU-UP, stores the received QoS latency configuration of the QoS flow, e.g., in the user plane of the access network node, as the basis for subsequent operations related to latency monitoring, measurement, calculation and reporting.

[0112] In step 4, the UE context in the gNB-DU is established under provisioning of the gNB-CU-CP.

[0113] In step 5, the gNB-CU-CP sends an RRC message, for example an RRC Setup Complete message or an RRC Reconfiguration Request message, to the UE for each QoS flow in the PDU session. The QoS latency configuration may optionally be included in the QoS parameters in the message such that the UE is informed by these latency configuration parameters.

[0114] In step 6, the UE stores the received QoS latency configuration for the QoS flow, so that the UE may determine its behavior in monitoring, measuring, calculating, and reporting QoS data packet network latency information based on such QoS latency configuration.

[0115] In step 7, a PDU session may be established / modified in the CN, the access network, e.g., gNB, and the UE by at least one of the QoS flows configured in the QoS latency monitoring, measurement, calculation, and reporting configuration.

[0116] Exemplary DL Direct E2E Latency Monitoring, Measurement, Calculation, and Reporting Scheme Under the configured direct E2E latency monitoring scheme, the networks may cooperatively monitor, measure, exchange, calculate, and report information related to the configured E2E latency results (e.g., average, per packet, distribution range, or distribution formula) for DL ​​packets of the QoS flow.

[0117] FIG. 7 illustrates an example flow diagram for monitoring, measuring, exchanging, calculating, and reporting latency information regarding DL E2E delay from the UPF to the UE.

[0118] As shown in Figure 7, in step 1, a PDU session may be established among the CN, the gNB, and the UE with at least one QoS flow configured with a QoS latency configuration as described above in relation to Figure 6. It is assumed that the QoS latency configuration indicates an E2E scheme.

[0119] In step 2, after the UPF determines that an E2E delay scheme is used according to the QoS latency configuration of the QoS flow, the UPF of the CN may send at least one downlink user plane packet to the user plane of the access network (e.g., gNB-CU-UP) with a corresponding UPF timestamp. Such a timestamp may be included, for example, in an Internet Protocol (IP) header of one or more corresponding IP packets of the QoS flow. The IP packets may be encapsulated into the downlink user plane packets. The UPF timestamp may indicate the time instance when the last one encapsulated IP packet is sent from or arrives at the UPF.

[0120] In step 3, the gNB-CU-UP may send downlink user plane packets to the gNB-DU (if CU-DU split is implemented in the access network).

[0121] In step 4, the gNB-DU may transmit downlink user plane packets to the UE.

[0122] In step 5, after the UE determines that the E2E latency scheme is used according to the QoS latency configuration of the QoS flow, the PDCP layer of the UE may calculate an E2E DL delay between the UPF of the received at least one downlink IP packet and the UE by subtracting a UPF timestamp included in an IP header of the at least one IP packet from a time when the at least one IP packet arrives at the PDCP entity of the UE. The UE may further record the calculated delay or latency result of the at least one DL packet.

[0123] In step 6, the UE may measure / monitor / calculate the DL E2E delay for the reporting time period as indicated in the QoS latency configuration. The UE may then transmit an RRC message with a DL E2E delay report information item to the access network control plane, e.g., gNB-CU-CP, via the gNB-DU. The E2E delay report information item may be generated according to the QoS latency configuration described above. Thus, such a report information item may include, for example, an average delay, a per-packet delay, a delay distribution histogram, or a delay distribution formula for the reporting time period, as configured in the QoS latency configuration.

[0124] In the above example implementation, the delay distribution information for the QoS flows may include, but is not limited to, at least one of the following: A list of delay distribution ranges or latency histograms. Specifically, each item in this list may indicate the number of delay samples within a specific delay value range, where each value range may be defined as a low and high delay value of the value range. Each item in the list may include at least one of a "range ID" to indicate a given delay value range, a "range start / end" pair to indicate the range by the minimum / maximum value of the range, and a "number of samples" to indicate the number of packets having measured network delay results within the delay value range corresponding to the "range ID" or "range start / end" pair. For example, range ID=1 may represent delay values ​​between [0,0.2ms), range ID=2 may represent delay values ​​between [0.2,0.4ms), and range ID=3 may represent delay values ​​between [0.4,0.6ms). Similarly, the "range start / end" pair may indicate the minimum / maximum value of the range. For example, if the delay range is (0.2ms, 0.4ms), the "range start" of the pair may be set to 0.2 and the "rung end" of the pair may be set to 0.4. A list of raw delay samples for the distribution calculation. Each item in the list indicates the delay result for one packet and may optionally include the PDCP sequence number associated with the measured packet. Such information may be used by other network nodes to perform the desired derivation or calculation. An information item corresponding to a parameterized mathematical delay distribution formula. Such an information item may include at least one of the following: a "Delay distribution formula ID" indicating a given delay distribution formula or a probability density formula for a delay distribution, a "Number of formula parameters" indicating the number of parameters of the selected parameterized mathematical distribution formula, and a "List of formula parameters", each item of the list indicating the values ​​of the parameters of the distribution formula used in the corresponding order. For example, the case where a formula for normal probability density is selected is shown below: [Table 2]

[0125] The above information items corresponding to the selected normal probability formula may represent: · Delay distribution formula ID: ID=1 indicates that the normal probability density formula is used. · Number of formula parameters = equal to 2 (only 2 parameters, μ and σ) · First item in the formula parameter list: the value of μ, the first parameter. · Second item in the formula parameter list: the value of σ, the second parameter.

[0126] Returning to Figure 7, in step 7, the QoS delay information during the reporting time period may be reported by the access network to the core network. Such reporting may be implemented by two exemplary optional methods.

[0127] In an optional implementation shown as step 7A, the reporting may be implemented in the control plane. Specifically, after receiving an RRC message with a DL delay information item sent from the UE, the gNB-CU-CP may, for example, send an NGAP message with a DL delay information item to the CN.

[0128] In an optional implementation shown as step 7B, the reporting may instead be implemented in the user plane. In particular, as shown in step 7B-1 of FIG. 7, after receiving an RRC message including a DL delay information item sent by the UE, the gNB-CU-CP sends a message including the DL delay information item (e.g., an E1 Application Protocol (E1AP) message) to the user plane of the access network node, e.g., gNB-CU-UP. Furthermore, in step 7B-2, after receiving a message with the DL delay information item sent from the gNB-CU-CP, the gNB-CU-UP sends user plane data, such as an NG-U packet with the DL delay information item, to the UPF of the CN. The NG-U packet may be implemented, for example, as a UL PDU session information PDU. In other words, the NG-U packet may be encapsulated in a special PDU used to report the UL PDU session information, where the UL PDU session information includes the QoS delay information item.

[0129] Exemplary UL Direct E2E Latency Monitoring, Measurement, Calculation, and Reporting Methodology Under the configured direct E2E latency monitoring scheme, the networks may cooperatively monitor, measure, exchange, calculate, and report information related to the configured E2E latency results (e.g., average, per packet, distribution range, or distribution formula) for UL packets of the QoS flow.

[0130] FIG. 8 illustrates an example flow diagram for monitoring, measuring, exchanging, calculating, and reporting latency information regarding UL E2E delay from the UE to the UPF.

[0131] As shown in Figure 8, in step 1, a PDU session may be established among the CN, the gNB, and the UE with at least one QoS flow configured with a QoS latency configuration as described above in relation to Figure 6. It is assumed that the QoS latency configuration indicates an E2E scheme.

[0132] In step 2, the UE may send an uplink user plane packet with a UE timestamp in the Internet Protocol (IP) header of the IP packet associated with the QoS flow to the gNB-DU. The IP packet may be encapsulated in the uplink user plane packet. The UE timestamp may indicate the time when the encapsulated IP packet is being transmitted, for example, from the PDCP layer of the UE.

[0133] In step 3, the gNB-DU may send uplink user plane packets to the gNB-CU-UP (if CU-DU split is implemented in the access network).

[0134] In step 4, the gNB-CU-UP may send uplink user plane packets to the CN's UPF.

[0135] In step 5, the CN's UPF may calculate the UL delay / latency between the UPF and the UE for the received uplink IP packet by subtracting the UE timestamp in the IP header of the IP packet from the time the IP packet arrived at the UPF. The UPF may further record the delay / latency results for each UL packet. The UPF may measure the UL delay for a period of time (e.g., the configured reporting time period described above) and use the collected UL delay results to determine the UL E2E delay distribution (histogram or distribution formula) as described above.

[0136] Exemplary DL RAN Partial Latency Monitoring, Measurement, Calculation, and Reporting Scheme Under the configured RAN partial latency monitoring scheme, the networks may cooperatively monitor, measure, exchange, calculate, and report information related to the configured RAN partial latency results (e.g., average, per packet, distribution range, or distribution formula) for DL ​​packets of the QoS flow.

[0137] FIG. 9 illustrates an example flow diagram for monitoring, measuring, exchanging, calculating, and reporting latency information regarding DL RAN partial delay.

[0138] As shown in Figure 9, in step 1, a PDU session may be established among the CN, the gNB, and the UE using at least one QoS flow configured in the QoS monitoring configuration. It is assumed that the QoS latency configuration indicates a RAN partial latency scheme.

[0139] In step 2, the CN's UPF may send downlink user plane packets to the gNB-CU-UP.

[0140] In step 3, the gNB-CU-UP may transmit the PDCP PDUs associated with the QoS flow to the gNB-DU with a gNB timestamp in the PDCP PDU header or in the IP header of the IP packet encapsulated in the PDCP PDU. The gNB timestamp may indicate the time when the PDCP PDU was transmitted from the PDCP layer / entity of the gNB or the time when the corresponding PDCP SDU arrived at the PDCP layer of the gNB.

[0141] In step 4, the gNB-DU may transmit downlink user plane packets to the UE.

[0142] In step 5, the UE PDCP layer may calculate the DL delay / latency time between the gNB and the UE of the received downlink PDCP PDU by subtracting the gNB timestamp included in the PDCP PDU header or the IP packet header therein from the time when the PDCP PDU arrives at the UE PDCP layer / entity. The UE may further record the delay / latency result of the DL packet as the RAN partial delay / latency.

[0143] In step 6, the UE may measure the RAN partial DL delay over a certain period (e.g., a configured reporting time period as described above). The UE may then send an RRC message to the gNB-CU-CP via the gNB-DU with at least one delay information item related to the RAN partial DL delay (e.g., average delay, delay per package, distribution range, and / or distribution information as described above) according to the UE's stored QoS latency configuration for the corresponding QoS flow.

[0144] In step 7, the control plane of the access network, e.g., gNB-CU-CP, reports the delay / latency information items to the CN. Such reporting can be implemented by two exemplary optional methods.

[0145] In an optional implementation shown as step 7A, the reporting may be implemented in the control plane. Specifically, as shown in step 7A, after receiving an RRC message with a delay information item sent by the UE, the gNB-CU-CP sends, for example, an NGAP message with a delay information item to the CN from the control plane of the access network.

[0146] In an optional implementation shown in step 7B, the reporting may instead be performed in the user plane. In particular, as shown in step 7B-1, after receiving an RRC message with a delay information item sent by the UE, the gNB-CU-CP transmits a message with the delay information item, e.g., an E1AP message, to the user plane of the access network, e.g., the gNB-CU-UP. Furthermore, in step 7B-2, after receiving a message with a delay information item sent by the gNB-CU-CP, the gNB-CU-UP transmits a user plane package, such as an NG-U packet with the delay information item, to the UPF of the CN. The NG-U packet may be implemented, for example, as a UL PDU session information PDU, etc. In other words, the NG-U packet may be encapsulated in a special PDU used to report the UL PDU session information, where the UL PDU session information includes a QoS delay information item.

[0147] Exemplary UL RAN Partial Latency Monitoring, Measurement, Calculation, and Reporting Scheme Under the configured RAN partial latency monitoring scheme, the networks may cooperatively monitor, measure, exchange, calculate, and report information related to the configured RAN partial latency results (e.g., average, per packet, distribution range, or distribution formula) for UL packets of the QoS flow.

[0148] FIG. 10 illustrates an example flow diagram for monitoring, measuring, exchanging, calculating, and reporting latency information regarding UL RAN partial delays.

[0149] As shown in Figure 10, in step 1, a PDU session may be established among the CN, the gNB, and the UE using at least one QoS flow configured with a QoS latency configuration. It is assumed that the QoS latency configuration indicates a RAN partial latency scheme.

[0150] In step 2, the UE may transmit the PDCP PDU associated with the QoS flow in the gNB-DU with a UE timestamp in the PDCP PDU header or in the IP header of the IP packet encapsulated in the PDCP PDU. The UE timestamp indicates the time when the PDCP PDU is transmitted from the PDCP layer / entity of the UE or when the corresponding PDCP SDU arrives at the PDCP layer / entity of the UE.

[0151] In step 3, the gNB-DU may transmit uplink user plane packets to the gNB-CU-UP.

[0152] In step 4, after receiving the PDCP PDU transmitted by the UE, the gNB-CU-UP (or the PDCP layer / entity of the gNB) may calculate the UL transmission delay / latency between the gNB and the UE of the received uplink PDCP PDU by subtracting the UE timestamp from the time when the PDCP PDU arrived at the gNB-CU-UP (the PDCP layer / entity of the gNB). The UE timestamp may be extracted from the IP header of the PDCP PDU or the IP packet encapsulated in the PDCP PDU header. The gNB-CU-UP may then record the delay / latency result of the UL packet as the RAN partial latency.

[0153] In step 5, the gNB-CU-UP may further send the uplink user plane packets to the CN's UPF.

[0154] In step 6, the RAN partial QoS latency information may be reported by the access network to the CN. Such reporting may be implemented by two exemplary optional methods.

[0155] In an optional implementation shown as step 6A, the reporting may be implemented in the control plane. Specifically, in step 6A-1, the gNB-CU-UP may measure the RAN partial UL delay over a certain period of time (e.g., a configured reporting time period). The gNB-CU-UP may then send a message, e.g., an E1AP message, having at least one of the delay information items of the RAN partial UL delay of the QoS flow according to the stored QoS latency configuration of the QoS flow of the gNB-CU-UP to the control plane of the access network, e.g., the gNB-CU-CP. Further, in step 6A-2, after receiving the message having the latency information item sent by the gNB-CU-CP, the gNB-CU-UP then sends a control plane message, e.g., an NGAP message having the DL delay information item, to the CN.

[0156] In an optional implementation shown as step 6B, the reporting may be implemented in the user plane. Specifically, as shown in step 6B of FIG. 6, the gNB-CU-UP measures the RAN partial UL delay over a certain configured time period, and then transmits a user plane package, e.g., an NG-U packet having at least one delay information item of the RAN partial UL delay of the QoS flow, to the UPF of the CN according to the stored QoS latency configuration of the gNB-CU-UP of the QoS flow. The NG-U packet may be implemented, for example, as a UL PDU session information PDU, etc. In other words, the NG-U packet may be encapsulated in a special PDU used to report the UL PDU session information, where the UL PDU session information includes the QoS delay information item.

[0157] UL PDU Session PDU for reporting latency information items including latency distribution range ID As described above with respect to the implementations of Figures 7, 9, and 10, a UL PDU Session PDU may be constructed to report QoS latency information from the user plane of the access network, e.g., gNB-CU-UP, to the core network. This may be considered as a dedicated user plane PDU in parallel with other regular data PDUs.

[0158] In some implementations, such a dedicated PDU may be constructed to report a latency information item containing latency distribution information associated with a latency range ID, as described above. An exemplary construction of such a PDU is shown below, which illustrates a UL PDU Session Information PDU (referred to as PDU Type 1) format with various UL / DL delay distribution information field definitions. Again, such a UL PDU Session Information PDU may be used to convey UL / DL delay information associated with a measured distribution of a latency range with a range ID to the UPF of the CN. It should be further appreciated that other types of PDU(s) may be constructed containing similar fields for conveying UL / DL delay distribution information to a target network node. [Table 3-1] [Table 3-2]

[0159] In addition to the normal PDU fields, various latency / delay information fields are described in more detail below. A UL distribution indication field (1 bit, value = 0 or 1) may be included. For example, if this bit is set to "1", DL delay distribution information is indicated as being included / present in the PDU. Otherwise, such information is not included in the PDU.

[0160] A DL delay distribution for E2E indication field (1 bit, value=0 or 1) may be included. This parameter indicates whether the DL delay distribution result is a RAN partial delay (delay between NG-RAN and UE) or an E2E delay (delay between UPF and UE) (e.g., a value of 0 corresponds to a RAN partial delay and a value of 1 corresponds to an E2E delay).

[0161] A UL Delay Distribution Indication field (1 bit, value = 0 or 1) may be included. If the bit is set to "1", UL RAN partial delay distribution information (between NG-RAN and UE) is included / present in the PDU. Otherwise, no such information is included in the PDU.

[0162] A DL Delay Distribution Range Count field may be included. If included, this parameter indicates how delay ranges (blocks) are configured for the current DL delay distribution information. In one example, as shown in Table 3 above, if included, this field may occupy one octet and provide an indication of up to 255 DL delay ranges.

[0163] For each DL latency range, a corresponding set of fields may be included to convey distribution information for each DL latency range, including a "DL range ID" field and a "number of DL samples in range" field, each field occupying, for example, one octet. The "DL range ID" field may indicate a predefined DL delay range. For example, range ID=1 may represent a DL latency delay range of [0, 0.2 ms), range ID=2 may represent a DL latency value range of [0.2, 0.4 ms), range ID=3 may represent a DL latency value range of [0.4, 0.6 ms), etc. In another example, the "number of DL samples in range" may be an integer representing the number of packets measured with DL delay results within the corresponding latency value range indicated by the range ID. As shown in Table 3, these two fields are repeated within the PDU over the "DL delay distribution range number" of time.

[0164] Additionally, a "DL Delay Distribution Range Number" field may be included. If included, this parameter indicates how delay ranges (blocks) are configured for the current UL delay distribution information. In one example, as shown in Table 3 above, if included, this field may occupy one octet and provide an indication of up to 255 UL delay ranges.

[0165] For each UL latency range, a corresponding set of fields may be included to convey distribution information for each UL latency range, including a "UL Range ID" field and a "Number of UL Samples in Range" field, each field occupying, for example, one octet. The "UL Range ID" field may indicate a predefined UL delay range. For example, Range ID=1 may represent a UL latency delay range of [0, 0.2 ms), Range ID=2 may represent a UL latency value range of [0.2, 0.4 ms), Range ID=3 may represent a UL latency value range of [0.4, 0.6 ms), etc. In another example, the "Number of UL Samples in Range" may be an integer representing the number of packets measured with UL delay results within the corresponding latency value range indicated by the Range ID. As shown in Table 3, these two fields are repeated within the PDU over the "UL Delay Distribution Range Number" of time.

[0166] UL PDU Session PDU for reporting latency information items containing latency distribution range start / end pairs In some implementations, such a dedicated PDU may be constructed to report a latency information item including latency distribution range start / end pair information. An exemplary construction of such a PUD is shown below, which shows a UL PDU Session Information PDU (referred to as PDU type 1) format with UL / DL delay distribution information field definition. Again, such a UL PDU Session Information PDU may be used to convey UL / DL delay distribution information related to a latency range associated with a start / end value pair to a UPF of a CN. It should be further understood that other types of PDUs can be constructed to include similar fields for conveying UL / DL delay distribution information related to a latency range with a start / end value pair to a target network node. [Table 4-1] [Table 4-2]

[0167] In addition to the normal PDU fields, the various latency / delay information fields in Table 4 are described in further detail below. Most of the field definitions for the UL / DL delay distribution information are similar to the example implementation associated with Table 3, with the exception of the following fields:

[0168] Specifically, for each DL latency range, a corresponding set of fields may be included to convey distribution information for each DL latency range, including: (1) a "Range Start" field, if indicated to be present, which may occupy one octet, e.g., to indicate a starting latency value of the corresponding DL latency range; (2) a "Range End" field, if indicated to be present, which may occupy one octet, e.g., to indicate an ending latency value of the corresponding DL latency range; and (3) a "Number of DL Samples in Range" field, which may occupy one octet, e.g., to indicate the number of packets measured by the DL latency results that are within the range of values ​​indicated by the Range Start and Range End. As shown in Table 4, these three fields are repeated within the PDU over a "DL Latency Distribution Range Number" of time.

[0169] Similarly, for each UL latency range, a corresponding set of fields may be included to convey distribution information for each UL latency range, including: (1) a "Range Start" field, if indicated to be present, which may occupy one octet, e.g., to indicate a starting latency value of the corresponding UL latency range; (2) a "Range End" field, if indicated to be present, which may occupy one octet, e.g., to indicate an ending latency value of the corresponding UL latency range; and (3) a "Number of UL Samples in Range" field, which may occupy one octet, e.g., to indicate the number of packets measured with the UL delay result that are within the range of values ​​indicated by the Range Start and Range End. As shown in Table 4, these three fields are repeated within the PDU over a "UL Delay Distribution Range Number" of time.

[0170] As an example, if the "Range Start" field is indicated as 0.2 and the "Range End" field is indicated as 0.4, the corresponding latency range may be (0.2ms, 0.4ms).

[0171] UL PDU Session PDU for reporting latency information items containing packet delay samples In some implementations, such a dedicated PDU may be constructed to report a latency information item including latency distribution information associated with latency packet-level samples, as described above. An exemplary construction of such a PUD is shown below, which illustrates a UL PDU Session Information PDU (referred to as PDU type 1) format with UL / DL delay distribution information field definitions. Again, such a UL PDU Session Information PDU may be used to convey UL / DL delay distribution information associated with packet-level latency samples to the CN's UPF. It should be further appreciated that other types of PDU(s) may be constructed including similar fields for conveying UL / DL delay distribution information associated with packet-level latency samples to a target network node. [Table 5]

[0172] In addition to the normal PDU fields, the various latency / delay information fields in Table 5 are described in further detail below. Some of the field definitions for the UL / DL Delay Distribution Information in Table 5 are similar to the implementations described above in relation to Tables 3 and 4, with the exception of the following fields:

[0173] Specifically, a "DL Delay Samples Count" may be included. If included, this parameter may occupy, for example, one octet to indicate up to 255 DL packet-level latency samples. This field may be followed by a corresponding number of blocks. Each block, if present, may occupy a number of octets (e.g., four octets) to carry the latency information of each DL packet, and may further occupy a number of octets (e.g., four octets) to carry the PDCP sequence number associated with the corresponding DL packet. Each of these blocks corresponds to one of the "DL Packet Delay" fields and one of the "DL PDCP Sequence Number" fields of Table 5.

[0174] Similarly, a "Number of UL Delay Samples" may be included. If included, this parameter may occupy, for example, one octet to indicate up to 255 UL packet-level latency samples. This field may be followed by a corresponding number of blocks. Each block, if present, may occupy a number of octets (e.g., four octets) to carry the latency information of each UL packet, and may also occupy a number of octets (e.g., four octets) to carry the PDCP sequence number associated with the corresponding UL packet. Each of these blocks corresponds to one of the "UL Packet Delay" and one of the "UL PDCP Sequence Number" fields of Table 5.

[0175] The above per-packet latency information may be used by various network nodes in a wireless network to calculate latency distribution information.

[0176] UL PDU Session PDU for reporting latency information items containing latency distribution information In some implementations, such a dedicated PDU may be constructed to report a latency information item including latency distribution information related to the latency distribution equation, as described above. An exemplary construction of such a PUD is shown below, which shows a UL PDU Session Information PDU (referred to as PDU type 1) format with UL / DL delay distribution equation information field definitions. Again, such a UL PDU Session Information PDU may be used to convey the UL / DL delay distribution equation information to the UPF of the CN. It should be further appreciated that other types of PDU(s) may be constructed to include similar fields for conveying the UL / DL delay distribution equation information to a target network node. [Table 6-1] [Table 6-2]

[0177] In addition to the normal PDU fields, the various latency / delay information fields in Table 6 are described in further detail below. Some of the field definitions for the UL / DL delay distribution information in Table 6 are similar to the implementations described above in relation to Tables 3, 4, and 5, with the exception of the following fields:

[0178] "DL Delay Distribution Formula ID" information may be included. If present, this field may occupy one octet to indicate, for example, up to 255 DL latency distribution formula IDs corresponding to a set of predefined DL latency distribution formulas. For example, formula ID=1 may correspond to a predefined binomial distribution formula, formula ID=2 may correspond to a predefined normal distribution formula, etc.

[0179] A "Number of Formula Parameters in DL" field may be included, which, if present, may occupy, for example, one octet to indicate up to 255 parameters used in the parameterized mathematical distribution formula.

[0180] Each block of "DL formula parameters" fields may be included to carry one of the DL formula parameters. Each of these fields, if present, may occupy, for example, four octets that specify one DL formula parameter.

[0181] Similarly, a "DL Delay Distribution Formula ID" field may be included. This field, if present, may occupy one octet to indicate up to 255 UL latency distribution formula IDs corresponding to a set of predefined UL latency distribution formulas. For example, formula ID=1 may correspond to a predefined binomial distribution formula, formula ID=2 may correspond to a predefined normal distribution formula, etc. A "Number of UL Formula Parameters" field may be included. This parameter, if present, may occupy one octet to indicate up to 255 parameters used in the parameterized mathematical distribution formulas. A block of "UL Formula Parameters" fields may each be included to carry one of the UL formula parameters. Each of these fields, if present, may occupy four octets, for example, identifying one UL formula parameter.

[0182] As explained above, the latency distribution equation may be a function that identifies all possible values ​​of a latency variable and also quantifies the relative frequency (probability) of how often each particular latency variable value occurs. In other words, the latency distribution equation provides a parameterized mathematical function that can be used to calculate the probability for any individual observation of latency from a sample space.

[0183] Exemplary latency distribution formulas may include, but are not limited to, binomial, Poisson, geometric, normal, and log-normal distributions. Latency distributions may be classified based on the type of data. For example, for collected RAN partial delays of packets, or E2E delays of packets between a UPF and a UE, a normal distribution may be appropriately used to describe the collected data, as shown below. [Table 7]

[0184] If the above normal probability density formula is selected, the blocks (sets) of UL delay distribution information in the above UL PDU Session PDU frame can be allocated as follows: · Delay distribution formula ID: ID=1 indicates that the normal probability density formula is used. · Number of formula parameters = equal to 2 (only 2 parameters, μ and σ) · First item in the formula parameter list: the value of μ, the first parameter. · Second item in the formula parameter list: the value of σ, the second parameter.

[0185] The above description and the accompanying drawings provide specific exemplary embodiments and implementations. However, the subject matter described may be embodied in various different forms, and therefore, it is intended that the subject matter covered or claimed be construed as not being limited to any exemplary embodiment described herein. A reasonably broad scope of the subject matter claimed or covered is intended. Among other things, for example, the subject matter may be embodied as a method, device, component, system, or non-transitory computer-readable medium for storing computer code. Thus, the embodiments may take the form of, for example, hardware, software, firmware, storage medium, or any combination thereof. For example, the method embodiments described above may be implemented by a component, device, or system including a memory and a processor by executing computer code stored in the memory.

[0186] Throughout this specification and the claims, terms may have subtly different meanings suggested or implied in the context beyond the meaning explicitly stated. Similarly, the phrase "in one embodiment / implementation" as used herein does not necessarily refer to the same embodiment, and the phrase "in another embodiment / implementation" as used herein does not necessarily refer to a different embodiment. For example, the subject matter described in the claims is intended to include combinations of the example embodiments in whole or in part.

[0187] Generally, terms may be understood at least in part from their usage in context. For example, terms such as "and," "or," or "and / or" as used herein may include various meanings that may depend at least in part on the context in which such terms are used. Typically, "or" when used to relate a list such as A, B, or C is intended to mean A, B, and C used in an inclusive sense, as well as A, B, or C used in an exclusive sense. Furthermore, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in a singular sense, or may be used to describe a combination of features, structures, or characteristics in a plural sense, depending at least in part on the context. Similarly, terms such as "a," "an," or "the" may be understood to convey a singular usage or to convey a plural usage, depending at least in part on the context. Furthermore, the term "based on" may be understood as not necessarily intended to convey an exclusive set of factors, and instead may allow for the existence of additional factors not necessarily explicitly described, depending at least in part on the context.

[0188] References to features, advantages, or similar language throughout this specification do not imply that all of the features and advantages that may be realized by the solution should or are included in any single implementation aspect thereof. Rather, language referring to features and advantages is understood to mean that the particular feature, advantage, or characteristic described in connection with an embodiment is included within at least one embodiment of the solution. Thus, descriptions of features and advantages throughout this specification, and similar language, may, but do not necessarily, refer to the same embodiment.

[0189] Furthermore, the described features, advantages, and characteristics of the solution may be combined in any suitable manner in one or more embodiments. Those skilled in the art will recognize in light of the description herein that the solution may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the solution.

Claims

1. 1. A method for provisioning a data transmission delay between a wireless terminal device and a core network by a radio access network node of a wireless network, comprising: receiving a transmission delay configuration from the core network, the transmission delay configuration comprising: a transmission delay provisioning segmentation scheme from among a plurality of segmentation schemes, or A monitoring / reporting configuration for the data transmission delay from among a plurality of monitoring / reporting configurations. and identifying at least one of transmitting at least a portion of said transmission delay configuration to said wireless terminal device; receiving from the wireless terminal device a transmission delay information item during a data transmission session between the core network and the wireless terminal device; generating a report according to the transmission delay configuration based on the transmission delay information item and transmitting the report to the core network; A method comprising:

2. The method of claim 1 , wherein the transmission delay provisioning segmentation scheme comprises one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

3. The monitoring / reporting configuration includes: Reporting timing structure, reporting granularity configuration, or Data packet transmission time stamp method The method of claim 2 , comprising at least one of:

4. The method of claim 3 , wherein the reporting timing configuration indicates a reporting frequency or a reporting time period.

5. The reporting granularity configuration may further comprise: Average data packet delay, Per-packet delay, Packet Delay Distribution, or Packet delay distribution information The method of claim 3 , further comprising reporting the at least one of:

6. the reporting granularity configuration indicates reporting the data transmission delay as the packet delay distribution; the packet delay distribution is included within an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field indicating the number of delay ranges; a plurality of blocks of fields, each block of fields including a number of packets having a latency value that falls within one of said delay ranges; The method of claim 5 , comprising:

7. The reporting granularity configuration indicates that the data transmission delay is reported as the packet delay distribution information; the packet delay distribution information is included in an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field for identifying a packet delay distribution formula; a second field for indicating the number of parameters associated with the packet delay distribution equation; a block of fields containing values ​​of said number of parameters; The method of claim 5 , comprising:

8. the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay; The per-packet delay is contained within an uplink protocol data unit (PDU) session frame; The PDU session frame includes: a first field indicating a number of delay samples per packet; a plurality of second fields each containing a per-packet delay sample; The method of claim 5 , comprising:

9. The data packet transmission time stamp method includes: Including a transmission timestamp in the data packet header, or Including a transmission time stamp in a packet data convergence protocol header The method of claim 3 , wherein the method further comprises:

10. The method of claim 3 , wherein the data transmission delay is associated with a user plane of the wireless network.

11. The method of claim 10 , wherein the data transmission delay comprises a downlink user plane data transmission delay.

12. The method further includes relaying at least one downlink data packet from the core network to the wireless terminal device; 12. The method of claim 11, wherein the transmission delay information item associated with the at least one downlink data packet comprises end-to-end downlink transmission delay information or RAN-partial downlink transmission delay information associated with the at least one downlink data packet received in a control plane of the radio access network node from the wireless terminal device and calculated by the wireless terminal device.

13. 13. The method of claim 12, wherein the transmission delay information item is received in the control plane of the radio access network node as part of a Radio Resource Control (RRC) measurement report.

14. 13. The method of claim 12, wherein generating and transmitting the report to the core network comprises inserting the report into a NG Application Protocol (NGAP) message and transmitting the NGAP message to the core network in the control plane.

15. generating and transmitting the report to the core network, inserting the report into an E1 Application Protocol (E1AP) message in the control plane and transmitting the E1AP message to the user plane of the radio access network node; extracting the report from the E1AP message and inserting the report into a PDU Session Information PDU in the user plane of the radio access network node; transmitting the PDU session information PDU to the core network in the user plane; The method of claim 12, comprising:

16. The method of claim 10 , wherein the data transmission delay comprises an uplink user plane data transmission delay.

17. 17. The method according to claim 16, wherein the transmission delay information item received from the wireless terminal device comprises time stamp information of at least one uplink data packet transmitted from the wireless terminal device.

18. 20. The method of claim 17, wherein the time stamp information of the at least one uplink data packet transmitted from the wireless terminal device is included in a header of the at least one uplink data packet.

19. the transmission delay provisioning segmentation scheme includes the end-to-end delay scheme; 18. The method of claim 17, wherein generating and transmitting the report to the core network in accordance with the transmission delay configuration comprises relaying the time stamp information to the core network for the core network to calculate the data transmission delay.

20. The transmission delay provisioning segmentation scheme includes the RAN partial delay scheme; generating and transmitting the report to the core network in accordance with the transmission delay configuration; calculating RAN partial delay information associated with the at least one uplink data packet in the user plane of the radio access network node; transmitting the RAN partial delay information to a control plane of the radio access network node; transmitting the RAN partial delay information to the core network via an NGAP message in the control plane; 20. The method of claim 17, comprising:

21. The transmission delay provisioning segmentation scheme includes the RAN partial delay scheme; generating and transmitting the report to the core network in accordance with the transmission delay configuration; calculating RAN partial delay information associated with the at least one uplink data packet in the user plane of the radio access network node; transmitting the RAN partial delay information to the core network to the core network via an uplink PDU session information PDU in the user plane; 20. The method of claim 17, comprising:

22. 1. A method for monitoring / reporting, by a wireless terminal device, a data transmission delay between said wireless terminal device and a core network in a wireless network, comprising: receiving a transmission delay configuration from a control plane of a radio access network node, the transmission delay configuration comprising: a transmission delay provisioning segmentation scheme from among a plurality of segmentation schemes, or A monitoring / reporting configuration for the data transmission delay from among a plurality of monitoring / reporting configurations. and identifying at least one of transmitting a transmission delay information item to said radio access network node during a data transmission session between said core network and said wireless terminal device according to said transmission delay configuration; A method comprising:

23. 23. The method of claim 22, wherein the transmission delay provisioning segmentation scheme includes one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

24. The monitoring / reporting configuration includes: Reporting timing structure, reporting granularity configuration, or Data packet transmission time stamp method 24. The method of claim 23, comprising at least one of:

25. The method of claim 24, wherein the reporting timing configuration indicates a reporting frequency or a reporting time period.

26. The reporting granularity configuration may further comprise: Average data packet delay, Per-packet delay, Packet Delay Distribution, or Packet delay distribution information 25. The method of claim 24, further comprising reporting the at least one of:

27. the reporting granularity configuration indicates reporting the data transmission delay as the packet delay distribution; the packet delay distribution is included within an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field indicating a number of delay ranges; a plurality of blocks of fields, each block of fields containing a number of packets having a delay value that falls within one of said delay ranges; 27. The method of claim 26, comprising:

28. The reporting granularity configuration indicates that the data transmission delay is reported as the packet delay distribution information; the packet delay distribution information is included in an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field for identifying a packet delay distribution formula; a second field for indicating the number of parameters associated with the packet delay distribution equation; a block of fields containing values ​​of said number of parameters; 27. The method of claim 26, comprising:

29. the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay; The per-packet delay is contained within an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field indicating a number of delay samples per packet; a plurality of second fields each containing a per-packet delay sample; 27. The method of claim 26, comprising:

30. The data packet transmission time stamp method includes: Including a transmission timestamp in the data packet header, or Including a transmission time stamp in a packet data convergence protocol header The method of claim 24, wherein the method further comprises:

31. The method of claim 22 , wherein the data transmission delay is associated with a user plane of the wireless network.

32. 32. The method of claim 31, wherein the data transmission delay comprises a downlink user plane data transmission delay.

33. The method includes: obtaining reception timestamp information of at least one downlink data packet; and generating the transmission delay information item by calculating end-to-end downlink transmission delay information or RAN-partial downlink transmission delay information associated with the at least one downlink data packet according to the reception timestamp information and the transmission delay configuration; 33. The method according to claim 32, wherein said transmission delay information item is transmitted to a control plane of said radio access network node.

34. 34. The method of claim 33, wherein the transmission delay information item is transmitted as part of a Radio Resource Control (RRC) measurement report.

35. 32. The method of claim 31, wherein the data transmission delay comprises an uplink user plane data transmission delay.

36. 36. The method according to claim 35, wherein said transmission delay information item comprises time stamp information of at least one uplink data packet transmitted from said wireless terminal device.

37. 37. The method of claim 36, wherein the time stamp information of the at least one uplink data packet transmitted from the wireless terminal device is included in a header of the at least one uplink data packet.

38. 1. A method for provisioning a data transmission delay between a wireless terminal device and a core network by a core network node of a wireless network, comprising: transmitting a transmission delay configuration to a radio access network node, the transmission delay configuration comprising: a transmission delay provisioning segmentation scheme from among a plurality of segmentation schemes, or A monitoring / reporting configuration for the data transmission delay from among a plurality of monitoring / reporting configurations. and identifying at least one of receiving, during a data transmission session between said core network node and said wireless terminal device, a transmission delay information item from said radio access network node, said transmission delay information item being generated by said radio access network node or said wireless terminal device in accordance with said transmission delay configuration; A method comprising:

39. 40. The method of claim 38, wherein the transmission delay provisioning segmentation scheme includes one of an end-to-end delay scheme or a radio access network (RAN) partial delay scheme.

40. The monitoring / reporting configuration includes: Reporting timing structure, reporting granularity configuration, or Data packet transmission time stamp method 40. The method of claim 39, comprising at least one of:

41. 41. The method of claim 40, wherein the reporting timing configuration indicates a reporting frequency or a reporting time period.

42. The reporting granularity configuration may further comprise: Average data packet delay, Per-packet delay, Packet Delay Distribution, or Packet delay distribution information 41. The method of claim 40, further comprising reporting the at least one of:

43. the reporting granularity configuration indicates reporting the data transmission delay as the packet delay distribution; the packet delay distribution is included within an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field indicating a number of delay ranges; a plurality of blocks of fields, each block of fields containing a number of packets having a delay value that falls within one of said delay ranges; 43. The method of claim 42, comprising:

44. The reporting granularity configuration indicates that the data transmission delay is reported as the packet delay distribution information; the packet delay distribution information is included in an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field for identifying a packet delay distribution formula; a second field for indicating the number of parameters associated with the packet delay distribution equation; a block of fields containing the numerical values ​​of said parameters; 43. The method of claim 42, comprising:

45. the reporting granularity configuration indicates reporting the data transmission delay as a per-packet delay; The per-packet delay is contained within an uplink protocol data unit (PDU) session frame; The uplink PDU session frame comprises: a first field indicating a number of delay samples per packet; a plurality of second fields each containing a per-packet delay sample; 43. The method of claim 42, comprising:

46. The data packet transmission time stamp method includes: Including a transmission timestamp in the data packet header, or Including a transmission time stamp in a packet data convergence protocol header 41. The method of claim 40, wherein the method further comprises:

47. 41. The method of claim 40, wherein the data transmission delay is associated with a user plane of the wireless network.

48. 48. The method of claim 47, wherein the data transmission delay comprises a downlink user plane data transmission delay.

49. The transmission delay information item is received from the radio access network node; and 49. The method of claim 48, comprising end-to-end downlink transmission delay information or RAN-partial downlink transmission delay information calculated by the wireless terminal device and associated with at least one downlink data packet relayed by the radio access network node.

50. 50. The method of claim 49, wherein the transmission delay information item is received from a control plane of the radio access network node in a NG Application Protocol (NGAP) message.

51. 50. The method of claim 49, wherein the transmission delay information item is received from the user plane of the radio access network node as a header in a PDU Session Information PDU.

52. The transmission delay information item includes the RAN partial downlink transmission delay information, and the method further comprises: calculating end-to-end downlink transmission delay information based on said transmission delay information item and core-to-access transmission delay information associated with said at least one downlink data packet; 50. The method of claim 49, further comprising:

53. the transmission delay provisioning segmentation scheme includes the end-to-end delay scheme; 48. The method according to claim 47, wherein said transmission delay information item comprises time stamp information for transmitting at least one uplink data packet from said wireless terminal device.

54. The transmission delay provisioning segmentation scheme includes the RAN partial delay scheme; 48. The method of claim 47, wherein said transmission delay information item comprises RAN partial delay information calculated by said radio access network node.

55. 55. A method according to claim 54, wherein the transmission delay information item is received in an NGAP message from a control plane of the radio access network node.

56. 55. The method of claim 54, wherein the transmission delay information item is received in a PDU Session Information PDU from the user plane of the radio access network node.

57. A radio network node in a radio network device comprising a memory for storing instructions and a processor for executing said instructions and for implementing any of claims 1 to 56.

58. 57. A computer-readable, non-transitory medium for storing computer instructions that, when executed by a processor of a wireless network device, cause the wireless network device to implement any of claims 1 to 56.

Images