关键词：WCDMA语音；存在问题；研究
1 语音传递相关过程
在WCDMA系统中，语音业务使用三个数据子流进行传递，RNC会针对这三个子流分配三个传输信道，分别对其进行加、解密，每个子流中的比特数对应为DCH传输块大小，TTI为20ms，AMR语音子流的结构如表1。
表1
对于语音业务，在不通话期间为了防止给人以通话中断的感觉，采取的措施是发送描述背景噪音的静默帧（SID），在接收端根据静默帧恢复出背景噪音。处理规则是：当检测到语音静默开始，后面连续7个20ms照旧发送语音帧，第8个20ms发送一个39比特帧，然后第9、10连续两个20ms不发送数据，第11个20ms开始发送一个39比特静默帧，然后连续7个20ms不发送帧，然后再发送一个39比特帧，以后都是每8个20ms中有一个39比特帧，直到在某个20ms中检测到语音，立即停止DTX状态，开始发送语音帧。可以通过下面的图参考一下，每个格子代表20ms中发送的一个帧，在最前面检测到语音静默。如表2所示。
表2
注：S为正常语音帧；F为第一个静默帧39bits；N为空帧0bit；U为更新的静默帧39bits。
另外语音在传递过程中会在空口进行加密，加密过程会涉及加密算法中一些相关参数，这些参数的变化有时也会引起语音质量的问题。WCDMA的空口加密算法如图1。
与完整性保护算法类似，CK由核心网在Security Mode Command消息中给出，并在终端和核心网中同时保存；COUNT-C由HFN和RRC消息的序号SN构成，而HFN从业务建立过程中RRC连接最后一条消息RRC CONNECTION SETUP COMPLETE消息中得到；DIRECTION为了避免上下行加密算法的输入内容出现相同，上行设置为0，下行设置为1；LENGTH用于指示生成的Keystream的长度；BEARER是每个无线承载的标识，用于区别所有无线承载使用同一组加密参数；最终根据f8算法计算出一个结果，这个结果会应用于需要加密的数据从而完成加密过程。
其中COUNT-C的结构可以分为确认模式、透明模式和非确认模式三种情况，如图2所示。
图2
对于语音业务而言，其RLC层采用的是透明传输模式，COUNT-C共32位，低8位的CFN在UE和RNC的MAC-d中维护，高24位为HFN，会随着CFN的周期而增长。
2 语音异常问题
2.1 由于加密不一致导致的流水声问题
3GPP R99/R4、R5 200403之前协议对于TS25.331 8.6.4.3/8.6.6.28的描述本身存在缺陷：8.6.4.3描述HFN使用RB SETUP COMPLETE消息中CS域的START值初始化后直接使用；但是8.6.6.28描述HFN在使用RB SETUP COMPLETE消息中CS域的START值初始化后还需要加1后才使用。
If the IE "Downlink DPCH info common for all radio links " is included in a message used to perform a Timing re-initialised hard handover， and ciphering is active for any radio bearer using RLC-TM， the UE shall， after having activated the dedicated physical channels indicated by that IE： increment HFN for RLC-TM by '1'。
而对于RB DRD过程，R5版本前后分别属于RB配置过程和硬切换过程，在R5版本前，在协议中，没有明确这个过程是属于RB阶段还是硬切换过程，可是对于加密参HFN来说，在RB阶段解密参数HFN不需要加1，而在硬切换过程中加密参数HFN需要加1，由于各个终端对协议理解上的不同，这里会出现终端和网络侧HFN不一致。有些厂商认为RB DRD阶段是一个硬切换阶段，所以HFN加1了，如果某些终端认为RB DRD过程是一个RB阶段HFN不加1，导致终端和网络侧维护的HFN不一致，出现流水声。由于各款终端和网络侧的实现不匹配、加密参数配置不一致导致的语音流水声属于协议本身的冲突，之后3GPP通过CR2284R1澄清，修改8.6.4.3描述，保持与8.6.6.28的处理一致，也就是说HFN加1后使用，来消除语音中流水声的问题。
如下例中所示，R5版本之前的终端在RB建立过程中没有对HFN进行加1，图3。
图4
2.2 由于传输时延导致的流水声
语音业务通话过程中，由于IUB接口传输时延突发变大，造成大量下行数据帧延迟到达，并且落在NodeB的时间窗外，NodeB检测到之后给RNC发送大量负的时间调整帧，使得RNC频繁对所维护的下行CFN（Connection Frame Number）作调整，当下行CFN超过上行数据帧中使用的CFN一圈后，由于解密出现错误而导致语音流水声问题。
所以对于同步系统而言，UE在物理信道重配置完成消息里携带的激活时间至少比UE发送时刻的CFN大200，并且是8的倍数。这主要是为了考虑到IUB口传输有较大的时延，有些终端可能没有考虑到导致在IUB口有较大传输时延的情况下出现加密参数HFN网络侧和UE侧维护的不一致，引入流水声。
2.3 与终端兼容性问题导致单通和静音
在拥塞小区用户拨打非拥塞小区用户过程中，如果小区打开AMRC功能，在拥塞的时候用户接入会进行降速，以保证速率4.75kbps进行接入，这样就会触发高通某些老款终端的bug，高通会把速率低于10.2kbps时的语音数据从3个传输信道重配置至2个信道，但网络侧分配一直都是3个子流3个传输信道，这样就会导致UE侧MAC层接收数据包后出现异常，最终编解码后表现为单通。
另外一种情况是高通某些版本终端在满足AMRC条件时会发起上行速率调整，当RNC通过UU口发送TFC控制消息给UE要求其调整到目标速率时，RR/MAC层在向上层递交消息的过程存在问题，导致UE在应用层按照12.2kbps的速率进行编解码，但到了MAC层后却会将12.2kbps的速率帧全部丢掉，最终出现静音。
2.4 扰码冲突导致流水声
由于Node B链路的CFN是根据RNC下发参数frameoffset、chipoffset等计算出来的，NodeB在进行FP组包时获取自己所维护的CFN值填入FP包中，RNC在进行多条链路的FP包合并时会根据该CFN进行合并。如果两个更软合并链路的帧偏移相差太大，会导致两条链路CFN计算不一致，从而导致FP包中携带的CFN参数突变。
NodeB侧CFN突变会引起以下两个问题：RNC侧的上行MDC合并根据CFN进行，异常的CFN导致合并失败，从而引起丢包，由于是部分丢包，所以UE侧的效果可能是噪音；RNC侧的加解密参数HFN会根据CFN进行相应的变化（每个CFN周期255结束HFN递增），异常的CFN导致异常的HFN，HFN错误就引起加解密错误，从而引起流水声，而在正常情况下，两条更软合并链路的fram
eoffset应该是相等或只相差一的，由于frameoffset以及chipoffset是UE根据RNC所配邻区的基准定时进行测量上报的，而扰码则是UE区分小区的依据。如果出现扰码冲突，UE测量时采用另一个相同扰码小区的基准定时，不同基站之间的定时相差较大，这就会使UE上报与原链路相差较大的frameoffset以及chipoffset值，导致NodeB侧CFN突变，进而引起流水声。
2.5 其他原因导致的单通问题
掉话产生的假单通问题：通话过程中因为质量差，发生了一侧掉话的情况，另一侧需要等到手机一定时器超时才能释放电路，此时该侧用户听不到任何声音，感觉象单通，实际为掉话；如果用户不主动拆链，最终会产生掉话，大部分发生掉话的另一侧用户可能主动挂机。
手机电量低导致的单通情况：该影响产生的单通为电量低手机的通话对方；另外还可能导致掉话，一般电量低的客户坚持一段时间后会主动关机。
Iu接口中继链路问题：Iu 接口中继链路如果存在问题（如：鸳鸯线问题）可以导致一个通话的来去两路话音中，有一路可以送达对端，而另一路不能正确的送达对端，引起单通。通话过程中，呼叫切换时如果被分配到有问题的Iu接口中继的时隙上，将导致该呼叫在通话中突然发生单通。这样整个基站控制器管辖区域下将出现一定比率的单通。
上下行干扰问题：如果一个小区上行或下行受到严重干扰，那么呼叫切入时，就可能导致质量好的一个方向听得到声音，而质量差的另一个方向听不到声音，形成单通。当然，也有可能是在没有任何切换的情况下，手机逐渐远离基站或进入室内，接收电平变差，一个方向的接收质量先于另一个方向恶化，形成通话中的单通。
分布系统的干放引起的单通问题：分布系统的干放对分布系统覆盖区域中所有的上行和下行信号进行放大，再传送到基站。如果干放中的上行或下行放大器存在问题，或放大参数存在问题，将导致一个方向的信号被正常放大，而另一个方向的信号不能被相应正常的放大。呼叫切入时，将导致单通现象。
手机元器件问题：有些手机使用年限长了，一些电子元器件老化，可能导致通话时扬声器不发声或麦克风不传声的问题。这种问题如果在通话过程中发生，将导致通话中的单通现象。
其它的手机问题：现在网络中手机的种类越来越多，由手机引发的问题也越来越多。部分手机的问题十分隐蔽，而且往往和特定的网络功能有关，不容易查找。
用户误操作问题：有些高端手机，在通话时手机屏幕上有静音按钮（部分手机为触摸屏手机），用户在通话时容易不经意的碰到该键，引起单通。
3 结束语
本文旨在讨论和汇总3G网络相关语音类问题，其中涉及到流水声、杂音、单通等现象，网络中的这些现象在很多情况下会极大的影响用户的使用感受，对品牌的提升和业务的正常使用产生较大的负面效果。文中所汇总的只是在现有经验基础上得出的相关结论，由于异常语音类问题涉及端到端的整个过程，定位和分析都极其复杂，因此不能排除本文之外的其他场景导致的异常情况的出现。在网络发展过程中出现类似问题，本文可以为分析和解决问题提供一种思路。
