GB2571260A

GB2571260A - Method and related aspects for buffer management

Info

Publication number: GB2571260A
Application number: GB1802491.9A
Authority: GB
Inventors: Marco Olivier
Original assignee: TCL Communication Ltd
Current assignee: TCL Communication Ltd
Priority date: 2018-02-15
Filing date: 2018-02-15
Publication date: 2019-08-28
Anticipated expiration: 2038-02-15
Also published as: GB2571260B; GB201802491D0

Abstract

A method for managing buffer congestion for a User Equipment accessing services provided by a Radio Access Network (RAN), comprising: receiving data at the (UE from a transmitter; detecting missing data in a data sequence; starting a reordering timer corresponding to the missing data; storing data in a buffer at the user equipment while waiting for the missing data; detecting congestion of the buffer at the UE; performing a buffer flush by passing at least some of the received data stored in the buffer to one or more higher layers of the protocol stack. The data may comprise Packet Data Convergence Protocol (PDCP) Service Data Units (SDUs) utilising a layer 2 buffer. Out-of-order delivery of data to upper layers may be allowed. A further method is disclosed for enabling wireless communication device to access services provided by a RAN, the method for managing buffer congestion comprising: receiving data at a UE from a transmitter; detecting missing data in the data sequence; storing data in a buffer at the UE while waiting for missing data; detecting congestion of the buffer at the UE; and sending a (partial) status report to the transmitter disregarding a running (full) status report prohibit timer.

Description

METHOD AND RELATED ASPECTS FOR BUFFER MANAGEMENT

Technical Field

Embodiments of the present invention generally relate to wireless communication systems and in particular to devices and methods for enabling a wireless communication device, such as a User Equipment (UE) or mobile device to access a Radio Access Technology (RAT) or Radio Access Network (RAN), particularly but nor exclusively relates to buffer management, in particular to a method of buffer management which seeks to avoid Layer 2 (L2) buffer overflow in a protocol stack. In particular, but not exclusively, the method of buffer management can be used in a New Radio (NR) UP protocol stack used for multi-rate dual connectivity.

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. Communication systems 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 more macro-cells 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) systems where one or more cells are supported by a base station known as a gNB.

In cellular systems, such as New Radio (NR), data is transmitted over the air interface trough so-called Radio Bearers (RB). A radio bearer is the service provided by Layer 2 to transport user data packets (Data Radio Bearer) or signalling data packets (Signalling Radio Bearer) between the User Equipment (UE) and the radio access network (NW). The RB service can be configured with specific characteristics depending of the traffic conveyed and the Quality of Service (QoS) desired for that traffic.

In NR and Long Term Evolution (LTE) systems, Layer 2 comprises several sublayers, one of which is the Packet Data Convergence Protocol (PDCP) sublayer. In such systems, several PDCP entities may be defined for each UE, where each PDCP entity is carrying the data of one radio bearer. A radio bearer conveys PDCP Service Data Units (SDUs) from a transmitting PDCP entity to a receiving PDCP entity. Each RB (except for the Signalling Radio Bearer SRBO) is associated with one PDCP entity.

Figure 1 of the accompanying drawings shows schematically an example of a Downlink Layer 2 Structure such as is known in the art from 3GPP TS 38.300v15.0.0. In Figure 1, the Layer 2 NR downlink protocol stack can be seen to comprise Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP) and Service Data Adaption Protocol (SDAP). As shown in Figure 1, in the Downlink Layer 2, the physical layer offers transport channels to the MAC sublayer. The MAC sublayer offers logical channels to the RLC sublayer logical channels. The RLC sublayer offers RLC channels to the PDCP sublayer. The PDCP sublayer offers radio bearers to the SDAP sublayer and the SDAP sublayer offers links to the 5GC QoS flows. Figure 1 does not show control channels such as, for example, BCCH, PCCH for clarity.

A downlink layer 2 structure is shown in Figure 1 of the accompanying drawings for example, a PDCP entity uses services from the underlying RLC entity. The RLC provides transparent mode (TM), unacknowledged mode (UM) and acknowledged mode (AM) data transfer service. For a RB, only RLC UM or RLC AM modes are used. Depending on the required QoS, a RB might be configured using RLC UM (UM bearer) or RLC AM (AM bearer). For a UM RB, packet losses on the air interface might happen. For an AM RB, packet losses on the air interface do not happen as RLC ARQ provides necessary retransmissions. Typically, SRBs (except for SRBO) are configured as AM RBs (as control plane signalling shall not be lost on the air interface), Data Radio Bearers (DRBs) used for real time services (such as voice) are configured as UM RBs (as this kind of service tolerates some packet loss, and is sensitive to latency induced by retransmissions), and DRBs used for data transfer are configured as AM RBs (as retransmission is best performed at lower layers than application layers).

The disclosed technology relates to AM RB for which RLC AM mode is configured. In single connectivity, each PDCP entity is associated with one AM RLC entity. In dual connectivity (DC), a multiple Rx/Tx UE may be configured to utilize radio resources provided by two distinct schedulers in two different nodes (the Master Node and the Secondary Node) connected via a non-ideal backhaul. At least the MN is connected to the Core Network. Each node provides resources within group of serving cells, respectively Master Cell Group (MCG) and Secondary Cell Group (SCG). In DC, a radio bearer might be configured as a MCG, SCG, or split radio bearer. A MCG radio bearer uses RLC/MAC configured in MCG only, a SCG radio bearer uses RLC/MAC configured in SCG only, and a split radio bearer uses RLC/MAC configured in both MCG and SCG. The PDCP entity of a split radio bearer is associated to (at least) 2 RLC AM entities, one associated to the MN and one associated to the SN. Dual connectivity was originally introduced for E-UTRA access (LTE).

As used herein, the term link denotes the RLC link (i.e., the RLC entity, and corresponding logical channel provided by the MAC layer) configured in one node for one radio bearer. A split bearer uses 2 links while a MCG or SCG bearer uses one link.

Multi-RAT Dual Connectivity (MR-DC) is a generalization of the Intra-E-UTRA Dual Connectivity (DC) in which one node is providing E-UTRA access and the other one is providing NR access.

Figure 2 of the accompanying drawings shows schematically an example of the overall ΕΝ-DC Radio Protocol Architecture from 3GPP TS 37.340v15.0.0. In EUTRA-NR Dual Connectivity (ΕΝ-DC), the CN is the EPC, and the UE is connected to one eNB acting as MN and one gNB (en-gNB) acting as SN.

Figure 3A shows schematically Radio Protocol Architecture for MCG, SCG and split bearers from a UE perspective in MR-DC with EPC (ΕΝ-DC) (from 3GPP TS 37.340v15.0.0).

Figure 3B shows schematically network side protocol termination options for MCG, SCG and split bearers in MR-DC with EPC (ΕΝ-DC) (from 3GPP TS 37.340v15.0.0).

NR-NR DC is also defined, as well as variants of ΕΝ-DC when connected to a 5G core network (NE-DC, NG-ENDC). In such scenarios, an Xn interface is used instead of an X2 interface for the interconnection of NG-RAN nodes within the NG-RAN architecture.

For data transfer services, it is generally required to use an AM RB as it is preferred to have the access stratum (AS) Layer 2 handle retransmissions of packet losses on the air interface. Typically, the lower the layer handling the retransmission in a protocol stack, the faster and the more efficient the retransmission. If a UM RB is used, an application level protocol such as TCP would eventually perform the retransmissions, but with lower performance and higher latency. Moreover, protocols like TCP would interpret missing packets as network congestion, and may reduce the transmission rate even when not needed. In addition, it is also generally required to have the AM RB perform in-sequence delivery, as protocols like TCP are also not very tolerant to reordering of packets.

For a non-split AM RB, the unique RLC AM entity ensures retransmissions through ARQ procedures. In LTE protocol stack, RLC AM provides in-sequence delivery of RLC SDUs to PDCP. While waiting for missing RLC AM PDU(s), received RLC AM PDUs not in sequence, or corresponding reassembled RLC SDUs, needs to be buffered in L2 memory. In NR protocol stack, there is no in-sequence delivery between RLC and PDCP; reassembled RLC SDUs are delivered to PDCP as soon as possible in order to ease deciphering of PDCP PDUs. It is up to PDCP to store PDCP SDUs in a reordering buffer while waiting for missing PDCP PDUs (corresponding to missing RLC AM PDUs). Hence, in a NR protocol stack, most of the L2 buffering while waiting for ARQ retransmission is performed in the PDCP reordering buffer.

For a split AM RB, the transmitting PDCP entity routes PDCP PDUs towards either link (RLC entity and MAC sublayer). The RLC AM entity associated to each link ensures retransmissions trough ARQ procedure for that link, and deliver RLC SDUs (PDCP PDUs) to the unique PDCP receive entity. Hence, the PDCP ensures the reordering of PDCP PDUs from both links before in-order delivery to application layer. This is enabled thanks to PDCP Sequence Number (SN) included in the PDCP PDU header. While waiting from missing PDCP PDUs from one link, subsequent PDCP PDUs received (e.g. from the other link) are processed, and the resulting PDCP SDUs are stored in the PDCP reordering buffer. When transmitting data for a AM RB, the Layer 2 also needs to store RLC SDUs (in one or 2 links) until ARQ confirms successful reception by the peer RLC entity. Hence, in order to support AM radio bearers, a significant amount of L2 buffer is needed. This is a dimensioning factor for a UE.

In relation to the L2 buffer at the UE, for an AM non-split radio bearer, one can evaluate the minimum required layer 2 buffer size as:

Minimum L2 Buffer Size = MaxDLDataRate * RTT + MaxULDataRate * RTT, where the RTT (RoundTripTime) corresponds to the time needed to receive retransmissions from ARQ function, DL corresponds to downlink direction, UL corresponds to UL direction.

For an AM split radio bearer, in addition, some data is routed to the Node not hosting PDCP. In the following, the link of the node with PDCP (typically the MN, but can be also the SN in case of SCG split bearer) is denoted as main link (MainLink), and the link of the node without PDCP (typically the SN, but can be also the MN in case of SCG split bearer) is denoted as alternative link (AltLink). This yields an additional delay corresponding to the Xn interface between both nodes as well as a queuing delay in that Node. Hence, the minimum layer 2 buffer size can be evaluated as:

Minimum L2 Buffer Size = MaxULDataRate * RTT + MaxDLDataRate_AltLink * RTT_AltLink + MaxDLDataRate_MainLink * (RTT_MainLink + Xn delay + Queuing in AltLink Node)

Usually, the UE is required to have at least the amount of minimum L2 buffer size needed to maintain its peak UL and DL data rate with a given RTT (corresponding to its category and configuration). There is no per RB or per direction L2 memory requirement, as is it more efficient to use L2 memory in a dynamic way depending of the need.

The UE may encounter a L2 buffer overflow (buffer full) issue, e.g. if some data are missing and waiting for, while subsequent data fill up the L2 memory (in DL). To some extent, the NW can avoid L2 buffer overflow by performing flow control thanks to RLC receiver feedback from one or both link(s). At any given time, the NW can know the amount of outstanding PDCP PDUs sent to the UE. For the link not hosting PDCP, a tight flow control over the X2/Xn interface is used for this purpose. This is needed to avoid the PDCP transmitter to send more outstanding PDCP PDUs than half of the PDCP SN space, as this could lead to a hyper frame number (HFN) desynchronization issue at the receiver, and consequently deciphering failure. But this can also be used by the transmitter to further limit the amount of DL data that may need to be stored in the UE L2 memory. The NW may also use the BSR information to know the amount of new UL data stored in UE L2 memory, as well as RLC receiver information at NW node side to evaluate the data stored for retransmission in the UE L2 memory.

However, it is difficult to ensure that L2 buffer overflow would never occur. This would require the network (NW) to take extra margin while scheduling. For instance, the network may have to assume that a packet would need the maximum ARQ retransmissions number to be successfully transmitted, whereas it usually needs no ARQ retransmission at all. Also, the RLC status report (SR) may be lost or delayed. This could be accounted for by the NW, but this generally does not happen. By taking such extra margin, L2 overflow might not occur, but it would result in L2 memory being underutilized, and throughput unnecessarily limited. Moreover, the L2 memory is shared for all RBs. In case of a multi-bearer scenario, data arrival from a high priority channel may cause buffer congestion since it would have priority over the data to be retransmitted on lower priority channel. As it can be seen, it is difficult and not necessarily desirable for the NW to guarantee at 100% that L2 buffer overflow will never occur at UE side.

In RAN2 NR AH#1801, it was highlighted that the L2 buffer overflow issue might be worse in the case or MR-DC.

In MR-DC scenarios, particularly ΕΝ-DC scenarios, both links are unbalanced (NR leg might reach a largely higher throughput with a largely lower latency than LTE link). If a AM split bearer is used, and some packets need retransmissions on the slow LTE link (HARQ/ARQ), the NR link might continue transferring data at high speed, filling quickly the L2 buffer memory (PDCP SDUs will be stored in the PDCP reordering buffer while waiting for missing PDUs from the slow LTE link). In such scenario, a single missing PDCP PDU expected from the LTE link can cause a buffer build-up up to RTTworstcase_LTEIink * MaxDLDataRateNR throughput. However, the L2 buffer size is expected to be dimensioned mainly using RTT_NRIink * MaxDLDataRateNR. As RTT of NR link is expected to be largely smaller than the RTT of the LTE link, it would be a waste to dimension the L2 buffer for that scenario. Hence, this kind of scenario may lead to L2 buffer overflow.

The potential L2 buffer overflow issue is not new, for example, for LTE, in 36.300v15.0.0, the following is captured: “NOTE 1: The eNB may not be able to guarantee that a L2 buffer overflow will never occur. If such overflow occurs, UE may discard packets in the L2 buffer.” Generally, in LTE, it is expected that the eNB can avoid sending too much outstanding data to avoid the issue. Hence no specific behaviour is defined. The above NOTE allows the UE to discard packets in L2 buffer if required but which packet(s) can be discarded in the L2 buffer is not indicated.

In UTRA, in 25.322v14.0.0, section 11.3.4.9. Full Buffer Behaviour discloses that in some conditions, e.g. when the window size is re-configured, the UE may have memory limitations.

While the buffer memory is full:

the UE is not required to segment RLC SDUs into AMD PDUs as per Subclause 11.3.2;

- the UE shall:

be able to process incoming AMD PDUs (especially to be able to process and store the AMD PDU with Sequence Number = VR(R));

operate according to the normal protocol, e.g. process STATUS reports and perform retransmissions;

the UE may discard received AMD PDUs with Sequence Number within the receiving window and consider the discarded AMD PDUs as not having been received.

It is specified that the UE may discard received RLC AM PDUs in order be able to process the ones which are waited for, and while doing so, act as if such RLC AM PDUs were never received. Obviously, this wastes radio resources as a successfully transmitted data is discarded at the receiver and will have to be retransmitted.

The problem of avoiding L2 buffer overflow, has been discussed in various standards forms in the past. For example, additional flow control was discussed in the past for

LTE, where for instance, it was proposed to send a quick indication at MAC when a congestion is detected. Additional flow control was also introduced for LWA at

PDCP using PDCP status report. Although such a mechanism could be reused in the present context, it relies on polling only, and hence would add a large signalling overhead as the NW would need to poll frequently to detect any UE L2 memory congestion in time.

The present invention is seeking to solve at least some of the outstanding problems in this domain.

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.

According to a first aspect of the present invention there is provided a method for enabling a wireless communication device to access services provided by a Radio Access Network, the method for managing buffer congestion, the method comprising: receiving data at a user equipment from a transmitter; detecting missing data in a data sequence; starting a reordering timer corresponding to the missing data; storing data in a buffer at the user equipment while waiting for the missing data; detecting congestion of the buffer at the user equipment; performing a buffer flush by passing at least some of the received data stored in the buffer to one or more higher layers of the protocol stack.

Preferably, the received data comprises Packet Data Convergence Protocol service data units.

Preferably, the buffer flush is performed by: setting a reordering timer corresponding to the missing data to an expired status; performing the actions specified upon reordering timer expiry.

Preferably, the buffer flush is performed by: setting the reordering timer corresponding to the missing data to an expired status; performing the actions specified upon reordering timer expiry; considering the reordering timer is configured to 0 while buffer congestion is detected by the UE.

Preferably, the buffer flush is performed by: considering the corresponding Data

Radio Bearer is configured so that the out-of-order delivery to upper layers is allowed.

Preferably, the buffer is a Layer-2 buffer.

Preferably, when the buffer flush is performed: a notification is sent to the Radio Access Network.

Preferably, the notification is a PDCP status report.

According to another aspect of the present invention there is provided a method for enabling a wireless communication device to access services provided by a Radio Access Network, the method for managing buffer congestion, the method comprising: receiving data at a user equipment from a transmitter; detecting missing data in the data sequence; storing data in a buffer at the user equipment while waiting for missing data; detecting congestion of the buffer at the user equipment; sending a status report to the transmitter disregarding a running status report prohibit timer.

Preferably, the Radio Access Network is a New Radio/5G network.

According to a second aspect of the present invention there is provided a base station.

According to a second aspect of the present invention there is provided a nontransitory computer readable medium having computer readable instructions stored thereon for execution by a processor to perform the method of another aspect of the present invention.

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.

FIG. 1 shows schematically an example of a Downlink Layer 2 Structure (from 3GPPTS 38.300v15.0.0);

FIG. 2 shows schematically an example of an ΕΝ-DC Overall Architecture (from 3GPP TS 37.340v15.0.0)

FIG. 3A shows schematically an example of a Radio Protocol Architecture for MCG, SCG and split bearers from a UE perspective in MR-DC with EPC (EN-DC) (from 3GPP TS 37.340v15.0.0);

FIG. 3B shows schematically an example of a Network side protocol termination options for MCG, SCG and split bearers in MR-DC with EPC (EN-DC) (from 3GPP TS 37.340v15.0.0);

FIG. 4A shows schematically an example of DL PDCP reordering;

FIG. 4B shows schematically an example of an issue with DL PDCP reordering;

FIG 5A shows a sequence diagram for configuring a SR prohibit timer as is known in the art for when a UE sends a RLC status report upon missing a PDU detection trigger;

FIG 5B shows a sequence diagram for when a UE sends a RLC status report upon missing a PDU detection trigger without a SR prohibit timer being configured (or equivalently being configured as 0) as is also known in the art;

FIG. 6A shows schematically how an RLC status report (SR) which signals Gap1, Gap2, and ACK_SN is interpreted according to the prior art;

FIG. 6B shows schematically how a partial RLC status report (SR) which signals Gap1, Gap2, and ACK_SN is interpreted according to an embodiment of the disclosed technology;

FIG. 6C shows schematically how a partial RLC status report (SR) which signals Gap2, and ACK_SN is interpreted according to an embodiment of the disclosed technology; and

FIG. 7 shows a sequence diagram for an RLC Status Report transmission is handled according to an embodiment of the disclosed technology.

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.

Some examples of embodiments of the disclosed technology seek to provide a way of preventing or avoiding fast buffer overflow. Some embodiments of the disclosed technology seek to avoid for example L2 buffer overflow and associated packet drop/discard by allowing part of L2 buffer to be flushed to buffer(s) in higher layers of the protocol stack once L2 buffer congestion is detected. Some examples of embodiments of the disclosed technology additionally propose a way to limit L2 buffer congestion occurrence by enhancing the ARQ protocol.

Some example embodiments of the disclosed technology enable L2 buffer memory to be freed soon as it is needed, for example when no longer able to accommodate new packets, whilst enabling the buffer to be used up to the maximum possible value (so that no L2 buffer memory is wasted). This solution accordingly differs from solutions known in the art which expect one or more of the following: the missing packets to eventually be received (e.g. following HARQ or ARQ retransmissions), or for a timer to expire (e.g. a reordering timer, or a retransmission timer), or for an indication to be sent to the transmitter (e.g. a flow control indication), all of which will incur some delay before being taken into account.

Some example embodiments of the disclosed technology avoid any waste of Uu resource. There is no discard/dropping of packets successfully received on Uu interface. New packets which made it to the UE don’t end being discarded in the UE protocol stack.

Some example embodiments of the disclosed technology may result in limited latency (compared to waiting for missing packets, which incurs additional delay in delivering packets). Some example embodiments of the disclosed technology may leverage end-to-end flow control (e.g. from TCP) as introducing packet loss will trigger TCP congestion avoidance (which would reduce the TCP transmission window). This does not necessarily mean that the TCP throughput will be impacted. This may be also triggered by late out-of-order packets, depending of the scenarios.

The example embodiments of the buffer management scheme disclosed herein have limited specification impact, very limited or no signalling overhead (the signalling overhead is present only if an indication is sent) and limited or no packet loss. There is no packet loss in the alternative where late out of order packets are delivered. In the alternative where missing packets are no longer waited for, packet loss is limited. For example, as described in one example embodiment loss may be limited to just one packet. In contrast, in the prior art, if packets are dropped from the PDCP reordering buffer, dataRate*congestionDuration bytes will be lost.

Example embodiments of the disclosed technology may result in there being no HFN desynchronization risk.

The LTE specification, which is the baseline for NR indicates in a NOTE “UE may discard packets in the L2 buffer”. This NOTE dates from Rel-8. At that time, most L2 buffering in DL is in RLC as reordering is in RLC. However, with dual connectivity introduced in Rel-12, part of L2 buffering is in PDCP (PDCP SDUs stored in PDCP reordering buffer), without the NOTE being updated. Such NOTE could allow, for instance, dropping (discarding) already stored RLC PDUs/SDUs whereas a RLC STATUS REPORT acknowledging the reception of these packets (for instance, discarding packets from the PDCP reordering buffer). This can lead to HFN desynchronization issue as soon as more than half of the PDCP SN space are discarded. Indeed the PDCP transmitter, relying on RLC status report, would falsely assume correct delivery of PDCP PDUs to receiving PDCP entity, and will no longer be able to ensure that less than half of the PDCP SN space are outstanding.

One known solution to avoid buffer overflow is flow control, e.g. sending an indication to the NW when approaching L2 buffer congestion. However, the AM bearer is supposed to be lossless. If the lossless delivery property is preserved in the context of the disclosed technology, a huge amount of radio resource would be wasted. Indeed this would result for instance in discarding all correctly received NR RLC PDUs while waiting for missing LTE RLC PDUs. Such discarded PDUs will have to be retransmitted, wasting radio resource. This also leads to increased latency.

The embodiments of the disclosed technology in contrast allow lossy behaviour which enables a TCP congestion avoidance mechanism to be triggered. This also helps resolve the congestion in the UE L2 buffer.

The preferred features may be combined as appropriate, as would be apparent to a skilled person, and may be combined with any of the aspects of the invention.

One example embodiment of the disclosed technology relates to NR DL PDCP reordering in which the NR PDCP receive operation uses a PUSH based reordering window.

Conventionally, the reordering window lower edge “RX_DELIV” is pushed by arrival of PDCP PDU with COUNT = RX_DELIV, or by expiry of the reordering timer. The reordering timer is started whenever it was not already running and a gap is created in the received COUNT sequence. Figure 4A of the accompanying drawings shows an example of such a downlink PDCP reordering window. As shown in Figure 4A, PDCP SDUs which were provided (delivered) to upper layers are shown on the left of the reordering window, and stored PDCP SDUs are shown on the right.

For a LTE link, LTE RLC delivers in-order PDCP PDUs to the receiving PDCP entity. For a NR link, however, RLC delivers complete RLC SDUs (PDCP PDUs) to PDCP as soon as they are received, i.e. contrary to LTE, there is no in-order-delivery from RLC to PDCP. Hence for NR, the (NR) PDCP ensures in-order-delivery function to application layer (when required). The PDCP reordering buffer is used both to handle out-of-order arrival of PDCP PDUs due to HARQ on a NR link, and due to multiple links in DC configurations. In ΕΝ-DC, NR PDCP is used (PDCP protocol specified for NR in 3GPP TS 38.323). When used in this description, PDCP is not limited to LTE PDCP protocol but also encompasses NR PDCP protocol.

As described earlier, MR-DC, and ΕΝ-DC in particular, creates certain issues. As a particular example (which could be seen as a worst case example), a single missing SDU from the LTE link could induce a quick buffer filling from NR link, as is shown schematically in Figure 4B.

In Figure 4B, the PDCP SDUs provided (delivered) to upper layers are shown on the left hand side before the start of the reordering window and stored PDCP SDUs are shown on the right. As shown in Figure 4B, the reordering window begins when there is a missing SDU from the LTE link, and results in layer 2 buffer congestion by SDUs from the NR.

Some example embodiments of a buffer management scheme providing a L2 Buffer flush to manage buffer overflow will now be described.

One embodiment of the disclosed technology proposes that a UE is allowed to perform a L2 buffer flush to upper layers, when L2 buffer congestion is detected, by considering that the reordering timer has expired (and by performing actions specified for reordering timer expiry). Since the reordering timer was considered as expired, the missing PDUs from the first gap (corresponding to RX_DELIV) will no longer be waited for. In the worst case example described above, this would lead to the whole reordering buffer being flushed to upper layers, hence freeing up all the corresponding L2 memory and resolving the L2 buffer congestion, and the missing SDU from LTE link will be lost.

L2 buffer congestion detection is described later. It is understood that L2 buffer congestion may last till enough L2 memory is freed, i.e. as long as there is L2 buffer congestion, L2 buffer congestion is considered detected, and any reordering timer started will be considered expired.

Equivalently, when (i.e. while) L2 buffer congestion is detected, the UE may consider that the reordering timer is configured to 0, and that running reordering timer (if any) is considered expired.

When performing such flush, since PDCP does not wait for reordering timer expiry, it is possible (and expected) that the missing (no longer waited for) SDU(s) would be eventually received. They will be discarded by the PDCP receiver, without additional change needed in PDCP receive operation. A PDCP feedback (e.g. PDCP status report) can enable the transmitter to optimize and discard/cancel the transmission of PDCP PDUs which are no longer waited for, however this is not required for correct protocol operation. The simplest implementation is to just let the link layers complete the transmission.

There is no risk of hyper frame number (HFN) desynchronization as long as the PDCP transmitter ensures that at any given time, the outstanding PDCP PDUs correspond to less than half the PDCP SN space, which is already a requirement for PDCP transmitter. It is expected that in 5G systems the base station (e.g., the gNB or eNB) will ensure most of the time that no L2 buffer congestion occurs. Indeed the gNB (or eNB) knows from RLC feedback and X2 or Xn tight flow control the amount of outstanding PDCP PDUs. Hence L2 buffer congestion should be rare and might not require an additional UE based flow control.

In practice, this leads to allowing packet loss on an AM bearer (conditionally to L2 buffer congestion being detected). This might not be always preferred; hence, it is proposed that the NW can configure for each radio bearer whether buffer flush is allowed. For instance, it could be preferable to forbid buffer flush on SRBs, as packet loss on a SRB might cause protocol issues. This might also be specified directly in the specification.

It should be noted though, that even an AM bearer can already encounter packet loss. This can be due to the expiry of PDCP reordering timer. This might be avoided by setting the reordering timer to infinite, but this prevents PDCP PDU discard at NW side, which can be a problem in DC configurations. This can be also due to Active Queue Management (AQM) at PDCP transmitter side (for instance, PDCP discard timer), which is necessary since L2 buffer memory is also limited on gNB (or eNB) side, and to prevent known issues such as buffer bloat.

Accordingly, allowing packet loss on an AM bearer in extreme cases is acceptable.

If packet drop (discard) solution is allowed, for instance as loosely defined in LTE 3GPP TS 36.300 specification, it is proposed to specify that this should be done by allowing discarding of RLC PDUs (and still indicating them as NACK), to preserve the lossless property of the bearer. If packet drop solution allows dropping PDCP SDUs from reordering buffer, there is no gain compared to the proposed buffer flush solution, since it introduces packet loss, but only drawbacks, as the discarded packets would anyway not be retransmitted by underlying links. If packet drop solution allows dropping PDCP PDUs I RLC SDUs while the corresponding RLC PDUs where already indicated as ACK, or dropping RLC PDUs which were already indicated as ACK, there is a risk of HFN desynchronization as described earlier.

Hence for each radio bearer, the NW could configure either:

- lossless buffer congestion handling (allowing discarding incoming RLC PDUs when it doesn’t correspond to the waited one).

- fast buffer overflow avoidance (not allowing discarding incoming RLC PDUs when it doesn’t correspond to the waited one I allowing considering reordering timer has expired for missing PDCP SDUs).

This can be part of PDCP configuration. It is understood that such behaviour would be allowed only when L2 buffer congestion is detected, which can be further specified, as described below.

For SRB, it might be preferred to mandate a lossless buffer congestion handling.

Some examples of buffer congestion detection will now be described in the context of the disclosed technology. In order to avoid bad UE implementations and misuse of the feature, it might be needed to specify when a UE is allowed to consider that its L2 buffer is congested (and allowed to consider that the reordering timer has expired to free-up some space).

It is proposed that the UE considers L2 buffer is congested when the occupied L2 memory, compared to declared sized in capability, is above a given threshold (e.g., 90%). Equivalently, the UE might considers L2 buffer is congested when the free L2 memory, compared to declared sized in capability, is less than a given threshold (e.g., 10%). This threshold might be configured as part of the configuration of “fast buffer overflow avoidance” for the radio bearer.

When considering re-ordering timer expired, a notification can be sent to the NW. For instance, to limit specification and implementation impact, the PDCP status report can be reused, with a bit indicating that a buffer flush occurred. Equivalently, a new control PDU could be defined, for instance reusing the PDCP status report format. Alternatively, a plain (unsolicited) PDCP status report could be sent. This would indicate to the NW that the UE encounters L2 buffer congestion, and can be used by the NW to take necessary actions (e.g. release the LTE link, adapt the scheduling to limit the outstanding PDCP PDUs,...). It can also enable the optimization to cancel the transmission of PDCP PDUs which are no longer waited for. Sending of such notification can be configured as part of PDCP configuration, as sending such indication can also add some signalling overhead.

In some examples of embodiments of the disclosed technology, NR-PDCP is used to configure out-of-order delivery for a DRB. When out-of-order delivery is configured, PDCP SDUs which would have remained stored in the PDCP reordering buffer are delivered to upper layers without waiting for the missing PDCP SDUs. The reordering timer is still configured and used to update the reordering window, and to decide when to stop waiting for missing PDCP PDUs.

Usually, radio bearers used for data transfer (often using TCP) are not configured with out-of-order delivery to upper layers, since TCP behaviour can be impacted by receiving out-of-order packets (possible throughput loss). This gives an alternative way to handle L2 buffer congestion in some embodiments, where when an L2 buffer congestion is detected, the UE is allowed to consider that the DRB allows out-oforder delivery to upper layers.

In such embodiments, the missing PDUs from the first gap (corresponding to RX_DELIV) will still be waited for during the duration of the reordering timer, but the stored PDCP SDUs will be delivered to upper layers, freeing the L2 memory.

In the worst case example described above, this would lead to the whole reordering buffer being flushed to upper layers, hence freeing up all the corresponding L2 memory and resolving the L2 buffer congestion, and the missing SDU from LTE link will be lost only if it is received after expiry of the reordering timer. Hence, compared to previous embodiment, this gives an opportunity to keep a lossless behaviour, to the expense of the delivery of late out-of-order packet(s).

When delivering late out-of-order packet(s) to upper layers, a notification can be sent to the NW. For instance, the PDCP status report can be reused, with a bit indicating that a buffer flush (of late out-of-order packets) occurred. Equivalently, a new control PDU could be defined, for instance reusing the PDCP status report format. Alternatively, a plain (unsolicited) PDCP status report could be sent. This would indicate to the NW that the UE encounters L2 buffer congestion, and can be used by the NW to take necessary actions (e.g. release the LTE link, adapt the scheduling to limit the outstanding PDCP PDUs,...). It can also enable the optimization to speed up the retransmission of PDCP PDUs which are waited for, for instance by triggering a retransmission of the PDCP PDU(s) on a different link. Sending of such notification can be configured as part of PDCP configuration, as sending such indication can also add some signalling overhead.

In another embodiment, a notification of L2 buffer congestion can be sent by PDCP as soon as a L2 buffer congestion is detected. In order to avoid too much signalling overhead, a prohibit timer can be used (started as soon as the indication is sent, and preventing sending again an indication while it is running). As for the notification of L2 buffer congestion, to limit specification and implementation impact, the PDCP status report can be reused, with a bit indicating that UE encounters L2 buffer congestion. Equivalently, a new control PDU could be defined, for instance reusing the PDCP status report format. Alternatively, a plain (unsolicited) PDCP status report could be sent. This would indicate to the NW that the UE encounters L2 buffer congestion, and can be used by the NW to take necessary actions (e.g. release the LTE link, adapt the scheduling to limit the outstanding PDCP PDUs,...). It can also enable the optimization to speed up the retransmission of PDCP PDUs which are waited for, for instance by triggering a retransmission of the PDCP PDU(s) on a different link.. Sending of such notification, along with the prohibit timer, can be configured as part of PDCP configuration, as sending such indication can also add some signalling overhead.

As described herein above, the L2 buffer overflow in the UE is mainly avoided by flow control from the NW using RLC feedback (i.e., STATUS REPORT messages which indicate reception status of RLC PDUs). This is applicable both for a NR link, a LTE link or both NR and LTE links in MR-DC configurations such as EN-DC.

In LTE and NR, a RLC status report may be triggered by missing PDU detection or by polling. When a STATUS REPORT is received by the transmitting RLC entity, the transmitting RLC entity prioritizes retransmissions (if any) over new transmissions. Missing PDU detection means a hole or gap is detected in the RLC PDU sequence and this detection is triggered upon expiry of a reordering (also called reassembly) timer corresponding to the maximum hybrid automatic repeat request (HARQ) delay, which is needed to be sure that the hole will not be filled by HARQ retransmission before requesting an ARQ retransmission (i.e. to be sure that an HARQ failure took place). Polling is indicated by a bit in the RLC PDU header. The RLC transmitter set the polling bit according to various triggers. Some triggers are particular events such as empty buffer (last PDU being sent) I stall window. Others are “periodic” triggers such as polling every X bytes transmitted or every Y PDUs sent. The “periodic” triggers can for instance be configured to ensure that only a given maximum amount of bytes will be outstanding before a SR is sent and retransmission are triggered, in order to limit the needed L2 buffer size (both at the transmitter side and the received side).

On the RLC receiver entity side, a RLC status reporting prohibit timer can be configured to limit the sending of RLC status report. The main goal of this timer is to ensure that the RLC receiver does not send a new SR without having let the opportunity to the RLC transmitter to perform retransmission from a previous SR.

This is important to avoid sending useless retransmissions several times.

Currently, RLC status reporting as is known in the art is mainly delayed by the prohibit timer. For LTE, the delay in producing the status report is typically configured to around ~40ms. If a missed PDU is detected just after having sent a SR, it will be reported only 40ms later.

The use of a prohibit timer avoids there being too much overhead (both for SR signalling and RLC PDU retransmissions) and accordingly the prohibit timer generally should be kept. Some example embodiments of the disclosed technology accordingly propose:

1) the UE is allowed to send RLC status report upon missing PDU detection trigger, even while the SR prohibit timer was already running. This can be conditional to L2 buffer congestion detection

2) to avoid overhead (both for SR signalling and RLC PDU retransmissions), a partial RLC status report is introduced. The partial RLC status report is only sent at missing PDU detection and only indicates the detection of new gap(s) in RLC SN sequence. It avoids e.g. to repeat previously sent (and possibly not yet handled by the gNB) status information. Upon polling a full RLC status report is sent.

3) in case a SR indicates a NACK status for RLC PDUs previously indicated as ACK, the corresponding RLC PDUS are not be considered for retransmission.

Some example embodiments of a method of buffer management according to the invention, accordingly allow UE to send RLC status report upon missing PDU detection trigger, even when the SR prohibit timer is already running.

In case of HARQ failure, RLC PDUs are dropped. A gap happens in the received RLC SDU sequence. The gap typically corresponds to contiguous RLC SDU and/or RLC SDU segments.

The gap is detected by the RLC receiver by a RLC PDU detection loss function, which uses a reordering timer to wait for possible HARQ retransmission before considering a RLC PDU lost.

In order to limit additional buffering in the UE, once a gap has been detected, it is important to signal this gap as soon as possible to the RLC transmitter.

In the prior art, sending of SR is further limited by a SR prohibit timer. As discussed, the notification of a gap detection can be delayed. This is illustrated in Figure 5A.

Hence, in order to ensure that the SR is sent a soon as possible, the SR prohibit timer has to be not configured (or equivalently configured to 0). Figure 5B of the accompanying drawings, shows an example of the situation with no prohibit timer (or equivalently configured to 0). This may lead to some issues, detailed below:

- additional overhead in control signalling, as additional SR reports are sent, and the SR reports all RLC SDU or segments thereof which are considered ACK or NACK till a given SN (ACK_SN);

- additional retransmission overhead, as the RLC receiver may report NACK for the same RLC SDU and/or RLC SDU segments without having waited retransmission from the RLC transmitter; and/or

- sending of back to back SRs means the SRs might be received out-of-order due to HARQ

In some examples of embodiments of the disclosed technology, the drawbacks of configuring SR prohibit timer to 0, are limited by:

1) the UE being allowed to send RLC status report upon missing PDU detection trigger (even if the prohibit timer is running), which in some embodiments, can be conditional to L2 buffer congestion detection. The prohibit timer is restarted when sending the SR, as in prior art behaviour; however, the other SR trigger (poll) would still be constrained to wait for SR prohibit timer expiry, to limit overhead. Equivalently, the prohibit timer can be considered as expired upon missing PDU detection trigger.

2) A partial RLC status report is introduced. This can be contrasted with the prior art in which a prohibit timer is used to ensure that the RLC receiver does not send a new SR before having let enough time for the RLC transmitter to perform retransmissions. In the prior art, the SR reports RLC SDU or segments thereof which are considered ACK or NACK until a given SN (ACK_SN), i.e., the SR always gives a full picture of RLC PDUs ACK / NACK status at the RLC receiver until a given SN (ACK_SN), and accordingly, could be qualified as a “full” SR. As can be seen in Figure 5B, sending a SR upon detection of gap 2 leads to report gap 1 a second time. The RLC transmitter will reschedule retransmissions for gap 1 as it doesn’t know whether the initial retransmissions were received or not.

The partial RLC SR provided by some embodiments of the disclosed technology may prevent this situation from occurring. The partial RLC status report is only sent at missing PDU detection and only indicates the detection of new gap(s) (RLC SDUs or segments thereof) in RLC SDU sequence. It avoids e.g. to repeat previously sent (and possibly not yet handled by the gNB) status information. Upon polling a full RLC status report is sent, as it is still required for the RLC transmitter to get the “full picture” of RLC PDUs ACK I NACK status at the RLC receiver, given for instance that partial SR might be lost on the air interface.

The partial RLC SR according to some embodiments uses the same format as the “full” existing RLC SR. In some embodiments of the disclosed technology, a different Control PDU Type is used to indicate “PARTIAL STATUS PDU” instead of “STATUS PDU”. In a partial SR, according to some embodiments of the disclosed technology, gaps (NACK SNs or ranges) and ACK_SN field are provided similarly to the existing “full” SR.

The existing “full” SR consists in a ACK_SN field, and other fields describing gaps (NACK SNs or ranges). The gaps can be of RLC PDUs I RLC SDU or segments thereof, hence the generic term “gap” is used to describe the signalling. It gives full ACK/NACK report of RLC SDU/segments thereof before ACK_SN.

Figure 6A of the company drawings, shows how a full status report which indicates first and second gaps (gap1 and gap2) and an ACK_SN is interpreted by the RLC entity receiving the SR. The “full” SR indicating Gap1, Gap2 and ACK_SN gives the interpretation shown in Figure 6A. All RLC PDUs/RLC SDUs or segment thereof, which do not fall into the signalled gaps (gap1 and gap2), and with a SN lower than ACK_SN, are interpreted as being ACKed by the RLC receiver (i.e. successfully received).

The partial SR generated using a method of buffer management according to some example embodiments of the disclosed technology uses a similar ACK_SN and gap(s) fields, but the interpretation is different. Assuming as an example, a partial SR indicating Gap1, Gap2 and ACK_SN again, according to the example embodiments, the interpretation would be as is shown in Figure 6B. All RLC PDUs/RLC SDUs or segment thereof, which do not fall into the signalled gaps (gap1 and gap2), and with a SN lower than ACK_SN, with the exception of all RLC PDUs/RLC SDUs or segment thereof earlier than the first signalled gap, are interpreted as being ACKed by the RLC receiver (i.e. successfully received). The partial SR does not give any information on RLC PDUs/RLC SDUs or segment thereof earlier than the first signalled gap.

The partial SR would enable to signal new gap(s), e.g. gap 2 only, even in the presence of previous gap, such as gap1, which would have been reported previously. It would not imply that gap 1 was successfully filled. This is illustrated schematically in Figure 6C, which shows the interpretation of “partial” SR with Gap2, ACK_SN.

In the example embodiments where a partial SR is provided, such as, for example, was illustrated in Figure 6C, the overhead in SR is eliminated and the risk of useless retransmission also removed.

Figure 7 of the accompanying drawings, is a sequence diagram showing how a partial status report (SR) according to some example embodiments of the disclosed technology impacts the sequence flow between a RLC transmitter and an RLC receiver.

In some example embodiments of the disclosed technology, as the RLC transmitter needs to have also the full picture of ACK/NACK at the UE, the existing “full” report is still used at polling. Accordingly the SR prohibit timer can be used for this “full” report. However, the SR prohibit timer may not be restarted on a partial report, as this could lead to a deadlock where a full SR is never sent.

In some example embodiments of the disclosed technology, when receiving a SR, in case a SR indicates a NACK status for RLC PDUs previously indicated as ACK, the corresponding RLC PDUS may not be considered for retransmission. This is to take into account the possible reordering due to HARQ, and avoid retransmission overhead. An earlier SR might be received last by the RLC transmitter, due to HARQ. Hence, RLC PDUs might be indicated as NACK whereas they were indicated ACK just before.

Although not shown in detail any of the devices or apparatus that form part of the network may include at least a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method of any aspect of the present invention. Further options and choices are described below.

The signal processing functionality of the embodiments of the invention especially the gNB and the UE may be achieved using computing systems or architectures known 22 to those who are skilled in the relevant art. Computing systems such as, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, etc.), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment can be used. The computing system can include one or more processors which can be implemented using a general or special-purpose processing engine such as, for example, a microprocessor, microcontroller or other control module.

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 system to 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.

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

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’, 10 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 15 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

1. A method for enabling a wireless communication device to access services provided by a Radio Access Network, the method for managing buffer congestion, the method comprising:

receiving data at a user equipment from a transmitter;

detecting missing data in a data sequence;

starting a reordering timer corresponding to the missing data;

storing data in a buffer at the user equipment while waiting for the missing data;

detecting congestion of the buffer at the user equipment;

performing a buffer flush by passing at least some of the received data stored in the buffer to one or more higher layers of the protocol stack.

2. The method of claim 1, wherein the received data comprises Packet Data Convergence Protocol service data units.

3. The method as claimed in any preceding claim, wherein the buffer flush is performed by:

a. setting a reordering timer corresponding to the missing data to an expired status;

b. performing the actions specified upon reordering timer expiry.

4. The method of claims 1 or 2, wherein the buffer flush is performed by:

a. setting the reordering timer corresponding to the missing data to an expired status;

b. performing the actions specified upon reordering timer expiry;

c. considering the reordering timer is configured to 0 while buffer congestion is detected by the UE.

5. The method of claims 1 or 2, wherein the buffer flush is performed by:

a. considering the corresponding Data Radio Bearer is configured so that the out-of-order delivery to upper layers is allowed.

6. The method of any preceding claims, wherein the buffer is a Layer-2 buffer.

7. The method of any preceding claims, wherein when the buffer flush is performed:

a. a notification is sent to the Radio Access Network.

8. The method of preceding claim, wherein the notification is a PDCP status report.

9. A method for enabling a wireless communication device to access services provided by a Radio Access Network, the method for managing buffer congestion, the method comprising:

receiving data at a user equipment from a transmitter;

detecting missing data in the data sequence;

storing data in a buffer at the user equipment while waiting for missing data;

detecting congestion of the buffer at the user equipment;

sending a status report to the transmitter disregarding a running status report prohibit timer.

10. The method of claim 9, wherein the received data comprises Radio Link Control protocol data units.

11. The method of claim 9 or claim 10, wherein while buffer congestion is detected at the user equipment, the status report prohibit timer prevents sending status report upon polling but does not prevent sending status report upon missing data detection.

12. The method of any one of the preceding claim wherein the Radio Access Network is a New Radio/5G network.

13. A user equipment, UE, apparatus comprising a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method as claimed in any one of claims 1 -12.

14. A base station, BS, apparatus comprising a processor, a storage unit and a communications interface, wherein the processor unit, storage unit, and communications interface are configured to perform the method as claimed in any one of claims 1 -12.

15. A non-transitory computer readable medium having computer readable instructions stored thereon for execution by a processor to perform the 5 method according to any of claims 1 -12.