asd199086的博客

所以问题应该就和这个IE有关系，插入问题卡，网络会回复Use of dual connectivity with NR is restricted，后续过程网络侧就没有配置NR相关的测量；到这里就怀疑到应该是卡的问题，导致UE在attach时，NW端回复的attach accept消息中会带 RestrictDCNR = 1，代表Use of dual connectivity with NR is restricted，之后网络端也并未配置NR 测量object 及event,因而无法注册5G。

第三个bit对应 SSB 2，10，18，26，34，42，49，58,依次类推。groupPresence(8bits) 针对的是SSB L=64的情况，用8bits表示，从左至右分别表示一组 SSB的情况，第一个bit对应SSB0～7，第二个bit对应SSB 8～15，第三个bit对应SSB 16～23，第4个bit对应SSB 24～31，第5个bit对应SSB 32~39，第6个bit对应SSB 40～47，第7个bit对应SSB 48～55，第8个bit对应SSB 56～63。

如果UE不能获取SIB1且MIB中intraFreqReselection为not allowed，UE会将对应小区bar 掉，bar时间最多300s不能进行小区重选和小区选择过程，如果cell是licensed spectrum ，则UE不得重选到与被禁止小区相同频率的另一个小区，并排除这些小区作为小区选择/重选的候选小区300秒；如上图UE SIB1 read fail导致UE无法获取cell 的camp info，进而将对应cell bar 300s，也有bar 30s的设定。

出现这种情况，芯片厂也有自己的规避策略，既然4G频点没带优先级，就默认给4G频点加上优先级，一般4G频点都是最高优先级，后面就根据对应的规定进行正常的小区重选过程就完了。而在4/5g cell reselection的规定中，也有明确提出cell reselection只考虑带priority信息的频点。根据priority based重选算法的描述，在UE支持priority based inter-RAT小区重选且有收到cell priority 参数时，才会进行2G4或2G3小区重选。

问题不复杂，场景很简单，如上图，UE在进行LTE attach过程时，在送完NAS security mode complete后，就立刻收到了网络attach reject 带cause 6 Illegal ME，根据协议描述这个cause 代表ME不被网络可接受，例如ME在禁止名单或者黑名单中就会有这种cause。然而前方在报这个问题的时候，也是知道SIM卡和手机IMEI在运营商那边没能成功绑定，然后才报的问题，要查看手机是不是有问题...... 告诉前方原因后，还认为是手机问题，告知要继续查。

如上将上述log打印 的16进制数转换成二进制，bits_1_64 从右至左，分别是band1~64;bits 65_128 从左至右分别是band65-128，理论上是这样。进过判断后，置1的band分别为N25/41/66/71/77，也就是UE支持这5个band。后面在读取到SIB1 时，发现这个小区是N78的小区且当前环境中只有这一个小区，进而导致UE驻网失败。这个文章只是简单记录下QC平台如何通过log 确定UE支持的band。首先与NR band相关的NV 举例如下。

在看到前面merge conference call成功后，网络侧返回的NOTITY时，我注意到了上面这个maximum-user-count element，当然其实是5 这个数字引起了我的注意。这个问题是关于conference call，根据运营商反馈，会议电话可以同时有6 名参与者，于是就有了这个测试。结果显示DUT只能添加另外4名参与者，即会议电话中一共只有5名参与者。maximum-user-count的值代表可邀请参加会议电话的用户数量，通常，该值代表允许通过不同方式加入会议的用户数总数。

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。access category及驻留小区配置的参数，判断access是否允许的操作，LTE也有类似的机制。

如果UE有配置SRI-PUSCH-PowerControl，其中有不止一个p0-PUSCH-AlphaSetId，这时候收到了DCI 带有SRI field，要根据SRI 与SRI-PUSCH-PowerControlId的映射关系，SRI-PUSCH-PowerControlId有对应的P0-PUSCH-AlphaSetId，找到P0-PUSCH-AlphaSetId->p0，这个p0值作为P o_UE_PUSCH,b,f,c(j)。没有配置就是功率累加方式。

EN-DC场景下，UE需要同时维持与LTE和NR系统的连接，由于总发射功率的限制，UE的发射功率要综合考虑LTE和NR系统。如果P_LTE+P_NR≤P_EN-DC_Total，即使LTE和NR系统独立进行功率控制和计算，也不会出现实际发射功率超过P_EN-DC_Total的情况，这种情况可以认为半静态共享场景，这种场景对UE的要求低，但是LTE和NR系统所能利用的最大发射功率都小于P_EN-DC_Total，即使在没有NR（LTE）信号要发送时，LTE（NR）也不能利用剩余的功率分配给NR（LTE）。

针对服务小区c的载波f 上的active UL BWP b ，RRC如果有收到SRS功率控制调整状态 l 的 P_(O_SRS,b,f,c) (q_s) 值或 α_(SRS,b,f,c) (q_s) 值的配置，则h_b,f,c(k) =0，k=0,1,...i。P_CMAX,f,c(i)和P_o_SRS_b,f,c两个参数相比，前者带的是f,c 后者带的是b,f,c，结合其含义，b代表的是对应的UL BWP index，前者f,c对应的是载波级别的功率参数，后者b,f,c对应的是BWP级别的功率参数。

这个UE频繁掉网的问题，其实蛮low的，熟悉的人，看一个参数值就搞定这个问题了，但是还是做个记录。P_EMAX1和P_EMAX2会针对SUL 和NUL 进行区分，分别取自p-Max和NR-NS-PmaxList，目前的log看都没有带NR-NS-PmaxList，也就是只关注P_EMAX1的值即可P_EMAX1=p-Max=29，而ppowercalss =23dbm.所以Pcompensation=max(P_EMAX1-P_PoweClass, 0)=max(29-23，0)=6。

第三个bit对应 SSB 2，10，18，26，34，42，49，58,依次类推。groupPresence(8bits) 针对的是SSB L=64的情况，用8bits表示，从左至右分别表示一组 SSB的情况，第一个bit对应SSB0～7，第二个bit对应SSB 8～15，第三个bit对应SSB 16～23，第4个bit对应SSB 24～31，第5个bit对应SSB 32~39，第6个bit对应SSB 40～47，第7个bit对应SSB 48～55，第8个bit对应SSB 56～63。

主要原因是有人说按照这段描述，UE应该可以支持最多4个BWP，这份log才有3个，不应该有错，但是他忽略了协议上描述的是最大能力，具体UE的情况，要根据相关能力IE的上报，具体问题具体分析，就像协议上有那么多内容的描述，不可能任何一台UE都支持，UE要通过capability的上报，告知网络具体情况，网络知道了UE具体能力情况后，才能保证之后的配置不出问题；从上面的log打印看，这个问题是与配置的BWP个数有关系，应该是这条RRCReconfiguration带的配置超过了UE支持的能力。