【5G系列】Unified access control（3）——AS层的UAC

access control的时机?

在RRC连接建立或者resume连接建立之前要进行unified access control，如果结果为bar，则接入程序终止。

相关参数

相关参数定义在SIB1中：

怎么做access control?

1. 假如accesscategory相对应的T390处于active状态，则认为接入被bar；
2. 假如T302处于active状态，并且accesscategory并非0或者2，则认为接入被bar；
3. 假如accesscategory为0，则认为接入允许。
4. 否则要按照如下步骤进行判断
   - 4-1)
    假如SIB1中包含uac-BarringPerPLMNList，并且它包含的UAC-BarringPerPImn中存在plmn-identitylndex对应NAS选择的PLMN，那么后续使用UAC-BaringPerPLMNentry。
    否则假如SIB1中包含uac-BarringForCommon，那么后续使用uac-BarringForCommon；如果不存在uac-BarringForCommon和uac-BarringPerPLMN-List，则允许接入。
   - 4-2)
    如果4-1)是使用uac-BarringForCommon或者uac-BarringPerPLMN-List中包含的uac-ExplicitACBarringList，那么选择ueaccesscategory对应的entry。假如这个entry中的uac-BarringInfoSetIndex在uac-BarringInfoSetList中可以找到，那么那句对应的参数bar检查(step4-3)。如果找不到对应的entry或者index，则认为接入允许。
    如果是使用了uac-BaringPerPImnList，且其中包含uac-ImplicitACBarringList，那么选择对应cat的uac-BarringInfoSetIndex，和4-2)一样到uac_barringlnfoSetList去找。确定了bar-BarringInfoSet，就可以使用该info去判断当前ac是否被bar。

归根结底，其实就是找到一组uac-barInfoSet，如果定义了plmn专属的barInfoset，就使用那一个。否则就是用公共的baringForCommon配置确定要使用的uac-barInfoSet，这个配置是以access category作为索引的。

- 4-3)
 假如accessindentity对应的bit在uac-BaringForAccessldentity中为0，则表示允许接入.
 否则需要在0和1之间随机一个rand，如果这个值小于uac-barringFactor，则表示接入被允许，否则bar，如果bar，则在0和1之间随机一个rand，并启动timerT390。
T390=(700+6*randValue(0~100)*uac-BarringTime)ms。

如果accessbar检查是上层请求的，那么还需要将检查结果通知上层:

• 假如接入被bar，并且T302正在running，并且access category 2对应的T390正在running，那么通知上层除了AC 0，其他的AC都被bar~
• 否则假如接入被bar，并且T302正在running，那么通知上层除了AC0和AC2，其他AC都被bar。
• 否则假如接入被bar，那么通知上层该AC被bar。

Access bar怎么消除?

1. 假如T302超时或者被STOP，并且对应的T390没有running，则认为相应的ac bar被解除；
2. 假如非AC2对应的T390超时，并且T302没有running，则这个AC的bar解除；
3. 假如AC2对应的T390超时或者被stop，则这个AC的bar解除。
   假如是AC=8的bar被解除，那么会触发RNAU。

Access control相关timer

1) T302

• 开启场景：
  (1)收到RRCRelease，其中包含了waitTime，则开启T302，并通知上层除了AC0和AC2，其他ac都被bar。
  (2)收到RRCReject，其中包含了waitTime，则开启T302，并通知上层除了AC0和AC2，其他ac都被bar。
• 停止场景：
  (1)收到RRCResume或者RRCSetup-
  (2)收到RRCrelease，其中没有waittime或者其余场景回到IDLE-
  (3)收到Reject，其中没有包含waitTime
  (4)发生小区选择/重选后

2) T390

• 停止场景：
  (1)收到RRCSetup、RRCResume\MobiityFromNRcommand，停止所有ac对应的T390。
  (2)发生了小区选择或者重选；
  (3)收到RRCReconfiguration，并且reconfigurationWithSync包含在spCellConfigofMCG；
  (4)收到RRCRelease，其中包含suspendConfig。
  (5)回到idle态。