WO2016180915A1

WO2016180915A1 - Method, system and device for providing flow control in a split bearer environment

Info

Publication number: WO2016180915A1
Application number: PCT/EP2016/060643
Authority: WO
Inventors: Torsten DUDDA; Reem KARAKI; Alexander Vesely; Hanzhi ZHANG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-05-13
Filing date: 2016-05-12
Publication date: 2016-11-17

Abstract

A method of enhanced flow-control based on TS 36.425 (split bearer environment) is presented where the feedback mechanism is extended by including an estimated queue delay in the SeNb and an estimated Internode interface (X2 backhaul) is included. The objective is to empty both queues at substantially the same moment. Due to delays in the internode interface or SeNB queue, this objective could be endangered when TS 36.425 is applied as such. The fed back delays are applied in determining the queue in the MeNB in a portion that represents the amount of PDUs that would not be submitted and acknowledged in time if these PDUs were forwarded to the SeNB. By partitioning the MeNB queue in parts that are, and are not allowed to be forwarded to the SeNB, the objective is achieved.

Description

Title

METHOD, SYSTEM AND DEVICE FOR PROVIDING FLOW CONTROL IN A

SPLIT BEARER ENVIRONMENT.

Technical Field The present idea relates generally to a method, system and device to enable a Radio Base Station to provide an enhanced flow control of Packet Data Units in a split bearer environment, in cooperation with one or more other Radio Base Stations or Access Points (APs)

Background

In a typical cellular network, also referred to as a wireless communication system, a User Equipment (UE), communicates via a Radio Access Network (RAN) to one or more Core Networks (CNs).

A UE is referred to as a mobile terminal by which a subscriber can access services offered by an operator's CN. The UEs may be for example communication devices such as mobile telephones, cellular telephones, laptops, tablet computers or vehicle-mounted mobile devices, enabled to communicate voice and/or data. The wireless capability enables to communicate voice and/or data, via the RAN, with another entity, such as another UE or a server.

The cellular network covers a geographical area which is divided into cell based areas. Each cell area is served by a Base Station (BS), or Radio Base Station (RBS), which is also referred to as e.g. "evolved NodeB", "eNB", "eNodeB", "NodeB", "B node", BTS (Base Transceiver Station) or Access Point (AP), depending on the technology and terminology used, such as Long Term Evolution (LTE), or Wireless Local Area Networks (WLAN), deploying WiFi IEEE 802.1 1 protocols. Aggregation of more than one carrier on the same or separate bands is an option, in addition to the bands already in use for LTE.

The RBSs may be of different classes such as e.g. macro RBS, home RBS or pico RBS, or short distance APs, based on transmission power and thereby also on cell size.

A cell is the geographical area where radio coverage is provided by the RBS at a RBS site or AP. One RBS or AP may serve one or more cells, also denoted as carriers. Further, each RBS or AP may support one or several communication technologies. The RBSs or AP communicate over the air interface operating on radio frequencies with the UEs within coverage range of the RBSs or APs.

The Universal Mobile Telecommunication System (UMTS) is a third- generation, 3G, mobile communication system, which evolved from the second- generation, 2G, Global System for Mobile communications (GSM), and is intended to provide improved mobile communication services based on Wideband Code Division Multiple Access (W-CDMA) access technology. UMTS Terrestrial Radio Access Network (UTRAN) is essentially a RAN using W-CDMA. The 3rd. Generation Partnership Project (3GPP) has undertaken to evolve further the UTRAN (and GSM) based radio access network technologies.

The Long Term Evolution (LTE) (-advanced) mobile communication system is defined as the fourth-generation (4G) mobile communication technology standard within 3GPP as to improve UMTS to cope with future requirements in terms of improved services such as higher data rates, improved efficiency, and lower costs. The UTRAN, being the radio access network of UMTS is further developed into an Evolved UTRAN (E-UTRAN), also referred to as a mobile broadband network, and indicated as the radio access network of an LTE (advanced) system. In an E-UTRAN, a UE is wirelessly connected to a RBS, commonly referred to as evolved NodeB, eNodeB or eNB.

Dual connectivity is one of the features that had been standardized within the umbrella work of small cell enhancements within 3GPP Release-12. Dual connectivity is a feature that allows a UE to simultaneously receive and transmit to at least two different RBSs or APs. If dual connectivity is deployed in an LTE network technology, the two different RBSs are usually denoted as Master eNodeB (MeNB) and Secondary eNodeB (SeNB). MeNBs serve a Master Cell Group (MCG), and the SeNBs serves a Secondary Cell Group (SCG). It is assumed that the Radio Resource Control (RRC) protocol, which is responsible for configuring the UE, is terminated within the MeNB. While the UE receives RRC control signaling via the MCG, it may receive user data via both the MCG and the SCG.

In the split bearer architecture option of dual connectivity the downlink data is split on the Packet Data Convergence Protocol (PDCP) layer in the MeNB. The MeNB may route PDCP Packet Data Units (PDUs) dynamically via MeNB Radio Link Control (RLC) to the UE directly, or via an internode interface, also known as backhaul channel, to the SeNB and SeNB to the UE.

The data flow from MeNB to SeNB via the internode interface is typically controlled by a flow control protocol. For this purpose flow control feedback had been defined in 3GPP TS 36.425.

Figure 1 illustrates a block diagram wherein the relations between MeNB, SeNB and Internode Interface are depicted. Figure 1 shows one or more wireless device(s) 100 (which may be interchangeably referred to as UEs 100), radio network node(s) 120A, 120B (which may be interchangeably referred to as eNBs), and core network node(s) 150. A UE 100 may communicate with eNB 120A, 120B over a wireless interface For example, UE 100 may transmit wireless signals to one or more of eNBs 120A and 120B, and/or receive wireless signals from one or more of radio network nodes 120A and 120B. The wireless signals may contain voice traffic, data traffic, control signals, and/or any other suitable information

UE 100 may have dual connectivity capability. Thus, UE 100 may be able to receive signals from and/or transmit signals to at least two different eNBs 120A, 120B simultaneously, via wireless links 1 1 OA, 1 10B respectively. eNB 120A, 120B may interface with core network node 150 via links 130A, 130B respectively, interconnecting network 140, and link 145. The interconnecting network 140 may refer to any interconnecting system capable of transmitting audio, video, signals, data, messages, or any combination of the preceding. eNBs 120A and 120B may communicate to each other by means of an internode interface 135A which may be implemented as an LTE X2 interface. eNBs 120A, 120B interface with one or more Radio Base Stations (RBSs), such as eNBs 120A and 120B over the interconnecting network 140 via links 130A, 130B. The signaling connection link between MeNB 120A and SeNB 120B, comprising links 130A, 130B and interconnecting network 140 may comprise LTE X2 or LTE S1 interfaces, and is collectively denoted as internode interface 135B in the remainder of this application. Core network node 150 may manage the establishment of communication sessions and various other functionalities for UE 100. Wireless device 1 10 may exchange certain signals with core network node 150 using the non-access stratum layer. In non-access stratum signaling, signals between UE 100 and core network node 150 may be transparently passed through the radio access network. Figure 2 illustrates a block diagram of stack layers of LTE entities wherein

PHY denotes the Physical layer, MAC denotes the Media Access Control Layer, RLC denotes the Radio Link Control layer and PDCP denotes the PDCP layer.

Figure 2 depicts an operation wherein, MeNB 120A receives user data via link 204 for UE 100. In other words, MeNB 120A may receive one or more PDCP PDUs to send to UE 100. MeNB 120A may transmit one or more PDCP PDUs to UE 100 via link 1 1 OA, and may forward via link 208 one or more PDCP PDUs to SeNB 120B so that SeNB 120B can transmit these PDCP PDUs to UE 1 10 via link 1 10B. The PDCP PDUs forwarded via link 208 to SeNB 120B may have both PDCP sequence numbers (SNs) and internode interface specific SNs. The internode interface specific SNs may be consecutive, and the PDCP SNs may not be consecutive from the perspective of SeNB 120B. SeNB 120B may report feedback via link 206 to MeNB 120A. The PDCP PDU received from MeNB 120A and SeNB 120B by the UE 100, are submitted via link 202 to the UE's processing system. The forwarded PDCP PDUs via link 208 and the reported feedback via link 206, both traverse the internode interface 135A, 135B. The SeNB 120B is depicted without a PDCP layer as it has no function for the explanation of the method proposed, although the SeNB is an eNB which applies a PDCP layer for its own communication to a network core node, such as core node 150.

MeNB 120A may perform one or more operations based on the received feedback via link 206. As described above, flow control feedback via link 206 between MeNB 120A and SeNB 120B may be required for the split bearer operation in dual connectivity to control the dataflow between MeNB 120A and SeNB 120B.

Feedback from SeNB 120B to MeNB 120A for a split bearer environment may comprise a highest successfully delivered PDCP PDU sequence number by the SeNB 120B RLC; a list of unsuccessfully delivered PDUs on internode interface 135A, 135B based on internode interface specific sequence numbers (e.g., as a list of sequence numbers); and a desired amount of additional bytes by SeNB 120B as an offset of bytes to the highest successfully delivered PDCP PDU sequence number.

Based on this feedback, MeNB 120A may perform flow control as to maximize the throughput via SeNB 1 15B,.

Summary In view of the discussion above, it is an object for embodiments herein to provide an enhanced flow control of Packet Data Convergence Protocol Packet Data Units, PDCP PDUs, in a split bearer environment. It is another object that the enhanced flow control has a flexibility to be dynamically adaptable to changing link conditions.

The present idea is described within the context of Long Term Evolution

(LTE), i.e. Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (E-UTRAN). It should be understood that the problems and solutions described herein are equally applicable to wireless access networks and User Equipment (UE) implementing other access technologies and standards. LTE is used as an example technology where the proposed idea is suitable, and using LTE in the description therefore is particularly useful for understanding the problem and solutions solving the problem.

As described above, dual connectivity is a feature that allows a UE to simultaneously receive and transmit to at least two different network points, commonly referred to as Master e-NodeB (MeNB) and Secundary e-NodeB (SeNB). Feedback between the MeNB and the SeNB may be required for the split bearer operation in dual connectivity to balance the dataflow between MeNB and SeNB. Feedback may also be required for the PDCP transmitting entity in the MeNB from SeNB to MeNB to make sure that for split bearers, the MeNB does not bring more than half of the PDCP sequence number space in flight and any delay in the link from the MeNB via the SeNB towards the UE is taken into account to reach a balancing to empty both queues of the MeNB and the SeNB at substantially the same time.

The present disclosure contemplates enhanced embodiments that may provide an efficient feedback mechanism that fulfils these requirements. Although explained for an implementation with one MeNB and a single SeNB, the solution is applicable for a configuration with multiple SeNBs. In an aspect of the proposed idea, a method in a system is proposed wherein the system comprises a first network node, a second network node and a User Equipment, wherein the network nodes are communicatively connected via an internode interface, and are operating in a split bearer environment.

The method comprising the steps,

A first step represents forwarding, by the first network node, downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for the user equipment, UE, which are forwarded by the first network node to the second network node via the internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface. Each of the one or more PDUs are having an associated PDCP sequence number and an associated internode interface specific sequence number, wherein the internode interface specific sequence numbers assigned by the first network node. A second step represents determining by the second node, based on the timestamps received from the first node,, an estimated delay in delivering the forwarded PDCP PDUs by the second network node, the PDCP PDUs destined for the UE (100), wherein the delay is caused by the internode interface and or the queueing time in the queue of the second network node.

A third step represents transmitting as feedback, by the second network node delay information based on the timestamps received from the first node, indicating the determined delay in delivering the forwarded PDCP PDUs, destined for the UE.

The received delay information may indicate a delay in relation to the throughput of the internode interface, on which the first network node forwards the PDCP PDUs towards the second network node or a delay in relation to the throughput of a queue of the second network node., The queue comprises PDCP PDUs forwarded by the first network node, that are to be scheduled for transmission to the UE, or both delays.

In a further aspect of the proposed idea, a method is proposed wherein the received feedback by the first network node is applied for controlling a PDCP PDU flow of PDUs destined for the UE towards the second network node via the internode interface.

In a still further aspect the proposed idea proposes a method in a first network node that operates in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a User Equipment, UE, are forwarded to a second network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface. Each of the one or more PDUs has an associated PDCP sequence number and an associated internode interface specific sequence number, wherein the internode interface specific sequence numbers are assigned by the first network node.

The method as proposed comprises the step of receiving feedback from the second network node wherein the feedback from the second network node comprises delay information that indicating a delay in delivering PDCP PDUs by the first network node, via the second network node, towards the UE.

In a still further aspect a method is proposed wherein the received delay information based on the timestamps received by the second node from the first node, indicates a delay in relation to the throughput of the internode interface, on which the first network node forwards the PDCP PDUs towards the second network node, or a delay in relation to the throughput of a queue of the second network node, wherein the queue comprises PDCP PDUs forwarded by the first network node, and to be scheduled for transmission to the UE, or both delays.

In a still further aspect of the method proposed, the feedback received from the second network node also comprises any or any combination of:

a highest PDCP sequence number of a PDCP PDU that was successfully delivered in sequence to the UE among the one or more PDCP PDUs forwarded to the second network node by the first network node;

- a desired additional amount of data in bytes, the desired additional amount of data in bytes counted from the highest PDCP sequence number of the PDCP PDU that was successfully delivered in sequence to the UE;

- a list of any internode interface specific sequence numbers of PDCP

PDUs forwarded to the second network node that were declared as being lost at the second network node and not yet reported to the network node as being lost.

In a still further aspect of a method is proposed in a second network node that operates in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a User Equipment, UE, are received from a first network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface.

Each of the one or more PDUs has an associated PDCP sequence number and an associated internode interface specific sequence number, wherein the internode interface specific sequence numbers were assigned by the first network node. The proposed method comprises the step of submitting feedback by the second network node, wherein the feedback from the second network node comprises delay information based on the timestamps received from the first node, indicating a delay in delivering PDCP PDUs received from the first network node, destined for the UE, and transmitted to the UE by the second network node.

In a still further aspect the method proposes that the delay information based on the timestamps received from the first node indicates a delay in relation to the throughput of the internode interface on which the first network node forwards the PDCP PDUs towards the second network node or a delay in relation to the throughput of a queue of the second network node, wherein the queue comprises PDCP PDUs received from the first network node and to be scheduled for transmission to the UE, or both delays. In a still further aspect of the method proposed, the first network node is

Master e-NodeB, MeNB, the second network node is a Secondary e-NodeB, SeNB, or wireless access point, wherein the MeNB and the SeNB operate in a Long Term Evolution, LTE, or LTE advanced technology and the wireless access point operates in an Wireless Local Area Network, WLAN.

In a still further aspect of the proposed idea a mobile telecommunication system is proposed that comprises a first network node, a second network node and at least one User Equipment, wherein the network nodes are communicatively connected via an internode interface and operate in a split bearer environment.

Both network nodes are communicatively connected via wireless links to the UE.

The first network node is arranged to forward downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for the user equipment, UE, to the second network node on the internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface. And wherein each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number. The internode interface specific sequence numbers are assigned by the first network node. The second network node is arranged to determine or estimate based on the timestamps received from the first node, a delay in delivering the forwarded PDCP PDUs destined for the UE, and is further arranged to transmit as feedback, delay information indicating the delay in delivering the forwarded PDCP PDUs, destined for the UE.

In a still further aspect a first network node is proposed that is arranged to operate in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, are forwarded by the first network node to a second network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface.

Each of the one or more PDUs are having an associated PDCP sequence number and an associated internode interface specific sequence number, wherein the first network node has an assigner module that is arranged to assign the internode interface specific sequence number.

The first network node further comprises a feedback receiver that is arranged to receive feedback via an I/O module from the second network node, and the feedback from the second network node comprises delay information based on the timestamps received from the first node, that indicates a delay in delivering PDCP PDUs by the first network node, destined for the UE, via the second network node, and transmitted to the UE by the second network node. In a still further aspect the first network node still further comprises a flow controller for controlling, based on the received feedback, a PDCP PDU flow of PDUs destined for the UE, towards the second network node via the internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface,

In a still further aspect a second network node is proposed that is arranged to operate in a split bearer environment, and wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, are received by the second network node from a first network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface.

Each of the one or more PDUs are having an associated PDCP sequence number and an associated internode interface specific sequence number assigned by the first network node.

The second network node comprises a feedback transmitter that is arranged to transmit feedback via an I/O module, wherein the feedback from the second network node that comprises delay information indicating a delay in delivering the PDCP PDUs , destined for the UE, by the second network node.

In a still further aspect the second network node further comprises a delay detector, arranged to detect a delay in relation to the throughput of the internode interface, on which the PDCP PDUs are received from the first network node, and wherein the feedback indicates the detected delay.

In a still further aspect the second network node comprises a delay detector that is arranged to detect a delay in relation to the throughput of a queue of the second network node, wherein the queue comprises PDCP PDUs received from the first network node, and are to be scheduled for transmission to the UE, and wherein the feedback indicates the detected delay.

In a still further aspect a computer program product is proposed, which, when being executed by a processor module in a first network node that is arranged to operate in a split bearer environment. This first network node is adapted to carry out or control a method for a flow control of downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE.

The PDCP PDUs are forwarded by the first network node to a second network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface. And wherein each of the one or more PDUs are having an associated PDCP sequence number and an associated internode interface specific sequence number.

The internode interface specific sequence is assigned by the first network node, and the method comprises the step of receiving feedback from the second network node, wherein the feedback from the second network node comprises delay information. This delay information indicates a delay in delivering PDCP PDUs by the first network node, destined for the UE, via the second network node, and wherein the received feedback is applied by the first network node to control a PDCP PDU flow of PDUs destined for the UE, towards the second network node via the internode interface.

In a still further aspect of the proposed idea a first network node is proposed that is arranged to operate in a split bearer environment and adapted to carry out or control a method for a flow control of downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a User Equipment, UE. The PDCP PDUs are forwarded by the first network node to a second network node on an internode interface. The downlink data includes timestamps indicating when the data is transmitted on the internode interface. And wherein each of the one or more PDUs are having an associated PDCP sequence number and an associated internode interface specific sequence number.

The internode interface specific sequence are assigned by the first network node, wherein the first network node comprises;

- a forwarding module for forwarding one or more PDCP PDUs to the second network node;

- a feedback receiver module for receiving feedback from the second network node, the feedback comprising delay information indicating a delay in delivering the one or more PDCP PDUs by the first network node, destined for the UE, via the second network node, and

- a controller module for controlling the flow of PDCP PDUs to the second network node, based on the feedback received.

The objective is to empty both queues with PDCP PDUs for a particular UE at substantially the same moment. Due to delays in the internode interface or SeNB queue, this objective could be challenging when 3GPP TS 36.425 is applied as such. The fed back delays are applied in determining the queue in the MeNB in a portion that represents the amount of PDCP PDUs that would not be submitted and acknowledged in time if these PDUs were forwarded to the SeNB. By partitioning the MeNB queue in parts that are, and are not allowed to be forwarded to the SeNB, the objective is achieved.

These and other embodiments according to the present idea illustrated in more detail with reference to the enclosed drawings.

Brief description of the Drawings Figure 1 is a block diagram illustrating an embodiment of a system;

Figure 2 is a block diagram illustrating an embodiment of a system;

Figure 3 is a signalling diagram illustrating an embodiment of a method;

Figure 3A is a signalling diagram illustrating an embodiment of a method;

Figure 3B is a signalling diagram illustrating an embodiment of a method;

Figure 4 is a block diagram illustrating an embodiment of a method;

Figure 5 is a block diagram illustrating an embodiment of an entity;

Figure 6 is a block diagram illustrating an embodiment of an entity;

Figure 7 is a block diagram illustrating an embodiment of modules;

Detailed Description

The method that will be described here, besides the specified 3GPP TS 36.425 flow control feedback of highest successfully in-sequence delivered PDCP PDU, desired additional number of bytes, and missing X2 PDUs on the internode interface 135A, 135B, explains how an additional flow control feedback information is sent from SeNB 120B to MeNB 120A. This additional information may include

The latest delay estimate or measurement of the one-way latency on the internode interface 135A, 135B from MeNB 120A to SeNB 120B. The measurement can be obtained e.g. by calculating the difference between sent- time and receive-time of downlink data. For this purpose the MeNB may include sent-time timestamps when transmitting downlink data on the internode interface 135A, 135B to the SeNB 120B, but also other methods are conceivable to give an acceptable estimate of the current internode interface 135A, 135B delay, e.g. sending a probing message on lower layers of the internode interface 135A, 135B. It must be assured that these delay measures, only measure the delay from MeNB 120A to SeNB 120B and not the round trip delay, while the other delay estimation measures typically measure the round trip delay..

The current SeNB 120B queuing delay in the SeNB 120B queue, which is the time the oldest data unit spent in the SeNB 120B queue. For this measure, the delay or time spent of a PDCP PDU in the queue associated with a PDCP PDU destined for the specific UE using the SeNB for aggregation purposes, or alternatively the overall packet data queue of all UEs associated with the SeNB could be considered. Alternatively, the SeNB may estimate the expected queueing time for new packets in the SeNB based on metrics defined further below.

Alternatively the sum of the one-way delay estimate of the internode interface 135A, 135B and SeNB 120B queuing delay as described previously may be indicated from SeNB 120B to MeNB 120A.

Feedback may be provided periodically, i.e. based on feedback periodicities used also for other feedback indications, such as highest successfully delivered PDCP PDU, desired bytes, missing X2 PDUs as described above, but also lower periodicities may be used, such as 10ms or 20ms.

In one embodiment of the flow control method, feedback is only given upon request. I.e. the SeNB 120B includes this information in flow control feedback only upon explicit request from MeNB 120A. This request could be triggered by inserting the before mentioned sent-timestamp in the downlink data transmission from MeNB 120A to SeNB 120B. If this timestamp is present, the SeNB 120B is requested to include the additional flow control feedback, i.e. internode interface 135A 135B delay measurement, SeNB 120B queuing time or sum of both.

The feedback request can also be seen as a probing of the delay on the internode interface 135A, 135B and/or on SeNB 135B queue. The feedback request can also be indicated explicitly in a new control frame from MeNB 120A to SeNB 120B, alternatively to including it in an existing transport frame from MeNB 120A to SeNB 120B. An existing transport frame could also be empty, e.g. does not need to include user data, when the feedback request is included.

Figure 3 is a signalling diagram illustrating an embodiment of method steps wherein the feedback is collected by the SeNB 120B and fed back to the MeNB 120A.

MeNB 120A assigns 302 internode interface numbers to each PDCP PDU that is to be forwarded to the SeNB 120B and subsequently forwards 304 the PDCP PDU to the SeNB via the internode interface 135A, 135B.

The SeNB receives 304 the PDCP PDU and is able, according to the method described in 3GPP TS 36.425 to detect 306 whether one or more PDCP PDUs are missing, and if so declares 308 these PDCP PDUs as lost and memorizes 310 the internode interface specific sequence number of these lost PDCP PDUs. The PDCP PDUs regarded as lost were apparently lost while traversing the internode interface 135A, 135B.

The SeNB 120B, still having PDCP PDUs received, albeit maybe not all the PDCP PDUs forwarded by the MeNB 120A, queues and schedules the PDCP PDUs for transmission to the UE. Subsequently the transmitter of SeNB transmits 312 the PDCP PDUs to UE 100 via wireless link 1 10B.

The UE 100, when having successfully received the PDCP PDUs will acknowledge 314 the reception of the particular PDCP PDU towards the SeNB 120B. The period of time that the PDCP PDUs were in the queue of SeNB 120B, regarded as a queue delay. The SeNB 120B delay comprises the queue delay and processing delay and can be estimated based on among others the packet's position in the queue, the outbound throughput, the priority of the bearer the packet is associated with, the scheduling type of the SeNB 120B, e.g. Round- Robin, Proportional Fair scheduling, or Hybrid Automatic Repeat reQuest (HARQ) error probability, HARQ Round Trip Time, RTT, RLC retransmission delay, processing time at the SeNB 120B and UE 100.

The queue delay is identified 316 by SeNB 120B. The SeNB 120B may also identify 316 an internode interface delay caused by the transfer over the internode interface 135A, 135B by e.g. detecting a timestamp in an internode interface specific frame, and comparing this timestamp with a local synchronized timer of the SeNB 120B. In an embodiment, the internode specific frame is a specific frame that comprises the forwarded PDCP PDUs.

The SeNB transmits 318 a feedback to the MeNB, comprising any or any combination of:

- the estimated queueing delay identified;

- the estimated internode interface delay identified;

- the highest PDCP sequence number of a PDCP PDU that was successfully delivered in sequence to the UE 100, as acknowledged by the UE 100, among the one or more PDCP PDUs received by the SeNB from the MeNB;

- a desired additional amount of data in bytes, the desired additional amount of data in bytes counted from the highest PDCP sequence number of the PDCP PDU that was successfully delivered in sequence to the user equipment;

- a list of any internode interface specific sequence numbers of PDCP PDUs forwarded to the SeNB 120B that were declared as being lost at the SeNB 120B and not yet reported to the MeNB 120A as being lost;

- the currently minimum desired buffer size at the SeNB for transmitting to the UE user data associated with Radio Access Bearers configured with the split bearer option.

Additionally the SeNB removes 320 the internode interface specific sequence numbers of the corresponding acknowledged PDCP PDUs from its queue.

On reception 318 of the feedback, the MeNB 120A removes 322 the acknowledged PDCP PDUs from its queue. The MeNB may, based on among others, the feedback received 318, its own queueing delay, its own processing status, priority bearers, etc. control 324 the dataflow of PDCP PDUs by means of a flow control scheme wherein a part of the PDCP PDU are transmitted by the MeNB 120A to the UE 100 and another part, also destined for the same UE 100, will be forwarded to the SeNB 120B. Figure 3A is a flowchart illustrating an embodiment of method steps performed by the MeNB 120A, wherein the feedback of the SeNB 120B is received by the MeNB 120A.

MeNB 120A assigns 302A internode interface specific sequence numbers to each PDCP PDU that is to be forwarded to the SeNB 120B and subsequently forwards 304A PDCP PDUs to the SeNB via the internode interface 135A, 135B.

The forwarded PDCP PDUs can be provided by the MeNB with a time stamp, thereby enabling the SeNB to detect an internode interface delay caused by the transfer over the internode interface 135A, 135B.

The MeNB receives 318A a feedback of the SeNB, comprising any one, or any combination of:

- the estimated queueing delay identified in the SeNB;

- the estimated internode interface delay identified;

On reception 318A of the feedback, the MeNB 120A removes 322A the acknowledged PDCP PDUs from its queue. The MeNB may, based on among others, the feedback received 318A, its own queueing delay, its own processing status, priority bearers, etc.. By processing the feedback of the SeNB, the MeNB is enabled to control 324A the dataflow of PDCP PDUs by means of a flow control scheme wherein a part of the PDCP PDU are transmitted by the MeNB 120A to the UE 100 and another part, also destined for the same UE 100, will be forwarded to the SeNB 120B.

Figure 3B is a flowchart illustrating an embodiment of method steps performed by the SeNB 120B, wherein the feedback is collected by the SeNB 120B and fed back to the MeNB 120A.

The SeNB receives 304B via internode interface 135A, 135B, PDCP PDUs from the MeNB wherein the received PDCP PDUs are assigned internode interface specific sequence numbers by the MeNB.

The SeNB is able, with the assigned internode interface specific sequence numbers, according to the method described in 3GPP TS 36.425 to detect 306B whether one or more PDCP PDUs are missing, and if so declares 308B these PDCP PDUs as lost and memorizes 310B the internode interface specific sequence number of these lost PDCP PDUs. The PDCP PDUs regarded as lost were apparently lost while traversing the internode interface 135A, 135B.

The SeNB 120B, still having PDCP PDUs received, albeit maybe not all the PDCP PDUs forwarded by the MeNB 120A, queues and schedules the PDCP PDUs for transmission to the UE. Subsequently the transmitter of SeNB transmits 312B the PDCP PDUs to UE 100 via wireless link 1 10B.

The UE 100, when having successfully received the PDCP PDUs will acknowledge 314B the reception of the particular PDCP PDU towards the SeNB 120B.

The period of time that the PDCP PDUs were in the queue of SeNB 120B, is regarded as a queue delay. The SeNB 120B delay comprises the queue delay and processing delay and can be estimated based on among others the packet's position in the queue, the outbound throughput, the priority of the bearer the packet is associated with, the scheduling type of the SeNB 120B, e.g. Round- Robin, Proportional Fair scheduling, or Hybrid Aautomatic Rrepeat reQquest (HARQ) error probability, HARQ Round Trip Time, RTT, RLC retransmission delay, processing time at the SeNB 120B and UE 100.

The queue delay is identified 316B by SeNB 120B. The SeNB 120B may also identify an internode interface delay caused by the transfer over the internode interface 135A, 135B by e.g. detecting a timestamp in an internode interface specific frame, and comparing this timestamp with a local synchronized timer of the SeNB 120B. In an embodiment, the internode specific frame is a specific frame that comprises the forwarded PDCP PDUs. The SeNB transmits 317B a feedback to the MeNB, comprising any or any combination of:

- the estimated queueing delay identified;

- the estimated internode interface delay identified;

Additionally the SeNB removes 320B the internode interface specific sequence numbers of the corresponding acknowledged PDCP PDUs from its queue. Figure 4 is a block diagram illustrating an embodiment of the method wherein the flow control of the MeNB 120A forwards PDCP PDUs to the SeNB. A general target of the MeNB 120A is to deliver data as fast as possible to the UE 100. In the case of a split bearer environment, also known as dual connectivity from the UE's 100 perspective, the target is to deliver PDCP PDUs as fast as possible to the UE, by either the MeNB 120A or the SeNB 120B. Such that this aim can be achieved by forwarding PDCP PDUs either via MeNB 120A directly to the UE 100 or via the internode interface 135A, 135B and SeNB 120B to the UE 100. Figure 4 depicts a queue 404A of the MeNB 120A and a queue 404Bof the SeNB 120B. PDCP PDUs, destined for UE 100, are received 402 by the MeNB 120A in its queue 404A.

The flow controller of MeNB 120A decides which and how many PDCP PDUs from queue 404A, based on among others the feedback received from the SeNB 120B, are forwarded 408 to SeNB 120B. PDCP PDUs scheduled for transmission to the UE 100, are taken out 406A, 406B of both queues 404A, 404B respectively.

The MeNB 120A estimates based on its own outbound throughput and the received feedback from the SeNB 120B how much of the queued PDCP PDUs it can transmit faster to the UE 100 itself than forwarding it to the SeNB 120B and transmitting it from there to the UE 100.

In one embodiment of this idea, for each newly incoming 402 PDCP PDU, or at each the reception of each flow control feedback, or periodically, the MeNB 120A estimates the delay of the new packet, or of each of the packets in the queue 404A, to reach the UE 100 via its own link 1 10A, as well as the delay of the internode interface 135A, 135B or the queueing delay of the SeNB 120B. Based on these values, the MeNB 120A may decide via which the PDCP PDU is send to the UE 100.

The queue 404A of MeNB 120A is for illustrative means divided into several parts, representing amounts of PDUs;

- part 41 OA, comprising a number of PDUs representing:

(MeNB 120A throughput * Internode interface 135A, 135B delay )

- part 410B, comprising a number of PDUs representing:

(MeNB 120A throughput * SeNB 120B queue delay )

- part 410C, PDUs received 402, and not allocated to either part 41 OA or 410B.

As an example decision criterion, the MeNB 120A flow controller may for each newly received 402 PDCP PDU define via which link the PDCP PDU will be submitted to the UE 100, and hence in which queue part 41 OA, 41 OB, 41 OC the PDU will be part of:

If the MeNB 120A delay is larger or equal to the sum of a) the delay in relation to the internode interface 135A, 135B, and b) the delay in relation to the queue 404B of SeNB 120B, then forward PDCP PDUs to the SeNB 120B. Figure 4 indicates the part of the queue 404A for these PDCP PDUs as "PDCP PDUs allowed to forward to SeNB" 41 OC.

If on the other hand the MeNB 120A delay is lower to the sum of a) the delay in relation to the internode interface 135A, 135B and b) the delay in relation to the queue 404B of SeNB 120B, then keep the packet in the queue 404A at the MeNB 120A, as indicated in figure 4 by "not allowed to forward to SeNB" 41 OA, 410B.

Wherein:

- The MeNB 120A delay comprises the queue delay and processing delay. MeNB 120A delay can be estimated based on among others the packet's position in the queue, the outbound throughput, the priority of the bearer the packet is associated with, the scheduling type of the MeNB 120A, e.g. Round-Robin, Proportional Fair scheduling, or Hybrid automatic repeat request (HARQ) error probability, HARQ Round Trip Time, RTT, RLC retransmission delay, processing time at the MeNB 120A and UE 100.

- The delay in relation to the internode interface 135A, 135B is the based on the corresponding delay information received from as feedback 318 from the SeNB.

The delay in relation to the queue 404B of SeNB 120B is the based on the corresponding delay information received from as feedback 318 from the SeNB. By means of allocating parts 41 OA, 410b and 410C of the queue 404A explained above the forwarding of PDCP PDUs, the flow control method shown in 3GPP TS 36.425 can take PDCP PDUs from the respective queue parts 41 OA, 410B, 410C. The MeNB 120A may take PDCP PDUs, to be transmitted via MeNB 120A to the Ue 100, from the entire queue 404A, so from parts 41 OA, 41 OB and 410C, while PDCP PDUs to be forwarded to the SeNB 120B may only be taken from the part 410C.

If there are free transmission opportunities at the MeNB 120A, e.g. indicated by MeNB scheduler, PDCP PDUs are taken or pulled from the queue 404A in the MeNB 120A and transmitted to the UE 100.

At the subsequent delay estimation, based on the received feedback 318, by the MeNB 120A as described above, delay for the PDCP PDUs is re-evaluated. It may happen that at this point the delay in relation to the internode interface 135AQ, 135B, or the delay in relation to the queue 404B of the SeNB 120B is reduced, in which case packets previously determined as "Not allowed to forward to the SeNB" are forwarded to the SeNB.

The flow controller of MeNB has a first task in partitioning the queue 404A into parts 41 OA, 410B and 410C by means of allocating newly received 402 PDCP PDUs, and a second task of taking out PDCP PDUs for delivering by the MeNB 120A directly to the UE 100, of having the MeNB 120A forwarding the PDCP PDU towards the SeNB 120B.

The objective of considering the information above in the forwarding decision of PDCP PDUs is eventually to balance the data queueing at MeNB 120A and SeNB 120B. At the end of a download session the method as explained above defines the means to empty both queues 404A, 404B substantially at the same time. This way, for the end user, it looks like a constant bitrate is provided by the aggregation of the carriers. Since no data is stuck in one queue while the other queue is already emptied, the total download time is decreased.

Figure 5 is a block diagram illustrating the MeNB 120A, with its components arranged for control a flow of PDCP PDUs in a split bearer environment according the method illustrated above.

The MeNB 120A comprises:

a processor module 501 arranged to process program instructions; a memory module 502 arranged to store the program instructions and network parameters;

an interface module 507 arranged to connect to other entities, such as to another eNB with an LTE X2 via interface 507A or an LTE S1 link towards a core node 150. Interface 507B might be a wireless interface to link to a UE 100 represented by link 1 10A;

A timer e.g. for providing timestamps to the internode interface specific frames as specified above, to enable internode interface 135A, 135B timing measurement estimates by the SeNB 120B;

- A sequence number assigner, to assign internode interface specific sequence numbers, as specified in TS 36.425;

A PDCP PDU queue 502A, representing the logical queue 404A;

A Feedback receiver 505 for interpreting and processing the feedback received from the SeNB 120B, and

- A flow controller 508 for controlling the queue 502A and forwarding

PDCP PDUs to the SeNB for delivery to the UE 100, applying the methods as described above.

The processor module 501 is further arranged, under the program instructions, to control the interface module 507, the sequence number assigner 504, the feedback receiver 505 and the flow controller 508.

Figure 6 is a block diagram illustrating the SeNB 120B, with its components arranged to cooperate in a flow control performed by a MeNB 120A, wherein both the MeNb 120A and SeNB 120B operate in a split bearer environment according the method illustrated above.

The SeNB 120B comprises:

a processor module 601 arranged to process program instructions; a memory module 602 arranged to store the program instructions and network parameters;

- an interface module 607 arranged to connect to other entities, such as to another eNB with an LTE X2 via interface 607A or an LTE S1 link towards a core node 150. Interface 607B might be a wireless interface to link to a UE 100 represented by link 1 10B; A timer e.g. for enabling a delay estimates of the internode interface 135A, 135B with support of the timestamps of as provided to the internode interface specific frames as specified above;

A delay detector 605 for estimating the delay in relation to the internode interface 135A, 135B, and the delay in the queue of SeNB 120B;

A PDCP PDU queue 602A, representing the logical queue 404B, and

A Feedback transmitter 606 for collecting and transmitting the feedback, as explained above, towards MeNB 120A.

Figure 7 is a block diagram illustrating modules comprised by MeNB 120A.

The MeNB 120A comprises a Feedback receiver module 702, enabled to receive feedback from the SeNB 120B wherein the feedback may comprise any or any combination of:

- the queueing delay identified by the SeNB 120B;

- the internode interface delay identified by SeNB 120B;

- the highest PDCP sequence number of a PDCP PDU that was successfully delivered in sequence to the UE 100, as acknowledged by the UE 100, among the one or more PDCP PDUs received by the SeNB 120B from the MeNB 120A;

- the currently minimum desired buffer size at the SeNB for transmitting to the UE user data associated with Radio Access Bearers configured with the split bearer option. The MeNB 120A further comprises a Control module 706, enabled to decide whether received 402 PDCP PDUs from a core network node 150 are whether or not allowed to forward to the SeNB 120B. As an example decision criterion, the MeNB 120A flow controller may apply:

If the MeNB 120A delay is larger or equal to the sum of a) the delay in relation to the internode interface 135A, 135B, and b) the delay in relation to the queue 404B of SeNB 120B, then forward PDCP packets to the SeNB 120B. Figure 4 indicates the part of the queue 404A for these PDCP PDUs as "PDCP PDUs allowed to forward to SeNB"

If on the other hand the MeNB 120A delay is lower to the sum of a) the delay in relation to the internode interface 135A, 135B and b) the delay in relation to the queue 404B of SeNB 120B, then keep the packet in the queue 404A at the MeNB 120A, as indicated in figure 4 by "not allowed to forward to SeNB".

The MeNB still further comprises a forwarding module 708, which is arranged to forward PDCP PDUs from the queue 404A towards the SeNB under control of the control module 708.

The method offers the advantage that at the end of a download session, both queues empty 404A, 404B substantially at the same time, despite changing conditions in queue processing, lost packets in flight on the internode interface, changing delays on the internode interface .

The advantage is based on controlling the flow of PDCP PDUs by the MeNB. This flow control is enabled by receiving delay information indicating a delay in delivering PDCP PDUs destined for the UE, from the second network node.

This way, for the end user, it looks like a constant bitrate is provided by the aggregation of the carriers. Since no data is stuck in one queue while the other queue is already emptied, the total download time is decreased.

As feedback is frequently provided by the SeNb 120B to the MeNB 120A, changing conditions on either the internode interface 135A, 135B or the queueing delay, as defined above, in either the MeNB 120A or SeNB 120B, the flow controller in the MeNB 120A is enabled to change the flow control advantageously on a frequent basis.

The objective is to empty both queues at substantially the same moment. The fed back delays are applied in determining the queue 404A in the MeNB 120A in a portion 41 OA, 41 OB that represents the amount of PDCP PDUs that would not be submitted and acknowledged in time if these PDUs were forwarded to the SeNB 120B.

By partitioning the MeNB queue 404A in parts that are, and are not allowed to be forwarded to the SeNB 120B, the objective is advantageously achieved.

Claims

1 ) A method for enhanced flow control of Packet Data Units in a system comprising a first network node (120A), a second network node (120B) and a User Equipment (100), the network nodes communicatively connected via an internode interface (135A, 135B) and operating in a split bearer environment, the method comprising the steps of:

Forwarding, by the first network node (120A), downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for the user equipment, UE, (100) to the second network node (120B) on the internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence numbers assigned by the first network node (120A);

- Determining, by the second network node (120B) based on the timestamps received from the first node, a delay in delivering the forwarded PDCP PDUs by the second network node (120B), the PDCP PDUs destined for the UE (100), and

- Transmitting as feedback, by the second network node (120B), delay information indicating the delay in delivering the forwarded PDCP PDUs, destined for the UE (100).

2) The method according to claim 1 wherein the received delay information indicates a delay in relation to the throughput of the internode interface

(135A, 135B), on which the first network node (120A) forwards the PDCP PDUs towards the second network node (120B).

3) The method according to claim 1 wherein the received delay information indicates a delay in relation to the throughput of a queue (404B) of the second network node (120B), the queue (404B) comprising PDCP PDUs forwarded by the first network node (120A), to be scheduled for transmission to the UE (100). 4) The method according to claim 1 wherein the received feedback is applied by the first network node (120A) to control a PDCP PDU flow of PDUs destined for the UE (100), towards the second network node (120B) via the internode interface (135A, 135B).

5) A method for enhanced flow control of Packet Data Units in a first network node (120A), operating in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, (100) are forwarded to a second network node (120B) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence numbers assigned by the first network node (120A), the method comprising the step of receiving feedback (318, 318A) from the second network node (120B), the feedback from the second network node (120B) comprising: delay information indicating a delay in delivering PDCP PDUs by the first network node (120A), destined for the UE (100), via the second network node (120B).

6) The method according to claim 5 wherein the received delay information indicates a delay in relation to the throughput of the internode interface (135A, 135B), on which the first network node (120A) forwards the PDCP PDUs towards the second network node (120B).

7) The method according to claim 6 wherein the delay in relation to the throughput of the internode interface (135A, 135B) is based on timestamps associated with a PDCP PDU, at least one of the timestamps set by the first network node (120A).

8) The method according to claim 5 wherein the received delay information indicates a delay in relation to the throughput of a queue (404B) of the second network node (120B), the queue (404B) comprising PDCP PDUs forwarded by the first network node (120A), to be scheduled for transmission to the UE (100).

The method according to claim 5 wherein the first network node (120A) requests the second network node (120B) for submitting the feedback.

10) The method according to claim 5 wherein the received feedback is applied by the first network node (120A) to control (324A) a PDCP PDU flow of PDUs destined for the UE (100), towards the second network node (120B) via the internode interface (135A, 135B).

1 1 ) The method according to claim 5 wherein the feedback from the second

network node (120B) also comprises any or any combination of:

- a highest PDCP sequence number of a PDCP PDU that was successfully delivered in sequence to the UE (100) among the one or more PDCP PDUs forwarded to the second network node (120B) by the first network node (120A);

- a desired additional amount of data in bytes, the desired additional amount of data in bytes counted from the highest PDCP sequence number of the PDCP PDU that was successfully delivered in sequence to the UE (100);

- a list of any internode interface specific sequence numbers of PDCP PDUs forwarded to the second network node (120B) that were declared as being lost at the second network node (120B) and not yet reported to the network node as being lost.

12) A method for enhanced flow control of Packet Data Units in a second network node (120B), operating in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, (100) are received from a first network node (120A) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence numbers assigned by the first network node (120A), the method comprising the step of submitting (317B) feedback by the second network node (120B), the feedback from the second network node (120B) comprising: delay information, based on the timestamps received from the first node, indicating a delay in delivering PDCP PDUs received from the first network node (120A), destined for the UE (100).

13) The method according to claim 12 wherein the delay information indicates a delay in relation to the throughput of the internode interface (135A, 135B), on which the first network node (120A) forwards the PDCP PDUs towards the second network node (120B).

14) The method according to claim 13 wherein the delay in relation to the throughput of the internode interface (135A, 135B) is based on timestamps associated with a PDCP PDU, wherein at least one timestamp, set by the first network node (120A), is compared with the actual time of the second network node (120B).

The method according to claim 12 wherein the received delay information indicates a delay in relation to the throughput of a queue (404B) of the second network node (120B), the queue (404B) comprising PDCP PDUs received (304, 304B) from the first network node (120A), to be scheduled for transmission to the UE (100). 16) The method according to claims 1 , 5 or 12 wherein the first network node (120A) is a Master e-NodeB, MeNB, the second network node (120B) is a Secondary e-NodeB, SeNB, or wireless access point, wherein the MeNB and the SeNB operate in a Long Term Evolution, LTE, or LTE advanced technology and the wireless access point operates in an Wireless Local Area Network, WLAN.

17) A mobile telecommunication system for enhanced flow control of Packet Data Units, comprising a first network node (120A), a second network node (120B) and at least a User Equipment (100), the network nodes communicatively connected via an internode interface (135A, 135B) and operating in a split bearer environment, both network nodes (120A, 120B) communicatively connected via wireless links (1 10A, 1 10B) to the UE (100), wherein;

the first network node is arranged to forward downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for the user equipment, UE, (100) to the second network node (120B) on the internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence numbers assigned by the first network node (120A);

the second network node (120B) arranged to determine, based on the timestamps received from the first node, a delay in delivering the forwarded PDCP PDUs destined for the UE (100), and

the second network node (120B) arranged to transmit as feedback, delay information indicating the delay in delivering the forwarded PDCP PDUs, destined for the UE (100). )A first network node (120A) for enhanced flow control of Packet Data Units , arranged to operate in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, (100) are forwarded by the first network node (120A) to a second network node (120B) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the first network node (120A) comprising an assigner module (504) arranged to assign the internode interface specific sequence number, the first network node (120A) further comprising a feedback receiver (505) arranged to receive feedback via an I/O module (507) from the second network node (120B), the feedback from the second network node (120B) comprising:

delay information indicating a delay in delivering PDCP PDUs by the first network node (120A), destined for the UE (100), via the second network node (120B).

19) The first network node (120A) according to claim 18 wherein the first network node (120A) still further comprises a flow controller (508) for controlling, based on the received feedback, a PDCP PDU flow of PDUs destined for the UE (100), towards the second network node (120B) via the internode interface (135A, 135B).

20) A second network node (120B) for enhanced flow control of Packet Data Units, arranged to operate in a split bearer environment, wherein downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, (100) are received by the second network node (120B) from a first network node (120A) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number assigned by the first network node (120A), the second network node comprising a feedback transmitter (606) arranged to transmit feedback via an I/O module (607), the feedback from the second network node (120B) comprising:

- delay information, based on the timestamps received from the first node, indicating a delay in delivering the PDCP PDUs, destined for the UE (100), by the second network node (120B). 21 ) The second network node according to claim 20 wherein the second network node (120B) further comprises a delay detector (605), arranged to detect a delay in relation to the throughput of the internode interface (135A, 135B), on which the PDCP PDUs are received from the first network node (120A), and wherein the feedback indicates the detected delay. 22) The second network node according to claim 20 wherein the second network node (120B) further comprises a delay detector (605), arranged to detect a delay in relation to the throughput of a queue (404B) of the second network node (120B), the queue (404B) comprising PDCP PDUs received from the first network node (120A), to be scheduled for transmission to the UE (100), and wherein the feedback indicates the detected delay.

23) A computer program product for enhanced flow control of Packet Data Units, which, when being executed by a processor module (501 ) in a first network node (120A), arranged to operate in a split bearer environment, is adapted to carry out or control a method for a flow control of downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a user equipment, UE, (100), forwarded by the first network node (120A) to a second network node (120B) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface, each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence assigned by the first network node (120A), the method comprising the step of receiving feedback from the second network node (120B), the feedback from the second network node (120B) comprising: delay information, based on the timestamps received from the first node, indicating a delay in delivering PDCP PDUs by the first network node (120A), destined for the UE (100), via the second network node (120B), andwherein the received feedback is applied by the first network node (120A) to control a PDCP PDU flow of PDUs destined for the UE (100), towards the second network node (120B) via the internode interface (135A, 135B).

24) A first network node (120A), arranged to operate in a split bearer environment, adapted to carry out or control a method for an enhanced flow control of downlink data comprising one or more packet data convergence protocol, PDCP, packet data units, PDUs, destined for a User Equipment, UE, (100), forwarded by the first network node (120A) to a second network node (120B) on an internode interface (135A, 135B), the downlink data including timestamps indicating when the data is transmitted on the internode interface each of the one or more PDUs having an associated PDCP sequence number and an associated internode interface specific sequence number, the internode interface specific sequence assigned by the first network node (120A), wherein the first network node comprises;

- a forwarding module (708) configured to forward one or more PDCP PDUs to the second network node (120B);

- a feedback receiver module (702) configured to receive feedback from the second network node (120B), the feedback comprising delay information based on the timestamps, indicating a delay in delivering the one or more PDCP PDUs by the first network node (120A), destined for the UE (100), via the second network node (120B), and

- a controller module (706) configured to control the flow of PDCP PDUs to the second network node (120B), based on the feedback received.