通信人家园

标题: 再来麻烦老哥了， 关于系统消息的调度。  [查看完整版帖子] [打印本页]
时间:  2024-5-27 09:54
作者: kqkqsmd     标题: 再来麻烦老哥了， 关于系统消息的调度。

本帖最后由 kqkqsmd 于 2024-5-27 09:55 编辑

11.png
协议这里 系统消息和普通下行数据单码字，计算 tbsize的过程，貌似是一样的，但是实际测试系统，终端行为却大有不同。
这里是终端实际解析的。

22.png

mcs和rb不对，协议要求rb为2或者3，qm不能超过2，也就是 mcs不能超过9，并且用mcs和rb按上面计算tbsize的过程，也是不对的。不知道是哪里不对。





附件: 11.png (2024-5-27 09:52, 58.13 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NjM0NTgyfGVmYzJkYTEwfDE3MzI0Nzc2NTh8MHww

附件: 22.png (2024-5-27 09:54, 22.59 KB) / 下载次数 0
https://www.txrjy.com/forum.php?mod=attachment&aid=NjM0NTg0fDc4MTU5MDQzfDE3MzI0Nzc2NTh8MHww
时间:  2024-5-28 09:03
作者: landai

朋友还在搞LTE啊，简单回答一下。
1. “协议要求rb为2或者3”，这个不是指实际分配的PRB数目，是指DCI 1A里面的一个field，你看36.212 5.3.3.1.3。实际分配的PRB数目27其实是影响的PDSCH码率
2. “也就是 mcs不能超过9”，协议的原话是调制方式是QPSK，不是MCS不能超过9
3. 关于tb size的疑问，我也觉得不对，应该查36.213 Table 7.1.7.2.1-1的第二列或者第三列
时间:  2024-5-28 13:46
作者: kqkqsmd

本帖最后由 kqkqsmd 于 2024-5-28 13:49 编辑
landai 发表于 2024-5-28 09:03
朋友还在搞LTE啊，简单回答一下。
1. “协议要求rb为2或者3”，这个不是指实际分配的PRB数目，是指DCI 1A里 ...

1: dci里面的tpc字段指定了是2rb或者3rb， 但是实际分配是27，这么怎么理解，为啥可以和实际分配的不一样。实际计算riv的时候用的27，但是tpc又是告诉终端为2或3。
2：确实影响码率，从实际看，及时qm=2， mcs超了，但是码率不超，确实也不影响。
3：这个问题，我们根据实际数据逆向计算发现， tb size = mcs0 * rb = mcs*rb2（mcs*rb3），实际的tbsize查表得时候，用mcs=0，去计算实际rb，然后用rb=3或者2，去计算实际的mcs，这里得到的实际rb和实际mcs，终端才能识别，并且能够正确解析pdsch数据，信令到终端也是正常的，但是协议没有找到出处。
小公司还有些4G 业务，不比大公司。
时间:  2024-5-29 08:53
作者: landai

1: dci里面的tpc字段指定了是2rb或者3rb ---  dci里面的这个东西，只是个索引，不是实际的PRB数目
3：这个问题，我们根据实际数据逆向计算发现， tb size = mcs0 * rb = mcs*rb2（mcs*rb3）---- 我没明白你的意思，你这个log截图里面，tb size = 96bytes=96*8=768bits. 36.213 Table 7.1.7.2.1-1里面也没有768这个数字啊
时间:  2024-5-29 20:48
作者: NeoHY123

1. 110维度那张大表就是PRB个数
2. 768是不对的，没有这个TBSize
时间:  2024-5-30 09:26
作者: kqkqsmd

本帖最后由 kqkqsmd 于 2024-5-30 09:31 编辑
landai 发表于 2024-5-29 08:53
1: dci里面的tpc字段指定了是2rb或者3rb ---  dci里面的这个东西，只是个索引，不是实际的PRB数目
3：这个 ...

1:协议原文，tpc的索引， 0是代表2rb，1是代表3rb。这个2rb，3rb和实际rb数确实不符合。问题是这里。
- TPC command for PUCCH – 2 bits as defined in section 5.1.2.1 of [3]
        - If the format 1A CRC is scrambled by RA-RNTI, P-RNTI, or SI-RNTI:
                - The most significant bit of the TPC command is reserved.
                - The least significant bit of the TPC command indicates column  of the TBS table defined in [3].
                 - If least significant bit is 0 then  =  2  else = 3.
3：768 应该是去掉相应了mac头之后的长度，这个长度不用纠结，高通终端解析出来的，是没问题的，关键是前面的计算过程。   计算过程你可以仔细看一下，计算过程我们也是从现网反推出来，我们也觉得很奇怪（没有找到现网计算的依据），正常rb和mcs确定tbsize，但是现在看到计算系统消息，不是这样。（rb=3，mcs=9的时候，tb size不超过57字节，这个时候使用正常的rb和mcs计算就行，但是超过57就得使用上面这种很奇怪的计算过程。另外fromat1A调度系统消息，不管多少字节使用这种奇怪得计算方式，终端都可以正常解析系统消息）
时间:  2024-5-30 09:35
作者: whywyq

LTE 不怎么搞了，但是这么成熟的东西，一定是没问题的，再仔细读读协议，魔鬼都在细节里。
时间:  2024-5-31 15:37
作者: kqkqsmd

本帖最后由 kqkqsmd 于 2024-5-31 15:40 编辑
whywyq 发表于 2024-5-30 09:35
LTE 不怎么搞了，但是这么成熟的东西，一定是没问题的，再仔细读读协议，魔鬼都在细节里。

翻了好多资料，都是正常的那种理解。
没看到现网的这种处理方式。以前我们也是按正常处理的，后面系统消息配置过大（>57字节），发现终端收不到，然后终端的dci都解不对，最后抓现网的log，才发现奇怪的这么处理。
时间:  2024-6-5 08:50
作者: aweeg

kqkqsmd 发表于 2024-5-31 15:37
翻了好多资料，都是正常的那种理解。
没看到现网的这种处理方式。以前我们也是按正常处理的，后面系统消 ...

协议完全没有问题。。
"qm不能超过2"不意味着“也就是 mcs不能超过9”，协议写的很清楚，如果是DCI CRC is scrambled by P-RNTI, RA-RNTI, or SI-RNTI，The UE shall use Qm = 2，根本不需要查表，这个时候I_MCS只是用来决定TB size的，不会用来决定modulation order。
“协议要求rb为2或者3”也不对，多少个RB是DCI里面FDRA决定的，完全可以分配27RB，TPC只是规定了在查找TB size表的时候，按照2RB或者3RB来查表，而不是分配RB只能2或者3RB。
查表的时候，I_MCS=13，RB=3的时候，TB size =744，加上24bits CRC正好是768bits，只能说log里把CRC bits也算上了不是很符合TB size的定义，但这是个小问题。然后这个TB，通过合适的速率匹配，采用QPSK在27个RB上传输。
时间:  2024-6-5 14:53
作者: kqkqsmd

aweeg 发表于 2024-6-5 08:50
协议完全没有问题。。
"qm不能超过2"不意味着“也就是 mcs不能超过9”，协议写的很清楚，如果是DCI CRC  ...

厉害，还有个问题， rb=2/3，查对应的 I_MCS可以查到对应的字节数，那么计算实际的rb的时候，为啥使用mcs=0去计算，也就是mcs=0的时候，再按当前字节数，计算使用的实际rb数。
时间:  2024-6-5 14:55
作者: kqkqsmd

aweeg 发表于 2024-6-5 08:50
协议完全没有问题。。
"qm不能超过2"不意味着“也就是 mcs不能超过9”，协议写的很清楚，如果是DCI CRC  ...

或者说为啥搞这么麻烦，和实际计算的时候搞成一样不就行了吗？
时间:  2024-6-6 10:19
作者: aweeg

kqkqsmd 发表于 2024-6-5 14:55
或者说为啥搞这么麻烦，和实际计算的时候搞成一样不就行了吗？

首先，SI，paging等，都是全小区的UE都是潜在要接收的，有些UE可能在边缘，信道质量很差。为了保证大家都能收到，需要分配很多的能量（功率）用来传输这些信息。而LTE下行的功率分配在不同RB上要尽量平坦的，不能在不同RB上功率波动过大，这是为了让UE接收机能够更好的工作。因此，想要分配更多的能量，只能通过分配更多的RB来实现，不能说只调度几个RB但是能量很高，这个在下行是不可以的，和上行的不一样。选择QPSK也是同理，高阶调制只是那些信道好的UE才能解对，QPSK可以让最差的UE也能有机会接收。
但另一方面，SI和paging本身需要的数据量不多，这个是人家自身的特点决定的。
所以，现在就有一个不同了，对于数据的，是大数据量就大带宽（大RB）调度，小数据量就小带宽（少RB）调度，信道质量好就MCS高一点，信道质量不好就MCS差一点。但是对于SI和paging来说，数据量就是不大，但是为了覆盖就是想要大带宽调度，为了让最差的UE也能接收，就是要低MCS调度。
这两者本身是不兼容的，所以，是可以搞两套规则分别计算的。但是，协议最终方法是，选择了用一套规则，但规定特例的方式，来处理SI和paging这类信息。这是个协议写法选择的问题，怎么写都行的，随便选了一个而已，不是必然的。但协议就是这样，很多时候就是很随意就定下来了，不需要太过深究为什么。
如果你了解5G NR对这块儿的处理的话，你就会发现，NR里面并没有和LTE一样这些特例的规定了，SI和paging的TBS计算弄得和普通数据的一致了，但还是为了处理前面说的问题，NR里面是通过引入了一个scaling factor，让SI，paging计算出来的TBS可以乘上一个小数，比如0.5，来实现大RB的调度但计算出来的TBS不会很大可以符合SI，paging自身的bit需求。
时间:  2024-6-6 11:37
作者: kqkqsmd

aweeg 发表于 2024-6-6 10:19
首先，SI，paging等，都是全小区的UE都是潜在要接收的，有些UE可能在边缘，信道质量很差。为了保证大家都 ...

那也就是说，为了功率考虑，下行要分配尽可能多的rb，所以选实际mcs=0，去计算实际需要的rb资源，然后传给终端的mcs和tpc那个rb，就是为了计算字节大小的。
时间:  2024-6-6 13:24
作者: aweeg

kqkqsmd 发表于 2024-6-6 11:37
那也就是说，为了功率考虑，下行要分配尽可能多的rb，所以选实际mcs=0，去计算实际需要的rb资源，然后传给 ...

嗯，你理解是对的，补充一下，
“所以选实际mcs=0，去计算实际需要的rb资源”只是一种实现方法，当然还可以有其他的实现方法，协议没有也不会这样要求，怎么实现这是基站厂家自己的事。
“然后传给终端的mcs和tpc那个rb，就是为了计算字节大小的”这部分才是协议的规定。
时间:  2024-6-6 18:10
作者: kqkqsmd

aweeg 发表于 2024-6-6 13:24
嗯，你理解是对的，补充一下，
“所以选实际mcs=0，去计算实际需要的rb资源”只是一种实现方法，当然还可 ...

感谢，总算搞明白了



通信人家园 (https://www.txrjy.com/) Powered by C114