WO2018171407A1

WO2018171407A1 - Layer 2 architecture for cellular radio systems

Info

Publication number: WO2018171407A1
Application number: PCT/CN2018/077865
Authority: WO
Inventors: Olivier Marco
Original assignee: Jrd Communication (Shenzhen) Ltd
Priority date: 2017-03-24
Filing date: 2018-03-02
Publication date: 2018-09-27
Also published as: CN110546985B; GB2561545B; GB2561545A; GB201704773D0; CN110546985A

Abstract

Systems and methods are provided for operating layer 2 of a cellular radio system. In particular methods for re-ordering of PDUs to ensure in order delivery with mechanisms to prevent excessive delays. Out of order delivery is provided where fast delivery is desired.

Description

Layer 2 Architecture For Cellular Radio Systems

Technical Field

The present disclosure relates to the layer 2 architecture of cellular communication systems, and in particular to the PDCP sub-layer of a cellular architecture.

Background

Wireless communication systems, such as the third-generation (3G) of mobile telephone standards and technology are well known. Such 3G standards and technology have been developed by the Third Generation Partnership Project (3GPP) . The 3 ^rd generation of wireless communications has generally been developed to support macro-cell mobile phone communications. Communicationsystems and networks have developed towards a broadband and mobile system. The 3rd Generation Partnership Project has developed the so-called Long Term Evolution (LTE) system, namely, an Evolved Universal Mobile Telecommunication System Territorial Radio Access Network, (E-UTRAN) , for a mobile access network where one or moremacrocells are supported by a base station known as an eNodeB or eNB (evolved NodeB) . More recently, LTE is evolving further towards the so-called 5G or NR (New Radio) .

5G or NR proposes a new radio link standard for the UE to base station link. The NR configuration and protocols utilise many LTE features as a starting point, but add a wide range of additional features and operation modes very different to LTE. The proposed layer 2 architecture of NR is shown in Figure 1. The MAC, RLC, and PDCP layers are comparable to the LTE layers of the same name, but as explained below have some fundamental differences in the functionality provided by the layers. A new AS layer is provided over PDCP to provide connection to the Next Generation Core (NGC) and support the new QoS framework proposed for the system.

Key differences between the LTE RLC/PDCP layers and those of the NR proposal are support for Out-of-Order Delivery (OOD) from RLC to PDCP of complete PDCP PDUs after RLC SDU reassembly, and no support for concatenation of RLC SDUs (i.e. each RLC data PDU contains one RLC SDU (or a segment of 1 RLC SDU) ) . The OOD of complete PDCP PDUs to PDCP was agreed to enable on the fly deciphering of PDCP PDUs, which reduce the processing capability needs. It is referred to as OOD radio link in the following. It is noted that a single PDCP entity might be connected to several radio links (split bearer) .

In the LTE system, only In-Order Delivery (IOD) bearers are supported (i.e. a bearer always provides IOD of packets, with more or less reliability depending of the QoS parameters) . Moreover, IOD is first enforced between the RLC and PDCP layers, i.e. at the radio link level. This means the receiving RLC entity provides PDCP PDUs to the receiving PDCP entity while conserving the initial order with which they were provided from the transmitting PDCP entity to the transmitting RLC entity. Looking at the PDCP PDU flow from a sending PDCP entity to the receiving PDCP entity, this means that in normal condition the receiving PDCP entity expect IOD from lower layers. The only exceptions to IOD delivery of PDUs to the PDCP entity are during dual connectivity (when a split bearer is configured) , or during HandOver (HO) .

In these limited circumstances the PDCP entity may have to re-order the received PDUs. The second case (handover) is sporadic. At HO, when RLC AM is used, latest PDCP PDUs transmitted on the initial link may be retransmitted on the new link. Thisis handled by setting up a reordering buffer only when the lower layers are re-established on the new link (only PDCP SDUs from old link are stored, while waiting for PDCP PDUs with higher SN arriving from the new link) . The first case (split bearer during dual connectivity) needs a reordering buffer during normal operation. With a split bearer, the PDCP PDU flow is split across 2 radio links (also denoted “legs” or “branches” ) , each with separate RLC entities, hence the receiving PDCP entity may receive PDUs from two different RLC entities. Even though each one separately provides IOD to PDCP, the overall IOD to PDCP is not ensured. However, in LTE, dual connectivity operates in RLC AM only (on each branch) and hence at least there is no RLC PDU loss that needs to be accommodated by the reordering process. In contrast, whenever an IOD bearer is required, the proposed NR system reordering will be required in the PDCP entity in all cases, including single connectivity (since it is no longer ensured by RLC) . It would also be required in particular whenRLC UMis used, where there may be significant PDU loss, whenever an IOD bearer is required. Acareful design is needed to avoid excessive reordering delay. In parallel, the NR system also targets lower user plane latency than LTE. A system is thus required such that NR can support efficiently IOD bearers while reordering functionality is in PDCP only (OOD radio links) .

As IOD is no longer enforced between RLC and PDCP, it also opens the door to the support of OOD bearers (a bearer for which IOD to upper layers is not enforced) . Such bearer can be useful to eliminate completely any reordering delay towards the upper layers, thereby reducing the latency while not compromising the reliability. A system is thus required to enable the support of OOD bearers.

Summary

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

The invention is defined in the claims which are appended to this description.

The non-transitory computer readable medium may comprise at least one from a group consisting of: a hard disk, a CD-ROM, an optical storage device, a magnetic storage device, a Read Only Memory, a Programmable Read Only Memory, an Erasable Programmable Read Only Memory, EPROM, an Electrically Erasable Programmable Read Only Memory and a Flash memory.

Brief description of the drawings

Further details, aspects and embodiments of the invention will be described, by way of example only, with reference to the drawings. Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. Like reference numerals have been included in the respective drawings to ease understanding.

Figure 1 shows the anticipated NR layer 2 architecture;

Figure 2 shows a reordering example;

Figure 3 shows a reordering window;

Figure 4 shows a reordering process;

Figure 5 shows a flow chart of a reordering process; and

Figure 6 shows a reordering example.

Detailed description of the preferred embodiments

Those skilled in the art will recognise and appreciate that the specifics of the examples described are merely illustrative of some embodiments and that the teachings set forth herein are applicable in a variety of alternative settings.

LTE may provide a starting point for providing IODbearer support in the proposed system, but if that is done a number of difficulties are encountered and must be overcome.

Reordering in LTE single connectivity is mainly based on RLC SN, as IOD is first enforced between the RLC and PDCP layers. Reordering on a radio link is needed due to HARQ operation which lead to OOD of RLC data PDUs (or RLC PDUs segments) to RLC. It is up to RLC to store complete PDUs or PDUs segments while waiting for any missing PDUs or PDU segments, in order to ensure IOD to PDCP. When RLC AM protocol is used, there are no gaps in the final RLC SN sequence due to the operation of ARQ. The reordering process does not therefore create any additional delay in addition to that caused by the ARQ system. When RLC UM is used, sparse gaps in the RLC SN sequence are encountered due to sporadic HARQ failure and the additional delay caused by the re-ordering processing is limited to waiting the lost RLC PDUs (each gap in the sequence resulting in a delay equal to the timer value t-Reordering) .

Reordering in the PDCP entity will be based on PDCP SN (not RLC SN) and hence the LTE approach cannot be utilised and new problems are encountered. In particular, gaps in the PDCP SN sequence must be considered by the selected process. However, it can be attractive to allow PDCP SN gaps at the transmitter for AQM (Active Queue Management) , flow control or SDU discard. Where re-ordering is conducted in the RLC entity this does not affect the PDCP entity, but this must be considered by a re-ordering algorithm in the PDCP entity. In particular, the PDCP entity could wait for PDCP PDUs that will never arrive.

For the proposed system dual connectivity may support RLC UM such that alternate PDCP PDUs could be routed to alternate legs (in LTE system, such use case was not possible as split bearer was supported only with RLC AM) . A transport block (TB) may include hundreds of non-consecutive PDCP PDUs meaning a single HARQ failure may result in hundreds of gaps in the PDCP PDU SNs sequence which must be accommodated by the reordering algorithm in the PDCP entity.

Conventional re-ordering algorithms apply a reordering time (t-reordering) for which the algorithm will wait for a missing SN or consecutive missing SNs; typical times are tens of ms. Such a system would not work with a data stream with numerous gaps created by a single HARQ failure.

To aid understanding of the problems with existing reordering systems, in particular the LTE system an explanation of such systems follows.

In LTE, PDCP reordering window operation is based on the following variables and timer:

● Next_PDCP_RX_SN –Next expected PDCP SN at the receiver for the PDCP entity. At establishment of the PDCP entity, the UE shall set Next_PDCP_RX_SN to 0.

● RX_HFN -Indicates the HFN value for the generation of the COUNT value used for the received PDCP PDUs for a given PDCP entity. At establishment of the PDCP entity, the UE shall set RX_HFN to 0.

● Last_Submitted_PDCP_RX_SN -For PDCP entities for DRBs mapped on RLC AM Last_Submitted_PDCP_RX_SN indicates the SN of the last PDCP SDU delivered to the upper layers. At establishment of the PDCP entity, the UE shall set Last_Submitted_PDCP_RX_SN to Maximum_PDCP_SN.

● Reordering_PDCP_RX_COUNT -the value of the COUNT following the COUNT value associated with the PDCP PDU which triggered t-Reordering.

● t-Reordering -This timer is used to detect loss of PDCP PDUs. If t-Reordering is running, t-Reordering shall not be started additionally, i.e. only one t-Reordering per PDCP entity is running at a given time.

As noted above, in LTE, reordering in the PDCP entity is only required during dual connectivity or HO, and when RLC AM is used. Operation of the LTE reordering process in PDCP will be given using the example of dual connectivity.

The variables listed above define a reordering window (which could also be called a receiving window) as represented in Figure 2. Its size is half the PDCP SN space.

The variable Last_Submitted_PDCP_RX_SN+1defines the lower edge (LE) of the reordering window, i.e. the first PDU not yet received from the lower layers (LL) . Earlier PDUs are no longer waited for from LL, and were already delivered to UL. The setting of Last_Submitted_PDCP_RX_SN uses a standard T-reordering based mechanism which works as follows:

Initial state is Last_Submitted_PDCP_RX_SN = MaxSN, Next_PDCP_RX_SN= 0.

If new PDUs are received in receiving window:

a. Last_Submitted_PDCP_RX_SN, Next_PDCP_RX_SNare updated.

b. If T-reordering is running

i. If the PDCP SDU with Reordering_PDCP_RX_COUNT –1 was delivered to UL:

1. The timer is stopped and reset

c. If T-reordering is not running (including when stopped above)

i. If there is at least one stored PDCP SDU, the timer t-Reordering is started, and Reordering_PDCP_RX_COUNT to the COUNT value associated to RX_HFN and Next_PDCP_RX_SN.

If new PDUs are receivedoutside of the receiving window: they are considered late PDUs, and are discarded (reordering window is a “pushed” type window) .

If t-Reordering expires

a. Reordering_PDCP_RX_COUNT is updated to the next missing PDU with SN >= Reordering_PDCP_RX_COUNT (missing PDCP SDUs with COUNT <Reordering_PDCP_RX_COUNT are no longer waited for) , previous PDUs are delivered to UL in ascending COUNT order

b. If there is at least one stored PDCP SDU, the timer t-Reordering is started, and andReordering_PDCP_RX_COUNT to the COUNT value associated to RX_HFN and Next_PDCP_RX_SN.

The operation of the reordering algorithm in LTE is more generally described in the following text. It applies both to the implementation in PDCP, as described above, but also to the implementation in both RLC AM (used before invoking ARQ) and RLC UM (used for IOD to PDCP) .

Considering a flow of incoming PDUs, identified by their sequence number, the reordering functionality maintains the following sequence number variables:

● R: corresponds to the SN of the earliest PDU considered for reordering. Earlier PDUs are no longer considered for re-ordering, i.e. they are already sent to the following block (when used to provide in-order delivery) or considered in a status report (when used for ARQ) . The value is used as the lower edge of the reordering window.

● H: corresponds to the SN of the highest received PDU. Used as the higher edge of the reordering window.

● X: corresponds to the SN of the “reordering PDU” , i.e. the PDU which triggered/which is associated with the t-Reordering timer.

As usual all arithmetic operations on SNs are affected by the modulus on SN space size, which is not detailed here for simplicity. Moreover, the actual variables can equivalently be R-1, H+1 or X+1 depending of the implementation in the specification. It is understood that due to solve SN potential ambiguity of incoming PDUs, generally the maximum reordering window size is set to half the SN space. Then there are 2 main ways to consider incoming PDUs falling out of maximum reordering window: either as new PDUs, or old PDUs. In the first case, the reordering window is “pulled” i.e. its higher edge (HE) is advanced when receiving packets out of the maximum reordering window, whereas in the latter case it is “pushed” , as only the arrival or the decision to no longer wait missing packets can advance the window by pushing its lower edge (LE) . The t-Reordering aspects discussed below generally apply to both window types.

Figure 3 gives an illustration of a possible situation at a given time t. The PDUs in blue are no longer considered for reordering (e.g., already sent to upper layers) . The PDUs within the reordering window (in light red, and yellow) are considered for reordering, i.e., the missing PDUs in between are waited for.

The timer t-Reordering is used to detect the loss of PDUs and avoid reordering window stalling. Typically its value is configured by RRC. In the following we note its value “Treordering” (without dash) . It needs to cover the worst reordering delay introduced by lower layers. When a PDU is received with a sequence number N different from R, the missing PDUs R, …, N-1 are supposed to arrive within Treordering from reception of PDU N (at instant TN) . Hence these missing PDUs only need to be waited for during that time (up to instant TN + Treordering) .

While PDUs are received in sequence, R=H+1, the reordering window is empty and no delay is introduced. As soon as a PDU with SN N >R is received, H is set to N, R does not change. The reordering window becomes non-empty (R<H+1) and the timer t-Reordering is started and is associated with the reordering PDU X=H. If t-Reordering timer expires (lost PDU) , any remaining missing PDUs before X are no longer waited for, and the reordering window lower edge R is advanced to the first missing PDU>X. The PDU X, as well as earlier PDUs which were blocked in the reordering window are no longer considered for reordering (and can e.g. be delivered to upper layers) . As expected the maximum introduced delay is t-Reordering from the reception of PDU X.

Whenever t-Reordering is stopped and reset (because missing PDUs up to X were received) , or expires, the reordering window lower edge R is advanced to the first missing PDUs>X. Then, if R < H+1 (reordering window is still not empty, because further PDUs were received increasing H and creating other gaps in the received PDUs) , t-Reordering is started and is associated with X = H. However in that case, the PDU with SN H could have been received Δms before, which introduces an additional delay of Δms to the expected maximum delay.

This additional delay is shown in Figure 4. At T ₁, PDU H ₁ is received, which starts the timer t-Reordering associated to X ₁ = H ₁. At TA, before t-Reordering expiry, the green PDU A is received. The timer t-Reordering is stopped, the reordering window lower edge is advanced from R ₁ to R ₂, PDUs up to R ₂ can be delivered in sequence. At this point, since R ₂< H ₂+1, the timer t-Reordering is started again and is associated to X ₂ = H ₂. As it can be seen, the PDU X ₂ was actually received at T ₂, i.e. Δms before TA. In this scenario, assuming the PDU R ₂ is lost, the PDUs up to X ₂ are blocked until TA + Treordering = T ₂ + Treordering + Δms, whereas they couldhave been delivered at T ₂ + Treordering.

Figure 5 shows an algorithm for providing reordering of PDCP PDUs in the proposed system which intends to alleviate at least some of the problems with prior systems. At step 500 the PDCP entity has connections to a plurality of LL legs (for example a plurality of OOD radio links) , each of which deliver PDCP PDUs to the PDCP entity. In single connectivity use case, only one leg is used. In dual connectivity use case (split bearer) , 2 legs are used. NR is also expected to support multiple connectivity use cases in which a PDCP entity might be connected to even more than 2 legs.

At step 501 each LL leg may deliver PDCP PDUs to the PDCP entity. On a given LL leg, PDCP PDUs can be delivered out-of-order.

At step 502 each LL leg transmits to the PDCP entity an indication that enables to derive the latest PDCP PDU (in the PDCP PDUs sequence) that should no longer be considered for reordering for that leg. Put another way, the indication enables to derive the earliest PDCP PDU (in the PDCP PDUs sequence) that should still be considered for reordering for that leg (i.e. waited for on that leg) . In the following, this PDCP PDU is referred to with the state variable VR (RLi) , where i is the index of the leg. VR (RLi) can correspond to a PDCP_SN or a COUNT value (HFN+PDCP_SN) . Within PDCP, a reordering window is defined which covers the PDCP PDUs received by the PDCP entity and which are to be considered by the reordering algorithm. PDCP PDUs falling prior to the reordering window will be assumed lost by the reordering algorithm and the reordering process, and transmission to the higher layer, will proceed without those PDCP PDUs.

At step 503 the PDCP entity performs PDCP PDU reordering utilising the indication received from each LL leg. The indication of the earliest PDCP PDU that should be considered for reordering can limit the time the PDCP entity will wait for a missing PDU. When each configured LL leg provides the information, it is possible for PDCP to know whether a missing PDU will no longer be received from any of the legs. That is, the reordering window lower edge in PDCP may be advanced based on LL indication from each leg, such as the t-reordering period is not utilised for every missing PDU. This process avoids the delays associated with waiting for PDCP PDUs which will never arrive, by using additional LL information for each leg which is otherwise not visible when considering only PDCP SNs of arriving PDUs. It is important to note that this is only possible if all legs are able to provide the indication to PDCP. As soon as one leg is not able to provide the indication to PDCP, it means that any missing PDU at the PDCP receiver could always be expected from this leg, hence there would be no benefit from using the indication from the other legs

The use of the indication from each LL leg is particularly useful for RLC UM, where HARQ failure will create gaps. With single connectivity, T-reordering timer in PDCP might be used to cover the time to wait for HARQ reordering. Howeverfor dual connectivity, PDCP SN gaps arise due to HARQ failure, or a backhaul delay between the two paths (thus creating a gap as PDCP PDUs via one path arrive before PDUs via the other path) . If using a reordering timer, it must be set to a very conservative value to cover both possible delays. The use of the indication from leg allows both situations to be covered without an excessive delay.

In an example system the HARQ reordering delay may be 10ms and the backhaul delay may be 20ms. In a conventional algorithm in the PDCP entity the reordering timer would be set to 30ms, meaning a 30ms delay for every gap created by a HARQ failure. In contrast, a timer for each leg may be set to 10ms giving a 10ms delay for each HARQ failure.

The indication from each LL leg which enables to derive VR (RLi) may be based on an independent reordering timer for each leg. Each reordering time can be configured according to the HARQ policy of the relevant eNB such that the PDCP entity can determine whether to wait for a PDCP PDU from each leg independently.

How to derive VR (RLi) might not need to be specified. It is understood that this information can be derived for instance from the knowledge of RLC state variables, corresponding to the lower edge of the RLC reception window.

In case of RLC AM, knowingthe RLC state variable VR (Ri) for leg i, the PDCP PDU N _i from the RLC PDU VR (Ri) -1 is the latest PDCP PDU no longer considered for reordering for leg i. Hence, the earliest PDCP PDU considered for reordering for leg i is N _i+1, i.e. VR (RL _i) = Ni+1.

In case of RLC UM, a similar algorithm can be used based on VR (URi) variable instead of VR (Ri) . However, one important point to consider is that given OOD is allowed from RLC to PDCP, maintaining a t-Reordering mechanism in RLC UM (hence a receiving window and its associated VR (URi) ) would not be required for ensuring IOD to PDCP. It is argued here that even though not needed for the purpose of ensuring IOD to PDCP, maintaining a t-Reordering mechanism in RLC UM (receiving windowand its associated VR (URi) ) is beneficial as it enables to derive the assistance information VR (RLi) which can expedite the reordering in PDCP. As an alternative, such t-Reordering mechanism might be implemented as part of PDCP, as a subblock added at the input of each leg connected to the PDCP entity. From a modelling point of view, this solution is less attractive as it introduces per-leg subblocks within the receiving PDCP entity. Another concern of that solution is that the per-leg reordering would be based on PDCP SN rather than RLC SN. The difference with proposed solution is that any PDCP SN gap created at the transmitter side would become visible to PDCP and would add reordering delay.

It may be allowed to have PDCP PDU without SN (e.g., control PDU) , or the RLC PDU with VR (R) -1 or VR (UR) -1 may not exist (for instance in case of RLC UM, when VR (UR) is updated following pulling of the reordering window) . In such case, the PDCP PDU N _i which can be used to derive VR (RLi) corresponds to the latest PDCP data PDU extracted before VR (R) or VR (UR) .

In certain configurations it may be preferable to allow Out Of Order delivery from the PDCP entity to a higher layer entity, for example where latency requirement is more important than PDU ordering (OOD bearer) . When OOD is activatedPDCP SDUs are passed directly to the upper layer without waiting for missed PDCP SDUs (from missed PDCP PDUs) . However, while allowing OOD to upper layers, it is important that delivery of duplicate packets are avoided. Duplication might happen at various places in the transmission resulting in the same PDCP PDU received several times by the PDCP entity. This can be due to lower layers errors (for instance following HARQ protocol errors such as ACK to NACK errors) but may be also done on purpose (several replicas of the same PDCP PDU may be sent on different radio links to improve the reliability of the transmission) . Hence, the PDCP PDU SN is utilised to record the PDUs that have been successfully received (and possibly deciphered) for transmission to the upper layer. Should a duplicate PDCP PDU SN be received the PDU is discarded as a duplicate. To allow such duplicate packet discarding for OOD bearer, it is beneficial to keep the same PDCP receiver window mechanism used when IOD bearer is configured, i.e. maintaining the same window state variables. The only required difference when OOD bearer is configured is that instead of storing SDUs for later IOD delivery, only the SDUs are delivered but the indication they are delivered is stored. This enables an efficient implementation of OOD bearer, reducing divergence with IOD bearer both from algorithm specification point of view and implementation point of view.

The support of OOD bearer was considered mainly for DRBs (data radio bearers) . However, it may also be useful for SRBs (signalling radio bearers) . An example where OOD may be utilised is for RRC Measurement Reports (particularly periodic measurement reports) carried on SRB where low latency is preferable to correct ordering of reports, while reliability should not be compromised. Hence it can be beneficial to configure OOD for SRBs. A SN might be included at RRC level to identify PDUs received out of order (for instance, a measurement report which was delayed and received later than expected could then be discarded considering that its SN is lower than the highest received SN) .

The configuration of OOD or IOD may be made independently for each beareras required.

In another embodiment, the reordering window may be implemented utilising a plurality of timers to monitor the time since a missing PDCP PDU. In conventional systems a single timer is utilised which is restarted each time a gap in the received PDCP PDUs sequence is encountered. This timer is started as soon as missing PDUs are detected (the received PDU is not the next in-sequence, hence it created a gap in the sequence) (a missing PDU received later may split an initial gap in 2 sub-gaps, we do not consider this as “creating a gap in the sequence” ) .

The missing PDUs corresponding to this gap are then waited for while T-reordering is running. If all are received (gap filled) , the timer is stopped and reset. If at least some are not received, the timer will expire and missing PDUs are no longer waited for. In both cases, it may happen that further PDUs were received while T-reordering was running, creating further gaps in the sequence. In that case, the timer will then be restarted just as if the gaps were just created, without consideration of when the PDUs actually created these gaps. This was described previously when analysing the general operation of the reordering algorithm in LTE (Figure 4) . Such systems can result in additional reordering delays as explained earlier. Ideally, whenever new gaps in the sequence are created, the corresponding missing PDUs should not be waited for during more than T-reordering delay.

It is therefore proposed to utilise a plurality of reordering timers such that a new timer is started each time a gap is detected, i.e. whenever a new PDU is received with a SN not following the highest received PDCP SN. Each time a new timer is started, it is associated to the PDCP PDU (PDCP SN or COUNT value) which created the sequence gap. Missing PDCP PDUs corresponding to each gapare then waited for only for a maximum duration corresponding to the maximum value of the reordering timer for that gap. When a reordering timer expires, the missing PDUs corresponding to this gap can be considered lost, i.e. PDCP does not need to wait for PDUs earlier in sequence than the PDCP PDU to which the timer was associated. It is convenient to allow multiple instance of the reordering timer for specifying the algorithm. In practical implementation, only one single reordering timer is needed, since it is enough to store a timestamp for each newly created gap. When the timer needs to be restarted, the duration can just be set as T-reordering delay - (current timestamp -gap timestamp) , which ensure that the missing PDUs are just waited for as long as it is required, with no extra. Such a system requires a higher number of timers, or storing of timestamps, which carries some small overhead burden, but provides a reduced latency for systems in which there can be multiple gaps within the expected reordering delay in the received PDCP PDUs.

It is possible to reduce the number of timers depending of the expected number of gaps to be handled in parallel (reducing the gap timestamps to be stored) . For instance, using N t-Reordering timers enable to handle in an optimal way (i.e. without extra reordering delay) up to N gaps in parallel. Additional gaps will lead to waiting for the maximum value of the t-Reordering timer but such an approach may provide a more attractive compromise between latency and processing requirements.

The reordering window operation used by LTE PDCP layer and discussed above assumes that PDCP PDUs received outside of the reordering window are old PDUs, and are discarded (so called “push” window operation) . The operation was defined in this way as the principal use of reordering in LTE is during HO in which old PDUs are likely to have been retransmitted via the new connection and can thus be consider as duplicates and disposed of. To avoid excessive amendment the same system was used for dual connectivity, but only RLC AM is supported thus limiting PDCP PDU gaps.

In such systems it is also assumed that the PDCP transmitter is configured such that less than half the PDCP SN space is in transmission at any time. This can be ensured due to the RLC AM feedback (e.g., VT (A) knowledge) . The PDCP transmitter has implicit knowledge of the “PDCP VT (A) ” value, corresponding to the cumulative ACK value from the PDCP receiver. As long as the PDCP transmitter controls transmission such that less than half of the PDCP SN space is in transmission, it is not possible to actually receive PDCP PDUs outside of the reordering window.

However, in the proposed system, since the reordering will be used with RLC UM, including in dual connectivity use cases, the prior assumptions are no longer applicable. In particular, without acknowledgements from the receiver the transmitter cannot control the number of PDCP PDUs in transmission and hence cannot ensure less than half the PDCP SN space is in transmission. If more than half the PDCP SN space is in transmission HFN synchronisation at the PDCP receiver can be lost. In LTE, to some extent this could be controlled by the transmitter using for instance HARQ feedback. However for RLC UM split bearer this becomes challenging.

To avoid loss of HFN synchronisation the full COUNT value can be used as PDCP SN. However, this would give a significant overhead, particularly in addition to the RLC header overhead which is larger than in the previous systems.

A transmit window at the PDCP transmitter could also be defined. When RLC AM is utilised, the lower edge of the transmit window can be advanced through implicit indication from RLC (e.g., VT (A) values) . However, since such information is not available when RLC UM is used, in addition, a cumulative ACK report from the PDCP receiver to the PDCP transmitter can be utilised to move the transmission window lower edge. This can be beneficial not only when RLC UM is used, but also when RLC AM is used but PDCP PDU discard is required for some reason. Such a report may be sent automatically from the PDCP receiver depending on window occupancy (window based) , or following a polling mechanism from the PDCP transmitter.

The above discussion has assumed that the RLC entity provides out of order delivery to the PDCP entity. This means that the RLC entity does not need to perform a reordering function, and hence does not need to store RLC PDUs pending reordering. Rather, the RLC entity can pass the RLC SDU directly to the PDCP entity. As noted above NR plans to support RLC PDU segmentation and hence RLC PDU segments should be stored for reassembly. Once the RLC PDU is reassembled the RLC SDU can be extracted and passed to the PDCP entity.

For RLC AM, a receive window may still be maintained in the RLC entity and RLC PDUs which are received outside of that window may be discarded. The RLC entity may also perform duplication detection within the receive window and discard PDUs that have already been processed and transmitted to the PDCP entity. This can be done by storing the information of RLC SDUs which were transmitted to PDCP, instead of storing the actual RLC PDUs. For RLC UM, a reordering window may still be maintained in the RLC entity. Similarly, the RLC entity may also perform duplication detection within the window and discard PDUs that have already been processed and transmitted to the PDCP entity. This can be done by storing the information of RLC SDUs which were transmitted to PDCP.

In NR, it was agreed that similarly to LTE, RLC AM supports T-reordering like functionality for the purpose of determining the content of the RLC status report.

The RLC AM ARQ procedure can be decomposed in 3 steps:

a. At Rx: detection of missing PDU (s) , which will not be recovered by LL retransmissions (HARQ)

b. At Rx: sending of a STATUS REPORT requesting retransmission of missing PDU (s)

c. At Tx: retransmission of the missing PDU (s) .

The purpose of T-reordering in RLC AM is to determine how much time the RLC receiver waits for missing PDUs before declaring them as lost and invoking ARQ procedure. The T-reordering in RLC AM hence impacts the step ‘a’ in ARQ procedure.

Generally, this is needed since LL do not provide in-order delivery to RLC, e.g. because of HARQ operation. In such case, the duration a missing PDU should be waited for can be derived from HARQ settings (e.g. HARQ RTT and number of HARQ retransmission) , and the NW should configure the shortest possible time in order to not delay the ARQ procedure.

However, in legacy T-reordering operation, it can be seen that in case further gaps are created in the reception sequence while T-reordering is running (waiting for initial missing PDUs) , the PDUs corresponding to these gaps will be waited for more than what is required, as T-reordering timer will be restarted as soon as first missing PDUs are received or no longer waited for, without consideration of when these gaps were created. This creates additional delay in invoking the ARQ procedure, which is not desirable.

As explained above in NR, a single HARQ failure may affect hundreds of RLC PDUs. Generally, they should be consecutive, in which case a single gap in the RLC PDU sequence would be created. Though, if we have centralized ARQ (CU/DU split option 3) , we may have new RLC PDUs alternatively sent one each leg. In such case, a single HARQ failure will create hundreds of gaps in the RLC PDUs sequence leading to potentially significant delays causing by a single failure.

Similar to the process described above, a new system in which a new T-reordering timer is started whenever a gap is detected (when receiving highest SN PDUs) can be utilised to avoid excessive delays.

In a practical implementation, only one reordering timer is needed, with a time stamp of each new gap being stored. When the timer needs to be restarted, the duration can be set as (T-reordering delay - (current timestamp -gap timestamp) ) , which ensures that each missing PDU is waited for as long as is required, with no additional delay due to multiple gaps.

Comparable considerations apply to RLC UM and the same multiple timer processes described above can be utilised in such configurations.

It is observed that the RLC AM status reports (for ARQ feedback) and RLC AM retransmissions, corresponding respectively to the steps ‘b’ and ‘c’ of the ARQ procedure, may be small and infrequent data. In order to minimize the overall ARQ latency, the control data and/or the retransmitted RLC PDUs or PDU segments may be mapped to URLLC resources, which benefit from very low latency and high reliability, but are mostly applicable to small and infrequent data. To enable this, the RLC AM status reports and/or RLC AM retransmissions may be mapped to a different logical channel than the one on which is mapped the RLC data PDU initial transmissions. This different logical channel could then be mapped on URLLC resources. The logical channel used for initial transmission as well as the alternate channel used for retransmissions are handled by the same receiving RLC entity.

It is also noted that contrary to LTE, ARQ may run on large set of RLC PDUs, since a single TB may comprise a high number of RLC PDUs (1 ms TTI with 20Gbps yields around 1666 PDUs of ～1500B) .

In order to reduce the data transmission requirements for ACK/NACK messaging, bitmap compression may be utilised to efficiently signal large ranges of missing PDUs. Allowing optional bitmap compression allows the UE to decide whether to use compressed or uncompressed signalling may be advantageous to allow selection of the most appropriate method in each case depending on the resulting message size or according to configuration information from the network. An indication in the STATUS REPORT message can be used to inform the receiver whether the ACK/NACK bitmap is compressed or not.

As will be apparent from the foregoing disclosure, a T-reordering timer in RLC (both AM and UM) is anticipated to beneficial for implementing the processes described herein.

The T-reordering time allowance maintenance of VR (UR) , which can be used to provide information VR (RL) to the PDCP entity to assist in the reordering processes in the PDCP entity described hereinbefore. Areordering timer in only the PDCP entity would prevent the provision of information to the PDCP entity to assist in reordering, hence creating additional delays. The timer information enables the PDCP entity to know whether to wait for missing PDUs from one of its legs or not. It also allows for different settings of reordering timer per leg (for instance if the HARQ settings are different) . It would be consistent with the fact this t-Reordering is related to HARQ for that specific leg.

Furthermore the timer enables maintenance of a “discard window" . For instance, if an RLC PDU segment is stored but not completed before T-reordering timer expiry, it could be discarded. It would be eventually discarded by the pulling of the window, but this leads to an increase risk to perform erroneous recombination the stored PDU segments with other future transmissions.

The following text describes overall system operation of the PDCP aspects of the above disclosure, and in particular how the PDCP layer can be implemented in NR to avoid reordering delays, ensure lowest possible latency and also ensure easy implementation of OOD bearers.

The following state variables can be defined, assuming that the PDCP SN range is extended to cover HFN, as proposed by some companies (i.e. there is no HFN, COUNT is used as PDCP SN) :

VR (R) –Receive state variable -This state variable holds the value of the SN which indicates the first missing PDU which is still waited for from lower layers (LL) . . It is initially set to 0. It serves as the lower edge of the receiving window.

VR (MR) –Maximum acceptable receive state variable This state variable equals VR (R) + AM_Window_Size, and it holds the value of the SN of the first PDU that is beyond the receiving window. It serves as the higher edge of the receiving window.

VR (X _k) –t-Reordering state variable k -This state variable holds the value of the SN following the SN of the PDCP PDU which triggered t-Reordering. Multiple instances are possible (hence the k index) .

VR (H) –Highest received state variable -This state variable holds the value of the SN following the SN of the PDCP PDU with the highest SN among received PDCP PDUs. It is initially set to 0.

VR (RL _i) –Receive state variable for leg i -This state variable holds the SN corresponding to the latest PDCP PDU no longer considered for reordering for leg i, based on lower layers information. This means PDCP PDUs with earlier SN are no longer expected from leg i. The setting of this variable is not detailed.

If the concept of COUNT is kept (HFN as MSBs, PDCP SN as LSBs) , then a variable RX_HFN is needed (as in legacy LTE) , and it is preferred to consider that the following variables are based on COUNT:

a. VR (X _k) –t-Reordering state variable k -This state variable holds the value of the COUNT following the COUNT value associated with the PDCP PDU which triggered t-Reordering. Multiple instances are possible (hence the k index) .

b. VR (RL _i) –Receive state variable for leg I -This state variable holds the COUNT corresponding to the latest PDCP PDU no longer considered for reordering for leg i, based on lower layers information. This means PDCP PDUs with earlier COUNT are no longer expected from leg i. The setting of this variable is not detailed.

For clarity, it is described assuming no HFN is used, but extension to include HFN is straightforward. If using HFN, a RX_HFN needs to be maintained similarly as for legacy LTE (increased at each rollover of PDCP_SN) , and it is used to derive the full COUNT value, while the state variable above are based on the COUNT value. As discussed above, there exist 2 main types of reordering (or receiving) windows: pull window, whereby new PDUs received out of the window pull the window (the LE of the window is advanced, meaning some old missing PDUs would no longer be waited for) or push window, whereby those PDUs are considered as late PDUs and are discarded. The description below assumes a push window is used, similarly as in legacy PDCP. This means there is a receiving window (with size equal to half the PDCP SN space) defined (and pushed) by its LE. The PDUs received out of this window are considered late PDUs and does no move the window. It would also be possible to use a pull window, the only difference being that the PDUs received out of the window are consider new PDUs, and might also trigger an update of VR (R) (similarly as in RLC UM LTE implementation) . Generally in PDCP, it is preferred to use a push window type to avoid HFN desynchronization issues, which is why this is chosen as the baseline in the description below. The description also assumes that all arithmetic operations are affected by modulus over the SN range. The modulus reference is VR (R) (similar as RLC AM operation described in 36.322 specification) .

○ Initial state is VR (R) = VR (H) = 0.

○ If a new PDU with SN N is received in receiving window:

■ If N already stored (IOD bearer case) or marked as delivered (OOD bearer case)

○ Discard the PDU

■ Else

○ Retrieve the SDU

○ Store the SDU (IOD case) or deliver to UL and mark as delivered (OOD case)

■ If N = VR (R)

○ Update VR (R) to the first missing PDU

■ If VR (H) < N

○ Start a new t-Reordering timer instance i associated to V (X _k) = N

■ Update VR (H)

○ If t-Reordering k expires

■ Update VR (R) to the first missing PDU with SN >= VR (X _k)

○ If one VR (RL _i) is updated, and VR (RL _j) is available for all configured legs j

■ Update VR (R) to min of all VR (RL _j)

○ Whenever VR (R) is updated

■ Deliver the stored PDCP SDUs which falls out of the receiving window to upper layers (IOD bearer case) or discard the delivered stored marking (OOD bearer case)

■ If VR (X _k) <= VR (R) for any k (i.e. PDUs which were waited for are received)

○ The timer k is stopped and reset, and VR (X _k) is discarded

■ If VR (RL _i) <= VR (R) for any leg i (e.g. following t-Reordering expiry)

○ VR (RLi) = VR (R)

The above description has been given with reference to PDCP entities and RLC entities. Such entities are typically computer-implemented devices performing the processing required by the PDCP and RLC layers respectively. The entity may be implemented by software running on a computer system, dedicated software and hardware, or firmware. The terms are therefore intended to refer to functionally defined entities not a specific physical implementation. Such entities may be located at either end of a cellular radio communication link, for example at a UE or an eNB.

The computing system can also include a main memory, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by a processor. Such a main memory also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor. The computing system may likewise include a read only memory (ROM) or other static storage device for storing static information and instructions for a processor.

The computing system may also include an information storage system which may include, for example, a media drive and a removable storage interface. The media drive may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a compact disc (CD) or digital video drive (DVD) read or write drive (R or RW) , or other removable or fixed media drive. Storage media may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive. The storage media may include a computer-readable storage medium having particular computer software or data stored therein.

In alternative embodiments, an information storage system may include other similar components for allowing computer programs or other instructions or data to be loaded into the computing system. Such components may include, for example, a removable storage unit and an interface , such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit to computing system.

The computing system can also include a communications interface. Such a communications interface can be used to allow software and data to be transferred between a computing system and external devices. Examples of communications interfaces can include a modem, a network interface (such as an Ethernet or other NIC card) , a communications port (such as for example, a universal serial bus (USB) port) , a PCMCIA slot and card, etc. Software and data transferred via a communications interface are in the form of signals which can be electronic, electromagnetic, and optical or other signals capable of being received by a communications interface medium.

In this document, the terms ‘computer program product’ , ‘computer-readable medium’ and the like may be used generally to refer to tangible media such as, for example, a memory, storage device, or storage unit. These and other forms of computer-readable media may store one or more instructions for use by the processor comprising the computer system to cause the processor to perform specified operations. Such instructions, generally referred to as ‘computer program code’ (which may be grouped in the form of computer programs or other groupings) , when executed, enable the computing systemto perform functions of embodiments of the present invention. Note that the code may directly cause a processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.

In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into computing system using, for example, removable storage drive. A control module (in this example, software instructions or executable computer program code) , when executed by the processor in the computer system, causes a processor to perform the functions of the invention as described herein.

Furthermore, the inventive concept can be applied to any circuit for performing signal processing functionality within a network element. It is further envisaged that, for example, a semiconductor manufacturer may employ the inventive concept in a design of a stand-alone device, such as a microcontroller of a digital signal processor (DSP) , or application-specific integrated circuit (ASIC) and/or any other sub-system element.

It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to a single processing logic. However, the inventive concept may equally be implemented by way of a plurality of different functional units and processors to provide the signal processing functionality. Thus, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organisation.

Aspects of the invention may be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented, at least partly, as computer software running on one or more data processors and/or digital signal processors or configurable module components such as FPGA devices. Thus, the elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed, the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also, the inclusion of a feature in one category of claims does not imply a limitation to this category, but rather indicates that the feature is equally applicable to other claim categories, as appropriate.

Furthermore, the order of features in the claims does not imply any specific order in which the features must be performed and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order. In addition, singular references do not exclude a plurality. Thus, references to ‘a’ , ‘an’ , ‘first’ , ‘second’ , etc. do not preclude a plurality.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognise that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term ‘comprising’ or “including” does not exclude the presence of other elements.

Claims

A method of processing PDCP PDUs from a radio bearer in a receiver of a cellular communication system, wherein a PDCP entity receives PDCP PDUs from at least one link entity, and wherein the PDCP entity is configured to provide out-of-order delivery of PDCP SDUs to upper layers, the method comprising the steps of

receiving PDCP PDUs at the receiving PDCP entity from at least one linkentity, each PDCP PDU having an associated SN, without guarantee of in-order delivery on each link;

maintaining a reception or reordering window;

transmitting the PDCP SDUs to an upper layer,

storing an indication of SNs of PDCP PDUs from which the PDCP SDU is successfully transmitted to the upper layer;

discarding any subsequently received PDCP PDUs having an SN matching a SN associated with an SDU successfully transmitted to an upper layer.
A method according to claim 1, wherein the radio bearer is a signalling radio bearer.
A method according to claim 1, wherein transmitted PDCP SDUs are not stored at the PDCP entity while waiting for earlier missing PDCP PDUs.
A method according to claim 1, further comprising discarding the stored indication of delivery to the upper layer when the indicated SNs falls out of the reception or reordering window
A method of processing PDCP PDUs from a radio bearer in a receiver of a cellular communication system, wherein a PDCP entity receives PDCP PDUs from at least one link entity, and wherein the PDCP entity is configured to provide in-order-delivery of PDCP SDUs to upper layers, the method comprising the steps of

receiving PDCP PDUs at the receiving PDCP entity from at least one linkentity, each PDCP PDU having an associated SN, without guarantee of in-order delivery on each link;

using the PDCP SN to perform reordering and enabling in-order delivery of PDCP SDUs to upper layers, by storing received PDCP SDUs while waiting for missing PDCP PDUs;

using assistance information from the at least one link entity from which PDCP PDUs were received to derive a PDCP SN or COUNT value indicating whether PDCP PDUs from that link entity with earlier SN or COUNT value are no longer expected from that link entity;

using aggregate assistance information from all the underlying link entities from which the PDCP entity can expect to receive PDCP PDUs to derive whether a given missing PDCP PDU is no longer expected to be received, and performing in-order delivery of PDCP SDUs from PDCP PDUs where all previous PDCP PDUs have been received or are no longer expected.
A method according to claim 5, further comprising using a reordering timer to limit the maximum time to wait for any missing PDCP PDUs.
A method according to claim 5 or 6, wherein the link entity is an RLC AM entity and the assistance information is derived from the AM receive state variable indicating the PDU following the last in-sequence completely received RLC AM data PDU.
A method according to claim 5 or 6, wherein the link entity is an RLC UM entity and the assistance information is derived from the UM receive state variable indicating the earliest RLC UM data PDU that is still considered for reordering.
A method of processing PDUs in a receiver of a cellular communication system, wherein a higher layer entity receives PDUs from at least one lower layer entity, the method comprising the steps of

receiving PDUs at the higher layer entity from a at least one lower layer entity, each PDU having an associated SN, without guarantee of in-order delivery;

maintaining a state variable H corresponding to the highest received PDU in the SN space;

maintaining a state variable R corresponding to the first missing PDU in the SN space which is still waited for from lower layers entities, earlier missing PDUs being considered lost;

starting a separate instance of a re-ordering timer whenever a received PDU SN is not directly following the highest received SN in the SN space, and associating it to the received PDU, such that the corresponding missing PDUs are not waited for more than the duration of the timer before being considered lost;

upon expiry of a re-ordering timer, considering the missing PDUs earlier than the associated PDU in the SN space as lost, and updating the state variable R to the first missing PDU following the associated PDU;

whenever R is updated, stop and discard any instance of a re-ordering timer which was associated to a PDU earlier than R;
A method according to claim 9, wherein a discard window is maintained, corresponding to half of the SN space preceding R, and comprising the additional initial step:

if the PDU falls into the discard window, discarding the PDU and stopping processing related to that PDU.
A method according to claims 9 or 10, wherein the higher layer entity is a PDCP entity, and the PDUs are PDCP PDUs.
A method according to claim 9 or 10, wherein the PDCP entity is configured for in-order delivery to upper layers, and upon update of R, stored SDUs corresponding to SN earlier than R are delivered in-order to upper layers.
A method according to claims 9 or 10, wherein the higher layer entity is an RLC AM entity, the PDUs are RLC PDUs or segments thereof, and upon considering missing PDUs as lost, an ARQ mechanism is triggered to request retransmission of the lost PDUs or segments thereof.
A method according to claim 9 or 10, wherein the higher layer entity is a RLC UM entity configured to allow out-of-order delivery of complete PDCP PDUs to PDCP, the PDUs are RLC PDUsor segments thereof, and upon update of R, stored RLC PDUs segments corresponding to SN earlier than R are discarded.
A method of processing PDCP PDUs in a transmitter of a cellular communication system, the method comprising the steps of

transmitting PDCP PDUs from a PDCP entity to at least one lower layer entity at a transmitter for transmission over at least one wireless link;

wherein the transmission of PDCP PDUs is controlled by a transmit window to limit the number of PDCP PDUs in transmission between the transmitter and a receiver configured to receive those PDUs;

wherein the transmit window is defined to ensure no more than half of the PDCP SN space is in transmission.
A method according to claim 15, wherein the transmit window is defined based on information from the RLC entity of each of the at least one wireless link.
A method according to claim 16, wherein the information from each RLC entity is anAcknowledgement state variableVT (A) value, corresponding to the lower edge of the RLC entitytransmitting window.
A method according claim 15, wherein the transmit window lower edge is updated using PDCP ACK reports from the receiver, indicating the PDCP SN up to which transmitted PDCP PDUs are considered received;
A method according to claim 18, wherein each PDCP ACK report is polled by the transmitter or sent by the receiver based on window occupancy