Qos flow status reporting method and communication device

Abstract

The application discloses a QoS flow state reporting method and a communication device, and relates to the communication field. The method is applied to a terminal device. The method comprises the following steps: sending data to a network device through a QoS flow; and sending a statistical summary. The statistical summary is used for uplink rate control of the QoS flow. The statistical summary comprises first indication information and normalized QoS scores of at least one QoS flow. The first indication information is used for indicating whether the normalized QoS scores of the respective QoS flows are contained in the statistical summary. The normalized QoS scores of the QoS flow are obtained from at least one of the following: a normalized Ath percentile of a transmission delay of the QoS flow within a window, a normalized packet loss rate and a normalized delay jitter.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a QoS flow status reporting method and communication device. Background Technology

[0002] In extended reality (XR) service scenarios of 5G-Advanced networks, a single terminal device often carries multiple data streams with different quality of service (QoS) requirements simultaneously. To ensure a low-latency, high-reliability immersive experience for users, network devices need to control the uplink rate of the QoS streams from the terminal device.

[0003] The existing uplink rate control relies solely on the priority of the 5G QoS identifier (5QI) of the QoS flow. Since the 5QI priority remains unchanged, the uplink rate of the QoS flow also remains basically unchanged, and it cannot adapt to changes in the service status of the QoS flow. Summary of the Invention

[0004] This application provides a QoS stream status reporting method and communication device to enable terminal devices to report the service status of QoS streams, thereby improving the user experience of latency-sensitive services such as XR.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] Firstly, a QoS flow status reporting method is provided, comprising: a terminal device sending data to a network device via a QoS flow; the terminal device sending a statistical summary to the network device, the statistical summary being used for uplink rate control of the QoS flow; the statistical summary including first indication information and at least one normalized QoS score of the QoS flow; the first indication information being used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary; the normalized QoS score of the QoS flow being obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS flow within the window, the normalized packet loss rate, and the normalized delay jitter.

[0007] The QoS flow status reporting method provided in this application reports a statistical summary containing a normalized QoS score. The normalized QoS score is obtained by comprehensively considering multiple QoS indicators (such as percentile of transmission delay, packet loss rate, and delay jitter). This enables network devices to perform uplink rate control based on dynamic and multi-dimensional QoS indicators, thereby overcoming the scheduling rigidity problem caused by relying solely on static 5QI priority for uplink rate control in the prior art. This achieves timely reporting of the service status of QoS flows and improves the user experience of latency-sensitive services such as XR.

[0008] It should be noted that this QoS flow status reporting method can be applied to any of the following scenarios:

[0009] XR and Metaverse Scenarios: In immersive services such as virtual reality and augmented reality, terminal devices need to simultaneously process high-bandwidth video streams and low-latency control streams. Traditional static scheduling mechanisms cannot perceive the real-time quality differences between streams, easily leading to screen stuttering or operational malfunctions. This solution dynamically reports the normalized QoS scores of each QoS stream, enabling network devices to distinguish and prioritize critical QoS streams experiencing experience degradation. This achieves coordinated scheduling and anti-motion sickness optimization for multiple QoS stream services, ensuring a smooth and stable immersive experience.

[0010] Industrial Internet Scenarios: In ultra-reliable, low-latency communication scenarios such as remote control and machine collaboration, networks need to have millisecond-level perception and response capabilities for latency and packet loss. This solution, by reporting latency percentiles and packet loss rates, enables the network to provide early warnings of reliability risks, reserve deterministic resources for critical command flows, or trigger redundant protection, thus meeting the stringent requirements of industrial control for determinism and reliability.

[0011] In intelligent connected vehicle scenarios, the QoS requirements for safety messages and information service messages differ significantly in vehicle-to-network and vehicle-to-vehicle communications. This solution supports terminal devices in reporting real-time quality scores for different QoS streams, enabling network devices to prioritize the transmission of emergency safety messages and identify regional channel problems when multiple vehicle traffic streams degrade simultaneously, thus achieving intelligent collaborative scheduling for both traffic safety and efficiency.

[0012] Cloud gaming and real-time interactive scenarios: In cloud-rendered and real-time interactive services, the end-to-end latency from user interaction to screen response directly impacts the user experience. This solution feeds back the latency and jitter scores perceived by the terminal device to the network device in real time. The network device can then dynamically adjust routing and scheduling strategies based on this information and collaborate with the cloud server to achieve adaptive bitrate, forming a closed loop that integrates "cloud-network-terminal" to ensure a seamless user experience.

[0013] Network slicing and industry-specific private network scenarios: In network slicing services targeting vertical industries, real-time monitoring of service experience within slices is required to ensure SLA compliance. The normalized QoS score provided in this solution serves as a lightweight micro-indicator of slice performance, supporting network devices in dynamically allocating and elastically guaranteeing slice resources, and enabling intelligent resource arbitration and service quality commitments across slices.

[0014] In one possible implementation, at least one QoS flow is a QoS flow selected by the terminal device from a plurality of candidate QoS flows according to weights, wherein the weights of the candidate QoS flows are obtained from at least one of the following: the normalized 5QI value of the candidate QoS flow, the normalized QoS score, and the normalized aging value.

[0015] By introducing a weighted QoS flow selection mechanism, the normalized 5QI value, normalized QoS score, and normalized aging value are comprehensively incorporated into the weight calculation, enabling terminal devices to intelligently filter out the QoS flows that need to be reported. Under limited signaling resources, the QoS flows that have the greatest impact on network device scheduling decisions are prioritized for reporting, thereby improving the decision value of the reported information and the efficiency of resource utilization.

[0016] In one possible implementation, a candidate QoS flow satisfies at least one of the following: data is waiting to be sent in a buffer, it is in a rate-adaptive state, it is configured as a monitoring target by a network device, and it has data to be sent within a window.

[0017] By clearly defining the conditions that candidate QoS flows must meet, the reporting mechanism is ensured to target only active QoS flows with adjustment needs, avoiding invalid reporting of silent or fixed-rate services, further reducing signaling overhead and improving the overall operating efficiency of the system.

[0018] In one possible implementation, the reporting method of statistical summary includes at least one of the following: periodic reporting with a first period, and reporting triggered by a first event; wherein the first event includes at least one of the following: the normalized QoS score of any QoS flow changes from less than a first score threshold to greater than a second score threshold, and the second score threshold is greater than the first score threshold; the normalized aging value of any QoS flow is greater than or equal to the aging threshold; a first request is received, the first request being used to instruct the terminal device to report the statistical summary.

[0019] By supporting a combination of periodic reporting and event-triggered reporting, and defining specific event triggering conditions, the reporting mechanism can provide stable quality situational awareness and respond quickly to sudden deterioration events, achieving an optimal balance between signaling overhead, response timeliness, and network proactivity.

[0020] In one possible implementation, the method further includes: the terminal device sending detailed statistics of the QoS stream, the detailed statistics including second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0021] By introducing a detailed statistical data reporting mechanism, more granular and richer raw data is provided to network devices, supporting advanced operation and maintenance functions such as root cause analysis, AI model training, and policy optimization on the network side. This enables closed-loop management from real-time control to long-term optimization, enhancing the system's diagnostics and intelligence.

[0022] In one possible implementation, the reporting method for detailed statistical data includes at least one of the following: periodic reporting with a second period, and reporting triggered by a second event; wherein the second period is longer than the first period; the second event includes at least one of the following: the rate of change of the normalized QoS score of any QoS flow is greater than or equal to a rate of change threshold; the normalized QoS score set of multiple QoS flows changes from less than a third score threshold to greater than a fourth score threshold, and the fourth score threshold is greater than the third score threshold; a second request is received, the second request being used to instruct the terminal device to report detailed statistical data of the QoS flow.

[0023] By setting longer reporting cycles and more advanced event triggering conditions for detailed statistical data, we ensure that large amounts of detailed information are reported only when necessary, avoiding excessive overhead from continuous reporting. At the same time, the network is able to identify systemic risks and rapid degradation scenarios, improving the accuracy and proactivity of network operation and maintenance.

[0024] In one possible implementation, the first indication information is a bitmap, where each bit corresponds to a QoS stream, used to indicate whether the normalized QoS score of the corresponding QoS stream is included in the statistical summary.

[0025] By using a bitmap as the primary indication information, the reporting status of each QoS stream is clearly indicated with extremely low bit overhead. The structure is simple and the parsing is efficient, making it particularly suitable for carrying in resource-constrained signaling such as MAC CE. This helps reduce the overhead of uplink control signaling and improve the system's spectrum efficiency.

[0026] In one possible implementation, the normalized QoS score is a quantized value that is quantized to the risk level.

[0027] By quantizing the normalized QoS score, continuous values ​​are mapped to finite discrete levels, significantly reducing the number of bits required for each score value in the statistical summary, further reducing signaling overhead. At the same time, the quantized levels can directly correspond to differentiated scheduling strategies, facilitating rapid decision-making by network devices and improving the real-time performance and scalability of the system.

[0028] Secondly, a QoS flow status reporting method is provided, comprising: a network device receiving data through a QoS flow; the network device receiving a statistical summary, the statistical summary being used for uplink rate control of the QoS flow, the statistical summary including first indication information and at least one normalized QoS score of the QoS flow, the first indication information being used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary, the normalized QoS score of the QoS flow being obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS flow within the window, the normalized packet loss rate, and the normalized delay jitter.

[0029] In one possible implementation, the method further includes: receiving detailed statistics of the QoS stream, the detailed statistics including second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0030] In one possible implementation, the first indication information is a bitmap, where each bit corresponds to a QoS stream, used to indicate whether the normalized QoS score of the corresponding QoS stream is included in the statistical summary.

[0031] Thirdly, a communication device is provided, comprising a processing module and a communication module. The communication module is used to send data to a network device via a QoS flow; and to send a statistical summary to the network device, the statistical summary being used for uplink rate control of the QoS flow. The statistical summary includes first indication information and a normalized QoS score for at least one QoS flow. The first indication information is used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary. The normalized QoS score of the QoS flow is obtained from at least one of the following: the normalized A-th percentile of the transmission delay of the QoS flow within a window, the normalized packet loss rate, and the normalized delay jitter.

[0032] In one possible implementation, the communication module is used to send detailed statistics of the QoS stream, which includes a second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0033] Fourthly, a communication device is provided, comprising a processing module and a communication module. The communication module is used to receive data via a QoS stream; receive a statistical summary, the statistical summary being used for uplink rate control of the QoS stream, the statistical summary including first indication information and a normalized QoS score for at least one QoS stream, the first indication information being used to indicate whether the normalized QoS score of each QoS stream is included in the statistical summary, the normalized QoS score of the QoS stream being obtained from at least one of the following: the normalized A-th percentile of the transmission delay of the QoS stream within a window, the normalized packet loss rate, and the normalized delay jitter.

[0034] In one possible implementation, the communication module is used to receive detailed statistics of the QoS stream, which includes a second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0035] Fifthly, a communication device is provided, including a processor. The processor is coupled to a memory and can be used to execute instructions or data in the memory to implement the method in any possible implementation of the first aspect described above. Optionally, the communication device further includes a memory. Optionally, the communication device further includes a communication interface, and the processor is coupled to the communication interface.

[0036] In one implementation, the communication interface may be a transceiver, or an input / output interface.

[0037] In another implementation, the communication device is a chip configured in the first device. When the communication device is a chip configured in the first device, the communication interface can be an input / output interface.

[0038] In a sixth aspect, a processor is provided, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute a method in any possible implementation of any of the preceding aspects.

[0039] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0040] In a seventh aspect, a communication device is provided, including a processor and a memory. The processor is used to read instructions stored in the memory and to receive signals via a receiver and transmit signals via a transmitter to execute the method in any possible implementation of any of the above aspects.

[0041] Optionally, the processor may be one or more, and the memory may be one or more.

[0042] Eighthly, a computer program product is provided, the computer program product comprising: a computer program (also referred to as code or instructions) that, when the computer program is run, causes a computer to perform a method in any possible implementation of any of the above aspects.

[0043] In a ninth aspect, a computer-readable storage medium is provided that stores a computer program (also referred to as code or instructions) that, when executed on a computer, causes the computer to perform the methods in any possible implementation of any of the preceding aspects.

[0044] In a tenth aspect, embodiments of this application provide a chip system including one or more processors for calling and executing instructions stored in memory, causing the methods in any of the above aspects or possible implementations to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0045] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0046] Eleventhly, a communication system is provided, including the aforementioned terminal device and network device. Optionally, the communication system may further include other devices that communicate with the terminal device or network device.

[0047] The technical effects of the second to eleventh aspects refer to the technical effects of the first aspect and any of its embodiments, and will not be repeated here. Attached Figure Description

[0048] Figure 1 This application provides a schematic diagram of the architecture of a communication system.

[0049] Figure 2 A flowchart illustrating a QoS flow status reporting method provided in an embodiment of this application;

[0050] Figure 3 A flowchart illustrating another QoS flow status reporting method provided in this application embodiment;

[0051] Figure 4 A schematic diagram of functional modules in a terminal device provided in an embodiment of this application;

[0052] Figure 5 A flowchart illustrating another QoS flow status reporting method provided in this application embodiment;

[0053] Figure 6 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0054] Figure 7 This is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0055] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0056] First, some concepts involved in this application will be described.

[0057] The terms "first" and "second" used in the embodiments of this application are only used to distinguish features of the same type and should not be construed as indicating relative importance, quantity, order, etc.

[0058] The terms "exemplary" or "for example" used in the embodiments of this application are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0059] The names of the various thresholds involved in the embodiments of this application are only for ease of understanding and to avoid confusion. The embodiments of this application do not limit the naming of the various thresholds.

[0060] The technical solutions provided in this application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink communication systems, Universal Mobile Telecommunication System (UMTS), Worldwide Interoperability for Microwave Access (WiMAX) communication systems, non-terrestrial network (NTN) communication systems, 5th generation (5G) mobile communication systems, new radio access technology (NR), future communication systems, and 5G Advanced communication systems. Among these, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networking. The technical solutions provided in this application can also be applied to future communication systems. This application does not limit the scope of these applications. The terms "system" and "network" in the embodiments of this application are often used interchangeably, and the described technologies can be used in the systems and radio technologies mentioned above, as well as in other systems and radio technologies.

[0061] Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application. The communication system 100 may include network devices, such as... Figure 1 At least one network device 110 is shown. The communication system 100 may also include terminal devices, such as... Figure 1 The terminal device 120 shown. The network device 110 and the terminal device 120 can communicate with each other via a wireless link.

[0062] Figure 1 An exemplary network device 110 and a terminal device 120 are shown. Optionally, the communication system 100 may also include multiple network devices 110 and multiple terminal devices 120.

[0063] The network equipment in this application can be network-side equipment such as access network equipment and core network equipment. Network equipment is sometimes also called an access node. Access network equipment has wireless transceiver capabilities for communicating with terminals. Access network equipment includes, but is not limited to, base stations, evolved NodeBs (eNodeBs), transmission reception points (TRPs) in the aforementioned communication systems, next-generation NodeBs (gNBs) in 5G mobile communication systems, access network equipment or modules of access network equipment in open RAN (ORAN) systems, satellites in NTN communication systems, base stations in future mobile communication systems, or access nodes in Wi-Fi systems. Access network equipment can also be modules or units capable of implementing some of the functions of a base station. Access network equipment can be a macro base station, micro base station, indoor station, relay node, donor node, or a wireless controller in a cloud radioaccess network (CRAN) scenario. Optionally, access network equipment can also be a server, wearable device, or vehicle-mounted equipment, etc. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). Multiple access network devices in a communication system can be base stations of the same type or different types. Base stations can communicate with terminals directly or via relay stations. Terminals can communicate with multiple base stations using different access technologies. The embodiments of this application do not limit the specific technology or device form used in the access network equipment. In this application, the access network equipment is referred to as a network device.

[0064] In this application, the means for implementing the functions of a network device can be a network device itself, or a means capable of supporting the network device in implementing those functions, such as a processor, circuit, chip, or chip system. This means can be installed in or connected to the network device. In the technical solutions provided in this application, the example of a network device being used to implement the functions of a network device is used to describe the technical solutions provided in this application.

[0065] The terminal device in this application can be a terminal device capable of wireless communication. The terminal device can be a device that provides voice and / or data connectivity to a user, a handheld device with wireless connectivity, or other processing devices connected to a wireless modem. For example, the terminal device can communicate with one or more core networks or the Internet via a radio access network (RAN). The terminal device can also be referred to as a terminal, user equipment (UE), mobile station, mobile terminal, etc. Terminal devices can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IoT), ultra-reliable low-latency communication (URLLC), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, or satellite communication, etc. The terminal can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, wearable device, vehicle, aircraft (such as drone, helicopter, airplane), hot air balloon, ship, robot, robotic arm, or smart home device, etc. The embodiments of this application do not limit the form of the terminal device.

[0066] In this application, the apparatus for implementing the functions of a terminal device can be the terminal device itself, or any apparatus capable of supporting the terminal device in implementing those functions, such as a processor, circuit, chip, or chip system. This apparatus can be installed in the terminal device or connected to and used with the terminal device. In the technical solutions provided in this application, the example of a terminal device being used to implement the functions of a terminal device is used to describe the technical solutions provided in this application.

[0067] Network devices and terminal devices can be fixed or mobile. They can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can be deployed in the air on airplanes, balloons, and artificial satellites. This application does not limit the application scenarios of the network devices and terminal devices. Network devices and terminal devices can be deployed in the same or different scenarios; for example, network devices and terminal devices can be deployed simultaneously on land; or, network devices can be deployed on land and terminal devices can be deployed on water, etc., and so on.

[0068] In practical applications, multiple network devices can collaborate to assist terminal devices in achieving wireless access, with different network devices each implementing a portion of the base station's functions. For example, network devices can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio frequency equipment or radio frequency units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0069] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called O-CU (Open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules. CU (or CU-CP and CU-UP), DU, and RU can implement different protocol layer functions.

[0070] To facilitate understanding of the embodiments of this application, the terminology used in this application is first briefly explained. Optionally, the explanation of some terms can also refer to the explanations in the 3rd Generation Partnership Project (3GPP) standard protocol. It should be understood that the technical terms in this application are only examples and not limitations. For example, as technology evolves, technical terms may also change; where the technical meaning remains the same, other technical terms should also apply to this application.

[0071] Extended reality (XR) encompasses all immersive technologies that blend real and virtual environments, primarily including:

[0072] Virtual reality (VR): Creates a completely virtual, closed digital environment for users. Users are fully immersed in a computer-generated world through devices such as headsets, for example, VR shooting games.

[0073] Augmented reality (AR) overlays digital information or virtual objects onto the real world. Users see a combination of real-world environment and virtual elements; for example, virtual characters or pets can be displayed in the real world.

[0074] Mixed reality (MR) is a more advanced form of AR. Virtual objects not only overlay reality, but can also interact and respond to the real world in real time. For example, virtual objects can be occluded by a real desktop.

[0075] Quality of Service (QoS) Flow: QoS flow is the core granularity of 5G network QoS management. It is the logical bearer channel for data packets with the same QoS requirements between terminal devices and the data network. QoS flow is not a physical or link layer channel, but rather a logical bearer channel used by the core network and radio access network to identify and guarantee a type of QoS when they work together.

[0076] 5G QoS Identifier (5QI): Each QoS flow is associated with a 5G QoS Identifier (5QI). 5QI is a standardized numerical index (e.g., 1 for voice calls, 80 for VR services) that predefines a set of QoS parameters, including: scheduling priority, packet delay budget (the maximum tolerable delay for data packets), packet error rate (the maximum tolerable packet loss rate), and default maximum data burst size (suitable for guaranteed bit rate services).

[0077] Characteristics of QoS streams in XR service scenarios: An XR device (such as a VR headset) typically establishes multiple concurrent QoS streams to carry different types of data. For example: QoS stream A is a high-fidelity video stream, requiring high bandwidth and medium to low latency (5QI may be 80 / 82). QoS stream B is control commands or attitude data, requiring low bandwidth, ultra-low latency, and high reliability (5QI may be 6 / 7). QoS stream C is an audio stream, requiring medium bandwidth and low latency (5QI may be 1).

[0078] These QoS streams have significantly different requirements, and their instantaneous bandwidth and latency jitter fluctuate dynamically in real time according to user actions and scene content. Optimal scheduling cannot be achieved using only static 5QI.

[0079] In view of this, this application provides a QoS flow status reporting method. The terminal device obtains the normalized QoS score of the QoS flow by comprehensively considering multi-dimensional QoS indicators (such as percentile of transmission delay, packet loss rate, and delay jitter). The terminal device reports the normalized QoS score of the QoS flow, enabling the network device to perform uplink rate control based on dynamic and multi-dimensional QoS indicators, thus overcoming the scheduling rigidity problem caused by relying solely on static 5QI priority for uplink rate control in the prior art.

[0080] The solution provided in this application will be described in detail below with reference to the corresponding flowcharts. It is understood that the illustrative flowcharts provided in this application primarily use different devices (e.g., terminal devices, network devices) as examples of the execution subjects of this interactive illustration to illustrate the method, but this application does not limit the execution subjects of the interactive illustrations. For example, the devices in the illustrative flowcharts (e.g., terminal devices, network devices) can also be chips, chip systems, or processors that support the implementation of this method on the device, or logic modules or software that can implement all or part of the functions of the device.

[0081] As a general statement, the message or signaling interactions involved in the interaction process of this application embodiment can be standard messages or signaling or newly introduced messages or signaling. This application embodiment does not make specific limitations on this.

[0082] Figure 2 This is a flowchart illustrating a QoS flow state reporting method provided in an embodiment of this application. It can be understood that the terminal device involved in this QoS flow state reporting method can be... Figure 1 The term "terminal device" can also refer to a component within that terminal device (such as a processor, chip, or chip system). The network devices involved in this QoS flow state reporting method can be... Figure 1 Network equipment can also refer to devices within network equipment (such as processors, chips, or chip systems). For example... Figure 2 As shown, the QoS flow status reporting method 200 includes the following steps S201-S205, where S205 is optional:

[0083] S201. The terminal device sends data to the network device through QoS flow.

[0084] Accordingly, the network device receives data from the terminal device via a QoS stream. For example, this data refers to XR data.

[0085] S202, The terminal device calculates the normalized QoS score of multiple candidate QoS flows. ), normalized 5QI value ( ), normalized aging value ( ).

[0086] Among them, i is the serial number of the QoS flow, used to distinguish different QoS flows, 1 ≤ i ≤ M, and M is the number of QoS flows. The candidate QoS flow refers to the QoS flow that is currently in an active state and requires an uplink rate control decision. The candidate QoS flow satisfies at least one of the following: there is data waiting to be sent in the buffer, it is in a rate adaptation state, it is configured by the network device as a monitoring object, and there is data sent within the window. Only when there is data waiting to be sent in the buffer of the QoS flow is there a need to adjust the rate. When the QoS flow is in the rate adaptation state, the service type of the QoS flow supports dynamic rate adjustment (such as XR video stream), rather than a fixed bit rate service, then there is a need to adjust the rate. Only when the QoS flow is configured by the network device as a monitoring object does it need to be reported. Only when there is data sent within the window of the QoS flow can the terminal device count various indicators within the window.

[0087] It should be noted that the normalization involved in the embodiments of this application facilitates weighted summation of various indicators to obtain a comprehensive indicator. In statistical QoS theory, the quality of service can be abstracted as a multi-dimensional random process, and there is usually an exponential distribution relationship between its effective bandwidth and QoS constraints. To achieve low-complexity processing on the terminal device side, a linear weighting form is often used for approximation. When the QoS dimension indicators are normalized, their weighted sum can effectively characterize the overall degradation trend of the system performance.

[0088] As Figure 3 shown, S202 includes S2021 - S2023. The following will separately introduce how to calculate the normalized QoS score 、normalized 5QI value 、normalized aging value .

[0089] S2021. The terminal device obtains the normalized QoS score ( ) of the candidate QoS flow according to at least one of the following: the normalized A-th percentile ( ) of the transmission delay within the window of the candidate QoS flow, the normalized packet loss rate ( ), and the normalized delay jitter ( ).

[0090] A is an integer, 0 < A ≤ 100. For example, A = 95. The normalized QoS score provides a dynamic and continuous quality perception supplement, reflecting the short-term volatility of the service. The larger the normalized QoS score , the higher the degradation risk of the QoS flow, that is, the more serious the performance deviation from the target. As Figure 4 shown, it can be calculated by the QoS monitor (MAC layer sub-module) of the terminal device. Specifically, refer to formula 1:

[0091] + Formula 1.

[0092] in, , , The QoS score coefficient can be issued by network devices via RRC signaling, or it can be specified by the protocol. All are greater than or equal to 0. .

[0093] in, Let A be the normalized A percentile of the transmission delay of QoS stream i within the window (or simply the A percentile of transmission delay). ,like Figure 4 As shown, The transmission latency of QoS stream i, as statistically analyzed by the XR encoder (application layer) of the terminal device within the window. The transmission delay reference value (e.g., 100ms) can be issued by the network device via RRC signaling, or it can be specified by the protocol. The value is the result of a trade-off between service requirements, network capabilities, and policies. It can be issued by network devices via RRC signaling, or it can be specified by the protocol. In lightly loaded cells, more stringent values ​​can be set. To provide a better experience; in congested communities, restrictions may be appropriately relaxed. This is to avoid frequent scheduling triggers that could exacerbate competition. Different latency settings can also be configured for different services' transmission latency requirements. For example, the interactive frames of cloud gaming. It can be set very low (e.g., 10-20ms) for VR 360° video background streaming. It can be set slightly higher (e.g., 50-100ms).

[0094] The A percentile of transmission delay refers to the delay value at position A% of the total delay, obtained by sorting the transmission delays of all data packets in ascending order within the window. In other words, within the window, the transmission delays of A% of the data packets are all less than or equal to this delay value, while only the slowest (100-A)% of the data packets will have a transmission delay exceeding this value. This is used to measure the tail latency risk of QoS flow i. Tail latency risk refers to the possibility that a small number of data packets experience excessively long delays during network data transmission, and the resulting service impairment. Here, "tail" refers to the tail of the latency probability distribution curve. The larger the value, the higher the risk of tail latency. For example, if... =80ms =100ms, then =0.8. If =150ms =100ms, then =1, the tail delay risk reaches its highest. The delay probability distribution curve describes the probability (or probability density) of the random variable packet transmission delay for different values. The horizontal axis is the delay value, usually in milliseconds (ms). The vertical axis can be a probability density function, representing the relative probability that the delay falls within a certain minimal neighborhood. The area under the curve is 1.

[0095] The reasons for assessing tail latency risk are as follows: First, average latency can be deceptive. For example, although the average latency may not be high, a few extremely late data packets can severely impact the XR experience, such as causing stuttering in AR or VR, or malfunctions in cloud gaming. These extremely late data packets exist at the tail of the latency probability distribution curve. Second, the A percentile of transmission latency is used to quantify how bad this tail is, essentially quantifying the latency of the worst 5% of data packets. XR services, in particular, are extremely sensitive to occasional high-latency frames. A timed-out keyframe can lead to screen tearing or control failure. Therefore, ensuring tail latency is more meaningful than ensuring average latency, as it directly relates to the smoothness and consistency of the user experience.

[0096] in, Let i be the normalized packet loss rate of QoS flow i within the window, such as Figure 4 As shown, within the window, the terminal device's XR encoder counts the number of packets sent and lost for QoS stream i, and calculates the packet loss rate. It equals the number of lost packets divided by the number of sent packets. The reference value for packet loss rate (e.g., 0.001) can be issued by network devices via RRC signaling, or it can be specified by the protocol. , Let be the normalized packet loss rate for QoS flow i. Used to measure how much the data transmission reliability of QoS stream i deviates from the target. The higher the packet loss rate, the lower the reliability. Taking XR services as an example, XR services are very sensitive to packet loss. The loss of a keyframe or control command may result in: pixelation or stuttering in the image (video decoding error), unresponsive operation, or incorrect actions (loss of control commands). Therefore, it is necessary to keep the packet loss rate at an extremely low level.

[0097] in, This is the normalized delay jitter of QoS stream i within the window, such as delay variance or inter-frame delay difference. ,like Figure 4 As shown, The delay jitter of QoS stream i measured by the XR encoder of the terminal device within the window. The reference value for latency jitter (e.g., 10ms) can be issued by the network device via RRC signaling, or it can be specified by the protocol. Used to measure the degree of dispersion of the latency of QoS stream i around the average level or the latency difference between adjacent frames. The higher the jitter, the greater the latency difference. The negative impacts of latency jitter on XR services are as follows: Receivers (e.g., VR headsets) typically have a jitter buffer to smooth latency fluctuations. Excessive latency jitter means that if the buffer is too small, it cannot absorb latency fluctuations, leading to stuttering or disconnections. If the buffer is too large, it introduces fixed additional latency, violating the initial goal of low latency. Latency jitter also affects user experience. Even if the average latency and tail latency meet requirements, latency jitter can cause unstable screen update rates, resulting in a dizzying sensation from sudden changes in speed. It can also lead to audio-visual desynchronization and control loop instability. In remote control or haptic feedback scenarios, high jitter can make the control system unstable, causing oscillations or malfunctions.

[0098] S2022, 5QI value of QoS flow for terminal equipment ( Normalization mapping is performed to obtain the normalized 5QI value. ).

[0099] Please refer to Formula 2 for details:

[0100] Formula 2.

[0101] in, Priority 5QI is defined in the communication protocol TS 23.501. The maximum QI priority supported by the system is 5. The minimum 5QI priority supported by the system. and The mapping range for 5QI priority is defined. This mapping table can be configured by network devices via RRC messages.

[0102] S2023, Aging value of QoS flow for terminal equipment ( Perform normalization mapping to obtain normalized aging values. ).

[0103] Please refer to Formula 3 for details:

[0104] Formula 3.

[0105] Among them, the maximum aging value of QoS flow This refers to the maximum number of consecutive periods during which a QoS flow can not be reported, i.e., the maximum number of consecutive periods during which a QoS flow can be reported. The cycle is not reported. Let i be the number of cycles since the most recent QoS report. It is an integer. A larger value indicates that the longer QoS flow i has not been reported, the greater the probability that it will be selected for reporting next time. For example... Figure 4 As shown, the QoS monitor is also used to update the cycle number of QoS flow i at each reporting time. If QoS flow i is reported, then =0, if QoS flow i is not reported, then .

[0106] S203. The terminal device obtains the weight of the candidate QoS flow based on at least one of the following: Normalized 5QI value of candidate QoS flow ( ), Normalized QoS score ( ), normalized aging value ( ).

[0107] like Figure 4 As shown, the QoS priority calculator on the terminal device is used to calculate the weights of candidate QoS flows. See Formula 4 for details:

[0108] Formula 4.

[0109] in, , The weighting coefficients can be issued by network devices via RRC signaling, or as specified by the protocol. , All are greater than or equal to 0. .

[0110] S204. The terminal device selects at least one QoS flow from multiple candidate QoS flows according to the weights and sends a statistical summary to the network device. The statistical summary is used for uplink rate control of the QoS flow. The statistical summary includes first indication information and normalized QoS scores of at least one QoS flow. The first indication information is used to indicate whether the normalized QoS scores of each QoS flow are included in the statistical summary.

[0111] Accordingly, network devices receive statistical summaries from terminal devices.

[0112] like Figure 4 As shown, the QoS flow selector of the terminal device selects candidate QoS flows according to weights. Arrange in descending order and select weights. The top K largest QoS flows are used to report normalized QoS scores, with weights... Larger QoS flows have a higher probability of being reported with a normalized QoS score. K represents the number of control slots that the current resources can accommodate. K equals (available uplink resource bits - fixed overhead bits) / the number of bits per control slot. A control slot refers to the slot in the rate control MAC CE that carries the rate control information for the QoS flow. For example, assuming there are 10 candidate QoS flows, if K=5, only weighted flows are considered. Information on the top 5 QoS flows can be loaded into the MAC CE report. Weighting The 6th ranked QoS flow, regardless of its weight. It was very close to 5th place, but couldn't be reported this time, although the weighting... The normalized aging value of the 6th ranked QoS stream It will increase by 1.

[0113] Based on the statistical summary, network devices can perform at least one of the following: real-time uplink scheduling decisions and truncation guidance. Network devices also use quantified normalized QoS scores. Different QoS levels are used for uplink scheduling decisions, which can be found in Formula 5 and will not be elaborated here. Truncation guidance is an indicative signaling generated by network devices and sent to terminal devices. Its core purpose is to proactively guide terminal devices to prioritize truncated reporting of one or more specified QoS flows in the next reporting cycle, in scenarios where network resources are limited or congested. Truncation guidance is a suggestion or instruction, not a mandatory command. Terminal devices typically follow it, but retain the final decision-making power, maintaining flexibility and standards compatibility for the terminal devices.

[0114] like Figure 4 As shown, the MAC CE constructor of the terminal device is used to construct a statistical digest. The statistical digest includes first indication information and normalized QoS scores for at least one (i.e., K) QoS flows. The first indication information is used to indicate the normalized QoS score for each QoS flow. Whether it is included in the statistical summary. For example, the first indication information can be a bitmap, with the number of bits in the bitmap equal to the maximum number of QoS flows (e.g., 16). Each bit in the bitmap corresponds to a QoS flow and is used to indicate the normalized QoS score of the corresponding QoS flow. Whether it is included in the statistical summary. For example, the i-th bit of the bitmap corresponds to QoS stream i, and is used to indicate the normalized QoS score of the corresponding QoS stream i. Whether it is included in the statistical summary. The i-th bit is the first value (e.g., 1), indicating the normalized QoS score of QoS flow i. Included in the statistical summary; the i-th bit is a second value (e.g., 0), indicating the normalized QoS score of QoS flow i. It is not included in the statistical summary. The number of bits for the first value (e.g., 1) in the first indication information is K. The first indication information can also be a specific numerical value i, indicating that the statistical data belongs to QoS flow i. The embodiments of this application do not limit the form of the first indication information.

[0115] Optionally, to reduce signaling overhead, the terminal device can use normalized QoS scores. Quantization is performed, mapping continuous numerical values ​​to risk levels that occupy fewer bits. That is, the normalized QoS score can be a quantized value down to the risk level, and the statistical summary includes the first indication information and the quantized normalized QoS score. At this point, the first indication information is equivalent to the quantized normalized QoS score indicating each QoS flow. Whether it is included in the statistical summary. For example, terminal devices can use discretization functions. ( Compressed Normalized QoS Score The required bits, for example, 2 bits or 3 bits. Taking 2 bits to represent levels 0-3 as an example, we can obtain Formula 5:

[0116] Formula 5.

[0117] in, , Predefined scoring thresholds can be issued by network devices via RRC signaling, or specified by the protocol. Subsequent network devices can then utilize... Adjusting uplink grants (UL grants) as a weighting factor, for example Larger QoS flows gain additional power or rate.

[0118] At this point, the statistical summary includes the first indication information and quantized normalized QoS scores for at least one (i.e., K) QoS flows. Normalized QoS scores for K QoS flows Or quantified normalized QoS score Arranged sequentially according to the order in which the corresponding bits appear in the bit map.

[0119] For example, the bitmap of the first indication information is 0101, with two bits (the 2nd and 4th bits) having a first value (e.g., 1), so K=2. The 2nd bit corresponds to QoS stream 2, and the 4th bit corresponds to QoS stream 4. These are the quantized normalized QoS scores for these two QoS streams. If the binary values ​​are 01 and 10 respectively, then the quantized normalized QoS score of QoS flow 2 is represented. The normalized QoS score for QoS stream 4 is represented by a binary value of 01. It is a binary value of 10.

[0120] For example, QoS scores are normalized using B-bit quantization (e.g., 2, 3 bits). For example, the total length of the statistical digest is: C bits + K * B bits. C is the length of the bitmap of the first indication information, for example, 16.

[0121] Statistical summaries are a basic reporting mechanism designed to provide continuous, lightweight status feedback, reflecting baseline status and long-term trends, for network devices to fine-tune policies. Statistical summaries are reported in at least one of the following ways: periodic reporting over a first cycle, or reporting triggered by a first event.

[0122] Periodic reporting in the first cycle refers to the terminal device reporting when the first cycle (e.g., 500ms to 2s) is reached. The first cycle can be configured by the network device through RRC signaling, or it can be specified by the protocol.

[0123] By periodically reporting statistical summaries, terminal devices enable network devices to continuously and lightweightly observe the dynamic quality status of multiple QoS flows from terminal devices. Network devices can systematically acquire the risk level of each QoS flow, providing the scheduler with a baseline quality unaffected by sudden events. Network devices can implement preventative resource allocation and long-term policy optimization; for example, they can identify QoS flows consistently at a medium-risk level and proactively increase scheduling to prevent them from deteriorating to a high-risk level.

[0124] First-event-triggered reporting refers to the process whereby a terminal device reports an event as soon as possible upon detecting the first event. The first event includes at least one of the following: a normalized QoS score for any QoS flow. The normalized aging value of any QoS flow changes from being less than the first scoring threshold to being greater than the second scoring threshold (the second scoring threshold is greater than the first scoring threshold). Greater than or equal to the aging threshold; the terminal device receives a first request from the network device, the first request being used to instruct the terminal device to report a statistical summary.

[0125] When the normalized QoS score of any QoS stream When the risk level changes from below the first scoring threshold to above the second scoring threshold—that is, from a relatively low-risk range to a relatively high-risk range—the terminal device can immediately report a statistical summary to indicate a deterioration in risk level. This allows network devices to detect a sudden degradation in user experience within milliseconds to tens of milliseconds and prioritize scheduling that QoS flow, thereby effectively curbing further increases in the tail latency of that QoS flow. For example, the first and second scoring thresholds can be referenced as described above. , , For example, normalized QoS score. From less than Become greater than Or, from less than Become greater than .

[0126] When the normalized aging value of any QoS flow When the aging threshold is greater than or equal to 3, the terminal device actively discovers and reports those QoS flows that have not been scheduled for a long time, avoiding the risk that QoS flows will be forgotten by network devices due to long-term silence, preventing the infinite backlog of queues and sudden severe congestion caused by long-term lack of resources, and improving the overall fairness and long-term stability of multiple QoS flows.

[0127] When a network device determines that it needs to obtain rate control information for a specific QoS flow based on a global view (such as cell load and multi-user interference coordination), the network device issues a first request (such as truncation guidance), triggering the terminal device to report a statistical summary of the QoS flow as rate control information. This changes the traditional mechanism where network devices passively wait for rate control information, greatly improving the accuracy and flexibility of network device scheduling and resource allocation decisions.

[0128] For example, the statistical summary can be carried in an optional field of the XR rate control medium access control element (MAC CE). The overhead is extremely low, adding almost no burden to existing XR rate control MAC CEs. The statistical summary provides network devices with critical input to obtain real-time degradation risks for individual QoS flows, which can be used to: immediately adjust uplink grants (UL grants) or generate downlink truncation guidance.

[0129] After receiving the XR Rate Control MAC CE from the terminal device, the network device first parses the first indication information and normalized QoS score in the MAC CE to obtain the normalized QoS scores of which QoS flows the terminal device reported this time. Then, the network device compares the set of QoS flows reported this time with the set of QoS flows reported in the previous cycle to identify missing QoS flows that were not included in this round of reporting but whose historical status indicated high risk or criticality. The network device can generate and issue truncation guidance, which is carried through the downlink rate control MAC CE or RRC layer parameters, to instruct the terminal device to prioritize reporting the normalized QoS scores of the missing QoS flows in the next reporting cycle. Finally, based on the received normalized QoS scores, the network device dynamically updates its internal QoS evaluation model and uplink scheduling weight parameters, providing an optimization basis for subsequent resource allocation. This series of operations enables the network device to effectively monitor, proactively guide, and adaptively optimize the QoS flow status, forming a closed-loop collaborative mechanism between the terminal device and the network device.

[0130] S205. The terminal device sends detailed statistics of at least one QoS flow to the network device.

[0131] Step S205 is optional.

[0132] Detailed statistical data is used for AI model training, online or offline intelligent scheduling, anomaly detection, and policy optimization. Detailed statistical data includes second indication information and at least one of the following: the A percentile of QoS flow transmission latency within a window (e.g., the 50th percentile, 90th percentile, or 95th percentile of transmission latency), packet loss data (e.g., window count, loss bursts), latency jitter distribution (e.g., mean, standard deviation), frame size distribution (e.g., mean, standard deviation), transmission rate, queue backlog, timestamped samples, etc.

[0133] It should be noted that the detailed statistics are based on QoS flows, such as the A percentile of transmission delay of QoS flow i, packet loss data of QoS flow i, delay jitter distribution of QoS flow i, frame size distribution of QoS flow i, transmission rate of QoS flow i, queue backlog of QoS flow i, and timestamp samples of QoS flow i.

[0134] The second indication information is used to indicate the QoS flow corresponding to detailed statistical data. For example, the second indication information can be a QoS flow identifier. The A percentile of transmission delay is described above and will not be repeated here. Window count refers to the number of packets sent and lost in a QoS flow within a window. Packet loss burst is used to quantify the temporal concentration or burstiness of packet loss in a QoS flow, measuring consecutive packet loss, for example, the number of packets contained in the longest consecutive packet loss in a QoS flow within a window. Delay jitter distribution refers to the probability distribution obtained after statistical analysis of all delay jitter sample values ​​of a QoS flow within a window. Frame size distribution refers to the statistical distribution of the size values ​​of application layer data frames (or transport blocks) sent by a QoS flow within a window. Transmission rate refers to the average rate at which a QoS flow sends data within a window. Queue backlog refers to the amount of data (in bytes or packets) generated for a QoS flow in the terminal device that has not yet been successfully transmitted. Timestamp sample is the original sample of key events or measurements with precise timestamps.

[0135] Detailed statistics can be reported in vector form. A vector refers to an ordered, composite data structure containing multiple fields, each representing a metric. An example JavaScript object notation (JSON) representation of detailed statistics is shown below:

[0136] {

[0137] "qos_flow_id":3,

[0138] "window":{

[0139] "start":1634567890123,

[0140] "duration_ms":500

[0141] },

[0142] "metrics":{

[0143] "delay_percentiles":{"p50":12, "p90":25, "p95":32},

[0144] "loss": {"packets_sent":600, "packets_lost":2, "max_burst":1},

[0145] "jitter": {"mean_ms":5, "std_ms":8},

[0146] }

[0147] }

[0148] Here, "qos_flow_id":3 indicates that the QoS flow identifier is 3. "window" represents the window size. "start":1634567890123 indicates that the window start time is 1634567890123 milliseconds. "duration_ms":500 indicates that the window length is 500 milliseconds. "metrics" represents the metrics. "delay_percentiles":{"p50":12, "p90":25, "p95":32} indicates that the A percentile of the transmission delay includes: the 50th percentile of the transmission delay is 12, the 90th percentile of the transmission delay is 25, and the 95th percentile of the transmission delay is 32. "loss": {"packets_sent":600, "packets_lost":2, "max_burst":1} indicates that in the packet loss data, the number of packets sent is 600, the number of packets lost is 2, and the number of packet loss bursts is 1. "jitter": {"mean_ms":5, "std_ms":8} indicates that the mean value of the jitter distribution is 5ms and the standard deviation is 8ms.

[0149] Given the large volume of detailed statistical data, a more reliable reporting method is required. For example, detailed statistical data can be carried in RRC signaling or dedicated messages between terminal devices and network devices. Examples include extended MAC CE and RRC measurement reports.

[0150] Detailed statistics are a supplementary advanced reporting mechanism involving large volumes of data, and are reported only when truly necessary. Reporting methods for detailed statistics include at least one of the following: periodic reporting over a second cycle, or reporting triggered by a second event.

[0151] Periodic reporting in a second cycle refers to the terminal device reporting when the first cycle (e.g., 100 seconds) is reached. The second cycle can be configured by the network device via RRC signaling, or it can be agreed upon by the protocol. The second cycle is longer than the first cycle.

[0152] Terminal devices can randomly select QoS flows and periodically report detailed statistics of QoS flows at a lower frequency. This is equivalent to sampling and reporting detailed statistics of QoS flows. By utilizing idle bandwidth, it can be used for long-term statistical modeling of network devices and analysis of key performance indicators (KPIs).

[0153] Second event-triggered reporting refers to the process of reporting a second event as soon as possible when the terminal device detects it. The second event includes at least one of the following: the normalized QoS score of any QoS flow. The rate of change is greater than or equal to the rate of change threshold; normalized QoS scores for multiple QoS flows. The concentration (within a preset time period) changes from less than the third scoring threshold to greater than the fourth scoring threshold (the fourth scoring threshold is greater than the third scoring threshold); the terminal device receives a second request from the network device, the second request being used to instruct the terminal device to report detailed statistics of QoS flows.

[0154] Normalized QoS score of QoS stream When the rate of change exceeds the threshold, the system can sensitively detect rapid deterioration in the service experience of QoS flows. Once such an event occurs, the terminal device promptly reports detailed statistical data, providing the network device with the diagnostic data needed for root cause analysis. The network device can then distinguish between causes such as instantaneous deterioration of the wireless link, sudden accumulation of buffers, or a surge in application layer bit rate, thereby implementing the most precise remedial measures, effectively suppressing the spread of rapid deterioration, and minimizing fault recovery time.

[0155] Normalized QoS scores for multiple QoS streams The concentration of QoS flow scores shifting from below the third scoring threshold to above the fourth scoring threshold is equivalent to using a higher risk level as a trigger condition, enabling the system to identify systemic risks at the cell or user level. When multiple QoS flows simultaneously exhibit moderate to high risk, it indicates a common cause failure (e.g., co-channel interference, base station overload). After triggering detailed data reporting, network devices can obtain detailed statistical data on the correlation between multiple QoS flows, which can be used to analyze the correlation of causes. This allows for a leap from single-point fault handling to system risk prevention and control, providing direct data support for optimization decisions such as load balancing and interference coordination of network devices.

[0156] The reasons why a network device sends a second request include at least one of the following, or in other words, after obtaining detailed statistics on QoS flows, the network device can use them for at least one of the following: when the network device observes that a user or QoS flow is continuously abnormal, it needs detailed statistics on QoS flows for root cause analysis and network diagnosis; during AI model training, detailed statistics on QoS flows need to be collected as high-quality training samples for reinforcement learning schedulers, etc.; it is necessary to compare detailed statistics on QoS flows to verify the actual effect of new scheduling parameters or QoS policies. This on-demand and precise data collection mechanism greatly improves the initiative and intelligence level of network device operation and maintenance, enabling the collection of detailed statistics to strictly serve advanced purposes such as fault diagnosis, policy verification, or AI training, avoiding the ineffective overhead of continuous reporting, and achieving optimal matching between diagnostic resources and operation and maintenance goals.

[0157] It should be noted that both statistical summaries and detailed statistical data can be combined with periodic reporting and event-triggered reporting to form an effective complement. Periodic reporting provides stable QoS situational awareness, while event-triggered reporting is responsible for capturing and responding to sudden events. The two work together to ensure that network devices have long-term quality control capabilities and rapid response capabilities to short-term risks. The optimal balance is achieved between signaling overhead, response speed, and analysis depth, enabling the entire system to cope with millisecond-level scheduling challenges and support long-term network intelligence evolution.

[0158] The QoS flow status reporting method provided in this application defines a statistical summary containing a normalized QoS score and its reporting mechanism, enabling network devices to perform uplink rate control based on dynamic, multi-dimensional QoS indicators (such as percentile of transmission delay, packet loss rate, and delay jitter). This overcomes the scheduling rigidity problem caused by relying solely on static 5QI priority for uplink rate control in the prior art, and achieves timely reporting of the service status of QoS flows, improving the user experience of latency-sensitive services such as XR.

[0159] Figure 5 This is a flowchart illustrating another QoS flow status reporting method provided in this application embodiment, used to describe the above QoS flow status reporting method in conjunction with a specific interaction process. It can be understood that the terminal device involved in this QoS flow status reporting method can be... Figure 1 The term "terminal device" can also refer to a component within that terminal device (such as a processor, chip, or chip system). The network devices involved in this QoS flow state reporting method can be... Figure 1 Network equipment can also refer to devices within network equipment (such as processors, chips, or chip systems). For example... Figure 5 As shown, the QoS flow status reporting method 500 includes the following steps S501-S506:

[0160] S501, The network device sends QoS flow parameters to the terminal device.

[0161] Specifically, network devices send QoS flow parameters to terminal devices via RRC QoS flow establishment messages. Correspondingly, terminal devices receive the QoS flow parameters. The QoS flow parameters are used to establish a QoS flow. The QoS flow parameters include at least one of the following: Protocol Data Unit (PDU) session identifier, QoS flow identifier (QFI), and 5QI. The PDU session identifier indicates the PDU session to which the QoS flow belongs. The QFI uniquely identifies the QoS flow within that PDU session. The 5QI is a standardized QoS feature template index that defines the QoS flow's priority, packet delay budget, packet error rate, and other objectives.

[0162] S502, The terminal device sends confirmation information of QoS parameters to the network device.

[0163] Specifically, the network device sends an acknowledgment message for QoS parameters to the terminal device via an RRC QoS flow establishment completion message. Correspondingly, the network device receives the QoS parameter acknowledgment message. The QoS parameter acknowledgment message indicates that the QoS flow establishment is complete.

[0164] S503, the network device sends configuration parameters to the terminal device.

[0165] Specifically, the network device sends configuration parameters to the terminal device via an RRC reconfiguration message. Correspondingly, the network device receives the configuration parameters. The configuration parameters include at least one of the following: statistical function flags, 5QI parameters, coefficients, reference values, thresholds, window parameters, and periods.

[0166] The statistical function flag indicates whether the function of reporting statistical summaries and detailed statistical data is enabled. For example, if the statistical function flag is a third value (e.g., 1), it indicates that the function of reporting statistical summaries and detailed statistical data is enabled, and the terminal device executes the above-described QoS flow status reporting method; if the statistical function flag is a fourth value (e.g., 0), it indicates that the function of reporting statistical summaries and detailed statistical data is not enabled, and the terminal device does not execute the above-described QoS flow status reporting method.

[0167] The 5QI parameters may include the maximum 5QI priority supported by the system as described above. The minimum 5QI priority supported by the system .

[0168] The coefficients may include the QoS scoring coefficients mentioned above. Weighting coefficient , .

[0169] The reference value may include the transmission delay reference value mentioned above. Reference value for packet loss rate Reference values ​​for latency jitter .

[0170] Thresholds may include the scoring thresholds mentioned above. , The thresholds are: aging threshold, rate of change threshold, first scoring threshold, second scoring threshold, third scoring threshold, and fourth scoring threshold.

[0171] Window parameters can include the window's start time and the window's length T.

[0172] The cycle can include the first cycle and the second cycle mentioned above.

[0173] S504. The terminal device sends confirmation information for the configuration parameters to the network device.

[0174] Specifically, the network device sends a confirmation message for the configuration parameters to the terminal device via an RRC reconfiguration completion message. Correspondingly, the network device receives the confirmation message for the configuration parameters. This confirmation message indicates that the configuration parameters have taken effect.

[0175] S505: The terminal device sends a statistical summary to the network device.

[0176] This step refers to S202-S204 as described above, and will not be repeated here.

[0177] S506: Network devices send uplink authorization or rate adjustment commands to terminal devices.

[0178] Uplink authorization refers to the network device allocating specific time-frequency resources to a terminal device through downlink control information, allowing the terminal device to transmit data on the specified time-frequency resources. Rate adjustment command refers to the network device instructing the terminal device to adjust the upper limit of the uplink data transmission rate through RRC signaling or the MAC control unit.

[0179] Optionally, in situations where resources are limited or reporting is partial, the network device sends a truncation instruction to the terminal device. The truncation instruction is described above and will not be repeated here. Under normal reporting conditions, the network device sends an uplink authorization or rate adjustment command to the terminal device. If the terminal device receives a truncation instruction from the network device, it will include the QoS flow indicated in the truncation instruction as a high-priority consideration when preparing for the next report. This will affect the weight calculation and QoS flow selection in the next round of reporting, ultimately achieving guided, dynamic, closed-loop collaborative optimization of the network. For example, the terminal device can increase the number of cycles since the most recent report for that QoS flow. Alternatively, directly assign weights to the QoS flow. Set it to the maximum value.

[0180] like Figure 6 As shown in the illustration, an embodiment of this application provides a communication device. The communication device 600 may include a communication module 610. The communication module 610 can implement corresponding communication functions, which can be internal communication functions of the communication device 600 or communication functions between the communication device 600 and other devices. Optionally, the communication module 610 may also be referred to as a communication interface or transceiver module. Optionally, the communication device 600 further includes a processing module 620. The processing module 620 can implement corresponding processing functions.

[0181] Optionally, the communication device 600 further includes a storage module 630, which can be used to store instructions and / or data; the processing module 620 can read the instructions and / or data in the storage module 630 so that the communication device 600 can implement the aforementioned method embodiments.

[0182] In one possible design, the communication device 600 may correspond to the terminal device in the above method embodiments, or to a component (such as a circuit, chip, or chip system) configured in the terminal device. The communication device 600 can be used to perform the steps or processes performed by the terminal device in any of the above method embodiments.

[0183] For example, the communication module 610 is used to send data to the network device via a QoS flow; and to send a statistical summary to the network device, the statistical summary being used for uplink rate control of the QoS flow, the statistical summary including first indication information and normalized QoS score of at least one QoS flow, the first indication information being used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary, the normalized QoS score of the QoS flow being obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS flow within the window, the normalized packet loss rate, and the normalized delay jitter.

[0184] In one possible implementation, the communication module 610 is used to send detailed statistics of the QoS stream, which includes second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0185] In one possible design, the communication device 600 may correspond to the network device in the above method embodiments, or to a component (such as a circuit, chip, or chip system) configured in the network device. The communication device 600 can be used to perform the steps or processes performed by the network device in any of the above method embodiments.

[0186] For example, the communication module 610 is used to receive data via a QoS stream; receive a statistical summary, which is used for uplink rate control of the QoS stream. The statistical summary includes first indication information and a normalized QoS score for at least one QoS stream. The first indication information is used to indicate whether the normalized QoS score of each QoS stream is included in the statistical summary. The normalized QoS score of the QoS stream is obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS stream within the window, the normalized packet loss rate, and the normalized delay jitter.

[0187] In one possible implementation, the communication module 610 is used to receive detailed statistics of the QoS stream, which includes second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

[0188] Figure 7 This is a schematic diagram of another communication device provided in an embodiment of this application. The communication device 700 may be a chip, chip system, or processor, etc., in a terminal device that implements the above-described methods. The communication device 700 can be used to implement the methods described in the above-described method embodiments; for details, please refer to the descriptions in the above-described method embodiments.

[0189] like Figure 7 As shown, the communication device 700 may include one or more processors 710, which may also be referred to as processing units or processing modules, and can implement certain control functions. The processor 710 may be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, while the central processing unit can be used to control the communication device 700 (e.g., a base station, baseband chip, user, user chip), execute software programs, and process data from the software programs.

[0190] In an alternative design, the processor 710 may also store instructions and / or data, which can be executed by the processor 710 to cause the communication device 700 to perform the methods described in the above method embodiments.

[0191] In another alternative design, the communication device 700 may include a communication interface 720 for implementing receiving and transmitting functions. For example, the communication interface 720 may be a transceiver circuit, interface, interface circuit, or transceiver. The transceiver circuit, interface, interface circuit, or transceiver for implementing receiving and transmitting functions may be separate or integrated. The aforementioned transceiver circuit, interface, interface circuit, or transceiver may be used for reading and writing code / data, or it may be used for transmitting or relaying signals.

[0192] Optionally, the communication device 700 may include one or more memories 730, which may store instructions that can be executed on the processor 710, causing the communication device 700 to perform the methods described in the above method embodiments. Optionally, the memories 730 may also store data. Optionally, the processor 710 may also store instructions and / or data. The processor 710 and the memories 730 may be provided separately or integrated together.

[0193] It should be understood that, in one possible design, the steps in the method embodiments provided in this application can be implemented by integrated logic circuits in the processor's hardware or by instructions in software form. The steps of the methods disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0194] In one implementation, the communication device 700 may correspond to the terminal device in the above method embodiments and may be used to execute the various steps and / or processes executed by the terminal device in the above method embodiments. The processor 710 may be used to execute instructions stored in the memory 730, and when the processor 710 executes the instructions stored in the memory, the processor 710 is used to execute the various steps and / or processes of the above method embodiments corresponding to the terminal device.

[0195] In another implementation, the communication device 700 may correspond to the network device in the above method embodiments and may be used to execute the various steps and / or processes executed by the network device in the above method embodiments. The processor 710 may be used to execute instructions stored in the memory 730, and when the processor 710 executes the instructions stored in the memory, the processor 710 is used to execute the various steps and / or processes of the above method embodiments corresponding to the network device.

[0196] It should be understood that the aforementioned processor can be one or more chips. For example, the processor can be a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a system-on-chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a microcontroller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0197] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0198] According to the method provided in the embodiments of this application, this application also provides a processor, including: an input circuit, an output circuit, and a processing circuit. The processing circuit is used to receive signals through the input circuit and transmit signals through the output circuit, causing the processor to execute the method described in the embodiments of this application.

[0199] In specific implementation, the processor can be one or more chips, the input circuit can be input pins, the output circuit can be output pins, and the processing circuit can be transistors, gate circuits, flip-flops, and various logic circuits. The input signal received by the input circuit can be received and input by, for example, but not limited to, a receiver, and the signal output by the output circuit can be, for example, but not limited to, output to and transmitted by a transmitter. Furthermore, the input circuit and the output circuit can be the same circuit, which is used as both the input circuit and the output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0200] According to the method provided in the embodiments of this application, this application also provides a chip system, which includes one or more processors for calling and executing instructions stored in memory, thereby causing the method described in the embodiments of this application to be executed. The chip system may be composed of chips or may include chips and other discrete devices.

[0201] The chip system may include input circuits or interfaces for transmitting information or data, and output circuits or interfaces for receiving information or data.

[0202] According to the method provided in the embodiments of this application, this application also provides a communication system, which includes the aforementioned terminal device and network device.

[0203] According to the method provided in the embodiments of this application, this application also provides a computer program product, which includes: computer program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the terminal device or network device in any of the foregoing method embodiments.

[0204] According to the method provided in the embodiments of this application, this application also provides a computer-readable storage medium storing program code, which, when run on a computer, causes the computer to execute the various steps or processes executed by the terminal device or network device in any of the foregoing method embodiments.

[0205] The computer-readable storage medium may be the aforementioned volatile memory or non-volatile memory, or it may include both volatile memory and non-volatile memory.

[0206] In the embodiments of this application, the terms and English abbreviations are exemplary examples given for ease of description and should not be construed as limiting the application in any way. This application does not preclude the possibility of defining other terms that can achieve the same or similar functions in existing or future agreements.

[0207] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0209] It should be understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0210] In summary, the above description is merely a preferred embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for reporting Quality of Service (QoS) flow status, characterized in that, Applied to a terminal device, the method includes: Data is sent via QoS stream; Send a statistical summary, which is used for uplink rate control of QoS flows. The statistical summary includes first indication information and normalized QoS score of at least one QoS flow. The first indication information is used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary. The normalized QoS score of the QoS flow is obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS flow within the window, the normalized packet loss rate, and the normalized delay jitter. The statistical summary is reported in a manner that includes at least one of the following: periodic reporting with a first period, or reporting triggered by a first event; the first event includes at least one of the following: the normalized QoS score of any QoS flow changes from less than a first score threshold to greater than a second score threshold, where the second score threshold is greater than the first score threshold; the normalized aging value of any QoS flow is greater than or equal to the aging threshold; a first request is received, wherein the first request is used to instruct the terminal device to report the statistical summary.

2. The method according to claim 1, characterized in that, The at least one QoS flow is a QoS flow selected by the terminal device from multiple candidate QoS flows according to a weight. The weight of the candidate QoS flow is obtained from at least one of the following: the normalized 5QI value, the normalized QoS score, and the normalized aging value of the candidate QoS flow.

3. The method according to claim 2, characterized in that, The candidate QoS flow satisfies at least one of the following: there is data waiting to be sent in the buffer, it is in a rate adaptive state, it is configured as a monitoring object by the network device, and there is data to be sent within the window.

4. The method according to claim 1, characterized in that, The method further includes: Detailed statistics of the QoS stream are sent, including second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

5. The method according to claim 4, characterized in that, The reporting methods for the detailed statistical data include at least one of the following: periodic reporting in a second cycle, or reporting triggered by a second event; Wherein, the second period is greater than the first period; the second event includes at least one of the following: the rate of change of the normalized QoS score of any QoS flow is greater than or equal to the rate of change threshold; the normalized QoS score set of multiple QoS flows changes from less than a third score threshold to greater than a fourth score threshold, the fourth score threshold being greater than the third score threshold; a second request is received, the second request being used to instruct the terminal device to report detailed statistical data of the QoS flow.

6. The method according to any one of claims 1-3, characterized in that, The first indication information is a bitmap, where each bit corresponds to a QoS stream and is used to indicate whether the normalized QoS score of the corresponding QoS stream is included in the statistical summary.

7. The method according to any one of claims 1-3, characterized in that, The normalized QoS score is a quantized value quantized to the risk level.

8. A method for reporting QoS (Quality of Service) flow status, characterized in that, Applied to network devices, the method includes: Data is received via QoS stream; Receive a statistical summary, the statistical summary being used for uplink rate control of QoS flows, the statistical summary including first indication information and at least one normalized QoS score of QoS flows, the first indication information being used to indicate whether the normalized QoS score of each QoS flow is included in the statistical summary, the normalized QoS score of the QoS flow being obtained from at least one of the following: the normalized A percentile of the transmission delay of the QoS flow within the window, the normalized packet loss rate, and the normalized delay jitter; The statistical summary is reported in a manner that includes at least one of the following: periodic reporting over a first period, or reporting triggered by a first event; the first event includes at least one of the following: the normalized QoS score of any QoS flow changes from less than a first score threshold to greater than a second score threshold, where the second score threshold is greater than the first score threshold; the normalized aging value of any QoS flow is greater than or equal to the aging threshold; or a first request is received, which instructs the terminal device to report the statistical summary.

9. The method according to claim 8, characterized in that, The method further includes: Receive detailed statistics of the QoS stream, the detailed statistics including second indication information and at least one of the following: the A percentile of the transmission delay of the QoS stream within the window, packet loss data, delay jitter distribution, frame size distribution, transmission rate, queue backlog, and timestamp samples; the second indication information is used to indicate the QoS stream corresponding to the detailed statistics.

10. The method according to claim 8 or 9, characterized in that, The first indication information is a bitmap, where each bit corresponds to a QoS stream and is used to indicate whether the normalized QoS score of the corresponding QoS stream is included in the statistical summary.

11. The method according to claim 8 or 9, characterized in that, The normalized QoS score is a quantized value quantized to the risk level.

12. A communication device, characterized in that, The communication device includes a processor and a memory, wherein the memory stores instructions, and when the processor executes the instructions, the communication device performs the method as described in any one of claims 1-11.

13. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed, they cause the computer to perform the method as described in any one of claims 1-11.

Images