Backoff Indicator is a special MAC subheader that carries the parameter indicating the time delay between a PRACH and the next PRACH.
There are cases where a UE has to send another PRACH after it already sent a PRACH.
The most common cases are 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.
If the random access attempt of a UE fails, either because the preamble sent by the UE was not detected by the eNB or the UE lost the contention resolution, the UE has to start the process over again. To avoid contention and overload, the eNB can signal the UEs that they have to wait a certain time before they try to connect again.
The parameter that controls this is called the backoff indicator (BI) and is signaled by the eNB in the random access response. The actual time the UE should backoff is chosen uniformly by the UE in the interval [0,B]. As mentioned, the backoff parameter is sent in the RA response, but all RA responses can however be read by all UEs who sent a preamble in step 1 of the random access procedure. This means that also a UE that did not get a random access response. with its own preamble, i.e., was not detected, can receive the backoff parameter and use it.
The eNB can force the UE to wait a certain time before it tries to connect again. The maximum length of the backoff time is signaled to the UE by the eNB with the backoff parameter B. One possible scenario is that the backoff only is activated when there is an overload in the system. Therefore it would be interesting to study how the observations of AD (Access Delay) are affected by different values on B, during different conditions of the system. If the AD observers cannot be upgraded to accurately estimate an eventual backoff it would mean that the eNB is depending on AD reports from the UEs.