前方高能、多图，没有耐心者请直接卷到最后看结论。
一、概述
从VoLTE开始LTE变得异常复杂了起来，直观的表现就是原来号称的极简两层网络结构（EPC-EUTRAN）被新加入的IMS域搅得神魂颠倒，所谓的21个网元和38个接口，相信很多人都是过目即忘。除了这些看得见的复杂之外，更大的复杂在于：（1）从VoLTE开始真正多业务混合并发；（2）QoS真正开始在网络中得到应用，且不得不用；（3）专用承载开始出现，并且需要不断不定时地做建立、修改和释放操作。这些新特点，给VoLTE的优化带来了前所未有的挑战。本文探讨的内容主要涉及到（3）复杂点，正是由于专用承载的频繁管理操作和SIP消息传递的不靠谱（丢失、重发和高延迟）以及二者之间还需要千丝万缕的联系，同时又缺乏相关的控制机制（如同步、交互）导致了一系列极为错综复杂的网络异常现象，这也必然意味着未来难以在网络中提供稳定性极高的VoLTE业务体验。从某种角度上来说，VoLTE网络通信机制本身是存在一定缺陷的，VoLTE事实上是由4个标准化组织的成果七拼八凑出来的半成品——除了3GPP的23（22和26中也有部分业务和编码方面的规范）系列规范外，SIP/RTP/DIAMETER/IPSec取自IETF的RFC，VoLTE Profile和RCS取自GSMA的IR，Video code取自ITU-T的H.264。
从2年多的测试情况来看，从终端（除iphone外）、EUTRAN、EPC、IMS没有一个网元不是问题百出，至今都不能说是完全可靠。也正是VoLTE的复杂性，某动最早宣称2014年年底就要商用，事实上到2015年才小心翼翼在内部试商用，即便是2016年也只敢说要发展3500万用户，仅为3亿LTE用户的10%左右，这也足以说明对其信心的不足。对于某信和某通，一上来就是要商用商用的叫嚣，我们只能报以呵呵两声。
本文通过对前期各种测试情况的汇总，试图总结出几种典型的信令交互异常，一方面希望网络设备当自强，能够提供更多更强壮性的设计，另一方面也希望对后续的VoLTE优化提供一点借鉴作用。
二、切换与专载管理流程冲突导致的异常
1、切换与专载建立流程冲突导致503
由于用户拨打电话具有随机性，网络无法准确预估专载建立的时间点，当专载建立请求在源小区（eNB-A）发出RRC Connection Reconfigure和MME收到S1 pathswitch request之间到达时，源小区会认为UE已切出，源基站除了缓存用户的用户面数据外，不应再处理该UE的消息，会以原因值为“未知的eNB UE S1APID”的方式拒绝专载建立请求，最终SBC会下发503错误，如图1。该问题的解决办法是要使MME能再次向切换的目标小区（eNB-B）发专载建立请求，即，在目标小区上发Path Switch Rquest ACK之后再发ERAB Setup Request。具体是通过升级SGW来解决该问题。但是，升级之后，又会牵出新问题，请见本节第3点的讨论。
图1 专载建立与空口切换流程冲突
2、切换与专载释放流程冲突导致的异常
上述现象在专载建立、修改和释放阶段都可能概率性发生，在建立和修改阶段一般会伴随出现503错误，导致未接通；在释放阶段，如果出现该问题则要严重得多——有可能会出现一种死循环，QCI1专载一直无法释放，除非人工干预（关机重启或飞行模式切换），否则可能永远无法做主被叫。
被挂侧（UE-B）出现RRC重建，没有及时接收到SIP消息，但S-CSCF先触发500(ServerInternal Error)，并清理了主挂侧的QCI专载和会话；但S-CSCF未同步清理被挂侧，直到SIP重传超时后，通过408(Request Timeout)清理IMS域会话；被挂终端每隔4秒重复BYE消息，SBC认为会话已结束，回复481(Call/Transaction Does Not Exist)，未触发MME启动专载释放流程，同时终端没有其他途径通知MME启动专载释放流程，因此QCI1专载一直吊死，后续通话无法进行。
图2 专载无法释放，无法做主被叫，频繁出现481，487和488错误
需要指出的是，切换是导致QCI1专载无法释放的原因之一，还有很多其他的可能，为避免上述这种极端的情况出现，建议SBC无论在收到或发出BYE消息之后，不要等待BYE200消息的确认，无条件启动会话清理和专载释放流程。
3、SGW升级后连续下发S1AP消息导致的异常
为了解决本节第1点的问题，现网中通过对SGW升级来使MME能向目标小区重发专载建立请求（ERAB Setup Request），但该消息的发送时机不当仍然会导致产生一些异常。
（1） ERAB Setup Request消息在PathSwitch Request ACK之前抵达
图3 ERAB Setup Request消息在PathSwitch Request ACK之前抵达
目标eNB（eNB-B）尚未完成S1承载的切换，因此会以cause值“unspecified”响应建立请求，专载建立失败，SBC将下发503错误。该现象说明SGW的处理机制存在一定问题，必须在Path Switch Request ACK之后再重发专载建立请求。
（2）ERAB Setup Request在Path Switch Request ACK之后1ms左右达到
eNB未响应专载建立请求
图4 专载建立请求消息丢失
根据3GPP规范和中国移动的技术白皮书，S1/X2切换目标侧执行阶段，基站必须先响应切换执行，然后再处理专载管理。由于eNB没有缓存该消息，导致没有响应专载建立请求。解决办法是对eNB做参数调整或升级，使其能够缓存ERAB管理消息 (erabsetup/ erab modify/ erab release )。
eNB异常处理NAS消息
图5 空口QCI1 DRB未释放
eNB响应了S1承载删除请求，但没有将NAS消息进一步传递给UE，导致UE的上下文出现异常，庆幸的是这个eNB还有点靠谱，及时发现上下文异常，主动请求MME清理UE上下文并释放RRC Connection。虽然本例现象发生在业务释放阶段，在SBC满足第2点改造要求的情况下，对业务体验不会有明显影响。如果eNB不及时清理，或者SBC不及时清理，就有可能出现上述第2点的死循环现象。
注：CDS仪表会统计为一次掉话，对路测指标仍有不良影响。
4、Gx和Rx流程异常导致的专载建立失败
PRCF的Gx和Rx接口采用Diameter信令，基于L-DRA路由，由于L-DRA的缓冲时延或者路由迂回都可能导致Gx链路时延大，RAR未及时发送到PGW，同时因X2/S1切换 SGW向PGW请求修改专载。根据协议规定，PGW会继续SGW-initiated bearer modification procedure而reject RAR(result code: DIAMETER_OUT_OF_SPACE)。该问题与第1点类似，也是专载建立与切换流程冲突造成的专载建立失败，同样会触发503错误，不过第1点冲突是发生在空口，本点是发生在EPC域内。
图6专载建立与EPC切换流程冲突
上面是几种比较典型的专载管理（建立、修改和释放）与切换流程冲突的情况。总结一下：
专载建立与流程冲突：主叫会收到503，终端主动转CSFB；被叫会发出580，然后收到Cancel由网络发CS paging转CSFB。
专载修改与流程冲突：空口的专载修改一般在主叫侧发生，终端会发出Canel，主动转CSFB。
专载释放与流程冲突：若SBC未及时触发专载清理，或者eNB丢失S1AP消息，有很可能出现死锁现象，导致无法主被叫，特别是在被挂侧；若SBC已升级（收到BYE消息立即清理）且MME由S1AP消息重发机制，则目前的问题主要集中在基站上。主要的问题是路测仪表统计为掉话，但不影响客户感知。
联系客服
