车载自组织网视频流媒体协助下载研究

陈亮，王军，陈蓉，顾翔，王进，万杰

（1. 南通大学计算机科学与技术学院，江苏 南通 226019；2. 江苏工程职业技术学院图文信息中心，江苏 南通 226007）

1 引言

车载自组织网（VANET，vehicle ad-hoc network）是指车辆之间、车辆与固定接入点之间为相互通信组成的移动ad-hoc网络。VANET技术在事故报警、辅助驾驶、交通信息查询及 Internet接入等领域具有广阔的应用前景[1]。VANET通常由车辆单元（OBU, on board unit）及路边单元（RSU,roadside unit）构成，车间通信可以不依赖RSU，使用自组织联网方式实现数据传输，但当车辆与Internet互访时，可通过RSU实现数据交换。

VANET既具有自组织、多跳路由、网络容量有限等普通移动自组网特点，还具备高密度节点分布与节点高速移动的特点[1]，为此电气和电子工程师协会（IEEE，Institute of Electrical and Electronics Engineers）发布了适用于车联网的IEEE 802.11p协议。但随着车联网应用的深入，乘客观看互联网视频对 MAC（media access control）传输机制与性能研究提出了新的挑战[2]。

由于基站 RSU的通信范围与部署数量限制，高速行驶的车辆在 RSU覆盖范围内的通信时间较短，一旦车辆行驶至通信盲区，还会导致网络连接频繁断开，产生车联网间歇性的接入问题[3]，最终影响传输性能。

当目标车辆无法与基站一跳直接传输时，IEEE 802.11p协助（中继）下载是一种有效增加吞吐量的技术方案[4-5]。在如图1所示的车联网拓扑中，根据协作车辆的行驶方向，协助下载方案分为同向协助[6]与对向协助[7-9]。针对不同的应用场景，研究者设计了不同的选车策略[6-9]及协作车辆激励机制[10]，据此建立相应的下载流量模型[6-7,9,11]。但是，以上研究在改进车联网传输性能的同时，也存在流量建模不精确与使用CBR（constant bit rate）协议传输视频等问题。

针对以上问题，本文开展了如下研究工作。

1） 分析OBU传输半径问题与同向转发下的信道竞争问题，提出车联网同向多跳下载的流量改进模型。NS2（network simulator version 2）仿真显示，相较文献[6]的流量模型，改进模型可以更准确地描述同向协助下载流量。

2） 根据上述理论建模，针对视频流媒体应用，设计同向与对向协助下载方案，同向车辆对目标车辆进行多跳协助下载，对向车辆对目标车辆进行时间优先或画质优先的一跳协助下载。实验表明，新方案的下载耗时少于DSRelay与VCoDS（VANET cooperative downloading scheme）算法，且画质能维持较好水平。

2 相关研究及问题

为了研究车联网协助下载并改进网络性能，研究人员开展了一系列工作。Zhao等[12]较早提出了“车对车”中继机制，有效扩展了RSU覆盖范围，将吞吐量维持在较高水平，算法仅依赖客户端，不需要在基站上做修改。

同向协作的连接保持时间长、信道衰落慢，而对向协作的车辆相遇条件好，目标车辆前方的对向车辆均可能与其相遇，因此通常从同向与对向两方面开展协助下载研究。

同向协助下载方面，刘业等[6]分析车辆OBU利用RSU下载数据时的MAC层信道竞争情形，提出了适用于高速公路场景的网络吞吐量模型。针对RSU单元之间存在的盲区问题，设计了一种利用同向行驶车辆协助下载的VCoDS方案，在同向一跳直接下载之外，增加同向两跳协助下载。仿真表明，新方案可有效提高RSU下行流量。

图1 车联网拓扑示意

对向协助下载方面，刘建航等[7]针对RSU通信范围受限，提出了对向车辆协助下载DSRelay算法。当目标车辆在一个 RSU区域内不能完成下载任务时，下一个 RSU通过计算目标车辆与对向车辆在RSU盲区中的相遇时间和通信时长，选择一组对向协助车辆携带目标车辆所需的数据，协助车辆在盲区中不同时间段将数据一跳传输给目标车辆，从而实现盲区中扩展下载。实验表明，该方法提高了下载吞吐量，减少了间歇性连接问题。

刘建航等[8]在DSRelay算法基础上，进一步提出了近似全局最优的车联网协助下载选车策略DSMOV（downloading scheme Markov optimization vehicle）。算法不仅提高了用户数据下载总量，而且各个目标车辆获取协助下载服务的次数更均衡，从而保证了系统的公平性。

谢永等[9]设计了一种高速公路的对向车辆无间隙协助下载方法，针对协助数据无法交付目标车辆问题，设计了在盲区创建数据副本的“N-副本”策略，提高了系统的QoS（quality of service）性能。

以上研究[6-7,9]在一跳直接流量的建模过程中，假定车辆在 RSU通信范围内一跳直接可达，没有考虑车辆有效传输半径对下载的影响问题。另外，文献[6]把转发节点视作一个独立发送的源节点，以此进行吞吐量建模，但实际的转发节点并非时刻有数据待发，因此需要进一步研究转发状态下的信道竞争问题。以上2种问题都可能造成流量计算的误差。

此外，传输文件的流量特性也是协助下载需要重视的问题。文献[6]与文献[7]均以固定传输速率的应用层协议传输电影文件，本质上是将视频作为普通数据文件进行下载。其中，文献[6]未考虑数据丢失及重传问题，而文献[7]规定数据块丢失后需要后续RSU重传给目标车辆，研究如何将电影文件完整无误地下载到目标车辆。文献[9]没有指明传输的文件类型，但实验中也是以恒定速率发送数据。所以上述研究都没有考虑视频流的突发、非连续及低速特性。Huang等[13]考虑目标车辆从3G公网下载视频流媒体，但同时利用 802.11p协议进行车间协作下载，有效提高了视频流媒体传输画质，但没有考虑车流密度对协助下载的影响。Mohamed等[14]利用硬件搭建了车联网视频传输系统，并在实验床中测试了视频传输质量，但研究仅完成了室内与室外的静态拓扑实验，没有考虑车辆移动对视频质量的影响。

本文2.1节～2.3节，将对上述研究涉及的问题，展开具体的分析。

2.1 车辆有效传输半径问题

由于发射功率、天线尺寸及安装位置等物理原因，基站RSU有效传输半径Rr通常大于车辆OBU有效传输半径Ro。当车辆在公路上以车速vi行驶，OBU与RSU之间的距离d经过以下3种情况。

1） 基站在车辆通信范围内，即d＜Ro。

2） 车辆仍在基站通信范围内，但基站不在车辆通信范围内，即 Ro＜d＜Rr。

3） 车辆不在基站通信范围内，即d＞Rr。

文献[6-7,9]认为，对于情况 1）与情况 2），两节点均可直接通信；对于情况3），两节点无法直接通信。当目标车辆完整地穿越某个RSU覆盖区域后，文献[6,9]推导出一跳直接传输的累计时长为并给出了下载流量计算式。换言之，上述研究假设OBU只要在RSU的通信范围内，就可以实现一跳通信。

但本文认为，IEEE 802.11p协议的MAC层是基于data帧与ACK帧的“二帧交换”。对情况2），OBU固然可以收到来自 RSU的数据帧，但由于RSU不在OBU有效通信范围内，OBU的ACK确认帧无法被RSU接收，从而导致二帧交换失败。因此，需要具体分析情况2）的传输过程。

考虑车辆 OBU和基站 RSU构成的最小网络（RSU→OBU），如图 2所示。OBU 有效传输半径Ro=300 m，初始坐标为（280,10）。RSU有效传输半径Rr=1 000 m，初始坐标为（1,10）。应用层传输视频，MAC层为IEEE 802.11p协议。从0时刻起，RSU向OBU发送视频，此时两者距离为d=279 m。从第10 s开始，OBU以车速vi=30 m/s向目的坐标（900,10）移动，此后OBU与RSU的距离d随时间逐渐增大。根据NS2仿真trace文件，OBU和RSU之间的部分数据帧记录如表1所示。

图2 车辆OBU和基站RSU传输示意

表1中第二列为事件类型，“s”、“r”及“d”分别代表“发送”、“接收”及“丢弃”；第三列为事件发生的时刻，单位为 s；第四列为事件所在节点代号，“0”代表 RSU 发送节点，“1”代表OBU接收节点；第五列为协议层，“RTR（router）”及“MAC”分别代表有关事件发生在“网络层”及“MAC层”；第六至八列分别代表分组丢失原因、帧序号与帧类型。DUP、CBK和 RET分别代表 3种不同的分组丢失原因 DROP_MAC_DUPLICATE、DROP_RTR_MAC_ CALLBACK 和DROP_ MAC_ RETRY_ COUNT_ EXCEEDED。

表1显示，随着车辆OBU逐渐远离基站RSU，传输过程经历了3个阶段。

第一阶段（记录号为2～5），当RSU在OBU的300 m有效传输半径内，273号视频帧正常发送且被OBU接收，随后RSU也收到了来自OBU的ACK确认，二帧交换顺利完成。可以发现，当 ACK确认帧在t=10.639 06 s被收到时，两节点距离d=298.2 m。

第二阶段（记录号为14～16），RSU发送的274号视频帧被OBU接收，随后OBU于t=10.736 504 s发送了ACK确认帧，由于节点移动已达 0.736 504 s，即OBU向东移动22 m，此时两节点相距d=301 m，该距离小于RSU传输半径Rr，却大于OBU传输半径Ro。但OBU仅能在300 m内实现有效通信，所以RSU无法接收到该ACK帧。

第三阶段（记录号为18～44），由于收不到ACK确认，RSU开启MAC层重传。但在第二阶段OBU已经正确接收了 274号视频帧，因此 OBU以duplicate（DUP）重复，丢弃了重传的274号视频帧，并继续对RSU发送ACK确认帧，但因为两者距离进一步拉大，第二次ACK确认帧仍然无法被RSU接收。以上过程共计重复了7次，达到了MAC层规定的最大重传次数，RSU最终放弃重传，并在MAC层以“重传次数超限（RET，retry）”原因丢弃274号帧，同时在网络层以“链路层断开（CBK，call back）”原因丢弃包含该视频帧的IP分组。此后，网络层开始重新路由，但 OBU同样无法将AODV路由帧发送至RSU，两者间仍然无法通信。

以上分析说明，当OBU与RSU的距离d大于Ro，由于 ACK帧传输失败，一跳通信将会中断。因此车辆移动过程中，MAC层遵守如下通信规则。

1）d＜Ro，两者可以进行一跳直接通信。

2）d＞Ro，两者无法进行一跳直接通信。

而文献[6-9]的一跳直接传输的距离假设（d＜Rr），会高估一跳传输的下载量。所以OBU传输半径Ro是流量建模必须考虑的因素。

2.2 同向转发的信道竞争问题

两跳转发（RSU→OBU1→OBU）的信道竞争过程为：1） RSU占用信道将数据发往车辆OBU1；2） OBU1占用信道将数据转发至目标车辆OBU。文献[6]假定上述2个过程互相独立，RSU与OBU1作为2个独立的源节点公平地竞争信道。

但本文认为，OBU1转发的数据帧来自源节点RSU、OBU1待发数据帧并争用信道的前提，是RSU成功地发送了数据帧。因此，OBU1并非独立的源节点。VCoDS模型可能会低估转发状态的下载流量，因此流量模型也需要进一步改进。

表1 NS2仿真IEEE802.11p传输Trace记录

2.3 视频流媒体下载问题

文献[6-7,9]均以固定传输速率传输电影文件，基于CBR协议的下载具有简单、易于实现的特点，但缺点是对文件传输的容错度较低，为保证文件下载的完整性，缺失或错误的数据块必须等待目标车辆进入下一个基站区域后重新下载[7]，这既不符合移动用户的观影习惯，也会增加文件传输时间。

相较CBR协议下载，“边下载边观看”的流媒体传输更适合移动客户端。流媒体的优点是发送速率并不恒定，占用带宽小，对丢帧的容错性更好，一般不需要考虑数据块重传问题。流媒体的传输经验表明，视频下载缓冲的时间要尽可能少，视频帧的少量丢失并不会对视频播放带来很大影响。相较某些画面的解码错误，用户对播放的卡顿更为敏感。所以，有必要针对视频流应用，研究车联网协助下载问题。

3 同向多跳下载流量的改进建模

由于建模结果要与NS2仿真值进行比较，为了避免转发车辆不存在造成NS2仿真流量为0的情况（概率上可能发生），本文先假定车辆密度足够大，即目标车辆在行驶中总能找到转发节点，这样建模得到的数值均为最大可达流量。

3.1 车联网一般吞吐量模型

考虑RSU在2Ro范围内有n个车辆节点，假设任一车辆节点i在某个随机时隙内发送一个数据帧的概率为τ，该数据帧与其他节点发出的数据帧发生碰撞的概率为η。在n一定时，有如下关系。

根据Bianchi利用马尔可夫链的建模，m为最大重传次数，CWmin为最小竞争窗口值，令W=CWmin，有

通过联立式（1）与式（2），可求解τ的数值解。

Tdata为一帧中的数据传输时长，Tσ为信道空闲的平均时间，Tdifs、Tsifs及TACK分别为分布式帧间间隙、短帧间间隙及 ACK帧传输时间。IEEE 802.11p的MAC层数据传输效率[6]为长为发送节点数n=1，根据式（3），有数据传输效率ψ（n=1）。IEEE 802.11p协议标称的数据速率为ωMbit/s。由于车辆密度足够大，考虑目标车辆存在概率Pv=1，则改进模型的一跳直接流量为

3.2 同向下载流量建模

3.2.1 一跳下载流量

当目标车辆OBU进入RSU通信范围，根据2.1节的分析，此时OBU无法与RSU直接通信，直至RSU进入车辆OBU的通信范围，一跳的直接下载才能进行。因此车辆 OBU的一跳直接下载时

3.2.2 两跳下载流量

随着OBU与RSU距离增加，两者进入转发下载状态。在“两跳下载”（RSU→OBU1→OBU）环境下，假设转发节点能迅速地转发数据帧，不会因带宽有限导致数据帧在转发节点处排队。在一个时隙中至少有一个帧在传输的概率为Ptr，有且仅有一个帧传输成功的概率为Ps，有

OBU1“有帧待发”的前提是RSU成功发送一个帧。所以一个时隙中，OBU1有帧待发的概率为Pf=Ptr（2）Ps（2），则 OBU1节点无帧待发的概率为1-Ptr（2）Ps（2）。下面分 2 种情况，讨论转发过程中的信道竞争问题。

情况1 当OBU1有帧待发。由于RSU也处于有帧待发状态，相当于RSU与OBU1公平竞争信道，则有发送节点数n=2 及τ（n=2）。根据式（3），可计算两节点争用信道的传输效率ψ（2）。

情况2 当OBU1无帧待发。由于只有RSU处于有帧待发状态，相当于回到“一跳”状态，此时除了 RSU，没有其他节点发送，则有发送节点数n=1 及τ（n=1）。根据式（3），可计算一节点争用信道的传输效率ψ（1）。

根据以上2种情况，改进模型的两跳流量为

3.2.3 三跳下载流量

与两跳流量类似，三跳下载（RSU→OBU1→OBU2→OBU）的转发节点也不是独立地随机发送。同样假定转发不会出现排队，OBU1有帧待发必须要RSU成功发送一个帧，而RSU成功发送一个帧，又需要与另外的2个节点竞争信道。所以一个时隙中，OBU1有帧待发的概率为Pf=Ptr（3）Ps（3），则 OBU1节点无帧待发的概率为 1-Ptr（3）Ps（3）。

情况1 当OBU1有帧待发。RSU与OBU2处于有帧待发状态，相当于3个节点公平竞争信道，则有发送节点数n=3 及τ（n=3）。根据式（3），可计算三节点争用信道的传输效率ψ（3）。

情况2 当OBU1无帧待发。即RSU与OBU2均可能发送，有发送节点数n=2 及τ（n=2）。根据式（3），可计算两节点争用信道的传输效率ψ（2）。

结合以上2种情况，改进模型的三跳流量为

式（7）、式（8）也可根据式（3）或式（5）及式（6）的定义展开。

3.2.4 四跳及五跳下载流量

以上分析的两跳及三跳流量，都假设转发节点能迅速地转发数据帧，不会因带宽有限而造成数据帧在转发节点处排队。但随着跳数的增加，可用带宽迅速下降，转发节点处可能产生分组队列，此时考虑排队因素，会使流量建模更加复杂。另一方面，第四、五跳在前五跳总流量中所占比重并不大。为了简化建模及计算，以第三跳流量的一半作为第四跳流量，以第四跳流量的一半作为第五跳流量，近似有

3.3 仿真验证

车辆单元OBU有效传输半径Ro分别为1 000 m、600 m、300 m和150 m，路边单元RSU有效传输半径Rr=1 000 m。目标车辆OBU以车速vi=30m/s穿越基站RSU。为了尽可能达到流量上限，NS2仿真设定车辆密度足够大，应用层选用发送速率 3 Mbit/s且分组长度 1 000 B的 CBR协议。IEEE 802.11p协议MAC层参数设置如表2所示，其中标称速率ω为3 Mbit/s，保证实验流量处于满载状态。OBU传输半径Ro分别在4种情况下，NS仿真、改进模型与VCoDS模型的下载流量如表3～表6所示。

表2 IEEE802.11p协议MAC层参数设置

分析表3～表6，可以得到以下三点结论。

首先，分析第一跳流量。在Ro的4种情况下，改进模型的第一跳流量都较好地符合 NS仿真。而VCoDS模型的一跳流量始终在165 Mbit附近，而且随着Ro的减小，其与NS仿真的误差逐渐增大。在车速条件相同时，一跳传输的流量由通信双方中有效通信范围较小的一方决定。VCoDS模型假定RSU通信覆盖范围内一跳直接可达，所以会高估一跳传输的流量。数据显示，一跳流量占总流量的比重最大，一般达到50%，是值得重视的传输环节。

表3 NS仿真、改进模型及VCoDS模型各跳流量对比（Ro=1 000 m）

表4 NS仿真、改进模型及VCoDS模型各跳流量对比（Ro=600 m）

表5 NS仿真、改进模型及VCoDS模型各跳流量对比（Ro=300 m）

表6 NS仿真、改进模型及VCoDS模型各跳流量对比（Ro=150 m）

其次，分析第二、三跳流量。在Ro的4种取值下，VCoDS模型计算值都比NS仿真值低，而改进模型则较好地符合NS仿真。这是由于VCoDS模型假设源节点与转发节点在持续而公平地竞争信道。而实际上，一旦转发节点快速地将某帧转发完成，此刻转发节点就不再争用信道，源节点 RSU可单独发送数据帧。由于高估了转发节点争用信道的程度，VCoDS模型的计算值偏低。数据显示，二跳至三跳合计流量占总流量的35%。因此二至三跳的转发对提高下载性能是有益的。

再次，分析第四、五跳流量。由于第四、五跳的流量没有精确建模，所以在Ro=1 000 m时，相较NS仿真，改进模型的第四、五跳流量的误差偏大，但在其他3种Ro值时，仍可较准确地预测流量。另外，由于第四、五跳流量在总流量中所占份额比较小，这种估算也未给下载总流量带来较大误差。数据显示，四跳及五跳合计占比约 15%，显示三跳以上的转发性能下降明显，多跳传输仅对轻负载应用有一定程度的帮助。

4 同向与对向协助下载QoS方案

针对流媒体特性，本文提出同向与对向协助下载（SODCD-QoS，same and opposite direction cooperative downloading）方案。一方面，RSU利用同向协助车辆实现与目标车辆的多跳传输；另一方面，对向协助车辆将数据一跳直接传输至目标车辆。

4.1 视频流媒体特性

以本文传输的视频为例，MPEG（moving picture experts group）对YUV（一种彩色电视编码方法）格式的原始视频进行压缩转码，得到周期性图像组（GOP，group of pictures）为单位的 mp4 文件，再将mp4文件转换为视频st文件，其视频帧编码信息如表7所示。表中第二列为视频帧类型，根据不同的画面类型，GOP可分为内部编码I帧、前向预测P帧及双向内插B帧。第三列为原始视频帧长度；第四列的含义为原始视频帧以1 024 B长度切割后，在传输层的分组数量；第五列为原始视频帧发送时刻。源端按照st文件设定的发送次序及发送时刻依次传输各视频帧。

表7 视频st文件示例

观察表7第一至四行记录，在时间区间（0, 0.235） s，视频流媒体的平均发送速率仅为0.208 2 Mbit/s，可见视频流媒体具有发送速率偏低、发送不连续且信道占用率不高的特性。

当目标车辆远离RSU，同向可用带宽随着传输跳数的增加而减小。对恒定速率发送的CBR应用而言，多跳转发容易造成转发节点缓冲区排队，进而导致数据帧延迟甚至丢失。但由于视频流媒体的轻负载特性，多跳传输模式可以基本满足其传输要求。

4.2 同向协助下载设计

由于VCoDS算法不支持两跳以上的协助下载，算法从两跳协助下载结束到重新接近下一个 RSU恢复两跳传输，中间的传输“空白区”没有充分利用。

因此本文考虑，一旦RSU不在OBU通信范围内（d＞Ro），只要有合适的同向协助车辆，则进入多跳转发下载。直至OBU离开RSU通信范围（d＞Rr），进入“盲区”，多跳的协助下载仍可继续。如果存在同向协助车辆，盲区中的多跳协助下载，理论上可以扩展到动态路由算法支持的最大转发跳数。

设某时刻目标车辆OBU与RSU之间距离的绝对值为d，同向下载方案如下。

1）d≤Ro，执行同向一跳直接下载。

2）d＞Ro，执行同向多跳协助下载。

3） 当同向多跳协助节点不再存在，同向协助下载终止。

同向协助下载伪代码如下。

4.3 对向协助下载设计

对向协助下载分为3个步骤。1） 服务器将未能完成的下载任务委托后方 RSU；2） 在对向车流中筛选出符合条件的对向协助节点；3） 根据用户不同的QoS选车策略，选择合适的对向协助节点完成数据协助传输任务。

4.3.1 冗余任务分解

目标车辆终止同向多跳传输后，服务器再分配后方 RSU加载数据至对向车辆，会导致等待时间增加。因此，当目标车辆在第一个 RSU注册时，服务器就可与后方 RSU协调分配任务。由于视频流媒体发送速率不恒定，再加上同向协助下载的跳数存在不确定性，文献[9]的精确任务分解策略不一定适用。所以，本文基于流媒体特性，提出一种冗余任务分解算法。

目标车辆在RSU注册时，获取当前同向车流所能支持的最大转发跳数 num，对一跳传输不能完成的视频，依次取同等时长的视频段segment[y]，y=1,2,3,…。每个segment[y]时间长度等于一跳对向协助的可传输时长tv，基站间距为DIB，规定若经上述分配后视频还未结束，则将剩余视频内容分配于后方第二个 RSU。定义正整数L，该参数可以根据应用的实际场景动态设置，根据上文流量建模，一般取L=5。任务分解算法思路如下。

1） 当 num＜L，则后方 RSU 从 segment[num+1]开始分配对向数据。

2） 当 num≥L，则后方 RSU 从 segment[L+1]开始分配对向数据。

可见，对低于L跳的同向多跳协助下载，系统认为多跳转发均能顺利完成，后方RSU从多跳转发结束后的视频segment[num+1]开始加载至对向车辆。

对高于L跳的同向多跳协助下载，系统认为第（L+1）跳开始的多跳转发不可靠，后方 RSU 从segment[L+1]开始向对向车辆加载的数据。所以，对向加载的segment[L+1]至segment[num]视频均为冗余数据。如果同向协助传输由于跳数过多而丢失视频，可利用上述对向车辆携带的冗余数据补充缺失的信息。

4.3.2 对向协助的候选节点

并非所有的对向车辆都适合向目标车辆传输数据。要成为对向协助的候选节点，对向（OD，opposite direction）车辆必须满足以下2个约束条件。

1） 数据加载时间条件

设目标车辆的速度vi，对向车辆j的速度vj。高速公路上依次分布的后方基站为RSUk，k=2,3,…。基站位置坐标为 RSUk_x，目标车辆的注册位置坐标为target_x，对向车辆j的注册位置坐标为ODj_x，j=1,2,3,…。通过车辆定期发送的广播消息，基站RSUk可获取附近对向车辆的相关行驶信息，所有车辆OBU传输半径均为Ro。

对向协助车辆j与目标车辆可传输时长为

对向车辆j与基站RSUk间距离为

Dj值可为负数或零，后方 RSUk与对向车辆j传输数据的预估时长为

为了最大限度利用协助车辆传输数据，保证对向车辆能从后方RSU加载到合适大小的协助数据，对向协助的候选节点应满足以下时间条件

对于后方RSU，如果te＜tv，表示该对向节点没有足够时间从 RSU处下载到合适的数据，为避免RSU频繁向某些对向车辆加载少量数据，则基站放弃这类节点。如果te≥tv，表示该对向节点具备充足的时间从后方 RSU处下载到数据，则该对向车辆j可作为协作候选节点。

2） 对向协助位置条件

同向一跳下载的流量占比高，所以对向协助传输不能干扰目标车辆与基站RSU的一跳下载。本文考虑以两车相遇的位置信息，判断是否会发生冲突。

基站估计的对向车辆j开始对向协助传输的位置为

为了保证对向传输不干扰同向的一跳传输，对向协助的候选节点还应满足以下位置条件

如满足式（16），对向车辆j可作为协作候选节点。否则，表示对向车辆将在基站附近的位置区间（RSUk_x-Ro, RSUk_x+Ro）内与目标车辆相遇并通信，则后方基站放弃该节点。

4.3.3 QoS选车策略

将同时满足式（14）与式（16）的候选车辆，按注册位置坐标自小到大顺序排列，组成一个候选协作车辆集合Q，定义Q集合中相邻车辆之间的距离为od_dh，h=1,2,3,…。根据不同的QoS选车策略，可从Q中选择适合的协作车辆加载数据，每车的数据加载时长仍为tv。

1） 时间优先（time first） QoS 策略

为了尽量减少视频传输时间，候选车辆集合Q中的所有车辆皆可顺序加载协作数据，如图1所示，策略要求选择的相邻协作车辆间距满足od_dh≥0。后方RSU尽可能快地在集合Q中的对向车辆上加载视频，再由以上车辆转发至目标车辆，以节约相邻对向下载之间的等待时间。但该策略下，相邻协作节点因为距离过近，增加了传输冲突的概率。

2） 画质优先（picture quality first）QoS 策略

在不增加过多传输时间的前提下，尽量保证视频的画质。如图1所示，在候选车辆集合Q中，策略要求选择的相邻协作车辆间距满足od_dh≥Ro。车速一定时，相邻对向协助节点之间距离越大，冲突的概率越小。所以该策略选择的相邻对向节点间距od_dh至少为Ro，既可以减少传输冲突带来的画质损失，又不会造成太长的等待延时。

对向协助下载伪代码如下。

① 冗余任务分解

5 算法仿真对比

下面对 SODCD-QoS（简称 QoS）、VCoDS 及DSRelay算法进行NS仿真。实验均满足以下条件：所有RSU有效传输半径Rr=1 000 m，所有车辆OBU有效传输半径Ro=300 m。基站RSU1坐标为（2 000,0），RSU2坐标为（7 000,0），相邻RSU间距5 000 m，后续 RSU坐标依次类推。同向与对向车流的车辆密度为ρ，长度为xm的某路段上，同向与对向车辆数目均满足λ=ρx的泊松分布[15]，则该路段存在n辆车的概率密度函数为层参数设置如表 2所示。NS2视频流媒体仿真平台使用myEvalvid-NT[16]。

本文使用峰值信噪比 PSNR （peak signal to noise ratio）作为视频质量评价指标[17]。PSNR单位为dB，其值越大，表示画质越好。为了直观比较算法的视频传输结果，表8给出了视频质量平均主观评分对应表。另外，图4与图8中的每个PSNR“离散点”代表某一段视频成功传输后统计的画质结果，连接离散点的折线没有画质意义。

表8 视频质量平均主观评分与等级的对应关系

实验 1车辆密度ρ=0.025时，各算法下载过程对比

同向及对向车流的车辆密度ρ=0.025，视频mp4文件6.66 MB（YUV文件216 MB）。车辆速度均为30 m/s。目标车辆初始坐标（1 600,10）。目标车辆的数据下载量及画质参数PSNR分别如图3和图4所示。

图3可见，下载最快的是QoS（time first）算法，其后依次为 QoS（picture quality first）、DSRelay 及VCoDS算法。QoS算法使用同向多跳协助下载，其下载曲线在72 s处才停滞，此后在85 s处就迎来对向协助传输，由于存在同向多跳协助传输，减少了等待对向协助车辆抵达所需的时间，其空窗期仅为13 s，所以能较快地完成下载。而DSRelay算法只支持与基站一跳直接下载，没有同向车辆协助，下载量曲线在21 s处停滞，此后在传输空窗约64 s后，迎来对向协助车辆的数据传输。VCoDS算法只能依靠同向一跳直接与同向两跳协助下载，所以下载量曲线在26.6 s处出现停滞，较DSRelay晚了近6 s，此后在盲区内完全没有数据流量，两基站间的空窗期达135 s，所以下载耗时最长。

图3 车辆密度（ρ=0.025）数据下载对比

图4 车辆密度（ρ=0.025）PSNR对比

图4可见，由于DSRelay算法的协作车辆间距设为 2Ro，可以尽量避免传输冲突，其视频质量最好，所有 20个视频片段的主观评价均为“优”等级。QoS（picture quality）算法的画质较好，主观评价为“优”与“良”的视频数分别是19和1。自76 s起，QoS（picture quality first）算法的传输画质明显高于QoS（time first），说明其选车策略能减少传输冲突，实现画质优先的设计。QoS（time first）算法画质一般，主观评价为“优”与“良”的视频数分别是18和2，由于挑选的对向协助节点之间距离较小，传输冲突增加，在 100 s附近的画质“点”近似垂直下降。最后，VCoDS算法主观评价为“优”与“良”的视频数量分别是19与 1，但曲线的锯齿状振荡显示视频下载出现了周期性卡顿，用户体验难以保证。

另外，QoS算法的PSNR值在50 s至76 s间下降明显，而DSRelay及VCoDS算法在上述区间附近的连线则较为平稳。这是因为后两者在区间的两端只有2个离散数据点，区间内没有任何视频成功传输，而基于多跳协助的QoS算法则可用较低画质的视频填补上述时段，从而有效减少了用户下载视频的等待时间。

实验2 车辆密度对算法性能的影响

双向车流的车辆密度ρ分别取0.006、0.012、0.025、0.05及0.08，视频mp4文件3.33 MB（YUV文件108 MB）。所有车辆速度均为30 m/s。目标车辆均位于坐标（1 600,10）附近。在5种车辆密度条件下，目标车辆的下载时间及平均画质PSNR分别如图5和图6所示。

图5可见，在5种车流密度条件下，文件下载任务最快的是QoS（time first）算法，其后依次为QoS（picture quality first）、DSRelay 及 VCoDS 算法。但图5也显示，随着车流密度的上升，各算法的下载耗时都出现下降，且车辆密度在大于0.025之后，下载耗时开始趋于各自的稳定值。以上现象表明，车辆密度的增加，能够有效减少协助下载时间，但随着车流密度继续增加，对协助下载性能的影响变得越来越小。此外，过大的车流密度还会影响高速公路行车安全，所以车流密度并非越大越好。

图6 不同车辆密度下的算法平均画质PSNR对比

图6可见，在5种车流密度条件下，DSRelay算法的画质最佳，其后依次为 VCoDS算法、QoS（picture quality first）与 QoS（time first）算法。这符合 QoS双向协助算法牺牲画质以换取下载时间的策略。但QoS算法的平均PSNR仍然维持在40 dB以上，并未比前两种算法低很多。

另外，DSRelay与 VCoDS算法的平均画质PSNR值并未随着车辆密度的改变而出现较大的波动。而双向QoS算法的PSNR却在车流密度增加时，出现一定程度的下降。这是由于车辆密度上升，同向转发可以支持更高的跳数，但端到端跨度的增加使多跳链路更为脆弱。一旦有同向节点出现转发问题，就会造成通信中断，重新路由并恢复传输将更加耗时，传输丢失的数据也更多，所以跳数过多的转发会对画质产生不利影响。

实验 3 协助车辆速度正态分布，各算法下载过程对比

双向车流的车辆密度ρ=0.025，视频mp4文件4.995 MB（YUV文件162 MB）。目标车辆初始坐标（1 600,10）。目标车辆速度30 m/s。其他车辆的速度满足均值为25，标准差为5的正态分布[6]。按照高速公路限速规定，车速低于16 m/s则记作16 m/s，高于33 m/s记作33 m/s。协助车辆速度正态分布时，目标车辆的下载量及画质PSNR值分别如图7和图8所示。

图7可见，协助车辆的车速正态分布时，QoS算法的下载耗时较短，其性能优于 VCoDS与DSRelay算法。但相较恒定车速情况，正态分布的车速导致QoS的2种算法的性能差距缩小，显示下载时间也受到车速的影响。DSRelay算法的下载耗时显著增加，对向下载流量出现较多的小停滞，表明因为选车条件变严苛，相邻对向协助下载之间容易出现较短的传输空窗。VCoDS算法的基站间盲区时间仍然较大，下载也最耗时。

图7 车速正态分布情况下数据下载对比

图8 车速正态分布情况下PSNR对比

图 8 显示，QoS（picture quality first）图像质量的画质仍略优于QoS（time first），但画质性能也趋于接近。2种算法传输的15个视频片段，其主观评价为“优”与“良”的数量均分别是13与2。这是由于实验加入车速条件，车间距离的设置不再是决定协作车辆互相干扰的唯一因素，正态分布的车速，增加了对向协助之间发生冲突的可能性，所以画质优先的QoS算法改善画质作用有限。此外，在对向协助下载阶段，即100～120 s时间段，QoS算法出现车序靠后的车辆早于靠前车辆完成视频协助传输的现象，显示车速随机分布给协助传输带来的数据乱序问题，因此目标车辆需要对乱序的视频进行重排。尽管DSRelay算法的所有视频片段主观评价均为“优”，但其在50～100 s时间区间仍然有较长的传输空白。车速正态分布也使VCoDS算法的画质性能出现明显下降，其主观评价为“优”的视频仅有10个。

6 结束语

本文首先研究了车辆通信范围及转发状态下信道竞争问题，建立了同向多跳下载流量改进模型。NS仿真显示，相较以往建模，改进模型可以更准确地估计车联网同向下载流量。其次，根据流量模型与视频流媒体特点，设计了一种基于服务质量的双向协助下载方案。最后，通过NS实验对比，说明新方案能较好地满足视频流媒体QoS要求。

随着用户对观影品质要求的提高，后续工作将研究同向协助跳数对视频传输质量的影响以及设计合理的冗余备份机制以应对协助车辆驶离公路的问题。