关于华为软交换端局局间呼叫掉话故障的排查报告
常见华为软交换故障
常见华为软交换故障一．故障分类华为软交换MSCServer今年第一季度故障根据有没有派单分成两类，有派单的是告警台上有相关告警，可以监控到的故障；另外一类是监控不到的，日常巡检中发现的故障。
以下是总结第一季度故障的具体类型。
1、派单故障：2、巡检故障：二．派单故障分析和处理根据故障的类型，简单介绍和分析故障，并给出处理意见和方法。
1．磁盘空间告警告警信息：XX局介质空间不足。
告警分析：主用IGWB在剩余磁盘空间小于15％的时候就会出磁盘空间告警，省公司要求话单保存时间：原始话单(D:\FORNTDAVE)15天，第一份最终话单（E：\BACKSAVE\X3KM\(HZM01)）15天，第二最终话单（E：\BACKSAVE\SECOND\X3KM\(HZM01)）90天。
告警处理：删除部分格式转换后的话单，剪切部分最终话单到应急工作站（暂时），新建话单备份机，在IGWB上压缩话单（待实现）。
告警级别：重要。
需及时处理，否则出现严重空间不足引起IGWB倒换。
2．单板故障告警信息：WSMU 板故障；单板CPU自检故障。
告警分析：该故障由单软的软件或硬件故障引起。
告警处理：1.复位 2.拔插 3.更换注意：一般要求处理单板故障必须在凌晨话务低时操作，对于备份的单板，只能对备用单板进行操作。
告警级别：重要。
涉及到WIFM,WBSG,WMGC,WCDB,WVDB,WSMU,WCSU等重要的单板需要向上级申请，及时更换单板或晚上操作。
3．电源故障告警信息：-48V 电源提供故障。
告警分析：根据指令DSP PDB可以查询到系统的电压正常范围是-42V～-57V,经常观察如果电压过高后，告警会在电压降到-54V的时候消除。
告警处理：观察一段时间，DSP PDB可查看当前电压值，分析告警原因，如果电压值正常，可通过SET PDBALMTHD:;设置PDB告警阀值恢复告警，如果是电源故障需联系动力值处理。
告警级别：紧急。
掉话及呼叫失败分析
1掉话问题1.1 掉话分析方法1.1.1话统分析：分析话统指标时，要先看BSC整体性能测量指标，掌握了网络运行的整体情况后，再有针对性地分析扇区载频性能统计。
分析时一般采取过滤法，先找出指标明显异常的小区分析，此时很可能是版本、硬件、传输、天馈（含GPS）或者数据出了问题导致的异常，可以结合告警首先从这几个方面检查。
如无明显异常，根据指标将各扇区载频进行统计分类，可整理出各重点指标较差小区列表，以便分类分析。
看指标时，不能只关注指标的绝对数值是高是低，关心的应该是指标的相对高低情况。
只有在统计量较大时，指标数值才具有指导意义。
1.1.2CDT数据分析及呼叫跟踪分析CDT（Call Detail Trace/呼叫详细跟踪）记录了一次呼叫过程中的基本信息（如：主叫、被叫号码、初始接入的小区、扇区、呼叫业务项、持续时长、引起呼叫释放的内部原因值等）和掉话发生时移动台所处的无线环境信息（如：掉话前激活集各个分支的小区号、扇区号、PN码、掉话前前向业务信道功率、掉话前反向EbNt等），我们可以利用这些信息对掉话进行分析。
CDT可以粗略分析到扇区级的呼叫信息如：接入小区、扇区，释放的内部原因，掉话时的分支信息；自动跟踪功能可以让路上行人作为路测对象，关注其详细流程；手动跟踪功能可以使网优人员有目的的定点路测，关注其详细流程。
1.1.3路测路测是了解网络质量、发现网络问题较为直接、准确的方法。
路测在掌握无线网络覆盖框架方面，具有话统等其它方法不可替代的特点。
包括了解是否有过覆盖、覆盖空洞，是否有上下行不平衡，是否有天馈装反，导致PN信号出现在不该出现的地方，等等。
特别在进行了参数调整或做了覆盖方面的调整后，如天馈调整、或功率配比等参数调整后，都需要路测了解这些调整是否达到了预期效果。
路测可以解决细节问题，但也有一定局限。
路测路线有限，时间有限，不可能得到网络完全数据，例如要想通过路测来找到掉话从而分析掉话原因是十分困难的，因为假定当前掉话率为3%，打100个电话才有3个掉话，而且很难找到掉话地点。
未接通、掉话及切换失败
未接通、掉话及切换失败分析一、未接通分析正常呼叫主叫起呼和被叫接入过程：主叫起呼信令流程图被叫接入信令流程图由主叫起呼信令流程图可以看出，主叫首先发出channel request report-→immediate assignment-→CM service request-→setup-→call proceeding-→assignment command-→assignment complete-→alerting-→connect-→完成一次起呼。
在主叫assignment complete 完成后2－3秒左右被叫开始信道请求流程Channel request report→immediate assignment-→setup→call confirmed→assignment command→assignment complete-→alerting→connect-→完成一次被叫接入。
1、未接通原因分析（1）RACH冲突或者AGCH拥塞建议：查看与RACH相关的参数――最大重发次数和发送分布时隙数以及与AGCH相关的参数――接入准许保留块数（2）SDCCH拥塞建议：检查SDCCH配置，查看相关小区SDCCH话务量（3）SDCCH掉话或者TCH拥塞建议：查看是否启用SDCCH信道上的切换，查看相关小区话务量和TCH配置，在排除无线方面原因后，应跟踪Abis接口、A接口信令从交换侧寻找问题原因（4）位置更新引起未接通建议：查看位置更新定时器和位置区设置（5）小区重选过程引起未接通建议：查看相关小区的小区重选参数2、未接通实例分析（1）SDCCH拥塞导致未接通在主叫完成起呼（assignment complete ）后2秒左右，此时被叫发起信道请求channel request report,由于SDCCH拥塞溢出，被叫手机无法获得SDCCH，重复2次发送信道请求后仍然无法获得SDCCH信道消息的回复，导致未接通的发生。
华为软交换常见告警
本局设备不能发送承载于M3UA 当本局到达M3UA目的实体没有配置M3UA路由或 的业务消息到产生告警的目的 所有M3UA路由均故障时，系统产生该告警。 实体。 故障的M3UA链路退出服务并且 当M3UA链路故障时，系统产生此告警 不能用于承载信令业务 对于主备配置的单板，如果备 板单板故障，则对业务无影 响，但是会严重影响系统可靠 性，备板故障必须及时修复。 对于主备配置的单板，如果主 板单板故障，系统会自动发生 主备倒换，从而使备板升为主 板，对业务只有微小影响，如 在倒换瞬间正在接续的业务建 立失败，但是会严重影响系统 可靠性，单板故障必须及时修 复。 当单板检测到自身运行故障或WSMU检测到与其 对于主备配置的业务单板，如 他业务板之间的通讯异常时，产生此告警。 果主板和备板同时故障，则该 单板所属的模块将无法承载任 何业务。注：业务单板指处理 业务的前插板，如：WCCU、 WCSU、WIFM、WVDB、WCDB、 WMGC等。 对于主备配置业务单板单配情 况，如果单板故障，则该单板 将无法承载任何业务。 对于负荷分担的单板，该单板 故障会导致该单板上的业务转 移到其他单板上，增加其他单 板的负荷。
SCTP路径，即使用SCTP协议作为传输协议的链 路（如M3UA/M2UA/IUA/H248/BICC链路等）， 如果在一条SCTP路径上传输数据或者心跳信息 时，没有收到证实消息，从而导致重传，当重 系统将不能通过该SCTP路径传 传次数达到“路径最大重传次数”（使用ADD 输相关的业务数据。
M3LNK/ADD M2LNK/ADD IUALNK/ADD H248LNK/ADD BICCSCTPLNK命令设置）时，系统认为这条SCTP路径不可 用，系统产生此告警。
计费中心长时间不取 iGWB话单
故障告警
掉话问题分析报告
掉话问题分析报告掉话是指在通话过程中，由于某种原因，使呼叫丢失或中断，正常通话无法进行的现象。
在一次通话中，接通之后如出现Disconnect或Channel Release中任意一条，就计为一次呼叫正常释放。
当两条消息都未出现而由专用模式转为空闲模式时，才计为一次掉话。
掉话的主要原因有：频点干扰、弱信号、越区覆盖、缺少邻区、硬件故障等。
下面列举在测试过程中遇到的几种掉话现象：1频点干扰导致掉话问题描述：MS在长江路上占用HF505A小区进行通话，BCCH频点113受HF007A小区同频干扰，发生7级质差，最终导致掉话。
相关数据：解决方案：修改HF007A BCCH：113->117，为了避免与HF060C小区同频，修改HF060C BCCH：117->114。
实施效果：现场复测，通话质量有了明显的改善，未再发生掉话现象。
2弱信号导致掉话问题描述：MS在环城路上占用信号不强的HF722B小区进行起呼通话，而不是占用主覆盖小区进行起呼，导致弱信号质差掉话。
相关数据：解决方案：修改HF722B CRO：6->2。
实施效果：现场复测，MS在该路段占用主覆盖小区HF007C进行通话，未再发生掉话现象。
3越区覆盖掉话问题描述：该问题点位于环城河附近，由于水面传播，HF119B小区的信号覆盖较远，MS在环城路上占用HF119B小区的信号，HF119B小区越区覆盖导致BCCH频点受严重干扰，最终产生掉话。
相关数据：实施效果：HF119B小区的信号电平在问题点处明显减弱，MS未再占用到HF119B小区的信号，掉话现象得以解决。
4小区信号反向导致掉话问题描述：MS在徽州大道HF016C小区方向上占用反向HF016A的信号，信号电平为-62dbm 左右，发生质差掉话。
现场进行反复测试并结合话务统计，发现该站天线并不存在天线接反的现象。
对现场无线环境进行勘测，HF016A小区正前方为一玻璃面高层，对信号产生明显的反射作用。
12 掉话问题分析
032a，表示是call control子层的release complete消息。
7. CN发RANAP_IU_RELEASE_COMMAND消息给RNC，开始释放Iu口
资源，包括RANAP层和ALCAP层资源。
8. RNC发RANAP_IU_RELEASE_COMPLETE消息给RNC。 9. RNC发RRC_RRC_CONN_REL消息给UE，开始释放RRC连接。 10. UE发RRC_RRC_CONN_REL_CMP消息给RNC。 11. RNC发NBAP_RL_DEL_REQ消息给NODEB，开始释放Iub口资源，
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 8
业务正常释放流程
PS业务正常释放的信令流程 PS业务正常释放的信令流程
1. UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nas message是0a46，表
示是session management子层的deactivate PDP context request消息。
1
2
3
RNC_CS_RAB_RE L_TRIG_BY_RNC _AAL2_LOSS
HUAWEI TECHNOLOGIES CO., LTD.
HUAWEI Confidential
Page 16
掉话分类定义
CS话统指标定义－面向小区 CS话统指标定义－面向小区
面向小区的CS掉话率公式： (RNC_CS_RAB_REL_CONV_CELL_TRIG_BY_RNC+RNC_CS_RAB_REL_STR_C ELL_TRIG_BY_RNC )/(CS_RAB_SETUP_SUCC_CONV_CELL +CS_RAB_SETUP_SUCC_STR_CELL )*100%
经典案例_异系统切换失败导致Volte掉话排查案例
异系统切换失败导致Volte掉话排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (9)异系统切换失败导致Volte掉话排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。
【关键字】VoLTE掉话异系统切换【业务类别】VoLTE一、问题描述2019年3月31日宣城电信RCU设备在市区进行拉网测试时出现VoLTE异常掉话现象，问题点位于宣州区水阳江大道宛陵湖展览馆附近。
测试设备在其他基站可以正常进行VoLTE呼叫，基本可以排除测试设备的问题。
并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。
需要信息分析优化定位故障并解决。
二、分析过程（一）、排查思路分析VoLTE掉话分为UE上下文释放、E-RAB承载释放两类掉话。
端到端信令VoLTE掉话：当eNodeB收到来自MME的E-RAB RELEASE COMMAND（UE CONTEXT RELEASE COMMAND）消息，或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”时，如果释放的承载包括QCI=1，则判断为VoLTE掉话。
ATU掉话导致频繁未接通问题分析处理
1、问题描述：在7月ATU测试中曾经出现主叫在1次掉话后，连续发生3次未接通。
为了彻底分析问题原因，测试时通过ATU、BSC、MSC对Um口、ABIS口、A口进行信令跟踪，重现该问题并予以解决。
在本次异常事件中，终端首先发生了一次掉话，之后出现4次未接通。
在这4次未接通中都是在终端发了CM SERVICE REQUEST信令后，系统下发CM SERVICE REJECT消息，说明网络侧拒绝了本次呼叫，且此时CM SERVICE REJECT消息携带原因值为：Reject cause Message compatible with（可理解为消息不兼容或呼叫不能识别），具体原因是系统认为终端正在进行某项业务（比如通话或短消息等），此时不能发起呼叫业务。
由于当时终端没有短消息和彩信等其他业务，因此可以判断是系统认为终端在掉话后，没有正常拆线仍然保持通话状态。
2、问题解决方案：经分析，华为公司在BSC9.0版本下，为了减少掉话，在BSC向BTS发了Handover Command之后，如果在T3103超时前收到BTS上报的Error Indication，为了挽救本次通话，BSC继续在原信道上等待MS上报的测量报告，在被叫主动挂机后才会清除本次通话连接。
也就是说在这种情况下，BSC向BTS发切换命令后T3103超时，BSC会向MSC发Clear Request；BSC没有下发切换命令，收到了BTS的Error Indication，也会向MSC发Clear Request；但是BSC向BTS发切换命令后，在T3103超时前收到了BTS 的Error Indication，则不会向MSC发Clear Request。
具体解决方案可以通过设置小区保留参数1的0bit来解决，将该bit位由0改成1，这样BSC收到Error Indication或T3103超时后，BSC立即向MSC发送CLEAR REQUEST进行拆线。
LTE掉话优化(华为)
秘密▲
连接与掉话的基本概念（3）
掉话的常见表现
2、空口信号变差等原因导致的掉话，从信令看：
只能看到信令不完整——UE在没有收到Release消息的情况下，直接从 RRC-CONNECTED状态转到RRC-IDLE。 此类掉话的一个典型表象为：UE发起了 RRCConnectionReestablishmentRequest、但是没有收到eNodeB发来的 RRCConnectionReestablishment，而且 UE也没有发出 RRCConnectionReestablishmentComplete消息。
秘密▲
常见掉话原因（4）——越区覆盖
优化手段
1. 越区覆盖的一般优化原则是：在区域中已有合理的稳 定信号覆盖的情况下、尽可能地控制越区覆盖的信号：
（1） 下调越区覆盖信号的功率 （2） 增加越区覆盖扇区的天线下倾角 （3） 在考虑了越区覆盖扇区周边的覆盖情况、以及网络拓扑结 构的情况下，谨慎地调整越区覆盖扇区的天线方位角
秘密▲
常见掉话原因（3）——邻区漏配
现象
Missing Neighbor
20 10 0 -10
Servin g Cell CINR
N1 CIN
R
Drop
-70 -90 -110 -130
Serving C ell RSRP
N1 RSRP
秘密▲
常见掉话原因（3）——邻区漏配
分析方法：采用信令分析法。
20 10 0 -10
Serving Cell CINR
Drop
Serving Cell CINR
Drop
N1 CINR
华为掉话问题分析
华为掉话分析第3章掉话问题分析3.1 概述在GSM网络运行中，掉话是用户投诉的热点，也是无线网络质量直接反映。
这里主要分析引起掉话的原因，以及通过哪些手段来定位问题，采用哪些办法来解决问题，从而降低掉话率，提高网络质量。
另一方面还可解决由掉话率高造成的最坏小区，降低最坏小区比，提高话务掉话比。
3.1.1 掉话问题描述掉话可分为两种形式：一类是在SDCCH信道上的掉话，一类是在TCH信道上的掉话。
SDCCH的掉话是指在BSC给移动台分配了SDCCH信道而TCH信道还未分配成功期间（包括只占用SDCCH信道的情况）发生的掉话。
TCH的掉话是指在BSC给移动台成功分配了TCH信道后，发生的不正常掉话。
造成掉话的原因，从全局角度来讲有三种：•无线链路超时（发生在通信过程中，消息无法正常接收）•T3103超时（发生在切换过程中，即MS无法占用目标小区信道，也无法返回原信道）•系统故障（设备故障等各种可能发生的故障）。
(1) 无线链路故障在这三种掉话原因中，主要的掉话形式是无线链路故障。
在GSM规范中有一参数为RADIO LINK TIMEOUT （无线链路超时）。
当移动台在通信过程中话音质量恶化到不可接收，且无法通过射频功率控制或切换来改善时，移动台认为无线链路故障，强行拆除链路，造成掉话。
GSM规范规定，移动台中有一计数器S，该计数器在通话开始时被赋予一个初值，即参数“无线链路超时”的值。
若移动台解码SACCH消息（周期480ms）失败，S减1；反之，移动台每正确接收到一SACCH消息，S加2，但S不可以超过初始被赋予的值，当S 计到0时，移动台报告无线链路超时。
信令流程如图3-1所示。
前面是相对于下行的情况，在小区属性表下的SACCH 复帧数（周期480ms），定义了上行链路连接失败时间。
当BTS检测到无线链路上一个被激活的连接被破坏时，就会向BSC上报连接失败消息CONNECT FAILURE。
系统判断连接失败的准则是基于上行链路SACCH 信道的误码率。
故障案例华为软交换
华为软交换端局（SERVER）与华为MGW的M3UA链路故障故障现象：SZS11与MZM02的一半M3UA链路都故障。
告警信息M3UA链路故障板类型=WBSG, 机架号=2, 框号=6, 槽号=14, 位置号=0, 模块号=145, M3UA链路名称=MZGM02-10(2), 本地IP地址1/IP地址2=10.125.30.10/10.125.30.138, 本地端口号=8102, 对端IP地址1/IP地址2=10.125.113.2/10.125.113.130, 对端端口号=7102, M3UA目的实体名称=MZGM02(2), 告警原因=SCTP偶联异常断链(原因码=48)M3UA SCTP路径故障板类型=WBSG, 机架号=2, 框号=6, 槽号=14,位置号=0, 模块号 = 145,链路名称=MZGM02-10(2),本地端口号=8102, 对端端口号=7102, 本地IP地址=10.125.30.138, 对端IP地址=10.125.113.130板类型=WBSG, 机架号=2, 框号=6, 槽号=14,位置号=0, 模块号 = 145,链路名称=MZGM02-10(2),本地端口号=8102, 对端端口号=7102, 本地IP地址=10.125.30.10, 对端IP地址=10.125.113.2原因分析：流程图：分析判断可能原因：1、IP层故障所导致。
2、数据配置存在问题。
3、单板软硬件故障。
原因排查：1、IP层故障分析先分析M3UA的协议栈：M3UASCTPIPMZM02是下挂在SZS11下的，这个M3UA是SERVER与MGW之间的。
从M3UA 链路故障告警上分析，原因码为48，是SCTP偶联异常断链，从协议栈上看，如果IP层出现故障，那SCTP层肯定是故障了，先判断是否IP层故障所导致呢？在MGW上进行PING包操作，华为MGW的本地维护终端提供了命令行和图形操作界面的PING包操作，本案例通过图像操作来进行PING包操作。
软交换局间切换故障的分析与解决
通过该专题分析， 使 软交 换局间切换成 功率恢 复正常， 同 时也为日后处理局间切换类 故障积累 了宝贵 的经验 ， 为避免类 似情况再次发 生， 我们可采取如下措施：
（ １ ） 新局入 网， 要加强对局数据 的核查力度 ， 重点关注 设备
Ｓ Ｃ Ｍ Ｇ 子系统 数据。
自 身数据特点 ， 诸如华为局间切换数据需要制作到Ｌ Ａ Ｃ ， 而爱立
手机在通话模式下， 按照系统信息中规定的相邻小区Ｂ Ｃ Ｃ Ｈ 频 点表测 量相关频点的强度并解读Ｓ Ｃ Ｈ 中的Ｂ Ｓ Ｉ Ｃ 上报给 网络， 网络根据系统定义的邻 区关 系， 按照Ｂ Ｃ Ｃ Ｈ 和Ｂ Ｓ Ｉ Ｃ 识别手机 所测
２ ． １后续切换失败
［ 故障现象］ ：
若满足切换算法， 则命令手机切换进 人该小区。 在基 测 试 人 员在 高 速 公 路 进 行 切 换 测 试 时 发 现 ， 手 机 在 量 的小区。 站分布密集的区域 ， 小区信号覆盖情况复 杂， 如 同Ｂ Ｃ Ｃ Ｈ 、同Ｂ Ｓ Ｉ Ｃ Ｈ Ｚ Ｓ Ｍ １ Ｂ ３（ 归属于Ｓ Ｚ Ｓ ０ ８ ） 切 换￣ Ｕ Ｈ Ｚ Ｄ Ｂ Ｓ Ｃ ２（ 归属于Ｈ Ｚ Ｄ Ｍ Ｓ Ｃ ） 再 的小 区Ａ 和 小区Ｂ 距 离较近 ， 小区Ａ 和小区Ｃ 定义了邻 区关系 ， 在 切换 ￣Ｈ Ｚ Ｓ Ｍ ９ Ｂ Ｉ（ 归属于 Ｓ Ｚ Ｓ ４ ２ ） 的过 程 中， 手机 无法 正常从
２ 各类切换故障的分析与解决
下面针对Ｉ ｎ ｔ ｅ ｒ — Ｍ Ｓ Ｃ 切换 的不同类 型 ， 对各类 故障 的原 因
资料 ， 发现 其Ｂ Ｃ Ｃ Ｈ 频 点￥ １ Ｂ Ｓ Ｉ Ｃ 与晶都酒店 的某个邻 区相同。
［ 原因分析］ ：
进行分析， 通 过列举典型案例 ， 探讨切换类 故障的解决办法。
WCDMA网络常见掉话现象分析及处理方法
WCDMA网络常见掉话现象分析及处理方法文章以WCDMA网络为例，重点分析了常见的网络掉话原因，并总结出掉话问题的处理方法以及掉话问题在网优各阶段的关注重点。
最后再通过一个典型掉话案例，帮助分析掉话产生的原因和对应的解决思路。
【摘要】【关键词】CDMA网络网络掉话导频污染杨 光 南京信息职业技术学院在使用手机通话过程中，由于某种原因而非正常终止双方通话的现象称为掉话。
在移动通信网络运行中，掉话现象是用户投诉热点。
因此，日常网络优化中要加强对掉话现象的分析与处理，以提高网络的服务质量，加强市场竞争力。
本文介绍了WCDMA网络掉话产生的常见原因及处理方法，并给出一个典型案例加以分析。
1 常见掉话原因1.1 邻区漏配一般来讲，初期优化过程掉话大多数是由于邻区漏配导致的。
对于同频邻区，通常采用以下办法来确认是否为同频邻区漏配：（1）观察掉话前UE（用户终端）记录的活动集Ec/Io信息和Scanner（扫频仪）记录的Best Server Ec/Io信息。
如果UE记录的Ec/Io很差，而Scanner记录的Best Server Ec/Io很好，同时检查Scanner记录Best Server扰码是否出现在掉话前最近出现的同频测量控制中，若测量控制中没有扰码，那么可以确认是邻区漏配。
（2）如果掉话后UE马上重新接入，并且UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，这可以通过测量控制进一步进行确认。
除此以外，邻区漏配还包括异频邻区漏配和异系统邻区漏配。
异频邻区漏配表现为掉话发生时，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上；异系统邻区漏配表现为手机在3G掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好。
1.2 弱覆盖判断覆盖差最简单的方式是直接观察Scanner采集的数据，若最好小区的RSCP和Ec/Io都很低，就可以收稿日期：2012-05-25责任编辑：袁婷 *****************认为是覆盖问题。
华为-GSM-掉话分析
GSM掉话分析一、华为GSM网络掉话原因分析及相关无线参数的修改在GSM网络运行中，掉话是用户投诉的热点，也是衡量无线网络质量的重要指标。
本文根据华为GSM网络优化的一些经验，结合网规网优理论，分析了掉话问题产生的原因，对与掉话相关的无线参数的作用做一点总结。
产生掉话的主要原因有：1.1覆盖原因：（1）不连续覆盖（盲区）由孤站引起的掉话，由于在孤站边缘，信号强度弱质量差，无法切换到其它小区而掉话。
由于基站所覆盖的区域地形复杂（如山区公路）、地势起伏，无线传播环境复杂，信号受阻挡，覆盖不连续造成掉话。
（2）室内覆盖差因为一些建筑物密集，信号传输衰耗大，加上建筑物墙体厚，穿透损耗大，室内电平低，使得在通话过程中掉话。
（3）孤岛服务小区由于各种原因（如功率过大）形成孤岛，以至于移动台超出了它所定义的邻小区B的覆盖范围之外到达了小区C后还占用着原服务小区A的信号，而小区A又未定义邻小区C，此时移动台再根据原服务小区A提供的邻小区B进行切换时，就会因找不到合适的小区而导致掉话，不连续覆盖（盲区）；对于覆盖原因产生的掉话，还是要具体分析原原因；在参数方面，与覆盖相关的参数，主要有四类：①MS最小接受信号等级②RACH最小接入电平③载频功率等级④最大时间提前量TAMS最小接受信号等级在搬迁时按照爱立信的设定值进行设定，城区基站较为密集，越区覆盖现象比较严重，所以在城区MS最小接受信号等级一般设为12或14；在郊区一般设为8或10；RACH最小接入电平都设为5（该值要比MS最小接受信号等级的值小，而且该值影响寻呼成功率，修改时要谨慎）；载频功率等级，城区基站，对于单载频配置的小区，由于不经过合路器，机顶输出功率大，路测时发现有越区覆盖现象；为防止越区覆盖产生掉话，所以把载频功率等级由0降为1。
至于最大时间提前量TA，在小区属性表中，开站时都设为62；1.2由于切换原因导致的掉话（1）参数设置不合理如两个小区相交的区域信号电平都很低，在参数上切换候选小区电平设置过低，切换门限设置太小，当邻小区电平某一时段稍强于服务小区时，一些MS就会切入该邻小区，而在切入后不久，恰好该小区的信号减弱，而又没有合适的小区再发生切换时就会掉话。
关于华为软交换端局局间呼叫掉话故障的排查报告
关于华为软交换端局局间呼叫掉话故障的排查报告作者：汕尾公司余跃虹一、隐患基本描述2010年5月1日，接到用户投拆，汕尾SWGM02局内呼叫正常，但局间呼叫接通后出现掉话现象，概率为10%~20%左右。
检查交换机设备正常，无异常告警；现网SWGM02 A口为TDM承载，局间为VOIP承载，而局内呼叫正常，可以排除A口侧设备故障；局间呼叫接通后出现掉话现象，此时通话由于需要完成TDM到IP的语音编解码转换，需要占用到语音处理单元MTCB板的TC资源，怀疑与TC资源相关的设备单板有隐性故障。
二、隐患排查分析1、首先介绍华为MGW的设备业务功能。
华为UMG8900设备提供与业务呼叫无关的业务承载功能，在MGC 的控制下实现业务承载转换和业务流格式处理。
对于UMG8900设备来说，不同业务的接续与交互过程，体现为IP、TDM、ATM和语音编解码等承载和业务资源的调用。
针对不同业务，MGW会分配不同的资源，通常一个呼叫分配的资源包含TDM资源、TC资源、EC资源,CC资源。
针对IP呼叫，还需要分配IP端点、UDP端口等。
要定位业务类的故障，必须知道该业务呼叫占用的系统资源和位置。
2、华为UMG8900设备与呼叫业务相关的TC资源、EC资源、CC 资源介绍。
UMG8900中，TC和EC是两种扣板，换句话说是两种资源。
TC扣在VPU的0号槽位和1号槽位，EC扣在VPU的2号槽位或扣在ECU 上。
TC可以提供编解码转换和放音收号功能。
当用于通信的两个终端之间没有可以共同支持的语音编解码格式时，需要通过TC资源来实现语音编解码的转换。
例如当发生类似于TDM-IP的呼叫需要进行编解码转换，此时需要添加TC。
EC：提供回波抵消功能。
在语音呼叫时有可能会添加EC。
EC可以插在ECU单板上，也可以插在VPB、VPD、TCB和TCD的2号槽位上。
CC：混音资源，就是常说的多方会议的MPTY资源。
它是由TC扣板提供，一块TC扣板插在0或1扣板槽位时可以提供1024个CC资源，插在2号扣板槽位时可以提供2048个CC资源。
华为GSM网络掉话分析
华为GSM网络掉话分析在GSM网络运行中，掉话是用户投诉的热点，也是衡量无线网络质量的重要指标。
本文分析了掉话问题产生的原因及其解决措施，并提供了典型的掉话案例。
一、掉话原因及其解决措施1. 由于覆盖原因导致的掉话2. 由于切换原因导致的掉话3. 由于干扰原因导致的掉话4. 由于天馈原因导致的掉话5. 由于传输原因导致的掉话6. 由于参数原因导致的掉话1. 由于覆盖原因导致的掉话【原因分析】（1）不连续覆盖（盲区）由孤站引起的掉话，由于在孤站边缘，信号强度弱质量差，无法切换到其它小区而掉话。
由于基站所覆盖的区域地形复杂（如山区公路）、地势起伏，无线传播环境复杂，信号受阻挡，覆盖不连续造成掉话。
（2）室内覆盖差因为一些建筑物密集，信号传输衰耗大，加上建筑物墙体厚，穿透损耗大，室内电平低，使得在通话过程中掉话。
（3）孤岛服务小区由于各种原因（如功率过大）形成孤岛，以至于移动台超出了它所定义的邻小区B的覆盖范围之外到达了小区C后还占用着原服务小区A的信号，而小区A又未定义邻小区C，此时移动台再根据原服务小区A提供的邻小区B进行切换时，就会因找不到合适的小区而导致掉话，如图1所示。
图1 覆盖过大导致的掉话（4）覆盖过小覆盖过小也有可能是由于某个小区的硬件设备出了问题，如天线受到阻挡或载频发生了故障（功放部分）。
【判断方法】根据用户的投诉，了解覆盖不足的地区，再进行较大范围的路测，观察信号电平大小，切换是否正常，是否存在掉话等，还可借助OMC话统查看BSC整体掉话率，找出掉话率大的小区，及其它相关的话统，来辅助分析和判断。
下面列举出了一些相关话统任务及统计项：（1）功率控制性能测量：是否平均上下行信号强度过低；（2）接收电平性能测量：接收电平低的次数所占比例过大；（3）小区性能测量/小区间切换性能测量：发起切换时电平等级过低，平均接收电平过低；（4）掉话性能测量：掉话时电平过低，掉话前TA值异常；（5）定义邻近小区性能测量：手机上报的在小区相邻关系表里定义的邻近小区的统计，可以定位到哪个邻区的平均电平过低；（6）未定义邻近小区性能测量：是否存在平均电平过高的未定义邻近小区；（7）功率控制性能测量：MS与BTS的最大距离（TA值），连续多个时段超常。
5G常见掉话问题定界分析与优化
5G常见掉话问题定界分析与优化
5G常见掉话问题定界分析与优化：空口原因导致掉话
空口原因导致掉话
●常见掉话场景 □下行RLC达到最大重传次数(默认32次) □上行RLC达到最大重传次数(默认32次) □SR达到最大次数(默认64次) □上行TA超时 ●常见掉话原因 □覆盖、干扰、切换问题，信号质量差，导致上下行高误码 □参数配置问题
5G常见掉话问题定界分析与优化：空口原因导致掉话
下行RLC达到最大重传次数
●下行发包时，会在上行接收UE反馈的状态报告，如果基站侧下行RLC层重传超 过32次，则L2会通知L3释放用户 ●下行RLC达到最大重传次数(默认32次) ●在以下几种情况下，RLC会发起重传 □收到对端的状态PDU的负确认( negative acknowledgement ) □没有收到对端的状态PDU，没有新数据发送，同时POLL周期定时器超时 □没有收到对端的状态PDU，发送窗满，同时POLL 周期定时器超时 问题定位 ●通常有类原因会导致RLC达到最大重传次数 □RLC层序号维护异常，包括UE侧上报了异常的状态报告 □下行MAC层误码很高，数据包总是传输错误，UE侧RLC层状态报告回复了大量 NACK，导致基站侧RLC层大量重传 □上行MAC层误码很高，数据包总是传输错误，基站侧RLC层收不到状态报告， 发起了大量重传
5G常见掉话问题定界分析与优化：非空口原因导致掉话
5G常见掉话问题定界分析与优化：非空口原因导致掉话
5G常见掉话问题定界分析与优化：非空口原因பைடு நூலகம்致掉话
5G常见掉话问题定界分析与优化：非空口原因导致掉话
5G常见掉话问题定界分析与优化：非空口原因导致掉话
5G常见掉话问题定界分析与优化：掉话重点参数排查
《SA站点终端掉话问题分析》
最佳实践上报表
《SA站点终端掉话问题分析》
在泉州某SA站点验证多个5G终端用户反映打电话掉话情况，跟踪信令分析掉话/掉线的原因，UE上下文释放携带原因CauseTransport_Root_unspecified。
45G用户面数据流交互走GTPU协议，即F1-U链路是UE级链路（动态）；信令面的走是SCTP协议，对应逻辑链路ENDC-X2AP是基站级链路（静态）。
这个类似于4G基站与SGW之间建立的是GTPU链路，和核心网的MME 建立的是SCTP S1AP，Option3X(EN-DC)协议栈图如下：
双IP场景：LTE基站传输层配置两个IP地址，映射一条SCTP链路。
平台对于信令传输有链路检测机制，当检测到某个IP地址故障时，会自动转换到非故障IP地址进行消息投递。
若两个IP均正常情况下，传输层使用负荷分担方式，选择IP。
异常释放均为跨PCE的SN添加场景（LTE侧发送EvPceDataFwdReq消息指示PCE进行数据反传，等待EvPceDataFwdRsp超时），PCE是否EvPceDataFwdRsp取决于是否收到LTE侧发送的关闸状态报告。
华为呼叫迁移与a口掉话初步分析报告
华为BSC 呼叫迁移功能与A 口掉话初步分析2009年6月，网优中心组织华为公司就掉话问题进行了技术交流，华为工程师讲述了在华为设备区进行跨BSC 切换的流程，其中有部份切换在特定情况下由BSC 申请、MSC 参与，华为公司称该流程为“呼叫迁移”。
网优中心统计华为BSC 间硬切换成功率平均只有90％左右，联系到前阶段的A2掉话高的问题，就呼叫迁移功能与A2掉话率是否产生影响进行了初步分析，下面简单地介绍一下。
图1图1为目前网络的基本示意图，为描述流程简洁，MSCe2+MGW 称为MSC2。
在一般情况下，MS 从BSC1下的BTS1通话移动到BSC2下的BTS2、BTS3或BTS4，在这个过程中MS 将与服务的BTS 发生切换，切换可能发生在2个BSC 间的2个BTS 之间，也可能发生在2个BSC 间的多个BTS 之间，在无线的切换过程中将会产生无线小区的合并过程，正常情况下，无线BSS 系统应该合并2个BSC 间可能发生切换的多个小区信息，通过2个BSC 间的A3/A7接口完成切换而不需要MSC 参与，目前，华为的2个BSS 间能够完成BTS1到BTS2的小区合并，但不能完成BTS1到BTS4的小区合并，所以，华为BSS 设计了呼叫迁移功能来弥补无线小区合并的不足，呼叫迁移实际上就是MSC 参与的硬切换，下面是呼叫迁移的主要信令流程。
一、“呼叫迁移”关键信令流程BTS4重庆 BSC11.源BSC的切换判决检测到需要进行呼叫迁移，其实就是要删除BSC1在激活中的唯一一个分支。
2.源BSC将目标小区的信息放在Handoff Required消息中发送到MSC。
MSC为切换分配一条地面电路，将电路的CIC、切换需要的无线信道类型等信息构造成Handoff Request 消息。
并且将该消息放在SCCP CONNECT REQUEST的用户数据域中发向BSC4（目标BSC），要求建立SCCP连接。
3.目标BSC和MSC完成SCCP的连接后开始处理层三的Handoff Request消息并建立Abis 地面链路，根据收到的Handoff Request消息中指定的无线信道类型，分配一条合适的无线业务信道。
WCDMA掉话分析报告及解决方法(精华)
WCDMA掉话分析及解决方法一、掉话的定义1.路测的掉话定义路测的掉话定义是：从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息满足以下3个条件的任何一个就视为路测掉话。
(1)收到任何的BCH消息（即系统消息）。
(2)收到无线资源释放的消息且释放的原因为非正常的。
注释：收到RRC Release消息（原因为非正常释放Not normal）(3)收到呼叫控制断开连接、呼叫控制释放等消息，而且释放的原因为非正常的。
注释：收到CC Disconnect，CC Release Complete，CC Release三条消息中的任何一条，而且释放的原因为Not Normal Clearing或者Not Normal，Unspecified。
2.话统指标中的掉话定义广义的掉话率应该包含CN和UTRAN的掉话率，由于我们做网优重点关注与UTRAN侧的掉话率指标，今天讲的掉话率描述也重点关注UTRAN侧的KPI指标。
注：UMTS Terrestrial Radio Access Network -- UMTS陆地无线接入网从大的方面讲，掉话分为两大类，信令面掉话和用户面掉话。
需要说明的是：无线接入网话统掉话的定义只从Iu接口的角度进行统计，统计了RNC主动发起的非正常资源释放的请求次数；路测的掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致。
“比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上看，这次主叫是没有掉话指标记录的。
所以两者的定义是不完全一致的，在分析时需加以区分。
”注：从RNC记录的信令上看，如果在Iu接口上看到了RNC 发向CN的消息为IuRelease Request或者RNC发给CN的消息为RAB Release Request消息，此时定义为异常掉话。
二、掉话原因分析由于掉话分析将涉及到具体的信令分析，因此本文参考华为设备的参数设置进行分析，而不同设备的参数定义并不一定相同，但是分析方法是相通的。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
关于华为软交换端局局间呼叫掉话故障的排查报告
作者：汕尾公司余跃虹
一、隐患基本描述
2010年5月1日，接到用户投拆，汕尾SWGM02局内呼叫正常，但局间呼叫接通后出现掉话现象，概率为10%~20%左右。
检查交换机设备正常，无异常告警；现网SWGM02 A口为TDM承载，局间为VOIP承载，而局内呼叫正常，可以排除A口侧设备故障；局间呼叫接通后出现掉话现象，此时通话由于需要完成TDM到IP的语音编解码转换，需要占用到语音处理单元MTCB板的TC资源，怀疑与TC资源相关的设备单板有隐性故障。
二、隐患排查分析
1、首先介绍华为MGW的设备业务功能。
华为UMG8900设备提供与业务呼叫无关的业务承载功能，在MGC 的控制下实现业务承载转换和业务流格式处理。
对于UMG8900设备来说，不同业务的接续与交互过程，体现为IP、TDM、ATM和语音编解码等承载和业务资源的调用。
针对不同业务，MGW会分配不同的资源，通常一个呼叫分配的资源包含TDM资源、TC资源、EC资源,CC资源。
针对IP呼叫，还需要分配IP端点、UDP端口等。
要定位业务类的故障，必须知道该业务呼叫占用的系统资源和位置。
2、华为UMG8900设备与呼叫业务相关的TC资源、EC资源、CC 资源介绍。
UMG8900中，TC和EC是两种扣板，换句话说是两种资源。
TC扣在VPU的0号槽位和1号槽位，EC扣在VPU的2号槽位或扣在ECU 上。
TC可以提供编解码转换和放音收号功能。
当用于通信的两个终端之间没有可以共同支持的语音编解码格式时，需要通过TC资源来实现语音编解码的转换。
例如当发生类似于TDM-IP的呼叫需要进行编解码转换，此时需要添加TC。
EC：提供回波抵消功能。
在语音呼叫时有可能会添加EC。
EC可以插在ECU单板上，也可以插在VPB、VPD、TCB和TCD的2号槽位上。
CC：混音资源，就是常说的多方会议的MPTY资源。
它是由TC扣板提供，一块TC扣板插在0或1扣板槽位时可以提供1024个CC资源，插在2号扣板槽位时可以提供2048个CC资源。
3、本故障原因分析与处理
对于多框承载业务MGW中，一次TDM到IP承载也就是案例中的局间呼叫，需要占用到TC资源，其业务流为：
ME32（TDM业务接口板）－TCLU（ TDM汇聚级连单元，为ME32同框）—MTNU（ TDM核心交换单元）—TCLU（ TDM汇聚级连单元，为MVPU同框）－MVPU（语音处理单元）－MNET（分组业务交换单元）－MHRU（高速路由转发板）－MG1O（后插IP分组接从上图可以看出，对局间呼叫，MGW将会涉及到上图中各种单元和资源的调用。
其转发流程为：
（1）、 UMG8900 设备通过后插E32 等TDM 接口单板接入TDM
承载业务流，通过内部TDM（TCLU/MTNU）交换到指定的VPU 单板上。
（2）、 VPU 单板接收到转发过来的TDM 承载业务流后，进行
编解码格式转换，转化为业务互通所需要的编解码格式，并封装为内
部通信数据包，然后通过内部分组业务总线转发给指定的HRB 单板。
（3）、 HRB 单板接收到转发过来的分组业务数据包后，去掉
内部通信的数据包头，然后对数据包进行分片、并完成RTP/UDP/IP 等
适配协议的处理，通过后插IP 分组接口单板转发出去。
再来看一下此次案例，局内呼叫正常，局间呼叫在接通后才出现
掉话，而根据以上所述，局间通话涉及TDM与IP承载的语音编解码
转换，怀颖是在VPU单板上的编解码转换不成功，也就是说TC资源
占用失败。
第一步是怀疑TC资源或对应语音处理单元MTCB（VPU）板有异常。
但是通过查询现网TC资源并没有异常状态。
%%DSP MEDIARES: QM=BTBN, BT=VPU;%%
RETCODE = 0 执行成功
资源查询信息
------------
框号槽位号板类型板组号资源块号资源块类型资源类型资源数空闲呼叫占用其他占用故障
1 0 VPU 0
2 VDB TC 512 467 45
0 0
1 1 VPU 1 0 VDB TC 51
2 462 50
0 0
1 2 VPU 8 0 VDB TC 512 447 65
0 0
1 2 VPU 8 1 VDB TC 512 453 59
0 0
0 0
2 0 VPU 2 0 VDB TC 512 462 50 0 0
2 1 VPU
3 0 VDB TC 512 460 52 0 0
2 2 VPU 9 0 VDB TC 512 455 57 0 0
2 2 VPU 9 1 VDB TC 512 44
3 69 0 0
2 2 VPU 9 2 VDB TC 512 45
3 59 0 0
2 3 VPU 10 0 VDB TC 512 436 76 0 0
2 3 VPU 10 1 VDB TC 512 469 43 0 0
2 3 VPU 10 2 VDB TC 512 468 44 0 0
3 0 VPU
4 0 VDB TC 384 34
5 39 0 0
3 0 VPU
4 0 VDB CC 256 244 12 0 0
3 1 VPU 5 2 VDB TC 448 39
4 54 0 0
3 1 VPU 5 2 VDB CC 256 252
4 0 0
3 2 VPU 6 0 VDB TC 512 461 51 0 0
3 2 VPU 6 1 VDB TC 512 447 65 0 0
3 2 VPU 6 2 VDB TC 512 459 53 0 0
3 3 VPU 7 0 VDB TC 512 461 51 0 0
3 3 VPU 7 1 VDB TC 512 45
4 58 0 0
3 3 VPU 7 2 VDB TC 512 461 51 0 0
4 0 VPU 11 0 VDB TC 512 446 66 0 0
4 0 VPU 11 1 VDB TC 512 46
5 47 0 0
4 0 VPU 11 2 VDB TC 512 454 58 0 0
0 0
4 1 VPU 12 1 VDB TC 512 459 53
0 0
4 1 VPU 12 2 VDB TC 512 458 54
0 0
(结果个数 = 29)
资源统计信息
------------
资源类型资源数空闲呼叫占用其他占用故障
TC 13632 12159 1473 0 0
CC 512 496 16 0 0
--- END
接下来对MTCB板逐板检查，最后发现，将第4框的两个MTCB板
闭塞掉后，故障恢复，局间呼叫正常，那是不是就可以确定这两块MTCB板有故障呢？答案是否定的，当时更换这两块MTCB板，解闭后
再进行拔测，还是出现局间呼叫掉话现象。
第二步怀疑第4框的TCLU板有故障。
通过查看MGW配置，第4
框中并没有配置ME32板或MS2L板，而由现网可以查到，设备上配置
的TC资源管理策略为所有框内轮选资源。
%%LST RESPLCY:;%%
RETCODE = 0 执行成功
资源管理策略配置表
------------------
TC/EC资源本框优选比例 = 0%（当本框优选比例设定为0时，表示当前资源管理策略为在所有框内轮
选资源。
）
IP资源本框优选分配比例 = 0%
公共编解码集优选策略 = 优选G711,再轮选其余编解码集
--- END
这就说明，从其他框ME32上来的业务呼叫，系统有可能会轮选
到4框中的两个MTCB板中的TC资源，此时，从A口上来的业务最终需要流转到4框的TCLU板，才能够占用到该框MTCB板的TC资源。
而当4框的TCLU板出现故障时，业务流就访问不到MTCB板进行编解码转换而导致通话失败，所以该框TCLU板也是可能故障点之一。
由于TCLU板是主备用，当对TCLU板进行主备倒换后，拔测恢复正常，由此，可以确定此次故障的元凶是在4框的主用TCLU板，进行硬件更换后，倒回主用侧测试通过。
三、隐患解决措施
华为UMG8900设备提供与业务呼叫无关的业务承载功能，在MGC 的控制下实现业务承载转换和业务流格式处理。
由于现网华为UMG8900设备的主动告警监测功能不完善，通常故障点并没有产生相应的告警，要定位业务类的故障，必须知道该业务呼叫占用的系统资源和位置，通过对UMG8900业务流的学习分析，在解决故障时需要进行有目的的排查，从最有可能发生故障的点开始，通过业务拔测和设备状态的观察找出故障原因。
四、本地解决情况
对于此次局间呼叫掉话现象，通过对华为MGW处理TDM-IP的业务流的分析，逐步排查，最后确定了故障单板并进行了更换，这次在处理的过程中，维护人员也得到了很好的学习机会，对华为UMG8900设备提供与业务呼叫无关的业务承载功能进行了一次很好的梳理和总结，更加深入的理解了华为UMG8900实现业务承载转换和业务流格式处理的方式。