|
|
||
|
Split Bearer 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 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.
The term 'SplitBearer' can be confusing because the two keywords 'Bearer' and 'Split' would be confusing terms. 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. In practice, < Case 4 > is the most common depolyment method when we deploy LTE and NR in dual carrier mode.
Exact Point of Split in Radio BearerNow 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 :
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 : 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. As you see here, the split and routing happens in UE PDCP (ENDC case)
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. 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. 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): 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 ... }
|
||
