1、ATU-plyer(MOS关注点)
2、定时器超时转SCFB 2.1、两个终端定时器
这两个定时器均为终端内部设置，协议规定，Tcall和Tqos定时器，大家记一下，超时后终端转CSFB。 定时器名称 Tcall Tqos 主叫终端发送INVITE消息 收到100 trying 10s 启动条件 停止条件 默认值 主叫/被叫收到/发送183 session 收到专有QCI1的承载建立消息（Activate 6s progress dedicated EPS bearer context request）
2.2、CS retry问题分析和归类
2.2.1、原理：当VoLTE用户作为被叫用户时，且呼叫被域选到IMS域后，由于被叫终端不在IMS域内导致该呼叫不能在IMS域被接续，SCC-AS支持尝试从CS域进行接续。 2.2.2、问题分析 ?
无线影响（维护、建设、优化、规划）：终端不响应寻呼（质差收不到寻呼，响应后基站无法收到），目前AS cs retry定时器设置长度为11s；超时后AS即选择从CS域寻呼。
? ?
设备原因：SEQ看到paging下发，终端不响应1、2、3次寻呼。
核心网原因： 无线无弱覆盖和质差并响应寻呼，或SEQ看到终端响应，IMS内部出错等。
大家遇到此类问题，及时备份SEQ单据，确认是否为无线以及设备原因导致。 2.2.3、典型问题：
11s后，AS未收到响应，发cancel
转MGCF
3、信令查看LTE小区发射功率：
在信令侧找到System Information，双击打开找到pdsch-ConfigCommon下面的referenceSignalPower：18 18表示对应的小区发射功率
4、MOS大于3.0分，丢包、抖动、延时判断门限： 丢包率：1% ，大于1%mos急降
抖动时延：小于90msVOLTE比较好，大于90ms就是坏点（每次数据包之间传输不一致，就叫抖动时延）； 时延：250ms（数据包在发生与接收之间的传输时间）； MOS打的点为前8秒的通话判定结果 5、RRC重建 RRC重建的原因：
切换失败；2、无线链路失败；3、完成性保护失败；4、RRC重配置失败；5、E-UTRA侧移动性失败 在RRC重建初始化阶段，UE会执行如下操作：
●停止定时器T310，如果正在运行； ●开始定时器T311； ●挂起除SRB0之外的所有RB； ●复位MAC；
●应用缺省的物理信道配置； ●应用缺省的半持久调度配置； ●应用缺省的MAC主配置；
●释放reportProximityConfig并情况所有邻近状态报告相关的定时器； ●进行小区选择；
当选择一个合适的E-UTRA小区后，意味着RRC重建初始化完成，此时，UE 将执行如下操作： ●停止定时器T311； ●开始定时器T301；
●采用SystemInformationBlockType2中包含的timeAlignmentTimerCommon。 ●初始化RRCConnectionReestablishmentRequest消息的发送； 注：该过程同样适用于如果UE返回源小区的情况
注：在定时器T311运行过程中，UE选择了一个不同RAT的小区时，UE 将离开RRC_CONNECTED状态，同时‘RRC连接失败’。 6、二次寻呼判定：
被叫收到paging在2秒内认为是一次寻呼，超过2秒是二次寻呼(2次寻呼的原因（1、被叫重选；2、无线环境差），三次寻呼10秒； 7、时延分析
A、 核查掉线、重传-------无线环境影响很大
B、 在无线环境良好的情况下核查主被叫在这个过程中是否发生了TAU、切换、重建；被叫核查寻呼paging（空闲态） C、 终端回复时间长初步定为终端问题，网络侧下发时间长初步定为网络侧问题。 D、 核查服务小区的Enodb寻呼进出次数。
相关推荐：
loading