浅析一个UE无法注册的问题

问题场景是环境中只有一个小区，UE在找到这个小区，收到MIB和SIB1后一直不发起注册，这个问题看起来些许有些凄凉，我抬头望着窗外的枇杷树，我想这大抵又是和S准则有关系了。这个问题看来又是没啥好看的了，先在SIB1周围随便找找就好了。

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 !

大概是想的过于简单，这log也有了些苦涩，通过log可以看出这个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。

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要用的禁止时间。

下面接着看如何根据上述参数进行UAC(38.331 5.3.14.5)。

如果有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）的均匀分布中选择随机数后与BarringFactor 比较，如果随机数小于BarringFactor，代表允许接入，但是这里的BarringFactor 是0，再怎么选择也不可能小于BarringFactor，所以会被bar，假如选取的rand＝0.5,bar time T390=(0.7+0.3)*uac-BarringTime= 128s。bar解除后，如果再次UAC的话，也会再次被bar，所以是不可能通过UAC的， 驻网这辈子是不可能了，别的又没什么好选的，爱干啥干啥吧......