VOLTE-TAU失败导致掉话问题分析
案例3：TAU失败导致掉话分析
问题描述：
查看信令流程，主叫占用朝阳亚运村HL-3发生掉话，携带原因值为承载丢失。。
查看掉话前信令，主叫占用朝阳马甸家园B栋HL-4跨POOL切换至朝阳亚运村HL-3小区后，发起TAU 更新，MME未回TAU接收消息，TAU更新失败导致承载丢失。
TAU更新失败。
MME未回TAU接收消息。问题原因：
诺基亚核心网问题。
WCDMA掉话问题分析及处理方案
WCDMA掉话问题分析及处理方法 作者：南京格安 在国外，W CDMA已经在多个国家投入商用；在国内，WCDMA产品正逐步走向成熟，网络商用化的脚步正在加快。在网络建设及运营中，掉话率（calldroprate）是反映网络质量的重要指标之一；掉话问题也是日常网络优化面临的一个常见问题。本文从掉话的定义、掉话处理的基本流程、各种掉话数据分析方法、掉话问题的解决方法等方面加以研究，并结合实际掉话案例进行分析。 一、掉话的定义 1.路测的掉话定义 路测的掉话定义是：从UE侧记录的空口信令上看，在通话过程（连接状态下）中，如果空口的消息满足以下3个条件的任何一个就视为路测掉话。 (1)收到任何的广播信道消息。 (2)收到无线资源释放的消息且释放的原因为非正常的。 (3)收到呼叫控制断连接、呼叫控制释放等消息，而且释放的原因为非正常的。 2.话统指标中的掉话定义 广义的掉话率应该包含CN和UTRAN的掉话率，由于网优重点关注与UTRAN侧的掉话率指标，本文掉话率描述也重点关注UTRAN侧的KPI指标。 从大的方面讲，掉话分为两大类，信令面掉话和用户面掉话。 需要说明的是：无线接入网话统掉话的定义只从Iu接口的角度进行统计，统计了RNC 主动发起的非正常资源释放的请求次数；路测的掉话定义主要从空口的消息和非接入层的消息结合原因值来进行定义的，两者不完全一致。比如说，对于同时进行主被叫通话，工具记录主叫的空口消息，如果被叫异常掉话，那么分析主叫的流程也会是一次掉话，但从话统上
看，这次主叫是没有掉话指标记录的。所以两者的定义是不完全一致的，在分析时需加以区分。 二、掉话原因分析 由于掉话分析将涉及到具体的信令分析，因此本文参考华为设备的参数设置进行分析，而不同设备的参数定义并不一定相同，但是分析方法是相通的。 1.邻区漏配 一般来讲，掉话在初期优化过程中大多数是由于邻区漏配导致的。对于同频邻区，通常采用以下方法来确认是否为同频邻区漏配。 方法一：观察掉话前UE记录的活动集EcIo信息和记录的BestServerEcIo信息。如果UE记录的EcIo很差，而记录的BestServer EcIo很好，同时检查记录Best Server EcIo 扰码是否出现在掉话前最近出现的同频测量控制的邻区列表中。如果同频测量控制的邻区列表中没有扰码，那么可以确认是邻区漏配。 方法二：如果掉话后UE马上重新接入，UE重新接入的小区扰码和掉话时的扰码不一致，也可以怀疑是邻区漏配问题，可以通过测量控制，进一步进行确认（从掉话位置的消息开始往前找，找到最近一条同频测量控制消息，检查该测量控制消息的邻区列表）。 方法三：有些UE会上报检测集（DetectedSet）信息，如果掉话发生前检测集信息中有相应的扰码信息，也可以确认是邻区漏配的问题。 邻区漏配导致的掉话包括异频邻区漏配和异系统邻区漏配。异频邻区漏配的确认方法和同频几乎相同，主要是掉话发生的时候，手机没有测量或者上报异频邻区，而手机掉话后重新驻留到异频邻区上。异系统邻区漏配表现为手机在3G网络掉话，掉话后手机重新选网驻留到2G网络，从信号质量来看，2G网络的质量很好（在掉话点用2G测试手机观察RSSI信号）。 2.覆盖差
语音呼叫失败原因分析
语音呼叫失败原因分析 经过第一阶段局外提供的相关数据，对后台的业务观察中，失败的语音呼叫、语音释放、切换等失败的原因进行简单的分析，整理成为这篇初稿，为局外的用服人员提供一个指导。 1．ERR_SPS_RLSA_RCM_DBAccFail_FCHResourceAllocate 2．ERR_SPS_RLSA_RCM_PCALL_OtherReason_CEC_REMOVEREQ
3．ERR_SPS_RLSA_RCM_FCH_TimerExpired_TconnExpired 4．DBS_STASTIC_NO_RESOURCE_LACK 5．DBS_STASTIC_FWDFCHCE_LACK 6．DBS_STASTIC_REVFCHCE_LACK
7．DBS_STASTIC_FWDFCHCE_REVCE_LACK 8．DBS_STASTIC_FWDSCHCE_LACK 9．DBS_STASTIC_WALSHCODE_LACK １０．DBS_STASTIC_UID_LACK １１．HO_STAT_PILOT_NO_SAME_FREQ
１２．HO_STAT_CARRIER_PWR_OVERLOAD １３．ERR_SPS_RLSA_DSPM_CLH_TimerExpired_Twaitorder １４．ERR_SPS_RLSA_DSPM_CLH_OtherReason_SNFailure １５．ERR_SPS_RLSA_DSPM_CLH_OtherReason_Tshakehandrecv
１６．ERR_SPS_RLSA_DSPM_HOH_OtherReason_AbisdShakeHandFailure １７．ERR_SPS_RLSA_DSPM_HOH_DBAccessFail_GetHandoffProc １８．ERR_SPS_RLSA_DSPM_HOH_DBAccessFail_GetInterFreqSSHO １９．ERR_SPS_RLSA_DSPM_HOH_TimerExpired_Thoreq
VoLTE业务资料VoLTE问题案例集
VoLTE网上问题案例集 文档版本V1.0 发布日期2015-01-28
华为技术
修订记录
目录 1导读 (5) 2语音呼叫类问题 (6) 2.1呼叫失败 (6) 2.2单通 (35) 3语音质量类问题 (61) 3.1语音质量差 (61) 4语音增强特性类问题 (82) 4.1RoHC (82) 4.2TTI_Bundling (89) 4.3SPS (92)
1导读 本文根据以往网上问题整理VoLTE相关问题的相关案例，在处理网上语音问题时，可以先翻阅本文相关案例，以拓展思路并缩小问题围，最终提升问题定位效率。 本文所包含案例包括从各产品收集到的历史案例，以及GTAC VoLTE专题组启动后处理的问题提取出来的案例，在案例格式上有些差异，后续逐步统一。 本文档会逐步完善，新需求或建议，请联系曾佳 00130333。
2语音呼叫类问题 2.1呼叫失败 案例1：英国VDF，VoLTE用户呼叫失败问题分析 【问题描述】 英国VDF在11月15号下午反馈同一终端同一套核心网，在爱立信/诺西基站下成功打通VoLTE call，在华为基站下必然失败； 问题表现为：VoLTE终端开机后，QCI5、默认承载均可建立但无法建立QCI1导致 不能通话； 【问题分析】 1.组网环境信息分析 1.1VoLTE业务原理分析 正常VoLTE业务流程分为以下几个过程： a)VoLTE终端完成TAU Attach流程建立QCI5承载； b)VoLTE终端发起IMS注册流程, 注册使用的SIP信令使用QCI5承载； c)VoLTE终端发起语音呼叫，建立QCI1专有承载，语音媒体使用QCI1承载； d)VoLTE终端发起视频呼叫，建立QCI2专有承载，视频媒体使用QCI2承载；
10-掉话类故障分析与处理
M900/M1800 基站子系统故障处理手册目录 目录 第10章掉话类故障分析与处理...........................................................................................10-1 10.1 概述...............................................................................................................................10-1 10.1.1 掉话问题描述......................................................................................................10-1 10.1.2 掉话的计算公式..................................................................................................10-3 10.2 导致掉话的几种因素......................................................................................................10-4 10.2.1 覆盖引起的掉话..................................................................................................10-4 10.2.2 切换引起的掉话..................................................................................................10-6 10.2.3 干扰引起的掉话..................................................................................................10-8 10.2.4 天馈引起的掉话................................................................................................10-10 10.2.5 传输引起的掉话................................................................................................10-11 10.2.6 无线参数设置不合理.........................................................................................10-11 10.2.7 其它原因引起的掉话.........................................................................................10-12 10.3 典型案例......................................................................................................................10-13 10.3.1 优化切换参数减少掉话.....................................................................................10-13 10.3.2 直放站干扰引起掉话.........................................................................................10-13 10.3.3 MAIO相同引起干扰掉话...................................................................................10-15 10.3.4 上下行不平衡....................................................................................................10-15 10.3.5 孤岛效应引起掉话.............................................................................................10-16 10.3.6 与版本相关的参数设置.....................................................................................10-17
VOlte语音通话错误码
100 正在尝试 180 正在拨打 181 正被转接 182 正在排队 183 通话进展 2xx = 成功应答 200 OK 202 被接受：用于转介 3xx = 转接应答 300 多项选择 301 被永久迁移 302 被暂时迁移 305 使用代理服务器 380 替代服务 4xx = 呼叫失败 400 呼叫不当 401 未经授权：只供注册机构使用，代理服务器应使用代理服务器授权407 402 要求付费（预订为将来使用) 403 被禁止的 404 未发现：未发现用户 405 不允许的方法 406 不可接受 407 需要代理服务器授权 408 呼叫超时：在预定时间内无法找到用户 410 已消失：用户曾经存在，但已从此处消失 413 呼叫实体过大 414 呼叫URI过长 415 不支持的媒体类型 416 不支持的URI方案 420 不当扩展：使用了不当SIP协议扩展，服务器无法理解该扩展 421 需要扩展 423 时间间隔过短 480 暂时不可使用 481 通话/事务不存在 482 检测到循环 483 跳数过多 484 地址不全 485 模糊不清 486 此处太忙 487 呼叫被终止 488 此处不可接受
491 呼叫待批 493 无法解读：无法解读S/MIME文体部分 5xx = 服务器失败 500 服务器内部错误 501 无法实施：SIP呼叫方法在此处无法实施 502 不当网关 503 服务不可使用 504 服务器超时 505 不支持该版本：服务器不支持SIP协议的这个版本513 消息过长 6xx = 全局失败 600 各处均忙 603 拒绝 604 无处存在 606 不可使用
详细讲解WCDMA掉话问题分析及优化方法
WCDMA 掉话问题分析 第一章掉话分类定义 第一节正常释放流程 一个CS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0325，表示是call control 子层的disconnect消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0325，表示是call control 子层的disconnect消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是832d，表示是call control 子层的release消息。 4.RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是832d，表示是call control子层的release消息。 5.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是032a，表示是call control 子层的release complete消息。 6. RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是032a，表示是call control 子层的release complete消息。
https://www.360docs.net/doc/a912972620.html,发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口资源，包括NBAP层和ALCAP 层，PHY层资源。 12. NODEB发NBAP_RL_DEL_RSP消息给RNC，整个释放过程结束。 一个PS正常释放信令流程 1.UE发RRC_UL_DIR_TRANSF消息给RNC，消息中nasmessage是0a46，表示是session management子层的deactivate PDP context request消息。 2.RNC发RANAP_DIRECT_TRANSFER消息给CN，消息中naspdu是0a46，表示是session management子层的deactivate PDP context request消息。 3. CN发RANAP_DIRECT_TRANSFER消息给RNC，消息中naspdu是8a47，表示是session management子层的deactivate PDP context accept消息。 4. CN发RANAP_RAB_ASSIGNMENT_REQ消息给RNC，消息中给出要释放的RAB list，其中包含了要释放的RAB ID。 5. RNC发RRC_DL_DIRECT_TRANSF消息给UE，消息中nasmessage是8a47，表示是session management子层的deactivate PDP context accept消息。 6. RNC发NBAP_RL_RECFG_PREP消息给NODEB。 7. NODEB发NBAP_RL_RECFG_READY消息给RNC， 8. RNC发RRC_RB_REL消息给UE，释放业务RB。 9. NODEB发NBAP_RL_RECFG_COMMIT消息给RNC，
移动VOLTE部分用户关闭VOLTE功能后呼叫失败问题分析
移动VOLTE部分用户关闭VOLTE功能后呼叫失败问题分析 发表时间：2018-05-31T15:04:48.147Z 来源：《基层建设》2018年第10期作者：杨奎 [导读] 摘要：目前VOLTE正在逐步替换2G语音，因网络结构复杂过程中会产生各种问题，本论文分析了此次呼叫失败的原因及处理措施。 中国移动通信集团河北有限公司唐山分公司河北唐山 063000 摘要：目前VOLTE正在逐步替换2G语音，因网络结构复杂过程中会产生各种问题，本论文分析了此次呼叫失败的原因及处理措施。 关键词：VOLTE，MGCF，IMS 1，VOLTE简介： VoLTE是基于IMS的语音业务。IMS由于支持多种接入和丰富的多媒体业务，成为全IP时代的核心网标准架构。经历了过去几年的发展成熟后，已经被3GPP、GSMA确定为移动语音的标准架构。VoLTE即Voice over LTE，它是一种新型IP数据传输技术，无需2G/3G网，全部业务承载于4G网络上，可实现数据与语音业务在同一网络下的统一。换言之，4G网络下不仅仅提供高速率的数据业务，同时还提供高质量的音视频通话，后者便需要VoLTE技术来实现。 2，问题描述： 河北移动中兴IMS割接后，唐山移动用户反馈，开通VOLTE业务，但是终端上关闭VOLTE功能并且用户联合位置更新到唐山POOL3的端局时（其它POOL端局没有问题），做被叫失败，主叫侧听到嘟嘟通知音，被叫无反应。 3，问题分析： 3.1进行问题复测，从被叫MSC端局跟踪的信令看，MSC端局收到关口局发送的IAM消息后，直接发送了REL消息释放呼叫，原因值为：”Normal unspecified（31）”。将用户归属IMS域改到华为后拨测没问题，对比华为MGCF和中兴MGCF发的IAM消息，有三处区别： 1)中兴IAM消息里Transmission Parameter requirement为speech，华为为3.1k audio 2)中兴IAM消息里的编解码写上列表里有AMR2和G.711，而华为只有G.711 3)中兴IAM消息里有redirection information字段，华为没有这些字段 3.2是携带的Transmission Parameter字段为speech导致 3.3中兴MGCF修改参数，将该字段填写为3.1k audio后，经过复测，问题现象依旧，排除该参数问题。 3.4可能是IAM消息中的Redirection Information字段导致，在中兴MGCF上修改参数，IAM消息中不携带该字段，拨测，被叫能接通。 3.5但是Redirection Information字段是3GPP协议规定字段，MGCF发送该字段是符合协议规范的。 本着尽快解决问题的原则，中兴MGCF增加相关配置，将redirection information字段屏蔽掉，暂时规避该问题。问题的最终解决需要爱立信进行本设备问题定位。
掉话原因及处理
GSM网络优化中掉话、拥塞的原因及解决办法 1．掉话 在移动通信中，掉话是指在分配了话音信道（TCH）后，由于某种原因，使呼叫丢失或中断，正常通话无法进行的现象。掉话不仅影响网络指标，而且会给用户造成许多不便，是用户投诉的热点。 1.1掉话产生的原因 1、由干扰引起的掉话： 干扰主要包括同频、邻频及交调干扰。当手机在服务小区中收到很强的同频或邻频干扰信号时，会引起误码率恶化，使手机无法准确解调邻近小区的BSIC码或不能正确接收移动台测量报告。基站在通过SDCCH为手机分配好应使用的话音信道后,由于没有临近小区BSIC码而无法判断该使用哪个小区的话音信道，从而产生掉话。交调干扰主要来自于外部干扰，如CDMA站会对我基站上行频率产生干扰。 2、由于切换引起的掉话： （1） MS在通话中，手机列表中计算6个最好的相邻小区为切换做准备，但当网络覆盖不好时，会产生频繁切换，造成无主控小区，产生掉话。 （2）一些小区由于话务忙，会把话务推给相邻小区，但当相邻小区信号不好或无空闲信道时就会产生掉话。 （3）孤岛效应。如果服务小区A由于地形的原因产生的场强覆盖小岛C，而在小岛C周围又为小区B的覆盖范围，如在A的相邻小区列表中未添加小区B，那么当用户在C 中建立呼叫后一走出小岛C，由于无处可切换将产生掉话。 3、参数设置不合理引起的掉话： 影响掉话的参数主要有切换参数和相邻小区参数。如：PMRG设置过高或相邻小区参数做错都会导致掉话。 4、基站硬件引起的掉话： BTS的硬件故障也会引起掉话，NOKIA设备中的7745（CHANNEL FAILURE RATE ABOVE DEFINED THRESHOLD） 、7949 （DIFFERENCE IN RX LEVELS OF MAIN AND DIVERSITY ANTENNA / TRX）是特别要引起注意的，因为这些告警同时伴随着掉话。 5、Abis接口失败产生的掉话 Abis接口的，包括BSC未收到来自BTS的测量报告，超过TA极限，切换过程的一些信令失败以及一些内部原因，此外还有Abis接口的误码率的影响。 6、覆盖不好引起的掉话： 有些小区由于覆盖范围过大造成在小区覆盖的边缘地带信号不好，电平值很低，手机列表中测量的相邻小区的电平值又达不到接入的要求（如RXLEV ACCESS MIN＝－95dBm）而引起掉话，在边远地区、网络覆盖不好的情况下经常会出现这种掉话。 1.2 掉话的解决办法 如果一个小区掉话很高，可以先通过查掉话报告（如163报告），先确定是由于哪方面引起的掉话。 （1）对于由于切换引起的掉话的解决，可先进行大范围的路测，通过路测可以确定是和哪个相邻小区切换不正常。对于一些与该小区有切换关系而拥塞率又较高的小区应作为测试的重点，并需要检查小区周围是否有盲区存在，如果是这种原因应及时修改相关频率并
融合语音通信平台解决方案
融合语音通信平台 解决方案
目录 1概述 (1) 2组网设计 (1) 3功能介绍 (3) 3.1基本业务功能 (3) 3.2指挥调度功能 (3) 3.3调度台功能 (6) 3.4录音功能 (7) 3.5业务功能扩展扩容要求 (8) 4配置清单（根据实际需求进行配置） (8) 4.1核心调度通信服务器 (8) 4.2数字录音服务器 (9) 4.3无线接入网关 (11) 4.4触摸屏调度台 (12) 4.5模拟用户接入网关（IAD） (13) 4.6数字中继网关 (14) 5.设备一览表 (16)
1概述 融合语音通信平台主要用于搭建一个集使用模拟、功能演示、性能验证于一体的内/外通话音通信演示平台，通过系统演示平台可模拟实现不同类型信道控制管理、不同类型信道的互通、不同频率信道互通以及信道优先级调度控制等功能。 2组网设计 根据实际应用需求，平台所配置的通信调度服务器提供基本的交换功能、调度功能。无线接入网关支持短波电台、对空超短波电台、对海超短波电台等外通设备的接入几大功能模块。E1/FXO/SIP中继可与海事卫星、Ku波段卫通、C波段卫通等对接，与单兵设备对接设备提供的（如SDK/SIP等）接口。模拟用户则可通过IAD接入平台，实现局内互通。数字中继网关通过与PLMN互联实现手机终端的接入。录音服务器提供通话录音服务。用户可通过触摸屏调度台实现指挥调度功能，可根据用户权限设置，高权限用户比如领导专用调度台可对低权限用户（指挥中心，值班室等）进行强插、强拆等操作，实现分级指挥调度功能。 组网说明： 融合语音通信平台主要由通信调度服务器、录音服务器、中继网关、无线接入网关、IAD、调度台等组成。
高掉话小区处理流程
高掉话小区处理流程建议 1. 背景 掉话率反映了系统话音业务的通讯保持能力，反映了系统的稳定性和可靠性，反映统计时间话音信道占用后因各种原因导致掉话严重程度，是无线通讯系统的重要性能指标，当系统的掉话率高时，会严重影响用户的感知，从而导致用户投诉或不满。此次我们主要针对TCH掉话的分析过程进行说明。 在NOKIA设备中，掉话次数count主要统计的是掉话出现在哪个接口，如：无线口、A_BIS口，A 口等等，并没有按掉话原因类型进行分类，如：信号质量差掉话或TA掉话等等，因此，在NOKIA设备中，应该按照掉话出现的接口进行分析。 2. 3J掉话率公式 (sum(a.tch_radio_fail+a.tch_rf_old_ho+a.tch_abis_fail_call+a.tch_abis_fail_old +a.tch_a_if_fail_call+a.tch_a_if_fail_old+a.tch_tr_fail+a.tch_tr_fail_old +a.tch_lapd_fail+a.tch_bts_fail+a.tch_user_act+a.tch_bcsu_reset +a.tch_netw_act+a.tch_act_fail_call)-sum(b.tch_re_est_assign))/ (sum(a.tch_norm_seiz)+sum(c.msc_i_sdcch_tch+c.bsc_i_sdcch_tch+c.cell_sdcch_tch)-sum(a.tc h_succ_seiz_for_dir_acc)+sum(a.tch_seiz_due_sdcch_con) -sum(b.tch_re_est_assign))*100% Counters from tables: A = p_nbsc_traffic B = p_nbsc_service C = p_nbsc_ho 上表就是NOKIA设备中，分为在各个接口的14类掉话。
CDMA呼叫失败原因分析
CDMA网络中几种呼叫失败原因分析 关于用户反映电话不好使用的几种情况分析： 一、覆盖不足引起的呼叫失败： 典型现象： 1、移动台前向接收功率Rx Power 大约在－100dBm 左右或更小； 2、移动台反向发射功率Tx Power 趋向于最大值23dBm； 3、最强导频强度Ec/Io 小于－15dB 或者更小； 4、移动台发出起呼消息后，迟迟无法接入成功，最后显示呼叫失败。现象分析： 1、移动台由于覆盖不足而发生呼叫失败是一种正常现象； 2、当移动台在覆盖边缘发起呼叫，由于空中链路很差，其与基站之间的信令传递很可能由于空中衰减太大而不能被对方正确接收，导致呼叫失败； 3、即使移动台在信号覆盖尚好处起呼，但由于移动台的接入需要一定的时间，所以如果移动台快速向覆盖区外移动（比如移动台在行驶较快的汽车、火车上），就有可能在接入完成前，移动台已经到了覆盖区外，导致呼叫失败。 优化方法： 1、对于覆盖不足引起的呼叫失败最根本的解决方法就是在覆盖盲区或者弱区增加基站（宏基站/微基站/射频拉远），也可以使用直放站，当然新增基站要考虑到和原有网络的拓扑结构配合问题； 2、如果加站暂不可行，可以使用其它一些方法来加强覆盖，比如增
加基站天线高度、选用大增益天线、调整天线方向角、下倾角等，但这些方法不能根本解决问题，并且要在不影响网络整体性能的前提下使用。 二、前反向不平衡引起呼叫失败（前向好于反向） 典型现象： 1、移动台前向接收功率Rx Power 和最强导频强度Ec/Io 维持在一个较好的状态，如Rx Power 大于－100dBm，Ec/Io 大于－15dB； 2、移动台起呼后，反向发射功率Tx Power 一直抬升，直到最大值23dBm，但无法接入成功；呼叫失败后，移动台会在原来的导频上待机； 3、让移动台向基站靠近，使之可以呼叫成功，观察Tx_Adj ，会是一个正值。（注：只有当移动台捕获前向业务信道，即反向闭环功控生效之后，才会有Tx_Adj 值） 现象分析： 1、在上面的情况中，移动台接收功率Rx Powe 和导频强度Ec/Io 较好表示有一个比较好的前向链路，但移动台起呼过程中，移动台一直抬升发射功率直至最大，表示反向链路较差，这就表明前反向链路不平衡。另外，Tx_Adj>0 也表明前向好于反向； 2、由于前向好于反向，所以在反向覆盖边缘，即使前向信号覆盖较好，但反向链路已经很差，这样就可能使基站不能正确接收移动台发来的信令，导致接入失败； 3、通过查看RSSI值进行确认，若RSSI>-103dbm时，说明存在反向
掉话优化思路
1 网优类 1.1 掉话类 掉话排查总体思路流程图
1.1.1 CS掉话类问题处理流程 现网的掉话监测分成RNC级的掉话与小区级的掉话两个方面，若出现网元大 面积掉话，可能由RNC硬件故障引起。但还有一种情况是全网所有的RNC 掉话率都较高，此时可以考虑可能是由于CN的故障或是由其它系统原因造成， 比如系统升级。
造成RNC掉话升级的原因可以有以下几种： 1. 参数配置错误：这有两个方面参数配置存在问题，一是RNC中的全局参 数配置存在问题，另一方面是由CN中对RNC的参数配置存在问题。 2. RNC硬件故障问题：需要通过对RNC告警的检查以及对RNC日志的检 查来确定是否是由硬件故障引起。 小区级掉话率较高，造成小区掉话的原因较多，主要有以下几种： 1. 干扰造成的掉话：（同频干扰、相关性较强的扰码引起的干扰、导频污 染、上下行交叉时隙干扰、上下行导频间干扰、系统间干扰、其它无线 设置的干扰） 2. 切换造成的掉话：（硬件故障导致切换异常、同频同扰码小区越区覆盖 导致切换异常、越区孤岛切换问题、目标小区上行同步失败导致切换失 败、无线参数设置不合理导致切换不及时） 3. 基站硬件故障造成的掉话 4. 终端问题造成的掉话 5. 链路失衡造成的掉话 6. 参数配置错误造成的掉话 覆盖问题造成的掉话（覆盖空洞造成的掉话、越区覆盖造成的掉话、孤岛效应 导致的掉话、导频杂乱导致的掉话、阴影衰落导致的掉话） 1.1.1.1 RNC级问题处理思路 1. 确定问题小区的分布情况（比如是否集中在同一框的某一单板上）。 2. 出现RNC级掉话后，首先需确定该RNC级的掉话是由多个小区引起的， 还是由个别高掉话的小区所导致。如果是由个别小区引起的，应进行小 区级的掉话处理步骤，否则进入网元级的掉话处理过程。 3. 检查RNC的系统告警，检查是否存在相关硬件的告警信息，如果存在单 板的告警，则需要进行排除。 4. 检查RNC的系统日志，对其中不正常部分进行检查。 5. 检查CT数据中掉话部分的信令，分析其错误代码，常见的RNC级参数 设置错误引起的掉话主要有以下几种：
VoLTE呼叫失败案例分析(华为修订版)
VoLTE呼叫失败案例分析0327 一、被叫未收到Paging消息导致呼叫失败（网格46） 问题描述： Xxx·xxx，被叫未收到寻呼消息（期间未进行过TAU，只有小区重选）导致呼叫建立失败。需要进一步跟踪确认MME是否未下发对应寻呼。 主叫15:09:23.182发起通话请求，对应SIP消息Invite，在随后的15:09:27.829→ 15:12:46.611 一共发起三次呼叫尝试，但MS2均未收到寻呼消息，呼叫超时，通话失败。 主叫上一次正常发起呼叫请求
被叫上一次通话正常收到寻呼消息 Paging消息里核心网分配给被叫的TMSI标识（在图中对ＴＭＳＩ加框）
从xxx到xxx主叫连续3次呼叫失败 3次主叫呼叫期间被叫均处于idle态
Paging消息里没有被叫TMSI标识 从ｘｘｘ到ｘｘｘ时间段内被叫所收到的Paging消息里没有携带被叫TMSI标识 在图中标识出哪些字段是ＴＭＳＩ
二、主被叫魏收到QCI1建立命令导致呼叫未建立（网格61博华 路路段） 问题描述： 主叫发出INVITE消息后，被叫收到对应寻呼并完成RRC连接以及QCI9和QCI5的承载，以及INVITE消息，但主被叫均未收到来自网络侧的QCI1 EPC Bearer建立命令，语音承载未建立，导致呼叫失败。需要核心网侧检查失败原因。 （后续3次通话均因为主被叫未建立专有承载QCI=1导致呼叫失败） 主叫发起通话请求后建立QCI=5和QCI=9但未建立QCI=1 圈出QCI9和QCI5的建立event
被叫收到寻呼请求前建立QCI=5和QCI=9但之后未建立QCI=1 圈出QCI9和QCI5的建立event RRC配置消息里被叫的默认承载QCI=9激活
VoLTE高掉话小区处理流程
VOLTE高掉话处理流程 1. 基站告警-主要指小区存在明显的站点告警，主要影响业务告警，包含硬件、停电、断站，射频单元驻波，IPPATH，S1故障等告警； 2. 隐形故障-主要指对问题点进行后台排查后，未发现明显故障，需上站检查相关硬件，计为隐性故障； 3. 传输故障-主要指小区存在传输链路断链，误码率过高,传输数据配置异常等问题； 4. 参数问题-主要指小区存在参数设置不合理、设置错误，参数漏配等； 5. 覆盖问题-主要指小区存在弱覆盖、覆盖过远或覆盖不合理等因素； 6. 内部干扰-主要指小区存在时隙配比不一致（要求同频点站点时隙配比一致）、GPS失锁、模三干扰、超远干扰； 7. 外部干扰-主要指小区存在阻塞干扰、杂散干扰、互调干扰、及其他外部干扰； 8. 邻区问题-新开站点邻区关系不全，不合理或未加任何邻区，影响UE小区选择或重选至不合理小区，从而影响掉线率。 9. 拥塞问题-主要指小区存在明显的资源不足，用户过多导致。 10. 核心网问题-主要指核心网数据定义不全、定义错误或网元合理化调整、功能验证等，导致指标恶化，计为核心网问题； 11. 终端问题-主要指对问题点通过后台排查和现场测试，排除为所有可能无线侧因素，结
合相关信令，确认为个别用户终端问题； 12. 突发异常-主要指某项指标在1-2个时段突然出现恶化，然后自行恢复正常，再排查完各种可能性原因后，未发现任何异常，计为突发异常。 2、E-RAB 掉线率(QCI=1/2)-高掉话TOP 小区分析流程 2、E-RAB掉线率(QCI=1/2)-高掉话TOP小区分析流程 1.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301） 2.如掉线率突增，查询操作日志，确认是否有修改，导致小区异常； 1. 检查小区时隙配比是否设置准确（DE:SA2\SSP7;F:SA2\SSP5）； 2.如每PRB 上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型 1.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差； 2. 通过后台QCI=1/2误码率跟踪，如BLER>1%，确定小区存在高误码； 1.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖； 2.对比64QAM 和QPSK 占比，如后者比例远大于前者,可确定小区覆盖异常； 1.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因； 2.如果确认问题后，转发相关人员处理，做好跟踪工作，直至问题闭环； 1.确定目标小区运行情况，是否基站故障或异常告警； 2. 检查邻区间参数设置是否正确； 3.通过Mapinfo 检查小区邻区配置是否合理，进行邻区合理性优化； 4.检查基站是否周边站点缺少，如为孤站，可视为正常； 1.通过LST ALMAF 查询站点实时告警,参考历史告警； 2.通过DSP BRD 查询单板运行情况； 是否存在弱覆盖 E-RAB 掉线率(QCI=1/2)高 掉话TOP 小区 服务小区是否存在异常告警或传输闪断，周边300米站点是否存在断站及告 警SRB 达到最大重传次数导致的激活的语音业务E-RAB 异常释放次数 切换流程失败导致的激活的语音业务E-RAB 异常释放 eNodeB 发起的原因为无线层问题的UE Context 释放次数 上行弱覆盖导致的激活的语音业务E-RAB 异常释放通过提取两两小区切换，确定目标小区 参数是否设置合理 是否存在高干扰 是否存在高质差 现场测试及后台跟踪 UE Reply 超时导致的激活的语音业务E-RAB 异常释放
掉话类故障处理指导
掉话类故障处理指导 掉话分类定义 在华为Probe侧对于掉话（ERAB Abnormal Release）的定义：UE没有收到Deactivate Eps Bearer Context Request消息，但收到RRC Release或RRC Connection Reconfiguration消息，则表示ERAB异常释放。 标口信令 在eNodeB跟踪到的标准接口信令中，如果存在eNodeB发起的释放，即在S1接口上发往CN的S1AP_UE_CONTEXT_REL_REQ消息内携带的原因值不为“User-inactivity (20)”时，则判断为掉话。 掉话预检查方式 异常掉话通常都是由eNB发起的释放，通知MME释放上下文，因此只要查看S1口发送的S1AP_UE_CONTEXT_REL_REQ消息即可，如下图所示。 S1AP_UE_CONTEXT_REL_REQ 点击“标准接口消息类型”按消息类型进行排序，这样所有的S1AP_UE_CONTEXT_REL_REQ 都会排列在一起，如下图所示。 按消息类型排序 依次点击下一条，查看中的原因值，找出最后的原因为非02 80 的原因值。
找到异常掉话消息 根据对应的时间点，打开标准UU口的跟踪，找到对应时间点的RRC_CONN_REL消息，如下图所示。 找到对应的UU口消息 掉话率指标话统公式 在话统侧异常掉话指标的公式定义如下： Call Drop Rate = L.E-RAB.AbnormRel / (L.E-RAB.AbnormRel + L.E-RAB.NormRel) 等同于： Call Drop Rate = L.E-RAB.AbnormRel.QCI.N / （L.E-RAB.AbnormRel.QCI.N +
掉话处理案例总结完整版
掉话处理案例总结 Document serial number【NL89WT-NY98YT-NC8CB-NNUUT-NUT108】
路测掉话的原因分析及解决 1. 关于掉话的描述 在 GSM 系统中掉话从统计角度讲分为两大类：RF_LOSS 和 HO_LOSS 即射频掉话和切换掉话。考虑到2层信令的接续等问题，我们把掉话作如下描述。 1) 射频掉话 ●下行原因：Radio_link_timeout 计数器减至 0 ●上行原因：BSS 在 link_fail 的设定时间内未能接收到 UL SACCH 消息，使link_fail 计数器减至 0。BSS 下行功率停止发射 ●在 Layer 2 上： BSS/MS 每 T200 时间发送 N200＋1 次 SABM/DISC 消息，但未从接收端收到回应 2) 切换掉话 ●MS 未能成功切换至目标小区, 但未能回到源小区 ●MS 发送 HO FAILURE 和 UL-SABM 消息给源小区，但未得到回应 2. 在路测时发现的掉话问题时,我们应从哪些方面进行考虑 在路测中，如果我们发现了掉话，我们应该如何入手建议根据不同的现象作出一些初步的判断，可以尽量减少不必要的周折，提高工作效率。归纳起来初步判断有以下几点： ●带内、外干扰 ●无可切换的小区（拥塞、无邻区）
●覆盖问题（overshooting/poor coverage） ●有线口的信道释放 ●基站硬件故障（时钟、CTU 低功、信道盘的收发功率不平） ●天线错误（下倾角、方位角等错误） ●由于切换失败造成的掉话 ●参数设置不当 ●其它特殊原因（手机问题、交换机参数设置问题） 3. 对掉话现象进行分析以及可能的原因 在这一节中我们对每种造成掉话的可能原因进行具体的研究。在每一种原因中，我们尽可能的举出实际例子来进行说明。 1) 频率干扰 干扰会导致误码率升高，通信质量下降，是造成掉话的一个重要的原因。干扰可以分为带内干扰和带外干扰，也可以叫做系统内部干扰和系统外部干扰。 带外干扰：随着科技的进步，空中的无线电波越来越多，有些系统如 TCS 系统与 GSM 系统工作在同一频段，如果频率设置不当，会造成严重的频率干扰。在发射设备的非线性单元由于载波与通过天线进入的干扰信号产生互调干扰，会引起通话质量下降，产生掉话。另外一种情况就是人为的加建 GSM 频段的直放站，对功率以及天线方向不进行控制，对系统会造成上下行的干扰。一般有这
LTE网络用户投诉处理流程及处理思路V1
LTE网络用户投诉处理流程及处理思路 随着LTE商用不断发展，日常各项网络问题不断凸显、基站扩容、网络割接、工程调整等都会带来一些网络问题，用户规模增加、城市区域环境变化等因素给无线网络都带来了一定的影响，用户投诉已经成为深入发掘网络问题的手段之一，解决好用户投诉也是提高移动服务品牌的重要途径之一。 （1）投诉处理流程 一直以来，网络投诉是反映客户感知和网络健康情况的重要途径，对投诉的分析总结，可以为网络优化方向提供重要参考。 投诉处理的流程如下： （2）常见投诉类型 一般情况，我们接到投诉后首先根据其现象进行归类。大致可
分为以下几类： ?用户终端问题 ?信号差 ?信号不稳定 ?网络问题 ?其他问题 用户投诉可能单独关注某一问题，而现场投诉中往往涉及多个方面，因此需要各项方面综合考虑。一般来说，要明确用户反映问题的现象、地点、涉及用户数量、时间等要素，这样更有助于我们判断问题的根源。 按照用户投诉现象的不同，我们可以将投诉分为以下几大类： 2.1终端设备问题 LTE终端设备主要有CPE、数据卡、MiFi，LTE手机等，目前主要推广以CPE、MiFi等为终端的上网业务套餐。 以华为CPE为例，设备型号：B593s-58b，只支持F、E频段，B593s-82，只支持D、E频段，B593s-58a，只支持F、D频段。 ?问题原因
1）终端设备硬件损坏，如电源模块烧坏； 2）SIM卡问题，如卡坏、SIM卡流量超支、SIM 卡鉴权加密机制等； 3）终端设备不支持网络频段，如现网室外宏站F频段建设网络，室分系统E频段，D频段补盲，只有相支持应频段的终端设备才能接入网络； ?问题对策 1）终端设备硬件坏，建议更换、送相关网点维修； 2）SIM问题，建议换卡、开通流量更大的套餐； 3）修改终端设备支持的网络频段，如还不行，建议更换支持网络的终端设备； 2.2覆盖类问题 覆盖类问题主要包括无覆盖、覆盖区过大和覆盖区过小。 ?问题原因 1）LTE网络未规划； 2）硬件（参数）故障，如CRS功率发射功率低等； 3）天馈驻波比过大； 4）天线方位角、下倾角不合理； 5）建筑物或地形阻挡； 6）天线高度与基站距离问题；