問題場景是環境中只有一個小區，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的， 駐網這輩子是不可能了，別的又沒什么好選的，愛干啥干啥吧......