随着铁路信息化的高速发展, 铁路网络对移动通信提出了越来越高的要求. 自铁路网络诞生之初, 铁路网络通信主要基于GSM-R^[1]系统, 但由于GSM-R作为一种窄带通信系统, 仅能用于铁路的日常运营管理, 难以实现当前铁路诸多业务的承载, 随后研发了LTE-R^[2]系统. 在LTE-R系统中, 虽然在列车管理运营, 旅客上网冲浪等方面有了更好的支持. 但是, 在高铁网络场景下, 由于列车自身移动速度快, 无线传输的空口资源有限, 仍存在以下问题:

(1) 车地之间无线资源有限, 利用效率低. 由于车地之间空口资源是有限的, 车地之间所有数据都需通过空口链路传输. 链路中的重复流量, 未经压缩的流量, 都会降低车地之间空口资源利用效率.

(2) 车地之间传输稳定性差, 吞吐量低. 由于车地之间是无线传输, 而且是在移动场景下的无线传输, 相比有线传输而言, 稳定性会差, 丢包率高, 进而降低网络吞吐量.

(3) 列车和列车之间传输时延高. 在LTE-R系统中, 列车和列车之间的通信必须经过核心网完成. 由于高铁列车行进速度快, 这种场景下带来的高时延对行车安全有很大隐患.

由于LTE-R系统中存在上述问题无法解决. 本文利用5G技术中移动边缘计算^[3–5](Mobile Edge Computing, MEC)的概念, 将MEC的理念应用到LTE-R系统中, 提出基于移动边缘计算的解决方案. 移动边缘计算由ETSI国际标准组织提出并制定, 是基于5G架构将基站与互联网业务相融合的技术; 是利用无线接入网, 将就近电信用户所需的服务融于云计算能力, 所搭建的电信级服务环境. 具体方案为在LTE-R系统基础上, 分别在高铁车厢和沿途基站部署MEC服务器. 高铁车内的网络请求先发送给车载MEC服务器, 由车载MEC服务器负责和基站处MEC服务器通信, 最后基站处MEC服务器和互联网通信, 完成网络服务的访问.

当分别在车厢和沿途基站部署了MEC服务器之后, 车内的网络请求通过车载MEC服务器发出, 在MEC服务器上采用缓存技术和多流合并技术, 消除无线链路上的重复流量, 提高车地之间无线空口资源利用率. 其次, 车载MEC服务器和基站处MEC服务器通信时采用特定的协议保障机制, 提高车地之间无线传输的速度和稳定性. 最后, 基于基站处MEC服务器的计算能力, 在列车之间传输数据时, 可直接通过基站处MEC服务器传输, 缩短传输时延, 提高列车运行安全.

终上所述, 在原有LTE-R系统基础上, 通过增加基站一侧的MEC服务器和车厢内部的MEC服务器, 可以提高车地之间空口资源利用效率, 保障车地之间无线传输的速度和稳定性, 降低列车之间数据传输时延, 解决现有LTE-R系统存在的问题. 后面章节中, 将详细论述本文如何将MEC技术应用到LTE-R系统中. 其中, 第一章详细讲述了MEC的概念及整体架构. 第二章介绍了MEC在高铁网络架构上的应用.

1 LTE-MEC系统整体概述

边缘计算产业联盟对边缘计算^[6]的定义是指在靠近物或数据源头的网络边缘侧, 融合网络、计算、存储、应用核心能力的开放平台, 就近提供边缘智能服务, 满足行业数字化在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求.

在边缘计算的基础上, 移动边缘计算^[7]的思想是把云计算平台迁移到移动接入网边缘, 试图将传统电信蜂窝网络与互联网业务进行深度融合, 减少移动业务交付的端到端时延, 发掘无线网络的能力, 提升用户体验. 具体来讲, 边缘计算将网络、计算、存储能力从云延伸到网络边缘, 在网络中加入一个逻辑终点, 是云计算结构的组成部分. 通过引入边缘计算的理念, 在网络边缘部署各种服务和缓存内容, 移动核心网络进一步减轻了拥塞, 并且可以有效地服务本地需求.

如图1所示, 是在LTE-R系统中加入MEC服务器之后的架构图. 因MEC服务器自身具备计算、存储、网络等能力, 可以在基站附近提供智能服务, 使原本必须在互联网中处理的业务, 可以下沉到MEC服务器上运行, 从而降低服务响应时延, 优化现有LTE-R系统.

2 MEC在高铁网络架构上的应用 2.1 MEC平台及其在高铁网络中的架构

图2给出了MEC平台^[8]示意, 主要包括MEC平台物理设施层、MEC应用平台及MEC应用层.

(1) MEC平台基础设施层基于通用服务器, 采用网络功能虚拟化的方式, 为MEC应用平台层提供底层硬件的计算、存储等物理资源.

(2) 由MEC的虚拟化管理和应用平台功能组件组成. 其中, MEC虚拟化管理采用以基础设施作为服务的思想, 为应用层提供一个灵活高效、多个应用独立运行的平台环境. MEC应用平台功能组件主要包括流量分析、缓存资源、流量压缩合并、流量分拆、流量解压缩、传输协议优化等功能, 并通过开放的API向上层应用开放.

(3) 基于网络功能虚拟化VM应用架构, 将MEC应用平台功能组件进一步组合封装成虚拟的应用(流量压缩缓存、多流合并、传输协议优化), 并通过标准接口开放给第三方业务应用.

MEC在高铁网络架构中的应用主要是通过在车厢内部署MEC服务器, 以及在LTE-R系统中的轨道基站一侧部署MEC服务器共同实现. 如图3所示, 车内的服务请求, 按照车载网关MEC服务器、基站网关MEC服务器、互联网的顺序进行发送.

在服务请求过程中, 车载网关的MEC服务器具备以下4点功能:

(1) 分析车内请求. 对于可以本地处理的服务请求, 由车载网关的MEC服务器进行本地化处理. 对于不能本地化处理的服务请求, 将以代理的形式, 向互联网发送服务请求.

(2) 缓存网络资源. 列车曾经访问的网络资源, 将被缓存在车载MEC服务器中, 为本地化处理做准备.

(3) 接收并处理来自基站MEC服务器的数据. 由于基站MEC服务器会对流量进行合并及压缩以节省空口带宽资源, 故车载MEC服务器需要对这部分流量进行分拆和解压缩.

(4) 优化无线传输. 配合基站网关的MEC服务器共同提升无线传输的稳定性, 降低丢包率.

在服务请求过程中, 基站网关的MEC服务器有3点功能:

(1) 分析车载MEC服务器的请求, 合并重复流量. 由于基站的空口资源有限, 当基站处MEC服务器分析到车载网关发出多个重复请求后, 基站网关MEC服务器在返回数据时将只返回一份数据.

(2) 压缩流量. 为提高空口资源利用率, 当基站网关MEC服务器向车载网关MEC服务器发送数据时, 将对数据进行压缩.

(3) 优化无线传输. 配合车载网关的MEC服务器共同提升无线传输的稳定性, 降低丢包率.

如图3所示, 在车厢和基站处部署MEC服务器之后, 基于两级MEC服务器的功能, 通过协同配合, 将完成下述功能:

(1) 基于MEC的流量缓存与压缩.

(2) 基于MEC的多流合并.

(3) 车地之间无线传输优化.

(4) 车车之间数据传输时延优化.

在本章接下来的小节中, 将详细介绍以上4点功能.

2.2 基于MEC的流量缓存与压缩

高铁网络中, 车地之间的数据通过无线进行传输. 但由于无线资源有限, 如何在有限的带宽资源下, 确保列车和乘客的需求得到满足, 及确保带宽资源的合理分配及利用, 提高空口带宽利用效用, 成为一个有待解决的问题.

面对该问题, 本节提出两个方案解决上述问题:

(1) 基于MEC服务器, 对静态内容缓存.

(2) 基于MEC服务器, 对单一流量压缩.

如图4所示, 当列车或乘客发送一个内容请求时, 首先会在车载MEC服务器中查找该内容是否存在. 如果车载MEC服务器已经缓存过该内容, 则直接由车载MEC服务器将内容返回, 完成此次内容请求. 这样既可以节省车地之间有限的传输带宽, 同时由于车载MEC服务器本地处理请求, 用户将会有更佳的用户体验.

否则, 如果车载MEC服务器没有缓存过该内容, 则车载MEC服务器将该请求发送给基站MEC服务器, 基站MEC服务器再向互联网进行请求. 当基站MEC服务器收到互联网返回的数据时, 要针对这部分流量做压缩处理, 然后将压缩后的流量发送至列车. 当列车接收到这部分流量时, 先对压缩的流量做解压缩处理, 并选取合适的内容做缓存, 同时将解压后的内容发送至列车或乘客处. 由于在无线链路上传输的是经过压缩之后的流量, 将会降低链路的占用率. 这样, 在无线链路带宽资源有限的前提下, 将可以承载更多业务, 有效提升带宽资源利用效率.

通过上述两个方案, 可以提高车地之间无线资源的利用效率. 同时, 当乘客访问已缓存内容时, 可以获得更好的用户体验.

2.3 基于MEC的多流合并

为了能够提高无线传输资源的利用效率, 针对单个流量、以及静态的互联网内容, 提出了流量压缩和缓存的策略. 但是当无线链路上传输的是多个相同流量, 并且处于动态变化中时, 仅仅压缩流量不足以提高利用率, 同时, 由于内容是动态变化, 车载MEC服务器中也无法实现缓存. 可见, 上一节的方案明显不足以解决这类问题. 这种情况下, 本节提出基于MEC的多流合并策略.

基于MEC的多流合并是指, 当列车或车内乘客发出多个相同请求时, 车载MEC服务器便向基站MEC服务器发送多个相同请求. 但是, 当基站MEC服务器从互联网上获取到数据向车载MEC服务器发送数据时, 会进行流量合并, 只发送一份数据. 车载MEC服务器在获取数据之后, 再将数据分为多份发送至请求者. 整个过程对用户而言, 完全透明. 整个传输过程如图5所示.

由于在无线链路上, 对多个相同流量做流量合并, 因此可以显著消除重复流量的传输, 提高无线链路资源的利用效率. 该功能发挥作用的一个场景是在车内观看直播. 当车内有多个乘客观看同一个直播内容时, 比如体育赛事直播, 乘客请求的数据都是相同的, 且进度也是同步的. 虽然每个用户在请求时, 都发出各自的请求, 但是当数据从互联网返回时, 在基站MEC服务器中会对着多个流量合并为一个流量, 传输给车载MEC服务器. 车载MEC服务器接收到之后, 将数据分别返回给每个请求的用户. 这样, 就在满足用户需求的前提下, 极大压缩了无线链路的传输占用比例, 提高无线链路的利用效率.

2.4 无线传输优化

在高铁网络中, 车地之间的传输采用无线传输. 在高速移动的场景下, 无线链路上较高的误码率以及列车和基站之间的频繁切换, 会导致大量的丢包, 而此刻的丢包并非是是因为网络拥塞引起的, 但由于TCP协议自身特点, TCP会启动不必要的拥塞机制, 造成链路空闲, 浪费发送机会, 导致性能下降^[9]. 为了提升无线链路的TCP性能问题, 本机提出了针对TCP连接的传输优化方案.

如图6所示, 传输过程优化是指对列车和基站之间的TCP连接进行性能优化, 优化的方法是在基站处的MEC服务器和列车上的MEC服务器中分别部署Snoop代理^[10], Snoop方法是一种利用了传输层知识的链路层协议. 以基站处MEC举例, 具体表示为, 在基站的MEC服务器中部署Snoop代理, 该代理监视每条TCP连接的每一个包, 即监视基站发往列车的TCP报文段和收到的ACK, 同时缓存所有未应答的TCP报文段. 该代理通过收到多个重复的ACK, 发生本地超时, 来判断某个报文段在无线链路上丢失, 将缓存中的TCP报文段重传, 扔掉由该报文段丢失引起的重复的ACK, 既能将无线链路上丢失的报文段恢复, 又能防止了发送端TCP收到多个重复的ACK而启动快速重传. 反之对列车上的MEC服务器中的Snoop代理亦是如此. 通过该方案, 将可以改善基站到列车方向的性能, 同时改善列车到基站方向的性能.

在对无线传输优化之前, 由于无线传输不稳定, 造成丢包较为严重. 对于采用TCP协议的应用, 频繁出现丢包导致ACK无法及时确认, 发送端将会以为网络中出现拥塞, 从而降低发送窗口大小, 降低无线链路吞吐量. 在对无线传输优化之后, 对于采用TCP协议的应用, 即使频繁出现丢包, 由于Snoop代理的存在, 并不会减小发送窗口大小, 从而确保无线链路能拥有较大的吞吐量, 优化网络传输性能.

2.5 列车之间数据传输时延优化

对高铁而言, 一个重要特点是列车的行驶速度快. 由于行驶速度快, 列车与列车之间的数据传输时延如果高, 将会给行车安全带来威胁. 传统方案中, 列车之间传输数据需要通过基站传送至核心网, 由核心网传输给中央控制室, 统一转发列车之间的数据. 但由于高铁场景中, 列车行驶速度快, 故该方案的高时延会威胁高铁的行车安全. 为优化列车之间数据传输时延, 本节提出的方案将基于基站MEC服务器做数据传输, 避免经过核心网、中央控制室. 从而有效节省数据传输时延.

基于基站MEC服务器进行数据传输是指, 当两辆高铁列车连接同一个基站, 前方列车采集的数据向其后方列车发送时, 列车通过无线传输先发送至基站处的MEC服务器, 然后基站处MEC服务器将采集的数据, 直接发送至该基站下的另一辆列车.

具体过程如图7所示, 前方行驶的列车, 将列车的运行状态和路面信息先回传至基站侧MEC服务器, 这时如果有其他车辆也连接在该基站下面, MEC服务器则直接将数据发送给该车辆, 无需将数据通过核心网发送至中央控制室, 再由中央控制室发送给其他车辆. 由于节省发送至中央控制室的步骤, 故可以显著降低其他列车接收数据的时延. 因此, 在前面列车发现路面有故障的情况下, 后续列车可以在最短时间接收到故障信息, 采取措施, 避免由于时延过长带来的危险因素, 增加列车行驶过程中的安全系数.

3 试验结果

基于本文提出的方案, 在某铁路局所属路段部署了小规模试验网, 进行了实际网络环境下的测试验证.

3.1 试验环境

试验路段全长X公里, 包含三个基站及一套核心网系统, 拓扑结构如图8所示. 三个基站分别标记为YL-0、YZ-0和YZ-YL-0, 位置关系如图9所示, 其中YZ-YL-0为中间基站, YL-0和YZ-0为两端基站. YZ-0与YZ-YL-0之间的距离为12.4 km, YZ-YL-0和YL-0之间的距离为14.4 km. 基站信号覆盖高铁铁轨以及与铁轨平行的高速公路. 三个基站处均部署了本文提出的MEC基站网关. 基站网关连接至核心网, 通过核心网接入互联网.

本次试验还对一辆列车及一辆汽车进行了改装, 在两辆车上都部署了本文提出的MEC车载网关. 试验时, 使用改装之后的车辆在三个基站附近往返完成相关网络性能试验.

3.2 试验内容及结果

试验一: 网络整体性能. 分别在信号强弱方面选取好、中、差测试点进行测试, 当测试终端附着到基站之后进行FTP上下行传输测试, 获得上下行传输速率.

该试验针对基站的信号强弱做上传下载速度测试, 得到的最大下载速度是129.57 Mbps, 最差下载速度是11.72 Mbps, 该下载速度为后续实验结果限定了下载速度的区间, 即正常的下载结果应介于11.72 Mbps和129.57 Mbps. 网络整体性能优良.

试验二: 车载网关的下载加速试验. 在行驶的车辆中将电脑连接车载网关, 从互联网进行软件下载操作, 分别在车载网关有缓存和无缓存的情况下, 对比下载速度.

通过以上试验数据, 可以发现车载MEC缓存对下载速度的提升十分明显.

试验三: 基站网关的下载加速试验.

在车内使用FTP工具, 下载位于基站网关中的文件, 测试得到下载平均速率为117 Mbps.

在车内使用FTP工具, 下载位于互联网上的文件, 测试得到的下载速率为13 Mbps.

通过对比, 发现当互联网上的数据下沉到基站MEC服务器时, 下载速度明显改善.

试验四: 传输时延优化试验. 在车内使用三组数据ping 不同网关, 每组数据是100个标准ping包, 获取传输时延数据.

试验数据表明, 在车内访问车载网关的平均时延只有0.19 ms, 访问基站网关的平均时延是14.827 ms, 访问互联网的平均时延则是37.867 ms. 采用了MEC基站网关后, 数据传输与处理的时延相比互联网减少23 ms左右. 因此, 将铁路相关数据处理业务下沉至基站可以有效减少服务的响应时间.

4 结语

由于现有GSM-R系统和LTE-R系统无法彻底解决高铁场景下的网络通信中存在的问题, 本文基于5G中边缘计算的思想, 将移动边缘计算技术, 应用到LTE-R系统中, 为MEC技术在高铁通信网络中的研究奠定了基础.

为验证本文方案的有效性, 在真实环境中部署了对应设备并完成了相关试验, 验证了车载网关、基站网关在下载速度和传输时延方面的优势. 在后续工作中, 还将在无线传输优化、降低时延、流量压缩等方面展开进一步研究.