基于MANET的语音调度系统设计与实现
2013-09-17彭生奇
徐 亮,文 鸿,彭生奇,周 恒
(湖南工业大学,计算机与通信学院,湖南 株洲 412007)
0 引言
传统的语音调度系统多采用公共交换电话网络(public switched telephone network,PSTN),其调度流程需要用户级交换机(private branch exchange,PBX)等网络基础设施的支持,系统部署周期较长,费用较高。随着VoIP技术的发展,调度系统的架构组成发生了重要变化。无线传输数据具有安装方便、灵活性强等优势,因此,利用WiFi等技术进行语音数据传输的应用越来越广泛[1]。但该类调度系统需部署无线转发节点,依赖移动电话网络时使用范围受限,运行成本较高,在灾害救援、战场调度场景下无法实施。移动无线自组织网络(mobile ad-hoc networks,MANET)技术可克服这些不足。MANET是一种数据包多跳传输的网络,网络中的节点地位都是平等的,都可充当周围节点数据包的转发节点[2],利用这种机制可以延长网络的传输距离。
本文运用VoIP技术,采用MANET承载语音数据,设计和实现了无线语音调度系统。该系统不需要专门的调度机和调度台,其功能完全由调度终端完成,无需固定转发节点,具有布网迅速、抗毁性强、链路冗余等优势。
1 会话发起协议(SIP)
会话发起协议(session initiation protocol,SIP)是一个由Internet工程任务组(Internet Engineering Task Force,IETF)的多方多媒体会话控制(Multiparty Multimedia Session Control,MMUSIC)工作组开发的应用层信令控制协议,作为标准提议用于建立、修改和终止包括视频、语音、即时通信、在线游戏和虚拟现实等多媒体元素在内的交互式会话协议[3]。
SIP是用于VoIP技术最主要的信令协议之一,其系统由4种元素组成,即用户代理、SIP代理服务器、重定向服务器以及注册服务器[4],图1显示了各个功能组件在网络中所处的位置。用户代理(user agents,UA)是一个发起和终止会话的实体;代理服务器与重定向服务器及位置服务器相连,为UA提供代理服务,完成SIP消息的路由转发功能;重定向服务器与位置服务器相连,使用轻量目录访问协议(lightweight directory access protocol,LDAP),将用户新的位置信息返回给呼叫方;位置服务器就是一个数据库,用于存放终端用户当前的位置信息,为SIP重定向服务器或代理服务器提供被叫用户的位置信息;用户将其信息在注册服务器注册,表明该用户加入了SIP网络,注册服务器可以支持鉴权功能。
图1 SIP网络的基本构成Fig.1 Basic framework of SIP network
2 最优化链路状态路由协议(OLSR)
MANET网络主要有两类路由协议,一类是表驱动路由协议,另一类是按需路由协议。采用按需路由协议,网络中信源结点在向信宿发送数据包时,当源端没有到达目的端的路由时才启动路由发现过程,在对时延要求严格的语音调度系统中,此类路由协议不适用。表驱动路由协议由结点周期性地发送Hello报文,随时更新邻居结点的链路状态,网络中的每个结点有整个网络的全部或大部分路由信息,在承载语音数据时,报文传输时延较小,接近有线网络[5],能满足语音调度系统对时延的要求。虽然周期性地广播Hello数据包加快了路由更新,但浪费了MANET宝贵的带宽资源,同时增加了无线调度终端的电池耗电量。
最优化链路状态路由协议(optimized link state routing,OLSR)采用有别于传统表驱动路由协议的拓扑更新机制,周期性地发送Hello数据包,或当检测到网络拓扑发生变化时,只选择被作为多点中继(multipoint relays,MPR)节点的邻居节点,进行拓扑数据包的转发,这种机制可以避免广播方式下数据包在网内大量传播[6]。如在图2的网络拓扑结构中,只有1号和3号结点转发0号结点的拓扑更新报文,这极大地减少了全网控制报文流量。
图2 OLSR拓扑更新包传输Fig.2 The transmission of OLSR topology updating packet
OLSR有多种实现方案,本文采用olsr.org OLSR daemon[7],该版本能实现OLSR的全部功能,支持IPv4和IPv6,在Linux和Windows操作系统上都可运行。
3 语音调度系统终端平台
SIP采用Client/Server结构的通讯机制,对呼叫的控制是将对信令的控制消息封装到消息的头域中,通过消息的传递来实现。因此,SIP系统中的终端就比较智能化,其不只是简单地提供数据,还提供了对呼叫的控制消息,这样就将网络设备的复杂性推向了终端设备,对终端硬件提出了更高的要求。
3.1 终端平台硬件组成
语音调度系统终端平台硬件构成见图3,包括ARM CPU控制模块、无线模块和音频处理模块等。
图3 语音调度系统终端平台硬件组成Fig.3 The hardware components of terminal platform
S3C6410模块是三星公司基于ARM1176处理器而研发的16/32bit、高性能低功耗的精简指令集计算机(reduced instruction set computing,RISC)通用微处理器,其运行速率达667 MHz,集成有2块128 MB的mDDR和1块1 GB的 NAND Flash,适用于手持、移动等终端设备。
S3C6410模块设有优化的外部存储接口,该接口能满足在高端通信服务中的数据带宽要求,接口分为两路,即DRAM和Flash/ROM/DRAM端口。终端平台采用的无线通信模块为AzureWave公司研发的GM320,该模块支持802.11 b/g协议,理论传输带宽最大达150 Mbps,完全能满足调度系统的音频传输带宽要求。音频处理模块WM9713负责完成音频信号的A/D, D/A转换。
3.2 终端平台软件设计
语音调度终端平台软件系统包括上层用户界面(user interface,UI)、liblinphone动态库、OLSR、硬件驱动程序等,其构架见图4。liblinphone动态库是软件系统的核心,提供语音数据传输功能接口,上层UI操作这些功能接口便可实现全部的语音调度行为。
图4 语音调度系统终端平台软件架构Fig.4 The software architecture of terminal platform
终端平台软件系统选用Linux操作系统作为应用程序和底层硬件之间的桥梁,可以更直观地在其网络层进行编写和修改[8],能满足调度系统对时效性的要求。OLSR在Linux操作系统的用户空间完成,该空间与操作系统的内核空间是相互独立的,实现的OLSR路由功能不会过度依赖于操作系统内核,也不会对系统的正常运行产生负面影响。
3.3 调度终端功能模块
调度终端系统平台由单呼和会议2个组件构成,特定组件中包含具体的功能模块,如图5所示。
图5 平台功能模块Fig.5 Platform functional modules
在一对一的通话时采用单呼模式,在该模式下,呼叫方只需在自己的操作界面上输入被呼叫方的编号,实际运用过程中可以是对方的工号等信息,然后执行呼叫操作即可。当2个拥有低级别权限的终端在通话中时,任一拥有高级别权限的终端可以发起强插、强拆操作,对通话过程进行干预。
在会议模式下,发起会议的操作者默认是会议的管理者。会议初始阶段,根据实际需要,选择被呼叫方编号,对会议参与者的呼叫是单呼模式下呼叫的重复过程,被呼叫方只需在自己的终端平台界面选择接受即可进入会议室,也可以选择齐呼模式,这时该终端周围所有的节点都会收到加入会议的提示信息。会议的管理者可以根据实际情况对处于会议中的用户执行踢除、静音和恢复等操作。图6为会议模式下系统工作流程图。
图6 会议操作流程图Fig.6 The flow chart of conference operation
终端操作界面采用QT的嵌入式版本Qt/E来实现。Qt/E是一个专门为嵌入式系统设计图形用户界面的工具包。操作者在UI界面上输入命令,由底层的liblinphone库完成功能实现。
调度平台的会议模式终端界面如图7所示。
图7 会议模式终端界面Fig.7 The conference user interface
在实际操作过程中,每台终端都存储了其他终端的IP地址和编号对应信息,可以将调度系统平台人为分成若干组,以方便调度过程的管理。如图7将全部调度终端平台分为4组,会议发起者根据需要和每台终端的状态来决定是否将该终端加入会议中,已进入会议的终端,会议发起者可以对其执行踢除、静音和恢复操作。
4 系统测试
语音调度系统的测试场景为湖南工业大学河东校区,测试拓扑如图8所示(节点的实际距离按图右下角比例尺计算),区域内随机分布6个终端节点。终端平台集成的GM320 WiFi模块支持802.11 b/g协议。采用802.11b协议,室外数据传输距离理论值约为100m[9]。基于WiFi的传统无线网络环境无法完成6台终端的两两通信,而在MANET网络中,调整每个终端的无线网卡,让其在Ad Hoc模式中工作,且都运行OLSR,即可实现6台终端的两两通信。
图8 测试布局图Fig.8 Testing layout
图8中,终端A和F借助其他终端对数据包的转发进行语音传输。开始测试时,6个节点保持静止状态,在A节点上使用traceroute命令,跟踪去往节点F的数据包,结果显示数据包的传输方向沿着图8中的虚箭头前进;然后,人为移动节点C至C′,E至E′(见图8);其后,在A节点上跟踪去往F节点的数据包,数据包沿着图8中的实箭头方向传输,重复测试3次,数据包转发路径没有改变。用ping命令测试A与F节点间的连通性(每次测试300个数据包),结果见表1。
表1 A和F节点间连通性测试Table1 Connectivity test between A and F
从表1中可以看出,移动节点C和E后,传输时延明显减少,这是因为数据包的转发由原来的3个节点变为2个节点的缘故,实际应用中,数据包转发节点不宜超过5个,否则,时延将明显增大,影响语音数据的实时传输。实际测试发现,当通话节点间的丢包率不大于15%,平均时延不大于200 ms时,即能满足语音通话要求。测试结果表明:该语音调度系统实时性好,话音质量可靠。
5 结语
基于Linux系统平台,结合liblinphone库和OLSR路由协议,构建语音调度系统,完成了硬件和软件的设计,并应用于实际场景进行测试。与以往的调度系统相比,此系统具有组网方便、性能稳定、实时性好、可靠性高等优点,可广泛应用于不方便甚至不可能部署基础设施的工厂调度、抢险救灾等领域中,具有广泛的应用前景。
[1] 卢 伟.基于WIFI技术的出租车监控调度系统研究[D].哈尔滨:哈尔滨工程大学,2009.Lu Wei. Research of Taxi Monitoring and Dispatching System Based on WIFI[D].Harbin:Harbin Engineering University,2009.
[2]Adrian Farrel. Mobile Ad Hoc Networks[EB/OL]. [2012-11-07]. http://datatracker.ietf.org/wg/manet/charter/.
[3] Alan B Johnston. Understanding the Session Initiation Protocol[M].2nd ed. Boston London:Artech House Publishers,2004:1-2.
[4] 李 琳,柴乔林,袁春阳.H.323与SIP在VOIP应用中的实现及比较[J].计算机应用,2002,22(9):74-76,79.Li Lin,Chai Qiaolin,Yuan Chunyang. H.323 and SIP in VOIP Applications to Realize and Compare[J]. Computer Applications,2002,22(9):74-76,79.
[5]Royer E M,Chai-Keong Toh. A Review of Current Routing Protocols for Ad-Hoc Mobile Wireless Networks[J]. IEEE Personal Communications,1999,6(2):46-55.
[6] KakarlaJ,Sathya SS,LaxmiBG,et al. A Survey on Routing Protocols and Its Issues in VANET[J]. International Journal of Computer Application, 2011,28(4):38-44.
[7]Thomas Lopatic. Olsr.org OLSR Daemon Project Homepage[EB/OL]. [2012-10-11]. http://www.olsr.org.
[8] 武亚静,黄钺峰,亢 旭,等.Ad Hoc 网络AODV协议在Windows CE上的实现[J].计算机辅助工程,2009,18(1):87-91.Wu Yajing,Huang Yuefeng,Kang Xu,et al. Implementation on AODV Routing Protocol of Ad Hoc Network in Windows CE[J]. Computer Aided Engineering,2009,18(1):87-91.
[9] [Anon]. IEEE 802.11[EB/OL].[2012-10-11]. http://zh.wikipedia.org/wiki/ IEEE_802.11.