Iur-g切换失败流程排查
切换失败原因分析
切换失败原因分析1、软切换失败原因根据信令流程，导致切换失败的情形有以下几种1）、ASU消息过多问题切换参数不合理的导致乒乓切换例如切换参数reporting range 1A和reporting range 1B的差别很小，那么小区刚进入AS 又马上移出AS；如果Hysteresis 1C设置太小，那么一个刚被替换进AS的小区又马上移出AS。
导频污染UE不断上报测量消息，RNC不断下发ASU消息，容易导致切换失败。
2）、软切换优化注意问题控制软切换比例网络建设初期，容量不受限制，以提升覆盖为目标。
软切换比例可容许在40%甚至更高。
这样可以保证上行良好覆盖并且可以减少掉话，由于软切换带来分集增益，从而降低了UE发射功率。
当网络不断发展，由于容量问题凸现，由于软切换带来上下行系统硬件开销以及消耗下行码资源。
综合考虑容量和覆盖问题，将软切换控制在一个合理的比例，通常为30-40%。
保证软切换成功率和低掉话绝对值以合理的网络规划和合理的软切换参数为前提，保证切换的及时性。
减少乒乓切换减少乒乓切换，以减少信令交互和资源消耗，从而降低掉话率。
乒乓切换调整有几个方面，控制导频污染，通过切换参数克服。
例如调整1A和1B的迟滞，增大Time to trigger 参数。
根据不同的场景设置不同的小区参数。
2、ISHO失败原因上行链路质量差事件2D门限（CM START）设置不合理时间3A参数（ISHO）设置不合理当前W小区漏配GSM邻区当前W小区配置GSM邻区过多目标GSM小区无可用无线资源当前ISHO优化主要针对W覆盖边界与GSM覆盖区的优化。
若W边界GSM小区覆盖较好，则有利于向GSM切换。
若GSM信号强度不够，则增大了异系统测量失败或者信令交互失败的可能，从而导致掉话。
所以W覆盖内部应尽量达到信号的连续覆盖，减少弱覆盖和盲区。
使得ISHO发生在W覆盖区域的边缘，减少ISHO的次数。
另外W系统间切换应尽量选择在人口密度小的区域，减少切换次数，也避免了因处理能力不足而使信令交互延时或失败，最终导致掉话。
路测切换失败的原因分析及解决
目录第一章前言..................................... 错误!未定义书签。
第二章切换流程分析............................. 错误!未定义书签。
一、小区内部切换（INTRA _CELL HANDOVER）.... 错误!未定义书签。
二、BSC内部小区间切换（INTRA_BSC HANDOVER）.错误!未定义书签。
三、MSC内部BSC间切换（INTRA MSC HANDOVER）.错误!未定义书签。
四、 MSC间切换.............................. 错误!未定义书签。
第三章切换失败的原因分析....................... 错误!未定义书签。
!未定义书签。
!未定义书签。
!未定义书签。
!未定义书签。
注: LAPD和LAPDm中使用的帧类型以及它们的结构错误!未定义书签。
二、单独出现的切换失败...................... 错误!未定义书签。
1）连续多个下行Physical Information，超过系统设置造成失败.错误!未定义书签。
.................... 错误!未定义书签。
2）无下行physical information........... 错误!未定义书签。
A．同站不同小区之间将Synchronized Indicator置为True错误!未定义书签。
注：设置小区同步切换对切换流程的影响. 错误!未定义书签。
B．小区之间将Synchronized Indicator置为False错误!未定义书签。
3）三层消息中出现HO_Complete后手机再上行发送HO_Failure消息....................................... 错误!未定义书签。
4）其它可能出现的切换失败现象............ 错误!未定义书签。
A．超过目标小区的最大服务距离，Cause: “handoverimpossible, timing advance out of range”错误!未定义书签。
无线网络规划-切换失败原因及优化方法
UE侧信令
eNodeB信令
3．切换命令丢失分析
切换命令丢失是指UE侧发出测量报告后，eNodeB收到测量报告，并下发 切换命令，但UE侧没有收到；从UE侧看到的现象与测量报告丢失相同，但在 eNodeB侧可以看到eNodeB下发了RRC重配置消息，UE侧未响应。
切换命令丢失
4．目标小区接入失败分析：参数问题
是
切换门限等修改
终端异常产生的切换失败
时钟问题
是 检查同步、GPS状态等
不属于网络原因造成，而且容易
目标小区拥塞 是
小区扩容
判断，因此在切换问题分析过程 将终端问题产生的切换失败排除 在外。
干扰 覆盖问题
其他
是
处理外部干扰或者无线 环境优化
是
进行天线、功率调整或 者新增基站等
2．测量报告丢失分析
在LTE切换过程中，UE会根据eNodeB下发的测量控制完成相应的测量内容， 并将测量结果上报给eNodeB，但在UE上报测量报告后，并不代表eNodeB就一定 收到或者eNodeB一定会处理，那么这必将产生切换失败。UE不断地上报测量报 告，但在eNodeB并未收到相应的内容，最终导致链路释放。
任务5 切换问题分析
切换失败原因及优化方法
LTE切换失败的原因及优化方法
LTE切换异常主要分为：终端异常、测量报告丢失、切换命令丢失、目 标小区接入失败四种情况。
1．终端异常 在测试过程中，由于终端长时间工作产生过热或者APP过程内存不足都 可能导致终端死机、不影响相应动作等情况发生。在测试过程中表现为一段 时间终端不接收、不发送信令，接收电平强度、电平质量无变化。这种情况 较明显，容易判断，且不属于网络问题，一般重启终端即可恢复，不需要特 别分析。
切换失败分析方法和案例介绍
TypeUnitOrDepartmentHereTypeYourNameHere TypeDateHere切换日常优化检查项目&切换失败分析和案例介绍 NOKIA Tiger Team2007-3-27TypeUnitOrDepartmentHereTypeYourNameHere TypeDateHere目录1. 前言 (3)2. 切换参数及日常检查项目 (3)2.1 参数规范性检查 (3)2.2 单向切换关系检查 (7)2.3 邻区关系过多的小区检查 (13)2.4 同频同色码复用距离检查 (14)2.5 切换目标错误检查 (15)2.6 TRX参数之TSC检查 (16)2.7 邻小区同频同色码检查 (17)2.8 同站DCS1800与GSM900未加切换关系的检查 (18)2.9 同频切换关系的检查 (19)2.10 长期无切换次数的切换关系清理 (20)2.11 经纬度错误的检查 (20)2.12 定义过远的切换关系检查 (20)2.13 切换关系垃圾数据检查 (21)3. 切换失败分析的方法和思路 (21)3.1 切换类话务统计分析和处理总体原则 (21)3.2 案例分析 (24)3.2.1 (900)火星报业1 CI=50151切换失败分析 (24)3.2.2 (900)袁家岭友谊1CI=50071切入失败高 (27)3.2.3 (900)三胞大厦3 CI=10793切换失败分析 (27)3.2.4 (900)黄花回龙切入失败分析 (30)3.2.5 (900)青竹湖切换失败分析 (31)3.2.6 (1800)留芳宾馆18002 CI=18442切入失败分析 (33)3.2.7 (900)商务学院1CI=16441切换失败分析 (34)TypeUnitOrDepartmentHereTypeYourNameHere TypeDateHere1.前言切换参数是网络优化工作中涉及最多的参数之一；而切换失败是我们最常见的网络问题之一。
经典案例_异系统切换失败导致Volte掉话排查案例
异系统切换失败导致Volte掉话排查案例目录一、问题描述 (3)二、分析过程 (3)三、解决措施 (6)四、经验总结 (9)异系统切换失败导致Volte掉话排查案例【摘要】LTE数据业务的掉话，我们通常是指UE异常退出RRC_CONNECTED状态导致的连接中断，在VoLTE语音业务时，对于开通VoLTE功能的用户会在RRC连接建立后建立QCI5的信令承载，在进行VoLTE通话时，会再建立QCI1的语音专用承载，QCI1的E-RAB释放，意味着VoLTE语音业务结束，所以我们用QCI1的E-RAB异常释放来定义VoLTE语音业务掉话，E-RAB(QCI=1)掉线率反映了系统的业务通讯保持能力，也反映了系统的稳定性和可靠性。
【关键字】VoLTE掉话异系统切换【业务类别】VoLTE一、问题描述2019年3月31日宣城电信RCU设备在市区进行拉网测试时出现VoLTE异常掉话现象，问题点位于宣州区水阳江大道宛陵湖展览馆附近。
测试设备在其他基站可以正常进行VoLTE呼叫，基本可以排除测试设备的问题。
并对基站参数和其它站点参数进行对比，未发现和VoLTE相关的参数存在差异。
需要信息分析优化定位故障并解决。
二、分析过程（一）、排查思路分析VoLTE掉话分为UE上下文释放、E-RAB承载释放两类掉话。
端到端信令VoLTE掉话：当eNodeB收到来自MME的E-RAB RELEASE COMMAND（UE CONTEXT RELEASE COMMAND）消息，或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“Detach”，“User Inactivity”，“CS Fallback triggered”，“UE Not Available for PS Service”，“Inter-RAT Redirection”，“Successful Handover”时，如果释放的承载包括QCI=1，则判断为VoLTE掉话。
切换异常的几种原因分析及排查
RNC发起无线链路建立，NodeB返回失败；
RadioLinkSetupFailure
RelocationFailure
RNC向CN发送重定位失败消息，根据失败的类型填写消息中的错误码；
IuReleaseRequest
D侧发起Iu连接释放过程；
IuReleaseCommand
原因分析及排查手段：
可能原因为：
UE未收到CONFIRM消息（下行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了CONFIRM消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
排查方法：
网络侧向终端发起物理信道重配过程，定时时间内终端未发送物理信道重配完成消息，且在等待时间内未上报小区更新；
measurementReport
UciuHelloForward
UciuHelloForwardAck
SUciuMacMeasReport
RadioLinkDeletionRequest
网络侧删除目标小区无线链路及承载；
RadioLinkDeletionResponse
FpSRelReq
IuReleaseRequest
原因分析及排查手段：
UE收到了RECONFIGURATION消息，并发送了COMPLETE消息，但RNC未收到（上行功率不足或存在干扰等原因）；
UE收到了RECONFIGURATION消息，但没发送COMPLETE消息（消息错误或UE内部错误等原因）；
1.1.2.5
1.信令截图：
2.原因分析及排查手段：
从WCDMA跨IUR口切换失败案例谈RNC规划原则
和控制与之相连或相关的 Nod e来自B 的无线资源。 Nod e B 则完成 Iu b 接口和 U u 接口之间的数据流的转换，同 时也参与一部分无线资源管理。
2 跨 IUR口切换失败案例
图1 WCDMA接口结构
2. 1 WCDMA 接口结构介绍 WCDMA 中 的 U T RA N 包含一个 或几个无 线网络
Iu r 接 口 是 连 接 R NC 之 间 的 接 口，Iu r 接 口 是 U MTS 系统特有的接口，用于对 RA N 中移动台的移动 管理。比如在不同的 RNC 之间进行软切换时，移动台 所有数据都是通过 Iu r 接口从 正在工作的 RN C 传 到目 标 RNC。 2. 2 问题现象
某 地 优 化 测 试 中 发 现 CS 语 音 业 务 掉 话，地 点 在 跨 R NC 的 交 界 处， 现 象 是 激 活 集 中 的 信 号 比 较
1D ：最好小区变化事件，发生硬切换时上报此事件 ； 详细流程见协议 25. 413。 查 看掉 话时 测试 数据 的信 令流 程， 发现 掉话 前激 活 集中的信 号为经 过 SR NC 与 CN 侧进 行通信 的一小 区（PSC274），手 机上 报了添 加 DRN C 下 另一信 号比 较 好的 小区（PSC121）的 1A 事件，同时 SRN C 侧也 收到了此测量报告，但接下来 RNC 却没有下发激活集 更新消息，手机激活集中的信号变差，等待超时导致掉 话。此 掉话发 生在相 邻 RNC（RNC4 和 R NC3） 交界 处，这两个 R NC 是存在 IU R 口的，正常流程应该上报 1A 事件，下发激活集更新消息进行跨 IU R 口的软切换。 但实际情况是 PSC121 比 PSC274 信号好的时候也一直
对于没有 IU R 口的 R NC 间的硬切换伴随迁移，是 指原 来的 RN C 为服务 R NC（SRNC ），另外一 个切入 的 RN C 为 目 标 R NC（DRN C）， 开 始 时 是 SR NC 与 CN 间存在通信链路，当跨过 SRN C 所属的小区时，与 CN 间 的通 信链 路变 为 DRNC 和 CN 间，新的 DRNC
LTE切换失败问题分析报告案例
X2IPPATH配置问题导致切换不成功关键字：X2IPPATH 切换【现象描述】切换测试时，从站点B1的标口信令跟踪发现站点B1连续出现切换准备失败，HANDOVER_REQUEST消息后出现HANDOVER_PREPARATION_FAILURE，进入该消息中可以看到cause为transport-resource-unavailable，切换不成功，如下图所示。
【原因分析】对于切换流程失败而言，如果是切换准备阶段的失败，其原因通常为以下几种：（1）传输资源不够用；（2）没有配置IPPATH；（3）IPPATH中的邻居节点配置错误。
由于切换测试阶段的网络业务负载很小，接入用户数少，通过X2口传输的数据不多，一般来说不会出现传输资源不够用的情况。
所以可以先重点怀疑IPPATH配置的问题，在处理过程中需要对X2口和IPPATH问题排查处理，一步步解决问题。
【处理过程】每次切换到目标小区完成后，UE会读取目标小区的系统消息（RRC_SIB_TYPE1）,该消息中可以看到目标小区的CGI，通过CGI中的基站ID确认目标基站B2的ID。
从该次切换的切换命令（RRC_CONN_RECFG）可以找到目标小区CELL2的PCI，在目标基站B2中用MML命令查询确实存在小区CELL2，所以接下来可以针对目标基站B2以及源基站B1来检查IPPATH的配置了。
先查看B2基站对应的IPPATH有没有配置，如果配置则确认X2接口ID与IPPATH的邻接点ID是否一致。
在webLMT上的命令如下：LST SCTPLNK；检查SCTPLNK是否建立并查看目标基站B2以及源基站B1对应的SCTP链路号SCTP Link No。
DSP X2INTERFACE；检查X2INTERFACE是否配置并根据SCTP链路号SCTP Link No，查看对应X2接口的标识X2InterfaceId。
LST IPPATH; 根据X2接口标识X2InterfaceId，查看X2口两端的IP配置是否正确。
切换异常的几种原因分析及排查共18页
名称：切换异常的几种原因分析及排查提交人：张鑫提交日期：2011-12-24软件版本：硬件版本：1.1 RNC内切换过程中的异常1.1.1 总体描述RNC内切换相关的异常主要有如下几种典型场景：物理信道重配失败：网络侧在下发physicalChannelReconfiguration消息后，终端回physicalChannelReconfigurationFailure消息，导致切换过程失败，此类异常影响RNC内切换成功率，但不会导致掉话；物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端仍然未上报cellUpdate，超时后释放，此类异常会同时影响切换成功率；小区更新后物理信道重配超时：网络侧在下发physicalChannelReconfiguration消息后，终端没有响应，网络侧等待一段时间后，终端上报cellUpdate，网络侧下发cellUpdateConfirm消息，终端响应超时后释放，此类异常会同时影响切换成功率；网络侧收到测量报告但未发起切换：网络侧收到终端上报的1G或2A测量报告，但未在目标小区发起无线链路建立过程，也未向终端下发physicalChannelReconfiguration，此类异常不会对KPI指标造成直接影响；1.1.2 典型信令过程1.1.2.1 物理信道重配失败1. 信令截图：第 1 页2. 信令分析：第 3 页原因分析及排查手段：查看PhysicalChannelReconfigurationFailure 中携带的失败原因，比如最常见的Failure cause 为physical channel failure ，表示UE 无法在建立新的物理信道，即UE 无法在新的信道配置上完成L1同步（UE 在T312时间内，收到N312个同步指示，即认为新的信道建立成功）。
Iurg切换失败流程排查
Iurg切换失败流程排查————————————————————————————————作者：————————————————————————————————日期：双方对采集信令分析如下：1、RNC侧向CN发送的RelocationRequired消息中，根据协议规定在Old BSS to New BSS信息中包含了D-RNTI字段，与BSC发给ＲＮＣ的Enhanced Relocation ResourceRespond消息中携带的D-RNTI值一致（过程中涉及十进制和十六进制转换），如下：2、查看CN侧与RNC侧的交互信息，可看到CN侧收到RNC中的字段信息无误，如下图：3、查看CN与BSC信息交互过程中，CN接收到Relocation Required消息后向BSC 发送Handover Request，按协议要求该“Handover Request”消息中同样必须携带Old BSS to New BSS信息，并在该信息中包含该D-RNTI字段。
但是目前看到的所有切换流程中CN发给BSC的Handover Request消息中都缺少该条字段，导致BSC一直处于等待状态（BSC会一直等待包含该字段的Handover Request消息），超过2 S后BSC释放资源，导致切换失败。
1）BSC A接口采集的收到CN的handover Request信令如下图（缺少该字段）。
2）CN侧采集到的CN发出的Handover Request消息（同样缺少该字段）如下附件是RNC与CN交互信令、BSC与CN交互的信令。
4、下文为集团Iur-g规范中关于切换流程的说明：引入Iur-g接口后，在标准2/3G语音切换流程基础上新增无线资源预留流程，由RNC与BSC直接交互，提前完成原本需要核心网转发的资源预留过程。
Iur-g+流程只适用于CS切换，PS切换还是传统切换流程。
•Iur-g+流程SRNC BSCUE CN 1：MEASUREMENT REPORT 2：ENHANCED RELOCATION RESOURCE REQUEST3：ENHANCED RELOCATION RESOURCE RESPONSE5： RELOCATION REQUIRED4：HANDOVER FROM UTRAN COMMAND 6：HANDOVER REQUEST7：HANDOVER REQUEST ACKNOWLEDGE 8：RELOCATION COMMAND 12： HANDOVER COMPLETE11：HANDOVER DETECT13：HANDOVER COMPLETE 14：IU RELEASE COMMAND15：IU RELEASE COMPLETE NODE B16：RADIO LINK DELETION REQUEST17：RADIO LINK DELETION REPONSE10： HANDOVER ACCESS9：RELOCATION COMMIT空口缓发定时器T图2-3 基于Iur-g+接口的切换流程1） RNC 收到UE 的测量报告，结合GSM 邻区的小区容量和负荷信息，确定向某个邻接的GSM 小区进行切换。
切换失败信令处理(中兴)
切换失败信令处理(中兴)切换失败信令处理UU接口信令异常的常见原因有：1)测量报告丢失，可能的原因主要有➢UE上发测量报告的UL GRANT没有收到，下行PDCCH受限➢UE上发的测量报告，eNB没有收到（或收到但CRC错），上行PUSCH受限➢UE内部层间丢失，例如L3把测量报告给L2发送时，L2处理失败2)切换命令丢失，可能的原因主要有➢eNB因为在切换内部流程处理（如邻区漏配、资源不够等）出错，没有下发切换命令➢UE下行PDCCH解析失败，下行PDCCH受限➢UE下行PDSCH解析失败，下行PDSCH受限3)切换完成信令丢失，可能的原因主要有➢UE在目标小区的PREAMBLE，eNB没有收到，上行PRACH受限➢UE下行接收RAR失败，下行PDSCH受限➢UE上发切换完成，eNB没有收到，上行PUSCH受限4)11111切换请求丢失，可能的原因主要有➢eNB内部处理测量报告异常，如邻区漏配、内部模块处理失败➢X2口传输异常，如传输丢包5)切换响应丢失，可能的原因主要有➢源小区内部异常，源小区在目标小区回切换响应之前，向目标小区在X2口发HANDOVER CANCEL信令➢目标小区切换准备异常，这时通常会在X2口出现 HANDOVER PREPARATION FAILURE信令➢X2口传输异常，如传输丢包6)SN状态前转信令丢失，可能的原因主要有➢X2口传输异常，如传输丢包➢源小区内部错7)UE上下文释放信令丢失，可能的原因主要有➢X2口传输异常，如传输丢包➢目标小区收到切换完成后内部处理错，导致没有进行S1 PATH切换➢S1 PATH切换失败对于X2口消息交互出现异常，通常是传输失败或基站内部处理出错，而基站内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
X2接口信令异常的常见原因有：8)跨X2切换的S1AP PATH SWITCH REQ丢失，可能的原因主要有➢目标eNB内部处理切换完成信令失败➢S1口传输异常，如传输丢包9)跨X2切换的S1AP PATH SWITCH REQ ACK丢失，可能的原因主要有➢核心网收到S1AP PATH SWITCH REQ消息后，内部处理失败10)跨S1切换的S1AP HANDOVER REQUIRTED信令丢失，可能的原因主要有➢源小区因为在切换内部流程处理出错（如邻区漏配、资源不够等），没有发切换请求消息S1AP HANDOVER REQUIRTED➢S1口传输异常，传输过程中丢失11)跨S1切换的S1AP HANDOVER REQUEST信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER REQUIRTED后，内部处理出错➢S1口传输异常，传输过程中丢失12)跨S1切换的S1AP HANDOVER REQUEST ACK信令丢失，可能的原因主要有➢目标小区收到S1AP HANDOVER REQUEST后，内部处理出错（如资源不足等）➢S1口传输异常，传输过程中丢失13)跨S1切换的S1 HANDOVER CMD信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER REQUEST ACK后，内部处理出错➢S1口传输异常，传输过程中丢失14)跨S1切换的S1AP ENB STATUS TRANSFER信令丢失，可能的原因主要有➢源小区处理收到S1 HANDOVER CMD后，内部处理出错➢S1口传输异常，传输过程中丢失15)跨S1切换的S1AP MME STATUS TRANSFER信令丢失，可能的原因主要有➢核心网收到S1AP ENB STATUS TRANSFER后，内部处理出错➢S1口传输异常，传输过程中丢失16)跨S1切换的S1AP HANDOVER NOTIFY信令丢失，可能的原因主要有➢目标小区收到切换完成消息后，内部处理出错➢S1口传输异常，传输过程中丢失17)跨S1切换的S1AP UE CONTEST REL CMD信令丢失，可能的原因主要有➢核心网收到S1AP HANDOVER NOTIFY后，内部处理出错➢S1口传输异常，传输过程中丢失18)跨S1切换的S1AP UE CONTEST REL CMP信令丢失，可能的原因主要有➢源小区收到S1AP UE CONTEST REL CMD后，内部处理出错➢S1口传输异常，传输过程中丢失对于S1口消息交互出现异常，通常是传输失败或网络设备内部处理出错，设备内部处理出错的概率较小，传输失败的可能性较大，但比较难以定位，需要在传输的两端抓包确认。
测试标准化流程_切换失败
切换失败问题定位流程目录1、测试信息描述 (2)2、网络信息收集 (2)3 、常见原因 (2)4 定位流程 (3)5各种造成切换失败的原因分析、定位及常用优化方法 (4)5.1小区拥塞处理 (4)5.2区域频率干扰处理 (4)5.3同频同BSIC处理 (4)5.4参数配置优化 (5)5.5硬件隐性故障处理 (5)5.6交换或路由定义问题 (6)1、测试信息描述故障发生位置信息现场详细地理环境描述故障发生时间段测试手机号码测试手机型号及测试软件版本是否占用该路段的主覆盖小区信号问题路段是否有突发用户行为（如集会、活动等）问题是否经过反复测试仍然存在2、网络信息收集周边站点分布及相关物理信息测试当天各时段的话务指标统计对应测试当天的最新CDD近期相关站点是否有网络维护工程相关基站（小区）是否存在告警和收集周边区域小区性能近期是否有网络调整（割接、升版等）故障路段是否有新入网局3 、常见原因目标小区话务拥塞区域频率干扰邻区同频（同频同BSIC）参数配置不合理小区硬件隐性故障交换或路由定义问题4 定位流程5各种造成切换失败的原因分析、定位及常用优化方法5.1小区拥塞处理原因分析: 由于网络资源无法满足实际话务需求，如拥塞小区作为目标小区时，因资源问题导致无法分配业务信道，可能在发起切换后会因无法提供业务信道接续而导致切换失败、回切甚至掉话；定位:查询目标小区话务，发现对应时段存在SDCCH或业务信道拥塞，则基本可定位为高话务导致切换失败；优化方法：A、对存在拥塞并影响切换的关键小区进行扩容；B、小区负荷分担功能的应用；C、双频网的建设及话务分流；D、半速率功能的应用；E、天线下倾调整、小区发射功率调整来降低话务。
5.2区域频率干扰处理原因分析：在日常优化中移动台在占用主覆盖小区通话出现严重质差时会发起紧急切换，反过来在切换中目标小区出现严重的频率干扰时，则会出现连续的切换申请和切换失败，主要是由于同频、邻频干扰严重，导致C/I偏低，影响系统解码，导致移动台与BSC间的信道激活等消息无法接收，最终激活信道超导致切换失败；定位：在测试数据回放或MRR分析中发现切换目标小区话音质量一直不理想，话务统计发现质差掉话多；通过现场TEMS锁频测试发现该小区的C/I较低且通话质量较差，再结合MCOM 分析可发现切换目标小区的频率受到严重的干扰；优化方法：A、更换受干扰频点；B、确保跳频功能的打开；C、动态功率控制功能的打开及期望值的优化；D、上下行不连续发射功能的打开；E、平衡话务并进行针对性减容；F、网络变频5.3同频同BSIC处理原因分析：由于在日常网优过程中，未免会出现更换频点或增加相邻关系时没有考虑到现有邻区存在同频或同频同BSIC的情况，导致小区间的严重干扰，也可能会造成移动台解码错误，导致切换失败或切换至非目标但同频小区，造成切换孤岛，最终掉话；定位：在测试过程中容易发现移动台切换失败或没有切向实际覆盖小区且切换后出现严重质差，通过MCOM发现误切的小区与实际目标小区的频点甚至BSIC也相同；优化方法：A、在日常频率优化中，务必考虑现网的频率配置，避免更换的频点与故障区域内小区存在同频或同频同BSIC情况；B、在增加相邻关系时，务必确保将要增加相邻关系的小区是否与现有邻区存在同频（同频同BSIC）；C、可以通过分析系统一致性检查结果发现现网邻区同频（同频同BSIC）并及时纠正。
LTE切换失败简析
LTE切换失败简析LTE切换失败简析坏⼩区定义现在给移动的⽇报中对于切换坏⼩区的定义为切换成功率<90%,切换失败次数>15该指标定义是ENB间的⼩区之间通过X2接⼝进⾏切换的成功率。
切换成功率是系统移动性管理性能的重要指标，并可⽤于分析相邻关系定义是否合理。
此KPI⼀般⼤于95%，处于⽐较良好的⽔平切换过程整个切换过程包括切换测量，切换准备与切换执⾏三个阶段：测量阶段，UE根据下发的测量配置消息进⾏相关测量，并将测量上报给准备阶段：根据UE上报的测量结果进⾏评估，准备切换资源，最终决定是否触发切换。
执⾏阶段：eNode根据切换准备结果，控制UE切换到⽬标⼩区，由UE完成切换。
因此切换成功率指标的分析需分别对切换测量，切换准备与切换执⾏来进⾏分析。
切换指标enb内切换成功率公式：VS_HO_Irc_eNB_succ_src/VS_HO_Irc_eNB_req_srcenb间X2切换成功率公式：VS_HO_IrC_X2_succ_prep_src/ VS_HO_IrC_X2_req_src ----enb间X2切出准备成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_succ_prep_src----enb间X2切出执⾏成功率VS_HO_IrC_X2_succ_src/ VS_HO_IrC_X2_req_src------------enb间X2切出成功率enb间S1切换成功率公式：VS_HO_IrC_S1_succ_prep_src / VS_HO_IrC_S1_req_src ----enb间S1切出准备成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_succ_prep_src----enb间S1切出执⾏成功率VS_HO_IrC_S1_succ_src/ VS_HO_IrC_S1_req_src------------enb间S1切出成功率Indicator与信令的对应对于源⼩区X2切换来说源⼩区发出Handover request---------VS_HO_IrC_X2_req_src源⼩区收到Handover request ACK---VS_HO_IrC_X2_succ_prep_src源⼩区收到ue context release---------VS_HO_IrC_X2_succ_src对于⽬标⼩区X2切换来说⽬标⼩区收到Handover request---------VS_HO_IrC_X2_req_tgt⽬标⼩区发出Handover request ACK---VS_HO_IrC_X2_succ_prep_tgt⽬标⼩区发出ue conte x t release---------VS_HO_IrC_X2_succ_tgtX2切换信令&counter点切换分析GSM中有180报告，通过这个报告可以清楚看到⼩区切出切⼊⼩区，切出切⼊请求次数，切出切⼊成功率；对于切换坏⼩区，可以很⽅便的找出对应切⼊或者切出问题⼩区。
切换失败原因分析
切换失败原因分析一、切换的定义及划分所谓切换，就是指当移动台在通话过程中从一个基站覆盖区移动到另一个基站覆盖区，或者由于外界干扰而造成通话质量下降时，必须改变原有的语音信道而转接到一条新的空闲语音信道上去，以继续保持通话的过程。
切换根据手机和基站测出的上下行电平质量和TA 值作为最基本的测量数据，根据切换判断算法和资源分配算法来决定是否应该切换和切向哪个小区。
切换是移动通信系统中一项非常重要的技术，切换失败会导致通话失败，影响网络的运行质量。
因此，切换成功率（包括切入和切出）是网络考核的一项重要指标，如何提高切换成功率、降低切换失败率是网络优化的重点工作之一。
根据不同的切换判决触发条件，切换可以分为紧急切换、负荷切换等5类。
（1）紧急切换。
包括TA过大紧急切换、质量差（BQ）紧急切换、快速电平下降紧急切换、干扰切换。
●TA过大切换条件：服务小区的TA大于等于紧急切换TA限制。
●BQ切换条件：服务小区的上行链路质量在滤波器长度时间内平均值大于等于紧急切换上行链路质量限制；服务小区的下行链路质量在滤波器长度时间内平均值大于等于紧急切换下行链路质量限制。
●快速电平下降切换在呼叫中电平突然下降时触发，触发条件：服务小区如果Value＞B（Value：一个与滤波器参数A1～A8相关的值，该值表示在一段时间内接收电平的变化趋势；B：滤波器参数）切换最后的MR6已经低于边缘切换门限，则发生切换。
●干扰切换：也属于紧急切换，当接收电平大于一定值但传输质量又低于干扰切换质量门限时触发。
（2）负荷切换。
负荷切换触发要同时满足三个条件：系统信令流量小于允许负荷切换系统流量级别门限；需要切换的小区负荷高于负荷切换启动门限；接收切换的小区的负荷低于负荷切换接收门限。
（3）正常切换。
包括边缘切换、分层分级切换和PBGT切换。
●边缘切换条件：服务小区已低于边缘切换门限；在边缘切换统计时间（如5 s）内，服务小区电平持续低于边缘切换门限（如4 s）。
5G优化案例：5G终端SCGFailur导致切换失败问题处理案例
5G 终端 SCG Failure 导切换失败问题处理XX【摘要】在 LTE(Long TermEvolution，长期演进)系统也即 4G 网络中，E-UTRAN(Evolved UMTS Terrestrial Radio Access Network，演进的 UMTS 陆地无线接入网)由多个 eNodeB(Evolved Node B，演进型基站)组成，eNodeB 与E PC(E vo lv ed Packet Core，核心分组网演进)之间通过 S1 接口连接，eNodeB 之间通过 X2 接口连接，为了支持更高的数据吞吐量，UE 用户设备可以通过两个eNodeB 实现双连接。
和 LTE 系统的双连接类似，在 5G 系统中，也支持 eNodeB 和 5G 基站 gNB 的紧耦合互操作 Tight Interworking，在 LTE 和 5G 紧耦合场景下，UE 与 gNB 之间的网络断开时，UE 就会发生辅小区组失败 SCG Failure，有用户反映在世贸商城附近区域，终端显示为 5G 信号，但是上网慢，经过分析该用户从室外切到室内时每次都发生“Random Access Problem” SCG Failure导致切换失败，从而回落4G，最终通过修改波速解决该问题。
【关键字】5G 切换失败AXON10Pro【业务类别】移动网1.现场测试外场针对用户反映的问题进行现场测试，用户所在区域为室内外切换带，在该区域主要占用室分小区思明区世贸商城二 QC_C1NCYT1（PCI:414）、室外小区思明区软件园二期观日路 8 号_C2WCND3（PCI：43），该区域的 RSRP 均>-95dBm，RSRP 值覆盖良好。
但是在使用 mate20 X 进行室内外切换过程中，室内往室外切换失败，“T310超时”的 SCG Falure，从而释放 5G SCG 掉4G。
2.分析优化2.1邻区核查核查室内外邻区，发现只添加了单向室外到室内邻区。
通过A口信令分析排查核心网侧切换失败原因的思路和方法
通过A口信令分析排查核心网侧切换失败原因的思路和方法文章先介绍基本局间切换的信令流程，再通过对A口信令追踪，对由于核心网侧问题引起的切换失败的原因进行了分析和判断，并提出解决方案，从而达到提高移动通信网络服务质量和用户感知的目的。
【摘要】【关键词】A口信令核心网侧切换源网元目标网元张 惠 广东宜通世纪科技股份有限公司1 引言切换是移动用户业务接入过程中或业务进行过程中，由于用户的移动性而发生的改变位置小区选择的行为。
通话中的手机需要靠切换来保持良好的上下行信号强度和质量。
切换主要包括BSC内的小区间切换、MSC内的BSC间切换以及MSC间切换。
本文通过对A口信令追踪，针对MSC内的BSC间切换、MSC间切换两种切换类型，对切换失败案例进行分析，确定引起切换失败的原因，并排查导致此类问题的原因和隐患，对提高移动通信网络的服务质量具有现实意义。
2 基本局间切换的信令流程基本局间切换的信令流程如图1所示。
具体如下：（1）BSS-A向MSC-A发送Handover Required。
（2）M S C-A给M S C-B发送M A P_P r e p a r e_ Handover消息。
（3）MSC-B向VLR-B申请切换号码。
（4）VLR-B分配一个切换号码给MSC-B。
（5）MSC-B回复VLR-B确认收到切换号码。
（6）M S C-B向B S S-B接口发送H a n d o v e r Request消息。
（7）BSS-B向MSC-B 发送Handover Request Ack消息。
（8）MSC-B局间通过MAP_Prepare_Handover_ Ack消息发送给MSC-A。
（9）MSC-A发送IAM消息给MSC-B。
（10）MSC-B向MSC-A发送ACM消息。
（11）M S C-A给B S S-A发切换命令H a n d o v e r Command。
（12）手机发送Handover Access消息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
双方对采集信令分析如下：
1、RNC侧向CN发送的RelocationRequired消息中，根据协议规定在Old BSS to New BSS信息中包含了D-RNTI字段，与BSC发给ＲＮＣ的Enhanced Relocation ResourceRespond消息中携带的D-RNTI值一致（过程中涉及十进制和十六进制转换），如下：
2、查看CN侧与RNC侧的交互信息，可看到CN侧收到RNC中的字段信息无误，如下图：
3、查看CN与BSC信息交互过程中，CN接收到Relocation Required消息后向BSC发送
Handover Request，按协议要求该“Handover Request”消息中同样必须携带Old BSS to New BSS信息，并在该信息中包含该D-RNTI字段。
但是目前看到的所有切换流程中CN发给BSC的Handover Request消息中都缺少该条字段，导致BSC一直处于等待状态（BSC会一直等待包含该字段的Handover Request消息），超过2 S后BSC释放资源，导致切换失败。
1）BSC A接口采集的收到CN的handover Request信令如下图（缺少该字段）。
2）CN侧采集到的CN发出的Handover Request消息（同样缺少该字段）
如下附件是RNC与CN交互信令、BSC与CN交互的信令。
4、下文为集团Iur-g规范中关于切换流程的说明：
引入Iur-g接口后，在标准2/3G语音切换流程基础上新增无线资源预留流程，由RNC与BSC直接交互，提前完成原本需要核心网转发的资源预留过程。
Iur-g+流程只适用于CS切换，PS切换还是传统切换流程。
Iur-g+流程
图2-3 基于Iur-g+接口的切换流程
1） RNC收到UE的测量报告，结合GSM邻区的小区容量和负荷信息，确定向某个邻接的GSM小区进行切换。
2）RNC为此UE申请Iur-g+接口的SCCP链路，并向BSC发送ENHANCED RELOCATIONRESOURCE REQUEST请求，请求为本UE预留资源。
3） BSC接收到ENHANCED RELOCATION RESOURCE REQUEST请求后，为UE分配D-RNTI，根据请求的Speech Version类型预留无线资源，并给RNC发送ENHANCEDRELOCATION RESOURCE RESPONSE，同时作为可选方式，响应消息中可以携带2G小区的容量和负荷信息。
4） RNC接收到ENHANCED RELOCATION RESOURCE RESPONSE消息后，把相关资源通过空口消息Handover From Utran Command发送给UE，同时向CN发送RelocationRequired消息，在消息的Old BSS to New BSS Information中添加D-RNTI 信息。
5） CN接收到Relocation Required消息后，向BSC发送Handover Request消息。
BSC完成A口资源的建立，并且根据Old BSS to New BSS Information中D-RNTI信息与预留的空口无线资源关联，向CN发送Handover Request Ack消息。
6） CN接收到BSC的Handover Request Ack，向RNC发送Relocation Command消息，RNC收到Relocation Command后，通过Iur-g+接口向BSC发送Relocation Commit 消息。
7） BSC收到UE的Handover Access时，若已接收到Relocation Commit，则向CN 回复Handover Detect，否则等待Relocation Commit达到后，再回复Handover Detect。
8） BSC接收到UE的Handover Complete，向CN发送Handover Complete消息，CN接收到消息后，向RNC发送Iu Release Command消息。
9） RNC完成UTRAN资源的释放，同时释放Iur-g接口的SCCP链路。
向CN回应Iu ReleaseComplete消息，流程结束。
与传统23G语音切换流程相比，Iur-g+流程有两点不同。
第一点不同是改变了Handover From Utran Command（信令4）和Relocation Required（信令5）的发送时序，在传统流程中是先发出Relocation Required，在收到CN回应的Relocation Command后，再发起Handover From Utran Command。
而在Iur-g+流程中通常是同时发起Relocation Required 和Handover From Utran Command，也就是这两条信令由传统方式下的串行，变成了Iur-g+流程下的并行，节约了切换时间。
第二点不同是增加了三条信令，在上图2-3中，蓝色字体标识出的为Iur-g+切换流程增加的信令，其中ENHANCED RELOCATIONRESOURCE REQUEST（信令2）和ENHANCEDRELOCATION RESOURCE RESPONSE（信令3）是通过Iur-g口进行资源准备，减少资源准备的时延；Relocation Commit（信令9）是为了保证BSC和CN间信令交互时序正常，BSC只有收到RNC 的Relocation Commit消息，才会向CN发出Handover Detect（信令11）消息。
在Iur-g+流程中，由于Relocation Required和Handover From Utran Command并行，在跨核心网切换时，可能存在信令空口时延小于Iu口时延的情况，如果没有Commit消息，可能存在Handover Detect早于Handover Request Ack（信令7）到达CN，这样就会导致时序混乱，产生异常掉话。