LTE SEQ分析案例非常实用

SEQ分析VOLTE实战操作指导书

一、SEQ平台简介

1、SEQ客户感知管理系统

2、以客户感知为中心

3、SEQ—采集接口介绍

二、SEQ平台登录说明

必须通过4A管理平台登录，且1个4A账号下只能同时登录1个SEQ账号，

但不同4A账号可以登录同一个SEQ账号（一旦点击SEQ时提示“Firfox已运行”，那就绪要重新换4A账号才能登录）。

SEQ保存文件目录设置

每个4A账号的下载目录都不一样，需要自己设置到自己想要的目录。

三、SEQ分析VOLTE主要功能介绍

1、单据查询功能介绍

CS综合单据可查询用户通话记录以及初步定位未接通或掉话原因。

PS单据可快速查询了解用户占用4G基站以及用户终端类型

投诉处理快速查询终端问题类型

四、SEQ分析VOLTE案例

4.1 SEQ分析用户投诉：20160224凌晨15196682002连续注册失败问题

问题号码：15196682002 问题终端型号：A1586 (IPHONE 6)

问题描述：苹果6 VOLTE用户凌晨连续6次注册失败，I –CSCF反馈401 （UA用户未授权），后续SBC反馈500（服务器内部错误）,需核心网工程师协助分析。 苹果6用户重注册和初始注册连续失败

注册失败I –CSCF反馈401 （UA用户未授权）

核查空口被叫在12:18:24.003占用中海国际F-SCDHLD3HM2GX-F1（PCI：257 RSRP=-78dBm SINR=7)收到INVITE-Request，回复183消息后在12:18:24.206同时发起切换和专载建立,12:18:24.315占用皇冠国际酒店F-SCDHLD3HM2GX-F2（PCI：301 RSRP=-79dBm SINR=3)同时终端上发承载建立确认和系统下发去激活专载。

问题结论

终端建立专载成功的信令到达MME之前系统触切换，由于这时MME状态仍然认为终端没有QCI1的承载，导致切换命令下发给eNodeB时，不包含QCI1,导致切换后QCI1被MME释放。

4.5 SEQ结合ATU分析异常事件：模3干扰导致RRC重建

问题描述

被叫在09：20：43.531收到INVITE REQUEST，09：20：44.750发送INVITE 200 OK主被叫接通，通话8秒09：20：52占用高新南凯德世纪名邸-SCDHLS3HM2GX-D1（RSRP:-91dBm SINR:-12dB) SINR差无线链路失效RRC重建网络拒绝后，占用天府一街西-SCDHLS3HM2GX-F3进行RRC连接建立后异常RRC释放，统计为被叫掉话。

问题分析

终端占用高新南凯德世纪名邸-SCDHLS3HM2GX-D1(PCI:270)上报天府一街西段-SCDHLS1HM1GX-D3(PCI:165) A3事件，未切换SINR差。

SEQ信令MME回复ENB间切换PATH请求，说明终端占用高新南凯德世纪名邸-SCDHLS3HM2GX-D1(PCI:270)和天府一街西段-SCDHLS1HM1GX-D3(PCI:165)模3 ，导致终端未收到RRC切换重配信令

问题结论

1、高新南凯德世纪名邸-SCDHLS3HM2GX-D1(PCI:270)和天府一街西段-SCDHLS1HM1GX-D3(PCI:165)模3干扰导致SINR未收到切换重配置

2、调整建议：高新南凯德世纪名邸-SCDHLS3HM2GX-D1(PCI:270)和高新南凯德世纪名邸-SCDHLS3HM2GX-D2(PCI:272)互换。

五、SIP消息标准协议原因值

序号 状态码 消息功能 表示已经接收到请求消息，正在对其进行处理，一次呼叫中 临时响应 临时响应可以有多个。 100 表示请求消息已收到，可以防止对局请求超时重传。 180 振铃 181 呼叫正在前转。在IMS中主要用于前转业务。 182 排队 1XX 2XX 3XX 4XX 5XX 183 呼叫处理中 成功响应 表示请求已经被成功接受、处理。 200 OK Accepted，指示订阅请求已被初步接受，但还需等到最终决策， 202 最终决策将在NOTIFY请求中给出。进一步信息请参考RFC 3265。 重定向响应 表示需要采取进一步动作，以完成该请求。 300 多重选择 301 永久迁移 302 临时迁移 303 其它 305 使用代理 380 代换服务 表示请求消息中包含语法错误或者 客户端错误 SIP服务器不能完成对该请求消息的处理。 400 错误请求 401 无权 402 要求付款 403 禁止 404 没有发现 405 不允许的方法 406 不接受 407 要求代理权 408 请求超时 410 消失 413 请求实体太大 414 请求URI太大 415 不支持的媒体类型 416 不支持的URI方案 420 分机无人接听 421 要求转机 423 间隔太短 480 暂时无人接听 481 呼叫腿/事务不存在 482 相环探测 483 跳频太高 484 地址不完整 485 不清楚 486 线路忙 487 终止请求 488 此处不接受 491 代处理请求 493 难以辨认 服务端错误 表示SIP服务器故障不能完成对正确消息的处理。 500 内部服务器错误 501 没实现的 502 无效网关 503 不提供此服务 504 505 513 580 全局故障 服务器超时 SIP版本不支持 消息太长 资源预留失败 表示请求不能在任何SIP服务器上实现。 600 全忙 603 用户拒绝 604 都不存在 6XX 606 不接受

六、VOLTE完整SIP信令

6.1 VOLTE最完整呼叫信令(含MS1和MS2)

6.2 VOLTE_ESRVCC完整呼叫信令

基于信令平台的eSRVCC切换优化指导手册

3）测试场景3：省内测试卡，到外省（安徽/上海）后开关机或飞行模式，注册到外省IMS；在外省直接发起VOLTE呼叫，接通后回当地（南京/苏州），切换到当地的LTE小区，然后向当地GSM进行esrvcc切换，结论：爱立信MME和华为下失败。

爱立信及华为MME都失败，流程如下：

满足A2/B2门限，但未能成功切换，随后转空闲。

4）具体原因分析及结论

1）省际边界VOLTE的esrvcc问题，华为在3月31号已开启TOP ON功能，爱立信需要升级解决； 2）爱立信在空闲态以及数据连接态情况情况下切换GSM失败，出现原因为unspecied的失败；主要原因为上海用户漫入到江苏，或江苏用户漫游到上海，并在上海SBC发生过注册后回到江苏。用户进入江苏后未发生重新注册刷新为江苏STNSR，此时发生了ESRVCC切换。因为用户仍然注册在外省的SBC上，MME发给EMSC的PS TO CS REQ消息中STNSR仍为上海的SBC/ATCF。江苏的EMSC只与本省SBC连接，所以切换请求无法送往上海的BSC，切换失败，给MME发送的PS TO CS RSP原因值为Unspecified。 确认需要爱立信MME升级 ；16A，目前在FOA；

3）华为的TOPON 功能及爱立信的补丁适用于：

漫游的情况下，PGW重选的模式是承载模式，也就是满足以下两个情况下会发生PGW重选：

1.专有承载删除时，判断如果没有QCI=1/2的承载，触发。 2. TAU结束时，判断如果没有QCI=1/2的承载，触发。

4）在VOLTE通话中，根据集团规范需要VOLTE通话结束后才可进行PDN重选，所以目前无法解决。

4、失败原因值为Failure in Radio Interface Procedure问题分析，切换后RRC 重建导致。应是中兴设备特有，与原因值2handover cancel为一类原因。 4.1、SEQ统计及信令截图

? 涉及地市：徐州、连云港；

? 涉及厂家：中兴；中兴版本升级为602后问题较多；通常为切换后RRC 重建引起。目前中兴正在排查具

体原因。

? 分析：从SEQ平台来看均是由于MME给MSC发起HO CANCEL导致，5月25日中兴选取了部分小区进行复

测，目前发现是由于弱覆盖导致UE存在下行失步，失步后发起RRC重建立，导致ESRVCC失败。

?复现关于Failure in Radio Interface原因的esrvcc失败问题，排查该问题出现的具体原因。

4.2. 问题复现--测试背景和测试小区配置

根据核心网统计发现徐州的eSRVCC切换失败原因为Failure in Radio Interface，流程分析发现目标侧发送cancel消息导致。

测试小区配置

参数名称 测试值 小区 打开系统间测量(语音业务) (A2)（dbm） -100 LTE市区民生医院_1 LTE向GERAN切换的B2 (LTE)门限（dbm） -120 LTE向GERAN切换的B2 (GSM)门限（dbm） -100 4.3. 问题复现---测试数据分析

经过后台指标统计，该时段内共发起30次esrvcc切换请求，切换成功19次，源侧发生重建立导致esrvcc切换失败11次，后台指标详见下表：

LTE到LTE到开始时间 结束时间 eSRVCC切换成功率 GSM的切换出准备请求次数 LTE到GSM的切换出执行成功次数 LTE到GSM的切换出准备成功次数 GSM的切换出执行失败次数，源侧发生重建立 9:45 10:15 63.33% 30 19 30 11

经过前台信令点统计，9点45分至10点15分，前台共出现11次次失败，失败时间点如下表所示：

4.4、问题复现---前台空口信令如下：

且11次esrvcc切换失败均是UE侧接收到基站侧发送的Handover Command后1秒左右UE主动发起RRC

重建请求，最终导致esrvcc切换失败。RRC重建结果有2种： RRC重建失败、RRC重建完成。

UE侧接收到基站侧发送的Handover Command后1秒左右UE主动发起RRC重建请求，RRC重建请求原因为ReestablishmentCause = 1 (handoverFailure)；

通过查看RRC重建请求消息，发现RRC重建的原因有2种，第一种是： handover Failure；第二种是： otherFailure

4.5问题复现---后台基站及核心侧信令如下：

1）基站侧跟踪 基站在接收到UE发送的MR报告时向MME发送Handover Required消息，在大概2秒后接收到MME发送的Handover Command消息，在接收到Handover Command时基站向UE发送mobility From EUTRA Command消息，让UE执行eSRVCC切换，但在1秒后接收到UE发送的RRC Connection Reestablishment Request，同时基站侧发起handover cancel造成切换失败。

2）核心网数据分析 根据前台反馈的失败问题时间点，核心网处进行分析发现切换发起之后，很快会取消切换。但是切换取消之后有重建reinvite。之后也会再发生切换/切换取消；呼叫没有掉话，有正常拆线。且每次都在切换SRVCC PS TO CS

REQUEST/RSPONSE之后收到MME发来的SRVCC PS TO CS CANCEL；原因值为：Failure in Radio Interface Procedure (8) 。

从消息看，每次都在切换SRVCC PS TO CS REQUEST/RSPONSE之后收到MME发来的SRVCC PS TO CS CANCEL；原因值为：Failure in Radio Interface Procedure (8) LAIGCI=4600050360882

本文来源：https://www.bwwdw.com/article/sfd7.html