掉话原因分析和解决方法：
1．突然掉话的分析和解决：
突然掉话主要是因为BSC在一段时间内收不到手机的上行测量报告，因此不能判断手机是究竟处于何种状态，当RLINKT到零时，强制释放。这其中的原因有下行干扰、用户突然进入信号盲区、切换过程中的丢失、直放站、用户行为(手机没电等)、载频问题等。
因此要分析解决突然掉话，
主要从这几方面着手。首先，要收取连续多天忙时统计或一天的统计进行分析，对上行干扰(OBJTYPE=IDLEUTCHF)、传输问题(OBJTYPE=LAPD)、各类释放次数(OBJTYPE=CELEVENTD,COUNTER=DISNORM,DISBQA,DISBSS,
DISTA)，切换情况(OBJTYPE=NICELHO,NCELLREL)等进行分析，看该小区是否存在干扰，传输是否有问题，与邻小区切换是否异常等。如果发现CDU-D的小区的掉话突然上升幅度较大而且几乎都是突然掉话，就需检查FU是否存在问题了。对突然掉话的解决主要靠修改频点，完善切换(如修改KHYST,KOFFSETP,QLIMUL,QLIMDL)，检查载频是否有问题(可以通过闭载频来测试一段时间)。
对于切换丢失，可以通过NCELLREL中HOVERCNT-HOVERSUC-HORTTOCH的值来确定两邻区间的切换参数是否仍需改进，如果HORTTOCH较大，而且切换丢失较多，但源小区的弱信号掉话不多，而且两者间切换多是K算法切换，则可以相应增大KOFFSETP，如果这两个小区都是切换丢失较多，则可以增大KHYST，但KHYST不宜大于6。
然后是检查该小区的切换关系是否完善，该加的就加，不该切的就应该删除，即使两者之间是存在切换，因为过多的切换就会带来更多的掉话，但在改动后需跟踪话务统计，看这些小区的掉话是否增加。
对于直放站和载频问题的检查，则可以通过关闭直放站和载频来进行测试，看是否由于硬件还是直放站问题引起。
可以考虑把2个载频以上并且可以关掉跳频的小区的IHO参数设置为SSOFFSETULN=10,QOOFSETULN=10,QOFFSETDLN=5,在一定程度上可以减少突然掉话，但要注意跟踪统计；
SSLENSI 是用于指定SSEVALSI滤波器的长度，另外，SSLENSSD是用于SSEVALS D滤波器。太短则有可能会出现误测，太长则有可能会出现反应迟慢。如对于高速移动区域（高速公路）则长度应短点(如6)，以跟得上快速变化的测量值。而对于非高速移动区，但情况复杂的劣质小区，则长度应大点(如10），以去除个别非规则的差质测量值造成的影响。
因此一般将SSLENSD和QLENSD设为8，如果一个小区的突然掉话较多，而基本上已确定参数和硬件都没有明显问题，则可以考虑把SSLENSD和QLENSD修改为10，或许也可以减少突然掉话，可以跟踪24小时的统计来看是否有较大的降低；
2、对于上行弱信号掉话和上下行弱信号掉话，其原因主要有越区覆盖、天线分集接收性能不好或者没有增益、邻区关系不完善、参数设置不当等
对于越区覆盖，最好是下压天线，现在一般的非高增益天线的垂直方向的波瓣角为15度，高增益天线则为7度，因此如果天线只是平打的话，就会有一半的主波瓣信号是射向天空的，太浪费了，因此建议较高的站的下倾角都可以打至4度以下。
对于天线问题，一般是在全向孤立站上会发现其话务很少，掉话也不多，但全是上行弱信号掉话，一般来说，全向孤立站的话务都比较集中在镇上或乡上，若基站硬件正常，一般不会出现上行弱信号掉话，因此请注意上行弱信号掉话较多的全向站和CDU-A的基站，尽可能下去检查。
邻区关系的分析与处理：在检查上行弱信号掉话较多小区的邻区关系时，也同样要取多天的统计或全天统计来分析，看每一对切换关系是否有必要，因为不恰当的切换关系只会带来更多的弱信号掉话和突然掉话，而且会改变其他小区的话务。
对于参数的设置，主要包括有LOCATING参数，切换参数，功控参数；
LOCATING参数主要有BSRXMIN,BSRXSUFF,MSRXMIN,SSLENSD,QLENSD;
其中BSRXMIN是上行K算法最小接入电平,BSRXSUFF是上行K算法开关，MSRXMIN是下行K算法最小接入电平，当把BSRXSUFF设为0，就开启了上行K算法最小接入电平，这样就在LOCATING对列筛选时考虑上行信号的强弱，从而确定是否允许手机切换至本小区，这对于解决越区覆盖较为严重的小区的掉话有一定的作用，因为虽然下行信号满足切换条件，但由于是越区小区接收的上行信号是从较远处传送而来的，强度肯定是很弱的，这样如果接入了该小区就很容易造成上行弱信号掉话，因此就限制了接入越区小区，使用户接入较近的小区，维持上下行电平的平衡。
对于MSRXMIN，一般设置为小于或等于ACCMIN。但如果设置过小，则有可能引起更多的上下行弱信号掉话，因为上行信号在经过一定的距离后已经较弱，如果再限制了切换队列中可供选择的小区，则使得下行信号也越来越弱，从而导致上下行弱信号掉话。
因此，在更改后需跟踪话务统计。
对于功控参数的设置，一般把SSLEN和QLEN设置为统一值，以使得功率控制较为平稳，4是一个比较好的值。
对付两个载频以上的最坏小区时，可以采用子小区结构来实现。子小区的设置如下：RLSTC:CELL=MY5810A,STATE=HALTED;
RLDGI:CELL=MY5810A,CHGR=1;
RXTCI:CELL=MY5810A,MO=RXOTG-65,CHGR=1;
RLCFE:CELL=MY5810A,DCHNO=9;
RLCFI:CELL=MY5810A,DCHNO=9,CHGR=1;
RLSTC:CELL=MY5810A,STATE=ACTIVE;
RLDSI:CELL=MY5810A;
RLCPC:CELL=MY5810A,SCTYPE=OL,BSPWRT=45,MSTXPWR=33;
RLLOC:CELL=MY5810A,SCTYPE=OL,BSTXPWR=49;
RLIHC:CELL=MY5810A,SCTYPE=OL,IHO=ON;
RLPCC:CELL=MY5810A,SCTYPE=OL,SSDES=92,INIDES=72,LCOMPUL=70,REGINT=4,SSLEN=4,QCOM PUL=30,QDESUL=30;
RLBCC:CELL=MY5810A,SSDESDL=80,REGINTDL=4,SSLENDL=4,QLENDL=4,LCOMPDL=50,QCOMPDL=6 0,QDESDL=30,SCTYPE=OL;
RLLUC:CELL=MY5810A,SCTYPE=OL,QLIMUL=45,QLIMDL=45;
RLOLC:CELL=MY5810A,LOL=150,LOLHYST=20,TAOL=30,TAOLHYST=5;
RLDGC:CELL=MY5810A,SCTYPE=OL,CHGR=1;
其中最主要的就是通过修改参数LOL和TAOL来控制在UNDERLAID和OVERLAID小区中的话务，OVERLAID小区占的话务越多，相对来说掉话数就会降低，因为发生在OVERLAID小区里的掉话和拥塞是不计算的。
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.覆盖差
TOP小区处理流程总结 1TOP小区处理流程及整体处理情况 1.1 TOP小区分解 TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。 1. 2 问题处理流程 TOP小区问题处理流程中，原因分析是流程中的关键点和重点。
2无线接通率TOP小区分析处理 无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB建立成功率两块进行分析。RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。每次RRC和RAB建立失败，话统都会输出一个失败原因统计。 2.1RRC建立失败处理
2.1.1RRC建立失败原因 RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。表3是RRC建立失败的对应原因打点。表4为RRC失败对应的原因分析。 表3：RRC失败原因打点 表4：RRC失败对应的原因分析
2.1.2RRC建立失败处理 1)拥塞 在RRC建立出现拥塞时，可以进行下面的操作： ?将主要业务的RRC建立在公共信道上，修改命令行为： ?主叫流媒类体RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGSTREAMCALLEST, SIGCHTYPE=FACH； ?主叫交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGINTERCALLEST, SIGCHTYPE=FACH； ?主叫背景类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=ORIGBKGCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMSTREAMCALLEST, SIGCHTYPE=FACH； ?终止交互类RRC建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=TERMINTERCALLEST, SIGCHTYPE=FACH； ?终止流媒体类RRC建立在FACH上 RCESTCAUSE: RRCCAUSE=TERMBKGCALLEST, SIGCHTYPE=FACH； ?去附着信令承载建立在FACH上 SET RRCESTCAUSE: RRCCAUSE=DETACHEST, SIGCHTYPE=FACH； ?注册登记承载在FACH上 SET RRCESTCAUSE: RRCCAUSE=REGISTEST, SIGCHTYPE=FACH； ?提高拥塞小区的最小接入电平，限制部分低电平用户的接入： 修改命令：MOD CELLSELRESEL: QRXLEVMIN=-96； ?打开LDC开关； ?对于业务量持续较大的小区，可以考虑建议扩容。 2)RL建立失败
京广铁路指标提升方案4 京广铁路指标提升方案 1.京广铁路概况(2) 1.1指标介绍(2) 2.京广指标提升优化方案(4) 2.1历史数据分析(4) 2.2覆盖优化方案(7) 2.2.1覆盖方案遵循原则(7) 2.2.2覆盖方案制定(8) 2.2.3覆盖方案小结(18) 2.3 GRRU工作情况汇报(19) 2.3.1 维护情况介绍(20) 2.3.2 设备运行情况介绍(20) 2.3.3 GRRU工作小结及后期工作建议(21) 2.4 优化方面工作(22) 2.4.1网络结构调整(22) 2.4.2覆盖优化调整(26)
2.4.3 参数优化调整(27) 2.4.4 优化工作小结(29) 3.计划解决时间(29) 1.京广铁路概况 京广铁路属于长沙的一条重要的交通枢纽。目前京广铁路长沙境内路段由154个小区，90个基站覆盖，微专网有8个。北段微专网有：糖酒公司,社会科学院。南段微专网有：东方科器，雪峰水泥，长途线路局，丽江翠园，乒乓厂，暮云牛角塘，丰成，暮云4区。 由以上可以看出微专网的覆盖在京广铁路长沙段有举足轻重的地位，与大站一起构成了京广铁路长沙段的主要覆盖。 长沙移动微专网采取用京信公司的GRRU设备进行专网覆盖，建设初期所有远端都建设在铁路红线范围以内；光缆和电源线经常被铁路施工而挖断，偷盗也时有发生,造成后期维护非常困难,譬如学峰水泥,东方科器微都完全瘫痪.乒乓厂微5个远端,只有#1,#2远端工作. 同时京信公司GRRU设备不能有效的进行故障监控和数据统计，导致故障和问题的处理进度缓慢，导致京广铁路指标不理想，用户感知度差。 因此，京广线需要提出合理有效可行的优化整改方案，提升京广铁路指标. 1.1指标介绍
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
上海贝尔阿尔卡特股份有限公司
ASB SSM-ISE 工程服务部
位置更新引起未接通的分析
ASB 工程服务部 外协工程师 赵枫
一,接通率的定义
根据 CMCC 的 2005 年测试规范中规定:在城市忙时采用手机相互拨打的方式,每次通 话时长 100 秒,呼叫间隔 20 秒;如出现未接通,应间隔 20 秒进行下一次试呼. 接通率,定义:接通率=接通总次数/试呼总次数×100%; 说明: 试呼次数:以 channel request 和 CM service request 同时出现来确定试呼开始. 接通次数:当一次试呼开始后出现了 Connect,Connect Acknowledge 消息中的任何一条 就计数为一次接通. 接通率=总(Connect 或 Connect Acknowledge)数/总(channel request 和 CM service request)数×100% 接通率取主叫测试手机的统计结果.
二,未接通现象:
"一次接通"从主叫手机 Channel request 开始, 一直到被叫手机的 TCH 分配完成, Alerting,Connect.在此过程中,任何的信令中断都是"未接通" . 从信令流程上分析,可分为以下几种情形: 1.起呼后没有 IMMEDIATE ASSIGNMENT 消息 定位:RACH 冲突或者 AGCH 拥塞 建议:查看与 RACH 相关的参数――最大重发次数和发送分布时隙数以及与 AGCH 相 关的参数――接入准许保留块数 2.IMMEDIATE ASSIGNMENT REJECT 导致未接通 定位:SDCCH 拥塞 建议:检查 SDCCH 配置,查看相关小区 SDCCH 话务量 3.IMMEDIATE ASSIGNMENT FAILURE 导致未接通 定位:SDCCH 指配失败 建议:排除无线方面原因后,应从交换侧寻找问题原因
ASB2005GSM001
移动通信经验交流汇编
1/5
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未接通概况 (2) 2未接通分析 (2) 2.1位置更新导致的未接通 (2) 2.1.1主叫位置更新导致的未接通 (2) 2.1.2被叫位置更新导致的未接通 (4) 2.2SDCCH拥塞导致的未接通 (5) 2.3SDCCH掉话导致的未接通 (7) 2.4TCH分配失败导致的未接通 (8) 2.4.1无线原因导致的TCH分配失败 (8) 2.4.2BSC原因导致的TCH分配失败 (10) 2.5TCH拥塞导致的未接通 (11) 2.6其他异常原因导致的未接通 (12) 2.6.1由于上行干扰导致的未接通 (12) 2.6.2Cause: No user responding (15) 2.6.3Cause: User Busy (16) 2.6.4呼叫重建导致的未接通 (18) 2.6.5交换机异常导致的未接通 (19) 2.6.6BSC与MSC间CR,CC丢失造成未接通 (21)
1未接通概况 ●未接通概述： 根据CMCC规范以主叫Channel request来确定试呼开始，接着出现了Connect，Connect Acknowledge消息中的任何一条就计数为一次接通，否则就计为一次未接通。 CMCC测试标准中规定：在城市忙时进行自动拨打测试，每次通话时长120秒，呼叫间隔20秒；出现未接通情况，应间隔20秒进行下一次试呼。 接通率定义：接通率＝接通总次数/试呼总次数×100％； 说明： ●接通次数：当一次试呼开始后出现了Connect，Connect Acknowledge消息中的任 何一条就计数为一次接通。 ●接通率＝总Connect（Connect Acknowledge）数/总Channel Request数×100％●接通率取主叫双频测试手机的统计结果。 2未接通分析 2.1位置更新导致的未接通 2.1.1主叫位置更新导致的未接通 在GSM DT正常测试中，主叫手机在idle状态下有时会发生小区重选现象，小区重选后主叫手机会有两种情况下的位置更新。一种为在idle时间内主叫手机位置更新顺利完成，另一种为手机小区重选后还未来得及进行位置更新或位置更新未完成，主叫手机就发起起呼命令（channel request），此种情况会导致未接通，网络下发CM Service Reject（Cause＝4，IMSI unknown in VLR）。 ●案例描述： 如图中红圈处所示，主叫测试手机行驶过程中占用林庄1小区，手机接收电平为－53dbm左右，发起呼叫，但未接通。
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.doczj.com/doc/986537540.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，
高掉话小区处理流程建议 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类掉话。
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高掉话处理流程 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 异常释放
路侧过程中未接通现象总结 未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。原因也是多种多样。 导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。 路测过程中L3信令流程： 从测试中主叫与被叫的信令流程分析，要完成一个完整的接续过程，一共有以下 几步的信令流程： 主叫的信令流程： MS BTS说明 RACH Channel request AGCH Immediate assignment SDCCH CM service request SDCCH CM service accept SDCCH Authentic request SDCCH Authentic response SDCCH Ciphering command SDCCH Ciphering complete
SDCCH Setup SDCCH Call proceeding SDCCH Assignment command FACCH Assignment complete FACCH Call Progceeding FACCH Alerting FACCH Connect FACCH Connect acknowledge TCH Speech
亳州GSM坏小区处理流程 1. 指标问题区分优先级别排查 1.1 指标监控一般分类 由于正常指标监控时间有限，需要利用有限的时间解决对网络质量影响程度更严重的、范围更广泛的指标问题，因此要将指标问题区分优先级别排查。 1）观察Net Indicator指标： 按指标重要性排序，分别为TCH、SD话务量增长情况、话务掉话比、TCH掉话率、TCH信道可用总数、TCH拥塞率（不含切换）、TCH分配失败率、SD拥塞率、切换成功率、TCH拥塞率（含切换）等指标，与近期相同时段相比，把握网络级指标变化情况。监控的宗旨是： 网络级容量指标稳中有升； 网络级质量相对稳定指标稳定； 2）观察BSC Indicator指标： 观察指标及观察方法具体如Net Indicator。监控的宗旨是，在Net Indicator指标变化的前提下，将指标变化范围定位到BSC级别。 网络容量指标如果发现为大多数BSC都增加的情况，那么多数都为节假日等公众行为所致，这类情况一般都能事前预测；如为部分BSC增加的情况，需要再进行Cell级别定位。 网络质量指标如果发现为大多数BSC都有恶化情况，多数情况为凌晨有网络级工程所致，例如核心网升版、核心网割接等工程，需要立即联系该工程所涉及硬件工程师；如为部分BSC恶化的情况，可以通过工程数据核查是否问题BSC属于某个或者某些特定的MSC，并了解交换侧工程情况，给予定位；如为个别BSC恶化的情况，需要再进行Cell级别定位。 3）观察Cell Indicator指标： 观察指标及观察方法具体如Net Indicator，监控的宗旨是，在BSC Indicator指标变化的前提下，将指标变化范围定位到Cell级别。但还需重点观察各小区TCH话务量、MC01/MC02比值及切换请求总次数等，这些指标可以发现是否有基站退服、吊死等故障情况。 网络容量指标通过涉及小区的数量及具体地理分布可以将变化情况定位到具体区域，多数原因可能是由于组织区域性活动等所致，这类问题需要局方尽量提前了解活动信息，优化工程师就活动信息提前调整网络配置或采用应急措施（例如：降低半速率占用门限、开启DR功能等）。 网络质量指标通过问题BSC下涉及小区数量可以将问题定位至BSC级问题还是
网络未接通问题点分析流程指导书 一、路测未接通问题点产生机制 未接通主要是在手机向系统发送呼叫请求，但是在呼叫过程中由于某种原因，主叫或被叫手机没有分配到TCH信道，导致未接通。路测(DRIVE TEST) 当中考察的一项重要指标, 接通率一直是优化中要应对的一个重要工作.在日常的测试当中, 我们经常遇到各种各样的未接通情况。原因也是多种多样。 导致未接通的常见的原因主要有：被叫手机位置更新、主叫手机TCH拥塞、被叫手机TCH拥塞、主叫手机SDCCH拥塞、被叫手机SDCCH拥塞、SDCCH 掉话、呼叫号码错误、CIC分配错误、寻呼失败。 从测试中主叫与被叫的信令流程分析，要完成一个完整的接续过程，一共有以下 几步的信令流程： 主叫的信令流程： MS BTS 说明 RACH Channel request AGCH Immediate assignment SDCCH CM service request SDCCH CM service accept SDCCH Authentication Request SDCCH Authentication response（鉴 权响应） SDCCH Ciphering command SDCCH Ciphering complete SDCCH Setup SDCCH Call proceeding（进程、程序） SDCCH Assignment command FACCH Assignment complete FACCH Progress FACCH Alerting FACCH Connect FACCH Connect acknowledge TCH Speech 被叫的信令流程： MS BTS 说明 PCH Paging Request RACH Channel request AGCH Immediate assignment SDCCH Paging response（响应） SDCCH Authentic request SDCCH Authentic response SDCCH Ciphering command SDCCH Ciphering complete SDCCH Setup
TOP小区处理流程 1TOP小区处理流程及整体处理情况 1.1 TOP小区分解 TD-SCDMA网络系统重要的话统KPI包括CS/PS无线接通率、CS/PS无线掉线率、接力切换成功率、RNC间硬切换成功率、3G/2G互操作成功率等，针对这些KPI指标，可以通过分析、处理和解决影响这些指标的问题小区，提升和改善KPI指标。 随着项目优化的深入开展，实行优化大区制，话统TOP小区也相应的落入大区进行分析和处理。TOP小区按问题类型进行分类处理，目前按23G互操作问题、产品性能问题、掉话类、接通率类、切换类等5大类进行分类，其中23G互操作问题由2G/3G团队处理，产品性能问题由产品性能研发处理，其余掉话类、接通类、切换类等落入大区进行处理。 1. 2 问题处理流程 TOP小区问题处理流程中，原因分析是流程中的关键点和重点，下面的章节中按问题类型进行分析和说明。
流程说明： 1)TOP小区输出，现阶段由机房在每天的KPI监控日报中一起输出，TOP小区处理团 队进行跟踪和处理； 2)每天跟踪TOP小区的KPI变化，刷新TOP小区问题跟踪表，更新处理情况和处理 内容； 3)完成调整的持续观察3－4天，如果话统恢复正常，关闭问题；仍未恢复的，转回 原因分析阶段，继续分析和处理；
4)每个问题建立案例，按照问题描述、原因分析和处理、指标变化、案例总结； 5)每天输出问题处理计划，外场测试必须输出测试报告； 6)每周输出TOP小区处理周报。 2无线接通率TOP小区分析处理 无线接通率＝RRC建立成功率*RAB建立成功率，接通率需要从RRC建立成功率和RAB 建立成功率两块进行分析。RRC建立成功率与业务类型没有关系，RAB建立成功率则与业务类相关，需要分PS业务/CS业务进行分析。每次RRC和RAB建立失败，话统都会输出一个失败原因统计。 2.1RRC建立失败处理 2.1.1RRC建立失败原因 RRC建立失败的原因可以通过RRC原因统计的细化Counter进行确定。表3是RRC建立失败的对应原因打点。表4为RRC失败对应的原因分析。 表3：RRC失败原因打点 表4：RRC失败对应的原因分析
掉话类故障处理指导 掉话分类定义 在华为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 +
TCH掉话处理流程 TCH掉话是影响用户感知度的重要指标之一。我们按其原因将其归为以下几类，对每种类型的掉话做了简要说明并给出了优化建议： 1系统原因掉话（MC14C） 因为系统的一些操作或者故障引起的掉话，如修改频率、RESET 载频和BTS、载频和基站闪断的等，判断的根据就是观察小区的告警和操作记录。 这类掉话处理建议： ●操作时，建议使用Shut Down来Lock小区； ●对于闪断故障需及时LOCK，并进行更换、处理； ●频率修改尽量选在非忙时进行。 传输闪断引起系统掉话的案例： 察看XAD140_1的话务报告，在某一时段出现大量的系统掉话，同时不可用信道数为3，我们怀疑载频闪断引起大量的系统原因掉话。 在OMC-R察看该小区的告警，在出现系统掉话的时段，一直反复出现LOSS OF TCH和LOSS OF SDCCH的告警，并且二路传输存在告警。所以我们判断，二路传输闪断，引起在RSL闪断，进而引起信道丢失的告警，产生系统原因掉话。 这种系统掉话就是由于传输闪断引起的，应尽快处理传输问题。 2传输掉话（MC739） 导致传输掉话的原因有以下几种情况：
●A口故障，可结合018报告，来判断具体为哪一路出现故障，及时LOCK 有问题的时隙或者PCM链路，并处理故障； ●ABIS故障，可以通过ABIS告警来发现，需及时处理故障，控制传输掉 话； ●TC故障，可以通过TC告警来发现，需及时处理故障； ●载频故障，可以先 reset相关载频，无效后更换载频。 传输误码引起的传输掉话案例： 从话务报告来看，XAM794_0存在多载频的传输掉话，我们怀疑ABIS口或者A口出现问题。 查看ABIS告警：我们发现在传输掉话所处时段，ABIS口存在BER-10E-3的告警，所以断定此告警导致小区的传输掉话。 当对传输链路进行故障处理之后，告警清除，传输掉话消失。 3无线掉话（MC736） 当RADIO LINK TIMEOUT（无线链路超时计时器）减为0 时，信道被释放从而引起的掉话记为无线掉话，在网络运行中此类型掉话最为常见，其产生原因有以下几种：