基于应用层中继的多径传输系统(MPTS-AR)是一种基于应用层中继的多径传输系统, 通过基于用户数据报协议的中继服务器构建端到端的多径传输条件, 并可支持多种业务实现多径传输.提出基于OMNeT++平台上的INET Framework实现MPTS-AR网络仿真的方法, 包括用户代理、中继服务器和中继控制器等网络逻辑实体的二次开发方法、相关网络链路和网络拓扑的构建方法、消息定义与处理方法等; 讨论了应用程序接口兼容和多业务支撑等重难点技术.最后, 通过H.264业务传输实例验证了所设计MPTS-AR网络仿真的正确性和有效性.
Multipath transport system based on application-level relay (MPTS-AR) is a multipath transport system model based on application-level relay. It uses user datagram protocol relay server to establish multiple paths for point-to-point session and supports multiple services. A method was proposed to create MPTS-AR network simulation basing on INET Framework of OMNeT++ platform, including how to create network topology, to implement logical entities (user agent, relay controller, relay server), and to define and process messages. The key and difficult points about application program interface compatibility and supporting multi-service were also discussed. H.264 service based simulation was carried out. It is shown the correctness and effectiveness of MPTS-AR network simulation.
多径传输技术同时使用网络中多条不相交或部分相交路径，是实现满足QoS传输的一种重要方式.近年来人们提出了多种多径传输方法.这些方法[1-3]工作在传输层，要求终端具有多网络接入能力.相比之下，基于应用层中继的多径传输系统(MPTS-AR, multipath transmission system based on application relay)通过应用层路由建立多条路径，避免了对终端网络接入能力的要求.
高效准确的仿真系统或平台可以节省人力或物力的投入，加快研究进度，是验证传输技术正确性和有效性的重要方法.目前，一款优秀的仿真平台OMNeT++已经实现了流控制传输协议(SCTP, stream control transmission protocol)和多径传输控制协议(MPTCP, multipath transmission control protocol)等传输层多径传输方法的仿真，但对于基于应用层路由的多径传输技术仿真尚无相关的工作介绍.以下将详细介绍基于OMNeT++平台开发MPTS-AR网络仿真的方法.
1 相关工作1.1 基于应用层中继的多径传输系统如图 1所示，MPTS-AR[4]由三类逻辑功能实体组成，分别为中继控制器、中继服务器和用户代理.中继控制器和中继服务器组成中继服务系统，为用户代理之间的会话提供多径服务.中继控制器是MPTS-AR的核心组件，工作在控制平面，通过OpenPath协议与中继服务器和用户代理通信，维护中继服务器的网络拓扑结构和为用户代理分配中继路径.中继服务器在控制平面与中继控制器交互信息，建立本地应用层路由表；在数据平面基于应用层路由表转发数据.用户代理通过控制平面向中继控制器申请多条路径；在数据平面使用多路径传输数据.
|
图 1 基于应用层中继的多径传输系统框架 |
MPTS-AR定义了通用的多径传输控制协议(MPTP, multipath transport protocol)组件，其工作层次如图 2所示.它为应用层提供与传统UDP一样的应用程序接口(API, application program interface)，调用UDP服务，实现UDP中继.根据业务需求，用户可以扩展MPTP组件，实现不同的功能.
|
图 2 MPTP组件 |
OMNeT++是一个开源的面向对象的离散事件仿真平台，其核心思想是基于模块化的结构和灵活的消息机制. OMNeT++现已成功应用于诸多领域，如通信网络、复杂IT系统、排队网络和硬件结构的仿真等.
OMNeT++中网络节点由简单模块和复合模块组成.用户可以使用网络描述(NED, network description)语言定义网络结构，极大地简化仿真建立过程. OMNeT++使用C++语言定义模块行为，和*. ini文件(通常命名为omnetpp. ini)配置仿真环境和参数.
OMNeT++不提供具体的仿真业务，但业界已经开发出很多模块或框架来解决这个问题. INET Framework[5]是一个基于OMNeT++平台开源的通信网络仿真框架，支持有线和无线网络协议，例如UDP、TCP、SCTP、IP、Ethernet、PPP、802.11等.它实现了基于传输层技术的多径传输方法SCTP.但INET Framework暂时没有相关模块支持基于应用层路由的多径传输技术；以下将基于INET Framework设计实现MPTS-AR网络仿真.
2 MPTS-AR仿真系统设计与实现将根据MPTS-AR定义的逻辑实体行为设计逻辑实体结构、实现消息机制和逻辑实体行为.
2.1 逻辑实体结构MPTS-AR定义了3种逻辑实体的行为，如表 1所示，它们协同实现多径传输.由于OMNeT++基于模块化的结构设计，逻辑实体的行为由构成逻辑实体结构的简单模块实现.根据逻辑实体行为，设计的逻辑实体结构如图 3所示.
|
表 1 逻辑实体行为 |
|
图 3 MPTS-AR逻辑实体结构 |
相比于INET Framework[6]中标准主机结构，中继控制器和中继服务器结构与其保持一致，用户代理则在应用层(Application)和传输层之间增加了3个简单模块，即多径模块(Multipath)、配置模块(Configurator)和路径管理模块(PathManager).
2.2 消息定义与处理逻辑实体之间消息遵循一定的消息格式. OMNeT++支持灵活的消息定义机制，用户可以定义消息成员. OMNeT++编译时会自动生成对消息成员的基本操作方法；用户也可以根据需求自定义对消息成员的操作方法.
如图 1所示，逻辑实体在控制平面和数据平面分别使用OpenPath和MPTP协议.创建. msg文件定义OpenPath和MPTP消息.
OpenPath消息的基本格式如下所示，其中消息成员msgType用以区分消息类型.
packet OpenPath
{
short msgType;
};
基于OpenPath消息的基本格式，通过增加消息成员实现不同的功能.
与OpenPath消息类似，MPTP消息也通过消息成员msgType区分消息类型. MPTP消息成员中需要包含路径标识(PathID)，用于指示消息沿着特定的路径传输至接收者.
在编译过程中，系统自动为*. msg文件调用消息编译器，产生*_m. h和*_m. cc文件，分别包含对消息成员操作方法的声明和定义.
2.3 逻辑实体行为实现图 3描述了逻辑实体结构，它们由一组简单模块复合组成.模块之间互相配合完成逻辑实体的行为. OMNeT++使用C++语言描述模块行为.
用户代理中的配置模块、路径管理模块和多径模块协同工作完成表 1中所定义的6种行为.
配置模块：由initialize()开始执行，从*. ini读取业务管理规则，包含业务可使用中继路径条数、带宽和时延要求等信息.
多径模块：用户代理的重要模块，承担用户代理大部分功能.行为实现过程如下：
步骤1 由initialize()开始执行，从*. ned和*. ini中读取配置参数.例如，模块启动时间.
步骤2 等待接收消息，进入handleMessage()处理消息.如果是发送者，进入步骤3；如果是接收者，进入步骤7.
步骤3 定期发送发送者报告；接收Application模块发来的消息，如果为控制命令包，进入步骤4，否则进入步骤5.
步骤4 提取控制信息，协助创建和管理多径会话，并将控制信息发送给UDP模块，进入步骤6.
步骤5 从中继路径池中选择一条路径.如果中继路径池为空，选择默认路径，并请求路径管理模块向中继控制器申请中继路径.结合中继路径信息将数据封装为MPTP数据包，发送给UDP模块.进入步骤6.
步骤6 数据发送完毕，进入步骤9，否则返回步骤3.
步骤7 重组接收的数据包，消除多路径间传输时延差异；同时统计各路径接收状态.
步骤8 将重组后的数据发送给Application模块；定期发送接收者报告.会话结束进入步骤9，否则返回Step 7.
步骤9 会话结束，向路径管理模块请求释放中继路径资源.
路径管理模块：用户代理的核心模块，负责会话和中继路径的管理.由initialize()开始执行，从*. ini获取中继控制器地址和OpenPath协议服务端口.接收多径模块请求，基于请求和从配置模块获得的业务管理规则向中继控制器发送路径请求.
中继服务器结构与标准主机结构保持一致，使用Application模块完成表 1所述的6种行为.工作流程如下：
步骤1 由initialize()开始执行，从*. ini中读取配置参数.
步骤2 向中继控制器注册在线状态.根据场景配置信息和服务能力动态调整中继服务状态，包括开始、暂停、终止中继服务3种操作.
步骤3 周期性测量与邻居中继服务器间路径状态，并报告给中继控制器.
步骤4 处理消息.如果是OpenPath消息，进入步骤5；如果是MPTP消息，进入步骤6.
步骤5 根据OpenPath消息修改中继服务，即增加、删除或更新路由表.返回步骤4.
步骤6 从消息中提取路径标识，查找路由表，将消息转发至下一跳地址和端口，返回步骤4.
中继控制器与中继服务器情形相似，使用Application模块实现表 1中所述的3种行为.工作流程如下：
步骤1 由initialize()开始执行，从*. ini中读取配置参数.周期性的检测中继服务器状态.
步骤2 接收处理消息.如果是来自用户代理的消息进入步骤3，否则进入步骤6.
步骤3 来自用户代理的消息，包括路径请求消息和路径管理消息.对于路径请求消息，进入步骤4；对于路径管理消息，进入步骤5.
步骤4 为用户代理分配中继路径，将分配的路径信息回送给用户代理，通知中继路径经过的中继服务器增加路由信息(路径标识、下一跳地址和端口)，告知接收者数据传输所使用的中继路径标识和数据接收端口，返回步骤2.
步骤5 响应用户代理路径管理请求，包括增加、删除中继路径，返回步骤2.
步骤6 来自中继服务器的消息，包括注册消息和中继服务管理消息.中继控制器认证鉴权中继服务器合法性；允许合法的中继服务器提供中继服务，并根据中继服务管理消息修改中继服务器的在线状态.返回步骤2.
2.4 仿真配置OMNeT++使用*. ini文件配置网络仿真参数. *. ini文件包括[General]和[Config]两个部分. [Genaral]部分可选，通常配置仿真网络的名称、仿真时间、CPU资源等通用信息；[Config]部分配置特定的仿真参数，如模块地址、模块启动时间、数据传输的目标地址、输入输出数据等信息.
文中第3部分H.264业务仿真的部分配置如图 4所示.运行仿真时，OMNeT++将根据*. ini文件建立和配置MPTS-AR仿真网络.
|
图 4 OMNeT++仿真配置实例 |
为了能够充分验证MPTS-AR的功能和性能；严格按照真实的网络环境设计实现MPTS-AR网络仿真.将详细阐述在此过程中遇到的难点与关键技术.
2.5.1 API兼容技术API兼容是指不改变现有模块的接口函数，各模块像以前一样为其他模块提供服务或使用其他模块提供的服务.如图 3所示，多径模块向Application模块提供与传统UDP一样的API，并像Application模块一样调用UDP模块服务.多径模块处理Application模块和UDP模块的消息，实现API兼容的流程如图 5所示.
|
图 5 多径模块API兼容实现方法流程图 |
初始化时，多径模块像Application模块一样创建一个UDPSocket，用于向Application模块提供UDP模块的服务；同时多径模块参考UDP模块行为处理来自Application模块的信息. Application模块消息分为两类：控制命令包和数据包. 1) 多径模块提取包中的控制信息建立和管理多径会话；然后将控制信息通过UDPSocket发送给UDP模块. 2) 多径模块提取出数据包中的控制信息和数据，然后将数据封装为MPTP数据包，并携带提取出的控制信息，使用UDPSocket发送给UDP模块.对于来自UDP模块的MPTP消息，多径模块解封装MPTP包，获得包中的数据，将其放入重组缓冲区，完成重组后发送给Application模块.
2.5.2 多业务支撑用户代理需要支持多业务(Application模块)多径传输能力.在用户代理结构中，Application模块与多径模块保持一一映射关系，多径模块保存Application模块使用的中继路径信息.路径管理模块代表用户代理在控制平面与中继控制器交互信息，即作为多径模块和中继控制器之间的消息解析器和转发器.
对于多Application模块的场景，为了实现多径模块和中继控制器之间消息转发，路径管理模块在第一次接收多径模块消息时建立多径模块和消息通道间的映射关系，即 < 应用标识，门索引标识 > 二元组.应用标识为2.5.1中多径模块从Application模块发送的控制命令包中获得的UDPSocket绑定的端口号，门索引标识为路径管理模块接收多径模块发来消息的消息通道索引号.对于中继控制器发来的消息，路径管理模块解析消息获得应用标识，查找映射关系二元组，将消息从门索引标识指示的消息通道发送给多径模块.
3 MPTS-AR评价由于MPTS-AR只定义了多径传输框架，不定义具体业务，因此将通过传输H.264业务验证所设计的MPTS-AR网络仿真的正确性和有效性.
仿真采用INET Framework[5]中实时传输协议(RTP, real-time transport protocol)实现H.264业务传输.为了支持H.264数据的发送和接收，RTP模块根据配置文件中定义的参数(ProfileName和PayloadType)动态创建H.264发送和接收模块[6].
网络拓扑如图 6所示，发送者和接收者之间存在3条中继路径(Path1, Path2, Path3)，分别经过中继服务器1、2、3，且3条路径的服务能力依次降低，即Path1>Path2>Path3，其中Path2的服务能力不稳定，在一定范围内波动.
|
图 6 H.264业务仿真网络拓扑 |
图 7展示了中继服务器Application模块转发数据和发送者的统计信息. x轴表示数据传输的时间，y轴表示传输数据包的序号.图中叉、十字、三角标记的曲线分别表示Path1、Path2、Path3传输数据包的序号.通过对比3条曲线发现路径承担负载的权重与路径的服务能力成正比. Path2从第1.5 s开始，服务能力开始下降；通过接收者报告，发送者感知到这一变化，降低了Path2承担负载的权重.受Path2服务能力持续下降的影响，发送者在第2 s时向中继控制器申请删除Path2.第3 s时，Path2恢复了服务能力并告知中继控制器；中继控制器通知发送者将Path2添加到刚才的会话中，数据传输恢复到会话最开始的状态.
|
图 7 数据流量统计 |
统计数据显示发送者可以使用多条中继路径发送数据，并且动态调整发送路径以适应网络状态变化，说明所设计的逻辑实体的结构合理、正确地实现了逻辑实体的行为.
3.2 MPTS-AR有效性分析图 8分别显示了发送端视频流和接收端视频流的第50、90帧图像.通过对比上下两部分图像发现图像质量差异不足以影响用户主观体验，说明用户代理中的多径模块可以正确地对从多条路径接收到的数据包进行排序，递交给RTP/RTCP模块，最后由接收模块恢复出原始视频流.
通过H.264业务仿真结果证明设计的MPTS-AR网络仿真可以有效地为业务提供多径传输服务，不影响业务的传输质量.
|
图 8 视频帧 |
基于INET Framework，从逻辑实体结构设计、消息定义、网络拓扑搭建、仿真环境配置等方面介绍MPTS-AR网络仿真的设计开发方法. H.264业务仿真实验结果表明，用户代理可以使用多条路径高质量地传输数据，实现了MPTS-AR所定义的功能，验证了设计开发的MPTS-AR网络仿真的正确性和有效性.
多径传输是网络传输技术领域的一个热点问题.鉴于网络仿真的诸多优点，基于INET Frame-work开发了MPTS-AR网络仿真，填补了该框架上基于应用层路由的多径传输技术仿真的空白.同时对于后续的多径传输控制机制(流量控制、拥塞控制、负载分配等控制算法和路径选择算法)的研究提供了仿真环境.
| [1] | Stewart R. Stream control transmission protocol (SCTP) [EB/OL]. IETF. 2013, 3. https://datatracker.ietf.org/doc/rfc4960. |
| [2] | Ford A, Raiciu C, Handley M, et al. Architectural guidelines for multipath TCP development (MPTCP) [EB/OL]. IETF.2013, 3.https://datatracker.ietf.org/doc/rfc6182. |
| [3] | Mao Shiwen, Dennis B, Sathya N, et al. MRTP: a multiflow real-time transport protocol for Ad Hoc networks[J].IEEE Trans on Multimedia, 2006, 8(2): 356–369. doi: 10.1109/TMM.2005.864347 |
| [4] | Lei Weimin, Zhang Wei, Liu Shaowei. A framework of multipath transport system based on application level relay [EB/OL]. IETF. 2015, 1. https://datatracker.ietf.org/doc/draft-leiwm-tsvwg-mpts-ar/. |
| [5] | Rudolf H. INET framework for the OMNeT++discrete event simulator [EB/OL]. 2012. http://github.com/inet-framework/inet. |
| [6] | Wang Y K, Even R, Kristensen T, et al. RTP payload format for H. 264 video [EB/OL]. IETF. 2013, 3. https://datatracker.ietf.org/doc/rfc6184/. |