TDD SPS 常见问题小结

hanjin

Semi-Persistent Scheduling，简称SPS，半永久性调度，又称为半静态调度。与动态调度每个TTI为UE分配一次无线资源不同（通过PDCCH指定），SPS允许半静态配置无线资源，并将该资源周期性地分配给某个特定UE。简单地说，eNodeB在某个TTI使用SPS C-RNTI加扰的PDCCH指定UE所使用的无线资源（这里将其称为SPS资源），每过一个周期，UE就使用该SPS资源来收或发数据。eNodeB无需在该子帧（这里将其称为SPS子帧）下发PDCCH来指定分配的资源。
经常发生的问题：
1.        上下行SPS未能正常激活
2.        下行SPS数据传输异常
3.        上行SPS数据传输异常
以下是就之前在调试过程中发生的一些问题做的简单总结。
上下行SPS未能正常激活
SPS正常激活的流程是UE收到SPS-RNTI加扰的PDCCH, 且PDCCH 的字段满足36.213 协议Table 9.2-1的校验要求。所以一定要遵照协议要求去填写PDCCH的每个字段。

下行SPS数据传输异常
下行SPS调度数据发生异常，通常有两方面的问题，一是UE侧解码失败，二是UE侧正常,反馈的HARQ ACK在eNodeB侧被检测成了NACK 或DTX。
        UE 侧解码失败
如果信号质量足够好，但UE侧解码失败，那么就要检查一下调度器调度的是否正确了。UE 侧解码其实就是根据接收到的SPS-CRNTI 加扰的PDCCH去解码PDSCH，如果解码不正确需要去检查一下调度器，PDSCH 是否是和PDCCH匹配的。
        UE 侧正常反馈的HARQ, 但是基站侧检测错误
        HARQ 在PUCCH上反馈
1.        只有HARQ 在PUCCH上反馈
对于下行传输，如果接收到的DCI指示DL SPS激活，则DCI中的TPC command for PUCCH字段将指示UE从4个PUCCH资源中选择1个用于回复ACK/NACK。该4个PUCCH资源是通过SPS-ConfigDL的n1PUCCH-AN-PersistentList来配置的. 所以基站侧一定要在正确的PUCCH资源上检测HARQ. 之前调试时发生过UE反馈的HARQ明明是ACK, 但基站在PUCCH上检测出的是DTX， 最后发现是PUCCH 资源不匹配。基站侧还是在动态调度分配的PUCCH资源上检测HARQ，结果检测不到造成DTX.
2.        HARQ 和SR复用在PUCCH上反馈
协议上明确说明在动态调度时，如果HARQ ACK/NACK和SR 同时发送时，则在SR的资源上发送HARQ ACK/NACK. 但是对于SPS调度时HARQ究竟是在DCI中的TPC command for PUCCH字段指示的PUCCH资源上发，还是和动态调度一样，在SR资源上发并没有明确说明。后来根据UE log发现，当HARQ和SR 同时发送时，和动态调度一样，在SR的PUCCH资源上发送HARQ.
      当HARQ在PUCCH 上传输时一定要看UE反馈HARQ所用的PUCCH 资源是否和基站检测的PUCCH资源匹配。
        HARQ 在PUSCH上反馈
TDD 因为上下行不对称，所以采用bundling 或者 multiplexing的方式反馈HARQ。Aricent的协议栈目前只支撑bundling。 为了正确检测HARQ，基站侧需要知道有多少个下行传输。这个通过DCI0 的DAI，Nsps值来确定，动态调度时DAI值都会根据下行传输做动态更新，而 SPS数据传输时由于没有DCI，所以这个值要格外注意，DAI值一定要和实际的下行PDSCH(包括SPS调度的PDSCH)吻合才能正确解码HARQ.

上行SPS数据传输异常
         上行SPS数据解码如果不正确，首先要先检查UE是否正常发送了周期的SPS调度数据，如果UE正常发了，但基站没解码正确，还是要进一步检查调度器，确认PDCCH和PUSCH是否匹配，是否存在问题。

此文档还很不完整，由于时间有限，以及目前对SPS调试经验的局限，所以只对前期遇到的问题做了简单总结，日后再逐步完善。