Devices and methods of communication

Abstract

Embodiments of the present disclosure relate to devices and methods of communication. In one aspect, upon determination that a RLC SDU fulfills a condition, a transmitting device may perform an operation comprising at least one of the following: discarding the RLC SDU or a segment of the RLC SDU or a RLC PDU corresponding to the RLC SDU; updating a first state variable at least based on a SN of a further RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received, and which are not discarded or whose retransmissions are not stopped; or considering that the positive acknowledgement has been received for the RLC SDU or the RLC SDU has been transmitted successfully. As such, a transmitting window of an AM RLC entity may not be blocked when a RLC SDU is discarded or its retransmission is stopped.

Description

DEVICES AND METHODS OF COMMUNICATIONTECHNICAL FIELD

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

[0002] Currently, it is expected to further enhance delay-sensitive traffic such as extended reality (XR) services. For user plane, it is proposed to make radio link control (RLC) retransmission enhancements for RLC acknowledged mode (AM) with small packet delay budget and delay-sensitive logical channel prioritization (LCP) enhancements considering delay or deadline information. However, solutions of a RLC AM retransmission and a LCP procedure are still incomplete and need to be further developed.SUMMARY

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

[0004] In a first aspect, there is provided a transmitting device. The transmitting device comprises a processor configured to cause the transmitting device to: determine that a first RLC service data unit (SDU) fulfills a first condition; and perform a first operation comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC protocol data unit (PDU) corresponding to the first RLC SDU, updating a first state variable at least based on a SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped, or considering that a positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.

[0005] In a second aspect, there is provided a receiving device. The receiving device comprises a processor configured to cause the receiving device to: determine that a status reporting is triggered; and construct a status PDU for the status reporting by at least one of  the following: setting, based on a value of a sequence number (SN) of a next RLC SDU which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU, or considering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.

[0006] In a third aspect, there is provided a receiving device. The receiving device comprises a processor configured to cause the receiving device to: receive, from a transmitting device, second information of a first RLC SDU which has been discarded or whose retransmission has been stopped; and perform a second operation comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU, or updating a set of state variables based on a SN of the first RLC SDU.

[0007] In a fourth 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, third information indicating whether a LCP procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a message A (MsgA) transmission; and perform the LCP procedure at least based on the third information.

[0008] In a fifth aspect, there is provided a method of communication. The method comprises: determining, at a transmitting device, that a first RLC SDU fulfills a first condition; and performing a first operation comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU; updating a first state variable at least based on a second SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped; or considering that the positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.

[0009] In a sixth aspect, there is provided a method of communication. The method comprises: determining, at a receiving device, that a status reporting is triggered; and constructing a status PDU for the status reporting by at least one of the following: setting, based on a value of a SN of a next RLC SDU which is not indicated as missing in the status  PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU, or considering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.

[0010] In a seventh aspect, there is provided a method of communication. The method comprises: receiving, at a receiving device and from a transmitting device, second information of a first RLC SDU which has been discarded or whose retransmission has been stopped; and performing a second operation comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU, or updating a set of state variables based on a SN of the first RLC SDU.

[0011] In an eighth aspect, there is provided a method of communication. The method comprises: receiving, at a terminal device and from a network device, third information indicating whether a LCP procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a MsgA transmission; and performing the LCP procedure at least based on the third information.

[0012] In a ninth 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 any of the fifth to eighth aspects of the present disclosure.

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

[0014] 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:

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

[0016] FIG. 2 illustrates a signaling chart illustrating an example process of communication for RLC AM retransmission according to embodiments of the present disclosure;

[0017] FIG. 3 illustrates a signaling chart illustrating an example process of communication for a LCP procedure according to embodiments of the present disclosure;

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

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

[0020] FIG. 6 illustrates a flowchart of another example method of communication implemented at a receiving device in accordance with some embodiments of the present disclosure;

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

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

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

[0024] 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.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] The terminal device or the network device may have artificial intelligence (AI) or machine learning 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.

[0029] The terminal 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.

[0030] 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.

[0031] 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, first information may be transmitted to the terminal device from the first network device and second information 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.

[0032] 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. Other definitions, explicit and implicit, may be included below.

[0033] 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.

[0034] In the context of the present disclosure, the term ‘a LCP procedure considering delayed data’ herein may be interchangeably used with ‘delay-sensitive LCP’ or ‘delay-sensitive LCP procedure’ or ‘delay awareness LCP’ or ‘delay awareness LCP procedure’ or ‘an LCP procedure’ or ‘delay-sensitive mechanism’ .

[0035] In the context of the present disclosure, if a delay of buffered data exceeds a configured threshold, or remaining delay budget of buffered data (e.g., remaining time of a packet data convergence protocol (PDCP) discard timer) is less than a configured threshold, the buffered data is considered as delayed data. Otherwise, the buffered data is non-delayed data. It is to be understood that any other ways to distinguish the delayed data and the non-delayed data are also feasible.

[0036] Principles and implementations of the present disclosure will be described in detail below with reference to the figures.

[0037] EXAMPLE OF COMMUNICATION NETWORK

[0038] FIG. 1 illustrates a schematic diagram of an example communication network 100 in which some embodiments of the present disclosure can be implemented. As shown in FIG. 1, the communication network 100 may include a terminal device 110 and a network device 120. The network device 120 may provide a serving cell 121. The terminal device 110 may be located in the serving cell 121 and may be served by the network device 120. It is to be understood that the network device 120 may provide more serving cells to serve one or more terminal devices.

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

[0040] As shown in FIG. 1, 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 100 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.

[0041] EXAMPLE IMPLEMENTATION OF RLC AM RETRANSMISSION

[0042] As known, delay-sensitive traffic such as extended reality (XR) services have strict latency requirements. Since any data which has exceeded a PDU delay budget (PDB)  / PDU set delay budget (PSDB) may not be useful, it is required to avoid sending these useless data to save radio resources.

[0043] RLC AM retransmission is typically used for services which require no packet loss but without stringent latency requirement. Shortcomings of RLC AM are not negligible for typical XR services which have strict latency requirements and certain reliability requirements. A conventional RLC AM mechanism does not consider remaining delay budget of a packet, and never gives up retransmission until successful transmission is confirmed or a radio link failure (RLF) is triggered. Thus, it may cause inefficiency in handling retransmissions of data packets within the stringent delay requirements of XR services, for example, unnecessary RLC AM retransmission when the remaining delay budget is almost exhausted.

[0044] If a RLC SDU is retransmitted, it means that a RLC SN (may also referred to as a SN herein) has been assigned to the RLC SDU and either the RLC SDU or segment thereof has been submitted to lower layers. Then, early stop of the retransmission of the RLC SDU may introduce a RLC SN gap and block advancement of a receiving window, since the RLC SDU may never be successfully received by a receiving side of an AM RLC entity. Similarly, discarding a RLC SDU may also introduce a RLC SN gap if either the RLC SDU or segment thereof has been submitted to the lower layers. Both cases may stall or block advancement of a transmitting window or a receiving window of an AM RLC entity.

[0045] In view of this, embodiments of the present disclosure provide solutions of communication for RLC AM retransmission. In one aspect, upon determination that a RLC SDU (for convenience, also referred to as a first RLC SDU herein) fulfills a condition (for convenience, also referred to as a first condition herein) , a transmitting device (e.g., a  transmitting side of an AM RLC entity) may perform an operation (for convenience, also referred to as a first operation herein) comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU; updating a first state variable at least based on a second SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped; or considering that the positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully. In this way, a transmitting window of an AM RLC entity may not be stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0046] In another aspect, upon determination that a status reporting is triggered, a receiving device (e.g., a receiving side of an AM RLC entity) may construct a status PDU for the status reporting by at least one of the following: setting, based on a value of a SN of a next RLC SDU which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU; or considering that a RLC SDU (for convenience, also referred to as a first RLC SDU herein) which has been discarded or whose retransmission has been stopped is successfully received. In this way, a transmitting window of an AM RLC entity may also not be stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0047] In still another aspect, a receiving device (e.g., a receiving side of an AM RLC entity) may receive, from a transmitting device (e.g., a transmitting side of an AM RLC entity) , second information of a first RLC SDU which has been discarded or whose retransmission has been stopped. Based on reception of the second information, the receiving device may perform an operation (for convenience, also referred to as a second operation herein) comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU; or updating a set of state variables based on a SN of the first RLC SDU. In this way, a receiving window of an AM RLC entity may not be stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0048] For illustration, these solutions will be described in details in connection with FIG. 2 below. FIG. 2 illustrates a signaling chart illustrating an example process 200 of  communication for RLC AM retransmission according to embodiments of the present disclosure. The process 200 may involve a transmitting device and a receiving device. For convenience, the process 200 may be described in connection with FIG. 1. 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.

[0049] In the context of the present disclosure, the term ‘a transmitting device’ may refer to a device transmitting a RLC SDU as a transmitting side of an AM RLC entity, and the term ‘a receiving device’ may refer to a device receiving a RLC SDU as a receiving side of an AM RLC entity. In some embodiments, the transmitting device may be a terminal device (e.g., the terminal device 110) and the receiving device may be a network device (e.g., the network device 120) . In some embodiments, the transmitting device may be a network device (e.g., the network device 120) and the receiving device may be a terminal device (e.g., the terminal device 110) .

[0050] As shown in FIG. 2, upon determination that a first RLC SDU fulfills a first condition, the transmitting device may perform 210 a first operation so as to facilitate advancement of a transmitting window. In other words, if the first condition is fulfilled, a transmitting side of an AM RLC entity may not wait for an acknowledgement of the first RLC SDU and may advance the transmitting window by performing the first operation.

[0051] In some embodiments, the first condition may comprise that the first RLC SDU is discarded. In some embodiments, the first RLC SDU may be considered as discarded due to an indication of discard received from an upper layer (e.g., a PDCP layer) . In other words, when the first RLC SDU with SN=x is discarded, the transmitting device may perform the first operation.

[0052] In some embodiments, the first condition may comprise that a retransmission of the first RLC SDU is stopped. In other words, when the retransmission of the first RLC SDU with SN=x is stopped, the transmitting device may perform the first operation.

[0053] In some embodiments, the first condition may comprise that first information is configured. The first information indicates that discarding the first RLC SDU or stopping the retransmission of the first RLC SDU is allowed even if the first RLC SDU or the segment of the first RLC SDU has been submitted to lower layers (e.g., per data radio bearer (DRB) or per RLC entity) . For example, a terminal device may be configured to discard the first  RLC SDU or stop the retransmission of the first RLC SDU even if the RLC SDU or a segment thereof has been submitted to the lower layers. In other words, in the case that the first information is configured, if the first RLC SDU is to be discarded or the retransmission of the first RLC SDU is to be stopped, the transmitting device may perform the first operation.

[0054] In some embodiments, the first condition may comprise that a SN (e.g., SN=x) has been assigned to the first RLC SDU. In other words, if the SN has been assigned to the first RLC SDU, the transmitting device may perform the first operation.

[0055] In some embodiments, the first condition may comprise that a positive acknowledgement is received for the first RLC SDU. In other words, upon reception the positive acknowledgement for the first RLC SDU with SN=x, the transmitting device may perform the first operation.

[0056] It is to be understood that the first condition may comprise any combination of the above conditions or any other suitable conditions or combinations of conditions.

[0057] With reference to FIG. 2, in some embodiments, the first operation may comprise discarding 211 the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU.

[0058] In some embodiments, the first operation may comprise updating 212 a first state variable at least based on a SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped. In some embodiments, the first state variable may be used to hold a value of a SN of a next RLC SDU for which a positive acknowledgement is to be received in-sequence. For example, the first state variable may be TX_Next_Ack. In some embodiments, the second state variable may be used to hold a value of a SN to be assigned for a next newly generated RLC SDU. For example, the second state variable may be TX_Next.

[0059] In some embodiments, the transmitting device may update the first state variable by setting the first state variable to be equal to the SN of the second RLC SDU. For example, a transmitting side of an AM RLC entity may set TX_Next_Ack to be 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 and ‘not be discarded or the retransmission is not stopped’ .

[0060] In some embodiments, the transmitting device may update the first state variable by setting the first state variable to be equal to the SN of the second RLC SDU if a SN (e.g., SN=x) of the first RLC SDU is equal to the first state variable. For example, if x = TX_Next_Ack, a transmitting side of an AM RLC entity may set TX_Next_Ack to be 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 and ‘not be discarded or the retransmission is not stopped’ .

[0061] With reference to FIG. 2, in some embodiments, the first operation may comprise considering 213 that a positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully or completely. In other words, RLC SDUs that have been discarded or whose retransmissions have been stopped may be considered as a positive acknowledgment has been received for the RLC SDUs or the RLC SDUs have been transmitted or received successfully or completely.

[0062] It is to be understood that the first operation may comprise any combination of the above operations or any other suitable operations or combinations of operations.

[0063] For illustration, an example procedure at the transmitting device may be described as below.

[0064] If at least one of the following conditions is met,

[0065] ·when the retransmission of an RLC SDU with SN = x is stopped,

[0066] ·when an RLC SDU with SN = x is discarded (e.g., due to an indication of discard received from upper layer (e.g. PDCP) ) ,

[0067] ·UE is configured to discard an RLC SDU or stop retransmission of an RLC SDU even if the RLC SDU or a segment thereof has been submitted to the lower layers (e.g., per DRB or per RLC entity) ,

[0068] ·an RLC SN has been assigned to the corresponding RLC SDU,

[0069] ·When receiving a positive acknowledgement for an RLC SDU with SN = x, the transmitting side of an AM RLC entity shall perform at least one of the following:

[0070] -discard the corresponding RLC SDU, RLC SDU segment, or RLC PDUs, if any;

[0071] -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 and ‘not be discarded or the retransmission is not stopped’ ;

[0072] -if x = TX_Next_Ack, 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 and ‘not be discarded or the retransmission is not stopped’ ;

[0073] -RLC SDUs that have been discarded or whose retransmission has been stopped may be considered as a positive acknowledgment has been received for the RLC SDUs or has been transmitted / received successfully / completely.

[0074] As such, a transmitting window of an AM RLC entity may be well advanced.

[0075] Continuing to refer to FIG. 2, the transmitting device may transmit 220, to the receiving device, information (for convenience, also referred to as second information herein) of the first RLC SDU which has been discarded or whose retransmission has been stopped. In some embodiments, the transmitting side of the AM RLC entity may indicate, to the receiving side of the AM RLC entity, information of RLC SDUs (e.g., RLC SN) that have been discarded or whose retransmissions have been stopped, e.g., via a RLC control PDU with SN gap information.

[0076] In some embodiments, the second information may comprise an indication for triggering a status reporting of the receiving device. For example, as the indication, a polling bit may be introduced in the RLC control PDU with SN gap information. If the polling bit is set to 1 or any other meaningful values, the receiving side of the AM RLC entity may trigger the status reporting.

[0077] In some embodiments, the second information may comprise a field indicating the RLC SN or RLC SN ranges of RLC SDUs that have been discarded or whose retransmissions have been stopped (e.g., by the transmitting side of the AM RLC entity) .

[0078] Continuing to refer to FIG. 2, upon reception of the second information of the first RLC SDU which has been discarded or whose retransmission has been stopped, the receiving device may perform 230 a second operation so as to facilitate advancement of a receiving window of an AM RLC entity. That is, if information of a RLC SDU (e.g., RLC SN) that has been discarded or whose retransmission has been stopped (e.g., by the transmitting side of the AM RLC entity) is received or got by the receiving side of the AM RLC entity, the receiving side of the AM RLC entity may perform the second operation.

[0079] With reference to FIG. 2, in some embodiments, the second operation may comprise discarding 231 the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU.

[0080] With reference to FIG. 2, in some embodiments, the second operation may comprise updating 232 a set of state variables (i.e., one or more state variables) based on a SN of the first RLC SDU.

[0081] In some embodiments, if the SN of the first RLC SDU is equal to a first value of a third state variable, the receiving device may update the third state variable to be a SN of a third RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped.

[0082] In some embodiments, the third state variable may be used to hold a highest possible value of a SN which can be indicated by a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in a status PDU when the status PDU needs to be constructed.

[0083] For example, the third state variable may be RX_Highest_Status. When a RLC SDU with SN = x is discarded or whose retransmission has been stopped (e.g., indicated in the RLC control PDU with SN gap information) , if x= RX_Highest_Status, a receiving side of an AM RLC entity may update RX_Highest_Status to a SN of a starting (i.e., the first) RLC SDU with SN > current RX_Highest_Status for which not all bytes have been received and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0084] In some embodiments, if the SN of the first RLC SDU is equal to the first value, the receiving device may update the third state variable to be a SN of a fourth RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received, and consider that the first RLC SDU has been successfully received.

[0085] For example, the third state variable may be RX_Highest_Status. When a RLC SDU with SN = x is discarded or whose retransmission has been stopped (e.g., indicated in the RLC control PDU with SN gap information) , if x= RX_Highest_Status, a receiving side of an AM RLC entity may update RX_Highest_Status to a SN of a starting (i.e., the first) RLC SDU with SN > current RX_Highest_Status for which not all bytes have been received. Meanwhile, the RLC SDU that has been discarded or whose retransmission has been stopped may be considered as completely / successfully received.

[0086] In some embodiments, if the SN of the first RLC SDU is equal to a second value of a fourth state variable, the receiving device may update the fifth state variable to be a SN of a sixth RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped.

[0087] In some embodiments, the fourth state variable may be used to hold a value of a SN following a last in-sequence successfully received RLC SDU.

[0088] For example, the fourth state variable may be RX_Next. When a RLC SDU with SN = x is discarded or whose retransmission has been stopped (e.g., indicated in the RLC control PDU with SN gap information) , if x= RX_Next, a receiving side of an AM RLC entity may update RX_Next to a SN of a starting (i.e., the first) RLC SDU with SN > current RX_Next for which not all bytes have been received and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0089] In some embodiments, if the SN of the first RLC SDU is equal to the second value, the receiving device may update the fourth state variable to be a SN of a seventh RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received, and consider that the first RLC SDU has been successfully received.

[0090] For example, the fourth state variable may be RX_Next. When a RLC SDU with SN = x is discarded or whose retransmission has been stopped (e.g., indicated in the RLC control PDU with SN gap information) , if x= RX_Next, a receiving side of an AM RLC entity may update RX_Next to a SN of a starting (i.e., the first) RLC SDU with SN > current RX_Next for which not all bytes have been received. Meanwhile, the RLC SDU that has been discarded or whose retransmission has been stopped may be considered as completely / successfully received.

[0091] For illustration, an example procedure may be described as below.

[0092] When an RLC SDU with SN = x is discarded or whose retransmission has been stopped (e.g., indicated in the RLC control PDU with SN gap information) , the receiving side of an AM RLC entity shall:

[0093] -discard the corresponding RLC SDU, RLC SDU segment, or RLC PDUs, if any;

[0094] -if x = RX_Highest_Status:

[0095] -Option 1: update RX_Highest_Status to the SN of the first RLC SDU with SN >current RX_Highest_Status for which not all bytes have been received and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0096] -Option 2: update RX_Highest_Status to the SN of the first RLC SDU with SN >current RX_Highest_Status for which not all bytes have been received. The RLC SDU that has been discarded or whose retransmission has been stopped may be considered as completely / successfully received.

[0097] -if x = RX_Next:

[0098] -Option 1: update RX_Next to the SN of the first RLC SDU with SN > current RX_Next for which not all bytes have been received and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0099] -Option 2: update RX_Next to the SN of the first RLC SDU with SN > current RX_Next for which not all bytes have been received. The RLC SDU that has been discarded or whose retransmission has been stopped may be considered as completely / successfully received.

[0100] So far, behaviors at a receiving side of an AM RLC entity when a RLC SDU has been discarded or a retransmission of a RLC SDU has been stopped are described. As such, a receiving window of an AM RLC entity may be well advanced.

[0101] Continuing to refer to FIG. 2, in some alternative or additional embodiments, the receiving device may perform 240 enhancements on a status reporting so as to keep advancement of a receiving window of an AM RLC entity. In some embodiments, upon determination that a status reporting is triggered, the receiving device may construct a status PDU to keep the advancement of the receiving window of the AM RLC entity.

[0102] With reference to FIG. 2, in some embodiments, the receiving device may construct 241 the status PDU by setting a first field based on a value of a SN of a next RLC SDU which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped. The first field indicates a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU. For example, the first field is ACK_SN. When constructing the status PDU, the AM RLC entity may set the ACK_SN to the SN of the next ‘not received RLC SDU which is not indicated as missing in the resulting STATUS PDU’ and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0103] With reference to FIG. 2, in some embodiments, the receiving device may construct 242 the status PDU by considering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received (e.g., all bytes have been received) .

[0104] For illustration, an example procedure of constructing a status PDU may be described as below.

[0105] When constructing a status PDU, the AM RLC entity shall:

[0106] -for the RLC SDUs with SN such that RX_Next ≤ SN < RX_Highest_Status that has not been completely received yet, in increasing SN order of RLC SDUs and increasing byte segment order within RLC SDUs, starting with SN = RX_Next up to the point where the resulting STATUS PDU still fits to the total size of RLC PDU (s) indicated by lower layer:

[0107] -for a RLC SDU for which no byte segments have been received yet:

[0108] -include in the STATUS PDU a NACK_SN which is set to the SN of the RLC SDU.

[0109] -for a continuous sequence of byte segments of a partly received RLC SDU that have not been received yet:

[0110] -include in the STATUS PDU a set of NACK_SN, SOstart and SOend.

[0111] -for a continuous sequence of RLC SDUs that have not been received yet:

[0112] -include in the STATUS PDU a set of NACK_SN and NACK range;

[0113] -include in the STATUS PDU, if required, a pair of SOstart and SOend.

[0114] -set the ACK_SN to the SN of the next ‘not received RLC SDU which is not indicated as missing in the resulting STATUS PDU’ and ‘not indicated / considered as discarded or retransmission is not stopped’ .

[0115] In some embodiments, the receiving device may determine whether the status reporting is triggered based on the second information of the first RLC SDU which has been discarded or whose retransmission has been stopped. In some embodiments, if the second information is received from the transmitting device, the receiving device may determine that the status reporting is triggered and may initiate the status reporting. In some embodiments, if the second information comprises the indication for triggering the status reporting, the receiving device may determine that the status reporting is triggered and may initiate the status reporting. For example, if the polling bit in the RLC control PDU (e.g., control PDU  with SN gap information) is set to 1 or any other meaningful values for triggering the status reporting, the receiving device may initiate the status reporting.

[0116] For illustration, an example procedure of triggering a status reporting may be described as below.

[0117] Triggers to initiate STATUS reporting include:

[0118] -Reception of the information of RLC SDUs that has been discarded or whose retransmission has been stopped (e.g. via an RLC Control PDU with SN Gap information) , or

[0119] -the polling bit in the RLC control PDU (e.g., control PDU with RLC SN Gap information) is set to "1 “.

[0120] -trigger a STATUS report.

[0121] -Polling from its peer AM RLC entity:

[0122] -When an AMD PDU with SN = x and the P field set to "1" is received from lower layer, the receiving side of an AM RLC entity shall:

[0123] -if the AMD PDU is to be discarded as specified in clause 5.2.3.2.2; or

[0124] -if x < RX_Highest_Status or x ≥ RX_Next + AM_Window_Size:

[0125] -trigger a STATUS report.

[0126] -else:

[0127] -delay triggering the STATUS report until x < RX_Highest_Status or x ≥ RX_Next + AM_Window_Size.

[0128] NOTE 1: This ensures that the RLC Status report is transmitted after HARQ reordering.

[0129] -Detection of reception failure of an AMD PDU

[0130] -The receiving side of an AM RLC entity shall trigger a STATUS report when t-Reassembly expires.

[0131] NOTE 2: The expiry of t-Reassembly triggers both RX_Highest_Status to be updated and a STATUS report to be triggered, but the STATUS report shall be triggered after RX_Highest_Status is updated.

[0132] In this way, new trigger conditions of the status reporting may be introduced to keep advancement of the receiving window of the AM RLC entity.

[0133] With the process 200, a transmitting window or receiving window of RLC entity may be not stalled or blocked when a RLC SDU is discarded or a retransmission of a RLC SDU is stopped. It is to be understood that the operations described in the process 200 may be carried out separately or in any suitable combinations, and the present disclosure does not limit this aspect.

[0134] EXAMPLE IMPLEMENTATION OF LCP PROCEDURE FOR MSGA TRANSMISSION

[0135] Conventionally, an uplink (UL) grant associated with a physical uplink shared channel (PUSCH) resource of MsgA is reserved for a MsgA transmission. However, if a delay-sensitive LCP is applied to the UL grant, delay critical data of other services may be served first and there may be no enough resource for the MsgA transmission.

[0136] In view of this, embodiments of the present disclosure also provide a solution of communication for a LCP procedure. In the solution, a network device may transmit, to a terminal device, information (for convenience, also referred to as third information herein) indicating whether a LCP procedure considering delayed data is applied for a UL grant associated with a UL resource of a MsgA transmission. The terminal device may perform the LCP procedure at least based on the third information. In this way, a delay-sensitive LCP may be configured to be not applicable for a UL grant associated with a UL resource of a MsgA transmission, and delayed data may not occupy the UL resource reserved for a MsgA transmission.

[0137] For illustration, this solution will be described in details in connection with FIG. 3 below. FIG. 3 illustrates a signaling chart illustrating an example process 300 of communication for a LCP procedure according to embodiments of the present disclosure. For convenience, the process 300 may be described in connection with FIG. 1. The process 300 may involve the terminal device 110 and the network device 120. 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.

[0138] As shown in FIG. 3, the network device 120 may transmit 310, to the terminal device 110, third information indicating whether a LCP procedure considering delayed data (i.e., delay-sensitive LCP) is applied for a UL grant associated with a UL resource (e.g., PUSCH resource) of a MsgA transmission.

[0139] In some embodiments, for UL grant associated with a PUSCH resource of MsgA  (e.g., msgA-PUSCH-Config) , the network device 120 may indicate the terminal device 110 whether to apply a delay-sensitive LCP, e.g., via a RRC signaling. In some embodiments, a field may be introduced to indicate whether the terminal device 110 shall apply the delay-sensitive LCP for the UL grant associated with the PUSCH resource of MsgA. It is to be noted that, for a delay-sensitive LCP, it shall take delay information (e.g., remaining delay budget) of a SDU / PDU into account.

[0140] With reference to FIG. 3, the terminal device 110 may perform 320 the LCP procedure at least based on the third information. In some embodiments, if the third information indicates that the delay-sensitive LCP is not applied for the UL grant associated with the PUSCH resource of MsgA, the terminal device 110 may not apply the delay-sensitive LCP for the UL grant associated with the PUSCH resource of MsgA. In this way, delayed data may not occupy a resource reserved for MsgA.

[0141] In some embodiments, if the third information indicates that the delay-sensitive LCP is applied for the UL grant associated with the PUSCH resource of MsgA, the terminal device 110 may apply the delay-sensitive LCP for the UL grant associated with the PUSCH resource of MsgA. In this way, the delayed data may occupy the resource reserved for MsgA.

[0142] In some additional embodiments, the terminal device 110 may perform the LCP procedure based on any suitable priority orders.

[0143] With the process 300, a flexible configuration of a delay-sensitive LCP for a UL grant associated with a UL resource of a MsgA transmission may be provided.

[0144] EXAMPLE IMPLEMENTATION OF PRIORITY ORDER FOR LCP PROCEDURE

[0145] Currently, a priority order between delayed data and other data or medium access control control element (MAC CE) is still unclear. Thus, embodiments of the present disclosure also provide another solution of communication for a LCP procedure. For convenience, the solution may be described in connection with FIG. 1.

[0146] In the solution, the terminal device 110 may perform a LCP procedure (i.e., delay-sensitive LCP) by considering at least one of the following: a priority of the delayed data is lower than a priority of a MAC CE for cell-radio network temporary identity (C-RNTI) or for data from an uplink-common control channel (UL-CCCH) ; or the priority of the delayed data is higher than a priority of non-delayed data or a logical channel with only non-delayed data.

[0147] In other words, during the LCP procedure, for delayed data or logical channel (s) with delayed data, its priority may be lower than the priority of MAC CE for C-RNTI  / data from UL-CCCH or other MAC CEs (e.g., important for specific functionality) , and / or higher than the non-delayed data or logical channel (s) with only non-delayed data.

[0148] For illustration, an example priority order may be described as below. Logical channels shall be prioritized in accordance with the following order (highest priority listed first) :

[0149] -MAC CE for C-RNTI, or data from UL-CCCH;

[0150] -MAC CE for (Enhanced) BFR, or MAC CE for Configured Grant Confirmation, or MAC CE for Multiple Entry Configured Grant Confirmation;

[0151] -MAC CE for Sidelink Configured Grant Confirmation;

[0152] -...

[0153] -MAC CE for (Extended) Pre-emptive BSR;

[0154] -MAC CE for SL-BSR, with exception of SL-BSR prioritized and SL-BSR included for padding;

[0155] -MAC CE for IAB-MT Recommended Beam Indication, or MAC CE for Desired IAB-MT PSD range, or MAC CE for Desired DL Tx Power Adjustment;

[0156] -delayed data from any Logical Channel, except data from UL-CCCH;

[0157] -data from any Logical Channel, except data from UL-CCCH and / or delayed data from any Logical Channel;

[0158] -MAC CE for Recommended bit rate query;

[0159] -MAC CE for BSR included for padding;

[0160] -MAC CE for SL-BSR included for padding.

[0161] Note: ‘delayed data from any Logical Channel, except data from UL-CCCH’ may be put in any place between ‘MAC CE for C-RNTI, or data from UL-CCCH’ and ‘data from any Logical Channel, except data from UL-CCCH and / or delayed data from any Logical Channel’ .

[0162] As such, a proper priority order for delayed data and other data or MAC CE may be defined and thus the delayed data may be multiplexed in a proper order.

[0163] It is to be noted that this solution of priority order of delayed data may be carried out separately or in combination with the process 300 (i.e., may be applied in the step 320) .

[0164] EXAMPLE IMPLEMENTATION OF METHODS

[0165] Corresponding to the above processes, embodiments of the present disclosure provide methods of communication implemented at a terminal device. These methods will be described below with reference to FIGs. 4 to 7.

[0166] FIG. 4 illustrates a flowchart of an example method 400 of communication implemented at a transmitting device in accordance with some embodiments of the present disclosure. For example, the method 400 may be performed at the terminal device 110 or the network device 120 as shown in FIG. 1. It is to be understood that the method 400 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.

[0167] At block 410, a transmitting device (e.g., the terminal device 110) may determine that a first RLC SDU fulfills a first condition. In some embodiments, the first condition may comprise at least one of the following: the first RLC SDU is discarded; a retransmission of the first RLC SDU is stopped; first information is configured, the first information indicating that discarding the first RLC SDU or stopping the retransmission of the first RLC SDU is allowed even if the first RLC SDU or the segment of the first RLC SDU has been submitted to lower layers; a SN has been assigned to the first RLC SDU; or a positive acknowledgement is received for the first RLC SDU.

[0168] At block 420, the transmitting device may perform a first operation. The first operation comprises at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU; updating a first state variable at least based on a SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped; or considering that a positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.

[0169] In some embodiments, the first state variable (e.g., TX_Next_Ack) may be used to hold a value of a SN of a next RLC SDU for which a positive acknowledgement is to be received in-sequence, and the second state variable (e.g., TX_Next) may be used to hold a  value of a SN to be assigned for a next newly generated RLC SDU.

[0170] In some embodiments, the transmitting device may update the first state variable by: setting the first state variable to be equal to the SN of the second RLC SDU; or in accordance with a determination that a SN of the first RLC SDU is equal to the first state variable, setting the first state variable to be equal to the SN of the second RLC SDU.

[0171] In some embodiments, the transmitting device may transmit, to a receiving device (e.g., the network device 120) , second information of the first RLC SDU which has been discarded or whose retransmission has been stopped, the second information comprising an indication for triggering a status reporting of the receiving device.

[0172] With the method 400, a transmitting window of an AM RLC entity may not be stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0173] FIG. 5 illustrates a flowchart of an example method 500 of communication implemented at a receiving device in accordance with some embodiments of the present disclosure. For example, the method 500 may be performed at the terminal device 110 or the network device 120 as shown in FIG. 1. 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.

[0174] At block 510, a receiving device (e.g., the network device 120) may determine that a status reporting is triggered. In some embodiments, the receiving device may determine that the status reporting is triggered based on at least one of the following: second information of the first RLC SDU is received from a transmitting device (e.g., the terminal device 110) , or the second information comprises an indication for triggering the status reporting.

[0175] At block 520, the receiving device may construct a status PDU for the status reporting. In some embodiments, the receiving device may construct the status PDU by at least one of the following: setting, based on a value of a SN of a next RLC SDU which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU; or considering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.

[0176] With the method 500, a transmitting window of an AM RLC entity may also not be  stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0177] FIG. 6 illustrates a flowchart of another example method 600 of communication implemented at a receiving device in accordance with some embodiments of the present disclosure. For example, the method 600 may be performed at the terminal device 110 or the network device 120 as shown in FIG. 1. 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.

[0178] At block 610, a receiving device (e.g., the network device 120) may receive, from a transmitting device (e.g., the terminal device 110) , second information of a first RLC SDU which has been discarded or whose retransmission has been stopped.

[0179] At block 620, the receiving device may perform a second operation. The second operation comprises at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU; or updating a set of state variables based on a SN of the first RLC SDU.

[0180] In some embodiments, the receiving device may update the set of state variables by: in accordance with a determination that the SN of the first RLC SDU is equal to a first value of a third state variable, updating the third state variable to be a SN of a third RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped; or in accordance with a determination that the SN of the first RLC SDU is equal to the first value, updating the third state variable to be a SN of a fourth RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received, and considering that the first RLC SDU has been successfully received.

[0181] In some embodiments, the third state variable (e.g., RX_Highest_Status) may be used to hold a highest possible value of a SN which can be indicated by a first field (e.g., ACK_SN) indicating a SN of a next RLC SDU which is not received and is not reported as missing in a status PDU when the status PDU needs to be constructed.

[0182] In some embodiments, the receiving device may update the set of state variables by: in accordance with a determination that the SN of the first RLC SDU is equal to a second value of a fourth state variable, updating the fifth state variable to be a SN of a sixth RLC  SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped; or in accordance with a determination that the SN of the first RLC SDU is equal to the second value, updating the fourth state variable to be a SN of a seventh RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received, and considering that the first RLC SDU has been successfully received.

[0183] In some embodiments, the fourth state variable (e.g., RX_Next) may be used to hold a value of a SN following a last in-sequence successfully received RLC SDU.

[0184] With the method 600, a receiving window of an AM RLC entity may not be stalled or blocked when a RLC SDU is discarded or a retransmission of the RLC SDU is stopped.

[0185] FIG. 7 illustrates a flowchart of an example method 700 of communication implemented at a receiving device in accordance with some embodiments of the present disclosure. For example, the method 700 may be performed at the terminal device 110 as shown in FIG. 1. It is to be understood that the method 700 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.

[0186] At block 710, the terminal device 110 may receive, from the network device 120, third information indicating whether a LCP procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a MsgA transmission.

[0187] At block 720, the terminal device 110 may perform the LCP procedure at least based on the third information.

[0188] In some embodiments, the terminal device 110 may perform the LCP procedure by considering at least one of the following: a priority of the delayed data is lower than a priority of a MAC CE for C-RNTI or for data from an UL-CCCH; or the priority of the delayed data is higher than a priority of non-delayed data or a logical channel with only non-delayed data.

[0189] With the method 700, a delay-sensitive LCP may be configured to be not applicable for a UL grant associated with a UL resource of a MsgA transmission, and delayed data may not occupy the UL resource reserved for a MsgA transmission.

[0190] It is to be understood that operations of the methods 400 to 700 correspond to the processes described in connection with FIGs. 2 and 3, and thus other details are not repeated  here for conciseness.

[0191] EXAMPLE IMPLEMENTATION OF DEVICES

[0192] FIG. 8 is a simplified block diagram of a device 800 that is suitable for implementing embodiments of the present disclosure. The device 800 can be considered as a further example implementation of the terminal device 110 or the network device 120 as shown in FIG. 1. Accordingly, the device 800 can be implemented at or as at least a part of the terminal device 110 or the network device 120.

[0193] As shown, the device 800 includes a processor 810, a memory 820 coupled to the processor 810, a suitable transceiver 840 coupled to the processor 810, and a communication interface coupled to the transceiver 840. The memory 810 stores at least a part of a program 830. The transceiver 840 may be for bidirectional communications or a unidirectional communication based on requirements. The transceiver 840 may include at least one of a transmitter 842 or a receiver 844. The transmitter 842 and the receiver 844 may be functional modules or physical entities. The transceiver 840 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.

[0194] The program 830 is assumed to include program instructions that, when executed by the associated processor 810, enable the device 800 to operate in accordance with the embodiments of the present disclosure, as discussed herein with reference to FIGs. 1 to 7. The embodiments herein may be implemented by computer software executable by the processor 810 of the device 800, or by hardware, or by a combination of software and hardware. The processor 810 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 810 and memory 820 may form processing means 850 adapted to implement various embodiments of the present disclosure.

[0195] The memory 820 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 820 is shown in the device 800, there may be several physically distinct memory modules in the device 800. The processor 810 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 800 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.

[0196] In some embodiments, a transmitting device comprises a circuitry configured to: determine that a first RLC SDU fulfills a first condition; and perform a first operation comprising at least one of the following: discarding the first RLC SDU or a segment of the first RLC SDU or a RLC PDU corresponding to the first RLC SDU, updating a first state variable at least based on a SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped, or considering that a positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.

[0197] In some embodiments, a receiving device comprises a circuitry configured to: determine that a status reporting is triggered; and construct a status PDU for the status reporting by at least one of the following: setting, based on a value of a SN of a next RLC SDU which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU, or considering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.

[0198] In some embodiments, a receiving device comprises a circuitry configured to: receive, from a transmitting device, second information of a first RLC SDU which has been discarded or whose retransmission has been stopped; and perform a second operation comprising at least one of the following: discarding the first RLC SDU or a segment of the  first RLC SDU or a RLC PDU corresponding to the first RLC SDU, or updating a set of state variables based on a SN of the first RLC SDU.

[0199] In some embodiments, a terminal device comprises a circuitry configured to: receive, from a network device, third information indicating whether a LCP procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a MsgA transmission; and perform the LCP procedure at least based on the third information.

[0200] 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.

[0201] 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.

[0202] 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. 1 to 7. 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.

[0203] 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.

[0204] 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.

[0205] 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.

[0206] 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 transmitting device, comprising:a processor configured to cause the transmitting device to:determine that a first radio link control (RLC) service data unit (SDU) fulfills a first condition; andperform a first operation comprising at least one of the following:discarding the first RLC SDU or a segment of the first RLC SDU or a RLC protocol data unit (PDU) corresponding to the first RLC SDU,updating a first state variable at least based on a SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped, orconsidering that a positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.2.The transmitting device of claim 1, wherein the first condition comprises at least one of the following:the first RLC SDU is discarded,a retransmission of the first RLC SDU is stopped,first information is configured, the first information indicating that discarding the first RLC SDU or stopping the retransmission of the first RLC SDU is allowed even if the first RLC SDU or the segment of the first RLC SDU has been submitted to lower layers,a SN has been assigned to the first RLC SDU, ora positive acknowledgement is received for the first RLC SDU.3.The transmitting device of claim 1, wherein the transmitting device is caused to update the first state variable by:setting the first state variable to be equal to the SN of the second RLC SDU; orin accordance with a determination that a SN of the first RLC SDU is equal to the first state variable, setting the first state variable to be equal to the SN of the second RLC SDU.4.The transmitting device of claim 1, wherein the transmitting device is further  caused to:transmit, to a receiving device, second information of the first RLC SDU which has been discarded or whose retransmission has been stopped, the second information comprising an indication for triggering a status reporting of the receiving device.5.The transmitting device of claim 1, wherein the first state variable is used to hold a value of a SN of a next RLC SDU for which a positive acknowledgement is to be received in-sequence, and the second state variable is used to hold a value of a SN to be assigned for a next newly generated RLC SDU.6.A receiving device, comprising:a processor configured to cause the receiving device to:determine that a status reporting is triggered; andconstruct a status protocol data unit (PDU) for the status reporting by at least one of the following:setting, based on a value of a sequence number (SN) of a next radio link control (RLC) service data units (SDU) which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU, orconsidering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.7.The receiving device of claim 6, wherein the receiving device is caused to determine that the status reporting is triggered based on at least one of the following:second information of the first RLC SDU is received from a transmitting device, orthe second information comprises an indication for triggering the status reporting.8.A receiving device, comprising:a processor configured to cause the receiving device to:receive, from a transmitting device, second information of a first radio link control (RLC) service data units (SDU) which has been discarded or whose retransmission has been stopped; andperform a second operation comprising at least one of the following:discarding the first RLC SDU or a segment of the first RLC SDU or a RLC protocol data unit (PDU) corresponding to the first RLC SDU, orupdating a set of state variables based on a sequence number (SN) of the first RLC SDU.9.The receiving device of claim 8, wherein the receiving device is caused to update the set of state variables by:in accordance with a determination that the SN of the first RLC SDU is equal to a first value of a third state variable, updating the third state variable to be a SN of a third RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped; orin accordance with a determination that the SN of the first RLC SDU is equal to the first value, updating the third state variable to be a SN of a fourth RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the first value for which not all bytes have been received, and considering that the first RLC SDU has been successfully received.10.The receiving device of claim 9, wherein the third state variable is used to hold a highest possible value of a SN which can be indicated by a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in a status PDU when the status PDU needs to be constructed.11.The receiving device of claim 8, wherein the receiving device is caused to update the set of state variables by:in accordance with a determination that the SN of the first RLC SDU is equal to a second value of a fourth state variable, updating the fifth state variable to be a SN of a sixth RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received and not all bytes have not been considered as discarded or whose retransmissions are not stopped; orin accordance with a determination that the SN of the first RLC SDU is equal to the second value, updating the fourth state variable to be a SN of a seventh RLC SDU with a smallest SN among RLC SDUs whose SNs are greater than the second value for which not all bytes have been received, and considering that the first RLC SDU has been successfully received.12.The receiving device of claim 11, wherein the fourth state variable is used to hold a value of a SN following a last in-sequence successfully received RLC SDU.13.A terminal device, comprising:a processor configured to cause the terminal device to:receive, from a network device, third information indicating whether a logical channel prioritization (LCP) procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a message A (MsgA) transmission; andperform the LCP procedure at least based on the third information.14.The terminal device of claim 13, wherein the terminal device is caused to perform the LCP procedure by considering at least one of the following:a priority of the delayed data is lower than a priority of a medium access control control element (MAC CE) for cell-radio network temporary identity (C-RNTI) or for data from an uplink-common control channel (UL-CCCH) ; orthe priority of the delayed data is higher than a priority of non-delayed data or a logical channel with only non-delayed data.15.A method of communication, comprising:determining, at a transmitting device, that a first radio link control (RLC) service data unit (SDU) fulfills a first condition; andperforming a first operation comprising at least one of the following:discarding the first RLC SDU or a segment of the first RLC SDU or a RLC protocol data unit (PDU) corresponding to the first RLC SDU,updating a first state variable at least based on a second SN of a second RLC SDU with a smallest SN among RLC SDUs whose SNs fall within a range between the first state variable and a second state variable, for which positive acknowledgements have not been received yet, and which are not discarded or whose retransmissions are not stopped, orconsidering that the positive acknowledgement has been received for the first RLC SDU or the first RLC SDU has been transmitted successfully.16.A method of communication, comprising:determining, at a receiving device, that a status reporting is triggered; andconstructing a status protocol data unit (PDU) for the status reporting by at least one of the following:setting, based on a value of a sequence number (SN) of a next radio link control (RLC) service data units (SDU) which is not indicated as missing in the status PDU, and which is not considered as discarded or whose retransmissions is not stopped, a first field indicating a SN of a next RLC SDU which is not received and is not reported as missing in the status PDU, orconsidering that a first RLC SDU which has been discarded or whose retransmission has been stopped is successfully received.17.A method of communication, comprising:receiving, at a receiving device and from a transmitting device, second information of a first radio link control (RLC) service data units (SDU) which has been discarded or whose retransmission has been stopped; andperforming a second operation comprising at least one of the following:discarding the first RLC SDU or a segment of the first RLC SDU or a RLC protocol data unit (PDU) corresponding to the first RLC SDU, orupdating a set of state variables based on a sequence number (SN) of the first RLC SDU.18.A method of communication, comprising:receiving, at a terminal device and from a network device, third information indicating whether a logical channel prioritization (LCP) procedure considering delayed data is applied for an uplink grant associated with an uplink resource of a message A (MsgA) transmission; andperforming the LCP procedure at least based on the third information.

Images