寻呼成功率

Um口优化
• 寻呼方式的调整: 可以考虑采 用TMSI寻呼方式，提高单个 paging block的寻呼容量，从 而减轻Um口发送的寻呼总量 • BCCH类型的检查，如果为COMB 则可调整为NCOMB增加CCCH信道 • 可以考虑调整AGBLK和MFRMS参 数，增加寻呼容量
寻呼成功率分析优化
寻呼成功率对网络的影响
• 对客户满意度的影响 用户对网络可接入性直观感觉，寻呼成功率低影响到客户对网络服务 的满意度，也影响客户实际通信的使用 • 对重要指标的影响 无线系统接通率是网络考核的一个重要指标 无线系统接通率＝主叫比例*随机接入成功率*业务信道分配成功率(不 含切换)+(1-主叫比例)*寻呼成功率*业务信道分配成功率(不含切换) 当前很多地区的无线系统接通率指标低都是由于寻呼成功率指标低导 致的。从指标方面考虑，寻呼成功率的优化已变得非常迫切
• 小区参数
BCCHTYPE: 设置BCCH的类型 AGBLK: 设置预留AGCH的数量,分配AGCH 和PCH在CCCH上占用的比例 MFRAMS: 寻呼复帧数，指以多少复帧数 作为寻呼子信道的一个循环；它确定了 一个小区中的寻呼信道分配成多少寻呼 子信道；MFRMS越大寻呼信道的承载能力 就越强，但是寻呼消息在空间段的时间 延时增大 T3212: 周期性位置更新的时间 CRH: 夸LAC的小区重选迟滞
A口问题
• •
寻呼未正常下发
MSC有两个object types来统计寻呼方 面（PAGING, LOCREAST) 每个LAC寻呼量＝第一次局部寻呼＋第 二次局部寻呼＋第一次全局寻呼＋第 二次全局寻呼＝LOCAREAST: （NLAPAG1LOTOT＋NLAPAG2LOTOT）＋ PAGING:（NPAG1GLTOT＋NPAG2GLTOT） BSC有object type（BSC），其中的 TOTPAG来计算BSC收到的寻呼总量 如果MSC和BSC两端的寻呼消息总量相 差比较大，则可能是A口出现问题导致 通过LOCREAST分析出各个LAC的寻呼总 量情况，以及各个LAC的寻呼成功率情 况 需要检查A口的拥塞情况
•
•
• •
•
Um接口CCCH信道拥塞导致寻呼消息 未能正常下发
A口和Abis口优化
• 如果通过比较，BSC端的寻呼消 息总数与MSC端的寻呼消息总数 相差比较多，则表示A口可能存 在拥塞问题 • 协调系统工程师对A口开展相关 优化措施(如扩容等)
优化措施
• 如果统计分析发现某些小区的 LAPD中的COVELOAD数量多，则 存在LAPD的信令溢出 • 可以调整LAPD的信令压缩方式 并协调相关工程师进行处理
• • •
•
Abis口问题
寻呼未正常下发
• BSC有object type (LAPD)，其 中的统计值COVERLOAD用于统计 LAPD的溢出 • 如果LAPD出现溢出，则也有可 能导致正常的寻呼消息不能下 发；如果刚好需要寻呼的MS就 在这个BTS的覆盖里，这就导致 寻呼失败 • 可以考虑调整LAPD信令压缩方 式
•
•
• • • • •
寻呼容量计算
• • • • • • • • • • • • • • • 寻呼是在 BCCH(Broadcast Contro Channel ) 的 0 时隙上进 行的，其中的 PCH 用来向移动台传送寻呼请求信息。 BCCH 的 0 时隙在逻辑上被分为复帧结构，每个复帧的发 送时间为 235.4ms。下面，我们计算当 BCCH 采用不同的 配置时，一秒钟最多可以发送的寻呼块的数量。 使用组合BCCH/SDCCH的小区： (AGBLK=0)：3/0.2354=12.75 paging blocks/second (AGBLK=1)：2/0.2354=8.50 paging blocks/second 非组合BCCH/SDCCH的小区： (AGBLK=0)：9/0.2354=38.35 paging block/second (AGBLK=1)：8/0.2354=33.98 paging block/second 所以根据不同的PAGING方式，BTS的每秒PAGING REQUEST理论最大处理能力是： 2 IMSI PAGING REQREST； 使用组合BCCH/SDCCH： (AGBLK=0): (3 / 0.2354)*2 = 25.5 paging request / second (AGBLK=1): (2 / 0.2354 )*2= 17 paging request / second 非组合BCCH/SDCCH： (AGBLK=0): (9 / 0.2354 )*2= 76.5 paging request / second (AGBLK=1): (8 / 0.2354) *2= 67.96 paging request / second • • • • • • • • • • • • • • 4 TMSI PAGING REQREST； 使用组合BCCH/SDCCH： (AGBLK=0): (3 / 0.2354)*4 = 51 paging request / second (AGBLK=1): (2 / 0.2354 )*4= 34 paging request / second 非组合BCCH/SDCCH： (AGBLK=0): (9 / 0.2354 )*4= 153 paging request / second (AGBLK=1): (8 / 0.2354) *4= 135.92 paging request / second 1 IMSI + 2 TMSI PAGING REQREST； 使用组合BCCH/SDCCH： (AGBLK=0): (3 / 0.2354)*3 = 38.25 paging request / second (AGBLK=1): (2 / 0.2354 )*3= 25.5paging request / second 非组合BCCH/SDCCH： (AGBLK=0): (9 / 0.2354 )*3= 114.75 paging request / second (AGBLK=1): (8 / 0.2354) *3= 101.94paging request / second
Biblioteka Baidu


寻呼组介绍
• • 参数AGBLK与MFRMS可以在小区内定义寻呼组的数量。 – AGBLK 参数AGBLK定义每复帧有多少寻呼块做为AGCH(立即指派)。爱立信的BTS支持GBLK=0(不保留AGBLK) 和AGBLK=1(保留一个AGBLK)。注意，当使用了小区广播时AGBLK只能设为 0。 – MFRMS MFRMS定义同一寻呼组的寻呼间隔，以一个复帧周期为单位。比如，MFRMS=9表示移动台属于一 个特定的寻呼组每9个复帧周期重复一次。那么这个寻呼组的寻呼周期大致为 2.1 秒 (9*235.4ms)。 MFRMS值越高，小区中寻呼组的数量越多。 我们可以对每个小区设定寻呼组的数量： – 寻呼组数量多意味着移动台在自己的正确的寻呼快到来之前必须要等更长的时间， 这增加了寻呼时间。 – 寻呼组数量少可以缩短呼叫建立的时间，因为移动台可以更频繁的听自己的寻呼， 但不利的是会增加移动台的功耗。 MFRMS、AGBLK 和寻呼组数量的关系是： 组合 BCCH/SDCCH 小区： 寻呼组数量=(3-AGBLK)*MRFMS 非组合 BCCH/SDCCH 小区： 寻呼组数量=(9-AGBLK)*MFRMS
寻呼无响应的原因分析
• 寻呼消息已正常下发，MS没有响应寻呼或者MSC没有收到MS的寻呼响 应 • 寻呼消息未能正常发出
覆盖不好
寻呼正常下发
• MS处于无覆盖区域，或者MS位 于覆盖差的区域 • MS不能正常接收到BTS下发的寻 呼消息
信道资源不足
寻呼正常下发
• BTS已经接收到MS响应寻呼的随 机接入信息，但是由于SDCCH信 道资源不足，使得无法正常给 MS分配SDCCH信道 • 网络发immediate assignment eject消息给MS
寻呼策略
• 对区域发送寻呼的方式
寻呼一般为发2次 第一次寻呼的方式: 第一次寻 呼一般设置为LAC寻呼 第二次寻呼的方式: LAC寻呼 或者GLOBAL寻呼
• 对手机的寻呼方式
IMSI寻呼 TMSI寻呼 寻呼容量不同，一个paging block可以携带2个IMSI或者4个 TMSI 采用IMSI寻呼，相同的寻呼量 就需要发送更多的paging block
寻呼成功率公式
• 寻呼成功率= （PAGING：NPAG1RESUCC + PAGING：NPAG2RESUCC）/ PAGING：NPAG1LOTOT+PAGING：NPAG1GLTOT)*100% • MSC收到的寻呼响应次数除于MSC发送的寻呼总次数 • NPAG1RESUCC: 对第一次寻呼的响应次数 • NPAG2RESUCC: 对第二次寻呼的响应次数 • NPAG1LOTOT: 第一次LAC寻呼的次数 • NPAG1GLTOT: 第一次全局寻呼的次数
Um口问题
•
寻呼未正常下发
Um接口的寻呼容量与小区相关参数 (BCCHTYPE, AGBLK, MFRMS)设置以 及寻呼方式(TMSI,IMSI)有关 小区级object types（CCCHLOAD, CELLPAG)中的统计记录Um口控制信 道的使用情况
DISCIMMASS 由于在BTS中排队过长而导致CS和PS 的immediate assignment和immediate assignment eject消息被丢失的次数 PAGPCHCONG 由于在BTS中排队队列已满而丢失的寻 呼信息次数 PAGETOOOLD 由于在BTS中排队时间过长而丢失的 寻呼信息次数
寻呼组计算
• • • • • • 某小区参数 BCCHTYPE=NCOMB，AGBLK=1，MFRMS=2, IMSI为460004509069055的用户应该聆听哪个寻呼组的信息 N=MFRMS*（9-AGBLK） N为寻呼组的个数 属于该用户的寻呼组为 （IMSI MOD 1000） MOD N 因此N=2*（9-1）=16 属于该用户的寻呼组为 （460004509069055 MOD 1000）MOD 16=7
寻呼信令流程
• MSC初始需要下发的寻呼消息， 并通过A接口下发到目标 BSC(LAC) • BSC收到MSC发来的寻呼消息， 通过Abis接口发到BSC内的所有 BTS • BTS(小区)则空口上的CCCH信道 (PCH)上发出 • MS收到寻呼消息，通过RACH发 起Channel request，BSS准备 信道资源，在AGCH上发 immediate assignment • MS则在分配的SDCCH上发寻呼响 应消息，通过BSS送到MSC，完 成寻呼响应
其他原因
寻呼正常下发
• GPRS用户手机，如果下发寻呼 消息时正在下载数据(packet transfer mode)，由于此时MS 未监听PCH，所以不能响应寻呼 • 如果有Gs接口，CS的寻呼消息 就可以通过PACCH来发送 • 如果MS正在做location update， 则MS也不能响应寻呼

影响寻呼的相关参数
• MSC参数
TMSIPAR: 定义是否分配TMSI号，当前主 要设置为0(不分配）和1（分配） PAGREP1LA: 在一个位置区重复寻呼的方 式(0:不重复寻呼，1:使用TMSI或者IMSI 在LAC重复，2: 使用IMSI在LAC重复，3: 使用IMSI在GLOBAL重复 PAGTIMEFRST1LA: 第一次LAC寻呼的监控 时间 PAGTIMEFRSTGLOB: 第一次GLOBAL寻呼的 监控时间 PAGTIMEREP1LA: 在LAC重复寻呼的监控时 间 PAGTIMEREPGLOB: 重复GLOBAL寻呼的监控 时间 BTDM: 设置手机隐含关机的时间 GTDM：手机隐含关机的保护时间