Sony终端PUCCH功控问题

【问题现象】
一阶段杭州外场测试主要通过Sony终端进行，通过分析终端和eNB数据，发现终端在半静态调度情况下错误的把TPC理解成PUCCH降功率指示。
注：协议中关于PUCCH激活时的DCI解释：
对于SPS只有在激活的时候会发送PDCCH，其中PDCCH中 PUCCH TPC命令字用于指示ACK码道。以下截图来自36.213。

但从终端log上看到，终端会针对SPS传输进行PUCCH降功率操作。

【问题分析】
从eNB观测到的数据现象,见下图所示：313帧之前反馈的都是ACK，之后出现DTX。

对应出现DTX时间段eNB的PUCCH功控命令字生成，见下图所示：从27分31s的503Ticks之后就没有降过功率，一直要求抬升。(DeltaTpc字段为-1代表降功率，0代表保持，1代表升功率)。
说明：下面的表格中未记录帧号，需要根据上下两张表中的时间及Ticks对应起来看，Ticks的单位为ms。

接着确认功控命令字是否正确发送给UE，用来给UE发送功控命令字的DCI有1A、2A、Format3等，1A/2A是动态调度下去的，Format3是200ms下发一次。

功控命令字是200ms生成一次，承载的原则是先碰到谁就在谁上发，如果先碰到动态调度就在动态调度上发，如果是Format3就在Format3上发。发送一次后，200ms内其他发送内容更新为保持不变。

先看一下终端的数据，DCI的接收情况。下图可以看到，格式为2a的只在303-6帧上发送的0，降低1db，对应上图503Ticks最后一次生成降1db。

格式为1a的在315-3、317-3等重传时刻由动态调度发送给UE的TPC为1保持不变，其他都是0，降1db。这些降1db的都是半静态调度，因为此时半静态调度已经激活，基站侧并没有再发送PDCCH给UE，怀疑是到了半静态调度时刻UE根据半静态激活时的信息自己生成的。

再来看下终端侧PUCCH发送功率数据：终端每隔几帧就有降功率的动作，TPC Command列可以看出来有降的命令字。而这些对应的帧基站侧并没有发送降功率的命令字，怀疑是UE自己生成的半静态调度1a的功控命令字导致的。

比如：308-2帧，降1db，对应下行调度307-4/307-6，307-4是半静态初传，307-6 是动态初传，307-6基站侧发送TPC为1保持不变，307-4是UE自己生成的-1，累加为-1，降低1db。304-2帧，将2db，对应下行调度303-4/303-6，303-4是半静态初传，303-6 是动态初传，303-6基站侧发送TPC为0降低1db，307-4是UE自己生成的-1，累加为-2，降低2db。

其他情况类似，不停的有降1db出现。

上述UE自己的控制导致功率维持在较低水平，持续了5s，功率才抬上来。原因是33s的时候已经退出了半静态，没有了半静态调度时的UE自己的异常调整，在基站的调整下功率逐步抬升了。

基站侧数据可以看到34S反馈情况在变好。

此时，终端数据：没有看到DCI格式为1a的异常数据，每个200ms还收到基站侧的功率抬升命令，DCI 2a格式的。

【问题解决】
1、终端对激活半静态的TPC命令理解不正确，协议规定该TPC不是用于PUCCH功控的，而从终端的log上观察，终端应该错误的把该TPC理解成PUCCH降功率指示。
2、终端把半静态激活时理解的降-1db PUCCH功率，应用到后续的每次半静态调度上，导致PUCCH功率异常低，eNB无法检测到终端在PUCCH上发的信息，即检测出大量的DTX，从而导致重传。

本文整理自网络，文章版权归原作者所有，如有侵权，请联系我们进行删除。小编微信（gprshome201101）

长按下方二维码图片 > 识别图中二维码 > 关注“51学通信公众号”

51学通信接头方式如下：

51学通信联络邮箱: gprshome@163.com
管理员及站长”爱卫生”微信号 : gprshome201101
喜马拉雅听FM频道：51学通信
优酷频道地址：i.youku.com/51xuetongxin
淘宝店：51xuetongxin.taobao.com
直播地址：douyu.com/zhihu
51学通信网站：www.51xuetongxin.com
51学通信精品阅读：read.51xuetongxin.com
微信公众号：51学通信（ID：woyaoxuetongxin）