[go: up one dir, main page]

WO2025162882A1 - Technique de gestion d'ensembles de pdu dans ul - Google Patents

Technique de gestion d'ensembles de pdu dans ul

Info

Publication number
WO2025162882A1
WO2025162882A1 PCT/EP2025/051996 EP2025051996W WO2025162882A1 WO 2025162882 A1 WO2025162882 A1 WO 2025162882A1 EP 2025051996 W EP2025051996 W EP 2025051996W WO 2025162882 A1 WO2025162882 A1 WO 2025162882A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdu set
qos
pdu
report message
measurement
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2025/051996
Other languages
English (en)
Inventor
Fabian DE LAVAL
Richard TANO
Jose Luis Pradas
Du Ho Kang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2025162882A1 publication Critical patent/WO2025162882A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS

Definitions

  • the present disclosure relates to a technique for handling a set of packet data units (PDUs). More specifically, and without limitation, methods and devices are provided for controlling Quality of Service (QoS) of a PDU set as a whole.
  • QoS Quality of Service
  • PDU Protocol Data Unit
  • 3GPP Third Generation Partnership Project
  • PDU sets are designed to encapsulate units of information generated at the application level, such as video frames or slices, and ensure their transmission within the same QoS flow. This is critical for services such as XR, wherein even minor disruptions or delays can significantly degrade the user experience.
  • the PDU set framework aims to meet the stringent QoS demands of these applications by providing parameters like PDU set Delay Budget (PSDB) and PDU set error rate (PSER), which help to define the acceptable bounds for delay and error rates in data transmission.
  • PSDB PDU set Delay Budget
  • PSER PDU set error rate
  • the existing technology faces a significant challenge: while the core network can signal PDU set information to the Radio Access Network (RAN) for downlink traffic management, there is a gap in the uplink path.
  • RAN Radio Access Network
  • gNodeB the Radio Access Network
  • This decision creates a dilemma for the RAN, which now lacks the ability to identify and measure the performance of uplink PDU sets against their QoS requirements.
  • This gap poses a risk to the reliability and effectiveness of services that rely on uplink data, such as XR applications, which may have dynamic and time-sensitive traffic patterns.
  • the absence of real-time QoS performance data makes it challenging for the network to configure and manage uplink PDU set handling effectively, potentially leading to suboptimal user experiences.
  • a method performed by a wireless device (WD), wirelessly connected or connectable to an access network (AN) comprises or initiates the step of measuring, at the WD, at least one quality of service (QoS) parameter of a packet data unit set (PDU set) in an uplink towards the AN.
  • the method further comprises or initiates the step of transmitting, to the AN, a report message indicative of a result of the measurement.
  • QoS quality of service
  • the first method aspect may be implemented alone or in combination with any one of the embodiments, particularly the claims 1 to 13.
  • Embodiments of the first method aspect may configure the wireless device (e.g., a UE) to measure and report UL QoS performance (as the result of the QoS measurement) in the report message.
  • the wireless device e.g., a UE
  • the UL QoS performance include PDU set error rate (PSER) and/or PDU set delay statistics.
  • PSER PDU set error rate
  • the report message may trigger replacing or modifying one or more existing rules for scheduling the PDU set (e.g., rules for scheduling radio resources, rules for bearer selection and/or rules for mapping the UL bearer to a QoS flow) at the AN (e.g., at the network node serving the wireless device).
  • rules for scheduling the PDU set e.g., rules for scheduling radio resources, rules for bearer selection and/or rules for mapping the UL bearer to a QoS flow
  • the AN e.g., at the network node serving the wireless device.
  • TFTs UL traffic flow templates
  • the TFTs may be used to map one or more data flows from the WD to the appropriate one or more bearers based on at least one of: the report message, one or more QoS requirements, an internet protocol (IP) address, the direction of the traffic (here being UL and not DL), a protocol, and a port number.
  • IP internet protocol
  • the report message may be indicative of the QoS used according to one or more TFTs.
  • the report message may trigger the replacement or modification of existing rules for scheduling the Protocol Data Unit (PDU) set, such as rules for scheduling radio resources, bearer selection, or mapping the uplink (UL) bearer to a Quality of Service (QoS) flow at the Access and Mobility Management Function (AMF) or the Next Generation NodeB (gNB) serving the WD.
  • PDU Protocol Data Unit
  • AMF Access and Mobility Management Function
  • gNB Next Generation NodeB
  • the wireless device may utilize UL traffic flow templates (TFTs) to select UL bearers within the 5G system.
  • TFTs UL traffic flow templates
  • TFTs can be applied to map one or more data flows from the WD to the appropriate bearers based on factors including the report message, QoS requirements, IP addresses, traffic direction, protocols, and/or port numbers.
  • the report message may provide an indication of the QoS used based on one or more TFTs.
  • the access network may be a wireless AN, e.g. a radio access network (RAN). Transmitting the report message may be referred to as reporting.
  • the measurement may be referred to as QoS measurement.
  • the measuring and the reporting may relate to the UL between the WD and the AN, e.g. between the WD and one or more network nodes of the AN.
  • the at least one QoS parameter may be measured for the UL towards a first network node of the AN.
  • the report message may be transmitted to a second network node of the AN.
  • the second network node may be different from the first network node (e.g., spatially separate base stations).
  • the measuring and the reporting may relate to the UL between the WD and the same network node.
  • the report message may be indicative of the measured at least one uplink QoS parameter and/or the result of the measured at least one uplink QoS parameter (e.g., an average or variance or a distribution) uplink QoS parameter.
  • the WD may transmit the PDU set, or may attempt to transmit the PDU set, to the AN.
  • the PDU set may be available for transmission at the WD or may have been partially transmitted to the AN.
  • the PDU set may comprise a plurality of PDUs.
  • the PDU may refer to the data units of a user plane (UP) PDU layer responsible for PDU session establishment.
  • UP user plane
  • the QoS parameter (e.g., according to the first method aspect) may relate to the PDU set as a whole. Alternatively or in addition, the QoS parameter may be not indicative of individual PDUs in the PDU set.
  • the QoS parameter may relate to the QoS for the PDU set as a whole, e.g. not for individual PDUs in the PDU set.
  • the at least one QoS parameter of the PDU set may comprise at least one of a PDU set error rate (PSER) of the PDU set; a PDU set delay budget (PSDB) of the PDU set; a PDU set importance (PSI) of the PDU set; and a PDU set integrated handling information (PSIHI) of the PDU set.
  • PSER PDU set error rate
  • PSDB PDU set delay budget
  • PSI PDU set importance
  • PSIHI PDU set integrated handling information
  • the PSI and/or PSIHI may be indicative of information related to one or more QoS parameters and their inter-relation.
  • the measured PSDB may comprise a delay of the PDU set (e.g., a maximum time or initial PSDB minus the delay).
  • the measured PSDB may be positive (e.g., representing a remaining PSDB) or negative (e.g., indicating that the delay budget has been exceeded).
  • the method may further comprise or initiate determining whether the measured at least one QoS parameter meets a predefined criterion.
  • the report message may be indicative of whether or not the predefined criterion may be fulfilled.
  • the transmission of the report message may be triggered if the predefined criterion is not fulfilled.
  • the predefined criterion may be received (e.g., in a configuration message) from the AN, e.g., from a network node of the AN (e.g., from the first network node and/or the second network node).
  • the predefined criterion may comprise a threshold value for a threshold of the at least one QoS parameter, optionally a threshold value for a threshold of a or the PDU set error rate (PSER) of the PDU set or a or the PDU set delay budget (PSDB) of the PDU set and/or a threshold value for a threshold of a variance of the at least one QoS parameter.
  • PSER PDU set error rate
  • PSDB PDU set delay budget
  • Layer 2 structure of new radio may be split in sublayers such as SDAP, PDCP, radio link control (RLC), and medium access control (MAC).
  • sublayers such as SDAP, PDCP, radio link control (RLC), and medium access control (MAC).
  • RLC radio link control
  • MAC medium access control
  • the method may further comprise or initiate transmitting a capability message to the AN.
  • the capability message may be indicative of at least one of a capability of the WD to measure the at least one QoS parameter of the PDU set in the uplink towards the AN; a capability of the WD to report the result of the measurement of the at least one QoS parameter to the AN; one or more QoS parameters of the PDU set in the uplink towards the AN, which the WD may be capable of measuring and/or for which the WD may be capable of transmitting the report message; a physical layer information of the WD; and a feature set indicator, optionally comprising radio protocol information.
  • the received configuration message from the AN may be based on the transmitted capability message to the AN.
  • the measuring mode and the reporting mode may correspond to one mode. For example, if the at least one QoS parameter is to be reported periodically, then the at least one QoS parameter is measured periodically, etc.
  • a or the (e.g., aforementioned) measuring mode for the measuring may comprise at least one of a periodic measurement, an aperiodic measurement, an event-triggered measurement, and on-demand measurement.
  • the event-triggered mode may be a meeting predefined criterion, optionally the predefined criterion may be received from the AN, e.g., as a configuration message.
  • on-demand may comprise upon request, e.g., upon receiving a request message from the AN (e.g., from the first or second network node).
  • a or the (e.g., aforementioned) reporting mode for the transmitting of the report message may comprise at least one of a periodic reporting, an aperiodic reporting, an event-triggered reporting, and on- demand reporting.
  • All PDUs in the PDU set may be transmitted on the same QoS flow (e.g., according to the first method aspect). Alternatively or in addition, all PDUs in the PDU set may be associated with the same QoS flow identifier (QFI). Alternatively or in addition, all PDUs in the PDU set may be transmitted on the same data radio bearer (DRB).
  • the report message (e.g., according to the first method aspect) may be transmitted to a network node of the AN, optionally to the network node serving the WD.
  • a method performed by a network node of an access network comprises or initiates receiving a report message from a wireless device (WD), wirelessly connected to the AN.
  • the report message may be indicative of a result of a measurement of at least one QoS parameter of a PDU set at the WD in an uplink towards the AN.
  • the method further comprises or initiates scheduling resources for the uplink of the WD based on the received report message.
  • the second method aspect may be implemented alone or in combination with any one of the embodiments, particularly the claims 14 to 19.
  • the second method aspect may further comprise any feature and/or any step disclosed in the context of the first method aspect, or a feature and/or step corresponding thereto, e.g., a receiver counterpart to a transmitter feature or step.
  • the AN e.g., the gNB
  • the AN may use this information to optimize network performance and/or ensure that QoS requirements are met for the PDU set as a whole.
  • Embodiments can improve scheduling decisions at the AN.
  • the AN e.g., the first and/or second network node, preferably a gNB
  • the AN can make better-informed scheduling decisions, prioritizing traffic of mutually dependent PDU collections (i.e., the PDU set) that are sensitive to delay or errors and/or can manage congestion more effectively.
  • mutually dependent PDU collections i.e., the PDU set
  • the report message may be indicative of a QoS performance reports from UEs.
  • the report message may comprise at least one of the following metrics: PDU set error rate (PSER), PDU set delay budget (PSDB), and other QoS-related information for the PDU set.
  • PSER PDU set error rate
  • PSDB PDU set delay budget
  • the receiving step may comprise receiving multiple report messages, e.g. relating to different QoS parameters of the same PDU set and/or relating to the same at least one QoS parameter at different times of the measurement.
  • the method may be performed by a network node of the AN, e.g., the network node serving the WD or the fore-mentioned first and/or second network node.
  • the method may be performed by a gNodeB (gNB) (e.g., a base station in a 5G network as the AN), which interfaces with the WD (e.g., a user equipment (U E)) and a core network (e.g., a 5G core network, 5GC).
  • gNB gNodeB
  • U E user equipment
  • 5GC 5G core network
  • embodiments of the AN can leverage the QoS parameters reported by the WD (e.g., UE) to optimize a performance of the AN, and/or ensuring that user experiences are consistent with the QoS profiles defined for various services. This can be critical in 5G ANs, wherein a wide range of services with diverse QoS requirements must be supported simultaneously.
  • the scheduling may comprise configuring the WD with radio resources for the uplink.
  • the scheduling may comprise setting one or more AN parameters related to the WD and/or the PDU set, e.g. at least one of a data rate, a (e.g., remaining) PDU set delay budget, and the predefined criterion.
  • the AN may use the information to configure enhanced scheduling mechanism, such as a configured grant (CG), discontinuous reception (DRX), and pre-scheduling or semi- persistent scheduling (SPS).
  • CG configured grant
  • DRX discontinuous reception
  • SPS semi- persistent scheduling
  • the receiving of the report message may comprise analyzing the report.
  • the AN e.g., the gNB
  • the AN may process the received one or more report messages to determine the current QoS performance for PDU set and/or for each WD (e.g., UE). This may involve analyzing QoS parameters of the PDU set related to error rate, delay, and throughput.
  • the QoS requirement of the PDU set and the predefined criterion for the PDU set may be equivalent and/or these terms may be used interchangeably.
  • the QoS requirement for the PDU set may be, or may be derived from, a service level agreement (SLA) for the service (e.g., application) underlying the PDU set.
  • SLA service level agreement
  • the receiving of the report message may comprise assessing compliance with QoS requirements for the PDU set (e.g., as a whole, not individual PDUs).
  • QoS requirements for the PDU set e.g., as a whole, not individual PDUs.
  • a QoS requirement of the PDU set may apply to each PDU in the PDU set for the QoS requirement of the PDU set to be fulfilled by the PDU set.
  • the AN may discard all PDUs in the PDU set if the requirement is not fulfilled by at least one PDU in the PDU set.
  • the AN e.g., the gNB
  • a network may comprise the AN and a core network (CN) serving the AN.
  • CN core network
  • PDU Set information (e.g., as to the QoS required in UL and/or DL) may be signaled from a core network (CN) to the AN (e.g., RAN). With this information available, the AN (e.g., the network node) may identify the PDU Set for PDU Set handling in the downlink (DL) traffic to meet PDU Set requirements. Alternatively or in addition, with this information available, the AN may compare result of the QoS measurements for the uplink (UL) in the report message with QoS requirements in the PDU Set information.
  • CN core network
  • the AN e.g., the network node
  • the AN may compare result of the QoS measurements for the uplink (UL) in the report message with QoS requirements in the PDU Set information.
  • the AN may control PDU set handling in the UL (e.g., scheduling) responsive to the report message to fulfill a dynamic traffic pattern and/or a dynamic QoS requirement (e.g., as indicated in the PDU set information from the CN).
  • the report message may provide real-time knowledge of the QoS at the wireless device to the AN.
  • the scheduling of the resources may comprise at least one of adjusting a resource allocation, optionally if the received report message may be indicative of at least one QoS requirement of the PDU set not being met, the resource allocation for WD may be adjusted or scheduling priorities may be changed or the allocation of time-frequency resources may be modified or the power control settings are adjusted; configuring one or more functions of the AN may be based on the received report message, optionally Hybrid Automatic Repeat Request (HARQ) settings are reconfigured or a modulation and coding scheme(MCS) may be reconfigured or a retransmission strategy may be reconfigured; updating PDU set handling at the AN; adapting to a dynamic traffic patterns, optionally the AN uses the received report message as dynamic QoS performance information to adapt to changing traffic patterns and/or wherein an application underlying the PDU set uses variable bit rates or burst-like traffic; and sending feedback to a core network serving the AN, optionally sending feedback to the core network regarding a QoS performance of
  • HARQ Hybrid Automatic Repeat Request
  • the QoS requirement is not met if the predefined criterion is not fulfilled, e.g., if a the PSER is greater than a predefined (e.g., configured) threshold value or if a delay exceeds the PSDB.
  • the predefined criterion e.g., if a the PSER is greater than a predefined (e.g., configured) threshold value or if a delay exceeds the PSDB.
  • (re-)configuring one or more functions of the AN based on the received report message can improve reliability and/or reduce latency if the criterion is not fulfilled, or can free resources if the criterion is fulfilled with a margin.
  • the AN e.g., the gNB
  • the AN may use the report message to handle the PDU set more efficiently, e.g., ensuring that all PDUs within a PDU set are delivered within the required QoS parameters of said application.
  • XR extended reality
  • the AN may use the dynamic QoS performance information to adapt to changing traffic patterns, which is especially important for applications with variable bit rates or bursty traffic.
  • the AN may continuously optimize its operation based on the report message.
  • the AN e.g., the gNB
  • continuously monitors the received report messages from multiple WDs e.g., UEs
  • the AN adapts to the varying conditions and/or maintains the desired QoS levels for all services.
  • the method may further comprise or initiate receiving a capability message from the WD.
  • the capability message being indicative of at least one of a capability of the WD to measure the at least one QoS parameter of the PDU set in the uplink towards the AN; a capability of the WD to report the result of the measurement of the at least one QoS parameter to the AN; one or more QoS parameters of the PDU set in the uplink towards the AN, which the WD may be capable of measuring and/or for which the WD may be capable of transmitting the report message; a physical layer information of the WD; and a feature set indicator, optionally comprising radio protocol information.
  • the method may further comprise or initiate transmitting a configuration message to the WD.
  • the configuration message being indicative of at least one of the at least one QoS parameter to be measured; the predefined criterion, optionally the threshold value, for the at least one QoS parameter, a measurement window for the measurement of the at least one QoS parameters; a measurement periodicity for the measurement of the at least one QoS parameter; a deadline for the receiving of the report message; a PDU set identifier of the PDU set; a QoS flow identifier (QFI) associated with the PDU set; a data radio bearer (DRB) associated with the PDU set; a PDU set importance (PSI) associated with the PDU set; a measuring mode for the measuring; and a reporting mode for the transmitting of the report message.
  • the configuration message being indicative of at least one of the at least one QoS parameter to be measured; the predefined criterion, optionally the threshold value, for the at least one QoS parameter, a measurement window
  • the scheduling may comprise changing a mapping of at least one data radio bearer (DRB) to at least one QoS flow identifier (QFI) used by the PDU set in response to the receiving of the report message.
  • DRB data radio bearer
  • QFI QoS flow identifier
  • a Data Radio Bearer may be a service provided by the radio protocol architecture to transfer user data between the WD (e.g., a UE) and the AN (e.g., a RAN).
  • the DRB may be responsible for the transfer of user plane data.
  • the DRB may be technically characterized by several parameters that define how data is handled and transmitted over the radio interface. The scheduling may comprise changing at least one of these parameters.
  • Each DRB may be associated with a specific QoS profile, which defines the treatment that the data flowing over this bearer will receive. This may include parameters such as priority, packet delay budget, packet error loss rate, and bit rates (GBR, MBR, etc.) of the level of individual PDUs, which can be controlled by the AN as opposed to the reported QoS parameters on the level of the PDU set, which cannot be measured at (e.g., the lower layers) of the AN.
  • the QoS profile may ensure the required level of service for various types of traffic such as voice over IP (VoIP), real-time video, or best-effort data transfer.
  • the DRB may be mapped to a Logical Channel, which is an abstract concept defining the type of information being transferred.
  • a dedicated traffic channel DTCH
  • DTCH dedicated traffic channel
  • a radio link control (RLC) protocol may be operated for the PDU set in one of three modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM).
  • TM transparent mode
  • UM unacknowledged mode
  • AM acknowledged mode
  • Each DRB may be associated with an RLC entity that operates in one of these modes, defining the level of reliability for the data transfer.
  • the scheduling may comprise changing the mode. For example, transparent mode does not provide error correction, unacknowledged mode may provide partial error correction, and acknowledged mode may use an Automatic Repeat Request (ARQ) mechanism for full error correction.
  • ARQ Automatic Repeat Request
  • the scheduling may comprise changing a configuration of a packet data convergence protocol (PDCP).
  • PDCP packet data convergence protocol
  • the PDCP may provide header compression, decompression, and ciphering functionalities to reduce overhead and secure the data.
  • the PDCP configuration for a DRB may define how the data should be processed by the PDCP layer.
  • the scheduling may comprise establishing, modifying, or releasing a radio bearer setup by signaling procedures between the WD (e.g., UE) and the AN. These procedures may define the properties of the one or more DRBs and how data is to be managed over them.
  • the scheduling may comprise changing a security of the PDU set on the one or more DRBs, which may be encrypted and/or integrity-protected to ensure privacy and prevent tampering.
  • the scheduling may comprise mobility handling of the PDU set.
  • the one or more DRBs may be configured to support seamless handovers when the WD (e.g., a UE) moves from one cell to another. This can ensure that all PDUs in the PDU set are continuously transferred despite the mobility of the WD.
  • a Quality of Service flow in the context of 3GPP specifications, particularly for 5G networks (5G NR), may encompass any concept defined in a service-based architecture of the AN and/or the core network (CN) serving the AN to manage and/or ensure the delivery of all PDUs in the PDU set with the required service quality.
  • QoS flow Quality of Service flow
  • CN core network
  • Each QoS flow may be identified by a QoS Flow Identifier (QFI).
  • the QFI may be unique for the WD and/or within a PDU session of the WD.
  • the QFI may be used for mapping between the 5G Core (5GC) as the CN and the Radio Access Network (RAN) as the AN.
  • the QFI may be carried in the protocol headers to differentiate between different QoS flows.
  • the scheduling of resources for the PDU set may comprise changing at least one parameter in a set of parameters associated with each QoS flow to define the required treatment by the network.
  • the 5QI may be an index defining a scalar QoS characteristics of IP packets transferred in the PDUs of the PDU set, which are reference to the level of guarantee to be provided for packet delivery.
  • the ARP may be used for ensuring resources in congested situations and has a priority level, preemption capability, and preemption vulnerability.
  • the GBR and the non-GBR may be two types of QoS flows. In the GBR, the QoS flow is allocated a certain amount of network resources, while a non-GBR QoS flow shares resources with other flows.
  • the scheduling may comprise changing QoS rules of the level of PDUs.
  • the QoS may be defined by rules that govern how certain types of traffic are treated within the AN or the CN or the network. These rules may be used to determine how packets are forwarded in a QoS flow and/or include QoS rule identifiers, precedence, and segregation and aggregation rules.
  • the scheduling may comprise changing a traffic flow template.
  • traffic flow templates For mapping between the user traffic and the QoS flows, one or more traffic flow templates (TFTs) may be used. These templates classify PDUs in the PDU set based on parameters such as source and destination IP addresses, source and destination ports, protocol identifiers, and more.
  • TFTs traffic flow templates
  • These templates classify PDUs in the PDU set based on parameters such as source and destination IP addresses, source and destination ports, protocol identifiers, and more.
  • the AN may apply the changed template to all PDUs in the PDU set.
  • the scheduling may comprise QoS flow level signaling or any signaling procedures for establishing, modifying, or releasing the QoS flows between the WD and the network (e.g., the AN or the CN).
  • the scheduling may comprise protocols and procedures for the QoS flow setup during the establishment of the PDU session.
  • the scheduling of the resources responsive to received report message may comprise a deviation from reflective QoS and/or reflective mapping of DRBs to QFIs.
  • the AN may use for the uplink the same QoS treatment and/or mapping as the corresponding downlink flow without explicit signaling from the WD.
  • the AN may use for the uplink the a QoS treatment and/or mapping the is different from the corresponding downlink flow based on the received report message.
  • the scheduling may control an operation of the AN to ensure that all PDUs of the PDU set associated with a QoS flow are handled in the network, complying with the predefined criterion (e.g., a QoS requirement of the PDU set).
  • Embodiments, especially in 5G networks, can support diverse services with different QoS requirements for their PDU sets, such as enhanced mobile broadband (eMBB), ultra-reliable and low latency communications (URLLC), and massive machine type communications (mMTC).
  • eMBB enhanced mobile broadband
  • URLLC ultra-reliable and low latency communications
  • mMTC massive machine type communications
  • the method may further comprise any one of the steps or features of the first method aspect.
  • the computer program product comprises program code portions for performing any one of the steps of the first method aspect or the second method aspect when the computer program product is executed on one or more computing devices, optionally stored on a computer-readable recording medium.
  • a wireless device wirelessly connected or connectable to an access network (AN).
  • the WD comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the WD is operable to measure, at the WD, at least one quality of service (QoS) parameter of a packet data unit set (PDU set) in an uplink towards the AN; and transmit, to the AN, a report message indicative of a result of the measurement.
  • QoS quality of service
  • the WD may further comprise the features or being operable to perform any one of the steps of the first method aspect.
  • a wireless device wirelessly connected or connectable to an access network (AN)
  • the WD being configured to measure, at the WD, at least one quality of service (QoS) parameter of a packet data unit set (PDU set), in an uplink towards the AN; and transmit, to the AN, a report message indicative of a result of the measurement.
  • QoS quality of service
  • PDU set packet data unit set
  • the WD may further comprise the features or being configured to perform any one of the steps of the first method aspect.
  • a network node of an access network comprising memory operable to store instructions and processing circuitry operable to execute the instructions, such that the network node is operable to receive a report message from a wireless device (WD), wirelessly connected to the AN.
  • the report message is indicative of a result of a measurement of at least one QoS parameter of a PDU set at the WD in an uplink towards the AN.
  • the network node is further operable to schedule resources for the uplink of the WD based on the received report message.
  • the network node (e.g. according to the second device aspect) may further operable to perform any one of the steps of the second method aspect.
  • a network node of an access network is provided.
  • the network node being configured to receive a report message from a wireless device (WD), wirelessly connected to the AN.
  • the report message is indicative of a result of a measurement of at least one QoS parameter of a PDU set at the WD in an uplink towards the AN.
  • the network node being further configured to schedule resources for the uplink of the WD based on the received report message.
  • the network node (e.g. according to the other second device aspect) may further configured to perform any one of the steps of the second method aspect.
  • the communication system including a host computer comprising processing circuitry configured to provide user data; and a communication interface configured to forward user data to a cellular or ad hoc radio network for transmission to a user equipment (UE).
  • the UE comprises a radio interface and processing circuitry, the processing circuitry of the UE being configured to execute any one of the steps of the first method aspect.
  • the communication system may further include the UE.
  • the radio network e.g. according to the system aspect
  • the base station (e.g. according to the system aspect), or the radio device functioning as a gateway, may comprise processing circuitry, which may be configured to execute any one of the steps of the second method aspect.
  • the processing circuitry of the host computer may be configured to execute a host application, thereby providing the user data; and the processing circuitry of the UE may be configured to execute a client application associated with the host application.
  • Embodiments of any one of the first and second method aspects can enhance the management of Quality of Service (QoS) for uplink communication in wireless networks.
  • Embodiments of the method enable a wireless device (WD) to measure QoS parameters of a Packet Data Unit (PDU) set in the uplink direction towards the access network (AN) and subsequently transmit a report message to the AN indicating the results of this measurement.
  • WD wireless device
  • PDU Packet Data Unit
  • At least some of these embodiments can improved QoS management.
  • the WD can provide valuable feedback to the access network, allowing it to adjust scheduling, resource allocation, and error correction strategies to meet the QoS requirements of different data flows.
  • Same or further embodiments can achieve real-time performance monitoring.
  • the ability to measure and report QoS parameters in real-time enables the AN to dynamically monitor the performance of the uplink connection. This can be particularly important for applications with stringent QoS requirements, such as extended reality (XR) services, wherein even small deviations in QoS can significantly impact user experience.
  • XR extended reality
  • Same or further embodiments can enhance network responsiveness.
  • the AN can quickly respond to changing network conditions or service requirements, e.g. implementing adjustments to maintain or improve the QoS for active PDU sets.
  • Same or further embodiments can use AN resource more efficiently or more effectively.
  • the information provided by the WD can assist the AN optimize the use of available radio resources, leading to more efficient network operation and/or higher overall throughput. For example, smaller margins in the resource allocation can be controlled by virtue of the measurement report.
  • Same or further embodiments can address or resolve AN issues preemptively.
  • the AN can proactively take corrective actions before service quality is noticeably impacted, thus maintaining high service reliability and user satisfaction.
  • the AN can use the reported QoS measurements to configure QoS policies (e.g., mapping rules or scheduling rules) for individual PDU sets or QoS flows, e.g. ensuring that each type of traffic receives the appropriate QoS based on its specific characteristics and requirements.
  • QoS policies e.g., mapping rules or scheduling rules
  • any “radio device” may be a user equipment (UE).
  • UE user equipment
  • the wireless device may be a remote wireless device that is wirelessly connected to the AN through relay wireless device.
  • the report message may be forwarded (e.g., on behalf of the wireless device or as a report message of the relay wireless device itself) to the AN.
  • the AN may be a radio access network (RAN).
  • the RAN may comprise one or more network nodes (e.g., base stations), e.g., performing the second method aspect.
  • the AN may be a vehicular, ad hoc and/or mesh network comprising two or more radio devices, e.g., acting as remote radio device and/or relay radio device.
  • Any wireless device may be a radio device, e.g. a 3GPP user equipment (UE) or a Wi-Fi station (STA).
  • the wireless device may be a mobile or portable station, a device for machine-type communication (MTC), a device for narrowband Internet of Things (NB-loT) or a combination thereof.
  • MTC machine-type communication
  • NB-loT narrowband Internet of Things
  • Examples for the UE and the mobile station include a mobile phone, a tablet computer and a self-driving vehicle.
  • Examples for the portable station include a laptop computer and a television set.
  • Examples for the MTC device or the NB-loT device include robots, sensors and/or actuators, e.g., in manufacturing, automotive communication and home automation.
  • the MTC device or the NB-loT device may be implemented in a manufacturing plant, household appliances and consumer electronics.
  • the AN may be implemented by one or more network nodes (e.g., base stations such as optical or radio base stations).
  • network nodes e.g., base stations such as optical or radio base stations.
  • the term network node may encompass any station that is configured to provide wireless access (e.g., radio access) to any of the wireless devices.
  • the base stations may also be or may comprise or may define a cell, a transmission and reception point (TRP), a radio access node or access point (AP).
  • TRP transmission and reception point
  • AP radio access node or access point
  • Examples for the network node may include a 3G base station or Node B (NB), 4G base station or eNodeB (eNB), a 5G base station or gNodeB (gNB), a Wi-Fi AP, and a network controller (e.g., according to Bluetooth, ZigBee or Z-Wave).
  • the AN may provide a data link from the wireless device to a host computer, e.g. providing a PDU set (e.g., carrying user data) in the DL and/or receiving the PDU set (e.g., carrying user data) from the wireless device in the UL.
  • a host computer e.g. providing a PDU set (e.g., carrying user data) in the DL and/or receiving the PDU set (e.g., carrying user data) from the wireless device in the UL.
  • the AN may be implemented according to the Global System for Mobile Communications (GSM), the Universal Mobile Telecommunications System (UMTS), 3GPP Long Term Evolution (LTE) and/or 3GPP New Radio (NR).
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Telecommunications System
  • LTE 3GPP Long Term Evolution
  • NR 3GPP New Radio
  • any aspect of the technique may be implemented on a Physical Layer (PHY), a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, a packet data convergence protocol (PDCP) layer, a Radio Resource Control (RRC) layer and/or a Service Data Adaptation Protocol (SDAP) layer of a protocol stack for the wireless (e.g., radio) communication.
  • PHY Physical Layer
  • MAC Medium Access Control
  • RLC Radio Link Control
  • PDCP packet data convergence protocol
  • RRC Radio Resource Control
  • SDAP Service Data Adaptation Protocol
  • the steps may be performed by one or more entities of a protocol layer at the AN.
  • Any one of the method aspects may be performed by a combination of different layers, e.g. the SDAP) layer in the user plane may be responsible for defining the QoS requirements and the PDCP layer may be responsible for processing (e.g., sending or receiving) the report message.
  • the SDAP Secure Sockets Layer
  • a wireless device e.g., a UE
  • may be configured e.g., by receiving a configuration message at the wireless device from the AN in the first method aspect and/or by sending a configuration message from the AN to the wireless device in the second method aspect) to report (e.g., to send) uplink (UL) QoS measurement information (e.g., in the report message), optionally over the PDCP or SDAP protocol layers.
  • the report message may be dynamically reported, e.g. either periodically, aperiodic, or upon a request from the AN.
  • referring to a protocol of a layer may refer to the corresponding layer in the protocol stack or a method performed by said layer.
  • referring to a layer of the protocol stack may also refer to the corresponding protocol of the layer. Any protocol may be implemented by a corresponding method.
  • a computer program product comprises program code portions for performing any one of the steps of the method aspect disclosed herein when the computer program product is executed by one or more computing devices.
  • the computer program product may be stored on a computer-readable recording medium.
  • the computer program product may also be provided for download, e.g., via the radio network, the RAN, the Internet and/or the host computer.
  • the method may be encoded in a Field-Programmable Gate Array (FPGA) and/or an Application-Specific Integrated Circuit (ASIC), or the functionality may be provided for download by means of a hardware description language.
  • FPGA Field-Programmable Gate Array
  • ASIC Application-Specific Integrated Circuit
  • a wireless device As to a first device aspect, a wireless device according to embodiment 21 of the list of embodiments is provided.
  • the wireless device comprises processing circuitry (e.g., at least one processor and a memory).
  • Said memory comprises instructions executable by said at least one processor whereby the wireless device is operative to perform any one of the steps of the first method aspect.
  • the wireless device is configured to perform any one of the steps of the first method aspect.
  • a network node according to embodiment 25 of the list of embodiments.
  • the network node comprises processing circuitry (e.g., at least one processor and a memory).
  • Said memory comprises instructions executable by said at least one processor whereby the network node is operative to perform any one of the steps of the second method aspect.
  • the network node is configured to perform any one of the steps of the second method aspect.
  • a communication system including a host computer.
  • the host computer comprises a processing circuitry configured to provide or receive user data, e.g., included in the PDU set.
  • the host computer may comprise a communication interface configured to receive the PDU set from a cellular network (e.g., the AN and/or the network node serving the wireless device) from the wireless device (e.g., a UE).
  • a processing circuitry of the cellular network is configured to execute any one of the steps of the first and/or second method aspects.
  • the UE comprises a radio interface and processing circuitry, which is configured to execute any one of the steps of the first and/or second method aspects.
  • the communication system may further include the UE.
  • the cellular network may further include one or more base stations configured for radio communication with the UE and/or to provide a data link between the UE and the host computer using the first and/or second method aspects.
  • the processing circuitry of the host computer may be configured to execute a host application, thereby providing the first and/or second data and/or any host computer functionality described herein.
  • the processing circuitry of the UE may be configured to execute a client application associated with the host application.
  • Any one of the devices, the UE, the base station, the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa.
  • any one of the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect.
  • any one of the devices, the transmitting node, the receiving node, the user equipment (UE), the network node, the base station, the communication system or any node or station for embodying the technique may further include any feature disclosed in the context of the method aspect, and vice versa the method aspect may comprise any step or feature disclosed in the context of the device aspects.
  • the units and modules disclosed herein may be configured to perform or initiate one or more of the steps of the method aspect, and the devices may comprise a unit or a module performing any of the steps of the method aspect.
  • Fig. 1 shows a schematic block diagram of a device embodiment of a first aspect for handling a PDU set
  • Fig. 2 shows a schematic block diagram of a device embodiment of a second aspect for handling a PDU set
  • Fig. 3 shows a flowchart for a method embodiment of a first aspect for handling a PDU set, which method may be implementable by the device of Fig. 1;
  • Fig. 4 shows a flowchart for a method embodiment of a second aspect for handling a PDU set, which method may be implementable by the device of Fig- 2;
  • Fig. 5 schematically illustrates a first example of an access network comprising first embodiments of the devices of Figs. 1 and 2 for performing the methods of Figs. 3 and 4, respectively;
  • Fig. 6 schematically illustrates an existing downlink network architecture, which may be combined with an uplink network architecture according to any of the embodiments of Figs. 1 to 4;
  • Fig. 7 schematically illustrates a second example of an access network and a downlink network architecture comprising second embodiments of the devices of Figs. 1 and 2 for performing the methods of Figs. 3 and 4, respectively;
  • Fig. 8 schematically illustrates a block diagram of protocol sublayers for performing the method of Fig. 3 or 4 according to a third embodiment
  • Fig. 9 schematically illustrates a block diagram of protocol entities for performing the method of Fig. 3 or 4 according to a fourth embodiment
  • Fig. 10 schematically illustrates a block diagram of protocol entities for performing the method of Fig. 3 or 4 according to a fifth embodiment
  • Fig. 11 schematically illustrates a block diagram of protocol sublayers for performing the method of Fig. 3 or 4 according to a sixth embodiment
  • Fig. 12 schematically illustrates a signaling diagram resulting from devices of Figs. 1 and 2 performing the method of Fig. 3 or 4 according to a seventh embodiment
  • Fig. 13 shows a schematic block diagram of a remote radio device embodying the device of Fig. 1;
  • Fig. 14 shows a schematic block diagram of a relay radio device embodying the device of Fig. 2;
  • Fig. 15 schematically illustrates an example telecommunication network connected via an intermediate network to a host computer
  • Fig. 16 shows a generalized block diagram of a host computer communicating via a base station or radio device functioning as a gateway with a user equipment over a partially wireless connection;
  • Figs. 17 and 18 show flowcharts for methods implemented in a communication system including a host computer, a base station or radio device functioning as a gateway and a user equipment.
  • WLAN Wireless Local Area Network
  • 3GPP LTE e.g., LTE-Advanced or a related radio access technique such as MulteFire
  • Bluetooth according to the Bluetooth Special Interest Group (SIG), particularly Bluetooth Low Energy, Bluetooth Mesh Networking and Bluetooth broadcasting, for Z-Wave according to the Z-Wave Alliance or for ZigBee based on IEEE 802.15.4.
  • SIG Bluetooth Special Interest Group
  • Fig. 1 schematically illustrates a block diagram of an embodiment of a device for handling a PDU set according to a first aspect of the subject technique.
  • the device is generically referred to by reference sign 100.
  • the device 100 may be capable of handling PDU sets, such as a wireless device, e.g. a user equipment (UE) in a telecommunication network.
  • UE user equipment
  • the device 100 for handling PDU sets comprises a PDU Set Measurement Module 106 and a Report Transmission Module 110.
  • the PDU Set Measurement Module 106 is responsible for measuring the QoS parameters of a PDU set in an uplink towards an access network, which could be tasks like calculating metrics such as PDU set delay budgets or error rates.
  • the measured QoS parameters pertain to the PDU set as a whole rather than individual PDUs within the set.
  • the Report Transmission Module 110 facilitates transmitting a report message indicative of the measurement results to an access network (AN, e.g. a RAN). Specifically, this module oversees creating and dispatching the report message, which may be a PDCP control PDU or an SDAP control PDU.
  • the report message may carry information such as the QoS parameter measurements and may be triggered by certain predefined criteria, like exceeding (e.g. positive or negative) thresholds of the QoS parameters measured by the PDU Set Measurement Module 106. This can enable the AN to control the scheduling to steer the PDU set QoS within a margin above the QoS requirements of the service underlying the PDU set.
  • Any of the modules of the device 100 may be implemented by units configured to provide the corresponding functionality.
  • the device 100 may also be referred to as, or may be embodied by, the wireless device (or briefly: UE).
  • the wireless device 100 and the AN may be in direct radio communication, e.g., at least for sending the report message from the wireless device 100 to the AN.
  • the AN may be embodied by the device 200, e.g. a base station or network node.
  • Fig. 2 schematically illustrates a block diagram of an embodiment of a device for handling a Packet Data Unit (PDU) set according to a second aspect of the subject technique.
  • the device is generically referred to by reference sign 200.
  • the device 200 depicted in Fig. 2 may be a network node designed for handling PDU sets.
  • This device can be embodied by a gNB, which is an element within an access network (AN) such as a 5G network responsible for communicating with wireless devices like user equipment (UE), e.g. the device 100.
  • AN access network
  • UE user equipment
  • the PDU Set Scheduling Module 212 Complementing the Report Reception Module 210 is the PDU Set Scheduling Module 212.
  • This module takes into account the QoS information received from the one or more wireless devices and schedules resources accordingly. For example, it uses the report message to allocate the necessary uplink resources to meet the QoS requirements for the PDU set or each of the PDU sets. It may also be responsible for managing any necessary adjustments or reconfigurations to the network's uplink scheduling strategies in order to optimize performance and adhere to service level agreements.
  • modules of the device 200 may be implemented by units configured to provide the corresponding functionality.
  • the device 200 may also be referred to as, or may be embodied by, the AN or a network node of the AN (or briefly: gNB).
  • the network node 200 and the wireless device may be in direct radio communication, e.g., at least for exchanging the report message from the wireless device to the network node 200.
  • the wireless device may be embodied by the device 100.
  • SA2 System Architecture and Services working group 2
  • PDU Packet Data Unit
  • new requirements including PDU set Quality of Service Parameters and PDU set information were introduced to support PDU set handling, e.g. each of which three features are exemplified below.
  • Radio Layer 2 and Radio Layer 3 RRC working group introduced UE features to support PDU set handling in the uplink.
  • RAN2 agreed that a UE can identify PDU sets and related PDU set information for PDU set handling.
  • a PDU set may comprise one or more PDUs carrying the payload of one unit of information generated at the application level, e.g. one or more frames or one or more video slices, etc., e.g. for extended Reality (XR) services. All the PDUs of a PDU set are transmitted within the same Quality of Service (QoS) flow.
  • QoS Quality of Service
  • Any embodiment of any aspect may be implemented based on general information provided by the 3GPP TS 23.501, version 18.4.0 or later.
  • PDU set QoS Parameters are used to support PDU set based QoS handling in the Next Generation RNA (NG- RAN) or 5G System (5GS). At least one PDU set QoS Parameter shall be sent to the NG-RAN to enable PDU set based QoS handling.
  • NG- RAN Next Generation RNA
  • 5GS 5G System
  • Any embodiment may use at least one of the following PDU set QoS parameters, e.g. as specified in any of the above-mentioned 3GPP documents:
  • PSDB PDU set Delay Budget
  • PSER PDU set Error Rate
  • PSI HI Integrated Handling Information
  • a QoS profile may include the PDU set QoS Parameters described herein.
  • the Policy Control Function may determine the one or more PDU set QoS parameters based on information provided by an Application Function (AF) and/or a local configuration.
  • the PDU set QoS parameters are sent to the Session Management Function (SMF) as part of a policy and charging control rule (PCC rule).
  • the Session Management Function (SMF) sends them to the AN (e.g., a Next Generation Radio Access Network, NG-RAN) as part of the QoS profile.
  • AN e.g., a Next Generation Radio Access Network, NG-RAN
  • the AN e.g., NG-RAN
  • receives PDU set QoS parameters and supports them it enables the PDU set based QoS handling and applies PDU set QoS Parameters as described herein.
  • Any embodiment of any aspect may use the PDU set error rate as an example of the QoS parameter.
  • the PDU set Error Rate defines an upper bound for the rate of PDU sets that have been processed by the sender of a link layer protocol (e.g. RLC in RAN of a 3GPP access) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. Packet Data Convergence Protocol (PDCP) in RAN of a 3GPP access).
  • PDCP Packet Data Convergence Protocol
  • the PSER defines an upper bound for a rate of non-congestion related PDU set losses.
  • the purpose of the PSER is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in RAN of a 3GPP access).
  • a PDU set may be considered as successfully delivered only when all PDUs of a PDU set are delivered successfully.
  • the PDU set may comprise at least two PDUs.
  • how the AN (e.g., RAN) enforces PSER is up to RAN implementation.
  • a QoS flow may be associated with only one PDU set error rate.
  • PSER is an optional parameter. If the PSER is available, the PSER supersedes the PER. The value of the PDU set error rate is the same in UL and DL.
  • any embodiment of any aspect may use the PDU set delay budget as an example of the QoS parameter, e.g. including any one of the following features.
  • the PDU set delay budget may define an upper bound for the delay that a PDU set may experience for the transfer between the UE 100 and the N6 termination point at the UPF (e.g., below reference sign 522), i.e. the duration between the reception time of the first PDU (at the N6 termination point for DL or the UE for UL) and the time when all PDUs of a PDU set have been successfully received (at the UE for DL or N6 termination point for UL).
  • the UPF e.g., below reference sign 522
  • the (e.g., same) PSDB may apply to the DL PDU set received by the PDU Session Anchor (PSA) UPF over the N6 interface and/or to the UL PDU set sent by the UE 100.
  • PSA PDU Session Anchor
  • a QoS Flow is associated with only one PDU set delay budget.
  • the value of the PDU set delay budget is the same in UL and DL.
  • PSDB is an optional parameter that may be provided by the Policy Control Function (PCF).
  • PCF Policy Control Function
  • the provided PSDB can be used by the NG-RAN to support the configuration of scheduling and link layer functions.
  • the PSDB When the PSDB is available, the PSDB supersedes a packet delay budget (PDB) for the given QoS Flow.
  • PDB packet delay budget
  • An AN PSDB (i.e., the PSDB of the access network, AN) may be derived at NG-RAN by subtracting a CN PDB (i.e. a packet delay budget or a PDU set delay budget of the core network, CN, e.g., as described herein or in clause 5.7.3.4 of aforementioned 3GPP document TS 23.501) from the PSDB.
  • a CN PDB i.e. a packet delay budget or a PDU set delay budget of the core network, CN, e.g., as described herein or in clause 5.7.3.4 of aforementioned 3GPP document TS 23.501
  • Any aspect of any embodiment may include PDU set based handling (or handling of the PDU set as a whole) as a QoS parameter of the PDU set or as a control item of the scheduling based on the report message.
  • a PDU set may be comprised of one or more PDUs carrying an application layer payload such as, e.g. a video frame or video slice.
  • the PDU set based QoS handling by the NG-RAN is determined by PDU set QoS Parameters in the QoS profile of the QoS Flow (specified in clause 5.7.7 of the afore-mentioned 3GPP document TS 23.501) and PDU set information provided by the PSA UPF via N3/N9 interface (e.g., as described in clause 5.37.5.2 loc. cit.).
  • the PDU set based QoS Handling can be applied for Guaranteed Bit Rate (GBR) and non-GBR QoS Flows.
  • GBR Guaranteed Bit Rate
  • the AF may provide PDU set related assistance information for dynamic Policy and Charging Control (PCC) control.
  • PCC Policy and Charging Control
  • One or more of the following PDU set related assistance information may be provided to the NEF/PCF using the AF session with required QoS procedures (e.g., in clauses 4.15.6.6 and 4.15.6.6a of the 3GPP document TS 23.502, version 18.4.0).
  • PDU set QoS Parameters as described in clause 5.7.7 of 3GPP document TS 23.501, version 18.4.0.
  • Protocol Description Indicates transport protocol (e.g. RTP, SRTP), transport protocol header extensions (e.g. RTP Header Extension for PDU set marking as defined in 3GPP document TS 26.522, version 0.2.0), payload type and format (e.g. H.264, H.265), and format parameters (e.g. H.264 profile level and packetization mode) used by the service data flow.
  • transport protocol e.g. RTP, SRTP
  • transport protocol header extensions e.g. RTP Header Extension for PDU set marking as defined in 3GPP document TS 26.522, version 0.2.0
  • payload type and format e.g. H.264, H.265
  • format parameters e.g. H.264 profile level and packetization mode
  • the PDU set QoS Parameters and/or Protocol Description may be provided by the CN, e.g. by the AF and/or may be used in determining PCC Rules by the PCF as defined in clause 6.1.3.27.4 of 3GPP document TS 23.503, version 18.4.0, and the Protocol Description may be used for identifying the PDU set information by the PSA UPF.
  • the SMF When the SMF receives a PCC rule containing one or more PDU set QoS Parameters (PSER, PSDB and PSIHI), the SMF adds these PDU set QoS parameters to the QoS Profile of the QoS Flow as described in clause 6.2.2.4 of the 3GPP document TS 23.503.
  • the SMF may be configured to support PDU set based QoS Handling without receiving PCC rules from a PCF.
  • the PSA UPF For the downlink direction, the PSA UPF identifies PDUs that belong to PDU sets and marks them accordingly as described in clause 5.37.5.2. If the UPF receives a PDU that does not belong to a PDU set based on Protocol Description for PDU set identification, then the UPF still maps it to a PDU set and determines the PDU set Information as described in said clause 5.37.5.2.
  • the PSA UPF determines the PDU set importance value based on pre-configuration.
  • Any embodiment of any aspect may use PDU set Information and/or Identification as an example of the QoS parameter, e.g. including any one of the following features.
  • the PSA UPF identifies PDUs that belong to PDU sets and determines the below PDU set information which it sends to the NG-RAN in the GPRS Tunneling Protocol (GTP-U) header.
  • the PDU set information is used by the NG-RAN for PDU set based QoS handling as described above.
  • the PDU set information comprises:
  • PDU set importance which identifies the relative importance of a PDU set compared to other PDU sets within a QoS Flow.
  • the NG-RAN may use the Priority Level (e.g. according to clause 5.7.3.3 of said 3GPP document 23.501) across QoS Flows and PDU set importance within a QoS Flow for PDU set level packet discarding in presence of congestion.
  • Priority Level e.g. according to clause 5.7.3.3 of said 3GPP document 23.501
  • NG-RAN could also consider the relative PDU set Importance across QoS Flows of the same Priority Level when determining which PDU set needs to be discarded, which is up to implementation and configuration of operator.
  • the PDU set Information can be different for different PDU sets within a QoS Flow.
  • the PDU set may have XR traffic characteristics, e.g. as described below.
  • XR applications typically generate traffic flows which are in principle periodic, e.g. video traffic with 30, 60, 90, or 120 fps.
  • the traffic arrival moment at the RAN is affected by jitter around the periodicity value, due to processing of the frames at the application (e.g. for compression) and the capabilities of the platform used by the application, as well as transmission through the Core Network.
  • This is modelled in 3GPP document TR 38.838, by assuming that each data frame arriving at the RAN has a random jitter of [-4; +4] ms (optionally [-5; +5] ms) around the main periodicity.
  • the probability of the jitter value within this interval is given by a truncated Gaussian distribution with mean 0 ms and standard deviation 2 ms.
  • XR traffic has strict delay requirements, in terms of packet delay budget (PDB). This is the maximum tolerable delay for a packet to be transmitted from a gNB to a UE.
  • PDB packet delay budget
  • the PDB value depends on the XR traffic type and is overall between 5 ms and 30 ms. It is expected that XR traffic will comprise one or more PDU sets.
  • Any embodiment of any aspect may relate to reporting QoS performance status information in the report message, e.g., dynamically, using control PDUs sent between SDAP and/or PDCP layers.
  • below reference sign may refer to Figs. 5 and 7.
  • the device 100 is described with reference to a wireless device for concreteness and not limitation.
  • Fig. 3 shows an example flowchart for a method 300 of handling PDU sets, e.g. by a device depicted in Fig. 1.
  • the method 300 may begin with an optional step 302 wherein the wireless device 100 transmits a capability message 502 to the access network 510.
  • This capability message 502 informs the network of various capabilities of the wireless device 100 including its ability to measure certain QoS parameters of a PDU set and transmit a report message indicating the result of the measurement.
  • the wireless device 100 receives a configuration message 504 from the access network 510.
  • the configuration message 504 provides parameters that the wireless device 100 needs to measure QoS parameters of the PDU set.
  • the parameters may include which QoS parameters to measure, criteria for determining when to transmit a report message, and metrics for how to perform the measurement.
  • the wireless device 100 measures at least one QoS parameter of the PDU set 750 in the uplink towards the access network 510. This involves measuring parameters that pertain to the PDU set as a whole, such as PDU set delay budget or error rate, rather than individual PDUs within the set.
  • step 308 the wireless device 100 determines whether the measured QoS parameter meets one or more predefined criteria.
  • the one or more criteria for the QoS measurement may comprise one or more thresholds or other comparison metrics that have been previously configured by the network and which relate to the satisfactory level of QoS.
  • the wireless device 100 transmits a report message 506 to the access network 510 which is indicative of the result of the measurement.
  • This report message 506 may include information such as whether the predefined criteria are met, and/or it may be used by the AN (e.g., the network node 200 of the wireless device 100) to make scheduling decisions or configure radio resources (e.g., by means of a configured grant, CG).
  • the transmission of this report message 506 might be triggered by events such as the criteria not being met, indicating a possible degradation in QoS for the PDU set 750.
  • the method 300 may be performed by the device 100.
  • the modules 106 and 110 may perform the steps 306 and 310, respectively.
  • Fig. 4 shows an example flowchart for a method 400 of handling PDU sets.
  • the method 400 depicted in Fig. 4 outlines a process for a network node 200 to manage the handling of a PDU set.
  • This method 400 may capture the actions the network node 200 takes upon receiving information from a wireless device about the Quality of Service parameters associated with the PDU set that the wireless device has been measuring in the uplink towards the access network, e.g. the network node itself.
  • the network node 200 receives 410 a report message from the wireless device, which is wirelessly connected to the access network.
  • This report message is indicative of the results of measurements of QoS parameters for a PDU set in the uplink direction.
  • the report message may contain various measured QoS parameters such as PDU set delay budget, error rates, or other relevant QoS data that reflect the performance of the uplink transmission of the PDU set.
  • the method 400 is described below for a network node 200 of an AN.
  • the network node 200 receives 402 a capability message from the wireless device, signaling the wireless device's capabilities pertinent to the QoS measurements of the PDU set.
  • This capability message may include details such as specific QoS parameters the wireless device is capable of measuring and reporting, along with any related physical layer information or feature set indicators.
  • the network node 200 transmits 404 a configuration message, which may be sent to the wireless device to configure certain aspects of the QoS parameters measurements.
  • the transmitted configuration message can specify details such as what QoS parameters should be measured, the thresholds or criteria for triggering measurements, measurement windows, periodicity, and reporting modes.
  • the method 400 involves the network node 200 scheduling resources 412 is the broadest technical sense, which is done based on the received report message.
  • the scheduling step 412 may entail making decisions and/or allocations regarding uplink resources that were or will be assigned to the wireless device. This may include adjusting the allocation of uplink resources to meet or compensate for the reported QoS measurements, ensuring the quality of the transmitted PDU set meets predefined QoS requirements or adjusting the priority and handling of different PDU sets based on their QoS parameters.
  • these actions carried out by the network node 200 in method 400 can collectively contribute to the effective management of the PDU set handling in the uplink, ensuring QoS compliance and optimized resource utilization in the access network (AN).
  • the dotted boxes signifying steps 402 and 404 represent optional actions that can augment the main scheduling operation but are not mandatory components of the method 400.
  • the method 400 may be performed by the device 200, e.g. a network node of any other one or more nodes of the AN or CN.
  • the modules 210 and 212 may perform the steps 410 and 412, respectively.
  • the technique may be applied to uplink (UL), downlink (DL) or direct communications between radio devices, e.g., device-to-device (D2D) communications or sidelink (SL) communications.
  • UL uplink
  • DL downlink
  • D2D device-to-device
  • SL sidelink
  • Each of the transmitting station 100 and receiving station 200 may be a radio device or a base station.
  • any radio device may be a mobile or portable station and/or any radio device wirelessly connectable to a base station or RAN, or to another radio device.
  • the radio device may be a user equipment (UE), a device for machine-type communication (MTC) or a device for (e.g., narrowband) Internet of Things (loT).
  • UE user equipment
  • MTC machine-type communication
  • LoT narrowband
  • Two or more radio devices may be configured to wirelessly connect to each other, e.g., in an ad hoc radio network or via a 3GPP SL connection.
  • any base station may be a station providing radio access, may be part of a radio access network (RAN) and/or may be a node connected to the RAN for controlling the radio access.
  • the base station may be an access point, for example a Wi-Fi access point.
  • the wireless device 100 is described with reference to an exemplary UE 100 and the network node 200 is described with reference to an exemplary gNB 200 in a 5G setting for illustration.
  • the skilled person will appreciate that this illustration is not limiting, and that the corresponding features and steps can be implemented beyond 5G and/or for an optical data link.
  • Fig. 5 schematically illustrates a first example of an access network comprising first embodiments of the devices 100 and 200 for performing corresponding first embodiments of the methods 300 and 400, respectively.
  • Fig. 5 depicts a schematic illustration of an example of a telecommunication network 500, emphasizing how it integrates devices for handling Packet Data Unit (PDU) sets.
  • the example features two wireless devices, labeled generically as UE 100, each situated within distinct cells or beams 201 of network nodes, labeled as gNB 200.
  • UE 100 operates within the scope of a gNB 200, representing its connection to the broader access network (AN) 510.
  • AN access network
  • the illustration captures a moment of communication wherein each UE 100 sends a report message 506 to its respectively serving gNB 200.
  • This exchange of the report message is denoted by directed arrows, symbolizing the sending 310 and receiving 410 of control signaling.
  • the report messages 506 result from the internal processes 300 of the UEs 100 concerning PDU sets, which are transmitted in the uplink, e.g. direction toward the gNB 200.
  • the illustration shows a core network (CN) 520, interfaced with the AN 510.
  • the CN 520 may serve as the backbone, interfacing with external networks or services and relaying information into and out of the AN 510.
  • the CN 520 may signal QoS requirements of the PDU set to the AN 510, while the report message 506 provides the actual measurement values of the QoS parameters at the UE 100.
  • Fig. 5 accentuates how individual components within a telecommunication network — e.g., UEs 100, gNBs 200, and the core network 520 — collaborate to manage and convey QoS-related information pertaining to PDU sets in a wireless communication environment.
  • a telecommunication network e.g., UEs 100, gNBs 200, and the core network 520 — collaborate to manage and convey QoS-related information pertaining to PDU sets in a wireless communication environment.
  • Fig. 6 schematically illustrates an existing downlink network architecture, which may be combined with an uplink network architecture according to any of the embodiments of the devices 100 and 200 and the methods 300 and 400.
  • Fig. 6 presents a schematic overview of an example of the downlink network architecture.
  • the devices 100 and 200 may inherit any feature of the devices 10 and 20, respectively.
  • the UE 10 interfaces with the gNB 20, which serves as a connection point within the access network to manage PDU sessions and QoS flows.
  • a feature of the architecture is the delineation of a PDU session, which encompasses the entirety of the QoS flow and interfaces with an N3 Tunnel connecting to a UPF.
  • the UPF provides connectivity to an Application Server (AS) within a Data Network (DN), establishing a comprehensive channel from the user applications to the network infrastructure.
  • AS Application Server
  • DN Data Network
  • DRBs data radio bearers
  • the Data Network addresses the service routing by imposing QoS policies for Service Data Flows (SDF), such as SDF1, SDF2, SDF3, and SDF4, each corresponding to specific IP flow characteristics such as flow 1, flow 2, flow 3, flow 4, and flow 5, which are ultimately realized in the user applications.
  • SDF Service Data Flows
  • An essential aspect of this communication system 50 is the implementation of QFI Insertion at various stages of the PDU session to precisely steer the data packets according to their predetermined QoS requirements.
  • This fine-grained control supported by additional network protocols like the Internet Protocol (IP), solidifies the QoS enforcement mechanisms integral to the network performance and the user experience.
  • IP Internet Protocol
  • TFT/SPDF Template filtering at a Data Network (DN), user plane function (UPF), and application server (AS) junction provides a supplementary means to refine and optimize traffic flow management based on complex rules and conditions that govern the passage of data packets through the network.
  • any concept illustrated or described by Fig. 6 for the ability of the network 50 to deliver differential QoS levels in the DL may be applied to the subject technique in the UL and/or controlled by the report message, e.g., ensuring that the diverse service requirements of modern telecommunication networks are met with precision and efficiency in both UL and DL.
  • conventional reflective QoS is an optional feature for the UE 10 that allows the UE 10 to deduce the uplink (UL) mapping between QoS flows and radio bearers from the downlink (DL) mapping, e.g., if QoS Flow Identifier (QFI) X is mapped to DRB Y in the DL, then it is the same in UL.
  • UL uplink
  • DL downlink
  • Fig. 7 schematically illustrates a second example of an access network (AN) 510 (e.g. a downlink network architecture of the AN 510) comprising second embodiments of the devices 100 and 200 for performing the methods 300 and 400, respectively.
  • AN access network
  • Fig. 7 schematically illustrates a second example of an access network (AN) 510 (e.g. a downlink network architecture of the AN 510) comprising second embodiments of the devices 100 and 200 for performing the methods 300 and 400, respectively.
  • AN access network
  • AN access network
  • Fig. 7 schematically illustrates an example of an access network (AN) 510 and a downlink network architecture encompassing second embodiments of devices for handling a PDU set 750.
  • AN access network
  • a downlink network architecture encompassing second embodiments of devices for handling a PDU set 750.
  • the wireless device 100 is capable of handling PDU sets such as those in an uplink towards the AN 510, e.g. a network node 200, which can be a components of broader telecommunication systems that manage various data flows and network efficiencies.
  • the architecture also includes the network node 200 (e.g., a gNB) designed to handle the PDU sets within the access network 510.
  • This network node may manage and/or optimize the flow of PDUs, especially the PDU sets 750, between the wireless device 100 and the core network (CN) 520.
  • the CN 520 is a part of the telecommunication network 500 that provides a multitude of services and connectivity to other networks or services, interfacing with the access network 510 and transmitting data to and from an application server (AS) located in or beyond a data network DN (e.g., the Internet).
  • AS application server
  • DN e.g., the Internet
  • the wireless device 100 Central to the efficiency of the system 500, the wireless device 100 employs a PDU Set Measurement Module 306 and a Report Transmission Module 310 for the uplink PDU set 750.
  • the PDCP layer 710 of the wireless device 100 is responsible for key functions like header compression, encryption, and ensuring data integrity.
  • Radio Bearers 714 facilitate the transfer of data radio bearers from applications within the wireless device 100.
  • the network node 200 leverages a Report Reception Module 210 to handle incoming reports and a PDU Set Scheduling Module 212 to manage resources optimally. It utilizes PDCP 710 and/or SDAP 720 layers for protocol functionality, which handle tasks such as mapping QoS flows to DRBs and marking QoS flow IDs in data packets, e.g. based on the report message 506.
  • the QoS flows 724 are associated with specific quality of service metrics, such as guaranteed bit rates, delays, and priority levels. These flows are critical for ensuring that the network can meet various service level agreements and user expectations for data transmission quality.
  • the PDU set 750 is the focal point of these interactions, being the collection of PDUs that are transmitted as a unit of data at the application level.
  • the entire set of PDUs is transmitted within the same QoS flow 724, ensuring consistent handling across the network.
  • a mapping function or PDU session 702 works in conjunction with an N3 Tunnel 704 to at least one of these layers 710 and/or 720 to the CN 520.
  • This tunneling facility is a critical part of ensuring secure and reliable data transfer from the AN 510 (e.g., a Radio AN, i.e. RAN) to the CN 520 part of the telecommunication system 500.
  • report messages 506 are crucial for conveying information about the performance and requirements of the PDU set 750.
  • These report messages 506 can be indicators of QoS parameters such as PDU set error rate, delay budget, and/or importance for each respective device's scheduling and handling of data flows.
  • Any feature, e.g. for the network node reaction in the step 412, may be based on or extend, any 3GPP features (e.g., as discussed herein) and/or may involve alternative or additional configurations, features, or communication protocols that can be implemented to enhance or modify the standard data handling procedures of the PDU set 750 in the wireless device 100 and/or the network node 200 within the access network 510.
  • any 3GPP features e.g., as discussed herein
  • any 3GPP features e.g., as discussed herein
  • the UE 100 may decide the mapping between QoS flows and radio bearers in the UL.
  • the gNB 200 may reflect that mapping in the UL.
  • the report message may comprise instructions to overrule the reflective mapping.
  • the gNB 200 may change the
  • the report message may trigger or change in the PDCP and/or SDAP layer (e.g., by using an PDCP or SDAP control PDU as the report message) the mapping between QFI and DRB.
  • the PDCP or SDAP may signal to lower layers of the radio protocol stack (e.g., the medium access control layer, MAC layer, or the physical layer, PHY layer) for performing scheduling
  • the radio protocol stack e.g., the medium access control layer, MAC layer, or the physical layer, PHY layer
  • Another advantage of using SDAP or PDCP control PDUs for the report message is that these PDUs are carried over the same DRB as the user data. This means they receive the same priority as the user data (e.g., the PDUs of the PDU set).
  • the report message may be sent using assistance information, e.g. to have the report reach the layer that is most relevant for the mapping or scheduling.
  • the SDAP or PDCP layer in the gNB 200 may simply receive 410 the report message and forward it to the corresponding implemented function, e.g. that does the bookkeeping of the QoS for each UE 100 in the gNB 200.
  • the reported message may be indicative a result of the measurement or a value QoS parameter for the PDU set that triggers a control reaction, e.g. by activating feature X in layer Y or reconfigure DRB mapping.
  • SDAP Service Data Adaptation Protocol
  • the objective is to describe the SDAP architecture and the SDAP entity from a functional point of view.
  • the specified functionality only applies to UE 100 with connection to the 5G-CN 520 and UE 100 in NR sidelink (SL) communication.
  • Any embodiment of any aspect may implement at least one of the following features of a structure of the SDAP layer 720.
  • Fig. 8 schematically illustrates one possible structure for the SDAP sublayer 720. It should not restrict an implementation of the SDAP sublayer 720.
  • the SDAP sublayer may be implemented according to the radio interface protocol architecture defined in 3GPP document TS 38.300, version 18.0.0, e.g. Figure 4.2.1-1 therein, which provides an SDAP sublayer structure view.
  • the SDAP sublayer may be configured for DRBs by RRC, e.g. according to 3GPP document TS 38.331, version 18.0.0.
  • the SDAP sublayer 720 maps QoS flows to DRBs. One or more QoS flows may be mapped onto one DRB. One QoS flow is mapped onto only one DRB at a time in the UL.
  • the SDAP sublayer may be configured for Multicast/Broadcast Service (MBS) Radio Bearers (MRBs) by RRC, e.g. according to 3GPP document TS 38.331, version 18.0.0.
  • MBS Multicast/Broadcast Service
  • MRBs Radio Bearers
  • the SDAP sublayer maps MBS QoS flows to MRBs. One or more MBS QoS flows may be mapped onto one MRB.
  • the SDAP sublayer maps PC5 QoS flows to SL-DRBs.
  • One or more PC5 QoS flows may be mapped onto one SL-DRB.
  • One PC5 QoS flow is mapped onto only one SL-DRB at a time in the NR sidelink for transmission.
  • Any embodiment of any aspect may implement at least one of the following features of SDAP entities 722.
  • the SDAP entities 722 are located in the SDAP sublayer 720 (also: layer). Several SDAP entities 722 may be defined for a UE 100. There is an SDAP entity 722 configured for each individual PDU session or MBS session for NR Uu. For NR sidelink, an SDAP entity 722 may be configured per Destination Layer-2 ID and cast type in the UE 100.
  • An SDAP entity 722 receives and/or delivers SDAP service data units (SDUs) from and/or to upper layers and/or submits and/or receives SDAP data packet data units (PDUs) to and/or from its peer SDAP entity 722 via lower layers.
  • SDUs SDAP service data units
  • PDUs SDAP data packet data units
  • an SDAP entity 722 for the SDAP sublayer 720 may be implemented according to the functional view of Fig. 9 and/or the SDAP layer functional view of Figure 4.2.2-1 in 3GPP document TS 38.300, version 18.0.0. These example should not restrict an implementation of the SDAP sublayer 720.
  • the figure is based on the radio interface protocol architecture defined in 3GPP document TS 38.300, version 18.0.0.
  • Reflective QoS flow to DRB mapping may be performed at the UE 100, e.g. as specified in the clause 5.3.2, if DL SDAP header is configured.
  • reflective mapping of a QoS flow to an MRB is not supported.
  • MRB i.e., Multicast/Broadcast Service Radio Bearer
  • reflective PC5 QoS flow to SL-DRB mapping is not supported for NR sidelink (SL) communication.
  • Any embodiment of any aspect may implement at least one of the following features and steps of services provided to upper layers.
  • the SDAP sublayer 720 provides its service to the user plane upper layers.
  • An example service provided by the SDAP sublayer 720 to upper layers is transfer of user plane data.
  • An SDAP entity 722 may expect from lower layers at least one of the following services: user plane data transfer service; in-order delivery except when out of order delivery is configured by RRC (e.g., according to 3GPP document TS 38.331, version 18.0.0).
  • RRC Radio Resource Control
  • Any embodiment of any aspect may implement at least one of the following functional features of the SDAP sublayer: transfer of user plane data; mapping between a QoS flow and a DRB for both DL and UL; mapping between an MBS QoS flow and an MRB for DL; mapping between a PC5 QoS flow and a SL-DRB for NR sidelink communication; marking QoS flow ID in both DL and UL packets; marking PC5 QoS flow ID in unicast of NR sidelink communication packets; and reflective QoS flow to DRB mapping for the UL SDAP data PDUs.
  • any step of the methods 300 and/or 400 may be implemented at or using a Packet Data Convergence Protocol (PDCP) layer 710.
  • PDCP Packet Data Convergence Protocol
  • the PDCP layer 710 may support at least one of the following functions: transfer of data (user plane or control plane); maintenance of PDCP SNs; header compression and decompression using the ROHC protocol; header compression and decompression using the EHC protocol; uplink data compression and decompression using the UDC protocol; ciphering and deciphering; integrity protection and integrity verification; timer based SDU discard; for split bearers and DAPS bearer, routing; duplication; reordering and in-order delivery; out-of-order delivery; duplicate discarding.
  • Fig. 10 provides a functional view of the PDCP layer 710.
  • the gNB 200 may comprise dedicated logic in the PDCP layer to respond to the QoS report message, e.g. trigger discarding of more or less packets in the PDCP layer 710, as an example of the step 410.
  • the PDCP entities are located in the PDCP sublayer. Several PDCP entities may be defined for a UE. Each PDCP entity is carrying the data of one radio bearer. A PDCP entity is associated either to the control plane or the user plane depending on which radio bearer it is carrying data for.
  • Fig. 11 provides a schematic structural view of the PDCP layer 710.
  • the PDCP entity 712 receiving 410 the report message may control the RLC (or further lower layers) for the changing the scheduling of radio resources, e.g. by scheduling less resources when there is a predefined margin between the measure QoS parameters for the PDU set and the QoS requirements, or by scheduling more resources when the margin falls below a predefined threshold or if the QoS requirement is not fulfilled.
  • the AN 510 may be referred to as the network.
  • the network 510 (e.g., the gNB 200) provides a configuration (e.g., in the steps 304 and 404) for the UE 100 to measure generic QoS related information (i.e., the QoS parameters), e.g. PSDB, PSER, minimum and/or maximum and/or average PDU set queued time, or PDU set dropping ratio.
  • the configuration may be compound of one or more of the following elements: measured parameter, one or more thresholds for the said parameter, measurement window, measurement periodicity, QFI, DRB. If the network provides the QFI or DRB, it limits the measurements to the PDU sets matching the QFI and/or DRB.
  • the UE 100 reporting in the steps 310 and 410 may be event-based, e.g. when the measured value is above or below the configured threshold, periodic-based e.g. measured value is reported periodically, or on-request e.g. the network requests the UE to report the last measured value or to start a measurement and report it to the network.
  • the network may be able to configure the one or more reporting methods the UE 100 should follow.
  • the following reporting options are possible:
  • a first option includes an event trigger: the report message 506 only contains the measured value which triggered the report in the corresponding DRB, QFI, and/or PSI. The report message 506 may then indicate to which DRB, QFI, and/or PSI corresponds (e.g., fails to meet a predefined criterium). Alternatively, the UE 100 reports 310 the measured value which triggers the report message 506 and the value of the parameter for other DRBs, QFIs, and/or PSIs. Alternatively, the UE 100 may report all measured values for the configured DRBs, QFIs, and/or PSIs. A second option includes a periodic trigger: the UE 100 may report all measured values for the configured QoS parameters, e.g. DRBs, QFIs, and/or PSIs.
  • the configured QoS parameters e.g. DRBs, QFIs, and/or PSIs.
  • a third option includes an on-demand reporting: the UE 100 reports 310 the measurements 306 of the one or more requested QoS parameters.
  • the report message 506 may include values for the DRBs, QF Is, and/or PSIs provided in the configuration or in the "on-demand" measurement request sent by the network to the UE 100.
  • the UE reports the measured parameter value e.g. UL PSER status inside a SDAP/PDCP control PDU.
  • Report may carry measured results for one or multiple QoS flows (QFIs) and/or DRBs and/or PSI levels. Measured results could also be carried in a PDCP Control PDU.
  • QFIs QoS flows
  • DRBs DRBs and/or PSI levels. Measured results could also be carried in a PDCP Control PDU.
  • the UE 100 is configured through RRC to either report periodically with time interval X or a-periodically.
  • the PDCP or SDAP layer triggers a UL PSER report when requested by gNB through a SDAP or PDCP control PDU.
  • the UE can be configured to either continuously measure the UL PSER status or only start the measurement upon request from an SDAP or PDCP control PDU.
  • the gNB may be unaware of this capability.
  • the UE may trigger the sending of a control PDU indicating to gNB that it supports a status report from respective layer.
  • the gNB may probe the UE for this capability. In this case it is the gNB that sends a control PDU to the UE for which the UE may respond with its own control PDU indicating its support or not. In case it does not support status reporting, the UE can also ignore this control PDU.
  • This mechanism will also enable the UE to update its capability dynamically, in case the traffic pattern and/or requirements of the service has changed.
  • Fig. 12 schematically illustrates a signaling diagram resulting from devices 100 and 200 performing the methods 300 and 400 according to a seventh embodiment.
  • the signaling diagram illustrates the interplay between various components during the execution of a method for handling a Packet Data Unit (PDU) set within a telecommunications network.
  • the signaling diagram illustrates the interaction between a wireless device 100 and a network node 200 of an access network AN, along with the core network 520.
  • the process initiates with the wireless device 100 transmitting a capability message 502 to the network node 200 in the step 302 or 402, which indicates the capabilities of the wireless device 100 in measuring and reporting QoS parameters for the PDU set in the uplink direction toward the AN 510, e.g., its serving network node 200 (illustrated as a gNB).
  • a gNB serving network node 200
  • the network node 200 may configure the wireless device 100 by sending a configuration message 504, which provides specific instructions for QoS measurements of the PDU set, according to the step 404 or 304.
  • the wireless device 100 then proceeds to measure 306 the QoS parameters, e.g. at various intervals denoted as a loop and optionally assess the UL QoS in the step 308, with the potential to engage multiple QoS measurements.
  • the wireless device 100 reports 310 the result of the measurement 306 or the assessment 308, e.g. according to at least one of the alternatives (labeled "alt") in the box. For example, the wireless device 100 evaluates whether the measured PDU set matches preset criteria, potentially triggering a report. If the determination 308 results in the need to report, the wireless device 100 sends 310 a report message 506 back to the network node 200.
  • the report message 506 may be event-based, periodic, or on-demand, as indicated by the multiple exit points from the sending 310 to the network node 200.
  • the network node 200 is poised to respond by either waiting 410 for periodical QoS measurement reports from the wireless device or by sending a request for QoS measurement to the wireless device, depicted by the vertical flow of communication from and to the network node 200 (e.g., gNB).
  • the network node 200 receives the report message 506 indicative of the QoS measurement results, it takes suitable action by updating its configuration, scheduling, or general resource allocation for the wireless device to optimize the QoS for the PDU set according to the step 412.
  • the measurements 306 at the UE 100 for the entire PDU set may (e.g., partly) be based on lower layer measurements involving indirect QoS parameters such as noise or a signal-to-noise ratio (SNR), or interference or a signal-to- interference-and-noise ratio (SINR).
  • Fig. 13 shows a schematic block diagram for an embodiment of the device 100.
  • the device 100 comprises processing circuitry, e.g., one or more processors 1304 for performing the method 300 and memory 1306 coupled to the processors 1304.
  • the memory 1306 may be encoded with instructions that implement at least one of the modules 106 and 110.
  • the one or more processors 1304 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 100, such as the memory 1306, wireless device functionality.
  • the one or more processors 1304 may execute instructions stored in the memory 1306.
  • Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein.
  • the expression "the device being operative to perform an action” may denote the device 100 being configured to perform the action.
  • the device 100 may be embodied by a wireless device 1300, e.g., functioning as a radio device or a transmitting UE.
  • the wireless device 1300 comprises a wireless (e.g., radio) interface 1302 coupled to the device 100 for radio communication with one or more receiving stations, e.g., functioning as a receiving base station or a receiving UE.
  • Fig. 14 shows a schematic block diagram for an embodiment of the device 200.
  • the device 200 comprises processing circuitry, e.g., one or more processors 1404 for performing the method 400 and memory 1406 coupled to the processors 1404.
  • processing circuitry e.g., one or more processors 1404 for performing the method 400
  • memory 1406 coupled to the processors 1404.
  • the memory 1406 may be encoded with instructions that implement at least one of the modules 210 and 212.
  • the one or more processors 1404 may be a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, microcode and/or encoded logic operable to provide, either alone or in conjunction with other components of the device 200, such as the memory 1406, network node functionality.
  • the one or more processors 1404 may execute instructions stored in the memory 1406.
  • Such functionality may include providing various features and steps discussed herein, including any of the benefits disclosed herein.
  • the expression "the device being operative to perform an action” may denote the device 200 being configured to perform the action.
  • the device 200 may be embodied by a network node 1400, e.g., functioning as a gNB or a receiving UE.
  • the network node 1400 comprises a wireless (e.g., radio) interface 1402 coupled to the device 200 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or a transmitting UE.
  • a wireless (e.g., radio) interface 1402 coupled to the device 200 for radio communication with one or more transmitting stations, e.g., functioning as a transmitting base station or a transmitting UE.
  • a communication system 1500 includes a telecommunication network 1510, such as a 3GPP-type cellular network, which comprises an access network 1511, such as a radio access network, and a core network 1514.
  • the access network 1511 comprises a plurality of base stations 1512a, 1512b, 1512c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1513a, 1513b, 1513c.
  • Each base station 1512a, 1512b, 1512c is connectable to the core network 1514 over a wired or wireless connection 1515.
  • a first user equipment (UE) 1591 located in coverage area 1513c is configured to wirelessly connect to, or be paged by, the corresponding base station 1512c.
  • a second UE 1592 in coverage area 1513a is wirelessly connectable to the corresponding base station 1512a. While a plurality of UEs 1591, 1592 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 1512.
  • any of the base stations 1512 may embody the device 200.
  • any of the UEs 1591 and 1592 may embody the device 100.
  • the telecommunication network 1510 is itself connected to a host computer 1530, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm.
  • the host computer 1530 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider.
  • the connections 1521, 1522 between the telecommunication network 1510 and the host computer 1530 may extend directly from the core network 1514 to the host computer 1530 or may go via an optional intermediate network 1520.
  • the intermediate network 1520 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 1520, if any, may be a backbone network or the Internet; in particular, the intermediate network 1520 may comprise two or more sub-networks (not shown).
  • the communication system 1500 of Fig. 15 as a whole enables connectivity between one of the connected UEs 1591, 1592 and the host computer 1530.
  • the connectivity may be described as an over-the-top (OTT) connection 1550.
  • the host computer 1530 and the connected UEs 1591, 1592 are configured to communicate data and/or signaling via the OTT connection 1550, using the access network 1511, the core network 1514, any intermediate network 1520 and possible further infrastructure (not shown) as intermediaries.
  • the OTT connection 1550 may be transparent in the sense that the participating communication devices through which the OTT connection 1550 passes are unaware of routing of uplink and downlink communications.
  • a base station 1512 need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 1530 to be forwarded (e.g., handed over) to a connected UE 1591. Similarly, the base station 1512 need not be aware of the future routing of an outgoing uplink communication originating from the UE 1591 towards the host computer 1530.
  • the performance or range of the OTT connection 1550 can be improved, e.g., in terms of increased throughput and/or reduced latency.
  • the host computer 1530 may indicate to the RAN 510 or the radio device 100 (e.g. a relay radio device or a remote radio device), optionally on an application layer, the QoS of the traffic.
  • a host computer 1610 comprises hardware 1615 including a communication interface 1616 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 1600.
  • the host computer 1610 further comprises processing circuitry 1618, which may have storage and/or processing capabilities.
  • the processing circuitry 1618 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the host computer 1610 further comprises software 1611, which is stored in or accessible by the host computer 1610 and executable by the processing circuitry 1618.
  • the software 1611 includes a host application 1612.
  • the host application 1612 may be operable to provide a service to a remote user, such as a UE 1630 connecting via an OTT connection 1650 terminating at the UE 1630 and the host computer 1610.
  • the host application 1612 may provide user data, which is transmitted using the OTT connection 1650.
  • the user data may depend on the location of the UE 1630.
  • the user data may comprise auxiliary information or precision advertisements (also: ads) delivered to the UE 1630.
  • the location may be reported by the UE 1630 to the host computer, e.g., using the OTT connection 1650, and/or by the base station 1620, e.g., using a connection 1660.
  • the communication system 1600 further includes a base station 1620 provided in a telecommunication system and comprising hardware 1625 enabling it to communicate with the host computer 1610 and with the UE 1630.
  • the hardware 1625 may include a communication interface 1626 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 1600, as well as a radio interface 1627 for setting up and maintaining at least a wireless connection 1670 with a UE 1630 located in a coverage area (not shown in Fig. 16) served by the base station 1620.
  • the communication interface 1626 may be configured to facilitate a connection 1660 to the host computer 1610.
  • the connection 1660 may be direct, or it may pass through a core network (not shown in Fig.
  • the hardware 1625 of the base station 1620 further includes processing circuitry 1628, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the base station 1620 further has software 1621 stored internally or accessible via an external connection.
  • the communication system 1600 further includes the UE 1630 already referred to.
  • Its hardware 1635 may include a radio interface 1637 configured to set up and maintain a wireless connection 1670 with a base station serving a coverage area in which the UE 1630 is currently located.
  • the hardware 1635 of the UE 1630 further includes processing circuitry 1638, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions.
  • the UE 1630 further comprises software 1631, which is stored in or accessible by the UE 1630 and executable by the processing circuitry 1638.
  • the software 1631 includes a client application 1632.
  • the client application 1632 may be operable to provide a service to a human or non-human user via the UE 1630, with the support of the host computer 1610.
  • an executing host application 1612 may communicate with the executing client application 1632 via the OTT connection 1650 terminating at the UE 1630 and the host computer 1610.
  • the client application 1632 may receive request data from the host application 1612 and provide user data in response to the request data.
  • the OTT connection 1650 may transfer both the request data and the user data.
  • the client application 1632 may interact with the user to generate the user data that it provides.
  • the host computer 1610, base station 1620 and UE 1630 illustrated in Fig. 16 may be identical to the host computer 1530, one of the base stations 1512a, 1512b, 1512c and one of the UEs 1591, 1592 of Fig. 15, respectively.
  • the inner workings of these entities may be as shown in Fig. 16, and, independently, the surrounding network topology may be that of Fig. 15.
  • the OTT connection 1650 has been drawn abstractly to illustrate the communication between the host computer 1610 and the UE 1630 via the base station 1620, without explicit reference to any intermediary devices and the precise routing of messages via these devices.
  • Network infrastructure may determine the routing, which it may be configured to hide from the UE 1630 or from the service provider operating the host computer 1610, or both. While the OTT connection 1650 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).
  • the wireless connection 1670 between the UE 1630 and the base station 1620 is in accordance with the teachings of the embodiments described throughout this disclosure.
  • One or more of the various embodiments improve the performance of OTT services provided to the UE 1630 using the OTT connection 1650, in which the wireless connection 1670 forms the last segment. More precisely, the teachings of these embodiments may reduce the latency and improve the data rate and thereby provide benefits such as better responsiveness and improved QoS.
  • a measurement procedure may be provided for the purpose of monitoring data rate, latency, QoS and other factors on which the one or more embodiments improve.
  • the measurement procedure and/or the network functionality for reconfiguring the OTT connection 1650 may be implemented in the software 1611 of the host computer 1610 or in the software 1631 of the UE 1630, or both.
  • sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 1650 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 1611, 1631 may compute or estimate the monitored quantities.
  • the reconfiguring of the OTT connection 1650 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 1620, and it may be unknown or imperceptible to the base station 1620.
  • measurements may involve proprietary UE signaling facilitating the host computer's 1610 measurements of throughput, propagation times, latency and the like.
  • the measurements may be implemented in that the software 1611, 1631 causes messages to be transmitted, in particular empty or "dummy" messages, using the OTT connection 1650 while it monitors propagation times, errors etc.
  • Fig. 17 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 17 will be included in this paragraph.
  • the host computer provides user data.
  • the host computer provides the user data by executing a host application.
  • the host computer initiates a transmission carrying the user data to the UE.
  • Fig. 18 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment.
  • the communication system includes a host computer, a base station and a UE which may be those described with reference to Figs. 15 and 16. For simplicity of the present disclosure, only drawing references to Fig. 18 will be included in this paragraph.
  • the host computer provides user data.
  • the host computer provides the user data by executing a host application.
  • the host computer initiates a transmission carrying the user data to the UE.
  • the transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure.
  • the UE receives the user data carried in the transmission.
  • the conventional network cannot or can hardly know the QoS impacts of configuring UL PDU Set handling in the UE.
  • at least some embodiments of the technique enable the network to make better configurations (i.e., scheduling in the broadest technical sense), e.g. of the UL PDU Set handling features and/or to make better scheduling decisions to improve the performance with respect to QoS requirements.
  • Wireless device for handling PDU sets, e.g. user equipment (UE)
  • UE user equipment
  • Network node for handling PDU sets e.g. gNB
  • mapping step e.g. mapping step
  • Report message e.g. indicative of PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), or PDU Set Importance (PSI)
  • PSDB PDU Set Delay Budget
  • PSER PDU Set Error Rate
  • PSI PDU Set Importance
  • CN e.g. 5G Core Network (5GC)
  • 5GC 5G Core Network
  • DRB Data Radio Bearer
  • SDAP Service Data Adaptation Protocol
  • QoS flow e.g. QoS flow identifier (QFI)
  • PDU set Packet data unit set
  • Client application e.g. generating the PDU set, e.g. extended Reality (XR)
  • XR extended Reality

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé (300) mis en œuvre par un dispositif sans fil, WD (100; 1300; 1591; 1592; 1630), connecté ou pouvant être connecté sans fil à un réseau d'accès, AN (510). Le procédé (300) comprend ou déclenche : la mesure (306), au niveau du WD (100; 1300; 1591; 1592; 1630), d'au moins un paramètre de qualité de service, QoS, d'un ensemble d'unités de données en paquets, ensemble PDU (750), dans une liaison montante vers l'AN (510); et la transmission (310), à l'AN (510), d'un message de rapport (506) indiquant un résultat de la mesure (306).
PCT/EP2025/051996 2024-01-31 2025-01-27 Technique de gestion d'ensembles de pdu dans ul Pending WO2025162882A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463627115P 2024-01-31 2024-01-31
US63/627,115 2024-01-31

Publications (1)

Publication Number Publication Date
WO2025162882A1 true WO2025162882A1 (fr) 2025-08-07

Family

ID=94386202

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2025/051996 Pending WO2025162882A1 (fr) 2024-01-31 2025-01-27 Technique de gestion d'ensembles de pdu dans ul

Country Status (1)

Country Link
WO (1) WO2025162882A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023211069A1 (fr) * 2022-04-27 2023-11-02 삼성전자 주식회사 Procédé et dispositif de traitement d'un trafic multimodal xr dans un système de communication sans fil

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023211069A1 (fr) * 2022-04-27 2023-11-02 삼성전자 주식회사 Procédé et dispositif de traitement d'un trafic multimodal xr dans un système de communication sans fil

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JUHA KORHONEN ET AL: "RAN2#123 Meeting Report", vol. RAN WG2, no. Xiamen, CN; 20231009 - 20231013, 8 October 2023 (2023-10-08), XP052528410, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_123bis/Docs/R2-2309401.zip R2-2309401.docx> [retrieved on 20231008] *
YACINE EL KOLLI ET AL: "PSER measurement and feedback", vol. RAN WG2, no. Toulouse, FR; 20230821 - 20230825, 7 August 2023 (2023-08-07), XP052442884, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_123/Docs/R2-2307164.zip R2-2307164 PSER measurement and feedback.docx> [retrieved on 20230807] *

Similar Documents

Publication Publication Date Title
EP3603220B1 (fr) Compteurs d&#39;inactivité de flux qos
US20230127924A1 (en) ProSe REMOTE AND RELAYING ENTITY QoS MANAGEMENT
US10827396B2 (en) Uplink data splitting
US9426689B2 (en) Control and data plane solutions for carrier-aggregation based WLAN offload
EP2965558B1 (fr) Envoi d&#39;informations de débit de données à un noeud de réseau d&#39;accès sans fil
EP2647175B1 (fr) Procédé pour faciliter une communication entre des dispositifs
WO2020030165A1 (fr) Procédé et appareil de transmission de données, et procédé et appareil de commutation de service
US20130279335A1 (en) Apparatus and methods for improved packet flow mobility
CN106717055A (zh) 用于lwa的延迟测量方法和设备
EP3804230B1 (fr) Technique de duplication de paquets
WO2022084483A1 (fr) Technique de gestion d&#39;un temps de survie dans une communication à durée de vie critique
US20240214867A1 (en) Data transmission method and apparatus
WO2025163106A1 (fr) Technique de gestion d&#39;ensembles de pdu multimodaux
WO2025168664A1 (fr) Technique de gestion d&#39;ensembles de pdu multimodales
EP4298773A1 (fr) Gestion adaptative de transfert de paquets de données
WO2024209095A1 (fr) Abandon d&#39;ensemble d&#39;unités de données de protocole (pdu) sur la base d&#39;une signalisation d&#39;importance d&#39;ensemble de pdu (psi), configuration et comportement d&#39;équipement utilisateur (ue)
WO2025162882A1 (fr) Technique de gestion d&#39;ensembles de pdu dans ul
CN117121556A (zh) 用于时间敏感联网的切换技术
WO2024184495A1 (fr) Technique de configuration d&#39;état de tampon

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25701979

Country of ref document: EP

Kind code of ref document: A1