WCDMA寻呼过程

WCDMA寻呼过程分析,前言,寻呼是接入过程中一个主要的行为，也是优化接入过程性能的一个主要方面。本文档概要介绍了寻呼的基本过程，在此基础上对寻呼相关的关键参数、信令、性能等内容进行了分析，帮助使用者熟悉WCDMA的寻呼过程。,课程目标,寻呼的主要过程寻呼过程的消息寻呼性能分析,学习完本课程，您将能够熟悉：,课程内容,T,第一章寻呼的主要过程第二章寻呼过程的消息第三章寻呼过程的性能,第一章寻呼的主要过程,第一节寻呼的类型第二节寻呼流程第三节DRX过程,寻呼的类型,寻呼过程是使用寻呼控制信道发送寻呼信息给处于空闲模式、CELL_PCH或者URA_PCH状态的UE的过程。CN可能请求寻呼，比如建立一个信令连接或发起一次业务。UTRAN也可以对处于CELL_PCH或者URA_PCH状态的UE发起寻呼触发小区更新过程；UTRAN还可以对处于空闲模式、CELL_PCH状态或者URA_PCH状态的UE发起寻呼触发UE读取更新的系统消息。,寻呼的类型,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会进行一次寻呼流程，作为对该寻呼的一种应答形式，UE会相应的发起一次小区更新或URA更新过程。,第一章寻呼的主要过程,第一节寻呼的类型第二节寻呼流程第三节DRX过程,寻呼流程,寻呼类型1RNC在PCCH下发PAGINGTYPE1消息，如果IU接口的PAGING消息中带有LAI或者RAI，RNC会向指定位置区或路由区的所有小区下发PAGINGTYPE1消息；如果没有LAI或者RAI，RNC会向本RNC的所有小区下发PAGINGTYPE1消息。如下图所示，CN在一个位置区LA中发起寻呼，LA分布在两个RNC中。RNC收到寻呼消息后，根据LAI查找与其对应的所有小区，然后计算出寻呼时刻，寻呼时刻到来时在PCCH上向这些小区发送寻呼类型1消息。UTRAN也可以在没有CN的参与下直接发起寻呼类型1。当UE处于CELL_PCH或URA_PCH状态时，如果UTRAN需要和UE进行信息交互，包括信令和数据，需要在PCCH上发送寻呼类型1来通知UE从CELL_PCH或URA_PCH迁移到CELL_FACH，UE通过小区更新的过程来完成状态迁移。,寻呼流程,寻呼类型1,寻呼流程,寻呼类型2如果UTRAN判断是协作寻呼，表明UE处于CELL_DCH或者CELL_FACH状态，UTRAN会立即在DCCH上向被寻呼的UE发送寻呼类型2消息。,寻呼流程,UE收到寻呼后的行为UTRAN在同一寻呼时刻可以对多个UE进行寻呼，每个被呼UE的信息包含在PAGINGTYPE1中的“pagingrecord”。如果UE在空闲模式，UE将：1、若信息元素Usedpagingidentitypagingoriginator为一个CN标识，则比较其中包含的CNIE“UE标识类型的标识”和所有其分配的CNUE标识；若找到一个相匹配，则指示寻呼接收；2、否则，UE将忽略该寻呼记录。如果UE在连接模式，UE将：1、若信息元素Usedpagingidentity为UTRAN，并且这个U-RNTI和已分配给UE的U-RNTI相同：如果包括可选信息元素“CNoriginatedpagetoconnectedmodeUE”，则UE指示寻呼接受；如果不包括可选信息元素“CNoriginatedpagetoconnectedmodeUE”，UE执行以“pagingresponse”为原因的小区更新过程；2、若信息元素“Usedpagingidentity”不为UTRAN，UE忽略该寻呼记录。若包含信息元素BCCHmodificationinfo，任何在空闲模式、CELL_PCH或URA_PCH状态的UE应重新读取系统消息，不去理会Pagingrecord的内容。,第一章寻呼的主要过程,第一节寻呼的类型第二节寻呼流程第三节DRX过程,DRX过程,DRX循环长度和寻呼时刻UE在空闲模式下可以使用两种方式监听寻呼，一种是每10ms直接去解码SCCPCH，另一种是按一定的周期去解码PICH，只有存在寻呼指示时，才会去解码随路的SCCPCH信息，即不连续接收方式k。空闲模式下DRX寻呼周期的计算公式：DRXcyclelength(2K)*PBPframes其中：K为IE“CNdomainspecificDRXcyclelengthcoefficient”，目前CS和PS的K值都是6；PBP为寻呼块周期，FDD模式下，PBP=1。UE寻呼时刻的计算公式：PagingOccasion（CELLSFN）=(IMSImodM)mod(DRXcyclelengthdivPBP)*PBP+n*DRXcyclelength+FrameOffset这里n=0,1,2，只要计算出的PagingOccasion小于SFN的最大值4096，在FDD情况下FrameOffset=0，M是承载PCH的SCCPCH的个数，通常为1。上述公式可以简化为：SFN=IMSImod(2K)+n*(2K),DRX过程,UE只需要在这些PICH帧上监视寻呼指示PI，如下图所示UE要监视每个寻呼周期中红点所指示的帧（pagingoccasions），然后解码该帧第q个PI，q的计算如下。,DRX过程,PICH和SCCPCH的关联寻呼指示信道（PICH）是固定速率的物理信道（扩频因子为256），用于携带寻呼指示（PI）。PICH总是和PCH所映射的SCCPCH相关联。下图给出了PICH的帧结构。一个长度为10ms的PICH由300bit组成，其中288bit(b0,b1,b288)用于携带寻呼指示，剩余12个bit留作后用。,每个PICH帧携带NP个寻呼指示，NP定义了PICH信道上每帧支持的最多寻呼指示数，UE在小区系统消息中获取NP的值。NP的取值为18，36，72，144，相当于将288个bit分为NP个等份，每等份有288/NP个bits，每等份就是一个寻呼指示（PI）。,DRX过程,UE通过计算出自己的寻呼指示下标p来确定和PICH每帧的第q等份bits相关联。,其中PI=DRXindexmodNP=(IMSIdiv8192)modNP，SFN就是UE的寻呼时刻，为PICH开始出现时PCCPCH的SFN。根据以上公式，UE可知道自己PI的下标，这样UE可以仅监视PICH中的与自己关联的bits，一旦发现它们被置为“1”时，UE就知道自己被寻呼了。这时它从该PICH无线帧结束后7680chips开始，在SCCPCH上接收寻呼消息并解析。PICH和SCCPCH的定时关系如下图所示，PICH无线帧的尾部比随路的SCCPCH提前7680chips。,DRX过程,寻呼信道选择系统信息块类型5（SIB5）规定了空闲模式使用的寻呼信道。在一个小区内，可建立一个或几个PCH，在系统信息中指出的每个SCCPCH可承载一个PCH，因此，对于每个规定的PCH都指出一个唯一对应的PICH。如果在SIB5中规定了不只一个PCH和相关的PICH，UE将根据如下规则进行选择：UE将基于IMSI从SIB5列出的SCCPCH中选择一个如下：IndexofselectedSCCPCH=(IMSIdiv(“DRXcyclelength”divPBP)*Np*NPICH)modK这里，K等于列出承载一个PCH的SCCPCH的个数，只承载一个FACH的SCCPCH将不计数。一般情况下，K值取1。目前一般实现的是一个小区配置一个PICH和一个SCCPCH，SCCPCH上承载两个FACH和一个PCH。,DRX过程,DRX应用举例小区建立后，广播的系统信息中，有关寻呼的参数设置为：IE“CNdomainspecificDRXcyclelengthcoefficient”：6IE“NumberofPIperframe”：36UE接收到这些信息后，计算出自己的寻呼时间、PI以及p值。现有一个用户，其IMSI为“448835805669362”，则该UE的计算结果如下：DRXcyclelength=64（2的6次方）CellSFN“448835805669362”mod64+n*64=50+64*n(n=0,1,2,.)PI=(448835805669362div8192)mod36=14q=(14+(18*(242+242/8+242/64+242/512)mod144)*0.25)mod36=27从上面的计算可知，该小区PICH每帧携带36个寻呼指示，每个寻呼指示有288/36=8个bit组成，UE需要监视每个PICH无线帧的bit216（278）bit223，如果这些8个bit变成了1，UE知道自己可能被寻呼了，要在SCCPCH上接收寻呼消息。,课程内容,T,第一章寻呼的主要过程第二章寻呼过程的消息第三章寻呼过程的性能,第二章寻呼过程的消息,第一节L3信令分析第二节L2信令分析,L3信令分析,与寻呼相关的信令主要包括寻呼（IU）、寻呼类型1、寻呼类型2，配置PCH、PICH参数的公共传输信道建立请求（IUB）、系统消息1、系统消息5等。,IU口寻呼,IU口寻呼CN如果需要和UE建立信令连接，就会在IU口发起寻呼过程。CN下发的PAGING消息包含以下信元：CNDomainIndicator：必选信元，表示寻呼消息来自CS还是PS域。PermanentNASUEIdentity：必选信元，被寻呼UE的IMSI。DRXCycleLengthCoefficient：可选信元，DRX循环长度系数K，用于计算UE的DRX周期，如果该信元存在UTRAN就透传给UE。UE可能会收到CS、PS、UTRAN配置的K值，UE取三者的最小值。TemporaryUEIdentity：可选信元，CN给UE分配的临时标识（TMSI或PTMSI），如果此信元不存在，UTRAN就使用IMSI进行寻呼。PagingArea：CS寻呼使用位置区标识LAI（MCC+MNC+LAC），PS的寻呼使用路由区标识RAI（LAI+RAC）。PagingCause：发送寻呼消息的原因，详细的寻呼原因可以参考3GPPTS25.413协议。NonSearchingIndicator：可选信元，CN指示RNC是否进行协作寻呼。如果该信元不存在或者信元的值为“Searching”，并且UTRAN检测到UE处于连接态，UTRAN会在空口发起寻呼类型2，其它情况下发起寻呼类型1。,IU口寻呼,IU口寻呼信令解析,寻呼类型1,寻呼类型1UTRAN可以通过寻呼分组在一个寻呼类型1消息中对多个UE进行寻呼，寻呼类型1的信令解析如下图所示。寻呼类型1包含以下信元：Pagingrecordlist：协议规定每个寻呼时刻最多可以寻呼8个UE，对应8个UE寻呼记录，每个寻呼记录中包含寻呼的来源。如果是CN发起的寻呼，要给出CN的域标识、UE的NAS层标识、寻呼原因等信息；如果是UTRAN发起的寻呼，要给出AS层UE标识URNTI。BCCHmodificationinfo：可选信元，使用valuetag标识系统信息的改变。如果该信元存在，UE会忽略Pagingrecordlist，去读系统消息。,寻呼类型1,寻呼类型1,寻呼类型2,寻呼类型2对处于CELL_DCH或CELL_FACH状态的UE，UTRAN通过在DCCH上发送PAGINGTYPE2消息启动该过程。UTRAN可以在进行其他过程时发送PAGINGTYPE2消息，同时那个过程的状态不应受到影响，除非另有说明。UTRAN应将信息元素“Pagingcause”设为从上层接收的寻呼原因。如果没有得到，UTRAN将其设为“Terminatingcauseunknown”。,公共传输信道建立请求,公共传输信道建立请求（IUB）RNC通过IUB口信令“公共传输信道建立请求”来通知NODEBPCH传输信道参数和PICH的相关参数。从下图可以看出，PCH的两种传输块格式（0 x240，1x240），功率相对PCPICH小2个dB；PICH的NP值为36，功率比PCPICH小7个dB。,公共传输信道建立请求,公共传输信道建立请求（IUB）,系统消息1,系统消息1UTRAN通过系统消息1通知UEDRX循环周期系数，如下图所示，CS、PS的DRX循环周期系数都是8。,系统消息5,系统消息5UE通过读系统消息5得到PCH的传输格式和PICH的NP值。,第二章寻呼过程的消息,第一节L3信令分析第二节L2信令分析,L2信令分析,L2信令分析,L2信令分析,L2信令分析从上图可以看出PCCH、MACC、PCHFP、SCCPCH间的映射关系，PCCH在RLC层采用TM模式，由MACC进行寻呼分组的调度。PCH的相关特性在PCHFP帧中得到体现，PCH数据帧包括寻呼指示信息和寻呼消息。为了寻呼一个UE，两个连续PCH数据帧用连续CFN发送，第一帧包含寻呼指示信息，第二帧包括寻呼消息。对于NODEB来说，除了NP通过公共传输信道建立获得，其它参数都体现在高层下发的PCHFP帧中，PI包含在PIbitmap中，DRXCyclelength是由具有相同的PI指示的PCHFP的时间间隔决定，寻呼时刻可以由PCHFP中的CFN计算得到。PCHFP帧结构如下图所示。,L2信令分析,L2信令分析,L2信令分析,其中数据帧中的各单元描述如下：头部CRC：循环容余多项式是按一个数据帧的头用多项式（X7+X6+X2+1）来计算的。CRC的计算应包括头中的所有比特。值范围：0-127，字段长度：7个比特。帧类型：描述它是一个控制帧还是数据帧。值范围：0=数据,1=控制，字段长度：1个比特。连接帧号(CFN)：指示在上行链路上接收或将要在下行链路上发送的第一个数据是哪一个无线帧。值范围和字段长度取决于CFN所用的传送信道。值范围(PCH)：0-4095，字段长度(PCH)：12个比特；其它传输信道的CFN范围（0-255）。传输格式指示：TFI是用于传送一个TTI的传送格式的标识号。值范围：0-31，字段长度：5个比特。,L2信令分析,传输块：传输块为一个要传送的或通过无线接口已接收的数据块。TFI指示的传输格式描述了传输块长度和传输块集合大小。净荷CRC：循环容余多项式是按一个数据帧的净荷用多项式（X16+X15+X2+1）来计算的。CRC的计算应包括数据帧的净荷中的所有比特，字段长度：16个比特。寻呼指示(PI)：描述净荷中是否出现PIBitmap。值范围：0=净荷中无PI-Bitmap,1=净荷中有PI-bitmap，字段长度：1个比特。寻呼指示比特映射(PI-bitmap)：寻呼指示PI0.PIN-1的bitmap。第一个字节的Bit7包含PI0，第一个字节的Bit6包含PI1,.,第二个字节的Bit7包含PI8，并一直这样下去。值范围：18,36,72或144寻呼指示。字段长度：3,5,9或18字节。如果PI-bitmap为1，标识监听该寻呼指示位的手机被寻呼。,课程内容,T,第一章寻呼的主要过程第二章寻呼过程的消息第三章寻呼过程的性能,第三章寻呼过程的性能,第一节寻呼调度第二节寻呼参数分析第三节寻呼话统与告警第四节寻呼异常情况,寻呼调度,寻呼调度在MACC进行。RNC的L3接到CN来的寻呼消息后，判断如果系统没有过载就将寻呼消息发给MACC，如果系统处于过载状态就丢弃寻呼消息。MACC收到上层发来的寻呼消息后，计算出寻呼时刻，在离当前CFN最近的一个寻呼周期的对应位置将寻呼记录保存下来，对于每个寻呼时刻MACC最多保存8个寻呼记录，如果超过8个就会丢弃。在每个寻呼时刻到来时，MACC对该寻呼时刻对应的寻呼记录进行编码后下发给NODEB，然后清除寻呼记录，NODEB在小区寻呼信道下发。如果系统消息更新引起的寻呼，MACC立即编码下发，并清除所有的寻呼记录。,寻呼调度,目前MACC支持的PCH的传输块为240bit，每帧支持的编码后的寻呼消息不能超过240bit。根据寻呼类型1的信元结构和ASN.1PER编码规则，如果寻呼消息的UE标识时IMSI，每个寻呼时刻最多支持3个UE，如果UE标识是TMSI或者PTMSI最多支持5个UE。以目前PCH的编码方式，一个寻呼帧寻呼的UE的个数还不能达到协议值8，如果在同一寻呼时刻寻呼UE的个数超过系统的处理能力，就会造成寻呼丢失，造成呼损的情况。根据寻呼时刻的计算方式，在配置IMSI时要进行详细规划，保证每个UE的寻呼时刻均匀分布在一个寻呼周期内每个帧上。网络可以采取重发寻呼来提高UE的寻呼成功率。CN在寻呼定时器超时后在IU口重发寻呼消息，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寻呼周期系数由UE和SGSN通过NAS层消息（attach过程）协商，不管UE处于IDLE或者是连接状态都以协商数据为准，如果协商失败则使用CS域的寻呼系数。对于CS域，如果UE在IDLE状态下，DRX寻呼周期系数使用系统消息、CN的寻呼消息中的最小值；如果UE在连接状态，DRX寻呼周期系数使用系统消息、CN的寻呼消息、UTRAN的UU口信令中的最小值。,寻呼参数分析,DRX寻呼周期系数RNC有两条MML命令可以修改DRX寻呼周期系数：1、SETFRC修改UTRAN的DRX寻呼周期系数，通过如下信令通知UE：UU_CELL_UPDATE_CONFIRM、UU_URA_UPDATE_CONFIRM、UU_PH_CH_RECFG、UU_TR_CH_RECFG、UU_RB_SETUP、UU_RB_REL、UU_RB_RECFG2、MODCNDOMAIIN修改CS、PS的DRX寻呼周期系数，修改后会发寻呼类型1通知UE读更新后的系统消息。,寻呼参数分析,NP值Np是物理信道PICH在一帧中下发的PI寻呼指示数，取值范围在（18，36，72，144），该参数在系统消息中通过“NumberofPIperframe”指示。UE会在确定的寻呼时机接收PICH发送的PI帧，只有相应的PI指示有效，UE才会去解调后续的S-CCPCH帧。Np参数将所有的UE分成了Np组，每一个组中所有的UE使用同一个PI。Np的取值对网络的影响：Np的值设置过小，则每组中对应的UE数目较多，对每个UE而言，PI指示出现的概率增大，被唤醒的次数越多；Np值设置过大，则每组中对应的UE数目较少，对每个IMSI而言，PI指示出现的概率也较小，被唤醒的次数也较少；Np越大，对UE的PICH解调性能要求越高。该参数通过ADDPICH命令设置。,寻呼参数分析,寻呼重发次数和时间间隔为了提高寻呼的成功率，CN和RNC都会重发寻呼消息。但是寻呼重发会造成寻呼量的增加，特别是在空中接口公共下行信道拥塞的情况下，大大浪费下行信道资源，造成新的寻呼消息不能及时下发。为了兼顾寻呼成功率和寻呼效率，CN寻呼重发次数和时间间隔要和UTRAN的重发结合起来考虑。目前我司的实现是RNC重发两次寻呼类型1消息，前后两次的间隔是一个寻呼周期，DRX循环周期系数取值6，也就是间隔640ms。CN最多支持4次寻呼重发，即CN支持寻呼消息的5次发送。CN寻呼重发时间间隔可以设由CN通过软参设置。设置CN寻呼重发次数和时间间隔的命令为MODPGCTRL；设置RNC寻呼重发次数的命令为SETWFMRCFGDATA。,寻呼参数分析,寻呼重发次数和时间间隔在CN重发1次的情况下，CN寻呼重发的时间间隔可以按以下考虑：如果UTRAN不重发，CN重发时间间隔应该大于一个DRX周期（640ms），可以取1s。从以上的寻呼调度可以看出，当一个寻呼消息从CN发到UTRAN，UTRAN计算出的寻呼时刻CFN离当前PCHCFN的最大时间间隔是一个DRX周期（640ms），如果在这个时间间隔内CN再发一个寻呼消息过来，上一个寻呼消息还没有发出，这样会造成不必要的信道带宽浪费。如果UTRAN重发1次，CN重发时间应该大于2个DRX周期。遵循一个原则，CN应该等到UTRAN完成上一条寻呼消息的发送和重发后再重发下一条寻呼消息。为了保证这个原则，可以同时调整CN的重发次数、重发时间间隔、UTRAN重发次数、DRX寻呼周期等参数使其满足这个关系原则。,第三章寻呼过程的性能,第一节寻呼