|
某局某个站点无法进行VoLTE呼叫，主要表现为手机无VoLTE标志，导致无法进行VoLTE呼叫。
测试UE在其他基站可以正常进行VoLTE呼叫，基本可以排除测试UE的问题。并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。由于之前一直未查出原因，现场还进行数据重新制作，也未能解决。
由于UE没有VoLTE标识，基本可以确认IMS注册应该没有成功，排查的思路如下：
首先确认终端设置是否正确。排查是否是终端设置问题，导致未发起注册。 通过eNB或EPC上跟踪信令，确认终端和网络是否支持VoLTE。 ●若终端不支持VoLTE，则无法发起注册。 ●若网络不支持VoLTE，不支持IMS注册，则网络下发的Attach Accept中IMSVoPS不为IMS。VoPS Session in S1 Mode supported，网络将不支持VoLTE。 排查QCI5承载是否建立成功，SIP注册消息是否成功发送且对方正确接收。 核查HSS中2G/3G/4G签约数据，确认是否签约IPv6 APN 。 确认IMS签约数据（将USIM卡装载在其他可以正常使用的手机中进行测试，确认USIM卡签约是否正常）。排查是否是IMS签约数据问题，导致无法注册。 如果上述方法还无法定位问题，在eNB、IMS和EPC、DRA、PCRF等网元跟踪数据包，检查终端是否已经发出Register消息，消息已经到哪个网元，终端是否已经注册多次，排查例如：异厂家对接，导致注册消息未发送到SBC。 最后在终端上抓取信令，确认终端问题。例如终端版本问题导致注册慢，升级版本后可以解决。
由于UE在其他站点正常，A、B、D、E都可以排除。 通过参考下图信令，显示QCI=5的承载正常激活，也可以排除C。 
G也可以排除，因为只是在某个站点出现，和UE无关系。 所以关键是针对F项进行排除。另外从逻辑结构看， MME、XGW和IMS对整个网络是统一的，理论上不应该存在差异，最有可能遇到的是基站问题或基站到核心网的传输问题。计划在基站和UE进行传输抓包和UE log的采集，并在IMS抓起SIP信令来排查相关的问题。
通过解析UE的SIP信令发现，在UE上发送了第一次register以后，可以收到401信令答复，并且UE也发送了第二次register信令，但是无法获取到200 ok的应答，导致IMS注册失败。UE的register信令流程如下图所示。 
通过核心网同事在IMS抓的信令发现，IMS发送了401应答以后，并未收到第二次的register请求，导致注册失败。由于无法确定第二次的register请求在哪里丢失了，只能进行基站用户面的数据抓包，确认基站是否收到了相关的信令。 
通过wireshark数据显示，在UE收到401以后，立刻发送了数据包给IMS，但是该数据包非常小，只有58个字节，如上图所示，不太可能是第二次regiseter信令，而且是加密的。但是通过去掉目标IP的筛选，查看到在该包附近有一个数据包的分片如下图所示。 
通过查看该包的ID，其实它和那条发到IMS的IP地址的数据报文是一个数据包，如下图所示，只是被分片了。 
通过查看两个报文的长度发现，第一个报文长度是1514（属于大报文传输），而查看那些正常的数据包基本都是在1454的大小。怀疑传输是否对大包传输的支持有问题。再通过在基站进行ping 1500的包，也出现了同样的情况，如下图所示。 
反馈相关的问题给传输工程师，传输反馈： 基站接的一个PTN设备上所有接口都不能ping大包，是因为其中一段中间链路走的是租用链路。中兴设备上都开了大包，基本上可以定位为运营商租用链路没开大包的功能。通过和运营商沟通，运营商推动租用的传输可以ping大包，如下图所示。 
上站测试， UE在该站点的VoLTE注册正常。
在由于VoLTE的业务基本是基于IP层传输的业务，使得传输问题将影响到VoLTE业务。比如本案例中的大包传输未开启，导致第二条IMS的register信令无法传输，导致VoLTE注册失败。
|
