MTP问题定位方法--超级有用.doc

MTP问题定位方法1. 消息跟踪系统提供的接口跟踪“MTP3”功能，是定位MTP问题的重要手段，可以跟踪MTP上层用户消息、测试消息、路由管理消息以及MTP二、三层之间的命令。MTP消息跟踪结果如图5-4所示。图5-4 MTP消息跟踪结果图5-4中，消息前加“”（黑色）表明是从此链路上收到的MTP消息，消息前加“”（蓝色）表明是从此链路上发送的MTP消息。选中某一条消息，按键或用鼠标左键双击，可查看此消息内容的详细解释。表5-5 MTP消息跟踪结果说明类型说明参数解释MTP2消息SIO为“MTP_L2_CMD”或“MTP_L2_REPORT”的消息是MTP二层和三层之间的命令或响应，一般只在链路中断、链路的定位过程或对信令链路进行统计时才会产生，这类消息是分析断链原因和定位失败原因的重要依据。TimeStamp：时间指示；SIO：消息类型，是MTP二层的命令（MTP_L2_CMD）还是MTP二层的响应（MTP_L2_REPORT）；Hex SigMsg：命令或响应参数。MSU信令链路上接收或发送的消息信令单元。TimeStamp：时间指示；SIO：业务指示，其中信令链路测试消息用TEST表示，MTP部分的信令网管理消息用MTP表示，TUP、ISUP、SCCP等的消息分别用TUP、ISUP、SCCP等表示；NI：网络指示，NAT表示国内网，INT表示国际网等；TICKS：消息产生的时间，单位是10毫秒；H1H0：指消息的标题码，标识具体的消息；CIC、SLS/SLC：对TUP、ISUP消息是电路识别码（CIC），对MTP消息是信令链路编码（SLC），对SCCP消息是信令链路选择码（SLS）；OPC、DPC：源信令点编码、目的信令点编码；Hex SigMSg：此消息的具体内容。2. 状态查询表5-6 MTP状态查询命令命令说明备注DSP N7LNK查询MTP链路状态正常状态为“In Use, Healthy”DSP N7DLNKDSP N7LSLNKDSP N7DSP查询MTP目的信令点状态正常状态为“Accessible”DSP N7RT查询MTP路由状态正常状态为“Healthy, In Service”DSP COMM查询板间通讯状态正常状态为“Normal”DSP PORT查询E1端口状态正常状态为“Normal”3. 自环测试表5-7 自环测试命令命令说明备注STR MTP2LNKLB启动MTP2自环用于MTP链路软件自环，可以测试链路的收发是否正常。下发自环命令后，如果能从链路跟踪窗口上看到有测试消息的收发，说明本端链路收发正常。STP MTP2LNKLB停止MTP2自环DSP MTP2LNKLB查询MTP2自环状态STR PORTLOP启动E1端口自环用于E1端口自环，可以测试底层硬件消息收发是否正常。STP PORTLOP停止E1端口自环5.3.4 MTP常见问题处理1. MTP链路正常，但是MTP目的信令点不可达(1) 故障现象用DSP N7LNK查询到某个目的信令点的链路状态正常，但是用DSP N7DSP查询MTP目的信令点状态为不可达。(2) 原因分析到某个目的信令点的链路状态正常，但是目的信令点不可达，一般是MTP路由没有配置或者配置不正确所致。另外，如果到某个信令点的路由经过STP转接，则还需要检查STP到该目的信令点是否可达。(3) 故障处理用LST N7RT查询到该目的信令点的路由，如果不存在，则需要增加到该目的信令点的路由。如果有到该目的信令点的路由，但是链路集索引不是到该目的信令点的链路集，而是到STP的链路集（迂回路由），则检查STP到该目的信令点是否可达。如果不可达，检查STP到该目的信令点的数据配置是否正确。2. MTP链路无法建立(1) 故障现象配置好数据后，MTP链路无法建立。(2) 原因分析导致无法建链的原因很多，包括：数据配置不正确、板间通信中断、传输误码过高等。通常，应先检查数据配置，之后检查单板状态、板间通信状态及EPI端口状态，同时查看是否有误码过高告警或者滑帧告警。最后，可以利用MTP消息跟踪功能，对MTP2层消息进行分析。(3) 故障处理如果是刚配置的链路无法建链，很有可能是数据配置错误，在这种情况下应逐项检查以下数据： 检查E1端口的收端、发端是否和对端的发端、收端对应，如果收端连接对端的收端，发端连接对端的发端，或者收发两端的E1不是同一个E1端口，则需要重新连接。 链路时隙和对端所用的时隙是否一致，如果是2M链路，还需要检查两端的时隙数是否一致。如果时隙不一致，需把链路删除后重新配置。 本端的链路编码和链路编码发送和对端是否一致。如果不一致，需把链路删除后重新配置。 本端和对端是否有一端使用卫星链路，两端必须保持一致。如果不一致，用MOD N7LNK修改卫星链路标记。 检查本端链路的目的信令点是否为对端的信令点编码，检查对端链路的目的信令点是否为本端信令点编码。如果不一致，需把链路删除后重新配置目的信令点、链路集、路由、链路。 用LST OFI检查本端信令点所处的网络标识（NI）以及信令点编码结构（24位编码或者14位编码）是否和对端一致。如果不一致，需要用SET OFI重新配置本局信息（或者要求对端修改）。注意，修改本局信息后，必须重启单板。l 用LST EPICFG检查E1端口配置是否完全，工作模式是否和对端一致（平衡模式：120欧姆；非平衡模式：75欧姆）。确信数据配置无误后，用DSP FRM查询单板状态：l 检查前插板的状态，如果是FAULT，复位前插板。l 检查EPI板的状态，如果是FAULT，复位后插板。l 检查所使用的扣板的状态（03号E1使用下扣板，47号E1使用上扣板），如果状态是FAULT，复位扣板。若单板状态正常，检查板间通信状态及EPI端口状态：l 用DSP COMM命令检查前插板和扣板间的通信状态，“DSP COMM: FN=0, SN=15, COMT=CPCI, CPCI=21;”，其中CPCI字段输入21表示查询下扣板的通信，输入22表示查询上扣板的通信。l 用DSP PORT命令检查EPI端口状态，“DSP PORT: FN=0, SN=15, PT=E1, PN=0;”。如果状态不是“NORMAL”，检查E1线缆和插头是否连接正确；如果状态是“Signal bit loss”，应该检查时钟是否已经和对端同步。此外，还应查看告警窗口，如果有误码过高的告警或者滑帧告警，查看传输是否正常，并请硬件维护人员协调解决。数据和环境检查无误后，如果仍然无法建链，可以打开“MTP3”接口跟踪，选择跟踪MTP2层消息，以定位故障原因。5.3.5 SCCP/TCAP问题定位方法1. 消息跟踪SCCP和TCAP模块提供了丰富的接口跟踪功能，如表5-8所示。遇到问题时，打开各层的跟踪，可以迅速定位出消息在哪一层丢失或者返回。所有跟踪都有消息解释功能，可以方便地得到消息出错、返回等原因。表5-8 SCCP消息跟踪跟踪功能说明备注SCCP DPC跟踪指定信令点的SCCP与底层交互消息信令点由输入参数NI、DPC、OPC决定SCCP User跟踪SCCP和其上层用户（如TCAP、BSSAP和RANAP）交互的原语SCCP MTP MG跟踪底层发送到SCCP的管理原语，包括：信令点禁止、信令点允许等。TCAP SCCP跟踪TCAP和SCCP之间交互的原语TCAP User跟踪TCAP和上层用户交互的原语2. 状态查询表5-9 SCCP状态查询命令命令说明备注DSP SCCPDSP查询SCCP目的信令点状态正常状态为“Allow”，表明到该信令点的通信正常；如果状态是“Prohibit”，则表明到该信令点的通信中断，信令点不可达。DSP SCCPSSN查询SCCP子系统的状态正常状态为“Allow”，表明到该子系统的通信正常；如果状态是“Prohibit”，表明到该子系统的通信中断，子系统不可达。TST SCCPGT测试SCCP GT翻译，检查所配置的SCCP GT能否翻译为需要的结果。测试结果包括以下内容：GT IndexGT索引；GT Matching LengthGT匹配长度；GT Matching ContentGT匹配内容；Translating Result Type翻译结果类型，包括SPC+old GT、SPC+SSN、SPC+new GT、SPC四种；NI网络标识；SPC信令点编码；SSN子系统号，仅当翻译类型为SPC+SSN时存在；New GT新GT码，仅当翻译类型为SPC+new GT时存在。5.3.6 SCCP常见问题处理1. 位置更新或者呼叫业务请求被SCCP拒绝(1) 故障现象RNC或者BSC发起的位置更新或者呼叫业务不能成功，SCCP DPC跟踪窗口显示收到从RNC或者BSC发来的连接请求消息（CR），SCCP直接回了连接拒绝消息（CREF）。(2) 原因分析根据SCCP回送的CREF消息中的拒绝原因进行分析，常见的拒绝原因有如下几种：l 原因一：消息不正确，这种情况在RNC或者BSC是由测试仪模拟的情况下，比较容易发生。l 原因二：本端A接口或者RANAP子系统未配置，消息无法上发到上层用户。l 原因三：本端A接口或者RANAP子系统状态为禁止，消息无法上发到上层用户。l 原因四：连接资源不足。l 原因五：上层用户超时不发送连接响应。l 原因六：上层用户拒绝。(3) 故障处理打开SCCP DPC消息跟踪，其中目的信令点是到RNC或者BSC的目的信令点（注意输入正确的NI）。此时，应该能跟踪到来自RNC或者BSC的CR消息和SCCP返回的CREF消息。首先，对跟踪到的CR消息进行消息解释，检查消息是否正确：l 必备参数偏移和实际被叫地址参数的起始位置是否符合；l 被叫地址长度是否和所带的地址信息实际长度相符。l 检查被叫地址是否正确：一般而言，路由标记应为“route on SSN”，不带有GT，带有或者不带有DPC，带有子系统号。l 如果被叫地址带有DPC，则DPC应该是本局信令点编码，其所占的字节数由接入网采用的信令点编码格式决定：如果是14位信令点编码，则占2个字节；如果是24位信令点编码，则占3个字节。可以通过LST OFI查看本局的信令点编码结构，如果消息中DPC所占的字节数和本端信令点编码结构不符，则被叫地址出错，应该和对端协商，双方使用同一种信令点编码格式。l 被叫地址的子系统号应该置于信令点后面，应为RANAP子系统（0x8E）或者A接口子系统（0xFE），视对端是RNC还是BSC而定。如果子系统号不正确，也需要和对端协商。如果CR消息正确，则对跟踪到的CREF消息进行解释，检查拒绝原因：l 拒绝原因是“Unequipped User”，对应于原因二，需要用LST SCCPSSN命令检查本端的RANAP子系统或者BSSAP子系统是否已经配置，其中本端子系统的SPC和OPC参数应该都是本端信令点编码，如果没有配置则需要增加该子系统。l 拒绝原因是“Subsystem Failure”，对应原因三，需要用DSP SCCPSSN检查本端RANAP子系统或BSSAP子系统的状态。如果是状态禁止，则检查是否曾用SET SCCPSSN命令改变过该子系统的状态，如果是维护操作造成的，只需用SET SCCPSSN命令重新将该子系统的状态置为“Allow”即可。否则，需要用LST SCCPDSP检查是否把本局信令点当作目的信令点配置在SCCP DSP表中。如果有，则把该记录删除，并用SET SCCPSSN命令重新将该子系统的状态置为“Allow”。l 拒绝原因是“Network Resource - QOS Not Available/Transient”，对应于原因四。如果同时已经有很多呼叫正在进行，则只需释放呼叫并等待片刻，即能重新建立连接。因为一个模块能同时建立的连接数量是有限的，并且SCCP有冻结定时器保护连接资源，释放后并不能马上分配。l 拒绝原因是“Expiration of the Connection Establishment Timer”，对应于原因五。此时，可以打开SCCP用户跟踪，应该能够看到SCCP上报到用户的“N_CONNECT_IND”原语，但用户不回送“N_CONNECT_RSP”响应原语，造成SCCP连接定时器超时，需要联系RANAP或者A接口的维护人员定位。l 拒绝原因是“End User Originated”或者其它原因值，对应于原因六。此时，可以打开SCCP用户跟踪，应该能够看到SCCP上报到用户的“N_CONNECT_IND”原语，以及用户回送的“N_DISCONNECT_REQ”原语，上层用户直接回了拒绝，需要联系RANAP或者A接口的维护人员定位。2. 上层用户发送的消息到达了SCCP，但SCCP无法发送到对端(1) 故障现象从SCCP用户跟踪窗口能看到上层用户（包括BSSAP、RANAP、TCAP）发送到SCCP的消息，但是链路跟踪上没有跟踪到SCCP发送到对端的消息。(2) 原因分析上层用户发送的消息，经过SCCP路由后，如果目的信令点可达，则发往底层，由底层发送到对端。因此，如果消息在SCCP层丢掉或者返回，可能的原因有：l 目的信令点或者子系统没有配置。l 目的信令点状态不可达。l GT码配置不正确。(3) 故障处理打开SCCP用户跟踪，对上层用户发送的消息进行解释，分析消息中的被叫地址：l 被叫地址带有DPC和SSN如果被叫地址带有DPC和SSN，用LST SCCPDSP查找该信令点是否已经配置，如果没有配置，需要增加该信令点。如果信令点已经配置，用DSP SCCPDSP命令查询该信令点的状态。如果信令点不可达，用DSP N7DSP命令（对于MTP承载）检查该信令点在底层的状态。如果状态为不可达，则检查数据配置、链路传输等。只有当底层信令点可达，SCCP信令点的状态就可恢复，消息才能发送到目的信令点。如果目的信令点可达，用LST SCCPSSN查找该子系统是否已经配置（OPC对应于主叫地址中的信令点编码），如果没有配置，则需要增加该子系统。如果子系统已经配置，则用DSP SCCPSSN命令查询该子系统的状态，如果不可达，则检查是否曾经用维护命令SET SCCPSSN将其禁止，如果是维护命令禁止的，用SET SCCPSSN命令把它重新设置为允许，如果不是维护命令禁止，检查本端和对端的SCCP SCMG子系统是否已经配置，如果没有配置，加上该子系统。打开SCCP DPC跟踪，应该能看到本端SCCP发送的SST消息（由UDT承载），而没有对端回送的SSA消息，联系对端检查子系统禁止的原因。l 被叫地址中有GT和SSN如果被叫地址中有GT和SSN，需要用TST SCCPGT检查GT的翻译结果是否正确（注意号码计划的输入，必须和消息中GT的号码计划一致），如果不正确需要修改该GT配置。如果GT翻译结果正确，用DSP SCCPDSP命令查询该信令点的状态，如果信令点不可达，检查到该信令点在底层的状态。如果状态为不可达，则检查数据配置、链路传输等。只有当底层信令点可达，SCCP信令点的状态就可恢复，消息才能发送到目的信令点。如果GT翻译结果正确而且目的信令点可达，检查主叫地址，如果主叫地址同样含有GT和SSN，则需要用LST SCCPGT检查主叫的GT码是否已经配置，翻译结果是否为本端信令点编码。如果没有配置，则需要增加主叫GT的配置（注意号码计划的输入，必须和消息中GT的号码计划一致），翻译结果类型选用SPC，输入本端信令点编码。3. 本端收到远端发送的SCCP消息，但不能发送给上层用户(1) 故障现象从SCCP DPC跟踪窗口可以跟踪到远端发来的消息，但是SCCP用户跟踪窗口没有跟踪到SCCP发送到用户的原语。(2) 原因分析远端发送到SCCP的消息，SCCP需要经过路由后发送到上层用户，路由失败可能的原因有：l 本端子系统没有配置。l 本端子系统状态不可达。l GT码配置错误。(3) 故障处理打开SCCP DPC跟踪，对对端发来的SCCP消息进行解释，分析消息中的被叫地址：l 根据SSN寻址如果路由标记指示根据SSN寻址“Route on SSN”，用LST SCCPSSN检查本端该子系统是否已经配置（SPC和OPC都同为本局信令点编码）。如果没有配置，需要增加该子系统。如果本端子系统已经配置，则用DSP SCCPSSN检查该子系统的状态，如果为禁止，检查是否曾用SET SCCPSSN将其置为禁止，如果是维护禁止，可用SET SCCPSSN将其恢复。l 根据GT寻址如果路由标记指示根据GT寻址“Route on GT”，用LST SCCPGT检查被叫地址中的GT是否已经配置，翻译结果是否为本端的信令点。如果本端没有配置，需要增加该GT，翻译结果为SPC，输入本端信令点编码。如果GT已经配置，用TST SCCPGT检查是否能翻译到本端信令点，如果能成功翻译到本端信令点，但是翻译结果是SPC+SSN，并且SSN和消息中的不一致，则需要把该GT的翻译结果改为SPC。如果翻译正确，则检查本端信令点上的SSN是否已经配置，如果没有配置，需要增加该子系统。如果本端子系统已经配置，则用DSP SCCPSSN检查该子系统的状态，如果为禁止，检查是否曾用SET SCCPSSN将其置为禁止，如果是维护禁止，可用SET SCCPSSN将其恢复。M3UA问题定位方法M3UA中的大多数问题都是由于人为因素造成的，例如：数据配置不正确、人工去激活某条M3UA链路等。1. 检查网络连接在维护台使用接口跟踪“PING”，检查是否能ping通对端设备。否则，需要检查物理通路是否有故障：网线连接是否正确；WIFM板是否运行正常；WIFM板的网口指示灯是否正常；对端设备是否运行正常。2. 检查数据配置(1) 使用LST FECFG命令，检查MSOFTX3000的接口IP地址配置是否和数据配置规划中的数据保持一致，如不正确则需要修改。(2) 如果MSOFTX3000与对端设备之间不是直接相连，使用LST FECFG命令检查网关地址是否配置正确，可以使用接口跟踪“TRACERT”，对IP报文进行跟踪（指定WIFM板模块号和对端设备的IP地址，查看经过路由以确定报文丢失地点）。(3) 使用LST M3LNK命令，检查本地端口号、本地IP地址、远端端口号、远端IP地址、C/S工作模式等参数的配置是否正确。(4) 使用LST M3LE、LST M3DE、LST M3LKS命令，检查本地实体索引、目的实体索引、链路集索引等参数的索引关系是否正确。3. 消息跟踪启动消息跟踪，如M3UA消息跟踪、SCTP消息跟踪，查看消息流程是否正确。如图5-10所示，一个正常的M3UA消息接续流程如下：l SCTP上报UP；l ASP向SG发送ASP UP消息，SG以ASP UP ACK进行应答；l ASP向SG发送ASP ACTIVE消息，SG以ASP ACTIVE ACK进行应答。至此，M3UA链路处于激活状态。图5-10 M3UA消息接续流程4. 查看告警信息在维护台上查看相关告警信息和维护信息，并采取相应的处理措施。5. 状态查询表5-13 M3UA状态查询命令命令说明备注DSP M3LNK查询M3UA链路状态正常状态为“Active”DSP M3DLNKDSP M3LSLNKDSP M3LKS查询M3UA链路集状态正常状态为“Active”DSP M3DE查询M3UA目的实体状态正常状态为“Accessible”DSP M3RT查询M3UA路由状态DSP M3VER查询M3UA版本信息5.6.4 M3UA常见问题处理1. M3UA链路状态显示为“Link Unestablished”(1) 故障现象M3UA链路无法建立，链路状态显示为“Link Unestablished”。(2) 原因分析原因一：数据配置错误，重点检查ADD M3LE命令中的参数路由上下文、ADD M3LKS中的业务模式、ADD M3LNK中的C/S模式、本端IP地址、对端IP地址、本端端口号以及对端端口号的配置是否正确。原因二：是否在客户端人工拆除M3UA链路，具体方法如下：%DSP M3LNK: MN=133, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeededM3UA Link Status-Module Number = 133Link Number = 0SCTP Association ID = 4294967295Lock Information = UnlockedLocal Inactive Info = Link Not Inactivated ManuallyLocal Release Info = Release UngracefullyLink Congestion Info = Not CongestedReal In Stream Num = 0Real Out Stream Num = 0Status = Link Unestablished.如果“Local Release Info”为“Release Ungracefully”或“Release Gracefully”，表示人工拆除M3UA链路。原因三：SCTP不能正常工作导致M3UA链路状态为“Link Unestablished”，具体原因请参见“5.2.4 SCTP常见问题处理”。(3) 故障处理对于原因一：修改两端相关数据配置。对于原因二：在客户端利用EST M3LNK命令人工建立M3UA链路，具体方法如下所示：%EST M3LNK: MN=133, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeeded对于原因三：故障处理方法具体请参见“5.2.4 SCTP常见问题处理”。2. M3UA链路状态显示为“Link Down”(1) 故障现象M3UA链路可以建立，但是在ASP侧，M3UA链路状态显示为“Link Down”。(2) 原因分析原因一：在SG侧对相关M3UA链路进行了锁定操作，如下所示：%DSP M3LNK: MN=132, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeededM3UA Link Status-Module Number = 133Link Number = 0SCTP Association ID = 101Lock Information = LockedLocal Inactive Info = Link Not Inactivated ManuallyLocal Release Info = Link Not Released ManuallyLink Congestion Info = Not CongestedReal In Stream Num = 0Real Out Stream Num = 0Status = Link Down.原因二：SG以及AS出现异常，两端状态不一致，如ASP 侧为“Link Active”，而SG侧为“Link Down”。(3) 故障处理对于原因一：在SG侧利用ULK M3LNK命令人工解除对链路的锁定，如下所示：%ULK M3LNK: MN=133, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeeded对于原因二：在客户端首先人工拆除对应的M3UA链路，然后再重新建立，如下所示：%REL M3LNK: MN=133, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeeded%EST M3LNK: MN=133, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeeded3. M3UA链路状态显示为“Link Inactive”(1) 故障现象M3UA链路可以建立，但是不能激活，链路状态显示为“Link Inactive”。(2) 原因分析原因一：两端数据配置错误，重点检查ADD M3LE命令中的路由上下文参数、ADD M3LKS中的业务模式、ADD M3LNK中的C/S模式、本端IP地址、对端IP地址、本端端口号以及对端端口号的配置是否正确。同时，可以启动M3UA消息跟踪查看消息流程，利用ERROR消息中的具体错误原因定位问题。原因二：在ASP侧人工去激活M3UA链路，如下所示：%DSP M3LNK: MN=132, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeededM3UA Link Status-Module Number = 132Link Number = 0SCTP Association ID = 108Lock Information = UnlockedLocal Inactive Info = Link Inactivated ManuallyLocal Release Info = Link Not Released ManuallyLink Congestion Info = Not CongestedReal In Stream Num = 17Real Out Stream Num = 17Status = Link Inactive(3) 故障处理对于原因一：根据ERROR消息中的错误码类型，修改两端相关数据配置。若错误码为“Invalid Routing Context”，表示两端路由上下文不一致，修改两端路由上下文配置使其保持一致；若错误码为“Unsupported Traffic Handling Mode”，表示两端的业务模式不一致，请修改链路集表中的业务模式使其保持一致。对于原因二：在ASP侧利用ACT M3LNK命令人工激活M3UA链路，如下所示：%ACT M3LNK: MN=132, M3LNK=0,CONFIRM=Y;%RETCODE = 0 Operation succeededBICC问题定位方法1. 检查网络连接在维护台使用接口跟踪“PING”，检查是否能ping通对端设备。否则，需要检查物理通路是否有故障：网线连接是否正确；WIFM板是否运行正常；WIFM板的网口指示灯是否正常；WIFM板所连接的网络设备（例如：路由器）是否工作正常；路由数据是否配置正确；对端设备是否运行正常。2. 检查数据配置(1) 使用LST FECFG命令，检查MSOFTX3000的接口IP地址配置是否和数据配置规划中的数据保持一致，如不正确则需要修改。(2) 如果MSOFTX3000与对端设备之间不是直接相连，使用LST FECFG命令检查网关地址是否配置正确，可以使用接口跟踪“TRACERT”，对IP报文进行跟踪（指定WIFM板模块号和对端设备的IP地址，查看经过路由以确定报文丢失地点）。(3) 使用LST BICCSCTPLNK命令，检查SCTP连接两端配置的客户端和服务器端是否与规划的数据一致。配置时必须保证SCTP连接一端配置为客户端，另一端配置为服务器端，两端都为客户端或者两端都为服务器端是不能建立连接的。(4) 如果MSOFTX3000配置为SCTP服务器端，通过SCTP消息跟踪看到本端收到INIT消息，但是本端没有任何响应。首先使用LST SCTPPARA命令，查看校验和算法参数“Checksum Arithmetic”，然后检查对端的校验和算法。如果不一致，需要修改为一致。MSOFTX3000的校验和算法缺省为“CRC32”，可以通过SET SCTPPARA命令进行修改。3. 状态查询表5-16 BICC状态查询命令命令说明备注DSP BSCTP查询BICC链路状态正常状态为“Active”DSP BSCTPOFCDSP BICCCIC查询 BICC CIC状态DSP BICCOFCDSP BICCSTA5.7.4 BICC常见问题处理1. BICC CIC状态异常(1) 故障现象使用DSP BICCCIC查询对端CIC状态的时候，返回操作超时或者有部分CIC状态显示为未安装。(2) 原因分析原因一：两端CIC数据配置不一致；原因二：底层信令承载故障。(3) 故障处理对于原因一，检查数据配置是否正常，常见的数据配置错误有：两端的CIC配置范围不一致；对应的CIC并没有配置到正确的局向上。& 说明：在不同的局向上，CIC的范围可以重叠。因此，如果CIC没有配置到正确的局向上，在此局向上进行相应的操作，将导致错误的结果。对于原因二，检查BICC信令承载是否正常：当底层的信令承载（SCTP/MTP3/MTP3B/M3UA）故障的时候，CIC的维护命令不可能到达对端。可以分别使用DSP BSCTPOFC、DSP N7DSP、DSP MTP3BDSP命令，进行底层信令链路的检查。2. BICC信令承载故障(1) 故障现象SCTP链路消息跟踪不到。(2) 原因分析BICC当前可以承载在MTP/MTP3B/M3UA/SCTP上，在ADD OFC命令中设置。当承载在MTP/MTP3B/M3UA上的时候，底层信令承载的配置与ISUP等的配置相同。而当承载在SCTP上的时候，需要使用ADD BICCSCTPLNK命令把局向与SCTP链路关联起来。原因一：局向上配置的BICC signaling bearer type与实际使用的信令承载类型不符合；原因二：两端SCTP链路的参数不一致；原因三：SCTP两端的Client/Server属性都设成一样的值。(3) 故障处理如果发现呼叫时信令链路上没有消息，可以检查局向表中BICC signaling bearer type的类型是否与实际此局向上配置的相同。如果是MTP3/MTP3B/M3UA，那么需要检查局向表中是否正确的配置了目的信令点编码。如果配置的是SCTP链路，那么使用LST BICCSCTPLNK检查是否把此链路配置到了正确的局向上，使用DSP BSCTP查看链路状态是否正常。如果链路状态不正常，可以检查两端的SCTP链路的配置，IP地址和端口号是否与对端一致，Client/Server属性是否相异。使用SCTP链路的跟踪消息，观察SCTP链路的建立过程，如果一直只有单方向的请求消息，那么检查双方的数据配置，如果数据没有问题，可以检查物理连线是否正确。可以使用ACT BSCTP命令激活BICC SCTP链路，用DEA BSCTP去激活BICC SCTP链路。UMG8900配置数据检查3.4.1 硬件数据检查项目说明结果备注机柜和机框机柜号、机框号在设备内统一编号。 Y； N主控框的框号必须为1、中心交换框的框号必须为0。 Y； N单板同一类型单板的板组号应统一规划，保持配置数据具有较好的可读性。 Y； N槽位设置要符合规范，多余单板将其删除。 Y； N11备份的单板要配置在对偶槽位，一般主用单板配置在偶数槽位，备用单板配置在奇数槽位。 Y； N时钟时钟参考源的配置应根据物理连线的实际情况配置，配置多个参考源时时钟工作模式应选择“自动”模式 Y； N时钟等级的配置是否与参考源的实际等级一致。如果参考源的等级为三级，而数据配置为二级，那么UMG8900就会检测到参考源达不到要求的时钟精度，上报“主用参考源频偏超出范围”的告警 Y； N系统时间时间的设置与当地标准时间的误差不能大于30秒 Y； N级联增加级联业务框（ADD FRM）时，级联板号参数与实际连接到的BLU板板组号一致 Y； N配置级联关系时（ADD FRMLNK），参数的设置和实际的物理连线一致 Y； N3.4.2 对接数据检查项目说明结果备注到MGC的连接按照规划要求给VMGW配置了TDM/IP端点资源，否则该VMGW不能用于承载业务 Y； N配置了多块PPU板时，应保证在每一块PPU板上都建立了H.248信令链路，这样可以将处理H.248消息的能力分散到每一块单板，实现负荷分担 Y； N修改了PPU板SCTP、H.248协议栈参数时，必须注意重启PPU板，修改后的协议参数才能生效 Y； NVMGW标识、H.248协议编解码类型、传输协议类型、鉴权类型和密钥参数需要和对接的MGC一致，仔细检查这些参数是否配置正确，可以极大缩减到MGC的调试时间 Y； N媒体资源分组，应确保每块CMU板都有VPU资源可供调用，同时应防止VPU没有纳入资源组中，导致资源浪费 Y； N特别是配置完数据后新增加的VPU板，应及时加入到资源组中到BSC/MSC/PSTN交换机的联机（TDM承载）按照TDM时隙规划表准确的配置TDMIU Y； NSDH接口的开销字节应该与对接的设备保持一致 Y； N配置数据后应检查告警管理系统中是否有关于SDH的相关告警E1接口的帧格式、线路编码格式应该与对接的设备保持一致 Y； N通常在跟海外交换机对接时需要注意此项到其它MGW的连接IP承载的接口地址与规划的数据一致，是否配置为“可用于承载” Y； NPOS接口的开销字节应该与对接的设备保持一致 Y； N配置数据后应检查告警管理系统中是否有关于SDH的相关告警网关地址应与承载IP地址在同一网段 Y； N配置集中转发数据时，集中转发口应配置为“不可用于承载” Y； N配置集中转发数据时，通过同一个集中转发口转发的不同单板，其协议类型与端口号不能完全相同 Y； N到SIWF的连接ADD IWFE1中E1编号的配置需要与SIWF侧一致 Y； N连接SIWF的E1中继类型（ADD TDMIU）设置为“内部时隙” Y； N已激活SIWF Y； N信令转发数据基于MTP3-M3UA转发模式时，MTP3本局信令点、目的信令点编码配置正确，M3UA本地实体、目的实体配置正确 Y； NM3UA本地实体、目的实体的路由上下文分别与MGC目的实体、本地实体的路由上下文一致 Y； NM3UA链路集的流量模式与MGC侧一致，同为负荷分担或者同为主备用 Y； NM3UA链路集的工作模式设置为SGP，MGC侧为ASP Y； N承载M3UA、M2UA的SCTP链路参数与MGC侧匹配 Y； N基于MTP2-M2UA的转发模式时，MTP2链路的整形接口ID、文本型接口ID统一规划，SPF扣板模式的设置是否能够满足信令转发的要求 Y； N基于半永久连接的透传模式时，半永久连接的时隙单元是否正确 Y； N第4章 本局调试4.1 本章内容简介本章讲述本局点的硬件数据配置、检查和调试工作，内容如下：l 单板调试；l 时钟调试；l 级联调试。& 说明：端口的调试由于通常需要跟对接设备进行联调，所以其调试分布在跟其它网元对接的调试章节中。4.2 单板调试4.2.1 单板运行状况检查机框上电并完成软件加载后，应通过设备面板检查单板的运行状况是否正常。启动LMT的操作维护系统，在默认显示的“维护”页签（位于界面左侧导航窗口的下部）中，选择维护导航/面板管理，系统将运行设备面板软件，用户可通过面板直观的了解各单板的运行状况。单板状况的颜色表示说明如表4-1。& 说明：初次使用设备面板的用户可能对面板的操作不太熟悉，请用户在操作面板时直接按F1键，查看设备面板的联机帮助。表4-1 单板状态的颜色表示颜 色状 态 与 说 明绿色主用正常表示以1+1备份方式工作的单板中的主用单板工作正常。非主备正常表示以负荷分担方式工作的单板工作正常。红色非主备故障表示以非1+1备份方式工作的单板故障。隔离故障表示以负荷分担方式工作的单板中原隔离的单板现处于故障状态。深红主备故障表示以1+1备份方式工作的主用单板或备用单板故障。浅红安装不匹配表示单板的配置和实际的单板不一致。灰蓝备用正常表示以1+1备份方式工作的单板中的备用单板工作正常。深蓝隔离正常表示以负荷分担方式工作的单板中的原工作正常的单板现处于隔离状态。浅灰单板未安装对已进行配置但未实际安装单板的板位，单板显示为未安装状态。深灰单板未配置槽位上插了单板，但软件上没有做配置时，单板显示为未配置状态。粉红安装的单板与配置的不一致表示该槽位上实际安装的单板类型与软件配置的单板类型不一致，比如：单板为TNU板，而配置时将其配为TCLU板，则该板显示为不一致状态。4.2.2 单板软件版本检查若单板运行正常，接下来需要检查单板的软件版本是否正确。在LMT操作维护系统中，执行LST BRDVER命令或者在设备面板上选中单板后选择右键菜单单板版本信息，查询单板的软件版本是否满足规划要求。4.2.3 单板倒换调试在电信级应用中，要求设备具有很高的自保护能力，许多单板都配置了备板（指工作方式为1+1备份的单板）。系统正常运行时，主板工作，当主板发生故障时，主备板发生倒换，原有备板升级为主板，接替主板完成工作。所以，在系统调试过程中，需要关注单板的主备倒换是否正常。单板倒换可以通过执行MML命令SWP BRD或者在设备面板中选中单板后点击右键菜单“倒换单板”来进行，倒换后观察主板降备板、备板升主板这个过程能否正常完成。单板倒换也可以结合业务调试来进行，在一次通话过程中执行单板倒换，观察是否影响正常通话。4.3 时钟调试数字程控交换机组成一个数字网，它们通过数字传输系统互相连接，这时要求各个交换机的时钟频率和相位能够协调一致，最好是完全一致。这就产生了网同步问题，要求网内所有交换机都具有相同的发送时钟频率和接受时钟频率。时钟的漂移和抖动可能引发很多的问题，比如通话时的杂音、通话中断等现象。本章旨在介绍如何调试时钟系统，在调试中发现一些故障，用户可以参见HUAWEI UMG8900 通用媒体网关 维护手册 故障处理分册。4.3.1 时钟线缆连接检查& 说明：有关时钟线缆的说明请参考HUAWEI UMG8900 通用媒体网关设备手册，时钟线缆的连接方法的详细说明请参考HUAWEI UMG8900 通用媒体网关安装手册硬件安装分册。表4-2 时钟线缆连接检查操作说明结果备注如果UMG8900锁BITS时钟，从BIT