Communication method and related device

Abstract

The invention provides a communication method and a related device, which can more effectively guarantee the QoS (Quality of Service) of a service. The method comprises: a network side device determines a PDB of a first data packet, a target PDB being determined based on an RTT demand, the target PDB comprising a target uplink PDB or a target downlink PDB, and the RTT demand being an RTT demand of the first data packet between a terminal device and a server; and the network side equipment transmits the first data packet based on the target PDB.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method and related apparatus. Background Technology

[0002] The packet delay budget (PDB) defines the upper limit of the time delay between a data packet and the N6 interface endpoint in the user plane function (UPF). In the radio access network (RAN), the PDB is used to support scheduling configuration and link-layer function configuration (e.g., setting scheduling priorities) to ensure that data packets meet transmission delay requirements. The PDB can be divided into uplink (UL) PDB and downlink (DL) PDB.

[0003] Among them, UL PDB is used to ensure the quality of service (QoS) of uplink services, and DL PDB is used to ensure the QoS of downlink services. Therefore, the appropriate DL PDB and DL PDB are particularly important for ensuring the QoS of services. Summary of the Invention

[0004] This application provides a communication method and related apparatus to better guarantee the QoS of services.

[0005] Firstly, this application provides a communication method applicable to network-side devices. For example, the network-side device may be an access network device or a UPF network element, or it may be a component (such as a chip, chip system, etc.) configured in the access network device or UPF network element, or it may be a logic module or software capable of implementing all or part of the functions of the access network device or UPF network element; this application does not limit this. For ease of understanding and explanation, the method will be described below using an access network device as an example of a network-side device.

[0006] For example, the method includes: determining a target PDB for a first data packet, the target PDB being determined based on round trip time (RTT) requirements, the target PDB including a target uplink PDB or a target downlink PDB, the RTT requirement being the RTT requirement of the first data packet between a terminal device and a server; and transmitting the first data packet based on the target PDB.

[0007] Optionally, the target PDB includes an uplink PDB, and the first data packet includes one or more uplink data packets; or, the target PDB includes a downlink PDB, and the first data packet includes one or more downlink data packets.

[0008] Alternatively, RTT requirement is the transmission time required for the first data packet to be transmitted from the terminal device to the server, processed by the server, and then transmitted back to the terminal device by the server. In other words, RTT requirement includes the total latency requirement of the 3rd Generation Partnership Project (3GPP) system and the total latency requirement of non-3GPP systems. The total latency requirement of the 3GPP system is the upper limit of the time delay between the data packet and the N6 interface endpoint in the UPF, while the total latency requirement of the non-3GPP system is the upper limit of the time delay between the data packet and the UPF to the server.

[0009] Optionally, the RTT requirement can be a predefined duration, or the RTT requirement can be determined by the server and instructed by the server to the network-side device.

[0010] Based on this technical solution, the network-side device determines the target PDB of the first data packet based on the RTT requirement. This RTT requirement includes not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. In other words, the target PDB of the first data packet determined by the network-side device considers not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. For end-to-end services (such as extended reality (XR) and robotics services), the total latency requirement of the non-3GPP system may also affect the transmission latency of the data packet. Therefore, the method of adjusting the target PDB based on the RTT requirement in this application can more effectively guarantee the QoS of such services. In addition, the network-side device adjusts the PDB at the data packet granularity. This method of adjusting the PDB can dynamically adjust the PDB according to the actual transmission situation of the data packet, thus better guaranteeing the QoS of the service.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the target PDB is the target downlink PDB; determining the target PDB of the first data packet includes: determining the target downlink PDB of the first data packet based on the RTT requirement, the first time moment, and the second time moment.

[0012] Wherein, the first time is the time when the first data packet arrives at the network-side device, the second time is the time when the terminal device generates the second data packet, and the first data packet is the data packet after the second data packet has been processed by the server.

[0013] The difference between the first and second time points can determine the transmission delay of the first data packet from the terminal device to the RAN and then to the server. After being processed by the server, the transmission delay continues from the server to the RAN. Therefore, based on the RTT requirement and this difference, the target PDB of the first data packet can be obtained.

[0014] For example, the target PDB of the first data packet = RTT demand - (first time - second time).

[0015] Optionally, the method further includes: recording the second moment when the first data packet arrives at the first communication device.

[0016] In conjunction with the first aspect, in some implementations of the first aspect, the target PDB is the target downlink PDB; determining the target PDB of the first data packet includes: determining the target downlink PDB of the first data packet based on the application layer processing deadline and the first time.

[0017] The application layer processing deadline is the sum of the time when the terminal device generates the second data packet and the RTT requirement.

[0018] For example, the application layer processing deadline = RTT requirement + second time, and the target PDB of the first data packet = application layer processing deadline - first time.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: receiving first information, the first information being used to indicate a mapping relationship between the generation time of at least one uplink data packet and the identifier of at least one downlink data packet, and to indicate the period of the uplink service, wherein the at least one uplink data packet and the first data packet belong to the uplink service; and determining the second time when the terminal device generates the second data packet based on the mapping relationship, the identifier of the first data packet, and the period of the uplink service.

[0020] Wherein, the generation time corresponding to the at least one uplink data packet is the time when the terminal device generates the at least one uplink data packet.

[0021] Optionally, the identifier of at least one downlink data packet may be the serial number (SN) of at least one downlink data packet or other identification information, which is not limited in this application. It is understood that the SN of any two downlink data packets in the at least one downlink data packet may be different.

[0022] Optionally, the first information is further used to indicate one or more of the following: a first parameter, burst arrival time (BAT), the application layer processing deadline corresponding to the at least one uplink data packet, or the RTT requirement; the first parameter is used to determine the number of uplink data packets corresponding to the first data packet, the uplink data packets including the second data packet.

[0023] The application layer processing deadline for at least one uplink data packet can be understood as the sum of the generation time of each uplink data packet and the RTT requirement in at least one uplink data packet, where the generation time of each uplink data packet is the time when the terminal device generates each uplink data packet.

[0024] Optionally, the first parameter can be the ratio of the number of at least one uplink data packet to the number of its corresponding at least one downlink data packet. For example, the at least one downlink data packet corresponding to the at least one uplink data packet refers to at least one data packet obtained after the at least one uplink data packet has been processed by the server.

[0025] In conjunction with the first aspect, in some implementations of the first aspect, the target PDB is a target uplink PDB; determining the target PDB of the first data packet includes: receiving second information from the server, the second information being used to indicate an adjustment value for the uplink PDB of the first data packet, the adjustment value being related to the RTT requirement; and adjusting the first uplink PDB to the target uplink PDB based on the adjustment value, wherein the first uplink PDB is the current uplink PDB of the first data packet.

[0026] Optionally, receiving second information from the server includes receiving second information from the server via an application function (AF).

[0027] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: determining whether to increase or decrease the first uplink PDB; and sending third information to the server, the third information being used to indicate whether to increase or decrease the first uplink PDB.

[0028] Optionally, sending third information to the server includes sending third information to the server via AF.

[0029] It is understandable that, if the RTT requirement remains unchanged, increasing the first uplink PDB will decrease the downlink PDB of the first data packet; or, if the RTT requirement remains unchanged, decreasing the first uplink PDB will increase the downlink PDB of the first data packet.

[0030] In conjunction with the first aspect, in certain implementations of the first aspect, determining to increase or decrease the first uplink PDB includes: determining to decrease the first uplink PDB based on one or more of the following conditions: the downlink PDB is less than a first preset value within a preset duration, the downlink data volume is greater than a second preset value, the downlink channel state is less than a third preset value, or the latency requirement of the downlink data packet in a future period is greater than the first downlink PDB, wherein the first downlink PDB is the current downlink PDB of the first data packet; or, determining to increase the first uplink PDB based on one or more of the following conditions: the downlink PDB is greater than or equal to the first preset value within a preset duration; the downlink data volume is less than or equal to the second preset value; the downlink channel state is greater than or equal to the third preset value; or the latency requirement of the downlink data packet in a future period is less than or equal to the first downlink PDB.

[0031] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: sending fourth information to the server, the fourth information being used to indicate the adjustment range of the first uplink PDB, the adjustment value belonging to the adjustment range, and the adjustment range of the uplink PDB being related to the RTT requirement.

[0032] Optionally, a fourth message may be sent to the server, including sending the fourth message to the server via AF.

[0033] Optionally, the adjustment range of the first uplink PDB is determined based on RTT requirements, the current downlink PDB, and one or more of the following differences: the difference between the downlink PDB and the first preset value within a preset duration, the difference between the downlink data volume and the second preset value, the difference between the parameter value of the downlink channel state and the third preset value, or the difference between the latency requirement of the downlink data packets and the first downlink PDB in a future time period.

[0034] In conjunction with the first aspect, in some implementations of the first aspect, the RTT requirement is at the granularity of a set of data packets.

[0035] Alternatively, the RTT requirement is the RTT requirement of the data packet set between the terminal device and the server. In this case, the data packet in this application can be replaced with a data packet set, for example, the first data packet mentioned above can be replaced with a first data packet set.

[0036] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes: establishing a user protocol data unit (PDU) session and a quality of service (QoS) stream, wherein the QoS parameters of the QoS stream include the RTT requirement.

[0037] Secondly, this application provides a communication method that can be applied to a terminal device, or to a component (such as a chip, chip system, etc.) configured in the terminal device, or to a logic module or software that can realize all or part of the functions of the terminal device. This application does not limit the application in this regard.

[0038] For example, the method includes: determining a mapping relationship between the generation time of at least one uplink data packet and the identifier of at least one downlink data packet; and sending first information to a network-side device, the first information being used to indicate the mapping relationship and the period of the uplink service.

[0039] Wherein, the generation time corresponding to the at least one uplink data packet is the time when the terminal device generates the at least one uplink data packet.

[0040] Based on this technical solution, the terminal device sends the mapping relationship between the generation time of the determined uplink data packet and the identifier of the downlink data packet, along with the uplink service cycle, to the network-side device. This allows the network-side device to deduce the generation time of the uplink data packet (i.e., the second data packet mentioned above) corresponding to the currently received downlink data packet (i.e., the first data packet mentioned above) based on this mapping relationship and service cycle. Consequently, the network-side device determines the target PDB of the first data packet based on the RTT requirement, the generation time, and the reception time of the currently received downlink data packet. This RTT requirement includes not only the total latency of the 3GPP system but also the total latency requirement of non-3GPP systems. In other words, the target PDB of the first data packet determined by the network-side device considers not only the total latency of the 3GPP system but also the total latency requirement of non-3GPP systems. For end-to-end services (such as extended reality...), this is crucial. For real-world (XR) and robotics services, the total latency requirements of non-3GPP systems may also affect the transmission latency of data packets. Therefore, the method of adjusting the target PDB based on RTT requirements in this application can more effectively guarantee the QoS of such services. In addition, the network-side equipment adjusts the PDB at the data packet granularity. This method of adjusting the PDB can dynamically adjust the PDB according to the actual transmission of data packets, thus better guaranteeing the QoS of the service.

[0041] In conjunction with the second aspect, in some implementations of the second aspect, the method further includes: recording the generation time corresponding to the at least one uplink data packet; and recording the identifier of the at least one downlink data packet.

[0042] Thirdly, this application provides a communication method that can be applied to a communication device. For example, the communication device can be a server, or a component configured within the server (such as a chip, chip system, etc.), or a logic module or software capable of implementing all or part of the server's functions; this application does not limit this. For ease of understanding and explanation, the method will be described below using a server as an example of a communication device.

[0043] For example, the method includes: receiving third information, the third information being used to indicate increasing or decreasing the first uplink PDB, the first uplink PDB being the current uplink PDB of the first data packet; determining an adjustment value for the uplink PDB of the first data packet based on the third information; and sending second information, the second information being used to indicate the adjustment value for the uplink PDB of the first data packet.

[0044] Based on this technical solution, the server sends the adjustment value of the uplink PDB determined by the third information to the network-side device. This allows the network-side device to consider the server's processing time when adjusting the current uplink PDB, rather than being limited to the adjustment of the PDB between the RAN and the terminal device. This adjustment method ensures that uplink data packets do not arrive at the server prematurely during uplink transmission between the terminal device and the server, while also ensuring that uplink data packets do not miss the server's processing time. Therefore, the method provided in this application can better guarantee the QoS of services.

[0045] Optionally, determining the adjustment value of the uplink PDB of the first data packet based on the third information includes: adjusting the processing time of the server based on the third information, and determining the adjustment value of the uplink PDB of the first data packet based on the adjusted processing delay.

[0046] The server's processing time can be a fixed time when the server processes data packets, and the server's processing duration can be the time required from when the server starts processing data packets to when it receives the processed data packets.

[0047] Since adjusting the server's processing time can change the transmission latency of data packets between the network-side device and the server, changes in the transmission latency between the network-side device and the server will affect the transmission latency budget between the terminal device and the network-side device, assuming the RTT requirement remains unchanged. Therefore, the server can adjust its processing latency to regulate both the uplink PDB and the downlink PDB.

[0048] In conjunction with the third aspect, in some implementations of the third aspect, the method further includes: receiving fourth information, the fourth information being used to indicate the adjustment range of the uplink PDB corresponding to the first uplink PDB, the adjustment value belonging to the adjustment range, and the adjustment range of the uplink PDB being related to the RTT requirement.

[0049] For a description of the scope of adjustment, please refer to the second part above; it will not be repeated here.

[0050] Fourthly, this application provides a communication device, including modules or units for implementing the methods of any of the above aspects and any possible implementations of any of the above aspects. It should be understood that each module or unit can implement its corresponding function by executing a computer program.

[0051] Fifthly, this application provides a communication device including a processor, the processor being configured to perform the methods described in any of the foregoing aspects and any possible implementations of any of the foregoing aspects.

[0052] The apparatus may further include a memory for storing instructions and data. The memory is coupled to the processor, which, when executing the instructions stored in the memory, can implement the methods described in the foregoing aspects.

[0053] The device may also include a communication interface for communicating with other devices. For example, the communication interface may be a transceiver, circuit, bus, module or other type of communication interface.

[0054] Sixthly, this application provides a chip system including at least one processor for supporting the implementation of the functions involved in any of the above aspects and any possible implementations of any of the above aspects, such as receiving or processing data and / or information involved in the above methods.

[0055] In one possible design, the chip system also includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0056] The chip system can consist of chips or include chips and other discrete components.

[0057] In a seventh aspect, this application provides a computer-readable storage medium including a computer program that, when run on a computer, causes the computer to implement the methods in any of the foregoing aspects and any possible implementations of any of the foregoing aspects.

[0058] Eighthly, this application provides a computer program product comprising: a computer program (also referred to as code or instructions) that, when run, causes a computer to perform the methods described in any of the foregoing aspects and any possible implementations of any of the foregoing aspects.

[0059] Ninthly, this application provides a communication system including the aforementioned terminal device and network-side device. The network-side device is used to execute the methods described in the first aspect and any possible implementation thereof; the terminal device is used to execute the methods described in the second aspect and any possible implementation thereof.

[0060] Optionally, the communication system further includes the aforementioned server, which is used to execute the methods in the third aspect and any possible implementation thereof.

[0061] It should be understood that aspects four through nine of this application correspond to the technical solutions of aspects one, two, or three of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0062] Figure 1 This is a structural schematic diagram of the network architecture provided in the embodiments of this application;

[0063] Figure 2 It is a fifth-generation (5G) quality of service (QoS) model based on QoS flow;

[0064] Figure 3 This is a schematic diagram of the QoS architecture;

[0065] Figure 4 This is a schematic diagram of a PDB;

[0066] Figure 5 This is a schematic flowchart of the communication method provided in the embodiments of this application;

[0067] Figure 6 This is another illustrative flowchart of the communication method provided in the embodiments of this application;

[0068] Figure 7 This is a schematic diagram of the server processing procedure provided in the embodiments of this application;

[0069] Figure 8 This is another illustrative flowchart of the communication method provided in the embodiments of this application;

[0070] Figure 9 This is a schematic block diagram of the device provided in the embodiments of this application;

[0071] Figure 10 This is another schematic block diagram of the device provided in the embodiments of this application. Detailed Implementation

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

[0073] To facilitate understanding of the embodiments of this application, the following points are explained first:

[0074] First, in the embodiments of this application, the use of prefixes such as "first" and "second" is merely for the purpose of distinguishing and describing different things belonging to the same name category, and does not constrain the order, size, or quantity of things. For example, "first information" and "second information" are simply different pieces of information, and there is no temporal sequence, size, or priority relationship between them.

[0075] Second, in the embodiments of this application, "send" and "receive" indicate the direction of signal transmission. For example, "send the target uplink PDB to the terminal device" can be understood as the destination of the target uplink PDB being the terminal device, which may include direct transmission via the air interface or indirect transmission via the air interface by other units or modules. "Receive the first information from the terminal device" can be understood as the source of the first information being the terminal device, which may include direct reception from the terminal device via the air interface or indirect reception from the terminal device via the air interface by other units or modules. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface.

[0076] In other words, sending and receiving can occur between devices, such as between a terminal device and a network-side device; or they can occur within a device, such as between components, modules, chips, software modules, or hardware modules within a device via a bus, wiring, or interface.

[0077] It is understandable that information may undergo necessary processing, such as encoding and modulation, before being sent from the source to the destination. Similarly, the destination, upon receiving information from the source, can also perform corresponding processing, such as decoding and demodulation, to interpret the valid information from the source. Similar expressions in this application can be understood in a similar way and will not be elaborated further.

[0078] Third, in the embodiments of this application, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates an "or" relationship between the preceding and following related objects, but it does not exclude the possibility of indicating an "and" relationship. The specific meaning can be understood in conjunction with the context. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c; a and b; a and c; b and c; or a and b and c. Here, a, b, and c can be single or multiple.

[0079] Fourth, in the embodiments of this application, "instruction" can include direct instruction and indirect instruction, as well as explicit instruction and implicit instruction. The information indicated by a certain piece of information (such as the first information, second information, etc., as described below) is called the information to be instructed. In the specific implementation process, there are many ways to instruct the information to be instructed, such as, but not limited to, directly instructing the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly instruct the information to be instructed by instructing other information, where there is a correlation between the other information and the information to be instructed; or it can only instruct a part of the information to be instructed, while the other parts of the information to be instructed are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol predefined) arrangement order of various pieces of information, thereby reducing the instruction overhead to a certain extent. This application does not limit the specific method of instruction.

[0080] It is understandable that, for the sender of the instruction information, the instruction information can be used to indicate the information to be indicated, and for the receiver of the instruction information, the instruction information can be used to determine the information to be indicated.

[0081] Fifth, the tables in the embodiments of this application are merely examples. The values ​​of the information in each table are only examples and can be configured to other values; this application is not limited thereto. The tables do not limit the scope of protection of this application. For example, appropriate modifications and adjustments can be made based on the tables described above, such as splitting, merging, etc. Furthermore, the parameter names shown in the headings of each table can also use other names understandable to the communication device, and the values ​​or representations of the parameters can also be other values ​​or representations understandable to the communication device. Moreover, in the implementation of the above tables, other data structures can also be used, such as arrays, queues, containers, stacks, linear lists, pointers, linked lists, trees, graphs, structures, classes, heaps, hash tables, or hash tables, etc.

[0082] Sixth, in the embodiments of this application, descriptions such as "when," "under the circumstances," "if," and "if" all refer to the fact that the device (e.g., network-side device or terminal device) will make corresponding processing under certain objective circumstances. They are not time limits, nor do they require the device (e.g., network-side device or terminal device) to make a judgment action when implementing it, nor do they imply any other limitations.

[0083] Seventh, the predefined terms in this application can be understood as: definition, pre-defined, storage, pre-storage, pre-negotiation, pre-configuration, solidification, or pre-firing.

[0084] Eighth, the term "storage" in this application can refer to storage in one or more memory devices. These memory devices can be separate installations or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memory devices can be separately installed, while others can be integrated into the decoder, processor, or communication device. The type of memory can be any form of storage medium, and this application does not limit this.

[0085] The technical solutions provided in this application can be applied to various communication systems, such as: Long Term Evolution (LTE) systems, LTE Frequency Division Duplex (FDD) systems, LTE Time Division Duplex (TDD) systems, sidelink (SL) communication systems, Worldwide Interoperability for Microwave Access (WiMAX) communication systems, 5th Generation (5G) mobile communication systems or new radio access technology (NR), satellite communication systems, etc. Among them, 5G mobile communication systems can include non-standalone (NSA) and / or standalone (SA) networking.

[0086] The technical solution provided in this application can also be applied to future communication systems.

[0087] Figure 1 This is a structural schematic diagram of the network architecture 100 provided in this application embodiment. The network architecture 100 is a 5th generation (5G) network architecture. The network elements in this 5G network architecture include user equipment (UE) 101, access network (AN) 102, user plane function (UPF) of the core network (CN) user data plane 103, data network (DN) 104, server 105, and core network control plane 106.

[0088] Among them, UE 101 has the capability to transmit carrier signals. UE can also be referred to as terminal equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device. In the following description, it will be uniformly referred to as terminal equipment.

[0089] Terminal devices can be devices that provide voice / data connectivity to users, such as handheld devices with wireless connectivity, in-vehicle devices, etc. Currently, examples of terminal devices include: mobile phones, tablets, computers with wireless transceiver capabilities (such as laptops and PDAs), mobile internet devices (MIDs), virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, drones, wireless terminals in remote medical care, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to wireless modems, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future public land mobile communication networks. Terminal equipment in a mobile network (PLMN), etc.

[0090] Wearable devices, also known as wearable smart devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables, such as glasses, gloves, watches, clothing, and shoes. Wearable devices are portable devices worn directly on the body or integrated into the user's clothing or accessories. Wearable devices are not merely hardware devices; they achieve powerful functions through software support, data interaction, and cloud interaction. Broadly defined, wearable smart devices include those with comprehensive functions, large sizes, and the ability to perform complete or partial functions without relying on a smartphone, such as smartwatches or smart glasses. They also include devices focused on a specific application function that require the use of other devices, such as smart bracelets and smart jewelry for vital sign monitoring.

[0091] Terminal devices can also be terminal devices in IoT systems. IoT is an important component of future information technology development. Its main technical characteristic is connecting objects to networks through communication technologies, thereby realizing an intelligent network that enables human-machine interconnection and machine-to-machine interconnection. IoT technology can achieve massive connectivity, deep coverage, and low power consumption at the terminal level through technologies such as narrowband (NB).

[0092] Terminal devices may also include sensors such as smart printers, train detectors, and gas station sensors. Their main functions include collecting data (for some terminal devices), receiving control information and downlink data from access network devices, and sending electromagnetic waves to transmit uplink data to access network devices.

[0093] Furthermore, the terminal device in this application can also be a virtualized device, for example, implemented through general-purpose hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions. The general-purpose hardware can be a server, such as a cloud server.

[0094] It should be understood that this application does not limit the specific form of the terminal device.

[0095] AN 102 is a device with wireless transceiver capabilities, such as a radio access network (RAN) device, used to provide wireless communication services and allow terminal devices to connect to the wireless network. A RAN device can be a node within the RAN, often referred to as a RAN node.

[0096] In one possible scenario, a RAN node can be a base station (BS), an evolved NodeB (eNodeB), a transmission reception point (TRP), a home evolved NodeB (or homeNode B, HNB), an access point (AP) for wireless fidelity (Wi-Fi), a mobile switching center, or a base station in a future mobile communication system. A RAN node can also be a device that performs base station functions in device-to-device (D2D) communication systems, vehicle-to-everything (V2X) communication systems, machine-to-machine (M2M) communication systems, and internet-to-things (IoT) communication systems. A RAN node can also be a RAN node in a nonterrestrial network (NTN), meaning that a RAN node can be deployed on a high-altitude platform or a satellite. RAN nodes can be macro base stations, micro base stations, indoor stations, relay nodes, donor nodes, or radio controllers in cloud radioaccess network (CRAN) scenarios, or nodes in open radio access network (O-RAN or ORAN) scenarios.

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

[0098] It can be understood that the RU is the unit that transmits, receives, amplifies, and digitizes radio frequency signals, and the RU is located near the antenna or integrated into the antenna; the DU and CU are the computing modules of the base station, which transmit digitized radio signals into the network. The DU is physically located at or near the RU, while the CU can be located closer to the core. It should be understood that in future systems, the functions provided by the CU, DU, and RU may be redefined.

[0099] The CU provides support for higher layers of the protocol stack, such as the Service Data Adaptation Protocol (SDAP) layer, the Packet Data Convergence Protocol (PDCP) layer, and the Radio Resource Control (RRC) layer, while the DU provides support for lower layers of the protocol stack, such as the Radio Link Control (RLC) layer, the Medium Access Control (MAC) layer, and the Physical (PHY) layer.

[0100] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in the ORAN system, CU can also be called open CU (O-CU), DU can also be called open DU (O-DU), CU-CP can also be called open CU-CP (O-CU-CP), CU-UP can also be called open CU-UP (O-CU-UP), and RU can also be called open RU (O-RU).

[0101] Any one of the CU (or CU-CP, CU-UP), DU, and RU units can be implemented through software modules, hardware modules, or a combination of software and hardware modules. That is, the wireless access network device in this application can be a virtualized device, for example, implemented through general-purpose hardware and instantiated virtualization functions, or dedicated hardware and instantiated virtualization functions. The general-purpose hardware can be a server, such as a cloud server.

[0102] It should be understood that this application does not limit the specific form of the wireless access network equipment.

[0103] It should also be understood that UE 101 and AN 102 can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on aircraft, balloons, and artificial satellites. This application embodiment does not limit the application scenarios of AN 102 and UE 101.

[0104] AN 102 and UE 101 can communicate via licensed spectrum, unlicensed spectrum, or both simultaneously; they can communicate via spectrum below 6 GHz, spectrum above 6 GHz, or both simultaneously. The embodiments of this application do not limit the spectrum resources used for wireless communication.

[0105] UPF 103 is the user plane functional unit, mainly responsible for packet forwarding, quality of service (QoS) control, billing information statistics, and connecting to external networks.

[0106] DN 104 is the network responsible for providing services to UE 101. For example, some DNs provide Internet access for UE 101, while others provide SMS functionality, and so on.

[0107] Server 105 is a device that communicates with UE 101 and can send service data to UE 101, such as video service data or voice service data. This application embodiment does not limit this.

[0108] The core network control plane 106 is primarily responsible for service process interaction, issuing data packet forwarding policies to the user plane, and QoS control policies. For example... Figure 1As shown, the control plane network elements in the core network control plane 106 may include: Access and Mobility Function (AMF), Session Management Function (SMF), Policy Control Function (PCF), Application Function (AF), and Network Exposure Function (NEF). Among these, the AMF is primarily responsible for the access and mobility management of UE 101. The SMF is mainly responsible for managing the creation and deletion of Protocol Data Unit (PDU) sessions, maintaining PDU session contexts and user plane forwarding pipeline information. The PCF is mainly responsible for executing policy control, similar to the Policy and Charging Rules Function (PCRF) network element in Long Term Evolution (LTE), including generating and managing user, session, Quality of Service (QoS) flow processing policies, QoS and charging rules, and distributing the corresponding rules to the UPF network element through the SMF. The AF (Agent Front-end) is primarily responsible for providing various service functions. It can interact with the core network through NEF (Network Front-end) elements and with the policy management framework for policy management. The NEF (Network Front-end) is used to provide frameworks, authentication, and interfaces related to network capability exposure, and to transmit information between 5G system network functions and other network functions.

[0109] exist Figure 1 In the network architecture shown, UE 101 communicates with AMF via the N1 interface, which is used to transmit nonaccess stratum (NAS) signaling. AN 102 communicates with AMF via the N2 interface; AN 102 communicates with UPF103 via the N3 interface, which uses the user-plane GPRS tunneling protocol for the user plane (GTP-U) for tunneling user data; UPF103 communicates with SMF via the N4 interface, which is used for policy configuration of UPF 103, etc. UPF 103 communicates with external DN 104 via the N6 interface. In specific scenarios, the N6 interface is required to support leased lines or L2 / L3 layer tunnels and can communicate with the DN network based on Internet Protocol (IP).

[0110] It should be noted that the network-side device in this application embodiment can be an access network device or a core network element; the various network elements involved in this application embodiment can be either the aforementioned Figure 1 The network elements mentioned above can also be network elements in future communication systems that have the same functions as the aforementioned network elements. For example, a user plane function network element can be a UPF network element, or a network element in a future communication system that has the same functions as a UPF network element; an application function network element can be an AF network element, or a network element that has the same functions as an AF network element; a policy management network element can be a PCF network element, or a network element that has the same functions as a PCF network element.

[0111] for Figure 1 In the communication system shown, server 105 can communicate with UE 101 via DN 104, UPF 103, core network control plane 106, and AN 102. For example, a video stream service on server 105 is transmitted to UE 101 via DN 104, UPF 103, core network control plane 106, and AN 102.

[0112] In mobile communication systems, when a terminal device communicates with an external network, a pathway needs to be established through the mobile communication network. This pathway is called a Protocol Data Unit (PDU) session. Communication data is transmitted within a PDU session in the form of QoS flows to enable QoS control and management. A PDU session can contain one or more QoS flows (or multiple QoS flows can share the same PDU session), and user services within the same QoS flow have the same QoS service level, such as scheduling and admission control.

[0113] Figure 2 This is a 5G QoS model based on Quality of Service (QoS) flow. Node B (NB) can be one of the RAN nodes mentioned above, and UPF refers to the function in the 5G core network (5GC) used to process user data plane data. For example... Figure 2 As shown, the data link established between the radio bearer (RB) NB and the UE is not one-to-one with the QoS flow; the NG-U tunnel is the user plane data tunnel established between the 5GC and the NG-RAN.

[0114] Figure 3 This is a schematic diagram of the QoS architecture. (For example...) Figure 3As shown, for downlink data, when an application layer data packet arrives at the UPF, the UPF identifies which QoS flow the data packet corresponds to according to the packet detection rule (PDR), marks it with a QoS flow identifier (QFI), and then sends it to the AN through the PDU session. The RAN then maps the QoS flow to the AN resource according to the mapping relationship between the QoS flow and the RB, and sends the data packet to the UE through the AN resource.

[0115] Conversely, for uplink data, when the application layer data packet is generated by the terminal device, the terminal device identifies which QoS flow the data packet corresponds to according to the QoS rules, marks it with QFI, and sends it to the AN through the corresponding AN resource through the mapping relationship between the QoS flow and RB; the AN then sends the data packet to the UPF, and then forwards it to the application server.

[0116] It's understandable that each QoS flow within a PDU session has a corresponding QoS profile. This profile includes a set of parameters for that QoS flow, containing a PDB (Programmable Depository) used to guarantee service transmission latency. The PDB defines the upper limit of the time delay for a data packet between the N6 interface endpoint in the UE and UPF (i.e., the 3GPP system transmission portion). Figure 1 Taking the 5G network architecture shown as an example, when a data packet arrives at UPF 103, UPF 103 needs to transmit the data packet to UE 101 within the PDB. More specifically, as... Figure 4 As shown, the PDB consists of the packet delay budget from the core network device to the access network device and the packet delay budget from the access network device to the terminal device. The packet delay budget from the core network device to the access network device can be abbreviated as CN PDB, and the packet delay budget from the access network device to the terminal device can be abbreviated as AN PDB. That is, AN PDB is determined by subtracting the static value of CN PDB from the PDB.

[0117] In the RAN, PDBs can be used to support link-layer functions such as scheduling configuration and priority scheduling weights, ensuring that data packets meet transmission latency requirements. If the latency of a data packet exceeds the PDB, the sender can choose to actively discard the data packet and consider it lost, or continue transmission, depending on the type of the QoS flow. Furthermore, the policy control function (PCF) can divide the PDB into UL PDB and DL PDB based on the round-trip latency requirements between the data flow and the N6 interface in the UPF. These two can be equal or different. UL PDB indicates the PDB of the uplink data packets in the data flow, while UL PDB indicates the PDB of the downlink data packets in the data flow.

[0118] Currently, adjusting the values ​​of UL PDB or DL ​​PDB requires initiation by the session management function (SMF). The SMF determines the UL PDB and / or DL ​​PDB based on the average latency of multiple data packets measured by the UPF over a period of time between the UE and the N6 interface of the UPF. This method of determining the PDB may result in DL PDB or UL PDB values ​​being too high or too low for some data packets. Secondly, for end-to-end services such as extended reality (XR) and robotics, where uplink data generated by the terminal device triggers server processing and generates downlink data to be fed back to the terminal device, the transmission latency of these services may be affected by both uplink and downlink PDB and server processing. Adjusting UL PDB and / or DL ​​PDB using the current method—focusing only on transmission latency within the 3GPP network and neglecting the transmission latency between the terminal device and the external network—may lead to difficulties in ensuring QoS for these services.

[0119] In view of this, embodiments of this application provide a communication method and related apparatus. In this method, the DLPDB or UL PDB is dynamically adjusted based on the RTT requirements of the service between the terminal device and the server, as well as the actual transmission status of uplink data packets and / or downlink data packets, effectively ensuring the transmission latency of uplink and downlink data packets, thereby ensuring the QoS of the service.

[0120] The communication method provided in the embodiments of this application is described in detail below with reference to the accompanying drawings. It should be understood that the method provided in this application can be applied to... Figure 1 The network architecture shown is not limited to this embodiment.

[0121] The following example uses adjusting the downlink PDB of downlink data packets, combined with... Figure 5The communication methods provided in the embodiments of this application are described in detail.

[0122] Figure 5 This is a schematic flowchart illustrating the communication method provided in an embodiment of this application. Figure 5 As shown, method 500 may include steps S501 to S510. The steps of method 500 are described in detail below. It should be understood that... Figure 5 The terminal device in the middle can be Figure 1 UE 101 in Figure 5 The server in the middle can be Figure 1 Server 105 in the middle, Figure 5 RAN in can be Figure 1 AN102 in the middle.

[0123] S501 establishes a PDU session and QoS flow between the terminal device and the server.

[0124] For a description of establishing PDU sessions and QoS flows, please refer to the relevant descriptions in existing technologies; they will not be repeated here.

[0125] Optionally, the QoS parameters of the QoS stream may include RTT requirements, which are used to guarantee end-to-end transmission latency.

[0126] The RTT requirement refers to the RTT time required for data packets in this QoS stream between the terminal device (end) and the server (end). In other words, the RTT requirement is the transmission latency required for data packets in this QoS stream to travel from the terminal device to the server, be processed by the server, and then be transmitted back to the terminal device by the server. That is, the RTT requirement includes the PDB mentioned earlier, as well as the round-trip transmission latency requirement from the UPF to the server.

[0127] Optionally, the RTT requirement can be a predefined duration, or it can be determined by the server and indicated by the server to other network elements involved in establishing the PDU session and / or QoS flow. For example, the server indicates the RTT requirement to the terminal device, RAN, or UPF.

[0128] It is understandable that the RTT requirement can be business-related, or in other words, different businesses can define different RTT requirements.

[0129] It is also understood that the RTT requirement can also be called round trip PDB (RT-PDB) or other names, and this application does not limit it to these terms.

[0130] S502, the terminal device records N times when N uplink data packets are generated.

[0131] Where N is a positive integer. A record can also be understood as something that is saved or stored.

[0132] The N uplink data packets may include the first packet of a certain service (e.g., XR service) and / or one or more packets in subsequent service cycles.

[0133] It can be understood that the N times when the terminal device generates N uplink data packets can be called the N generation times of the N uplink data packets (for ease of description, they will be referred to as the N generation times below).

[0134] S503, the terminal device sends the N uplink data packets to the server. Correspondingly, the server receives the N uplink data packets from the terminal device.

[0135] It is understandable that a terminal device sending N uplink data packets to a service can involve forwarding through multiple network elements. For example, the terminal device can send these N uplink data packets to the server through the RAN and core network elements.

[0136] S504, the server processes the N uplink data packets to obtain M downlink data packets.

[0137] Where M is a positive integer, and M and N may be the same or different.

[0138] Example 1: M equals N, meaning that each of the N uplink data packets, after being processed by the server, will result in one downlink data packet. That is, the number of uplink data packets and the number of downlink data packets have a 1:1 relationship.

[0139] Example 2, where M is not equal to N, and N is equal to 1, indicates that after one uplink data packet is processed by the server, it can generate M downlink data packets. That is, the number of uplink data packets and the number of downlink data packets satisfy a 1:M relationship.

[0140] Example 3, where M is not equal to N, and M equals 1, means that after N uplink data packets are processed by the server, one downlink data packet can be obtained. That is, the number of uplink data packets and the number of downlink data packets satisfy an N:1 relationship.

[0141] Example 4, where M is not equal to N, and both N and M are greater than 1, indicates that after N uplink data packets are processed by the server, M downlink data packets can be obtained. That is, the number of uplink data packets and the number of downlink data packets satisfy an N:M relationship.

[0142] By combining Examples 1 to 4, a certain proportional relationship can be obtained between the number of uplink data packets and the corresponding number of downlink data packets. This proportional relationship is defined as the first parameter in this application. That is, the first parameter is used to determine the number of downlink data packets corresponding to one or more uplink data packets. In other words, the number of downlink data packets obtained after each uplink data packet is processed by the server can be determined through the first parameter.

[0143] For example, if the first parameter is 1:3, then when one uplink data packet is obtained, it can be determined from the first parameter (1:3) that the uplink data packet was processed by the server into three downlink data packets.

[0144] Optionally, each of the M downlink data packets processed by the server may have a corresponding identification information to distinguish different downlink data packets. For example, this identification information may be the serial number (SN) of the downlink data packet, which may be carried in the header portion of the downlink data packet. For instance, the SN of the data packet may be carried in a header encapsulated using Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Real-Time Transport Protocol (RTP).

[0145] S505, the server sends the M downlink data packets to the terminal device. Correspondingly, the terminal device receives the M downlink data packets from the server.

[0146] It is understandable that when a server sends M downlink data packets to a terminal device, the packets can be forwarded through multiple network elements. For example, the server can send M downlink data packets to the terminal device through core network elements and the RAN.

[0147] S506, the terminal device recognizes a correspondence between N uplink data packets and M downlink data packets.

[0148] Since the terminal device can determine which uplink data packets the server processed to obtain the downlink data packets from the server, after receiving M downlink data packets, the terminal device can identify which uplink data packets (N) the server processed to obtain each of the M downlink data packets, and thus obtain the correspondence between the N uplink data packets and the M downlink data packets.

[0149] For example, the terminal device can use the moment when uplink data packet #1 is generated as the starting moment to begin timing, and determine the downlink data packets received within a preset time period after this starting moment as the downlink data packets corresponding to uplink data packet #1. For instance, if the terminal device generates data packet #1 at time t1 and receives downlink data packet #1 between time t1 and (t1+Δt), then the terminal device determines that there is a correspondence between uplink data packet #1 and downlink data packet #1. Here, Δt is the preset time period.

[0150] Table 1 shows a correspondence between uplink and downlink data packets.

[0151] Table 1

[0152] SN of UL data packet SN of DL packets 1 1 2 2 … … N N

[0153] As shown in Table 1, each uplink data packet is processed by the server to obtain a DL data packet. The DL data packet with SN=1 is processed by the server to obtain DL data packet with SN=1, the DL data packet with SN=2 is processed by the server to obtain DL data packet with SN=2, and so on. The DL data packet with SN=N is processed by the server to obtain DL data packet with SN=N.

[0154] Optionally, the terminal device can determine the first parameter based on the above correspondence.

[0155] For example, if the terminal device recognizes that each of the M downlink data packets is obtained by processing one uplink data packet, then the first parameter can be determined to be 1:1, and the correspondence between the identifier of each downlink data packet and the identifier of each uplink data packet can be determined; if the terminal device recognizes that each of the M downlink data packets is obtained by processing the same uplink data packet, then the first parameter can be determined to be 1:M; if the terminal device recognizes that a downlink data packet is obtained by processing N uplink data packets, then the first parameter can be determined to be N:1; if the terminal device recognizes that M uplink data packets are obtained by processing corresponding N uplink data packets, then the first parameter can be determined to be N:M.

[0156] For example, based on the correspondence shown in Table 1, the terminal device can determine that the first parameter is 1:1.

[0157] S507, the terminal device determines the mapping relationship between N generation times and M downlink data packet identifiers.

[0158] For example, the terminal device can determine the downlink data packet corresponding to each of the N generation times based on the correspondence between the identified N uplink data packets and M downlink data packets, as well as the N generation times corresponding to the N uplink data packets. In this way, the mapping relationship between the N generation times and the identifiers of the M downlink data packets can be obtained.

[0159] The generation time of each uplink data packet can be recorded by the terminal device. This is because the uplink data packets are generated by the terminal device, so the terminal device can directly obtain the generation times of N uplink data packets.

[0160] Table 2 shows the correspondence between UL data packets and the generation time of UL data packets.

[0161] Table 2

[0162] UL data packet generation time SN of UL data packet t1 1 t2 2 … … tN N

[0163] As shown in Table 2, UL data packets with SN=1 are generated at time t1, UL data packets with SN=2 are generated at time t2, UL data packets with SN=1 are generated at time t1, and so on, with UL data packets with SN=N being generated at time tN.

[0164] It is understandable that since one uplink data packet can correspond to one or more downlink data packets, or multiple uplink data packets can correspond to one or more downlink data packets, the mapping relationship can include one generation time corresponding to one or more downlink data packets, or multiple generation times corresponding to one or more downlink data packets.

[0165] Combining Table 1 and Table 2, we can obtain a mapping relationship as shown in Table 3 below.

[0166] Table 3

[0167] UL data packet generation time SN of DL packets t1 1 t2 2 … … tN M

[0168] As shown in Table 3, the SN of the downlink data packet corresponding to the uplink data packet generated at time t1 is 1, the SN of the downlink data packet corresponding to the uplink data packet generated at time t2 is 2, and so on, the SN of the downlink data packet corresponding to the uplink data packet generated at time tN is N=M.

[0169] If N uplink data packets belong to periodic uplink traffic, then tN can be represented by t1 and the uplink traffic period: tN = t1 + (N-1)p, where p is the uplink traffic period and N is the serial number (SN) of the downlink data packets. For example, t2 = t1 + p, t3 = t2 + p = t1 + 2p.

[0170] For example, when N≠M and N=1, the identifier of the downlink data packet corresponding to the generation time of each uplink data packet can be the identifier of the last downlink data packet to arrive at the RAN among M downlink data packets.

[0171] For example, when N≠M and M=1, the generation time of the multiple uplink data packets corresponding to the identifier of each downlink data packet can be the generation time of the last uplink data packet that arrives at the RAN among the N uplink data packets.

[0172] For example, when N≠M and N=M≠1, the generation time of the uplink data packet in a set of mapping relationships (e.g., a row in Table 3) can be the generation time of the last uplink data packet that arrives at the RAN among N uplink data packets, and the identifier of the downlink data packet can be the identifier of the last downlink data packet that arrives at the RAN among M downlink data packets.

[0173] S508, the terminal device sends the first information to the RAN.

[0174] This first information is used to indicate the aforementioned mapping relationship and the cycle of the uplink service. Correspondingly, the RAN receives the first information from the terminal device.

[0175] The period of this uplink service can be understood as the time difference between two adjacent uplink data packets generated by the terminal device that belong to this uplink service. For example, for XR service, if an uplink data packet is generated every 5 milliseconds (ms), then the period of the XR service is 5ms.

[0176] Optionally, this first information may also be used to indicate one or more of the following: a first parameter, a burst arrival time (BAT), or an RTT requirement. For a description of the first parameter, please refer to the relevant description in S506 above; it will not be repeated here.

[0177] Optionally, the first information can also be used to indicate the application layer processing deadline for each of the N uplink data packets, where the application layer processing deadline is the sum of the time when the terminal device generates the uplink data packet and the RTT requirement.

[0178] S509, the RAN determines the second time when the terminal device generates the second data packet based on the mapping relationship, the identifier of the first data packet, and the cycle of the uplink service.

[0179] The second data packet and the first data packet satisfy the following relationship: the first data packet is the downlink data packet obtained after the second data packet has been processed by the server. It can be understood that the second data packet can be one or more data packets generated by the terminal device.

[0180] The first data packet here can be one or more downlink data packets from the server, and the first data packet belongs to the same service as the downlink data packets included in the mapping relationship; or, the second data packet belongs to the same service as the uplink data packet corresponding to the generation time included in the mapping relationship.

[0181] Optionally, the RAN derives the time when the terminal device generates the second data packet based on the mapping relationship between the identifier of the first data packet and the first information indication and the cycle of the uplink service.

[0182] Taking the mapping relationship shown in Table 3 as an example, we can obtain that the downlink data packet SN = N, and the corresponding uplink data packet generation time is tN, where tN = t1 + (N-1)p. Therefore, if the RAN obtains the first data packet SN = n, then the RAN can determine the time when the terminal device generates the second data packet as tn = t1 + (n-1)p. For example, if n = 7, then t7 = t1 + (7-1)p = t1 + 6p.

[0183] Optionally, the RAN records the first moment when the first data packet from the server arrives at the RAN.

[0184] S510, the RAN determines the target downlink PDB of the first data packet based on the RTT requirement, the first time, and the second time.

[0185] Based on the definitions of the first and second time points, the RAN can determine the time interval from when the terminal device generates the second data packet, sends it to the server, and then receives the first data packet from the server after processing the second data packet. Therefore, based on the definition of RTT requirements and the definitions of the first and second time points, the RAN can determine the target downlink AN PDB of the first data packet from the RAN to the terminal device.

[0186] Based on the mapping relationship shown in Table 3, Table 4 illustrates the relationship between downlink PDB and generation time, and downlink data packet identifier.

[0187] Table 4

[0188] UL data packet generation time SN of DL packets DL PDB t1 1 RT-PDB-(t1'-t1) t2 2 RT-PDB-(t2'-t2) … … tN M RT-PDB-(tN'-tN)

[0189] In Table 4, t1' represents the arrival time of the downlink data packet with SN=1 at the RAN, t2' represents the arrival time of the downlink data packet with SN=2 at the RAN, and so on, with tN' representing the arrival time of the downlink data packet with SN=N at the RAN. From Table 4, we can obtain: the DLPDB of the downlink data packet with SN=1 = RT - PDB - (t1' - t1), the DLPDB of the downlink data packet with SN=2 = RT - PDB - (t2' - t2), and so on, with the DLPDB of the downlink data packet with SN=M=N = RT - PDB - (tN' - tN).

[0190] For example, when the RAN is divided into logical entities such as CU (CU can be further divided into CU-CP / CU-UP) and DU, S510 mainly occurs between CU-CP and CU-UP, and between CU-CP and DU. CU-CP and CU-UP are connected via an E1 interface, CU-CP and DU are connected via an F1-C interface, and CU-UP and DU are connected via an F1-U interface.

[0191] In this embodiment, the RAN determines the target downlink PDB of the first data packet based on the RTT requirement. This RTT requirement includes not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. In other words, the target downlink PDB of the first data packet determined by the RAN considers not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. Since the total latency requirement of the non-3GPP system may also affect the transmission latency of data packets for end-to-end services (such as extended reality (XR) and robotics services), the method of adjusting the target PDB based on the RTT requirement in this application can more effectively guarantee the QoS of such services. In addition, the RAN adjusts the PDB at the data packet granularity. This method of adjusting the PDB can dynamically adjust the PDB according to the actual transmission situation of the data packets, thus better guaranteeing the QoS of the service.

[0192] It should be noted that the steps performed by the RAN in method 500 can be replaced by the UPF. For example, the RAN in S508 to S510 can be replaced by the UPF. However, it should be noted that when the RAN in S508 to S510 is replaced by the UPF, the downlink PDB (including the target downlink PDB) described in method 500 is no longer the downlink PDB of the first data packet from the RAN to the terminal device, but rather the downlink PDB of the first data packet from the UPF to the terminal device.

[0193] Optionally, the data packets described in the above method 500 (including N uplink data packets, M downlink data packets, a first data packet, a second data packet, etc.) can be replaced with a set of data packets. This set of data packets can be understood as the complete data packets required by the application layer to complete a business operation. For example, in a virtual reality (VR) device, the left-eye video data packets and right-eye video data packets that need to be played at a certain moment can be packaged into a set of data packets. This set of data packets can also be called a PDU set.

[0194] It is understandable that if data packets are replaced with data packet sets, then the identifier of a data packet can be replaced with the identifier of a data packet set. For example, each data packet set is identified by an identifier (that is, the identifier is at the data packet set granularity), or data packets with the same identifier constitute a data packet set (that is, the identifier is at the data packet granularity). When data packets are replaced with data packet sets, the aforementioned RTT requirement also needs to be at the data packet set granularity; that is, the RTT requirement is the RTT requirement between the terminal device and the server for each data packet set.

[0195] Optionally, the time when the terminal device generates uplink data packets in the above method 500 (including N generation times, the generation time of the second data packet, etc.) can be replaced with: the application layer processing deadline of the uplink data packets on the terminal device side, which is the sum of the time when the terminal device generates the second data packet and the RTT requirement.

[0196] For example, S507 above can be replaced by: the terminal device determining the mapping relationship between N application layer processing deadlines and the identifiers of M downlink data packets; S509 above can be replaced by: the RAN determining the application layer processing deadline of the second data packet on the terminal device side based on the mapping relationship, the identifier of the first data packet, and the uplink service cycle; S510 above can be replaced by: the RAN determining the downlink PDB of the first data packet based on the application layer processing deadline and the first time.

[0197] The following example uses adjusting the uplink PDB of uplink data packets, combined with... Figure 6 The communication methods provided in the embodiments of this application are described in detail.

[0198] Before introducing method 600, let's first combine... Figure 7 Here's a brief overview of the server-side processing. For periodic tasks, the server typically has a fixed processing time, such as... Figure 7As shown, the server buffer deadline occurs periodically (this periodic server buffer deadline can be considered as the server's fixed processing time). In the uplink scenario, uplink data packets P1, P2, and P3 arrive at the server sequentially. After uplink data packet P1 arrives, the server does not process uplink data packet P2 before the server buffer deadline has expired; similarly, after uplink data packet P2 arrives, the server does not process uplink data packet P2 before the server buffer deadline has expired; however, after uplink data packet P3 arrives, the server buffer deadline has also expired, and the server begins to process uplink data packets P1, P2, and P3, resulting in one downlink data packet.

[0199] like Figure 7 The relationship between the uplink data packets P1, P2, and P3 and the server's cache expiration time shows that the processing latency of uplink data packet P1 is greater than that of uplink data packet P2, and the processing latency of uplink data packet P2 is greater than that of uplink data packet P3. Within these uplink data packets P1, P2, and P3, the uplink PDB of uplink data packet P1 can be greater than that of uplink data packet P2, and the uplink PDB of uplink data packet P2 can be greater than that of uplink data packet P3. This ensures that these three uplink data packets neither arrive at the server prematurely nor miss the server's processing time.

[0200] Therefore, even if uplink data packets arrive at the server ahead of schedule, the server will first put them in the buffer and only process them during the processing time (e.g., the aforementioned server buffer deadline). In this case, if you want to reserve more time budget margin for downlink by tightening the uplink data packet transmission time (or reducing the uplink PDB), adjusting the UL PDB only on the RAN side may not be effective. This is because although adjusting the UL PDB only on the RAN side can make uplink data packets arrive at the server earlier, the server still needs to wait for the processing time to process them. Therefore, after considering the total non-3GPP latency, it may be difficult to reserve more time budget margin for downlink data packets by tightening the uplink data packet transmission time, and the server needs to adjust its processing time synchronously. Similarly, if the RAN relaxes the uplink transmission time (or increases the uplink PDB), it may cause uplink data packets to miss the server processing time, affecting the service experience. Therefore, the server's processing time also needs to be adjusted synchronously. In summary, if the RAN determines to reduce the first uplink PDB to reserve more time budget margin for the downlink, or if the RAN determines to increase the first uplink PDB to reserve less time budget margin for the downlink, the server needs to synchronously adjust its local processing time to achieve the RAN's adjustment of the uplink and downlink PDB.

[0201] Figure 6 This is another illustrative flowchart of the communication method provided in the embodiments of this application. For example... Figure 6 As shown, method 600 may include steps S601 to S607. The steps of method 600 are described in detail below.

[0202] S601 establishes a PDU session and QoS flow between the terminal device and the server.

[0203] The process is the same as S501, so it will not be described again here.

[0204] S602, RAN determines whether to increase or decrease the first uplink PDB.

[0205] The first uplink PDB is the current uplink PDB of the first data packet, which includes one or more uplink data packets. The first uplink PDB is the uplink AN PDB of the first data packet from the terminal device to the RAN.

[0206] To ensure service QoS, while maintaining the same RTT requirement, the uplink transmission time can be tightened to reserve more time budget for downlink transmission when the following conditions occur (or, the RAN can determine to reduce the first uplink PDB based on one or more of the following conditions): the downlink PDB within a preset duration is less than the first preset value, the downlink data volume is greater than the second preset value, the downlink channel state parameter value is less than the third preset value, or the downlink data packet latency requirement in the future period is greater than the first downlink PDB.

[0207] The downlink channel state parameter values ​​in this application may include one or more of the following: channel state information (CSI), reference signal received power (RSRP), received signal strength indication (RSSI), reference signal received quality (RSRQ), signal to interference plus noise ratio (SINR), etc.

[0208] Furthermore, based on one or more of the above conditions, the RAN can also determine the adjustment range of the first uplink PDB.

[0209] For example, the RAN can determine the range within which the current downlink PDB can be increased based on one or more of the following differences and the current downlink PDB, and then determine the adjustment range of the first uplink PDB based on the RTT requirement and the range within which the current downlink PDB can be increased: the difference between the downlink PDB and the first preset value within a preset duration, the difference between the downlink data volume and the second preset value, the difference between the parameter value of the downlink channel state and the third preset value, or the difference between the latency requirement of the downlink data packet and the first downlink PDB in a future time period.

[0210] Conversely, to ensure service QoS, while keeping RTT requirements unchanged, the uplink transmission time can be relaxed to reserve more time budget for downlink transmission when the following conditions occur (or, the RAN can determine to increase the first uplink PDB based on one or more of the following conditions): the downlink PDB within a preset duration is greater than or equal to the first preset value; the downlink data volume is less than or equal to the second preset value; the downlink channel state parameter value is greater than or equal to the third preset value; or the downlink data packet latency requirement in the future time period is less than or equal to the first downlink PDB.

[0211] Similarly, the RAN can determine the range within which the current downlink PDB can be reduced based on one or more of the following differences and the current downlink PDB, and then determine the adjustment range of the first uplink PDB based on the RTT requirement and the range within which the current downlink PDB can be reduced: the difference between the downlink PDB and the first preset value within a preset duration, the difference between the downlink data volume and the second preset value, the difference between the parameter value of the downlink channel state and the third preset value, or the difference between the latency requirement of the downlink data packet and the first downlink PDB in a future time period.

[0212] The description of RTT requirements can be found in Method 500, and will not be repeated here.

[0213] It is understood that the first to third preset values ​​mentioned above can be predetermined or determined based on the requirements for the quality of the business.

[0214] S603, the RAN sends a third message to the server, which indicates whether to increase or decrease the first uplink PDB. Correspondingly, the server receives the third message from the RAN.

[0215] Optionally, the method 600 further includes: the RAN sending fourth information to the server, the fourth information being used to indicate the adjustment range of the first uplink PDB.

[0216] It is understood that the third and fourth information can be sent simultaneously or separately, and this application does not impose any restrictions on this.

[0217] S604, the server determines the adjustment value of the uplink PDB of the first data packet based on the third information.

[0218] It is understandable that if the RAN sends the fourth information to the server, the server can determine the adjustment value of the uplink PDB of the first data packet from the adjustment range indicated by the fourth information. In other words, when the RAN sends the fourth information to the server, the adjustment value of the uplink PDB determined by the server can fall within that adjustment range.

[0219] Optionally, the server determines the adjustment value of the uplink PDB of the first data packet based on the third information, including: the server adjusting the server's processing time based on the third information; and determining the adjustment value of the uplink PDB of the first data packet based on the adjusted processing time.

[0220] The server's processing time can be a fixed time for the server to process data packets. For example, if the server processes a data packet every 5ms, and the first data packet processing time is 1ms, then the second data packet processing time is (1+5=6)ms, and so on, with the m-th data packet (m being an integer greater than 2) processing time being (1+5(m-1))ms. The server's processing duration can be the time required from when the server starts processing the data packet to when it receives the processed data packet.

[0221] Since adjusting the server's processing time can change the transmission latency of data packets between the network-side device and the server, changes in the transmission latency between the network-side device and the server will affect the transmission latency budget between the terminal device and the network-side device, assuming the RTT requirement remains unchanged. Therefore, the server can adjust its processing latency to regulate both the uplink PDB and the downlink PDB.

[0222] Example 1: If the downlink PDB needs to be increased (conversely, the uplink PDB needs to be decreased) while the RTT demand remains unchanged, the server can reduce the processing time for each iteration while keeping the processing duration unchanged (for example, by...). Figure 7 (The server cache expiration period is shifted to the right as shown).

[0223] It is understandable that by reducing the processing time of each server cycle, or by advancing the inherent processing time of the server, in order to ensure that the upstream data packets do not miss the server's processing time, the upstream PDB can be reduced so that the upstream data packets arrive at the server earlier.

[0224] Example 2: If the uplink PDB needs to be reduced (or increased) while the RTT requirement remains unchanged, the server can increase the processing latency for each iteration while keeping the processing time constant (for example, by increasing the uplink PDB). Figure 7 (The server cache expiration period is shifted to the left as shown).

[0225] Similarly, by increasing the processing time of each server cycle, or by delaying the inherent processing time of the server, in order to prevent upstream data packets from arriving at the server too early, the upstream PDB can be increased to reduce the waiting time of data packets on the server, or in other words, to reduce the processing latency of data packets on the server side. This processing latency is the time from when the server receives the data packet to when the server begins to process the data packet.

[0226] S605, the server sends a second message to the RAN, which indicates the adjustment value of the uplink PDB of the first data packet. Correspondingly, the RAN receives the second message from the server.

[0227] S606, RAN adjusts the first uplink PDB to the target uplink PDB based on the adjustment value.

[0228] For example, if the RAN determines to increase the first uplink PDB and the adjustment value is greater than 0, the target uplink PDB can be the sum of the first uplink PDB and the adjustment value; or, if the RAN determines to decrease the first uplink PDB and the adjustment value is greater than 0, the target uplink PDB can be the difference between the first uplink PDB and the adjustment value.

[0229] S607, RAN sends the target uplink PDB to the terminal equipment.

[0230] Optionally, the RAN can send the target PDB to the terminal device through a radio resource control (RRC) configuration message, or the target uplink PDB can be carried in the RRC configuration message.

[0231] In this embodiment, the RAN dynamically adjusts the current uplink PDB based on the actual communication status and RTT requirements between the RAN and the terminal device. When adjusting the current uplink PDB, the server-side processing time is taken into account, rather than being limited to the adjustment of the PDB between the RAN and the terminal device. This adjustment method ensures that uplink data packets do not arrive at the server prematurely during uplink transmission between the terminal device and the server, and also ensures that uplink data packets do not miss the server's processing time. Therefore, the method provided in this application can better guarantee the QoS of services.

[0232] It should be noted that the steps performed by the RAN in method 600 can be replaced by UPF. For example, the RAN in S602, S603, and S605 to S607 can be replaced by UPF. However, it should be noted that when replaced by UPF, the uplink PDB (including the first uplink PDB and the target uplink PDB) described in method 600 is no longer the uplink PDB of the first data packet from the terminal device to the RAN, but rather the uplink PDB of the first data packet from the terminal device to the UPF.

[0233] Similar to method 500, the data packets (including the first data packet, etc.) described in method 600 can be replaced with a set of data packets. For a description of the data packet set, please refer to the relevant description above; it will not be repeated here.

[0234] It is understandable that the above Figure 5 and Figure 6 The illustrated embodiments can be combined with each other or implemented independently. Wherein, when Figure 5 and Figure 6 When implemented alone, it can perform more Figure 5 or Figure 6More or fewer steps in the steps shown; when Figure 5 and Figure 6 When combined with the embodiments shown, the communication method provided in this application may include: establishing a PDU session and QoS flow between the terminal device and the server; the RAN determining the downlink PDB of the first data packet based on RTT requirements; the RAN determining whether to increase or decrease the first uplink PDB; other more detailed procedures can be found above. Figure 5 and Figure 6 The illustrated embodiment is described below. That is, method 600 can be executed after method 500.

[0235] The following is based on Figure 5 and Figure 6 Based on the illustrated embodiments, combined with Figure 8 The method provided in this application is described below. Figure 5 and Figure 6 The content already described in the illustrated embodiments will not be repeated here.

[0236] Figure 8 This is another schematic flowchart of the communication method 800 provided in this application embodiment. The method 800 can be executed by a network-side device, or by a chip, chip system, or processor that supports the implementation of the method by the network-side device, or by a logic module or software capable of implementing all or part of the functions of the network-side device. It should be understood that... Figure 8 The communication method shown is applied to Figure 1 In the communication system shown, the network-side device can be an access network device or a UPF. It should be noted that if the network-side device is an access network device, the target PDB described below is the AN PDB; specifically, the target uplink PDB is the uplink AN PDB, and the target downlink PDB is the downlink AN PDB. If the network-side device is a UPF, the target PDB described below is the upper limit of the time delay between the data packet and the N6 interface endpoint in the UPF.

[0237] like Figure 8 As shown, method 800 may include steps S801 and S802. The steps in method 800 are described in detail below.

[0238] S801, determine the target PDB of the first data packet, which is determined based on the RTT requirement.

[0239] The target PDB includes either the target uplink PDB or the target downlink PDB.

[0240] It can be understood that the target PDB includes an uplink PDB, and the first data packet includes one or more uplink data packets; or, the target PDB includes a downlink PDB, and the first data packet includes one or more downlink data packets.

[0241] The description of RTT requirements can be found in Method 500, and will not be repeated here.

[0242] S802, transmit the first data packet based on the target PDB.

[0243] For example, the target PDB includes a target downlink PDB, and the network-side device transmits the first data packet to the terminal device within the transmission duration defined by the target downlink PDB.

[0244] For example, the target PDB includes a target uplink PDB. The terminal device notifies the network-side device to schedule corresponding resources within the transmission duration defined by the target uplink PDB, so that the first data packet is transmitted to the network-side device within the defined transmission duration.

[0245] In this embodiment, the network-side device determines the target PDB of the first data packet based on the RTT requirement. This RTT requirement includes not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. In other words, the target PDB of the first data packet determined by the network-side device considers not only the total latency of the 3GPP system but also the total latency requirement of the non-3GPP system. For end-to-end services (such as extended reality (XR) and robotics services), the total latency requirement of the non-3GPP system may also affect the transmission latency of the data packet. Therefore, the method of adjusting the target PDB based on the RTT requirement in this application can more effectively guarantee the QoS of such services. In addition, the network-side device adjusts the PDB at the data packet granularity. This method of adjusting the PDB can dynamically adjust the PDB according to the actual transmission situation of the data packet, thus better guaranteeing the QoS of the service.

[0246] In the first possible implementation, the target PDB is the target downlink PDB. In this case, the above determination of the target PDB of the first data packet can be replaced with the determination of the target downlink PDB of the first data packet.

[0247] Optionally, determining the target PDB of the first data packet includes: determining the target downlink PDB of the first data packet based on RTT requirements, a first time point, and a second time point; or, determining the target downlink PDB of the first data packet based on the application layer processing cutoff time and the first time point.

[0248] Wherein, the first moment is the moment when the first data packet arrives at the network-side device, the second moment is the moment when the terminal device generates the second data packet, the application layer processing deadline is the sum of the moment when the terminal device generates the second data packet and the RTT requirement, and the first data packet is the data packet after the second data packet has been processed by the server.

[0249] For example, the target downlink PDB of the first data packet = RTT requirement - (first time step - second time step). For instance, if the RTT requirement is 70ms, and the difference between the first and second time steps is 65ms, then the target downlink PDB of the first data packet is (70-65=5)ms.

[0250] For example, the target downlink PDB of the first data packet = application layer processing deadline - second time.

[0251] Optionally, the method 800 further includes: the terminal device sending the first information to the network-side device, the first information indicating a mapping relationship between the generation time of at least one uplink data packet and the identifier of at least one downlink data packet, and indicating the period of the uplink service. Correspondingly, the network-side device receives the first information from the terminal device; and based on the mapping relationship, the identifier of the first data packet, and the period of the uplink service, determines the second time when the terminal device generates the second data packet.

[0252] At least one uplink data packet and the first data packet belong to the uplink service.

[0253] This process can be referred to in the descriptions of S508 and S509 in Method 500 above, and will not be repeated here.

[0254] Optionally, the first information is also used to indicate one or more of the following: a first parameter, BAT, the application layer processing deadline or RTT requirement corresponding to the at least one uplink data packet; the first parameter is used to determine the number of uplink data packets corresponding to the first data packet, the uplink data packets including the second data packet.

[0255] Optionally, the method 800 further includes: the terminal device determining a mapping relationship between the generation time of at least one uplink data packet and the identifier of at least one downlink data packet.

[0256] This process can be referred to in the descriptions of S506 and S507 in Method 500 above, and will not be repeated here.

[0257] In the second possible implementation, the target PDB is the target uplink PDB. Therefore, determining the target PDB of the first data packet can be replaced with determining the target uplink PDB of the first data packet.

[0258] Optionally, determining the target PDB of the first data packet includes: the server sending second information to the network-side device, the second information indicating an adjustment value for the uplink PDB of the first data packet, the adjustment value being related to the RTT requirement. Correspondingly, the network-side device receives the second information from the AF or the server; and adjusts the first uplink PDB to the target uplink PDB based on the adjustment value.

[0259] Here, the first uplink PDB is the current uplink PDB of the first data packet.

[0260] Optionally, the server sends a second message to the network-side device via AF.

[0261] This process can be referred to as S605 and S606 in method 600, and will not be repeated here.

[0262] Optionally, the method 800 further includes: the network-side device determining whether to increase or decrease the first uplink PDB; and sending third information to the server, the third information being used to indicate whether to increase or decrease the first uplink PDB. Correspondingly, the AF or the server receives the third information and, based on the third information, determines the adjustment value of the uplink PDB of the first data packet.

[0263] Optionally, network-side devices can send third-party information to the server via AF.

[0264] The process can be referred to in S602 to S604 of method 600, and will not be repeated here.

[0265] Optionally, the network-side device determines to increase or decrease the first uplink PDB, including: determining to decrease the first uplink PDB based on one or more of the following conditions: the downlink PDB is less than a first preset value within a preset time period, the downlink data volume is greater than a second preset value, the parameter value of the downlink channel state is less than a third preset value, or the latency requirement of the downlink data packet is greater than the first downlink PDB in the future time period, wherein the first downlink PDB is the current downlink PDB of the first data packet;

[0266] Alternatively, the first uplink PDB may be increased based on one or more of the following conditions: the downlink PDB is greater than or equal to the first preset value within a preset duration; the downlink data volume is less than or equal to the second preset value; the parameter value of the downlink channel state is greater than or equal to the third preset value; or, the latency requirement of downlink data packets in the future period is less than or equal to the first downlink PDB.

[0267] Optionally, the method 800 further includes: the network-side device sending fourth information to the server, the fourth information indicating the adjustment range of the first uplink PDB, the adjustment value of which falls within the adjustment range, and the adjustment range of the uplink PDB being related to the RTT requirement. Correspondingly, the AF or the server receives the fourth information from the network-side device.

[0268] Optionally, network-side devices can send fourth information to the server via AF.

[0269] As described in S602 of method 600 above, the adjustment range of the uplink PDB is determined based on the RTT requirement, the current downlink PDB, and one or more of the following differences: the difference between the downlink PDB within a preset duration and a first preset value, the difference between the downlink data volume and a second preset value, the difference between the downlink channel state parameter value and a third preset value, or the difference between the downlink data packet latency requirement in a future time period and the first downlink PDB. Therefore, it can be said that the adjustment range of the uplink PDB is related to the RTT requirement.

[0270] Optionally, the method 800 further includes: establishing a Protocol Data Unit (PDU) session and a Quality of Service (QoS) stream, wherein the QoS parameters of the QoS stream include RTT requirements.

[0271] It is understood that when the QoS parameters of the QoS flow carry the RTT requirement, the first information mentioned above may not carry the RTT parameter; if the QoS parameters of the QoS flow do not carry the RTT requirement, then the RTT parameter is carried in the first information.

[0272] For a description of establishing Protocol Data Unit (PDU) sessions and Quality of Service (QoS) flows, please refer to existing technologies; it will not be repeated here.

[0273] The above text combined Figures 1 to 8 The method provided in the embodiments of this application has been described in detail below, in conjunction with... Figure 9 and Figure 10 The apparatus provided in this application is described in detail.

[0274] Figure 9 and Figure 10 The diagram illustrates possible apparatuses provided for embodiments of this application. These apparatuses can be used to implement the functions of the terminal device, network-side device, or server in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0275] Figure 9 This is a schematic block diagram of the apparatus provided in the embodiments of this application. Figure 9 As shown, the device 900 includes a processing module 910 and a transceiver module 920.

[0276] One possible design is that device 900 is used to achieve the above. Figure 5 , Figure 6 and Figure 8 The method embodiment shown illustrates the functionality of the network-side device.

[0277] For example, the processing module 910 is configured to: determine the target packet delay budget (PDB) of the first data packet, wherein the target PDB is determined based on the round-trip time (RTT) requirement, and the target PDB includes a target uplink PDB or a target downlink PDB, wherein the RTT requirement is the RTT requirement of the first data packet between the terminal device and the server; the transceiver module 920 is configured to: transmit the first data packet based on the target PDB.

[0278] Optionally, the processing module 910 is specifically used to: determine the target downlink PDB of the first data packet based on the RTT requirement, the first time, and the second time.

[0279] Optionally, the processing module 910 is specifically used to: determine the target downlink PDB of the first data packet based on the first application layer processing deadline and the first time.

[0280] Optionally, the transceiver module 920 is further configured to: receive first information, the first information being used to indicate the correspondence between the generation time of at least one uplink data packet and the identifier of at least one downlink data packet, and to indicate the period of the uplink service; the processing module 910 is further configured to: determine the second time when the terminal device generates the second data packet based on the correspondence, the identifier of the first data packet and the period of the uplink service.

[0281] Optionally, the transceiver module 920 is further configured to: receive second information from the application function AF or the server, the second information being used to indicate an adjustment value for the uplink PDB of the first data packet, the adjustment value being related to the RTT requirement; the processing module 910 is further configured to: adjust the first uplink PDB to the target uplink PDB based on the adjustment value, the first uplink PDB being the current uplink PDB of the first data packet.

[0282] Optionally, the processing module 910 is further configured to: determine whether to increase or decrease the first uplink PDB; the transceiver module 920 is further configured to: send third information to the server, the third information being used to indicate whether to increase or decrease the first uplink PDB.

[0283] Optionally, the transceiver module 920 is further configured to: send fourth information to the AF or the server, the fourth information being used to indicate the adjustment range of the first uplink PDB, the adjustment value being within the adjustment range, and the adjustment range of the uplink PDB being related to the RTT requirement.

[0284] Optionally, the processing module 910 is specifically configured to: determine to reduce the first uplink PDB based on one or more of the following conditions: the downlink PDB is less than a first preset value within a preset duration, the downlink data volume is greater than a second preset value, the downlink channel state is less than a third preset value, or the latency requirement of the downlink data packet in the future period is greater than the first downlink PDB, wherein the first downlink PDB is the current downlink PDB of the first data packet; or, determine to increase the first uplink PDB based on one or more of the following conditions: the downlink PDB is greater than or equal to the first preset value within a preset duration; the downlink data volume is less than or equal to the second preset value; the downlink channel state is greater than or equal to the third preset value; or the latency requirement of the downlink data packet in the future period is less than or equal to the first downlink PDB.

[0285] Optionally, the processing module 910 is specifically used to: establish a Protocol Data Unit (PDU) session and a Quality of Service (QoS) stream, wherein the QoS parameters of the QoS stream include the RTT requirement.

[0286] For a more detailed description of the aforementioned processing module 910 and transceiver module 920, please refer to the following: Figure 5 , Figure 6 and Figure 8 The relevant descriptions in the illustrated embodiments are directly obtained and will not be repeated here.

[0287] Another possible design is that device 900 is used to achieve the above. Figure 5 , Figure 6 and Figure 8 The method embodiment shown illustrates the functionality of the terminal device.

[0288] For example, the processing module 910 is used to: determine the correspondence between the generation time of at least one uplink data packet and the sequence number of at least one downlink data packet; the transceiver module 920 is used to: send the first information to the network-side device, wherein the first information is used to indicate the correspondence and to indicate the period of the uplink service.

[0289] Optionally, the processing module 910 is further configured to: record the generation time corresponding to the at least one uplink data packet; and record the identifier of the at least one downlink data packet.

[0290] For a more detailed description of the aforementioned processing module 910 and transceiver module 920, please refer to [link / reference needed]. Figure 5 , Figure 6 and Figure 8 The relevant descriptions in the illustrated embodiments are directly obtained and will not be repeated here.

[0291] Another possible design is that device 900 is used to achieve the above. Figure 5 , Figure 6 and Figure 8The method embodiment shown illustrates the functionality of the server.

[0292] For example, the transceiver module 920 is configured to: receive third information, the third information being used to indicate an increase or decrease in the first uplink PDB, the first uplink PDB being the current uplink PDB of the first data packet; the processing module 910 is configured to: determine an adjustment value for the uplink PDB of the first data packet; the transceiver module 920 is further configured to: send the second information, the second information being used to indicate the adjustment value for the uplink PDB of the first data packet.

[0293] Optionally, the transceiver module 920 is further configured to: receive fourth information, the fourth information being used to indicate the adjustment range of the uplink PDB corresponding to the first uplink PDB, the adjustment value belonging to the adjustment range, and the adjustment range of the uplink PDB being related to the RTT requirement.

[0294] For a more detailed description of the aforementioned processing module 910 and transceiver module 920, please refer to [link / reference needed]. Figure 5 , Figure 6 and Figure 8 The relevant descriptions in the illustrated embodiments are directly obtained and will not be repeated here.

[0295] It should be noted that device 900 may include a transmitting module but not a receiving module. Alternatively, device 900 may include a receiving module but not a transmitting module. Specifically, it depends on whether the above-described scheme executed by device 900 includes both transmitting and receiving actions. It is understood that because device 900 has communication capabilities, it can also be called a communication device.

[0296] Figure 10 This is another schematic block diagram of the device provided in the embodiments of this application. For example... Figure 10 As shown, the device 1000 includes one or more processors 1010. The processor 1010 can be a general-purpose processor or a dedicated processor, such as a baseband processor or a central processing unit (CPU). The baseband processor can be used to process communication protocols and communication data, while the CPU can be used to control the device (e.g., a terminal device, network-side device, or chip), execute software programs, and process data from the software programs.

[0297] Optionally, in one design, the processor 1010 may include a program (also referred to as code or instructions) that can be executed on the processor 1010, causing the device 1000 to perform the methods executed by the terminal device or network-side device in the above method embodiments. In yet another possible design, the device 1000 includes circuitry (…). Figure 10 (Not shown), the circuit is used to implement the functions of the terminal device or network-side device in the above method embodiments.

[0298] For example, processor 1010 can be used to execute computer programs or instructions in memory to achieve Figure 5 , Figure 6 and Figure 8 The steps performed by the terminal device or network-side device in any of the embodiments shown.

[0299] Optionally, the device 1000 may include one or more memories 1020 storing programs (sometimes referred to as code or instructions) that can be run on the processor 1010, causing the device 1000 to perform the methods executed by the terminal device or network-side device in the above embodiments.

[0300] Optionally, the processor 1010 and / or memory 1020 may also store data. The processor and memory may be configured separately or integrated together.

[0301] Optionally, the device 1000 may further include a communication interface 1030. The processor 1010, sometimes referred to as a processing unit, controls the device (e.g., a terminal device or a network-side device). The communication interface 1030, sometimes referred to as a transceiver unit, transceiver, transceiver circuit, or transceiver, is used to implement the device's transceiver functions.

[0302] Optionally, the device 1000 also includes a communication interface 1030. The processor 1010 and the communication interface 1030 are coupled to each other. It is understood that the communication interface 1030 can be a transceiver or an input / output interface.

[0303] It is understandable that since device 1000 has communication capabilities, it can also be called a communication device.

[0304] When device 1000 is used to achieve Figure 5 , Figure 6 and Figure 8 In this method, the processor 1010 performs the functions of the aforementioned processing unit, and the communication interface 1030 performs the functions of the aforementioned transceiver module. Whether the communication interface 1030 is used for sending or receiving depends on whether the device 1000 is used to perform a sending or receiving action in the execution scheme.

[0305] When the aforementioned device 1000 is a chip applied to a terminal device, the chip implements the functions of the terminal device in the above method embodiments. The chip of the terminal device receives signals from other modules (such as radio frequency modules or antennas) in the terminal device, and these signals may be sent to the terminal device by the network-side device; or, the chip of the terminal device sends signals to other modules (such as radio frequency modules or antennas) in the terminal device, and these signals may be sent to the network-side device by the terminal device.

[0306] When the aforementioned device 1000 is a chip applied to a network-side device, the chip implements the functions of the network-side device in the above method embodiments. The chip of the network-side device receives signals from other modules (such as radio frequency modules or antennas) in the network-side device, and these signals may be sent from the terminal device to the network-side device; or, the chip of the network-side device sends signals to other modules (such as radio frequency modules or antennas) in the network-side device, and these signals may be sent from the network-side device to the terminal device.

[0307] It is understood that when the device 1000 is a terminal device or a network-side device, the communication interface 1030 can be a transceiver, specifically including a transmitter and a receiver, with the transmitter used to send signals and the receiver used to receive signals. When the device 1000 is a chip applied to a terminal device or a network-side device, the communication interface 1030 can be an input / output circuit, wherein the input circuit can be used for receiving and the output interface can be used for sending.

[0308] It should be noted that the above method embodiments can be applied to a processor, or implemented by a processor. A processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by software instructions.

[0309] The aforementioned processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0310] The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in mature storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

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

[0312] This application also provides a computer program product that, when run on a processor, can implement the methods shown in the above method embodiments.

[0313] This application also provides a computer-readable storage medium containing computer instructions that, when executed on a processor, can implement the methods shown in the above-described method embodiments.

[0314] This application also provides a communication system, including the aforementioned network-side equipment and terminal equipment. Optionally, the communication system may further include the aforementioned server.

[0315] The methods provided in the above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, they can be implemented, in whole or in part, in the form of a computer program product. The computer program product may include one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic disk), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0316] Those skilled in the art will 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, or a combination of computer software and electronic hardware. 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.

[0317] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0319] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0320] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0321] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network-side device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0322] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method characterized by comprising: The method comprises: determining a target packet delay budget PDB of a first data packet, the target PDB being determined based on a round trip time RTT requirement between a terminal device and a server, the target PDB comprising a target uplink PDB or a target downlink PDB, the RTT requirement being a RTT requirement between the terminal device and the server; transmitting the first data packet based on the target PDB.

2. The method of claim 1, wherein, The target PDB is a target downlink PDB. The determining of the target PDB of the first data packet comprises: determining a target downlink PDB of the first data packet based on the RTT requirement, a first time and a second time, the first time being a time when the first data packet arrives at a network side device, the second time being a time when a second data packet is generated by the terminal device, the first data packet being a data packet processed by the server from the second data packet. The target PDB is a target downlink PDB.

3. The method of claim 1, wherein, The determining of the target PDB of the first data packet comprises: determining a target downlink PDB of the first data packet based on an application layer processing deadline and a first time, the first time being a time when the first data packet arrives at a network side device, the application layer processing deadline being a sum of a time when a second data packet is generated by the terminal device and the RTT requirement, the first data packet being a data packet processed by the server from the second data packet. The method further comprises: receiving first information, the first information being used to indicate a mapping relationship between a generation time corresponding to at least one uplink data packet and an identifier of at least one downlink data packet, and being used to indicate a period of uplink service, the at least one uplink data packet and the first data packet belonging to the uplink service; 4. The method of claim 2, wherein, determining the second time when the second data packet is generated by the terminal device based on the mapping relationship, the identifier of the first data packet and the period of the uplink service. The first information is further used to indicate one or more of the following: a first parameter, a burst arrival time BAT, an application layer processing deadline corresponding to the at least one uplink data packet, or the RTT requirement, the first parameter being used to determine a number of uplink data packets corresponding to the first data packet, the uplink data packets including the second data packet. The target PDB is a target uplink PDB.

5. The method of claim 4, wherein, The determining of the target PDB of the first data packet comprises:

6. The method of claim 1, wherein, receiving second information from the server, the second information being used to indicate an adjustment value of an uplink PDB of the first data packet, the adjustment value being related to the RTT requirement; adjusting a first uplink PDB to the target uplink PDB based on the adjustment value, the first uplink PDB being a current uplink PDB of the first data packet. The method further comprises: determining to increase or decrease the first uplink PDB; 7. The method of claim 6, wherein, sending third information to the server, the third information being used to indicate to increase or decrease the first uplink PDB. The method further comprises: ​ 8. The method of claim 7, wherein, ​ The fourth information is sent to the server, and the fourth information is used to indicate an adjustment range of the first uplink PDB, and the adjustment value belongs to the adjustment range, and the adjustment range of the uplink PDB is related to the RTT requirement.

9. The method according to claim 7 or 8, characterized in that, The first uplink PDB is determined to be adjusted up or down, including: The first uplink PDB is determined to be adjusted down based on one or more conditions that the downlink PDB in a preset time period is less than a first preset value, the downlink data volume is greater than a second preset value, a parameter value of a downlink channel state is less than a third preset value, or a delay requirement of a downlink data packet in a future period is greater than a first downlink PDB, and the first downlink PDB is a current downlink PDB of the first data packet. Or, the first uplink PDB is determined to be adjusted up based on one or more conditions that the downlink PDB in a preset time period is greater than or equal to a first preset value; the downlink data volume is less than or equal to a second preset value; a parameter value of a downlink channel state is greater than or equal to a third preset value; or a delay requirement of a downlink data packet in a future period is less than or equal to the first downlink PDB.

10. The method according to any one of claims 1 to 9, characterized in that, The RTT requirement is in a granularity of a first data packet set.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: A protocol data unit (PDU) session and a quality of service (QoS) flow are established, and the RTT requirement is included in a QoS parameter of the QoS flow.

12. A communication method characterized by comprising: Including: A mapping relationship between a generation time corresponding to at least one uplink data packet and an identifier of at least one downlink data packet is determined. First information is sent to a network side device, and the first information is used to indicate the mapping relationship and indicate a cycle of uplink service.

13. A communications device, characterized by The module for implementing the method of any one of claims 1 to 12 is included.

14. A communications device, characterized by The processor is used to execute the computer program and / or the logic circuit, so that the communication device implements the method of any one of claims 1 to 12.

15. The apparatus of claim 14, wherein, The memory is further included to store the computer program and / or the configuration file of the logic circuit.

16. The apparatus of claim 14 or 15, wherein, The communication interface is further included to input and / or output signals.

17. A computer-readable storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor, and the method of any one of claims 1 to 12 is executed.

18. A computer program product, characterised in that, The computer program is executed by the processor, and the method of any one of claims 1 to 12 is executed.

Images