CN110098899A - 一种基于融合传输系统的协议栈、数据重传的方法 - Google Patents

一种基于融合传输系统的协议栈、数据重传的方法 Download PDF

Info

Publication number
CN110098899A
CN110098899A CN201810094567.8A CN201810094567A CN110098899A CN 110098899 A CN110098899 A CN 110098899A CN 201810094567 A CN201810094567 A CN 201810094567A CN 110098899 A CN110098899 A CN 110098899A
Authority
CN
China
Prior art keywords
fusion
channel
transmission
data
transmission block
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.)
Granted
Application number
CN201810094567.8A
Other languages
English (en)
Other versions
CN110098899B (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 Fusion (beijing) Media Science And Technology Development Co Ltd
Original Assignee
Guoguang Fusion (beijing) Media Science And 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 Fusion (beijing) Media Science And Technology Development Co Ltd filed Critical Guoguang Fusion (beijing) Media Science And Technology Development Co Ltd
Priority to CN201810094567.8A priority Critical patent/CN110098899B/zh
Publication of CN110098899A publication Critical patent/CN110098899A/zh
Application granted granted Critical
Publication of CN110098899B publication Critical patent/CN110098899B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B7/00—Radio transmission systems, i.e. using radiation field
    • H04B7/14—Relay systems
    • H04B7/15—Active relay systems
    • H04B7/185—Space-based or airborne stations; Stations for satellite systems
    • H04B7/18578—Satellite systems for providing broadband data service to individual earth stations
    • H04B7/18582—Arrangements for data linking, i.e. for data framing, for error recovery, for multiple access
    • 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
    • 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/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
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Astronomy & Astrophysics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请提供一种基于融合传输系统的协议栈、数据重传的方法，所述数据重传的方法包括：实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至融合传输流子层；融合传输流子层根据融合传输块请求生成重传请求，且融合传输流子层将重传请求经由物理传输层发送至服务器；融合传输流子层接收服务器经由物理传输层发送的封装有重传数据的重传响应；融合传输流子层根据重传响应生成融合传输块响应、并将融合传输块响应发送至实体单元；实体单元对融合传输块响应进行解析获得重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件，从而避免了冗余数据的产生。

Description

一种基于融合传输系统的协议栈、数据重传的方法
技术领域
本申请涉及通信技术领域，特别涉及一种基于融合传输系统的协议栈、数据重传的方法。
背景技术
数据传输是将数据从一个设备传送到另一个设备的通信过程。以服务器和终端为例，服务器将数据形成数据流，然后传送至终端。该数据流可通过两种方式传输给终端：一种是提交给卫星等广播前端设备，通过卫星广播等广播网络发送给所有终端；另一种是将数据保存于互联网服务器或提交给内容分发网络(CDN)上的缓存服务器，并提供统一资源描述符(Uniform Resource Identifier，URI)，终端可主动通过互联网协议来访问数据流数据。
数据传输的过程中，不可避免地会产生数据的丢失。终端接收文件并对文件解码，若解码失败，则意味着数据丢失，需要终端按照该协议定义的链路返回请求丢失的文件数据。现有的数据传输协议下，服务器并不能准确确定丢失的数据，在数据重传的过程中，存在大量的冗余数据，消耗网络资源。
发明内容
有鉴于此，本申请实施例提供了一种基于融合传输系统的协议栈、数据重传的方法和装置、计算设备以及计算机可读存储介质，以解决现有技术中存在的技术缺陷。
本申请公开了一种基于融合传输系统的协议栈，用于服务器端，包括：
业务应用层，包括用于存储待发送文件的文件单元；
融合传输层，包括业务特定传输协议子层和融合传输流子层；
业务特定传输协议子层包括有至少一个用于对待发送文件进行前置处理生成原始数据的实体单元；
融合传输流子层包括：用于将原始数据封装为融合传输块的融合传输块生成单元；
所述实体单元与所述文件单元之间形成有传输待发送文件的数据通道，所述实体单元与所述融合传输块生成单元之间形成有用于传输原始数据的数据通道；
物理传输层，所述融合传输块生成单元与所述物理传输层之间形成有用于将传输所述融合传输块的数据通道。
本申请公开了一种基于融合传输系统的协议栈，用于终端，包括：
业务应用层，包括用于接收待处理文件的原始数据的文件单元；
融合传输层，包括业务特定传输协议子层和融合传输流子层；
业务特定传输协议子层包括有至少一个用于将融合传输块进行解析生成原始数据的实体单元；
每个实体单元与所述文件单元之间形成有传输待发送文件的原始数据的数据通道，每个所述实体单元与融合传输流子层之间形成有用于传输融合传输块的数据通道；
物理传输层，所述物理传输层与所述融合传输流子层之间形成有用于传输所述融合传输块的数据通道。
本申请公开了一种基于融合传输系统的数据重传的方法，用于如上所述的协议栈，包括：
所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
所述融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
本申请公开了一种基于融合传输系统的数据重传的方法，用于如上所述的协议栈，包括：
所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
本申请公开了一种基于融合传输系统的数据重传的装置，用于如上所述的协议栈，包括：
重传请求接收模块，用于触发所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
重传数据封装模块，用于触发所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
重传响应生成模块，用于触发所述融合传输流子层将所述融合传输块封装形成重传响应；
重传响应发送模块，用于触发所述融合传输流子层将重传响应经由物理传输层发送至终端。
本申请公开了一种基于融合传输系统的数据重传的装置，用于如上所述的协议栈，包括：
融合传输块请求生成模块，用于触发所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
重传请求生成模块，用于触发所述融合传输流子层根据所述融合传输块请求生成重传请求；
重传请求发送模块，用于触发所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
重传响应接收模块，用于触发所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
融合传输块响应生成模块，用于触发所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
融合传输块响应解析模块，用于触发所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对所述待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现以下步骤：
所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
所述融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述指令时实现以下步骤：
所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
本申请公开了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如上所述的用于服务器的数据重传方法的步骤。
本申请公开了一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如上所述的用于终端的数据重传方法的步骤。
本申请提供的基于融合传输系统的协议栈、数据重传的方法和装置，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
另外，本申请的协议栈的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
附图说明
图1是本申请实施例的融合传输系统的结构示意图；
图2是本申请实施例的用于服务器侧的基于融合传输系统的协议栈的结构示意图；
图3是本申请实施例的用于终端侧的基于融合传输系统的协议栈的结构示意图；
图4是本申请实施例的融合传输流的结构示意图；
图5是本申请实施例的融合传输块的结构示意图；
图6是本申请实施例的每个融合传输流在下一代广播电视无线NGB-W/S信道中的映射过程示意图；
图7是本申请实施例的每个融合传输流在数字卫星广播系统DVB-S信道中的映射过程示意图；
图8是本申请实施例的用于服务器的协议栈的数据重传的方法的流程图；
图9是本申请实施例的用于直播业务时的UDP重传请求的结构示意图；
图10是本申请实施例的用于推送业务时的UDP重传请求的结构示意图；
图11是本申请实施例的文件编码符号标识的结构示意图；
图12是本申请实施例的UDP重传响应的结构示意图；
图13是本申请实施例的HTTP重传响应的结构示意图；
图14是本申请实施例的用于终端的协议栈的数据重传的方法的流程图；
图15是本申请实施例的终端在发送UDP重传请求至服务器请求重传的示意图；
图16是本申请实施例的终端在发送HTTP重传请求至服务器请求重传的示意图；
图17是本申请实施例的用于服务器的协议栈的数据重传的装置的结构图；
图18是本申请实施例的用于终端的协议栈的数据重传的装置的结构图。
具体实施方式
在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。
首先对本申请下文中会涉及的名词术语进行解释。
业务(service)——在广播者的控制下，可以按照时间表分步广播的一系列节目或数据。
卫星移动多媒体(mobile satellite multimedia)——通过卫星通信网络向移动终端提供的多媒体服务，如音视频、点播和数据推送业务。
卫星广播网(satellite broadcast network)——基于地球同步轨道卫星来提供音视频广播和其他信息服务的网络。
移动通信网(mobile communication network)——基于地面基站来提供移动通信和双向数据传输的网络，包括2G/双向/xG。
网络融合传输(network converged transmission)——同一个业务采用卫星广播网和移动通信网两种网络途径来进行传输以提高业务覆盖范围和业务可靠性的传输方式。
传输流(MPEG2-TS，又称TS)——用于音效、图像与数据的通信协定，用来封装音视频媒体数据的复合信息流。
分片文件(slice file)——将一个音视频节目的传输流按时间进行切成的可独立播放的媒体文件。
文件流(file stream)——由同一个业务源按照时间顺序产生的一系列文件。
融合传输块(converged transport block)——一种用来承载上层业务数据的定长包结构。
融合传输流(converged transport stream)——由连续的融合传输块组成的可传输多个业务的复合信息流。
物理信道(physical pipe)——占有一定信道资源并且可独立进行编码和调制的物理层信道。
文件段(file segment)——将文件进行分割产生的片段。
统一资源描述符(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的双向链路来重传丢失或出错的业务数据，以保证业务数据接收的可靠性。
本申请公开的协议栈分别用于服务器和终端，参见图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所示。
其中，块头(40位比特)又进一步包括以下字段：
块序号——32位比特，用来对同一个融合传输流中的融合传输块进行循环编号，块序号从0开始，当达到最大值232－1后，又从0开始编号。
业务类型——3位比特，用来指示融合传输块中封装的业务数据的类型，如表1所示。当业务类型为空业务时，融合传输块中的数据采用随机数据进行填充。
校验指示——1位比特，值为1时表示融合传输块末尾有校验字段CRC32，值为0则无此校验字段。
校验字段(CRC32)——32位比特，为校验字段，当校验指示为1时存在，该字段对文件传输块的块头和块净荷所有字节进行校验。
表1
值 描述
1 文件流传输业务
2 大文件推送业务
3 控制消息业务
7 空业务
其他 待定
具体地，用于服务器端的协议栈如图2所示，包括：
业务应用层，包括用于存储待发送文件的文件单元。
为了直播或推送一个文件，需要将该文件添加到一个业务中。每个业务对应有至少一个文件，对应地，每个文件单元存储添加至一个业务中的文件。
在融合传输系统中，每个业务对应着一个融合传输流，因此，在将文件添加到业务的过程中，也相当于为该文件指定了融合传输流。
融合传输层，包括业务特定传输协议子层和融合传输流子层。
业务特定传输协议子层包括有至少一个用于对待发送文件进行前置处理生成原始数据的实体单元。实体单元与文件单元之间形成有传输待发送文件的数据通道，实体单元通过该数据通道接收待发送文件，然后对待发送文件进行前置处理。需要注意的是，每个实体单元对应至少一个文件单元。
业务特定传输协议子层可以支持多种协议，本实施例以直播流传输协议和大文件推送协议为例进行说明，来支持直播业务和推送业务。对应地，实体单元可以分为直播流传输实体单元和大文件推送实体单元。
在直播业务时，实体单元将待发送文件进行前置处理生成原始数据，包括：
为每个所述待发送文件添加一个文件描述头；
将添加有文件描述头的所述待发送文件分割为至少一个文件段；其中，所述至少一个文件段形成所述原始数据。
需要解释的是，在直播业务中，将直播文件添加文件描述头，然后将添加有文件描述头的文件切分为至少一个文件段。切分后，文件描述头存在于第一个文件段中，并被封装于融合传输流的第一个融合传输块中，直播文件的数据依次添加到其他融合传输块中。在终端接收到融合传输流的融合传输块后进行解析，得到文件描述头以及直播文件。
在推送业务时，实体单元将待发送文件进行前置处理生成原始数据，包括：
将待发送文件进行编码生成文件编码符号；
根据待发送文件生成对应的文件描述信息；
将所述文件描述信息添加对应的业务描述信息头，以生成业务描述信息；其中，所述业务描述信息和文件编码符号形成所述原始数据。
在此需要解释的是，与直播业务不同，在推送业务时，封装有文件编码符号和业务描述信息分别封装于不同的融合传输块中，封装有文件编码符号的融合传输块和业务描述信息的融合传输块并非同时被推送至终端的实体单元。
在一个具体的实施方案中，实体单元对文件进行前向纠错编码(FEC)，所采用的FEC编码算法为Raptor喷泉编码，具体算法参考IETF标准RFC5053。在此编码过程中，文件需要先生成文件源符号，然后再根据文件源符号生成文件编码符号。需要注意的是，在正常传输过程中，服务器只需要向终端传输文件的文件编码符号；在重传过程中，终端则需要向服务器请求文件的文件源符号。
融合传输流子层包括用于将原始数据封装为融合传输块的融合传输块生成单元，另外还包括发送单元和重传响应单元。
实体单元与融合传输块生成单元之间形成有用于传输原始数据的数据通道。融合传输块生成单元通过与实体单元之间的数据通道接收原始数据，然后将每个业务对应的原始数据封装为一个融合传输流。
需要注意的是，实体单元与融合传输块生成单元为一一对应的关系，一个融合传输流可以包括至少一个业务。
发送单元和重传响应单元的作用不同，发送单元是用于正常发送时服务器给终端发送融合传输块，重传响应单元是用于服务器重传数据至终端。融合传输块生成单元与所述发送单元形成有用于传输所述融合传输块的数据通道，融合传输块生成单元与所述重传响应单元之间形成有用于传输所述融合传输块的数据通道。
对于物理传输层，所述融合传输块生成单元与所述物理传输层之间形成有用于将传输所述融合传输块的数据通道。
物理传输层包括：卫星广播信道和互联网信道。
更为详尽地，发送单元与所述卫星广播信道之间形成有用于传输所述融合传输块的数据通道，重传响应单元与所述互联网信道之间形成有用于传输所述融合传输块的数据通道。
下面对卫星广播信道进行详细的说明。卫星广播信道包括：NGB-W/S信道或DVB-S信道；
所述发送单元将融合传输块封装为适用于NGB-W/S信道或DVB-S信道的广播数据，并经由数据通道发送至NGB-W/S信道或DVB-S信道。
在NGB-W/S信道中，一个或若干个融合传输流可以复合在一个物理管道上传送，每个融合传输流均占用该物理管道上连续调度周期上的固定时段，其映射过程如图6所示。
该融合传输流的每一个融合传输块CTB，均一一映射为一个链路数据包，进一步被链路层封装为一个业务负载包，并交给物理层进行编码调制。
在DVB-S信道中，广播链路采用MPEG2-TS传输流作为业务的输入形式，并未将物理信道划分为若干个独立的物理管道。因此，一个融合传输流可以直接映射到整个物理信道或者自定义的逻辑信道上。
融合传输流中的每个融合传输块将映射到整数个TS包中，其映射过程及TS包结构如图7所示。由图7中可见，每个TS包包括包头和净荷，包头包括：同步字节(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所示，包括：业务应用层、融合传输层和物理传输层。
业务应用层包括用于接收待处理文件的原始数据的文件单元。
融合传输层包括业务特定传输协议子层和融合传输流子层。
业务特定传输协议子层包括有至少一个用于将融合传输块进行解析生成原始数据的实体单元；每个实体单元与文件单元之间形成有传输待发送文件的原始数据的数据通道，每个实体单元与融合传输流子层之间形成有用于传输融合传输块的数据通道。
业务特定传输协议子层可以支持多种协议，本实施例以直播流传输协议和大文件推送协议为例进行说明，来支持直播业务和推送业务。对应地，实体单元可以分为直播流传输实体单元和大文件推送实体单元。
在直播业务时，实体单元将融合传输块进行解析生成原始数据，包括：
将融合传输块解封装，得到至少一个文件段；其中，所述原始数据为将添加有文件描述头的所述待发送文件分割为至少一个文件段而形成。
需要解释的是，在直播业务中，将直播文件添加文件描述头，然后将添加有文件描述头的文件切分为至少一个文件段。切分后，文件描述头存在于第一个文件段中，并被封装于融合传输流的第一个融合传输块中，直播文件的数据依次添加到其他融合传输块中。在终端接收到融合传输流的融合传输块后进行解析，得到文件描述头以及直播文件。
在推送业务时，实体单元将融合传输块进行解析生成原始数据，包括：
将融合传输块解封装，得到文件编码符号和业务描述信息。其中，所述原始数据包括业务描述信息和文件编码符号，所述业务描述信息为将所述待发送文件的文件描述信息添加对应的业务描述信息头而生成。
在此需要解释的是，与直播业务不同，在推送业务时，封装有文件编码符号和业务描述信息分别封装于不同的融合传输块中，封装有文件编码符号的融合传输块和业务描述信息的融合传输块并非同时被推送至终端的实体单元。实体单元会先对封装有业务描述信息的融合传输块进行解封装，以得到业务描述信息，并以此为依据建立所需文件的文件表，然后再去接收封装有文件编码符号的融合传输块并解析。
另外，融合传输流子层包括接收单元和重传请求单元。接收单元与实体单元之间形成有用于传输所述融合传输块的数据通道，重传请求单元与实体单元之间形成有用于传输所述融合传输块的数据通道。
接收单元和重传请求单元的作用并不相同，接收单元用于接收卫星广播信道的数据，重传请求单元用于经由互联网信道发送重传请求和接收服务器的重传数据。
物理传输层与所述融合传输流子层之间形成有用于传输所述融合传输块的数据通道。具体地，物理传输层包括：卫星广播信道和互联网信道。
卫星广播信道与接收单元之间形成有用于传输融合传输块的数据通道。具体地，卫星广播信道包括：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重传响应。
可见，在终端解码失败需要重传的过程中，由终端发起重传过程，且终端也主动决策了重传信道的选择；对于服务器，则被动地选择与终端的重传信道相同的互联网信道。
本申请的协议栈，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
本申请的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
上述为对本申请公开的协议栈的架构进行了详细的说明。该协议栈为融合传输系统的运行提供了支撑。下面对基于该协议栈的数据重传的方法进行详细的介绍。与协议栈的描述相同，本实施例的数据重传的方法也分别对终端侧和服务器侧进行描述。
在融合传输系统中，一个融合传输流的融合传输块在产生之后，将存储于系统前端的服务器上或者通过内容分发网络分发给网络中的多个缓存服务器。为叙述方便，上述所有存储融合传输流的服务器统称为融合传输系统的服务器端。
当终端通过广播链路接收到融合传输流时，可通过各种差错校验方法来确认融合传输块的丢失或出错，终端可以根据业务的需求向服务器端发起请求，重传丢失或出错的融合传输块。
在本申请中，提供了一种基于融合传输系统的数据重传的方法和装置、计算设备和计算机可读存储介质，在下面的实施例中逐一进行详细说明。
图8是示出了根据本申请一实施例的用于服务器的协议栈的数据重传的方法的流程图，包括步骤801至步骤803：
801、融合传输流子层经由物理传输层接收终端发送的重传请求。其中，所述重传请求中包括重传数据的信息。
需要说明的是，物理传输层包括：卫星广播信道和互联网信道。如前协议栈的技术方案所述，卫星广播信道用于服务器和终端正常状态下的数据传输，互联网通道用于终端向服务器请求重传数据。由于本实施例仅关注如何实现数据的重传，故关于卫星广播信道的具体细节便不再赘述。
具体地，融合传输流子层经由互联网信道接收重传请求和发送重传响应。
互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道。
对应地，重传请求包括：UDP重传请求和HTTP重传请求。所述融合传输流子层经由UDP信道接收UDP重传请求，所述融合传输流子层经由HTTP信道接收HTTP重传请求。
需要注意的是，对于互联网信道中，UDP信道和HTTP信道是并存的，但是UDP信道和HTTP信道只能择一使用。具体地，当所述重传数据的数据量小于阈值时，所述融合传输流子层通过UDP信道接收所述UDP重传请求和发送所述UDP重传响应；当所述重传数据的数据量大于阈值时，所述融合传输流子层通过HTTP信道接收所述HTTP重传请求和发送所述HTTP重传响应。
具体地，UDP重传请求(UDP_CTB_REQ)的参数包括：必选参数和可选参数；
所述必选参数包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识和重传请求编号；
所述可选参数包括：业务流内编号、业务内文件标识、请求的源符号总数、请求的源符号组数、每组源符号列表、请求的融合传输块总数、请求的融合传输块组数和每组融合传输块序号；
每组所述源符号列表包括：源块号、源符号起始标识和源符号个数；
所述每组融合传输块序号包括：融合传输块起始序号和融合传输块个数。
具体地，用于直播业务时，参见图9，UDP重传请求包括：
融合传输流协议版本(8bit)、消息报文类型(8bit)、消息报文长度(16bit)、融合传输流标识(12bit)、重传请求编号(8bit)、请求的融合传输块总数(6bit)、请求的融合传输块组数(6bit)、每组融合传输块序号(40bit)以及校验码(32bit)。
每组融合传输块序号包括：融合传输块起始序号(32bit)和融合传输块个数(8bit)。
各字段含义如下：
融合传输流协议版本——8位比特，指示融合传输流协议版本，当前值为0x01。
消息报文类型——8位比特，指示UDP消息报文的类型，当消息为UDP_CTB_REQ时该值为0x01。
消息报文长度——16位比特，指示整个消息报文的字节数，从协议版本开始到第M组CTB，包括CRC32。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
请求重传的融合传输块总数——6位比特，指示本次重传请求中的融合传输块的总数。
请求重传的融合传输块组数——6位比特，指示本次请求重传的融合传输块组的数目M，该值决定了后续的组融合传输块参数的个数。
第一组融合传输块序号——40位比特，指示需要重传的第一组融合传输块序号，由32位的融合传输块起始序号和8位的融合传输块个数组成。
第二组融合传输块序号、……第M组融合传输块序号——均为40位比特，其存在由请求重传的融合传输块组数来决定，均由32位的融合传输块起始序号和8位的融合传输块个数组成。
校验码(CRC32)——32位比特，对消息报文进行校验，包括从协议版本到第M组融合传输块参数。
用于推送业务时，参见图10，UDP重传请求包括：
融合传输流协议版本(8bit)、消息报文类型(8bit)、消息报文长度(16bit)、融合传输流标识(12bit)、重传请求编号(8bit)、业务流内编号(12bit)、业务内文件标识(16bit)、请求的源符号总数(8bit)、请求的源符号组数(8bit)、每组源符号列表(40bit)以及校验码(32bit)
每组源符号列表包括：源块号(16bit)、源符号起始标识(16bit)和源符号个数(8bit)。
各字段含义如下：
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参数。
对于HTTP重传请求HTTP_GET_REQ，终端将响应的请求参数放在统一资源定位符URL中发送至服务器。举例如下：
GET“http://www.CTB-server.com/getCTB3？CTS_ID＝601&REQ_SEQ＝21&
ISS_ID＝2&FILE_LID＝301&ES_REQ_LIST＝20:1:3；21:4:5；22:1:10”
其中，getCTB3为HTTP服务端的方法入口，符号？后为携带的请求参数，符号&用来作为多个请求参数的分隔符。
HTTP重传请求(HTTP_GET_REQ)包括：URL前缀、端口号、具体目录和请求参数；
在直播业务中请求重传文件源符号时，HTTP重传请求的请求参数包括：融合传输流标识、重传请求编号、请求的融合传输块列表。
在推送业务中请求重传文件源符号时，HTTP重传请求的请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表。
在此需要注意的是，在推送时，HTTP重传请求不仅可以请求文件源符号，还可以请求重传业务描述信息。在请求重传业务描述信息时，HTTP重传请求的请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
802、融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块。
根据业务类型的不同，重传数据包括：待发送文件的文件段或文件源符号。
在直播业务中，待发送文件被分割为至少一个文件段。对应地，在请求重传时，融合传输流子层根据重传请求向实体单元询问并获得请求重传的文件段，并根据该文件段生成融合传输块。
在一个具体的实施方案中，在推送业务时，实体单元对文件进行前向纠错编码(FEC)，所采用的FEC编码算法为Raptor喷泉编码，具体算法参考IETF标准RFC5053。在此编码过程中，文件需要先生成文件源符号，然后再根据文件源符号生成文件编码符号，然后将文件编码符号封装为融合传输块。
一个文件经过Raptor喷泉编码后，可以生成任意多个编码符号(EncodingSymbol，ES)，其中，每个编码符号的长度是固定的。根据其生成过程，每个编码符号都有一个唯一的32位标识，称为文件编码符号标识(File Encoding Symbol ID，FESI)，根据RFC5053标准，每个FESI由16位的源块号(SBN)和16位的编码符号标识(ESI)组成，如图11所示。对应地，每个文件源符号也有一个唯一的文件源符号起始标识，其格式与文件编码符号标识相同。
需要注意的是，在正常传输过程中，服务器只需要向终端传输文件的文件编码符号；在重传过程中，终端则需要向服务器请求文件的文件源符号。
803、融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
对应地，重传响应包括：UDP重传响应和HTTP重传响应。所述融合传输流子层将封装有重传数据的UDP重传响应经由UDP信道发出，所述融合传输流子层将封装有重传数据的HTTP重传响应经由HTTP信道发出。
具体地，参见图12，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个校验码。
具体地，参见图13，所述HTTP重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量和至少一个请求的融合传输块。
各字段含义如下：
响应主体类型——需设置为“application/octet-stream”；
响应主体长度——需设置为实体主体的长度；
响应主体摘要——需设置为实体主体的MD5摘要，用来检测其完整性；
融合传输流协议版本——8位比特，指示融合传输流协议的版本，当前值为0x01。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
单个融合传输块长度指示——4位比特，指示每个融合传输块的长度，当该指示为0时，表示融合传输块长度为缺省值2118字节。
请求重传的融合传输块总数——16位比特，指示本次重传反馈中的融合传输块的总数N，决定了后续融合传输块的个数。
第一个融合传输块、第二个融合传输块、……第N个融合传输块——指示本次重传反馈中的所有融合传输块数据。
本实施例的基于融合传输系统的数据重传的方法，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
上述实施例为本申请实施例的用于服务器的数据重传的技术方案的描述。由上述实施例可见，服务器在数据重传的过程中，并不主动发起重传过程，只是在接收到重传请求后，做出重传响应。
本申请实施例还公开了一种基于融合传输系统的数据重传的方法，用于终端的协议栈，如图14所示，包括：
1401、所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层。其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成。
对于直播业务，原始数据包括至少一个文件段，该至少一个文件段中包括待处理文件的文件描述头；对于推送业务，原始数据包括待发送文件的文件编码符号文件描述信息。
对应地，对于直播业务，重传数据包括待发送文件的文件段；对于推送业务，重传数据包括文件源符号。
一个文件经过Raptor喷泉编码后，可以生成任意多个编码符号(EncodingSymbol，ES)，其中，每个编码符号的长度是固定的。根据其生成过程，每个编码符号都有一个唯一的32位标识，称为文件编码符号标识(File Encoding Symbol ID，FESI)，根据RFC5053标准，每个FESI由16位的源块号(SBN)和16位的编码符号标识(ESI)组成，如图11所示。对应地，每个文件源符号也有一个唯一的文件源符号起始标识，其格式与文件编码符号标识相同。在重传过程中，终端则需要向服务器请求文件的文件源符号。
在业务特定传输协议子层，可能同时运行多个实体单元，这些实体单元可能采用同一种业务特定传输协议，也可能采用不同的业务特定传输协议。每个实体单元都对应着一个特定的融合传输流，因此，可通过融合传输流携带的融合传输流标识(CTS_ID)来区分不同的实体单元。
每个实体单元均可向融合传输流子层发出融合传输块请求，融合传输流子层完成重传功能后，将重传的结果通过融合传输块响应反馈给实体单元。同一个实体也可以并行发出多个融合传输块请求，这些融合传输块请求均携带相应的请求编号。
参见图15和图16，图15为终端在发送UDP重传请求至服务器请求重传的示意图，图16为终端在发送HTTP重传请求至服务器请求重传的示意图。
具体地，融合传输块请求CTS_CTB_REQ包括：必选参数和可选参数；
所述必选参数包括：融合传输流标识和重传请求编号；
所述可选参数包括：业务描述信息类型、流内业务编号、文件列表、业务内文件标识、请求的源符号总数、请求的源符号列表、请求的融合传输块总数、请求的融合传输块列表。
各字段含义如下：
融合传输流标识(CTS_ID)——整数类型，取值范围0～4095，需要补发的融合传输流标识。
重传请求编号(REQ_SEQ)——整数类型，取值范围0～255，BFP实体按时间顺序对发出的融合传输块请求进行的循环编号。
业务描述信息类型(GET_TYPE)——整数类型，取值范围0～2，指示终端请求的业务描述信息类型，当GET_TYPE为0时请求的是融合传输流中最新序号的业务描述信息；当GET_TYPE为1时请求的是指定业务的业务描述信息；当GET_TYPE为2时请求的是指定文件的业务描述信息。
文件列表(FILE_LIST)——字符串类型，当GET_TYPE为2时有效，指示业务描述信息应包含哪些指定文件的描述信息，由若干个二元组组成，每个二元组代表一个文件，其编码如下：
<ISS_ID:FILE_LID>
其中，ISS_ID指示该文件的流内业务编号，和前述的CTS_ID构成业务标识；FILE_LID指示该业务内文件标识。
多个二元组之间用分号隔开，整体格式如下：
ISS_ID1:FILE_LID1；ISS_ID2:FILE_LID2；ISS_ID3:FILE_LID3；……
举例来说：当FILE_LIST为字符串11:3；11:4；12:10时，表示终端请求的业务描述信息应该包括下面三个文件的描述信息：文件1(流内业务编号为11，业务内文件标识为3)、文件2(流内业务编号为11，业务内文件标识为4)和文件3(流内业务编号为12，业务内文件标识为10)。
流内业务编号(ISS_ID)——整数类型，取值范围0～255，指定流内业务编号，和融合传输流标识构成业务标识。
业务内文件标识(FILE_LID)——整数类型，取值范围0～(220-1)，指定业务内文件标识，和融合传输流标识和流内业务编号一起构成全局文件标识。
请求的源符号总数(ES_REQ_COUNT)——整数类型，取值范围1～1000，请求补发的源符号总数。
请求的源符号列表(ES_REQ_LIST)——字符串类型，指示需要补发的一个或多个源符号，由若干个三元组组成，每个三元组代表一组标识连续的源符号，其编码如下：
<ES_SBN:ESI_BEGIN:ES_NUM>
其中，ES_SBN指示该组文件源符号所属的源块号，
ESI_BEGIN指示该组源符号的起始ESI标识，
ES_NUM指示从ESI_BEGIN开始需要重传的源符号个数。
多个三元组之间用分号隔开，整体格式如下：
ES_SBN1:ESI_BEGIN1:ES_NUM1；ES_SBN2:ESI_BEGIN2:ES_NUM2；ES_SBN3:ESI_BEGIN3:ES_NUM3；……
举例来说：当ES_REQ_LIST为字符串20:1:3；21:4:5；22:1:10时，表示需要补发三个编码符号组，分别是：源块号为20的3个源符号(ESI为1，2，3)、源块号为21的5个源符号(ESI为4～8)和源块号为22的10个源符号(ESI为1～10)。
请求的融合传输块总数(CTB_REQ_COUNT)——整数类型，取值范围1～1000，请求重传的融合传输块总数。
请求的融合传输块列表(CTB_REQ_LIST)——字符串类型，指示需要重传的融合传输块的序号，由若干个二元组<CTB_BEGIN:CTB_NUM>组成，每个二元组代表编号连续的一组融合传输块，其中，CTB_BEGIN指示起始序号，CTB_NUM指示该融合传输块组中的融合传输块个数，多个二元组之间用分号隔开，整体格式如下：
CTB_BEGIN1:CTB_NUM1；CTB_BEGIN2:CTB_NUM2；CTB_BEGIN3:CTB_NUM3；……
举例来说，当CTB_REQ_LIST为字符串1001:1；1050:4；1066:2时，表示需要重传的融合传输块包括序号为1001、1050、1051、1052、1053、1066和1067的7个融合传输块。
具体地，在请求不同类型的数据时，融合传输块请求所携带的参数也不同。
在直播业务中，融合传输块请求CTS_CTB_REQ包括的参数为：融合传输流标识、重传请求编号、请求的融合传输块总数和请求的融合传输块列表；
具体地，在推送业务请求文件源符号时，融合传输块请求CTS_CTB_REQ包括的参数为：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号总数和请求的源符号列表；
具体地，在推送业务请求文件描述信息时，融合传输块请求CTS_CTB_REQ包括的参数为：融合传输流标识、重传请求编号、业务描述信息类型、流内业务编号和文件列表。
1402、所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器。
其中，物理传输层包括：卫星广播信道和互联网信道；
所述融合传输流子层经由所述互联网信道发送重传请求和接收重传响应。
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道。如前协议栈的技术方案所述，卫星广播信道用于服务器和终端正常状态下的数据传输，互联网通道用于终端向服务器请求重传数据。由于本实施例仅关注如何实现数据的重传，故关于卫星广播信道的具体细节便不再赘述。
本申请的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
重传请求包括：UDP重传请求和HTTP重传请求。融合传输流子层发送UDP重传请求至UDP信道，融合传输流子层发送HTTP重传请求至HTTP信道。
需要注意的是，对于互联网信道中，UDP信道和HTTP信道是并存的，但是UDP信道和HTTP信道只能择一使用。终端的融合传输流子层主动对信道进行选择，当重传数据的数据量小于阈值时，融合传输流子层通过UDP信道发送所述UDP重传请求和接收所述UDP重传响应；当重传数据的数据量大于阈值时，融合传输流子层通过HTTP信道发送所述HTTP重传请求和接收所述HTTP重传响应。
具体地，终端的融合传输流子层判断重传数据的数据量是否小于一个UDP重传响应的报文阈值，若是，则采用UDP信道发送UDP重传请求和接收UDP重传响应；若否，则采用HTTP信道发送HTTP重传请求和接收HTTP重传响应。
所述UDP重传请求(UDP_CTB_REQ)包括：必选参数和可选参数；
所述必选参数包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识和重传请求编号；
所述可选参数包括：业务流内编号、业务内文件标识、请求的源符号总数、请求的源符号组数、每组源符号列表、请求的融合传输块总数、请求的融合传输块组数和每组融合传输块序号；
每组所述源符号列表包括：源块号、源符号起始标识和源符号个数；
所述每组融合传输块序号包括：融合传输块起始序号和融合传输块个数；
所述HTTP重传请求(HTTP_GET_REQ)包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：：融合传输流标识、重传请求编号和请求的融合传输块列表；或
融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表；或
融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
关于UDP重传请求和HTTP重传请求的具体报文格式，在前述实施例中已经做了详细的介绍，在此便不再赘述。
由步骤1402可见，对于终端侧，融合传输块请求并不能直接经由物理传输层发送至服务器，需要融合传输流子层将融合传输块请求生成重传请求，然后才能发送至服务器。
1403、所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应。
所述重传响应包括：UDP重传响应和HTTP重传响应。具体地，融合传输流子层接收UDP信道发送的封装有重传数据的UDP重传响应，融合传输流子层接收HTTP信道发送的封装有重传数据的HTTP重传响应。
UDP重传响应(UDP_CTB_RESP)包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量、至少一个请求的融合传输块以及校验码；
所述HTTP重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量和至少一个请求的融合传输块。
关于UDP重传响应和HTTP重传响应的具体报文格式，在前述实施例中已经做了详细的介绍，在此便不再赘述。
1404、所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元。
具体地，融合传输块响应(CTS_CTB_RESP)包括：融合传输流标识、重传请求编号、重传结果、重传错误类型、重传成功的融合传输块的数目以及重传成功的融合传输块的数据。
各个字段说明如下：
融合传输流标识(CTS_ID)——整数类型，取值范围0～4095，发起重传的融合传输流标识。
重传请求编号(REQ_SEQ)——整数类型，取值范围0～255，表明该消息所针对的请求编号。
重传结果(REQ_RESULT)——整数类型，取值范围0～2，0表示重传成功，1表示重传接收到部分数据，2表示失败。
重传错误类型(ERROR_TYPE)——整数类型，取值范围0～100，指示重传错误类型。
重传成功的融合传输块的数目(CTB_RESP_COUNT)——整数类型，取值范围0～1000，指示成功接收的融合传输块数目，0表示未收到任何融合传输块。
重传成功的融合传输块的数据(CTB_RESP_DATA)——字节流类型，指示重传成功的融合传输块数目，由融合传输块级联而成。
根据重传请求的不同，融合传输块中封装的数据也不同，包括：文件段、文件源符号或业务描述信息。
由步骤1404可见，对于终端侧，经由物理传输层接收的重传响应并不能直接发送至实体单元，需要将重传响应转换为融合传输块响应，再将融合传输块响应发送至实体单元。
1405、所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对所述待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
上述实施例为本申请实施例的用于终端的数据重传的技术方案的描述。由上述实施例可见，终端在数据重传的过程中，会主动发起重传请求，并接收重传响应。
本实施例的基于融合传输系统的数据重传的方法，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
在本申请的一个实施例中，本申请公开了一种基于融合传输系统的数据重传的装置，用于服务器侧的协议栈，参见图17，包括：
重传请求接收模块1701，用于触发所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
重传数据封装模块1702，用于触发所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
重传响应生成模块1703，用于触发所述融合传输流子层将所述融合传输块封装形成重传响应；
重传响应发送模块1704，用于触发所述融合传输流子层将重传响应经由物理传输层发送至终端。
可选地，物理传输层包括：卫星广播信道和互联网信道；
所述重传请求接收模块1701触发所述融合传输流子层经由所述互联网信道接收重传请求；所述重传响应发送模块1704触发所述融合传输流子层经由所述互联网信道发送重传响应。
具体地，互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传请求包括：UDP重传请求和HTTP重传请求；
所述重传响应包括：UDP重传响应和HTTP重传响应；
所述重传请求接收模块1701触发所述融合传输流子层经由UDP信道接收UDP重传请求，所述重传响应发送模块1704触发所述融合传输流子层将封装有重传数据的UDP重传响应经由UDP信道发出；
所述重传请求接收模块1701触发所述融合传输流子层经由HTTP信道接收HTTP重传请求，所述重传响应发送模块1704触发所述融合传输流子层将封装有重传数据的HTTP重传响应经由HTTP信道发出。
进一步地，当所述重传数据的数据量小于阈值时，所述重传请求接收模块1701触发所述融合传输流子层通过UDP信道接收所述UDP重传请求、所述重传响应发送模块1704触发所述融合传输流子层通过UDP信道发送所述UDP重传响应；
当所述重传数据的数据量大于阈值时，所述重传请求接收模块1701触发所述融合传输流子层通过HTTP信道接收所述HTTP重传请求、所述重传响应发送模块1704触发所述融合传输流子层通过HTTP信道发送所述HTTP重传响应。
对应业务的不同，重传数据包括：待发送文件的文件段或源符号。
可选地，UDP重传请求(UDP_CTB_REQ)包括：必选参数和可选参数；
所述必选参数包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识和重传请求编号；
所述可选参数包括：业务流内编号、业务内文件标识、请求的源符号总数、请求的源符号组数、每组源符号列表、请求的融合传输块总数、请求的融合传输块组数和每组融合传输块序号；
每组所述源符号列表包括：源块号、源符号起始标识和源符号个数；所述每组融合传输块序号包括：融合传输块起始序号和融合传输块个数。
可选地，HTTP重传请求(HTTP_GET_REQ)包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号和请求的融合传输块列表；或
融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表；或
融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
可选地，UDP重传响应(UDP_CTB_RESP)包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量、至少一个请求的融合传输块以及校验码；
可选地，HTTP重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量和至少一个请求的融合传输块。
本申请提供的基于融合传输系统的数据重传的装置，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
另外，本申请的协议栈的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
在本申请的一个实施例中，本申请公开了一种基于融合传输系统的数据重传的装置，用于终端侧的协议栈，参见图18，包括：
融合传输块请求生成模块1801，用于触发所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
重传请求生成模块1802，用于触发所述融合传输流子层根据所述融合传输块请求生成重传请求；
重传请求发送模块1803，用于触发所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
重传响应接收模块1804，用于触发所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
融合传输块响应生成模块1805，用于触发所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
融合传输块响应解析模块1806，用于触发所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对所述待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
可选地，物理传输层包括：卫星广播信道和互联网信道；
所述重传请求发送模块1803触发所述融合传输流子层经由所述互联网信道发送重传请求，所述重传响应接收模块1804触发所述融合传输流子层经由所述互联网信道接收重传响应。
可选地，互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传请求包括：UDP重传请求和HTTP重传请求；
所述重传响应包括：UDP重传响应和HTTP重传响应；
所述重传请求发送模块1803触发所述融合传输流子层发送UDP重传请求至UDP信道，所述重传响应接收模块1804触发所述融合传输流子层接收UDP信道发送的封装有重传数据的UDP重传响应；
所述重传请求发送模块1803触发所述融合传输流子层发送HTTP重传请求至HTTP信道，所述重传响应接收模块1804触发所述融合传输流子层接收HTTP信道发送的封装有重传数据的HTTP重传响应。
当所述重传数据的数据量小于阈值时，所述重传请求发送模块1803触发所述融合传输流子层通过UDP信道发送所述UDP重传请求，所述重传响应接收模块1804触发所述融合传输流子层通过UDP信道接收所述UDP重传响应；
当所述重传数据的数据量大于阈值时，所述重传请求发送模块1803触发所述融合传输流子层通过HTTP信道发送所述HTTP重传请求，所述重传响应接收模块1804触发所述融合传输流子层通过HTTP信道接收所述HTTP重传响应。
对应着不同的业务，重传数据包括：待发送文件的文件段或源符号。
参见图15和图16，图15为终端在发送UDP重传请求至服务器请求重传的示意图，图16为终端在发送HTTP重传请求至服务器请求重传的示意图。
可选地，融合传输块请求(CTS_CTB_REQ)包括：必选参数和可选参数；
所述必选参数包括：融合传输流标识和重传请求编号；
所述可选参数包括：业务描述信息类型、流内业务编号、文件列表、业务内文件标识、请求的源符号总数、请求的源符号列表、请求的融合传输块总数、请求的融合传输块列表；
可选地，融合传输块响应(CTS_CTB_RESP)包括：融合传输流标识、重传请求编号、重传结果、重传错误类型、重传成功的融合传输块的数目以及重传成功的融合传输块的数据。
可选地，UDP重传请求(UDP_CTB_REQ)包括：必选参数和可选参数；
所述必选参数包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识和重传请求编号；
所述可选参数包括：业务流内编号、业务内文件标识、请求的源符号总数、请求的源符号组数、每组源符号列表、请求的融合传输块总数、请求的融合传输块组数和每组融合传输块序号；
每组所述源符号列表包括：源块号、源符号起始标识和源符号个数，所述每组融合传输块序号包括：融合传输块起始序号和融合传输块个数；
可选地，HTTP重传请求(HTTP_GET_REQ)包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号和请求的融合传输块列表；或
融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表；或
融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
可选地，UDP重传响应(UDP_CTB_RESP)包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量、至少一个请求的融合传输块以及校验码；
可选地，HTTP重传响应(HTTP_GET_RESP)包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量和至少一个请求的融合传输块。
本申请提供的基于融合传输系统的数据重传的装置，在终端解码文件的原始数据失败后，经由物理传输层发送重传请求至服务器，服务器将重传数据封装于重传响应并经由物理传输层传输至终端，从而避免了冗余数据的产生。
另外，本申请的协议栈的物理传输层采用卫星广播信道和互联网信道的双链路，在推送数据时，使用卫星广播信道来传输数据；在重传数据时，使用互联网信道来重传丢失或出错的数据，从而保证数据接收的可靠性。
上述为本实施例的基于融合传输系统的数据重传的装置的示意性方案。需要说明的是，该基于融合传输系统的数据重传的装置的技术方案与上述的基于融合传输系统的数据重传的方法的技术方案属于同一构思，基于融合传输系统的数据重传的装置的技术方案未详细描述的细节内容，均可以参见上述基于融合传输系统的数据重传的方法的技术方案的描述。
本申请一实施例公开了一种计算设备1900，该计算设备1900能够访问页面，该计算设备1900的部件包括但不限于存储器1910和处理器1920。处理器1920与存储器1910相连接。
应该知道，计算设备1900还可以包括网络接口，网络接口使得计算设备1900能够经由一个或多个网络通信。这些网络的示例包括局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。网络接口可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。计算设备可以通过网络接口访问页面。
计算设备1900可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备1900还可以是移动式或静止式的服务器。
其中，处理器1920可以执行以下步骤：
所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
所述融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
本申请一实施例公开了一种计算设备，包括存储器2010、处理器2020及存储在存储器2010上并可在处理器2020上运行的计算机指令，所述处理器2020执行所述指令时实现以下步骤：
所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述的用于服务器的数据重传方法的步骤。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现如前所述的用于终端的数据重传方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的数据重传的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于融合传输系统的数据重传的方法的技术方案的描述。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (32)

1.一种基于融合传输系统的协议栈，其特征在于，用于服务器端，包括：
业务应用层，包括用于存储待发送文件的文件单元；
融合传输层，包括业务特定传输协议子层和融合传输流子层；
业务特定传输协议子层包括有至少一个用于对待发送文件进行前置处理生成原始数据的实体单元；
融合传输流子层包括：用于将原始数据封装为融合传输块的融合传输块生成单元；
所述实体单元与所述文件单元之间形成有传输待发送文件的数据通道，所述实体单元与所述融合传输块生成单元之间形成有用于传输原始数据的数据通道；
物理传输层，所述融合传输块生成单元与所述物理传输层之间形成有用于将传输所述融合传输块的数据通道。
2.根据权利要求1所述的协议栈，其特征在于，所述物理传输层包括：卫星广播信道和互联网信道；
所述融合传输流子层还包括：发送单元和重传响应单元；
所述融合传输块生成单元与所述发送单元以及所述发送单元与所述卫星广播信道之间形成有用于传输所述融合传输块的数据通道；
所述融合传输块生成单元与所述重传响应单元之间以及所述重传响应单元与所述互联网信道之间形成有用于传输所述融合传输块的数据通道。
3.根据权利要求1所述的协议栈，其特征在于，所述实体单元将待发送文件进行前置处理生成原始数据，包括：
为每个所述待发送文件添加一个文件描述头；
将添加有文件描述头的所述待发送文件分割为至少一个文件段；其中，所述至少一个文件段形成所述原始数据。
4.根据权利要求1所述的协议栈，其特征在于，所述实体单元将所述待发送文件进行前置处理生成原始数据，包括：
将待发送文件进行编码生成文件编码符号；
根据待发送文件生成对应的文件描述信息；
将所述文件描述信息添加对应的业务描述信息头，以生成业务描述信息；其中，所述业务描述信息和文件编码符号形成所述原始数据。
5.根据权利要求2所述的协议栈，其特征在于，
所述卫星广播信道包括：下一代广播电视无线NGB-W/S信道或数字卫星广播系统DVB-S信道；
所述发送单元将融合传输块封装为适用于NGB-W/S信道或DVB-S信道的广播数据，并经由数据通道发送至NGB-W/S信道或DVB-S信道。
6.根据权利要求2所述的协议栈，其特征在于，
所述重传响应单元与所述互联网信道之间还形成有用于传输重传请求的消息通道；
所述重传响应单元经由所述消息通道接收所述重传请求，并将封装有融合传输块的重传响应经由数据通道发送至所述互联网信道。
7.根据权利要求6所述的协议栈，其特征在于，
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传响应单元经由所述消息通道接收UDP信道发送的UDP重传请求，并将封装有融合传输块的UDP重传响应经由数据通道发送至UDP信道；
所述重传响应单元经由所述消息通道接收HTTP信道发送的HTTP重传请求，并将封装有融合传输块的HTTP重传响应经由数据通道发送至HTTP信道。
8.根据权利要求7所述的协议栈，其特征在于，
当请求重传的融合传输块的数据量小于阈值时，所述重传响应单元通过UDP信道接收所述UDP重传请求和发送所述UDP重传响应；
当请求重传的融合传输块的数据量大于阈值时，所述重传响应单元通过HTTP信道接收所述HTTP重传请求和发送所述HTTP重传响应。
9.一种基于融合传输系统的协议栈，其特征在于，用于终端，包括：
业务应用层，包括用于接收待处理文件的原始数据的文件单元；
融合传输层，包括业务特定传输协议子层和融合传输流子层；
业务特定传输协议子层包括有至少一个用于将融合传输块进行解析生成原始数据的实体单元；
每个实体单元与所述文件单元之间形成有传输待发送文件的原始数据的数据通道，每个所述实体单元与融合传输流子层之间形成有用于传输融合传输块的数据通道；
物理传输层，所述物理传输层与所述融合传输流子层之间形成有用于传输所述融合传输块的数据通道。
10.根据权利要求9所述的协议栈，其特征在于，所述物理传输层包括：卫星广播信道和互联网信道；
所述融合传输流子层包括接收单元和重传请求单元；
所述卫星广播信道与接收单元之间以及所述接收单元与实体单元之间形成有用于传输所述融合传输块的数据通道；
所述互联网信道与重传请求单元之间以及所述重传请求单元与实体单元之间形成有用于传输所述融合传输块的数据通道。
11.根据权利要求9所述的协议栈，其特征在于，所述实体单元将融合传输块进行解析生成原始数据，包括：
将融合传输块解封装，得到至少一个文件段；其中，所述原始数据为将添加有文件描述头的所述待发送文件分割为至少一个文件段而形成。
12.根据权利要求9所述的协议栈，其特征在于，所述实体单元将融合传输块进行解析生成原始数据，包括：
将融合传输块解封装，得到文件编码符号和业务描述信息；
其中，所述原始数据包括业务描述信息和文件编码符号，所述业务描述信息为将所述待发送文件的文件描述信息添加对应的业务描述信息头而生成。
13.根据权利要求10所述的协议栈，其特征在于，
所述卫星广播信道包括：下一代广播电视无线NGB-W/S信道或数字卫星广播系统DVB-S信道；
所述接收单元将所述NGB-W/S信道或所述DVB-S信道的广播数据解封装为融合传输块，并将所述融合传输块经由数据通道发送至所述实体单元。
14.根据权利要求10所述的协议栈，其特征在于，
所述重传请求单元与所述互联网信道之间还形成有用于传输重传请求的消息通道；
所述重传请求单元经由所述消息通道发送所述重传请求，并经由数据通道接收所述互联网信道发送的封装有融合传输块的重传响应。
15.根据权利要求14所述的协议栈，其特征在于，
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传请求单元经由所述消息通道发送UDP重传请求至UDP信道，并经由数据通道接收UDP信道发送的封装有融合传输块的UDP重传响应；
所述重传请求单元经由所述消息通道接收HTTP重传请求至HTTP信道，并经由数据通道接收HTTP信道发送的封装有融合传输块的HTTP重传响应。
16.根据权利要求15所述的协议栈，其特征在于，
当请求重传的融合传输块的数据量小于阈值时，所述重传请求单元通过UDP信道发送所述UDP重传请求和接收所述UDP重传响应；
当请求重传的融合传输块的数据量大于阈值时，所述重传请求单元通过HTTP信道发送所述HTTP重传请求和接收所述HTTP重传响应。
17.一种基于融合传输系统的数据重传的方法，其特征在于，用于权利要求1-8任一项所述的协议栈，包括：
所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
所述融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
18.根据权利要求17所述的方法，其特征在于，
所述物理传输层包括：卫星广播信道和互联网信道；
所述融合传输流子层经由所述互联网信道接收重传请求和发送重传响应。
19.根据权利要求18所述的方法，其特征在于，
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传请求包括：UDP重传请求和HTTP重传请求；
所述重传响应包括：UDP重传响应和HTTP重传响应；
所述融合传输流子层经由UDP信道接收UDP重传请求，所述融合传输流子层将封装有重传数据的UDP重传响应经由UDP信道发出；
所述融合传输流子层经由HTTP信道接收HTTP重传请求，所述融合传输流子层将封装有重传数据的HTTP重传响应经由HTTP信道发出。
20.根据权利要求19所述的方法，其特征在于，
当所述重传数据的数据量小于阈值时，所述融合传输流子层通过UDP信道接收所述UDP重传请求和发送所述UDP重传响应；
当所述重传数据的数据量大于阈值时，所述融合传输流子层通过HTTP信道接收所述HTTP重传请求和发送所述HTTP重传响应。
21.根据权利要求17所述的方法，其特征在于，
所述重传数据包括：待发送文件的文件段或文件源符号。
22.根据权利要求19所述的方法，其特征在于，
所述UDP重传请求包括：必选参数和可选参数；
所述必选参数包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识和重传请求编号；
所述可选参数包括：业务流内编号、业务内文件标识、请求的源符号总数、请求的源符号组数、每组源符号列表、请求的融合传输块总数、请求的融合传输块组数和每组融合传输块序号；
每组所述源符号列表包括：源块号、源符号起始标识和源符号个数；
所述每组融合传输块序号包括：融合传输块起始序号和融合传输块个数；
所述HTTP重传请求包括：URL前缀、端口号、具体目录和请求参数；
所述请求参数包括：融合传输流标识、重传请求编号和请求的融合传输块列表；或
融合传输流标识、重传请求编号、流内业务编号、业务内文件标识、请求的源符号列表；或
融合传输流标识、重传请求编号、流内业务编号、业务描述信息类型和文件列表。
23.根据权利要求19所述的方法，其特征在于，
所述UDP重传响应包括：融合传输流协议版本、消息报文类型、消息报文长度、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量、至少一个请求的融合传输块以及校验码；
所述HTTP重传响应包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个融合传输块的长度、融合传输块的数量和至少一个请求的融合传输块。
24.一种基于融合传输系统的数据重传的方法，其特征在于，用于权利要求9-16任一项所述的协议栈，包括：
所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
25.根据权利要求24所述的方法，其特征在于，
所述物理传输层包括：卫星广播信道和互联网信道；
所述融合传输流子层经由所述互联网信道发送重传请求和接收重传响应。
26.根据权利要求25所述的方法，其特征在于，
所述互联网信道包括：用户数据报协议UDP信道和超文本传输协议HTTP信道；
所述重传请求包括：UDP重传请求和HTTP重传请求；
所述重传响应包括：UDP重传响应和HTTP重传响应；
所述融合传输流子层发送UDP重传请求至UDP信道，所述融合传输流子层接收UDP信道发送的封装有重传数据的UDP重传响应；
所述融合传输流子层发送HTTP重传请求至HTTP信道，所述融合传输流子层接收HTTP信道发送的封装有重传数据的HTTP重传响应。
27.根据权利要求26所述的方法，其特征在于，
当所述重传数据的数据量小于阈值时，所述融合传输流子层通过UDP信道发送所述UDP重传请求和接收所述UDP重传响应；
当所述重传数据的数据量大于阈值时，所述融合传输流子层通过HTTP信道发送所述HTTP重传请求和接收所述HTTP重传响应。
28.根据权利要求24所述的方法，其特征在于，
所述重传数据包括：待发送文件的文件段或文件源符号。
29.根据权利要求24所述的方法，其特征在于，
所述融合传输块请求包括：必选参数和可选参数；
所述必选参数包括：融合传输流标识和重传请求编号；
所述可选参数包括：业务描述信息类型、流内业务编号、文件列表、业务内文件标识、请求的源符号总数、请求的源符号列表、请求的融合传输块总数和请求的融合传输块列表；
所述融合传输块响应包括：融合传输流标识、重传请求编号、重传结果、重传错误类型、重传成功的融合传输块的数目以及重传成功的融合传输块的数据。
30.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现以下步骤：
所述融合传输流子层经由物理传输层接收终端发送的重传请求；其中，所述重传请求中包括重传数据的信息；
所述融合传输流子层根据重传请求向所述实体单元询问并获得重传数据，且所述融合传输流子层将所述重传数据生成融合传输块；
所述融合传输流子层将所述融合传输块封装形成重传响应、并将重传响应经由物理传输层发送至终端。
31.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述指令时实现以下步骤：
所述实体单元对获取的原始数据进行解码，在对待处理文件的原始数据解码失败后，发送请求重传数据的融合传输块请求至所述融合传输流子层；其中，所述原始数据为所述实体单元对接收到的融合传输块进行解析生成；
所述融合传输流子层根据所述融合传输块请求生成重传请求，且所述融合传输流子层将所述重传请求经由所述物理传输层发送至服务器；
所述融合传输流子层接收服务器经由所述物理传输层发送的封装有重传数据的重传响应；
所述融合传输流子层根据所述重传响应生成融合传输块响应、并将所述融合传输块响应发送至所述实体单元；
所述实体单元对所述融合传输块响应进行解析获得所述重传数据，并继续对待处理文件的重传数据进行解码，直至解码得到整个待处理文件。
32.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该指令被处理器执行时实现权利要求17-23任意一项所述方法的步骤或权利要求24-29任意一项所述方法的步骤。
CN201810094567.8A 2018-01-31 2018-01-31 一种基于融合传输系统的协议栈、数据重传的方法 Active CN110098899B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810094567.8A CN110098899B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的协议栈、数据重传的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810094567.8A CN110098899B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的协议栈、数据重传的方法

Publications (2)

Publication Number Publication Date
CN110098899A true CN110098899A (zh) 2019-08-06
CN110098899B CN110098899B (zh) 2021-11-09

Family

ID=67442377

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810094567.8A Active CN110098899B (zh) 2018-01-31 2018-01-31 一种基于融合传输系统的协议栈、数据重传的方法

Country Status (1)

Country Link
CN (1) CN110098899B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181698A (zh) * 2019-10-31 2020-05-19 腾讯云计算（北京）有限责任公司 数据处理方法、装置、设备及介质
CN116367308A (zh) * 2023-03-10 2023-06-30 中国电信股份有限公司卫星通信分公司 确定终端数据传输方式的方法、装置以及电子设备

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1668037A (zh) * 2004-03-10 2005-09-14 浙江大学 融合ip网络和有线电视网络的接入方法及其设备
CN101022571A (zh) * 2006-02-15 2007-08-22 华为技术有限公司 一种实现移动多媒体业务的系统和方法
EP1826930A2 (en) * 2006-02-27 2007-08-29 Samsung Electronics Co.,Ltd. Method and apparatus for supporting mobility in DVB-H CBMS system
US20080170531A1 (en) * 2007-01-12 2008-07-17 Petry Brian D Convergence sublayer for use in a wireless broadcasting system
CN102739650A (zh) * 2012-05-28 2012-10-17 无锡力合数字电视技术有限公司 结合广电网和互联网的文件传输系统
CN103108213A (zh) * 2011-11-14 2013-05-15 中国科学院声学研究所 一种将数字地面多媒体广播系统双向化的方法
CN103546765A (zh) * 2013-06-08 2014-01-29 上海数字电视国家工程研究中心有限公司 传输流封装方法、传输流及其解析方法
CN103703797A (zh) * 2013-08-29 2014-04-02 华为技术有限公司 聚合传输的方法、装置和系统以及网络服务器和用户设备
CN104869461A (zh) * 2015-05-22 2015-08-26 南京创维信息技术研究院有限公司 视频数据处理系统及方法
US20160234754A1 (en) * 2015-02-10 2016-08-11 Qualcomm Incorporated Relay signaling between ue and network
CN105900392A (zh) * 2013-09-26 2016-08-24 相干逻辑公司 下一代广播系统和方法

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1668037A (zh) * 2004-03-10 2005-09-14 浙江大学 融合ip网络和有线电视网络的接入方法及其设备
CN101022571A (zh) * 2006-02-15 2007-08-22 华为技术有限公司 一种实现移动多媒体业务的系统和方法
EP1826930A2 (en) * 2006-02-27 2007-08-29 Samsung Electronics Co.,Ltd. Method and apparatus for supporting mobility in DVB-H CBMS system
US20080170531A1 (en) * 2007-01-12 2008-07-17 Petry Brian D Convergence sublayer for use in a wireless broadcasting system
CN103108213A (zh) * 2011-11-14 2013-05-15 中国科学院声学研究所 一种将数字地面多媒体广播系统双向化的方法
CN102739650A (zh) * 2012-05-28 2012-10-17 无锡力合数字电视技术有限公司 结合广电网和互联网的文件传输系统
CN103546765A (zh) * 2013-06-08 2014-01-29 上海数字电视国家工程研究中心有限公司 传输流封装方法、传输流及其解析方法
CN103703797A (zh) * 2013-08-29 2014-04-02 华为技术有限公司 聚合传输的方法、装置和系统以及网络服务器和用户设备
CN105900392A (zh) * 2013-09-26 2016-08-24 相干逻辑公司 下一代广播系统和方法
US20160234754A1 (en) * 2015-02-10 2016-08-11 Qualcomm Incorporated Relay signaling between ue and network
CN104869461A (zh) * 2015-05-22 2015-08-26 南京创维信息技术研究院有限公司 视频数据处理系统及方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
闫复利: ""专网与4G网络融合在应急通信的应用研究"", 《通信技术-电子测量技术》 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181698A (zh) * 2019-10-31 2020-05-19 腾讯云计算（北京）有限责任公司 数据处理方法、装置、设备及介质
CN116367308A (zh) * 2023-03-10 2023-06-30 中国电信股份有限公司卫星通信分公司 确定终端数据传输方式的方法、装置以及电子设备

Also Published As

Publication number Publication date
CN110098899B (zh) 2021-11-09

Similar Documents

Publication Publication Date Title
US20180123810A1 (en) Methods for delivery of flows of objects over broadcast/multicast enabled networks
AU2005268492B2 (en) Point-to-point repair request mechanism for point-to-multipoint transmission systems
CN110099087B (zh) 一种基于融合传输系统的文件传输方法
EP3319330B1 (en) Multicast transmission method, apparatus, and system for ott media
US10470000B2 (en) Methods and apparatus for enhanced MBMS content provisioning and content ingestion
CN110099086A (zh) 一种基于融合传输系统的数据传输方法
KR20140009315A (ko) 방송 시스템에서의 멀티미디어 프레임 전송장치 및 방법
CN105580342B (zh) 发送广播信号的方法、接收广播信号的方法、发送广播信号的设备以及接收广播信号的设备
CN106233703B (zh) 接收设备、接收方法、传输设备以及传输方法
US10218759B2 (en) Method and apparatus for transceiving data packet for transmitting and receiving multimedia data
CN107948762A (zh) 直播视频的传输方法、装置和系统
CN110224793A (zh) 一种基于媒体内容的自适应fec方法
CN103916375A (zh) Hfc网络下行数据多通道封装与传输方法
EP2207354B1 (en) Method and device for ensuring reliability during transmission of television data in a television system based on internet protocol
CN107070535A (zh) 一种提供全球天地一体卫星广播服务的方法
KR101346669B1 (ko) 데이터 수신 방법, 복구 방법 및 대응 단말기
Xu et al. Smart media transport: A burgeoning intelligent system for next generation multimedia convergence service over heterogeneous networks in China
CN110098899A (zh) 一种基于融合传输系统的协议栈、数据重传的方法
CN105827361B (zh) 一种基于媒体内容的fec方法
US9160638B2 (en) Method and apparatus for performing non real time service in digital broadcast system
CN103826143A (zh) 基于多播和单播混用的视频点播服务提供装置及其方法

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