eMTC 寻呼信道增强

在Rel-13 eMTC中，寻呼的监控存在一些问题，导致UE功耗增加。这两个问题是无法执行MPDCCH早期检测和由于MPDCCH在不同寻呼场合之间重叠而导致的误报。这些问题可以在Rel-14中通过在规范中引入一些最小的更改来解决。

与用于常规PDSCH的MPDCCH不同，用于paging的MPDCCH只能在寻呼场合启动。作出这一决定是为了能够早期检测到MPDCCH的存在，从而实现良好的覆盖。这对于寻呼信道至关重要，因为eNB不知道给定UE的实际覆盖增强级别，因此，MPDCCH被确定为覆盖最坏情况的UE。

这种早期检测背后的基本原理如下：UE可以确定RSRP/RSRQ值，并且基于此，确定正确解码它所需的MPDCCH重复次数。如果在该重复次数之后没有解码MPDCCH，则UE可以确定没有MPDCCH存在并返回睡眠。例如，处于良好覆盖的UE可以确定单个子帧足以解码MPDCCH，并且如果没有正确解码，则可以返回睡眠。

然而，这种方法需要知道MPDCCH的功率电平，这不能从测量的RSRP/RSRQ获得。这是由于用于CRS的端口和用于MPDCCH传输的端口不相同，因此UE不能仅仅基于所测量的CRS功率对MPDCCH端口进行任何假设。UE可以假设两个端口使用相同的功率，但是这可能导致UE行为不可预测的一些情形：

• 如果eNB功率提升CRS并且向MPDCCH提供较少的功率，则UE可以确定当MPDCCH实际存在时不存在MPDCCH（例如，UE确定其需要1个SF来解码，但实际上将需要2个）

• 如果eNB提升MPDCCH功率，UE保持唤醒的时间可能比需要的时间长，从而导致不必要的功率消耗（例如，UE确定其需要128次重复解码，但是eNB实际上正在将MPDCCH提升3dB，因此它将只需要64次重复）。

解决这个问题的简单方法是在SIB中引入CRS端口和MPDCCH端口之间的某种关系。例如，功率偏移值（例如{3，0，3}dB）可以包括在SIB2中，以便UE可以正确地评估解码MPDCCH所需的重复次数。

在eMTC中，寻呼消息通过MPDCCH调度的PDSCH传送。由于覆盖增强的需要，控制和数据信道都可以重复。在许多情况下，特别是由于大量的UE，eNB可以配置大量的PO/PF以增加寻呼容量。在这种情况下，并且如果PO之间的间隔小于256个子帧，则用于第一个PO的MPDCCH可以与第二个PO重叠。这给UE在第二次寻呼场合造成了混乱，当MPDCCH属于前一个PO时，它将解码MPDCCH并将其解释为自己的PO。

在解码MPDCCH之后，UE将尝试解码相应的PDSCH，从而产生不必要的功耗增加。在图1中，给出了这个问题的一个例子：

• eNB为PO1发送MPDCCH。PO1中的UE 1解码MPDCCH和相应的PDSCH。

• MPDCCH与PO2重叠。PO2中的UE 2解码对应于PO1的MPDCCH。它解释DCI的内容并尝试解码PDSCH。

如果UE2没有这个错误警报，它将只监视自己的po2，确定没有MPDCCH，然后返回睡眠。由于MPDCCH产生的混乱，UE在更长的时间内处于唤醒状态，因为它需要解码PDSCH。

协议同意增加nB的范围，以防止发生这种错误警报，然而，这个解决方案只解决了部分问题，因为它强制使用长DRX和少量的寻呼场景。此解决方案有两个主要缺点：

1. 不同的PO之间的大间隔：为了防止发生混淆，不同的PO（从网络角度来看，可能是针对不同的UE）必须被至少256个有效的下行子帧分隔。对于TDD小区（例如，带有UL/DL 配置1） ，由于减少了下行子帧的数量，该数字必须乘以系数2。

2.  使用很长的DRX值：应用该解决方案可能会导致使用不必要的长DRX值。一些eMTC UE（例如可穿戴设备、控制应用）可能需要更低的时延要求。如果所有UE被迫使用长DRX值来避免这种混淆，则这些要求可能无法满足。

3. 为最坏情况UE设计的网络：在典型部署中，需要MPDCCH大量重复的UE的数量（例如256）预计相当小。如果我们强制PO被这个大的值隔开，那么大多数UE的寻呼将由于需要避免歧义而被不必要地延迟。

4. 减少PO的数量：当寻呼概率小时，从功耗的角度来看，拥有更多的UE group是有益的。这种小的寻呼概率预期用于主要是MO业务的情况，其中给定UE的数据很少，或者在具有少量UE的小区（例如，small cell）中。例如，如果网络需要寻呼单个UE，则将解码该MPDCCH的UE的分数是1/N，其中N是DRX周期中的PO的数目。因此，较大数量的PO可能有利于降低UE功耗。

所以，建议的解决方案是，在MPDCCH中引入一种特定于PO的加扰。MPDCCH的加扰序列的初始化如下：