基于核心网优化平台分析小区掉话..docxVIP

基于核心网优化平台分析小区掉话在总部发布 “业务感知分析与优化月报”中，“3G掉话大于30%用户比”和“2G掉话大于30%用户比”排名靠后，该指标是从用户角度来考量掉话率高的用户占比，但就实际优化而言，我们关注的仍然是掉话发生在哪些小区，即高掉话小区分析与优化。从全省来看，2G掉话率高的地市依次为深圳、广州、东莞、茂名，3G掉话率高的地市依次为清远、深圳、茂名、惠州，因此需要这些地市重点分析优化。核心网优化分析中的“掉话问题分析”模块中，已经可以将掉话统计到呼叫结束小区，同时在筛选条件中可以选择呼叫结束小区，分公司可以直接在核心网平台进行查询分析,具体步骤如下：设定时间粒度，时间范围，网元（地市）：时间粒度选择天，设定需要的开始时间和结束时间，建议时间不要超过2天，时间太长查询较慢，然后在网元中选择城市，如下图：设定接入网类型、指标以及指标条件：设定接入网类型，选择2G或3G，在指标选择窗口中选中掉话次数，掉话次数大于等于一定门限，如下：设定维度：维度可选择呼叫结束的CGI/SAI，对于掉话，目前已经按呼叫结束的小区来统计（但对于其他维度，如地市、MSC等，都是指呼叫开始小区所在的地市或者MSC等来统计的，因此准确度上稍有偏差），设定如下：查询结果： 设定好条件之后，点击查询按钮，就开始按照设定条件查询数据，结果如下：对于查询的结果中统计的次数，均可以钻取详单，如下，对460014231529131小区的352次掉话详单进行钻取，如下：钻取详单结果如下：可以看到这些掉话中，很多都是拨打10010的呼叫，这是手机卖场或者手机厂商测试造成，可以说是用户原因导致的掉话，具体分析时可以通过钻取详单进行分析。此外，对于交换侧掉话特别说明：在掉话分析中有很多情况是核心网发起的掉话（平台掉话标志为“交换侧掉话”），这类掉话的释放原因都是“正常释放”，经分析是用户在通话过程中发起另一个呼叫的业务请求（不同于呼叫保持），核心网对原呼叫发起了呼叫清除这是合理的，实际上用户应该已经掉话不能正常进行通话了，只是无线的定时器比较长，没有发呼叫清除请求而已，由于用户已经掉话，用户就再次发起业务请求呼叫。还有一种情况是因为用户还在通话中用户就发起在另一个位置区的位置更新，核心网认为用户已经脱网就发起呼叫清除，实际上用户也应该已经脱网，否则用户不会发起位置更新而是发起切换，明显用户已经从一个位置区进入另一个位置区，典型的信令流程如下：交换侧掉话经过对核心网平台中的“交换侧掉话”进行核查，无一另外都是这两种情况，上面的情况，虽然是核心网发起的掉话，但实际原因还是无线原因导致的掉话，因此建议掉话分析时掉话类型和释放原因仅供简单参考，重点还是无线侧分析为什么掉话？附：核心网优化平台的掉话率计算方法：掉话率＝（无线掉话次数+交换掉话次数+切换掉话次数）/应答次数2G交换原因掉话次数：MS未处于切换状态，在A接口上采集到向BSC发送的Clear Command消息（原因值不为Handover successful），且未采集到“Clear Request”和“Disconnect”消息。(3GPP24.008)3G交换原因掉话次数：用户未处于切换状态，在IuCS口上采集到向RNC发送的Iu Release Command消息（原因值不为Successful Relocation），且用户处在切换状态，且未采集到“Clear Request”和“Disconnect”消息。2G无线掉话次数：通话过程中，MS未处于切换状态，统计BSC在A接口上向MSCServer发送“Clear Request”消息次数，且未采集到Disconnect消息。(3GPP24.008)3G无线掉话次数：通话过程中，MS未处于切换状态，统计MSCServer在IuCS接口上收到RNC发送“Iu Release Request”消息的次数，其中Cause指示了异常原因值（正常释放原因为”Normal Release”，”Successful Relocation”，”Resource Optimisation Relocation”，”User Inactivity”或者”release-due-to-UE-generated- CCgnalling-connection-release”）。2G切换掉话次数：MS处于切换状态，统计BSC在A接口上向MSCServer发送“Clear Request”消息次数或者统计MSCServer在A接口上向BSC发送“Clear Command”消息中“cause”的取值不为 Handover successful的次数，且未采集到“Clear Request”和“Disconnect”消息。(3GPP24.008)3G切换掉话次数：MS处于切换状态，统