LeafFly

I'm a leaf on wind, Watch how I fly.

收发短信时延与优化分析

摘要:
随着短信业务的逐渐发展,在用户业务中所占比重越来越高,短信的接收时延问题逐渐成为影响用户感受的重要问题,本文通过结合无线侧,通过信令分析对产生时延的各阶段进行了详细阐述,并进行了降低时延的各种优化试验。
案例分析背景:
短信接收时延是体现网络质量的重要部分,也是集团第三方网络测试的考核项目,而我们这一指标和广东、辽宁等采用爱立信设备的网络一样,处于比较靠后的水平,为了找到原因,尽可能的压缩接收时延,对其进行了测试和分析。
问题描述:
一、初步问题定位
根据第三方测试结果,我省短消息中心存在首次成功下发短消息时延过长的问题,修改IMEI验证后约为4.6秒,略低于全国平均水平。引起短消息收发速度缓慢的原因不外乎两个环节:1、短消息系统处理消息速度慢。2、GSM网络传送消息速度慢。因此,我们确定了测试方案:跟踪短信中心USAU到LSTP间的链路,通过信令消息来确定时延发生在那一段。在短信USAU上闭掉一定中继链路,以便能快速跟踪到短消息收发的所有信令。通过信令跟踪发现,短信下发延时主要是MSC以下下发过程缓慢,导致短信延时较大。具体分析如下:
1、短消息信令过程简介
1条正常的点对点短消息,在短消息中心与LSTP之间共有6条信令交互,它们是:MO_DATA(前转的短消息)、MO_ACK(前转短消息的应答)、SMS_REQ(取路由消息)、SMS_REQ_ACK(取路由消息的应答)、MT_DATA(下发短消息)、MT_ACK(下发短消息的应答)。
MO过程如下图所示:

 

 

 

 

 

 

 

MT过程如下图所示:

 

 

 

 

 


2、对信令跟踪结果的分析
09:29:20短消息中心从MSC接收到mo短消息,然后短消息中心在同一秒内09:29:20非常迅速地给手机返回mo_ack应答;几乎同时,短消息中心仍在同一秒内随即向HLR发出取路由的消息,并在09:29:21收到取路由的应答消息。MO_DATA、MO_ACK和SMS_REQ过程不存在时延问题,平均时间开销不到1秒钟。短消息中心在收到路由应答消息后,也在09:29:21立即开始了向MSC下发短消息的过程,但是MSC侧的时间开销比较大,短信中心在4秒后才收到了手机经MSC返回的应答确认消息。这就导致被叫用户最终收到短消息的耗时较长。
由以上跟踪结果发现,短信中心从接收到mo消息到取路由并开始下发只用了不超过1秒时间。在MSC侧的时间开销短则4秒内可以完成,长则5秒多。
由此可见,短信延时主要发生在MT过程,MT下发时延主要是在从MSC到手机这一段环节上。
分析过程:
二、两种测试方式的差异
利用CDS进行短信测试通常采用两种方式:自发自收短信、两部不同的手机间收发短信。集团公司第三方测试中采用第二种方式。
1、自发自收短信测试
4月12日至14日,我们从CQT测试点中随机选取了3个,共进行了433次测试,测试结果如下:
地市 地点编号 地点名称 SMS发送尝试次数 SMS点到点成功次数 SMS点到点成功率 SMS点到点平均时间
YY 综合结果: 433 432 99.80% 2.5
YY 1 智慧大厦_1.log 100 100 100.00% 2.5
YY 2 智慧大厦_2.log 100 100 100.00% 3.2
YY 3 东郊饭店_1.log 50 50 100.00% 1.8
YY 4 东郊饭店_2.log 100 99 99.00% 2.8
YY 5 八一22楼_SAGEM290.log 50 50 100.00% 1.7
YY 6 八一22楼_SAGEM290.log 33 33 100.00% 1.8

2、不同手机间收发短信测试
4月13日在八一22楼同一地点、同一时段,并且无线环境类似的情况下,采用不同手机间收发短信也进行了测试,对比结果如下:
地点名称 测试方式 SMS发送尝试次数 SMS点到点成功次数 SMS点到点成功率 SMS点到点平均时间
八一22楼.log OT290自发自收 50 50 100.0% 1.7
八一22楼.log OT190发、OT290收 50 50 100.0% 4.1

 


每一次的时延统计如下图:

去除两手机互发时出现的一次11.45秒的超长时延短信外,两手机互发时MT短信时延平均为3.97秒,而自发自收时平均时延为1.71秒,两者相差2.26秒。
3、时长差异分析
由上面统计看出,不同手机间收发短信时MT时延在4秒左右,典型的信令流程如下:

 

 

 

 

 

 

 

而手机自发自收短信时MT时延在2秒以下,典型的信令流程如下:

 

 

 

 

 


可见,38:11.137手机上发CP-ACK,上发短信完成,而在1.4秒以后系统即下发下行短信,中间没有寻呼的过程,缺少的信令过程如下:

 

缺少的这一段信令耗时约为2-2.5秒。
手机自发自收时合计进行的433次测试中,去除1次发送失败,在其余成功的432次中,包含信道释放寻呼立即指配加密模式过程的MT短信合计96次,占22.2%,不经过信道释放寻呼立即指配加密模式过程而直接下发CP-DATA的MT过程合计336次,占77.8%。而不同手机间收发短信时进行的50次测试中,所有MT过程均包括信道释放寻呼立即指配加密模式流程,而该过程的平均耗时在2-2.5秒,可见,是否经过该过程是两种测试方式时延差别的原因所在。
4、几个问题的假设分析
假设1:是否由于CDS测试软件本身的问题,自发自收时空口采集的消息不全,而漏掉了寻呼消息导致了统计不准确?
验证方法:寻呼是由MSC发起,在A接口采集信令,与CDS测试软件采集的到寻呼消息对比。4月13日上午10:00-11:00在JNG9下的小区智慧大厦(G01F301)进行200次自发自收短信测试,同时在JNG9 A接口跟踪手机的IMSI,跟踪结果如下:
消息名称 消息数量
A接口 空口
【MM_CMSReq--CM业务请求】 200 200
【RR_PR--寻呼响应】 60 60
可见,并不是测试软件没有采集完整,而是其中有140次A接口并没有下发寻呼指令,该次测试中没有下发寻呼指令而直接下发CP-DATA的比例为70%。
假设2:自发自收测试时设置的两次短信之间的时间间隔一般为3秒或5秒,是否由于该时间设置太短,手机的状态受之前或之后的短信行为影响?
验证方法:将自发自收时两次短信之间的时间间隔分别设置为3秒和1分钟,共进行了48次测试,测试结果如下表:
两次短信间隔时长 平均时延 包含寻呼过程数量 无寻呼过程而直接下发CP-DATA数量 包含寻呼过程比例 无寻呼过程而直接下发CP-DATA比例
3秒 2.5秒 16 32 27.10% 72.90%
1分钟 2.8秒 13 35 33.30% 66.70%
可见,由于1分钟间隔对短信来说足够长,去除个体样本影响,自发自收时设置的两次短信之间的时间间隔大或小对是否下发寻呼请求无影响。
假设3:不同手机终端是否对“是否发送寻呼请求”或其比例有影响?
验证方法:用R520/S888手机采用自发自收的方式,各测试十次,其中R520手机十次MT过程均包含信道释放寻呼立即指配加密模式过程,S888有8次包括,2次不包括而直接下发CP-DATA。R520测试筛选后的主要信令如下图:

 

 

 

 

 

 

 

 

 

 

  
采用R520和S888测试的统计如下:
手机型号 平均时延 测试1 测试2 测试3 测试4 测试5 测试6 测试7 测试8 测试9 测试10
R520 7.05 3.83 3.34 3.58 9.69 8.99 9.42 9.66 9.04 9.2 3.75
S888 3.62 4.49 3.79 4.52 4.93 3.79 4.06 0.71 4.71 4.44 0.71
采用R520进行的10次测试中,MO、MT过程包含完整的信令流程, 而S888手机测试中出现了2个0.71秒的超短时长,对应于没有经过信道释放、寻呼等而直接下发短信内容的过程,但无寻呼出现的比例仅为20%,远低于采用SAGEM290、SAGEM190测试时的情况(70%左右)。
可见,对于自发自收短信时的MT过程,不同的手机终端对 “是否发送寻呼请求”及其比例存在较大影响。
另外,采用R520的10次短信中,第4、5、6、7、8、9次均伴随TMSI Reallocation过程,MT时延基本在9秒以上,事实上TMSI Reallocation耗时并不长,但从上行MO短信发送完毕(channel release消息)到下行MT过程中响应寻呼的channel request消息之间间隔很长,这两个消息间的时间间隔如下表:

MO过程ch_rel时间 测试1 测试2 测试3 测试4 测试5 测试6 测试7 测试8 测试9 测试10
39.28 1.65 22.36 50.15 11.1 31.11 51.37 12.8 31.89 2.53
MT过程ch_req时间 40.68 2.98 23.79 57.24 17.6 38.18 58.5 19.68 38.77 3.9
时间间隔 1.4 1.33 1.43 7.09 6.5 7.07 7.13 6.88 6.88 1.37
可见,R520测试中,这个平均约7秒的时间间隔是导致MT过程大于9秒的原因,可见与手机有关。
三、时延的三个主要环节
汇总前期的测试数据分析,MT短信取路由时间在1秒左右,在MSC侧以下大约需要3-3.5秒,合计为4-4.5秒。下面从无线侧结合A口对各过程时延进行分析,A口一个典型的MT短信流程如下表:
╳ 17:41:29.359 [IMSI=460003184510781] 【RR_PR--寻呼响应】
收 2Mb01 时间=17:41:29.359 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:4
GSM A 接口:<SCCP_UDT---单位数据> <BSSMAP 消息>
BSSMAP_PAG 寻呼
收 2Mb02 时间=17:41:30.672 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_CR---连接请求> <BSSMAP 消息>
BSSMAP_CL3I 完全L3信息 <RR_PR>--<寻呼响应>
发 2Mb01 时间=17:41:30.712 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_CC---连接确认>
发 2Mb01 时间=17:41:30.712 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <BSSMAP 消息>
BSSMAP_CMCmd 加密模式命令
收 2Mb02 时间=17:41:30.912 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <BSSMAP 消息>
BSSMAP_CU CLASSMARK更新
收 2Mb02 时间=17:41:31.351 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <BSSMAP 消息>
BSSMAP_CUComp 加密模式完成
发 2Mb01 时间=17:41:31.374 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <DTAP 消息> <SMS消息>
收 2Mb02 时间=17:41:32.768 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <DTAP 消息> <SMS消息>
收 2Mb02 时间=17:41:33.005 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <DTAP 消息> <SMS消息>
发 2Mb01 时间=17:41:33.048 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <DTAP 消息> <SMS消息>
发 2Mb01 时间=17:41:33.049 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <BSSMAP 消息>
BSSMAP_CCmd 清除命令
收 2Mb02 时间=17:41:33.065 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:13
GSM A 接口:<SCCP_DT1---数据形式1> <BSSMAP 消息>
BSSMAP_CComp 清除完成
发 2Mb01 时间=17:41:33.104 DPC: 0- 1- 3 OPC: 0- 12- 3 SLS:13
GSM A 接口:<SCCP_RLSD---释放连接>
收 2Mb02 时间=17:41:33.119 DPC: 0- 12- 3 OPC: 0- 1- 3 SLS:5
GSM A 接口:<SCCP_RLC---释放完成>

上面举例短信MSC侧以下的时间开销为3.41秒,结合寻址过程的1秒,整体时延为4.5秒左右,与测试结果吻合。通过A口信令分析得知:
(1)收到连接请求(SCCP_CR) 发送SCCP_CC确认消息在20-40毫秒之间,不超过50毫秒,可以忽略。
(2)发送SCCP_CC确认消息发送加密模式命令(BSSMAP_CMCmd)之间基本是同时的,相差不超过1毫秒,可以忽略。
(3)接收到加密模式完成消息(BSSMAP_CUComp)下发短消息一般在30毫秒左右,不超过50毫秒,可以忽略。
为找到主要矛盾,忽略掉上面三个时间段,MSC以下的短信时延主要产生在下面三段:
(1)寻呼过程。对应下发寻呼消息(BSSMAP_PAG)到收到寻呼响应(SCCP_CR连接请求)。
(2)加密模式建立及CLASSMARK UPDATE过程。对应下发加密模式命令(BSSMAP_CMCmd)、收到CLASSMARK UPDATE消息、收到加密模式完成消息(BSSMAP_CUComp)之间的过程。
(3)下发短信至收到回应。A口上对应下发短信和接收到响应的两个DTAP消息,无线口上的对应下行的CP_DATA和上行的CP_ACK消息。
1、寻呼过程
取17:17-17:51共约35分钟的JNBSC7的A接口数据,MSC共收到寻呼响应70577个,以100毫秒为一个时间段划分,关于寻呼响应时长的统计如下表:
0-1秒 时间范围 0-100 100-200 200-300 300-400 400-500 500-600 600-700 700-800 800-900 900-1000
寻呼个数 0 1 10 226 944 2630 4298 5372 6004 7009
比例 0.0000% 0.0014% 0.0142% 0.3202% 1.3377% 3.7268% 6.0904% 7.6123% 8.5079% 9.9320%
归一值 0.00 0.00 0.04 1.12 6.02 20.50 39.59 57.09 72.32 94.35
1-2秒 时间范围 1000-1100 1100-1200 1200-1300 1300-1400 1400-1500 1500-1600 1600-1700 1700-1800 1800-1900 1900-2000
寻呼个数 7676 7307 6188 4706 4023 3432 2675 1828 1390 942
比例 0.1088 0.1035 0.0877 0.0667 0.0570 0.0486 0.0379 0.0259 0.0197 0.0133
归一值 114.21 119.07 109.61 90.03 82.66 75.38 62.54 45.33 36.44 26.03
2-3秒 时间范围 2000-2100 2100-2200 2200-2300 2300-2400 2400-2500 2500-2600 2600-2700 2700-2800 2800-2900 2900-3000
寻呼个数 760 566 446 376 321 273 222 159 151 95
比例 1.0769% 0.8020% 0.6320% 0.5328% 0.4549% 0.3868% 0.3146% 0.2253% 0.2140% 0.1346%
归一值 22.08 17.24 14.22 12.52 11.14 9.86 8.34 6.20 6.10 3.97
3-4秒 时间范围 3000-3100 3100-3200 3200-3300 3300-3400 3400-3500 3500-3600 3600-3700 3700-3800 3800-3900 3900-4000
寻呼个数 75 59 62 48 52 45 35 21 22 15
比例 0.1063% 0.0836% 0.0879% 0.0680% 0.0737% 0.0638% 0.0496% 0.0298% 0.0312% 0.0213%
归一值 3.24 2.63 2.86 2.28 2.54 2.26 1.81 1.12 1.20 0.84
4-5秒 时间范围 4000-4100 4100-4200 4200-4300 4300-4400 4400-4500 4500-4600 4600-4700 4700-4800 4800-4900 4900-5000
寻呼个数 13 11 11 9 7 9 6 8 2 3
比例 0.0184% 0.0156% 0.0156% 0.0128% 0.0099% 0.0128% 0.0085% 0.0113% 0.0028% 0.0043%
归一值 0.75 0.65 0.66 0.55 0.44 0.58 0.40 0.54 0.14 0.21
5-6秒 时间范围 5000-5100 5100-5200 5200-5300 5300-5400 5400-5500 5500-5600 5600-5700 5700-5800 5800-5900 5900-6000
寻呼个数 3 4 7 2 4 5 1 0 0 1
比例 0.0043% 0.0057% 0.0099% 0.0028% 0.0057% 0.0071% 0.0014% 0.0000% 0.0000% 0.0014%
归一值 0.21 0.29 0.52 0.15 0.31 0.39 0.08 0.00 0.00 0.08


将上表数据统计如下:
时间范围 寻呼个数所占比例 归一化寻呼响应时长(毫秒)
0-1秒 37.54% 291.03
1-2秒 56.92% 761.3
2-3秒 4.77% 111.67
3-4秒 0.62% 20.78
4-5秒 0.11% 4.91
5-6秒 0.04% 2.05
合计 1191.7
可见,利用各时间范围寻呼数所占比例*时间范围中间值,然后累加得到的归一值为1191.7毫秒,即JNBSC7中的寻呼响应时长平均约为1.2秒,从A接口信令看,这一时长对应MSC下发BSSMAP_PAG消息到收到RR_PR消息(SCCP_CR连接请求)的时间。
2、加密模式建立及CLASSMARK UPDATE过程
对应下发加密模式命令(BSSMAP_CMCmd)、收到CLASSMARK UPDATE消息、收到加密模式完成消息(BSSMAP_CUComp)之间的过程。
  MT1 MT2 MT3 MT4 MT5 MT6 MT7 MT8 MT9 MT10 平均值
A:下发加密指令 32.628 50.288 39.344 41.927 57.604 42.796 44.395 35.001 34.219 37.93  
B:收到CLASSMARK更新消息 32.868 50.516 39.522 42.088 57.804 42.963 44.572 35.215 34.404 38.077  
A-B时间 0.24 0.228 0.178 0.161 0.2 0.167 0.177 0.214 0.185 0.147 0.19秒
C:加密模式完成 33.293 50.755 39.78 42.531 58.281 43.199 45.07 35.68 34.641 38.56  
A-C时间 0.665 0.467 0.436 0.604 0.677 0.403 0.675 0.679 0.422 0.63 0.57秒
可见,完成加密过程需0.6秒左右的时间。
3、下发短信至接收完毕时长
随机选取A接口上10个接收短信的过程,统计如下表:
  MT1 MT2 MT3 MT4 MT5 MT6 MT7 MT8 MT9 MT10
MSC下发短信的时间 30.956 37.232 39.654 31.374 4.986 13.714 38.601 30.912 30.954 36.791
MSC收到回应的时间 32.317 38.705 41.248 32.768 6.147 15.566 39.287 33.164 32.099 39.373
下发短信长度 42 99 86 42 54 90 2 156 46 161
下发至接收完毕的时长 1.361 1.473 1.594 1.394 1.161 1.852 0.686 2.252 1.145 2.582
上表中MSC下发短信和收到回应的时间省略了分钟和小时,仅保留秒及毫秒,A接口上分别对应MSC下发SMS和收到回应的时间。可见MSC下发短信收到回应的时间与短消息长度密切相关,短消息长度越短,下发至收到回应的时间越短,反之越长。如下图所示:

集团测试使用的短信内容在A口LAYER3的长度约为104,由于JNBSC7在现场测试时因仪表问题未能与A接口对应起来,而JNBSC9测试时Um口和A口相对应,所以,对于JNBSC7选取了长度类似的短信过程,统计上略有偏差。
下发短信至接收完毕时长统计如下表:
MT1 MT2 MT3 MT4 MT5 MT6 MT7 MT8 MT9 MT10
JNBSC9 MSC下发短信的时间 57.188 37.473 13.841 17.653 11.856 2.518 14.355 41.078 43.877 4.277
MSC收到回应的时间 59.28 39.555 15.878 19.753 13.904 4.622 16.415 43.169 45.947 6.344
下发至接收完毕的时长 2.092 2.082 2.037 2.1 2.048 2.104 2.06 2.091 2.07 2.067
JNBSC7 MSC下发短信的时间 13.714 57.319 32.516 31.363 8.664 33.144 33.676 36.18 37.068 45.737
MSC收到回应的时间 15.566 59.147 34.587 33.219 10.63 35.096 35.764 38.018 38.664 47.565
下发至接收完毕的时长 1.852 1.828 2.071 1.856 1.966 1.952 2.088 1.838 1.596 1.828
从A接口口看,对于与测试短信类似长度的短信过程,JNBSC7和JNBSC9从发送短信到收到响应时长平均约为1.89秒和2.07秒。综合看来,这一过程时长在1.9-2秒。
空口接收短信时的信令如下图:
 

从上图看出,MS收到CP_DATA的时间与发送响应的时间一样,可见,MS收到CP_DATA的时间实际上是手机已经完成接收处理后的时间,信息在何时到达手机以及手机接收时的处理时长难以筛选出来。所以,MSC下发短信至收到响应的过程虽然在A口消息上相邻,中间没有别的信令,但从过程上经过很多环节,并涉及到MS、BTS等的处理时长,而且没有严格的区分相应处理时长的消息。
四、主要环节分解
根据上面分析,已将MSC以下的时延定位为三个主要过程中:寻呼过程平均约为1.2秒、加密模式建立过程约为0.5-0.6秒、下发短信至收到回应约为1.9-2秒,合计约为3.6-3.8秒,由于CDS软件是在Um口截取信令计时,而上面第三个阶段包括响应基站BSCMSC的过程,所以,接收短信的计时时长小于1.9-2秒,MSC以下的时长约为3.5-3.7秒。
1、PAGING过程
(1)手机等待寻呼的过程,受寻呼组个数的影响,由于Abis口上PAGING消息下发的时间解不出,等待寻呼的时长从Abis口无法截取。
(2)立即指配-寻呼响应过程,建立MS-BTS间的层2的异步平衡模式(SABM-UM),需耗时0.35秒。
2、加密过程
BTS和MS完成加密过程需0.5-0.6秒,ABIS口和A口时间一致,可见,BSC对该时长的影响可忽略。
3、短信接收过程
(1)ABIS口EST_REQ和EST_CONF之间耗时约0.42秒,用以建立BSC-BTS-MS之间传送短信所需SAPI=3的通道。Um口对应SABM-UM消息。
(2)BSC下发短信、BTS接收和转发、MS接收短信合计约1.1秒。
其它方面
五、几种改进方式的试验和对比
根据上面分析,我们针对上面的主要环节分别进行了改进尝试。主要为
 缩短寻呼响应时长
 寻呼参数的权衡分析
 MFRMS优化设置的测试验证
 分BSC短信测试对比
 减少ABIS口信令
 关闭加密和CALSSMARK早送控制
1、缩短寻呼时长
(1) MFRMS对接续时长的影响
MFRMS 定义了每个PAGING GROUP 重复出现的周期性间隔时长。例如:当MFRMS=1 时,间隔时长为0.2354 秒;MFRMS=2 时,间隔时长为0.4708 秒;MFRMS=6 时,间隔时长为1.4124 秒。由于手机只在对应“寻呼组”的时刻监听网络,因此间隔时长越大,网内的手机将获得更长的待机时间,但是,上述优点的获得是以牺牲寻呼消息在无线信道上的平均时延为代价的,即MFRMS越大使寻呼消息在空间段的时间延迟增大,系统的平均服务性能降低。通过TEMS测试可截取如下的信令图:

上述中B/D过程对应为主、被叫手机与网络间的接续信令交互,主要为鉴权加密,C 所对应的过程为主叫手机向网络发送被叫号码,对方网络通过寻呼与被叫手机取得联络。所以,在已使用选择性鉴权的情况下,缩短C过程是降低接续时长的主要问题。
手机在进入小区后,根据SIM 卡上的IMSI、小区当前的CCCH 配置情况及MFRMS取值,计算出自己应当在哪个PAGING GROUP 上听寻呼消息。另一方面,在基站侧,当一个针对手机的寻呼消息到来时,基站计算出该手机用户驻留在哪个
PAGING GROUP 上,并在该PAGING GROUP 到来时,发送PAGING 消息。
通过TEMS测试发现,当mfrms由5减为3时,可使C过程减小平均约0.3-0.4秒。
(2) 寻呼容量分析
 MFRMS为不同值时容量分析
移动台传送寻呼请求信息。BCCH 的0 隙在逻辑上被分为复帧结构,每个复帧的发送时间为235.4ms。下面,我们计算当BCCH采用不同的配置时,一秒钟最多可以发送的寻呼块的数量。现网所有小区为非组合BCCH/SDCCH 的小区,AGBLK=1。
每秒可发送的寻呼块数为:8/0.2354=33.98 pagingblock/second,YY现网中一次寻呼均采用TMSI,二次寻呼采用IMSI,假设二次寻呼比例为X,则每个寻呼块可以容纳的寻呼尝试为:4/(1+2*X)。对应现网中的典型配置,每个复帧上有8 个寻呼块,可以得到理论上现网BTS 最大的寻呼容量为:
[4/(1+2*X)]*8/0.2354PA/second,相应每秒可发送的寻呼指令数为
[4/(1+2*X)]*8/0.2354*(1+X)paging command/second,每小时可发送的寻呼指令数为 [4/(1+2*X)]*8/0.2354*(1+X)*3600 pagingcommand/hour,由上面分析可见,理论上BTS每秒可发送的寻呼容量与MFRMS无关,只是相当于寻呼消息被缓冲。
 现网实际寻呼负荷分析
第一次寻呼次数: PAGE1=NPAG1LOTOT + NPAG1GLTOT
第二次寻呼次数: PAGE2=NPAG2LOTOT + NPAG2GLTOT
现网中一个小时发出的寻呼总次数:PAGETOL=PAGE1+PAGE2,取YY现网统计(11月7日晚忙时),代入上面公式,如下表:
网元 第一次寻呼次数 第二次寻呼次数 总寻呼次数 二次寻呼比例(X) 设计容量 寻呼负荷
JNG1 110619 4590 115209 4.15% 470630 24.5%
JNG2 76196 4296 80492 5.64% 464584 17.3%
JNG3 109534 5209 114743 4.76% 468128 24.5%
JNG4 88770 4638 93408 5.22% 466230 20.0%
JNG5 112566 4346 116912 3.86% 471840 24.8%
JNG6 180820 11633 192453 6.43% 461485 41.7%
JNG7 161219 7686 168905 4.77% 468080 36.1%
JNG8 143340 7375 150715 5.15% 466550 32.3%
JNG9 169533 8697 178230 5.13% 466611 38.2%
JNG10 60138 2789 62927 4.64% 468610 13.4%
JNG11 142749 9600 152349 6.73% 460370 33.1%

可见,JNG6忙时寻呼负荷偏高,覆盖市区的网元JNG1、JNG3、JNG4、JNG5、JNG10寻呼负荷都在25%以下。另外,统计显示,JNBSC1小区 MFRMS修改为2后忙时寻呼成功率没有变化。
(3)测试结论
由于MFRMS的修改并不会减小“理论上”的寻呼容量,而且可以将寻呼消息尽快下发出去,所以,对于开启TMSI寻呼、且目前寻呼负荷较低的市区网元(JNG1、JNG3、JNG4、JNG5、JNG10)可以将MFRMS缩短,从而可减小短信(MT)时长,从而提升网络的服务性能。
经过试验性修改MFRMS参数,由原来的5调整到3,短信时延约缩短了0.4秒。修改后利用CDS软件进行了验证,经过四轮(每轮测试20次点对点)测试,短信平均时延分别是:4.2 4.3 4.2 4.1 秒。总的来说比原来可降低0.4秒左右。
1、 寻呼参数的权衡分析
通话A接口跟踪寻呼消息在时间上的分布规律,以一桢(0.235s)为时间单位计算出标准偏差的变化,这样做的主要目的是分析当突发话务时突发的“时间粒度”,如在每0.235s的时间范围内寻呼数是比较均匀的(如标准差低于某一设定值),那么,MFRMS修改为1也是可行的;如在每0.47s的时间范围内寻呼数是比较均匀的,那么MFRMS修改为2是可行的。
另外,提升该值的必需在AGCH和PCH不过载的情况下(合理设置BS_AG_BLK),尽量减小MFR( Number Of Multiframes Between Paging)的设置,即监听所属寻呼子信道的时间间隔尽量减少,以提升整体的响应时间。以JNBSC3为例进行分析。
 BS_AG_BLK&MFR的设置是否满足最忙时接入请求和寻呼次数
因为现阶段JNBSC3下各个小区为BCCH/SDCCH非combined的组合方式,LAC=21265下小区的BS_AG_BLK一般设置为1,按照该设置每小时sd的最大请求次数(Immediate Assignment)为:3600/0.235=15319(次)。按照该设置应该可以满足最忙时最忙小区的sd请求次数,虽然极个别小区忙时sd请求次数大于该值,由于爱立信在AGCH负荷不足时,优先占用PCH的机制,从实际接入成功率上看该设置还是合理的。
根据BSC3忙时统计(17:00:00-18:00:00),寻呼次数为151141;由于现阶段YY的寻呼方式为IMSI呼损,所以Paging Request可以携带两个用户的寻呼信息,所以按照该设置每小时最大寻呼用户数(IMSI)为:(3600/0.235)*8*2=245106次>151141;151141/245106=61.66%。所以从整体上看BS_AG_BLK一般设置为1,也可以满足最忙时的寻呼次数。
其次我们进一步查看更短时间间隔下网络容量,即从每秒寻呼容量是否满足网络实际寻呼尝试。(跟踪时段并非最忙时,以下数据仅从思路上进行解释)因此我们截取BSC3跟踪时段(11:00:00-11:10:00)做以秒为单位的量化如下:

可以看到统计阶段最大寻呼量为50次/秒。
按照现网设置,寻呼的用户数=(8/0.235)*2=68.08次/秒>50次/秒;
所以从单位时间上看现阶段的设置是可以满足,网络寻呼和SD指配要求的。
 从寻呼子信道出发查看每个寻呼信道的承载能力
为了查看每个寻呼子信道的承载能力,我们进一步查看每个寻呼子信的每秒承载用户的容量。所跟踪信令还以上面(11:00:00-11:10:00)数据为例。按照现网设置MFR=3,而且寻呼方式为IMSI寻呼,所以现阶段每秒每个寻呼子信承载最大用户数应该小于以下结果:(1/0.705)*2=2.83(个/秒)
假如每个Paging _request下发后都可以立即响应,即没有针对某个IMSI重复的Paging _request 。所以2.83(个/秒)应该为一个理论值,实际容量应小于2.83。
以下举例寻呼寻呼子信道寻呼量分布(单位:次/秒):

可以看到寻呼子信道10的平均尝试为1.883次/秒(最大值)<2.83,占子信道容量的66.54%,所以整体上看是现阶段JNBSC3的BS_AG_BLK和MFR设置还是可以满足网络的寻呼,接入需求的。
 寻呼参数的权衡
综上,寻呼时延应该是在AGCH和PCH不过载的情况下,去追求的指标项。盲目的减小MFRMS虽然会对部分寻呼的时间有明显提升,但是对其余被叫寻呼则由于寻呼子信道用户容量的增大,而导致部分寻呼消息由于溢出延时发送,甚至寻呼消息的丢失。反而会造成寻呼成功率,寻呼时延整体下降。通过对JNBSC寻呼参数的核查,JNBSC3整体情况如下:
►最忙时最大寻呼数为:151141,占系统理论最大容量的比例:151141/245106=61.66%;
►信令跟踪时段最大寻呼用户为50次/秒,占系统理论最大容量的比例:50/68.08=83.22%;
►单一寻呼子信道平均最大占用为1.883次/秒,占单一寻呼子信道每秒承载最大用户的比例1.883/2.83=66.54%。
上述都是与理论值的对比,因此在实际计算时应该考虑保留一定的冗余25%左右(需要更加详细的理论模型),我们认为从寻呼时间上考虑BS_AG_BLK和MFR设置为1,3;参数设置已经为最小设置,该BSC的寻呼成功率可以达到96.7%以上,属于优秀值,权衡寻呼时长和寻呼成功率,我MFRMS设置为3已是最小值。
2、 MFRMS优化设置的测试验证
上面已以JNBSC3为例进行了理论分析和测试,继续修改为2是不是如理论上的推断呢?当某一BSC内该参数设置不一致有什么影响呢?为了验证这两个问题,将该参数的最优设置值浮出水面,我们进行了如下测试:
测试选用集团组巡的CDS测试软件,完全依照集团组巡的标准。总体测试结果如下:
测试类别 SMS发送尝试次数 SMS点到点成功次数 SMS点到点成功率 SMS点到点平均时间
汇总 140 140 100.0% 3.9
MFRMS=3 50 50 100.0% 3.5
MFRMS=2(周边小区设置为3) 40 40 100.0% 4.8
MFRMS=2(周边小区设置为2) 50 50 100.0% 3.7
详细的测试数据如下表:
测试序号 mfrms=3 mfrms(only) mfrms(all)
1 1.49 5.59 1.49
2 1.99 0.59 10.19
3 6.49 9.39 1.39
4 1.09 8.99 5.79
5 1.59 10.69 10.19
6 2.19 0.89 6.39
7 1.29 5.69 1.29
8 6.29 1.59 1.39
9 1.49 6.39 1.99
10 1.09 1.99 1.19
11 1.49 0.99 6.49
12 5.99 6.49 1.49
13 1.29 1.79 1.99
14 6.69 1.69 1.09
15 1.09 1.19 2.29
16 0.89 10.09 4.79
17 2.19 10.09 5.99
18 6.09 9.29 0.59
19 1.89 1.69 1.39
20 6.89 1.19 0.89
21 0.99 5.39 5.49
22 6.09 1.29 2.09
23 5.29 9.89 1.89
24 1.29 1.39 1.19
25 6.09 2.09 10.19
26 2.29 1.19 5.39
27 5.29 5.19 0.99
28 6.19 4.49 1.49
29 1.09 6.99 2.19
30 5.79 6.59 0.99
31 2.19 0.79 2.19
32 1.09 1.49 1.29
33 6.19 10.39 0.89
34 5.19 1.19 0.69
35 5.19 9.39 1.59
36 6.99 1.19 6.29
37 1.09 10.09 4.49
38 2.19 0.99 4.49
39 4.99 6.09 1.99
40 1.29 10.29 9.69
41 5.19 1.99
42 5.19 5.19
43 5.49 0.99
44 1.29 6.19
45 5.99 2.39
46 7.29 9.49
47 1.39 5.49
48 1.99 1.99
49 1.09 5.99
50 1.49 9.89
为了较为清晰的展现各次所测时延值,忽略各数值产生的时间顺序,按时间长短排序后形成如下图表:

由上图和数据详表对比,可以看到下面几点不同,并得出下面几点结论:
1、 当MFRMS修改为3时,MT短信时延低于1秒的为2次,而MFRMS=2(ONLY)为5次,MFRMS=2(ALL)为7次。
结论1:当MFRMS设置越小,手机等待寻呼的时间越短,“超短时延”出现的概率越大,与理论上相符。
2、 当MFRMS修改为3时,MT短信时延高于7秒的为1次,而MFRMS=2(ONLY)为11次,MFRMS=2(ALL)为6次。其中大于10秒的MFRMS=3为0次,MFRMS=2(ONLY)为6次,MFRMS=2(ALL)为3次。
结论2:当MFRMS设置越小,二次寻呼出现次数较多(一次寻呼等待为7秒左右,推断为此原因,还有待根据信令流程验证),“超长时延”出现概率越大;
3、 MFRMS=为2时,当与周边小区不一致时平均时延为4.8秒,而相同时则为3.7秒。
结论3:当服务小区与周边小区设置不一致时,服务小区改变时手机归属寻呼组需重新计算,影响接续时延甚至成功率。建议同一BSC内该参数设置一致。
汇总结论:从测试结果看,当MFRMS进一步修改为2时,虽然理论上会缩小接续时延,但“超长时延”增加带来的负面影响要大于“超短时延”增加带来的有利影响,均衡看来,MFRMS设置为3较为恰当。另外,测试的服务小区应与周边小区MFRMS参数尽量设置一致。
4、 分BSC短信测试对比
选择覆盖市区的共11个BSC,每个BSC进行50次短信测试,短信成功率为100%,各个BSC平均接收时间在4.0-4.3,测试结果与前期关于短信时延的分析结果一致,并且各个BSC非常平均,如下表:

地点编号 地点名称 SMS发送尝试次数 SMS点到点成功次数 SMS点到点成功率 SMS点到点平均时间
总合结果: 550 550 100.0% 4.1
1 JNBSC1.log 50 50 100.0% 4.1
2 JNBSC3.log 50 50 100.0% 4.0
3 JNBSC4.log 50 50 100.0% 4.3
4 JNBSC5.log 50 50 100.0% 4.3
5 JNBSC7.log 50 50 100.0% 4.2
6 JNBSC8.log 50 50 100.0% 4.1
7 JNBSC9.log 50 50 100.0% 4.2
8 JNBS10A.log 50 50 100.0% 4.3
9 JNBS10B.log 50 50 100.0% 4.0
10 JNBS11A.log 50 50 100.0% 4.0
11 JNBSC12.log 50 50 100.0% 4.0
上述覆盖市区的11个BSC中选择的测试小区基本都是主覆盖小区,小区重选不超过1次,并且信号强度均在-70dBm以上,ECSC均打开,MFRMS均设置为3,如下表:
网元 小区 BCCH/BSIC RXLEV ECSC MFRMS
JNBSC1 G010084 D010083 10\53 525\65 -60.78 YES 3
JNBSC3 G016821 5\67 -66.15 YES 3
JNBSC4 G018482 83\75 -59.74 YES 3
JNBSC5 G010701 77\42 -59.24 YES 3
JNBSC7 G017003 73\77 -60.55 YES 3
JNBSC8 G016561 G018612 78\65 71\45 -64.94 YES 3
JNBSC9 G010033 G019181 93\44 72\44 -65.55 YES 3
JNBS10A G01F111 G018411 5\45 72\56 -68.66 YES 3
JNBS10B G019121 G017383 72\76 88\73 -62.43 YES 3
JNBS11A G010742 84\61 -55.15 YES 3
JNBSC12 G018623 94\61 -53.73 YES 3
另外,对八一22楼微蜂窝在关闭和打开早送控制ECSC的情况下分别进行了短信测试,ECSC关闭时较打开时缩短了0.3秒,如下表:
地点编号 地点名称 SMS发送尝试次数 SMS点到点成功次数 SMS点到点成功率 SMS点到点平均时间
1 22楼-打开ECSC 50 50 100.0% 4.3
2 22楼-关闭ECSC 50 50 100.0% 4.0
50次测试的时长对比如下图:

如去掉上面两次10秒以上的短信,ECSC开启和关闭时的短信时长分别为4.02和4.00,两者基本相同,可见,ECSC是否开启对接收短信的时延影响很小。
1、10.88秒

 

 

 

 

 

 

 

 

 

 

 


第一次指配成功后,上发PAGING REPONSE中为 TMSI,系统无响应,等待计时器超时后第二次指配才成功,此时PAGING RESPONSE中上发的为IMSI,导致时延增加了6秒。
2、11.69秒
第二次情况与第一次类似,另外多了一次小区重选过程,两次均伴随着TMSI重分配过程。
所以,从两次较长的时延来看,怀疑手机中存储的TMSI与系统中的不一致,导致寻呼响应中携带的TMSI系统不识别,或者手机不响应寻呼,而后通过寻呼响应携带IMSI或采用IMSI寻呼,从而增加了时延。另外,接收过程中的小区重选会增加时延。
由于上面测试出现了两次比较特殊的情况,为了验证是否是必然出现的,与9月12日下午再次进行了测试,结果如下:

在第二次测试中,没有出现超长时延短信的情况。
汇总结论:
(1) 通过测试结果看,关闭与开启ECSC对时延影响不是很大。
(2) TMSI不一致或非法带来的二次寻呼对时延影响较大,出现的概率较小,当ECSC开启时总共100次测试中出现了2次;
(3) 接收短信时如存在小区重选会增加时延。
(4) 通过对JNBSC10A测试情况看,开启TMSI寻呼的情况下,对于短信而言仍然是选择性鉴权。
(5) 市区内各BSC短信时延大致相当,在4.0-4.3秒左右,市区平均4.1秒。
5、 减少ABIS口信令
ABIS接收短信的流程如下图:

根据信令流程,可减少的仅为SDCCH信道的功率控制过程,但经过测对比,关闭了SDCCH功率控制后,虽然减少了A-bis口信令,但从测试结果看,对减少时延没有帮助。
1、 关闭加密和CLASSMARK早送控制
(1)关闭加密参数
为进一步降低短信MT时延,按照省公司安排,YY公司对鉴权、选择性鉴权、加密不同情况下的短信接收进行了测试。测试验证主要包括两个过程:
 关闭鉴权和加密参数
>!close AUTHENTICATE
>dbtri;
>dbtsp:tab=axepars,name=AUTHENTICATE;
>dbtsc:tab=axepars,name=AUTHENTICATE,value=0,setname=GSMMMSC;
>dbtre:com;
>
>!close cipher
>mgepp:id=cipher;
>mgepc:prop=cipher-0;
经测试,空口仍然有加密过程存在,时延没有缩短。
 关闭鉴权和加密,同时将IMEIFETCHCIPH设置为0
IMEIFETCHCIPH参数确定了在加密过程中是否用于获取IMEI。经测试,将该参数设置为0后,空口仍然有加密过程存在,时延没有缩短。
我们利用TEMS520进行测试,并根据层三信令统计时延,测试前我们同惠捷朗公司进行沟通,确认了CDS短信MT时延计时起始信令,如下图:

 

 

 

 

 

 

 

CDS软件是利用发送手机的上行发送CP_ACK消息为计时起点,接受手机受到下行CP_DATE消息为计时结束,按照CDS软件的计时方法,我们利用TEMS520对对鉴权、选择性鉴权。加密三种模式下短信接受情况进行了计时统计,由于CDS计时统计中不考虑发送手机信令过程,我们在测试中重点对接受手机信令流程进行对比。
(A)鉴权
1、测试结果
次数 发送时间 接收时间 时延
1 31:10.0 31:19.9 9.9
2 31:42.2 31:47.0 4.7
3 32:11.4 32:21.6 10.1
4 32:41.1 32:45.3 4.2
5 33:07.0 33:07.5 0.5
6 33:40.4 33:50.6 10.1
7 34:08.4 34:18.1 9.7
8 34:39.5 34:44.0 4.5
9 35:11.8 35:16.3 4.5
10 35:45.7 35:46.2 0.5
平均 33:25.8 33:31.6 5.87
2、接受手机信令流程

(B)选择性鉴权
1、测试结果
次数 发送时间 接收时间 时延
1 54:44.5 54:48.2 3.7
2 55:19.1 55:19.5 0.5
3 55:47.1 55:56.8 9.7
4 56:13.7 56:22.9 9.2
5 56:40.3 56:49.8 9.4
6 57:05.8 57:06.2 0.5
7 57:33.8 57:37.3 3.6
8 57:57.8 58:07.4 9.6
9 58:21.8 58:31.5 9.6
10 58:57.4 59:06.8 9.4
平均 56:52.1 56:58.6 6.52
2、接受手机信令流程

(C)加密
1、测试结果
次数 发送时间 接收时间 时延
1 21:47.4 21:51.4 4
2 22:19.7 22:23.2 3.5
3 22:57.1 23:01.1 4
4 23:31.3 23:35.0 3.7
5 23:59.8 24:03.6 3.8
6 24:28.7 24:37.7 8.9
7 24:54.8 25:04.7 9.9
8 25:25.7 25:35.1 9.4
9 25:51.1 26:00.6 9.4
10 26:36.3 26:45.5 9.2
平均 24:11.2 24:17.8 6.58
2、接受手机信令流程

(D)鉴权与加密均关闭
1、测试结果
次数 发送时间 接收时间 时延
1 10:24.9 10:34.4 9.4
2 10:47.3 10:56.9 9.7
3 11:11.6 11:12.0 0.5
4 11:43.8 11:53.5 9.6
5 12:15.1 12:18.9 3.7
6 12:48.3 12:58.5 10.1
7 13:17.0 13:20.6 3.6
8 13:57.8 14:06.7 9
9 14:33.8 14:43.7 9.9
10 15:15.5 15:15.9 0.5
平均     6.6

 

2、接受手机信令流程

可见,两种方式均关闭后,测试发现仍然有加密过程出现,导致时延没有降低。

 

 


(2)关闭早送控制ECSC

上述CLASSMARK UPDATE占用0.3秒的时间,将classmark信息更新过程由早发模式改为晚发,即将ECSC参数设置为NO,修改后手机上发的CLASSMARK过程被省略掉了,短信时延缩短0.2-0.3秒,但无法实现向1800小区的切换,所以,在双频网中该功能应该打开,无法通过关闭该功能降低接收时延。
取得效果:
通过A接口信令监测、无线测试对短信时延的各个环节进行了详细分析,并进行了缩短寻呼响应时长、寻呼参数的权衡分析、MFRMS优化设置的测试验证、分BSC短信测试对比、减少ABIS口信令、关闭加密和CALSSMARK早送控制等各项优化试验,确定了最佳参数设置,使得时延有效降低。

发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。

日历

Search

热评文章

最新评论及回复

最近发表

Powered By Z-Blog & LeafFly

* ©leafFly.com.浙ICP备08102798号
本站采用创作共用版权协议, 要求署名、非商业用途和保持一致.回顶部