Efficient uplink scheduling mechanisms for dual connectivity

11678217 · 2023-06-13

Assignee

Inventors

Cpc classification

International classification

Abstract

The present disclosure mainly relates to improvements for the buffer status reporting and the logical channel prioritization procedures performed in the UE, in scenarios where the UE is in dual connectivity and the PDCP layer of the UE is shared in the uplink for MeNB and SeNB. According to the present disclosure, a ratio is introduced according to which the buffer values for the PDCP are split in the UE between the SeNB and the MeNB according to said ratio.

Claims

1. A communication system comprising: a mobile node; a master base station; and a secondary base station; wherein the mobile node comprises: circuitry, which, in operation, connects to the master base station and to the secondary base station via a split bearer that is split between the master base station and the secondary base station in a Packet Data Convergence Protocol (PDCP) layer; determines whether a total buffer occupancy of the PDCP layer in the mobile node exceeds a threshold; responsive to the total buffer occupancy exceeding the threshold, splits the total buffer occupancy of the PDCP layer into both a first PDCP buffer occupancy value for the master base station and a second PDCP buffer occupancy value for the secondary base station; responsive to the total buffer occupancy not exceeding the threshold, splits the total buffer occupancy of the PDCP layer based on a defined split ratio into a first PDCP buffer occupancy value for the master base station and a second PDCP buffer occupancy value for the secondary base station, wherein the defined split ratio is configured such that one of the first and second PDCP buffer occupancy values is equal to the total buffer occupancy, and the other one of the first and second PDCP buffer occupancy values is equal to zero; and a transmitter, which is coupled to the circuitry and which, in operation, transmits a first buffer status report based on the first PDCP buffer occupancy value to the master base station responsive to the first buffer occupancy value being more than zero, and a second buffer status report based on the second PDCP buffer occupancy value to the secondary base station responsive to the second buffer occupancy value being more than zero.

2. The communication system according to claim 1, wherein the defined split ratio is configured by a Radio Resource Control (RRC) message.

3. The communication system to claim 2, wherein the transmitter transmits all uplink data, processed by the PDCP layer, to either the master base station or to the secondary base station depending on the defined split ratio, with an exception of Radio Link Control (RLC) uplink data being transmitted to the master base station and to the secondary base station, respectively.

4. The communication system according to claim 1, wherein the defined split ratio is 1:0 or 0:1.

5. The communication system according to claim 1, wherein transmission of the first buffer status report to the master base station and transmission of the second buffer status report to the secondary base station are independent of each other.

6. The communication system according to claim 1, wherein the threshold is configured by a Radio Resource Control (RRC) message.

7. A method performed by a communication system comprising a mobile node, a master base station and a secondary base station, the method comprising: the mobile node connecting to the master base station and to the secondary base station via a split bearer that is split between the master base station and the secondary base station in a Packet Data Convergence Protocol (PDCP) layer; the mobile node determining whether a total buffer occupancy of the PDCP layer in the mobile node exceeds a threshold; responsive to the total buffer occupancy exceeding the threshold, the mobile node splitting the total buffer occupancy of the PDCP layer into both a first PDCP buffer occupancy value for the master base station and a second PDCP buffer occupancy value for the secondary base station; responsive to the total buffer occupancy not exceeding the threshold, the mobile node splitting the total buffer occupancy of the PDCP layer based on a defined split ratio into a first PDCP buffer occupancy value for the master base station and a second PDCP buffer occupancy value for the secondary base station, wherein the defined split ratio is configured such that one of the first and second PDCP buffer occupancy values is equal to the total buffer occupancy, and the other one of the first and second PDCP buffer occupancy values is equal to zero; the mobile node transmitting a first buffer status report based on the first PDCP buffer occupancy value to the master base station responsive to the first buffer occupancy value being more than zero; and the mobile node transmitting a second buffer status report based on the second PDCP buffer occupancy value to the secondary base station responsive to the second buffer occupancy value being more than zero.

8. The method according to claim 7, wherein the defined split ratio is configured by a Radio Resource Control (RRC) message.

9. The method according to claim 8 comprising: the mobile node transmitting all uplink data, processed by the PDCP layer, to either the master base station or to the secondary base station depending on the defined split ratio, with an exception of Radio Link Control (RLC) uplink data being transmitted to the master base station and to the secondary base station, respectively.

10. The method according to claim 7, wherein the defined split ratio is 1:0 or 0:1.

11. The method according to claim 7, wherein transmission of the first buffer status report to the master base station and transmission of the second buffer status report to the secondary base station are independent of each other.

12. The method according to claim 7, wherein the threshold is configured by a Radio Resource Control (RRC) message.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

(1) The present disclosure will be better understood with reference to the accompanying drawings. The corresponding embodiments are only possible configuration in which the individual features may, however, as described above, be implemented independently of each other or may be omitted. Equal elements illustrated in the drawings are provided with equal reference signs. Parts of the description relating to equal elements illustrated in the drawings may be left out.

(2) FIG. 1 schematically shows an exemplary architecture of a 3GPP LTE system,

(3) FIG. 2 schematically shows an exemplary overview of the overall E-UTRAN architecture of 3GPP LTE,

(4) FIG. 3 schematically shows exemplary subframe boundaries on a downlink component carrier as defined for 3GPP LTE (Release 8/9),

(5) FIG. 4 schematically illustrates the OSI model with the different layers for communication,

(6) FIG. 5 schematically illustrates the relationship of a protocol data unit (PDU) and a service data unit (SDU) as well as the inter-layer exchange of same,

(7) FIG. 6 schematically illustrates the layer 2 user and control-plane protocol stack composed of the three sublayers, PDCP, RLC and MAC,

(8) FIG. 7 schematically gives an overview of the different functions in the PDCP, RLC and MAC layers as well as illustrates exemplary the processing of SDUs/PDUs by the various layers,

(9) FIGS. 8A-8D schematically show four possible dual cell scenarios,

(10) FIG. 9 schematically shows exemplary architectures for dual connectivity,

(11) FIG. 10 schematically shows various options in the DL direction for the U-plane data;

(12) FIG. 11 schematically shows a single MAC entity receiving grants from more than one cell,

(13) FIG. 12 schematically shows two MAC cells receiving grants from two cells without split-bearers,

(14) FIG. 13 schematically shows a network side, user plane architecture option 2C,

(15) FIG. 14 schematically shows a UE side, user plane architecture option 2C,

(16) FIG. 15 schematically shows a network side, user plane architecture option 3C,

(17) FIG. 16 schematically shows a UE side, user plane architecture option 3C,

(18) FIG. 17 schematically shows In UP architecture option 3C and 3D, where the PDCP is a common entity,

(19) FIG. 18 schematically shows an example of an application of a ratio for deriving the BSR,

(20) FIG. 19 schematically shows a UE side user plane architecture option 3C according to one embodiment of the present disclosure,

(21) FIG. 20 schematically shows a UE side user plane architecture option 3C according to one embodiment of the present disclosure.

DETAILED DESCRIPTION

(22) In the present description, use is made of the following terms.

(23) A “mobile station” or “mobile node” is a physical entity within a communication network. One node may have several functional entities. A functional entity refers to a software or hardware module that implements and/or offers a predetermined set of functions to other functional entities of a node or the network. Nodes may have one or more interfaces that attach the node to a communication facility or medium over which nodes can communicate. Similarly, a network entity may have a logical interface attaching the functional entity to a communication facility or medium over it may communicate with other functional entities or correspondent nodes.

(24) The term “master base station” used in the claims and throughout the description of the present disclosure is to be construed as used in the field of dual connectivity of 3GPP LTE-A; thus, other terms are macro base station, or master/macro eNB; or serving base station or any other terminology to be decided later by 3GPP. Similarly, the term “secondary base station” used in the claims and throughout the description is to be construed as used in the field of dual connectivity of 3GPP LTE-A; thus, other terms are slave base station, or secondary/slave eNB or any other terminology to be decided later by 3GPP.

(25) The term “radio bearer” used in the claims and throughout the description of the present disclosure is to be construed in connection with 3GPP terminology, and refers to a virtual connection between two endpoints, i.e., mobile station and base station, which is used for transport of data between those; a term that emphasizes the fact that the virtual connection provides a “bearer service”, i.e., a transport service with specific QoS attributes. A data radio bearer may also be called user plane radio bearer, and a signaling radio bearer may also be called control plane radio bearer. A radio bearer shall be distinguished from other terminology as defined by 3GPP, such as S1 bearer, E-RAB, S5/S8 bearer, EPS bearer, etc. (see also FIG. 2.8 of LTE—The UMTS Long Term Evolution FROM THEORY TO PRACTICE, Edited by: Stefania Sesia, Issam Toufik, Matther Baker, Second Edition, ISBN 978-0-470-66025-6, incorporated herein by reference).

(26) In the following, several embodiments of the present disclosure will be explained in detail. For exemplary purposes only, most of the embodiments are outlined in relation to a radio access scheme according to 3GPP LTE (Release 8/9) and LTE-A (Release 10/11) mobile communication systems, partly discussed in the Technical Background section above. It should be noted that the present disclosure may be advantageously used for example in a mobile communication system such as 3GPP LTE-A (Release 12) communication systems as described in the Technical Background section above. These embodiments are described as implementations for use in connection with and/or for enhancement of functionality specified in 3GPP LTE and/or LTE-A. In this respect, the terminology of 3GPP LTE and/or LTE-A is employed throughout the description. Further, exemplary configurations are explored to detail the full breadth of the present disclosure.

(27) The explanations should not be understood as limiting the present disclosure, but as a mere example of the present disclosure's embodiments to better understand the present disclosure. A skilled person should be aware that the general principles of the present disclosure as laid out in the claims can be applied to different scenarios and in ways that are not explicitly described herein. Correspondingly, the following scenarios assumed for explanatory purposes of the various embodiments shall not limit the present disclosure as such.

(28) According to the present disclosure, some of the drawbacks in some of the alternatives of series 3; e.g., 3C and 3D, shall be removed. Correspondingly, the present disclosure provides several embodiments with regard to an improved buffer status reporting and logical channel prioritization procedure.

(29) As explained before for the prior art, there is so far only one MAC entity, even in carrier aggregation. So, it can only apply the Logical Channel Prioritization, LCP, procedure once, even if it receives grants from more than one cell/link. When the UE is requested to transmit multiple MAC PDUs in one TTI, steps 1 to 3 and the associated rules of the standard LCP procedure may be applied either to each grant independently or to the sum of the capacities of the grants. As a result of the user plane architecture option 3, the UE will have 2 MAC entities that receive separate grants from corresponding cell; but how the LCP will be run (e.g., one by one or aggregately) is not clear, especially for the shared bearer. Consequently, it is also not clear how the PBR allocation could work for such a bearer.

(30) FIG. 15 schematically illustrates an S1-U interface terminating in MeNB, in addition to a radio bearer split in the MeNB, as well as independent RLCs for the split radio bearers. FIG. 17 schematically shows that in the UP architecture options 3C and 3D, the PDCP is a common entity for the RLC, MAC and PHY layers for the MeNB and SeNB.

(31) In the following, the BSR will be considered first.

(32) User plane architecture option Series 3 being considered in 3GPP, in particular in 3GPP document TR 36.842, allows a bearer split such that packets from a particular bearer(s) can be received/transmitted via more than one cell simultaneously from/to the UE.

(33) In order to fulfil the QoS of all bearer(s) of each UE being served in the network, different UL activities, e.g., LCP, BSR, PHR and others can be linked so that, once the UE knows, e.g., how the BSR for the split bearer has to be reported to each link/cell, it can also derive how the PBR derivation shall be done for running LCP for this split bearer correspondingly in each MAC entity towards the individual participating cell(s) or vice versa. This can be further linked to PHR such that a specific PHR trigger may also trigger the BSR/PBR, etc., re-derivation/re-computation and even reporting in that sense a corresponding new trigger.

(34) An option is then to use a fixed ratio which can be semi-statically used (until re-derived/re-configured) to derive for example the BSR and the LCP parameters like the PBR. The ratio could be semi-statically fixed (hereafter called ‘fixed’) until changed later upon a fresh derivation/signalling of the same.

(35) An example thereof is illustrated in FIG. 18. As can be seen in the figure, for a ratio of 1:4 split of Logical Channel 2 (LC2)—BSR in MeNB is reported for 110 and 99 Bytes for LCG1 and LCG2 respectively. Moreover, 133 and 78 Bytes are reported to SeNB for LCG1 and LCG2 respectively.

(36) More specifically, FIG. 18 schematically illustrates a UE side picture. Here, it is assumed that the BSR for only those channels are reported inside an LCG that are actually received/transmitted between the corresponding pair of MeNB-UE or SeNB-UE. As illustrated, in this embodiment, there are two MAC entities in the UE, namely MAC-MeNB and MAC-SeNB, that calculate the buffer size corresponding to their part of the logical channels. In particular, in this example there are two Logical Channel Groups, LCG1 and LCG2, where LCG1 has Logical Channels LC1 and LC4, while LCG2 has Logical Channels LC2 and LC3. As can be seen, only LC2 is the Split Bearer whose packets are transmitted/received via both the MeNB and SeNB. Calculation of the Buffer Status Report adds the BO for all logical channels. BO for each Logical Channel is RLC Buffer+PDCP Buffer. Further, the RLC BO (Buffer Occupancy) is only reported to the corresponding Node, i.e., not shared, since RLC is per eNB. PDCP buffer is shared/split between the corresponding MACs only if the related logical channel is split, otherwise not.

(37) Therefore, for LC1, as an example, BSR to be reported to MeNB by MAC-MeNB is a simple sum of PDCP BO for LC1 (100 Bytes)+RLC BO for LC1 (10 Bytes), and therefore, MAC-MeNB calculates the buffer size corresponding to the logical Channel LC1 as 110 Bytes. Since LCG1 for MAC-MeNB is only consisting of LC1 (LC4 also belonging to LCG1 refers to SeNB), the Buffer Status reported to MeNB (by MAC-MeNB) for LCG1 is 110 Bytes.

(38) Taking the example of Split Bearer case, LC2, since the example ratio is 1:4, namely one part to the MeNB and four parts to the SeNB, the PDCP BO gets split in this ratio. That is, PDCP BO to be reported to MeNB by MAC-MeNB for LC2 is 80*1/5=16 Bytes. Since LC3 is also part of LCG2, the PDCP BO of LC3 is added directly, since LC3 is not a split-bearer. Therefore, PDCP Buffer Occupancy for LCG2 to be reported to MeNB by MAC-MeNB is 76, that is, 16+60 Bytes. Additionally, since the Buffer Status Report is the sum of PDCP BO+RLC BO, the corresponding BSR adds the RLC BOs to this value. Therefore, MAC-MeNB calculates the buffer size corresponding to the logical Channels LCG2 as 99 Bytes, namely 76+11+12 Bytes. Conversely, for reporting to the SeNB, the remaining part of the PDCP BO for LC2 is used, namely 80*4/5=64 Bytes, to which the RLC BO is added, in this example, another 14 Bytes, resulting in a total reported value to the SeNB of 78 Bytes.

(39) In the above example 1:4 is only taken as an exemplary ratio; could be represented also as 1/5:4/5 or 0.2:0.8. As another example, if the UE has 100 Bytes of data to be sent in the UL for a particular split-bearer and the ratio derived and signalled by the network is 2:3 between the MeNB and SeNB for the same bearer, then the UE should report a buffer occupancy of 40 Bytes to the MeNB and 60 Bytes to the SeNB. According to one advantageous implementation, this ratio is based primarily on how much traffic the network wants to offload to the Small Cell (e.g., 10%, 50%, 99% or 100%).

(40) If, e.g., the ratio is 100%, then all the traffic shall be offloaded to the Small Cell. Considering a corresponding ratio of 0:1, namely nothing to the MeNB and all to the SeNB, the PDCP BO gets split accordingly. When presuming the PDCP and RLC buffers of FIG. 18, this would result in the following. For logical channel LC2, the PDCP BO to be reported to the MeNB by MAC-MeNB is 0 bytes. As before, since logical channel LC3 is also part of the group LCG2, the PDCP BO of 60 bytes for logical channel LC3 is added, and in this case completely due to not being a split bearer. Therefore, PDCP BO for group LCG2 to be reported to the MeNB is 60 bytes. To the 60 bytes for the PDCP BO, the corresponding RLC BOs for group LCG2 are to be added; this adds another 11 bytes and 12 bytes for logical channels LC2 and LC3 respectively.

(41) Conversely, for the BSR report to the SeNB, the full PDCP buffer for the split bearer is reported. In particular, the 80 bytes in the PDCP buffer for LC2 are added completely to the RLC BO of 14 bytes for LC2. Thus, the complete BSR reports a total value 94 bytes (80+14).

(42) This applies correspondingly to a special ratio of 0%, or 1:0, i.e., to the case where no traffic shall be offloaded to the Small Cell. In this case, the full PDCP buffer for the split bearer LC2 is reported to the MeNB (in addition to the 60 bytes for LC3, and the RLC BO for LC2 and LC3), and nothing of the PDCP buffer for the split bearer LC2 is reported to the SeNB (although the RLC BO for LC2 is non-zero and still reported to the SeNB).

(43) The particular split ratios of 1:0 and 0:1 have the advantage of a simplified UE behavior with respect to the BSR procedure for the split bearer cases.

(44) It is further advantageous, if buffer status reports are actually only reported when the value of the BSR is not zero. Put differently, especially in the above-mentioned cases where the PDCP BO may be 0 due to the special split ratio of 1:0 or 0:1, the BSR basically reports the BO for the RLC layer, i.e., RLC BO reflecting the status of the received RLC PDUs in the downlink, to the SeNB. However, for those cases where no data is in the buffer for the RLC layer (in this case for LC2), the corresponding BSR that would be computed would have the value 0. Consequently, according to an advantageous embodiment, these kind of BSR which would report a value of 0 shall not be transmitted.

(45) The fixed ratio can, for example, be derived by the network and signalled to the UE. In some implementations, the MeNB is in charge of defining the ratio value, for instance by taking input such as the SeNB load factor from SeNB as well. In one embodiment, the eNB could signal the ratio value to the UE using RRC Signalling (e.g., while (re)-Configuring a Bearer) or using MAC Signalling.

(46) This ratio can tell the UE what fraction of the buffer needs to be reported to each of the participating cells for a particular split-bearer or, alternatively, to all the split-bearers, therefore it can be implemented by using only one ratio per UE.

(47) In some embodiments, the network nodes MeNB and SeNB can share this allocated ratio information so that eNBs not only know how much UL grant will be provided to the UE by the other eNB, for instance in the next few TTIs. This can give an indication of the resource/UL power usage of the other link, and then each link may provide its resource/UL power usage accordingly.

(48) For the particular ratios of 1:0 and 0:1 (i.e., no/full offloading to small cell), the network can signal how to split the total buffer occupancy of the PDCP layer in different ways, as will be explained in the following. For instance, the network may already indicate in the bearer configuration, which link should be used for the BSR reporting for PDCP data as explained above. This may be done, e.g., by a Radio Resource Control (RRC) message, e.g., by a radio resource configuration message. According to a first signalling implementation, a flag may be introduced for a logical channel associated to a split EPS bearer. The flag is thus indicating whether the UE should report PDCP data in the buffer within a BSR for this logical channel or not. For instance, the flag may be included in the logicalChannelConfig information element, defined in the standard TS36.331, in a similar way as the logicalChannelSR-Mask Information Element (IE). Alternatively, the definition of the “data becoming available” in the technical standards TS 36.323, TS36.322 and TS 36.321 can be reused in said respect, such that the PDCP data shall only be considered for the BSR reporting and optionally also for BSR triggering as “data becoming available” when the flag is set. This flag would basically indicate which of the two logical channels for a split bearer is used for BSR reporting of PDCP data. One of the two logical channels, either the one used for transmissions towards the MeNB or the one towards the SeNB, would be enabled for BSR reporting of PDCP data, whereas the other one would be disabled (or suspended) for BSR reporting of PDCP data.

(49) According to a second signalling implementation, a new information element may be specified in either the MAC-MainConfig IE or DRB-ToAddMod IE (already standardized in TS36.331), thus indicating whether the PDCP data of a split bearer shall be considered by a specific radio bearer or logical channel for BSR reporting or not.

(50) Moreover, even if one of the links is configured to be disabled or suspended for BSR reporting of PDCP data of a split bearer, this link is still used for reporting RLC data of a split bearer, e.g., RLC STATUS PDUs, to the corresponding eNB. MAC Control elements (MAC CEs) like BSR or PHR which are also transmitted in the uplink are not radio bearer specific data and hence are not in the scope of this present disclosure.

(51) How the network, for instance the MeNB, derives the ratio could be based on some specific criteria like cell load of participating cell, offloading requirements, such as how much traffic needs to be offloaded to SeNB, UE's UL channel conditions, such as which link is better/worse, QoS factors such as packet delay/bearer latency requirements, etc.

(52) The BSR allocation may only apply to the buffer occupancy in the PDCP sub-layer, as in 3GPP document TS 36.323, but not, e.g., to RLC sub-layer which may be reported “as-is,” i.e., without any further splitting between the MeNB and SeNB.

(53) Further, the above ratio-based splitting may be subject to some “Certain Minimum Traffic/buffer” which may be configured to the UE or specified. For instance, the certain minimum range will be configurable, i.e., when the network configures a bearer to the UE using an RRC Connection Reconfiguration message; it may say that up to Index 20 of Table 6.1.3.1-1: Buffer size levels for BSR (as described in 3GPP TS 36.321-a40) is considered as below certain minimum range.

(54) When the buffer occupancy of the combined PDCP and RLC is less that this minimum threshold, then the UE may rather send its UL data to only one of the link; the link itself could be based on UE's choice or could be pre-configured together with the minimum traffic/buffer occupancy. As one possible alternative of this enhancement, the bearer type (e.g., signalling or specific data bearer like streaming, background, etc.) may determine that the UE may only use a particular link for this data transmission. The choice of link/bearer itself could be pre-configured/specified or based on UE's implementation choice.

(55) According to a further embodiment, which may be used in addition or alternatively to the above and below described embodiments regarding the BSR splitting, any acknowledgements of the TCP layer associated with TCP downlink data received in the UE are always to be transmitted to the MeNB. This is independent from whether the TCP ACKs refer to data received via the SeNB, and/or independent from whether or not other uplink data is transmitted by the mobile node to the MeNB or SeNB.

(56) TCP acknowledgements are transmitted in the uplink for each TCP downlink data packet received by the UE. Usually, TCP acknowledgements are processed as exemplified in FIG. 7, thus being encapsulated in the IP layer and further by the PDCP layer as a PDCP PDU, etc. In order to force all TCP ACKs to be transmitted to the MeNB, the UE must detect these TCP ACKs (or at least those TCP ACKs that would otherwise be transmitted to the SeNB) and forward them over the appropriate logical channel to the MeNB (instead of to the SeNB). This may be achieved by the UE according to different implementations, some of which will be explained in the following.

(57) According to a first implementation, inter-layer notification(s) may be defined between the TCP and the PDCP layers, thus allowing the PDCP layer to identify the TCP ACKs and forward them to the appropriate RLC entity for further processing and transmission to the MeNB.

(58) Alternatively, the PDCP layer may detect the TCP ACKs directly, i.e., without any inter-layer notification from the above layers, based, e.g., on some implementation rules. For instance, usually TCP ACKs have a fixed PDCP PDU size, and may thus be distinguished from other PDCP PDUs. Alternatively, the TCP/IP header identifies the data to relate to a TCP ACK.

(59) These detection procedures may be performed by the PDCP layer before IP header compression.

(60) In any case, the UE shall be able to direct all the TCP ACKs to the appropriate lower layers, for transmission to the MeNB.

(61) As evidenced by simulation results, the TCP performance is directly related to the RTT (Round Trip Time)/delay. Thus, the downlink throughput would be optimized/increased when the TCP ACKs do not experience the additional X2 delay between the SeNB and the MeNB, and the TCP RTT is reduced.

(62) As mentioned before, this particular embodiment where all TCP ACKs are to transmitted to the MeNB, may be used in combination with any of the embodiments relating to the split ratio when calculating the BSR and when deactivating uplink transmission of PDCP data for a split bearer to one of the MeNB and SeNB. In these particular cases however, when the split bearer to the MeNB is deactivated (i.e., all traffic shall be offloaded to the SeNB), the TCP ACKs shall not be offloaded but shall be transmitted to the MeNB (even though they are actually processed by the PDCP layer). This would allow the offloading of traffic to the SeNB, which is nearer to the UE, but would at the same time enhance the TCP performance as explained above, by transmitting all TCP ACK to the MeNB.

(63) For said reason, TCP uplink ACKs shall be treated as an exception to the described procedure and must also be considered for the buffer status reporting.

(64) As explained for the above embodiment, when the ratio is 0:1 (i.e., all PDCP data is transmitted in the uplink to the SeNB, and the BSR is split by 0:1 with regard to the PDCP BO), the PDCP buffer occupancy for TCP ACKs shall be indeed considered for the BSR reporting; as an exception to the above-mentioned embodiment. In particular, any TCP ACKs occupying the PDCP buffer shall be reported to the MeNB in the corresponding BSR, but shall not be reported to the SeNB; TCP ACKs shall be thus treated differently from other data in the PDCP buffer, for which the split ratio shall indeed be applied. In other words, the split ratio, even when configured for the BSR reporting, shall not be applied to TCP ACKs in the PDCP buffer.

(65) Alternatively to the embodiment where the network determines the ratio, the fixed ratio could for example be derived by the UE itself, based on a variety of input parameters including one or more of the following but not limited to: Radio thresholds/HARQ re-transmissions (e.g., use a better radio link more than a poor radio link) History: Past grants received (higher grants received from a particular cell would lead to higher ratio in its favor)

(66) Generally, the UE's ratio derivation can be a function of these parameters such that a more favorable cell, for example, which gave more grants in the past time, such as 10/100/1000 ms, or which had a smaller HARQ operating point, receives a higher BSR/PBR ratio.

(67) The ratio could be informed to the network by UL RRC or MAC signalling, enabling the network node(s) to know how much buffer occupancy is being reported to the other node for the split-bearer.

(68) In addition, for the non-split-bearer(s) that is received/transmitted between the UE and only one of the Network Nodes, i.e., so to say the Single Connectivity bearer, the buffer occupancy of these could be reported to the ‘other node’. In other words, for instance, in FIG. 18, 110 and 133 Bytes could be reported to the other nodes (SeNB and MeNB respectively); this provides an indication to determine if the UE will have high/low resource allocation (for example >1 Mbps) from the other node. Accordingly, the MeNB/SeNB may schedule the UE to minimize conflicts while allocating the radio resources including and affecting UE transmission power.

(69) The buffer status is reported by a UE not per Logical Channel but for a Logical Channel Group. A Logical Channel Group may contain Logical Channel(s) for Split Bearer(s) as well as Logical Channel(s) for non-Split Bearer(s). The buffer status for Logical Channel(s) for non-Split Bearer(s) may be reported to only the corresponding eNB (i.e., Buffer Status for a non-Split Bearer towards MeNB should be reported to only MeNB; and similarly for SeNB). As a further enhancement, the buffer status for a non-Split Bearer towards MeNB may also be reported to SeNB and vice-versa. This will for example help the Master base station (MeNB) to determine how much scheduling the UE might receive in the next few subframes from the secondary base station, and accordingly the master base station may schedule the UE to minimize conflicts while allocating the radio resources. This could be for example helpful while estimating the UE's total transmit power requirement in the next few subframes. This enhancement can be accomplished by configuring (by the network towards the UE) and UE including in the Buffer Status Report 2 parts, one each for MeNB and SeNB.

(70) As for reporting BSR for Logical Channel(s) for Split Bearer(s): The Logical Channel for Split Bearer(s) should be configured as a separate Logical Channel Group, i.e., not including any Logical Channel(s) for Non-Split Bearer(s) in this group by the network. Mapping of bearers to a LCG should still be done in accordance to the priority of the bearers. Essentially only bearers of the same priority should be mapped into the same LCG. Therefore, if split Bearers have a different priority they should presumable end up in separate LCGs.

(71) So, buffer status for all the Logical Channel(s) for Split Bearer(s) can be reported together in a LCG of its own. This may require the network to configure more than 4 LCGs, as is (maximum 4 LCGs) currently the case. In this case, network may internally decide (using Xn interface) to serve the UE in a specified ratio.

(72) Or, alternatively, buffer status for the Logical Channel(s) for Split Bearer(s) may be computed for the UE as a whole (no segregation for MeNB/SeNB, i.e., such that all PDCP BO is reported) and reported to either/both of the eNB inside the corresponding LCG.

(73) In the case when reporting the BSR (e.g., for split-bearer) to only one of the Nodes, the UE could choose the node based on: History, such as HARQ re-transmissions, Previous allocations, etc., to maximize the use of the link that is more suitable according to the UE's UL channel condition and resource availability in that Node. The particular node could also be configured to be selected as part of network policy that might dictate that under following situations, the UE is supposed to choose a particular cell for BSR reporting: Radio Threshold, for instance, if DL RSRP, UL HARQ operating point, etc., are above a certain threshold then choose cell X for BSR reporting, buffer occupancy, for instance, if BO is less than a predetermined value Threshold1 then choose SeNB, Choose the Cell to send the BSR where a D-SR, dedicated SR on PUCCH. is configured, Some UE implementation way.

(74) As a possible enhancement, the UE can send the BSR to the other cell/link if the first cell/link did not provide much/any grant in a specified amount of time such as, after the expiry of N retxBSR-Timer; where N is an integer greater than or equal to 1; for instance, if the first cell provided less than 50% of the grants that the UE asked for.

(75) As yet another solution, the ratio values 0 (0:1), infinity (1:0), etc., could be used to switch off one of the links completely. For example, if the ratio 0 is signalled using the MAC signalling, then the UE will stop using the first link (e.g., MeNB) completely (corresponding split bearer or all the bearers depending on what the ratio denotes). Similarly, if the ratio infinity is signalled, then the UE will stop using the second link (e.g., SeNB).

(76) In a more detailed implementation, the split ratios of 0:1 and 1:0, already considered for the BSR calculation as explained above, may in addition or alternatively be used to deactivate the split bearer to either the MeNB or the SeNB for transmitting data from the shared PDCP entity in the uplink. For instance, in line with the BSR reporting when the PDCP BO is fully reported to the MeNB for a split ratio of 1:0, the bearer to the SeNB may be deactivated or suspended and thus not used for transmitting any uplink data, processed by the PDCP layer, to the SeNB. Conversely, in line with the BSR reporting when the PDCP BO is fully reported to the SeNB for a split ratio of 0:1, the bearer to the MeNB may be deactivated or suspended and thus not used for transmitting any uplink data, processed by the PDCP layer, to the MeNB.

(77) This has the advantage that the UE behavior is simplified for the LCP procedure for those split bearers, since bearer splitting thus effectively only occurs in the downlink. Since all the uplink data (except RLC data) goes only to one eNB, the UE does not need to determine how to split the PDCP buffer occupancy between the two eNBs.

(78) FIG. 19, which is similar to FIG. 16, exemplarily illustrates the deactivation of the bearer to Cell 2 (the SeNB), in that the shared PDCP layer (entity) forwards everything down to only the RLC layer entity for Cell 1 (i.e., towards MeNB). FIG. 20 depicts the case where the bearer towards the MeNB is deactivated, and thus the shared PDCP layer (entity) forwards everything down to only the RLC layer entity for Cell 2 (i.e., towards the SeNB).

(79) As already mentioned above, even if one of the links is configured to be disabled or suspended for uplink transmissions of PDCP data of a split bearer, this link is still used for transmitting RLC data of the split bearer, e.g., RLC STATUS PDUs, to the corresponding eNB. In other words, data that originates from the RLC entities may still be transmitted to the corresponding base station, independent from the split ratio and deactivation of a split bearer. Furthermore, MAC Control elements (MAC CEs) like BSR or PHR which are also transmitted in the uplink are not radio bearer specific data and hence are not in the scope of this present disclosure; they are further transmitted to the corresponding base station. As apparent from FIG. 19, data as generated by the lower layers of the PDCP (RLC, MAC) are still forwarded via Cell 2 to the SeNB.

(80) Optionally, A further exception relates to TCP acknowledgements, i.e., acknowledgments sent from the UE TCP layer in response to TCP downlink data received in the UE. As explained in a further embodiment, TCP Acknowledgements shall always be transmitted to one configured eNB, i.e., the MeNB, and thus in a split bearer case, TCP ACKs shall be forwarded from the PDCP layer to the corresponding lower layers so as to be further forwarded to the MeNB; this shall be the case even for TCP ACKs which relate to TCP downlink data received from the SeNB, and even for the above case, where all PDCP data (which includes the TCP ACKs processed by the PDCP layer) is supposed to be transmitted to the SeNB.

(81) This could, e.g., lead to the scenario where all data is offloaded to the SeNB, with at least the exception of having all TCP uplink ACKs being sent to the MeNB. According to another embodiment optionally, also PDCP status PDUs are sent always to one predefined eNB, e.g., MeNB in order to avoid the additional Xn delay. Similar to the TCP Acknowledgments, the PDCP entity would always forward a PDCP status report to the corresponding lower layers so as to be further transmitted to the MeNB independent from a split ratio or deactivation of a bearer. This could, e.g., lead to the scenario where all data is offloaded to the SeNB, with at least the exception of having all PDCP status PDUs being sent to the MeNB.

(82) The UE may be informed about the split ratio, and thus about which link of the split bearer to deactivate for the PDCP uplink data in various ways by the MeNB. As has been already explained in connection with the split ratio used in connection with the BSR calculation, the network may already indicate in the bearer configuration, whether the particular link should be used for transmitting the PDCP uplink data or not; i.e., whether the particular link should be deactivated with respect to transmitting PDCP uplink data. This may be done by a Radio Resource Control (RRC) message, e.g., by a radio resource configuration message.

(83) According to a first signalling implementation, a flag may be introduced for a logical channel associated to a split EPS bearer. The flag is thus indicating whether the UE should use the particular logical channel for transmitting the PDCP uplink data or not (and may additionally indicate whether to report PDCP data in a BSR for this logical channel or not). For instance, the flag may be included in the LogicalChannelConfig information element, defined in the standard 36.331 in a similar way as the logicalChannelSR-Mask Information Element (IE). Alternatively, the definition of the “data becoming available” in the technical standards TS 36.323, TS36.322 and TS 36.321 can be reused in said respect.

(84) According to a second signalling implementation, a new information element may be specified in either the MAC-MainConfig or DRB-ToAddMod (already standardized in TS36.331, thus indicating whether the UE should use the particular radio bearer or respectively logical channel for transmitting the PDCP uplink data or not (and may additionally indicate whether to report PDCP data for transmission on this radio bearer or logical channel or not).

(85) The above-described BSR derivation ratio could also be used to run the Logical Channel Prioritization procedure, e.g., by using the same, or a derived ratio to split the PBR (prioritisedBitRate). For example if a PBR of ‘kBps128’, i.e., 128 Bytes per TTI is allocated in the ratio 1:3, i.e., for each Byte on MeNB, SeNB gets 3, then the effective PBR on those links will be 32 and 96 respectively. With these derived PBRs, the LCP Procedure can be run in the 2 different MAC sub-layers, for corresponding 2 different cells/links, as defined in the Logical Channel Prioritization as defined in Section 5.4.3.1 of TS 36.321.

(86) However, if no fixed ratio approach has to be used, then another alternative would be to use a Virtual Bucket Approach. In this approach MAC-1, corresponding to cell/link1, can run the LCP as usual and update the satisfied PBR situation (defined “Bj” as in Section 5.4.3.1 of TS36.321, here incorporated by reference) of the split-bearer accordingly; the MAC-2, corresponding to cell/link2, can run the LCP as usual but taking for the split-bearer the new value (“Bj” as in Section 5.4.3.1 of TS36.321) updated by the MAC-1 accordingly.

(87) As to which MAC entity, for which link, should start to run the LCP procedure first, there can be several mechanisms. This could be left to UE implementation; for instance some UE implementation may always start with the SeNB, and others may always start with the MeNB; alternatively, other UE implementation may decide randomly, or based on the grant that was received earlier for one of the links.

(88) In one possible example, if most for instance more than 50% of the grant was provided by a particular eNB, then the UE can start with this eNB's grant. As a further option the UE could toggle the first MAC (cell/link) based on a similar criteria or could even be configured by the network, for instance by starting with the cell (BO occupancy corresponding to this cell) which has less unhappiness in terms of less aggregated data to be transmitted, etc. The Unhappiness can be calculated by aggregating the unsatisfied PBR and/or the remaining amount of the data in the buffer. Further, in the MAC entity selected this way, the highest priority Bearer's unhappiness can be minimized first by allocating the extra grants to it and then going on to the lower priority unhappy bearers sequentially.

(89) As an alternative solution to when no fixed ratio approach has to be used, the network could configure the division in time, such as in TDM fashion, of when which MAC will run the LCP considering the split bearer(s). The other MAC does not consider this split bearer(s) for these time slots but otherwise run the LCP normally for all other bearer(s).

(90) As a further alternative solution to when no fixed ratio approach has to be used, more Steps could be added to the procedure described in Section 5.4.3.1 of 3GPP TS36.321 such that first CP is run normally in both the MAC entities and then one of the MAC that has highest unhappiness tries to reduce the unhappiness by taking off the allocations to the split bearer such that a Negative Bj, if any, of the split bearer just gets back to 0. These grants are then distributed to other bearer(s) if their Bj was still positive, else (or if the grant was still remaining) allocating the grant to other high priority bearers, starting with the highest priority bearer that has still any data in its buffer such that the highest priority Bearer's unhappiness can be minimized first by allocating the extra grants to it and then going on to the lower priority unhappy bearers sequentially.

(91) In the following, further alternative approaches will be disclosed.

(92) As a yet another alternative solution to when no fixed ratio approach has to be used, the grants from all the cell/link could be aggregated as one grant, and then the LCP procedure could be run such that the sum of the so far allocated grant to the logical channels in a cell does not exceed the grant that was coming from that cell, and, when this happens, the LCP procedure shall allocate grant to the remaining Logical Channel of the other MAC-cell.

(93) As yet another alternative for Logical Channel Prioritization, the network (RRC) could configure the split-bearer as two separate configurations, corresponding to two different cells, in the UE such that the PBR (prioritisedBitRate) or other parameters that RRC controls for the scheduling of uplink data by signalling for each logical channel has different values for each PBR (prioritisedBitRate) or other parameters that RRC controls for the scheduling of uplink data.

(94) Thereafter, each MAC entity in the UE may run its LCP independently. What values of such parameter could be configured might be a decision similar to “ratio” derivation that was described above. As an implementation option the UE could also configure itself in this similar manner, that is, configure internally the split-bearer as two separate configurations.

(95) Further, putting the different UL Scheduling procedures together can be done such that these not only share, for example, the ratio but also the trigger. This could for example happen when one of the cell goes down (like meets RLF or cannot be used for a similar reason), then the UE should report the BSR, PHR assuming no transmission for the bad link and change the ratio (that is used to work out the BSR, LCP and even PHR) such that it is clear to the receiving network node that the other link is down and/or that it needs to/can provide a higher grant (power, physical resources) to the UE and also initiate a subsequent necessary procedure including the mobility of the UE to some other cell using, e.g., the Handover Procedure. In this cell a change of one situation like Power (PHR report) may subsequently trigger the other reports like BSR, and also the UL logical channel prioritization should also account for these changes such that a split-bearer does not suffer/suffers minimally in the transmission. So, whenever RLF happens, the UE could signal using special reporting (implicitly or explicitly) in one of these reports/procedure that RLF has happened, and then the network could initiate some kind of recovery mechanism.

(96) In the following a further embodiment of the present disclosure will be described according to which the Logical Channel Prioritization procedure considers the split bearer, and particularly the split buffer status reporting as introduced in any of the previous embodiments.

(97) According to one of the previous embodiments, the PDCP buffer for the split bearer (e.g., LC2 in FIG. 18) is shared between the radio bearer to the MeNB and the radio bearer to the SeNB. This may lead to a waste of uplink grant during the LCP procedure as will be exemplified by the following scenario.

(98) The UE is assumed to be configured with an eNB-specific bearer RB1, mapped only to the MeNB, and with a “split bearer” RB2, mapped both to the MeNB and the SeNB. Additionally, BSR reporting for the split bearer RB2 shall be configured with a ratio of 0.4 to 0.6. Assuming that 100 bytes of (PDCP) data arrive for both bearer simultaneously, the UE would correspondingly send a first BSR1 with 140 bytes (100 bytes+0.4*100 bytes) to the MeNB, and a second BSR2 with 60 bytes (0.6*100 bytes) to the SeNB.

(99) First, the UE is scheduled with a grant of 140 bytes from the MeNB. Provided the Logical Channel priority of RB2 is higher than priority of RB1 and when performing the common LCP procedure for a split bearer as described in the embodiment above, the UE sends 100 bytes of data via RB2 towards MeNB, and 40 bytes of data via RB1 towards MeNB. Later, the UE receives another grant of 60 bytes from the SeNB. However, there is no data left for any bearers mapped towards the SeNB, and the UE may not use the grant from the SeNB for data towards the MeNB. Thus, the UE sends padding bytes to the SeNB, and the data of RB1 pending for uplink transmission towards MeNB waits in the UE buffer, until the MeNB receives new information on the buffer status, e.g., via a periodic BSR. As apparent, the present LCP procedure is inefficient when implementing the embodiments where the PDCP buffer occupancy is split and only a split PDCP BO is reported to the eNBs.

(100) According to this further embodiment, the LCP procedure is adapted to consider that only part of the PDCP BO is reported to the two eNBs. In particular, at least the first and third steps of the LCP procedure would be specified in a similar manner as follows:

(101) Step 1: All the logical channels with Bj>0 are allocated resources in a decreasing priority order. If the PBR of a radio bearer is set to “infinity”, the UE shall allocated resources for all the data that is available for transmissions on the radio bearer before meeting the PBR of the lower priority radio bearer(s), but only up to a maximum of the buffer occupancy reported to the base station;

(102) Step 2: if any resources remain, all the logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the reported data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels with equal priority should be served equally.

(103) Therefore, when performing the two LPC procedures (one for each direction of the split bearer, towards the MeNB and SeNB), in the above mentioned scenario a waste of resources is avoided. In this example, When receiving the first grant of 140 bytes from the MeNB, instead of serving resources for sending all 100 bytes of data of the RB2 to MeNB, only 40 bytes are transmitted by the UE via RB2 to the MeNB, since only 40 bytes were reported with the BSR1 regarding the RB2. Out of the remaining 100 bytes of this first grant from the MeNB, 100 bytes are spent to transmit the 100 bytes of data waiting for RB1 towards the MeNB. Then, when receiving to the second grant of 60 bytes from the SeNB, the remaining 60 bytes waiting for RB2 are transmitted using a corresponding amount of resources from this second grant.

(104) For the case that one radio bearer or logical channel of a split bearer is deactivated or suspended for UL transmission of PDCP data, the LCP procedure will only consider data in the RLC entity of this disabled/suspended logical channel but no data available in the PDCP entity for this disabled/suspended logical channel.

(105) According to another further embodiment, the LCP procedure for split bearers considers a virtual PDCP buffer for each of the link/bearers the split bearer is using in the uplink. Since the PDCP entity is shared between the two RLC/MAC entities in the case of a split bearer as shown in FIG. 16, the UE is creating a virtual PDCP buffer/entity for each of the cells which are used in LCP procedure in the two MAC entities. The PDCP buffer occupancy of a virtual PDCP entity/buffer is calculated by the PDCP buffer occupancy of the shared PDCP entity multiplied with the configured split ratio. For example, in case the PDCP buffer occupancy of the shared PDCP entity is 100 bytes at one time instance and the configured split ratio is 0.4 to 0.6, then BO of the virtual PDCP buffer/entity for Cell 1 (towards MeNB) is 40 bytes whereas the BO of the virtual PDCP buffer/entity of cell (towards SeNB) is 60 bytes. The advantage of the virtual PDCP buffer/entities is that the normal LCP operations can be done for a split bearer as described in above embodiment.

(106) In the following, a further embodiment of the present disclosure will be explained. It is assumed that a split bearer is present, i.e., an EPS bearer is split across MeNB and SeNB. However, it is yet unspecified how the triggering of the BSR by the MAC entities will be handled by the UE. When data arrives in the buffers of the split bearer and a BSR is triggered in MAC entity (be it MAC-MeNB or MAC-SeNB), the other MAC entity (MAC-SeNB or MAC-MeNB) might not be triggered.

(107) According to a first option, the BSR trigger in one of the MAC entities for the split bearer is indeed not propagated to the other MAC entity. Rather, the one MAC entity shall report the BSR to its corresponding base station, while the other MAC entity shall report the BSR when triggered itself (e.g., by arrival of data, or by a periodic BSR trigger). The corresponding split-ratios can be considered for the respective calculation of the two BSR. In this case, the reporting by the two MAC entities of the split bearer is completely independent, which facilitates implementation.

(108) According to a second option, the BSR trigger in one of the MAC entities (be it MAC-MeNB or MAC-SeNB) is propagated to the other MAC entity, such that this other MAC entity will also internally trigger the BSR; effectively, the MAC entities of the split bearer will always be triggered together to report the BSR and thus two buffer status reports are to be transmitted, one to the MeNB and one to the SeNB. However, depending on how the uplink resources for the BSR reporting are scheduled, the two transmissions of BSR are likely to happen at different times in the two cells. Therefore, the buffer occupancy of the split bearer might have changed, i.e., new data could arrive in the buffer between the two transmission time instances, which leads to problems on how to handle such situations, especially with regard to the later BSR report.

(109) This embodiment thus also deals with the question of how the two BSR are to be calculated with respect to each other, and different options are possible, four of which will be explained in greater detail. T0 shall be the time at which the two MAC entities are triggered for BSR reporting; T1 shall be the time at which the first BSR is scheduled to be transmitted (be it the BSR-MeNB, or the BSR-SeNB); correspondingly, T2 shall be the time at which the second BSR is scheduled to be transmitted (be it the BSR-SeNB or the BSR-MeNB).

(110) According to a first calculation option, both of the BSR are calculated based on the buffer occupancy at either T0 (i.e., when the BSR are triggered) or at T1 (i.e., when the first one is to be transmitted). The split-ratio can be respectively applied for the calculation of the two BSRs. UE needs to store the PDCP buffer occupancy at T0 or T1 in order to perform the calculation of BSR at T2.

(111) According to a second calculation option, the first-timed BSR is calculated with the buffer occupancy at either T0 or T1, and then transmitted as scheduled at T1. Then, the second-timed BSR is calculated to be the buffer occupancy at time T2, minus what was already reported by the first-time BSR; i.e., equal to BO_T2-reported_BO_T1/0. Thus, although at time T0 or T1, the split ratio can be applied to this firstly-timed BSR, for the secondly-timed BSR the split-ratio shall not be applied, since the value of this secondly-timed BSR reflects the difference of the BO at T2 vis-a-vis the reported BO at time T1 or T0. The advantage of this second calculation option is that the entire buffer occupancy is reported to eNBs.

(112) According to a third calculation option, the two BSRs are calculated independently from each other at basically the corresponding times when they are transmitted. Thus, the firstly-timed BSR is calculated based on the BO at time T1, while the secondly-timed BSR is calculated based on the BO at time T2. Again, in both cases the split-ratio may be applied respectively, as explained in one of the various embodiments discussed before. This option has the advantage that the BSR reporting procedure can be performed independently in the two MAC entities which is preferable from implementation point of view.

(113) According to a fourth calculation option, the firstly-timed BSR (e.g., for the MeNB) is calculated at time T1 based on the BO at time T1 (with use of the corresponding split ratio). Furthermore, at time T1 also the value for the other BSR (e.g., for the SeNB) is calculated based on the BO at time T1 (with use of the corresponding split ratio); however, this one is not transmitted but merely stored for later use. In particular, at time T2 the UE shall calculate a BSR based on the newly-arrived data (i.e., data arrived between T1 and T2) (also applying the split ratio accordingly), and add this to the stored value of the BSR (e.g., for the SeNB) as calculated at time T1. The thus resulting value is then reported at T2, as scheduled.

(114) The differences of these four options will be illustrated according to the following exemplary scenario. It is assumed, that the buffer status at T0 and T1 is 100 bytes. New data of 200 bytes is supposed to arrive between T1 and T2. A split ratio of 0.3 to 0.7 for MeNB to SeNB is defined. At time T1 the BSR for the MeNB is scheduled; at time T2 the BSR for the SeNB is scheduled.

(115) TABLE-US-00002 TABLE 2 BO reported at T1 BO reported at T2 Option 1 30 (0.3 * 100)  70 (0.7 * 100) Option 2 30 (0.3 * 100) 270 (300 − 30) Option 3 30 (0.3 * 100) 210 (0.7 * 300) Option 4 30 (0.3 * 100) 210 ((0.7 * 200) + 70)

(116) This present disclosure further looks into the aspect of transporting the Signalling Radio Bearer (RRC Signalling messages) between the MeNB and UE RRC using the Layer 2 scheduling/Transport of UE-SeNB link.

(117) In Normal circumstances for Signalling Radio Bearer (RRC Signalling messages) Layer 2 transport only RRC->PDCP->RLC-M->MAC-M might be sufficient; but we need to have the other possibility of RRC->PDCP->RLC-S->MAC-S for the same SRB at some special conditions like when the MeNB would want to have RRC Diversity (i.e., sent the RRC message via both MeNB and SeNB links so as to ensure that the UE receives the RRC Signalling message through at least one link) or when the Radio Link has failed towards one of the eNBs and the UE may want to send a reporting message to report the situation (including Measurements) to the RRC in MeNB (via the available MeNB or SeNB link).

(118) Layer 2 transports of SRBs, in the DL, from the UE's perspective would mean that the UE needs to be configured for receiving some SRBs from SeNB as well. Since MAC-S will anyway be available (corresponding to SeNB), the only further configuration required would be likely for RLC-S. If the RLC-S configuration would be exactly the same as RLC-M, then UE implementation can ensure that SRB packets are delivered to RRC by both MAC-M and MAC-S similarly, e.g., by having a SAP (Service Access Point) between the MAC-S and RLC-M; this enhanced implementation aspect works such that this SAP is always available or alternatively, the network should activate this SAP (or configure/activate RLC-S) when it intends to send a DL RRC message via the SeNB L2 transport. UE implementation “can” ensure that SRB packets are delivered to RRC by L2 of MAC-M and MAC-S entities by having always a dedicated SAP between them. However, in one further alternative network may specifically control when the SRB from the SeNB L2 will be delivered by way of MAC or RRC level signalling (thereby sort of activating this link between the MAC-M and MAC-S entities).

(119) In the UL however, since in normal circumstances, the RRC packets should not be unnecessarily duplicated and sent across 2 different links but only upon special conditions (using same/different RRC transaction identifiers) whereby RRC/PDCP can trigger/activate this in the lower layer and later come back to 1 link SRB transmission. This can be done by UE RRC when it needs to: respond to a RRC Signalling message that was received on SeNB L2 link initiate a RRC Signalling message on SeNB L2 link when MeNB L2 link is not available due to Radio Link failure initiate a RRC Signalling message on MeNB L2 link when SeNB L2 link is not available due to Radio Link failure a critical information needs to be sent in the Uplink

(120) For the above enhancements related to SRB delivery via the L2 SeNB link, the network may need to configure relevant parameters in UE RRC and lower layers and enable MAC signalling when required. This network configuration may allow the duplication of RRC messages on the L2 SeNB link, use of MAC/RRC signalling for this purpose and even configure the scenarios where this new UE behavior would be required.

(121) Hardware and Software Implementation of the Present Disclosure

(122) Another embodiment of the present disclosure relates to the implementation of the above described various embodiments using hardware and software. In this connection the present disclosure provides a user equipment (mobile terminal) and eNodeBs (master and secondary base station). The user equipment is adapted to perform the methods described herein.

(123) It is further recognized that the various embodiments of the present disclosure may be implemented or performed using computing devices (processors). A computing device or processor may for example be general purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, etc. The various embodiments of the present disclosure may also be performed or embodied by a combination of these devices.

(124) Further, the various embodiments of the present disclosure may also be implemented by means of software modules, which are executed by a processor or directly in hardware. Also a combination of software modules and a hardware implementation may be possible. The software modules may be stored on any kind of computer readable storage media, for example RAM, EPROM, EEPROM, flash memory, registers, hard disks, CD-ROM, DVD, etc.

(125) It should be further noted that the individual features of the different embodiments of the present disclosure may individually or in arbitrary combination be subject matter to another present disclosure.

(126) It would be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present disclosure as shown in the specific embodiments without departing from the spirit or scope of the present disclosure as broadly described. The present embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.