|
楼主 |
发表于 2007-11-5 12:18:16
|
显示全部楼层
RE:中国移动软交换IP承载语音业务的实现
同样的需要在CE上划分VPN,逻辑上隔离不同的业务应用。CE需要支持多VRF以分离各种业务数据流,通过LAN Switch的VLAN ID映射到路由器的不同VRF上(由于各种业务分别在不同VLAN,因此映射到不同VRF),通过此方式在交换机和路由器上隔离信令、媒体、网管、计费等数据流。CE与AR之间运行两个OSPF进程,分别用于信令流VRF和媒体流VRF。
由于CE启用VRRP协议,当CE故障,也立即产生VRRP切换,保证业务的正常进行。VRRP可以设置fast-interval至100ms,中断的时间在300ms左右,如不调整VRRP定时器值,缺省情况1s左右完成切换,推荐使用VRRP缺省配置。
2、网络性能测试评估
按照上述组网方法,我们在湖南的吉首和怀化两地搭建了相应的实际网络。MSC Server和MGW采用中兴公司的ZXWN系统,CE采用Juniper公司的M10i路由器,AR选用阿尔卡特公司SR 7750路由器,LAN Switch用的是中兴公司的ZXR10 3928。使用Autoload(大话务发生器)、Cloud(IP损伤发生器)、Ethereal(Nc、Nb和Mc接口抓包和解码)、HRping(测试路由收敛时间)、GL-VQT(测试客观语音质量)等工具对网络进行了全面的测试以验证其性能。
测试组网图如图6所示。
图6 测试组网图
呼叫模拟器模拟A接口,发起的呼叫,话务量为10CAPS局间呼叫和4CAPS局内呼叫,呼叫时长统一为60s。用HRping测量故障收敛时间。
测试分5大部分:(1)故障对业务的影响;(2)IP接口网络损伤测试;(3)语音质量测试;(4)系统功能测试;(5)系统兼容性测试。
2.1 故障对业务的影响(如表2所示)
表2 测试情况
从测试结果来看,由于采用了多种保护机制,不论系统发生何种故障均没有发生呼叫业务中断的情况。说明该网络拥有非常高的可靠性。
中兴软交换设备信令流Mc、Nc接口开启SCTP多归属保护,对每个SCTP偶联的端点有两个IP地址,两个地址配置在负荷分担的SIGIPI接口板上,共有两个物理通路。主用通路为接口板1-LAN Switch1-CE1-AR1,备用通路为接口板2-LAN Switch2-CE2-AR2。
当主用接口板到LAN Switch 1间链路故障时,SCTP多归属起作用,数据经备用板、备用通路重传,主用通路的重传达到5次,发生SCTP多归属倒换,链路故障消失后,数据会倒回到主用通路上。在这个过程中,可以看到SCTP的倒回。
当主用通路LAN Switch1和CE1间链路故障时,发生VRRP收敛,在VRRP收敛过程中,主用通路的数据在备用通路上重传,VRRP收敛完成后,数据倒回主用通路。在这个过程中,可以看到SCTP的跳变。
当主用通路上的CE1、AR1故障时,发生承载网动态路由的收敛,在收敛过程中,主用通路的数据在备用通路上重传,路由收敛完成后,数据倒回主用通路。在这个过程中,可以看到SCTP的跳变。
备用接口板故障,只会产生偶联备用通路断链,对主用通路上的信令流不会产生影响。
在备用通路上的LAN Switch故障、CE2故障不会对主用通路上的信令流产生影响。
中兴软交换设备Nb口媒体流采用两块IPI接口板,配置为主备方式,支持负荷分担,当主用单板接入链路故障时,立即发生倒换,未发现对局间呼叫业务有影响。
CE1和CE2配置了VRRP,VRRP虚地址作为MSC Server信令流和MGW的网关。媒体流在CE1上主用,当CE1故障(或LAN Switch故障或VRRP心跳通路故障时),CE2转为主用,对呼叫业务不会产生影响。
当承载网内的路由器间故障时,发生路由收敛,路由收敛过程中产生的丢包未发现呼损。
LAN Switch故障测试,使得系统配合VRRP进行使用。隔离了CE和站点软交换之间的关联,不论VRRP如何浮动,与站点相关性都会比较小,使得CE真正的独立进行备份。
2.2 IP接口网络损伤测试(如表3所示)
表3 IP接口网络损伤测试
接口 参数 呼损 备注
Mc接口 AF41,时延、抖动和丢包率分别为(40ms,5ms,0.5%) 0
60ms、10ms、0.5% 0
80ms、10ms、0.5% 0
100ms、10ms、1% 0
Nc接口 40ms、5ms、0.5% 0
60ms、10ms、0.5% 0
80ms、10ms、0.5% 0
100ms、10ms、1% 0
Nb接口 40ms、5ms、0.5% 0
60ms、10ms、0.5% 0
80ms、10ms、0.5% 0
100ms、10ms、1% 0
参数均为时延、抖动和丢包进行罗列。
表4 语音在IP承载上的理论带宽参考
启用VAD(激活因子参考0.6) 不启用VAD
AMR 12.2kbit/s 29.5kbit/s 45.5kbit/s
G.711,5ms 120.8kbit/s 195.6kbit/s
G.711,10ms 81.5kbit/s 130kbit/s
G.711,20ms 64.8kbit/s 97.2kbit/s
参数均为时延、抖动和丢包进行罗列。
表4 语音在IP承载上的理论带宽参考
测试项目
次数 测试项目 备注
IP承载的软交换端局局间(语音编解码采用AMR2 12.2kbit/s,开启VAD) 1 优
2 优
3 优
IP承载的软交换端局局间(语音编解码采用AMR2 12.2kbit/s,关闭VAD) 1 优
2 优
3 优
IP承载的软交换端局局内(语音编解码采用G.711,开启VAD) 1 优
2 优
3 优
IP承载的软交换端局局内(语音编解码采用G.711,关闭VAD) 1 优
2 优
3 优
IP承载的软交换端局局间(语音编解码采用G.711,开启VAD) 1 优
2 优
3 优
IP承载的软交换端局局间(语音编解码采用G.711,关闭VAD) 1 优
2 优
3 优
IP端局到TDM端局的呼叫 1 优
2 优
3 优
IP端局到TDM端局的切换 1 优
移动用户呼叫PSTN 1 优
2 优
参数均为时延、抖动和丢包进行罗列。
在Nc、Nb和Mc接口分别增加模拟损伤仪表,时延、抖动和丢包达到最大的100ms、10ms、1%,没有呼损产生。中兴软交换设备在Nc、Nb和Mc接口的抗干扰满足要求。在启用SCTP多归属的情况下,为业务的正常进行提供了更多的保障。
2.3 语音质量测试
2.3.1 主观语音质量测试(如表5所示)
表5 主观语音质量测试
测试项目 语音质量(20组的平均值) 备注
IP承载的软交换端局局内(语音编解码采用G.711,关闭VAD) 3.2
IP承载的软交换端局局内(语音编解码采用G.711,开启VAD) 3.12
IP承载的软交换端局局间(语音编解码采用AMR2 12.2kbit/s,关闭VAD) 3.05
IP承载的软交换端局局间(语音编解码采用AMR2 12.2kbit/s,开启VAD) 3.03
IP承载的软交换端局局间(语音编解码采用G.711,关闭VAD) 3.1
IP承载的软交换端局局间(语音编解码采用G.711,开启VAD) 3.09
TDM端局局间呼叫语音质量 3.11 传统TDM交换网的语音质量
测试表明关闭VAD和打开VAD的差异很小;建议在以后的实际网络中使用VAD的方式。通过使用静音监测来减少了网络的流量。
测试表明使用G.711和使用AMR2 12.2kbit/s,主观感觉上差异很小;建议在以后的实际网络中使用AMR2 12.2kbit/s的方式,从而减少网络的流量。
2.3.2 客观语音质量测试(如表6所示)
表6 客观语音质量测试
打开和关闭VAD对语音质量的影响比较小,但是对于网络流量的传输会比较大;打开VAD,等于为语音增加了一个激活因子,如果以激活因子0.6来计算,则会减少约30%的带宽,因此建议开启VAD功能。
利用仪器直接测试现网,数值为3.11;因为本次测试使用的是室内实验室功率很小的基站,如果忽略这个因素对语音质量的影响,则移动软交换端局和移动TDM端局基本一致,从客观语音评测的角度来看,移动软交换端局的IP承载,并不会降低原有TDM的语音质量。
2.3.3 语音质量测试结果
采用中兴软交换架构的核心网,对于局内软交换语音质量没有影响,基本与现网一致或略高。
对于局内,打开和关闭VAD,对客观话音质量评价的结果影响较小。
对于局间采用AMR2和G.711,打开和关闭VAD,对话音影响也是很小;考虑IP承载后的网络间话音流量,建议采用AMR2,并打开VAD。
2.4 系统功能测试
系统功能测试就是在软交换IP承载网上测试所有中国移动现在已经开展的各种业务。通过对所有业务类别进行测试(在此不一一列出)之后验证了软交换IP承载网完全能够支持所有业务的承载,而且能够达到或超过传统TDM网的性能水平。
2.5 设备兼容性测试
在上述测试的基础上,我们还在中国移动统一组织下实施了第二阶段测试:同一省内不同的软交换设备厂家之间的IP承载语音的测试,验证了不同软交换设备之间完全能够在IP承载网上实现各种业务的互通;在此之后进行了第三阶段测试:跨省测试。通过在省际层面引入CMN(呼叫协调节点),来完成全网被叫号码分析及省际软交换机之间信令链路的汇聚,验证了全国软交换之间及全国软交换和TDM局之间在IP承载网上业务互通的能力。以上所有的测试都得到了优良的测试结果。
3、结束语
通过3个阶段的现网测试,充分验证了中国移动软交换IP承载网系统的可靠性及承载业务的能力。按照该方案建设的核心网完全能够达到电信级网络的运行要求。而且,中国移动也将从今年开始在全国推广该方案,以完成传统TDM网到下一代网络的演进,为将来用户多样化、个性化的业务需求提高强大的网络支撑能力。 |
|