路测切换失败的原因分析及解决
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
目录
第一章前言 (2)
第二章切换流程分析 (5)
一、小区内部切换(INTRA _CELL HANDOVER) (5)
二、BSC内部小区间切换(INTRA_BSC HANDOVER) (6)
三、MSC内部BSC间切换(INTRA MSC HANDOVER) (8)
四、 MSC间切换 (11)
第三章切换失败的原因分析 (13)
一、连续的切换失败 (13)
实例1 731医院的时钟失锁 (14)
实例2 化工研究院时钟失锁 (17)
实例3 沙沟DCS与东铁家坟DCS的同频同BSIC (18)
注: LAPD和LAPDm中使用的帧类型以及它们的结构 (20)
二、单独出现的切换失败 (21)
1)连续多个下行Physical Information,超过系统设置造成失败
(22)
实例:马家堡DCS1 (22)
2)无下行physical information (23)
A.同站不同小区之间将Synchronized Indicator置为True 23
注:设置小区同步切换对切换流程的影响 (25)
B.小区之间将Synchronized Indicator置为False (25)
3)三层消息中出现HO_Complete后手机再上行发送HO_Failure消
息 (25)
4)其它可能出现的切换失败现象 (26)
A.超过目标小区的最大服务距离,Cause: “handover
impossible, timing advance out of range” (26)
B.Cause: “frequency not implemented” (26)
C.Cau se: “channel mode unacceptable” (27)
D.lower layer 信道建立失败造成切换失败 (27)
E.目标小区要求加密、VGCS等设置与源小区不同且在
HO_Command中没有提及的 (27)
5) Cause 3与Cause 111的对比 (27)
结束语 (28)
第一章前言
在移动用户通话过程中为了使呼叫建立在最好的小区中以及为了使呼叫不至于掉话,就引入了切换的概念。
换句话说切换就是为了维持手机从一个小区移动到另一个小区使通话能继续进行,以满足网络管理的需要。
触发切换的原因、切换的准备和判决及切换的执行等是一个十分复杂的过程。
根据不同准则,切换的种类可从不同角度来划分。
一种角度是通过交换点的位置不同,广义的分可分为小区内部切换和小区间切换;具体的分可分为小区内部切换、BTS内部切换、BSC内部切换、MSC内部切换、MSC间切换。
还可以根据触发切换的原因(Cause)来划分:切换触发原因包括上下行Quality原因切换、上下行Level原因切换、干扰切换、Distance原因切换、功率预算切换(PBGT)。
其中功率预算定义为非紧急切换,其余切换类型定义为紧急切换。
在Motorola BSS判决切换时,优先级由高至低分别为
●Uplink Quality
●Uplink Interference
●Downlink Quality
●Downlink Interference
●Uplink Level
●Downlink Level
●Distance
●PBGT
当然切换还可以根据其他不同的条件分为其他种类,例如根据定时提前来划分,可以分为同步切换和异步切换,等等。
图1、图2为Motorola BSS判决切换的流程图。
可以从图中看出紧急切换判决的优先级别。
图 1
图 2
本文要讨论的是在路测过程中发现的切换失败的现象和原因,这些我们将在后面作主要介绍。
在这之前,先让我们大概了解一下小区内部切换(Intra_CELL)、BSC内部切换(Intra_BSC)、MSC内部切换(Inter_BSC)和MSC间切换的正常的
流程分析,这有利于后边切换失败流程的分析。
第二章切换流程分析
一、小区内部切换(INTRA _CELL HANDOVER)
因为是在该小区内部来分配TCH资源,其接续过程同呼叫建立是TCH的接续分配过程是一样的。
当BSC收到BTS发送过来的指派完成(ASSIGNMENT COMPLETE)的消息后,将向MSC发送出切换已执行(HO PERFOMED)的报文,该报文中将含有该切换的类型(如INTRACELL)。
此后,BSC将通过无线信道释放(RF CHANNEL RELEASE)的报文将旧的TCH信道释放,BTS收到该指令后,将把旧的TCH资源释放掉,并返回一条确认的消息(RF CHANNEL RELEASE ACK),表示该信道已空闲可用于其它的分配了。
流程如图3所示。
图 3 Intra_cell Handover 流程图
二、BSC内部小区间切换(INTRA_BSC HANDOVER)
当手机想切入的目标小区是同一BSC下的不同小区时,即将触发BSC内部切换事件。
BSC将通过对手机上行发送的测量报告进行分析,排列出符合切换条件的邻小区组,当发现该手机切换的目标小区是它所管理的另一小区时,将向目标小区B发出信道激活(CHANNEL ACTIVE)的命令,该报文中含有请求的信道类型和加密算法以及切换参考号等。
当B小区已准备好,则向BSC发出信道激活响应(CHANNEL ACTIVE ACK)的报文作为回应。
BSC收到该报文后,则将向原小区A 发出切换命令(HANDOVER COMMAND)的报文来要求手机去接入新的小区,该消息中含有在新信道上传输的所有特征信息和手机接入所需的数据,而且它还指示了该切换是同步切换还是异步切换,基站再将切换命令发送给手机。
当手机收到该命令后,通过判别若是同步切换则根据切换命令的指示,在所分配的新的TCH信道上向目标小区B发送几个(一般是四个)切换接入(HANDOVER ACCESS)的请求,然后用以前的TA值提前开始正常传输。
在这里还应注意一个问题,切换接入(HANDOVER ACCESS)这一消息通过的是接入突发脉冲(ACCESS BURST)发送的,这是接入突发脉冲用到专用信道上的一个唯一的特例,它仅含有从切换命令(HO COMMAMD)中所获得的8比特的切换参考号,由于该参考号是目标小区已知的,因此新的小区就可以通过该切换识别号来检查是否是期望的手机的接入请求了。
若是异步切换,当目标小区B的信道被激活后,它将一直在所分配的专用信道上来等候手机的接入,当它检测到手机发出的切换接入请求后,一方面向BSC 发出切换检测到(HO DETECT)的消息,一方面向手机发出物理消息(PHYSICAL INFORMATION)来向手机提供它所计算出的新的定时提前的结果。
,
就会使用该TA值,进入正常传输模式,在新的TCH信道上(此时是NORMAL BURST 的形式)向网络发出SABM的报文(Um接口Layer2的设置异步平衡模式。
我们将会在后面的章节中,介绍二层信息的种类和作用),若网络收到了该报文,一方面向BSC发出建立指示(ESTABLISHE INDICATION)的报文,表明数据链路层已建立起来了,一方面向手机发出UA的响应帧。
当手机收到UA的响应后,它会认为已和该小区建立起了信令的应答模式,此后它就会向目标小区发送一条切换完成的消息(HANDOVER COMPLETE),在该报文中,只有切换完成的指示,并不携带其它消息,只有在该报文发出后,手机才会放弃会到旧信道的所有可能性。
若手机没有收到目标小区发出的物理消息(PHYSICAL INFORMATION)或UA的响应帧超过设置时长,它就会在该信道上向源小区发出一条切换失败(HANDOVER FAILURE)的报文,再由原小区考虑是否再进行切换。
有关路测中切换失败的问题我们将在下一章作具体介绍。
当目标小区B收到手机发出的切换完成的消息后,将再把切换完成的消息通知给BSC。
BSC收到该消息后,一方面向原小区A通过无线信道释放(RF CHANNEL RELEASE)的报文通知来它释放旧的TCH信道。
当原小区A收到该报告后,将返回一条无线信道释放响应(RF CHANNEL RELEASE ACK)报文,表示该无线信道已释放完毕,可用于再次分配了。
另一方面,BSC则会向MSC发出切换已执行的报文(HO PERFOMED)通知,该消息中有切换的类型。
BSC内部切换通常是由BSC自动完成,在整个决策过程中都不需要MSC的参与,为了通知MSC已成功的完成了一次切换,一般会向MSC发出一条HO PERFOMED 的通知。
三、MSC内部BSC间切换(INTRA MSC HANDOVER)
本节中讨论的切换也可以称为BSC间切换(INTER_BSC HANDOVER),但仅限于在同一个MSC内的BSC间切换,跨交换机的BSC间切换,则称为MSC间的切换。
BSC通过对手机测量报告的分析,若发现切换的首选目标小区属于不在该BSC 下时,它将向MSC发出一条切换申请(HANDOVER REQUIRED)的报文,该报文中包含了切换的目标小区组和原小区的小区识别号(CELL ID),以及切换的原因等。
当MSC收到该消息后,将尝试切入首选的目标小区,通过查询本端LAC表若发现目标小区的LAC号是自己的,则查询该小区的位置所在BSC,并向新BSC发出一
条切换请求的消息(HANDOVER REQUEST),该消息中包括目标小区和原小区的信息、传输模式(从目前的需要获得,因此可能与原小区连接的特性不同)、加密模式(与以前一样)、手机类标(CLASSMARK)及所需的信道类别等。
当新BSC收到该消息后,首先向MSC发一条SCCP连接的(CC)的确认消息,表示MSC与它的SCCP的连接已建立起来了,此后将通过该路径来传递A接口的信息。
若当BSC 发现有信道资源,则将通过交换信道激活和信道激活响应两条报文来准备好一条新的TCH信道,目标小区同时也准备好手机的接入。
当新BSC收到目标小区发来的信道激活响应后,将向MSC发送一条切换请求响应(HANDOVER REQUEST ACK)的报文,在该报文中携带着切换命令的消息,表明本端已经准备完毕,并将与该次切换所分配资源有关的信息发送给MSC。
当MSC 收到该消息后,将向原BSC发送切换命令(HANDOVER COMMAND),该报文中含有小区号码、信道类型和切换参考等消息。
当手机收到该切换命令的消息后,将根据该消息的指示来试图接入新的小区,此后将进行切换接入过程,当手机成功的接入后,新的BSC将向MSC发切换完成(HO COMPLETE)消息。
当MSC收到该消息后,就会向原BSC发送一条清除命令(CLEAR COMMAND),该报文中含有清除的原因(如切换清除等),当原BSC收到该报文后将释放掉旧的TCH信道后将向MSC 发出清除完成(CLEAR COMMAND)的消息。
在MSC收到该消息后,将把以前的SCCP 拆除掉。
于是,本次切换过程完毕。
流程如图5所示。
图 5 Inter_BSC Handover 流程图
四、 MSC间切换
当MSCA收到BSC的切换申请(HANDOVER REQUIRED)后,通过对报告的分析,若发现切换首选目标小区的LAC号没有在其本地的LAC表中,则会查询其远端的LAC表,该LAC表中含有相邻MSC/VLR的路由地址,当找到目标MSCB的地址后,MSCA则会向该目标发出切换准备(PREPARE HANDOVER)的消息,并将切换请求( HANDOVER REQUEST)装到此报文的一个“信封”中。
目标MSC收到切换准备的报文后,将向其VLRB通过发送(ALLOCATE_HO_NUMBER)来请求分配切换号码,切换号码的分配只是为了使归属MSCA能够建立起来与目标MSCB之间的路由而提供的一个指向,VLRB将选择一个空闲的切换号码(HON)并通过送切换报告的消息(SEND HO REPORT)将切换号码发送给MSCB,MSCB收到后将返回一个送切换报告响应(SEND HO REPORT)的报文。
此后,MSCB将建立一条与目标BSCB的SCCP链路,并向BSCB发出切换请求(HANDOVER REQUEST),再由BSCB将目标小区的信道激活。
BSCB在收到目标小区发来的信道激活响应后,将向MSCB发送含有切换命令报文的切换请求响应(HANDOVER REQUEST ACK)。
在MSCB收到该消息后,就将该消息同切换号码一同包装在切换准备响应(PREPARE HANDOVER ACK)中发送给归属MSCA。
MSCA一旦收到该报文后,就能向MSCB发送通过初始化地址消息(IAM)的报文,在该报文中含有VLRB所分配的切换号码,以使MSCB来识别哪个话音信道是为该手机所保留的。
流程如图6所示。
图6 MSC间切换过程
在MSCA 收到MSCB发来的地址全(ACM)消息后,便可将切换命令发送给手机,通知它接入目标小区。
此后手机将完成与目标小区的切换接入过程。
在收到手机发送的切换接入消息后,MSCB将向MSCA发送一条PROCESS ACCESS SIGNING 的报文表示切换已检测到。
当目标小区收到手机发回的切换完成消息后,将通知给MSCB,于是MSCB就通过向MSCA发送一条送结束信号(SEND END SIGNAL)的消息,来通知它切换已完成。
在MSCA收到切换完成的指示后,将向原BSCA发送清除命令,来释放旧的信道资源。
当释放完成后MSCA将通知MSCB,MSCB并向其VLRB发送切换报告,来请求释放所分配的切换号码。
此时已完成MSC间切换。
异常情况是,当MSCB发现无法识别的目标小区、不允许切换到所指示的目标小区、目标小区中无可用的无线信道、VLRB中无可用的切换号码或在出现数据错误时都将向MSCA发出切换失败的指示。
从而使MSCA再对次选的小区进行切
换,或返回到原来的信道上去。
第三章切换失败的原因分析
手机在通话中为了保证通话质量,经常会切换到能够提供更好服务的小区上去,如果移动的距离较长,则会发生多次切换的现象。
虽然切换失败不等同于掉话,但在GSM网络中切换失败就意味着增加了网络的信令流量,并且也是掉话的隐患。
因此处理好切换关系,减少切换失败的任务是优化工作非常重要的一项环节。
在这一章里我们将从路测角度结合实例来分析日常工作中会遇到的切换失败的现象,并分析造成各种现象的原因以及相应的处理办法。
总的来说,在遇到切换失败事件时首先应该从HO_FAILURE消息中查找切换失败的原因解释(Cause value),有些切换失败是可以直接查到切换失败原因的(可以详查GSM规范)。
但对于有些Cause value,如Cause value111(Protocol error,unspecified)、Cause value 3(Abnormal release,timer expired)等就无法定位具体原因。
对于这些情况,我们就应该再进一步的对信令流程、多种测量参数、统计报告以及测试现场的环境等进行综合的分析,从而进一步确定切换失败原因。
下面的大部分篇幅的分析解决办法都是基于这些无法定位具体原因的Cause value。
一、连续的切换失败
测试中我们有时会遇到这样的情况:如图7所示,接连不断的出现切换失败,当测试工程师继续驱车向前行驶时,就可能导致拖带掉话。
从系统下行发送的Handover_Command消息中我们可以发现,目标小区都是同一个小区(或同一个基站的不同小区)。
此种现象一般都和基站或传输设备的时钟故障有关,但也有可能是同频同BISC的小区造成的。
下面我们通过几个具体实例来说明。
图7 连续的切换失败
实例1 731医院的时钟失锁
现象:我们先从一个小区因PBGT原因切换至小区3070,切换正常。
当与服务小区3070距离较远,下行电平逐渐变弱,邻区电平逐渐增强时,迟迟没有切换,最后向排位很低的一个小区进行了切换,切换后效果很差,服务电平仍然不高,致使Quality很差。
随后又在这两个小区之间乒乓切换,但始终没有向较好的另外几个小区发出HO Command;
分析:最好的前几个邻区的BSIC码均没有解出,所以只能向解出BSIC码的邻区发出HOCommand。
如图8。
图 8
通过分析,我们知道最强的34号和47号频点来自于基站‘731医院’的两个小区(3557、3558)。
因此,我们把车停在了该基站附近,由于解码错误,这时解出的邻区BSIC是错误的,而并非当前最强的34、47号频点小区的BSIC,致使全部切换失败。
如图9。
图 9
故障原因:
先从Handover Failure的CauseValue入手(图10),在发现是无法具体定位原因的Cause111后,再通过对目标小区的告警分析,发现该站的时钟失锁,需更换时钟硬件。
图10
更换时钟后该问题解决。
实例2 化工研究院时钟失锁
现象:无法切入该站任何一个小区,经空闲状态下重选到该站后,又无法切出至周围任何一个小区。
如图11、12、13所示。
图 11 无法切入
图 12 空闲状态
图 13 无法切出
原因分析:先查看HO_Failure的Cause Value=111。
再根据切换失败现象怀疑为时钟硬件问题,查看硬件告警发现该站时钟失锁。
经过更换硬件,问题解决。
实例3 沙沟DCS与东铁家坟DCS的同频同BSIC
现象:在路测过程中,主被叫手机突然出现莫名其妙的连续的切换失败。
从现象上看很像是时钟问题,但经检查并无基站有时钟告警。
故障分析:分析了切换的目标小区为BSIC=41,BCCH=522,经过检查是邻区沙沟DCS2,但从基站位置来看,当时切换失败所处的位置是不可能收到该小区很强的信号的,,而在该位置上应该收到301医院的信号,但是当时却没有收到301医院的信号。
通过检查发现当时301医院断站,造成该路段无主覆盖小区。
经过核查数据,发现当时的服务小区正大南路DCS北侧的东铁家坟DCS2的BSIC 和BCCH与切换的目标小区沙沟DCS相同,但不是正大南路DCS的邻区。
由此可以断定,手机当时测到的邻区频点522的强度为东铁家坟DCS2的,但由于与邻区沙沟DCS同频同BSIC,而造成系统下发HO_CMD,最终导致了切换失败。
解决问题的办法就是首先启动已断基站,让该路段拥有主控小区;另外应适当减小东铁家坟的覆盖范围,或通过改频和BSIC,将东铁家坟DCS2加为正大南路的邻区。
表 1 切换失败的Layer2&Layer3的信令流程1
图 15 有关各基站位置示意图
表2 LAPD和LAPDm帧类型(其中RNR和FRMR在LAPDm中不用)LAPD和LAPDm帧各自的结构如图所示。
地址段包含有SAPI;另外,对LAPD 帧,
因为接口是点到多点的,还包括目的终端的地址。
控制段包含帧类型,对于携带消息的编号帧,还包含有帧编号(发送端)和下一个期望帧编号(接收端)。
(a)LAPD帧结构
图16 LAPD和LAPDm帧结构
在下面的切换失败分析里,我们将提出将路测文件中的Layer3 Message和Layer2 Message综合分析的办法,因为这样才能发现以前传统做法(只分析Layer3 Message)所不能发现的问题。
二、单独出现的切换失败
如上所述,面对连续的切换失败时,我们的目标比较明确,而且基本上都是
与时钟等硬件有关,比较容易发现问题,也比较好解决。
而实际工作中,却存在着偶尔单独出现的切换失败现象。
出现这种现象的原因却是多种多样,我们在这一节中将针对不同的现象分析不同的原因,值得注意的是,虽然大多数单独出现的切换失败现象很相似,但通过对信令的分析(时间、帧号、信令内容等),就会找出切换失败的具体原因。
带着这个思路我们来看下面的介绍。
1)连续多个下行Physical Information,超过系统设置造成失败实例:马家堡DCS1
现象:从Handover_Command到系统下行发第一个Physical Information正常,因此软件认为切换成功,发送HO_Complete消息。
但1.05秒后又上行发送
的新思路积累经验。
2)无下行physical information
A.同站不同小区之间将Synchronized Indicator置为True;
实例:北太平庄路口DCS
现象:测试工程师在北三环自西向东行驶,占用小区31047,随着继续行驶,
TA已经达到3,这时服务小区的覆盖电平已经降到-8xdBm,Quality也达到4、5级,但邻区覆盖电平并不高。
后系统令手机向同站的31048发出切换命令,但切换失败。
分析:首先先看Handover_failure中的CauseValue=111。
再分析信令流程:从HO_Access到HO_Complete之间无任何信令,原因是同站不同小区之间我们在邻区设置时,将默认同步值设为True,因此,在切换时系统不会下行发送Physical Information,而手机在发送HO_Acces后也不会等待下行消息,不会
但是为什么最后还是切换失败了呢?仔细研究2层消息,手机连续发送6条SABM消息,等待接收UA-RSP的连接确认消息,造成Um接口的LAPDm协议上的T200×(N200+1)超时是切换失败的原因。
经过核查邻区关系,我们发现小区31047缺少东边一些相邻的邻区,造成只能回切至自己本站的2小区的现象,但由于距离太远,已经无法收到下行或上行的消息,造成了切换失败。
故障解决:加上适当邻区后该问题解决。
我们在下面的注解中将刚才提到的有关同步/非同步切换所涉及到的计时器介绍一下:
注:设置小区同步切换对切换流程的影响
✓在邻区关系设为Non_Synchronized时,手机在发送HO_Access同时会启动T3124,在这个计时器期间未收到下行的Physical
Information,便认为切换失败;收到Physical Information后T3124
自动停止,这时会上行发送Layer 2 SABM消息,启动LAPDm的T200
和N200计时器,在T200×(N200+1)时间内未收到下行的UA-RSP
的确认消息就会发送切换失败消息。
✓在邻区关系设为Synchronized时,手机不会启动T3124计时器步骤,直接进入Layer2计时器阶段。
B.小区之间将Synchronized Indicator置为False;
在收到手机上报的HO_ACCESS消息后,从理论上基站是应该发出下行Physical Information的,但造成手机端未收到或未正确解码的原因有很多。
这种情况下应当首先考虑硬件问题,比如信道盘、时钟、传输等。
另外考虑是否有频率干扰的问题,由于干扰造成的上下行消息不能正确接受的影响范围很广,产生的原因也多种多样,所以有时不能单单从GI分析软件(GSM Investigator,Motorola开发的优化工具)等方法中发现带内干扰,例如可能由于邻区不全造成拖带,从而造成与远处基站的干扰等等,这就要视具体情况而定。
3)三层消息中出现HO_Complete后手机再上行发送HO_Failure消息
实际上在GSM规范中没有此类的规定,仅在用TEMS测试中中发现此类现象。
如果系统收到的手机上报的切换失败的消息后,会通知源小区进行拆线,空出原信道,这样手机切换失败后就不能回到原信道,从而造成切换掉话。
但经过大量TEMS的路测文件的分析,并没有出现上述的切换掉话现象,从这个角度说,我们可以认为这是软件问题,实际上系统并没有收到切换成功的消息。
至于软件问题的具体原因,Ericsson公司还没有给出正面的答复。
实际我们可以参照第一种情况“连续多个下行Physical Information,超过系统设置造成失败”的解决办法。
4)其它可能出现的切换失败现象
除了以上所介绍的几种常见的切换失败的类型外,我们还可能遇到一些其它不常见的切换失败,这些都是GSM规范中定义的切换失败类型,主要是系统设置出现问题,或手机不支持网络设置所致。
A.超过目标小区的最大服务距离,Cause: “handover impossible, timing advance out of range”(见GSM规范04.08)
在小区设置时,可以设置小区的最大服务距离,参数以TA为单位,最小可以设到0。
该参数的目的有两个:1、控制小区用户起呼的范围,超过设置范围的用户将不能起呼;2、控制该小区的话务量,使得超过该小区设置范围的用户自动切出,另外“阻止”超过改设置范围的用户切入。
这样在Handover Failure中的Cause: "handover impossible, timing advance out of range"。
在GSM规范中规定在同步切换或预同步切换的时候,下行系统发送的HO_Command消息中包含了目标小区TA设置为多大,由于手机会以源小区的TA为基准向目标小区接入,当发现自己所用的TA值超过目标小区的限制时,便会立即上行发送HO_Falure消息,并且Cause: "handover impossible, timing advance out of range"。
B. Cau se: “frequency not implemented”(见GSM规范04.08)
如果切换失败原因为Cause "frequency not implemented"时,说明有以下两种可能:一种是手机不能调谐到HANDOVER COMMAND消息中所包含的频率上,例如单频手机不能切到其他频段上,但此类现象只有在交换机上设置参数错误或出现故障时才可能发生,因为系统是会根据手机的类别来有针对性的发出切换命令的;另外一种原因是手机在收到的包含有Frenquency List的字节中包含有不同频段的频点。
以上两种情况手机就会立即直接发送HANDOVER FAILURE消息,
并保持使用原先的信道不变,返回系统的失败原因就是Cause "frequency not implemented"。
C.Cause: “channel mode unacceptable”
如果手机不支持HANDOVER COMMAND中提供的信道模式或者根本没有此类信道模式,手机就会立即发送HANDOVER FAILURE消息,并保持现有信道和信道模式。
(详见GSM规范04.08)
D.lower layer 信道建立失败造成切换失败
此类现象在实际工作中从未遇到过,但是规范中有此类原因的切换失败。
(详见GSM规范04.08)
E.目标小区要求加密、VGCS等设置与源小区不同且在HO_Command中没有提及的;(见GSM规范04.08)
5) Cause 3与Cause 111的对比
在日常工作中,我们使用的测试设备有两大类,一类是Ericsson公司的TEMS 系列,这其中包括TEMS98,TEMS-Investigation2.0/3.0,TEMS-Automatic等;一类是NEMO公司的NEMO-TOM/SAM系列。
由于双方软件设计的一些不同,一些方
TEMS中三层消息较全,另外还有二层消息,对于分析问题更加便利。
相比而言TOM的三层消息就比较少,有些重复发送的例如系统消息和测量报告就不会纪录下来,另外还没有二层消息。
另外,我们发现在Ho_Failure中的Cause Value中也有这不同的判断,这一般体现在不明原因的切换失败上,在TEMS中均为Cause111(Protocol error,unspecified),而在TOM中则多为Cause3(timer expired)。
因此,前文中Cause Value不明原因的切换失败是基于TEMS的Cause111的,但在用TOM 测试的分析中,遇到的Cause Value3也同样适用。