重庆移动eSRVCC切换指标分析报告

1、重庆移动eSRVCC切换指标分析报告交换中心核心网维护部2016年3月10日、前言随着VoLTE业务的逐渐商用化， VoLTE用户数和业务量持续增长，eSRVCC的切换量也随之持续增长。但是，目前重庆移动的eSRVCC切换成功率指标还不理想，在集团的排名也很靠后。这是 3月8日全天的指标统计数据：时间SRVCC切入请求次数SRVCC切入取消次数SRVCC切入接受次数SRVCC切入接受率SRVCC切入完成次数SRVCC切入完成率SRVCC切入成功次数SRVCC切入成功率2016/3/8186097185899.89%90848.82%62933.82%为此，交换中心核心网维护部开展了对eSRVC

2、C切换的专项优化工作，对当前指标的现状进行了详细分析，以期对今后的优化工作提供指向性的信息。、eSRVCC切换涉及的主要接口F图是一次正常eSRVCC切换的标准流程:*©口 心I SarvwrFE jiukril uTR!<nl 堵七起切a:Q NVTTE注01為BJN弓們MV1E屣待mift合话 僮克叠话捲人宾EPCtt S.-P-GW，/iBUrryatimTHarJor 圈qjlrd hanawflFf 活目沖:Vr.-5M2.槪妙傅它园UJFM/GEFt-N*E- JTfiAN可见，在eSRVCC切换流程中，eMSC （上图红圈内，也称 SRVCC IWF ）主要涉及到

3、 3 个接口（上图黄圈内）的业务处理：1）Sv接口。eMSC与MME之间的接口，采用 GTP协议。在这个接口上， eMSC接收eNodeB发来的切换请求，并返回目标小区的相关信息，与E接口一起协助 UE完成从4G向2G的切换。2）E接口。eMSC与目标MSC之间的接口，采用 MAP协议。在这个接口上， eMSC将收到的切换请求转发给目标MSC，并接收目标小区的相关信息，完成局间切换流程，与Sv接口一起协助UE完成从4G向2G的切换。（注：若目标小区与eMSC 处于同一 POOL内，则只需要进行局内切换。）3）Mw 口。eMSC与SBC/ATCF之间的接口，采用 SIP协议。在这个接口上， eM

4、SC 将切换用户的信息转发给 ATCF，ATCF再和IMS域内SCC AS完成会话的转移。可见，eMSC在eSRVCC流程中处于一个十字路口的地位，而上述3个接口中的信令消CQGS47这个eMSC的角息也反映了切换流程中的各种关键信息。因此，本报告也主要从度，对当前的eSRVCC指标现状进行分析。三、eSRVCC指标的计算公式(一)计算公式根据集团公司规定的计算公式，eSRVCC存在以下2个比较重要的指标：eSRVCC成功率=SRVCC切入成功次数/SRVCC切入请求次数eSRVCC完成率=SRVCC切入完成次数/SRVCC切入请求次数(二)公式解读1 .分母：SRVCC切入请求次数触发点：e

5、MSC从MME收到PS to CS Request消息。2.分子：SRVCC切入完成次数触发点：eMSC 向 MME 发送 SRVCC PS to CS Complete 消息。SRVCC切入成功次数触发点：eMSC 向 MME 发送 SRVCC PS to CS Complete 消息，且 eMSC 收到IMS域ATCF发来的2000K消息。这是因为，整个 SRVCC的过程包括两个 相对独立的环节：(1) 承载切换。无线承载从4G向2G的切换。(2) 会话转移。会话从IMS域向CS域的转移。只有这两个环节全部成功，才表示SRVCC过程最终成功。四、eSRVCC切换失败分析F面是一次正常eSR

6、VCC切换的信令交互流程:嵌EJ出 Ml£ AP工昭亠ATCF At k-S-CSCF A4TCW AMMl AS.- 3CC A3_AR樹方啰讪"冃无勺j童或的 AULI HtUW5.ADD REPLY£L£MAP PRE°AtE HAHDCE2 SRVCC 吨nhg Q5 RgqpiL FJijrMrTkAf-!llT.lmt FRMIP*TOP9 R#i 5»ee h RwuestaEj k1Ift.ADD RFQ17 MAP PRFP.pF HAnr(VFRn%rJXAD RQ:e MOO REQ” MD REP営 1冃nit

7、FRMIPI.ADC FLEPILYAMrlcT11 *D0 REPUf«fl SRV«*ATCF1 ifra虫傳;端点:湾斤IhIVrTE(1)27 MOD REQpa MC43 REPLJREO30 NTFYREPLYCSRBK新A$ioc4ihc*n 匸 sd/t f33 *R(|l0Cd !>fPr CWiEflijklINCilMjWIGWAMMV WEIHD 朗0 3M3曲如疔也I止1aspsioCdHpterw.事mi.Mnti*aban:)r atet&根据成功率的计算公式：当eMSC收到PS to CS Request消息（上图红框消息），分

8、母开始计数。当eMSC收到200 OK消息、且发出 SRVCC PS to CS Complete消息（上图蓝框消息1、2），分子开始计数。而eMSC收到200 OK消息和发出 SRVCC PS to CS Complete消息，是2个相对独立的过程。其中：是否收到200 OK，主要取决于 SBC/ATCF对会话信息及状态的判断。这个过 程主要通过 Mw接口实现。是否发出Complete消息，主要取决于局间（或局内）切换是否正常完成、UE是否已成功接入到目标 2G小区。这个过程主要通过 Sv接口及E接口实现。F面，我们就在不同的接口上，对上述2个过程进行深入分析。（一） Mw 接口从上面的信令

9、流程图来看，Mw接口的信令交互较为简单，正常情况下只有Invite、 100、200这3条消息即完成交互，似乎不会有什么失败的情况。但是，3月8日的两个关键指标SRVCC完成率和成功率之间存在着15%左右的差值（这个差值就是发出Complete消息却没有收到 200 OK的次数），表明这个接口上仍然存在一定的失败情 况。1. 失败原因汇总为此，我们连续多日在 CQGS47上对Mw接口的SIP消息进行了持续的全量跟踪, 并对各种异常的情况进行了汇总分析。汇总结果如下：消息次数占比发出的Invite消息2252200 OK for Invite164373.00%183 Session Progr

10、ess48621.60%480 Temporarily Unavailable37516.70%487 Request Terminated1858.20%408 Request Timeout160.70%491 Request Pending140.60%从上表可见，eMSC收到的200 OK （for Invite ）消息仅有73%，其余还出现了 183、 480、487、408、491共5种响应消息。我们结合 VoLTE信令监测系统、贝尔IMS镜像 消息，对上表中出现的各自响应消息依次进行了详细分析。2.183响应消息a. 失败场景：现网Mw接口上出现183消息的情况较多。我们从中抽取

11、了部分消息，根据切换用户号码搜索到IMS域内对应的完整消息，发现所有ATCF返回183消息的场景都是呼叫尚处于振铃阶段 （无论发生切换的号码是主叫方还是被叫方都如此）。注：这种振铃阶段发生的SRVCC也称为aSRVCC。b. 失败原因：对于aSRVCC的场景，ATCF不会直接返回200 OK，而是首先返回183消息。只有当被叫接听电话后，才会返回200 OK消息。否则，就将记为一次 eSRVCC切换失败。c. 解决思路：从上面的分析可见，按照现有的算法，aSRVCC场景的切换成功与否， 完全取决于被叫用户的用户行为，具有不合理的因素。 为此，集团公司已对算法进行了修正：aSRVCC切换场景的切

12、换成功次数统计的触发点为：eMSC向MME发送SRVCC PS to CS Complete 消息，且 eMSC 收到 IMS 域 ATCF 发来的 Info 消息。从现网抓取的消息来看，aSRVCC流程基本上都收到了Info消息（用于告知切换用户的振铃状态及主被叫状态）。因此，如果采用新算法，aSRVCC基本都可以成功。据华为公司反馈，包含新算法的eMSC补丁有望在3月底左右加载，届时即可解决此问题。3.480响应消息a. 失败场景：现网Mw接口上出现480消息的情况也较多。我们采用相同的方法分析，发现ATCF返回480消息的场景有2种：呼叫尚处于振铃前阶段。 在被叫尚未振铃的时候 （未返回

13、180 ring）， 主叫发生 SRVCC切换（这种振铃阶段发生的SRVCC也称为bSRVCC）,呼叫处于拆线阶段。在呼叫正在拆线时，主叫或被叫发生SRVCC切换，ATCF返回也会480 Temporarily Un available。但是这种场景发生 的概率极低。b. 失败原因：对于bSRVCC的场景，目前集团公司尚无相应的切换流程规范，此 场景切换必然失败，eMSC也不可能收到200消息。对于拆线阶段的切换，由于ATCF或SCC AS上已无呼叫的会话信息，因此切换也必然失败。c. 解决思路：由于尚无bSRVCC切换的流程规范，现阶段只要发生 bSRVCC必然切换失败， 故解决的思路只能放

14、在如何尽量避免发生bSRVCC切换上：缩短接续时延。 接续时延越短，发生 bSRVCC的概率就越低。但是 目前volte域内互通的接续时延已控制在34秒左右，与 cs域互通的接续时延也已经过长期的优化，与网间用户互通的接续时延又取决于其他运营商的接续速度，可见能够提升的空间都不大。改善LTE网络覆盖。显然，LTE信号覆盖越好，发生 bSRVCC的概 率也越低，从而减少失败的发生。4.487响应消息a.失败场景:出现487消息的占比同样不容忽视。分析后发现，ATCF返回487消息的场景也都与振铃阶段的 aSRVCC有关：振铃期间如果主叫或被叫提前挂机，贝UATCF向eMSC返回487消息。b.

15、失败原因：由于主叫或被叫提前挂机，此场景下ATCF必然不会返回200 OK，按照现在的统计算法，这将被记为一次切换失败。c. 解决思路：由于是aSRVCC场景，采用新的算法后，此场景也基本能够记为成功切换。5.408响应消息a. 失败场景：出现408消息的占比很小。分析发现，ATCF返回408的场景也与振铃阶段的aSRVCC有关：如果被叫久叫不应，则ATCF向eMSC返回408消息。b. 失败原因：由于被叫最终没有接听电话，此场景下ATCF必然无法返回200 OK，按照现在的统计算法，这将被记为一次切换失败。c. 解决思路：由于是aSRVCC场景，采用新的算法后，此场景也基本能够记为成功切换。

16、6.491响应消息a. 失败场景：出现491消息的占比较也极小。目前对于出现此消息的原因尚未完全梳理清楚，后续将继续关注分析。b. 失败原因：此场景下 ATCF 返回 409 Request Pending（其中包含 Warning 信息:transaction inprogress on SAL,怀疑出现了某种流程冲突导致Invite请求被挂起），因此被记为一次切换失败。c.解决思路:根据后续的分析结果寻找对策。7.小结根据上述分析，我们可以看到：目前Mw接口上的切换失败主要都是由于aSRVCC和bSRVCC两种场景引起的。前者在更新算法后基本能够得到解决，而后者目前可能解决的办法不多，由此

17、造成的失败可能会长期存在下去。另外，我们发现不论 Mw接口成功与否，均不影响 eMSC向MME发送正常的SRVCC PS to CS Complete消息。也就是说， Mw接口的结果只影响 SRVCC切换成功率，但不影响 SRVCC切换完成率。（二） Sv 接口从eSRVCC的信令流程图来看，Sv接口涉及的信令交互相对较为复杂，要和局间的E接口（或局内的 A接口）共同完成 UE从4G向2G的切换。正常情况下，单纯的 Sv接口 只有4条消息：消息塑型人12016-030710:12:68.6>GTP_MSG_SRVCCPS_TO_CS_RE 022016-03-0710:12:69.448

18、<GTP M8G SRVCC FS TO CS RSP32016-0307 10 ：13；00.008< GTP MSG S RVCC P S TO CS Ca M P NTF42016-03-07 10 13：00 C13GTP MSG SRVCCP S TO GS Ga M P ACK其中，第2条“ PS to CS Respons6'消息中有以下 2个重要的字段：cause字段：用于表示 PS到CS的SRVCC切换请求是否被接受。如果Cause的值不等于“ Request accepted',则表示切换被拒绝。srvcc-cause字段：如果 SRVCC Ca

19、use value 的取值不等于 “ Request accepted",通过该信元用于进一步表示用户PS到CS的SRVCC切换请求被拒绝。3GPP协议29280-930协议对此字段定义了 110共10种取值，分别对应不同的失败 原因。eSRVCC原因值英文解释中文解释1Unspecified未指定2Handover/Relocation cancelled by source system源系统取消切换或重分配3Handover /Relocation Failure with Target system目标系统切换或重分配失败4Handover/Relocation Target

20、 not allowed不允许切换或重分配目标5Unknown Target ID未知目标ID6Target Cell not available目标单元不可用7No Radio Resources Available in Target Cell目标单元中没有无线资源可用8Failure in Radio Interface Procedure无线接口流程失败9Permanent session leg establishment error永久会话建立失败10Temporary session leg establishment error临时会话建立失败另外，如果在 eMSC发出第3条S

21、RVCC PS to CS Complete消息前，收到了 MME发来的SRVCC PS to CS Cancel Notification消息，这条取消消息中也会包含 srvcc-cause字段。因此，对于Sv接口的分析，我们将重点基于 Response信息或Cancel消息的srvcc-cause 字段信息。（注：由于E接口和Sv接口共同构成了处理无线切换的信令管道”两者有一定的重复性，且 E接口上更多的是与 eSRVCC无关的普通局间切换消息，因此目前暂时只 针对Sv接口进行分析。）1.自主开发Sv接口消息分析程序由于Sv接口上的 GTP消息很多，且无论切换是否成功，eMSC都会返回 P

22、S to CSResponse消息，只是通过其中的 cause字段、再结合srvcc-cause字段来区分不同的结果，因此仅根据消息类型根本无法看出是成功还是失败。另外，就算找到了失败的 Response消息，还要倒回去寻找对应的Request消息，才能找到切换的各种关键信息（用户号、 STN_SR、目标小区等）。根据上述特点，人工分析显然是无法胜任的，必须采用程序化手段进行自动化分析。为此，我们仔细对 GTP消息样例分析了细致分析，确定了不同消息类型、不同关键信 息的特征代码，设计了从原始GTP消息代码流中定位失败消息、并从对应Request消息中提取关键切换信息的处理思路。 然后在Micr

23、osoft Visual Basic平台上，完成了 “ Sv接口消息 分析”程序的开发。在Windows7操作系统下，只要运行此程序，选中GTP接口消息文件，点击“分析”按钮，就可以迅速完成所有消息的读取和分析，找出其中的失败消息及失败原因，并提取出本次失败切换的发生日期、时间、 MSISDN、IMSI、STN_SR、目标小区，所有这些信息都 输出到指定的文件中，以供进一步的深入分析使用。在这个分析程序的帮助下，我们可以迅速找出切换失败的相关信息，大大提升了对Sv接口的分析效率，将可以节约出来的宝贵的人力资源投入到更有价值的优化工作中去。2. 失败原因汇总从3月2日到3月7日我们连续在 CQG

24、S47上对Sv接口的GTP消息进行了持续跟踪，并利用自主开发的分析程序对全量消息进行了汇总分析。汇总结果如下（切换请求次数=3992)eSRVCC原因值英文解释中文解释发生次数失败率1Unspecified未指定110327.63%2Handover/Relocation cancelled by sourcesystem源系统取消切换或重分配2075.19%3Handover /Relocation Failure with Targetsystem目标系统切换或重分配失败210.53%4Handover/Relocation Target not allowed不允许切换或重分配目标00.

25、00%5Unknown Target ID未知目标ID00.00%6Target Cell not available目标单元不可用00.00%7No Radio Resources Available in Target Cell目标单元中没有无线资源可用60.15%8Failure in Radio Interface Procedure无线接口流程失败40.10%9Permanent session leg establishment error永久会话建立失败00.00%10Temporary session leg establishment error临时会话建立失败00.00%从

26、上表可见，10种srvcc-cause中，目前共出现了 1、2、3、7、8五种cause,其余5种没有出现过。其中srvcc-cause=1、2出现的次数最多，构成了 Sv 口失败的主要原因。为此，我们结合VoLTE信令监测系统、贝尔IMS镜像消息，对以上5种cause依次进行了详细分析。3. srvcc-cause=1 未指定）出现srvcc-cause=1的情况非常多，是本次分析的重点。利用Sv接口分析程序， 我们提取了所有与之相关的用户号码、STN_SR等信息。通过对比发现，这些失败切换的STN_SR都不是重庆本地 STN_SR( 13746832/13746833 )。再对比对应的 用

27、户号码，发现存在 2种不同的失败场景：a. 失败场景1：用户号码也不是重庆号段，且以浙江、北京、福建等省的号段居多。联想到春节期间发现的部分外省用户在重庆进行eSRVCC切换失败的案例，可以认定srvcc-cause=1就是相同的情况。具体场景如下：当采用华为scc as设备省份的volte用户漫游至重庆发起注册时，由 于贝尔IMS核心网设备会把自身内部的IP地址都加入到注册消息的Via字段中，最终导致Via字段长度超过1024字节，超出了归属省华为 SCC AS 的处理限制。因此SCC AS处理本次注册失败，这就导致华为 SCC AS无法刷新MME 上保存的STN_SR号码。因此，MME上保

28、存的仍然是之前的旧 STN_SR 而不是用户当前注册的重庆 SBC/ATCF对应的STN_SR。这样，当用户发起 eSRVCC时，MME发给eMSC还是旧STN_SR，显然无法路由到当前的重庆 SBC/ATCF上，因此切换必然失败。b. 失败场景2:用户号码属于是重庆号段(出现的概率较小)。具体场景如下：重庆volte用户原先在外省注册，后返回重庆，附着在重庆的mme上。重庆MME没有选择重庆本地 PGW，而是仍然选择外省 PGW。根据VoLTE 附着和注册流程，该用户将向外省SBC/ATCF发起注册。注册完成后，外省 SBC/ATCF对应的STN_SR将刷新到重庆 MME上保 存。这样，当用

29、户发起 eSRVCC时，重庆MME发给重庆eMSC的将是外省的STN_SR。按照集团公司目前的切换流程规范，eMSC是无法通过长途SSA最终路由到外省SBC/ATCF的，因此切换将会失败。c.失败原因：2种场景下，eMSC都无法路由到当前的注册SBC/ATCF，导致eMSC向目标MSC发出BICC_REL消息，提前终止了无线切换流程。对SRVCC切换完成率的影响：由于eMSC下发了异常的 SRVCC PS to CSResponse,因此将会影响 SRVCC切换完成率。对SRVCC切换成功率的影响：由于eMSC没有下发 SRVCC PS to CSComplete，因此将会影响 SRVCC切换

30、成功率。d.解决思路：1） 场景1：此场景属于外省华为 SCC AS与重庆贝尔IMS设备的配合问题， 前期我们已将此问题发至集团公司进行判责。3月3日集团公司已反馈判责结果，要求华为 SCC AS进行整改。预计此问题得到解决后，重庆的 eSRVCC切换成功率指标将有大幅提升，同时极大改善外省漫入VoLTE用户的使用感知。2） 场景2：此场景属于EPC附着时MME对PGW的选择机制问题（目前已知爱立信MME存在这种情况，华为MME不存在）。解决思路也有2种：a）爱立信MME修改选择机制。改为始终选择重庆本地 PGW，这样UE 就不会注册到外省 SBC/ATCF上。b）完善目前的切换流程规范。在各

31、省的SSA上制作本省STN_SR的字冠分析数据，落地到本省的eMSC上。这样对于外省的STN_SR，也 可以通过本省 eMSC-本省SSA-外省SSA-外省eMSC-外省ATCF的 路由找到当前 ATCF。同时，还需补充统计算法，将此场景下eMSC收到SSA返回的BICC_ANM 视同收到SIP_200消息，记作一次切换 成功。4. srvcc-cause=2（取消切换）除去前面分析的 srvcc-cause=1的情况以外，srvcc-cause=2 （取消切换）是 Sv口最多的失败原因，影响eSRVCC切换成功率5%左右。a. 失败场景:srvcc-cause=2发生时，都是 eMSC发出&

32、quot;PS to CS ResponsW'消息后，随后又 收到 MME 发来的 SRVCC PS to CS Cancel Notification 消息。192016-03-07 10:17:19.532>GTF MSG SRVC C PS TO CS REQ202016-03-07 10:17:20.017GTP MSG SRVCC PS TO CS RSP212016-03-07 10:17:21 1282-GTP_M SG_SRVGC_PS,TO cs_cance l,ntfE22016-03-07 10:17:21 133<QTP MSG SRVCC P3 T

33、0 CS CANCEL ACKb. 失败原因：对比正常的切换流程， 当UE成功接入到目标2G小区时，目标BSC会通过目标MSC通知源侧的eMSC，eMSC收到后就会下发 SRVCC PS to CS Complete。在 srvcc-cause=2的场景下，eMSC并未收到目标侧发来的UE接入2G成功的消息，而是收到 MME发来的SRVCC PS to CS Cancel Notification 消息，表明 UE应该是 在没有成功接入目标 2G小区。对SRVCC切换完成率的影响：由于eMSC下发了正常的 SRVCC PS to CS Response,因此不会影响 SRVCC切换完成率。对S

34、RVCC切换成功率的影响：由于eMSC没有下发 SRVCC PS to CSComplete，因此将影响SRVCC切换成功率。c. 解决思路：根据前面的分析，需要无线专业进一步分析UE未成功接入目标2G小区、同时取消切换的原因。5. srvcc-cause=3（目标小区切换失败）srvcc-cause=3 （目标小区切换失败）出现的概率较小，对eSRVCC切换成功率 的影响在1%以下。a. 失败场景：对于这种无线切换失败的场景，我们利用Sv接口分析程序，获取到相关的目标小区；同时，根据程序获取的切换用户号码、切换时间等信息，在贝尔IMS系统的接口镜像消息包中提取到用户呼叫时所在的4G小区信息，

35、一并发给 volte联合办公组的网优同事进行分析。网优同事初步分析后反馈，怀疑是在4G小区上定义了错误的相邻 2G小区信息，导致了切换最终失败。b. 失败原因：怀疑是在4G小区上定义了错误的相邻2G小区信息，导致了切换最终失败。对SRVCC切换完成率的影响：由于eMSC下发了异常的 SRVCC PS to CS Response,因此将会影响 SRVCC切换完成率。对SRVCC切换成功率的影响：由于eMSC没有下发 SRVCC PS to CSComplete，因此将会影响 SRVCC切换成功率。c. 解决思路：目前网优部门正在全网进行清查，排查此类定义了错误相邻 2G小区信息的情况。6. s

36、rvcc-cause=7（目标小区资源不可用）srvcc-cause=7 （目标小区资源不可用）出现的概率也较小，对eSRVCC切换成功率的影响在1%以下。a. 失败场景：从cause的解释可以看出，是由于目标小区的无线资源不足，导致UE无法接入目标小区，导致无线切换失败。b. 失败原因: 目标小区的无线资源不足，导致切换失败。对SRVCC切换完成率的影响：由于eMSC下发了异常的 SRVCC PS to CS Response,因此将会影响 SRVCC切换完成率。对SRVCC切换成功率的影响：由于eMSC没有下发 SRVCC PS to CSComplete，因此将会影响 SRVCC切换成功

37、率。c. 解决思路：对于这种目标小区资源不可用的场景，我们将获取到相关的目标小区，发给volte联合办公组的网优同事进行分析和处理（如扩容等）。7. srvcc-cause=8（无线接口流程失败）srvcc-cause=8 （无线接口流程失败）出现的概率很小，对eSRVCC切换成功率的影响在0.5%以下。a. 失败场景：此cause的解释较为含糊，且出现的次数较少，故对此失败暂未总结出很明确的场景。b. 失败原因：暂未定位。对SRVCC切换完成率的影响：由于eMSC下发了异常的 SRVCC PS to CS Response,因此将会影响 SRVCC切换完成率。对SRVCC切换成功率的影响：由

38、于eMSC没有下发 SRVCC PS to CSComplete，因此将会影响 SRVCC切换成功率。c. 解决思路：暂未定位。从以上对Sv 口各种主要失败原因值的分析，我们可以看到：目前影响最大的是外省漫游入访volte用户的切换问题。此问题已明确了解决方案，待外省华为 see as改造后即可解决。影响其次的是 切换取消问题。此问题需要网优部门深入分析，定位切换被取消的原因并确定相应的对策。其余3种失败场景占比较小， 待网优部门排查完相邻小区的错误，同时保证2G小区资源充足，可将对指标的影响控制在可接受范围内。另外，Sv 口的消息主要是完成 UE从4G到2G的无线切换，因此 Sv 口的消息与A接口的2G切换信息类似，而且两者的失败原因值也基本是相互一致的。下面将Sv 口和A接口切换消息进行类比:A接口切换消息Sv接口切换消息消息方向消息方向HANDOVER REQUIREDBSC-MSCGTP_MSG_SRVCC_PS_TO_CS_REQMME-eMSCHANDOVER COMMANDMSC-BSCGTP_MSG_SRVCC_PS_TO_CS_RSPeMSC-MMECLEAR COMMANDMSC-BSCGTP_MSG_SRVCC_PS