TD网络指标提升专题-寻呼专题(针对大唐TD区域)

网络指标提升专题-寻呼专题
目录
1. 概述 (3)
1.1. 编写目的 (3)
1.2. 预期读者与建议 (3)
2. 寻呼原理 (3)
2.1.寻呼类型1（Paging Type 1） (3)
2.1.1. 寻呼块描述 (3)
2.1.2. 寻呼过程描述 (4)
2.2.寻呼类型2（Paging Type 2） (6)
3. 寻呼流程及相关参数 (7)
3.1.寻呼成功率定义 (7)
3.2.寻呼流程 (7)
3.1.1. CN寻呼 (7)
3.1.1.1. CN发起的寻呼类型1 (7)
3.1.1.2. CN发起的寻呼类型2 (8)
3.1.2. RNC寻呼 (8)
3.1.2.1. 系统信息更新发起的寻呼类型1 (8)
3.1.2.2. 小区更新发起寻呼类型1 (9)
3.1.2.3. 释放CELL_PCH/URA_PCH用户发起的寻呼类型1 (9)
3.3.寻呼相关参数介绍 (10)
3.2.1. 寻呼信道配置 (10)
3.2.2. RNC侧重发次数 (12)
4. 寻呼容量计算（Paging Type 1消息） (14)
4.1.理论计算公式 (14)
4.2.现网寻呼容量计算 (15)
5. 寻呼问题分析流程 (15)
5.1.UE没有收到寻呼消息问题分析 (17)
5.2.问题分析定位思路小结 (19)
6. 案例分析 (20)
6.1.案例1：呼叫未接通问题分析 (20)
1.概述
1.1.编写目的
在TD系统中，影响接入成功率的一类问题就是寻呼问题，解决寻呼问题对于提升接入指标和提高用户满意度很有帮助。

本文档旨在帮助TD无线网络规划优化相关的人员了解TD 寻呼原理和机制，并掌握常见寻呼问题的分析思路。

1.2.预期读者与建议
从事TD无线网络规划优化相关的人员。

2.寻呼原理
为了完成一次被叫业务（CS业务、PS业务和短信业务等），就需要网络侧对注册用户终端进行寻址和通知，这样的过程就是寻呼过程。

在TD系统中，寻呼可以由CN发起也可以由RNC发起。

CN发起的寻呼主要用于对用户进行寻址和通知，并建立相应的信令连接，以进行一次被叫业务（CS业务、PS业务和短信业务等）；RNC发起的寻呼主要用于告知特定状态下的注册用户：系统消息更新（IDLE/CELL_PCH/URA_PCH状态），小区更新（CELL_PCH/URA_PCH状态）或者RRC连接释放（CELL_PCH/URA_PCH状态）。

CN发起寻呼时并不区分寻呼类型，仅注明寻呼的范围是位置区、路由区还整个MSC。

与之不同的，RNC发起寻呼或是收到CN下发的寻呼时，会根据寻呼消息内容以及寻呼用户所处的UE状态来决定寻呼的类型和范围。

寻呼的类型分为寻呼类型1（Paging Type 1）和寻呼类型2（Paging Type 2）。

如果被寻呼的UE处于IDLE/CELL_PCH/ URA_PCH状态，RNC将通过PCCH信道发一个寻呼类型1（PAGING TYPE 1）消息给此UE；如果被寻呼的UE处于CELL_FACH / CELL_DCH状态，RNC将通过DCCH 信道发一个寻呼类型2（PAGING TYPE 2）消息给此UE。

寻呼的范围分为位置区（LA）范围、路由区（RA）范围、UTRAN网络注册区（URA）范围和小区（Cell）范围。

如果被寻呼的UE处于IDLE状态，RNC将在位置区或路由区范围寻呼该UE；如果被寻呼的UE处于Cell_PCH/ Cell_FACH/ Cell_DCH状态，RNC将在小区范围寻呼该UE；如果被寻呼的UE处于URA_PCH状态，RNC将在URA区范围寻呼该用户。

由此可见，TD系统相较GSM而言，核心网侧的寻呼方式并没有任何的差异，只是TD 系统的接入网在实现上更多考虑了系统容量的节省进而采用了最小范围寻呼的思想。

2.1.寻呼类型1（Paging Type 1）
2.1.1.寻呼块描述
网络依据寻呼块周期（PBP）调度寻呼信息，UE按照非连续接收周期（DRX cycle）监测寻呼信息。

如图1所示，一个寻呼块由一个PICH Block和一个PCH Block组成。

若PICH块中某个寻呼指示位（PI）被设置成'1' ，则表示与该PI对应的UE应该在同一个寻呼块的PCH Block
中相应的寻呼子信道上读取它的寻呼信息（N PICH 、N PCH 、N GAP >0均由高层配置，并在SIB5/6中广播给UE ）。

PCH Block 的一个子信道由两个连续的PCH 帧组成，RNC 的RRC 层发给UE 的寻呼消息在特定的子信道上发送。

寻呼子信道和寻呼指示由高层分配，但独立进行。

PICH
N PICH N GAP 2*N PCH Paging Block
PCH Block
PICH Block
图1 寻呼子信道和相应的PICH / PCH 块
2.1.2. 寻呼过程描述 一个完整的寻呼类型1（Paging Type 1）消息处理流程包括以下几个步骤：
第1步：确定寻呼范围
RNC 发起寻呼或是收到CN 下发的寻呼时，会根据寻呼消息内容以及寻呼用户所处的UE 状态来决定寻呼的类型和范围。

来自CN 的寻呼，若寻呼的UE 处于IDLE 状态，且此寻呼请求消息中带了LAI/RAI 信息，RNC 将根据LAI/RAI 与小区的映射关系，找出当前LAI/RAI 下所有的激活小区；若该寻呼请求消息中没有带LAI/RAI 信息，RNC 将认为当前RNC 内所有激活小区都是需要发送寻呼的小区。

来自CN 的寻呼/RNC 用于小区更新的寻呼/ RNC 用于释放RRC 连接的寻呼，若寻呼的UE 处于CELL_PCH 状态，则根据该UE 最后一次小区更新的结果，RNC 就可确定需要发送寻呼的小区。

来自CN 的寻呼/来自RNC 用于小区更新的寻呼/来自RNC 用于释放RRC 连接的寻呼，若寻呼的UE 处于URA _PCH 状态，则RNC 根据该UE 最后一次URA 更新的结果，确定出UE 当前所属的URA ，然后再根据URA 与小区的映射关系，将当前URA 下所有的激活小区都看作是需要发送寻呼的小区。

来自RNC 用于通知系统信息发生改变的寻呼，其系统信息变化的小区就作为要寻呼的小区。

第2步：选择一个PCH
一个小区中可以有多个PCH ，一个PCH 映射在一个SCCPCH 上，一个PCH 有唯一的PICH 与其相关联。

一个小区中可以有多个SCCPCH ，因此，RNC 在处理寻呼之前先要确定该寻呼所在的PCH ，即该PCH 映射的SCCPCH （PCH 与SCCPCH 的映射信息，以及PICH 的信息在SIB5/6中广播给UE ）。

系统信息更新引起的寻呼类型1（Paging Type 1）消息不需要选择PCH 。

为了使小区内IDLE/CELL_PCH / URA_PCH 状态的UE 都能监测到这种寻呼消息，RNC 会在当前小区的所有PCH 上调度寻呼信息。

承载寻呼类型1（Paging Type 1）消息的PCH 信道的选择方法与UE 状态有关，寻呼IDLE 状态UE 时选择PCH 信道的方法与寻呼CELL_PCH / URA_PCH 状态UE 时选择PCH 信道的方法
不同，具体计算如公式1和公式2所示。

公式1: IDLE状态UE选择PCH信道的原则
"Index of selected SCCPCH" = IMSI mod K
公式2: CELL_PCH / URA_PCH状态UE选择PCH信道的原则
"Index of selected SCCPCH" = U-RNTI mod K
其中，K 等于列出的携带PCH信息的SCCPCH 信道个数，这些SCCPCH 应该以它们在SIB5/6 中出现的顺序从0 到K-1进行索引。

若终端没有IMSI（对应UE中无USIM），那么取IMSI=0。

第3步：计算寻呼时刻
由于IDLE/CELL_PCH / URA_PCH状态的UE采用DRX方式，每个DRX cycle到来时，UE首先读取PICH ，然后根据PICH中该UE对应PI的取值决定是否需要在PCH上读取寻呼信息。

UE开始读取PICH的时刻，就是寻呼时刻（Paging Occasion）。

对于RAN网络来说，它需要在Paging Occasion将相应的寻呼指示位图（PI Bitmap）放在PICH上。

Paging Occasion给出了寻呼块第一帧的SFN，即PICH Block起始位置的SFN。

对于系统信息更新引起的寻呼类型1（Paging Type 1）消息，由于该消息用于通知小区内所有IDLE/CELL_PCH/URA_PCH状态UE系统信息发生改变，它面向的是整个小区。

因此，为了增加寻呼的成功率，RNC可以将每个寻呼块周期都作为寻呼时刻。

寻呼类型1（Paging Type 1）消息的Paging Occasion的计算方法如公式3所示。

公式3: 寻呼时刻（Paging Occasion）的计算原则
Paging Occasion = {(IMSI div K) mod (DRX cycle length div PBP)} * PBP
+n * DRX cycle length + Frame Offset
其中，n = 0,1,2… 使寻呼时段值小于最大SFN的整数。

DRX cycle length的单位为帧。

PBP 为PICH Block的重复周期，该参数在SIB5/6中广播给UE。

Frame Offset为PICH Block的帧偏移，该参数在SIB5/6中广播给UE。

值得注意的是，空闲状态和CELL_PCH / URA_PCH状态下，DRX cycle length的计算方法不同：
对于IDLE状态UE：
DRX cycle length = MIN (CS specific DRX cycle length, PS specific DRX cycle length)；
对于CELL_PCH / URA_PCH状态UE：
DRX cycle length = MIN (UTRAN DRX cycle length ，CS specific DRX cycle length和/或
PS specific DRX cycle length)
其中，
⏹UTRAN DRX cycle length = MAX (2k, PBP)
k = UTRAN DRX Cycle length coefficient，k的取值范围(3…9)。

在RRC CONNECTION SETUP消息中是必选项，在CELL UPDATE CONFIRM/URA UPDATE CONFIRM/PHYSICAL CHANNEL RECONFIGURATION/RADIO BEARER RECONFIGURATION/RADIO BEARER RELEASE/RADIO BEARER SETUP/TRANSPORT CHANNEL RECONFIGURATION消息中是可选项。

⏹CS specific DRX cycle length = MAX (2k, PBP)
k = CS domain specific DRX cycle length coefficient，k的取值范围(6…9)。

指的是CS域的DRX cycle length coefficient，在SIB1中广播给UE。

⏹PS specific DRX cycle length = MAX (2k, PBP)
k = PS domain specific DRX cycle length coefficient，k的取值范围(6…9)。

指的是PS域的
DRX cycle length coefficient，在SIB1中广播给UE。

第4步：计算寻呼指示
UE每DRX cycle监测一次PICH，目的是为了读取PI Bitmap，根据它所对应的PI值确定是否需要进一步读取PCH。

因此，当有寻呼到来时，RNC需要将更新后的PI Bitmap发给NodeB。

PI的计算方法如公式4所示。

公式4: PI的计算原则
PI = DRX Index mod Np
其中，
DRX Index = IMSI div 8192。

N P = N PI * N PICH，表示一个PICH Block中所有PI的数目。

N PICH表示一个PICH Block中PICH帧数，该参数在SIB5/6中广播给UE
N PI表示一个PICH帧中寻呼指示的数目，它的值可由表1得到。

其中，L PI的取值在SIB5/6中广播给UE。

表1: 每个无线帧中PI长度为L时对应的N
第5步：计算寻呼接收时刻
若UE发现PICH中对应的PI值为1，则它要在合适的时刻在PCH上读取具体的寻呼信息，这个合适的时刻就是寻呼接收时刻（Paging Message Receiving Occasion）。

具体的计算方法如公式5所示。

公式5：Paging Message Receiving Occasion的计算方法
Paging Message Receiving Occasion =Paging Occasion + N PICH + N GAP
+ {(DRX Index mod Np) mod N PCH} *2
其中，
DRX Index = IMSI div 8192。

N PICH为PICH Block的长度，它等于在系统信息中给出的PICH 重复长度，该参数在SIB5/6中广播给UE。

N GAP为寻呼块PICH Block的最后一帧与PCH Block第一帧间相隔的帧数，该参数在SIB5/6中广播给UE。

N PCH为PCH Block中寻呼子信道的数目，最大值为8，该参数在SIB5/6中广播给UE。

2.2.寻呼类型2（Paging Type 2）
对于处于CELL_FACH /CELL_DCH 状态的UE，UTRAN在DCCH上使用AM RLC给UE发PAGING TYPE 2消息来发起一个专用寻呼过程。

如果没有特别说明，通常若另一个RRC过程正在进行，UTRAN仍然可以发起一个UE专用寻呼过程。

专用寻呼的原因与寻呼类型1类似，都是为了在某个域上建立业务或信令。

如果高层没有给出寻呼的原因，UTRAN将该寻呼原因置为"Terminating – cause unknown"。

3.寻呼流程及相关参数
3.1.寻呼成功率定义
寻呼成功率一般由CN进行统计，寻呼成功率定义如下：
寻呼成功率=寻呼成功次数总和/寻呼请求次数总和*100% 其中，
寻呼成功次数总和：指CN收到的所有寻呼响应的总次数，统计消息为CN 收到的“PAGING RESPONSE”(含二次寻呼的响应)消息。

寻呼请求次数总和：指CN发出的所有寻呼的总次数，统计消息为CN发出的“PAGING REQUEST” (不包含二次寻呼的次数)消息。

3.2.寻呼流程
寻呼
CN发起寻呼时并未区分寻呼类型，寻呼类型是由RNC根据寻呼用户所处的不同的UE 状态来决定。

发起的寻呼类型1
收到CN下发的寻呼后，RNC对寻呼用户的状态进行判断。

若寻呼用户处于IDLE/CELL_PCH/ URA_PCH状态，则RNC在PCCH信道上发送PAGING TYPE 1消息。

具体流程参见图2。

图2 CN发起寻呼类型1
发起的寻呼类型2
收到CN下发的寻呼后，RNC对寻呼用户的状态进行判断。

若寻呼用户处于CELL_FACH /CELL_DCH状态，则RNC在DCCH信道上发送PAGING TYPE 2消息。

该寻呼过程与UE连接态的其他RRC过程类似，它不需要在PCH上进行传输。

此外，RNC只会在UE所在的小区内发送该寻呼消息。

具体流程参见图3。

图3 CN发起寻呼类型2
3.1.2.RNC寻呼
3.1.2.1.系统信息更新发起的寻呼类型1
小区的系统信息发生变更时，RNC需要及时通知UE。

对于IDLE/CELL_PCH/URA_PCH 状态UE，RNC发起PAGING TYPE 1消息，同时将PICH的PI Bitmap都置为“1”，以便让所有相关的UE都重新读取系统信息。

这种情况下，UE将忽略PAGING TYPE 1消息中的"Paging record"，它只会读取消息中的“BCCH modification info”信息，并根据此信息在合适的时刻重新读取系统信息。

具体流程参见图4。

图4 系统信息更新发起的寻呼类型1
3.1.2.2.小区更新发起寻呼类型1
如果有下行数据需要传送给CELL_PCH/URA_PCH状态UE，此时RNC会发起PAGING TYPE 1消息。

UE收到寻呼消息后，将进行小区更新跃迁到CELL_FACH状态。

具体流程参见图5。

图5 小区更新发起的寻呼类型1
3.1.2.3.释放CELL_PCH/URA_PCH用户发起的寻呼类型1
利用寻呼消息释放CELL_PCH /URA_PCH状态用户的功能是R5以后RNC新增的一个功能。

该功能的出现使得RNC释放CELL_PCH /URA_PCH状态UE的流程大大简化。

在之前的版本中，如果RNC想释放CELL_PCH/URA_PCH状态UE，则必须先进行小区更新过程将UE跃迁到CELL_FACH状态，然后才可以进行RRC连接释放。

R5新增寻呼功能以后，如果RNC想释放CELL_PCH/URA_PCH状态UE/UEs，只需发送PAGING TYPE 1消息给对应UE/UEs（如果只释放单个UE，RNC选择“Paging record”下的“UTRAN single UE identity”，并将对应的“RRC connection release information”置为“Release”；如果释放多个UE，RNC选择“Paging record”下的“UTRAN group identity”，并将对应的“RRC connection release information”置为“Release”）。

UE收到该消息后，不再需要跃迁到CELL_FACH状态，而是直接将本侧的无线资源释放掉，然后转入IDLE状态。

具体流程参见图6。

图6 释放CELL_PCH/URA_PCH 状态UE 发寻呼类型1
3.3.
寻呼相关参数介绍
3.2.1. 寻呼信道配置
中文名称
最小值 最大值 默认值 参数描述 TFS 参数索引号
1 150 表示TFS 参数的索引号。

RLC 大小
0 4992 RLC 大小 传输块大小 0 5000 传输块大小
中文名称最小值最大值默认值参数描述
物理信道重复周期（单位：帧）
即PBP 1 64 64 该参数表示物理信道帧分配方案的重复周
期(单位：帧)。

取值范围：(1, 2, 4, 8, 16, 32, 64)。

物理信道重复长度 1 63 2 该参数表示物理信道帧分配的重复长度
3.2.2.寻呼信道功率配置
中文名称最小值最大值默认值参数描述
最大传输功率（单位：0.1dB）-350 150 对于PCH传输信道，如果发射功率设置过
小，会使得小区边缘UE无法正确接收寻呼
信息，影响下行公共信道覆盖，从而最终
中文名称最小值最大值默认值参数描述
PICH功率偏移（单位：dB）-10 5 0 PICH 的功率设置主要综合考虑小区覆盖、
容量和质量要求，与PCCPCH 相比较，PICH
3.2.3.RNC侧重发次数
4.寻呼容量计算（Paging Type 1消息）
4.1.理论计算公式
采用TMSI或P-TMSI进行寻呼：
寻呼数/秒/小区= ((TB Size – 19)/40 *N PCH)/PBP
(TB-Size – 19)/40的结果向下取整。

采用IMSI进行寻呼：
寻呼数/秒/小区= ((TB Size – 19)/72 *N PCH)/PBP
(TB-Size – 19)/72的结果向下取整。

其中，19bits中3bits为ASN.1编码的开销、1bits为IE”Message Type”占用的比特数消息类型、3bits为IE” Paging record list”占用的比特数消息类型、12bits为IE” Paging record list”占用的比特数，40bits为采用TMSI或P-TMSI进行寻呼时IE”BCCH modification info”占用的比特数，72bits为采用IMSI进行寻呼时IE”Paging Record”占用的比特数。

4.2.现网寻呼容量计算
PBP = 64帧，N PCH＝8组，TB size = 240bit*1，
可知，
采用TMSI或P-TMSI进行寻呼时，寻呼数/秒/小区= ((240– 19)/40 *8)/0.64=62.5次采用IMSI进行寻呼时，寻呼数/秒/小区= ((240– 19)/72 *8)/0.64=37.5次
LA可支持的最大用户数
假设话务模型参数为，忙时每用户寻呼次数1.5次（未考虑多次寻呼），
采用TMSI/P-TMSI寻呼时LA下的最大用户数= 62.5×3600/1.5 = 15万
采用IMSI寻呼时LA下的最大用户数= 37.5×3600/1.5 = 9万
5.寻呼问题分析流程
寻呼问题分析可按下图顺序进行：
寻呼成功率低的问题按照寻呼流程可分成两大类，一类是由于UE没有收到寻呼消息导致的寻呼成功率低，另一类是由于UE收到寻呼消息但CN未收到寻呼响应消息导致的寻呼成功率低。

造成第二类问题的主要原因属于接入专题分析的内容，这里不再展开讨论，下面重点介绍第一类问题（UE没有收到寻呼消息）的分析定位思路。

5.1.U E没有收到寻呼消息问题分析
问题现象：
被叫UE未收到寻呼消息
问题分析定位思路：
1)CN没有下发寻呼消息
寻呼消息可以由CN发起，也可以由RNC发起。

而用于对用户进行寻址和通知，并建立相应的信令连接的寻呼是由CN发起的。

也就是说，就被叫业务而言，RNC只有在接收到CN 发起的寻呼消息后，才会组织寻呼消息的下发。

由于CN下发寻呼消息时没有相应的UE ID与之匹配，故分析该类问题时需要了解CN 发送给RNC的Paging消息的内容。

在Paging消息中携带了被叫的IMSI，分析时可以以此为依据，核查被叫侧RNC问题时段收到的Paging消息是否包含被叫UE的IMSI，从而定位是否由于CN没有下发Paging消息导致了问题的发生。

一般情况下，该问题的定位需要与核心网厂家配合解决。

2)寻呼容量不足，RNC未下发寻呼
通过前面的分析可知，在一个DRX cycle length周期内，寻呼消息的条数超过寻呼块所能承载的最大值时就会出现拥塞。

在拥塞的情况下，RNC将丢弃超出部分的寻呼消息，然后等待CN侧重发该寻呼消息。

对于网络的寻呼能力，需要在规划阶段进行充分考虑，以避免寻呼拥塞的发生。

如果在网络运行阶段发生寻呼拥塞，则需要进行寻呼信道扩容或者是LA/RA区的重新划分。

a)增加寻呼信道容量；
网络中发生个别小区寻呼拥塞时，可以考虑针对拥塞小区进行寻呼信道扩容。

b)合理规划LA/RA区域范围，减少由于范围不合理引起的寻呼信道过载的现象。

由于网络针对空闲状态用户下发的寻呼消息是在整个LA/RA发送的，因此如果LA/RA 区域设置过大，将会导致寻呼信道拥塞。

网络中发生LA/RA下多个小区寻呼拥塞时，需要考虑结合各小区话务情况进行LA/RA调整，降低寻呼拥塞的概率。

3)由于功率设置不合适，导致UE没有收到寻呼消息
和寻呼相关的有PICH和SCCPCH（承载PCH）两个信道，当这两个信道的功率配置偏低时，将不能满足UE对信号解调的要求，最终导致UE不能正确的接收寻呼消息。

a)PICH信道的发射功率
该参数设置过小，会使得小区边缘UE无法正确接收寻呼指示信息，导致呼叫时延增加，同时可能导致误读SCCPCH（承载PCH）信道，浪费UE电池，并影响下行公共信道覆盖，从而最终影响小区覆盖。

b)SCCPCH（承载PCH）信道的发射功率
该参数设置过小，会使得小区边缘UE无法正确接收寻呼信息，增加寻呼的时延，甚至导致寻呼成功率低。

此时需要核查PICH和SCCPCH信道的功率配置是否合理。

4)UE频繁进行小区重选或位置区更新没有收到寻呼消息
UE在小区重选过程需要读取系统信息，从而无法监听发送给该UE的寻呼消息。

对于UE的寻呼会在用户所在的LA/RA区内发送，如果这时UE在新的LA/RA区尚未完成位置区/路由区更新，则这条寻呼消息将发送到原来的LA/RA区，而无法发送到新的LA/RA 区，导致UE无法收到寻呼消息导致寻呼失败。

如果UE在某一区域小区重选频繁的话，可以通过调整相关参数（常用的方法包括提高测量门限、提高小区重选偏移值或者减小UE最小接收电平等手段）来降低小区重选的频率。

对于由于频繁LA/RA区更新导致的寻呼失败，需要对LA/RA区边界进行优化。

尽量避免LA/RA 区边界划分在高话务小区边缘，适当地增大周期性位置区更新定时T3212的取值，从而减少由于LA/RA区造成的寻呼损失。

另外还可以通过增加寻呼的重发次数来提高寻呼成功率：增加RNC重发寻呼消息次数和增加CN重发寻呼消息次数。

实践证明，合理的设置重发次数可以有效的提高寻呼成功率。

但需要注意的是：增加重发次数会带来一些负面影响。

重发次数的增加，也就意味着寻呼量的增加，这就使得寻呼信道负荷增加，在寻呼容量几近极限的情况下易导致寻呼信道拥塞，从而起了寻呼成功率降低的反向作用。

在这种情况下需要综合考虑寻呼能力和多次寻呼，才能达到最佳的优化效果。

5)覆盖或干扰问题导致的寻呼消息接收失败
对于覆盖或干扰问题导致的寻呼成功率低，需要解决覆盖及干扰的问题。

覆盖问题和干扰问题的解决可参考相关的优化专题，这里不再赘述。

5.2.问题分析定位思路小结
对于寻呼问题大致可以通过以下几个步骤进行分析定位：
1)首先需要对寻呼过程有整体的认识。

从大的过程来说，大致可以将寻呼过程分为两
个过程：一个是从主叫用户起呼到CN发起寻呼的过程；另一个是从CN发起向被叫
用户的寻呼到被叫接收到寻呼消息的过程。

2)结合上述的两大过程，可以将寻呼问题的分析分成两个环节。

在第一个环节，主要
分析的内容是主叫侧是否为寻呼被叫做好了准备，即主叫的接入过程是否成功。

由
此可见，这一环节主要集中在接入问题上，属于接入专题。

如果第一个环节没有问
题，则需要进入第二环节的分析过程；
3)第二环节的问题分析较第一环节要复杂一些。

第二个环节将涉及较多的网元以及网
元间接口的问题分析。

首先就是CN，需要分析是否向被叫用户所属RNC下发了
Paging消息；其次是RNC，需要分析在收到Paging消息后是否向UE下发了Paging
消息；最后就是UE，需要判断是否收到了RNC下发的Paging消息。

针对上述三种
问题，大致定位方法如下：
a)对于CN是否下发的Paging消息的分析环节，由于没有UE ID可查，故需要对
Paging消息的本身特性有所了解，譬如Paging消息IE内容携带了被叫的
IMSI，故可以以此为依据，查询被叫侧RNC问题时段收到的Paging消息内容，
查询是否有属于被叫IMSI的Paging消息；从而定位是否由于CN没有下发
Paging消息导致了问题的发生；
b)对于RNC在收到Paging消息后是否向UE侧下发了Paging消息的分析环节，
该类情况通常是由于RNC内部BUG或硬件原因导致，故问题发生率应该较为频
繁，复现相对较为容易，后续可以依靠网络侧的信令跟踪进行分析；
c)对于UE是否收到了RNC下发的Paging消息分析环节，需要结合覆盖、干扰、
寻呼功率、Paging消息重发次数等传统分析方法进行分析，定位UE没有收到
Paging消息的具体原因。

4)通过上述一系列分析方法，大致已可以定位导致问题发生的原因，并提出相应的优
化方案和措施；
5)在优化方案实施后，还需要通过复测验证调整效果。

6.案例分析
6.1.案例1：呼叫未接通问题分析
现象描述
某日测试车辆沿图示方向行驶（测试车辆沿平塘路由南向北行驶至金钟后，右转沿金钟路由西向东继续行进）。

当时，UE1占用北翟2小区（RNCID：396，CellID：18）启呼，RSCP 在-97dBm左右，在接续过程中，UE1完成RB建立后，在12：59：41收到网络侧下发的Progress 消息，随后在12：59：51收到了网络侧下发的Release消息，由于整个接续过程没有完成，UE1发生了未接通1次。

观察当时被叫UE2的测试情况，根据时间节点来看，在UE1收到网络侧下发的Progress消息和Release消息这段时间期间，UE2始终保持空闲模式（UE2驻留在RNC390下的北新泾3小区上），并监听系统消息，而并没有收到网络侧下发的任何Paging 消息。

图7 Outum测试情况示意图
分析推理过程
1)表象分析过程
首先，回顾一下MOC在RB配置完成后直到接续完成的信令流程，如下图：
图8 MOC在RAB建立完成后的信令流程示意图
显然，UE1在完成了RB建立过程后，应该等待被叫UE2端完成RRC信令连接、RB建立后，向网络侧回Alerting消息，并通过CN侧转发该消息给UE1，而本次呼叫过程中，UE1并没有收到Alerting消息，而是收到了网络侧下发的Release消息后释放链路的，根据Release消息的原因来看，其IE携带的释放原因为：“No user responding”，即对端没有响应。

具体Release消息内容如图9所示：
图9 UE1收到的Rel ease消息内容示意图
而正常情况下，主叫UE1建完RB后到UE1收到对端Alerting消息前，被叫端应该进行一些什么操作呢？在这里也顺便回顾一下MTC的信令流程：
图10 MTC的信令流程示意图
从上述过程可以看到，被叫UE2应该先监听来自网络侧的Paging消息（寻呼消息），随后发起RRC Connection Request消息，向网络侧申请RRC信令连接，并进行后续的过程，在RB建立完成后，UE2向网路侧发送Alerting消息。

而本案例中，Outum测试软件显示，UE2没有收到网络侧理应在Uu口发送的Paging Type 1消息，故UE2根本没有向网络侧发起RRC Connection Request消息。

为何在Uu口没有看到UE2收到Paging消息呢？是由于网络侧没有下发Paging消息？还是由于无线环境等原因，导致UE2没有收到网络侧下发的Paging消息呢？
由于Outum软件所能看到的信令情况局限于Uu口，因此需要配合网络侧信令进行进一步的问题定位工作。

2)深入分析过程
针对上述初步分析，可以通过两个方面来分析判断的为何UE2没有收到Paging消息，其一，就是究竟网络有没有下发Paging消息；其二，则是网络侧下发了Paging消息，而UE2为何没有收到该消息。

a)针对网络侧是否下发Paging消息的分析过程
要分析网络侧是否下发Paging消息，需要考虑以下两点：
第一点，RNC侧在收到主叫UE1上发的Radio Bearer Setup Complete消息后，才会向CN侧发送RAB Assignment Response消息，并由CN侧发起向被叫端UE2的寻呼。

换句话说，如果RNC没有收到UE1上发的Radio Bearer Setup Complete消息的话，也就不会触发后续的寻呼过程。

因此，首先需要确认的一点就是RNC是否收到先前在Uu口看到的由主叫UE1上发的Radio Bearer Setup Complete消息？
第二点，如果RNC侧收到了主叫UE1上发的Radio Bearer Setup Complete消息，那么CN侧是否按照正常的流程触发了后续的寻呼过程，即是否向被叫UE2所属的RNC侧下发了Paging消息？
i.针对第一点的分析
核查UE1的网络侧信令跟踪，可以看出RNC应该收到了主叫UE1上发的Radio Bearer Setup Complete消息，并立即向CN发送了RAB Setup Success消息。

参照时间节点来看，RNC是在13：00：36向CN侧上发RAB Setup Success消息的，在大约10s后收到CN侧主动发起的Iu Release Command消息，该消息IE携带的原因值为：“正常释放”。

图11 UE1启呼后对应的CDL记录情况示意图
由上述情况，基本可以确定两点，第一，可以确定RNC收到了主叫UE1发出的RB Setup。