经典网络技术案例集锦-第五期.pdf

网管中心技术支援室 1/39 主编：主编：网络管理中心网络管理中心 技术支援室技术支援室 期刊：期刊：第五第五期期 2009 年年 10 月月 网管中心技术支援室 2/39 目录 案例 1：本月知识点：-MSOFTX3000 主叫号码缺省变换 .3案例 2：内蒙移动呼市分公司集团铃音不能正常放音 .6案例 3：MSC IN POOL部分用户切换失败造成掉话处理 .8案例 4：通过呼叫跟踪处理通话噪音问题 .10案例 5：拨打呼转空号的VPMN用户无录音通知提示即挂断 .13案例 6：M3UA链路故障的问题处理 .15案例 7：如何核对爱立信的基站退服率 .18案例 8：互联互通固网无法正常呼叫移动 4001*的问题处理 .19案例 9：关于某用户反映区内漫游免费的集团网内,资费有时免费,有时收费 .21案例 10：集团用户省内漫游后拨打同集团其他成员的短号，听到提示“对不起，您不允许呼叫此号码”.23案例 11：SIM卡问题导致 2/3G空闲模式下重选失败-TD案例 .25案例 12：2G向 3G频繁重选的问题-TD案例 .27案例 13：邻区数据错误导致 2/3G互操作失败案例-TD案例 .32案例 14：去激活小区后无法重新激活的故障解决-TD案例 .35案例 15：华为无线对接爱立信MSC视频电话无法主叫案例-TD案例 .38 网管中心技术支援室 3/39 案例案例 1：本本月知识点：月知识点：-MSOFTX3000 主叫号码主叫号码缺省变换缺省变换 1、特性描述：在号码分析过程前，MSOFTX3000 会对主叫号码进行缺省变换处理，目的主要是将主叫号码规整成与其号码属性对应的、可直接回拨的号码，便于被叫用户直接回拨主叫 2、实现原理 根据呼叫来源的不同，可以把 MSOFTX3000 呼叫分成两类：2.1：来自中继的入局呼叫；2.2：来自 A 接口（或 Iu_CS 接口）的本局移动始发呼叫；以下分入局呼叫和本局始发呼叫两种情况介绍主叫号码变换的 方法和变换结果。（1）入局呼叫 当呼叫为中继入局呼叫时，根据网间主叫号码的传递规范要求，系统对主叫号码的变换分为四种情况，如表1所示。注意软参P76，P98的描述。（按研发分析，P76软参没有使用）表 1 入局呼叫主叫号码默认变换 变换前主叫号码特性 变换方法 变换后主叫号码格式 举例 不包含本国接入码 86；不带国内号码前缀（例如国内号码为 0）；号 码长度不超过 7 位（可由在原号码前补充国内号码前缀（例如：0）+本地“国内长途前缀（如：0）+国内长途区号+用 户 号28780808 变换为：075528780808 注：本例号码判断长度为 8，可更改网管中心技术支援室 4/39 变换前主叫号码特性 变换方法 变换后主叫号码格式 举例 软件参数“主叫号码判断长度”进行设置）；号码属性为：用户号码。区号 码”软参实现 不包含本国接入码 86；不带国内号码前缀 0；号码长度超过 7 位（可由软件参数“主叫号码判断长度”进行设置）；号码属性为：国内号码。在原号码前补充国内号码前缀（例如：0）“国内长途前缀（如：0）+国内长途区号+用 户 号码”75528780808 变换为：075528780808 号码属性为：国际号码 在原号码前补充国际号码前缀（如：00）“国际长途前缀（如：00）+国际号码”例一：8675528780808 变换为：008675528780808 例二：85291234567变换为：0085291234567 移动主叫号码；号码属性为：国内号码 删除 MSISDN的国家码“13SH0H1H2H3ABCD”的 格式。8613912345667 变换为：13912345667 不包含本国接入码 86；带国内号码前缀（例如国内号码为 0）；号码长度等于 7 位（可由软件删除前缀 0，添加本地区号“国内长途前缀（如：0）+国内长途区号+用 户 号0271860 变换为：0本地区号271860 网管中心技术支援室 5/39 变换前主叫号码特性 变换方法 变换后主叫号码格式 举例 参数“主叫号码判断长度”进行设置）；号码属性为：用户号码。码”（2）本局始发呼叫 当本局作为移动始发端局时，根据主叫号码传递规范要求，可将 主叫号码变换为下面两种格式：移动号码“13SH0H1H2H3ABCD”，号码属性为“国内号码”；“国际长途前缀（00）+国际号码”，号码属性为“国际号码”。网管中心技术支援室 6/39 案例 2：内蒙移动呼市分公司集团铃音不能正常放音 问题描述问题描述:AIP 的 VP 台无法对内蒙移动呼市分公司集团铃音 7011605 进行正常放音。原因分析：原因分析：VP 台是 AIP 的放音设备，对特定格式的彩铃文件进行解析后为彩铃用户进行放音，铃音文件的具体要求为：1、wav 单声道文件格式 2、位速：64kbps 3、音频采样大小：8 位 4、音频采样级别：8kHz 音频格式：PCM 或 A-Low 处理步骤：处理步骤：1、问题收集：将铃音编码为 7011605 的铃音文件下载后进行分析，发现音频格式为：U-Low，由于 VP 台无法良好支持 U-Low 的音频文件，致使放音出现问题。2、使用 goldwave 音频编辑软件打开一个 PCM 格式的正常音频文件，同时打开问题铃音文件 7011605。3、将 7011605 音频波形全选后复制，粘贴并替换掉正常 PCM 格式的铃音文件音频波形。网管中心技术支援室 7/39 4、保存正常 PCM 格式的铃音文件，退出 goldwave，将正常 PCM格式文件更名为 7011605.wav。5、在铃音文件服务器上，用步骤 4 中生成的 7011605.wav 替换原文件，同时进行其他铃音文件服务器的同步操作。6、待全部文件服务器同步完成后，放音问题消除。经验总结：经验总结：彩铃 AIP 架构下的放音设备，VP 台，对于不同铃音文件格式的支持和兼容性相对较差，所以要求 SP 在上载铃音前严格按照集团公司相关规范对铃音格式进行核查，同时加强日常维护和监控，以避免此类问题。网管中心技术支援室 8/39 案例案例 3：MSC IN POOL 部分用户切换失败部分用户切换失败造成掉话处理造成掉话处理 问题描述问题描述:部分用户投诉在通话过程出现掉话。原因分析：原因分析：掉话的原因很多，可以概括为三类：无线覆盖造成的掉话、切换不成功造成掉话、设备故障造成掉话；在处理中可以根据用户投诉，定位用户所登记的 VLR 及对应的 BSC 和基站，然后根据这些信息综合分析出现掉话可能出现的原因。除此之外，利用交换机统计可以帮助查找用户掉话的原因。处理步骤：处理步骤：问题信息收集：根据用户投诉发现发生掉话情况发生在 MSC IN POOL 改造以后，对投诉用户进行跟踪发现投诉用户登记在不同的 MSC下,不同的小区。设备无异常告警。通过查看统计发现，某华为端局与 MSC POOL 的爱立信软交换局的切换成功率很低。问题准确定位：首先掉话发生在不同的 MSC 和不同的小区，排除最常见的无线覆盖的原因，其次设备运行正常，无异常告警排除了设备故障引起的掉话。通过查看统计发现，某华为端局与 MSC POOL 的爱立信软交换局的切换成功率很低，说明可能是因为切换不成功造成的掉话。经检查发现与华为交换局存在相邻关系的爱立信软交换局及BSC 上已经定义了切换数据；并且华为端局及 BSC 上也定义了切换数网管中心技术支援室 9/39 据。进一步对发生掉话的呼叫进行跟踪，发现掉话现象虽然不在同一个 MSC，但是却在与华为端局存在相邻关系的 BSC 上。这是因为 MSC IN POOL 中，用户登记在哪个 MSC 下由 BSC 计算得到，然后通过 TMSI 中NRI 的值找到对应的 MSC/VLR 进行登记，所以同一个 BSC 下用户会登记在不同的 MSC 上。在定义外部小区时，只要 MSC POOL 中一个 MSC与 MSC POOL 以外的 MSC 存在相邻关系，就要在 MSC POOL 中所有的MSC 中定义相邻关系，所以应该检查 MSC POOL 中其它 MSC 是否定义了与华为端局间的切换数据。经过检查，发现 MSC POOL 中其他 MSC没有定义与华为端局的切换数据，因而造成部分用户切换失败而出现掉话。问题解决：MSC POOL 其它 MSC 添加至华为端局的切换数据，并对MSC POOL 内所有的 MSC 切换数据进行比较，保证添加的数据一致。经验总结：经验总结：MSC IN POOL 的建立，使 MSC POOL 中每个 MSC/VLR 在逻辑上与 MSC POOL 的所有 BSC 相连接。MSC POOL 根据负载均衡机制（NNSF 算法）把进入 MSC Pool 服务区内的用户分配给不同 MSC-S，一直由某个MSC-S 为该用户提供服务，直到用户离开 MSC POOL。这样就要求无论与 MSC POOL 外的 MSC 有没有相邻关系，只要一个 MSC 存在切换关系，其他 POOL 内 MSC 全部都需要定义切换数据，因此在处理此类故障时要充分考虑 MSC POOL 的因素。网管中心技术支援室 10/39 案例案例 4：通过呼叫跟踪处理通话噪音问题通过呼叫跟踪处理通话噪音问题 问题描述：问题描述：VOIP 改造后，有很多用户投诉在通话中有时会出现噪音。原因分析原因分析：在通话中出现噪音一般是如下原因：1、用户手机问题；2、用户所处的无线环境差，或者有干扰；3、A 接口电路质量不好；5、Ais 接口电路质量不好；4、Nb 接口电路质量部好；5、设备单板故障；处理步骤处理步骤：问题信息收集：通过用户的投诉我们了解到这些用户均在一个BSC下，但是却不在同一个基站下。检查 MSC-S 和 MGW 的告警信息，未发现异常告警。问题准确定位：首先不同的用户在不同的基站均发生通话噪音的问题，这就排除了用户手机、无线覆盖、Abis 接口电路的问题，同时也排除了Nb接口的问题。因为VOIP改造后软交换网络采用SIGTRAN协议，软交换端局间呼叫控制由 SERVER 间 BICC 协议完成，Nb 口话务承载由 TDM 承载方式变为 IP 承载，因此如果只有一个 BSC 下用户出现此问题，问题应该在 A 接口设备和电路上，并且 A 接口采用光口网管中心技术支援室 11/39 直连的方式。所以针对此情况，我们在此 BSC 下进行了多次拨打测试，当出现有噪音的通话时，我们对此通话进行跟踪，记录用户通话占用的设备和电路。用户跟踪方法与 VOIP 前有所不同，首先对通话呼叫进行跟踪，在 MSC-S 上执行：CTRAI:MSISDN=861*;会输出对应的MGW 和 Context ID，然后在 MGW 上进行 call path 追踪，点 EMAS call path 菜单，在 context ID 处输入从 server 跟踪呼叫中得到的context ID，然后点 OK，就会显示通话所占用的设备和电路。经过多次跟踪我们发现用户所占用的电路虽然不在同一光口上，但却在同一块 ET-C41 单板上，ET-C41 提供 4 个 TDM 模式的光纤接口，因此确定故障在 MGW 接口板 ET-C41 单板上。如果 A 接口采用光口打散的方式，通过呼叫跟踪会同样发现用户通话占用的设备和电路，如果出现噪音是同一条电路，那么需要监听这条电路是否传输质量部不好引起的，如果出现噪音不是同一条电路，那么就可能是单板或光口的问题。问题解决：在 MGW 上打开 EMAS，点 Equipment 菜单,找到故障的ET-C41 板卡,右键选择 LOCK 该块板卡，查看板卡状态是否变为LOCKED，然后再进行拨测，噪音情况应该消失。然后右键选择 Restart该板卡，对该板进行重启，查看板卡状态为 enabled 时再进行拨测，如果仍然有噪音，就应该更换此单板。对单板操作应该在夜间进行，会影响该单板上带的业务。故障总结故障总结：通话出现噪音这类通话质量故障，一般不会有告警出现，只有通网管中心技术支援室 12/39 过用户投诉才会发现。手机故障、无线覆盖的原因比较容易查找，但是电路故障和设备故障难以定位，因此需要了解 VOIP 改造后信令流程和呼叫流程，并结合设备硬件进行分析，在具体某接口的单板或者电路上，可以通过呼叫跟踪来进行定位，进而确定故障原因和解决方案。网管中心技术支援室 13/39 案例案例 5：拨打呼转空号的拨打呼转空号的 VPMN 用户无录音用户无录音通知提示即挂断通知提示即挂断 问题描述问题描述:用户投诉拨打 13904711800 无任何提示。原因分析原因分析：经检查用户数据发现 13904711800 做了无条件呼转，转移号码为8647168，该号码为国际格式，经交换机号码规整去掉国家代码 86 和长途区号 471 后为 68。经现象模拟发现，当被叫用户为普通用户时，呼转 8647168 可以听到录音通知，通知音为“您的号码有误，请查证后再拨。”当被叫用户为 VPMN 用户时，则没有录音通知直接挂断。根据该情况我们做了拨打测试并跟踪信令，在智能网呼转流程中，端局上报 IDP 消息后，SCP 回了 release call，携带原因值为 31（正常未指定），该原因值对应的情况有计数器超时或者非特定因素引起的呼叫失败等，由于 SCP 回了该消息后，端局无法放音（产生该情况的原因有很多，端局无法统一放音），所以，呼叫直接释放。从智能网侧分析，SCP返回release call的原因为：在智能网呼转流程中，由于号码68位数小于等于6位，SCP认为用户呼转的是短号（目前SCP设置不允许用户呼转短号），所以，SCP回了release call，携带原因值为31（正常未指定）。处理步骤：处理步骤：网管中心技术支援室 14/39 联系了华为智能网工程师，商议处理方法：开发 SCP 补丁，当用户呼转短号时，智能网呼转流程中修改 SCP 不返回原因值，而是直接放音，目前该补丁还在研发之中。经验总结经验总结:当没有录音通知提示的时候，问题可能是对端局返回的原因值有误。网管中心技术支援室 15/39 案例案例 6：M3UA 链路故障的问题处理链路故障的问题处理 问题描述问题描述:2009 年 6 月 5 日 15：05，HHGS31 报 M3UA 链路故障。告警信息告警信息:名称:M3UA 链路故障 定位信息:板类型=WBSG,机架号=1,框号=5,槽号=14,位置号=0,模块号=140,M3UA 链路名称=HHGS31_EDSGM4_0(1),本地 IP 地址 1/IP 地址2=10.168.17.6/10.168.17.134,本地端口号=5000,对端 IP 地址 1/IP 地址2=10.168.81.5/10.168.81.133,对端端口号=5000,M3UA 目的实体名称=EDSGM4(2),级别:重要 告警源:HHGS31 发生时间(NT):05/06/2009 15:05:57 告警 ID:1811 清除时间(NT):05/06/2009 16:51:58 MO 对象:链路名称=HHGS31_EDSGM4_0,模块号=140,链路号=1 清除:已清除()网络流水号:19615939 设备告警流水号:346366 网元类型:MSC Server 种类:故障 类型:信令系统 清除类型:正常清除。原因分析：原因分析：经核查，该链路不是供新建 BSC 使用的 M3UA 链路，但是在该链路所在的 140 模块的 WBSG 板上，有一条故障的 MTP3 链路，故初步判断可能与这条故障的 MTP3 链路有关。处理步骤处理步骤：网管中心技术支援室 16/39 1、通过命令核查和此 M3UA 链路相关的信息，发现 IP 地址、端口号、M3DE 等均正常而且正确，只有在 140 模块的 WBSG 板上有一条故障的 MTP3 链路；2、试着激活 M3UA 链路，无效；删除故障的 M3UA 链路重新制作，仍无效；3、通过维护终端帮助信息，发现一块 SPF 单板可以配置的 M3UA链路数受单板上的 SCTP 最大偶联数目限制的，SPF 单板的最大偶联数目石 64，为占用 SCTP 偶联的 L2UALNK 和 M3LNK 使用，其中每条做客户端的 L2UALNK 和 M3LNK 占用一个偶联，做服务器端的L2UALNK 和 M3LNK 占用两个偶联。例如 SPF 单板上已经配置了32 条服务器端的 L2UALNK，那么此 SPF 板不能再配置 M3LNK。鉴于此，我们对 HHGS31-EDSGM4 上的 L2UA 链路进行核查，发现均未达到最大数，此原因被排除；4、最后只剩下“一条故障的 MTP3 链路”一个原因，为了查找故障的真正原因，我们将此 MTP3 链路（新建 BSC 的一条链路，不影响业务）删除，删除后，M3UA 链路故障恢复；5、虽然证明了故障原因确为故障的 MTP3 链路所为，但我们不能使用删除故障链路来解决此问题，要么恢复故障链路，要么寻找其他方法；6、由于故障的 MTP3 链路属于入网前的调测链路，不能短时间内恢复正常，而且如果调整的话还一些底层的 MTP2 链路及一些关联的参数需要调整，不是很方便，故我们通过调整 M3UA 链路涉及的网管中心技术支援室 17/39 WBSG 板来解决此问题，只要选择一块没有故障链路的 WBSG 板即可，更改后，故障恢复。7、启示：后通过华为 800 及一些资料了解到，造成此故障的原因的确是“一条故障的 MTP3 链路”，但真正的原理是：交换机会实时检测 MTP3 链路的状态，如果该链路故障时长超过 6 分钟，该 MTP3链路所在 WBSG 板上的 M3UA 链路就会被视为故障，从而产生此告警。网管中心技术支援室 18/39 案例案例 7：如何核对爱立信的基站退服率如何核对爱立信的基站退服率 问题描述：问题描述：核对小区退服时长，主要是为了核对基站退服率指标。怎样核对，要以基站退服率指标从何处收集告警为基础，故从 OSS 的告警库中查询。处理步骤处理步骤：1、基站退服率以OSS转发的告警为准进行统计，应从OSS上查看小区的退服情况。2、在OSS上选择Alarm下的View Alarms下的Alarm Log Brower 3、根据设置向导，选择时间段、网元、告警字段，最后以 Expanded格式查询告警，对查询到得告警保存。问题总结：问题总结：通过用 OSS 上的 ALB 工具，可以对小区退服告警进行准确统计，以此核对小区退服情况最准确。网管中心技术支援室 19/39 案例案例 8：互联互通固网无法正常呼叫移动互联互通固网无法正常呼叫移动4001*的问题处理的问题处理 故障现象故障现象：移动新开通 4001 业务，前期拨测过程中发现铁通、电信固网、联通固网拨测均提示“空号”。通过消息跟踪，发现一个共性的现象：对端发送过来的号码只有4001，后面还有 6 位号码没有发送过来。原因分析：原因分析：由于 4001 业务的分析位长要求是 4-10 的不定位长，测试号码都是 10 位的号码，但对端 IAM 消息里送过来的只有 4 位的 4001，问题可能是对端发送的位长有问题。处理步骤处理步骤：1、首先处理铁通拨测异常的问题，通过在关口局上跟踪消息，发现铁通送过来的 IAM 消息里只有 4 位的 4001，后面的 6 位有时会在后续的消息里一位一位的补全，多数则没有后续消息，就直接返回ACM 消息。移动 4001 业务是在关口局上见 4001 就触发智能，所以 10位的号码还没有收全，就触发智能，但因为没有收到全号码导致找不到相应的目的号码，从而无法正常接续；2、确认铁通关口局做的分析位长也是 4-10 的不定位长，试探性的请对方将位长改为定长的 10 位，呼叫正常，也可以在 IAM 消息里直接送过来 10 位的全号码了，至此，确定是发送的号码的位长不符网管中心技术支援室 20/39 合要求导致，但文件中 明确要求分析位长是不定位的 4-10 位，如果改为 10 位的定长，虽然解决了当前的问题，但感觉仍不是真正的原因；3、接着对电信固话的异常拨测进行消息跟踪，现象同铁通一样，经过协商，改为 10 位的定长后，的确可以正常接续，但与文件要求不符。回想消息现象，主要是号码没能一次性从对端发送过来，只要号码可以一次性在 IAM 消息里发送过来，就可以正常接续，故电信关口局将发码规则改为一次性发码后，问题得到根本的解决。4、启示：结合本问题，我们发现在华为设备里的增加局向（ADD OFC）时，有个参数是“一次发送被叫号码的最大长度”，可通过此参数来控制单个消息（如 IAM 消息）中所携带的“被叫号码”的最大长度。以后遇到此类问题，可以观察一下此参数的设置，现网我们的设备一般使用默认的“不限制”。但注意，如果对端是西门子设备，需要将此参数设置为 14 位。网管中心技术支援室 21/39 案例案例 9：关于某用户反映区内漫游免费的集关于某用户反映区内漫游免费的集团网团网内内,资费有时免费资费有时免费,有时收费有时收费 问题描述问题描述:某用户反映在区内漫游免费的集团网内,但有时按免费收取,有时按正常资费扣费。原因分析原因分析:用户漫游未优惠的原因经过信令监测系统消息分析发现由于 MSC上报 IDP 消息后 SCP 返回相关信令消息超时导致 MSC 发送了TC_P_ABORT,经过咨询爱立信工程师,得知由于爱立信交换局对于IDP消息后的消息返回时长有 5 秒的要求,所以超过 5 秒的信令将不再继续处理，导致转普通呼叫。处理处理 步骤步骤：经过查询话单发现,用户主叫话单未在智能网侧产生,产生在了端局。用户漫游未优惠的原因经过信令监测系统消息分析发现由于 MSC上报 IDP 消息后 SCP 返回相关信令消息超时导致 MSC 发送了TC_P_ABORT,经过咨询爱立信工程师,得知由于爱立信交换局对于IDP消息后的消息返回时长有 5 秒的要求,所以超过 5 秒的信令将不再继续处理，导致转普通呼叫.经过反复测试发现信令超时原因为华为软交换局 paging 延时导致的。在智能网发 ATI 消息到 HLR 过程中，呼和华为局设置了 PSI 的预寻呼，这个寻呼发生二次寻呼的比例比较大，测试结果反映约为 30%，目前我们设置的寻呼策略为两次寻呼每网管中心技术支援室 22/39 次 5 秒，当发生二次寻呼时 PSI 过程的时延就会大于 5 秒。解决办法：通过取消 MSC 的 PSI 的预寻呼功能问题得到解决。经验总结经验总结:多个网元配合完成的业务的投诉处理问题,需要涉及多个机型交换机及设备,今后工作有必要全面了解各设备的相关知识,这样能够提高问题定位速度和质量。网管中心技术支援室 23/39 案例案例 10：集团用户省内漫游后拨打同集团其集团用户省内漫游后拨打同集团其他成员的短号，听到提示他成员的短号，听到提示“对不起，您不允“对不起，您不允许呼叫此号码许呼叫此号码”故障现象故障现象：某集团用户省内漫游后拨打同集团其他成员的短号，听到提示音“对不起，您不允许呼叫此号码，再见”，之后呼叫释放 原因分析：原因分析：可能由于集团的权限或集团成员的某个权限设置有误导致,由于用户漫游,也可能 ATI 消息存在问题。处理步骤处理步骤：由于此用户发生漫游，在权限不足的情况下是会听见此提示的。1、检查用户归属集团的权限：允许省内漫游。2、检查用户权限：允许省内漫游且超出权限转个人付费，再查看debug 日志中的查询语句的返回结果，发现权限数据也正常，至此可以判断问题不是由权限导致的。3、对于主叫用户发生漫游的时候，业务在计费时需要考虑是否存在“同城特例”的情况，此时对于被叫用户的归属位置 SCP 会向HLR 下 发 ATI 消 息 去 查 询（此 功 能 由 mvpn_service 表controlflags3 字段的第 3 位控制）。4、查看 debug 日志中的 MAP 层消息，发现 SCP 下发 ATI 后 HLR 返网管中心技术支援室 24/39 回 TC_U_ERROR，之后呼叫转为普通呼叫。5、由于用户拨打的是被叫短号，此时业务会再查 mvpn_service表的 controlflags2 字段及 mvpn_isdntype 表，判断普通呼叫是否允许呼叫被叫短号，被叫号码是否为电视电话号码等，当所有条件都无法匹配时，系统向用户放提示音“您不允许呼叫此号码”。处理结果:维护人员检查 HLR 数据配置，发现其中关于 ATI 消息的数据配置存在问题，修改后问题解决。故障总结故障总结：1、对于呼叫业务，首先要熟悉呼叫流程。2、在查看日志时不仅仅要关注 CAP 层的消息，一些重要的 MAP 层消息同样需要关注。网管中心技术支援室 25/39 案例案例 11：SIM 卡问题导致卡问题导致 2/3G 空闲模式下空闲模式下重选失败重选失败-TD 案例案例 故障现象故障现象:在现网 TD 与 2G 互操作测试过程中发现，CS 通话过程中，TD可以切换至 G 网，切换后可以正常通话，但通话结束后，终端在 G 网下显示仅限紧急呼叫。空闲模式下双向重选失败。原因分析原因分析:1：异系统邻区关系配置问题；2：核心网侧数据配置问题；3：TD 和 G 数据配合问题；4：终端原因；5：其它原因；处理方式：处理方式：1：因 TD 在通话状态下，可以正常切换到 G 网，且切换后通话正常，基本可以排除邻区关系问题。经实际确认，系统间已互加邻区，邻区关系正确，邻区关系的各项参数正确。2：测试过程中还发现一个比较奇怪的现象：终端在通话状态下由 TD 切换成功至 G 网后，可以正常通话，但通话结束后，终端显示仅限紧急呼叫。每次测试均如此。3：对切换数据进行分析，发现手机在切换完成且正常挂机后，终端没有发送位置更新消息。对重选数据进行分析，终端有收到小区网管中心技术支援室 26/39 重选的信令，随后跟一条System To GSM Reselect Success:Abnormal Release(Direct into Idle mode)的信令。4：将终端网络模式设定为只用 2G 网络，终端显示仅限紧急呼叫，将终端网络模式设定为只用 3G 网络，终端显示正常，通话也正常。5：怀疑是终端问题，更换测试终端，问题依旧，排除终端问题。6：因终端在 G 网上根本就无法驻留，而终端问题又已经排除，怀疑是测试卡问题。更换测试卡后，终端可以正常驻留 G 网，重新进行测试，CS 业务可以从 TD 网络下正常切换至 G 网，TD 网络和 G 网络双向重选正常。问题解决。网管中心技术支援室 27/39 案例案例 12：2G 向向 3G 频繁重选的问题频繁重选的问题-TD 案案例例 故障现象：故障现象：郑州 2/3G 互操作优化调整工作开展后，2/3G 重选的问题比较多，测试时乒乓重选的现象比较严重。原因分析原因分析:从话务统计看，全网 PS 域 2G-3G 重选尝试次数全天 24 小时总计为 12 万次，从现网用户使用情况看明显偏高。起始时间 PS 域 2G-3G 重选尝试次数 PS 域 2G-3G 重选成功次数 PS 域 2G-3G 重选成功率 4 月 11 日 26348 24781 94.05%4 月 18 日 14759 14458 97.96%4 月 19 日 12718 12447 97.87%调整前全网 2G 侧重选参数 QSRI、QSRP 设置为：QSRI=QSRP=Always或Never，即GSM无条件开启对TD频点的测量，或直接关闭对TD频点的测量。TDD=Always或Never，即只要有满足小区选择条件的3G小区就进行异系统重选，或关闭异系统重选。从参数设置看，上述参数的设置，鼓励 2G/3G 之间的频繁切换与重选或关闭，设置极为不合理，需要进行全网参数进行优化调整。对于 2G 重选到 TD，我们认为如果 PCCPCH_RSCP 在-95dBm 以下，异系统互操作相对不安全，我们建议尽量在 TD 信号好且稳定时才重网管中心技术支援室 28/39 选，可以考虑选择较高的 TD 信号电平门限。QSRI、QSRP 对应表 QSRI（GPRS threshold to search UTRAN cells）和 QSRP（threshold to search UTRAN cells）来控制对双模手机对异系统 UTRAN 频点的测量：00-98-9888-78-781122-94-94-90-90991010-74-74-70-7033-86-861111-66-6644-82-821212-62-6255-78-781313-58-586677-74-74AlwaysAlways14141515-54-54NeverNeverR_BelowdBmR_UpperdBm00-98-9888-78-781122-94-94-90-90991010-74-74-70-7033-86-861111-66-6644-82-821212-62-6255-78-781313-58-586677-74-74AlwaysAlways14141515-54-54NeverNeverR_BelowdBmR_UpperdBm FDD and TDD cell reselect offset(FDD)对应表 FDD and TDD cell reselect offset(FDD)用来设置 TD 信号与GSM 信号的强弱差别程度来选择合适的小区 00-Always-Always88001122-28-28-24-24991010448833-20-201111121244-16-161212161655-12-12131320206677-8-8-4-41414151524242828RangedBmRangedBm00-Always-Always88001122-28-28-24-24991010448833-20-201111121244-16-161212161655-12-12131320206677-8-8-4-41414151524242828RangedBmRangedBm 从调整前的路测信令看，在 2G 信令侧打开 Systerm Information Type 2 quarter 消息，发现参数设置为 QSRI=QSRP=7，对 应 值 Always,TDD=0,对应值 Always.网管中心技术支援室 29/39 处理步骤处理步骤：经过认真分析，我们向 GSM 侧相关技术人员提交了参数修改建议，建议：QSRI=QSRP=8，对应值-78dBm，即 GSM 高于-78dBm 启动对 TD频点的测量；TDD=5,对应值-12dB，即 3G 低于 GSM 的差值小于 12dB进行重选。即：我们建议 2G 重选到 TD 时，TD 信号应该在-78dBm-12dB=-90dBm 以上。4 月 19 日，该参数在 2G 侧进行了调整，调整后我们进行了测试，2G 信令打开 Systerm Information Type 2 quarter 消息，发现参数设置为 QSRI=QSRP=8，对应值高于-78dBm,TDD=5,对应值-12dB.网管中心技术支援室 30/39 2G 侧参数调整后，我们统计了全网 PS 域 2G-3G 重选尝试次数，全天 24 小时总计为 5000 次作用，重选次数下降明显。时间 PS 域 2G-3G 切换尝试次数(小区)PS域2G-3G切换成功次数(小区)PS域2G-3G切换成功率 4 月 20 日 5331 5206 97.66%4 月 21 日 5924 5737 96.84%4 月 22 日 6960 6557 94.21%从调整前后全网的 2/3G 重选次数对比看，参数调整起到了较好的效果，全天 2G 向 3G 重选次数由调整前的 1200016000 次左右降低到5000 次左右。网管中心技术支援室 31/39 PS域2G-3G切换尝试次数(小区)400060008000100001200014000160004月18日4月19日4月20日4月21日4月22日 网管中心技术支援室 32/39 案例案例 13：邻区数据错误导致邻区数据错误导致 2/3G 互操作失互操作失败案例败案例-TD 案例案例 问题现象问题现象:在 23G 切换过程中，TD 切换到 2G 时，UE 已达到切换条件，UE 上报3A事 件 切 换 测 量 报 告measurementReport后，出 现RelocationPreparationFailure，导致 TD 切到 2G 失败。切换失败的信令如下：原因分析原因分析:从以上失败切换信令看，查看测量报告可确定为 TD 到 GSM 切换，切换事件为 3A，UE 测量报告无问题，信令如下：网管中心技术支援室 33/39 根据现场测试人员反馈 UE 完全达到切换条件但未进行切换，进行2 次测试均未切换成功。检查测量控制信息信令也未发现 GSM 小区信息有问题，信令如下：通过信令看，TD 所要切换到 GSM 小区信息（ncc：6；bcc：4，bcch：86）与实际切换的 GSM 小区相符，无问题。检查后台 23G 相关配置参数，均未发现问题。目前刚进行 23G 互操作，主要怀疑 2G 小区信息不准确，检查 2G小区对应的 LAC，得知此 2G 站点前一天刚进行割接，GSM 小区 LAC 号有变化，由原来 22805 变为 22814。查找 GSM 小区 LAC 号，如下：网管中心技术支援室 34/39 需注意的是以上 LAC 号 5915 为十六进制数值，转化为十进制数值为 22805，确定 GSM 小区配置 LAC 号为 22805。与移动割接后 LAC 不一致，需修改 LAC 再进行测试。处理方式：处理方式：对 GSM 小区修改 LAC 号，再进行验证，切换成功，信令如下：网管中心技术支援室 35/39 案例案例 14：去激活小区后无法重新激活的故障去激活小区后无法重新激活的故障解决解决-TD 案例案例 故障现象故障现象：B042 版本下，NODE B 侧新增一个 RRU，去激活小区并添加数据后无法重新激活小区，系统提示在线设定失败。原因分析原因分析：由于 CHRNC1 的 RNC 版本刚由 B161 升级为 B170，大部分 NODE B版本也已经升级到 B262。考虑到 CELL=110 的小区需要接入老版本的RRU，CELL=110 的室分系统 NODE B 版本保留为 B042。我们首先怀疑升级造成数据不一致引发故障。根据提示，执行 ACT CRC,但 CRC 校验结果显示数据并无不一致。怀疑添加 RRU 对数据进行改动时存在错误指令，于是将数据恢复网管中心技术支援室 36/39 为去激活小区前的状态，激活小区依然不成功。根据系统消息中 NODEB 硬件版本不一致的提示，怀疑 NODEB 硬件版本存在不匹配，使用 LST NODEB 指令查询 NODEB 硬件版本和软件版本，发现在 RNC 中注册的 NODEB 硬件版本全部为 HEAT，软件版本全部是 LCR40。而 HEAT 是基于 B261 及以上版本开发的硬件版本，B042版本不支持 HEAT，即 B042 版本的 NODE B 在 RNC 注册的硬件版本应为 510-520。处理步骤处理步骤：使用 MOD NODEB 命令，将 B042 版本的 NODE B 硬件版本由 HEAT改为 510-520。再进行激活小区的操作，执行成功。网管中心技术支援室 37/39 通过修改 NODE B 硬件参数，小区可以重新激活，现场测试功能正常，故障解决。网管中心技术支援室 38/39 案例案例 15：华为无线对接爱立信华为无线对接爱立信 MSC 视频电视频电话无法主叫案例话无法主叫案例-TD 案例案例 故障现象故障现象：华为 DRNC820 对接核心网 CS 域，爱立信 MSC，业务开通后，语音电话主被叫都正常，视频电话可以做被叫，主叫时提示：网络无法连接。原因分析原因分析：1.RNC 数据配置问题；2.核心网数据配置问题；考虑到可以作被叫，基本排除无