MG003302 SCCP信令分析与处理ISSUE11.docx

资源描述

MG003302 SCCP信令分析与处理ISSUE11.docx

《MG003302 SCCP信令分析与处理ISSUE11.docx》由会员分享，可在线阅读，更多相关《MG003302 SCCP信令分析与处理ISSUE11.docx（16页珍藏版）》请在冰豆网上搜索。

MG003302 SCCP信令分析与处理ISSUE11.docx

MG003302SCCP信令分析与处理ISSUE11

MG003302

SCCP信令分析与处理

ISSUE1.1

华为技术有限公司

课程说明1

课程介绍1

课程目标1

相关资料

第1章SCCP数据配置

1.1SCCP数据表间关系及数据配置

相对于MTP和TUP，SCCP的数据表比较简单，表的个数也比较少，总共只有四张表：

SCCP目的信令点表、SCCP子系统表、GT码翻译表、新GT表。

下面我们以移动交换中心MSC到HLR取漫游号码和HLR返回漫游号码给MSC为例说明SCCP表间关系，本局为MSC。

MSC到HLR取漫游号码：

首先查询GT码翻译表，在该表中应该有本局MSC的一条GT数据，把该条数据作为取路由信息这条消息的主叫地址，同时根据被叫的GT数据，匹配相应的记录，如果该条记录翻译类型为DPC+OLDGT，则取得下一目的信令点的DPC，再查询SCCP目的信令点表，看该DPC是否是合法的DPC（主要看该DPC在SCCP目的信令点表中是否配置、是否有效），如果配置且有效，则到MTP层选路出局，否则失败。

如果匹配到的记录翻译类型为DPC+SSN，则取得下一目的信令点的D_PC，同时用该记录中的SSN替换原来GT地址信息中的SSN，再查询SCCP目的信令点表和SCCP子系统表，如果该DPC和SSN都是合法的DPC和SSN（主要看该DPC和SSN在相应表中是否配置、是否有效），如果配置且有效，则到MTP层选路出局，任何一个表未配置，都将失败。

如果翻译类型为DPC，查表和处理顺序同翻译类型为DPC+OLDGT，只是取得的DPC不同而已。

HLR返回漫游号码：

在MTP层把该条消息收下来后，首先判断该条消息的寻址方式，如果该条消息是以DPC+SSN寻址，则不到GT码翻译表中做GT翻译（不查询GT码翻译表），而是直接查询SCCP子系统表，看相应的子系统是否有效，如果有效，则把消息送到相应的子系统进行处理，否则出错。

如果寻址方式为DPC+GT寻址，则首先到GT码翻译表中做GT翻译（查询GT码翻译表），匹配到本局的GT数据（本局GT数据只有一条，而且只能翻译成DPC），然后再查询SCCP子系统表，看相应的子系统是否有效，如果有效，则把消息送到相应的子系统进行处理。

下面我们一一讲述这几张表。

1.1.1SCCP目的信令点表

1、说明

定义与本局有信令关系的（直连或准直连）的目的信令点。

与［MTP目的信令点表］一样，只需做MTP层能够看得到的，而且需要传递SCCP目的信令点数据。

待加入［SCCP目的信令点表］中的SCCP目的信令点一定要在［MTP目的信令点表］中有描述，但在［MTP目的信令点表］中描述的MTP目的信令点并不一定都要加入［SCCP目的信令点表］中。

例如在MSC数据配置中，［MTP目的信令点表］中描述的对端PSTN局的MTP目的信令点就不需加入到［SCCP目的信令点表］中，而描述对端HLR局、对端其他MSC局的MTP目的信令点则必须加入到［SCCP目的信令点表］中。

2、注意事项及技巧

需要注意的是在配置数据的时候有人喜欢将本局信令点也加入SCCP目的信令点表中，这样做是错误的，因为SCCP目的信令点表中应该配置的是远端信令点的数据，而本局信令点应该在本局信息表中配置。

在MSC60已经不能将本局信令点加入SCCP目的信令点表中。

在SCCP目的信令点表中有一个域是备用DPC索引，该域主要用于指示本信令点的负荷分担信令点的索引。

一个简单的例子如下图：

C和D是STP，A到C和D必然是负荷分担的，因此在配置SCCP目的信令点表的时候，配置目的信令点C的时候将其备用DPC索引设置为D的索引，另外将D的备用DPC索引设置为C的索引。

另外有一个域是是否动态负荷分担标识，该域主要是表示本信令点的负荷分担信令点之间的关系，现在有主备用和动态负荷分担两种。

主备用是指主用不可达，才走备用；动态负荷是指在两个信令点之间动态负荷分担。

图1-1SCCP信令点负荷分担模型

1.1.2SCCP子系统

1、说明

SCCP子系统表中的子系统号码SSN是SCCP使用的本地寻址信息，用于识别一个节点中的各个SCCP用户，如GSM系统中的各个组成部分的子系统号分别为：

MSC：

8、VLR：

7、HLR：

6、BSS：

fe。

注1：

SCCP管理、ISDN用户部分、操作维护管理部分（OMAP）、MAP应用部分、归属位置登记处（HLR）、拜访位置登记处（VLR）、设备识别中心（EIR）、认证中心（AUC）、移动交换中心（MSC）、CAP应用部分（CAP）、BSSAPA接口、BSSAP+Gs接口、BSSO&MA接口、gsmSCF_SSN、SGSN_SSN、GGSN_SSN。

2、注意事项及技巧

首先需要注意的是和SCCP目的信令点表不同，SCCP子系统表不仅需要配置远端信令点的子系统，而且需要配置本局的子系统，例如在MSC上一般就需要配置MSC、VLR、SCMG及CAP子系统。

同时在增加SCCP子系统的记录时，系统需要判断目的信令点是否在"SCCP目的信令点"中存在，如果不存在，表示是一条非法的记录。

需要注意的还有相关子系统，配置相关子系统的含义是指该子系统状态变化的时候通知我们配置的子系统，例如：

我们配置本局MSC子系统的相关子系统为本局VLR子系统，那么当MSC的状态有变化时，SCCP将通过N_STATE_IND原语通知VLR关于MSC子系统状态的变化，现在一般不配置该域。

在SCCP子系统表中最后一项是备用子系统索引，该项和SCCP目的信令点中的备用DPC索引有一定的区别。

在SCCP目的信令点中的备用DPC和主用DPC不是纯粹的主备关系，实际上还有负荷分担的作用，如下图，在A的SCCP目的信令点中配置目的信令点C的备用子系统为D的话，在C和D都正常的时候，那么发向C的消息将有一半被负荷分担到D；如果C不可达，D可达的情况下，所有消息将发送到D；如果C可达，D不可达的情况下，所有消息将发送到C。

在SCCP子系统表中的备用子系统是纯粹的主备用关系，例如在A的SCCP子系统表中配置子系统C（SSN1）的备用子系统为D（SSN1），在C（SSN1）正常的情况下，所有消息将发送到C（SSN1）；只有在C（SSN1）不正常，D（SSN1）正常的情况下，消息才发送到D（SSN1）。

图1-1SCCP子系统主备用模型

1.1.3GT码转换表

1、说明

该表用于将GT翻译成由DPC、SSN、OLD_GT或NEWGT等不同组合而组成的新地址。

注1：

2、注意事项及技巧

需要注意的是：

［子系统表］中的DPC和［GT码表］中的DPC如果不是本局信令点，则在［SCCP目的信令点表］中必须是有效值，如果是本局信令点，则必须在[本局信息表]中为有效值，［GT码表］中的子系统在［子系统表］中也必须是有效值。

值得注意的是对于一个GT码只能做一个GT翻译数据，经常有一种错误配置，对于同一个GT码配置了三条GT翻译数据，分别对应不同的翻译结果。

例如对于如下的GT码：

8613642356678，GT表示语、编号计划等域都相同，但做了三条数据，分别翻译到：

DPC+VLR，DPC＋MSC，DPC＋SCMG。

这种数据配置是错误的，实际上根据SCCPGT的翻译原则，SCCP只会将该GT翻译到一个结果上，也就是说这三条数据中只有一条数据起作用，具体哪一条数据起作用，与数据设定的顺序有关。

但这样配置造成数据混乱，而且影响查问题的效率。

现在MSC一般都有两个用户MAP和CAP，但MSC只有一个GT码，即MSC号，那么现在我们就有一个问题，从远端来一条消息，该消息所带的GT码就是MSC号，如果该消息的寻址方式是根据GT码寻址的话，由于一个GT只能有一种翻译结果，如果翻译成DPC＋SSN的话，该SSN只能是MAP和CAP中的一种，那么我们如何判定该消息应该送给MAP还是CAP呢？

在这种情况下，一般是这样的，被叫地址中的地址形式都是SSN+GT，我们在做GT翻译数据的时候，要将这个GT翻译成DPC（不是DPC+SSN），那么我们会将该GT翻译成DPC，并从被叫地址中取SSN（如果翻译成DPC+SSN的话，SSN是从GT翻译表的SSN域中取的），这个SSN是消息带的，可能是MAP，也可能是CAP，这样的话我们就可以将消息正确地送给相应的用户了。

另外一个需要注意的地方是，在多信令中由于多信令选择SLS的需要，要求在本局必须配置本局的GT码翻译数据，例如：

本局有两个信令点OPC1，OPC2，对应的GT码分别是GT1，GT2，那么在GT码翻译表中必须配置GT1和GT2的翻译数据。

如果没有配置本局GT，那么消息肯定是发送不出去的。

1.1.4新GT表

1、说明

在GT码翻译表中有一个新GT索引域，如果该GT的翻译结果是DPC+NEWGT的话，在进行GT翻译后将用本表的GT码代替原地址中的GT。

因此该表定义本局GT翻译出的新GT码的内容。

2、注意事项及技巧

现在网上对该表的未使用，一般无需配置。

1.2常见的错误的SCCP数据配置

在SCCP层的数据配置中，常见的错误数据有下面一些：

1、SCCP目的信令点表中配置本局的信令点数据。

因为该表主要是在本局信令点向远端目的信令点发送SCCP消息时需要查询，而本局接受来自远端目的信令点发送的SCCP消息时并不查询该表。

2、SCCP目的信令点表中“负荷分担信令点索引”配置错误或者是有SCCP信令消息需要进行负荷分担时没有配置该域，导致不能进行SCCP消息进行动态负荷分担。

3、SCCP子系统表中不配置本局的信令点数据。

或者当本局是做VMSC时，只配置本局信令点编码为国内网编码的数据，未配置本局信令点编码为国内备用网编码的数据。

因为该表在本局信令点向远端目的信令点发送SCCP消息和本局信令点接受来自远端目的信令点发送的SCCP消息时都需要查询该表。

4、GT码翻译表中对于同一样的GT内容做多条数据，导致事故的发生。

特别是针对本局，配置多条数据。

第2章故障案例分析

2.1GT码翻译表中本局数据配置错误导致电话不通

【故障现象】

某局进行升级，升级以后出现如下现象：

1、固定电话拨打本地手机正常接通。

2、固定电话拨打外省手机用户全部不能接通。

3、固定电话拨打本省其他地区的手机用户部分地区可以接通，部分地区不能接通。

【故障原因分析】

工程师Z对用户进行接口跟踪，发现固定电话拨打外地手机不能接通时，本GMSC向HLR发出SRI信息取漫游号码，但是一直没有对方发来的SRIACK的消息，导致本端超时释放，呼叫接续失败。

根据此现象，工程师Z初步认定问题出在对方的HLR上没有做我们MSC的数据或者本省的HSTP没有作本局的数据，导致呼叫不通。

为了进一步定位是否为对方HLR的问题，在外省B地我司的HLR对某一用户进行用户接口跟踪，使用A地的固定电话拨打该用户，发现B地的HLR收到GMSC发来的SRI消息，而且HLR也正确的返回了SRIACK消息。

据此，工程师Z判断为本省的HSTP数据作错，没有将信令发回到A局的GMSC上。

要求A地局方协调HSTP检查数据。

HSTP认为在A局升级前后，他们没有修改过数据，因此认为自己没有问题，认为是我们的接口跟踪有问题。

局方在HSTP到GMSC的链路上进行挂表测试，发现HSTP已经将SRIACK消息发送到GMSC。

分析到这一步，HSTP已经把消息发到我们GMSC，应该是我们GMSC由于数据配置的原因导致这些消息收不下来，问题应该出在GT码翻译表，仔细检查GT码翻译表，发现关于本局的GT码在GT码翻译表中的配置如下表所示：

A局的GT码翻译表如下配置：

（本局信令点为1BFF11）

序号

GT码

翻译类型

DPC

SSN

其他

8613900755

DPC+SSN

1BFF11

MSC

8613900755

DPC+SSN

1BFF11

SCCP管理

到此，原因很明显，是由于对本局的GT数据配置错误，导致当送到本局的SCCP消息是以GT寻址时，本局不能对该消息进行正确的分析，致使该消息处理错误，导致呼叫失败。

在前面的数据配置中我们也详细分析的HLR返回漫游号码的查表顺序。

本地因为GMSC与HLR是直连的，所以是以DPC+SSN寻址，所以呼叫可以接通。

外省HLR与本GMSC都是以GT寻址的，所以外省的呼叫都不能接通。

本省外地的HLR与本GMSC部分以DPC+SSN寻址的就可以呼叫成功，而以DPC+GT寻址的，则呼叫失败。

【故障处理过程】

将第二条数据删除以后，用固定电话拨打外地手机用户，可以正常接通。

问题：

本案例中的局点为GMSC，可以只做第一条数据，如果本局是端局MSC，则应该如何配置GT翻译表中本MSC号的GT数据？

为什么？

2.2由于MSC的GT翻译数据错误导致新割接HLR所属用户无法在某MSC漫游

【故障现象】

某地省会城市新割接一个HLR3，割接后有用户投诉该HLR3中的用户漫游到某地MSC无法位置更新上网。

【故障原因分析】

对于漫游故障，一般来说是GT翻译等数据配置错误所导致，另外由于是新割接的HLR，很可能是某个信令节点的数据错误导致。

首先询问省会HSTP和新割接的HLR3机房，要求检查数据，对方答复数据正确无误，下面对我们自己的数据进行分析。

首先对无法做位置更新用户对应的IMSI号段数据进行了GT翻译测试，MSC能够正确的将其翻译到新割接HLR3。

为了进一步查明原因，对链路进行了信令跟踪，找到了该用户位置更新的信令：

1、首先MSC能够根据用户的IMSI正确翻译到新HLR3去取鉴权集，HLR3也正确将鉴权集送回；

2、VLR在对手机进行鉴权并通过后，根据IMSI向HLR3发出位置更新请求；

3、HLR3向VLR插入用户数据，VLR回插入用户数据证实消息；

4、信令进行到这一步，按说应该是完全正确的，但接下来的消息却错了：

本来应该是HLR回位置更新证实消息的，对方却回了一条Abort消息，原因为unrecognizedTransactionID；同时链路上还有一条HLR3回的END消息，内容为systemfailure。

5、为什么同一个位置更新请求会有同时两个HLR回消息呢？

经过仔细检查，发现MSC给HLR发的位置更新请求消息的目的地址为**FF60，而位置插入用户数据证实的目的地址却为**FFC0，其中**FF60为新割接的HLR3信令点，**FFC0为原来HLR2的目的信令点；该省省内采用DPC寻址方式。

这下原因查到了，是MSC对HLR3ID的GT翻译错了，本来该送到HLR3的信令送到了HLR2去，结果HLR2回了条未识别的对话ID消息，HLR3等插入用户数据证实超时回了条系统失败的消息；在做GT翻译测试时没有做HLR3的ID号的GT翻译，所以没有及时查出问题。

下面是两个HLR回的消息。

ABORT

DestinationTransactionID（Hex）:

3908405BA

reason

AbortCause:

1=unrecognizedTransactionID

END

DestinationTransactionID（Hex）:

390805BA

Component

ReturnError

InvokeID:

ErrorCode

LocalValue:

34=SystemFailure

【故障处理过程】

在本局GT码翻译表中，把HLR号码对应的GT翻译数据的目的信令点编码修改为HLR3的信令点编码。

2.3国际漫游用户无法上网

【故障现象】

某地端局调测时，发现一国际漫游用户无法上网。

跟踪用户接口消息，发现A接口有消息：

LOCATION_UPDATING_REJECT，拒绝原因：

网络故障。

该端局接该地两个平面STP到国际局。

【故障原因分析】

首先做该无法漫游用户的IMSI号段GT翻译测试和HLR号码的GT翻译测试，都是正常的，于是进行信令链路跟踪，跟踪的信令如下：

>SCCPNAT1362800eFF0D80FF0D940A01030D170A520700120468310020260A1206001204042900100314651248045C0409F649034D00FD6C05A2030201D9

第一条消息是该MSC位置更新回应插入用户数据的证实消息（sccpUDT消息），而第二条是信令点为FF0D80的STP发回来的出错返回消息（sccpUDTS消息），出错原因为01（无法翻译这种地址），说明该MSC发出的消息到了STP，只是STP没有配置到国外的GT数据，因此消息出不去，被返回！

具体消息解释：

09（SCCPUDT消息）

81（有序传送，出错返回）

030D17（地址、数据偏移指针）

0A12060012040429001003（被叫地址）

0A12070012046831002026（主叫地址）

14651248045C0409F649034D00FD6C05A2030201D9（SCCP用户数据）

>SCCPNAT1362800eFF0D80FF0D94

0A（SCCPUDTS消息）

01（返回原因：

无法翻译这种地址）

030D17（地址、数据偏移指针）

0A52070012046831002026（被叫地址）

0A12060012040429001003（主叫地址）

14651248045C0409F649034D00FD6C05A2030201D9（SCCP用户数据）

从以上信令链路跟踪消息来看，是该MSC收到HLR的插入用户数据消息，然后根据HLR号向HLR发插入用户数据证实消息的时候，等待HLR的位置更新响应超时。

从各种情况的分析来看，可能是该MSC设备的定时器过短，或者STP寻址不到HLR。

1、VLR->HLR，使用IMSI转换为GT寻址（位置更新请求），正常；

2、HLR->VLR，根据VLR号寻址（插入用户数据），正常；

3、VLR->HLR，根据HLR号寻址（插入用户数据响应），应该已发送出去，但HLR是否收到不能确定，应该没有收到，因为MSC发给STP，STP直接给MSC回了出错消息。

联系STP，是否数据做错，经过证实，的确是STP的数据没有做全！

【故障处理过程】

要求STP局把相应的数据做全。

2.4手机不能上网的问题的总结

2.4.1手机上网的流程

图2-1位置更新流程图

2.4.2会造成手机无法上网的数据配置

1.MSC-MAP层未做IMSI-GT数据

MAP会根据BSC送来的手机的IMSI号，将它进行转换。

比如IMSI为460001234567812，则MAP将IMSI转换为GT数据000471046831193254761802，通过GT到HLR寻址；MAP层要配置一条IMSI--GT数据：

46000-----86139。

转换成的GT是E.214编码的。

案例：

某一手机无法上网：

●现象

（1）MSC的A接口发现位置更新请求到达了MSC，MSC没有发送位置更新请求该HLR。

●分析

（1）另一用户A可以正常上网，基本上BSC、MSC、HLR都没有问题，只是用户B的IMSI的相关数据没有做。

（2）MSC观察的A接口有数据，查看MSC的IMSI-->GT的翻译表是否有相关的IMSI的数据，果然没有。

●结果

在IMSI-->GT的翻译表中增加相关的数据，则用户B也可以登记上网了。

2.SCCP子系统数据未配置

与上网有关的MSC侧SCCP子系统要配置本局的MSC、VLR子系统，要配置HLR的子系统HLR。

HLR侧SCCP子系统要配置MSC的MSC、VLR子系统，要配置本局的子系统HLR。

案例：

某一手机无法上网：

●现象

（1）从MSC看（MSC的人远端调测），该用户的位置更新消息往HLR发送了，但没有接收到HLR的插入用户数据；

（2）从HLR的D接口看，HLR已经将插入用户数据发送给MSC，一段时间后，超时“远端没有响应”

●分析

（1）从D接口查看插入用户数据已经发送，所以问题原因不是HDB，而是前置机。

在前置机中，也不是MAP层，而是在MAP层以下。

（2）再查看No.7信令链路的SCCP消息有没有发送。

结果：

没有，HLR没有将信令发送出去。

（3）信令没有发送，再查看HLR到MSC的信令链路是否是正常的，可以从HLR维护台查看。

结果：

正常，HLR与MSC之间的No.7信令链路没有问题。

●原因

显然，在HLR前置机中，信令没有从MAP层到达No.7的SCCP层。

基本上可以确定是SCCP相关的数据没有配置。

查看SCCP相关的4个表，果然没有配HLR到MSC的数据。

数据增加如下：

SCCP远端信令点表中增加MSC的数据。

SCCP子系统表（原来没有MSC的数据）增加MSC、VLR的子系统。

●结果

用户A现在可以上网了。

3.SCCP-GT数据未配置

与上网有关的MSC侧GT数据要配置：

MSC本

展开阅读全文