WO2022223103A1

WO2022223103A1 - Downlink duplication of protocol data units

Info

Publication number: WO2022223103A1
Application number: PCT/EP2021/060280
Authority: WO
Inventors: Torsten DUDDA; Ying Sun
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2021-04-20
Filing date: 2021-04-20
Publication date: 2022-10-27
Anticipated expiration: 2023-10-20

Abstract

There is provided mechanisms for performing downlink RLC PDU duplication towards a user equipment. A method is performed by a network node. The method comprises determining to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service. The method comprises performing the downlink RLC PDU duplication for the URLLC service towards the user equipment upon having entered the RLC URLLC mode.

Description

DOWNLINK DUPLICATION OF PROTOCOL DATA UNITS TECHNICAL FIELD

Embodiments presented herein relate to a method, a network node, a computer program, and a computer program product for performing downlink protocol data unit duplication towards a user equipment. Embodiments presented herein further relate to a method, a user equipment, a computer program, and a computer program product for triggering downlink protocol data unit duplication from a network node.

BACKGROUND

In communication networks, there may be a challenge to obtain good performance and capacity for a given communications protocol, its parameters and the physical environment in which the communication network is deployed. For example, two parameters in providing good performance and capacity for a given communications protocol in a communication network are reliability and low latency.

In this respect, ultra-reliable and low latency communication (URLLC) requirements specified for the New Radio (NR) air interface by the third generation partnership project (3GPP) are intended to handle a variety of scenarios in which high reliability and low latency are required. Examples of such scenarios appear in the automotive safety field, in factory automation, as well as in applications of augmented and virtual reality functionality with tactile feedback. The performance requirements are then enhanced, from capacity/spectral efficiency requirements related to wireless mobile broadband services, to include also stringent requirements on round trip latency and reliability. Typically, the latency requirements could reach sub-millisecond figures and the reliability requirements could reach packet loss probabilities as low as io ⁶to 10-4. With regards to reliability, it is noted that current wireless mobile broadband transmission systems are optimized for operation at a block-error rate of 1-10%, meaning that error rates of about to^-2 are achievable without re-transmissions.

With regards to reliability, there is not any existing retransmission scheme with the purpose to optimize both spectrum efficiency and latency at higher protocol layers. To meet application layer reliability requirements, there are many existing tools at different protocol layers. One of the most commonly used tools is retransmission schemes, as for example used on the Transmission Control Protocol (TCP), Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), and Medium Access Control (MAC) protocol layers. These retransmission schemes are used when transmission feedback indicates that transmission, for example of a Protocol Data Unit (PDU), has failed. For example, a MAC protocol layer failure resulting from failed hybrid automatic repeat request (hybrid ARQ or HARQ) (re-)transmissions on the MAC protocol layer will trigger a retransmission of an RLC packet; multiple RLC retransmission failures will result in a failed transmission of the payload data, e.g. TCP packets. At the TCP layer, if a TCP acknowledge is not received, a retransmission of the TCP packet will be triggered.

These retransmission schemes are thus used on demand and based on transmission feedback and optimized for resource utilization efficiency. For example, if a transmission fails, a retransmission is triggered, and extra resources are consumed only if a retransmission occurs. However, since any retransmission loop will require at least a round trip time delay to receive the feedback information, these retransmission schemes are not optimized to minimize latency and transmission delay. As an example, in Table 5.7.4-1 in section 5.7 of 3GPP TS 23.501 V16.3.0, for a service, such as an electricity distribution high voltage service, with a guaranteed delay critical Guaranteed Bit Rate (GBR) with Quality of Service Class Identifier CQI (also denoted 5QI, which is short for 5G QoS Identifier ) value 85 (i.e., CQI = 85 or 5QI = 85), and with required packet error rate loss of lo s and a packet delay budget (PDB) of 5 ms. A static value for the core network (CN) PDB of 2 ms for the delay between a user plane function (UPF) terminating interface N6 and a 5G-AN (where AN is short for access network) should be subtracted from a given PDB to derive the packet delay budget that applies to the air interface. This is the most challenging QoS requirement in the current specifications, which requires both very low latency and low error rate. In order to fulfill the overall package delay budget of 5 ms, a delay budget of 3 ms is needed at the air interface. Retransmissions that potentially are required for reliability purposes on different protocol layers are not affordable due to the latency constraint. When PDCP duplication (such as PDCP duplication of PDUs) is applied, the PDCP packets are duplicated on different carriers or in different frequency bands based on dual connectivity schemes and carrier aggregation schemes. Currently, a maximum of four copies of the same PDCP packet are supported. The number of copies is configured at Radio Resource Control (RRC) level and can be activated through the use of a MAC control element (CE) or RRC configuration.

However, there is currently no RLC mode ideal for PDUs of URLLC services. In this respect, RLC unacknowledged mode does not satisfy the necessary reliability requirements, and RLC acknowledged mode does not satisfy the necessary latency requirements. PDCP duplications of the radio bearer to which RLC belong are possible, making use of multiple RLC entities, but transmissions among those RLC entities may not always be time-aligned. Reliability tools such as repetitions and HARQ are provided at the MAC layer but these tools are service agnostic, implying that if repetitions for reliability would be configured, those would be applied to all services, independent of their reliability requirements, thus causing many unnecessary retransmissions to be performed.

When there is an on-going HARQ retransmission/repetition, the same coded layer 1 transport block (TB) is retransmitted/repeated with the same or different redundancy version (RV). At the receiver side, the repeated/retransmitted TB will be combined with the TB of previous transmission stored in soft buffer to obtain soft combining gain. Hopefully, with the extra combining gain, even fast channel variations can be combated, and the TB can be correctly decoded. However, in some scenarios, when radio conditions are very poor, multiple HARQ retransmissions might still fail, resulting in HARQ failure and therefore introducing much longer delay than tolerated. This can occur for example when the network strives for more spectrum efficiency and schedules larger TB size to transmit data of not only time critical services but also of non-time critical services. In the downlink, channel estimation is less accurate and sometimes cannot follow fast channel variations because channel quality estimation is based on channel state information (CSI) reports which have quantization errors and reporting delays. Hence, there is still a need for transmission techniques for PDUs belonging to URLLC services that enable both reliability requirements and latency requirements to be satisfied.

SUMMARY An object of embodiments herein is to address the above issues by providing transmission techniques that enable both reliability requirements and latency requirements to be satisfied for PDUs belonging to URLLC services.

According to the herein disclosed embodiments, the object is achieved by the use of an RLC URLLC mode that the network node is configured with. According to a first aspect there is presented a method for performing downlink RLC PDU duplication towards a user equipment. The method is performed by a network node. The method comprises determining to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service. The method comprises performing the downlink RLC PDU duplication for the URLLC service towards the user equipment upon having entered the RLC URLLC mode.

According to a second aspect there is presented a network node for performing downlink RLC PDU duplication towards a user equipment. The network node comprises processing circuitry. The processing circuitry is configured to cause the network node to determine to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service. The processing circuitry is configured to cause the network node to perform the downlink RLC PDU duplication for the URLLC service towards the user equipment upon having entered the RLC URLLC mode.

According to a third aspect there is presented a network node for performing downlink RLC PDU duplication towards a user equipment. The network node comprises a determine module configured to determine to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service. The network node comprises a transmit module configured to perform the downlink RLC PDU duplication for the URLLC service towards the user equipment upon having entered the RLC URLLC mode.

According to a fourth aspect there is presented a computer program for performing downlink RLC PDU duplication towards a user equipment. The computer program comprises computer program code which, when run on processing circuitry of a network node, causes the network node to perform a method according to the first aspect.

According to a fifth aspect there is presented a method for triggering downlink RLC PDU duplication from a network node. The method is performed by a user equipment. The method comprises providing a trigger to the network node to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC

URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment.

According to a sixth aspect there is presented a user equipment for triggering downlink RLC PDU duplication from a network node. The user equipment comprises processing circuitry. The processing circuitry is configured to cause the user equipment to provide a trigger to the network node to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment.

According to a seventh aspect there is presented a user equipment for triggering downlink RLC PDU duplication from a network node. The user equipment comprises a provide module configured to provide a trigger to the network node to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment. According to an eighth aspect there is presented a computer program for triggering downlink RLC PDU duplication from a network node. The computer program comprises computer program code which, when run on processing circuitry of a user equipment, causes the user equipment to perform a method according to the fifth aspect.

According to a ninth aspect there is presented a computer program product comprising a computer program according to at least one of the fourth aspect and the eighth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

Advantageously, the transmission of PDUs belonging to URLLC services according to these aspects satisfy both reliability requirements and latency requirements.

Advantageously, these aspects enable earlier retransmission of the PDUs than the RLC round trip time (RTT) or HARQ round trip time. Advantageously, these aspects enable RLC PDU duplication for the URLLC service right from the start, and hence enable instant retransmission of the PDUs.

Advantageously, these aspects provide efficient RLC PDU duplication for the URLLC service without relying on feedback for retransmission of the PDUs as in RLC acknowledged mode. Advantageously, these aspects provide efficient RLC PDU duplication for the URLLC service whilst providing the reliability to achieve a bounded latency, as compared to RLC unacknowledged mode.

Advantageously, these aspects, compared to HARQ retransmissions, enable duplicated PDUs to be multiplexed with other logical channels to build bigger transport blocks when radio conditions allow, or to be segmented to smaller piece when radio conditions are poor.

Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings. Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a/an/the element, apparatus, component, means, module, action, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, action, etc., unless explicitly stated otherwise. The actions of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Fig. l is a schematic diagram illustrating a communication network according to embodiments;

Figs. 2 and 3 are flowcharts of methods according to embodiments;

Fig. 4 is a signalling diagrams of RLC PDU duplication according to an embodiment; Fig. 5 is a schematic diagram showing functional units of a network node according to an embodiment;

Fig. 6 is a schematic diagram showing functional modules of a network node according to an embodiment;

Fig. 7 is a schematic diagram showing functional units of a user equipment according to an embodiment;

Fig. 8 is a schematic diagram showing functional modules of a user equipment according to an embodiment; and

Fig. 9 shows one example of a computer program product comprising computer readable means according to an embodiment. DETAILED DESCRIPTION

The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any action or feature illustrated by dashed lines should be regarded as optional.

Fig. l is a schematic diagram illustrating a communication network loo where embodiments presented herein can be applied. The communication network too could be a third generation (3G) telecommunication network, a fourth generation (4G) telecommunication network, or a fifth (5G) telecommunication network and support any 3GPP telecommunications standard.

The communication network 100 comprises a transmission and reception point 140 configured to provide network access to user equipment 300 in an (radio) access network no over a radio propagation channel 150. The access network no is operatively connected to a core network 120. The core network 120 is in turn operatively connected to a service network 130, such as the Internet, an Intranet, or a private industrial network. The connection from the core network 120 to the service network 130 maybe optional in some scenarios, e.g., when the core network 120 is providing services directly, such as in some private industrial networks. The user equipment 300 is thereby, via the transmission and reception point 140, enabled to access services of, and exchange data with, the service network 130 or core network 120. Operation of the transmission and reception point 140 is controlled by a network node 200. The network node 200 might be part of, collocated with, or integrated with the transmission and reception point 140. Examples of network nodes 200 are (radio) access network nodes, radio base stations, base transceiver stations, Node Bs (NBs), evolved Node Bs (eNBs), gNBs, access points, access nodes, and integrated access and backhaul nodes. Examples of user equipment 300 are wireless devices, mobile stations, mobile phones, handsets, wireless local loop phones, smartphones, laptop computers, tablet computers, network equipped sensors, network equipped vehicles, so-called Internet of Things devices, Virtual reality (VR) devices, Augmented reality (AR) devices, Extended reality (XR) devices, and network equipped gaming controllers. As noted above, there is still a need for transmission techniques for PDUs belonging to URLLC services that enable both reliability requirements and latency requirements to be satisfied.

The embodiments disclosed herein therefore relate to mechanisms for performing downlink RLC PDU duplication towards a user equipment 300 and triggering downlink RLC PDU duplication from a network node 200. In order to obtain such mechanisms there is provided a network node 200, a method performed by the network node 200, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the network node 200, causes the network node 200 to perform the method. In order to obtain such mechanisms there is further provided a user equipment 300, a method performed by the user equipment 300, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the user equipment 300, causes the user equipment 300 to perform the method.

Reference is now made to Fig. 2 illustrating a method for performing downlink RLC PDU duplication towards a user equipment 300 as performed by the network node 200 according to an embodiment.

S102: The network node 200 determines to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node 200 is to perform downlink RLC PDU duplication for the URLLC service.

S106: The network node 200 performs the downlink RLC PDU duplication for the URLLC service towards the user equipment 300 upon having entered the RLC URLLC mode.

Embodiments relating to further details of performing downlink RLC PDU duplication towards a user equipment 300 as performed by the network node 200 will now be disclosed.

Aspects of the URLLC service will now be disclosed. There could be different types of URLLC services. In some non-limiting examples, the URLLC service corresponds to a quality-of-service (QoS) and/or a latency requirement. In some non-limiting examples, the QoS requirement is defined by QoS identifier 5QI. In some non limiting examples, 5QI e {4, 5, 6, 8, 9, 69, 70, 80, 84, 85}.

There could be different factors based on which the network node 200 determines to enter the RLC URLLC mode as in action S102. In some aspects, the RLC URLLC mode is entered when the network node 200 obtains an indication to do so. Particularly, in some embodiments, the RLC URLLC mode is entered upon the network node 200 having obtained an indication that the latency bound and reliability requirement of the URLLC service cannot be met using the currently used RLC mode. There could be different such indications that could be obtained by the network node 200. According to some non-limiting examples, the indication is represented by any of: number of received NACKs for HARQ transmission of the RLC PDUs for the URLLC service exceeds a threshold value, a portion of a packet delay budget of the RLC PDUs for the URLLC service is reached, time for arrival of RLC status report with ACK for HARQ transmission of the RLC PDUs for the URLLC service exceeds a threshold value (i.e., not receiving the RLC status report with an ACK within a certain threshold time), a logical channel on which the RLC PDUs for the URLLC service are to be transmitted fails to support HARQ retransmissions that fulfil the latency bound and reliability requirement, and/or there is not any unoccupied logical channel on which the RLC PDUs for the URLLC service can be transmitted. Further, according to some non-limiting examples, the indication is obtained as a trigger from a MAC protocol layer at the network node 200. Further, according to some non-limiting examples, the indication is obtained as a trigger from the user equipment 300. In some aspects, the network node 200 reschedules one or more retransmissions of downlink transmission of the RLC PDUs for the URLLC service by cancelling at least one ongoing HARQ retransmission of these RLC PDUs. For example, the network node 200 might reschedule an RLC PDU retransmission, whilst cancelling an on going HARQ retransmission (on which beside the URLLC RLC PDU also MBB RLC PDUs or other type of non-URLLC PDUs are multiplexed). This could for example be in the case when the network node 200 is notified that part of downlink transmitted data (from LCH 1, e.g. MBB, where LCH is short for logical channel), which is multiplexed in previous transport block transmission has been already successfully received but other part of downlink transmitted data (from LCH 2 e.g. URLLC) has not been successfully received, and potential soft combining gain does not help if another complete HARQ retransmission is performed. The network node 200 might then decide to reschedule an RLC PDU retransmission for the other data (LCH 2, e.g. URLLC), which was not correctly received yet. Particularly, in some embodiments, the network node 200 is configured to perform (optional) action S104:

S104: The network node 200 cancels an ongoing HARQ retransmission of the RLC PDUs for the URLLC service.

The ongoing HARQ retransmission might pertain to only retransmission of RLC PDUs for URLLC service or to retransmission of RLC PDUs for URLLC service multiplexed other RLC PDUs for a non-URLLC service. Hence, in some embodiments, in the HARQ retransmission, the RLC PDUs for the URLLC service are multiplexed with other RLC PDUs for a non-URLLC service, or wherein in the HARQ retransmission, there are only RLC PDUs for the URLLC service. This could for example be the case when the RLC PDUs for the non-URLLC service have been already successfully received at the user equipment 300 but the RLC PDUs for the URLLC service have not been successfully received, and that potential soft combining gain will not be successful even if another complete HARQ retransmission is performed. The network node 200 might then decide to reschedule the retransmission of the RLC PDUs for the URLLC service not yet correctly received, as in action S104. Hence, the network node 200 may reschedule the retransmission of the RLC PDUs for the URLLC services with optimized parameters and/or resources to ensure the success of the retransmissions, considering e.g., the channel conditions and/or resource availabilities. Discarding in the receiver at the user equipment 300 of duplicated RLC PDUs which have already been successfully received can be made either on RLC level when RLC sequence numbers are employed or on PDCP level, which supports duplicate discarding based on PDCP sequence numbers. It is noted that duplicate discarding in the receiver at the user equipment 300 can be either on RLC level when RLC sequence numbers are employed but can in all cases be done on PDCP level, which supports duplicate discarding based on PDCP sequence numbers.

Aspects of how the downlink RLC PDU duplication can be performed will now be disclosed. In some aspects, when in the RLC URLLC mode the operation n of the network node 200 might be described as providing, upon request for either initial transmission or retransmission, duplicated RLC PDUs. That is, the original RLC PDUs and at least one duplicate of this original RLC PDU are, possibly at the same time, provided to lower layers for transmission. The lower layers, as represented by the MAC layer, utilize mechanisms to convey both RLC PDUs (possibly at the same time), e.g. via different carriers, or via different multiple-input multiple-output (MIMO) layers or transmission and reception points (TRPs). That is, in some embodiments, the downlink RLC PDU duplication is performed by any of parallel transmission of the RLC PDUs for the URLLC service: in at least two different HARQ processes, on at least two different carriers, on at least two different MIMO layers, and/or from at least two different TRPs.

The RLC PDUs for the URLLC service might be provided to the lower layers either in one transmission buffer from which multiple copies of the RLC PDUs can be called (e.g., on demand based on scheduling) or in multiple transmission buffers, one RLC PDU per copy. In the latter it might be assumed that the copies of all transmission buffers are always used since otherwise the transmission buffers would go out of synchronization. Particularly, in some embodiments, the network node 200 is configured to perform (optional) action Sio6a as part of action S106:

Sio6a: The network node 200 provides, as part of performing the downlink RLC PDU duplication of the RLC PDUs for the URLLC service, the RLC PDUs for the URLLC service to a lower layer entity in the network node 200 either in a single buffer from which all downlink RLC PDU duplications are to be made, or in as many buffers as there are downlink RLC PDU duplications to be made.

Compared to ordinary HARQ retransmissions, the herein disclosed downlink RLC PDU duplication for the URLLC service can be multiplexed with other logical channels to build bigger transport blocks when radio conditions allow, or be segmented to smaller piece when radio conditions are poor. Particularly, in some embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be multiplexed with other RLC PDUs for a non-URLLC service, and in other embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be segmented into RLC PDU segments. In some aspects, an RLC PDU is, upon transmission (i.e., initial transmission), immediately considered negatively acknowledged, and thus selected for retransmission. Then, the retransmission (i.e. the duplicate RLC PDU) is provided to lower layers as well, or provided upon request from lower layers. In this way, in case the transport block size of initial transmission and retransmission is different, segmentation of the retransmission (i.e., the for duplicated RLC PDUs) can be applied as well to fit the transport block size for the retransmission. Particularly, in some embodiments, according to the RLC URLLC mode, the RLC PDUs for the URLLC service are, upon transmission, immediately considered to be negatively acknowledged regardless of whether positive or negative acknowledgement of the

RLC PDUs is received from the user equipment 300. Upon determining the negative acknowledgment, retransmission, might be immediately performed or performed at a predetermined delay according some configurations, either given in the RCL URLLC mode configuration, a DCI, a MAC CE, or based on a tigger. There could be different factors based on which the network node 200 determines to exit the RLC URLLC mode. In some aspects, the RLC URLLC mode is entered when the network node 200 obtains an indication to do so. Particularly, in some embodiments, the network node 200 is configured to perform (optional) action S108:

S108: The network node 200 determines to exit the RLC URLLC mode upon the network node 200 having obtained an indication that using the RLC URLLC mode is no longer needed to meet the latency bound and reliability requirement of the URLLC service. There could be different such indications that could be obtained by the network node 200. According to some non-limiting examples, the indication is represented by any of: expiration of a timer (such as after expiration of a RoomForRLCRetx delay/time value), the timer having started upon the RLC URLLC mode having been entered or upon initial transmission of the RLC PDUs for the URLLC service, number of received HARQ acknowledgements for HARQ transmissions of the RLC PDUs for the URLLC service exceeds a threshold value, reception of a status report indicating successful reception at the user equipment 300 of the RLC PDUs for the URLLC service, a maximum number of duplicates of the RLC PDUs for the URLLC service having been transmitted, and/or there is at least one unoccupied logic channel on which the RLC PDUs for the URLLC service can be transmitted. Thus, in some examples, when a status report indicates successful transmission, no further duplicates shall be transmitted, i.e. the maximum number of RLC PDU duplicates for this RLC PDU is lowered. Further, in some examples, RLC PDUs are only to be duplicated for a certain time after the original RLC PDU was transmitted, and afterwards, no further duplicated RLC PDUs shall be transmitted. I.e. there could be a maximum time the URLLC RLC mode is activated, and afterwards it is deactivated again and a default RLC mode (or any other RLC mode according to which the network node 200 was operating before entering the RLC URLLC mode).

The herein disclosed RLC URLLC mode can be provided as a stand-alone RLC mode or be provided as an extension to an existing RLC mode. Hence, the herein disclosed RLC mode of operation is also applicable to existing RLC modes. Further aspects relating thereto will now be disclosed.

In some aspects, the herein disclosed RLC URLLC mode is based on the RLC unacknowledged mode (RLC UM) according to which no sequence numbers are assigned to RLC PDUs unless segmentation is required. Particularly, in some embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed as an extension to an RLC unacknowledged mode. In some aspects, when the herein disclosed RLC URLLC mode is based on the RLC unacknowledged mode, the RLC URLLC mode is only applied for new RLC PDUs. Particularly, in some embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed only for RLC PDUs for the URLLC service which have yet not been transmitted.

In some aspects, the herein disclosed RLC URLLC mode is based on the RLC acknowledged mode (RLC AM), with the herein disclosed RLC trigger utilized to consider an RLC SDU/PDU as negatively acknowledged for retransmission. Particularly, in some embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed as an extension to an RLC acknowledged mode. In some aspects, when the herein disclosed RLC URLLC mode is based on the RLC acknowledged mode, the RLC URLLC mode is used to for retransmission of negatively acknowledged RLC PDUs. Particularly, in some embodiments, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed for at least one of: RLC PDUs for the URLLC service yet to be transmitted, transmitted RLC PDUs for the URLLC service for which a negative acknowledgement (NACK) has been received from the user equipment 300. The duplicates of the RLC PDUs for the URLLC service may be provided also upon request from lower protocol layers (i.e., the PHY layer or the MAC layer). When the RLC URLLC mode is an extension to the RLC acknowledged mode, the request from a lower protocol layer is considered as an RLC trigger for considering the previous, or a number of previous, RLC PDUs as negatively acknowledged, where retransmission is to be immediately performed.

Reference is now made to Fig. 3 illustrating a method for triggering downlink RLC PDU duplication from a network node 200 as performed by the user equipment 300 according to an embodiment.

S202: The user equipment 300 provides a trigger to the network node 200 to enter an RLC URLLC mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode. According to the RLC URLLC mode the network node 200 is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment 300.

Embodiments relating to further details of triggering downlink RLC PDU duplication from a network node 200 as performed by the user equipment 300 will now be disclosed.

There could be different types of triggers provided from the user equipment 300 to the network node 200 in action S202.

In some aspects, the trigger is a feedback report. Particularly, in some embodiments, the trigger is provided as a feedback report of a transmission of the RLC PDUs for the

URLLC service towards the user equipment 300.

In some aspects, the trigger is an explicit request. Particularly, in some embodiments, the trigger is provided as an explicit request for the network node 200 to enter the RLC URLLC mode. One particular embodiment for performing downlink RLC PDU duplication towards a user equipment 300 as performed by the network node 200 based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram 400 of Fig. 4. Operation at both the network node 200 and the user equipment 300 is illustrated separately for the MAC layer and the PHY layer on the one hand and for the RLC layer at the other hand.

RLC PDUs denoted PDUl and PDU2 are in a buffer at the RLC layer. Downlink transmission of PDUl and PDU2 is made after RLC data has been requested by the MAC/PHY layers to the RLC layer. PDUl and PDU2 are then transmitted over a logical channel according to the regular RLC mode. If PDUl and/or PDU2 is/are not correctly received, this will trigger HARQ retransmission. The HARQ retransmission is assumed to fail. The RLC PDUs are not correctly delivered to the user equipment 200 within the packet delay budget and hence latency requirements are not satisfied. When the network node 200 obtains an indication that the transmission and HARQ retransmissions are not successful within a certain fraction of the packet delay budget (PDB), e.g. not successful before PDB minus a RoomForRLCRetx value, the network node 200 activates the RLC URLLC mode for this logical channel. RoomForRLCRetx is a delay/time value set for the expected time the RLC duplicate-retransmission requires to be delivered to the user equipment 300. This also triggers duplicate RLC retransmission of the previously transmitted but unsuccessfully received RLC PDUs. The RLC PDUs are according to the example of Fig. 4 duplicate-retransmitted, i.e. duplicate RLC PDUs are transmitted in parallel via e.g. different HARQ processes, different carriers or different MIMO streams or TRPs. Using the URLLC RLC mode, these RLC PDUs and all subsequent RLC PDUs may be transmitted in this duplicate fashion, until the URLLC mode is exited.

Fig. 5 schematically illustrates, in terms of a number of functional units, the components of a network node 200 according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product

910a (as in Fig. 9), e.g. in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA). Particularly, the processing circuitry 210 is configured to cause the network node 200 to perform a set of operations, or actions, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 may be configured to retrieve the set of operations from the storage medium 230 to cause the network node 200 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus, the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The network node 200 may further comprise a communications interface 220 for communications with other entities, functions, nodes, and devices, such as the user equipment 300. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry 210 controls the general operation of the network node 200 e.g. by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the network node 200 are omitted in order not to obscure the concepts presented herein.

Fig. 6 schematically illustrates, in terms of a number of functional modules, the components of a network node 200 according to an embodiment. The network node 200 of Fig. 6 comprises a number of functional modules; a determine module 210a configured to perform action S102, and a transmit module 210c configured to perform action S106. The network node 200 of Fig. 6 may further comprise a number of optional functional modules, such as any of a cancel module 210b configured to perform action S104, a provide module 2iod configured to perform action Sio6a, and a determine module 2ioe configured to perform action S108. In general terms, each functional module 2ioa:2ioe maybe implemented in hardware or in software. Preferably, one or more or all functional modules v may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and/or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 2ioa:2ioe and to execute these instructions, thereby performing any actions of the network node 200 as disclosed herein.

The network node 200 may be provided as a standalone device or as a part of at least one further device. For example, the network node 200 may be provided in a node of the radio access network or in a node of the core network. Alternatively, functionality of the network node 200 may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as the radio access network or the core network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time.

Thus, a first portion of the instructions performed by the network node 200 may be executed in a first device, and a second portion of the instructions performed by the network node 200 may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the network node 200 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a network node 200 residing in a cloud computational environment. Therefore, although a single processing circuitry 210 is illustrated in Fig. 5 the processing circuitry 210 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 210a: 2ioe of Fig. 6 and the computer program 920a of Fig. 9.

Fig. 7 schematically illustrates, in terms of a number of functional units, the components of a user equipment 300 according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 910b (as in Fig. 9), e.g. in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA). Particularly, the processing circuitry 310 is configured to cause the user equipment 300 to perform a set of operations, or actions, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 may be configured to retrieve the set of operations from the storage medium 330 to cause the user equipment 300 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

The user equipment 300 may further comprise a communications interface 320 for communications with other entities, functions, nodes, and devices, such as the network node 200. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry 310 controls the general operation of the user equipment

300 e.g. by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the user equipment 300 are omitted in order not to obscure the concepts presented herein.

Fig. 8 schematically illustrates, in terms of a number of functional modules, the components of a user equipment 300 according to an embodiment. The user equipment 300 of Fig. 8 a trigger module 310a configured to perform action S202. The user equipment 300 of Fig. 8 may further comprise a number of optional functional modules, as represented by functional module 310b. In general terms, each functional module 3ioa:3iob may be implemented in hardware or in software. Preferably, one or more or all functional modules 3ioa:3iob may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and/or the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 3ioa:3iob and to execute these instructions, thereby performing any actions of the user equipment 300 as disclosed herein. Fig. 9 shows one example of a computer program product 910a, 910b comprising computer readable means 930. On this computer readable means 930, a computer program 920a can be stored, which computer program 920a can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 920a and/or computer program product 910a may thus provide means for performing any actions of the network node 200 as herein disclosed. On this computer readable means 930, a computer program 920b can be stored, which computer program 920b can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 920b and/or computer program product 910b may thus provide means for performing any actions of the user equipment 300 as herein disclosed. In the example of Fig. 9, the computer program product 910a, 910b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu- Ray disc. The computer program product 910a, 910b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 920a, 920b is here schematically shown as a track on the depicted optical disk, the computer program 920a, 920b can be stored in any way which is suitable for the computer program product 910a, 910b.

The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

1. A method for performing downlink radio link control, RLC, protocol data unit, PDU, duplication towards a user equipment (300), the method being performed by a network node (200), the method comprising: determining (S102) to enter an RLC ultra-reliable low latency, URLLC, mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service; and performing (S106) the downlink RLC PDU duplication for the URLLC service towards the user equipment (300) upon having entered the RLC URLLC mode.

2. The method according to claim 1, wherein the downlink RLC PDU duplication is performed by any of parallel transmission of the RLC PDUs for the URLLC service: in at least two different HARQ processes, on at least two different carriers, on at least two different MIMO layers, and/or from at least two different TRPs.

3. The method according to any preceding claim, wherein the RLC URLLC mode is entered upon the network node (200) having obtained an indication that the latency bound and reliability requirement of the URLLC service cannot be met using the currently used RLC mode.

4. The method according to claim 3, wherein the indication is represented by any of: number of received NACKs for HARQ transmission of the RLC PDUs for the URLLC service exceeds a threshold value, a portion of a packet delay budget of the RLC PDUs for the URLLC service is reached, time for arrival of RLC status report with ACK for HARQ transmission of the RLC PDUs for the URLLC service exceeds a threshold value, a logical channel on which the RLC PDUs for the URLLC service are to be transmitted fails to support HARQ retransmissions that fulfil the latency bound and reliability requirement, there is not any unoccupied logical channel on which the RLC PDUs for the URLLC service can be transmitted.

5. The method according to claim 3, wherein the indication is obtained as a trigger from a Medium Access Control, MAC, protocol layer at the network node (200).

6. The method according to claim 3, wherein the indication is obtained as a trigger from the user equipment (300).

7. The method according to any preceding claim, wherein the method further comprises: determining (S108) to exit the RLC URLLC mode upon the network node (200) having obtained an indication that using the RLC URLLC mode is no longer needed to meet the latency bound and reliability requirement of the URLLC service.

8. The method according to claim 7, wherein the indication is represented by any of: expiration of a timer, the timer having started upon the RLC URLLC mode having been entered or upon initial transmission of the RLC PDUs for the URLLC service, number of received HARQ acknowledgements for HARQ transmissions of the

RLC PDUs for the URLLC service exceeds a threshold value, reception of a status report indicating successful reception at the user equipment (300) of the RLC PDUs for the URLLC service, a maximum number of duplicates of the RLC PDUs for the URLLC service having been transmitted, there is at least one unoccupied logic channel on which the RLC PDUs for the URLLC service can be transmitted.

9. The method according to any preceding claim, wherein the method further comprises: providing (Sio6a), as part of performing the downlink RLC PDU duplication of the RLC PDUs for the URLLC service, the RLC PDUs for the URLLC service to a lower layer entity in the network node (200) either in a single buffer from which all downlink RLC PDU duplications are to be made, or in as many buffers as there are downlink RLC PDU duplications to be made.

10. The method according to any preceding claim, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be multiplexed with other RLC PDUs for a non-URLLC service.

11. The method according to any preceding claim, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be segmented into RLC PDU segments.

12. The method according to any preceding claim, wherein, according to the RLC URLLC mode, the RLC PDUs for the URLLC service are, upon transmission, immediately considered to be negatively acknowledged regardless of whether positive or negative acknowledgement of the RLC PDUs is received from the user equipment (300).

13. The method according to any preceding claim, wherein the method further comprises: cancelling (S104) an ongoing HARQ retransmission of the RLC PDUs for the URLLC service.

14. The method according to claim 13, wherein in the HARQ retransmission, the RLC PDUs for the URLLC service are multiplexed with other RLC PDUs for a non- URLLC service, or wherein in the HARQ retransmission, there are only RLC PDUs for the URLLC service.

15. The method according to any preceding claim, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed as an extension to an RLC unacknowledged mode.

16. The method according to claim 15, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed only for RLC PDUs for the URLLC service which have yet not been transmitted.

17. The method according to any of claims 1 to 14, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed as an extension to an RLC acknowledged mode.

18. The method according to claim 17, wherein, according to the RLC URLLC mode, the downlink RLC PDU duplication of the RLC PDUs for the URLLC service is to be performed for at least one of: RLC PDUs for the URLLC service yet to be transmitted, transmitted RLC PDUs for the URLLC service for which a negative acknowledgement, NACK, has been received from the user equipment (300).

19. The method according to any preceding claim, wherein the URLLC service corresponds to a quality-of-service, QoS, and/or a latency requirement.

20. The method according to claim 19, wherein the QoS requirement is defined by QoS identifier 5QI.

21. A method for triggering downlink radio link control, RLC, protocol data unit, PDU, duplication from a network node (200), the method being performed by a user equipment (300), the method comprising: providing (S202) a trigger to the network node (200) to enter an RLC URLLC mode when a latency bound and reliability requirement of an ultra-reliable low latency, URLLC, service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment (300).

22. The method according to claim 21, wherein the trigger is provided as a feedback report of a transmission of the RLC PDUs for the URLLC service towards the user equipment (300).

23. The method according to claim 21, wherein the trigger is provided as an explicit request for the network node (200) to enter the RLC URLLC mode.

24. A network node (200) for performing downlink radio link control, RLC, protocol data unit, PDU, duplication towards a user equipment (300), the network node (200) comprising processing circuitry (210), the processing circuitry being configured to cause the network node (200) to: determine to enter an RLC ultra-reliable low latency, URLLC, mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service; and perform the downlink RLC PDU duplication for the URLLC service towards the user equipment (300) upon having entered the RLC URLLC mode.

25. A network node (200) for performing downlink radio link control, RLC, protocol data unit, PDU, duplication towards a user equipment (300), the network node (200) comprising: a determine module (210a) configured to determine to enter an RLC ultra- reliable low latency, URLLC, mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service; and a transmit module (210c) configured to perform the downlink RLC PDU duplication for the URLLC service towards the user equipment (300) upon having entered the RLC URLLC mode.

26. The network node (200) according to claim 24 or 25, further being configured to perform the method according to any of claims 2 to 20.

27. A user equipment (300) for triggering downlink radio link control, RLC, protocol data unit, PDU, duplication from a network node (200), the user equipment (300) comprising processing circuitry (310), the processing circuitry being configured to cause the user equipment (300) to: provide a trigger to the network node (200) to enter an RLC URLLC mode when a latency bound and reliability requirement of an ultra-reliable low latency, URLLC, service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment (300).

28. A user equipment (300) for triggering downlink radio link control, RLC, protocol data unit, PDU, duplication from a network node (200), the user equipment (300) comprising: a provide module (310a) configured to provide a trigger to the network node (200) to enter an RLC URLLC mode when a latency bound and reliability requirement of an ultra-reliable low latency, URLLC, service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment (300).

29. The user equipment (300) according to claim 27 or 28, further being configured to perform the method according to any of claims 22 to 23.

30. A computer program (920a) for performing downlink radio link control, RLC, protocol data unit, PDU, duplication towards a user equipment (300), the computer program comprising computer code which, when run on processing circuitry (210) of a network node (200), causes the network node (200) to: determine (S102) to enter an RLC ultra-reliable low latency, URLLC, mode when a latency bound and reliability requirement of a URLLC service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service; and perform (S106) the downlink RLC PDU duplication for the URLLC service towards the user equipment (300) upon having entered the RLC URLLC mode.

31. A computer program (920b) for triggering downlink radio link control, RLC, protocol data unit, PDU, duplication from a network node (200), the computer program comprising computer code which, when run on processing circuitry (310) of a user equipment (300), causes the user equipment (300) to: provide (S202) a trigger to the network node (200) to enter an RLC URLLC mode when a latency bound and reliability requirement of an ultra-reliable low latency, URLLC, service cannot be met using a currently used RLC mode, wherein according to the RLC URLLC mode the network node (200) is to perform downlink RLC PDU duplication for the URLLC service towards the user equipment (300).

32. A computer program product (910a, 910b) comprising a computer program (920a, 920b) according to at least one of claims 30 and 31, and a computer readable storage medium (930) on which the computer program is stored.