问题场景是环境中只有一个小区，UE在找到这个小区，收到MIB SIB1后一直不发起注册。我想这大概是和S准则不满足有关系了，这个问题基本是又没啥好看的了，太简单了，在SIB1周围找找就解决了，于是我发现了以下log 打印。

2023 Jan 10 17:01:55.981             nr5g_rrc_cep.c 2361  UAC Category 8 !barred 0 time 1379841

2023 Jan 10 17:01:55.982             nr5g_rrc_cep.c 1272 H Sub-ID:1 Misc-ID:0 UAC: its a match !!the requested access id = 0x0, BarringForAccessId in SIB1 = 0x0

2023 Jan 10 17:01:55.982             nr5g_rrc_cep.c 1811 H Sub-ID:1 Misc-ID:0 UAC: Barred because of Barring Factor is p00

2023 Jan 10 17:01:55.982             nr5g_rrc_inactive.c 5910 H Sub-ID:1 Misc-ID:0 INACTIVE: UAC Access Barred !

是的 ，这个cell S准则是满足的，不是S准则的问题，而且通过上面的打印，可以确定该问题与UAC过程有关系，而且UE access被bar了，要搞清楚这个问题就先简单捋一遍相关协议，看整个流程是怎么回事。

所谓UAC就是在UE进行access前，根据 access identities和 access category及驻留小区配置的参数，判断access是否允许的操作，LTE也有类似的机制。 UAC需要USIM，NAS及RRC层共同完成，大概过程就是根据USIM中的access identities，结合NAS层确定的access category，交由RRC层进行UAC check后决定是否允许接入。

在24.501 4.5.1章节中有描述需要触发UAC的具体场景，如下。

 当NAS检测到表格中的场景，NAS就需要将access identities和access category进行关联后，交由RRC层进行access baring check。

有关access identities和access category的确定可以参考UAC，但是这里有关uac-ImplicitACBarringList的描述是错误的，可以去CSDN modem协议笔记看下UAC那篇，因为CSDN对文章的改正比较友好。

UAC过程的主要描述在38.331 5.3.14，对于问题场景首先要根据access category确定barring 参数，然后再根据access identities进行UAC判断是否会被bar以及后续的bar操作，问题场景中UE 的access identities=0，access category=8，这里就先确定下barring 参数。

根据38.331 5.3.14.2中的描述，当前的场景直接定位到上面的这段描述：如果uac-BarringForCommon可用或者 uac-ACBarringListType 指示要用uac-ExplicitACBarringList，而此时UAC-BarringPerCatList包含UAC-BarringPerCat,就要根据UE的access category 找到对应的access catedgory 对应的UAC-BarringInfoSet参数，如下图，UE access catedgory=8。

根据上图找到UAC-barring参数后，就要按照38.331 5.3.14.5进行UAC，稍微看下UAC-BarringInfoSet中IE的解释。

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 的接入都是允许的。

uac-BarringFactor 表示在 access barring check 期间允许访问尝试的概率。

uac-BarringTime 代表 在同一access category 被bar后，计算T390要用的禁止时间。

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

如果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，而log中的场景对应的就是这种判断场景。

问题中是access attempt bar的情况，后面接着看bar之后应该怎么做。

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

继续看T390 超时后UE应该怎么做，主要规则在 5.3.14.4 T302, T390 expiry or stop (Barring alleviation)中有描述，这里T320的解释也贴在上图。

1 T302 超时或者stop且每个Access Category 对应T390 没有在运行，则认为这个access category 的bar 解除 ；

2 else 如果access category 不是2 ，且其T390 超时或者stop ，T302 也没在run，也认为 bar解除，这里对应问题场景；

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

当 Access Category 的bar解除，如果这个access category 之前已经告知NAS处于bar状态 ，那这时UE要告知NAS 现在bar解除了。

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

至此整个UAC 的流程就比较清楚了，最后结合SIB1中的信息，总结下这个问题bar的具体原因。

该问题中 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 比较，如果随机数小于BarringFactor，代表允许接入，但是这里的BarringFactor 是0，再怎么选择也不可能小于BarringFactor，所以会被bar，假如选取的rand＝0.5,bar time T390=(0.7+0.3)*uac-BarringTime= 128s。bar解除后，如果再次UAC的话，也会再次被bar，所以是不可能通过UAC的， 驻网是不可能了，UE只能自生自灭......