《[信息与通信]W高级-寻呼过程分析培训课件-20051108-A-11.ppt》由会员分享，可在线阅读，更多相关《[信息与通信]W高级-寻呼过程分析培训课件-20051108-A-11.ppt（57页珍藏版）》请在三一文库上搜索。
1、,WCDMA 寻呼过程分析,前言,寻呼是接入过程中一个主要的行为，也是优化接入过程性能的一个主要方面。 本文档概要介绍了寻呼的基本过程，在此基础上对寻呼相关的关键参数、信令、性能等内容进行了分析 ，帮助使用者熟悉WCDMA的寻呼过程。,课程目标,寻呼的主要过程 寻呼过程的消息 寻呼性能分析,学习完本课程，您将能够熟悉：,课程内容,T,第一章 寻呼的主要过程 第二章 寻呼过程的消息 第三章 寻呼过程的性能,第一章 寻呼的主要过程,第一节 寻呼的类型 第二节 寻呼流程 第三节 DRX过程,寻呼的类型,Paging Type 1： 应用于UE处于idle、CELL_PCH、URA_PCH状态时。 P
2、aging Type 2: 应用于UE处于CELL_FACH或者CELL_DCH状态时。,寻呼的类型,CN发起的寻呼： CN发起寻呼的目的是使CN能够请求UTRAN联系UE。寻呼过程在IU接口使用无连接的信令过程。CN通过发送寻呼消息触发寻呼过程，UTRAN则将CN寻呼消息通过UU接口上的寻呼过程发送给UE，使得被寻呼的UE发起与CN的信令连接建立过程 。 UTRAN发起的寻呼： 当系统消息发生改变时，UTRAN为了通知处在空闲模式、CELL_PCH和URA_PCH状态下的UE进行系统消息更新，会触发寻呼过程。 为了触发处于CELL_PCH，URA_PCH状态下的UE进行状态迁移，UTRAN会
3、进行一次寻呼流程，作为对该寻呼的一种应答形式，UE会相应的发起一次小区更新或URA更新过程。,第一章 寻呼的主要过程,第一节 寻呼的类型 第二节 寻呼流程 第三节 DRX过程,寻呼流程,寻呼类型1 CN发起的寻呼： 如果IU接口的PAGING消息中带有LAI或者RAI，RNC会向指定位置区或路由区的所有小区下发PAGING TYPE1消息；如果没有LAI或者RAI，RNC会向本RNC的所有小区下发PAGING TYPE1消息。 如下图所示，CN在一个位置区LA中发起寻呼，LA分布在两个RNC中。RNC收到寻呼消息后，根据LAI查找与其对应的所有小区，然后计算出寻呼时刻，寻呼时刻到来时在PCCH
4、上向这些小区发送寻呼类型1消息 。 UTRAN发起的寻呼： 当UE处于CELL_PCH或URA_PCH状态时，如果UTRAN需要和UE进行信息交互，包括信令和数据，需要在PCCH上发送寻呼类型1来通知UE从CELL_PCH或URA_PCH迁移到CELL_FACH，UE通过小区更新的过程来完成状态迁移。,寻呼流程,寻呼类型1,寻呼流程,寻呼类型2 如果UE处于CELL_DCH或者CELL_FACH状态，UTRAN会在DCCH上向被寻呼的UE发送寻呼类型2消息。,寻呼流程,UE收到寻呼后的行为 UTRAN在同一寻呼时刻可以对多个UE进行寻呼，每个被呼UE的信息包含在PAGING TYPE 1中的“
5、paging record”。 若包含信息元素“BCCH modification info”，任何在空闲模式、CELL_PCH 或 URA_PCH 状态的UE应重新读取系统消息，不去理会“Paging record”的内容。其他： 如果UE在空闲模式，UE将： 1、若信息元素“ Used paging identity paging originator“为一个CN标识，则比较其中包含的CN IE“UE标识类型”和所有其分配的CN UE标识；若找到一个相匹配，则指示寻呼接收； 2、否则，UE将忽略该寻呼记录。 如果UE在连接模式，UE将： 1、若信息元素“ Used paging ident
6、ity“为UTRAN，并且这个U-RNTI和已分配给UE的U-RNTI相同： 如果包括可选信息元素“CN originated page to connected mode UE”，则UE指示寻呼接受； 如果不包括可选信息元素“CN originated page to connected mode UE”，UE执行以“paging response”为原因的小区更新过程； 2、若信息元素“ Used paging identity”不为UTRAN，UE忽略该寻呼记录。,第一章 寻呼的主要过程,第一节 寻呼的类型 第二节 寻呼流程 第三节 DRX过程,DRX过程,PICH 寻呼指示信道（PIC
7、H）是固定速率的物理信道（扩频因子为256），用于携带寻呼指示（PI）。PICH总是和PCH所映射的SCCPCH相关联。 下图给出了PICH的帧结构。一个长度为10ms的PICH由300bit组成，其中288bit(b0,b1,b288)用于携带寻呼指示，剩余12个bit留作后用。,DRX过程,每个PICH帧携带NP个寻呼指示，NP定义了PICH信道上每帧支持的最多寻呼指示数， UE在小区系统消息中获取NP的值。NP的取值为18，36，72，144，相当于将288个 bit分为NP个等份，每等份有288/NP个bits，每等份就是一个寻呼指示（PI）。,Mapping of paging in
8、dicators Pq to PICH bits,DRX过程,PICH和SCCPCH的关联 寻呼指示信道（PICH），用于携带寻呼指示（PI）。PCH承载于SCCPCH信道，其携带被寻呼的UE 的具体信息。PICH总是和PCH所映射的SCCPCH相关联。PICH无线帧的尾部比随路的SCCPCH提前7680chips。 PICH和SCCPCH的定时关系如下图所示：,DRX过程,UE采用非连续的方式侦听PICH，监视寻呼指示PI，如下图所示UE要监视每个寻呼周期中红点所指示的帧（paging occasions），然后解码该帧第q个PI，q的计算如下。,DRX过程,DRX循环长度和寻呼时刻 UE在
9、空闲模式下按一定的周期去解码PICH，只有存在寻呼指示时，才会去解码随路的SCCPCH信息，即不连续接收方式（DRX）。 空闲模式下DRX寻呼周期的计算公式： DRX cycle length (2K) *PBP frames 其中：K为IE“CN domain specific DRX cycle length coefficient”，目前CS和PS的K值都是6；PBP为寻呼块周期（主要用于TDD模式），FDD模式下，PBP = 1。 UE寻呼时刻的计算公式： Paging Occasion（CELL SFN） = (IMSI div M) mod (DRX cycle length di
10、v PBP) * PBP + n * DRX cycle length + Frame Offset 这里n = 0,1,2，只要计算出的Paging Occasion小于SFN的最大值4096，在FDD情况下Frame Offset = 0，M是承载PCH的SCCPCH的个数，通常为1。 上述公式可以简化为： SFN = IMSI mod (2K) + n*(2K),DRX过程,UE通过计算出自己的寻呼指示下标P（ PICH每帧的第q等份bits）：,其中PI = DRX index mod NP = (IMSI div 8192) mod NP，SFN就是UE的寻呼时刻，为PICH开始出现
11、时PCCPCH的SFN。 根据以上公式，UE可知道自己PI的下标，这样UE可以仅监视PICH中的与自己关联的bits，一旦发现它们被置为“1”时，UE就知道自己被寻呼了。,DRX过程,寻呼信道选择 系统信息块类型5（SIB5）规定了空闲模式使用的寻呼信道。在一个小区内，可建立一个或几个PCH，在系统信息中指出的每个SCCPCH可承载一个PCH，因此，对于每个规定的PCH都指出一个唯一对应的PICH。 如果在SIB5中规定了不只一个PCH和相关的PICH，UE将根据如下规则进行选择： UE将基于IMSI从SIB5列出的SCCPCH中选择一个如下： Index of selected SCCPCH
12、 = IMSI mod K 这里，K等于列出承载一个PCH的SCCPCH的个数，只承载一个FACH的SCCPCH将不计数。一般情况下，K值取1。 目前一般实现的是一个小区配置一个PICH和一个SCCPCH，SCCPCH上承载两个FACH和一个PCH。,DRX过程,DRX应用举例 小区建立后，广播的系统信息中，有关寻呼的参数设置为： IE“CN domain specific DRX cycle length coefficient”：6 IE“Number of PI per frame”：36 UE接收到这些信息后，计算出自己的寻呼时间、PI以及p值。 现有一个用户，其IMSI 为“4488
13、35805669362”，则该UE的计算结果如下： DRX cycle length = 64 （2的6次方） Cell SFN “448835805669362” mod 64+ n*64 = 50 + 64*n (n = 0,1,2,.)（假设此处 n 取值为3） PI = (448835805669362 div 8192) mod 36 = 14 q = (14 + (18*(242 + 242/8 + 242/64 + 242/512) mod 144) *0.25) mod 36 = 27 从上面的计算可知，该小区PICH每帧携带36个寻呼指示，每个寻呼指示有288/36 = 8个
14、bit组成，UE需要监视每个PICH无线帧的bit216（278）bit223，如果这些8个bit变成了“1“，UE知道自己可能被寻呼了，要在SCCPCH上接收寻呼消息。,课程内容,T,第一章 寻呼的主要过程 第二章 寻呼过程的消息 第三章 寻呼过程的性能,第二章 寻呼过程的消息,第一节 L3信令分析 第二节 L2信令分析,L3信令分析,与寻呼相关的信令主要包括： Iu ：Paging Iub：“COMMON TRANSPORT CHANNEL SETUP REQUEST ”（配置PCH、PICH参数） Uu：寻呼类型1、寻呼类型2、系统消息1、系统消息5。,IU口寻呼,Paging CN如果
15、需要和UE建立信令连接，就会在IU口发起寻呼过程。CN下发的PAGING消息包含以下信元： CN Domain Indicator：必选信元，表示寻呼消息来自CS还是PS域。 Permanent NAS UE Identity：必选信元，被寻呼UE的IMSI。 DRX Cycle Length Coefficient：可选信元，DRX循环长度系数K，用于计算UE的DRX周期，如果该信元存在UTRAN就透传给UE。UE可能会收到CS、PS、UTRAN配置的K值，UE取三者的最小值。 Temporary UE Identity：可选信元，CN给UE分配的临时标识（TMSI或PTMSI），如果此信元
16、不存在，UTRAN就使用IMSI进行寻呼。 Paging Area：CS寻呼使用位置区标识LAI（MCC+MNC+LAC），PS的寻呼使用路由区标识RAI（LAI+RAC）。 Paging Cause：发送寻呼消息的原因，详细的寻呼原因可以参考3GPP TS25.413 9.2.3.3协议（主要是terminating call/signalling等）。 Non Searching Indicator：可选信元，CN指示RNC是否进行协作寻呼。如果该信元不存在或者信元的值为“Searching”，并且UTRAN检测到UE处于连接态，UTRAN会在空口发起寻呼类型2，其它情况下发起寻呼类型1。
17、,IU口寻呼,IU口寻呼信令解析,寻呼类型1,寻呼类型1 UTRAN可以通过寻呼分组在一个寻呼类型1消息中对多个UE进行寻呼，寻呼类型1的信令解析如下图所示。 寻呼类型1包含以下信元： Paging record list：协议规定每个寻呼时刻最多可以寻呼8个UE，对应8个UE寻呼记录，每个寻呼记录中包含寻呼的来源。如果是CN发起的寻呼，要给出CN的域标识、UE的NAS层标识、寻呼原因等信息；如果是UTRAN发起的寻呼，要给出AS层UE标识URNTI。 BCCH modification info：可选信元，使用value tag标识系统信息的改变。如果该信元存在，UE会忽略Paging re
18、cord list，去读系统消息。,寻呼类型1,寻呼类型1,寻呼类型2,寻呼类型2 对处于CELL_DCH或CELL_FACH状态的UE，UTRAN通过在DCCH上发送PAGING TYPE 2消息启动该过程。 UTRAN可以在进行其他过程时发送PAGING TYPE 2消息，同时那个过程的状态不应受到影响，除非另有说明。 UTRAN应将信息元素“Paging cause”设为从上层接收的寻呼原因。如果没有得到，UTRAN将其设为“Terminating cause unknown”。,公共传输信道建立请求,COMMON TRANSPORT CHANNEL SETUP REQUEST （IUB
19、） RNC通过IUB口信令“公共传输信道建立请求”来通知NODEB PCH传输信道参数和PICH的相关参数。 从下图可以看出，PCH的两种传输块格式（0x240，1x240），功率相对PCPICH大2个dB；PICH的NP值为36，功率比PCPICH小3个dB。,公共传输信道建立请求,公共传输信道建立请求（IUB）,系统消息1,系统消息1 UTRAN通过系统消息1通知UE DRX循环周期系数，如下图所示，CS、PS的DRX循环周期系数都是8。,系统消息5,系统消息5 UE通过读系统消息5得到PCH的传输格式和PICH的NP值。,第二章 寻呼过程的消息,第一节 L3信令分析 第二节 L2信令分析
20、,L2信令分析,L2信令分析,L2信令分析,L2信令分析 从上图可以看出PCCH、MACC、PCH FP、SCCPCH间的映射关系，PCCH在RLC层采用TM模式，由MACC进行寻呼分组的调度。PCH的相关特性在PCH FP帧中得到体现，PCH数据帧包括寻呼指示信息和寻呼消息。为了寻呼一个UE，两个连续PCH数据帧用连续CFN发送，第一帧包含寻呼指示信息，第二帧包括寻呼消息。 对于NODEB来说，除了NP通过公共传输信道建立获得，其它参数都体现在高层下发的PCH FP帧中，PI包含在PI bitmap中，DRX Cycle length是由具有相同的PI指示的PCH FP的时间间隔决定，寻呼时
21、刻可以由PCH FP中的CFN计算得到。 PCH FP帧结构如下图所示。,L2信令分析,PCH FP结构,L2信令分析,其中数据帧中的各单元描述如下： 头部CRC： 循环容余多项式是按一个数据帧的头用多项式（X7+X6+X2+1）来计算的。CRC 的计算应包括头中的所有比特。值范围： 0-127，字段长度： 7个比特。 帧类型： 描述它是一个控制帧还是数据帧。值范围： 0=数据, 1=控制，字段长度： 1个比特。 连接帧号 (CFN)： 指示在上行链路上接收或将要在下行链路上发送的第一个数据是哪一个无线帧。值范围和字段长度取决于CFN 所用的传送信道。值范围(PCH)：0-4095，字段长度(
22、PCH)：12个比特；其它传输信道的CFN范围（0-255）。 传输格式指示：TFI是用于传送一个TTI的传送格式的标识号。值范围：0-31，字段长度：5个比特。,L2信令分析,传输块：传输块为一个要传送的或通过无线接口已接收的数据块。TFI 指示的传输格式描述了传输块长度和传输块集合大小。 净荷CRC：循环容余多项式是按一个数据帧的净荷用多项式（X16+X15+X2+1）来计算的。CRC 的计算应包括数据帧的净荷中的所有比特，字段长度：16个比特。 寻呼指示 (PI)：描述净荷中是否出现PI Bitmap。值范围：0=净荷中无PI -Bitmap , 1=净荷中有PI-bitmap ，字段长
23、度：1个比特。 寻呼指示比特映射 (PI-bitmap)：寻呼指示PI0PIN-1 的bitmap 。第一个字节的Bit 7包含PI0，第一个字节的Bit 6包含PI1,., 第二个字节的Bit 7包含PI8，并一直这样下去。值范围： 18, 36, 72 或144 寻呼指示。字段长度：3, 5, 9 或 18 字节 。如果PI-bitmap为1，标识监听该寻呼指示位的手机被寻呼。,课程内容,T,第一章 寻呼的主要过程 第二章 寻呼过程的消息 第三章 寻呼过程的性能,第三章 寻呼过程的性能,第一节 寻呼调度 第二节 寻呼参数分析 第三节 寻呼话统与告警 第四节 寻呼异常情况,寻呼调度,寻呼调度
24、在MACC进行，主要动作： RNC的L3接到CN来的寻呼消息后，判断如果系统没有过载就将寻呼消息发给MACC，如果系统处于过载状态就丢弃寻呼消息。 MACC收到上层发来的寻呼消息后，计算出寻呼时刻，在离当前CFN最近的一个寻呼周期的对应位置将寻呼记录保存下来，对于每个寻呼时刻MACC最多保存8个寻呼记录，如果超过8个就会丢弃。 在每个寻呼时刻到来时，MACC对该寻呼时刻对应的寻呼记录进行编码后下发给NODEB，然后清除寻呼记录，NODEB在小区寻呼信道下发。 如果系统消息更新引起的寻呼，MACC立即编码下发，并清除所有的寻呼记录。,寻呼调度,PCH容量：目前MACC支持的PCH的传输块为240
25、bit，每帧支持的编码后的寻呼消息不能超过240bit。根据寻呼类型1的信元结构和ASN.1 PER编码规则，如果寻呼消息的UE标识时IMSI，每个寻呼时刻最多支持3个UE，如果UE标识是TMSI或者PTMSI最多支持5个UE。 硬件处理能力问题：以目前PCH的编码方式，一个寻呼帧寻呼的UE的个数还不能达到协议值8，如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力，就会造成寻呼丢失，造成呼损的情况。根据寻呼时刻的计算方式，在配置IMSI时要进行详细规划，保证每个UE的寻呼时刻均匀分布在一个寻呼周期内每个帧上。 网络可以采取重发寻呼来提高UE的寻呼成功率。CN在寻呼定时器超时后在IU口重发寻呼
26、消息，UTRAN也可以在MACC调度时重发，表现在不同的寻呼周期内重发 。,第三章 寻呼过程的性能,第一节 寻呼调度 第二节 寻呼参数分析 第三节 寻呼话统与告警 第四节 寻呼异常情况,寻呼参数分析,DRX寻呼周期系数 DRX寻呼周期系数K值决定了DRX周期长度，K值越大，DRX周期就越长，UE功耗会降低，但是UE寻呼周期变长；如果K值过小，寻呼周期变小，UE处理寻呼开销和功耗都会增加。协议值给出范围212，目前我司取值6，寻呼周期为0.64秒。 UE的DRX寻呼周期系数有三个来源：系统消息、CN的寻呼消息、UTRAN的Uu口信令，并且CS、PS的处理方式也不一样。 对于PS域，DRX寻呼周期
27、系数由UE和SGSN通过NAS层消息（attach过程）协商，不管UE处于IDLE或者是连接状态都以协商数据为准，如果协商失败则使用CS域的寻呼系数。 对于CS域，如果UE在IDLE状态下，DRX寻呼周期系数使用系统消息、CN的寻呼消息中的最小值；如果UE在连接状态，DRX寻呼周期系数使用系统消息、CN的寻呼消息、UTRAN的UU口信令中的最小值。,寻呼参数分析,DRX寻呼周期系数（二） RNC有两条MML命令可以修改DRX寻呼周期系数： 1、SET FRC修改UTRAN的DRX寻呼周期系数(“DRXCYCLELENCOEF”)，通过如下信令通知UE： UU_CELL_UPDATE_CONFI
28、RM、 UU_URA_UPDATE_CONFIRM、 UU_PH_CH_RECFG、 UU_TR_CH_RECFG、 UU_RB_SETUP、 UU_RB_REL、 UU_RB_RECFG 2、MOD CNDOMAIN修改CS、PS的DRX寻呼周期系数，修改后会发寻呼类型1通知UE读更新后的系统消息（in Idle Mode）。,寻呼参数分析,NP值 Np是物理信道PICH在一帧中下发的PI寻呼指示数，取值范围在（18，36，72，144），该参数在系统消息5中通过“Number of PI per frame”指示。UE会在确定的寻呼时机接收PICH发送的PI帧，只有相应的PI指示有效，UE
29、才会去解调后续的S-CCPCH帧。 Np参数将所有的UE分成了Np组，每一个组中所有的UE使用同一个PI。 Np的取值对网络的影响：Np的值设置过小，则每组中对应的UE数目较多，对每个UE而言，PI指示出现的概率增大，被唤醒的次数越多；Np值设置过大，则每组中对应的UE数目较少，对每个IMSI而言，PI指示出现的概率也较小，被唤醒的次数也较少；Np越大，对UE的PICH解调性能要求越高。 该参数通过ADD PICH命令设置（“PICHMODE”）。,寻呼参数分析,寻呼重发次数和时间间隔 为了提高寻呼的成功率，CN和RNC都会重发寻呼消息。但是寻呼重发会造成寻呼量的增加，特别是在空中接口公共下行
30、信道拥塞的情况下，大大浪费下行信道资源，造成新的寻呼消息不能及时下发。为了兼顾寻呼成功率和寻呼效率，CN寻呼重发次数和时间间隔要和UTRAN的重发结合起来考虑。 目前我司的实现是RNC重发一次寻呼类型1消息，前后两次的间隔是一个寻呼周期，DRX循环周期系数取值6，也就是间隔640ms。CN最多支持4次寻呼重发，即CN支持寻呼消息的5次发送。CN寻呼重发时间间隔可以设由CN通过软参设置。 设置CN寻呼重发次数和时间间隔的命令为MOD PGCTRL；设置RNC寻呼重发次数的命令为SET WFMRCFGDATA（“MACCPAGEREPEAT”）。,寻呼参数分析,寻呼重发次数和时间间隔（二） 在CN
31、重发1次的情况下，CN寻呼重发的时间间隔可以按以下考虑： 如果UTRAN不重发，CN重发时间间隔应该大于一个DRX周期（640ms），可以取1s。从以上的寻呼调度可以看出，当一个寻呼消息从CN发到UTRAN，UTRAN计算出的寻呼时刻CFN离当前PCH CFN的最大时间间隔是一个DRX周期（640ms），如果在这个时间间隔内CN再发一个寻呼消息过来，上一个寻呼消息还没有发出，这样会造成不必要的信道带宽浪费。 如果UTRAN重发1次，CN重发时间应该大于2个DRX周期。 遵循一个原则，CN应该等到UTRAN完成上一条寻呼消息的发送和重发后再重发下一条寻呼消息。为了保证这个原则，可以同时调整CN的
32、重发次数、重发时间间隔、UTRAN重发次数、DRX寻呼周期等参数使其满足这个关系原则。,第三章 寻呼过程的性能,第一节 寻呼调度 第二节 寻呼参数分析 第三节 寻呼话统与告警 第四节 寻呼异常情况,寻呼话统与告警,寻呼话统 RNC的寻呼话统指标如下表所示。其中“CN_PAGE_IDLE_UE_SUCC_RATE”和“UTRAN_PAGE1_SUCC_RATE”两个主要指标表征了寻呼的性能。在CN侧也可以统计寻呼的成功率、第一次/第二次寻呼的成功率等。,寻呼话统与告警,寻呼话统（二）,寻呼话统与告警,寻呼告警 在网络实际运行过程中，由于流控或者寻呼容量限制会导致寻呼丢失。 如果寻呼丢失数目达到预
33、先设定的门限，输出寻呼丢失告警，给出寻呼丢失的主要原因。,第三章 寻呼过程的性能,第一节 寻呼调度 第二节 寻呼参数分析 第三节 寻呼话统与告警 第四节 寻呼异常情况,寻呼异常情况,UTRAN对寻呼消息不作缓存处理，如果在整个寻呼过程中有异常出现，寻呼消息都会被丢掉。 系统异常 RNC为保证系统运行的稳定性，避免突发的消息风暴对系统的冲击，对包括寻呼在内的某些频率很高的消息进行了流控。 当RNC收到CN的寻呼消息后，判断系统如果处于过载状态，就会丢弃寻呼消息，并记录下寻呼消息丢失的个数。如果寻呼丢失比例达到一定的门限，RNC就会向CN发“Overload”消息，CN会控制消息发送流量按照一定的
34、步长减少。如果在一定的时间内没有收到“Overload”消息，IU接口的消息流量会逐步增长直至恢复正常。 NODEB在过载状态下也不会处理寻呼消息包。 如果系统出现故障，如IUB口传输层故障，小区处于异常状态等都会导致寻呼消息丢弃。 为减少寻呼丢失带来的呼损，网络侧目前采用的措施是寻呼消息重发。,寻呼异常情况,寻呼信道容量限制 由于PCH容量的限制，同一寻呼时刻能够寻呼的UE个数有限，如果UE的个数超过这个限制就会发生寻呼丢失，有以下两种情况： 一种情况是同一寻呼时刻的UE超过8个，已经超过了协议规定值和MACC的处理能力，MACC对每个寻呼时刻申请了能够存储8个寻呼记录的内存区； 另外一种情况是，由于编码后的每帧传输块最大为240bits，即使每个寻呼时刻UE个数小于8，也会发生寻呼丢弃的情况。如果寻呼记录的UE标识是IMSI，每帧寻呼消息只能处理3个UE的寻呼记录，如果寻呼记录的UE标识是TMSI或PTMSI，每帧寻呼消息只能处理5个UE的寻呼记录，超过的UE寻呼记录就会被丢弃。,