WO2026026352A1 - 数据传输方法、装置、计算机可读介质及电子设备 - Google Patents

数据传输方法、装置、计算机可读介质及电子设备

Info

Publication number
WO2026026352A1
WO2026026352A1 PCT/CN2025/104236 CN2025104236W WO2026026352A1 WO 2026026352 A1 WO2026026352 A1 WO 2026026352A1 CN 2025104236 W CN2025104236 W CN 2025104236W WO 2026026352 A1 WO2026026352 A1 WO 2026026352A1
Authority
WO
WIPO (PCT)
Prior art keywords
transmission
qos
streams
synchronization
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/104236
Other languages
English (en)
French (fr)
Inventor
雷艺学
贾宇航
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tencent Technology (Shenzhen) Co Ltd
Original Assignee
Tencent Technology (Shenzhen) Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tencent Technology (Shenzhen) Co Ltd filed Critical Tencent Technology (Shenzhen) Co Ltd
Publication of WO2026026352A1 publication Critical patent/WO2026026352A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24—Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W56/00—Synchronisation arrangements
    • H04W56/001—Synchronization between nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/50—Allocation or scheduling criteria for wireless resources
    • H04W72/54—Allocation or scheduling criteria for wireless resources based on quality criteria
    • H04W72/543—Allocation or scheduling criteria for wireless resources based on quality criteria based on requested quality, e.g. QoS

Definitions

  • This application relates to the fields of computer and communication technology, and more specifically, to a data transmission method, apparatus, computer-readable medium, and electronic device.
  • 5G 5th-Generation
  • 5G-A 5th-Generation
  • 6G 6th-Generation
  • high-bandwidth interactive services are important service types, such as cloud gaming, virtual reality (VR), augmented reality (AR), mixed reality (MR), extended reality (XR), cinematic reality (CR), XR and media services (XRM), etc.
  • High-bandwidth interactive services not only have very high requirements for transmission timeliness, but their service flows also typically include multiple media types, such as audio, video, haptic, or other media types.
  • the embodiments of this application provide a data transmission method, apparatus, computer-readable medium, and electronic device that can ensure that multiple QoS streams with synchronous transmission requirements can achieve the same transmission delay during transmission, avoiding the problem of asynchronous playback content caused by different QoS streams having different delays.
  • This application provides a data transmission method, including: determining whether multiple QoS streams have a synchronous transmission requirement; if it is determined that multiple QoS streams have a synchronous transmission requirement, allocating transmission resources to the multiple QoS streams according to the synchronous transmission requirement, so that the multiple QoS streams meet the synchronization requirement when transmitting based on the allocated transmission resources.
  • This application provides a data transmission apparatus, including: a determining unit configured to determine whether multiple Quality of Service (QoS) streams have a synchronous transmission requirement; and a processing unit configured to, if it is determined that multiple QoS streams have a synchronous transmission requirement, allocate transmission resources to the multiple QoS streams according to the synchronous transmission requirement, so that the multiple QoS streams meet the synchronization requirement when transmitting based on the allocated transmission resources.
  • QoS Quality of Service
  • This application provides a computer-readable medium having a computer program stored thereon, which, when executed by a processor, implements the data transmission method described above.
  • This application provides an electronic device, including: one or more processors; and a storage device for storing one or more computer programs, which, when executed by the one or more processors, cause the electronic device to implement the data transmission method described above.
  • This application provides a computer program product comprising a computer program stored in a computer-readable storage medium.
  • An electronic device's processor reads and executes the computer program from the computer-readable storage medium, causing the electronic device to perform the data transmission method described above.
  • Figure 1 illustrates a schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied;
  • Figure 2 illustrates a schematic diagram of the transmission process of multimedia data packets according to some embodiments of this application
  • Figure 3 illustrates a schematic diagram of data transmission via multiple QoS streams according to some embodiments of this application
  • Figure 4 shows a flowchart of a data transmission method according to some embodiments of this application.
  • Figure 5 shows a flowchart of a data transmission method according to some embodiments of this application.
  • Figure 6 illustrates a flowchart of a data transmission method according to some embodiments of this application.
  • Figure 7 shows a block diagram of a data transmission apparatus according to some embodiments of this application.
  • Figure 8 shows a schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application.
  • module refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof.
  • a processor or multiple processors or memory
  • each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.
  • cloud server 101 is used to run cloud games.
  • Cloud server 101 can render game screens, encode audio signals and rendered images, and finally transmit the encoded data obtained through the encoding process to various game clients via the network.
  • the game client can be a user equipment (UE) with basic streaming media playback capabilities, human-computer interaction capabilities, and communication capabilities, such as smartphones, tablets, laptops, desktop computers, smart TVs, smart home devices, in-vehicle terminals, aircraft, etc.; or the game client can be an application running on a terminal device.
  • the game client can decode the encoded data transmitted by cloud server 101 to obtain analog audio and video signals, and then play them.
  • Figure 1 is merely an exemplary representation of the system architecture of a cloud gaming system and does not limit the specific architecture of the cloud gaming system; for example, in other embodiments, the cloud gaming system may also include a backend server for scheduling, etc.
  • the cloud server 101 can be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.
  • the game client and the cloud server 101 can be directly or indirectly connected via wired or wireless communication, which is not limited herein.
  • the user plane mainly includes the application server, User Plane Function (UPF), next generation nodeB (gNB), and UE.
  • Multimedia data packet transmission in some typical service scenarios is mainly in the downlink direction, such as from the application server (AS) to the UPF, and then sent to the UE via the gNB.
  • the multimedia data packet (taking XR data packets as an example in Figure 2) is split at the application layer of the application server.
  • the 5G system transmits the sub-data packets to the UE through Protocol Data Unit (PDU) sessions.
  • PDU Protocol Data Unit
  • the sub-data packets are submitted level by level up from the protocol stack and reassembled to recover the multimedia data packet.
  • L1 refers to the physical layer, which is used to ensure that raw data can be transmitted over various physical media
  • L2 refers to the data link layer, which provides services to the network layer on the basis of the services provided by the physical layer
  • IP Internet Protocol
  • a single multimedia service frame or a group of packets may also form a large data packet, requiring a series of IP packets to carry it.
  • These IP packets have a certain correlation, and processing these messages based on this correlation can effectively save wireless network bandwidth. For example, assuming transmission is performed using multiple IP packets, these multiple IP packets can form a PDU set.
  • a single service stream typically contains multiple media types, such as audio, video, haptic, or other media types.
  • service streams of different media types may be mapped to different Quality of Service (QoS) streams.
  • QoS streams may have different transmission delays, such as the delay between the Radio Access Network (RAN) and the UPF. Consequently, when multiple QoS streams arrive at the receiving end through different transmission paths, it may cause a synchronization problem for service data of different media types when the receiving end generates media content based on the received multiple QoS streams for playback.
  • RAN Radio Access Network
  • the technical solution of this application proposes a new data transmission scheme.
  • transmission resources are allocated to these multiple QoS streams according to the synchronous transmission requirement, so that the multiple QoS streams meet the synchronization requirements (e.g., equal transmission delay) when transmitting based on the allocated transmission resources.
  • This can ensure that multiple QoS streams with synchronous transmission requirements can achieve the same transmission delay during transmission, avoiding the problem of different QoS streams having different delays and causing asynchronous playback content, which is beneficial to improving the user's experience of multimedia services.
  • FIG. 4 shows a flowchart of a data transmission method according to some embodiments of this application.
  • This data transmission method can be executed by an access network element, such as a base station device.
  • an access network element such as a base station device.
  • this data transmission method includes at least S410 to S420, which are described in detail below:
  • different media components of a multimedia service can be transmitted via differentiated QoS streams.
  • the media types of the multimedia service may include audio (latency-sensitive), video (bandwidth-sensitive), haptic (jitter-sensitive), or other media types.
  • Service data packets of different media types may have different QoS requirements, or they may have the same QoS requirements. If service data packets of different media types have different QoS requirements, then these different media type service data packets can be mapped to different QoS streams.
  • multimedia services can include cloud gaming, VR, AR, MR, XR, XRM, CR, etc.
  • Multimedia service data packets can be transmitted using a service data packet set (PDU set). This is because a single multimedia service frame or GOP-formed data packet may be quite large in size, requiring it to be split into a series of data packets for transport. These data packets have a certain correlation, hence the term PDU set.
  • the service data stream can also be transmitted per-packet.
  • cloud gaming services may contain audio data packets, video data packets, and haptic or other types of data packets. Since these multi-media data packets are associated with the same multimedia service, if they are mapped to different QoS streams during transmission, these QoS streams will be related. For example, there may be synchronous transmission requirements between these QoS streams, meaning that the latency between these QoS streams should be consistent or within a certain latency range.
  • an explicit indication parameter sent by a core network element can be received, and then the synchronization requirement between multiple QoS flows can be determined based on the explicit indication parameter. That is, in this embodiment, the synchronization requirement between multiple QoS flows is determined by an explicit indication parameter.
  • the explicit indication parameter may include a Multi-Modality Service ID (MMSID), which indicates that multiple QoS flows within the same PDU session are associated.
  • MMSID Multi-Modality Service ID
  • whether there is a synchronous transmission requirement between multiple QoS flows can be inferred based on implicit indication parameters. For example, QoS parameters at the PDU session level and QoS flow level can be analyzed from user equipment context information to infer whether there is a synchronous transmission requirement between multiple QoS flows.
  • QoS configuration is typically associated with specific session entities (such as EPS Bearers or 5GS QoS flows). These entities serve as the logical carriers for QoS policy implementation and implement differentiated services.
  • EPS Bearer is the basic unit of QoS configuration. All data flows on the same bearer have the same QoS configuration.
  • QoS flow is the basic unit of QoS configuration.
  • QoS parameters may include:
  • the priority parameter determines the processing order of data packets in the scheduling queue
  • MRR Maximum Bit Rate
  • GRR Guaranteed Bit Rate
  • a packet filter set is used to associate data packets in a network with specific QoS rules.
  • QoS rule identifiers (such as 5QI, ARP, etc.) are used to uniquely identify QoS rules.
  • the following steps can be taken: First, look up the QoS parameters associated with a specific session in the UE context, and then determine whether there is a synchronous transmission requirement between multiple QoS flows by analyzing the correlation of these parameters.
  • the determination of the synchronization relationship of multiple QoS streams can be achieved by parsing the QoS parameters at the QoS stream level.
  • QoS flow-level parameters may include: QoS Flow Identifier (QFI), QoS Class Identifier (5QI), Allocation and Retention Priority (ARP), Guaranteed Flow Bit Rate (GFBR), and Maximum Flow Bit Rate (MFBR), etc.
  • QFI QoS Flow Identifier
  • QI QoS Class Identifier
  • ARP Allocation and Retention Priority
  • GFBR Guaranteed Flow Bit Rate
  • MFBR Maximum Flow Bit Rate
  • QFI is used to identify QoS flow
  • 5QI is used to index a 5G QoS feature
  • different 5QI values represent different QoS categories
  • ARP parameters define the priority, preemption capability, and preemptibility of QoS flow
  • GBR QoS flow GFBR and MFBR represent the guaranteed bit rate and maximum bit rate, respectively.
  • QoS flows with the same 5QI value may have similar QoS processing; QoS flows with the same ARP parameters follow the same processing strategy during resource allocation; QoS flows with similar GFBR and MFBR values may have similar rate guarantee requirements.
  • This parameter correlation provides a technical basis for synchronization identification. Therefore, QoS parameters at the QoS flow level can be used to identify whether multiple QoS flows have synchronous transmission requirements. When multiple QoS flows exhibit the same or similar key parameters, it can be determined that they have service synchronization requirements. For example, QFI can be used to identify whether different QoS flows have the same ARP parameters or the same delay parameters. If they have the same or similar delay parameters, it indicates that the QoS flows have synchronous transmission requirements.
  • the corresponding QoS parameters may also include at least one of the following parameters: PDU Set Delay Budget (PSDB), PDU Set Error Rate (PSER), Maximum Data Burst Volume (MDBV), and Packet Delay Variation (PDV).
  • PSDB PDU Set Delay Budget
  • PSER PDU Set Error Rate
  • MDBV Maximum Data Burst Volume
  • PV Packet Delay Variation
  • the corresponding QoS parameters may also include at least one of the following parameters: Packet Delay Budget (PDB), Packet Error Rate (PER), and Maximum Data Burst Volume.
  • multiple QoS flows contained in the same PDU session can be directly identified as synchronization-related flows.
  • This implicit identification mechanism omits the parameter comparison process and directly identifies multiple QoS flows contained in the same PDU session as QoS flows with synchronization transmission requirements, without the need for other parameters to indicate this.
  • transmission resources are allocated to the multiple QoS streams according to the synchronous transmission requirement, so that the multiple QoS streams meet the synchronization requirement when transmitting based on the allocated transmission resources.
  • synchronous transmission parameters for the multiple QoS streams can be generated; wherein, for data streams using PDU set transmission mode, the synchronous transmission parameters include: PDU set delay budget; for data streams based on single packet transmission, the synchronous transmission parameters include: packet delay budget.
  • synchronization transmission requirements By converting synchronization transmission requirements into synchronization transmission parameters, abstract performance metrics can be transformed into specific, configurable parameters (such as AN-PDB or PSDB) to achieve flexible system control and optimization.
  • standardized delay parameters e.g., AN-PDB for non-PDU set scenarios
  • the system can explicitly define transmission delay thresholds, facilitating real-time detection and dynamic adjustment of resource allocation, thereby avoiding synchronization degradation caused by transmission jitter in the radio access network (e.g., from NG-RAN to the UE segment).
  • the solution in this application not only simplifies the maintenance of synchronization policies (e.g., no core logic reconstruction is required when modifying thresholds) but also supports serial expansion, adapting to the QoS requirements of different service scenarios.
  • a single Data Radio Bearer (DRB) can satisfy the synchronization requirements of all QoS streams, then the single DRB can be used to transmit multiple QoS streams, achieving precise time alignment by sharing radio resources. If the same DRB cannot satisfy the synchronization requirements of all QoS streams, then independent DRBs can be allocated to each QoS stream so that the synchronization requirements are met when multiple QoS streams are transmitted based on different DRBs.
  • DRB Data Radio Bearer
  • FIG. 5 shows a flowchart of a data transmission method according to some embodiments of this application.
  • This data transmission method can be executed by an access network element, such as a base station device.
  • an access network element such as a base station device.
  • the technical solution of the embodiment shown in Figure 5 can also be executed by other electronic devices with computing processing capabilities.
  • this data transmission method in addition to S410 to S420 shown in Figure 4, also includes S430 and S440, which are described in detail below:
  • TM Transparent Mode
  • AM Acknowledged Mode
  • UM Unacknowledged Mode
  • AM Acknowledged Mode
  • AM is a more reliable transmission mode.
  • AM the sender waits for confirmation from the receiver after sending data to ensure correct reception. If the receiver doesn't receive the data or the data is incorrect, it sends a Negative Acknowledgement (NACK) message to the sender, requesting retransmission. This mechanism ensures data integrity and accuracy but also increases transmission latency.
  • NACK Negative Acknowledgement
  • differentiated delay detection schemes are provided for different transmission modes.
  • UM Unacknowledged Mode
  • the uplink and downlink bidirectional latency measurements can be performed by that RLC instance.
  • different measurement modes can be configured to meet the synchronous transmission requirements of different service types: measurement by data packet is suitable for services sensitive to latency jitter; measurement by transport block (TB) is suitable for high-volume services, and batch processing can reduce measurement overhead.
  • the transmission delay difference between data packets of multiple QoS streams is within a set threshold, it can be determined that the multiple QoS streams can meet the synchronization requirements during transmission; if the transmission delay difference between data packets of multiple QoS streams is not within the set threshold, it can be determined that the multiple QoS streams cannot meet the synchronization requirements during transmission.
  • the technical solution of this embodiment can ensure that the transmission delay difference of multiple QoS streams is considered to be synchronized when it is within a certain range, avoiding the problem of misjudgment caused by latency jitter.
  • the synchronization state of the QoS streams can be characterized by multiple state transitions of a state machine. For example, based on the delay detection results of multiple QoS streams, different states of the state machine can indicate whether the multiple QoS streams can meet the synchronization requirements during transmission; wherein, the state machine includes a synchronized state and an asynchronous state.
  • the state machine can also include other states, such as an impending asynchronous state, a slightly asynchronous state, a severely asynchronous state, etc.
  • local resource adjustments are first made to allocate more transmission resources to high-latency QoS flows or switch to less busy transmission links to reduce the latency of the QoS flows.
  • core network collaborative optimization can be initiated by sending notification messages to core network elements to enable them to adjust the transmission parameters for multiple QoS flows. For example, core network elements can adjust the QoS parameters for multiple QoS flows through a PDU session modification procedure.
  • the technical solution of this application mainly targets end-to-end XRM service flows.
  • the NG-RAN Next Generation Radio Access Network
  • the synchronization relationship between QoS flows is identified.
  • QoS flows with synchronization relationships can achieve equal transmission latency during transmission in the NG-RAN.
  • the steps may include:
  • NG-RAN determines whether multiple QoS flows have synchronous transmission requirements, and when it is determined that multiple QoS flows have synchronous generation requirements, the synchronous transmission requirements are converted into parameters.
  • the synchronization requirements of multiple QoS streams can be explicitly determined based on parameters provided by the core network.
  • the MMSID defined in 3GPP SA2 R18 is a parameter used to identify the relationships between multiple media streams in XRM (Extended Reality Media) services.
  • This parameter can logically bind multimedia streams (such as audio, video, haptic feedback, etc.) belonging to the same service scenario through a unified service identifier, and can explicitly indicate the synchronization requirements between different streams, such as the strict timing alignment requirements between video streams and motion sensor data in VR scenarios.
  • the network side needs to treat streams marked with the same MMSID as an indivisible whole for resource allocation.
  • this parameter has certain limitations. Its original intention was to indicate the dependency between different streams, and the network should not accept or reject a part of it when allocating and scheduling transmission resources, but should treat it as a whole.
  • this parameter to indicate synchronization needs to be based on the following two assumptions: different QoS streams with synchronization dependencies can only belong to the same PDU session, and all streams within the same XRM service adopt a unified synchronization level.
  • the synchronization requirements of multiple QoS flows can be implicitly inferred.
  • This method avoids introducing new indication parameters into the AF and core network, instead analyzing the synchronization between different QoS flows by analyzing control plane or user plane entities.
  • implicit inference may include, but is not limited to, parsing QoS parameters (e.g., latency sensitivity and reliability metrics in QoS parameters) or extracting information from the UE context (e.g., QoS parameters at the PDU session level and QoS flow level in the UE context).
  • This scheme which infers QoS flow synchronization transmission requirements through implicit parameters, avoids explicit signaling overhead, utilizes the existing QoS parameter system to derive synchronization requirements, maintains compatibility with the existing 5G QoS framework, and requires no modification to the core network architecture.
  • NG-RAN can analyze QoS parameters at the session level and QoS flow level from the UE context stored in the gNB to analyze whether there is a synchronous transmission requirement between different QoS flows.
  • NG-RAN can automatically determine multiple flows within a UE's PDU session as having synchronous transmission requirements when the core network only declares synchronous transmission requirements without specifying which QoS flows need to be synchronous.
  • synchronization transmission requirements can be translated into PDB parameters, such as AN-PDB (corresponding to non-PDU set) parameters or PSDB parameters (corresponding to PDU set).
  • AN-PDB is used for independent data streams of non-PDU sets, defining the maximum allowable delay threshold for data packets from the application layer sender to the receiver.
  • PSDB parameters are used for PDU sets (such as XR multimodal service flow groups), setting the cooperative transmission delay budget for the entire group of data packets. Unified resource scheduling ensures that the time difference of data packets from all flows within the group at the receiver does not exceed the threshold.
  • NG-RAN uses one or more DRBs for data transmission and detects the transmission delay of each QoS stream.
  • multiple QoS streams can be transmitted using a single DRB to ensure synchronization when any of the following conditions are met:
  • PDB metric PDU metric
  • the NG-RAN assessment confirmation sheet can meet the QoS requirements of all QoS flows.
  • the same DRB provides consistent underlying transport characteristics (such as scheduling priority and HARQ mechanism) for all QoS flows carried, thereby naturally maintaining inter-flow latency consistency.
  • NG-RAN may employ independent DRB transmission when different QoS flows exhibit the following characteristics:
  • QoS parameter conflict The latency requirements are the same, but the reliability metrics (PER) do not match, that is, the reliability metrics are different between different QoS flows; other key parameters (such as jitter tolerance) cannot be met simultaneously by a single DRB.
  • PER reliability metrics
  • other key parameters such as jitter tolerance
  • the base station in order to ensure that different QoS streams can meet the same latency index, the base station needs to perform latency detection on multiple QoS streams with synchronous transmission requirements.
  • the latency measurement in RLC UM mode, if it is an uplink (UL) transmission, the latency measurement can be performed by the receive (RX) RLC instance; if it is a downlink (DL) transmission, the latency measurement can be performed by the transmit (TX) RLC instance.
  • RX receive
  • TX transmit
  • the sequence number latency change trend of the RLC instance can be used to analyze whether multiple QoS flow service flows can meet the synchronization requirements.
  • S603 will trigger a reporting mechanism and modify QoS parameters.
  • NG-RAN if NG-RAN detects that the transmission between multiple QoS flows can meet the synchronization requirements, the transmission can continue; if the synchronization requirements cannot be met, NG-RAN can adjust the resource transmission algorithm to make the multiple QoS flows meet the synchronization requirements. If the synchronization requirements still cannot be met within a set time period, a notification message can be sent to the 5G core network (5G Core, 5GC) so that 5GC can trigger the update of QoS flow parameters after receiving the notification.
  • 5G Core 5G Core
  • the 5GC can also send the notification to the AF, which can then make adaptive adjustments.
  • the AF can regenerate QoS requirement information for multiple QoS flows and send it to the core network element to adjust the processing strategy for multiple QoS flows.
  • the detection of transmission delays of multiple QoS streams and the determination of whether synchronization requirements are met can be performed in the following ways:
  • Packet-level inspection Measure the latency of each data packet and determine its synchronization.
  • MAC TB-level detection Perform latency detection and synchronization judgment during each MAC TB transmission.
  • the synchronization requirement judgment can be designed as a state machine or threshold judgment, and implemented in the user plane RLC or MAC instance.
  • a threshold when making threshold judgments, a threshold can be set. When the delay of data packet transmission is within the threshold range, it can be considered that the synchronization requirements are met and the reporting process will not be triggered. If the delay of data packet transmission exceeds the threshold range, it is considered that the synchronization requirements are not met and the reporting process needs to be triggered.
  • a state machine When making judgments using a state machine, a state machine can be designed, including two states: synchronous and asynchronous, or it can contain other states. Transition conditions between each state can be set to dynamically follow the changes in the state.
  • the state machine approach and the threshold-based approach can be implemented in combination or separately.
  • the technical solution of this application proposes a novel data transmission scheme that enables NG-RAN base stations to identify the synchronization relationship between QoS streams. By selecting appropriate radio resources for different QoS streams, it ensures that QoS streams with synchronization relationships can achieve equal transmission latency during transmission in NG-RAN.
  • the technical solution of this application can solve the problem that when multimedia streams are mapped into multiple QoS streams, the different latency caused by the transmission of these multiple QoS streams in 5G/6G networks affects the user experience of multimedia services at the receiving end.
  • Figure 7 shows a block diagram of a data transmission apparatus according to some embodiments of the present application.
  • the data transmission apparatus can be applied to access network elements, such as base station equipment.
  • the data transmission apparatus shown in Figure 7 can also be applied to other electronic devices with computing processing functions.
  • a data transmission apparatus 700 includes: a determination unit 702 and a processing unit 704.
  • the determining unit 702 is configured to determine whether multiple QoS flows have a synchronous transmission requirement; the processing unit 704 is configured to allocate transmission resources to the multiple QoS flows according to the synchronous transmission requirement when it is determined that there is a synchronous transmission requirement among the multiple QoS flows, so that the multiple QoS flows meet the synchronization requirement when transmitting based on the allocated transmission resources.
  • FIG 8 shows a schematic diagram of a computer system suitable for implementing an electronic device according to the embodiments of this application.
  • the electronic device may be an access network element in the foregoing embodiments, such as a base station device.
  • the computer system 800 may include a Central Processing Unit (CPU) 801, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 802 or programs loaded from storage portion 808 into Random Access Memory (RAM) 803, such as performing the methods described in the above embodiments.
  • the RAM 803 also stores various programs and data required for system operation.
  • the CPU 801, ROM 802, and RAM 803 are interconnected via a bus 804.
  • An Input/Output (I/O) interface 805 is also connected to the bus 804.
  • I/O interface 805 The following components can be connected to I/O interface 805: an input section 806 including a keyboard, mouse, etc.; an output section 807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 808 including a hard disk, etc.; and a communication section 809 including a network interface card such as a LAN (Local Area Network) card, modem, etc.
  • the communication section 809 performs communication processing via a network such as the Internet.
  • a drive 810 is also connected to I/O interface 805 as needed.
  • Removable media 811 such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 810 as needed so that computer programs read from them can be installed into storage section 808 as needed.
  • embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium for performing the methods shown in the flowcharts.
  • the computer program can be downloaded and installed from a network via communication section 809, and/or installed from removable medium 811.
  • CPU central processing unit
  • the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two.
  • a computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.
  • a computer-readable storage medium can be any tangible medium containing or storing a computer program that can be used by or in conjunction with an instruction execution system, apparatus, or device.
  • a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program.
  • the transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof.
  • the computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device.
  • the computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.
  • each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function.
  • the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved.
  • each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and a computer program.
  • the units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor.
  • the names of these units do not necessarily limit the specific unit itself.
  • this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device.
  • the computer-readable medium carries one or more computer programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.
  • the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause an electronic device to execute the method according to the embodiments of this application.
  • the electronic device can be an access network element, and the access network element can execute the data transmission method shown in Figures 4 and 5.

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

本申请的实施例提供了一种数据传输方法、装置、计算机可读介质及电子设备。该数据传输方法包括：确定多个服务质量QoS流是否具有同步传输需求；若确定所述多个QoS流具有同步传输需求，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。

Description

数据传输方法、装置、计算机可读介质及电子设备
本申请要求于2024年8月1日提交中国专利局、申请号为202411057354X，发明名称为“数据传输方法、装置、计算机可读介质及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机及通信技术领域，具体而言，涉及一种数据传输方法、装置、计算机可读介质及电子设备。
背景技术
在第五代移动通信技术(5th-Generation，5G)及其后续演进系统(如5G-A、6G等)中，高带宽的交互型业务是重要的业务类型，诸如云游戏(Cloud gaming)、虚拟现实(Virtual Reality，VR)、增强现实(Augmented Reality，AR)、混合现实(Mixed Reality，MR)、扩展现实(Extended Reality，XR)、影像现实(Cinematic Reality，CR)、XR和媒体服务(XR and Media Services，XRM)等。
这些高带宽的交互型业务不仅对传输时效性要求很高，而且这种业务的业务流通常会包含多种媒体类型，比如音频(audio)、视频(video)和触觉(haptic)或其他媒体类型。。
技术内容
本申请的实施例提供了一种数据传输方法、装置、计算机可读介质及电子设备，可以确保存在同步传输需求的多个QoS流在传输过程中可以实现同等的传输延迟，避免了不同的QoS流有不同的时延而导致播放内容不同步的问题。
本申请的其它特性和优点将通过下面的详细描述变得显然，或部分地通过本申请的实践而习得。
本申请实施例提供了一种数据传输方法，包括：确定多个服务质量QoS流是否具有同步传输需求；若确定多个QoS流具有同步传输需求，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。
本申请实施例提供了一种数据传输装置，包括：确定单元，配置为确定多个服务质量QoS流是否具有同步传输需求；处理单元，配置为若确定多个QoS流具有同步传输需求，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。
本申请实施例提供了一种计算机可读介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的数据传输方法。
本申请实施例提供了一种电子设备，包括：一个或多个处理器；存储装置，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现如上述的数据传输方法。
本申请实施例提供了一种计算机程序产品，该计算机程序产品包括计算机程序，该计算机程序存储在计算机可读存储介质中。电子设备的处理器从计算机可读存储介质读取并执行该计算机程序，使得该电子设备执行上述的数据传输方法。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图简要说明
图1示出了可以应用本申请实施例的技术方案的示例性系统架构的示意图；
图2示出了根据本申请的一些实施例的多媒体数据包的传输过程示意图；
图3示出了根据本申请的一些实施例的通过多个QoS流进行数据传输的示意图；
图4示出了根据本申请的一些实施例的数据传输方法的流程图；
图5示出了根据本申请的一些实施例的数据传输方法的流程图；
图6示出了根据本申请的一些实施例的数据传输方法的流程图；
图7示出了根据本申请的一些实施例的数据传输装置的框图；
图8示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。
具体实施方式
现在参考附图以更全面的方式描述示例实施方式。然而，示例的实施方式能够以各种形式实施，且不应被理解为仅限于这些范例；相反，提供这些实施方式的目的是使得本申请更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。
此外，本申请所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施例中。在下面的描述中，有许多具体细节从而可以充分理解本申请的实施例。然而，本领域技术人员应意识到，在实施本申请的技术方案时可以不需用到实施例中的所有细节特征，可以省略一个或更多特定细节，或者可以采用其它的方法、元件、装置、步骤等。
本申请实施例中，术语“模块”或“单元”是指有预定功能的计算机程序或计算机程序的一部分，并与其他相关部分一起工作以实现预定目标，并且可以通过使用软件、硬件(如处理电路或存储器)或其组合来全部或部分实现。同样的，一个处理器(或多个处理器或存储器)可以用来实现一个或多个模块或单元。此外，每个模块或单元都可以是包含该模块或单元功能的整体模块或单元的一部分。
附图中所示的方框图仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
附图中所示的流程图仅是示例性说明，不是必须包括所有的内容和操作/步骤，也不是必须按所描述的顺序执行。例如，有的操作/步骤还可以分解，而有的操作/步骤可以合并或部分合并，因此实际执行的顺序有可能根据实际情况改变。
需要说明的是：在本文中提及的“多个”是指两个或两个以上。“和/或”描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。
随着5G及其后续演进系统(如5G-A、6G等)的发展，使得许多要求多数据量、短时延的多媒体业务得到了应用。比如云游戏业务、VR、AR、MR、XR、CR等交互业务。
例如，在图1所示的云游戏场景中，云端服务器101用于运行云游戏，云端服务器101可以对游戏画面进行渲染，并将音频信号及渲染后的图像进行编码处理，最后将编码处理得到的编码数据通过网络传输至各个游戏客户端。游戏客户端可以是具有基本的流媒体播放能力、人机交互能力以及通信能力等的用户设备(User Equipment，UE)，例如，智能手机、平板电脑、笔记本电脑、台式计算机、智能电视、智能家居、车载终端、飞行器等；或者该游戏客户端可以是运行于终端设备中的应用程序。具体的，游戏客户端可以将云端服务器101传输的编码数据进行解码，得到模拟音视频信号，并进行播放。
应理解的是，图1中只是示例性的表征云游戏系统的系统架构，并不对云游戏系统的具体架构进行限定；例如在其它实施例中，云游戏系统中还可包括用于调度的后台服务器等等。并且云端服务器101可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(Content Delivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器。游戏客户端以及云端服务器101可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。
在上述的各种基于多媒体的交互业务应用场景中，由于多媒体数据包巨大，因此在传输时需要拆分为多个数据包进行传输。具体而言，如图2所示，以5G系统为例，用户面主要包括应用服务器、用户面功能(User Plane Function，UPF)、基站(next generation nodeB，gNB)和UE。多媒体数据包的传输对于一些典型业务场景主要在下行方向，比如从应用服务器(Application Server，AS)到UPF，然后再通过gNB发送给UE。在进行传输时，多媒体数据包(在图2中以XR数据包为例)在应用服务器的应用层进行拆分，拆分后的数据包作为IP包从应用服务器到达UPF后，5G系统通过协议数据单元(Protocol Data Unit，PDU)会话把子数据包传输到UE端，在UE端从协议栈逐级向上递交并进行重组恢复出该多媒体数据包。
其中，在图2所示的系统中，L1层是指物理层，其用于确保原始的数据可在各种物理媒体上传输；L2层指的是数据链路层，数据链路层在物理层提供的服务的基础上向网络层提供服务；网际互联协议(Internet Protocol，IP)层即为网络层，用于实现两个端系统之间的数据传送。
如前所述，对多媒体业务(比如XRM业务)来说，把一帧多媒体数据包分成多个数据包传输是很常见的情况，单个多媒体业务帧或者数据包组(Group of Packets，GoP)形成的数据包也可能字节量比较大，需要由一系列IP数据包来承载。这些IP数据包之间存在一定的相关性，根据相关性来处理这些报文能够有效节省无线网络带宽。举例来说，假设在进行传输时通过多个IP数据包进行传输，这多个IP数据包可以组成PDU set(PDU集合)。
同时，在多媒体业务(比如XRM业务)的业务中，单一业务流通常会包含多种媒体类型，比如音频(audio)、视频(video)和触觉(haptic)或其他媒体类型。如图3所示，在进行传输时，为了保障服务质量，不同媒体类型的业务流可能会映射到不同的服务质量(Quality of Service，QoS)流(flow)上，而不同的QoS流在传输时可能会有不同的时延，比如无线接入网(Radio Access Network，RAN)与UPF之间的时延，进而当多QoS流通过不同传输路径到达接收端时，可能造成接收端在根据接收到的多个QoS流生成媒体内容进行播放时，出现不同媒体类型的业务数据不同步的问题。
正是基于上述问题，本申请实施例的技术方案提出了一种新的数据传输方案，可以在确定多个QoS流之间具有同步传输需求时，根据该同步传输需求为这多个QoS流分配传输资源，以使这多个QoS流基于所分配的传输资源进行传输时满足同步要求(例如，同等的传输时延)，这样可以确保存在同步传输需求的多个QoS流在传输过程中可以实现同等的传输延迟，避免了不同的QoS流有不同的时延而导致播放内容不同步的问题，有利于提升用户对于多媒体业务的使用体验。
以下对本申请实施例的技术方案的实现细节进行详细阐述：
图4示出了根据本申请的一些实施例的数据传输方法的流程图，该数据传输方法可以由接入网网元来执行，比如可以由基站设备来执行，当然图4所示实施例的技术方案也可以由其它具有计算处理功能的电子设备来执行。参照图4所示，该数据传输方法至少包括S410至S420，详细介绍如下：
在S410中，确定多个服务质量QoS流是否具有同步传输需求。
在一些实施例中，多媒体业务(例如云游戏/XR业务)的不同媒体组件可以通过差异化QoS流传输。多媒体业务的媒体类型可以包括音频(audio)(时延敏感)、视频(video)(带宽敏感)和触觉(haptic)(抖动敏感)或其他媒体类型等，不同媒体类型的业务数据包可能具有不同的QoS需求，也可能具有相同的QoS需求。如果不同媒体类型的业务数据包具有不同的QoS需求，那么这些不同媒体类型的业务数据包可以映射到不同的QoS流上。
需要说明的是，多媒体业务比如可以是云游戏业务、VR业务、AR业务、MR业务、XR业务、XRM业务、CR业务等。多媒体业务的数据包可以采用业务数据包集合(即PDU set)的方式进行传输，这是由于单个多媒体业务帧或者GoP形成的数据包可能字节量比较大，需要拆分为一系列的数据包来进行承载，而这些数据包之间具有一定的相关性，因此可以将这些具有相关性的数据包称之为PDU set。在本申请的其它实施例中，业务数据流也可以采用逐个业务数据包(即per-packet)的方式进行传输。
以云游戏业务为例，云游戏业务中可能包含有音频类型的业务数据包、视频类型的业务数据包，也可能包含有触觉或其他类型的业务数据包等，这多种媒体类型的业务流数据包由于是关联至同一个多媒体业务，因此在进行传输时如果被映射到不同的QoS流上，那么这些QoS流是存在关联关系的，比如这些QoS流之间存在同步传输要求，即这些QoS流之间的延迟应该保持一致或者处于一定的时延范围内。
在一些实施例中，可以通过接收核心网网元发送的显式指示参数，然后根据该显式指示参数确定多个QoS流之间是否具有同步传输需求。即该实施例中是通过显式指示参数的方式来确定多个QoS流具有同步传输需求。在一些实施例中，该显式指示参数可以包括多模态服务标识(Multi-Modality Service ID，MMSID)，该多模态服务标识用于指示同一个PDU会话内的多个QoS流具有关联关系。
在一些实施例中，可以根据隐式指示参数推断多个QoS流之间是否具有同步传输需求。比如，可以从用户设备相关的上下文信息(UE context)中分析会话级(PDU session level)和QoS流级(QoS flow level)的QoS参数，来推断多个QoS流之间是否具有同步传输需求。
具体而言，QoS的配置通常与特定的会话实体(如EPS Bearer或5GS QoS流)相关联，这些实体作为QoS策略实施的逻辑载体，承载着差异化服务的功能。例如，在4G系统中，EPS承载(EPS Bearer)是QoS配置的基本单元。相同承载上的所有数据流均具有相同的QoS配置。在5G系统中，QoS流作为QoS配置的基本单元。QoS参数可能包括：
优先级参数，用于决定数据包在调度队列中的处理顺序；
速率控制参数，如最大比特率(Maximum Bit Rate，MBR)、保证比特率(Guaranteed Bit Rate，GBR)等，用于控制数据传输的速度；
包过滤器集(Packet Filter Set)，用于将网络中的数据包与特定的QoS规则关联起来；
QoS规则标识符(如5QI、ARP等)，用于唯一标识QoS规则。
在通过UE context中包含的会话级参数确定QoS流之间是否具有同步传输需求时，可以执行以下操作：首先，在UE Context中查找与特定会话相关联的QoS参数，然后通过分析这些参数的关联性判定多个QoS流之间是否具有同步传输需求。
在一些实施例中，在根据隐式指示参数进行同步性识别时，可以通过解析QoS流级别的QoS参数来实现多QoS流同步关系的判定。
具体而言，QoS流作为PDU会话中最精细的QoS区分单元，其配置和管理依赖于一组标准化的QoS参数，这些参数不仅定义了单个QoS流的服务特性，还隐式地揭示了不同QoS流之间的潜在关联性。QoS流级别的QoS参数可能包含有：QoS流标识(QoS Flow Identifier，QFI)、QoS类别标识符(QoS Class Identifier，5QI)、分配和保留优先级(Allocation and Retention Priority，ARP)、保证流比特率(Guaranteed Flow Bit Rate，GFBR)和最大流比特率(Maximum Flow Bit Rate，MFBR)等。
其中，QFI用于标识QoS流；5QI用于索引一个5G QoS特性，不同的5QI值代表不同的QoS类别，ARP参数定义了QoS流的优先级、抢占能力和可被抢占性，GBR QoS流，GFBR和MFBR分别表示保证的比特率和最大比特率。
参数间的关联性体现在：具有相同5QI值的QoS流在QoS处理上可能具有相似性；具有相同ARP参数的QoS流在资源分配时遵循相同的处理策略；具有相似GFBR和MFBR值的QoS流可能具有相似的速率保障需求。这种参数关联性为同步性识别提供了技术基础。因此可以基于QoS流级别的QoS参数来识别多个QoS流之间是否具有同步传输需求，当多个QoS流展示出相同或近似的关键参数时，即可判定它们存在业务同步需求。比如根据QFI来识别不同的QoS流是否具有相同的ARP参数或者是否具有相同的延迟参数等，如果具有相同或近似的延迟参数，那么说明QoS流之间具有同步传输需求。
在一些实施例中，除了上述的QoS参数之外，对于通过PDU set的方式进行传输的业务数据而言，其对应的QoS参数也可以包括如下参数中的至少一个：PDU集合延迟预算(PDU Set Delay Budget，PSDB)、PDU集合误码率(PDU Set Error Rate，PSER)、最大数据突发量(Maximum Data Burst Volume，MDBV)、包时延变化/抖动(Packet Delay Variation，PDV)。对于采用单个数据包(per-packet)的形式来进行传输的业务数据而言，其对应的QoS参数也可以包括如下参数中的至少一个：数据包延迟预算(Packet Delay Budget，PDB)、数据包丢包率(Packet Error Rate，PER)、最大数据突发量等。
在一些实施例中，在核心网网元指示了同步性要求的情况下，可以直接将同一个PDU会话中包含的多个QoS流识别为同步关联流。这种隐式识别机制省略了参数比对过程，直接将同一个PDU会话中包含的多个QoS流识别为具有同步传输需求的QoS流，无需其它参数进行指示。
继续参照图4所示，在S420中，若确定多个QoS流具有同步传输需求，则根据该同步传输需求为多个QoS流分配传输资源，以使多个QoS流基于所分配的传输资源进行传输时满足同步要求。
在一些实施例中，如果确定多个QoS流存在同步传输需求，那么可以生成针对多个QoS流的同步传输参数；其中，对于采用PDU集合传输模式的数据流，该同步传输参数包括：PDU集合延迟预算；对于基于单包传输的数据流，该同步传输参数包括：数据包延迟预算。
通过将同步传输需求转换为同步传输参数，可以将抽象的性能指标转化为具体、可配置的参数(如AN-PDB或PSDB)，以实现系统的灵活控制与优化。通过将同步传输需求量化为标准化的延迟参数(例如AN-PDB用于非PDU set场景)，系统能够明确定义传输延迟阈值，便于实时检测和动态调整资源分配，从而避免因无线接入网(如NG-RAN到UE段)的传输抖动导致同步性劣化。本申请实施例的方案不仅简化了同步策略的维护(如修改阈值时无需重构核心逻辑)，还支持系列化扩展，可适配不同业务场景的QoS需求。
在一些实施例中，在根据同步传输需求为多个QoS流分配传输资源时，当通过单一数据无线承载(Data Radio Bearer，DRB)能够满足所有QoS流的同步传输需求，那么可以使用单一数据无线承载传输多个QoS流，通过共享无线资源实现精确的时间对齐。如果通过同一个DRB不能够满足所有QoS流的同步传输需求，那么可以为各个QoS流分配独立的数据无线承载，以使多个QoS流基于不同的数据无线承载进行传输时满足同步传输需求。
图5示出了根据本申请的一些实施例的数据传输方法的流程图，该数据传输方法可以由接入网网元来执行，比如可以由基站设备来执行，当然图5所示实施例的技术方案也可以由其它具有计算处理功能的电子设备来执行。参照图5所示，该数据传输方法在包含图4所示的S410至S420的基础上，还包括S430和S440，详细介绍如下：
在S430中，在根据同步传输需求为多个QoS流分配传输资源之后，对多个QoS流的传输过程进行延迟检测。
需要说明的是，数据包在传输时一般分为透明模式(Transparent Mode，TM)、确认模式(Acknowledged Mode，AM)和非确认模式(Unacknowledged Mode，UM)。其中，在透明模式TM下，传输数据的设备或者系统对于传输的数据来说是“透明的”，即不对数据的内容进行任何修改或处理。在非确认模式UM下发送数据时不需要等待接收方的确认，发送方发送数据后不会等待接收方的任何反馈，因此数据传输的效率相对较高，适用于对实时性要求较高但对数据传输准确性要求相对较低的场景。确认模式AM则是一种更为可靠的传输模式。在AM模式下，发送方在发送数据后需要等待接收方的确认消息，以确保数据被正确接收。如果接收方没有收到数据或数据有误，它会向发送方发送一个否定确认(NACK)消息，请求发送方重新发送数据，这种机制可以确保数据的完整性和准确性，但相应地也会增加一些传输延迟。
在一些实施例中，针对不同的传输模式，提供了差异化的延迟检测方案。对于采用非确认模式(UM)的QoS流，上行方向由接收端RLC实例执行延迟测量，下行方向由用于发送端RLC实例执行延迟测量。
在一些实施例中，对于采用确认模式(AM)的QoS流，由于收发共用一个RLC实例，因此可以由该RLC实例执行上下行双向的延迟测量。
在一些实施例中，针对不同业务类型的同步传输需求，可以配置不同的测量模式：以数据包为单位测量，适用于对时延抖动敏感的业务；以传输块(Transport Block，TB)为单位测量，适合大流量业务，通过批量处理可以降低测量开销。
在一些实施例中，如果多个QoS流的数据包之间的传输延迟差在设定的阈值内，则可以确定多个QoS流在传输时能够满足同步要求；若多个QoS流的数据包之间的传输延迟差不在设定的阈值内，则确定多个QoS流在传输时不能满足同步要求。该实施例的技术方案可以确保多个QoS流的传输延迟差在一定范围内时就认定为是同步的，避免时延抖动而带来误判的问题。
在一些实施例中，在对多个QoS流的传输过程进行延迟检测时，可以通过状态机的多状态转换表征QoS流的同步状态，比如可以根据对多个QoS流的延迟检测结果，通过状态机的不同状态指示多个QoS流在传输时是否能够满足同步要求；其中，状态机包括同步状态和不同步状态。当然，状态机也可以包括其它状态，比如即将不同步状态、轻微不同步状态、严重不同步状态等。
在S440中，若检测到多个QoS流在传输时不能满足同步要求，则调整针对多个QoS流的传输资源分配。
在一些实施例中，首先进行本地资源调整，为高延迟QoS流分配更多的传输资源或者切换至较为空闲的传输链路等，以降低该QoS流的延迟。在一些实施例中，若经过设定时长之后，多个QoS流仍然不能满足同步要求，则可以启动核心网协同优化，向核心网网元发送通知消息，以使核心网网元调整针对多个QoS流的传输参数。比如核心网网元可以通过PDU会话修改流程来调整针对多个QoS流的QoS参数等。
以下结合图6，以5G系统处理XRM业务为例对本申请实施例的技术方案的实现细节进行详细阐述：
本申请实施例的技术方案主要是针对端到端的XRM业务流，在NG-RAN(Next Generation Radio Access Network)基站识别QoS流之间的同步性关系，通过为不同的QoS流选择合适的无线资源，使得存在同步性关系的QoS流之间能够在NG-RAN中的传输过程中实现同等的传输延迟。具体参照图6所示，可以包括如下步骤：
S601，在PDU会话及QoS流建立/修改之后，NG-RAN确定多个QoS流是否具有同步传输需求，并在确定多个QoS流具有同步产生需求时，将所述同步传输需求转化为参数。
在一些实施例中，可以基于核心网提供的参数显式地确定多个QoS流的同步传输要求。
具体而言，第三代合作伙伴计划(The 3rd Generation Partnership Project，3GPP)SA2 R18定义的MMSID用于标识XRM(扩展现实媒体)业务中多个媒体流之间的关联关系的参数，该参数可以通过统一的服务标识符将属于同一业务场景的多媒体流(如音频、视频、触觉反馈等)进行逻辑绑定，可以明确指示不同流之间的同步性需求，例如VR场景中视频流与运动传感器数据的严格时序对齐要求。网络侧需将标记为同一MMSID的流视为不可分割的整体进行资源分配。但是该参数具有一定的局限性，其引入的本意是指示不同流之间有依赖性，网络在分配和调度传输资源时，不能接受或者拒绝其中的一部分，而是应该作为一个整体。因此，该参数用于指示同步性需要基于以下两个假设：具有同步性依赖的不同QoS流只能属于同一个PDU会话、同一个XRM业务内的所有流采用统一的同步等级。
在一些实施例中，可以隐式推断多个QoS流的同步需求，这种方法可以不在AF以及核心网引入新的指示参数，而是通过分析控制面或者用户面实体，分析不同QoS流之间的同步性。比如，隐式推断可以包括但不限于：通过解析QoS参数(例如，QoS参数中的时延敏感度)和可靠性指标)或者提取UE context中的信息(例如UE上下文中的PDU会话级和QoS流级的QoS参数)。这种通过隐式参数推断QoS流同步传输需求的方案，可以避免显式信令开销，利用现有QoS参数体系实现同步需求推导，保持与现有5G QoS框架兼容，无需修改核心网架构。
具体而言，NG-RAN可以从gNB存储的UE context中分析session level和QoS flow level的QoS参数，以分析不同的QoS流间是否有同步传输需求。或者，NG-RAN可以在核心网仅声明同步传输需求但没有具体指明哪些QoS流需要具有同步性的情况下，自动将一个UE的PDU session内的多个流判定为具有同步传输需求。
在一些实施例中，同步传输需求可以转化为PDB参数，如AN-PDB(对应于非PDU set)参数或者PSDB参数(对应于PDU set)。其中，AN-PDB用于非PDU集合的独立数据流，定义数据包从应用层发送端到接收端允许的最大时延阈值。将同步传输需求对应为AN-PDB参数的考虑是：假设数据包在到达NG-RAN时能够满足同步性要求，不会因为NG-RAN与UE之间的传输，进一步导致同步性变差。PSDB参数用于PDU集合(如XR多模态业务流组)，设定整组数据包的协同传输时延预算。通过统一资源调度确保组内所有流的数据包在接收端的时间差不超过阈值。
S602，NG-RAN使用一个或者多个DRB进行数据传输，并检测各QoS流的传输延迟。
在一些实施例中，当满足以下任一条件时，可以采用单一DRB传输多个QoS流以确保同步性：
多个QoS流具有相同的5QI；
共享相同的时延预算参数(PDB指标，或者PDU指标)；
具备匹配的PER指标或MDBV指标；
NG-RAN评估确认单DRB可以满足所有QoS流的QoS要求。
同一DRB为承载的所有QoS流提供一致的底层传输特性(如调度优先级、HARQ机制)，从而天然维持流间延迟一致性。
在一些实施例中，当不同QoS流存在以下特征差异时，NG-RAN可以采用独立DRB传输：
业务类型差异：包括不同的XRM media stream/type(如视频/触觉反馈分离)，归属不同的PDU set且PDU set的重要性信息(PDU set importance，PSI)不一致；
QoS参数冲突：延迟需求相同但是可靠性指标(PER)不匹配，即不同的QoS流之间可靠性指标不一样；其他关键参数(如抖动容限)无法通过单DRB同时满足。
通过使用不同的DRB传输多个QoS流，实现了差异化调度策略，避免可靠性要求冲突。
在一些实施例中，为了保证不同的QoS流能够满足相同的延迟指标，基站需要对具有同步传输需求的多个QoS流进行延迟检测。
在一些实施例中，在RLC UM模式下，如果是上行(Up Link，UL)传输，那么可以由接收端(Receive，RX)RLC实例来执行时延测量；如果是下行(Down link，DL)传输，那么可以由发送端(Transmit，TX)RLC实例来执行时延测量。
在一些实施例中，在RLC AM模式下，如果UL和DL共用RLC实例，因此可以通过该RLC实例的序列号时延变化趋势分析，来分析多个QoS流业务流是否能满足同步要求。
S603，如果不能满足同步要求，则触发上报机制及QoS参数修改。
在一些实施例中，如果NG-RAN检测到多个QoS流之间的传输能够满足同步要求，则可以继续进行传输；若不能满足同步要求，则NG-RAN可以调整资源传输算法来使多个QoS流满足同步要求，如果在设定的时长内仍然无法满足同步要求，则可以发送通知消息(notification)给5G核心网(5G Core，5GC)，以使5GC在收到通知后触发QoS流参数的更新。
在一些实施例中，5GC在收到通知后，也可以将notification发送给AF，进而可以由AF进行自适应调整，比如AF重新生成针对多个QoS流的QoS需求信息，并发送给核心网网元，以调整针对多个QoS流的处理策略。
在一些实施例中，多个QoS流的传输延迟检测以及是否满足同步要求的判断，可以采用以下方式：
包级检测：对每个数据包进行时延测量并进行同步性判断；
MAC TB级检测：在每次MAC TB传输时执行延迟检测和同步性判断。
上述的判断方式在无线信道快速衰落场景(如高速移动)会产生误判，因此可能不适合无线信道变化剧烈的情况。因此，为了提高系统的扩展性，可以将同步要求的判断设计为一个状态机或者阈值判断，在用户面RLC或MAC实例中来实施。
具体而言，在进行阈值判断时，可以设定一个阈值，当数据包传输的延迟变化在阈值范围之内时，可以认定为是满足同步要求的，并且不会触发上报过程；如果数据包传输的延迟变化超过了该阈值范围，则认定为不满足同步性要求，需要触发上报过程。
在通过状态机进行判断时，可以设计一个状态机，包括同步、不同步两个状态，或者也可以包含其他状态，可以设置各个状态之间的转换条件以动态跟随状态的变化。
在一些实施例中，通过状态机的方式和通过阈值进行判断的方式可以结合实施，也可以分开实施。
综上，本申请实施例的技术方案提出了一种新的数据传输方案，使得NG-RAN基站可以识别QoS流之间的同步性关系，通过为不同的QoS流选择合适的无线资源，确保存在同步性关系的QoS流之间能够在NG-RAN中的传输过程中实现同等的传输延迟。本申请实施例的技术方案能够解决多媒体流在映射成多个QoS流后由于多个QoS流之间在5G/6G网络中传输导致不同延迟，从而影响到接收端多媒体业务的用户体验的问题。
需要说明的是，本申请实施例的技术方案不仅适用于5G系统，而且也适用于未来演进的移动通信系统。同时，本申请实施例的技术方案不仅适用于XRM业务，也可以适用于对其它多媒体业务流的处理。
以下介绍本申请的装置实施例，可以用于执行本申请上述实施例中的数据传输方法。对于本申请装置实施例中未披露的细节，请参照本申请上述的数据传输方法的实施例。
图7示出了根据本申请的一些实施例的数据传输装置的框图，该数据传输装置可以应用于接入网网元，比如可以应用于基站设备，当然图7所示的数据传输装置也可以应用于其它具有计算处理功能的电子设备。
参照图7所示，根据本申请的一些实施例的数据传输装置700，包括：确定单元702和处理单元704。
其中，确定单元702，配置为确定多个服务质量QoS流是否具有同步传输需求；处理单元704，配置为在确定多个QoS流之间具有同步传输需求时，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。
图8示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图，该电子设备可以是前述实施例中的接入网网元，比如基站设备。
需要说明的是，图8示出的电子设备的计算机系统800仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图8所示，计算机系统800可以包括中央处理单元(Central Processing Unit，CPU)801，其可以根据存储在只读存储器(Read-Only Memory，ROM)802中的程序或者从存储部分808加载到随机访问存储器(Random Access Memory，RAM)803中的程序而执行各种适当的动作和处理，例如执行上述实施例中所述的方法。在RAM 803中，还存储有系统操作所需的各种程序和数据。CPU 801、ROM 802以及RAM 803通过总线804彼此相连。输入/输出(Input/Output，I/O)接口805也连接至总线804。
以下部件可以连接至I/O接口805：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN(Local Area Network，局域网)卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。
特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序用于执行流程图所示的方法。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被中央处理单元(CPU)801执行时，执行本申请的系统中限定的各种功能。
需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储计算机程序的有形介质，该计算机程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。
附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机程序的组合来实现。
描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个计算机程序，当上述一个或者多个计算机程序被一个该电子设备执行时，使得该电子设备实现上述实施例中所述的方法。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本申请实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台电子设备执行根据本申请实施方式的方法。比如，电子设备可以是接入网网元，那么接入网网元可以执行图4至图5中所示的数据传输方法。
本领域技术人员在考虑说明书及实践这里公开的实施方式后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (17)

  1. 一种数据传输方法，由电子设备执行，包括：
    确定多个服务质量QoS流是否具有同步传输需求；
    若确定所述多个QoS流具有同步传输需求，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。
  2. 根据权利要求1所述的数据传输方法，其中，所述确定多个服务质量QoS流是否具有同步传输需求，包括以下方式中的至少一种：
    接收核心网网元发送的显式指示参数，根据所述显式指示参数确定所述多个QoS流是否具有同步传输需求；
    根据隐式指示参数推断所述多个QoS流是否具有同步传输需求。
  3. 根据权利要求2所述的数据传输方法，其中，所述显式指示参数包括多模态服务标识，所述多模态服务标识用于指示同一个协议数据单元PDU会话内的多个QoS流具有关联关系。
  4. 根据权利要求2所述的数据传输方法，其中，所述根据隐式指示参数推断所述多个QoS流是否具有同步传输需求，包括以下方式中的至少一种：
    根据用户设备上下文信息中包含的会话级QoS参数，推断所述多个QoS流是否具有同步传输需求；
    根据用户设备上下文信息中包含的QoS流级别的QoS参数，推断所述多个QoS流是否具有同步传输需求；
    在核心网网元配置了同步性约束时，确定同一个PDU会话中包含的多个QoS流具有同步传输需求。
  5. 根据权利要求1至4任一项所述的数据传输方法，进一步包括：
    若确定所述多个QoS流具有同步传输需求，则根据所述同步传输需求生成针对所述多个QoS流的同步传输参数；其中，所述同步传输参数包括以下参数中的至少一个：PDU集合延迟预算PSDB、针对接入网的数据包延迟预算PDB。
  6. 根据权利要求5所述的数据传输方法，所述多个QoS流基于所分配的传输资源进行传输时满足同步要求包括：所述多个QoS流基于所分配的传输资源进行传输时满足相同的传输延迟。
  7. 根据权利要求1至6任一项所述的数据传输方法，其中，根据所述同步传输需求为所述多个QoS流分配传输资源，包括：
    根据所述同步传输需求使用同一个数据无线承载传输所述多个QoS流，以使所述多个QoS流基于所述同一个数据无线承载进行传输时满足同步要求；或者
    根据所述同步传输需求为所述多个QoS流分配不同的数据无线承载，以使所述多个QoS流基于不同的数据无线承载进行传输时满足同步要求。
  8. 根据权利要求1至7任一项所述的数据传输方法，进一步包括：
    在根据所述同步传输需求为所述多个QoS流分配传输资源之后，对所述多个QoS流的传输过程进行延迟检测；
    若检测到所述多个QoS流在传输时不能满足同步要求，则调整为所述多个QoS流分配的传输资源。
  9. 根据权利要求8所述的数据传输方法，其中，所述对所述多个QoS流的传输过程进行延迟检测，包括：
    对于传输模式为非确认模式的QoS流，由接收端无线链路控制RLC实例对上行传输进行延迟检测，并由发送端RLC实例对下行传输进行延迟检测；
    对于传输模式为确认模式的QoS流，由上行和下行共享的RLC实例进行延迟检测。
  10. 根据权利要求8或9所述的数据传输方法，其中，所述对所述多个QoS流的传输过程进行延迟检测，包括：
    针对所述多个QoS流，以数据包为单位进行延迟测量；或者
    针对所述多个QoS流，以传输块为单位进行延迟测量。
  11. 根据权利要求8至10任一项所述的数据传输方法，进一步包括：
    若所述多个QoS流的数据包之间的传输延迟差在设定的阈值范围内，则确定所述多个QoS流在传输时能够满足同步要求；
    若所述多个QoS流的数据包之间的传输延迟差不在设定的阈值内，则确定所述多个QoS流在传输时不能满足同步要求。
  12. 根据权利要求8所述的数据传输方法，进一步包括：
    根据对所述多个QoS流的延迟检测结果，通过状态机的不同状态指示所述多个QoS流在传输时是否能够满足同步要求；其中，所述状态机包括同步状态和不同步状态。
  13. 根据权利要求8所述的数据传输方法，进一步包括：
    在调整为所述多个QoS流分配的传输资源之后，若经过设定时长，所述多个QoS流仍然不能满足同步要求，则向核心网网元发送通知消息，以使核心网网元调整针对所述多个QoS流的传输参数。
  14. 一种数据传输装置，包括：
    确定单元，配置为确定多个服务质量QoS流是否具有同步传输需求；
    处理单元，配置为若确定所述多个QoS流具有同步传输需求，则根据所述同步传输需求为所述多个QoS流分配传输资源，以使所述多个QoS流基于所分配的传输资源进行传输时满足同步要求。
  15. 一种计算机可读介质，其上存储有计算机程序，其中，所述计算机程序被处理器执行时实现权利要求1至13中任一项所述的数据传输方法。
  16. 一种电子设备，包括：
    一个或多个处理器；
    存储器，用于存储一个或多个计算机程序，当所述一个或多个计算机程序被所述一个或多个处理器执行时，使得所述电子设备实现权利要求1至13中任一项所述的数据传输方法。
  17. 一种计算机程序产品，所述计算机程序产品包括计算机程序，所述计算机程序存储在计算机可读存储介质中，电子设备的处理器从所述计算机可读存储介质读取并执行所述计算机程序，使得所述电子设备执行权利要求1至13中任一项所述的数据传输方法。
PCT/CN2025/104236 2024-08-01 2025-06-27 数据传输方法、装置、计算机可读介质及电子设备 Pending WO2026026352A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202411057354.X 2024-08-01
CN202411057354.XA CN121463125A (zh) 2024-08-01 2024-08-01 数据传输方法、装置、计算机可读介质及电子设备

Publications (1)

Publication Number Publication Date
WO2026026352A1 true WO2026026352A1 (zh) 2026-02-05

Family

ID=98576146

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/104236 Pending WO2026026352A1 (zh) 2024-08-01 2025-06-27 数据传输方法、装置、计算机可读介质及电子设备

Country Status (2)

Country Link
CN (1) CN121463125A (zh)
WO (1) WO2026026352A1 (zh)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103354528A (zh) * 2013-06-28 2013-10-16 北京智谷睿拓技术服务有限公司 多流同步方法及装置
CN116155875A (zh) * 2021-11-22 2023-05-23 华为技术有限公司 一种数据传输的方法及通信装置
CN116368775A (zh) * 2020-07-30 2023-06-30 欧芬诺有限责任公司 多个数据流的同步
CN118383049A (zh) * 2021-11-03 2024-07-23 交互数字专利控股公司 用于多流同步的方法、架构、装置和系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103354528A (zh) * 2013-06-28 2013-10-16 北京智谷睿拓技术服务有限公司 多流同步方法及装置
CN116368775A (zh) * 2020-07-30 2023-06-30 欧芬诺有限责任公司 多个数据流的同步
CN118383049A (zh) * 2021-11-03 2024-07-23 交互数字专利控股公司 用于多流同步的方法、架构、装置和系统
CN116155875A (zh) * 2021-11-22 2023-05-23 华为技术有限公司 一种数据传输的方法及通信装置

Also Published As

Publication number Publication date
CN121463125A (zh) 2026-02-03

Similar Documents

Publication Publication Date Title
US12219515B2 (en) Data transmission method and apparatus, computer readable medium, and electronic device
US12363588B2 (en) Data transmission method and apparatus, computer readable medium, and electronic device
WO2022247550A1 (zh) 数据重传处理方法、装置、计算机设备和存储介质
WO2023213086A1 (zh) 数据处理方法、装置、计算机可读介质及电子设备
TW201306527A (zh) 利用相異網路傳送一封包之方法
US20250048491A1 (en) Data transmission method and apparatus, computer-readable medium, and electronic device
WO2024060991A1 (zh) 一种多路径的数据流引流方法及装置
WO2024066362A1 (zh) 数据传输方法、装置、计算机可读介质及电子设备
US12610333B2 (en) Data transmission method, data transmission apparatus, computer-readable medium, and electronic device
US12556307B2 (en) Reducing transmission of data packets in data trnasmission
US12610301B2 (en) Network handover processing method, network handover processing apparatus, computer-readable medium, and electronic device
WO2024001451A1 (zh) 业务数据包的处理方法、装置、介质及电子设备
WO2022141096A1 (zh) 一种无线投屏方法及装置
WO2025139499A1 (zh) 基于非3GPP接入的QoS处理方法、装置、可读介质及设备
CN121463125A (zh) 数据传输方法、装置、计算机可读介质及电子设备
WO2026066552A1 (zh) 业务数据流的处理方法、装置、计算机可读介质及设备
WO2025139500A1 (zh) 服务质量处理方法、装置、计算机可读介质及电子设备
WO2025139498A1 (zh) 基于有线接入的拥塞处理方法、装置、可读介质及设备
WO2025130053A1 (zh) 服务质量处理方法、装置、计算机可读介质及电子设备
WO2026026751A1 (zh) 业务数据流的处理方法、装置、计算机可读介质及设备
HK40092246A (zh) 数据传输方法、装置、计算机可读介质及电子设备
HK40092246B (zh) 数据传输方法、装置、计算机可读介质及电子设备
CN120881105A (zh) 一种数据传输方法、装置、设备、介质及产品
WO2025130439A1 (zh) 业务数据包集合的QoS处理方法、装置、可读介质及设备
HK40044544B (zh) 数据传输方法、装置、计算机可读介质及电子设备

Legal Events

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

Ref document number: 25846798

Country of ref document: EP

Kind code of ref document: A1