1. 引言
随着网络及通信技术的不断发展,人类快速进入了信息时代。最近十几年,伴随着无线通信技术的不断革新,无线通信及其应用己成为当今信息科学技术最活跃的研究领域之一。无线通信的快速增长及其在各行各业中的广泛应用,给人们日常的生产生活带来了巨大的改变 [1]。
本文根据项目的实际的应用需求,采用分配类多信道接入的方式来实现无线信道资源的分配,提高资源利用率的同时降低通信冲突的发生概率,保证资源的利用率以及网络的稳定性 [2]。
2. 相关研究现状
2.1. 无线自组网信道接入协议的研究动态
在无线网络环境中,信道资源十分昂贵,媒体访问控制协议(MAC)位于物理层之上,网络层之下,对整个网络协议栈起着承上启下的作用。MAC协议控制着信道资源的分配,其性能将直接影响信道的使用效率 [3]。而在无线自组网中,MAC协议性能的优劣对整个网络性能的影响则更为明显,性能不良的MAC协议甚至可能造成网络的瘫痪。
每一种协议都有各自的设计目标和对应的信道接入技术。根据信道接入个数将信道分为单信道、双信道、多信道三种类型。
多信道接入协议具有多个无线信道可用,这种信道接入协议的优点就是相邻两个节点可以使用不同的信道而不会互相冲突。既可以使用一个信道混合发送控制和数据两种报文,也可以使用公共信道发送控制报文,不同信道发送数据报文 [4]。
2.2. 无线自组网资源调度的研究动态
目前,国内外学者已经对无线自组织网络资源的调度算法进行了相关研究,相关算法虽然不能直接用于无线自组织网络的资源调度,但对无线自组织网络的研究具有很好的参考价值 [5]。
现今无线自组网MAC协议的研究主要集中在提高信道接入的公平性问题、提高吞吐量、提高信道利用率等方面。单信道MAC协议ALOHA协议发展而来,包括载波侦听多址访问协议(CSMA)、多址访问与碰撞回避协议(Multiple Access with Collision Avoidance, MACA)、IEEE802.11MAC DCF协议 [6]。但单信道MAC协议存在先天不足:由于只采用一个信道,有限的信道容量成为制约MAC协议性能的瓶颈。研究表明,无论协议设计的如何巧妙都无法弥补其先天的缺陷 [7]。
已经存在的多信道MAC协议包括多信道CSMA协议、DCA协议等,分别从不同方面改进单信道协议,各有特点,并都在一定程度上改善了MAC协议的性能。但以下问题依然存在:1) 协议控制复杂,控制开销大,在一定程度上影响了网络吞吐量。2) 对终端的配置和性能都提出了较高的要求,实际用于无线自组网的难度较大,可移植性较差 [8]。
3. 可行性分析
本课题研究是本人的主要研究方向,根据无线自组网的特点,采用合适的分配算法对系统的性能有很大的提升,为整个项目的稳定性提供了强有力的保证,具有很强的实用性。
资源调度一直是国内网络研究的热点,有很好的发展现状,而且此方向有大量的资料可供参考,很多研究与系统也体现出技术的成熟性。
无线自组网常用于军事通信,抢险救灾等场景,该选题基于本单位自组网合作项目,为了改善目前系统资源分配算法在信道资源分配过程、分配带宽选择上的弊端而进行的 [9]。在自组网项目中同样是多信道、无线自组织网络的特点,采用动态资源分配将对系统的性能有极大的提升,为整个项目的稳定性能提供了强有力地保证,具有很强的实用性。
4. 实施方案
在无线自组网项目系统中,应用模型如图1所示,要求实现各个节点车台之间的相互通信,同时即使某个节点掉线或被摧毁,也不影响其它节点的通信功能。该系统要求能够传输视频、语音、数据等多种大容量、高实时业务,保证通信的质量。
Figure 1. Application model of wireless ad hoc network project
图1. 无线自组网项目应用模型
4.1. 系统需求
1) 系统网络架构需求
各节点之间通过空口进行控制面信令的交互和用户面数据传输,节点设备由核心处理单元(DTD CP)和业务处理单元(DTD AP)组成,其中DTD CP包括DTD-RAN (DTD无线接入)和DTD-NPS (DTD网络处理子系统)。
2) 系统核心处理单元架构需求
系统核心处理单元由数字基带处理部分和射频通道组成,数字基带处理部分在XLINX ZYNQ7000 SOC芯片实现,DTD-RAN除PHY外的子系统及DTD-NPS软件分布于ARM核中,PHY子系统在FPGA上实现。
3) 系统软件架构需求
整个项目基于双核XLINX ZYNQ7000 SOC + A9芯片上实现,针对无线自组网设备特点进行开发的自组网软件项目,满足终端在一定范围内,多跳节点、快速移动中自组组成网络,支持路由切换,跳频等功能,支持语音、视频、指控消息和数据等典型业务,也支持不同的业务QOS需求。
4.2. 系统概要设计
1) 软件结构设计
整个资源管理模块RRM的软件架构如图2所示:
Figure 2. Resource management module (RRM) structure diagram
图2. 资源管理模块(RRM)结构图
2) 软件概要设计
本层为待测元件及配套的测试机架,当待测元件测试模式种类较多时,可以在数据采集层增加一个元件控制器,通过测试模式控制信号流来控制当前的测试状态。
a) BRC通信
本节点BRC进程与其他对端节点BRC进程通信,所有信息对于AMC和PHY都是透明,所有的节点BRC模块定时收集本节点邻居、AMC、Topo信息等,通过Dispatch->PHY路径发出去,其他节点空口收到广播后通过PHY->Dispatch->BRC路径交给BRC模块处理。
b) 邻居表维护
邻居的上下线分为脱网、入网、脱网、子网融合4个过程分别说明,在每一个过程中重点说明每种状态的资源调度过程和收到广播的处理过程。
c) 资源分配设计
资源的协商算法需要基于一定的策略和原则,初期考虑到实现复杂度、时间紧迫性以及项目需求采用全静态资源分配策略,以控制资源开关,后期采用静态和动态分配相结合的方式,并根据系统当前的业务量和运行状态进行相应的调度和规划 [10]。
4.3. 详细设计
1) BRC通信
BRC由以下模块组成,分别是定时器管理、广播收/发、邻居表维护、AMC协商和同其它模块交互,如图3所示。定时器管理用于管理BRC模块所有定时器,包括所有邻居老化定时器、S0发送周期定时器以及AMC相关定时器等;广播收发模块从本进程队列中获取广播消息或者其他进程消息,做相应的处理。广播发送模块构建S0广播消息或者向其他进程发送通知消息,需要结合AMC消息、MMAC消息等;邻居表维护负责维护邻居的基本信息和邻居的邻居信息;AMC协商负责节点之间调制编码方式的协商处理;其他模块交互负责在邻居上下线的时候,及时通知到AMC线程协商、MMAC和Dispatch模块,做出相应的资源更新操作。
2) 邻居表维护
邻居的上线过程是本节点收到邻居的广播信息开始,通过查询本节点的邻居表判断此邻居是否是第一次上线或者是第一个邻居,如果邻居节点是本节点的第一个邻居且广播的邻居的信息中也本节点的信息,那么给本节点分配静态时隙,具体的处理流程如图4所示。
3) 资源分配
首先竞争资源的申请原则主要是预申请机制,并且快速响应空口转发层传递过来的需求,资源预申请就是在当前空口需求快要达到空口带宽的80% (此值可设置)时进行资源申请操作,竞争资源的申请采用广播告知的方式,在广播中携带本节点需要申请的竞争资源个数和位置,同时在此广播报文中标注报文携带了竞争资源的内容。
动态资源的使用采用两种调度方式,第一种是“逐级申请,先到先得”,这种调度方式先申请的节点可以获得资源的调度,如果竞争资源已经耗尽,则后到的节点将得不到资源调度;第二种是“最优公平调度”,这种调度方式下每个节点通过广播本节点需要申请的竞争资源个数。
第一种调度方式比较简单,在其他节点把竞争资源申请完之后,如果某个节点还想申请竞争资源只能等到其他节点把竞争资源释放后才能申请到资源,且优先发出申请广播的节点才能申请到资源时隙。第二种调度方式需要知道每个邻居节点需要申请的竞争资源时隙个数,通过一种公平调度算法,平均分配或者再资源时隙不够的情况下按照一定比例分配给本机节点,这种调度方式相较于第一种的方式更好。
申请过程是在协商事件队列中进行的,在协议事件调度器轮询到本次竞争资源申请事件后,首先判断是否和其他邻居在申请事件上是否有冲突,再确认当前是否有竞争资源可以申请,然后向外广播本次拟申请的竞争资源,延时等待后确认没有干扰冲突就设置资源,结束本次申请流程。竞争资源的申请具体的流程图如图5所示。
Figure 4. Flow chart of neighbor on-line
图4. 邻居上线流程图
Figure 5. Flow chart of resource application
图5. 资源申请流程图
竞争资源的释放流程相对简单,在一段时间内如果本机的动态申请资源比较空闲,则注册竞争资源释放事件,直接释放后更新本机信息,则下次广播后所有的邻居信息就能自动更新,不需要特殊的流程。资源释放流程图如图6所示。
Figure 6. Resource release flow diagram
图6. 资源释放流程图
5. 测试与分析
整个系统的测试步骤如下:
1) 搭建如图7的系统测试环境。宽带通信节点设备连接导航模块同步时间信息,通过固定衰减器连接到8口可编程衰减器上,每个节点下挂一台PC,节点之间的射频连接通过可编程衰减器控制。
2) 每台设备烧写嵌入RRM模块的系统版本文件,此文件是一个Linux的镜像文件,系统在上电启动时会将Flash中的镜像版本文件下载解压到内存中并根据启动脚本启动相关进程。
3) 本RRM模块则针对组网时延和带宽要求进行测试,通过测试判定RRM信道资源协商收敛时间是否达到要求,节点之间的流量带宽是否满足业务需求。
流量测试还是采用图7的环境测试,用3个节点进行组网,然后采用节点下挂的PC之间互相灌包测试。流量监测我们用NetMeter软件观测节点上下行的流量情况。灌包软件采用iperf灌包软件,包长1024 Bytes,在灌包业务发起端开始灌包。测试中,采用64QAM5/6的调制编码方式,理论带宽流量双向可达41.47 Mbps。
测试时,首先节点2向节点1进行灌包20 Mbps,在节点1查看接收到的流量,从图8和图9中的流量监控来看,节点1接收到的流量由最初的1.99 Mbps呈阶梯状的逐渐递增到18.7 Mbps,此时查看节点2的资源,如图10,可以发现系统剩余的信道资源因节点2与1之间的业务需求被动态协商分配完毕,这是动态调度算法中的按需调度。此时接收端抖动较小,流量趋于稳定,符合设计的需求。
Figure 7. Schematic diagram of system test environment
图7. 系统测试环境示意图
Figure 8. Unilateral one-way filling test sending end
图8. 单边单向灌包测试发送端
Figure 9. Unilateral one-way filling test receiver
图9. 单边单向灌包测试接收端
上面测试结果显示,系统在节点组网的初始时段能够按照设计方案正确的分配4个静态时隙资源以保障基本业务链路带宽,当节点之间有业务产生时能够触发动态资源协商,注册动态资源分配事件,并正确分配系统的剩余时隙资源,并且根据流量变化按需分配,当业务停止时系统能够及时回收动态分配的资源以备下次使用,完全符合设计方案的初衷,验证了动态资源分配算法的逻辑正确性,具备RRM模块预期设计的功能。
6. 总结及展望
本文对系统现有RRM模块的信道资源分配算法进行了多项改进,极大提升了系统组网时延以及系统整体稳定性性能。
本文主要从软件工程的角度对RRM模块的设计与实现进行了详细的描述,在软件设计部分采用分层设计与模块化设计,结合嵌入式软件开发流程与方法,并根据现有的成熟的MAC协议设计与实现了RRM模块的动态资源分配算法。整个设计过程中分层与模块化的设计使得RRM模块结构清晰,设计思路明确,层层之间的服务简洁明了,代码可塑性与可移植性强,调试阶段能够快速定位具体位置,体现了产品开发阶段工程性的要求。