A communication method and related device

Abstract

The application provides a communication method, comprising: receiving a pre-warning interval configured by a second device, the pre-warning interval being characterized by a delay critical threshold and a pre-warning interval upper limit, the pre-warning interval upper limit being determined according to the delay critical threshold and a pre-warning window length; when a first device detects that a delay status report (DSR) is in an active state, detecting whether the pre-warning interval includes pre-warning data to be reported; if yes, adding pre-warning information in the DSR, the pre-warning information including a data volume of the pre-warning data; and reporting the DSR to the second device, the DSR being used to instruct the second device to allocate resources for the pre-warning data. The method detects whether there is pre-warning data to be reported in the pre-warning interval when the DSR is active, and carries pre-warning information through the DSR if there is pre-warning data to be reported, so that the network side allocates resources for the pre-warning data based on the pre-warning information, without additional signaling, thus solving the picture frame drop and interaction delay problems caused by emergency scheduling of low-delay services, and ensuring service experience.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a communication method, communication device, first device, second device, communication system, computer-readable storage medium, and computer program product. Background Technology

[0002] In the continuous evolution of fifth-generation (5G) mobile communication technology, Release-19 (Rel-19), as an important iteration to meet the needs of emerging services, has one of its core objectives: to satisfy the scheduling requirements of low-latency, high-reliability services such as Augmented Reality (AR), Virtual Reality (VR), and Extended Reality (XR). These services are extremely sensitive to data transmission latency, typically requiring millisecond-level response capabilities. Any scheduling delays or resource shortages can directly lead to issues affecting user experience, such as screen stuttering and positioning errors, and may even cause service interruptions. Against this backdrop, Delay Status Reporting (DSR), as a Medium Access Control Element (MAC CE) that feeds back "delay critical / delay-reported data status" from user equipment (UE) to the network (NW), has become a core mechanism for optimizing the scheduling of low-latency services such as XR. Among them, DSR enables the network side to monitor the dynamics of latency-sensitive data on the UE side in real time, thereby accurately allocating transmission resources and ensuring smooth operation of services.

[0003] To clarify the operational rules of DSRs, the 3GPP TSG-RAN WG2 working group (THIRD GENERATION PARTNERSHIP PROJECT Technical Specification Group RadioAccess Network Work Group2) adopted the MAC-1 protocol consensus at Meeting #131. This consensus explicitly stipulates that "when a UE no longer possesses a delay-critical Service Data Unit (SDU), or when all delay-critical SDUs have been reported, the pending DSR will be cancelled without any additional conditions." This consensus completely adopts the DSR triggering and cancellation logic from 5G Rel-18, with the core judgment based solely on the "existence or absence of delay-critical SDUs," without providing additional definitions or constraints for other types of delay-related data.

[0004] However, the MAC-1 protocol consensus has revealed significant limitations in practical applications, including the lack of clarity regarding the reporting scenarios for "delay-reporting SDUs." In the UE's data transmission process, delay-reporting SDUs and delay-critical SDUs are not statically separate but rather dynamically transformed: the remaining transmission time of a delay-reporting SDU decreases over time. When this time falls below the network-side preset remaining time threshold (remainingTimeThreshold), the delay-reporting SDU automatically transforms into a delay-critical SDU. According to the MAC-1 protocol logic, the network can only obtain the delay status of the data through the new DSR triggered by the UE after the delay-reporting SDU has completed its transformation, thus initiating the resource allocation process. This "passive waiting for transformation" mode prevents the network from anticipating the existence of delay-reporting SDUs and their delay requirements, only allowing for "emergency scheduling" after the delay-reporting SDU becomes a delay-critical SDU. For services highly sensitive to latency, such as XR, this delayed scheduling method easily leads to insufficient resource reservation, ultimately causing issues like dropped frames and interaction delays, severely restricting the service experience. Summary of the Invention

[0005] This application provides a communication method and related equipment, aiming to solve the problem that lagging scheduling methods can easily lead to insufficient resource reservation for time-sensitive services, ultimately causing frame drops, interaction delays, and affecting service experience.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] The first aspect of this application provides a communication method. This method can be applied to a first device. The first device is a user-side device, including user equipment such as a terminal. Specifically, the first device can receive a warning interval configured by a second device. The warning interval is characterized by a delay key threshold and a warning interval upper limit, the upper limit of which is determined based on the delay key threshold and the warning window length. When the first device detects that a Delay Status Report (DSR) is active, the first device can detect whether the warning interval includes warning data to be reported. If so, the first device adds warning information to the DSR, the warning information including the amount of warning data. Then, the first device reports the DSR to the second device, which instructs the second device to allocate resources for the warning data.

[0008] This method detects whether there is any warning data to be reported within the warning interval when the DSR is active, such as a delayed-reporting SDU with a relatively small remaining transmission time. If warning data exists, the warning information is carried through the DSR, allowing the network to allocate resources based on the warning information, such as allocating resources for both delay-critical SDUs and delay-reporting SDUs simultaneously, without additional signaling. This solves the problem of dropped frames and interaction delays caused by emergency scheduling in low-latency services, ensuring a good service experience. If no warning data exists, only the status information of the delay-critical SDU is reported, and the network allocates resources only for the delay-critical SDU. This method avoids the DSR "cancel → re-trigger" loop by pre-configuring resources for reporting warning data (such as delayed-reporting SDUs with a relatively small remaining transmission time), and also solves the problem of insufficient resources after a delayed-reporting SDU is converted into a delay-critical SDU.

[0009] In some possible implementations, adding warning information to the DSR includes:

[0010] An alert field is added to the Media Access Control Element (MAC CE) of the DSR, and the field value of the alert field includes the amount of data in the alert data.

[0011] In some possible implementations, adding warning information to the DSR includes:

[0012] A first warning field and a second warning field are added to the MAC CE of the DSR. The field value of the first warning field includes the amount of data of the warning data, and the field value of the second warning field includes the shortest remaining time of the warning data.

[0013] In some possible implementations, the amount of the warning data is increased in the reserved field of the Media Access Control Element (MAC CE) of the DSR.

[0014] In some possible implementations, detecting whether the warning interval includes the warning data to be reported includes:

[0015] Receive service data unit (SDU) stream for the service, wherein the SDU stream includes at least one SDU;

[0016] Based on the remaining transmission time of the SDU, it is detected whether the warning interval includes warning data to be reported, wherein the warning data includes SDUs with remaining transmission time in the warning interval.

[0017] In some possible implementations, the method further includes:

[0018] Detect whether the SDU stream includes a delay-critical SDU based on the remaining transmission time of the SDU and the delay-critical threshold;

[0019] When the SDU stream includes the delay-critical SDU, it is determined that the DSR is in an active state.

[0020] In some possible implementations, the SDU stream includes a first SDU and a second SDU, wherein the first SDU is the delay-critical SDU and the second SDU is an early warning SDU, and the method further includes:

[0021] Receive resource information of the resources allocated by the second device for the first SDU and the second SDU;

[0022] The first SDU and the second SDU are transmitted through resources corresponding to the resource information;

[0023] When the transmission of the first SDU and the second SDU is completed and no delay-critical SDU is detected, the DSR is cancelled.

[0024] In some possible implementations, the resources corresponding to the resource information include a first resource and a second resource, and the transmission of the first SDU and the second SDU through the resources corresponding to the resource information includes:

[0025] The first SDU is transmitted through the first resource;

[0026] When the remaining transmission time of the second SDU decreases to the latency critical threshold, the second SDU is transmitted through the second resource.

[0027] A second aspect of this application provides a communication method. This method is applied to a second device, which is a network-side device, such as a base station or other network equipment.

[0028] In practice, the second device can send configuration information to the first device. This configuration information includes a warning interval, characterized by a delay key threshold and an upper limit. The upper limit is determined based on the delay key threshold and the warning window length. The second device can then receive a Data Set Report (DSR) reported by the first device. The DSR includes warning information, specifying the amount of warning data to be reported. The DSR indicates the allocation of resources for the warning data. The second device then allocates resources for the warning data based on the DSR.

[0029] This method carries early warning information in the DSR, enabling the network side to pre-allocate resources for early warning SDUs and other early warning data based on the early warning information when allocating resources for latency-critical SDUs. Under the premise of "not modifying the existing DSR triggering / cancellation rules", it realizes the collaborative management of latency-critical SDUs and early warning SDUs, which not only ensures compatibility with existing protocols, but also solves the resource reservation requirements of low-latency services (such as XR).

[0030] In some possible implementations, the warning data includes warning SDUs in the service data unit (SDU) stream of the service, and the DSR includes the warning information and the status information of delay-critical SDUs, wherein the delay-critical SDUs are SDUs in the SDU stream whose remaining transmission time is less than or equal to the delay-critical threshold.

[0031] The method further includes:

[0032] Resources are allocated to the latency-critical SDU based on the DSR.

[0033] A third aspect of this application provides a communication device. The device includes:

[0034] The communication module is used to receive a warning interval configured by the second device. The warning interval is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length.

[0035] The detection module is used to detect whether the warning interval includes warning data to be reported when the Delay Status Report (DSR) is detected to be active.

[0036] The early warning module is used to add early warning information to the DSR if the condition is met; the early warning information includes the data volume of the early warning data.

[0037] The communication module is also used to report the DSR to the second device, and the DSR is used to instruct the second device to allocate resources for the early warning data.

[0038] A fourth aspect of this application provides a communication device. The device includes:

[0039] The communication module is used to send configuration information to the first device. The configuration information includes a warning interval, which is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length.

[0040] The communication module is further configured to receive a DSR reported by the first device, the DSR including warning information, the warning information including the amount of warning data to be reported, and the DSR being used to indicate the allocation of resources for the warning data;

[0041] The resource allocation module is used to allocate resources to the early warning data according to the DSR.

[0042] The fifth aspect of this application provides a first device. The first device includes:

[0043] Memory is used to store computer programs or computer instructions;

[0044] A processor for executing a computer program or computer instructions stored in the memory, causing the first device to perform the method as described in any implementation of the first aspect.

[0045] A sixth aspect of this application provides a second device. The second device includes:

[0046] Memory is used to store computer programs or computer instructions;

[0047] A processor for executing a computer program or computer instructions stored in the memory, causing the second device to perform the method as described in any implementation of the second aspect.

[0048] A seventh aspect of this application provides a communication system. The communication system includes a first device and a second device, the first device being configured to perform the method described in any implementation of the first aspect, and the second device being configured to perform the method described in any implementation of the second aspect.

[0049] The eighth aspect of this application provides a computer storage medium for storing a computer program, which, when executed, implements the communication method provided in the first or second aspect of this application.

[0050] A ninth aspect of this application provides a computer program product containing instructions. When executed on a first device, it causes the first device to perform the method described in any implementation of the first aspect. When executed on a second device, it causes the second device to perform the method described in any implementation of the second aspect. Attached Figure Description

[0051] Figure 1This is a schematic diagram of the structure of a communication system disclosed in an embodiment of this application;

[0052] Figure 2 This is a flowchart of a communication method disclosed in an embodiment of this application;

[0053] Figure 3 This is a flowchart of a communication method disclosed in an embodiment of this application;

[0054] Figure 4 This is an interactive flowchart of a communication method disclosed in an embodiment of this application;

[0055] Figure 5 This is a schematic diagram of the structure of a communication device disclosed in an embodiment of this application;

[0056] Figure 6 This is a schematic diagram of another communication device disclosed in an embodiment of this application;

[0057] Figure 7 This is a hardware structure diagram of a first device disclosed in an embodiment of this application;

[0058] Figure 8 This is a hardware structure diagram of a second device disclosed in an embodiment of this application. Detailed Implementation

[0059] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to be a limitation of this application. As used in the specification and appended claims of this application, the singular expressions "a," "an," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the embodiments of this application, "one or more" refers to one, two, or more; "and / or" describes the relationship between related objects, indicating that three relationships may 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 that the preceding and following related objects are in an "or" relationship.

[0060] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0061] The "multiple" mentioned in the embodiments of this application refers to two or more. It should be noted that in the description of the embodiments of this application, terms such as "first" and "second" are used only for the purpose of distinguishing descriptions and should not be construed as indicating or implying relative importance, nor should they be construed as indicating or implying order.

[0062] The embodiments of this application are applied to communication systems. The communications in the communication system include, but are not limited to: long term evolution (LTE), 5th generation (5G), new radio (NR), 5G advanced (5GA), B5G, 6G, wireless communications related to the 3rd generation partnership project (3GPP), or a mixture of multiple wireless communications, or other wireless communications that may emerge in the future.

[0063] A communication system includes a first device and a second device. The first device is typically located on the user side and is also called user equipment, including terminals. The second device is located on the network side and is also called network equipment. Network equipment is the device on the network side used to provide network communication functions; in some cases, it is also called a network element. Network equipment can typically be a base station, a functional unit of a base station, or a combination of functional units of a base station. An example of a communication system is as follows... Figure 1 As shown, Figure 1 It includes base station 1 and terminal 2.

[0064] In the embodiments provided in this application, the base station can be any device with wireless transceiver capabilities, including but not limited to: evolved base stations (NodeB, eNB, or e-NodeB) in Long Term Evolution (LTE), base stations (gNodeB or gNB) or transmission receiving points / transmission reception points (TRPs) in New Radio (NR), base stations in subsequent 3GPP evolutions, access nodes in Wi-Fi systems, wireless relay nodes, wireless backhaul nodes, etc. The base station can be: macro base station, micro base station, pico base station, small cell, relay station, or balloon station, etc. The base station can include one or more co-located or non-co-located Transmission Reception Points (TRPs). The base station can also be a radio controller, centralized unit (CU), and / or distributed unit (DU) in a cloud radioaccess network (CRAN) scenario. The base station can communicate with the terminal, or it can communicate with the terminal through a relay station. The terminal can communicate with multiple base stations using different technologies. For example, the terminal can communicate with base stations that support LTE networks, base stations that support 5G networks, and can also establish dual connections with both LTE and 5G base stations.

[0065] In the embodiments provided in this application, the terminal can take various forms, such as a mobile phone, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, vehicle-mounted terminal device, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, wearable terminal device, etc. The terminal may also be referred to as terminal equipment, user equipment (UE), access terminal equipment, vehicle-mounted terminal, industrial control terminal, UE unit, UE station, mobile station, mobile station, remote station, remote terminal equipment, mobile device, UE terminal equipment, terminal equipment, wireless communication equipment, UE agent, or UE device, etc. The terminal can also be a fixed terminal or a mobile terminal.

[0066] Figure 1 This is an example of a communication system architecture applicable to embodiments of this application. Figure 1 The names of the various network elements included are merely names and do not limit the function of the network element itself. In 5G networks and other future networks, the aforementioned network elements may also have other names, and this application embodiment does not specifically limit this. For example, in 6G networks, some or all of the aforementioned network elements may use the terminology from 5G, or they may have other names, etc. This is uniformly explained here and will not be elaborated further below.

[0067] exist Figure 1 In the example, base station 1 and terminal 2 can transmit service data, which may include services that are currently or will be implemented in the future. For example, the service data may include service data for low-latency, high-reliability services such as Augmented Reality (AR), Virtual Reality (VR), and Extended Reality (XR).

[0068] Low-latency, high-reliability services, such as XR, are extremely sensitive to data transmission latency, typically requiring millisecond-level response times. Any scheduling delays or resource shortages can directly lead to issues affecting user experience, such as screen stuttering and positioning errors, and may even cause service interruptions. Therefore, Delay Status Reporting (DSR), as a MAC CE (Macro-Controlled Execution System) that allows user equipment (UE) to report "latency-critical / latency-reported data status" to the network, has become a core mechanism for optimizing the scheduling of low-latency services like XR. Specifically, DSR enables the network to monitor the dynamics of latency-sensitive data from the UE in real time, thereby accurately allocating transmission resources and ensuring smooth service operation.

[0069] 3GPP TSG-RAN WG2 stipulates through the MAC-1 protocol consensus that when a UE no longer has a delay-critical service data unit (SDU), or when all delay-critical SDUs have been reported, the pending DSR will be cancelled without any additional conditions.

[0070] However, the MAC-1 protocol consensus does not clearly define the reporting scenario for "delay-reporting SDUs". According to the MAC-1 protocol logic, the network side can only obtain the latency status of the data through the new DSR triggered by the UE after the delayed-reporting SDU has been converted, and then initiate the resource allocation process. This "passive waiting for conversion" mode makes it impossible for the network side to perceive the existence of delayed-reporting SDUs and their latency requirements in advance, and can only perform "emergency scheduling" after the delayed-reporting SDU becomes a latency-critical SDU. For services such as XR that are extremely sensitive to latency, this delayed scheduling method can easily lead to insufficient resource reservation, ultimately causing problems such as dropped frames and interaction delays, which seriously restricts the service experience.

[0071] Regarding the above scenarios, a certain consensus has been reached among mainstream solutions in the industry. Many telecommunications companies believe that delayed SDU reporting is non-urgent data and does not need to occupy the current DSR transmission resources. Their core arguments include two points: first, delayed SDU reporting can be completed through Buffer Status Reports (BSRs), without relying on the DSR mechanism; second, if delayed SDU reporting requires DSR feedback, it can wait until it is transformed into a delayed critical SDU before triggering a new DSR process. The aforementioned companies oppose retaining the current DSR for delayed reporting SDUs primarily based on three concerns: First, retaining DSRs for non-urgent delayed reporting SDUs would significantly increase the complexity of interaction between the UE and the network. The UE would need to additionally maintain the association status between delayed reporting SDUs and critical delayed SDUs, and the network would need to process more diverse feedback information. Second, this operation would break the protocol compatibility between 5G Rel-18 and Rel-19 versions. Rel-18 version UEs do not have the ability to handle DSRs associated with delayed reporting SDUs, which may lead to communication anomalies between cross-version devices. Third, redundant DSR usage would waste radio resources and increase the interaction costs between the MAC layer and higher protocol layers, such as the Packet Data Convergence Protocol (PDCP) layer, reducing overall communication efficiency. Therefore, the relevant solutions explicitly limit the cancellation conditions of DSRs strictly to "the UE has no critical delayed SDUs or all critical delayed SDUs have been reported," completely eliminating the impact of delayed reporting SDUs on the DSR status.

[0072] However, the drawbacks of these solutions have also become apparent, directly impacting the performance of low-latency services. On one hand, the "delayed reporting" characteristic of delayed SDUs leads to passive network scheduling. Since the network cannot obtain the delay information of delayed SDUs in advance, it can only initiate emergency scheduling after they are transformed into delay-critical SDUs. Emergency scheduling often lacks prior resource planning, easily resulting in insufficient resource allocation. Especially for XR services, even millisecond-level scheduling delays can cause positioning discrepancies between the virtual scene and the real environment, or cause screen stuttering due to untimely data transmission, severely damaging the user's immersive experience. On the other hand, the "cancel → re-trigger" loop of DSRs results in significant resource waste. When a delayed SDU is transformed into a delay-critical SDU, the UE needs to re-trigger a new DSR. During this process, the UE needs to repeatedly perform preprocessing operations, including calculating the actual data volume after the delayed SDU transformation, mapping the Logical Channel Group (LCG) to the corresponding threshold range, and triggering a scheduling request (SR). Simultaneously, the network also needs to re-parse the new DSR information and execute the resource allocation process again. More importantly, the re-triggered DSR may conflict with the signaling transmission of other LCGs, causing congestion in the overall scheduling queue and further reducing the scheduling efficiency of the communication system.

[0073] To address the aforementioned problems, this application proposes a communication method. This method can be applied to a communication system. The communication system includes a first device on the user side and a second device on the network side. The first device can be a terminal, and the second device can be a network device, such as a base station.

[0074] In practice, the first device can receive the warning interval configured by the second device. The warning interval is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. When the first device detects that the DSR is active, it checks whether the warning interval includes the warning data to be reported. If so, the first device adds warning information to the DSR, including the amount of warning data, and then reports the DSR to the second device. The DSR is used to instruct the second device to allocate resources for the warning data.

[0075] This method detects whether there is any warning data to be reported within the warning interval when the DSR is active, such as a delayed-reporting SDU with a relatively small remaining transmission time. If warning data exists, the warning information is carried through the DSR, allowing the network to allocate resources based on the warning information, such as allocating resources for both delay-critical SDUs and delay-reporting SDUs simultaneously, without additional signaling. This solves the problem of dropped frames and interaction delays caused by emergency scheduling in low-latency services, ensuring a good service experience. If no warning data exists, only the status information of the delay-critical SDU is reported, and the network allocates resources only for the delay-critical SDU. This method avoids the DSR "cancel → re-trigger" loop by pre-configuring resources for reporting warning data (such as delayed-reporting SDUs with a relatively small remaining transmission time), and also solves the problem of insufficient resources after a delayed-reporting SDU is converted into a delay-critical SDU.

[0076] To make the communication method of this application clearer and easier to understand, embodiments of the communication method of this application will be described in detail below with reference to the accompanying drawings.

[0077] See Figure 2 The flowchart illustrates a communication method that can be applied to a first device, which may include, but is not limited to, a terminal. The method specifically includes the following steps:

[0078] S202, The first device receives the warning range configured by the second device.

[0079] The warning interval is characterized by a critical delay threshold (denoted as T0) and an upper limit of the warning interval (denoted as T1). The upper limit of the warning interval T1 can be determined based on the critical delay threshold T0 and the warning window length (denoted as dsr-WarningWindow). The critical delay threshold T0 is equivalent to the remaining time threshold (remainingTimeThreshold). When the remaining transmission time of the service data to be transmitted (such as SDU) is ≤ T0, it is determined to be a critical delay SDU, triggering DSR. The `dsr-WarningWindow` is used to define a buffer space for SDUs that are about to become delay-critical, preventing the network from being caught in a resource scheduling slump due to sudden data demands. In some examples, T1 = T0 + `dsr-WarningWindow`. Parameters T0 and `dsr-WarningWindow` can be dynamically adjusted by the network side based on the current service type of the first device (e.g., UE). Service types can include XR, high-definition video, etc. When the remaining transmission time of the service data to be transmitted (e.g., SDU) ∈ (T0, T1), it is determined to be a warning SDU. Warning SDUs belong to a subset of delay-reporting SDUs and have the characteristic of "high probability of becoming delay-critical SDUs".

[0080] The warning interval is the core threshold range that distinguishes between "ordinary delay reporting SDUs" and "warning SDUs that are about to become critical delay SDUs". It can be statically or dynamically configured by the network side to the first device (such as UE and other terminals) through Radio Resource Control (RRC) signaling, without the need for additional signaling interaction, and fully reuses the existing RRC configuration channel.

[0081] Based on this, the first device can receive the T0 and dsr-WarningWindow parameters sent by the second device on the network side through the RRC connection reconfiguration signaling, and then store them in the local MAC layer configuration register. The remaining transmission time of all subsequent service data to be transmitted (such as SDU) can be determined based on these parameters.

[0082] S204. When the first device detects that the DSR is in an active state, the first device checks whether the warning range includes the warning data to be reported. If so, proceed to S206.

[0083] In this application, the DSR coordination logic strictly follows the core rule of "delaying critical SDUs to trigger / cancel DSR" in the [MAC-1] protocol. Only when the DSR is active (i.e., the first device has unreported delayed critical SDUs) is a new "early warning SDU detection - information reporting" step added.

[0084] Based on this, the first device can detect whether a DSR is active. Specifically, the first device can receive a service SDU stream, which includes at least one SDU. The first device can then detect whether the SDU stream includes a delay-critical SDU based on the remaining transmission time of the SDU and a delay-critical threshold. When the SDU stream includes a delay-critical SDU, the first device determines that the DSR is active. For example, if the remaining transmission time of an SDU in the SDU stream is less than or equal to the delay-critical threshold, the first device determines that the SDU stream includes a delay-critical SDU and that the DSR is active.

[0085] Furthermore, the first device can detect whether the warning interval includes the warning data to be reported based on the remaining transmission time of the SDU. The warning data includes SDUs with remaining transmission time within the warning interval.

[0086] To facilitate understanding, this application also provides an example. In this example, when the UE initiates an XR service, the network side can configure T0 to 8 milliseconds (ms) and the dsr-WarningWindow to 3ms, i.e., T1=11ms, ensuring that the warning SDU has a 3ms "early reporting buffer period". The SDU stream can include SDU1, SDU2, and SDU3, where the remaining transmission times for SDU1 to SDU3 are 10ms, 15ms, and 6ms, respectively. Correspondingly, SDU1 is the warning SDU, and SDU3 is the delay-critical SDU.

[0087] S206. The first device adds early warning information to the DSR.

[0088] The warning information includes the amount of warning data. This amount of data can include the total amount of data for the warning SDUs (e.g., the sum of the data for multiple warning SDUs). Furthermore, the warning information may also include the minimum remaining time for the warning data. For example, if the warning data includes multiple warning SDUs, the minimum remaining time can be the minimum of the remaining transmission times for those multiple warning SDUs.

[0089] In some possible implementations, to achieve efficient transmission of warning information, the first device can incrementally extend the MAC CE structure of the DSR, adding a warning field to each DSR MAC CE without modifying existing fields (such as the amount of data for critical SDUs). Specifically, the first device can add a warning field to the DSR MAC CE. The field value of the warning field includes the amount of warning data. The warning field can be filled only when a warning SDU exists; otherwise, it should be filled with "0" to avoid interfering with existing protocol parsing logic. In some examples, the first device can add a first warning field and a second warning field to the DSR MAC CE. The field value of the first warning field includes the amount of warning data, such as the amount of data in the T0-T1 interval, and the field value of the second warning field includes the shortest remaining time for the warning data, such as the shortest remaining time for the warning SDU. The design of both warning fields revolves around the "network resource allocation decision requirements," providing key information about the warning SDU from the two dimensions of "resource scale" and "urgency," as defined in the table below:

[0090] Table 1

[0091] Add field name Field definition core role Data volume in the T0-T1 interval Total number of bytes for all warning SDUs with remaining time ∈ (T0, T1] (cumulative effective data amount of all warning SDUs under this LCG) The network assesses and warns of the resource demand of SDUs to avoid insufficient resource allocation or excessive reservation. Early warning SDU minimum remaining time Minimum remaining time (in ms) for all warning SDUs under this LCG. The network determines the urgency of an early warning SDU becoming a delay-critical SDU, and reserves resources for higher-priority early warning SDUs.

[0092] In some other possible implementations, the first device can increase the amount of warning data in the reserved field of the MAC CE of the DSR. Similarly, the first device can increase the minimum remaining time of the warning data in the reserved field of the MAC CE of the DSR.

[0093] S208. The first device reports DSR to the second device. The DSR is used to instruct the second device to allocate resources for the early warning data.

[0094] Specifically, the first device can report DSR to the second device in the form of a DSR MAC CE by assembling a DSR MAC CE and sending it to the second device. This DSR is used not only to instruct the second device to allocate resources for delay-critical data (such as delay-critical SDUs), but also to instruct the second device to allocate resources for early warning data (such as early warning SDUs).

[0095] Furthermore, the SDU stream of the service received by the first device includes a first SDU and a second SDU, wherein the first SDU is a delay-critical SDU and the second SDU is an early warning SDU. The first device can also receive resource information of the resources allocated by the second device for the first and second SDUs. This resource information indicates the available resources for transmitting data (such as the first and second SDUs). Resources may include Physical Resource Blocks (PRBs). PRBs, as units of physical resource allocation, include contiguous resource blocks in both the time and frequency domains.

[0096] Accordingly, the first device can transmit the first SDU and the second SDU through resources corresponding to the resource information. The resources corresponding to the resource information include the first resource and the second resource, such as the first PRB and the second PRB. When transmitting the first SDU and the second SDU, the first device can transmit the first SDU through the first resource. When the remaining transmission time of the second SDU decreases to a delay critical threshold, the first device can transmit the second SDU through the second resource. When the transmission of the first SDU and the second SDU is complete, and no delay critical SDU is detected, the first device can cancel the DSR (Delay Reduction Service).

[0097] The above describes a scenario where the first device detects DSR activation (if there is a delayed critical SDU) and an early warning SDU exists. In this scenario, the first device appends early warning information to the MAC CE of the current DSR, such as the data volume in the T0-T1 interval and the minimum remaining time of the early warning SDU. This allows the early warning information to be reported to the network side along with the status information of the delayed critical SDU. Accordingly, the network side can jointly allocate resources based on "current critical needs + future early warning needs," without waiting for the early warning SDU to become a critical SDU before re-triggering the DSR.

[0098] In scenarios where the first device detects DSR activation but does not detect warning data (such as warning SDUs), for example, if a delay-critical SDU is detected but no SDU is in the (T0,T1] range, the first device can report the status information of the delay-critical SDU (such as data volume, LCG to which it belongs, etc.). The network side only allocates resources for the delay-critical SDU, which is completely consistent with the Rel-18 / 19 process.

[0099] It should be noted that when the first device does not detect DSR activation (e.g., no delay-critical SDU), the first device does not perform any warning SDU detection, nor does it report any warning information. In this case, the warning SDU will wait until the remaining time is ≤T0 before becoming a delay-critical SDU, and then trigger a new DSR, ensuring full compatibility with the MAC-1 rules.

[0100] Based on the above description, the communication method of this application addresses the scheduling lag and resource waste problems in the processing of delayed SDUs in the DSR mechanism. On the basis of strictly following the 3GPP TSG-RAN WG2 [MAC-1] protocol consensus (based only on triggering / canceling DSR based on delay-critical SDUs), it subdivides the status of delayed SDUs and other data through "early warning intervals" and realizes on-demand reporting of early warning information based on the activation status of DSR. Under the premise of "not modifying the existing DSR triggering / canceling rules", it realizes the collaborative management of delay-critical SDUs and early warning SDUs, which not only ensures compatibility with existing protocols, but also solves the resource reservation requirements of low-latency services (such as XR).

[0101] Figure 2 The illustrated embodiment describes the communication method from the perspective of a first device. The following describes the communication method from the perspective of a second device.

[0102] See Figure 3 The flowchart illustrates a communication method applied to a second device, which may include a network device, such as a base station. The method includes the following steps:

[0103] S302, The second device sends configuration information to the first device.

[0104] The configuration information includes a warning interval, which is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. Based on this, the second device can send the delay key threshold and the warning window length to the first device, or the second device can send the delay key threshold and the warning interval upper limit to the first device. This application does not impose any limitations on this.

[0105] When the second device sends configuration information to the first device, it can use RRC signaling to statically or dynamically configure the first device without adding additional signaling interaction, thus fully reusing the existing RRC configuration channel.

[0106] S304. The second device receives the DSR reported by the first device.

[0107] The DSR can include warning information. This warning information includes the amount of warning data to be reported. The warning data can be warning SDUs in the service's SDU stream. The DSR is used to indicate the allocation of resources for the warning data. Furthermore, the warning information can also include the minimum remaining time for the warning data. For example, the DSR can include the total amount of warning SDU data and the minimum remaining transmission time for the warning SDUs.

[0108] In some possible implementations, the DSR may include not only warning information but also status information of delay-critical SDUs. Delay-critical SDUs are those SDUs in the SDU stream whose remaining transmission time is less than or equal to a delay-critical threshold. Warning SDUs can be SDUs whose remaining transmission time is within the warning interval. Thus, the DSR can instruct the joint allocation of resources for delay-critical SDUs and warning SDUs to meet current critical needs and future warning needs, without waiting for warning SDUs to transform into delay-critical SDUs.

[0109] S306. The second device allocates resources for the early warning data based on the DSR.

[0110] Specifically, the second device can allocate resources for early warning SDUs and other early warning data based on the early warning information in the DSR. It should be noted that the DSR also includes the status information of delay-critical SDUs. Correspondingly, the second device can allocate resources for delay-critical SDUs based on the DSR. In practical implementation, the second device can jointly allocate resources for both early warning SDUs and delay-critical SDUs based on the early warning information and the status information of the delay-critical SDUs.

[0111] Based on the above description, this application provides a communication method. This method carries early warning information in the DSR (Delay-Sensitive Resource Provider), enabling the network side to pre-allocate resources for early warning SDUs and other early warning data based on the early warning information when allocating resources for delay-critical SDUs. Under the premise of "not modifying existing DSR triggering / cancellation rules," this method achieves collaborative management of delay-critical SDUs and early warning SDUs, ensuring compatibility with existing protocols while addressing the resource reservation requirements of low-latency services (such as XR).

[0112] To make the technical solution of this application clearer and easier to understand, the communication method of this application will be introduced from the perspective of interaction in combination with specific application scenarios below.

[0113] Taking XR service initiation by a terminal (such as a UE) as an example, this paper details the implementation process of the solution, combining the interaction flow between the terminal and the network. The RRC configuration parameters are T0=10ms and dsr-WarningWindow=5ms (i.e., T1=15ms). See [link / reference] Figure 4 The flowchart of a communication method is shown below, and the specific steps are as follows:

[0114] S402. The network device sends DSR configuration parameters to the terminal.

[0115] Specifically, network devices can send XR service-specific DSR configuration parameters to terminals via RRC Connection Reconfiguration signaling: T0=10ms, dsr-WarningWindow=5ms.

[0116] S404. The terminal detects whether there is a delay-critical SDU. If so, keep DSR active.

[0117] S406. Does the terminal detect whether there is a warning SDU in the warning range?

[0118] S408. The terminal sends a DSR to the network device. The DSR includes status information and warning information of the delay-critical SDU.

[0119] Specifically, when a terminal receives an RRC Connection Reconfiguration signaling message, it can initiate the MAC layer's state detection module for detection. In this example, the detection period is assumed to be 1ms.

[0120] When detecting delay-critical SDUs, the terminal can receive the SDU stream of XR services from the PDCP layer. In this example, the remaining transmission times of the three SDUs in the SDU stream are: SDU1 (8ms, ≤T0), SDU2 (12ms, ∈(10,15]), and SDU3 (14ms, ∈(10,15]). The terminal detects SDU1 as a "delay-critical SDU", triggering DSR activation, which conforms to the MAC-1 rule. At the same time, the terminal detects SDU2 and SDU3 as "early warning SDUs", and enters the early warning information calculation stage.

[0121] The warning information can include the amount of data in the T0-T1 interval and the minimum remaining time of the warning SDU. In this example, the amount of data in the T0-T1 interval = SDU2 payload (180 bytes) + SDU3 payload (160 bytes) = 340 bytes; the minimum remaining time of the warning SDU = min(12ms, 14ms) = 12ms. The terminal can temporarily store the results in the warning information buffer.

[0122] The terminal can then trigger a scheduling request (SR), and the network device can allocate uplink resources to the terminal through an uplink grant (UL Grant). Next, the terminal can assemble a Delay-Specific MAC CE (DSR MAC CE), which includes the data volume of the delay-critical SDU, the data volume in the T0-T1 interval, and the minimum remaining time for the warning SDU. Specifically, for the XR service-specific LCG, such as LCG 3, the data volume of the delay-critical SDU can be the data volume of SDU1, such as 200 bytes; the data volume in the T0-T1 interval can be the total data volume of SDU2 and SDU3, such as 340 bytes; and the minimum remaining time for the warning SDU can be the minimum remaining transmission time from SDU1 to SDU3, such as 12ms. The terminal can then encapsulate the DSR MAC CE into a MAC PDU and report it to the network device using the allocated uplink resources.

[0123] S410, the network device parses the warning information and the status information of the delay-critical SDU in the DSR.

[0124] Specifically, the network device parses the DSR and confirms that there is a latency-critical SDU (data size of 200 bytes, requiring 2 PRB basic resources) in LCG 3, and there is also a warning SDU (data size of 340 bytes ≥ 200 bytes, minimum remaining time 12ms = T0 + 2ms).

[0125] S412. Network devices allocate resources to latency-critical SDUs and early warning SDUs based on the resolution results.

[0126] Specifically, the network device can calculate the total resources, for example, 2 PRBs of basic resources + 2 PRBs of additional resources = 4 PRBs, and then send the resource information to the terminal via UL Grant signaling. The resource information may include the temporal location of the resources. Furthermore, the resource information may also include the number of resources. For example, the resource information may include: 4 PRBs, with the temporal location being subframes 10-13.

[0127] S414, Terminal uses allocated resources to transmit delay critical SDU.

[0128] S416. Check if the remaining transmission time of the terminal detection and warning SDU is ≤ T0. If yes, execute S418.

[0129] S418, Terminal uses allocated resources to transmit early warning SDUs and convert delay-critical SDUs.

[0130] Specifically, the terminal prioritizes using basic resources (such as 2PRB) to transmit SDU1 (a delay-critical SDU), which can typically be completed within 1ms. The terminal can then wait for the remaining time of the warning SDU to decrease. When the remaining time of SDU2 drops from 12ms to 10ms (≤T0), SDU2 becomes a delay-critical SDU. The terminal can then directly use reserved additional resources (such as 2PRB) to transmit SDU2 and SDU3. Since the resources have been pre-allocated, there is no need to trigger a new DSR.

[0131] S420: The terminal checks if there are any delay-critical SDUs yet to be transmitted. If not, proceed to S422.

[0132] S422, Terminal cancels DSR.

[0133] Specifically, after SDU1, SDU2, and SDU3 have all been transmitted, the terminal detects the critical SDU with no delay and cancels the DSR according to the rules.

[0134] Based on the above description, this application provides a communication method. In this method, when a terminal has an active DSR (i.e., a delay-critical SDU), it detects whether a delay-reporting SDU (i.e., a warning SDU) exists within the warning interval. If it exists, the DSR carries warning information such as the data volume in the T0-T1 interval and the shortest remaining time of the warning SDU. The network device allocates resources to both the delay-critical SDU and the warning SDU based on the warning information, without additional signaling. If it does not exist, only the status information of the delay-critical SDU is reported, and the network device allocates resources only to the delay-critical SDU. This avoids the DSR "cancellation → re-triggering" cycle and solves the problem of insufficient resources after a delay-reporting SDU is converted into a delay-critical SDU.

[0135] The above Figures 2 to 4 The communication method described in this application has been introduced. This application also provides a communication device corresponding to the above-described communication method, which will be described below from the perspective of functional modularity.

[0136] First, see Figure 5 The diagram shows the structure of a communication device 500, which is used to implement... Figure 2 The communication method shown specifically includes:

[0137] Communication module 502 is used to receive a warning interval configured by the second device, wherein the warning interval is characterized by a delay key threshold and a warning interval upper limit, and the warning interval upper limit is determined according to the delay key threshold and the warning window length;

[0138] The detection module 504 is used to detect whether the warning interval includes warning data to be reported when the Delay Status Report (DSR) is detected to be active.

[0139] The early warning module 506 is used to add early warning information to the DSR if the condition is met, wherein the early warning information includes the amount of data of the early warning data.

[0140] The communication module 502 is also used to report the DSR to the second device, and the DSR is used to instruct the second device to allocate resources for the early warning data.

[0141] For example, the communication module 502, detection module 504, and early warning module 506 described above can be implemented in hardware or in software.

[0142] When implemented in software, the communication module 502, detection module 504, and early warning module 506 can be applications running on the first device (such as a terminal). These applications can also be virtualized and provided to users as virtualized services.

[0143] When implemented in hardware, the communication module 502 may include a transceiver module, such as a wireless communication module. The detection module 504 and the early warning module 506 may be implemented using a processor.

[0144] In some possible implementations, the early warning module 506 is specifically used for:

[0145] An alert field is added to the Media Access Control Element (MAC CE) of the DSR, and the field value of the alert field includes the amount of data in the alert data.

[0146] In some possible implementations, the early warning module 506 is specifically used for:

[0147] A first warning field and a second warning field are added to the MAC CE of the DSR. The field value of the first warning field includes the amount of data of the warning data, and the field value of the second warning field includes the shortest remaining time of the warning data.

[0148] In some possible implementations, the early warning module 506 is specifically used for:

[0149] Increase the amount of the warning data in the reserved field of the Media Access Control Element (MAC CE) of the DSR.

[0150] In some possible implementations, the detection module 504 is specifically used for:

[0151] Receive service data unit (SDU) stream for the service, wherein the SDU stream includes at least one SDU;

[0152] Based on the remaining transmission time of the SDU, it is detected whether the warning interval includes warning data to be reported, wherein the warning data includes SDUs with remaining transmission time in the warning interval.

[0153] In some possible implementations, the detection module 504 is also used for:

[0154] Detect whether the SDU stream includes a delay-critical SDU based on the remaining transmission time of the SDU and the delay-critical threshold;

[0155] When the SDU stream includes the delay-critical SDU, it is determined that the DSR is in an active state.

[0156] In some possible implementations, the SDU stream includes a first SDU and a second SDU, wherein the first SDU is the delay-critical SDU and the second SDU is an early warning SDU, and the communication module 502 is further configured to:

[0157] Receive resource information of the resources allocated by the second device for the first SDU and the second SDU;

[0158] The first SDU and the second SDU are transmitted through resources corresponding to the resource information;

[0159] The communication device 500 further includes:

[0160] DSR management module 508 is used to cancel the DSR when the transmission of the first SDU and the second SDU is completed and no delay-critical SDU is detected.

[0161] In some possible implementations, the resources corresponding to the resource information include a first resource and a second resource, and the communication module 502 is specifically used for:

[0162] The first SDU is transmitted through the first resource;

[0163] When the remaining transmission time of the second SDU decreases to the latency critical threshold, the second SDU is transmitted through the second resource.

[0164] Next, see Figure 6 The diagram shows another communication device, communication device 600 is used to implement... Figure 3 The communication method shown specifically includes:

[0165] Communication module 602 is used to send configuration information to the first device. The configuration information includes a warning interval, which is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length.

[0166] The communication module 602 is further configured to receive a DSR reported by the first device, the DSR including warning information, the warning information including the amount of warning data to be reported, and the DSR being used to indicate the allocation of resources for the warning data;

[0167] Resource allocation module 604 is used to allocate resources to the early warning data according to the DSR.

[0168] For example, the communication module 602 and the resource allocation module 604 described above can be implemented in hardware or in software.

[0169] When implemented in software, the communication module 602 and the resource allocation module 604 can be applications running on a second device (such as a network device like a base station). These applications can also be virtualized and provided to users as virtualized services.

[0170] When implemented in hardware, the communication module 502 may include a transceiver module, such as a transceiver unit, including a receiver and a transmitter. The resource allocation module 604 may be implemented using a processor.

[0171] In some possible implementations, the warning data includes warning SDUs in the service data unit (SDU) stream of the service, and the DSR includes the warning information and the status information of delay-critical SDUs, wherein the delay-critical SDUs are SDUs in the SDU stream whose remaining transmission time is less than or equal to the delay-critical threshold.

[0172] The resource allocation module 604 is also used for:

[0173] Resources are allocated to the latency-critical SDU based on the DSR.

[0174] This application also provides a first device for implementing Figure 5 The function of the communication device 500 shown, or its execution Figure 2 The communication method is shown below. The first device will then be described from a hardware implementation perspective.

[0175] Figure 7 This application provides an example of the composition of a first device. The first device may be a terminal, including but not limited to mobile phones, smart wearable devices (such as smartwatches), and other electronic devices. Taking a mobile phone as an example, the first device may include a processor 710, an external memory interface 720, an internal memory 721, a display screen 730, a camera 740, antenna 1, antenna 2, a mobile communication module 750, and a wireless communication module 760, etc.

[0176] It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on the first device. In other embodiments, the first device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0177] The processor 710 may include one or more processing units, such as an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). These different processing units may be independent devices or integrated into one or more processors.

[0178] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a limitation on the structure of the electronic device. In other embodiments of this application, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0179] The external memory interface 720 can be used to connect external memory cards, such as Micro SD cards, to expand the storage capacity of electronic devices. The external memory card communicates with the processor 710 through the external memory interface 720 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0180] Internal memory 721 can be used to store executable program code, including instructions. Processor 710 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 721. Internal memory 721 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of the electronic device (such as audio data, phonebook, etc.). Furthermore, internal memory 721 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc. Processor 710 executes various functional applications and data processing of the electronic device by running instructions stored in internal memory 721 and / or instructions stored in memory located within the processor.

[0181] The wireless communication function of electronic devices can be implemented through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, modem processor, and baseband processor.

[0182] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in the electronic device can be used to cover one or more communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with a tuning switch.

[0183] The mobile communication module 750 can provide solutions for wireless communication applications including 2G / 7G / 4G / 5G / 7G in electronic devices. The mobile communication module 750 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 750 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 750 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1. In some embodiments, at least some functional modules of the mobile communication module 750 may be housed in the processor 710. In some embodiments, at least some functional modules of the mobile communication module 750 and at least some modules of the processor 710 may be housed in the same device.

[0184] In some embodiments, the electronic device initiates or receives call requests via the mobile communication module 750 and the antenna 1.

[0185] In addition, an operating system runs on top of the aforementioned components. Examples include iOS, Android, and Windows. Applications can be installed and run on this operating system.

[0186] This application also provides a second device for implementing Figure 6 The function of the communication device 600 shown, or the execution of... Figure 3 The communication method is shown below. The second device will then be introduced from a hardware implementation perspective. Figure 8 This application provides an example of the composition of a second device. The second device may be a network device, such as a base station. Figure 8 A simplified schematic diagram of a base station structure is shown. The base station includes sections 810, 820, and 830. Section 810 is mainly used for baseband processing and base station control; section 810 is typically the control center of the base station, often referred to as a processor, used to control the base station to perform processing operations on the network device side in the above method embodiments. Section 820 is mainly used to store computer program code and data. Section 830 is mainly used for the transmission and reception of radio frequency signals and the conversion between radio frequency signals and baseband signals; section 830 is often referred to as a transceiver module, transceiver, transceiver circuit, or transceiver unit. The transceiver module of section 830, also referred to as a transceiver or transceiver unit, includes an antenna 833 and a radio frequency circuit (not shown in the figure), where the radio frequency circuit is mainly used for radio frequency processing. Optionally, the device in section 830 used to implement the receiving function can be regarded as a receiver, and the device used to implement the transmitting function can be regarded as a transmitter; that is, section 830 includes a receiver 832 and a transmitter 831. A receiver can also be called a receiving module, receiver, or receiving circuit, while a transmitter can be called a transmitting module, transmitter, or transmitting circuit.

[0187] Sections 810 and 820 may include one or more circuit boards, each of which may include one or more processors and one or more memories. The processors are used to read and execute programs from the memories to implement baseband processing functions and control the base station. If multiple circuit boards exist, they can be interconnected to enhance processing capabilities. As an alternative implementation, multiple circuit boards may share one or more processors, multiple circuit boards may share one or more memories, or multiple circuit boards may simultaneously share one or more processors.

[0188] For example, in one implementation, the transceiver module of part 830 is used to perform... Figure 3 The transmit / receive related processes are performed by the base station in the illustrated embodiment. The processor in the 810 part is used to execute... Figure 3 The process related to the processing performed by the base station in the illustrated embodiment.

[0189] It should be understood that Figure 8 This is for illustrative purposes only and not as a limitation. The network devices mentioned above, including processors, memory, and transceivers, may be independent of... Figure 8 The structure shown.

[0190] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the explanations and beneficial effects of the relevant content in any of the communication devices provided above can be referred to the corresponding method embodiments provided above, and will not be repeated here.

[0191] In this application, the terminal or network device may include a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on top of the operating system layer. The hardware layer may include hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory (also known as main memory). The operating system layer may be any one or more computer operating systems that implement business processing through processes, such as Linux, Unix, Android, iOS, or Windows. The application layer may include applications such as browsers, address books, word processing software, and instant messaging software.

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

[0193] 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 modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 indirect coupling or communication connection through some interfaces, apparatuses, or modules, and may be electrical, mechanical, or other forms.

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

[0195] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0196] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the essential contribution of the technical solution of this application, or all or part 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, server, or network device, etc.) to execute all or part of the processes 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.

[0197] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A communication method, characterized in that, Applied to a first device, the method includes: The system receives a warning interval configured by a second device. The warning interval is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. When the first device detects that the Delay Status Report (DSR) is active, it checks whether the warning interval includes warning data to be reported. If so, add warning information to the DSR, the warning information including the amount of data of the warning data; The DSR is reported to the second device, and the DSR is used to instruct the second device to allocate resources for the warning data.

2. The method according to claim 1, characterized in that, The addition of warning information to the DSR includes: An alert field is added to the Media Access Control Element (MAC CE) of the DSR, and the field value of the alert field includes the amount of data in the alert data.

3. The method according to claim 1, characterized in that, The addition of warning information to the DSR includes: A first warning field and a second warning field are added to the MAC CE of the DSR. The field value of the first warning field includes the amount of data of the warning data, and the field value of the second warning field includes the shortest remaining time of the warning data.

4. The method according to claim 1, characterized in that, The addition of warning information to the DSR includes: Increase the amount of the warning data in the reserved field of the Media Access Control Element (MAC CE) of the DSR.

5. The method according to any one of claims 1 to 4, characterized in that, The detection of whether the warning interval includes the warning data to be reported includes: Receive service data unit (SDU) stream for the service, wherein the SDU stream includes at least one SDU; Based on the remaining transmission time of the SDU, it is detected whether the warning interval includes warning data to be reported, wherein the warning data includes SDUs with remaining transmission time in the warning interval.

6. The method according to claim 5, characterized in that, The method further includes: Detect whether the SDU stream includes a delay-critical SDU based on the remaining transmission time of the SDU and the delay-critical threshold; When the SDU stream includes the delay-critical SDU, it is determined that the DSR is in an active state.

7. The method according to claim 6, characterized in that, The SDU stream includes a first SDU and a second SDU, wherein the first SDU is the delay-critical SDU and the second SDU is an early warning SDU, and the method further includes: Receive resource information of the resources allocated by the second device for the first SDU and the second SDU; The first SDU and the second SDU are transmitted through resources corresponding to the resource information; When the transmission of the first SDU and the second SDU is completed and no delay-critical SDU is detected, the DSR is cancelled.

8. The method according to claim 7, characterized in that, The resources corresponding to the resource information include a first resource and a second resource. The step of transmitting the first SDU and the second SDU through the resources corresponding to the resource information includes: The first SDU is transmitted through the first resource; When the remaining transmission time of the second SDU decreases to the latency critical threshold, the second SDU is transmitted through the second resource.

9. A communication method, characterized in that, Applied to a second device, the method includes: Send configuration information to the first device. The configuration information includes a warning interval, which is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. The device receives a DSR reported by the first device. The DSR includes warning information, which includes the amount of warning data to be reported. The DSR is used to indicate the allocation of resources for the warning data. Resources are allocated to the early warning data based on the DSR.

10. The method according to claim 9, characterized in that, The early warning data includes early warning SDUs in the service data unit (SDU) stream of the service. The DSR includes the early warning information and the status information of delay-critical SDUs. The delay-critical SDUs are SDUs in the SDU stream whose remaining transmission time is less than or equal to the delay-critical threshold. The method further includes: Resources are allocated to the latency-critical SDU based on the DSR.

11. A communication device, characterized in that, The device includes: The communication module is used to receive a warning interval configured by the second device. The warning interval is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. The detection module is used to detect whether the warning interval includes warning data to be reported when the Delay Status Report (DSR) is detected to be active. The early warning module is used to add early warning information to the DSR if the condition is met; the early warning information includes the data volume of the early warning data. The communication module is also used to report the DSR to the second device, and the DSR is used to instruct the second device to allocate resources for the early warning data.

12. A communication device, characterized in that, The device includes: The communication module is used to send configuration information to the first device. The configuration information includes a warning interval, which is characterized by a delay key threshold and a warning interval upper limit. The warning interval upper limit is determined based on the delay key threshold and the warning window length. The communication module is further configured to receive a DSR reported by the first device, the DSR including warning information, the warning information including the amount of warning data to be reported, and the DSR being used to indicate the allocation of resources for the warning data; The resource allocation module is used to allocate resources to the early warning data according to the DSR.

13. A first device, characterized in that, The first device includes: Memory is used to store computer programs or computer instructions; A processor for executing a computer program or computer instructions stored in memory, causing the first device to perform the method as described in any one of claims 1 to 8.

14. A second device, characterized in that, The second device includes: A processor for executing a computer program or computer instructions stored in memory, causing the second device to perform the method as described in claim 9 or 10.

15. A communication system, characterized in that, The communication system includes a first device and a second device, wherein the first device is used to perform the communication method as described in any one of claims 1 to 8, and the second device is used to perform the communication method as described in claim 9 or 10.

16. A computer storage medium, characterized in that, The computer storage medium is used to store a computer program, which, when executed, is used to implement the communication method as described in any one of claims 1 to 10.

17. A computer program product, characterized in that, Includes computer-readable instructions; the computer-readable instructions are used to implement the communication method as described in any one of claims 1 to 10.

Images