BSR is a kind of MAC CE from UE to Network carrying the information on how much data is in UE buffer to be sent out. Putting it another way, it is a kind of MAC layer message from UE to Network (eNodeB) saying "I have something to transmit, would you give me a Grant to send this data ?" Then Network would allocate the bare minimum amount of UL Grant (Resources for PUSCH) if the resource is available. With this mechanism, network can optimize UL resources based on following logics.

• Allocate UL resources (UL Grant) only when UE has something to transmit
• Avoid allocating too much UL resources (more than what UE needs) which lead to waste of resources.

(For the details, refer to TS 36.321 5.4.5 Buffer Status Reporting. Also refer to the MAC PDU anaysis examples in MAC_LTE)

• How is a BSR laid out, and what is an LCG?
• How can six bits describe the whole uplink buffer?
• When does the UE decide to send a BSR?
• Triggers for BSR transmission
• When to send Long BSR and When to send Short BSR

How is a BSR laid out, and what is an LCG?

A BSR has to say two things at once. It has to say how much data is waiting, and it has to say which kind of traffic that data belongs to. The second half is what the LCG field is for, so let's settle what an LCG is before reading the two formats. That also explains why a Long BSR carries exactly four buffer sizes, and why a Short BSR carries only one.

LCG stands for Logical Channel Group, and a UE has exactly four of them. RRC assigns every uplink logical channel to one group, through the logicalChannelGroup field in LogicalChannelConfig, which takes a value from 0 to 3. The UE then reports one buffer size per group rather than one per logical channel. That is a deliberate compromise. A per-channel report would be more precise. But a UE can hold many logical channels at once, and the whole report has to fit into a MAC control element of one or three octets.

Grouping also matches what a scheduler actually needs. The eNB does not need to know that 12 bytes are waiting in DRB3 and 40 bytes in DRB5. It needs to know how much of the waiting data is delay sensitive and how much can wait, and four groups carry that.

There are several types of BSR and we can classify these in terms of data structure and BSR timing.

In terms of data structure of BSR, there are two types. One is Short BSR and the other is Long BSR. The structure is as follows. With short BSR, UE can inform the amount of data in UL buffer only for one specific LCG (Logical Channel Group). That's why you see 'LCG ID' field at the beginning of Short BSR. With long BSR, UE can inform the UL buffer information for all LCG. That's why you don't see any specifc LCG ID field in Long BSR but you have multiple 'Buffer Size' field, each of which represent one LCG.

< 36.321 - Figure 6.1.3.1-1: Short BSR and Truncated BSR MAC control element >

< 36.321 - Figure 6.1.3.1-2: Long BSR MAC control element >

Buffer Size #0 is BSR index for LCG 0

Buffer Size #1 is BSR index for LCG 1

Buffer Size #2 is BSR index for LCG 2

Buffer Size #3 is BSR index for LCG 3

Those four lines are the whole of the mapping, and Figure 1 draws the same thing from the other end. It starts at the logical channels the UE actually has, and it follows them through the groups into the Buffer Size fields above.

Figure 1. Logical channels are grouped before they are reported. RRC puts every uplink logical channel into one of four LCGs, and the BSR then carries one buffer size per group rather than one per channel. The mapping drawn here is a typical one, not a fixed one, because the network chooses it.

• Left column : the uplink logical channels the UE has configured. SRB1 and SRB2 carry RRC signalling, and the DRBs carry user data.
• Middle column : the four LCGs. Two bits are enough to name one of them, which is exactly the width of the LCG ID field in a Short BSR.
• Right column : the Buffer Size fields of a Long BSR. Field #0 reports LCG 0, field #1 reports LCG 1, and so on down to field #3.
• The two sets of arrows mean different things : the left ones are configuration and change only when RRC reconfigures the UE. The right ones are the report itself, and the UE recomputes them every time it builds a BSR.

Look at those two figures once more before reading further. They carry two details that matter later, and both are easy to miss.

• A Short BSR is exactly one octet : 2 bits of LCG ID and 6 bits of Buffer Size fill it with nothing left over. Add the MAC subheader in front of it and one Short BSR costs two octets of the grant.
• A Long BSR is three octets and carries no LCG ID : four 6 bit fields make 24 bits, which leaves no room for one. None is needed, because the position of each field already names its group.
• The Long BSR fields do not line up with the octets : 36.321 Figure 6.1.3.1-2 draws Buffer Size #1 split across Oct 1 and Oct 2. It draws Buffer Size #2 split across Oct 2 and Oct 3. A decoder has to read the three octets as one 24 bit string rather than octet by octet.
• The title of 36.321 Figure 6.1.3.1-1 names two formats : a Truncated BSR has the same one octet layout as a Short BSR. Only the LCID in the MAC subheader separates them, which is why the specification draws both with one picture.

The three formats sit side by side in the table below. The last column is the part a log reader needs, because the UE picks the format from its own state rather than from anything the network asked for.

• An LCG is the unit of reporting : the UE never reports a single logical channel. It adds up the data waiting in every channel of a group and reports that one number.
• The number of groups with data picks the format : one group gives a Short BSR and more than one gives a Long BSR. Padding changes that rule, and the last section on this page covers how.
• Three formats, but only two layouts : Short and Truncated BSR share one octet and one field layout. Long BSR is the only different shape on the air.

How can six bits describe the whole uplink buffer?

One thing you would notice here would be that regardless of Long BSR or Short BSR, 'Buffer Size' bit field size is always 6 which means it can represent only 0~63.

How this small set of numbers can represent such a wider range of possible data size in UL buffer ?

Good Question.

It would require too many bits to represent real data size in UL buffer, so they break down the data size into 64 different ranges and put an index to each of the ranges as shown in the following table from TS 36.321. The 'Buffer Size' field in BSR represent the 'Index' value of the following table.

< 36.321 v11.5.0 - Table 6.1.3.1-1 : Buffer size levels for BSR >

< 36.321 v11.5.0 - Table 6.1.3.1-2 : Extended Buffer size levels for BSR >

Note : As you see, BSR index (value) 0 means "I have no data to transmit" and as the number gets larger, it means UE has more data to transmit.

The second table is not an alternative the UE picks for itself. 36.321 Table 6.1.3.1-2 applies only when the network configures extendedBSR-Sizes, which arrived in Release 10 alongside carrier aggregation. Without that configuration the UE always uses Table 6.1.3.1-1, so the same six bits mean two different things depending on a setting that is not in the report.

The reason for a second table sits at the top of the first one. Index 63 in Table 6.1.3.1-1 means more than 150000 bytes and says nothing beyond that. A UE aggregating several carriers can easily hold more than that, so every large buffer would report the same index. The scheduler would then lose the difference between a 200 kB buffer and a 2 MB one. Table 6.1.3.1-2 moves the ceiling to 3000000 bytes and keeps that difference visible.

The cost is resolution lower down. Both tables spend the same 64 indices, so stretching the range makes every step coarser. Index 31 covers 967 to 1132 bytes in Table 6.1.3.1-1, and 4017 to 4940 bytes in Table 6.1.3.1-2. A small buffer is therefore described less precisely once the extended sizes are configured.

• The Buffer Size field is an index, never a byte count : a decoder that prints the raw six bits as bytes is wrong by orders of magnitude. Look the value up in the table the network configured.
• Each index names a range, not a value : the UE reports the index whose range contains the amount waiting, so the eNB reads the upper bound of that range and grants against it.
• Which table applies is a configuration question : Table 6.1.3.1-2 is used only when extendedBSR-Sizes is configured. A log without that configuration beside it cannot be decoded with confidence.
• Index 0 and index 63 are the two ends : 0 means nothing is waiting, and 63 means more than the largest bound in the table. That bound is 150000 bytes normally and 3000000 bytes with the extended sizes.

When does the UE decide to send a BSR?

The two formats answer what a BSR says. This section answers when the UE says it. Three names appear in the specification for that, and all three produce the same MAC control element. What differs is the event that triggered the report. So a log that labels a BSR as Periodic is telling you about the trigger, and not about the bits that went on the air.

There are three BSR types according to the timing UE send BSR. Regular BSR, Periodic BSR, Padding BSR are these. Regular BSR is sent when a New data arrives in UL buffer and the new data has higher priority than the one already waiting in the buffer.

Periodic BSR is sent with the predefined periodicity. The periodicity is defined by Network and get informed to UE by RRC message (e.g, radioResourceConfigDedicated IE in RRC Connection Reconfiguration) as follows.

Decoded RRC message, protocol analyser output. Field values come from one live capture, not from the specification.

| +-mac-MainConfig ::= CHOICE [explicitValue] OPTIONAL:Exist
| | +-explicitValue ::= SEQUENCE [111]
| |   +-ul-SCH-Config ::= SEQUENCE [11] OPTIONAL:Exist
| |   | +-maxHARQ-Tx ::= ENUMERATED [n5] OPTIONAL:Exist
| |   | +-periodicBSR-Timer ::= ENUMERATED [sf20] OPTIONAL:Exist
| |   | +-retxBSR-Timer ::= ENUMERATED [sf320]
| |   | +-ttiBundling ::= BOOLEAN [FALSE]
| |   +-drx-Config ::= CHOICE [release] OPTIONAL:Exist
| |   | +-release ::= NULL
| |   +-timeAlignmentTimerDedicated ::= ENUMERATED [infinity]
| |   +-phr-Config ::= CHOICE [setup] OPTIONAL:Exist
| |     +-setup ::= SEQUENCE
| |       +-periodicPHR-Timer ::= ENUMERATED [sf500]
| |       +-prohibitPHR-Timer ::= ENUMERATED [sf200]
| |       +-dl-PathlossChange ::= ENUMERATED [dB3]

Padding BSR is sent when the number of padding bits in a data message is larger than the size of BSR, so that the padding bit space can be used to send the BSR.

In that capture two fields are marked in red. They are the timers behind the second and third of those triggers. The network sets both in mac-MainConfig, and both count subframes, which is why the values read as sf20 and sf320 rather than as milliseconds.

periodicBSR-Timer sets how often the UE refreshes a report while it still has data. The UE restarts the timer each time it sends a BSR, and a Periodic BSR is triggered when the timer expires. At sf20 the UE reports at least every 20 ms for as long as something is waiting.

retxBSR-Timer does a different job. The UE restarts it whenever an uplink grant arrives, and a Regular BSR is triggered if it expires while data is still waiting. So it covers the case where the eNB has stopped granting and the earlier report was lost or ignored. At sf320 that recovery takes 320 ms, which is a long time on a data call. It is worth knowing that number before reading a stalled uplink as a UE fault.

• The three names describe triggers, not formats : Regular, Periodic and Padding BSR all produce the same Short or Long BSR control element. The name records why the UE sent it.
• A trigger is not a transmission : a triggered BSR waits for a grant that can carry it. The next section covers what the UE does while it waits.
• Read the two timers together : periodicBSR-Timer sets how often the UE refreshes a report, and retxBSR-Timer sets how long it waits before repeating one. Both count subframes, so sf20 is 20 ms.

Triggers for BSR transmission

There are several cases where UE transmit BSR. Brief summary of each of these cases (Triggers). Read the four cases below as conditions that set a flag inside the UE, rather than as four different messages. When any of them fires, the UE marks a BSR as pending and then looks for somewhere to put it. Case ii) works differently from the other three, because there the grant arrives first and the BSR fills space that would otherwise have been padding.

i) UE has UL data to transmit : When UE has some data to transmit in RLC or PDCP entity for a certain LCG. (This is called Regular BSR)

ii) UE got the UL Grant and the padding data is larger than the size of BSR CE and the subheader (This is called Padding BSR).

There are somes cases where network send UL Grant when UE does not have any data to transmit, in this case UE transmit all 00 data or some garbage data and long padding 0s. In this situation, UE would put BSR MAC CE as part of MAC PDU and set BSR index value all 0. See one example here.

iii) retxBSR-Timer is expired and UE has some data to transmit (This BSR is called Regular BSR)

iv) periodicBSR-Timer is expired (This BSR is called Periodic BSR)

One case is missing from that list, and it is the one that causes the most confusion in a log. A Regular BSR can be triggered when the UE has no uplink grant at all. A BSR is a MAC control element, so it needs a PUSCH allocation to travel in, and at that moment the UE has none.

The UE then asks for one. A Scheduling Request is triggered alongside the Regular BSR, and the UE sends it on its dedicated PUCCH SR resource. If the network answers with a grant, the BSR goes out in that grant. If the UE has no valid PUCCH SR resource configured, it cannot ask that way, so it starts a Random Access procedure instead. Figure 2 puts the three paths side by side.

Figure 2. A trigger is not a transmission. A Regular BSR with no grant to travel in turns into a Scheduling Request, and a UE with no SR resource uses Random Access instead. The BSR itself is the same control element on all three paths, so only the delay in front of it changes.

• The left box is the only real input : everything after it is the UE working out how to get the report out, not working out what to report.
• The decision is taken per TTI : the UE asks whether it has a grant for this subframe. A grant that arrives two subframes later is a separate decision.
• The lower path costs time : an SR waits for the next SR opportunity on PUCCH, and Random Access costs more again. Both delays sit in front of the first uplink byte.
• The dashed box is a configuration case, not an error case : a UE can legitimately have no PUCCH SR resource, and Random Access is then the specified behaviour rather than a fault.

That path sits underneath all four of the numbered cases above. Any of them can fire while the UE holds no grant, and the UE then has to ask before it can report.

• A trigger sets a flag, and a grant carries it : the four cases above decide that a BSR is pending. None of them puts it on the air by itself.
• Case ii) reverses the order : in a Padding BSR the grant comes first and the BSR fills space that would have been thrown away. That is why a log shows BSRs the UE had no real reason to send.
• An SR in a log usually means a BSR is waiting : when you see a Scheduling Request, look for the Regular BSR that triggered it and for the grant that followed.

When to send Long BSR and When to send Short BSR

This is pretty tricky quesiton... for the details you have to refer to "5.4.5 Buffer Status Reporting" of 36.321. But unless you try to do implement this process on your own (programming MAC protocol stack) or analyze a lot of live network log line by line, it would not be easy to make very clear sense out of just reading the specification. However, just big picture is as follows : First criteria is to check whether it is Padding BSR or Regular/Periodic BSR and once it is determined, apply following rule.

For Regular and Periodic BSR,

if( the number of LCG with allocated data > 1) --> Long BSR

else --> Short BSR

For Padding BSR,

if( the number of padding bit >= the size of the Short BSR plus its subheader

&& the number of padding bit <= the size of the Long BSR plus its subheader)

{

if( the number of LCG with allocated data > 1) --> Truncated BSR

else --> Short BSR

} else {

         --> Long BSR

}

One branch there needs explaining, and it is the branch that produces a Truncated BSR. It is the only place where the UE knowingly sends an incomplete report.

A Truncated BSR appears in exactly one situation. More than one LCG has data, so a Long BSR is what the UE would like to send. But the padding space only fits one octet. Rather than report nothing, the UE sends a one octet report and names a single group in it.

Which group it names is not arbitrary. The UE picks the LCG that holds the highest priority logical channel with data waiting. So the eNB gets the most urgent number and loses the rest, which is the right choice when there is room for only one.

That also explains the title of 36.321 Figure 6.1.3.1-1, which covers Short BSR and Truncated BSR in a single drawing. The two share one octet and one field layout, and the receiver separates them by the LCID in the MAC subheader rather than by anything inside the control element itself.

The practical consequence is worth stating plainly. A Truncated BSR is not a complete picture of the buffer. A scheduler must not read it as one, or it will allocate too little. The UE has not cancelled the data in the other groups. It simply had no room to mention it.

• Padding is where the format rule changes : for a Regular or Periodic BSR the choice is simply one group or more than one. For a Padding BSR the amount of padding decides, and that is outside the UE's control.
• Truncated means incomplete, not wrong : the UE reported the most urgent group and had no space for the others. Expect another BSR shortly afterwards.
• Short and Truncated look identical on the air : same octet, same field layout. Only the LCID in the subheader separates them, so a decoder that ignores the LCID will label one as the other.