Backoff Indicator

Backoff Indicator is a special MAC subheader that carries the parameter indicating the time delay between a PRACH and the next PRACH. It is one octet long, it is optional, and a Random Access Response carries it at most once.

36.321 gives the field a blunter purpose than that. The specification says the BI field identifies the overload condition in the cell, and that is the part worth remembering. Backoff is not a retry timer the network sets for one UE. It is a congestion control. Every UE that failed on the same cell at the same moment reads it, and its job is to stop them all retrying together.

• Why would a UE send another PRACH ?
• What does the Backoff Indicator subheader look like ?
• Where does the BI subheader sit in the MAC PDU ?
• What does the UE actually do with the value ?
• Which backoff table applies ?
• Reference

Why would a UE send another PRACH ?

A PRACH preamble is not a reliable message. It is one of a small pool of sequences, sent without a grant, and several UEs can choose the same one in the same subframe. A first attempt failing is therefore normal rather than exceptional, and 36.321 plans for it.

Then you may say.. "Next PRACH ? Isn't a PRACH supposed to be transmitted only once ? Why/when UE send another PRACH ?".

Good question !

There are cases where a UE has to send another PRACH after it already sent a PRACH. The most common cases would be as follows.

i) UE sent a PRACH but didn't get a RAR for some reason.

ii) UE sent a PRACH and got RAR, but the RAPID in the RAR is not for the UE.

In this case, UE is supposed to send another PRACH. In this case, UE would have a question, saying "When/How soon do I have to send the next PRACH ?".

Backoff Indicator provide the answer to this question.

Those two cases are not a summary of the specification. They are the specification. 36.321 clause 5.1.4 gives two conditions. The Random Access Response reception counts as not successful if no RAR arrives within the RA Response window. It counts as not successful too if none of the RARs that did arrive carries a Random Access Preamble identifier matching the one the UE sent. The two cases above are those two branches, in that order.

A third failure has not come up yet, and it happens later in the procedure. The UE can receive a RAR meant for it, send Msg3, and then lose contention resolution to another UE that chose the same preamble. Clause 5.1.5 treats that as a failure too, and it applies the same backoff before the next attempt. So backoff covers both ends of the procedure. A preamble that drew no usable answer, and a preamble that drew an answer the UE then lost.

• The two cases are the specification's own two branches : no RAR inside the RA Response window, or no matching RAPID in any RAR that did arrive.
• Losing contention resolution is a third case : clause 5.1.5 applies the same backoff after another UE wins Msg4 with the same preamble.
• Each failure also increments PREAMBLE_TRANSMISSION_COUNTER : at preambleTransMax plus one the MAC reports a Random Access problem to upper layers instead of backing off again.

What does the Backoff Indicator subheader look like ?

At the beginning I said 'Backoff Indicator' is a special form of MAC header/subheader. As you know, each form of MAC header/subheader has it's own data structure. The structure of 'Backoff Indicator' is as follows.

< 36.321 - Figure 6.1.5-2: E/T/R/R/BI MAC subheader >

If you see the bit field shown above, you would notice that BI (Backoff Indicator) field is made up of 4 bits, implying that it can carry the value from 0~15. Each of these value maps to a specific time value as shown in the following table. (36.321). For example, if the BI field value is 10, Backoff Parameter value is 320 ms. This means UE can send PRACH any time in between 0 and 320 ms from now.

< 36.321 - Table 7.2-1: Backoff Parameter values. >

The other four bits of the octet are worth naming. Two of them are what let the UE tell this subheader from the ones around it. 36.321 clause 6.2.2 defines all of them.

E is the Extension field. Set to 1 it means another set of E/T/RAPID fields follows. Set to 0 it means a MAC RAR or padding starts at the next byte.

T is the Type field, and this one is the discriminator. T set to 0 means the subheader carries a Backoff Indicator. T set to 1 means it carries a Random Access Preamble ID. A UE reading the header therefore does not work out the type from position. It reads one bit.

The two R bits are reserved and set to 0. Count the widths and the reason is plain. E, T and two R bits leave four bits for BI, while E, T and a six-bit RAPID fill the same octet. Both subheader forms are one byte, which is what keeps the header octet aligned however many RARs follow it.

Three rows of the table need a note the screenshot does not carry. Indexes 13, 14 and 15 are reserved, and 36.321 clause 7.2 has a UE of the current release take any of them as 960 ms. A reserved value is therefore not something to ignore. It is the longest backoff in the table.

• T is the field that identifies the subheader : T set to 0 means a Backoff Indicator, and T set to 1 means a RAPID.
• Both subheader forms are one octet : four bits of BI plus two reserved bits occupy exactly what the six-bit RAPID uses on its own.
• A reserved index is not a no-op : clause 7.2 has the UE read indexes 13 to 15 as 960 ms, the largest value defined.
• The BI field names an overload : 36.321 calls it an indication of the overload condition in the cell. The value describes the cell, not one UE.

Where does the BI subheader sit in the MAC PDU ?

When this BI is transmitted by MAC, it is transmitted as in the following structure (36.321). You see BI subheader should always be at the beginning of the whole MAC header. If you see more carefully, you would notice that BI subheader is shown with 'dotted' rectangle. It means that this is optional, implying that the network send or does not send BI depending on the situation.

If you see even more carefully, you would notice that BI subheader does not have any corresponding payload part. It means "Backoff Indicator" information is carried directly by the MAC header/subheader and it doesn't use any payload field.

< 36.321 - Figure 6.1.5-4: Example of MAC PDU consisting of a MAC header and MAC RARs >

36.321 clause 6.1.5 states both of those observations in a sentence each. A MAC PDU header consists of one or more subheaders, and each one corresponds to a MAC RAR except for the Backoff Indicator subheader. If it is included, the Backoff Indicator subheader is included only once, and it is the first subheader in the header.

That "only once" is worth adding to what the drawing shows. A RAR MAC PDU can carry many RAPID subheaders, one for each UE it answers, but it never carries two backoff values. The cell has one congestion state and it reports that state once.

• The BI subheader has no payload of its own : every other subheader points at a MAC RAR, and this one carries its value inside the header.
• It appears at most once, and always first : a PDU answering many UEs still reports a single backoff value for the whole cell.
• The dotted outline means optional : with no BI subheader present the UE uses a backoff of 0 ms, which the next section explains.

What does the UE actually do with the value ?

Knowing that index 10 means 320 ms leaves the important question open. The UE does not wait 320 ms. 36.321 clause 5.1.4 has it draw a random number instead. The value from the table is only the upper end of that range.

Three points in the procedure touch the backoff parameter, and they run in this order.

At the start of every Random Access procedure the MAC entity sets the backoff parameter value to 0 ms. A backoff therefore never carries over from an earlier procedure.

When a Random Access Response arrives, the MAC entity looks for a Backoff Indicator subheader. If one is present, it sets the backoff parameter from the BI field through Table 7.2-1. If there is none, it sets the backoff parameter to 0 ms. That second branch is the one people forget. A RAR without a BI subheader does not leave the previous value in place. It clears it.

When the attempt then fails, the MAC entity picks a random backoff time, uniformly distributed between 0 and the backoff parameter value. It delays the next Random Access transmission by that time, then returns to selecting a Random Access resource. With index 10 the UE waits somewhere between 0 and 320 ms. Two UEs that read the same RAR will almost certainly pick different delays, and that is the whole point. A fixed wait would move the collision rather than break it.

One condition sits over all of this and is easy to miss. Clause 5.1.4 applies the backoff only if the Random Access Preamble was selected by MAC. A contention-free procedure uses a preamble the network assigned, through a PDCCH order or a handover command. No contention exists there, so no backoff is applied. Backoff belongs to the contention-based pool alone.

• The table value is a ceiling, not a delay : the UE draws uniformly between 0 and it. Index 10 therefore means somewhere between 0 and 320 ms.
• Randomness is the mechanism : a fixed wait would move a collision instead of breaking it, so two UEs reading one RAR pick different delays.
• A RAR with no BI subheader sets the backoff to zero : it clears whatever was there rather than leaving the previous value in place.
• Contention-free random access never backs off : the rule applies only when MAC selected the preamble, so a PDCCH order or handover preamble is exempt.

Which backoff table applies ?

The screenshot above is the table most readers need, and for ordinary E-UTRA it is the only one. Later releases added two more. A UE reading the same four bits can land on a very different number, depending on which table applies to it.

36.321 clause 7.2 now names three. Table 7.2-1 is the one above and covers E-UTRA. Table 7.2-2 replaces it for NB-IoT. Table 7.2-3 differs in kind, because it holds a backoff factor rather than a time. It is used for the CB-Msg3-EDT procedure, where the backoff is that factor multiplied by the configured CB-Msg3 transmission window periodicity.

The NB-IoT scale is the one that surprises people. Index 1 is 10 ms in E-UTRA and 256 ms in NB-IoT. Index 12 moves from 960 ms to 524288 ms, which is over eight and a half minutes. The traffic explains it. A cell full of meters reporting once an hour can afford to spread a retry across minutes, and it has far more devices to spread.

The reserved indexes follow the same pattern. A current-release UE reads a reserved index as the largest value in its own table. The three columns below put the scales side by side. The E-UTRA column repeats the screenshot above, so all three can be read in one place.

• Three tables read the same four-bit field : index 10 means 320 ms in E-UTRA, 131072 ms in NB-IoT, and a factor of 32 for CB-Msg3-EDT.
• NB-IoT backs off in minutes rather than milliseconds : its largest value is 524288 ms. That suits a cell holding far more devices, each reporting far less often.
• CB-Msg3-EDT stores a factor : the backoff is that factor multiplied by the configured CB-Msg3 transmission window periodicity, so it scales with the window.
• Reserved always means the maximum : indexes 13 to 15 read as 960 ms, 524288 ms or a factor of 40. Each is the largest in its own table.

Reference

One specification carries every rule quoted on this page. The clause numbers sit beside each claim, so the wording can be checked rather than taken on trust.

• 36.321 - Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification, v19.3.0. Clause 5.1.4 is Random Access Response reception and the random backoff draw. Clause 5.1.5 is contention resolution. Clause 6.1.5 is the MAC PDU for a Random Access Response, and clause 6.2.2 defines the E, T, R, BI and RAPID fields. Clause 7.2 holds Table 7.2-1, Table 7.2-2 for NB-IoT and Table 7.2-3 for CB-Msg3-EDT.