The functionality of BSR in NR is exactly sa the LTE BSR. For the BSR functionality, refer to LTE BSR page. The dfference is the structure of MAC CE and the length of Buffer Size Bit field. It is understandable that the length of the BSR bit field in NR would be longer than LTE BSR. Another difference is that NR BSR has explcit bit field for LCG as shown below whereas LTE BSR specifies LCG implcitely.

Simply put, Buffer Status Report (BSR) is a message from UE to eNB (MAC layer command) saying 'I have this amount of data to send would you give grants big enough to transmit all of these data ?"

As a formal definition, 38.321-5.4.5 states as follows :

The Buffer Status reporting (BSR) procedure is used to provide the serving gNB with information about UL data volume in the MAC entity.

Followings are the topics to be convered in this note.

• Parameters for BSR and Overall Operation
• Data Structure of BSR MAC CE
• Selection of BSR Type
• RRC Parameters for BSR
• What triggers a BSR ?
• What happens when a BSR is triggered but there is no grant ?
• What is a Logical Channel Group, and why are there eight ?
• What did Release 16 add for BSR ?

Parameters for BSR and Overall Operation

In order to send BSR, the first thing UE has to do is to estimate how much data it has to transmit. This process is called 'Data Volumn Calculation'.  The data volumn to transmit is based on how much data is in RLC and PDCP. Regarding RLC layer data volumn calculation, there are several factors to be used to calculate the data volumn as listed below (based on 38.322-5.5)

• RLC SDUs and RLC SDU segments that have not yet been included in an RLC data PDU;
• RLC data PDUs that are pending for initial transmission;
• RLC data PDUs that are pending for retransmission (RLC AM).

Regarding PDCP layer data volumn calculation, there are also factors to be used to calculate the data volumn as listed below (based on 38.322-5.5)

• the PDCP SDUs for which no PDCP Data PDUs have been constructed;
• the PDCP Data PDUs that have not been submitted to lower layers;
• the PDCP Control PDUs;
• for AM DRBs, the PDCP SDUs to be retransmitted according to 38.322-5.1.2;
• for AM DRBs, the PDCP Data PDUs to be retransmitted according to 38.322-5.5.

Once Data Volumn Calculation is done, UE need to determine exactly when it needs to send BSR and for which logical channel it wants to send. There are multiple parameters affecting this decision making. According to 38.321-5.4.5, those parameters are as follows :

• periodicBSR-Timer;
• retxBSR-Timer;
• logicalChannelSR-DelayTimerApplied;
• logicalChannelSR-DelayTimer;
• logicalChannelSR-Mask;
• logicalChannelGroup.

These parameters can be configured by Rrc message.

Data Structure of BSR MAC CE

Short BSR is a format for a Short Buffer Status Report (BSR). These reports are used to inform the network about the status of data buffers in the User Equipment (UE). The following diagram outlines the structure of these reports, which include fields for the Logical Channel Group ID (LCG ID) and Buffer Size.

The LCG ID is used to identify which group of logical channels the report pertains to, and the Buffer Size field indicates the amount of data waiting to be transmitted.

<  38.321-Figure 6.1.3.1-1: Short BSR and Short Truncated BSR MAC CE >

Folliwng diagram displays a format for a Long Buffer Status Report (BSR) and Long Truncated BSR in the context of MAC in a cellular communication system. This extended version of the BSR includes multiple Logical Channel Group IDs (LCG0 to LCG7), each corresponding to a different group of logical channels. For each LCG ID, there is a corresponding Buffer Size field (Buffer Size 1 to Buffer Size m) that indicates the volume of data queued for each logical channel group.

<  38.321-Figure 6.1.3.1-2: Long BSR and Long Truncated BSR MAC CE >

Following table shows a table listing buffer size levels for a 5-bit Buffer Size field in bytes, which is used for the short BSR. Each entry in the table corresponds to an index value that can be sent in the Buffer Status Report (BSR) from a UE to inform the network of the amount of data that is buffered and ready to be transmitted.

The table is divided into 32 index values (from 0 to 31), as 5 bits can represent 32 different states. Each index has a corresponding Buffer Size (BS) value, which is the maximum number of bytes that the UE's buffer can hold for that index value. For example, an index of 0 corresponds to a BS value of 0 bytes, indicating an empty buffer, while an index of 31 indicates a BS value greater than 150,000 bytes, which corresponds to the largest buffer size represented in this table.

The buffer size values increase non-linearly, with smaller increments at lower index values and larger increments at higher index values. This allows for finer granularity in reporting small amounts of data and coarser granularity for larger volumes, optimizing the reporting process for different traffic conditions and data requirements.

<  38.321-Table 6.1.3.1-1: Buffer size levels (in bytes) for 5-bit Buffer Size field >

Following table shows buffer size levels for an 8-bit Buffer Size field in bytes which is used in long BSR MAC CE. With 8 bits, there are 256 possible index values (0 to 255), and each index corresponds to a Buffer Size (BS) value. This table serves a similar purpose to the 5-bit table shown above but allows for much finer granularity in reporting the size of the UE's data buffer to the network. The BS values range from 0 bytes to well over 8 million bytes, increasing non-linearly with the index. The larger the index value, the larger the range of data that can be represented, which reflects a more precise buffer status as the buffer size increases.

<  38.321-Table 6.1.3.1-2: Buffer size levels (in bytes) for 8-bit Buffer Size field >

Selection of BSR Type

From the UE side, what type of BSR it should use when it is supposed to send a BSR ? It is described in 38.321-5.4.5. It is pretty long (confusing to me) statement. It would be summarized as follows (I hope I didn't get mixed up).

RRC Parameters for BSR

BSR-Config is short enough that I assumed I was looking at an excerpt the first time. It is the whole thing. RRC sets three timers for BSR, and everything else about the procedure is fixed in TS 38.321.

The nesting is worth noticing before the fields are. BSR-Config is not configured on its own. It hangs off MAC-CellGroupConfig, which is configured per cell group. A UE with a master and a secondary cell group therefore carries two independent BSR configurations.

Each of the three timers maps onto behaviour described elsewhere on this page. The periodicBSR-Timer field drives the Periodic trigger. The retxBSR-Timer field drives one of the Regular triggers. The logicalChannelSR-DelayTimer field delays the Scheduling Request that a Regular BSR raises. Each one is described in turn after the definitions.

MAC-CellGroupConfig ::= SEQUENCE {

   drx-Config                   SetupRelease { DRX-Config } OPTIONAL, -- Need M

   schedulingRequestConfig      SchedulingRequestConfig OPTIONAL, -- Need M

   bsr-Config                   BSR-Config OPTIONAL, -- Need M

   tag-Config                   TAG-Config OPTIONAL, -- Need M

   phr-Config                   SetupRelease { PHR-Config } OPTIONAL, -- Need M

   skipUplinkTxDynamic          BOOLEAN,

   ...,

   [[

   csi-Mask         BOOLEAN   OPTIONAL, -- Need M

   dataInactivityTimer   SetupRelease { DataInactivityTimer }   OPTIONAL -- Cond MCG-Only

   ]],

   [[

   usePreBSR-r16   ENUMERATED {true}   OPTIONAL, -- Need R

   schedulingRequestID-LBT-SCell-r16   SchedulingRequestId   OPTIONAL, -- Need R

   lch-BasedPrioritization-r16   ENUMERATED {enabled}   OPTIONAL, -- Need R

   schedulingRequestID-BFR-SCell-r16   SchedulingRequestId   OPTIONAL, -- Need R

   drx-ConfigSecondaryGroup-r16   SetupRelease { DRX-ConfigSecondaryGroup-r16 }   OPTIONAL -- Need M

   ]],

   [[

   enhancedSkipUplinkTxDynamic-r16   ENUMERATED {true}   OPTIONAL, -- Need R

   enhancedSkipUplinkTxConfigured-r16   ENUMERATED {true}   OPTIONAL -- Need R

   ]],

   [[

   intraCG-Prioritization-r17   ENUMERATED {enabled}   OPTIONAL, -- Cond LCH-PrioWithReTxTimer

   drx-ConfigSL-r17   SetupRelease { DRX-ConfigSL-r17 }   OPTIONAL, -- Need M

   drx-ConfigExt-v1700   SetupRelease { DRX-ConfigExt-v1700 }   OPTIONAL, -- Need M

   schedulingRequestID-BFR-r17   SchedulingRequestId   OPTIONAL, -- Need R

   schedulingRequestID-BFR2-r17   SchedulingRequestId   OPTIONAL, -- Need R

   schedulingRequestConfig-v1700   SchedulingRequestConfig-v1700   OPTIONAL, -- Need M

   tar-Config-r17   SetupRelease { TAR-Config-r17 }   OPTIONAL, -- Need M

   g-RNTI-ConfigToAddModList-r17   SEQUENCE (SIZE (1..maxG-RNTI-r17)) OF MBS-RNTI-SpecificConfig-r17   OPTIONAL, -- Need N

   g-RNTI-ConfigToReleaseList-r17   SEQUENCE (SIZE (1..maxG-RNTI-r17)) OF MBS-RNTI-SpecificConfigId-r17   OPTIONAL, -- Need N

   g-CS-RNTI-ConfigToAddModList-r17   SEQUENCE (SIZE (1..maxG-CS-RNTI-r17)) OF MBS-RNTI-SpecificConfig-r17   OPTIONAL, -- Need N

   g-CS-RNTI-ConfigToReleaseList-r17   SEQUENCE (SIZE (1..maxG-CS-RNTI-r17)) OF MBS-RNTI-SpecificConfigId-r17   OPTIONAL, -- Need N

   allowCSI-SRS-Tx-MulticastDRX-Active-r17   BOOLEAN   OPTIONAL -- Need M

   ]],

   [[

   schedulingRequestID-PosMG-Request-r17   SchedulingRequestId   OPTIONAL, -- Need R

   drx-LastTransmissionUL-r17   ENUMERATED {enabled}   OPTIONAL -- Need R

   ]],

   [[

   posMG-Request-r17   ENUMERATED {enabled}   OPTIONAL -- Need R

   ]]

}

NOTE : this is the Release 17 form of the information element. Three of its fields affect uplink reporting and scheduling. The bsr-Config field holds the BSR timers. The usePreBSR-r16 field enables the pre-emptive BSR. The lch-BasedPrioritization-r16 field governs the choice between a configured grant and a dynamic grant. The remaining extension groups cover DRX, multicast and positioning.

NOTE : the Release 15 group is csi-Mask and dataInactivityTimer, without a version suffix, and dataInactivityTimer carries the condition Cond MCG-Only.

BSR-Config ::= SEQUENCE {

   periodicBSR-Timer              ENUMERATED { sf1, sf5, sf10, sf16, sf20, sf32, sf40, sf64,

                                               sf80, sf128, sf160, sf320, sf640, sf1280,

                                               sf2560, infinity },

   retxBSR-Timer                  ENUMERATED { sf10, sf20, sf40, sf80, sf160, sf320, sf640,

                                               sf1280, sf2560,sf5120, sf10240, spare5, spare4,

                                               spare3, spare2, spare1},

   logicalChannelSR-DelayTimer    ENUMERATED { sf20, sf40, sf64, sf128, sf512, sf1024,

                                               sf2560, spare1} OPTIONAL, -- Need R

...

}

periodicBSR-Timer: This timer controls how frequently the UE sends a Periodic BSR. The ENUMERATED values represent predefined time intervals, with 'sf' standing for subframes. For example, 'sf10' would mean 10 subframes, and each subframe is 1ms, so 'sf10' would be 10ms. The value 'infinity' indicates that the periodic BSR is effectively disabled, and the UE will not send periodic BSRs unless triggered by other events.

retxBSR-Timer: This is the retransmission timer for BSRs. If the UE has sent a BSR and does not receive a resource allocation in response within the duration specified by this timer, it will retransmit the BSR. The time values are similar to the periodicBSR-Timer, with additional longer intervals, like 'sf5120' (5120 subframes) and 'sf10240' (10240 subframes). The 'spare' values are reserved for future use or special functions not currently specified.

logicalChannelSR-DelayTimer: This optional timer defines a delay before the UE sends a Scheduling Request (SR) after it has data to transmit. This timer is only applicable if logicalChannelSR-DelayTimerApplied(this is in LogicalChannelConfig IE) is set to true for a particular logical channel. The values follow a similar subframe-based timing, with 'sf20' being 20 subframes, and so on. The 'spare1' value is reserved

What triggers a BSR ?

Selection of BSR Type answers which of the four formats the UE sends. It does not answer why the UE is sending one at all. Those are two different questions, and TS 38.321 keeps them separate.

There are three triggers, and the specification names them.

Keeping the trigger apart from the format is worth the effort when reading a log. A Short BSR tells you one LCG had data. It does not tell you why. New high priority data, an expired timer, and spare room in an existing grant all produce the same octet.

One asymmetry matters more than the others. Only a Regular BSR can lead to a Scheduling Request. A Periodic or Padding BSR is sent in a grant the UE already holds, so there is nothing to ask for. The next section follows what happens when a Regular BSR has no grant to travel in.

• Three triggers, four formats : The trigger says why a BSR is sent, and the format says how it is encoded. They are chosen independently.
• Regular BSR is the event-driven one : Higher priority data arriving, or data arriving into an empty buffer, or retxBSR-Timer expiring.
• Periodic BSR is the timer-driven one : It refreshes the gNB's view while data keeps flowing.
• Padding BSR is free : It fills space in a grant that would otherwise be padding, so the UE takes the opportunity.
• Only a Regular BSR can trigger an SR : The other two travel in a grant the UE already has.

What happens when a BSR is triggered but there is no grant ?

A BSR is a MAC CE. Like every MAC CE it travels inside a transport block, and a transport block needs an uplink grant. That produces a problem worth stating plainly. The message whose job is to ask for a grant cannot be sent without one.

NR solves it with a smaller signal that needs no grant at all. If a Regular BSR is triggered and no uplink resource is available, the UE triggers a Scheduling Request instead. An SR is a single bit on PUCCH. It carries no buffer size and no LCG, and it says only that the UE wants a grant.

The gNB answers with a grant, and the BSR then travels in that grant with the detail the SR could not carry. The two signals work as a pair, and the order is always the same.

There is a third step for the case where even the SR cannot be sent. If no valid PUCCH resource for SR is configured on any serving cell, the UE falls back to random access. The same fallback applies when SR transmissions reach sr-TransMax without producing a grant.

Figure 1 follows the whole ladder.

Figure 1. The BSR says how much data there is. The Scheduling Request only says that there is some, which is why it is the fallback rather than the main channel.

• A BSR cannot ask for its own grant : It is a MAC CE, so it needs a transport block, so it needs a grant already.
• The Scheduling Request is the way out : One bit on PUCCH, needing no grant, saying only that the UE wants one.
• The pair is ordered : SR asks for a grant, the grant arrives, and the BSR then travels in it with the numbers.
• Random access is the last resort : It applies when no SR resource is configured, and when SR reaches sr-TransMax.
• Only Regular BSRs enter this flow : Periodic and Padding BSRs already have a grant to sit in.

What is a Logical Channel Group, and why are there eight ?

A BSR does not report per logical channel. It reports per Logical Channel Group, and understanding why explains the shape of both BSR formats.

A UE can have many logical channels open at once. Reporting a buffer size for every one of them would make the BSR large. It would also repeat itself, because channels of similar priority tend to be served together. So each logical channel is assigned to a group by the logicalChannelGroup parameter, and the BSR reports one buffer size per group.

NR allows eight groups, numbered 0 to 7. The number follows directly from the field width. A Short BSR carries a 3-bit LCG ID, and three bits address eight values. LTE used a 2-bit field and therefore had four groups, which is the main reason an NR BSR is not the same size as an LTE one.

The Long BSR handles multiple groups with a bitmap rather than a list of identities. Its first octet has one bit per group, and a Buffer Size octet follows for each bit that is set. A UE with one active group sends two octets, and a UE with all eight active sends nine.

The grouping is a configuration decision with a real cost either way. Putting every logical channel in its own group gives the scheduler precise information and a larger BSR. Putting them all in one group gives a two-octet report that says nothing about which traffic is waiting.

Figure 2. The bitmap is what lets a Long BSR stay short. A UE with one active group pays two octets, not nine.

• BSR reports per group, not per channel : logicalChannelGroup assigns each logical channel to one of the groups.
• Eight groups because the field is three bits : LTE had four, with a two-bit field.
• The Long BSR uses a bitmap : One bit per group in the first octet, then one Buffer Size octet per bit that is set.
• A Long BSR is 2 to 9 octets : Its size follows the number of groups with data, not the number of groups configured.
• Grouping trades detail against overhead : One group per channel is precise and large, and one group for everything is small and blind.

What did Release 16 add for BSR ?

The BSR MAC CE formats and BSR-Config have not changed since Release 15. What Release 16 added sits beside them, in MAC-CellGroupConfig, and it is easy to miss because it is a single field.

That field is usePreBSR-r16, and it enables the pre-emptive BSR. An ordinary BSR reports data the UE already holds. A pre-emptive BSR reports data the sender expects to receive but has not received yet.

The motivation is IAB. An IAB node relays traffic, so data arriving from its children will shortly need a grant from its parent. Waiting for that data to arrive before reporting it would add a request and grant round trip at every hop. Those delays add rather than divide. A pre-emptive BSR lets the node ask its parent in advance, so the grant is already in place when the data arrives.

Two further Release 16 fields in the same information element affect uplink scheduling without being BSR fields. One is lch-BasedPrioritization-r16, which lets the UE prioritise between a configured grant and a dynamic grant. The other is schedulingRequestID-LBT-SCell-r16, which gives a dedicated Scheduling Request identity for listen-before-talk failure on an SCell.

Release 17 added more groups to the same information element, covering DRX, multicast, positioning and sidelink. None of them changes how a BSR is built or reported. The ASN.1 in RRC Parameters for BSR now shows all of these groups, so the BSR fields can be seen in their real context.

• BSR-Config is unchanged since Release 15 : The three timers it holds are the same ones Release 15 defined.
• usePreBSR-r16 is the Release 16 addition : It enables a report about data that has not arrived yet.
• The pre-emptive BSR exists for IAB : It removes one request and grant round trip per hop from the relayed path.
• Release 17 touched the container, not the BSR : The new groups in MAC-CellGroupConfig cover DRX, multicast, positioning and sidelink.

Reference

[1]