|
|
|||||||||
|
Access ControlWhat would happen so many UEs are tyring to get access to a same cell (eNB, NB, BTS etc) ? 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) 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 ControlFirst 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 >BCCH-DL-SCH-Message message: c1 (0) c1: systemInformationBlockType1 (1) systemInformationBlockType1 cellAccessRelatedInfo plmn-IdentityList: 1 item .... ....
systemInformationBlockType1 cellAccessRelatedInfo cellBarred: barred (0) < LTE SIB2 >sib2 .... < 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. +-sib2 ::= SEQUENCE [10] +-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-BRACKETS4 ::= SEQUENCE [0] OPTIONAL:Exist | +-voiceServiceCauseIndication-r12 ::= ENUMERATED OPTIONAL:Omit < LTE SIB14 >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 < LTE Paging >PCCH-Message message: c1 (0) c1: paging (0) paging nonCriticalExtension lateNonCriticalExtension: <MISSING> nonCriticalExtension nonCriticalExtension nonCriticalExtension Access Control by SIB1 : Cell BarringI created following table based on 36.304 5.3.1 Cell status and cell reservations
Access Control by SIB2 : ac-BarringYou 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'. ac-BarringForXXXXXX ac-BarringFactor: pXY (0) ac-BarringTime: sA (0) ac-BarringForSpecialAC: ABCDE (bitmap)
For example, Let's assume that pXY is set to be p50 and ac-BarringForSpecialAC is set to be 0 AC 11 = Not 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. 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. Access Control by SIB2 : ssac-Barringssac 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.
|
|||||||||