Unified Access Control

Posted 2022-11-26 modem协议笔记

微信同步更新欢迎关注同名modem协议笔记

UAC就是在进行access前，根据access identities和access category及驻留小区配置的参数，判断下access是否允许的操作。而UAC 需要USIM，NAS及RRC层共同完成，大概过程就是根据USIM中的access identities，结合NAS层确定的access category，交由RRC层进行UAC 后决定是否允许接入。24.501 4.5.1章节中描述要触发UAC的具体场景如下。

 当NAS检测到表格中的场景，NAS就需要将access identities和access category映射后，交由RRC层进行access baring check。再分别看下access identities和access category的规定。

access identities 

access identity是写在USIM EF_UAC_AIC 中的参数，access identity 是否有效是有场景规定的。

Access identity 1: 首先USIM EF_UAC_AIC 需要配置为 Access identity 1，在RPLMN，Registration accept ->5GS network feature support->MPS indicator 显示 ”Access identity 1 valid“时 才认为Access identity 1是有效的。

Access identity 2: 首先USIM EF_UAC_AIC 需要配置为 Access identity 2，在RPLMN，Registration accept ->5GS network feature support->MCS indicator 显示 ”Access identity 2 valid“时 才认为Access identity 2是有效的。

Access identity 11和15只在HPLMN和EHPLMN中有效；Access identity 12/13/14 只在HPLMN 和home country的visited PLMN有效。

Access identity 1/2/11/12/13/14/15 都无效的场景，就用Access identity 0。

Access identity 的定义如下。

Registration accept中的5GS network feature support 主要是告知UE网络端支持的feature，如果Registration accept中没有包含 5GS network feature support 就认为5GS network feature support中的所有bit都为0进行处理。Access identity 1/2相关的MPS indicator/MCS indicator就包含在5GS network feature support 中，配置结构如下。

access identity 1，2，11，12，13，14，15 USIM配置 files 如下

 

access category

access category 需要根据不同的rule进行匹配后才能确定，如果NAS层匹配完，发现有多个rule都适用，最终要选择rule number最小的那个access category。access category mapping表格在24.501 Table 4.5.2.2。

Mapping between access categories/access identities and RRC establishment cause

在进行接入时RRCSetupRequest中的IE RRC establishment cause的确定也和access categories/access identities有关系。如果匹配到多个rule，要选用rule number最小的那个cause，具体映射关系如下。

RRC层EstablishmentCause的定义也是根据NAS层上面的定义一一对应的，如下。

NAS层的操作进行完毕后，就需要RRC进行具体的access barring check，具体内容在38.331 5.3.14 Unified Access Control。

 

38.331 Unified Access Control

承接NAS部分，在access identities和access category完成映射后 RRC层就要进行access barring check；但是在RRC connected mode PCell变化时，UE要等到收到SIB1后才能进行access barring check，因为UAC的参数都在SIB1中。

首先第一步就是要根据UE的access category去找用于access barring check的参数，进而判断在当前环境下是否允许接入，UAC barring参数的配置结构如下。

UAC-Barring 的RRC 消息配置结构

结构图如上，主要是通过将accessCategory 与uac-barringInfoSetIndex进行配对，之后根据uac-barringInfoSetIndex在UAC-BarringInfoSetList中找对应的参数，uac-barringInfoSetIndex=1 代表要找UAC-BarringInfoSetList中的第一个入口的参数，uac-barringInfoSetIndex=2 代表要找UAC-BarringInfoSetList中的第而个入口的参数，由于UAC要用到两个timer，这里先列出来T302/390的定义。

UAC initiation

1 如果Access Category对应的T390在生效中，则access attempt 处于bar状态；

2 T390没有run，但是T302在生效中且Access Category 不是0和2，则认为access attempt 处于bar状态；

3 T390/T302都没有run，access category 是0，则access attempt是允许的，access category=0对应的是MT access场景，不用判断，直接允许接入，毕竟MT access为大；其他access category的运气就没有这么好，还是要进行UAC。

4 T390/T302都没有run且access category不是0，如果SIB1中包含 uac-BarringPerPLMN-List-> UAC-BarringPerPLMN->plmn-identitylndex，那么后续使用UAC-BaringPerPLMNentry，不考虑uac-BarringForCommon中的参数；如果没有配置uac-BarringPerPLMN-List但是有配置uac-BarringForCommon，则使用uac-BarringForCommon的参数；如果uac-BarringForCommon和uac-BarringPerPLMN-List都不存在，则直接允许接入。

     如果uac-BarringForCommon或者 uac-ACBarringListType 指示要用uac-ExplicitACBarringList，而此时UAC-BarringPerCatList包含UAC-BarringPerCat,就要根据UE的access category 找到对应的access catedgory 对应的UAC-BarringInfoSet参数，如下图，假如access catedgory=8。

如果uac-barringInfoSetList中根据uac-barringInfoSetIndex 找不到对应的barringinfo ，则允许access attempt，例如如果uac-barringInfoSetIndex=2，但是下面的uac-barringInfoSetList 只配置了一套barrringinfo 参数，那就认为accessCategory 8 没有bar参数，允许接入，如下图，这也就是举个例子，实网应该不会这么配置。

如果uac-BarringForCommon或者 uac-ACBarringListType 指示要用uac-ExplicitACBarringList，而此时UAC-BarringPerCatList没有包含对应的UAC-BarringPerCat,则允许接入，如上图，UE access category =5,但是SIB1中只有access category =8 参数，则对于access category =5 允许接入。

如果uac-ACBarringListType 指示要用uac-ImplicitACBarringList，就根据UE 的access category 找对应的参数信息，有对应的参数就进行access bar check, 找不到就说明允许接入，例如下面的图，accessCategory =6有对应的bar参数，要进行bar check，access  category =8,找不到，则允许接入；其他没有配置的access  category，由于没有参数，也允许接入。所以在SIB1中不配置对应accessCategory 的uac barring参数，是可以免除UAC过程，直接允许接入的。

协议上在UAC initiation中还有一些其他规定如下。

 

1 access attempt处于bar状态时，如果T302 在生效中且access category 2的T390也在生效中，RRC要通知NAS所有access categories都处于bar状态(access category 0除外，0处于unbar状态)；

2 access attempt处于bar状态时，如果T302 在生效中当access category 2的T390已经停止或超时，RRC通知NAS所有access categories都处于bar状态(不包含access category 0和2，0和2 处于unbar状态 )；

3 access attempt处于bar状态时，如果T302 停止或超时，就直接执行access barring check过程。

根据access category 结合SIB1的内容确定了用于access barring check的参数后，就可以进行access attempt的判断，而通过UAC initiation过程是可以初步对一些access attempt做出判断的，其余无法判断的部分就需要根据access identity 结合access  barring check完成，下面来看看。

 

38.331 5.3.14.5 Access barring check

如果有one or more Access Identities 或者 至少其中一个 access identities  的bit位  在 SIB1-> UAC barring parameter ->uac-BarringForAccessIdentity 置为0, 这样的attemp access是无条件允许的。

 uac-BarringForAccessIdentity 有7 bit，从左至右 的bit位分别代表  access Id 1,2,11,12,13,14,15 ，如果 uac-BarringForAccessIdentity '0000000'B就代表 access id 1,2,11,12,13,14,15 的接入都是允许的。

如果RRC connection 建立的原因是因为之前收到了release 消息带了redirect with mpsPriorityIndication且uac-BarringForAccessIdentity中与access Identity 1相关的bit位 是0，这样的access attemp也是允许的。

其他情况 就要从 [0 ，1）的均匀分布中随机选取一 rand 值；如果 rand 的值 小于 "UAC barring parameter" 中的 uac-BarringFactor  则 允许access attempt；否则 access attemp 就被bar。

如果 access attempt  被bar，就从[0 ，1）的均匀分布中 随机选取一 rand 值，针对对应的access category开启T390 ；T390 由下列由公式得到T390 = (0.7+ 0.6 * rand) * uac-BarringTime。T390 超时之前access category 都处于bar的状态，stop/超时的操作如下表。

由上面的内容可以看出UAC bar主要与T390/302有关系，stop或超时后就可以解除bar状态，这个内容主要在38.331 5.3.14.4 T302, T390 expiry or stop (Barring alleviation)中描述。

1 T302 超时或者stop且每个Access Category 都没有T390 处于生效状态，则认为这个access category 的bar 解除 

2 如果access category 不是2 ，且其T390 超时或者stop ，T302 也没在run，也认为 bar解除

3 access category 2的T390 超时或者stop  ，则 bar解除。

如果这个bar解除针对的是Access Category 8和2 则 按照 38.311 5.3.13.8 进行RNA update（不在本篇范围略过）。

协议的内容看起来是乱糟糟的，但其实整个过程是比较简单的，最后就看一个具体例子结尾。

UE access ID=0 ，access category =8,SIB1中的消息有配置access category 8的uac参数。

SIB1中 uac-BarringForAccessIdentity '0000000'B  从左至右 的bit位  分别代表  access Id 1,2,11,12,13,14,15 其值为0， 代表 access id 1,2,11,12,13,14,15 的接入都是允许的；UE access ID=0，这时需要从[0，1）的均匀分布中选择随机数后与BarrinfFactor 比较，如果随机数小于BarrinfFactor，代表允许接入，但是这里的BarringFactor 是0，再怎么选择也不可能小于BarringFactor，所以会被bar，假如选取的rand＝0.5,bar time T390=(0.7+0.3)*uac-BarringTime= 128s，其实在这种配置下access category 8的接入是永远不会成功的，就是因为BarringFactor=0。

最后再看下这个access category 8，不知道有没有注意到在NAS的定义中就没有有关系access category 8的描述，那什么时候access category =8? 其实这个场景在38.331 5.3.13 RRC connection resume中有描述，就不细说了，搜一下就知道对应的是情况。