Broadcast transmission device, broadcast transmission method, broadcast reception device, and broadcast reception method

Abstract

A reception method for receiving a broadcast signal is disclosed. The reception method according to embodiments may comprise the steps of: receiving a broadcast signal; physical layer processing the broadcast signal to obtain link layer packets; link layer processing the link layer packets to obtain UDP / IP packets; UDP / IP layer processing the UDP / IP packets to obtain first data packets based on a first delivery protocol or second data packets based on a second delivery protocol; and processing the first data packets or the second data packets to obtain service data for a first service or service data for a second service.

Description

Broadcast transmitting device, broadcast transmitting method, broadcast receiving device and broadcast receiving method

[0001] This document relates to a broadcast transmitting device, a broadcast transmitting method, a broadcast receiving device, and a broadcast receiving method, and particularly to a device and method for providing external services using the ATSC (Advanced Television Systems Committee, Inc.) 3.0 system.

[0002] ATSC 3.0 is the ATSC standard for terrestrial television broadcasting developed by ATSC. It is designed to support cutting-edge technologies, including High Efficiency Video Coding (HEVC) for video channels with up to 4K resolution at 120 frames per second, wide color gamut, high dynamic range, Dolby AC-4 and MPEG-H 3D audio, datacasting capabilities, and more robust mobile television support.

[0003] The purpose of this document is to provide a device and method for providing external services not defined in ATSC 3.0 using an ATSC 3.0 broadcasting system.

[0004] The purpose of this document is to provide a device and method for providing a DRM (Digital Radio Mondiale)-based service using an ATSC 3.0 broadcasting system.

[0005] However, the scope of the embodiments is not limited to the aforementioned technical tasks, and the scope of the embodiments may be expanded to other technical tasks that can be inferred by a person skilled in the art based on the entire contents of this document.

[0006] In order to achieve the above-described object and other advantages, a receiving method according to embodiments may include the steps of receiving a broadcast signal, performing physical layer processing of the broadcast signal to obtain link layer packets, performing link layer processing of the link layer packets to obtain UDP / IP packets, performing UDP / IP layer processing of the UDP / IP packets to obtain first data packets based on a first delivery protocol or second data packets based on a second delivery protocol, and performing processing of the first data packets or the second data packets to obtain service data for a first service or to obtain service data for a second service.

[0007] According to embodiments, the first service may be a service defined in ATSC 3.0, and the second service may be a service not defined in ATSC 3.0.

[0008] According to embodiments, the first service may be one of a linear audio / video service, a linear audio-only service, an app-based service, an Electronic Service Guide (ESG) service, and a Digital Rights Management (DRM) data service, and the second service may be a Digital Radio Mondiale (DRM) service.

[0009] According to embodiments, the first delivery protocol may be a ROUTE (Real time Object delivery over Unidirectional Transport) protocol or an MMTP (MPEG Media Transport Protocol), and the second delivery protocol may be a DCP (Distribution and Communications Protocol).

[0010] According to embodiments, signaling information for obtaining the second service is encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets can be received by a receiving device by being encapsulated into one or more link layer packets.

[0011] According to embodiments, at least some of the signaling information for obtaining the second service may be carried via the first delivery protocol or the second delivery protocol.

[0012] According to embodiments, the receiving device may include a physical layer processor that receives a broadcast signal, performs physical layer processing on the received broadcast signal to obtain link layer packets, a link layer processor that performs link layer processing on the link layer packets to obtain UDP / IP packets, a UDP / IP layer processor that performs UDP / IP layer processing on the UDP / IP packets to obtain first data packets based on a first delivery protocol or second data packets based on a second delivery protocol, and a service processor that processes the first data packets or the second data packets to obtain service data for a first service or to obtain service data for a second service.

[0013] According to embodiments, the first service may be a service defined in ATSC 3.0, and the second service may be a service not defined in ATSC 3.0.

[0014] According to embodiments, the first service may be one of a linear audio / video service, a linear audio-only service, an app-based service, an ESG service, or a DRM (Digital Rights Management) data service, and the second service may be a DRM (Digital Radio Mondiale) service.

[0015] According to embodiments, the first delivery protocol may be a ROUTE protocol or MMTP, and the second delivery protocol may be DCP.

[0016] According to embodiments, signaling information for obtaining the second service may be encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets may be received encapsulated into one or more link layer packets.

[0017] According to embodiments, a transmission method may include a step of delivering service data for a first service based on a first delivery protocol, a step of delivering service data for a second service based on a second delivery protocol, a step of encapsulating at least one of service data for the first service delivered based on the first delivery protocol or service data for the second service delivered based on the second delivery protocol into UDP / IP packets, a step of encapsulating the UDP / IP packets into link layer packets, and a step of generating a broadcast signal by physical layer processing the link layer packets.

[0018] According to embodiments, the first service may be a service defined in ATSC 3.0, and the second service may be a service not defined in ATSC 3.0.

[0019] According to embodiments, the first service may be one of a linear audio / video service, a linear audio-only service, an app-based service, an ESG service, or a DRM (Digital Rights Management) data service, and the second service may be a DRM (Digital Radio Mondiale) service.

[0020] According to embodiments, the first delivery protocol may be a ROUTE protocol or MMTP, and the second delivery protocol may be DCP.

[0021] According to embodiments, signaling information for obtaining the second service may be encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets may be encapsulated into one or more link layer packets.

[0022] According to embodiments, at least some of the signaling information for obtaining the second service may be carried via the first delivery protocol or the second delivery protocol.

[0023] According to embodiments, when a link layer packet generator that generates link layer packets through the encapsulation is located outside a broadcast gateway, the link layer packets may be transmitted to the broadcast gateway based on ALPTP (ALP Transport Protocol), and the link layer packets may be transmitted from the broadcast gateway to a receiving device based on STLTP (STL Transport Protocol).

[0024] According to embodiments, when a link layer packet generator that generates link layer packets through the encapsulation is located inside a broadcast gateway, the link layer packets can be transmitted to a receiving device based on STLTP.

[0025] According to embodiments, a computer program stored on a computer-readable recording medium can be combined with a computer, which is hardware, to perform the above method.

[0026] The above-described solutions are only some of the various embodiments of this specification, and those skilled in the art to which this specification pertains can infer modified embodiments that reflect the technical features of this specification through the overall intent described in this specification.

[0027] The device and method according to the embodiments propose an ATSC 3.0 protocol stack for providing external services not defined in ATSC 3.0, and in particular, by packetizing data and service signaling information for external services into IP / UDP packets and then packetizing them again into link layer packets for transmission, there is an effect that external services not defined in ATSC 3.0 can be provided through an ATSC 3.0 system without modifying the ATSC 3.0 standard.

[0028] The device and method according to the embodiments propose an ATSC 3.0 protocol stack for providing a DRM (Digital Radio Mondiale) service, and in particular, by packetizing data and service signaling information for the DRM (Digital Radio Mondiale) service into IP / UDP packets and then packetizing them again into link layer packets for transmission, there is an effect that the DRM (Digital Radio Mondiale) service can be provided through an ATSC 3.0 system without modifying the ATSC 3.0 standard.

[0029] In addition to the technical effects explicitly mentioned above, effects that are obvious to those skilled in the art can also be inferred from the entire description of this specification.

[0030] The drawings are included to further understand the embodiments, and the drawings illustrate the embodiments together with the description related to the embodiments.

[0031] FIG. 1 is a diagram illustrating an example of a protocol stack for a service according to embodiments.

[0032] FIG. 2 is a diagram illustrating an example of an LLS table according to embodiments.

[0033] FIGS. 3A to 3C are diagrams showing an example of the syntax structure of SLT according to embodiments.

[0034] FIG. 4 is a diagram illustrating an example of a link layer protocol architecture according to embodiments.

[0035] FIG. 5 is a diagram illustrating the operation of a link layer when an input packet according to embodiments is an IP packet.

[0036] FIG. 6 illustrates an example of the structure of a physical layer processor in a transmitting device according to embodiments.

[0037] FIG. 7 is a diagram showing an example of an ATSC 3.0 system architecture according to embodiments.

[0038] FIG. 8 is a diagram illustrating another example of an ATSC 3.0 protocol stack for external services according to embodiments.

[0039] FIG. 9 is a diagram showing an example of a DRM content server according to embodiments.

[0040] FIG. 10 is a diagram showing another example of an ATSC 3.0 system architecture according to embodiments.

[0041] FIG. 11 is a diagram showing another example of an ATSC 3.0 system architecture according to embodiments.

[0042] FIG. 12 is a diagram showing another example of an ATSC 3.0 system architecture according to embodiments.

[0043] FIG. 13 is a diagram showing another example of an ATSC 3.0 system architecture according to embodiments.

[0044] FIG. 14 is a diagram illustrating an example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0045] FIG. 15 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0046] FIG. 16 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0047] FIG. 17 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0048] FIG. 18 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0049] FIG. 19 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments.

[0050] FIG. 20 is a diagram illustrating another example of an LLS table according to embodiments.

[0051] FIG. 21 is a drawing illustrating an example of a receiving device according to embodiments.

[0052] FIG. 22 is a diagram illustrating an example of a physical layer processor in a receiving device according to embodiments.

[0053] Hereinafter, embodiments disclosed in this specification will be described in detail with reference to the attached drawings. Regardless of the reference numerals used in the drawings, identical or similar components will be assigned the same reference numerals, and redundant descriptions thereof will be omitted. The following embodiments are intended to concretize the present disclosure and do not limit or restrict the scope of the present disclosure. Anything that a specialist in the technical field to which the present disclosure pertains can easily infer from the detailed description and embodiments of the present disclosure is interpreted as falling within the scope of the present disclosure.

[0054] The detailed description herein is not to be construed in any way as limiting, but rather as illustrative. The scope of this disclosure should be determined by a reasonable interpretation of the appended claims, and all changes within the equivalent scope of this disclosure are intended to be embraced therein.

[0055] Preferred embodiments are described in detail, examples of which are illustrated in the accompanying drawings. The following detailed description with reference to the accompanying drawings is intended to illustrate preferred embodiments rather than merely illustrate possible embodiments. The following description includes details to provide a thorough understanding of the present disclosure. However, it will be apparent to those skilled in the art that the present disclosure may be practiced without such details. Most of the terms used in this specification are selected from those commonly used in the relevant field, but some terms are arbitrarily selected by the applicant, and their meanings are described in detail in the following description as needed. Therefore, the present disclosure should be understood based on the intended meaning of the terms, not the simple name or meaning of the terms. In addition, the drawings and detailed description below should not be interpreted as being limited to the specifically described embodiments, but should be interpreted to include equivalents or alternatives to the embodiments described in the drawings and detailed description.

[0056] In this specification, ATSC 3.0 may be referred to as A3.

[0057] In this specification, the term 'broadcast signal' is defined as a concept that includes signals and / or data provided in interactive broadcasting such as Internet broadcasting, broadband broadcasting, communication broadcasting, data broadcasting, and / or VOD (Video On Demand), in addition to terrestrial broadcasting, cable broadcasting, satellite broadcasting, and / or mobile broadcasting.

[0058] In this specification, "PLP (Physical Layer Pipe)" refers to a specific unit that transmits data belonging to the physical layer. Therefore, the content designated as "PLP" in this specification may also be renamed as "data unit" or "data pipe."

[0059] In this specification, a signal frame (or frame, or A3 frame, or physical layer frame) is broadly divided into three regions. The first region located at the very front of the signal frame is called a bootstrap (or bootstrap region), the second region located immediately following the first region is called a preamble (or preamble region), and the third region located following the second region is called a data region.

[0060] The bootstrap region includes bootstrap data, and the preamble region includes L1 (Layer 1) signaling data (or L1 control signaling data) applicable to the remainder of the frame. The data region is further divided into one or more subframes. If a signal frame includes multiple subframes, the multiple subframes are concatenated together in time. A subframe consists of a set of time-frequency resources within the signal frame. That is, data transmitted to one or more PLPs is mapped to one or more subframes.

[0061] The above L1 signaling data provides the information necessary to configure physical layer parameters. The L1 signaling data includes L1 basic (L1-Basic) signaling data and L1 detail (L1-Detail) signaling data. At this time, bootstrap data may also be included in the L1 signaling data.

[0062] And, as an example, among the information included in the L1 signaling data described hereafter, information starting with L1B is information included in the L1-Basic signaling data, and information starting with L1D is information included in the L1-Detail signaling data.

[0063] FIG. 1 is a diagram illustrating an example of a protocol stack for ATSC 3.0 services according to embodiments.

[0064] According to embodiments, ATSC 3.0 services are delivered through multiple layers. The multiple layers may include a physical layer, a delivery layer, and a service management layer.

[0065] The above physical layer provides a mechanism to transport signaling, service announcements, and IP packet streams via the broadcast physical layer and / or the broadband physical layer.

[0066] The above delivery layer provides object and object flow transmission capabilities and is enabled by MMTP (MPEG Media Transport Protocol) or ROUTE (Real-time Object delivery over Unidirectional Transport). These operate in a UDP / IP multicast manner on the broadcast physical layer, and are enabled by the HTTP protocol based on TCP / IP unicast on the broadband physical layer.

[0067] The above service management layer supports service discovery and acquisition, and enables the provision of various types of services, such as linear TV or HTML5 application services, through the lower delivery layer and physical layer.

[0068] As shown in Fig. 1, there may be two methods for service delivery via a broadcast network in the present disclosure. In the present disclosure, the delivery layer may further include a UDP / IP layer and a link layer.

[0069] The first method relies on MMT (MPEG Media Transport), processing service data with MPUs (Media Processing Units) and transmitting it using MMTP (MMT protocol). For example, service components for linear services and / or their corresponding service signaling information can be delivered via MMTP. Here, the service signaling information can correspond to the service layer signaling (SLS) information described later.

[0070] The second method is to process service data into DASH segments based on MPEG DASH and transmit them via the ROUTE protocol. For example, service components for linear services, their corresponding service signaling information, and / or NRT data, etc. can be delivered via the ROUTE protocol. Here, the service signaling information can correspond to SLS information. As another example, service components processed into DASH segments, their corresponding service signaling information, and / or NRT data, etc. can be delivered via HTTP (Hypertext Transfer Protocol).

[0071] In the present disclosure, the types of ATSC 3.0 services may include linear audio / video service, linear audio-only service, app-based service, ESG (Electronic Service Guide) service, DRM (Digital Rights Management) data service, etc.

[0072] Here, the linear audio / video service is a streaming-based service comprising one or more continuous video components, one or more continuous audio components (each associated with one or more of the video components), and one or more closed caption components (each associated with one or more of the audio components). The linear audio / video service may include app-based features.

[0073] The linear audio transmission service is a streaming-based service comprising one or more continuous audio components and one or more closed caption components (each associated with one or more of the audio components). The linear audio-only service may include app-based features.

[0074] The above app-based service is a service that consists solely of app-based features that provide a user interface for the service.

[0075] The above app-based feature is a service consisting of an application, optional files to be used by the application, and optional notifications directing the application to take particular actions at particular times.

[0076] The above ESG service is a service that delivers ESG information.

[0077] The above DRM data service is a service that delivers arbitrary data to a specified DRM system.

[0078] In this disclosure, the rules for the presence of a ROUTE session and / or an MMTP session for carrying components of an ATSC 3.0 service are as follows.

[0079] a) When a linear service without app-based features is delivered over a broadcast network, the components of the service may be carried by one or more ROUTE sessions or one or more MMTP sessions.

[0080] b) When a linear service with app-based features is delivered over a broadcast network, the service's components may be carried by one or more ROUTE sessions and zero or more MMTP sessions. However, using both ROUTE and MMTP to stream components within the same service is not permitted.

[0081] c) When an app-based service, ESE service, or DRM data service is delivered via a broadcast network, the service components may be carried by one or more ROUTE sessions. In this case, the service data used for the app-based service may be carried by one or more ROUTE sessions in the form of NRT data or other files. In the case of hybrid service delivery, some service components or some NRT data, files, etc. of such services may be delivered via a broadband network.

[0082] d) When a data service is delivered over a broadcast network, components of the service may be carried by one or more ROUTE sessions or one or more MMTP sessions.

[0083] Each ROUTE session includes one or more LCT channels, which carry, in whole or in part, the components that make up an ATSC 3.0 service. In streaming service delivery, an LCT channel can carry individual components of a user service, such as audio, video, or closed caption streams. Streaming media is formatted as DASH segments.

[0084] Each MMTP session contains one or more MMTP packet flows that carry MMT signaling messages or all or part of their components. An MMTP packet flow may carry MMT signaling messages or components formatted as MPUs.

[0085] For the delivery of system metadata, such as app-based features or services and application signaling information, the LCT channel carries file-based content items. These content files can consist of applications, continuous (time-based) or discontinuous (i.e., non-time-based) components of app-based features, or metadata such as Service Layer Signaling (SLS) or ESG fragments. Furthermore, delivery of Service Layer Signaling (SLS) can be accomplished via the signaling message mode of MMTP.

[0086] In this disclosure, Service Signaling provides service discovery and description information and consists of two functional elements: Bootstrap Signaling via the Service List Table (SLT) and the Service Listing Service (SLS). These two elements represent the information required to discover and acquire ATSC 3.0 services.

[0087] The SLT enables the receiver to build a basic service list and bootstrap SLS discovery for each ATSC 3.0 service. The SLT enables very rapid acquisition of basic service information.

[0088] The above SLS enables the receiver to discover and access ATSC 3.0 services and their components.

[0089] According to embodiments, for ROUTE / DASH services delivered over a broadcast network, the SLS is carried on a signaling server or carried over ROUTE / UDP / IP on one of the LCT transport channels constituting a ROUTE session, and is repeated at an appropriate carousel cycle to support fast channel joins and switching. Furthermore, for MMTP / MPU streaming delivered over a broadcast network, the SLS is carried by MMTP signaling messages, and is also repeated at an appropriate carousel cycle to support fast channel joins and switching.

[0090] As described above, data processed according to the MMTP or ROUTE protocol can be processed as IP packets via the UDP (User Datagram Protocol) / IP (Internet Protocol) layer. That is, the UDP / IP layer adds a UDP header to a UDP payload containing data processed according to the MMTP or ROUTE protocol to create a UDP packet, and adds an IP header to the UDP packet to create an IP / UDP packet. In the present disclosure, for the convenience of explanation, the IP / UDP packet will be referred to as an IP packet. In transmitting service data through a broadcast network, the SLT (Service List Table) can also be transmitted in the form of an IP packet via the UDP / IP layer. The SLT can be transmitted by being included in the LLS (Low Level Signaling) table, and the SLT and LLS tables will be described later.

[0091] IP packets can be processed as link layer packets at the link layer. The link layer encapsulates various formats of data transmitted from upper layers into link layer packets and then passes them to the physical layer. The link layer is described later.

[0092] In hybrid service delivery, at least one service element can be delivered via a broadband path. In hybrid service delivery, data delivered via a broadband network may include service components in DASH format, service signaling information for the components, and / or NRT data. This data may be processed via HTTP / TCP / IP, passed through a link layer for broadband transmission, and then delivered to a physical layer for broadband transmission.

[0093] According to embodiments, signaling information carried as the payload of IP packets having a well-known IP address / port is referred to as LLS. For example, LLS is transmitted in IP packets having the address 224.0.23.60 and the destination port 4937 / udp. Each type of LLS information is in the form of an LLS table.

[0094] FIG. 2 is a diagram illustrating an LLS table according to embodiments.

[0095] In FIG. 2, the LLS table may include information according to the LLS_table_id field, the LLS_group_id field, the group_count_minus 1 field, the LLS_table_version field, and / or the LLS_table_id field.

[0096] The LLS_table_id field identifies the type of table being delivered as a body.

[0097] The LLS_group_id field links the LLS table (LLS_table()) to tables in the group with the same LLS_group_id. The scope of this field is the broadcast stream, meaning that the value of this field must be unique within the broadcast stream.

[0098] The group_count_minus1 field indicates the total number of distinct LLS table groups present in the current LLS packet stream or in the link layer packet stream carried by a specific PLP minus one. For example, a value of 0 in this field indicates that the LLS_table() has only one LLS_group_id value. A value of 1 indicates that there are LLS_table()s with two LLS_group_id values.

[0099] The LLS_table_version field can provide version information for the corresponding LLS table. For example, the value of this field is incremented by 1 whenever data in the table identified by the combination of the LLS_table_id and LLS_group_id fields changes.

[0100] According to embodiments, depending on the value of the LLS_table_id field, the LLS table may include one of an SLT (e.g., an LLS_table_id field having a value of 0x01), an RRT (Rating Region Table) (e.g., an LLS_table_id field having a value of 0x02), a System Time Fragment (e.g., an LLS_table_id field having a value of 0x03), an AEAT (Advanced Emergency Alert Table) (e.g., an LLS_table_id field having a value of 0x04), an Onscreen Message Notification fragment (e.g., an LLS_table_id field having a value of 0x05), and a SingnedMultiTable, which is a set of one or more LLS table instances (e.g., an LLS_table_id field having a value of 0xFE). In addition to these, other information may also be included in the LLS table depending on embodiments.

[0101] In this disclosure, SLT is one of the instance types of LLS information. The SLT supports fast channel scan, which allows the receiver to build a list of all receivable services, including information such as channel name and channel number. In addition, the SLT provides bootstrap information that allows the receiver to discover SLS for each service. That is, the SLT includes bootstrap information, which allows the receiver to acquire SLS for each service. For example, for ROUTE / DASH-delivered services, i.e., when the SLS is carried through ROUTE, the bootstrap information may include the source IP address, destination IP address, and destination port of the LCT channel carrying the SLS (i.e., the ROUTE-specific SLS). As another example, for MMTP / MPU-delivered services, i.e., where SLS is carried over MMT, the bootstrap information may include the destination IP address and destination port information of the MMTP session carrying the SLS (i.e., MMTP-specific SLS).

[0102] The above SLT supports rapid channel scanning and service acquisition by including the following information about each service in the broadcast stream: This information provides viewers with a meaningful list of services, allows them to select an initial service via channel number or up / down selection, and provides information necessary to find the SLS for each listed service.

[0103] FIGS. 3A to 3C are diagrams showing an example of the syntax structure of SLT according to embodiments.

[0104] Each field may be omitted or may exist multiple times depending on the value of the Use column shown.

[0105] The @bsid attribute may be an identifier of a broadcast stream that constitutes a service. The SLTCapabilities element may provide capability information required to decode and meaningfully present content for all services within the SLT. The SLTInetUrl element may provide base URL information used to obtain ESG or SLS files for services of the SLT via broadband. The SLTInetUrl element may further include the @urlType attribute, which may indicate the types of files that can be obtained through the URL. For example, if the @urlType attribute value is 1, the SLTInetUrl element represents the URL of a signaling server (which provides access to the SLS), and if the @urlType attribute value is 2, the SLTInetUrl element represents the URL of an ESG server (which provides access to ESG data). Additionally, if the @urlType attribute value is 3, the SLTInetUrl element represents the URL of the Service Usage Data Gathering Report server, and if the @urlType attribute value is 4, the SLTInetUrl element represents the URL of the Dynamic Event WebSocket server.

[0106] A Service element can be an element that contains information about the services described by the SLT, and there can be a Service element for each service. A Service element can contain a @serviceId attribute, a @globalServiceID attribute, a @sltSvcSeqNum attribute, a @protected attribute, a @majorChannelNo attribute, a @minorChannelNo attribute, a @serviceCategory attribute, a @shortServiceName attribute, a @hidden attribute, a @hideInGuide attribute, a @broadbandAccessRequired attribute, an @essential attribute, a @drmSystemID attribute, a @configuration attribute, a CodecStrings element, a SimulcastTSID element, a SvcCapabilities element, a BroadcastSvcSignaling element, a svcInetUrl element, and / or an OtherBsid element.

[0107] The @serviceId property is the identifier of the service, and the @globalserviceID property is a globally unique URI that identifies the service. The @globalserviceID property does not exist for ESG or DRM data services. The @sltSvcSeqNum property can indicate the sequence number (or version) of the SLT information for the service. The @protected property can indicate whether one or more components required for meaningful presentation of the service are protected (e.g., encrypted). The @majorChannelNo and @minorChannelNo properties can indicate the major and minor channel numbers of the service, respectively.

[0108] The @serviceCategory attribute can indicate the category of the service, i.e., the service type. For example, a value of 1 for the @serviceCategory attribute can indicate a linear A / V service, 2 for a linear audio-only service, 3 for an app-based service, 4 for an ESG service, 6 for a DRM data service, and 7 for a data service. The @shortServiceName attribute can provide a short name for the service. The @hidden attribute can indicate whether the service is for testing or proprietary use. The @hideInGuide attribute can indicate whether the service is visible on the ESG display. The @broadbandAccessRequired attribute can indicate whether broadband access is required for meaningful playback of the service. The @essential attribute can indicate whether the essential portion of the service is delivered through the broadcast stream. The @drmSystemID attribute can indicate the DRM system ID(s) associated with the service. The @configuration attribute can declare a service configuration.

[0109] The SimulcastTSID element indicates the identifiers (e.g., major channel number and minor channel number) of ATSC 1.0 broadcast streams carrying the same programming content.

[0110] The svcCapabilities element can provide capability information necessary for decoding and meaningful playback of the service.

[0111] The BroadcastSvcSignaling element can provide information related to broadcast signaling for a given service. This element can provide information about the service's broadcast network signaling, such as location, protocol, and address. Details are provided below.

[0112] The svcInetUrl element can provide URL information for obtaining ESG or SLS files for the corresponding service via broadband. The sltInetUrl element can additionally include the @urlType attribute, which can indicate the type of files that can be obtained through the URL, as described above.

[0113] The aforementioned BroadcastSvcSignaling element may contain the @slsProtocol attribute, the @slsMajorProtocolVersion attribute, the @slsMinorProtocolVersion attribute, the @slsDestinationIpAddress attribute, the @slsDestinationUdpPort attribute, and / or the @slsSourceIpAddress attribute.

[0114] The @slsProtocol attribute can indicate the type of SLS delivery protocol used by the service. For example, a value of 1 for the @slsProtocol attribute can indicate ROUTE, and a value of 2 can indicate MMTP. The @slsMajorProtocolVersion and @slsMinorProtocolVersion attributes can indicate the major and minor version numbers of the protocol used to deliver the SLS of the service, respectively.

[0115] The @slsDestinationIpAddress, @slsDestinationUdpPort, and @slsSourceIpAddress properties can indicate the destination IP address, destination UDP port, and source IP address of packets delivering SLS (e.g., broadcast SLS data) for the corresponding service, respectively. They can identify the transport session (ROUTE session or MMTP session) over which the SLS is delivered. These can be included in the bootstrap information.

[0116] According to embodiments, the SLS is signaling information that describes the characteristics of the corresponding service, and may include information for obtaining the corresponding service and its components, or receiver capability information for meaningfully playing the corresponding service. By having separate service signaling for each service, the receiver can obtain the appropriate SLS for the desired service without having to parse the entire SLS transmitted within the broadcast stream.

[0117] When SLS is delivered via ROUTE protocol, the receiver can obtain SLS fragments carried on the IP / UDP / LCT channel indicated by SLT. In some embodiments, the LCT channel may be an LCT channel identified by tsi = 0. In this case, the SLS may include USBD / USD (User Service Bundle Description / User Service Description), S-TSID (Service-based Transport Session Instance Description) and / or MPD (Media Presentation Description). The SLS may further include HELD (HTML Entry pages Location Description), DWD (Distribution Window Description) and / or RSAT (Regional Service Availability Table).

[0118] When SLS is delivered via the MMT protocol, the receiver can obtain SLS fragments carried by the MMTP session indicated by the SLT. In some embodiments, the packet_id of MMTP packets delivering SLS may have a value of 00. In this case, the SLS may include USBD / USD and / or MMT Package (MP) tables. The SLS may further include HELD and DWD.

[0119] A ROUTE session is identified by a source IP address, a destination IP address, and a destination port number. An LCT channel (and the associated service components carrying it) is identified by a transport session identifier (TSI) that is unique within the scope of the parent ROUTE session. Each LCT channel can be carried on a single physical layer pipe (PLP). Each PLP can contain one or more LCT channels. Different LCT channels in a ROUTE session may or may not be contained in different PLPs.

[0120] MMTP sessions are identified by their destination IP address and destination port number. MMTP packet flows (and the associated service components that carry them) are identified by a packet_id that is unique within the scope of the parent MMTP session.

[0121] For ROUTE, the S-TSID, USBD / USD, MPD, or the LCT channel that carries them may be called a service signaling channel. For MMTP, the USBD / USD, MMT signaling messages, or the packet flow that carries them may be called a service signaling channel.

[0122] Additionally, a single ROUTE or MMTP session can be delivered via multiple PLPs. That is, a single service can be delivered via more than one PLP. Depending on the embodiment, components constituting a single service can be delivered via different ROUTE sessions. Additionally, depending on the embodiment, components constituting a single service can be delivered via different MMTP sessions. Depending on the embodiment, components constituting a single service can be delivered separately across ROUTE sessions and MMTP sessions. Depending on the embodiment, components constituting a single service can also be delivered via broadband (hybrid delivery).

[0123] The following describes the link layer.

[0124] FIG. 4 is a diagram illustrating a link layer protocol architecture according to embodiments.

[0125] FIG. 5 is a diagram illustrating the operation of a link layer when an input packet according to embodiments is an IP packet.

[0126] The link layer can be a layer between the physical layer and the network layer. The sender can transmit data from the network layer to the physical layer, and the receiver can transmit data from the physical layer to the network layer. The purpose of the link layer may be to abstract all input packet types into a single format for processing by the physical layer, to ensure flexibility for input packet types that have not yet been defined, and to ensure future extensibility. Furthermore, the link layer can provide an option to compress unnecessary information in the headers of input packets, thereby enabling efficient transmission of input data. Operations of the link layer, such as overhead reduction and encapsulation, are called link layer protocols, and packets generated using these protocols are called link layer packets. The link layer can perform functions such as packet encapsulation, overhead reduction, and / or signaling transmission. In the present disclosure, the link layer protocol is also referred to as ATSC Link Layer Protocol (ALP), and the link layer packet is also referred to as a link layer packet.

[0127] From the transmitter side, the link layer can perform an overhead reduction process on input packets and then encapsulate them into link layer packets. Additionally, depending on the embodiment, the link layer can encapsulate them into link layer packets without performing the overhead reduction process. The use of a link layer protocol can significantly reduce the overhead for data transmission on the physical layer. In other embodiments, the link layer protocol can provide IP overhead reduction and / or MPEG-2 TS overhead reduction.

[0128] When an IP packet is input as an input packet, the link layer can sequentially perform IP header compression, adaptation, and / or encapsulation processes as shown in FIG. 5. Depending on the embodiment, some processes may be omitted. At this time, for optimal operation of IP header compression, a pre-processing module may be used before the RoHC (RObust Header Compression) module. First, when fragmented IP packets are input from one IP packet, the fragmented IP packets are collected through pre-processing by the pre-processing module, restored to a pre-fragmented IP packet, and output to the RoHC module. If the input IP packet is not a fragmented IP packet, it is output directly to the RoHC module without going through pre-processing.

[0129] The RoHC module can reduce unnecessary overhead by performing IP packet header compression on input IP packets, extract context information by performing an adaptation process in the adaptation module, and transmit the extracted context information out of band. IP header compression and the adaptation process may be collectively referred to as IP header compression. Alternatively, the pre-processing, IP header compression, and adaptation processes may be collectively referred to as IP header compression. After this, the encapsulation module can perform an encapsulation process to encapsulate IP packets or header-compressed packets and the extracted context information into link layer packets. In one embodiment, this document will refer to the pre-processing module, the RoHC module, and the adaptation module collectively as an IP header compression unit, and the IP header compression unit and the encapsulation module collectively as an ALP stream generator or ALP generator. That is, the above ALP stream generator is a single ALP stream generator that generates one ALP stream containing ALP packets. The ALP stream is also called a link layer stream.

[0130] When MPEG 2 TS packets are input as input packets, the link layer may sequentially perform overhead reduction and / or encapsulation processes on the TS packets. Depending on the embodiment, some processes may be omitted. For overhead reduction, the link layer may provide sync byte removal, null packet removal, and / or common header removal (compression). Sync byte removal may provide overhead reduction of 1 byte per TS packet. Null packet removal may be performed in a manner that can be reinserted at the receiving end. Additionally, common information between consecutive headers may be removed (compressed) in a manner that can be recovered at the receiving end. Some of the overhead reduction processes may be omitted. Afterwards, the TS packets may be encapsulated into link layer packets through the encapsulation process. The link layer packet structure for encapsulation of TS packets may be different from that of other types of packets.

[0131] The following explains IP Header Compression.

[0132] IP packets have a fixed header format, but some information required in a communications environment may be unnecessary in a broadcast environment. Link layer protocols can provide mechanisms to reduce broadcast overhead by compressing IP packet headers.

[0133] The transmitter may include an RoHC module (or header compressor) and / or an adaptation module, as shown in FIG. 5, for IP header compression. The RoHC module may reduce the size of an IP packet header based on the RoHC method. Thereafter, the adaptation module may extract context information from the header-compressed IP packet and generate signaling information related to header compression. The receiver may restore the packet header based on the signaling information and the context information to reconstruct the original IP packet. Hereinafter, IP header compression may mean only IP header compression by the RoHC module, or may mean a concept that combines the IP header compression by the RoHC module and the adaptation process by the adaptation module. The same applies to decompressing by the receiver.

[0134] For convenience of explanation, in this disclosure, an IP packet before compression is referred to as a data packet, and a packet after compression using the RoHC method is referred to as a RoHC packet (or header-compressed data packet). In addition, a stream containing IP packets before compression is referred to as an IP stream or IP packet stream, and a stream containing RoHC packets is referred to as a RoHC packet stream or RoHC packet flow or RoHC IP stream or RoHC stream or compressed IP stream.

[0135] And the data packet, which is an IP packet before compression, is composed of a header and a payload, and the header includes at least an IP header and a UDP header according to the ROHC UDP profile (0x0002). That is, data processed according to the MMTP or ROUTE protocol in the delivery layer of the transmitting system is encapsulated as IP packets in the UDP / IP layer and then transmitted to the link layer. At this time, a UDP packet is created by adding a UDP header to a UDP payload including data processed according to the MMTP or ROUTE protocol, and an IP header is added to the UDP packet to create an IP / UDP packet, as an embodiment. In the present disclosure, for the convenience of explanation, a packet composed of an IP header, a UDP header, and a payload, or a packet composed of an IP header and a payload, is referred to as an IP packet or a data packet.

[0136] In addition, during IP streaming, information included in the IP header and UDP header of the IP packet, such as the IP version, source IP address, destination IP address, IP fragment flag, source port number, and destination port number, hardly changes during streaming. In the present disclosure, fields that transmit information that hardly changes during streaming as described above are referred to as static fields. In addition, information transmitted in the static field is referred to as static information. In the present disclosure, static information is used with the same meaning as static chain information. In the RoHC compression method, such static information is not transmitted additionally for a while after being transmitted once. This is called the Initialization and Refresh (IR) state, and the RoHC packet in which the static information is transmitted as a header is called an IR packet.

[0137] In addition, separate transmission is provided for dynamic information that fluctuates frequently but remains constant for a certain period of time. This dynamic information is transmitted via a dynamic field, and in this disclosure, dynamic information is used with the same meaning as dynamic chain information.

[0138] The RoHC packet in which the above dynamic information is transmitted as a header is called an IR-DYN packet. In one embodiment, the IR packet also includes dynamic information. That is, the IR packet and IR-DYN packet contain all the information of the existing header, and thus have a similar size to the existing header.

[0139] As described above, the IP header compression scheme in the present disclosure is RoHC-based, and the RoHC framework defines RoHC channels to identify compressed packet flows, i.e., RoHC packet flows. According to embodiments, one PLP may be mapped to one RoHC channel. Therefore, the CID (Context Identifier) ​​is managed separately in each PLP. In one embodiment of the present disclosure, each RoHC channel is composed of a small CID (Context ID) and a 1-byte large CID (Large CID).

[0140] Below, we will explain adaptation.

[0141] For transmissions over unidirectional links, if the receiver lacks context information, its decompressor cannot recover the received packet header until it receives the complete context. This can result in channel change delays and turn-on delays. For this reason, context information and configuration parameters are transmitted in the RDT (ROHC-U Description Table).

[0142] Therefore, the adaptation function can construct link layer signaling including RDT using context information and / or configuration parameters. In addition, the adaptation function provides out-of-band transmission of configuration parameters and context information between a compressor / decompressor. That is, out-of-band transmission can be achieved through link layer signaling. In other words, the adaptation function is used to reduce decompression errors and channel switching delays due to loss of context information. In the present disclosure, link layer signaling and link layer signaling information are used interchangeably.

[0143] Below, the extraction of context information is explained.

[0144] Context information is extracted from header-compressed IP packets, i.e., RoHC packets, and various methods can be used depending on the adaptation mode.

[0145] Adaptation Mode 1 is a mode in which no operation is performed on the basic RoHC stream (i.e., RoHC packet flow). In this mode, the adaptation module can act as a buffer. In other words, in Adaptation Mode 1, context information is not extracted from RoHC packets. And the RoHC packets in the RoHC packet flow are encapsulated into at least one link layer packet by the encapsulation module and transmitted to the physical layer.

[0146] In adaptation mode 2, the adaptation module detects IR packets from the RoHC packet flow and extracts context information (i.e., static chain information) from the header of the detected IR packet. The IR packet from which the context information has been extracted is converted into an IR-DYN packet, and the converted IR-DYN packet is transmitted to the encapsulation module in the same order within the RoHC packet flow, replacing the original IR packet. The extracted context information is included in the RDT (RoHC-U Description Table) of link layer signaling information and transmitted to the encapsulation module. The encapsulation module encapsulates packets within the RoHC packet flow into at least one link layer packet, and also encapsulates the link layer signaling information into at least one link layer packet and transmits the encapsulated link layer signaling information to the physical layer. The PLP that transmits at least one link layer packet including the RoHC packet flow and the PLP that transmits at least one link layer packet including the link layer signaling may be different or may be the same.

[0147] In adaptation mode 3, the adaptation module detects IR packets and IR-DYN packets from the RoHC packet flow, and extracts context information from the detected IR packets and IR-DYN packets. In one embodiment, the context information extracted from the IR packets is static chain information and dynamic chain information, and the context information extracted from the IR-DYN packets is dynamic chain information. The IR and IR-DYN packets from which the context information has been extracted are converted into compressed packets. These converted compressed packets can be transmitted in the same order within the RoHC packet flow as replacements for the original IR and IR-DYN packets. In one embodiment, the extracted context information is included in the RDT of link layer signaling information and transmitted to the encapsulation module. The encapsulation module encapsulates packets within the RoHC packet flow into at least one link layer packet, and also encapsulates the link layer signaling information into at least one link layer packet and transmits the encapsulated link layer signaling information to the physical layer. The PLP transmitting at least one link layer packet including the RoHC packet flow and the PLP transmitting at least one link layer packet including the link layer signaling may be different or the same. The at least one link layer packet including the link layer signaling information may be transmitted through a specific physical data path. The specific physical data path may mean one of the general PLPs, a PLP through which LLS (Low Level Signaling) is transmitted, a dedicated PLP, or an L1 signaling path, depending on the embodiment.

[0148] Here, RDT may be signaling information including context information (static chain and / or dynamic chain) and / or information related to header compression (also called header compression information). Depending on the embodiment, RDT may be transmitted whenever context information changes. Also, depending on the embodiment, RDT may be transmitted in every physical frame. In order to transmit RDT in every physical frame, a previous RDT may be reused.

[0149] Below, packet encapsulation is explained.

[0150] The link layer protocol, i.e. the encapsulation module, can 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 packets as a type of network layer packet). That is, each network layer packet or input packet is transformed into the payload of a generic link layer packet by the encapsulation module.

[0151] Segmentation can be utilized during packet encapsulation. If a network layer packet is too large to be processed by the physical layer, it can be divided into two or more segments. The link layer packet header can include fields for segmentation at the sender and reassembly at the receiver. Each segment can be encapsulated into a link layer packet in the same order as its original location.

[0152] Concatenation can also be utilized during packet encapsulation. If a link layer packet is sufficiently small to contain multiple network layer packets within its payload, concatenation can be performed. The link layer packet header can include fields for performing concatenation. With concatenation, each input packet can be encapsulated into the link layer packet payload in the same order as its original input order.

[0153] A link layer packet includes a header and a payload, and the header may include a base header, an additional header, and / or an optional header. Additional headers may be added depending on situations such as concatenation or segmentation, and the additional header may include necessary fields tailored to the situation. Additionally, an optional header may be added to convey additional information. The presence of an optional header is indicated by a flag field in the additional header. Depending on the embodiment, fields indicating the presence of the additional header and the optional header may be located in the base header.

[0154] Fig. 6 shows the structure of a physical layer processor in a transmitting device according to embodiments.

[0155] The broadcast signal transmission device or physical layer processor of FIG. 6 may include an input formatting block (1000), a bit interleaved coding & modulation (BICM) block (1010), a frame building block (1020), an orthogonal frequency division multiplexing (OFDM) generation block (OFDM generation block) (1030), and a signaling generation block (1040). The operation of each block of the broadcast signal transmission device will be described.

[0156] The input data according to one embodiment is at least one ALP stream. Each ALP stream comprises link layer packets.

[0157] The input formatting block (1000) outputs each ALP stream to each PLP, to which independent coding and modulation are applied. A PLP is a basic unit for robustness control, which affects the Quality of Service (QoS). One or more services or service components can be delivered by a PLP. A PLP is a logical channel in the physical layer that carries service data or related metadata that can deliver one or more services or service components.

[0158] The above input formatting block (1000) adds a baseband header to a baseband payload including at least one link layer packet per PLP, generates a baseband packet, and then outputs it to the corresponding BICM block (1010) through the corresponding PLP. Each PLP consists of a stream of baseband packets. The BICM block (1010) operates per PLP.

[0159] The above BICM block (1010) may include an FEC (Forward Error Correction) encoder, a bit interleaver, and a constellation mapper.

[0160] The above FEC encoder performs FEC encoding on the input baseband packet using outer coding (BCH) and inner coding (LDPC, Low Density Parity Check). The output of the data FEC encoder is an FEC frame. Outer coding (BCH, Bose, Chaudhuri, Hocquenghem) is an optional coding method. The bit interleaver bit-interleaves the output of the FEC encoder, and can achieve optimized performance by combining LDPC codes and modulation methods. The constellation mapper modulates cell words from a bit interleaver or cell word demultiplexer using Quadrature Phase Shift Keying (QPSK), Quadrature Amplitude Modulation (QAM)-16, Non-Uniform QAM (NUQ-64, NUQ-256, NUQ-1024), or Non-Uniform Constellation (NUC) (NUC-16, NUC-64, NUC-256, NUC-1024) to output power-normalized constellation points (i.e., QAM symbols) to the frame building blocks (1030). The output of the constellation mapper is an FEC block.

[0161] The above frame building block (1020) is composed of a time interleaver, a frame builder, and a frequency interleaver. The time interleaver time-interleaves the input FEC block and outputs it to the frame builder. The frame builder maps the data cells of the data pipes that are time-interleaved and output to OFDM symbols within the frame, and the frequency interleaver can perform frequency interleaving for frequency domain diversity.

[0162] The output of the above frame building block (1020) is OFDM symbols such as a preamble or data sequentially arranged in the final frame, and frequency interleaving in the frequency interleaver is performed on the OFDM symbols in one embodiment. That is, the frequency interleaver can provide frequency diversity by randomly interleaving the input data cells. In addition, the frequency interleaver can operate on data corresponding to an OFDM symbol pair composed of two sequential OFDM symbols or data corresponding to one OFDM symbol by using a different interleaving seed order to obtain the maximum interleaving gain in a single frame.

[0163] The frame output through the above frequency interleaving is divided into a preamble and a data region. In the OFDM generation block (1030), a bootstrap region containing bootstrap data is inserted before the preamble of the frame. In one embodiment, the L1 signaling data transmitted through the preamble is generated in the signaling generation block (1040).

[0164] The above L1 signaling data includes L1 basic (L1-Basic) signaling data and L1 detail (L1-Detail) signaling data. The L1 basic signaling data is also referred to as PLS1 data, and the L1 detail signaling data is also referred to as PLS2 data.

[0165] The OFDM generation block (1030) modulates the OFDM carrier using the cells generated by the frame building block (1020), inserts a pilot, and generates a time-domain signal for transmission. Furthermore, the block sequentially inserts guard intervals, applies PAPR reduction processing, and then inserts a bootstrap containing bootstrap data at the beginning of the frame to generate the final RF signal.

[0166] The signaling generation block (1040) can generate physical layer signaling information used for the operation of each functional block. The physical layer signaling information according to an embodiment can include L1 basic signaling data and L1 detail signaling data. In one embodiment, the L1 basic signaling data (or PLS1 data) conveys basic information about the system as well as parameters required for decoding the L1 detail signaling data (or PLS2 data). In one embodiment, the length of the L1 basic signaling data is fixed to 200 bits. The L1 detail signaling data (or PLS2 data) defines in detail a data context and information required for its decoding. In addition, the length of the L1 detail signaling data is variable from frame to frame.

[0167] The BICM block (1010) may further include a BICM block for protecting L1 signaling data (or PLS data). The BICM block for protecting L1 signaling data (or PLS data) may include an FEC encoder, a bit interleaver, and a constellation mapper.

[0168] The FEC encoder may include a scrambler for scrambling L1 basic signaling data (or PLS1 data) and L1 detail signaling data (or PLS2 data), respectively, a BCH encoding / zero insertion block for performing external encoding (e.g., BCH) on the scrambled L1 basic and detail signaling data (or PLS 1,2 data) using a shortened BCH code, inserting zero bits after BCH encoding, an LDPC encoding block for performing encoding using an LDPC code, and an LDPC parity puncturing block. Output bits of the zero-inserted L1 basic signaling data and / or L1 detail signaling data may be permuted after LDPC encoding. The bit interleaver bit-interleaves each shortened and punctured L1 basic signaling data (or PLS1 data) and L1 detail signaling data (or PLS2 data), and the constellation mapper can map the bit-interleaved L1 basic signaling data (or PLS1 data) and L1 detail signaling data (or PLS2 data) to a constellation. In one embodiment, time interleaving is not performed on the L1 signaling data, but frequency interleaving is performed.

[0169] FIG. 7 is a diagram showing an example of an ATSC 3.0 system architecture according to embodiments.

[0170] In the ATSC 3.0 system architecture of FIG. 7, linear TV providers provide linear TV content for linear services, ESG providers provide ESG data, and NRT providers provide NRT data.

[0171] According to embodiments, the linear TV content, ESG data or NRT data may be transmitted to the receiving device via a broadcast network as described above or may be transmitted to the receiving device via a broadband network.

[0172] According to embodiments, when transmitted over a broadcast network, linear TV content may be encoded into DASH segments or MPUs by an encoder and then provided to a delivery & signaling server, ESG data may be provided to the delivery & signaling server via the ESG server, and NRT data may be provided to the delivery & signaling server via the NRT server. According to embodiments, the ESG server and the NRT server may respectively process the ESG data and the NRT data, convert them into packetized and metadata-included structures, and prepare them for transmission. In one embodiment, the encoder may format service data, such as linear TV content, into MPUs or DASH segments according to a delivery protocol. For example, if the service data includes both video and audio, it may be formatted into video MPUs and audio MPUs, or formatted into video segments and audio segments.

[0173] According to embodiments, MPUs are delivered using MMTP in the delivery & signaling server, and DASH segments are delivered using the ROUTE protocol. At this time, MMTP packet flows carrying MPUs or LCT channels carrying DASH segments can be encapsulated into DSTP (Data Source Transport Protocol)-based DSTP packets and transmitted to the broadcast gateway.

[0174] According to embodiments, if ESG data and / or NRT data are transmitted through a broadcast network, the ESG data and / or NRT data may be delivered through an LCT channel in the delivery & signaling server, and the LCT channel at this time may also be encapsulated into DSTP-based DSTP packet(s) and transmitted to the broadcast gateway.

[0175] According to embodiments, MMTP packet flows or LCT channels may be encapsulated into IP packets and then encapsulated into DSTP packets.

[0176] The present disclosure may be referred to as a studio, including providers, encoders, ESG servers, NRT servers, and delivery & service servers.

[0177] According to embodiments, the broadcast gateway may or may not include an ALP generator. If the broadcast gateway does not include an ALP generator, the ALP generator may be located between the Delivery & Signaling Server and the broadcast gateway.

[0178] In one embodiment, the ALP generator in FIG. 7 is included in a broadcast gateway. In this case, the broadcast gateway may be referred to as a link layer processor. That is, in one embodiment, the broadcast gateway performs operation and transmission functions at the link layer (i.e., Layer 2).

[0179] If the packets transmitted from the Delivery & Signaling Server are DSTP packets, a decapsulation process can be performed to extract IP packets from the DSTP packets. If the packets transmitted from the Delivery & Signaling Server are IP packets, the decapsulation process is omitted.

[0180] The above ALP generator may include a pre-processor, a RoHC module, an adaptation module, and an encapsulation module as shown in FIG. 5, and a detailed description of each block will be described with reference to FIG. 5.

[0181] That is, the broadcast gateway connects between the studio and the transmitter site, which includes the delivery & signaling server, and performs multi-layered roles such as ALP, STLTP, security, time synchronization, channel bonding, and frame structuring.

[0182] According to embodiments, the transmitter site includes an ATSC 3.0 exciter, and the ATSC 3.0 exciter includes a broadcast signal transmission device of FIG. 6. According to embodiments, the broadcast signal transmission device of FIG. 6 may be referred to as a physical layer processor. For convenience of description, the present disclosure may refer to an ATSC 3.0 exciter or a transmitter site including an ATSC 3.0 exciter as an ATSC 3.0 transmitter.

[0183] According to embodiments, the input formatting block (1000) of FIG. 6 may be included in a physical layer processor or may be included in a link layer processor (e.g., a broadcast gateway).

[0184] In the latter case, the broadcast gateway may create a baseband packet (BBP) by adding a baseband header to the baseband payload containing at least one ALP packet per PLP, which is then encapsulated into a Studio to Transmitter Link Transport Protocol (STLTP) packet and transmitted to one or more transmitter sites. That is, each PLP consists of a stream of baseband packets.

[0185] According to embodiments, STLTP packets may be transmitted to an ATSC 3.0 exciter via an antenna and an IP switch, or may be transmitted to an ATSC 3.0 exciter via an IP network and an IP switch.

[0186] Each ATSC 3.0 exciter may include a BICM block (1010), a frame building block (1020), an OFDM generation block (1030), and a signaling generation block (1040) as illustrated in FIG. 6. In this case, the ATSC 3.0 exciter may convert baseband packets including ALP packets (or an ALP stream including ALP packets) transmitted from a broadcast gateway into physical layer signals by performing physical layer processing as illustrated in FIG. 6, and then transmit the converted physical layer signals in an RF band through one or more antennas. At this time, the ATSC 3.0 exciter supports a single frequency network (SFN) configuration, and multiple exciters can transmit physical layer signals synchronized at the same frequency.

[0187] According to embodiments, the receiving device (or receiver) may be included in a mobile terminal such as a smart phone, a laptop, a desktop, a television, a set-top box, etc.

[0188] As described above, in the present disclosure, service data, ESG data, or NRT data, such as linear TV content, may be transmitted to a receiving device via a broadband network. In this case, the service data, ESG data, or NRT data may be transmitted to the broadband network via a Content Delivery Network (CDN). The CDN is a distributed server network for transmitting the service data, ESG data, or NRT data via the broadband network.

[0189] So far, we have explained how to process and provide services defined in ATSC 3.0 using the ATSC 3.0 broadcasting system.

[0190] The present disclosure provides another embodiment in which an external service not defined in ATSC 3.0 can be provided using an ATSC 3.0 system.

[0191] FIG. 8 is a diagram illustrating another example of a protocol stack for a service according to embodiments.

[0192] According to embodiments, services defined in ATSC 3.0 may include linear audio / video services, linear audio-only services, app-based services, ESG services, and DRM (Digital Rights Management) data services, and these services are transmitted using MMTP or ROUTE protocols.

[0193] According to embodiments, there may be external services not defined in ATSC 3.0, and these external services may be transmitted using external service protocols other than MMTP or ROUTE protocols.

[0194] Figure 8 is a protocol stack illustrating such an example, wherein service components for external services delivered via external service protocols are processed as IP packets in the UDP / IP layer, and the IP packets are processed as ALP packets in the link layer and then transmitted to the physical layer. In addition, service signaling information for external services (external service signaling) is also processed as IP packets in the UDP / IP layer, and the IP packets are processed as ALP packets in the link layer and then transmitted to the physical layer.

[0195] In this way, when transmitting an external service using the ATSC 3.0 system, the protocol structure that the receiver can consider is as follows.

[0196] That is, in order to provide an external service, signaling information for the external service (External Service Signaling) can be IP packetized through the IP / UDP layer, ALP packetized through the link layer, and transmitted to the physical layer. In addition, protocols for external services not defined in the ATSC 3.0 system (External Service Protocol) can also be IP packetized through the IP / UDP layer, ALP packetized through the link layer, and transmitted to the physical layer. In other words, an IP / UDP stream including an external service can be transmitted to a receiver using the link layer and the physical layer.

[0197] In Fig. 8, UDP / IP layer processing of the UDP / IP layer, link layer processing of the link layer, and physical layer processing of the physical layer are omitted to avoid redundant description, and detailed descriptions refer to the descriptions of Figs. 1 to 7.

[0198] According to embodiments, one of the external services may be a DRM (Digital Radio Mondiale) service. In the following, unless otherwise specified, DRM is an abbreviation for Digital Radio Mondiale. Furthermore, the DRM (Digital Radio Mondiale) service may be referred to as a DRM-R (Digital Radio Mondiale-Radio) service to distinguish it from the DRM (Digital Rights Management) data service.

[0199] The above DRM is an international standard that provides high-quality digital radio broadcasting in various frequency bands from AM band to shortwave, medium wave, and ultra-short wave, and supports the transmission of not only audio but also various additional data (e.g., news, images, software updates, etc.). According to embodiments, the Distribution and Communications Protocol (DCP) is used for the DRM service. DCP is a delivery protocol designed to enable distributed transmission of data packets through various transmission paths. In particular, it integrates a Reed-Solomon-based Forward Error Correction (FEC) function to ensure high reliability even in error-prone unidirectional links, thereby enabling data restoration without retransmission.

[0200] For this purpose, the DRM system includes a DRM content server.

[0201] FIG. 9 is a diagram showing an example of a DRM content server according to embodiments.

[0202] In FIG. 9, the DRM content server includes audio and data service encoders for one transmission signal and a DRM multiplex generator, which serves to integrate content within a Main Service Channel (MSC).

[0203] Additionally, a Fast Access Channel (FAC) and a Service Description Channel (SDC) are inserted into the multiplex signal (i.e., the multiplex data stream) output from the DRM multiplex generator. The FAC and SDC include information regarding the identification of the transmitted content and transmission parameters for receiving the DRM signal. According to embodiments, the MSC includes data regarding all services included in the DRM multiplex. For example, the DRM multiplex may include one to four services, and each service may be audio or data. The MSC may be encoded using one or two protection levels. According to embodiments, the DRM multiplex configuration may be signaled using the SDC.

[0204] The above MSC is a channel of a multiplexed data stream that occupies a major part of the transmission frame and carries all digital audio services along with possible support and additional data services.

[0205] The above FAC is a channel of a multiplex data stream that contains information necessary to find a service and initiate the multiplex decoding.

[0206] The above SDC is a channel of a multiplex data stream that provides information for decoding services included in the multiplex.

[0207] According to embodiments, the entire multiplex signal, in which the MSC, FAC, and SDC are combined, is transmitted to the DRM modulators via the Multiplex Distribution Interface (MDI) using the so-called Distribution and Communications Protocol (DCP). That is, the DRM multiplex signal is configured and set up by the DRM Content Server within the studio, and then transmitted to the DRM modulators at the corresponding transmission locations using the MDI / DCP. The DCP provides error correction and packet structure. In one embodiment, the MDI / DCP signal (or MDI / DCP data stream) output from the DRM Content Server is composed of the MSC, FAC, and SDC.

[0208] In this way, DRM-R services can be provided using MDI and DCP. The DCP can be composed of TAG (Tag_Length_Value), AF (Application Framing), and PFT (Protection, Fragmentation, and Transportion) sublayers. In each layer, data is encapsulated into a series of packets. The TAG layer encapsulates data items composed of tag, length, and value, the AF layer groups data items into a single packet to create a transmission unit, and the PFT layer performs error correction, data fragmentation, and addressing functions.

[0209] FIG. 10 is a diagram illustrating another example of an ATSC 3.0 system architecture according to embodiments. That is, FIG. 10 is an example for providing a DRM-R service on an ATSC 3.0 system. In particular, FIG. 10 is an example of a network topology in a case where an ALP generator is located outside a broadcast gateway.

[0210] According to embodiments, an ATSC 3.0 broadcast studio formats service data, such as linear TV content, into MPUs or DASH segments, encapsulates IP packets including MMTP packet flows carrying MPUs or IP packets including LCT (Layered Coding Transport) channels carrying DASH segments into DSTP packets, and outputs the encapsulated IP packets to a first ALP generator. The first ALP generator is located outside a broadcast gateway and may be referred to as an external ALP generator.

[0211] The first ALP generator may include a pre-processor, an RoHC module, an adaptation module, and an encapsulation module as shown in FIG. 5, and a detailed description of each block will be described with reference to FIG. 5. That is, the first ALP generator extracts IP packets from input DSTP packets, performs link layer processing on the extracted IP packets as shown in FIG. 5, generates an ALP stream including ALP packets, and then transmits the ALP stream to a broadcast gateway using ALPTP (ALP Transport Protocol). The ALP packets included in the ALP stream may include IP packets including service data and signaling information for a service defined in ATSC 3.0, RDT, LMT, and / or link layer signaling information. The ALPTP is a tuning protocol for transmitting the ALP stream including ALP packets to the broadcast gateway. For example, the ALP stream is encapsulated into an RTP / UDP / IP packet and transmitted to the broadcast gateway.

[0212] According to embodiments, a DRM-R studio including a DRM content server processes audio sources and data for a DRM-R service to generate an MDI / DCP data stream including MSC, FAC, and SDC, encapsulates the MDI / DCP data stream into IP packets, and then encapsulates the IP packets again into DSTP packets and outputs them to a second ALP generator. The second ALP generator is located outside the broadcast gateway and may be referred to as an external ALP generator.

[0213] The second ALP generator may include a pre-processor, an RoHC module, an adaptation module, and an encapsulation module as shown in FIG. 5, and a detailed description of each block will be described with reference to FIG. 5. That is, the second ALP generator extracts IP packets from input DSTP packets, processes the extracted IP packets at a link layer as shown in FIG. 5, generates an ALP stream including ALP packets, and then transmits the ALP stream to a broadcast gateway using ALPTP. The ALP packets included in the ALP stream may include IP packets including service data and signaling information for a DRM-R service, RDT, LMT, and / or link layer signaling information.

[0214] The above broadcast gateway generates one or more baseband packets based on ALP packets of an ALP stream output from a first ALP generator and ALP packets of an ALP stream output from a second ALP generator, and transmits the one or more baseband packets to an ATSC 3.0 transmitter using STLTP (STL Transport Protocol). For example, a baseband packet including ALP packets of an ALP stream output from the first ALP generator and a baseband packet including ALP packets of an ALP stream output from the second ALP generator may be different and may be transmitted through different PLPs.

[0215] The ATSC 3.0 transmitter may include a BICM block (1010), a frame building block (1020), an OFDM generation block (1030), and a signaling generation block (1040) as illustrated in FIG. 6. In this case, the ATSC 3.0 transmitter may convert baseband packets transmitted from a broadcast gateway into physical layer signals by performing physical layer processing as described in FIG. 6, and then transmit the converted signals to a receiving device via one or more antennas.

[0216] According to embodiments, the receiving device (or receiver) may be included in a mobile terminal such as a smart phone, a laptop, a desktop, a television, a set-top box, etc.

[0217] According to embodiments, the receiving device may be an ATSC 3.0 receiver(s), or may be an ATSC 3.0 receiver(s) including a DRM-R client, or may be a DRM-R receiver(s).

[0218] In one embodiment, assuming that a physical layer signal transmitted from an ATSC 3.0 transmitter includes both a ROUTE / MMTP-based service and an MDI / DCP-based DRM-R service, the ATSC 3.0 receiver(s) can process only the ROUTE / MMTP-based service and provide it to a user, the ATSC 3.0 receiver(s) including the DRM-R client can process both the ROUTE / MMTP-based service and the MDI / DCP-based DRM-R service and provide it to a user, and the DRM-R receiver(s) can process only the MDI / DCP-based DRM-R service and provide it to a user.

[0219] FIG. 11 is a diagram illustrating another example of an ATSC 3.0 system architecture according to embodiments. That is, FIG. 11 is another example for providing DRM-R services on an ATSC 3.0 system. In particular, FIG. 11 is an example of a network topology in the case where an ALP generator is located within a broadcast gateway.

[0220] In Fig. 11, the configuration and operation of the ATSC 3.0 broadcast studio and the DRM-R studio are the same as in Fig. 10, so to avoid duplicate description, refer to the description of Fig. 10 and omit detailed description here.

[0221] The ALP generator included in the above broadcast gateway may include a pre-processor, an RoHC module, an adaptation module, and an encapsulation module as shown in FIG. 5, and a detailed description of each block will be described with reference to FIG. 5. That is, the ALP generator extracts IP packets from DSTP packets provided from an ATSC 3.0 broadcast studio and a DRM-R studio, and generates an ALP stream including ALP packets by link layer processing the extracted IP packets as shown in FIG. 5. The ALP packets included in the ALP stream may include IP packets, RDT, LMT, and / or link layer signaling information. At this time, the IP packets may include service data and signaling information for a service defined in ATSC 3.0 and / or may include service data and signaling information for a DRM-R service. In addition, IP packets containing service data and signaling information for services defined in ATSC 3.0 and IP packets containing service data and signaling information for DRM-R services may be included in one ALP stream or may be included in different ALP streams.

[0222] The broadcast gateway generates one or more baseband packets based on ALP packets of one or more ALP streams, and transmits the one or more baseband packets to an ATSC 3.0 transmitter using STLTP. For example, a baseband packet including ALP packets including service data and signaling information for a service defined in ATSC 3.0 and a baseband packet including ALP packets including service data and signaling information for a DRM-R service may be different and may be transmitted via different PLPs.

[0223] The ATSC 3.0 transmitter may include a BICM block (1010), a frame building block (1020), an OFDM generation block (1030), and a signaling generation block (1040) as illustrated in FIG. 6. In this case, the ATSC 3.0 transmitter may convert baseband packets transmitted from a broadcast gateway into physical layer signals by performing physical layer processing as described in FIG. 6, and then transmit the converted signals to a receiving device via one or more antennas.

[0224] According to embodiments, the receiving device (or receiver) may be included in a mobile terminal such as a smart phone, a laptop, a desktop, a television, a set-top box, etc.

[0225] According to embodiments, the receiving device may be an ATSC 3.0 receiver(s), or may be an ATSC 3.0 receiver(s) including a DRM-R client, or may be a DRM-R receiver(s). In one embodiment, assuming that a physical layer signal transmitted from an ATSC 3.0 transmitter includes both a ROUTE / MMTP-based service and an MDI / DCP-based DRM-R service, the ATSC 3.0 receiver(s) may process and provide to a user only the ROUTE / MMTP-based service, the ATSC 3.0 receiver(s) including the DRM-R client may process and provide to a user both the ROUTE / MMTP-based service and the MDI / DCP-based DRM-R service, and the DRM-R receiver(s) may process and provide to a user only the MDI / DCP-based DRM-R service.

[0226] FIG. 12 is a diagram illustrating another example of an ATSC 3.0 system architecture according to embodiments. That is, FIG. 12 is another example for providing a DRM-R service on an ATSC 3.0 system. In particular, FIG. 12 is an example of a network topology in which an ALP generator is located outside a broadcast gateway, and is an example of a DRM-R standalone service using an ATSC 3.0 system. In this case, an ATSC 3.0 broadcast studio is excluded.

[0227] The configuration and operation of the DRM-R studio, ALP generator, broadcast gateway, ATSC 3.0 transmitter and DRM-R receiver(s) of FIG. 12 are the same as those of FIG. 10, so to avoid redundant description, reference will be made to the description of FIG. 10 and a detailed description will be omitted here.

[0228] FIG. 13 is a diagram illustrating another example of an ATSC 3.0 system architecture according to embodiments. That is, FIG. 13 is another example for providing a DRM-R service on an ATSC 3.0 system. In particular, FIG. 13 is an example of a network topology in which an ALP generator is located within a broadcast gateway, and is an example of a DRM-R standalone service using an ATSC 3.0 system. In this case, an ATSC 3.0 broadcast studio is excluded.

[0229] The configuration and operation of the DRM-R studio, broadcast gateway including ALP generator, ATSC 3.0 transmitter and DRM-R receiver(s) of FIG. 13 are the same as those of FIG. 11, so to avoid redundant description, reference will be made to the description of FIG. 10 and a detailed description will be omitted here.

[0230] FIGS. 14 to 18 are diagrams illustrating examples of ATSC 3.0 protocol stacks for DRM-R services according to embodiments. That is, they are examples of a protocol stack (standalone DRM-R protocol stack) when only DRM-R services are provided in an ATSC 3.0 system, as in FIGS. 12 and 13.

[0231] In FIGS. 14 to 18, DRM-R service data is delivered via MDI / DCP. The DRM-R service data is data output from the DRM-R studio and may include MSC, FAC, and SDC.

[0232] According to embodiments, DRM-R service data delivered via MDI / DCP is processed into IP packets via the UDP / IP layer. That is, the UDP / IP layer creates a UDP packet by adding a UDP header to a UDP payload including DRM-R service data delivered using the MDI / DCP protocol, and creates an IP / UDP packet by adding an IP header to the UDP packet. In the present disclosure, for the convenience of explanation, the IP / UDP packet will be referred to as an IP packet. The IP packets of the DRM-R service data generated in the UDP / IP layer are encapsulated as ALP packets in the link layer and transmitted to the physical layer.

[0233] Meanwhile, signaling information for obtaining DRM-R service data can be delivered in various ways as shown in FIGS. 14 to 18.

[0234] FIG. 14 is an example of configuring all signaling information related to DRM-R, including a service list, within a DST (DRM-R Service Table), encapsulating the DST into one or more IP packets at the UDP / IP layer, and encapsulating it into one or more ALP packets at the link layer to transmit it to the physical layer. That is, separate service layer signaling-related data can be configured in the DST. In addition, service announcement-related data can also be configured in the DST. The service announcement-related data can include service announcement data, service guide data, service logos, and icon graphics, etc. That is, all signaling information related to DRM-R can include service announcements, service guides, logos, icons, etc.

[0235] Figure 15 illustrates an example of delivering signaling information for a DRM-R service by dividing it into DST and DRM-R service layer signaling information. In one embodiment, the DST includes information about a service list, and the DRM-R service layer signaling information may include service announcements, service guides, logos, icons, etc.

[0236] According to embodiments, the DST is encapsulated in one or more IP packets at the UDP / IP layer and in one or more ALP packets at the link layer and delivered to the physical layer. In one embodiment, the DST may be carried as the payload of IP packets having well-known addresses / ports.

[0237] According to embodiments, DRM-R service layer signaling information is delivered via MDI / DCP. At this time, the DRM-R service layer signaling information delivered via MDI / DCP is encapsulated into one or more IP packets in the UDP / IP layer and encapsulated into ALP packets in the link layer and transmitted to the physical layer. That is, service announcement related data is also delivered via MDI / DCP. The service announcement related data may include service announcement data, service guide data, service logos, and icon graphics.

[0238] Figure 16 illustrates an example of delivering signaling information for a DRM-R service by dividing it into DST, service announcement-related information, and DRM-R service layer signaling information. In one embodiment, the DST includes information about a service list, and the service announcement-related information (or "service announcement-related data") may include service announcements, service guides, logos, icons, and the like.

[0239] According to embodiments, the DST is encapsulated in one or more IP packets at the UDP / IP layer and in one or more ALP packets at the link layer and delivered to the physical layer. In one embodiment, the DST may be carried as the payload of IP packets having well-known addresses / ports.

[0240] According to embodiments, service announcement-related information is delivered via the ROUTE protocol. At this time, the service announcement-related information delivered via the ROUTE protocol is encapsulated into one or more IP packets at the UDP / IP layer and one or more ALP packets at the link layer and transmitted to the physical layer. That is, the service announcement-related information can be transmitted in the same manner as the ATSC 3.0 service guide (i.e., using the ROUTE protocol). The service announcement-related information may include service announcement data, service guide data, service logos, and icon graphics.

[0241] According to embodiments, DRM-R service layer signaling information is delivered via MDI / DCP. At this time, the DRM-R service layer signaling information delivered via MDI / DCP is encapsulated into one or more IP packets in the UDP / IP layer and encapsulated into one or more ALP packets in the link layer and transmitted to the physical layer.

[0242] In this way, in FIG. 16, service announcement related information is delivered to the UDP / IP layer using the ROUTE protocol, and DRM-R service data and DRM-R service layer signaling information are delivered to the UDP / IP layer using MDI / DCP.

[0243] Figure 17 illustrates another example of delivering signaling information for a DRM-R service by dividing it into DST, service announcement-related information, and DRM-R service layer signaling information. In one embodiment, the DST includes information about a service list, and the service announcement-related information (or service announcement-related data) may include service announcements, service guides, logos, icons, and the like.

[0244] According to embodiments, the DST is encapsulated in one or more IP packets at the UDP / IP layer and in one or more ALP packets at the link layer and delivered to the physical layer. In one embodiment, the DST may be carried as the payload of IP packets having well-known addresses / ports.

[0245] According to embodiments, service announcement-related information is delivered via the ROUTE protocol. At this time, the service announcement-related information delivered via the ROUTE protocol is encapsulated into one or more IP packets at the UDP / IP layer and one or more ALP packets at the link layer and transmitted to the physical layer. That is, the service announcement-related information can be transmitted in the same manner as the ATSC 3.0 service guide (i.e., using the ROUTE protocol). The service announcement-related information may include service announcement data, service guide data, service logos, and icon graphics.

[0246] According to embodiments, DRM-R service layer signaling information is delivered via the ROUTE protocol. At this time, the DRM-R service layer signaling information delivered via the ROUTE protocol is encapsulated into one or more IP packets in the UDP / IP layer and encapsulated into one or more ALP packets in the link layer and transmitted to the physical layer.

[0247] In this way, in FIG. 17, service announcement related information and DRM-R service layer signaling information are delivered to the UDP / IP layer using the ROUTE protocol, and DRM-R service data is delivered to the UDP / IP layer using MDI / DCP.

[0248] Figure 18 illustrates another example of delivering signaling information for a DRM-R service by dividing it into DST and DRM-R service layer signaling information. In one embodiment, the DST includes information about a service list, and the DRM-R service layer signaling information may include service announcements, service guides, logos, icons, etc.

[0249] According to embodiments, the DST is encapsulated in one or more IP packets at the UDP / IP layer and in one or more ALP packets at the link layer and delivered to the physical layer. In one embodiment, the DST may be carried as the payload of IP packets having well-known addresses / ports.

[0250] According to embodiments, DRM-R service layer signaling information is delivered via the ROUTE protocol. At this time, the DRM-R service layer signaling information delivered via the ROUTE protocol is encapsulated into one or more IP packets in the UDP / IP layer and encapsulated into one or more ALP packets in the link layer and transmitted to the physical layer. That is, service announcement related information can be transmitted in the same manner as the ATSC 3.0 service guide (i.e., using the ROUTE protocol). The service announcement related information may include service announcement data, service guide data, service logos, and icon graphics.

[0251] The physical layer of FIGS. 14 to 18 can convert baseband packets containing ALP packets into physical layer signals by processing them as described in FIG. 6 and then transmit them in the RF band through one or more antennas.

[0252] FIG. 19 is a diagram illustrating another example of an ATSC 3.0 protocol stack for a DRM-R service according to embodiments. That is, it is an example of a protocol stack when a hybrid service, for example, an ATSC 3.0 service and a DRM-R service are provided together (or simultaneously) in an ATSC 3.0 system, as in FIGS. 10 and 11.

[0253] According to embodiments, ATSC 3.0 services may include linear audio / video services, linear audio-only services, app-based services, ESG services, and DRM (Digital Rights Management) data services, and these ATSC 3.0 services are delivered using the MMTP or ROUTE protocol.

[0254] For details on ATSC 3.0 services and service signaling information delivered using the MMTP or ROUTE protocol in FIG. 19, refer to the description in FIG. 1 and are omitted here to avoid redundant description.

[0255] In Figure 19, DRM-R service data and signaling information are delivered to the UDP / IP layer via MDI / DCP. Here, the signaling information may be DRM-R service layer signaling information or service announcement-related information. The service information may include service announcements, service guides, logos, icons, and the like.

[0256] In addition, the DRM-R service data and signaling information delivered through the above MDI / DCP are processed into IP packets in the UDP / IP layer, and the IP packets are processed into ALP packets in the link layer and then transmitted to the physical layer.

[0257] According to embodiments, the DST is encapsulated in one or more IP packets at the UDP / IP layer and in one or more ALP packets at the link layer and delivered to the physical layer. In one embodiment, the DST may be carried as the payload of IP packets having well-known addresses / ports.

[0258] At this time, SLT can also be carried as the payload of IP packets having well-known addresses / ports, and the address / port information carrying DST and the address / port information carrying SLT may be the same or different.

[0259] In Fig. 19, UDP / IP layer processing of the UDP / IP layer, link layer processing of the link layer, and physical layer processing of the physical layer are omitted to avoid redundant description, and detailed descriptions refer to the descriptions of Figs. 1 to 7.

[0260] In the present disclosure, DST can be transmitted using LLS (Low Layer Signaling) format.

[0261] Fig. 20 is a diagram illustrating another example of an LLS table according to embodiments. That is, the LLS table of Fig. 20 is an example for transmitting DST.

[0262] The description of the LLS_table_id field, LLS_group_id field, group_count_minus 1 field, LLS_table_version field and / or LLS_table_id field in the LLS table of Fig. 20 is referred to Fig. 2 and is omitted here to avoid redundant description.

[0263] According to embodiments, depending on the value of the LLS_table_id field, the LLS table may include one of an SLT (e.g., an LLS_table_id field having a value of 0x01), an RRT (Rating Region Table) (e.g., an LLS_table_id field having a value of 0x02), a System Time Fragment (e.g., an LLS_table_id field having a value of 0x03), an AEAT (Advanced Emergency Alert Table) (e.g., an LLS_table_id field having a value of 0x04), an Onscreen Message Notification fragment (e.g., an LLS_table_id field having a value of 0x05), a DST (e.g., an LLS_table_id field having a value of 0x06), and a SingnedMultiTable, which is a set of one or more LLS table instances (e.g., an LLS_table_id field having a value of 0xFE). In addition to these, other information may also be included in the LLS table depending on embodiments.

[0264] That is, the present disclosure can identify DST within LLS by assigning 0x06 to the LLS table id as in FIG. 19.

[0265] In one embodiment, the DST may include one or more of Service ID information, Service Type information, Service Signaling Protocol information, IP address and port number information, Service Announcement Data, Service Guide Information, Service Logo information, and Service Icon information.

[0266] As another embodiment, the present disclosure may define a DCP with a new value of the @slsProtocol property within an SLT, and provide bootstrap information of service signaling information for a DRM-R service within the SLT based on the value of the @slsProtocol property. In this case, the service signaling information for the DRM-R service may be transmitted through a broadcast network in IP packetization, or may be transmitted through a broadband network.

[0267] Fig. 21 is a block diagram showing an example of a receiving device according to embodiments.

[0268] The receiving device of FIG. 21 may be one of an ATSC 3.0 receiver, an ATSC 3.0 receiver including a DRM-R client, and a DRM-R receiver.

[0269] In one embodiment, assuming that a physical layer signal transmitted from an ATSC 3.0 transmitter includes both a ROUTE / MMTP-based service and an MDI / DCP-based DRM-R service, the ATSC 3.0 receiver can process only the ROUTE / MMTP-based service, the ATSC 3.0 receiver including the DRM-R client can process both the ROUTE / MMTP-based service and the MDI / DCP-based DRM-R service, and the DRM-R receiver can process only the MDI / DCP-based DRM-R service.

[0270] The present disclosure describes an embodiment in which the receiving device of FIG. 21 is an ATSC 3.0 receiver including a DRM-R client, and an ATSC 3.0 service and a DRM-R service are transmitted as in FIG. 19.

[0271] According to embodiments, the receiving device may include a tuner, which may be located internally or externally to the physical layer processor (3010).

[0272] The above tuner receives broadcast signals transmitted to a broadcast network through m (where m is 1 or more) antennas. In one embodiment, the physical layer processor (3010) performs demodulation, frame parsing, deinterleaving, error correction decoding, etc. on the broadcast signals received through the tuner.

[0273] FIG. 22 is a drawing showing an embodiment of a detailed block diagram of a physical layer processor (3010) according to embodiments.

[0274] A physical layer processor according to embodiments may include a synchronization and demodulation module (4000), a frame parsing module (4010), a demapping and decoding module (4020), an output processor (4030), and a signaling decoding module (4040).

[0275] The above synchronization and demodulation module (4000) performs synchronization on a broadcast signal received and processed by the tuner, and performs OFDM demodulation in the reverse process of a broadcast signal transmission device, according to one embodiment. That is, it can perform bootstrap information detection, FFT (Fast Fourier Transform) performance, pilot detection, etc.

[0276] The above frame parsing module (4010) may include a frequency deinterleaver, a frame parser, and a time deinterleaver. In the transmitting device of the present document, frequency interleaving is mandatory for the preamble symbols of the demodulated broadcast signal, and optional for the data symbols included in the subframe(s) of the demodulated broadcast signal. Therefore, the frequency deinterleaver performs frequency deinterleaving on the preamble symbols, and selectively performs frequency deinterleaving on the data symbols according to the L1D_frequency_interleaver field of the L1-Detail signaling data. The frequency-deinterleaved preamble symbols are output to the signaling decoding module (4040), and the signal frame including the data symbols of the subframe(s) on which frequency deinterleaving has been selectively performed is output to the frame parser and parsed.

[0277] The data pipes (i.e., PLPs) contained in the subframe(s) parsed by the above frame parser are output to a time deinterleaver for each data pipe and time deinterleaved in the reverse direction of the broadcast signal transmission device. The frame parsing and time deinterleaving are also performed based on L1 signaling data.

[0278] The signaling decoding module (4040) decodes the L1 signaling data included in the preamble and provides the information included in the L1 signaling data to the necessary blocks. To this end, the signaling decoding module (4040) includes, in one embodiment, a constellation demapper, a bit deinterleaver, and an FEC decoder, and performs decoding on the L1 signaling data in reverse order of a broadcast signal transmission device.

[0279] The above demapping and decoding module (4020) includes a demapper, a bit deinterleaver, and a decoder, and performs symbol demapping in the reverse process of a broadcast signal transmission device based on the L1 signaling data for the data of the corresponding data pipe, performs bit deinterleaving, and then performs error correction decoding. The output of the above demapping and decoding module (9020) is at least one baseband packet.

[0280] The output processor (4030) may perform the reverse process of various compression / signal processing procedures applied by the broadcast signal transmission device to improve transmission efficiency for the input baseband packet. In this case, the output processor (4030) may obtain necessary control information from the data output from the signaling decoding module (4040).

[0281] Decapsulation, adaptation, decompression processing, etc. for ALP packets included in the payload of the baseband packet may be performed in the physical layer or the link layer. If performed in the physical layer, the output processor (4030) may include a decapsulation module, an adaptation module, and a decompression module. In this case, the output processor (4030) processes the baseband packet in a reverse process of the broadcast signal transmission device to detect ALP packets, and performs decapsulation, adaptation, decompression processing, etc. on the detected ALP packets, according to one embodiment. If decapsulation, adaptation, decompression processing, etc. are performed in the link layer, the output of the output processor (4030) may be an ALP stream including link layer packets.

[0282] The present disclosure provides an embodiment of performing decapsulation, adaptation, decompression processing, etc. at a link layer.

[0283] In this case, the physical layer processor (3010) of FIG. 21 outputs at least one ALP stream containing link layer packets to the link layer processor (3020).

[0284] The above link layer processor (3020) performs link layer processing, such as decapsulation, on at least one input ALP stream. If header compression is applied to IP packets, decapsulation, adaptation, and decompression processing are performed to restore them to original IP packets.

[0285] If the input packets included in the ALP packets of a specific ALP stream are IP packets, the output of the link layer processor (3020) becomes IP packets. In this disclosure, IP packet and IP datagram are used interchangeably.

[0286] The above IP / UDP layer processor (3030) can parse SLT and / or DST from received IP packets.

[0287] For example, if DST is transmitted as in Fig. 20, LLS may include SLT and / or DST depending on the LLS table id value.

[0288] The IP / UDP layer processor (3030) can obtain service layer signaling information for an ATSC 3.0 service based on SLT, and can obtain service data for an ATSC 3.0 service carried through the ROUTE protocol or MMTP from IP packets based on the service layer signaling information. For example, the service layer signaling information can be obtained from IP packets. The service processor (3040) can process service data for an ATSC 3.0 service carried through the ROUTE protocol or MMTP to provide an ATSC 3.0 service to a user.

[0289] The above IP / UDP layer processor (3030) can obtain service layer signaling information for a DRM-R service based on DST, and can obtain service data for a DRM-R service carried through MDI / DCP from IP packets based on the service layer signaling information. For example, the service layer signaling information can be obtained from IP packets.

[0290] The above service processor (3040) can process service data for DRM-R service carried through MDI / DCP to provide DRM-R service to the user.

[0291] Each of the parts, modules, or units described above may be software, processors, or hardware parts that execute sequential execution processes stored in memory (or storage units). Each of the steps described in the embodiments described above may be performed by processors, software, or hardware parts. Each of the modules / blocks / units described in the embodiments described above may operate as a processor, software, or hardware. In addition, the methods presented in the embodiments may be implemented as code. This code may be written on a processor-readable storage medium and thus may be read by a processor provided by an apparatus.

[0292] Furthermore, throughout the specification, when a part is said to "include" a component, this does not exclude other components, unless otherwise specifically stated, but rather implies the inclusion of other components. Furthermore, terms such as "part" described in the specification mean a unit that processes at least one function or operation, which may be implemented using hardware, software, or a combination of hardware and software.

[0293] For convenience of explanation, this specification has been described separately in each drawing. However, it is also possible to design new embodiments by combining the embodiments described in each drawing. Furthermore, designing a computer-readable recording medium containing a program for executing the previously described embodiments, as required by those skilled in the art, is also within the scope of the embodiments.

[0294] The devices and methods according to the embodiments are not limited to the configurations and methods of the embodiments described above, but the embodiments may be configured by selectively combining all or part of each embodiment so that various modifications can be made.

[0295] Although preferred embodiments of the embodiments have been illustrated and described, the embodiments are not limited to the specific embodiments described above, and various modifications may be made by those skilled in the art to which the present disclosure pertains without departing from the spirit or scope of the embodiments claimed in the claims, and such modifications should not be understood individually from the technical idea or prospect of the embodiments.

[0296] The various components of the devices of the embodiments may be implemented by hardware, software, firmware, or a combination thereof. The various components of the embodiments may be implemented by a single chip, for example, a single hardware circuit. The components according to the embodiments may be implemented by separate chips. At least one of the components of the devices of the embodiments may be configured with one or more processors capable of executing one or more programs, and the one or more programs may perform, or include instructions for performing, one or more of the operations / methods according to the embodiments. The executable instructions for performing the methods / operations of the devices of the embodiments may be stored in non-transitory CRMs or other computer program products configured to be executed by one or more processors, or may be stored in temporary CRMs or other computer program products configured to be executed by one or more processors. In addition, the memory according to the embodiments may be used as a concept including not only volatile memory (e.g., RAM, etc.), but also non-volatile memory, flash memory, PROM, etc. Additionally, it may include implementations in the form of carrier waves, such as transmissions via the Internet. Furthermore, processor-readable recording media may be distributed across network-connected computer systems, allowing processor-readable code to be stored and executed in a distributed manner.

[0297] In this document, " / " and "," are interpreted as "and / or". For example, "A / B" is interpreted as "A and / or B", and "A, B" is interpreted as "A and / or B". Additionally, "A / B / C" means "at least one of A, B, and / or C". Also, "A, B, C" means "at least one of A, B, and / or C". Additionally, "or" in this document is interpreted as "and / or". For example, "A or B" can mean 1) "A" only, 2) "B" only, or 3) "A and B". In other words, "or" in this document can mean "additionally or alternatively".

[0298] Various elements of the embodiments may be implemented by hardware, software, firmware, or a combination thereof. Various elements of the embodiments may be implemented on a single chip, such as a hardware circuit. In some embodiments, the embodiments may optionally be implemented on separate chips. In some embodiments, at least one of the elements of the embodiments may be implemented within one or more processors that include instructions for performing operations according to the embodiments.

[0299] Additionally, the operations according to the embodiments described in this document may be performed by a transceiver device including one or more memories and / or one or more processors according to the embodiments. One or more memories may store programs for processing / controlling the operations according to the embodiments, and one or more processors may control various operations described in this document. One or more processors may be referred to as a controller, etc. The operations according to the embodiments may be performed by firmware, software, and / or a combination thereof, and the firmware, software, and / or a combination thereof may be stored in a processor or a memory.

[0300] Terms such as "first," "second," etc. may be used to describe various components of the embodiments. However, the various components according to the embodiments should not be interpreted as limited by these terms. These terms are merely used to distinguish one component from another. For example, a first user input signal may be referred to as a second user input signal. Similarly, a second user input signal may be referred to as a first user input signal. The use of these terms should be interpreted as not departing from the scope of the various embodiments. Although a first user input signal and a second user input signal are both user input signals, they do not mean the same user input signals unless the context clearly indicates otherwise.

[0301] The terminology used to describe the embodiments is for the purpose of describing particular embodiments and is not intended to be limiting of the embodiments. As used in the description of the embodiments and in the claims, the singular is intended to include the plural unless the context clearly dictates otherwise. The expressions “and / or” are used to mean all possible combinations of the terms. The expression “comprises” or “includes” describes the presence of features, numbers, steps, elements, and / or components, but does not mean that additional features, numbers, steps, elements, and / or components are not included. Conditional expressions such as “if” or “when” used to describe the embodiments are not intended to be limited to only optional cases. When a specific condition is satisfied, a related action is performed in response to a specific condition, or a related definition is intended to be interpreted.

[0302] Various embodiments have been described in the best mode for carrying out the present disclosure.

[0303] It will be apparent to those skilled in the art that various modifications and variations can be made to the present embodiments without departing from the spirit or scope of the present embodiments. Accordingly, the present embodiments are intended to include modifications and variations of the present embodiments provided they come within the scope of the appended claims and their equivalents.

Claims

1. Step of receiving a broadcast signal; A step of obtaining link layer packets by processing the above broadcast signal in a physical layer; A step of obtaining UDP / IP packets by link layer processing the above link layer packets; A step of obtaining first data packets based on a first delivery protocol or second data packets based on a second delivery protocol by processing the UDP / IP packets in a UDP / IP layer; and A receiving method comprising a step of processing the first data packets or the second data packets to obtain service data for a first service or to obtain service data for a second service.

2. In paragraph 1, A receiving method wherein the first service is a service defined in ATSC 3.0 and the second service is a service not defined in ATSC 3.

0.

3. In paragraph 2, A receiving method wherein the first service is one of a linear audio / video service, a linear audio-only service, an app-based service, an Electronic Service Guide (ESG) service, and a Digital Rights Management (DRM) data service, and the second service is a Digital Radio Mondiale (DRM) service.

4. In paragraph 3, A receiving method wherein the first delivery protocol is ROUTE (Real time Object delivery over Unidirectional Transport) protocol or MMTP (MPEG Media Transport Protocol), and the second delivery protocol is DCP (Distribution and Communications Protocol).

5. In paragraph 3, A receiving method in which signaling information for obtaining the second service is encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets are encapsulated into one or more link layer packets and received by a receiving device.

6. In paragraph 5, A receiving method wherein at least some of the signaling information for obtaining the second service is carried via the first delivery protocol or the second delivery protocol.

7. A physical layer processor that receives a broadcast signal and performs physical layer processing on the received broadcast signal to obtain link layer packets; A link layer processor that obtains UDP / IP packets by link layer processing the above link layer packets; A UDP / IP layer processor that processes the UDP / IP packets in the UDP / IP layer to obtain first data packets based on the first delivery protocol or second data packets based on the second delivery protocol; and A receiving device including a service processor that processes the first data packets or the second data packets to obtain service data for a first service or service data for a second service.

8. In paragraph 7, A receiving device in which the first service is a service defined in ATSC 3.0 and the second service is a service not defined in ATSC 3.

0.

9. In paragraph 8, A receiving device wherein the first service is one of a linear audio / video service, a linear audio-only service, an app-based service, an ESG service, or a DRM (Digital Rights Management) data service, and the second service is a DRM (Digital Radio Mondiale) service.

10. In paragraph 9, A receiving device wherein the first delivery protocol is a ROUTE protocol or MMTP, and the second delivery protocol is DCP.

11. In paragraph 9, A receiving device in which signaling information for obtaining the second service is encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets are received encapsulated into one or more link layer packets.

12. A step of delivering service data for the first service based on the first delivery protocol; A step of delivering service data for a second service based on a second delivery protocol; A step of encapsulating at least one of service data for a first service delivered based on the first delivery protocol or service data for a second service delivered based on the second delivery protocol into UDP / IP packets; A step of encapsulating the above UDP / IP packets into link layer packets; and A transmission method comprising a step of generating a broadcast signal by processing the above link layer packets in a physical layer.

13. In paragraph 12, A transmission method wherein the first service is a service defined in ATSC 3.0 and the second service is a service not defined in ATSC 3.

0.

14. In paragraph 13, A transmission method wherein the first service is one of a linear audio / video service, a linear audio-only service, an app-based service, an ESG service, or a DRM (Digital Rights Management) data service, and the second service is a DRM (Digital Radio Mondiale) service.

15. In paragraph 14, A transmission method wherein the first delivery protocol is a ROUTE protocol or MMTP, and the second delivery protocol is DCP.

16. In paragraph 14, A transmission method in which signaling information for obtaining the second service is encapsulated into one or more UDP / IP packets, and the one or more UDP / IP packets are encapsulated into one or more link layer packets.

17. In paragraph 16, A transmission method wherein at least some of the signaling information for obtaining the second service is carried via the first delivery protocol or the second delivery protocol.

18. In paragraph 12, A transmission method in which a link layer packet generator that generates link layer packets through the above encapsulation is located outside a broadcast gateway, the link layer packets are transmitted to the broadcast gateway based on ALPTP (ALP Transport Protocol), and the link layer packets are transmitted from the broadcast gateway to a receiving device based on STLTP (STL Transport Protocol).

19. In paragraph 12, A transmission method in which a link layer packet generator that generates link layer packets through the above encapsulation is located inside a broadcast gateway, and the link layer packets are transmitted to a receiving device based on STLTP.

20. A computer program stored on a computer-readable recording medium that is combined with a computer as hardware and enables the method of claim 12 to be performed.

Images