A communication method and apparatus
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HUAWEI TECH CO LTD
- Filing Date
- 2025-02-07
- Publication Date
- 2026-08-07
AI Technical Summary
[0089] The specific content and achievable technical effects of any of the above-mentioned aspects 2 to 4 and 6 to 10 can be referred to the descriptions in the above-mentioned aspects 1 or 5, and the repetitions will not be discussed.
Smart Images

Figure CN122534652A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology
[0002] With the continuous development of wireless communication systems, data transmission latency is constantly decreasing. To meet latency requirements, communication systems have introduced delay status reports (DSRs). Terminals can trigger DSRs, which are used to report information related to data latency. After a DSR is triggered, if the terminal sends the relevant DSR information, the access network device can schedule resources for the terminal based on that information.
[0003] After a DSR is triggered, it can be considered pending or suspended. Further research is needed on how to cancel a DSR. Summary of the Invention
[0004] This application provides a communication method and apparatus for canceling DSR.
[0005] In a first aspect, embodiments of this application provide a communication method that can be applied to a first device or an apparatus of the first device. The first device includes a Packet Data Convergence Protocol (PDCP) entity, and a first Media Access Control (MAC) entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data from the first device. Optionally, the first device may be a terminal; the apparatus for the first device may be a module for the terminal (e.g., a communication module, circuitry or chip responsible for communication and / or sensing functions (such as a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip or system-in-package (SIP) chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the terminal functions. For ease of description, the following explanation uses a first device as an example. It should be understood that when the first device is used as the execution subject in the following text, the first device can be replaced by an apparatus for the first device.
[0006] The method may include: a first device triggering a first DSR corresponding to a first MAC entity. If the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold, the first device may cancel the first DSR. Here, the first data volume is the total data volume of at least one latency-critical data associated with the first DSR, and the at least one latency-critical data includes latency-critical data for each of N1 entities, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first radio link control (RLC) entity, where the first RLC entity is the entity between the PDCP entity and the first MAC entity.
[0007] For example, the latency-critical data of a PDCP entity includes at least one of the following: a latency-critical PDCP service data unit (SDU) that is not constructed as a PDCP data protocol data unit (PDU), a lower-layer PDCP data PDU containing a latency-critical PDCP SDU that has not yet been transmitted to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted.
[0008] For example, the latency critical data of the first RLC entity includes at least one of the following: a latency critical RLC SDU or a latency critical RLC SDU segment that has not been constructed as an RLC dataPDU, an RLC data PDU to be initially transmitted containing a latency critical RLC SDU or a latency critical RLCSDU segment, an RLC data PDU to be retransmitted, or an RLC status report.
[0009] Optionally, when the at least one latency key data is a single latency key data, the first data volume is the data volume of the single latency key data; when the at least one latency key data is multiple latency key data, the first data volume is the sum of the data volumes of the multiple latency key data.
[0010] Optionally, the first threshold can be used to measure the size of the first data volume. When the first data volume is less than or equal to the first threshold, the first data volume associated with the first DSR is small, and the first device can cancel the first DSR.
[0011] Optionally, the first threshold may be greater than or equal to zero. For example, the first threshold is zero. When the first threshold is zero, "the first device may cancel the first DSR if the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold" can be understood as: the first device may cancel the first DSR if the first amount of data to be transmitted by the first MAC entity is zero.
[0012] Using this method, when the first data volume is less than or equal to a first threshold, the first device can cancel the first DSR corresponding to the first MAC entity. The first data volume can be the amount of latency-critical data associated with the first DSR that the first MAC entity is waiting to transmit. This method avoids situations where the first device cannot cancel the first DSR if the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity, thereby preventing the first device from continuously marking uncancellable DSRs awaiting transmission and reducing the power consumption of the first device.
[0013] In one possible design, time-critical data is transmitted by a second MAC entity.
[0014] Optionally, the transmission of latency-critical data by the second MAC entity may include: the transmission of latency-critical data associated with the first DSR by the second MAC entity. Accordingly, if the amount of first data to be transmitted by the first MAC entity is less than or equal to a first threshold, the first device may cancel the first DSR, or alternatively: if the amount of first data to be transmitted by the first MAC entity is less than or equal to the first threshold, and the latency-critical data associated with the first DSR is transmitted by the second MAC entity, the first device may cancel the first DSR.
[0015] This design avoids the first device being unable to cancel the first DSR when latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device. This prevents the first device from continuously marking DSRs that cannot be canceled and are yet to be transmitted, thereby reducing the power consumption of the first device.
[0016] In one possible design, the method further includes: the first device receiving first indication information from a PDCP entity via a first MAC entity. If the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold, the first device cancels the first DSR, which may include: the first device canceling the first DSR based on the first indication information when the first data amount is less than or equal to the first threshold. With this design, the first device can cancel the first DSR based on the first indication information when the first data amount is less than or equal to the first threshold. For example, the first MAC entity of the first device can accurately determine that a second data amount is less than or equal to a second threshold based on the first indication information, thereby canceling the first DSR when the first data amount is less than or equal to the first threshold. This avoids the first device continuously marking DSRs that cannot be canceled and are yet to be transmitted, thereby reducing the power consumption of the first device.
[0017] In one possible design, the first indication information can be used to indicate at least one of the following:
[0018] 1. All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device, where N2 is a positive integer. The N2 entities include at least one of the following: a second RLC entity and a second MAC entity, wherein the second RLC entity is the entity between the PDCP entity and the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the first indication information, that all latency-critical data associated with the first DSR is transmitted to the N2 entities in the first device.
[0019] 2. All latency-critical data associated with the first DSR has been transmitted by the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the first indication information, that all latency-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0020] 3. The latency-critical data associated with the first DSR consists of a first part of latency-critical data and a second part of latency-critical data. The first part of latency-critical data is transmitted to N2 entities, and the second part of latency-critical data has been transmitted by the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the first indication information, that the latency-critical data associated with the first DSR consists of a first part of latency-critical data and a second part of latency-critical data, that the first part of latency-critical data is transmitted to N2 entities, and that the second part of latency-critical data has been transmitted by the second MAC entity.
[0021] 4. The second data volume is less than or equal to the second threshold; wherein, the second data volume is the data volume of the first data, and the first data is the latency key data of the PDCP entity among at least one latency key data. Optionally, the second threshold can be used to measure the size of the second data volume. When the second data volume is less than or equal to the second threshold, the second data volume associated with the first DSR is smaller. Optionally, the second threshold can be greater than or equal to zero. For example, the second threshold is zero. When the second threshold is zero, "the second data volume is less than or equal to the second threshold" can be understood as: the second data volume is zero. In this way, the first MAC entity of the first device can accurately determine that the second data volume is less than or equal to the second threshold based on the first indication information.
[0022] In one possible design, the first indication information is transmitted only if at least one of the following conditions is met: all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device, where N2 is a positive integer, and the N2 entities include at least one of the following: a second RLC entity and a second MAC entity, wherein the second RLC entity is an entity between the PDCP entity and the second MAC entity; all latency-critical data associated with the first DSR has been transmitted by the second MAC entity; the latency-critical data associated with the first DSR consists of a first portion of latency-critical data and a second portion of latency-critical data, the first portion of latency-critical data has been transmitted to the N2 entities, and the second portion of latency-critical data has been transmitted by the second MAC entity; or, the second data volume is less than or equal to a second threshold; wherein the second data volume is the data volume of the first data, and the first data is the latency-critical data of the PDCP entity among at least one of the latency-critical data. With this design, the first indication information is transmitted only if at least one of the above conditions is met. Thus, based on the first indication information, the first MAC entity can accurately determine that the second data volume is less than or equal to the second threshold.
[0023] In one possible design, the method further includes: a first device sending second indication information to a PDCP entity via a second MAC entity, the second indication information indicating that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity, the second DSR being a DSR triggered by the second MAC entity. With this design, the first device can accurately determine, based on the second indication information, that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity.
[0024] In one possible design, the first data volume is less than or equal to the first threshold in the following case: receiving first indication information from the PDCP entity through the first MAC entity, and the third data volume is less than or equal to the third threshold, wherein the first data volume is the sum of the second data volume and the third data volume, the second data volume is the data volume of the first data, the first data is the latency key data of the PDCP entity among at least one latency key data, and the third data volume is the data volume of the second data, the second data is the latency key data of the first RLC entity among at least one latency key data.
[0025] Optionally, a third threshold can be used to measure the size of the third data volume. When the third data volume is less than or equal to the third threshold, the third data volume associated with the first DSR is smaller.
[0026] Optionally, the third threshold can be greater than or equal to zero. For example, the third threshold is zero. When the third threshold is zero, "the third data quantity is less than or equal to the third threshold" can be understood as: the third data quantity is zero.
[0027] With this design, the first device (e.g., the first MAC entity in the first device) can accurately determine that the first data amount is less than or equal to the first threshold based on the first indication information and the third data amount, thereby canceling the first DSR. This avoids the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking DSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0028] In one possible design, if a first condition is met at a first time, the first device can cancel the first DSR. The first time is related to the transmission time of the medium access control-control element (MAC CE) corresponding to the first DSR. If the first condition is met, the first data volume is less than or equal to a first threshold. The first condition includes at least one of the following: all delay-critical data associated with the first DSR has been transmitted by any MAC entity; or, in the MAC CE, the delay information corresponding to the first DSR has a value of zero.
[0029] For example, the delay information corresponding to the first DSR may include: the data volume information corresponding to the first DSR, and / or the remaining time information corresponding to the first DSR.
[0030] In some implementations, before canceling the first DSR, the method further includes: the first device sending the MAC CE. Optionally, the first device sending the MAC CE includes: if the first time is a time after the time of sending the MAC CE, the first device sending the MAC CE.
[0031] In other implementations, the method further includes: if a first condition is met, and / or, after canceling the first DSR, the first device determines not to send the MAC CE. Optionally, the first device determining not to send the MAC CE includes: if the first time is the time of transmission of the MAC CE, or a time prior to the transmission time, the first device determines not to send the MAC CE.
[0032] With this design, if the first condition is met at the first time, the first device (e.g., the first MAC entity in the first device) can cancel the first DSR, thereby preventing the first device from being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device. This avoids the first device continuously marking DSRs that cannot be canceled and are yet to be transmitted, thus reducing the power consumption of the first device.
[0033] In one possible design, the method further includes: a first device sending third indication information to a first MAC entity via a second MAC entity. The third indication information indicates that first latency-critical data associated with the second DSR is transmitted by the second MAC entity, and the second DSR is a DSR triggered by the second MAC entity. In this way, the first device (e.g., the first MAC entity in the first device) can accurately determine whether the first data volume is less than or equal to a first threshold based on the third indication information, thereby canceling the first DSR. This prevents the first device from being unable to cancel the first DSR when latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus avoiding the first device continuously marking uncancellable and pending transmission DSRs and reducing the power consumption of the first device.
[0034] In one possible design, the method further includes: a first device receiving first configuration information, which can be used to instruct the cancellation of a first DSR when the first amount of data to be transmitted by a first MAC entity is less than or equal to a first threshold. With this design, the first device can cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold, based on the first configuration information. Furthermore, in this design, the first configuration information is sent from a second device to the first device, allowing the second device to flexibly configure or instruct the operation of the first device.
[0035] In one possible design, the method further includes: a first device capable of sending first capability information, which can be used to indicate that the first device has the capability to cancel a first DSR when the first amount of data to be transmitted by a first MAC entity is less than or equal to a first threshold. With this design, the first device can accurately report to a second device via the first capability information that it has the capability to cancel a first DSR when the first amount of data to be transmitted by a first MAC entity is less than or equal to the first threshold. Thus, the second device can determine a configuration for the first device that is appropriate to its capabilities.
[0036] In one possible design, the first device triggers the first DSR corresponding to the first MAC entity by: the first device triggering the first DSR under the condition that the second condition is met, the second condition including: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device. With this design, the first device can only trigger the first DSR if the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device. This avoids the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thereby preventing the first device from continuously marking uncancellable and pending transmission DSRs and reducing the power consumption of the first device.
[0037] In one possible design, the method further includes: a first device receiving second configuration information, the second configuration information being used to instruct the first device to trigger a first DSR when a second condition is met. With this design, the first device can trigger the first DSR according to the second configuration information when the second condition is met. Furthermore, in this design, the second configuration information is sent from the second device to the first device, thus allowing the second device to flexibly configure or instruct the operation of the first device.
[0038] In one possible design, the method further includes: a first device sending second capability information, the second capability information indicating that the first device has the capability to trigger a first DSR when a second condition is met. With this design, the first device can accurately report to the second device, via the second capability information, that it has the capability to trigger a first DSR when the second condition is met. Thus, the second device can determine a configuration appropriate to the capabilities of the first device.
[0039] Secondly, embodiments of this application provide a communication method that can be applied to a second device or an apparatus for the second device. Optionally, the second device may be an access network device; the apparatus for the second device may be a module for the access network device (e.g., a communication module, circuitry or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the functions of the access network device. For ease of description, the following description uses a second device as an example. It should be understood that when the second device is used as the execution subject in the following text, the second device can be replaced by an apparatus for the second device.
[0040] The method includes: a second device sending first configuration information. The first configuration information instructs the first device to cancel the first DSR corresponding to the first MAC entity if the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold. The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity; the first MAC entity and the second MAC entity are used to transmit data of the first device. The first data volume is the total data volume of at least one latency-critical data associated with the first DSR. The at least one latency-critical data includes latency-critical data of each of N1 entities, where N1 is a positive integer. The N1 entities are located in the first device, and the N1 entities include: the PDCP entity, and a first RLC entity, where the first RLC entity is the entity between the PDCP entity and the first MAC entity.
[0041] Optionally, before sending the first configuration information, the second device may determine (or generate, or obtain) the first configuration information, and the method of determining (or generating, or obtaining) is not limited.
[0042] For example, the latency-critical data of a PDCP entity includes at least one of the following: a latency-critical PDCP SDU that has not been constructed as a PDCP data PDU, a lower-level PDCP data PDU that contains a latency-critical PDCP SDU and has not yet been delivered to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted.
[0043] For example, the latency critical data of the first RLC entity includes at least one of the following: a latency critical RLC SDU or a latency critical RLC SDU segment that has not been constructed as an RLC dataPDU, an RLC data PDU to be initially transmitted containing a latency critical RLC SDU or a latency critical RLCSDU segment, an RLC data PDU to be retransmitted, or an RLC status report.
[0044] In one possible design, the method further includes: a second device receiving first capability information, the first capability information being used to indicate that the first device has the capability to cancel the first DSR if the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
[0045] Thirdly, embodiments of this application provide a communication method that can be applied to a first device or an apparatus of the first device. The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. Optionally, the first device may be a terminal; the apparatus for the first device may be a module for the terminal (e.g., a communication module, circuitry or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the terminal functions. For ease of description, the following description uses a first device as an example. It should be understood that when the first device is used as the execution subject in the following text, the first device can be replaced with an apparatus for the first device.
[0046] The method includes: under the condition that a second condition is met, the first device may trigger a first DSR corresponding to a first MAC entity, the second condition including: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0047] Optionally, the first device may determine that the second condition is met before triggering the first DSR corresponding to the first MAC entity.
[0048] In one possible design, the method further includes: a first device can receive second configuration information, the second configuration information being used to instruct the first device to trigger a first DSR when a second condition is met.
[0049] In one possible design, the method further includes: the first device can send second capability information, the second capability information being used to indicate that the first device has the capability to trigger a first DSR when a second condition is met.
[0050] Fourthly, embodiments of this application provide a communication method that can be applied to a second device or an apparatus for the second device. Optionally, the second device may be an access network device; the apparatus for the second device may be a module for the access network device (e.g., a communication module, circuitry or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the functions of the access network device. For ease of description, the following description uses a second device as an example. It should be understood that when the second device is used as the execution subject in the following text, the second device can be replaced by an apparatus for the second device.
[0051] The method includes: a second device sending second configuration information. The second configuration information can be used to instruct a first device to trigger a first DSR corresponding to a first MAC entity when a second condition is met. The second condition may include: latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device. Optionally, before sending the second configuration information, the second device may determine (or generate, or acquire) the second configuration information, and the method of determination (or generation, or acquisition) is not limited.
[0052] In one possible design, the method further includes: a second device being able to receive second capability information, which can be used to indicate that the first device has the capability to trigger a first DSR when a second condition is met.
[0053] Fifthly, embodiments of this application provide a communication method that can be applied to a first device or an apparatus of the first device. The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. Optionally, the first device may be a terminal; the apparatus for the first device may be a module for the terminal (e.g., a communication module, a circuit or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the terminal functions. For ease of description, the following description uses a first device as an example. It should be understood that when the first device in the following text is used as the execution subject, the first device can be replaced with an apparatus for the first device.
[0054] The method includes: a first device triggering a first BSR corresponding to a first MAC entity. If the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold, the first device may cancel the first BSR. Here, the fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0055] For example, the data of a PDCP entity may include at least one of the following: a PDCPSDU that has not been constructed as a PDCP data PDU, a lower-level PDCP data PDU that contains a PDCP SDU and has not yet been delivered to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted.
[0056] For example, the data of the first RLC entity may include at least one of the following: an RLC SDU or RLCSDU segment that is not constructed as an RLC data PDU, an RLC Data PDU to be initially transmitted containing an RLC SDU or RLC SDU segment, an RLC data PDU to be retransmitted, or an RLC status report. Here, an RLC SDU or RLC SDU segment that is not constructed as an RLC data PDU can be understood as an RLC SDU or RLC SDU segment not included in an RLC data PDU.
[0057] Optionally, when the at least one data is a single data, the fourth data quantity is the data quantity of that single data; when the at least one data is multiple data, the fourth data quantity is the sum of the data quantities of the multiple data.
[0058] Optionally, a fourth threshold can be used to measure the size of the fourth data volume. When the fourth data volume is less than or equal to the fourth threshold, the fourth data volume associated with the first BSR is small, and the first device can cancel the first BSR.
[0059] Optionally, the fourth threshold may be greater than or equal to zero. For example, the fourth threshold may be zero. When the fourth threshold is zero, "the first device may cancel the first BSR if the fourth data amount to be transmitted by the first MAC entity is less than or equal to the fourth threshold" can be understood as: the first device may cancel the first BSR if the fourth data amount to be transmitted by the first MAC entity is zero.
[0060] Using this method, when the fourth data volume is less than or equal to the fourth threshold, the first device can cancel the first BSR corresponding to the first MAC entity. Here, the fourth data volume is the total data volume of at least one data associated with the first BSR. This method avoids situations where the first device cannot cancel the first BSR when data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity, thereby preventing the first device from continuously marking uncancellable BSRs awaiting transmission and reducing the power consumption of the first device.
[0061] In one possible design, the method further includes: a first device receiving fourth indication information from a PDCP entity via a first MAC entity. If the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold, the first device can cancel the first BSR, including: the first device canceling the first BSR according to the fourth indication information when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold. With this design, the first device can cancel the first BSR when the fourth data volume is less than or equal to the fourth threshold, based on the fourth indication information. For example, the first MAC entity of the first device can accurately determine that the fifth data volume is less than or equal to the fifth threshold based on the fourth indication information, thereby canceling the first BSR when the fourth data volume is less than or equal to the fourth threshold. This avoids the first device continuously marking BSRs that cannot be canceled and are yet to be transmitted, thereby reducing the power consumption of the first device.
[0062] In one possible design, the fourth indication information can be used to indicate at least one of the following:
[0063] 1. All data associated with the first BSR is transmitted to N2 entities in the first device, where N2 is a positive integer. The N2 entities include at least one of the following: a second RLC entity and a second MAC entity, wherein the second RLC entity is the entity between the PDCP entity and the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the fourth indication information, that all data associated with the first BSR is transmitted to the N2 entities in the first device.
[0064] 2. All data associated with the first BSR has been transmitted by the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the fourth indication information, that all data associated with the first BSR has been transmitted by the second MAC entity.
[0065] 3. The data associated with the first BSR consists of a first part of data and a second part of data. The first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity. Thus, the first MAC entity of the first device can accurately determine, based on the fourth indication information, that the data associated with the first BSR consists of a first part of data and a second part of data, the first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity.
[0066] 4. The fifth data volume is less than or equal to the fifth threshold. Here, the fifth data volume is the data volume of the third data, and the third data is the data of the PDCP entity within the at least one data set. Optionally, the fifth threshold can be used to measure the size of the fifth data volume. When the fifth data volume is less than or equal to the fifth threshold, the fifth data volume associated with the first BSR is smaller. Optionally, the fifth threshold can be greater than or equal to zero. For example, the fifth threshold is zero. When the fifth threshold is zero, "the fifth data volume is less than or equal to the fifth threshold" can be understood as: the fifth data volume is zero. Thus, the first MAC entity of the first device can accurately determine whether the fifth data volume is less than or equal to the fifth threshold based on the fourth indication information.
[0067] In one possible design, the fourth indication information is transmitted only if at least one of the following conditions is met: all data associated with the first BSR has been transmitted to N2 entities in the first device; all data associated with the first BSR has been transmitted by the second MAC entity; the data associated with the first BSR consists of a first part of data and a second part of data, the first part of data has been transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity; or, the fifth data volume is less than or equal to a fifth threshold. With this design, the fourth indication information is transmitted only if at least one of the above conditions is met. Thus, based on the fourth indication information, the first MAC entity can accurately determine that the second data volume is less than or equal to the second threshold.
[0068] In one possible design, the method further includes: the first device sending fifth indication information to the PDCP entity via the second MAC entity. The fifth indication information can be used to indicate that all data associated with the second BSR has been transmitted by the second MAC entity, where the second BSR is a BSR triggered by the second MAC entity. With this design, the first device can accurately determine, based on the fifth indication information, that all data associated with the second BSR has been transmitted by the second MAC entity.
[0069] In one possible design, the fourth data quantity is less than or equal to the fourth threshold when the first device receives fourth indication information from the PDCP entity via the first MAC entity, and the sixth data quantity is less than or equal to the sixth threshold. Optionally, the sixth threshold can be used to measure the size of the sixth data quantity. When the sixth data quantity is less than or equal to the sixth threshold, the sixth data quantity associated with the first BSR is small. Optionally, the sixth threshold can be greater than or equal to zero. For example, the sixth threshold is zero. When the sixth threshold is zero, "the sixth data quantity is less than or equal to the sixth threshold" can be understood as: the sixth data quantity is zero. With this design, the first device (e.g., the first MAC entity in the first device) can accurately determine that the fourth data quantity is less than or equal to the fourth threshold based on the fourth indication information and the sixth data quantity, thereby canceling the first BSR. This avoids the first device being unable to cancel the first BSR when data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking uncancellable and pending BSRs and reducing the power consumption of the first device.
[0070] In one possible design, at a second time, if the third condition is met, the first device may cancel the first BSR. Optionally, the second time is related to the transmission time of the MAC CE corresponding to the first BSR. If the third condition is met, the fourth data amount is less than or equal to a fourth threshold. Exemplarily, the third condition includes at least one of the following: all data associated with the first BSR has been transmitted by any MAC entity; or, in the MAC CE, the value of the information corresponding to the first BSR is zero.
[0071] With this design, if the third condition is met at the second time, the first device (e.g., the first MAC entity in the first device) can cancel the first BSR, thereby preventing the first device from being unable to cancel the first BSR when the data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus avoiding the first device continuously marking BSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0072] In one possible design, the method further includes: the first device sending a sixth indication message to the first MAC entity via the second MAC entity. If the fourth data quantity to be transmitted by the first MAC entity is less than or equal to a fourth threshold, the first device can cancel the first BSR, including: the first device canceling the first BSR according to the sixth indication message when the fourth data quantity is less than or equal to the fourth threshold. With this design, the first device sends the sixth indication message to the first MAC entity via the second MAC entity. The sixth indication message can be used to indicate that data #1 associated with the second BSR is transmitted by the second MAC entity. Thus, the first device (e.g., the first MAC entity in the first device) can accurately determine whether the fourth data quantity is less than or equal to the fourth threshold based on the sixth indication message, thereby canceling the first BSR. This avoids the first device being unable to cancel the first BSR when the data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, preventing the first device from continuously marking uncancellable BSRs awaiting transmission and reducing the power consumption of the first device.
[0073] In one possible design, the method further includes: a first device receiving third configuration information. The third configuration information is used to indicate that the first BSR should be cancelled if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold. With this design, the first device can cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold, based on the third configuration information. Furthermore, in this design, the third configuration information is sent from the second device to the first device, allowing the second device to flexibly configure or instruct the operation of the first device.
[0074] In one possible design, the method further includes: the first device sending third capability information. This third capability information can be used to indicate that the first device has the capability to cancel the first BSR when the fourth amount of data to be transmitted by the first MAC entity is less than or equal to a fourth threshold. With this design, the first device can accurately report to the second device via the third capability information that it has the capability to cancel the first BSR when the fourth amount of data to be transmitted by the first MAC entity is less than or equal to the fourth threshold. Thus, the second device can determine a configuration appropriate to the capabilities of the first device.
[0075] Sixthly, embodiments of this application provide a communication method, which can be applied to a second device or an apparatus for the second device. Optionally, the second device may be an access network device; the apparatus for the second device may be a module for the access network device (e.g., a communication module, circuitry or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or may be a logical node, logical module, or software capable of implementing all or part of the functions of the access network device. For ease of description, the following description uses a second device as an example. It should be understood that when the second device is used as the execution subject in the following text, the second device can be replaced by an apparatus for the second device.
[0076] The method includes: a second device sending third configuration information, which can be used to indicate that a first BSR is canceled if the fourth data volume to be transmitted by a first MAC entity is less than or equal to a fourth threshold. The fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data volume includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0077] Optionally, before sending the third configuration information, the second device may determine (or generate, or obtain) the third configuration information, and the method of determining (or generating, or obtaining) is not limited.
[0078] In one possible design, the method further includes: the second device being able to receive third capability information. This third capability information can be used to indicate to the first device that it has the capability to cancel the first BSR if the fourth amount of data to be transmitted by the first MAC entity is less than or equal to a fourth threshold.
[0079] In a seventh aspect, this application provides a communication device. In some examples, the communication device can be a terminal or a device for a terminal. The device for a terminal can be a module for a terminal (e.g., a communication module, circuitry or a chip responsible for communication and / or sensing functions (e.g., a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or a logic node, logic module, or software capable of implementing all or part of the terminal functions. The communication device has the functions to implement the first, third, or fifth aspects described above. In other examples, the communication device can be an access network device or a device for an access network device. The device for an access network device can be a module for an access network device (e.g., a communication module, circuitry or a chip responsible for communication and / or sensing functions (e.g., a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or a logic node, logic module, or software capable of implementing all or part of the access network device functions. The communication device has the functions to implement the second, fourth, or sixth aspects described above.
[0080] In one possible embodiment, the communication device includes modules, units, or means corresponding to the operations involved in any of the first to sixth aspects described above. These modules, units, or means can be implemented in software, hardware, or a combination of both. For example, the communication device includes an interface unit and a processing unit. The interface unit can be used to transmit and receive signals to enable communication between the communication device and other devices; the processing unit can be used to perform some internal operations of the communication device. The functions performed by the processing unit and the interface unit can correspond to the operations involved in any of the first to sixth aspects.
[0081] In one possible embodiment, the communication device includes a processor. The processor is capable of executing a computer program or instructions that, when executed, cause the communication device to implement the methods in any possible design of any of the first to sixth aspects described above.
[0082] In one possible embodiment, the communication device includes a processor and a memory, the memory of which may store necessary computer programs or instructions for implementing the functions involved in any of the first to sixth aspects described above. The processor may execute the computer programs or instructions stored in the memory, and when the computer programs or instructions are executed, cause the communication device to implement the methods in any possible design of any of the first to sixth aspects described above.
[0083] In one possible embodiment, the communication device includes a processor and an interface circuit, wherein the processor is configured to communicate with other devices via the interface circuit and to execute the methods in any possible design of any of the first to sixth aspects described above.
[0084] Eighthly, this application provides a communication system that may include a first device and a second device. The first device may execute the communication method provided in the first aspect, and the second device may execute the communication method provided in the second aspect; or, the first device may execute the communication method provided in the third aspect, and the third device may execute the communication method provided in the fourth aspect; or, the first device may execute the communication method provided in the fifth aspect, and the third device may execute the communication method provided in the sixth aspect.
[0085] In some possible designs, the first device is a terminal and the second device is an access network device.
[0086] Ninthly, this application provides a computer-readable storage medium storing a computer program or instructions, wherein when the computer program or instructions are executed, a method in any possible design of any of the first to sixth aspects described above is implemented.
[0087] In a tenth aspect, this application provides a computer program product comprising computer program code, wherein when the computer program code is run, a method in any possible design of any of the first to sixth aspects described above is implemented.
[0088] In one aspect, this application provides a chip for reading a computer program stored in a memory to execute a method in any of the possible designs of any of the first to sixth aspects described above.
[0089] The specific content and achievable technical effects of any of the above-mentioned aspects 2 to 4 and 6 to 10 can be referred to the descriptions in the above-mentioned aspects 1 or 5, and the repetitions will not be discussed. Attached Figure Description
[0090] Figure 1 An architecture diagram of a communication system provided in an embodiment of this application;
[0091] Figure 2 A schematic diagram of a DSR MAC CE provided for an embodiment of this application;
[0092] Figure 3 A schematic diagram illustrating a separate carrier provided in an embodiment of this application;
[0093] Figure 4A schematic diagram illustrating an application scenario provided in an embodiment of this application;
[0094] Figure 5 A flowchart illustrating the first communication method provided in this application embodiment;
[0095] Figures 6A to 6D Schematic diagrams illustrating several application scenarios provided in the embodiments of this application;
[0096] Figure 7 A flowchart illustrating the second communication method provided in this application embodiment;
[0097] Figure 8 A flowchart illustrating the third communication method provided in the embodiments of this application;
[0098] Figure 9 A structural diagram of a communication device provided in an embodiment of this application;
[0099] Figure 10 This is a structural diagram of another communication device provided in an embodiment of this application. Detailed Implementation
[0100] The technical solutions in the embodiments of this application will be described below with reference to the accompanying drawings. The technical solutions in the embodiments of this application can be applied to various communication systems, such as wireless local area networks (WLANs), wireless fidelity (Wi-Fi or WiFi) systems, fourth-generation (4G) mobile communication systems (such as long-term evolution (LTE) systems), fifth-generation (5G) mobile communication systems (such as new radio (NR) systems), or future communication systems. The methods provided in the embodiments of this application can be applied to terrestrial network communication systems or non-terrestrial network (NTN) communication systems. NTN communication systems can be, for example, satellite communication systems, and may also include unmanned aerial vehicles (UAVs), high-altitude platform stations (HAPS), and other aerial access network equipment; this application does not limit these aspects.
[0101] This application will present various aspects, embodiments, or features relating to systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.
[0102] Figure 1 A schematic diagram of a communication system provided in an embodiment of this application is shown as an example. Figure 1 As shown, the communication system 10 includes a radio access network (RAN) 100 and a core network (CN) 200. Optionally, the communication system 10 may also include an Internet 300.
[0103] RAN 100 includes at least one RAN node (such as...) Figure 1 110a and 110b (collectively referred to as 110) and at least one terminal (such as Figure 1 RAN 100, denoted as RAN 120a-120j, is collectively referred to as RAN 120. RAN 100 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment. Figure 1 (Not shown in the image). Terminal 120 is connected to RAN node 110 wirelessly. RAN node 110 is connected to core network 200 wirelessly or via wired connection. The core network equipment in core network 200 and RAN node 110 in RAN 100 can be different physical devices, or they can be the same physical device integrating core network logical functions and radio access network logical functions.
[0104] RAN 100 can be a cellular system related to the 3rd Generation Partnership Project (3GPP), such as 4G, 5G mobile communication systems, or future-oriented evolution systems. RAN 100 can also be ORAN, cloud radio access network (CRAN), or WiFi system. RAN 100 can also be a communication system that integrates two or more of the above systems.
[0105] RAN node 110, sometimes referred to as RAN entity or access node, constitutes part of the communication system and assists terminals in achieving wireless access. Multiple RAN nodes 110 in communication system 10 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal 120 are relative, for example... Figure 1 Network element 120i can be a helicopter or a drone, and it can be configured as a mobile base station. For terminals 120j that access RAN 100 through network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal. RAN node 110 and terminal 120 are sometimes referred to as communication devices, for example... Figure 1Network elements 110a and 110b can be understood as communication devices with base station functions, while network elements 120a-120j can be understood as communication devices with terminal functions.
[0106] RAN nodes can also be described in different ways, such as access network equipment. Unless otherwise specified in this application, access network equipment will be used as the term.
[0107] Access network equipment can be devices or modules located on the network side of the aforementioned communication system and possessing corresponding communication functions. Access network equipment typically contains communication modules, circuits, or chips that perform the corresponding communication functions. Access network equipment may also be configured with programs or instructions for performing the corresponding communication functions, as well as the corresponding programs or instructions themselves.
[0108] In one possible scenario, access network equipment can be a base station (BS) (e.g., an evolved NodeB, eNodeB), a transmission point (TP), an access point (AP), a transmission reception point (TRP), a mobile switching center, a next-generation NodeB (gNB), a next-generation base station in a future communication system, or an access node in a WiFi system, etc. Access network equipment can also be a macro base station (e.g., Figure 1 110a), micro base stations or indoor stations (such as Figure 1 The access network equipment can be 110b), relay nodes or donor nodes, wireless controllers in CRAN scenarios, satellites, drones, balloons, or aircraft, etc. Optionally, the access network equipment can also be servers, wearable devices, vehicles, or in-vehicle equipment, etc. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the access network equipment in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform).
[0109] In another possible scenario, multiple access network devices collaborate to assist the terminal in achieving wireless access, with each device performing a portion of the base station's functions. For example, the access network devices can be a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU and DU can be separate entities or included in the same network element, such as a baseband unit (BBU). The RU can be included in radio frequency equipment or radio frequency units, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radiohead (RRH).
[0110] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called an open CU (O-CU), DU can also be called an open DU (O-DU), CU-CP can also be called an open CU-CP (O-CU-CP), CU-UP can also be called an open CU-UP (O-CU-UP), and RU can also be called an open RU (O-RU). Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.
[0111] A terminal is a device or module that connects to the aforementioned communication system and possesses corresponding communication functions. A terminal can also be called a terminal device, user equipment (UE), mobile station, mobile terminal, wireless terminal device, subscriber unit, subscriber station, mobile station, remote station, user terminal, user agent, or user device, etc. A terminal typically contains communication modules, circuits, or chips that perform the corresponding communication functions. The terminal can also be configured with programs or instructions for performing these communication functions.
[0112] Terminals can be widely used in various scenarios, such as device-to-device (D2D), V2X communication, machine-type communication (MTC), Internet of Things (IoT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, and smart cities. Terminals can be mobile phones, tablets, computers with wireless transceiver capabilities, wearable devices, vehicles, drones, helicopters, airplanes, ships, robots, robotic arms, smart home devices, etc. Wearable devices, also known as wearable smart devices or smart wearable devices, are a general term for devices that utilize wearable technology to intelligently design and develop everyday wearables. Terminals used in vehicles are called in-vehicle terminal devices, which include, for example, transportation vehicles with wireless communication capabilities, communication modules, or on-board units (OBUs).
[0113] For example, a terminal may include a mobile phone (or "cellular" phone), a computer with a mobile terminal device, or a portable, pocket-sized, handheld, or computer-embedded mobile device. For instance, a terminal may be a Personal Communication Service (PCS) phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), or other similar devices. A terminal may also include restricted devices, such as devices with limited power consumption, limited storage capacity, or limited computing power. For example, a terminal may be an information sensing device such as a barcode scanner, radio frequency identification (RFID), a sensor, a global positioning system (GPS), or a laser scanner. The embodiments of this application do not limit the device form of the terminal.
[0114] In this application, core network equipment refers to equipment in the core network that provides service support to terminals. For example, in the case where CN200 is the core network of a future communication system, a 5G core network, or an evolved 5G core network, some examples of core network equipment include: access and mobility management function (AMF) entities, session management function (SMF) entities, user plane function (UPF) entities, policy control function (PCF) entities, etc., which are not listed here. Among them, the AMF entity can be responsible for terminal access management and mobility management; the SMF entity can be responsible for session management, such as user session establishment; the UPF entity can be a user plane functional entity, mainly responsible for connecting to external networks. For example, in the case of CN200 as the 4G core network, some core network devices include: Mobility Management Entity (MME), Home Subscriber Server (HSS), Serving Gateway (S-GW), Policy and Charging Rules Function (PCRF), Public Data Network Gateway (PDN Gateway, P-GW), etc., which will not be listed here. It should be noted that in this application, entities can also be referred to as network elements or functional entities. For example, an AMF entity can also be called an AMF network element or AMF functional entity, and similarly, an SMF entity can also be called an SMF network element or SMF functional entity. The aforementioned core network devices can operate independently or be combined to implement certain control functions. For example, AMF, SMF, and PCF can be combined into a single core network device.
[0115] The communication systems and service scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new service scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0116] The relevant terms used in the embodiments of this application will be explained below. It should be noted that these explanations are for the purpose of making the embodiments of this application easier to understand, and should not be regarded as a limitation on the scope of protection claimed by this application.
[0117] I. Data:
[0118] In this application, the unit or form of data can be one of the following: a data frame, an SDU, a PDU, a Protocol Data Unit set (PDU set), or a data burst. A PDU may include an SDU or a segment of an SDU (or byte segment), and may also include a header. For example, an RLC PDU may include segments of an RLC SDU or an RLCSDU, and an RLCSDU also includes a header. A PDU set may include at least one PDU, which may carry an information unit generated by an application (or application layer). For example, when the data volume of a data frame is large, the data frame may be divided into multiple PDUs for transmission, and a PDU set may include these multiple PDUs. A data burst can be understood as a group of PDUs generated and sent by an application (or application layer) within a certain period of time. This group of PDUs may come from one or more PDU sets, and the duration of this period may be less than a set value.
[0119] II. Extended Reality (XR) Services:
[0120] The real-time broadband communication (RTBC) scenario under the new 5G vision aims to support high bandwidth and low interaction latency. The goal is to increase bandwidth tenfold under given latency and certain reliability requirements, thereby creating an immersive experience for human-virtual world interaction. XR services, with their ultra-high bandwidth and ultra-low latency requirements, can be applied to RTBC scenarios. XR services can include one or more types of data, such as video, audio, and control signals. Video typically consists of several ultra-high-definition images, each of which can be compressed and encoded, such as using High Efficiency Video Coding (HEVC), resulting in a large data block. The higher the video resolution, the larger the data block. When XR services include video, XR data is called a data frame. A data frame typically needs to be transmitted by several Internet Protocol (IP) packets or several PDUs. For details on the content of a data frame, please refer to the explanation of data frames above; it will not be repeated here.
[0121] III. The Importance of Data:
[0122] For example, in services such as XR, there may be dependencies between data frames. For instance, a second data frame may require the first data frame to be decoded. Therefore, if the transmission of the first data frame fails, the receiving device cannot decode the second data frame even if it is received. To address this characteristic of services such as XR, the concept of data importance is introduced; for example, data frames in services such as XR are divided into important data frames and unimportant data frames.
[0123] Optionally, the importance of data can be distinguished by an importance threshold. For example, if the importance of a certain data is higher than or equal to the importance threshold, then the data can be considered important data, and the corresponding data frame can be considered an important data frame; if the importance of a certain data is lower than the importance threshold, then the data can be considered unimportant or low-importance data, and the corresponding data frame can be considered an unimportant data frame.
[0124] Optionally, different data units within a data unit group (such as a PDU set) may have the same importance. For example, PDU set #1 may include RLC PDUs #1 through #4. RLC PDUs #1 through #4 may all be important data; alternatively, RLCPDUs #1 through #4 may all be unimportant data. A data unit group may include the aforementioned data frames.
[0125] Optionally, for downlink data, core network equipment can identify the importance of the data and notify the access network equipment of this importance so that the access network equipment can perform scheduling and management accordingly. For uplink data, the terminal can identify the importance of the data. Currently, the importance of data is identified by the transmitting device; the receiving device is usually unaware of the importance of the data.
[0126] IV. Packet Loss Timer:
[0127] The packet loss timer can be configured by the access network equipment for the terminal, such as for the terminal's radio bearer. The terminal's PDCP entity can start a packet loss timer for each PDCP SDU. For example, after receiving each PDCP SDU, the PDCP entity can start a packet loss timer for that PDCP SDU; thus, each PDCP SDU can correspond to one packet loss timer. If the packet loss timer of a certain PDCP SDU expires, the terminal can discard that PDCP SDU, for example, the PDCP entity can discard that PDCP SDU.
[0128] In some implementations, the duration of the packet loss timer may differ for different PDCP SDUs. For example, if importance-based packet loss is enabled, the duration of the packet loss timer for important data (hereinafter referred to as the first packet loss timer) and the duration of the packet loss timer for unimportant data (hereinafter referred to as the second packet loss timer) will differ; for instance, the duration of the first packet loss timer may be longer than the duration of the second packet loss timer. Accordingly, the terminal can perform the discard operation for important data based on the first packet loss timer and the discard operation for unimportant data based on the second packet loss timer. The first packet loss timer may have other names, such as discardTimer or a regular packet loss timer. The second packet loss timer may have other names, such as discardTimerForLowImportance.
[0129] Optionally, the first packet loss timer can be a packet loss timer configured by the access network device for important PDCP SDUs; the second packet loss timer can be a packet loss timer configured by the access network device for unimportant PDCP SDUs. For example, the access network device can pre-configure the first and second packet loss timers.
[0130] Optionally, when the access network device requires the terminal to perform importance-based packet loss, the access network device can activate "importance-based packet loss" for the terminal. For example, when the access network device requires the terminal to perform importance-based packet loss, the access network device can send a MAC CE to the terminal to activate "importance-based packet loss," such as a PDU setimport (PSI)-based discard activation MAC CE. For example, when congestion occurs, the access network device can send this MAC CE to the terminal to activate importance-based packet loss; when congestion is resolved, the access network device can send a MAC CE to the terminal to deactivate "importance-based packet loss," such as a PSI-based discard deactivation MAC CE. The access network device can perform activation and deactivation at the data radiobearer (DRB) level.
[0131] V. Delay-critical data:
[0132] Latency-critical data may also have other names, such as low-latency data or urgent data, without restriction. Latency-critical data refers to data where the remaining time of the corresponding packet loss timer is less than or equal to threshold #1, or data where the remaining duration of the corresponding packet delay budget (PDB) is less than or equal to threshold #1. This threshold #1 can be configured by the access network device for the terminal, for example, for the terminal's logical channel group (LCG), or for the terminal's logical channel (LCH).
[0133] Optionally, the threshold #1 can be implemented in at least one of the following ways, which will be described below.
[0134] 1. This threshold #1 is related to delay status reporting (DSR). For example, this threshold #1 is used for terminal to trigger DSR.
[0135] 2. This threshold #1 is related to logical channel prioritization (LCP) enhancement. For example, this threshold #1 is used by the terminal to trigger or execute LCP enhancement. Optionally, LCP enhancement may also have other names, such as LCP process enhancement, without limitation. LCP enhancement can be understood as an LCP process that takes into account the delay information of data packets. For example, when executing the LCP process, the terminal may allocate resources for the data to be transmitted based on the delay information of the data packets, and / or assemble the data to be transmitted into packets. The delay information includes, for example, at least one of the following: the remaining time of the data, the remaining duration of the data's PDB, or the remaining duration of the packet loss timer.
[0136] Alternatively, integrity factors can also be used as a factor in defining latency-critical data. For example, a piece of data might become latency-critical data because the remaining time of its corresponding packet loss timer is less than or equal to threshold #1 (e.g., the packet loss timer is about to expire); or it might become latency-critical data because it belongs to a data set containing latency-critical data. For instance, if the remaining time of the packet loss timer corresponding to the first PDU SDU is less than or equal to threshold #1, then the first PDU SDU can be latency-critical data. As another example, if the first PDU SDU belongs to a first PDU set, and latency-critical data exists in the first PDU set (e.g., the remaining time of the packet loss timer corresponding to the second PDU SDU in the first PDU set is less than or equal to threshold #1, in other words, the packet loss timer corresponding to the second PDU SDU is about to expire), then the first PDU SDU can be latency-critical data.
[0137] Alternatively, importance can also be a factor in defining latency-critical data. For example, latency-critical data can have different meanings depending on whether "importance-based packet loss" is activated. This will be illustrated below.
[0138] In some examples, if "importance-based packet loss" is activated on a logical channel, then the latency-critical data on that logical channel refers to important data whose remaining time for the corresponding packet loss timer is less than or equal to threshold #1; in other words, the latency-critical data on that logical channel is important and urgent data. For example, if the terminal is configured with a first packet loss timer (i.e., the packet loss timer corresponding to important data) and a second packet loss timer (i.e., the packet loss timer corresponding to unimportant data), and the LCH corresponding to the first DRB is activated with "importance-based packet loss," then the latency-critical data on the LCH corresponding to the first DRB includes: data whose remaining time for the corresponding first packet loss timer is less than or equal to threshold #1.
[0139] In other examples, if a logical channel is not activated for "importance-based packet loss," then low-latency data on that logical channel refers to data whose remaining time for the corresponding packet loss timer is less than or equal to threshold #1. In other words, latency-critical data on that logical channel is urgent data, and its importance can be disregarded. For example, if the terminal is not configured with a second packet loss timer, and / or the LCH corresponding to the first DRB is not activated for "importance-based packet loss," then latency-critical data on the LCH corresponding to the first DRB includes data whose remaining time for the corresponding first packet loss timer is less than or equal to threshold #1.
[0140] Optionally, for delay-critical data, the PDCP entity may send a delay-critical indication to the corresponding entity at a lower layer of the PDCP layer (e.g., the RLC layer and / or the MAC layer). For example, if a PDCP data PDU has already been transmitted to a lower layer of the PDCP layer, and the corresponding PDCP SDU has become a delay-critical PDCP SDU, the PDCP entity may send a delay-critical indication to the RLC entity and / or the MAC entity; or, if a PDCP data PDU has been transmitted to a lower layer of the PDCP layer, and the corresponding PDCP SDU is already a delay-critical PDCP SDU, the PDCP entity may send a delay-critical indication to the RLC entity and / or the MAC entity. In other words, if the PDCPSDU corresponding to the PDCP data PDU becomes a delay-critical PDCP SDU after the PDCP data PDU is transmitted to a lower layer of the PDCP layer, the PDCP entity can send a delay-critical indication to the RLC entity and / or the MAC entity; or, if the PDCP SDU becomes a delay-critical PDCP SDU in the PDCP entity, and then the PDCP data PDU corresponding to the PDCP SDU is transmitted to a lower layer of the PDCP layer, the PDCP entity can send a delay-critical indication to the RLC entity and / or the MAC entity.
[0141] VI. DSR:
[0142] Terminals can report latency-critical data to access network devices via DSR, enabling the access network devices to obtain this information. The latency-critical data information includes, for example, at least one of the following: the amount of latency-critical data, or the remaining time of the latency-critical data. Optionally, the latency-critical data information can be understood as: information related to (or connected to) the latency-critical data.
[0143] The DSR process (e.g., triggering a DSR, reporting a DSR, and canceling a DSR, or one or more of these) can be performed by the terminal or a device within the terminal (e.g., a MAC entity within the terminal). The following explanation uses a terminal as an example.
[0144] 1. Trigger DSR:
[0145] When the DSR triggering conditions are met, the terminal can trigger a DSR for the first LCH. For example, the DSR triggering conditions include: the minimum remaining time of the packet loss timer corresponding to the data cached in the first LCH is less than or equal to threshold #1 (also known as the DSR triggering threshold), and / or, there are currently no pending DSRs for the first LCH. The packet loss timer can be the packet loss timer described above, for example, the first packet loss timer.
[0146] (1) The minimum remaining time of the packet loss timer corresponding to the data in the first LCH cache is less than or equal to threshold #1:
[0147] Optionally, the minimum remaining time of the packet loss timer corresponding to the data in the first LCH cache can be understood as: the remaining time of the packet loss timer corresponding to the first cached data. Here, the first cached data is the data in the first LCH cache whose corresponding packet loss timer has the shortest remaining time. For example, if the data in the first LCH cache includes data #1 to data #3, and the remaining times of the packet loss timers corresponding to data #1 to data #3 are 3 milliseconds (ms), 5 ms, and 7 ms respectively, then the first cached data can be data #1, and the minimum remaining time of the packet loss timer corresponding to the data in the first LCH cache can be 3 ms.
[0148] Optionally, in the DSR triggering condition, the data in the first LCH cache can be understood as at least one of the following: data in the first LCH cache that has not been transmitted in the MAC PDU (e.g., all data in the first LCH cache that has not been transmitted in the MAC PDU); or, data in the first LCH cache that has not been reported through the DSR MAC CE (e.g., all data in the first LCH cache that has not been reported through the DSR MAC CE).
[0149] Optionally, data whose data volume is not reported through the DSR MAC CE may include at least one of the following: data whose data volume has not been reported as latency-critical data in the DSR MAC CE; or data whose data volume is not reported through the data volume information in the DSR MAC CE. For example, the access network device may configure multiple DSR reporting thresholds for the terminal, each DSR reporting threshold corresponding to at least one data volume information in the DSR MAC CE, and the multiple DSR reporting thresholds collectively correspond to one or more data volume information in the DSR MAC CE; data whose data volume is not reported through the data volume information in the DSR MAC CE may include: data whose data volume is not reported through any / any data volume information in the one or more data volume information.
[0150] For example, threshold #1 may be a threshold configured by the access network device for the first LCH, or it may be a threshold configured by the access network device for the first LCG, where the first LCH is a logical channel in the first LCG.
[0151] (2) There are currently no pending DSRs for the first LCH:
[0152] Optionally, the absence of a pending DSR for the first LCH can be understood as at least one of the following: the first LCH currently has no pending DSR / suspended DSR / dSR to be transmitted; or, the first LCH does not have a pending DSR.
[0153] In some examples, the DSR triggering conditions include: the minimum remaining time of the packet loss timer corresponding to the data cached in the first LCH is less than or equal to threshold #1, and there is currently no pending DSR for the first LCH. That is, the terminal can trigger a DSR for the first LCH if the minimum remaining time of the packet loss timer corresponding to the data cached in the first LCH is less than or equal to threshold #1, and there is currently no pending DSR for the first LCH.
[0154] 2. Report (or send) DSR:
[0155] After DSR is triggered, the terminal can report DSR. For example, the terminal can send DSR MAC CE, which may include information on latency-critical data.
[0156] In some implementations, the DSR MAC CE may include information about one or more LCGs reported at the LCG granularity; correspondingly, the terminal may include information about one or more LCGs reported at the LCG granularity in the DSR MAC CE. Optionally, the LCG information may be related to a threshold (hereinafter referred to as threshold #2, or reporting threshold, or DSR reporting threshold) configured by the access network device for reporting DSR.
[0157] In some examples, threshold #2 can be the threshold used to trigger DSR (i.e., threshold #1 mentioned above), and the terminal can report information on latency-critical data based on threshold #1.
[0158] In other examples, the access network device can be configured with multiple thresholds #2 (or multiple DSR reporting thresholds or multiple reporting thresholds). The terminal can report information related to the multiple thresholds #2 based on these multiple thresholds #2. The relationship between these multiple thresholds #2 and threshold #1 is not limited. For example, threshold #1 may be less than or equal to the minimum value among the multiple thresholds #2; or threshold #1 may be greater than or equal to the maximum value among the multiple thresholds #2; or threshold #1 may be less than the maximum value among the multiple thresholds #2 and greater than the minimum value among the multiple thresholds #2.
[0159] For example, if the threshold #1 configured by the access network device is less than or equal to the minimum value among multiple thresholds #2, the terminal may include at least one of the following in the DSR MACCE: information on latency-critical data, information on data arriving earlier than the latency-critical data (if any data arrives earlier than the latency-critical data), or information on non-latency-critical data whose remaining time of the corresponding packet loss timer is greater than threshold #1 and corresponds to one or more of the multiple thresholds #2. If the threshold #1 configured by the access network device is greater than or equal to the maximum value among multiple thresholds #2, the terminal may include at least one of the following in the DSR MACCE: information on latency-critical data, or information on data arriving earlier than the latency-critical data (if any data arrives earlier than the latency-critical data), wherein the latency-critical data corresponds to one or more of the multiple thresholds #2. If the threshold #1 configured by the access network device is less than the maximum value among multiple thresholds #2 and greater than the minimum value among multiple thresholds #2, the terminal may include at least one of the following in the DSR MAC CE: information on latency-critical data; information on data whose arrival time is earlier than the latency-critical data (if there is data whose arrival time is earlier than the latency-critical data), wherein the latency-critical data corresponds to one or more thresholds #2 among multiple thresholds #2; or information on non-latency-critical data whose remaining time of the corresponding packet loss timer is greater than threshold #1 and corresponds to one or more thresholds #2 among multiple thresholds #2.
[0160] The following example illustrates DSR MAC CE.
[0161] The DSR MAC CE may include: information on latency-critical data of one or more LCGs reported at the LCG granularity; or, the DSR MAC CE may include: information on one or more LCGs reported at the LCG granularity, wherein the information on the one or more LCGs includes information on latency-critical data of the one or more LCGs. The latency-critical data information may include at least one of the following: remaining time information of the latency-critical data, data volume information of the latency-critical data, or data volume table information of the latency-critical data, etc. For example, the DSR MAC CE may be as follows: Figure 2 As shown.
[0162] The first LCG is one of the one or more LCGs. The following explanation uses the latency key data of the first LCG as an example.
[0163] (1) Remaining Time Information: The remaining time information may be referred to as the remaining time field; or, the remaining time information may be indicated by the remaining time field. The remaining time information may indicate the minimum remaining time of the packet loss timers corresponding to all PDCP SDUs cached in the first LCG that have not been transmitted via any MAC PDU. Optionally, the minimum remaining time may be the minimum remaining time of the packet loss timers corresponding to all PDCP SDUs cached in the first LCG that have not been transmitted via any MAC PDU at time #1. Wherein, time #1 may be the time corresponding to the first symbol occupied by the first physical uplink shared channel (PUSCH), and the first PUSCH may be the PUSCH including the DSR MAC CE. Optionally, the length of the remaining time field may be 6 bits. Optionally, the remaining time field will only appear, be valid, or take a valid value when the buffer size indicated by the corresponding buffer size field is not zero; when the buffer size indicated by the corresponding buffer size field is zero, the value of the remaining time field is 0, or in other words, the remaining time field can be set to 0.
[0164] (2) Data Volume Information: The data volume information can be referred to as the buffer size field; alternatively, the data volume information can be indicated through the buffer size field. The data volume information can indicate the data volume of latency-critical data for the first LCG. Optionally, this data volume may include: the data volume of latency-critical data for the PDCP entity, and the data volume of latency-critical data for the RLC entity. The data volume of latency-critical data for the PDCP entity can be understood as the data volume calculated by the PDCP entity, and the data volume of latency-critical data for the RLC entity can be understood as the data volume calculated by the RLC entity. For example, the amount of delay-critical data for a PDCP entity may include at least one of the following: a delay-critical PDCPSDU that has not been constructed as a PDCP data PDU, a lower-layer PDCP data PDU containing a delay-critical PDCP SDU that has not yet been transmitted to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted (or to be retransmitted), or a PDCP data PDU to be retransmitted (or to be retransmitted); the delay-critical data for an RLC entity includes at least one of the following: a delay-critical RLCSDU or a segment of a delay-critical RLCSDU that has not been constructed as an RLC data PDU, an RLCData PDU to be initially transmitted containing a delay-critical RLC SDU or a segment of a delay-critical RLC SDU, an RLC data PDU to be retransmitted (or to be retransmitted), or an RLC status report.
[0165] (3) Data Volume Table Information: The data volume table information can be referred to as the buffer size table (BT) field; or, the data volume table information can be indicated by the buffer size table field. Optionally, the buffer size table field exists, is valid, or takes a valid value only when the first LCG is configured with the first parameter and the buffer size indicated by the buffer size field corresponding to the first LCG is not 0; when the first LCG is not configured with the first parameter, and / or the buffer size indicated by the buffer size field corresponding to the first LCG is 0, the value of the buffer size table field is 0, or in other words, the buffer size table field can be set to 0. The first parameter can indicate whether the terminal is allowed to use refined buffer size levels for the first LCG. For example, when the value of the first parameter is 1, it can indicate whether the terminal is allowed to use refined buffer size levels for the first LCG. Optionally, the first parameter can be an additional BS-TableAllowed parameter.
[0166] In some implementations, for scenarios where multiple thresholds #2 are configured for access network devices, the terminal can report information corresponding to each of one or more thresholds #2 through the DSR MAC CE. For details, please refer to the above explanation of "the terminal can report information about data related to multiple thresholds #2 based on these multiple thresholds #2," which will not be repeated here. Optionally, the DSR MAC CE may include: information about the data of one or more LCGs (e.g., information about the data to be reported), and the information about the data of these one or more LCGs may include information corresponding to each of the one or more thresholds #2. For example, the data information may include at least one of the following: remaining time information, data volume information, or data volume table information, etc. Wherein, one or more of the remaining time information, data volume information, or data volume table information may be information corresponding to each of the one or more thresholds #2. The specific content of the remaining time information, data volume information, and data volume table information of the data can be found in the above descriptions of the remaining time information, data volume information, and data volume table information of the latency key data. The latency key data will simply be replaced with data, and will not be described again.
[0167] 3. Cancel DSR:
[0168] Once a DSR is triggered, the DSR can be considered to be in a pending state until it is canceled. Therefore, canceling a DSR can also be understood as canceling a pending DSR.
[0169] Optionally, the terminal may cancel DSR in at least one of the following situations:
[0170] Scenario 1: All PDCP SDUs associated with the DSR have been discarded.
[0171] Scenario 2: A MAC PDU is transmitted, which includes a DSR MAC CE that contains the delay information of all the PDCP SDUs associated with the DSR; or
[0172] Scenario 3: A MAC PDU is transmitted, which includes all the PDCP SDUs associated with the DSR.
[0173] Optionally, if a PDCP SDU is not transmitted in any MAC PDU and is a delay-critical PDCP SDU associated with the LCH that triggered the DSR, then the PDCP SDU is a PDCP SDU associated with the DSR.
[0174] Optionally, in "The terminal can cancel DSR under at least one of the following conditions", "under at least one of the following conditions" can be replaced with: under at least one of the following conditions is met; the conditions in conditions 1, 2 and 3 can be replaced with conditions.
[0175] VII. Buffer Status Report (BSR):
[0176] A BSR can be used to indicate the size of uplink data to be transmitted in the terminal. Optionally, the format of a BSR may include at least one of the following:
[0177] 1. A Long BSR can include information from multiple LCGs, such as indexes of multiple LCGs. The length of a Long BSR is variable. For example, the length of a Long BSR can vary depending on the number of LCGs it includes.
[0178] 2. Short BSR can include information about an LCG, such as an index of the LCG. The length of a short BSR is fixed.
[0179] 3. Truncated BSRs can be used to carry zero-padding data. Truncated BSRs can include long truncated BSRs and short truncated BSRs. Long truncated BSRs are used to carry zero-padding data. Short truncated BSRs are used to carry zero-padding data.
[0180] The following explains the circumstances (or conditions) for canceling a BSR.
[0181] In some possible ways, when uplink resources can accommodate all pending data available for transmission but are insufficient to accommodate additional BSR MAC CE and its subheadings, all triggered BSRs can be cancelled; correspondingly, when uplink resources can accommodate all pending data available for transmission but are insufficient to accommodate additional BSR MAC CE and its subheadings, the terminal can cancel all triggered BSRs.
[0182] In other possible approaches, when a MAC PDU is transmitted, and the MAC PDU includes at least one of a long BSR MAC CE, an extended long BSR MAC CE, a refined long BSR MAC CE, a short BSR MAC CE, or an extended short BSR MAC CE, all BSRs triggered before the MAC PDU is assembled (or generated) can be cancelled; correspondingly, when a MAC PDU is transmitted, and the MAC PDU includes at least one of a long BSR MAC CE, an extended long BSR MAC CE, a refined long BSR MAC CE, a short BSR MAC CE, or an extended short BSR MAC CE, the terminal can cancel all BSRs triggered before the MAC PDU is assembled (or generated). The aforementioned MAC CEs included in the MAC PDU may include: a buffer state up to (including) the last event that triggered a BSR before the MAC PDU was assembled (or generated).
[0183] 8. Dual connectivity (DC):
[0184] In a dual-connectivity scenario, a terminal can connect to two access network devices simultaneously. Optionally, these two access network devices can be referred to as the master node (MN) and the secondary node (SN), respectively. Optionally, MN can be an access network device connected to the control plane and the core network, or MN can be an access network device carrying control plane connectivity; SN can be an access network device not connected to the control plane and the core network, or SN can be the other of the two access network devices besides MN. SN can provide additional auxiliary radio resources for the terminal.
[0185] Optionally, the dual connectivity scenario may include at least one of the following scenarios: an Intra-E-UTRA dual connectivity scenario within the evolved-universal terrestrial radio access (E-UTRA) standard, or a multi-radio dual connectivity (MR-DC) scenario.
[0186] Optionally, in a dual-connectivity scenario, the terminal can be configured with a master cell group (MCG) and a secondary cell group (SCG). An MCG can be understood as a group of cells associated with a primary cell (MN), and an SCG can be understood as a group of cells associated with a secondary cell (SN). For example, an MCG may include a primary cell (PCell), and optionally, an MCG may also include one or more secondary cells (SCells); an SCG may include primary and secondary cells (PSCells), and optionally, an SCG may also include one or more SCells. A PCell can be understood as the primary cell of the MCG, a PSCell as the primary cell of the SCG, and an SCell as a secondary cell of either the MCG or the SCG.
[0187] In dual-connectivity scenarios, the terminal can be configured with a split bearer. A split bearer can be understood as: the terminal simultaneously having radio bearers corresponding to RLC bearers in both the MCG and SCG; or, the terminal simultaneously having radio bearers with RLC bearers in both the MCG and SCG.
[0188] When the terminal is configured with a separate bearer, such as Figure 3As shown, the entities corresponding to this separate bearer may include: a PDCP entity, a master node RLC (MN RLC, RLC-M) entity, a master node MAC (MN MAC, MAC-M) entity, a secondary node RLC (SNRLC, RLC-S) entity, and a secondary node MAC (SN MAC, MAC-S) entity. The RLC-M and MAC-M entities are used to communicate with the MN, while the RLC-S and MAC-S entities are used to communicate with the SN. Specifically, the RLC-M entity can be referred to as the master RLC entity, the MAC-M entity as the master MAC entity, the RLC-S entity as the secondary RLC entity, and the MAC-S entity as the secondary MAC entity. Optionally, when the dual connectivity scenario is any of the following scenarios, the above-mentioned PDCP entity may include an NR PDCP entity, the above-mentioned RLC entity may include an E-UTRA RLC entity and / or an NR RLC entity, and the above-mentioned MAC entity may include an E-UTRA MAC entity and / or an NR MAC entity: E-UTRA-NR dual connectivity (EN-DC), next-generation-RAN (NG-RAN) E-UTRA-NR dual connectivity (NGEN-DC), NR-E-UTRA dual connectivity (NE-DC), or NR-NR dual connectivity (NR-NR dual connectivity (NR-DC).
[0189] After receiving data, the PDCP entity can transmit the data to a lower layer (or lower layer) of the PDCP layer. For example, after receiving data from a higher layer (or upper layer) of the PDCP layer, the PDCP entity can transmit the data to the RLC entity, where the higher layer of the PDCP layer is, for example, the Service Data Adaptation Protocol (SDAP) layer. In a dual-connectivity scenario, the PDCP entity can decide which RLC entity to transmit the current data to based on the total amount of data. For example, if the total amount of data is greater than or equal to threshold #3 (e.g., the uplink data splitting threshold (ul-DataSplitThreshold)), the PDCP entity can transmit the data to RLC-M or RLC-S; if the total amount of data is less than threshold #3, the PDCP entity can deliver the data to RLC-M. The total amount of data can include at least one of the following: the data volume of the PDCP entity, the data volume of the RLC-M entity (e.g., the amount of data to be initially transmitted in the RLC-M entity), or the data volume of the RLC-S entity (e.g., the amount of data to be initially transmitted in the RLC-S entity).
[0190] 9. In this application, "instruction" or "for instruction" may include explicit instruction (or direct instruction) and implicit instruction (or indirect instruction). When describing information for instructing A, it may include whether the information explicitly instructs A or implicitly instructs A, but does not necessarily mean that the information carries A.
[0191] The indication methods involved in the embodiments of this application should be understood to cover various methods that enable the party to be indicated to obtain the information to be indicated. The information to be indicated can be sent as a whole or divided into multiple sub-information and sent separately. Moreover, the sending period and / or sending time of these sub-information can be the same or different, without limitation.
[0192] In the embodiments of this application, "information" can be an explicit indication, that is, a direct indication through signaling, or obtained by combining other rules or parameters with parameters indicated by signaling, or by deduction. It can also be an implicit indication, that is, obtained based on rules or relationships, or based on other parameters, or by deduction. No limitation is imposed.
[0193] 10. In this application, communication between different devices can refer to direct communication between different devices (i.e., without the need for relaying or forwarding by other devices), or communication between different devices through other devices (i.e., requiring relaying or forwarding by other devices), or communication between a functional unit within a device and other devices through another functional unit. For example, "sending information to…(terminal)" can be understood as the destination of the information being the terminal, and may include sending information directly or indirectly to the terminal. "Receiving information from…(terminal)" can be understood as the source of the information being the terminal, and may include receiving information directly or indirectly from the terminal. Information may undergo necessary processing between the source and destination ends, such as format changes, digital-to-analog conversion, amplification, filtering, etc., but the destination end can understand the valid information from the source end. Similar expressions in this application can be understood in a similar way, and will not be elaborated further here.
[0194] XI. In this application, the words "exemplarily," "for example," "for instance," and "example" are used to indicate examples, illustrations, or explanations, and are not intended to limit the scope of protection of this application. It should be understood that the examples in this application may also be implemented in other ways. In this application, "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably, and it should be noted that when their distinction is not emphasized, their intended meanings are consistent.
[0195] 12. In this application, any two of the programs, instructions, and code may be substituted for one another.
[0196] Thirteen, in this application, "greater than or equal to" and "greater than" can be used interchangeably. For example, "A is greater than threshold 1" and "A is greater than or equal to threshold 1" can be used interchangeably. "Less than or equal to" and "less than" can be used interchangeably. For example, "A is less than threshold 1" and "A is less than or equal to threshold 1" can be used interchangeably.
[0197] 14. In this application, “in the case of…”, “when…”, “if…”, and “if…” can have the same meaning and can be substituted for each other. Optionally, in this application, “in the case of…”, “when…”, “if…”, and “if…” all refer to the corresponding processing that will be carried out under certain objective circumstances, and are not limited to a time, nor do they require a judgment action at the time of implementation, nor do they imply the existence of other limitations.
[0198] 15. In this application, data in a certain LCH cache can be understood as data belonging to or corresponding to that LCH. For example, data in the first LCH cache can be understood as data belonging to the first LCH, or data corresponding to the first LCH.
[0199] In this application, data cached in a certain LCG can be understood as data belonging to or corresponding to that LCG. For example, data cached in the first LCG can be understood as data belonging to the first LCG, or data corresponding to the first LCG.
[0200] XVI. In this application, a transmission to a lower layer of a certain layer can be replaced by any of the following: submit, transmit, present, or output. For example, a transmission "to a lower layer of the PDCP layer" can be replaced by any of the following: submit, transmit, present, or output.
[0201] In this application, a lower layer of a certain layer can be replaced with any of the following: the layer below that layer, or the layer below that. For example, "the lower layer of the PDCP layer" can be replaced with any of the following: the layer below the PDCP layer, or the layer below that.
[0202] In this application, the transmission to an entity can be replaced by any of the following: submission, transmission, presentation, or output. For example, the transmission to a second MAC entity can be replaced by any of the following: submission, transmission, presentation, or output.
[0203] Currently, in dual-connectivity scenarios, both MAC entities of the terminal can execute the DSR procedure. For example, if data #1 is data to be transmitted by MAC-M entity, and the remaining time of the packet loss timer corresponding to data #1 is less than or equal to the threshold #1 corresponding to MAC-M entity, then MAC-M entity will execute at least one of the following DSR operations: triggering, reporting, and canceling. If data #1 is data to be transmitted by MAC-S entity, and the remaining time of the packet loss timer corresponding to data #1 is less than or equal to the threshold #1 corresponding to MAC-S entity, then MAC-S entity will execute at least one of the following DSR operations: triggering, reporting, and canceling. The threshold #1 corresponding to MAC-M entity and the threshold #1 corresponding to MAC-S entity can be the same or different.
[0204] How to cancel DSR, for example, how to cancel DSR in a dual-connection scenario, requires further research.
[0205] For example, in a dual-connectivity scenario, if the current total data volume is greater than or equal to threshold #3, data cached at the PDCP layer may be transmitted through either the MAC-M entity or the MAC-S entity. The specific details of the total data volume and threshold #3 can be found in the explanation of terms above, and will not be repeated here. If data #1 is cached at the PDCP layer, and the remaining time of the packet loss timer corresponding to data #1 is less than or equal to threshold #1 for both the MAC-M and MAC-S entities, then both the MAC-M and MAC-S entities trigger DSR. If data #1 triggers DSR through the MAC-M entity, the MAC-S entity cannot cancel the triggered DSR.
[0206] The following is for reference. Figure 4 The following example illustrates this point, using the case where the threshold #1 corresponding to the MAC-M entity and the threshold #1 corresponding to the MAC-S entity are the same.
[0207] At time T0, PDCP SDU#1 is cached in the PDCP layer. Optionally, the current total data volume is greater than or equal to threshold #3. If the total data volume is greater than or equal to threshold #3, the PDCP entity may transmit PDCP SDU#1 to the RLC-M entity or to the RLC-S entity.
[0208] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to threshold #1, both the MAC-M entity and the MAC-S entity will trigger DSR. The DSR triggered by the MAC-M entity can be represented as DSR#1, and the DSR triggered by the MAC-S entity can be represented as DSR#2.
[0209] At time T2, the MAC-M entity transmits MAC PDU#1, which contains PDCP SDU#1. For example, at time T2, if the MAC-M entity has transmission resources, it can transmit MAC PDU#1 including PDCP SDU#1. For instance, the PDCP entity can transmit PDCP SDU#1 to the RLC-M entity, which in turn can transmit PDCP SDU#1 to the MAC-M entity. Thus, the MAC-M entity can transmit MAC PDU#1 including PDCP SDU#1. When the MAC-M entity transmits MAC PDU#1, it can determine that condition 3 for canceling DSR described above is satisfied, thereby canceling DSR#1.
[0210] If the MAC-M entity transmits MAC PDU #1 including PDCP SDU #1, the MAC-S entity cannot cancel DSR #2. For example, at time T2, the MAC-M entity can transmit MAC PDU #1 including PDCP SDU #1; since there is no interaction between the MAC-M and MAC-S entities, at time T2, the MAC-S entity cannot cancel DSR #2 according to any of the conditions 1 to 3 above. As another example, at time T3, if the MAC-S entity has transmission resources, since PDCP SDU #1 no longer exists, therefore, at time T3, the MAC-S entity cannot cancel DSR #2 according to any of the conditions 1 to 3 above.
[0211] Optionally, the above example uses the transmission of MAC PDU#1, which includes PDCP SDU#1, by the MAC-M entity as an example, but it is not limited to this. For example, a MAC PDU containing PDCP SDU#1 can be transmitted by the MAC-S entity, in which case the MAC-M entity cannot cancel DSR#1.
[0212] In a dual-connection scenario, if the current total amount of data is greater than or equal to threshold #3, how to cancel DSR requires further research.
[0213] Based on this, embodiments of this application provide a communication method and apparatus for canceling DSR, for example, for canceling DSR in a dual-connectivity scenario. The method and apparatus described in this application are based on the same technical concept. Since the principles by which the method and apparatus solve the problem are similar, the implementations of the apparatus and method can be mutually referred to, and repeated details will not be elaborated further.
[0214] The various communication methods provided in the embodiments of this application will now be described in detail with reference to the accompanying drawings. These methods can be applied to... Figure 1The communication system shown is not limited to this. This application describes the interaction between a first device and a second device as an example. Optionally, the first device may be a terminal; the second device may be an access network device. Optionally, the method executed by the first device in this application may also be executed by a module for the first device (e.g., a communication module, circuits or chips responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or by a logical node, logical module, or software capable of implementing all or part of the functions of the first device, or by a combination of hardware and software. For example, the method executed by the first device in this application may be executed by a first MAC entity and / or a second MAC entity in the first device. The method executed by the second device in this application may also be executed by a module for the second device (e.g., a communication module, circuits or chips responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), a chip system, or a processor), or by a logical node, logical module, or software capable of implementing all or part of the functions of the second device, or by a combination of hardware and software.
[0215] It is understood that in the embodiments of this application, the first device and / or the second device may perform some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also perform other operations or variations thereof. Furthermore, the steps may be performed in different orders as presented in the embodiments of this application, and it is not necessarily necessary to perform all the operations in the embodiments of this application.
[0216] Figure 5 This is a flowchart illustrating a communication method provided in an embodiment of this application. Figure 5 As shown, the method may include:
[0217] S501: The first device triggers the first DSR corresponding to the first MAC entity.
[0218] The first device may include a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity can be used to transmit data of the first device. For example, the first MAC entity is... Figure 3 The MAC-M entity shown is the second MAC entity. Figure 3 The MAC-S entity shown; or, the first MAC entity is Figure 3 The MAC-S entity shown is the second MAC entity. Figure 3 The MAC-M entity is shown. Thus, the first device can be a device in a dual-connectivity scenario; for example, the first device can be a terminal in a dual-connectivity scenario.
[0219] Optionally, the first device triggering the first DSR corresponding to the first MAC entity can be understood as either: the first MAC entity in the first device triggers the first DSR; or, the first device triggers the first DSR through the first MAC entity.
[0220] As mentioned above, the first device can trigger the first DSR corresponding to the first MAC entity in various ways, such as method a1 or method a2.
[0221] Method a1: If condition #1 is met, the first device may trigger the first DSR corresponding to the first MAC entity. Condition #1 may include at least one of the following conditions #a1 to #a3:
[0222] Condition #a1: PDU SDU#1 is data cached in the PDCP layer, and the remaining time of the packet loss timer corresponding to PDU SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity.
[0223] Optionally, PDU SDU#1 is data cached in the PDCP layer, which can be understood as at least one of the following: PDU SDU#1 is data of the PDCP entity; or PDU SDU#1 is data received by the PDCP entity but not transmitted to a lower layer of the PDCP layer.
[0224] Optionally, the remaining time of the packet loss timer corresponding to PDU SDU#1 being less than or equal to the threshold #1 corresponding to the first MAC entity can be understood as at least one of the following: in the data of the first LCH cache, there exists a PDU SDU#1 whose remaining time of the corresponding packet loss timer is less than or equal to the threshold #1 corresponding to the first MAC entity; or, PDU SDU#1 is the data in the data of the first LCH cache with the smallest remaining time of the corresponding packet loss timer, and the remaining time of the packet loss timer corresponding to PDU SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity.
[0225] Optionally, the threshold #1 corresponding to the first MAC entity can be understood as at least one of the following: a threshold for triggering the DSR corresponding to the first MAC entity; or a threshold for triggering the DSR for the first LCH through the first MAC entity; or a threshold for triggering the DSR for one or more LCHs in the first LCG through the first MAC entity, wherein the first LCH belongs to the first LCG.
[0226] Optionally, condition #a1 can be understood as: PDU SDU#1 is data cached in the PDCP layer, and PDU SDU#1 is latency-critical data.
[0227] The following example illustrates condition #a1.
[0228] For example, after receiving PDU SDU#1, the PDCP entity can start a packet loss timer #1 for PDU SDU#1. If the threshold #1 corresponding to the first MAC entity is 5ms, and PDU SDU#1 is still cached in the PDCP layer when the remaining time of packet loss timer #1 is less than or equal to 5ms, then condition #a1 is satisfied.
[0229] Condition #a2: The current total amount of data is greater than or equal to threshold #3.
[0230] The specific details regarding the total data volume and threshold #3 can be found in the explanation of terms above, where the RLC-S entity is replaced with the first RLC entity and the RLC-M entity with the second RLC entity. The first RLC entity can be the entity between the PDCP entity and the first MAC entity; the second RLC entity can be the entity between the PDCP entity and the second MAC entity.
[0231] Optionally, the first RLC entity can be an entity between the PDCP entity and the first MAC entity, which can be understood as: the first RLC entity is the RLC entity associated with the LCH corresponding to the first MAC entity. The second RLC entity can be an entity between the PDCP entity and the second MAC entity, which can be understood as: the second RLC entity is the RLC entity associated with the LCH corresponding to the second MAC entity. For example, the first MAC entity is... Figure 3 The MAC-M entity shown is the first RLC entity. Figure 3 The RLC-M entity shown is the second MAC entity. Figure 3 The MAC-S entity shown is the second RLC entity. Figure 3 The RLC-S entity shown; or, the first MAC entity is Figure 3 The MAC-S entity shown is the first RLC entity. Figure 3 The RLC-S entity shown is the second MAC entity. Figure 3 The MAC-M entity shown is the second RLC entity. Figure 3 The RLC-M entity shown.
[0232] Optionally, the entity between the PDCP entity and the first MAC entity may not include the PDCP entity and the first MAC entity, and the entity between the PDCP entity and the second MAC entity may not include the PDCP entity and the second MAC entity.
[0233] The following example illustrates condition #a2.
[0234] For example, the total data volume includes the data volume of the PDCP entity. PDCP SDU#1 and PDCP SDU#2 are cached in the PDCP layer; in other words, PDCP SDU#1 and PDCP SDU#2 are the data of the PDCP entity. If threshold #3 is 5 megabytes (MB), the data volume of PDCP SDU#1 is 4MB, and the data volume of PDCP SDU#2 is 2MB, then the current total data volume is 4 + 2 = 6MB. The current total data volume is greater than or equal to threshold #3, and condition #a2 is satisfied.
[0235] For example, the total data volume includes: the data volume of the PDCP entity, the data volume of the first RLC entity, and the data volume of the second RLC entity. PDCP SDU#1 is cached in the PDCP layer, PDCP SDU#2 is cached in the RLC layer corresponding to the first RLC entity (e.g., PDCP SDU#2 has been constructed as a PDCP PDU and transmitted to the first RLC entity), and PDCP SDU#3 is cached in the RLC layer corresponding to the second RLC entity (e.g., PDCP SDU#3 has been constructed as a PDCP PDU and transmitted to the first RLC entity); in other words, PDCP SDU#1 is the data of the PDCP entity, PDCP SDU#2 is the data of the first RLC entity, and PDCP SDU#3 is the data of the second RLC entity. If the threshold #3 is 5MB, the data volume of PDCP SDU#1 is 4MB, the data volume of PDCP SDU#2 is 1MB, and the data volume of PDCP SDU#3 is 1MB, then the current total data volume is 4+1+1=6MB. The current total data volume is greater than or equal to the threshold #3, and condition #a2 is satisfied.
[0236] Condition #a3: PDU SDU#1 is the data cached in the first LCH. Currently, there is no pending DSR for the first LCH in the DSR corresponding to the first MAC entity.
[0237] In some examples, condition #1 may include condition #a1 and condition #a3. Optionally, in this example, the current total amount of data may be greater than or equal to threshold #3; or, the current total amount of data may be less than threshold #3.
[0238] In other examples, condition #1 may include conditions #a1 through #a3.
[0239] By means of method a1, the first device can accurately trigger the first DSR according to condition #1.
[0240] Method a2: Under the condition that the second condition is met, the first device may trigger the first DSR. The second condition may include condition #2: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0241] For example, the first device includes a first MAC entity and a second MAC entity. PDU SDU#1 is latency-critical data associated with the first DSR. If PDU SDU#1 is transmitted by either the first MAC entity or the second MAC entity, then condition #2 is not satisfied; if PDU SDU#1 is not transmitted by either the first MAC entity or the second MAC entity, then condition #2 is satisfied.
[0242] Optionally, condition #2 can be replaced with condition #2': The latency-critical data associated with the first DSR is not transmitted by any MAC entity in the first device other than the first MAC entity.
[0243] For example, the first device includes a first MAC entity and a second MAC entity. PDU SDU#1 is latency-critical data associated with the first DSR. If PDU SDU#1 is transmitted by the second MAC entity, then condition #2' is not satisfied; if PDU SDU#1 is not transmitted by the second MAC entity, then condition #2' is satisfied.
[0244] Optionally, the first device includes a first MAC entity and a second MAC entity. The threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity may be different. For example, the threshold #1 corresponding to the first MAC entity is 3ms, and the threshold #1 corresponding to the second MAC entity is 5ms.
[0245] For details regarding the threshold #1 corresponding to the first MAC entity, please refer to method a1 for the section on "threshold corresponding to the first MAC entity".
[0246] The explanation of "#1"; the specific content of the threshold #1 corresponding to the second MAC entity can be found in the explanation of "threshold #1 corresponding to the first MAC entity" in method a1, except that the first MAC entity is replaced with the second MAC entity, the first LCH is replaced with the second LCH, and the first LCG is replaced with the second LCG, which will not be repeated here.
[0247] In some implementations, the second condition may also include condition #1. For details on condition #1, please refer to the explanation of condition #1 in method a1; it will not be repeated here.
[0248] The following is combined with Figure 6A Here is an example illustrating method a2.
[0249] At time T1, PDCP SDU#1 is cached in the PDCP layer, and the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the second MAC entity (e.g., 5ms). If the DSR triggering condition corresponding to the second MAC entity is met at this time, the first device can trigger the second DSR corresponding to the second MAC entity. The DSR triggering condition corresponding to the second MAC entity can be referenced from the second condition, except that the first MAC entity is replaced by the second MAC entity, the first LCH is replaced by the second LCH, and the first LCG is replaced by the second LCG; further details are omitted here.
[0250] At time T2, the second MAC entity transmits MAC PDU#1, which contains PDCP SDU#1. For example, at time T2, if the second MAC entity has transmission resources, it can transmit MAC PDU#1 including PDCP SDU#1. For instance, the PDCP entity can transmit PDCP SDU#1 to the second RLC entity, and the second RLC entity can transmit PDCP SDU#1 to the second MAC entity. Thus, the second MAC entity can transmit MAC PDU#1 including PDCP SDU#1.
[0251] At time T3, the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity (e.g., 3ms). If time T3 is after time T2, then since PDCP SDU#1 has been transmitted by the second MAC entity, condition #2 is not met. Therefore, the first device will not trigger the DSR corresponding to the first MAC entity.
[0252] It should be understood that this application is applicable to both situations where the current total amount of data is greater than or equal to threshold #3 and situations where the current total amount of data is less than threshold #3. Figure 6A And the following text Figures 6B to 6D The example is taken when the current total amount of data is greater than or equal to threshold #3.
[0253] By means of method a2, the first device may trigger the first DSR only if the latency-critical data associated with the first DSR is not transmitted by any MAC entity in the first device. This avoids the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device. This also avoids the first device continuously marking DSRs that cannot be canceled and are yet to be transmitted, thereby reducing the power consumption of the first device.
[0254] Among some possible approaches, in approach a2, Figure 5 The method shown also includes step A1:
[0255] Step A1: The second device sends the second configuration information; correspondingly, the first device receives the second configuration information.
[0256] The second configuration information can be used to instruct (or configure) the first device to trigger the first DSR when the second condition is met. This application does not limit the specific instruction method. For example, it can be an explicit instruction or an implicit instruction.
[0257] The second configuration information can be carried in a traditional message or in a new message, without restriction. For example, the second configuration information can be carried in downlink control information (DCI), MAC CE, or radio resource control (RRC) messages.
[0258] The second configuration information may have other names, such as trigger configuration information, indication information, or trigger indication information, without restriction.
[0259] Optionally, step A1 can be performed before S501.
[0260] In this method, the first device can trigger the first DSR when the second condition is met, based on the second configuration information. Furthermore, in this method, the second configuration information is sent from the second device to the first device, allowing the second device to flexibly configure or instruct the operation of the first device.
[0261] Among some possible approaches, in approach a2, Figure 5 The method shown also includes step B1:
[0262] Step B1: The first device sends the second capability information; correspondingly, the second device receives the second capability information.
[0263] The second capability information can be used to indicate that the first device has the capability to trigger the first DSR when the second condition is met. This application does not limit the specific indication method. For example, it can be indicated explicitly or implicitly.
[0264] Optionally, the second capability information can be used to indicate that the first device has the capability to trigger the first DSR when the second condition is met. This can be understood as: the second capability information can be used to indicate that the first device is able to trigger the first DSR when the second condition is met.
[0265] Optionally, the second capability information can be used to determine (or trigger) the second configuration information. For example, after receiving the second capability information, the second device can determine the second configuration information and send the second configuration information to the first device.
[0266] Secondary capability information can be carried in traditional messages or in new messages, without restriction. For example, secondary capability information can be carried in uplink control information (UCI), MAC CE, or RRC messages.
[0267] Secondary capability information may have other names, such as capability indication information, and there are no restrictions.
[0268] Optionally, step B1 may be performed before step A1.
[0269] In this way, the first device can accurately report to the second device, through the second capability information, that the first device has the capability to trigger the first DSR under the condition that the second condition is met. Thus, the second device can determine a configuration for the first device that is appropriate to its capabilities.
[0270] S502: If the amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold, the first device may cancel the first DSR.
[0271] The first data volume refers to the total data volume of at least one latency-critical data associated with the first DSR. This at least one latency-critical data includes latency-critical data for each of the N1 entities, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first RLC entity. The first RLC entity can be an entity between the PDCP entity and the first MAC entity. The specific content of the first RLC entity can be found in the description of the first RLC entity in method a1 of S501 above, and will not be repeated here.
[0272] Optionally, the latency-critical data of a PDCP entity may include at least one of the following: a latency-critical PDCP SDU not constructed as a PDCP data PDU, a lower-layer PDCP data PDU containing a latency-critical PDCP SDU but not yet transmitted to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted (or retransmitted PDCP SDU), or a PDCP data PDU to be retransmitted (or retransmitted PDCP data PDU). For example, the PDCP SDU to be retransmitted may be a PDCP SDU corresponding to an acknowledged mode (AM) DRB, such as a PDCP PDU to be retransmitted in a PDCP reconstruction or uplink data switching scenario; the PDCP data PDU to be retransmitted may be a PDCP data PDU corresponding to an AM DRB, such as a PDCP data PDU to be retransmitted in a data recovery scenario.
[0273] Optionally, the latency-critical data of the first RLC entity may include at least one of the following: a latency-critical RLC SDU or a latency-critical RLC SDU segment that is not constructed as an RLC dataPDU, an RLC Data PDU to be initially transmitted containing a latency-critical RLC SDU or a latency-critical RLC SDU segment, an RLC data PDU to be retransmitted, or an RLC status report. Here, a latency-critical RLC SDU or a latency-critical RLC SDU segment that is not constructed as an RLC data PDU can be understood as a latency-critical RLC SDU or a latency-critical RLC SDU segment not included in the RLC data PDU. For example, the RLC dataPDU to be retransmitted may be the RLC dataPDU to be retransmitted corresponding to the AM RLC.
[0274] Optionally, when the at least one latency key data is a single latency key data, the first data volume is the data volume of the single latency key data; when the at least one latency key data is multiple latency key data, the first data volume is the sum of the data volumes of the multiple latency key data.
[0275] The first threshold can be preset, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0276] Optionally, the first threshold can be used to measure the size of the first data volume. When the first data volume is less than or equal to the first threshold, the first data volume associated with the first DSR is small, and the first device can cancel the first DSR.
[0277] Optionally, the first threshold may be greater than or equal to zero. For example, the first threshold may be zero. When the first threshold is zero, S502 can be understood as follows: if the first amount of data to be transmitted by the first MAC entity is zero, the first device may cancel the first DSR.
[0278] Optionally, the first data quantity to be transmitted by the first MAC entity being zero can be replaced by at least one of the following: at least one delay key data to be transmitted by the first MAC entity does not exist, and the at least one delay key data is associated with the first DSR; the delay key data associated with the first DSR to be transmitted by the first MAC entity does not exist; there is no at least one delay key data to be transmitted by the first MAC entity, and the at least one delay key data is associated with the first DSR; there is no delay key data associated with the first DSR to be transmitted by the first MAC entity; the delay key data associated with the first DSR (e.g., delay key PDCP SDU) becomes unavailable for transmission, for example, all delay key data (e.g., delay key PDCP SDU) associated with the first DSR becomes unavailable for transmission; or, the delay key data (e.g., delay key PDCP SDU) associated with the first DSR is unavailable for transmission, for example, all delay key data (e.g., delay key PDCP SDU) associated with the first DSR is unavailable for transmission. The following explanation uses the example of the first data quantity to be transmitted by the first MAC entity being zero.
[0279] Optionally, the cancellation of the first DSR by the first device can also be understood as: the first MAC entity in the first device cancels the first DSR, or the first device cancels the first DSR through the first MAC entity.
[0280] The following is combined with Figure 6B Here is an example of S502.
[0281] At time T0, PDCP SDU#1 is cached in the PDCP layer. In some examples, the current total data volume is greater than or equal to threshold #3. For details regarding "the current total data volume is greater than or equal to threshold #3," please refer to the explanation of condition #a2 in S501, which will not be repeated here. In other examples, the current total data volume is less than threshold #3. For details regarding the total data volume and threshold #3, please refer to the explanations of the terms above, which will not be repeated here.
[0282] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity, the first device triggers the first DSR corresponding to the first MAC entity.
[0283] At time T2, the first data volume to be transmitted by the first MAC entity is zero. For example, at time T2, if all latency-critical data associated with the first DSR in the first device is PDCP SDU#1, and PDCP SDU#1 belongs neither to the latency-critical data of the PDCP entity nor to the latency-critical data of the first RLC entity, then the first data volume is zero. For instance, at time T2, if all latency-critical data associated with the first DSR in the first device is PDCP SDU#1, and PDCP SDU#1 has already been transmitted to the RLC layer corresponding to the second RLC entity or the MAC layer corresponding to the second MAC entity, or PDCP SDU#1 has already been transmitted by the second MAC entity, then PDCP SDU#1 belongs neither to the latency-critical data of the PDCP entity nor to the latency-critical data of the first RLC entity. In this case, for the first MAC entity, the first data volume is less than or equal to the first threshold, and the first device can cancel the first DSR.
[0284] In some possible scenarios, latency-critical data may be transmitted by a second MAC entity. Optionally, "latency-critical data may be transmitted by a second MAC entity" can be combined with... Figure 5 Other features in the method shown may be combined, for example, with one or more of the methods b1 to b3 described below.
[0285] Optionally, if latency-critical data is transmitted by the second MAC entity, it may include: latency-critical data associated with the first DSR being transmitted by the second MAC entity. Accordingly, S502 may be replaced by: if the amount of first data to be transmitted by the first MAC entity is less than or equal to a first threshold, and latency-critical data associated with the first DSR is transmitted by the second MAC entity, the first device may cancel the first DSR.
[0286] Optionally, the transmission of latency-critical data by the second MAC entity can be understood as follows: the latency-critical data associated with the first DSR is not transmitted by the first MAC entity, or the latency-critical data associated with the first DSR is not transmitted through the first MAC entity, for example, the latency-critical data associated with the first DSR is not transmitted through the MAC PDU of the first MAC entity. That is, when the latency-critical data is transmitted by the second MAC entity, S502 can be replaced by: if the amount of first data to be transmitted by the first MAC entity is less than or equal to the first threshold, the first device can cancel the first DSR even if the latency-critical data associated with the first DSR is not transmitted by the first MAC entity. Alternatively, S502 can be replaced by: if the latency-critical data associated with the first DSR (e.g., latency-critical PDCP SDU) becomes unavailable for transmission, the first device can cancel the first DSR even if the latency-critical data associated with the first DSR is not transmitted by the first MAC entity. Alternatively, S502 can be replaced by: if the latency-critical data associated with the first DSR (e.g., latency-critical PDCP SDU) is unavailable for transmission, the first device may cancel the first DSR even if the latency-critical data associated with the first DSR is not transmitted by the first MAC entity.
[0287] Optionally, the determination that the first data volume to be transmitted by the first MAC entity is less than or equal to the first threshold can be based on the first indication information. For example, if the first device receives the first indication information through the first MAC entity, the first device can determine that the first data volume is less than or equal to the first threshold. For instance, the first device can determine that the first data volume is less than or equal to the first threshold through the first MAC entity. Accordingly, S502 can be replaced by: upon receiving the first indication information, even if the delay-critical data associated with the first DSR is not transmitted by the first MAC entity, the first device can cancel the first DSR. The specific content of the first indication information will be described in S503 and will not be elaborated here.
[0288] The following is combined with Figure 6C The example illustrates how the first device cancels the first DSR when critical data with time delay is transmitted by the second MAC entity.
[0289] At time T0, PDCP SDU#1 is cached in the PDCP layer. In some examples, the current total data volume is greater than or equal to threshold #3. For details regarding "the current total data volume is greater than or equal to threshold #3," please refer to the explanation of condition #a2 in S501, which will not be repeated here. In other examples, the current total data volume is less than threshold #3. For details regarding the total data volume and threshold #3, please refer to the explanations of the terms above, which will not be repeated here.
[0290] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity, the first device triggers the first DSR corresponding to the first MAC entity and the second DSR corresponding to the second MAC entity.
[0291] At time T2, the first data volume to be transmitted by the first MAC entity is zero. For example, at time T2, if all latency-critical data associated with the first DSR in the first device is PDCP SDU#1, and the second MAC entity transmits MAC PDU#1, where MACPDU#1 contains PDCP SDU#1, then the first data volume to be transmitted by the first MAC entity is zero. The following example illustrates "the second MAC entity transmitting MAC PDU#1". For instance, at time T2, if the second MAC entity has transmission resources, it can transmit MAC PDU#1 including PDCP SDU#1. For example, the PDCP entity can transmit this PDCP SDU#1 to the second RLC entity, and the second RLC entity can transmit the PDCP SDU#1 to the second MAC entity. Thus, the second MAC entity can transmit MAC PDU#1 including PDCP SDU#1. Here, PDCP SDU#1 is not transmitted through the first MAC entity. At this time, for the first MAC entity, the first data volume is less than or equal to the first threshold, and the first device can cancel the first DSR. Alternatively, for the first MAC entity, if the first data volume is less than or equal to the first threshold, the first device can cancel the first DSR even if the first MAC entity does not transmit PDCP SDU#1.
[0292] It should be understood that the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity can be the same or different. For example, the threshold #1 corresponding to the first MAC entity is equal to the threshold #1 corresponding to the second MAC entity; the threshold #1 corresponding to the first MAC entity is greater than the threshold #1 corresponding to the second MAC entity; or, the threshold #1 corresponding to the first MAC entity is less than the threshold #1 corresponding to the second MAC entity. For instance, if the threshold #1 corresponding to the first MAC entity is equal to the threshold #1 corresponding to the second MAC entity, then the first MAC entity and the second MAC entity can trigger DSR simultaneously for a data packet; if the threshold #1 corresponding to the first MAC entity is greater than the threshold #1 corresponding to the second MAC entity, then for a data packet, the first MAC entity can trigger DSR earlier than the second MAC entity, and the second MAC entity can trigger DSR later than the first MAC entity; if the threshold #1 corresponding to the first MAC entity is less than the threshold #1 corresponding to the second MAC entity, then for a data packet, the first MAC entity can trigger DSR later than the second MAC entity, and the second MAC entity can trigger DSR earlier than the first MAC entity. The above example illustrates the case where the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity are the same. For details regarding the threshold #1 corresponding to the first MAC entity, please refer to the explanation of "threshold #1 corresponding to the first MAC entity" in method a1; for details regarding the threshold #1 corresponding to the second MAC entity, please refer to the explanation of "threshold #1 corresponding to the first MAC entity" in method a1, except that the first MAC entity is replaced with the second MAC entity, and will not be repeated here.
[0293] Optionally, this method can be applied to situations where multiple thresholds #2 (or reporting thresholds) are not configured, or to situations where multiple thresholds #2 are configured. The specific details of thresholds #2 can be found in the explanation of terminology above, and will not be repeated here. For example, this method can be applied to situations where both the first MAC entity and the second MAC entity are configured with multiple thresholds #2, or to situations where either the first MAC entity or the second MAC entity is configured with multiple thresholds #2, or to situations where neither the first MAC entity nor the second MAC entity is configured with multiple thresholds #2.
[0294] pass Figure 5The method described above allows a first device to cancel a first DSR corresponding to a first MAC entity when the first data volume is less than or equal to a first threshold. The first data volume can be the amount of latency-critical data associated with the first DSR that the first MAC entity is waiting to transmit. This method avoids situations where the first device cannot cancel the first DSR if the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity. This prevents the first device from continuously marking uncancellable DSRs awaiting transmission, thereby reducing the power consumption of the first device.
[0295] Among some possible ways, Figure 5 The method shown also includes S503:
[0296] S503: The first device can receive the first instruction information through the first MAC entity.
[0297] Accordingly, S502 may include: the first device canceling the first DSR when the first data volume is less than or equal to the first threshold, based on the first indication information. The first device receiving the first indication information through the first MAC entity can be understood as the first device receiving the first indication information from a higher layer through the first MAC entity. The higher layer is, for example, the layer above the first MAC entity, such as the PDCP layer or the RLC layer.
[0298] In some possible designs, the first device may receive first indication information from the PDCP entity via the first MAC entity.
[0299] Optionally, the first device may receive first indication information from the PDCP entity through the first MAC entity, which can be understood as at least one of the following: the first MAC entity in the first device receives first indication information from the PDCP entity; the first device sends first indication information to the first MAC entity through the PDCP entity; or, the PDCP entity of the first device sends first indication information to the first MAC entity.
[0300] In some implementations, the first indication information from the PDCP entity can be used to indicate at least one of the following: all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device; all latency-critical data associated with the first DSR has been transmitted by the second MAC entity; the latency-critical data associated with the first DSR consists of a first portion of latency-critical data and a second portion of latency-critical data, the first portion of latency-critical data is transmitted to N2 entities, and the second portion of latency-critical data has been transmitted by the second MAC entity; the second data volume is less than or equal to a second threshold; or, the first data volume is less than or equal to a first threshold. Optionally, all latency-critical data associated with the first DSR can be understood as: all latency-critical PDCP SDUs associated with the first DSR.
[0301] The following is a detailed explanation of the content that the first instruction information can be used to indicate.
[0302] 1. All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0303] Wherein, N2 is a positive integer, and the N2 entities include at least one of the following: a second RLC entity or a second MAC entity. The second RLC entity is the entity between the PDCP entity and the second MAC entity. The specific contents of the second MAC entity and the second RLC entity can be found in the description of the second MAC entity and the second RLC entity in S501, and will not be repeated here.
[0304] Optionally, the transmission of all latency-critical data associated with the first DSR to N2 entities in the first device can be replaced by at least one of the following: all latency-critical data associated with the first DSR is transmitted to the second path; all latency-critical PDCP SDUs associated with the first DSR are transmitted to the N2 entities; or, all latency-critical PDCP SDUs are transmitted to the N2 entities. Optionally, the transmission of PDCP SDUs to the N2 entities can be understood as: the PDCP SDU is constructed as a PDCP PDU and transmitted to a lower layer of the PDCP layer.
[0305] The second path will be illustrated with an example below.
[0306] In some examples, the first path is the path where the first MAC entity is located, and the second path is the path where the second MAC entity is located. For example, the first path includes the N1 entities mentioned above, and the second path includes the N2 entities mentioned above.
[0307] In other examples, the first path corresponds to logical channel #1, which is associated with the first MAC entity; the second path corresponds to logical channel #2, which is associated with the second MAC entity. For example, the first MAC entity is a MAC-M entity, and the first path corresponds to the primary logical channel; the second MAC entity is a MAC-S entity, and the second path corresponds to the secondary logical channel. Yet another example: the first MAC entity is a MAC-S entity, and the first path corresponds to the secondary logical channel; the second MAC entity is a MAC-M entity, and the second path corresponds to the primary logical channel.
[0308] The following example illustrates how all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0309] For example, the first DSR is a DSR triggered for the first LCH. All latency-critical data buffered in the first LCH are PDCPSDU#1 and PDCP SDU#2. At this time, all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCPSDU#2. If the first device has already transmitted PDCP SDU#1 and PDCP SDU#2 to the second RLC entity through the PDCP entity, then all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0310] For example, if the first DSR is triggered for the first LCH, and all latency-critical data buffered in the first LCH are PDCPSDU#1 and PDCP SDU#2, then all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCPSDU#2. If the first device has already transmitted PDCP SDU#1 and PDCP SDU#2 to the second RLC entity through the PDCP entity, and the first device has already transmitted PDCP SDU#1 to the second MAC entity through the second RLC entity, then all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0311] For example, if the first DSR is triggered for the first LCH, and all latency-critical data buffered in the first LCH are PDCPSDU#1 and PDCP SDU#2, then all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCPSDU#2. If the first device has already transmitted PDCP SDU#1 and PDCP SDU#2 to the second RLC entity through the PDCP entity, and the first device has already transmitted PDCP SDU#1 and PDCP SDU#2 to the second MAC entity through the second RLC entity, then all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0312] This application does not limit the manner in which the first indication information indicates that all delay-critical data associated with the first DSR is transmitted to N2 entities in the first device, such as explicit or implicit indication.
[0313] Using this method, the first MAC entity of the first device can accurately determine, based on the first instruction information, that all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0314] 2. All latency-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0315] Optionally, the transmission of all latency-critical data associated with the first DSR by the second MAC entity can be replaced by at least one of the following: all latency-critical PDCP SDUs associated with the first DSR have been transmitted by the second MAC entity; all latency-critical PDCP SDUs have been transmitted by the second MAC entity; all latency-critical data associated with the first DSR have been transmitted; all latency-critical PDCP SDUs associated with the first DSR have been transmitted; or, all latency-critical PDCP SDUs have been transmitted. Optionally, the second MAC entity can be replaced by any of the following: a MAC entity in the first device other than the first MAC entity; any MAC entity; or any MAC entity in the first device. The transmission of a PDCP SDU can be understood as the PDCP SDU being sequentially subjected to the following operations: constructed into a PDCP PDU, constructed into an RLC PDU by the RLC entity, output to the second MAC entity, and transmitted by the second MAC entity.
[0316] For example, the first DSR is a DSR triggered for the first LCH. All latency-critical data buffered in the first LCH are PDCPSDU#1 and PDCP SDU#2. At this time, all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCP SDU#2. If the first device has transmitted a MACPDU including PDCP SDU#1 and PDCP SDU#2 through the second MAC entity, then all latency-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0317] This application does not limit the manner in which the first indication information indicates that all delay-critical data associated with the first DSR has been transmitted by the second MAC entity, such as explicit or implicit indication.
[0318] Using this method, the first MAC entity of the first device can accurately determine, based on the first indication information, that all latency-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0319] 3. The latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data. The first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity.
[0320] The specific content of the first part of the latency key data being transmitted to N2 entities can be found in the above description of "all latency key data associated with the first DSR being transmitted to N2 entities in the first device," except that all latency key data associated with the first DSR is replaced with the first part of the latency key data. The specific content of the second part of the latency key data being transmitted by the second MAC entity can also be found in the above description of "all latency key data associated with the first DSR being transmitted by the second MAC entity," except that all latency key data associated with the first DSR is replaced with the second part of the latency key data, and will not be repeated here.
[0321] For example, the first DSR is a DSR triggered for the first LCH. All latency-critical data buffered in the first LCH are PDCPSDU#1 and PDCP SDU#2. In this case, all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCPSDU#2. If the first device has transmitted PDCP SDU#1 to the second RLC entity through the PDCP entity, and the first device has transmitted a MAC PDU including PDCP SDU#2 through the second MAC entity, then the latency-critical data associated with the first DSR consists of a first part of latency-critical data and a second part of latency-critical data. The first part of latency-critical data is transmitted to N2 entities, and the second part of latency-critical data has been transmitted by the second MAC entity.
[0322] This application does not limit the manner in which the first indication information indicates that "the latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data, the first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity", such as explicit indication or implicit indication.
[0323] Using this method, the first MAC entity of the first device can accurately determine, according to the first indication information, that the latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data. The first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity.
[0324] 4. The second data volume is less than or equal to the second threshold.
[0325] The second data volume is the same as the first data volume, and the first data is the latency key data of the PDCP entity in the at least one latency key data.
[0326] Optionally, the second data volume is the data volume of the first data, where the first data is the latency key data of the PDCP entity among the at least one latency key data. This can be understood as: the second data volume is the data volume of the latency key data of the PDCP entity associated with the first DSR.
[0327] The second threshold can be preset, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0328] Optionally, a second threshold can be used to measure the size of the second data volume. When the second data volume is less than or equal to the second threshold, the second data volume associated with the first DSR is smaller.
[0329] Optionally, the second threshold may be greater than or equal to zero. For example, the second threshold may be zero. When the second threshold is zero, "the second data quantity is less than or equal to the second threshold" can be understood as: the second data quantity is zero; the first indication information can indicate: the second data quantity is zero. Optionally, the second threshold may be less than or equal to the first threshold.
[0330] Optionally, the second data volume being zero can be replaced by at least one of the following: the latency key data associated with the first DSR is absent in the latency key data of the PDCP entity; there is no latency key data associated with the first DSR in the latency key data of the PDCP entity; the data volume of latency key PDCP data (data) associated with the first DSR is zero; the latency key PDCP data associated with the first DSR is absent; there is no latency key PDCP data associated with the first DSR; the data volume of latency key PDCP data is zero; the latency key PDCP data is absent; there is no latency key PDCP data; or, the PDCP layer does not have latency key data associated with the first DSR. Wherein, the latency key PDCP data can be replaced by at least one of the following: a PDCP SDU associated with the first DSR, or a latency key PDCP SDU associated with the first DSR. Optionally, the delay-critical PDCP data may include: a PDCP SDU that has not been constructed as a PDCP PDU, wherein the PDCP PDU is a delay-critical SDU; and / or a lower-level PDCP data PDU that has been constructed as a PDCP PDU but has not been transmitted to the PDCP layer, wherein the PDCP data PDU includes the delay-critical PDCP SDU.
[0331] The following example illustrates the condition "the second data volume is less than or equal to the second threshold".
[0332] For example, the first DSR is a DSR triggered for the first LCH, and all latency-critical data cached in the first LCH is PDCPSDU#1. At this time, all latency-critical data associated with the first DSR is PDCP SDU#1. If the first device has transmitted PDCP SDU#1 to the second RLC entity through the PDCP entity, and / or the first device has transmitted a MAC PDU including PDCP SDU#1 through the second MAC entity, then the second data volume is less than or equal to the second threshold.
[0333] Using this method, the first MAC entity of the first device can accurately determine whether the second data volume is less than or equal to the second threshold based on the first indication information.
[0334] 5. The first data volume is less than or equal to the first threshold.
[0335] For details regarding the first data volume being less than or equal to the first threshold, please refer to the explanation of "the first data volume being less than or equal to the first threshold" in S502, which will not be repeated here.
[0336] Using this method, the first MAC entity of the first device can accurately determine whether the first data volume is less than or equal to the first threshold based on the first indication information.
[0337] In some implementations, the first indication information from the PDCP entity is transmitted under the condition that at least one of the following conditions #b1 to #b4 is met; accordingly, in S503, under the condition that at least one of the following conditions #b1 to #b4 is met, the first device can receive the first indication information from the PDCP entity through the first MAC entity.
[0338] Condition #b1: All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0339] Where N2 is a positive integer, and the N2 entities include at least one of the following: a second RLC entity or a second MAC entity. The second RLC entity is the entity between the PDCP entity and the second MAC entity.
[0340] For details regarding condition #b1, please refer to the explanation in S503 above regarding "all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device", which will not be repeated here.
[0341] Optionally, if condition #b1 is satisfied, the first indication information may be used to indicate at least one of the following: all latency-critical data associated with the first DSR is transmitted to N2 entities in the first device; the second data volume is less than or equal to the second threshold; or, the first data volume is less than or equal to the first threshold.
[0342] Condition #b2: All latency-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0343] For details on condition #b2, please refer to the explanation in S503 above regarding "all latency-critical data associated with the first DSR has been transmitted by the second MAC entity", which will not be repeated here.
[0344] Optionally, if condition #b2 is satisfied, the first indication information may be used to indicate at least one of the following: all delay-critical data associated with the first DSR has been transmitted by the second MAC entity; the second data volume is less than or equal to the second threshold; or, the first data volume is less than or equal to the first threshold.
[0345] Condition #b3: The latency critical data associated with the first DSR consists of a first part of latency critical data and a second part of latency critical data. The first part of latency critical data is transmitted to N2 entities, and the second part of latency critical data has been transmitted by the second MAC entity.
[0346] For details regarding condition #b3, please refer to the explanation in S503 above, which states that "the latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data. The first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity." It will not be repeated here.
[0347] Optionally, if condition #b3 is satisfied, the first indication information may be used to indicate at least one of the following: the latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data, the first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity; the second data volume is less than or equal to a second threshold; or, the first data volume is less than or equal to a first threshold.
[0348] Condition #b4: The second data volume is less than or equal to the second threshold.
[0349] The second data volume is the same as the first data volume, and the first data is the latency key data of the PDCP entity in at least one latency key data.
[0350] For details on condition #b4, please refer to the explanation of "the second data volume is less than or equal to the second threshold" in S503 above, and will not be repeated here.
[0351] Optionally, if condition #b4 is met, the first indication information can be used to indicate that the second data amount is less than or equal to the second threshold.
[0352] Optionally, the first indication information is transmitted when at least one of conditions #b1 to #b4 occurs; correspondingly, in S503, when at least one of conditions #b1 to #b4 is satisfied, the first device can receive the first indication information from the PDCP entity through the first MAC entity.
[0353] In this manner, the first indication information is transmitted only if at least one of conditions #b1 to #b4 is met. Thus, based on the first indication information, the first MAC entity can accurately determine that the second data volume is less than or equal to the second threshold.
[0354] In other possible designs, the first device may receive first indication information from the first RLC entity via the first MAC entity.
[0355] Optionally, the first device may receive first indication information from the first RLC entity through the first MAC entity, which can be understood as at least one of the following: the first MAC entity in the first device receives first indication information from the first RLC entity; the first device sends first indication information to the first MAC entity through the first RLC entity; or, the first RLC entity of the first device sends first indication information to the first MAC entity.
[0356] In some implementations, the first indication information from the first RLC entity can be used to indicate that the third data volume is less than or equal to a third threshold. The third data volume is the data volume of the second data, which is the latency key data of the first RLC entity among at least one latency key data. Optionally, the third data volume being the data volume of the second data, which is the latency key data of the first RLC entity among at least one latency key data, can be understood as: the second data volume being the data volume of the latency key data of the first RLC entity associated with the first DSR.
[0357] The third threshold can be pre-set, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0358] Optionally, a third threshold can be used to measure the size of the third data volume. When the third data volume is less than or equal to the third threshold, the third data volume associated with the first DSR is smaller.
[0359] Optionally, the third threshold may be greater than or equal to zero. For example, the third threshold is zero. When the third threshold is zero, the statement that the third data quantity is less than or equal to the third threshold can be replaced with: the third data quantity is zero. Optionally, the third threshold may be less than or equal to the first threshold. For example, the sum of the third threshold and the second threshold may be less than or equal to the first threshold.
[0360] Optionally, the third data volume being zero can be replaced by at least one of the following: The latency key data associated with the first DSR is absent in the latency key data of the first RLC entity; there is no latency key data associated with the first DSR in the latency key data of the first RLC entity; the data volume of the latency key data (data) associated with the first DSR is zero; the latency key data associated with the first DSR is absent; there is no latency key data associated with the first DSR; the data volume of the latency key data is zero; the latency key data is absent; there is no latency key data; or, the RLC layer corresponding to the first RLC does not have latency key data associated with the first DSR. Wherein, the latency key data can be replaced by at least one of the following: an RLCSDU or RLC SDU segment associated with the first DSR, or a latency key RLC SDU or RLC SDU segment associated with the first DSR. Optionally, the latency-critical data may include: an RLC SDU or RLC SDU segment that has not been constructed as an RLC PDU, wherein the RLC SDU is a latency-critical SDU and the RLC SDU segment is a latency-critical SDU segment; and / or, a lower-level RLC data PDU that has been constructed as an RLC PDU but has not been delivered to the RLC layer, wherein the RLC data PDU includes a latency-critical RLCSDU or RLC SDU segment.
[0361] The following example illustrates the condition "the third data volume is less than or equal to the third threshold".
[0362] For example, the first DSR is a DSR triggered for the first LCH, and all latency-critical data cached in the first LCH is PDCPSDU#1. At this time, all latency-critical data associated with the first DSR is PDCP SDU#1. If the first device has transmitted PDCP SDU#1 to the second RLC entity through the PDCP entity, and / or the first device has transmitted a MAC PDU including PDCP SDU#1 through the second MAC entity, then the third data volume is less than or equal to the third threshold.
[0363] Optionally, the first indication information from the first RLC entity may be sent when the third data volume is less than or equal to the third threshold; correspondingly, in S503, when the third data volume is less than or equal to the third threshold, the first device may receive the first indication information from the first RLC entity through the first MAC entity.
[0364] In some other possible designs, the first device may receive first indication information (referred to as first indication information #1) from the PDCP entity via the first MAC entity, and may also receive first indication information (referred to as first indication information #2) from the first RLC entity via the first MAC entity.
[0365] Specifically, the first device can receive the first indication information #1 from the PDCP entity through the first MAC entity. For details, please refer to the above description of "the first device can receive the first indication information from the PDCP entity through the first MAC entity". The first device can receive the first indication information #2 from the first RLC entity through the first MAC entity. For details, please refer to the above description of "the first device can receive the first indication information from the first RLC entity through the first MAC entity".
[0366] Optionally, the first device may also determine, based on the first indication information, that the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
[0367] In some examples, if the first device receives first indication information from a PDCP entity through a first MAC entity, the first device can determine, based on the first indication information, that the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold. Optionally, in this example, the first indication information indicates that the first data volume is less than or equal to the first threshold.
[0368] In other examples, if the first device receives first indication information #1 from the PDCP entity and first indication information #2 from the first RLC entity through the first MAC entity, the first device can determine that the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold based on the first indication information #1 and the first indication information #2, wherein the first data volume is the sum of the second data volume and the third data volume. Optionally, in this example, the first indication information #1 indicates that the second data volume is less than or equal to a second threshold, and the first indication information #2 indicates that the third data volume is less than or equal to a third threshold.
[0369] Among some possible ways, Figure 5 The method shown also includes S504:
[0370] S504: The first device sends a second instruction message to the PDCP entity through the second MAC entity.
[0371] The second indication information can be used to indicate that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity, and the second DSR is a DSR triggered by the second MAC entity.
[0372] Optionally, the first device sending the second indication information to the PDCP entity through the second MAC entity can be understood as at least one of the following: the second MAC entity in the first device sends the second indication information to the PDCP entity; the first device receives the second indication information from the second MAC entity through the PDCP entity; or, the PDCP entity in the first device receives the second indication information from the second MAC entity.
[0373] Optionally, the transmission of all latency-critical data associated with the second DSR by the second MAC entity can be replaced by at least one of the following: all latency-critical PDCP SDUs associated with the second DSR have been transmitted by the second MAC entity; or, all latency-critical PDCP SDUs have been transmitted by the second MAC entity. Optionally, the second MAC entity can be replaced by a MAC entity in the first device other than the first MAC entity.
[0374] For example, the second DSR is a DSR triggered by the second MAC entity for the second LCH. All latency-critical data buffered in the second LCH are PDCP SDU#1 and PDCP SDU#2. At this time, all latency-critical data associated with the second DSR are PDCP SDU#1 and PDCP SDU#2. If the first device has already transmitted a MAC PDU including PDCP SDU#1 and PDCP SDU#2 through the second MAC entity, then all latency-critical data associated with the second DSR has been transmitted by the second MAC entity.
[0375] In some implementations, the second indication information is transmitted under the following conditions; correspondingly, in S504, the first device can send the second indication information to the PDCP entity through the second MAC entity under the following conditions: all latency-critical data associated with the second DSR has been transmitted by the second MAC entity. The specific content regarding the transmission of all latency-critical data associated with the second DSR by the second MAC entity can be found in the above explanation of "all latency-critical data associated with the second DSR has been transmitted by the second MAC entity," and will not be repeated here.
[0376] In some implementations, the second indication information can be used to determine the first indication information in S503; correspondingly, the first device can determine the first indication information based on the second indication information. For example, the first device can determine the first indication information based on the second indication information through the PDCP entity. Optionally, the first indication information determined based on the second indication information can indicate that all delay-critical data associated with the first DSR has been transmitted by the second MAC entity.
[0377] The following example illustrates how "the first device can determine the first indication information based on the second indication information through the PDCP entity" uses the example of "the first DSR is a DSR triggered by the first MAC entity for the first LCH, and the second DSR is a DSR triggered by the second MAC entity for the second LCH". Here, the first LCH and the second LCH can be understood as the same logical channel, or they can be understood as different logical channels.
[0378] In some examples, all latency-critical data in the first LCH cache consists of PDCP SDU#1 and PDCP SDU#2, and all latency-critical data in the second LCH cache consists of PDCP SDU#1 and PDCP SDU#2. For example, if both PDCP SDU#1 and PDCP SDU#2 are cached at the PDCP layer, then the latency-critical data in both the first and second LCH caches includes PDCP SDU#1 and PDCP SDU#2. In this case, all latency-critical data associated with the first DSR consists of PDCP SDU#1 and PDCP SDU#2, and all latency-critical data associated with the second DSR consists of PDCP SDU#1 and PDCP SDU#2. If the second indication information indicates that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity, then the first device can determine that all latency-critical data associated with the first DSR has been transmitted by the second MAC entity, and thus can determine and send the first indication information through the PDCP entity.
[0379] In other examples, all data in the first LCH cache includes PDCP SDU#1 and PDCP SDU#2, and all data in the second LCH cache includes PDCP SDU#1 and PDCP SDU#2. For example, if both PDCP SDU#1 and PDCP SDU#2 are cached at the PDCP layer, then the data in both the first and second LCH caches includes PDCP SDU#1 and PDCP SDU#2. If the threshold #1 corresponding to the first MAC entity is 3ms, and the remaining time of the packet loss timer corresponding to PDCP SDU#1 is 2ms, then PDCP SDU#1 is latency-critical data associated with the first DSR. If the threshold #1 corresponding to the second MAC entity is 5ms, the remaining time of the packet loss timer corresponding to PDCP SDU#1 is 2ms, and the remaining time of the packet loss timer corresponding to PDCP SDU#2 is 4ms, then both PDCP SDU#1 and PDCP SDU#2 are latency-critical data associated with the second DSR. If the second indication information indicates that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity, the first device can determine that all latency-critical data associated with the first DSR has been transmitted by the second MAC entity, and thus can determine and send the first indication information through the PDCP entity.
[0380] Optionally, S504 may precede S503. The order of S504 and S501 is not limited in this application.
[0381] In this way, the first device can accurately determine, based on the second instruction information, that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity.
[0382] Among the possible implementations, S502 can have multiple implementations, such as at least one of implementations b1 to b3, that is, implementations b1 to b3 can be combined with each other.
[0383] Method b1: The first data volume is less than or equal to the first threshold in the following cases; correspondingly, the first device can determine that the first data volume is less than or equal to the first threshold and cancel the first DSR in the following cases, or the first MAC entity in the first device can determine that the first data volume is less than or equal to the first threshold and cancel the first DSR in the following cases: the first device receives the first indication information from the PDCP entity through the first MAC entity (see S503 above), and the third data volume is less than or equal to the third threshold.
[0384] The first data volume is the sum of the second and third data volumes. The second data volume is the data volume of the first data, which is the latency key data of the PDCP entity in at least one latency key data. For the specific content of the second data volume, please refer to the description of the second data volume in S503; for the specific content of the third data volume being less than or equal to the third threshold, please refer to the description of the third data volume being less than or equal to the third threshold in S503, and will not be repeated here.
[0385] Optionally, in method b1, Figure 5 The method shown may include S503 as described above. Optionally, in mode b1, Figure 5 The method shown may include S504 mentioned above.
[0386] Through this method b1, the first device (e.g., the first MAC entity in the first device) can accurately determine that the first data volume is less than or equal to the first threshold based on the first indication information and the third data volume, thereby canceling the first DSR. This avoids the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking DSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0387] Method b2: At the first moment, if the amount of the first data to be transmitted by the first MAC entity is less than or equal to the first threshold, the first device may cancel the first DSR.
[0388] In some implementations, the first time can be related to the transmission time of the MAC CE (hereinafter referred to as the first MAC CE) corresponding to the first DSR. For example, the first time can be the transmission time of the first MAC CE, or the time before or after that transmission time. Optionally, the first device can encapsulate the first MAC CE into a MAC PDU and map the MAC PDU onto a PUSCH; the transmission time of the first MAC CE can be the transmission time of the PUSCH at the physical layer.
[0389] In other implementations, the first timeframe can be the time after the first DSR is triggered, during which there are transmission resources available for the first MAC entity. For example, the first timeframe could be... Figure 6D The T3 time in the middle.
[0390] In some implementations, the "first time" can be the time when the first device receives the first indication information through the first MAC entity, or the time after the first device receives the first indication information through the first MAC entity. The specific content of the first indication information can be found in the description of the first indication information in S503, and will not be repeated here. Optionally, in this implementation, the first device can cancel the first DSR after receiving the first indication information; or, method b2 can be replaced by: the first device can cancel the first DSR upon receiving the first indication information. For example, if the first device receives the first indication information from the PDCP entity through the first MAC entity, the first device can cancel the first DSR after receiving the first indication information. Another example is if the first device receives the first indication information from the first RLC entity through the first MAC entity, the first device can cancel the first DSR after receiving the first indication information. Yet another example is if the first device receives first indication information #1 from the PDCP entity through the first MAC entity and first indication information #2 from the first RLC entity through the first MAC entity, the first device can cancel the first DSR after receiving both first indication information #1 and first indication information #2.
[0391] In other implementations, the first time may be the time when the first device transmits a MAC PDU (hereinafter referred to as the first MACPDU) through the second MAC entity. Optionally, the first MAC PDU includes latency-critical data. Exemplarily, the first MAC PDU may include latency-critical data associated with the first DSR. For example, the first MAC PDU may include all latency-critical data associated with the first DSR.
[0392] It should be understood that the above implementation is only an example, and it can also be implemented at other times.
[0393] Among some possible approaches, approach b2 may include: at a first time, if a first condition is met, the first device may cancel the first DSR. Wherein, if the first condition is met, the first data volume may be less than or equal to a first threshold.
[0394] Optionally, the first condition may include at least one of the following conditions #c1 to #c5:
[0395] Condition #c1: All latency-critical data associated with the first DSR has been transmitted by any MAC entity.
[0396] Optionally, the statement that all latency-critical data associated with the first DSR has been transmitted by any MAC entity can be replaced by at least one of the following: all latency-critical PDCP SDUs have been transmitted by any MAC entity; all PDCP SDUs have been transmitted by any MAC entity; latency-critical PDCP SDUs do not exist; or, there are no latency-critical PDCP SDUs. For example, the statement that all latency-critical data associated with the first DSR has been transmitted by any MAC entity includes: all latency-critical PDCPSDUs associated with the first DSR have been transmitted by any MAC entity. For instance, a first MAC PDU is transmitted by any MAC entity, and this first MAC PDU includes all latency-critical PDCP SDUs associated with the first DSR.
[0397] Optionally, the MAC entity can be any MAC entity in the first device. Optionally, the MAC entity can be replaced by a MAC entity in the first device other than the first MAC entity (e.g., a second MAC entity).
[0398] For example, if the first DSR is a DSR triggered for the first LCH, and all latency-critical data buffered in the first LCH are: PDCPSDU#1 and PDCP SDU#2, then all latency-critical data associated with the first DSR are: PDCP SDU#1 and PDCPSDU#2. If the first device has transmitted a MAC PDU including PDCP SDU#1 and PDCP SDU#2 through the second MAC entity, then condition #c1 is satisfied.
[0399] For example, if the first DSR is a DSR triggered for the first LCH, and all latency-critical data cached in the first LCH are PDCPSDU#1 and PDCP SDU#2, then all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCPSDU#2. If the first device has transmitted a MAC PDU including PDCP SDU#1 through the first MAC entity, and the first device has transmitted a MAC PDU including PDCP SDU#2 through the second MAC entity, then condition #c1 is satisfied.
[0400] Optionally, the latency-critical data associated with the first DSR can be understood as at least one of the following: a piece of data that is not transmitted in any MAC PDU and is latency-critical data associated with the LCH that triggered the first DSR; a piece of data that is not transmitted by any MAC entity and is latency-critical data associated with the LCH that triggered the first DSR; or, a piece of data that is not transmitted by any MAC entity in any MAC PDU and is latency-critical data associated with the LCH that triggered the first DSR. The data may be, for example, a PDCP SDU.
[0401] In some examples, the LCH that triggers the first DSR is the first LCH. All data cached in the first LCH is: PDCPSDU#1.
[0402] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity, the first device triggers the first DSR corresponding to the first MAC entity and the second DSR corresponding to the second MAC entity.
[0403] At time T2, if the second MAC entity has transmission resources, the second MAC entity sends a MACPDU including PDCP SDU#1 and cancels the second DSR.
[0404] At time T3, for example, after time T2, since PDCP SDU#1 has been transmitted by the second MAC entity, PDCP SDU#1 is not a latency-critical data associated with the first DSR. Because there is no latency-critical data associated with the first DSR, the first MAC entity can cancel the first DSR. Here, time T3 can be the time when the first MAC entity has transmission resources, or the time when the first MAC entity receives the third indication information from the second MAC entity. The specific content of the third indication information can be found in method b3 and will not be repeated here.
[0405] In other examples, the LCH that triggers the first DSR is the first LCH. All data cached in the first LCH is: PDCPSDU#1 and PDCP SDU#2.
[0406] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity, the first device triggers the first DSR corresponding to the first MAC entity and the second DSR#1 corresponding to the second MAC entity.
[0407] At time T2, if the second MAC entity has transmission resources, the second MAC entity sends a MACPDU including PDCP SDU#1 and cancels the second DSR#1.
[0408] At time T3, the remaining time of the packet loss timer corresponding to PDCP SDU#2 is less than or equal to the threshold #1 corresponding to the first MAC entity. Optionally, since the first MAC entity has a pending first DSR, the first MAC entity may no longer trigger a DSR. Optionally, since the second MAC entity does not have a pending DSR, that is, the second DSR#1 has been canceled, the first device may still trigger the second DSR#2 corresponding to the second MAC entity.
[0409] At time T4, if the first MAC entity has transmission resources, it can send a DSR MAC CE including delay information for PDCP SDU#2. If time T4 is after time T2, since PDCP SDU#1 has already been transmitted by the second MAC entity, PDCP SDU#1 is not the delay-critical data associated with the first DSR. All data associated with the first DSR is PDCP SDU#2. Since the first MAC entity has already sent a DSR MAC CE including delay information for PDCP SDU#2, it can cancel the first DSR.
[0410] Condition #c2: In the first MAC CE, the delay information corresponding to the first DSR is zero.
[0411] Optionally, the delay information corresponding to the first DSR is zero, which can be understood as: the first DSR is a DSR triggered for the first LCH, and the delay information corresponding to the first LCH is zero.
[0412] In some implementations, the latency information corresponding to the first DSR includes: the data volume information corresponding to the first DSR, and / or, the remaining time information corresponding to the first DSR. The specific content of the data volume information and the remaining time information can be found in the explanation of data volume information and remaining time information above; repetitions will not be repeated. Optionally, the data volume information corresponding to the first DSR can be understood as follows: the first DSR is a DSR triggered for the first LCH, and the data volume information of the first LCH is zero; the remaining time information corresponding to the first DSR can be understood as follows: the first DSR is a DSR triggered for the first LCH, and the remaining time information of the first LCH is zero.
[0413] For example, in the first MAC CE, when the data volume information in the delay information corresponding to the first DSR is zero, condition #c2 is satisfied.
[0414] For example, in the first MAC CE, when the remaining time information in the delay information corresponding to the first DSR is zero, condition #c2 is satisfied.
[0415] For example, in the first MAC CE, when both the data volume information and the remaining time information in the delay information corresponding to the first DSR are zero, condition #c2 is satisfied.
[0416] Condition #c3: All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device.
[0417] Condition #c4: The latency critical data associated with the first DSR consists of a first part of latency critical data and a second part of latency critical data. The first part of latency critical data is transmitted to N2 entities, and the second part of latency critical data has been transmitted by any MAC entity.
[0418] For details on conditions #c3 and #c4, please refer to the explanation of conditions #b1 and #b3 above. The only difference is that the second MAC entity is replaced with any MAC entity, which will not be repeated here.
[0419] Condition #c5: The first device does not receive the seventh indication information corresponding to the delay key data associated with the first DSR through the first MAC entity; and / or, the second data volume is less than or equal to the second threshold.
[0420] For example, the seventh indication information can be used to indicate at least one of the following: the latency-critical data associated with the first DSR is latency-critical data; or, latency-critical data exists in the data cached by the first LCH, and the data cached by the first LCH includes the latency-critical data associated with the first DSR. As another example, the seventh indication information can be a latency-critical indication. The seventh indication information can be sent by the first device to the first RLC entity and / or the first MAC entity via the PDCP entity.
[0421] The second data volume is the same as the first data volume, and the first data volume is the latency key data of the PDCP entity among the at least one latency key data. For details regarding whether the second data volume is less than or equal to the second threshold, please refer to the explanation of "the second data volume is less than or equal to the second threshold" in S503, which will not be repeated here.
[0422] The following example illustrates condition #c5, using the first latency-critical data cached in the PDCP layer that triggered the first DSR and the second DSR.
[0423] In some examples, if all latency-critical data associated with the first DSR includes the first latency-critical data, and the PDCP entity transmits the first latency-critical data to the second RLC entity, then the PDCP entity may send a seventh indication message to the second RLC entity and / or the second MAC entity. Since the first latency-critical data was not transmitted to the first RLC entity, the PDCP entity does not send the seventh indication message to the first RLC entity and / or the first MAC entity. Since the first latency-critical data has been transmitted to the second RLC entity, the second data volume is less than or equal to the second threshold. In this case, condition #c5 is satisfied.
[0424] In other examples, if all latency-critical data associated with the first DSR includes first latency-critical data and second latency-critical data, and the PDCP entity transmits the first latency-critical data and second latency-critical data to the second RLC entity, then the PDCP entity may send a seventh indication message to the second RLC entity and / or the second MAC entity. Since the first latency-critical data and second latency-critical data were not transmitted to the first RLC entity, the PDCP entity does not send the seventh indication message to the first RLC entity and / or the first MAC entity. Since the first latency-critical data and second latency-critical data have been transmitted to the second RLC entity, the second data volume is less than or equal to the second threshold. In this case, condition #c5 is satisfied.
[0425] The following is combined with Figure 6D Here is an example illustrating method b2.
[0426] At time T0, PDCP SDU#1 is cached in the PDCP layer. In some examples, the current total data volume is greater than or equal to threshold #3. For details regarding "the current total data volume is greater than or equal to threshold #3," please refer to the explanation of condition #a2 in S501, which will not be repeated here. In other examples, the current total data volume is less than threshold #3. For details regarding the total data volume and threshold #3, please refer to the explanations of the terms above, which will not be repeated here.
[0427] At time T1, if the remaining time of the packet loss timer corresponding to PDCP SDU#1 is less than or equal to the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity, the first device triggers the first DSR corresponding to the first MAC entity and the second DSR corresponding to the second MAC entity.
[0428] At time T2, the first data volume to be transmitted by the first MAC entity is zero. For example, at time T2, if all latency-critical data associated with the first DSR in the first device is PDCP SDU#1, and the second MAC entity transmits MAC PDU#1, where MAC PDU#1 contains PDCP SDU#1, then the first data volume to be transmitted by the first MAC entity is zero. The following example illustrates "the second MAC entity transmitting MAC PDU#1". For instance, at time T2, if the second MAC entity has transmission resources, it can transmit MAC PDU#1 including PDCP SDU#1. For example, the PDCP entity can transmit this PDCP SDU#1 to the second RLC entity, and the second RLC entity can transmit PDCP SDU#1 to the second MAC entity. Thus, the second MAC entity can transmit MAC PDU#1 including PDCP SDU#1 and cancel the second DSR.
[0429] At time T3, the first MAC entity has transmission resources. If the first MAC entity determines that the first condition is met, then the first MAC entity may cancel the first DSR.
[0430] It should be understood that the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity may be the same or different. For example, the threshold #1 corresponding to the first MAC entity is equal to the threshold #1 corresponding to the second MAC entity; the threshold #1 corresponding to the first MAC entity is greater than the threshold #1 corresponding to the second MAC entity; or the threshold #1 corresponding to the first MAC entity is less than the threshold #1 corresponding to the second MAC entity. The above example illustrates that the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity are the same. For the specific content of the threshold #1 corresponding to the first MAC entity, please refer to the explanation of "threshold #1 corresponding to the first MAC entity" in method a1; for the specific content of the threshold #1 corresponding to the second MAC entity, please refer to the explanation of "threshold #1 corresponding to the first MAC entity" in method a1, only the first MAC entity is replaced with the second MAC entity, and will not be repeated here. Regarding whether the threshold #1 corresponding to the first MAC entity and the threshold #1 corresponding to the second MAC entity are the same, please refer to the description in S502, and will not be repeated here.
[0431] In this method b2, if the first condition is met at the first time, the first device (e.g., the first MAC entity in the first device) can cancel the first DSR, thereby avoiding the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking the DSR that cannot be canceled and is yet to be transmitted, and reducing the power consumption of the first device.
[0432] In some implementations, in method b2, the first device may send the first MAC CE before canceling the first DSR. Optionally, if the first time is a time after the time when the first MAC CE was sent, the first device may send the first MAC CE before canceling the first DSR. For example, if the first time is a time after the time when the first MAC CE was sent, the first device may send the first MAC CE first. If the first condition is met at the first time, the first device may cancel the first DSR.
[0433] In other implementations, in method b2, if the first condition is met, and / or after canceling the first DSR, the first device may determine not to send the first MAC CE. Optionally, if the first condition is met, and / or after canceling the first DSR, the first device may determine not to send the first MAC CE if the first time is the transmission time of the first MAC CE, or a time prior to the transmission time. For example, the first MAC CE may indicate the delay information of each LCG in one or more LCGs, each LCG including one or more LCHs. If the delay information corresponding to each LCG is 0, for example, if the delay information of one or more LCHs included in each LCG is 0, then the first device may determine not to send the first MAC CE. Through this implementation, if the first condition is met, and / or after canceling the first DSR, the first device may determine not to send the first MAC CE, thereby avoiding unnecessary transmission of the first MAC CE and preventing waste of transmission resources.
[0434] Optionally, method b2 (or S502) can be replaced by: if the first condition is met, then the first device may cancel the first DSR. For details regarding "if the first condition is met, then the first device may cancel the first DSR," please refer to method b2, which will not be repeated here.
[0435] Method b3: The first device sends third indication information to the first MAC entity through the second MAC entity. Accordingly, S502 may include: the first device cancels the first DSR if the first data volume is less than or equal to the first threshold according to the third indication information.
[0436] The third indication information can be used to indicate that the first delay key data associated with the second DSR is transmitted by the second MAC entity, and the second DSR is a DSR triggered by the second MAC entity. For the specific content of the third indication information, please refer to the description of the second indication information in S504, except that the second indication information is replaced by the third indication information and all delay key data is replaced by the first delay key data, which will not be repeated here.
[0437] Optionally, the first device sending third indication information to the first MAC entity through the second MAC entity can be understood as at least one of the following: the second MAC entity in the first device sending third indication information to the first MAC entity; the first device receiving third indication information from the second MAC entity through the first MAC entity; or, the first MAC entity in the first device receiving third indication information from the second MAC entity.
[0438] In some implementations, the third indication information can be used to determine whether the first data volume is less than or equal to the first threshold; correspondingly, the first device can determine whether the first data volume is less than or equal to the first threshold based on the third indication information.
[0439] The following example illustrates how "the first device can determine whether the first data volume is less than or equal to the first threshold based on the third indication information," using the example that "the first DSR is a DSR triggered by the first MAC entity against the first LCH, and the second DSR is a DSR triggered by the second MAC entity against the second LCH." Here, the first LCH and the second LCH can be understood as the same logical channel, or they can be understood as different logical channels.
[0440] In some examples, all latency-critical data in the first LCH cache is PDCP SDU#1, and all latency-critical data in the second LCH cache is PDCP SDU#1. For example, if PDCP SDU#1 is cached at the PDCP layer, then all latency-critical data in both the first and second LCH caches includes PDCP SDU#1. In this case, PDCP SDU#1 represents all latency-critical data associated with the first DSR and all latency-critical data associated with the second DSR. If the third indication information indicates that PDCP SDU#1 associated with the second DSR has been transmitted by the second MAC entity, the first device can determine whether the first data volume is less than or equal to the first threshold.
[0441] In other examples, all latency-critical data in the first LCH cache are PDCP SDU#1 and PDCP SDU#2, and all latency-critical data in the second LCH cache are PDCP SDU#1 and PDCP SDU#2. For example, if both PDCP SDU#1 and PDCP SDU#2 are cached at the PDCP layer, then the latency-critical data in both the first and second LCH caches includes PDCP SDU#1 and PDCP SDU#2. In this case, all latency-critical data associated with the first DSR are PDCP SDU#1 and PDCP SDU#2, and all latency-critical data associated with the second DSR are PDCP SDU#1 and PDCP SDU#2. If third indication information #1 indicates that PDCP SDU#1 associated with the second DSR has been transmitted by the second MAC entity, and third indication information #2 indicates that PDCP SDU#2 associated with the second DSR has been transmitted by the second MAC entity, then the first device can determine whether the first data volume is less than or equal to the first threshold.
[0442] In this method b3, the first device sends a third indication message to the first MAC entity through the second MAC entity. The third indication message can be used to indicate that the first latency-critical data associated with the second DSR is transmitted by the second MAC entity. In this way, the first device (e.g., the first MAC entity in the first device) can accurately determine whether the first data volume is less than or equal to the first threshold based on the third indication message, thereby canceling the first DSR. This avoids the first device being unable to cancel the first DSR when the latency-critical data associated with the first DSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking DSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0443] Optionally, Figure 5 The method shown may also include only "the first device sends third indication information to the first MAC entity through the second MAC entity" in mode b3, without including the other features in mode b3.
[0444] Among some possible ways, Figure 5 The method shown also includes S505:
[0445] S505: The second device sends the first configuration information; correspondingly, the first device receives the first configuration information.
[0446] The first configuration information is used to indicate that the first DSR should be cancelled when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold. This application does not limit the specific indication method; for example, it can be explicit or implicit. The specific content of "the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold" can be found in the explanation of "the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold" in S502, and will not be repeated here. For example, when the first threshold is zero, the first configuration information is used to indicate that the first DSR should be cancelled when the first amount of data to be transmitted by the first MAC entity is zero. The specific content of "the first amount of data to be transmitted by the first MAC entity is zero" can be found in the explanation of "the first amount of data to be transmitted by the first MAC entity is zero" in S502, and will not be repeated here.
[0447] The initial configuration information can be carried in a traditional message or in a new message, without restriction. For example, the initial configuration information can be carried in a DCI, MAC CE, or RRC message.
[0448] The first configuration information may have other names, such as cancellation configuration information, instruction information, or cancellation instruction information, without restriction.
[0449] Optionally, S505 precedes some or all of the steps in S502 to S504; the order between S505 and S501 is not limited in this application.
[0450] In this method, the first device can cancel the first DSR if the amount of first data to be transmitted by the first MAC entity is less than or equal to a first threshold, based on the first configuration information. Furthermore, in this method, the first configuration information is sent from the second device to the first device, allowing the second device to flexibly configure or instruct the operations of the first device.
[0451] Among some possible ways, Figure 5 The method shown also includes S506:
[0452] S506: The first device sends first capability information; correspondingly, the second device receives the first capability information.
[0453] The first capability information can be used to indicate that the first device has the ability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold. This application does not limit the specific indication method; for example, it can be explicit or implicit. The specific content of "the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold" can be found in the explanation of "the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold" in S502, and will not be repeated here. For example, when the first threshold is zero, the first capability information can be used to indicate that the first device has the ability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is zero. The specific content of "the first amount of data to be transmitted by the first MAC entity is zero" can be found in the explanation of "the first amount of data to be transmitted by the first MAC entity is zero" in S502, and will not be repeated here.
[0454] Optionally, the first capability information can be used to indicate that the first device has the ability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold. This can be understood as: the first capability information can be used to indicate that the first device can cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold.
[0455] Optionally, the first capability information can be used to determine (or trigger) the first configuration information. For example, after receiving the first capability information, the second device can determine the first configuration information and send the first configuration information to the first device.
[0456] First capability information can be carried in traditional messages or in new messages, without restriction. For example, first capability information can be carried in UCI, MAC CE, or RRC messages.
[0457] The primary capability information may have other names, such as capability indication information, and there are no restrictions.
[0458] Optionally, S506 may precede S505; the order between S506 and S501 is not limited in this application.
[0459] In this way, the first device can accurately report to the second device, through the first capability information, that the first device has the capability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold. In this way, the second device can determine a configuration for the first device that is appropriate to its capabilities.
[0460] Figure 7 This is a flowchart illustrating a communication method provided in an embodiment of this application. Figure 7 As shown, the method may include:
[0461] S701: When the second condition is met, the first device triggers the first DSR corresponding to the first MAC entity. The second condition includes: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0462] Optionally, the first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. For details regarding the first device, please refer to the description of the first device in S501, which will not be repeated here.
[0463] For details on S701, please refer to the description of mode a2 in S501, which will not be repeated here.
[0464] Among some possible ways, Figure 7 The method shown also includes S702:
[0465] S702: The second device sends the second configuration information; correspondingly, the first device receives the second configuration information.
[0466] The second configuration information is used to instruct the first device to trigger the first DSR when the second condition is met.
[0467] For details on S702, please refer to [link / reference]. Figure 5 Step A1 in the method shown will not be repeated.
[0468] Among some possible ways, Figure 7 The method shown also includes S703:
[0469] S703: The first device sends the second capability information; correspondingly, the second device receives the second capability information.
[0470] The second capability information is used to indicate that the first device has the capability to trigger the first DSR when the second condition is met.
[0471] For details on S703, please refer to Figure 5 Step B1 in the method shown will not be repeated.
[0472] Figure 7 The technical effects of the method shown can be referenced. Figure 5 The explanation of the technical effects of the method shown will not be repeated here.
[0473] Figure 8 This is a flowchart illustrating a communication method provided in an embodiment of this application. Figure 8 As shown, the method may include:
[0474] S801: The first device triggers the first BSR corresponding to the first MAC entity.
[0475] The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. For details of the first device, please refer to the description of the first device in S501, which will not be repeated here.
[0476] This application does not restrict the way in which the first device triggers the first BSR; for example, it may adopt the method specified in the protocol.
[0477] S802: If the amount of fourth data to be transmitted by the first MAC entity is less than or equal to the fourth threshold, the first device may cancel the first BSR.
[0478] The fourth data volume refers to the total data volume of at least one data associated with the first BSR (e.g., cached data, uplink data available for transmission in the LCH, or data cached in the LCH). The at least one data volume includes data from N1 entities, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity. The specific content of the first RLC entity can be found in the description of the first RLC entity in method a1 of S501 above, and will not be repeated here.
[0479] Optionally, the data of a PDCP entity may include at least one of the following: a PDCPSDU that has not been constructed as a PDCP data PDU, a lower-level PDCP data PDU that contains a PDCP SDU and has not yet been delivered to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted.
[0480] Optionally, the data of the first RLC entity may include at least one of the following: an RLCSDU or RLCSDU segment not constructed as an RLC data PDU, an RLC data PDU to be initially transmitted containing an RLC SDU or RLC SDU segment, an RLC data PDU to be retransmitted, or an RLC status report. Here, an RLC SDU or RLC SDU segment not constructed as an RLC data PDU can be understood as an RLC SDU or RLC SDU segment not included in the RLC data PDU.
[0481] Optionally, when the at least one data is a single data, the fourth data quantity is the data quantity of that single data; when the at least one data is multiple data, the fourth data quantity is the sum of the data quantities of the multiple data.
[0482] The fourth threshold can be preset, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0483] Optionally, a fourth threshold can be used to measure the size of the fourth data volume. When the fourth data volume is less than or equal to the fourth threshold, the fourth data volume associated with the first BSR is small, and the first device can cancel the first BSR.
[0484] Optionally, the fourth threshold may be greater than or equal to zero. For example, the fourth threshold may be zero. When the fourth threshold is zero, S802 can be understood as follows: if the amount of fourth data to be transmitted by the first MAC entity is zero, the first device may cancel the first BSR.
[0485] Optionally, the fourth data quantity to be transmitted by the first MAC entity being zero can be replaced by at least one of the following: at least one data quantity to be transmitted by the first MAC entity does not exist, and the at least one data quantity associated with the first BSR does not exist; at least one data quantity to be transmitted by the first MAC entity associated with the first BSR does not exist; there is no at least one data quantity to be transmitted by the first MAC entity associated with the first BSR; there is no data quantity to be transmitted by the first MAC entity associated with the first BSR; the data associated with the first BSR (e.g., PDCP SDU) becomes unavailable for transmission; or, the data associated with the first BSR (e.g., PDCP SDU) is unavailable for transmission.
[0486] Optionally, the cancellation of the first BSR by the first device can also be understood as: the first MAC entity in the first device cancels the first BSR, or the first device cancels the first BSR through the first MAC entity.
[0487] In some possible scenarios, data is transmitted by the second MAC entity. For details regarding the specifics of data transmission by the second MAC entity, refer to the description of "sometimes latency-critical data is transmitted by the second MAC entity" in S502, only replacing "latency-critical data" with "data". Figure 5 Replace with Figure 8 S502 is replaced by S802, and DSR is replaced by BSR, which will not be elaborated further.
[0488] pass Figure 8The method described allows the first device to cancel the first BSR corresponding to the first MAC entity when the fourth data volume is less than or equal to a fourth threshold. Here, the fourth data volume is the total data volume of at least one data associated with the first BSR. This method avoids situations where the first device cannot cancel the first BSR when data associated with it is transmitted by a MAC entity other than the first MAC entity. This prevents the first device from continuously marking uncancellable BSRs awaiting transmission, thereby reducing the power consumption of the first device.
[0489] Among some possible ways, Figure 8 The method shown also includes S803:
[0490] S803: The first device can receive the fourth instruction information through the first MAC entity.
[0491] Accordingly, S802 may include: the first device cancels the first BSR if the fourth amount of data to be transmitted by the first MAC entity is less than or equal to the fourth threshold, based on the fourth indication information.
[0492] In some possible designs, the first device may receive fourth indication information from the PDCP entity via the first MAC entity.
[0493] Optionally, the first device may receive fourth indication information from the PDCP entity through the first MAC entity, which can be understood as at least one of the following: the first MAC entity in the first device receives fourth indication information from the PDCP entity; the first device sends fourth indication information to the first MAC entity through the PDCP entity; or, the PDCP entity of the first device sends fourth indication information to the first MAC entity.
[0494] In some implementations, the fourth indication information from the PDCP entity can be used to indicate at least one of the following: all data associated with the first BSR has been transmitted to N2 entities in the first device; all data associated with the first BSR has been transmitted by the second MAC entity; the data associated with the first BSR consists of a first part of data and a second part of data, the first part of data has been transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity; the fifth data volume is less than or equal to a fifth threshold; or, the fourth data volume is less than or equal to a fourth threshold. These will be explained below.
[0495] 1. All data associated with the first BSR is transmitted to N2 entities in the first device.
[0496] For details on how all data associated with the first BSR is transmitted to the N2 entities in the first device, please refer to the description in S503 of "all latency-critical data associated with the first DSR is transmitted to the N2 entities in the first device", except that latency-critical data is replaced with data and DSR is replaced with BSR, and will not be repeated here.
[0497] 2. All data associated with the first BSR has been transmitted by the second MAC entity.
[0498] For details on the transmission of all data associated with the first BSR by the second MAC entity, please refer to the explanation in S503 that "all latency-critical data associated with the first DSR has been transmitted by the second MAC entity," except that latency-critical data is replaced with data and DSR is replaced with BSR, which will not be repeated here.
[0499] 3. The data associated with the first BSR consists of a first part of data and a second part of data. The first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity.
[0500] The specific content of "the data associated with the first BSR consists of a first part of data and a second part of data. The first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity" can be found in S503, which explains that "the latency key data associated with the first DSR consists of a first part of latency key data and a second part of latency key data. The first part of latency key data is transmitted to N2 entities, and the second part of latency key data has been transmitted by the second MAC entity." The only difference is that the latency key data is replaced with data, and the DSR is replaced with BSR. This will not be repeated here.
[0501] 4. The fifth data volume is less than or equal to the fifth threshold.
[0502] The fifth data volume is the data volume of the third data, and the third data is the data of the PDCP entity in the at least one data.
[0503] Optionally, the fifth data volume is the data volume of the third data, which is the data of the PDCP entity in the at least one data. It can be understood as: the fifth data volume is the data volume of the data associated with the first BSR in the data of the PDCP entity.
[0504] The fifth threshold can be preset, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0505] Optionally, a fifth threshold can be used to measure the size of the fifth data volume. When the fifth data volume is less than or equal to the fifth threshold, the fifth data volume associated with the first BSR is smaller.
[0506] Optionally, the fifth threshold may be greater than or equal to zero. For example, the fifth threshold may be zero. When the fifth threshold is zero, the fourth indication information may indicate that the fifth data quantity is zero. Optionally, the fifth threshold may be less than or equal to the fourth threshold.
[0507] Optionally, the fifth data volume being zero can be replaced by at least one of the following: no data associated with the first BSR exists in the PDCP entity data; no data associated with the first BSR exists in the PDCP entity data; the amount of PDCP data associated with the first BSR is zero; no PDCP data associated with the first BSR exists; no PDCP data associated with the first BSR exists; the amount of PDCP data is zero; no PDCP data exists; no PDCP data exists; or, the PDCP layer does not have data associated with the first BSR. Wherein, PDCP data can be replaced by: PDCP SDU associated with the first BSR. Optionally, PDCP data may include: PDCP SDU not constructed as a PDCPPDU; and / or, lower-layer PDCP data PDU that has been constructed as a PDCP PDU but not transmitted to the PDCP layer.
[0508] The following example illustrates the condition "the fifth data volume is less than or equal to the fifth threshold".
[0509] For example, the first BSR is a BSR triggered for the first LCH, and the data cached in the first LCH includes PDCP SDU#1. In this case, PDCP SDU#1 is the data associated with the first BSR. If the first device has transmitted PDCP SDU#1 to the second RLC entity through the PDCP entity, and / or the first device has transmitted a MAC PDU including PDCP SDU#1 through the second MAC entity, then the fifth data volume is less than or equal to the fifth threshold.
[0510] Using this method, the first MAC entity of the first device can accurately determine whether the fifth data volume is less than or equal to the fifth threshold based on the fourth indication information.
[0511] 5. The fourth data volume is less than or equal to the fourth threshold.
[0512] For details regarding the fourth data quantity being less than or equal to the fourth threshold, please refer to the explanation of "the fourth data quantity being less than or equal to the fourth threshold" in S802, which will not be repeated here.
[0513] Using this method, the first MAC entity of the first device can accurately determine whether the fourth data volume is less than or equal to the fourth threshold based on the fourth indication information.
[0514] In some implementations, the fourth indication information from the PDCP entity is transmitted under the condition that at least one of the following conditions #d1 to #d4 is met; accordingly, in S803, under the condition that at least one of the following conditions #d1 to #d4 is met, the first device can receive the fourth indication information from the PDCP entity through the first MAC entity.
[0515] Condition #d1: All data associated with the first BSR is transmitted to N2 entities in the first device.
[0516] For details on condition #d1, please refer to the explanation in S803 above regarding "all data associated with the first BSR is transmitted to N2 entities in the first device", which will not be repeated here.
[0517] Optionally, if condition #d1 is satisfied, the fourth indication information may be used to indicate at least one of the following: all data associated with the first BSR is transmitted to N2 entities in the first device; the fifth data volume is less than or equal to the fifth threshold; or, the fourth data volume is less than or equal to the fourth threshold.
[0518] Condition #d2: All data associated with the first BSR has been transmitted by the second MAC entity.
[0519] For details on condition #d2, please refer to the explanation of "all data associated with the first BSR has been transmitted by the second MAC entity" in S803 above, and will not be repeated here.
[0520] Optionally, if condition #d2 is satisfied, the fourth indication information may be used to indicate at least one of the following: all data associated with the first BSR has been transmitted by the second MAC entity; the fifth data volume is less than or equal to the fifth threshold; or, the fourth data volume is less than or equal to the fourth threshold.
[0521] Condition #d3: The data associated with the first BSR consists of a first part of data and a second part of data. The first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity.
[0522] For details on condition #d3, please refer to the explanation in S803 above regarding "the data associated with the first BSR consists of a first part of data and a second part of data. The first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity". It will not be repeated here.
[0523] Optionally, if condition #d3 is satisfied, the fourth indication information may be used to indicate at least one of the following: the data associated with the first BSR consists of a first part of data and a second part of data, the first part of data is transmitted to N2 entities, and the second part of data has been transmitted by the second MAC entity; the fifth data volume is less than or equal to the fifth threshold; or, the fourth data volume is less than or equal to the fourth threshold.
[0524] Condition #d4: The fifth data volume is less than or equal to the fifth threshold.
[0525] For details on condition #d4, please refer to the explanation of "the fifth data volume is less than or equal to the fifth threshold" in S803 above, and will not be repeated here.
[0526] Optionally, if condition #d4 is met, the fourth indication information can be used to indicate that the fifth data quantity is less than or equal to the fifth threshold.
[0527] Optionally, the fourth indication information is transmitted when at least one of conditions #d1 to #d4 occurs; correspondingly, in S803, when at least one of conditions #d1 to #d4 is satisfied, the first device can receive the fourth indication information from the PDCP entity through the first MAC entity.
[0528] In this manner, the fourth indication information is transmitted only if at least one of conditions #d1 to #d4 is met. Thus, based on the fourth indication information, the first MAC entity can accurately determine that the fifth data volume is less than or equal to the second threshold.
[0529] In some other possible designs, the first device may receive fourth indication information from the first RLC entity via the first MAC entity.
[0530] Optionally, the first device may receive fourth indication information from the first RLC entity through the first MAC entity, which can be understood as at least one of the following: the first MAC entity in the first device receives fourth indication information from the first RLC entity; the first device sends fourth indication information to the first MAC entity through the first RLC entity; or, the first RLC entity of the first device sends fourth indication information to the first MAC entity.
[0531] In some implementations, the fourth indication information from the first RLC entity can be used to indicate that the sixth data quantity is less than or equal to the sixth threshold. This will be explained below. The sixth data quantity is the data quantity of the fourth data, which is the data of the first RLC entity among at least one set of data. Optionally, the sixth data quantity being the data quantity of the fourth data, which is the data of the first RLC entity among at least one set of data, can be understood as: the fourth data quantity is the data quantity of the data associated with the first BSR within the data of the first RLC entity.
[0532] The sixth threshold can be preset, such as as specified in the protocol; or it can be notified to the first device by other devices (such as the second device or the core network device); or it can be determined by the first device.
[0533] Optionally, a sixth threshold can be used to measure the size of the sixth data volume. When the sixth data volume is less than or equal to the sixth threshold, the sixth data volume associated with the first BSR is smaller.
[0534] Optionally, the sixth threshold may be greater than or equal to zero. For example, the sixth threshold is zero. When the sixth threshold is zero, the statement that the sixth data quantity is less than or equal to the sixth threshold can be replaced with: the sixth data quantity is zero. Optionally, the sixth threshold may be less than or equal to the fourth threshold. For example, the sum of the sixth threshold and the fifth threshold may be less than or equal to the fourth threshold.
[0535] Optionally, the sixth data quantity being zero can be replaced by at least one of the following: no data associated with the first BSR exists in the data of the first RLC entity; no data associated with the first BSR exists in the data of the first RLC entity; the data quantity associated with the first BSR is zero; no data associated with the first BSR exists; no data associated with the first BSR exists; the data quantity is zero; no data exists; no data exists; or, the RLC layer corresponding to the first RLC does not have data associated with the first BSR. Wherein, data can be replaced by at least one of the following: an RLC SDU or RLC SDU segment associated with the first BSR, or an RLC SDU or RLC SDU segment associated with the first BSR. Optionally, the data may include: RLCSDU or RLC SDU segments that are not constructed as RLC PDUs, where the RLCSDU is an SDU and the RLC SDU segment is an SDU segment; and / or, lower-level RLC data PDUs that have been constructed as RLC PDUs but not delivered to the RLC layer, where the RLC data PDU includes RLC SDUs or RLC SDU segments.
[0536] The following example illustrates the condition "the sixth data volume is less than or equal to the sixth threshold".
[0537] For example, if the first BSR is a BSR triggered for the first LCH, and all data in the first LCH cache is PDCP SDU#1, then all data associated with the first BSR is PDCP SDU#1. If the first device has transmitted PDCP SDU#1 to the second RLC entity through the PDCP entity, and / or the first device has transmitted a MACPDU including PDCP SDU#1 through the second MAC entity, then the sixth data volume is less than or equal to the sixth threshold.
[0538] Optionally, the fourth indication information from the first RLC entity may be sent when the sixth data amount is less than or equal to the sixth threshold; accordingly, in S803, when the sixth data amount is less than or equal to the sixth threshold, the first device may receive the fourth indication information from the first RLC entity through the first MAC entity.
[0539] In some other possible designs, the first device can receive fourth indication information (referred to as fourth indication information #1) from the PDCP entity through the first MAC entity, and receive fourth indication information (referred to as fourth indication information #2) from the first RLC entity through the first MAC entity.
[0540] Specifically, the first device can receive the fourth indication information #1 from the PDCP entity through the first MAC entity. For details, please refer to the above description of "the first device can receive the fourth indication information from the PDCP entity through the first MAC entity". The first device can also receive the fourth indication information #2 from the first RLC entity through the first MAC entity. For details, please refer to the above description of "the first device can receive the fourth indication information from the first RLC entity through the first MAC entity".
[0541] Among some possible ways, Figure 8 The method shown also includes S804:
[0542] S804: The first device sends the fifth instruction information to the PDCP entity through the second MAC entity.
[0543] The fifth indication information can be used to indicate that all data associated with the second BSR has been transmitted by the second MAC entity, and the second BSR is a BSR triggered by the second MAC entity.
[0544] For details on S804, please refer to S504, except that the second instruction information is replaced with the fifth instruction information, the first instruction information is replaced with the fourth instruction information, DSR is replaced with BSR, and the delay key data is replaced with data. Further details will not be repeated here.
[0545] In this way, the first device can accurately determine, based on the fifth instruction information, that all data associated with the second BSR has been transmitted by the second MAC entity.
[0546] Among the possible implementations, S802 can be implemented in multiple ways, for example, at least one of methods c1 to c3.
[0547] Method c1: The fourth data volume is less than or equal to the fourth threshold in the following cases; correspondingly, the first device can determine that the fourth data volume is less than or equal to the fourth threshold and cancel the first BSR in the following cases, or the first MAC entity in the first device can determine that the fourth data volume is less than or equal to the fourth threshold and cancel the first BSR in the following cases: the first device receives the fourth indication information from the PDCP entity through the first MAC entity (i.e., S803 above), and the sixth data volume is less than or equal to the sixth threshold.
[0548] The fourth data quantity is the sum of the fifth and sixth data quantities. The fifth data quantity is the data quantity of the third data, which is the data of the PDCP entity in at least one data set. For details on the fifth data quantity, please refer to the description of the fifth data quantity in S803; for details on the sixth data quantity being less than or equal to the sixth threshold, please refer to the description of the sixth data quantity being less than or equal to the sixth threshold in S803, and will not be repeated here.
[0549] For details on method c1, please refer to Figure 5 The description of method b1 in the illustrated method is simply that the first data volume is replaced with the fourth data volume, the second data volume is replaced with the fifth data volume, the third data volume is replaced with the sixth data volume, the first threshold is replaced with the fourth threshold, the second threshold is replaced with the fifth threshold, the third threshold is replaced with the sixth threshold, the latency key data is replaced with data, and DSR is replaced with BSR. It will not be described again.
[0550] Through this method c1, the first device (e.g., the first MAC entity in the first device) can accurately determine that the fourth data quantity is less than or equal to the fourth threshold based on the fourth indication information and the sixth data quantity, thereby canceling the first BSR. This avoids the first device being unable to cancel the first BSR when the data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking BSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0551] Method c2: At the second time, if the amount of fourth data to be transmitted by the first MAC entity is less than or equal to the fourth threshold, the first device may cancel the first BSR.
[0552] In some implementations, the second time can be the time when the first device receives the fourth indication information through the first MAC entity, or the time after the first device receives the fourth indication information through the first MAC entity. The specific content of the fourth indication information can be found in the description of the fourth indication information in S803, and will not be repeated here. Optionally, in this implementation, the first device can cancel the first BSR after receiving the fourth indication information; or, method c2 can be replaced by: the first device can cancel the first BSR upon receiving the fourth indication information. For example, if the first device receives the fourth indication information from the PDCP entity through the first MAC entity, the first device can cancel the first BSR after receiving the fourth indication information. Another example is if the first device receives the fourth indication information from the first RLC entity through the first MAC entity, the first device can cancel the first BSR after receiving the fourth indication information. Yet another example is if the first device receives fourth indication information #1 from the PDCP entity through the first MAC entity and fourth indication information #2 from the first RLC entity through the first MAC entity, the first device can cancel the first BSR after receiving both fourth indication information #1 and fourth indication information #2.
[0553] Optionally, at the second time, if the third condition is met, the first device may cancel the first BSR. If the third condition is met, the fourth data volume is less than or equal to the fourth threshold.
[0554] For details on method c2, please refer to Figure 5 The description of method b2 in the illustrated method is simply that the first data volume is replaced with the fourth data volume, the second data volume is replaced with the fifth data volume, the third data volume is replaced with the sixth data volume, the first threshold is replaced with the fourth threshold, the second threshold is replaced with the fifth threshold, the third threshold is replaced with the sixth threshold, the latency key data is replaced with data, DSR is replaced with BSR, and the first time is replaced with the second time. It will not be described again.
[0555] In this method c2, if the third condition is met at the second time, the first device (e.g., the first MAC entity in the first device) can cancel the first BSR, thereby avoiding the first device being unable to cancel the first BSR when the data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus avoiding the first device continuously marking BSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0556] Optionally, mode c3 (or S802) can be replaced by: if the third condition is met, the first device can cancel the first BSR.
[0557] Method c3: The first device sends a sixth indication message to the first MAC entity through the second MAC entity. Accordingly, S802 may include: the first device cancels the first BSR if the fourth data volume is less than or equal to the fourth threshold, based on the sixth indication message.
[0558] The sixth indication information can be used to indicate that data #1 associated with the second BSR is transmitted by the second MAC entity, and the second BSR is a BSR triggered by the second MAC entity.
[0559] For details on method c3, please refer to Figure 5 The description of method b3 in the illustrated method is simply that the first data volume is replaced with the fourth data volume, the second data volume is replaced with the fifth data volume, the third data volume is replaced with the sixth data volume, the first threshold is replaced with the fourth threshold, the second threshold is replaced with the fifth threshold, the third threshold is replaced with the sixth threshold, the latency key data is replaced with data, and DSR is replaced with BSR. It will not be described again.
[0560] In this method c3, the first device sends a sixth indication message to the first MAC entity through the second MAC entity. The sixth indication message can be used to indicate that the data #1 associated with the second BSR is transmitted by the second MAC entity. In this way, the first device (e.g., the first MAC entity in the first device) can accurately determine whether the fourth data amount is less than or equal to the fourth threshold based on the sixth indication message, thereby canceling the first BSR. This avoids the first device being unable to cancel the first BSR when the data associated with the first BSR is transmitted by a MAC entity other than the first MAC entity in the first device, thus preventing the first device from continuously marking BSRs that cannot be canceled and are yet to be transmitted, and reducing the power consumption of the first device.
[0561] Optionally, Figure 8 The method shown may also include only "the first device sends the sixth instruction information to the first MAC entity through the second MAC entity" in mode c3, without including the other features in mode c3.
[0562] Among some possible ways, Figure 8 The method shown also includes S805:
[0563] S805: The second device sends the third configuration information; correspondingly, the first device receives the third configuration information.
[0564] The third configuration information is used to indicate that the first BSR should be cancelled when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold. This application does not limit the specific indication method; for example, it can be explicit or implicit. The specific content of "the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold" can be found in the explanation of "the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold" in S802, and will not be repeated here. For example, when the fourth threshold is zero, the third configuration information is used to indicate that the first BSR should be cancelled when the fourth data volume to be transmitted by the first MAC entity is zero. The specific content of "the fourth data volume to be transmitted by the first MAC entity is zero" can be found in the explanation of "the fourth data volume to be transmitted by the first MAC entity is zero" in S802, and will not be repeated here.
[0565] The third configuration information can be carried in traditional messages or in new messages, without restriction. For example, the third configuration information can be carried in DCI, MAC CE, or RRC messages.
[0566] The third configuration information may have other names, such as cancellation configuration information, instruction information, or cancellation instruction information, without restriction.
[0567] Optionally, S805 precedes S802; the order between S805 and S801 is not limited in this application.
[0568] In this method, the first device can cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold, based on the third configuration information. Furthermore, in this method, the third configuration information is sent from the second device to the first device, allowing the second device to flexibly configure or instruct the first device's operations.
[0569] Among some possible ways, Figure 8 The method shown also includes S806:
[0570] S806: The first device sends third capability information; correspondingly, the second device receives the third capability information.
[0571] The third capability information can be used to indicate that the first device has the ability to cancel the first BSR when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold. This application does not limit the specific indication method; for example, it can be explicit or implicit. The specific content of "the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold" can be found in the explanation of "the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold" in S802, and will not be repeated here. For example, when the fourth threshold is zero, the third capability information can be used to indicate that the first device has the ability to cancel the first BSR when the fourth data volume to be transmitted by the first MAC entity is zero. The specific content of "the fourth data volume to be transmitted by the first MAC entity is zero" can be found in the explanation of "the fourth data volume to be transmitted by the first MAC entity is zero" in S802, and will not be repeated here.
[0572] Optionally, the third capability information can be used to indicate that the first device has the ability to cancel the first BSR when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold. This can be understood as: the third capability information can be used to indicate that the first device can cancel the first BSR when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold.
[0573] Optionally, the third capability information can be used to determine (or trigger) third configuration information. For example, after receiving the third capability information, the second device can determine the third configuration information and send it to the first device.
[0574] Third-party capability information can be carried in traditional messages or in new messages, without restriction. For example, third-party capability information can be carried in UCI, MAC CE, or RRC messages.
[0575] Third-party capability information may have other names, such as capability indication information, and there are no restrictions.
[0576] Optionally, S806 may precede S805; the order between S806 and S801 is not limited in this application.
[0577] In this way, the first device can accurately report to the second device via third capability information that the first device has the capability to cancel the first BSR when the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold. In this way, the second device can determine a configuration for the first device that is appropriate to its capabilities.
[0578] Based on the same technical concept as the above-described method embodiments, this application provides a corresponding communication device that can be used to perform the functions of the relevant steps in the above-described method embodiments. This function can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The communication device can be a terminal or access network device, or it can be a device for a terminal or access network device (e.g., a module, communication module, circuit or chip responsible for communication and / or sensing functions (such as a modem chip, or a SoC chip or SIP chip containing a modem core), chip system, or processor), or it can be a logical node, logical module, or software capable of implementing all or part of the functions of the terminal or access network device.
[0579] In one possible implementation, the communication device provided in this application embodiment has the following structure: Figure 9 As shown, the communication device includes a processing unit 902. Optionally, the communication device may also include an interface unit 901. The functions of each unit in the communication device 900 are described below.
[0580] Interface unit 901 is used for inputting and / or outputting information. Input information can be replaced by received information, and output information can be replaced by transmitted information. When outputting information, interface unit 901 can output information to other devices outside of communication device 900, or to other units within communication device 900. In some embodiments, interface unit 901 can be implemented through at least one of a physical interface, a communication module, a communication interface, and an input / output interface. In other embodiments, interface unit 901 can be implemented through an interface circuit, such as a mobile communication module. The mobile communication module may include one or more of at least one antenna, at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. Interface unit 901 is used to perform the receiving and transmitting operations in the above method embodiments.
[0581] In this application, the interface unit 901 may also have other names, such as a transceiver unit or a communication unit. Optionally, the interface unit 901 may include a receiving unit and / or a sending unit, used for inputting information and outputting information, respectively. The receiving unit is used to perform the receiving operation in the above method embodiments. The sending unit is used to perform the sending operation in the above method embodiments.
[0582] The processing unit 902 can be used to support the communication device 900 in performing the processing actions in the above method embodiments. The processing unit 902 can be implemented by one or more processors. For example, the processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), microprocessors (MCUs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor. The processing unit 902 is used to perform processing-related operations in the above method embodiments, for example, to instruct operations other than receiving and sending operations in the above method embodiments.
[0583] In one embodiment, the communication device 900 is applied to Figure 5 The first device shown in this embodiment of the application is described below. The specific functions of the processing unit 902 in this embodiment are described below.
[0584] The processing unit 902 is configured to: trigger a first DSR corresponding to a first MAC entity; and cancel the first DSR if the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold, wherein the first data volume is the total data volume of at least one latency key data associated with the first DSR, and the at least one latency key data includes latency key data of each of N1 entities, where N1 is a positive integer, and the N1 entities include: a PDCP entity and a first radio link control RLC entity, wherein the first RLC entity is an entity between the PDCP entity and the first MAC entity.
[0585] In some possible ways, the processing unit 902 is also configured to: receive first indication information from the PDCP entity through the interface unit 901 via the first MAC entity; and cancel the first DSR if the first data volume is less than or equal to the first threshold according to the first indication information.
[0586] Optionally, the processing unit 902 is further configured to: send second indication information to the PDCP entity through the interface unit 901 via the second MAC entity, the second indication information being used to indicate that all delay-critical data associated with the second DSR has been transmitted by the second MAC entity, the second DSR being a DSR triggered by the second MAC entity.
[0587] In some possible ways, the processing unit 902 is specifically configured to: cancel the first DSR if a first condition is met at a first time; wherein the first time is related to the transmission time of the MAC CE corresponding to the first DSR; if the first condition is met, the first data amount is less than or equal to a first threshold; the first condition includes at least one of the following: all delay-critical data associated with the first DSR has been transmitted by any MAC entity; or, in the MAC CE, the delay information corresponding to the first DSR is zero.
[0588] In some implementations, the processing unit 902 is also used to send a MACCE through the interface unit 901 before canceling the first DSR.
[0589] Optionally, the processing unit 902 is specifically used to: send the MAC CE through the interface unit 901 when the first time is after the time when the MAC CE is sent.
[0590] In other implementations, the processing unit 902 is also configured to: determine not to send a MAC CE if the first condition is met, and / or after canceling the first DSR.
[0591] Optionally, the processing unit 902 is specifically configured to: determine not to send the MAC CE if the first time is the time of transmission of the MAC CE, or if it is a time before the transmission time.
[0592] In some possible ways, the processing unit 902 is also used to: send third indication information to the first MAC entity through the second MAC entity via the interface unit 901, the third indication information being used to indicate that the first delay key data associated with the second DSR is transmitted by the second MAC entity, the second DSR being a DSR triggered by the second MAC entity.
[0593] In some possible ways, the processing unit 902 is also configured to: receive first configuration information through the interface unit 901, the first configuration information being used to indicate that if the first amount of first data to be transmitted by the first MAC entity is less than or equal to a first threshold, the first DSR is cancelled.
[0594] Optionally, the processing unit 902 is further configured to: send first capability information through the interface unit 901, the first capability information being used to indicate that the first device has the capability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
[0595] In some possible ways, the processing unit 902 is specifically configured to: trigger a first DSR when a second condition is met, the second condition including: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0596] Optionally, the processing unit 902 is further configured to: receive second configuration information through the interface unit 901, the second configuration information being used to instruct the first device to trigger the first DSR under the condition that the second condition is met.
[0597] Optionally, the processing unit 902 is further configured to: send second capability information through the interface unit 901, the second capability information being used to indicate that the first device has the capability to trigger the first DSR under the condition that the second condition is met.
[0598] In another embodiment, the communication device 900 is applied to Figure 5 The second device shown in this embodiment of the application. The specific functions of the processing unit 902 in this embodiment are described below.
[0599] Processing unit 902 is configured to: send first configuration information through interface unit 901, the first configuration information being used to instruct the first device to cancel the first DSR corresponding to the first MAC entity when the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold. The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. The first data volume is the total data volume of at least one latency key data associated with the first DSR. The at least one latency key data includes latency key data of each of N1 entities, where N1 is a positive integer. The N1 entities are located in the first device, and the N1 entities include: the PDCP entity and a first RLC entity, the first RLC entity being the entity between the PDCP entity and the first MAC entity.
[0600] In some possible ways, the processing unit 902 is also configured to: receive first capability information through the interface unit 901, the first capability information being used to indicate that the first device has the capability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
[0601] In yet another embodiment, the communication device 900 is applied to Figure 7 The first device shown in this embodiment of the application is described below. The specific functions of the processing unit 902 in this embodiment are described below.
[0602] The processing unit 902 is configured to: trigger the first DSR corresponding to the first MAC entity when a second condition is met, wherein the second condition includes: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0603] In some possible ways, the processing unit 902 is also configured to: receive second configuration information through the interface unit 901, the second configuration information being used to instruct the first device to trigger the first DSR when the second condition is met.
[0604] Optionally, the processing unit 902 is further configured to: send second capability information through the interface unit 901, the second capability information being used to indicate that the first device has the capability to trigger the first DSR under the condition that the second condition is met.
[0605] In yet another embodiment, the communication device 900 is applied to Figure 7 The second device shown in this embodiment of the application. The specific functions of the processing unit 902 in this embodiment are described below.
[0606] Processing unit 902 is configured to: send second configuration information through interface unit 901, the second configuration information being used to instruct the first device to trigger the first DSR corresponding to the first MAC entity under the condition that a second condition is met, the second condition including: the latency key data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0607] In some possible ways, the processing unit 902 is also configured to: receive second capability information through the interface unit 901, the second capability information being used to indicate that the first device has the capability to trigger the first DSR under the condition that the second condition is met.
[0608] In yet another embodiment, the communication device 900 is applied to Figure 8 The first device shown in this embodiment of the application is described below. The specific functions of the processing unit 902 in this embodiment are described below.
[0609] Processing unit 902 is configured to: trigger a first BSR corresponding to a first MAC entity; and cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold. The fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data volume includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0610] In some possible ways, the processing unit 902 is also configured to: receive fourth indication information from the PDCP entity through the interface unit 901 via the first MAC entity; and cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to the fourth threshold according to the fourth indication information.
[0611] Optionally, the processing unit 902 is further configured to: send fifth indication information to the PDCP entity through the interface unit 901 via the second MAC entity. The fifth indication information can be used to indicate that all data associated with the second BSR has been transmitted by the second MAC entity, and the second BSR is a BSR triggered by the second MAC entity.
[0612] In some possible embodiments, processing unit 902 is specifically configured to: cancel the first BSR if a third condition is met at a second time. Optionally, the second time is related to the transmission time of the MAC CE corresponding to the first BSR. If the third condition is met, the fourth data amount is less than or equal to a fourth threshold. Exemplarily, the third condition includes at least one of the following: all data associated with the first BSR has been transmitted by any MAC entity; or, in the MAC CE, the value of the information corresponding to the first BSR is zero.
[0613] In some possible ways, the processing unit 902 is also configured to: send a sixth indication message to the first MAC entity through the second MAC entity via the interface unit 901; and cancel the first BSR if the fourth data amount is less than or equal to the fourth threshold according to the sixth indication message.
[0614] In some possible configurations, the processing unit 902 is further configured to receive third configuration information via the interface unit 901. The third configuration information indicates that the first BSR should be cancelled if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold.
[0615] Optionally, the processing unit 902 is further configured to: send third capability information through the interface unit 901. The third capability information can be used to indicate that the first device has the capability to cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold.
[0616] In yet another embodiment, the communication device 900 is applied to Figure 8 The second device shown in this embodiment of the application. The specific functions of the processing unit 902 in this embodiment are described below.
[0617] Processing unit 902 is configured to: send third configuration information through interface unit 901, the third configuration information being used to indicate that the first BSR is cancelled if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold. The fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0618] In some possible configurations, the processing unit 902 is further configured to: receive third capability information via the interface unit 901. The third capability information can be used to indicate that the first device has the capability to cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold.
[0619] In one possible design, when the communication device 900 is a communication equipment or a communication module within a communication equipment, the functionality of the processing unit 902 can be implemented by one or more processors. For example, the processor may include a modem chip, or a system-on-a-chip (SoC) or SIP chip containing a modem core. The functionality of the interface unit 901 can be implemented by transceiver circuitry.
[0620] In one possible design, when the communication device 900 is a circuit or chip responsible for communication functions in a communication device, such as a modem chip or a system-on-a-chip (SoC) or SIP chip containing a modem core, the function of the processing unit 902 can be implemented by a circuit system in the aforementioned chip that includes one or more processors or processor cores. The function of the interface unit 901 can be implemented by the interface circuit or data transceiver circuit on the aforementioned chip.
[0621] The communication device can be a terminal or an access network device.
[0622] For a more detailed description of the processing unit 902 and the interface unit 901 mentioned above, please refer to [link / reference]. Figures 5 to 8 The relevant descriptions in the method embodiments shown are directly obtained and will not be repeated here.
[0623] It should be noted that the module division in the above embodiments of this application is illustrative and only represents a logical functional division. In actual implementation, there may be other division methods. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, exist as separate physical units, or have two or more units integrated into one unit. The integrated units can be implemented in hardware, as software functional units, or in a combination of hardware and software. Whether a function is executed 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.
[0624] For example, the functional unit in any of the above devices may be one or more integrated circuits configured to implement the above methods, such as one or more ASICs, one or more CPUs, one or more MCUs, one or more DSPs, or one or more FPGAs, or a combination of at least two of these integrated circuit forms.
[0625] If the integrated units described above 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 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.) or processor 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 (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0626] In one possible implementation, the communication device provided in the embodiments of this application is described below. Figure 10 As shown, the communication device 1000 includes a processor 1002. Optionally, the communication device 1000 further includes an interface circuit 1001 and a memory 1003. The interface circuit 1001, the processor 1002, and the memory 1003 are coupled to each other.
[0627] Optionally, the interface circuit 1001, processor 1002, and memory 1003 are coupled to each other via bus 1004. Bus 1004 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 10 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0628] Interface circuit 1001 is used for inputting and / or outputting information. Input information can be replaced with received information, and output information can be replaced with transmitted information. When outputting information, interface circuit 1001 can output information to other devices outside of communication device 1000, or to other units within communication device 1000. For example, interface circuit 1001 can be implemented through at least one of a physical interface, a communication module, a communication interface, an input / output interface, and a mobile communication module. The mobile communication module may include one or more of at least one antenna, at least one filter, a switch, a power amplifier, an LNA, etc. Interface circuit 1001 is used to perform the receiving and transmitting operations in the above method embodiments.
[0629] The interface circuit 1001 may be one of the following: a transceiver, a transceiver circuit, a communication circuit, an interface, a communication interface, or an input / output interface (e.g., a chip's input / output interface). The interface circuit 1001 may include an input interface circuit and an output interface circuit, used for inputting information and outputting information, respectively. The input interface circuit is used to perform the receiving operation in the above method embodiments. The output interface circuit is used to perform the transmitting operation in the above method embodiments.
[0630] The transceiver can be used for communication with other communication devices. For example, if communication device 1000 is a terminal, the transceiver can be used to communicate with access network equipment or with another terminal. As another example, if communication device 1000 is an access network device, the transceiver can be used to communicate with a terminal or with another access network device.
[0631] Optionally, the transceiver may include a receiver and / or a transmitter. The receiver is used to perform the receiving operation in the above method embodiments. The transmitter is used to perform the sending operation in the above method embodiments.
[0632] Optionally, the transceiver can be integrated with the processor 1002 or exist independently and be coupled to the processor 1002 through the interface circuit of the communication device 1000. This application embodiment does not specifically limit this.
[0633] Processor 1002 can be used to support communication device 1000 in performing the processing actions in the above method embodiments. When communication device 1000 is used to implement the above method embodiments, processor 1002 can also be used to implement the functions of processing unit 902. Processor 1002 can be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. General-purpose processors can be microprocessors or any conventional processor. Processor 1002 is used to perform processing-related operations in the above method embodiments, for example, to instruct operations other than receiving and sending operations in the above method embodiments.
[0634] In one embodiment, the communication device 1000 is applied to Figure 5 The first device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0635] The processor 1002 is configured to: trigger a first DSR corresponding to a first MAC entity; and cancel the first DSR if the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold, wherein the first data volume is the total data volume of at least one delay key data associated with the first DSR, and the at least one delay key data includes the delay key data of each of N1 entities, where N1 is a positive integer, and the N1 entities include: a PDCP entity and a first radio link control RLC entity, wherein the first RLC entity is an entity between the PDCP entity and the first MAC entity.
[0636] In another embodiment, the communication device 1000 is applied to Figure 5 The second device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0637] Processor 1002 is configured to: send first configuration information via interface circuit 1001, the first configuration information being used to instruct the first device to cancel the first DSR corresponding to the first MAC entity when the first data volume to be transmitted by the first MAC entity is less than or equal to a first threshold. The first device includes a PDCP entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. The first data volume is the total data volume of at least one latency key data associated with the first DSR. The at least one latency key data includes latency key data of each of N1 entities, where N1 is a positive integer. The N1 entities are located in the first device, and the N1 entities include: the PDCP entity and a first RLC entity, the first RLC entity being the entity between the PDCP entity and the first MAC entity.
[0638] In yet another embodiment, the communication device 1000 is applied to Figure 7 The first device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0639] The processor 1002 is configured to: trigger a first DSR corresponding to a first MAC entity when a second condition is met, the second condition including: latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0640] In yet another embodiment, the communication device 1000 is applied to Figure 7 The second device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0641] The processor 1002 is configured to: send second configuration information through the interface circuit 1001, the second configuration information being used to instruct the first device to trigger the first DSR corresponding to the first MAC entity under the condition that a second condition is met, the second condition including: the latency critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
[0642] In yet another embodiment, the communication device 1000 is applied to Figure 8 The first device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0643] Processor 1002 is configured to: trigger a first BSR corresponding to a first MAC entity; and cancel the first BSR if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold. The fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data volume includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0644] In yet another embodiment, the communication device 1000 is applied to Figure 8 The second device shown in this embodiment of the application is described below. The specific functions of the processor 1002 in this embodiment are described below.
[0645] Processor 1002 is configured to: send third configuration information via interface circuit 1001, the third configuration information being used to indicate that the first BSR is cancelled if the fourth data volume to be transmitted by the first MAC entity is less than or equal to a fourth threshold. The fourth data volume is the total data volume of at least one data associated with the first BSR. The at least one data volume includes data from N1 entities in the first device, where N1 is a positive integer. The N1 entities include: a PDCP entity and a first RLC entity. The first RLC entity may be an entity between the PDCP entity and the first MAC entity.
[0646] The specific functions of processor 1002 can be found in the descriptions of the communication methods provided in the embodiments and examples of this application above. Figure 9 The specific functional description of the communication device 900 shown in the embodiments of this application will not be repeated here.
[0647] Memory 1003 is used to store program instructions and / or data. Specifically, program instructions may include program code, which includes computer operation instructions. Memory 1003 may include RAM and may also include non-volatile memory, such as at least one disk storage device. Processor 1002 executes the program instructions stored in memory 1003 and uses the data stored in memory 1003 to implement the above-mentioned functions, thereby realizing the communication method provided in the embodiments of this application. Memory 1003 may be integrated with processor 1002 or may be a memory outside the communication device.
[0648] It is understood that this application Figure 10The memory 1003 can be volatile memory or non-volatile memory, or may include both. The non-volatile memory can be 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 RAM, which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0649] Based on the above embodiments, this application also provides a computer program product including computer-executable instructions, which, when run, causes the methods provided in the above embodiments to be executed.
[0650] Based on the above embodiments, this application also provides a computer-readable storage medium storing a computer program, which, when executed by a computer, causes the computer to perform the methods provided in the above embodiments.
[0651] The storage medium can be any available medium that a computer can access. For example, but not limited to, a computer-readable medium can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
[0652] Based on the above embodiments, this application also provides a chip for reading a computer program stored in a memory and implementing the method provided in the above embodiments.
[0653] Based on the above embodiments, this application provides a chip system including a processor for supporting a computer device in implementing the functions involved in the devices in the above embodiments. In one possible design, the chip system further includes a memory for storing necessary programs and data of the computer device. The chip system may be composed of chips or may include chips and other discrete components.
[0654] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.
[0655] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0656] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0657] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0658] In this application, the terms "system" and "network" are used interchangeably. "At least one item" refers to one or more items, and "more than one item" refers to two or more items. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple. "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. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. In the textual description of this application, the character " / " generally indicates that the objects before and after it are in an "or" relationship. For example, A / B can mean A or B, where A and B can be singular or plural.
[0659] Furthermore, to facilitate a clear description of the technical solutions in the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first" and "second" do not limit the quantity or execution order, and that "first" and "second" are not necessarily different. Additionally, the numbering of steps in the various embodiments described in this application is only for distinguishing different steps and is not intended to limit the order of steps.
[0660] It is understood that some optional features in the embodiments of this application can be implemented independently in certain scenarios without relying on other features, such as the current solution on which they are based, to solve the corresponding technical problems and achieve the corresponding effects. Alternatively, they can be combined with other features as needed in certain scenarios. Correspondingly, the apparatus given in the embodiments of this application can also implement these features or functions, which will not be elaborated here.
[0661] In this application, unless otherwise specified, the same or similar parts between the various embodiments can be referred to each other. In the various embodiments of this application, unless otherwise specified or there is a logical conflict, the terminology and / or descriptions between different embodiments are consistent and can be mutually referenced. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships. The following descriptions of the embodiments of this application do not constitute a limitation on the scope of protection of this application.
[0662] It is understood that the term "embodiment" used throughout the specification means that a specific feature, structure, or characteristic related to an embodiment is included in at least one embodiment of this application. Therefore, various embodiments throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It is understood that in the various embodiments of this application, the sequence number of each process does not imply the order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0663] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.
[0664] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.
Claims
1. A communication method, characterized in that, An application to a first device or apparatus for a first device, the first device including a Packet Data Convergence Protocol (PDCP) entity, and a first Media Access Control (MAC) entity and a second MAC entity associated with the PDCP entity, the first MAC entity and the second MAC entity being used to transmit data of the first device, the method comprising: Trigger the first Delay Status Report (DSR) corresponding to the first MAC entity; If the first data volume to be transmitted by the first MAC entity is less than or equal to the first threshold, the first DSR is cancelled. The first data volume is the total data volume of at least one latency key data associated with the first DSR. The at least one latency key data includes the latency key data of each of N1 entities, where N1 is a positive integer. The N1 entities include: the PDCP entity and the first Radio Link Control (RLC) entity. The first RLC entity is the entity between the PDCP entity and the first MAC entity.
2. The method as described in claim 1, characterized in that, Sometimes, critical data is transmitted by the second MAC entity.
3. The method as described in claim 1 or 2, characterized in that, The method further includes: The first MAC entity receives first indication information from the PDCP entity; Cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold, including: canceling the first DSR when the first amount of data is less than or equal to the first threshold according to the first indication information.
4. The method as described in claim 3, characterized in that, The first indication information is used to indicate at least one of the following: All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device, where N2 is a positive integer. The N2 entities include at least one of the following: a second RLC entity and a second MAC entity, wherein the second RLC entity is the entity between the PDCP entity and the second MAC entity. All latency-critical data associated with the first DSR has been transmitted by the second MAC entity; The latency-critical data associated with the first DSR consists of a first portion of latency-critical data and a second portion of latency-critical data. The first portion of latency-critical data is transmitted to the N2 entities, and the second portion of latency-critical data has been transmitted by the second MAC entity; or The second data volume is less than or equal to the second threshold; wherein the second data volume is the data volume of the first data, and the first data is the latency key data of the PDCP entity among the at least one latency key data.
5. The method as described in claim 3 or 4, characterized in that, The first indication information is transmitted under at least one of the following conditions: All latency-critical data associated with the first DSR is transmitted to N2 entities in the first device, where N2 is a positive integer. The N2 entities include at least one of the following: a second RLC entity and a second MAC entity, wherein the second RLC entity is the entity between the PDCP entity and the second MAC entity. All latency-critical data associated with the first DSR has been transmitted by the second MAC entity; The latency-critical data associated with the first DSR consists of a first portion of latency-critical data and a second portion of latency-critical data. The first portion of latency-critical data is transmitted to the N2 entities, and the second portion of latency-critical data has been transmitted by the second MAC entity; or The second data volume is less than or equal to the second threshold; wherein the second data volume is the data volume of the first data, and the first data is the latency key data of the PDCP entity among the at least one latency key data.
6. The method as described in claim 4 or 5, characterized in that, The second threshold is zero.
7. The method according to any one of claims 4 to 6, characterized in that, The method further includes: The second MAC entity sends a second indication message to the PDCP entity, the second indication message being used to indicate that all latency-critical data associated with the second DSR has been transmitted by the second MAC entity, the second DSR being a DSR triggered by the second MAC entity.
8. The method according to any one of claims 3 to 7, characterized in that, The first data volume is less than or equal to the first threshold in the following cases: The first indication information is received from the PDCP entity through the first MAC entity, and the third data volume is less than or equal to the third threshold, wherein the first data volume is the sum of the second data volume and the third data volume, the second data volume is the data volume of the first data, the first data is the latency key data of the PDCP entity among the at least one latency key data, the third data volume is the data volume of the second data, and the second data is the latency key data of the first RLC entity among the at least one latency key data.
9. The method as described in claim 8, characterized in that, The third threshold is zero.
10. The method according to any one of claims 1 to 8, characterized in that, The latency-critical data of the PDCP entity includes at least one of the following: a latency-critical PDCP service data unit (SDU) that has not been constructed as a PDCP data protocol data unit (PDU), a lower-layer PDCP data PDU that contains a latency-critical PDCP SDU and has not yet been transmitted to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted. The latency critical data of the first RLC entity includes at least one of the following: a latency critical RLC SDU or a latency critical RLC SDU segment that has not been constructed as an RLC data PDU, an RLC data PDU to be initially transmitted containing a latency critical RLC SDU or a latency critical RLC SDU segment, an RLC data PDU to be retransmitted, or an RLC status report.
11. The method according to any one of claims 1, 2, and 10, characterized in that, The step of canceling the first DSR when the amount of data to be transmitted by the first MAC entity is less than or equal to the first threshold includes: If the first condition is met immediately, the first DSR is cancelled. Wherein, the first time is related to the transmission time of the Media Access Control Unit (MAC CE) corresponding to the first DSR; when the first condition is met, the first data volume is less than or equal to the first threshold; the first condition includes at least one of the following: All latency-critical data associated with the first DSR has been transmitted by any MAC entity; or In the MAC CE, the delay information corresponding to the first DSR is zero.
12. The method as described in claim 11, characterized in that, The delay information corresponding to the first DSR includes: The data volume information corresponding to the first DSR, and / or the remaining time information corresponding to the first DSR.
13. The method as described in claim 11 or 12, characterized in that, Before canceling the first DSR, the method further includes: sending the MAC CE; or It also includes: if the first condition is met, and / or, after canceling the first DSR, determining not to send the MAC CE.
14. The method as described in claim 13, characterized in that, The step of determining not to send the MAC CE includes: determining not to send the MAC CE if the first time is the time when the MAC CE is sent, or a time before the sending time; and / or Sending the MAC CE includes: sending the MAC CE when the first time is a time after the time when the MAC CE was sent.
15. The method according to any one of claims 1, 2, and 10, characterized in that, The method further includes: The second MAC entity sends a third indication message to the first MAC entity, the third indication message being used to indicate that the first delay key data associated with the second DSR is transmitted by the second MAC entity, the second DSR being a DSR triggered by the second MAC entity.
16. The method according to any one of claims 1 to 15, characterized in that, The first threshold is zero.
17. The method according to any one of claims 1 to 16, characterized in that, The method further includes: Receive first configuration information, which is used to indicate that the first DSR is cancelled if the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
18. The method as described in claim 17, characterized in that, The method further includes: Send first capability information, which is used to indicate that the first device has the ability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
19. The method according to any one of claims 1 to 18, characterized in that, Triggering the first DSR corresponding to the first MAC entity includes: The first DSR is triggered when a second condition is met, the second condition including: the latency-critical data associated with the first DSR has not been transmitted by any MAC entity in the first device.
20. The method as described in claim 19, characterized in that, The method further includes: Receive second configuration information, which is used to instruct the first device to trigger the first DSR when the second condition is met.
21. The method as described in claim 20, characterized in that, The method further includes: Send second capability information, which indicates that the first device has the capability to trigger the first DSR when the second condition is met.
22. A communication method, characterized in that, The method includes: an application to a second device or an apparatus for a second device; Send first configuration information, which instructs the first device to cancel the first delay status report (DSR) corresponding to the first MAC entity when the first data volume to be transmitted by the first media access control (MAC) entity is less than or equal to a first threshold. The first device includes a packet data convergence protocol (PDCP) entity, and a first MAC entity and a second MAC entity associated with the PDCP entity. The first MAC entity and the second MAC entity are used to transmit data of the first device. The first data volume is the total data volume of at least one delay key data associated with the first DSR. The at least one delay key data includes delay key data of each of N1 entities, where N1 is a positive integer. The N1 entities are located in the first device. The N1 entities include the PDCP entity and a first radio link control (RLC) entity, where the first RLC entity is the entity between the PDCP entity and the first MAC entity.
23. The method as described in claim 22, characterized in that, The latency-critical data of the PDCP entity includes at least one of the following: a latency-critical PDCP service data unit (SDU) that has not been constructed as a PDCP data protocol data unit (PDU), a lower-layer PDCP data PDU that contains a latency-critical PDCP SDU and has not yet been delivered to the PDCP layer, a PDCP control PDU, a PDCP SDU to be retransmitted, or a PDCP data PDU to be retransmitted. The latency critical data of the first RLC entity includes at least one of the following: a latency critical RLC SDU or a latency critical RLC SDU segment that has not been constructed as an RLC data PDU, an RLC data PDU to be initially transmitted containing a latency critical RLC SDU or a latency critical RLC SDU segment, an RLC data PDU to be retransmitted, or an RLC status report.
24. The method as described in claim 22 or 23, characterized in that, The method further includes: The device receives first capability information, which indicates that the device has the capability to cancel the first DSR when the first amount of data to be transmitted by the first MAC entity is less than or equal to a first threshold.
25. A communication device, characterized in that, Includes a unit for performing the method as described in any one of claims 1-24.
26. A communication device, characterized in that, Includes a processor for executing computer programs or instructions that cause the device to perform the method as described in any one of claims 1-24.
27. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions, which, when executed, implement the method as described in any one of claims 1-24.
28. A computer program product, characterized in that, The computer program product includes: computer program code, which, when the computer program code is run, implements the method as described in any one of claims 1-24.