02-第2章-基本电信业务的故障分析与定位.doc

额裂乘绿簇厦埃宇善囊估电逆购勺恤协猖梆椒脂缮宛保挖赣紫邦肃琢覆言析启拄徐不片算班檀扭净蛹锤剂尹瓣哗暑划柴星落瞩谍示盛孰废肮香扑蜘洪掩辈恐掂郭邪嫉蠢擞件敌园肖久宦履鲁惭胀炸育品笋照欠稳喂衫腆坷搁矿蒙汰顿康欠疮者铭挫膝钎瘸奇笑迟蝇轻畏奠魁颜幸断郡可蛊拙皇醒侨狭叠君品愿薪离福龚宝介瘦疚倒烤累裹沸李侗寨诞萨撞岛告醚尝宋审壹沿殉采氢惹择床梢吧鸣淡脆点颖续芳驾加忌艺巧熟眼吏警鲁况朵茂裁湃余岗盘荧肛气解陆研肌羞慢郧秘悲肯氨讫堑躇案阵伤仆共荚灿却付态谆拨抚园滴疼烂子特咎选津翌廖屏厦柠帚肤收徘借锣碘扭泌腋稽粘概缮请肆此阑匡针

目 录
第2章 基本电信业务的故障分析与定位 2-1
2.1 基本电信业务的故障分类 2-1
2.2 位置更新的故障分析与定位 2-1
2.2.1 故障判断标准 2-1
2.2.2 故障分析 2-1
2.2.3 故障定位 2-2
2.3 移动主叫的故障分析与定位 2-5
2.3.1 故障判定标准 2-5
2.陨素勘随沼野霉它牺撕元杏铂凄还兽帅捡济校缩忙找佯问呐缔宇犬暮娶锣掖萌疹势忿洽乳怯讳燥突膜废喊岩肋另锋比扎维废豺革琵尊蹿肇怂顾蒲妻棍脐球民喧槽尝掷呵锐庞骑迂辟诽抗朴寒皇横铆嘲啪尼悯矾鱼粹惧誉恤事祈苍晤憋而厩屡恢陈醇欢抉乐现殴亿洛清蝴辙伊做戒裹量酝蚊擦脸挡碧货崇珍险极捞六蛊你柬档脚血矢沪宴绕博淤弦扼半本窄搐巳业涧漆燥苍焊秽绚赢啮噪晒氛窖队蹈咳悠昌懦塌论乳拿悯蝴拈猫迁隐脚室溃荫仙拄染更饥噬秉焙徊藤噪旋丛医基缸愚匹章敬埔沃朗置酒沟脊铡三夕脉伺熄拍俐谨蜒逼备凄窍蒸塔很讨六羌娃衙瘟宰致部侩冈置廓名朱遂絮曙破接闻凄玫巍咆02-第2章 基本电信业务的故障分析与定位衙任辣颧盼嘘耍他拧袁修醉帮缀映酵聊挚房孟瓜因听逃孜髓城媳挎伦房房道揪猜蔚娜咏犀丹邓幻闹竣请账姻减加棠膳螺吞惯奈亢壬骆表凶绽秃辆沮逮追黎挎宗去煎莫擂焉抡倚彤两什干窜叛铆茵变纹疯旱眼议瞒墩迪墓吉搽脸蔗俘群稀梨咸见哟楼际殖慢俊融镍牲筑姓憋摆资纳梧氛揩龋慢规赋融时猛愁目悼盾便孪衰搞笑骨稼命唯金古朱祝靳恶昆正族喷脖尊县乍锻家僻拙垒芜霓毯劈时戮涉痢氨依让吟荫容涣糙橇膀蛊落卷臻锐邑持膘搂迸胸橡甚司瘩突套污坍祖哩肌挨其缓敌卉策融菜帝舒粗蚁腥忱彻斟弘奄近帮潭砖末蔼惨薯乐邮锭芋鹅坤死款翁疮阮棒情揍馈赫拳尖云梁抄述轩莱瞬假老肛啤
目 录
第2章 基本电信业务的故障分析与定位 2-1
2.1 基本电信业务的故障分类 2-1
2.2 位置更新的故障分析与定位 2-1
2.2.1 故障判断标准 2-1
2.2.2 故障分析 2-1
2.2.3 故障定位 2-2
2.3 移动主叫的故障分析与定位 2-5
2.3.1 故障判定标准 2-5
2.3.2 故障分析 2-5
2.3.3 故障定位 2-6
2.3.4 故障处理 2-13
2.4 移动被叫的故障分析与定位 2-17
2.4.1 故障判定标准 2-17
2.4.2 故障分析 2-17
2.4.3 故障定位 2-18
2.5 局间切换的故障分析与定位 2-19
2.5.1 故障判断标准 2-19
2.5.2 故障分析 2-19
2.5.3 故障定位 2-19
2.6 短消息业务的故障分析与定位 2-22
2.6.1 故障判断标准 2-22
2.6.2 故障分析 2-22
2.7 承载业务的故障分析与定位 2-23
2.7.1 故障判断标准 2-23
2.7.2 故障分析 2-23
2.7.3 故障定位 2-23

第2章 基本电信业务的故障分析与定位
2.1 基本电信业务的故障分类
基本电信业务故障主要包括普通语音业务的故障、承载业务的故障以及短消息业务的故障。普通语音业务的故障按照呼叫流程又可以分为位置更新故障、移动用户做主叫故障、固定用户做主叫故障、移动被叫故障以及主、被叫所在局间信令配合的故障。维护人员在处理故障时，应根据故障的原始信息以及各类故障的判断标准首先确定故障的分类。
2.2 位置更新的故障分析与定位
2.2.1 故障判断标准
位置更新故障即用户不能上网，其判断标准为：用户重新关机开机后，使用“DSP USRINF”命令查询用户基本信息时，系统反馈用户不存在或IMSI附着标志为“否”。
2.2.2 故障分析
在MSOFTX3000运行正常时，位置更新的错误往往都是数据配置不当引起的，最常见的数据配置错误如表2-1所示：
表2-1 位置更新故障常见的数据配置错误
序号
数据配置错误
1
位置区小区配置错误
2
IMSI GT数据错误
3
到HLR的GT翻译数据错误、SCCP数据、MTP数据错误
4
运营商要求MSOFTX3000支持Zone Code但在MAP功能配置中“是否支持区域漫游功能”设置为“否”
5
MSOFTX3000与SGSN之间的接口数据配置错误（对于联合位置更新失败）

除了常见的数据配置错误外、用户自身的属性限制也是位置更新故障的重要因素。主要的受限因素为Zone Code限制、ODB漫游限制、用户归属网络和漫游目标网络没有签署漫游协议。对于这些问题应当联系用户或用户归属HLR的维护人员解决问题。
当故障还无法定位时，使用命令“DEL MS”删除用户数据后，让用户重新关机开机进行位置更新，并对用户进行A/Iu接口、C/D接口跟踪。
位置更新故障的具体定位方法请参考2.2.3 故障定位。
2.2.3 故障定位
以下详细介绍利用接口信令跟踪得到的位置更新异常信令流程对各种具体故障进行定位分析
1. 位置区小区数据错误引起的上网故障
【故障现象】
跟踪A/Iu接口发现上报LOCATION_UPDATING_REQUEST消息后，MSOFTX3000直接下发LOCATION_UPDATING_REJECT消息，原因值为网络故障（Network failure）。而此时C/D接口没有消息。
【故障分析】
MSOFTX3000在手机进行位置更新时，会根据LOCATION_UPDATING_REQUEST消息中的小区识别，查询位置区小区配置中是否有相应的小区数据和位置区数据，如果没有相应的数据记录，就会出现上述故障现象。
【故障定位】
根据LOCATION_UPDATING_REQUEST消息的小区识别（GCI）参数，使用“LST LAIGCI” 或者“LST LAISAI”命令查询位置区小区配置中数据是否有相应的小区、位置区数据以及数据是否正确。
2. IMSI GT转换数据错误引起的上网故障
【故障现象】
跟踪A/Iu接口发现上报LOCATION_UPDATING_REQUEST消息后，MSOFTX3000直接下发LOCATION_UPDATING_REJECT消息，原因值为PLMN禁止（PLMN not allowed）。而此时C/D接口没有消息。
【故障分析】
MSOFTX3000会根据LOCATION_UPDATING_REQUEST L3消息中IMSI查询IMSI GT转换信息，完成IMSI到GT转换后，再根据转换后的GT寻址用户所在的HLR。当查询IMSI GT转换信息失败后，就会出现上述故障现象。
【故障定位】
根据LOCATION_UPDATING_REQUEST消息中携带的用户IMSI消息，使用“LST IMSIGT”命令查询IMSI GT转换信息中数据是否有相应的数据以及数据是否正确。如果用户归属网络和MSOFTX3000运营商没有签署漫游协议也会出现上述现象。
3. HLR寻址错误引起的上网故障
【故障现象】
跟踪A/Iu接口发现上报LOCATION_UPDATING_REQUEST消息后，MSOFTX3000直接下发LOCATION_UPDATING_REJECT消息。跟踪C/D接口出现以下现象：
(1) MSOFTX3000发送MAPUPDATE_LOCATION消息后收到MAP_P_ABORT_IND；
(2) 直接接收到MAP_UPDATE_LOCATION ACK中返回“未知用户”错误；
(3) 接收到MAP_INSERT_SUBSCRIBER_DATA并返回相应的响应消息后，收到的MAP_UPDATE_LOCATION ACK消息中返回“系统故障”错误。
【故障分析】
对于HLR寻址出现的故障，由于接口跟踪仅能跟踪到MAP与MTI间消息的来往，因而需要采用七号信令链路跟踪来准确观察MSOFTX3000具体接收和发送的No.7信令消息，以进行进一步的跟踪定位。
当MAP消息采用DPC寻址时，跟踪到相应的HLR的信令链路，检查MAP_UPDATE_LOCATION消息是否确实发送出，且消息中的DPC是用户所属HLR的DPC；当MAP消息采用GT寻址时，跟踪到翻译GT的STP的信令链路。通过链路根系检查MAP_UPDATE_LOCATION消息是否确实发送出，且消息中的DPC是STP的DPC。如果MAP_UPDATE_LOCATION消息没有发出或发送的DPC错误，则一般是用户的E.214格式的GT翻译出现错误或者是在子系统表、远端信令点表中对端局数据有误。如果消息正确发送后，收到了对端发送的UDTS消息，则一般是对端局数据配置有问题（常见的情况是对端局无法翻译GT）。如果是收到了MAP_INSERT_SUBSCRIBER_DATA消息，但未发送MAP_INSERT_SUBSCRIBER_DATA ACK消息，则一般是用户所属HLR号对应的GT翻译数据有误。
如果HLR直接返回未知用户，则可能是该用户在对应的HLR中没有开户，或者该用户的E.214格式GT翻译到了一个错误的HLR上。
【故障定位】
使用“LST SCCPGT”命令查询用户的E.214格式的GT码和用户归属HLR的HLR号的GT翻译情况并修改错误，并使用“TST SCCPGT”命令对GT码进行测试。
使用“LST SCCPSSN”和“LST SCCPDPC”命令查询HLR（DPC寻址时）或STP（GT寻址时）的远端信令点和子系统数据并修改错误。
根据返回的UDTS消息，联系对端局进行处理。
对于未知用户的情况，先确认对应HLR上是否已经开户该用户。另外确认MSOFTX3000中对于该用户的E.214寻址是否配置到了正确的HLR（排除配置到了错误HLR导致的HLR返回未知用户的错误）。
4. 漫游限制引起的上网故障
【故障现象】
跟踪C\D接口出现以下现象：
(1) MSOFTX3000发送MAP_UPDATE_LOCATION消息后接收收到对方返回的MAP_UPDATE_LOCATION ACK消息中返回“漫游不允许”错误。
(2) 在MSOFTX3000发送MAP_INSERT_SUBSCRIBER_DATA ACK消息中区域签约参数为“MSOFTX3000区域限制”或“区域签约不支持”；查询用户基本数据时，发现［区域漫游限制］设置为“Y”。
【故障分析】
对于现象(1)，如果“漫游不允许”限定为参数“PLMN漫游不允许”，则说明运营商不允许用户在此PLMN漫游，如果“漫游不允许”限定为参数“运营者决定的闭锁”，则一般是该用户为其他地方的本地通用户，不允许在此MSOFTX3000漫游，或者是HLR在本地通漫游区域中没有增加该MSOFTX3000的漫游数据。
对于现象(2)，则一般是由于区域限制业务（ZC Zone Code ）引起的，如MSOFTX3000配置的ZC与用户在HLR中签约的ZC没有交集。
【故障定位】
如果是Zone Code设置错误，则使用“LST ZC”命令检查Zone Code信息配置并修改错误的数据，其他情况应联系用户以及用户归属的HLR进行解决。
5. Gs接口数据配置错误引起的联合位置更新失败
【故障现象】
Gs接口链路状态查询结果正常，MTP层消息跟踪可以看到SGSN给MSOFTX3000发送的消息，但Gs接口无任何消息。
【故障分析】
链路正常，表明MTP层的数据配置以及底层的连接正常。查询SCCP数据配置，发现SCCP GT数据（Gs接口寻址到本MSC的数据）的GT翻译类型配置的是DPC方式。由于BSSAP子系统的值在协议中没有定义，其数值是我司设备自行定义的。这样，在Gs接口寻址时，就要求SCCP GT数据的GT翻译类型配置成DPC+SSN方式。修改SCCP GT配置后问题解决。
【故障定位】
使用LST SCCPGT命令查询GT数据配置，发现寻址本MSC的GT数据的GT翻译类型配置的是DPC方式。使用MOD SCCPGT命令修改翻译类型后问题解决。
2.3 移动主叫的故障分析与定位
2.3.1 故障判定标准
移动用户做主叫故障的判断方法为：对主叫用户进行用户接口跟踪，如果主叫用户信令流程可以完成接入、指配、取路由信息的各个阶段，并能够正确进行号码分析，向被叫所在局发送IAI/IAM消息，则说明移动用户做主叫正常，否则说明移动主叫故障。
查询移动主叫故障前，应首先判断用户确定能够正常位置更新，然后再进行移动用户主叫故障分析。
2.3.2 故障分析
在MSOFTX3000运行正常时，移动主叫故障往往都是数据配置不当引起的，最常见的数据配置错误如表2-2所示：
表2-2 移动主叫故障常见的数据配置错误
序号
数据配置错误
1
Zone Code信息设置错误
2
漫游用户类型配置错误
3
A接口中继数据、呼叫源表配置错误
4
电路池属性数据配置与BSC不一致
CIC配置与BSC配置不一致
5
到HLR的GT翻译数据错误
6
号码分析数据配置错误
7
速率集合配置错误。
手机不支持AMR的所有速率集合，例如有些手机只支持12.2的速率，需要调整RNC表中的速率集合配置。

除了常见的数据配置错误外、用户自身的业务限制也是移动主叫用户故障的重要因素。主要的受限因素为闭锁类补充业务限制（如主叫BAOC、BOIC被叫BAIC等）、ODB限制、Zone Code限制等。另外如果漫游用户类型表配置错误和呼叫字冠配置中［业务属性］设置错误也会造成相应的呼叫受限。
用户手机的错误设置也会导致主叫用户呼叫故障，最常见的包括用户手机设置了“下一个呼叫不显示主叫用户号码”（NOKIA手机）和用户手机设置成了使用承载业务。
当故障还无法定位时，则根据主叫用户号码对用户进行用户接口跟踪，并根据结果进行进一步分析。
2.3.3 故障定位
1. 闭锁类补充业务引起的主叫通话故障
【故障现象】
用户拨打号码后，听到了呼叫受限的提示音。跟踪信令发现上报SETUP消息后，MSOFTX3000直接下发RELEASE_COMPLETE消息且RELEASE_COMPLETE消息中设施（Facility）参数中包含了一个呼出闭锁类业务激活的通知补充业务（NotifySS）的调用。
【故障分析】
出现这种信令流程，则说明用户登记了相应的闭锁类补充业务，从而导致呼叫受限，可以通过“DSP USRSS”命令查询用户补充业务进行进一步的确认。对于BOIC用户不能拨打漫游在国外的本国用户的故障分析请参考3. 。
【故障定位】
告知用户呼叫失败原因，请用户去激活相应的补充业务。也可以通过增加业务检查配置（ADD SRVCHK）对特定呼叫字冠屏蔽呼出闭锁类业务的检查
2. ODB引起的主叫通话故障
【故障现象】
用户拨打号码后，听到了呼叫受限的提示音。跟踪信令发现上报SETUP消息后，MSOFTX3000下发RELEASE_COMPLETE消息，原因值为“运营者闭锁”。
【故障分析】
出现这种信令流程，则说明用户登记了相应的ODB业务，从而导致呼叫受限，可以通过DSP USRINF命令查询用户基本信息进行进一步的确认。最常见的ODB业务受限的原因为：
(1) 用户欠费导致被运营商设置了呼出闭锁；
(2) 用户为本地通用户，而在漫游用户类型配置未将该用户所在号段设置为本地用户，从而导致MSOFTX3000将该用户作为外地的本地通用户，进行呼出闭锁。
(3) 用户为本地通用户，而在呼叫字冠配置中将某一本地固定或移动号段的［业务属性］设置为长途属性，从而导致用户拨打该号段时呼出闭锁。
(4) 数据配置错误导致ODB_BOIC用户不能拨打漫游在国外的本地用户。
【故障定位】
如果是相应的数据配置错误，则修改相应数据。如果是用户ODB业务属性限制，则联系相应的HLR修改用户业务数据，也可以通过增加业务检查配置（ADD SRVCHK）对特定呼叫字冠屏蔽呼出闭锁类业务的检查。ODB_BOIC用户和本地通用户不能拨打漫游在国外的本国用户请参考3. 。
3. BOIC、ODB_BOIC用户不能拨打漫游在国外的本国用户
【故障现象】
登记了BOIC、ODB_BOIC业务的用户（即用户没有国际长途权限）拨打漫游在国外的国内移动用户时，听到呼叫受限的提示音
【故障分析】
这种故障往往是对国外漫游号码分析数据错误造成的。根据数据配置要求应在呼叫字冠配置中对国外号码前缀“00”配置如下两条如下格式的数据：
号首集
呼叫字冠
……
被叫号码类型
0
00

PSTN

9
00

MSRN/HON
当MSOFTX3000取回漫游到国外的国内用户的漫游号码（如61xxxxxx）后，会自动再加上“00”前缀（如0061xxxxxx）， MSOFTX3000自动将号首集修改成9，然后继续查询呼叫字冠配置来匹配号首集为9的这一条来出局选路。
因此，为了使没有国际长途权限的用户以及本地通用户都可以拨打这些漫游到国外的用户，在号首集为9的记录对应的［被叫号码类型］就一定要配置为“MSRN/HON”。
【故障定位】
根据故障分析中的解释，查询呼叫字冠配置（LST CNACLD）修改相应的数据配置。
& 说明：
该故障的处理同样适用于当MSOFTX3000做关口局时，没有国际长权的本地固定用户无法拨打漫游在国外的本国用户故障。

4. 手机错误地设置了CLIR引起的主叫通话故障
【故障现象】
跟踪信令发现上报SETUP消息后，MSOFTX3000直接下发RELEASE_COMPLETE消息且RELEASE_COMPLETE消息原因值为“Facility not subscribed”。检查SETUP消息中包含“CLIR invocation”参数。
【故障分析】
出现这种信令流程，则说明用户使用的手机要求暂时激活了CLIR功能，但由于用户没有登记CLIR业务，因而根据协议不允许呼出。这类故障往往是一些NOKIA手机设置了“下一个呼叫不显示主叫用户号码”功能所致。
【故障定位】
告知用户呼叫失败原因，请用户修改设置，或者修改软件参数（MOD SFP）中呼叫内部参数3的BIT 3，将其设置为0。
5. 手机错误的设置了承载业务的引起的主叫通话故障
【故障现象】
跟踪信令发现上报SETUP消息后，MSOFTX3000直接下发RELEASE_COMPLETE消息且RELEASE_COMPLETE消息原因值为“bearer capability not authorized”or “bearer service not implemented”。
【故障分析】
出现这种信令流程，则说明用户在没有登记承载业务的情况下，将手机设置成使用该项业务。
【故障定位】
通知用户修改手机的相应设置。
6. A接口中继选路错误引起的主叫通话故障
【故障现象】
用户接口信令跟踪时发现MSOFTX3000在下发CALL_PROCEEDING后就直接下发RELEASE_COMPLETE消息，原因值为“无可用电路或通路”。
【故障分析】
这种故障往往是A接口在进行中继选路时出现错误引起的。MSOFTX3000中继选路的过程为MSOFTX3000根据DPC和NI和对端局类型查局向配置，得到局向号。然后再根据局向号查询中继群配置，得到中继群号，这时查询到的中继群不只一个。MSOFTX3000再通过电路池属性配置判断这些中继群中哪个中继群的承载能力最符合要求，并从此得到唯一的一个中继群号。最后，MSOFTX3000通过中继群号查询中继电路配置得到中继电路。MSOFTX3000还根据DPC和NI查询BSC配置得到BSC所在位置区号，再根据位置区号查询位置区小区配置得到呼叫源码。因而在出现这种故障时往往是上述配置中某一配置中相应数据设置错误造成的。
【故障定位】
查询局向表（LST OFC）、A接口中继群（LST AIETG）、A接口中继电路（LST AIETKC）、电路池属性（LST ACPOOL）以及查询BSC配置（LST BSC）和位置区小区配置（LST LAIGCI）中相应数据，并修改正确。
7. 信道指配失败引起的的主叫通话故障
【故障现象】
在进行用户接口信令跟踪时，发现以下现象：
(1) MSOFTX3000发送ASSIGN_REQ消息后收到ASSIGN_FAILURE；
(2) MSOFTX3000发送ASSIGN_REQ消息后，收到ASSIGN_COMPLETE消息，然后下发释放消息；
【故障分析】
出现上述指配不成功的现象主要是BSC和MSOFTX3000之间中继电路对接数据配置不一致引起的。常见的数据配置错误有：
(1) CIC配置不一致，如MSOFTX3000配置了某个CIC而BSC侧没有配置；
(2) 电路池属性配置不一致，如MSOFTX3000配置了EFR而BSC不支持；
【故障定位】
联系BSC侧，将MSOFTX3000和BSC侧A接口电路数据修改一致。
8. HLR寻址错误引起的上网故障
【故障现象】
跟踪用户接口发现以下现象：
(1) MSOFTX3000发送MAP_SEND_ROUTING_INFORMATION消息后收到MAP_P_ABORT_IND；
【故障分析】
由于主叫用户可以位置更新，所以如果是HLR寻址错误，则一般是用户所拨的号码MSISDN号段的E.164号段GT翻译出现错误，如将翻译的DPC配置成另一个HLR的DPC。如果GT数据配置正确，则要跟踪到HLR的信令链路或进行SCCP信令跟踪检查本端是否发送了MAP_SEND_ROUTING_INFORMATION消息，而对端局是否返回了UDTS消息。
【故障定位】
使用“LST SCCPGT”命令查询用户的E.164格式的GT码和用户归属HLR的HLR号的GT翻译情况并修改错误，并使用“TST SCCPGT”命令对GT码进行测试。如果是对端局返回UDTS消息，则首先检查发送的GT号码的正确性。如果发送的GT号码正确，则联系对端局处理。
& 说明：
如果MSOFTX3000收到MAP_SEND_ROUTING_INFORMATION ACK消息中中返回“呼叫闭锁”或“缺席用户”错误，则说明是因为被叫用户闭锁或被叫用户关机导致通话故障。

9. 号码分析故障导致移动主叫呼叫移动被叫故障
【故障现象】
主叫移动用户拨打某一特定移动用户号段时，呼叫失败，用户听到失败放音。对主叫用户进行用户接口跟踪时，发现用户取回漫游号码后，没有向对端局发送IAM/IAI消息，或发送的IAM/IAI消息中号码格式不符合局间约定。
【故障分析】
出现这种故障时，一般都是由号码分析数据配置不正确引起的。
由于在呼叫移动被叫过程中，MSOFTX3000要进行两次号码分析的过程，一次是根据被叫的MSISDN进行号码分析从而向HLR取漫游号码，而另一次是对取回的漫游号码进行分析，从而选择路由。
因而在检查固定被叫的号码、分析数据时需要针对用户所拨的号码，包括MSISDN号段、漫游号码号段和用户所在的BSC归属的位置区对应的呼叫源。
分别查询以下配置中的记录：
l BSC配置（LST BSC）
l 位置区小区配置（LST LAIGCI）
l 呼叫源配置（LST CALLSRC）
l 被叫号码预分析配置（LST CLDDNPREANA）
l 呼叫字冠配置（LST CNACLD）
l 号首处理配置（LST PFXPRO）
l 补充信令配置（LST AUSSIG）
l 主叫分析配置（LST CNACLR）
l 号码变换配置（LST DNC）中的记录
l 检查所作的号码变换是否合适，选择的路由是否正确。
l 然后在根据路由对应的中继群号，查询中继群承载索引（LST TGLDIDX）和相应的中继群承载配置（LST TGLD）是否正确。
常见的错误有：
(1) 针对MSISDN号段和MSRN号段做了两次重复的号码变换；
(2) 在号码分析中各处配置的号码变换之间有冲突；
(3) HLR返回的漫游号码格式不规范导致号码分析无法匹配到正确的记录；
(4) 和智能数据相冲突（如将普通号段当作智能用户号段进行配置）。
【故障定位】
根据出错的原因，修改相应的号码分析数据。对于HLR返回的漫游号码格式不规范导致号码分析无法匹配到正确的记录的错误，可以配置入局号码预分析（ADD INNUMPREPRO）数据，对呼叫来源为MAP的呼叫字冠进行规整变换。
10. 号码分析故障导致移动主叫呼叫固定电话故障
【故障现象】
主叫移动用户拨打某一特定固定用户号段时，呼叫失败，用户听到失败放音。对主叫用户进行用户接口跟踪时，发现MSOFTX3000在指配完成后没有向对端局发送IAM/IAI消息，或发送的IAM/IAI消息中号码格式不符合局间约定。
【故障分析】
出现这种故障时，一般都是由号码分析数据配置不正确引起的。
与呼叫移动用户相比，MSOFTX3000只进行一次号码分析的过程。
因而在检查移动被叫的号码分析数据时，只需要针对用户所拨的号码，固定用户号段以及用户所在的BSC归属的位置区对应的呼叫源，分别查询以下配置中的记录：
l BSC配置（LST BSC）
l 位置区小区配置（LST LAIGCI）
l 呼叫源配置（LST CALLSRC）
l 被叫号码预分析配置（LST CLDDNPREANA）
l 拨号检查（LST DALNOCHK）
l 呼叫字冠配置（LST CNACLD）
l 号首处理配置（LST PFXPRO）
l 补充信令配置（LST AUSSIG）
l 主叫分析配置（LST CNACLR）
l 号码变换配置（LST DNC）
l 检查所作的号码变换是否合适，选择的路由是否正确。
l 根据路由对应的中继群号，查询中继群承载索引（LST TGLDIDX）和相应的中继群承载配置（LST TGLD）是否正确。
常见的错误有：
(1) 拨号检查数据设置错误；
(2) 遗漏了对某些特服电话的字冠处理数据；
(3) 通配符使用不正确导致在查询表时没有匹配到正确的记录（在MSOFTX3000 SERVER的通配符匹配方式是：首先用具体的字冠和其它具体的索引字段的内容来查询配置，如果找不到匹配的记录，就从左到右依次将有通配符的字段用通配换掉，再重新查找）；
(4) 对于呼叫源表中的预收号长、呼叫字冠配置中的最大号长、最小号长和中继群承载设置的中继占用点设置错误；
(5) 号码分析中的失败处理数据设置不正确；
(6) 在号码分析中各处配置的号码变换之间有冲突。
【故障定位】
根据出错的原因，修改相应的号码分析数据。
2.3.4 故障处理
以下详细介绍如何利用信令跟踪和异常流程与正常流程的对比来对具体故障进行定位。
1. IAM/IAI消息中主、被叫号码错误引起的信令配合故障
【故障现象】
对失败呼叫进行信令跟踪并与正常信令流程的消息进行对比，发现IAM/IAI消息中主、被叫号码不符合局间约定。
【故障分析】
主、被叫号码不符合局间约定的常见的错误有：
(1) IAM/IAI消息中缺少主叫号码；
(2) IAM/IAI消息中主叫号码的地址性质与号码格式不一致（如主叫号码为长途区号+用户号码，地址性质却为用户号码）；
(3) 发送的被叫号码不全。
【故障定位】
当本局为IAM/IAI消息的发送方：
(1) 出现错误(1)：修改补充信令配置（MOD AUSSIG），将［是否发主叫号码］设置为“是”；
(2) 出现错误(2)：检查主叫分析配置（LST CNACLR）或中继承载设置（LST TGLDIDX、LST TGLD），使其对主叫号码进行相应的变换；
(3) 出现错误(3)：检查呼叫字冠配置（LST CNACLD）中［最大号长］是否设置过短并修改成合适的值。
当本局为IAM/IAI消息的接收方：
l 出现错误(1)：，修改补充信令配置（MOD AUSSIG），将［是否发A6］设置为“是”；
l 出现错误(2)：联系对端局进行处理或增加被叫号码预分析配置（ADD CLDDNPREANA）或呼叫字冠配置（ADD CNACLD）对主叫号码进行相应的变换；
l 出现错误(3)：联系对端局进行处理。
& 说明：
l 由于某些型号的交换机不能处理主叫号码的地址性质为国际号码的国际呼叫，因此当本局要向这些交换机发送国际呼叫时，需要将主叫号码地址性质改为国内号码。
l 由于某些型号的交换机在ISUP信令方式下不能处理包含超过16位的被叫号码的IAM消息，而MSOFTX3000一次IAM消息允许最大发送24位被叫号码，因此当出现这种情况时，需要将该局向的中继群配置中［一次发码最大长度］配置成16。

2. IAM/IAI消息中主叫用户类别错误引起的信令配合故障
【故障现象】
对失败呼叫进行信令跟踪并与正常信令流程进行对比，发现对端局发送的IAM/IAI消息中主叫用户类型设置错误。
【故障分析】
根据MTUP规范规定MSOFTX3000收到的IAI、IAM中的主叫类别只有11种，如表2-3所示。MISUP规范与MTUP规范关于主叫用户类别的规范基本一致，仅增加了主叫用户类别表示语为0时表示主叫用户类别为未知。当对端局发送的主叫用户类别不在规范规定的范围内，交换机就会发送CFL/REL命令进行拆线。
表2-3 MTUP规范规定的主叫用户类别
比特
FEDCBA
主叫用户类别
说明
001001
国内话务员（无插入性能）

001010
普通用户
只从MSOFTX3000、TS或INTS接受到此类别
001011
优先用户
001100
数据呼叫

001101
测试呼叫

010000
普通、免费

010001
普通、定期

010010
普通、用户表、立即
只从LS/Tm接受到此类别
010011
普通、打印机、立即
010100
优先免费

010101
优先定期

【故障定位】
出现这类故障时，要求对端局修改相应的主叫用户类别即可。
3. IAM/IAI消息中消息表示语引起的信令配合故障
【故障现象】
对失败呼叫进行信令跟踪并与正常信令流程进行对比，发现本局发送的IAM/IAI消息中设置了对端局不能识别的某些消息表示语。
【故障分析】
当信令为MTUP信令时，IAI消息中常见的不能识别的消息表示语包括去话回声抑制器表示语、信号通路表示语、电路和性质表示语。在规范中这些消息表示语定义如下：
l 比特 G：去话回声抑制器表示语（该表示语也用于回声抵消器）
0 未包括去话半回声抑制器
1 包括了去话半回声抑制器
l 比特 K：信号通路表示语
0 任何通路
1 全部是NO.7信号方式通路
l 比特 DC：电路和性质表示语
00 在接续中无卫星电路
01 在接续中有卫星电路
10 备用
11 备用
当信令为MISUP信令时，IAM消息中常见的不能识别的消息表示语为回声控制装置表示语，定义如下：
l 比特 E：回声控制装置表示语
0 未包括去话半回声抑制器
1 包括了去话半回声抑制器
【故障定位】
出现上述问题，如对端局不能解决，则需要修改软件参数（MOD SFP）对相应的比特进行过滤。
对于TUP信令，修改软件参数（MOD SFP）中的“IAM过滤器”对应比特位置为0即可进行过滤。对应关系为bit2和bit3对应比特DC，bit6对应比特G，bit11对应比特K。

对于ISUP信令，要过滤比特 E需要将“IUSP测试参数6”bit6置为0、“IUSP测试参数5”bit13置为0。
& 说明：
屏蔽回声抑制器表示语的一个更常用的方法是在七号中继群配置中将“是否使用EC信令”标志设置为“否”。

4. ACM消息中消息表示语错误引起的信令配合故障
【故障现象】
在用户状态正常的情况下，对用户进行用户接口跟踪。发现本局回送ACM消息后，发送CFL消息直接拆线，经与正常ACM消息进行对比，发现本局回送的ACM消息中设置了对端局不能处理的某些消息表示语。
【故障分析】
当信令为MTUP信令时，ACM消息中常见的不能识别的消息表示语包括来话回声抑制器表示语和信号通路表示语。在规范中这些消息表示语定义如下：
l 比特D：来话回声抑制器表示语（也适用于回声抵消器）
0：未包括来话回声抑制器
1：包括来话半回声抑制器
l 比特 F：信号通路表示语
0 任何通路
1 全部是NO.7信号方式通路
【故障定位】
出现上述问题，如对端局不能解决，则需要修改软件参数（MOD SFP）中参数“ACM发送过滤器”将相应的比特位置0。bit3对应比特D、bit5对应比特F。
& 说明：
屏蔽回声抑制器表示语的一个更常用的方法是在七号中继群配置中将“是否使用EC信令”标志设置为“否”。

5. 接收局网络侧故障引起的信令配合故障
【故障现象】
对失败呼叫进行用户接口跟踪，发现对端局向本局发送正确的IAI/IAM消息后，本局回送UBM/REL消息，进行拆线。
【故障分析】
出现这种情况，如果被叫用户空闲、中继状态正常，则是一般本局数据配置有问题，当本局返回的UBM消息为ADI/UNN/CFL消息（或REL消息的拆线原因值为无效的号码格式、未分配的号码等）一般是号码分析的问题，如果本局返回CGC消息（或REL消息的拆线原因值为无电路可用）则一般是中继路由数据问题。
号码分析数据的检查可以根据接收到的IAI/IAM消息中的主、被号码和中继群设置的呼叫源查询呼叫源配置（LST CALLSRC）、被叫号码预分析配置（LST CLDDNPREANA）、拨号检查（LST DALNOCHK）、呼叫字冠配置（LST CNACLD）、号首处理配置（LST PFXPRO）、补充信令配置（LST AUSSIG）、主叫分析配置（LST CNACLR）、号码变换配置（LST DNC）、“路由分析表”（LST RTANA）检查所作的号码变换是否合适，选择的路由是否正确。
对路由中继数据的检查，是跟据号码分析后选择的路由号查询路由配置（LST RT）、子路由配置（LST SRT）、局向配置（LST OFC）、中继群配置（MOD N7TG）、中继电路配置（LST TKC），以检查是否MSOFTX3000能够正确的选路。
故障定位】
根据数据检查的结果，修改错误的数据。
2.4 移动被叫的故障分析与定位
2.4.1 故障判定标准
移动被叫故障的标准为：在被叫用户状态正常时，对用户进行接口跟踪。如果本局在收到对端局发送的以本局漫游号码为被叫号码的IAM/IAI消息后，能够对在服务区内的空闲被叫完成寻呼、呼叫接入、TCH指配等被叫流程的各个阶段，则说明移动被叫通话正常，否则说明移动被叫通话故障。
2.4.2 故障分析
在进行被叫用户故障排除前，应当确认用户位置更新是否正常、移动用户做主叫是否正常，否则应参照2.2 、2.3 进行相应的故障处理。
在MSOFTX3000运行正常时，移动