KR101672290B1 - Method for providing a service and mobile broadcast receiver - Google Patents

Abstract

The present invention relates to a non-real-time service providing method and a mobile broadcast receiver, and more particularly, to a non-real-time service providing method, And is received and included in one ensemble; Constructing and displaying a service guide using first signaling information obtained from the ensemble; Obtaining first content identification information for the selected content in the displayed service guide; Accessing a FLUTE session using second signaling information obtained from the ensemble and obtaining second content identification information matching the first content identification information from the connected flute session; And receiving and storing at least one or more files constituting the content based on the acquired second content identification information.
According to the present invention, the transmission end may include signaling data for properly recognizing, receiving, and processing the NRT service provided by the receiver, and may properly process the received NRT service using the transmitted signaling data And provide the service guide to the user using the transmitted signaling data. The receiver can correctly receive and process the content selected from the configured service guide using the signaling information .

Description

[0001] The present invention relates to a service providing method and a mobile broadcast receiver,

The present invention relates to a service providing method and a mobile broadcast receiver, and more particularly, to a service providing method and service for a service transmitted through a non-real time (NRT) A method of signaling for detailed information on an NRT receiver and an operation of an NRT receiver for receiving and processing the information.

NRT service (Non Real Time service) is one of the potential applications to be utilized in the future DTV service. NRT is not literally real-time streaming, but transmits non-real-time transmission, storage and viewing operations, and transmits file-type content over extra bandwidth through terrestrial broadcast media. And the like.

It is an object of the present invention to define signaling data for an NRT service.

It is another object of the present invention to define a method for transmitting the defined signaling data.

It is still another object of the present invention to provide an NRT service access method for receiving signaling data for the NRT service transmitted from a receiver.

It is still another object of the present invention to provide a method for mapping a content identifier of the signaling data and an identifier of a content to which a selected content is transmitted in a receiver.

It is still another object of the present invention to provide a method of receiving a content selected from a service guide configured by using signaling data at a receiver and providing the received content to a user.

An example of a method for providing a non-real-time service according to the present invention includes: receiving a file constituting a non-real-time service, first signaling information and second signaling information in an IP packetized form and being included in one ensemble; Constructing and displaying a service guide using first signaling information obtained from the ensemble; Obtaining first content identification information for the selected content in the displayed service guide; Accessing a FLUTE session using second signaling information obtained from the ensemble and obtaining second content identification information matching the first content identification information from the connected flute session; And receiving and storing at least one or more files constituting the content based on the acquired second content identification information.

Receiving TPC data including Fast Information Channel (FIC) data including cross-layer information for NRT service acquisition and FIC version information capable of identifying an update of the FIC; .

The FIC data may include the ensemble identifier and the transport stream identifier.

Also, the second signaling information may be encapsulated in a UDP / IP header having a predetermined IP address and a UDP port number.

And a slot corresponding to the ensemble can be received in a time slicing manner.

Also, the first signaling information may be an OMA-BCAST service guide, and the second signaling information may be a service map table (SMT).

The acquired first content identification information may be globalContentID for the content or may include content identification information separately defined with respect to the non-real-time service.

The obtained first content identification information may be mapped based on the obtained second content identification information, and the second content identification information may be 16 bits of binary type.

The transport stream identifier in the received FIC and the service identifier information in the received second signaling information may be combined into a specific type, and the service identifier information may be mapped based on the service identifier information in the first signaling information.

An example of a mobile broadcast receiver according to the present invention is a mobile broadcast receiver comprising: a baseband processor unit for receiving a file constituting a non-real-time service, an ensemble including first signaling information and second signaling information including IP packetization; A first handler for acquiring first signaling information from the received ensemble, and constructing and displaying a service guide using the acquired first signaling information; A second handler for obtaining first content identification information for the selected content in the displayed service guide; Obtaining second signaling information from the ensemble, accessing a FLUTE session using the obtained second signaling information, acquiring second content identification information matching the first content identification information from the connected flute session A third handler; A control unit for controlling to receive at least one or more files constituting the content based on the acquired second content identification information; And a storage unit for storing the received at least one or more files.

At this time, it is possible to receive transmission parameter channel (TPC) data including FIC information including cross-layer information for NRT service acquisition and FIC version information capable of identifying an update of the FIC.

The FIC data may include the ensemble identifier and the transport stream identifier.

Also, the second signaling information may be encapsulated in a UDP / IP header having a predetermined IP address and a UDP port number.

And a slot corresponding to the ensemble can be received in a time slicing manner.

Also, the first signaling information may be an OMA-BCAST service guide, and the second signaling information may be a service map table (SMT).

The acquired first content identification information may be globalContentID for the content or may include content identification information separately defined with respect to the non-real-time service.

The obtained first content identification information may be mapped based on the obtained second content identification information, and the second content identification information may be 16 bits of binary type.

The transport stream identifier in the received FIC and the service identifier information in the received second signaling information may be combined into a specific type, and the service identifier information may be mapped based on the service identifier information in the first signaling information.

According to the present invention,

First, the transmission terminal has an effect of including signaling data so as to appropriately recognize, receive, and process the NRT service provided by the receiver.

Second, the receiver has an effect of appropriately receiving and processing the received NRT service using the signaling data to be transmitted to the user.

Thirdly, the receiver has the effect of constructing and providing a service guide to the user by using the signaling data transmitted.

Fourth, the receiver has the effect of correctly receiving and processing the content selected from the configured service guide using the signaling information.

1 is a conceptual diagram of an NRT service,
2 is a block diagram of a receiving system according to an embodiment of the present invention,
FIG. 3 is a view for explaining a relationship between an NRT service, a content item and a file,
FIG. 4 illustrates a protocol stack for a mobile NRT service configured according to an embodiment of the present invention,
FIG. 5 is a diagram illustrating a structure of a data group according to an embodiment of the present invention,
FIG. 6 illustrates a structure of an RS frame including a mobile NRT service configured according to an embodiment of the present invention,
7 is a diagram illustrating an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention,
FIG. 8 shows an example of a VSB frame structure,
9 is a diagram illustrating a data transmission structure in a physical layer according to an embodiment of the present invention,
FIG. 10 is a diagram illustrating a hierarchical signaling structure according to an embodiment of the present invention,
11 and 12 illustrate a bitstream syntax of an SMT constructed in accordance with an embodiment of the present invention,
13 is a diagram illustrating a structure of a service guide (SG) according to an embodiment of the present invention,
FIG. 14 illustrates a bitstream syntax of an NRT component descriptor constructed according to an embodiment of the present invention,
FIG. 15 illustrates a bitstream syntax of NRT_component_data when the component type value is 38 in the NRT component descriptor of FIG. 14,
16 is a diagram for explaining the relationship between an M / H service, a FLUTE session and an NRT service according to the present invention,
FIG. 17 is a view for explaining an FDT schema for mapping a file and a content_id according to an embodiment of the present invention,
18 is a diagram for explaining an FDT scheme for mapping a file and a content_id according to another embodiment of the present invention,
FIG. 19 illustrates an example of a configuration block diagram of a receiver used for mapping signaling information configured according to an embodiment of the present invention,
FIG. 20 is a view for explaining a process of converting SMT data and OMA-BCAST SG data to perform mapping in accordance with an embodiment of the present invention,
21 is a diagram illustrating an XML schema of an OMA BCAST SG broadcast service delivery for providing access information through an NRT service according to an embodiment of the present invention.
22 is a diagram for explaining a method of converting the service_id,
23 is a flowchart illustrating a method of providing an NRT service according to an embodiment of the present invention, and Fig.
24 is a flowchart illustrating a method of providing an NRT service according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of the present invention will be described with reference to the accompanying drawings. At this time, the configuration and operation of the present invention shown in the drawings and described in the drawings are explained as at least one embodiment, and the technical idea of the present invention and its core configuration and operation are not limited thereby.

Definitions of terms used in the present invention

The terms used in the present invention are selected from general terms that are widely used in the present invention while considering the functions of the present invention. However, the terms may vary depending on the intention or custom of the artisan or the emergence of new technology. Also, in certain cases, there may be a term selected arbitrarily by the applicant, in which case the meaning thereof will be described in detail in the description of the corresponding invention. Therefore, it is to be understood that the term used in the present invention should be defined based on the meaning of the term rather than on the name of the term, and on the content of the present invention throughout the present invention.

Among the terms used in the present invention, main service data may include audio / video (A / V) data as data that can be received by a fixed receiving system. That is, the main service data may include HD (High Definition) or SD (Standard Definition) A / V data, and various data for data broadcasting may be included. The known data is previously known data by the promise of the transmitting / receiving side.

Among the terms used in the present invention, M / H (or MH) is the first letter of each of a mobile and a handheld, and is a concept opposite to a fixed type. The M / H service data includes at least one of mobile service data and hand-held service data. For convenience of explanation, the M / H service data is also referred to as mobile service data. That is, in the present invention, MH, M / H, and mobile are used in the same sense. At this time, the mobile service data may include not only M / H service data, but also service data indicating movement or carrying, so that the mobile service data will not be limited to the M / H service data.

The mobile service data defined above may be data having information such as a program executable file, stock information, etc., or A / V data. In particular, the mobile service data may be service data for a portable or mobile terminal (or broadcast receiver), and may be A / V data having a smaller resolution and a smaller data rate than the main service data. For example, if the A / V codec used for the existing main service is the MPEG-2 codec, MPEG-4 Advanced Video Coding (AVC) , Scalable Video Coding (SVC), or the like may be used. In addition, any kind of data can be transmitted with the mobile service data. For example, Transport Protocol Expert Group (TPEG) data for broadcasting traffic information in real time may be transmitted as mobile service data, and in connection with the present invention, NRT service may be transmitted as mobile service data.

The data service using the mobile service data includes a weather service, a traffic service, a securities service, a viewer participation quiz program, a real-time opinion survey, an interactive education broadcast, a game service, a story of a drama, Provide information on the program by service, media, time, or topic that provides information service for sports, history of sports, profiles and grades of players, product information, and ordering Service, and the like, and the present invention is not limited thereto.

The transmission system of the present invention is capable of multiplexing and transmitting the main service data and the mobile service data including the NRT service to the same or another physical channel without any influence on receiving the main service data in the existing receiving system do.

The transmission system of the present invention performs additional encoding on the mobile service data, and inserts known data, that is, known data, into both the transmitting and receiving sides.

With the transmission system according to the present invention, it is possible to receive and receive mobile service data including the NRT service in the receiving system, and to receive stable reception of mobile service data even with various distortions and noise generated in the channel It is possible.

NRT service concept map

1 is a conceptual diagram of an NRT service.

The broadcasting station transmits RT (Real Time) service according to the existing method. At this time, the broadcasting station may transmit the RT service and use the remaining bandwidth in the process or provide NRT (Non Real Time) service using the dedicated bandwidth. Here, the NRT service may include news clips, weather information, advertisements, content for push VOD (Video On Demand), and the like.

However, in principle, the conventional DTV receiver, that is, a legacy device, is not influenced by the NRT stream included in the channel. Therefore, the conventional DTV receiver has a problem in receiving and properly processing the NRT service provided by the broadcasting station.

On the other hand, the broadcast receiver according to the present invention, that is, the NRT device, can properly receive and process the NRT service combined with the RT service, thereby providing the viewer with various functions as compared with the conventional DTV receiver.

Here, the RT service and the NRT service are transmitted through the same or different DTV channels, and are transmitted through IP datagrams. Therefore, the receiver needs to distinguish between the two services transmitted over the same channel. For this purpose, the present invention describes defining and providing signaling information so that a receiver can receive an NRT service and properly process it.

Receiving system

2 is a block diagram illustrating a configuration of a reception system according to an embodiment of the present invention.

2 includes an operation controller 100 for controlling the entire system, a tuner 111, a demodulator 112, an equalizer 113, a known data detector 114, a block decoder 115, a primary RS A frame decoder 116, a secondary RS frame decoder 117, a signaling decoder 118 and a baseband controller 119. The receiving system may further include an FIC handler 121, a service manager 122, a service signaling handler 123 and a first storage unit 124. The receiving system may further include a primary RS frame buffer 131, a secondary RS frame buffer 132, and a transport packet (TP) handler 133. The receiving system includes an IP (Internet Protocol) datagram handler 141, a descrambler 142, a UDP (User Datagram Protocol) datagram handler 143, an RTP / time Transport Control Protocol (NTP) datagram handler 144, an NTP (Network Time Protocol) datagram handler 145, a service protection stream handler 146, a second storage unit 147, an ALC / LCT A decompressor 149, an Extensible Mark-up Language (XML) parser 150, and an FDT handler 151. The Layered Coding / Layered Coding Transport The receiving system may further include an A / V decoder 161, a file decoder 162, a third storage unit 163, a middleware engine 164, and an SG handler 165. The receiving system may further include an EPG manager 171, an application manager 172, and a user interface (UI) manager 173.

Hereinafter, for the sake of convenience of explanation, a tuner 111, a demodulator 112, an equalizer 113, a known data detector 114, a block decoder 115, a primary RS frame decoder 116, a secondary RS The baseband processor 110 includes a frame decoder 117, a signaling decoder 118 and a baseband controller 119. The FIC handler 121, the service manager 122, the service signaling handler 123, 1 storage unit 124 and is referred to as a service demultiplexer 120. [ An IP adaptation module 130 including the primary RS frame buffer 131, the secondary RS frame buffer 132 and the transport packet handler 133 is also referred to as an IP datagram handler 141 and a descrambler 142, a UDP datagram handler 143, an RTP / RTCP datagram handler 144, an NTP datagram handler 145, a service protection stream handler 146, a second storage 147, an ALC / LCT stream handler 148, a decompressor 149 and an FDT handler 151 to be referred to as a common IP module 140. The application module 160 includes the A / V decoder 161, the file decoder 162, the third storage unit 163, the middleware engine 164, and the SG handler 165.

Although the term used in FIG. 2 is a general term that is widely used at present, it has been arbitrarily used by the applicant in the present invention in accordance with the emergence of a new technology. . Therefore, it should be understood that the present invention should be grasped as a meaning of a term that is not a name of a simple term in understanding the present invention.

In FIG. 2, the operation controller 100 controls the operation of each block of the baseband processor 110.

The tuner 111 tunes the receiving system to a specific physical channel (or a physical transmission channel, PTC) frequency, and transmits the main service data, which is a broadcast signal for the fixed broadcast receiving apparatus, And receives mobile service data. The tuner 111 down-converts the frequency of the tuned specific channel into an IF (Intermediate Frequency) signal and outputs it to the demodulator 112 and the known data detector 114. The passband digital IF signal output from the tuner 111 may include only main service data, only mobile service data, or both main service data and mobile service data.

The demodulator 112 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the passband inputted from the tuner 111, converts the digital IF signal into a baseband signal, and outputs it to the equalizer 113 and the known data detector 114 . The demodulator 112 can improve demodulation performance by using a known data symbol sequence received from the known data detector 114 during timing recovery or carrier recovery.

The equalizer 113 compensates for the distortion on the channel included in the demodulated signal from the demodulator 112, and outputs the compensated signal to the block decoder 115. The equalizer 113 can improve the equalization performance by using the known data symbol sequence received from the known data detector 114. Also, the equalizer 113 may feedback the decoding result of the block decoder 115 to improve the equalization performance.

The known data detector 114 detects the known data positions inserted at the transmitting side from the input / output data of the demodulator 112, that is, the data before the demodulation or the data including the demodulated data, And outputs the sequence of known known data to the demodulator 112, the equalizer 113, and the operation controller 100. Also, the known data detector 114 outputs information for enabling the block decoder 115 to distinguish the mobile service data that has been further encoded in the transmitting side and the main service data that has not undergone the additional coding, to the block decoder 115 do.

The block decoder 115 demultiplexes the data that is input after the channel equalization in the equalizer 113 into data in which both the block encoding and the trellis encoding of the serial concatenated convolutional code (SCCC) Data and signaling data), it performs trellis decoding and block decoding inversely to the transmitting side. If the data is only Trellis-encoded (i.e., main service data) without performing block encoding, only Trellis decoding is performed do.

The signaling decoder 118 performs decoding of the signaling data that is input after being equalized by the equalizer 113. It is assumed that the signaling data (or signaling information) input to the signaling decoder 118 is data in which both block encoding and trellis encoding are performed in the transmission system. Examples of such signaling data include transmission parameter channel (TPC) data and fast information channel (FIC) data. For example, the signaling decoder 118 performs the recursive turbo decoding of the data of the signaling information area of the input data in parallel concatenated convolutional code (PCCC), then outputs the FIC data and the TPC Separate the data. In addition, the signaling decoder 118 performs RS decoding on the separated TPC data in reverse to the transmitting side, and outputs it to the operation controller 100. Then, the signaling decoder 118 deinterleaves the separated FIC data in units of subframes, performs RS decoding inverse to the transmitting side, and outputs it to the FIC handler 121. The transmission unit of the FIC data deinterleaved and RS-decoded by the signaling decoder 118 and output to the FIC handler 121 is an FIC segment.

The FIC handler 121 receives the FIC data from the signaling decoder 118 and extracts signaling information for service acquisition, that is, mapping information between the ensemble and the mobile service. To this end, the FIC handler 121 may include an FIC segment buffer, an FIC segment parser, and a FIC chunk parser.

The FIC segment buffer buffers the FIC segment group in units of M / H frames input from the signaling decoder 118, and outputs the buffered FIC segment group to the FIC segment parser. The FIC segment parser extracts and analyzes the header of each FIC segment stored in the FIC segment buffer, and outputs the payload of the corresponding FIC segment to the FIC chunk parser according to the analysis result. The FIC chunk parser reconstructs and analyzes the FIC chunk data structure from the FIC segment payloads using the results analyzed in the FIC segment parser to extract signaling information for service acquisition. The signaling information obtained from the FIC chunk parser is output to the service manager 122.

The service signaling handler 123 includes a service signaling buffer and a service signaling parser. The service signaling handler 123 buffers table sections of the service signaling channel, for example, SMT sections, transmitted from the UDP datagram handler 143 Analyze and process. The SMT information processed by the service signaling handler 123 is also output to the service manager 122.

The SMT section or the service signaling channel for transmitting the SMT section is received in a corresponding RS frame in the form of a UDP / IP packet having a well-known IP desination address and a well-known destination UDP port number . Thus, the receiving system can process the SMT section and the descriptors of each SMT section without requiring any additional information.

The SMT section also provides signaling information (including IP connection information) for all services in the ensemble including the SMT section. Therefore, an IP stream component belonging to a service desired to be received can be accessed using the information processed from the SMT, and the corresponding service can be provided to the user.

The information processed from the SMT is collected by the service manager 122 and stored in the first storage unit 124. The service manager 122 stores the information extracted from the SMT in the first storage unit 124 in the form of a service map.

The service manager 122 configures the service map using the signaling information collected from the FIC handler 121 and the service signaling handler 123 and transmits the service guide SG collected from the service guide To create a program guide. Referring to the service map and the created service guide, the operation controller 100 is controlled to receive the mobile service desired by the user, and the program guide is displayed on at least a part of the screen according to the input of the user .

The operation controller 100 stores a service map and a service guide created in the service manager 122. The operation controller 100 extracts necessary data according to a request from the service manager 122 and the EPG manager 171 and delivers the extracted data to the service manager 122 and / or the EPG manager 171.

The operation controller 100 receives M / H frame time information, existence of a data group of a selected parade, location information of known data in a data group, power control information, and the like, by receiving base data location information and TPC data, To each block of the processor 110. A detailed description of the TPC data will be given later.

Meanwhile, according to the present invention, the transmission system uses the RS frame concept as an encoding unit. The RS frame is divided into a primary RS frame and a secondary RS frame. In the present invention, the division between the primary RS frame and the secondary RS frame is performed according to the importance of data.

The primary RS frame decoder 116 receives the output of the block decoder 115 as an input. In this case, the primary RS frame decoder 116 receives the Reed Solomon (RS) and / or CRC (Cyclic Redundancy Check) encoded mobile service data or NRT service data from the block decoder 115 do. The primary RS frame decoder 116 may receive Reed Solomon (RS) and / or CRC (Cyclic Redundancy Check) encoded SMT section data or OMA BCAST SG data from the block decoder 115.

That is, the primary RS frame decoder 116 receives at least one of data other than the main service data, for example, mobile service data, NRT service data, SMT section data, and OMA BCAST SG data. The primary RS frame decoder 116 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the primary RS frame. That is, the primary RS frame decoder 116 collects a plurality of data groups to form a primary RS frame, and then performs error correction on a primary RS frame basis. In other words, the primary RS frame decoder 116 decodes the primary RS frame transmitted for an actual broadcast service or the like. The primary RS frame decoded by the primary RS frame decoder 116 is output to the primary RS frame buffer 131. The primary RS frame buffer 131 buffers the primary RS frame and constructs an M / H TP for each row to output to the TP handler 133.

The secondary RS frame decoder 117 receives the output of the block decoder 115 as an input. In this case, the secondary RS frame decoder 117 also receives RS (Reed Solomon) encoding and / or CRC (Cyclic Redundancy Check) encoded mobile service data or NRT service data from the block decoder 115 as an example. The secondary RS frame decoder 117 may receive Reed Solomon (RS) and / or CRC (Cyclic Redundancy Check) encoded SMT section data or OMA BCAST SG data from the block decoder 115.

That is, the secondary RS frame decoder 117 receives at least one of data other than the main service data, for example, mobile service data, NRT service data, SMT section data, and OMA BCAST SG data. The secondary RS frame decoder 117 performs an inverse process of the RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 117 collects a plurality of data groups to form a secondary RS frame, and then performs error correction on a secondary RS frame basis. In other words, the secondary RS frame decoder 117 decodes secondary RS frames transmitted for mobile audio service data, mobile video service data, guide data, and the like. The data of the secondary RS frame decoded by the secondary RS frame decoder 117 is output to the secondary RS frame buffer 132. The secondary RS frame buffer 132 buffers the secondary RS frame and configures an M / H TP on a row-by-row basis and outputs the M / H TP to the TP handler 133.

The TP handler 133 is composed of a TP buffer and a TP parser. The TP handler 133 buffers the M / H TPs received from the primary and secondary RS frame buffers 131 and 132, extracts each header of the buffered M / And restores the IP datagram from the payload of the corresponding M / H TP. The restored IP datagram is output to the IP datagram handler 141.

The IP datagram handler 141 comprises an IP datagram buffer and an IP datagram parser. The IP datagram handler 141 buffers the IP datagram received from the TP handler 133, extracts and analyzes the header of the buffered IP datagram And restores the UDP datagram from the payload of the IP datagram. The restored UDP datagram is output to the UDP datagram handler 143.

If the UDP datagram is scrambled, the scrambled IP datagram is descrambled by the descrambler 142 and output to the UDP datagram handler 143. For example, when scrambling is applied to a UDP datagram among the received IP datagrams, the descrambler 142 receives an encryption key from the service protection stream handler 146, And outputs the scrambled data to the UDP datagram handler 143.

The UDP datagram handler 143 comprises a UDP datagram buffer and a UDP datagram parser. The UDP datagram handler 143 buffers a UDP datagram input from the IP datagram handler 141 or the descrambler 142, Extracts and analyzes the header of the datagram and restores the data transmitted to the payload of the corresponding UDP datagram. If the restored data is an RTP / RTCP datagram, the RTP / RTCP datagram handler 144 outputs the restored data. If the restored data is an NTP datagram, the NTP datagram is output to the NTP handler 145. Or outputs the restored data to the service protection stream handler 146 if it is a service protection stream and to the ALC / LCT stream handler 148 if it is an ALC / LCT stream. And outputs the restored data to the service signaling section handler 123 if the restored data is SMT section data.

Since the SMT section or the service signaling channel for transmitting the SMT section is an IP datagram having a well-known IP desination address and a well-known des- pination UDP port number, the IP datagram handler 141 and the UDP datagram handler 143 May output the data including the SMT section to the service signaling section handler 123 without requiring any additional information.

The RTP / RTCP datagram handler 144 comprises an RTP / RTCP datagram buffer and an RTP / RTCP datagram parser. The RTP / RTCP datagram handler 144 buffers data of the RTP / RTCP structure output from the UDP datagram handler 143, Extracts the audio / video stream from the buffered data. The extracted audio / video stream is output to an audio / video (A / V) decoder 161. The A / V decoder 161 decodes the audio stream and the video stream output from the RTP / RTCP datagram handler 144 using a decoding algorithm, and outputs the decoded audio stream and the video stream to the presentation manager 170. For example, the audio decoding algorithm may be an audio decoding algorithm such as an AC-3 decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audio decoding algorithm, an AAC decoding algorithm, an AAC + decoding algorithm, a HE AAC decoding algorithm, an AAC SBR decoding algorithm, And the video decoding algorithm may apply at least one of an MPEG 2 video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264 decoding algorithm, an SVC decoding algorithm, and a VC-1 decoding algorithm.

The NTP datagram handler 145 comprises an NTP datagram buffer and an NTP datagram parser. The NTP datagram handler 145 buffers data of the NTP structure output from the UDP datagram handler 143 and extracts an NTP stream from the buffered data. do. The extracted NTP stream is output to the A / V decoder 161 and decoded.

The service protection stream handler 146 may further include a service protection stream buffer. The service protection stream handler 146 buffers data for service protection output from the UDP datagram handler 143, and then generates descrambling information . The information for descrambling includes a key value for descrambling such as SKTM, LKTM, and the like. The information for descrambling is stored in the second storage unit 147 and is output to the descrambler 142 if necessary.

The ALC / LCT stream handler 148 comprises an ALC / LCT stream buffer and an ALC / LCT stream parser. The ALC / LCT stream handler 148 buffers data of the ALC / LCT structure output from the UDP datagram handler 143, And analyzes the header and header extension of the ALC / LCT session. As a result of analyzing the header and header extension of the ALC / LCT session, the header and header extension of the ALC / LCT session can be output to the FDT handler 151, the SG handler 165 or the file decoder 162 according to the type of data transmitted in the ALC / LCT session .

At this time, if the data transmitted in the ALC / LCT session is compressed, the compressed data is released from the decompressor 149 and output to the file decoder 162.

The FDT handler 151 analyzes and processes a file description table of a FLUTE protocol transmitted in an XML structure through an ALC / LCT session.

The SG handler 165 collects and analyzes data for a service guide transmitted in an XML structure, and outputs the collected data to the service manager 122.

The file decoder 162 decodes the file structure data transmitted through the ALC / LCT session and outputs the decoded data to the middleware engine 164 or the third storage unit 163. [

The middleware engine 164 interprets and executes the data of the file structure, that is, the application. The application may be output to an output device such as a screen or a speaker through the presentation manager 170. The middleware engine 164 is a Java (JAVA) based middleware engine. Here, the middleware engine 164 controls the process of receiving the NRT content item and its associated files. For example, the middleware engine 164 may control the FDT handler 151, the SG handler 165, and the EPG manager 171.

The EPG manager 171 receives the EPG data from the service manager 122 or the SG handler 165 according to an input from the user, converts the EPG data into a display format, and outputs the display format to the presentation manager 170.

The application manager 172 performs overall management of processing of application data transmitted in the form of an object, a file, or the like.

The operation controller 100 controls at least one of the service manager 122, the EPG manager 171, the application manager 172 and the presentation manager 170 according to a command of a user input through the UI manager 173. [ So that the function according to the command of the user is performed.

The UI manager 173 transfers the user's input to the operation controller 100 through the UI.

The presentation manager 170 transmits at least one of audio and video data output from the A / V decoder 161, file data output from the middleware engine 164, and EPG data output from the EPG manager 171, / Or provide it to the user via the screen.

In the present invention, an NRT service may be included in a mobile broadcast service, and an SMT section for signaling an NRT service included in the mobile broadcast service is extracted from, for example, a primary RS frame decoder 116. Here, the SMT section may be extracted from the secondary RS frame decoder 117. And then processed in the IP module via the extracted IP adaptation module. That is, the IP datagram handler 141 processes the IP datagram including the SMT section, and the extracted SMT section is processed in the service signaling section handler 123 after processing the UDP datagram. In addition, the FDT data and the NRT service data other than the SMT section data may be processed by the mobile broadcast receiver through the ALC / LCT processing unit to provide the NRT service.

Describe the relationship between NRT services, content items, and files

FIG. 3 is a view for explaining the relationship between the NRT service, the content item and the file.

Referring to FIG. 3, one NRT service may include one or more content items, and each content item may comprise at least one or more file (s). Also, the content item may correspond to a program or an event in a real-time broadcast as an independently reproducible entity. Therefore, the NRT service refers to a group that can be served by a combination of the above-described content items, and corresponds to a channel concept in real time.

In this regard, in the mobile service environment, the receiver has insufficient signaling information for the received mobile NRT service data, so that even if the mobile NRT service is received, it is difficult to properly process the received mobile NRT service.

SUMMARY OF THE INVENTION Accordingly, the present invention has been made to solve the above-mentioned problems, and it is an object of the present invention to provide a processing method using signaling information for defining mobile signaling service data received from a receiver. However, a more detailed description thereof will be described later in this section, and a brief description will be given here.

In the following description, an SMT (Service Map Table) and an OMA BCAST SG (Service Guide) are used for signaling for a mobile NRT service.

First, the receiver can identify whether the mobile service is a mobile NRT service, for example, by referring to the service_category field in the SMT. And one or more content item (s) in the mobile NRT service can be identified using the content identifier information in the OMA BCAST SG and the content_id field in the FDT. In addition, the mobile NRT service can be identified using, for example, NRT_service_id in the SMT and service identifier information in the OMA BCAST SG.

However, since the signaling information is defined in different formats, the present invention provides a mapping method for identifier information of different formats for processing the signaling information. Thus, the receiver can appropriately process the received NRT service.

In this regard, the mobile NRT service is transmitted over a FLUTE session and extracts FDT information from the FLUTE session. The content_id in the extracted FDT information may be received by checking the NRT service content selected by the user by mapping the content identifier of the OMA-BCAST SG. For example, each file constituting the content item is identified using the TOI and Content-Location fields specified in the FDT in the FLUTE session, and each TOI or Content-Location and content The connection of the items can be achieved by mapping the content_ID field in the FDT to the content identifier field of the OMA BCAST SG. However, only the concept of the present invention has been described and will be described in detail later.

Protocol for Mobile NRT Service

The NRT service can be classified into a fixed NRT service (Fixed NRT service) and a mobile NRT service (Mobile NRT service). Hereinafter, the mobile NRT service will be described as an example for convenience of explanation.

FIG. 4 illustrates a protocol stack for a mobile NRT service configured according to an embodiment of the present invention. Referring to FIG.

FIG. 4 illustrates an exemplary embodiment of the present invention. Referring to FIG. 4, an adaptation layer may be included between the IP layer and the physical layer to transmit an IP datagram including signaling information without using the MPEG-2 TS format.

In FIG. 4, the NRT service for mobile service is packetized according to a UDP (User Datagram Protocol) scheme in the IP layer, and the UDP packet is packetized according to the IP scheme to become UDP / IP packet data. The packetized UDP / IP packet data is referred to as an IP datagram in this specification for convenience of description. Also, the signaling information channel including the SMT is packetized according to a UDP (User Datagram Protocol) scheme, and the UDP packet is packetized according to the IP scheme to become UDP / IP packet data.

In FIG. 4, the OMA-BCAST Service Guide (SG) and NRT content items / files are packetized according to the FLUTE scheme, and packetized according to the ALC / LCT (Asynchronous Layered Coding / Layered Coding Transport) do. The ALC / LCT packet is again packetized according to the UDP scheme, and the ALC / LCT / UDP packet is again packetized according to the IP scheme to become ALC / LCT / UDP / IP packet data.

In the adaptation layer, an RS frame including signaling information, an IP datagram, and identification information capable of distinguishing the signaling information from the IP datagram is generated. That is, the adaptation layer is a data link layer that distinguishes IP datagrams of mobile service data from IP datagrams of signaling information tables, and connects the separated datagrams to be processed in an upper layer. The RS frame is modulated into a predetermined transmission scheme, for example, a VSB transmission scheme in the mobile physical layer, and is transmitted to the reception system.

Data format structure

Meanwhile, the data structure used in the mobile broadcasting technology according to the embodiment of the present invention includes a data group structure and an RS frame structure. This will be described in detail as follows.

5 is a diagram illustrating a structure of a data group according to an embodiment of the present invention.

5 shows an example in which a data group is divided into 10 M / H blocks (M / H blocks B1 to B10). And each M / H block has a length of 16 segments. In FIG. 5, only the RS parity data is allocated to a part of the 5 segments preceding the M / H block B1 and the 5 segments after the M / H block B10, and is excluded from the A area to the D area of the data group.

That is, assuming that one data group is divided into A, B, C, and D regions, each M / H block is divided into any one of the A region to the D region according to the characteristics of each M / Can be included. At this time, each M / H block is included in one of the A region and the D region according to the degree of interference of the main service data.

The reason why the data group is divided into a plurality of regions is to differentiate each use. That is, a region where there is no interference of the main service data or a region where there is no interference can show robust reception performance than the region where no interference occurs. In addition, when a system for inserting known data known by the promise of a transmitting / receiving end into a data group and transmitting the data is applied, when it is desired to periodically insert consecutively long base data into mobile service data, It is possible to periodically insert a known length of known data into an area where there is no interference of data (that is, an area where main service data is not mixed). However, it is difficult to periodically insert the known data due to the interference of the main service data in the area where interference of the main service data exists, and it is also difficult to continuously insert the known data.

The M / H block B4 to the M / H block B7 in the data group of FIG. 5 show an example where long known data strings are inserted before and after each M / H block as an area free of interference of main service data. In the present invention, the A region (= B4 + B5 + B6 + B7) including the M / H block B4 to the M / H block B7 will be described. As described above, in the case of the A region having the known data sequence for each M / H block back and forth, the receiving system can perform equalization using the channel information obtained from the known data. Thus, the most robust equalization Performance can be obtained.

The M / H block B3 and the M / H block B8 in the data group of FIG. 5 are areas where interference of main service data is small, and an example in which a long known data row is inserted into only one of both M / H blocks is shown. That is, due to the interference of the main service data, the M / H block B3 inserts a long base data string only after the corresponding M / H block, and the M / H block B8 inserts a long base data string only in front of the corresponding M / H block . In the present invention, the B region (= B3 + B8) including the M / H block B3 and the M / H block B8 will be described. As described above, in the case of the B region having the known data sequence in either one of the M / H blocks, the receiving system can perform equalization using the channel information obtained from the known data, The equalization performance can be obtained.

The M / H block B2 and the M / H block B9 in the data group of FIG. 5 have more interference of the main service data than the B area, and can not insert a long known data row back and forth in both M / H blocks. In the present invention, a C region (= B2 + B9) including the M / H block B2 and the M / H block B9 will be described.

The M / H block B1 and the M / H block B10 in the data group of FIG. 5 have more interference of the main service data than the C area, and similarly, it is impossible to insert a long known data sequence back and forth in both M / H blocks. In the present invention, the D region (= B1 + B10) including the M / H block B1 and the M / H block B10 will be described. Since the C / D region is far away from the known data sequence, the reception performance may be poor if the channel changes rapidly.

Also, the data group includes a signaling information area to which signaling data (or signaling information) is allocated.

The present invention can use a part of the second segment from the first segment of the M / H block B4 in the data group as the signaling information area.

The present invention uses 276 (= 207 + 69) bytes of the M / H block B4 of each data group as a signaling information area. That is, the signaling information area is composed of 207 bytes, which is the first segment of the M / H block B4, and the first 69 bytes of the second segment. The first segment of the M / H block B4 corresponds to the 17th or 173rd segment of the VSB field.

The signaling data to be transmitted to the signaling information area can be divided into two kinds of signaling channel data. One is Transmission Parameter Channel (TPC) data, and the other is Fast Information Channel (FIC) data.

Since the TPC data mainly includes parameters used in a physical layer module and is transmitted without being interleaved, the TPC data can be accessed on a slot-by-slot basis.

The FIC data is provided to enable a fast service acquisition at a receiver, and includes cross-layer information between a physical layer and an upper layer. The FIC data is interleaved and transmitted in units of subframes.

For example, when the data group includes six known data strings as shown in FIG. 5, the signaling information area is located between the first known data string and the second known data string. That is, the first known data sequence is inserted into the last two segments of the M / H block B3 in the data group, and the second known data sequence is inserted into the second and third segments of the M / H block B4. And the third to sixth known data streams are inserted into the last two segments of the M / H blocks B4, B5, B6 and B7, respectively. The first, third, and sixth to sixth known data streams are separated by 16 segments.

RS frame (RS Frame)

FIG. 6 illustrates a structure of an RS frame including a mobile NRT service configured according to an embodiment of the present invention.

The RS frame is received in each M / H frame in a state of being switched to the time slicing mode. One RS frame includes IP streams of each mobile service data or signaling data, and SMT (service map table) section data may exist in all RS frames. The SMT section data may be in the form of an IP stream or in another form. The data of the RS frame is allocated to a corresponding area of a plurality of data groups and transmitted.

The RS frame according to an exemplary embodiment of the present invention includes at least one M / H TP (Transport Packet). This M / H TP consists of an M / H header and an M / H payload.

The M / H payload may include mobile service data as well as signaling data. That is, one M / H payload may include only mobile service data, only signaling data, or both service data and signaling data. Here, the mobile service data may include an NRT service according to the present invention.

6 shows an example in which an IP datagram for SMT (IP Datagram 1) and two kinds of IP datagrams for mobile services (i.e. IP datagram 2 and IP datagram 3) are allocated.

Data transfer structure

7 is a diagram illustrating an example of an M / H frame structure for transmitting / receiving mobile service data according to the present invention.

FIG. 7 shows an example in which one M / H frame is composed of 5 subframes, and one subframe is composed of 16 slots. In this case, one M / H frame includes 5 subframes and 80 slots.

One slot consists of 156 data packets (i.e., transport stream packets) at the packet level and 156 data segments at the symbol level. Or a half of the VSB field. That is, since one data packet of 207 bytes has the same amount of data as one data segment, a data packet before data interleaving can be used as a concept of a data segment. At this time, two VSB fields are gathered to form one VSB frame.

FIG. 8 shows an example of a VSB frame structure. One VSB frame is composed of two VSB fields (i.e., an odd field and an even field). Each VSB field is composed of one field sync segment and 312 data segments.

The slot is a basic time unit for multiplexing mobile service data and main service data. One slot may include mobile service data, or may consist of only main service data.

If the first 118 data packets in the slot correspond to one data group, the remaining 38 packets become the main service data packet. As another example, if there is no data group in one slot, the slot is made up of 156 main service data packets.

Meanwhile, the mobile service data in one RS frame may be all allocated to the A / B / C / D area in the data group or may be allocated to at least one area of the A / B / C / D area. In one embodiment, mobile service data in one RS frame is all allocated to an A / B / C / D area or allocated to only one of an A / B area and a C / D area. That is, in the latter case, the RS frame allocated to the A / B area in the data group is different from the RS frame allocated to the C / D area. According to an embodiment of the present invention, an RS frame allocated to an A / B area in a data group is referred to as a primary RS frame, and an RS frame allocated to a C / D area is referred to as a secondary RS frame frame. The primary RS frame and the secondary RS frame constitute one parade. That is, if mobile service data in one RS frame is all allocated in the A / B / C / D area in the data group, one parade transmits one RS frame. On the other hand, if the mobile service data in one RS frame is allocated to the A / B area in the data group and the mobile service data in the other RS frame is allocated to the C / D area in the corresponding data group, RS frames.

That is, the RS frame mode indicates whether one parade transmits one RS frame or two RS frames. This RS frame mode is transmitted as TPC data.

Table 1 below shows an example of the RS frame mode.

Value Application Identifier Format 0x0000 DASE application 0x0001 ATSC reserved 0x0002 ATSCA / 92 Application 0x0003 NRT Application 0x0004-0x7FFF ATSC reserved 0x8000-0xFFFF User private

In Table 1, 2 bits are allocated to indicate the RS frame mode. Referring to Table 1, if the RS frame mode value is 00, it indicates that one parade transmits one RS frame. If the RS frame mode value is 01, one parade is transmitted to two RS frames, that is, a primary RS Frame and the secondary RS frame. That is, when the RS frame mode value is 01, the data of the primary RS frame for region A / B for the A / B region is allocated and transmitted to the A / B region of the data group, And the data of the secondary RS frame (region C / D) for the region is assigned to the C / D region of the corresponding data group and is transmitted.

As with the allocation of the data groups, it is also an embodiment that the parades are allocated as far apart as possible in the subframe. This makes it possible to strongly respond to burst errors that may occur in one subframe.

And, the allocation method of parades can be applied differently for each M / H frame, and the same applies to all M / H frames. The same applies to all subframes within one M / H frame, or may be applied to each subframe differently. The present invention is applicable to all subframes within one M / H frame, which may be different for each M / H frame. That is, the M / H frame structure can be changed in units of M / H frames, which enables flexible adjustment of the ensemble data rate.

That is, in the embodiment of the present invention, an ensemble concept is introduced to define a set of services. One M / H ensemble has the same QoS and is coded with the same FEC code. Also, one ensemble has the same unique identifier (i.e., ensemble id) and corresponds to consecutive RS frames.

FIG. 9 is a diagram illustrating a data transmission structure in a physical layer according to an embodiment of the present invention. In FIG. 9, FIC data is included in each data group and transmitted.

As described above, the M / H frame for about 0.968 seconds is divided into five subframes, and data groups corresponding to a plurality of ensembles exist in each subframe. A data group corresponding to each ensemble exists Are interleaved in units of M / H frames to form an RS frame belonging to one ensemble. In Fig. 7, there are two ensembles (NoG = 4, NoG = 3). Also, a certain portion (e.g., 37 bytes / data group) of each data group is used to transmit FIC data to which encoding is applied separately from the RS frame data channel. The FIC area allocated to each data group constitutes one FIC segment, and these FIC segments are interleaved on a subframe basis. For example, RS encoding and serial concatenated convolutional code (SCCC) encoding are applied to the RS frame data, and RS encoding and parallel concatenated convolutional coding (PCCC) encoding are applied to the FIC data . On the other hand, RS encoding and parallel concatenated convolutional code (PCCC) encoding are applied to the TPC data as well as the FIC data. In this case, (187 + P, 187) -RS encoding is applied to the RS frame data, (51,37) -RS encoding is applied to the FIC data, and the TPC data is One embodiment is applied. Here, P is the number of parity bytes.

Hierarchical signaling structure

10 is a diagram illustrating a hierarchical signaling structure according to an embodiment of the present invention. The mobile broadcasting technology according to the present embodiment employs a signaling method using FIC and SMT as shown in FIG. This is referred to as a hierarchical signaling structure in the present invention.

That is, FIG. 10 shows a hierarchical signaling structure for providing data required for service acquisition through the service map table (SMT) among the FIC chunk and the mobile service signaling channel at the IP level.

As can be seen in Figure 10, the FIC chunk uses its fast nature to deliver the mapping relationship between the mobile service and the ensemble to the receiving system. That is, the FIC chunk provides signaling data to the receiving system to quickly find the ensemble that delivers the desired service in the receiving system and to quickly receive the RS frames of the ensemble.

Service Map Table (SMT)

Next, the signaling information for NRT services transmitted through the IP datagram in the RS frame of FIG. 6 will be described. Hereinafter, the SMT, which is one of the signaling information, will be described.

Figures 11 and 12 illustrate the bitstream syntax of an SMT constructed in accordance with an embodiment of the present invention.

Here, the syntax is written in the form of an MPEG-2 private section for the sake of understanding, but the format of the data may be any form. The SMT describes service information and IP connection information in an ensemble in which the SMT is transmitted, and also provides broadcast stream information of the service using Transport_Stream_ID, which is a recognizer of a broadcast stream to which each service belongs. The SMT according to the present embodiment includes description information of each mobile service in one MH ensemble, and other additional information may be included in the descriptor area.

Referring to Figs. 11 and 12, the SMT section may be included and transmitted in the form of an IP stream in the RS frame, as described above. In this case, the RS frame decoders of the receiver to be described later decode the input RS frame, and output the decoded RS frame to the corresponding RS frame handler. Each RS frame handler divides the inputted RS frame into rows and constructs the MH TP to output it to the MH TP handler.

On the other hand, examples of fields that can be transmitted through the SMT are as follows.

The table_id field (8 bits) is a field for identifying the type of the table, and it is known that the table section is a table section in SMT (table_id: An 8-bit unsigned integer number indicates that the type of table section being defined in Service Map Table (SMT)).

The section_syntax_indicator field (1 bit) is an indicator for defining the section format of the SMT. The section format may be MPEG short-form syntax (0) or the like (section_syntax_indicator: This 1-bit field shall be set to 0 to always indicate that this table is derived from the short form of the MPEG-2 private section table.

The private_indicator field (1 bit) indicates whether the SMT follows the private section (private_indicator: This 1-bit field shall be set to 1).

The section_length field (12 bits) indicates the length of the section of the remaining SMT after the corresponding field (section_length: A 12-bit field. 4093 (0xFFD)).

The table_id_extension field (16 bits) is table-dependent and is a logical part of the table_id field that provides a range of remaining fields (table_id_extension: This is a 16-bit field and is table-dependent. of the table_id field providing the scope for the remaining fields). Here, the table_id_extension field includes an SMT_protocol_version field.

The SMT_protocol_version field (8 bits) tells the protocol version to allow the NRT SMT to be transmitted by parameters whose structure differs from those defined in the current protocol (SMT_protocol_version: An 8-bit unsigned integer whose function is to allow, in The future, this NRT Service Map Table of carry parameters may be structured differently than the current protocol. At present, the value for the SMT_protocol_version shall be zero. Non-zero values of SMT_protocol_version may be used by a future version of this standard to indicate structurally different tables).

The ensemble_id field (8 bits) is an ID value associated with the corresponding MH ensemble, and values of 0x00 to 0x3F may be assigned. The value of this field is preferably derived from the parade_id of the TPC data. If the corresponding MH ensemble is transmitted via the primary RS frame, the most significant bit (MSB) is set to 0, and the remaining 7 bits are used as the parade_id value of the corresponding MH parade. On the other hand, if the corresponding MH ensemble is transmitted through the secondary RS frame, the most significant bit (MSB) is set to 1 and the remaining 7 bits are used as the parade_id value of the corresponding MH parade (ensemble_id: This 8-bit unsigned integer field in the range 0x00 to 0x3F Ensemble ID associated with this MH Ensemble. The value of this field shall be derived from the parade_id carried from the baseband processor of the MH physical layer subsystem, by the parade_id of the associated MH Parade for The least significant 7 bits, and using 0 for the most significant bit when the MH Ensemble is carried over the Primary RS frame, and using 1 for the most significant bit when the MH Ensemble is performed over the Secondary RS frame).

The version_number field (5 bits) indicates the version number of the SMT.

The current_next_indicator field (1 bit) indicates whether the transmitted SMT table section is currently applicable (current_next_indicator: A one-bit indicator, which when set to 1 indicates that the Service Map Table is currently applicable. An update to the currently available table is currently set to 0, which will not indicate that the table has not yet been applied to the table. applicable table shall be signaled by incrementing the version_number field).

The section_number field (8 bits) represents the section number in the sections in which the current table section constitutes the SMT table (section_number: This 8-bit field shall give the section number of this NRT Service Signaling table section. The NRT Service Signaling Table shall be 0x00. The section_number shall be incremented by 1 in each additional section in the NRT Service Signaling table.

The last_section_number field (8 bits) indicates the last section number constituting the SMT table (last_section_number: This 8-bit field shall give the number of the last section (ie, the section with the highest section_number) this section is a part).

The num_services field (8 bits) indicates the number of services in the SMT section. Here, if the service is an NRT service, it can indicate the number of corresponding NRT services (num_services: This 8 bit field specifies the number of services in the SMT section).

Meanwhile, the SMT according to the present embodiment provides information on a plurality of mobile services (or NRT services) using a for loop. Hereinafter, the following field information can be provided for each service.

The service_id field (16 bits) is an indicator for uniquely identifying a mobile service within the range of the MH broadcast. The service_id does not change throughout the service. Herein, if the mobile service is an NRT service, the ervice_id will identify each NRT service (service_id: A 16-bit unsigned integer number that will uniquely identify the M / H Service within the scope of the MH Broadcast. The MH_service_id of A service should not be changed for the life of the service. To avoid confusion, it is recommended that a service be terminated, then the MH_service_id for the service should be used for another service. Annex A for an allocation scheme for MH_service_id values).

The Multi_ensemble_service field (2 bits) identifies whether the mobile service is transmitted via one or more ensembles. In addition, the field identifies whether or not the mobile service is only represented as part of the mobile service transmitted via the ensemble. That is, it identifies whether the NRT service is transmitted through one or more ensembles (multi_ensemble_service: A two-bit enumerated field that will identify whether the M / H Service is carried over more than one M / H Ensemble. Table 6.8). The value of this field is defined in Table 6.8).

The MH_service_status field (2 bits) identifies the state of the mobile service. Here, the MSB indicates whether the corresponding mobile service is active (1) or inactive (0), and the LSB indicates whether the corresponding mobile service is hidden (1) or not (0). If the mobile service is an NRT service, it will identify the state of the corresponding NRT service (MH_service_status: A 2-bit enumerated field that will identify the status of this M / H Service. H Service is active (when set to 1) or inactive (when set to 0) and the least significant bit is labeled whether this M / H Service is hidden (when set to 1) are normally used for proprietary applications, and ordinary receiving devices should ignore them.

The SP_indicator field (1 bit) indicates if a service protection applied to at least one of the components necessary for providing a meaningful presentation of the mobile service is set (SP_indicator: , when set, that service is applied to at least one of the components needed to provide a meaningful presentation of this M / H Service).

The short_service_name_length field (3 bits) indicates the number of byte pairs in the short_service_name field. (short_service_name_length: A three-bit unsigned integer indicates that the number of bytes in the short_service_name field. The value of this field shall be 0).

The short_service_name field indicates the short name of the mobile service (short_service_name: The short name of the M / H Service, each character of which will be encoded in UTF-8 [29]. name, the second byte of the last byte of the byte pair specified by the short_service_name_length field shall contain 0x00).

The MH_service_category field (6 bits) identifies the type category of the service to be transmitted within the mobile service, as defined in Table 2 below. If the value of the field is set to a value indicating Informative only, then the value of that field is treated as an informative description of the category of service. The receiver is then required to check the component_level_descriptors () field of the SMT to identify the actual category of service transmitted via the MH service. For services with video and / or audio components, they have an NTP timebase component (MH_service_category: A 6-bit enumerated type field that shall identify the type of service carried in this M / H Service as defined in Table 7.3. () Of the SMT-1, which is the value of this field is set to the value, which is the Informative only, the value of this field shall be treated as an informative description of the category of service, and the receiver is required to examine the component_level_descriptors MH to identify the actual category of service carried through this M / H Service. For services that have a video and / or audio component, they should have an NTP timebase component.

Value Encapsulated Protocol 0x00 Not in a MPEG-2 Transport Stream 0x01 Asynchronous non-flow controlled scenario of DSM-CC Download protocol encapsulated in DSM-CC sections 0x02 Non-streaming Synchronized Download protocol encapsulated in DSM-CC sections 0x03 Asynchronous multiprotocol datagrams in Addressable Sections using LLC / SNAP header 0x04 Asynchronous IP datagrams in Addressable Sections 0x05 Synchronized streaming data encapsulated in PES 0x06 Synchronous streaming data encapsulated in PES 0x07 Synchronized streaming multiprotocol datagrams in PES using LLC / SNAP header 0x08 Synchronous streaming multiprotocol datagrams in PES using LLC / SNAP header 0x09 Synchronized streaming IP datagrams in PES 0x0A Synchronous streaming IP datagrams in PES 0x0B Proprietary Data Piping 0x0C SCTE DVS 051 asynchronous protocol [19] 0x0D Asynchronous carousel scenario of DSM-CC Download protocol encapsulated in DSM-CC sections 0x0E Reserved for harmonization with another standard body 0x0F-0x7F ATSC reserved 0x80-0Xff User defined

In particular, in connection with the present invention, the receiver knows that the mobile service is a mobile NRT service if the value of the MH_service_category field in the received SMT section is a value of, for example, 0x0E. Accordingly, when the value of the MH_service_category field is 0x0E, the receiver identifies that the corresponding mobile service is an NRT service, and as a result, the receiver displays the component level information including the information on the FLUTE session in which the identified NRT service is transmitted 14 component_descriptor should be checked. In checking the component_descriptor, if the value of the component_type field in the corresponding descriptor is 38, information on the FLUTE session received in the component data of FIG. 15 described later is extracted.

The num_components field (5 bits) describes the number of IP stream components in the mobile service (num_components: This 5-bit field specifies the number of IP stream components in this M / H Service).

When the IP_version_flag field (1 bit) is set to 1, the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv6 addresses, and when set to 0, the source_IP_address field, the MH_service_destination_IP_address field, and the component_destination_IP_address field are IPv4 addresses (IP_version_flag: A 1-bit indicator, which when set to 0 indicates that the source_IP_address, MH_service_destination_IP_address, and component_destination_IP_address fields are IPv4 addresses. The value of this field is reserved for possible future indication that source_IP_address, MH_service_destination_IP_address, and component_destination_IP_address fields are for IPv6. of IPv6 addressing is not currently defined).

When the source_IP_address_flag field (1 bit) is set, a flag indicating that the source IP address value for the mobile service exists to indicate the source specific multicast (source_IP_address_flag: A 1-bit Boolean flag that indicates indicate when set , that a source IP address value for this M / H Service is present to indicate a source specific multicast).

When the MH_service_destination_IP_address_flag field (1 bit) is set, it indicates that the corresponding IP stream component is transmitted via an IP datagram having a target IP address different from MH_service_destination_IP_address. Therefore, when this flag is set, the receiving system uses component_destination_IP_address as the destination_IP_address and ignores the MH_service_destination_IP_address field in the num_channels loop to access the corresponding IP stream component (MH_service_destination_IP_address_flag: A 1-bit Boolean flag indicating that when set to 1, that a MH_service_destination_IP_address value is present, to serve as the default IP address for the M / H Service).

The source_IP_address field (32 or 128 bits) needs to be interpreted when source_IP_address_flag is set to 1, but not when source_IP_address_flag is not set to zero. When the source_IP_address_flag is set to 1 and the IP_version_flag field is set to 0, this field indicates a 32-bit IPv4 address representing the source of the virtual channel. If the IP_version_flag field is set to 1, this field indicates a 32-bit IPv6 address indicating the source of the virtual channel (source_IP_address: This field shall be present if source_IP_address_flag is set to 1 and not present if source_IP_address_flag is set to 0. If present, this field will contain the source IP address of all the IP datagrams carrying the components of this M / H Service. The conditional use of the 128 bit-long address IPv6 in the future, although use of IPv6 is not currently defined).

The MH_service_destination_IP_address field (32 or 128 bits) needs to be interpreted when the MH_service_destination_IP_address_flag is set to 1, but not when the MH_service_destination_IP_address_flag is set to 0. When the MH_service_destination_IP_address_flag is set to 1 and the IP_version_flag field is set to 0, this field indicates the 32-bit target IPv4 address for the virtual channel. When the MH_service_destination_IP_address_flag is set to 1 and the IP_version_flag field is set to 1, this field indicates a 64-bit target IPv6 address for the virtual channel. If the corresponding MH_service_destination_IP_address can not be interpreted, the component_destination_IP_address field in the num_components loop must be interpreted and the receiving system must use the component_destination_IP_address to access the IP stream component (MH_service_destination_IP_address: this field shall be present if the MH_service_destination_IP_address_flag is set to 1 and If the MH_service_destination_IP_address is not present, then the component_destination_IP_address field shall be present for each component in the num_components loop. The conditional use of the 128-bit address It is possible to use IPv6 in the future, although IPv6 is not currently defined).

Meanwhile, the SMT according to the present embodiment provides information on a plurality of components using a for loop.

The essential_component_indicator field (1 bit), when set to 1, indicates that the component is a required component for mobile services. Otherwise, it indicates that the component is an optional component (essential_component_indicator: A one-bit indicator which indicates when this component is an essential component for the M / H Service. Otherwise, this field indicates that this component is an optional component).

The component_destination_IP_address_flag field (1 bit) is a flag indicating that a component_destination_IP_address field exists for the corresponding component if it is set to 1 (component_destination_IP_address_flag: A 1-bit Boolean flag that indicates when the component_destination_IP_address is present this component).

The port_num_count field (6 bits) indicates the number of the UDP port associated with the corresponding UDP / IP stream component. The target UDP port number value increases by 1, starting from the destination_UDP_port_num field value. For the RTP stream, the target UDP port number is incremented by 2, starting from the destination_UDP_port_num field value, to contain the RTCP stream associated with the RTP stream (port_num_count: this field indicates the number of destination UDP ports associated with this UDP / IP stream component. The values of the destination UDP port numbers shall start from the component_destination_UDP_port_num field and shall be incremented by one, except in the case of RTP streams, when the destination UDP port numbers shall start from the component_estination_UPD_port_num field and shall be incremented by two, to allow for the RTCP streams associated with the RTP streams).

The destination_UDP_port_num field (16 bits) indicates the target UDP port number for the corresponding IP stream component. The value of destination_UDP_port_num is an even number for the RTP stream and the next higher value represents the target UDP port number of the associated RTCP stream (component_destination_UDP_port_num: A 16-bit unsigned integer field, which represents the destination UDP port number for this UDP / IP stream component For RTP streams, the value of component_estination_UDP_port_num shall be even, and the next higher value shall represent the destination UDP port number of the associated RTCP stream.

The component_destination_IP_address field (32 or 128 bits) indicates the 32-bit target IPv4 address for this IP stream component if the IP_version_flag field is set to zero. If the IP_version_flag field is set to '1', this field indicates a 128-bit target IPv6 address for the corresponding IP stream component (component_destination_IP_address: This field shall be present if component_destination_IP_address_flag is set to 1 and not present if component_destination_IP_address_flag is set to 0. When this field is present, the destination address of the IP datagrams carrying this component shall be the address of this field. The IPv6 address of the IPv6 address is the IPv6 address of the IPv6 address, which is the IPv6 address of the IPv6 address.

The num_component_level_descriptors field (4 bits) describes the number of component level descriptors for the component (num_component_level_descriptors: This 4 bits field specifies the number of component level descriptors for this component).

The component_level_descriptor () indicates a descriptor that provides additional information about the corresponding IP component (component_level_descriptor (): one or more descriptors providing additional information for this IP stream component, may be included).

The num_MH_service_level_descriptors field (4 bits) describes the number of NRT service level descriptors for the service (num_MH_service_level_descriptors: This 4 bits field specifies the number of service level descriptors for this service).

MH_service_level_descriptor () indicates a descriptor that provides additional information about the service. Here, the mobile service may include an NRT service and may indicate a specific service type for the corresponding NRT service. The concrete service type may include, for example, a portal service for providing web contents, a push VOD, and an A / V download (MH_service_level_descriptor (): Zero or more descriptors providing additional information for this M / H Service, may be included).

The num_ensemble_level_descriptors field (4 bits) describes the number of ensemble level descriptors for the ensemble (num_ensemble_level_descriptors: This 4 bit field specifies the number of ensemble level descriptors for this ensemble).

The ensemble_level_descriptor () indicates a descriptor that provides additional information on the mobile ensemble described by the SMT (ensemble_level_descriptor (): Zero or more descriptors providing for the M / H Ensemble which SMT-MH describes, may be included) .

The Source_IP_address is a source IP address of the same server that transmits all channels of the FLUTE session when the service is an NRT service.

MH_service_destination_IP_Address is signaled if there is a destination IP address of the session level of this FLUTE session.

A Component can be mapped to a channel in a FLUTE session, and a separate destination IP address (different from the IP address signaled on a per-session basis) can be signaled for each channel via component_destination_IP_address. Also, the destination port number can be signaled through the component_destination_UDP_port_num, and the number of the destination port number starting from the component_destination_UDP_port_num can be additionally designated through the port_num_count.

OMA - BCAST  Service Guide

13 is a diagram illustrating a structure of a service guide (SG) according to an embodiment of the present invention.

When the entry point information of the service guide is included in the ensemble and transmitted, the receiving system receives the service guide delivery descriptor (Service GuideDelivery Descriptor), which is information describing the service guide using the entry point information. Service Guide The structure and acquisition of the service guide can be obtained from the delivery descriptor, and the service guide information can be received using the information. The SG may provide signaling information (also referred to as announcement information) in a subdivided sub-unit, and the subdivided sub-unit is referred to as a fragment. The fragment used in the SG includes a Service fragment, a Schedule fragment, a Content fragment, a Purchase Item fragment, a Purchase Data fragment, a Purchase Channel ) Fragment, and an Access fragment, a Session description fragment, a previewData fragment, and an interactiveData fragment. In Fig. 13, arrows indicate reference relationships. According to this example, a perceived item fragment, a content fragment, a schedule fragment, and an access fragment can refer to a service fragment. Schedule fragments can refer to service fragments and content fragments. The numbers illustrated in the respective arrows in Fig. 12 indicate the possible number of each subunit information. And the number represents the possible number of each fragment.

The main fragments of the exemplified fragments will be described as follows.

The service fragment includes information about a service to be provided to the user, for example, a service such as a conventional television channel.

The content fragment includes metadata about the content. For example, a type of A / V, text, image, etc. for the content is included in the content fragment.

Also, the NRT service guide data can be obtained by acquiring a service fragment, a schedule fragment, and a content fragment. Here, the NRT service guide data may include information on a content version, a content_id, a content availability time, and the like.

The schedule fragment includes schedule information for one content of the service. For example, the broadcast time of the content may correspond to this.

The perceived item fragment includes item information related to purchase.

The perceived data fragment includes information related to the purchase of a service that the user can purchase. The perchance channel fragment refers to an interface through which a terminal or a user communicates with a purchasing system. The perchance channel fragment includes information related to the purchase system and management of the purchase channel.

The access fragment includes information related to the access of the service or the content.

Mobile NRT Service Signaling Architecture

How the characteristics of NRT services are signaled in M / H broadcasts. The signaling of information for individual MH NRT content items consists of the following two steps. First, the FDT of FLUTE sessions is used to convey lists of items of all content items, their sizes, data types and information related to obtaining the items. Second, the OMA-BCAST SG provides more detailed description information on the items and their delivery schedules. (The signaling of information about individual M / H NRT content items is done at two levels:

1. The File Delivery Table (FDT) of the FLUTE sessions used to deliver the items lists all the content items and provides their sizes, data types, and other information relevant to the acquisition of the items.

2. The OMA BCAST Service Guide (SG) provides more detailed descriptive information about the items and their delivery schedules.

NRT_component_descriptor ()

The contents through the NRT service are transmitted through the FLUTE, and the access information on the SMT table signals the FLUTE session information as follows.

FIG. 14 illustrates a bitstream syntax of an NRT component descriptor according to an embodiment of the present invention. Referring to FIG.

NRT_component_descriptor () will appear in the component descriptor loop of each component of each NRT service in the SMT. And all parameters in the descriptor correspond to the parameters used for the components of the NRT service (An NRT_component_descriptor () shall appear in the component descriptor loop of each component of each NRT service in the SMT and all parameters in the descriptor shall correspond to the parameters of the NRT Service.

Hereinafter, each field information transmitted through the NRT_component_descriptor will be described.

The descriptor_tag field (8 bits) identifies the corresponding descriptor (0x8D) (descriptor_tag: This 8-bit unsigned integer shall have the value, identifying this descriptor as the NRT_component_descriptor).

The descriptor_length field (8 bits) describes the length (in bytes) from the immediately following field to the end of the descriptor (descriptor_length: This 8-bit unsigned integer shall specify the length (in bytes) immediately following this field up to the end of this descriptor).

The component_type field (7 bits) identifies the encoding format of the component. The identification value may be one of values assigned for the payload_type of the RTP / AVP stream. Or one of the values shown in Table 3 assigned by this specification. Or a dynamic value. For the components that make up the media being transmitted via RTP, the values in this field will match the values in the payload_type in the RTP header of the IP stream that is transmitting the component (component_type: This 7-bit field shall identify the encoding format of the The value may be any of the values assigned by IANA for the payload_type of an RTP / AVP stream [10], or it may be any of the values in [3] value in the range 96-127. For components of media carrying via RTP, the value of this field shall match the value in the payload_type field in the RTP header of the IP stream carrying this component. Note that additional values of the component_type field in the range of 43-71 can be defined in future versions of this standard.

In case of transmitting the NRT service stream on the basis of FLUTE, the component_type 38 defined for the FLUTE component in the ATSC-M / H may be used to further signal the following parameters required for the FLUTE session, 43 is newly defined as a component_type for NRT transmission.

component_type Meaning 0-34 Assigned or reserved by IANA, except that 20-4, 27, and 29-30 are unassigned 35 H.264 / AVC video stream component (assigned by ATSC use) 36 SVC enhancement layer stream component (assigned by ATSC use) 37 HE AAC v2 audio stream component (assigned by ATSC use) 38 FLUTE file delivery session (assigned by ATSC use) 39 STKM stream component (assigned by ATSC use) 40 LTKM stream component (assigned by ATSC use) 41 OMA-RME DIMS stream component (assigned by ATSC use) 42 NTP timebase stream component (assigned by ATSC use) 43-71 [Unassigned by IANA and reserved by ATSC use] 72-76 Reserved by IANA 77-95 Unassigned by IANA 96-127 Designated by IANA for dynamic use

The num_STKM_streams field (8 bits) identifies the number of STKM streams associated with the component (num_STKM_streams: An 8-bit unsigned integer field that will identify the number of STKM streams associated with this component).

The STKM_stream_id field (8 bits) identifies the STKM stream with the keys to decrypt the corresponding protected component obtained. Herein, the STKM_stream_id field is referred to in the component descriptor for the STKM stream (STKM_stream_id: An 8-bit unsigned integer field that will identify an STKM stream where keys to decrypt this protected component can be obtained by reference to the STKM_stream_id in the component descriptor for the STKM stream).

The NRT_component_data (component_type) field provides the encoding parameters and / or other parameters needed to represent the component. Here, the structure of the NRT_component_data element is determined by the value of the component_type field (NRT_component_data (component_type): The NRT_component_data () element provides the encoding parameters and / or other parameters necessary for rendering this component. value of component_type field).

The File Delivery Table (FDT) of the FLUTE sessions is used to convey the list of items of all content items and provides the size, data type and information of the items involved in obtaining the items. to deliver the items lists all the content items and provide their sizes, data types, and other information relevant to the acquisition of the items).

For example, a receiver can configure and display a service guide using OMA BCAST SG. And the receiver obtains information from the SMT to connect the FLUTE session in which the content selected in the indicated service guide is transmitted. In addition, based on the content identifier information of the OMA BCAST SG and the access information acquired from the SMT, information on a file transmitted through the accessed file information (FDT) in the FLUTE session is mapped and received. Here, the content identifier information of the OMA-BCAST SG is a globalContentID that can globally uniquely identify a corresponding content item in an XML format or a concept including an NRT_content_id defined separately with respect to an NRT service, Conversion is required when mapping file information in a FLUTE session. However, the conversion process is described in detail in the corresponding part, and is omitted here.

In this regard, in order to signal a FLUTE session, parameters are required, and these parameters have mandatory parameters that are essential and optional parameters that are relevant to the FLUTE session. First, the required parameters include a source IP address, a number of channels in the session, a destination IP address and port number for each channel in the session, (TSI) of the session, and the start time and end time of the session parameters, and the corresponding session Optionally relevant parameters in relation to the FEC include: FEC Object Transmission Information, the first received information of the session including the files of interest (some information that tells the receiver that the interest is in the first place, And a Bandwidth specification parameter.

In this case, the number parameter of the in-session channel may be explicitly provided or may be obtained by summing the number of streams constituting the session. Through the session_description_descriptor, a source IP address, a destination IP address for each channel in the session, and a destination IP address for each channel in the session can be signaled through the SMT proposed in the present invention among the above parameters. The parameters for the address, port number, and number of channels in the session can be signaled.

NRT_component_data

FIG. 15 illustrates a bitstream syntax of NRT_component_data when the component type value in the NRT component descriptor of FIG. 14 is 38; FIG.

One NRT service may be included in multiple FLUTE sessions. Each session may be signaled using one or more FLUTE component descriptors depending on the IP addresses and ports used for the sessions. (Each single session may be signaled using one or more FLUTE sessions. more FLUTE component descriptors, depending on the IP addresses and ports used for the sessions.

Each field of NRT_component_data will be described in detail as follows.

The TSI field (16 bits) indicates the TSI of the FLUTE session (TSI: A 16-bit unsigned integer field, which will be the TSI of the FLUTE session).

The session_start_time field indicates the time at which the FLUTE session starts. If the value of the field is all 0, the session can be interpreted as already started (session_start_time: The time at which the FLUTE session starts. If the value of this field is set to all zero, then it will be interpreted to mean that the session has already started).

The session_end_time field indicates the time at which the FLUTE session ends. If the value of the field is all 0, the session can be interpreted as continuing indefinitely (session_end_time: the time at which the FLUTE session ends. If the value of this field is set to all zero, then it will be interpreted to mean that the session continues indefinitely.

The tias_bandwidth_indicator field (1 bit) indicates flags that contain Transport Independent Application Specific (TIAS) bandwidth information. To indicate that the TIAS bandwidth field is present, the corresponding bit shall be set to 1 and the corresponding bit shall be set to 0 to indicate that the TIAS bandwidth field does not exist (tias_bandwidth_indicator: A 1-bit field that flags the inclusion of TIAS bandwidth information. This bit shall be set to 1 to indicate the TIAS bandwidth field is present, and it shall be set to 0 to indicate the TIAS bandwidth field is absent.

The as_bandwidth_indicator field (1 bit) is a flag including AS (Application Specific) bandwidth information. To indicate that the AS bandwidth field is present, the corresponding bit shall be set to 1, and to indicate that the AS bandwidth field does not exist, the corresponding bit shall be set to 0 (as_bandwidth_indicator: A 1-bit field that flags the inclusion This field shall be set to 1 to indicate the AS bandwidth field is present, and it shall be set to 0 to indicate the AS bandwidth field is absent.

The FEC_OTI_indicator field (1 bit) indicates whether FEC object transmission information (OTI) information is provided (FEC_OTI_indicator: A 1-bit indicator indicating whether FEC Object Transmission Information is provided).

The tias_bandwidth field indicates the maximum bandwidth of the TIAS (tias_bandwidth: This value shall be set to one-thousandth of the Transport Independent Application Specific maximum bandwidth as defined in RFC 3890 [16] This gives the TIAS bandwidth in kilobits per second).

The as_bandwidth field will have the value of the AS maximum bandwidth (as_bandwidth: This value will be defined in RFC 4566 [17].) This gives the AS bandwidth in kilobits per second.

The FEC_encoding_id field indicates the FEC encoding ID used in the corresponding FLUTE session (FEC_encoding_id: FEC encoding ID used in this FLUTE session, as defined in RFC 3926 [18]).

The FEC_instance_id field indicates the FEC instance ID used in the corresponding FLUTE session (FEC_instance_id: FEC instance ID used in this FLUTE session, as defined in RFC 3926 [18]).

By signaling the above parameters through the FLUTE component data bytes, it is possible to provide all the necessary information for receiving the FULTE session. Through this session, the FDT is received and the FLUTE session data A method of acquiring information on all files transferred and receiving these files can be used.

Here, the NRT component descriptor may be transmitted through a Component_level_descriptor loop of the SMT. Therefore, even if the FLUTE channels are plural, since the session level parameters TSI, session_start_time, session_end_time, etc. are signaled only once, only one of the components of several channels can transmit the NRT component descriptor through the Component_level_descriptor loop.

Relationship between M / H service, FLUTE session and NRT service

16 is a diagram for explaining the relationship between the M / H service, the FLUTE session and the NRT service according to the present invention.

M / H services include one or more M / H component (s), and each M / H component is transmitted over a FLUTE channel. The FLUTE channel corresponds to the MH service component. In addition, one M / H NRT service includes multiple FLUTE sessions, and each FLUTE session includes multiple FLUTE channels. Here, the MH component is defined as one destination IP address and one UDP port number.

For example, the MH NRT service A includes FLUTE session 1, and the FLUTE session 1 is indicated by TSI 1 information of MH component 1 and MH component 2 of MH services. In addition, the MH NRT service B includes FLUTE sessions 2 and 3, the FLUTE session 2 is indicated by the TSI 2 information of the MH component 3 and the MH component 4 of the MH services, and the FLUTE session 3 is indicated by the TSI 3 information.

A description of the FDT schema

17 illustrates an FDT schema for mapping a file and a content_id according to an embodiment of the present invention. FIG. 18 illustrates an FDT schema for mapping a file and a content_id according to another embodiment of the present invention. And represents the FDT instant level entry file designation method.

Hereinafter, the FDT instance level refers to a level that includes a definition portion thereof when it is necessary to define common attributes of all files declared in the FDT, and the FDT file level includes definitions of individual attributes in each file Is used to refer to the level of

Referring to FIGS. 17 to 18, a portion denoted by 1 indicates a content identifier at an FDT-Instance level, and the content identifier declared here includes all files declared in the corresponding FDT- . Of course, this information may be overridden by newly assigning a content identifier at the file level. Alternatively, if a particular file belongs to a content item other than the content item defined at the FDT-Instance level, it may be informed by giving the file level content identifier described below. In the present embodiment, the content identifier is represented by 16 bits.

The part marked with 2 declares the content identifier at the file level. If the file included in the FDT Instance belongs to a different content item, this method is used to signal which content item each file belongs to.

3 is a method for informing each file whether or not the corresponding file is an entry file. That is, a file corresponding to a root file, which must be executed first to reproduce the content item first or to access the content item, among the plurality of files constituting the content item, is called an entry file, and a method for informing such information . The entry attribute can be omitted, and if the default value is omitted, it indicates that the file is not an entry file.

By signaling whether each entry belongs to a group belonging at the file level, a particular file may serve as an entry in a particular group and not in another group.

As an example of an entry file, when a content item is configured in the form of a web page, and index.htm and several other associated pictures and text files exist, index.htm is directly associated with the entry file .

The following two methods can be considered as a method of indicating whether or not an entry file is used when a content identifier is assigned at the FDT-instance level.

1) Adding a file level content identifier to the file corresponding to the entry file and setting its entry attribute to true: In this case, the content identifier has the disadvantage of overlapping with the FDT-Instance level and the file level, but the most flexible Structure.

2) It is possible to consider a method of directly referring to files that serve as an entry file in the content identifier definition of the FDT-instance level as in another embodiment of the FDT schema shown in FIG. To this end, in the embodiment of FIG. 18, the FDT-Content-ID-Type is separately defined for the FDT-instance level content identifier and extended to include the content location of the entry file as indicated by No. 2 .

In this method, it may be a drawback that the signaling of the content location is duplicated, but it is advantageous that the entry file configuration information can be acquired directly for each content item.

Mapping of SMT and FDT to OMA-BCAST SG

19 shows an example of a configuration block diagram of a receiver used for mapping signaling information configured according to an embodiment of the present invention.

According to the present invention, the mobile broadcasting receiver extracts and processes the SMT among the RS frame data of the ensemble after being tuned to a desired ensemble. Here, the SMT extracted / processed includes information necessary for mapping the mobile service (or NRT service) and the IP access information and the acquisition of the IP stream component of each mobile service (or NRT service) in the form of a table and a descriptor. In addition, the SMT is divided into sections and transmitted, and each section can be processed by itself. One SMT section contains the virtual channel information of the ensemble to which the SMT section is transmitted. Each SMT section is distinguished by ensemble_id and section_number. Each SMT section is encapsulated in UDP / IP, where the IP address and UDP port number use a well-known value, allowing the mobile broadcast receiver to receive the SMT section without additional IP connection information. Each SMT section is transmitted in binary form, and the mobile broadcast receiver processes the corresponding SMT section in binary form.

Here, the data of the SMT section is basically in a binary form, and the data of the OMA-BCAST SG is in XML form. Therefore, the two data can be used for subsequent mapping only after conversion. That is, the mobile broadcast receiver maintains consistency with the OMA-BCAST SG by converting the binary data elements of each received SMT section into XML format. Here, the binary SMT is processed by an SMT binary parser in the handler and stored in the storage unit 124, and then extracted from the storage unit 124 for mapping and converted into an XML form by the SMT converter, 165, and when the XML-type OMA-BCAST SG is input to the SG handler 165, mapping is performed using both data.

The conversion process for mapping both data will be described in more detail as follows.

FIG. 20 is a diagram for explaining a process of converting SMT data and OMA-BCAST SG data for mapping according to an embodiment of the present invention. FIG. 22 illustrates a method of converting a service_id will be.

Referring to FIGS. 20 and 22, a mobile broadcast receiver converts an SMT section of a binary format into an XML form for mapping.

For example, the transport_stream_id in the FIC and the service_id of the 16-bit binary type in the SMT are combined into an anyURI type and mapped to the service identifier information (for example, globalServiceID) on the OMA-BCAST SG. Here, the converted anyURI type may be, for example, a format such as urI :: // atsc. <Transport_stream_id> <service_id>. Thus, the receiver can find the service fragment using the service identifier information (e.g., globalServiceID) on the OMA-BCAST SG.

It also maps the content identifier information (e.g., globalContentID or NRT_content_id) on the OMA-BCAST SG based on the content_id in the FDT. Accordingly, the receiver can use the mapping to find a corresponding content fragment in the OMA-BCAST SG and a schedule fragment referring to the content fragment. Also, the content_id in the FDT may be 16 bits of binary type, for example.

Therefore, according to the present invention, the MH receiving system, which is a mobile broadcasting system, converts binary format SMT and FDT transmitted through a well-known IP address and a UDP port number into XML format, and converts OMA-BCAST SG The corresponding information can be mapped to maintain consistency.

NRT Signaling Architecture Description ( NRT Signaling Architechture description)

FIG. 21 illustrates an XML schema of an OMA BCAST SG broadcast service delivery for providing access information through an NRT service according to an embodiment of the present invention. Referring to FIG.

In the above procedure, the following method may be used for signaling access information for a service transmitted through an NRT service in an access fragment of the BCAST SG.

Access information for service delivery through broadcast is provided through a broadcast service delivery structure. As shown in FIG. 21, it is possible to provide access information of a service transmitted through the NRT service. If NRTerviceRef element is added as a method for the Session Description to provide access information for the NRT service, the NRT service reference information is referred to by referring to the NRT service access information on the SMT table.

To this end, as shown in FIG. 21, an NRT service ID is provided through a NRT-Service-Reference to use an NRT-Broadcast-Locator as a URI (Uivesical Resource Identifier) uniquely identifying an ensemble from which an NRT service is loaded, It is possible to distinguish between

It is also possible to extend the NRT-Broadcast-Locator as follows to identify the NRT service with a single URI.

atm: // f = <frequency>. <program_number> [.m = <modulation_format>] [/ <NRT_service_ID>]

As described above, the NRT service ID can be uniquely identified by one URI by including the NRT service ID in the URI.

How to provide NRT service

23 is a flowchart illustrating a method of providing an NRT service according to an embodiment of the present invention.

The receiver receives the OMA BCAST SG and processes the received OMA BCAST SG to configure and display the service guide (S2301).

If a specific content item in the at least one mobile NRT service is selected by the user or the like from the displayed service guide, a content identifier associated with the selected specific content item is obtained (S2302).

The receiver processes and reads the SMT among the signaling information to receive the selected specific content item (S2303).

If the M / H service includes a single or multiple M / H NRT service (s), it finds the MH_service_category field and identifies the NRT service (S2304). Here, the receiver can identify a desired NRT service using the MH_service_id field.

The receiver reads and stores session information such as an IP address and a UDP port number for each component corresponding to the NRT service in the SMT (S2305).

The receiver processes the component_descriptor () for the NRT service and reads information about the FLUTE session (S2306).

The receiver can process the component_descriptor for each component (M / H component data with type 38) to determine the TSI value for each component. The receiver joins the FLUTE file delivery session using the obtained information, reads the FDT, and obtains a content_id for the selected content item (S2307).

The content_id acquired in step S2307 and the content identifier acquired in step S2302 are mapped (S2308). Here, the mapping is performed because the content_id obtained in step S2307 and the content identifier obtained in step S2302 are defined in different formats. For example, the above-described mapping process can be referred to FIG. 20 to FIG. 22 described above.

If the content_id obtained in step S2307 and the content identifier obtained in step S2302 match, the file in the selected content item is downloaded (S2309).

24 is a flowchart illustrating a method of providing an NRT service according to another embodiment of the present invention.

The receiver processes and reads the SMT among the signaling information to receive the content item in the NRT service (S2401).

If the M / H service includes a single or multiple M / H NRT service (s), it finds the MH_service_category field and identifies it as an NRT service (S2402). Here, the receiver can identify a desired NRT service using the MH_service_id field.

The receiver reads and stores session information such as an IP address and a UDP port number for each component corresponding to the NRT service in the SMT (S2403).

The receiver processes the component_descriptor () for the NRT service and reads information about the FLUTE session (S2404).

The receiver can process the component_descriptor for each component (M / H component data with type 38) to determine the TSI value for each component. The receiver joins the FLUTE file delivery session using the obtained information and reads the FDT to obtain the content_id for the content item in the NRT service. The obtained content_id and files transmitted through the corresponding FLUTE session are stored (S2405).

The receiver receives the OMA BCAST SG and processes the received OMA BCAST SG to configure and display the service guide (S2406).

If a specific content item in at least one mobile NRT service is selected by the user or the like from the displayed service guide, a content identifier associated with the selected specific content item is obtained (S2407).

The content_id acquired in step S2405 and the content identifier acquired in step S2407 are mapped (S2408). Here, the mapping is performed because the content_id acquired in step S2405 and the content identifier acquired in step S2407 are defined in different formats. The above-described mapping process refers to the above-described FIG. 20 to FIG. 22.

If the content_id obtained in step S2405 and the content identifier obtained in step S2407 match, the file in the selected content item is reproduced (S2409).

In the case of the service method of FIG. 23, the SMT is firstly processed to access the FLUTE session in which the NRT service is provided to receive and store the content items in the corresponding service, and then, the OMA- Is a flow of reproducing a content item desired by a user or the like.

In contrast, in another embodiment of the service method of FIG. 24, the OMA-BCAST SG is first processed to provide a service guide. When a user selects a specific content item, the SMT is processed to connect to the FLUTE session in which the selected content item is transmitted And receives and stores the content, and then plays back the content.

The service method of FIG. 23 and the service method of FIG. 24 have the above-described difference. In the case of FIG. 23, by receiving and storing all relevant content items, the user can broaden the selection range and the desired content is already stored. However, there is a limit to the storage space, and receiving all the content items in the service and receiving unnecessary content items may reduce the efficiency of the system. In the case of FIG. 24, it is possible to increase the efficiency of the system by receiving only the desired content item. However, if the user desires another content item, the service guide is provided again and the selected content item must be received. have.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, .

Claims (8)

Generating a first broadcast service,
Here, the first broadcast service is a broadcast service in which first broadcast data included in the first broadcast service is transmitted before the first broadcast service is displayed, and is stored in a receiver;
Generating first signaling data including information for acquiring the first broadcast service;
The first broadcast data included in the first broadcast service is processed by an ALC / LCT protocol and the first broadcast data processed by the ALC / LCT protocol is processed by UDP (User Datagram Protocol) and processing the first broadcast data processed by the UDP with IP (Internet Protocol);
Processing the first signaling data by UDP and processing the first signaling data processed by the UDP by IP; And
Transmitting a broadcast signal including the first broadcast data processed by the IP and the first signaling data processed by the IP;
/ RTI &gt;
Here, the first signaling data is transmitted in a fixed IP address and a fixed UDP port number in the broadcast signal,
The method of claim 1, wherein the first signaling data includes information necessary to obtain a service guide. The method according to claim 1,
Generating a second broadcast service;
Further comprising:
Here, the second broadcast service is a broadcast service in which second broadcast data included in the second broadcast service is transmitted in real time;
Wherein the second broadcast service is a broadcast service for displaying additional information using the first broadcast data. 3. The method of claim 2, wherein the first signaling data comprises:
And service category information for identifying that the broadcast service is the first broadcast service. The method of claim 3,
Wherein the broadcast signal further comprises second signaling data,
Wherein the second signaling data includes transmission start time information indicating a start time of transmission of the first broadcast data included in the first broadcast service. A first encoder for generating a first broadcast service,
Here, the first broadcast service is a broadcast service in which first broadcast data included in the first broadcast service is transmitted before the first broadcast service is displayed, and is stored in a receiver;
A first signaling encoder for generating first signaling data including information for obtaining the first broadcast service;
The first broadcast data included in the first broadcast service is processed by an ALC / LCT protocol and the first broadcast data processed by the ALC / LCT protocol is processed by UDP (User Datagram Protocol), processes the first broadcast data processed by the UDP with IP (Internet Protocol), processes the first signaling data into UDP, processes the first signaling data processed by the UDP into IP A protocol processing unit; And
A broadcast signal generator for transmitting a broadcast signal including first IP data processed first broadcast data and IP processed first signaling data;
/ RTI &gt;
Here, the first signaling data is transmitted in a fixed IP address and a fixed UDP port number in the broadcast signal,
Wherein the first signaling data includes information necessary for obtaining a service guide. 6. The method of claim 5,
A second encoder for generating a second broadcast service;
Further comprising:
Here, the second broadcast service is a broadcast service in which second broadcast data included in the second broadcast service is transmitted in real time;
Wherein the second broadcast service is a broadcast service for displaying additional information using the first broadcast data. 7. The method of claim 6, wherein the first signaling data comprises:
And service category information for identifying the broadcast service as the first broadcast service. 8. The method of claim 7,
Wherein the broadcast signal further comprises second signaling data,
Wherein the second signaling data includes transmission start time information indicating a time at which transmission of the first broadcast data included in the first broadcast service is started.

Images