QChat业务寻呼参数优化建议Word格式.docx
《QChat业务寻呼参数优化建议Word格式.docx》由会员分享,可在线阅读,更多相关《QChat业务寻呼参数优化建议Word格式.docx(11页珍藏版)》请在冰豆网上搜索。
第一层寻呼(最近上报的有效激活集扇区寻呼):
该级寻呼是对上次终端与基站发生消息交互时,AT上报的RU消息里包含的有效PN所在的BTS发送寻呼;
即上次上报的RU中如果包含N个有效PN,在对该终端做第一级寻呼时,这N个有效PN所属的所有BTS下的所有小区将发送寻呼消息;
距上次终端与基站侧联系间隔t,当满足t<
邻区方式RU有效时间(默认为1秒)时,在此区间寻呼。
第二层寻呼(邻区寻呼):
该级寻呼是对上次终端与基站交互的接入小区的所有邻区所属的BTS寻呼,即上次上报RU的接入小区是Cell1,对Cell1所有邻区所在的BTS的所有小区发送寻呼消息;
距上次终端与基站侧联系间隔t,当满足:
邻区方式RU有效时间<
t<
.子网方式RU有效时间(默认在1秒到10秒间),在此区间寻呼。
第三层寻呼(子网+邻区寻呼):
该级寻呼是对上次终端与基站发生消息交互时,接入小区所在的子网和接入小区邻区从属的BTS的合集发寻呼,即上次上报的RU的接入小区是Cell1,对Cell1所在子网,以及Cell1的非本子网的邻区所在的BTS发送寻呼消息;
距上次终端与基站侧联系间隔超过t,当满足:
t>
子网方式RU有效时间(默认10秒),在此区间寻呼。
基站首次发送寻呼消息的范围不一定是第一层,这是因为终端在休眠下在子网内移动可能不会上报路由更新消息,因此第一层和第二层的寻呼范围有时效性。
从进入休眠开始,超过一定时间后,就不能认为用户还在原来的位置。
寻呼层次的选择与2个参数有关,邻区方式RU有效时间RUNLAvailableTime(以下描述用t1表示),子网方式RU有效时间RUSNAvailableTime(以下描述用t2表示),且t1<
t2。
这两个参数与寻呼层次的关系如下:
1)当0<
t<
=t1时,寻呼的范围是第一级(最近一次激活集内的扇区,下图中红色基站表示寻呼区域);
2)当t1<
t<
t2时,寻呼的范围是第二级(邻区方式寻呼,下图中红色基站表示寻呼区域);
3)当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-BSServiceRequest机制
PCF重激活等待A9-setup-A8定时器默认为10秒(此定时器不可修改)。
在该定时器超时后,如果超时,PCF将向AN重发A9-BSServiceRequest,最多重发2次。
2.1.2SCI=9的寻呼策略补充说明
1、AN收到PCF发送来的A9-BSServiceRequest,会发送1个page消息。
1)寻呼次数:
1次
2)寻呼范围:
通过计算得出在哪个范围内进行寻呼
3)触发寻呼的条件:
AN收到PCF的“A9-BSServiceRequest”,且无空口连接。
2、对SCI=9的终端,PCF存在禁止后续寻呼的机制
3次寻呼无响应后,PCF将禁止后续的寻呼(即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼)。
直到收到用户主动发起建立请求消息后,才取消对此用户的寻呼禁止。
2.1.3SCI=5的寻呼策略补充说明
1、AN收到PCF发送来的A9-BSServiceRequest,会发送2个page消息。
2次(不可配置)
2)寻呼间隔:
1.5秒(可配置)
3)寻呼范围:
3级,每次寻呼前通过计算得出在哪个范围进行寻呼
4)触发寻呼的条件:
2、对SCI=5的终端,PCF存在禁止后续寻呼的机制
6次寻呼无响应后,PCF将禁止后续的寻呼(即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼)。
2.2QChat业务寻呼策略优化建议
1、寻呼间隔:
1.5秒
2、分层寻呼范围的2个时间间隔参数:
“邻区方式RU有效时间RUNLAvailableTime”为1000ms,“子网方式RU有效时间RUSNAvailableTime”值为10000ms。
这一参数对所有业务均发生作用。
三、华为无线设备寻呼机制
3.1EVDO寻呼机制
根据终端与网络协商的不同SCI值,有分别针对SCI=9和SCI=5的2套寻呼策略,且两套寻呼策略有不同的默认参数。
3.1.1寻呼机制描述
SCI=9与SCI=5的寻呼机制基本相同,可以根据实际业务需求设置2套参数,从而使普通DO数据卡业务与QChat业务有不同的寻呼策略。
寻呼机制包含2个方面:
PCF的A9-BSServiceRequest重发机制和AN多次寻呼机制。
AN多次寻呼机制
PCF向AN发起A9-BSServiceRequest后,AN按照设定的寻呼策略发起对AT的寻呼(Page消息)。
Page消息最多发送3次,Page消息发送的范围和两次Page消息间的时间间隔均可在一定范围内进行设定。
SCI=9的普通用户寻呼间隔为7秒,SCI=5的Qchat用户为1.6秒。
AN寻呼策略默认为在子网、子网、AN(目前默认第一次为基于子网寻呼)范围寻呼3次(可设定),每次寻呼间隔可设定(SMP8号定时器:
发送了Page消息后等待Connectionreq消息的定时器,超时后此次寻呼失败,进行下一次寻呼)。
PCF具有重发A9-BSServiceRequest的机制。
PCF重激活等待A9-Setup-A8应答的定时器超时(PCU14号定时器:
默认为22秒)或者AN三次寻呼AT失败后,PCF将删除触发当前寻呼的数据报文。
如果此时PCF还有其他数据发送,AN将重发A9-BSServiceRequest。
对于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多次寻呼机制参数
3次(不可修改),也就是说,AN收到PCF发送来的A9-BSServiceRequest,最多会发送3个page消息。
第一次可配置为子网、最近一次RU上报的激活集扇区、距离或AN,第二次(子网)和第三次(AN)寻呼范围分别固定为子网和AN。
3)寻呼间隔:
可设定,任两次寻呼消息之间的时间间隔均相同
4)触发首次寻呼必须满足的条件:
a)PCF从PDSN收到DATA-Transfer
b)PCF未禁止对此AT的寻呼
c)无空口连接
5)触发第二次、第三次寻呼的条件:
首次、第二次寻呼无应答,且寻呼定时器超时
2、PCF重发A9-BSServiceRequest机制
PCF重激活等待A9-setup-A8定时器默认为22秒;
如果超时,PCF将向AN重发A9-BSServiceRequest,最多再重发2次。
3.1.3SCI=9的寻呼策略补充说明
1)对SCI=9的终端,AN多次寻呼机制中2次寻呼间隔默认为7秒。
2)对SCI=9的终端,PCF存在禁止后续寻呼的机制
9次寻呼无响应后,PCF禁止后续的寻呼(即PCF收到PDSN发送来的DATA-Transfer后不会发起对此AT的寻呼)。
3.1.4SCI=5的寻呼策略补充说明
1、对SCI=5的终端,AN重发机制中2次寻呼间隔默认为1.6秒。
2、对SCI=5的终端,BSC多次寻呼失败后,不启动PPP释放定时器,不存在禁止后续寻呼的机制
3.2QChat业务寻呼参数优化建议
使用SCI=5(QChat业务)的寻呼策略(华为版本默认值已经修改):
1.6秒(默认値)
2、寻呼范围:
子网(第一次寻呼)/子网(第二次寻呼)/AN(第三次寻呼)。
四、阿朗无线设备寻呼机制
4.1EVDO寻呼机制描述
可以针对普通DO数据卡终端(BE业务)和QChat业务设置两套寻呼策略:
DBE寻呼(缺省的BestEffort寻呼)策略和基于QoS的寻呼策略。
当QChat业务QoS功能激活后,可通过对特定的profileID(16400、1283和280)配置激活使用基于QoS的寻呼;
当某profileID未配置激活基于QoS的寻呼时,RNC收到PDSN的DATA-Transfer包后使用缺省的BE寻呼。
RNC具有多次寻呼机制,即在收到PDSN发送来的数据包后在一定的范围内发送多次page消息,寻呼范围、寻呼次数及两次寻呼间隔均可设定。
可设定,最多8次
对于BE寻呼,Lastactiveset和lastseenRNC最多各4次;
对于QoS寻呼,activeset和RNC寻呼的次数无限制,但总的寻呼次数是8次。
可选择theLastActiveSet或theLastSeenRNC
对于BE寻呼,顺序上默认Lastactiveset寻呼总是先于lastseenRNC,除非不选择进行activeset寻呼。
对于基于Qos的寻呼,在网管设置上没有先后顺序的限制,但逻辑上应该先进行lastactiveset寻呼,除非不选择lastactiveset寻呼。
默认值是2秒,对于BE寻呼在在0.1~10之间可设定,对于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-BSServiceRequest重发机制。
另外,RNC也不存在禁止后续寻呼的机制。
DBE(缺省的BestEffort)寻呼和基于QoS的寻呼机制相同,可通过采用不同的参数设置使普通DO数据卡终端(BE业务)和激活QoS的QChat业务具有不同的寻呼策略。
4.2、QChat业务寻呼参数优化建议
4.2.1不开启QoS
DBE寻呼参数:
保持现网设置不变;
1秒(大部分的现网値为2秒)
保持现网设置不变。
解决由于寻呼范围小、寻呼间隔过大造成寻呼被叫过晚引起的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个profileID(16400)配置激活使用基于QoS的寻呼。
profileID等于16400的激活QoS寻呼参数:
3次
1.6秒
Lastactiveset(第一次)/lastseenRNC(第二次)/lastseenRNC(第三次)。
profileID等于1283的激活QoS寻呼参数:
2秒
Lastactiveset(第一次)/lastseenRNC(第二次)/lastseenRNC(第三次),可视实际负荷情况进行适当调整。
profileID等于280的激活QoS寻呼参数:
2次
Lastactiveset(第一次)/lastseenRNC(第二次),可视实际负荷情况进行适当调整。
附录一:
EVDO寻呼流程
网络侧发起的呼叫激活流程说明如下。
1.AT处于Dormant态。
2.PDSN在A10连接上向PCF发送分组数据包。
3.PCF判断分组数据呼叫处于Dormant态,向AN发送A9-BSServiceRequest消息请求分组数据业务。
4.AN用A9-BSServiceResponse消息响应PCF。
5.AN向AT发送Page消息。
6.AT向AN发送ConnectionRequest消息和RouteUpdate消息,请求建立空口连接。
7.AN组装TrafficChannelAssignment消息,发送给AT。
8.AT发送TrafficChannelComplete消息,确认空中接口连接建立。
9.AN向PCF发送A9-Setup-A8消息,请求建立A8连接。
10.PCF向PDSN发送A11-Registration-Request消息,请求记录计费相关信息。
11.PDSN返回A11-Registration-Reply消息。
12.PCF向AN返回A9-Connect-A8消息,A8连接建立成功。
13.分组数据业务进入连接态。