信令跟踪案例分析解读
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
四平Abis 口信令跟踪案例分析
目录
一、概述:........................................................................................................................................ (2)
二、信令分析工作的基本流程: (2)
三、信令分析软件简介: (5)
3.1 DAFNE软件输出文件介绍: (5)
3.2 Opt软件功能简介: (8)
四、前台数据采集操作流程: (9)
4.1小区各载频对应的RSL 时隙配置: (9)
4.2 K1205上的配置过程: (15)
五、四平信令跟踪案例分析: (16)
5.1民政局1小区
(17219_6211): (1)
6
5.2公主岭3小区:.......................................................................................................................................
20
5.3木材厂1
(17217_2051):.................................................................................................................. . (22)
5.4 郭家店2小区
(17220_3112) (27)
六小结:........................................................................................................................................ .. (31)
七附录:........................................................................................................................................ .. (32)
一、概述:
利用信令跟踪分析处理问题小区是网络优化的基本手段。
通过跟踪分析Abis 接口信令数据,对现网中存在的隐性硬件故障、传输问题、频点干扰、越区覆盖、网外强干扰等进行定位,并根据现场情况作出合理的结论。
下面,我将从信令分析工作的基本流程、后台分析软件的使用、前台信令跟踪流程等几个方面对信令跟踪工作做以讲解,最后,结合一些我们四平优化中的案例,阐述一下自己的分析过程以及解决后的效果,望给信令分析工作的朋友一些借鉴。
二、信令分析工作的基本流程:
1. 通过分析话务报告,查找存在掉话多、分配失败率高、切换成功率低、干扰等级偏高等
问题的小区;或者根据OMC-R 、路测、RNP 等各组的要求,确定需要跟踪分析的小区。
2. 利用K1205 Protocol-Tester信令跟踪仪器,跟踪收集Abis(BTS-BSC接口信令数据。
3. 利用DAFNE 、OPTIMIZA TION(Abis等后台分析软件处理上述数据文件。
4. 首先分析.Bil 文件,整体分析一下小区各载频的工作情况,比如:TCH 平均占用时长、链
路损耗、上下行质量等指标情况。
如果指标明显异常,则需结合OPT 软件做进一步细致分析,看小区整体的覆盖电平、通话质量情况,TA 情况,由于问题的出现往往集中在某个载频上,或者某几个载频上。
因此,还需通过Opt 软件对每个载频的覆盖电平、通话质量情况,TA 等指标做分析,以锁定问题原因。
5. 根据以上处理结果(必要时需直接阅读信令流程,过滤相关信息,帮助定位问题),得出
分析结论,与相关小组会商,提出解决建议。
6. 在做出相应调整后,再次做信令分析,评估调整效果并及时反馈、或通过对问题小区的
话务报告做统计分析,评估问题指标改善情况。
图1、信令分析工作基本流程图
三、信令分析软件简介:
信令跟踪工作,前台使用K1205对Abis 口相关小区的信令做数据采集,后台我们使用DAFNE 和OPT 做处理分析。
3.1 DAFNE软件输出文件介绍:
K1205采集的数据格式为:“.rf5”文件,需先使用软件“
RecFileConverter
图3、DAFNE 输出文件规类
DAFNE 输出文件:
1 “res ”文件:对每个呼叫过程进行的测量,主要包含:呼叫类型、时间、所在载频、频
点号、信道类型、BTS 和手机的发射功率、TA 、手机的接收电平、6个邻区的接收电平评估。
2 “ptc ”文件:记述每一个呼叫Abis 口的信令流程。
并包括时间、消息类型、收发方向、信
道类型。
另外,在“Others ”项里,会对于一些关键信令里的重要内容简单陈述,这些信令主要包括:CHNA V 、HOCMD 。
3 “inX ”文件:该文件里记述了,干扰的门限、弱覆盖门限(DAFNE 内设置的),并统计了报
告里超过门限值的信令消息。
如下图:
图4 “inX ”文件内容
4 “siX ”:干扰扰和坏覆盖的一些统计。
内容包括:Interference 和Bad Coverage 定义的门限
值,“inX ”“siX ”其中的“X ”代表的是第几块载频,它的最大值能体现小区真正的载频数;
5 “poX ”:统计一些主要信令消息的比例,从中可以看到一些主要过程的成功或失败的比例,
例如:切出,切入失败的比例等等。
▲说明:其中的“X ”代表的是第几块载频,它的最大值并不能体现该小区真正的载频数,它的
大小是在用DAFNE 处理数据前,由操作者设置的载频数决定的,如果设置的数值大于跟踪小区实际拥有的载频量,那么相关的“poX ”文件里数据就是空的。
图5 DAFNE 处理数据前的BTS 载频数及想关信息配置图
6 “Bil ”:主要是功率预算,上下行路径损耗计算;功率的预算中具体包括:上下行的接收
电平情况,手机和BTS 的发射功率情况,载频占用次数,占用时长等。
7 “diX ”:上下行电平、质量的分布。
8 “hoX ”切换门限的评估。
9 “trc&bit”:测量结果&功率预算。
10 “ptt ”:协议消息。
3.2 Opt软件功能简介:
1 Tek Optimization的功能与DAFNE 类似,可直接处理.rf5文件
2 支持对8载频以上或RSL 和OML 复用的小区进行分析(Dafne 不支持)
3 以图形方式输出处理结果,清晰、直观、利于引用。
4 提供时隙级的分析,可更准确的反映问题原因。
5 可以滤出各个完整的话务流程,并根据设定的条件加以筛选,便于查找、分析▲注意:但由于该软件是试用版(memo,所以不能详细的输出功能。
四、前台数据采集操作流程:
ABIS 接口即BTS 与BSC 接口,它以LapD(GSMLayer2_08.56协议传送信息。
无线系统需不断对周围信号环境进行测试调整,以维持系统的动态平衡。
BTS 将其发射功率和接收电平在ABIS 的 RSL ( radio signal link ,GSM Layer 3_08.58 中传给BSC ,同时,该RSL 也承载DTAP 消息,如手机每半秒将其接收电平及本身的发射功率,相邻小区接收电平等信息的测量报告,这些测量报告的大量收集及统计分析为我们详细描述了各小区各频点的无线状况
Abis 接口以小区为最小单位配置信令传输时隙,首先要在OMC-R 上查找CELL 的Abis 配置(RSL 时隙配置),然后在信令仪上做相应的设置以便接收信令数据文件。
4.1小区各载频对应的RSL 时隙配置:
1 在“RNUSM ”中,选中需跟踪的小区(如图6、7)。
右键选择“Show Equipment”,在出来的
对话框里(如图8),点击USD →USD Cell Overview,进入界面后选中跟踪小区, 点击“Cell Report ”(如图9);,在出现的对话框里,可以看到TRX ID 和RSL 的对应关系(如图10)。
图6 OMCR界面菜单
图7 RNSUM界面
图8 BSSUM界面
图9 USD Cell Overview界面
2 在HW Equipmeng,选中需看的小区。
右键点击选择“Navigate to Abis view”,可以查到小
区所在的Abis 端口(如图11),然后根据TP 号,查到相应的DDF 架位置
(对应关系表由局方提供)。
15 右键点击小区,选择“Display TS Allocation ”,就可以查看TRE 所在2M 链路32时隙中
的哪个时隙传输了(如图12)。
图12 Abis TS Allocation Pannel界面
▲注意:在跟踪前要确保小区是关闭跳频的的。
4.2 K1205上的配置过程:
以上面的工交干校1小区跟踪为例,通过4.1的流程,查到Abis TP口为27;时隙为第 27时隙的0、1、2子时隙。
然后,数据连接线的串口接PRIMO board (数据采集板)的串口,另一端的接口接DDF 架上与TP27口对应的端口。
连接后,PRIMO board 上的连线指示灯是不会亮的,只有在配置完接口后才会亮灯
配置的基本流程如下: 2 进入K1205,在Online Scenario中增加Online Recording、Online Monitoring监视窗口。
3 点击进入Src (Configured窗口中选择哪
个Scenario 板的哪个端口,及哪种协议和时隙。
4 由于进行ABIS 口跟踪,所以选择c:\k1205\stack\gsm2p\gsm2p_abis+.stk协议。
5
选择27时隙的时候,由于RSL 进行了复用,则BIT RATE 应选择
16KBITS/S,SUBSLOT 中选择相应的时隙(0、1、2),
▲注意:对于OML 与RSL 复用的情况,后台处理中不能在使用DAFNE 软件分析,可以使用Tektronix 公司
的OPT 软件进行分析。
6 操作完毕后在Monitor 窗口中看每个端口每个时隙是否有数据进入,并查找SYSINF5 消息中的LAC CI等小区标识是否与所要跟踪的小区相同(点击图13B 处的“OFF ”框)。
7 最后,对本次跟踪的记录文件大小设置一个上限,一般每个载频设置
2M~3M。
点击(如图13)Recoding file 图标上的OPEN 。
在里面根据载频数设置一个文件大小。
最后,点击图3中A 处的“OFF ”框,数据就开始录入了。
图13
五、四平信令跟踪案例分析:
5.1民政局1小区(17219_6211):
现象描述:从历史话务报告可以看出746B 分配失败较多,导致TCH 分配失败率较高
跟踪分析:从信令跟踪整体上看,除了53频点下行质量较差外,其他频点的上下行质量尚可,
在开启跳频的条件下,小区的通话质量应相对可以。
观察53号载频,发现其上
下行路径损耗也相对偏大,如下表:频点上行电平下行电平上行质量下行质量上行路径损耗下行路径损耗路径损耗差质量差手机发射功率
基站发射功率采样数试呼数 51-83.59-78.050.550.6113.99121.05-7.06-
0.0530.443671120958-78.75-76.960.690.64107.1119.96-12.870.0528.3443842029415-77.5-79.1400108.86122.14-13.27031.364322253-83.77-79.660.30.88114.11122.66-8.55-0.5830.354310266117-82.17-74.650.510.57111.99117.65-5.66-0.0629.8243583717779-80.4-71.510.30.26109.31114.51-5.210.0428.9143512178 通过提取分析TCH 分配失败的CALL 流程,我们发现民政局1小区覆盖范围很远,如下图14,在TA =6~12的范围内,尚分布一定比例的话务,而此范围的覆盖电平和质量已经很差,如图15、16。
图
14 Counter of Measurement By TA
图15 Rxlev by TA
图16 RxQual by TA
我们对所有的TCH 分配失败事件进行细致的分析发现,TCH 分配失败的事件,大都发生在TA>6的距离上,而且此时的接收电平己很差,在-90db 以下,而且TCH 分配频繁失败,下图是一次TCH 分配失败事件发生过程,每一时间点的电平情况:
图17 一次TCH 分配失败事件电平情况分布图
图18 民政局1小区的切换情况
由此,我们认为TCH 分配失败次数偏多,是由于民政局1小区覆盖过远所致。
通过使用OPT 软件对每一块载频的Rxlev by TA;RxQual by TA分析得到一个规律:凡是带有SDCCH 信道的载频,在TA>6的距离里的采样点,要比不带SDCCH 信道的载频多很多;由此分析①民政局1小区有CRO ;②该小区在TA>6的距离里,周边小区的接收电平情况要稍好于本小区。
此外,通过EasyRNP 观察其与周边小区的位置情况(如图5):根据周边小区的的切换情况及向局方了解,图18中空旷区域可以由舒家2小区、红旗3小区来覆盖。
调整建议:①降低民政局1小区的功率4dB ,适当减小民政局1的覆盖范围;②调整民政局
1小区CRO :8→6(由于该CRO 的设置是为了吸收双辽市区的话务,因此不
易降过低)。
调整效果:调整后,立刻观察下一小时报告,MC746B 次数明显减少。
图19是调整前后,
MC746B 计数走势图:
图19 MC746B 计数走势图
5.2公主岭3小区(17218_4013:
现象描述:话务报告显示该小区65频点所在载频TCH 占用时长相对较短。
分析:如图20,TRX4载频平均占用时长偏短在11秒以下,从MC370看该载频被占用的次数很高,但从小区的TCH 掉话次数来看,并不高,由于TCH 占用时长很短,因此怀疑在占用到该载频上的信道后,又迅速的切换到别的小区上,由MC712计数来看,该载频的切
出次数非常高,占约占整个小区切出次数的1/5.切出成功率为87.8%,通过OPT 处理分析信令跟踪数据,发现当给手机分配的TCH 信道占到该载频上,下行信号电平立刻会变得很差,图21为一次事件TCH 分配失败过程中,各时间点的电平情况。
图20 5月11日10~11点小区各载频使用信息
图21该载频某一切换失败事件各时间点的电平情况
处理:建议更换TRX4所在的载频。
调整效果:更换载频后,TCH 占用时长恢复正常,MC746b 次数明显下降,如图22所示
图22 MC746B计数走势图
5.3木材厂1(17217_2051):
现象描述:从历史话务报告可以看出746B 分配失败较多,导致TCH 分配失败率较高,并伴
随10次以上的MC736掉话。
跟踪分析:木材厂1小区(17217_2051)从下表看出,除了311号频点外,其他频点的电平、质量都尚属可以。
该频点上下行电平相对其他频点也偏低。
频点上行电平下行电平上行质量下行质量上行路径损耗下行路径损耗路径损耗差质量差手机发射功率基站发射功率
采样数试呼数 74-84.41-79.790.510.64115.51122.79-7.28-0.1331.1437848728-82.32-77.860.690.73111.26119.15-7.89-0.0428.9441.291005119760-81.44-
76.50.320.18108.98117.19-8.20.1427.5440.691091612231-83.12-
80.171.160.88113.48121.94-8.460.2830.3641.5817813239-79.39-
73.90.360.33106.69114.57-7.880.0327.340.6617772718-78.52-72.6800107.52114.58-7.0602941.9311 观察每个频点的Rxlev by TA、RxQual by TA、Count Measurement
by TA图,我们发现只有74号频点、31号频点在TA=6~9的范围内有一定比重的采样点,而相应的电平质量也已相当差,如下各图:
图23 频点74号RxQual by TA
图24 频点74号RxLev by TA
图25 频点31号RxQual by TA
图26 频点31号RxLev by TA
图27 频点60、7的RxLev by TA
通过观察发现,74号、31号频点都有SDCCH 信道。
而其他三个频点只有TCH 信道。
由上面的现象,分析认为在木材厂信号弱区域仍可以重选到该小区,而在占用上SDCCH 信道后,信号确变弱,在分配成功TCH 信道后,由于信号不好,立刻切换至其它小区。
由于全网都没有开SDCCH 信道切换,因此怀疑该小区设置了CRO ,通过核查,果然木材厂1 CRO=5。
调整建议:木材厂1小区, CRO 由5改为0。
复跟结果:调整木材厂一小区的CRO 复跟后,原31号频点由于存在干扰,已更改频点为
1004,原74号频点的RxLev by TA、RxQual by TA图如下:
图28 频点74号的RxLev by TA、RxQual by TA图
由上图,很明显在TA=6~9的范围内,已经基本没有采样点了,达到预期效果,从话务指标上来看,该小区的掉话次数有一定下降,控制在10次以下,如下图所示:
图29 MC746B计数走势图
图30 TCH掉话次数走势图
5.4 郭家店2小区(17220_3112)
现象描述:从历史话务报告可以看出该小区MC746较高,导致TCH 分配失败较高。
并伴随
20次左右的MC736、MC621掉话。
跟踪分析:跟踪发现,第58号频点,上下行电平相对其他频点偏低,通话质量也较差。
此外,
如下表所示,有四个频点的下行损耗明显偏高。
频点上行电平下行电平上行质量下行质量上行路径损耗下行路径损耗路径损耗差质量差手机发射功率基站发射功率
采样数试呼数 38 -78.62-75.210.330.18111.5 118.21-6.7 0.1532.880 38610 32 -82.23-79.850.050.61113.16122.08-8.92-0.5530.9342.23119
6 21 -90.36-85.460.590.66123.3 128.3-5.01-0.0732.940 19970 58 -92.51-
87.650.90.94125.4 130.65-5.25-0.0432.8943 15561 107-81.66-
79.820.070.15109.16117.62-10.45-0.0827.5 39.796020148 115-83.73-
80.590.240.18110.06116.99-6.920.0529.3339.4 5028166 7 -89.3-
85.150.480.67121.04127.18-6.14-0.1931.7441.6 3920145 125-88 -
83.840.310.64119.06125.05-6 -0.3231.0641.212856176
▲注意:(1)郭家店2小区配置了10块载频,由于DAFNE 最多处理分析八块载频,因此有两个载频
的指标信息没有显示出来。
(2)由于频点中有EGSM 频点,DAFNE 软件无法解出。
但可以通过OPT 软件来确定频点对
应情况。
利用OPT 软件仔细观察每块载频的RxLev by TA、RxQual by TA情况,发现在TA=0~5
的范围内,有六块载频采样点集中的区域下行接收电平平均值在-80db ~-85db ,其他的四块载频采样点集中的区域平均值在-85db 以下。
图31郭家店2小区BCCH 频点的RxLev by TA、RxQual by TA情况。
通过OMCR 查该小区的硬件情况,发现该小区天馈系统配置为两个ANC ,一个ANY ,共接10块载频。
由此,我们推出该小区使用两幅天线,通过向局方了解,这两幅天线分上下两个平台覆盖同一区域。
载频接法如下图:
图32 郭家店2载频天馈连接图
由图32可知,接在ANY 上的四个载频的下行链路衰耗要比其他六块载频多出3.3db 左右,从工程要求上来说,此种配置方法是正确的,会导致链路不平衡,影响网络的覆盖,造成MC621、MC736掉话,MC76b 异常。
正确的接法是十块载频经过三个ANY 连接到两个ANC 上,这样衰耗一致,链路衰耗也就一致了。
但从实际情况来看,该做法是很不经济的。
因此,要想让各载频的覆盖达到一种均匀的状态,只能将小区的BCCH 频点踢到连接在ANY 下的载频上,这样就保证了其他载频的衰耗等于或小于它,那么也就相当于保证了该小区的每一块载频都能充分覆盖到BCCH 载频所覆盖的区域了(即小区的覆盖范围)。
郭家店2小区的BCCH 所在的载频,恰好是直接连在ANC2上,输出的信号通过上平台的天线发射出去,因此导致小区覆盖过远,而实际上,并不是所有的载频都能够有效覆盖到那么远。
当小区给手机分配的频点位于ANY 下的载频时,就会导致接收电平的衰减,从而发生掉话或者TCH 分配失败。
通过OPT 观察每一次TCH 分配失败事件,发现大部分时间发生在TA 大于10的距离上,图33就是一次TCH 分配失败过程的TA by TIME :
图33,某一次分配失败事件的
TA by Time
图34 郭家店站与周边站的位置情况图
调整建议:在非忙时,将衰耗小的六块载频打死,从而将 BCCH 频点踢到衰耗大的载频上,使覆盖区域内每块载频的下行链路消耗达到一致,小区覆盖明显稳定。
35 是调图整前后,MC746B、TCH 掉话次数的走势图。
图 35 TCH 掉话次数、MC746 走势图▲说明:此种方法再使用时,要特别注意,不要造成覆盖盲区。
就本例而言,从图 34 可知,距离 10 公里的范围内已经有站,而该小区在 TA =27 的的地方还有部分采样点,说明存在越区覆盖现象。
六小结:信令跟踪是无线网络优化中重要环节之一,它是帮助 OMCR、DT 等其他各组分析问题,定位问题的重要手段。
作为一名信令分析人员,我认为需要满足三个条件:①能够熟练的使用信令分析软件,如:DAFNE、Opt、K1205 的灵活使用。
只有这样,才能为自己的分析思路迅速找到相关的信令数据,有效的定位问题;②GSM Abis 口的信令流程以及信令信息的内容要做到熟练于心,对于各种事件(比如:TCH 掉话、TCH 分配失败、切换失败),要了解其 Abis 口信令是如何定义的,③也是最后一点,我觉得信令分析人员,对于每一个 CASE 细致入微的观察,总结问题
所体现出的规律,结合 GSM 理论知识分析处理,这样问题就一定能够定位。
最后,希望这篇有关信令分析的文章能给阅读此文的人带来一些借鉴、帮助。
四平信令跟踪案例分析(SP&RNO)第 31 页共 32 页
七附录: 1 Axis 接口信令解码是基于如下的 GSM 规范:①LAPD (GSM Layer 2 - 08.56 ②RSL (GSM Layer 3 - 08.58 ③DTAP (GSM Layer 3 - 04.08 2 GSM 规范中规定 Abis 口的掉话有 2 种形式:① Whenever a 08.58 “CONNECTION FAILURE INDICATION” message with a cause value of "radio link failure" is received on Abis interface for a TCH channel (after successful seizure. ② Whenever an 08.58 “ERROR INDICATION” with a cause value of “timer T200 is expired (N200+1 times " message is received on Abis interface and leads to a loss of call. 四平信令跟踪案例分析
(SP&RNO)第 32 页共 32 页。