Communication for delay sensitive traffic

Abstract

Embodiments of the present disclosure relate to communication for delay sensitive traffic. In one aspect, a first device may maintain a first state variable based at least on one or more of the following: a first timer, a reassembly timer, a receive state variable, a reassembly timer state variable, a maximum status transmit state variable, or a highest received state variable. Upon determination that the first timer expires, the first device may determine, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed. In this way, avoidance of unnecessary retransmissions in a Rx side may be performed correctly.

Description

COMMUNICATION FOR DELAY SENSITIVE TRAFFICTECHNICAL FIELD

[0001] Embodiments of the present disclosure generally relate to the field of telecommunication, and in particular, to methods, devices and computer storage media of communication for delay sensitive traffic.BACKGROUND

[0002] Radio link control (RLC) acknowledged mode (AM) is typically used for services which require no packet loss but without stringent latency requirement. Characteristics of RLC AM are not negligible for delay sensitive traffic such as typical extended reality (XR) services which have strict latency requirements and certain reliability requirements.

[0003] In addition, a delay status reporting (DSR) functionality has been specified and a DSR medium access control (MAC) control element (CE) has been introduced for the DSR functionality. However, the current delay status reporting has a limitation that when multiple protocol data unit (PDU) sets in a logical channel group (LCG) have different remaining times, only the smallest remaining time below a threshold is reported. Thus, enhancements for delay sensitive traffic still need to be studied.SUMMARY

[0004] In general, embodiments of the present disclosure provide methods, devices and computer storage media of communication for delay sensitive traffic.

[0005] In a first aspect, there is provided a first device. The first device comprises a processor configured to cause the first device to: maintain, via a receiving side of a RLC entity, a first state variable based at least on one or more of the following: a first timer, a reassembly timer, a receive state variable, a reassembly timer state variable, a maximum status transmit state variable, or a highest received state variable; and in accordance with a determination that the first timer expires, determine, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed.

[0006] In a second aspect, there is provided a terminal device. The terminal device comprises a processor configured to cause the terminal device to: receive, from a network device, at least one configuration indicating a first DSR comprising single set of delay information for each LCG and a second DSR comprising multiple sets of delay information for each LCG; and perform an operation comprising at least one of the following: in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR; in accordance with a determination that an uplink resource is not enough to accommodate a MAC CE for the second DSR, adjusting at least one of the first DSR or the second DSR; or in accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR.

[0007] In a third aspect, there is provided a method of communication. The method is implemented at a first device. The method comprises: maintaining, via a receiving side of a RLC entity, a first state variable based at least on one or more of the following: a first timer, a reassembly timer, a receive state variable, a reassembly timer state variable, a maximum status transmit state variable, or a highest received state variable; and in accordance with a determination that the first timer expires, determining, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed.

[0008] In a fourth aspect, there is provided a method of communication. The method is implemented at a terminal device. The method comprises: receiving, from a network device, at least one configuration indicating a first DSR comprising single set of delay information for each LCG and a second DSR comprising multiple sets of delay information for each LCG; and performing an operation comprising at least one of the following: in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR; in accordance with a determination that an uplink resource is not enough to accommodate a MAC CE for the second DSR, adjusting at least one of the first DSR or the second DSR; or in accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR.

[0009] In a fifth aspect, there is provided a computer readable medium having instructions stored thereon. The instructions, when executed on at least one processor, cause the at least one processor to perform the method according to the third or fourth aspect of the present disclosure.

[0010] Other features of the present disclosure will become easily comprehensible through the following description.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein:

[0012] FIG. 1A illustrates an example communication network in which some embodiments of the present disclosure can be implemented;

[0013] FIG. 1B illustrates a schematic diagram of an example DSR MAC CE in which some embodiments of the present disclosure can be implemented;

[0014] FIG. 1C illustrates a schematic diagram of another example DSR MAC CE in which some embodiments of the present disclosure can be implemented;

[0015] FIG. 2 illustrates a signaling chart illustrating an example process of communication according to embodiments of the present disclosure;

[0016] FIG. 3 illustrates a signaling chart illustrating another example process of communication according to embodiments of the present disclosure;

[0017] FIG. 4 illustrates an example DSR scenario in which some embodiments of the present disclosure can be implemented;

[0018] FIG. 5 illustrates a flowchart of an example method of communication implemented at a first device in accordance with some embodiments of the present disclosure;

[0019] FIG. 6 illustrates a flowchart of an example method of communication implemented at a terminal device in accordance with some embodiments of the present disclosure; and

[0020] FIG. 7 is a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure.

[0021] Throughout the drawings, the same or similar reference numerals represent the same or similar element.DETAILED DESCRIPTION

[0022] Principle of the present disclosure will now be described with reference to some embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitations as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

[0023] In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

[0024] As used herein, the term ‘terminal device’ refers to any device having wireless or wired communication capabilities. Examples of the terminal device include, but not limited to, user equipment (UE) , personal computers, desktops, mobile phones, cellular phones, smart phones, personal digital assistants (PDAs) , portable computers, tablets, wearable devices, Internet of things (IoT) devices, ultra-reliable and low latency communications (URLLC) devices, Internet of everything (IoE) devices, machine type communication (MTC) devices, device on vehicle for V2X communication where X means pedestrian, vehicle, or infrastructure / network, devices for integrated access and backhaul (IAB) , space borne vehicles or air borne vehicles in non-terrestrial networks (NTN) including satellites and high altitude platforms (HAPs) encompassing unmanned aircraft systems (UAS) , XR devices including different types of realities such as augmented reality (AR) , mixed reality (MR) and virtual reality (VR) , the unmanned aerial vehicle (UAV) commonly known as a drone which is an aircraft without any human pilot, devices on high speed train (HST) , or image capture devices such as digital cameras, sensors, gaming devices, music storage and playback appliances, or Internet appliances enabling wireless or wired Internet access and browsing and the like. The ‘terminal device’ can further has ‘multicast / broadcast’ feature, to support public safety and mission critical, V2X applications, transparent IPv4 / IPv6 multicast delivery, IPTV, smart TV, radio services, software delivery over wireless, group communications and IoT applications. It may also incorporate one or multiple subscriber identity module (SIM) as known as multi-SIM. The term ‘terminal device’ can be used interchangeably with a UE, a mobile station, a subscriber station, a mobile terminal, a user terminal or a wireless device.

[0025] As used herein, the term ‘network device’ refers to a device which is capable of providing or hosting a cell or coverage where terminal devices can communicate. Examples of a network device include, but not limited to, a Node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a next generation NodeB (gNB) , a transmission reception point (TRP) , a remote radio unit (RRU) , a radio head (RH) , a remote radio head (RRH) , an IAB node, a low power node such as a femto node, a pico node, a reconfigurable intelligent surface (RIS) , and the like.

[0026] The terminal device or the network device may have artificial intelligence (AI) or machine learning (ML) capability. It generally includes a model which has been trained from numerous collected data for a specific function, and can be used to predict some information.

[0027] The terminal device or the network device may work on several frequency ranges, e.g., FR1 (410 MHz to 7125 MHz) , FR2 (24.25GHz to 71GHz) , frequency band larger than 100GHz as well as Tera Hertz (THz) . It can further work on licensed / unlicensed / shared spectrum. The terminal device may have more than one connection with the network devices under multi-radio dual connectivity (MR-DC) application scenario. The terminal device or the network device can work on full duplex, flexible duplex and cross division duplex modes.

[0028] The embodiments of the present disclosure may be performed in test equipment, e.g., signal generator, signal analyzer, spectrum analyzer, network analyzer, test terminal device, test network device, channel emulator.

[0029] In one embodiment, the terminal device may be connected with a first network device and a second network device. One of the first network device and the second network device may be a master node and the other one may be a secondary node. The first network device and the second network device may use different radio access technologies (RATs) . In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is eNB and the second RAT device is gNB. Information related with different RATs may be transmitted to the terminal device from at least one of the first network device or the second network device. In one embodiment, information A may be transmitted to the terminal device from the first network device and information B may be transmitted to the terminal device from the second network device directly or via the first network device. In one embodiment, information related with configuration for the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information related with reconfiguration for the terminal device configured by the second network device may be transmitted to the terminal device from the second network device directly or via the first network device.

[0030] As used herein, the singular forms ‘a’ , ‘an’ and ‘the’ are intended to include the plural forms as well, unless the context clearly indicates otherwise. The term ‘includes’ and its variants are to be read as open terms that mean ‘includes, but is not limited to. ’ The term ‘based on’ is to be read as ‘at least in part based on. ’ The term ‘one embodiment’ and ‘an embodiment’ are to be read as ‘at least one embodiment. ’ The term ‘another embodiment’ is to be read as ‘at least one other embodiment. ’ The terms ‘first, ’ ‘second, ’ and the like may refer to different or same objects. The term ‘and / or’ indicates that there may be three relationships. For example, A and / or B may indicate cases includes ‘only A’ , ‘both A and B’ , and ‘only B’ . The term ‘at least one of the following items’ or a similar expression thereof refers to any combination of these items, including any combination of a single item or a plurality of items. For example, ‘at least one of A, B, or C’ may represent A, B, C, ‘A and B’ , ‘A and C’ , ‘B and C’ , or ‘A, B and C’ . Other definitions, explicit and implicit, may be included below.

[0031] In some examples, values, procedures, or apparatus are referred to as ‘best, ’ ‘lowest, ’ ‘highest, ’ ‘minimum, ’ ‘maximum, ’ or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

[0032] In the context of the present disclosure, the term ‘below’ may be interchangeably used with ‘smaller than or equal to’ or ‘lower than or equal to’ . The term ‘above’ may be interchangeably used with ‘greater than or equal to’ or ‘higher than or equal to’ .

[0033] In the context of the present disclosure, the term ‘DSR’ herein may refer to a reporting of a status of delayed data. The term ‘delayed data’ may refer to data whose remaining time is lower than a threshold (also referred to as remaining time threshold herein) . The term ‘delayed data’ may be interchangeably used with ‘delay-critical data’ .

[0034] In the context of the present disclosure, the term ‘remaining time’ herein may be interchangeably used with ‘remaining delay time’ or ‘remaining delay budget’ . The remaining time may refer to remaining time of a discard timer for a data packet. In the context of the present disclosure, the term ‘data packet’ herein may refer to a RLC service data unit (SDU) or PDU.

[0035] In the context of the present disclosure, the term ‘first DSR’ may refer to a DSR comprising single set of delay information for each LCG. It is to be noted that the first DSR may be a legacy DSR or any newly defined DSRs. The term ‘first DSR’ may be interchangeably used with ‘legacy DSR’ or any other suitable names. The term ‘second DSR’ may refer to a DSR comprising multiple sets of delay information for each LCG, and may be interchangeably used with ‘enhanced DSR’ or any other suitable names. The term ‘AM RLC entity’ herein may be interchangeably used with ‘RLC entity’ .

[0036] In the context of the present disclosure, the term ‘a first threshold’ may refer to a threshold for triggering the second DSR, and may be interchangeably used with ‘a triggering threshold’ . The term ‘a second threshold’ may refer to any of a set of thresholds (also referred to as a set of reporting thresholds herein) for a set of delay ranges in an enhanced DSR, e.g., a largest threshold among the set of reporting thresholds. The term ‘a second threshold’ may be interchangeably used with ‘a largest configured reporting threshold’ or ‘a configured reporting threshold’ . The term ‘a third threshold’ may refer to a threshold for triggering the first DSR, and may be interchangeably used with ‘a remaining time threshold’ .

[0037] In the context of the present disclosure, the term ‘receive state variable’ (denoted as RX_Next herein) may refer to a state variable holding a value of a sequence number (SN) following the last in-sequence completely received RLC data packet, and serving as a lower edge of a receiving window. This state variable may be initially set to 0, and may be updated whenever an AM RLC entity receives a RLC data packet with SN = RX_Next.

[0038] The term ‘reassembly timer state variable’ (denoted as RX_Next_Status_Trigger herein) may refer to a state variable holding a value of a SN following a SN of a RLC data packet which triggered t-Reassembly. The term ‘reassembly timer state variable’ may be interchangeably used with ‘t-Reassembly state variable’ herein.

[0039] The term ‘maximum status transmit state variable’ (denoted as RX_Highest_Status herein) may refer to a state variable holding the highest possible value of a SN which can be indicated by ‘ACK_SN’ when a status PDU needs to be constructed. This state variable may be initially set to 0.

[0040] The term ‘highest received state variable’ (denoted as RX_Next_Highest herein) may refer to a state variable holding a value of a SN following a SN of a RLC data packet with the highest SN among received RLC data packets. This state variable may be initially set to 0.

[0041] The term ‘reassembly timer’ (denoted as t-Reassembly herein) may refer to a timer used by a receiving (Rx) side of an AM RLC entity and Rx unacknowledged mode (UM) RLC entity in order to detect loss of RLC PDUs at a lower layer. If t-Reassembly is running, t-Reassembly shall not be started additionally, i.e. only one t-Reassembly per RLC entity is running at a given time. The term ‘first timer’ (denoted as t_discardTimer herein) herein may refer to a timer used by a Rx side of a RLC entity in order to detect miss of RLC data packet (s) or discard RLC data packet (s) or stop retransmission of RLC data packet (s) . When the first timer expires, the RLC data packet (s) associated with the timer (e.g., SN <RX_T) may be discarded or be considered to be discarded / missed or the retransmission of which shall be stopped.

[0042] It is to be noted that the above timers and state variables may be named in any other suitable ways.

[0043] It is assumed that XR services have strict latency requirements. Since any data which has exceeded packet delay budget (PDB)  / PDU set delay budget (PSDB) may not be useful, it is needed to avoid sending these useless data to save radio resources.

[0044] As mentioned above, RLC AM is typically used for services which require no packet loss but without stringent latency requirement. The characteristics of RLC AM are not negligible for typical XR services which have strict latency requirements and certain reliability requirements.

[0045] DSR functionality has been specified and a DSR MAC CE was introduced. However, current delay status reporting has a limitation that when multiple PDU sets in a LCG have different remaining times, only the smallest remaining time below a threshold is reported. Thus, the DSR MAC CE may not provide a full picture of delayed buffer of a terminal device and hence a network device may not be able to efficiently assign one or more uplink (UL) resources in response to a received DSR.

[0046] Currently, work item description (WID) about further enhancing XR is ongoing. For user plane, RLC re-transmission related enhancements for RLC AM with small packet delay budget needs to be discussed. For UL, enhancements using delay / deadline information need to be specified for support of UL scheduling to enable high XR capacity while meeting delay requirements / avoiding too late PDUs.

[0047] Embodiments of the present disclosure provide solutions of communication for delay sensitive traffic. In one aspect, a first device may maintain, via a receiving side of a RLC entity, a first state variable based at least on one or more of the following: a first timer, a reassembly timer, a receive state variable, a reassembly timer state variable, a maximum status transmit state variable, or a highest received state variable. In accordance with a determination that the first timer expires, the first device may determine, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed. In this way, avoidance of unnecessary retransmissions in a Rx side may be performed correctly.

[0048] In another aspect, a terminal device may receive, from a network device, at least one configuration indicating a first DSR comprising single set of delay information for each LCG and a second DSR comprising multiple sets of delay information for each LCG. The terminal device may perform an operation comprising at least one of the following: in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR; in accordance with a determination that an uplink resource is not enough to accommodate a MAC CE for the second DSR, adjusting at least one of the first DSR or the second DSR; or in accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR. In this way, delay information may be reported properly.

[0049] Principles and implementations of the present disclosure will be described in detail below with reference to the figures.EXAMPLE OF COMMUNICATION NETWORK

[0050] FIG. 1A illustrates a schematic diagram of an example communication network 100A in which some embodiments of the present disclosure can be implemented. As shown in FIG. 1A, the communication network 100A may include a terminal device 110 and a network device 120. In some embodiments, the terminal device 110 may be served by the network device 120.

[0051] It is to be understood that the numbers of terminal devices and network devices in FIG. 1A are given for the purpose of illustration without suggesting any limitations to the present disclosure. The communication network 100A may include any suitable number of network devices and / or terminal devices adapted for implementing implementations of the present disclosure.

[0052] As shown in FIG. 1A, the terminal device 110 may communicate with the network device 120 via a channel such as a wireless communication channel. The communications in the communication network 100A may conform to any suitable standards including, but not limited to, global system for mobile communications (GSM) , long term evolution (LTE) , LTE-evolution, LTE-advanced (LTE-A) , new radio (NR) , wideband code division multiple access (WCDMA) , code division multiple access (CDMA) , GSM EDGE radio access network (GERAN) , machine type communication (MTC) and the like. The embodiments of the present disclosure may be performed according to any generation communication protocols either currently known or to be developed in the future. Examples of the communication protocols include, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) communication protocols, 5.5G, 5G-advanced networks, or the sixth generation (6G) networks.

[0053] In some scenarios, the terminal device 110 may transmit, to the network device 120, a first DSR (e.g., legacy DSR) comprising single set of delay information for each LCG via a DSR MAC CE (for convenience, also referred to as a first DSR MAC CE or a DSR MAC CE herein) . FIG. 1B illustrates a schematic diagram of a DSR MAC CE 100B in which some embodiments of the present disclosure can be implemented. The DSR MAC CE 100B is an example of the first DSR MAC CE. As shown in FIG. 1B, the DSR MAC CE 100B may comprise a LCGi field 101, where i = 0 to 7. The LCGi field indicates presence of delay information (i.e., Remaining Time and Buffer Size fields 104 and 105) for LCG i. The LCGi field set to 1 indicates that the delay information for the LCG i is reported. The LCGi field set to 0 indicates that the delay information for the LCG i is not reported.

[0054] As shown in FIG. 1B, the DSR MAC CE 100B may comprise a BT field 102. The BT field is present only if a corresponding LCG is configured with an additional buffer size table (e.g., an information element (IE) ‘additionalBS-TableAllowed’ ) and a buffer size indicated by a corresponding Buffer Size field is not zero; otherwise, the BT field is reserved and set to 0. If present, the BT field set to 1 indicates that specified buffer sizes are used to set a value of the Buffer Size field, while the BT field set to 0 indicates that the specified buffer sizes are used instead.

[0055] As shown in FIG. 1B, the DSR MAC CE 100B may comprise a R field 103. The R field indicates a reserved bit.

[0056] As shown in FIG. 1B, the DSR MAC CE 100B may comprise a Remaining Time field 104. The Remaining Time field indicates the shortest remaining value of running PDCP discard timer among all PDCP SDUs that are buffered for an LCG but have not been transmitted in any MAC PDU, at the time of the first symbol of the first PUSCH transmission that includes this DSR MAC CE.

[0057] As shown in FIG. 1B, the DSR MAC CE 100B may comprise a Buffer Size field 105. The Buffer Size field indicates the total amount of delay-critical data for an LCG according to a data volume calculation procedure for associated RLC and PDCP entities, respectively, after a MAC PDU has been built.

[0058] It is to be understood that in the example of FIG. 1B, delay information of only m LCGs is reported, where m ≤ 8. The first DSR MAC CE is designed for reporting one pair of remaining time and buffer size for a LCG.

[0059] In some scenarios, the terminal device 110 may transmit, to the network device 120, a second DSR (i.e., enhanced DSR) comprising multiple sets of delay information for each LCG via a DSR MAC CE (for convenience, also referred to as a second DSR MAC CE or an enhanced DSR MAC CE herein) . FIG. 1C illustrates a schematic diagram of a DSR MAC CE 100C in which some embodiments of the present disclosure can be implemented. It is to be noted that the DSR MAC CE 100C is merely an example of the second DSR MAC CE, and the second DSR MAC CE may adopt any other suitable forms.

[0060] As shown in FIG. 1C, the DSR MAC CE 100C may comprise a field LCGi 111 which indicates a type of delay information for a LCG i. In this example, i = 0 to 7. In some embodiments, this field LCGi may indicate whether multiple sets of delay information or a single set of delay information is reported for the LCG. In some embodiments, this field LCGi may indicate whether the multiple sets of delay information are reported. For illustration, example values of this field LCGi may be described in Table 1 below. Table 1

[0061] As shown in FIG. 1C, the DSR MAC CE 100C may comprise a field ‘smallest remaining time’ 112 which indicates the smallest or shortest remaining value of running PDCP discard timer among all PDCP SDUs of a delay level or range that are buffered for a LCG. In this example, m sets of delay information are reported for each LCG, and each set comprise a corresponding field ‘smallest remaining time’ . That is, m delay levels or ranges are reported for a LCG.

[0062] As shown in FIG. 1C, the DSR MAC CE 100C may comprise a field ‘E’ 113 which indicates whether a set of delay information follows. In this example, m sets of delay information are reported for each LCG, and each set comprises a corresponding field ‘E’ . For example, the field ‘E’ in each of 1st to (m-1) th sets of delay information may indicate a set of delay information follows, and the field ‘E’ in mth set of delay information may indicate no set of delay information follows.

[0063] As shown in FIG. 1C, the DSR MAC CE 100C may comprise a field ‘buffer size’ 115 which indicates the total amount of uplink data or delay-critical uplink data or non-delay-critical uplink data for a delay range. In this example, m sets of delay information are reported for each LCG, and each set comprises a corresponding field ‘buffer size’ . That is, a buffer size is reported for each delay range of each LCG.

[0064] In the example of FIG. 1C, the DSR MAC CE 100C may comprise a field ‘BT1’ 116 and fields ‘R’ 117. The field ‘BT1’ may have the same meaning as the BT field 102 in FIG. 1B, and thus not be repeated here for conciseness. The fields ‘R’ indicates reserved bits.

[0065] It is to be noted that FIGs. 1B and 1C are merely examples, and the first or second DSR MAC CE may adopt any other similar forms.

[0066] Embodiments of the present disclosure provide solutions of communication so as to enhance delay sensitive traffic in terms of a RLC AM management and a DSR management. The solutions will be described in detail with reference to FIGs. 2 to 4.EXAMPLE IMPLEMENTATION OF RLC AM MANAGEMENT

[0067] Current RLC AM mechanism does not consider remaining delay budget of a packet, and never give up retransmission until successful transmission is confirmed or radio link failure (RLF) is triggered. Hence, it may cause inefficiency in handling retransmissions of data packets within the stringent delay requirements of XR applications, for example, un-necessary RLC AM retransmission when the remaining delay budget is almost exhausted.

[0068] If a RLC data packet is retransmitted, it means that a RLC sequence number (SN) has been assigned to the RLC data packet and either the RLC data packet or segment thereof has been submitted to the lower layers. Then, early stop of discard / retransmission of a RLC data packet may introduce a RLC SN gap and block the advancement of a receiving window, since the RLC data packet may never be successfully received by a Rx side of an AM RLC entity. It also happens when discarding a RLC data packet whose RLC SN has been assigned.

[0069] To avoid unnecessary retransmissions, it has been agreed that the Rx side of the AM RLC entity may abandon the RLC data packet based on a timer. When the timer expires, the RLC data packet associated with the timer may be discarded or be considered to have been discarded / missed. However, it is still unclear how to determine such RLC data packet, and what actions should be taken when timer is stopped or expired.

[0070] In view of this, embodiments of the present disclosure provide a solution of RLC AM management. This solution will be described in detail with reference to FIG. 2. FIG. 2 illustrates a signaling chart illustrating an example process 200 of communication according to embodiments of the present disclosure. For the purpose of discussion, the process 200 will be described with reference to FIG. 1A. The process 200 may involve the terminal device 110 and the network device 120 as illustrated in FIG. 1A. It is to be understood that the steps and the order of the steps in FIG. 2 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any suitable additional steps may be added.

[0071] For illustrations, the process 200 is described in connection with Rx and Tx sides of a RLC entity at the terminal device 110. It is to be noted that the process 200 may also be applied to Rx and Tx sides of a RLC entity at the network device 120.

[0072] As shown in FIG. 2, at step 210, the terminal device 110 may receive one or more RLC data packets (e.g., one or more RLC SDUs) from the network device 120 via the Rx side of the RLC entity.

[0073] In some embodiments, the Rx side of the RLC entity may use a first timer (denoted as t_discardTimer herein) to detect miss of the one or more RLC data packets or discard the one or more RLC data packets or stop a retransmission of the one or more RLC data packets. In some embodiments, the first timer may be configured per RLC entity. In some embodiments, the first timer may be configured per RLC data packet (e.g., per RLC SDU) .

[0074] In some embodiments, if a RLC data packet is not fully received by the Rx side of the RLC entity, the Rx side of the RLC entity may start the first timer. In some embodiments, when a reassembly timer (denoted as t-Reassembly herein) expires, the Rx side of the RLC entity may start the first timer. In some embodiments, if an indication from an upper layer (e.g., packet data convergence packet (PDCP) layer) , for example, the PDCP layer detects a SN gap, the Rx side of the RLC entity may start the first timer. In some embodiments, when RLC delivers a RLC data packet with SN higher than RX_Next to the PDCP layer (out of order) , i.e., there is a SN gap at the Rx side of the RLC entity, the Rx side of the RLC entity may start the first timer. It is to be noted that any combinations of the above conditions or any other suitable conditions may also be feasible to trigger the starting of the first timer.

[0075] As shown in step 220, the terminal device 110 may maintain a first state variable via the Rx side of the RLC entity. The first state variable may be introduced to hold a value of a SN following a SN of a RLC data packet which triggers or starts the first timer. RLC data packets (e.g., that are missing or have not successfully received) with SNs below the first state variable may be discarded or considered to be discarded or missed when the first timer expires. The first state variable may be initially set to 0. For convenience, the first state variable may be denoted as RX_T herein. It is to be noted that this state variable may be named in any suitably ways.

[0076] In some embodiments, the Rx side of the RLC entity may maintain the first state variable RX_T based at least on one or more of the following: the first timer (e.g., t_discardTimer) , the reassembly timer (e.g., t-Reassembly) , a receive state variable (denoted as RX_Next herein) , a reassembly timer state variable (denoted as RX_Next_Status_Trigger herein) , a maximum status transmit state variable (denoted as RX_Highest_Status herein) , or a highest received state variable (denoted as RX_Next_Highest herein) .

[0077] In some embodiments, when the first timer (e.g., t_discardTimer) is started, or when a condition for starting the first timer is satisfied, the terminal device 110 may set or update the first state variable (e.g., RX_T) to RX_Next_Highest, or RX_Highest_Status, or RX_Next_Status_Trigger, or a SN of a first RLC data packet with a SN greater than a current or first or largest SN of delivered RLC data packet for which not all bytes have been received or discarded or missed, or a SN of a first RLC data packet with SN greater than RX_T or RX_NEXT for which not all bytes have been received or discarded or missed.

[0078] In some embodiments, upon determination that the reassembly timer expires, the Rx side of the RLC entity may perform a first operation to maintain the first state variable. In some embodiments, the first operation may comprise causing one or more RLC data packets with a SN < RX_Highest_Status or RX_Next_Highest to be associated with the first timer t_discardTimer. For example, the association may be determined before RX_Highest_Status is updated.

[0079] In some embodiments, the first operation may comprise setting the first state variable RX_T based on RX_Next_Status_Trigger or RX_Highest_Status or RX_Next_Highest, e.g., setting RX_T to RX_Next_Status_Trigger or RX_Highest_Status or RX_Next_Highest.

[0080] In some embodiments, the first operation may comprise starting or restarting the first timer t_discardTimer) . For example, the first timer may be started before RX_Highest_Status is updated.

[0081] In some embodiments, the first operation may comprise updating RX_Highest_Status to the SN of the first RLC data packet (e.g., the first RLC SDU) with SN ≥ RX_Next_Status_Trigger for which not all bytes have been received.

[0082] In some embodiments, the first operation may comprise starting t-Reassembly and setting RX_Next_Status_Trigger to RX_Next_Highest if RX_Next_Highest >RX_Highest_Status +1, or if RX_Next_Highest = RX_Highest_Status + 1 and there is at least one missing byte segment of a RLC data packet (e.g., a RLC SDU) associated with SN = RX_Highest_Status before the last byte of all received segments of this RLC data packet.

[0083] It is to be noted that any combinations of the above first operations may also be feasible.

[0084] For illustration, an example procedure may be described as below. When t-Reassembly expires, a receiving side of an AM RLC entity shall  perform at least one of the following: - the RLC SDUs with SN < RX_Highest_Status or RX_Next_Highest are  associated with the first timer t_discardTimer. For example, the association is determined before the RX_Highest_Status is updated; or - set the first state variable RX_T to RX_Next_Status_Trigger or  RX_Highest_Status or RX_Next_Highest; or - start or restart the first timer (e.g., t_discardTimer) . For example, the timer is  started before the RX_Highest_Status is updated; - update RX_Highest_Status to the SN of the first RLC SDU with SN >=  RX_Next_Status_Trigger for which not all bytes have been received; - if RX_Next_Highest> RX_Highest_Status +1, or - if RX_Next_Highest = RX_Highest_Status + 1 and there is at least one  missing byte segment of the SDU associated with SN = RX_Highest_Status before the last byte of all received segments of this SDU: - start t-Reassembly; - set RX_Next_Status_Trigger to RX_Next_Highest.

[0085] In some embodiments, when a first condition associated with RX_Next_Highest is satisfied, the Rx side of the RLC entity may perform a second operation to maintain the first state variable.

[0086] In some embodiments, the first condition may comprise RX_Next_Highest is greater than RX_Next. In some embodiments, the first condition may comprise RX_Next_Highest is smaller than or equal to a sum of the RX_Next and a window size (denoted as AM_Window_Size herein) and is greater than the RX_Next. In some embodiments, the first condition may comprise RX_Next_Highest is greater than RX_T or a sum of RX_T and a first value (e.g., 1 or any other values) . In some embodiments, the first condition may comprise RX_Next_Highest is greater than the sum of RX_T and the first value and there is at least one missing byte segment of a data packet (e.g., RLC SDU) associated with a SN equal to RX_T before the last byte of all received segments of the data packet. It is to be noted that any suitable combinations of the above first conditions or any other suitable conditions may also be feasible.

[0087] In some embodiments, the second operation may comprise starting the first timer t_discardTimer, e.g., if the first timer is not running. In some embodiments, the second operation may comprise causing one or more RLC data packets with a SN smaller than RX_Next_Highest to be associated with the first timer. In some embodiments, the second operation may comprise setting RX_T based on RX_Next_Highest or a SN of a first RLC data packet (e.g., the first RLC SDU) with a SN greater than a current, first or largest SN of delivered RLC data packets for which not all bytes have been received or discarded or missed. It is to be noted that any combinations of the above second operations or any other suitable operations may also be feasible.

[0088] For illustration, an example procedure may be described as below. When the first timer (e.g., t_discardTimer) is not running (or is running) or  expired and / or after updating the needed state variables, - if RX_Next_Highest > RX_Next +1 or RX_Next; or RX_Next +  AM_Window_Size >= RX_Next_Highest > RX_Next; or - if RX_Next_Highest = RX_Next + 1 and there is at least one missing byte  segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU; or - if RX_Next_Highest > RX_T +1 or RX_T; or - if RX_Next_Highest = RX_T + 1 and there is at least one missing byte  segment of the SDU associated with SN = RX_T before the last byte of all received segments of this SDU; or - RLC SDU with SN higher than RX_Next is delivered to PDCP layer, i.e.,  there is a SN gap at RX side, a receiving side of an AM RLC entity shall perform at least one of the following: - start the first timer (e.g., t_discardTimer) , e.g., if not running. - the RLC SDUs with SN < RX_Next_Highest are associated with the first  timer t_discardTimer, or - set the first state variable RX_T to RX_Next_Highest or to the SN of the  first RLC SDU with SN > current / first / largest SN of delivered RLC SDU for which not all bytes have been received / discarded / missed.

[0089] In some embodiments, the Rx side of the RLC entity may stop the timer (if running) if all the RLC data packets associated with the first timer (e.g., t_discardTimer) have been successfully received. In some embodiments, the Rx side of the RLC entity may stop the timer (if running) if all the RLC data packets with a SN below the first state variable (e.g., RX_T) have been successfully received. In some embodiments, the Rx side of the RLC entity may stop the timer (if running) upon reception of a RLC control PDU with information indicating that all the associated RLC SDUs with the first timer (or all the RLC SDUs with SN below the first state variable) has been discarded.

[0090] In some embodiments, upon determination that a second condition associated with RX_Next_Status_Trigger is satisfied during running of the first timer t_discardTimer, the Rx side of the RLC entity may perform a third operation to maintain the first state variable.

[0091] In some embodiments, the second condition may comprise RX_Next_Status_Trigger is equal to RX_Next. In some embodiments, the second condition may comprise RX_Next_Status_Trigger is equal to a sum of RX_Next and a first value (e.g., 1 or any other values) and there is no missing byte segment of a data packet (e.g., RLC SDU) associated with a SN equal to RX_Next before the last byte of all received segments of the data packet. In some embodiments, the second condition may comprise RX_Next_Status_Trigger falls outside of a receiving window and RX_Next_Status_Trigger is not equal to a sum of RX_Next and a window size (e.g., AM_Window_Size) . It is to be noted that any suitable combinations of the above second conditions or any other suitable conditions may also be feasible.

[0092] In some embodiments, the third operation may comprise stopping the first timer t_discardTimer. In some embodiments, the third operation may comprise resetting the first timer t_discardTimer. In some embodiments, the third operation may comprise resetting the first state variable RX_T. It is to be noted that any combinations of the above third operations or any other suitable operations may also be feasible.

[0093] For illustration, an example procedure may be described as below. When an AMD PDU with SN = x is placed in the reception buffer, the receiving  side of an AM RLC entity shall: ... - if the first timer (t_discardTimer) is running: - if RX_Next_Status_Trigger = RX_Next; or - if RX_Next_Status_Trigger = RX_Next + 1 and there is no missing byte  segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU; or - if RX_Next_Status_Trigger falls outside of the receiving window and  RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size; or - if RX_T = RX_Next or RX_Next_Highest; or - if RX_T = RX_Next + 1 and there is no missing byte segment of the SDU  associated with SN = RX_Next before the last byte of all received segments of this SDU; or - if RX_T falls outside of the receiving window and / or RX_T is not equal  to RX_Next + AM_Window_Size: - stop and / or reset the first timer (t_discardTimer) , - reset RX_T (optional) .

[0094] In some embodiments, upon determination that the first timer expires and a third condition associated with RX_Next_Highest is satisfied, the Rx side of the RLC entity may perform a fifth operation to maintain the first state variable.

[0095] In some embodiments, the third condition may comprise RX_Next_Highest is greater than a sum of RX_Highest_Status and a first value (e.g., 1 or any other values) . In some embodiments, the third condition may comprise RX_Next_Highest is equal to the sum of RX_Highest_Status and the first value and there is at least one missing byte segment of a data packet (e.g., RLC SDU) associated with a SN equal to RX_Highest_Status before the last byte of all received segments of the data packet. In some embodiments, the third condition may comprise RX_Highest_Status is greater than RX_T. In some embodiments, the third condition may comprise RX_Next_Status_Trigger is greater than RX_T. In some embodiments, the third condition may comprise a RLC data packet with a SN higher than RX_Next is delivered to a PDCP layer. It is to be noted that any suitable combinations of the above third conditions or any other suitable conditions may also be feasible.

[0096] In some embodiments, the fifth operation may comprise starting the first timer t_discardTimer. In some embodiments, the fifth operation may comprise setting the first state variable RX_Next based on RX_Next_Status_Trigger, RX_Highest_Status, RX_Next_Highest, or a SN of a first RLC data packet (e.g., the first RLC SDU) with a SN greater than a largest SN of delivered RLC data packets for which not all bytes have been received or discarded or missed. It is to be noted that any combinations of the above fifth operations or any other suitable operations may also be feasible.

[0097] As shown in step 230, upon determination that the first timer (t_discardTimer) expires, the terminal device 110 may determine a set of RLC data packets associated with the first timer to be discarded or missed based on the first state variable (RX_T) . In some embodiments, the terminal device 110 may determine RLC data packet (s) with SN < RX_T as the set of RLC data packets. In other words, when the first timer expires, one or more RLC data packets associated with the first timer (e.g., RLC data packet (s) with SN < RX_T) may be discarded or be considered to be discarded / missed or the retransmission of which shall be stopped.

[0098] In some embodiments, the terminal device 110 may maintain other state variables via the Rx side of the RLC entity. In some embodiments, upon determination that the first timer expires, the Rx side of the RLC entity may perform a fourth operation to maintain other state variables.

[0099] In some embodiments, the fourth operation may comprise updating RX_Next to a SN of a first RLC data packet (e.g., the first RLC SDU) with a SN greater than RX_T or RX_Next for which not all bytes have been received or discarded or missed. In some embodiments, the fourth operation may comprise: if RX_Highest_Status is smaller than RX_T, updating RX_Highest_Status to a SN of a first RLC data packet with a SN greater than or equal to RX_T or RX_Highest_Status or RX_Next_Status_Trigger for which not all bytes have been received or discarded or missed. In some embodiments, the fourth operation may comprise stopping and resetting the reassembly timer if RX_Highest_Status is smaller than RX_T. It is to be noted that any combinations of the above fourth operations or any other suitable operations may also be feasible.

[0100] For illustration, an example procedure may be described as below. When t_discardTimer expires, the receiving side of the RLC entity shall: - update state variables, discard an acknowledged mode data (AMD) PDU  (AMD segment SDU) in the reception buffer, start / stop t-Reassembly and start t_discardTimer as needed.

[0101] For illustration, an example procedure may be described as below. If the first timer (e.g., t_discardTimer) expires, the receiving side of the RLC  entity may perform at least one of the following: - the RLC SDUs associated with the timer is discarded / missed. - update RX_Next to the SN of the first RLC SDU with SN > current  RX_Next or Rx_T for which not all bytes have been received and / or for which not be discarded / missed. - if RX_Highest_Status < RX_T, update RX_Highest_Status to the SN of  the first RLC SDU with SN >= current RX_T or RX_Highest_Status or RX_Next_Status_Trigger for which not all bytes have been received or discarded / missed. - if RX_Next_Status_Trigger < RX_T, stop and reset t-Reassembly (e.g.,  if running) . - if RX_Next_Highest > RX_T + 1, or - if RX_Next_Highest = RX_T + 1 and there is at least one missing byte  segment of the SDU associated with SN = RX_Highest_Status before the last byte of all received segments of this SDU, or - if RX_Next_Highest > RX_Highest_Status +1, or - if RX_Next_Highest = RX_Highest_Status + 1 and there is at least one  missing byte segment of the SDU associated with SN = RX_Highest_Status before the last byte of all received segments of this SDU, or - if RX_Highest_Status > RX_T, or - if RX_Next_Status_Trigger > RX_T, or - RLC SDU with SN higher than RX_Next is delivered to PDCP layer, i.e.,  there is a SN gap at RX side. - start the first timer (e.g., t_discardTimer) ; - set the first state variable RX_T to RX_Next_Status_Trigger,  RX_Highest_Status, RX_Next_Highest or the SN of the first RLC SDU with SN > current / first / largest SN of delivered RLC SDU for which not all bytes have been received.

[0102] In some embodiments, when t_discardTimer expires, the Rx side of the RLC entity may update RX_Next. Based on RX_Next, the Rx side of the RLC entity may also check t-Reassembly, and update some state variables.

[0103] In some embodiments, upon determination that the first timer expires, the Rx side of the RLC entity may perform a sixth operation to maintain some state variables.

[0104] In some embodiments, the sixth operation may comprise stopping and / or resetting the reassembly timer if the reassembly timer is running based on one of the following: RX_Next_Status_Trigger is equal to RX_Next; RX_Next_Status_Trigger is equal to a sum of RX_Next and a first value (e.g., 1 or any other values) , and there is no missing byte segment of a data packet (e.g., RLC SDU) associated with a SN equal to RX_Next before the last byte of all received segments of the data packet; or RX_Next_Status_Trigger falls outside of a receiving window and RX_Next_Status_Trigger is not equal to a sum of RX_Next and a window size (e.g., AM_Window_Size) .

[0105] In some embodiments, the sixth operation may comprise starting the reassembly timer and / or setting RX_Next_Status_Trigger to RX_Next_Highest if the reassembly timer is not running based on one of the following: RX_Next_Highest is greater than the sum of RX_Next and the first value (e.g., 1 or any other values) ; RX_Next_Highest is smaller than or equal to the sum of RX_Next and the window size, and is greater than RX_Next; or RX_Next_Highest is equal to the sum of RX_Next and the first value (e.g., 1 or any other values) , and there is at least one missing byte segment of a data packet (e.g., RLC SDU) associated with a SN equal to RX_Next before the last byte of all received segments of the data packet.

[0106] For illustration, an example procedure may be described as below. If the first timer (e.g., t_discardTimer) expires, the receiving side of the RLC  entity may perform at least one of the following: - the RLC SDUs associated with the timer is discarded / missed. - update RX_Next (e.g., to the SN of the first RLC SDU with SN > current  RX_Next or Rx_T for which not all bytes have been received and / or for which not be discarded / missed) . - update RX_T (e.g., if the conditions described above is met) . - if t-Reassembly is running: - if RX_Next_Status_Trigger = RX_Next; or - if RX_Next_Status_Trigger = RX_Next + 1 and there is no missing  byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU; or - if RX_Next_Status_Trigger falls outside of the receiving window  and RX_Next_Status_Trigger is not equal to RX_Next + AM_Window_Size: - stop and reset t-Reassembly. - if t-Reassembly is not running (includes the case t-Reassembly is stopped  due to actions above) : - if RX_Next_Highest> RX_Next +1; or RX_Next +  AM_Window_Size >= RX_Next_Highest > RX_Next, or - if RX_Next_Highest = RX_Next + 1 and there is at least one missing  byte segment of the SDU associated with SN = RX_Next before the last byte of all received segments of this SDU: - start t-Reassembly; - set RX_Next_Status_Trigger to RX_Next_Highest.

[0107] In some embodiments, if a status reporting is triggered by expiration of the first timer (t_discardTimer) , the terminal device 110 may construct a status PDU via the Rx side of the RLC entity. That is, a status reporting may be triggered by the expiration of the first timer. The status reporting triggered by the expiration of t_discardTimer may not be prohibited by a prohibit timer for the status reporting (e.g., t-StatusProhibit) . That is, even if the prohibit timer t-StatusProhibit is running, the status reporting triggered by the expiration of t_discardTimer is still reported.

[0108] For illustration, an example procedure may be described as below. When a status reporting has been triggered, a receiving side of an AM RLC  entity shall: - if t-StatusProhibit is not running, or - the STATUS reporting is triggered by the expiration of t_discardTimer: - at the first transmission opportunity indicated by lower layer,  construct a status PDU and submit it to lower layer. - else: - at the first transmission opportunity indicated by lower layer after t- StatusProhibit expires, construct a single status PDU even if status reporting was triggered several times while t-StatusProhibit was running and submit it to lower layer.

[0109] In some embodiments, if a positive acknowledgement for a RLC data packet is received and the RLC data packet is pending for retransmission, the terminal device 110 may cancel or stop the retransmission of the RLC data packet via the Tx side of the RLC entity.

[0110] For illustration, an example procedure may be described as below. When receiving a positive acknowledgement for an RLC SDU with SN = x, the  transmitting side of an AM RLC entity shall: - send an indication to the upper layers of successful delivery of the RLC  SDU (e.g., if the RLC SDU is not pending for retransmission) ; - cancel / stop retransmission of the RLC SDU if the RLC SDU is pending for  retransmission; - set TX_Next_Ack equal to the SN of the RLC SDU with the smallest SN,  whose SN falls within the range TX_Next_Ack ≤ SN ≤ TX_Next and for which a positive acknowledgment has not been received yet.

[0111] In this example procedures, TX_Next_Ack denotes an acknowledgement state variable which holds a value of a SN of a next RLC SDU for which a positive acknowledgment is to be received in-sequence, and serves as a lower edge of a transmitting window, and TX_Next denotes a send state variable which holding a value of a SN to be assigned for a next newly generated AMD PDU. TX_Next_Ack is initially set to 0, and is updated whenever the AM RLC entity receives a positive acknowledgment for a RLC SDU with SN = TX_Next_Ack. TX_Next is initially set to 0, and is updated whenever the AM RLC entity constructs an AMD PDU with SN = TX_Next and contains a RLC SDU or the last segment of a RLC SDU.

[0112] So far, solutions of RLC AM management are described. As such, a state variable RX_T is introduced to determine RLC SDU (s) associated with a timer t_discardTimer. When and how to update the state variable is specified. A start / stop condition of the timer t_discardTimer is specified, and an action when the timer t_discardTimer expires are also specified. With the solutions described in connection with the process 200, avoidance of unnecessary retransmissions in a Rx side of a RLC entity may be performed correctly.

[0113] It is to be understood that operations or steps in the above process 200 may be carried out separately or in any suitable combinations.EXAMPLE IMPLEMENTATION OF DSR MANAGEMENT

[0114] Since both enhanced DSR and legacy DSR coexist, it is needed to avoid reporting multiple DSRs. Further, if available UL-SCH resources is not large enough to accommodate an enhanced DSR MAC CE, it is needed to specify how to report delay information.

[0115] In view of this, embodiments of the present disclosure provide a solution of DSR management. This solution will be described in detail with reference to FIG. 3. FIG. 3 illustrates a signaling chart illustrating another example process 300 of communication according to embodiments of the present disclosure. For the purpose of discussion, the process 300 will be described with reference to FIG. 1A. The process 300 may involve the terminal device 110 and the network device 120 as illustrated in FIG. 1A. It is to be understood that the steps and the order of the steps in FIG. 3 are merely for illustration, and not for limitation. For example, the order of the steps may be changed. Some of the steps may be omitted or any suitable additional steps may be added.

[0116] As shown in FIG. 3, at step 310, the terminal device 110 may receive, from the network device 120, at least one configuration indicating a first DSR (e.g., legacy DSR) comprising single set of delay information for each LCG and a second DSR (i.e., enhanced DSR) comprising multiple sets of delay information for each LCG. In some embodiments, the first DSR and the second DSR may be configured in a same configuration. In some embodiments, the first DSR and the second DSR may be configured in separate configurations. In some embodiments, a LCH or LCG may be configured for the first DSR or the second DSR or both.

[0117] In some scenarios, if an enhanced DSR is triggered / reported, it will cover all the delay-critical data. For example, if the enhanced DSR is triggered / reported, it shall guarantee that delay information (including but not limited to shortest remaining time and corresponding buffer size) of packets with PDCP discard timers below a remaining time threshold (e.g., of a LCG or LCH) shall be reported (e.g., even when the largest configured reporting threshold or trigger threshold is lower than a remaining time threshold) . It is needed to avoid report delay information via multiple DSRs.

[0118] In view of this, embodiments of the present disclosure provide a solution of reporting delay information. As shown in step 320, if a second DSR (i.e., enhanced DSR) is triggered, the terminal device 110 may report, in the second DSR, delay information based on a largest one among the following thresholds: a first threshold (e.g., a triggering threshold) for triggering the second DSR, a second threshold (e.g., a largest configured reporting threshold) which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold (e.g., a remaining time threshold) for triggering the first DSR.

[0119] That is, for a LCH or LCG, an enhance DSR MAC CE shall report delay information up to max (trigger threshold  / largest configured reporting threshold, remaining time threshold) . For example, if the enhanced DSR is triggered or reported, the terminal device 110 may report delay information up to the remaining time threshold (e.g., when the largest configured reporting threshold or trigger threshold is lower than the remaining time threshold) or largest configured reporting threshold / trigger threshold (e.g., when the largest configured reporting threshold or trigger threshold is larger than or equal to the remaining time threshold) .

[0120] As such, an unnecessary reporting of a legacy DSR after an enhanced DSR has been reported may be prevented, and thus resources may be saved.

[0121] In some scenarios, if at least one enhanced DSR has been triggered and not cancelled, uplink shared channel (UL-SCH) resources are available for a new transmission and the UL-SCH resources can accommodate an enhanced DSR MAC CE plus its subheader as a result of logical channel prioritization, a terminal device may instruct a multiplexing and assembly procedure to generate enhanced DSR MAC CE (s) . However, how to transmit delay information when there is no enough resource is still unclear.

[0122] In view of this, embodiments of the present disclosure provide a solution of adjusting DSR(s) . As shown in step 330, if an uplink resource is not enough to accommodate a MAC CE for the second DSR (i.e., enhance DSR MAC CE) , the terminal device 110 may adjust at least one of the first DSR (e.g., legacy DSR) or the second DSR (i.e., enhanced DSR) .

[0123] In some embodiments, the terminal device 110 may report the first DSR with delay information up to a largest one among the first threshold, the second threshold, and the third threshold. In some embodiments, the terminal device 110 may report the first DSR with delay information up to the second threshold or one of the set of thresholds. In some embodiments, the terminal device 110 may report the first DSR with delay information up to the third threshold.

[0124] For example, if at least one enhanced DSR has been triggered and not cancelled, and available UL-SCH resources is not large enough to accommodate an enhanced DSR MAC CE, the legacy DSR may be reported with delay information up to at least one of the following: max (largest configured reporting threshold  / trigger threshold, remaining time threshold) ; largest configured reporting threshold or one of the configured reporting thresholds for enhanced DSR; or remaining time threshold.

[0125] As such, delay information in the first DSR may be adjusted.

[0126] In some embodiments, the terminal device 110 may report the second DSR with at most one pair of delay information for a LCG. In some embodiments, the enhanced DSR shall be reported with at most one pair of delay information for a LCG, and the pair shall include all the delay information with remaining time below a configured threshold (e.g., largest configured reporting threshold, trigger threshold or remaining time threshold) . As such, delay information in the second DSR may be adjusted by controlling number of pairs of delay information.

[0127] In some embodiments, the terminal device 110 may merge delay information of one or more pairs in the multiple pairs of delay information in the second DSR. In some embodiments, some delay information of different pairs or levels shall be merged, until available UL-SCH resources can accommodate the enhanced DSR MAC CE. As such, delay information in the second DSR may be adjusted by merging some delay information.

[0128] In some embodiments, the terminal device 110 may report a truncated MAC CE for the second DSR. As such, delay information in the second DSR may be adjusted with the truncated MAC CE.

[0129] In some embodiments, the terminal device 110 may report the first DSR via a first part of the LCG and the second DSR via a second part of the LCG. For example, some of a LCG shall report legacy DSR information (only one pair of delay information for the LCG) and other LCGS shall report enhance DSR information (with multiple pairs) . As such, delay information in the first and second DSRs may be adjusted.

[0130] It is to be noted that a pair of delay information herein includes but not limited to shortest remaining time and corresponding buffer size of packet with PDCP discard timers below a configured threshold (e.g., configured reporting threshold or remaining time threshold) . Delay information of multiple pairs or delay levels may be reported for a LCG / LCH.

[0131] In some scenarios, if the trigger threshold is larger than the largest configured reporting threshold, there may be triggered enhanced DSR but no delay data below largest configured reporting threshold, i.e., enhanced DSR is triggered but no delay information is reported. FIG. 4 illustrates an example DSR scenario 400 in which some embodiments of the present disclosure can be implemented. As shown in FIG. 4, the trigger threshold is larger than the largest configured reporting threshold. If there is no data with remaining time below the largest configured reporting threshold, the enhance DSR shall be triggered but no delay information is to be reported.

[0132] In view of this, embodiments of the present disclosure provide a solution of triggering a DSR. As shown in step 340, if there is data with remaining time below the first threshold (e.g., the triggering threshold) and there is data with remaining time below one of the set of thresholds (e.g., the largest configured reporting threshold) , the terminal device 110 may trigger the second DSR (i.e., enhanced DSR) . As such, delay information may be reported properly.

[0133] So far, solutions for DSR management are described. With the solutions, if available UL-SCH resources is not large enough to accommodate an enhanced DSR MAC CE, the legacy DSR or enhanced DSR with reduced / combined delay information may be reported, and thus delay information may be reported properly.

[0134] It is to be understood that operations or steps in the above process 300 may be carried out separately or in any suitable combinations.EXAMPLE IMPLEMENTATION OF METHODS

[0135] Corresponding to the above processes, embodiments of the present disclosure provide at least methods of communication implemented at a first device and a terminal device. The first device may be a terminal device or a network device. These methods will be described below with reference to FIGs. 5 and 6.

[0136] FIG. 5 illustrates a flowchart of an example method 500 of communication implemented at a first device in accordance with some embodiments of the present disclosure. For the purpose of discussion, in the following, the method 500 will be described with reference to FIG. 1A. It is to be understood that the method 500 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0137] At block 510, a first device (e.g., the terminal device 110 or the network device 120) may maintain a first state variable via a receiving side of a RLC entity. In some embodiments, the first device may maintain the first state variable based at least on one or more of the following: a first timer (e.g., t_discardTimer) , a reassembly timer (e.g., t_Reassembly) , a receive state variable (e.g., RX_Next) , a reassembly timer state variable (e.g., RX_Next_Status_Trigger) , a maximum status transmit state variable (e.g., RX_Highest_Status) , or a highest received state variable (e.g., RX_Next_Highest) .

[0138] In some embodiments, the first state variable may be initially set to zero.

[0139] In some embodiments, the first device may maintain the first state variable by: in accordance with a determination that the first timer is started or a condition for starting the first timer is satisfied, setting the first state variable based on one of the following: the highest received state variable, the maximum status transmit state variable, the reassembly timer state variable, a sequence number of a first RLC data packet with a sequence number greater than a current, first or largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed, or a sequence number of a first RLC data packet with a sequence number greater than the first state variable or the receive state variable for which not all bytes have been received or discarded or missed.

[0140] In some embodiments, the first device may maintain the first state variable by: in accordance with a determination that the reassembly timer expires, performing a first operation comprising at least one of the following: starting the first timer, causing one or more RLC data packets with a sequence number smaller than the maximum status transmit state variable or the highest received state variable to be associated with the first timer, or setting the first state variable based on the reassembly timer state variable, the maximum status transmit state variable, or the highest received state variable.

[0141] In some embodiments, the first device may maintain the first state variable by: in accordance with a determination that a first condition associated with the highest received state variable is satisfied, performing a second operation comprising at least one of the following: starting the first timer, causing one or more RLC data packets with a sequence number smaller than the highest received state variable to be associated with the first timer, or setting the first state variable based on the highest received state variable or a sequence number of a first RLC data packet with a sequence number greater than a current, first or largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed.

[0142] In some embodiments, the first condition may comprise one of the following: the highest received state variable is greater than the receive state variable; the highest received state variable is smaller than or equal to a sum of the receive state variable and a window size and is greater than the receive state variable; the highest received state variable is greater than the first state variable or a sum of the first state variable and a first value; or the highest received state variable is greater than the sum of the first state variable and the first value and there is at least one missing byte segment of a data packet associated with a sequence number equal to the first state variable before the last byte of all received segments of the data packet.

[0143] In some embodiments, the first device may maintain the first state variable by: in accordance with a determination that a second condition associated with the reassembly timer state variable is satisfied during running of the first timer, performing, via the receiving side of the RLC entity, a third operation comprising at least one of the following: stopping the first timer; resetting the first timer; or resetting the first state variable.

[0144] In some embodiments, the second condition may comprise one of the following: the reassembly timer state variable is equal to the receive state variable; the reassembly timer state variable is equal to a sum of the receive state variable and a first value and there is no missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet; or the reassembly timer state variable falls outside of a receiving window and the reassembly timer state variable is not equal to a sum of the receive state variable and a window size.

[0145] In some embodiments, the first device may maintain the first state variable by: in accordance with a determination that the first timer expires and a third condition associated with the highest received state variable is satisfied, performing a fifth operation comprising at least one of the following: starting the first timer, or setting the first state variable based on the reassembly timer state variable, the maximum status transmit state variable, the highest received state variable, or a sequence number of a first RLC data packet with a sequence number greater than a largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed.

[0146] In some embodiments, the third condition may comprise one of the following: the highest received state variable is greater than a sum of the maximum status transmit state variable and a first value; the highest received state variable is equal to the sum of the maximum status transmit state variable and the first value and there is at least one missing byte segment of a data packet associated with a sequence number equal to the maximum status transmit state variable before the last byte of all received segments of the data packet; the maximum status transmit state variable is greater than the first state variable; the reassembly timer state variable is greater than the first state variable; or a RLC data packet with a sequence number higher than the receive state variable is delivered to a PDCP layer.

[0147] At block 520, in accordance with a determination that the first timer expires, the first device may determine, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed.

[0148] In some embodiments, in accordance with a determination that the first timer expires, the first device may perform, via the receiving side of the RLC entity, a fourth operation comprising at least one of the following: updating the receive state variable to a sequence number of a first RLC data packet with a sequence number greater than the first state variable or the receive state variable for which not all bytes have been received or discarded or missed; in accordance with a determination that the maximum status transmit state variable is smaller than the first state variable, updating the maximum status transmit state variable to a sequence number of a first RLC data packet with a sequence number greater than or equal to the first state variable or the maximum status transmit state variable or the reassembly timer state variable for which not all bytes have been received or discarded or missed; or in accordance with a determination that the maximum status transmit state variable is smaller than the first state variable, stopping and resetting the reassembly timer.

[0149] In some embodiments, in accordance with a determination that the first timer expires, the first device may perform, via the receiving side of the RLC entity, a sixth operation comprising at least one of the following: in accordance with a determination that the reassembly timer is running, stopping and resetting the reassembly timer based on one of the following: the reassembly timer state variable is equal to the receive state variable, the reassembly timer state variable is equal to a sum of the receive state variable and a first value, and there is no missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet, or the reassembly timer state variable falls outside of a receiving window and the reassembly timer state variable is not equal to a sum of the receive state variable and a window size; or in accordance with a determination that the reassembly timer is not running, starting the reassembly timer and setting the reassembly timer state variable to the highest received state variable based on one of the following: the highest received state variable is greater than the sum of the receive state variable and the first value, the highest received state variable is smaller than or equal to the sum of the receive state variable and the window size, and is greater than the receive state variable, or the highest received state variable is equal to the sum of the receive state variable and the first value, and there is at least one missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet.

[0150] In some embodiments, in accordance with a determination that a status reporting is triggered by expiration of the first timer, the first device may construct a status PDU via the receiving side of the RLC entity. In some embodiments, in accordance with a determination that a positive acknowledgement for a RLC data packet is received and the RLC data packet is pending for retransmission, the first device may cancel or stop the retransmission of the RLC data packet via a transmitting side of the RLC entity.

[0151] With the method 500, avoidance of unnecessary retransmissions in a Rx side of a RLC entity may be performed correctly.

[0152] FIG. 6 illustrates a flowchart of an example method 600 of communication implemented at a terminal device in accordance with some embodiments of the present disclosure. For example, the method 600 may be performed at the terminal device 110 as shown in FIG. 1A. For the purpose of discussion, in the following, the method 600 will be described with reference to FIG. 1A. It is to be understood that the method 600 may include additional blocks not shown and / or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

[0153] At block 610, a terminal device (e.g., the terminal device 110) may receive, from a network device (e.g., the network device 120) , at least one configuration indicating a first DSR comprising single set of delay information for each LCG and a second DSR comprising multiple sets of delay information for each LCG.

[0154] At block 620, the terminal device may perform an operation comprising at least one of the following: in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR; in accordance with a determination that an uplink resource is not enough to accommodate a MAC CE for the second DSR, adjusting at least one of the first DSR or the second DSR; or in accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR.

[0155] In some embodiments, the terminal device may adjust at least one of the first DSR or the second DSR by one or more of the following: reporting the first DSR with delay information up to at least one of the following: a largest one among the first threshold, the second threshold, and the third threshold, the second threshold or one of the set of thresholds, or the third threshold; reporting the second DSR with at most one pair of delay information for a LCG; merging delay information of one or more pairs in the multiple pairs of delay information; reporting a truncated MAC CE for the second DSR; or reporting the first DSR via a first part of the LCG and the second DSR via a second part of the LCG.

[0156] With the method 600, delay information may be reported properly.

[0157] It is to be understood that operations of the methods 500 and 600 correspond to the processes described in connection with FIGs. 2 to 4, and thus other details are not repeated here for conciseness.EXAMPLE IMPLEMENTATION OF DEVICES

[0158] FIG. 7 is a simplified block diagram of a device 700 that is suitable for implementing embodiments of the present disclosure. The device 700 can be considered as a further example implementation of the terminal device 110 or the network device 120 as shown in FIG. 1A. Accordingly, the device 700 can be implemented at or as at least a part of the terminal device 110 or the network device 120. As shown, the device 700 includes a processor 710, a memory 720 coupled to the processor 710, a suitable transceiver 740 coupled to the processor 710, and a communication interface coupled to the transceiver 740. The memory 710 stores at least a part of a program 730. The transceiver 740 may be for bidirectional communications or a unidirectional communication based on requirements. The transceiver 740 may include at least one of a transmitter 742 or a receiver 744. The transmitter 742 and the receiver 744 may be functional modules or physical entities. The transceiver 740 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 / Xn interface for bidirectional communications between eNBs / gNBs, S1 / NG interface for communication between a mobility management entity (MME)  / access and mobility management function (AMF)  / SGW / UPF and the eNB / gNB, Un interface for communication between the eNB / gNB and a relay node (RN) , or Uu interface for communication between the eNB / gNB and a terminal device.

[0159] The program 730 is assumed to include program instructions that, when executed by the associated processor 710, enable the device 700 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGs. 1A to 6. The embodiments herein may be implemented by computer software executable by the processor 710 of the device 700, or by hardware, or by a combination of software and hardware. The processor 710 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 710 and memory 720 may form processing means 750 adapted to implement various embodiments of the present disclosure.

[0160] The memory 720 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 720 is shown in the device 700, there may be several physically distinct memory modules in the device 700. The processor 710 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 700 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

[0161] In some embodiments, a device comprises a circuitry configured to perform the method 500 or 600. The term ‘circuitry’ used herein may refer to hardware circuits and / or combinations of hardware circuits and software. For example, the circuitry may be a combination of analog and / or digital hardware circuits with software / firmware. As a further example, the circuitry may be any portions of hardware processors with software including digital signal processor (s) , software, and memory (ies) that work together to cause an apparatus, such as a terminal device or a network device, to perform various functions. In a still further example, the circuitry may be hardware circuits and or processors, such as a microprocessor or a portion of a microprocessor, that requires software / firmware for operation, but the software may not be present when it is not needed for operation. As used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (s) or a portion of a hardware circuit or processor (s) and its (or their) accompanying software and / or firmware.

[0162] Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0163] The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above with reference to FIGs. 1A to 6. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

[0164] Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0165] The above program code may be embodied on a machine readable medium, which may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0166] Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

[0167] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1.A first device, comprising:a processor configured to cause the first device to:maintain, via a receiving side of a radio link control (RLC) entity, a first state variable based at least on one or more of the following:a first timer,a reassembly timer,a receive state variable,a reassembly timer state variable,a maximum status transmit state variable, ora highest received state variable; andin accordance with a determination that the first timer expires, determine, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed.2.The first device of claim 1, wherein the first state variable is initially set to zero.3.The first device of claim 1, wherein the first device is caused to maintain the first state variable by:in accordance with a determination that the first timer is started or a condition for starting the first timer is satisfied, setting the first state variable based on one of the following:the highest received state variable,the maximum status transmit state variable,the reassembly timer state variable,a sequence number of a first RLC data packet with a sequence number greater than a current, first or largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed, ora sequence number of a first RLC data packet with a sequence number greater than the first state variable or the receive state variable for which not all bytes have been received or discarded or missed.4.The first device of claim 1, wherein the first device is caused to maintain the first state variable by:in accordance with a determination that the reassembly timer expires, performing a first operation comprising at least one of the following:starting the first timer,causing one or more RLC data packets with a sequence number smaller than the maximum status transmit state variable or the highest received state variable to be associated with the first timer, orsetting the first state variable based on the reassembly timer state variable, the maximum status transmit state variable, or the highest received state variable.5.The first device of claim 1, wherein the first device is caused to maintain the first state variable by:in accordance with a determination that a first condition associated with the highest received state variable is satisfied, performing a second operation comprising at least one of the following:starting the first timer,causing one or more RLC data packets with a sequence number smaller than the highest received state variable to be associated with the first timer, orsetting the first state variable based on the highest received state variable or a sequence number of a first RLC data packet with a sequence number greater than a current, first or largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed.6.The first device of claim 5, wherein the first condition comprises one of the following:the highest received state variable is greater than the receive state variable;the highest received state variable is smaller than or equal to a sum of the receive state variable and a window size and is greater than the receive state variable;the highest received state variable is greater than the first state variable or a sum of the first state variable and a first value; orthe highest received state variable is greater than the sum of the first state variable and the first value and there is at least one missing byte segment of a data packet associated with a sequence number equal to the first state variable before the last byte of all received segments of the data packet.7.The first device of claim 1, wherein the first device is caused to maintain the first state variable by:in accordance with a determination that a second condition associated with the reassembly timer state variable is satisfied during running of the first timer, performing, via the receiving side of the RLC entity, a third operation comprising at least one of the following:stopping the first timer;resetting the first timer; orresetting the first state variable.8.The first device of claim 7, wherein the second condition comprises one of the following:the reassembly timer state variable is equal to the receive state variable;the reassembly timer state variable is equal to a sum of the receive state variable and a first value and there is no missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet; orthe reassembly timer state variable falls outside of a receiving window and the reassembly timer state variable is not equal to a sum of the receive state variable and a window size.9.The first device of claim 1, wherein the first device is further caused to:in accordance with a determination that the first timer expires, perform, via the receiving side of the RLC entity, a fourth operation comprising at least one of the following:updating the receive state variable to a sequence number of a first RLC data packet with a sequence number greater than the first state variable or the receive state variable for which not all bytes have been received or discarded or missed;in accordance with a determination that the maximum status transmit state variable is smaller than the first state variable, updating the maximum status transmit state variable to a sequence number of a first RLC data packet with a sequence number greater than or equal to the first state variable or the maximum status transmit state variable or the reassembly timer state variable for which not all bytes have been received or discarded or missed; orin accordance with a determination that the maximum status transmit state variable is smaller than the first state variable, stopping and resetting the reassembly timer.10.The first device of claim 1, wherein the first device is caused to maintain the first state variable by:in accordance with a determination that the first timer expires and a third condition associated with the highest received state variable is satisfied, performing a fifth operation comprising at least one of the following:starting the first timer, orsetting the first state variable based on the reassembly timer state variable, the maximum status transmit state variable, the highest received state variable, or a sequence number of a first RLC data packet with a sequence number greater than a largest sequence number of delivered RLC data packets for which not all bytes have been received or discarded or missed.11.The first device of claim 10, wherein the third condition comprises one of the following:the highest received state variable is greater than a sum of the maximum status transmit state variable and a first value;the highest received state variable is equal to the sum of the maximum status transmit state variable and the first value and there is at least one missing byte segment of a data packet associated with a sequence number equal to the maximum status transmit state variable before the last byte of all received segments of the data packet;the maximum status transmit state variable is greater than the first state variable;the reassembly timer state variable is greater than the first state variable; ora RLC data packet with a sequence number higher than the receive state variable is delivered to a packet data convergence protocol (PDCP) layer.12.The first device of claim 1, wherein the first device is further caused to:in accordance with a determination that the first timer expires, perform, via the receiving side of the RLC entity, a sixth operation comprising at least one of the following:in accordance with a determination that the reassembly timer is running, stopping and resetting the reassembly timer based on one of the following:the reassembly timer state variable is equal to the receive state variable,the reassembly timer state variable is equal to a sum of the receive state variable and a first value, and there is no missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet, orthe reassembly timer state variable falls outside of a receiving window and the reassembly timer state variable is not equal to a sum of the receive state variable and a window size; orin accordance with a determination that the reassembly timer is not running, starting the reassembly timer and setting the reassembly timer state variable to the highest received state variable based on one of the following:the highest received state variable is greater than the sum of the receive state variable and the first value,the highest received state variable is smaller than or equal to the sum of the receive state variable and the window size, and is greater than the receive state variable, orthe highest received state variable is equal to the sum of the receive state variable and the first value, and there is at least one missing byte segment of a data packet associated with a sequence number equal to the receive state variable before the last byte of all received segments of the data packet.13.The first device of claim 1, wherein the first device is further caused to:in accordance with a determination that a status reporting is triggered by expiration of the first timer, construct a status protocol data unit (PDU) via the receiving side of the RLC entity; orin accordance with a determination that a positive acknowledgement for a RLC data packet is received and the RLC data packet is pending for retransmission, cancel or stop the retransmission of the RLC data packet via a transmitting side of the RLC entity.14.The first device of claim 1, wherein the first device is a terminal device or a network device.15.A terminal device, comprising:a processor configured to cause the terminal device to:receive, from a network device, at least one configuration indicating a first delay status reporting (DSR) comprising single set of delay information for each logical channel group (LCG) and a second DSR comprising multiple sets of delay information for each LCG; andperform an operation comprising at least one of the following:in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR,in accordance with a determination that an uplink resource is not enough to accommodate a medium access control (MAC) control element (CE) for the second DSR, adjusting at least one of the first DSR or the second DSR, orin accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR.16.The terminal device of claim 15, wherein the terminal device is caused to adjust at least one of the first DSR or the second DSR by one or more of the following:reporting the first DSR with delay information up to at least one of the following:a largest one among the first threshold, the second threshold, and the third threshold,the second threshold or one of the set of thresholds, orthe third threshold;reporting the second DSR with at most one pair of delay information for a LCG;merging delay information of one or more pairs in the multiple pairs of delay information;reporting a truncated MAC CE for the second DSR; orreporting the first DSR via a first part of the LCG and the second DSR via a second part of the LCG.17.A method of communication at a first device, comprising:maintaining, via a receiving side of a radio link control (RLC) entity, a first state variable based at least on one or more of the following:a first timer,a reassembly timer,a receive state variable,a reassembly timer state variable,a maximum status transmit state variable, ora highest received state variable; andin accordance with a determination that the first timer expires, determining, based on the first state variable, a set of RLC data packets associated with the first timer to be discarded or missed.18.A method of communication at a terminal device, comprising:receiving, from a network device, at least one configuration indicating a first delay status reporting (DSR) comprising single set of delay information for each logical channel group (LCG) and a second DSR comprising multiple sets of delay information for each LCG; andperforming an operation comprising at least one of the following:in accordance with a determination that the second DSR is triggered, reporting, in the second DSR, delay information based on a largest one among a first threshold for triggering the second DSR, a second threshold which is a largest one among a set of thresholds for a set of delay ranges in the second DSR, and a third threshold for triggering the first DSR,in accordance with a determination that an uplink resource is not enough to accommodate a medium access control (MAC) control element (CE) for the second DSR, adjusting at least one of the first DSR or the second DSR, orin accordance with a determination that there is data with remaining time below the first threshold and there is data with remaining time below one of the set of thresholds, triggering the second DSR.

Images