5G Stuff: Dual Connectivity basics and various User plane (UP) and Control plane (C or CP) options (part 2)

User Plane (UP) Bearer split options for DC

From the previous post part 1, the below are the 3 options

Option 1: S1-U also terminates in SeNB;

Option 2: S1-U terminates in MeNB, no bearer split in RAN;

Option 3: S1-U terminates in MeNB, bearer split in RAN.

Bearer Split options

For S1-U termination at the MeNB, the protocol stack in the SeNB is at least required to support (re-)segmentation due to the non-ideal back haul used and the (re-)segmentation must take place in the same node as the one transmitting the RLC PDUs. Based on this assumption, four families of U-plane alternatives emerge: 

A. Independent PDCPs

B. Master-Slave PDCPs

C. Independent RLCs


D. Master-Slave RLCs

Based on the options for bearer split and U-plane protocol stack above, we obtain the following alternatives:

-     1A: S1-U terminates in SeNB + independent PDCPs (no bearer split);

-     2A: S1-U terminates in MeNB + no bearer split in MeNB + independent PDCP at SeNB;

-     2B: S1-U terminates in MeNB + no bearer split in MeNB + master-slave PDCPs;

-     2C: S1-U terminates in MeNB + no bearer split in MeNB + independent RLC at SeNB;

-     2D: S1-U terminates in MeNB + no bearer split in MeNB + master-slave RLCs;

-     3A: S1-U terminates in MeNB + bearer split in MeNB + independent PDCPs for split bearers;

-     3B: S1-U terminates in MeNB + bearer split in MeNB + master-slave PDCPs for split bearers;

-     3C: S1-U terminates in MeNB + bearer split in MeNB + independent RLCs for split bearers;

-     3D: S1-U terminates in MeNB + bearer split in MeNB + master-slave RLCs for split bearers.

Out of all the above alternative 1A and 3C are considered due to the flexibility and advantages they have in the implementation (based on the Table 8.1.1.11-1 from 3GPP TR 36842).

UP 1A:

The expected benefits of this alternative are:

-     no need for MeNB to buffer or process packets for an EPS bearer transmitted by the SeNB;

-     little or no impact to PDCP/RLC and GTP-U/UDP/IP;

-     no need to route all traffic to MeNB, low requirements on the backhaul link between MeNB and SeNB and no flow control needed between the two;

-     support of local break-out and content caching at SeNB straightforward for dual connectivity UEs.

The expected drawbacks of this alternative are:

-     SeNB mobility visible to CN;

-     offloading needs to be performed by MME and cannot be very dynamic;

-     security impacts due to ciphering being required in both MeNB and SeNB;

-     utilisation of radio resources across MeNB and SeNB for the same bearer not possible;

-     for the bearers handled by SeNB, handover-like interruption at SeNB change with forwarding between SeNBs;

-     in the uplink, logical channel prioritisation impacts for the transmission of uplink data (radio resource allocation is restricted to the eNB where the Radio Bearer terminates).

UP 3C:

The expected benefits of this alternative are:

-     SeNB mobility hidden to CN;

-     no security impacts with ciphering being required in MeNB only;

-     no data forwarding between SeNBs required at SeNB change;

-     offloads RLC processing of SeNB traffic from MeNB to SeNB;

-     little or no impacts to RLC;

-     utilisation of radio resources across MeNB and SeNB for the same bearer possible;

-     relaxed requirements for SeNB mobility (MeNB can be used in the meantime).

The expected drawbacks of this alternative are:

-     need to route, process and buffer all dual connectivity traffic in MeNB;

-     PDCP to become responsible for routing PDCP PDUs towards eNBs for transmission and reordering them for reception;

-     flow control required between MeNB and SeNB;

-     in the uplink, logical channel prioritisation impacts for handling RLC retransmissions and RLC Status PDUs (restricted to the eNB where the corresponding RLC entity resides);

-     no support of local break-out and content caching at SeNB for dual connectivity UEs.

As per 8.1.2, there is no requirement to have co-ordination between eNBs for PRACH resource and any eNB can respond for PRACH when there is no overlap with Random access preamble transmission. It is required in SeNB addition/modification procedure.

From the UE power consumption point of view, DRX co-ordination is beneficial and expected to have separate DRX timers and active time for MeNB and SeNB.

UE side MAC entity is configured per Cell Group, i.e., one MAC for MCG and another one for SCG.

Control Plane (CP) for DC

In dual connectivity operation, a UE always stays in a single RRC state, i.e., either RRC_CONNECTED or RRC_IDLE. With this principle, the main two architecture alternatives for RRC are the following:

Option C1: Only the MeNB generates the final RRC messages to be sent towards the UE after the coordination of RRM functions between MeNB and SeNB. The UE RRC entity sees all messages coming only from one entity (in the MeNB) and the UE only replies back to that entity.

L2 transport of these messages depends on the chosen UP architecture and the intended solution.

Option C2: MeNB and SeNB can generate final RRC messages to be sent towards the UE after the coordination of RRM functions between MeNB and SeNB and may send those directly to the UE (depending on L2 architecture) and the UE replies accordingly. How and whether to distinguish source and destination RRC entity are FFS. How to route UL messages is FFS. L2 transport of these messages depends on the chosen UP architecture and the intended solution.

Based on the performance comparison C1 is selected as baseline to support the following qualities.

Configuration delay

Synchronization of RRC parameter change

Signalling and processing overload

Complexity in the UE side

Complexity in the NW side