CDMA1xEVDORevAVoIP语音容量测试方法研究.docx

?

?

ＣＤＭＡ１ｘＥＶＤＯＲｅｖＡＶｏＩＰ语音容量测试方法研究

?

?

摘要：CDMA1xEVDORevA支持VoIP业务，解决了一直为人诟病的EVDO系统无法同时支持数据和语音的问题。接下来容量问题成了备受关注的焦点：EVDORevAVoIP容量是否能和1x系统相当？VoIP容量如何测量？目前业界的EVDORevAVoIP进展还未进入商用阶段，尤其是终端进展，目前尚无成熟的DOAVoIP商用终端，测试终端数量有限，而能否用少量终端测试就可以测试出VoIP的扇区容量。

关键词：1xEVDORevA;VoIP;VoIP容量;功率开销;ROT;VoIP终端

1容量分析

根据3GPP2evaluationmethodology中的容量仿真结果，EVDORevA系统的VoIP容量是反向受限的，故本文只分析扇区反向容量和反向容量测试方法。

根据3GPP2evaluationmethodology中的定义，扇区VoIP反向容量是指在扇区ROT大于7dB的时间比例不超过1％情况下的最大用户数。（当ROT超过一定门限时，AN将启动反向负荷控制，该门限在MasterSystemParametersforIS-856-A(1xEV-DORev.A)中建议值是5.75dB。传统的测试方法就是在扇区中不断加载VoIP用户，当ROT大于7dB的比例超过1％时的用户数可以认为是达到反向扇区容量，在Figure1-1中，显示了ROT分布函数和扇区用户数之间的关系，从图中可以看到VoIP容量是44。从图中看到，用户数和ROT之间不是线形关系，所以在得到10、30个用户的ROT分布情况下无法预测ROT达到7时的用户数。

在EVDORevA系统中，业务是分优先级的，不同优先级的业务在反向负荷控制算法（T2P）中的作用效果是不同的。VoIP业务是承载在EF流（ExpeditedForwarding），是高优先级流，T2P算法保证了RLMAC调度不受反向负荷影响；FTP业务是承载在BE流（BestEffort），是低优先级流，其RLMAC调度依赖于反向负荷状况，受AN发送的RAB影响。

在扇区中BE用户和VoIP用户混合加载，VoIP用户数逐渐增加，将引起RAB置1（置1表示反向负荷过载）频率逐渐增加，RAB置1频率增加，BE用户的反向吞吐量将逐渐减小，当VoIP用户数足够大时，BE用户吞吐量将减少到零，这时BE用户只有反向Pilot信道和MAC信道发射（这些开销功率可以折合成VoIP用户数，下面会进行详细折合计算），所以此时的VoIP用户数加上BE用户开销功率折合的VoIP用户数就等于扇区的VoIP容量。以上分析结论为解决引言中的问题提供了一个思路。

2方法详解

根据上节的思路，Qualcomm的测试结果如下图Figure2-1所示，可以看到VoIP用户数和BE用户吞吐量成线形关系，当BE用户吞吐量降为零时，VoIP用户数大约达到41个，根据上节的分析，实际的扇区容量应该大于41个，因为BE用户虽然吞吐量降为零，但还有反向pilot和反向MAC信道的功率开销，下面详细分析如何将这些开销折合成VoIP用户数。

BE用户吞吐量降为0时，还有DSC、DRC、RRI和Pilot信道发射，MAC信道功率相对与Pilot信道的增益如下：

BE用户的开销功率计算公式如下：

所以4个BE用户的开销功率近似可以折合为3个VoIP用户的功率（1.92*4=2.62*3）。故实际扇区吞吐量应该是41+3＝44。这和使用第一种方法测得的结果是一致得，从而也验证了这种方法的可行性。

以下数据是Qualcomm在外场嵌入式小区中测得的一组真实数据。该测试使用了13个BE用户，24个VoIP用户，被测扇区是L-44（见Table2-2中蓝色行），其它扇区为相邻扇区。

需要说明的是，以下这组数据是在一定无线环境条件下的测试数据，仅仅是用来说明本文测试方法的可行性。

Table2-2和Table2-3分别是ROT分布与VoIP用户数之间的对应关系和BE用户吞吐量与VoIP用户数之间的对应关系：

3该方法的优点

1.从Figure2-2中可以看到，BE用户吞吐量和VoIP用户数是成线形关系的，这就为解决引言中的问题提供了契机。比如，如果我们只有24个VoIP终端，通过测试0、5、10、20个VoIP呼叫等几个点的数据，通过拟合可以得到扇区的VoIP容量，如Figure2-2所示。

2.使用这种方法，不需要在AN上进行ROT统计，只需要观察BE用户的吞吐量即可，这通过AT的log