4G/LTE - LCG

 

 

 

LCG(Logical Channel Group)

 

With just a little modification of 3GPP description, LCG can be defined as "A group of Logical Channel which buffer status is being reported." There are four LCGs being used in LTE and each of the group has it's own ID from 0 to 3. You can see how this LCG ID is being used in BSR (Buffer Status Report)

Where a Logical Channel Group Sits

A group is not a message and not a procedure. It is a label attached to a logical channel by one optional field, and everything else about the group follows from which channels carry that label.

Each uplink logical channel carries a LogicalChannelConfig, and that structure holds the priority, the prioritised bit rate, the bucket size duration and the logical channel group. The first three govern how the channel is served. The last one says nothing about service. It only says which channels are counted together. Figure 1 follows a small configuration from the radio bearer through to the group.

Radio bearer Uplink logical channel Logical channel group SRB1 SRB2 DRB 1 DRB 2 DCCH, logical channel 1 DCCH, logical channel 2 DTCH, logical channel 3 DTCH, logical channel 4 no group LCG 0 LCG 1 LCG 2 LCG 3 A logical channel with no logicalChannelGroup belongs to no group, and 36.321 clause 5.4.5 never counts it. Each group reports at most one Buffer Size value per TTI, so the group is the unit the report counts.

Figure 1. One optional field decides the whole picture. SRB1 and SRB2 take group 0 from the 36.331 default configurations, and the two data radio bearers are an example. A channel with no logicalChannelGroup sits outside every group and is never counted.

36.331 clause 9.2.1.1 and clause 9.2.1.2 put SRB1 and SRB2 in group 0 by default, so signalling is already grouped before any data bearer is added. A data radio bearer takes whatever logicalChannelGroup the reconfiguration gives it, and the capture on this page puts logicalChannelIdentity 3 in group 2. The field is optional with Need OR, so a channel can be left out of every group.

The network never learns the per channel figures. 36.321 clause 5.4.5 allows each group at most one buffer status value per TTI, so four channels in one group arrive as a single number. Splitting them across groups gives separate numbers, and the report grows to carry them.

  • A group is a label on a logical channel : logicalChannelGroup in LogicalChannelConfig is the only field that puts a channel in one.
  • SRB1 and SRB2 start in group 0 : 36.331 clause 9.2.1.1 and clause 9.2.1.2 set that value in the default configurations.
  • A channel can belong to no group : the field is optional with Need OR, and 36.321 clause 5.4.5 then never counts that channel.
  • One group reports one number : 36.321 clause 5.4.5 allows each group at most one buffer status value per TTI.
  • Grouping is an uplink property and nothing else : 36.331 describes the field as the mapping of a logical channel to a group for BSR reporting, and it sits under ul-SpecificParameters.

Why There Are Four Groups

The page above gives the count without the reason, and the reason is a field width. Four is not a design preference. It is what two bits hold, and those two bits sit in a MAC control element rather than in any RRC message.

36.321 clause 6.1.3.1 defines that field. The Logical Channel Group ID field identifies the group of logical channels whose buffer status is being reported, and the length of the field is 2 bits. Four values fit, so four groups exist. The definition quoted at the top of this page is the same clause, almost word for word.

The same clause shows the other half of the arithmetic. A Short BSR and a Truncated BSR each carry one LCG ID field and one Buffer Size field, and those two fields fill a single octet. A Long BSR drops the identifier and carries four Buffer Size fields instead, one for each of LCG 0 to 3. Position names the group there, so no identifier is needed. Figure 2 draws both layouts at the same scale, following 36.321 Figure 6.1.3.1-1 and Figure 6.1.3.1-2.

Short BSR and Truncated BSR, one octet LCG ID 2 bits Buffer Size 6 bits Oct 1 Long BSR, three octets Buffer Size #0 6 bits Buffer Size #1 first 2 bits Oct 1 Buffer Size #1 last 4 bits Buffer Size #2 first 4 bits Oct 2 Buffer Size #2 last 2 bits Buffer Size #3 6 bits Oct 3 The Long BSR carries no LCG ID field. Position names the group, and two of the fields cross an octet boundary.

Figure 2. The Short BSR and the Truncated BSR share the one octet layout, and the Long BSR uses the other. Two bits go to an LCG ID in the short forms, and that is what holds the design to four groups. The long form recovers those bits by letting position carry the group number.

Four fields of 6 bits come to 24 bits, so the Long BSR occupies three octets. Those fields do not align with the octets. Figure 2 shows Buffer Size #1 split across the first octet and the second, and Buffer Size #2 split across the second and the third. A reader decoding one of these by hand therefore counts in 6 bit steps rather than in bytes.

The Buffer Size field is 6 bits, and it carries an index rather than a byte count. 36.321 Table 6.1.3.1-1 maps the 64 values onto byte ranges, and Table 6.1.3.1-2 replaces that table when extendedBSR-Sizes is configured. The value reported covers every logical channel in the group, counted after the MAC PDUs for the TTI have been built, with the RLC and MAC headers left out.

  • Four groups because the field is two bits : 36.321 clause 6.1.3.1 fixes the LCG ID field at that length.
  • A Long BSR carries no identifier : its four Buffer Size fields stand for LCG 0 to 3 in order, so position does the naming.
  • The Long BSR is three octets : four fields of 6 bits make 24 bits, and two of those fields straddle an octet boundary.
  • The buffer size is an index, not a byte count : 6 bits into 36.321 Table 6.1.3.1-1, or Table 6.1.3.1-2 when extendedBSR-Sizes is configured.
  • Headers are not counted : the figure covers RLC and PDCP data only, measured once the TTI's MAC PDUs are built.
  • NB-IoT uses a single group : 36.321 sets the LCG ID to 0 there and does not support the Long BSR.

LCG in the DRB Configuration

The LCG is usually used in the DRB settings as shown below. (The most common place for DRB setting is in RRC Connection Reconfiguration message). Refer to 6.3.2 Radio resource control information elements of TS36.331

RRC Connection Reconfiguration, the DRB-ToAddMod branch, decoded as a tree, capture. The values are what one network sent, not what the specification requires.

              | +-drb-ToAddModList ::= SEQUENCE OF SIZE(1..maxDRB[11]) [1] OPTIONAL:Exist
              | | +-DRB-ToAddMod ::= SEQUENCE [11111]
              | |   +-eps-BearerIdentity ::= INTEGER (0..15) [5] OPTIONAL:Exist
              | |   +-drb-Identity ::= INTEGER (1..32) [1]
              | |   +-pdcp-Config ::= SEQUENCE [101] OPTIONAL:Exist
              | |   | +-discardTimer ::= ENUMERATED [infinity] OPTIONAL:Exist
              | |   | +-rlc-AM ::= SEQUENCE OPTIONAL:Omit
              | |   | +-rlc-UM ::= SEQUENCE OPTIONAL:Exist
              | |   | | +-pdcp-SN-Size ::= ENUMERATED [len12bits]
              | |   | +-headerCompression ::= CHOICE [notUsed]
              | |   |   +-notUsed ::= NULL
              | |   +-rlc-Config ::= CHOICE [um-Bi-Directional] OPTIONAL:Exist
              | |   | +-um-Bi-Directional ::= SEQUENCE
              | |   |   +-ul-UM-RLC ::= SEQUENCE
              | |   |   | +-sn-FieldLength ::= ENUMERATED [size10]
              | |   |   +-dl-UM-RLC ::= SEQUENCE
              | |   |     +-sn-FieldLength ::= ENUMERATED [size10]
              | |   |     +-t-Reordering ::= ENUMERATED [ms50]
              | |   +-logicalChannelIdentity ::= INTEGER (3..10) [3] OPTIONAL:Exist
              | |   +-logicalChannelConfig ::= SEQUENCE [1] OPTIONAL:Exist
              | |     +-ul-SpecificParameters ::= SEQUENCE [1] OPTIONAL:Exist
              | |       +-priority ::= INTEGER (1..16) [13]
              | |       +-prioritisedBitRate ::= ENUMERATED [infinity]
              | |       +-bucketSizeDuration ::= ENUMERATED [ms100]
              | |       +-logicalChannelGroup ::= INTEGER (0..3) [2] OPTIONAL:Exist
  • One line in the box names a group : logicalChannelGroup reads 2, from the range 0 to 3.
  • It sits under ul-SpecificParameters : the group is an uplink property, so the branch that holds it is the uplink one.
  • The same branch carries the priority and the bucket : priority 13, prioritisedBitRate infinity, and bucketSizeDuration ms100.
  • The logical channel identity is a separate field : logicalChannelIdentity reads 3, and it names the channel rather than the group.
  • This bearer is UM in both directions : rlc-Config takes um-Bi-Directional, with a 10 bit sequence number each way and t-Reordering of 50 ms.

36.331 v19.3.0 still gives logicalChannelGroup the range 0 to 3, and still marks it optional with Need OR. That optionality matters more than it looks. 36.321 clause 5.4.5 triggers a buffer status report when data arrives for a logical channel which belongs to a LCG, so a logical channel left without a group never triggers one.

The prioritised bit rate in the box is the other field to read carefully. 36.321 clause 5.4.3.1 covers the infinity setting. The MAC entity then allocates resources for all the data available on that channel, before it meets the PBR of any lower priority channel. Priority 13 is low on a scale where 1 is highest, so this bearer drains ahead of channels 14 to 16 and behind everything above it.

  • A logical channel without a group triggers no BSR : 36.321 clause 5.4.5 counts only the channels that belong to one.
  • The range has not changed : 36.331 v19.3.0 still gives logicalChannelGroup the values 0 to 3.
  • The group is an uplink idea throughout : configured under ul-SpecificParameters, reported in an uplink MAC control element.
  • Infinity is a setting, not an omission : 36.321 clause 5.4.3.1 hands that channel everything it has before any lower priority channel reaches its own rate.

How the Group Reaches the Network

Grouping matters at one moment only, which is the moment a report is sent. The grouping then decides which of three report formats goes out, and that decision is made per TTI rather than once at configuration time.

36.321 clause 5.4.5 lists four things that start a report. Uplink data becomes available for a logical channel that belongs to a group. Padding in an allocated grant grows large enough to hold the control element and its subheader. The retxBSR-Timer expires with data still waiting. The periodicBSR-Timer expires. The clause names the second a Padding BSR, the third a Regular BSR and the fourth a Periodic BSR.

The format then follows from the grouping. For a Regular or a Periodic BSR the clause reports a Long BSR when more than one group has data in the TTI carrying the report, and a Short BSR otherwise. Grouping therefore sets the size of the report. Put every bearer in one group and every regular report is short.

Padding has a rule of its own. The spare bits may fit a Short BSR and its subheader but not a Long one. If more than one group has data at that moment, the UE sends a Truncated BSR for the group holding the highest priority logical channel with data waiting. Spare bits enough for a Long BSR bring a Long BSR instead. Figure 3 sets the two rules side by side.

Regular BSR or Periodic BSR Padding BSR More than one LCG has data in that TTI Long BSR Only one LCG has data in that TTI Short BSR Padding holds a Long BSR and its subheader Long BSR Padding holds only a Short BSR, and more than one LCG has data Truncated BSR Padding holds only a Short BSR, and one LCG has data Short BSR A Truncated BSR reports the group holding the highest priority logical channel with data waiting.

Figure 3. How 36.321 clause 5.4.5 picks the report format. Grouping settles the question on the left, and the size of the padding settles it on the right. One configuration can therefore produce a one octet report in one TTI and a three octet report in the next.

  • One group with data means a Short BSR : 36.321 clause 5.4.5 reports Long only when more than one group has data in that TTI.
  • Grouping sets the report size : collapsing the bearers into one group makes every regular report short.
  • Padding chooses between all three formats : Short, Truncated or Long, decided by how many bits are spare.
  • A Truncated BSR names one group : the one holding the highest priority logical channel with data waiting.
  • Four triggers feed three formats : data arrival, padding, the retxBSR-Timer and the periodicBSR-Timer.

Reference

Two specifications carry everything above. The RRC one says where the group is configured, and the MAC one says what the group is for and how many of them there can be.

[1] 36.331 : 3GPP - E-UTRA; Radio Resource Control, v19.3.0. LogicalChannelConfig holds logicalChannelGroup, with the range 0 to 3 and a Need OR optionality.

[2] 36.321 : 3GPP - E-UTRA; Medium Access Control, v19.3.0. Clause 6.1.3.1 gives the BSR control elements and the two field widths, clause 5.4.5 the triggers and the format rule, and clause 5.4.3.1 the meaning of a prioritised bit rate of infinity.