CN111373759B - 广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法 - Google Patents

广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法 Download PDF

Info

Publication number
CN111373759B
CN111373759B CN201880072268.2A CN201880072268A CN111373759B CN 111373759 B CN111373759 B CN 111373759B CN 201880072268 A CN201880072268 A CN 201880072268A CN 111373759 B CN111373759 B CN 111373759B
Authority
CN
China
Prior art keywords
packet
packets
information
rdt
link layer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201880072268.2A
Other languages
English (en)
Other versions
CN111373759A (zh
Inventor
权祐奭
尹准熙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
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 LG Electronics Inc filed Critical LG Electronics Inc
Publication of CN111373759A publication Critical patent/CN111373759A/zh
Application granted granted Critical
Publication of CN111373759B publication Critical patent/CN111373759B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2381—Adapting the multiplex stream to a specific network, e.g. an Internet Protocol [IP] network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4343—Extraction or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving MPEG packets from an IP network
    • H04N21/4381—Recovering the multiplex stream from a specific network, e.g. recovering MPEG packets from ATM cells
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/812—Monomedia components thereof involving advertisement data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/835—Generation of protective data, e.g. certificates
    • H04N21/8358—Generation of protective data, e.g. certificates involving watermark
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/18—Loop-free operations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]

Abstract

根据本公开的一个实施例的广播传输方法包括：互联网协议(IP)层处理步骤，生成包括广播数据的IP分组，对IP分组中的至少一个IP分组进行分段来生成多个分段的IP分组，并且将其发送到链路层；第一链路层处理步骤，组合在IP层处理步骤处输出的IP分组当中的分段的IP分组，以便于将其重组成至少一个IP分组；第二链路层处理步骤，执行包括被重组的至少一个IP分组的IP分组的报头压缩；以及第三链路层处理步骤，将其报头已被压缩的IP分组封装成至少一个链路层分组并将其发送到物理层。

Description

广播信号传输设备、广播信号传输方法、广播信号接收设备及 广播信号接收方法
技术领域
本公开涉及广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法，并且更具体地，涉及用于在链路层中处理数据的广播信号传输/接收设备和方法。
背景技术
随着模拟广播信号传输的终止，已经开发用于发送和接收数字广播信号的各种技术。数字广播信号比模拟广播信号能够包含更多量的视频/音频数据，并且还包含各种类型的附加数据以及视频/音频数据。
也就是说，数字广播系统可以提供高清晰度(HD)图像、多通道音频和各种其他服务。然而，对于数字广播，需要考虑到用于大量数据传输的数据传输效率、收发网络的鲁棒性以及移动接收设备来增强网络灵活性。
发明内容
技术问题
本公开的目的是提供一种广播信号传输设备、广播信号传输方法、广播信号接收设备和广播信号接收方法，旨在有效地压缩和解压缩分组报头用于大量的数据传输和开销减少。
本公开的另一个目的是提供广播信号传输设备、广播信号传输方法、广播信号接收设备以及广播信号接收方法，旨在有效地压缩和解压缩因特网协议(IP)分组的报头。
本公开的另一目的是提供广播信号传输设备、广播信号传输方法、广播信号接收设备和广播信号接收方法，旨在在链路层中有效地处理数据。
技术方案
根据本公开的一个实施例的广播信号传输方法包括：互联网协议(IP)层处理步骤，该IP层处理步骤生成包括广播数据的IP分组，并且通过对IP分组中的至少一个IP分组进行分段来生成分段的IP分组以便于发送到链路层；第一链路层处理步骤，该第一链路层处理步骤通过组合在IP层处理步骤处输出的IP分组中的分段的IP分组来恢复至少一个IP分组；第二链路层处理步骤，该第二链路层处理步骤执行包括恢复的至少一个IP分组的IP分组的报头压缩；以及第三链路层处理步骤，该第三链路层处理步骤将报头压缩的IP分组封装到至少一个链路层分组中，并且将至少一个链路层分组发送到物理层。
在一个实施例中，IP层处理步骤包括：如果至少一个IP分组的长度长于最大传输单元(MTU)则将至少一个IP分组分割成分段，并且通过向每个分段添加IP报头来生成经分段的IP分组。
在一个实施例中，第一链路层处理步骤包括：收集分段的IP分组，并且通过基于被输入的IP分组的IP报头内的不分段(DF)标志、更多分段(MF)标志、标识字段、以及分段偏移字段来组合所收集的分段的IP分组来恢复至少一个IP分组。
在一个实施例中，第二链路层处理步骤包括：通过对被输入的IP分组应用稳健的报头压缩(RoHC)方案执行报头压缩，来生成RoHC分组流。
在一个实施例中，第二链路层处理步骤包括：从RoHC分组流中提取上下文信息，并且通过RoHC-U描述表(RDT)来发送所提取的上下文信息以及与报头压缩有关的信息。
根据本公开的一个实施例的广播信号传输设备包括：演播室，该演播室用于生成包括广播数据的互联网协议(IP)分组，并且通过对IP分组中的至少一个IP分组进行分段来生成分段的IP分组以便于发送到链路层；链路层的广播网关，该链路层的广播网关用于通过组合从演播室输出的IP分组中的分段的IP分组来恢复至少一个IP分组，执行包括恢复的至少一个IP分组的IP分组的报头压缩，将报头压缩的IP分组封装到至少一个链路层分组中，并且然后将至少一个链路层分组发送到物理层；以及发射器，该发射器用于通过物理层处理来发送从广播网关发送的至少一个链路层分组。
有益效果
根据本公开，可以简化IP报头压缩过程以降低广播系统的复杂性。
根据本公开，在传输到接收系统之前，可以禁止应用于传输系统的IP分段过程，从而可以简化接收系统的实现。
根据本公开，可以有效地增强IP报头压缩的带宽减少。
附图说明
附图被包括以提供对本公开的进一步理解并且被并入且构成本申请的一部分，附图图示本公开的实施例，并且与描述一起用作解释本公开的原理。在附图中：
图1是示出根据本公开的实施例的协议栈的图；
图2是示出根据本公开的实施例的服务发现过程的图；
图3是示出根据本公开的实施例的低等级信令(LLS)表和服务列表表(SLT)的图；
图4是示出根据本公开的实施例的通过ROUTE递送的USBD和S-TSID的图；
图5是示出根据本公开的实施例的通过MMT递送的USBD的图；
图6是示出根据本公开的实施例的链路层协议架构的图；
图7是示出根据本公开的实施例的链路层操作的图；
图8(a)和8(b)是示出根据本公开的实施例的IP报头压缩中的自适应模式2和3的示例的图；
图9是示出根据本公开的实施例的链路层分组的基本报头的结构的图；
图10是示出被指配给图9的packet_type字段的代码值的含义的实施例的图；
图11是图示根据本公开的另一实施例的用于链路层分组的信令信息的附加报头结构的图；
图12是图示用于图11的信令信息的附加报头的语法结构的一个实施例的图；
图13是图示根据本公开的LMT的语法结构的一个实施例的图；
图14是图示根据本公开的RDT的语法结构的一个实施例的图；
图15是图示根据本公开的广播传输设备的一个实施例的框图；
图16是图示图15的输入格式化块的一个实施例的详细框图；
图17是图示根据本公开的混合广播信号接收设备的一个实施例的框图；
图18是图示根据本公开的物理层的广播信号接收设备的一个实施例的框图；
图19是图示根据本公开的IP分组的IP报头结构的一个实施例的图；
图20(a)至20(d)是图示根据本公开的在IP/UDP层中生成的IP分组的一个实施例的图；
图21(a)至21(d)是图示应用于图20(a)至20(d)的IP分组的报头压缩和链路层分组封装的一个实施例的图；
图22是图示根据本公开的广播系统的一个实施例的框图；
图23(a)至图23(d)是图示根据本公开的在IP/UDP层中生成的IP分组的一个实施例的图；
图24(a)、图24(b1)至图24(b3)、图24(c)和图24(d)是图示应用于图23(a)至图23(d)的一些IP分组的分段的一个实施例的图；
图25(a)、图25(b1)至图25(b3)、图25(c)和图25(d)是图示应用于图24(a)、图24(b1)至图24(b3)、图24(c)和图24(d)的IP分组的报头压缩和链路层分组封装的一个实施例的图；
图26是图示根据本公开的广播系统的另一实施例的图；
图27是图示图26的广播系统的广播网络结构的一个实施例的框图；
图28(a)至图28(d)是图示根据本公开的在IP/UDP层中生成的IP分组的一个实施例的图；
图29(a)、图29(b1)至图29(b3)、图29(c)和图29(d)是图示应用于图28(a)至图28(d)的一些IP分组的分段的一个实施例的图；
图30(a)至图30(d)是图示应用于图29(a)、图29(b1)至图29(b3)、图29(c)和图29(d)的IP分组的预处理的一个实施例的图；
图31(a)至图31(d)是图示应用于图30(a)至图30(d)的IP分组的报头压缩和链路层分组封装的一个实施例的图；
图32是图示根据本公开的一个实施例的包括预处理器的广播网关的操作的流程图；
图33(a)至图33(d)是图示根据本公开的由接收器接收的ALP分组的一个实施例的图；
图34(a)至图34(d)是图示通过将解封装和报头压缩应用于图33(a)至图33(d)的ALP分组而获得的IP分组的一个实施例的图；
图35(a)、图35(b1)至图35(b3)、图35(c)和图35(d)是图示应用于图34(a)至图34(d)的一些IP分组的分段的一个实施例的图；
图36(a)至图36(d)是图示本公开的一个实施例的图，其中，在图35(a)、图35(b1)至图35(b3)、图35(c)和图35(d)中应用分段的IP分组被恢复成原始IP分组；
图37是图示根据本公开的用于信令信息的附加报头的语法结构的一个实施例的图；
图38是图示根据本公开的用于信令信息的附加报头的语法结构的另一实施例的图；
图39是图示根据本公开的RDT的语法结构的另一实施例的图；
图40是图示根据本公开的RDT的语法结构的另一实施例的图；以及
图41是图示分配给图40的RDT_type字段的代码值的含义的一个实施例的图。
优选实施方式
现在将参考附图详细地参考本公开的优选实施例。下面将参考附图给出的详细描述旨在解释本公开的示例性实施例，而不是示出仅可以根据本公开实现的实施例。
虽然在本说明书中使用的术语考虑到它们在本说明书中的功能选自一般公知和使用的术语，但是取决于本领域中的技术人员的意图、实践或者新技术的出现可以修改术语。而且，在具体情况下，在本说明书的描述中所提及的术语可以是通过申请人随意选择的，其详细意义在本文描述的有关部分中被描述。因此，不应通过实际使用的术语简单地理解在此使用的术语，而是通过其中的意义和在此公开的描述来理解。
在本说明书中公开的实施例中的特定结构或功能描述旨在描述实施例，并且可以以各种形式实施实施例，并且不应理解本公开的范围受到本说明书中所描述的实施例的限制。
因为可以以其他特定方式来执行根据本说明书的实施例并且可以对实施例进行各种修改，所以将在附图中图示特定实施例，并且将在本说明书中对其进行详细描述。然而，这并不旨在将根据本说明书的实施例限制为特定的公开的类型，并且要理解，根据本说明书的实施例包括在本说明书的精神和技术范围内包括的所有改变、等效物或替换。
尽管本说明书中的诸如“第一”和/或“第二”的术语可以用于描述各种元素，但是要理解，这些元素不受这些术语的限制。这些术语可以用来识别一个元素与另一元素。例如，在不脱离本说明书的范围的范围内，第一元素可以被称为第二元素，反之亦然。
在说明书中，当部件“包含”或“包括”元素时，这意指该部件还包含或包括另一个元素，除非另有说明。另外，说明书中公开的术语“……模块(或单元)”意指用于处理至少一个功能或操作的单元，并且可以由硬件、软件或硬件和软件的组合来实现。
在本说明书中，“信令”指示从广播系统、因特网广播系统和/或因特网组合系统提供的服务信息(SI)被发送/接收。服务信息包括从当前存在的每个广播系统提供的广播服务信息(例如，ATSC-SI和/或DVB-SI)。
在本说明书中，除了地面广播、有线广播、卫星广播和/或移动广播以外，“广播信号”被定义为还包括从诸如互联网广播、宽带广播、通信广播、数据广播和/或视频点播(VOD)的双向广播中提供的信号和/或数据。
在本说明书中，“物理层通道(PLP)”意指发送属于物理层的数据的特定单元。因此，本说明书中的PLP可以被称为“数据信元”或“数据通道”。
作为要用于数字广播(DTV)服务的强大应用之一，可能存在通过广播网络和互联网网络之间的交互的混合广播服务。混合广播服务可以通过经由互联网网络(或宽带)广播实时地发送与通过地面广播网络发送的广播音频/视频(A/V)内容相关联的增强数据或一些广播A/V内容来允许用户实时体验各种内容。
本公开旨在提供能够发送和接收用于高级广播服务的广播信号的广播传输设备、广播信号接收设备、广播传输方法和广播接收方法。根据本公开的一个实施例的高级广播服务包括地面广播服务、移动广播服务和超高清电视(UHDTV)服务。
在本公开的一个实施例中，用于高级广播服务的广播信号以非MIMO(多输入多输出)方案或MIMO方案被处理。根据本公开的一个实施例的非MIMO方案可以包括多输入单输出(MISO)方案、单输入单输出(SISO)方案等。在下文中，例如，尽管可以基于两个天线来描述MISO或MIMO的多个天线，但是本公开的描述可以应用于使用两个或更多个天线的系统。
此外，在本公开中，信号帧(或帧或A3帧或物理层帧)被划分为三个区域，并且位于信号帧的前面的第一区域被称为引导(或引导区域)，位于第一区域之后的第二区域被称为前导(或前导区域)，并且位于第二区域之后的第三区域被称为数据区域。
引导区域包括数据，并且前导区域包括适用于此帧中的其他的L1(层1)信令数据(或L1控制信令数据)。数据区域被划分成一个或多个子帧。如果一个信号帧中存在多个子帧，则多个子帧在时间上被级联在一起。一个子帧在信号帧中包括时频资源的集合。即，发送到一个或多个PLP的数据被映射到一个或多个子帧中。
L1信令数据提供配置物理层参数所需的信息。L1信令数据包括L1基本信令数据和L1详细信令数据。此时，引导数据可以被包括在L1信令数据中。
在一个实施例中，在稍后将描述的L1信令数据中包括的信息中，以L1B开始的信息是被包括在L1基本信令数据中的信息，并且以L1D开始的信息是被包括在L1详细信令数据中的信息。
L1基本信令数据可以对应于物理层信令1(PLS1)数据，并且L1详细信令数据可以对应于PLS2数据。
图1是示出根据本公开的实施例的协议栈的图。
服务可以经由多个层递送给接收器。首先，传输侧可以生成服务数据。服务数据可以在传输侧的递送层上被处理以用于传输，并且服务数据可以在物理层处被编码为广播信号并通过广播或者宽带网络发送。
在这里，服务数据可以以ISO基础媒体文件格式(BMFF)生成。ISO BMFF媒体文件可以被用于广播/宽带网络递送、媒体封装和/或同步格式。在这里，服务数据是与服务相关的所有数据，并且可以包括配置线性服务的服务组件、其信令信息、非实时(NRT)数据和其他文件。
将描述递送层。递送层可以提供用于发送服务数据的功能。服务数据可以通过广播和/或宽带网络被递送。
广播服务递送可以包括两种方法。
作为第一种方法，服务数据可以基于MPEG媒体传输(MMT)以媒体处理单元(MPU)被处理，并且使用MMT协议(MMTP)被发送。在这种情况下，使用MMTP递送的服务数据可以包括用于线性服务的服务组件和/或其服务信令信息。
作为第二种方法，服务数据可以基于MPEG DASH，被处理为DASH分片(segment)，并且使用通过单向传输的实时对象递送(ROUTE)来发送。在这种情况下，经由ROUTE协议递送的服务数据可以包括用于线性服务的服务组件、其服务信令信息和/或NRT数据。也就是说，NRT数据和非定时的数据，诸如文件，可以通过ROUTE被递送。
根据MMTP或者ROUTE协议处理的数据可以通过数据报协议/互联网协议(UDP/IP)层被处理为IP分组。换句话说，在UDP/IP层中，通过将UDP报头添加到包括根据MMTP或ROUTE协议处理的数据的UDP有效载荷中来构成UDP分组，并且通过将IP报头添加到UDP分组来构成IP/UDP分组。在本公开中，为了便于描述，将IP/UDP分组称为IP分组。在通过广播网络的服务数据递送中，服务列表表(SLT)也可以通过UDP/IP层在广播网络上被递送。SLT可以在低等级信令(LLS)表中被递送。稍后将描述SLT和LLS表。
IP分组可以在链路层中被处理为链路层分组。链路层可以将从上层(较高层)递送的各种格式的数据封装到链路层分组中，并且然后将该分组递送给物理层。稍后将详细描述链路层。
在混合服务递送中，至少一个服务元素可以通过宽带路径被递送。在混合服务递送中，通过宽带递送的数据可以包括DASH格式的服务组件、其服务信令信息和/或NRT数据。此数据可以通过HTTP/TCP/IP被处理，并且通过用于宽带传输的链路层被递送给用于宽带传输的物理层。
物理层可以处理从递送层(上层和/或链路层)接收的数据，并且通过广播或者宽带网络发送该数据。稍后将给出物理层的详细描述。
将描述服务。服务可以是显示给用户的服务组件的集合，组件可以具有各种媒体类型，服务可以是连续或者间断的，服务可以是实时或者非实时的，并且实时服务可以包括TV节目的序列。
服务可以具有各种类型。第一，服务可以是具有基于应用(app)的增强的线性音频/视频或者音频服务。第二，服务可以是基于app的服务，其再现/配置由下载的应用来控制。第三，服务可以是用于提供电子服务指南(ESG)的ESG服务。第四，服务可以是用于提供紧急警报信息的紧急警报(EA)服务。
当不具有基于app的增强的线性服务通过广播网络被递送时，服务组件可以由(1)一个或多个ROUTE会话，或者(2)一个或多个MMTP会话被递送。
当具有基于app的增强的线性服务通过广播网络被递送时，服务组件可以由(1)一个或多个ROUTE会话以及(2)零或零个以上MMTP会话被递送。在这种情况下，用于基于app的增强的数据可以以NRT数据或者其他文件的形式通过ROUTE会话被递送。在本发明的一个实施例中，使用两个协议的一个服务的线性服务组件(流媒体组件)的同时的递送可能是不被允许的。
当基于app的服务通过广播网络被递送时，服务组件可以由一个或多个ROUTE会话被递送。在这种情况下，用于基于app的服务的服务数据可以以NRT数据或者其他文件的形式通过ROUTE会话被递送。
这样的服务的一些服务组件、一些NRT数据、文件等等可以通过宽带被递送(混合服务递送)。
也就是说，在本公开的一个实施例中，一个服务的线性服务组件可以通过MMT协议被递送。在本公开的另一个实施例中，一个服务的线性服务组件可以通过ROUTE协议被递送。在本公开的另一个实施例中，一个服务的线性服务组件和NRT数据(NRT服务组件)可以通过ROUTE协议被递送。在本公开的另一个实施例中，一个服务的线性服务组件可以通过MMT协议被递送，并且NRT数据(NRT服务组件)可以通过ROUTE协议被递送。在以上描述的实施例中，服务的某些服务组件或者某些NRT数据可以通过宽带被递送。在这里，基于app的服务和关于基于app的增强的数据可以以NRT数据的形式通过根据ROUTE的广播网络，或者通过宽带被递送。NRT数据可以被称为本地缓存的数据。
每个ROUTE会话包括用于完整地或者部分地递送配置该服务的内容组件的一个或多个LCT会话。在流服务递送中，LCT会话可以递送用户服务的个别的组件，诸如音频、视频或者闭合字幕流(closed caption stream)。流媒体被格式化为DASH分片。
每个MMTP会话包括用于递送所有或者一些内容组件或者MMT信令消息的一个或多个MMTP分组流。MMTP分组流可以递送已格式化为MPU的组件或者MMT信令消息。
对于NRT用户服务或者系统元数据的递送，LCT会话递送基于文件的内容项目。这样的内容文件可以包括NRT服务的连续的(定时的)或者离散的(非定时的)媒体组件或者元数据，诸如服务信令或者ESG分段。系统元数据(诸如服务信令或者ESG分段)可以通过MMTP的信令消息模式被递送。
当调谐器调谐到频率时，接收器可以检测广播信号。接收器可以提取和发送SLT给处理模块(即，SLT解析器)。SLT解析器可以解析SLT，并且获取数据并且基于获取的数据生成或者更新信道映射图(channel map)。接收器可以获取并将SLT的引导信息(bootstrapinformation)递送给ROUTE或者MMT客户端。接收器可以获取和存储SLS。USBD可以被获取并由信令解析器解析。
图2是示出根据本公开的一个实施例的服务发现过程的图。
由物理层的广播信号帧递送的广播流可以承载低等级信令(LLS)。LLS数据可以通过被递送给公知的IP地址/端口的IP分组的有效载荷被承载。此LLS可以根据其类型包括SLT。LLS数据可以以LLS表的形式被格式化。承载LLS数据的每个UDP/IP分组的第一字节可以是LLS表的开始。与示出的实施例不同，用于递送LLS数据的IP流可以与其他的服务数据一起被递送给相同的PLP。
SLT可以通过快速信道扫描使接收器能够生成服务列表，并且提供用于定位SLS的接入信息。SLT包括引导信息。此引导信息可以使接收器能够获取每个服务的服务层信令(SLS)。当SLS，也就是说，服务信令信息通过ROUTE被递送时，引导信息可以包括承载SLS的LCT信道、包括LCT信道的ROUTE会话的目的地IP地址和目的地端口信息。当通过MMT递送SLS时，引导信息可以包括承载SLS的MMTP会话的目的地IP地址和目的地端口信息。
在示出的实施例中，在SLT中描述的服务#1的SLS通过ROUTE被递送，并且SLT可以包括包含由SLS递送的LCT信道的ROUTE会话的引导信息sIP1、dIP1和dPort1。在SLT中描述的服务#2的SLS通过MMT被递送，并且SLT可以包括包含由SLS递送的MMTP分组流的MMTP会话的引导信息sIP2、dIP2和dPort2。
SLS是描述服务的特性的信令信息，并且可以包括用于显著地再现服务或者用于提供用于获取服务和该服务的服务组件的信息的接收器能力信息。当每个服务具有单独的服务信令时，在无需解析在广播流内递送的所有SLS的情况下，接收器获取用于所期望的服务的合适的SLS。
当SLS通过ROUTE协议被递送时，SLS可以通过由SLT指示的ROUTE会话的专用的LCT信道被递送。在一些实施例中，此LCT信道可以是通过tsi＝0识别的LCT信道。在这种情况下，SLS可以包括用户服务捆绑描述(USBD)/用户服务描述(USD)、基于服务的传输会话实例描述(S-TSID)和/或媒体呈现描述(MPD)。
在这里，USBD/USD是SLS分段中的一个，并且可以用作描述服务的详细描述信息的信令中心(signaling hub)。USBD可以包括服务标识信息、设备能力信息等等。USBD可以包括其它的SLS分段(S-TSID、MPD等等)的参考信息(URI参考)。也就是说，USBD/USD可以参考S-TSID和MPD。此外，USBD可以进一步包括用于使接收器能够决定传输模式(广播/宽带网络)的元数据信息。USBD/USD的详细描述将在下面被给出。
S-TSID是SLS分段中的一个，并且可以提供承载服务的服务组件的传输会话的整个会话描述信息。S-TSID可以提供通过其递送服务的服务组件的ROUTE会话和/或用于ROUTE会话的LCT信道的传输会话描述信息。S-TSID可以提供与一个服务相关联的服务组件的组件获取信息。S-TSID可以提供MPD的DASH表示(representation)和服务组件的tsi之间的映射。S-TSID的组件获取信息可以以相关联的DASH表示和tsi的标识符的形式提供，并且在一些实施例中可以包括或者可以不包括PLP ID。通过该组件获取信息，接收器可以收集一个服务的音频/视频组件，并且执行DASH媒体分片的缓存和解码。S-TSID可以如上所述由USBD参考。S-TSID的详细描述将在下面给出。
MPD是SLS分段中的一个，并且可以提供服务的DASH媒体呈现的描述。MPD可以提供媒体分片的资源标识符，并且在被识别的资源的媒体呈现内提供上下文信息。MPD可以描述通过广播网络递送的DASH表示(服务组件)，并且描述通过宽带递送(混合递送)的额外的DASH表示。MPD可以如上所述由USBD参考。
当通过MMT协议递送SLS时，可以通过由SLT指示的MMTP会话的专用的MMTP分组流来递送SLS。在一些实施例中，递送SLS的MMTP分组的packet_id可以具有00的值。在这种情况下，SLS可以包括USBD/USD和/或MMT分组(MP)表。
在这里，USBD是SLS分段中的一个，并且可以如在ROUTE中一样描述服务的详细描述信息。此USBD可以包括其它的SLS分段的参考信息(URI信息)。MMT的USBD可以参考MMT信令的MP表。在一些实施例中，MMT的USBD可以包括S-TSID和/或MPD的参考信息。在这里，S-TSID用于通过ROUTE协议递送的NRT数据。即使当线性服务组件经由MMT协议被递送时，NRT数据也可以经由ROUTE协议被递送。MPD用于在混合服务递送中通过宽带递送的服务组件。MMT的USBD的详细描述将在下面给出。
MP表是用于MPU组件的MMT的信令消息，并且可以提供承载服务的服务组件的MMTP会话的整个会话描述信息。此外，MP表可以包括通过MMTP会话递送的资产(asset)的描述。MP表是用于MPU组件的流信令信息，并且可以提供对应于一个服务的资产列表和这些组件的位置信息(组件获取信息)。MP表的详细描述可以在MMT中被定义或者修改。在这里，资产是多媒体数据实体，通过一个唯一的ID合并，并且可以意指用于一个多媒体呈现的数据实体。资产可以对应于配置一个服务的服务组件。可以使用MP表来访问对应于所期望的服务的流服务组件(MPU)。MP表可以通过如上所述的USBD参考。
其它的MMT信令消息可以被定义。与服务和MMTP会话相关联的附加信息可以由这样的MMT信令消息描述。
ROUTE会话通过源IP地址、目的地IP地址和目的地端口号识别。LCT会话通过在父ROUTE会话范围内唯一的传输会话标识符(TSI)识别。MMTP会话通过目的地IP地址和目的地端口号识别。MMTP分组流通过在父MMTP会话范围内唯一的packet_id识别。
在ROUTE的情况下，S-TSID、USBD/USD、MPD或者递送其的LCT会话可以被称为服务信令信道。在MMTP的情况下，USBD/USD、MMT信令消息或者递送其的分组流可以被称为服务信令信道。
与示出的实施例不同，一个ROUTE或者MMTP会话可以通过多个PLP被递送。也就是说，一个服务可以通过一个或多个PLP被递送。与示出的实施例不同，在一些实施例中，配置一个服务的组件可以通过不同的ROUTE会话被递送。此外，在一些实施例中，配置一个服务的组件可以通过不同的MMTP会话被递送。在一些实施例中，配置一个服务的组件可以被划分并且在ROUTE会话和MMTP会话中被递送。虽然未示出，配置一个服务的组件可以通过宽带被递送(混合递送)。
图3是示出根据本公开的一个实施例的低等级信令(LLS)表和服务列表表(SLT)的图。
LLS表的一个实施例t3010可以包括根据LLS_table_id字段、provider_id字段、LLS_table_version字段和/或LLS_table_id字段的信息。LLS表可以进一步包括LLS_group_id字段和group_count_minus1字段。
LLS_table_id字段可以识别在主体中递送的表的类型，并且provider_id字段可以识别与由LLS表用信号发送的服务相关联的服务提供商。在这里，服务提供商是使用所有或者一些广播流的广播器(broadcaster)，并且provider_id字段可以识别正在使用广播流的多个广播器中的一个。LLS_table_version字段可以提供LLS表的版本信息。在一个实施例中，每当通过LLS_table_id字段和LLS_group_id字段的组合识别的表的数据改变时，该字段的值被增加1。
根据LLS_table_id字段的值，LLS表可以包括至少下述之一：SLT，包括与内容咨询评级有关的信息的评级区域表(RRT)、用于提供与系统时间有关的信息的系统时间信息、以及用于提供与紧急警报有关的信息的通用警报协议(CAP)消息。LLS表可以包括符合高级紧急警报消息格式(AEA-MF)结构的高级紧急警报表(AEAT)分段，而不是CAP消息。AEAT分段可以包括CAP消息。根据实施例，除了这些信息之外，LLS表还可以包括其他信息。
LLS_group_id字段可将LLS表(LLS_table())与具有相同LLS_group_id的组的表相关联。此字段的范围是广播流。即，LLS_group_id字段的值在广播流内应是唯一的。
group_count_minus1字段指示比当前LLS分组流或特定PLP中承载的链路层分组流中的表的不同LLS表组的总数少一。例如，值0指示存在仅承载一个LLS_group_id的值的LLS_table()，并且值1指示存在承载两个LLS_group_id的值的LLS_table()。
示出的SLT的一个实施例t3020可以包括@bsid属性、@sltCapabilities属性、sltInetUrl元素和/或服务元素。每个字段可以根据示出的使用(Use)列的值被省略，或者可以存在多个字段。
@bsid属性可以是广播流的标识符。@sltCapabilities属性可以提供解码和显著地再现在SLT中描述的所有服务所需要的能力信息。sltInetUrl元素可以通过宽带提供用于获取服务信令信息的基础URL信息和用于SLT的服务的ESG。sltInetUrl元素可以进一步包括@urlType属性，其可以指示能够通过URL获取的数据类型。
服务元素可以包括有关在SLT中描述的服务的信息，并且可以存在每个服务的服务元素。服务元素可以包括@serviceId属性、@sltSvcSeqNum属性、@protected属性、@majorChannelNo属性、@minorChannelNo属性、@serviceCategory属性、@shortServiceName属性、@hidden属性、@broadbandAccessRequired属性、@svcCapabilities属性、BroadcastSvcSignaling元素和/或svcInetUrl元素。服务元素可以进一步包括@globalserviceID属性。
@serviceId属性是服务的标识符，并且@globalserviceID属性是表示服务标识的全球唯一URI值。@sltSvcSeqNum属性可以指示服务的SLT信息的序列号。@protected属性可以指示针对服务的显著的再现所必需的至少一个服务组件是否被保护。@majorChannelNo属性和@minorChannelNo属性可以分别地指示服务的主要信道编号和次要信道编号。
@serviceCategory属性可以指示服务的类别。服务的类别可以包括线性A/V服务、线性音频服务、基于app的服务、ESG服务、EAS服务等等。@shortServiceName属性可以提供服务的短的名称。@hidden属性可以指示是否服务是用于测试或者专用用途。@broadbandAccessRequired属性可以指示对于服务的显著的再现，宽带接入是否是必需的。@svcCapabilities属性可以提供用于服务的解码和显著的再现所必需的能力信息。服务属性可以包含@essential元素。@essential元素指示是否经由此广播流递送此服务的必要部分。
BroadcastSvcSignaling元素可以提供与服务的广播信令相关联的信息。此元素可以提供关于服务的广播网上的信令的信息，诸如位置、协议和地址。其细节将在下面描述。
svcInetUrl元素可以提供用于通过宽带访问服务的信令信息的URL信息。sltInetUrl元素可以进一步包括@urlType属性，其可以指示能够通过URL被获取的数据类型。
以上描述的BroadcastSvcSignaling元素可以包括@slsProtocol属性、@slsMajorProtocolVersion属性、@slsMinorProtocolVersion属性、@slsPlpId属性、@slsDestinationIpAddress属性、@slsDestinationUdpPort属性和/或@slsSourceIpAddress属性。
@slsProtocol属性可以指示用于递送服务的SLS的协议(ROUTE、MMT等等)。@slsMajorProtocolVersion属性和@slsMinorProtocolVersion属性可以分别地指示用于递送服务的SLS的协议的主要版本号和次要版本号。
@slsPlpId属性可以提供用于识别递送服务的SLS的PLP的PLP标识符。在一些实施例中，此字段可以被省略，并且由SLS递送的PLP信息可以使用以下描述的LMT的信息和SLT的引导信息的组合来确认。
@slsDestinationIpAddress属性、@slsDestinationUdpPort属性和@slsSourceIpAddress属性可以分别地指示递送服务的SLS的传输分组的目的地IP地址、目的地UDP端口和源IP地址。这些可以识别由SLS递送的传输会话(ROUTE会话或者MMTP会话)。这些可以包括在引导信息中。
图4是示出根据本公开的一个实施例的通过ROUTE递送的USBD和S-TSID的图。
示出的USBD的一个实施例t4010可以具有bundleDescription根元素。bundleDescription根元素可以具有userServiceDescription元素。userServiceDescription元素可以是一个服务的实例。
userServiceDescription元素可以包括@globalServiceID属性、@serviceId属性、@serviceStatus属性、@fullMPDUri属性、@sTSIDUri属性、名称元素、serviceLanguage元素、capabilityCode元素和/或deliveryMethod元素。每个字段可以根据示出的使用列的值被省略，或者可以存在多个字段。
@globalServiceID属性是服务的全球唯一标识符，并且可以用于与ESG数据(Service@globalServiceID)的链接。@serviceId属性是对应于SLT的服务条目的参考，并且可以等同于SLT的服务ID信息。@serviceStatus属性可以指示服务的状态。此字段可以指示该服务是否是活动的还是非活动的。
@fullMPDUri属性可以参考服务的MPD分段。MPD可以提供如上所述的通过广播或者宽带网络递送的服务组件的再现描述。@sTSIDUri属性可以参考服务的S-TSID分段。S-TSID可以提供与如上所述的接入承载服务的传输会话相关联的参数。
名称元素可以提供服务的名称。此元素可以进一步包括@lang属性，并且此字段可以指示由名称元素提供的名称的语言。serviceLanguage元素可以指示服务可用的语言。也就是说，此元素可以罗列能够由服务提供的语言。
capabilityCode元素可以指示显著地再现服务所必需的接收器的能力或者能力组信息。此信息与在服务通告中提供的能力信息格式兼容。
deliveryMethod元素可以提供相对于通过服务的广播或者宽带网络接入的内容的传输相关的信息。deliveryMethod元素可以包括broadcastAppService元素和/或unicastAppService元素。这些元素中的每个可以具有作为子元素的basePattern元素。
broadcastAppService元素可以包括通过广播网络递送的DASH表示的与传输相关联的信息。DASH表示可以包括在服务媒体呈现的所有时段上的媒体组件。
此元素的basePattern元素可以指示用于接收器执行与分片URL匹配的字形。这可以用于DASH客户端请求表示的分片。匹配可以暗指媒体分片在广播网络上的递送。
unicastAppService元素可以包括通过宽带递送的DASH表示的传输相关的信息。DASH表示可以包括在服务媒体呈现的所有时段上的媒体组件。
此元素的basePattern元素可以指示用于接收器执行与分片URL匹配的字形。这可以用于DASH客户端请求表示的分片。匹配可以暗指媒体分片在宽带网上的递送。
示出的S-TSID的一个实施例t4020可以具有S-TSID根元素。S-TSID根元素可以包括@serviceId属性和/或RS元素。每个字段可以根据示出的使用列的值被省略，或者可以存在多个字段。
@serviceId属性是服务的标识符，并且可以参考USBD/USD的服务。RS元素可以描述有关通过其服务的服务组件被递送的ROUTE会话的信息。根据ROUTE会话的数目，可以存在多个元素。RS元素可以进一步包括@bsid属性、@sIpAddr属性、@dIpAddr属性、@dport属性、@PLPID属性和/或LS元素。
@bsid属性可以是其中服务的服务组件被递送的广播流的标识符。如果此字段被省略，则默认广播流可以是包括递送该服务的SLS的PLP的广播流。此字段的值可以等于@bsid属性的值。
@sIpAddr属性、@dIpAddr属性和@dport属性可以分别地指示ROUTE会话的源IP地址、目的地IP地址和目的地UDP端口。当这些字段被省略时，默认值可以是递送SLS，也就是说，递送S-TSID的当前ROUTE会话的源地址、目的地IP地址和目的地UDP端口值。在不是当前ROUTE会话的递送该服务的服务组件的另一个ROUTE会话中，此字段可以不必被省略。
@PLPID属性可以指示ROUTE会话的PLP ID信息。如果此字段被省略，默认值可以是由S-TSID递送的当前PLP的PLP ID值。在一些实施例中，此字段被省略，并且ROUTE会话的PLP ID信息可以使用以下描述的LMT的信息和RS元素的IP地址/UDP端口信息的组合来确认。
LS元素可以描述有关通过其服务的服务组件被发送的LCT信道的信息。根据LCT信道的数目，可以存在多个元素。LS元素可以包括@tsi属性、@PLPID属性、@bw属性、@startTime属性、@endTime属性、SrcFlow元素和/或RepairFlow元素。
@tsi属性可以指示LCT信道的tsi信息。使用此，通过其服务的服务组件被递送的LCT信道可以被识别。@PLPID属性可以指示LCT信道的PLP ID信息。在一些实施例中，此字段可以被省略。@bw属性可以指示LCT信道的最大带宽。@startTime属性可以指示LCT会话的开始时间，并且@endTime属性可以指示LCT信道的结束时间。
SrcFlow元素可以描述ROUTE的信源流。ROUTE的信源协议被用于发送递送对象，并且至少一个信源流可以在一个ROUTE会话内被建立。信源流可以递送作为对象流的相关联的对象。
RepairFlow元素可以描述ROUTE的修复流。根据信源协议递送的递送对象可以根据前向纠错(FEC)被保护，并且修复协议可以定义启用FEC保护的FEC框架。
图5是示出根据本公开的一个实施例的通过MMT递送的USBD的图。
示出的USBD的一个实施例可以具有bundleDescription根元素。bundleDescription根元素可以具有userServiceDescription元素。userServiceDescription元素可以是一个服务的实例。
userServiceDescription元素可以包括@globalServiceID属性、@serviceId属性、名称元素、serviceLanguage元素、contentAdvisoryRating元素、信道元素、mpuComponent元素、routeComponent元素、broadbandComponent元素和/或ComponentInfo元素。userServiceDescription元素可以进一步包括@servicestatus属性和otherRatings元素。
每个字段可以根据示出的使用列的值被省略，或者可以存在多个字段。
@globalServiceID属性、@serviceId属性、@servicestatus、名称元素和/或serviceLanguage元素可以等同于通过ROUTE递送的USBD的字段。contentAdvisoryRating元素可以指示服务的基于RRT的内容报告评级。otherRatings元素可以指示服务的非RRT内容报告评级。此信息与在服务通告中提供的内容报告评价信息格式兼容。信道元素可以包括与服务相关联的信息。此元素的详细描述将在下面给出。
mpuComponent元素可以提供作为服务的MPU递送的服务组件的描述。此元素可以进一步包括@mmtPackageId属性、@contentIdSchemeIdUri属性、@contentIdValue属性、@nextMmtPackageId属性、@nextcontentIdSchemeIdUri属性、和/或@nextcontentIdValue属性。@mmtPackageId属性可以参考作为服务的MPU递送的服务组件的MMT包。@contentIdSchemeIdUri属性可以指示用于识别与当前MMT包有关的内容ID的方案的URI。@contentIdValue属性可以指示与当前MMT包有关的内容ID的值。@nextMmtPackageId属性可以参考在时间上由@mmtPackageId属性参考的MMT包之后要使用的MMT包。@nextcontentIdSchemeIdUri属性可以指示URI以识别与下一个MMT包有关的内容ID的方案。@nextcontentIdValue属性可以指示与下一个MMT包有关的内容ID的值。通过此元素的信息，可以参考MP表。
routeComponent元素可以包括服务的服务组件的描述。即使当线性服务组件通过MMT协议递送时，NRT数据也可以根据如上所述的ROUTE协议被递送。此元素可以描述有关这样的NRT数据的信息。此元素的详细描述将在下面给出。
broadbandComponent元素可以包括通过宽带递送的服务的服务组件的描述。在混合服务递送中，一个服务的某些服务组件或者其他的文件可以通过宽带被递送。此元素可以描述有关这样的数据的信息。此元素可以进一步包括@fullMPDUri属性。此属性可以参考描述通过宽带递送的服务组件的MPD。除了混合服务递送之外，广播信号可能由于在隧道中行进而被减弱，并且因此，此元素可能是支持在广播网络和宽带之间切换所必需的。当广播信号变弱时，服务组件通过宽带被获取，并且当广播信号变强时，服务组件通过广播网络被获取以保证服务连续性。
ComponentInfo元素可以包括有关服务的服务组件的信息。根据服务的服务组件的数目，可以存在多个元素。此元素可以描述每个服务组件的类型、作用、名称、标识符或者保护。此元素的详细信息将在下面描述。
以上描述的信道元素可以进一步包括@serviceGenre属性、@serviceIcon属性和/或ServiceDescription元素。@serviceGenre属性可以指示服务的流派(genre)，并且@serviceIcon属性可以包括服务的代表性图标的URL信息。ServiceDescription元素可以提供服务的服务描述，并且此元素可以进一步包括@serviceDescrText属性和/或@serviceDescrLang属性。这些属性可以指示服务描述的文本和在文本中使用的语言。
以上描述的routeComponent元素可以进一步包括@sTSIDUri属性、@sTSIDDestinationIpAddress属性、@sTSIDDestinationUdpPort属性、@sTSIDSourceIpAddress属性、@sTSIDMajorProtocolVersion属性和/或@sTSIDMinorProtocolVersion属性。
@sTSIDUri属性可以参考S-TSID分段。此字段可以等同于通过ROUTE递送的USBD的字段。此S-TSID可以提供通过ROUTE递送的服务组件的接入相关信息。此S-TSID可以在根据MMT协议递送线性服务组件的状态下，为了根据ROUTE协议递送的NRT数据而存在。
@sTSIDDestinationIpAddress属性、@sTSIDDestinationUdpPort属性和@sTSIDSourceIpAddress属性可以指示承载以上描述的S-TSID的传输分组的目的地IP地址、目的地UDP端口和源IP地址。也就是说，这些字段可以识别承载以上描述的S-TSID的传输会话(MMTP会话或者ROUTE会话)。
@sTSIDMajorProtocolVersion属性和@sTSIDMinorProtocolVersion属性可以分别地指示用于递送以上描述的S-TSID的传输协议的主要版本号和次要版本号。
以上描述的ComponentInfo元素可以进一步包括@componentType属性、@componentRole属性、@componentProtectedFlag属性、@componentId属性和/或@componentName属性。
@componentType属性可以指示组件的类型。例如，此属性可以指示组件是否是音频、视频或者隐藏字幕组件。@componentRole属性可以指示组件的角色。例如，如果组件是音频组件，则此属性可以指示主要音频、音乐、评论(commentary)等等。如果组件是视频组件，则此属性可以指示主要视频。如果组件是隐藏字幕组件，则此属性可以指示常规字幕或者简单的阅读器类型。
@componentProtectedFlag属性可以指示是否服务组件被保护，例如，被加密。@componentId属性可以指示服务组件的标识符。此属性的值可以对应于此服务组件的MP表的asset_id(资产ID)。@componentName属性可以指示服务组件的名称。
如上所述，在本公开的实施例中，可以通过多个ROUTE会话来传递一个服务的服务组件。在这种情况下，可以通过SLT的引导信息来获取SLS。可以通过SLS的USBD来参考S-TSID和MPD。S-TSID不仅可以描述由SLS递送的ROUTE会话，而且可以描述由服务组件承载的另一ROUTE会话的传输会话描述信息。通过此，可以收集所有通过多个ROUTE会话递送的服务组件。这类似地适用于其中一个服务的服务组件通过多个MMTP会话被递送的情况。作为参考，多个服务可以同时使用一个服务组件。
在本公开的另一实施例中，可以通过广播或宽带网络来执行ESG服务的引导。通过在宽带上获取ESG，可以使用SLT的URL信息。可以使用此URL来请求ESG信息。
在本公开的另一实施例中，一个服务的一个服务组件可以通过广播网络来递送，而另一个服务组件可以通过宽带来递送(混合)。S-TSID可以描述通过广播网络被递送的组件，使得ROUTE客户端获得期望的服务组件。另外，USBD可以具有基本模式信息，以描述哪些分片(哪些组件)通过哪个路径被递送。因此，接收器可以确认要从宽带服务请求的分片和要在广播流中检测的分片。
在本公开的另一个实施例中，可以执行服务的可缩放编码。USBD可能具有渲染服务所需的所有能力信息。例如，当以HD或UHD提供一个服务时，USBD的能力信息可以具有“HD或UHD”的值。接收器可以检查哪个组件被再现以便使用MPD渲染UHD或HD服务。
在本公开的另一实施例中，通过经由递送SLS的LCT信道递送的LCT分组的TOI字段，可以识别出使用该LCT分组哪个SLS分段被递送(USBD、S-TSID、MPD等)。
在本公开的另一实施例中，要用于基于app的增强/基于app的服务的app组件可以作为NRT组件通过广播网络被递送，或者可以通过宽带被递送。另外，用于基于app的增强的app信令可以由与SLS一起被递送的应用信令表(AST)执行。另外，可以以事件消息表(EMT)的形式与SLS一起被递送作为要由该app执行操作的信令的事件，可以在MPD中用信号发送，或者可以在DASH表示内以框的形式用带内信号发送。AST、EMT等可以通过宽带被递送。可以使用收集的app组件和此类信令信息来提供基于app的增强等。
在本公开的另一实施例中，可以在上述LLS表中包括并提供AEAT以用于紧急警报。还可以提供用于紧急警报的富媒体内容。富媒体可以由AEAT用信号发送，如果存在富媒体，则可以将富媒体作为由SLT用信号发送的EAS服务来提供。
在本公开的另一实施例中，可以根据MMT协议通过广播网络递送线性服务组件。在这种情况下，可以根据ROUTE协议通过广播网络递送服务的NRT数据(例如，app组件)。另外，服务的数据可以通过宽带来递送。接收器可以使用SLT的引导信息来接入递送SLS的MMTP会话。根据MMT的SLS的USBD可以参考MP表，使得接收器获取格式化为根据MMT协议递送的MPU的线性服务组件。另外，USBD可以进一步参考S-TSID，使得接收器获取根据ROUTE协议递送的NRT数据。另外，USBD可以进一步参考MPD以提供对通过宽带递送的数据的再现描述。
在本公开的另一实施例中，接收器可以通过网络套接字(web socket)方法将能够获取文件内容项(文件等)和/或流组件的位置URL信息递送给配套设备。配套设备的应用可以通过使用此URL经由HTTP GET的请求来获取组件、数据等。另外，接收器可以将诸如系统时间信息、紧急警报信息等的信息递送到配套设备。
在下文中，将描述链路层。
图6是示出根据本公开的实施例的链路层协议架构的图。图7是示出当输入分组是IP分组时的链路层操作的本公开的图。
链路层可以是物理层和网络层之间的层。传输侧可以将数据从网络层发送到物理层，而接收侧可以将数据从物理层发送到网络层。链路层的目的是将所有输入分组类型压缩(提取)为一种格式，用于物理层进行处理，并确保尚未定义的输入分组类型的灵活性和可扩展性。另外，链路层可以提供用于压缩(提取)输入分组的报头的不必要的信息以有效地发送输入数据的选项。诸如链路层的开销减少、封装等的操作被称为链路层协议，并且使用此协议生成的分组可以被称为链路层分组。链路层可以执行诸如分组封装、开销减少和/或信令传输的功能。
在传输侧处，链路层可以执行关于输入分组的开销减少过程，并且然后将输入分组封装为链路层分组。另外，在一些实施例中，链路层可以执行封装到链路层分组中同时不执行开销减少过程。由于使用链路层协议，可以显著地减少物理层上的数据传输开销，并且根据本公开的链路层协议可以提供IP开销减少和/或MPEG-2TS开销减少。
当输入IP分组作为输入分组时，链路层可以依次执行IP报头压缩、自适应和/或封装，如图7中所示。在一些实施例中，可以省略一些过程。例如，RoHC模块可以执行IP分组报头压缩以减少不必要的开销。可以通过在自适应模块中执行自适应过程来提取上下文信息并且将其进行带外发送。IP报头压缩和自适应过程可以统称为IP报头压缩。此后，通过在封装模块中执行封装过程，可以将IP分组和/或报头压缩分组和/或上下文信息封装到链路层分组中。当MPEG 2TS分组作为输入分组被输入时，链路层可以顺序地执行关于TS分组的开销减少和/或封装过程。在一些实施例中，可以省略一些过程。在开销减少中，链路层可以提供同步字节去除、空分组删除和/或公共报头去除(压缩)。通过同步字节去除，可以提供每个TS分组1个字节的开销减少。可以以其中在接收侧处能够重新插入的方式执行空分组删除。另外，可以以其中可以在接收侧处恢复连续报头之间的公共信息的方式执行删除(压缩)。可以省略一些开销减少过程。此后，通过封装过程，TS分组可以被封装为链路层分组。用于封装TS数据分组的链路层分组结构可能与其他类型的分组不同。
接下来，将描述IP报头压缩。
IP分组可以具有固定的报头格式，但是对于通信环境而言所必需的一些信息对于广播环境而言可能是不必要的。链路层协议可以压缩IP分组的报头以提供一种减少广播开销的机制。
发射器可以包括用于IP报头压缩的RoHC模块(或报头压缩器)和/或自适应模块，如图7中所示。RoHC模块可以基于RoHC方法来减小IP分组的报头的大小。然后，自适应模块可以从报头压缩的IP分组中提取上下文信息，并生成与报头压缩有关的信令信息。接收器可以基于信令信息和上下文信息来恢复分组报头，以重新配置原始IP分组。在下文中，IP报头压缩可以仅意指由RoHC模块进行的IP报头压缩，并且可以是组合通过RoHC模块进行的IP报头压缩和通过自适应模块进行的自适应过程的概念。这可能与接收器的解压缩中的相同。
在本公开中，为了便于描述，压缩之前的IP分组将被称为数据分组，并且RoHC类型的压缩之后的分组将被称为RoHC分组(或报头压缩的数据分组)。包括压缩之前的IP分组的流将被称为IP流或IP分组流，并且包括RoHC分组的流将被称为RoHC分组流或RoHC IP流。
在一个实施例中，IP版本、源IP地址、目的地IP地址、IP分段标志、源端口号、包括在IP报头中的信息的目的地端口号以及IP分组的UDP报头在IP流期间几乎没有改变。在本公开中，用于发送在流期间几乎没有改变的信息的字段将被称为静态字段。另外，发送到静态字段的信息将被称为静态信息。在本公开中，静态信息用于指代静态链信息。
在RoHC压缩中，在发送这些静态信息一次之后，暂时不执行附加信息。这将被称为初始化和刷新(IR)状态，并且用于将静态信息发送到报头的RoHC分组将被称为IR分组。另外，对于频繁改变但维持一定时间的动态信息，单独执行附加传输。动态信息通过动态字段被发送，并且被用于表示与本公开中的动态链信息相同的意思。
用于将动态信息发送到报头的RoHC分组将被称为IR-DYN分组。在一实施例中，IR分组还包括动态信息。即，因为IR分组和IR-DYN分组包括各种信息，所以分组具有与现有报头相似的大小。
RoHC分组中的除了IR分组和IR-DYN分组之外的其他分组将被称为压缩的分组。在一个实施例中，每个压缩的分组(或压缩分组)的报头仅包括1-2字节信息。在下文中，将描述自适应。
在通过单向链路传输的情况下，如果接收器不具有上下文信息，则接收器的解压缩器无法恢复接收到的分组报头，直到接收到完整的上下文。这可能会导致信道变更延迟和开启延迟。因此，压缩器/解压缩器之间的配置参数与上下文信息可以通过自适应功能在带外发送。自适应功能可以通过使用上下文信息和/或配置参数来构造链路层信令。即，可以通过链路层信令来执行带外传输。换句话说，自适应功能用于减少由上下文信息的丢失引起的解压缩错误和信道变更延迟。在本公开中，链路层信令和链路层信令信息用于表示相同的意思。
在下文中，将描述上下文信息的提取。
从报头压缩的IP分组，即，RoHC分组中提取上下文信息，并且可以根据自适应模式使用各种方法。
图8(a)和8(b)是图示当自适应模式为2并且当自适应模式为3时提取和处理上下文信息的过程的图。
自适应模式1是用于不对基本RoHC分组流(即，RoHC分组流)执行任何操作的模式。在这种模式下，自适应模块可以作为缓冲器操作。换句话说，在自适应模式1中，不从RoHC分组中提取上下文信息。RoHC分组流中的RoHC分组在封装模块中被封装为至少一个ALP分组，并且然后被发送到物理层。
在图8(a)的自适应模式2中，自适应模块从RoHC分组流中检测IR分组，并从检测到的IR分组的报头中提取上下文信息(即，静态链信息)。在一个实施例中，从其提取上下文信息的IR分组被转换成IR-DYN分组，其中，IR-DYN分组替代原始IR分组，并且以RoHC分组流中的相同顺序被发送到封装模块。在一个实施例中，所提取的上下文信息通过被包括在链路层信令信息的RoHC-U描述表(RDT)中而被发送到封装模块。封装模块将RoHC分组流中的分组封装为至少一个ALP分组，并将链路层信令信息封装为至少一个ALP分组，并将ALP分组发送到物理层。用于发送包括RoHC分组流的至少一个ALP分组的PLP可以与用于发送包括链路层信令信息的至少一个ALP分组的PLP不同或相同。
在图8(b)的自适应模式3中，自适应模块从RoHC分组流中检测IR分组和IR-DYN分组，并从检测到的IR和IR-DYN分组中提取上下文信息。在一个实施例中，从IR分组提取的上下文信息是静态链信息和动态链信息，而从IR-DYN分组提取的上下文信息是动态链信息。从其提取上下文信息的IR和IR-DYN分组被转换为压缩的数据分组。转换后的压缩的分组可以替换原始的IR和IR-DYN分组，并以相同的顺序在RoHC分组流中进行发送。在一个实施例中，所提取的上下文信息通过被包括在链路层信令信息的RDT中而被发送到封装模块。封装模块将RoHC分组流中的分组封装为至少一个ALP分组，并将链路层信令信息封装为至少一个ALP分组，并将ALP分组发送到物理层。用于发送包括RoHC分组流的至少一个ALP分组的PLP可以与用于发送包括链路层信令信息的至少一个ALP分组的PLP不同或相同。可以通过特定的物理数据路径来发送包括链路层信令信息的至少一个ALP分组。在一些实施例中，特定物理数据路径可以意指通用PLP或低等级信令(LLS)被转发到的PLP中的一个，或者可以意指专用的PLP或L1信令路径。
在这种情况下，RDT可以是信令信息，包括与报头压缩有关的信息(或报头压缩信息)和/或上下文信息(静态链和/或动态链)。在一些实施例中，每当上下文信息被改变，RDT都可以被发送。而且，在一些实施例中，可以从每个物理帧发送RDT。为了从每个物理帧发送RDT，可以重用先前的RDT。
在下文中，将描述分组封装。
链路层协议，即，封装模块可以将诸如IP分组和TS分组的所有类型的输入分组封装到至少一个链路层分组中。通过这种情况，物理层独立于网络层的协议类型仅需要处理一种分组格式(在这种情况下，MPEG-2TS分组可以被视为网络层分组)。即，每个网络层分组或输入分组在封装模块中被修改为通用链路层分组的有效载荷。
在分组封装过程期间可以使用分片。如果网络层分组太大而不能被物理层处理，则网络层分组可以被分割成两个或更多个分片。链路层分组报头可以包括用于在传输侧执行分片并且在接收侧进行重组的字段。可以按照与原始位置相同的顺序将这些分片封装到链路层分组中。
在分组封装过程期间也可以使用级联。如果网络层分组足够小以至于链路层分组的有效载荷包括数个网络层分组，则可以执行级联。链路层分组报头可以包括用于执行级联的字段。在级联的情况下，可以按照与原始输入顺序相同的顺序将输入分组封装到链路层分组的有效载荷中。
一个链路层分组可以包括报头和有效载荷，其中报头可以包括基本报头、附加报头和/或可选报头。可以取决于级联或分片的状态进一步添加附加报头，并且适合于该状态的必要字段可以被包括在附加报头中。此外，还可以添加可选的报头，以进行附加信息递送。可选报头的存在由附加报头的标志字段指示。在一些实施例中，指示附加报头和可选报头的存在的字段可以位于基本报头中。
图9是图示根据本公开的一个实施例的链路层分组的基本报头结构的图。
链路层分组的基本报头具有分级结构。基本报头具有对应于链路层分组报头的最小长度的2个字节的长度。
根据本公开的一个实施例的基本报头可以包括3个比特的packet_type字段、1个比特的PC字段和/或11个比特的长度字段。在一些实施例中，基本报头可以进一步包括1个比特的HM字段或S/C字段。
图10是图示分配给packet_type字段的代码值的实施例的表。
packet_type字段指示如图10中所示的在被封装到链路层分组中之前的输入数据的原始协议或分组类型。即，IPv4分组、压缩的IP分组、链路层信令分组和其他类型的分组可以用这种基本报头结构被封装。然而，在一些实施例中，可以用不同于基本报头结构的特定结构来封装MPEG-2TS分组。如果packet_type的值为“000”、“010”、“100”或“110”，则ALP分组的原始数据类型是IPv4分组、压缩的IP分组、链路层信令分组或扩展分组之一。如果MPEG-2TS分组被封装，则packet_type的值可以是“111”。packet_type字段的其他值可以保留以供将来使用。
Payload_Configuration(PC)字段指示有效载荷的配置。值为0指示链路层分组递送一个完整的输入分组，并且下一个字段为Header_Mode。值为1指示链路层分组递送一个或多个输入分组(级联)或一些较大的输入分组(分片)，并且下一个字段为Segmentation_Concatenation。
如果Header_Mode(HM)字段被设置为0，则其指示没有附加报头，并且指示链路层分组的有效载荷长度小于2048个字节。此值可以根据实施例而变化。值1指示在长度字段旁边存在附加的报头。在这种情况下，有效载荷的长度可能大于2047个字节/或可以使用可选功能(子流标识、报头扩展等)。此值可以取决于实施例而变化。仅当链路层分组的Payload_Configuration字段的值为0时，此字段才可能存在。
如果Segmentation_Concatenation(S/C)字段被设置为0，则指示有效载荷递送输入分组的分片，并且长度字段旁边存在用于分片的附加报头。值为1指示有效载荷递送具有大于0的有效载荷的完整输入分组并且用于级联的附加报头存在于长度字段旁边。只有ALP分组的Payload_Configuration字段的值为1时，此字段才可能存在。
长度字段可以指示由相应的链路层分组递送的有效载荷的字节单位的长度中的11个低位(即，11个最低有效位(LSB))。如果在附加报头中存在Length_MSB字段，则将长度字段级联在Length_MSB字段中，并成为LSB以提供有效载荷的实际总长度。长度字段的比特数可以更改为除了11个比特之外的其他比特数。
因此，以下分组结构的类型可用。即，没有附加报头的单个分组、具有附加报头的单个分组、分片的分组和级联的分组是可用的。在一些实施例中，更多的分组配置可以通过附加报头、可选报头、用于信令信息的附加报头和用于类型扩展的附加报头的组合来获得，稍后将会对其进行描述。
图11是图示根据本公开的一个实施例的用于信令信息的链路层分组的附加报头结构的图。
也就是说，如何将链路层信令合并到链路层分组中如下所述。当基本报头的packet_type字段等于100时，识别包括链路层信令的链路层分组，即，信令分组。
在图11中，斜线部分是用于信令信息的附加报头。即，除了图9中所示的报头之外，链路层分组可以包括两个附加部分(即，用于信令信息的附加报头和实际信令表)。信令表被包括在ALP分组的有效载荷中。因此，在一个实施例中，在链路层分组报头中指示包括信令表的链路层分组的总长度。
图12是图示本公开的附加报头(signaling_information_hdr())的语法结构的一个实施例的图。在图12中，根据实施例，可以省略或添加一些字段。
Signaling_Type字段是可以指示信令类型的8比特字段。在一个实施例中，如果Signaling_Type字段的值为0x01，则指示信令表是链路映射表(LMT)，如果Signaling_Type字段的值为0x02，则其指示信令表是RDT。
Signaling_Type_Extension字段是可以指示信令属性的16比特字段。相应字段的详细信息可以在信令选项中被定义。
Signaling_Version字段是可以指示信令版本的8比特字段。在一个实施例中，每当由Signaling_type字段标识的信令的数据改变时，此字段的值增加1。
Signaling_Format字段是2比特字段，其可以指示信令数据的数据格式。在这种情况下，数据格式可以意指二进制、XML等。
Signaling_Encoding字段是可以指定编码/压缩格式的2比特字段。此字段可以指示是否尚未执行压缩或已经执行特定压缩。
RDT和LMT是被包括在链路层信令中的表，并且链路层信令可以在低于IP层的级别的级别下操作。接收侧可以比LLS、SLT、SLS等的IP级别信令更快地获取链路层信令。因此，可以在会话建立之前获取链路层信令。
链路层信令可以根据输入路径包括内部链路层信令和外部链路层信令。内部链路层信令可以是在链路层生成的信令信息。这包括RDT或LMT。外部链路层信令可以是从外部模块、外部协议或上层接收到的信令信息。链路层中的封装模块可以将链路层信令封装到链路层分组中，并将链路层分组递送到物理层。此时，可以定义用于链路层信令的链路层分组结构(报头结构)，并且可以根据此结构将链路层信令信息封装到链路层分组中。
图13是示出根据本公开的一个实施例的链接映射表(LMT)的语法结构的图。即，在信令表是LMT的情况下，在ALP分组的ALP报头中的用于信令信息的附加报头中，signaling_type字段的值为0x01，signaling_type_extension字段的值为0xFFFF，signaling_format字段的值为00，并且signaling_encoding字段的值为00。
LMT可以提供通过PLP承载的上层(或较高层)会话的列表。另外，LMT可以提供用于处理承载上层会话的链路层分组的附加信息。在此，上层会话可以被称为多播。LMT可以用信号发送关于通过特定PLP发送的IP流或传输会话的信息。相反，LMT可以用信号发送关于递送特定传输会话的PLP的信息。
可以通过被标识为递送LLS的PLP发送LMT。在此，可以通过物理层的L1基本信令数据的L1B_lls_flag字段和L1详细信令数据的L1D_plp_lls_flag字段来标识用于递送LLS的PLP。L1B_lls_flag字段指示当前帧中的一个或多个PLP中LLS的存在或者不存在。在一个实施例中，当L1B_lls_flag字段的值为0时，其指示当前帧中没有LLS，并且当L1B_lls_flag字段的值为1时，其指示存在当前帧中承载的LLS。L1D_plp_lls_flag字段对于每个PLP指示当前PLP是否承载LLS。这些字段的目的是允许接收器快速定位上层信令信息(即，LLS)。即，LMT还可以与LLS一起通过相同的PLP被发送。如上所述，每个LMT都可以描述PLP和IP地址/端口之间的映射。如上所述，LLS可以包括SLT，并且在这一点上，由LMT描述的IP地址/端口可以是与由通过诸如相应LMT的PLP发送的SLT描述的任何服务相关的任何IP地址/端口。
在一些实施例中，上述SLT、SLS等中的PLP标识符信息可以用于确认指示通过哪个PLP发送由SLT或SLS指示的特定传输会话的信息。
在另一个实施例中，将省略上述SLT、SLS等中的PLP标识符信息，并且可以通过参考LMT中的信息来确认由SLT或SLS指示的特定传输会话的PLP信息。在这种情况下，接收器可以组合LMT和其他IP等级的信令信息来识别PLP。即使在此实施例中，也不会省略SLT、SLS等中的PLP信息，并且可以保留在SLT、SLS等中。
LMT可以包括PLP_ID字段、num_session字段和/或关于每个会话的信息。LMT可以描述通过一个PLP发送的IP流，并且可以通过添加PLP循环来描述关于多个PLP的信息。在这种情况下，如上所述，使用PLP循环，LMT可以描述与由被一起发送的SLT描述的所有服务有关的所有IP地址/端口的PLP。根据实施例，在图13的LMT中的会话可以是与多播相同的含义。LMT可以进一步包括num_PLPs_minus1字段。
num_PLPs_minus1字段指示的值比在表中为其提供多播到PLP映射的PLP的数量小一。PLP_ID字段可以指示与会话相对应的PLP。当使用PLP循环时，每个PLP_ID字段可以识别每个目标PLP。从PLP_ID字段的字段可以被包括在PLP循环中。这里，以下描述的PLP_ID字段可以是PLP循环的一个PLP的标识符，并且随后的字段可以是与对应的PLP相对应的字段。
num_session字段可以指示通过由PLP_ID字段识别的PLP递送的上层会话的数量。根据num_session字段指示的数字，可以包括有关每个会话的信息。此信息可以包括src_IP_add字段、dst_IP_add字段、src_UDP_port字段、dst_UDP_port字段、SID_flag字段、compressed_flag字段、SID字段和/或context_id字段。
src_IP_add字段、dst_IP_add字段、src_UDP_port字段和dst_UDP_port字段可以指示在通过由PLP_ID字段识别的PLP所递送的上层会话当中的传输会话的源IP地址、目的地IP地址、源UDP端口和目的地UDP端口。
SID_flag字段可以指示递送由四个字段Src_IP_add字段、Dst_IP_add字段、Src_UDP_Port字段、Dst_UDP_Port字段识别的上层会话的链路层分组在可选报头中是否具有SID字段。递送上层会话的链路层分组可以在可选报头中具有SID字段，并且SID字段值可以等于LMT中的SID字段的值。
compressed_flag字段可以指示报头压缩是否被应用于递送由四个字段Src_IP_add字段、Dst_IP_add字段、Src_UDP_Port字段、Dst_UDP_Port字段识别的上层会话的链路层分组的数据。另外，可以根据此字段的值来确定下述context_id字段的存在/不存在。当应用报头压缩(compressed_flag＝1)时，RDT可能存在，并且RDT的PLP ID字段可能具有与有关当前Compressed_flag字段的相应PLP_ID字段相同的值。
SID字段可以指示链路层分组的子流ID(SID)，用于递送由四个字段Src_IP_add字段、Dst_IP_add字段、Src_UDP_Port字段、Dst_UDP_Port字段识别的上层会话。链路层分组可以在可选报头中包括具有与当前SID字段相同的值的SID。因此，接收器可以在没有解析所有链路层分组的情况下使用LMT的信息和链路层分组报头的SID信息来滤波链路层分组。
context_id字段可以为RDT中的上下文ID(CID)提供参考。RDT的CID信息可以指示压缩IP分组流的上下文ID。RDT可以提供压缩IP分组流的上下文信息。通过此字段，可以将RDT和LMT关联起来。
在本公开的信令信息/表的上述实施例中，字段、元素或属性可以被省略或可以被其他字段替换。在一些实施例中，可以添加附加字段、元素或属性。
图14是图示根据本公开的一个实施例的RoHC-U描述表(RDT)的语法结构的一个实施例的图。也就是说，在一个实施例中，如果信令表为RDT，则对应的ALP分组的ALP报头中的用于信令信息的附加报头的signaling_type字段值为0x02，其signaling_type_extension字段值为0xFFFF，其signaling_format字段值为00，并且其signaling_encoding字段值为00。
图14的RDT可以包括PLP_ID字段、max_CID字段、adaptation_mode字段、context_config字段、num_context字段、context_id字段、context_profile字段、context_length字段、static_chain_byte()字段和/或dynamic_chain_byte()字段。
PLP_ID字段可以是指示与对应的RDT表相对应的PLP的8比特字段。
max_CID字段指示用于对应于此PLP的上下文ID的最大值。
context_id字段可以是指示压缩的IP流的上下文ID(CID)的8比特字段。在相应的系统中，可以将8比特的CID用于较大的CID。
context_profile字段可以是指示用于压缩的IP分组的协议(或层)的范围的8比特字段。在本公开中，如果context_profile字段的值为0，则该数据分组具有RoHC压缩格式，或者其指示实际报头信息尚未被压缩。在一个实施例中，如果context_profile字段值为1，则其指示RoHC压缩类型已被应用直至RTP；如果context_profile字段值为2，则其指示RoHC压缩类型已被应用直至UDP，如果context_profile字段值为3，则其指示RoHC压缩类型已应用直至ESP，并且如果context_profile字段值为4，则其指示RoHC压缩类型已经被应用直至IP。可以省略相应的字段。
adaptation_mode字段可以是2比特字段，其指示相应的PLP中的自适应模块的模式。在本公开的一个实施例中，如果adaptation_mode字段值为00，则其指示自适应模式1，如果adaptation_mode字段值为01，则其指示自适应模式2；如果adaptation_mode字段值为10，则其指示自适应模式3。上面已经描述每种自适应模式。
context_config字段可以是指示上下文信息的组合的2比特字段。如果上下文信息在相应的表中不存在，则可以将相应的字段设置为“0x0”。如果相应表中包括static_chain_byte()或dynamic_chain_byte()，则相应字段可以被设置为“0x01”或“0x02”。如果相应表中包括static_chain_byte()和dynamic_chain_byte()，则相应字段可以被设置为“0x03”。
num_context字段指示此表的上下文的数量。num_context字段的值不能大于max_CID字段的值。
context_length字段可以是8比特字段，其指示static_chain_byte()序列、dynamic_chain_byte()序列或通过将static_chain_byte()和dynamic_chain_byte()相加获得的序列的长度。可以省略相应的字段。
static_chain_byte()字段可以是用于递送用于初始化RoHC-U解压缩器的静态信息的字段。相应字段的大小和结构取决于上下文简档。
dynamic_chain_byte()字段可以是用于递送用于初始化RoHC-U解压缩器的动态信息的字段。相应字段的大小和结构取决于上下文简档。
static_chain_byte()可以被定义为IR分组的子报头信息。dynamic_chain_byte()可以被定义为IR分组和IR-DYN分组的子报头信息。
如上所述，包括在链路层中生成的APL分组的ALP流被发送到物理层。
图15是示出根据本公开的实施例的物理层中的广播服务的广播信号传输设备的结构的图。
根据本公开的实施例的广播服务的广播信号传输设备可以包括输入格式化块1000、比特交织编码和调制(BICM)块1010、帧构建块1020、正交频分复用(OFDM)生成块1030和信令生成块1040。将描述广播信号传输设备的每个块的操作。
根据本公开的实施例，输入数据可以是IP流/分组和MPEG2-TS或ALP流，并且其他流类型可以作为通用流来处理。
输入格式化块1000可以使用对其应用独立编码和调制的一个或多个数据通道(即，物理层通道)对每个输入流进行解复用。数据通道可能是用于稳健性控制的基本单元，并且可能会影响服务质量(QoS)。一个或多个服务或服务组件可能会影响一个数据通道。数据通道可以是物理层中的用于递送一个或多个服务或服务组件的用于递送服务数据或元数据的逻辑信道。在本公开中，数据通道DP是用作与物理层通道(PLP)相同的含义的物理路径，并且其标题可以根据设计者的意图而改变。
图16是图示根据本公开的一个实施例的输入格式化块1000的一个实施例的框图。
在图16中，输入格式化块1000包括封装和压缩块1001、基带格式化块1003和调度器1005。
封装和压缩块1001对输入数据分组进行报头压缩(选择性)，并封装输入数据分组，并且然后将其作为ALP分组输出。封装和压缩块1001的详细操作已经在链路层中被描述，并且因此在此将省略。封装和压缩块1001可以设置在链路层或物理层中。在一个实施例中，如果在链路层中提供封装和压缩块1001，则在物理层中将省略封装和压缩块1001，并且基带格式化块1003接收从链路层提供的ALP分组的ALP流。
从链路层或封装和压缩块1001输出的ALP分组的长度是可变的，并且可以从ALP分组的报头中识别。
从封装和压缩块1001输出的ALP分组被输入到基带格式化块1003。
基带格式化块1003根据调度器1005的指示生成一个或多个数据通道。也就是说，基带格式化块1003通过将基带报头添加到每个数据通道包括至少一个ALP分组的基带有效载荷来生成基带分组，并且然后通过相应的数据通道将基带分组输出到相应的BICM块1010。每个数据通道包括基带分组的流。
一个基带分组包括基带报头和包括至少一个ALP分组的基带有效载荷。在一个实施例中，基带分组的长度是固定的，并且由为目标数据通道选择的外码类型、内码率和码长来确定。在一个实施例中，将ALP分组以输入顺序分配给基带有效载荷。此时，在一个实施例中，如果输入的ALP分组的数量不足以填满相应的基带分组，则使用填充来填满相应的基带分组。在一个实施例中，如果甚至在相应的基带分组以最后一个ALP分组被填满之后仍有输入的ALP分组数目剩余，则将剩余部分(即，分割的ALP)分配给下一个基带分组。
基带报头包括最多三个字段。第一部分是指示所有基带分组的基础字段，第二部分是可选字段，并且第三部分是扩展字段。
因为QoS取决于根据本公开的实施例的广播服务的广播信号传输设备提供的服务的特性，所以需要经由不同的方法来处理与每个服务相对应的数据。BICM块1010针对每个数据通道进行操作。
BICM块1010可以包括被应用于对其不应用MIMO的简档(或系统)的处理块和/或对其应用MIMO的简档(或系统)的处理块，并且可以包括用于处理每个数据通道的多个处理块。
对其未应用MIMO的BICM块1010的处理块可以包括数据FEC编码器、比特交织器和星座映射器。BICM块1010可以进一步包括信号空间分集(SSD)编码块和时间交织器。时间交织器可以被包括在帧构建块1020中。根据本公开的实施例，时间交织器被包括在帧构建块1020中。对其应用MIMO的BICM块1010的处理块与对其不应用MIMO的BICM的处理块不同之处在于，还包括信元字解复用器和MIMO编码块。在不被包括在BICM块1010中的情况下，MIMO编码块可以被独立地形成。
数据FEC编码器可以使用外部编码(BCH)和内部编码(LDPC)对输入基带分组(BBP)执行FEC编码。数据FEC编码器的输出是FEC帧。外部编码(BCH)可以是选择性编码方法。比特交织器可以使用LDPC码和调制方法的组合来对数据FEC编码器的输出进行比特交织以实现优化的性能。星座映射器可以使用QPSK、QAM-16、不规则QAM(NUQ-64、NUQ-256、NUQ-1024)或不规则星座(NUC-16、NUC-64、NUC-256、NUC-1024)来调制来自比特交织器或信元字解复用器的信元字，并提供功率标准化的星座点。NUC具有任意类型，但是QAM-16和NUQ具有正方形。可以相对于每个码率特别地定义所有NUQ和NUC，并且由L1详细信令数据的L1D_PLP_mod字段(或PLS2数据的参数DP_MOD)用信号发送。星座映射器的输出是FEC块。
时间交织器可以在数据通道等级处操作。可以相对于每个数据通道不同地设置时间交织的参数。
在一个实施例中，在本公开的时间交织器中，无时间交织模式、卷积时间交织器(CTI)模式和混合时间交织器(HTI)模式中的一种被应用于每个PLP。时间交织器模式由L1-详细信令数据的L1D_plp_TI_mode字段用信号发送。作为示例，如果一个服务包括多个组件并且每个组件通过每个PLP发送，则每个PLP可以在无时间交织模式或HTI模式下操作。此时，HTI模式的各个参数可以彼此不同。作为另一示例，如果通过一个PLP发送一个服务，则可以使用CTI模式。
在CTI模式的情况下，在一个实施例中，时间交织器包括卷积时间交织器。在一个实施例中，与卷积时间交织器有关的信令信息被用信号发送到L1-详细信令数据的L1D_plp_CTI_depth字段、L1D_plp_CTI_start_row字段和L1D_plp_CTI_fecframe_start字段。
在HTI模式的情况下，时间交织器可以包括信元交织器、块交织器(BI)和卷积延迟线(或卷积交织器)。此时，块交织器可以被称为扭曲块交织器。
信元交织器将输入的FEC块布置在时间交织(TI)块中，并且然后在每个FEC块中执行交织。即，信元交织器以FEC块为单位接收输入信元，并将输入信元布置在TI块中。此时，每个TI块可以包括一个或多个FEC块，并且通过使用不同的交织序列在TI块中每个FEC块执行信元交织。另外，可以不使用信元交织，并且将关于是否使用信元交织的信息用信号发送到L1-详细信令数据的L1D_plp_HTI_cell_interleaver字段。
块交织器对TI块执行块交织。例如，块交织器通过对TI块执行扭曲的块交织来执行子帧内交织。此时，一个TI块可以包括一个或多个信元交织的FEC块，或者可以包括非信元交织的一个或多个FEC块。在执行扭曲块交织之后，选择性地执行卷积延迟线。向L1-详细信令数据的L1D_plp_HTI_inter_subframe字段用信号发送是否使用卷积延迟线。
在本公开中，可以将输入到时间交织器的FEC块分组为交织帧(IF)。交织帧具有独立于物理层帧的结构。此时，IF中的FEC块的数量NBLOCK_IF(n)可以从最小1变为最大NBLOCK_IF_MAX，并且在IF之间，FEC块的数量可以不同。与IF中的FEC块的数量有关的信息被用信号发送到L1-详细信令数据的L1D_plp_HTI_num_ti_block字段。
此时，每个IF可以被直接映射到一个子帧，或者可以扩展到多个子帧。每个IF可以被划分成一个或多个TI块，并且此时，TI块是用于信元交织器、块交织器和卷积延迟线的操作的基本单元。一个IF块中的每个TI块可以包括一个或多个FEC块。
信元字解复用器被用于将单个信元字流分割为双信元字流以处理MIMO。在一实施例中，信元字解复用器位于比特交织器与星座映射器之间，并且MIMO编码块位于星座映射器与时间交织器之间。因为如果应用MIMO则单个信元字流通过信元字解复用器被分割成双信元字流，因此需要两个星座映射器。MIMO编码块可以通过使用MIMO编码方案来处理每个星座映射器的输出。本公开的MIMO编码方案可以被定义为用于通过接收器中相对小的复杂性增加来提供容量增加的全速率空间复用(FR-SM)。MIMO处理在数据通道等级处被应用。如果将作为星座映射器输出对的NUQ(e1,i和e2,i)作为MIMO编码块的输入来供应，则MIMO编码块的输出对g1,i和g2,i通过每个发射天线的相同载波k和OFDM符号l发送。在本公开的一个实施例中，MIMO处理不应用于帧内的引导和前导。
帧构建块1020可以将通过被时间交织而输入的PLP的数据信元映射到帧中的OFDM符号中，并且执行频率交织用于频域分集。
在一个实施例中，帧构建块1020的输出是诸如前导或数据的OFDM符号，其被顺序地布置在最终帧中，并且针对OFDM符号执行频率交织器中的频率交织。即，频率交织器可以通过随机地交织输入数据信元来提供频率分集。而且，频率交织器可以通过使用不同的交织种子顺序针对与由两个连续的OFDM符号组成的OFDM符号相对应的数据或与一个OFDM符号相对应的数据进行操作，以在单个帧中获得最大交织增益。
通过进行频率交织而输出的帧被划分成前导区域和数据区域。在OFDM生成块1030中，包括引导数据的引导区域被插入到帧的前导的前面。在一个实施例中，在信令生成块1040中生成通过前导发送的L1信令数据。
L1信令数据包括L1基本信令数据和L1详细信令数据。L1基本信令数据可以被称为PLS1数据，并且L1详细信令数据可以被称为PLS2数据。
OFDM生成块1030通过由帧构建块1020生成的信元来调制OFDM载波，插入导频，并生成用于传输的时域信号。同样，相应的块顺序地插入保护间隔，应用PAPR减少处理，并且然后通过将包括引导数据的引导插入到相应帧的前面来生成最终的RF信号。
信令生成块1040可以生成用于每个功能块的操作的物理层信令信息。根据本公开的一个实施例的物理层信令信息可以包括L1基本信令数据和L1详细信令数据。在一个实施例中，L1基本信令数据(或PLS1数据)递送关于系统的基本信息以及解码L1详细信令数据(或PLS2数据)所需的参数。在一个实施例中，L1基本信令数据的长度固定为200比特。L1详细信令数据(或PLS2数据)详细定义数据上下文和解码数据上下文所需的信息。并且L1详细信令数据的长度在帧之间可变。
BICM块1010可以进一步包括用于保护L1信令数据(或PLS数据)的BICM块。用于保护L1信令数据(或PLS数据)的BICM块可以包括FEC编码器、比特交织器和星座映射器。
FEC编码器可以包括：加扰器，用于分别加扰L1基本信令数据(或PLS1数据)和L1详细信令数据(或PLS2数据)；BCH编码/零插入块，用于执行针对加扰的L1基本和详细信令数据(或PLS 1和2数据)的外部编码(例如，BCH)并在BCH编码后插入零位；LDPC编码块，用于通过使用LDPC码执行编码；以及LDPC奇偶打孔块。可以在LDPC编码之后对零插入的L1基本信令数据和/或L1详细信令数据的输出比特进行置换。比特交织器可以对经受缩短和打孔的L1基本信令数据和L1详细信令数据执行比特交织，并且星座映射器可以将比特交织的L1基本信令数据和L1详细信令数据映射到星座。在一个实施例中，不对L1信令数据执行时间交织，但是对L1信令数据执行频率交织。
图17是图示根据本公开的混合广播信号接收设备的一个实施例的框图。
混合广播接收器可以通过地面广播和宽带之间的交互从广播系统的DTV服务接收混合广播服务。混合广播接收器可以接收通过地面广播发送的广播音频/视频(A/V)内容，并且可以接收与A/V内容或一些A/V内容相关联的增强数据。在本说明书中，广播A/V内容可以被称为媒体内容。
混合广播接收器可以包括物理层控制器D55010、调谐器D55020、物理层处理器D55030、链路层处理器D55040、IP/UDP分组处理器D55050、ATSC 3.0DTV控制引擎D55060、ALC/LCT+客户端D55070、定时控制D55080、信令解析器D55090、HTTP动态自适应流(DASH)客户端D55100、HTTP接入客户端D55110、ISO基本媒体文件格式(BMFF)解析器、(ISO BMFF解析器)D55120和/或媒体解码器D55130。
物理层控制器D55010可以通过使用期望由混合广播接收器接收的地面广播信道的射频(RF)信息来控制调谐器D55020、物理层处理器D55030等的操作。
调谐器D55020接收并处理通过m根天线通过广播网络发送的广播信号，并将该广播信号输出到物理层处理器D55030。
在一个实施例中，物理层处理器D55030对从调谐器D55020输出的广播信号执行解调、帧解析、解交织和纠错解码。
图18是图示物理层处理器D55030的一个实施例的框图。即，图18图示根据本公开的一个实施例的用于物理层中的广播服务的广播信号接收设备的结构。
根据本公开的一个实施例的用于广播服务的广播信号接收设备可以对应于图15的用于广播服务的广播信号传输设备。
根据本公开的一个实施例的用于广播服务的广播信号接收设备可以包括同步和解调模块9000、帧解析模块9010、解映射和解码模块9020、输出处理器9030以及信令解码模块9040。
在一个实施例中，同步和解调模块9000对由调谐器D55020接收和处理的广播信号执行同步，并且以广播信号传输设备的相反过程执行OFDM解调。即，同步和解调模块9000可以执行引导信息检测、快速傅立叶变换(FFT)和导频检测。
帧解析模块9010可以包括频率解交织器、帧解析器和时间解交织器。在本公开的广播信号传输设备中，频率交织对于解调的广播信号的前导符号是必不可少的，并且对于包括在解调的广播信号的子帧中的数据符号是可选的。因此，频率解交织器针对前导符号执行频率解交织，并且根据L1详细信令数据的L1D_frequency_interleaver字段来对数据符号选择性地执行频率解交织。频率解交织的前导符号被输出到信令解码模块9040，并且包括对其选择性地执行频率解交织的子帧的数据符号的信号帧被输出到帧解析器，并且然后在帧解析器中被解析。由帧解析器解析的子帧中包括的数据通道(即，PLP)被输出到每个数据通道的时间解交织器，并且以广播信号传输设备的相反过程被时间解交织。基于L1信令数据执行帧解析和时间解交织。
信令解码模块9040对包括在前导中的L1信令数据进行解码，并且将包括在L1信令数据中的信息提供给必要的块。为此，信令解码模块9040包括星座解映射器、比特解交织器和FEC解码器，并且以广播信号传输设备的相反过程对L1信令数据执行解码。
解映射和解码模块9020基于L1信令数据以广播信号传输设备的相反过程对相应数据通道的数据执行符号解映射，执行比特解交织，并且然后执行纠错解码。解映射和解码模块9020的输出是至少一个基带分组。
输出处理器9030可以执行广播信号传输设备对输入基带分组应用的各种压缩/信号处理过程的逆过程，以改善传输效率。在这种情况下，输出处理器9030可以从从信令解码模块9040输出的数据中获取必要的控制信息。
对基带分组的有效载荷中包括的ALP分组的解封装、自适应和解压缩处理可以由物理层执行，或者可以由链路层执行。如果对ALP分组的解封装、自适应和解压缩处理由物理层执行，则解封装模块、自适应模块和解压缩模块可以被包括在输出处理器9030中。在这种情况下，在一个实施例中，输出处理器9030通过以广播信号传输设备的相反过程处理基带分组来检测ALP分组，并对检测到的ALP分组执行解封装、自适应和解压缩处理。此时，输出处理器9030的输出可以是IP流/分组或MPEG2-TS。如果由链路层执行对ALP分组的解封装、自适应和解压缩处理，则输出处理器9030的输出可以是包括ALP分组的ALP流。
在本公开的一个实施例中，解封装、自适应和解压缩处理由链路层执行。
在这种情况下，图17的物理层处理器D55030可以将ALP分组的流输出到链路层处理器D55040。
链路层处理器D55040对输入的ALP分组执行解封装、自适应和解压缩处理，稍后将描述详细操作。
如果包括在ALP分组中的输入分组是IP分组，则链路层处理器D55040的输出成为一个或多个IP分组。在本公开中，IP分组被用来指代与IP数据报相同的含义。
IP/UDP分组处理器D55050可以滤波一个或多个接收到的IP分组中的特定一个。即，IP/UDP分组处理器D55050对由DTV控制引擎D55060从链路层处理器D55040输出的一个或多个IP分组中选择的IP分组进行滤波，并以诸如ALC/LCT+的应用层传输协议分组的形式输出IP分组。
DTV控制引擎D55060可以负责每个混合广播接收器中包括的模块之间的接口。而且，DTV控制引擎D55060可以将每个模块所需的参数递送到每个模块，并通过该参数控制每个模块的操作。在本公开中，DTV控制引擎D55060可以将媒体呈现描述(MPD)和/或MPD URL递送给DASH客户端D55100。而且，在本公开中，DTV控制引擎D55060可以将递送模式和/或传输会话标识符(TSI)递送到ALC/LCT+客户端D55070。在这种情况下，TSI可以指示用于发送包括诸如MPD或MPD URL相关信令的信令消息的传输分组的会话的标识符，例如，作为应用层传输协议的ALC/LCT+会话或FLUTE会话。此外，传输会话标识符可以对应于MMT的资产id。
ALC/LCT+客户端D55070可以通过处理诸如ALC/LCT+的应用层传输协议并且收集并处理多个分组来生成一个或多个ISO基本媒体文件格式(ISOBMFF)对象。ALC/LCT分组、ALC/LCT+分组、ROUTE分组和/或MMTP分组可以被包括在应用层传输协议分组中。
定时控制器D55080可以处理包括系统时间信息的分组，并因此控制系统时钟。
信令解析器D55090可以获取并解析与DTV广播服务有关的信令(例如，LLS、SLS)，并且基于解析的信令来生成和管理信道映射。在本公开中，信令解析器可以解析从信令信息扩展的与MPD或MPD相关的信息。
DASH客户端D55100可以执行与实时流或自适应流有关的计算。DASH客户端D55100可以通过HTTP接入客户端D55110从HTTP服务器接收DASH内容。DASH客户端D55100可以通过处理接收到的DASH片段来输出ISO基本媒体文件格式对象。在本公开中，DASH客户端D55100可以将完全合格的表示ID或分片URL递送给DTV控制引擎D55060。在这种情况下，例如，完全合格的表示ID可以意指通过MPD URL、period@id和representation@id的组合获得的ID。另外，DASH客户端D55100可以从DTV控制引擎D55060接收MPD或MPD URL。DASH客户端D55010可以通过使用接收到的MPD或MPD URL从HTTP服务器接收所期望的媒体流或DASH分片。在本说明书中，DASH客户端D55100可以被称为处理器。
HTTP接入客户端D55110可以请求用于HTTP服务的特定信息，并且可以通过从HTTP服务器接收响应来处理对该请求的响应。在这种情况下，HTTP服务器可以处理从HTTP接入客户端收到的请求，并提供对该请求的响应。
ISO BMFF解析器D55120可以从ISO基本媒体文件格式对象提取音频/视频的数据。
媒体解码器D55130可以解码接收到的音频和/或视频数据，并执行用于呈现解码后的音频/视频数据的处理。
同时，如上所述，在传输系统的递送层中根据MMTP或ROUTE协议处理的数据被封装到UDP/IP层的IP分组中，并且然后被发送到链路层。即，在一个实施例中，将UDP报头添加到包括根据MMTP或ROUTE协议处理的数据的UDP有效载荷以生成UDP分组，并且将IP报头添加到该UDP分组以生成IP/UDP分组。在本公开中，为了便于描述，将由IP报头、UDP报头和有效载荷组成的分组或将由IP报头和有效载荷组成的分组称为IP分组。
图19是图示发送到链路层的IP分组的报头结构的一个实施例的图，其中，报头包括IP报头和UDP报头。
在图19中，将4比特分配给版本字段，其指示相应分组的版本是IPv4或IPv6。在一个实施例中，版本是IPv4。
互联网报头长度(IHL)字段被分配有4个比特，并且指示IP报头的长度。即，IHL字段指示除了数据区域的长度之外的纯报头的长度。
服务类型(TOS)字段被分配有8个比特，并且显示与IP协议向用户提供的服务质量(QoS)有关的内容。即，TOS字段定义IP分组的优先级。
总长度字段被分配有16个比特，并且以字节为单位指示IP报头和实际数据区域的总大小。即，总长度字段指示相应的IP分组的总长度。
标识字段被分配有16个比特，并且是用于标识每个IP分组的标识符。如果将要发送的IP分组被分段成两个或更多个小分组，则从一个IP分组分段的分组的标识字段值彼此相等。即，不进行分段的IP分组具有不同的值。在本公开中，为了便于描述，将从一个IP分组分段的分组称为分段分组或分段的IP分组。
IP标志字段被分配有3个比特，并且包括与IP分组的分段有关的信息。此字段的第一个标志为0，第二个标志为不分段(DF)，并且指示相应的分组是否被分段。例如，如果DF的标志值为0，则指示相应的分组是分段的分组。如果DF的标志值为1，则指示相应的分组是未被分段的分组。此字段的第三个标志是“更多分段(MF)”标志，并且指示相应的分组是否是最后分段分组。例如，如果MF标志的值为0，则指示相应的分组是最后分段分组，如果MF标志的值为1，则指示相应的分组不是最后分段分组。
分段偏移(fragment offset)字段被分配有13个比特，并且指示当IP分组被分段时，相应的分段分组在IP分组中的数据区域中的相对位置。
存活时间(time to live,TTL)字段被分配有8个比特，并且指示相应的分组可以在网络上保留多长时间。
协议(protocol)字段被分配有8个比特，并且指示存储在相应IP分组的有效载荷中的上层协议。
报头校验和(header checksum)字段被分配有16个比特，并且仅用于IP报头。
源IP地址(Source IP address)字段和目的地IP地址(Destination IP address)字段分别被分配有32个比特，并指示相应分组的源IP地址和目的地IP地址。
版本字段、IHL字段、TOS字段、总长度(total length)字段、标识(Identification)字段、IP标志(IP flags)字段、分段偏移(Fragment offset)字段、TTL字段、协议(Protocol)字段和报头校验和(Header Checksum)字段是包括在IP报头中的字段。
在图19中，源端口(source port)字段、目的地端口(destination port)字段、长度(Length)字段和校验和(Checksum)字段是UDP报头中包含的字段。
源端口字段和目的地字段分别被分配有16个比特，并且指示相应分组的源端口号和目的地端口号。
长度字段被分配有16个比特，并且以字节为单位指示UDP报头和实际数据区域的和大小。即，长度字段指示相应的UDP分组的总长度。
校验和字段被分配有16个比特，并且仅用于UDP报头。
接下来，将描述IP分组的分段过程。
当要从IP/UDP层发送到链路层的IP分组的大小大于最大传输单元(MTU)时，对IP分组执行分段，从而将IP分组分割成两个或更多个分段的分组，并且然后进行发送。在这种情况下，在一个实施例中，MTU意指可以一次从IP/UDP层发送到链路层的数据大小。即，如果要发送到链路层的IP分组的大小大于MTU，则不能发送IP分组，从而对IP分组执行分段。
如果对IP分组执行分段，则将IP分组分割成两个或更多个分段，并将IP报头添加到每个分段的前面以生成分段分组。换句话说，每个分段分组是由IP报头和有效载荷组成的IP分组。
例如，假设在IP/UDP层中对IP分组执行分段，并且将IP分组分割成三个分段分组。还假设第一分段分组被称为分段分组A，第二分段分组被称为分段分组B，并且第三分段分组被称为分段分组C。
此时，分段分组A、B和C的各自的IP报头内的标识字段值都彼此相等，但是分段偏移字段值都彼此不同。分段分组A、B和C的各自IP报头中的IP标志字段的DF标志都被设置为0以指示相应的分组是分段的分组。另外，分段分组A和B的各自的IP报头内的IP标志字段的MF标志都被设置为1以指示存在另外的分段分组，并且分段分组C的IP报头中的MF标志被设置为0以指示其为最后分段分组。
图20(a)至20(d)是图示从IP/UDP层向链路层发送未对其执行分段的四个IP分组的图。在这种情况下，四个IP分组的各自的IP报头内的标识字段值都彼此不同，并且分段偏移字段值都为0。四个IP分组的各自的IP报头内的IP标志字段的DF标志都被设置为1以指示相应的分组是未被分段的分组。另外，根据一个实施例，四个IP分组的各自的IP报头内的IP标志字段的MF标志都被设置为0。
图21(a)至21(d)是图示如图20(a)至图20(d)中所示当接收到四个IP分组时RoHC方案被应用于四个IP分组以执行IP报头压缩并且然后将IP分组封装到ALP分组中的图。在这种情况下，通过报头压缩将RoHC报头应用于每个有效载荷，并且通过封装处理添加ALP报头以生成四个ALP分组。
图22是图示根据本公开的数据传输过程的广播系统的一个实施例的框图。
在图22中，广播系统可以包括演播室(studio)1211、广播网关1213和发射器1215。在本公开中，广播网关1213可以被称为链路层处理器。
在一个实施例中，考虑到OSI 7层结构，演播室1211执行IP/UDP层以及比IP/UDP层更高的层中的操作和传输功能。在一个实施例中，广播网关1213执行链路层(即，层2)中的操作和传输功能。如果从演播室1211发送的分组是IP分组，则广播网关1213包括RoHC模块、自适应模块和封装模块，如图7中所示。在一个实施例中，发射器1215执行物理层中的操作和传输功能。在一个实施例中，发射器1215包括图15的广播信号传输设备。
演播室1211、广播网关1213和发射器1215中的每一个的功能或模块被连接到具有单独协议的链路，其中在一个实施例中，该链路被称为演播室到发射器链路(STL)。
例如，基于ATSC 3.0，演播室1211对视频和/或音频数据进行编码，并通过使用包括编码后的视频和/或音频数据的ROUTE和/或MMT分组来配置递送格式。演播室1211处理IP/UDP分组中的ROUTE分组和/或MMT分组，并将分组递送到广播网关1213。在ATSC 3的情况下，广播网关1213对应于ATSC链路层协议(ALP)功能，并且在DVB的情况下对应于通用流封装(GSE)功能。通常，IP(或IP/UDP)层和链路层的RoHC模块彼此独立运行。
图23(a)至图23(d)是图示根据本公开的在IP/UDP层中生成的四个IP分组的一个实施例的图，并且图24(a)、24(b1)至24(b3)、24(c)和24(d)是图示对图23(b)的IP分组执行分段以生成如图24(b1)至24(b3)的三个分段分组的图。即，图24(a)、24(b1)至24(b3)、24(c)和24(d)的IP分组被输入到链路层的RoHC模块。
当对具有IP报头和UDP报头的IP分组，即，IP/UDP分组执行分段操作时，如图24(b1)至24(b3)中所示，注意到UDP报头仅存在于第一分段分组中，并且不存在于其他分段分组中。IP报头存在于所有的分段分组中。
当IP分组被递送到链路层，在IP分组的递送路径或路由器中无法处理足够长度的IP分组，即，MTU小于要被发送的IP分组的长度时，支持IP分段。根据IP分组的递送路径或路由器可以发送的MTU，将一个IP分组分割成多个分段，并将IP报头添加到每个分段以生成分段分组，并且然后将这些分段分组发送到链路层。即，根据路由器或演播室广播网关之间的链路的MTU，IP分组可以在演播室中被分段，并且然后被发送到广播网关。在接收器中，基于用信号发送到每个IP报头的与分段相关的信息，对其应用分段的分段分组，即，IP分组可以被恢复为原始IP分组。
如上所述，在一个实施例中，RoHC方案被用于IP分组的报头压缩，并且考虑到ATSC3.0广播链路的属性，RoHC框架以单向模式(U模式)操作。在RoHC框架中，定义多个报头压缩简档。每个简档指示特定的协议组合，并且简档标识符由互联网数字分配授权机构(IANA)分配。在一个实施例中，“0x0002”简档被用于ATSC 3.0。下表1是为ATSC 3.0定义的RoHC简档示例。
[表1]
简档标识符 简档 协议组合 参考
0x0002 RoHC UDP UDP/IP RFC 3095,RFC 4815
也就是说，如果在链路层的RoHC模块中不存在IP报头和UDP报头中的任何一个，则在链路层的RoHC模块中不执行报头压缩。因此，如图24(b2)和24(b3)中所示，不对不具有UDP报头的IP分组执行报头压缩。
换句话说，如果通过IP分段输入不具有UDP报头的IP分组，则RoHC模块应用具有简档编号为0x00的非压缩简档，如图24(b2)和24(b3)中所示。此时，因为非压缩简档具有用于通过使用RoHC报头格式来发送实际IP报头的结构，所以无法期望报头压缩效率。
图25(a)、25(b1)至25(b3)、25(c)和25(d)是图示当广播网关1213的RoHC模块将报头压缩和封装应用于图24(a)、24(b1)至24(b3)、24(c)和24(d)的IP分组时的ALP分组的图。
如图25(b2)和25(b3)中所示，注意，实际上没有对不具有UDP报头的IP分组执行报头压缩，并且已经以RoHC分组报头的形式改变IP分组的格式。即，具有IP报头和UDP报头的IP分组以0x02简档经受报头压缩，而具有IP报头但无UDP报头的IP分组(即，分段分组)以0x00简档经受报头压缩。
如果如图25(a)、25(b1)至25(b3)、25(c)和25(d)中所示执行IP报头压缩，可能会出现一些问题。即，如果在分组流的中间改变压缩的简档，则出现系统复杂度和延迟增加的问题。如果递送单一类型的分组流，则可以使用一个简档和根据一个简档的RoHC分组结构，但是应配置用于IP分段的附加的简档，并且应根据附加的简档对应于附加的RoHC分组结构。另外，在切换简档的过程中，在发射器中发生延迟，并且对于接收器来说需要大量的存储容量以用于在使用不同简档压缩的分组流报头之间的同步。为了通过使用RoHC有效利用带宽并同时快速发送和接收大量广播流，减少开销是非常重要的。为了减少开销，增加广播传输网络的容量是最有效的。然而，出现更新广播系统的基础设施需要大量成本和大量时间的问题。
为了解决上述问题，本公开提出用于广播网关内的链路层中的IP分段的附加预处理。
图26是图示根据本公开的包括在链路层中操作的广播网关的广播系统的一个实施例的图。即，在一个实施例中，预处理器1321位于广播网关1320的RoHC模块1322之前。
图27是图示图26的广播系统的广播网络结构的一个实施例的框图，其中预处理器包括在广播网关中。
在一个实施例中，图26和图27中的广播系统的发送侧1300包括演播室1310、广播网关1320和发射器1330。
在一个实施例中，演播室1310执行IP/UDP层以及比IP/UDP层更高的层中的操作和传输功能。在一个实施例中，广播网关1320执行链路层(即，层2)中的操作和传输功能。
如果从演播室1310发送的分组是IP分组，则根据一个实施例，广播网关1320包括预处理器1321、RoHC模块1322、自适应模块1323和封装模块1324。
在一个实施例中，发射器1324执行物理层中的操作和传输功能。在一个实施例中，发射器1324包括图15的广播信号传输设备。
在一个实施例中，演播室1310对视频和/或音频数据进行编码，并且通过使用包括编码后的视频和/或音频数据的ROUTE和/或MMT分组来配置递送格式。演播室1310将ROUTE分组和/或MMT分组分包在IP/UDP分组中。此时，根据演播室与广播网关之间的链路或路由器的MTU，将IP/UDP分组发送到广播网关1320，即，链路层，或者被分段成多个分段分组并且然后被发送到链路层。即，在一个实施例中，如果IP/UDP分组的长度比MTU长，则对IP/UDP分组执行分段。
图28(a)至28(d)是图示在演播室1310的IP/UDP层中生成的四个IP分组的一个实施例的图，图29(b1)至29(b3)是图示对图28(b)的IP分组执行分段以产生三个分段分组的图。即，包括图29(a)、29(b1)至29(b3)、29(c)和29(d)的IP分组的分组流(即，广播流)通过演播室1310的每个路由器被输入到在链路层中操作的广播网关1320的预处理器1321。
当对具有IP报头和UDP报头的IP分组，即，IP/UDP分组执行分段操作时，如在图29(b1)至29(b3)中所示，注意到UDP报头仅存在于第一分段分组中，而不存在于其他分段分组中。IP报头存在于所有分段分组中。
预处理器1321参考输入分组流内的IP分组的每个IP报头检测IP分段是否已应用于输入分组流。在一个实施例中，如果检测到经历IP分段的分段分组，则将分段分组存储在缓冲器或存储器中，直到接收到构成对应的IP/UDP分组的所有分段分组。如果接收到构成对应的IP/UDP分组的所有分段分组，则将接收到的分段分组进行组合以恢复为原始IP/UDP分组。即，通过预处理器1321执行的预处理而恢复的IP/UDP分组(即，IP流)与期望由初始演播室1310发送的IP/UDP分组(即，IP流)相同。
例如，如果从IP/UDP分组分段的三个分段分组被输入到预处理器1321，如图29(b1)至29(b3)中所示，预处理器1321在存储接收到的分组的同时等待分段分组，直到接收到三个分段分组。如果接收到全部三个分段分组，则将这三个分段分组合并以恢复为分段前的IP/UDP分组，如图30(b)中所示。
由预处理器1321预处理的图30(a)至30(d)的IP分组(即，IP/UDP分组)被输出到RoHC模块1322。
RoHC模块1322通过将RoHC方案应用于输入IP分组来执行IP报头压缩。
此时，因为输入到RoHC模块1322的IP分组包括IP报头和UDP报头两者，所以以0x02简档对IP分组执行报头压缩，并且不考虑其他简档。在传输系统的实现中，RoHC模块1322的分组分类功能可以被重新用于此预处理。
图31(a)至图31(d)是图示通过使用RoHC方案对四个IP分组执行IP报头压缩并且然后如图30(a)至30(d)中所示当接收到四个IP分组时将IP分组封装成ALP分组的图。在这种情况下，通过报头压缩将RoHC报头添加到每个有效载荷，并且通过封装处理将ALP报头添加到每个有效载荷，从而生成四个ALP分组。以此方式，所生成的ALP分组被发送到物理层。
以上已经描述RoHC模块1322、自适应模块1323和封装模块1324的详细操作，并且因此在此将省略其详细描述。
图32是图示根据本公开的一个实施例的包括预处理器1321的广播网关的操作的流程图。在本公开中，IP分组的报头压缩是可选的，并且图32图示对包括IP分组的IP流执行报头压缩。
如图19中所示，IP分组的IP报头包括与分段有关的字段。在本公开中，从字段中注意到，相应的IP分组是否是被应用分段的分段分组。如果相应的IP分组是分段分组，则注意分段分组是否是最后的分段分组，并且可以识别相应的分段分组的IP/UDP分组内的相对位置。例如，在一个实施例中，与分段有关的字段包括标识字段、IP标志字段中包括的DF标志和MF标志以及分段偏移字段。
也就是说，如果从IP/UDP层接收到IP分组(S1421)，则预处理器1321检查接收到的IP分组是否为应用分段的分段的IP分组(S1422)。例如，预处理器1321通过使用所接收的IP分组的IP报头内的IF标志字段的DF标志来检查对应的IP分组是否是分段的IP分组。例如，如果DF标志的值为0，则预处理器1321确定对应的IP分组是分段的IP分组。
如果在步骤S1422中检查到接收到的IP分组是未对其应用分段的分组(即，DF标志值为1)，则执行步骤S1426用于接收到的IP分组的报头压缩。
如果在步骤S1422中检查到接收到的IP分组是对其应用分段的分组，则存储接收到的IP分组，并且等待具有与IP分组的IP报头内的标识字段值相同的值的一个或者多个IP分组(S1423)。重复此过程，直到具有相同标识字段值的IP分组都被接收和存储。IP报头中的MF标志可以用于检查是否已经接收到具有相同标识字段值的所有IP分组的方法。即，如果MF标志值为1，则指示还存在分段的IP分组，并且如果MF标志值为0，则指示对应的IP分组是最后的分段的IP分组。因此，如果接收到具有MF标志值为0的IP分组，则可以确定已经接收到具有相同标识字段值的所有IP分组。另外，为了增强可靠性，UDP报头内的校验和字段和长度字段可以另外用于验证是否已经接收到具有相同标识字段值的所有IP分组。
如果确定通过上述步骤已经接收到具有相同标识字段值的所有IP分组(S1424)，则使用每个IP分组内的IP报头的分段偏移字段来标识IP分组的顺序，并且IP分组以识别的顺序被组合并且因此被恢复为分段之前的IP分组(S1425)。此时，在一个实施例中，因为已恢复的IP分组是不应用分段的分组，所以将恢复的IP分组的IP报头内的DF标志值设置为1，并且分段偏移字段值设置为0。
下表2图示当IP分组被分段为三个分段的IP分组时每个IP报头内的分段相关字段的值和当预处理器1321通过组合三个分段的IP分组将IP分组恢复成分段之前的IP分组时IP报头内的分段相关字段的值的一个实施例。
[表2]
DF标志 MF标志 标识 分段偏移
分段的IP分组1 0 1 111 0
分段的IP分组2 0 1 111 1248
分段的IP分组3 0 0 111 2048
恢复的IP分组 1 0 111 0
如果检查到在步骤S1422中接收到的IP分组是未应用分段的IP分组，或者在步骤S1425中多个分段的IP分组被恢复为分段之前的IP分组，则RoHC模块1322通过将RoHC方案应用于输入IP分组的IP流来执行报头压缩(S1426)。在步骤S1426中，将对其执行报头压缩的RoHC分组流输出到自适应模块1323，并且自适应模块1323基于自适应模式从RoHC分组流内的IR和/或IR-DYN分组中提取上下文信息。在一个实施例中，上下文信息通过被包括在链路层信令的RDT中来发送。例如，在自适应模式1的情况下，不存在提取上下文信息的过程，并且包括IR和IR-DYN分组的RoHC分组流被封装模块1324封装成至少一个ALP分组，并且然后通过数据PLP被发送到接收器。此时，包括RDT和LMT的链路层信令被封装模块1324封装到至少一个ALP分组中，并且然后通过向其发送LLS的信令PLP发送到接收器。
在自适应模式2的情况下，从IR分组中提取上下文信息(即，静态链信息)，并将从其提取上下文信息的IR分组转换成IR-DYN分组。转换后的IR-DYN分组从原始IR分组中被替换，并且以RoHC分组流内的相同顺序被发送到封装模块1324。并且，IR-DYN分组被封装到至少一个ALP分组中，并且然后通过数据PLP被发送到接收器。所提取的上下文信息被包括在RDT中，并且包括RDT和LMT的链路层信令被封装模块1324封装成至少一个ALP分组，并且然后通过向其发送LLS的信令PLP发送到接收器。
在自适应模式3的情况下，从IR分组中提取上下文信息(即，静态链信息和动态链信息)，并且从IR-DYN分组中提取上下文信息(即，动态链信息)。从其提取上下文信息的IR分组和IR-DYN分组分别被转换成压缩分组。转换后的压缩分组从原始IR分组和IR-DYN分组中被替换，并且以RoHC分组流内的相同顺序被发送到封装模块1324，被封装成至少一个ALP分组，并且然后通过数据PLP被发送到接收器。所提取的上下文信息被包括在RDT中，并且包括RDT和LMT的链路层信令被封装模块1324封装成至少一个ALP分组，并且然后通过向其发送LLS的信令PLP发送到接收器。
同时，图17中的接收器的物理层处理器D55030对通过被包括在信号帧中而接收到的信令PLP和数据PLP执行解交织、解映射和纠错解码，并且将数据PLP和信令PLP输出到链路层处理器D55040。图18是图17的物理层处理器D55030的详细框图，上面已经描述详细描述，并且这里将省略其详细描述。图26的链路层处理器1440可以被应用于图17的链路层处理器D55040。
在一个实施例中，物理层控制器D55010可以通过使用L1基本信令数据的L1B_lls_flag字段和L1详细信令数据的L1D_plp_lls_flag来快速识别包括LLS、LMT和RDT的信令PLP。因此，在RoHC分组流之前，链路层处理器D55040可以获取通过信令PLP接收的至少一个ALP分组内的链路层信令信息。
也就是说，链路层处理器D55040的解封装模块1441通过对通过信令PLP接收到的至少一个ALP分组进行解封装来获取链路层信令信息。解封装模块1441可以通过使用链路层信令信息中包括的LMT和RDT对通过数据PLP接收到的至少一个ALP分组进行解封装来获取RoHC分组流。
在自适应模式1的情况下，不存在从RDT中提取上下文信息的过程。即，通过绕过自适应模块1442，将通过数据PLP接收到的ALP分组获取的RoHC分组流输出到RoHC模块(即，解压缩块)1443。RoHC模块1443通过使用RDT中包括的压缩信息对RoHC分组流内的RoHC分组执行报头解压缩，并且然后在报头压缩之前恢复IP分组。
在自适应模式2的情况下，自适应模块1442提取包括在RDT中的上下文信息，并通过使用所提取的上下文信息(即，静态链信息)和RoHC分组流内的对应IR-DYN分组来恢复IP分组。包括恢复的IR分组的RoHC分组流被输出到RoHC模块1443，并且RoHC模块1443通过使用从RDT获取的压缩信息对RoHC分组流内的RoHC分组执行报头压缩恢复报头压缩之前的IP分组。
在自适应模式3的情况下，自适应模块1442提取包括在RDT中的上下文信息。上下文信息包括从IP分组提取的静态链信息和动态链信息，以及从IR-DYN分组提取的动态链信息。自适应模块1442通过使用RoHC分组流内的相应压缩分组和提取的上下文信息来恢复IR分组和IR-DYN分组。包括恢复的IR和IR-DYN分组的RoHC分组流被输出到RoHC模块1443，并且RoHC模块1443通过通过使用从RDT获取的压缩信息对RoHC分组流内的RoHC分组执行报头解压缩来恢复报头压缩之前的IP分组。
从RoHC模块1443恢复的IP分组可以照原样发送到IP/UDP层。
同时，如果发射器的广播网关1320的预处理器1321通过组合分段的IP分组来恢复分段应用之前的IP分组并执行报头压缩，则接收器可能需要将通过报头解压缩恢复的相应的IP分组分段成多个分段的IP分组。在一个实施例中，取决于路由器或演播室广播网关之间的链路的MTU来确定是否执行分段。为此，本公开的接收器包括在RoHC模块1443旁边提供的后处理器1444。
在本公开的一个实施例中，如果由RoHC模块1443解压缩的IP分组报头的长度长于路由器或演播室广播网关之间的链路的MTU，则后处理器1444对IP分组执行分段。也就是说，IP分组被分割成两个或更多个分段，并且IP报头被添加到每个分段的前面以生成分段分组。在一个实施例中，如果后处理器1444对IP分组执行分段，则属于IP分组的多个分段分组的IP报头内的一些字段值被改变。
例如，假设后处理器1444通过对IP分组应用分段来将IP分组分割成三个分段分组。还假定第一分段分组是分段分组A，第二分段分组是分段分组B，并且第三分段分组是分段分组C。
此时，分段分组A、B和C的每个IP报头内的标识字段值被同等地设置，并且从分段偏移字段值中分配相应的分段分组的IP分组内的相对位置值。分段分组A、B和C的每个IP报头内的IP标志字段的DF标志都被设置为0以指示相应的分组是分段的分组。另外，将分段分组A和B的每个IP报头中的IP标志字段的MF标志设置为1以指示存在另外的分段分组，并且将分段分组C的IP报头内的MF标志设置为0以指示其为最后的分段分组。
如果不对由RoHC模块1443解压缩的IP分组报头执行分段，则后处理器1444执行缓冲器的功能。
绕过后处理器1444的IP分组或由后处理器1444分段的多个分段分组被输入到IP/UDP层处理器D55050。IP/UDP层处理器D55050参考输入IP分组的每个IP报头来检查是否已经对输入IP分组应用分段。当分段被应用于输入IP分组时，在上面已经描述用于将输入IP分组恢复为原始IP分组的方法并且在此将会省略。在执行IP分组恢复过程之后IP/UDP分组处理器D55050从一个或多个IP分组中滤波特定的一个，并以诸如ALC/LCT+的应用层传输协议分组的形式输出IP分组。
图33(a)至33(d)是图示输入到接收器的链路层处理器1440的解封装模块1441的ALP分组的一个实施例的图。如果在依次通过解封装模块1441、自适应模块1442和RoHC模块1443的同时对图33(a)至图33(d)的ALP分组执行解封装、自适应和解压缩，则如图24(a)至24(d)的IP分组被恢复。
图35(b1)至35(b3)是图示后处理器1444通过对IP分组应用分段将图34(b)的IP分组分割成三个分段的IP分组的图。IP/UDP分组处理器D55050可以通过组合分段的IP分组将图35(b1)到35(b3)的分段的IP分组恢复成图36(b)的原始IP分组。
在本公开中，上面已经描述将包括报头压缩信息和上下文信息(自适应模式2和3)的RDT发送到信令PLP并且在信令PLP中接收的示例。
作为本公开的另一个实施例，RDT可以划分成两种类型。两种类型中的一种将被称为目录RDT(catalog RDT)，并且另一种将被称为离散RDT(discrete RDT)。在本公开中，为了便于描述，目录RDT可以被称为第一RDT，并且离散RDT可以被称为第二RDT。
在本公开的一个实施例中，目录RDT被定义为包括用于一个或多个RoHC/ALP流的上下文数据的RDT递送类型并且被发送到信令PLP。因此，在本公开中，可以提供用于多个ALP流的多个RDT。在一个实施例中，信令PLP发送LMT、LLS等。可以由接收器在随机接入点处接收目录RDT。目录RDT可以被发送到稳健的特定PLP，而不是信令PLP。即，在一个实施例中，用于发送目录RDT的PLP和用于发送与目录RDT相关的RoHC分组流的PLP彼此不同。
在本公开中，离散RDT被定义为在由其自身支持的ALP流内专门承载的RDT递送类型。此接入适合RFC 3095，并且上下文始终在相关的IP流中被承载。即，离散RDT取决于上下文改变而频繁地生成，并且可以与RoHC分组流一起被发送到向其发送RoHC分组流的PLP。如果上下文改变，则因为离散RDT被生成并被立即发送，所以离散RDT可能不会在随机接入点发送。即，在一个实施例中，用于发送离散RDT的PLP和用于发送与离散RDT相关的RoHC分组流的PLP彼此相同。
目录RDT的语法结构和离散RDT的语法结构可以彼此相同或彼此不同。在本公开的一个实施例中，目录RDT和离散RDT遵循图14的RDT语法结构。
在一个实施例中，将“100”分配作为用于发送目录RDT的ALP分组的分组类型字段的值和用于发送离散RDT的ALP分组的分组类型字段的值，如图10和11中所示。
如果ALP分组的分组类型字段的值是“100”，则对应的ALP分组的报头还包括用于信令信息的附加报头，如图11中所示。图12图示用于信令信息的附加报头的语法结构的示例。在上面已经详细描述图10至图12，并且因此在此将会省略。
在一个实施例中，当同时发送目录RDT和离散RDT时，如果接收器正在改变频道，则接收器首先处理目录RDT。
在一个实施例中，当同时发送目录RDT和离散RDT时，如果接收器正在接收内容流，则接收器首先处理离散RDT。
为了执行此操作，接收器需要从离散RDT中识别目录RDT。
本公开建议用于从离散RDT中识别目录RDT的各种实施例。
第一实施例是使用用于ALP分组的ALP报头内的信令信息的附加报头的signaling_type字段的识别方法。即，如果在信令PLP中接收到的ALP分组的分组类型字段具有值“100”并且用于相应的ALP分组的信令信息的附加报头的signaling_type字段具有值0x02，则接收器识别递送到相应的ALP分组的有效载荷的表是目录RDT。如果在数据PLP中接收到的ALP分组的分组类型字段的值为“100”并且用于相应的ALP分组的信令信息的附加报头的signaling_type字段的值为0x02，则接收器识别递送到相应ALP分组的有效载荷的表是离散RDT。
第二实施例是一种用于使用用于ALP分组的ALP报头内的信令信息的附加报头的signaling_type_extension字段的方法。在本公开的一个实施例中，分配0x0000作为用于目录RDT的signaling_type_extension字段的值，并且分配0xFFFF作为用于离散RDT的signaling_type_extension字段的值。如果ALP分组的分组类型字段的值为“100”并且如图37中所示用于相应的ALP分组的信令信息的附加报头的signaling_type_extension字段的值为0x0000，则接收器识别递送到相应ALP分组的有效载荷的表是目录RDT。如果ALP分组的分组类型字段的值为“100”并且如图38中所示用于相应的ALP分组的信令信息的附加报头的signaling_type_extension字段的值为0xFFFF，则接收器识别递送到有效载荷的表是离散RDT。
第三实施例是一种如图39中所示的用于使用指示RDT的上下文信息的组合的context_config字段的方法。也就是说，在一个实施例中，如果在RDT中存在用于目录RDT的上下文信息，则将此字段设置为“0”。在一个实施例中，如果context_config字段具有值“0”，则在相应的循环中包括context_length字段和catalog_RDT_context()字段。
context_length字段指示catalog_RDT_context()字段的长度。
在一个实施例中，catalog_RDT_context()字段有必要包括static_chain_byte()。catalog_RDT_context()字段传送用于重置解压缩器的静态或动态信息。catalog_RDT_context()字段的大小和结构取决于上下文简档而变化。如果相应表中包括static_chain_byte()或dynamic_chain_byte()，则相应字段可以设置为“0x01”或“0x02”。如果相应表中同时包括static_chain_byte()和dynamic_chain_byte()，则相应字段可以设置为“0x03”。在自适应模式2的情况下，相应的表不包括dynamic_chain_byte()。在自适应模式3的情况下，相应的表可以包括dynamic_chain_byte()。
第四实施例是用于将RDT_type字段添加到RDT的方法，如图40中所示。RDT_type字段被分配有4个比特，并且指示相应RDT的类型。在本公开的一个实施例中，如图41中所示，如果RDT_type字段的值为0000，则相应的表被识别为目录RDT，并且如果RDT_type字段的值为0001，则相应的表被识别为离散RDT。
装置的内部组件可以是执行存储在存储器或其他硬件组件中的连续过程的处理器。这些可以位于装置的内部/外部。
在一些实施例中，上述模块可以被省略，或者可以由执行相同或相似操作的其他模块代替。
上述部件、模块或单元可以是执行存储在存储器(或存储单元)中的连续过程的处理器或硬件部件。可以通过处理器或硬件部件来执行上述实施例中描述的步骤。在上述实施例中描述的模块/块/单元可以作为硬件/处理器操作。另外，本发明提出的方法可以作为代码执行。这样的代码可以被写在处理器可读存储介质上，并且因此可以由装置所提供的处理器读取。
尽管为了便于描述已经参考单独的附图描述本发明，但是可以通过组合各自的附图中图示的实施例来实现新的实施例。如本领域的技术人员所需要的，设计其中记录有用于实现上述实施例的程序的计算机可读记录介质落入本发明的范围内。
根据本发明的装置和方法不限于应用于如前所述的实施例的构造和方法；相反，全部或一些实施例可以选择性地组合以实现各种修改。
同时，根据本说明书的方法可以被实现为可以被写在处理器可读记录介质上并因此被网络设备中设置的处理器读取的代码。处理器可读记录介质可以是其中以处理器可读方式存储数据的任何类型的记录设备。处理器可读记录介质可以包括例如只读存储器(ROM)、随机存取存储器(RAM)、紧凑光盘只读存储器(CD-ROM)、磁带、软盘和光学数据存储设备，并且可以以通过互联网发送的载波的形式实现。另外，处理器可读记录介质可以分布在连接到网络的多个计算机系统上，使得处理器可读代码以分散的方式被写入到其中并从中执行。
另外，将会显而易见的是，尽管在上面已经示出并描述优选实施例，但是本说明书不限于上述特定实施例，并且在不背离所附权利要求的要旨的情况下本发明所属的本领域的技术人员可以进行各种修改和变型。因此，旨在不应独立于本说明书的技术精神或前景来理解修改和变型。
本领域的技术人员将理解，在不脱离本发明的精神和基本特征的情况下，可以以不同于本文所述的其他特定方式来实施本发明。因此，本发明的范围应该由所附权利要求书及其合法的等效物来确定，而不是由以上描述来确定，并且落入所附权利要求书的含义和等同范围内的所有改变都旨在包含在其中。
另外，本说明书描述产品发明和方法发明两者，并且可以根据需要互补地应用这两个发明的描述。
实现本公开的模式
已经以用于实现本公开的优选实施方式描述各种实施例。
工业适用性
本公开用于一系列广播信号的领域。
对于本领域的技术人员而言将会显而易见的是，在不脱离本公开的精神和基本特征的情况下，可以对本公开进行各种修改和变型。因此，本公开的范围应由所附权利要求书及其合法等同物来确定，而不是由以上描述来确定，并且落入所附权利要求书的含义和等同范围内的所有改变都旨在被包含在其中。

Claims (8)

1.一种广播信号传输方法，包括：
互联网协议(IP)层处理步骤，所述互联网协议(IP)层处理步骤生成包括广播数据的IP分组，通过对所述IP分组中的至少一个IP分组进行分段来生成分段的IP分组，以及发送所述分段的IP分组和所述IP分组中的剩余IP分组；
链路层处理步骤，所述链路层处理步骤链路层处理所述分段的IP分组和所述剩余的IP分组，
其中，所述链路层处理步骤包括：
通过组合在所述IP层处理步骤输出的所述分段的IP分组来恢复所述至少一个IP分组；
通过稳健的报头压缩(RoHC)方案执行包括恢复的至少一个IP分组的所述IP分组的报头压缩来生成RoHC分组流，其中，所述RoHC分组流包括初始化刷新(IR)分组、IR动态(IR-DYN)分组以及压缩的分组，其中，所述IR分组包括静态信息和动态信息，以及其中所述IR-DYN分组包括动态信息；
从所述RoHC分组流的IR分组或所述IR-DYN分组的至少一个中提取上下文信息，并且生成RoHC-U描述表(RDT)，
其中，所述RDT包括上下文信息，所述上下文信息包括所述静态信息和所述动态信息中的至少一个，
其中，所述RDT进一步包括用于指示所述上下文信息的组合的上下文配置信息，
其中，当所述RDT包括所述静态信息时，所述上下文配置信息被设置为1，
其中，当所述RDT包括所述动态信息时，所述上下文配置信息被设置为2，
其中，当所述RDT包括所述静态信息和所述动态信息两者时，所述上下文配置信息被设置为3，以及
其中，取决于递送类型，所述RDT是目录RDT和离散RDT之一；以及
将从其提取所述上下文信息的所述RoHC分组流封装到第一链路层分组中以及将所述RDT封装到至少一个第二链路层分组；以及
物理层处理步骤，所述物理层处理步骤通过第一物理层管道(PLP)发送所述第一链路层分组，
其中，所述至少一个第二链路层分组包括通过不同于所述第一PLP的第二PLP发送的所述目录RDT，以及
其中，所述至少一个第二链路层分组包括通过携带第一链路层分组的所述第一PLP发送的所述离散RDT。
2.根据权利要求1所述的广播信号传输方法，其中，所述IP层处理步骤包括：如果所述至少一个IP分组的长度长于最大传输单元(MTU)，则将所述至少一个IP分组分割成分段并且通过向每个分段添加IP报头来生成分段的IP分组。
3.根据权利要求1所述的广播信号传输方法，其中，所述链路层处理步骤包括：收集所述分段的IP分组，并且通过基于被接收的所述IP分组的IP报头内的不分段(DF)标志、更多分段(MF)标志、标识字段、以及分段偏移字段组合所收集的分段的IP分组来恢复所述至少一个IP分组。
4.根据权利要求1所述的广播信号传输方法，其中，包括所述RDT的所述至少一个第二链路层分组的报头包括：用于信令信息的附加报头，并且其中所述附加报头包括用于指示被递送给所述至少一个第二链路层分组的有效载荷的信令表是所述RDT的信令类型信息。
5.一种广播信号传输设备，包括：
IP层的演播室，用于生成包括广播数据的互联网协议(IP)分组，通过对所述IP分组中的至少一个IP分组进行分段来生成分段的IP分组，以及发送所述分段的IP分组和所述IP分组中的剩余的IP分组；
链路层的广播网关，所述链路层的广播网关用于通过组合从所述演播室输出的所述分段的IP分组来恢复所述至少一个IP分组，通过RoHC方案执行包括恢复的至少一个IP分组的所述IP分组的报头压缩来生成RoHC分组流，
其中，所述RoHC分组流包括初始化刷新(IR)分组、IR动态(IR-DYN)分组以及压缩的分组，其中，所述IR分组包括静态信息和动态信息，以及其中所述IR-DYN分组包括动态信息；
其中所述广播网关进一步从所述RoHC分组流的IR分组或所述IR-DYN分组的至少一个中提取上下文信息，生成RDT，将从其提取所述上下文信息的所述RoHC分组流封装到第一链路层分组，以及将所述RDT封装到至少一个第二链路层分组；
其中，所述RDT包括所述上下文信息，所述上下文信息包括所述静态信息和所述动态信息中的至少一个，
其中，所述RDT进一步包括用于指示所述上下文信息的组合的上下文配置信息，
其中，当所述RDT包括所述静态信息时，所述上下文配置信息被设置为1，
其中，当所述RDT包括所述动态信息时，所述上下文配置信息被设置为2，
其中，当所述RDT包括所述静态信息和所述动态信息两者时，所述上下文配置信息被设置为3，以及
其中，取决于递送类型，所述RDT是目录RDT和离散RDT之一；以及
物理层的发射器，所述物理层的发射器用于通过第一PLP发送所述第一链路层分组，
其中，所述至少一个第二链路层分组包括通过不同于所述第一PLP的第二PLP发送的所述目录RDT，以及
其中，所述至少一个第二链路层分组包括通过携带第一链路层分组的所述第一PLP发送的所述离散RDT。
6.根据权利要求5所述的广播信号传输设备，其中，如果所述至少一个IP分组的长度长于最大传输单元(MTU)，则所述演播室将所述至少一个IP分组分割成分段，并且通过向每个分段添加IP报头来生成分段的IP分组。
7.根据权利要求5所述的广播信号传输设备，其中，所述广播网关收集所述分段的IP分组，并且通过基于被输入的所述IP分组的IP报头内的不分段(DF)标志、更多分段(MF)标志、标识字段、以及分段偏移字段组合所收集的分段的IP分组来恢复所述至少一个IP分组。
8.根据权利要求5所述的广播信号传输设备，其中，包括所述RDT的所述至少一个第二链路层分组的报头包括：用于信令信息的附加报头，并且其中所述附加报头包括用于指示被递送给所述至少一个第二链路层分组的有效载荷的信令表是所述RDT的信令类型信息。
CN201880072268.2A 2017-11-09 2018-11-09 广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法 Active CN111373759B (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762584109P 2017-11-09 2017-11-09
US62/584,109 2017-11-09
US201862614915P 2018-01-08 2018-01-08
US62/614,915 2018-01-08
PCT/KR2018/013655 WO2019093829A1 (ko) 2017-11-09 2018-11-09 방송 송신 장치, 방송 송신 방법, 방송 수신 장치 및 방송 수신 방법

Publications (2)

Publication Number Publication Date
CN111373759A CN111373759A (zh) 2020-07-03
CN111373759B true CN111373759B (zh) 2022-10-21

Family

ID=66439009

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880072268.2A Active CN111373759B (zh) 2017-11-09 2018-11-09 广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法

Country Status (5)

Country Link
US (2) US11277501B2 (zh)
KR (5) KR102640674B1 (zh)
CN (1) CN111373759B (zh)
MX (1) MX2020004441A (zh)
WO (1) WO2019093829A1 (zh)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020165229A1 (en) * 2019-02-14 2020-08-20 Sony Corporation Header compression adaptive to quality of radio channel
JP2021118467A (ja) * 2020-01-28 2021-08-10 ソニーセミコンダクタソリューションズ株式会社 情報処理装置、情報処理方法、並びにプログラム
US11924260B2 (en) * 2020-07-09 2024-03-05 Triveni Digital Inc. Secure television distribution over heterogeneous networks
US11343715B1 (en) * 2020-08-23 2022-05-24 Rockwell Collins, Inc. Header compression for network
WO2022239983A1 (ko) * 2021-05-12 2022-11-17 엘지전자 주식회사 멀티캐스트 신호 처리 방법 및 장치
WO2023003396A1 (ko) * 2021-07-22 2023-01-26 엘지전자 주식회사 멀티캐스트 신호 처리 방법 및 장치

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105379259A (zh) * 2013-07-11 2016-03-02 Lg电子株式会社 发送广播信号的方法、接收广播信号的方法、发送广播信号的设备以及接收广播信号的设备
CN106063280A (zh) * 2014-04-30 2016-10-26 Lg电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法以及接收广播信号的方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030081582A1 (en) 2001-10-25 2003-05-01 Nikhil Jain Aggregating multiple wireless communication channels for high data rate transfers
KR101366254B1 (ko) 2007-08-03 2014-02-20 삼성전자주식회사 방송망을 통하여 전송되는 ｉｐ 패킷의 압축 및 복원 방법
JP2009278364A (ja) * 2008-05-14 2009-11-26 Canon Inc パケット受信装置及びその処理方法
US9019990B2 (en) * 2012-07-13 2015-04-28 Telefonaktiebolaget L M Ericsson (Publ) Using encapsulation headers to indicate internet protocol packet fragmentation in cellular networks
CN105794174B (zh) * 2014-03-03 2019-06-21 Lg电子株式会社 用于发送/接收广播信号的设备和方法
US9356879B2 (en) 2014-05-22 2016-05-31 Dell Products L.P. Optimized path maximum transmission unit discovery
WO2015199468A1 (ko) * 2014-06-26 2015-12-30 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
JP6359680B2 (ja) * 2014-10-20 2018-07-18 エルジー エレクトロニクス インコーポレイティド 放送信号送信装置、放送信号受信装置、放送信号送信方法、及び放送信号受信方法
KR101764637B1 (ko) 2014-12-05 2017-08-14 엘지전자 주식회사 방송 신호 송신 방법, 방송 신호 송신 장치, 방송 신호 수신 방법 및 방송 신호 수신 장치
JP6301497B2 (ja) * 2014-12-10 2018-03-28 エルジー エレクトロニクス インコーポレイティド 放送信号伝送装置、及び放送信号伝送方法
WO2016148497A1 (ko) * 2015-03-16 2016-09-22 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016153241A1 (ko) * 2015-03-23 2016-09-29 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105379259A (zh) * 2013-07-11 2016-03-02 Lg电子株式会社 发送广播信号的方法、接收广播信号的方法、发送广播信号的设备以及接收广播信号的设备
CN106063280A (zh) * 2014-04-30 2016-10-26 Lg电子株式会社 发送广播信号的装置、接收广播信号的装置、发送广播信号的方法以及接收广播信号的方法

Also Published As

Publication number Publication date
US20220159107A1 (en) 2022-05-19
US20200336572A1 (en) 2020-10-22
CN111373759A (zh) 2020-07-03
KR102356784B1 (ko) 2022-02-08
US11799990B2 (en) 2023-10-24
KR102519917B1 (ko) 2023-04-10
WO2019093829A1 (ko) 2019-05-16
US11277501B2 (en) 2022-03-15
KR20200015732A (ko) 2020-02-12
KR20220017513A (ko) 2022-02-11
KR102418146B1 (ko) 2022-07-07
KR20210099200A (ko) 2021-08-11
MX2020004441A (es) 2020-08-06
KR20230049775A (ko) 2023-04-13
KR102288089B1 (ko) 2021-08-10
KR20220080021A (ko) 2022-06-14
KR102640674B1 (ko) 2024-02-27

Similar Documents

Publication Publication Date Title
CN111373759B (zh) 广播信号传输设备、广播信号传输方法、广播信号接收设备及广播信号接收方法
US11784860B2 (en) Broadcast signal transmitting/receiving device and method
KR102603460B1 (ko) 방송 신호 송신 장치, 방송 신호 송신 방법, 방송 신호 수신 장치 및 방송 수신 신호 방법
US11271791B2 (en) Method and apparatus for transmitting/receiving a broadcast signal
US11310770B2 (en) Broadcast signal transmission/reception device and method

Legal Events

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