异系统切换中的并发业务（Multi-RAB）掉话研究和优化

谭永全

（中国联通广东省分公司 广州 510627）

WCDMA网络以其优越的3G制式，给用户带来前所未有的体验感受，高速的上网速率、丰富多彩的增值业务是吸引用户的重要因素。而且WCDMA支持多业务同时进行，可以实现话音与上网同时使用，在WCDMA通信术语中通常叫做Multi-RAB，中文一般叫并发业务。

但目前由于3G处于建网初期，网络覆盖不完善，WCDMA网络暂时不能实现连续覆盖，所以在WCDMA信号较差时需要切换到2G网络，就涉及到2G/3G互操作的问题，由于GSM网络不支持多业务同时进行，这就引出本文的研究课题。本文就并发业务（Multi-RAB）在进行2G/3G互操作时造成的掉话进行分析和研究，找出异系统切换时造成掉话的原因并给出调整建议。

1 研究背景

目前中国联通的WCDMA语音掉话率的目标值为 0.7%，图1为广东某地市（下称A城市）的CS域掉话率走势，由于目前用户基数较少，在完成邻区优化后掉话发生的小区仍比较分散并且有部分日期不达标,关于掉话率的分析我们在下文中做了进一步研究。

此地市为爱立信设备，RNC版本是CXP9012995_R6EB/32 P7.0。

2 问题分析定位和解决措施

2.1 KPI分析

A地市从2010年04月15～25日晚忙时在KPI统计中总共有132 次语音掉话。通过爱立信的优化工具GPEH跟踪同一时间段中找到了134次语音RAB相关的system release事件，从GPEH的事件来分析掉话的原因。

图2 语音RAB相关的system release事件分布

从图2中可以看出大约20%的掉话是在 Multi-RAB的情况下发生的，也就是多业务并发的时候发生。由于其它80%的掉话比较分散，每天的掉话小区都没有规律性，而且在一个小时内的掉话非常少，很难在短期内解决。对于掉话率的优化考虑在20%的Multi-RAB的掉话上。

通过后台信令跟踪统计发现：90%的双RAB掉话发生在CONVERSATIONAL_CS_SPEECH_12.2_12.2-INTERACTIVE_PS_64_64业务模式下。

在这些 Multi-RAB(SPEECH_12.2+PS)的system release中，大多数的原因是Unspecified。所以我们不能直接从GPEH的信息中找到掉话原因。但是如果把这些Multi-RAB 掉话事件与异系统切换（IRAT Handover）执行事件结合起来，我们可以发现两者之间有一定的联系。

从图3中可以看出，同一个Multi-RAB (SPEECH_12.2+PS)用户在做完一次异系统切换（IRAT Handover）之后，紧接着就会发生一次掉话。而掉话的原因又是Unspecified。可见异系统切换（IRAT Handover）与这些掉话之间肯定有一定的关系。为了验证这种猜测，接下来做了路测和信令分析。

2.2 Multi-RAB 路测与信令分析

首先通过模拟Multi-RAB异系统切换的场景进行了路测分析。

路测的场景是UE拨打语音电话之后开始做R99数据业务，然后在保持两种业务的情况下做异系统间切换。

路测中使用爱立信OSS系统的UETR进行后台跟踪和TEMS 做前台记录，对比两者进行分析。

从TEMS Log中我们发现异系统切换成功完成，没有掉话产生。

但在UETR中，异系统切换时的RRC和RANAP网络侧信令流程如图4所示。

在UETR中，在发生异系统切换到2G的信令后，核心网发送的IU release command信令(RAN发起的IU release request的回应) 带的cause全部都是release-due-to-utran-generated-reason。

图3 信令流程

图4 异系统切换时的RRC和RANAP网络侧信令流程

同时，爱立信的统计数据中的两个计数器 pmNo SystemRabReleaseSpeech和pmNoSystemRab ReleasePacket都发生了跳转，（注：根据KPI公式，pmNoSystemRabReleaseSpeech代表语音掉话，pmNoSystemRabReleasePacket代表数据业务掉话），Counter的值如图5所示。

RNC侧收到核心网的release-due-to-utrangenerated-reason的释放请求，认为是异常的掉话，将双RAB中的CS域和PS域都计算为掉话。按照正常的流程，由于2G不支持双RAB业务，在双RAB业务进行3G->2G的切换时，应该CS域正常切换，PS域挂起。问题定位在核心网下发的Release的原因值上。

由于无线网发Iu-ReleaseRequest（原因值为successful-relocation）后，SGSN返回Iu-Release Command消息，原因值是release-due-to-utrangenerated-reason。也就是说核心网下发的原因值与无线侧的原因值不一致。

目前广东省在广州和深圳都有SGSN，其中广州SGSN是中兴设备，而深圳SGSN是华为设备。上述的A城市是与广州的中兴SGSN相连。为了进一步验证，我们选择了连接深圳华为SGSN的B城市做同样的测试。

从B城市的测试结果看，TEMS Log中我们发现异系统切换同样成功完成，没有掉话产生。

但是UETR的网络侧信令却与A城市的结果有所不同。

在UETR中，异系统切换时的RRC和RANAP网络侧信令流程如图6所示。

在UETR中，核心网发送的IU release command信令(RAN发起的IU release request的回应) 带的cause是 successful-relocation，与无线网发的原因值一样。

并且，统计数据中的counter pmNoSystemRab ReleaseSpeech和pmNo SystemRabReleasePacket都没有跳转。

图5 Counter的值

图6 异系统切换时的RRC和RANAP网络侧信令流程

图7 信令流程

所以，在Multi-RAB的异系统切换中，如果核心网发送的IU release command信令(RAN发起的IU release request的回应) 带的cause是release-due-to-utran-generated-reason,那么即使异系统切换成功，system RAB release（指示掉话）counter还是会跳转。如果核心网发送的IU release command信令(RAN发起的IU release request的回应) 带的原因值是successful-relocation，那么如果异系统切换成功，则system RAB release（指示掉话）counter正常，不会发生跳转。

问题已经定位，是由于中兴SGSN下发的release原因值与无线侧的不一致，RNC侧认为下发的原因值为release-due-to-utran-generated-reason的释放指示后，认为是异常释放而发生掉话的计数器跳转。

查看3GPP资料，规范没明确规定在这种情况下SGSN应该返回什么原因值，但从逻辑上讲，华为SGSN的处理更合乎逻辑(华为的返回原因值与无线上报原因值一致)。

2.3 结论

从以上分析可知，在异系统成功切换之后，怀疑中兴的SGSN发送的IU release command信令(RAN发起的IU release request的回应) 带的release-due-to-utran-generated-reason cause，引起掉话计数器（pmNoSystemRabReleaseSpeech pmNoSystemRabReleasePacket）跳转的问题。

而华为的SGSN发送的IU release command信令(RAN 发起的IU release request的回应) 带的successful-relocation cause，则没有此问题。

3 解决建议

建议中兴SGSN把在异系统切换成功后回复IU release request的IU release command信令的cause从release-due-to-utran-generated-reason 改 为successful-relocation。其信令流程如图7所示。

目前已定位问题所在，也得到中兴和爱立信的双方认可。由于SGSN的修改不能通过修改参数解决，需要打补丁进行整改，目前中兴SGSN研发已列入开发计划，在下一个版本中解决。

[1]3GPP规范：TS 125413-V3.0.0

[2]张长钢, 李猛. WCDMA/HSDPA无线网络优化原理与实践

[3]爱立信参考文档：Iu Release RANAP procedure