Access Control
What would happen so many UEs are tyring to get access to a same cell (eNB, NB, BTS etc) ? The question is not hypothetical. A cell has a fixed number of preambles and a fixed amount of uplink, and both are exhausted well before the number of UEs in a stadium or a disaster area is. What follows is the set of mechanisms LTE uses to prevent that.
In worst case, the signal from different UEs interfers each other and does not get decoded by the cell (the signal is percieved as a noise). Even when they are lucky enough to reach and get decoded by the cell, it may create an overloading on the cell and network.
What would the cell (network) would do in this situation ? I would try to control (limit) the amount of the access from UEs. This kind of control process is called 'Access Control'.
There are several different ways for Access Control, but in terms of overall logic we can think of two different mechanism as listed below.
- Type 1) Accept initial request from UE but Network send Reject message
- Type 2) Prevent UE from trying initial access itself. (This type is called 'Barring')
- Case 1 : Bar every UE from any type of access even for emergency call (Configured by SIB1)
- Case 2 : Bar only specific UE (with specific marking in USIM) from a specific services (Configured by SIB2)
Type 1) is usually done by RRC Connection Reject in case of RRC layer, Attach Reject in case of NAS layer.
Type 2) is usually done by various SIB settings. Again in Type 2), a couple of different ways has been evolved as cellular technology evolves.
In this page, I will focus on Type 2) access control and followings are the topics :
- Factors/Message/Parameters for Access Control
- Access Control by SIB1 : Cell Barring
- Access Control by SIB2 : ac-Barring
- How the Access Barring Check Runs
- Access Control by SIB2 : ssac-Barring
- Reference
Factors/Message/Parameters for Access Control
First let's think of all the factors (Radio Messages and Parameters) that are involved in Access Control. How these parameters plays in Access Control ? I will post explanation later.. but I think you can imagine on your own. Refer to 3GPP 22.011 4.Access Control and 36.331 would give you the detailed meaning of each of these parameters. I strongly recommend you to try making your own story based on your imagination before you refer to the specification.
One important tip is that most of these messages has a parameters in the form of bitmap. These bitmap represents Access Control Class (each bits represents a specific Access Control Class). How does a UE knows which Access Control Class it belongs to ? It is specified in EF_ACC field in USIM.
Followings are all the SIBs and Information Elements that are related to various types of barring. Details of barring mechanism can be complicated and confusing, but I will try to clarify as best as I can.
LTE SIB1
SIB1 carries the coarsest control there is. It does not select between UEs by class or by service, and it does not use a probability. The two fields highlighted below decide whether the cell may be camped on at all, so they are read before anything in SIB2 matters.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
BCCH-DL-SCH-Message
message: c1 (0)
c1: systemInformationBlockType1 (1)
systemInformationBlockType1
cellAccessRelatedInfo
plmn-IdentityList: 1 item
....
cellBarred: barred (0)
....
systemInformationBlockType1
cellAccessRelatedInfo
cellReservedForOperatorUse: notReserved (1)
cellBarred: barred (0)
intraFreqReselection: notAllowed (1)
.... ..0. csg-Indication: False
LTE SIB2
SIB2 is where barring becomes selective. Each block below names a service, and each carries the same three parameters : a probability, a retry time, and a bitmap for the special Access Classes. Note how many copies of that shape appear, because the copy is what makes the control service-specific.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
sib2
ac-BarringInfo
...1 .... ac-BarringForEmergency: True
ac-BarringForMO-Signalling
ac-BarringFactor: p00 (0)
ac-BarringTime: s4 (0)
ac-BarringForSpecialAC: 10000 (bitmap)
ac-BarringForMO-Data
ac-BarringFactor: p00 (0)
ac-BarringTime: s4 (0)
ac-BarringForSpecialAC: 00000 (bitmap)
....
ssac-BarringForMMTEL-Voice-r9
ac-BarringFactor: p00 (0)
ac-BarringTime: s4 (0)
ac-BarringForSpecialAC: 00000 (bitmap)
ssac-BarringForMMTEL-Video-r9
ac-BarringFactor: p00 (0)
ac-BarringTime: s4 (0)
ac-BarringForSpecialAC: 00000 (bitmap)
LTE SIB2 - Rel 12, 13
In Rel 12, 13, Access Control mechanism has become more sophisticated. To implement this, many additional IEs are added as highlighted in RED. Two additions are worth finding in the tree below. Barring became configurable per PLMN rather than once for the cell, which matters on a shared network where one operator is congested and another is not. And ACDC arrived, which bars by application category rather than by service type.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
+-sib2 ::= SEQUENCE [10]+-ac-BarringInfo ::= SEQUENCE [11] OPTIONAL:Exist | +-ac-BarringForEmergency ::= BOOLEAN [FALSE] | +-ac-BarringForMO-Signalling ::= SEQUENCE OPTIONAL:Exist | | +-ac-BarringFactor ::= ENUMERATED [p00] | | +-ac-BarringTime ::= ENUMERATED [s4] | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] | +-ac-BarringForMO-Data ::= SEQUENCE OPTIONAL:Exist | +-ac-BarringFactor ::= ENUMERATED [p00] | +-ac-BarringTime ::= ENUMERATED [s4] | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] +-radioResourceConfigCommon ::= SEQUENCE | +-rach-ConfigCommon ::= SEQUENCE | +-bcch-Config ::= SEQUENCE | +-pcch-Config ::= SEQUENCE | +-prach-Config ::= SEQUENCE | +-pdsch-ConfigCommon ::= SEQUENCE | +-pusch-ConfigCommon ::= SEQUENCE | +-pucch-ConfigCommon ::= SEQUENCE | +-soundingRS-UL-ConfigCommon ::= CHOICE [release] | +-uplinkPowerControlCommon ::= SEQUENCE | +-ul-CyclicPrefixLength ::= ENUMERATED [len1] | +-EXTENSION ::= SEQUENCE [000] +-ue-TimersAndConstants ::= SEQUENCE +-freqInfo ::= SEQUENCE [00] +-mbsfn-SubframeConfigList ::= SEQUENCE OF OPTIONAL:Omit +-timeAlignmentTimerCommon ::= ENUMERATED [infinity] +-EXTENSION ::= SEQUENCE [011111] +-lateNonCriticalExtension ::= OCTET STRING OPTIONAL:Omit+-VERSION-BRACKETS1 ::= SEQUENCE [11] OPTIONAL:Exist | +-ssac-BarringForMMTEL-Voice-r9 ::= SEQUENCE OPTIONAL:Exist | | +-ac-BarringFactor ::= ENUMERATED [p00] | | +-ac-BarringTime ::= ENUMERATED [s4] | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] | +-ssac-BarringForMMTEL-Video-r9 ::= SEQUENCE OPTIONAL:Exist | +-ac-BarringFactor ::= ENUMERATED [p00] | +-ac-BarringTime ::= ENUMERATED [s4] | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] +-VERSION-BRACKETS2 ::= SEQUENCE [1] OPTIONAL:Exist | +-ac-BarringForCSFB-r10 ::= SEQUENCE OPTIONAL:Exist | +-ac-BarringFactor ::= ENUMERATED [p00] | +-ac-BarringTime ::= ENUMERATED [s4] | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] +-VERSION-BRACKETS3 ::= SEQUENCE [1111] OPTIONAL:Exist | +-ac-BarringSkipForMMTELVoice-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringSkipForMMTELVideo-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringSkipForSMS-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringPerPLMN-List-r12 ::= SEQUENCE OF SIZE(1..maxPLMN-r11[6]) [1] OPTIONAL:Exist | +-AC-BarringPerPLMN-r12 ::= SEQUENCE [1111111] | +-plmn-IdentityIndex-r12 ::= INTEGER (1..maxPLMN-r11[6]) [1] | +-ac-BarringInfo-r12 ::= SEQUENCE [11] OPTIONAL:Exist | | +-ac-BarringForEmergency-r12 ::= BOOLEAN [FALSE] | | +-ac-BarringForMO-Signalling-r12 ::= SEQUENCE OPTIONAL:Exist | | | +-ac-BarringFactor ::= ENUMERATED [p00] | | | +-ac-BarringTime ::= ENUMERATED [s512] | | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [10000] | | +-ac-BarringForMO-Data-r12 ::= SEQUENCE OPTIONAL:Exist | | +-ac-BarringFactor ::= ENUMERATED [p00] | | +-ac-BarringTime ::= ENUMERATED [s512] | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] | +-ac-BarringSkipForMMTELVoice-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringSkipForMMTELVideo-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringSkipForSMS-r12 ::= ENUMERATED [true] OPTIONAL:Exist | +-ac-BarringForCSFB-r12 ::= SEQUENCE OPTIONAL:Exist | | +-ac-BarringFactor ::= ENUMERATED [p00] | | +-ac-BarringTime ::= ENUMERATED [s4] | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] | +-ssac-BarringForMMTEL-Voice-r12 ::= SEQUENCE OPTIONAL:Exist | | +-ac-BarringFactor ::= ENUMERATED [p00] | | +-ac-BarringTime ::= ENUMERATED [s4] | | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] | +-ssac-BarringForMMTEL-Video-r12 ::= SEQUENCE OPTIONAL:Exist | +-ac-BarringFactor ::= ENUMERATED [p00] | +-ac-BarringTime ::= ENUMERATED [s4] | +-ac-BarringForSpecialAC ::= BIT STRING SIZE(5) [00000] +-VERSION-BRACKETS4 ::= SEQUENCE [0] OPTIONAL:Exist | +-voiceServiceCauseIndication-r12 ::= ENUMERATED OPTIONAL:Omit+-VERSION-BRACKETS5 ::= SEQUENCE [11] OPTIONAL:Exist +-acdc-BarringForCommon-r13 ::= SEQUENCE OPTIONAL:Exist | +-acdc-HPLMNonly-r13 ::= BOOLEAN [FALSE] | +-barringPerACDC-CategoryList-r13 ::= SEQUENCE OF SIZE(1..maxACDC-Cat-r13[16]) [1] | +-BarringPerACDC-Category-r13 ::= SEQUENCE [1] | +-acdc-CatValue-r13 ::= INTEGER (1..maxACDC-Cat-r13[16]) [1] | +-acdc-BarringConfig-r13 ::= SEQUENCE OPTIONAL:Exist | +-ac-BarringFactor-r13 ::= ENUMERATED [p00] | +-ac-BarringTime-r13 ::= ENUMERATED [s4] +-acdc-BarringPerPLMN-List-r13 ::= SEQUENCE OF SIZE(1..maxPLMN-r11[6]) [1] OPTIONAL:Exist +-ACDC-BarringPerPLMN-r13 ::= SEQUENCE +-plmn-IdentityIndex-r13 ::= INTEGER (1..maxPLMN-r11[6]) [1] +-acdc-HPLMNonly-r13 ::= BOOLEAN [FALSE] +-barringPerACDC-CategoryList-r13 ::= SEQUENCE OF SIZE(1..maxACDC-Cat-r13[16]) [1] +-BarringPerACDC-Category-r13 ::= SEQUENCE [1] +-acdc-CatValue-r13 ::= INTEGER (1..maxACDC-Cat-r13[16]) [1] +-acdc-BarringConfig-r13 ::= SEQUENCE OPTIONAL:Exist +-ac-BarringFactor-r13 ::= ENUMERATED [p00] +-ac-BarringTime-r13 ::= ENUMERATED [s4]
LTE SIB14
Extended Access Barring lives in its own SIB rather than in SIB2, and it targets a different population. Its bitmap covers Access Classes 0 to 9 instead of 11 to 15, so it reaches ordinary subscribers rather than the privileged classes. It was added for delay-tolerant traffic, which is why a machine-type device is the usual target.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
BCCH-DL-SCH-Message
message: c1 (0)
c1: systemInformation (0)
systemInformation
criticalExtensions: systemInformation-r8 (0)
systemInformation-r8
sib-TypeAndInfo: 1 item
Item 0
sib-TypeAndInfo item: sib14-v1130 (12)
sib14-v1130
eab-Param-r11: eab-Common-r11 (0)
eab-Common-r11
eab-Category-r11: a (0)
eab-BarringBitmap-r11: 0000000000
LTE Paging
Paging carries no barring parameters of its own. What it carries is a flag saying the EAB parameters have changed, so a UE that ignores SIB14 between modification periods still learns it needs to re-read it. Watch for eab-ParamModification-r11 below and nothing else.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
PCCH-Message
message: c1 (0)
c1: paging (0)
paging
nonCriticalExtension
lateNonCriticalExtension: <MISSING>
nonCriticalExtension
nonCriticalExtension
eab-ParamModification-r11: true (0)
nonCriticalExtension
Access Control by SIB1 : Cell Barring
Cell barring is the coarser of the two mechanisms, and it is worth understanding first because everything in SIB2 assumes it has already passed. Two independent fields combine here, and the combination matters more than either field alone.
I created following table based on 36.304 5.3.1 Cell status and cell reservations
|
Information Element Setting |
Barring Behavior |
|
cellBarred = not Barred cellReservedForOperatorUse = not reserved |
Any UE under this cell are allowed to select/reselect to this cell |
|
cellBarred = not Barred cellReservedForOperatorUse = reserved |
|
|
cellBarred = Barred cellReservedForOperatorUse = Any |
The UE is not permitted to select/reselect this cell, not even for emergency calls and it has to select another cell |
Three points about the table are easy to miss. The first is that cellBarred overrides everything else : when it reads barred, no Access Class helps and no emergency call is possible. The second is that cellReservedForOperatorUse only ever helps Access Classes 11 and 15, and only in the home network, so it is an operator test tool rather than a congestion control. The third is that neither field carries a probability or a timer.
That last point is what separates SIB1 barring from everything after it. A barred cell is barred for every UE that reads the SIB, with no random draw and no per-service distinction. The UE does not retry on this cell either. It reselects to another one, and intraFreqReselection in the same message decides whether a cell on the same frequency is even a candidate.
cellBarred is absolute : no Access Class and no emergency call overrides it, so it is the first field to read in a camping failure.cellReservedForOperatorUse is narrow : it admits Access Classes 11 and 15 in the HPLMN or EHPLMN, and bars 0 to 9 and 12 to 14.There is no probability at this level : SIB1 barring is a yes or a no, and the random draw only appears in the SIB2 mechanisms below.Read intraFreqReselection beside it : it decides whether the UE may look at another cell on the same frequency after being barred from this one.
Access Control by SIB2 : ac-Barring
You may easily guess the Access Control Mechanism by SIB2. You would see several different copies of the following structure. Just by looking at the name of the parameters, you may guess 'this is to allowing (or barring) a certain UE group (Access Class) to a certain service with only a certain probability'.
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
ac-BarringForXXXXXX
ac-BarringFactor: pXY (0)
ac-BarringTime: sA (0)
ac-BarringForSpecialAC: ABCDE (bitmap)
- XXXXX here represents the name of the service (application).
- ac-BarringFactor represents the probability of allowance of the access.
- ac-BarringForSpecialAC represents Access Class for UEs. A = 11, B = 12, C = 13, D = 14, E = 15
For example,
Let's assume that pXY is set to be p50 and ac-BarringForSpecialAC is set to be 0
Decoded message from a live capture. The values are what one network actually broadcast, not specification text.
AC 11 = Not BarringAC 12 = Barring AC 13 = Not Barring AC 14 = Not Barring AC 15 = Not Barring
Therefore, this barring applies only to the UE that has Access Class 12 is set to be '1' in its USIM.
Two things are worth adding beside that example, both from 36.331 v19.3.0. The first is a configuration rule. The field description for ac-BarringFactor states that values other than p00 can only be set if all bits of the corresponding ac-BarringForSpecialAC are set to 0. A network is therefore outside what the specification allows if it sends p50 together with the bitmap 01000. Treat the example as an illustration of the bit mapping rather than as a configuration to copy.
The second is larger. The bitmap governs Access Classes 11 to 15 only, and most subscribers hold none of those. A UE with no special Access Class is not exempt and not named in the bitmap. It goes straight to the random draw, so the barring factor reaches almost every ordinary UE on the cell, not only the class the bitmap mentions.
With this SIB settings, If a UE belonging to Access Class 12 sees this SIB parameter, it generate a random number between 0 and 1. If the number is lower than 0.5 (p50), it is allowed to get access. If the number is higher than 0.5, it should not get access. UE can retry this with the everage interval of A seconds set in ac-BarringTime when it is necessary.
How the Access Barring Check Runs
The sections above list the parameters. This one puts them in the order a UE applies them, which is the part the page above leaves to the reader. The order is set out in 36.331 clause 5.3.3.11, and it matters, because the first test that matches ends the check. A parameter further down is never reached once an earlier branch has decided.
The check runs when the UE wants to establish an RRC connection, and it produces one of two answers : barred, or not barred. Read the steps in this order.
Is a barring timer already running ? If T302 or Tbarring is running, access is barred and nothing else is examined. This is why a UE can appear barred while the SIB on air says otherwise.Does SIB2 carry the AC barring parameter for this establishment cause ? If it does not, access is not barred and the check ends here.Does the UE hold a valid special Access Class ? The USIM may carry one or more classes in the range 11 to 15. 36.331 notes that 12, 13 and 14 are valid only in the home country, and that 11 and 15 are valid only in the HPLMN or EHPLMN.If it does, is the matching bit zero ? For at least one valid class, a bit of zero in ac-BarringForSpecialAC means access is not barred. The bit is an exemption, and zero is what grants it.Otherwise, draw a random number. The UE draws rand uniformly in 0 to 1. If rand is lower than ac-BarringFactor, access is not barred. If not, it is.If barred, start Tbarring. The timer is not simply ac-BarringTime. 36.331 gives Tbarring = (0.7 + 0.6 * rand) * ac-BarringTime, with a fresh random draw.
Two of those steps are easy to misread. The exemption test uses zero rather than one. The reason is that the bitmap marks which privileged classes are still admitted, rather than which ones are blocked. And the Tbarring formula spreads retries between 0.7 and 1.3 times the configured value, which is what stops every barred UE in the cell from retrying in the same second. The mean is exactly ac-BarringTime, which is why 36.331 calls that field a mean access barring time.
The barring factor itself is not a free choice of percentage. 36.331 enumerates sixteen values, and the spacing is uneven : p00, p05, p10, p15, p20, p25, p30, p40, p50, p60, p70, p75, p80, p85, p90, p95. There is no p35, p45, p55 or p65, so the resolution is finest at the two ends and coarsest in the middle.
The first matching branch ends the check : a parameter below it is never consulted, so reading the clause in order is the only reliable way to predict the outcome.A zero bit is an exemption : ac-BarringForSpecialAC marks the privileged classes that still get through, which is the opposite of how a barring bitmap usually reads.Ordinary UEs are never in that bitmap : a subscriber with no class in 11 to 15 reaches the random draw every time, whatever the bitmap says.Tbarring is randomised : the 0.7 to 1.3 spread exists to stop a synchronised retry storm, and it is why two UEs barred together return at different times.The factor has sixteen steps, unevenly spaced : there is no p35 or p45, so a network cannot tune the middle of the range as finely as the ends.
Access Control by SIB2 : ssac-Barring
ssac stands for Service Specific Access Control. The ac-Barring is mainly designed for controlling access for general signaling and data and cs call (in case of UMTS), but with the introduction of Voice and Video over LTE. It became necessary to have access control mechanism for those voice and video call over LTE and that's the motivation of ssac barring. ssac-Barring is described TR 22.986. The main motivation of this type of access control is based on the following use-cases.
Use case 1
Japanese operators provide 'Disaster Message Board' services whenever a major disaster has happened such as an earthquake, tsunami or typhoon. This service enables the large number of subscribers to access the message board in order to post or retrieve information concerning the safety of individuals in the affected area with their mobile phones during a major disaster.
The human psychological behaviour is to make a voice call in emergency situations. Thus increased voice traffic consumes too much bandwidth for accessing other services such as the Disaster Message Board and/or data services (e.g. SMS).
Hence, a limiting mechanism is required to differentiate bandwidth consuming real-time services (e.g. Voice) from bandwidth-efficient data service to access to e.g. a Disaster Message Board.
Use case 2
As described in the Use case 1 above, subscribers may wish to make voice calls to check on the safety of individuals and it may cause congestion. Under such a situation, prioritised subscribers (e.g. governmental, military civil authorities ) and (depending on national regulation) access to emergency services should still be allowed access to EPS, while voice calls for other subscribers are restricted.
Reference
The page draws on four documents, and each answers a different part of the question. Two are radio specifications, one is the service requirement that started the service specific mechanism, and one is the study that motivated it.
- 36.331 - E-UTRA; Radio Resource Control (RRC) protocol specification. Clause 5.3.3.11 carries the access barring check, and the SIB2 and SIB14 field descriptions carry the bit ordering.
- 36.304 - E-UTRA; UE procedures in idle mode. Clause 5.3.1 is the source of the cell status table above.
- 22.011 - Service accessibility. This defines the Access Classes themselves and where each one is valid.
- TR 22.986 - Study on Service Specific Access Control. The two use cases quoted above come from here.