CN110099087B - 一种基于融合传输系统的文件传输方法 - Google Patents

一种基于融合传输系统的文件传输方法 Download PDF

Info

Publication number
CN110099087B
CN110099087B CN201810094340.3A CN201810094340A CN110099087B CN 110099087 B CN110099087 B CN 110099087B CN 201810094340 A CN201810094340 A CN 201810094340A CN 110099087 B CN110099087 B CN 110099087B
Authority
CN
China
Prior art keywords
file
source symbol
description information
service
response
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201810094340.3A
Other languages
English (en)
Other versions
CN110099087A (zh
Inventor
南凯
王冬冬
张威
姜红旗
邢观斌
邱翔东
李群
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guoguang Integration Beijing Media Technology Development Co ltd
Original Assignee
Guoguang Integration Beijing Media Technology Development Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guoguang Integration Beijing Media Technology Development Co ltd filed Critical Guoguang Integration Beijing Media Technology Development Co ltd
Priority to CN201810094340.3A priority Critical patent/CN110099087B/zh
Priority to PCT/CN2019/071618 priority patent/WO2019149054A1/zh
Publication of CN110099087A publication Critical patent/CN110099087A/zh
Application granted granted Critical
Publication of CN110099087B publication Critical patent/CN110099087B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1809—Selective-repeat protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/55—Push-based network services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms
    • H04L67/1078—Resource delivery mechanisms
    • H04L67/108—Resource delivery mechanisms characterised by resources being split in blocks or fragments

Abstract

本申请提供一种基于融合传输系统的文件传输方法，所述方法包括：获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端；在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。本申请的文件传输方法在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。

Description

一种基于融合传输系统的文件传输方法
技术领域
本申请涉及通信技术领域，特别涉及一种基于融合传输系统的文件传输方法。
背景技术
卫星移动广播系统是利用地球同步轨道卫星来为信号覆盖区域(可包括一个或多个国家和地区)提供包括音频、视频、数据等在内的多媒体信息服务。卫星移动广播具有覆盖区域广、在开阔地区信号传输稳定、支持终端的高速移动等优点，尤其适合为车载终端提供信息服务。
但是目前卫星移动广播在进行业务数据传输的过程中，业务只能依赖单一的传输服务，比如单独由卫星广播网提供的传输服务或是单独由移动通信网提供的互联网传输服务。
现有技术中，当推送某个文件时，终端只有在特定时间从头到尾将该文件接收完毕后彻底解码才能完成数据的接收。假如文件解码失败，需要服务器侧轮播多遍来实现文件的重传，但是不能避免文件的已接收部分的重复接收，造成冗余数据的产生。
发明内容
有鉴于此，本申请实施例提供了一种基于融合传输系统的文件传输方法及装置、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。
本申请公开了一种基于融合传输系统的文件传输方法，应用于服务器，所述方法包括：
获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端；
在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
本申请公开了一种基于融合传输系统的文件传输方法，应用于终端，所述方法包括：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：
获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端；
在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
本申请公开了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如上所述的用于服务器的文件传输方法的步骤或用于终端的文件传输方法的步骤。
本申请提供的基于融合传输系统的文件传输方法，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
并且，本申请的方法可以准确地查找到需求重传的文件源符号，从而避免文件的已接收部分的重复接收，节省了网络链路资源。
附图说明
图1是本申请实施例的融合传输系统的结构示意图；
图2是本申请实施例的用于服务器侧的基于融合传输系统的协议栈的结构示意图；
图3是本申请实施例的用于终端侧的基于融合传输系统的协议栈的结构示意图；
图4是本申请实施例的融合传输流的结构示意图；
图5是本申请实施例的融合传输块的结构示意图；
图6是本申请实施例的文件编码符号标识的结构示意图；
图7是本申请实施例的每个融合传输流在下一代广播电视无线NGB-W/S信道中的映射过程示意图；
图8是本申请实施例的每个融合传输流在数字卫星广播系统DVB-S信道中的映射过程示意图；
图9是本申请实施例的用于服务器的基于融合传输系统的文件传输方法流程图；
图10是本申请实施例的业务描述信息的结构示意图；
图11是本申请实施例的业务描述信息的扩展信息的结构示意图；
图12是本申请实施例的文件轮播信息的结构示意图；
图13是本申请实施例的文件MD5码的结构示意图；
图14是本申请实施例的文件名的结构示意图；
图15是本申请实施例的文件A在融合传输流的四个时间段上进行推送的示意图；
图16是本申请实施例的某个星期的业务编排表；
图17是本申请实施例的第一融合传输块的结构示意图；
图18是本申请实施例的一个业务描述信息封装到两个连续的融合传输块的示意图；
图19是本申请实施例的融合传输流的生成示意图；
图20是本申请实施例的终端在发送UDP重传请求至服务器请求重传的示意图；
图21是本申请实施例的终端在发送HTTP重传请求至服务器请求重传的示意图；
图22是本申请实施例的UDP文件源符号重传请求的结构图；
图23是本申请实施例的UDP文件源符号重传响应的结构图；
图24是本申请实施例的HTTP文件源符号重传响应的结构图；
图25是本申请实施例的用于服务器的基于融合传输系统的文件传输方法流程图；
图26是本申请实施例的用于终端的基于融合传输系统的文件传输方法流程图；
图27是本申请实施例的用于终端的基于融合传输系统的文件传输方法流程图；
图28是本申请实施例的基于融合传输系统的文件传输装置的结构图；
图29是本申请实施例的基于融合传输系统的文件传输装置的结构图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
首先对本申请下文中会涉及的名词术语进行解释。
业务(service)——在广播者的控制下，可以按照时间表分步广播的一系列节目或数据。
卫星移动多媒体(mobile satellite multimedia)——通过卫星通信网络向移动终端提供的多媒体服务，如音视频、点播和数据推送业务。
卫星广播网(satellite broadcast network)——基于地球同步轨道卫星来提供音视频广播和其他信息服务的网络。
移动通信网(mobile communication network)——基于地面基站来提供移动通信和双向数据传输的网络，包括2G/双向/xG。
网络融合传输(network converged transmission)——同一个业务采用卫星广播网和移动通信网两种网络途径来进行传输以提高业务覆盖范围和业务可靠性的传输方式。
传输流(MPEG2-TS，又称TS)——用于音效、图像与数据的通信协定，用来封装音视频媒体数据的复合信息流。
融合传输块(converged transport block)——一种用来承载上层业务数据的定长包结构。
融合传输流(converged transport stream)——由连续的融合传输块组成的可传输多个业务的复合信息流。
物理信道(physical pipe)——占有一定信道资源并且可独立进行编码和调制的物理层信道。
统一资源描述符(uniform resource identifier)——一个用于标识某一互联网资源名称的字符串，该种标识允许用户对任何(包括本地和互联网)的资源通过特定的协议进行交互操作。
文件轮播(file carousel)——将一个文件的原始数据或其编码数据在一个广播信道上持续发送以保证用户接收的传送方式。
业务编排(service orchestration)——一个融合传输流上统一安排各个业务所属的文件的轮播时间段。
源符号(source symbol)——喷泉编码中对文件分割的最小单元。
编码符号(encoding symbol)——喷泉编码中对文件分割的最小单元。
本申请的文件传输方法，主要用于文件推送时。文件的推送包括：文件的点播、文件的轮播、地图文件推送等。
在介绍本申请的技术方案之前，首先对本申请所涉及的融合传输系统的架构进行说明。
融合传输系统10的架构参见图1。在融合传输系统10中，各种业务平台101(如音视频广播业务、数据推送业务等)的输出数据首先提交给融合网关103。融合网关103对各种业务数据进行处理后，生成统一格式的融合传输流。该融合传输流可通过两种方式传输给终端110：一是提交给卫星广播前端设备105，通过卫星广播网106广播发送给所有终端110；另一种是将数据保存于互联网服务器或提交给内容分发网络(Content Delivery Network，CDN)104上的缓存服务器，并提供统一资源描述符(Uniform Resource Identifier，URI)，终端110可主动通过移动通信网107来访问融合传输流数据。
卫星广播网106是利用地球同步轨道卫星来为信号覆盖区域(可包括一个或多个国家和地区)提供包括音频、视频、数据等在内的多媒体信息服务。卫星广播网106具有覆盖区域广、在开阔地区信号传输稳定、支持终端的高速移动等优点，尤其适合为车载终端提供信息服务。
融合传输系统10的基本原理如下：终端110同时接收来自卫星广播网106和来自移动通信网107的信号，一般情况下，终端110优先从卫星广播网106接收业务数据，但当卫星广播网106上接收的数据发生出错或丢失时，终端110将通过移动通信网107的双向链路来重传丢失或出错的业务数据，以保证业务数据接收的可靠性。
大文件传输(Big File Push，BFP)协议主要用来实现基于网络融合传输系统的大文件可靠传输，其中传输的文件大小从几M字节到十几个G字节。BFP协议可支持各种基于文件的非实时业务，如高质量的音视频点播、地图推送等等。
在服务器和终端均设置有基于BFP协议的协议栈，参见图2和图3。融合传输系统中，协议栈均分为三层：业务应用层、融合传输层和物理传输层。
在网络融合传输系统中，业务不再依赖单一的网络传输服务，比如单独由卫星广播网提供的传输服务或是单独由互联通信网提供的互联网传输服务，而是同时依赖于上述两种网络提供的融合传输功能。上述融合传输功能由一个新的协议层——融合传输层来实现。
融合传输层向业务屏蔽了底层网络传输的细节。在系统前端，业务源只需要将数据提交给融合传输层，融合传输层负责将业务数据以推送的形式在卫星广播网上传送，同时为其提供在互联通信网上的访问途径；在终端，融合传输层负责接收并检查卫星广播网上接收的业务数据，并根据需要启动在互联通信网上的重传，并将重传后的业务数据与卫星广播网接收的业务数据整合在一起，提供给上层业务处理。
在实际网络中，需要传送的业务类型多样，各种业务的服务质量(QoS)要求也各不相同。例如，音视频直播业务要求保证节目的实时性，但是容许出现少量的数据丢失；而地图数据更新则需要充分保证其数据的可靠性，对数据实时性则要求较低。因此，为了支持不同的业务类型，融合传输层又进一步划分为两个子层：融合传输流子层和业务特定传输协议子层。
各子层的功能如下：
1)融合传输流(Converged Transport Stream，CTS)子层
融合传输流子层提供了一种统一的格式——融合传输块(Converged TransportBlock，CTB)来封装各种上层业务的数据。融合传输块是具有固定大小的数据块，并且按照产生的顺序进行连续编号，该编号称为融合传输块的块序号。
融合传输流子层支持融合传输块在卫星广播网上的传输。为了适应不同的卫星广播链路，需要进行传输适配，将融合传输块封装到不同的卫星广播链路传输包中。
融合传输流子层支持融合传输块在互联网上的重传，包括单个CTB的重传，也包括多个CTB的重传。其中，重传的多个CTB的块序号可以是连续的，也可以是分散的。
2)业务特定传输协议(SSTP)子层
业务特定传输协议子层是为了保证不同业务的服务质量(QoS)而引入的业务适配层。业务特定传输协议子层包括多种传输协议，每种传输协议都是针对一种类型的业务，以满足该类业务的实时性及可靠性要求。目前，主要的传输协议为：
A.适合实时直播业务的直播流传输协议(LSTP)；
B.适合非实时大文件业务的大文件推送协议(BFP)。
这些传输协议的功能包括如何将业务提交的数据进行处理，此外，传输协议还包括为满足业务需求的特定重传功能及其他业务适配功能。
融合传输流的结构参见图4，融合传输块的结构参见图5。
融合传输流是由连续编号的定长数据块——融合传输块(CTB)组成的复合信息流，可以用来承载各种类型的上层业务数据，如图4所示。
一般来说，在一个融合传输系统中存在多个并行传输的融合传输流，每个融合传输流都放在一定的物理信道或逻辑信道上传送，当底层信道的调制编码方案确定时，一个融合传输流的传输速率是恒定的。为了区分不同的融合传输流，系统给每个融合传输流分配一个12位的标识，称为融合传输流标识(CTS-ID)。
融合传输块是传输业务信息的基本单元。对于一个融合传输流来说，其融合传输块的大小是固定的，主要由该融合传输流所占用的物理信道协议来决定。例如，当采用NGB-W/S信道时，融合传输块的大小固定为2118字节。
融合传输块由块头、块净荷和校验字段三部分组成，其中块头大小固定为5个字节，结构如图5所示。
其中，块头又进一步包括以下字段：
块序号——32位比特，用来对同一个融合传输流中的融合传输块进行循环编号，块序号从0开始，当达到最大值232－1后，又从0开始编号。
业务类型——3位比特，用来指示融合传输块中封装的业务数据的类型，如表1所示。当业务类型为空业务时，融合传输块中的数据采用随机数据进行填充。
校验指示——1位比特，值为1时表示融合传输块末尾有校验字段CRC32，值为0则无此校验字段。
校验字段(CRC32)——32位比特，为校验字段，当校验指示为1时存在，该字段对文件传输块的块头和块净荷所有字节进行校验。
表1
值 描述
1 文件流传输业务
2 大文件推送业务
3 控制消息业务
7 空业务
其他 待定
具体地，用于服务器端的协议栈如图2所示，包括：
业务应用层，包括用于存储待发送文件的文件单元。
为了直播或推送一个文件，需要将该文件添加到一个业务中。每个业务对应有至少一个文件，对应地，每个文件单元存储添加至一个业务中的文件。
在融合传输系统中，每个业务对应着一个融合传输流，因此，在将文件添加到业务的过程中，也相当于为该文件指定了融合传输流。
融合传输层，包括业务特定传输协议子层和融合传输流子层。
业务特定传输协议子层包括有至少一个用于对待发送文件进行前置处理生成原始数据的实体单元。实体单元与文件单元之间形成有传输待发送文件的数据通道，实体单元通过该数据通道接收待发送文件，然后对待发送文件进行前置处理。需要注意的是，每个实体单元对应至少一个文件单元。
业务特定传输协议子层可以支持多种协议，本实施例以大文件推送BFP协议为例进行说明，来支持推送业务。对应地，实体单元为BFP实体单元。
在推送业务时，实体单元将待发送文件进行编码生成文件编码符号，根据待发送文件生成对应的文件描述信息，将文件描述信息添加对应的业务描述信息头，以生成业务描述信息。其中，业务描述信息和文件编码符号形成原始数据。
在此需要解释的是，在推送业务时，封装有文件编码符号和业务描述信息分别封装于不同的融合传输块中，封装有文件编码符号的融合传输块和业务描述信息的融合传输块并非同时被推送至终端的实体单元。
在一个具体的实施方案中，实体单元对文件进行前向纠错编码(FEC)，所采用的FEC编码算法为Raptor喷泉编码，具体算法参考IETF标准RFC5053。一个文件经过Raptor喷泉编码后，可以生成任意多个编码符号(Encoding Symbol)，其中，每个编码符号的长度是固定的。根据其生成过程，每个编码符号都有一个唯一的32位标识，称为文件编码符号标识(File Encoding Symbol ID,FESI)，根据RFC5053标准，每个FESI由16位的源块号(SBN)和16位的编码符号标识(ESI)组成，如图6所示。
Raptor喷泉编码是一种系统码，在对文件进行编码时首先产生的是文件的源符号，源符号是一种特殊的文件编码符号，每个源符号也有一个FESI。在文件推送过程中，实际发送的是除源符号之外的其他编码符号。当接收端收到的编码符号的数量不足以实现成功解码时，可以通过请求服务器端补发文件的源符号来实现文件的解码。
所以，需要注意的是，在正常传输过程中，服务器只需要向终端传输文件的文件编码符号；在重传过程中，终端则需要向服务器请求文件的文件源符号。
融合传输流子层用于将原始数据封装为融合传输块，并将融合传输块形成的融合传输流经由物理传输层发送至终端。
具体地，物理传输层包括：卫星广播信道和互联网信道。
更为详尽地，融合传输流子层与卫星广播信道之间形成有用于传输融合传输块的数据通道，融合传输流子层与互联网信道之间形成有用于传输融合传输块的数据通道。
下面对卫星广播信道进行详细的说明。卫星广播信道包括：下一代广播电视无线NGB-W/S信道或数字卫星广播系统DVB-S信道；
融合传输流子层将融合传输块封装为适用于NGB-W/S信道或DVB-S信道的广播数据，并经由数据通道发送至NGB-W/S信道或DVB-S信道。
在NGB-W/S信道中，一个或若干个融合传输流可以复合在一个物理管道上传送，每个融合传输流均占用该物理管道上连续调度周期上的固定时段，其映射过程如图7所示。
该融合传输流的每一个融合传输块CTB，均一一映射为一个链路数据包，进一步被链路层封装为一个业务负载包，并交给物理层进行编码调制。
在DVB-S信道中，广播链路采用MPEG2-TS传输流作为业务的输入形式，并未将物理信道划分为若干个独立的物理管道。因此，一个融合传输流可以直接映射到整个物理信道或者自定义的逻辑信道上。
融合传输流中的每个融合传输块将映射到整数个TS包(188字节)中，其映射过程及TS包结构如图8所示。由图8中可见，每个TS包包括包头(4字节)和净荷(184字节)，包头包括：同步字节(8bit)、传输错误指示(1bit)、净荷单元起始指示(1bit)、传输优先级(1bit)、节目标识(13bit)、CTB起始指示(1bit)、CTB结束指示(1bit)、保留(2bit)和TS包循环计数(4bit)。
下面对互联网信道进行详细的说明。互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道。
另外，互联网信道与融合传输流子层之间还形成有用于传输重传请求的消息通道；融合传输流子层经由消息通道接收重传请求，并将封装有融合传输块的重传响应经由数据通道发送至互联网信道。
具体地，融合传输流子层经由消息通道接收UDP信道发送的UDP重传请求，并将封装有融合传输块的UDP重传响应经由数据通道发送至UDP信道；融合传输流子层经由消息通道接收HTTP信道发送的HTTP重传请求，并将封装有融合传输块的HTTP重传响应经由数据通道发送至HTTP信道。
需要注意的是，对于互联网信道中，UDP信道和HTTP信道是并存的，具体使用哪个信道，是由终端在发送重传请求时决定。当请求重传的融合传输块的数据量小于阈值时，融合传输流子层通过UDP信道接收UDP重传请求和发送UDP重传响应；当请求重传的融合传输块的数据量大于阈值时，融合传输流子层通过HTTP信道接收HTTP重传请求和发送HTTP重传响应。
具体地，用于终端的协议栈如图3所示，包括：业务应用层、融合传输层和物理传输层。
业务应用层包括用于接收待处理文件的原始数据的文件单元。
融合传输层包括业务特定传输协议子层和融合传输流子层。
业务特定传输协议子层包括有至少一个用于将融合传输块进行解析生成原始数据的实体单元；每个实体单元与文件单元之间形成有传输待发送文件的原始数据的数据通道，每个实体单元与融合传输流子层之间形成有用于传输融合传输块的数据通道。
业务特定传输协议子层可以支持多种协议，本实施例以BFP协议为例进行说明。
在推送业务时，实体单元将融合传输块进行解析生成原始数据，包括：
将融合传输块解封装，得到文件编码符号和业务描述信息。其中，所述原始数据包括业务描述信息和文件编码符号，所述业务描述信息为将所述待发送文件的文件描述信息添加对应的业务描述信息头而生成。
在此需要解释的是，在推送业务时，封装有文件编码符号和业务描述信息分别封装于不同的融合传输块中，封装有文件编码符号的融合传输块和业务描述信息的融合传输块并非同时被推送至终端的实体单元。实体单元会先对封装有业务描述信息的融合传输块进行解封装，以得到业务描述信息，并以此为依据建立所需文件的文件表，然后再去接收封装有文件编码符号的融合传输块并解析。
另外，融合传输流子层与实体单元之间形成有用于传输融合传输块的数据通道，用于经由卫星广播信道接收数据以及经由互联网信道发送重传请求和接收服务器的重传数据。
物理传输层与所述融合传输流子层之间形成有用于传输所述融合传输块的数据通道。具体地，物理传输层包括：卫星广播信道和互联网信道。
卫星广播信道与融合传输流子层元之间形成有用于传输融合传输块的数据通道。具体地，卫星广播信道包括：NGB-W/S信道或DVB-S信道，融合传输流子层将所述NGB-W/S信道或所述DVB-S信道的广播数据解封装为融合传输块，并将融合传输块经由数据通道发送至所述实体单元。
关于NGB-W/S信道以及DVB-S信道，前述内容已经做了详细介绍，在此便不再展开赘述。
互联网信道与融合传输流子层之间形成有用于传输所述融合传输块的数据通道，互联网信道与融合传输流子层之间还形成有用于传输重传请求的消息通道。融合传输流子层经由消息通道发送重传请求，并经由数据通道接收所述互联网信道发送的封装有融合传输块的重传响应。
更为具体地，互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
融合传输流子层经由所述消息通道发送UDP重传请求至UDP信道，并经由数据通道接收UDP信道发送的封装有融合传输块的UDP重传响应；
融合传输流子层经由所述消息通道接收HTTP重传请求至HTTP信道，并经由数据通道接收HTTP信道发送的封装有融合传输块的HTTP重传响应。
需要注意的是，对于互联网信道中，UDP信道和HTTP信道是并存的，具体使用哪个信道，是由终端在发送重传请求时决定。当请求重传的融合传输块的数据量小于阈值时，融合传输流子层通过UDP信道发送UDP重传请求和接收UDP重传响应；当请求重传的融合传输块的数据量大于阈值时，融合传输流子层通过HTTP信道发送HTTP重传请求和接收HTTP重传响应。
具体地，终端的融合传输流子层判断重传数据的数据量是否小于一个UDP重传响应的报文阈值，若是，则采用UDP信道发送UDP重传请求和接收UDP重传响应；若否，则采用HTTP信道发送HTTP重传请求和接收HTTP重传响应。
可见，在终端解码失败需要重传的过程中，由终端发起重传过程，且终端也主动决策了重传信道的选择；对于服务器，则被动地选择与终端的重传信道相同的互联网信道。
本申请的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
上述为对本申请公开的协议栈的架构进行了详细的说明。该协议栈为融合传输系统的运行提供了支撑。
本申请中，提供了一种基于融合传输系统的文件传输方法和装置、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。与协议栈的描述相同，本实施例的文件传输的方法也分别对终端侧和服务器侧进行描述。
本申请一实施例公开了一种基于融合传输系统的文件传输方法，参见图9，应用于服务器端，方法包括：
901、获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端。
具体地，BFP实体获取待推送的文件的文件编码符号以及文件对应的文件描述信息，融合传输流子层将文件描述信息以及待推送的所述文件的文件编码符号通过卫星广播信道封装为融合传输流发送至终端。
在融合传输流中，除了传输经过FEC编码后的文件数据(即编码符号)外，还需要传输一些与传送文件相关的描述信息，例如，传送文件的大小、文件的MD5、文件FEC编码参数等等，这些信息可以辅助业务的接收和解码，称为业务描述信息(Service DescriptionInformation,SDI)。
在每个业务编排周期，可生成一个或多个与该业务编排周期相关的业务描述信息。其中，每个业务描述信息既可以包含整个业务编排周期内所有推送文件的描述信息，也可以只包含当前一段时间内推送文件的描述信息，例如，仅包含当天推送文件的描述信息。在一个业务编排周期中，业务描述信息按照其生成的时间顺序来编号，称为更新序号。生成融合传输流时，只需发送最新生成的业务描述信息。
业务描述信息可作为一种系统控制消息插入到融合传输流中传送。为保证接收端能及时获得业务描述信息，业务描述信息应反复发送，其发送间隔可按需设定，例如每5分钟发送一次。另一方面，系统也支持接收端通过移动互联网方式来获取融合传输流的业务描述信息。
具体地，文件的文件描述信息的生成方法包括：将所述文件添加到业务中，并根据业务生成对应的业务描述信息。
需要注意的是，添加到一个业务中的文件为至少一个，每个业务对应着一个融合传输流，因此，在将文件添加到业务的步骤，也实质上是为文件指定了融合传输流。
其中，参见图10，业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息。
业务描述信息头包括：控制消息类型(8bit)、控制消息长度(16bit)、业务编排周期序号(16bit)、描述信息更新序号(8bit)、文件描述信息个数(8bit)；
所述文件描述信息包括：基本信息和扩展信息；
所述基本信息包括：文件描述信息长度(16bit)、全局文件标识(40bit)、文件长度(48bit)、扩展信息指示(1bit)、文件轮播状态指示(3bit)和文件类型(4bit)；
所述扩展信息包括：下一个扩展信息指示(1bit)、扩展信息类型(7bit)、扩展信息长度(16bit)和扩展信息内容(8Nbit)。
对各个字段的解释如下：
控制消息类型——8位比特，指示控制消息的类型：当控制消息为业务描述消息时，该值为0x05；当控制消息为填充消息时，该值为0xFF。
控制消息长度——16位比特，指示业务描述信息的总长度。
业务编排周期序号——16位比特，指示该业务描述信息对应的业务编排周期。这里，设定2017年5月1日到2017年5月7日对应的业务编排周期的序号为1，2017年5月8日到2017年5月14日对应的业务编排周期的序号为2，依此类推。
描述信息更新序号——8位比特，每个业务编排周期内的第一个业务描述信息所对应的更新序号为0，每重新生成一次，则将该更新序号加1。
文件描述信息个数——8位比特，指示该业务描述信息中所包含的文件描述信息的个数，一个业务描述信息中最多可支持256个文件描述信息。
每个文件描述信息由基本信息和若干个扩展信息组成，其中，基本信息包括如下字段：
文件描述信息长度——16位比特，指示文件描述信息的长度，包括基本信息和扩展信息。
全局文件标识——40位比特，标识推送文件，包括20位业务标识和20位局部文件标识。
文件长度——48位比特，指示文件的大小，单位是字节。
扩展信息指示——1位比特，指示在基本信息后面是否有扩展信息，值为1表示有，值为0表示无。
文件轮播状态指示——3位比特，指示该文件的轮播状态，定义见表2。
表2
值 文件轮播状态
0 未定义
1 轮播未启动
2 轮播将在若干秒内启动
3 轮播暂停
4 轮播运行中
5 轮播终止
其他 保留
文件类型——4位比特，指示该文件的类型，具体对应格式待定。
扩展信息进一步描述了文件相关的属性，扩展信息的各字段如下：
下一个扩展信息指示——1位比特，指示在此扩展信息之后是否还有扩展信息：值为1表示有；值为0表示无。
扩展信息类型——7位比特，标识扩展信息的类型，定义见表3。
表3
值 扩展信息类型
1 FEC编码信息
2 文件轮播信息
3 文件MD5码
4 文件名
其他 保留
扩展信息长度——16位比特，指示整个扩展信息的长度，单位是字节。
扩展信息内容——8*N位比特，指示扩展信息的具体内容，具体格式由扩展信息类型决定。
参见表3，FEC编码信息用来传送文件的FEC编码信息，其对应的扩展信息类型为1，扩展信息的内容如图11所示。
FEC编码信息包括：编码符号长度(16bit)、源块数目(16bit)、子块数目(8bit)和符号对齐参数(8bit)。
其中，各个字段的解释如下：
编码符号长度——16位比特，指示在每个编码符号的长度，单位为字节，参考RFC5053中的FEC_OTI参数T。
源块数目——16位比特，指示文件划分的源块数目，参考RFC5053中的FEC_OTI参数Z。
子块数目——8位比特，具体含义参考RFC5053中的FEC_OTI参数N。
符号对齐参数——8位比特，具体含义参考RFC5053中的FEC_OTI参数A1。
参见表3，文件轮播信息用来传送文件的轮播信息，其对应的扩展信息类型为2，扩展信息的内容格式如图12所示。
文件轮播信息包括：剩余轮播时间(24bit)、剩余轮播时间段1*(48bit)，剩余轮播时间段2*(48bit)，……，剩余轮播时间段S*(48bit)，每个剩余轮播时间段包括：轮播时间段起始时间(24bit)和轮播时间段持续时间(24bit)。
其中，各个字段的解释如下：
剩余轮播时间——24位比特，指示该文件剩余的轮播时间，单位为秒，该值为0表示文件轮播结束。
剩余轮播时间段1*，剩余轮播时间段2*，……，剩余轮播时间段S*——均为48位比特，可选字段，指示一个文件当前正在轮播的时间段或等待轮播的下一个或多个时间段；如果文件轮播结束，则无此字段。
轮播时间段起始时间——24位比特，指示轮播时间段在业务编排周期中的相对起始时间，单位为秒。举例来说，假设业务描述信息头中的业务编排周期的序号为2，轮播时间段起始时间为28800，则文件轮播时间段的实际起始时间是2017年5月8日8时0分0秒。
轮播时间段持续时间——24位比特，指示一个轮播时间段持续的时间，单位为秒。
参见表3，文件MD5码用来传送文件的MD5码，其对应的扩展信息类型为3，扩展信息的内容格式如图13所示。
其中，各字段的含义如下：
文件MD5码——128位比特，指示该文件的MD5码。
参见表3，文件名用来传送文件名，其对应的扩展信息类型为4，扩展信息的内容格式如图14所示。
其中，各字段的含义如下：
文件名——变长字段，指示该文件名称，长度N-3，N为扩展信息总长度。
更为详尽地，在步骤901中，将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端，包括：
9011、根据预先存储的业务编排表中的推送时间段，将待推送的所述文件的文件编码符号封装为第一融合传输块。其中，所述业务编排表预先存储有每个文件的推送时间段。
首先对业务编排表以及推送时间段进行解释。
在启动推送之前，必须指定该文件在融合传输流的哪些时间段上传送，我们称这些时间段为推送时间段。如图15所示，文件A在融合传输流的四个时间段上进行推送。
对于一个融合传输流来说，可能同时需要传送多个业务的文件或同一个业务的不同文件，为了保证这些文件的推送时间段不发生冲突，系统采用统一编排来设置各个文件的推送时间段。
一次业务编排涉及的时间段称为一个业务编排周期。业务编排周期可自行选择，例如为一个星期。图16中给出了某个星期的业务编排表。如图16所示，该业务编排周期为七天，共有四个文件(文件A/B/C/D)在该业务编排周期中推送，每个文件均占用多个推送时间段，如文件A占用5个推送时间段(分别为周一到周五的0:00到4:00)、文件B占用5个推送时间段等等。当一个时间段没有被任何文件占用时，称为空业务时间段。
对于每个融合传输流的每个业务编排周期，系统将生成一个业务编排表，来描述业务文件占用融合传输流的情况。业务编排表应包含下述内容：
1)业务编排表的起始时间和结束时间：例如，从2018年1月1日0时0分0秒到2018年1月7日24时0分0秒；
2)推送时间段列表：每一个表项对应一个推送时间段，包括该时间段的起始时间，持续时间(或结束时间)和推送文件的全局文件标识。推送时间段可以按照起始时间来排序，其中起始时间可以采用相对时间(从整个业务编排周期的起始时间开始计算)。
一个业务编排周期的业务编排表应在该业务编排周期开始之前生成，在整个业务编排周期内基本保持不变。如果在业务编排周期中需要对文件推送安排进行调整，则需要同时更新其业务编排表。
下面对第一融合传输块的结构进行说明。如图17所示，第一融合传输块包括：第一融合传输块头、第一融合传输块净荷和校验码；
所述第一融合传输块净荷包括：符号头(40bit)、一个或两个所述文件的文件编码符号标识(32bit)、一个或两个所述文件的文件编码符号字段(8*Tbit)以及填充码(8*Pbit)；
所述符号头包括：业务流内编号(8bit)、局部文件标识(20bit)、符号封装模式(3bit)和保留字段(9bit)。
如图17所示，一个融合传输块中可以封装同一个推送文件的一个或两个文件编码符号。其中，第一融合传输块头中的业务类型为2，第一融合传输块净荷由5个字节的符号头、文件编码符号标识1(FESI1)和文件编码符号字段1(长度为T个字节)、文件编码符号标识2(FESI2)和文件编码符号字段2(长度为T个字节)、填充(P个字节)组成。当融合传输块只封装一个文件编码符号时，文件编码符号标识2和对应的文件编码符号字段2不存在。
当系统采用不同的物理层和链路层协议时，融合传输块的长度会发生变化，参数T和参数P也随之变化，文件编码符号的个数、参数T和参数P由符号头中的符号封装模式来指示。
符号头中的各字段定义如下：
业务流内编号——8位比特，指示该文件所对应的业务在融合传输流内的编号。
局部文件标识——20位比特，指示该文件在所属业务中的标识，该字段和融合传输流标识(CTS_ID)、业务流内编号一起组成该文件的全局文件标识。
符号封装模式——3位比特，指示融合传输块中所封装的文件编码符号的个数、参数T和参数P，如表4所示。其中，模式0和模式1适合于下一代广播电视无线NGB-W/S标准下的融合传输块，模式2和模式3则适合于数字卫星广播系统DVB-S标准下的融合传输块(模式2中一个融合传输块在6个TS包中传输，模式3中一个融合传输块在12个TS包中传输)。
保留字段——作为扩展用。
表4
Figure BDA0001564631420000251
9012、按照设定的时间间隔，将最新生成的业务描述信息封装为第二融合传输块。
业务描述信息作为一种控制消息，将和其他控制消息一起，封装到一个融合传输块或块序号连续的多个融合传输块中。当最后一个融合传输块在封装完业务描述信息后还有剩余空间，可以填充字节0xFF。
第二融合传输块的结构包括：第二融合传输块头、第二融合传输块净荷和校验码；第二融合传输块净荷包括：消息头指示字段和业务描述信息字段。
图18中给出了一个业务描述信息封装到两个连续的融合传输块中的情况。业务描述信息的结构参见前述内容，在此便不再赘述。
当融合传输块传送包括业务描述信息在内的控制消息时，块头中的业务类型为3，块净荷的头两个字节为消息头指示(Head Indicator，HI)字段，其定义如下：
消息头指示字段(HI)——16位比特，指示该块净荷中出现的第一个控制消息头的位置。
该值为0时表示业务描述信息头的起始位置为HI字段后的第一个字节，该值为1则表示业务描述信息头的起始位置为HI字段后的第二个字节，依此类推；当该净荷中无任何业务描述信息头时，该字段指示的是填充字节0xFF的起始位置；如果该净荷中既无任何业务描述信息头又无任何填充，也即该净荷为一个业务描述信息的中间部分，则该字段值为0xFFFF。
9013、将所述第二融合传输块和所述第一融合传输块封装至同一个融合传输流发送至终端。
参见图19，图19为本申请实施例的融合传输流的生成示意图。如图19中所示为将文件A、文件B和文件C生成融合传输流的示意图。需要注意的是，文件A、文件B和文件C属于同一业务，并在业务编排表中处于当前的推送时间段内。服务器根据业务编排表，将上述两种融合传输块合并在一起，生成最终的融合传输流。当业务编排表中的轮播时间段对应为空业务时，既可以发送业务类型为7(即空业务)的融合传输块，也可以重复发送业务描述信息对应的融合传输块。
902、在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将文件的文件源符号封装为文件源符号重传响应发送至终端。
具体地，互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求，文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应。
服务器经由UDP信道接收UDP文件源符号重传请求，服务器将UDP文件源符号重传响应经由UDP信道发出；服务器经由HTTP信道接收HTTP文件源符号重传请求，服务器将HTTP文件源符号重传响应经由HTTP信道发出。
需要注意的是，对于互联网信道中，UDP信道和HTTP信道是并存的，但是UDP信道和HTTP信道只能择一使用。具体地，当终端请求重传的文件源符号数据量小于阈值时，所述服务器通过UDP信道接收所述UDP文件源符号重传请求和发送所述UDP文件源符号重传响应；当终端请求重传的文件源符号数据量大于阈值时，所述服务器通过HTTP信道接收所述HTTP文件源符号重传请求和发送所述HTTP文件源符号重传响应。
参见图20和图21，图20为终端在发送UDP重传请求至服务器请求重传的示意图，图21为终端在发送HTTP重传请求至服务器请求重传的示意图。
参见图22，UDP文件源符号重传请求UDP_CTB_REQ包括：融合传输流协议版本(8bit)、消息报文类型(8bit)、消息报文长度(16bit)、融合传输流标识(12bit)、业务流内编号(12bit)、业务内文件标识(16bit)、重传请求编号(8bit)、请求重传的源符号总数(8bit)、请求的源符号组数(8bit)、每一组文件源符号列表(48bit)和校验码(32bit)；
每一组文件源符号列表(48bit)包括：源块号(16bit)、文件源符号起始标识(16bit)以及文件源符号个数(16bit)。
CTS协议版本——8位比特，指示融合传输流协议的版本，当前值为0x02。
消息报文类型——8位比特，指示UDP消息报文的类型。
消息报文长度——16位比特，指示整个消息报文的字节数，从协议版本开始到第M组ES，包括CRC32。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
业务流内编号——8位比特，指定业流内务编号，和融合传输流标识一起标识了补发文件所在的业务。
业务内文件标识——20位比特，指示文件在业务内的标识，和融合传输流标识、流内业务编号一起组成了文件的全局文件标识，标识了补发的编码符号所属的文件。
请求的源符号总数——8位比特，指示本次补发请求中的源符号的总数。
请求的源符号组数——8位比特，指示本次请求补发的源符号组的数目M，该值决定了后续的源符号组参数的个数。
第一组源符号——48位比特，指示需要重传的第一组编码符号，由16位的源块号(SBN)、16位的ESI起始和16为的源符号个数(ES Number)组成。
第二组源符号、……第M组源符号——均为48位比特，其存在由请求重传的ES组数来决定，均由16位的源块号(SBN)、16位的源符号起始标识(ESI)和16位的源符号个数(ESNumber)组成。
校验码(CRC32)——32位比特，对消息报文进行校验，包括从协议版本到第M组ES参数。
参见图23，UDP文件源符号重传响应UDP_CTB_RESP包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量、至少一个请求的第一融合传输块以及校验码。
各字段含义如下：
融合传输流协议版本——8位比特，指示融合传输流协议的版本，当前值为0x01。
消息报文类型——8位比特，指示UDP消息报文的类型，当消息为UDP_CTB_RESP时该值为0x81。
消息报文长度——16位比特，指示整个消息报文的字节数，从协议版本开始到第N个CTB，包括CRC32。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
每个第一融合传输块的长度——4位比特，指示每个融合传输块的长度，当该指示为0时，表示融合传输块长度为缺省值2118字节。
请求重传的第一融合传输块总数——8位比特，指示本次重传反馈中的第一融合传输块的总数N，决定了后续第一融合传输块的个数。
第一个第一融合传输块、第二个第一融合传输块、……第N个第一融合传输块——指示本次重传反馈中的所有第一融合传输块数据。
校验码(CRC32)——32位比特，对消息报文进行校验，包括从协议版本到第N个校验码。
HTTP文件源符号重传请求包括：URL前缀、端口号、具体目录和请求参数；请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识和请求的源符号列表。
参见图24，HTTP文件源符号重传响应HTTP_CTB_RESP包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量和至少一个请求的第一融合传输块。
各字段含义如下：
响应主体类型——需设置为“application/octet-stream”；
响应主体长度——需设置为实体主体的长度；
响应主体摘要——需设置为实体主体的MD5摘要，用来检测其完整性；
融合传输流协议版本——8位比特，指示融合传输流协议的版本，当前值为0x01。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
单个第一融合传输块的长度——4位比特，指示每个第一融合传输块的长度，当该指示为0时，表示第一融合传输块长度为缺省值2118字节。
请求重传的第一融合传输块总数——16位比特，指示本次重传反馈中的第一融合传输块的总数N，决定了后续第一融合传输块的个数。
第一个第一融合传输块、第二个第一融合传输块、……第N个第一融合传输块——指示本次重传反馈中的所有第一融合传输块数据。
可选地，在本申请的一个示意性的实施方案中，参见图25，本申请实施例的方法包括：
2501、所述服务器接收终端发送的业务描述信息主动请求，并将封装有业务描述信息的业务描述信息重传响应发送至终端。
2502、服务器将待推送的所述文件的文件编码符号封装为融合传输流发送至终端。
2503、服务器在接收到终端发送的文件源符号重传请求后，重新获取请求的文件的文件源符号，将文件的文件源符号封装为文件源符号重传响应发送至终端。
具体地，服务器经由HTTP信道接收终端发送的业务描述信息主动请求，并将封装有业务描述信息的业务描述信息重传响应经由HTTP信道发送至终端。
具体地，业务描述信息主动请求(HTTP_GET_REQ4)包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
所述业务描述信息重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、补发请求编号重传请求编号、每个第二融合传输块的长度、第二融合传输块的数量和至少一个封装有所述业务描述信息的第二融合传输块。
其中，业务描述信息主动请求与HTTP文件源符号重传请求的格式类似，业务描述信息重传响应与HTTP文件源符号重传响应的格式类似。关于各个字段的具体含义，参照前述各个请求和响应报文的具体介绍，在此不再赘述。
本申请提供的基于融合传输系统的文件传输方法，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
并且，本申请的方法可以准确地查找到需求重传的文件源符号，从而避免文件的已接收部分的重复接收，节省了网络链路资源。
需要注意的是，文件推送可以自动关闭或手动关闭。当一个文件在所有推送时间段上都发送完毕后，则自动关闭推送。当采用手动关闭时，则融合传输流将停止在后续的推送时间段上传送该文件，这些清空的推送时间段可重新分配给业务使用。
当一次文件推送关闭后，文件仍然保留在业务中，此时，还可以通过重新设置其播出时间段，再次启动推送。当该文件不再需要进行推送，则可从业务中删除。一个文件从其添加到业务的时间开始计算，到从业务中删除所经过的时间称为该文件的生命期。
上述为用于服务器的基于融合传输系统的文件传输方法，下面介绍用于终端的基于融合传输系统的文件传输方法。
需要注意的是，本申请实施例提供的文件传输方法是基于服务器和终端的交互，所以本实施例的技术特征与上述用于服务器侧的文件传输方法的技术特征有重合之处。在本实施例中未详细介绍的技术细节，可参考上述用于服务器侧的文件传输方法中的介绍。
参见图26，本申请实施例提供了一种基于融合传输系统的文件传输方法，用于终端，包括下述步骤2601～2605。
2601、接收融合传输流中的文件描述信息。
更为具体地，所述终端接收融合传输流中的文件描述信息，包括：所述终端接收融合传输流中的封装有业务描述信息的第二融合传输块，并解析获得文件的文件描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息。
2602、根据所述文件描述信息接收融合传输流中的对应的文件编码符号。
更为具体地，终端根据文件描述信息接收融合传输流中的对应的文件编码符号，包括：所述终端根据所述文件描述信息建立待接收文件列表，并根据接收封装有对应的文件编码符号的第一融合传输块，并解析获得文件编码符号。
终端通过卫星广播信道接收所述服务器发送的所述文件描述信息以及所述文件的文件编码符号。
2603、对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求。
2604、对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号。
终端通过互联网信道发送所述文件源符号重传请求和接收所述文件源符号重传响应。
具体地，互联网信道包括用户数据报协议UDP信道和超文本传输协议HTTP信道；
文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求；所述文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应。
所述终端经由UDP信道发送UDP文件源符号重传请求，所述终端经由UDP信道接收所述UDP文件源符号重传响应；
所述终端经由HTTP信道发送HTTP文件源符号重传请求，所述终端经由HTTP信道接收所述HTTP文件源符号重传响应。
当终端请求重传的文件源符号数据量小于阈值时，所述终端通过UDP信道发送所述UDP文件源符号重传请求和接收所述UDP文件源符号重传响应；当终端请求重传的文件源符号数据量大于阈值时，所述终端通过HTTP信道接收所述HTTP文件源符号重传请求和接收所述HTTP文件源符号重传响应。
具体地，终端判断重传数据的数据量是否小于一个UDP重传响应的报文阈值，若是，则采用UDP信道发送UDP重传请求和接收UDP重传响应；若否，则采用HTTP信道发送HTTP重传请求和接收HTTP重传响应。可见，本申请中的终端起到主动选择互联网信道的作用，而对于服务器侧，只是被动地选择互联网信道。
2605、根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
对于各个请求以及响应的报文的具体格式和各个字段的定义，在前述用于服务器的文件传输方法中已经详细介绍，本实施例便不再赘述。
本申请提供的基于融合传输系统的文件传输方法，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
在本申请的一个实施例中，业务描述信息可以由终端主动请求，以使终端提前建立待接收文件列表。参见图27，本申请的基于融合传输系统的文件传输方法包括：
2701、所述终端发送业务描述信息主动请求至服务器，并接收服务器发送的封装有业务描述信息的业务描述信息重传响应。
2702、根据所述文件描述信息接收融合传输流中的对应的文件编码符号。
2703、对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求。
2704、对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号。
2705、根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
本申请提供的基于融合传输系统的文件传输方法，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
参见图28，本申请实施例公开了一种基于融合传输系统的文件传输装置，设置于服务器端，所述装置包括：
文件发送模块2801，用于获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端。
具体地，文件发送模块2801将所述业务描述信息以及待推送的所述文件的文件编码符号通过卫星广播信道发送至所述终端。
进一步地，文件发送模块2801包括：
文件编码符号封装模块，用于根据预先存储的业务编排表中的推送时间段，将待推送的所述文件的文件编码符号封装为第一融合传输块；其中，所述业务编排表预先存储有每个文件的推送时间段；
业务描述信息封装模块，用于按照设定的时间间隔，将最新生成的业务描述信息封装为第二融合传输块；
融合传输流发送模块，用于将所述第二融合传输块和所述第一融合传输块封装至同一个融合传输流发送至终端。
具体地，第一融合传输块包括：第一融合传输块头、第一融合传输块净荷和校验码；
第一融合传输块净荷包括：符号头、至少一个所述文件的文件编码符号标识、一个或两个所述文件的文件编码符号字段以及填充码；
符号头包括：业务流内编号、局部文件标识、符号封装模式和保留字段。
具体地，第二融合传输块包括：第二融合传输块头、第二融合传输块净荷和校验码；第二融合传输块净荷包括：消息头指示字段和业务描述信息字段。
重传响应模块2802，用于在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
具体地，重传响应模块2802通过互联网信道接收所述文件源符号重传请求和发送所述文件源符号重传响应。
具体地，互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求；文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应。
重传响应模块2802经由UDP信道接收UDP文件源符号重传请求，文件发送模块将所述UDP文件源符号重传响应经由UDP信道发出；重传响应模块2802经由HTTP信道接收HTTP文件源符号重传请求，文件发送模块将所述HTTP文件源符号重传响应经由HTTP信道发出。
当终端请求重传的文件源符号数据量小于阈值时，重传响应模块2802通过UDP信道接收所述UDP文件源符号重传请求和发送所述UDP文件源符号重传响应；当终端请求重传的文件源符号数据量大于阈值时，重传响应模块2802通过HTTP信道接收所述HTTP文件源符号重传请求和发送所述HTTP文件源符号重传响应。
具体地，UDP文件源符号重传请求包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、业务流内编号、业务内文件标识、重传请求编号、请求重传的源符号总数、请求的源符号组数、每一组文件源符号列表和校验码；
每一组所述文件源符号列表包括：源块号、文件源符号起始标识以及文件源符号个数。
具体地，UDP文件源符号重传响应包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量、至少一个请求的第一融合传输块以及校验码。
具体地，HTTP文件源符号重传请求包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表。
具体地，HTTP文件源符号重传响应包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量和至少一个请求的第一融合传输块。
可选地，除去上述模块外，本申请的文件传输装置还包括：
业务描述信息生成模块，用于将所述文件添加到业务中，并根据所述业务生成对应的业务描述信息。其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息。
业务描述信息发送模块，用于接收终端发送的业务描述信息主动请求，并将封装有业务描述信息的业务描述信息重传响应发送至终端。
可选地，业务描述信息主动请求(HTTP_GET_REQ4)包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表；
可选地，业务描述信息重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第二融合传输块的长度、第二融合传输块的数量和至少一个封装有所述业务描述信息的第二融合传输块。
本申请提供的基于融合传输系统的文件传输装置，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
本申请实施例还公开了一种基于融合传输系统的文件传输装置，设置于终端，如图29所示，包括：
文件描述信息接收模块2901，用于接收融合传输流中的文件描述信息。
具体地，文件描述信息接收模块2901通过卫星广播信道接收所述服务器发送的所述文件描述信息。
具体地，文件描述信息接收模块2901接收融合传输流中的文件描述信息，包括：所述文件描述信息接收模块2901接收融合传输流中的封装有业务描述信息的第二融合传输块，并解析获得文件的文件描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息。
文件编码符号接收模块2902，用于根据所述文件描述信息接收融合传输流中的对应的文件编码符号。
具体地，文件编码符号接收模块2902通过卫星广播信道接收所述文件的文件编码符号。
具体地，文件编码符号接收模块2902根据所述文件描述信息接收融合传输流中的对应的文件编码符号，包括：所述文件编码符号接收模块2902根据所述文件描述信息建立待接收文件列表，并根据接收封装有对应的文件编码符号的第一融合传输块，并解析获得所述文件编码符号。
文件编码符号解码模块2903，用于对接收到的所述文件的文件编码符号进行解码，并在确定对整个文件解码失败后，通知文件源符号重传请求模块动作。
文件源符号重传请求模块2904，用于向服务器发送文件源符号重传请求。
具体地，文件源符号重传请求模块2904通过互联网信道发送所述文件源符号重传请求。
文件源符号接收模块2905，用于接收封装有所述文件的文件源符号的文件源符号重传响应并对其进行解析，得到所述文件的文件源符号。
具体地，文件源符号接收模块2905通过互联网信道接收所述文件源符号重传响应。互联网信道包括用户数据报协议UDP信道和超文本传输协议HTTP信道。
文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求；文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应。
文件源符号重传请求模块2904经由UDP信道发送UDP文件源符号重传请求，文件源符号接收模块2905经由UDP信道接收UDP文件源符号重传响应；文件源符号重传请求模块2904经由HTTP信道发送HTTP文件源符号重传请求，文件源符号接收模块2905经由HTTP信道接收HTTP文件源符号重传响应。
当请求重传的文件源符号数据量小于阈值时，文件源符号重传请求模块2904通过UDP信道发送UDP文件源符号重传请求，文件源符号接收模块2905通过UDP信道接收UDP文件源符号重传响应；当请求重传的文件源符号数据量大于阈值时，文件源符号重传请求模块2904通过HTTP信道发送HTTP文件源符号重传请求，文件源符号接收模块2905通过HTTP信道接收HTTP文件源符号重传响应。
关于UDP文件源符号重传请求、UDP文件源符号重传响应、HTTP文件源符号重传请求、HTTP文件源符号重传响应的报文具体格式和字段定义，在前述实施例中已经详细介绍，在此便不再赘述。
文件源符号解码模块2906，用于对所述文件的文件源符号进行解码，并在确定对整个文件解码失败后，通知文件源符号重传请求模块2904动作，直至解码得到整个文件。
可选地，除去上述模块外，本申请的文件传输装置还包括：
业务描述信息请求模块，用于发送业务描述信息主动请求至服务器，并接收服务器发送的封装有业务描述信息的业务描述信息重传响应。
关于业务描述信息主动请求和业务描述信息重传响应的报文具体格式和字段定义，在前述实施例中已经详细介绍，在此便不再赘述。
本申请提供的基于融合传输系统的文件传输装置，在终端对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器将请求的文件源符号封装为文件源符号重传响应发送至终端，以实现终端对文件的全部解码，从而保证文件传输的可靠性。
上述为本实施例的文件传输的装置的示意性方案。需要说明的是，该文件传输的装置的技术方案与上述的文件传输的方法的技术方案属于同一构思，文件传输的装置的技术方案未详细描述的细节内容，均可以参见上述文件传输的方法的技术方案的描述。
本申请一实施例公开了一种计算设备3000，计算设备3000能够访问页面，该计算设备3000的部件包括但不限于存储器3010和处理器3020。处理器3020与存储器3010相连接。
应该知道，计算设备3000还可以包括网络接口，网络接口使得计算设备3000能够经由一个或多个网络通信。这些网络的示例包括局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。网络接口可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。计算设备可以通过网络接口访问页面。
在本申请的一个实施例中，计算设备3000的上述中未示出的其他部件也可以彼此相连接，例如通过总线。
计算设备3000可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备3000还可以是移动式或静止式的服务器。
其中，处理器3020执行所述程序时实现以下步骤：
获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端；
在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
计算设备3100包括存储器3110、处理器3120及存储在存储器3110上并可在处理器3120上运行的计算机程序，其特征在于，所述处理器3120执行所述程序时实现以下步骤：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如前所述用于服务器的基于融合传输系统的文件传输方法的步骤。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如前所述用于终端的基于融合传输系统的文件传输方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的文件传输方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述文件传输方法的技术方案的描述。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (18)

1.一种基于融合传输系统的文件传输方法，应用于服务器，其特征在于，所述方法包括：
将文件添加到业务中，并根据所述业务生成对应的业务描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息；
获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并根据预先存储的业务编排表中的推送时间段，将待推送的所述文件的文件编码符号封装为第一融合传输块；其中，所述业务编排表预先存储有每个文件的推送时间段；
按照设定的时间间隔，将最新生成的业务描述信息封装为第二融合传输块；
将所述第二融合传输块和所述第一融合传输块封装至同一个融合传输流发送至终端；
在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
2.根据权利要求1所述的方法，其特征在于，所述业务描述信息头包括：控制消息类型、控制消息长度、业务编排周期序号、描述信息更新序号、文件描述信息个数；
所述文件描述信息包括：基本信息和扩展信息；
所述基本信息包括：文件描述信息长度、全局文件标识、文件长度、扩展信息指示、文件轮播状态指示和文件类型；
所述扩展信息包括：下一个扩展信息指示、扩展信息类型、扩展信息长度和扩展信息内容。
3.根据权利要求1所述的方法，其特征在于，所述第一融合传输块包括：第一融合传输块头、第一融合传输块净荷和校验码；
所述第一融合传输块净荷包括：符号头、一个或两个所述文件的文件编码符号标识、一个或两个所述文件的文件编码符号字段以及填充码；
所述符号头包括：业务流内编号、局部文件标识、符号封装模式和保留字段；
所述第二融合传输块包括：第二融合传输块头、第二融合传输块净荷和校验码；
第二融合传输块净荷包括：消息头指示字段和业务描述信息字段。
4.根据权利要求1所述的方法，其特征在于，
所述服务器将所述业务描述信息以及待推送的所述文件的文件编码符号通过卫星广播信道发送至所述终端；
所述服务器通过互联网信道接收所述文件源符号重传请求和发送所述文件源符号重传响应。
5.根据权利要求4所述的方法，其特征在于，
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求；
所述文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应；
所述服务器经由UDP信道接收UDP文件源符号重传请求，所述服务器将所述UDP文件源符号重传响应经由UDP信道发出；
所述服务器经由HTTP信道接收HTTP文件源符号重传请求，所述服务器将所述HTTP文件源符号重传响应经由HTTP信道发出。
6.根据权利要求5所述的方法，其特征在于，
当终端请求重传的文件源符号数据量小于阈值时，所述服务器通过UDP信道接收所述UDP文件源符号重传请求和发送UDP所述文件源符号重传响应；
当终端请求重传的文件源符号数据量大于阈值时，所述服务器通过HTTP信道接收所述HTTP文件源符号重传请求和发送所述HTTP文件源符号重传响应。
7.根据权利要求5所述的方法，其特征在于，
所述UDP文件源符号重传请求包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、业务流内编号、业务内文件标识、重传请求编号、请求重传的源符号总数、请求的源符号组数、每一组文件源符号列表和校验码；
每一组所述文件源符号列表包括：源块号、文件源符号起始标识以及文件源符号个数；
所述UDP文件源符号重传响应包括：
融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量、至少一个请求的第一融合传输块以及校验码。
8.根据权利要求5所述的方法，其特征在于，
所述HTTP文件源符号重传请求包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识和请求的源符号列表；
所述HTTP文件源符号重传响应包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量和至少一个请求的第一融合传输块。
9.根据权利要求1所述的方法，其特征在于，还包括：所述服务器接收终端发送的业务描述信息主动请求，并将封装有业务描述信息的业务描述信息重传响应发送至终端。
10.根据权利要求9所述的方法，其特征在于，
所述业务描述信息主动请求包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表；
所述业务描述信息重传响应包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第二融合传输块的长度、第二融合传输块的数量和至少一个封装有所述业务描述信息的第二融合传输块。
11.一种基于融合传输系统的文件传输方法，应用于终端，其特征在于，所述方法包括：
所述终端接收融合传输流中的封装有业务描述信息的第二融合传输块，并解析获得文件的文件描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息；
所述终端根据所述文件描述信息建立待接收文件列表，并根据接收封装有对应的文件编码符号的第一融合传输块，并解析获得所述文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
12.根据权利要求11所述的方法，其特征在于，所述终端通过卫星广播信道接收所述服务器发送的所述文件描述信息以及所述文件的文件编码符号；
所述终端通过互联网信道发送所述文件源符号重传请求和接收所述文件源符号重传响应。
13.根据权利要求12所述的方法，其特征在于，所述互联网信道包括用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述文件源符号重传请求包括：UDP文件源符号重传请求和HTTP文件源符号重传请求；
所述文件源符号重传响应包括：UDP文件源符号重传响应和HTTP文件源符号重传响应；
所述终端经由UDP信道发送UDP文件源符号重传请求，所述终端经由UDP信道接收所述UDP文件源符号重传响应；
所述终端经由HTTP信道发送HTTP文件源符号重传请求，所述终端经由HTTP信道接收所述HTTP文件源符号重传响应。
14.根据权利要求13所述的方法，其特征在于，
当终端请求重传的文件源符号数据量小于阈值时，所述终端通过UDP信道发送所述UDP文件源符号重传请求和接收所述UDP文件源符号重传响应；
当终端请求重传的文件源符号数据量大于阈值时，所述终端通过HTTP信道接收所述HTTP文件源符号重传请求和接收所述HTTP文件源符号重传响应。
15.根据权利要求11所述的方法，其特征在于，还包括：所述终端发送业务描述信息主动请求至服务器，并接收服务器发送的封装有业务描述信息的业务描述信息重传响应。
16.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现以下步骤：
将文件添加到业务中，并根据所述业务生成对应的业务描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息；
获取待推送的所述文件的文件编码符号以及所述文件对应的文件描述信息，并根据预先存储的业务编排表中的推送时间段，将待推送的所述文件的文件编码符号封装为第一融合传输块；其中，所述业务编排表预先存储有每个文件的推送时间段；
按照设定的时间间隔，将最新生成的业务描述信息封装为第二融合传输块；
将所述第二融合传输块和所述第一融合传输块封装至同一个融合传输流发送至终端；
在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。
17.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现以下步骤：
终端接收融合传输流中的封装有业务描述信息的第二融合传输块，并解析获得文件的文件描述信息；其中，所述业务描述信息包括：业务描述信息头以及该业务中所述文件的文件描述信息；
所述终端根据所述文件描述信息建立待接收文件列表，并根据接收封装有对应的文件编码符号的第一融合传输块，并解析获得所述文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器发送文件源符号重传请求，直至解码得到整个文件。
18.一种计算机可读存储介质，其存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1-10任意一项所述文件传输方法的步骤或权利要求11-15任意一项所述文件传输方法的步骤。
CN201810094340.3A 2018-01-31 2018-01-31 一种基于融合传输系统的文件传输方法 Active CN110099087B (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN201810094340.3A CN110099087B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的文件传输方法
PCT/CN2019/071618 WO2019149054A1 (zh) 2018-01-31 2019-01-14 一种基于融合传输系统的文件传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810094340.3A CN110099087B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的文件传输方法

Publications (2)

Publication Number Publication Date
CN110099087A CN110099087A (zh) 2019-08-06
CN110099087B true CN110099087B (zh) 2021-02-02

Family

ID=67442391

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810094340.3A Active CN110099087B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的文件传输方法

Country Status (2)

Country Link
CN (1) CN110099087B (zh)
WO (1) WO2019149054A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112788078B (zh) * 2019-11-07 2023-03-24 上海哔哩哔哩科技有限公司 数据传输方法、接收装置、发送装置和计算机设备
CN113392055B (zh) * 2020-03-13 2024-01-30 北京小米移动软件有限公司 文件传输方法、文件传输装置及存储介质
CN114845134B (zh) * 2020-10-16 2023-01-24 腾讯科技（深圳）有限公司 文件封装方法、文件传输方法、文件解码方法及相关设备
CN112866294B (zh) * 2021-03-15 2023-03-31 中国电子科技集团公司第十五研究所 一种多协议适配方法、装置及可读存储介质
CN114793183B (zh) * 2022-06-22 2022-09-09 山东致群信息技术股份有限公司 一种基于多源数据处理的分布式融合通讯方法
CN116248778B (zh) * 2023-05-15 2023-08-11 珠海迈科智能科技股份有限公司 一种多协议环境下的数据融合传输方法及系统

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101465791A (zh) * 2007-12-18 2009-06-24 国家广播电影电视总局广播科学研究院 一种基于单向链路的文件传输方法
CN101729997A (zh) * 2008-10-10 2010-06-09 中兴通讯股份有限公司 消息互通方法及融合业务系统
CN101977182A (zh) * 2010-09-03 2011-02-16 中国电影科学技术研究所 一种数字电影传输方法、系统和设备
CN102143137A (zh) * 2010-09-10 2011-08-03 华为技术有限公司 媒体流发送及接收方法、装置和系统
EP2400683A1 (de) * 2010-06-28 2011-12-28 Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung e.V. Decodierung eines paketbasierten Datenstroms
CN103703797A (zh) * 2013-08-29 2014-04-02 华为技术有限公司 聚合传输的方法、装置和系统以及网络服务器和用户设备
CN105432089A (zh) * 2013-09-10 2016-03-23 华为技术有限公司 一种蜂窝广播融合的预推送方法、设备及系统
CN106464932A (zh) * 2014-03-31 2017-02-22 英国电讯有限公司 多播流传输

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101465791A (zh) * 2007-12-18 2009-06-24 国家广播电影电视总局广播科学研究院 一种基于单向链路的文件传输方法
CN101729997A (zh) * 2008-10-10 2010-06-09 中兴通讯股份有限公司 消息互通方法及融合业务系统
EP2400683A1 (de) * 2010-06-28 2011-12-28 Fraunhofer-Gesellschaft zur Förderung der Angewandten Forschung e.V. Decodierung eines paketbasierten Datenstroms
CN101977182A (zh) * 2010-09-03 2011-02-16 中国电影科学技术研究所 一种数字电影传输方法、系统和设备
CN102143137A (zh) * 2010-09-10 2011-08-03 华为技术有限公司 媒体流发送及接收方法、装置和系统
CN103703797A (zh) * 2013-08-29 2014-04-02 华为技术有限公司 聚合传输的方法、装置和系统以及网络服务器和用户设备
CN105432089A (zh) * 2013-09-10 2016-03-23 华为技术有限公司 一种蜂窝广播融合的预推送方法、设备及系统
CN106464932A (zh) * 2014-03-31 2017-02-22 英国电讯有限公司 多播流传输

Also Published As

Publication number Publication date
CN110099087A (zh) 2019-08-06
WO2019149054A1 (zh) 2019-08-08

Similar Documents

Publication Publication Date Title
CN110099087B (zh) 一种基于融合传输系统的文件传输方法
US11805286B2 (en) Apparatus and method for transmitting/receiving processes of a broadcast signal
US11895357B2 (en) Broadcasting signal transmission device, broadcasting signal reception device, broadcasting signal transmission method, and broadcasting signal reception method
US8351363B2 (en) Method and apparatus for enhanced file distribution in multicast or broadcast
US7937638B2 (en) Error correction apparatus and method
RU2369040C2 (ru) Буферизация при потоковой передаче данных
CN110099086B (zh) 一种基于融合传输系统的数据传输方法
KR20150140783A (ko) 브로드캐스트/멀티캐스트 인에이블드 네트워크들을 통해 오브젝트들의 플로우들을 전달하기 위한 방법들
KR102170717B1 (ko) 멀티미디어 서비스를 위한 비트 에러율을 이용한 레이트 어댑테이션 방법 및 그 장치
KR101868628B1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN110098899B (zh) 一种基于融合传输系统的协议栈、数据重传的方法
CN110099036B (zh) 一种基于融合传输系统的数据封装方法
KR20140051493A (ko) 복합 멀티미디어 데이터를 전송하기 위한 데이터 패킷을 송수신하는 방법 및 장치
CN101189851A (zh) 用于多点播送或广播中的增强型文件分布的方法和设备
KR20200015655A (ko) 데이터 패킷을 송수신하는 방법 및 장치
EP3595254A1 (en) Multicast signal transmission/reception method and device
KR102074226B1 (ko) 데이터 패킷을 수신하는 방법 및 장치
Pekowsky et al. Multimedia data broadcasting strategies
Belda et al. Multimedia system for emergency services over tetra-dvbt networks
KR20190021300A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법
KR20180039604A (ko) 복합 네트워크에서 멀티미디어 데이터를 전송하기 위한 장치 및 그 방법

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant