WO2017010785A1 - Appareil et procédé d'émission et de réception de signal de radiodiffusion - Google Patents

Appareil et procédé d'émission et de réception de signal de radiodiffusion Download PDF

Info

Publication number
WO2017010785A1
WO2017010785A1 PCT/KR2016/007548 KR2016007548W WO2017010785A1 WO 2017010785 A1 WO2017010785 A1 WO 2017010785A1 KR 2016007548 W KR2016007548 W KR 2016007548W WO 2017010785 A1 WO2017010785 A1 WO 2017010785A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
service
wakeup
broadcast
signaling information
Prior art date
Application number
PCT/KR2016/007548
Other languages
English (en)
Korean (ko)
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 WO2017010785A1 publication Critical patent/WO2017010785A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to a broadcast signal transmitting apparatus, a broadcast signal receiving apparatus, a broadcast signal transmitting method, and a broadcast signal receiving method.
  • the digital broadcast signal may include a larger amount of video / audio data than the analog broadcast signal, and may further include various types of additional data as well as the video / audio data.
  • the digital broadcasting system may provide high definition (HD) images, multichannel audio, and various additional services.
  • HD high definition
  • data transmission efficiency for a large amount of data transmission, robustness of a transmission / reception network, and network flexibility in consideration of a mobile receiving device should be improved.
  • the present invention proposes a broadcast signal transmission method and a broadcast signal transmission apparatus.
  • a method for transmitting broadcast signals comprising: generating first level signaling information including information for discovery and acquisition of broadcast service data; Encoding the broadcast service data and the first level signaling information based on a delivery protocol, wherein the delivery protocol includes at least one of a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol. Including; Generating second level signaling information, wherein the second level signaling information includes information related to first signaling information and emergency alert (EA) for providing discovery of the first level signaling information and building a basic service list.
  • ROUTE Real-Time Object Delivery over Unidirectional Transport
  • MMT MPEG Media Transport
  • At least one of second signaling information for providing Encapsulating the broadcast service data, the first level signaling information, and the second level signaling information, respectively; User Datagram Protocol (UDP) / Internet Protocol (IP); And generating a signal frame by performing physical layer processing on the broadcast service data, the first level signaling information, and the second level signaling information.
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • the broadcast signal transmitter is a signaling generator for generating first level signaling information and second level signaling information for broadcast service data, wherein the first level signaling information is used for discovery and acquisition of the broadcast service data.
  • the second signaling information includes first signaling information for providing discovery of the first level signaling information and building a basic service list, and second information for providing information related to an Emergency Alert (EA).
  • EA Emergency Alert
  • a delivery layer encoder for encoding the broadcast service data and the first level signaling information based on a delivery protocol, wherein the delivery protocol is at least one of a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.
  • ROUTE Real-Time Object Delivery over Unidirectional Transport
  • MMT MPEG Media Transport
  • a UDP / IP encapsulator for encapsulating the broadcast service data, the first level signaling information, and the second level signaling information, respectively; User Datagram Protocol (UDP) / IP (Internet Protocol); And a physical layer processor configured to physically process the broadcast service data, the first level signaling information, and the second level signaling information to generate a signal frame.
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • the second signaling information of the second level signaling information includes identification information for an audio component for EA
  • the first level signaling information is an attribute of an attribute of the audio component having the identification information. It may include a first fragment containing information and a second fragment including location information on a location where the audio component having the identification information is delivered.
  • the property information may include at least one of mime type information, codec information, and language information for the audio component, and the location information may include at least one of IP information, port information, and TSI information for the audio component. It may include.
  • the attribute information may further include first extension information indicating that the audio component is a secondary audio component or second extension information indicating that the audio component is an audio component for an EA.
  • the (secondary) audio component may be an audio component different from the audio component constituting the linear service.
  • the signal frame includes third level signaling information
  • the third level signaling information includes a wakeup signal for providing wakeup information to a receiver, wherein the wakeup signal includes a 2-bit value. Can be.
  • the wakeup signal when the wakeup signal is' 00 ', the wakeup signal indicates that the wakeup information does not correspond to a wakeup call indicating a wakeup of the receiver, and the wakeup signal is' If not 00 ', the wakeup signal indicates that the wakeup information corresponds to a wakeup call indicating a wakeup of the receiver, and the wakeup signal is not' 00 'and is different from a previous wakeup signal.
  • the wakeup signal may indicate that the wakeup information corresponds to a new wakeup call.
  • the first signaling information of the second level signaling information includes service category information
  • the service category indicated by the service category information includes a linear A / V service, a linear audio only service, App-based services and EA services.
  • the second level signaling information may be carried in an IP packet having a predetermined address.
  • the present invention can provide various broadcast services by processing data according to service characteristics to control a quality of service (QoS) for each service or service component.
  • QoS quality of service
  • the present invention can achieve transmission flexibility by transmitting various broadcast services through the same radio frequency (RF) signal bandwidth.
  • RF radio frequency
  • the present invention it is possible to provide a broadcast signal transmission and reception method and apparatus capable of receiving a digital broadcast signal without errors even when using a mobile reception device or in an indoor environment.
  • the present invention can effectively support the next generation broadcast service in an environment supporting the next generation hybrid broadcast using the terrestrial broadcast network and the Internet network.
  • FIG. 1 is a diagram illustrating a protocol stack according to an embodiment of the present invention.
  • FIG. 2 is a diagram illustrating a service discovery process according to an embodiment of the present invention.
  • LLS low level signaling
  • SLT service list table
  • FIG. 4 illustrates a USBD and an S-TSID delivered to ROUTE according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating a USBD delivered to MMT according to an embodiment of the present invention.
  • FIG. 6 illustrates a link layer operation according to an embodiment of the present invention.
  • FIG. 7 illustrates a link mapping table (LMT) according to an embodiment of the present invention.
  • FIG. 8 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • FIG 9 illustrates a writing operation of a time interleaver according to an embodiment of the present invention.
  • FIG. 10 is a block diagram of an interleaving address generator composed of a main-PRBS generator and a sub-PRBS generator according to each FFT mode included in a frequency interleaver according to an embodiment of the present invention.
  • FIG. 11 illustrates a protocol stack of a broadcast system according to an embodiment of the present invention.
  • EAS Emergency Alert System
  • FIG. 13 (a) shows a hierarchical structure of an EAS according to an embodiment of the present invention.
  • FIG. 13 (b) shows a method for delivering EA information according to an embodiment of the present invention.
  • FIG. 14 illustrates a method of transmitting EA information using UDP / IP according to an embodiment of the present invention.
  • FIG 16 illustrates EA information according to an embodiment of the present invention.
  • FIG 17 illustrates an embodiment of signaling an embedded EA in EA information.
  • FIG. 18 illustrates an embodiment of signaling an EA transmitted in a separate session in EA information.
  • USBD syntax including EA information according to an embodiment of the present invention.
  • FIG. 20 illustrates a method for delivering a universal alert using EA information according to an embodiment of the present invention.
  • 21 illustrates a method for delivering an audio alert according to an embodiment of the present invention.
  • 22 illustrates a method of signaling secondary audio streaming for an audio alert according to an embodiment of the present invention.
  • 23 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • FIG. 24 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • 25 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • 26 illustrates a method of providing an EA related symbol icon according to an embodiment of the present invention.
  • FIG. 27 illustrates elements associated with an EA related symbol icon added to an extended CAP message according to an embodiment of the present invention.
  • 29 illustrates syntax of EA information according to another embodiment of the present invention.
  • FIG 30 illustrates syntax of EA information according to another embodiment of the present invention.
  • FIG. 31 illustrates a signaling structure of rich media content according to another embodiment of the present invention.
  • ENRT-IT EA related NRT information table
  • 35 illustrates a signaling structure of rich media content according to an embodiment of the present invention.
  • FIG. 36 illustrates a signaling structure of rich media content according to another embodiment of the present invention.
  • FIG. 37 is a diagram illustrating a wake-up information and EA information processing method of a broadcast receiver according to an embodiment of the present invention.
  • 39 illustrates an operation of a broadcast receiver according to wake up information according to another embodiment of the present invention.
  • FIG. 40 illustrates a broadcast signal transmission method according to an embodiment of the present invention.
  • 41 illustrates a broadcast signal transmitter and a broadcast signal receiver according to an embodiment of the present invention.
  • the present invention provides an apparatus and method for transmitting and receiving broadcast signals for next generation broadcast services.
  • the next generation broadcast service includes a terrestrial broadcast service, a mobile broadcast service, a UHDTV service, and the like.
  • a broadcast signal for a next generation broadcast service may be processed through a non-multiple input multiple output (MIMO) or MIMO scheme.
  • the non-MIMO scheme according to an embodiment of the present invention may include a multiple input single output (MISO) scheme, a single input single output (SISO) scheme, and the like.
  • MISO multiple input single output
  • SISO single input single output
  • the present invention proposes a physical profile (or system) that is optimized to minimize receiver complexity while achieving the performance required for a particular application.
  • FIG. 1 is a diagram illustrating a protocol stack according to an embodiment of the present invention.
  • the service may be delivered to the receiver through a plurality of layers.
  • the transmitting side can generate service data.
  • the delivery layer on the transmitting side performs processing for transmission to the service data, and the physical layer encodes it as a broadcast signal and transmits it through a broadcasting network or broadband.
  • the service data may be generated in a format according to ISO BMFF (base media file format).
  • the ISO BMFF media file may be used in broadcast network / broadband delivery, media encapsulation and / or synchronization format.
  • the service data is all data related to the service, and may include a concept including service components constituting the linear service, signaling information thereof, non real time (NRT) data, and other files.
  • the delivery layer will be described.
  • the delivery layer may provide a transmission function for service data.
  • the service data may be delivered through a broadcast network and / or broadband.
  • the first method may be to process service data into Media Processing Units (MPUs) based on MPEG Media Transport (MMT) and transmit the data using MMM protocol (MMTP).
  • MPUs Media Processing Units
  • MMT MPEG Media Transport
  • MMTP MMM protocol
  • the service data delivered through the MMTP may include service components for linear service and / or service signaling information thereof.
  • the second method may be to process service data into DASH segments based on MPEG DASH and transmit it using Real Time Object Delivery over Unidirectional Transport (ROUTE).
  • the service data delivered through the ROUTE protocol may include service components for the linear service, service signaling information and / or NRT data thereof. That is, non-timed data such as NRT data and files may be delivered through ROUTE.
  • Data processed according to the MMTP or ROUTE protocol may be processed into IP packets via the UDP / IP layer.
  • a service list table (SLT) may also be transmitted through a broadcasting network through a UDP / IP layer.
  • the SLT may be included in the LLS (Low Level Signaling) table and transmitted. The SLT and the LLS table will be described later.
  • IP packets may be treated as link layer packets at the link layer.
  • the link layer may encapsulate data of various formats delivered from an upper layer into a link layer packet and then deliver the data to the physical layer. The link layer will be described later.
  • At least one or more service elements may be delivered via a broadband path.
  • the data transmitted through the broadband may include service components in a DASH format, service signaling information and / or NRT data thereof. This data can be processed via HTTP / TCP / IP, passed through the link layer for broadband transmission, and delivered to the physical layer for broadband transmission.
  • the physical layer may process data received from a delivery layer (upper layer and / or link layer) and transmit the data through a broadcast network or a broadband. Details of the physical layer will be described later.
  • the service may be a collection of service components that are shown to the user as a whole, the components may be of different media types, the service may be continuous or intermittent, the service may be real time or non-real time, and the real time service may be a sequence of TV programs. It can be configured as.
  • the service may be a linear audio / video or audio only service that may have app-based enhancements.
  • the service may be an app-based service whose reproduction / configuration is controlled by the downloaded application.
  • the service may be an ESG service that provides an electronic service guide (ESG).
  • ESG electronic service guide
  • EA Emergency Alert
  • the service component may be delivered by (1) one or more ROUTE sessions or (2) one or more MMTP sessions.
  • the service component When a linear service with app-based enhancement is delivered through a broadcast network, the service component may be delivered by (1) one or more ROUTE sessions and (2) zero or more MMTP sessions.
  • data used for app-based enhancement may be delivered through a ROUTE session in the form of NRT data or other files.
  • linear service components (streaming media components) of one service may not be allowed to be delivered using both protocols simultaneously.
  • the service component may be delivered by one or more ROUTE sessions.
  • the service data used for the app-based service may be delivered through a ROUTE session in the form of NRT data or other files.
  • some service components or some NRT data, files, etc. of these services may be delivered via broadband (hybrid service delivery).
  • the linear service components of one service may be delivered through the MMT protocol.
  • the linear service components of one service may be delivered via a ROUTE protocol.
  • the linear service component and NRT data (NRT service component) of one service may be delivered through the ROUTE protocol.
  • linear service components of one service may be delivered through the MMT protocol, and NRT data (NRT service components) may be delivered through the ROUTE protocol.
  • some service component or some NRT data of a service may be delivered over broadband.
  • the data related to the app-based service or the app-based enhancement may be transmitted through a broadcast network according to ROUTE or through broadband in the form of NRT data.
  • NRT data may also be referred to as locally cashed data.
  • Each ROUTE session includes one or more LCT sessions that deliver, in whole or in part, the content components that make up the service.
  • an LCT session may deliver an individual component of a user service, such as an audio, video, or closed caption stream.
  • Streaming media is formatted into a DASH segment.
  • Each MMTP session includes one or more MMTP packet flows carrying an MMT signaling message or all or some content components.
  • the MMTP packet flow may carry a component formatted with an MMT signaling message or an MPU.
  • an LCT session For delivery of NRT user service or system metadata, an LCT session carries a file based content item.
  • These content files may consist of continuous (timed) or discrete (non-timed) media components of an NRT service, or metadata such as service signaling or ESG fragments.
  • Delivery of system metadata, such as service signaling or ESG fragments, can also be accomplished through the signaling message mode of the MMTP.
  • the tuner can scan frequencies and detect broadcast signals at specific frequencies.
  • the receiver can extract the SLT and send it to the module that processes it.
  • the SLT parser can parse the SLT, obtain data, and store it in the channel map.
  • the receiver may acquire bootstrap information of the SLT and deliver it to the ROUTE or MMT client. This allows the receiver to obtain and store the SLS. USBD or the like can be obtained, which can be parsed by the signaling parser.
  • FIG. 2 is a diagram illustrating a service discovery process according to an embodiment of the present invention.
  • the broadcast stream delivered by the broadcast signal frame of the physical layer may carry LLS (Low Level Signaling).
  • LLS data may be carried through the payload of an IP packet delivered to a well known IP address / port. This LLS may contain an SLT depending on its type.
  • LLS data may be formatted in the form of an LLS table. The first byte of every UDP / IP packet carrying LLS data may be the beginning of the LLS table. Unlike the illustrated embodiment, the IP stream carrying LLS data may be delivered to the same PLP along with other service data.
  • the SLT enables the receiver to generate a service list through a fast channel scan and provides access information for locating the SLS.
  • the SLT includes bootstrap information, which enables the receiver to obtain Service Layer Signaling (SLS) for each service.
  • SLS Service Layer Signaling
  • the bootstrap information may include destination IP address and destination port information of the ROUTE session including the LCT channel carrying the SLS and the LCT channel.
  • the bootstrap information may include a destination IP address and destination port information of the MMTP session carrying the SLS.
  • the SLS of service # 1 described by the SLT is delivered via ROUTE, and the SLT includes bootstrap information (sIP1, dIP1, dPort1) for the ROUTE session including the LCT channel to which the SLS is delivered. can do.
  • SLS of service # 2 described by the SLT is delivered through MMT, and the SLT may include bootstrap information (sIP2, dIP2, and dPort2) for an MMTP session including an MMTP packet flow through which the SLS is delivered.
  • the SLS is signaling information describing characteristics of a corresponding service and may include information for acquiring a corresponding service and a service component of the corresponding service, or may include receiver capability information for reproducing the corresponding service significantly. Having separate service signaling for each service allows the receiver to obtain the appropriate SLS for the desired service without having to parse the entire SLS delivered in the broadcast stream.
  • the SLS When the SLS is delivered through the ROUTE protocol, the SLS may be delivered through a dedicated LCT channel of a ROUTE session indicated by the SLT.
  • the SLS may include a user service bundle description (USBD / USD), a service-based transport session instance description (S-TSID), and / or a media presentation description (MPD).
  • USBD / USD user service bundle description
  • S-TSID service-based transport session instance description
  • MPD media presentation description
  • USBD to USD is one of the SLS fragments and may serve as a signaling hub for describing specific technical information of a service.
  • the USBD may include service identification information, device capability information, and the like.
  • the USBD may include reference information (URI reference) to other SLS fragments (S-TSID, MPD, etc.). That is, USBD / USD can refer to S-TSID and MPD respectively.
  • the USBD may further include metadata information that enables the receiver to determine the transmission mode (broadcast network / broadband). Details of the USBD / USD will be described later.
  • the S-TSID is one of the SLS fragments, and may provide overall session description information for a transport session carrying a service component of a corresponding service.
  • the S-TSID may provide transport session description information for the ROUTE session to which the service component of the corresponding service is delivered and / or the LCT channel of the ROUTE sessions.
  • the S-TSID may provide component acquisition information of service components related to one service.
  • the S-TSID may provide a mapping between the DASH Representation of the MPD and the tsi of the corresponding service component.
  • the component acquisition information of the S-TSID may be provided in the form of tsi, an identifier of an associated DASH representation, and may or may not include a PLP ID according to an embodiment.
  • the component acquisition information enables the receiver to collect audio / video components of a service and to buffer, decode, and the like of DASH media segments.
  • the S-TSID may be referenced by the USBD as described above. Details of the S-TSID will be described later.
  • the MPD is one of the SLS fragments and may provide a description of the DASH media presentation of the service.
  • the MPD may provide a resource identifier for the media segments and may provide contextual information within the media presentation for the identified resources.
  • the MPD may describe the DASH representation (service component) delivered through the broadcast network, and may also describe additional DASH representations delivered through the broadband (hybrid delivery).
  • the MPD may be referenced by the USBD as described above.
  • the SLS When the SLS is delivered through the MMT protocol, the SLS may be delivered through a dedicated MMTP packet flow of an MMTP session indicated by the SLT.
  • packet_id of MMTP packets carrying SLS may have a value of 00.
  • the SLS may include a USBD / USD and / or MMT Package (MP) table.
  • USBD is one of the SLS fragments, and may describe specific technical information of a service like that in ROUTE.
  • the USBD here may also include reference information (URI reference) to other SLS fragments.
  • the USBD of the MMT may refer to the MP table of the MMT signaling.
  • the USBD of the MMT may also include reference information on the S-TSID and / or the MPD.
  • the S-TSID may be for NRT data transmitted through the ROUTE protocol. This is because NRT data can be delivered through the ROUTE protocol even when the linear service component is delivered through the MMT protocol.
  • MPD may be for a service component delivered over broadband in hybrid service delivery. Details of the USBD of the MMT will be described later.
  • the MP table is a signaling message of the MMT for MPU components and may provide overall session description information for an MMTP session carrying a service component of a corresponding service.
  • the MP table may also contain descriptions for assets delivered via this MMTP session.
  • the MP table is streaming signaling information for MPU components, and may provide a list of assets corresponding to one service and location information (component acquisition information) of these components. Specific contents of the MP table may be in a form defined in MMT or a form in which modifications are made.
  • Asset is a multimedia data entity, which may mean a data entity associated with one unique ID and used to generate one multimedia presentation. Asset may correspond to a service component constituting a service.
  • the MP table may be used to access a streaming service component (MPU) corresponding to a desired service.
  • the MP table may be referenced by the USBD as described above.
  • MMT signaling messages may be defined. Such MMT signaling messages may describe additional information related to the MMTP session or service.
  • ROUTE sessions are identified by source IP address, destination IP address, and destination port number.
  • the LCT session is identified by a transport session identifier (TSI) that is unique within the scope of the parent ROUTE session.
  • MMTP sessions are identified by destination IP address and destination port number.
  • the MMTP packet flow is identified by a unique packet_id within the scope of the parent MMTP session.
  • the S-TSID, the USBD / USD, the MPD, or the LCT session carrying them may be called a service signaling channel.
  • the S-TSID, the USBD / USD, the MPD, or the LCT session carrying them may be called a service signaling channel.
  • the S-TSID, the USBD / USD, the MPD, or the LCT session carrying them may be called a service signaling channel.
  • the MMT signaling messages or packet flow carrying them may be called a service signaling channel.
  • one ROUTE or MMTP session may be delivered through a plurality of PLPs. That is, one service may be delivered through one or more PLPs. Unlike shown, components constituting one service may be delivered through different ROUTE sessions. In addition, according to an embodiment, components constituting one service may be delivered through different MMTP sessions. According to an embodiment, components constituting one service may be delivered divided into a ROUTE session and an MMTP session. Although not shown, a component constituting one service may be delivered through a broadband (hybrid delivery).
  • LLS low level signaling
  • SLT service list table
  • An embodiment t3010 of the illustrated LLS table may include information according to an LLS_table_id field, a provider_id field, an LLS_table_version field, and / or an LLS_table_id field.
  • the LLS_table_id field may identify a type of the corresponding LLS table, and the provider_id field may identify service providers related to services signaled by the corresponding LLS table.
  • the service provider is a broadcaster using all or part of the broadcast stream, and the provider_id field may identify one of a plurality of broadcasters using the broadcast stream.
  • the LLS_table_version field may provide version information of a corresponding LLS table.
  • the corresponding LLS table includes the above-described SLT, a rating region table (RRT) including information related to a content advisory rating, a SystemTime information providing information related to system time, and an emergency alert. It may include one of the CAP (Common Alert Protocol) message that provides information related to. According to an embodiment, other information other than these may be included in the LLS table.
  • RRT rating region table
  • CAP Common Alert Protocol
  • One embodiment t3020 of the illustrated SLT may include an @bsid attribute, an @sltCapabilities attribute, a sltInetUrl element, and / or a Service element.
  • Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.
  • the @bsid attribute may be an identifier of a broadcast stream.
  • the @sltCapabilities attribute can provide the capability information required to decode and significantly reproduce all services described by the SLT.
  • the sltInetUrl element may provide base URL information used to obtain ESG or service signaling information for services of the corresponding SLT through broadband.
  • the sltInetUrl element may further include an @urlType attribute, which may indicate the type of data that can be obtained through the URL.
  • the service element may be an element including information on services described by the corresponding SLT, and a service element may exist for each service.
  • the Service element contains the @serviceId property, the @sltSvcSeqNum property, the @protected property, the @majorChannelNo property, the @minorChannelNo property, the @serviceCategory property, the @shortServiceName property, the @hidden property, the @broadbandAccessRequired property, the @svcCapabilities property, the BroadcastSvcSignaling element, and / or the svcInetUrl element. It may include.
  • the @serviceId attribute may be an identifier of a corresponding service, and the @sltSvcSeqNum attribute may indicate a sequence number of SLT information for the corresponding service.
  • the @protected attribute may indicate whether at least one service component necessary for meaningful playback of the corresponding service is protected.
  • the @majorChannelNo and @minorChannelNo attributes may indicate the major channel number and the minor channel number of the corresponding service, respectively.
  • the @serviceCategory attribute can indicate the category of the corresponding service.
  • the service category may include a linear A / V service, a linear audio service, an app-based service, an ESG service, and an EAS service.
  • the @shortServiceName attribute may provide a short name of the corresponding service.
  • the @hidden attribute can indicate whether the service is for testing or proprietary use.
  • the @broadbandAccessRequired attribute may indicate whether broadband access is required for meaningful playback of the corresponding service.
  • the @svcCapabilities attribute can provide the capability information necessary for decoding and meaningful reproduction of the corresponding service.
  • the BroadcastSvcSignaling element may provide information related to broadcast signaling of a corresponding service. This element may provide information such as a location, a protocol, and an address with respect to signaling through a broadcasting network of a corresponding service. Details will be described later.
  • the svcInetUrl element may provide URL information for accessing signaling information for a corresponding service through broadband.
  • the sltInetUrl element may further include an @urlType attribute, which may indicate the type of data that can be obtained through the URL.
  • the aforementioned BroadcastSvcSignaling element may include an @slsProtocol attribute, an @slsMajorProtocolVersion attribute, an @slsMinorProtocolVersion attribute, an @slsPlpId attribute, an @slsDestinationIpAddress attribute, an @slsDestinationUdpPort attribute, and / or an @slsSourceIpAddress attribute.
  • the @slsProtocol attribute can indicate the protocol used to deliver the SLS of the service (ROUTE, MMT, etc.).
  • the @slsMajorProtocolVersion attribute and @slsMinorProtocolVersion attribute may indicate the major version number and the minor version number of the protocol used to deliver the SLS of the corresponding service, respectively.
  • the @slsPlpId attribute may provide a PLP identifier for identifying a PLP that delivers the SLS of the corresponding service.
  • this field may be omitted, and the PLP information to which the SLS is delivered may be identified by combining information in the LMT to be described later and bootstrap information of the SLT.
  • the @slsDestinationIpAddress attribute, @slsDestinationUdpPort attribute, and @slsSourceIpAddress attribute may indicate the destination IP address, the destination UDP port, and the source IP address of the transport packet carrying the SLS of the corresponding service, respectively. They can identify the transport session (ROUTE session or MMTP session) to which the SLS is delivered. These may be included in the bootstrap information.
  • FIG. 4 illustrates a USBD and an S-TSID delivered to ROUTE according to an embodiment of the present invention.
  • One embodiment t4010 of the illustrated USBD may have a bundleDescription root element.
  • the bundleDescription root element may have a userServiceDescription element.
  • the userServiceDescription element may be an instance of one service.
  • the userServiceDescription element may include an @globalServiceID attribute, an @serviceId attribute, an @serviceStatus attribute, an @fullMPDUri attribute, an @sTSIDUri attribute, a name element, a serviceLanguage element, a capabilityCode element, and / or a deliveryMethod element.
  • Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.
  • the @globalServiceID attribute is a globally unique identifier of the service and can be used to link with ESG data (Service @ globalServiceID).
  • the @serviceId attribute is a reference corresponding to the corresponding service entry of the SLT and may be the same as service ID information of the SLT.
  • the @serviceStatus attribute may indicate the status of the corresponding service. This field may indicate whether the corresponding service is active or inactive.
  • the @fullMPDUri attribute can refer to the MPD fragment of the service. As described above, the MPD may provide a reproduction description for a service component delivered through a broadcast network or a broadband.
  • the @sTSIDUri attribute may refer to the S-TSID fragment of the service.
  • the S-TSID may provide parameters related to access to the transport session carrying the service as described above.
  • the name element may provide the name of the service.
  • This element may further include an @lang attribute, which may indicate the language of the name provided by the name element.
  • the serviceLanguage element may indicate the available languages of the service. That is, this element may list the languages in which the service can be provided.
  • the capabilityCode element may indicate capability or capability group information of the receiver side necessary for significantly playing a corresponding service. This information may be compatible with the capability information format provided by the service announcement.
  • the deliveryMethod element may provide delivery related information with respect to contents accessed through a broadcasting network or a broadband of a corresponding service.
  • the deliveryMethod element may include a broadcastAppService element and / or a unicastAppService element. Each of these elements may have a basePattern element as its child element.
  • the broadcastAppService element may include transmission related information on the DASH presentation delivered through the broadcast network.
  • These DASH representations may include media components across all periods of the service media presentation.
  • the basePattern element of this element may represent a character pattern used by the receiver to match the segment URL. This can be used by the DASH client to request segments of the representation. Matching may imply that the media segment is delivered over the broadcast network.
  • the unicastAppService element may include transmission related information on the DASH representation delivered through broadband. These DASH representations may include media components across all periods of the service media presentation.
  • the basePattern element of this element may represent a character pattern used by the receiver to match the segment URL. This can be used by the DASH client to request segments of the representation. Matching may imply that the media segment is delivered over broadband.
  • An embodiment t4020 of the illustrated S-TSID may have an S-TSID root element.
  • the S-TSID root element may include an @serviceId attribute and / or an RS element.
  • Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.
  • the @serviceId attribute is an identifier of a corresponding service and may refer to a corresponding service of USBD / USD.
  • the RS element may describe information on ROUTE sessions through which service components of a corresponding service are delivered. Depending on the number of such ROUTE sessions, there may be a plurality of these elements.
  • the RS element may further include an @bsid attribute, an @sIpAddr attribute, an @dIpAddr attribute, an @dport attribute, an @PLPID attribute, and / or an LS element.
  • the @bsid attribute may be an identifier of a broadcast stream through which service components of a corresponding service are delivered. If this field is omitted, the default broadcast stream may be a broadcast stream that includes a PLP that carries the SLS of the service. The value of this field may be the same value as the @bsid attribute of SLT.
  • the @sIpAddr attribute, the @dIpAddr attribute, and the @dport attribute may indicate a source IP address, a destination IP address, and a destination UDP port of the corresponding ROUTE session, respectively. If these fields are omitted, the default values may be the source IP address, destination IP address, and destination UDP port values of the current, ROUTE session carrying that SLS, that is, carrying that S-TSID. For other ROUTE sessions that carry service components of the service but not the current ROUTE session, these fields may not be omitted.
  • the @PLPID attribute may indicate PLP ID information of a corresponding ROUTE session. If this field is omitted, the default value may be the PLP ID value of the current PLP to which the corresponding S-TSID is being delivered. According to an embodiment, this field is omitted, and the PLP ID information of the corresponding ROUTE session may be confirmed by combining information in the LMT to be described later and IP address / UDP port information of the RS element.
  • the LS element may describe information on LCT channels through which service components of a corresponding service are delivered. Depending on the number of such LCT channels, there may be a plurality of these elements.
  • the LS element may include an @tsi attribute, an @PLPID attribute, an @bw attribute, an @startTime attribute, an @endTime attribute, an SrcFlow element, and / or a RepairFlow element.
  • the @tsi attribute may represent tsi information of a corresponding LCT channel. Through this, LCT channels through which a service component of a corresponding service is delivered may be identified.
  • the @PLPID attribute may represent PLP ID information of a corresponding LCT channel. In some embodiments, this field may be omitted.
  • the @bw attribute may indicate the maximum bandwidth of the corresponding LCT channel.
  • the @startTime attribute may indicate the start time of the LCT session, and the @endTime attribute may indicate the end time of the LCT channel.
  • the SrcFlow element may describe the source flow of ROUTE.
  • the source protocol of ROUTE is used to transmit the delivery object, and can establish at least one source flow in one ROUTE session. These source flows can deliver related objects as an object flow.
  • the RepairFlow element may describe the repair flow of ROUTE. Delivery objects delivered according to the source protocol may be protected according to Forward Error Correction (FEC).
  • FEC Forward Error Correction
  • the repair protocol may define a FEC framework that enables such FEC protection.
  • FIG. 5 is a diagram illustrating a USBD delivered to MMT according to an embodiment of the present invention.
  • One embodiment of the illustrated USBD may have a bundleDescription root element.
  • the bundleDescription root element may have a userServiceDescription element.
  • the userServiceDescription element may be an instance of one service.
  • the userServiceDescription element may include an @globalServiceID attribute, an @serviceId attribute, a Name element, a serviceLanguage element, a content advisoryRating element, a Channel element, an mpuComponent element, a routeComponent element, a broadbandComponent element, and / or a ComponentInfo element.
  • Each field may be omitted or may exist in plurality, depending on the value of the illustrated Use column.
  • the @globalServiceID attribute, the @serviceId attribute, the Name element and / or the serviceLanguage element may be the same as the corresponding fields of the USBD delivered to the above-described ROUTE.
  • the contentAdvisoryRating element may indicate the content advisory rating of the corresponding service. This information may be compatible with the content advisory rating information format provided by the service announcement.
  • the channel element may include information related to the corresponding service. The detail of this element is mentioned later.
  • the mpuComponent element may provide a description for service components delivered as an MPU of a corresponding service.
  • This element may further include an @mmtPackageId attribute and / or an @nextMmtPackageId attribute.
  • the @mmtPackageId attribute may refer to an MMT package of service components delivered as an MPU of a corresponding service.
  • the @nextMmtPackageId attribute may refer to an MMT package to be used next to the MMT package referenced by the @mmtPackageId attribute in time.
  • the MP table can be referenced through the information of this element.
  • the routeComponent element may include a description of service components of the corresponding service delivered to ROUTE. Even if the linear service components are delivered in the MMT protocol, the NRT data may be delivered according to the ROUTE protocol as described above. This element may describe information about such NRT data. The detail of this element is mentioned later.
  • the broadbandComponent element may include a description of service components of the corresponding service delivered over broadband.
  • some service components or other files of a service may be delivered over broadband. This element may describe information about these data.
  • This element may further include the @fullMPDUri attribute. This attribute may refer to an MPD that describes service components delivered over broadband.
  • the element when the broadcast signal is weakened due to driving in a tunnel or the like, the element may be needed to support handoff between the broadcast network and the broadband band. When the broadcast signal is weakened, while acquiring the service component through broadband, and when the broadcast signal is stronger, the service continuity may be guaranteed by acquiring the service component through the broadcast network.
  • the ComponentInfo element may include information on service components of a corresponding service. Depending on the number of service components of the service, there may be a plurality of these elements. This element may describe information such as the type, role, name, identifier, and protection of each service component. Detailed information on this element will be described later.
  • the aforementioned channel element may further include an @serviceGenre attribute, an @serviceIcon attribute, and / or a ServiceDescription element.
  • the @serviceGenre attribute may indicate the genre of the corresponding service
  • the @serviceIcon attribute may include URL information of an icon representing the corresponding service.
  • the ServiceDescription element provides a service description of the service, which may further include an @serviceDescrText attribute and / or an @serviceDescrLang attribute. Each of these attributes may indicate the text of the service description and the language used for that text.
  • the aforementioned routeComponent element may further include an @sTSIDUri attribute, an @sTSIDDestinationIpAddress attribute, an @sTSIDDestinationUdpPort attribute, an @sTSIDSourceIpAddress attribute, an @sTSIDMajorProtocolVersion attribute, and / or an @sTSIDMinorProtocolVersion attribute.
  • the @sTSIDUri attribute may refer to an S-TSID fragment. This field may be the same as the corresponding field of USBD delivered to ROUTE described above. This S-TSID may provide access related information for service components delivered in ROUTE. This S-TSID may exist for NRT data delivered according to the ROUTE protocol in the situation where linear service components are delivered according to the MMT protocol.
  • the @sTSIDDestinationIpAddress attribute, the @sTSIDDestinationUdpPort attribute, and the @sTSIDSourceIpAddress attribute may indicate a destination IP address, a destination UDP port, and a source IP address of a transport packet carrying the aforementioned S-TSID, respectively. That is, these fields may identify a transport session (MMTP session or ROUTE session) carrying the aforementioned S-TSID.
  • the @sTSIDMajorProtocolVersion attribute and the @sTSIDMinorProtocolVersion attribute may indicate a major version number and a minor version number of the transport protocol used to deliver the aforementioned S-TSID.
  • ComponentInfo element may further include an @componentType attribute, an @componentRole attribute, an @componentProtectedFlag attribute, an @componentId attribute, and / or an @componentName attribute.
  • the @componentType attribute may indicate the type of the corresponding component. For example, this property may indicate whether the corresponding component is an audio, video, or closed caption component.
  • the @componentRole attribute can indicate the role (role) of the corresponding component. For example, this property can indicate whether the main audio, music, commentary, etc., if the corresponding component is an audio component. If the corresponding component is a video component, it may indicate whether it is primary video. If the corresponding component is a closed caption component, it may indicate whether it is a normal caption or an easy reader type.
  • the @componentProtectedFlag attribute may indicate whether a corresponding service component is protected, for example, encrypted.
  • the @componentId attribute may represent an identifier of a corresponding service component.
  • the value of this attribute may be a value such as asset_id (asset ID) of the MP table corresponding to this service component.
  • the @componentName attribute may represent the name of the corresponding service component.
  • FIG. 6 illustrates a link layer operation according to an embodiment of the present invention.
  • the link layer may be a layer between the physical layer and the network layer.
  • the transmitter may transmit data from the network layer to the physical layer
  • the receiver may transmit data from the physical layer to the network layer (t6010).
  • the purpose of the link layer may be to compress all input packet types into one format for processing by the physical layer, to ensure flexibility and future scalability for input packet types not yet defined. have.
  • the link layer may provide an option of compressing unnecessary information in the header of the input packet, so that the input data may be efficiently transmitted. Operations such as overhead reduction and encapsulation of the link layer may be referred to as a link layer protocol, and a packet generated using the corresponding protocol may be referred to as a link layer packet.
  • the link layer may perform functions such as packet encapsulation, overhead reduction, and / or signaling transmission.
  • the link layer ALP may perform an overhead reduction process on input packets and then encapsulate them into link layer packets.
  • the link layer may encapsulate the link layer packet without performing an overhead reduction process.
  • the use of the link layer protocol can greatly reduce the overhead for data transmission on the physical layer, and the link layer protocol according to the present invention can provide IP overhead reduction and / or MPEG-2 TS overhead reduction. have.
  • the link layer may sequentially perform IP header compression, adaptation, and / or encapsulation. In some embodiments, some processes may be omitted.
  • the RoHC module performs IP packet header compression to reduce unnecessary overhead, and context information may be extracted and transmitted out of band through an adaptation process.
  • the IP header compression and adaptation process may be collectively called IP header compression.
  • IP packets may be encapsulated into link layer packets through an encapsulation process.
  • the link layer may sequentially perform an overhead reduction and / or encapsulation process for the TS packet. In some embodiments, some processes may be omitted.
  • the link layer may provide sync byte removal, null packet deletion and / or common header removal (compression).
  • Sync byte elimination can provide overhead reduction of 1 byte per TS packet. Null packet deletion can be performed in a manner that can be reinserted at the receiving end. In addition, common information between successive headers can be deleted (compressed) in a manner that can be recovered at the receiving side. Some of each overhead reduction process may be omitted. Thereafter, TS packets may be encapsulated into link layer packets through an encapsulation process.
  • the link layer packet structure for encapsulation of TS packets may be different from other types of packets.
  • IP header compression will be described.
  • the IP packet has a fixed header format, but some information required in a communication environment may be unnecessary in a broadcast environment.
  • the link layer protocol may provide a mechanism to reduce broadcast overhead by compressing the header of the IP packet.
  • IP header compression may include a header compressor / decompressor and / or adaptation module.
  • the IP header compressor (RoHC compressor) may reduce the size of each IP packet header based on the RoHC scheme.
  • the adaptation module may then extract the context information and generate signaling information from each packet stream.
  • the receiver may parse signaling information related to the packet stream and attach context information to the packet stream.
  • the RoHC decompressor can reconstruct the original IP packet by recovering the packet header.
  • IP header compression may mean only IP header compression by a header compressor, or may mean a concept in which the IP header compression and the adaptation process by the adaptation module are combined. The same is true for decompressing.
  • the adaptation function may generate link layer signaling using context information and / or configuration parameters.
  • the adaptation function may periodically send link layer signaling over each physical frame using previous configuration parameters and / or context information.
  • the context information is extracted from the compressed IP packets, and various methods may be used according to the adaptation mode.
  • Mode # 1 is a mode in which no operation is performed on the compressed packet stream, and may be a mode in which the adaptation module operates as a buffer.
  • Mode # 2 may be a mode for extracting context information (static chain) by detecting IR packets in the compressed packet stream. After extraction, the IR packet is converted into an IR-DYN packet, and the IR-DYN packet can be transmitted in the same order in the packet stream by replacing the original IR packet.
  • context information static chain
  • Mode # 3 t6020 may be a mode for detecting IR and IR-DYN packets and extracting context information from the compressed packet stream.
  • Static chains and dynamic chains can be extracted from IR packets and dynamic chains can be extracted from IR-DYN packets.
  • the IR and IR-DYN packets can be converted into regular compressed packets.
  • the switched packets can be sent in the same order within the packet stream, replacing the original IR and IR-DYN packets.
  • the remaining packets after the context information is extracted may be encapsulated and transmitted according to the link layer packet structure for the compressed IP packet.
  • the context information may be transmitted by being encapsulated according to a link layer packet structure for signaling information as link layer signaling.
  • the extracted context information may be included in the RoHC-U Description Table (RTT) and transmitted separately from the RoHC packet flow.
  • the context information may be transmitted through a specific physical data path along with other signaling information.
  • a specific physical data path may mean one of general PLPs, a PLP to which LLS (Low Level Signaling) is delivered, a dedicated PLP, or an L1 signaling path. path).
  • the RDT may be signaling information including context information (static chain and / or dynamic chain) and / or information related to header compression.
  • the RDT may be transmitted whenever the context information changes.
  • the RDT may be transmitted in every physical frame. In order to transmit the RDT in every physical frame, a previous RDT may be re-use.
  • the receiver may first select PLP to acquire signaling information such as SLT, RDT, LMT, and the like. When the signaling information is obtained, the receiver may combine these to obtain a mapping between the service-IP information-context information-PLP. That is, the receiver can know which service is transmitted to which IP streams, which IP streams are delivered to which PLP, and can also obtain corresponding context information of the PLPs. The receiver can select and decode a PLP carrying a particular packet stream. The adaptation module can parse the context information and merge it with the compressed packets. This allows the packet stream to be recovered, which can be delivered to the RoHC decompressor. Decompression can then begin.
  • signaling information such as SLT, RDT, LMT, and the like.
  • the receiver may combine these to obtain a mapping between the service-IP information-context information-PLP. That is, the receiver can know which service is transmitted to which IP streams, which IP streams are delivered to which PLP, and can also obtain corresponding context information of the PLPs.
  • the receiver detects the IR packet and starts decompression from the first received IR packet according to the adaptation mode (mode 1), or detects the IR-DYN packet to perform decompression from the first received IR-DYN packet.
  • the link layer protocol may encapsulate all types of input packets, such as IP packets and TS packets, into link layer packets. This allows the physical layer to process only one packet format independently of the protocol type of the network layer (here, consider MPEG-2 TS packet as a kind of network layer packet). Each network layer packet or input packet is transformed into a payload of a generic link layer packet.
  • Segmentation may be utilized in the packet encapsulation process. If the network layer packet is too large to be processed by the physical layer, the network layer packet may be divided into two or more segments.
  • the link layer packet header may include fields for performing division at the transmitting side and recombination at the receiving side. Each segment may be encapsulated into a link layer packet in the same order as the original position.
  • Concatenation may also be utilized in the packet encapsulation process. If the network layer packet is small enough that the payload of the link layer packet includes several network layer packets, concatenation may be performed.
  • the link layer packet header may include fields for executing concatenation. In the case of concatenation, each input packet may be encapsulated into the payload of the link layer packet in the same order as the original input order.
  • the link layer packet may include a header and a payload, and the header may include a base header, an additional header, and / or an optional header.
  • the additional header may be added depending on the chaining or splitting, and the additional header may include necessary fields according to the situation.
  • an optional header may be further added to transmit additional information.
  • Each header structure may be predefined. As described above, when the input packet is a TS packet, a link layer header structure different from other packets may be used.
  • Link layer signaling may operate at a lower level than the IP layer.
  • the receiving side can acquire the link layer signaling faster than the IP level signaling such as LLS, SLT, SLS, and the like. Therefore, link layer signaling may be obtained before session establishment.
  • Link layer signaling may include internal link layer signaling and external link layer signaling.
  • Internal link layer signaling may be signaling information generated in the link layer.
  • the above-described RDT or LMT to be described later may correspond to this.
  • the external link layer signaling may be signaling information received from an external module, an external protocol, or an upper layer.
  • the link layer may encapsulate link layer signaling into a link layer packet and deliver it.
  • a link layer packet structure (header structure) for link layer signaling may be defined, and link layer signaling information may be encapsulated according to this structure.
  • FIG. 7 illustrates a link mapping table (LMT) according to an embodiment of the present invention.
  • the LMT may provide a list of higher layer sessions carried by the PLP.
  • the LMT may also provide additional information for processing link layer packets carrying higher layer sessions.
  • the higher layer session may be called multicast.
  • Information on which IP streams and which transport sessions are being transmitted through a specific PLP may be obtained through the LMT. Conversely, information on which PLP a specific transport session is delivered to may be obtained.
  • the LMT may be delivered to any PLP identified as carrying an LLS.
  • the PLP through which the LLS is delivered may be identified by the LLS flag of the L1 detail signaling information of the physical layer.
  • the LLS flag may be a flag field indicating whether LLS is delivered to the corresponding PLP for each PLP.
  • the L1 detail signaling information may correspond to PLS2 data to be described later.
  • the LMT may be delivered to the same PLP together with the LLS.
  • Each LMT may describe the mapping between PLPs and IP address / port as described above.
  • the LLS may include an SLT, where these IP addresses / ports described by the LMT are all IP addresses associated with any service described by the SLT forwarded to the same PLP as that LMT. It can be / ports.
  • the PLP identifier information in the above-described SLT, SLS, etc. may be utilized, so that information on which PLP the specific transmission session indicated by the SLT, SLS is transmitted may be confirmed.
  • the PLP identifier information in the above-described SLT, SLS, etc. may be omitted, and the PLP information for the specific transport session indicated by the SLT, SLS may be confirmed by referring to the information in the LMT.
  • the receiver may identify the PLP to know by combining LMT and other IP level signaling information.
  • PLP information in SLT, SLS, and the like is not omitted, and may remain in the SLT, SLS, and the like.
  • the LMT according to the illustrated embodiment may include a signaling_type field, a PLP_ID field, a num_session field, and / or information about respective sessions.
  • a PLP loop may be added to the LMT according to an embodiment, so that information on a plurality of PLPs may be described.
  • the LMT may describe PLPs for all IP addresses / ports related to all services described by the SLTs delivered together, in a PLP loop.
  • the signaling_type field may indicate the type of signaling information carried by the corresponding table.
  • the value of the signaling_type field for the LMT may be set to 0x01.
  • the signaling_type field may be omitted.
  • the PLP_ID field may identify a target PLP to be described. When a PLP loop is used, each PLP_ID field may identify each target PLP. From the PLP_ID field may be included in the PLP loop.
  • the PLP_ID field mentioned below is an identifier for one PLP in a PLP loop, and the fields described below may be fields for the corresponding PLP.
  • the num_session field may indicate the number of upper layer sessions delivered to the PLP identified by the corresponding PLP_ID field. According to the number indicated by the num_session field, information about each session may be included. This information may include an src_IP_add field, a dst_IP_add field, a src_UDP_port field, a dst_UDP_port field, a SID_flag field, a compressed_flag field, a SID field, and / or a context_id field.
  • the src_IP_add field, dst_IP_add field, src_UDP_port field, and dst_UDP_port field are the source IP address, destination IP address, source UDP port, destination UDP port for the transport session among the upper layer sessions forwarded to the PLP identified by the corresponding PLP_ID field. It can indicate a port.
  • the SID_flag field may indicate whether a link layer packet carrying a corresponding transport session has an SID field in its optional header.
  • a link layer packet carrying an upper layer session may have an SID field in its optional header, and the SID field value may be the same as an SID field in an LMT to be described later.
  • the compressed_flag field may indicate whether header compression has been applied to data of a link layer packet carrying a corresponding transport session.
  • the existence of the context_id field to be described later may be determined according to the value of this field.
  • the SID field may indicate a sub stream ID (SID) for link layer packets carrying a corresponding transport session.
  • SID sub stream ID
  • These link layer packets may include an SID having the same value as this SID field in the optional header.
  • the context_id field may provide a reference to a context id (CID) in the RDT.
  • the CID information of the RDT may indicate the context ID for the corresponding compressed IP packet stream.
  • the RDT may provide context information for the compressed IP packet stream. RDT and LMT may be associated with this field.
  • each field, element, or attribute may be omitted or replaced by another field, and additional fields, elements, or attributes may be added according to an embodiment. .
  • service components of one service may be delivered through a plurality of ROUTE sessions.
  • the SLS may be obtained through the bootstrap information of the SLT.
  • the SLS's USBD allows the S-TSID and MPD to be referenced.
  • the S-TSID may describe transport session description information for other ROUTE sessions to which service components are delivered, as well as a ROUTE session to which an SLS is being delivered.
  • all service components delivered through a plurality of ROUTE sessions may be collected. This may be similarly applied when service components of a service are delivered through a plurality of MMTP sessions.
  • one service component may be used simultaneously by a plurality of services.
  • bootstrapping for ESG services may be performed by a broadcast network or broadband.
  • URL information of the SLT may be utilized. ESG information and the like can be requested to this URL.
  • one service component of one service may be delivered to the broadcasting network and one to the broadband (hybrid).
  • the S-TSID may describe components delivered to a broadcasting network, so that a ROUTE client may acquire desired service components.
  • USBD also has base pattern information, which allows you to describe which segments (which components) are to be routed to which path. Therefore, the receiver can use this to know what segment to request to the broadband server and what segment to find in the broadcast stream.
  • scalable coding for a service may be performed.
  • the USBD may have all the capability information needed to render the service. For example, when a service is provided in HD or UHD, the capability information of the USBD may have a value of “HD or UHD”.
  • the receiver may know which component should be played in order to render the UHD or HD service using the MPD.
  • app components to be used for app-based enhancement / app-based service may be delivered through a broadcast network or through broadband as an NRT component.
  • app signaling for app-based enhancement may be performed by an application signaling table (AST) delivered with SLS.
  • an event which is a signaling of an operation to be performed by the app, may be delivered in the form of an event message table (EMT) with SLS, signaled in an MPD, or in-band signaled in a box in a DASH representation. . AST, EMT, etc. may be delivered via broadband.
  • App-based enhancement may be provided using the collected app components and such signaling information.
  • a CAP message may be included in the aforementioned LLS table for emergency alerting. Rich media content for emergency alerts may also be provided. Rich media may be signaled by the CAP message, and if rich media is present it may be provided as an EAS service signaled by the SLT.
  • the linear service components may be delivered through a broadcasting network according to the MMT protocol.
  • NRT data for example, an app component
  • data on the service may be delivered through a broadcasting network according to the ROUTE protocol.
  • data on the service may be delivered through broadband.
  • the receiver can access the MMTP session carrying the SLS using the bootstrap information of the SLT.
  • the USBD of the SLS according to the MMT may refer to the MP table so that the receiver may acquire linear service components formatted with the MPU delivered according to the MMT protocol.
  • the USBD may further refer to the S-TSID to allow the receiver to obtain NRT data delivered according to the ROUTE protocol.
  • the USBD may further reference the MPD to provide a playback description for the data delivered over the broadband.
  • the receiver may transmit location URL information for obtaining a streaming component and / or a file content item (such as a file) to the companion device through a method such as a web socket.
  • An application of a companion device may request the component, data, and the like by requesting the URL through an HTTP GET.
  • the receiver may transmit information such as system time information and emergency alert information to the companion device.
  • FIG. 8 shows a structure of a broadcast signal transmission apparatus for a next generation broadcast service according to an embodiment of the present invention.
  • a broadcast signal transmission apparatus for a next generation broadcast service includes an input format block 1000, a bit interleaved coding & modulation (BICM) block 1010, and a frame building block 1020, orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) 1030, and signaling generation block 1040. The operation of each block of the broadcast signal transmission apparatus will be described.
  • BICM bit interleaved coding & modulation
  • OFDM generation block orthogonal frequency division multiplexing
  • signaling generation block 1040 The operation of each block of the broadcast signal transmission apparatus will be described.
  • IP streams / packets and MPEG2-TS may be main input formats, and other stream types are treated as general streams.
  • the input format block 1000 can demultiplex each input stream into one or multiple data pipes to which independent coding and modulation is applied.
  • the data pipe is the basic unit for controlling robustness, which affects the quality of service (QoS).
  • QoS quality of service
  • One or multiple services or service components may be delivered by one data pipe.
  • a data pipe is a logical channel at the physical layer that carries service data or related metadata that can carry one or multiple services or service components.
  • the BICM block 1010 may include a processing block applied to a profile (or system) to which MIMO is not applied and / or a processing block of a profile (or system) to which MIMO is applied, and for processing each data pipe. It may include a plurality of processing blocks.
  • the processing block of the BICM block to which MIMO is not applied may include a data FEC encoder, a bit interleaver, a constellation mapper, a signal space diversity (SSD) encoding block, and a time interleaver.
  • the processing block of the BICM block to which MIMO is applied is distinguished from the processing block of BICM to which MIMO is not applied in that it further includes a cell word demultiplexer and a MIMO encoding block.
  • the data FEC encoder performs FEC encoding on the input BBF to generate the FECBLOCK procedure using outer coding (BCH) and inner coding (LDPC).
  • Outer coding (BCH) is an optional coding method.
  • the bit interleaver interleaves the output of the data FEC encoder to achieve optimized performance with a combination of LDPC codes and modulation schemes.
  • Constellation Mapper uses QPSK, QAM-16, non-uniform QAM (NUQ-64, NUQ-256, NUQ-1024) or non-uniform constellation (NUC-16, NUC-64, NUC-256, NUC-1024)
  • the cell word from the bit interleaver or cell word demultiplexer can then be modulated to provide a power-normalized constellation point.
  • NUQ has any shape, while QAM-16 and NUQ have a square shape. Both NUQ and NUC are specifically defined for each code rate and are signaled by the parameter DP_MOD of PLS2 data.
  • the time interleaver may operate at the data pipe level. The parameters of time interleaving can be set differently for each data pipe.
  • the time interleaver of the present invention may be located between a BICM chain block and a frame builder.
  • the time interleaver according to the present invention may selectively use a convolution interleaver (CI) and a block interleaver (BI) according to a physical layer pipe (PLP) mode, or both.
  • PLP according to an embodiment of the present invention is a physical path used in the same concept as the above-described DP, the name can be changed according to the designer's intention.
  • the PLP mode according to an embodiment of the present invention may include a single PLP mode or a multiple PLP mode according to the number of PLPs processed by the broadcast signal transmitter or the broadcast signal transmitter.
  • time interleaving using different time interleaving methods according to the PLP mode may be referred to as hybrid time interleaving.
  • the hybrid time deinterleaver may perform an operation corresponding to the reverse operation of the aforementioned hybrid time interleaver.
  • the cell word demultiplexer is used to separate a single cell word stream into a dual cell word stream for MIMO processing.
  • the MIMO encoding block can process the output of the cell word demultiplexer using the MIMO encoding scheme.
  • the MIMO encoding scheme of the present invention may be defined as full-rate spatial multiplexing (FR-SM) to provide capacity increase with a relatively small complexity increase at the receiver side.
  • MIMO processing is applied at the data pipe level. NUQ (e 1, i ), the pair of constellation mapper outputs And e 2, i are fed to the input of the MIMO encoder, the MIMO encoder output pairs g1, i and g2, i are transmitted by the same carrier k and OFDM symbol l of each transmit antenna.
  • the frame building block 1020 may map data cells of an input data pipe to OFDM symbols and perform frequency interleaving for frequency domain diversity within one frame.
  • a frame according to an embodiment of the present invention is divided into a preamble, one or more frame signaling symbols (FSS), and normal data symbols.
  • the preamble is a special symbol that provides a set of basic transmission parameters for efficient transmission and reception of a signal.
  • the preamble may signal a basic transmission parameter and a transmission type of the frame.
  • the preamble may indicate whether an emergency alert service (EAS) is provided in the current frame.
  • EAS emergency alert service
  • the main purpose of the FSS is to carry PLS data. For fast synchronization and channel estimation, and fast decoding of PLS data, the FSS has a higher density pilot pattern than normal data symbols.
  • the frame building block adjusts the timing between the data pipes and the corresponding PLS data so that a delay compensation block is provided at the transmitter to ensure co-time between the data pipes and the corresponding PLS data.
  • a cell mapper and a frequency interleaver for mapping a PLS, a data pipe, an auxiliary stream, and a dummy cell to an active carrier of an OFDM symbol in a frame.
  • the frequency interleaver may provide frequency diversity by randomly interleaving data cells received from the cell mapper.
  • the frequency interleaver uses a different interleaving seed order to obtain the maximum interleaving gain in a single frame.
  • the frequency interleaver uses a single symbol or data corresponding to an OFDM symbol pair consisting of two sequential OFDM symbols. Operate on corresponding data.
  • OFDM generation block 1030 modulates the OFDM carrier, inserts pilots, and generates time-domain signals for transmission by the cells generated by the frame building block. In addition, the block sequentially inserts a guard interval and applies a PAPR reduction process to generate a final RF signal.
  • the signaling generation block 1040 may generate physical layer signaling information used for the operation of each functional block.
  • Signaling information may include PLS data.
  • PLS provides a means by which a receiver can connect to a physical layer data pipe.
  • PLS data consists of PLS1 data and PLS2 data.
  • PLS1 data is the first set of PLS data delivered to the FSS in frames with fixed size, coding, and modulation that convey basic information about the system as well as the parameters needed to decode the PLS2 data.
  • PLS1 data provides basic transmission parameters including the parameters required to enable reception and decoding of PLS2 data.
  • PLS2 data carries more detailed PLS data about the data pipes and systems and is the second set of PLS data sent to the FSS.
  • PLS2 signaling further consists of two types of parameters: PLS2 static data (PLS2-STAT data) and PLS2 dynamic data (PLS2-DYN data).
  • PLS2 static data is PLS2 data that is static during the duration of a frame group
  • PLS2 dynamic data is PLS2 data that changes dynamically from frame to frame.
  • the PLS2 data may include FIC_FLAG information.
  • FIC Fast Information Channel
  • the FIC_FLAG information is a 1-bit field and indicates whether a fast information channel (FIC) is used in the current frame group.If the value of this field is set to 1, the FIC is provided in the current frame. If the value of the field is set to 0, the FIC is not transmitted in the current frame.
  • the BICM block 1010 may include a BICM block for protecting PLS data
  • the BICM block for protecting PLS data is a PLS FEC encoder. , Bit interleaver, and constellation mapper.
  • the PLS FEC encoder performs external encoding on scrambled PLS 1,2 data using a scrambler for scrambling PLS1 data and PLS2 data, shortened BCH code for PLS protection, and a BCH for inserting zero bits after BCH encoding.
  • An encoding / zero insertion block, an LDPC encoding block for performing encoding using an LDPC code, and an LDPC parity puncturing block may be included.
  • the output bits of zero insertion can be permutated before LDPC encoding.
  • the bit interleaver interleaves the respective shortened and punctured PLS1 data and PLS2 data, and the constellation mapper bit interleaves.
  • the PLS1 data and the PLS2 data can be mapped to the constellation.
  • the broadcast signal receiving apparatus for the next generation broadcast service may perform a reverse process of the broadcast signal transmitting apparatus for the next generation broadcast service described with reference to FIG. 8.
  • An apparatus for receiving broadcast signals for a next generation broadcast service includes a synchronization and demodulation module for performing demodulation corresponding to a reverse process of a procedure executed by a broadcast signal transmitting apparatus and an input signal.
  • a frame parsing module for parsing a frame, extracting data on which a service selected by a user is transmitted, converting an input signal into bit region data, and then deinterleaving the bit region data as necessary, and transmitting efficiency
  • a demapping and decoding module for performing demapping on the mapping applied for decoding, and correcting an error occurring in a transmission channel through decoding, of various compression / signal processing procedures applied by a broadcast signal transmission apparatus.
  • Demodulated by an output processor and a synchronization and demodulation module that executes the inverse process It may include a signaling decoding module for obtaining and processing the PLS information from the signal.
  • the frame parsing module, the demapping and decoding module, and the output processor may execute the function by using the PLS data output from the signaling decoding module.
  • a time interleaving group according to an embodiment of the present invention is directly mapped to one frame or spread over P I frames.
  • Each time interleaving group is further divided into one or more (N TI ) time interleaving blocks.
  • each time interleaving block corresponds to one use of the time interleaver memory.
  • the time interleaving block in the time interleaving group may include different numbers of XFECBLOCKs.
  • the time interleaver may also act as a buffer for data pipe data prior to the frame generation process.
  • the time interleaver according to an embodiment of the present invention is a twisted row-column block interleaver.
  • the twisted row-column block interleaver according to an embodiment of the present invention writes the first XFECBLOCK in the column direction to the first column of the time interleaving memory, the second XFECBLOCK to the next column and the remaining XFECBLOCKs in the time interleaving block in the same manner. You can fill in these. And in an interleaving array, cells can be read diagonally from the first row to the last row (starting from the leftmost column to the right along the row).
  • the interleaving array for the twisted row-column block interleaver may insert the virtual XFECBLOCK into the time interleaving memory to achieve a single memory deinterleaving at the receiver side regardless of the number of XFECBLOCKs in the time interleaving block.
  • the virtual XFECBLOCK must be inserted in front of the other XFECBLOCKs to achieve a single memory deinterleaving on the receiver side.
  • FIG 9 illustrates a writing operation of a time interleaver according to an embodiment of the present invention.
  • the block shown on the left side of the figure represents a TI memory address array, and the block shown on the right side of the figure shows that virtual FEC blocks are placed at the front of the TI group for two consecutive TI groups. It represents the writing operation when two and one are inserted respectively.
  • the frequency interleaver may include an interleaving address generator for generating an interleaving address for applying to data corresponding to a symbol pair.
  • FIG. 10 is a block diagram of an interleaving address generator composed of a main-PRBS generator and a sub-PRBS generator according to each FFT mode included in a frequency interleaver according to an embodiment of the present invention.
  • the interleaving process for an OFDM symbol pair uses one interleaving sequence and is described as follows.
  • x m, l, p is the p th cell of the l th OFDM symbol in the m th frame
  • N data is the number of data cells.
  • H l (p) is an interleaving address generated based on the cyclic shift value (symbol offset) of the PRBS generator and the sub-PRBS generator.
  • 11 illustrates a protocol stack of a broadcast system according to an embodiment of the present invention.
  • 11 shows a conceptual model of a broadcast system according to an embodiment of the present invention.
  • FIG. 11 the same descriptions as those described above with reference to FIG. 1 are omitted.
  • two methods for transmitting a broadcast service are defined.
  • the first method is based on the MPEG Media Transport (MMT) protocol, and a broadcast system can transmit an MPU (Media Processing Unit) using the MMTP protocol.
  • MMT MPEG Media Transport
  • MPU Media Processing Unit
  • the MMT protocol may be used for transmission of broadcast program elements.
  • Media Processing Units (MPUs) and MPEG DASH segments may be used as transport, media encapsulation, and synchronization formats for the MMT protocol and the ROUTE protocol, respectively.
  • Non real-time content including Non-Real Time (NRT) media, Electronic Service Guide (ESG) data, and other files can be transmitted via the ROUTE protocol.
  • NRT Non-Real Time
  • ESG Electronic Service Guide
  • the second method is based on MPEG DASH, and a broadcast system can transmit a DASH segment using a Real-time Object Delivery over Unidirectional Transport (ROUTE) protocol.
  • ROUTE Real-time Object Delivery over Unidirectional Transport
  • the ROUTE protocol can be used to transport streaming media and / or non-real time media as well as files and / or signaling metadata in a broadcast stream.
  • the fact that a service is transmitted through broadband means that one or more program components are transmitted through broadband rather than a broadcasting network.
  • a DASH-IF profile of MPEG DASH may be used over HTTP / TCP / IP.
  • Media files in ISO Base Media File Format (BMFF) format may be used as delivery, media encapsulation, and / or synchronization formats for broadcast and / or broadband transmission.
  • Signaling may be transmitted using the MMT or ROUTE protocol, and bootstrap signaling information for obtaining signaling transmitted through the MMT or ROUTE may be provided through a service list table (SLT).
  • SLT may be transmitted at the UDP / IP layer.
  • the SLT is not encoded at the delivery layer, but is encapsulated and transmitted as an IP / UPD packet, so that it can be processed faster at the receiver, and thus a delay required for providing a service when the receiver is turned on or when a channel is changed. Can be reduced.
  • the SLT may be referred to as a fast information table (FIT), a fast information channel (FIC), or the like.
  • signaling transmitted through MMT or ROUTE may be referred to as service layer signaling (SLS).
  • SLS means signaling that provides information for discovery and acquisition of a service and a content component of the service (SLS is a signaling which provides information for discovery and acquisition of services and their content components),
  • SLT is a table of signaling information which is used to build a basic service listing and provide bootstrap discovery of SLS ).
  • FIG. 12 illustrates an Emergency Alert System (EAS) according to an embodiment of the present invention.
  • FIG. 12 illustrates a method of transmitting an Emergency Alert (EA) message in a next generation broadcast system and obtaining the same in an receiver.
  • FIG. 12 illustrates signaling and EA related information flow in an EAS according to an embodiment of the present invention.
  • the thick solid line represents the flow of EA and signaling
  • the thin solid line represents the flow of content and data
  • the dotted line represents internal signaling.
  • EA-related information may be referred to as EA information
  • EA information may be represented by an Emergency Alert Table (EAT), an Emergency Non-Real-Time Information Table (ENRT-IT), an Advanced EAT (AEAT), an EA message, or an AEA.
  • EAT Emergency Alert Table
  • ENRT-IT Emergency Non-Real-Time Information Table
  • AEAT Advanced EAT
  • EA message EA message
  • CAP Advanced EA
  • AEAT may be an EA-related table including EAT and ENRT-IT, or may be a newly-defined EA-related table
  • AEA may be a message included in AEAT.
  • the protocol stack or protocol stack for broadband may be the protocol stack of the embodiment of FIG. 11.
  • the EA information must be broadcast and presented to the user in an emergency. Therefore, the EA information may be transmitted in a different path from the normal service data.
  • the EA information may be transmitted using a dedicated channel for the EA information or a specific PLP.
  • data / signals must be processed and inserted in the physical layer, which may make it difficult to operate a system for EA information. Therefore, hereinafter, a method of transmitting EA information using a UDP / IP packet will be described.
  • the EA information may be transmitted in an IP packet instead of being transmitted in link layer signaling or physical layer channel / data.
  • the IP-based EA information may have an effect of facilitating system operation.
  • additional signaling information for which IP packet an EA related information is delivered may be configured.
  • the presence or absence of the EA information may be indicated using the header portion of the packet.
  • a packet or table including EA related information may be referred to as an EA packet.
  • an IPAW Aggregator Integrated Public Alert and Warning system
  • An information collecting device such as an IPAW Aggregator may configure an EA to be transmitted through a broadcasting network as a message of a predefined format and deliver the EA to a broadcaster.
  • the information collection device may configure the EA as a message based on a Common Alerting Protocol (CAP) and deliver the EA to a broadcaster.
  • CAP Common Alerting Protocol
  • a broadcaster configures an EA-related content (eg, EA-related banner text / audio, EA-related rich media content, and, according to an embodiment, EA-related banner text / audio through a module processing a corresponding message). May be burned-in to the main audio / video) and signaling information (for example, EA-related signaling information) for the main audio / video.
  • EA-related information (data) including EA-related content and EA-related signaling information may be processed according to each purpose and form, and transmitted to a broadcasting network or a broadband network through a data pipe (DP).
  • DP may also be referred to as a physical layer pipe (PLP).
  • the receiver can then decode the EA related signaling information (EA information).
  • EA information EA related signaling information
  • the receiver may parse it to provide an EA message to the user.
  • the decoded signaling information includes path information for receiving an EA-related audio / video service
  • the receiver may use the same to find a path through which the corresponding service is received and provide an AV service. This allows the receiver to provide the user with EA related banner text or EA related audio alerts.
  • the video in which the EA-related banner text is bundled-in or the EA-related audio alert may be provided to the user.
  • the receiver uses the corresponding information to transmit the information through the broadband.
  • EA-related non-real time (NRT) services and additional information may be received.
  • FIG. 13 (a) shows a hierarchical structure of an EAS according to an embodiment of the present invention.
  • signaling information may be transmitted hierarchically, for example, at three levels.
  • physical layer signaling PLS and bootstrap signal
  • EAT and SLT may be transmitted at the level of the IP / UDP layer
  • SLS is a delivery layer.
  • the signaling information transmitted to the delivery layer level is referred to as first level signaling information
  • the signaling information transmitted at the IP / UDP layer level is referred to as second level signaling information
  • the signaling information transmitted at the physical layer level is referred to as third level signaling information. You may.
  • EA-related information is provided hierarchically in the EAS.
  • the EA information may be a concept including EA related content and EA related signaling information.
  • EA related signaling information may be abbreviated as EA signaling information.
  • the EA-related signaling information may be referred to as an Emergency Alert Table (EAT), an Advanced EAT (AEAT) or an Emergency Non-Real-Time Information Table (ENRT-IT), or a Common Alert Protocol (CAP) message.
  • EAT Emergency Alert Table
  • AEAT Advanced EAT
  • ENRT-IT Emergency Non-Real-Time Information Table
  • CAP Common Alert Protocol
  • the signal frame of the physical layer may include physical layer signaling information including the bootstrap information, and the bootstrap information including the wakeup signal that provides the wakeup information indicating the wakeup of the receiver is included in the signal frame. It can be included and delivered. This will be described in detail below with reference to FIGS. 37 to 39.
  • the first type of EA information for providing a universal alert such as banner text, audio sound or symbol icon associated with the EA is delivered embedded in the EA related signaling information, or to obtain the first type of EA information. Information necessary for this may be included in the EA-related signaling information and delivered.
  • the EA signaling information may be signaled by being included in low level signaling (LLS) information similarly to the SLT information.
  • LLS low level signaling
  • the EA related banner text or secondary audio may be burned-in to the main video or audio and transmitted.
  • the EA signaling information may be transmitted in the IP / UDP layer, and the video segment including the bundled-in banner text and the audio segment including the bundled-in secondary audio are encoded in the delivery layer and transmitted through the broadcasting network. Can be.
  • the EA-related banner text or secondary audio may be transmitted in a separate transmission session from the main video or audio. This will be described in detail below with reference to FIGS. 16 to 28.
  • the EA information of the second type for providing advanced alerts may be encoded in the delivery layer and transmitted to the broadcast network, or transmitted through the broadband network.
  • link information for acquiring the second type of EA information may be included in the EA related signaling information.
  • the EA signaling information may be included in the SLS information and signaled. This will be described in detail below with reference to FIGS. 29 to 36.
  • FIG. 13 (b) shows a method for delivering EA information according to an embodiment of the present invention.
  • FIG. 13B illustrates an embodiment in which the EA related signaling information (EAT) is included in the LLS information (LLS table) for delivery.
  • the EA information may be included in the LLS information and signaled like the SLT.
  • an EAT may include at least one EA message, and each EA message may include information about EA-related banner text or information about EA-related rich media content (eg, EA through broadcast).
  • Related rich media content LCC: path information for acquiring locally cashed content or URL information for acquiring EA related rich media content from an EA server via broadband
  • EAT may be referred to as AEAT.
  • EA messages may be referred to as AEAM, and EA related rich media content may also be referred to as EA related additional information.
  • LLS information (LLS) including EAT is encapsulated into IP / UDP packets through IP / UDP layer processing, and IP / UDP packets are link layer packets through link layer processing.
  • an ALP packet may be generated as a signal frame L1 frame of the physical layer through physical layer processing.
  • the signal frame of the physical layer may include wake-up flag indicating wake-up of the receiver.
  • the wakeup information may be signaled by being included in physical layer signaling information (eg, bootstrap information and / or L1 signaling information) included in a signal frame of the physical layer.
  • EAT can also be delivered through the most robust PLP.
  • FIG. 14 illustrates a method of transmitting EA information using UDP / IP according to an embodiment of the present invention.
  • the broadcast transmitter may collect a CAP message and related data so as to transmit EA information through IP (S21010).
  • the CAP message may be referred to as an EA message.
  • the EA related data may include an EA table or packet.
  • the Emergency Alert Table (EAT) may also be referred to as EA information or EA messages.
  • the EA message may mean an EA message to be delivered to the user, and in this case, signaling information required to deliver the EA message may be referred to as EA information or EAT.
  • the broadcast transmitter may configure the EA related information / data in an IP packet format by UDP / IP encapsulation (S21020). It has been described above that such an IP packet may be LLS information.
  • the payload of the IP packet may include a table in the form of an Emergency Alert Table (EAT).
  • the IP packet may include EA related information / data as a payload.
  • the field / information indicating that data configured in the payload is EA information may be added to the packet header during encapsulation.
  • the IP address and the UDP port number may be known in advance or may use dedicated values known to the transmitter and the receiver to indicate EA information. As a designated value, a predetermined IP address and UDP port number of the LLS information can be used.
  • the broadcast transmitter may PHY layer process the IP packet including the EA related information (S21030).
  • the IP packet including the EA information may be transmitted to a specific base PLP or a general PLP.
  • the receiver can decode the PLP without additional signaling information.
  • the broadcast transmitter may encode broadcast data such as A / V content based on the delivery protocol (S21040).
  • the delivery protocol may be a ROUTE protocol or an MMT protocol.
  • the broadcast transmitter may configure the IP packet format by encapsulating the broadcast data in UDP / IP.
  • the broadcast receiver may process the received signal by PHY layer processing, and may IP / UDP decode / decapsulate IP packets included in the PLP (S21060).
  • the broadcast receiver decodes the IP packet and checks whether the corresponding packet is an EA packet by checking the IP address and port number from the header of the IP packet.
  • the broadcast receiver may check the LLS information by the IP address and the port number, and may check the EA related information included in the LLS information.
  • the broadcast receiver may extract an EA message, such as a CAP message, using the header and payload information of the EA packet, and deliver the EA message to the CAP parser or the message parser (S21070).
  • the broadcast receiver may parse EA related information using a CAP parser or a message parser (S21080).
  • the broadcast receiver may receive service data by decoding the corresponding PLP when the EA related information is included in the payload in the EA packet.
  • the PLP may continue to receive the corresponding PLP.
  • the broadcast receiver may receive the data. If necessary, the broadcast receiver may receive EA related NRT service data over broadband. If there is duplicate information in the payload of the EA packet and the CAP message, the broadcast transmitter may properly adjust the location of the information.
  • FIG. 15 illustrates a method of transmitting EA information using UDP / IP according to an embodiment of the present invention.
  • FIG. 15 illustrates a case in which EA related information is transmitted using a general PLP, and a description of the same operation as that of FIG. 14 is not duplicated.
  • the physical layer signaling information may include information indicating whether the PLP included in the signal frame includes EA information. In other words, since the EA information is included in the LLS information, the physical layer signaling information may signal / indicate whether the PLP includes the LLS information.
  • the broadcast transmitter may configure and transmit the IP address / port number of the service packet and the IP address / port number of the EA packet differently.
  • the broadcast transmitter may use a dedicated IP address and port number for an IP packet including EA information, and use an IP address and port number specified in service signaling for service data.
  • the broadcast receiver may perform physical layer processing of the PLP.
  • the broadcast receiver may identify the EA packet and the service data packet by the IP address / port number of the IP packets. The description of the identified EA packet and the service data packet are as described with reference to FIG. 14.
  • the broadcast receiver may first receive and process EA related information transmitted through a dedicated IP address and a port number.
  • the broadcast receiver may process EA related signaling and EA messages and receive EA related audio / video days using the received EA signaling. That is, the broadcast receiver may identify an IP address and a port number for receiving related audio / video data using EA signaling, and may service A / V content through receiving the corresponding packet stream.
  • related reception information URI
  • FIG. 16 illustrates EA information according to an embodiment of the present invention.
  • the embodiment of FIG. 16 proposes a structure of EA information (EA table) composed of one or more EAs.
  • EA table An embodiment of an EA table or description syntax consisting of one or more EAs is shown in FIG. 16.
  • the structure of the binary syntax proposed by the present invention may be configured in an XML format. Description of the fields included in the EA table (EA message) of FIG. 16 is as follows.
  • the EA information includes signaling information for at least one EA content.
  • the transmission type of the EA content may be a type embedded in the EA information, a type transmitted over a broadcasting network, or a type transmitted over a broadband.
  • the format of the EA content is identified by EA format information (ea_format).
  • the format of the EA content may correspond to a CAP format, a binary syntax format, or an XML format.
  • table_id Unique ID of the table granted to the EAT table.
  • ea_id Unique identifier given per emergency alert issued per day
  • ea_transfer_type A value indicating the path to which the EA is sent. If 0x01, it means embedded in the table and transmitted. In case of 0x02, it means the case of transmitting to the broadcasting network. If 0x03, it means that the data is transmitted through broadband.
  • ea_format The format of emergency alert transmitted through EAT.
  • the CAP is transmitted.
  • 0x02 it means a predefined message format in the form of binary syntax.
  • 0x03 it means a predefined message format in XML format. Otherwise, it is defined as reserved for Future Extensibility.
  • encoding_type When transmitted in a CAP message, this means an encoding type of a CAP. 0x00 (no compression), 0x01 (DEFLATE).
  • CAP_data_length indicates the length of CAP when emergency alert is sent to CAP
  • broadcast_stream_id The stream identifier of the broadcast, if it is not embedded in the table and is sent in another IP packet. If it is defined as 0x00, it means that it is transmitted in the same broadcast_stream_id as the corresponding EAT.
  • PLP_ID The identifier of the PLP to be sent if it is not embedded in the table and is sent to another PLP.
  • sourceIPaddress The source IP address of the UDP / IP session if it is not embedded in the table and is sent to another UDP / IP session.
  • destinationIPaddress The destination IP address of the UDP / IP session if it is not embedded in the table and is sent to another UDP / IP session.
  • destinationPort Destination port number of the UDP / IP session if it is not embedded in the table and is sent to another UDP / IP session.
  • tsi transport session identifier of the transmitted LCT session, if it is not embedded in the table and is sent to another LCT session
  • ea_url_length Length of URL sent when emergency alert is sent over broadband
  • ea_url URL to which emergency alerts are sent over broadband
  • FIG 17 illustrates an embodiment of signaling an embedded EA in EA information.
  • An ea_transfer_type field value of 0x01 may indicate that an EA is embedded in an EA table. If the value of ea_format is 0x01, this may indicate that the embedded EA is CAP data, and if 0x02, it is a predefined EA format.
  • Two EA messages TOR_ALERT_001 and HUR_ALERT_001 may be included in the EAT and transmitted. The first EA message TOR_ALERT_001 may be sent in CAP, and the second EA message HUR_ALERT_001 may be sent in a predefined EA format.
  • FIG. 18 illustrates an embodiment of signaling an EA transmitted in a separate session in EA information.
  • the ea_transfer_type field value is 0x02, which may indicate that an alert message is transmitted to a separate session. If the ea_format value is 0x01, this may indicate that the transmitted message is CAP data, and when 0x02, it is a predefined EA format.
  • USBD 19 illustrates a USBD syntax including EA information according to an embodiment of the present invention.
  • the EA message may be signaled in the form of a descriptor of USBD / USD.
  • FIG. 19 descriptions identical to those of the USBD / USD described above with reference to FIGS. 4 to 5 will be omitted.
  • the USBD may include an atsc: EAMDescription element associated with an EA message.
  • the USBD may optionally include an atsc: EAMDescription subelement in an atsc: Channel subelement in a USD element.
  • the atsc: Channel element may include an @atsc: EAMDescrText attribute, an @atsc: EAMDescrLang attribute, and an @atsc: expiration attribute.
  • the atsc: Channel element is an element that contains information about the channel of the service
  • the atsc: EAMDescription element is an element that contains a description of EA information (EA messages) available in multiple languages.
  • the @atsc: EAMDescrText attribute is an attribute indicating a description of EA information
  • the @atsc: EAMDescrLang attribute is an attribute indicating a language of the EAMDescrText
  • the @atsc: expiration attribute is an attribute indicating an expiration of the EAMDescrText. it means.
  • the universal alert is one of EAs requested by the EAS framework of the next generation broadcast system, and may be an EA including at least one of banner text, audio alert, or symbol icon.
  • the EA information may be EA related signaling information (EAT information).
  • the EAT information may include at least one EA related message.
  • each message may have a unique identifier (message_id information). As shown, the message_id of message # 1 may be 10 and the message_id of message # 2 may be 12.
  • each message may further include EA Bund-in information.
  • the EA bund-in information may include information indicating whether a universal alert including at least one of banner text, audio data, or symbol icon is burned in to the main video or audio. In this case, when the value of the EA bundle-in information is true, it may indicate that the EA has been burned in to the main video or audio, and when the value of the EA bundle-in information is false, the EA is burned in to the main video or audio. May indicate no.
  • the EA Bund-in information may be additional information about the time when the bundled-in banner text, audio, or symbol icon is displayed or played, or additional information such that the main video or content information does not block the bundled information. May be provided.
  • the EAT information may be encapsulated into an IP packet having a predetermined IP address and transmitted through the most robust PLP.
  • the EAT information includes information that must be received by all receivers regardless of the delivery protocol. Therefore, the EAT must be processed and transmitted in a lower level layer than the delivery layer.
  • the EAT may be included in the above-described low level signailing (LLS) information and transmitted.
  • LLC low level signailing
  • the EAT information may include at least one of bundle information, message ID information, and message version information.
  • the bund-in information and the message ID information are not described in detail as described above.
  • the message version information is information indicating a version of the EA message, and the receiver may not perform repetitive processing on the same EA message using this information.
  • banner text may be burned in to a video segment or video mpus
  • secondary audio may be burned in to an audio segment or audio mpus
  • video data with banner text bundled in and audio data with secondary audio bundled in may be encoded and delivered in a delivery protocol (ROUTE protocol or MMTP), respectively.
  • ROUTE protocol or MMTP
  • FIG. 21 illustrates a method for delivering an audio alert according to an embodiment of the present invention.
  • FIG. 21A illustrates an embodiment of providing audio alerts using secondary audio streaming in a ROUTE delivery protocol
  • FIG. 21B illustrates implementation of providing audio alerts using secondary audio streaming in an MMTP delivery protocol.
  • an audio alert which is one of the above-described universal alerts, may be delivered through a separate transmission session without being burned in to the main audio.
  • the secondary audio alert is an audio component distinguished from an audio component constituting a linear service (eg, a linear A / V service or a linear audio only service) and may also be referred to as an alternative audio alert.
  • an audio component for an audio alert may be referred to as an audio alert.
  • an audio alert may be delivered in a transport session (tsi-eaa) different from a transport session (LCT channel, tsi-a) in which the main audio constituting the broadcast service is delivered.
  • the audio alert may be an audio alert configured in a different language, and each audio alert may be delivered in a different transmission session (tsi-eaa1 or tsi-eaa2).
  • an audio alert may be delivered in a packet-eaa different from a packet (MMTP packet, packet-a) in which the main audio constituting the broadcast service is delivered in the MMTP delivery protocol.
  • the audio alert may be an audio alert configured in a different language, and each audio alert may be delivered in a different packet (packet-eaa1 or packet-eaa2).
  • FIG. 22 illustrates a method of signaling secondary audio streaming for an audio alert according to an embodiment of the present invention.
  • FIG. 22 illustrates an embodiment of signaling an audio alert using EAT information and SLS information when the audio alert is delivered using the ROUTE protocol as shown in FIG. 21 (a).
  • the audio alert may be delivered in a different transport session than the main audio.
  • the EAT information may include information about one or more audio alerts.
  • the audio alert information (audio_alert_info) may include at least one of identification information (eg, representation ID information) for the audio component for the audio alert and information about attributes of the audio component.
  • the representation ID may be information for mapping EAT information and SLS information.
  • the representation ID may be information linking EAT information and S-TSID information and / or MPD information in the SLS.
  • the attribute information may include at least one of mime type information, codec information, and language information about the audio component.
  • the representation ID information for the first audio alert (audio_alert # 1) is rep_eaa1 and the representation ID information for the second audio alert (audio_alert # 2) is rep_eaa2.
  • the broadcast receiver may identify the representation ID (rep_eaa1 or rep_eaa2) of the audio component from the EAT information, and check the position information on the location where the audio component having the corresponding ID is delivered from the SLS information. For example, the broadcast receiver may obtain, from the S-TSID fragment in the SLS, the transport session information for the transport session in which the audio component having the corresponding ID is delivered.
  • the transport session information may be TSI information (tsi-eaa1 or tsi-eaa2) that matches the representation ID one-to-one.
  • the location information may further include at least one of PLP information, IP information, and port information for the audio alert.
  • the broadcast receiver may receive the corresponding audio component using the location information.
  • the receiver may receive an audio component (Hurricane audio alert (English) or Hurricane audio alert (English)) for an audio alert using the transmission session information tsi-eaa1 or tsi-eaa2.
  • the audio component may be received in an LCT session.
  • the receiver may provide the user with the received audio alert using the component attribute information.
  • the broadcast receiver may receive an audio component for an audio alert streamed as secondary audio through the broadcast network using the EAT information and the SLS information (S-TSID fragment of the SLS), and provide the same to the viewer.
  • FIG. 23 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • FIG. 23 illustrates another embodiment of signaling an audio alert using EAT information and SLS information when the audio alert is delivered using the ROUTE protocol as shown in FIG. 21 (a).
  • FIG. 23 detailed descriptions of the same description as those described above with reference to FIG. 22 will be omitted for convenience of description.
  • the EAT information may include information about one or more audio alerts.
  • the audio alert information audio_alert_info may include identification information (representation ID information) for the audio component for the audio alert.
  • the representation ID information for the first audio alert is rep_eaa1 and the representation ID information for the second audio alert is rep_eaa2.
  • the broadcast receiver identifies the representation ID (rep_eaa1 or rep_eaa2) of the audio alert from the EAT information, and at least one of component attribute information for the attribute of the audio component having the corresponding ID and position information for the position where the audio component is delivered.
  • the broadcast receiver may obtain at least one of mime type information, codec information, and language information for an audio alert having the corresponding ID from the MPD fragment in the SLS information using the representation ID information. have.
  • the component property information may further include at least one extension information, for example, role extension information and / or essential property extension information.
  • Such Role extension information and EssentialProperty extension information may include a schemeIDUri attribute and a value attribute.
  • the role extension information may provide information about what role the corresponding representation has.
  • the role extension information may signal that an audio component for an audio alert having a corresponding DASH representation ID is secondary audio (alternative) audio instead of main audio.
  • the secondary (alternative) audio component may be an audio component that is different from the audio component that constitutes a linear service (eg, a linear A / V service or a service of linear audio only).
  • the secondary audio component may be an audio component for the EA.
  • the EssentialProperty extension information may provide information on what property (characteristic) the DASH representation has.
  • the EssentialProperty extension information may signal that an audio component having a corresponding representation ID is EA audio. Accordingly, the broadcast receiver may combine the two pieces of information and confirm that the audio component having the corresponding representation ID is an audio component for an EA (audio alert) streamed as secondary audio.
  • the broadcast receiver may obtain, as location information, transport session information about a transport session in which an audio component having the corresponding ID is delivered, from the S-TSID fragment in the SLS, using the representation ID information.
  • the transport session information may be TSI information (tsi-eaa1 or tsi-eaa2) that matches the representation ID one-to-one.
  • the location information may further include at least one of PLP information, IP information, and port information for the audio alert.
  • the broadcast receiver may receive the corresponding audio component using the location information.
  • the receiver may receive an audio component (Hurricane audio alert (English) or Hurricane audio alert (English)) for an audio alert using the transmission session information tsi-eaa1 or tsi-eaa2.
  • the audio component may be received in an LCT session.
  • the receiver may provide the user with an audio alert consisting of the received audio component using the component attribute information.
  • the broadcast receiver may receive an audio component streamed as secondary audio through the broadcast network using the EAT information and the SLS information (the MPD fragment and the S-TSID fragment of the SLS) and provide the same to the viewer.
  • FIG. 24 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • FIG. 24 illustrates an embodiment of signaling an audio alert using only EAT information when the audio alert is delivered using the ROUTE protocol or the MMTP as shown in FIG. 21 (a) or (b).
  • FIG. 24 detailed descriptions of the same description as those described above with reference to FIGS. 21 through 23 will be omitted for convenience of description.
  • emergency alert table (EAT) information may include information on one or more audio alerts.
  • the audio alert information audio_alert_info may include at least one of component attribute information, location information, and representation ID information for the audio component for the audio alert.
  • the component property information may include at least one of mime type information, codec information, and language information about the corresponding audio component.
  • the location information may include, for example, at least one of PLP information, IP information, port information, delivery type information (eg, ROUTE delivery protocol or MMPT delivery protocol) for the audio component, and transport session information according to the delivery type.
  • the transport session information may be TSI information about an LCT session in which an audio alert is delivered in the ROUTE protocol, and packet ID information on an MMPT packet flow in which the audio alert is delivered in the case of MMTP.
  • the broadcast receiver may obtain component attribute information and position information for the audio component for the audio alert from the EAT information. Thereafter, the broadcast receiver may receive the corresponding audio alert using the location information and provide the received audio alert to the user by using the component attribute information.
  • the broadcast receiver may receive an audio alert streamed as secondary audio through the broadcast network using only the EAT information and provide the same to the viewer.
  • FIG. 25 illustrates a method of signaling secondary audio streaming for an audio alert according to another embodiment of the present invention.
  • FIG. 25 illustrates an embodiment of signaling an audio alert using only the EAT information when the size of the audio alert is sufficiently small so that audio data for the audio alert is included in the EAT information and transmitted.
  • FIG. 25 detailed descriptions of the same description as those described above with reference to FIGS. 21 through 24 will be omitted for convenience of description.
  • emergency alert table (EAT) information may include information on one or more audio alerts.
  • the audio alert information audio_alert_info may include at least one of component attribute information and delivery type information for an audio component for an audio alert.
  • the component attribute information may include at least one of mime type information, codec information, and language information about audio information.
  • the delivery type information is information on a type for which an audio alert is delivered.
  • the delivery type information may include a case where the audio alert is included in the EAT information and transmitted in an embedded type. In this embodiment, since the audio component is embedded in the EAT information and transmitted, no additional location information is required other than the information that the delivery type is the embedded type.
  • the broadcast receiver may obtain component attribute information on the audio alert and data on the audio alert itself (eg, emergency audio alert segment (english) or emergency audio alert segment (spanish)) from the EAT information. Thereafter, the broadcast receiver may provide the user with the received audio alert using the component attribute information. As such, the broadcast signal receiver may obtain an audio alert streamed as secondary audio through the broadcast network using only the EAT information and provide the same to the viewer.
  • component attribute information on the audio alert and data on the audio alert itself eg, emergency audio alert segment (english) or emergency audio alert segment (spanish)
  • the broadcast receiver may provide the user with the received audio alert using the component attribute information.
  • the broadcast signal receiver may obtain an audio alert streamed as secondary audio through the broadcast network using only the EAT information and provide the same to the viewer.
  • FIG. 26 illustrates a method of providing an EA related symbol icon according to an embodiment of the present invention.
  • FIG. 26 illustrates a method of providing an EA related symbol icon through expansion of a CAP message.
  • the EA-related symbol icon may be an icon assigned to each EA type (eg, an icon for Blizzard, an icon for an earthquake, etc.), and the information about the EA-related symbol icon may include EA information (such as a CAP message). Signaled via an EA message).
  • the XML schema of the CAP message may be extended for the display of such symbol icons, and as in the embodiment of FIG. 26, the ⁇ icon> element for the symbol icon may be added to the CAP message.
  • the ⁇ icon> element may be added in the ⁇ info> subelement in the ⁇ alert> element that is the root element of the CAP message.
  • the extended CAP message may include an icon element.
  • the icon element is a subelement and may include a symbolDesc element, a size element, a uri element, a derefUri element, a digest element, and the like. Referring to FIG. 27, each element is described below.
  • the icon element may be a container for all component parts of the ⁇ icon> subelement in the ⁇ alert> element of the ⁇ info> subelement in the ⁇ alert> element.
  • the icon element may be an optional element. (1) the icon element may refer to an additional symbol icon with supplemental information related to the corresponding ⁇ info> element, and (2) multiple instances may be generated within the ⁇ info> block.
  • the symbolDesc element may be text describing the type and content of the icon.
  • the symbolDesc element may be an element that is required.
  • the symbolDesc element may provide human readable text describing the type and content of the EA related symbol icon file.
  • the symbolDesc element may be a "Blizzard Warning, Child Abduction Emergency, Civil Emergency Message, Dust Storm Warning, Presidential Emergency Alert Notification, Earthquake Warning, Fire Warning, Flash Flood Warning, Hurricane Warning, Law Enforcement Warning, Nuclear Power Plant Warning, Radiological Hazard. Warning, Shelter In-Place Warning, Tornado Warning ", etc. can provide text describing the type and content of the symbol icon file for the EA.
  • the size element may be an integer indicating the size of the icon file.
  • the size element may be an optional element.
  • the size element may be an approximate size in bytes of the icon file, and (2) for uri based icons, the size element should be formatted only when available.
  • the uri element may be an identifier of a hyperlink to the icon file.
  • the uri element may be an optional element.
  • the uri element may be a generic Uniform Resource Locator (URL) that can be used to retrieve an icon over the Internet, a full absolute URI, or a relative URI that names the content of the derefUri element if a derefUri element is present in the icon block.
  • URL Uniform Resource Locator
  • the derefUri element may be the base-64 encoded data content of the icon file.
  • the derefUri element may be an optional element.
  • the derefUri element MAY be used either with or instead of (1) an uri element in a message sent over a unidirectional (eg broadcast) data link if icon retrieval via a URI is not feasible. of the ⁇ uri> element in messages transmitted over one-way (eg, broadcast) data links where retrieval of a icon via a URI is not feasible.).
  • Clients intended for use with one-way data links MUST support this element.
  • This element MUST NOT be used unless the sender is certain that all direct clients are capable of processing it. .
  • the forwarder must strip the derefUri element, extract the file contents, and provide a uri link to the searchable version of the file (If messages including this element are forwarded onto a two-way network, the forwarder MUST strip the ⁇ derefUri> element and SHOULD extract the file contents and provide a ⁇ uri> link to a retrievable version of the file.).
  • Providers of unidirectional links should enforce additional restrictions on the use of this element, including message-size restrictions and file insertion restrictions. , including message-size limits and restrictions regarding file types.).
  • the digest element may be a code representing a digital digest ("hash") that is calculated from the icon file.
  • the digest element may be an optional element.
  • the digest element may be calculated using a hash algorithm, for example, Secure Hash Algorithm per [FIPS 180-2].
  • FIG. 28 illustrates extension of EA information according to an embodiment of the present invention.
  • FIG. 28 shows a method of providing additional information through expansion of EA information (EAT) in the form of a CAP message.
  • EAT EA information
  • CAP messages may be transmitted via a dedicated IP address / port.
  • the CAP message may have information about multiple events in multiple ⁇ info> elements.
  • each ⁇ info> element corresponding to the text banner and the rich media content may be signaled in EA related signaling information (eg, ENRT-IT information).
  • EA related signaling information eg, ENRT-IT information.
  • ENRT-IT information EA related signaling information
  • an embodiment of extending a CAP message through an element or attribute added in a ⁇ parameter> element or a ⁇ resource> element of the CAP message will be described.
  • the ⁇ parameter> element and the ⁇ resource> element may be included in the ⁇ info> element in the ⁇ alert> element of the CAP message.
  • an identifier (ID) of the message may be provided through the CAP message extension.
  • message ID information may be provided through a ⁇ valueName> element and a ⁇ value> element in an optional ⁇ parameter> element added to an ⁇ info> element.
  • the ⁇ value> element may indicate a string value (eg, 13970876) of the ID.
  • banner information may be provided via CAP message extension.
  • banner information can be provided through the ⁇ valueName> and ⁇ value> elements in the optional ⁇ parameter> element added to the ⁇ info> element (if there is only one banner normally, Only one ⁇ info> element may appear).
  • banner information can be provided through the ⁇ valueName> and ⁇ value> elements in the optional ⁇ parameter> element added to the ⁇ info> element (if there is only one banner normally, Only one ⁇ info> element may appear).
  • bannerText when the ⁇ valueName> element in the ⁇ parameter> element is "bannerText"
  • the ⁇ value> element may be a string value of the banner text (eg Herricane is coming).
  • information about rich media content may be provided via CAP message extension.
  • alert.info in the CAP message to establish linkage between the ⁇ resource> element in the CAP message and the rich media content delivered via the ROUTE protocol in the EAS service.
  • the "contented" attribute can be added to the .resource element.
  • the alert.info.resource element in the CAP message may include a ⁇ mimeType> element and a ⁇ uri> element as child elements.
  • the broadcast receiver may acquire rich media content through broadband using URI information (URL) in the ⁇ uri> element.
  • an alert.info.resource in a CAP message to provide additional information, such as information related to the time at which the EA is displayed and played or the "time_slot" period, such as "time_slot” information and "playback_length” information.
  • An element may include additional elements and / or additional attributes.
  • FIG. 29 illustrates syntax of EA information according to another embodiment of the present invention.
  • FIG. 29 illustrates EA information (EAT information) defined for rich media transmission associated with EA. Fields identical to those in FIG. 16 in the table of FIG. 29 are not duplicated.
  • the EA table of FIG. 29 includes EAS_NRT_Service_id information. Rich media associated with one EA may be transmitted via EAS NRT service signaling.
  • the present invention proposes a method of granting an EAS NRT service ID associated with one EA of the EAT and signaling rich media content associated with the EA through signaling of the corresponding service.
  • the EAS_NRT_Service_ID information represents a service identifier for transmitting rich media associated with an EA.
  • a type in which rich media content is transmitted may be CAP, broadcast, or broadband, and EA information provides resource location information for each type.
  • the EA information may provide at least one field of a broadcast stream ID, a PLP ID, a source IP address, a destination IP address, a destination port number, and TSI.
  • TSI indicates a transport session identifier (TSI) of the LCT session when the rich media content is transmitted in the LCT session. That is, the TSI may indicate LCT channel information on which rich media content is transmitted.
  • the EA information includes URL information from which the rich media content can be downloaded.
  • FIG. 30 illustrates syntax of EA information according to another embodiment of the present invention.
  • the embodiment of FIG. 30 proposes a structure of EA information (EA table) composed of one or more EAs.
  • EA table composed of one or more EAs.
  • the same fields as those in FIGS. 16 and 29 in the table of FIG. 30 are not duplicated.
  • the signaling structure shown as the embodiment of FIG. 30 can be extended to have more elements and attributes.
  • elements and attributes included in the EA table (EA message) of FIG. 30 will be described.
  • the EA table EAT may be referred to as AEAT.
  • the EAT may include one or more EA messages, and the EA messages may be formatted with a predefined message structure (eg, the CAP message format structure described above or a newly defined message format structure).
  • a predefined message structure eg, the CAP message format structure described above or a newly defined message format structure.
  • Each EA message transmits the fields associated with EA-related content, such as the required fields defined by the CAP and the universal alerts and advanced alerts requested by the EAS framework of next generation broadcast systems. May contain fields for.
  • @eatSectionVersion attribute Version number of the EAT section. This property can be increased by one whenever a change in the information carried within the EAT occurs. May return to zero when maximum value is reached
  • @eatSectionNumber attribute The number of the current section of the EAT, counting from one. If not present, it is set to the default value of 1.
  • @totalEatSectionNumbers attribute: The total number of sections of the EAT to which this section belongs (ie, the section with the highest @eatSectionNumber value). @eatSectionNumber and @totalEatSectionNumbers may be considered together to indicate "Part M of N" of a portion of the EAT when the EAT is sent to the fragment. If not present, it is set to the default value of 1.
  • eaMessage element Represents an EA message entry. Description of elements or attributes included in the eaMessage element of FIG. 23 is as follows.
  • @burnedIn attribute Indicates that the banner text and associated auditory sound are burned in to the video / audio. If true, the banner is burned in. If not present, the default value is 'true'.
  • @messageId attribute An integer number that uniquely identifies this EA message.
  • @eaServiceId attribute When rich media content is delivered via broadcast delivery or unicast delivery, this service ID indicates the service ID that is mapped in the SLT. This service may have a special type of category. This service will not be shown to users in the channel map.
  • This element is the banner information. This element contains banner text and audio sound information.
  • @lang attribute Represents the language of eaBanner. If not present, the default value is "ENG".
  • bannerText element String value for EA banner text.
  • bannerSound element Media resource of the EA sound.
  • @xmlmime contentType attribute: The mim type of the EA audio content. After the receiver has obtained the overall binary hex digit value embedded in CAT, the receiver can use this property to know what the file type is.
  • CAPMessage element CAP formatted message
  • alert This element contains an ⁇ alert> element of a CAP message that has been extended or profiled for use in ATSC 3.0 Advanced EA.
  • 31 illustrates a signaling structure of rich media content according to another embodiment of the present invention.
  • the EA-related rich media content may be transmitted through broadcast or broadband.
  • 31 shows a signaling structure for the case where rich media content is streamed into a broadcast. That is, in the embodiment of FIG. 31, the rich media content is provided as an EAS NRT service.
  • EAS NRT service may also be referred to as EA service.
  • the EA information may include an ID of a service for transmitting EA-related rich media content.
  • the EA information may include an EAS message for one or more EAS services, and each EAS message may include an ID of an EAS service through which EA related rich media content is transmitted.
  • the EAS service IDs for each EAS service are 0x10EA and 0x20EA.
  • the broadcast receiver may identify an ID of a service for transmitting rich media content from an EAS message for each EAS service, and may check SLS information about a service having the corresponding ID from the SLT information. That is, the broadcast receiver identifies the corresponding service to which the rich media content is transmitted among the services in the SLT information by using the service ID, and resource information (IP information, port information, TSI-) for the SLS signaling information about the service. SLS information, etc.) can be obtained. Thereafter, the broadcast receiver may acquire SLS information for each service that delivers EA-related rich media content, and receive corresponding service data, that is, rich media content, using the SLS information. Rich media content may be received in an LCT session.
  • the service category information of the SLT may include an EAS service category.
  • Table 1 below shows service category information of the SLT.
  • the service category information (service_category) included in the SLT information is a service category such as linear A / V service, linear audio only service, and app-based service.
  • the EAS service may be further included.
  • the EAS NRT service may be referred to as an EAS service.
  • the URL type information means information indicating a type of URL for at least one of a signaling server, an ESG server, or a rich media content server.
  • the URL type information is URL type information included in the sltInetUrl element in the SLT
  • the URL type information is related to a base URL for obtaining an ESG or SLS file available through broadband for all services in the SLT. It may be type information.
  • the URL type information is URL type information included in the svcInentUrl element in the Service element in the SLT
  • the corresponding URL type information may be type information on a URL for accessing internet signaling for the corresponding service.
  • the EA-related rich media content may be transmitted through broadcast or broadband.
  • 32 shows a signaling structure for a case in which rich media content is transmitted over broadband.
  • the EA information may include one or more EAS messages.
  • FIG. 32 descriptions overlapping with those described in FIG. 31 are omitted.
  • the EAS message may include URI information for EA related rich media content.
  • an EAS message (Message # 1) formatted in the form of a CAP message may contain a uri subelement containing URI information for rich media content in a resource subelement in an info subelement in an alert element. Can be.
  • the broadcast receiver may use the URI information to receive EA related rich media content over broadband.
  • the EA information includes URL information for each resource, the broadcast receiver may directly obtain EA-related rich media content through broadband using only the EA information.
  • the EAS message may include a service ID for the EAS service.
  • the EAS message (Message # 2) may include an EAS service ID (0x20EA).
  • the broadcast receiver may identify the ID of the EAS service through which the rich media content is transmitted from the EA information, and may check URI information about the rich media content from the SLT information. That is, the broadcast receiver may identify a service through which rich media content is transmitted in the SLT information, and obtain URL information about the service. The broadcast receiver may use this URL information to receive service data, that is, rich media content, over broadband.
  • the EA information includes the EAS service ID instead of the URI information
  • the broadcast receiver may acquire EA-related rich media content through broadband using other signaling structures such as EA information and SLT.
  • ENRT-IT EA related NRT information table
  • table_id Unique ID of the table granted to the ENRT-IT table.
  • service_id The identifier of the EAS NRT service specified by the EAT as the service associated with the EA.
  • num_rich_media_contents Number of rich media content delivered via EAS NRT service
  • content_linkage Specifies a value mapped with Content_linkage specified in the FDT (File Delivery Table).
  • the receiver may use this value to obtain information of each file defined in the FDT. It may indicate a URL that matches the content-location attribute of the file element in the FDT of the LCT channel that delivers the file.
  • time_slot_info time_slot information of the content
  • content_description_length The length of the description string that indicates brief information about the content
  • content_description a string representing brief information about the content
  • name_length the length of the name of the content
  • availableOnInet flag indicating whether acquisition of corresponding content is available via broadband
  • content_url_length Broadband URL length of the content
  • content_url the broadband URL of the content
  • FIG. 34 illustrates ENRT-IT syntax for rich media content signaling according to another embodiment of the present invention.
  • the embodiment of FIG. 34 proposes a structure of EA information (ENRT-IT table) composed of one or more EA related rich media contents.
  • EA information EA information
  • FIG. 34 illustrates ENRT-IT syntax for rich media content signaling according to another embodiment of the present invention.
  • the embodiment of FIG. 34 proposes a structure of EA information (ENRT-IT table) composed of one or more EA related rich media contents.
  • the same fields as in FIG. 33 in the table of FIG. 34 will not be duplicated.
  • the signaling structure shown as the embodiment of FIG. 34 can be extended to have more elements and attributes.
  • elements and attributes included in the ENRT-IT table (EA information) of FIG. 34 will be described.
  • the ENRT-IT table (ENRT-IT) may be referred to as AEAT.
  • the EAT may include one or more EA messages, and the EA messages may be formatted with a predefined message structure (eg, the CAP message format structure described above or a newly defined message format structure).
  • a predefined message structure eg, the CAP message format structure described above or a newly defined message format structure.
  • Each EA message transmits the fields associated with EA-related content, such as the required fields defined by the CAP and the universal alerts and advanced alerts requested by the EAS framework of next generation broadcast systems. May contain fields for.
  • @enrtitSectionVersion attribute Version number of the ENRT-IT section. This property may be increased by one whenever a change in the information carried within the ENRT-IT occurs. May return to zero when maximum value is reached
  • @enrtitSectionNumber attribute The number of the current section of the ENRT-IT, counting from 1; If not present, it is set to the default value of 1.
  • @totalEnrtitSectionNumbers attribute: The total number of sections of the ENRT-IT to which this section belongs (ie, the section with the highest @eatSectionNumber). @enrtitSectionNumber and @totalEnrtitSectionNumbers can be considered together to indicate “Part M of N” of a part of ENRT-IT when EAT is sent to the fragment. If not present, it is set to the default value of 1.
  • @serviceId attribute Identifier of the EAS NRT service.
  • the service has an SLS that includes an ENRT-IT for information about rich media content.
  • eaRichMediaContent element one EA rich media content
  • @contentLinkage attribute An integer value given for each rich media content. This value must map to the content linkage attribute described in the EFDT (for broadcast delivery)
  • url element URL information for the receiver to request the download of content from the server
  • name element the name of the content
  • FIG. 35 illustrates a signaling structure of rich media content according to an embodiment of the present invention.
  • FIG. 35 illustrates a signaling structure for a case where EA-related rich media content is streamed through a broadcast, similar to FIG. 31.
  • FIG. 35 descriptions overlapping with those described in FIGS. 31 to 34 will be omitted.
  • the EA information may include an ID of a service for transmitting EA-related rich media content
  • the ENRT-IT information may include content linkage information about the rich media content.
  • the content linkage information may include a value matching the ContentLinkage attribute in the FDT.
  • the broadcast receiver may identify an ID of a service for transmitting rich media content from EA information, and check SLS information for a service having the corresponding ID from the SLT information. For example, the broadcast receiver identifies a service through which rich media content is transmitted in the SLT information, and obtains resource information (IP information, port information, TSI-SLS information, etc.) for the SLS signaling information about the service. Can be.
  • the broadcast receiver may obtain SLS information about a service that delivers EA-related rich media content, and receive service data, that is, rich media content using the SLS information.
  • the broadcast receiver may acquire content linkage information included in the ENRT-IT information in the SLS information, and check the information of the corresponding file in the FDT using the content linkage information. In this way, the broadcast receiver may acquire EA-related rich media content. Rich media content may be received in an LCT session.
  • FIG. 36 illustrates a signaling structure of rich media content according to another embodiment of the present invention.
  • FIG. 36 shows a signaling structure for a case in which rich media content is transmitted over broadband, similar to FIG. 32.
  • FIG. 36 descriptions overlapping with those described in FIGS. 31 to 35 will be omitted.
  • the EA information may include a service ID for the EAS service
  • the ENRT-IT information may include URL information about EA-related rich media content.
  • the broadcast receiver may identify an ID of a service for transmitting rich media content from EA information, and may check SLS information for a service having the corresponding ID from the SLT information. For example, the broadcast receiver identifies a service through which rich media content is transmitted in the SLT information, and obtains resource information (IP information, port information, TSI-SLS information, etc.) for the SLS signaling information about the service. Can be.
  • the broadcast receiver may obtain SLS information about a service that delivers EA-related rich media content, and receive service data, that is, rich media content using the SLS information.
  • the broadcast receiver may acquire the rich media content file through broadband using URL information included in the ENRT-IT information in the SLS information.
  • the EA information may or may not wake up the receiver based on the priority of the information.
  • a wake up indicator may be signaled for this purpose.
  • the receiver may wake up only when EA information having a priority higher than a specific value is received based on the priority.
  • the wake up operation may occur when the TV or broadcast receiver is turned off or in standby mode.
  • the broadcast receiver should not wake up for the same EA information.
  • the wakeup indicator and / or wakeup version may be signaled so that the receiver knows whether the wakeup signal is the same wakeup signal or a new / updated wakeup signal. If multiple alert messages are received at the same time, the highest priority message should wake up the broadcast receiver. In this case, the broadcast receiver may display all EA information in the order of priority.
  • FIG. 37 is a diagram illustrating a wake-up information and EA information processing method of a broadcast receiver according to an embodiment of the present invention.
  • FIG. 37A illustrates a case of using a version of the wake-up signal itself
  • FIG. 37B illustrates a case of using a version of the EA message.
  • the broadcast receiver may decode the bootstrap signal of the signal frame of the physical layer.
  • the bootstrap signal of the physical layer frame serves as an entry point for the transmitted signal and has a fixed configuration known to all receivers.
  • the bootstrap information may include wakeup information (eas_wake_up or ea_wake_up).
  • the broadcast receiver may wake up from the standby mode to the active mode based on the value of the wakeup information.
  • the wakeup information may be one bit of wakeup indication information indicating the wakeup of the receiver.
  • the broadcast receiver in the standby mode may decode L1 signaling information and check wakeup version information included in the L1 signaling information. If the wakeup version is new, the user may enter the active mode and acquire the EA information (EAT).
  • EAT EA information
  • the broadcast receiver entering the active mode may acquire EA information and check version information of EA information included in the EA information. And if the version is new, EA information can be processed.
  • the wakeup information may include version information for determining whether to acquire or process wakeup indication information or EA information indicating wakeup of the receiver.
  • the version information may indicate the version of the wakeup information or the version of the EA information.
  • the receiver may not need to acquire and process the EA information, thereby further reducing unnecessary processing of the receiver.
  • wakeup indication information and version information may be referred to as wakeup information.
  • a signal frame of a physical layer may include bootstrap information and physical layer signaling (PLS) information, and the PLS information may provide L1 signaling information.
  • the bootstrap information may provide wakeup indication information
  • the L1 signaling information may provide wakeup version information.
  • the wakeup indication information provided by the bootstrap information may consist of 1 bit.
  • the wakeup indication information may be configured with a flag of 1 bit.
  • the wakeup instruction information and the wakeup version information may be collectively referred to as wakeup information.
  • the receiver detects the wakeup information and accordingly wakes up to process and provide the EA information.
  • EA information may include information that a hurricane is coming.
  • the receiver detects the wakeup information.
  • the wakeup information detected by the receiver includes wakeup indication information and wakeup version information.
  • the wakeup instruction information in the wakeup information indicates the wakeup of the receiver, but the wakeup version information indicates the same version as the wakeup version information received at time t1. Thus, the receiver may not wake up.
  • the receiver detects the wakeup information.
  • the wake indication information in the wakeup information detected by the receiver indicates a wakeup of the receiver, and the wakeup version information has a higher version than the wakeup version information received at time t2. Therefore, the receiver may wake up to process and provide EA information.
  • EA information may include new information that a tornado is coming.
  • the wakeup information includes wakeup version information as well as wakeup instruction information delivered in the physical layer, so that the receiver wakes up again unnecessarily to process the same EA information when the same version of EA information is received again. And it does not need to provide.
  • 39 illustrates an operation of a broadcast receiver according to wake up information according to another embodiment of the present invention.
  • the signal frame of the physical layer may provide bootstrap information.
  • Signaling information of the physical layer including bootstrap information may be referred to as physical layer signaling information.
  • the bootstrap information may include a wakeup signal that provides the wakeup information to the receiver.
  • the wakeup information may be information indicating wakeup from the standby mode of the receiver or information indicating whether the wakeup of the receiver and a version of the wakeup are performed.
  • the wakeup signal provided by the bootstrap information may consist of two bits.
  • the wakeup signal may consist of a two bit flag. This wakeup signal may be referred to as wakeup information, wakeup bit, or wakeup indicator.
  • the receiver detects the wakeup signal.
  • the wakeup signal may indicate that the wakeup signal is a wakeup call indicating the wakeup of the receiver.
  • the receiver may wake up to process and provide EA information.
  • EA information may include information that a hurricane is coming.
  • the wakeup signal may indicate that the wakeup information is not a wakeup call indicating the wakeup of the receiver.
  • the receiver may not wake up.
  • the receiver detects the wakeup signal. As shown, the wakeup signal is not "00", but includes the same value ("10") as the wakeup information received at time t1. Thus, the receiver may determine that the wakeup information is not new and may not wake up. That is, the receiver may confirm that the version of the wakeup has not changed and may not wake up.
  • the receiver detects the wakeup signal.
  • the wakeup signal is not "00" and includes a different value ("11") from the wakeup signal received at the time t2.
  • the wakeup signal may indicate that the wakeup information is a new wakeup call. That is, it may indicate that the version of the wakeup has been changed. Accordingly, the receiver may determine that the wakeup information is new, wake up, and process and provide the EA information.
  • EA information may include new information that a tornado is coming.
  • the wake-up signal is composed of two bits of information provided by the bootstrap information, so that the receiver does not need to detect separate L1 signaling information, and checks whether the wake-up instruction and the new version of the wake-up information. Can be.
  • the receiver has an advantage of not needing to wake up again unnecessarily to process and provide the same EA information when the same version of the EA information is received again.
  • FIG. 40 illustrates a broadcast signal transmission method according to an embodiment of the present invention.
  • the broadcast transmitter may generate first level signaling information about broadcast service data in operation S40010.
  • the broadcast service data is data supporting a function provided by the broadcast service and may include at least one of audio, video, and text data.
  • Broadcast service data may be referred to as a service data component or a service component.
  • the first level signaling information may be signaling information including information for discovery and acquisition of broadcast service data.
  • the first level signaling information is signaling transmitted at the level of the delivery layer and may be, for example, the above-described service layer signaling (SLS) information (eg, ROUTE SLS information or MMT SLS information).
  • SLS service layer signaling
  • the broadcast transmitter may encode the broadcast service data and the first level signaling information on the basis of the delivery protocol (S40020).
  • the delivery protocol in which the broadcast service data and the first level signaling information are encoded includes at least one of a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.
  • ROUTE Real-Time Object Delivery over Unidirectional Transport
  • MMT MPEG Media Transport
  • the same delivery protocol may be applied to the broadcast service data and the SLS information. That is, when broadcast service data is encoded in the MMT protocol, the first level signaling information for the broadcast service data may be encoded in the MMT protocol.
  • the first level signaling information for the broadcast service may be encoded in the MMT protocol.
  • the broadcast transmitter may generate second level signaling information on broadcast service data in operation S40030.
  • the second level signaling information includes at least one of first signaling information for providing discovery of the first level signaling information and building a basic service list, and second signaling information for providing information related to an Emergency Alert (EA). It may include one.
  • the first level signaling information is signaling transmitted at the level of the IP / UDP layer.
  • the first level signaling information may be the above-described low level signing (LLS) information.
  • the first signaling information in the first level signaling information may be the above-described Service List Table (SLT) information
  • the second signaling information may be EA related signaling information, for example, the above-described CAP message or EAT information (or AEAT information). have.
  • the first level signaling when the first level signaling information includes only the first signaling information, the first level signaling may be the SLT itself which is the first signaling information.
  • the first level signaling may be EA related signaling information that is second signaling information, for example, CAP message or EAT information (or AEAT information) itself.
  • the SLT information when the first signaling information is SLT information, the SLT information includes service category information as described above.
  • the service category information may include a linear A / V service, a linear audio only service, an app-based service, and an EA service (EAS service) as shown in Table 1.
  • EAS service EA service
  • rich media content can be delivered to an EA service.
  • the EA related signaling information includes service ID information for delivering rich media content.
  • the EA related signaling information may include identification information about an audio component for the EA.
  • the identification information for the audio component may be a representation ID of the audio component and may be a value mapped to the representation ID in the first level signaling information.
  • the first level signaling information includes a first fragment including property information on an attribute of an audio component having identification information and a second fragment including location information on a location at which the audio component having identification information is delivered. can do.
  • the first level signaling information is ROUTE SLS information
  • the first fragment information may be the above-described MPD information
  • the second fragment information may be the above-mentioned S-TSID information.
  • the attribute information of the first fragment may include at least one of mime type information, codec information, and language information about the audio component.
  • the attribute information of the first fragment may further include first extension information indicating that the audio component is a secondary audio component or second extension information indicating that the audio component is an audio component for the EA.
  • the secondary audio component may be an audio component different from an audio component constituting a linear service (eg, a linear A / V service or a linear audio only service).
  • the location information may include at least one of IP information, port information, and TSI information for the audio component.
  • the receiver may quickly receive / decode the EA related message / content and thus may be used by the user.
  • compatibility may be enhanced by using EA-related signaling information as a CAP message.
  • the EA related rich media content may be transmitted separately from the EA related signaling information and may be transmitted by broadcasting or broadband.
  • the EA related signaling information provides the resource information (URL information and / or LCT channel information) needed for the receiver to receive the rich media content in broadcast / broadband. Therefore, even if the receiver does not receive the rich media content through one path, the receiver can receive the rich media content through the other path, thereby increasing the reliability of EA content delivery in a disaster situation.
  • rich media content may be provided as an EA.
  • the EA related signaling information may include signaling information for transmitting EA related rich media content.
  • the EA related signaling information may indicate uniform resource locator (URL) information capable of receiving the rich media content.
  • URL uniform resource locator
  • the EA related signaling information may indicate LCT channel information through which the rich media content is delivered.
  • the broadcast transmitter may encapsulate broadcast service data, first level signaling information, and second level signaling information, respectively, by User Datagram Protocol (UDP) / Internet Protocol (IP) (S40040).
  • UDP User Datagram Protocol
  • IP Internet Protocol
  • the UDP / IP encapsulated broadcast service data, the first level signaling information, and the second level signaling information may be identified as an IP packet by an IP address and a port number. Therefore, data transmitted by the broadcast transmitter according to the present invention may be operated / identified based on IP.
  • the second level signaling information can be encapsulated into an IP packet having a predetermined address. That is, the second level signaling information may be carried in an IP packet having a predetermined address.
  • the LLS information can be carried as a payload of an IP packet having a well-known address and port number.
  • the broadcast transmitter may generate a signal frame by performing physical layer processing on the broadcast service data, the first level signaling information, and the second level signaling information (S40050).
  • the signal frame may include third level signaling information.
  • the third level signaling information is signaling transmitted at the level of the physical layer and may be physical layer signaling including a bootstrap signal and / or L1 signaling information.
  • the third level signaling information may include a wakeup signal for providing wakeup information to the receiver.
  • the wakeup signal may consist of a value of two bits.
  • the wakeup information may be information indicating wakeup from the standby mode of the receiver, or information indicating whether the wakeup of the receiver and a version of the wakeup are performed.
  • the wakeup signal when the wakeup signal is '00', the wakeup signal may indicate that the wakeup information is not a wakeup call indicating the wakeup of the receiver. In addition, when the wakeup signal is not '00', the wakeup signal may indicate that the wakeup information is a wakeup call indicating the wakeup of the receiver. In addition, when the wakeup signal is not '00' and has a different value from the previous wakeup signal, the wakeup signal may indicate that the wakeup information is a new wakeup call.
  • 41 illustrates a broadcast signal transmitter and a broadcast signal receiver according to an embodiment of the present invention.
  • the broadcast signal transmitter 41100 may include a signaling generator 41110, a delivery layer encoder 41120, a UDP / IP encapsulator 41130, and a physical layer processor 41140.
  • the signaling generator 41110 may generate first level signaling information and second level signaling information for broadcast service data.
  • the first level signaling information may include information for discovery and acquisition of broadcast service data
  • the second signaling information may include information for providing discovery of the first level signaling information and building a basic service list. It may include at least one of the first signaling information and the second signaling information for providing information related to an Emergency Alert (EA).
  • EA Emergency Alert
  • the delivery layer encoder 41120 may encode broadcast service data and first level signaling information based on a delivery protocol.
  • the delivery protocol may include at least one of a Real-Time Object Delivery over Unidirectional Transport (ROUTE) protocol or an MPEG Media Transport (MMT) protocol.
  • ROUTE Real-Time Object Delivery over Unidirectional Transport
  • MMT MPEG Media Transport
  • the UDP / IP encapsulator 41130 may encapsulate broadcast service data, first level signaling information, and second level signaling information, respectively.
  • the physical layer processor 41140 may generate a signal frame by performing physical layer processing on the broadcast service data, the first level signaling information, and the second level signaling information.
  • the broadcast signal transmitter 4100 of FIG. 41 performs the above-described broadcast signal transmission method, and the same description is not repeated.
  • the broadcast signal receiver 41200 may include a signaling parser 4210, a delivery layer decoder 4220, a UDP / IP packet parser 41230, and a physical layer parser 41240.
  • the broadcast signal receiver 41200 may perform a reverse operation of the broadcast signal transmitter.
  • the physical layer parser 41240 may physically process the received signal frame and output a UDP / IP packet stream.
  • the UDP / IP packet parser 41230 may output the service component data by decapsulating the received IP packet stream.
  • the delivery layer decoder 41240 may decode service component data according to a delivery protocol.
  • the signaling parser 4210 may acquire and parse signaling information to control the operation of the broadcast signal receiver.
  • the broadcast signal receiver may acquire the SLT which is the second level signaling and parse the SLT to obtain the IP address and the port number of the SLS which is the necessary second level signaling.
  • the broadcast signal receiver may parse the SLS to obtain a transmission path of necessary service data.
  • the broadcast signal receiver may provide a corresponding broadcast service to a user by performing physical layer parsing, UDP / IP decapsulation, and delivery layer decoding of necessary broadcast data along the entire path.
  • subunits of the broadcast signal transmitter and the broadcast signal receiver are classified according to their operation. That is, one sub unit does not have to be implemented as one physical processor, one sub unit may be implemented by a plurality of physical processors, or a plurality of sub units may be implemented by one physical processor.
  • Each of the steps described in the above embodiments may be performed by hardware / processors.
  • Each module / block / unit described in the above embodiments can operate as a hardware / processor.
  • the methods proposed by the present invention can be executed as code. This code can be written to a processor readable storage medium and thus read by a processor provided by an apparatus.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor.
  • Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet.
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention is used in the field of transmitting / receiving a series of broadcast signals.

Landscapes

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

Abstract

L'invention concerne un procédé d'émission de signal de radiodiffusion. Le procédé d'émission de signal de radiodiffusion, selon un mode de réalisation de la présente invention, comporte les étapes suivantes: une couche de distribution traite des données de service de radiodiffusion et des informations de signalisation sur les données de service de radiodiffusion; une couche de liaison traite les données de service de diffusion et les informations de signalisation sur les données de service de diffusion; et une couche physique traite les données de service de radiodiffusion et les informations de signalisation sur les données de service de radiodiffusion.
PCT/KR2016/007548 2015-07-12 2016-07-12 Appareil et procédé d'émission et de réception de signal de radiodiffusion WO2017010785A1 (fr)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201562191470P 2015-07-12 2015-07-12
US62/191,470 2015-07-12
US201562195803P 2015-07-23 2015-07-23
US62/195,803 2015-07-23
US201562205766P 2015-08-17 2015-08-17
US62/205,766 2015-08-17
US201562209853P 2015-08-25 2015-08-25
US62/209,853 2015-08-25

Publications (1)

Publication Number Publication Date
WO2017010785A1 true WO2017010785A1 (fr) 2017-01-19

Family

ID=57757130

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/007548 WO2017010785A1 (fr) 2015-07-12 2016-07-12 Appareil et procédé d'émission et de réception de signal de radiodiffusion

Country Status (1)

Country Link
WO (1) WO2017010785A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113170222A (zh) * 2018-11-23 2021-07-23 索尼集团公司 用于电视机和电子设备的电视接收器应用

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012161552A2 (fr) * 2011-05-25 2012-11-29 엘지전자 주식회사 Système de transmission/de réception et procédé permettant de traiter un signal de diffusion
KR20140126210A (ko) * 2013-04-22 2014-10-30 삼성전자주식회사 Ｄｖｂ 지상파 방송 시스템에서 ｍｐｅｇ ｍｍｔ를 위한 시그널링 정보를 송수신하는 장치 및 방법
US8880019B1 (en) * 2007-02-12 2014-11-04 At&T Mobility Ii Llc Emergency alert system (EAS) message service profile
WO2015023098A1 (fr) * 2013-08-12 2015-02-19 엘지전자 주식회사 Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, procédé d'émission de signal de diffusion, et procédé de réception de signal de diffusion.
WO2015056401A1 (fr) * 2013-10-18 2015-04-23 Sony Corporation Dispositif et procédé de réception destinés à recevoir des informations d'alerte d'urgence, programme d'ordinateur et dispositif externe

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8880019B1 (en) * 2007-02-12 2014-11-04 At&T Mobility Ii Llc Emergency alert system (EAS) message service profile
WO2012161552A2 (fr) * 2011-05-25 2012-11-29 엘지전자 주식회사 Système de transmission/de réception et procédé permettant de traiter un signal de diffusion
KR20140126210A (ko) * 2013-04-22 2014-10-30 삼성전자주식회사 Ｄｖｂ 지상파 방송 시스템에서 ｍｐｅｇ ｍｍｔ를 위한 시그널링 정보를 송수신하는 장치 및 방법
WO2015023098A1 (fr) * 2013-08-12 2015-02-19 엘지전자 주식회사 Appareil d'émission de signal de diffusion, appareil de réception de signal de diffusion, procédé d'émission de signal de diffusion, et procédé de réception de signal de diffusion.
WO2015056401A1 (fr) * 2013-10-18 2015-04-23 Sony Corporation Dispositif et procédé de réception destinés à recevoir des informations d'alerte d'urgence, programme d'ordinateur et dispositif externe

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113170222A (zh) * 2018-11-23 2021-07-23 索尼集团公司 用于电视机和电子设备的电视接收器应用
CN113170222B (zh) * 2018-11-23 2023-08-04 索尼集团公司 用于电视机和电子设备的电视接收器应用

Similar Documents

Publication Publication Date Title
WO2017014586A1 (fr) Dispositif et procédé d'émission et de réception de signal de radiodiffusion
WO2016186407A1 (fr) Appareil et procédé d'émission ou de réception de signal de diffusion
WO2017204546A1 (fr) Dispositif et procédé d'émission/réception de signaux de diffusion
WO2016144072A1 (fr) Appareil et procédé pour émettre et recevoir un signal de radiodiffusion
WO2016060422A1 (fr) Dispositif et procédé d'émission de signal de diffusion, dispositif et procédé de réception de signal de diffusion
WO2016076623A1 (fr) Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion et procédé de réception de signal de diffusion
WO2016140486A1 (fr) Appareil et procédé d'émission/réception de signal de diffusion
WO2016076569A1 (fr) Appareil de transmission de signaux de diffusion, appareil de réception de signaux de diffusion, procédé de transmission de signaux de diffusion, et procédé de réception de signaux de diffusion
WO2016093537A1 (fr) Dispositif de transmission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé de transmission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2016076654A1 (fr) Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion et procédé de réception de signal de diffusion
WO2016111526A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2016126116A1 (fr) Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion et procédé de réception de signal de diffusion
WO2016093576A1 (fr) Appareil de transmission de signal de radiodiffusion, appareil de réception de signal de radiodiffusion, procédé de transmission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2017007224A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2016060416A1 (fr) Dispositif d'émission d'un signal de diffusion, dispositif de réception d'un signal de diffusion, procédé d'émission d'un signal de diffusion, et procédé de réception d'un signal de diffusion
WO2016153241A1 (fr) Dispositif d'émission de signal de radiodiffusion, dispositif de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion et procédé de réception de signal de radiodiffusion
WO2016064151A1 (fr) Dispositif d'émission de signal de diffusion, dispositif de réception de signal de diffusion, procédé d'émission de signal de diffusion, et procédé de réception de signal de diffusion
WO2018101566A1 (fr) Dispositif et procédé d'émission/réception de signal de radiodiffusion
WO2016068564A1 (fr) Appareil et procédé d'émission de signal de diffusion, appareil et procédé de réception de signal de diffusion
WO2017209514A1 (fr) Dispositif et procédé d'émission et de réception de signal de diffusion
WO2016122269A1 (fr) Dispositif de transmission de signaux de radiodiffusion, dispositif de réception de signaux de radiodiffusion, procédé de transmission de signaux de radiodiffusion et procédé de réception de signaux de radiodiffusion
WO2019093829A1 (fr) Appareil de transmission de diffusion, procédé de transmission de diffusion, appareil de réception de diffusion, et procédé de réception de diffusion
WO2017061792A1 (fr) Dispositif et procédé d'émission/réception de signal de diffusion
WO2016114638A1 (fr) Appareil de transmission de signal de radiodiffusion, appareil de réception de signal de radiodiffusion, procédé de transmission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion
WO2016129904A1 (fr) Appareil d'émission de signal de radiodiffusion, appareil de réception de signal de radiodiffusion, procédé d'émission de signal de radiodiffusion, et procédé de réception de signal de radiodiffusion

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: 16824702

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16824702

Country of ref document: EP

Kind code of ref document: A1