Patent Application
20250113405
Various examples described in this subject disclosure generally relate to apparatus, methods, and computer programs, and more particularly (but not exclusively) to apparatus, methods and computer programs for retransmitting data.
A communication system can be seen as a facility that enables communication sessions between two or more entities such as communication devices, base stations and/or other nodes by providing carriers between the various entities involved in the communications path.
The communication system may be a wireless communication system. Examples of wireless systems comprise public land mobile networks (PLMN) operating based on radio standards such as those provided by 3GPP, satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). The wireless systems can typically be divided into cells, and are therefore often referred to as cellular systems.
The communication system and associated devices operate in accordance with a given set of standards or specifications that set out what the various entities associated with the system are permitted to do and how that is to be achieved. Communication protocols and/or parameters that are to be used for the connection are also typically defined. Examples of standards are the so-called 5G standards.
Communications between different communication devices in a communication system may be controlled between a plurality of corresponding and different protocol stacks comprised in each device. For example, where a data packet is to be retransmitted because it has not been successfully received and/or decoded at a receiver, the retransmission of this data packet may be controlled by at least one protocol layer.
Issues can arise when there are a plurality of protocol layers that are each configured with a respective retransmission mechanism for causing retransmission of a missing data packet. For example, there may be unnecessary latency introduced into the communication system when these retransmission mechanisms are deployed in series.
Several aspects of the various examples described in the subject disclosure are detailed as follows:
According to a first aspect, there is provided an apparatus comprising means for performing: maintaining, at a radio link control, RLC, protocol layer of the apparatus, at least a first RLC entity and a second RLC entity, each of the first and second RLC entities being associated with a respective set of service data units to be acknowledged; determining, by the RLC protocol layer from an indication received from a medium access control, MAC, and/or physical, PHY, protocol layer of the apparatus, that a retransmission procedure of a data packet comprising at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received; causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs based on the determining; and when the first RLC entity and/or the second RLC entity determines that the at least one trigger event has occurred, signalling to a transmitter of the data packet an indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The at least one trigger event may comprise at least one of: a determination that a service data unit of one of said sets of service data units has been received that comprises a sequence number that is out of sequence relative to a sequence number expected to be received for that set of service data units; or a determination that a timer that was started in response to the receipt of the indication from the MAC and/or PHY protocol layer has expired.
The means for determining that a retransmission procedure of a data packet comprising the at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received may comprise means for: receiving an indication from the MAC and/or PHY protocol level that indicates that a maximum number of retransmissions of the data packet has been made at the MAC and/or PHY level; and/or receiving a scheduling indication that indicates that no resources have been allocated for retransmission of the data packet.
For each of said respective sets, the service data units comprised within that respective set may be associated with a reception sequence order that indicates an order in which said service data units are expected to be received within their respective set, and wherein the causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs is performed before the RLC protocol layer receives a service data unit out of sequence to service data units already received by the RLC protocol layer.
The apparatus may further comprise means for performing: receiving, from a transmitter of the data packet, a configuration for causing the at least one first and/or second RLC entity to determine whether the at least one trigger event occurs; and applying the received configuration.
The apparatus may further comprise means for performing: determining whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer; and delaying transmission of said signalling to the transmitter until expiry of said timer.
The apparatus may further comprise means for performing: transmitting said signalling of the indication that the at least one service data unit has not been successfully received by the RLC protocol layer regardless of whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
According to a second aspect, there is provided an apparatus comprising means for performing: determining, for at least one of a first and second radio link control, RLC, entity maintained by an RLC protocol layer of the apparatus, a configuration for corresponding first and second radio RLC entities maintained by an RLC protocol layer of a receiver, wherein the configuration is for causing the at least one first and/or second RLC entity at the receiver to determine whether at least one trigger event occurs in response to the receiver determining that retransmission mechanism performed at a medium access control, MAC, protocol layer and/or physical, PHY, protocol layer has been completed; and providing the configuration to the receiver.
According to a third aspect, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: maintaining, at a radio link control, RLC, protocol layer of the apparatus, at least a first RLC entity and a second RLC entity, each of the first and second RLC entities being associated with a respective set of service data units to be acknowledged; determining, by the RLC protocol layer from an indication received from a medium access control, MAC, and/or physical, PHY, protocol layer of the apparatus, that a retransmission procedure of a data packet comprising at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received; causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs based on the determining; and when the first RLC entity and/or the second RLC entity determines that the at least one trigger event has occurred, signalling to a transmitter of the data packet an indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The at least one trigger event may comprise at least one of: a determination that a service data unit of one of said sets of service data units has been received that comprises a sequence number that is out of sequence relative to a sequence number expected to be received for that set of service data units; or a determination that a timer that was started in response to the receipt of the indication from the MAC and/or PHY protocol layer has expired.
The determining that a retransmission procedure of a data packet comprising the at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received may comprise: receiving an indication from the MAC and/or PHY protocol level that indicates that a maximum number of retransmissions of the data packet has been made at the MAC and/or PHY level; and/or receiving a scheduling indication that indicates that no resources have been allocated for retransmission of the data packet.
For each of said respective sets, the service data units comprised within that respective set may be associated with a reception sequence order that indicates an order in which said service data units are expected to be received within their respective set, and wherein the causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs is performed before the RLC protocol layer receives a service data unit out of sequence to service data units already received by the RLC protocol layer.
The at least one processor may be configured to cause the apparatus to perform: receiving, from a transmitter of the data packet, a configuration for causing the at least one first and/or second RLC entity to determine whether the at least one trigger event occurs; and applying the received configuration.
The at least one processor may be configured to cause the apparatus to perform: determining whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer; and delaying transmission of said signalling to the transmitter until expiry of said timer.
The at least one processor may be configured to cause the apparatus to perform: transmitting said signalling of the indication that the at least one service data unit has not been successfully received by the RLC protocol layer regardless of whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
According to a fourth aspect, there is provided an apparatus comprising at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: determining, for at least one of a first and second radio link control, RLC, entity maintained by an RLC protocol layer of the apparatus, a configuration for corresponding first and second radio RLC entities maintained by an RLC protocol layer of a receiver, wherein the configuration is for causing the at least one first and/or second RLC entity at the receiver to determine whether at least one trigger event occurs in response to the receiver determining that retransmission mechanism performed at a medium access control, MAC, protocol layer and/or physical, PHY, protocol layer has been completed; and providing the configuration to the receiver.
According to a fifth aspect, there is provided a method for an apparatus, the method comprising: maintaining, at a radio link control, RLC, protocol layer of the apparatus, at least a first RLC entity and a second RLC entity, each of the first and second RLC entities being associated with a respective set of service data units to be acknowledged; determining, by the RLC protocol layer from an indication received from a medium access control, MAC, and/or physical, PHY, protocol layer of the apparatus, that a retransmission procedure of a data packet comprising at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received; causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs based on the determining; and when the first RLC entity and/or the second RLC entity determines that the at least one trigger event has occurred, signalling to a transmitter of the data packet an indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The at least one trigger event may comprise at least one of: a determination that a service data unit of one of said sets of service data units has been received that comprises a sequence number that is out of sequence relative to a sequence number expected to be received for that set of service data units; or a determination that a timer that was started in response to the receipt of the indication from the MAC and/or PHY protocol layer has expired.
The determining that a retransmission procedure of a data packet comprising the at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received may comprise: receiving an indication from the MAC and/or PHY protocol level that indicates that a maximum number of retransmissions of the data packet has been made at the MAC and/or PHY level; and/or receiving a scheduling indication that indicates that no resources have been allocated for retransmission of the data packet.
For each of said respective sets, the service data units comprised within that respective set may be associated with a reception sequence order that indicates an order in which said service data units are expected to be received within their respective set, and wherein the causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs is performed before the RLC protocol layer receives a service data unit out of sequence to service data units already received by the RLC protocol layer.
The method may further comprise: receiving, from a transmitter of the data packet, a configuration for causing the at least one first and/or second RLC entity to determine whether the at least one trigger event occurs; and applying the received configuration.
The method may further comprise: determining whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer; and delaying transmission of said signalling to the transmitter until expiry of said timer.
The method may further comprise: transmitting said signalling of the indication that the at least one service data unit has not been successfully received by the RLC protocol layer regardless of whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
According to a sixth aspect, there is provided a method for an apparatus, the method comprising: determining, for at least one of a first and second radio link control, RLC, entity maintained by an RLC protocol layer of the apparatus, a configuration for corresponding first and second radio RLC entities maintained by an RLC protocol layer of a receiver, wherein the configuration is for causing the at least one first and/or second RLC entity at the receiver to determine whether at least one trigger event occurs in response to the receiver determining that retransmission mechanism performed at a medium access control, MAC, protocol layer and/or physical, PHY, protocol layer has been completed; and providing the configuration to the receiver.
According to a seventh aspect, there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: maintaining, at a radio link control, RLC, protocol layer of the apparatus, at least a first RLC entity and a second RLC entity, each of the first and second RLC entities being associated with a respective set of service data units to be acknowledged; determining, by the RLC protocol layer from an indication received from a medium access control, MAC, and/or physical, PHY, protocol layer of the apparatus, that a retransmission procedure of a data packet comprising at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received; causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs based on the determining; and when the first RLC entity and/or the second RLC entity determines that the at least one trigger event has occurred, signalling to a transmitter of the data packet an indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The at least one trigger event may comprise at least one of: a determination that a service data unit of one of said sets of service data units has been received that comprises a sequence number that is out of sequence relative to a sequence number expected to be received for that set of service data units; or a determination that a timer that was started in response to the receipt of the indication from the MAC and/or PHY protocol layer has expired.
The determining that a retransmission procedure of a data packet comprising the at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received may comprise: receiving an indication from the MAC and/or PHY protocol level that indicates that a maximum number of retransmissions of the data packet has been made at the MAC and/or PHY level; and/or receiving a scheduling indication that indicates that no resources have been allocated for retransmission of the data packet.
For each of said respective sets, the service data units comprised within that respective set may be associated with a reception sequence order that indicates an order in which said service data units are expected to be received within their respective set, and wherein the causing at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs is performed before the RLC protocol layer receives a service data unit out of sequence to service data units already received by the RLC protocol layer.
The at least one processor may be configured to cause the apparatus to perform: receiving, from a transmitter of the data packet, a configuration for causing the at least one first and/or second RLC entity to determine whether the at least one trigger event occurs; and applying the received configuration.
The at least one processor may be configured to cause the apparatus to perform: determining whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer; and delaying transmission of said signalling to the transmitter until expiry of said timer.
The at least one processor may be configured to cause the apparatus to perform: transmitting said signalling of the indication that the at least one service data unit has not been successfully received by the RLC protocol layer regardless of whether a timer is running that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
According to an eighth aspect, there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: determining, for at least one of a first and second radio link control, RLC, entity maintained by an RLC protocol layer of the apparatus, a configuration for corresponding first and second radio RLC entities maintained by an RLC protocol layer of a receiver, wherein the configuration is for causing the at least one first and/or second RLC entity at the receiver to determine whether at least one trigger event occurs in response to the receiver determining that retransmission mechanism performed at a medium access control, MAC, protocol layer and/or physical, PHY, protocol layer has been completed; and providing the configuration to the receiver.
According to a ninth aspect, there is provided a non-transitory computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least the method according to any of the preceding aspects.
According to a tenth aspect, there is provided a computer program product stored on a medium that may cause an apparatus to perform any method as described herein.
According to an eleventh aspect, there is provided an electronic device that may comprise apparatus as described herein.
According to a twelfth aspect, there is provided a chipset that may comprise an apparatus as described herein.
In all of the above-mentioned aspects, where a configuration is mentioned, the configuration may comprise a different configuration for each of the first and/or second RLC entity for determining whether the at least one trigger event occurs. The configuration may comprise a same configuration for the first and second RLC entity for determining whether the at least one trigger event occurs. The configuration may comprise an indication to initiate a timer and/or an indication that a sequence number order is to be monitored for detecting whether a service data unit is received out of order.
In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.
Some examples, will now be described, merely by way of illustration only, with reference to the accompanying drawings in which:
The following considers situations in which a retransmission mechanism is deployed at a radio link control (RLC) protocol layer.
In particular, the following aims to provide mechanisms for reducing the amount of time taken for a retransmission mechanism to be deployed at the RLC protocol layer relative to the current time taken. Stated differently, the following aims to improve the latency associated with retransmission mechanisms currently deployed at the RLC protocol layer.
In general, this is achieved by configuring at least part of a receiver's RLC protocol layer to enter an “alert” state when the receiver determines that transmission and/or retransmission procedures at the Physical (PHY) and/or Medium access Control (MAC) protocol layer have been completed in respect of at least one missing transport block. A transport block may be considered to be a fundamental payload that is passed between the transmitter and receiver at the MAC and/or PHY protocol layers. A transport block may be considered as missing when it is not successfully received at the MAC and/or PHY protocol layers.
In this alert state, the RLC protocol layer monitors for at least one trigger event to occur. For example, the trigger event may comprise receipt of a protocol data unit (PDU) comprising a sequence number that is different to a sequence number associated with the missing transport block (e.g., the sequence number is different to an expected sequence number). As another example, the trigger even may comprise the expiry of a timer that was initialised when the RLC protocol layer entered the alert state.
When it is determined that at least one of the trigger events has occurred, the receiver RLC protocol layer signals the transmitter RLC protocol layer an indication that the missing transport block has not been successfully received by the receiver. The transmitter RLC protocol layer may subsequently (e.g., in response to receipt of this indication) cause the data comprised in the missing packet to be retransmitted in accordance with an RLC protocol layer retransmission procedure.
Further illustration of how this may be achieved is provided below.
In the following examples, certain aspects are explained with reference to devices that are often configured to communicate via a wireless cellular system and mobile communication systems serving such mobile communication devices. For brevity and clarity, the following describes such aspects with reference to a 5G wireless communication system. However, it is understood that such aspects are not limited to 5G wireless communication systems, and may, for example, be applied to other wireless communication systems (for example, current 6G proposals, IEEE 802.11, etc.).
Before describing in detail the examples, certain facets of a 5G wireless communication system are briefly explained with reference to
3GPP standards defined a service-based architecture in 5G, which is expected to be utilized in 6G and beyond. In a service-based architecture, a modular framework is used in which common applications can be deployed using components from different sources and/or suppliers.
The 5G RAN may comprise one or more gNodeB (gNB) distributed unit functions connected to one or more gNodeB (gNB) unit functions. The RAN may comprise one or more access nodes.
The 5GC 106 may comprise one or more Access and Mobility Management Functions (AMF) 112, one or more Session Management Functions (SMF) 114, one or more authentication server functions (AUSF) 116, one or more Unified Data Management (UDM) functions 118, one or more User Plane Functions (UPF) 120, one or more Unified Data Repository (UDR) functions 122, one or more Network Repository Functions (NRF) 128, and/or one or more Network Exposure Functions (NEF) 124. The role of an NEF is to provide secure exposure of network services (e.g. voice, data connectivity, charging, subscriber data, and so forth) towards a 3rd party. Although NRF 128 is not depicted with its interfaces, it is understood that this is for clarity reasons and that NRF 128 may have a plurality of interfaces with other network functions. Likewise, other network functions of the 5GC 106 may include one or more further interfaces with each other that are not depicted in
The 5GC 106 also comprises a network data analytics function (NWDAF) 126. The NWDAF is responsible for providing network analytics information upon request from one or more network functions or apparatus within the network. Network functions can also subscribe to the NWDAF 126 to receive information therefrom. Accordingly, the NWDAF 126 is also configured to receive and store network information from one or more network functions or apparatus within the network. The data collection by the NWDAF 126 may be performed based on at least one subscription to the events provided by the at least one network function.
The station of the access system may be categorized into two different types: distributed units (DUs), and centralized units (CUs).
An example wireless communication device will now be described in more detail with reference to
A wireless communication device may, for example, be implemented as a mobile device or a stationary device, or a combination thereof. A mobile device is a device not fixed to a particular location, whereas a stationary device may be configured to be fixed to a particular location (or removably attached thereto). The wireless device may utilize human interaction for communication, or may not utilize human interaction for communication. As described herein, the terms UE or “user” are used to refer to any type of wireless communication device.
The wireless device 300 may receive signals over an air or radio interface 307 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In
A wireless device is typically provided with at least one data processing entity 301, at least one memory 302 and other possible components 303 for use in software code and hardware aided execution of tasks it is configured to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant control apparatus can be provided on an appropriate circuit board and/or in chipsets. This feature is denoted by reference 304. The user may control the operation of the wireless device by means of a suitable user interface such as keypad 305, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 308, a speaker and a microphone can be also provided. Furthermore, a wireless communication device may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto.
The present disclosure relates to data recovery mechanisms performed between a transmitter and a receiver. It is understood that the transmitter and/or receiver mentioned herein may be located at various points of a communication network. For example, the transmitter and receiver may be comprised in respective UE (e.g., as described above in relation to
The transmitter and/or receiver may comprise a plurality of different types of data recovery loops that are used to ensure reliability of transmission of data between the transmitter and the receiver. These data recovery loops generally provide some mechanism for causing retransmission of data that has not been correctly received at the receiver. The data recovery loops are also referred to herein as retransmission mechanisms.
The data recovery loops may be deployable at respective protocol layers of the protocol stack. For example, at the PHY and/or MAC protocol layers, a Hybrid Automatic Repeat request (H-ARQ) process may be used to cause re-transmission of a missing data packet (e.g., a data packet that has not been received at all, and/or a data packet that has been incorrectly received). At the Radio Link Control (RLC) layer, an Automatic Repeat reQuest (ARQ) process may be used to cause retransmission of the missing data packet. RLC ARQ is a process that is used to recover packets that were not recovered by the lower layer HARQ procedure (e.g., due to time-outs and/or false-positive acknowledgement errors).
The MAC/PHY protocol layer may provide a first layer retransmission mechanism using some type of ARQ procedure (e.g., H-ARQ, ARQ, etc.). This may be performed at a per-transmission level of operation.
The RLC protocol layer may provide a second layer retransmission mechanism using some type of RLC Acknowledged Mode procedure. This may be performed within a predetermined window of time from the initial transmission and/or receipt of a negative acknowledgement (NACK).
The PDCP protocol layer may provide a third layer retransmission mechanism using some type of PDCP-based recovery mechanism (e.g., handover, multi-connectivity, etc.).
The TCP protocol layer may provide a fourth layer retransmission mechanism using some type of TCP-based recovery mechanism (e.g., TCP Acknowledged mode).
The RLC protocol layer is associated with a plurality of timers and state variables. The RLC protocol layer can be implemented in three modes, namely a transparent mode, an unacknowledged mode, and an acknowledged mode. The following is focused on the acknowledged mode. In general, the following techniques may be applied in respect of any RLC protocol layer retransmission mechanism in which an RLC protocol layer of a receiver causes a retransmission of a missing data packet from the transmitter to the receiver.
The RLC protocol layer can currently be implemented in three different modes, namely the transparent mode (TM), the unacknowledged mode (UM), and the acknowledged mode (AM). The following focuses on the AM.
In more detail, a transmitter RLC protocol layer receives an RLC Service Data Unit (SDU) from an upper protocol layer. It assigns the next available SN to this SDU. The transmitter RLC protocol layer sends an RLC header plus the RLC SDU to the MAC protocol layer for transmission to a receiver. This RLC header plus SDU is also referred to as a data PDU.
An AM Data PDU (e.g., from the transmitter) comprises an RLC header, which in turn contains the Sequence Number (SN) of the RLC Service Data Unit (SDU). SN and Segment Offset (SO) are header fields that help with acknowledgements and retransmissions. STATUS PDU is a type of control PDU signalled from the receiver to the transmitter.
The receiving side RLC acknowledges correctly received SDUs using an acknowledgement signal, and/or negatively acknowledges incorrectly received or lost SDUs to the transmitter RLC.
The AM mode supports at least one (and often a plurality) of mechanisms to enable retransmission of data. Some of these mechanisms are triggered at the transmitter of the data while others of these mechanisms are triggered at the receiver of the data.
Stated differently, the transmitter RLC protocol layer may retransmit SDUs that were either not received by the receiver RLC protocol layer, or which were not correctly received by the receiver RLC protocol layer. The RLC protocol layer may allow a maximum number of retransmissions to be made, after which the error is indicated to upper layer.
The retransmission may be made following the receiver RLC protocol layer providing a STATUS report to the transmitter RLC protocol layer (or any other signalling that indicates which SDUs have been incorrectly and/or correctly received by the receiver RLC protocol layer).
Transmission of the STATUS report may be performed in response to signalling from the transmitter that requests the STATUS report and/or autonomously by the receiver RLC layer (e.g., not in response to a request for the STATUS report from the transmitter).
A polling mechanism is an example of a how the transmitter may initiate transmission of the STATUS report. In this example, at the transmitter, a polling mechanism can be used to request a report from the receiver using a poll bit in a request signalled from the transmitter to the receiver. This polling method is premised on the assumption that the transmitted data is correctly decoded.
The use of configured timers is an example of how the receiver may autonomously signal a STATUS report. Two of the configured timers associated with this autonomous signalling in the AM mode are the t-Reassembly timer and the t-StatusProhibit timer (see details in 3GPP TS 38.322). The former timer (e.g., the t-Reassembly timer) defines a time window within which packets are expected to be received in-sequence, and so provides a window to detect missing packets. The latter timer (e.g., the t-StatusProhibit timer) defines a time window within which no new status report can be sent from the RLC entity at the receiving device to its peer entity at the transmitting device. A time window may be considered to be a duration of time. The time windows defined by the timers may be different durations.
The start time of these timers may be triggered in response to at least one event being detected. For example, when a missing transport block is detected (e.g., based on a missing sequence number of at least one PDU comprised in the missing transport block), the RLC entity at the receiver starts the t-Reassembly timer. In the downlink direction, the t-Reassembly timer at the UE RLC AM entity is configured via Radio Resource Control (RRC) signaling. In setting the t-Reassembly timer by means of RRC signaling, 3GPP TS 38.331 makes provision for 0-200 milliseconds (3GPP TS 38.322 specifies the behaviour when it expires, see clause 5.2).
This t-Reassembly timer is set such that it can accommodate any retransmission process happening at the lower layer (e.g., HARQ retransmissions). The t-Reassembly timer potentially does not expire before the HARQ processes are completed at the lower protocol level. This t-reassembly timer may therefore contribute to the delay attributed to the Radio Link Control Layer.
The t-Reassembly timer stops when either the RLC protocol layer determines that the missing packet has been received, or the t-Reassembly timer expires.
In its current implementation, and for downlink communications, when the UE RLC entity detects a missing packet, the UE RLC entity starts the t-Reassembly timer. As mentioned above, the RLC t-reassembly timer may be configured based on any of the values as defined in RLC config subsection of section 6.32 in the standard (TS 38.331), for terrestrial networks from 0-200 ms. This value is however, set based on a worst-case scenario dominated by the maximum HARQ retransmission time and the assumed radio frame configuration and its parameters (such as the sub-carrier spacing, TDD configuration, etc.).
In the AM, whenever a radio bearer is setup, an RLC entity is also established. This RLC entity is also referred to herein as an RLC process. The establishment of an RLC process involves creating the RLC process and then initializing all the protocol state variables for that RLC process. Once the initialization is completed, the RLC AM process moves into the ACTIVE state.
In the ACTIVE state, the RRC layer can: re-establish the RLC AM process if the session has been reinitialized due to a radio link failure; and release the RLC AM process if the radio bearer is released at the RRC level. Re-establishment and release result in the discard of all RLC service data units (SDUs), RLC SDU segments, and RLC PDUs for that RLC AM process.
The transmitting side of an RLC AM process sends data PDUs associated with that process, while the receiving side of an RLC AM process acknowledges the transmission via control PDUs.
As shown in
Stated differently, in the example of
The following aims to provide mechanisms for reducing the latency associated with the RLC layer performing its retransmission procedure in respect of at least one missing PDU.
In more detail, the following introduces an “alert” state or mode for at least one AM process in the RLC protocol layer. The RLC protocol layer may cause the at least one AM process to enter this alert state in response to a receiver determining that there has been a transport block reception failure comprising data associated with the at least one AM process. This transport block reception failure may be determined in any of a plurality of different ways. For example, the RLC protocol layer may identify that no scheduling grant has been received in respect of a failed transport block reception. As another example, the transport block failure may be identified by the RLC protocol layer being explicitly informed of the transport block failure by the MAC/PHY layer of the receiver.
After the receiver RLC protocol layer initiates the alert state for the at least one AM process, the at least one AM process monitors for a trigger event.
The trigger event may be the expiry of a new timer that was started when the transport block failure was determined by the RLC protocol layer, and/or the determination that, for an AM process, a sequence number has been received that is out of sequence to an expected sequence number for that AM process. The new timer may be AM-process specific, or may be the same for all AM processes being maintained by the RLC protocol layer.
Stated differently, during the alert state, each of the AM processes associated with the missing transport block may perform at least one of:
When a trigger event is determined to have occurred, the receiver RLC protocol layer sends an indication to the transmitter RLC protocol layer that informs the transmitter that data is missing in respect of the at least one active AM process. This indication is also referred to herein as an early status report, as it may comprise the information of the status report transmitted when the t-reassembly timer expires, but is transmitted earlier. In response to this signalling, the transmitter RLC protocol layer may cause retransmission of the missing data using an RLC protocol layer retransmission mechanism.
Once the data comprised in the missing transport block is recovered and/or the early status report has been sent, the RLC protocol layer exits the alert state, and may continue to monitor for missing data.
During 601, the transmitter (e.g., an access network node/gNB) configures the receiver RLC protocol layer to enable an AM alert state in respect of at least one AM process maintained at the receiver RLC protocol layer. An AM process may be considered to have an enabled AM alert state when, in response to the RLC protocol layer determining that data associated with that AM process has not been received at the MAC/PHY level, that AM process enters the alert state. In addition to enabling at least one AM alert state, the transmitter may configure the receiver RLC protocol layer to disable an AM alert state in respect of one other AM process maintained at the receiver RLC protocol layer.
The configuration of the receiver RLC protocol layer by the transmitter may be performed using signalling associated with a session establishment procedure and/or during a session reestablishment procedure, and/or during a session update procedure. Being able to perform the configuration at multiple times is useful as it may allow the network apparatus to respond to different network loads.
For example, where the signalling for causing the configuration relates to an already established session, this signalling may be performed in response to a dynamic determination of a current load in the network and/or current network conditions. For example, when a lot of transmissions/retransmissions are not being received by the receiver/UE and/or when the transmitter/network node is using more than a threshold amount of resources for signalling to a plurality of UEs, the network node may configure the UE with alert states in respect of only a subset (e.g., less than all) of the AM processes maintained at the RLC protocol layer. This subset may be determined in dependence on relative priority of the different AM processes, e.g., so that higher priority AM processes are more likely to be configured to use the alert state mechanism described herein than lower priority AM processes. Higher priority AM processes may comprise, for example, voice data and/or time critical data. Lower priority AM processes may comprise, for example, text data and/or non-time critical data.
The signalling for causing the configuration may be performed in dependence on a capability of the receiver/UE. Where the UE has multiple AM processes maintained at the RLC protocol layer, the configuration signalling may indicate that all or less than all of these multiple AM processes are to be enabled and/or disabled. To this effect, the configuration signalling may be able to distinguish between individual AM processes, and/or between associated groups (or sets) of more than one AM process.
The configuration may indicate at least one trigger event to be monitored for during the alert state.
As a first example, the configuration may indicate that, on an AM process entering the alert state, the AM process initiates (e.g., starts) a timer (referred to herein as an alert timer). The duration of the alert timer may be set by the configuration signalling. The duration of the alert timer may be set by some other signalling and/or preconfigured at the UE. The duration of the alert timer may be less than the duration of the t-reassembly timer. It is understood that as some AM processes maintained at the receiver RLC protocol layer may enabled for the alert state while other AM processes maintained at the receiver RLC protocol layer are not enabled for the alert state, the receiver RLC may simultaneously be configured with (and, when applicable, initialise timers corresponding to durations of) values for the alert timer and the t-reassembly timer. Further, the duration of the alert timer may be same for each AM process enabled for alert state, be the same for only a fraction (e.g., less than all) of the AM processes enabled for alert state, and/or be different for the AM processes enabled for alert state. In this first example, the trigger event comprises expiry of the alert timer without the missing data being detected by the RLC protocol layer. In this last example, the trigger event(s) to be monitored by a specific AM process may be configured independently of the trigger event(s) to be monitored by at least one other AM process.
As a second example of a trigger event, the configuration may indicate that, on an AM process entering the alert state, the RLC protocol layer should monitor for a specific sequence number for that AM process (also referred to herein as an “expected” sequence number). In this second example, the trigger event comprises receiving a sequence number for that AM process that is different to the expected sequence number.
It is understood that multiple of these trigger events may be monitored for by an AM process during the alert state.
During 602, subsequent to data transmissions being made to the UE, the UE determines that retransmission procedures in respect of data comprised in a missing transport block have been completed at the PHY/MAC protocol layer. This determination may be made in any of a plurality of different ways. For example, the RLC protocol layer may identify that no scheduling grant has been received in respect of a failed transport block reception. As another example, the transport block failure may be identified by the RLC protocol layer being explicitly informed of the transport block failure by the MAC/PHY layer of the receiver. This latter option is illustrated in below in relation to
During 603, the UE MAC protocol layer indicates to the RLC protocol layer that a transport block has not been successfully received at the PHY/MAC. Stated differently, the UE MAC protocol layer indicates to the RLC protocol layer that there is missing data associated with a transport block. The RLC protocol layer determines which AM processes are affected by this missing data (e.g., which AM processes maintained by the RLC protocol layer were expecting data to be received in a transport block that was not successfully received. Of those affected AM processes, the RLC protocol layer further identify which of those AM processes are configured to enter the alert state, and to cause those identified AM processes to enter the alert state. The remaining AM processes that were affected but which are not configured to enter the alert state are treated as described above in relation to
During 604, each AM process in an alert state monitors for at least one trigger event.
As mentioned above, as a first example, the trigger event may comprise expiry of the alert timer without the missing data being detected by the RLC protocol layer. As a second example of a trigger event, the trigger event may comprise receiving a sequence number for that AM process that is different to the sequence number expected to be next received for that AM process. It is understood that one, or multiple of these trigger events may be monitored for by an AM process during the alert state, depending on how that AM process is configured for its alert state.
With respect to the first example, if the expected RLC SDU sequence number arrives, within the alert timer running time, the AM process exits the alert state to 601 and/or 602.
During 605, when at least one monitored trigger event is detected, the AM process causes an indication to be sent to the RLC protocol layer at the transmitter. This indication informs the transmitter RLC protocol layer that the missing data has not been received. This indication may inform the transmitter RLC in respect of only the missing data at the triggered AM process, or in respect of all of the AM processes for which data is missing. Subsequent to this indication being signalled, the triggered AM process exits the alert state to 601 or 602. The indication may comprise the information currently signalled during STATUS signalling at expiry of the t-reassembly timer. However, this indication may be signalled much sooner than the STATUS signalling. Further, transmission of the indication may cause any currently running t-reassembly timer to be reset when information relating to those AM processes is signalled with the indication.
It is understood that when a StatusProhibit timer is running in any of the RLC processes, the UE can have two different behaviors whenever the method described above triggers a status report for transmission. The StatusProhibit timer is a timer that, while running, causes the transmission of STATUS reports to be delayed until expiry of the StatusProhibit timer.
In a first behaviour, the UE will wait until the expiry of the StatusProhibit timer before sending the generated status report (if still valid). This first behaviour is consistent with current operations of the StatusProhibit timer.
In a second behaviour, the UE overrides any running StatusProhibit timer and sends the status report without waiting for expiry of the StatusProhibit timer. This behavior may be configured via the access network node (e.g., when configuring the AM alert state via an RRC message).
As mentioned above, a receiver may be configured to determine when transmission attempts have been exhausted on a given retransmission process (e.g., a H-ARQ process) using information provided to the receiver (e.g., a UE, and/or an access network node) in explicit signaling from the transmitter (e.g., an access network node, such as a gNB, and/or a UE).
To enable this, a PHY and/or MAC protocol layer of the receiver may be configured to communicate expiry information to the receiver's RLC protocol layer for indicating that a retransmission mechanism deployed for a data packet at the PHY and/or MAC protocol layer has been completed. In response to this expiry information, the RLC protocol layer of the receiver may be configured to signal the RLC protocol layer of the transmitter to request retransmission at the RLC protocol layer. The receiver RLC protocol layer may further terminate any running RLC t-reassembly timer before the RLC t-Reassembly timer is scheduled to expire.
To illustrate how this may be achieved,
In the semi-static case, the transmitter PHY/MAC protocol layer informs the receiver PHY/MAC protocol layer in advance of how many times the transmitter PHY/MAC protocol layer will transmit a missing packet (e.g., a packet that has not been received correctly at the receiver PHY/MAC protocol layer). The receiver PHY/MAC protocol layer subsequently counts a number of transmissions of the missing packet and informs the receiver RLC protocol layer when the number of transmissions of the missing packet equals the number of times the transmitter PHY/MAC protocol layer will transmit the missing packet.
In contrast, the dynamic case relates to the transmitter PHY/MAC protocol layer explicitly signaling the receiver PHY-MAC protocol layer when a retransmission of a missing packet is the last retransmission of that missing packet. When the receiver PHY/MAC protocol layer receives this “last” transmission and it is determined that the data comprised therein cannot be recovered based on all transmissions of this missing packet, the receiver PHY/MAC may identify that no more retransmissions of the missing packet will be performed by the PHY/MAC protocol layer and inform the receiver RLC protocol layer accordingly.
In both cases, following the receiver RLC protocol layer being informed that no further PHY/MAC protocol layer retransmissions will be performed in respect of the missing packet, the receiver RLC protocol layer may cause the transmitter RLC protocol layer to cause retransmission of the missing packet in accordance with RLC-layer data recovery mechanism. This may be effected, for example, by the receiver RLC protocol layer causing a STATUS PDU message to be transmitted to the transmitter RLC protocol layer.
The UE may initialize a respective retransmission counter (C1k) in its MAC protocol layer when the UE generates the first NACK feedback for any of said HARQ processes. C1k may be a vector with size equal to the number of HARQ processes. Stated differently, the receiver may comprise a respective counter for each HARQ process. Each of the elements of C1k may comprise an updated number of retransmissions that the UE counts per HARQ process.
When an initialized retransmission counter equals the stored maximum number of retransmissions, the UE MAC protocol layer may inform the UE's RLC protocol layer through an internal message (UE implementation) to terminate the RLC acknowledged mode t-Reassembly timer and generate a STATUS PDU.
How the UE messages its RLC protocol layer may be implementation specific. For example, when the RLC protocol layer labels packet data units (PDUs) and/or service data units (SDUs) using explicit sequence numbering, the RLC protocol layer may determine when to start t-Reassembly timer for generating a STATUS PDU for a specific PDU/SDU by identifying that non-consecutive sequence numbers have been received in consecutive PDUs and/or SDUs received at the RLC protocol layer. The t-Reassembly timer may be initialized in response to this identification, and may be considered as being tightly coupled to specific missing PDUs.
During 7001, the transmitter RRC 701 signals the receiver RRC 706. This signaling may comprise an indication of a maximum number of HARQ retransmissions that are to be performed at the MAC level. This indication may be labelled as “MaxrofHARQReTxPerHARQ-PRocessforPDSCH”. This indication may comprise a value C0 that indicates the maximum number of HARQ retransmissions per HARQ process. This indication may be comprised in an RRC radio link control establishment setup signaling operation.
During 7002, the receiver MAC 704 stores the value C0. The receiver MAC 704 may store the value C0 after being configured to store this value by the receiver radio resource control layer.
During 7003, the transmitter MAC 703 signals the receiver MAC 704. This signaling may comprise downlink control information (DCI). This signaling may indicate a modulation and coding scheme (MCS) for signaling data between the transmitter and the receiver. This signaling may comprise an indication that there is no new data being transmitted (e.g., the new data indicator (NDI) may equal zero).
During 7004, the transmitter RLC 702 signals the transmitter MAC 703. This signaling may comprise sequence numbering that labels protocol data units (PDUs) to be transmitted by the transmitter MAC 703 to the receiver MAC 704.
During 7005, the transmitter MAC 703 signals the receiver MAC 704. This signaling may comprise data in the form of PDUs. This signaling may be transmitted using a physical downlink shared channel. This signaling may label, at an RRC-level, the transmitted data using the sequence numbers indicated during 7004. This sequence numbering may be transparent at the MAC level. Stated differently, the receiver MAC 704 may not see the sequence numbers.
During 7006, the receiver MAC 704 determines (e.g., using cyclic redundancy check mechanisms) that at least one PDU has not been received correctly. For example, the receiver MAC 704 may determine that at least one received signalling has not been decoded correctly at the MAC/PHY level. Stated differently, the receiver MAC 704 determines to signal a NACK to the transmitter in respect of at the least one PDU. During this time, a counter C1 is started, which tracks a number of retransmissions made of the at least one PDU.
From 7006, the transmitter MAC may continue to retransmit the at least one PDU until the number of retransmissions made reaches the maximum value stored during 7002. At this point, the at least one PDU may be considered as being missing (e.g., not successfully received), and the apparatus proceeds to 7007.
During 7007, the receiver MAC 704 signals the receiver RLC 705. This signaling may comprise MAC PDUs received at the receiver MAC 704 from the transmitter MAC 703, and may comprise an indication that the at least one PDU has not been successfully received.
During 7008, the receiver RLC 705 begins processing the received MAC PDUs. The receiver RLC 705 may start a timer (e.g., the t-Reassembly timer mentioned above) in respect of any AM processes that are affected by the missing at least one PDU that are not enabled for alert state. The receiver RLC 705 may cause AM processes that are affected by the at least one PDU and that are enabled for alert state to enter alert state and to monitor for at least one trigger event. The at least one trigger event may be as described above.
During 7009, the receiver RLC 705 detects that at least one trigger event has occurred for an AM process (e.g., an alert timer has expired and/or an out-of-sequence sequence number has been received), and causes a STATUS PDU to be generated early.
During 7010, the receiver RLC 705 signals the transmitter RLC 702. This signaling may comprise the early STATUS PDU generated during 7009. This signaling may be transmitted over the physical uplink shared channel (PUSCH) and/or physical uplink control channel (PUCCH).
During 7011, the transmitter RLC 702 signals the transmitter MAC 703. This signaling may comprise an instruction to retransmit the PDU received incorrectly.
During 7012, the transmitter MAC 703 signals the receiver MAC 704. This signaling may comprise downlink control information. The downlink control information may comprise an indication of a modulation and coding scheme. The signaling may comprise an indication that NDI=1.
During 7013, the transmitter MAC 703 signals the receiver MAC 704. This signaling may comprise an indication that TB N+1. Stated differently, the TB index used to label the PDU to be retransmitted is updated relative to previous transmissions. A different TB index may be used to indicate different transmission characteristics for transmission and/or reception of a transmission block (e.g., different MCS). This signaling may be transmitted on the physical downlink shared channel.
The transmitter/network node of
The signaling between the network node and UE to configure the maximum number of retransmissions at the UE MAC protocol layer may be performed using RRC signaling. The new configuration may be fully controlled by the network. The new configuration may allow the UE to monitor the H-ARQ status and terminate the RLC timer early. When not configured, the UE can follow the legacy RLC configuration method (e.g., no early termination of the RLC-layer retransmission timer).
The UE may cause the UE RLC protocol layer to be informed about expiry events (e.g., about when a HARQ process has been terminated in respect of a specific PDU and/or SDU).
During 8001, the transmitter RRC 801 signals the receiver RRC 806. This signaling may be comprised in an RRC radio link control establishment setup signaling operation.
During 8002, the transmitter MAC 803 signals the receiver MAC 804. This signaling may comprise an indication of a last data indicator (LDI). In the present example, LDI equals 0. This signaling may comprise downlink control information (DCI). This signaling may indicate a modulation and coding scheme for signaling data between the transmitter and the receiver. This signaling may comprise an indication that NDI=0.
During 8003, the transmitter RLC 802 signals the transmitter MAC 803. This signaling may comprise an indication of sequence numbers to be applied to protocol data units (PDUs) to be transmitted by the transmitter MAC 803 to the receiver MAC 804.
During 8004, the transmitter MAC 803 signals the receiver MAC 804. This signaling may comprise data in the form of PDUs. This signaling may be transmitted using a physical downlink shared channel. This signaling may label the transmitted data using the sequence numbers indicated during 8003.
During 8005, the receiver MAC 804 determines (e.g., using the sequence number labelling and/or cyclic redundancy checking) that at least one PDU has not been received correctly. Stated differently, the receiver MAC 804 determines to signal a NACK to the transmitter in respect of at least one PDU.
From 8005, the transmitter MAC 803 may continue to retransmit the at least one PDU that has been NACKed by the receiver MAC 803 until a maximum number of transmission attempts have been made and/or until a timeout event occurs on expiry of a timer. At least one of these events may indicate that the retransmission attempts at the MAC layer have been completed in respect of the at least one PDU. In this example, the transmitter MAC 803 makes the determination of when this has been completed, and provides an indication of that completed retransmission process in signaling to the receiver MAC 804. When the receiver MAC 804 receives that indication that the at least one PDU will not be retransmitted at the MAC protocol layer, the receiver MAC 804 proceeds to 8006.
During 8006, the receiver MAC 804 signals the receiver RLC 805. This signaling may comprise MAC PDUs received at the receiver MAC 804 from the transmitter MAC 803. This signalling may comprise an indication that at least one transport block comprising the at least one PDU has not been received successfully.
During 8007, the receiver RLC 805 begins processing the received MAC PDUs. The receiver RLC 805 may start a timer (e.g., the t-Reassembly timer mentioned above) in respect of any AM processes that are affected that are not enabled for alert state. The receiver RLC 805 may cause AM processes that are affected and that are enabled for alert state to enter alert state and to monitor for at least one trigger event. The at least one trigger event may be as described above.
During 8008, the receiver RLC 805 detects that at least one trigger event has occurred for an AM process (e.g., an alert timer has expired and/or an out-of-sequence sequence number has been received), and causes a STATUS PDU to be generated early.
During 8009, the receiver RLC 805 signals the transmitter RLC 802. This signaling may comprise the STATUS PDU generated during 8008. This signaling may be transmitted over the physical uplink shared channel and/or physical uplink control channel.
During 8010, the transmitter RLC 802 signals the transmitter MAC 803. This signaling may comprise an instruction to retransmit the PDU received incorrectly.
During 8011, the transmitter MAC 803 signals the receiver MAC 804. This signaling may comprise downlink control information. The downlink control information may comprise an indication of a modulation and coding scheme. The signaling may comprise an indication that NDI=1.
During 8012, the transmitter MAC 803 signals the receiver MAC 804. This signaling may comprise an indication that TB N+1. This signaling may be transmitted on the physical downlink shared channel.
As per the signaling method of
One way of signaling this information is by means of physical downlink control channel (PDCCH) control signaling. For example, similar to a “NEW DATA” indicator field that is currently used, a new indicator field for “LAST DATA” or “LAST Tx ATTEMPT” can be added as part of resource allocation signaling. Activation of the signaling mode to cause the UE to monitor for signals related to dynamic signaling of a last transmission indicator may also be toggled on and/or off by means of explicit RLC signaling if it is desired to save DCI bits.
As mentioned above, the presently disclosed last data indicator may be similar to the new data indicator (NDI) field in the DCI (see, for example, 3GPP TS 38.214). The last data indicator may comprise a single bit field. When the UE MAC's attempt at decoding this last retransmission fails, the UE MAC informs the UE's RLC entity to terminate the t-Reassembly timer and send a STATUS PDU.
In one example, the LDI field can be combined with the NDI field to give a single two bit field with combinations such as:
In another example, the LDI may be maintained as a separate single bit field from the NDI with values:
Like in the semi static case, the LDI indicator may be HARQ process specific, such that a received LDI indicator relates to a specific HARQ process (e.g., less than all HARQ processes currently deployed between the transmitter and the receiver).
The UE MAC may use internal messaging to inform the RLC protocol layer to terminate the t-Reassembly timer.
Which of the semi-static and dynamic cases is more useful in a specific case may vary with the specifics of that case.
For example, the semi-static option offers a signaling efficient approach by limiting a transmitter to work with dynamic number of maximum retransmissions based on, for example, any of a plurality of different factors, including current load considerations, hardware limitations (e.g., memory, processor limitations), energy consumption limitations, etc. However, this semi-static option may use more monitoring and thus increased complexity to estimate the early timer event at the receiver.
In contrast, the dynamic option uses more signaling between the transmitter and the receiver than the semi-static option, but offers more flexibility in terms of scheduler and link adaptation at the transmitter and requires less monitoring of the H-ARQ processes at the receiver than the semi-static option.
Although the presently described mechanisms are especially useful for cases when a receiver is configured with only a single RLC acknowledged mode entity (e.g., so that there is no ambiguity between what was sent on the physical layer and how it maps to the logical channels the RLC protocol layer controls), the mechanisms may be applied to other scenarios.
For example, the present mechanisms may be applied when the missing packet on the air interface applies to a signaling radio bearer (e.g., RRC message or otherwise) that is not part of the RLC acknowledged mode entity.
In this example, the RLC acknowledged mode may react to any expired transmission and it is expected that signaling radio bearer will not be expired. In the dynamic method, that is covered directly as the transmitter decides which transmissions it communicates expiration notice for. In the semi-static method, signaling radio bearers (SRBs) may be sent only on certain H-ARQ stop-and-wait (SAW) processes, or it may be assumed that there is no maximum number of transmission attempts.
Therefore, the presently described techniques are not limited to RLC acknowledged mode.
As another example, the present mechanisms may be applied when a receiver has parallel RLC acknowledged mode entities configured for the radio bearers in the interface between the receiver and the transmitter (e.g., the Uu interface when the transmitter-receiver pair is an access network node-UE pair).
In this example, the RLC acknowledged mode may only react to missing PDUs when there is a low probability of packets being missing across all current H-ARQ communications. The RLC protocol layer in the receiver handling the parallel RLC acknowledged mode entities may optimize which entity the retransmission should be done for based on parallel monitoring of all the flows. The receiver may comprise an internal expiry time that allows for pending service data units (SDUs) to reach the receiver before a decision for retransmission is made at the RLC protocol layer. Alternatively, the transmitter MAC protocol layer could explicitly indicate to the receiver which RLC acknowledged mode entity a certain expiration applies for.
Features of the above examples are illustrated below with reference to
During 901, the apparatus maintains, at a radio link control, RLC, protocol layer of the apparatus, at least a first RLC entity and a second RLC entity, each of the first and second RLC entities being associated with a respective set of service data units to be acknowledged. For example, the first RLC entity may be associated with a first order of sequence numbers of service data units to be acknowledged, while the second RLC entity may be associated with a second order of sequence numbers of service data units to be acknowledged. The sequence numbers in each of the first and second orders may be different during at least a first time period. An RLC entity may correspond to an RLC process.
During 902, the apparatus determines, by the RLC protocol layer from an indication received from a medium access control, MAC, and/or physical, PHY, protocol layer of the apparatus, that a retransmission procedure of a data packet comprising at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received. The set of service data units may correspond to the set of service data units associated with the first RLC entity and/or the set of service data units associated with the second RLC entity. The data packet may comprise a transport block. The transport block may comprise service data units associated with the first RLC entity and/or the second RLC entity.
During 903, the apparatus causes at least one of the first RLC entity or the second RLC entity to determine whether at least one trigger event occurs based on the determining.
For example, when it is determined during 902 that a service data unit associated with the first RLC entity has not been successfully received, the apparatus may cause the first RLC entity to determine whether the at least one trigger event occurs. Similarly, when it is determined during 902 that a service data unit associated with the second RLC entity has not been successfully received, the apparatus may cause the second RLC entity to determine whether the at least one trigger event occurs. When it is determined during 902 that service data units associated with both the first and second RLC entities have not been received successfully, the first and second RLC entities may both be caused to determine whether the at least one trigger event occurs. In this latter case, the trigger event may be the same for both of the first and second entities, and/or different for the first and second entities (e.g., both initialise a timer for the same duration and/or each initialises a timer for respective, different durations).
The first and/or second RLC entity may be caused to determine whether the at least one trigger event occurs. The at least one trigger event may comprise, for example, a determination that a service data unit of one of said sets of service data units has been received that comprises a sequence number that is out of sequence relative to a sequence number expected to be received for that set of service data units. Alternately or additionally, the at least one trigger event may comprise a determination that a timer that was started in response to the receipt of the indication from the MAC and/or PHY protocol layer has expired.
During 904, when the first RLC entity and/or the second RLC entity determines that the at least one trigger event has occurred, the apparatus signals, to a transmitter of the data packet, an indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The determining that a retransmission procedure of a data packet comprising the at least one service data unit of the set of service data units has been completed without the at least one service data unit being successfully received may comprise receiving an indication from the MAC and/or PHY protocol level that indicates that a maximum number of retransmissions of the data packet has been made at the MAC and/or PHY level, and/or receiving a scheduling indication that indicates that no resources have been allocated for retransmission of the data packet.
For each of said respective sets, the service data units comprised within that respective set may be associated with a reception sequence order that indicates an order in which said service data units are expected to be received within their respective set. In such a case, the causing at least one of the first RLC entity or the second RLC entity to determine whether the at least one trigger event occurs may be performed before the RLC protocol layer receives a service data unit out of sequence to service data units already received by the RLC protocol layer.
Stated differently, the causing at least one of the first RLC entity or the second RLC entity to determine whether the at least one trigger event occurs may be performed before a t-reassembly timer would have been started (e.g., before the RLC protocol layer receives a service data unit comprising a sequence number that is out of sequence to a sequence number expected to be received by the RLC protocol layer).
The apparatus may determine whether a timer is running at the apparatus that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer (e.g., a t-prohibit timer is running). When such a timer is running, the apparatus may delay transmission of said signalling to the transmitter until expiry of said timer.
The apparatus may signal said indication that the at least one service data unit has not been successfully received by the RLC protocol layer regardless of whether a timer is running at the apparatus that prohibits transmission of the signalling to the transmitter the indication that the at least one service data unit has not been successfully received by the RLC protocol layer.
The apparatus may receive, from a transmitter of the data packet, a configuration for causing the at least one first and/or second RLC entity to determine whether the at least one trigger event occurs, and apply the received configuration.
The configuration may comprise an indication to initiate a timer and/or an indication that a sequence number order is to be monitored for detecting whether a service data unit is received out of order.
The configuration may comprise a different configuration for each of the first and/or second RLC entity for determining whether the at least one trigger event occurs. For example, the configuration may comprise at least one different parameter to be monitored (e.g., different timer values for the first and second RLC entities respectively, different types of events to be monitored, such as timer and/or an out of sequence number).
The configuration may comprise a same configuration for the first and second RLC entity for determining whether the at least one trigger event occurs.
During 1001, the apparatus determines, for at least one of a first and second radio link control, RLC, entity maintained by an RLC protocol layer of the apparatus, a configuration for corresponding first and second radio RLC entities maintained by an RLC protocol layer of a receiver. The receiver may correspond to the receiver of
During 1002, the apparatus provides the configuration to the receiver.
The configuration may comprise an indication to initiate a timer and/or an indication that a sequence number order is to be monitored for detecting whether a service data unit is received out of order.
The configuration may comprise a different configuration for each of the first and/or second RLC entity for determining whether the at least one trigger event occurs. For example, the configuration may comprise at least one different parameter to be monitored (e.g., different timer values for the first and second RLC entities respectively, different types of events to be monitored, such as timer and/or an out of sequence number).
The configuration may comprise a same configuration for the first and second RLC entity for determining whether the at least one trigger event occurs.
The subject disclosure has provided by way of non-limiting and illustrative examples a full and informative description of some of the various examples described herein. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the claims. However, all such and similar modifications of the teachings will still fall within the scope of the various examples of the subject disclosure.
In the above, different examples are described using, as an example of an access architecture to which the described techniques may be applied, a radio access architecture based on long term evolution advanced (LTE Advanced, LTE-A) or new radio (NR, 5G, 6G, etc.), without restricting the examples to such an architecture, however. The examples may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures where appropriate. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN), wireless local area network (WLAN or Wi-Fi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.
As provided herein, several aspects are described in the various examples of the subject disclosure as well as in the claims. In general, some examples may be implemented in hardware or special purpose circuits, software code, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software code which may be executed by a controller, microprocessor or other computing device, although examples are not limited thereto. While various examples may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting and illustrative examples, hardware, software code, firmware code, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.
The examples may be implemented by computer software code stored in a memory and executable by at least one data processor of the involved entities or by hardware, or by a combination of software code and hardware.
The memory referred to herein may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.
The (data) processors referred to herein may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting and illustrative examples.
Further in this regard it should be noted that any procedures, e.g., as in
The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), gate level circuits and processors based on multicore processor architecture, as non-limiting and illustrative examples.
Additionally or alternatively, some examples may be implemented using circuitry. The circuitry may be configured to perform one or more of the functions and/or method steps previously described. That circuitry may be provided in the network node and/or the base station and/or in the communications device and/or in a core network entity.
As used herein, the term “circuitry” or “means” may refer to one or more or all of the following examples:
This definition of circuitry applies to all uses of this term herein, including in any claims. As a further example, as used herein, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware code. The term circuitry also covers, for example, integrated device(s).
Implementations of the disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.
As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.
The term “non-transitory,” as used herein, is a limitation of the medium itself (e.g., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).
The scope of protection sought for the various examples of the subject disclosure is set out by the independent claims. The various examples and aspects/features thereof, described in this specification that do not, if any, fall under the scope of the independent claims are to be interpreted as examples useful for understanding this subject disclosure.
This subject disclosure has provided, by way of non-limiting and illustrative examples, a full and informative description of some example implementations. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the claims. However, all such and similar modifications of the teachings of this subject disclosure will still fall within the scope of this various examples described herein. Indeed, there is a further example implementation comprising a combination of one or more example implementations with any of the other example implementations described herein.
| Number | Date | Country | Kind |
|---|---|---|---|
| 23200862.3 | Sep 2023 | EP | regional |
