VOLTE案例汇总目录1：覆盖类问题31.1：地形环境导致弱覆盖31.2：邻区漏配导致弱覆盖31.3：站点故障导致弱覆盖51.4：越区覆盖导
致无法切换52：干扰类问题73：已知版本问题93.1：Pathswichfail故障导致切换后掉话或重建后被拒93.2：基站发送T
M3\8切换后掉话104：终端异常124.1：终端异常主动挂机导致未接通事件134.2：终端不上报TAU请求135：测试软件统计1
45.1：异常统计掉话146：eSRVCC切换问题分析146.1：GSM邻区参数错误导致掉话146.2：切换准备失败166.3：G
SM邻区频点配置不全177：其他187.1：TAU 更新完成发起CSFB187.2：承载建立异常187.3：VoLTE跨异厂家MM
E切换失败分析197.4：中兴SBC与华为PCRF接口交互问题227.5：河东VoLTE呼叫时延问题分析247.6：VoLTE连续
呼叫出现CSFB现象分析287.7：河西被叫寻呼响应时延异常分析317.8：关于Rx接口会话内消息携带Dest Host AVP的
问题的分析327.9：核心网侧未配置完整性保护和加密算法导致呼叫失败397.10：中兴HSS返回UDA(LOC)的格式错误407.
11：SBC收到UPDATE的200OK后没有转发427.13：江苏漫游卡发起Ut业务失败427.14：SIP over TCP被
叫接续时延问题437.15：湖南漫游卡在江苏作被叫回落CSFB437.16：视频互通问题441：覆盖类问题1.1：地形环境导致弱覆
盖【问题表象】路测表现为：主被叫手机当前小区和所有邻区RSRP均小于-110dbm，无主服务小区导致SINR<-3dbm,无线环境
恶化，导致掉线、切换失败、接入失败等异常事件频发。 【问题分析方法】结合现场环境和基站拓扑图，对周边所有基站进行逐个勘察和验证覆盖
，对于地形原因导致无法彻底解决的区段，提交后续工程建设方案。【解决方案】：1：核查局方站点规划方案，如果有规划站点，提高建设开通优
先级，如果无建设规划，提交建站方案；2：测试2G网络覆盖情况，对于2覆盖良好情况下，开启SRVCC功能；同时确保2G侧FR功能开启
，确保及时回落4G。3：对于有测试考核要求的情况下，采取规避路线，减少异常事件发生概率；1.2：邻区漏配导致弱覆盖【问题表象】DT
测试中，此类问题主要表象为如下几种情况：频发A3事件而无法切换；通常伴随主被叫占用小区不同，RSRP相差较大；切换链紊乱；容易引发
掉线、重建立、切换失败等事件如下图：【问题分析方法】1：前台测试分析，核对A3事件上报小区信息是否包含在RRCConnection
Reconfiguration。如未包含，则确定为漏配邻区。核对基站拓扑图，判断是否需要添加该邻区，排除过覆盖、针状覆盖小区（室分
泄露小区、非道路覆盖小区等）尤其需要慎重添加，防止切换后无法及时切出问题发生。如下图所示，两个基站相距200m，并且为相邻基站，所
以建议补充邻区关系2：后台IMSI跟踪信令分析，可以通过UDA工具筛选UnknowPciNotify，对于持续上报未定义PCI的现
象要重点结合基站拓扑图来进一步确定是否添加邻区。如下图，后台信令分析同样发现上报多个测量报告切换候补邻区为486，结合拓扑图，最终
建议添加邻区关系 【解决方案】：1：近距离相邻基站通常采用添加遗漏邻区方案；2：过覆盖小区优先控制覆盖；3：针状覆盖场景不建议添加
，此问题一般影响较短路面，优先控制覆盖；1.3：站点故障导致弱覆盖【问题表象】测试中，此问题表现为：无法占用附近基站，会伴随邻区漏
配、过覆盖情况发生，易导致未接通、掉线、切换链紊乱等现象；如下图，基站462682位于麓枫路和咸嘉湖西路十字口，为该两条主干道主服
务小区，测试到该路段后始终未占用该基站，RSRP下降到-110dbm以下，切换链紊乱，导致掉线。【问题分析方法】告警排查，确定是否
存在告警信息，重点关注：中断告警、时钟告警、驻波比告警、传输告警等严重影响业务类告警；【解决方案】：优先恢复告警，尤其针对2\3\
4共站址基站要优先解决，否则SRVCC无法正常到达2G或者在2G侧引发异常事件概率大增。1.4：越区覆盖导致无法切换【问题表象】过
覆盖问题主要表象为：未占用过覆盖小区情况下，当前小区可能会发生SINR恶化，伴随上报测量报告包含周边未知PCI。占用过覆盖小区情况
下，RSRP变化较大，伴随上行信号异常，邻区漏配现象，易导致掉线、接入失败、切换失败等异常事件。如下图，手机占用PCI=121小区
，enodeid=471089，无法向周边PCI=110切换，最终导致掉话； 【问题分析方法】此类问题需要结合周边道路测试分析和基
站拓扑关系来判断问题小区为周边哪个区域的主覆盖小区，进而采取优化手段进行调整；如下图描述，问题点区域最近4次切换链为1、2、3、4
次切换，其中2、3、4切换和PCI=121有关，同时分析周边道路主服务小区并无PCI=121,查看拓扑图发现该站位于周边较远区域，
同时前往PCI=121测试发现，经纬度正确，主要原因是地势较高导致；【解决方案】：针对周边过覆盖小区，采用调整俯仰角、天线挂高、基
站分布等手段；对于特殊场景建设的基站，比如此案例中该站实际主要覆盖附近风景区，但是地势原因导致信号无法彻底控制，可以采取单向删除过
远基站邻区，避免孤岛效应。2：干扰类问题【问题表象】测试中一般表现为RSRP良好但SINR偏差，干扰严重区域容易导致掉线、切换失败
等各类异常事件发生。【问题分析方法】干扰类问题涉及方面较多，有系统内干扰和系统外干扰，详细排查方法可以参考排查指导文档，这里仅仅对
现场发现的案例进行描述。实例1：PCI规划不合理导致下图中，测试区域发现信号RSRP良好同时伴随SINR较差，优先排查PCI规划问
题，发现近距离有同PCI基站，如下图：实例2：重叠覆盖引发干扰网格17内西二环路段存在同频基站分布密集，存在200-300米路段S
INR差，此段路段发生重建概率较高，是掉话隐患点，23日测试发生1起主叫掉话。下图圈中区域来自4个站点信号均在-95dbm~-10
0dbm，当切换到PCI=66/67后，SINR容易恶化，地势较为平坦，周边间距均在300-400m。【解决方案】：针对PCI规划
不合理问题，建议重新规划和修改PCI。针对重叠覆盖引发干扰问题，首先通过RF优化控制覆盖，减少重叠覆盖，其次采用异频组网方案解决。
比如此西二环路段，PCI=66/67/68三个小区可以不用覆盖该路段，其他三个小区可以良好覆盖不同区段，引入PCI=66/67/6
8后易发生摸3干扰。3：已知版本问题3.1：Pathswichfail故障导致切换后掉话或重建后被拒【问题表象】前台测试中在发起切
换或重建立，收到重配消息和上报重配完成后随即收到RRC释放消息。后台IMSI跟踪可以发现有Path switch request
failure【问题分析】下图中，手机发生重建立后，收到RRCConnectionReconfiguration并上报完成消息后，
随即收到RRCConnectionRelease，容易造成未接通或掉话事件。同时间段后台信令中发现收到核心网侧下发的Path sw
itch request failure。见下图：该问题原因是版本问题导致选择MME错误导致.【解决方案】：此问题为已知版本问题，
需升级版本解决。3.2：基站发送TM3\8切换后掉话【问题表象】从前台信令看掉话流程，终端的模式为TM3，然后上发A2测量，然后终
端收到异频测量控制的重配消息，发送完成后下行链路失步，之后发起重建后掉话。此过程中，无线环境在RSRP -100，SINR 3左右
。从后台信令分析，基站侧收到终端上发的A2，然后下发测量重配消息，紧接着发送TM8模式切换的重配消息，出现TM8的重配无法下发，用
户面上报SRB1的RLC的ERRORIND导致释放而掉话【问题分析】12:09:14秒的重配置为TM3模式12:09:14秒上发的
是A2测量重配，然后广播消息，在12:09:26秒收到重建请求后被拒。12:09:26秒终端上发BYE掉话。基站侧12:09:18
收到A2测量12:09:18秒TM8模式转换的重配。12:09:25秒出现错误的标示，该重配未下发，达到最大重传次数。12:09:
25秒文本释放。【解决方案】：需要版本升级解决，目前规避措施是改为强制TM3模式。4：终端异常4.1：终端异常主动挂机导致未接通事
件【问题表象】被叫向主叫发180振铃消息，主叫端也成功收到被叫180振铃消息，但在被叫发出180消息后，紧接着3秒后向主叫发406
用户忙消息（见下图），核心网收到后给主叫放音，然后释放，相同的现象，两次呼叫未接通。从信令上看，被叫发486用户忙消息，是终端主动
拒绝的原因，和网络无关。至于被叫为什么在振铃3秒后发用户忙和拒绝消息，终端问题，需要终端解决。4.2：终端不上报TAU请求【问题表
象】主叫正常呼叫后从PCI=17,TAU=29580小区切换到PCI=64，TAU=29482小区后不主动发起TAU请求后RRC释
放,重新接入到其它小区,3次重复这样过程后，终端主动发BYE，被叫终端TAU正常。由于对于不同TAU切换后手机终端需要上报TAU请
求，此处终端始终未发起TAU，为终端原因5：测试软件统计5.1：异常统计掉话【问题表象】被叫在2G下人工释放，上报DISCONNE
CT，挂机流程结束，此时主叫在4G下收到IMS下发BYE，并去激活了QCI=1承载，并标记为normal call clearin
g，但仍会统计为dropped ，此时主叫继续正常释放流程，为软件统计问题。6：eSRVCC切换问题分析6.1：GSM邻区参数错误
导致掉话【问题表象】手机在LTE覆盖弱场，收到B2测量的重配消息后，手机发起Measurementreport（B2事件）后收到网
络下发的RRC Connection Release，重定向到2G后掉话。【问题分析方法】当UE上报A2测量报告后，eNB下发B2
重配消息给UE，根据B2重配消息，UE测量满足B2-1和B2-2条件并上报B2事件，上报的B2事件包含准备切换的目标2G小区BCC
H/NCC/BCC，见下图：正常情况下，eNB收到该B2事件测量报告后下发mobilityFromEUTRACommand消息给U
E，切换到该GSM邻区；异常情况下网络下发RRC Connection Release消息使UE重定向到BCCH为512的GSM小
区，如下图：随后主叫重定向到GSM网络，在2G网络手机状态是空闲态，统计为掉话，如下图：通过以上现象分析可知UE VoLTE业务e
SRVCCC切换到BCCH 525(BSIC 12)的G网邻区失败，核查网管中该G网邻区参数配置，发现该邻区BSIC配置为7，与实
际UE测量的BSIC 12不一致，修改网管中该G网邻区BSIC为12后，可正常切换到该小区，掉话解决【解决方案】：同步LTE-->
GSM网络邻区定义和实际GSM网络规划数据，如上案例，LTE-->GSM邻区定义中BSCI配置为7，而实际UE测量的BSIC为12
，将LTE定义GSM邻区中BSIC改为12后，正常eSRVCC。6.2：切换准备失败【问题表象】UE空口表现为发起多次B2测量后无
法进行eSRVCC，最终易导致重建立和掉话事件发生；eNB侧表现为接收到手机上报B2测量并发起切换请求，但是收到来自核心网的切换准
备失败消息；【问题分析方法】正常情况下，eNB收到该B2事件测量报告后下发mobilityFromEUTRACommand消息给U
E，UE会收到mobilityFromEUTRACommand并实施切换；异常情况下，UE发起多个B2事件而未收到mobility
FromEUTRACommand，此时可能涉及空口无线环境恶化导致B2事件测量报告未上报给eNB，需要结合eNB侧信令分析。如下图
：当eNB收到B2测报后向MME发送handover require消息（为eSRVCC切换准备资源），但随后收到了切换准备失败的
回复。见下图：导致此类失败的原因通常是核心网没有对目标小区配置eSRVCC相关功能参数的原因，需要核心网检查目标网络小区相关参数是
否生效或正确配置。【解决方案】：导致此类失败的原因通常是核心网未配置SRVCC功能、未配置目标MSC、未配置TAU等原因，需要同核
心网及目标网络核查相关配置是否生效。6.3：GSM邻区频点配置不全 【问题表象】UE上报A2事件后，网络下发B2重配消息并成功上报
网络后，手机RSRP满足B2-1判决门限却始终未上报B2事件测量报告，最终容易导致重定向、掉话事件发生【问题分析方法】实际网络中会
存在由于无线环境的改变、G网参数优化后同步不及时或RF优化等原因，导致LTE小区的GSM邻区频点配置不够准确，对于A2重配里下发的
GSM频点在终端测量后，不满足B2-2事件，导致无法触发eSRVCC。如下图：其他可能原因：需要检查系统间邻区是否已经设置为“支持
切换”，如下图【解决方案】：完善和及时更新LTE邻区定义中的GSM邻区关系和参数定义；对于问题点，建议进行GSM网络扫频或者结合G
SM测试数据分析，检查这些频点是否已包含在后台配置中7：其他7.1：TAU 更新完成发起CSFB【问题表象】前台测试中，寻呼被叫手
机时正在进行TAU，导致该寻呼未响应，TAU成功后手机监听PAGING消息。核心网在PS域寻呼未收到响应后会针对该手机发起CS域寻
呼，因此触发手机发起了CSFB流程，软件统计为异常。如下图：7.2：承载建立异常【问题现象】主叫发起会话请求，无响应，导致未接通；
【问题描述】主叫12:27:57发起invite，12:28:13 无响应之后未接通，检查DRB承载，发现优先级为9的承载有两条，
如下图所示：【解决方案】HSS删除多余APN签约，之后恢复正常，如下图所示；7.3：VoLTE跨异厂家MME切换失败分析【问题描述
】湖南移动在长沙做跨MME的VoLTE语音切换时，发现从河西（中兴EPC、无线覆盖区域）切换到河东（华为EPC和无线覆盖）区域时，
切换成功；反之，从河东切换到河西则会掉话。【问题分析】华为侧跟踪信令分析：从华为MME上的信令来看，切换流程是成功的。在Forwa
rd Relocation Request消息里面，华为MME已经将bearer ID=5/6/7的承载信息都传递个中兴MME了，
需要MME侧转包分析收到Forward Relocation Request消息后的处理流程是否正常。并提供整理信令流程截图和Fo
rward Relocation Request里关于bearer ID=5/6/7承载的相关信息供中兴分析参考。 中兴侧跟踪信令
分析：看华为-中兴的切换信令流程，应该都是走完了，但是在比对中兴切华为和华为切中兴的消息时发现一个问题，在“forward rel
ocation request”里面，中兴MME带上了“Additional MM context for SRVCC”和“Add
itional flags for SRVCC”这两个IE，而华为MME在往中兴MME切换的时候在“forward relocat
ion request”里面看不到这两个IE。3GPP 29.274上对这两个IE对于SRVCC业务定义是必须的：8.90Addi
tional MM context for SRVCCThe additional MM Context for SRVCC in
formation element contains mobile station classmarks, supported c
odec list that are necessary for the MME/S4-SGSN to perform SRVCC
as defined in 3GPP TS 23.216 [43].定位分析缺少这两个IE是导致切换后掉话的原因。继续分析为什么
会导致IE缺失？中兴分析HW MME没有把专有承载带给中兴MME，HW MME向华为发的Forward Relocation Re
quest消息中没有将QCI=1的承载上下文带过来，见下图：华为反馈在他们设备上跟到的消息是带了ebi=7，qci=1的承载的，而
中兴侧看不到。首先排除了IMS侧的可能性，因为在切换流程中，不涉及IMS网元。继续验证中兴两个MME38、39局，发现：MME38
局，从HW切换到中兴MME的时候，对方没有带专有承载过来MME39局，华为带有承载的信令，中兴MME没有解开。仔细分析华为MME信
令的码流，华为MME消息中携带的专有承载列表信息中的Spare/Instance字段中的Spare位为2。一般情况下发送方默认填写
0值，而接收方应该忽略。但中兴MME判断Instance字段合法性的时候，判断过严，对Spare位非0值判断错误，跳过这个IE，继
续后面的解码，导致切换掉话。 参见下面码流和定义表格：5D 00 3E 20 49 00 01 00 07 57 00 09 00
81 01 18 F6 F8 64 4E FF 30 57 00 09 01 85 01 40 87 44 DF 67 15 2
4 50 00 16 00 08 01 00 00 00 00 5F 00 00 00 00 34 00 00 00 00 5F
00 00 00 00 34 89 00 01 00 A0BitsOctets876543211Type = xxx (decim
al)2 to3Length = n4SpareInstance5 to (n+4)IE specific data or con
tent of a grouped IE现场两个解决方案：华为MME修改该字段参数为默认0值；中兴MME修改判断规则，对Spare
字段非0值忽略；【解决方案】1，在省公司协调下，由中兴MME修改判断规则，对Spare字段非0值忽略。2，修改判断规则后，再次现场
验证，从河东MME切换到河西MME成功。7.4：中兴SBC与华为PCRF接口交互问题【问题现象】现场测试发现，我司S-CSCF处理
SBC转发主叫发起的invite消息时回复了500错误。错误的原因是由于SBC发送给S-CSCF网元的INVITE消息中携带的PC
V头部有问题，具体的PCV头部信息如下：SIP信令中PCV头部中携带了两个ecid信息（红框显示），第二个ecid是“1F890A
6F”，这个里面有一个换行符（0A），导致S-CSCF网元上解码认为头部结束，从而认为不合语法规范，获取ecid失败。【问题分析】
目前我司SBC对Rx接口AAA以及RAR消息中返回的Access-Network-Charging-Identifier-valu
e字段类型的理解，认为只会返回可见字符的处理（如a-z\A-Z字母字符，0-9数字字符），对于部分不可见字符不支持将其转换为HEX
DIG类型。从协议规范语法上的定义如下：PCRF等网元通过Rx接口返回的接入网络计费标识值（Access-Network-Char
ging-Identifier-Value）的语法类型定义：根据29.214协议：The Access-Network-Charg
ing-Identifier-Value AVP (AVP code 503) is of type OctetString, a
nd contains a charging identifier。 SBC通过Rx接口返回的信息，通过ecid参数来编码上述计费
标识信息，SIP协议的语法定义如下（24.229协议）：eps-bearer-hierarchy = "eps-info" EQU
AL LDQUOT eps-info (COMMA eps-info) RDQUOT eps-info = eps-item S
EMI eps-sig SEMI ecid [SEMI flow-id] eps-item = "eps-item" EQUAL
DIGIT eps-sig = "eps-sig" EQUAL ("yes" / "no") ecid = "ecid" EQUA
L 1HEXDIGDIGIT = %x30-39 ; 0-9 HEXDIG = DI
GIT / "A" / "B" / "C" / "D" / "E" / "F" 根据上述语法定义，这里涉及一个OctetStrin
g到HEXDIG字符的转换问题，目前我司SBC对Rx接口返回的部分不可见字符不支持（如现场抓包中的0x1f890a6f），具体原因
见如下抓包截图：SBC收到invite请求后进行Rx接口查询返回的信息（AAA消息以及RAR消息）抓包截图如下：可以看到，Rx接口
返回给SBC的Access-Network-Charging-Identifier-value信息为1f890483（AAA消息中
返回）以及1f890a6f（RAR消息中返回），这其中包含了不可见字符。【解决方案】通过上述分析，该问题是一个不同厂商网元间对接口
字段类型理解不一致的IOT互通问题。目前我司SBC网元，我司对RX接口中的信息理解为作为可见字符来处理，不支持华为网元通过Rx接口
返回的不可见字符（如现场抓包中的1F 89 0A 83），后续若要支持，需要做Octet String到HEXDIG的类型转换处理
。因此，后续的方案如下：解决方案一：建议华为网元是否可以对该ecid生成的规则做一下说明，能否修改为可见字符（0x30-39，以及
A-Z a-z）规避解决；解决方案二：该问题，计划SBC进行相应的版本或补丁解决，支持Octet String到HEXDIG的类型
转换处理。7.5：河东VoLTE呼叫时延问题分析【问题描述】湖南移动在长沙河东（华为EPC和无线覆盖）区域进行现场短呼叫测试，发现
呼叫时延较长，大部分都达到4s以上，因此进行分析。 【问题分析】在2015年1月27日进行了路测和抓包，同时联合华为和无线外场进行
了抓包和信令保持，通过信令抓包分析见下面详细描述。以其中一个呼叫为例进行分析，该呼叫核心网整体时延4.3s，计算收到主叫终端上行的
INVITE消息到向主叫终端发送下行的180 RINGING消息之间的时延。首先主叫SBC收到主叫终端INVITE消息后触发Rx口
流程，从发出AAR到收到AAA消息总共290ms，同时由于AAR消息要求上报位置信息（AVP：Specific-Action：Ac
cess_Network_Info_Report）,但是没有收到上报，500ms超时后才转发INVITE给CSCF，总共时延790
ms到主叫SCSCF后经过主叫AS触发，Cx接口流程到达被叫SCSCF，中间各网元处理时延都比较正常。到达被叫SCSCF后触发SC
C AS做域选择，在SH接口的时延总共130ms，其中从DRA收到消息到DRA转发消息之间时延总共67+53=120ms完成被叫A
S触发后到达被叫SBC，触发Rx口流程，从发出AAR到收到AAA消息总共301ms，同时由于没有AAR要求的收到位置信息上报，50
0ms超时后才转发INVITE给CSCF，总共时延801ms被叫终端收到INVITE后，回复183消息，在被叫SBC触发Rx接口，
从发出AAR到收到AAA消息时延284ms183消息经过IMS核心网到达主叫SBC，触发Rx接口，从发出AAR到收到AAA消息时延
270ms183消息发送给主叫，完成第一次协商交互主叫终端完成Precondition流程的资源预留后，发出Update消息，到达
主叫SBC后触发Rx口流程，从发出AAR到收到AAA消息时延277ms Update转发到被叫SBC后，Rx接口从发出AAR到收到
AAA消息时延137ms被叫终端收到Update后回复200 OK（Update），到被叫SBC后触发Rx接口流程，从发出AAR到
收到AAA消息时延285ms200 OK（Update）送到主叫SBC后，主叫SBC触发Rx口流程，从发出AAR到收到AAA消息时
延139ms综上所述，总共4.3s的时延中，Rx接口DRA+PCRF+EPC时延就有2983ms，占比超过一半，建议DRA+PCR
F+EPC各网元重点分析一下是否合理；需其中主叫SBC和被叫SBC发送AAR消息中携带要求上报位置信息（AVP：Specific-
Action：Access_Network_Info_Report），但是没有收到上报，总共约1s（500ms+500ms）需要重
点解决。另外，SH接口时延130ms中DRA转发消息的时延120ms，占比超过90%，也需要DRA分析一下。同时，在呼叫中同时存在
另外一个问题，呼叫中被叫的响应时间不稳定，有时候会比较长，导致从被叫SBC发送INVITE消息到收到终端响应时间很长，也会影响呼叫
时延。上面的时延分析特地选取了响应时长较短的一次（305ms），排除了这个方面的影响，如下面这次呼叫，从被叫SBC发INVITE到
收到终端的100 TRYING有1.3s多，中间SBC还将INVITE重发了一次（第一次重发500ms）【解决方案】1，PCRF和
EPC确认并定位解决没有上报位置信息的问题2，DRA+PCRF+EPC各网元重点分析当前Rx口时延是否合理3，DRA分析SH接口的
转发时延是否合理4，EPC+无线侧分析解决INVITE下发到终端响应时间较长的问题7.6：VoLTE连续呼叫出现CSFB现象分析【
问题描述】湖南移动在长沙河东（华为EPC和无线覆盖）区域进行现场短呼叫测试，测试中发现二个终端反复发起VoLTE呼叫，一段时间后被
叫终端会发起CSFB，主叫终端呼叫一直保持VoLTE呼叫。【问题分析】华为侧经过分析，被叫SBC发起的AAR-I消息中，携带的流描
述信息中IP为IPv4，PCRF转发给PGW，而PGW只配置了支持IPv6，因此当PGW接收到流描述信息中的IP为IPv4时，直接
给PCRF响应成功，同时在charging-rule-report标识专有承载创建的规则为inactive，PCRF将PGW的响应
传递给了SBC，同时把规则标记为inactive。经过多次呼叫后（大概40次），由于单个用户inactive规则数过多，PCRF会
给SBC响应5063错误，导致了用户CSFB。华为认为根据集团规范《中国移动通信网络组织规范_VoLTE_局数据设置原则分册 v1
.0.0.doc》要求如下所示，终端地址类型只有IPv6，要求将AAR-I消息中的地址修改为IPv6而实际上，上述规范要求的是终端
的地址是IPv6，而并没有规定AAR-I消息中必须是IPv6的地址；而在呼叫过程中被叫SBC收到网络的INVITE消息，并触发Rx
接口发出AAR-I消息时候，其Flow Description的填写是从收到的INVITE中的SDP中的C行获取的，而被叫SBC收
到的INVITE消息中，是不存在IPv6的地址的关于AAR消息的Flow Description字段填写，在3GPP 29.213
Table 6.2.2: Rules for derivation of Media-Sub-Component AVP fro
m SDP media component中有如下的规定，Flow-DescriptionFor uplink and downl
ink direction, a Flow-Description AVP shall be provided unless no
IP Flows in this direction are described within the media compon
ent.If UDP is used as transport protocol, the SDP direction attri
bute (NOTE 4) indicates the direction of the media IP flows withi
n the media component as follows: IF a=recvonly THEN (NOTE 3) IF
= UE originated (NOTE 7) THEN Provide only downli
nk Flow-Description AVP ELSE / UE terminated (NOTE 7) / Provide
only uplink Flow-Description AVP ENDIF; ELSE IF a=sendonly THEN
(NOTE 3) IF = UE originated (NOTE 7) THEN Provide
only uplink Flow-Description AVP ELSE / UE terminated (NOTE 7)
/ Provide only downlink Flow-Description AVP ENDIF; ELSE / a=se
ndrecv or a=inactive or no direction attribute / Provide uplink
and downlink Flow-Description AVPs ENDIF; ENDIF;However, for RTCP
IP flows uplink and downlink Flow-Description AVPs shall be prov
ided irrespective of the SDP direction attribute.If TCP is used a
s transport protocol (NOTE 8), IP flows in uplink and downlink di
rection are described in SDP irrespective of the SDP direction at
tribute, as TCP uses an IP flow for feedback even if contents are
transferred only in the opposite direction. Thus, both uplink an
d downlink Flow-Description AVPs shall be provided.The uplink des
tination address shall be copied from the "c=" line of downlink S
DP. (NOTE 6) (NOTE 7)The uplink destination port shall be derived
from the "m=" line of downlink SDP. (NOTE 6) (NOTE 7) However, f
or TCP transport the uplink destination port shall be wildcarded,
if the local UE is the passive endpoint (NOTE 9)The downlink des
tination address shall be copied from the "c=" line of uplink SDP
. (NOTE 6) However, a P-CSCF acting as AF and applying NAT traver
sal procedures in Annex C shall derive the downlink destination a
ddress using those procedures.The downlink destination port shall
be derived from the "m=" line of uplink SDP. (NOTE 6) (NOTE 7) H
owever, for TCP transport the downlink destination port shall be
wildcarded, if the local UE is the active endpoint (NOTE 9). A P-
CSCF acting as AF and applying NAT traversal procedures in Annex
C shall derive the downlink destination port using those procedur
es.For IPv6, uplink and downlink source addresses shall either be
derived from the prefix of the destination address or be wildcar
ded by setting to "any", as specified in 3GPP TS 29.214 [10]. How
ever, a P-CSCF acting as AF and applying NAT traversal procedures
in Annex C shall derive the uplink source address using those pr
ocedures.If IPv4 is being utilized, the uplink source address sha
ll either be set to the address contained in the "c=" line of the
uplink SDP or be wildcared, and the downlink source address shal
l either be set to the address contained in the "c=" line of the
downlink SDP or be wildcarded. However, for TCP transport, if the
local UE is the passive endpoint (NOTE 9), the uplink source add
ress shall not be wildcarded. If the local UE is the active endpo
int (NOTE 9), the downlink source address shall not be wildcarded
. A P-CSCF acting as AF and applying NAT traversal procedures in
Annex C shall derive the uplink source address using those proced
ures.Source ports shall not be supplied. However, for TCP transpo
rt, if the local UE is the passive end point (NOTE 9), the uplink
source port shall be derived from the “m=” line of the uplink SD
P. If the local UE is the active end point (NOTE 9), the downlink
source port shall be derived from the “m=” line of the downlink
SDP. A P-CSCF acting as AF and applying NAT traversal procedures
in Annex C shall derive the downlink source ports using those pro
cedures.Proto shall be derived from the transport of the "m=" lin
e. For "RTP/AVP" proto is 17(UDP). For "TCP", as defined in RFC 4
145 [16], or " TCP/MSRP", as defined in RFC 4975 [17], proto is 6
(TCP).【解决方案】1，中兴SBC在AAR-I消息的填写以及Rx接口的触发流程，是符合3GPP协议和中国移动规范要求的，不能做
修改。2，华为PCRF在接收到PGW无效规则处理方面存在缺陷，导致了一段时间后被叫终端CSFB的发生，需要华为PCRF进行修改。详
细描述在华为提供的问题分析报告的”解决方案”部分有描述，但是放在了”其他说明”部分第2点。7.7：河西被叫寻呼响应时延异常分析【问
题现象】湖南VoLTE试点测试中，终端空闲态时，被叫寻呼响应时延异常，有时4s、8s、11s时才寻呼成功，导致呼叫建立时延过长，影
响用户体验。【问题分析】从SBC下发Invite到PGW，以及MME向eNB发送Paging消息的时延固定。从MME跟踪信令发现，
发送Paging到收到Paging Service Request的时延间隔有较大变化。在SBC侧跟踪信令发现，被叫寻呼时延较大时
，SBC向PGW发送2-3次Invite消息。从流程上分析，SBC发送Invite消息，如果寻呼成功，UE回100Try给SBC，
如果超时未回，SBC会重新发送Invite消息，SBC重新发送的时间间隔依次为1s，2s，4s…。因此初步判断在PGW上未把该缓存
开关打开。该功能用于Invite消息缓存，当UE超时未回100Try，PGW立刻使用该缓存，直至使用完，如果S1u还未建立完成，则
后续的下行报文丢弃。【解决方案】打开PGW上的缓存开关，设置缓存数目3。现场测试验证，被叫寻呼时延稳定在1.5s左右，不再出现超长
寻呼时延。7.8：关于Rx接口会话内消息携带Dest Host AVP的问题的分析【问题描述】湖南移动现场中兴SBC和华为DRA对
接的Rx口时，应华为DRA要求，在AAR消息中不带Destination-Host AVP，在会话结束后，华为DRA最后接收到的S
TR消息中也未带有Destination-Host AVP，华为DRA最终不能释放本次会话资源。影响到双方对接测试。【处理过程】通
过分析现场反馈的系统日志和信令抓包故障原因已经确定，并通过和集团网络技术部孟令希进行技术沟通，确定由中兴SBC修改来配合本次对接。
【问题分析】本次故障产生的技术原因分析如下：根据现场反馈的系统日志如下，已定位出故障原因。华为DRA和中兴SBC双方在协议理解方面
没有达成一致。中兴分析如下：一、根据RFC6733 Diameter Base Protocol的描述，STR消息中，Destin
ation-Host AVP是可选的。 Message Format ::= < Diameter Header: 2
75, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } {
Destination-Realm } { Auth-Application-Id } { Termination-Cause }
[ User-Name ] [ Destination-Host ] [ Class ] [ Origin-State-Id
] [ Proxy-Info ] [ Route-Record ] [ AVP ]二、 根据3GPP TS 29.2
13 V12.4.1 的7.4.1.3 Termination of Diameter Sessions章节，7.4.2.1.1
Non-roaming cases小节的描述: Figure 7.4.1.3.1.1: Termination of Diamet
er sessions through DRA (proxy)1. A Client receives an external t
rigger (e.g. an IP-CAN session termination is initiated by the UE
or PCRF) that requires the sending of a Diameter Termination Req
uest.2.A Diameter Termination Request (e.g., a Diameter CCR sent
by PGW to indicate termination of an IP-CAN session) as defined i
n clauses 4.5, 4a.5 of 3GPP TS 29.212 [9]) is sent by the Client
to the DRA (proxy). The message uses the same Session-Id AVP valu
e of the active Diameter session established between the Client a
nd PCRF-1.3. The DRA (proxy) verifies that there is an active DRA
binding for the IP-CAN session based on the Session-Id AVP in th
e request. 4. The DRA (proxy) proxies the Diameter Termination Re
quest to the target PCRF. The proxied Diameter Request maintains
the same Session-Id AVP value.从以上的描述可以看出：没有要求AF在STR消息中需要填写Destina
tion-Host AVP，DRA判断STR使用属于某一活动会话和路由该STR消息去PCRF，是依据 Session-Id AVP
，和是否有Destination-Host AVP没有关系 三、在DRA组网中， Diameter会话内消息填写Destinati
on-Host AVP是有特定用途的。可以参考3GPP TS 29.213 V12.4.1 的7.4.1.1Establishme
nt of Diameter Sessions章节，7.4.1.1.1Non-roaming cases小节的描述:Figure
7.4.1.1.1.1: Establishment of Diameter sessions using DRA (proxy)
1. A Client receives an external trigger (e.g. IP-CAN session est
ablishment request) that requires the establishment of a Diameter
session with a PCRF.2. A Diameter Request (e.g. a Diameter CCR s
ent by PGW to indicate establishment of an IP-CAN session as defi
ned in clauses 4.5.1, 4a.5.1 of 3GPP TS 29.212 [9]) is sent by th
e Client and received by a DRA (proxy). 3. The DRA (proxy) stores
the user information (e.g. UE-NAI) and checks whether an active
DRA binding exists. If not, the DRA creates a dynamic DRA bindin
g (assignment of a PCRF node per UE or per IP-CAN session).NOTE 1
:When the AF establishes an Rx session or TDF establishes a TDF s
ession with the DRA, there is already a DRA binding active.4. The
DRA (proxy) proxies the Diameter Request to the target PCRF. The
proxied Diameter Request maintains the same Session-Id AVP value
.5. PCRF-1 returns a Diameter Answer as defined in clauses 4.5, 4
a.5 of 3GPP TS 29.212 [9] to the DRA (proxy).6. DRA (proxy) proxi
es the Diameter Answer to the Client. The proxied Diameter Answer
maintains the same Session-Id AVP value.7. If PA2 option is impl
emented, the Client uses the Origin-Host AVP value providedin the
Diameter Answer of step 6. This value is the identity of the tar
get PCRF. The client populates the Destination-Host AVP with this
address and sends any subsequent Diameter messages directly to t
his PCRF bypassing the DRA (proxy).参考第7条描述，对于diameter消息，也就是图中PA2的
部分，如果填写了Destination-Host AVP，那么需要旁路DRA，直接路由到PCRF去综合以上情况，我们认为在STR消
息中，不填Destination-Host AVP才是比较合理的。四、中兴SBC Diameter会话路由原理ZTE ZXUN B
200 SBC Rx接口功能中，对Diameter 会话内消息的路由，按照Diameter消息中的Session-Id AVP来路
由，保证同一个Diameter会话走同样的路径。SBC对Diameter会话内消息不修改Destination-Host AVP或
者Destination-Realm AVP的值。ZTE SBC和其他厂商设备的IOT情况：中兴SBC和F5Network现网DR
A对接时，STR消息中无论是否带Destination-Host AVP都可以正确路由，信令截图如下：请求信令中不带Destina
tion-Host AVP 时：AAR消息：AAA消息：STR消息；STA消息：从以上信令分析，在会话初始不带Destinatio
n-Host AVP，那么在STR消息中也不带Destination-Host AVP。可见，F5 Network的DRA对该ST
R消息，可以正确路由，回应STA。请求信令中带Destination-Host AVP 时：AAA消息STR消息：STA消息：从以
上信令分析，在会话初始带有Destination-Host AVP，那么在STR消息中也会带Destination-Host AV
P。同样，F5 Network的DRA对该STR消息，可以正确路由，回应STA。经过信令对比分析，无论中兴SBC采用Rx接口是否携
带PCRF目的主机名，F5公司的DRA都能正确路由到PCRF，在协议上，Destination-Host AVP是个可选项，我们理
解这是符合设备兼容性的特性。综上，我们认为Destination-Host AVP在Diameter会话内消息中，完全是可选的。为
了互通兼容性，设备支持Diameter会话内消息带或者不带Destination-Host AVP才是合理的。华为分析如下：首先对
比一下“华为SBC－LDRA－华为PCRF”和“中兴SBC－LDRA－中兴PCRF”会话绑定场景里的消息，截图如下：（上图华为，下
图中兴）两个SBC发起的AAR消息里都不带目的主机名D-Host，这个是正常的。（上图华为，下图中兴）华为SBC发起的STR消息里
带了目的主机名，而中兴SBC则没有。可以认为AAR和STR虽同属Rx口的消息，但是可以根据实际情况带或不带目的主机名D-Host这
个AVP。按照下面Diameter协议描述：初始AAR消息因为不是发给某个特定服务器（PCRF），因此不需要带目的主机名D-Hos
t，但通话完成后的STR消息是发给特定服务器的，而且同一会话有了多次交互（STR之前的AAR/AAA），故STR这个请求消息需要通
过D-Realm和D-Host来送到指定的服务器。从中兴SBC发出的STR消息里带的信息来看，只有一个目的域名D-Realm，即便
做了Rx口的路由数据，也无法单根据一个域名路由到PCRF网元。该问题在后方已经发现已经在V2.00.81的最新补丁版本中解决。 【
解决方案】中兴SBC按照和集团网络技术部孟令希协商结果进行更改，除了Diameter初始会话AAR消息不带Destination-
Host AVP外，所有后续会话内请求消息都会携带Destination-Host AVP。现场11月13日修改完成后，测试验证通
过，问题解决。7.9：核心网侧未配置完整性保护和加密算法导致呼叫失败【问题现象】：eNB侧配置ZUC完整性保护（EIA3）和加密算
法（EEA3）后，尝试拨打电话，在QCI=1建立后，核心网回UE上下文释放命令，终端呼叫失败。【问题分析】：在eNB侧配置加密算法
和完整性保护算法后，终端起呼失败（确认终端支持ZUC算法）：eNB默认配置：【解决方案】：经排查因核心网侧未配置ZUC算法设置，从
而导致终端起呼失败，核心网侧设置该完整性和加密算法后，该呼叫失败问题解决。 7.10：中兴HSS返回UDA(LOC)的格式错误【问
题现象】：智能网测试发现被叫用户在CS域时，SCPAS向HSS发起用户位置信息查询时，HSS返回的格式存在问题。【问题分析】： H
SS返回的格式： nInformation>hBNoNwE= aId>ZPAA4wO+Cw== tring>kWgxRHKE r>kWgxRHKE ss>0 ved>2 ationInformation> 按照3GPP 29328-a90规范，在ShDataType_Rel10.
xsd中显示如下： rs="0"/> rs="0"/> element name="Address" type="tAddressString" maxOccurs="9"/> 按照理解
，结构应该为：kWgxBDAw本次故障主要原因
是协议错误导致的，协议的WORD文档和XSD文件针对XML编码方式定义不一致在39328-a90版本，VLRNumber的定义见下
：VLRNumbertISDNAddresstISDNAddressISDNAddressAddressStringtAddres
sString从协议定义看，下面的XML格式就是正确的 >kWgxRHKE而39328-C30版本，上
面这种格式通过提案“CP-130461”进行了修改CP-1304610477-tISDNAddresstISDNAddressSG
SNNumber, VLRNumber, MSCNumberAddresstAddressString1修改之后就应该是下面的格式
kWgxRHKE由于ZTE HSS是对齐修订之
前的协议，所以和对端网元对接时出现问题影响范围： 所有智能用户的增值业务【解决方案】：ZTE-HSS提供补丁，对齐最新修订后的协议
7.11：SBC收到UPDATE的200OK后没有转发【问题描述】：湖南移动现场短呼叫测试，发现测试20次，就会失败1次，失败原因
初步分析信令抓包发现是SBC未转发被叫终端发送给主叫的200 OK（update）消息造成失败，影响短呼叫的接通率。【问题分析】：
本次故障产生的技术原因分析如下：根据现场反馈的系统日志如下，已定位出故障原因。PE1:p_sip_proxy_dialog.c:2
888 Sip dynamic data add failed because mem left is not enough (m
em left=1472, mem asked=1473)。Update的200OK触发了Rx接口,Rx触发时申请异步动态数据区失
败，失败的具体原因是在计算数据区大小的时候没有考虑结束符\0，在临界值的时候就会申请数据区就会失败。目前异步动态数据区是分级的，固
定分为6k，7k，8k，16k四个级别。申请数据区的时候需要根据公式计算需要的数据区大小，但是由于在计算缓存SIP消息的长度时，没
有考虑到结束符\0。当SIP消息长度恰好是分级的临界值时，实际保存内容的长度要比申请的长度大1，会在保存数据区时造成内存越界，进而
导致响应处理失败，没有转发该响应。该问题在后方已经发现并在最新版本V2.13.10(T10a)中合入解决，湖南VoLTE测试使用的是V2.13.10(T7a)的版本，该故障并未合入这个版本，因此现场升级到V2.13.10(T10a)版本之后就可以解决这个问题。影响范围： 影响短呼叫的接通率【解决方案】：现场在6月8日将SBC版本升级到V2.13.10(T10a)，经过超200次的呼叫测试全部成功故障现象未复现。7.13：江苏漫游卡发起Ut业务失败【问题描述】：江苏漫游卡发起Ut业务， UT发起的MAR请求消息贝尔HSS认为缺少AVP SIP-Num-Auth-Item，返回5012错误。解决上述问题后南京AS UT服务器收到GET后响应409，业务仍然失败：HTTP/1.1 409 Conflict Server: gSOAP/2.8 Content-Type: application/xcap-el+xml; charset=utf-8 Content-Length: 751 Connection: close【问题分析】：1. HSS将SIP-Number-Auth-Items AVP视为必选 2. AS UT处理错误。影响范围： 影响江苏漫游用户Ut功能【解决方案】：1. 研究院确认HSS不应将将SIP-Number-Auth-Items AVP视为必选 2. 业务配置代理网关发送到AS Ut服务器HTTP GET请求消息，AS返回200 OK响应7.14：SIP over TCP被叫接续时延问题【问题描述】： 中兴SBC打开配置支持SIP over TCP功能后呼叫OK，但是被叫接入延时6s左右【问题分析】： SGW在转发release的时候，只转发给了cmnet PDN连接对应的PGW，导致ims PDN连接不知道用户idle了，导致报文到达时，PGW直接发给并被丢弃影响范围： 影响终端SIP over TCP被叫接入时长，影响用户体验，对主叫侧TCP建链没有影响【解决方案】：SGW需要将release转发给多PDN对应的PGW,修正版本已提供，升级解决7.15：湖南漫游卡在江苏作被叫回落CSFB【问题描述】： 湖南漫游卡在江苏作被叫回落CSFB，经过检查，在江苏做Attatch时候贝尔MME未携带state/location-information Retrieval特性【问题分析】： 贝尔MME不支持携带state/location-information Retrieval特性影响范围： 目前经过研究院确认，该问题目前影响漫游用户的智能网业务【解决方案】：需要贝尔进一步明确该功能实现方案，并制定相应实现方案和计划7.16：视频互通问题【问题描述】： 5月19日：ZTE&S5视频互通无图像，H264(视频包)丢包率高达90%7月14日：ZTE&S5、ZTE&高通MTP直接视频互通稳定性不佳，通过语音升级视频正常 直接拨打视频电话，互通失败概率高；概率性互通成功，但视频互通无图像。语音电话，升级为视频电话成功率100%，且有图像【问题分析】： 5月19日问题：ZTE&S5无图像，下行丢包率高 1）：eNB压缩RTP包时，未及时检测扩展头变化并告知UE，导致UE侧扩展头字段解错，进而CRC校验出错，导致大量丢包。 2）：eNB解压缩IPV6动态链扩展头字段时，多偏移一个字节，导致基站侧UDP报文CRC校验错。 3）：高通芯片在压缩同一时间点的视频包时，错将Time原值带为?（时间变量）值。7月14日问题：ZTE下S5、高通MTP视频问题 1）：三星S5主叫视频媒体包未发出，被叫侧媒体包正常发送并传输至主叫，但两侧均无图像；三星&中兴分析定位中 2）：高通MTP主、被叫双向媒体正常传输，但两侧均无图像；中兴、高通美国分析中 影响范围： 测试阶段，S5先拨打语音电话，后升级为视频电话； 影响中兴&三星测试线，基本视频互通测试及用户体验【解决方案】：5月19日问题：ZTE&S5下行丢包率高 1）：eNB补丁升级； 2）：高通4.0新版本已解决并验证7月14日问题：ZTE&S5、ZTE&高通MTP视频互通稳定性不佳 三星、高通、中兴端到端分析定位中 第43页 |
|
