微信公众号网站自己做导航条,企业网站建设 南通,广东h5网站建设,昆明新闻最新消息今天问题场景是环境中只有一个小区#xff0c;UE在找到这个小区#xff0c;收到MIB SIB1后一直不发起注册。我想这大概是和S准则不满足有关系了#xff0c;这个问题基本是又没啥好看的了#xff0c;太简单了#xff0c;在SIB1周围找找就解决了#xff0c;于是我发现了以下log…
问题场景是环境中只有一个小区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需要USIMNAS及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 identities0access category8这里就先确定下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 catedgory8。 根据上图找到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 0000000B就代表 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 ID0 access category 8SIB1中的消息有配置access category 8的uac参数。 SIB1中 uac-BarringForAccessIdentity 0000000B 从左至右 的bit位 分别代表 access Id 1,2,11,12,13,14,15 其值为0 代表 access id 1,2,11,12,13,14,15 的接入都是允许的UE access ID0这时需要从[01的均匀分布中选择随机数后与BarrinfFactor 比较如果随机数小于BarringFactor代表允许接入但是这里的BarringFactor 是0再怎么选择也不可能小于BarringFactor所以会被bar假如选取的rand0.5,bar time T390(0.70.3)*uac-BarringTime 128s。bar解除后如果再次UAC的话也会再次被bar所以是不可能通过UAC的 驻网是不可能了UE只能自生自灭......
