GSM BSS 网络性能 KPI 呼叫建立时延 优化手册 仅供内部使用Word文件下载.docx
《GSM BSS 网络性能 KPI 呼叫建立时延 优化手册 仅供内部使用Word文件下载.docx》由会员分享，可在线阅读，更多相关《GSM BSS 网络性能 KPI 呼叫建立时延 优化手册 仅供内部使用Word文件下载.docx（14页珍藏版）》请在冰豆网上搜索。
摘要:
本文主要介绍了呼叫建立时延的优化方法。
1.呼叫建立时延定义说明
1.1呼叫建立时延含义
呼叫建立时间反映了用户从发起呼叫到呼叫建立的平均时延,如果该指标过长,将严重影响用户感受,是运营商重点关注的指标之一。
1.2推荐公式
呼叫建立时间主要通过路测结果获得,是终端MS在无线网络设备中建立端到端呼叫流程所需时间,可以分为三种情况,具体见下文描述:
✓MStoPSTN:
从MS发CHANNELREQUEST到MS收到MSC下发ALERTING信令之间的平均耗时;
✓MStoMS:
从主叫MS发送CHANNELREQUEST到主叫MS收到MSC下发
ALERTING信令之间的平均耗时;
✓PSTNtoMS:
从MSC下发PAGING到MS向MSC发送ALERTING信令之间的平均耗时;
注:
呼叫建立时间统计的是多次成功的呼叫建立时间的平均值,在测试时需要多次拨测取平均。
1.3信令流程及统计点
BTSBSC
图1主叫流程的呼叫建立时间统计点（以早指配流程为例
MSBTSBSCMSC
图2被叫流程的呼叫建立时间统计点（以早指配流程为例
其中,A——MS发送ChannelRequest的时间点
B——MS收到MSC下发的Alerting的时间点
C——MSC下发Paging的时间点
D——MS发送Alerting的时间点
在MStoMS、MStoPSTN的测试方法中,呼叫建立时间为（B-A;
在PSTNtoMS的测试方法中,呼叫建立时间为（D-C。
2.涉及特性
不涉及。
3.影响呼叫建立时延的因素
3.1流程配置
主被叫的呼叫时延中都涉及到许多的流程,如鉴权、加密等,同时又关联到MSC、BSC、BTS和MS等多个网元,所以呼叫流程的配置直接决定着呼叫时延的长短。
3.2参数设置
呼叫建立时延涉及到主叫、被叫信令的整个流程,因此影响呼叫时延的参数较多。
1.相同寻呼间复帧数:
2.立即指配重发参数开关:
3.立即指配重发最大允许延迟时间、立即指配重发最大允许发送次数:
4.预寻呼功能（N侧配置:
5.立即指配优化:
6.ECSC（极早类标发送控制:
7.允许重指配:
8.晚指配功能（N侧配置:
9.指配命令优化;
10.是否在指配中强制开通排队功能;
11.T11。
3.3其它问题
由于在不同网络设备厂家之间的产品可能存在着差别,所以针对跨厂家设备或路由发生变化时,应该根据具体的路测数据情况进行分析处理。
3.4硬件、传输、覆盖、干扰等问题
硬件、传输、覆盖和干扰等出现问题时,也会导致呼叫时延的增加。
4.呼叫建立时延分析流程和优化方法4.1分析流程图
4.2呼叫建立时延问题定位及优化方法说明
4.2.1流程配置问题
在呼叫建立流程中,有些流程是可选的,如鉴权、加密、TMSI重分配等流程,而且他们是相互独立,可根据运营商的要求进行灵活配置。
现网一般加密全部打开,鉴权、TMSI重分配按一定比例（10%~20%进行。
鉴权:
对于3G用户,若接入GSM网络进行鉴权时,N侧通过下发鉴权消息（含RAND、AUTN、RES进行鉴权。
由于包含RAND、AUTN、RES的鉴权消息大于23字节,LAPDm需2次分割下发。
因此在GSM网络下,3G用户相比2G用户,其呼叫建立时延多240~260ms左右。
说明:
另外若BSC分配AMR信道,跳频MA过长时会出现AssignmentCommand长度超过23字节,也会造成多延迟240~260ms左右。
加密:
对于主叫:
若不进行加密流程,MS需收到N侧CmServiceAccept,才会上报Setup;
而打开加密流程后,MS加密完成后可以立即上报Setup;
因此对于移动主叫用户,打开加密一般比不打开加密仅增加250~300ms的时延,主要由于多上报一条上行消息（加密完成导致。
TMSI重分配:
TMSI是根据网络侧的设置,在每次或若干次空中接口操作后（呼叫或位置更新时,重新分配一次。
类标查询:
为了获得MS的多频段,多时隙等支持能力,核心网可以通过类标查询流程获取MS相关信息。
在B侧有小区级参数:
ECSC（极早类标发送,通过系统消息3下发,MS一旦接入,会主动上报Classmark3（协议规定:
多频段,多时隙能力,支持组呼的MS必须实现。
在实际网中,友商核心网一般不打开类标查询,多采用ECSC,这样减少空口LAPDm信令的交互,减少了呼叫建立时延。
而我司核心网默认全部打开类标查询,且用户不可配置,只能通过保留软参进行控制。
因此,在B侧相同（打开ECSC,采用我司核心网时的呼叫接续时延要多出240ms以上。
<
相关案例1>
<
相关案例2>
LAPDm层I帧优化:
我司BTS在LAPDm层未能实现下行I帧证实上行I帧的功能,即在接收到MS的上行I帧后,立即回应了RR响应帧,若这次收发这个过程中收到BSC的下行I帧,使得下行I帧只能推迟了一个下发周期下发,增加了时延。
可升级版本将其优化,实现用下行I帧证实上行I帧,即在收到MS的上行I帧后BTS不立即下发RR帧,而是等待一定时延,判断是否会收到下行I帧,若有的话可以直接利用下行I帧进行确认上行I帧,节省了一个下发周期,减少时延。
如下图。
上述优化手段只能通过BTS版本升级来实现,没有相应的设置项。
目前在BTS:
V3R8C11B337版本中将会包含此功能,现场对呼叫时延进行优化时,可考虑BTS版本是否已进行了I帧优化。
4.2.2参数设置问题
影响呼叫建立时延的主要参数:
该参数决定了寻呼以多少个复帧数作为寻呼子信道的一个循环,该参数过大,寻呼消息的平均时延就越大。
从而增加MStoMS、PSTNtoMS的呼叫建立时间。
该参数配置为“是"
则BSC下发立即指配重发参数,否则不
下发。
该功能可以提高MS接通率,但是会增加MS接入时延和BSC的负荷。
（建议关闭
3.立即指配重发最大允许延迟时间、立即指配重发最大允许发送次数:
这类参数决定了立即指配重发的次数和最大允许延迟时间。
如果网络环境较差,需要进行立即指配重发,则这类参数决定了重发可能的最大时长,如果设置过大,则可能导致呼叫建立平均时间变长。
打开预寻呼功能后N侧在收到主叫Setup消息后立即进行被叫寻呼,而未打开时N侧在下发Callproceeding之后立即进行被叫寻呼。
因此对于手机打手机,打开预寻呼功能后会减少主叫的呼叫建立时延。
（建议打开
5.立即指配优化:
指将信道激活和立即指配同时下发,加快信令的处理过程,以保证网络的响应速度。
6.ECSC（极早类标发送:
表示在某个小区内的MS是否使用提早发送类标。
在立即指配成功后,MS尽可能早的发送附加的类标信息给网络。
对双频MS而言,该参数设置为“否"
时,MS在上报ESTIND后,而MSC仍然会发起CLASSMARKREQUEST消息,MS上报CLASSMARKUPDATE消息,对MS的接入时延有影响。
当BSC收到Um口的指配失败消息时,BSC发起二次指配,其有利于提高MS的接通率,提高网络服务质量,但在重指配成功后,会增加MS的接入时延并可能增加BSC负荷。
（建议关闭
8.晚指配流程（N侧配置:
在振铃后再下发指配命令,可以减少呼叫建立时延的统计,但由于晚指配流程中Alerting之后并不表示可以进行通话,所以一般不对晚指配流程进行呼叫建立时间的考核。
9.指配命令优化:
我司跳频时指配命令中跳频频点默认以CA+MA的形式下发,这样可能使指配命令消息长度大于23个字节,在LAPDm层指配命令消息就须被拆分成两个I帧下发,增加了一个下发周期,增加时延约230ms。
可以将其给为Frequencylist的形式下发,以保证指配命令消息能尽可能的以一个I帧下发,以减少呼叫时延。
现网中建议使用Frequencylist的形式下发指配命令,设置方法如下:
此功能在:
BSC6000V900R008C11B168SP11及以上版本支持。
10.是否在指配中强制开通排队功能:
如果此参数设置为"
是”,则当BSC收到指配请求时:
如果没有空闲的TCH信道可以分配,即使指配请求中携带的queuingallowedindicator的值为"
1”,也将该消息放入指配请求消息队列;
有空闲信道时,BSC为MS分配信道。
否”,则指配请求中携带的queuingallowedindicator的值为"
0”,则该指配请求不允许放入指配请求消息队列,信道申请失败。
改参数默认值为否。
11.T11:
信道指配时的排队定时器。
当BSC接收到信道请求,且分配不到可用信道时,BSC将启动排队流程,并启动此定时器。
若在定时器超时前,申请信道成功,则停止该定时器,否则定时器超时时,信道指配失败。
当在开启排队功能时,T11值设置过大将直接影响到呼叫建立的时延,使时延加大。
4.2.3其它问题
在现网中,由于搬迁前后,BSC和MSC都进行重新划分和布局,导致呼叫路由产生变化,在跨MSC出局时,可能会对呼叫时延产生影响。
针对这样的问题,要先进行测试,并对前后的测试结果进行分析对比。
相关案例>
以实验室MS-MS为例,各个信令点间时延如下表所示。
具体的时延和现场实际环境关联较大,以下数据仅作为作参考。
（版本号:
核心网:
G9MSC90MSOFTX3000V100R003
;
BSC:
V9R8C01B051;
BTS:
V3.03R002.20011015
4.2.4硬件、传输、覆盖、干扰等问题
当出现TRX或合路器故障,射频连线错误等硬件情况时,将会造成SDCCH和TCH占用困难,会导致呼叫建立时延的增大。
Abis接口、A接口链路等传输质量不好,传输链路不稳定,或者资源不足、误码等异常将造成链路差错率增加,导致交换机之间消息重传的次数增多,致使消息传送时延增加,链路发生拥塞。
严重时将使链路频繁进行倒换和倒回,造成链路运行不稳定,链路出现拥塞现象。
上述情况如果发生在呼叫建立阶段,将会增加呼叫建立时延。
当网络上存在着覆盖或干扰问题时,我们可以查看相关话统或KPI来判断。
如判断干扰问题时,可以通话查看话统中的干扰带分布情况获得,如果干扰带3-5级的比例较高,说明存在较严重的上行干扰;
下行干扰可以通过路测发现,也可以通过分析接收质量话统发现。
如果存在着较强的干扰,TCH掉话率、TCH指配成功率,SDCCH建立成功率都会受到影响。
这样就会对呼叫建立时延产生影响。
排查干扰可以分网内干扰和网外干扰分别进行排查,具体排查方法请参见《G-干
扰问题处理指导书》。
如果确认覆盖存在问题,可通过调整天线下倾角、增大发射功率,添加直放站、改变合路方式等方法来解决覆盖问题。
具体解决办法请参考《GSMBSS网络性能KPI（覆盖问题优化手册》
5.测试方法
呼叫建立时延是路测类指标,可进行MS-MS或MS-PSTN间的CQT和DT测试。
利用手机MOC短呼测试,两次呼叫间隔5s,通话持续10s,如果呼叫失败,间隔30s再重新发起下一次呼叫,推荐测试呼叫100次左右,具体测试次数请根据现场要求合理调整;
需要跟踪呼叫的Um口信令和A口信令。
对于呼叫建立时间异常值,请根据信令分析是否因为首次寻呼不成功导致,如果是则剔除该异常值,如果否,则正常统计。
查看A口信令,如果针对一次呼叫,MSC下发了两次Paging消息,则该次呼叫首次寻呼不成功。
6.呼叫建立时延优化案例
6.1指配命令下发周期较长,导致呼叫建立时延加长
现象描述:
某局点现网搬迁后呼叫接续时延长于原网（爱立信,发现我司指配命令需2、3个下发周期,而爱立信大多只需1个下发周期。
处理过程:
在跳频模式下,目前BSC6000产品在指配命令下发频点采用CA+MA方式,由于CA（TV格式长度固定为17字节,再加上MA（TLV格式长度3~10字节,若分配AMR（TLV格式,则再得加上4~8字节,导致指配命令的长度大于23字节,因此在LAPDm层将指配命令拆分下发;
而友商全部采用FrequencyList（TLV格式方式下发,大多数只需要1个下发周期。
建议与总结:
在配置BSC参数【指配命令频点下发方式】
（仅当小区跳频打开时有效,
1、若【指配命令频点下发方式】为【CA+MA】时,采用目前频点下发方式不变;
2、若【指配命令频点下发方式】为【FrequencyList】时,将实际的跳频频点编码后采用FrequencyList方式下发;
将信息调整在一个下发周期内发送,来减少呼叫时延。
6.2上报两次Classmarkchane消息导致呼叫时延过长
现象描述:
某局点现网搬迁后呼叫接续时延长于原网。
若为我司核心网,在打开【ECSC】时,呼叫建立信令流程中会多上报一条classmarkchange消息,原因是我司的核心网默认打开类标查询功能,如下图。
此时可通过设置【ECSC】为“是”和软参【类标更新优化类型】为“2”来避免这种情况的出现,也可协调核心网直接关闭类标查询功能。
6.3主被叫号码不在同一MSC内导致呼叫建立时延加长
在R国某搬迁项目中,个别BSC搬迁后,路测指标对比中,Callsetuptime比搬迁前增加了3000ms左右。
这个指标是项目的验收考核指标,用于计算Channelrequest
和Alerting之间的时延。
1、参数检查,由于是搬迁网络,参数继承原网,所以Callsetuptime相关参数没有被修改。
2、分析搬迁前后TEMS上的呼叫信令,搬迁前后加密流程时长也没有变化。
3、搬迁后的信令中多了2条Progress（该消息出现在AssCmp和connect之间,消息描述是:
Callisnotend-to-endPLMN/ISDN,furthercallprogressinformationmaybeavailablein-band。
从核心网跟踪的消息看,虽然搬迁前后被叫的测试号码没有变,但搬迁后对测试号码进行呼叫的时候,已经是出局呼叫了,原因是搬迁后,路测手机在华为的MSC下,但被叫的测试号码还是在友商的原MSC下。
现场在搬迁后路测是只注意被叫测试号码没有变化,但没有注意到主被叫号码已经不在同一个MSC下了。
所以对于搬迁前后的测试条件一致性问题,一定要注意这种比较隐蔽的测试条件变化。
6.4信令流程不一致导致呼叫时延过长
首先可从搬迁前后的呼叫建立信令流程分析,如搬迁后比搬迁前在呼叫建立中多了流程,则应去掉此流程。
以孟加拉GP搬迁前后的流程为例,如下图:
对比搬迁前后发现搬迁后多了GPRSSuspensionRequest流程,这与测试时手机有没有进行过GPRSattach有关,因为依据协议（Ref:
44.018此时不论手机有没有在做PS业务,手机都会上报GPRSSuspensionRequest消息,将PS业务挂起。
我们测试的是CS呼叫建立时长,因此应去掉这一流程,可通过更给手机设置
来去掉这一功能。
若采用NOKIA手机测试时:
可在工具->
设置->
连接-
升级会员 