VOLTE网络中异常事件的分析.docxVIP

VOLTE网络中异常事件分析 一、概述 从volte开始lte流程变得更加复杂；首先，原来的双层网络结构被新 加入的IMS域搞得异常复杂；其次，21个网元和38个接口使多数人都是过目 即忘；此外,多业务混合并发、QoS得到应用、专用承载不定时地做建立、修改 和释放操作。 在VOLTE网络中由于专用承载的频繁管理操作、SIP消息传递丢失、重发和 高延迟，以及相互之间千丝万缕的联系，相互之间缺乏相关控制机制（如同步、 交互）导致了一系列极为错综复杂网络异常现象，这些给日常分析带来许多困难。 volte网络的通信机制是来自4个标准化组织组合的产物，它们分别是： ①.3GPP 的 23 系列规范；C2 SIP/RTP/DIAMETER/IPSec 取自 IETF 的 RFC ; ③.VoLTE Profile 和 RCS 取自 GSMA 的 IR ;O. Video code 取自 ITU-T 的 H.264。 目前网络中的异常事件主要与这些标准之间的兼容性相关； 本文以切换与承 载管理冲突形成的异常事件为样本，分析 volte网络中的异常事件。 二、切换与专用承载管理流程冲突导致的异常事件 1、切换与专用承载 建立流程冲突导致（SIP消息503） 通常用户拨打电话具有随机性，网络无法准确预估专用承载建立的时间点。 当专用承载建立请求在源小区（eNB-A ）发出RRC Conn ection Reco nfigure 和 MME收到S1 pathswitch request之间到达时，源小区会认为 UE已切出，源基 站除了缓存用户的用户面数据外，不应再处理该 UE的（切换）消息，以原因值 “未知的eNB UE S1APID ”的方式拒绝专用承载建立请求，最终 SBC会下发 503错误。 UEeNB-B UE Handover Requesl RKC conn reconf com pl!Si ERAS Setup SeNB源基站不再处 -理此终 RKC conn reconf com pl! Si ERAS Setup SeNB源基站不再处 - 理此终端的有关信岂I | SI ERAB Setup Refect 陽了鍰帝卞彳刊臼⑹ SI Path Switch Request SI Path Switch Request ACK SI ERAB Sf ‘ —斤日驛陶』一 图1专用承载建立与空口切换流程冲突 如上图所示：该问题的解决办法是要使 MMEE再次向切换的目标小区 （eNB-B发专用承载建立请求，即在目标小区上发 Path Switch Rquest ACK 之后再发 ERAB Setup Request。 目前一般是通过升级SGV来解决该问题；但是升级之后可能会出现新问题下 面讨论的问题。 2、切换与专用承载释放流程冲突导致的异常事件 切换与专用承载释放流程冲突在专用承载建立、修改和释放阶段都可能概率 性发生，在建立和修改阶段一般会伴随出现 503错误，导致未接通； 在释放阶段，如果出现该问题则有可能会出现一种死循环， QCI1专用承载一 直无法释放，除非人工干预(关机重启或飞行模式切换)，否则可能永远无法做 主被叫。 5BC-AEYEBYEBYEJL5s481BYEBYE4S：IDO Trying._1CDJ■咖 pRTPTJnwoijrt乍57亠石RWC 坯塔摆 5BC-A EYE BYE BYE JL5s 481 BYE BYE 4S： IDO Trying. _1CDJ■咖 p RTPTJnwoijrt 乍57亠石RWC 坯塔摆SEPT as+i*i*i*7=3i-5j RRClt it -Il Rvp向于卓活三 431 Ut-fi 用RC 加e M3SEy# 冏 1■己 图2专用承载无法释放，无法做主被叫，频繁出现 481，487和488错误 被挂(叫)侧(UE-B )出现RRC重建，没有及时接收到SIP消息，但S-CSCF 先触发500(Server Internal Error)，并清理了主挂侧的QCI专用承载和会话；但 S-CSCF未同步清理被挂侧，直到SIP重传超时后，通过408(Request Timeout) 清理IMS域会话；被挂终端每隔4秒重复BYE消息，而SBC认为会话已结束， 回复481(Call/Transaction Does Not Exist)，未触发 MME启动专用承载释放流 程，同时终端没有其他途径通知 MME启动专用承载释放流程，因此 QCI1专用 承载一直吊死，后续通话无法进行。 在测试中切换是导致QCI1专用承载无法释放的原因之一，还有很多其他 的可能，为避免上述这种极端的情况出现，目前给出的建议是： SBC无论在收 到或发出BYE消息之后，不要等待BYE200消息的确认，无