Processing method and apparatus for status report, communication device, and storage medium

CN122423253APending Publication Date: 2026-07-17BEIJING XIAOMI MOBILE SOFTWARE CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202480042676.9
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-11-15
Publication Date
2026-07-17

AI Technical Summary

Technical Problem

In existing technologies, RLC status reports suffer from the problem of repeatedly reporting the same content, which leads to a decrease in the efficiency and reliability of wireless communication systems.

Method used

By using reserved bits in the RLC PDU to carry indicator bits to indicate feedback in the RLC status report, the content of the RLC status report is optimized, duplicate reporting is avoided, and data integrity and resource utilization are ensured.

Benefits of technology

It improves the efficiency and reliability of wireless communication systems, reduces data conflicts and redundancy, and optimizes the content of RLC status reports.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122423253A_ABST
    Figure CN122423253A_ABST
Patent Text Reader

Abstract

This disclosure provides a method, apparatus, communication device, and storage medium for processing status reports. The method includes: a first communication device receiving first information sent by a second communication device, the first information being feedback on a first Radio Link Control (RLC) status report sent by the first communication device; and the first communication device determining a second RLC status report based on the first information. By implementing this disclosure, the content of a new RLC status report can be optimized based on feedback from previously reported RLC status reports, thereby improving the efficiency and reliability of the wireless communication system.
Need to check novelty before this filing date? Find Prior Art

Description

Status report processing methods, devices, communication equipment, and storage media Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to methods, apparatus, communication devices and storage media for processing status reports. Background Technology

[0002] 3GPP (3rd Generation Partnership Project) Radio Link Control (RLC) entities can be configured in three modes: Transparent Mode (TM), Unacknowledged Mode (UM), or Acknowledged Mode (AM). Correspondingly, an RLC entity can be classified as a TM RLC entity, a UM RLC entity, or an AM RLC entity. An AM RLC entity can consist of a transmitting side and a receiving side. For an RLC entity configured on the network side, the terminal side is configured with a peer RLC entity, and vice versa. An RLC entity can receive RLC SDUs (Service Data Units) from upper layers and pass them to upper layers. An RLC entity can send RLC PDUs (Protocol Data Units) to or receive RLC PDUs from its peer RLC entity through lower layers.

[0003] RLC PDU types can include data PDUs and control PDUs. The RLC data PDU can be used to transmit higher-layer PDUs (i.e., RLC SDUs). The RLC control PDU can be used for ARQ (Automatic Repeat reQuest), such as RLC status reporting, which is an RLC control PDU. Summary of the Invention

[0004] This disclosure provides a method, apparatus, communication device, and storage medium for processing status reports.

[0005] According to a first aspect of the present disclosure, a method for processing a status report is provided, the method being executed by a first communication device, the method comprising: receiving first information sent by a second communication device, the first information being feedback on a first Radio Link Control (RLC) status report sent by the first communication device; and determining a second RLC status report based on the first information.

[0006] According to a second aspect of the present disclosure, a method for processing a status report is provided, the method being executed by a second communication device, the method comprising: sending first information to a first communication device, the first information being feedback on a first radio link control (RLC) status report sent by the first communication device; wherein the first information is used by the first communication device to determine a second RLC status report.

[0007] According to a third aspect of the present disclosure, a communication apparatus is provided, comprising: a transceiver module for receiving first information sent by a second communication device, the first information being feedback on a first radio link control (RLC) status report sent by a first communication device; and a processing module for determining a second RLC status report based on the first information.

[0008] According to a fourth aspect of the present disclosure, a communication apparatus is provided, comprising: a transceiver module configured to send first information to a first communication device, the first information being feedback on a first radio link control (RLC) status report sent by the first communication device; wherein the first information is used by the first communication device to determine a second RLC status report.

[0009] According to a fifth aspect of the embodiments of this disclosure, a communication system is provided, comprising:

[0010] The first communication device is configured to perform an optional implementation of the aforementioned first aspect;

[0011] The second communication device is configured to perform an optional implementation of the aforementioned second aspect.

[0012] According to a sixth aspect of the present disclosure, a communication device is provided, comprising: one or more processors;

[0013] The processor is used to invoke instructions to cause the communication device to execute the optional implementations of the first and second aspects mentioned above.

[0014] According to a seventh aspect of the present disclosure, a storage medium is provided that stores instructions which, when executed on a communication device, cause the communication device to perform optional implementations of the first and second aspects described above.

[0015] According to an eighth aspect of the present disclosure, a program product is provided, including at least one of a program and instructions, wherein the program and instructions, when executed by a communication device, implement optional implementations of the first and second aspects described above.

[0016] According to the technical solution disclosed herein, the RLC status report can be enhanced. That is, the content of the new RLC status report can be optimized based on the feedback of the reported RLC status report. This can solve the problem of repeated reporting of the same content when reporting the RLC status in the prior art, thereby improving the efficiency and reliability of the wireless communication system. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings required for the description of the embodiments are introduced below. The following drawings are only some embodiments of this disclosure and do not impose specific limitations on the protection scope of this disclosure.

[0018] Figure 1 is a schematic diagram of the architecture of a communication system provided in an embodiment of this disclosure;

[0019] Figure 2A is an example diagram showing the transceiver buffer storing an RLC SDU according to an embodiment of this disclosure;

[0020] Figure 2B is an example diagram showing the transceiver buffer storing an RLC SDU according to an embodiment of this disclosure;

[0021] Figure 2C is an example diagram showing the transceiver buffer storing an RLC SDU according to an embodiment of this disclosure;

[0022] Figure 2D is an example diagram illustrating the state variables maintained by the receiving device and the triggering of state reports according to an embodiment of this disclosure;

[0023] Figure 3 is an interactive schematic diagram of the status report processing method shown in an embodiment of this disclosure;

[0024] Figure 4A is an example diagram showing the position of the third indicator bit in a STATUS PDU carrying a 12-bit SN, according to an embodiment of this disclosure;

[0025] Figure 4B is an example diagram showing the position of the third indicator bit in a STATUS PDU carrying an 18-bit SN, according to an embodiment of this disclosure;

[0026] Figure 4C is an example diagram showing the position of the second indicator bit in an AMD PDU carrying an 18-bit SN (without SO) according to an embodiment of this disclosure;

[0027] Figure 5 is an interactive schematic diagram of a status report processing method according to an embodiment of the present disclosure;

[0028] Figure 6A is a schematic diagram of the structure of the first communication device proposed in an embodiment of this disclosure;

[0029] Figure 6B is a schematic diagram of the structure of the second communication device proposed in an embodiment of this disclosure;

[0030] Figure 7A is a schematic diagram of the structure of the communication device 7100 proposed in an embodiment of this disclosure;

[0031] Figure 7B is a schematic diagram of the structure of the chip 7200 proposed in the embodiments of this disclosure. Detailed Implementation

[0032] This disclosure provides a method, apparatus, communication device, and storage medium for processing status reports.

[0033] In a first aspect, embodiments of this disclosure propose a method for processing status reports, which is executed by a first communication device. The method includes: receiving first information sent by a second communication device, wherein the first information is feedback on a first Radio Link Control (RLC) status report sent by the first communication device; and determining a second RLC status report based on the first information.

[0034] In the above embodiments, the content of the new RLC status report can be optimized based on the feedback from the reported RLC status report. That is, by enhancing the RLC status report, the problem of repeated reporting of the same content when reporting the RLC status in the prior art can be solved, thereby improving the efficiency and reliability of the wireless communication system.

[0035] In conjunction with some embodiments of the first aspect, in some embodiments, receiving the first information sent by the second communication device includes: receiving one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) sent by the second communication device, wherein the first RLC PDU includes at least one indicator bit, and at least one indicator bit of the one or more first RLC PDUs is used to indicate the first information.

[0036] In the above embodiments, at least one indicator bit can be carried in the reserved bits (also called reserved bits) of the RLC PDU to indicate feedback on the RLC status report, which can improve the resource utilization of the RLC PDU.

[0037] In conjunction with some embodiments of the first aspect, in some embodiments, at least one indicator bit includes a first indicator bit, which satisfies one or more of the following: the value of the first indicator bit is a first value, indicating that the first information is an acknowledgment response (ACK) feedback; the value of the first indicator bit is a second value, indicating that the first information is a non-acknowledgment response (NACK) feedback; the first indicator bit is defaulted, used to indicate that the second communication device does not have a first RLC status report that needs to be fed back.

[0038] In conjunction with some embodiments of the first aspect, in some embodiments, at least one indicator bit includes a first indicator bit, which satisfies one or more of the following: the value of the first indicator bit is a first value, indicating that the first information is ACK feedback; the value of the first indicator bit is a second value, indicating that the second communication device does not have the first RLC status report that needs to be fed back or indicating that the first information is NACK feedback.

[0039] In conjunction with some embodiments of the first aspect, in some embodiments, at least one indicator bit includes a second indicator bit that identifies a first RLC status report.

[0040] In the above embodiments, by identifying the first RLC status report in the first RLC PDU, it can serve as a unique identifier to distinguish whether the feedback in the first RLC PDU is feedback on the first RLC status report, thus ensuring the data integrity of the RLC status report and avoiding data conflicts and data redundancy.

[0041] In conjunction with some embodiments of the first aspect, in some embodiments, the first RLC status report includes a third indicator bit that identifies the first RLC status report.

[0042] In the above embodiments, by identifying the first RLC status report, it can serve as a unique identifier, distinguishing it from other RLC status reports, ensuring the data integrity of the RLC status reports, and avoiding data conflicts and data redundancy.

[0043] In conjunction with some embodiments of the first aspect, in some embodiments, the second indicator bit and the third indicator bit have the same value.

[0044] In conjunction with some embodiments of the first aspect, in some embodiments, the second indicator bit is defaulted, which is used to indicate that the second communication device does not have a first RLC status report that needs to be fed back.

[0045] In the above embodiments, when the second communication device does not have a first RLC status report that needs to be fed back, it can indicate this by using the default second indicator bit, which can reduce the content of the data packet and thus save resources.

[0046] In conjunction with some embodiments of the first aspect, in some embodiments, determining a second RLC status report based on first information includes: the first information being ACK feedback, and determining the content of the second RLC status report based on the first RLC status report, so as to reduce the duplicate reporting of at least some content.

[0047] In conjunction with some embodiments of the first aspect, in some embodiments, determining the content of the second RLC status report based on the first RLC status report includes: determining the reception status of N RLC SDUs and / or RLC SDU segments that is not included in the first RLC status report as the content of the second RLC status report; wherein, the reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes acknowledgment acknowledgment (ACK) status or non-acknowledgment acknowledgment (NACK) status.

[0048] In conjunction with some embodiments of the first aspect, in some embodiments, determining a second RLC status report based on the first information includes: determining that the first information is a NACK feedback or determining that the second communication device does not have a first RLC status report that needs to be fed back based on the first information, and determining the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report; wherein, the reception status of the M RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status.

[0049] In conjunction with some embodiments of the first aspect, in some embodiments, the first state variable is RX_Next, representing the receive state variable; the second state variable is RX_Highest_Status, representing the maximum STATUS send state variable.

[0050] In conjunction with some embodiments of the first aspect, in some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report.

[0051] Secondly, embodiments of this disclosure propose a method for processing status reports, which is executed by a second communication device. The method includes: sending first information to a first communication device, wherein the first information is a feedback of a first radio link control (RLC) status report sent by the first communication device; wherein the first information is used by the first communication device to determine a second RLC status report.

[0052] In conjunction with some embodiments of the second aspect, in some embodiments, sending the first information to the first communication device includes: sending one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) to the first communication device, wherein the first RLC PDU includes a first indication bit, and at least one indication bit of the one or more first RLC PDUs is used to indicate the first information.

[0053] In conjunction with some embodiments of the second aspect, in some embodiments, the at least one indication bit includes a first indication bit, which satisfies one or more of the following: the value of the first indication bit is a first value, indicating that the first information is an acknowledgment response (ACK) feedback; the value of the first indication bit is a second value, indicating that the first information is a non-acknowledgment response (NACK) feedback; the first indication bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

[0054] In conjunction with some embodiments of the second aspect, in some embodiments, the at least one indication bit includes a first indication bit, the first indication bit satisfying one or more of the following: the value of the first indication bit is a first value, indicating that the first information is ACK feedback; the value of the first indication bit is a second value, indicating that the second communication device does not have the first RLC status report that needs to be fed back or indicating that the first information is NACK feedback.

[0055] In conjunction with some embodiments of the second aspect, in some embodiments, the at least one indicator bit includes a second indicator bit that identifies a first RLC status report.

[0056] In conjunction with some embodiments of the second aspect, in some embodiments, the first RLC status report includes a third indicator bit that identifies the first RLC status report.

[0057] In conjunction with some embodiments of the second aspect, in some embodiments, the second indicator bit and the third indicator bit have the same value.

[0058] In conjunction with some embodiments of the second aspect, in some embodiments, the method further includes: determining that there is no first RLC status report that needs to be fed back, and defaulting the second indicator bit in the first RLC PDU.

[0059] In conjunction with some embodiments of the second aspect, in some embodiments, the first information is ACK feedback, and the second RLC status report includes: the reception status of N RLC SDUs and / or RLC SDU segments that is not included in the first RLC status report, wherein the reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status; or, the first information is NACK feedback or the second communication device does not have the first RLC status report that needs to be fed back, and the second RLC status report includes the reception status of M RLC SDUs and / or RLC SDU segments, wherein the reception status of the M RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status.

[0060] In conjunction with some embodiments of the second aspect, in some embodiments, the first state variable is RX_Next, representing the receive state variable; the second state variable is RX_Highest_Status, representing the maximum STATUS send state variable.

[0061] In conjunction with some embodiments of the second aspect, in some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report.

[0062] Thirdly, embodiments of this disclosure provide a first communication device, including at least one of a transceiver module and a processing module; wherein the first communication device is used to execute an optional implementation of the first aspect.

[0063] Fourthly, embodiments of this disclosure provide a second communication device, including at least one of a transceiver module and a processing module; wherein the second communication device is used to execute an optional implementation of the second aspect.

[0064] Fifthly, embodiments of this disclosure provide a communication system, including:

[0065] The first communication device is configured as an optional implementation of the aforementioned first aspect;

[0066] The second communication device is configured to perform an optional implementation of the aforementioned second aspect.

[0067] In a sixth aspect, embodiments of this disclosure provide a communication device, comprising: one or more processors; wherein the processors are configured to invoke instructions to cause the communication device to perform an optional implementation of the first aspect described above.

[0068] In a seventh aspect, embodiments of this disclosure provide a communication device, comprising: one or more processors; wherein the processors are configured to invoke instructions to cause the communication device to perform an optional implementation of the second aspect described above.

[0069] Eighthly, embodiments of this disclosure provide a storage medium storing instructions that, when executed on a communication device, cause the communication device to perform optional implementations of the first and second aspects described above.

[0070] Ninthly, embodiments of this disclosure provide a program product that, when executed by a communication device, causes the communication device to perform the method as described in the optional implementations of the first and second aspects.

[0071] In a tenth aspect, embodiments of this disclosure provide a computer program that, when run on a computer, causes the computer to perform the methods described in alternative implementations of the first and second aspects.

[0072] Eleventhly, embodiments of this disclosure provide a chip or chip system. The chip or chip system includes processing circuitry configured to perform the methods described according to optional implementations of the first and second aspects above.

[0073] It is understood that the aforementioned first communication device, second communication device, communication system, storage medium, program product, computer program, chip, or chip system are all used to execute the methods proposed in the embodiments of this disclosure. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0074] This disclosure provides a method, apparatus, communication device, and storage medium for processing status reports. In some embodiments, the terms "processing method for status reports" and "information processing method," "communication method," etc., can be used interchangeably, as can the terms "apparatus for processing status reports" and "apparatus for information processing," "communication device," etc.

[0075] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments. In all embodiments of this disclosure, unless otherwise specified or logically conflicting, the terminology and / or descriptions between the 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.

[0076] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure.

[0077] In this embodiment of the disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular expression or a plural expression.

[0078] In the embodiments disclosed herein, "multiple" refers to two or more.

[0079] In some embodiments, the terms “at least one of A or B, at least one of A and B”, “one or more”, “a plurality of”, “multiple”, etc., may be used interchangeably.

[0080] In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "in response to one case A, in response to another case B", etc., may include the following technical solutions depending on the situation: in some embodiments, A (execute A regardless of whether there is a branch B); in some embodiments, B (execute B regardless of whether there is a branch A); in some embodiments, execution is selected from A and B (A and B are selectively executed); in some embodiments, both A and B are executed. The same applies when there are more branches such as A, B, C, etc.

[0081] In some embodiments, the notation "A or B" may include the following technical solutions, depending on the situation: in some embodiments, A (execute A regardless of whether a branch B exists); in some embodiments, B (execute B regardless of whether a branch A exists); in some embodiments, execution is selected from A and B (A and B are selectively executed). The same applies when there are more branches such as A, B, and C.

[0082] The prefixes "first," "second," etc., used in the embodiments of this disclosure are merely for distinguishing different descriptive objects and do not impose restrictions on the position, order, priority, quantity, or content of the descriptive objects. The description of the descriptive objects is found in the claims or the context of the embodiments, and the use of prefixes should not constitute unnecessary restrictions. For example, if the descriptive object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the descriptive object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the number of descriptive objects is not limited by ordinal numbers and can be one or more. For example, in "first device," the number of "devices" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device", then "first device" and "second device" can be the same device or different devices, and their types can be the same or different. Similarly, if the object being described is "information", then "first information" and "second information" can be the same information or different information, and their content can be the same or different.

[0083] In some embodiments, “including A,” “containing A,” “for indicating A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0084] In some embodiments, terms such as “in response to…”, “in response to determining…”, “in the case of…”, “when…”, “when…”, “if…”, etc. can be used interchangeably. These descriptions all refer to the device making a corresponding action under certain objective circumstances. They do not necessarily limit the time, nor do they require the device to make a judgment action when implementing it, nor do they mean that there must be other limitations.

[0085] In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”.

[0086] In some embodiments, devices, etc., may be interpreted as physical or virtual, and their names are not limited to those described in the embodiments. Terms such as “device,” “equipment,” “circuit,” “network element,” “network function,” “network device,” “function,” “node,” “unit,” “section,” “system,” “network,” “chip,” “chip system,” “entity,” and “subject” are interchangeable.

[0087] In some embodiments, "network" can be interpreted as devices included in a network (e.g., access network devices, core network devices, etc.).

[0088] In some embodiments, the terms "access network device (AN device)," "radio access network device (RAN device)," "base station (BS)," "radio base station," "fixed station," "node," "access point," "transmission point (TP)," "reception point (RP)," "transmission / reception point (TRP)," "panel," "antenna panel," "antenna array," "cell," "macro cell," "small cell," "femto cell," "pico cell," "sector," "cell group," "serving cell," "carrier," "component carrier," and "bandwidth part (BWP)" can be used interchangeably.

[0089] In some embodiments, the terms "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", "subscriber station", "mobile unit", "subscriber unit", "wireless unit", "remote unit", "mobile device", "wireless device", "wireless communication device", "remote device", "mobile subscriber station", "access terminal", "mobile terminal", "wireless terminal", "remote terminal", "handset", "user agent", "mobile client", and "client" can be used interchangeably.

[0090] In some embodiments, access network devices, core network devices, or network devices can be replaced by terminals. For example, embodiments of this disclosure can also be applied to structures where communication between access network devices, core network devices, or network devices and terminals is replaced by communication between multiple terminals (e.g., device-to-device (D2D), vehicle-to-everything (V2X), etc.). In this case, the structure can also be configured such that the terminal has all or part of the functions of the access network device. Furthermore, terms such as "uplink" and "downlink" can be replaced with terms corresponding to communication between terminals (e.g., "sidelink"). For example, uplink channel, downlink channel, etc., can be replaced with sidelink channel, and uplink link, downlink, etc., can be replaced with sidelink link.

[0091] In some embodiments, the terminal may be replaced by an access network device, a core network device, or a network device. In this case, the access network device, core network device, or network device may also be configured to have all or some of the functions of the terminal.

[0092] In some embodiments, the acquisition of data, information, etc., may comply with the laws and regulations of the country where the location is situated.

[0093] In some embodiments, data, information, etc., may be obtained with the user's consent.

[0094] Furthermore, each element, each row, or each column in the table of this disclosure can be implemented as an independent embodiment, and any combination of any element, any row, or any column can also be implemented as an independent embodiment.

[0095] Figure 1 is a schematic diagram of the architecture of a communication system according to an embodiment of the present disclosure. This communication system may include, but is not limited to, one first communication device and one second communication device. The number and configuration of devices shown in Figure 1 are for illustrative purposes only and do not constitute a limitation on the embodiments of the present disclosure. In practical applications, it may include two or more first communication devices and two or more second communication devices. The communication system 100 shown in Figure 1 is exemplified by including one first communication device 101 and one second communication device 102.

[0096] In some embodiments, the first communication device 101 may be, for example, an RLC status report sender, and the second communication device 102 may be understood as an RLC status report receiver. In some embodiments, the RLC status report sender may be a network device, and the RLC status report receiver may be a terminal; that is, the first communication device 101 may be a network device, and the second communication device 102 may be a terminal. In some embodiments, the RLC status report sender may be a terminal, and the RLC status report receiver may be a network device; that is, the first communication device 101 may be a terminal, and the second communication device 102 may be a network device.

[0097] In some embodiments, the terminal in this document may be a user-side entity used to receive or transmit signals. In some embodiments, terminal 101 includes, for example, at least one of the following: mobile phone, wearable device, Internet of Things device, car with communication capabilities, smart car, tablet computer, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal device in industrial control, wireless terminal device in self-driving, wireless terminal device in remote medical surgery, wireless terminal device in smart grid, wireless terminal device in transportation safety, wireless terminal device in smart city, and wireless terminal device in smart home, but is not limited thereto.

[0098] In some embodiments, the network device may be an access network device. In some embodiments, the access network device is, for example, a node or device that connects a terminal to a wireless network. The access network device may include at least one of the following in a 5G communication system: evolved Node B (eNB), next-generation evolved Node B (ng-eNB), next-generation Node B (gNB), node B (NB), home node B (HNB), home evolved node B (HeNB), radio backhaul device, radio network controller (RNC), base station controller (BSC), base transceiver station (BTS), base band unit (BBU), mobile switching center, base station in a 6G communication system, open RAN, cloud RAN, base station in other communication systems, and access node in a Wi-Fi system, but is not limited thereto.

[0099] In some embodiments, the technical solutions of this disclosure can be applied to the Open RAN architecture. In this case, the interfaces between or within access network devices involved in the embodiments of this disclosure can be transformed into internal interfaces of Open RAN. The processes and information interactions between these internal interfaces can be implemented by software or programs.

[0100] In some embodiments, the access network device may be composed of a central unit (CU) and a distributed unit (DU). The CU may also be called a control unit. The CU-DU structure can separate the protocol layer of the access network device. Some of the protocol layer functions are centrally controlled by the CU, while the remaining part or all of the protocol layer functions are distributed in the DU and centrally controlled by the CU. However, this is not the only possibility.

[0101] It is understood that the communication system described in this disclosure is for the purpose of more clearly illustrating the technical solutions of this disclosure, and does not constitute a limitation on the technical solutions proposed in this disclosure. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions proposed in this disclosure are also applicable to similar technical problems.

[0102] The following embodiments of this disclosure can be applied to the communication system 100 shown in FIG1, or to some of the main bodies, but are not limited thereto. The main bodies shown in FIG1 are illustrative. The communication system may include all or some of the main bodies in FIG1, or may include other main bodies outside of FIG1. ​​The number and form of each main body are arbitrary. Each main body may be physical or virtual. The connection relationship between the main bodies is illustrative. The main bodies may not be connected or may be connected. The connection can be in any way, it can be a direct connection or an indirect connection, it can be a wired connection or a wireless connection.

[0103] The embodiments disclosed herein can be applied to Long Term Evolution (LTE), LTE-Advanced (LTE-A), LTE-Beyond (LTE-B), SUPER 3G, IMT-Advanced, 4th generation mobile communication system (4G), 5th generation mobile communication system (5G), 5G new radio (NR), Future Radio Access (FRA), New-Radio Access Technology (RAT), New Radio (NR), New radio access (NX), Future generation radio access (FX), Global System for Mobile communications (GSM), CDMA2000, Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), and IEEE 802.20, Ultra-Wideband (UWB), Bluetooth (a registered trademark), Public Land Mobile Network (PLMN) networks, Device-to-Device (D2D) systems, Machine-to-Machine (M2M) systems, Internet of Things (IoT) systems, Vehicle-to-Everything (V2X) systems, systems utilizing other communication methods, and next-generation systems built upon them, etc. Furthermore, multiple systems can be combined (e.g., a combination of LTE or LTE-A with 5G).

[0104] In some embodiments, a 3GPP (3rd Generation Partnership Project) Radio Link Control (RLC) entity can be configured in three modes: Transparent Mode (TM), Unacknowledged Mode (UM), or Acknowledged Mode (AM). Correspondingly, an RLC entity can be classified as a TM RLC entity, a UM RLC entity, or an AM RLC entity. An AM RLC entity can consist of a transmitting side and a receiving side. For an RLC entity configured on the network side, the terminal side is configured with an RLC peer entity, and vice versa. An RLC entity can receive RLC SDUs (Service Data Units) from upper layers and pass them to upper layers. An RLC entity can send RLC PDUs (Protocol Data Units) to or receive RLC PDUs from an RLC peer entity through lower layers. When the space provided by the MAC (Medium Access Control) layer is insufficient to transmit a complete RLC SDU, the RLC SDU is transmitted in segments, referred to as RLC SDU segments. The RLC header information may include a Segmentation Offset (SO) field, which indicates the position of the RLC SDU segment within the original RLC SDU (e.g., in bytes). For example, the SO field may indicate the position of the first byte of the RLC SDU segment in the Data field corresponding to the position in the original RLC SDU. For instance, the first byte of the original RLC SDU might correspond to an SO field value of 0, meaning the numbering starts from zero.

[0105] In some embodiments, RLC PDUs can be classified into data PDUs and control PDUs. The RLC data PDU can be used to transmit higher-layer PDUs (i.e., RLC SDUs). An RLC data PDU in UM mode can be called a UMD PDU, and an RLC data PDU in AM mode can be called an AMD PDU. The RLC control PDU can be used for ARQ (Automatic Repeat reQuest), such as RLC status reporting, which is an RLC control PDU.

[0106] In some embodiments, TM mode, also known as transparent transmission, is the simplest of the three transmission modes. The RLC layer does not process the SDUs from the upper-layer PDCP (Packet Data Convergence Protocol) and sends them directly to the MAC layer for transmission. Similarly, it does not process the PDUs received from the MAC layer and sends them directly to the PDCP. In this case, the RLC entity on the transmission side (also known as the sending side) is called the transmitting TM RLC entity, and the PDUs it transmits are called TMD PDUs. When an RLC SDU (PDCP PDU) arrives at the RLC layer, the transmitting TM RLC entity does not perform any processing and sends the RLC SDU directly to the MAC layer. In other words, in transparent transmission, an RLC SDU is a TMD PDU, and the transmitting TM RLC entity does not perform header additions, segmentation, or other processing on the TMD PDUs. Correspondingly, on the receiving side, the receiving TM RLC entity also directly sends the received TMD PDU to the PDCP layer. Since the sending end does not add a header or segment, the receiving end does not need to perform header removal, reassembly, or other operations.

[0107] In some embodiments, similar to TM mode, in UM mode, the transmitting side (also called the sending side) is called the transmitting UM RLC entity, the receiving side is called the receiving UM RLC entity, and the transmitted PDU is called the UMD PDU. The difference from TM mode is that although UM is an Unacknowledged mode, meaning it doesn't guarantee correct transmission, it is more complex than TM mode. The sending side needs to segment (if necessary) and add headers to the RLC SDU to construct the UMD PDU, and the receiving side correspondingly needs to remove the headers and reassemble (if necessary) the UMD PDU. Segmentation and reassembly occur because the MAC layer informs the UM RLC entity of the size limit of the UMD PDU that the MAC layer can receive. Due to this size limitation, for excessively large RLC SDUs, a single PDU may not be able to contain a complete SDU when constructing a UMD PDU. Therefore, the RLC SDU needs to be segmented into multiple RLC SDU segments. Each PDU's data field contains only one RLC SDU segment, and a header is added to construct a UMD PDU before it is sent to the MAC layer for transmission. Therefore, segmentation / reassembly and adding / removing headers are the main differences between UM mode and TM mode.

[0108] In some embodiments, similar to UM mode, AM RLC entities in AM mode also undergo segmentation and reassembly, as well as header addition and removal, when necessary. The first difference from TM and UM modes is that AM mode is bidirectional, so AM RLC entities are not divided into transmitting and receiving AM RLC entities, but rather referred to as the transmitting side and receiving side of the AM RLC entity. However, this is merely a difference in protocol terminology; in general discussions, they can still be simply understood as the transmitting and receiving ends.

[0109] In some embodiments, the second difference from TM / UM mode is that AM mode is an Acknowledgement Mode. To ensure the correctness of data transmission, the sender must retransmit as necessary based on the receiver's reception status. The transmitted data PDU is called an AMD PDU, and the transmitted control PDU is called a STATUS PDU (status report). The receiver informs the sender of the reception status (also known as reception status) of the RLC SDU by feeding back the STATUS PDU. The STATUS PDU has higher priority than the AMD PDU, and retransmitted RLC SDUs and / or RLC SDU segments have higher priority than newly transmitted RLC SDUs and / or RLC SDU segments. Other differences lie in the data transmission process.

[0110] In some embodiments, an AM RLC entity needs to maintain some state variables, timers, and counters. The following is a list of all the state variables of the transmitting device:

[0111] a) TX_Next_Ack indicates the acknowledgment status variable;

[0112] For example, the value of this state variable can be the SN (Sequence Number) of the next SDU awaiting acknowledgment (ACK) message, which serves as the lower boundary of the sending window. The initial value is 0. For instance, if AMD PDUs with SNs of 1, 2, and 3 have all received feedback from the receiver and have been correctly received, then TX_Next_Ack = 4, indicating that the sender expects the next SDU awaiting acknowledgment (ACK) message to have an SN of 4. Even if the sender receives an SDU with ACK SN = 5, TX_Next_Ack will remain equal to 4 as long as it hasn't received an SDU with ACK SN = 4. The TX_Next_Ack variable will only be updated after ensuring that the AMD PDU with SN = 4 has been correctly received.

[0113] b) TX_Next indicates the transmission status variable;

[0114] For example, the value of this state variable can be the SN value to be assigned to the next newly constructed AMD PDU, for instance, with an initial value of 0. This variable is updated when the AM RLC entity constructs a PDU containing an SDU or the last segment of an SDU with SN = TX_Next. For example, if an RLC SDU with SN = 1, 2, 3 has been constructed and sent, then TX_Next = 4, the SN value to be assigned to the next newly constructed AMD PDU. Once an RLC SDU with SN = 4 is sent, TX_Next = 5 is updated; this behavior does not change whether an ACK for an SDU with SN = 4 is received. Every AMD PDU has SN = TX_Next, regardless of whether the AMD PDU contains a complete RLC SDU or an RLC SDU segment. TX_Next = TX_Next + 1 is updated when an AMD PDU contains a complete RLC SDU or the last segment of an RLC SDU.

[0115] c) POLL_SN indicates the polling and sending status variables;

[0116] For example, the value of this state variable can be the maximum SN value among all AMD PDUs currently sent to the lower layer (such as the MAC layer). This state variable is updated when the polling field in the sent PDU is 1.

[0117] In other words, the aforementioned state variable TX_Next is the sequence number of the PDU, while TX_Next_Ack indicates where the transmission has reached correctly. The sending end maintains a transmission window with the following range based on the state variable TX_Next_Ack:

[0118] TX_Next_Ack<=SN <TX_Next_Ack+AM_Window_Size

[0119] In other words, AMD PDUs whose SN values ​​fall outside the transmission window will not be transmitted. TX_Next_Ack can be the lower boundary of the transmission window, which is driven by the correct transmission of the AMD PDU. AM_Window_Size is the window size, a constant, such as 2048 for a 12-bit SN and 131072 for an 18-bit SN.

[0120] When the transmitting end receives feedback from a certain RLC SDU, it can indicate to the PDCP layer that the RLC SDU has been correctly received, and set the state variable TX_Next_Ack to the next SN that is expected to receive an ACK, that is, the smallest SN within the range TX_Next_Ack<=SN<=TX_Next that has not yet received an ACK.

[0121] In some embodiments, the receiver may maintain the following state variables:

[0122] a) RX_Next indicates that the received status variable is being received;

[0123] For example, the value of this state variable can be the SN value of the SDUs that have been received in complete order + 1, that is, the next smallest SN that the receiver expects to receive. It can be used as the lower boundary of the receiving window, for example, with an initial value of 0. When an RLC SDU with SN = RX_Next is received, this state variable is updated. For example, if SN = 1, 2, and 3 have been received, then RX_Next = 4. Even if an SDU with SN = 5 has been received, as long as an SDU with SN = 4 has not been received, RX_Next will still be equal to 4.

[0124] b) RX_Next_Status_Trigger, representing the t-Reassembly (reassembly timer) status variable;

[0125] For example, this state variable can store the value of SN+1 of the RLC SDU that triggered t-Reassembly. For example, this state variable is updated immediately upon starting t-Reassembly.

[0126] c)RX_Highest_Status indicates the highest STATUS sent status variable;

[0127] For example, this state variable stores the highest possible SN value that can be identified by "ACK_SN" when the STATUS PDU is constructed. The state variable RX_Highest_Status can be updated in the following two cases: Case 1) when an SDU with the same SN value is fully received, the state variable RX_Highest_Status is updated; Case 2) when the t-Reassembly times out.

[0128] d) RX_Next_Highest, representing the highest received state variable;

[0129] For example, the state variable can store: the highest value of SN in the received RLC SDU + 1.

[0130] It's worth noting that the status variable RX_Next can point to the SN value of the next SDU awaiting acknowledgment. SDUs with SN values ​​less than RX_Next have already been acknowledged. The status variable RX_Next_Highest can point to the highest SN value among the currently received PDUs plus 1. If there are still SDUs unacknowledged before the value of RX_Next_Highest and after the value of RX_Next, the t-Reassembly timer needs to be started. t-Reassembly can be a timer waiting for SDUs that were not previously fully received. If t-Reassembly is stopped and reset, it means that all previous SDUs were successfully received during this period. If t-Reassembly times out, it means that some SDUs could not be fully received, thus causing the receiver to actively send a STATUS report to the sender. The status variable RX_Next_Status_Trigger is updated when t-Reassembly is started, indicating which SN of the SDU must be fully received before the task within that t-Reassembly period is considered complete. The status variable RX_Highest_Status can be updated when t-Reassembly times out, indicating which SDUs need to be retransmitted.

[0131] It should be noted that in some embodiments, the receiving end can maintain a receiving window based on the state variable RX_Next, and the following formula represents the range of the receiving window:

[0132] RX_Next<=SN <RX_Next+AM_Window_Size

[0133] Similar to the transmit window, RX_Next is the lower boundary of the receive window, which is "pushed" by the correct reception of the SN. This differs from the reassembly window in UM mode, where the upper boundary of the reassembly window is adjusted by the received SN.

[0134] When an AMD PDU is received, the AM RLC entity will discard it or place it in the reception buffer as appropriate. Specifically: if the SN is not within the receive window or is a previously received duplicate SN, it is discarded; otherwise, AMD PDUs containing RLC SDU segments are placed in the reception buffer. For example, as shown in Figure 2A, SNs 0, 1, 2, and 4 have been correctly received, RX_Next = 3, and the receive window size (AM_Window_Size) is assumed to be 4. Therefore, the receiving window range is [3, 7). So, if an SN < 3 or SN ≥ 7 is received, it is discarded; if SN = 4 is received again, it is discarded; if an AMD PDU containing RLC SDU segments with SN = 3, 5, or 6 is received, it is placed in the reception buffer.

[0135] For an AMD PDU placed in the reception buffer, the AM RLC entity can perform the following operations: update RX_Next_Highest (if needed); check if the RLC SDU corresponding to the SN placed in the reception buffer has been fully received (or completely received). If fully received, reassemble, remove the header, and immediately send it to the PDCP layer; update the status variables RX_Highest_Status and / or RX_Next (if needed), with the updated value being the next smallest SN that has not yet been fully received and is greater than the original value. For example, based on the above as shown in Figure 2A, as shown in Figure 2B, if the received SN=3 and has been fully received, then update RX_Next=5; as shown in Figure 2C, if the received SN=5 and has been fully received, then update RX_Highest_Status=6.

[0136] It should be noted that the AM mode also involves the timer t-Reassembly. However, the start / stop conditions differ slightly from those in UM mode. In some embodiments, the start condition for t-Reassembly may include either of the following: a) RX_Next_Highest > RX_Next + 1; b) RX_Next_Highest = RX_Next + 1 and the RLC SDU with SN = RX_Next has not yet been fully acquired. In other words, t-Reassembly can only be started because a new AMD PDU arrives, causing RX_Next_Highest to be updated, thus satisfying the start condition.

[0137] In some embodiments, the stop conditions for t-Reassembly may include any one of the following: a) RX_Next_Status_Trigger = RX_Next; b) RX_Next_Status_Trigger = RX_Next + 1 and the RLC SDU with SN = RX_Next has been completely received; c) RX_Next_Status_Trigger has fallen out of the receive window and RX_Next_Status_Trigger ≠ RX_Next + AM_Window_Size. Among them, stop condition a) and stop condition b) can be understood as the correct reception of the data packet resulting in an update of RX_Next, thus satisfying the stop condition.

[0138] In some embodiments, when t-Reassembly times out, that is, it is considered unnecessary to wait any longer, the status variable RX_Highest_Status can be updated. Because during the operation of t-Reassembly, RX_Next has not been updated to a condition that can satisfy the stop of t-Reassembly, and at this time, it is considered that the reception fails, so RX_Next will be stuck. At this time, the updated RX_Highest_Status will replace RX_Next to determine whether t-Reassembly needs to be started again. Otherwise, if judged by RX_Next, the start condition of t-Reassembly will surely be satisfied. Therefore, the start conditions after t-Reassembly times out include any one of the following: a) RX_Next_Highest > RX_Highest_Status + 1; b) RX_Next_Highest = RX_Highest_Status + 1 and the RLC SDU with SN = RX_Highest_Status has not been completely received.

[0139] In some embodiments, there are two cases for triggering the RLC status report:

[0140] Case (1), triggered by the receiving device after receiving the Polling (polling) from the sending device; for example, if the receiving device receives Polling and this AMD PDU of the Polling is discarded; or when the SN of this AMD PDU satisfies SN < RX_Highest_Status or SN >= RX_Next + AM_Window_Size, a STATUS report is triggered. Otherwise, it is not triggered temporarily until the SN satisfies the condition.

[0141] Case (2), which is triggered when the receiving device has missing SDUs and / or SDU segments. For example, when the receiving device detects missing SDUs or SDU segments, it starts the t-Reassembly timer. When the t-Reassembly timer expires, a status report is triggered.

[0142] In some embodiments, once a status report is triggered, the receiving device may also consider the status of the t-StatusProhibit timer to determine when to send a STATUS PDU. That is, if t-StatusProhibit is not running, the STATUS PDU is sent at the nearest transmission opportunity indicated by the MAC layer (the priority of the STATUS PDU is higher than that of the AMD PDU); if t-StatusProhibit is running, the STATUS PDU needs to be transmitted at the nearest transmission opportunity after t-StatusProhibit expires. Once a STATUS PDU is sent, t-StatusProhibit is started. This can avoid frequent reporting.

[0143] In some embodiments, when constructing a status report (STATUS PDU), first, for RLC SDUs with SN in the range RX_Next <= SN < RX_Highest_Status and not fully received, the STATUS PDU is constructed in ascending order of SN and subject to the requirement that the size of the finally formed STATUS PDU does not exceed the limit. The situation of incomplete reception or reception failure is further divided into the following types:

[0144] (1) For an RLC SDU for which no segment has been received, when constructing the STATUS PDU, the NACK_SN of the RLC SDU is included.

[0145] (2) For an incompletely received RLC SDU for which some consecutive segments t have not been received, when constructing the STATUS PDU, the NACK_SN of the RLC SDU, as well as SOstart and SOend, are included. SOstart represents the starting position of the incompletely received RLC SDU segment in the original RLC SDU, and SOend represents the ending position of the incompletely received RLC SDU segment in the original RLC SDU.

[0146] (3) For some consecutive unreceived RLC SDUs, when constructing the STATUS PDU, it contains a series of NACK_SN and NACK range, and if necessary, it also contains a pair of SOstart and SOend. Among them, NACK_SN represents the sequence number of the RLC SDU that was not fully received, and NACK range represents the number of consecutive unreceived RLC SDUs in the incompletely received RLC SDUs.

[0147] (4) When constructing a STATUS PDU, the ACK_SN can be set to the SN of the next unreceived RLC SDU.

[0148] For example, as shown in Figure 2D, the receiving device receives data packet number 3 (also known as an RLC SDU or RLC SDU segment). Since A (i.e., state variable RX_Highest_Status) = 3, A (i.e., state variable RX_Highest_Status) is not updated to 3. Similarly, since B (i.e., state variable RX_Next) = 3, B is also not updated to 3. However, D (i.e., state variable RX_Next_Highest) > B + 1, so t-Reassembly (the timer in Figure 2D) is started. Simultaneously, C (i.e., state variable RX_Next_Status_Trigger) is updated to D, meaning C changes from 0 to 4. When the receiving device receives data packet number 7, t-Reassembly times out. A is updated to the SN of the first RLC SDU that has not received all bytes, which is 5 as shown in Figure 2D, where SN is greater than or equal to C. After updating A, D > A + 1 is still satisfied, so t-Reassembly is restarted. During t-Reassembly, the device waits for data packet 5.

[0149] For example, the receiving device receives Packet 7, and the t-Reassembly times out, triggering a status report (i.e., the RLC status report), and reporting the ACK / NACK of RX_Next <= SN < RX_Highest_Status, that is: the status reports of Packets 2, 3, and 4. However, there are no status reports of Packets 5, 6, and 7 in the status report. Since Packet 5 is not received, t-Reassembly is restarted. If the t-Reassembly for waiting for Packet 5 times out and Packet 5 is not received, the status report will be triggered again, and then the status report will be reported again. Since RX_Next is used as the lower edge and will only move when the packet is received, the ACK / NACK of the packets that have been reported before may be repeatedly reported each time the status report is triggered. Because the RLC status report reports the ACK / NACK of RX_Next <= SN < RX_Highest_Status. For example, RX_Highest_Status is continuously updated, but RX_Next remains unchanged. Even if RX_Next changes, the RLC status report may still contain the ACK / NACK of the packets that have been reported before. For example, at the moment of Packet 7, t-Reassembly is restarted. Assume that the t-Reassembly times out and triggers the RLC status report again. Assume that Packet 2 is not fully received at this time and RX_Next remains unchanged. The RLC status report triggered this time needs to report the ACK / NACK of RX_Next <= SN < RX_Highest_Status, but RX_Next still remains 2, and RX_Highest_Status may have been updated. For example, if Packets 8, 9, 10, and 12 are received, RX_Highest_Status is updated to 11.

[0150] Based on this, the embodiments of the present disclosure provide a method for processing a status report, which supports the receiving device of the RLC status report to feedback on the RLC status report. The RLC status report sending device can optimize the content in the new RLC status report according to the feedback. That is, by enhancing the RLC status report, the problem of repeated reporting of the same content during the RLC status reporting in the prior art can be solved, thereby improving the efficiency and reliability of the wireless communication system.

[0151] FIG. 3 is an interaction schematic diagram of the method for processing a status report according to an embodiment of the present disclosure. As shown in FIG. 3, the method for processing a status report according to an embodiment of the present disclosure can be applied to a communication system 100. The above method includes but is not limited to the following steps.

[0152] Step S3101, send the first information.

[0153] In some embodiments, the first information may be sent by the second communication device 102. For example, the second communication device 102 may send the first information to the first communication device 101, and correspondingly, the first communication device 101 receives the first information sent by the second communication device 102. In some embodiments, the first communication device 101 may be, for example, an RLC status report sender, and the second communication device 102 may be understood as an RLC status report receiver. In some embodiments, the RLC status report sender may be a network device, and the RLC status report receiver may be a terminal; that is, the first communication device 101 may be a network device, and the second communication device 102 may be a terminal. In some embodiments, the RLC status report sender may be a terminal, and the RLC status report receiver may be a network device; that is, the first communication device 101 may be a terminal, and the second communication device 102 may be a network device.

[0154] In some embodiments, the first information may be information sent by the second communication device 102 after receiving the first RLC status report sent by the first communication device 101.

[0155] In some embodiments, the first RLC status report may be, for example, an RLC status report already sent by the first communication device 101. In some embodiments, the first RLC status report may be triggered by the second communication device 102 through polling. For example, the second communication device 102 sends an RLC PDU to the first communication device 101, and correspondingly, the first communication device 101 receives the RLC PDU sent by the second communication device 102. The RLC PDU carries polling information, which can instruct the first communication device 101 to generate and send an RLC status report to the second communication device 102, thus triggering the first RLC status report.

[0156] In some embodiments, the first RLC status report may be triggered when the first communication device 101 detects an AMD PDU reception failure. For example, the first RLC status report is triggered when a second timer (i.e., a timer that needs to be started when the first communication device has incompletely received RLC SDUs and / or RLC SDU segments, such as a t-Reassembly timer) times out.

[0157] Optionally, the first communication device 101 may identify the first RLC status report using a third indicator bit. In some embodiments, the first RLC status report sent by the first communication device 101 may include a third indicator bit, which can be used to identify the first RLC status report. For example, the third indicator bit may be a reserved bit (or reserved area bit) in the first RLC status report. The third indicator bit is defined by using the reserved bit in the first RLC status report, and the first RLC status report is identified by the third indicator bit. In some embodiments, the proportion of the third indicator bit may be 1 bit, but it is not limited thereto. For example, it may occupy 2 bits or more, and this disclosure does not specifically limit it. For example, taking the third indicator bit as occupying 1 bit, the first communication device 101 flips this bit every time it sends an RLC status report (such as the first RLC status report). For example, taking the initial value of the third indicator bit as 0, the first communication device 101 can set the value of the third indicator bit to 0 when sending the RLC status report for the first time, set the value of the third indicator bit to 1 when sending the RLC status report for the second time, set the value of the third indicator bit to 0 when sending the RLC status report for the third time, and so on. For example, taking the initial value of the third indicator bit as 1, the first communication device 101 can set the value of the third indicator bit to 1 when sending the RLC status report for the first time, set the value of the third indicator bit to 0 when sending the RLC status report for the second time, set the value of the third indicator bit to 1 when sending the RLC status report for the third time, and so on. For example, when the third indicator bit is 1 bit, as shown in Figures 4A and 4B, this third indicator bit can be located at the "E4" position of the third byte (Oct 3) in both a STATUS PDU carrying a 12-bit SN and a STATUS PDU carrying an 18-bit SN. It should be noted that Figures 4A and 4B are merely examples for ease of understanding. The position of this third indicator bit in the RLC status report, and how the third indicator bit is used to identify the first RLC status report, may have other forms. This disclosure does not impose specific limitations on these forms, nor will it elaborate further.

[0158] For example, taking the initial value of the third indicator bit as 0, the first communication device 101 can set the value of the third indicator bit to 1 when sending the RLC status report for the first time, set the value of the third indicator bit to 0 when sending the RLC status report for the second time, set the value of the third indicator bit to 1 when sending the RLC status report for the third time, and so on. Thus, when the third indicator bit occupies 1 bit, different RLC status reports can be identified by bit flipping.

[0159] For example, taking the third indicator bit as occupying 3 bits, an RLC report can be identified by one of the following: 000, 001, 010, 011, 100, 101, 110, and 111. For instance, 000 identifies RLC status report a, 001 identifies RLC status report b, 010 identifies RLC status report c, 011 identifies RLC status report d, 100 identifies RLC status report e, 101 identifies RLC status report f, 110 identifies RLC status report g, and 111 identifies RLC status report k. Here, RLC status reports a, b, ..., k can be different RLC status reports. It should be noted that the example of the number of bits occupied by the third indicator bit is provided to facilitate understanding of this disclosure by those skilled in the art, but it is not limited thereto. That is, the number of bits occupied by the third indicator bit can also be other values; the number of bits occupied by the third indicator bit can be determined according to the actual application, and this disclosure does not specifically limit this.

[0160] In some embodiments, the first information may be feedback on a first RLC status report sent by the first communication device 101. In some embodiments, this feedback may include, but is not limited to, acknowledgment (ACK) feedback and non-acknowledgment (NACK) feedback; that is, the first information may include ACK feedback on the first RLC status report, or the first information may include NACK feedback on the first RLC status report. For example, if the second communication device 102 determines that it has received the first RLC status report sent by the first communication device 101, the second communication device 102 may send first information to the first communication device 101, which may include ACK feedback on the first RLC status report. For example, if the second communication device 102 determines that it has not received the first RLC status report or determines that the reception of the first RLC status report has failed, the second communication device 102 may send first information to the first communication device 101, which may include NACK feedback on the first RLC status report.

[0161] Optionally, the first information can be carried in an RLC PDU. For example, the first information can be carried in an RLC AMD PDU. In some embodiments, the second communication device 102 sends one or more first RLC PDUs, and correspondingly, the first communication device 101 can receive the one or more first RLC PDUs sent by the second communication device 102. The one or more first RLC PDUs can include a first indication bit, which can be used to indicate the first information. For example, after receiving the first RLC status report from the first communication device 101, the second communication device 102 can indicate the first information (i.e., indicate feedback on the first RLC status report) in one or more subsequently sent first RLC PDUs through the first indication bit. The sending of one or more first RLC PDUs by the second communication device 102 can be understood as the second communication device 102 determining, after receiving the first RLC status report from the first communication device 101, that there is data to be sent. This data may not be fully transmitted through a single RLC PDU and may require multiple RLC PDUs. One possible implementation is that each of the one or more first RLC PDUs sent by the second communication device 102 may include the first indicator bit to indicate the first information. Another possible implementation is that after receiving the first RLC status report from the first communication device 101, at least one of the one or more first RLC PDUs sent by the second communication device 102 includes the first indicator bit to indicate the first information. The specific number of RLC PDUs containing the first indicator bit can be determined by the second communication device 102 according to its implementation; this disclosure does not impose specific limitations.

[0162] In some embodiments, the first indicator bit can be a reserved bit (or reserved area bit) in the first RLC PDU. The first indicator bit is defined by using the reserved bit in the first RLC PDU and indicates the first information. In some embodiments, the proportion of the first indicator bit can be 1 bit, but is not limited thereto. For example, it can also be 2 or more bits, and this disclosure does not limit this. In some embodiments, the position of the first indicator bit in the first RLC PDU, for example as shown in FIG4C, can be the bit position after the SI field in the first RLC PDU, but is not limited thereto, and this disclosure does not limit this either.

[0163] Optionally, in some embodiments, when the feedback of the RLC status report supports both ACK and NACK feedback mechanisms, the first indicator bit can be set to a first value, which can be used to indicate that the first information is ACK feedback; the first indicator bit can be set to a second value, which can be used to indicate that the first information is NACK feedback; the first indicator bit can be omitted, which can be used to indicate that the second communication device 102 does not have a first RLC status report that needs to be fed back. For example, the first communication device 101 sent the first RLC status report, but the second communication device 102 did not receive the first RLC status report sent by the first communication device 101. Here, "the second communication device 102 did not receive the first RLC status report sent by the first communication device 101" means that the first RLC status report needs to be retransmitted, that is, the first communication device 101 sent the first RLC status report. The first indicator bit is omitted in one or more first RLC PDUs received by the first communication device 101, which is equivalent to the first information being NACK feedback. Another scenario is that the second communication device 102 does not have an RLC status report that needs to be fed back (such as the first RLC status report sent by the first communication device 101). For example, if the second communication device 102 sends one or more first RLC PDUs before receiving the first RLC status report (such as the first RLC status report), the first indicator bit can be omitted (i.e., if the first communication device 101 has not sent an RLC status report to the second communication device 102 before, and the second communication device 102 sends one or more first RLC PDUs to the first communication device 101, then the first indicator bit in those one or more first RLC PDUs can be omitted). Accordingly, the first communication device 101 knows that it has not sent an RLC status report to the second communication device 102. Therefore, when it receives one or more first RLC PDUs sent by the second communication device 102, if the one or more first RLC PDUs... If the first indicator bit in the PDU is missing, it can be determined that the second communication device 102 has not received an RLC status report sent by the first communication device 101, or that the second communication device 102 has no RLC status report that needs to be fed back, or that the first communication device 101 has not sent an RLC status report.

[0164] Continuing with the example of the ACK and NACK feedback mechanisms for RLC status reports, in another possible implementation, one or more first RLC PDUs may contain a first indicator bit. The specific number of RLC PDUs containing the first indicator bit is determined by the second communication device. In this case, first RLC PDUs that do not contain the first indicator bit are not used to indicate that a first RLC status report has not been received; instead, they indicate nothing. For example, the first indicator bit may be included in one of the one or more first RLC PDUs, and this first indicator bit in that one RLC PDU may be used to indicate feedback on the first RLC status report. For example, the value of the first indicator bit in the RLC PDU is a first value, which can indicate that the first information is ACK feedback, that is, the feedback to the first RLC status report is ACK feedback; the value of the first indicator bit in the RLC PDU is a second value, which can indicate that the first information is NACK feedback, that is, the feedback to the first RLC status report is NACK feedback; the first indicator bit in the RLC PDU is defaulted, which can indicate that the second communication device 102 does not have a first RLC status report that needs to be fed back, that is, the second communication device 102 has already determined that it is no longer necessary to feed back the first RLC status report.

[0165] For example, the second communication device 102 sends one or more first RLC PDUs, and correspondingly, the first communication device 101 can receive the one or more first RLC PDUs sent by the second communication device 102. The one or more first RLC PDUs may include a first indicator bit, which indicates the first information. If the value of the first indicator bit is a first value, the first communication device 101 can determine that the first information is an ACK feedback, that is, the feedback from the second communication device 102 to the first RLC status report sent by the first communication device 101 is an ACK feedback, meaning the second communication device 102 confirms that it has successfully received the first RLC status report sent by the first communication device 101. Optionally, if the value of the first indicator bit is a second value, the first communication device 101 can determine that the first information is a NACK feedback, that is, the feedback from the second communication device 102 to the first RLC status report sent by the first communication device 101 is a NACK feedback, such as the second communication device 102 confirming that the decoding of the first RLC status report sent by the first communication device 101 failed. Optionally, if the first indicator bit is omitted in the first RLC PDU, the first communication device 101 can determine that the second communication device 102 does not have a first RLC status report that needs to be fed back. In some embodiments, the first value can be 1 and the second value can be 0; or the first value can be 0 and the second value can be 1; or the first value and the second value can also be represented by other values. This disclosure does not specifically limit them and will not elaborate further.

[0166] In some embodiments, the first indication bit can be set to a first value, which can be used to indicate that the first information is ACK feedback; the first indication bit can be set to a second value, which can be used to indicate that the second communication device 102 does not have a first RLC status report that needs to be fed back, or can be used to indicate that the first information is NACK feedback.

[0167] For example, the second communication device 102 sends one or more first RLC PDUs, and correspondingly, the first communication device 101 can receive the one or more first RLC PDUs sent by the second communication device 102. The one or more first RLC PDUs may include a first indicator bit, which can indicate the first information. If the value of the first indicator bit is a first value, the first communication device 101 can determine that the first information is an ACK feedback, that is, the feedback from the second communication device 102 to the first RLC status report sent by the first communication device 101 is an ACK feedback, meaning the second communication device 102 confirms that it has successfully received the first RLC status report sent by the first communication device 101. Optionally, if the value of the first indicator bit is the second value, the first communication device 101 can determine that the second communication device 102 does not have a first RLC status report that needs to be fed back; or, if the value of the first indicator bit is the second value, the first communication device 101 can determine that the first information is a NACK feedback, that is: the feedback of the second communication device 102 to the first RLC status report sent by the first communication device 101 is a NACK feedback, such as the second communication device 102 confirming that the decoding of the first RLC status report sent by the first communication device 101 failed.

[0168] Optionally, a first RLC status report may be identified in the first RLC PDU. In some embodiments, the first RLC PDU may include a second indicator bit, which can be used to identify the first RLC status report. For example, as shown in FIG4C, the second indicator bit is located at the reserved bits "E4" and "E5" of the first byte (Oct1) of an AMD PDU carrying an 18-bit SN (No SO). However, it is not limited to this and may be located in other positions. This disclosure does not specifically limit this. It should be noted that the number of bits occupied by the second indicator bit and its position in the RLC PDU shown in FIG4C are merely an example for the convenience of those skilled in the art and should not be regarded as a specific limitation of this disclosure. In some embodiments, for an RLC PDU without reserved bits, it may be extended by one byte, and the remaining bits besides the first and second indicator bits can be padded with reserved R bits. In some embodiments, the second indicator bit can be omitted. For example, when the second communication device 102 does not receive the first RLC status report, the second indicator bit in the first RLC PDU sent by the second communication device 102 can be omitted. For example, the second indicator bit can be omitted in one or more first RLC PDUs sent by the second communication device 102 before receiving the first RLC status report. Correspondingly, when the first communication device 101 receives the first RLC PDU sent by the second communication device 102 and determines that the second indicator bit in the first RLC PDU is omitted, the first communication device 101 can determine that the second communication device 102 does not have a first RLC status report that needs to be fed back. In other words, the timing of the transmission of the one or more first RLC PDUs is before the timing of the transmission of the first RLC status report. Therefore, if the first communication device 101 receives the one or more first RLC PDUs sent by the second communication device 102 before sending the first RLC status report, the one or more first RLC PDUs... If the second indicator bit in the PDU is missing, the first communication device 101 can determine that the second communication device 102 has not received the first RLC status report, or in other words, the second communication device 102 has no first RLC status report to feed back. In another possible implementation, where the first indicator bit is included in one or more RLC PDUs, and the specific number of RLC PDUs containing the first indicator bit is implemented by the second communication device, then RLC PDUs that do not contain the first indicator bit are not used to indicate that the first RLC status report has not been received; they indicate nothing at all.In other words, in some embodiments, "the second communication device 102 does not have a first RLC status report that needs to be fed back" can be understood as: the second communication device 102 did not receive the first RLC status report sent by the first communication device 101; or, it can also mean: the second communication device 102 does not need to feed back the first RLC status report.

[0169] Optionally, in some embodiments, when only ACK feedback mechanism and default are supported for feedback of RLC status reports, the first indicator bit can be set to a fourth value, which can be used to indicate that the first information is ACK feedback. If the first indicator bit is defaulted, it can be used to indicate that the first information is NACK feedback, for example, indicating that the first RLC status report was received incorrectly (such as decoding failure) or to indicate that the second communication device 102 does not have a first RLC status report that needs to be fed back, for example, indicating that the first RLC status report was not received. Optionally, "not receiving the first RLC status report" here can mean that the first RLC status report needs to be retransmitted, that is, the first communication device 101 sent the first RLC status report. If the first indicator bit is defaulted in one or more first RLC PDUs received by the first communication device 101, it is equivalent to the first information being NACK feedback. Another scenario is that the second communication device 102 does not have an RLC status report (such as a first RLC status report) sent by the first communication device that needs to be fed back. For example, if the second communication device 102 sends one or more first RLC PDUs before receiving the first RLC status report (such as a first RLC status report), the first indicator bit can be omitted (i.e., if the first communication device 101 has not sent an RLC status report to the second communication device 102 before, and the second communication device 102 sends one or more first RLC PDUs to the first communication device 101 first, then the first indicator bit in those one or more first RLC PDUs can be omitted). Accordingly, the first communication device 101 knows that it has not sent an RLC status report to the second communication device 102, and when it receives one or more first RLC PDUs sent by the second communication device 102, if the one or more first RLC PDUs... If the first indicator bit in the PDU is missing, it can be determined that the second communication device 102 has not received an RLC status report sent by the first communication device 101, or that the second communication device 102 has no RLC status report to feed back, or that the first communication device 101 has not sent an RLC status report. In one possible implementation, each of the one or more first RLC PDUs sent by the second communication device 102 may include the first indicator bit to indicate the first information.In another possible implementation, after receiving the first RLC status report from the first communication device 101, the second communication device 102 sends at least one of the one or more first RLC PDUs containing the first indication bit to indicate the first information. The specific number of RLC PDUs containing the first indication bit can be determined by the second communication device 102 according to the implementation, and this disclosure does not impose a specific limitation. In this case, the first RLC PDUs that do not contain the first indication bit are not used to indicate that the first RLC status report has not been received, but do not indicate anything. The first RLC PDUs that do not contain the first indication bit do not need to indicate feedback on the first RLC status report.

[0170] For example, continuing with the case where feedback on RLC status reports only supports the ACK feedback mechanism and is defaulted, the second communication device 102 sends one or more first RLC PDUs. Correspondingly, the first communication device 101 can receive the one or more first RLC PDUs sent by the second communication device 102. The one or more first RLC PDUs may contain a first indicator bit, which indicates the first information. If the value of the first indicator bit is a fourth value, the first communication device 101 can determine that the first information is an ACK feedback, that is, the feedback from the second communication device 102 to the first RLC status report sent by the first communication device 101 is an ACK feedback, meaning the second communication device 102 confirms that it has successfully received the first RLC status report sent by the first communication device 101. Optionally, if the first indicator bit is omitted in the first RLC PDU, the first communication device 101 can determine that the first information is a NACK feedback or determine that the second communication device 102 has no first RLC status report that needs to be fed back.

[0171] Optionally, in some embodiments, when the feedback to the RLC status report only supports the NACK feedback mechanism and is the default, the first indicator bit can be set to a fifth value, which can be used to indicate that the first information is NACK feedback, for example, indicating that the first RLC status report reception was incorrect (such as decoding failure); the first indicator bit is defaulted and can be used to indicate that the first information is ACK feedback. In one possible implementation, each of the one or more first RLC PDUs sent by the second communication device 102 may include the first indicator bit to indicate the first information. In another possible implementation, after receiving the first RLC status report from the first communication device 101, the second communication device 102 sends at least one of the one or more first RLC PDUs containing the first indication bit to indicate the first information. The specific number of RLC PDUs containing the first indication bit can be determined by the second communication device 102 according to the implementation, and this disclosure does not impose a specific limitation. In this case, the first RLC PDUs that do not contain the first indication bit are not used to indicate that the first RLC status report has not been received, but do not indicate anything. The first RLC PDUs that do not contain the first indication bit do not need to indicate feedback on the first RLC status report.

[0172] For example, continuing with the case where feedback to the RLC status report only supports the NACK feedback mechanism and is the default, the second communication device 102 sends one or more first RLC PDUs. Correspondingly, the first communication device 101 can receive the one or more first RLC PDUs sent by the second communication device 102. The one or more first RLC PDUs may contain a first indicator bit, which indicates the first information. If the value of the first indicator bit is a fifth value, the first communication device 101 can determine that the first information is a NACK feedback. Optionally, if the first indicator bit is omitted in the first RLC PDU, the first communication device 101 can determine that the first information is an ACK feedback, that is, determine that the feedback from the second communication device 102 to the first RLC status report sent by the first communication device 101 is an ACK feedback.

[0173] In some embodiments, the second indicator bit in the first RLC PDU may have the same value as the third indicator bit in the first RLC status report. In this way, the first information included in the first RLC PDU can be determined as a feedback to the first RLC status report by using the second indicator bit and the third indicator bit. For example, if the second indicator bit in the first RLC PDU has the same value as the third indicator bit in the first RLC status report, then the first information included in the first RLC PDU can be considered as a feedback to the first RLC status report. For example, if the second communication device 102 confirms that it has successfully received (e.g., successfully decoded) the first RLC status report sent by the first communication device 101, or confirms that it has failed to receive (e.g., failed to decode) the first RLC status report sent by the first communication device 101, then one or more first RLC PDUs sent by the second communication device 102 to the first communication device 101 may include a second indicator bit for identifying the first RLC status report. Correspondingly, the first communication device 101 may receive one or more first RLC PDUs sent by the second communication device 102, wherein the one or more first RLC PDUs include a second indicator bit for identifying the first RLC status report, and the value of the second indicator bit is the same as the value of the third indicator bit in the first RLC status report. Then the first communication device 101 may consider that the one or more first RLC PDUs include feedback on the first RLC status report. For example, the first communication device 101 can determine whether the one or more RLC PDUs contain feedback on the first RLC report by using the second indicator bit, then determine whether the feedback is ACK or NACK (implemented by the indication of the first indicator bit). For instance, if the one or more RLC PDUs received by the first communication device 101 contain the second indicator bit, it indicates that the first indicator bit is present. If the one or more RLC PDUs received by the first communication device 101 do not contain the second indicator bit, there is no need to check the first information, because the first information is meaningless, and the first communication device 101 can directly determine that the second communication device believes there is no RLC report that needs to be fed back.

[0174] In one possible implementation, the first communication device 101 sends a first RLC status report to the second communication device 102. If the second communication device 102 does not receive the first RLC status report, then the second indicator bit in one or more first RLC PDUs sent by the second communication device 102 to the first communication device 101 is missing. In this case, when the first communication device 101 receives the one or more first RLC PDUs, it can determine that the second communication device 102 has not received the first RLC status report because the second indicator bit is missing in the one or more first RLC PDUs. The first communication device 101 can consider the feedback to the first RLC status report included in the one or more first RLC PDUs as NACK. For example, if all RLC PDUs between the first and second RLC status reports are missing the second indicator bit, then the first communication device 101 can consider the feedback from the second communication device 102 to the RLC status reports sent by the first communication device 101 as NACK feedback, or it can consider that the second communication device 102 has no RLC status reports that need to be fed back.

[0175] In another possible implementation, the first communication device 101 sends a first RLC status report, and the second communication device 102 successfully receives the first RLC status report. The second communication device 102 has already informed the first communication device 101 of the ACK / NACK feedback for the first RLC status report through multiple RLC PDUs (i.e., through the indication of the first indicator bit). Therefore, some subsequent RLC PDUs may omit the second indicator bit, and the first communication device 101 can assume that the feedback from the second communication device 102 for the first RLC status report is either ACK or NACK (because there is already an indication from a received RLC PDU). In this implementation, the default second indicator bit can indicate that there is no RLC status report requiring feedback.

[0176] In some embodiments, the second indicator bit in the first RLC PDU may have a different value than the third indicator bit in the first RLC status report. However, the second indicator bit in the first RLC PDU may have a mapping relationship with the third indicator bit in the first RLC status report. Thus, the mapping relationship between the second and third indicator bits can be used to determine whether the first information included in the first RLC PDU is a feedback to the first RLC status report. For example, if the mapping relationship between the second indicator bit in the first RLC PDU and the third indicator bit in the first RLC status report is correct, then the first information included in the first RLC PDU can be considered a feedback to the first RLC status report.

[0177] In some embodiments, the second communication device 102 may indicate ACK or NACK feedback of the first RLC status report in one or more RLC PDUs via a first indicator bit and / or a second indicator bit. For example, if the first communication device 101 sends a first RLC status report to the second communication device 102, and the second communication device 102 does not receive the first RLC status report, the second indicator bit may be omitted from one or more first RLC PDUs sent by the second communication device 102 to the first communication device 101. Correspondingly, the first communication device 101 may receive the one or more first RLC PDUs sent by the second communication device 102. If the first communication device 101 determines that the second indicator bit is omitted from the one or more first RLC PDUs, the first communication device 101 may determine that the second communication device 102 has not received the first RLC status report sent by the first communication device 101. For example, a first communication device 101 sends a first RLC status report, and a second communication device 102 successfully receives the first RLC status report. The second communication device 102 may send one or more first RLC PDUs to the first communication device 101, including a second indicator bit (to identify the first RLC status report). The one or more first RLC PDUs may also include a first indicator bit, which indicates the feedback to the first RLC status report. Correspondingly, the first communication device 101 may receive the one or more first RLC PDUs sent by the second communication device 102. If the first communication device 101 determines that the value of the second indicator bit in the one or more first RLC PDUs matches the value of the third indicator bit in the first RLC status report (e.g., they are the same, or the mapping relationship between the two is correct), then the first communication device 101 may determine that the one or more first RLC PDUs include feedback to the first RLC status report. Then, the first indicator bit in the one or more first RLC PDUs may be used to determine whether the feedback to the first RLC status report is ACK feedback or NACK feedback.

[0178] In some embodiments, the first information described above can be used by the first communication device 101 to determine the content of the second RLC status report. In some embodiments, the second RLC status report can be, for example, the next RLC status report to be constructed following the first RLC status report. For example, the first communication device 101 sends the first RLC status report to the second communication device 102, and the second communication device 102 can provide feedback on the first RLC status report. For example, the second communication device 102 can send first information to the first communication device 101, which is a feedback on the first RLC status report sent by the first communication device 101. Accordingly, upon receiving the first information, the first communication device 101 can determine the content of the second RLC status report (such as the next RLC status report to be constructed following the first RLC status report) based on the first information.

[0179] Step S3102: The first information is ACK feedback, and the content of the second RLC status report is determined based on the first RLC status report.

[0180] In some embodiments, the first communication device 101 receives first information sent by the second communication device 102 and can determine whether the first information is an ACK feedback. For example, if the first information is an ACK feedback, the first communication device 101 can determine the content of the second RLC status report based on the first RLC status report.

[0181] In some embodiments, the second RLC status report may be the next generated RLC status report following the first RLC status report. For example, the first RLC status report may be understood as the RLC status report that the first communication device 101 has sent to the second communication device 102, and the second RLC status report is the next generated RLC status report following the first RLC status report.

[0182] In some embodiments, the second RLC status report may be triggered by the second communication device 102 through polling. For example, the second communication device 102 sends an RLC PDU to the first communication device 101, and correspondingly, the first communication device 101 receives the RLC PDU sent by the second communication device 102. The RLC PDU carries polling information, which can instruct the first communication device 101 to generate and send an RLC status report to the second communication device 102, thus triggering the second RLC status report.

[0183] In some embodiments, the second RLC status report may be triggered when the first communication device 101 detects an AMD PDU reception failure. For example, the second RLC status report is triggered when a second timer (i.e., a timer that needs to be started when the first communication device has incompletely received RLC SDUs and / or RLC SDU segments, such as a t-Reassembly timer) times out.

[0184] It should be noted that in some embodiments, step S3102 can be applied to the RLC status report generation scenario. For example, when the first communication device 101 generates the second RLC status report, the first communication device 101 can determine the content of the second RLC status report. For instance, when the second RLC status report is triggered, the first communication device 101 can determine whether the first timer (such as a status prohibition timer (t-StatusProhibit)) is running. If the first timer is not running, the first communication device 101 generates the second RLC status report at the first transmission opportunity indicated by the underlying layer and submits it to the underlying layer, such as the MAC layer. When generating the second RLC status report, the first communication device 101 can determine the content of the second RLC status report. Optionally, when the second RLC status report is triggered, the first communication device 101 can determine whether the first timer (such as the status prohibit timer (t-StatusProhibit)) is running. If the first timer is running, after the first timer expires, the first communication device 101 generates the second RLC status report at the first transmission opportunity indicated by the lower layer and submits it to the lower layer, such as the MAC layer. During the operation of the first timer, even if the second RLC status report is triggered multiple times, the first communication device 101 will only generate one second RLC status report.

[0185] Optionally, the second RLC status report can be determined based on the first information sent by the second communication device 102. In some embodiments, the first communication device 101 receives the first information sent by the second communication device 102 and can determine the content of the second RLC status report based on the first information.

[0186] It should be noted that, because the content of the first information is different, the method for determining the content of the second RLC status report will also be different. In some embodiments, the first communication device 101 determines that the first information is an ACK feedback, and the first communication device 101 can determine the content of the second RLC status report based on the first RLC status report. For example, the second RLC status report only includes the reception status of RLC SDUs and / or RLC SDU segments that were not reported in the previously sent first RLC status report.

[0187] In one possible implementation, when the first information is an ACK feedback, the first communication device 101 can determine the reception status of N RLC SDUs and / or RLC SDU segments that is not included in the first RLC status report as content in the second RLC status report. This reception status can include either an ACK status or a NACK status. For example, the first communication device 101 determines the reception status of N RLC SDUs and / or RLC SDU segments. These N RLC SDUs and / or RLC SDU segments can be RLC SDUs and / or RLC SDU segments where SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. This reception status includes either an ACK status or a NACK status. If the first communication device 101 determines that the reception status of K RLC SDUs and / or RLC SDU segments is already included in the first RLC status report, the first communication device 101 will not include the reception status of these K RLC SDUs and / or RLC SDU segments in the second RLC status report. The first status variable can be RX_Next, representing the reception status variable; the second status variable can be RX_Highest_Status, representing the maximum STATUS transmission status variable. For example, the last RLC status report reported by the first communication device 101 was the reception status of data packets 2 to 10. When a new RLC status report is triggered and generated, the SNs of data packets with SNs greater than or equal to RX_NEXT and less than RX_Highest_Status are determined to be 6 to 15. Since the repeated statuses between data packets 6 to 15 and data packets 2 to 10 do not need to be reported again, for example, if data packets 7 and 8 between data packets 2 and 10 are both NACK, and data packets 7 and 8 have associated SO start and SO end, then it is not necessary to report NACK_SN(7) and SO start and SO end of 7, or NACK_SN(8) and SO start and SO end of 8 again.

[0188] Optionally, in some embodiments, if the reception status of these N RLC SDUs and / or RLC SDU segments is not included in the first RLC status report, the reception status of these N RLC SDUs and / or RLC SDU segments is reported (N is actually equal to M, because they are all within the range determined by the first and second status variables). For example, the last RLC status report reported by the first communication device 101 was the reception status of data packets 2 to 10. When a new RLC status report is triggered and generated, the SNs of data packets with SNs greater than or equal to RX_NEXT and less than RX_Highest_Status are determined to be 14 to 25. Since there are no duplicate data packets between data packets 2 to 10 and data packets 14 to 25, the reception status between data packets 14 to 25 is included in the new RLC status report.

[0189] For example, if the first communication device 101 determines that the first information is an ACK feedback (that is, the feedback from the first communication device 101 to the first RLC status report is an ACK feedback), the first communication device 101 can determine the reception status of RLC SDUs and / or RLC SDU segments between SN greater than or equal to RX_Next and less than RX_Highest_Status, and which are not included in the first RLC status report, as the content of the second RLC status report. In other words, the second RLC status report only includes the reception status of RLC SDUs and / or RLC SDU segments that were not reported in the first RLC status report. That is, the content of the second RLC status report is not included in the first RLC status report. For example, if at least one of NACK_SN, SO start, and SO end has been reported in the first RLC status report, then it will not be reported in the second RLC status report.

[0190] It should be noted that in some embodiments, the aforementioned first information may be carried in one or more first RLC PDUs sent by the second communication device 102, but is not limited thereto. Alternatively, the first information may be a newly defined signaling, and the content indicated by the first information can be determined by the value of the first information. In some embodiments, taking the first information carried in one or more first RLC PDUs sent by the second communication device 102 as an example, the first communication device 101 may determine the feedback status of the first RLC status report based on the second indicator bit in one or more first RLC PDUs sent by the second communication device 102. For example, after the first communication device 101 sends the first RLC status report, during the production (generation) of the second RLC status report by the first communication device, if the second indicator bit in one or more first RLC PDUs received by the first communication device 101 is missing, it can be determined that the second communication device 102 has not received the first RLC status report. The first communication device 101 may consider the first information to be equivalent to NACK feedback in this case. Optionally, the first communication device 101 may determine whether the first information is an ACK feedback or a NACK feedback based on the first indicator bit and the second indicator bit in one or more first RLC PDUs sent by the second communication device 102 (i.e., determine whether the feedback of the second communication device 102 to the first RLC status report is an ACK feedback or a NACK feedback). For example, the first communication device 101 may determine that the value of the second indicator bit in the one or more first RLC PDUs matches the value of the third indicator bit in the first RLC status report. The first communication device 101 may determine that the one or more first RLC PDUs include feedback to the first RLC status report. The first communication device 101 may determine the value of the first indicator bit in the one or more first RLC PDUs and determine whether the first information is an ACK feedback or a NACK feedback. For example, if the first indicator bit is a first value, the first information is determined to be an ACK feedback; if the first indicator bit is a second value, the first information is determined to be a NACK feedback.

[0191] For example, taking the first information carried in one or more first RLC PDUs sent by the second communication device 102 as an example, if only the first indicator bit is supported, and the feedback of the RLC status report supports both ACK and NACK feedback mechanisms, then the first communication device 101 can determine the feedback status of the first RLC status report based on the first indicator bit in one or more first RLC PDUs sent by the second communication device 102. For instance, after the first communication device 101 sends the first RLC status report, during the generation of the second RLC status report, if the value of the first indicator bit in one or more first RLC PDUs received by the first communication device 101 is a first value, the first communication device 101 can determine that the first information is ACK feedback, thus determining that the feedback of the second communication device 102 to the first RLC status report is ACK feedback. If the value of the first indicator bit in one or more first RLC PDUs received by the first communication device 101 is a second value, the first communication device 101 can determine that the first information is NACK feedback, thus determining that the feedback of the second communication device 102 to the first RLC status report is NACK feedback. If the first indication bit is missing in one or more first RLC PDUs received by the first communication device 101, the first communication device 101 can determine that the second communication device 102 does not have a first RLC status report that needs to be fed back, such as determining that the second communication device 102 has not received the first RLC status report.

[0192] For example, taking the first information carried in one or more first RLC PDUs sent by the second communication device 102 as an example, if only the first indicator bit is supported, and the feedback to the RLC status report only supports the ACK feedback mechanism and the default, then the first communication device 101 can determine the feedback status of the first RLC status report based on the first indicator bit in one or more first RLC PDUs sent by the second communication device 102. For instance, after the first communication device 101 sends the first RLC status report, during the production (generation) of the second RLC status report by the first communication device, if the value of the first indicator bit in one or more first RLC PDUs received by the first communication device 101 is the fourth value, the first communication device 101 can determine that the first information is ACK feedback, and thus determine that the feedback from the second communication device 102 to the first RLC status report is ACK feedback. If the first indication bit is missing in one or more first RLC PDUs received by the first communication device 101, the first communication device 101 may determine that the first information is a NACK feedback (such as a first RLC status report receiving error (such as decoding failure)) or may determine that the second communication device 102 does not have a first RLC status report that needs to be fed back (such as not receiving the first RLC status report).

[0193] For example, taking the first information carried in one or more first RLC PDUs sent by the second communication device 102 as an example, if only the first indicator bit is supported, and the feedback to the RLC status report only supports the NACK feedback mechanism and the default, then the first communication device 101 can determine the feedback status of the first RLC status report based on the first indicator bit in one or more first RLC PDUs sent by the second communication device 102. For instance, after the first communication device 101 sends the first RLC status report, during the generation of the second RLC status report, if the first indicator bit in one or more first RLC PDUs received by the first communication device 101 has the fifth value, the first communication device 101 can determine that the first information is a NACK feedback, such as a first RLC status report reception error (e.g., decoding failure). If the first indicator bit in one or more first RLC PDUs received by the first communication device 101 is defaulted, the first communication device 101 can determine that the first information is an ACK feedback, and thus determine that the feedback from the second communication device 102 to the first RLC status report is an ACK feedback.

[0194] It should be noted that in some embodiments, when the first communication device 101 receives the first information sent by the second communication device 102, if the first communication device 101 determines that the first information is an ACK feedback, it can execute the above step S3102, that is, determine the content of the second RLC status report based on the first RLC status report. If the first communication device 101 determines that the first information is a NACK feedback, or if the first communication device 101 determines based on the first information that the second communication device does not have a first RLC status report that needs to be fed back, it can execute the following step S3103.

[0195] Step S3103: Determine if the first information is NACK feedback or if the second communication device does not have a first RLC status report that needs to be fed back based on the first information, and determine the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report.

[0196] In some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report. For example, the first RLC status report can be understood as an RLC status report that the first communication device 101 has sent to the second communication device 102, and the second RLC status report is the next generated RLC status report following the first RLC status report.

[0197] In some embodiments, the second RLC status report may be triggered by the second communication device 102 through polling. For example, the second communication device 102 sends an RLC PDU to the first communication device 101, and correspondingly, the first communication device 101 receives the RLC PDU sent by the second communication device 102. The RLC PDU carries polling information, which can instruct the first communication device 101 to generate and send an RLC status report to the second communication device 102, thus triggering the second RLC status report.

[0198] In some embodiments, the second RLC status report may be triggered when the first communication device 101 detects an AMD PDU reception failure. For example, the second RLC status report is triggered when a second timer (i.e., a timer that needs to be started when the first communication device has incompletely received RLC SDUs and / or RLC SDU segments, such as a t-Reassembly timer) times out.

[0199] It should be noted that in some embodiments, step S3103 can be applied to the RLC status report generation scenario. For example, when the first communication device 101 generates the second RLC status report, the first communication device 101 can determine the content of the second RLC status report. For instance, when the second RLC status report is triggered, the first communication device 101 can determine whether the first timer (such as a status prohibition timer (t-StatusProhibit)) is running. If the first timer is not running, the first communication device 101 generates the second RLC status report at the first transmission opportunity indicated by the underlying layer and submits it to the underlying layer, such as the MAC layer. When generating the second RLC status report, the first communication device 101 can determine the content of the second RLC status report. Optionally, when the second RLC status report is triggered, the first communication device 101 can determine whether the first timer (such as the status prohibit timer (t-StatusProhibit)) is running. If the first timer is running, after the first timer expires, the first communication device 101 generates the second RLC status report at the first transmission opportunity indicated by the lower layer and submits it to the lower layer, such as the MAC layer. During the operation of the first timer, even if the second RLC status report is triggered multiple times, the first communication device 101 will only generate one second RLC status report.

[0200] Optionally, the second RLC status report can be determined based on the first information sent by the second communication device 102. In some embodiments, the first communication device 101 receives the first information sent by the second communication device 102 and can determine the content of the second RLC status report based on the first information.

[0201] It should be noted that the determination method for the content of the second RLC status report will also differ depending on the content of the first information. In some embodiments, if the first communication device 101 determines that the first information is a NACK feedback or that the second communication device has not received the first RLC status report (i.e., the second communication device does not have a first RLC status report that needs to be fed back), the reception status of M RLC SDUs and / or RLC SDU segments will be determined as the content of the second RLC status report. For example, if the first communication device 101 determines that the first information is a NACK feedback, the first communication device 101 can determine the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report. For example, if the first communication device 101 determines that the second communication device has not received the first RLC status report, the first communication device 101 can determine the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report.

[0202] In some embodiments, the reception status of the aforementioned M RLC SDUs and / or RLC SDU segments may include: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of a first status variable and less than the value of a second status variable. This reception status may include an ACK status or a NACK status. The first status variable may be RX_Next, representing a reception status variable; the second status variable may be RX_Highest_Status, representing a maximum STATUS transmission status variable.

[0203] For example, if the first communication device 101 determines that the first information is a NACK feedback or determines that the second communication device 102 has not received the first RLC status report (i.e., the second communication device does not have a first RLC status report that needs to be fed back), the first communication device 101 may determine the reception status (including ACK status or NACK status) of the RLC SDU and / or RLC SDU segments between SN greater than or equal to RX_Next and less than RX_Highest_Status as the content of the second RLC status report.

[0204] It should be noted that in some embodiments, the aforementioned first information may be carried in one or more first RLC PDUs sent by the second communication device 102, but is not limited thereto. Alternatively, the first information may be a newly defined signaling, and the content indicated by the first information can be determined by the value of the first information. In some embodiments, taking the example that the aforementioned first information is carried in one or more first RLC PDUs sent by the second communication device 102, the first communication device 101 may determine the feedback status of the first RLC status report based on the second indicator bit in one or more first RLC PDUs sent by the second communication device 102. For example, after the first communication device 101 sends the first RLC status report, during the production of the second RLC status report by the first communication device, if the second indicator bit in one or more first RLC PDUs received by the first communication device 101 is missing, it can be determined that the second communication device 102 has not received the first RLC status report. The first communication device 101 may consider that the first information in this case is equivalent to NACK feedback. Optionally, the first communication device 101 may determine whether the first information is an ACK feedback or a NACK feedback based on the first indicator bit and the second indicator bit in one or more first RLC PDUs sent by the second communication device 102 (i.e., determine whether the feedback of the second communication device 102 to the first RLC status report is an ACK feedback or a NACK feedback). For example, the first communication device 101 may determine that the value of the second indicator bit in the one or more first RLC PDUs matches the value of the third indicator bit in the first RLC status report. The first communication device 101 may determine that the one or more first RLC PDUs include feedback to the first RLC status report. The first communication device 101 may determine the value of the first indicator bit in the one or more first RLC PDUs and determine whether the first information is an ACK feedback or a NACK feedback. For example, if the first indicator bit is a first value, the first information is determined to be an ACK feedback; if the first indicator bit is a second value, the first information is determined to be a NACK feedback.

[0205] In some embodiments, whether the second indicator bit in the first RLC PDU is missing can be used to determine whether the second communication device 102 needs to provide a first RLC status report. For example, if the first communication device 101 receives a first RLC PDU sent by the second communication device 102 and determines that the second indicator bit in the first RLC PDU is missing, then the first communication device 101 can determine that the second communication device 102 does not need to provide a first RLC status report.

[0206] It should be noted that in some embodiments, if only the first indicator bit is supported, and the feedback of the RLC status report supports both ACK and NACK feedback mechanisms, the implementation method of how the first communication device 101 determines the feedback status of the second communication device 102 on the first RLC status report can be found in the relevant description in step S3102 above, and will not be repeated here.

[0207] In some embodiments, if only the first indicator bit is supported, the feedback to the RLC status report only supports the ACK feedback mechanism and the default. The implementation method of how the first communication device 101 determines the feedback status of the second communication device 102 to the first RLC status report can be found in the relevant description in step S3102 above, and will not be repeated here.

[0208] In some embodiments, if only the first indicator bit is supported, the feedback to the RLC status report only supports the NACK feedback mechanism and the default. The implementation method of how the first communication device 101 determines the feedback status of the second communication device 102 to the first RLC status report can be found in the relevant description in step S3102 above, and will not be repeated here.

[0209] It should be noted that in some embodiments, steps S3102 and S3103 are not executed simultaneously. For example, when the first information is an ACK feedback, step S3102 is executed, i.e., the content of the second RLC status report is determined based on the first RLC status report. When the first information is a NACK feedback or the second communication device does not have a first RLC status report requiring feedback, step S3103 is executed, i.e., the reception status of M RLC SDUs and / or RLC SDU segments is determined as the content of the second RLC status report. This may include: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. This reception status may include an ACK status or a NACK status.

[0210] In some embodiments, the names of information, etc., are not limited to the names described in the embodiments. Terms such as "information", "message", "signal", "signaling", "report", "configuration", "indication", "instruction", "command", "channel", "parameter", "domain", "field", "symbol", "symbol", "codebook", "codeword", "codepoint", "bit", "data", "program", and "chip" can be used interchangeably.

[0211] In some embodiments, “get,” “obtain,” “receive,” “transmit,” “bidirectional transmission,” and “send and / or receive” can be used interchangeably and can be interpreted as receiving from other entities, obtaining from protocols, obtaining from higher layers, obtaining through self-processing, or autonomous implementation, among other meanings.

[0212] In some embodiments, terms such as “send,” “transmit,” “report,” “distribute,” “transfer,” “bidirectional transmission,” “send and / or receive” can be used interchangeably.

[0213] In some embodiments, terms such as "certain," "preset," "default," "set," "indicated," "a certain," "any," and "first" can be used interchangeably. "Certain A," "preset A," "default A," "set A," "indicated A," "a certain A," "any A," and "first A" can be interpreted as A pre-defined in a protocol or the like, or as A obtained through setting, configuration, or instruction, or as specific A, a certain A, any A, or first A, but are not limited thereto.

[0214] In some embodiments, the determination or judgment can be made by a value represented by 1 bit (0 or 1), or by a true or false value (boolean), or by a comparison of numerical values ​​(e.g., a comparison with a predetermined value), but is not limited thereto.

[0215] The method involved in the embodiments of this disclosure may include at least one of steps S3101 to S3103. For example, step S3101 may be implemented as a standalone embodiment, step S3102 may be implemented as a standalone embodiment, step S3101 + step S3102 may be implemented as a standalone embodiment, step S3103 may be implemented as a standalone embodiment, or step S3101 + step S3103 may be implemented as a standalone embodiment, but is not limited thereto.

[0216] In some embodiments, steps S3102 and S3103 are optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0217] In some embodiments, steps S3101 and S3103 are optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0218] In some embodiments, step S3103 is optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0219] In some embodiments, steps S3101 and S3102 are optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0220] In some embodiments, step S3102 is optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0221] In some embodiments, other alternative implementations may be described before or after the specification corresponding to FIG3A.

[0222] Figure 5 is an interactive schematic diagram of a status report processing method according to an embodiment of the present disclosure. As shown in Figure 5, the status report processing method of the present disclosure can be applied to a communication system 100, and the method includes, but is not limited to, the following steps.

[0223] Step S5101: Send the first message.

[0224] In some embodiments, the first information may be sent by the second communication device 102. For example, the second communication device 102 may send the first information to the first communication device 101, and correspondingly, the first communication device 101 receives the first information sent by the second communication device 102. In some embodiments, the first information may be feedback on a first RLC status report sent by the first communication device 101.

[0225] In some embodiments, the second communication device 102 sends one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) to the first communication device 101, and correspondingly, the first communication device 101 receives the one or more first RLC PDUs sent by the second communication device 102. Each first RLC PDU includes at least one indicator bit, and the at least one indicator bit of the one or more first RLC PDUs is used to indicate first information.

[0226] In some embodiments, the at least one indication bit includes a first indication bit, which satisfies one or more of the following: the value of the first indication bit is a first value, which can indicate that the first information is ACK feedback; the value of the first indication bit is a second value, which can indicate that the first information is NACK feedback, or indicate that the second communication device does not have a first RLC status report that needs to be fed back; the first indication bit is defaulted, which can indicate that the second communication device does not have a first RLC status report that needs to be fed back.

[0227] In some embodiments, the at least one indicator bit may include a second indicator bit that identifies a first RLC status report. In some embodiments, the first RLC status report may include a third indicator bit that identifies the first RLC status report. In some embodiments, the values ​​of the second and third indicator bits may be the same.

[0228] In some embodiments, the second indicator bit in the first RLC PDU is omitted, which can indicate that the second communication device does not need to provide a first RLC status report. For example, if the second communication device 102 determines that there is no first RLC status report to provide, then the second communication device 102 can omit the second indicator bit in the first RLC PDU, i.e., the first RLC PDU omits the second indicator bit. If the first communication device 101 receives the first RLC PDU and determines that the second indicator bit is omitted in the first RLC PDU, then the first communication device 101 can determine that the second communication device 102 has not received the first RLC status report sent by the first communication device 101.

[0229] Step S5102: Determine the second RLC status report based on the first information.

[0230] In some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report.

[0231] In some embodiments, the first communication device 101 determines the first information as ACK feedback. The first communication device 101 can determine the content of the second RLC status report based on the first RLC status report to reduce the duplicate reporting of at least some content. In some embodiments, the first communication device 101 can determine the reception status of N RLC SDUs and / or RLC SDU segments that are not included in the first RLC status report as the content of the second RLC status report; wherein, the reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status. Wherein, the first status variable can be RX_Next, representing the reception status variable; the second status variable can be RX_Highest_Status, representing the maximum STATUS transmission status variable.

[0232] In some embodiments, if the first communication device 101 determines that the first information is a NACK feedback or determines based on the first information that the second communication device has no first RLC status report that needs to be fed back, the first communication device 101 may determine the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report; wherein, the reception status of the M RLC SDUs and / or RLC SDU segments may include: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status may include ACK status or NACK status. The first status variable may be RX_Next, representing the reception status variable; the second status variable may be RX_Highest_Status, representing the maximum STATUS transmission status variable.

[0233] Optional implementations of the methods involved in the embodiments of this disclosure can be found in the description of the relevant steps in the embodiment shown in Figure 3 above, and will not be repeated here.

[0234] The method involved in the embodiments of this disclosure may include at least one of steps S5101 and S5102. For example, step S5101 may be implemented as a standalone embodiment, step S5102 may be implemented as a standalone embodiment, and step S5101 + step S5102 may be implemented as a standalone embodiment, but is not limited thereto.

[0235] In some embodiments, step S5102 is optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0236] In some embodiments, step S5101 is optional, and one or more of these steps may be omitted or substituted in different embodiments.

[0237] It is worth noting that this disclosure provides an RLC status report feedback method, which supports the RLC status report receiver to provide feedback on the RLC status report. The RLC status report sender can reduce the duplicate reporting of some contents in the RLC status report based on this feedback. The following will describe the method in detail with reference to the embodiments.

[0238] In some embodiments, the second communication device and / or the first communication device identify the first report via a third indicator bit.

[0239] For example, the first report is an RLC status report. For example, a third indicator bit is defined in the first report to identify the first report. The number of bits occupied by this third indicator bit is not specifically limited; for example, it can be a 1-bit indicator bit. For example, the first communication device flips this bit after each transmission of the first report. For example, the third indicator bit is initially 0. When the first communication device transmits the first report, it sets the third indicator bit to 1. When the first communication device transmits the first report a second time, it sets the third indicator bit to 0. When the first communication device transmits the first report a third time, it sets the third indicator bit to 1, and so on. For example, the third indicator bit is initially 1. When the first communication device transmits the first report, it sets the third indicator bit to 0. When the first communication device transmits the first report a second time, it sets the third indicator bit to 1. When the first communication device transmits the first report a third time, it sets the third indicator bit to 0, and so on. For example, when the third indicator bit is 1 bit, the position of the third indicator bit is shown in Figures 4A and 4B below (12-bit SN and 18-bit SN). It should be noted that this is just an example. The percentage of the third indicator bit, the position of the third indicator bit in the first report, and how to identify the first report through the third indicator bit may also be in other forms. This disclosure does not make specific limitations.

[0240] In some embodiments, the second communication device may send first information (also called first feedback) to the first communication device. This first feedback is a response to a first report sent by the first communication device.

[0241] For example, the second communication device is a network device, and the first communication device is a terminal. Alternatively, the second communication device is a terminal, and the first communication device is a network device. The first report is an RLC status report. The first report may be triggered by the second communication device via polling. Alternatively, the first report may be triggered by the first communication device when it detects an AMD PDU reception failure; for example, the first report is triggered when a first timer times out. For example, the first timer is a t-Reassembly timer.

[0242] For example, the first feedback may include ACK feedback and / or NACK feedback. For example, ACK and / or NACK feedback may be indicated by indication information. For example, a first indication bit is defined in the first RLC PDU (such as an AMD PDU), for example, E5 as shown in Figure 4C (or another name). This first indication bit is set to a first value to indicate ACK feedback, and the first indication bit is set to a second value to indicate NACK feedback. For example, the first value is 1 and the second value is 0, or the first value is 0 and the second value is 1. The first indication bit may be omitted; for example, when no first report is received, the first indication bit may be omitted in the first RLC PDU sent. Another possible implementation is that the first indication bit being set to a first value can be used to indicate ACK feedback, and the first indication bit being set to a second value can be used to indicate that no first report or NACK feedback has been received. The proportion of the first indication bit and its position in the first RLC PDU are not specifically limited in this disclosure.

[0243] For example, the first RLC PDU (such as an AMD PDU) may include a second indicator bit, which is used to identify the first report. The value of the second indicator bit can be the same as the value of the third indicator bit. For example, E4 (or other naming conventions) shown in Figure 4C. The second indicator bit can be omitted; for example, when no first report is received, the second indicator bit in the first RLC PDU can be omitted. For example, if the second communication device receives the first report from the first communication device, and the second indicator bit in the first report is set to the third value, the second communication device in the first RLC PDU will also be set to the third value. It should be noted that Figure 4C is only an example of 18 bits without SO. Example diagrams of 12 bits without SO, 12 bits with SO, and 18 bits with SO are similar to those in Figure 4C and will not be described again here. For RLC PDUs without R bits (reserved bits), one byte can be added, and the remaining bits except for the first and second indicator bits can be padded with R bits.

[0244] For example, after receiving the first report from the first communication device, the second communication device may indicate the ACK / NACK feedback of the first report in one or more subsequent first RLC PDUs through the first indicator bit and / or the second indicator bit.

[0245] In some embodiments, the first communication device may determine the content of the first report based on the first feedback.

[0246] For example, if the second timer times out (e.g., T-prohibit, or t-StatusProhibit), and a first report is triggered, and the first communication device determines that the first feedback of the previously sent first report was an ACK feedback, then the first communication device can report the ACK and / or NACK status of data packets with SN numbers greater than or equal to RX_NEXT and less than RX_HighestStatus. This newly triggered first report only includes the ACK and / or NACK status of data packets not reported in the previously sent first report. For example, if at least one of NACK_SN, SO start, or SO end was already reported in the previously sent first report, this newly triggered first report will not report it again.

[0247] For example, if the second timer times out, and the second timer is T-prohibit, and the first report is triggered, and the first communication device determines that the first feedback of the first report sent last time was not ACK (e.g., it could be NACK feedback or the first report was not received, by default), then the first communication device can report the ACK and / or NACK status of data packets with SN numbers greater than or equal to RX_NEXT and less than RX_HighestStatus.

[0248] In some embodiments, the steps and their optional implementations in other embodiments described before or after this embodiment, as well as other related parts in the specification, can be referred to, and will not be repeated here.

[0249] This disclosure also proposes an apparatus (also referred to as a communication device, etc.) for implementing any of the above methods. For example, an apparatus is proposed that includes units or modules for implementing the steps performed by the terminal in any of the above methods. Furthermore, another apparatus is proposed that includes units or modules for implementing the steps performed by a network device (e.g., an access network device, a core network functional node, a core network device, etc.) in any of the above methods.

[0250] It should be understood that the division of units or modules in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units or modules in the device can be implemented by a processor calling software: for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units or modules in the above device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits. The functionality of some or all of the units or modules can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC). The functionality of some or all of the units or modules is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD). Taking a field-programmable gate array (FPGA) as an example, it can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby achieving the functionality of some or all of the units or modules. All units or modules of the above device can be implemented entirely through processor-called software, entirely through hardware circuits, or partially through processor-called software with the remaining parts implemented through hardware circuits.

[0251] In this embodiment, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a Neural Network Processing Unit (NPU), a Tensor Processing Unit (TPU), or a Deep Learning Processing Unit (DPU).

[0252] Figure 6A is a schematic diagram of the structure of a first communication device according to an embodiment of this disclosure. The first communication device 6100 is used to perform any of the above methods. In some embodiments, as shown in Figure 6A, the first communication device 6100 may include at least one of a transceiver module 6101, a processing module 6102, etc. In some embodiments, the transceiver module 6101 is used to receive first information sent by a second communication device, the first information being feedback on a first Radio Link Control (RLC) status report sent by the first communication device; the processing module 6102 is used to determine the content of the second RLC status report based on the first information.

[0253] In some embodiments, the transceiver module 6101 is configured to: receive one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) sent by the second communication device, wherein the first RLC PDU includes at least one indicator bit, and the at least one indicator bit of the one or more first RLC PDUs is used to indicate first information.

[0254] In some embodiments, the at least one indication bit includes a first indication bit, which satisfies one or more of the following: the value of the first indication bit is a first value, indicating that the first information is an acknowledgment response (ACK) feedback; the value of the first indication bit is a second value, indicating that the first information is a non-acknowledgment response (NACK) feedback, or indicating that the second communication device does not have a first RLC status report that needs to be fed back; the first indication bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

[0255] In some embodiments, the at least one indicator bit includes a second indicator bit that identifies a first RLC status report. In some embodiments, the first RLC status report includes a third indicator bit that identifies the first RLC status report. In some embodiments, the second indicator bit and the third indicator bit have the same value.

[0256] In some embodiments, the second indicator bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

[0257] In some embodiments, the processing module 6102 is used to: firstly provide ACK feedback, and then determine the contents of the second RLC status report based on the first RLC status report.

[0258] In some embodiments, the processing module 6102 is configured to: determine the reception status of N RLC SDUs and / or RLC SDU segments that are not included in the first RLC status report as content in the second RLC status report; wherein, the reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes acknowledgment acknowledgment (ACK) status or non-acknowledgment acknowledgment (NACK) status.

[0259] In some embodiments, the processing module 6102 is configured to: determine that the first information is NACK feedback or determine that the second communication device does not have a first RLC status report that needs to be fed back based on the first information, and determine the reception status of M RLC SDUs and / or RLC SDU segments as the content of the second RLC status report; wherein, the reception status of the M RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status.

[0260] In some embodiments, the first status variable is RX_Next, which represents the receive status variable; the second status variable is RX_Highest_Status, which represents the maximum STATUS sent status variable.

[0261] In some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report.

[0262] Optionally, the transceiver module is used to perform at least one of the communication steps such as sending and / or receiving performed by the first communication device 101 in any of the above methods, which will not be elaborated here. Optionally, the processing module is used to perform at least one of the other steps (such as step S3102, step S3103, step S5102, but not limited thereto) performed by the first communication device 101 in any of the above methods, which will not be elaborated here.

[0263] Figure 6B is a schematic diagram of the structure of the second communication device proposed in an embodiment of this disclosure. The second communication device 6200 is used to perform any of the above methods. In some embodiments, as shown in Figure 6B, the second communication device 6200 may include at least one of a transceiver module 6201, a processing module 6202, etc. In some embodiments, the transceiver module 6201 is used to send first information to the first communication device, the first information being feedback on a first Radio Link Control (RLC) status report sent by the first communication device; wherein, the first information is used by the first communication device to determine the content of the second RLC status report.

[0264] In some embodiments, the transceiver module 6201 is configured to: send one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) to the first communication device, wherein the first RLC PDU includes at least one indicator bit, and at least one indicator bit of the one or more first RLC PDUs is used to indicate first information.

[0265] In some embodiments, the at least one indication bit includes a first indication bit, which satisfies one or more of the following: the value of the first indication bit is a first value, indicating that the first information is an acknowledgment response (ACK); the value of the first indication bit is a second value, indicating that the first information is a non-acknowledgment response (NACK), or indicating that the second communication device does not have a first RLC status report that needs to be fed back; the first indication bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

[0266] In some embodiments, the at least one indicator bit includes a second indicator bit that identifies a first RLC status report. In some embodiments, the first RLC status report includes a third indicator bit that identifies the first RLC status report. In some embodiments, the second indicator bit and the third indicator bit have the same value.

[0267] In some embodiments, the processing module 6202 is configured to: determine that the second communication device does not have a first RLC status report that needs to be fed back, and the first RLC PDU defaults to the second indicator bit.

[0268] In some embodiments, the first information is ACK feedback, and the second RLC status report includes: the reception status of N RLC SDUs and / or RLC SDU segments that is not included in the first RLC status report. The reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. The reception status includes ACK status or NACK status.

[0269] In some embodiments, the first information is a NACK feedback or the second communication device does not have a first RLC status report that requires feedback. The second RLC status report includes the reception status of M RLC SDUs and / or RLC SDU segments. The reception status of the M RLC SDUs and / or RLC SDU segments includes the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. The reception status includes ACK status or NACK status.

[0270] In some embodiments, the first status variable is RX_Next, which represents the receive status variable; the second status variable is RX_Highest_Status, which represents the maximum STATUS sent status variable.

[0271] In some embodiments, the second RLC status report is the next generated RLC status report following the first RLC status report.

[0272] Optionally, the transceiver module is used to perform at least one of the communication steps (such as step S3101, step S5101, but not limited thereto) performed by the second communication device 102 in any of the above methods, which will not be elaborated here. Optionally, the processing module is used to perform at least one of the other steps performed by the second communication device 102 in any of the above methods, which will not be elaborated here.

[0273] In some embodiments, the transceiver module may include a transmitting module and / or a receiving module, which may be separate or integrated. Optionally, the transceiver module may be interchangeable with a transceiver.

[0274] In some embodiments, the processing module may be a single module or may include multiple sub-modules. Optionally, the multiple sub-modules may each perform all or part of the steps required by the processing module.

[0275] In some embodiments, the processing module can be replaced by the processor, and the transceiver module can be replaced by the transceiver.

[0276] Figure 7A is a schematic diagram of the structure of the communication device 7100 proposed in an embodiment of this disclosure. The communication device 7100 can be a network device (e.g., access network device, core network device, etc.), a terminal (e.g., user equipment, etc.), a chip, chip system, or processor that supports the network device in implementing any of the above methods, or a chip, chip system, or processor that supports the terminal in implementing any of the above methods. The communication device 7100 can be used to implement the methods described in the above method embodiments; for details, please refer to the descriptions in the above method embodiments.

[0277] As shown in Figure 7A, the communication device 7100 is used to execute any of the above methods. In some embodiments, the communication device 7100 includes one or more processors 7101. The processor 7101 may be a general-purpose processor or a special-purpose processor, such as a baseband processor or a central processing unit. The baseband processor may be used to process communication protocols and communication data, and the central processing unit may be used to control communication devices (e.g., base stations, baseband chips, terminal devices, terminal device chips, DUs or CUs, etc.), execute programs, and process program data. Optionally, the communication device 7100 is used to execute any of the above methods. Optionally, one or more processors 7101 are used to invoke instructions to cause the communication device 7100 to execute any of the above methods.

[0278] In some embodiments, the communication device 7100 further includes one or more transceivers 7103. When the communication device 7100 includes one or more transceivers 7103, the transceiver 7103 performs at least one of the communication steps (e.g., steps S3101, S5101, but not limited thereto) in the above method, such as sending and / or receiving, and the processor 7101 performs at least one of other steps (e.g., steps S3102, S3103, S5102, but not limited thereto). In optional embodiments, the transceiver may include a receiver and / or a transmitter, which may be separate or integrated. Optionally, the terms transceiver, transceiver unit, transceiver, transceiver circuit, interface circuit, interface, etc., can be used interchangeably; the terms transmitter, sending unit, transmitter, sending circuit, etc., can be used interchangeably; the terms receiver, receiving unit, receiver, receiving circuit, etc., can be used interchangeably.

[0279] In some embodiments, the communication device 7100 further includes one or more memories 7102 for storing data and / or instructions. Optionally, one or more processors 7101 are used to invoke instructions stored in the memory 7102 to cause the communication device 7100 to perform any of the above methods. Optionally, all or part of the memory 7102 may also be located outside the communication device 7100. In an optional embodiment, the communication device 7100 may include one or more interface circuits 7104. Optionally, the interface circuit 7104 is connected to the memory 7102 and can be used to receive data and / or instructions from the memory 7102 or other devices, and can be used to send data and / or instructions to the memory 7102 or other devices. For example, the interface circuit 7104 can read data and / or instructions stored in the memory 7102 and send the data and / or instructions to the processor 7101.

[0280] The communication device 7100 described in the above embodiments may be a network device or a terminal, but the scope of the communication device 7100 described in this disclosure is not limited thereto, and the structure of the communication device 7100 may not be limited by FIG. 7A. The communication device may be a standalone device or may be part of a larger device. For example, the communication device may be: (1) a standalone integrated circuit IC, or chip, or chip system or subsystem; (2) a collection of one or more ICs, optionally, the IC collection may also include storage components for storing data, programs and / or instructions; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, terminal device, smart terminal device, cellular phone, wireless device, handheld device, mobile unit, vehicle device, network device, cloud device, artificial intelligence device, etc.; (6) others, etc.

[0281] Figure 7B is a schematic diagram of the structure of the chip 7200 according to an embodiment of this disclosure. For cases where the communication device 7100 can be a chip or a chip system, the schematic diagram of the chip 7200 shown in Figure 7B can be referred to, but is not limited thereto.

[0282] Chip 7200 includes one or more processors 7201. Chip 7200 is used to perform any of the above methods.

[0283] In some embodiments, chip 7200 further includes one or more interface circuits 7202. Optionally, terms such as interface circuit, interface, and transceiver pin can be used interchangeably. In some embodiments, chip 7200 further includes one or more memories 7203 for storing data and / or instructions. Optionally, all or part of the memories 7203 may be located outside of chip 7200. Optionally, the interface circuit 7202 is connected to the memories 7203, and the interface circuit 7202 can be used to receive data and / or instructions from the memories 7203 or other devices, and the interface circuit 7202 can be used to send data and / or instructions to the memories 7203 or other devices. For example, the interface circuit 7202 can read data and / or instructions stored in the memories 7203 and send the data and / or instructions to the processor 7201.

[0284] In some embodiments, the interface circuit 7202 performs at least one of the communication steps (e.g., steps S3101, S5101, but not limited thereto) in the above-described method, such as sending and / or receiving. For example, the interface circuit 7202 performing the communication steps (e.g., sending and / or receiving) in the above-described method means that the interface circuit 7202 performs data and / or instruction interaction between the processor 7201, the chip 7200, the memory 7203, or the transceiver device. In some embodiments, the processor 7201 performs at least one of other steps (e.g., steps S3102, S3103, S5102, but not limited thereto).

[0285] The modules and / or devices described in the various embodiments, such as virtual devices, physical devices, and chips, can be combined or separated arbitrarily as needed. Optionally, some or all steps can also be performed collaboratively by multiple modules and / or devices, which is not limited here.

[0286] This disclosure also proposes a storage medium storing instructions that, when executed on a communication device, cause the communication device to perform any of the above methods. Optionally, the storage medium is an electronic storage medium. Optionally, the storage medium is a computer-readable storage medium, but not limited thereto; it may also be a storage medium readable by other devices. Optionally, the storage medium may be a non-transitory storage medium, but not limited thereto; it may also be a temporary storage medium.

[0287] This disclosure also proposes a program product, including a program and / or instructions, which, when executed by a communication device, cause the communication device to perform any of the above methods. Optionally, the program product is a computer program product. Optionally, the program product is stored on the storage medium.

[0288] This disclosure also proposes a computer program that, when run on a computer, causes the computer to perform any of the above methods.

[0289] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer programs. When the computer program is loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program can be transferred from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., high-density digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0290] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

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

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

Claims

1. A method of handling status reports, characterized by, The method is performed by a first communication device, and the method includes: Receive first information sent by the second communication device, wherein the first information is a feedback of the first radio link control (RLC) status report sent by the first communication device; Based on the first information, determine the second RLC status report.

2. The method of claim 1, wherein, The first information received from the second communication device includes: The device receives one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) sent by the second communication device, wherein the first RLC PDU contains at least one indicator bit, and the at least one indicator bit of the one or more first RLC PDUs is used to indicate the first information.

3. The method of claim 2, wherein, The at least one indicator bit includes a first indicator bit, wherein the first indicator bit satisfies one or more of the following: The value of the first indicator bit is a first value, indicating that the first information is an acknowledgment response (ACK). The value of the first indicator bit is the second value, indicating that the first information is a non-acknowledgment response (NACK) feedback, or indicating that the second communication device does not have a first RLC status report that needs to be fed back. The first indicator bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

4. The method of claim 2 or 3, wherein, The at least one indication bit includes a second indication bit, the second indication bit identifying the first RLC status report; or The second indicator bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

5. The method of claim 4, wherein, The first RLC status report includes a third indicator bit, which identifies the first RLC status report.

6. The method of claim 5, wherein, The second indicator bit has the same value as the third indicator bit.

7. The method of any one of claims 1-6, wherein, The step of determining the second RLC status report based on the first information includes: The first information includes ACK feedback, and the content of the second RLC status report is determined based on the first RLC status report.

8. The method of claim 7, wherein, Determining the content of the second RLC status report based on the first RLC status report includes: The reception statuses of N RLC SDUs and / or RLC SDU segments that are not included in the first RLC status report are determined as contents of the second RLC status report; wherein, the reception statuses of the N RLC SDUs and / or RLC SDU segments include: the reception statuses of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception statuses include acknowledgment acknowledgment (ACK) status or non-acknowledgment acknowledgment (NACK) status.

9. The method of any one of claims 1-6, wherein, The step of determining the second RLC status report based on the first information includes: If the first information is determined to be NACK feedback or if the second communication device does not have a first RLC status report that needs to be fed back based on the first information, the reception status of M RLC SDUs and / or RLC SDU segments is determined as the content of the second RLC status report. The reception status of the M RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments where SN is greater than or equal to the value of the first status variable and less than the value of the second status variable, and the reception status includes ACK status or NACK status.

10. The method as described in claim 8 or 9, characterized in that, The first state variable is RX_Next, which represents the received state variable; The second status variable is RX_Highest_Status, which represents the highest STATUS transmission status variable.

11. The method of any one of claims 1-10, wherein, The second RLC status report is the next generated RLC status report following the first RLC status report.

12. A method of handling status reports, characterized by The method is performed by a second communication device, and the method includes: Send first information to the first communication device, wherein the first information is a feedback to the first radio link control (RLC) status report sent by the first communication device; The first information is used by the first communication device to determine the second RLC status report.

13. The method of claim 12, wherein, Sending the first information to the first communication device includes: Send one or more first Radio Link Control (RLC) Protocol Data Units (PDUs) to the first communication device, wherein the first RLC PDU includes at least one indicator bit, and the at least one indicator bit of the one or more first RLC PDUs is used to indicate the first information.

14. The method of claim 13, wherein, The at least one indicator bit includes a first indicator bit, wherein the first indicator bit satisfies one or more of the following: The value of the first indicator bit is a first value, indicating that the first information is an acknowledgment response (ACK). The value of the first indicator bit is the second value, indicating that the first information is a non-acknowledgment response (NACK) feedback, or indicating that the second communication device does not have a first RLC status report that needs to be fed back. The first indicator bit is defaulted, indicating that the second communication device does not have a first RLC status report that needs to be fed back.

15. The method of claim 13 or 14, wherein, The at least one indication bit includes a second indication bit, the second indication bit identifying the first RLC status report.

16. The method of claim 15, wherein, The first RLC status report includes a third indicator bit, which identifies the first RLC status report.

17. The method of claim 16, wherein, The second indicator bit has the same value as the third indicator bit.

18. The method of claim 15, wherein, The method further includes: If it is determined that there is no first RLC status report that requires feedback, the second indicator bit in the first RLC PDU is defaulted.

19. The method according to any one of claims 12-18, characterized in that, The first information is an ACK feedback. The second RLC status report includes: the reception status of N RLC SDUs and / or RLC SDU segments that is not included in the first RLC status report. The reception status of the N RLC SDUs and / or RLC SDU segments includes: the reception status of RLC SDUs and / or RLC SDU segments whose sequence number SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. The reception status includes an ACK status or a NACK status. The first information is a NACK feedback or the second communication device does not have a first RLC status report that needs to be fed back. The second RLC status report includes the reception status of M RLC SDUs and / or RLC SDU segments. The reception status of the M RLC SDUs and / or RLC SDU segments includes the reception status of RLC SDUs and / or RLC SDU segments whose SN is greater than or equal to the value of the first status variable and less than the value of the second status variable. The reception status includes ACK status or NACK status.

20. The method as described in claim 19, characterized in that, The first state variable is RX_Next, which represents the received state variable; The second status variable is RX_Highest_Status, which represents the highest STATUS transmission status variable.

21. The method of any one of claims 12-20, wherein, The second RLC status report is the next generated RLC status report following the first RLC status report.

22. A communications device, characterized by The communication device is used to perform the status report processing method according to any one of claims 1-11 or any one of claims 12-21.

23. A storage medium, the storage medium storing instructions, wherein, When the instruction is executed on the communication device, it causes the communication device to perform a status report processing method as described in any one of claims 1-11 or any one of claims 12-21.

24. A program product comprising at least one of a program, instructions, characterized in that When at least one of the programs or instructions is executed by the communication device, it implements the steps of the method described in any one of claims 1-11 or any one of claims 12-21.