QChat业务寻呼参数优化建议.doc

EVDO网络寻呼机制及QChat业务寻呼策略优化建议一、概述QChat业务是基于CDMA2000 1xEVDO RevA的一种PTT业务，是语音IP（VoIP）应用，与目前现网上其他EVDO业务相比，该业务用户移动性较强，如果寻呼策略配置不合理，有可能因为被叫寻呼应答过晚引起业务呼叫失败，从而发生漏呼现象。这种问题可以通过调整寻呼策略来解决。寻呼策略的选择是寻呼成功率、寻呼效率和寻呼时延三者之间的折中。较大的寻呼区域和较小的寻呼间隔会带来控制信道负荷的增加，对数据速率也有一定影响。应根据本地网具体业务信道和控制信道负荷情况调整寻呼策略；寻呼策略调整后要密切关注寻呼成功率、控制信道负荷和寻呼时延等指标的变化，确保网络的稳定运行。下面详细介绍中兴、华为、阿朗无线设备的EVDO寻呼机制。二、中兴无线设备寻呼机制2.1EVDO寻呼机制描述根据终端与网络协商的不同SCI值，可以针对SCI=9和SCI=5设置2套寻呼策略。目前现网普通DO数据卡业务（BE业务）均采用SCI=9。无论是否开启QoS，QChat业务都会把SCI协商为5。SCI=9和SCI=5的寻呼策略主要区别在于AN重发寻呼的次数，AN收到PCF发来的A9-BS Service Request，对QChat终端（SCI=5）发送两次page，对普通DO数据卡(SCI=9)发送一次page。2.1.1 寻呼机制描述中兴设备的寻呼机制包括AN的分层寻呼机制和PCF重发A9-BS Service Request机制两个方面。 AN的分层寻呼机制及参数AN采用分层寻呼机制，每层寻呼包含的载扇范围不同，共有三种不同层次的寻呼范围：第一层寻呼（最近上报的有效激活集扇区寻呼）：该级寻呼是对上次终端与基站发生消息交互时，AT上报的RU消息里包含的有效PN所在的BTS发送寻呼；即上次上报的RU中如果包含N个有效PN，在对该终端做第一级寻呼时，这N个有效PN所属的所有BTS下的所有小区将发送寻呼消息；距上次终端与基站侧联系间隔t，当满足t 邻区方式RU有效时间（默认为1秒）时，在此区间寻呼。第二层寻呼（邻区寻呼）：该级寻呼是对上次终端与基站交互的接入小区的所有邻区所属的BTS寻呼，即上次上报RU的接入小区是Cell1，对Cell1所有邻区所在的BTS的所有小区发送寻呼消息；距上次终端与基站侧联系间隔t，当满足：邻区方式RU有效时间t子网方式RU有效时间（默认10秒），在此区间寻呼。基站首次发送寻呼消息的范围不一定是第一层，这是因为终端在休眠下在子网内移动可能不会上报路由更新消息，因此第一层和第二层的寻呼范围有时效性。从进入休眠开始，超过一定时间后，就不能认为用户还在原来的位置。寻呼层次的选择与2个参数有关，邻区方式RU有效时间RUNLAvailableTime（以下描述用t1表示），子网方式RU有效时间RUSNAvailableTime（以下描述用t2表示），且t1 t2。这两个参数与寻呼层次的关系如下： 1) 当0t = t1时，寻呼的范围是第一级（最近一次激活集内的扇区，下图中红色基站表示寻呼区域）；2) 当 t1 t =t2时，寻呼的范围是第三级（子网+邻区寻呼，下图中红色基站表示寻呼区域）。第一次寻呼与第二次寻呼是分别计算的时间，没有无固定范围，可能组合有：（第一级，第二级），（第二级，第二级），（第二级，第三级），（第三级，第三级）； 调整 “邻区方式RU有效时间RUNLAvailableTime”与“子网方式RU有效时间RUSNAvailableTime”来变动寻呼范围，QChat业务与普通DO业务一致；注：所有的EVDO终端（包括QChat终端）使用相同的分层寻呼参数，修改其中的任一个参数将影响所有的终端。上面这两个参数，“邻区方式RU有效时间RUNLAvailableTime”与“子网方式RU有效时间RUSNAvailableTime”分别为1秒和10秒。这两个参数在寻呼的时候，决定第一层和第二层寻呼范围选择的时效性，具体策略见下面附说明。由于我们认为，寻呼最可靠的范围是全子网寻呼。所以对指定范围（第一层和第二层）寻呼只能在一个有效时间内使用（寻呼到达和上次终端与基站侧联系的时间差），这个时间后台默认配置是1秒和10秒。子网寻呼对系统的负荷代价较大，BSC侧的处理CPU消耗增加，BTS侧空口控制信道用来发送寻呼的消耗增加。而特定区域寻呼可以有效减少系统消耗，但是由于终端移动的位置无法把握，使用特定区域寻呼时，有效时间设定需要准确评估。如果评估不准可能降低寻呼成功率。这两个参数确定特定区域寻呼的有效时间。默认值分别为1秒和10秒。即我们认为，终端上次报告了准确位置后，1秒内不会离开上次上报的RU范围，10秒内不会离开邻区范围。这个有效时间其实非常保守，年前局外实测，将“子网方式RU有效时间RUSNAvailableTime”改为180秒。改成180秒后完全没有降低寻呼成功率，但是明显降低了寻呼对系统的负荷，特别是寻呼还有突发特性。强烈建议将这个值修改为180秒，甚至更多，180秒已经实测过，更多的话需要实测确定。 PCF重发A9-BS Service Request机制PCF重激活等待A9-setup-A8定时器默认为10秒（此定时器不可修改）。在该定时器超时后，如果超时，PCF将向AN重发A9-BS Service Request，最多重发2次。2.1.2 SCI=9的寻呼策略补充说明1、AN收到PCF发送来的A9-BS Service Request，会发送1个page消息。1）寻呼次数：1次2）寻呼范围：通过计算得出在哪个范围内进行寻呼3）触发寻呼的条件：AN 收到PCF 的“A9-BS Service Request”,且无空口连接。2、对SCI=9的终端，PCF存在禁止后续寻呼的机制3次寻呼无响应后，PCF将禁止后续的寻呼（即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼）。直到收到用户主动发起建立请求消息后，才取消对此用户的寻呼禁止。2.1.3 SCI=5的寻呼策略补充说明1、AN收到PCF发送来的A9-BS Service Request，会发送2个page消息。1）寻呼次数：2次（不可配置）2）寻呼间隔：1.5秒（可配置）3）寻呼范围：3级，每次寻呼前通过计算得出在哪个范围进行寻呼4）触发寻呼的条件：AN 收到PCF 的“A9-BS Service Request”,且无空口连接。2、对SCI=5的终端，PCF存在禁止后续寻呼的机制6次寻呼无响应后，PCF将禁止后续的寻呼（即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼）。直到收到用户主动发起建立请求消息后，才取消对此用户的寻呼禁止。2.2 QChat业务寻呼策略优化建议1、寻呼间隔：1.5秒2、分层寻呼范围的2个时间间隔参数：“邻区方式RU有效时间RUNLAvailableTime”为1000 ms，“子网方式RU有效时间RUSNAvailableTime”值为10000 ms。这一参数对所有业务均发生作用。三、华为无线设备寻呼机制3.1 EVDO寻呼机制根据终端与网络协商的不同SCI值，有分别针对SCI=9和SCI=5的2套寻呼策略，且两套寻呼策略有不同的默认参数。目前现网普通DO数据卡业务（BE业务）均采用SCI=9。无论是否开启QoS，QChat业务都会把SCI协商为5。3.1.1 寻呼机制描述SCI=9与SCI=5的寻呼机制基本相同，可以根据实际业务需求设置2套参数，从而使普通DO数据卡业务与QChat业务有不同的寻呼策略。寻呼机制包含2个方面：PCF的A9-BS Service Request重发机制和AN多次寻呼机制。 AN多次寻呼机制PCF向AN发起A9-BS Service Request后，AN按照设定的寻呼策略发起对AT的寻呼（Page消息）。Page消息最多发送3次， Page消息发送的范围和两次Page消息间的时间间隔均可在一定范围内进行设定。SCI=9的普通用户寻呼间隔为7秒，SCI=5的Qchat用户为1.6秒。AN寻呼策略默认为在子网、子网、AN（目前默认第一次为基于子网寻呼）范围寻呼3次（可设定），每次寻呼间隔可设定（SMP8号定时器：发送了Page消息后等待Connection req消息的定时器，超时后此次寻呼失败，进行下一次寻呼）。 PCF重发A9-BS Service Request机制PCF具有重发A9-BS Service Request的机制。PCF重激活等待A9-Setup-A8应答的定时器超时（PCU14号定时器：默认为22秒）或者AN三次寻呼AT失败后，PCF将删除触发当前寻呼的数据报文。如果此时PCF还有其他数据发送，AN将重发A9-BS Service Request。对于SCI=9的普通数据业务用户，若三次等待A9-setup-A8均超时，则会启动PPP释放定时器（默认为30000毫秒），该定时器启动后，系统禁止再次寻呼手机，避免该用户造成大量的寻呼失败。但用户可以主动接入，用户主动接入后则停止该定时器。该定时器超时后，PCF会删除该用户的PPP。对于SCI=5的Qchat用户，若三次等待A9-setup-A8均超时，不会启动PPP释放定时器。有Qchat寻呼时，系统继续对QChat用户进行寻呼。举例：SCI=9的普通用户寻呼机制3.1.2 寻呼机制相关参数说明1、AN多次寻呼机制参数1）寻呼次数：3次（不可修改），也就是说，AN收到PCF发送来的A9-BS Service Request，最多会发送3个page消息。2）寻呼范围：第一次可配置为子网、最近一次RU上报的激活集扇区、距离或AN，第二次（子网）和第三次（AN）寻呼范围分别固定为子网和AN。3）寻呼间隔：可设定，任两次寻呼消息之间的时间间隔均相同4）触发首次寻呼必须满足的条件：a）PCF从PDSN收到DATA-Transferb）PCF未禁止对此AT的寻呼c）无空口连接5）触发第二次、第三次寻呼的条件：首次、第二次寻呼无应答，且寻呼定时器超时2、PCF重发A9-BS Service Request机制PCF重激活等待A9-setup-A8定时器默认为22秒；如果超时，PCF将向AN重发A9-BS Service Request，最多再重发2次。3.1.3 SCI=9的寻呼策略补充说明1）对SCI=9的终端，AN多次寻呼机制中2次寻呼间隔默认为7秒。2) 对SCI=9的终端， PCF存在禁止后续寻呼的机制9次寻呼无响应后，PCF禁止后续的寻呼（即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼）。3.1.4 SCI=5的寻呼策略补充说明1、对SCI=5的终端，AN重发机制中2次寻呼间隔默认为1.6秒。2、对SCI=5的终端， BSC多次寻呼失败后，不启动PPP释放定时器，不存在禁止后续寻呼的机制3.2 QChat业务寻呼参数优化建议使用SCI=5（QChat业务）的寻呼策略(华为版本默认值已经修改)：1、寻呼间隔：1.6秒（默认値）2、寻呼范围：子网（第一次寻呼）/子网（第二次寻呼）/AN（第三次寻呼）。四、阿朗无线设备寻呼机制4.1 EVDO寻呼机制描述可以针对普通DO数据卡终端（BE业务）和QChat业务设置两套寻呼策略：DBE寻呼 (缺省的Best Effort寻呼)策略和基于QoS的寻呼策略。当QChat业务QoS功能激活后，可通过对特定的profile ID（16400、1283和280）配置激活使用基于QoS的寻呼；当某profile ID未配置激活基于QoS的寻呼时，RNC收到PDSN的DATA-Transfer包后使用缺省的BE寻呼。无论是否开启QoS，QChat业务都会把SCI协商为5。RNC具有多次寻呼机制，即在收到PDSN发送来的数据包后在一定的范围内发送多次page消息，寻呼范围、寻呼次数及两次寻呼间隔均可设定。1）寻呼次数：可设定，最多8次对于BE寻呼，Last active set和last seen RNC最多各4次；对于QoS寻呼，active set和RNC寻呼的次数无限制，但总的寻呼次数是8次。2）寻呼范围：可选择the Last Active Set或the Last Seen RNC对于BE寻呼，顺序上默认Last active set寻呼总是先于last seen RNC，除非不选择进行active set 寻呼。对于基于Qos的寻呼，在网管设置上没有先后顺序的限制，但逻辑上应该先进行last active set寻呼，除非不选择last active set 寻呼。3）寻呼间隔：默认值是2秒，对于BE寻呼在在0.110之间可设定，对于Qos寻呼，在0.1-5之间之间可设定。实际2次寻呼消息之间的时间间隔取SCI与寻呼间隔两者之间的较大值，即基站在空口发送寻呼消息的间隔为max（寻呼间隔，寻呼周期SCI），例如，设定寻呼间隔=2秒，且SCI=9，那么RNC向BTS发送寻呼消息的间隔为5.12秒。4）寻呼周期SCI：SCI=9（5.12秒）默认通过EIS协议，终端可以协商短的寻呼周期。目前QChat业务协商的SCI=5。5）触发首次寻呼必须满足的条件：DBE寻呼策略：PCF从PDSN收到DATA-Transfer，且无空口连接。QoS寻呼策略：收到A10上的数据，且无空口连接，并从与此A10关联的RLP流中获取到profileID。6）触发二次/(n+1)次寻呼的条件：首次/n次寻呼无应答，且寻呼定时器超时阿朗设备没有A8/A9接口，不存在A9-BS Service Request重发机制。另外，RNC也不存在禁止后续寻呼的机制。DBE（缺省的Best Effort）寻呼和基于QoS的寻呼机制相同，可通过采用不同的参数设置使普通DO数据卡终端（BE业务）和激活QoS的QChat业务具有不同的寻呼策略。4.2、QChat业务寻呼参数优化建议4.2.1 不开启QoSDBE寻呼参数：1）寻呼次数：保持现网设置不变；2）寻呼间隔：1秒（大部分的现网値为2秒）3）寻呼范围：保持现网设置不变。 解决由于寻呼范围小、寻呼间隔过大造成寻呼被叫过晚引起的QChat业务呼叫失败的问题时，需要考虑解决方案对普通DO数据业务造成的影响（寻呼响应率、寻呼时延和寻呼信道负荷等指标的影响）不大。 在阿朗系统中，2次page消息之间的时间间隔取SCI与寻呼间隔之间的较大值，即RNC向BTS发送寻呼消息的间隔为max（寻呼间隔，寻呼周期SCI）。例如，设定寻呼间隔=1秒，且SCI=9，那么RNC向BTS发送寻呼消息的间隔为5.12秒；如设定寻呼间隔=1秒，且SCI=5（终端的醒来周期为128个时隙），那么RNC向BTS发送寻呼消息的间隔为1秒之后的终端的第一个醒来周期。那么，将DBE寻呼参数的寻呼间隔改小为1秒，既可以解决寻呼被叫过晚引起的QChat业务呼叫失败的问题，对普通DO数据业务造成的影响（寻呼响应率、寻呼时延和寻呼信道负荷等指标的影响）也不大。 4.2.2 开启QoS激活基于QoS的寻呼。对QChat业务使用的3个profile ID（16400）配置激活使用基于QoS的寻呼。 profile ID等于16400的激活QoS寻呼参数：1）寻呼次数：3次2）寻呼间隔：1.6秒3）寻呼范围：Last active set（第一次）/last seen RNC（第二次）/ last seen RNC（第三次）。 profile ID等于1283的激活QoS寻呼参数：1）寻