【绝对原创】LTE学习过程遇到的实际问题及其解决方案材料.docxVIP

 PAGE \* MERGEFORMAT 47 接下来的部分是我学习LTE以来遇到的一些问题及最终的解决方法和思路，请查阅。能力有限故所提及之处若有错误请见谅！敬请指正，谢谢！ 案例一 结论 如图所示，之后更换版本后为防止上行业务中出现较大随机性误码，需要将-B中的“超码率开关”即“小区参数—UP参数—MAC配置参数”中的预留字段6设为“1”，即打开超码率开关，限制码率不超过0.93。限制码率之后会牺牲1M左右的上行速率。 问题经过 测试过程出现“上行极好点出现随机性突发误码，持续时间不定，有时误码甚至可达到5%-10%”的现象。 问题分析 查看协议，协议里中对PDSCH信道的码率有明确的限制“若超过0.93，UE就可能丢弃TB块”。 援引——The UE may skip decoding a transport block in an initial transmission if the effective channel code rate is higher than 0.930, where the effective channel code rate is defined as the number of downlink information bits (including CRC bits) divided by the number of physical channel bits on PDSCH. 那么问题来了：①协议是根据什么计算出0.93这个值的？ ②从协议上并未限制上行PUSCH的码率，那么为什么只有下行需要限制码率而上行不需要限制呢？ 那么根据出现的这个案例，我们需要思考一下的是，PUSCH其是否也有此限制？是否真的是由于我们未限制上行业务信道的码率即PUSCH码率从而造成了丢包或者CRC校验错误从而导致误码的现象？ 首先，对于①根据多方查找资料和跟有关人员讨论得知，0.93最开始并不是通过计算得出，而是各终端公司通过性能仿真得出各自的码率上限，然后再折衷的一个值，Nokia和Moto的手机性能在当时属于前列，仿真出来的值能达到0.98以上，然而众多日本厂商认为此值太高，并且会抬升终端的成本，通过协商，最终各厂家妥协到0.93这个值。 对于②PUSCH码率没有约束的原因是检测者是eNB本身，不像下行检测者是终端。如果终端的解调码率门限不做约定，那么eNB就不清楚下行数据包到底是超过UE解调能力被丢了还是真的信道不佳传丢了。对于上行，调度都是受eNB控制的，eNB显然清楚自身的解调能力。 那在这个问题里出现的B4场景下，“上行极好点出现随机性突发误码，持续时间不定，有时误码甚至可达到5%-10%”的现象，到底是不是由于我们未限制上行业务信道的码率即PUSCH码率从而造成了丢包或者还是由于CRC校验错误等其他原因从而导致误码的现象呢？ 通过跟UP同事和基带同事交流，我们之前的上行解调能力确实存在一定瓶颈，因此需要限制一下下行的编码效率0.93，而这个0.93的数值也恰恰就是根据协议里对PDSCH的限制，借鉴而来，当然也经过一定数量的仿真和实现最终大致得出这个结果，并非经过某些算式精确计算而得。UP同事同样表示，通过我们代码的上行解调能力的逐渐增强，之后可能某一天限制与不限制码率0.93效果都是一样的。 前段时间又出了一个针对上行提高解调性能的DSP0版本，通过跟基带同事交流后，其表示之前限制的0.93主要目的是限制信道条件比较好的时候的上行码率，也就是SNR比较高的时候，而后来出的提高上行解调性能的DSP0版本主要是提高低SNR时候即差点的上行解调性能，并不能覆盖所有情况，因此暂时0.93这个码率限制暂时还不能放开。 而具体看是否此时此刻的码率超过了限制的0.93的具体计算方法是，例如下图的情况，筛选出PUSCH_REQ，Tblen=43816 除以调制阶数Qm=4再除以H=11664.结果即为码率（依据码率定义） 相关自学知识： 依据可用的RB数选择满足CR(码率—36.104中annex A中的coderate)不超过0.93的最大的TBS，CR = (TBS+CRC)/可携带比特数；如果CR超过0.93，MCS就要降阶。根据协议，PHY层会把超过6144bits的TBS进行分块，给每块加上24bits的CRC，最后整个TBS还要加上一个TB CRC。 计算每个子帧可携带的比特数：可携带比特数＝可用RE×调制系数（QPSK为2，16QAM为4，64QAM为6）。 码率是用来计算吞吐率的，一个PRB承载的码率在不同的MCS等级下是不同的，MCS等级越高，PRB承载的码率也越高。 【峰值速率计算方法】在无线环境足够好的情况下，可以使用最高等级的MCS，在使用最高等级的MCS时每个PR