返回信息流最近做LTE物理层的项目,在速率匹配这块遇到问题。
速率匹配之后输出序列的长度E是得怎么求的?
之前看到有人说得先求得RB数目,再求每个RB里面用于传输数据的symbo数目,进而转换为比特数目。如:
由DL-SCH传来的传输块,采用单天线端口的方式,有10个RB,每个RB是一个12*14时频单元,去掉控制和导频,余下75%的可用资源,这样的话可以承载10*12*14*3/4=1260(QAM符号),对于MCS Index = 0而言,可以承载的物理比特个数为1260(QPSK符号) * 2(QPSK)调制 = 2520比特,G = 2520,进而可求E。
但是我觉得这种方法不对,跟导师交流也觉得不对,应该不是这种求法。
我觉得应该是由编码速率来求,比如知道信道编码之前是200bit的比特流,经过turbo编码和速率匹配之后的编码速率为2/1,可求得G=400bit,进而求E。
但是标准里面只有在TS36.213的table 7.2.3-1中提到需要变成的编码速率的值:
CQI index modulation code rate x 1024 efficiency
0 out of range
1 QPSK 78 0.1523
2 QPSK 120 0.2344
3 QPSK 193 0.3770
4 QPSK 308 0.6016
5 QPSK 449 0.8770
6 QPSK 602 1.1758
7 16QAM 378 1.4766
8 16QAM 490 1.9141
9 16QAM 616 2.4063
10 64QAM 466 2.7305
11 64QAM 567 3.3223
12 64QAM 666 3.9023
13 64QAM 772 4.5234
14 64QAM 873 5.1152
15 64QAM 948 5.5547
对于下行信道,可以由CQI反馈信息来定位CQI index,从而确定所用的 code rate。而对于上行信道,貌似只能确定自适应调制方式,没有办法把它同CQI index 联系起来,所以感觉没法求相应的code rate 。
这种求速率匹配输出的方法对不对?如果对上行是怎么求得呢?求高手指点。
这是一条镜像帖。来源:北邮人论坛 / communications / #18536同步于 2011/8/16
该镜像源已超过 30 天没有更新,可能在源站已被删除。
Communications机器人发帖
LTE速率匹配的问题
ivanlee2011
2011/8/16镜像同步10 回复
订阅后,新回复会通过你的通知中心匿名送达。
9 条回复
跟导师交流也觉得不对。。那么导师为啥不告诉你答案呢。。北邮导师应该随意会LTE啊。。好多还教移动通信的课的。
编码速率肯定不对,因为编码速率就是 turbo coding 前后的bit数之比,当然turbo coding 会多4个bit。
速率匹配是干嘛的呢,就是干这么一件事的,你要把一车子煤装进一个仓库,可是煤的数量和仓库的容量不一定一样,然后速率匹配就对其进行重复或者打孔来使两者相等。
根据分配RB就可以算出仓库的容量,而煤的数目你也是知道的,turbo coding的编码效率是固定的。然后就可以算出来到达速率匹配前的数目。
【 在 xiecaiji 的大作中提到: 】
: 跟导师交流也觉得不对。。那么导师为啥不告诉你答案呢。。北邮导师应该随意会LTE啊。。好多还教移动通信的课的。
: 编码速率肯定不对,因为编码速率就是 turbo coding 前后的bit数之比,当然turbo coding 会多4个bit。
: 速率匹配是干嘛的呢,就是干这么一件事的,你要把一车子煤装进一个仓库,可是煤的数量和仓库的容量不一定一样,然后速率匹配就对其进行重复或者打孔来使两者相等。
: ...................
靓仔,你说的道理我懂,可是呢,到底是根据啥来确定速率匹配的输出呢?像楼主所说的一样用标准里面那个表,一个CQI index对应一个编码率,可是上行信道有肿么办
【 在 tracyone 的大作中提到: 】
: : 跟导师交流也觉得不对。。那么导师为啥不告诉你答案呢。。北邮导师应该随意会LTE啊。。好多还教移动通信的课的。
: : 编码速率肯定不对,因为编码速率就是 turbo coding 前后的bit数之比,当然turbo coding 会多4个bit。
: : 速率匹配是干嘛的呢,就是干这么一件事的,你要把一车子煤装进一个仓库,可是煤的数量和仓库的容量不一定一样,然后速率匹配就对其进行重复或者打孔来使两者相等。
: ...................
具体我也不知道,要不我就直接回答了,标准太复杂,不做的话懒得看。然后就忘了。。以前看协议的时候我就是像lz说的第一种情况那样理解的,先把问题简单话,比如单天线的情况,知道分配的RB了,然后知道调制方式了,然后不就知道速率匹配之后的bit数了么,这个上下行都是一样的
上行PUSCH的发送是基站来调度的,基站通过PDCCH来告知UE怎么做,UE通过解PDCCH得到DCI格式0,DCI格式0有一个域叫MCS-5bit得到相应的上行PUSCH的I_MCS,还有一个域叫RAI(资源分配指示)得到RB个数,通过I_MCS得到I_TBS(有对应关系),再利用I_TBS和RB个数查表得到PUSCH上行的TB_size.
【 在 tracyone 的大作中提到: 】
: 靓仔,你说的道理我懂,可是呢,到底是根据啥来确定速率匹配的输出呢?像楼主所说的一样用标准里面那个表,一个CQI index对应一个编码率,可是上行信道有肿么办
【 在 hyghyg 的大作中提到: 】
: 上行PUSCH的发送是基站来调度的,基站通过PDCCH来告知UE怎么做,UE通过解PDCCH得到DCI格式0,DCI格式0有一个域叫MCS-5bit得到相应的上行PUSCH的I_MCS,还有一个域叫RAI(资源分配指示)得到RB个数,通过I_MCS得到I_TBS(有对应关系),再利用I_TBS和RB个数查表得到PUSCH上行的TB_size.
: 【 在 tracyone 的大作中提到: 】
: : 靓仔,你说的道理我懂,可是呢,到底是根据啥来确定速率匹配的输出呢?像楼主所说的一样用标准里面那个表,一个CQI index对应一个编码率,可是上行信道有肿么办
: ...................
然后呢,跟速率匹配的输出有关系么?
我们实际做的时候一般是将每个RB中业务数据RE填满,根据分配给UE的RB索引号,可以确定数据的符号数N,去除上行控制信息(CQI、PMI,RI,ACK/NACK)所点用的RE,再由调制方式Qm,得到传输块可实际传输的比特数G = N*Qm,TB_Size --->G,多余的打掉
【 在 tracyone 的大作中提到: 】
: 然后呢,跟速率匹配的输出有关系么?
【 在 hyghyg 的大作中提到: 】
: 我们实际做的时候一般是将每个RB中业务数据RE填满,根据分配给UE的RB索引号,可以确定数据的符号数N,去除上行控制信息(CQI、PMI,RI,ACK/NACK)所点用的RE,再由调制方式Qm,得到传输块可实际传输的比特数G = N*Qm,TB_Size --->G,多余的打掉
: 【 在 tracyone 的大作中提到: 】
: : 然后呢,跟速率匹配的输出有关系么?
: ...................
问题是去掉控制信息还有导频占用的RE之后,剩下的RE数目,每个RB剩下的RE数目都一样吗?如果一样的话我们才能先求出每个RB有多少可用的RE,再乘以RB数目。求解释