寻呼次数
- 格式：docx
- 大小：61.81 KB
- 文档页数：7
一、概述网络侧要对一个手机进行寻呼，比如典型的，寻呼处于IDLE状态的UE建立CS呼叫连接，则网络侧要对PCH传输信道（其映射到SCCPCH物理信道）和PICH物理信道进行配置和内容填充。
对PCH来说，就是要填充合适的Paging Type 1消息发送出去；而对于PICH 来说，则要配置好Paging Occasion以及PI值，这样PCH和PICH相配合，就能寻呼到指定的UE。
我们先来看看系统信息广播中对PICH和PCH的描述情况。
有一个SIB5内容的实例，里面涉及到PICH的配置参数，摘录如下：sCCPCH-LCR-ExtensionsList {{pich-Info {timeslot 0,pichChannelisationCodeList-LCR-r4 {cc16-5,cc16-6},midambleShiftAndBurstType {midambleAllocationMode defaultMidamble : NULL,midambleConfiguration 4},repetitionPeriodLengthOffset rpp64-2 : 0,pagingIndicatorLength pi4,n-GAP f4,n-PCH 2}}}具体各个参数的含义，会在下面讲解时给出相应的解释。
在这里先提前说明一下，下面讲到的物理层和协议栈行为并没有具体区分发送端NodeB和接收端UE，并且描述时可能偏向某一方来进行，实际上不论是发送端还是接收端，都要按照描述的准则分别做动作，这一点请大家注意。
二、物理层行为有了以上的配置参数，我们从物理层面说说PICH的信道结构以及与PCH的时序关系。
PICH 固定的占用两个码道，如示例中的cc16-5和cc16-6，并处于下行时隙0中。
在一帧之内，即连续两个子帧，该PICH BURST共有N PIB=352个比特可以用来携带寻呼指示，如图1所示。
图1 PICH BURST中寻呼指示的分配情况N PIB=352个比特是指寻呼指示经过编码之后的总比特数，而不是说一帧里可以存放352个寻呼指示，实际的寻呼指示个数N PI是N PIB除以每个寻呼指示的编码长度（比特）后的结果，而每个寻呼指示的编码长度在SIB5中已经给出，即pagingIndicatorLength对应的值pi4，单位是bit，所以我们可以算出一帧中寻呼指示的个数N PI= N PIB/4=88。
至于协议上提到的L PI，意思是一个寻呼指示所对应的符号长度，因为是QPSK调制，一个符号对应两个比特，所以在本例中L PI=2，意思是一样的。
基于协议上的表示方法，存在如下关系式：N PIB = 2*N PI*L PI，对应生成如下的表格：表1 不同的寻呼指示长度与相应的每帧寻呼指示个数对应表为了与后面讲到的PI形成区分，这里提到的寻呼指示用符号P q（q = 0, ..., N PI-1, P q Î {0, 1}）来表示。
所以我们从上面的分析可以知道，当P q为0或1时，对应映射成2*L PI个连续重复比特，如表2所示：表2 寻呼指示的比特映射表上面讲的是一帧里面PICH的配置情况，实际上在传输中，PICH都不是单帧出现的，而是以PICH Block的形式出现，一个PICH Block包含了N PICH个连续帧，N PICH数值也在SIB5中广播，即repetitionPeriodLengthOffset中的Length，所以本例中N PICH=2，即一个PICH Block中含有2个连续的帧，每帧中都带有寻呼指示，这样总的寻呼指示个数N P就可以表示成N P=N PICH*N PI，如图2所示。
图2 一个PICH Block的结构针对某个特定的UE，上层协议会根据相关参数计算出该UE的PI值（PI = 0, ..., N P-1），具体的计算方法放在后面上层协议栈部分里讲。
这里的PI是指在一个PICH Block中其相对于总的寻呼指示个数N P的索引值，而不是之前所说的具体每一个寻呼指示，所以为什么在前面我们会用符号P q来表示每一个寻呼指示，就是为了和这里的PI形成区别，以免引起混淆（初学的人在这点上很容易混淆）。
当知道了这个UE的PI值之后，如何定位是处在PICH Block中的什么位置呢？因为只有知道了这个位置，NodeB才能正确地设置相应位置的寻呼比特为“1”，从而寻呼到UE。
其实这个不难，当前PI值处于PICH块的第几帧可以由公式n = PI div N PI给出，进而，在此帧中的偏移值即P q的下标q可以由公式q = PI mod N PI给出。
说完了PICH，接着谈谈PCH。
PCH实际上都是以PCH Block的方式出现的，每个PCH Block 包含了N PCH个寻呼子信道。
N PCH也是由SIB5广播的，在本例中N PCH = 2。
每一个寻呼子信道映射到两个连续的PCH帧上，UE所携带的层3信息Paging Type 1就是在相应的寻呼子信道里发送的。
寻呼子信道以及PCH和PICH的时序关系，如图3所示。
图3 寻呼子信道以及PICH和PCH的时序关系图有上面的图可以看出，一个Paging Block包含了一个PICH Block和一个PCH Block。
如果在PICH Block中的某个寻呼指示被设置为“1”，那么和该寻呼指示相关的UE就会去读该PCH Block内相应的寻呼子信道。
PICH Block的结尾和PCH Block的开始之间的空隙帧数N GAP也是由SIB5广播，在本例中其值为4。
三、上层协议栈行为我们知道，在一个小区里，可能会建立一个或者多个PCH传输信道，而PCH是映射到物理信道SCCPCH上的，每一个SCCPCH物理信道可能会携带最多一个PCH传输信道（也有可能没有），所以一个小区中也会有一个或者多个SCCPCH物理信道。
同时，对于每一个PCH，都有一个唯一的PICH与之对应。
于是问题就来了，NodeB和UE该选择哪一个PCH（SCCPCH）和与之相应的PICH来发送和接收寻呼呢？这里就要用到寻呼信道的选择准则。
UE从SIB5中所列的SCCPCH信道中进行选择是基于UE的IMSI，计算公式如下：选择的SCCPCH索引= IMSI mod K，其中，K等于携带PCH的SCCPCH的个数，仅仅携带FACH的SCCPCH不计算在内。
这些SCCPCH的索引按照其在SIB5中出现的顺序来定，范围是0到K-1。
一旦SCCPCH选定了，则SCCPCH携带的PCH以及与PCH对应的PICH都确定了，NodeB 和UE就可以使用它们了。
如果SIB5中SCCPCH就一个的话，上面的公式就不用使用了，直接选择这一个即可。
如果UE没有IMSI，比如UE在没有USIM卡的情况下进行紧急呼叫，此时IMSI的数值默认为0。
找到了要使用的PCH和PICH，上层协议栈只完成了第一步，接下来还要计算出该UE的PI值，以便NodeB在PICH相应的位置设置成“1”；同时由于是不连续接收DRX，还要计算出相应的Paging Occasion和Paging Message Receiving Occasion，这样上层协议栈的任务才算结束。
下面就来谈谈这些东西。
UE使用DRX的好处就是省电，并定义了DRX周期，其值等于MAX(2k, PBP)，单位是帧。
其中k就是DRX周期长度系数，在IDLE状态下使用SIB1中广播的值，范围是6到9，比如取k = 6；在连接状态（CELL_PCH和URA_PCH）下k的选取和IDLE下有所不同，因为不是重点，不再多说，有兴趣的可以看25.304协议。
PBP就是Paging Block周期，在TDD情况下等于PICH的重复周期，在本例中PBP = 64。
所以综合来看，DRX的周期就是64，即每64帧UE在Paging Occasion接收一下寻呼，其余的时间处于睡眠状态。
Paging Occasion的定义就是，参照图3，一个Paging Block的第一帧的SFN值，其计算公式如下：Paging Occasion = {(IMSI div K) mod (DRX周期div PBP)} * PBP + n * DRX 周期+帧偏移，其中n = 0,1,2…，K就等于上面说的PCH选择时的K值，帧偏移就是PICH的帧偏移，在SIB5中给出，本例中偏移值为0；其余的参数在前面都已经介绍了。
如果UE没有IMSI，比如UE在没有USIM卡的情况下进行紧急呼叫，此时IMSI的数值默认为0，DRX周期默认为256（2.56s），再应用上面的公式。
UE对应的PI值（即在PICH中的索引值）的计算公式如下：PI = DRX Index mod Np，这里DRX Index = IMSI div 8192，Np就是前面介绍的一个Paging Block中总的寻呼指示个数。
有了PI值，NodeB就可以在PICH Block中相应位置设置比特为“1”，见上面物理层部分的讲解。
同时根据PI值在PCH Block中相应位置填充Paging Type 1消息的ASN.1码流，这里就要用到下面讲到的Paging Message Receiving Occasion，其定义为：Paging Message Receiving Occasion =Paging Occasion + N PICH + N GAP + {(DRX Index mod Np) mod N PCH } *2各个参数的意义在前面都已经介绍了，Paging Message Receiving Occasion的定义就是UE接收实际寻呼消息的帧号，参照图3，我想大家都能看明白公式的意义，不再赘述。
最后，NodeB和UE都按照上述的公式和准则进行发送和接收，如果UE在DRX周期内的Paging Occasion，检测到其相应的寻呼指示P q值为1，则根据Paging Message Receiving Occasion去定位读取PCH信道承载的数据内容，此时还不能说明这个寻呼是自己的。
经过RRC层ASN.1解码，得到完整的Paging Type 1消息，UE还要查看消息中的Paging record list中的Paging Identity是否有和自己匹配的，如果有则接收此寻呼过程，如果没有则忽略此次寻呼，好像没有接收到一样。
至于UE接收到Paging Type 1消息后的处理，包括根据消息IE设置的不同，还可能含有通知UE小区系统信息发生改变的功能，由于Paging Type 1消息比较简单，IE内容不太复杂，UE处理流程也很容易理解，在此就不再叙述了，有兴趣的话可以查看3GPP 25.331协议。
