LTE paging注释

每次切版本，首先都是想到的是调试paging。

搞清楚几个问题：1、paging传输过程信道映射关系

                                 2、paging是如何触发的？

                                 3、paging发送周期多少？里面都带有什么东西？   paging的周期有SIB2中配置参数决定。默认1280ms,和idle态DRX周期一致。

网络可以向空闲状态和连接状态的UE发送寻呼，寻呼过程可以由核心网触发，用于通知某个UE接收寻呼请求；或者由eNodeB触发，用于通知系统信息更新，以及通知UE接收ETWS以及CMAS等信息。LTE中的paging是一项重要行为。

t-transform: none; white-space: normalPaging 消息的作用包括：

（1）向处于 RRC_IDLE 态的 UE 发送呼叫请求；

（2）通知处于RRC_IDLE 和 RRC_CONNECTED 态的 UE，系统信息发生了变化；

（3）通知 UE 开始接收 ETWSprimary 通知和/或 ETWS secondary 通知；

（4）通知 UE 开始接收 CMAS 通知。

（1）eNodeB侧触发

eNB触发的paging，一般分为，IDLE状态和Connected状态，典型的场景，就是SIB消息的更新。

显然，这时候的paging消息比较简单，只有一个IE，告诉UE，系统消息改变，需要重新读取SIB消息。

在IDLE下，UE会将所有SIB都读取；而在Connected状态下，只读取SIB1,2.

PCH（Paging CHannel）用于传输来自 PCCH 逻辑信道的 Paging 信息。 PCH 传输信道直接映射
到 PDSCH 物理信道，与 DL-SCH 数据共同参与下行调度。 Paging 消息的内容如下：

Paging ::= SEQUENCE {
pagingRecordList PagingRecordList OPTIONAL, --
Need ON------被寻呼的UE列表
systemInfoModification ENUMERATED {true} OPTIONAL, --
Need ON------如果存在，指示一个除SIB10、SIB11、SIB12外的系统消息变更
etws-Indication ENUMERATED {true} OPTIONAL, --
Need ON------如果存在，指示一个ETWS primary notification和/或ETWS secondary notification
nonCriticalExtension Paging-v890-IEs OPTIONAL
}
Paging-v890-IEs ::= SEQUENCE {
lateNonCriticalExtension OCTET STRING OPTIONAL, -
- Need OP
nonCriticalExtension Paging-v920-IEs OPTIONAL
}
Paging-v920-IEs ::= SEQUENCE {
cmas-Indication-r9 ENUMERATED {true} OPTIONAL, --
Need ON------如果存在，指示一个CMAS notification
nonCriticalExtension SEQUENCE {} OPTIONAL -
- Need OP
}
PagingRecordList ::= SEQUENCE (SIZE (1..maxPageRec)) OF PagingRecord     //一个paging里最多包含16个ue
PagingRecord ::= SEQUENCE {
ue-Identity PagingUE-Identity,------指示被寻呼的UE的NAS ID，唯一地
指定一个UE
cn-Domain ENUMERATED {ps, cs},
...
}
PagingUE-Identity ::= CHOICE {
s-TMSI S-TMSI,
imsi IMSI,------International Mobile Subscriber Identity的简称。
一个全球唯一的永久性的用户标识
...
}
IMSI ::= SEQUENCE (SIZE (6..21)) OF IMSI-Digit
IMSI-Digit ::= INTEGER (0..9)
只有处于 RRC_IDLE 态的 UE，才会读取pagingRecordList 中的信息。
为了接收来自 eNodeB 的 Paging 消息，处于 RRC_IDLE 态的 UE 会监听使用 P-RNTI（值为
0xFFFE）加扰的 PDCCH。

（2）EPC侧触发

当UE处于空闲态，而EPC需要和UE进行交互，网络侧也是通过paging来告知UE。这时候UE只有监听到paging消息才能进行后续响应，而UE不可能一直都在监听paging消息。类似Connected的DRX的，这时候，UE和EPC也会协商时间去监听paging消息，这就是IDLE下的DRX。

EPC会将paging消息发给同一个TAC下面的eNB，由PCCH-PCH-PDSCH下发给UE。UE收到的寻呼消息中如果带有UEID列表，终端需要用自己的UE ID来跟寻呼消息中携带的UE ID进行匹配，以判断此寻呼消息是否是在呼叫自己。

在寻呼消息中如果所指示Paging ID是S-TMSI，则表示本次寻呼是一个正常的业务呼叫；如果PagingID是IMSI，则表示本次寻呼是一次异常的呼叫，用于网络侧的错误恢复，此种情况下终端需要重新做一次附着(Attach)过程。Paging的消息如下：

 另一方面，UE之前通过读取SIB2中的pcch-config，得到了pcch的基本配置，通过算法，UE就会知道如何去监听paging消息。

defaultPagingCycle：缺省寻呼周期，这里是128无线帧。

nB：寻呼周期数量。

从本质上讲，寻呼过程就是网侧在特定的时刻向UE发送寻呼消息，通知UE执行相应的操作或者更新相关的参数。无论UE处于IDLE态，还是连接态，都可以接收来自网侧的寻呼消息：处于RRC连接态的UE，可以通过解码寻呼消息来判断当前的系统信息是否有改变（system information change），UE一旦检测到系统信息有改变，就会重新去解读系统信息；而处于RRC空闲态的UE，除了可以获知当前的系统信息是否有改变外，还能知道当前是否有本UE的来电（incoming call），UE一旦检测到有来电，后续将会触发随机接入过程。关于随机接入的内容，请参考《LTE-TDD随机接入过程（1）-目的和分类》等相关博文。

除此之外，无论是IDLE态还是连接态，如果UE能力支持的话，还可以通过寻呼消息判断是否需要接收ETWS（Earthquake and Tsunami Warning System，地震海啸告警系统）和CMAS（Commercial Mobile Alert Service，商用移动警报业务）信息。寻呼消息的内容如图1所示，其中S-TMSI和IMSI都可以用来标识UE。S-TMSI的全称是SAE-Temporary Mobile Subscriber Identity，出于安全考虑，在寻呼过程中主要使用S-TMSI来标识UE。maxPageRec值固定等于16，表示一条寻呼消息最多可以寻呼16个UE，这个值在计算寻呼容量的时候需要考虑。

需要注意的是，由于寻呼消息是使用P-RNTI加扰的，同个小区内所有的UE都可以解码得到，不同的UE如果发现寻呼消息中包含了系统信息变更或者有ETWS、CMAS的消息指示，都需要进行相应的处理，这个时候UE是不需要将自己的S-TMSI或IMSI与寻呼消息中的标识进行比较的。

Paging 支持非连续接收（Discontinuous Reception，DRX），使得处于 RRC_IDLE 态的 UE 只在预先定义好的时间段内“醒来”以接收 Paging 消息，而在其它时间可以保持“休眠”状态，这样就能够降低功耗，提升 UE 的电池使用时间。这个DRX是idle太的DRX，不是connect 太的DRX。

可以查看金辉大神博客关于计算paging的时频资源，非常详细，

需要用到的配置参数有两个：一个是paging的周期，这个是idle态的DRX周期一样，DRX周期有两个，一个是SIB2里面配置PCCH里面带的，还有一个由 MME 通过 IE:Paging DRX 来配置的，用的时候取小的。

PCCH-Config ::= SEQUENCE {
defaultPagingCycle ENUMERATED {
rf32, rf64, rf128, rf256},------默认的DRX cycle，对应36.304中定义的“T”。其中rf32对应32个系统帧，rf64对应64个系统帧，以此类推
nB ENUMERATED {fourT, twoT, oneT, halfT, quarterT,
oneEighthT,
oneSixteenthT, oneThirtySecondT}------nB用于推导PF和PO（见36.304）。fourT对应4 * T，twoT对应2 * T，以此类推
}
第二个是nB, 表示一个DRX周期里面有多少个PO，（这个要么是周期的倍数2、4，要么是周期的约数1/2,1/4,1/8,1/16），可以表示当前paging的多少。值越大，paging越多。

PF是发送paging的系统帧号，PO是发送paging的系统子帧号。一个DRX周期内有多少个N_PF, N_PF=min(paging周期、nB)。PO 这个子帧号跟UE的imsi有关。

若是周期T为32个系统帧，nB=1/2T, 则N_PF=16, 若nB=2T, 则N_PF=62

然后根据公式查表（TDD和FDD查表时有区别），就可以知道在一个DRX周期内，在几号帧几号子帧去发送paging, 在哪个子帧上发送和UE的imsi有关，不同UE在不同的子帧号上发送paging, 需要注意的是，由于寻呼消息是在PDSCH信道中传输的，因此对于TDD制式下Ns=4的场景，此时每个PF系统帧中有4个子帧（0、1、5、6子帧）可以发送寻呼消息，但子帧1和子帧6是特殊子帧，不一定能发送PDSCH数据，这需要依赖于当前的特殊子帧配置：如果特殊子帧配置是0、5，且下行CP类型是Normal，或者特殊子帧配置是0、4，且下行CP类型是Extended，那么不能在该特殊子帧中发送PDSCH数据（包括寻呼消息）。

UE 在 DRX cycle 内并不知道上行 timing，所以不能进行 HARQ 确认，也不能进行 HARQ 软合并。即 Paging 不支持 HARQ。

NodeB 侧同样需要计算特定 UE 的 DRX cycle、 PF 和 PO，这样 eNodeB 才能只在对应的 PO 上给 UE 发送 Paging 消息。

每次paging里面可以携带多少个UE paging, 有ENB自己控制，默认最多16个。16个ue可以同时在PF上的PO去监听解码paging pdcch。每个PO上传多少个UE，有多少个PO，就可以传出paging的容量。

处于 RRC_IDLE 态的 UE 在 DRX cycle 内的绝大部分时间里是休眠的，而只在对应 PF 的对应 PO 上醒来，去监听使用 P-RNTI 加扰的 PDCCH。如果 UE 在 PO 上检测到使用 P-RNTI 加扰的PDCCH，UE 会去读取 pagingRecordList 中的每一个PagingRecord，PagingRecord中包含了被寻呼的 UE 的标志ue-Identity。 如果 UE 发现自己的 UE 标志与某个ue-Identity 一致，就会把ue-Identity和cn-Domain 发往上层继续处理。如果 UE 没有找到一个与其 UE 标志一致的ue-Identity，UE 会丢弃接收到的 Paging 消息，并进入休眠。