问题分析总结及NR power control
文章平均质量分 80
一些工作中遇到的问题的分析总结记录及power control 部分协议走读
modem协议笔记
专注3GPP协议学习,每天进步一点点。
展开
-
因而band不支持导致的驻网失败
如上将上述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 举例如下。原创 2024-01-20 15:11:34 · 392 阅读 · 0 评论 -
一个conference call添加用户失败的问题
在看到前面merge conference call成功后,网络侧返回的NOTITY时,我注意到了上面这个maximum-user-count element,当然其实是5 这个数字引起了我的注意。这个问题是关于conference call,根据运营商反馈,会议电话可以同时有6 名参与者,于是就有了这个测试。结果显示DUT只能添加另外4名参与者,即会议电话中一共只有5名参与者。maximum-user-count的值代表可邀请参加会议电话的用户数量,通常,该值代表允许通过不同方式加入会议的用户数总数。原创 2023-12-20 11:02:21 · 400 阅读 · 0 评论 -
一个UE无法注册的问题
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也有类似的机制。原创 2023-11-17 17:19:53 · 188 阅读 · 0 评论 -
NR PUSCH power control
如果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)。没有配置就是功率累加方式。原创 2022-12-07 19:48:48 · 6485 阅读 · 0 评论 -
Dynamic power sharing(DPS) for ENDC/NEDC
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)。原创 2023-02-01 21:41:51 · 1839 阅读 · 4 评论 -
NR SRS power control
针对服务小区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级别的功率参数。原创 2023-10-18 18:23:37 · 348 阅读 · 0 评论 -
一个UE频繁掉网的问题
这个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。原创 2023-07-10 18:22:34 · 519 阅读 · 0 评论 -
SSB配置异常引起的问题
第三个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。原创 2023-04-17 18:53:51 · 893 阅读 · 0 评论 -
一个BWP配置异常的问题
主要原因是有人说按照这段描述,UE应该可以支持最多4个BWP,这份log才有3个,不应该有错,但是他忽略了协议上描述的是最大能力,具体UE的情况,要根据相关能力IE的上报,具体问题具体分析,就像协议上有那么多内容的描述,不可能任何一台UE都支持,UE要通过capability的上报,告知网络具体情况,网络知道了UE具体能力情况后,才能保证之后的配置不出问题;从上面的log打印看,这个问题是与配置的BWP个数有关系,应该是这条RRCReconfiguration带的配置超过了UE支持的能力。原创 2023-03-28 18:39:50 · 831 阅读 · 0 评论