5G/NR - Split Bearer                                           Home : www.sharetechnote.com

 

 

 

 

As mentioned in deployment Scenario page,  NR can be deployed in many different forms. Especially at the early stage of NR deployment, it is highly likely that NR is deployed as a supplimentary note (i.e, SN (Secondary Node)) to LTE (MN (Master Node)). This type of deployment is called NSA (Non-StandAlone) deployment. In this case, there are several different ways to constuct a bearer as 37.340 - 4.2.2 states :

    'In MR-DC, from a UE perspective, three bearer types exist: MCG bearer, SCG bearer and split bearer. These three bearer types are depicted in Figure 4.2.2-1 for MR-DC with EPC (EN-DC) and in Figure 4.2.2-2 for MR-DC with 5GC (NGEN-DC, NE-DC).

 

In this page, I will explain only on a specfic type of bearer mentioned above called 'Split Bearer' since it may be a kind of confusing concept.

 

 

 

Which Bearer ? Which Split ?

 

The term 'SplitBearer' can be confusing because the two keywords 'Bearer' and 'Split' would be confusing terms. Do let's clarify on these two keywords first.

 

First, let's think of what kind of Bearer are defined. In case of LTE, roughly several different types of Bearer are defined as shown below (I would not describe any detailed on each of these bearers here). Just as a conclusion, when we say 'SplitBearer', the Bearer in this case is more related to the last one. More accurate location of bearer split will be explained later.

 

 

 

In short, when we say SplitBearer. The bearer would mean 'Radio Beaer'. Then the question is exactely at which point in Radio Bearer the 'Split' happens. Technically you can split the radio bearer at various different way as indicated by dotted lines as shown below. Just as a conclusion, the Split in SplitBearer mean the split marked in Red Dotted line. The split indicated by Blue dotted lines are called 'Separation'. You can see a example of this separation in CU/DU Separation.

 

 

 

 

SplitBearer Usecase in deployment scenario

 

Typical situation where SplitBearer can be used in terms of network deployment plan is < Case 4 > and < Case 6 > as shown below. Especially at early stage of NR deployment called NSA, < Case 4 > would be the most typical deplyment scenario.  However, it doesn't mean that < Case 4 >, <Case 6 > always use split bearer. It can use MCG bearer only, SCG Bearer only or MCG and SCG separately. SplitBearer is only an option among many different options for these deployment scenario.

 

 

 

 

Exact Point of Split in Radio Bearer

 

Now let's look more in details on what's happening inside the radio bearer with split bearer. Following is the illustration highlighting the data path of splitbearer based on 37.340 - Figure 4.2.2-3 and Figure 4.2.2-1. Following through the solid red arrows and lines, you would read out followings :

  • In splitbearer, NR PDCP is used both in LTE Anchor and NR.
  • Splitting of data stream is done by PDCP

 

 

 

Now getting further into details, let's think of exactly at which point within PDCP the split happens. According to 38.323  4.2.2   PDCP entities, it is stated as follows :

    For split bearers, routing is performed in the transmitting PDCP entity.

In 3GPP NR Specification, not so much details are explained about SplitBearer mechanism. For now, you may get a little bit more detailed idea from LTE specification described in 36.323 4.2.2 PDCP entities. This is the specification for LTE Dual Connectivity (not NR splitbearer) but I think similar idea would apply to NR split bearer as well.

 

Based on this, the point of the bearer split within PDCP can be highlighted as shown below.  

 

 

 

 

Would SplitBearer can confuse RLC ?

 

A couple of weeks ago I had a chat with my friend about this splitbearer and there was a question that I couldn't answer clearly at the moment. Putting it in simple way, the question was what would happen when SplitBearer was supported in downlink only and not supported in Uplink. As of now, I haven't confirmed on 3GPP specification whether only one directional SplitBearer (downlink only or Uplink only) is supported or not, but I think we can think of this case at least conceptually.

At first, we thought there might be some confusion in UL RLC on UE side when DL is configured for SplitBearer but UL is not configured for SplitBearer. However, putting some more thought on this, I realized that there wouldn't be such a confusion.

There was a situation brought up. When network sent data using splitbearer, meaning that both NR RLC and LTE RLC is transmitting the data to UE, how UE can get the RLC ACK to each of the corresponding network ? We got confused because we assumed that UE will have only one RLC path when SplitBearer is configured for downlink only (as shown in < Case 3 >. But come to think of it, it doesn't seem to be right. Even if the SplitBearer is configured for downlink only, UE should still handle two RLC stream (both in LTE and NR) in recieving side as shown in < Case 1>. Donwlink only SplitBearer mean that both UE and Network have data path in < Case 1 > and  Uplink will have the data path as in < Case 2 >. The data path like < Case 3 > would not exist.

 

 

< Case 1 : Split Bearer >

 

 

< Case 2 : Non-Split Bearer >

 

 

< Case 3 : Is this possible ? >

 

 

 

How the throuput gets split ?

 

Before I talk about 'How', let me ask 'Who is going to split the data ?' Is it UE or NW ? Obviously it is UE. It means that the decision making for the split is done on UE side. It may sound obvious, but I often forgot about the simple fact and get confused about the split process.  

There are several factors configured by RRC to affect on the decision making on split as shown below.

 

  moreThanOneRLC SEQUENCE {

        primaryPath SEQUENCE {

            cellGroup              CellGroupId               OPTIONAL, -- Need R

            logicalChannel         LogicalChannelIdentity    OPTIONAL -- Need R

        },

        ul-DataSplitThreshold      UL-DataSplitThreshold     OPTIONAL, -- Cond SplitBearer

        pdcp-Duplication                                     BOOLEAN OPTIONAL -- Need R

    } OPTIONAL, -- Cond MoreThanOneRLC

 

 UL-DataSplitThreshold ::= ENUMERATED {

    b0, b100, b200, b400, b800, b1600, b3200, b6400, b12800, b25600, b51200, b102400, b204800,

    b409600, b819200, b1228800, b1638400, b2457600, b3276800, b4096000, b4915200, b5734400,

    b6553600, infinity, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}

 

Overall procedure may go like this :

    i) pick a logical channel specified by LogicalChannelIdentity specified by RRC

    ii) estimate how much data the UE has to transmit (this process is tightly related to the data volumn calculation in BSR process)

    iii) Based on the estimated data volumn, UE need to determine whether it need split or not. The criteria of this decision is configured by ul-DataSplitThreshold in Rrc. If the estimated data volumn is less than the threshold it does not split and if the data volumn is greater than the threshold it need to split.

    iiii) Once it is decided to split the data, now it has to determine how much portions of the data to be transmitted through each cell. This is determined by cellGroup in Rrc.

    • If the cellGroup is set to 0 which means MCG (indicating LTE in ENDC), the amount of data upto ul-DataSplitThreshold is transmitted through LTE and the remaining data is going through NR cell.
    • If the cellGroup is set to 1 which means SCG (indicating NR in ENDC), the amount of data upto ul-DataSplitThreshold is transmitted through NR and the remaining data is going through LTE cell

    Sound simple, but there are two confusing parameters in ul-DataSplitThreshod. They are b0 and Infinity. If b0 is set, It does not mean 'no split'. It indicates UE determine the split ratio by its own algorithm. If Infinity is set, UE send 100% of the data via the cell specified in cellGroup.

    NOTE : I mentioned that the split is determined by UE. But UL Grant (Physical layer UL scheduling) is done by Network (RAN). Then you may ask .. 'how UE can make RAN to provide UL Grant as per the split decision ?'. It is done by BSR.  Simply put, once split is determined, UE send BSRs to LTE and NR based on the split ratio.

 

 

Following is formal description of split mechanism described in 3GPP.

 

38.323-5.2.1 states : (I am always struggling this kind of pseudo-code style description WITHOUT BRACKET.. easily lose track while reading -:).  The part highlighed red would be about SplitBearer operation.

 

When submitting a PDCP PDU to lower layer, the transmitting PDCP entity shall:

    if the transmitting PDCP entity is associated with one RLC entity:

      submit the PDCP PDU to the associated RLC entity;

    else, if the transmitting PDCP entity is associated with at least two RLC entities:

      if the PDCP duplication is activated for the RB:

        if the PDCP PDU is a PDCP Data PDU:

          duplicate the PDCP Data PDU and submit the PDCP Data PDU to the associated RLC entities activated for PDCP duplication;

      else:

        submit the PDCP Control PDU to the primary RLC entity;

      else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer):

        if the split secondary RLC entity is configured; and

        if the total amount of PDCP data volume and RLC data volume pending for initial transmission (as specified in TS 38.322) in the primary RLC entity and the split secondary RLC entity is equal to or

        larger than ul-DataSplitThreshold:

          submit the PDCP PDU to either the primary RLC entity or the split secondary RLC entity;

        else, if the transmitting PDCP entity is associated with the DAPS bearer:

          if the uplink data switching has not been requested:

            submit the PDCP PDU to the RLC entity associated with the source cell;

          else:

            if the PDCP PDU is a PDCP Data PDU:

              submit the PDCP Data PDU to the RLC entity associated with the target cell;

            else:

              if the PDCP Control PDU is associated with source cell:

                submit the PDCP Control PDU to the RLC entity associated with the source cell;

              else:

                submit the PDCP Control PDU to the RLC entity associated with the target cell;

      else:

        submit the PDCP PDU to the primary RLC entity

 

Now let go to 38.322 and see what happen.. (It would be more appreciated if 3GPP TS authors put section/chapter number as well when they referring to other document -:). For this part, I would suggest you to look into the note on BSR rather than putting those details in this note.

 

 

 

RRC Parameters

 

 

PDCP-Config ::= SEQUENCE {

    drb SEQUENCE {

        discardTimer ENUMERATED {ms10, ms20, ms30, ms40, ms50, ms60, ms75, ms100, ms150, ms200,

                            ms250, ms300, ms500, ms750, ms1500, infinity} OPTIONAL, --Cond Setup

        pdcp-SN-SizeUL ENUMERATED {len12bits, len18bits} OPTIONAL, -- Cond Setup2

        pdcp-SN-SizeDL ENUMERATED {len12bits, len18bits} OPTIONAL, -- Cond Setup2

        headerCompression CHOICE {

        notUsed NULL,

        rohc SEQUENCE {

            maxCID INTEGER (1..16383) DEFAULT 15,

            profiles SEQUENCE {

                profile0x0001 BOOLEAN,

                profile0x0002 BOOLEAN,

                profile0x0003 BOOLEAN,

                profile0x0004 BOOLEAN,

                profile0x0006 BOOLEAN,

                profile0x0101 BOOLEAN,

                profile0x0102 BOOLEAN,

                profile0x0103 BOOLEAN,

                profile0x0104 BOOLEAN

            },

            drb-ContinueROHC ENUMERATED { true } OPTIONAL -- Need N

        },

        uplinkOnlyROHC SEQUENCE {

            maxCID INTEGER (1..16383) DEFAULT 15,

            profiles SEQUENCE {

                profile0x0006 BOOLEAN

            },

            drb-ContinueROHC ENUMERATED { true } OPTIONAL -- Need N

            },

        ...

        },

        integrityProtection ENUMERATED { enabled } OPTIONAL, -- Cond ConnectedTo5GC

        statusReportRequired ENUMERATED { true } OPTIONAL, -- Cond Rlc-AM

        outOfOrderDelivery ENUMERATED { true } OPTIONAL -- Need R

    } OPTIONAL, -- Cond DRB

    moreThanOneRLC SEQUENCE {

        primaryPath SEQUENCE {

            cellGroup              CellGroupId               OPTIONAL, -- Need R

            logicalChannel         LogicalChannelIdentity    OPTIONAL -- Need R

        },

        ul-DataSplitThreshold      UL-DataSplitThreshold     OPTIONAL, -- Cond SplitBearer

        pdcp-Duplication                                     BOOLEAN OPTIONAL -- Need R

    } OPTIONAL, -- Cond MoreThanOneRLC

    t-Reordering ENUMERATED {

                        ms0, ms1, ms2, ms4, ms5, ms8, ms10, ms15, ms20, ms30, ms40,

                        ms50, ms60, ms80, ms100, ms120, ms140, ms160, ms180, ms200, ms220,

                        ms240, ms260, ms280, ms300, ms500, ms750, ms1000, ms1250,

                        ms1500, ms1750, ms2000, ms2250, ms2500, ms2750,

                        ms3000, spare28, spare27, spare26, spare25, spare24,

                        spare23, spare22, spare21, spare20,

                        spare19, spare18, spare17, spare16, spare15, spare14,

                        spare13, spare12, spare11, spare10, spare09,

                        spare08, spare07, spare06, spare05, spare04, spare03,

                        spare02, spare01 } OPTIONAL, -- Need S

    ...,

    [[

    cipheringDisabled ENUMERATED {true} OPTIONAL -- Cond ConnectedTo5GC

    ]]

}

 

UL-DataSplitThreshold ::= ENUMERATED {

    b0, b100, b200, b400, b800, b1600, b3200, b6400, b12800, b25600, b51200, b102400, b204800,

    b409600, b819200, b1228800, b1638400, b2457600, b3276800, b4096000, b4915200, b5734400,

    b6553600, infinity, spare8, spare7, spare6, spare5, spare4, spare3, spare2, spare1}

 

 

RLC-BearerConfig ::= SEQUENCE {

        logicalChannelIdentity              LogicalChannelIdentity,

        servedRadioBearer     CHOICE {

                srb-Identity     SRB-Identity,

                drb-Identity     DRB-Identity

    }     OPTIONAL, -- Cond LCH-SetupOnly

    reestablishRLC     ENUMERATED {true} OPTIONAL, -- Need N

    rlc-Config         RLC-Config OPTIONAL, -- Cond LCH-Setup

    mac-LogicalChannelConfig     LogicalChannelConfig OPTIONAL, -- Cond LCH-Setup

...

}

 

 

CellGroupId : The IE CellGroupId is used to identify a cell group. 0 identifies the master cell group. Other values identify secondary cell groups. In Jun 2018 Specification, only values 0 and 1 are supported.

 

LogicalChannelIdentity : LogicalChannelIdentity is used to identify one logical channel (LogicalChannelConfig) and the corresponding RLC bearer (RLC-BearerConfig).

 

ul-DataSplitThreshold : Indicates the threshold value for uplink data split operation specified in TS 36.323. Value b100 means 100 Bytes, b200 means 200 Bytes and so on. E-UTRAN only configures this field for split DRBs.