Method, system and device for traffic flow transmission

Abstract

The application discloses a service flow transmission method, system and device, relates to the field of wireless mobile communication, and is applied to a first device. The method comprises the following steps: receiving service attribute information of a QoS flow from a third device; sending wireless air interface mapping configuration information to a second device based on the service attribute information of the QoS flow; and sending a marked data packet to the second device. Through the method, the QoS is subjected to differential transmission, so that the transmission efficiency and rationality are improved.

Description

Technical Field

[0001] This invention relates to the field of wireless mobile communications, and particularly to methods, systems and devices for transmitting service streams. Background Technology

[0002] 5G constructs a three-layer end-to-end QoS architecture consisting of PDU Session (Protocol Data Unit Session), QoS Flow (Quality of Service Flow), and SDF (Service Data Flow). It uses QoS flow as the finest granularity of QoS management and abstracts and maps multi-dimensional QoS requirements such as latency, reliability, and priority through 5QI (5G QoS Identifier). This can better meet the transmission requirements of the three typical service scenarios in the 5G era: eMBB (Enhanced Mobile Broadband), URLLC (Ultra-Reliable and Low-Latency Communications), and mMTC (massive Machine Type Communications).

[0003] However, as mobile communication technology evolves to 6G, various new 6G services, such as holographic communication, industrial control, converged sensing communication, AI-native and semantic communication, have emerged and put forward new QoS requirements. The existing 5G QoS framework has gradually exposed obvious technical shortcomings: On the one hand, the 5G RAN (Radio Access Network) has weak service perception capabilities and can only perform resource scheduling based on protocol layer parameters. It cannot effectively distinguish data packets of different importance and semantics within the same QoS flow, nor can it perceive the actual application experience on the UE (User Equipment) side in real time, which can easily lead to ineffective waste of network resources and a decline in service transmission experience. On the other hand, 5G QoS always uses the QoS flow as the smallest management granularity. There is a lack of fine-grained differentiated processing mechanisms within the flow, and the 5QI standard table has limited coverage of QoS requirements and insufficient dynamic adaptation capabilities, making it difficult to meet the core requirements of new 6G services for multi-level differentiated transmission within the same Qo flow, deterministic guarantee of transmission latency, and dynamic semantic perception.

[0004] In summary, how to differentiate QoS transmission to improve transmission efficiency and rationality is a problem that needs to be solved in this field. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a service flow transmission method, system, and device to perform differentiated transmission based on QoS to improve transmission efficiency and rationality. The specific solution is as follows: In a first aspect, this application discloses a service flow transmission method, applied to a first device, comprising: Receive QoS stream service attribute information from a third device; The wireless air interface mapping configuration information is sent to the second device based on the service attribute information of the QoS flow. Send a tagged data packet to the second device.

[0006] Secondly, this application discloses a service flow transmission method applied to a second device, comprising: Receive QoS stream service attribute information from a third device; Receive QoS stream wireless interface mapping configuration information from the first device; Receive the tagged data packet sent by the first device.

[0007] Thirdly, this application discloses a service flow transmission method applied to a third device, comprising: Transmit QoS stream service attribute information to the first or second device; Receive QoS stream service attribute change requests or indication information from the first device.

[0008] Fourthly, this application discloses a service flow transmission system, including a first device, a second device, and a third device, wherein: The first device is used to receive QoS flow service attribute information from the third device, send wireless air interface mapping configuration information to the second device based on the QoS flow service attribute information, and send tagged data packets to the second device. The second device is used to receive service attribute information of QoS streams from the third device, receive radio interface mapping configuration information of QoS streams from the first device, and receive tagged data packets sent by the first device. The third device is used to transmit QoS stream service attribute information to the first device or the second device, and to receive QoS stream service attribute change requests or indication information from the first device.

[0009] Fifthly, this application discloses an electronic device, comprising: Memory, used to store computer programs; A processor is configured to execute the computer program to implement the steps of the aforementioned disclosed service flow transmission method.

[0010] The beneficial effects of this application are as follows: This application is applied to a first device, which receives service attribute information of a QoS flow from a third device; sends wireless air interface mapping configuration information to a second device based on the service attribute information of the QoS flow; and sends tagged data packets to the second device. Therefore, when this application is applied to a first device to receive service attribute information of a QoS flow from a third device, the first device can accurately perceive the fine-grained service characteristics and differentiated QoS requirements of the QoS flow, breaking through the limitation of traditional 5G using only QoSFlow as the smallest management granularity. This provides a precise basis for subsequent differentiated wireless air interface processing, achieving deep perception of services and meeting the core requirements of 6G service perception. Sending wireless air interface mapping configuration information to the second device based on the service attribute information of the QoS flow enables the second device and the first device to form a unified wireless air interface bearer mapping rule. This allows the second device to implement differentiated mapping of QoS flows and sub-flows to wireless bearers, logical channels, etc., based on the configuration, ensuring that different service attribute data are handled correctly at the air interface transmission layer. The system's differentiated processing capabilities optimize the allocation and scheduling strategies of wireless air interface resources, improving the adaptability and efficiency of air interface transmission. By sending tagged data packets to the second device, the second device can quickly and accurately identify the QoS flow and sub-flow, service component identifier, and other key information of the data packets. This drives the second device to execute corresponding differentiated processing strategies for the data packets at each protocol layer, achieving fine-grained scheduling and robustness guarantees at the packet level. This ensures that data packets with different service attributes receive matching transmission treatment, improves the transmission success rate and latency certainty of key data, reduces the ineffective occupation of resources by secondary data, and improves the overall efficiency and service quality of wireless air interface data transmission. At the same time, it achieves compatibility with the existing 5G architecture, allowing for functional upgrades without significant modifications to the existing network architecture. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0012] Figure 1 This is a flowchart of the first service flow transmission method disclosed in this application; Figure 2 This is a schematic diagram illustrating a specific differentiation instruction disclosed in this application; Figure 3 This is a schematic diagram illustrating a specific change in business attribute information disclosed in this application; Figure 4 This is a schematic diagram illustrating another specific change in business attribute information disclosed in this application; Figure 5This is a specific QoS flow decomposition diagram disclosed in this application; Figure 6 This is a schematic diagram of a specific type of substream transmission disclosed in this application; Figure 7 This is a schematic diagram of a specific QoS sub-stream differentiation mapping disclosed in this application; Figure 8 This is a schematic diagram of a specific RRC configuration disclosed in this application; Figure 9 This is a schematic diagram of a specific data packet marking disclosed in this application; Figure 10 This is a schematic diagram of a specific differentiated QoS substream transmission disclosed in this application; Figure 11 This is a flowchart of the second service flow transmission method disclosed in this application; Figure 12 This is a flowchart of the third service flow transmission method disclosed in this application; Figure 13 This application discloses a specific network signaling interaction diagram; Figure 14 This is a schematic diagram of a service flow transmission system disclosed in this application; Figure 15 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0014] As mobile communications evolve towards 6G, service models are shifting from "traffic-centric" to "task / semantic-centric." Traditional 5G RAN architectures, due to their weak awareness of service models, are unable to adapt to the service transmission requirements of 6G. Traditional 5G RANs have limited awareness of application layer states within the standard framework, and QoS scheduling relies solely on protocol stack parameters such as QFI / 5QI, priority, and GBR. This makes it impossible to distinguish data packets of different importance within the same QoS flow, and it's difficult to guarantee the synchronous delivery of multiple flows in scenarios such as multimedia calls. Furthermore, the network side lacks awareness of the actual user experience, easily leading to invalid retransmissions and reordering, resulting in resource waste and a decline in service experience. These issues have driven the industry to strengthen the service awareness capabilities of QoS frameworks in 6G research.

[0015] Traditional 5G QoS also cannot support the differentiated QoS service transmission requirements of 6G. It uses QoS Flow as the finest granularity of end-to-end QoS control, where all data packets within the same QoS Flow receive the same QoS forwarding treatment, failing to distinguish the relative importance of different types of data within the same application flow. On one hand, the lack of sub-granular differentiation mechanisms within QoS Flow means all packets within the same flow receive only the uniform QoS treatment defined by 5QI, failing to provide targeted protection for critical data and resulting in low network resource utilization efficiency. On the other hand, the coverage of the 5QI standard table is limited, and the standardization of dynamic 5QI is insufficient, making it difficult to accurately match the characteristic requirements of new applications such as 6G holographic communication and multi-dimensional control of industrial robots. The static 5QI mechanism cannot adapt to the flexible service needs of 6G.

[0016] Therefore, this application provides a service flow transmission scheme that performs differentiated transmission of QoS to improve transmission efficiency and rationality.

[0017] See Figure 1 As shown in the figure, this application discloses a service flow transmission method, applied to a first device, including: Step S11: Receive the service attribute information of the QoS stream from the third device.

[0018] Service flow transmission is divided into uplink and downlink according to the transmission direction. Downlink transmission refers to the transmission direction in which service data from the data network is forwarded by a third device (core network) to a first device (base station), and then the first device (base station) transmits the data to a second device (terminal) through the wireless interface. Uplink transmission refers to the transmission direction in which the second device (terminal) acts as the data sender, transmitting the service data stream through the wireless interface to the first device (base station), and then the base station forwards it to a third device (core network), finally delivering it to the data network. The two constitute an end-to-end service flow transmission link. The following section will elaborate on downlink transmission.

[0019] The first device is the Radio Access Network (RAN), and the third device is the core network. When establishing a service session with the RAN (e.g., NGAP PDU Session Resource Setup), the core network indicates differentiated QoS flow information. Specifically, the core network categorizes data flows with different service attribute characteristics according to QoS attributes, identifies the differentiated QoS sub-flows, and defines independent service attribute information (i.e., QoS parameter / profile) for each sub-flow, further instructing the RAN. Furthermore, to support dynamic QoS requirements, multiple sets of service attribute information can be defined for different QoS flows or differentiated QoS sub-flows to support on-demand updates of the QoS parameter set (QoS parameter / profile).

[0020] Specifically, such as Figure 2 As shown, the core network instructs the RAN (Radio Access Network) to provide differentiated QoS flow information (i.e., service attribute information) through the radio resource establishment procedure. Upon receiving the resource establishment request from the core network, the radio access network allocates radio resources to establish corresponding radio interface bearers for the service QoS flow according to the instructions. If the RAN successfully establishes the corresponding air interface resources according to the core network's requirements, the RAN sends a confirmation response to the core network; otherwise, it sends a rejection response.

[0021] In this embodiment, the service attribute information is used to indicate the transmission requirement information of the QoS stream or the transmission requirement information of each QoS sub-stream in the QoS stream.

[0022] In this embodiment, the service attribute information is an identifier selected from the identifiers corresponding to each preset configuration parameter set, which is used to indicate the transmission requirement information of each QoS sub-stream, or a configuration parameter set dynamically generated by the third device, which is used to indicate the transmission requirement information of each QoS sub-stream.

[0023] In the first specific embodiment of service attribute information modification, after receiving the service attribute information of the QoS stream from the third device, the method further includes: modifying the service attribute information according to the modification instruction issued by the third device to obtain new service attribute information.

[0024] In the second specific embodiment of service attribute information modification, after receiving the service attribute information of the QoS stream from the third device, the method further includes: sending a modification request to the third device, and modifying the service attribute information according to the modification indication returned by the third device based on the modification request, so as to obtain new service attribute information.

[0025] The business attribute information will be explained in detail below.

[0026] First, service attribute information is used to indicate the transmission requirements of a QoS flow or the transmission requirements of each QoS subflow within a QoS flow. The core network, such as the SMF (Session Management Function), supports the transmission of differentiated subflow QoS configurations in the radio resource establishment request message exchange sent to the RAN. For example, during the initial PDU (Protocol Data Unit) session establishment or modification, when the AMF (Access and Mobility Management Function) / SMF sends a QoS Flow description to the gNB (next generation NodeB) via NGAP (Next Generation Application Protocol), it appends a list of subflow configuration information (i.e., service attribute information). The format can define a QoS-SubFlow-List information element, where each item contains the QoS subflow ID and corresponding QoS parameters, specifically, any one or any combination of the following: QoSFlowIdentifier (QFI): QoS Flow ID, used to indicate the current service flow ID.

[0027] SubFlowID (SQFI) parameter: The sub-stream number of the data stream after being split within the QoS Flow. It can also be called SCID (Service Component ID) or other identifier IDs.

[0028] The SubQoSProfile ID (or ScQosProfileId) parameter is used to indicate the QoS parameter set identifier of the current subQoS Flow. A subQoS Flow may have multiple QoS parameter sets.

[0029] The SubPriority parameter indicates the priority of the current QoS Flow sub-flow. When there are multiple QoS Flow sub-flows in a QoS Flow, the data processing of the QoS Flow sub-flows is performed according to this priority.

[0030] The SubPacketDelayBudget parameter indicates the packet delay budget for the current QoS Flow subflow, which the RAN uses for radio air interface data transmission.

[0031] The SubPacket ErrorRate parameter indicates the packet error rate of the current QoS Flow sub-flow. The RAN uses this delay budget for radio air interface data transmission.

[0032] The SubTreatment parameters, {PreferSeparateDRB, Shared DRB}, indicate whether a separate DRB (Data RadioBearer) should be used when transmitting data of the current QoSFlow sub-stream over the radio interface. For example, the core network might instruct the RAN on a video QoS stream with a QFI (QoS Flow Identifier) ​​of 10, containing two sub-streams: ID1, a keyframe with a priority 3 (higher) than the mainstream stream and a stricter PDB (Packet Delay Budget), and recommends that the RAN place it on a separate DRB; and ID2, a regular frame using the default QoS. Upon receiving this, the RAN can establish two SDAP (Service Data Adaptation Protocol) queues and decide whether to create a new DRB for ID1.

[0033] The Dynamic SubPriority Adjustment parameter defines whether dynamic adjustment of subQoS subflow priority is allowed. In 6G networks, some service data may encounter emergencies during execution, requiring temporary priority increases to obtain better service quality.

[0034] Furthermore, when the core network transmits AI (Artificial Intelligence) data to the RAN, the corresponding AI QoS-related information differs from the general QoS parameter set information. It's important to note that the 6G AI QoS mechanism is fundamentally different from traditional 5G QoS. In 5G networks, 5QI (5G QoS Identifier) ​​is a parameter used to identify different service quality requirements, with a value range of 1-255. Each value corresponds to a set of preset performance values, including default priority level, packet delay budget, packet error rate, etc. However, in 6G networks, the AI ​​service quality dimensions will be further expanded, covering multiple aspects such as AI service latency, AI model accuracy, communication overhead, computational overhead, and data privacy. Therefore, the corresponding AI QoS-related information differs from the general QoS parameter set information. The 6G AI QoS parameter set information is indicated to the RAN through the control plane.

[0035] In the control plane, during core network-RAN interface interaction, the set of control plane parameters related to AI data indicated by the core network to the RAN includes the basic AI QoS identifier parameter set, the AI ​​task characteristic parameter set, the network resource requirement parameter set, and the security management parameter set (one or any combination thereof), as detailed below: The basic AI QoS identification parameter set includes QoS Flow ID (1-16), QCI (QoS Class Identifier), ARP (Allocation and Retention Priority), PBR (Packet Filter Rule), and / or possibly SubQoSflowId (the QoS subflow identifier to which the AI ​​belongs). These parameters provide basic QoS identification and priority management capabilities for the AI ​​data flow.

[0036] QoS Flow ID: This is a unique identifier for each AI QoS flow, used to distinguish different AI data flows. Each QoS Flow ID corresponds to a specific AI task or service, and the RAN allocates appropriate network resources to different AI data flows based on this identifier.

[0037] Sub-QoS Flow ID: This is a unique identifier for each sub-flow AI QoS flow, used to distinguish sub-data flows of different AI sub-flows within the same AI QoS flow. Each Sub-QoS Flow ID corresponds to a specific sub-AI task or service. The RAN uses this identifier to differentiate between different AI sub-data flows and allocate corresponding network resources.

[0038] QoS Class Identifier (QCI): Defines a pre-configured quality of service category, mapping to different network resource allocation strategies. In 6G networks, the QCI parameter will be extended to support AI-related service categories, such as QCI=5 for low-latency AI inference services and QCI=9 for high-reliability AI training services. Each QCI value corresponds to a set of preset performance parameters, including default priority level, packet delay budget, packet error rate, etc.

[0039] The Allocation and Retention Priority (ARP) parameter defines the resource allocation and retention priority, used for resource preemption strategies during network congestion. For example, ARP values ​​range from 1 to 8, where 1 represents the highest priority and 8 represents the lowest. In AI applications, urgent AI inference requests (such as autonomous driving safety decisions) will be assigned higher ARP values ​​to ensure that the necessary resources are still available during network congestion.

[0040] Packet Filter Rule (PFR) defines packet filtering rules used to identify AI data belonging to a specific QoS flow.

[0041] The AI ​​task characteristic parameter set is the core of the 6G AI control plane parameter architecture, used to describe information such as the specific type, version, target node, and urgency of the AI ​​task. These parameters enable the RAN to perform fine-grained resource scheduling and service quality assurance based on the characteristics of the AI ​​task. These parameters include AI Task Type (classification task, detection task, generation task, reinforcement learning), Model Version (v1.0, v2.1, etc.), Edge Node ID (EdgeNode_01, EdgeNode_02, etc.), Urgency Level (high, medium, low), and Data Source Type (real-time streaming data, batch data, parameter update data). The AI ​​task characteristic parameters include any one or a combination of the following: The AI ​​Task Type parameter identifies the specific type of AI task, including classification, detection, generation, and reinforcement learning. Different types of AI tasks have different network resource requirements. For example, classification tasks typically require low-latency inference services, while generation tasks may require high-bandwidth data transmission. The RAN allocates appropriate resource configurations to different types of tasks based on the AI ​​Task Type parameter.

[0042] The Model Version parameter identifies the version information of the AI ​​model, such as v1.0, v2.1, etc. In 6G networks, AI model updates and version management are important functions. The Model Version parameter enables the RAN to identify different versions of AI models, ensuring data transmission compatibility with model versions.

[0043] The Edge Node ID parameter specifies the identifier of the target edge computing node, such as EdgeNode_01, EdgeNode_02, etc. In 6G networks, AI inference and training tasks are typically distributed across multiple edge nodes. The Edge Node ID parameter ensures that AI data can be accurately transmitted to the target edge node for processing.

[0044] The Urgency Level parameter defines the urgency level of AI data, categorized into three levels: Urgent, Medium, and Low. High-urgency AI data (such as safety decision data for autonomous driving) requires higher transmission priority and stricter latency guarantees, while low-urgency data (such as periodic update data for AI models) can utilize lower-priority resources.

[0045] The Data Source Type parameter identifies the source type of the AI ​​data, including real-time streaming data, batch data, parameter update data, etc. Data from different sources has different transmission characteristics. Real-time streaming data typically requires low latency and continuous transmission, batch data may have bursty and high-volume characteristics, and parameter update data requires high reliability and integrity guarantees.

[0046] The network resource requirement parameter set defines the specific requirements of AI data streams for network resources, including the required resource type (low latency, high bandwidth, high reliability) and service level and network capability AI Service Type (inference service, training service, data acquisition service). These parameters provide clear guidance for RAN resource scheduling and allocation. The network resource requirement parameter set includes any one or a combination of the following: The Required Resource Type parameter specifies the type of network resources needed for the AI ​​data stream, including low-latency resources, high-bandwidth resources, and high-reliability resources. For example, real-time AI inference tasks typically require low-latency resources to ensure timely responses, while AI model training tasks may require high-bandwidth resources to support large-scale data transmission.

[0047] The AI ​​Service Type parameter identifies the type of AI service, including inference services, training services, and data acquisition services. Different types of AI services have different network resource requirements. Inference services typically require low latency and high reliability, training services require high bandwidth and large storage capacity, and data acquisition services require continuous data transmission capabilities.

[0048] AI service density parameter: defined as the number of AI services that can simultaneously meet specific accuracy and latency requirements per unit area. Network resource requirement parameters also include the requirement for AI service density, which will affect the RAN's resource allocation and scheduling strategies.

[0049] The AI ​​Service Accuracy parameter defines the accuracy requirement of the AI ​​service, that is, the degree to which the output of the AI ​​inference / learning service matches the truth value corresponding to a given input. This parameter is closely related to network transmission quality; high-quality network transmission is fundamental to ensuring the accuracy of the AI ​​service.

[0050] The `Adaptive Bandwidth` parameter defines whether dynamic bandwidth adjustment is allowed. In AI applications, the bandwidth requirements of different task phases can vary significantly. For example, the AI ​​model training phase may require high bandwidth to transmit large amounts of training data, while the inference phase only requires lower bandwidth to transmit inference requests and results. The `AdaptiveBandwidth` parameter enables the network to automatically adjust bandwidth allocation based on the task phase. (Note that this parameter may also be used for other QoS service flows, not limited to AI-type services, such as XR (Extended Reality) audio and video services, and is not limited to control plane services that may be indicated through the user plane.)

[0051] The Dynamic Priority Adjustment parameter defines whether dynamic adjustment of AI QoS priorities is allowed. In 6G networks, some AI tasks may encounter emergencies during execution, requiring a temporary increase in priority to obtain better service quality. For example, when an autonomous driving system detects an emergency, the priority of the relevant AI inference task can be increased through a dynamic priority adjustment mechanism. (Note that this parameter may also be used for other QoS service flows, not limited to AI-type services such as XR audio and video services, and also not limited to control plane services that may be indicated through the user plane.)

[0052] The Activation / Deactivation Conditions parameter defines the activation and deactivation conditions for AI QoS flows. These conditions are typically based on changes in the state of the AI ​​task, such as automatically deactivating the corresponding QoS flow when the AI ​​model parameters are updated. This mechanism can automatically manage the lifecycle of QoS resources, improving resource utilization efficiency. (Note: This parameter may also be used for other QoS service flows, not limited to AI-type services, such as XR audio and video services, and is not limited to control plane services that may be indicated through the user plane.)

[0053] Security Management Set: Responsible for the secure transmission and privacy protection of AI data, ensuring the confidentiality, integrity, and availability of AI data during network transmission. These parameters are crucial in 6G networks because AI data often contains sensitive user information and trade secrets. Parameters include Encryption Required (Yes / No), Integrity Protection Required (Yes / No), and Privacy Level (Confidential, Internal, Public), specifically including one or any combination of the following: The Encryption Required parameter specifies whether encrypted transmission of AI data is required. In 6G networks, highly sensitive AI data (such as medical diagnostic data and financial transaction data) typically requires end-to-end encryption using advanced encryption algorithms such as AES (Advanced Encryption Standard)-256. This encryption not only protects the confidentiality of the data but also prevents it from being intercepted and tampered with during transmission. (Note: This parameter may also be used for other QoS service flows, not limited to AI-type services such as XR audio and video services, and is not limited to control plane services that may be indicated through the user plane.)

[0054] The Integrity Protection Required parameter specifies whether integrity verification of AI data is required. For example, integrity verification typically employs technologies such as HMAC (Hash-based Message Authentication Code) to ensure that data has not been accidentally modified or maliciously tampered with during transmission. Integrity protection is a necessary security measure for critical information such as AI model parameters and training data. (Note: This parameter may also be used for other QoS service flows, not limited to AI-type services such as XR audio and video services, and is not limited to control plane services that may be indicated through the user plane.)

[0055] The Privacy Level parameter defines the privacy level of AI data, including three levels: Confidential, Internal, and Public. Different privacy levels require different security protection measures. Confidential data typically requires the highest level of encryption and access control, while public data can use simpler security measures. (Note: This parameter may also be used for other QoS service flows, not limited to AI-type services such as XR audio and video services, and is not limited to control plane services that may be indicated through the user plane.)

[0056] When the core network transmits XR type data to the RAN, in addition to traditional service QoS flow information indications, proprietary service-aware information related to XR also needs to be indicated to the RAN. In the control plane, when the core network interacts with the RAN interface, the set of control plane QoS parameters related to the XR data indicated by the core network to the RAN includes any one or any combination of the following: XR service type identifier: Used to distinguish XR service subclasses (VR (Virtual Reality) / AR (Augmented Reality) / MR (Mixed Reality)) and specific application scenarios (such as immersive meetings, industrial AR maintenance, XR games). Its function is to enable RAN to match differentiated scheduling strategies (such as VR video requiring high bandwidth and low jitter, and AR overlay requiring low latency and high reliability). Typical examples are VR-01 (immersive video), AR-02 (industrial maintenance), MR-03 (virtual-real interaction), etc.

[0057] XR Flow ID (or XR Sub QoSflow ID): Uniquely identifies a session data flow instance of a single XR user, covering related flows such as uplink interactive flow, downlink video flow, and audio flow, and can support RAN for joint scheduling and resource allocation of multiple flows for the same XR session.

[0058] XR terminal capability level: indicates the XR terminal's rendering capabilities, cache capacity, and multi-connection support capabilities (such as whether it supports millimeter wave + Sub-6G dual connectivity). The RAN can adjust transmission parameters accordingly (e.g., if the terminal cache is small, the data burst volume needs to be reduced; if dual connectivity is supported, multi-link transmission should be enabled).

[0059] XRDedicatedQCI (6G-QCI-XR): A QCI specific to XR, which predefines the core QoS characteristics (latency, reliability, bandwidth priority) of XR services, and enables the RAN to directly map scheduling policies (such as allocating dedicated resource blocks for high-priority XR interaction flows).

[0060] XRP Priority (ARP-XR): Used to distinguish the resource preemption priority of XR flows from other service flows. It can also distinguish the priority of multiple flows within the same XR session. When the network is congested, it can guarantee the resources of core XR flows (such as interactive control flows) and give priority to preempting non-critical service resources.

[0061] XR Experience Level Requirements (QoE-XR): Indicates the core experience metrics required for XR services, including resolution, frame rate, and dynamic bitrate range. The RAN can adjust the transmission bitrate and scheduling cycle accordingly (e.g., a higher scheduling frequency corresponds to an 8K / 60fps requirement). A typical example is: resolution: 8K, frame rate: 60fps, bitrate range: 15-25Gbps, etc. (Note: This parameter may be indicated by multiple individual cells.)

[0062] User interaction status indicator: Real-time feedback on the interaction activity of XR users, such as high interaction (gestures / rapid head movement), low interaction (static viewing), etc. RAN can dynamically adjust scheduling priority based on this indicator (increase resource allocation priority and reduce scheduling latency when there is high interaction). Typical examples are interaction levels: High (gesture operation frequency > 5 times / second), Low (static viewing), etc.

[0063] XR data dependencies: Indicate the dependencies between different data streams within the same XR session, such as control flow triggering video stream updates, audio stream and video stream synchronization, etc., helping the RAN to achieve multi-stream collaborative scheduling and avoid experience degradation caused by data asynchrony (such as audio and video asynchrony). A typical example is control flow (ID:001) → video stream (ID:002), with a synchronization latency of ≤20ms. (Note: Specific data dependencies can be indicated through the user plane interface of the core network and RAN, such as adding the PDU Set number of the dependent frame (I frame) to the header of the data packets in the PDU Set, which is based on frames (e.g., B frames, P frames).

[0064] Supports XR data fragmentation and reassembly mechanism: Indicates the fragment size, fragment numbering rules and reassembly priority of large XR data (such as 8K video frames). The RAN can optimize the fragment transmission order accordingly, prioritize the transmission of key fragments (such as core area fragments of the image), and improve rendering timeliness. A typical example is fragment size: 1MB, key fragment priority: P0 (core area), P1 (edge ​​area).

[0065] Retransmission policy configuration (Retrans-XR): Defines the retransmission mechanism for XR data, including whether retransmission is allowed, the number of retransmissions, and the retransmission timeout. It can balance reliability and latency (core streams such as control streams allow limited retransmissions, while non-core streams such as auxiliary video streams can abandon retransmissions to avoid latency accumulation). Typical examples are: control stream: number of retransmissions ≤ 2, timeout ≤ 500μs; auxiliary video stream: retransmissions prohibited, etc.

[0066] Multi-stream synchronous transmission requirement: This indicates the upper limit of the synchronization deviation for audio, video, and control streams within an XR session. It helps the RAN achieve joint scheduling of multiple streams, ensuring audio-visual synchronization and synchronization between control commands and screen updates. A typical example is an audio-video synchronization deviation ≤20ms, and a control stream-video stream synchronization deviation ≤5ms. (The specific synchronization relationships of the data streams can be further indicated through the user plane interfaces of the core network and the RAN.)

[0067] Encryption and Integrity Protection Indication: Indicates whether XR data needs to be transmitted with encryption (e.g., AES-256) and integrity verification (e.g., HMAC). The RAN can work with the core network to achieve end-to-end secure transmission and protect sensitive XR data (e.g., user interaction data, personalized content). Typical examples are: encryption: yes (AES-256), integrity verification: yes (HMAC-SHA256), etc.

[0068] Secondly, the service attribute information consists of identifiers selected from the corresponding identifiers of each preset configuration parameter set, used to indicate the transmission requirements of each QoS sub-flow; or, it consists of configuration parameter sets dynamically generated by a third device, used to indicate the transmission requirements of each QoS sub-flow. The third device is the core network, which predefines multiple sets of preset QoS configuration parameter sets containing transmission attributes such as latency, packet error rate, priority, whether DRB is shared, dropping policies, and retransmission mechanisms. It assigns a unique QoS Profile ID to each parameter set and forms a corresponding table. Only this identifier needs to be issued to indicate transmission requirements, significantly reducing signaling overhead. The dynamically generated configuration parameter sets are customized by the core network according to the specific service characteristics and actual transmission requirements of each QoS sub-flow. They can include core parameters such as QoSFlowIdentifier, SubFlowID / SCID, and SubPriority, and can also generate exclusive parameter sets for unique service sub-flows such as AI and XR. Alternatively, only the modified parameter content can be issued to achieve accurate and flexible indication of transmission requirements.

[0069] In the first specific embodiment of service attribute information modification, after receiving the service attribute information of the QoS flow from the third device, the service attribute information is modified according to the modification instruction issued by the third device to obtain new service attribute information. That is, when the transmission requirements of the QoS flow or QoS sub-flow change due to changes in service characteristics, network resource adjustments, etc., the core network will proactively issue a QoS Profile parameter modification instruction to the first device (Radio Access Network RAN), such as... Figure 3As shown, the instruction may contain entirely new service attribute information, or only modified part of the parameter content, or the identifier corresponding to the pre-configured parameter set. After receiving the change instruction, the RAN will update and adjust the original service attribute information accordingly, generate new service attribute information that matches the new transmission requirements, and at the same time, it will also complete the synchronous update of the radio interface configuration based on the new information, including SCID configuration, QoS flow and sub-flow mapping relationship adjustment, etc., and supports partial reconfiguration to reduce signaling overhead.

[0070] In the second specific embodiment of service attribute information modification, after receiving the service attribute information of the QoS stream from the third device, a modification request is sent to the third device, and the service attribute information is modified according to the modification indication returned by the third device based on the modification request to obtain new service attribute information. During actual data transmission, if the first device (RAN) finds that the current network status and radio interface environment cannot meet the transmission requirements corresponding to the service attribute information initially indicated by the core network, it will proactively initiate a QoS Profile parameter modification request to the core network, such as... Figure 4 As shown, the request may include new service attribute information suggested by the RAN. If the QoS flow or subflow has multiple pre-configured parameter sets in its initial configuration, the request may also only carry the identifier of the parameter set to be changed. After the core network reviews the request, it returns the corresponding change instruction. The RAN then modifies and replaces the original service attribute information according to the instruction, generates new service attribute information, and adjusts the bearer mapping, RRC configuration, data marking, and scheduling strategy of the radio air interface based on the new information to adapt to the actual transmission scenario and requirements.

[0071] In the third specific embodiment of service attribute information change, a dynamic QoS parameter adjustment mechanism without CN request or confirmation can also be considered, i.e., a mechanism that supports pre-configuration of multiple QoS Profiles + dynamic activation. Specifically, the core network pre-configures multiple QoS Profile parameter information (i.e., preset configuration parameter sets) for the same service to the RAN, and simultaneously instructs the activation conditions and corresponding threshold information for each QoS Profile (e.g., activating QoS Profile A when the latency meets the latency threshold, or activating QoS Profile B when the transmission rate meets the rate threshold, or activating QoS Profile C when the packet loss rate meets the packet loss rate threshold, etc.). The RAN determines the corresponding QoS Profile activation information based on the activation conditions, and when the QoS Profile activation conditions are met, it promptly activates the required QoS Profile.

[0072] When the QoS parameter set (i.e. service attribute information) of a QoS flow or QoS subflow changes, the RAN needs to adjust the DRB configuration of the radio interface accordingly to match the dynamic QoS transmission requirements. If the service characteristics change during the session, the mapping relationship between the QoS flow or QoS subflow and the DRB also needs to be changed synchronously.

[0073] In this embodiment, the QoS sub-stream is a fine-grained split of the data in the QoS stream by the first device or the third device according to the service type, service component, service characteristics or service requirements contained in the QoS stream, forming independent QoS sub-streams composed of data of different types or requirements, and each QoS sub-stream is configured with independent transmission requirement information.

[0074] The radio access network (RAN) of the first device or the core network of the third device performs fine-grained decomposition of the data in the QoS flow according to the service type, service components, service characteristics, or service requirements contained in the QoS flow, and then the data of different types or requirements are composed of independent QoS sub-flows. In other words, the core network can extend PCC rules during the service session establishment phase to split corresponding QoS sub-streams based on the differences in service type and service component of data within the QoS stream. It can also classify and split data with differentiated transmission requirements according to the service characteristics and actual service needs of the data. The RAN can also maintain the original granularity of the QoS Flow on the access side and autonomously split the QoS stream data with fine granularity based on its own perception of service semantics. The split independent QoS sub-streams can correspond to different types or requirements of data, such as key frames, ordinary frames, and control information in video QoS streams, real-time control commands and status monitoring data in industrial control QoS streams, and inference instructions and model parameters in AI QoS streams. Each QoS sub-stream is configured with independent transmission requirement information. The core network will assign a unique SubFlowID / SCID (Service Component Identifier) ​​to each QoS sub-stream. The SCID is an identifier used to distinguish different service service types (Service Components) within the same QoS Flow. A service service type can be a logical unit defined by the application layer, such as the frame type in a video stream, the audio stream in a real-time call, or the rendering instructions in an AR application. As shown in Figure 5, the QoS flow management dimension is broken down based on SCID. Structurally, it is divided into three dimensions: PDU, Session, QoS flow, and SCID. This multi-dimensional identification system allows the network to apply precise control policies to different service components. The specific breakdown is shown below: PDU Session (id=1); QoS Flow 1 (QFI=5); SCID=0: Keyframe (I / P frame); SCID=1: Normal frame (B-frame); SCID=2: Control information; QoS Flow 2 (QFI=8); SCID=0: Real-time control commands; SCID=1: Monitoring data; To support the aforementioned differentiated QoS processing, an independent SubQoSProfile ID needs to be configured to associate it with a dedicated set of QoS parameters for the sub-stream. At the same time, core transmission parameters are defined separately. For QoS sub-streams with special services such as AI and XR, dedicated independent transmission requirement information adapted to their service characteristics will also be configured. The core network can also configure multiple sets of independent transmission requirement information for the same QoS sub-stream to support dynamic switching based on service transmission status and network resource conditions, thereby meeting the differentiated transmission requirements in different scenarios.

[0075] In this embodiment, the transmission requirement information of the QoS sub-stream is used to describe the service requirements of the QoS sub-stream for transmission over the wireless air interface.

[0076] In a first specific embodiment of transmission requirement information indication, the transmission requirement information of the QoS sub-stream is indicated by a third device control plane message.

[0077] In the second specific embodiment of transmission requirement information indication, the transmission requirement information of the QoS sub-stream is indicated by the user plane data packet header of the third device.

[0078] The transmission requirements are described in detail below.

[0079] The transmission requirement information of QoS sub-streams is used to describe the service requirements of QoS sub-streams in the radio air interface. This requirement information covers general transmission requirements and the exclusive transmission requirements of special service sub-streams such as AI and XR, providing a precise basis for RAN to carry out differentiated bearer mapping, air interface configuration and data scheduling.

[0080] In the first specific embodiment of transmission requirement information indication, the transmission requirement information of the QoS sub-flow is indicated by the control plane message of the third device, namely the core network. During the process of establishing a service session with the RAN, such as NGAP PDU SessionResource Setup, the core network transmits the sub-flow configuration information list to the RAN through control plane messages such as radio resource establishment requests. At the same time, the core network can also issue only the Profile ID corresponding to the pre-configured QoS parameter set through control plane messages. The RAN parses the corresponding transmission requirements through the pre-configured table to realize the comprehensive and standardized indication of the sub-flow transmission requirement information of the control plane.

[0081] In the second specific embodiment of transmission requirement information indication, the transmission requirement information of the QoS sub-flow is indicated by the user plane data packet header of the third device, namely the core network. When the core network's UPF transmits service data to the RAN, it adds fields such as QFI, SCID / SQFI, and SubImportance to the user plane data packet header or GTP-U extension header to indicate the QoS sub-flow to which the data packet belongs and the corresponding importance and other transmission requirement information. The transmission requirement information of the QoS sub-flow is indicated in the packet by the user plane data packet header, so that the RAN can accurately identify the sub-flow transmission requirements while receiving data and adapt to the fine-grained scheduling processing at the packet level.

[0082] In the third specific embodiment of transmission requirement information indication, the transmission requirement information of the QoS sub-stream is indicated partly by the control plane message of the third device, i.e., the core network, and partly by the user plane data packet header of the third device, i.e., the core network.

[0083] In this embodiment, the service requirements of the QoS sub-stream transmitted over the wireless air interface include any one or more of the following attributes: timeliness attribute, synchronization attribute, fault tolerance attribute, importance attribute and / or dependency attribute, processing priority, packet delay budget, packet false alarm rate, air interface bearer mapping information, and priority escalation authority. The dependency attribute indicates whether there is a dependency between data within the QoS stream and / or whether there is a dependency between QoS streams.

[0084] The service requirements for QoS substreams transmitted over the wireless air interface include any one or more of the following attributes: timeliness, synchronization, fault tolerance, importance and / or dependency, processing priority, packet delay budget, packet false alarm rate, air interface bearer mapping information, and priority escalation authority.

[0085] Data stream type attribute: Used to distinguish the type of data stream being transmitted, such as control flow or service flow. Different stream types correspond to different processing mechanisms.

[0086] Timeliness attribute: Remaining deadline (absolute or relative lifetime), i.e., whether the business data is scheduled based on the deadline to ensure data timeliness. Furthermore, the remaining time limit may be indicated through the user plane packet header; that is, if scheduling or transmission is completed within the remaining time, the packet is considered valid; otherwise, the packet is invalid and discarded.

[0087] Critical / Important Attributes: Priority Level (e.g., used to distinguish between I-frames and P-frames, critical AI tokens and background tokens). Used to differentiate packet scheduling or transmission priorities or packet drop policies. Furthermore, the importance of packets may be indicated through the user plane packet header to assist in congestion decision-making, prioritizing the dropping of less important packets when congestion occurs.

[0088] Dependency attribute: Dependency identifier (dependence id) or protocol data unit set identifier (e.g., used to group semantically related and fate-shared data packets), indicating whether there is a dependency relationship between the service data. If a dependency relationship exists, it indicates the specific dependency situation (including dependencies between data within the same flow, or dependencies between flows). When a dependency relationship exists, if the dependent data packet is lost, the RAN sender, as the main data transmission entity, needs to discard the dependent data.

[0089] Synchronization attribute: Synchronization group identifier (used to identify service flows that need to be coordinated to meet the inter-flow synchronization threshold), that is, to indicate whether there is a synchronization relationship between this service data flow and other service data flows. If so, the RAN needs to ensure that the service flows with synchronization relationship are scheduled within the required synchronization time.

[0090] Data Stream Mode Attribute: Burst info, used to indicate the expected burst size, interval, or period of business data for burst data stream types, for timely adjustment of resource pre-allocation CG or DRX.

[0091] The fault tolerance attribute, Reliability Requirement, indicates whether the data stream has fault tolerance requirements or must be transmitted with guaranteed reliability.

[0092] Other attributes may include non-integer periodicity (for 60 / 90 / 120fps video), jitter envelope, priority label, or reliability class.

[0093] Step S12: Send wireless air interface mapping configuration information to the second device based on the service attribute information of the QoS flow.

[0094] The first device is the Radio Access Network (RAN), and the second device is the User Equipment (UE). After receiving the service attribute information of the QoS flow from the core network, the RAN will formulate a targeted radio interface mapping configuration strategy and generate radio interface mapping configuration information based on the transmission requirements of the QoS flow and each QoS sub-flow in the information.

[0095] In this embodiment, sending wireless air interface mapping configuration information to the second device based on the service attribute information of the QoS flow includes: performing fine-grained, differentiated, and independent wireless air interface bearer mapping configuration for each QoS flow or QoS sub-flow based on the service attribute information of the QoS flow, and indicating the obtained wireless air interface configuration information to the second device.

[0096] Based on the service attribute information of the QoS flow, the first device (Radio Access Network RAN) sends radio interface mapping configuration information to the second device (UE). Specifically, the first device (RAN) performs fine-grained, differentiated, and independent radio interface bearer mapping configuration for each QoS flow and its split QoS sub-flows according to their differentiated transmission requirements, based on the service attribute information of the QoS flow, and sends it to the UE through RRC messages. After the UE receives and confirms the radio interface mapping configuration information, it can perform differentiated QoS flow and sub-flow data transmission with the RAN according to the configuration.

[0097] In this embodiment, fine-grained, differentiated, and independent radio interface bearer mapping configuration is performed for each of the QoS sub-streams, including: mapping each independent QoS sub-stream in the QoS stream to different independent radio interface bearers based on the service attribute information of the QoS stream.

[0098] In traditional mechanisms, QoS flows and radio interface bearer DRBs have a one-to-one mapping relationship, meaning that all data within a QoS flow can only be transmitted through a single DRB, which cannot meet the differentiated and fine-grained transmission requirements of different data within a flow. Therefore, this embodiment performs differentiated bearer mapping for differentiated services within the same QoS flow based on the QoS attributes (such as QoS Profile or QoS parameter set) of its sub-flows. The core innovation lies in supporting multiple sub-QoS flows within a single QoS flow to be mapped to different DRBs based on their own QoS differences, completing the pipeline mapping from (QFI, SQFI / SCID) to (SQFI / SCID, DRBid).

[0099] like Figure 6As shown, taking QoS flow1 as an example, it is split into 3 SubQoS flows (i.e., 3 QoS sub-flows) based on the differences in QoS attributes of the data within the flow. SubQoS flow1 (i.e., QoS sub-flow 1) and SubQoS flow2 (i.e., QoS sub-flow 2), which have similar QoS transmission attributes, are mapped to the same radio bearer DRB1, while SubQoS flow3 (i.e., QoS sub-flow 3), which has significantly different QoS transmission attributes from the former two, is mapped to another radio bearer DRB2. The RAN base station generates corresponding DRB configurations (including AM / UM mode, retransmission mechanism, and drop mechanism) based on the QoS transmission attributes of each SubQoS flow and the radio interface transmission requirements (such as latency, false alarm rate, and urgency level) and sends them to the UE. The base station and the UE complete the guaranteed data transmission based on their respective DRB configurations.

[0100] The QoS transmission attributes and radio interface transmission requirements of these SubQoS flows mainly originate from the core network, while the specific radio interface configuration of the DRB is determined based on the differentiated bearer mapping mechanism. This mechanism decomposes the QoS flow into sub-flows and maps SubQoS flows with different QoS attributes to different DRBs, thereby achieving differentiated transmission and resource scheduling of intra-flow data and accurately matching the transmission requirements of different data.

[0101] In this embodiment, sending radio interface mapping configuration information to the second device based on the service attribute information of the QoS flow includes one of the following: mapping each independent QoS sub-flow in the QoS flow to different radio interface bearers; or mapping each QoS sub-flow to different RLC entities bound to the same radio interface bearer; or mapping each QoS sub-flow to different logical channels bound to the same RLC entity of the same radio interface bearer; or mapping each QoS sub-flow to different sub-logical channels in the same logical channel of the same RLC entity of the same radio interface bearer; or mapping each QoS sub-flow to the same logical channel of the same RLC entity of the same radio interface bearer but indicating different logical channel priorities; and sending an RRC message containing radio interface mapping configuration information to the second device based on the service attribute information of the QoS flow.

[0102] Specifically, based on the service attribute information of the QoS stream, wireless air interface mapping configuration information is sent to the second device. This means implementing fine-grained, differentiated, and independent wireless air interface bearer mapping configuration for each QoS sub-stream. There are five possible methods, such as... Figure 7 As shown, the specific method is as follows: The first approach maps each independent QoS sub-stream within a QoS flow to a different radio interface bearer DRB. The core of this approach is establishing a one-to-one correspondence between (QFI, SCID / SQFI) and (DRB id, LCID). Based on the differentiated transmission requirements of the QoS sub-streams (such as latency, reliability, and priority), the RAN allocates a dedicated DRB to each independent QoS sub-stream. The core network then uses control plane messages to indicate whether each sub-stream requires independent DRB sub-Treatment parameters. The RAN then creates independent radio bearer resources for different sub-streams accordingly, ensuring that each sub-stream receives transmission guarantees that match its own needs, achieving complete bearer isolation and fine-grained resource allocation between sub-streams.

[0103] The second approach is to map each QoS sub-stream to different RLC (RadioLink Control) entities bound to the same radio interface bearer. This means multiple QoS sub-streams share the same DRB but are associated with different RLC entities. Different RLC entities can be configured with different transmission modes (AM / UM), retransmission mechanisms, maximum retransmission counts, and other parameters. For example, QoS sub-streams with high reliability requirements can be bound to AM mode RLC entities to support ARQ retransmissions, while latency-sensitive sub-streams can be bound to UM mode RLC entities to reduce transmission delays. This differentiated configuration of RLC entities satisfies the transmission characteristic requirements of different sub-streams under the same DRB.

[0104] The third approach is to map each QoS sub-stream to different Logical Channels (LCHs) bound to the same RLC entity carried by the same radio air interface. The same RLC entity will distribute the data of different QoS sub-streams to independent LCHs for transmission. Each LCH can be configured with its own priority, scheduling weight, token bucket parameters, etc. The RAN, through the MAC (Medium Access Control) layer scheduler, allocates differentiated air interface resources to different QoS sub-streams according to the configuration parameters of the LCH, ensuring that high-priority sub-streams get priority scheduling in resource contention, while achieving logical isolation of sub-stream data.

[0105] The fourth approach is to map each QoS sub-stream to different sub-logical channels within the same logical channel of the same RLC entity carried by the same radio air interface, thus dividing the transmission channels into subdivided segments within a single LCH. By configuring independent transmission parameters (such as drop thresholds, delay budgets, and retransmission strategies) for the sub-logical channels, different QoS sub-streams within the same LCH can receive differentiated processing. This maintains the efficient use of logical channel resources while accurately matching the personalized transmission needs of each sub-stream, making it particularly suitable for scenarios with moderate sub-stream differences.

[0106] The fifth approach is to map each QoS sub-stream to the same logical channel of the same RLC entity carried by the same radio interface, but indicate different logical channel priorities. Differentiated scheduling of sub-streams is achieved through priority differentiation. In the RRC configuration, the RAN assigns a corresponding logical channel priority level to each QoS sub-stream. The smaller the value, the higher the priority. The MAC layer scheduler allocates resources according to this priority. When there is no congestion, transmission resources are allocated according to priority weight. In congested scenarios, the QoS requirements of high-priority sub-streams are prioritized. At the same time, unified logical channel transmission simplifies configuration and resource consumption.

[0107] After completing any of the above mapping configurations, the RAN will send an RRC message containing the radio interface mapping configuration information to the second device (UE, i.e., user equipment) based on the service attribute information of the QoS flow, to ensure that the UE is configured synchronously and performs data transmission and reception according to the rules.

[0108] In this embodiment, the RRC message also includes any one or more of the following: the service element identifier of the QoS sub-stream supported by each radio air interface bearer, the identifier of the radio air interface bearer, transmission configuration information, air interface bearer mapping information, and the second device auxiliary information reporting permission.

[0109] In this embodiment, the transmission configuration information includes any one or more of the following: scheduling priority, delay budget, reliability requirements, dropping policy, retransmission policy, mapping information or Boolean value representing whether the QoS sub-stream exclusively enjoys a single logical channel or RLC entity.

[0110] Within the access network (RAN), the base station, based on the differentiated QoS flow received from the core, further performs RRC configuration for the UE. This means configuring the corresponding bearer for the differentiated QoS flow transmission over the radio interface to meet the service transmission requirements of the differentiated QoS flow. Specifically, the base station needs to consider configuring and enhancing differentiated data flows and service awareness during the radio interface bearer configuration and then configure these features for the UE through the radio interface; this is known as RRC configuration enhancement.

[0111] like Figure 8 As shown, specifically, the configuration of DRB is enhanced through RRC signaling. The main extensions focus on the related IEs (Information Elements) of the radio air interface bearer DRB configuration and the SDAP (or other protocol layers mainly used to receive data from the core network and perform radio air interface transmission adaptation processing) configuration.

[0112] The RRC configuration is extended by introducing a new information element into the RadioBearerConfig of the RRC to configure the list of SubQoS flow IDs (SCIDs) and their parameters supported under each DRB. Specifically, a serviceComponentConfigList can be added under sdap-Config in the DRB-ToAddMod structure, or a list of supported SubQoS flow IDs (SCIDs) and their parameters can be directly specified to enumerate the allowed SCIDs and their QoS configurations under that DRB. The specific configuration may include the following parameter information (any one or a combination thereof): Scid (Service Component ID): This parameter represents the service ID value of the QoS flow identifier (i.e., the service element identifier of the QoS subflow). scid=0 can be defined as the default subflow with no special privileges, while other values ​​represent specific service categories used to distinguish differentiated service flow types. It is also called SubFlowID (SQFI), which is the number of the sub-QoS flow after the data subflow is split within the QoS flow. It may also be called SQFI (SubQoSflowID) or other identifier IDs.

[0113] defaultServiceComponentId: This parameter represents the default SCID, that is, the current DRB can be used to carry the service flow of the default SCID. When a service of a certain SCID does not specify a corresponding DRB, the wireless air interface transmission can be performed with a delay of the DRB.

[0114] AssociatedDRBid: This parameter represents the DRB-Identity associated with the current SCID data stream, i.e., the wireless air interface bearer identifier.

[0115] ScQosProfileId: This parameter represents the QoS parameter set information for the data flow of the current SCID. It can be a predefined "subflow QoS configuration profile". This mechanism includes data scheduling and processing parameters for this SCID, such as priority weights, packet scheduling policies, and the maximum allowed packet loss rate. Refer to the static indication method used by the core network to indicate the specific QoS parameter set of a sub-QoS flow to the access network RAN.

[0116] scPriorityLevel: This parameter indicates whether the current SCID data stream has priority, or priority level, such as highest priority, normal priority, no priority, etc.

[0117] scPacketDelayBudget: This parameter represents the data transmission delay budget for the current SCID data stream over the wireless air interface.

[0118] scReliabilityTarget: This parameter indicates the reliability requirements for the current SCID data stream in wireless air interface transmission, such as best-effort, high reliability, very high reliability, and extremely high reliability transmission.

[0119] scDiscardPolicy: This parameter indicates the discarding policy for the current SCID data stream transmitted over the wireless interface, such as allowing the discarding of some packets (further indicating the proportion to be discarded), or disallowing discarding. Further indications regarding the discarding policy can include enableEarlyDiscard configuration and earlyDiscardThreshold (such as a transmission latency threshold or a threshold for the proportion of already received packets).

[0120] scHarqConfig: This parameter indicates the retransmission policy for the current SCID data stream transmitted over the wireless air interface, such as allowing repeated transmissions, allowing retransmissions and their maximum number of retransmissions, disallowing retransmissions, etc.

[0121] MappedToDedicatedLogicalChannel: This parameter indicates whether the data flow of the current SCID is transmitted via a separate logical channel or a separate RLC entity during radio over-the-air transmission. It is a Boolean value. If set to TRUE, the network side recommends mapping the SubQoS flow belonging to this SCID to a separate MAC layer logical channel or a separate RLC entity. If FALSE or the default, the SubQoS flow belonging to the SCID shares the same logical channel or a separate RLC entity with other SubQoS flows, i.e., they are transmitted together.

[0122] ueAssistanceReportEnable: This parameter indicates whether the UE is allowed to report auxiliary information for the current SCID data stream during radio over-the-air transmission, such as packet loss rate, packet error rate, latency, etc. When allowed, the UE will report the corresponding transmission information.

[0123] An example of the definition of ASN.1 is as follows: SDAP-Config ::= SEQUENCE { pdu-Session PDU-SessionID, mappedQoS-FlowsToAdd SEQUENCE (SIZE(1..maxNrofQFIs)) OF QFI, ..., serviceComponentConfigList SEQUENCE (SIZE(1..maxNrofSCIDs)) OF SCID-Config OPTIONAL, defaultServiceComponentId INTEGER (0..15) OPTIONAL, (-- NEW: Default SCID for flows without ) } SCID-Config ::= SEQUENCE { Scid INTEGER (0..15), ScQosProfileId INTEGER (0..255), AssociatedDRBid DRB-Identity OPTIONAL scPriorityLevel INTEGER (1..127) OPTIONAL, scPacketDelayBudget INTEGER OPTIONAL, scReliabilityTarget ENUMERATED { besteffort,high,veryHigh,ultraReliable} OPTIONAL, scDiscardPolicy ENUMERATED { normal,congestionOptimized, noDiscard}OPTIONAL, scHarqConfig ENUMERATED {enableDuplication,maxRetransmissions,ErrorRate}, MappedToDedicatedLogicalChannel ENUMERATED { dedicated,shared}OPTIONAL, ueAssistanceReportEnable ENUMERATED { allowed, not allowed}OPTIONAL, }。

[0124] It is important to note that if the base station adopts a CU-DU separation architecture, the radio interface parameter configuration information (including the SCID list corresponding to each DRB, sub-stream QoS parameter set, bearer mapping rules, drop policy, retransmission mechanism, whether to use independent logical channels / RLC entities, and other configuration content related to differentiated QoS transmission) sent by the base station to the UE via RRC signaling must first be synchronously sent by the base station's CU (Central Unit) to the DU through a dedicated interface between the CU and DU. This ensures that the DU can obtain complete parameter configuration information and then perform radio interface bearer mapping, data marking, and scheduling processing of QoS sub-streams according to unified configuration rules. This ensures that the CU and DU work together, so that the configuration information received by the UE is consistent with the actual air interface transmission policy, and achieves accurate implementation of differentiated QoS transmission.

[0125] Step S13: Send the tagged data packet to the second device.

[0126] It is understandable that the third device can not only send QoS flow service attribute information to the first device, but also send user plane data to the first device.

[0127] When a core network element (UPF, User Plane Function) receives an IP packet from the data network, in addition to determining the QoS flow it belongs to based on the five-tuple matching, it further identifies the service type (SCID) of the packet within the corresponding QoS flow. This can be achieved in two ways: First, application-layer tagging and identification. For specific application protocols such as RTP (Real-time Transport Protocol), QUIC (Quick UDP Internet Connections), and HTTP (Hypertext Transfer Protocol), SDAP or UPF parses the application-specific fields in the packet header. For example, it distinguishes video and audio types from the Payload Type field in RTP, and different data types from the URL (Uniform Resource Locator) path in HTTP, thereby deriving the corresponding SCID. Second, deep packet inspection. Through the optional DPI function, it deeply parses the application protocol to identify more granular semantic information, such as parsing the I / P / B frame type for H.264 / H.265 video and the SCID for OPUS (Optimized Perceptual Audio). Coding (i.e., optimized perceptual audio coding) encodes audio to distinguish between speech frames and music frames, and matches them with corresponding SCIDs to complete the identification.

[0128] In one specific embodiment, when the core network transmits AI data to the RAN, at the user plane level, the core network and RAN interface interact. 6G core network user plane functions, such as the UPF, need to transmit AI service data and related user plane information to the RAN, and are responsible for the actual transmission control of the AI ​​data. In the core network-RAN user plane interface, the transmission of AI data uses an optimized data packet format, containing AI-related metadata information. The data packet not only contains the raw data but also QoS parameters, timestamps, sequence numbers, and other information, enabling the receiving end to correctly identify and process the data. The UPF needs to indicate in the data packet header or the GTP-U (GPRS Tunneling Protocol for User Plane) extension header that the AI ​​user plane information includes any one or any combination of the following fields: QoSFlowIdentifier (QFI): QoS Flow ID, used to indicate the current service flow ID.

[0129] SubFlowID (SQFI): The QoS flow sub-flow number after the data is split within the QoS flow. It may also be called SCID (Service Component ID) or other identifier IDs. It is used to indicate the QoS flow sub-flow number to which the current data packet belongs.

[0130] SubImportance: Indicates the importance of the QoS Flow subflow to which the current packet belongs or the importance of the current packet itself.

[0131] Timestamp parameters: Define the timestamp information of AI data. AI data packets need to embed the specific timestamp value in the user plane metadata field. The timestamp format must conform to the baseline and precision defined in the control plane "AI data timestamp configuration instruction" (such as UTC (Coordinated Universal Time) timestamp format). Specify the position, field length and parsing rules of the timestamp field (any one or a combination of the above).

[0132] Sequence number parameter: Defines the numbering information of AI data packets, used to define the order of data packets. The core network instructs each AI data packet to carry a unique sequence number, sequence number format, etc., through the user plane. Optionally, for fragmented AI data (such as large-size AI inference results), a fragmentation identifier must be appended to the sequence number, and the concatenation rules and parsing priority of the sequence number field and fragmentation identifier field must be clearly defined. The RAN can determine the data packet reception order through the sequence number, buffer and reassemble out-of-order data packets, and trigger retransmission for data packets with missing sequence numbers, ensuring the orderly and complete transmission of AI data.

[0133] The Model Size parameter defines the size of the AI ​​model, including the number of parameters, model file size, and other information. The Model Size parameter is used by the RAN to estimate transmission bandwidth requirements and allocate resources; larger models require more transmission resources and longer transmission times.

[0134] Furthermore, the core network can also instruct the RAN on the following AI-related service characteristics and transmission unit definitions, and instruct the RAN on one or any combination of the following information through the control plane or user plane: Token group / unit: The core unit set of AI serves as the basic unit for instructing the RAN to transmit units; Token group / cell start / end: ​​used to indicate the boundaries of the AI ​​data cell set; Token size / Number: Used to indicate the size and number of Tokens in the AI ​​data unit set; Token Dependence: Used to indicate the dependencies of AI data unit sets; Token inter-arrival Time / Jitter: Used to indicate the generation interval or jitter of AI data unit set tokens; Token Priority: Used to indicate the priority of the AI ​​data unit set Tokens.

[0135] Token importance: Used to indicate the importance of the AI ​​data unit set Token.

[0136] Token Deadline: Indicates the deadline for the AI ​​data unit set Token. It is valid only if the transmission is completed before the deadline.

[0137] Token fault tolerance: Used to indicate whether the AI ​​data unit set tokens support retransmission, that is, whether retransmission is required if the transmission is unsuccessful, and whether the impact of loss is significant.

[0138] Token size distribution: Used to indicate the typical size, minimum value, maximum value, or statistical distribution of tokens in the AI ​​data unit set.

[0139] The process of the first device sending a tagged data packet to the second device is described below.

[0140] In this embodiment, the QoS sub-stream in the QoS stream includes multiple data packets; sending the marked data packets to the second device includes: carrying QoS sub-stream identification information in the data sub-header or extended sub-header of the SDAP protocol layer that the QoS sub-stream undergoes during its transmission over the wireless air interface; the QoS sub-stream identification information includes any one or more of the following: service element identifier, or QoS sub-stream identifier, or critical data flag, reliability requirement flag, and discardable flag; processing the data packets carrying the QoS sub-stream identification information, and sending the processed data packets to the second device over the wireless air interface; wherein, the processing includes any one or more of the following: encryption processing, integrity protection processing, retransmission processing, discarding processing, and header compression processing.

[0141] The QoS sub-flow within a QoS flow contains multiple data packets. During the transmission of tagged data packets to the second device (UE), QoS sub-flow identification information is carried in the data header or optional extended header at the SDAP protocol layer through which the QoS sub-flow passes via the radio interface. This QoS sub-flow identification information may include any one or a combination of Service Element Identifier (SCID), QoS Sub-flow Identifier (SQFI), or Critical Data Flag (Cr), Reliability Requirement Flag (Re), and Droppable Flag (Dr). Next, the first device (RAN) performs corresponding processing on the data packet based on the QoS sub-flow's transmission requirement information and the identification information carried by the SDAP protocol layer. The processing methods may include any one or a combination of encryption, integrity protection, retransmission, dropping, and header compression. Finally, the identified and processed data packet is transmitted to the UE via the radio interface, ensuring that the UE can perform corresponding differentiated reception and processing based on the identification information in the data packet.

[0142] In wireless air interface transmission, the core of differentiated QoS flow data processing in the user plane is to achieve differentiated QoS processing and transmission within service flows based on service awareness. Its key feature is to break through the limitation of traditional QoS Flow as the smallest management granularity and introduce a "sub-flow / service-aware" marking and processing mechanism on the basis of QoS Flow, thereby realizing differentiated scheduling and robustness guarantee within a single flow. To support the differentiated data transmission of this mechanism in the Radio Access Network (RAN), a "sub-flow / service-aware" marking needs to be introduced in the data adaptation layer connecting the user plane of the RAN and the core network, namely the SDAP / PDCP layer, to provide technical support for differentiated scheduling and service guarantee within a single flow for the RAN.

[0143] Specifically, SCID needs to be introduced into the SDAP / PDCP layer / adaptation protocol layer packet extension header. An optional extension header is added to the SDAP sublayer protocol, using a new extension indicator bit (E) in the SDAP PDU header to indicate whether an extension field is included, as follows: When E=0, the existing SDAP header format (containing only QFI, etc.) is used. When E=1, an extended field such as {SCID, Flags} is added after QFI. The SCID field is used to distinguish sub-streams or specific data service types, such as video streams, audio streams, haptic feedback, control signaling, sensor data, AI models (gradients, weights, inference inputs and outputs), and other application-specific types; the Flags field is used to carry the importance or characteristic markers of data packets, such as keyframe flags, discardable flags, reliability flags, synchronous playback flags, etc. (any combination or one of these).

[0144] The following is based on Figure 9 The following example illustrates the design of this extended subheader: Extended header (located after the standard header): Octet N: Bit 4-7: SCID (4 bits, value 0-15); Bit 3: Cr (Critical) - 0: normal, 1: critical; Bit 2: Re (Reliable) - 0: best-effort, 1: high reliability; Bit 1: Dr (Droppable) - 0: must deliver, 1: can drop under congestion; Bit 0: Reserved; Bits 2 through 4 are extended flag bits. This explanation is for illustrative purposes only and does not specify the position of the bits.

[0145] It is understandable that the use of the extension header needs to be backward compatible. UEs or gNBs that do not support this feature will treat the E bit as 0 when receiving an SDAP PDU (or always set E=0 when sending the packet), ignoring any subsequent extension fields and processing it in the traditional way. Therefore, it can be stipulated that the network will only activate the use of the SCID extension header in the RRC configuration when both parties declare support for the SCID feature; for terminals that do not support it, the network will continue to provide services at the previous QoS Flow granularity without being affected. The above packet sub-header marking processing applies to both the base station's data processing protocol layer and the UE's data processing protocol layer.

[0146] The following is based on Figure 10 Taking this as an example, the corresponding explanation of the service-aware differentiated data transmission processing flow is given.

[0147] 1) After receiving downlink data, the base station SDAP / PDCP layer or adaptation protocol layer first matches the corresponding QoSFlow based on QFI, then distinguishes and tags the data queues by sub-stream ID, completing the mapping to the Radio Bearer (DRB). The SDAP layer first reads the SCID from the packet sub-header, or derives the SCID value from the QFI information; then, it adds an optional extension header to the SDAP sub-header containing QFI, sets the extension indicator bit E=1 and carries the SCID, and can also add flags such as keyframe, dropable, and reliability flags as needed; finally, it performs the mapping from (QFI, SCID) to (DRB, LCID) according to the RRC configuration, and determines whether to map the corresponding QoS flow to an independent logical channel or RLC entity according to the service QoS requirements.

[0148] 2) The PDCP layer retains the original basic functions such as encryption, integrity protection, and header compression, and formulates differentiated processing strategies for the reliability requirements of different SCIDs. For SCIDs marked as critical (C=1), enhanced strategies such as PDCP retransmission and strengthened integrity protection are adopted to improve data transmission reliability; for SCIDs marked as disposable (D=1), optimization strategies such as early packet discarding and selective skipping of header compression are implemented to save buffer resources and reduce transmission latency.

[0149] 3) The RLC layer enhances the ARQ (Automatic Repeat Request) retransmission strategy, providing adapted retransmission behavior for different SCIDs. In AM (Acknowledged Mode), it breaks the traditional retransmission rules based on NACK arrival order or packet sequence number, and performs retransmission based on the reliability priority of SCIDs, prioritizing NACK requests for critical SCID data and abandoning the retransmission of low-priority, discardable data. In UM (Unacknowledged Mode), for SCID data with high reliability requirements, it implements a flow control strategy of multiple transmissions to compensate for the reliability shortcomings of the lack of a retransmission mechanism.

[0150] 4) For SCID data streams with independent bearer requirements, the MAC layer employs an independent logical channel mapping mechanism to map key SCID configurations to dedicated logical channels. This design allows the MAC layer scheduler to directly apply priority weights to LCIDs without needing to be aware of SCID details, directly reusing existing LCID-level priority scheduling mechanisms, thus ensuring network compatibility while achieving differentiated SCID scheduling.

[0151] 5) After receiving the data from the MAC layer that has completed SCID differentiation processing, the base station PHY (Physical Layer) layer executes the physical layer standard processing procedure and finally sends the data to the terminal UE through the radio interface to complete the downlink SCID-based differentiated QoS data transmission.

[0152] After the SDAP layer on the UE side parses the sub-flow marking information in the data packet, it will adopt differentiated caching and data processing strategies for different types of sub-flows. Data packets marked as important sub-flows will be forwarded to the upper layer application for processing first. For data packets of non-important sub-flows, even if they are forwarded with a short delay in the cache, the service requirements can be met. This differentiated processing method realizes the coordinated matching between the data processing strategy on the UE side and the sub-flow scheduling strategy on the network side, ensuring the end-to-end service-aware differentiated QoS transmission effect.

[0153] The beneficial effects of this application are as follows: This application is applied to a first device, which receives service attribute information of a QoS flow from a third device; sends wireless air interface mapping configuration information to a second device based on the service attribute information of the QoS flow; and sends tagged data packets to the second device. Therefore, when this application is applied to a first device to receive service attribute information of a QoS flow from a third device, the first device can accurately perceive the fine-grained service characteristics and differentiated QoS requirements of the QoS flow, breaking through the limitation of traditional 5G using only QoSFlow as the smallest management granularity. This provides a precise basis for subsequent differentiated wireless air interface processing, achieving deep perception of services and meeting the core requirements of 6G service perception. Sending wireless air interface mapping configuration information to the second device based on the service attribute information of the QoS flow enables the second device and the first device to form a unified wireless air interface bearer mapping rule. This allows the second device to implement differentiated mapping of QoS flows and sub-flows to wireless bearers, logical channels, etc., based on the configuration, ensuring that different service attribute data are handled correctly at the air interface transmission layer. The system's differentiated processing capabilities optimize the allocation and scheduling strategies of wireless air interface resources, improving the adaptability and efficiency of air interface transmission. By sending tagged data packets to the second device, the second device can quickly and accurately identify the QoS flow and sub-flow, service component identifier, and other key information of the data packets. This drives the second device to execute corresponding differentiated processing strategies for the data packets at each protocol layer, achieving fine-grained scheduling and robustness guarantees at the packet level. This ensures that data packets with different service attributes receive matching transmission treatment, improves the transmission success rate and latency certainty of key data, reduces the ineffective occupation of resources by secondary data, and improves the overall efficiency and service quality of wireless air interface data transmission. At the same time, it achieves compatibility with the existing 5G architecture, allowing for functional upgrades without significant modifications to the existing network architecture.

[0154] See Figure 11 As shown in the figure, this application discloses a service flow transmission method applied to a second device, including: Step S21: Receive QoS stream service attribute information from the third device.

[0155] The second device (terminal) receives the service attribute information of the QoS flow from the third device (core network). This service attribute information can be used to indicate the transmission requirement information of the QoS flow or the transmission requirement information of each QoS sub-flow in the QoS flow.

[0156] A QoS sub-stream is an independent sub-stream composed of different types or requirements of data after the first device (base station) or the third device has finely split the QoS stream data according to the service type, service components, service characteristics or service requirements contained in the QoS stream, and each QoS sub-stream is configured with independent transmission requirement information.

[0157] The service attribute information can be an identifier selected from the identifiers corresponding to each preset configuration parameter set, which respectively indicates the transmission requirements of each QoS sub-stream, or it can be a configuration parameter set dynamically generated by the third device, which respectively indicates the transmission requirements of each QoS sub-stream. Specifically, it can be indicated through the control plane message or user plane data packet header of the third device.

[0158] The transmission requirement information of QoS sub-streams is used to describe their service requirements for transmission over the wireless air interface. Specifically, it includes attributes such as timeliness, synchronization, fault tolerance, importance, and dependency, as well as processing priority, packet delay budget, packet error rate, air interface bearer mapping information, and priority escalation authority, among which the dependency attribute indicates whether there is a dependency between data within a QoS stream or between QoS streams.

[0159] Step S22: Receive the QoS stream radio interface mapping configuration information from the first device.

[0160] The second device receives the radio interface mapping configuration information of the QoS flow from the first device. This configuration information is formulated by the first device based on the service attribute information of the QoS flow. The core is to complete the fine-grained, differentiated, and independent radio interface bearer mapping configuration for each QoS flow or QoS sub-flow. Specifically, it can be implemented in five ways: mapping each QoS sub-flow to different radio interface bearers, mapping to different RLC entities bound to the same radio interface bearer, mapping to different logical channels bound to the same RLC entity of the same radio interface bearer, mapping to different sub-logical channels in the same logical channel of the same RLC entity of the same radio interface bearer, or mapping to the same logical channel of the same RLC entity of the same radio interface bearer but indicating different logical channel priorities. The first device will send an RRC message containing the mapping configuration to the second device. The RRC message may also contain any one or more of the following: the QoS sub-flow service element identifier supported by each radio interface bearer, the radio interface bearer identifier, the transmission configuration information, the air interface bearer mapping information, and the second device's auxiliary information reporting permissions. The transmission configuration information covers relevant information such as scheduling priority, delay budget, reliability requirements, drop policy, and retransmission policy.

[0161] Step S23: Receive the tagged data packet sent by the first device.

[0162] The second device receives a tagged data packet sent by the first device. The QoS sub-flow in the data packet contains multiple data packets. Before sending, the first device carries QoS sub-flow identification information in the data header or extended header of the SDAP protocol layer that the QoS sub-flow undergoes during its wireless air interface transmission. This identification information includes any one or more of the following: service element identifier, QoS sub-flow identifier, critical data flag, reliability requirement flag, and discardable flag. The first device performs any one or more of the following processing on the data packet carrying this identification information: encryption, integrity protection, retransmission, discarding, and header compression. Then, it sends the processed data packet to the second device through the wireless air interface. After receiving the data packet, the second device can parse the sub-flow marking information in the data packet and adopt differentiated caching and processing strategies for different sub-flows to achieve coordination with the network-side scheduling strategy.

[0163] See Figure 12 As shown in the figure, this application discloses a service flow transmission method applied to a third device, including: Step S31: Transmit the service attribute information of the QoS stream to the first device or the second device.

[0164] The third device (core network) transmits QoS flow service attribute information to the first device (base station) or the second device (terminal). This service attribute information can be used to indicate the transmission requirement information of the QoS flow or the transmission requirement information of each QoS sub-flow in the QoS flow. A QoS sub-stream is an independent sub-stream formed by a first or third device after fine-grained splitting of the data in a QoS stream based on the service type, service components, service characteristics, or service requirements contained in the QoS stream. Each QoS sub-stream is configured with independent transmission requirement information. This service attribute information can be an identifier selected from the identifiers corresponding to each preset configuration parameter set, used to indicate the transmission requirement information of each QoS sub-stream, or it can be a set of configuration parameters dynamically generated by the third device, used to indicate the transmission requirement information of each QoS sub-stream. The transmission requirement information of the QoS sub-stream describes its service requirements for transmission over the wireless air interface, specifically including any one or more of the following: timeliness attribute, synchronization attribute, fault tolerance attribute, importance attribute and / or dependency attribute, processing priority, packet delay budget, packet error rate, air interface bearer mapping information, and priority escalation authority. Among them, the dependency attribute indicates whether there is a dependency between data within the QoS stream and / or whether there is a dependency between QoS streams. This transmission requirement information can be indicated by the third device through control plane messages or user plane packet headers.

[0165] Step S32: Receive the QoS flow service attribute change request or indication information from the first device.

[0166] When changing service attribute information, the third device will receive a QoS flow service attribute change request or indication information sent by the first device. The change request is initiated by the first device based on the actual needs of service transmission, while the indication information is the feedback from the first device to the third device regarding the relevant circumstances of the service attribute information change. After receiving the change request or indication information, the third device will adjust the QoS flow service attribute information accordingly based on its content and send the adjusted change indication to the first device.

[0167] When changing service attribute information, the third device can proactively send a change instruction to the first device, which will then modify the service attribute information and generate new service attribute information based on the instruction. Specifically, when the transmission requirements of a QoS flow or QoS sub-flow change due to changes in service characteristics or network resource adjustments, the core network, acting as the third device, will proactively send a QoS Profile parameter change instruction to the first device (Radio Access Network RAN). This instruction may contain entirely new service attribute information, only partially modified parameters, or identifiers corresponding to pre-configured parameter sets. Upon receiving the change instruction, the RAN will update and adjust the existing service attribute information accordingly, generating service attribute information that matches the new transmission requirements. Simultaneously, it will also synchronize the update of the radio interface configuration based on the new service attribute information, including SCID configuration, adjustments to the mapping relationship between QoS flows and sub-flows to DRBs, and other operations. This process supports partial reconfiguration to reduce signaling overhead.

[0168] When changing service attribute information, a dynamic QoS parameter adjustment mechanism can be adopted that does not require requests or confirmations from third-party devices. This mechanism is specifically implemented by pre-configuring multiple QoS Profiles and dynamically activating them. The core network will pre-configure multiple QoS Profile parameter information for the same service to the RAN, that is, a preset configuration parameter set. At the same time, it will specify the corresponding activation conditions and related threshold information for each QoS Profile. For example, QoS Profile A will be activated when the latency reaches a specified latency threshold, QoS Profile B will be activated when the transmission rate meets a specified rate threshold, and QoS Profile C will be activated when the packet loss rate meets a specified packet loss rate threshold. The RAN will determine the activation status of the corresponding QoS Profile in real time according to the preset activation conditions. When it detects that the activation conditions of a certain QoS Profile are met, it will activate that QoS Profile in a timely manner.

[0169] like Figure 13As shown, when the QoS parameter set of a QoS flow or QoS subflow, i.e., the service attribute information, changes, the RAN needs to adjust the DRB configuration of the radio interface accordingly to match the dynamically changing QoS transmission requirements. If the service characteristics change during the service session, the mapping relationship between the QoS flow or QoS subflow and the DRB also needs to be adjusted synchronously to ensure that the bearer configuration of the radio interface always matches the actual transmission requirements of the service.

[0170] It is important to note that service transmission is divided into uplink and downlink directions according to the transmission direction. Uplink transmission refers to the second device (terminal) dividing and marking service data into sub-streams according to the QoS flow service attribute information issued by the core network and the radio air interface mapping configuration information configured by the first device (base station). After adding QoS sub-stream identification information to the data packets and completing the corresponding processing at the SDAP protocol layer, the marked data packets are sent to the first device (base station) through the radio air interface. After receiving the data, the base station parses the sub-stream identification, completes differentiated protocol layer processing and bearer mapping according to the service attribute information, and then forwards the data to the third device (core network), thus completing the uplink data transmission.

[0171] It is understandable that uplink and downlink transmissions share many similarities in their core transmission logic. Both rely on QoS flow service attribute information from the core network to achieve fine-grained QoS sub-stream segmentation; both require adding QoS sub-stream identification information to data packets at the SDAP protocol layer; both configure differentiated radio interface bearer mapping strategies for QoS flows or QoS sub-streams through the base station; and both protocol layers perform differentiated processing such as encryption, retransmission, and discarding on different QoS sub-streams based on identification information such as SCID. The difference lies in the reverse direction of data transmission: downlink from the core network to the base station and then to the terminal, while uplink from the terminal to the base station and then to the core network. Furthermore, the entities responsible for identifying data packets and performing radio interface mapping configuration have corresponding reverse operations in uplink and downlink. Downlink involves the base station marking data packets and issuing air interface configurations, while uplink involves the terminal marking data packets before sending them to the base station. The base station receives and processes the uplink data based on the configuration. The following section elaborates on the uplink transmission process.

[0172] Uplink service flow transmission uses the second device (terminal) as the data initiator. The terminal first receives QoS flow service attribute information from the third device (core network). This information includes the independent transmission requirements of the QoS flow and each QoS sub-flow. Simultaneously, the terminal also receives radio interface mapping configuration information generated based on this service attribute information from the first device (base station), clarifying the mapping relationship between (QFI, SCID / SQFI) and (DRB id, LCID) and various transmission configuration parameters. After generating uplink service data, the terminal performs fine-grained segmentation of the QoS flow based on the service attribute information, dividing it into different QoS sub-flows. Then, according to the radio interface mapping configuration information, it performs corresponding bearer mapping rule matching for the data packets of each QoS sub-flow to determine the corresponding air interface bearer, RLC entity, or logical channel for transmission.

[0173] After completing the QoS sub-stream segmentation and bearer mapping matching, the terminal will carry QoS sub-stream identification information in the data sub-header or extended sub-header at the SDAP protocol layer through which the data packets are transmitted over the radio air interface. This identification may include any one or more of the following: service element identification, QoS sub-stream identification, critical data flag, reliability requirement flag, and discardable flag. Subsequently, the terminal will perform differentiated processing on the data packets carrying the identification information according to the transmission requirements of each QoS sub-stream. The processing methods include one or more of the following: encryption, integrity protection, retransmission, discarding, and header compression. Then, according to the predetermined radio air interface mapping configuration, the terminal will send the processed marked data packets to the base station through the radio air interface.

[0174] After receiving the uplink tagged data packets sent by the terminal, the first device (base station) first parses the QoS sub-flow identification information in the SDAP protocol layer to identify the QoS flow and QoS sub-flow to which each data packet belongs. Then, based on the service attribute information received from the core network, it performs differentiated processing on the data packets of different QoS sub-flows at each protocol layer, including reliability differentiation processing at the PDCP layer, ARQ retransmission differentiation scheduling at the RLC layer, and logical channel priority scheduling at the MAC layer. After the base station completes the differentiation processing at all protocol layers, it forwards the uplink service data to the third device (core network). After receiving the data, the core network can perform subsequent data forwarding and processing according to service requirements. At the same time, if the base station finds that the service attribute information needs to be adjusted during transmission, it can send a QoS flow service attribute change request or indication information to the core network. The core network then completes the information adjustment and issues a change indication, realizing dynamic adaptation of service attribute information during uplink transmission.

[0175] See Figure 14 As shown in the figure, this application discloses a service flow transmission system, including a first device, a second device, and a third device, wherein: The first device 11 is used to receive QoS flow service attribute information from the third device, send wireless air interface mapping configuration information to the second device based on the QoS flow service attribute information, and send tagged data packets to the second device; The second device 12 is used to receive service attribute information of QoS stream from the third device, receive radio interface mapping configuration information of QoS stream from the first device, and receive tagged data packets sent by the first device. The third device 13 is used to transmit QoS stream service attribute information to the first device or the second device, and to receive QoS stream service attribute change requests or indication information from the first device.

[0176] Furthermore, the first device is a base station, the second device is a terminal, and the third device is a core network.

[0177] Furthermore, embodiments of this application also provide an electronic device. Figure 15 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0178] Figure 15 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Specifically, it may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the service flow transmission method performed by the electronic device disclosed in any of the foregoing embodiments.

[0179] In this embodiment, the power supply 23 is used to provide operating voltage for various hardware devices on the electronic device; the communication interface 24 can create a data transmission channel between the electronic device and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0180] The processor 21 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 21 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 21 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0181] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored on it include operating system 221, computer program 222 and data 223, etc., and the storage method can be temporary storage or permanent storage.

[0182] The operating system 221 manages and controls the various hardware devices and computer programs 222 on the electronic device to enable the processor 21 to perform calculations and processing on the massive amounts of data 223 in the memory 22. The operating system 221 can be Windows, Unix, Linux, etc. The computer program 222, in addition to including a computer program capable of performing the service flow transmission method executed by the electronic device as disclosed in any of the foregoing embodiments, may further include computer programs capable of performing other specific tasks. The data 223 may include data received by the electronic device from external devices, as well as data collected by its own input / output interface 25.

[0183] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned disclosed service flow transmission method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0184] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0185] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly in hardware, software modules executed by a processor, or a combination of both. The software module may be located in random access memory (RAM), memory, read-only memory (ROM), electrically programmable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), register, hard disk, removable disk, CD-ROM (Compact Disc Read-Only Memory), or any other form of storage medium known in the art.

[0186] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0187] The above provides a detailed description of a service flow transmission method, system, and device provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only intended to help understand the method and core ideas of the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A service flow transmission method, characterized in that, Applied to the first device, including: Receive QoS stream service attribute information from a third device; The wireless air interface mapping configuration information is sent to the second device based on the service attribute information of the QoS flow. Send a tagged data packet to the second device.

2. The service flow transmission method according to claim 1, characterized in that, The service attribute information is used to indicate the transmission requirement information of the QoS stream or the transmission requirement information of each QoS sub-stream in the QoS stream; The QoS sub-stream is a fine-grained breakdown of the data in the QoS stream by the first device or the third device based on the service type, service component, service characteristics, or service requirements contained in the QoS stream, resulting in independent QoS sub-streams composed of data of different types or requirements, and each QoS sub-stream is configured with independent transmission requirement information.

3. The service flow transmission method according to claim 1, characterized in that, The service attribute information is either an identifier selected from the identifiers corresponding to each preset configuration parameter set, used to indicate the transmission requirement information of each QoS sub-stream, or a configuration parameter set dynamically generated by the third device, used to indicate the transmission requirement information of each QoS sub-stream.

4. The service flow transmission method according to claim 2, characterized in that, The transmission requirement information of the QoS sub-stream is used to describe the service requirements of the QoS sub-stream for transmission over the wireless air interface.

5. The service flow transmission method according to claim 4, characterized in that, The service requirements for the QoS sub-stream transmitted over the wireless air interface include any one or more of the following attributes: timeliness attribute, synchronization attribute, fault tolerance attribute, importance attribute and / or dependency attribute, processing priority, packet delay budget, packet false alarm rate, air interface bearer mapping information, and priority escalation authority. The dependency attribute indicates whether there is a dependency between data within the QoS stream and / or whether there is a dependency between QoS streams.

6. The service flow transmission method according to claim 2, characterized in that, The transmission requirement information of the QoS sub-stream is indicated by a third device control plane message.

7. The service flow transmission method according to claim 2, characterized in that, The transmission requirement information of the QoS sub-stream is indicated by the user plane data packet header of the third device.

8. The service flow transmission method according to claim 1, characterized in that, After receiving the service attribute information of the QoS stream from the third device, the method further includes: The service attribute information is modified according to the change instruction issued by the third device to obtain new service attribute information.

9. The service flow transmission method according to claim 1, characterized in that, After receiving the service attribute information of the QoS stream from the third device, the method further includes: A change request is sent to the third device, and the service attribute information is changed according to the change instruction returned by the third device based on the change request, so as to obtain new service attribute information.

10. The service flow transmission method according to claim 1, characterized in that, The process of sending wireless air interface mapping configuration information to the second device based on QoS flow service attribute information includes: Based on the service attribute information of the QoS flow, fine-grained, differentiated, and independent wireless air interface bearer mapping configuration is performed for each QoS flow or QoS sub-flow, and the obtained wireless air interface configuration information is indicated to the second device.

11. The service flow transmission method according to claim 10, characterized in that, Fine-grained, differentiated, and independent radio interface bearer mapping configurations are performed for each of the aforementioned QoS sub-streams, including: Based on the service attribute information of the QoS flow, each independent QoS sub-flow in the QoS flow is mapped to a different independent radio air interface bearer.

12. The service flow transmission method according to claim 11, characterized in that, The wireless air interface mapping configuration information sent to the second device based on the QoS flow service attribute information includes one of the following: Map each independent QoS sub-stream in the QoS stream to a different radio air interface bearer; Alternatively, each of the QoS substreams can be mapped to a different RLC entity bound to the same radio interface bearer; Alternatively, each of the QoS substreams can be mapped to a different logical channel bound to the same RLC entity carried by the same radio air interface; Alternatively, each of the QoS sub-streams can be mapped to a different sub-logical channel within the same logical channel of the same RLC entity carried by the same radio interface; Alternatively, each of the QoS substreams can be mapped to the same logical channel of the same RLC entity carried by the same radio air interface, but with different logical channel priorities indicated. Based on the QoS flow service attribute information, an RRC message containing wireless air interface mapping configuration information is sent to the second device.

13. The service flow transmission method according to claim 12, characterized in that, The RRC message also includes one or more of the following: the service element identifier of the QoS sub-stream supported by each radio air interface bearer, the identifier of the radio air interface bearer, transmission configuration information, air interface bearer mapping information, and the second device auxiliary information reporting permission.

14. The service flow transmission method according to claim 13, characterized in that, The transmission configuration information includes scheduling priority, delay budget, reliability requirements, drop policy, retransmission policy, mapping information or Boolean values ​​representing whether the QoS sub-stream exclusively enjoys a single logical channel or RLC entity.

15. The service flow transmission method according to claim 1, characterized in that, The QoS sub-stream in the QoS stream includes multiple data packets; the sending of the tagged data packets to the second device includes: The QoS sub-stream identification information is carried in the data sub-header or extended sub-header of the SDAP protocol layer that the QoS sub-stream undergoes during its transmission over the wireless air interface; the QoS sub-stream identification information includes any one or more of the following flags: service element flag, QoS sub-stream flag, critical data flag, reliability requirement flag, and discardable flag. The data packet carrying the QoS sub-stream identifier information is processed, and the processed data packet is sent to the second device through the wireless air interface; wherein, the processing includes any one or more of the following: encryption processing, integrity protection processing, retransmission processing, discarding processing, and header compression processing.

16. A service flow transmission method, characterized in that, Applied to a second device, including: Receive QoS stream service attribute information from a third device; Receive QoS stream wireless interface mapping configuration information from the first device; Receive the tagged data packet sent by the first device.

17. A service flow transmission method, characterized in that, Applied to third-party devices, including: Transmit QoS stream service attribute information to the first or second device; Receive QoS stream service attribute change requests or indication information from the first device.

18. A service flow transmission system, characterized in that, It includes the first device, the second device, and the third device, wherein: The first device is used to receive QoS flow service attribute information from the third device, send wireless air interface mapping configuration information to the second device based on the QoS flow service attribute information, and send tagged data packets to the second device. The second device is used to receive service attribute information of QoS streams from the third device, receive radio interface mapping configuration information of QoS streams from the first device, and receive tagged data packets sent by the first device. The third device is used to transmit QoS stream service attribute information to the first device or the second device, and to receive QoS stream service attribute change requests or indication information from the first device.

19. The service flow transmission system according to claim 18, characterized in that, The first device is a base station, the second device is a terminal, and the third device is a core network.

20. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the service flow transmission method as described in any one of claims 1 to 17.

Images