随着IP网络向多业务网的发展，广大用户希望能够以更方便更快捷的方式获得通信服务，这一日益迫切的需求对传统IP通信系统提出了更高的要求.但在通信服务实际使用的网络中，其传输层控制协议大多只使用一条路径建立网络连接，使得通信双方也只能利用这唯一的一条路径进行通信.近年来学术研究领域提出了网络多径路由(multipath routing)思想，应用市场上也不断涌现支持多宿(multi-homing)功能的多模智能移动终端^[1](加载IOS或Android移动操作系统的设备)，使通信双方具有多条传输路径成为可能；另外随着有线和无线网络技术的快速发展，使得在同一地理位置同时接入多个网络成为可能.如果网络应用能够同时使用2条或2条以上网络路径传输数据，与传统的单径传输相比，必然会极大地提高应用的吞吐量、健壮性、可靠性.

当前提出作为多径传输控制协议的研究成果主要包括：MPTCP，mTCP，SCTP，MTU-SCTP和MPRTP，接下来分别介绍这几种协议的相关研究内容和研究进展.

MPTCP(multipath TCP)协议通过资源共享分配传输数据到多条传输路径上实现了数据多径并发传输控制^[2].MPTCP工作组目前正在进行的研究工作是定义MPTCP应用程序接口.最早在实际网络环境中被实现的多径传输控制协议mTCP的基本设计思想是在建立TCP连接时使用多条路径，每条路径上传输数据单独组成一个数据子流，在整个数据传输过程中路径根据当前路径状况动态调节数据发送速率.但mTCP协议因为缺乏整体的拥塞控制方式，并且其路径控制方式比较简单，不适合在大规模网络中部署^[3].

另一种面向连接的传输层协议——SCTP提出了一个新概念“偶联”^[4]，SCTP端点可以通过偶联使用多条路径传输数据，但其使用多径的默认方式是指定这些路径中的1条为主路径，并使用这条主路径传输所有数据，而其他路径作为备用路径，所以SCTP并没有同时使用多条路径传输数据.MTU-SCTP是由SCTP改进获得，MTU-SCTP中的数据分配是根据传输路径的传输时延、带宽、丢包率、抖动等参数动态进行的，极大地增强了传输应用的负载均衡^[4].MTU-SCTP存在的最主要问题是由于多径传输使用的每条路径传输时延不同导致的接收方数据乱序问题^[5,6]，而且它并没有对当前应用非常广泛的实时数据多径传输给予充分的考虑.

在Singh等提出的MPRTP(multipath RTP)个人协议草案^[7,8]中类似于SCTP和mTCP的“子流”概念被提出并应用到RTP这一实时传输控制协议中.该草案在对RTP协议分组格式扩展的基础上定义了与多径实时传输相关的分组头部，草案中还对多径实时传输控制的一些相关问题给出了基本解决方案并定义了相关方法及框架.但草案还没有涉及更多更深入的研究内容，所以该协议距离真正的实际网络环境部署还需要做大量的工作.

本文主要研究端到端基于应用中继的多径传输控制机制，应用场景中包括的主要实体有：中继控制器、发送方和接收方.在图1中发送方和接收方分别与中继控制器进行信息交互，通过中继控制器实时控制网络，图中发送方和接收方与中继控制器间的连线代表控制信息，发送方和接收方间的连线代表数据信息.本文主要研究端到端传输控制机制，并把研究重点放在通信双方、中继控制器三者之间的交互机制.

图 1(Figure 1)

Fig. 1

图 1 基于中继端到端多径实时传输模型 Fig. 1 Real-time transmission model of relay-based end-to-end multipath protocol

图1中发送方实现的主要功能包括：数据分组发送、数据编码、负载分配、路径调整等.接收方实现的主要功能包括：数据解码、路径状态信息反馈、负载数据接收和重组等.中继控制器负责管理整个网络，其主要实现功能包括：中继节点及中继路径管理、中继节点信息收集、中继节点列表维护、周期性地与发送方和接收方交互中继路径信息以完成数据负载的动态分配和调整.本文提出并设计了基于中继的端到端多径传输控制协议MRTCP协议，该协议的主要目的是使终端支持多径传输.协议通用头部消息格式如图2所示，共12字节.

图 2(Figure 2)

Fig. 2

图 2 MRTCP通用头部 Fig. 2 MRTCP common header

图2中所示MRTCP通用头部中包括的各字段具体含义如下：

V：版本号，6位，代表当前使用的MRTCP协议版本号，目前该字段值设为1.

R：1位，用于判断当前消息类型的标志位.值取1时当前消息为请求消息，值取0则为响应消息.

S：该字段值是否有意义取决于R位值.R位值为1，则S位被忽略.R位值为0，S位用来代表响应消息种类.S位值为1时，表示此消息是成功响应，值为0时则为失败响应.

Type：消息类型，共8位.

Length：消息长度，16位.消息长度字节数等于该字段值乘以4.

Relay ID： 32位，中继节点ID，用来唯一表示网络中的一个中继节点.

Transaction ID：事务ID，32位.这一字段值是由发送方生成的随机数，当此事务需要被终止时，发送方必须收到与请求消息具有相同事务ID的响应消息，终止才可以被完成.

下面2.2节和2.3节分别对终端和中继控制器相关行为以及为其设计的消息格式进行介绍.

通信终端行为主要分为发送方行为和接收方行为.它们的主要实现功能已经在上节中介绍，为实现这些功能，本节设计了相应的消息格式.

1) REQUEST_PATH(请求中继路径)消息. REQUEST_PATH消息由使用中继路径的用户向中继控制器发送.图3展示了整个消息的格式.

图 3(Figure 3)

Fig. 3

图 3 REQUEST_PATH消息 Fig. 3 REQUEST_PATH message

MAX_RPATHS：16位.这个字段用于标志发送方和接收方之间可支持的最大路径数.

Bandwidth：32位.这个字段用来标志网络业务的期望带宽.一般要求中继控制器提供的中继路径实际带宽大于该值.

2) REQUEST_DELETE(请求删除路径)消息. REQUEST_DELETE消息用于用户删除某条中继路径，该消息由用户主动向中继控制器发出.中继控制器在收到该消息后，根据实际情况给出响应.

图 4(Figure 4)

Fig. 4

图 4 REQUEST_DELETE消息 Fig. 4 REQUEST_DELETE message

DPATH_NO：16位，该字段用于标志用户请求删除的路径.Path ID #1到Path ID #N这些字段表示当前被使用的所有中继路径.

中继控制器收到REQUEST_DELETE消息后，如成功删除该路径，则向用户终端发送一个只包含通用消息头部的反馈消息.

3) PATH_REPORT(路径传输状态报告)消息. PATH_REPORT消息由接收方在数据传输过程中周期性地向发送方发送，该消息中包含传输中使用的所有路径在一定时间范围内的相关状态.PATH_REPORT消息格式如图5所示.

图 5(Figure 5)

Fig. 5

图 5 PATH_REPORT消息 Fig. 5 PATH_REPORT message

START_TIME：路径状态统计起始时间.

END_TIME：路径状态统计结束时间.

Max Subflow Sequence：统计时间范围内在对应路径号为Path ID的路径上接收数据包具有的最大序列号，16位.它主要用于判断Path ID路径是否中断，判断的依据是字段值与发送方发送数据包最大序列号的比较结果.

Correct Received Num：统计时间范围内从路径号为Path ID的路径上正确接收数据包个数，16位.

中继控制器是管理中继路径的核心部件，实现的主要功能包括：发现中继节点并维护中继路径表、为通信双方提供当前使用中继路径的状态信息.

1) UPDATE_PATH(中继路径状态更新)消息. 中继控制器通过向中继节点发送UPDATE_PATH消息修改中继路径表中的中继路径状态，该消息如图6所示.

图 6(Figure 6)

Fig. 6

图 6 UPDATE_PATH消息 Fig. 6 UPDATE_PATH message

Address Type：中继节点地址类型，8位;

Port：消息使用端口，16位;

Address：目的中继节点地址，32位;

Idle timeout：路径剩余无负载时间，16位.当该字段值为0时，将会启动探测机制，确定当前路径是否需要继续使用.

Hard timeout：路径终止剩余时间，16位.当该字段值为0时，将不再使用当前路径.

成功响应UPDATE_PATH消息只需由终端发送一个仅包含通用头部的消息.

2) PATH_ALARM(路径状态报警)消息. PATH_ALARM消息是在中继控制器向终端提供其所需中继路径状态信息后，终端向中继控制器回送的响应消息.该消息格式如图7所示.

图 7(Figure 7)

Fig. 7

图 7 PATH_ALARM消息 Fig. 7 PATH_ALARM message

APATHS_NO：标志包含路径状态报警信息的路径，16位.

APATHS_DEGREE：字段APATHS_NO标志中继路径中报警信息的警报等级，警报等级字段值及对应含义使用刘玥霄提出的对照表数值^[9].

本文使用OMNeT++仿真软件对文中设计的基于中继多径实时传输控制机制进行实验仿真，并重点模拟负载数据分配和重组、失效中继路径发现的整个过程，仿真网络场景配置如图8所示.以太网信道的参数设置为：时延为正态分布模型，期望为1.5×10^-4s，标准差为5×10^-5s；数据率为10Mbps；误码率为1×10^-5.图8所示是一个进行实时传输的场景，其中发送方(Agent1)和接收方(Agent2)之间有3条路径：

图 8(Figure 8)

Fig. 8

图 8 多径实时传输场景配置示意图 Fig. 8 Configuration diagram of multipath real-time transmission

Agent1→SuperRelay→Agent2路径为subflow #1，为缺省路径；Agent1→relay2→Agent2路径为subflow #2；Agent1→relay3→relay1→Agent2路径为subflow #3.

在仿真过程中，设置缺省路由信道的传输时延为0.15s，超级中继节点的排队时延和处理时延服从(0.05s,0.051s)的均匀分布.

图9中横轴表示仿真时间，纵轴表示Loss Fraction字段的值.本次仿真从第20685个事件开始进行统计采样.仿真运行将近25s的时间内没有进行Loss Fraction评价，即从接收端直到收到了第一个LSR字段不为0的RR分组才开始进行Loss Fraction评价.音频业务一般对丢包率要求并不是很严格，不超过1 % 即可，从图9可以看出，满足音频业务需求.

图 9(Figure 9)

Fig. 9

图 9 音频业务丢包率 Fig. 9 Packet loss in audio service

图10为音频媒体数据多径传输过程中中继路径单向时延参数仿真运行结果，图中横轴数值代表仿真时间；纵轴数值表示中继路径单向时延.整个仿真一共持续了40个RTT(round trip time)时间范围，从仿真时间第32.0196s开始进行采样，最大值为1.9401×10^-2s，最小值为1.3593× 10^-2s，平均值为1.6982×10^-2s.由于大多数音频媒体数据时延在150~200ms，因此仿真结果表明本文提出的机制在传输音频媒体数据时，能够满足其对网络环境的需求.

图 10(Figure 10)

Fig. 10

图 10 音频业务时延 Fig. 10 Audio service delay

为了测量评价音频媒体数据的综合传输性能，本文采用王晓峰等提出的以网络测量的时延、丢包率及可用带宽结果为指标的多指标综合评价体系^[10]，计算公式中的指标权重系数统一取值1.虽然图11中所示的仿真实验结果表明应用这一评价体系的音频媒体数据经过多径中继传输后质量在不断发生变化，但其变化范围总体能够保持在[0.4,0.8]范围内，媒体数据质量总体保持较好.

图 11(Figure 11)

Fig. 11

图 11 音频业务传输质量 Fig. 11 Transmission quality of audio service

与音频仿真类似，统计接收方丢包率.与音频数据包相比，视频业务数据包较大，传输过程中主要影响业务带宽的因素是MTU(最大传输单元)，因此，其丢包率并不会受到太大影响.仿真结果表明丢包率仍在1 % 范围内，符合视频业务传输需求.中继路径单向时延取值在[0.2000s,0.2010s]区间，满足一般视频媒体业务对时延的要求.

在评价视频媒体业务的综合传输质量时，仍采用王晓峰等提出的多指标综合评价体系^[10]，所有指标的权重系数选取值同音频媒体业务.仿真结果表明视频媒体业务采用中继多径传输后总体质量没有发生剧烈变化，其最大综合评价结果为0.6901，最小结果为0.4602，显示整个业务的总体性能较好.

本文首先介绍了当前多径传输协议以及传输控制机制的最新研究现状，在对“如何进行多径实时传输控制”这一问题深入剖析的基础上，提出利用中继在重叠网络中进行端到端多径传输.为了实现这一想法，文中从中继控制器和通信终端两个中继网络中的主要实体考虑，设计了基于中继的端到端多径实时传输控制 协议(MRTCP)，并定义了协议整体消息流程及流程中相关的控制消息格式及相关字段含义.最后通过OMNeT++ 仿真软件对设计方案从音视频媒体业务入手进行了相关仿真实验，仿真结果表明该协议满足实际业务需求.