一种基于IP组播实现PIS数据文件的高效传递方法与流程

本发明涉及通信技术领域，具体是一种基于ip组播实现pis数据文件的高效传递方法。

背景技术：

在城市轨交行业中，乘客信息系统(pis)是信息化建设的必要部分，它一般由中心子系统、车站子系统、车载子系统和网络子系统等组成。中心子系统通过网络技术将列车信息、直播视频流、广告信息等推送到车站的播放控制器，由播放控制器根据当前播表的定义对收到的内容进行解释并在显示屏上显示相应的内容。

在网络发生异常的情况下，中心子系统与车站的播放控制器通信中断，此时播放控制器将进入垫播模式，它开始播放存放于播放控制器本地硬盘的视频文件，条件是播放控制器在网络正常时提前获得了垫播文件。

垫播用的视频文件在编辑完成后，首先是上传到中心子系统供审核，审核通过后再传递到各个播放控制器。当前主要采取数据下载/上载的方式，传送协议可以是ftp或者http，角色上可以由中心子系统作为服务端，播放控制器作为客户端，也可以互换设计。

具体到地面pis的工程设计，一般是这样部署的：以线路为单位部署pis，在线路控制中心部署pis的中心子系统；一条线路有若干个车站，典型地在20个左右，每个车站一般会部署一台车站服务器以及若干播放控制器。整个线路的上百个播放控制器都需要在网络正常时下载获得垫播用的视频文件。

考虑到视频文件都很大，每个播控都直接连接中心子系统下载视频文件对中心子系统带来了较大压力，也有采取改进的分级下载方式：首先车站服务器把垫播用的视频文件下载到本地，然后播放控制器再从本地的车站服务器下载垫播用的视频文件。

直接下载和分级下载方案如图1-2所示。

现有的方案本质都是点对点方案，没有很好地利用pis的业务特点，存在以下缺点：

pis中心子系统性能压力大：在大量播放控制器同时下载时，需要应对大量的ftp/http的冲击；

下载时间长：在直接下载模式下，为了降低系统性能压力，一般会采取分组模式，中心子系统通过调度保持合理数目的播放控制器同时参与下载，拉长整体的下载时间。在分级下载模式下，由于分两个阶段，理论时间就至少长了一倍；

存在部署约束：采取分级下载模式是较常用的模式，但必须部署车站服务器，这是先决条件。而对于有轨电车或者建设资金紧张的地铁项目，车站服务器是否一定部署是可以商榷的，这样就带来了两难局面。

技术实现要素：

本发明的目的在于提供一种基于ip组播实现pis数据文件的高效传递方法，以解决上述背景技术中提出的问题。

为实现上述目的，本发明提供如下技术方案：

一种基于ip组播实现pis数据文件的高效传递方法，包含以下步骤：

a、pis中心子系统分析下发的播表文件，确定本次需要推送传递哪些垫播文件到哪些播放控制器；分析后形成关系表；

b、通过点对点的控制流发送給每个播放控制器，每个播放控制器也就清楚了自身需要注意接收哪些垫播文件；

c、中心子系统选择一个待传递的文件，在传递前把本次计划传递的文件基本信息和ip组播组信息通过点对点控制流发送給播放控制器。文件基本信息包括文件名、文件的摘要信息、文件总体大小、文件分片大小和最大序列号；ip组播组信息包括组播组ip和端口号；

d、中心子系统加入对应的组播组，同时延时等一下需要接收该文件的播放控制器也加入该组播组；

e、中心子系统把该文件进行分片，按顺序加上分片的序列号，然后把分片按照顺序发送到组播组中；

f、播放控制器通过步骤b接收到关系表，知道自身需要接收哪些文件；

g、播放控制器接收到步骤c的消息时，判断下面传递的文件是否是自己需要接收的文件，若是就加入对应的组播组接收数据；若不是，则不予处理，也就不加入对应的组播组；

h、加入组播组的各个播放控制器接收组播组中的文件分片，因为文件分片中增加了序列号信息，因此可以清楚地知道整个文件内容是否接收完毕，是否出现了个别异常，若一切都正常则按顺序把多个分片的内容合并为完整的垫播文件；

i、重复步骤c-h，直到把所有的文件传递完毕。

作为本发明的进一步技术方案：对于个别异常，播放控制器在整个大流程结束后进行补帧处理。播放控制器向中心子系统发起“补帧”请求，参数为“文件名+分片序列号”，中心子系统相应地回复发送该文件分片，补帧请求和文件分片回应基于udp的点对点请求和回应方式完成。所述个别异常是指某个序列号的文件分片没有收到。

作为本发明的进一步技术方案：把控制通道与数据通道进一步合一化，控制流信息也通过组播通道进行传递。

作为本发明的进一步技术方案：pis的设备单独划分到一个子网中，可以使用广播方式替代组播方式进行数据传递。

与现有技术相比，本发明的有益效果是：本发明改变传统的点对点传递方式，把握pis业务的特点(实际上各播放控制器需要下载的垫播文件基本是相同的)，采用ip组播的方式来传递垫播文件，借助网络设备进行数据复制，而不是由中心子系统的应用层来完成，从而产生以下优点：1、本发明方案中心子系统不承担数据复制，负载是最轻的；2、本发明方案中不需要对播放控制器进行分组，也不需要分级下载，下载时间更快；3、本发明法案中不需要分级下载，从而不要求一定部署车站服务器。

附图说明

图1为现有技术直接下载的原理图。

图2为现有技术分级下载的原理图。

图3为本发明的原理示意图。

图4本发明的基本流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参阅图1-4，实施例1，一种基于ip组播实现pis数据文件的高效传递方法，包含以下步骤：

a、pis中心子系统分析下发的播表文件，确定本次需要推送传递哪些垫播文件到哪些播放控制器；分析后形成关系表；

b、通过点对点的控制流发送給每个播放控制器，每个播放控制器也就清楚了自身需要注意接收哪些垫播文件；

c、中心子系统选择一个待传递的文件，在传递前把本次计划传递的文件基本信息(文件名、文件的摘要信息、文件总体大小、文件分片大小和最大序列号)和ip组播组信息(组播组ip和端口号)通过点对点控制流发送給播放控制器；

d、中心子系统加入对应的组播组，同时延时等一下需要接收该文件的播放控制器也加入该组播组；

e、中心子系统把该文件进行分片，按顺序加上分片的序列号，然后把分片按照顺序发送到组播组中；

f、播放控制器通过步骤b接收到关系表，知道自身需要接收哪些文件；

g、播放控制器接收到步骤c的消息时，判断下面传递的文件是否是自己需要接收的文件，若是就加入对应的组播组接收数据；若不是，则不予处理，也就不加入对应的组播组；

h、加入组播组的各个播放控制器接收组播组中的文件分片，因为文件分片中增加了序列号信息，因此可以清楚地知道整个文件内容是否接收完毕，是否出现了个别异常(某个序列号的文件分片没有收到)，若一切都正常则按顺序把多个分片的内容合并为完整的垫播文件；

i、重复步骤c-h，直到把所有的文件传递完毕。

实施例2：在实施例1的基础上，对于个别异常，播放控制器在整个大流程结束后进行补帧处理。播放控制器向中心子系统发起“补帧”请求，参数为“文件名+分片序列号”，中心子系统相应地回复发送该文件分片，补帧请求和文件分片回应基于udp的点对点请求和回应方式完成。

本发明使用ip组播实现了pis垫播文件的传递，它带来了以下结果：

中心子系统性能开销为传统方案的1/n，n为传统方案的下载客户端的并行数目。传统方案下多个播控或者车站服务器会同时向中心子系统下载文件，即有多个下载的连接，假设数目为n，而本发明方案可以理解仅仅一个连接，因此性能开销是传统方案的1/n；

垫播文件传递时长至少节约一半。假设播放控制器在一段时间里只能接收一个文件的数据，所有播放控制器所需要的垫播文件相同，那么按照本发明方案，垫播文件的传递时长近似于这些文件顺序地通过组播各发送一次的总时长t；而在传统方案中，若采用分级下载模式则传递时长大约为tx2，直接下载模式则更长，可见文件传递时长节约了至少一半左右；

无部署约束：本发明方案中不需要分级下载，从而不要求部署车站服务器。传统方案中的分级下载模式则依赖于车站服务器。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。