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

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

Info

Publication number
WO2019149054A1
WO2019149054A1 PCT/CN2019/071618 CN2019071618W WO2019149054A1 WO 2019149054 A1 WO2019149054 A1 WO 2019149054A1 CN 2019071618 W CN2019071618 W CN 2019071618W WO 2019149054 A1 WO2019149054 A1 WO 2019149054A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
source symbol
fused
description information
service
Prior art date
Application number
PCT/CN2019/071618
Other languages
English (en)
French (fr)
Inventor
南凯
王冬冬
张威
姜红旗
邢观斌
邱翔东
李群
Original Assignee
国广融合（北京）传媒科技发展有限公司
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 国广融合（北京）传媒科技发展有限公司 filed Critical 国广融合（北京）传媒科技发展有限公司
Publication of WO2019149054A1 publication Critical patent/WO2019149054A1/zh

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

Definitions

  • the present application relates to the field of communications technologies, and in particular, to a file transmission method based on a converged transmission system.
  • the satellite mobile broadcast system utilizes geosynchronous orbit satellites to provide multimedia information services including audio, video, data, etc. for signal coverage areas (which may include one or more countries and regions). Satellite mobile broadcasting has the advantages of wide coverage area, stable signal transmission in open areas, and high-speed mobile support terminals, and is especially suitable for providing information services for vehicle terminals.
  • the service can only rely on a single transmission service, such as a transmission service provided by a satellite broadcasting network alone or an Internet transmission service provided by a mobile communication network alone.
  • the terminal when a file is pushed, the terminal can completely decode the file after receiving the file from beginning to end at a specific time to complete the data reception. If the file decoding fails, the server side needs to be rotated multiple times to implement file retransmission, but the repeated reception of the received part of the file cannot be avoided, resulting in redundant data generation.
  • the embodiments of the present application provide a file transmission method and apparatus based on a converged transmission system, a computing device, and a computer readable storage medium, to solve the technical defects existing in the prior art.
  • the present application discloses a file transmission method based on a converged transmission system, which is applied to a server side, and the method includes:
  • the file source symbol of the requested file After receiving the file source symbol retransmission request sent by the terminal side, the file source symbol of the requested file is re-acquired, and the file source symbol of the file is encapsulated into a file source symbol retransmission response and sent to the terminal side.
  • the present application discloses a file transmission method based on a converged transmission system, which is applied to a terminal side, and the method includes:
  • Decoding according to the file source symbol after determining that the entire file fails to be decoded, continuing to send the file source symbol retransmission request to the server side until the entire file is decoded.
  • the present application discloses a computing device comprising a memory, a processor, and a computer program stored on the memory and operable on the processor, the processor implementing the program to implement the following steps:
  • the file source symbol of the requested file After receiving the file source symbol retransmission request sent by the terminal side, the file source symbol of the requested file is re-acquired, and the file source symbol of the file is encapsulated into a file source symbol retransmission response and sent to the terminal side.
  • the present application discloses a computing device comprising a memory, a processor, and a computer program stored on the memory and operable on the processor, the processor implementing the program to implement the following steps:
  • Decoding according to the file source symbol after determining that the entire file fails to be decoded, continuing to send the file source symbol retransmission request to the server side until the entire file is decoded.
  • the present application discloses a computer readable storage medium storing a computer program which, when executed by a processor, implements the steps of the file transfer method for the server side as described above or the file transfer method for the terminal side step.
  • the file transmission method based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • the method of the present application can accurately find the file source symbol that needs to be retransmitted, thereby avoiding repeated reception of the received part of the file, and saving network link resources.
  • FIG. 1 is a schematic structural diagram of a fusion transmission system according to an embodiment of the present application.
  • FIG. 2 is a schematic structural diagram of a protocol stack based on a converged transmission system for a server side according to an embodiment of the present application
  • FIG. 3 is a schematic structural diagram of a protocol stack based on a converged transmission system for a terminal side according to an embodiment of the present application
  • FIG. 4 is a schematic structural diagram of a converged transport stream according to an embodiment of the present application.
  • FIG. 5 is a schematic structural diagram of a fused transport block according to an embodiment of the present application.
  • FIG. 6 is a schematic structural diagram of a file coding symbol identifier in an embodiment of the present application.
  • FIG. 7 is a schematic diagram of a mapping process of each fused transport stream in a next-generation broadcast television wireless NGB-W/S channel according to an embodiment of the present application;
  • FIG. 8 is a schematic diagram of a mapping process and a TS packet structure of each fused transport stream in a DVB-S channel of a digital satellite broadcasting system according to an embodiment of the present application;
  • FIG. 9 is a flowchart of a file transmission method based on a converged transmission system for a server side according to an embodiment of the present application.
  • FIG. 10 is a schematic structural diagram of service description information according to an embodiment of the present application.
  • FIG. 11 is a schematic structural diagram of extended information of service description information according to an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of a file MD5 code according to an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of a file name in an embodiment of the present application.
  • 15 is a schematic diagram of file A of the embodiment of the present application pushing on four time segments of a fused transport stream;
  • 16 is a business schedule of a certain week of the embodiment of the present application.
  • FIG. 17 is a schematic structural diagram of a first fused transport block according to an embodiment of the present application.
  • FIG. 18 is a schematic diagram of a service description information encapsulated into two consecutive fused transport blocks according to an embodiment of the present application.
  • FIG. 19 is a schematic diagram of generating a fused transport stream according to an embodiment of the present application.
  • 20 is a schematic diagram of a terminal side requesting retransmission by a terminal side to send a UDP retransmission request to a server side according to an embodiment of the present application;
  • FIG. 21 is a schematic diagram of the terminal side requesting retransmission to the server side when sending an HTTP retransmission request according to an embodiment of the present application
  • FIG. 22 is a structural diagram of a UDP file source symbol retransmission request according to an embodiment of the present application.
  • FIG. 23 is a structural diagram of a UDP file source symbol retransmission response according to an embodiment of the present application.
  • FIG. 24 is a structural diagram of an HTTP file source symbol retransmission response body according to an embodiment of the present application.
  • 25 is a flowchart of a file transmission method based on a converged transmission system for a server side according to an embodiment of the present application
  • 26 is a flowchart of a file transmission method based on a converged transmission system for a terminal side according to an embodiment of the present application
  • FIG. 27 is a flowchart of a file transmission method based on a converged transmission system for a terminal side according to an embodiment of the present application.
  • FIG. 28 is a structural diagram of a file transmission apparatus based on a fusion transmission system according to an embodiment of the present application.
  • FIG. 29 is a structural diagram of a file transmission apparatus based on a converged transmission system according to an embodiment of the present application.
  • Service - A series of programs or data that can be broadcasted step by step according to a schedule under the control of a broadcaster.
  • Mobile satellite multimedia - multimedia services provided to mobile terminals via satellite communication networks, such as audio and video, on-demand and data push services.
  • Satellite broadcast network - A network that provides audio and video broadcasting and other information services based on geosynchronous orbit satellites.
  • Mobile communication network A network that provides mobile communications and two-way data transmission based on terrestrial base stations, including 2G/bidirectional/xG.
  • Network convergence transmission The same service uses both the satellite broadcast network and the mobile communication network to transmit to improve service coverage and service reliability.
  • Transport Stream (MPEG2-TS, also known as TS) - A communication protocol for sound effects, images and data used to encapsulate a composite stream of audio and video media data.
  • MPEG2-TS also known as TS
  • Converged transport block - A fixed-length packet structure used to carry upper-layer service data.
  • Converged transport stream - A composite information stream consisting of consecutive converged transport blocks that can transport multiple services.
  • Physical pipe - A physical layer channel that occupies certain channel resources and can be independently encoded and modulated.
  • Uniform resource identifier - A string used to identify the name of an Internet resource that allows the user to interact with any (including local and Internet) resources through a specific protocol.
  • File carousel - A method in which the original data of a file or its encoded data is continuously transmitted on a broadcast channel to ensure that the user receives the transmission.
  • Service orchestration A carousel time period on a converged transport stream that uniformly schedules files belonging to each service.
  • Source symbol - The smallest unit of file division in fountain coding.
  • the file push includes: on-demand file, file rotation, map file push, and so on.
  • the output data of various service platforms 101 is first submitted to the converged gateway 103.
  • the converged gateway 103 processes various service data, it generates a converged transport stream in a unified format.
  • the converged transport stream can be transmitted to the terminal 110 in two ways: one is submitted to the satellite broadcast headend device 105, sent to all terminals 110 via the satellite broadcast network 106 via the broadcast channel 108; the other is to save the data to an internet server or It is submitted to a cache server on the Content Delivery Network (CDN) 104 and provides a Uniform Resource Identifier (URI).
  • CDN Content Delivery Network
  • URI Uniform Resource Identifier
  • the terminal 110 can actively access the fused transport stream via the network channel 109 through the mobile communication network 107. data.
  • the satellite broadcast network 106 utilizes geosynchronous orbit satellites to provide multimedia information services including audio, video, data, etc. for signal coverage areas (which may include one or more countries and regions).
  • the satellite broadcasting network 106 has the advantages of wide coverage area, stable signal transmission in an open area, and high-speed movement of a support terminal, and is particularly suitable for providing an information service for an in-vehicle terminal.
  • the basic principle of the converged transmission system 10 is as follows:
  • the terminal 110 simultaneously receives signals from the satellite broadcast network 106 and from the mobile communication network 107.
  • the terminal 110 preferentially receives service data from the satellite broadcast network 106, but when on the satellite broadcast network 106
  • the terminal 110 will retransmit the lost or erroneous service data through the bidirectional link of the mobile communication network 107 to ensure the reliability of the service data reception.
  • the Big File Push (BFP) protocol is mainly used to implement reliable transmission of large files based on the network convergence transmission system, and can be used to transfer files from several Mbytes to a dozen Gbytes.
  • the BFP protocol supports a variety of file-based non-real-time services, such as high-quality audio and video on demand, map push, and more.
  • a protocol stack based on the BFP protocol can be set on both the server side and the terminal side, see FIG. 2 and FIG.
  • the protocol stack includes three layers: a service application layer, a converged transport layer, and a physical transport layer.
  • a network convergence transmission system services are no longer implemented by relying on a single network transmission service, such as a transmission service provided by a satellite broadcast network alone or an Internet transmission service provided by an interconnection communication network alone, but
  • the converged transmission function provided by the above two networks is implemented.
  • the above converged transmission function is implemented by a new protocol layer, the converged transport layer.
  • the converged transport layer shields the business from the details of the underlying network transport.
  • the service source only needs to submit the data to the converged transport layer, and the converged transport layer is responsible for pushing the service data on the satellite broadcast network and providing access to the service data on the interconnected communication network;
  • the converged transport layer is responsible for Receiving and checking the service data pushed by the satellite broadcast network, and starting the retransmission on the interconnection communication network as needed, and integrating the retransmitted service data with the service data received by the satellite broadcast network, and providing the upper layer service processing.
  • the types of services that need to be transmitted are diverse, and the quality of service (QoS) requirements of various services are also different.
  • QoS quality of service
  • the audio and video live broadcast service is required to ensure the real-time performance of the program, but a small amount of data loss is allowed; and the map data update needs to fully guarantee the reliability of the data, and the real-time performance of the data is low.
  • the converged transport layer is further divided into two sub-layers: a converged transport stream sub-layer and a service-specific transport protocol sub-layer.
  • the Converged Transport Stream sublayer provides a unified format, Converged Transport Block (CTB), to encapsulate data for various upper layer services.
  • CTB Converged Transport Block
  • the fused transport block is a data block having a fixed size and is consecutively numbered in the order of generation, which is referred to as a block number of the fused transport block.
  • the converged transport stream sublayer supports the transmission of the converged transport block over the satellite broadcast network.
  • transmission adaptation is required to encapsulate the converged transport blocks into different satellite broadcast link transport packets.
  • the fused transport stream sublayer supports retransmission of the fused transport block over the Internet, including retransmission of a single CTB, and also includes retransmission of multiple CTBs.
  • the block numbers of the multiple CTBs that are retransmitted may be continuous or discrete.
  • the service specific transport protocol sublayer is a service adaptation layer introduced to guarantee the quality of service (QoS) of different services.
  • the service specific transport protocol sublayer includes multiple transport protocols, each for one type of service to meet the real-time and reliability requirements of such services.
  • the main transport protocols include:
  • LSTP Live Streaming Protocol
  • BFP Large File Push Protocol
  • These transport protocols include how to process the data submitted by the service.
  • these transport protocols include specific retransmission functions and other service adaptation functions to meet business needs.
  • the fused transport stream is a composite information stream consisting of consecutively numbered fixed-length data blocks, the Converged Transport Block (CTB), which can be used to carry various types of upper-layer service data, as shown in Figure 4.
  • CTB Converged Transport Block
  • each converged transport stream is transmitted on a certain physical channel or logical channel.
  • the modulation coding scheme of the underlying channel is determined, one
  • the transmission rate of the fused transport stream is constant.
  • the system assigns each converged transport stream a 12-bit identifier called the Converged Transport Stream Identifier (CTS-ID).
  • CTS-ID Converged Transport Stream Identifier
  • a converged transport block is the basic unit for transmitting service information.
  • the size of its converged transport block is fixed, mainly determined by the physical channel protocol occupied by the converged transport stream. For example, when the NGB-W/S channel is used, the size of the fused transport block is fixed to 2118 bytes.
  • the fused transport block is composed of a block header, a block payload and a check field, wherein the block header size is fixed to 5 bytes, and the structure is as shown in FIG. 5.
  • Block number - 32-bit number used to cyclically number the fused transport block in the same fused transport stream.
  • the block number starts from 0.
  • the maximum value is 2 32 -1, it is numbered from 0.
  • the service type 3-bit, is used to indicate the type of service data encapsulated in the converged transport block, as shown in Table 1.
  • the service type is empty, the data in the fused transport block is filled with random data.
  • Check indicator - 1 bit A value of 1 indicates that there is a check field CRC32 at the end of the fused transport block. If the value is 0, there is no check field.
  • check field which is a 32-bit bit, is a check field.
  • the check indication is 1, the field checks the block header and block payload of the file transfer block.
  • the protocol stack disposed on the server side is as shown in FIG. 2, and includes:
  • the business application layer includes file units for storing files to be sent.
  • each service corresponds to a converged transport stream. Therefore, in the process of adding a file to a service, it is equivalent to specifying a converged transport stream for the file.
  • the converged transport layer includes a service specific transport protocol sublayer and a converged transport stream sublayer.
  • the service specific transport protocol sublayer includes at least one physical unit for preprocessing the file to be sent to generate the original data.
  • a data channel for transmitting a file to be sent is formed between the physical unit and the file unit, and the entity unit receives the file to be sent through the data channel, and then performs preprocessing on the file to be sent.
  • each physical unit corresponds to at least one file unit.
  • the service-specific transport protocol sub-layer can support multiple protocols.
  • the large-file push BFP protocol is used as an example to support the push service.
  • the physical unit is a BFP physical unit.
  • the entity unit When the service is pushed, the entity unit encodes the file to be sent to generate a file code symbol, generates a corresponding file description information according to the file to be sent, and adds the file description information to the corresponding service description information header to generate service description information.
  • the service description information and the file encoding symbol form the original data.
  • the file coding symbol and the service description information are respectively encapsulated in different converged transport blocks, and the converged transport block encapsulating the file coding symbol and the converged transport block encapsulating the service description information are not simultaneously A physical unit that is pushed to the terminal.
  • the entity unit performs forward error correction coding (FEC) on the file
  • FEC forward error correction coding
  • the FEC encoding algorithm used may be a Raptor fountain code.
  • the specific algorithm refers to the IETF standard RFC5053.
  • Encoding Symbol any number of encoding symbols (Encoding Symbol) can be generated, wherein the length of each encoding symbol is fixed.
  • each code symbol has a unique 32-bit identifier called File Encoding Symbol ID (FESI).
  • FESI File Encoding Symbol ID
  • each FESI consists of a 16-bit source block number (SBN). And 16-bit code symbol identification (ESI), as shown in Figure 6.
  • the Raptor fountain code is a system code.
  • the first source of the file is the source code of the file.
  • the source symbol is a special file code symbol.
  • Each source symbol has a FESI.
  • the actual transmitted symbols are other than the source symbols.
  • the decoding of the file may be implemented by requesting the server side to reissue the source symbol of the file.
  • the server side only needs to transmit the file encoding symbol of the file to the terminal side; in the process of requesting the retransmission, the terminal needs to request the file source symbol of the file from the server side.
  • the fused transport stream sublayer is used to encapsulate the original data into a fused transport block, and the fused transport stream formed by the fused transport block is transmitted to the terminal side via the physical transport layer.
  • the physical transport layer includes: a satellite broadcast channel and an internet channel.
  • a data channel for transmitting a fused transport block is formed between the fused transport stream sublayer and the satellite broadcast channel, and a data channel for transmitting the fused transport block is formed between the fused transport stream sublayer and the Internet channel.
  • the satellite broadcast channel includes: a next-generation broadcast television wireless NGB-W/S channel or a digital satellite broadcast system DVB-S channel;
  • the fused transport stream sublayer encapsulates the fused transport block into broadcast data suitable for the NGB-W/S channel or the DVB-S channel and transmits it to the NGB-W/S channel or the DVB-S channel via the data channel.
  • one or several fused transport streams can be combined and transmitted on one physical pipeline, and each fused transport stream occupies a fixed period on a continuous scheduling period on the physical pipeline, and the mapping process is as shown in FIG. 7. Shown.
  • Each of the fused transport blocks CTB of the fused transport stream is uniformly mapped into a link data packet, further encapsulated into a service load packet by the link layer, and handed over to the physical layer for coding and modulation.
  • the broadcast link uses the MPEG2-TS transport stream as the input form of the service, and does not divide the physical channel into several independent physical pipes. Therefore, a converged transport stream can be mapped directly to the entire physical channel or to a custom logical channel.
  • each fused transport block in the fused transport stream is mapped into an integer number of TS packets (188 bytes), and its mapping process and TS packet structure are as shown in FIG.
  • each TS packet includes a header (4 bytes) and a payload (184 bytes), and the header includes: a sync byte (8 bits), a transmission error indication (1 bit), and a payload unit start indication ( 1 bit), transmission priority (1 bit), program identification (13 bit), CTB start indication (1 bit), CTB end indication (1 bit), reservation (2 bit), and TS packet loop count (4 bits).
  • the Internet channel is described in detail below.
  • the Internet channel includes: a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel.
  • a message channel for transmitting a retransmission request is formed between the Internet channel and the fused transport stream sublayer; the fused transport stream sublayer receives the retransmission request via the message channel, and passes the retransmission response encapsulated with the fused transport block via the data
  • the channel is sent to the internet channel.
  • the fused transport stream sublayer receives the UDP retransmission request sent by the UDP channel via the message channel, and sends the UDP retransmission response encapsulated with the fused transport block to the UDP channel via the data channel; or the fused transport stream sublayer passes the message channel Receiving an HTTP retransmission request sent by the HTTP channel, and transmitting an HTTP retransmission response encapsulated with the fused transport block to the HTTP channel via the data channel.
  • the UDP channel and the HTTP channel are coexisting, and which channel is specifically used is determined by the terminal when transmitting the retransmission request.
  • the fused transport stream sublayer receives the UDP retransmission request and sends the UDP retransmission response through the UDP channel; when the data volume of the fused transport block requesting the retransmission is greater than the threshold, The fused transport stream sublayer receives the HTTP retransmission request and sends an HTTP retransmission response over the HTTP channel.
  • the protocol stack disposed on the terminal side is as shown in FIG. 3, and includes: a service application layer, a converged transport layer, and a physical transport layer.
  • the business application layer includes file units for receiving raw data of a file to be processed.
  • the converged transport layer includes a service specific transport protocol sublayer and a converged transport stream sublayer.
  • the service specific transmission protocol sublayer includes at least one physical unit for parsing the fused transport block to generate original data; each physical unit and the file unit form a data channel for transmitting original data of the file to be sent, and each physical unit A data channel for transmitting the fused transport block is formed with the fused transport stream sublayer.
  • the service-specific transport protocol sub-layer can support multiple protocols. This embodiment uses the BFP protocol as an example for description.
  • the entity unit parses the transport block to generate the original data, including:
  • the fused transport block is decapsulated to obtain file coding symbols and service description information.
  • the original data includes the service description information and the file coding symbol, and the service description information is generated by adding the file description information of the file to be sent to the corresponding service description information header.
  • the file coding symbol and the service description information are respectively encapsulated in different converged transport blocks, and the converged transport block encapsulating the file coding symbol and the converged transport block encapsulating the service description information are not.
  • the entity unit first decapsulates the fused transport block encapsulating the service description information to obtain the service description information, and establishes a file table of the required file according to the data, and then receives the fused transport block encapsulating the file code symbol. And parsing.
  • a data channel for transmitting the fused transport block is formed between the fused transport stream sublayer and the physical unit for receiving data via the satellite broadcast channel and transmitting a retransmission request and receiving retransmission data from the server side via the Internet channel.
  • a data channel for transmitting the fused transport block is formed between the physical transport layer and the fused transport stream sublayer.
  • the physical transport layer includes: a satellite broadcast channel and an internet channel.
  • a data channel for transmitting the fused transport block is formed between the satellite broadcast channel and the fused transport stream sublayer.
  • the satellite broadcast channel includes: an NGB-W/S channel or a DVB-S channel
  • the fused transport stream sublayer decapsulates the broadcast data of the NGB-W/S channel or the DVB-S channel into a fused transport block And transmitting the fused transport block to the physical unit via the data channel.
  • a data channel for transmitting the fused transport block is formed between the Internet channel and the fused transport stream sublayer, and a message channel for transmitting a retransmission request is formed between the Internet channel and the fused transport stream sublayer.
  • the fused transport stream sublayer sends a retransmission request via the message channel, and receives, via the data channel, a retransmission response encapsulated by the Internet channel and encapsulated with the fused transport block.
  • the Internet channel includes: a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel;
  • the fused transport stream sublayer sends a UDP retransmission request to the UDP channel via the message channel, and receives a UDP retransmission response encapsulated with the fused transport block sent by the UDP channel via the data channel;
  • the fused transport stream sublayer receives an HTTP retransmission request to the HTTP channel via the message channel, and receives an HTTP retransmission response encapsulated with the fused transport block sent by the HTTP channel via the data channel.
  • the UDP channel and the HTTP channel are coexisting, and which channel is specifically used is determined by the terminal side when transmitting the retransmission request.
  • the fused transport stream sublayer of the terminal side sends a UDP retransmission request and receives a UDP retransmission response through the UDP channel; when the data volume of the fused transport block requesting retransmission is greater than
  • the fused transport stream sublayer on the terminal side transmits an HTTP retransmission request and receives an HTTP retransmission response through the HTTP channel.
  • the fused transport stream sublayer on the terminal side determines whether the data volume of the retransmitted data is smaller than a packet threshold of a UDP retransmission response, and if yes, sends a UDP retransmission request and receives a UDP retransmission response by using the UDP channel; Then, the HTTP channel is used to send an HTTP retransmission request and receive an HTTP retransmission response.
  • the terminal side initiates a retransmission process, and the terminal side also actively determines the retransmission channel selection; for the server side, responds to the retransmission request sent by the terminal side, The same Internet channel as the retransmission channel on the terminal side transmits a retransmission response.
  • the physical transport layer of the present application uses a dual link of a satellite broadcast channel and an Internet channel, and uses a satellite broadcast channel to transmit data when pushing data; when retransmitting data, an Internet channel is used to retransmit lost or erroneous data, thereby Guarantee the reliability of data reception.
  • the above is a detailed description of the architecture of the protocol stack disclosed in the present application.
  • the protocol stack provides support for the operation of the converged transmission system.
  • a file transmission method and apparatus based on a converged transmission system, a computing device, and a computer readable storage medium are provided, which are described in detail in the following embodiments.
  • the method of file transmission in this embodiment is also described on the terminal side and the server side, respectively, as described in the protocol stack.
  • An embodiment of the present application discloses a file transmission method based on a converged transmission system. Referring to FIG. 9, the method is applied to the server side, and the method includes:
  • the file encoding symbol of the file to be pushed and the file description information corresponding to the file are obtained, and the file description information and the file encoding symbol of the file to be pushed are encapsulated into a fused transport stream and sent to the terminal side.
  • the BFP entity obtains the file encoding symbol of the file to be pushed and the file description information corresponding to the file, and the fused transport stream sublayer encapsulates the file description information and the file encoding symbol of the file to be pushed into the fused transmission through the satellite broadcast channel.
  • the stream is sent to the terminal side.
  • SDI Service Description Information
  • each service orchestration cycle one or more service description information related to the service orchestration cycle may be generated.
  • Each of the service description information may include description information of all the push files in the entire service orchestration period, or only the description information of the push file in the current period of time, for example, only the description information of the push file of the current day.
  • service description information is numbered according to the time sequence in which it is generated, which is called an update sequence number.
  • the service description information can be transmitted as a system control message inserted into the fused transport stream.
  • the service description information can be repeatedly sent, and the sending interval can be set as needed, for example, every 5 minutes.
  • the terminal side can also obtain the service description information of the fused transport stream through the mobile internet.
  • the method for generating the file description information of the file includes: adding the file to the service, and generating corresponding service description information according to the service.
  • each service corresponds to a converged transport stream, so the step of adding files to the service essentially specifies a converged transport stream for the file.
  • the service description information includes: a service description information header and file description information of the file in the service.
  • the service description information header includes: control message type (8bit), control message length (16bit), service orchestration cycle sequence number (16bit), description information update sequence number (8bit), and file description information number (8bit);
  • the file description information includes: basic information and extended information
  • the basic information includes: a file description information length (16 bits), a global file identifier (40 bits), a file length (48 bits), an extended information indication (1 bit), a file carousel status indication (3 bits), and a file type (4 bits);
  • the extended information includes: a next extended information indication (1 bit), an extended information type (7 bits), an extended information length (16 bits), and extended information content (8 Nbit).
  • Control message type - 8-bit bit indicating the type of control message: when the control message is a service description message, the value is 0x05; when the control message is a padding message, the value is 0xFF.
  • Control message length 16 bits, indicating the total length of the service description information.
  • the service orchestration cycle number is 16 bits, indicating the service orchestration period corresponding to the service description information.
  • the number of the business scheduling cycle corresponding to May 1, 2017 to May 7, 2017 can be set to 1, and the serial number of the business scheduling cycle from May 8, 2017 to May 14, 2017 is 2. ,So on and so forth.
  • the description information update sequence number is 8-bit bits, and the update sequence number corresponding to the first service description information in each service orchestration period is 0. Each time it is regenerated, the update sequence number is incremented by one.
  • Each file description information is composed of basic information and a plurality of extended information, wherein the basic information includes the following fields:
  • File Description Information Length - 16-bit indicating the length of the file description information, including basic information and extended information.
  • Global file identifier - 40-bit identifies the push file, including the 20-bit service identifier and the 20-bit local file identifier.
  • File length 48 bits, indicating the size of the file, in bytes.
  • Extended information indication 1-bit bit indicating whether there is extended information after the basic information, a value of 1 indicates that there is, and a value of 0 indicates no.
  • the extended information further describes the file-related attributes.
  • the fields of the extended information are as follows:
  • the next extended information indication - 1-bit bit indicates whether there is extended information after this extended information: a value of 1 indicates that there is; a value of 0 indicates no.
  • Extended information type - 7-bit identifies the type of extended information, as defined in Table 3.
  • Extended message length 16 bits, indicating the length of the entire extended message, in bytes.
  • the FEC encoding information is used to transmit the FEC encoding information of the file, and the corresponding extended information type is 1, and the content of the extended information is as shown in FIG.
  • the FEC coding information includes: coded symbol length (16 bits), number of source blocks (16 bits), number of sub-blocks (8 bits), and symbol alignment parameters (8 bits).
  • Number of source blocks - 16 bits, indicating the number of source blocks for file partitioning, refer to FEC_OTI parameter Z in RFC5053.
  • the file carousel information is used to transmit the carousel information of the file, and the corresponding extended information type is 2, and the content format of the extended information is as shown in FIG.
  • the file carousel information includes: remaining carousel time (24bit), remaining carousel time period 1* (48bit), remaining carousel time period 2*(48bit), ..., remaining carousel time period S*(48bit), Each remaining carousel period includes: a carousel time period start time (24 bits) and a carousel time period duration (24 bits).
  • Carousel duration - 24-bit indicating the duration of a carousel, in seconds.
  • the file MD5 code is used to transmit the MD5 code of the file, and the corresponding extended information type is 3, and the content format of the extended information is as shown in FIG.
  • the file name is used to transfer the file name, and the corresponding extended information type is 4, and the content format of the extended information is as shown in FIG.
  • File name - variable length field indicating the file name, length N-3, N is the total length of the extended information.
  • step 901 the file description information and the file encoding symbol of the file to be pushed are encapsulated into a fused transport stream and sent to the terminal side, including:
  • the file coding symbol of the file to be pushed is encapsulated into a first fused transport block according to a push time period in a pre-stored service schedule.
  • the service schedule table pre-stores a push time period of each file.
  • unified scheduling can be used to set the push time period of each file.
  • the time period involved in a business orchestration is called a business orchestration cycle.
  • the business orchestration cycle can be chosen by itself, for example one week.
  • a business schedule for a week is given in Figure 16.
  • the service scheduling period is seven days.
  • a total of four files (file A/B/C/D) are pushed during the service orchestration cycle.
  • Each file occupies multiple push time segments, such as file A. 5 push time periods (0:00 to 4:00 Monday to Friday, respectively), file B takes 5 push time periods, and so on.
  • file A 5 push time periods (0:00 to 4:00 Monday to Friday, respectively)
  • file B takes 5 push time periods, and so on.
  • the business schedule should contain the following:
  • Push time period list Each item corresponds to a push time period, including the start time, duration (or end time) of the time period and the global file identifier of the push file.
  • the push time period can be sorted by the start time, wherein the start time can be relative time (calculated from the start time of the entire business orchestration cycle).
  • the business orchestration table of a business orchestration cycle is generated before the start of the business orchestration cycle and remains substantially unchanged throughout the business orchestration cycle. If you need to adjust the file push schedule during the business orchestration cycle, you need to update its business schedule at the same time.
  • the first fused transport block includes: a block header of the first fused transport block, a block payload of the first fused transport block, and a check code;
  • the block payload of the first converged transport block includes: a symbol header (40 bits), one or two file encoding symbol identifiers (32 bits) of the file, and one or two file encoding symbol fields of the file (8*) Tbit) and padding code (8*Pbit);
  • the symbol header includes: a service stream number (8 bits), a local file identifier (20 bits), a symbol encapsulation mode (3 bits), and a reserved field (9 bits).
  • one or two file encoding symbols of the same push file may be encapsulated in one fused transport block.
  • the service type in the block header of the first converged transport block is 2, and the block payload of the first converged transport block is represented by a 5-byte symbol header, a file encoding symbol identifier 1 (FESI1), and a file encoding symbol field 1 (length). It is composed of T bytes), file encoding symbol identifier 2 (FESI2), and file encoding symbol field 2 (length is T bytes) and padding (P bytes).
  • FESI1 file encoding symbol identifier 1
  • FESI2 file encoding symbol field 2
  • P bytes padding
  • the length of the fused transport block changes, and the parameter T and the parameter P also change.
  • the number of file coding symbols, the parameter T and the parameter P are determined by the symbol header. Symbol encapsulation mode to indicate.
  • the number of the service stream - 8-bit indicating the number of the service corresponding to the file in the converged transport stream.
  • Local file identifier 20-bit, indicating the identifier of the file in its own service. This field, together with the converged transport stream identifier (CTS_ID) and the intra-service stream number, constitutes the global file identifier of the file.
  • mode 0 and mode 1 are suitable for the converged transport block under the next-generation broadcast TV wireless NGB-W/S standard
  • mode 2 and mode 3 are suitable for the converged transport block under the DVB-S standard of the digital satellite broadcasting system (mode 2).
  • mode 2 One of the fused transport blocks is transmitted in 6 TS packets, and one fused transport block in mode 3 is transmitted in 12 TS packets.
  • the service description information is encapsulated together with other control messages into a fused transport block or a plurality of fused transport blocks with consecutive block numbers.
  • the last converged transport block has enough space after the service description information is encapsulated, it can be padded with byte 0xFF.
  • the structure of the second fused transport block includes: a block header of the second fused transport block, a block payload of the second fused transport block, and a check code; and a block payload of the second fused transport block includes: a message header indication field and a service description information Field.
  • FIG. 1 A case where a service description information is encapsulated into two consecutive fused transport blocks is shown in FIG. The structure of the service description information is as described above, and will not be described here.
  • the service type in the block header is 3
  • the first two bytes of the block payload are the Head Indicator (HI) field, which is defined as follows:
  • Message Header Field (HI) - A 16-bit bit indicating the location of the first control message header that appears in the payload of the block.
  • the value of 0 indicates that the starting position of the service description information header is the first byte after the HI field, and the value of 1 indicates that the starting position of the service description information header is the second byte after the HI field. And so on; when there is no service description header in the payload, the field indicates the starting position of the padding byte 0xFF; if there is neither header or any padding in the payload, ie The payload is the middle part of a service description information, and the field value is 0xFFFF.
  • FIG. 19 is a schematic diagram of file A, file B, and file C generating a fused transport stream. It should be noted that file A, file B, and file C belong to the same service and are in the current push time period in the service schedule.
  • the server side combines the above two converged transport blocks according to the service orchestration table to generate a final converged transport stream.
  • the fused transport block with the service type of 7 ie, the null service
  • the fused transport block corresponding to the service description information may be repeatedly sent.
  • the Internet channel includes: a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel;
  • the file source symbol retransmission request includes: a UDP file source symbol retransmission request and an HTTP file source symbol retransmission request
  • the file source symbol retransmission response includes: a UDP file source symbol retransmission response and an HTTP file source symbol retransmission response.
  • the server side receives the UDP file source symbol retransmission request via the UDP channel, and sends the UDP file source symbol retransmission response via the UDP channel; or the server receives the HTTP file source symbol retransmission request via the HTTP channel, and retransmits the HTTP file source symbol.
  • the response is sent via the HTTP channel.
  • the UDP channel and the HTTP channel are coexisting, but the UDP channel and the HTTP channel can only be used one by one.
  • the server side receives the UDP file source symbol retransmission request and sends the UDP file source symbol retransmission request through a UDP channel;
  • the server side receives the HTTP file source symbol retransmission request and sends the HTTP file source symbol retransmission response through the HTTP channel.
  • FIG. 20 is a schematic diagram of the terminal side requesting retransmission by sending a UDP retransmission request to the server side
  • FIG. 21 is a schematic diagram of the terminal side requesting retransmission by sending an HTTP retransmission request to the server side.
  • the UDP file source symbol retransmission request UDP_CTB_REQ includes: a converged transport stream protocol version (8 bits), a message packet type (8 bits), a message packet length (16 bits), a converged transport stream identifier (12 bits), and a service stream.
  • Each set of file source symbol list (48bit) includes: source block number (16bit), file source symbol start identifier (16bit), and file source symbol number (16bit).
  • Message packet type - 8-bit indicating the type of UDP message.
  • Message message length 16 bits, indicating the number of bytes of the entire message message, starting from the protocol version to the Mth group of Encoding Symbols (ES), including CRC32.
  • the number of the service stream - 8-bit specifies the flow number of the industry stream, and together with the identity of the converged transport stream, identifies the service in which the reissue file is located.
  • In-service file identifier 20-bit, indicating the identifier of the file in the service, and the merged transport stream identifier and the in-stream service number together form the global file identifier of the file, and identify the file to which the re-issued code symbol belongs.
  • the number of source symbol groups requested - 8-bit bits indicating the number M of source symbol groups that are requested to be reissued this time. This value determines the number of subsequent source symbol group parameters.
  • the first set of source symbols 48 bits, indicating the first set of coded symbols that need to be retransmitted, consisting of a 16-bit source block number (SBN), a 16-bit ESI, and a 16-bit ES number.
  • SBN source block number
  • ESI 16-bit ESI
  • the second set of source symbols, ... the Mth group of source symbols - are all 48-bit bits, the existence of which is determined by the number of ES groups requesting retransmission, by 16-bit SBN, 16-bit ESI, and 16-bit ES. Number composition.
  • Check code (CRC32) - 32-bit bit, which verifies the message, including the protocol version to the M-th group ES parameter.
  • the UDP file source symbol retransmission response UDP_CTB_RESP includes: a converged transport stream protocol version, a message packet type, a message packet length, a converged transport stream identifier, a retransmission request number, a length of each first converged transport block, The number of first fused transport blocks that need to be retransmitted, at least one requested first fused transport block, and a check code.
  • Converged Transport Stream Protocol Version - 8-bit indicating the version of the Converged Transport Stream Protocol, current value is 0x01.
  • Message packet type - 8-bit indicating the type of UDP message.
  • the value is 0x81.
  • Message message length 16 bits, indicating the number of bytes of the entire message, starting from the protocol version to the Nth CTB, including CRC32.
  • each first converged transport block 4-bit bits
  • the length of each fused transport block indicates the length of each fused transport block. When the indication is 0, it indicates that the fused transport block length is the default value of 2118 bytes.
  • the total number of the first converged transport blocks which is the number of the first converged transport blocks, is determined by the total number of the first converged transport blocks in the retransmission feedback.
  • the first first fused transport block, the second first fused transport block, ... the Nth first fused transport block - indicates all of the first fused transport block data in the current retransmission feedback.
  • CRC32 32-bit bit that verifies the message, including the protocol version to the Nth check code.
  • the HTTP file source symbol retransmission request includes: a URL prefix, a port number, a specific directory, and a request parameter; the request parameters include: a converged transport stream identifier, a retransmission request number, an in-stream service number, a service internal file identifier, and a requested source symbol list. .
  • HTTP file source symbol retransmission response HTTP_CTB_RESP includes: response header and response body;
  • the response header includes: a response body type, a response body length, and a response body summary;
  • the response body includes: a fused transport stream protocol version, a fused transport stream identifier, a retransmission request number, a length of each first fused transport block, a number of first fused transport blocks that need to be retransmitted, and at least one The requested first fused transport block.
  • Response body summary - MD5 digest to be set as the entity body to detect its integrity
  • Converged Transport Stream Protocol Version - 8-bit indicating the version of the Converged Transport Stream Protocol, current value is 0x01.
  • the length of a single first fused transport block 4-bit bits, indicating the length of each first fused transport block, when the indication is 0, indicates that the first fused transport block length is a default value of 2118 bytes.
  • the total number of the first fused transport blocks, which are requested to be retransmitted is 16 bits, indicating the total number N of the first fused transport blocks in the current retransmission feedback, which determines the number of subsequent first fused transport blocks.
  • the first first fused transport block, the second first fused transport block, ... the Nth first fused transport block - indicates all of the first fused transport block data in the current retransmission feedback.
  • the method in the embodiment of the present application includes:
  • the server side receives the service description information sent by the terminal side, and sends a service description information retransmission response encapsulated with the service description information to the terminal side.
  • the server side encapsulates the file coded symbol of the file to be pushed into a fused transport stream and sends the file to the terminal side.
  • the server side After receiving the file source symbol retransmission request sent by the terminal side, the server side re-acquires the file source symbol of the requested file, and encapsulates the file source symbol of the file into a file source symbol retransmission response and sends the response to the terminal side.
  • the server side receives the service description information sent by the terminal side through the HTTP channel, and sends the service description information retransmission response encapsulated with the service description information to the terminal via the HTTP channel.
  • the service description information active request includes: a URL prefix, a port number, a specific directory, and a request parameter;
  • the request parameters include: a converged transport stream identifier, a retransmission request number, an in-stream service number, a service description information type, and a file list.
  • the service description information retransmission response includes: a response header and a response body;
  • the response header includes: a response body type, a response body length, and a response body summary;
  • the response body includes: a fused transport stream protocol version, a fused transport stream identifier, a retransmission request number retransmission request number, a length of each second fused transport block, a number of second fused transport blocks, and at least one packaged A second converged transport block of service description information.
  • the service description information is actively requested in the same format as the HTTP file source symbol retransmission request, and the service description information retransmission response is similar to the format of the HTTP file source symbol retransmission response.
  • the service description information retransmission response is similar to the format of the HTTP file source symbol retransmission response.
  • the file transmission method based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • the method of the present application can accurately find the file source symbols that need to be retransmitted, thereby avoiding repeated reception of the received partial files, and saving network link resources.
  • file push can be automatically turned off or manually turned off. When a file is sent on all push time periods, the push is automatically turned off. When manual shutdown is used, the fused transport stream will stop transmitting the file on subsequent push time periods, and these emptied push time periods can be reassigned to service usage.
  • the above is a file transmission method based on the converged transmission system for the server side, and a file transmission method based on the converged transmission system for the terminal side is described below.
  • the file transmission method provided by the embodiment of the present application is implemented based on the interaction between the server side and the terminal side, so the technical features of the embodiment overlap with the technical features of the file transmission method for the server side described above. .
  • the technical details that are not described in detail in this embodiment reference may be made to the above description of the file transfer method for the server side.
  • an embodiment of the present application provides a file transmission method based on a converged transmission system, which is used on a terminal side, and includes the following steps 2601 to 2605.
  • the terminal side receives the file description information in the fused transport stream, where the terminal side receives the second fused transport block encapsulated with the service description information in the fused transport stream, and parses and obtains the file description of the file.
  • Information wherein the service description information includes: a service description information header and file description information of the file in the service.
  • the terminal side receives the corresponding file encoding symbol in the fused transport stream according to the file description information, including: the terminal side establishes a to-be-received file list according to the file description information, and has a corresponding file encoding according to the receiving package.
  • the first fused transport block of the symbol is parsed to obtain the file encoding symbol.
  • the terminal side receives the file description information sent by the server side and a file encoding symbol of the file through a satellite broadcast channel.
  • the terminal side transmits the file source symbol retransmission request and receives the file source symbol retransmission response through an internet channel.
  • the Internet channel includes a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel;
  • the file source symbol retransmission request includes: a UDP file source symbol retransmission request and an HTTP file source symbol retransmission request; and the file source symbol retransmission response includes: a UDP file source symbol retransmission response and an HTTP file source symbol retransmission response.
  • the terminal side may send a UDP file source symbol retransmission request via a UDP channel, and receive the UDP file source symbol retransmission response via a UDP channel;
  • the terminal side may send an HTTP file source symbol retransmission request via an HTTP channel, and receive the HTTP file source symbol retransmission response via an HTTP channel.
  • the terminal side When the amount of file source symbol data requested by the terminal side to be retransmitted is less than a threshold, the terminal side sends the UDP file source symbol retransmission request through the UDP channel and receives the UDP file source symbol retransmission response; when the terminal side requests heavy When the amount of file source symbol data transmitted is greater than a threshold, the terminal side receives the HTTP file source symbol retransmission request and receives the HTTP file source symbol retransmission response through an HTTP channel.
  • the terminal side determines whether the data volume of the retransmission data is smaller than a packet threshold of a UDP retransmission response, and if yes, sends a UDP retransmission request and receives a UDP retransmission response by using a UDP channel; if not, sends the HTTP channel by using an HTTP channel.
  • HTTP retransmission request and receiving HTTP retransmission response can select the Internet channel according to the data volume of the retransmitted data, and the server side sends the retransmission response through the same Internet channel as the retransmission channel on the terminal side.
  • the file transmission method based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • the service description information may be actively requested by the terminal side, so that the terminal side establishes a file list to be received in advance.
  • the file transmission method based on the fusion transmission system of the present application includes:
  • the terminal side sends a service description information to the server side, and receives a service description information retransmission response that is sent by the server side and encapsulates the service description information.
  • the file transmission method based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • the embodiment of the present application discloses a file transmission device based on a converged transmission system, which is disposed on a server side, and the device includes:
  • the file sending module 2801 is configured to obtain a file encoding symbol of the file to be pushed and file description information corresponding to the file, and encapsulate the file description information and the file encoding symbol of the file to be pushed into a fused transport stream. To the terminal side.
  • the file sending module 2801 transmits the service description information and the file encoding symbol of the file to be pushed to the terminal side through a satellite broadcast channel.
  • the file sending module 2801 includes:
  • a file encoding symbol encapsulating module configured to encapsulate a file encoding symbol of the file to be pushed into a first converged transport block according to a push time period in a pre-stored service scheduling table; wherein the service choreography table is pre-stored Push time period for each file;
  • a service description information encapsulating module configured to encapsulate the newly generated service description information into a second converged transport block according to a set time interval
  • the fused transport stream sending module is configured to encapsulate the second fused transport block and the first fused transport block into a same fused transport stream and send the same to the terminal side.
  • the first fused transport block includes: a first fused transport block header, a first fused transport block payload, and a check code;
  • the first converged transport block payload includes: a symbol header, a file encoding symbol identifier of at least one of the files, a file encoding symbol field of one or two of the files, and a padding code;
  • the symbol header includes: a service flow number, a local file identifier, a symbol encapsulation mode, and a reserved field.
  • the second fused transport block includes: a second fused transport block header, a second fused transport block payload, and a check code; and the second fused transport block payload includes: a message header indication field and a service description information field.
  • the retransmission response module 2802 is configured to re-acquire the file source symbol of the requested file after receiving the file source symbol retransmission request sent by the terminal side, and encapsulate the file source symbol of the file into a file source symbol retransmission. The response is sent to the terminal side.
  • the retransmission response module 2802 receives the file source symbol retransmission request and transmits the file source symbol retransmission response through an internet channel.
  • the Internet channel includes: a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel;
  • the file source symbol retransmission request includes: a UDP file source symbol retransmission request and an HTTP file source symbol retransmission request;
  • the file source symbol retransmission response includes: a UDP file source symbol retransmission response and an HTTP file source symbol retransmission response.
  • the retransmission response module 2802 receives the UDP file source symbol retransmission request via the UDP channel, the file sending module sends the UDP file source symbol retransmission response via the UDP channel, and the retransmission response module 2802 receives the HTTP file source symbol retransmission via the HTTP channel.
  • the retransmission response module 2802 When the amount of the file source symbol data requested by the terminal side to be retransmitted is less than the threshold, the retransmission response module 2802 receives the UDP file source symbol retransmission request and sends the UDP file source symbol retransmission request through the UDP channel; when the terminal side requests When the retransmitted file source symbol data amount is greater than the threshold, the retransmission response module 2802 receives the HTTP file source symbol retransmission request and transmits the HTTP file source symbol retransmission response through the HTTP channel.
  • the UDP file source symbol retransmission request includes: a fused transport stream protocol version, a message packet type, a message packet length, a fused transport stream identifier, a service stream internal number, a service internal file identifier, a retransmission request number, and a request weight.
  • Each set of the file source symbol list includes: a source block number, a file source symbol start identifier, and a file source symbol number.
  • the UDP file source symbol retransmission response includes: a fused transport stream protocol version, a message packet type, a message packet length, a fused transport stream identifier, a retransmission request number, a length of each first fused transport block, and a required weight The number of first fused transport blocks transmitted, at least one requested first fused transport block, and a check code.
  • the HTTP file source symbol retransmission request includes: a URL prefix, a port number, a specific directory, and a request parameter;
  • the request parameters include: a fused transport stream identifier, a retransmission request number, an in-stream service number, an in-service file identifier, and a requested source symbol list.
  • the HTTP file source symbol retransmission response includes: a response header and a response body;
  • the response header includes: a response body type, a response body length, and a response body summary;
  • the response body includes: a fused transport stream protocol version, a fused transport stream identifier, a retransmission request number, a length of each first fused transport block, a number of first fused transport blocks that need to be retransmitted, and a first of at least one request Converged transport blocks.
  • the file transmission device of the present application further includes:
  • the service description information generating module is configured to add the file to the service, and generate corresponding service description information according to the service.
  • the service description information includes: a service description information header and file description information of the file in the service.
  • the service description information sending module is configured to receive an active request for the service description information sent by the terminal side, and send a service description information retransmission response encapsulated with the service description information to the terminal side.
  • the service description information active request includes: a URL prefix, a port number, a specific directory, and a request parameter;
  • the request parameter includes: a fused transport stream identifier, a retransmission request number, an in-stream service number, a service description information type, and a file list;
  • the service description information retransmission response includes: a response header and a response body;
  • the response header includes: a response body type, a response body length, and a response body summary;
  • the response body includes: a fused transport stream protocol version, a fused transport stream identifier, a retransmission request number, a length of each second fused transport block, a number of second fused transport blocks, and at least one encapsulated with the service description information.
  • the second converged transport block includes: a fused transport stream protocol version, a fused transport stream identifier, a retransmission request number, a length of each second fused transport block, a number of second fused transport blocks, and at least one encapsulated with the service description information.
  • the file transmission device based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • the embodiment of the present application further discloses a file transmission device based on a converged transmission system, which is disposed on the terminal side, as shown in FIG. 29, and includes:
  • the file description information receiving module 2901 is configured to receive file description information in the fused transport stream.
  • the file description information receiving module 2901 receives the file description information sent by the server side through a satellite broadcast channel.
  • the file description information receiving module 2901 receives the file description information in the fused transport stream, and the file description information receiving module 2901 receives the second fused transport block encapsulated with the service description information in the fused transport stream, and parses and obtains File description information of the file; wherein the service description information includes: a service description information header and file description information of the file in the service.
  • the file encoding symbol receiving module 2902 is configured to receive a corresponding file encoding symbol in the fused transport stream according to the file description information.
  • the file encoding symbol receiving module 2902 receives the file encoding symbol of the file through a satellite broadcast channel.
  • the file encoding symbol receiving module 2902 receives the corresponding file encoding symbol in the fused transport stream according to the file description information, including: the file encoding symbol receiving module 2902 establishes a file list to be received according to the file description information, and And obtaining the file encoding symbol according to the first fusion transport block that is encapsulated with the corresponding file encoding symbol.
  • the file encoding symbol decoding module 2903 is configured to decode the received file encoding symbol of the file, and notify the file source symbol retransmission request module to act after determining that the entire file fails to be decoded.
  • the file source symbol retransmission request module 2904 is configured to send a file source symbol retransmission request to the server side.
  • the file source symbol retransmission request module 2904 transmits the file source symbol retransmission request through an internet channel.
  • the file source symbol receiving module 2905 is configured to receive and parse the file source symbol retransmission response of the file source symbol encapsulating the file to obtain a file source symbol of the file.
  • the file source symbol receiving module 2905 receives the file source symbol retransmission response through an internet channel.
  • the Internet channel includes a User Datagram Protocol UDP channel and a Hypertext Transfer Protocol HTTP channel.
  • the file source symbol retransmission request includes: a UDP file source symbol retransmission request and an HTTP file source symbol retransmission request;
  • the file source symbol retransmission response includes: a UDP file source symbol retransmission response and an HTTP file source symbol retransmission response.
  • the file source symbol retransmission request module 2904 sends a UDP file source symbol retransmission request via the UDP channel, the file source symbol receiving module 2905 receives the UDP file source symbol retransmission response via the UDP channel; the file source symbol retransmission request module 2904 transmits via the HTTP channel.
  • the HTTP file source symbol retransmission request, the file source symbol receiving module 2905 receives the HTTP file source symbol retransmission response via the HTTP channel.
  • the file source symbol retransmission request module 2904 transmits a UDP file source symbol retransmission request through the UDP channel, and the file source symbol receiving module 2905 receives the UDP file source symbol retransmission through the UDP channel.
  • the file source symbol retransmission request module 2904 transmits an HTTP file source symbol retransmission request through the HTTP channel, and the file source symbol receiving module 2905 receives the HTTP file source symbol through the HTTP channel. Retransmit the response.
  • the file source symbol decoding module 2906 is configured to decode the file source symbol of the file, and after determining that the entire file fails to be decoded, notify the file source symbol retransmission request module 2904 to operate until the entire file is decoded.
  • the file transmission device of the present application further includes:
  • the service description information requesting module is configured to send the service description information to the server side, and receive the service description information retransmission response that is sent by the server side and encapsulates the service description information.
  • the file transmission device based on the converged transmission system provided by the present application sends a file source symbol retransmission request to the server side after the terminal side fails to decode the file encoding symbol of the file, and the server side encapsulates the requested file source symbol into the file source symbol.
  • the retransmission response is sent to the terminal side to implement complete decoding of the file on the terminal side, thereby ensuring the reliability of file transmission.
  • An embodiment of the present application discloses a computing device capable of implementing a file transfer method.
  • Components of the computing device include, but are not limited to, a memory and a processor, the processor being coupled to the memory.
  • the computing device can also include a network interface that enables the computing device to communicate via one or more networks.
  • networks include a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet.
  • the network interface may include one or more of any type of network interface (eg, a network interface card (NIC)), wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, global microwave interconnect access (Wi- MAX) interface, Ethernet interface, Universal Serial Bus (USB) interface, cellular network interface, Bluetooth interface, Near Field Communication (NFC) interface, and more.
  • the computing device can access the page through a network interface.
  • other components of the computing device not shown above may also be connected to each other, such as by a bus.
  • the computing device can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (eg, tablet computer, personal digital assistant, laptop computer, notebook computer, netbook, etc.), mobile phone (eg, smart phone)
  • a wearable computing device eg, a smart watch, smart glasses, etc.
  • a stationary computing device such as a desktop computer or PC.
  • the computing device can also be a mobile or static server.
  • the file source symbol of the requested file After receiving the file source symbol retransmission request sent by the terminal side, the file source symbol of the requested file is re-acquired, and the file source symbol of the file is encapsulated into a file source symbol retransmission response and sent to the terminal side.
  • the processor may further implement the following steps when executing the program:
  • Decoding according to the file source symbol after determining that the entire file fails to be decoded, continuing to send the file source symbol retransmission request to the server side until the entire file is decoded.
  • An embodiment of the present application further provides a computer readable storage medium storing a computer program, which when executed by a processor, implements the steps of the file transfer method based on the fused transport system for the server side as described above.
  • An embodiment of the present application further provides a computer readable storage medium storing a computer program, which when executed by a processor, implements the steps of the file transfer method based on the fusion transmission system for the terminal side as described above.
  • the above is a schematic illustration of a computer readable storage medium of the present embodiment. It should be noted that the technical solution of the storage medium belongs to the same concept as the technical solution of the file transmission method described above, and the details of the technical solution of the storage medium are not described in detail.
  • the computer instructions include computer program code, which may be in the form of source code, an object code, an executable, or some intermediate form.
  • the computer readable medium may include any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a removable hard disk, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM). , random access memory (RAM, Random Access Memory), electrical carrier signals, telecommunications signals, and software distribution media. It should be noted that the content contained in the computer readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in a jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, computer readable media Does not include electrical carrier signals and telecommunication signals.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

本申请提供一种基于融合传输系统的文件传输方法，所述方法包括：获取待推送的文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端；在接收到终端发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端。

Description

一种基于融合传输系统的文件传输方法
本申请要求于2018年1月31日提交中国专利局、申请号为201810094340.3、发明名称为“一种基于融合传输系统的文件传输方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，特别涉及一种基于融合传输系统的文件传输方法。
背景技术
卫星移动广播系统利用地球同步轨道卫星来为信号覆盖区域(可包括一个或多个国家和地区)提供包括音频、视频、数据等在内的多媒体信息服务。卫星移动广播具有覆盖区域广、在开阔地区信号传输稳定、支持终端的高速移动等优点，尤其适合为车载终端提供信息服务。
但是目前卫星移动广播在进行业务数据传输的过程中，业务只能依赖单一的传输服务，比如单独由卫星广播网提供的传输服务或是单独由移动通信网提供的互联网传输服务。
现有技术中，当推送某个文件时，终端只有在特定时间从头到尾将该文件接收完毕后彻底解码才能完成数据的接收。假如文件解码失败，需要服务器侧轮播多遍来实现文件的重传，但是不能避免文件的已接收部分的重复接收，造成冗余数据的产生。
发明内容
有鉴于此，本申请实施例提供了一种基于融合传输系统的文件传输方法及装置、计算设备和计算机可读存储介质，以解决现有技术中存在的技术缺陷。
本申请公开了一种基于融合传输系统的文件传输方法，应用于服务器侧，所述方法包括：
获取待推送的文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端侧；
在接收到终端侧发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端侧。
本申请公开了一种基于融合传输系统的文件传输方法，应用于终端侧，所述方法包括：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器侧发送文件源符号重传请求；
对接收到的封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器侧发送文件源符号重传请求，直至解码得到整个文件。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：
获取待推送的文件的文件编码符号以及所述文件对应的文件描述信息，并 将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端侧；
在接收到终端侧发送的文件源符号重传请求后，重新获取请求的所述文件的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端侧。
本申请公开了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现以下步骤：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器侧发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器侧发送文件源符号重传请求，直至解码得到整个文件。
本申请公开了一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如上所述的用于服务器侧的文件传输方法的步骤或用于终端侧的文件传输方法的步骤。
本申请提供的基于融合传输系统的文件传输方法，在终端侧对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器侧将请求的文件源符号封装为文件源符号重传响应发送至终端侧，以实现终端侧对文件 的全部解码，从而保证文件传输的可靠性。
并且，本申请的方法可以准确地查找到需求重传的文件源符号，从而避免文件的已接收部分的重复接收，节省了网络链路资源。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1是本申请实施例的融合传输系统的结构示意图；
图2是本申请实施例的用于服务器侧的基于融合传输系统的协议栈的结构示意图；
图3是本申请实施例的用于终端侧的基于融合传输系统的协议栈的结构示意图；
图4是本申请实施例的融合传输流的结构示意图；
图5是本申请实施例的融合传输块的结构示意图；
图6是本申请实施例的文件编码符号标识的结构示意图；
图7是本申请实施例的每个融合传输流在下一代广播电视无线NGB-W/S信道中的映射过程示意图；
图8是本申请实施例的每个融合传输流在数字卫星广播系统DVB-S信道中的映射过程以及TS包结构示意图；
图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 convergence 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通过广播通道108发送给所有终端110；另一种是将数据保存于互联网服务器或提交给内容分发网络(Content Delivery Network，CDN)104上的缓存服务器，并提供统一资源描述符(Uniform Resource Identifier，URI)，终端110可主动通过移动通信网107经由网络通道109来访问融合传输流数据。
卫星广播网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  Transport Block，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开始，当达到最大值2 32－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 Description Information,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 PCTCN2019071618-appb-000001
9012、按照设定的时间间隔，将最新生成的业务描述信息封装为第二融合传输块。
业务描述信息作为一种控制消息，将和其他控制消息一起，封装到一个融合传输块或块序号连续的多个融合传输块中。当最后一个融合传输块在封装完业务描述信息后还有剩余空间，可以填充字节0xFF。
第二融合传输块的结构包括：第二融合传输块的块头、第二融合传输块的块净荷和校验码；第二融合传输块的块净荷包括：消息头指示字段和业务描述信息字段。
图18中给出了一个业务描述信息封装到两个连续的融合传输块中的情况。业务描述信息的结构参见前述内容，在此便不再赘述。
当融合传输块传送包括业务描述信息在内的控制消息时，块头中的业务类型为3，块净荷的头两个字节为消息头指示(Head Indicator，HI)字段，其定义如下：
消息头指示字段(HI)——16位比特，指示该块净荷中出现的第一个控制消息头的位置。
该值为0时表示业务描述信息头的起始位置为HI字段后的第一个字节，该值为1则表示业务描述信息头的起始位置为HI字段后的第二个字节，依此类推；当该净荷中无任何业务描述信息头时，该字段指示的是填充字节0xFF的起始位置；如果该净荷中既无任何业务描述信息头又无任何填充，也即该净荷为一个业务描述信息的中间部分，则该字段值为0xFFFF。
9013、将所述第二融合传输块和所述第一融合传输块封装至同一个融合传输流发送至终端侧。
参见图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组编码符号(Encoding Symbol，ES)，包括CRC32。
融合传输流标识——12位比特，指示融合传输流的标识，即CTS_ID。
重传请求编号——8位比特，指示重传请求的编号，即REQ_SEQ。
业务流内编号——8位比特，指定业流内务编号，和融合传输流标识一起标识了补发文件所在的业务。
业务内文件标识——20位比特，指示文件在业务内的标识，和融合传输流标识、流内业务编号一起组成了文件的全局文件标识，标识了补发的编码符号所属的文件。
请求的源符号总数——8位比特，指示本次补发请求中的源符号的总数。
请求的源符号组数——8位比特，指示本次请求补发的源符号组的数目M，该值决定了后续的源符号组参数的个数。
第一组源符号——48位比特，指示需要重传的第一组编码符号，由16位的源块号(SBN)、16位的ESI和16位的ES个数组成。
第二组源符号、……第M组源符号——均为48位比特，其存在由请求重传的ES组数来决定，由16位的SBN、16位的ESI和16位的ES个数组成。
校验码(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前缀、端口号、具体目录和请求参数；请求参数包括：融合传输流标识、重传请求编号、流内业务编号、业务内文件标识和请求的源符号列表。
HTTP文件源符号重传响应HTTP_CTB_RESP包括：响应头和响应主体；
所述响应头包括：响应主体类型、响应主体长度和响应主体摘要；
参见图24，所述响应主体包括：融合传输流协议版本、融合传输流标识、重传请求编号、每个第一融合传输块的长度、需要重传的第一融合传输块的数量和至少一个请求的第一融合传输块。
各字段含义如下：
响应主体类型——需设置为“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动作，直至解码得到整个文件。
可选地，除去上述模块外，本申请的文件传输装置还包括：
业务描述信息请求模块，用于发送业务描述信息主动请求至服务器侧，并接收服务器侧发送的封装有业务描述信息的业务描述信息重传响应。
关于业务描述信息主动请求和业务描述信息重传响应的报文具体格式和字段定义，在前述实施例中已经详细介绍，在此便不再赘述。
本申请提供的基于融合传输系统的文件传输装置，在终端侧对文件的文件编码符号解码失败后，发送文件源符号重传请求至服务器侧，服务器侧将请求的文件源符号封装为文件源符号重传响应发送至终端侧，以实现终端侧对文件的全部解码，从而保证文件传输的可靠性。
上述为本实施例的文件传输的装置的示意性方案。需要说明的是，该文件传输的装置的技术方案与上述的文件传输的方法的技术方案属于同一构思，文件传输的装置的技术方案未详细描述的细节内容，均可以参见上述文件传输的方法的技术方案的描述。
本申请一实施例公开了一种计算设备，所述计算设备能够实现文件传输方法。该计算设备的部件包括但不限于存储器和处理器，处理器与存储器相连接。
应该知道，计算设备还可以包括网络接口，网络接口使得计算设备能够经由一个或多个网络通信。这些网络的示例包括局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。网络接口可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。计算设备可以通过网络接口访问页面。
在本申请的一个实施例中，计算设备的上述中未示出的其他部件也可以彼此相连接，例如通过总线。
计算设备可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备还可以是移动式或静止式的服务器。
其中，处理器执行所述程序时实现以下步骤：
获取待推送的文件的文件编码符号以及所述文件对应的文件描述信息，并将所述文件描述信息以及待推送的所述文件的文件编码符号封装为融合传输流发送至终端侧；
在接收到终端侧发送的文件源符号重传请求后，重新获取请求的所述文件 的文件源符号，将所述文件的文件源符号封装为文件源符号重传响应发送至终端侧。
另一实施例中，所述处理器执行所述程序时还可以实现以下步骤：
接收融合传输流中的文件描述信息；
根据所述文件描述信息接收融合传输流中的对应的文件编码符号；
对接收到的所述文件的文件编码符号进行解码，在确定对整个文件解码失败后，向服务器侧发送文件源符号重传请求；
对接收到封装有所述文件的文件源符号的文件源符号重传响应进行解析，得到所述文件的文件源符号；
根据所述文件源符号进行解码，在确定对整个文件解码失败后，继续向服务器侧发送文件源符号重传请求，直至解码得到整个文件。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如前所述用于服务器侧的基于融合传输系统的文件传输方法的步骤。
本申请一实施例还提供一种计算机可读存储介质，其存储有计算机程序，该程序被处理器执行时实现如前所述用于终端侧的基于融合传输系统的文件传输方法的步骤。
上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的文件传输方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述文件传输方法的技术方案的描述。
所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。
需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。
以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (21)

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

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
WO2019149054A1 true WO2019149054A1 (zh) 2019-08-08

Family

ID=67442391

Family Applications (1)

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

Country Status (2)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112866294A (zh) * 2021-03-15 2021-05-28 中国电子科技集团公司第十五研究所 一种多协议适配方法、装置及可读存储介质
CN113392055A (zh) * 2020-03-13 2021-09-14 北京小米移动软件有限公司 文件传输方法、文件传输装置及存储介质
CN114793183A (zh) * 2022-06-22 2022-07-26 山东致群信息技术股份有限公司 一种基于多源数据处理的分布式融合通讯方法
CN116248778A (zh) * 2023-05-15 2023-06-09 珠海迈科智能科技股份有限公司 一种多协议环境下的数据融合传输方法及系统

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112788078B (zh) * 2019-11-07 2023-03-24 上海哔哩哔哩科技有限公司 数据传输方法、接收装置、发送装置和计算机设备
CN112565815B (zh) * 2020-10-16 2022-05-24 腾讯科技（深圳）有限公司 文件封装方法、文件传输方法、文件解码方法及相关设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
CN105432089A (zh) * 2013-09-10 2016-03-23 华为技术有限公司 一种蜂窝广播融合的预推送方法、设备及系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101465791B (zh) * 2007-12-18 2011-08-17 国家广播电影电视总局广播科学研究院 一种基于单向链路的文件传输方法
WO2015027429A1 (zh) * 2013-08-29 2015-03-05 华为技术有限公司 聚合传输的方法、装置和系统以及网络服务器和用户设备
EP3127333A1 (en) * 2014-03-31 2017-02-08 British Telecommunications Public Limited Company Multicast streaming

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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 华为技术有限公司 媒体流发送及接收方法、装置和系统
CN105432089A (zh) * 2013-09-10 2016-03-23 华为技术有限公司 一种蜂窝广播融合的预推送方法、设备及系统

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113392055A (zh) * 2020-03-13 2021-09-14 北京小米移动软件有限公司 文件传输方法、文件传输装置及存储介质
CN113392055B (zh) * 2020-03-13 2024-01-30 北京小米移动软件有限公司 文件传输方法、文件传输装置及存储介质
CN112866294A (zh) * 2021-03-15 2021-05-28 中国电子科技集团公司第十五研究所 一种多协议适配方法、装置及可读存储介质
CN112866294B (zh) * 2021-03-15 2023-03-31 中国电子科技集团公司第十五研究所 一种多协议适配方法、装置及可读存储介质
CN114793183A (zh) * 2022-06-22 2022-07-26 山东致群信息技术股份有限公司 一种基于多源数据处理的分布式融合通讯方法
CN114793183B (zh) * 2022-06-22 2022-09-09 山东致群信息技术股份有限公司 一种基于多源数据处理的分布式融合通讯方法
CN116248778A (zh) * 2023-05-15 2023-06-09 珠海迈科智能科技股份有限公司 一种多协议环境下的数据融合传输方法及系统
CN116248778B (zh) * 2023-05-15 2023-08-11 珠海迈科智能科技股份有限公司 一种多协议环境下的数据融合传输方法及系统

Also Published As

Publication number Publication date
CN110099087A (zh) 2019-08-06
CN110099087B (zh) 2021-02-02

Similar Documents

Publication Publication Date Title
WO2019149054A1 (zh) 一种基于融合传输系统的文件传输方法
JP6648211B2 (ja) マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置
US9350488B2 (en) Content delivery system with allocation of source data and repair data among HTTP servers
CN107196941B (zh) 用于传送和接收媒体数据的接口装置和方法
RU2369040C2 (ru) Буферизация при потоковой передаче данных
US9414123B2 (en) Method for hybrid delivery of MMT package and content and method for receiving content
US10615907B2 (en) Rate adaptation method using bit error rate for multimedia service and apparatus therefor
WO2019149053A1 (zh) 一种基于融合传输系统的数据传输方法
JP4242419B2 (ja) サービスインフォメーションにおけるタイムスライシングパラメーター信号伝達方法
US9894421B2 (en) Systems and methods for data representation and transportation
US10498788B2 (en) Method and apparatus for transceiving data packet for transmitting and receiving multimedia data
US20150249835A1 (en) Method for adaptively transmitting fec parity data using cross-layer optimization
CN101729887B (zh) 一种数字广播系统的数据传输方法及装置
CN110098899B (zh) 一种基于融合传输系统的协议栈、数据重传的方法
CN108882054B (zh) 用于stl-sfn传输过程的数据报头结构及封装方法
Belda et al. Multimedia system for emergency services over tetra-dvbt networks
KR102421791B1 (ko) Mmt 네트워크 시스템에서 미디어 시간 정보를 전송 하는 방법 및 장치
KR20190139815A (ko) 데이터 패킷을 수신하는 방법 및 장치
KR20170050697A (ko) Mmt 패킷 구성 장치 및 mmt 패킷 구성 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19747700

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 18/11/2020)

122 Ep: pct application non-entry in european phase

Ref document number: 19747700

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 520412610

Country of ref document: SA