KR20200132464A - Method for providing additional content of service handoff in the terrestrial uhd broadcasting and apparatus using the same - Google Patents

Abstract

Disclosed are a method for providing service handoff additional content in terrestrial UHD broadcasting and a device therefor. According to an embodiment of the present invention, the method for providing service handoff additional content comprises the following steps of: providing, by a service handoff additional content server, additional content to a user terminal that uses a mobile broadcasting service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system; and executing, by a user terminal, the additional content in a service discontinuous section by service handoff performed as moving in a broadcasting area. Therefore, the inconvenience of a user can be reduced.

Description

A method of providing service handoff supplementary content in terrestrial UHD broadcasting, and a device therefor {METHOD FOR PROVIDING ADDITIONAL CONTENT OF SERVICE HANDOFF IN THE TERRESTRIAL UHD BROADCASTING AND APPARATUS USING THE SAME}

The present invention relates to a technology for providing service handoff supplementary content. In particular, when a broadcasting area is moved or a signal is located in an area where the signal is not good, the present invention provides a service handoff that connects to a communication network instead of a broadcasting network to continue service. It relates to a technology for providing additional content.

In providing a mobile broadcasting service, a case may occur when a user moves around a region or is located in a shadow area, or a signal reception state is not good. For example, referring to FIG. 1, a viewer 100 moving from a broadcasting area B 130 to a broadcasting area C 140 has to manually search for service information in an adjacent area and then find and select the service. It is accompanied by rejuvenation.

To this end, mobile broadcasting technology provides a service following function that automatically moves a region in a digital radio. In order to apply the function of this concept to an ATSC 3.0 based mobile broadcasting environment, service linkage information must be transmitted through a broadcasting network or other communication network 110.

In the case of delivering through a broadcasting network, related information for continuing the service is required through streaming addresses provided in an adjacent area or broadband. In order to handoff a service through a broadcasting network, a frequency of an adjacent area and a broadcaster identifier, generally a broadcast stream identifier (BSID) and a service identifier are required. After tuning adjacent areas using these identifiers, it is possible to handoff to the same or similar service.

Such service handoff information can be delivered to a receiver through a signaling method of a broadcast network. In general, a receiver receives a service and separately transmits signaling information to show related service information to a user. ATSC 3.0 stipulates such service signaling in the A/331 standard, and service handoff information must be provided for each service, so it can be delivered together with information delivered in Service Layer Signaling (SLS).

When the service handoff information is received by the receiver, the adjacent RF area is tuned to find a service to be linked. If a service to be linked to is not found in an adjacent RF area, the service can be linked through streaming reception using a communication network based on the provided URL.

Korean Patent Publication No. 10-2010-0066371, published on June 17, 2010 (Name: Method and apparatus for transmitting/receiving signals for handoff in broadcasting network)

An object of the present invention is to reduce user discomfort by providing additional content based on a communication network in a section in which a video cannot be displayed on the screen because a signal is not good during a service handoff execution process or the sound of a sound source is broken. .

In addition, an object of the present invention is to provide a service in a form that is beneficial to viewers based on additional content previously stored or downloaded in a service discontinuity section caused by a service handoff.

In the method for providing handoff supplementary content according to the present invention for achieving the above object, a service handoff supplementary content server is added to a user terminal using a mobile broadcast service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system. Providing content; And executing, by the user terminal, the additional content in a service discontinuity section due to a service handoff performed as the broadcasting area moves.

In this case, the additional content may be provided to the user terminal in advance before the service handoff is performed, and may be executed based on a decoder in the user terminal when the service handoff is performed.

In this case, when the additional content is provided through the broadcasting network, the additional content may be provided in a form corresponding to at least one of multimedia content and content composed of a stream corresponding to any one of HEVC and MPEG-H.

In this case, the additional content may correspond to at least one of video, audio, image, text, and an application defined by ATSC 3.0.

In this case, the user terminal may correspond to an ATSC 3.0 receiving module supporting service handoff.

In this case, the user terminal may build a database for the service handoff by receiving signaling information in advance based on the ATSC 3.0 transmission system.

In this case, the database may include frequency information corresponding to an adjacent RF region within a preset distance from the user terminal.

In this case, in the service handoff, when the service reception state monitored by the user terminal falls below a preset reference state, the searched linkable service is provided by tuning adjacent RF regions within the preset distance based on the database. It can be done on a basis.

In this case, when the additional content is provided through the broadcasting network, it may be configured as DASH SEGMENTS through the ENCODER&DASH FORMATTER specified in the ATSC 3.0 A/331 standard and transmitted to the user terminal.

In addition, a handoff additional content server according to an embodiment of the present invention includes a processor that provides additional content to a user terminal using a mobile broadcasting service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system; And a memory for storing frequency information corresponding to an adjacent RF region within a preset distance from the user terminal, wherein the user terminal is in a service discontinuity section due to a service handoff performed as the broadcasting region is moved. Run the additional content.

According to the present invention, it is possible to reduce user discomfort by providing additional content based on a communication network in a section in which a video cannot be displayed on a screen due to a bad signal during a service handoff execution process or a sound from a sound source is broken. have.

In addition, the present invention can provide a service in a form that is beneficial to viewers based on additional content previously stored or downloaded in a service discontinuity section caused by a service handoff.

1 is a diagram showing an example of a service handoff to an adjacent area or a service handoff through a communication network when a mobile broadcast is received.
2 is a diagram illustrating a system for providing service handoff additional content according to an embodiment of the present invention.
3 is a flowchart illustrating a method of providing service handoff additional content according to an embodiment of the present invention.
4 is a diagram showing an example of an application section of additional content according to the present invention.
5 is a diagram showing an example of a process of delivering additional content through a broadcasting network or a communication network according to the present invention.
6 is a diagram showing an example of a user terminal according to the present invention.
7 is a diagram showing an example of a process of transmitting additional content by applying ROUTE according to the present invention.
8 to 10 are diagrams showing an example of multiplexer and service signaling for transmitting additional content according to the present invention.
11 is a block diagram showing a service handoff supplementary content server according to an embodiment of the present invention.

The present invention will be described in detail with reference to the accompanying drawings as follows. Here, repeated descriptions, well-known functions that may unnecessarily obscure the subject matter of the present invention, and detailed descriptions of configurations are omitted. Embodiments of the present invention are provided to more completely explain the present invention to those with average knowledge in the art. Accordingly, the shapes and sizes of elements in the drawings may be exaggerated for clearer explanation.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

2 is a diagram illustrating a system for providing service handoff additional content according to an embodiment of the present invention.

2, the service handoff supplementary content providing system according to an embodiment of the present invention includes a transmission system consisting of an HEVC encoder for video transmission, a ROUTE/MMT server, a signaling server, an ATSC 3.0 gateway, and an ATSC 3.0 modulator, and an ATSC. It can be classified as a 3.0 receiver.

In this case, signaling information corresponding to service-related additional information may be converted through a signaling server, and may be multiplexed and delivered based on an ATSC 3.0 gateway. In this case, the signaling server may convert SLT/SLS data into signaling data specified in ATSC 3.0 and transmit it.

In this case, additional signaling information for service handoff according to an embodiment of the present invention may be processed by a signaling server in a service handoff data format and transmitted through an ATSC 3.0 gateway. In this case, the service handoff data may be configured and delivered separately from other SLS signaling data.

In this case, the service handoff data may be transmitted to the ATSC 3.0 receiver through the ATSC 3.0 broadcasting network 220. Thereafter, when a service handoff situation occurs, the ATSC 3.0 receiver may search for a linkable service by tuning an adjacent area signal using the service handoff data. This process may take a long time, and the screen or audio of the content 201 that has been serviced may not be continued and may be maintained in a stopped state. That is, a service discontinuity section in which a service is not continuously provided occurs, and such a service discontinuity section may last a little longer when there are many adjacent areas or a target to be handed off is not quickly determined.

Accordingly, in the present invention, as shown in FIG. 2, by providing additional content 202 (video, advertisement, audio, image or text) to the ATSC 3.0 receiver in advance based on the broadcasting network 220 or the communication network 230 After saving, the additional content 202 stored in the service discontinuous section due to the service handoff may be displayed on the screen. In addition, when an advertisement image is provided in a service discontinuous section, additional advertisement revenue may be provided to the broadcaster.

In order to enable these processes, a service handoff additional content server 210 for providing additional content 202 through a communication network 230 such as the broadcasting network 220 or a broadband network may be required.

In this case, the additional content 202 generated from the service handoff additional content server 210 may be previously delivered to the ATSC 3.0 receiver through the NRT server in non-real time and stored in the case of delivery through the broadcasting network 220. have.

In this case, the NRT server generally corresponds to a server having a function for repeatedly transmitting a file object in advance, and in ATSC 3.0 technology, a Real-time Object Delivery over Unidirectional Transport (ROUTE) technology may be applied. That is, it may be assumed that the additional content 202 according to an embodiment of the present invention is generally delivered and stored in advance to the ATSC 3.0 receiver before service handoff is performed.

In addition, the additional content 202 according to an embodiment of the present invention may be downloaded and provided in advance to an ATSC 3.0 receiver through the communication network 230. To this end, information such as URL may be provided to the ATSC 3.0 receiver, and such information may be included in service handoff data and transmitted. Therefore, the ATSC 3.0 receiver has information for interworking with the service handoff supplementary content server 210 through the communication network 230 in advance, and then, if necessary, the service handoff supplementary content server ( 210) to download additional content.

As described above, in the present invention, the method of delivering the additional content 202 by service handoff to the broadcasting network 220 is not limited, but a method using the communication network 230 or other method is used to transmit and store the additional content to the ATSC 3.0 receiver in advance. It can be provided to a user by reproducing it in a service discontinuous section during service handoff.

3 is a flowchart illustrating a method of providing service handoff additional content according to an embodiment of the present invention.

Referring to FIG. 3, in a method for providing service handoff supplementary content according to an embodiment of the present invention, a service handoff supplementary content server is a user who uses a mobile broadcast service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system. Additional content is provided to the terminal (S310).

For example, referring to FIG. 5, the service handoff additional content server 510 transmits the additional content to the ATSC 3.0 receiver 520 that is a user terminal through the ATSC 3.0 transmission system-based broadcasting network 511 or the communication network ( 512) through the ATSC 3.0 receiver 520.

In this case, the additional content delivered to the ATSC 3.0 receiver 520 corresponds to at least one of a multimedia content and a content composed of a stream corresponding to any one of HEVC and MPEG-H when provided through the broadcasting network 511 It can be provided in a form.

In this case, the ATSC 3.0 transmission system shown in FIG. 5 is a system including an NRT server and an ATSC 3.0 gateway, and includes equipment for transmission, and may correspond to a transmission system that satisfies the ATSC 3.0 standard.

In this case, the ATSC 3.0 receiver 520 shown in FIG. 5 may be simplified and configured with an ATSC 3.0 baseband processing module 521, a service handoff processing unit 522, and a decoder 523. The ATSC 3.0 baseband processing module 521 may receive an ATSC 3.0 broadcast signal based on the broadcast network 511 and perform a function of extracting corresponding service data.

For example, the additional content delivered from the ATSC 3.0 baseband module 521 may be processed, stored and managed by the service handoff processing unit 522 for the service handoff additional content provision service, and the additional content must be provided. At a time point, it may be reproduced through the decoder 523 and output on the screen of the ATSC 3.0 receiver 520.

In this case, the service handoff processing unit 522 shown in FIG. 5 may receive and process the file object by applying the ATSC 3.0 NRT standard, specifically ROUTE, to restore the file object.

In addition, when the additional content is provided through the communication network 512, the service handoff processing unit 522 may access the service handoff additional content server 510 based on an access address such as a URL to receive the additional content. have. In this case, a method of receiving additional content from the service handoff additional content server 510 using the communication network 512 may apply various Internet protocols including HTTP.

In this case, the additional content that can be delivered from the service handoff additional content server 510 may correspond to at least one of a video, an audio, an image, a text, and an application defined in ATSC 3.0. The additional content provided as described above is pre-delivered to the ATSC 3.0 receiver 520 and is being prepared, and then played back at a time when a service handoff is required, and can be output through a screen, a speaker, or other output device of the ATSC 3.0 receiver 520. .

In this case, when the additional content is provided through a broadcasting network, it may be configured as DASH SEGMENTS through the ENCODER&DASH FORMATTER specified in the ATSC 3.0 A/331 standard and transmitted to the user terminal.

For example, referring to FIG. 7, the additional content generated from the service handoff additional content server according to an embodiment of the present invention is composed of DASH Segments through the Encoder & DASH Formatter specified in the ATSC 3.0 A/331 standard. And transmitted to the ATSC 3.0 receiver 700.

At this time, metadata about the additional content (metadata, additional information necessary for restoring a corresponding object in an ATSC 3.0 receiver) may be included in service signaling and transmitted separately. For example, metadata for additional content may be generated and delivered according to the SLS signaling standard defined in the ATSC 3.0 A/331 standard based on the SLS Sender of the root sander 710 shown in FIG. 7.

The meta data delivered in this way corresponds to an extended FDT extended in ATSC 3.0 as a File Delivery Table (FDT) defined in the FLUTE standard. In this case, the EFDT may be included in and delivered in a Service-based Transport Session Instance Description (S-TSID) through an SLS Sender as shown in FIG. 7.

At this time, the EFDT is detailed information for restoring the corresponding content in the ATSC 3.0 receiver 700, and is a file identifier (generally expressed as a URI), a file name, which are FDT properties specified by FLUTE. It may include a file type, file size, content encoding, and security properties.

For example, the file identifier may be displayed as a TOI (Transfer Object Identifier). In addition, the file name is generally Content-Location having a URI (Uniform Resource Identifier) value, the file type is Content-Type, the file size is Content-Length, the content encoding is Content-Encoding to inform the same method as gzip, and the password property is It is configured in a format corresponding to Contnet-MD5 and may be delivered to the ATSC 3.0 receiver 700 through a path for transmitting signaling data.

At this time, the ATSC 3.0 receiver 700 may apply the EFDT extended FDT, and the EFDT version, the maximum expiration time (maxExpiresDelta), the maximum transmission size (maxTransportSize), the app context identification list in addition to the value defined in the FDT. Properties such as (appContextIdList), file template, and filter code may be additionally included.

In this case, the EFDT version may mean the version of the corresponding EFDT element. In addition, the maximum expiration time may mean the expiration time of the EFDT, and the maximum transmission size may represent the maximum byte size value of the delivery object (file) described by the EFDT. In addition, the app context identification list (appContextIDList) can be used as information (identifier) for grouping files to be used in Broadcaster Applications defined in ATSC 3.0 A334 "Interactive Content". Also, the file template can be used to construct the URL of the file. Finally, the filter code corresponds to a value used for personalization description by a broadcaster, and may mean a code applied to all files delivered through a corresponding source delivery path.

At this time, metadata (EFDT) and objects (files or binary sequences) of the additional content described in FIG. 7 must be configured and transmitted according to the ATSC 3.0 transmission method. Hereinafter, such a process will be described with reference to FIGS. 8 to 10 Do it.

If, assuming that the service requiring service handoff is service #1, initial information on service #1 may be delivered to the ATSC 3.0 receiver through the SLT 910. In this case, the initial information may include at least one of a service identifier, a service name, a protocol type, and multiplexing information.

After that, after acquiring service delivery information through the SLT 910, the PLP is accessed from the physical layer frame to receive service signaling and each component (video, audio, data, or NRT data) constituting the service. have.

In this case, referring to FIG. 9, the ATSC 3.0 receiver may first access the LCT (tsi-sls) of the PLP (#1) to receive related service signaling information, and then receive each component constituting the service. It can be decoded and provided to the user (901). In this case, in the case of a video service, after accessing the separately transmitted video and audio segments, segments transmitted in real time may be received and decoded, and may be output through the screen or speaker of the ATSC 3.0 receiver.

If it is desired to provide additional content according to an embodiment of the present invention during the service handoff, the ATSC 3.0 receiver receives NRT segments transmitted through the LCT (tsi-nrt) channel, restores the corresponding data, and then provides service. It can be provided in the middle of a handoff.

For this, metadata, which is the promised information for playing the additional content, is required. The metadata can be provided in various ways, but it may be desirable to be provided by including it in the service handoff description in general. have.

For example, information specifying a service handoff may be represented as shown in [Table 1], and service or broadband address information of a neighboring area that can be linked with a corresponding service may be provided.

Element or Attribute Name Use Data Type Short Description Service Handoff Description Root Element of Service HandoffDescription HandoffServices 0..1 Service handoff information @serviceid One unsignedShort Integer number that identifies this service within the scope of this broad area. HandoffviaBroadcast 0..N Handoff list via broadcast network @frequency 0..1 unsignedInteger The center_frequency is a 32-bit field giving the center frequency value in multiples of 10Hz. The coding range is from minimum 10 Hz(0x00000001) up to a maximum of 42949672950 Hz(0xFFFFFFFF) @bsid One slt:listOfUnsignedShort Identifies the one or more broadcast streams comprising the services @handoffserviceid One unsignedShort Inter number that identifies this service within the scope of handoff broadcast area. @handofftype 0..1 boolean The type of service handoff
1: hard handoff
0: soft handoff HandoffviaBroadband 0..1 Handoff list via broadband network @handoffURL One anyURI URL to access the service provided via the broadband @handofftype 0..1 boolean The type of service handoff
1: hard handoff
0: soft handoff HandoffContentviaBroadcast 0..1 Handoff content discovery via broadcast @in-service One Boolean 1: deliverd in the same service (PLP)
0: deliverd in the other service(other PLP) @otherserviceid 0..1 unsignedInt The value of service id of other service that carries the relevant handoffcontent file.
If in-band value is '0', this value can be present @tsi One unsignedInt TSI value that carries the handoffcontent file @Content-Location 0..1 The name of the content HandoffContentviaBroadBand 0..1 Handoff content discovery via broadband @handoffcontentURL One anyURI URL to access the handoff content provided via the broadband

That is, as illustrated in [Table 1], when additional content is transmitted (in-band) in the same PLP, identification information on the additional content may be specified corresponding to a transport session identifier (TSI).

On the other hand, as shown in FIGS. 8 to 10, when additional content is transmitted through another PLP, a service id may be additionally specified.

That is, as illustrated in [Table 1], when handoff is performed through an adjacent broadcasting network, linkage may be performed to a service provided in an adjacent region through frequency, bsid, handoffserviceid, and handofftype specified in the HandoffviaBroadcast element.

In this case, frequency is a parameter indicating a frequency of an adjacent region, bsid is a parameter indicating a broadcast stream identifier, handoffserviceid is a parameter indicating the same or similar service identifier to be linked, and handofftype is whether the service to be linked is the same or similar. May correspond to a parameter representing

If it is not possible to link a service through a broadcasting network, service linkage is possible through streaming reception using a communication network. For this, a HandoffviaBroadband element may be provided as illustrated in [Table 1].

In this case, as a parameter of the HandoffviaBroadband element, a handofftype indicating whether a service to be linked with a handoffURL specifying a URL that is a streaming address on the Internet is similar or the same may be included.

If the additional content is provided through a broadcasting network, metadata for the additional content may be provided through the HandoffContentviaBroadcast element. To this end, the HandoffContentviaBroadcast element may have parameter values such as in-service, otherserviced, and tsi.

In this case, the in-service may correspond to a flag indicating whether the additional content is transmitted in the same PLP or through another PLP. If the in-service value is '1', since additional content is transmitted within the same PLP, that is, the same service, only a tsi value is required, and a service id value may not be required. In addition, if the in-service value is '0', it means that the additional content is transmitted from another PLP, so the otherserviceid may be required together with the tsi value.

In this case, the ATSC 3.0 receiver may receive and identify additional content based on this information, and then play and output the identified additional content in a service discontinuity section that occurs when a service handoff event occurs.

In addition, when additional content is transmitted in-service through a broadcasting network, the additional content may be repeatedly transmitted along with the service within a section in which the service is being provided.

For example, in the case of a scenario in which additional content is transmitted in advance during a late night time, which is a service idle time, and when a service handoff event occurs, additional content is used, a separate PLP may be allocated, and then an NRT service may be designated and transmitted. In this case, the ATSC 3.0 receiver may receive and include related additional content in advance in a corresponding time slot. In this case, the received additional content may be identified by the name of the content corresponding to the content-location (generally URI) specified in the FDT. That is, it is possible to identify additional content by adding the @Content-Location parameter as in the data structure illustrated in [Table 1]. This value can be designated as a unique value so that duplication of each service or broadcaster does not occur.

In addition, in order to transmit additional content through a communication network, a HandoffContentviaBroadband element may be included in the data structure as illustrated in [Table 1]. In this case, the HandoffContentviaBroadband element may include a handoffcontentURL parameter for specifying a URL address on the Internet.

Accordingly, the ATSC 3.0 receiver may access the Internet address corresponding to the handoffcontentURL to receive the additional content, and then play the additional content received in the service discontinuity section due to the service handoff and provide it to the user. In general, the HTTP protocol can be applied to file download using the Internet, and additional content can be provided in the form of streaming.

In addition, the method of providing service handoff supplementary contents according to an embodiment of the present invention executes supplementary contents in a service discontinuity section due to a service handoff performed as a user terminal moves a broadcasting area (S320). .

In this case, the additional content may be provided to the user terminal before service handoff is performed, and may be executed based on a decoder in the user terminal when the service handoff is performed.

For example, referring to FIG. 4, content A 410 may mean a service section currently being received by a user terminal, and content A` 411 can mean a service section to be linked by a handoff service. have. In this case, a section corresponding to the additional content 420 in FIG. 4 may mean a playback section of the additional content provided in the user terminal in advance through a broadcasting network, a communication network, or other method.

That is, there is a service discontinuity section corresponding to the service handoff section between the content A 410 and the content A` 411, and in this service discontinuity section, the additional content 420 previously stored in the user terminal is By doing so, more useful information can be provided to the user watching the user terminal.

At this time, as shown in FIG. 4, service discontinuous sections 421 and 422 may exist between the content A 410 and the additional content 420 or between the additional content 420 and the content A` 411, respectively, The discontinuous section may appear shorter than the length of the service handoff section.

In this case, the user terminal may correspond to an ATSC 3.0 receiving module supporting service handoff.

In this case, the user terminal may construct a database for service handoff by receiving signaling information in advance based on the ATSC 3.0 transmission system.

In this case, the database may include frequency information corresponding to an adjacent RF region within a preset distance from the user terminal.

At this time, the service handoff is performed based on the searched linkable service by tuning adjacent RF regions within a preset distance based on the database when the service reception state monitored by the user terminal falls below a preset reference state. Can be.

For example, referring to FIG. 6, the ATSC 3.0 receiver 600 according to an embodiment of the present invention includes tuner modules 610 and 611, a baseband processing unit 620, a service handoff processing unit 640, and a broadband processing unit. It can be composed of 630.

First, at least one tuner module 610 and 611 may be provided to perform a function of receiving an RF signal. At this time, since one or more tuner modules 610 and 611 are provided, there is an advantage in that it is possible to quickly tune a service to be linked during RF service handoff.

The baseband processing unit 620 may perform the same function as the ATSC 3.0 baseband module 521 described in FIG. 5.

The service handoff processing unit 640 may periodically monitor a service reception state. In this case, the error rate of the packet received together with the RF signal can be monitored, and when the error and error are higher than a preset level, a service handoff can be performed. To this end, the service handoff processing unit 640 may receive signaling information transmitted through the ATSC 3.0 broadcasting network in advance, and establish linkage information for service handoff, that is, a database.

In addition, the service handoff processing unit 640 may receive and store the additional content through a broadcasting network or a broadband network (communication network) in advance in order to provide the additional content to be presented in the present invention. After that, the stored additional content can be played immediately during service handoff.

To describe the procedure of the service handoff processing unit 640 in detail, a database for service handoff may be constructed by first receiving signaling information.

After that, you can monitor the status of the service that is always being received. If the reception state of a service is not good, a service handoff can be determined, and when a service handoff is determined, a linkable service can be searched by tuning an adjacent RF region through a database in advance.

At this time, after checking a signal using frequency information provided in the database, a service that can be linked can be found by tuning an RF band that is a good signal within a predetermined range. If a service to be linked to is not found in an adjacent RF area, the service can be linked through a communication network by accessing a designated Internet address.

At this time, if the service is linked to the RF area based on the broadcasting network, the service handoff can be determined in consideration of the state of the RF signal at the moment, but if the service handoff is made to the broadband based on the communication network, the previous RF band or adjacent Service handoff can be determined by periodically monitoring the signal of the RF band.

In addition, when a service with a good signal is identified in an adjacent RF area while receiving a service by performing a service handoff to a communication network, the service may be returned to the RF area and the corresponding service may be continuously provided.

In addition, although not shown in FIG. 3, the method of providing service handoff additional content according to an embodiment of the present invention may store various pieces of information generated in the process of providing additional content described above in a separate storage module.

Through this method of providing additional content for service handoff, the user can provide additional content based on the communication network in the section where the video cannot be displayed on the screen because the signal is not good during the service handoff execution process or the sound of the sound source is broken. It can reduce discomfort.

In addition, a service in a form that is beneficial to viewers may be provided based on additional content previously stored or downloaded in a service discontinuity section caused by a service handoff.

11 is a block diagram showing a service handoff supplementary content server according to an embodiment of the present invention.

Referring to FIG. 11, a service handoff supplementary content server according to an embodiment of the present invention includes a communication unit 1110, a processor 1120, and a memory 1130.

The communication unit 1110 may serve to transmit additional content and related information by service handoff to a user terminal through a network such as a broadcasting network or a communication network.

The processor 1120 provides additional content to a user terminal using a mobile broadcasting service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system.

For example, referring to FIG. 5, the processor 1120 transmits additional content to the ATSC 3.0 receiver 520 that is a user terminal through the ATSC 3.0 transmission system-based broadcasting network 511 or the ATSC 3.0 receiver 520 through the communication network 512. 3.0 may be responsible for a function of directly transmitting to the receiver 520.

In this case, the additional content delivered to the ATSC 3.0 receiver 520 corresponds to at least one of a multimedia content and a content composed of a stream corresponding to any one of HEVC and MPEG-H when provided through the broadcasting network 511 It can be provided in a form.

In this case, the ATSC 3.0 transmission system shown in FIG. 5 is a system including an NRT server and an ATSC 3.0 gateway, and includes equipment for transmission, and may correspond to a transmission system that satisfies the ATSC 3.0 standard.

In this case, the ATSC 3.0 receiver 520 shown in FIG. 5 may be simplified and configured with an ATSC 3.0 baseband processing module 521, a service handoff processing unit 522, and a decoder 523. The ATSC 3.0 baseband processing module 521 may receive an ATSC 3.0 broadcast signal based on the broadcast network 511 and perform a function of extracting corresponding service data.

For example, the additional content delivered from the ATSC 3.0 baseband module 521 may be processed, stored and managed by the service handoff processing unit 522 for the service handoff additional content provision service, and the additional content must be provided. At a time point, it may be reproduced through the decoder 523 and output on the screen of the ATSC 3.0 receiver 520.

In this case, the service handoff processing unit 522 shown in FIG. 5 may receive and process the file object by applying the ATSC 3.0 NRT standard, specifically ROUTE, to restore the file object.

In addition, when the additional content is provided through the communication network 512, the service handoff processing unit 522 may access the service handoff additional content server 510 based on an access address such as a URL to receive the additional content. have. In this case, a method of receiving additional content from the service handoff additional content server 510 using the communication network 512 may apply various Internet protocols including HTTP.

In this case, the additional content that can be delivered from the service handoff additional content server 510 may correspond to at least one of a video, an audio, an image, a text, and an application defined in ATSC 3.0. The additional content provided as described above is pre-delivered to the ATSC 3.0 receiver 520 and is being prepared, and then played back at a time when a service handoff is required, and can be output through a screen, a speaker, or other output device of the ATSC 3.0 receiver 520. .

In this case, when the additional content is provided through a broadcasting network, it may be configured as DASH SEGMENTS through the ENCODER&DASH FORMATTER specified in the ATSC 3.0 A/331 standard and transmitted to the user terminal.

For example, referring to FIG. 7, the additional content generated from the service handoff additional content server according to an embodiment of the present invention is composed of DASH Segments through the Encoder & DASH Formatter specified in the ATSC 3.0 A/331 standard. And transmitted to the ATSC 3.0 receiver 700.

At this time, metadata about the additional content (metadata, additional information necessary for restoring a corresponding object in an ATSC 3.0 receiver) may be included in service signaling and transmitted separately. For example, metadata for additional content may be generated and delivered according to the SLS signaling standard defined in the ATSC 3.0 A/331 standard based on the SLS Sender of the root sander 710 shown in FIG. 7.

The meta data delivered in this way corresponds to an extended FDT extended in ATSC 3.0 as a File Delivery Table (FDT) defined in the FLUTE standard. In this case, the EFDT may be included in and delivered in a Service-based Transport Session Instance Description (S-TSID) through an SLS Sender as shown in FIG. 7.

At this time, the EFDT is detailed information for restoring the corresponding content in the ATSC 3.0 receiver 700, and is a file identifier (generally expressed as a URI), a file name, which are FDT properties specified by FLUTE. It may include a file type, file size, content encoding, and security properties.

For example, the file identifier may be displayed as a TOI (Transfer Object Identifier). In addition, the file name is generally Content-Location having a URI (Uniform Resource Identifier) value, the file type is Content-Type, the file size is Content-Length, the content encoding is Content-Encoding to inform the same method as gzip, and the password property is It is configured in a format corresponding to Contnet-MD5 and may be delivered to the ATSC 3.0 receiver 700 through a path for transmitting signaling data.

At this time, the ATSC 3.0 receiver 700 may apply the EFDT extended FDT, and the EFDT version, the maximum expiration time (maxExpiresDelta), the maximum transmission size (maxTransportSize), the app context identification list in addition to the value defined in the FDT. Properties such as (appContextIdList), file template, and filter code may be additionally included.

In this case, the EFDT version may mean the version of the corresponding EFDT element. In addition, the maximum expiration time may mean the expiration time of the EFDT, and the maximum transmission size may represent the maximum byte size value of the delivery object (file) described by the EFDT. In addition, the app context identification list (appContextIDList) can be used as information (identifier) for grouping files to be used in Broadcaster Applications defined in ATSC 3.0 A334 "Interactive Content". Also, the file template can be used to construct the URL of the file. Finally, the filter code corresponds to a value used for personalization description by a broadcaster, and may mean a code applied to all files delivered through a corresponding source delivery path.

At this time, metadata (EFDT) and objects (files or binary sequences) of the additional content described in FIG. 7 must be configured and transmitted according to the ATSC 3.0 transmission method. Hereinafter, such a process will be described with reference to FIGS. 8 to 10 Do it.

If, assuming that the service requiring service handoff is service #1, initial information on service #1 may be delivered to the ATSC 3.0 receiver through the SLT 910. In this case, the initial information may include at least one of a service identifier, a service name, a protocol type, and multiplexing information.

After that, after acquiring service delivery information through the SLT 910, the PLP is accessed from the physical layer frame to receive service signaling and each component (video, audio, data, or NRT data) constituting the service. have.

In this case, referring to FIG. 9, the ATSC 3.0 receiver may first access the LCT (tsi-sls) of the PLP (#1) to receive related service signaling information, and then receive each component constituting the service. It can be decoded and provided to the user (901). In this case, in the case of a video service, after accessing the separately transmitted video and audio segments, segments transmitted in real time may be received and decoded, and may be output through the screen or speaker of the ATSC 3.0 receiver.

If it is desired to provide additional content according to an embodiment of the present invention during the service handoff, the ATSC 3.0 receiver receives NRT segments transmitted through the LCT (tsi-nrt) channel, restores the corresponding data, and then provides service. It can be provided in the middle of a handoff.

For this, metadata, which is the promised information for playing the additional content, is required. The metadata can be provided in various ways, but it may be desirable to be provided by including it in the service handoff description in general. have.

For example, information specifying a service handoff may be represented as shown in [Table 1] above, and service or broadband address information of a neighboring area that can be linked with a corresponding service may be provided.

That is, as illustrated in [Table 1], when additional content is transmitted (in-band) in the same PLP, identification information on the additional content may be specified corresponding to a transport session identifier (TSI).

On the other hand, as shown in FIGS. 8 to 10, when additional content is transmitted through another PLP, a service id may be additionally specified.

That is, as illustrated in [Table 1], when handoff is performed through an adjacent broadcasting network, linkage may be performed to a service provided in an adjacent region through frequency, bsid, handoffserviceid, and handofftype specified in the HandoffviaBroadcast element.

In this case, frequency is a parameter indicating a frequency of an adjacent region, bsid is a parameter indicating a broadcast stream identifier, handoffserviceid is a parameter indicating the same or similar service identifier to be linked, and handofftype is whether the service to be linked is the same or similar. May correspond to a parameter representing

If it is not possible to link a service through a broadcasting network, service linkage is possible through streaming reception using a communication network. For this, a HandoffviaBroadband element may be provided as illustrated in [Table 1].

In this case, as a parameter of the HandoffviaBroadband element, a handofftype indicating whether a service to be linked with a handoffURL specifying a URL that is a streaming address on the Internet is similar or the same may be included.

If the additional content is provided through a broadcasting network, metadata for the additional content may be provided through the HandoffContentviaBroadcast element. To this end, the HandoffContentviaBroadcast element may have parameter values such as in-service, otherserviced, and tsi.

In this case, the in-service may correspond to a flag indicating whether the additional content is transmitted in the same PLP or through another PLP. If the in-service value is '1', since additional content is transmitted within the same PLP, that is, the same service, only a tsi value is required, and a service id value may not be required. In addition, if the in-service value is '0', it means that the additional content is transmitted from another PLP, so the otherserviceid may be required together with the tsi value.

In this case, the ATSC 3.0 receiver may receive and identify additional content based on this information, and then play and output the identified additional content in a service discontinuity section that occurs when a service handoff event occurs.

In addition, when additional content is transmitted in-service through a broadcasting network, the additional content may be repeatedly transmitted along with the service within a section in which the service is being provided.

For example, in the case of a scenario in which additional content is transmitted in advance during a late night time, which is a service idle time, and when a service handoff event occurs, additional content is used, a separate PLP may be allocated, and then an NRT service may be designated and transmitted. In this case, the ATSC 3.0 receiver may receive and include related additional content in advance in a corresponding time slot. In this case, the received additional content may be identified by the name of the content corresponding to the content-location (generally URI) specified in the FDT. That is, it is possible to identify additional content by adding the @Content-Location parameter as in the data structure illustrated in [Table 1]. This value can be designated as a unique value so that duplication of each service or broadcaster does not occur.

In addition, in order to transmit additional content through a communication network, a HandoffContentviaBroadband element may be included in the data structure as illustrated in [Table 1]. In this case, the HandoffContentviaBroadband element may include a handoffcontentURL parameter for specifying a URL address on the Internet.

Accordingly, the ATSC 3.0 receiver may access the Internet address corresponding to the handoffcontentURL to receive the additional content, and then play the additional content received in the service discontinuity section due to the service handoff and provide it to the user. In general, the HTTP protocol can be applied to file download using the Internet, and additional content can be provided in the form of streaming.

In addition, although not shown in FIG. 11, the user terminal executes additional content in a service discontinuity section due to a service handoff performed as a broadcast area is moved.

In this case, the additional content may be provided to the user terminal before service handoff is performed, and may be executed based on a decoder in the user terminal when the service handoff is performed.

For example, referring to FIG. 4, content A 410 may mean a service section currently being received by a user terminal, and content A` 411 can mean a service section to be linked by a handoff service. have. In this case, a section corresponding to the additional content 420 in FIG. 4 may mean a playback section of the additional content provided in the user terminal in advance through a broadcasting network, a communication network, or other method.

That is, there is a service discontinuity section corresponding to the service handoff section between the content A 410 and the content A` 411, and in this service discontinuity section, the additional content 420 previously stored in the user terminal is By doing so, more useful information can be provided to the user watching the user terminal.

At this time, as shown in FIG. 4, service discontinuous sections 421 and 422 may exist between the content A 410 and the additional content 420 or between the additional content 420 and the content A` 411, respectively, The discontinuous section may appear shorter than the length of the service handoff section.

In this case, the user terminal may correspond to an ATSC 3.0 receiving module supporting service handoff.

In this case, the user terminal may construct a database for service handoff by receiving signaling information in advance based on the ATSC 3.0 transmission system.

In this case, the database may include frequency information corresponding to an adjacent RF region within a preset distance from the user terminal.

At this time, the service handoff is performed based on the searched linkable service by tuning adjacent RF regions within a preset distance based on the database when the service reception state monitored by the user terminal falls below a preset reference state. Can be.

For example, referring to FIG. 6, the ATSC 3.0 receiver 600 according to an embodiment of the present invention includes tuner modules 610 and 611, a baseband processing unit 620, a service handoff processing unit 640, and a broadband processing unit. It can be composed of 630.

First, at least one tuner module 610 and 611 may be provided to perform a function of receiving an RF signal. At this time, since one or more tuner modules 610 and 611 are provided, there is an advantage in that it is possible to quickly tune a service to be linked during RF service handoff.

The baseband processing unit 620 may perform the same function as the ATSC 3.0 baseband module 521 described in FIG. 5.

The service handoff processing unit 640 may periodically monitor a service reception state. In this case, the error rate of the packet received together with the RF signal can be monitored, and when the error and error are higher than a preset level, a service handoff can be performed. To this end, the service handoff processing unit 640 may receive signaling information transmitted through the ATSC 3.0 broadcasting network in advance, and establish linkage information for service handoff, that is, a database.

In addition, the service handoff processing unit 640 may receive and store the additional content through a broadcasting network or a broadband network (communication network) in advance in order to provide the additional content to be presented in the present invention. After that, the stored additional content can be played immediately during service handoff.

To describe the procedure of the service handoff processing unit 640 in detail, a database for service handoff may be constructed by first receiving signaling information.

After that, you can monitor the status of the service that is always being received. If the reception state of a service is not good, a service handoff can be determined, and when a service handoff is determined, a linkable service can be searched by tuning an adjacent RF region through a database in advance.

At this time, after checking a signal using frequency information provided in the database, a service that can be linked can be found by tuning an RF band that is a good signal within a predetermined range. If a service to be linked to is not found in an adjacent RF area, the service can be linked through a communication network by accessing a designated Internet address.

At this time, if the service is linked to the RF area based on the broadcasting network, the service handoff can be determined in consideration of the state of the RF signal at the moment, but if the service handoff is made to the broadband based on the communication network, the previous RF band or adjacent Service handoff can be determined by periodically monitoring the signal of the RF band.

In addition, when a service with a good signal is identified in an adjacent RF area while receiving a service by performing a service handoff to a communication network, the service may be returned to the RF area and the corresponding service may be continuously provided.

The memory 1130 stores frequency information corresponding to an adjacent RF region within a preset distance from the user terminal.

In addition, the memory 1130 may support a function for providing additional content according to an embodiment of the present invention as described above. In this case, the memory 1130 may operate as a separate mass storage, and may include a control function for performing the operation.

Meanwhile, the service handoff supplementary content server is equipped with a memory to store information in the device. In one implementation, the memory is a computer-readable medium. In one implementation, the memory may be a volatile memory unit, and in another implementation, the memory may be a non-volatile memory unit. In one implementation, the storage device is a computer-readable medium. In various different implementations, the storage device may include, for example, a hard disk device, an optical disk device, or some other mass storage device.

In the process of executing the service handoff using such a service handoff supplementary content server, the video cannot be displayed on the screen because the signal is not good or the sound of the sound source is broken. It can reduce discomfort.

In addition, a service in a form that is beneficial to viewers may be provided based on additional content previously stored or downloaded in a service discontinuity section caused by a service handoff.

As described above, the method and apparatus for providing service handoff additional content in terrestrial UHD broadcasting according to the present invention are not limited to the configuration and method of the embodiments described as described above, but the embodiments are various All or part of each of the embodiments may be selectively combined and configured to be modified.

100: viewers 110, 230, 512: communication network
120: broadcasting area A 130: broadcasting area B
140: Broadcasting area C 201: Content that was served
202, 420: additional content 210, 510: service handoff additional content server
220, 511: broadcasting network 410: content A
411: Content A` 421, 422: Service discontinuous section
520, 600, 700: ATSC 3.0 receiver
710: root sander 910: SLT
920: service signaling 1110: communication unit
1120: processor 1130: memory

Claims (1)

Providing, by a service handoff additional content server, additional content to a user terminal using a mobile broadcasting service based on at least one of a broadcasting network and a communication network based on an ATSC 3.0 transmission system; And
The user terminal executing the additional content in a service discontinuity section due to a service handoff performed as the broadcast area moves
Service handoff additional content providing method comprising a.

Images