LTEeSRVCC短板优化案例.docx
《LTEeSRVCC短板优化案例.docx》由会员分享，可在线阅读，更多相关《LTEeSRVCC短板优化案例.docx（22页珍藏版）》请在冰豆网上搜索。
LTEeSRVCC短板优化案例
概述
SRVCC（SingleRadioVoiceCallContinuity）是3GPP提出的一种VoLTE语音业务连续性方案，主要是为了解决当单射频UE在LTE/Pre-LTE网络和2GCS网络之间移动时，如何保证语音呼叫连续性的问题，即保证单射频UE在IMS控制的VoIP语音和CS域语音之间的平滑切换。
LTE网络建设初期，其覆盖范围有限，当用户在使用LTE网络进行语音通话过程中，移动到LTE信号较弱，但GERAN网络信号覆盖较好的区域时，为了保证语音呼叫连续性（VoiceCallContinuity，VCC），需要将话路由LTE切换到GERAN。
由于目前还没有能够在LTE和GERAN同时附着并收发数据的终端，因此LTE和2G之前的业务连续性都基于SingleRadio模式，即双模单待方式。
目前3GPP已经制定出双模单待方式的语音业务连续性方案，即3GPPTS23.216R9中提出的双模单待无线语音呼叫连续性（SingleRadioVoiceCallContinuity，SRVCC）方案。
1eSRVCC切换成功率指标介绍
eSRVCC切换成功率=切换至2G的切换成功次数（C373333312）/切换至2G的切换请求次数（C373333330）。
其中：
●切换至2G的切换成功次数：
源eNB接收到MME发送的“UE上下文释放”消息（UECONTEXTRELEASECOMMAND），指示系统间（EUTRAN->GERAN）分组域切换执行成功。
（3GPPTS36.413）
●
●切换至2G的切换请求次数：
源eNB向MME发送的“切换请求”消息（HANDOVERREQUIRED），HandoverTypeIE（LTEtoGERAN）指示系统间（EUTRAN->GERAN）分组域切换请求。
（3GPPTS36.413）
1.1eSRVCC指标统计信令节点
失败原因
对应计数器
失败原因描述
统计节点
LTE到GSM的切换出准备失败次数，等待切换响应定时器超时
C373333309
源eNodeB等HandoverCommand消息定时器超时
采样点4
LTE到GSM的切换出准备失败次数，目标侧准备失败
C373333310
源eNodeB接收到从MME来的HandoverPreparationfailures消息
采样点5
LTE到GSM的切换出准备失败次数，其它原因
C373333311
源eNodeB在切换准备阶段发生除上述2种原因外其它失败
采样点3
LTE到GSM的切换出执行失败次数，源侧发生重建立
C373333313
在切换执行阶段源eNodeB收到RRC连接重建立请求消息
采样点7
LTE到GSM的切换出执行失败次数，等待UECONTEXTRELEASE消息超时
C373333314
源eNodeB等待MME的UeContextRelease消息定时器超
采样点8
LTE到GSM的切换出执行失败次数，其他原因
C373333315
源eNodeB在切换执行阶段发生除上述原因外其它失败
采样点9
1.2eSRVCC失败原因分析
eSRVCC切换分为切换准备阶段和切换执行阶段：
切换准备阶段发生在HandoverRequired-->HandoverCommand，切换执行阶段发生在MobilityFromEUTRACommand-->UeContextRealeaseCommand。
切换准备阶段为eNodeB-->MME-->eMSC-->GSM基站之间的信令交互，和空口覆盖无关；切换执行阶段从采样节点来看只有MobilityFromEUTRACommand和LTE空口覆盖相关，当LTE下行覆盖较差（弱RSRP或弱RSRQ）时会增加UE接收MobilityFromEUTRACommand失败的概率从而造成eSRVCC失败，该原因造成的失败会统计到源eNodeB等待MME的UeContextRelease消息定时器超，其它的失败原因值和LTE覆盖、上行干扰、基站故障关系不大。
1.2.1LTE到GSM的切换出准备失败次数，目标侧准备失败
TS36.413协议规定如果EPC或是目标侧不接受任何一个承载或是在切换准备阶段发生错误，MME会回复“handoverPreparationfailure”消息，eNode收到handoverpreparationfailure消息后会统计到“目标侧准备失败”中。
造成目标侧准备失败的主要原因包括：
LTE侧GSM外部邻区参数配置、EPC参数配置错误、eMSC侧参数配置、GSM侧基站接纳失败、其它原因。
1.2.1.1GSM外部邻区参数核查
GSM外部邻区核查主要是和核查GSMCGI相关参数，在handoverrequire中主要依靠CGI参数来进行目标侧寻址，如果CGI参数配置错误会导致核心网/GSM侧认为发生错误从而导致切换准备失败。
CGI（CellGlobalIndentfier）全球小区识别=MCC+MNC+LAC+CI
需要重点核查：
1、核查“管理网元->无线参数->TD-LTE->邻接小区配置->GERAN邻接小区”中“邻接小区所在的移动国家码”、“邻接小区所在的移动网络码”参数配置是否正确
2、核查“管理网元->无线参数->TD-LTE->邻接小区配置->GERAN邻接小区”中的“位置区码”和"小区标识"的对应关系和GSM工参一致。
1.2.1.2eMSC侧参数核查
eMSC侧相关参数配置如下：
1、eMSC检查eSRVCC相关控制开关和参数配置
2、eMSC检查LAI和VMSC切换数据配置
1.2.1.3EPC侧参数核查
待补充。
。
。
1.2.1.4GSM侧参数核查
待补充。
。
。
1.2.1.5其它原因排查流程
切换准备涉及到LTE、核心网、GSM，在排查参数配置问题后可能需要核心网或GSM共同进行排查。
TS23.2166.2.2规定了eSRVCC相关的信令流程，我们在做问题排查时依据相关的信令节点做问题定位排查，排查步骤如下：
1、MME收到HandoverRequired后是否给eMSC发送了PStoCSReq，如果MME直接回复了HandoverPreparationFailure，可能由于核心网参数配置或是核心网处理异常导致切换失败导致，需要核心网协助进行排查
2、如果eMSC收到PStoCSReq之后回复的HandoverPreparationFailure，则需要GSM协助进行排查
1.2.2LTE到GSM的切换出准备失败次数，等待切换响应定时器超时
“管理网元->无线参数->TD-LTE->控制面定时器TDD”中“S1HO时等待HOCOMMAND的定时器（毫秒）”设置为10000ms（10s），在源侧发送HandoverRequired后再10s内未收到HandoverCommand命令造成eSRVCC切换失败。
造成定时器超时的原因主要有：
核心网/GSM侧参数配置错误导致核心网寻址错误；传输问题导致核心网/GSM侧未收到sRVCC相关信令；GSM基站故障未响应sRVCC切换命令。
1.2.2.1参数核查
1、LTE侧“管理网元->无线参数->TD-LTE->控制面定时器TDD->S1HO时等待HOCOMMAND的定时器（毫秒）”参数核查：
确定参数配置为10000ms
2、eMSC侧核查：
VMSC检查和eMSC之间切换数据、VMSC检查LAI&CI和BSC关联数据配置
1.2.2.2其它原因排查流程
1、MME是否收到HandoverRequied消息：
如果MME未收到HandoverRequired消息，核查eNodeB<-->MME之间的传输可靠性。
核查方法：
使用ems的“IP通道测试功能”检查eNodeB<-->MME通道是否丢包，如果存在丢包的情况协调传输解决传输问题
2、MME收到HandoverRequied后是否向eMSC进行了PstoCsReq消息转发，如果MME未进行消息转发，协调MME共同进行排查
3、eMSC是否收到PstoCsreq消息，如果未收到核查MME<-->eMSC之间的传输
4、eMSC收到PstoCsreq后是否回复了PstoCsRsp，如果未回复，协调GSM侧共同进行排查
5、eMSC回复PstoCsRsp后MME是否收到，如果未收到，核查MME<-->eMSC之间的传输
6、MME收到PstoCsRsp是否向eNodeB发送了HandoverCommand，如果未发送，协调MME共同进行排查
7、MME发送HandoverCommand后eNodeB是否收到，如果未收到，核查eNodeB<-->MME传输
1.2.3LTE到GSM的切换出准备失败次数，其它原因
切换出准备失败，其它原因是指未收到MME发送的HandoverpreparationFailure，S1HO时等待HOCOMMAND的定时器也未超时，其它未知原因造成的失败，失败的原因可能有：
eNodeB处理异常、MME/GSM处理异常
、MME/GSM处理异常：
类似于类似于在eNodeB发送HandoverRequired后，发起了UEContextReleaseRequest造成sRVCCC切换失败。
对于eNodeB处理异常的情况需要根据信令分析找出问题的根本原因。
MME处理异常举例说明：
类似于在eNodeB发送HandoverRequired后收到MME发送的UEContextReleaseCommand命令造成sRVCC切换准备失败。
对于MME处理异常的情况，根据信令分析情况联合核心网共同进行排查。
总之准备失败的其它原因比较复杂，需要详细分析信令后再做进一步处理。
1.2.4LTE到GSM的切换出执行失败次数，源侧发生重建立
在切换执行过程中源侧收到UE的rrcconnectionreestablishmentrequest消息，源侧发起handovercancel造成切换失败。
在eSRVCC切换执行阶段造成UE重建立的原因包括：
无线链路失败、Mobilityfromeutra失败。
1.2.4.1无线链路失败
无线链路失败主要是由于LTE覆盖较差造成UE上行/下行失步，造成失步的原因主要是弱RSRQ、弱RSRQ、上行干扰、基站功率相关告警、测量时间过长造成切换延迟、切换准备阶段handoverrequire-->handovercommad时延比较大造成切换延迟。
目前版本sRVCC时参数默认配置为B2（LTE）:
-115dBm/B2（GSM）:
-95dBm，当下行干扰（mode3干扰、或重叠覆盖较高时），UE下行失步的概率较高，对于下行干扰严重区域，建议提高B2（LTE）门限降低下行失步的概率。
参数配置路径
参数名称
默认值
管理网元->无线参数->TD-LTE->测量参数配置->UE系统间测量参数
测量配置号1012：
语音B2RSRP门限
B2（LTE）:
-115dBm/B2（GSM）:
-95dBm
上行干扰会造成上行失步UE进行重建，建议：
（1）干扰排查
（2）对于上行干扰站点可以尝试调整功控方式“闭环”-->"开环",同时修改P0_Nominal为"-87"->"-75"
基站功率相关告警包括：
驻波告警、功率异常、RRU故障等告警
测量时间长短和“测量参数->GERAN载频测量配置”相关，配置的冗余频点过多会增加UE检测时间，造成切换延迟，建议对GERAN载频进行精细优化
切换准备阶段时延过大造成切换延迟，优化建议：
（1）核查切换时延大原因，进行时延优化
（2）提高B2（LTE）门限使切换提前
1.2.4.2Mobilityfromeutra失败
Mobiltyfromeutracommand失败原因包括：
（1）T304超时
（2）在2G未能进行成功接入（3）UE和Mobiltyfromeutracommand消息中部分内容不匹配
Mobiltyfromeutracommand失败超时主要和邻区配置、GSM覆盖相关、特定UE、GSM侧未知故障等因素相关。
邻区配置异常包括邻区漏配、邻区频点漏配、配置超远邻区。
邻区漏配需要精细化的邻区优化来完成。
邻区频点漏配是指“管理网元->无线参数->TD-LTE->邻接小区配置->GERAN邻接小区->BCCH载波的ARFCN”在“测量参数->GERAN载频测量配置”未配置造成部分邻区UE不测量从而影响eSRVCC切换成功率。
优化建议核查“测量参数->GERAN载频测量配置”要包含所有“GERAN邻接小区->BCCH载波的ARFCN”。
GSM覆盖：
目标侧GSM信号质量差会造成GSM接入失败，目前版本默认B2（GSM）:
-95dBm，对于重建立失败较高的TOP小区适当提高B2（GSM）门限以保障在GSM侧能够正常接入。
参数配置路径
参数名称
默认值
管理网元->无线参数->TD-LTE->测量参数配置->UE系统间测量参数
测量配置号1012：
语音B2RSRP门限
B2（LTE）:
-115dBm/B2（GSM）:
-95dBm
特定终端影响主要是指某个或某款终端在GSM侧接入异常导致。
确定是否是某个终端导致切换异常可以通过
（1）netmax切换智能分析可以基于“IMSI的汇总”来分析
（2）通过汇总M-TMSI来进行分析；确定是否是某款终端导致同一通过“FGI（FeatureGroupID）”汇总进行分析
图21NetmaxIMSI汇总
图22M-TMSI信息查询
图23FGI信息查询
GSM侧未知故障造成UE在GSM接入异常，该问题需要跟踪GSM、LTE侧信令共同进行分析。
1.2.5等待UECONTEXTRELEASE消息超时
“S1源侧切换成功后等待MME释放定时器（毫秒）”配置为15s，eNodeB下发Mobilityformeutracommand”后15s内未收到MME的Uecontextreleasecommand，eNodeB会记录一次eSRVCC切换失败。
造成超时的原因可能有：
MME版本问题、传输问题、其它未知问题。
MME版本问题：
在R11之前的协议中未明确规定在eSRVCC切换完成后必须下发Uecontextreleasecommand。
UE在sRVCC成功切换到GSM后，某些厂家的MME不下发Uecontextreleasecommand从而造成等待UECONTEXTRELEASE消息。
该问题优化建议：
（1）MME版本升级
（2）升级602版本后会对这部分进行TY，可以对这部分失败不做统计。
传输问题由于传输丢包造成Uecontextreleasecommand未收到，该问题建议进行传输可靠性核查。
其它未知问题分析：
端到端信令进行分析。
1.2.6LTE到GSM的切换出执行失败次数，其他原因
当eNodeB收到MME的Uecontextreleasecommand时，只有当里面携带的原因值为successful_handover才认为是sRVCC切换成功，所有其它携带的原因值都认为是执行失败
造成命令携带其它原因值的原因有：
中兴MME版本、其它原因
1.2.6.1中兴MME版本问题
中兴MME在R11之前的版本中eSRVCC切换完成后，核心网下发UECONTEXTREALEASECOMMAND，携带的原因值为TS1AP_CauseNAS_Root_normal_release。
根据TS36.4139.2.1.3，当切换成功导致的上下文释放，携带的原因值应该为HandoverSuccess而不是NormalRelease。
网管目前统计eNBeSRVCC切换执行成功也是统计源eNB接收到MME发送的“UE上下文释放”消息（UECONTEXTRELEASECOMMAND），释放原因是“handoversuccess”。
目前MMEV4.10.18已经取得入网证并在全网进行升级，对于未升级的区域建议尽快进行MME版本升级。
1.2.6.2其它原因
详见附录A，释放原因说明。
需要根据UECONTEXTRELEASECOMMAND携带的原因值再进行进一步的定位。
在P02版本中计划对其它原因造成的失败进行TY，按照原因值分为4个开关：
NormalRelease、ReleaseduetoE-UTRANGeneratedReason、FailureintheRadioInterfaceProcedure、其它所有原因，4个开关可以通关B类参数进行控制，可以根据优化需求有选择性的关闭其中某个或全部失败原因值的统计。
附录A释放原因说明（TS36.4139.2.1.3）
IE/GroupName
Presence
Range
IETypeandReference
SemanticsDescription
CHOICECauseGroup
M
>RadioNetworkLayer
>>RadioNetworkLayerCause
M
ENUMERATED
（Unspecified,
TX2RELOCOverallExpiry,
SuccessfulHandover,
ReleaseduetoE-UTRANGeneratedReason,
HandoverCancelled,PartialHandover,HandoverFailureInTargetEPC/eNBOrTargetSystem,
HandoverTargetnotallowed,
TS1RELOCoverallExpiry,
TS1RELOCprepExpiry,
Cellnotavailable,
UnknownTargetID,
NoRadioResourcesAvailableinTargetCell,UnknownoralreadyallocatedMMEUES1APID,
UnknownoralreadyallocatedeNBUES1APID,
UnknownorinconsistentpairofUES1APID,Handoverdesirableforradioreasons,
Timecriticalhandover,
Resourceoptimisationhandover,
Reduceloadinservingcell,Userinactivity,
RadioConnectionWithUELost,LoadBalancingTAURequired,CSFallbackTriggered,
UENotAvailableForPSService,Radioresourcesnotavailable,
FailureintheRadioInterfaceProcedure,
InvalidQoScombination,Inter-RATredirection,
Interactionwithotherprocedure,UnknownE-RABID,MultipleE-RABIDinstances,Encryptionand/orintegrityprotectionalgorithmsnotsupported,S1intrasystemHandovertriggered,S1intersystemHandovertriggered,X2Handovertriggered
…,
Redirectiontowards1xRTT,
NotsupportedQCIvalue,
invalidCSGId）
>TransportLayer
>>TransportLayerCause
M
ENUMERATED
（TransportResourceUnavailable,
Unspecified,
…）
>NAS
>>NASCause
M
ENUMERATED（NormalRelease,
Authenticationfailure,
Detach,
Unspecified,
…,
CSGSubscriptionExpiry）
>Protocol
>>ProtocolCause
M
ENUMERATED
（TransferSyntaxError,
AbstractSyntaxError（Reject）,
AbstractSyntaxError（IgnoreandNotify）,
MessagenotCompatiblewithReceiverState,
SemanticError,
AbstractSyntaxError（FalselyConstructedMessage）,Unspecified,…）
>Misc
>>MiscellaneousCause
M
ENUMERATED
（ControlProcessingOverload,NotenoughUserPlaneProcessingResources,
HardwareFailure,
O&MIntervention,
Unspecified,UnknownPLMN,…）
Themeaningofthedifferentcausevaluesisdescribedinthefollowingtable.Ingeneral,“notsupported”causevaluesindicatethattherelatedcapabilityismissing.Ontheotherhand,“notavailable”causevaluesindicatethattherelatedcapabilityispresent,butinsufficientresourceswereavailabletoperformtherequestedaction.
RadioNetworkLayercause
Meaning
Unspecified
Sentforradionetworklayercausewhennoneofthespecifiedcausevaluesapplies.
TX2RELOCOverallExpiry
ThetimerguardingthehandoverthattakesplaceoverX2hasabnormallyexpired.
SuccessfulHandover
Successfulhandover.
Releasedueto
升级会员 