CN101558589B - For send broadcast method and apparatus, for receiving the method and apparatus of broadcast - Google Patents

Abstract

[Problem] It is difficult to apply the A-VSB transmission system to mobile broadcasting. [Solutions] A method and apparatus for transmitting broadcast and a method and apparatus for receiving broadcast are provided. In a method for transmitting a broadcast service for mobile communication, the method includes: generating an encapsulation packet including configuration information and application data adapted to application data to be transmitted; generating the encapsulation packet by dividing the encapsulation packet into packets of a predetermined size a transport packet having data on the encapsulated packet, wherein the transport packet includes information on the structure of the transport packet; generating service configuration information including information on a channel with the transport packet, and including the service configuration information on at least the transport stream A service information channel at a predetermined location within a transmission channel. Therefore, it is possible to effectively use the data area and increase the speed of data transfer.

Description

Method and device for sending broadcast, method and device for receiving broadcast

technical field

The present invention relates to a method and device for transmitting broadcasts and a method and device for receiving broadcasts, and more particularly, to a broadcast transmitting method and a device for providing mobile broadcast services.

Background technique

ATSC (Advanced Television Systems Committee) is an organization that defines digital television (DTV) transmission standards in the United States of America among terrestrial digital television (DTV) broadcast transmission standards. The main points of the standard defined by ATSC relate to audio/video (AV) compression and transmission. That is, video signals are compressed according to the MPEG2 standard, sound and speech signals are compressed according to the AC-3 standard, and these signals are transmitted using a vestigial sideband (VSB) technique. The advantage of VSB as a standard for terrestrial DTV reception is that it increases the utilization of the frequency band, thereby maximizing the range of DTV viewing, and the disadvantage is that it is difficult to apply VSB to mobile TV due to the difficulty of receiving radio signals during sports.

Meanwhile, with the increase in demand for broadcast services using mobile communication devices, such as terrestrial DMB broadcast service and satellite DMB broadcast service, and the increase and diversification of demand for broadcast services, various methods for satisfying user needs have been proposed. broadcast technology.

Description of drawings

Fig. 1A and Fig. 1 B show the MCAST data protocol stack according to an embodiment of the present invention;

Fig. 2 shows the MCAST data protocol stack according to another embodiment of the present invention;

Fig. 3 schematically shows the structure of the A-VSBMCAST transmission system according to an embodiment of the present invention;

Fig. 4 schematically shows the structure of the A-VSBMCAST transmission system according to another embodiment of the present invention;

Fig. 5 schematically shows the OMA-BCAST service layer according to an embodiment of the present invention;

Fig. 6 schematically shows a terminal network protocol interface according to an embodiment of the present invention;

7A to 7D show a high-speed service access method supported by the ATSC-MCAST system according to an embodiment of the present invention;

8A and 8B show a high-speed service access method supported by the ATSC-MCAST system according to another embodiment of the present invention;

9A and 9B show a high-speed service access method supported by the ATSC-MCAST system according to another embodiment of the present invention;

10A to 10C illustrate service configuration information according to an embodiment of the present invention;

FIG. 11 shows the structure of the version_indicator_information() field shown in FIG. 10A according to an embodiment of the present invention;

FIG. 12 shows the structure of the frame_group_information() field;

FIG. 13 shows the structure of the turbo_channel_information() field shown in FIG. 10A according to an embodiment of the present invention;

FIG. 14 shows the structure of the additional_service_information() field shown in FIG. 10A according to an embodiment of the present invention;

FIG. 15 shows the structure of the Turbo_channel_information_description() field according to an embodiment of the present invention;

FIG. 16A shows the structure of the turbo_channel_configuration() field shown in FIG. 10B according to an embodiment of the present invention;

FIG. 16B shows the structure of a turbo_channel_configuration() field according to another embodiment of the present invention;

FIG. 17 shows the structure of the descriptor_loop() field shown in FIG. 16A according to an embodiment of the present invention;

FIG. 18 shows the structure of the "frame_group_update" field when the value of the "tag" field shown in FIG. 17 is set to "0";

FIG. 19A shows the structure of the 'Frame_Slicing_Duration_update' field when the value of the 'tag' field shown in FIG. 17 is set to '1' according to an embodiment of the present invention;

FIG. 19B shows a structure of a 'Frame_Slicing_Duration_update' field when the value of the 'tag' field shown in FIG. 17 is set to '1' according to another embodiment of the present invention;

20A shows the structure of the "SRS_position_update" field when the value of the "tag" field shown in FIG. 17 is set to "2" according to an embodiment of the present invention;

20B shows the structure of the 'SRS_position_update' field when the value of the 'tag' field shown in FIG. 17 is set to '2' according to another embodiment of the present invention;

FIG. 21A shows the structure of the 'turbo_channel_update' field when the value of the 'tag' field shown in FIG. 17 is set to '3' according to an embodiment of the present invention;

FIG. 21B shows a structure of a 'turbo_channel_update' field when the value of the 'tag' field shown in FIG. 17 is set to '3' according to another embodiment of the present invention;

FIG. 22A shows the structure of the "BD_Packet" field according to an embodiment of the present invention;

FIG. 22B shows the structure of the "BD_Packet" field according to another embodiment of the present invention;

FIG. 23 shows the structure of a Broadcast Descriptor (BD) according to an embodiment of the present invention;

FIG. 24A shows the structure of the "Channel_info_update()" field when the value of the "tag" field shown in FIG. 23 is set to "1" according to an embodiment of the present invention;

FIG. 24B shows the structure of the "Channel_info_update()" field according to an embodiment of the present invention;

FIG. 24C shows the structure of the "Channel_info_update()" field according to another embodiment of the present invention;

25A shows an Internet Protocol (IP) mapping descriptor when the value of the "tag" field shown in FIG. 23 is set to "1" according to an embodiment of the present invention;

FIG. 25B shows an IP mapping descriptor according to another embodiment of the present invention;

FIG. 26 shows the structure of the "IP_channel_description" field shown in FIG. 25A according to an embodiment of the present invention;

FIG. 27A shows the structure of the "IP_address_table" field when the value of the "tag" field shown in FIG. 26 is set to "1" according to an embodiment of the present invention;

27B shows the structure of the 'IP_address_table' field when the value of the 'tag' field shown in FIG. 26 is set to '1' according to another embodiment of the present invention;

FIG. 28 shows the structure of the "MAC_address_table" field when the value of the "tag" field shown in FIG. 26 is set to "2" according to an embodiment of the present invention;

FIG. 29 shows the structure of the "Text_description_table" field when the value of the "tag" field shown in FIG. 26 is set to "3" according to an embodiment of the present invention;

Figure 30A shows the MCAST multiplexing structure according to an embodiment of the present invention;

Fig. 30B shows the MCAST multiplexing structure according to another embodiment of the present invention;

Figure 31A shows the MCAST frame structure and LMT according to an embodiment of the present invention;

Fig. 31 B shows the MCAST frame structure and LMT according to another embodiment of the present invention;

FIG. 32 shows a method of checking a change in a sub-data channel by using Virtual Mapping Identification (VMI) according to an embodiment of the present invention;

33 is a flowchart illustrating a method of obtaining a service by using a VMI according to an embodiment of the present invention;

FIG. 34A shows the structure of a location mapping table (LMT) according to an embodiment of the present invention;

Figure 34B shows in detail the structure of the LMT of Figure 34A according to an embodiment of the present invention;

35A and 35B illustrate the structure of an LMT according to an embodiment of the present invention;

FIG. 36 shows the structure of the "LMT_information" field shown in FIG. 35 according to an embodiment of the present invention;

37A and 37B illustrate structures of LMT and "LMT_information" fields according to another embodiment of the present invention;

FIG. 38 shows the structure of an LMT according to another embodiment of the present invention;

Fig. 39 shows the structure of MCAST frame and Link Information Table (LIT) according to an embodiment of the present invention;

FIG. 40 shows the structure of a LIT according to an embodiment of the present invention;

41A and 41B illustrate the structure of a LIT according to another embodiment of the present invention;

42A is a flowchart illustrating a method of providing a service using LMT and LIT according to an embodiment of the present invention;

42B is a flowchart illustrating a method of providing a service using LMT and LIT according to another embodiment of the present invention;

FIG. 43 shows the structure of object transfer information according to an embodiment of the present invention;

FIG. 44 shows the structure of the 'directory_information' field shown in FIG. 43 according to an embodiment of the present invention;

FIG. 45 shows the structure of the "time_table" field shown in FIG. 43 according to an embodiment of the present invention;

FIG. 46 shows the structure of the 'content_name_descriptor' field when the value of the 'tag' field shown in FIG. 43 is set to '1' according to an embodiment of the present invention;

FIG. 47 shows the structure of the 'mime_type_description' field when the value of the 'tag' field shown in FIG. 43 is set to '2' according to an embodiment of the present invention;

Fig. 48 shows the relationship between the encapsulation packet and the transport packet in the MCAST system according to an embodiment of the present invention;

FIG. 49A and FIG. 49B illustrate an encapsulation packet used for signaling according to an embodiment of the present invention;

Figures 50A and 50B illustrate a package for real-time data according to an embodiment of the present invention;

Fig. 51 shows the syntax of the encapsulation package for real-time data according to an embodiment of the present invention;

52A and 52B illustrate the syntax of an encapsulated packet for IP data according to an embodiment of the present invention;

Fig. 53 shows the syntax of an encapsulation packet for IP data according to another embodiment of the present invention;

54A and 54B illustrate the structure of a packet for object data according to an embodiment of the present invention;

55A and 55B illustrate the structure of a packet for object data according to another embodiment of the present invention;

FIG. 56 illustrates a method of transmitting object data according to an embodiment of the present invention;

Figure 57 shows the application of application layer forward error correction (AL-FEC) according to an embodiment of the present invention;

FIG. 58 shows a header structure of a transport packet and a transport packet according to an embodiment of the present invention;

Figure 59 shows the syntax of a transport packet according to an embodiment of the present invention;

FIG. 60A and FIG. 60B illustrate the structure of a transport packet, a basic header and additional fields according to another embodiment of the present invention;

61A and 61B show the structure of the "padding_field" field according to an embodiment of the present invention when the value of the "tag" field shown in FIG. 60 is set to "0";

FIG. 62 shows the structure of the 'LMT_field' field when the value of the 'tag' field shown in FIG. 60 is set to '1' according to an embodiment of the present invention;

FIG. 63 shows the structure of the 'compression_field_parameter' field when the value of the 'tag' field shown in FIG. 60 is set to '2' according to an embodiment of the present invention;

64A and 64B illustrate the structure of a signaling packet according to an embodiment of the present invention;

FIG. 65 shows the process of providing OMA-BCAST service in the MCAST transmission system according to an embodiment of the present invention;

FIG. 66 shows a method of providing a service by using MCAST supporting OMA-BCAST according to an embodiment of the present invention;

Figure 67 illustrates four layers for securing services and content according to an embodiment of the present invention;

Figure 68 illustrates a power management mechanism according to an embodiment of the invention;

Figure 69 shows parameters related to MCAST frame fragmentation according to an embodiment of the present invention;

Figure 70 shows parameters related to energy saving according to an embodiment of the present invention;

71 is a diagram illustrating a method of allocating each service to a predetermined bandwidth for burst mode transmission according to an embodiment of the present invention;

FIG. 72 is a diagram illustrating rotation of services for burst mode transmission according to an embodiment of the present invention;

Figure 73 is a diagram illustrating a generator matrix according to an embodiment of the present invention;

FIG. 74 is a flowchart illustrating a method of determining deg(v _i ) according to an embodiment of the present invention;

Figure 75 is a flow chart illustrating the connection of a message node to a code node according to an embodiment of the present invention;

FIG. 76 is a flowchart illustrating in detail operation S7520 illustrated in FIG. 75 according to an embodiment of the present invention;

77 is a block diagram of a MCAST broadcast receiving device according to an embodiment of the present invention;

78 is a flowchart illustrating a method of receiving broadcast according to an embodiment of the present invention;

Figure 79 schematically shows an A-VSBMCAST receiving system according to an embodiment of the present invention;

80 is a block diagram of a broadcast receiving device capable of indicating an error packet according to an embodiment of the present invention;

FIG. 81 is a flowchart illustrating a method of receiving a broadcast indicating an error packet according to an embodiment of the present invention;

82A and 82B illustrate the structure of a preamble according to an embodiment of the present invention;

83 is a flowchart illustrating a method of processing DCI by a broadcast receiving device according to an embodiment of the present invention;

FIG. 84A shows a method of updating a TCC in adaptive time slicing according to an embodiment of the present invention;

FIG. 84B shows an update method using BDs in adaptive time slicing according to an embodiment of the present invention;

85 is a block diagram of a broadcast service transmission device according to an embodiment of the present invention;

86 is a block diagram of a broadcast service receiving device according to an embodiment of the present invention;

FIG. 87 is a flowchart illustrating a method of transmitting a broadcast service according to an embodiment of the present invention;

FIG. 88 is a flowchart illustrating a method of receiving a broadcast service for mobile communication according to an embodiment of the present invention.

Contents of the invention

technical problem

The present invention provides a broadcast service sending method and a device capable of quickly and efficiently providing high-quality standard broadcast service in a mobile communication system, as well as a broadcast service receiving method and device.

Technical solutions

The present invention provides a method for transmitting a broadcast service for mobile communication, the method comprising: generating an encapsulation package including configuration information and application data adapted to the application data to be transmitted; by dividing the encapsulation package into predetermined A packet of size generates a transport packet with data about the encapsulated packet, wherein the transport packet includes information about the structure of the transport packet; generates service configuration information including information about the channel with the transport packet, and includes at least one on the transport stream The service configuration information in the service information channel at the predetermined position in the transport channel.

Beneficial effect

According to the present invention, since service configuration information exists in a predetermined area of a transmission frame, a broadcast service receiving device can access a transmission channel by using the service configuration information without processing a signaling information channel. Therefore, it is possible to reduce the waiting time of the broadcast service receiving device to receive the broadcast service which does not occur until each broadcast service is accessed after detecting the signaling information channel in the transmission frame and interpreting the signaling information channel. step.

In addition, according to the present invention, the structure of the encapsulation packet and the transport packet is determined to be suitable for the type of application data provided, thereby effectively using the data area and increasing the speed of data transfer.

In addition, according to the present invention, decoder configuration information is transmitted together with a broadcast service providing real-time media data, so that a receiving end can update a specification of a decoder adapted to a format of media data provided in advance by using the decoder configuration information.

optimal mode

According to an aspect of the present invention, there is provided a device for transmitting broadcast services for mobile communications, the device comprising: a package generating unit for generating a package including configuration information and application data adapted to the application data to be transmitted Encapsulating packets; a transport packet generating unit, which generates a transport packet with data about the encapsulating packet by dividing the encapsulating packet into packets of a predetermined size, wherein the transport packet includes information about the structure of the transport packet; a service configuration information generating unit, which includes Service configuration information about information on channels having transport packets, and includes service configuration information in a service information channel at a predetermined position in at least one transport channel on the transport stream.

According to an aspect of the present invention, there is provided a method for receiving a broadcast service for mobile communication, the method comprising: determining a predetermined transmission channel by using service configuration information extracted from a service information channel; extracting from the determined transmission channel Transport packets; extract information about the transport packets from the extracted transport packets; obtain combinations of encapsulated packets each having at least one transport packet by extracting information about the transport packets; obtain at least one encapsulated packet by using information about the encapsulated packets A combination of packaged application data, wherein the package is extracted from the combination of packaged packages.

According to an aspect of the present invention, there is provided an apparatus for receiving a broadcast service for mobile communication, the apparatus including: a transmission channel determination unit that determines a predetermined transmission channel by using service configuration information extracted from a service information channel; A packet extracting unit extracts a transport packet from the determined transport channel; a transport packet information extracting unit extracts information about the transport packet from the extracted transport packet; an encapsulation packet combining unit obtains each having at least one A combination of capsules of transport packets; an application data combining unit that obtains a combination of application data having at least one capsule by using information on the capsules, wherein the capsules are extracted from the combination of capsules.

According to an aspect of the present invention, there is provided a method for transmitting a stream, the method comprising: inserting a second transport stream required by a mobile terminal for receiving broadcast data into a first transport stream; the first transport stream of .

The second transport stream may be inserted at a predetermined position on the first transport stream.

The method may further include: generating signaling information including at least one of information on a location of the second transport stream and information required to process the second transport stream, wherein during transmitting the first transport stream, the signaling information is also transmitted. order information.

According to an aspect of the present invention, there is provided a method for receiving a stream, the method comprising: obtaining a second transport stream by receiving a first transport stream inserted with a second transport stream; and processing the second transport stream.

The second transport stream may be inserted at a predetermined position on the first transport stream.

During obtaining the second transport stream, signaling information including at least one of information about the location of the second transport stream and information required for processing the second transport stream may also be obtained, and the processing of the second transport stream may include based on The signaling information handles the second transport stream.

Detailed ways

invention model

For the convenience of explanation, the abbreviations and terms used in this specification are defined as follows:

Application Layer: Audio/Video (A/V) Streaming, Internet Protocol (IP), and Non-Real-Time (NRT) Services

ATSC-M/H terminal: Terminal device for accessing ATSC-M/H services

ATSC-M/H service: ATSC broadcast service targeting mobile phones and handheld terminals

ATSC-M/H system: a combination of service system and headend equipment that makes ATSC-M/H services available on broadcast and optionally on interactive channels

Cluster: Any number of sectors (sectors) that place Turbo slices

Primary Service: The first priority service that the user watches when the power is turned on. This is an optional service for broadcasters

Link layer: FEC encoding, segmentation, and mapping between Turbo streams and clusters

Link Information Table (LIT): Link information table between service components placed everywhere in the MCAST package

Location Mapping Table (LMT): the location information table placed everywhere in the MCAST package

MCAST package: transport package defined in MCAST package

MCAST package: group of MCAST packets decoded after extracting Turbo packets from the package

MCAST stream: sequence of MCAST packets

MCAST transport layer: transport layer defined in ATSC-MCAST

MPEG data: TS with missing sync byte

MPEG packets: TS packets with missing sync bytes

Package: a set of 624 TS MPEG packets

Sector: 8-byte space reserved in AF packets of TS or MPEG

SIC: type of turbo flow, which is a signaling information channel containing information for processing all turbo flows

Subchannel: Physical space for A/V streaming, Internet Protocol (IP) and NRT data

Sub-data channel: Physical space for sub-channel components

Transport layer: The transport layer defined in ATSC-MCAST

Turbo channel: The physical space for storing transport streams. The protection level of the Turbo channel can be different from each other

turbo stream: turbo encoded TS

VSB frame: 626 segments consisting of two data field sync segments and 624 (data+FEC) segments

A-VSB: Advanced VSB System

AF: Adaptation field in TS packets defined by A/53

ATSC: Advanced Television Systems Committee

BD: Broadcast Descriptor

BCAST: OMA Mobile Broadcast Service Enabler

IRD: Integrated Receiver and Decoder

DC: Decoder configuration

DCI: Decoder Configuration Information

DFS: Data Field Synchronization

DVB: Digital Video Broadcasting

ES: base stream

EC channel: basic component channel

FEC: forward error correction

F/L: first/last

IMT: IP mapping table

IPEP: IP Encapsulation Packet

LMT: Location Mapping Table

LIT: Link Information Table

MAC: Media Access Layer

MCAST: Mobile Broadcasting

OEP: Object Encapsulation Package

OMA: Open Mobile Alliance

PCR: Program Clock Reference

PSI: Program Specific Information

PSIP: Program Specific Information Protocol

REP: Real-Time Package

SD-VFG: Service division in individual frame groups

SEP: Signaling Encapsulation Packet

SG: Service Guide

SIC: Signaling Information Channel

SRC: Secondary Reference Sequence

TS: transport stream

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

The MCAST transmission system according to the present invention can provide various types of services together or only specific types of services, such as Internet Protocol (IP) services. FIG. 1 shows a case where various types of services are provided together. FIG. 2 shows a case where only a specific type of service is provided.

1A and 1B illustrate the MCAST data protocol stack according to an embodiment of the present invention. Referring to FIGS. 1A and 1B , various types of content are transmitted, thereby providing various types of services through the MCAST transmission system. Examples of services supported by the MCAST transport system (eg, real-time services, IP services, and object download services) will now be described. However, the types of services that can be supported by the MCAST transmission system are not limited thereto.

In a real-time service, data is received in real time and is expected to be consumed as soon as it is received. Types of real-time data include video, audio, and auxiliary information that accompanies audio/video (A/V).

IP service is a broad term indicating all types including services using IP-based data, such as IP data broadcasting. In IP services, IP-based data received in real time is expected to be consumed as soon as possible, or data to be received in the near future is expected to be consumed. Alternatively, the IP service may be extended to a service in which IP-based data is downloaded as an object and stored in a memory device so that it can be used later.

The object download service is characterized by receiving multimedia data or general object data at any point of time, and displaying or storing it in response to a control signal.

The characteristics of the data supported by the MCAST system for providing services will now be described.

MCAST supports H.264/AVC video encoding and decoding in IRD. In order to allow full compliance with the specification and upward compatibility with future enhanced versions, the IRD is able to skip data structures that are currently "reserved" or correspond to functionality not implemented by the IRD.

Regarding files and levels, MCAST supports the following encoding and decoding:

.encoding: The H.264/AVC bitstream shall conform to the ITU-T recommendation H.264 (ITU-T recommended H.264)/ISO/IEC14496-10 for level 1.3 of the baseline profile with constraint_set1_flag equal to "1" Descriptive qualification.

.decoding: Similarly, IRDs supporting H.264/AVC shall be able to decode and render images using a level 1.3 baseline profile with constraint_set1_flag equal to "1".

In the case of a sampling aspect ratio, using a square (1:1) sampling aspect ratio for encoding, each IRD may support decoding and rendering of images using a square (1:1) sampling aspect ratio for decoding.

Regarding random access points, it is recommended to send the sequence and set image parameters with the random access points at least every two seconds.

Regarding audio, ATSC-MCAST supports MPEG-4AAC files, MPEG-4HEAAC files and MPEG-4HEAACv2 files. To allow full compliance with ISO/IEC 14496-3 [5] and upward compatibility with future enhanced versions, the IRD can skip data structures that are currently "reserved" or correspond to functions not implemented by the IRD.

Regarding audio modes, audio is coded in mono, parametric stereo or 2-channel stereo according to the functions defined in HEAACv2 profile level 2, or in accordance with HEAACv2 profile level The functions defined in 4 encode audio in multiple channels. Additionally, the IRD is capable of decoding mono, parametric stereo or 2-channel stereo of the functions defined in HEAACv2 profile level 2, as specified in ISO/IEC 14496-3 including amendments 1 and 2 [5].

Regarding the bit rate, during encoding, the maximum bit rate cannot exceed 192kbit/s for stereo paired audio and 320kbit/s for multi-channel audio. During decoding, the IRD will support HEAACv2 files, the level chosen corresponds to the maximum value of 192kbit/s for stereo pairs.

In addition, regarding matrix down-conversion (downmixing), IRD will support matrix down-conversion defined in MPEG-4.

However, MCAST is not limited to the above-mentioned encoding methods. Streams encoded according to other encoding methods (eg, MPEG-2Video/BSAC) can also be transmitted by direct/indirect expression encoding methods.

Fig. 2 shows a MCAST data protocol stack according to another embodiment of the present invention. In detail, FIG. 2 shows a case where IP services are provided only through MCAST.

The packet layer divides signaling information and IP data programs into MCAST packets and adds transmission headers to them. The Signaling Information Channel (SIC) contains signaling information about each turbo channel.

In mobile services, fast service acquisition is highly desirable. MCAST reduces the steps of service tuning, demultiplexing and decoding, thereby providing fast service acquisition.

Additionally, MCAST supports the concept of master services. The main service is the first priority service that users watch in continuous mode. In the general case where a service accesses a turbo stream, the SIC needs to be obtained and first decoded for turbo processing. SIC contains physical decoding information and some brief descriptions of all turbo services. In the case of the main service, since access information is defined in Data Field Synchronization (DFS), quick access is possible. The quick access method will be described later with reference to FIGS. 7 to 9 .

Main service and SIC shall be in continuous transmission mode and SIC shall be present in every frame. In continuous transmission mode, frames are sent continuously. In burst transfer mode, multiple frames are sent at a specific point in time (see Figure 68 for details). SIC is mandatory. However, the main service is optional and depends on the service provider.

Fig. 3 schematically shows the structure of an A-VSBMCAST transmission system according to an embodiment of the present invention. Referring to Figure 3, MCAST supports various service types. The MCAST architecture consists of four layers: application layer, transport layer, data link layer and physical layer. These layers are shown from left to right in FIG. 3 .

The transport layer provides application-oriented and segmented information of application data and encapsulates primary units using a predetermined syntax. Application streams are encapsulated by a specific type and multiplexed into fixed-length packets, called "MCAST turbo streams". The packets then form a turbo channel.

The link layer receives turbo channels and applies a specific forward error correction (FEC), such as code rate, to each turbo channel. The signaling information present in the SIC is important, so stronger FEC is applied so that signaling can be received even at low signal-to-noise ratio (SNR) levels. Next, the turbo channel to which FEC is applied is sent to the A-VSBMAC layer together with general TS packets.

The A-VSBMAC layer inserts or adds robust packets containing additional data receivable by the mobile terminal to the general TS. For example, a robust packet can be inserted into an empty packet area of MPEGTS or included in a private data area of MPEG-2TS. If necessary, the A-VSBMAC layer turns on the Adaptation Field (AF) in the general TS packet. In this case, an SIC that transmits signaling information for processing a robust packet is defined, and the SIC can be easily obtained since the SIC exists at a predetermined location or by using a flag indicating the location of the SIC. As described above, the A-VSBMAC layer specifies a method or information on inserting or adding a robust packet to a general TS. In order to obtain the result (improvement) of overall gain and efficiency on the system that the 8-VSB system does not have originally, while maintaining the compatibility, the robust data is mapped to a definite frame structure, signaled and sent to the 8-VSB physical layer . In addition, the oscillator deterministically operates at the physical layer under the control of the MAC layer and inserts signaling information into the DFS.

MCAST provides real-time services, IP services, and object services provided as application services. Multiplex at least one of these services into each turbo channel's MCAST stream. Specifically, MCAST can provide a main service for obtaining a high-speed initial service.

To provide various services, MCAST provides at least one of four data types: real-time audio, real-time video, IP, and object signaling. For example, in order to improve the quality of service of applications, when sending a large number of files, application-layer FEC (AL-FEC) can be applied to object streams or IP streams. AL-FEC will be described later with reference to FIG. 57 .

Fig. 4 schematically shows the structure of an A-VSBMCAST transmission system according to another embodiment of the present invention. Referring to Figure 4, MCAST only supports IP services. The A-VSB MCAST transmission system is the same as that shown in Fig. 3, except that for each turbo channel, only IP services are multiplexed into one MCAST stream.

Fig. 5 schematically shows an OMA-BCAST service layer according to an embodiment of the present invention. In FIG. 5, "terminal" corresponds to "ATSC-M/H terminal" in terms of function, and other elements correspond to "ATSC-M/H system".

● BCAST-5 is an upper broadcast service layer interface for the management layer. The lower part of this interface is the Internet Protocol (IP), which in turn interfaces with the upper part of the interface X-3/X-4.

• BCAST-6 is an upper interactive service layer interface for the management layer.

• BCAST-7 indicates interface support signaling for user management and service/content transactions.

• BCAST-8 indicates service-scope interactions.

• X-3 and X-4 are considered the same in this specification. They indicate the bearer layer and carry data related to the interface BCAST-5. For the lower part, the interface specifies the A-VSB bearer layer. For the upper part, the interface specifies the transport supported by the MCAST transport of BCAST-5.

• X-5 and X-6 are considered the same in this specification. They indicate an optional interaction network/bearer layer that carries data related to interfaces BCAST-6, BCAST-7 and BCAST-8.

Interfaces BCAST-1, BCAST-2, BCAST-3, BCAST-4, BDS-1, BDS-2, X-1 and X-2 are not relevant to this specification and will not be described here.

Fig. 6 schematically shows a terminal network protocol interface according to an embodiment of the present invention. In FIG. 6, the ATSC-M/H terminal-network interface will be described in detail using the concepts of BCAST interface and MCAST structure. Figure 6 shows the proposed protocol stack related to ATSC-M/H not only for broadcast interactive mode but also for broadcast only mode. The stack is divided into two main parts. A major part is the ATSC-M/H service layer, consisting of methods and optional interaction methods applicable to all ATSC-M/H receivers. Below the ATSC-M/H service layer are bearer layers, one of which describes the ATSC-M/H bearer layer and the others describe any optional interactive bearer layers.

The signaling method of the MCAST system will now be described. An important requirement for mobile broadcasting is high-speed service access. ATSC-MCAST provides two representative ways for high-speed service access: main service and division of ES signaling information for real-time media service. A high-speed service access method supported by the ATSC-MCAST system will be described later with reference to FIG. 7 .

In addition, the ATSC-MCAST system can provide SIC. The SIC may contain essential information for processing turbo channels. The SIC may contain essential information indispensable for a user to browse broadcasts. For example, the SIC may contain, as an option, physical decoding information or a brief description of all turbo services. In order to process other turbo channels the SIC must be processed first. The SIC will be described later with reference to FIG. 10 .

Main service and SIC exist in continuous transmission mode, SIC can exist in all frames. Although the SIC is an indispensable element, the service provider may determine whether to provide the main service.

FIG. 7 shows a high-speed service access method supported by the ATSC-MCAST system according to an embodiment of the present invention. Referring to FIG. 7, a main service is provided according to a high-speed service access method. The main service has high priority for users to receive broadcast services.

Specifically, FIG. 7A shows the process of receiving a service in the MCAST system according to an embodiment of the present invention.

The broadcast receiving device checks the position of the SIC by interpreting the DFC. Then, the broadcast receiving device accesses the SIC based on the checked location of the SIC, as indicated by arrow (1). The SIC contains information on the number of turbo channels constituting a frame, information on the structure of each turbo channel (turbo channel decoding information, meta information, etc.).

The broadcast receiving device accesses the desired turbo channel by using the information contained in the SIC, as indicated by the arrow (2), and obtains the data of the application layer by processing the turbo stream received through the desired turbo channel, as indicated by the arrow (3) instruct.

As described above, in order to allow a user to receive a broadcast service, since the above-described processing must be performed after power is supplied to the broadcast receiving apparatus and a broadcast signal is received, a predetermined waiting time is required. In order to solve the problem that the broadcast service is not provided until the SIC is fully explained, a service that can be provided as a default before the broadcast receiving device operates and receives the SIC is proposed. Such a service is called a "master service". The main service is provided by a broadcast service provider so that users can browse it first.

FIG. 7B illustrates the process of providing the main service by the MCAST system according to an embodiment of the present invention. In FIG. 7B, access information for accessing a main service exists at a predetermined position of a transmission frame.

In case of an ATSC transmission frame according to the ATSC standard, access information for accessing a main service may be defined in the DFS. Therefore, the broadcast receiving device can directly access the turbo stream for the main service from the DFS without having to seek and process the SIC, as indicated by arrow (1).

FIG. 7C illustrates a method of transmitting a turbo stream for a main service according to an embodiment of the present invention.

The turbo stream for the main service is formed in the same method as other turbo streams are formed, and similarly to the other turbo streams, can be transmitted when it is mapped to a transmission frame. However, the turbo stream for the main service may be transmitted through the remaining data area of the transmission frame. Generally, the size of the remaining data area of the transport frame is smaller than that of the channel used for the main service, so that the turbo stream of the main service is divided according to the size of the remaining data area of the transport frame and transmitted through a plurality of transport frames.

Signaling information to be described later can be transmitted in a similar manner. That is, signaling information may be transmitted through an independent channel such as SIC or the remaining data area of the transmission frame. A method of allowing a user to obtain signaling information while browsing a main service will now be described with reference to a case of transmitting signaling information through an independent channel and a case of transmitting signaling information through a remaining data area of a transmission frame.

Fig. 7D is a diagram illustrating a method for obtaining signaling information in the MCAST system according to an embodiment of the present invention.

In operation S710, a broadcast signal is searched for when power is supplied to the broadcast receiving device.

In operation S720, the broadcast receiving device processes a turbo stream for a main service. The turbo stream for the main service may be transmitted in an additional turbo channel, or may be divided into several parts and transmitted in the remaining data area of the transmission frame.

In operation S730, the broadcast receiving device provides a main service by using the result processed in operation S720. Simultaneously with operation S730, operation S740 is performed to obtain signaling information. The information indicates whether signaling information or turbo stream for the main service is transmitted through an independent channel or through the remaining data area of the transmission frame, and may be stored in a predetermined area of the transmission frame, and the signaling for the main service is obtained using the information Information and turbo flow. In the case of an ATSC system, the information may be stored in the DFS.

If the signaling information is transmitted through an independent SIC, operation S742 is performed to obtain the signaling information by processing the SIC. If the signaling information is divided into several parts and transmitted through the remaining data area of the transmission frame, operation S744 is performed to obtain the signaling information from the remaining data area of the transmission frame.

In operation S750, it is determined whether the signaling information is updated. If the signaling information is updated, operation S740 is performed again to obtain updated signaling information. If the signaling information is not updated, perform S760 using the signaling information, thereby performing channel switching.

FIG. 8 shows a high-speed access method supported by the ATSC-MCAST system according to another embodiment of the present invention. Referring to FIG. 8, signaling information is divided for high-speed service access.

In case of real-time rich media service, information such as PSI (PAT, PMT, CAT or NIT) should be obtained first to decode multimedia data in a broadcast receiver. The user can watch the video after all PSIs are received. Although the receiver gets a decoded frame, the user must wait until the receiver receives decoder specific information from the PSI.

ATSC-MCAST proposes to send a Multimedia Decoder Specific Information Descriptor included in each Multimedia Element Stream (ES). This means that decoder configuration information and multimedia data are sent simultaneously. Therefore, the receiver does not need to wait to get PSI.

More specifically, FIG. 8A is a diagram comparing a service access time in ATSC-MCAST according to the present invention and a service access time in a conventional broadcasting system.

For example, it is assumed that the transmission time period of PAT and PMT is 0.5 second, and the transmission time period of I frame is delta second. In the worst case, it takes 0.5+0.5+delta seconds to see the first video since PAT, PMT and I frames have to be obtained. However, ATSC-MCAST only requires delta seconds to get the first I-frame present on the receiver. Therefore, ATSC-MCAST can quickly process I frames when they are received. The decoder specific information will be described with reference to FIG. 8B.

Fig. 8B shows the decoder configuration information (DCI) of an embodiment of the present invention. DCI is included in a "DCI_field" field.

The "DCI_field" field shown in FIG. 8B relates to real-time media in the MCAST encapsulation layer. The 'Decoder Specific Information' field included in the 'DCI_field' field contains specific information for a media decoder. A 'DCI_field' field may exist only in an encapsulation packet for real-time media.

The "ContentType" field indicates the content type in the stream. An example of defining a content type based on the value of this field is as follows:

[Table 1]

value Content Type Description 0 reserve 1 H.264/AVC 2 HE AAC 3-255 TBD

The 'MaxDecodingBufferSize' field indicates the length of the decoding buffer in bytes. Buffering is defined according to the type of stream.

The "DSIlength" field indicates the length of the "decoderspecificInformation" field in bytes.

The "DecoderspecificInformation" field contains decoder specific information. The "DecoderspecificInformation" field depends on the stream type and indicates the specification of the decoder.

FIG. 9 shows high-speed access methods supported by the ATSC-MCAST system according to another embodiment of the present invention.

In FIG. 9, it is assumed that IP data broadcast or IP service is provided through MCAST. Generally, IP data broadcasting or IP service and service guide (SG) must be provided at the same time to provide IP data broadcasting or IP service. A general broadcast receiver must first obtain an SG to obtain IP data broadcast or IP service. Hereinafter, SG defined in OMA-BCAST is used as an example of SG, but is not limited thereto. Any type of SG that provides information on IP data broadcasting or IP services for IP data broadcasting or IP services or access information may be used.

A user must first obtain an SG to receive a service through IP data broadcasting, and thus, a broadcast receiving device must stand by until an SG is received regardless of whether the user needs the SG. In order to solve this problem, the information required to receive IP data broadcast or IP service is transmitted so that the service can be provided first without receiving SG. Therefore, high-speed service access is enabled by IP data broadcasting or IP service.

More specifically, FIG. 9A shows the structure of transmission data for high-speed service access in IP data broadcasting according to an embodiment of the present invention.

The SIC contains IP information for the receiving SG, such as the SG's IP address. A fixed address that has been known by the broadcast receiving device can be used as the IP address of the SG, or it can be instructed that the SG is included in the IP information. For example, the transmission of the SG in the IP information may be expressed indirectly by using a tag indicating the IP information corresponding to the SG.

In addition, the SIC may contain additional information for providing a service to the user before the broadcast receiving device acquires part or all of the SG. Hereinafter, for convenience of explanation, a service that can be provided to a user before obtaining part or all of the SG will be referred to as a "typical service". The additional information may contain information for providing IP data broadcasting or IP service corresponding to a typical service, or information indicating a location of the information. Additionally, additional information may include IP addresses for typical services. At the location indicated by the IP address, there is a flow for providing a typical service or information necessary to provide a typical service. Examples of such information are flute session information, Session Description Protocol (SDP) or stream handling information.

In a MCAST system, there may be one or more typical services. If a plurality of typical services are provided, information on the typical services is supplied to the broadcast receiving apparatus so that a user can select one of them. When the user selects one of a plurality of typical services, the selected typical service is provided until the broadcast receiving device completely acquires the SG. After fully obtaining the SG, the user can select a desired service again based on the SG.

Alternatively, only one typical service may be provided, or a selected typical service may be provided without user's selection even when a plurality of typical services are provided.

In the turbo channel, an IP stream for providing a typical service and an IP stream for providing a general broadcast service are transmitted.

FIG. 9B is a flowchart illustrating a high-speed service access method for IP data broadcasting according to an embodiment of the present invention.

In operation S910, IMT is obtained. The IMT indicates mapping information between an IP address and a turbo channel, and can be transmitted through the SIC.

In operation S920, it is determined whether the transport stream provides a typical service. If the typical service is not provided, operation S932 is performed to obtain the SG. In this case, the broadcast service cannot be provided to the user until a predetermined part or all of the SGs are obtained. If the typical service is provided, operation S934 is performed to provide the typical service to the user. That is, typical services are provided by parsing streams provided by using information on typical services included in SIC (or DFS) and IMT. Meanwhile, operation S936 is performed in the background to obtain the SG.

After the SG is completely obtained, operation S940 is performed to determine whether a user's input is received. If the user's input is not received, operation S952 is performed to repeatedly reproduce the typical service or stand by until the user's input is received. If a user's input is received, operation S954 is performed to process and reproduce an IP stream corresponding to a channel selected by the user.

FIG. 10A shows service configuration information according to an embodiment of the present invention.

The SIC contains signaling information such as information on turbo channel information. Specifically, the SIC has information including turbo channel location information on each turbo channel in the A-VSB frame, time slice information, and information for processing each turbo channel. The SIC may be a type of turbo channel that exists at a predetermined position in the A-VSB frame.

The structure of the service configuration information will now be described with reference to FIG. 10A.

A 'turbo_channel_information_flag' field indicates whether turbo channel information exists. In the current embodiment, the 'turbo_channel_information' field contains turbo channel information which will be described in detail with reference to FIG. 13 later.

An 'additional_service_information_flag' field indicates whether description information of a turbo service exists. In the current embodiment, the 'additional_service_information' field contains additional service information of all turbo channels. Additional service information will be described in detail with reference to FIG. 14 later.

A "padding_flag" field indicates whether a padding area exists.

A 'version_indicator_information()' field indicates the version of the service configuration information and when the information is updated. In the current embodiment, the version of the "ServiceConfigurationInformation()" field is indicated and when this field is updated. The "version_indicator_information()" field will be described later with reference to FIG. 11 .

A 'frame_group_information()' field indicates the number of current frames and the total number of frames within a frame group. The "frame_group_information()" field will be described later with reference to FIG. 12 .

The "byte" field indicates padding bytes and is used by the encoder. This field is used to fill unallocated areas with a value of 0xFF.

The "CRC" field contains a CRC value.

FIG. 10B shows service configuration information according to another embodiment of the present invention.

A "current_frame_number" field indicates a current frame number. The frame count is incremented by 1 within the framegroup.

A 'total_frame_number' field indicates the total number of frames in a frame group.

In the current embodiment, the service configuration information may include information on TCC or Broadcast Descriptor (BD) according to the current frame number. That is, if the current frame number is even, information on TCC is included, and if the current frame number is odd, information on BD is included.

A 'TCC_next_updata_offset' field indicates the total number of frames before version update of turbo channel configuration information. In the current embodiment, the 'TCC_next_updata_offset' field contains turbo channel configuration information.

A "TCC_version" field is composed of 3 bits and indicates the version number of the TCC field. The version number shall be incremented by 1 modulo 8 whenever one of the fields related to TCC is changed.

A 'number_of_turbo_channel' field indicates the total number of turbo channels carried by the A-VSB. The number of scattered SRS channels is also specified in this field.

A 'turbo_channel_configuration' field includes turbo channel configuration information. The "turbo_channel_configuration" field will be described in more detail later with reference to FIG. 16 .

A 'BD_next_update_offset' field indicates the number of frames before a BD is updated.

A "BD_packet()" field contains a broadcast descriptor. The "BD_packet()" field will be described in more detail later with reference to FIG. 22 .

FIG. 10C shows service configuration information according to another embodiment of the present invention. The service configuration information shown in FIG. 10C is the same as that shown in FIG. 10B except for the "wake_up_mode" field.

A 'wake_up_mode' field indicates a TCC parsing mode of a subsequent TCC in the 'TCC_next_updata_offset' field. For example, if the value of this field is set to '1', subsequent TCCs can be parsed.

FIG. 11 shows the structure of the version_indicator_information( ) field shown in FIG. 10A according to an embodiment of the present invention.

In mobile broadcasting, service configuration information is very important. A "version_indicator_information()" field to be described includes update information of service configuration information. Therefore, the "Service_Configuration_Informaton()" field indicates the exact location and version of the frame to be changed.

A 'frame_counter' field indicates the total number of frames transmitted before the service configuration information is changed. Upon receipt of a transport frame, the service configuration information will change.

A "version" field indicates a version of service configuration information. The version value is incremented by 1 whenever the service configuration information changes.

FIG. 12 shows the structure of the 'frame_group_information()' field shown in FIG. 10A according to an embodiment of the present invention.

A frame group is a group of frames created by MCAST frame fragmentation and occurs periodically starting with the same frame number. In a transmission system, a technique of including transmission data about one service in at least one frame and transmitting the frame in a burst mode is called a frame fragmentation technique. When the frame slicing technique is used, there is a frame that does not contain data on the intended service, and the terminal can enter an idle state without receiving a signal in a portion of the transmitted frame, thereby saving energy consumption. The burst portion indicates a group of frames containing data on the intended service. And can be expressed using the number of frames to be described later.

A 'current_frame_number' field indicates the number of the current frame in the frame group. The number of frames in a frame group can be increased by 1.

A 'total_frame_number' field indicates the total number of frames in a frame group.

FIG. 13 shows the structure of the turbo_channel_information( ) field shown in FIG. 10A according to an embodiment of the present invention.

A 'turbo_channel_information()' field indicates turbo channel information and contains information indispensable for a plurality of turbo channels. Physical decoding information, information indicating the presence or absence of MCAST frame fragmentation, and the total number of turbo channels are important factors. Specifically, when MCAST frame fragmentation is supported, the 'turbo_channel_information()' field indicates the number of the current frame and the total number of frame blocks to be received for the selected turbo channel.

A "version" field is composed of 3 bits and indicates a version of turbo channel information. In the current embodiment, the version may be increased by 1 every time the 'turbo_channel_information()' field is changed. When the version changes, the turbo channel information should be sent in advance.

According to an embodiment of the present invention, the 'Turbo_svc' field indicates the total number of turbo channels in the A-VSB system.

A 'Turbo_svc_id' field indicates an identifier of a current turbo channel.

The "Is_Enhanced" field indicates whether the data is basic data or extended data. For example, when a "scalable" video codec is used, the base and extension streams may be contained in separate turbo channels or sub-data channels. If the basic stream and the extended stream are included in an independent turbo channel, the basic stream and the extended stream can be distinguished by using the 'Is_Enhanced' field.

The "MCAST_Frame_Slicing_flag" field specifies whether to transmit the current turbo stream in burst mode.

The "MCAST_AL_FEC_flag" field specifies whether the current turbo stream supports application layer FEC (AL-FEC).

A 'turbo_start_position' field indicates a start position of a turbo channel.

A 'turbo_fragments_bits' field indicates an index of a turbo channel length.

A "turbo_arrange_index" field indicates the number. If the number is n, it means that every nth packet includes a turbo channel segment.

A 'coding_rates' field indicates an index of a turbo channel code rate.

A 'start_frame_number' field indicates the start frame number of the current turbo service when there is a MAST frame fragment.

A 'frame_block_number' field indicates the current total number of turbo channels.

FIG. 14 shows the structure of the additional_service_information( ) field shown in FIG. 10A according to an embodiment of the present invention.

SIC provides a structure for carrying additional information. In the current embodiment, the 'additional_service_information' field contains additional information. The 'additional_service_information' field may be transmitted using multiple blocks, and the 'additional_service_information' field indicates the current index and the last index of the segment block.

A "current_index" field indicates an index describing a current block within the total number of blocks.

A "last_index" field indicates an index describing the last block within the total number of blocks.

A "length" field indicates the length of the additional service information.

The "user_data" field indicates the syntax of user-specific data and shall follow <tag><length><data>. Define tag values in Table 2.

[Table 2]

tag identifier 0 reserve 1 turbo channel information descriptor 2-255 TBD

If the tag value is '1', the 'user_data' field contains a turbo channel information descriptor which will be described later with reference to FIG. 15 .

FIG. 15 shows the structure of a 'Turbo_channel_information_description()' field according to an embodiment of the present invention. The structure of the "Turbo_channel_information_description()" field is similar to that of the "Turbo_channel_information" field shown in FIG. 13 .

FIG. 16A shows the structure of the turbo_channel_configuration( ) field shown in FIG. 10B according to an embodiment of the present invention.

The "turbo_channel_configuration()" field contains configuration information indispensable to the turbo channel. Similar to the 'turbo_channel_information' field shown in FIG. 13 , the 'turbo_channel_configuration()' field may contain important information such as physical decoding information, information indicating whether frame fragmentation exists, and information on the total number of turbo channels.

A 'selector_bits' field indicates whether there is frame fragmentation, a dispersed SRS channel, a turbo channel, or a 'Turbo_channel_descriptor_loop' field. Table 3 below shows the definition of the 'selector_bits' field according to the value of the 'selector_bits' field. In Table 3, "x" can be "0" or "1".

[table 3]

selector_bits value identifier 0B1xx frame fragmentation 0Bx1x Distributed SRS channel locations 0Bx0x turbo channel position 0Bxx1 Turbo_channel_descriptor_loop

A 'Turbo_channel_id' field indicates an identifier of a turbo channel. When the specific identifier of the turbo channel is included, this field is used for the identification of the turbo channel. However, if this field has a predetermined value, such as 0x1f, the descriptor shall be applied to all turbo channels. For example, when a field containing information on a frame group is updated and the 'Turbo_channel_id' field is 0x1f, the information on the frame group should be applied to the 'turbo_channel_configuration' field on all channels.

A 'start_frame_number' field indicates the number of start frames of a service transmitted in burst mode. A start frame is the first frame that will be received for service.

A 'frame_count' field indicates the total number of frames to be received for service in burst mode.

The "reserved" field is a reserved field for future use. The value of the "reserved" field is set to "1". In the current specification, the "reserved" field has the same function, so it will not be described here.

A 'turbo_cluster_size' field indicates a cluster size of an SRS stream dispersed in a plurality of sectors.

The 'is_enhanced' field indicates whether the current turbo channel contains enhanced data. If the value of this field is set to '1', it means that the current turbo channel contains enhanced data. In this case, the base channel and enhancement channel should share the same turbo channel ID. A receiver can receive both channels and provide them as one channel. For example, using the "scalable" video codec provides higher quality video when two channels are received than when a single channel is received.

The 'adaptive_time_slicing_flag' field indicates whether the current turbo channel supports adaptive time slicing. If the value of this field is set to "1", it means that the current turbo channel supports adaptive time slicing. Change the physical configuration according to this field.

A 'coding_rates' field indicates an index of a turbo channel coding rate.

A 'full_packet_flag' field indicates whether to send the first sector of the turbo stream through a null packet or a specific PID packet. If the value of this field is set to '1', it means that the first sector is carried by an empty packet having no AF header field or a specific PID packet. Similarly, if the value of this field is set to '0', the first sector is carried by AF.

A 'turbo_start_sector' field indicates a physical start position of a turbo stream.

A 'turbo_cluster_size' field indicates a cluster size of a turbo stream in a plurality of sectors.

The "Turbo_channel_descriptor_loop" field provides additional, optional information about the turbo channel. This field will be described in more detail later with reference to FIG. 17 .

FIG. 16B shows the structure of a 'turbo_channel_configuration()' field according to another embodiment of the present invention.

The structure of the "turbo_channel_configuration()" field shown in FIG. 16B is the same as that of the "turbo_channel_configuration()" field shown in FIG. 16A except for the "enhanced_protection_mode" field.

An 'enhanced_protection_mode' field indicates whether enhanced protection mode is supported. There is a case where errors can be easily corrected depending on the type of transmitted data or the communication environment. In this case, error correction can be easily performed by reducing the length of the payload in the packet and increasing the RS byte. If the value of this field is set to "1", the payload length of the transport packet is 168 bytes long, and the RS byte is 40 bytes. However, if the value of this field is set to '0', the payload length is 188 bytes long, and the RS byte is 20 bytes.

FIG. 17 shows the structure of the 'descriptor_loop()' field shown in FIG. 16A according to an embodiment of the present invention.

The "descriptor_loop()" field can enable signaling of additional information about each turbo channel. Changes in information, such as the number of frame groups, the duration of the time slicing with respect to the turbo channel, and the position of the turbo channel, shall be signaled by the "descriptor_loop()" field.

A "next_indicator" field is a 1-bit field and indicates the presence of a "descriptor_information" field. If the value of this field is set to '1', a 'descriptor_information' field follows. If the value of this field is set to '0', the 'descriptor_information' field does not exist in the 'descriptor_loop()' field.

A 'tag' field indicates an identifier of a 'descriptor_information' field, as defined in Table 4 below.

[Table 4]

tag describe 0 Frame_Group_Update 1 Frame_Slicing_Duration_Update 2 SRS_position_Update 3 Turbo_Channel_Position_Update 4-127 reserved for future use

A "length" field indicates the total length in bytes of the "descriptor_information" field.

The 'descriptor_information' field may be defined differently according to the value of the 'tag' field. The "descriptor_information" field defined in Table 4 will be described in more detail later with reference to FIGS. 18 to 21 .

FIG. 18 shows the structure of the 'frame_group_update' field when the value of the 'tag' field shown in FIG. 17 is set to '0'.

"frame_group_update" may be used for a change of a time segment of a time slice. That is, the 'frame_group_update' field may be used to update the total number of frame groups. The "frame_group_update" field may be signaled at least 6 seconds prior to the update. The information contained in this field shall be applied to all turbo channel configurations. When this field is received, the "sectorbits" field may be set to "0x001" indicating a frame group update, and the "Turbo_channel_id" field may be set to a predetermined value, for example, " 0x1f".

A 'next_update_offset' field indicates the total number of frames remaining before the number of new GOF (groups of frame) is applied. This field has an associated value based on the "TCC_next_update_offset" field described above. Therefore, the value of this field is changed when the TCC is updated. That is to say, the value of this field is not changed on a frame-by-frame basis, but this field is changed as the TCC version is changed, thereby reducing the number of times to update the TCC.

A "new_GOF" field indicates the total number of new GOFs.

FIG. 19A shows the structure of the 'Frame_Slicing_Duration_update' field according to an embodiment of the present invention when the value of the 'tag' field shown in FIG. 17 is set to '1'.

The 'Frame_Slicing_Duration_update' field is used when the number of frames constituting frame slices in the current turbo channel is changed. Equation (1) below can be used to calculate the pause duration when frame fragmentation is applied. In this case, updating is performed in units of the number of frames constituting the frame group.

(TCC_next_update+start_frame_number)*48.4ms+jittertime(1)

In Equation (1), "jittertime" means the setup time required for the physical layer, and "48.4ms" means the period for transmitting the VSB frame. However, the present invention is not limited to VSB frames. If the transmission time period is determined by another transmission frame and another frame group.

A 'new_start_frame_number' field indicates the number of a new start frame for a frame slice within a GOF.

A 'new_frame_count' field indicates the number of new end frames for a frame slice within a GOF.

FIG. 19B illustrates the structure of the 'Frame_Slicing_Duration_update' field when the value of the 'tag' field shown in FIG. 17 is set to '1' according to another embodiment of the present invention.

Equation (2) indicates the time required to obtain the first frame for a frame slice in the "descriptor_information" field, the syntax of which is shown in FIG. 19B:

(TCC_next_update_offset+next_update_offset)*48.4ms+jittertime(2)

The "descriptor_information" field shown in FIG. 19B is the same as that shown in FIG. 19A except for the "next_update_offset" field.

A 'next_update_offset' field indicates a position of a frame to which new frame fragmentation information is applied based on the 'TCC_next_update_offset' field.

FIG. 20A shows the structure of the 'SRS_position_update' field when the value of the 'tag' field shown in FIG. 17 is set to '2' according to an embodiment of the present invention.

The 'SRS_position_update' field is used when the position of the dispersed SRS is changed. The time point when the new location information is applied can be calculated based on the start correlation of .

The "start_frame_offset" field indicates the number of start frames within the new GOF to which the new SRS position will be applied.

A 'turbo_cluster_size' field indicates the size of a new turbo cluster in multiple sectors.

FIG. 20B illustrates the structure of the 'SRS_position_update' field when the value of the 'tag' field shown in FIG. 17 is set to '2' according to another embodiment of the present invention.

The "SRS_position_update" field is the same as that shown in FIG. 20A except for the "next_update_offset" field.

A "next_update_offset" field indicates a next update position to which subsequent values are applied.

The time point at which new location information is applied can be expressed by adding the value of the 'TCC_next_update_offset' field and the value of the 'next_update_offset' field. Alternatively, the value of the 'next_update_offset' field may be used as a relative value of the value of the 'TCC_next_update_offset' field.

FIG. 21A illustrates the structure of the 'turbo_channel_update' field when the value of the 'tag' field shown in FIG. 17 is set to '3' according to an embodiment of the present invention.

The "turbo_channel_update" field is used when updating the location of the turbo channel. This field shall be applied after reception of "TCC_next_update_offset" indicating that a new GOF has been received.

A 'start_frame_offset' field indicates the number of start frames within a new GOF. From this frame a new "turbo_cluster_size" field can be applied.

The 'is_enhanced' field indicates whether the current turbo channel contains enhanced data. If the value of this field is set to '1', it means that the current turbo channel contains enhanced data. In this case, the base channel and the enhancement channel may be the same turbo channel ID as described above.

A 'coding_rates' field indicates an index of turbo channel coding rates.

A 'full_packet_flag' field indicates whether the first sector in the turbo stream is transmitted through a null packet or a specific PID packet. If the value of this field is set to "1", it means that the first sector of the turbo stream is carried by an empty packet without the AF header field or a specific PID packet. If the value of this field is set to '0', the first sector is carried through the AF header field.

A 'turbo_start_sector' field indicates a physical start position of a turbo stream.

A 'turbo_cluster_size' field indicates a cluster size of a turbo stream in a plurality of sectors.

FIG. 21B illustrates the structure of the 'turbo_channel_update' field when the value of the 'tag' field shown in FIG. 17 is set to '3' according to another embodiment of the present invention.

The "turbo_channel_update" field shown in FIG. 21B is the same as that shown in FIG. 21A except for the "next_update_offset" field, the "adaptive_time_slicing_flag" field, and the "enhanced_protection_mode" field.

A "next_update_offset" field indicates an update position to which subsequent values are applied. The time point at which new location information is applied can be expressed by adding the value of the 'TCC_next_update_offset' field and the value of the 'next_update_offset' field. Otherwise, the value of the 'next_update_offset' field may be used as a related value of the 'TCC_next_update_offset' field.

The 'adaptive_time_slicing_flag' field indicates whether the current turbo channel supports adaptive time slicing. If the value of this field is set to "1", it means that the current turbo channel supports adaptive time slicing. The physical configuration of the 'turbo_channel_update' field is changed according to this field.

The 'enhanced_protection_mode' field indicates whether the current turbo channel supports enhanced protection mode. If the value of this field is set to "1", it means that the current turbo channel supports the enhanced protection mode.

For example, if the value of this field is set to "1", the length of the payload in the transport packet may be 168 bytes, and the length of the RS byte may be 40 bytes to provide enhanced protection. However, if the value of this field is set to '0', the payload length may be 188 bytes, and the RS byte length may be 20 bytes.

FIG. 22A shows the structure of a 'BD_Packet' field according to an embodiment of the present invention.

The 'BD_Packet' field should be used to transmit additional information on turbo flow, such as IP mapping table and turbo channel update information. This field shall be applied to all turbo channels and may be carried within several fragments.

The "first_last" field consists of two bits and specifies whether the packet is the first packet or the last packet, as defined in Table 5.

[table 5]

value describe 00 sequence tundish 01 sequence last packet 10 sequence first pack 11 only one package

A "padding_flag" field indicates whether padding bytes exist.

A 'BD_version' field consists of three bits and designates a version number of a Broadcast Descriptor (BD). This version number shall be increased by 1 modulo 8 whenever the BD is updated.

A "padding_length" field indicates the number of bytes of padding in the "padding_flag" field.

The "padding_byte" field has one or more 8-bit values set to "0xFF" that can be inserted by an encoder. This field is discarded by the decoder.

A "BD_Fragment" field contains a BD fragment. That is, a BD is divided into a plurality of fragment blocks and transmitted through a 'BD_Fragment' field. BD will be described later with reference to FIG. 23 .

FIG. 22B shows the structure of a 'BD_Packet' field according to another embodiment of the present invention.

The "BD_Packet" field shown in FIG. 22B is the same as that shown in FIG. 22A except for the "System_time_flag" field and the "System_time" field.

A 'System_time_flag' field indicates whether system time information exists. In this specification, the "System_time" field contains system time information. If the value of this field is set to '1', it means that the 'System_time' field exists.

A "System_time" field indicates a system time. System time may be expressed based on absolute time, such as UTC, which is the same regardless of location, but may be expressed based on time influenced by the sending system. The system time can be used to correct the time in the terminal. In this way, the difference (offset time) according to the location can be used. The system time is used to make the service provider's time the same as the service receiver's time, or to correct the times. For example, information such as an electronic service guide (ESG) may contain time information, such as when each service starts or ends. In this case, the broadcast receiving device can start or end the service to be provided to the user precisely according to the schedule by using the system time information.

FIG. 23 shows the structure of a Broadcast Descriptor (BD) according to an embodiment of the present invention.

A BD is fragmented into several BD segments and mapped to a 'BD_Packet' field.

A 'number_of_BD' field indicates the total number of 'broadcast_descriptor_information' fields to be described later.

A 'tag' field indicates the type of data included in the 'broadcast_descriptor_information' field. According to the data type of the value of this field as follows:

[Table 6]

tag describe 0 prohibit 1 Channel_info_update 2 IP_mapping_descriptor 3-127 reserve

A 'length' field indicates the length of the 'broadcast_descriptor_information' field.

The type of data in the "broadcast_descriptor_information" field is determined according to Table 6. The structure of the 'broadcast_descriptor_information' field according to data type will be described later with reference to FIGS. 24 and 25 .

FIG. 24A shows the structure of the 'Channel_info_update()' field when the value of the 'tag' field shown in FIG. 23 is set to '1' according to an embodiment of the present invention.

"Channel_info_update" is used to update turbo channel information. This field indicates when new turbo channel information is applied. This field may include version and turbo channel configuration information.

An 'update_frame_counter' field indicates a relevant frame number based on the reference frame number to which the new TCC is applied.

A "new_TCC_version" field indicates a version of information of TCC. This field shall be the same as the "TCC_version" field present in the SIC when an update is performed.

A 'number_of_turbo_channel' field indicates the number of subsequent new_turbo_channel_configuration() fields.

The structure of the 'new_turbo_channel_configuration()' field may be the same as that of the above-described 'turbo_channel_configuration()' field.

FIG. 24B illustrates the structure of the 'Channel_info_update()' field when the value of the 'tag' field shown in FIG. 23 is set to '1' according to another embodiment of the present invention.

The "Channel_info_update()" field shown in FIG. 24B is the same as that shown in FIG. 24A except for the "next_update_offset" field.

A 'next_update_offset' field indicates a frame to which a new TCC will be applied. This field has an associated value based on the 'BD_next_update_offset' field.

FIG. 24C shows the structure of a 'Channel_Info_update()' field according to another embodiment of the present invention.

The "Channel_info_update()" field shown in FIG. 24C is the same as that shown in FIG. 24B except for the "update_frame_counter" field and the "new_TCC_version" field.

An 'update_frame_counter' field indicates a frame to which a new TCC will be applied.

A "new_TCC_version" field indicates version information of TCC. The version value may be the same as that of the TCC in the SIC.

FIG. 25A shows an IP mapping descriptor when the value of the 'tag' field shown in FIG. 23 is set to '1' according to an embodiment of the present invention.

The IP mapping descriptor provides mapping information between IP flows and turbo channels. At least one of turbo channel information, an IP address, a MAC address, and a brief description of IP may be included in the IP mapping descriptor. In the current embodiment, an IP mapping table (IMT) indicates an IP mapping descriptor.

An 'Extended_version' field indicates whether to update the IMT. If the value of this field is set to '1', it means that the IMT is not updated even if the 'BD_version_number' field is updated.

A "Number_of_IP" field indicates the total number of IP flows.

A 'Reference_ch_flag' field indicates whether a current channel is a reference channel. If the value of this field is set to '1', it means that the current channel is a reference channel. An example of a reference channel may be an aggregate ESG channel. ESG information is a large amount of information, and thus, in general, ESG information may not be fully included in one channel. In this case, the broadcast receiving device may collect all ESG information only through the reference channel. Therefore, the amount of ESG information transmitted through the independent channel is smaller than the amount of ESG information transmitted through the reference channel, thereby allocating higher bandwidth to the content.

A 'turbo_channel_id' field indicates an identifier of a current turbo channel.

The 'LMT_index_number' field indicates the position of the IP flow in the turbo channel. IP streams are mapped to sub-data channels in the turbo channel.

A 'Number_of_IP_ch_descriptor' field indicates the number of subsequent 'IP_channel_description' fields.

The 'IP_channel_description' field contains additional information of the IP channel. This field will be described in detail later with reference to FIG. 26 .

FIG. 25B shows an IP mapping descriptor according to another embodiment of the present invention.

The IMT shown in FIG. 25B is the same as that shown in FIG. 25A except for the "number_of_channel" field and the "VMI" field.

A 'number_of_channel' field indicates the total number of turbo channels or sub data channels.

A "VMI (Virtual Map ID)" field indicates an identifier of a sub-data channel in a turbo channel.

FIG. 26 shows the structure of the 'IP_channel_description' field shown in FIG. 25A according to an embodiment of the present invention.

The "IP_channel_description" field is used to transmit the above-mentioned additional information on the IP channel.

The "tag" field is used to identify data included in the "IP_channel_table" field. According to the data type of the value of this field as follows:

[Table 7]

tag describe 0 prohibit 1 IP_address_table 2 MAC_address_table 3 Text_description_table 4-255 reserve

The "length" field indicates the length of the "IP_channel_description" field in bytes.

The 'IP_channel_table()' field indicates IP channel information such as IP address and IP interface. This field will be described in detail later with reference to FIGS. 27 to 29 .

FIG. 27A shows the structure of the 'IP_address_table' field when the value of the 'tag' field shown in FIG. 26 is set to '1' according to an embodiment of the present invention.

The 'IP_version' field indicates IP version 4 or IP version 6, but the present invention is not limited thereto. That is, other versions may be retained.

IPv4_address and IPv6_address are described in detail in RFC791 and RFC2460. Also, Port_number is described in more detail in RFC793 for TCP and RFC768 for UDP.

FIG. 27B shows the structure of the 'IP_address_table' field when the value of the 'tag' field shown in FIG. 26 is set to '1' according to another embodiment of the present invention.

The "IP_address_table" field shown in FIG. 27B is the same as that shown in FIG. 27A except for the "Port_number_usage_flag" field.

A 'Port_number_usage_flag' field indicates whether there is a port number. In the current embodiment, whether there is a port number is indicated in the "IP_address_table" field.

FIG. 28 illustrates the structure of the 'MAC_address_table' field when the value of the 'tag' field shown in FIG. 26 is set to '2' according to an embodiment of the present invention.

MAC_address is described in detail in RFC1042.

FIG. 29 illustrates a structure of a 'Text_description_table' field when the value of the 'tag' field shown in FIG. 26 is set to '3' according to an embodiment of the present invention.

The "Text_description_table" field provides a text description about the IP channel.

An 'ISO_639_language_code' field indicates that the subsequent text information is recognized by an ISO639 language code. In the current embodiment, the "description" field contains textual information.

The "description" field provides a text description of the IP channel. Encode the textual description in IOS8859-1 characters.

The multiplexing structure of the MCAST system will now be described.

A transmission frame includes multiple turbo channels, and each turbo channel includes multiple sub-channels. Additionally, each sub-channel may contain sub-data channels. The same type of data is sent over subchannels. A sub-data channel can be the service itself or a service component.

Various types of data or only specific types of data can be multiplexed and transmitted through MCAST. An example of the former case, signaling data, real-time media data, IP data and object data can be multiplexed and sent. An example of the latter case, only signaling data and IP data can be sent. In the latter case, sub-data channels can be classified by differences from IP compression types.

Signaling data is sent via 168 or 188 (or 187) byte MCAST transport packets. The length of the transport packet is variable. The LMT specifies the location and number of all sub-data channels. In addition, the LMT may specify the location of data mapped to a sub-data channel or the location of an IP flow in a turbo channel.

Subsequent LMTs may exist in transport packets in a turbo data channel, or periodically or aperiodically in packets at specific locations. For example, the LMT may exist in the first signaling sub-data channel or in the MCAST packet header. In addition, LMT may exist in every frame, but when the position of the service component is fixed in the frame, the LMT may not be transmitted.

The LIT contains service configuration information, as well as the number and identifier of each sub-data channel.

While conventional broadcasting systems search for desired programs through PID filtering, MCAST systems can directly provide users with desired services by detecting the exact location of data constituting each service on a frame-by-frame basis via LMT and/or LIT without performing filtering .

FIG. 30A shows a MCAST multiplexing structure according to an embodiment of the present invention.

In detail, FIG. 30A shows a case where signaling data, implementation data, IP data, and object data are multiplexed. A frame is divided into a service access area for accessing a service (eg, LMT or LIT) and a data area for data transmission. The MCAST transmission frame according to an embodiment of the present invention may be transmitted while being inserted into a transmission frame of another broadcast system, may be transmitted alone, or may be transmitted while being one-to-one mapped to a transmission frame of another broadcast system. In the current embodiment, the MCAST transmission frame is sent through the ATSC transmission frame.

As mentioned above, the MCAST transmission frame is divided into sub-channels according to the data type. The sub-channel is a sub-divided channel by physically dividing the turbo channel that transmits the data stream according to the data type. In FIG. 30A, subchannels are divided again into subchannels for real-time data type, subchannels for IP data type, and subchannels for object data type.

Sub-channels can be divided into independent sub-data channels. A sub-data channel includes more than one transport packet. The sub-data channel consists of a group of 188 bytes (or 168 bytes) MCAST transport packets within the ATSC frame. Packet length can be variable.

FIG. 30B shows a MCAST multiplexing structure according to another embodiment of the present invention.

Specifically, FIG. 30B shows a case where only signaling data and IP data are multiplexed. When the LMT information is included in a SIC or IP data type sub-channel, the LMT information may be transmitted.

FIG. 31A shows the MCAST frame structure and LMT according to an embodiment of the present invention.

FIG. 31A shows the subchannels shown in FIG. 30A in more detail. Referring to FIG. 31A, the MCAST transmission frame is composed of signaling subchannels, real-time media subchannels, IP subchannels and object subchannels. That is, at least one of three types of data, such as real-time media data, IP data, and object data, is transmitted through the MCAST transport frame.

Each sub-channel includes sub-data channels.

The real-time media sub-channel transmits real-time media data such as A/V streams. In the current embodiment, the real-time media sub-channel is composed of sub-data channel 1 (R-1) and sub-data channel 2 (R-2). In the current embodiment, the IP sub-channel transmits IP data and includes a sub-data channel (IP-1). The object sub-channel transmits object data used in real time or received and used after being stored in a broadcast service receiving device. In the current embodiment, the object sub-channels include sub-data channel 1 (O-1), sub-data channel 2 (O-2), sub-data channel 3 (O-3), and sub-data channel 4 (O-4).

A service contains more than one service component. Therefore, all service components of a service must be received in order to provide the service. A sub-data channel is a path through which only one service component is transmitted. Therefore, in order to access a service, it is necessary to know the positions of all the sub-data channels respectively transmitting the service components.

Service access information (such as LMT or LIT) for accessing service components constituting the service is included in the header portion of the transport packet. The transport packet may include at least one of a 'header' field, a 'LMT' field, a 'LIT' field, and a payload.

The LMT field provides structure and physical location information of the sub-data channel, which will be described in more detail later with reference to FIG. 34 .

FIG. 31B shows a MCAST frame structure and LMT according to another embodiment of the present invention.

Referring to FIG. 31B, only IP data including VMI information to identify a sub data channel is transmitted through the MCAST frame.

It is important to detect the position of the sub-data channel in the MCAST frame, this information is included in the above-mentioned LMT. The position of the sub-data channel is detected using the offset in the frame. However, when a sub-data channel is changed, for example, when a sub-data channel is added or deleted, the change needs to be recognized. If the sub-data channel can be identified by a virtual map identification (VMI), changes in the sub-data channel can be easily checked. The VMI will be described in detail later by referring to FIG. 32 .

FIG. 32 illustrates a method of checking a change in a sub data channel by using Virtual Map Identification (VMI) according to an embodiment of the present invention.

The VMI according to an embodiment of the present invention is included in signaling information such as LMT, LIT or IMT. VMI is an identifier for identifying a sub data channel. Whether the sub data channel is changed can be determined by using the VMI.

Referring to FIG. 32 , in the previous frame, sub data channels constituting Service 1 are Audio 1 , Video 1 , and Image 1 . Values 1, 3, and 5 are respectively assigned to these sub-data channels as VMI values.

In subsequent frames, the sub-data channel associated with picture 1 is canceled. If the position of the sub-data channel is specified only by the offset in the frame, it is unreasonable to use the offset as an identifier since the offset of the sub-data channel is different on a frame-by-frame basis. However, if VMIs are respectively assigned to the sub data channels as unique identifiers, the changed sub data channels can be accurately identified.

FIG. 33 is a flowchart illustrating a method of obtaining a service by using a VMI according to an embodiment of the present invention.

In operation S3310, LMT and/or LIT are obtained.

In operation S3320, the VMI of the sub-data channel transmitting the service components constituting the requested service is checked.

In operation S3330, the IMT is obtained.

In operation S3340, the VMI in the current turbo channel is checked.

In operation S3350, data is obtained by accessing a desired sub data channel.

FIG. 34A shows the structure of an LMT according to an embodiment of the present invention.

The LMT according to an embodiment of the present invention includes a 'typebitmap' field, a 'versionnumber' field, and at least one 'subdatachannelnumber' field.

The 'typebitmap' field indicates the type of data included in the MCAST transmission frame transmitted at a predetermined time interval. Assume that object data, real-time media data, and IP data are transmitted through MCAST transport frames.

The "typebitmap" field contains three bits each of which may indicate the presence or absence of the type of data. For example, assuming that the first bit indicates whether there is real-time media data in the frame, the second bit indicates whether there is IP data in the frame, and the third bit indicates whether there is object data in the frame, the presence and bit value is "1" corresponding data. Therefore, if the value of the 'typebitmap' field is '111', it means that all types of data exist, and if the value of the 'typebitmap' field is '011', it means that IP data and object data exist.

A "versionnumber" field indicates a version of the LMT.

A 'subdatachannelnumber' field indicates the total number of subdata channels for each type of data. The value of this field corresponds to the total number of 'channelpointer' fields indicating physical addresses of sub data channels.

Referring to FIG. 34A, since there is a 'channelpointer' field corresponding to real-time media data, there is a sub-data channel transmitting real-time media data.

Each "channelpointer" field indicates a physical location of a sub-data channel. The number of indicators can be assigned consecutively to the "channelpointer" field. The numbers consecutively assigned to the "channelpointer" field in the LMT are called "LMT pointer number". The LMT index number may not be included in the 'channelpointer' field, but is continuously assigned to the 'channelpointer' field when the broadcast receiving device interprets the 'LMT' field. LMT index numbers are allocated to refer to the channel pointers of the subchannels making up the respective services in the LIT.

FIG. 34B details the structure of the LMT of FIG. 34A according to an embodiment of the present invention.

If it is assumed that the value of the "typebitmap" field is "011", the value of the "subdatachannelnumber" field for IP data is "2", the value of the "subdatachannelnumber" field is "3", and the "channelpointer" fields 1 and 2 indicate the For the location of the sub-data channel for IP data, the "channelpointer" fields 3 to 5 indicate the location of the sub-data channel for IP data. If the LMT indicator numbers are assigned consecutively to these "channelpointer" fields, the LMT indicator numbers 1 to 5 are assigned to the "channelpointer" fields 1 to 5, respectively.

35A and 35B illustrate the structure of an LMT according to an embodiment of the present invention.

A "tag" field indicates whether LMT information is to be included. In the current embodiment, LMT information is actually included in the 'LMT_information' field.

A 'length' field contains eight bits and indicates the length of the 'LMT_information' field.

The 'LMT_information' field specifies the location of the sub-data channel in the sub-channel and signaling data (SD) in the signaling sub-channel. The "LMT_information" field will be described later with reference to FIG. 36C .

FIG. 36 shows the structure of the 'LMT_information' field shown in FIG. 35 according to an embodiment of the present invention.

A 'LMT_coverage' field indicates the number of subsequent LMTs that are the same as the current LMT. For example, if the value of the "version_number" field which will be described later is "1" and the value of the "LMT_coverage" field is "001", it means that there is an LMT whose version is "1". Similarly, if the subsequent LMT is different from the current LMT, the value of this field is set to '0'.

A "version_number" field contains four bits and indicates the version of the LMT. The version number is incremented by 1 modulo 16 whenever a field related to the LMT changes.

A 'LMT_boundary' field indicates the position of a packet covered by the current LMT. If the 'LMT_boundary' field can represent a packet covered by the current LMT, its value is not limited. For example, the value of this field may indicate the offset or total number of packets covered by the current LMT.

A 'SD_end_offset' field is an 8-bit field indicating an end position of a signaling subchannel. If no signaling data is contained in the signaling subchannel, the value of this field shall be set to '0'.

A 'number_of_IP' field indicates the number of IP sub-data channels.

The 'IP_end_offset' field is an 8-bit field indicating the end position of the IP sub-data channel within the IP sub-channel. If no IP data is contained in the first IP sub-data channel, the value of this field shall be set to '0'.

37A and 37B illustrate structures of LMT and 'LMT_information' fields according to another embodiment of the present invention.

Referring to FIG. 37A , the LMT indicates end offset information of a sub data channel. The sub-data channels respectively transmit four types of data: signaling data, real-time media data, IP data, and object data, using an end offset to express the position of the sub-data channels according to types.

The start value of each sub-data channel is always "1", and numbers are assigned independently to the sub-data channels according to the sub-data type. However, if there is no first sub-data channel, the value of the 'next_indicator()' field is set to '0'.

If there is no valid data packet temporarily present in one or more packets, the offset of the corresponding sub-data channel is the same as that of the previous packet. The offset of the first sub-data channel is set to "0".

Each field is defined with reference to FIG. 37B.

A 'SEP_flag' field indicates whether a Signal Encapsulation Packet (SEP) exists.

A 'SEP_end_offset' field is an 8-bit field, and indicates an end position of a SEP sub-data channel when the 'SEP_flag' field is '1'.

The first 'next_indicator' channel indicates whether a 'real_time_end_offset' field is still present. If the value of this field is '0', the 'real_time_end_offset' field no longer exists, and if the value of this field is '1', it means that the 'real_time_end_offset' field still exists.

A 'real_time_end_offset' field is a 7-bit field indicating an end position of a real-time sub-data channel transmitting real-time media data. If the current MCAST package does not have real-time data, the value of this field shall be set to "0", or this field does not exist.

The second "next_indicator" channel indicates whether there is another "IP_end_offset" field. If the value of this field is '0', the current 'IP_end_offset' field is the last one, and if the value of this field is '1', it means that another 'IP_end_offset' field exists.

The 'IP_end_offset' field is a 7-bit field indicating the end position of the IP sub-data channel in which IP data is transmitted. If there is no IP sub-data channel in the current MCAST package, the value of this field shall be set to "0", or this field does not exist.

The third 'next_indicator' channel indicates whether there is another 'object_end_offset' field. If the value of this field is '0', the current 'object_end_offset' field is last, and if the value of this field is '1', another 'object_end_offset' field exists.

An 'object_end_offset' field is a 7-bit field indicating an end position of an object sub-data channel in which object data is transmitted. If the object sub-data channel does not exist in the current MCAST package, the value of this field shall be set to "0", or this field does not exist.

FIG. 38 shows the structure of an LMT according to another embodiment of the present invention.

The 'LMT_coverage' field indicates the number of subsequent LMTs that are the same as the current LMT. If the subsequent LMT is different from the current LMT, the value of this field is set to '0'.

A "version_number" field is a two-bit field indicating the version of the LMT. The version number is incremented by 1 modulo 4 whenever one of the fields related to the LMT changes.

A 'selector_bits (SEP, Reserved, IP)' field indicates the type of sub-data channel that exists. In FIG. 38, since it is assumed that only IP data is transmitted through the MCAST frame, the second bit is a reserved bit. If the first bit is "1", it means that the SEP sub-data channel exists, and if the third bit is "1", it means that the IP sub-data channel exists.

A 'LMT_length' field indicates the length of the LMT field.

A 'LMT_boundary' field indicates the number of offsets of packets covered by the current LMT.

A 'numberofSEP' field is an eight-bit field indicating the total number of SEP sub-data channels.

A 'VMI' field indicates an identifier of a sub data channel, which is unique in a turbo channel.

A 'SEP_end_offset' field is an 8-bit field indicating an end position of a SEP subchannel.

A 'num_of_IP' field indicates the number of IP sub-data channels.

An 'IP_end_offset' field is an 8-bit field indicating an end position of an IP sub-data channel. The "SEP_end_offset" field and the "IP_end_offset" field are calculated by counting packets based on the packets containing the LMT. In another embodiment of the present invention, the offset can be calculated in bytes.

FIG. 39 shows the structure of MCAST frame and LIT according to an embodiment of the present invention.

The LIT may be located on a signaling sub-channel that is first located in a turbo channel that contains data within an ATSC frame. Each service contains one or more service components, and LIT indicates a list of service components. That is, the LIT can specify service component information. The position of the sub-data channel is detected from the above-mentioned LMT.

LIT is closely related to LMT and can exist in every frame.

FIG. 40 shows the structure of an LIT according to an embodiment of the present invention.

A 'service_number' field indicates the number of services included in the MCAST frame according to the present invention.

A "version_number" field indicates a version of the LIT.

Each service field contains a 'serviceidentifier' field and at least one 'LMTindexnumber' field. The "LMTindexnumber" field is assigned to the "channelpointer" field as described in FIG. 34B. Accordingly, the broadcast receiving device can detect the physical address of the sub-data channel used to transmit the desired service in the frame by interpreting the LIT.

41A and 41B illustrate the structure of an LIT according to another embodiment of the present invention.

When a plurality of sub-data channels form one service, the LIT specifies the structure of the service. The location of the sub-data channel may be determined through offset information of the sub-data channel included in the LMT. That is, each component can be identified by an accumulation counter for each sub-data channel.

A 'num_of_service' field is a 6-bit field indicating the number of services available in the current frame.

A "version_number" field is a 10-bit field indicating a version number of a field related to the LIT. The version number shall be incremented by 1 whenever one of the fields related to the LIT changes.

A "service_ID" field is an 8-bit field that identifies a service in the turbo channel.

A 'next_indicator' field is a 1-bit field indicating whether there are additional 'next_indicator' field and 'LMT_index_number' field. If the value of this field is '1', it means that there are additional 'next_indicator' field and 'LMT_index_number' field, and if the value of this field is '0', the 'next_indicator' field and 'LMT_index_number' field no longer exist.

The "type_info" field indicates the type of word data channel indicated by the "LMT_index_number" field, defined as follows according to the value of this field:

[Table 8]

value describe 00 reserve 01 Real-time data 10 IP data 11 object data

A 'LMT_index_number' field is a 7-bit field indicating an array index of each LMT. The value of this field is incremented independently from the "type_info" field. That is, referring to FIG. 40, the number of LMT indices continues to increase regardless of the type of sub-data channel. However, referring to FIG. 41, the number of LMT indices increases independently according to the type of sub-data channel.

For example, assume that two channel pointers corresponding to the IP sub-data channel and three channel pointers corresponding to the object sub-data channel exist in the MCAST frame. In this case, referring to FIG. 40, LMT index numbers 1 to 5 are consecutively assigned to channel pointers, and thus LMT index numbers 3 to 5 are respectively assigned to channel pointers corresponding to object sub-data channels. However, referring to FIG. 41, the number of LMT pointers is independently increased according to the type of the sub-data channel, so that the number of LMT pointers from 1 to 3 is assigned to the channel pointers corresponding to the object sub-data channel, respectively.

FIG. 42A is a flowchart illustrating a method of providing a service using LMT and LIT according to an embodiment of the present invention.

Referring to FIG. 42A, the LMT field is transmitted at a fixed interval and located in a predetermined area of the MCAST frame. In operation S4201, when receiving a transmission frame, the broadcast service receiving device obtains and interprets a signaling packet including service access information, the signaling packet being located at a predetermined area of the transmission frame.

In operation S4203, the broadcast service receiving device determines whether the LMT field exists in the signaling packet. If it is determined in operation S4203 that no LMT field exists in the signaling packet, it is determined in operation S4205 whether the previous LMT field has been stored in the broadcast service receiving device. If it is determined that the previous LMT field exists in the broadcast service receiving device in operation S4205, the method proceeds to operation S4211.

If it is determined that no LMT field exists in the signaling packet in operation S4203, the broadcast service receiving device determines whether a version of the LMT field has been updated by using version information included in the LMT field in operation S4207. If it is determined whether the version of the LMT field has been updated in operation S4207, the LMT field is interpreted in operation S4209. Information on the sub-data channel is obtained by interpreting the LMT field at operation S4209.

In operation S4211, the broadcast service receiving device determines whether the LIT field exists in the signaling packet. If it is determined in operation S4211 that the LIT field does not exist, it is determined in operation S4213 whether the previous LIT field exists in the broadcast service receiving device. In operation S4213, if it is determined that the previous LMT field exists, the method proceeds to operation S4219.

In operation S4211, if it is determined that the LIT field exists in the signaling packet, it is determined whether the version of the LIT field is in operation S4215. Link information about each service, that is, service configuration information is obtained by interpreting the LIT field in operation S4217.

In operation S4219, a service is obtained from the result of interpretation of the LMT field and the LIT field, and then processed.

FIG. 42B is a flowchart illustrating a method of providing a service using LMT and LIT according to another embodiment of the present invention.

Referring to FIG. 42B, an LMT includes 'LMT_coverage', and thus, even when a packet including an LMT cannot be received due to an error or the LMT is not inserted periodically, the location of the subsequent LMT can be detected. Therefore, the position of the LMT and the period at which the LMT is inserted into the transport field change. Operations in FIG. 42B indicated by the same reference numerals as in FIG. 42A are the same as those in FIG. 42A , and thus detailed description thereof is omitted.

Referring to FIG. 42B , in operation S4220, an LMT is extracted from the MCAST frame according to LMT pointer information extracted from a previous LMT. The LMT pointer information indicates the location of the subsequent LMT. Therefore, even when the insertion of the LMT into a predetermined area of the transmission frame fails, the LMT can be easily extracted from the transmission frame.

In operation S4203, it is determined whether the LMT field exists in the location indicated by the LMT pointer information. In operation S4203, if it is determined that the LMT field exists, the method proceeds to operation S4207. In operation S4203, if it is determined that there is no LMT field, the method proceeds to operation S4230. The absence of the LMT field in the position indicated by the LMT pointer information indicates a case where the LMT field is omitted and a case where an error is generated in the LMT field.

In operation S4230, it is determined whether the previous LMT field is available based on the information about the total number of LMTs of the same version included in the previous LMT field. The fact that the previous LMT field is available means that it can be used continuously. In operation S730, if it is determined that the previous LMT field is available, the method proceeds to operation S4211.

The structure of transmission information according to data types will now be described.

First, in the case of real-time rich services, the PSI of MPEG-2 and ATSC must be obtained and decoded to decode the multimedia elementary stream in the broadcasting system. Subsequently, the decoder must wait to receive the frame to be decoded first. Subsequently, the user can browse the video. In MCAST, important decoding information is encoded as an information descriptor included in each multimedia elementary stream.

In this case, decoder configuration information (DCI) and multimedia data can be simultaneously transmitted for high-speed access as described above. That is, DCI is inserted into an I frame and then transmitted. The DCI has been described above with reference to FIG. 4 .

FIG. 43 shows the structure of object transfer information according to an embodiment of the present invention.

Referring to FIG. 43 , an 'Object_Delivery_information' field contains signaling information for delivering an object. An 'Object_Delivery_information' field includes an effective date of an object, parameters for AL-FEC, and additional descriptors. Directory components are objects or other directories.

The 'Object_Delivery_information' field may be sent through a Signaling Encapsulation Packet (SEP).

A "directory_information_flag" field indicates whether a directory exists.

Object information can be expressed in a tree directory. If the value of the 'directory_information_flag' field is '1', it shall be understood that a directory exists.

A 'number_of_objects' field indicates the total number of objects transmitted through the 'Object_Delivery_information' field.

A "number_of_directory" field indicates the total number of directory information. In the current embodiment, the "directory_information" field contains directory information.

A "directory_information" field contains directory information, which will be described in detail later with reference to FIG. 44 .

An "object_id" field indicates an identifier of an object.

An 'expire_time_flag' field indicates whether an object has an expiration time.

A 'LMT_index_number' field indicates an index number of sub-data channels classified according to data types.

When objects are transmitted in the same sub-data channel, the 'object_extension_id' field serves as an additional identifier for multiple objects.

An 'AL-FEC_mode' field indicates an AL-FEC mode. Examples of AL-FEC modes according to the value of this field are as follows:

[Table 9]

value model 0 MCAST_AL_FEC 1-15 reserve

A "total_length" field indicates the length of an object in bytes.

The "time_table" field contains time information that objects are not allowed to be used after their expiration time. This field will be described in detail later with reference to FIG. 45 .

An "encoding_mode" field indicates an encoding mode used by AL-FEC. Examples of encoding modes according to the value of this field are as follows:

[Table 10]

value describe(n,k) 0 (2880, 2304) 1 (1920, 1536) 2 (960,768) 3-15 reserve

A 'padding_length' field indicates the padding length in the last source block of the object.

A "number_of_descriptors" field indicates the number of consecutive "descriptor" fields.

The "tag" field indicates the data type of the object. In the current embodiment, this field indicates the data type included in the "descriptor" field. Examples of data types according to the value of this field are as follows:

[Table 11]

value describe(n,k) 0 prohibit 1 Content_name_description 2 Mime_type_description 3-15 reserve

The "length" field indicates the length of the "descriptor" field in bytes.

A "descriptor" field indicates a descriptor according to a value of the "tag" field. The "descriptor" field according to the value of the "tag" field will be described later with reference to FIGS. 46 and 47 .

FIG. 44 shows the structure of the 'directory_information' field shown in FIG. 43 according to an embodiment of the present invention.

A "number_of_directory" field indicates the number of directories.

A "directory_id" field indicates an identifier of a directory.

A "directory_name_length" field indicates the length of the directory name in bytes.

A "directory_name" field indicates a directory name encoded in ISO8859-1 characters.

A "number_of_components" field indicates the number of components included in each directory.

The "object_id, directory_id" field indicates an identifier of an object or other directory.

FIG. 45 shows the structure of the 'time_table' field shown in FIG. 43 according to an embodiment of the present invention.

The "years" field indicates years. Expresses how much time has passed since a specific point in time. For example, FIG. 45 shows the structure of the 'time_table' field shown in FIG. 43 according to an embodiment of the present invention.

The "years" field indicates years. Expresses how much time has passed since a specific point in time. For example, if 1970 is the reference year and the value of this field is "0", it means 1970.

The "months" field indicates a month from January to December.

The "days" field indicates days.

The "hours" field indicates an hour from one hour to twenty-four hours.

The "minutes" field indicates one minute from one minute to sixty minutes.

FIG. 46 shows the structure of the 'content_name_descriptor' field when the value of the 'tag' field shown in FIG. 43 is set to '1' according to an embodiment of the present invention.

A "content_name_length" field indicates the length of the content name in bytes.

A "content_name" field indicates a content name encoded in ISO8859-1 characters.

FIG. 47 illustrates the structure of the 'mime_type_description' field when the value of the 'tag' field shown in FIG. 43 is set to '2' according to an embodiment of the present invention.

A "mime_type_length" field indicates the length of the mime type in bytes. ("mime" stands for Multipurpose Internet Mail Extensions???)

A "mime_type" field indicates a mime type. This field is set to the encoded characters of any media type registered with IANA (see RFC2045, RFC2046 and http://www.iana.org/assignments/media-typs for more details).

FIG. 48 shows the relationship between encapsulated packets and transport packets in the MCAST system according to an embodiment of the present invention.

In the MCAST system, the transport layer is divided into encapsulation layer and packing layer. The encapsulation layer is responsible for segmenting the application data, and the transport layer divides the encapsulation packets into MCAST transport packets.

More specifically, the encapsulation layer will accommodate all types of application data encapsulation for the A-VSB transport method. That is, a wrapper having a structure suitable for application data is created in a format suitable for application data. Application data includes real-time media data, IP data, object data and signaling data. A wrapper has a specific structure according to the type of application.

The packing layer divides the encapsulated packets generated from the encapsulating layer into at least one transport packet. The size of the transport packet may be determined differently, for example, 168 bytes or 188 bytes.

The payload of MCAST packets may be sent continuously. That is, a part of capsules or all of two or more capsules can be included in one MCAST package. According to the present invention, the "first_last" field and the "pointer_field" field are used to indicate this when saving bits.

[Table 12]

A 'pointer_field' field indicates whether the MCAST transport packet includes two or more encapsulated packets. If the value of this field is '1', it means that two or more encapsulated packets exist in the MCAST transport packet. In the current embodiment, the value of this field is '1' so that two or more encapsulated packets are included in the MCAST transport packet.

A 'first_last' field indicates whether the start and end of the encapsulated packet are included in the MCAST transport packet. For the convenience of explanation, the former packet and the latter packet are respectively referred to as the first packet and the second packet from two or more consecutive packets. If two or more encapsulated packets are included in the MCAST transport packet, the end of the first encapsulated packet and the start of the second encapsulated packet shall be included in the MCAST transport packet.

The first bit of the 'first_last' field indicates whether the start of the first encapsulated packet is included in the MCAST transport packet, and the second bit of the 'first_last' field indicates whether the end of the second encapsulated packet is included in the MCAST transport packet. For example, if the value of this field is '10', both the start and end of the first encapsulated packet are included in the MCAST transport packet, and only the start of the second encapsulated packet is included in the MCAST transport packet.

49 to 55 illustrate wrappers according to embodiments of the present invention.

49A and 49B illustrate the structure of an encapsulation packet for signaling according to an embodiment of the present invention.

The packet shown in Fig. 49A includes a 4-byte header and payload. The payload may include description or metadata of the application, such as ESG and Electronic Program Guide (EPG). In addition, the payload includes optional data such as IP mapping information table and metadata information of the object.

A "first_last" field is a 2-bit field indicating whether the encapsulated packet is the first or the last. This field can be defined according to the value of this field, as shown in Table 5.

A "compression_flag" field is a 1-bit field indicating whether payload data is compressed or uncompressed. If the value of this field is "1", it means that the payload data is compressed.

A "signal_type" field indicates the type of payload data. The type of payload data according to this field is shown in Table 13 or Table 14:

[Table 13]

value describe 0 prohibit 1 [TBD] 2 Object_Delivery_Information 3-31 reserve

[Table 14]

value describe 0 prohibit 1 IP_mapping_Table 2-31 reserve

A 'sequence_number' field is an 8-bit field indicating a value incremented within an envelope of the same data type. If the field reaches its maximum value, its value returns "0". A 'sequence_number' field is used for an object segment identifier during retransmission.

A 'version_number' field is a 4-bit field indicating a version number of a Signaling Encapsulation Packet (SEP). This version number is incremented by 1 whenever the encapsulating payload version changes.

A "packet_length" field indicates the length of the payload in the packet in bytes.

A "data_byte" field is an 8-bit field. The type of data transmitted through the payload depends on the value of the "signal_type" field.

50A and 50B illustrate the structure of a package for real-time data according to an embodiment of the present invention.

The packet shown in FIG. 50 is an encapsulated packet for real-time data type, including a header, additional fields, and a payload.

A "first_last" field is a 2-bit field indicating whether the encapsulated packet is the first or the last. This field can be defined according to the value of this field, as shown in Table 5.

A 'RT_type' field is a 6-bit field indicating the type of data transmitted through the payload. Examples of data types according to the value of this field are as follows:

[Table 15]

value describe 0 audio 1 video 3-63 reserve

A 'DCI_flag' field indicates whether decoder configuration information (DCI) exists in the header of the encapsulated packet. In the current embodiment, the 'DCI_field' field contains DCI.

A "DC_version" field indicates a version of DCI. The value of this field is closely related to the value of the DC field (or DCI_field) of the transport packet and shall be set equal to the value of the DC field (or DCI_field) of the transport packet.

An 'addition_flag' field indicates whether additional information exists in the header of the encapsulated packet. In the current embodiment, the 'addition_flag' field includes additional information.

The "DCI_length" field indicates the length of the "DCI_field" field in the packet header in bytes.

A "DCI_field" field indicates DCI. The "DCI_field" field (or "Decoder_Configuration_Information" field) has been described above with reference to FIG. 4 .

The 'packet_length' field indicates the length of the payload of the packet according to the 'packet_length' field in bytes.

A 'PTS_flag' field indicates whether PTS information exists in the header of the encapsulated packet. In the current embodiment, the 'PTS' field contains PTS information.

A 'DTS_flag' field indicates whether DTS information exists in the header of the encapsulated packet. In the current embodiment, the 'DTS' field contains DTS information.

A "padding_flag" field indicates whether padding bytes exist in the header of the encapsulated packet.

The "scrambling_control" field signals the scrambling mode of the encapsulated packet payload.

A "PTS" field is a 33-bit field indicating a playback time stamp (PTS) defined in ISO/IEC13818-1.

A "DTS" field is a 33-bit field indicating a decoding time stamp (DTS) defined in ISO/IEC13818-1.

A "padding_length" field indicates the length of padding data in the packet in bytes. In the current embodiment, the "padding_byte" field contains padding data.

A 'padding_byte' field has an 8-bit value equal to '0xFF' and can be inserted by an encoder. This field is discarded by the decoder.

A "data_byte" field includes 8 bits.

FIG. 51 shows syntax of a wrapper for real-time data according to another embodiment of the present invention. This field in the capsule shown in FIG. 51 is the same as that shown in FIG. 50 .

52A and 52B illustrate syntax of an encapsulated packet for IP data according to an embodiment of the present invention.

The packets shown in Fig. 52 are used to send IP datagrams. An IP datagram can be divided into multiple encapsulated packets and then sent. It is necessary to indicate whether the current packet is the last packet, in which case a "first_last" field which will be described later can be used. Alternatively, if the value of the 'first_last' field is set to '0x01' or '0x03', it may be determined that the current IP encapsulation packet is the last one.

If the destination encapsulated packet is the first, the header field contains information indicating whether the encapsulated packet is the first packet or the last packet, information indicating whether additional information is present, information on the format of the IP data included in the payload area, and Information about the length of the encapsulated packet.

If the destination encapsulated packet is not the first packet, the header field includes information indicating whether the encapsulated packet is the first packet or the last packet, sequence number information, and information on the length of the encapsulated packet.

The additional header field contains information indicating whether subsequent additional information exists, information on the type of additional information, information on the length of additional information, and additional information.

A "first_last" field is a 2-bit field indicating whether the current packet is the first or the last. This field can be defined according to the value of this field, as shown in Table 5.

An 'addition_flag' field is a 1-bit field indicating whether additional information exists. In the current embodiment, the 'addition_dara' field contains additional information. If the value of this field is "1", it should be understood that the "addition_data" field exists.

The "IP_type" field is a 5-bit field indicating the type of data transmitted through the IP payload. For example, this field can be used to distinguish IPv4 from IPv6.

The "sequence_number" field consists of 4 bits, and is incremented by 1 within an envelope of the same data type. If the field reaches its maximum value, its value returns "0". This field is used for IP fragment identifiers during retransmissions.

The "encapsulation_packet_length" field includes 12 bits, and indicates the length of the payload in bytes.

A "continuity_flag" field includes one bit, and indicates whether a "{tag, length, additional_data}" field will follow. If the value of this field is "0", it can be understood that the current field is the last field containing additional information.

The "tag" field is a 7-bit field indicating the type of the "additional_data" field. This field serves as a container capable of containing various types of information additionally required to transmit IP data. The type of additionally required information is not limited.

The "length" field indicates the length of the "additional_data" field in bytes.

The length of the 'additional_data' field may be variously determined. The 'additional_data' field includes information according to the 'tag' field.

The 'payload' field may be variously determined, and includes an IP packet as defined in the 'IP_type' field.

FIG. 53 shows syntax of an encapsulation packet for IP data according to another embodiment of the present invention.

The packet shown in FIG. 53 is the same as the packet shown in FIG. 52 except that the header is changed.

54A and 54B illustrate the structure of a packet for object data according to an embodiment of the present invention.

The packet shown in FIG. 54A is an encapsulation packet for sending the object data type. The packet includes a plurality of transport packets through which the object data type is sent. The packet is divided into header, additional information and payload. Additional header fields contain additional information about the payload.

Object data is transmitted through the object sub-data channel according to two methods that will be described in detail later with reference to FIG. 56 .

If the encapsulated packet is the first packet, the header field contains information indicating whether the packet is the first packet or the last packet, information indicating whether additional information is present, identification information of the object data transmitted through the payload field, information about the type of object data information and information about the length of the packet.

If the encapsulated packet is not the first packet, the header field includes information indicating whether the packet is the first packet or the last packet, information indicating whether there is additional information, sequence number information, and information on the length of the packet.

The additional header field contains information indicating whether there is subsequent additional information, information on the type of additional information, information on the length of the additional information, and additional information.

A "first_last" field indicates whether the current packet is a start-encapsulation packet or a last-encapsulation packet. This field can be defined according to the value of this field, as shown in Table 5.

An 'addition_flag' field indicates whether additional information exists in the header of the encapsulated packet. In the current embodiment, the 'addition_data' field contains additional information.

The 'object_ID' field is used to identify all objects transmitted through the same sub-data channel.

The "object_type" field specifies the type of object data, for example, jpeg (compressed or uncompressed), text (compressed or uncompressed), or mp3.

A "sequence_number" field indicates segment information.

A "packet_length" field indicates the length of subsequent data.

A "continuity_flag" field indicates whether an "additional_data" field will follow. If the value of this flag is set to '1', it means that the 'additional_data' field will follow, and if the value of this field is set to '0', it means that the current 'additional_data' field is the last field.

A 'tag' field indicates a type of object decoder specific information. This field shows a breakdown of the type of object data specified in the "object_type" field. For example, if the 'object_type' field indicates text (compression), the data type can be subdivided according to the compression method. In this case, the data type can be expressed as "GZIP compressed text" through the "tag" field.

The "length" field expresses the length of the "additional_field_data" field in bytes.

An 'additional_field_data' field contains object decoder specific information.

The "payload" field contains the object data.

55A and 55B illustrate the structure of a packet for object data according to another embodiment of the present invention.

A "first_last" field is a 2-bit field indicating whether the current packet is a start-encapsulation packet or a last-encapsulation packet. The definition of this field according to the value of this field is shown in Table 5.

An "object_delivery_mode" field indicates a source block mode. If the value of this field is "0", the source block number may not be used, and if the value of this field is "1", it is reserved for future use.

The 'object_extention_id' field is used as an additional identifier for multiple objects when objects are transmitted within the same sub-data channel.

A 'source_block_number_8' field includes 8 bits and indicates the number of a source block. The value of this field indicates the number of the source block to which the current OEP belongs.

A 'source_block_number_16' field includes 16 bits and indicates the number of a source block. The value of this field indicates the number of the source block to which the current OEP belongs.

A "version" field indicates a version number of object data. The version number is incremented by 1 whenever the object data changes. A change in an object means that the object is updated. For example, when a name is added to a map file, the object that is the map file is changed.

A 'fragment_number' field indicates fragment information of a field source block or object when the length of the field source block or object exceeds the maximum length of the packet.

A "packet_length" field indicates a packet length in bytes.

FIG. 56 illustrates a method of transmitting object data according to an embodiment of the present invention.

One or more pieces of object data are transmitted at a time through one sub-data channel. The case of transmitting one piece of object data through one sub-data channel is called single-object mode, and the case of transmitting multiple pieces of object data through one sub-data channel is called multi-object mode.

In the multi-object mode, identifiers must be assigned to a series of object data in sub data channels respectively. Alternatively, multiple pieces of object data transmitted through the same sub-data channel may be identified using the object ID. Or, when a packet includes an 'additional_field' field for transmitting additional information such as characteristic information of object data, a series of object data in the sub data channel may be identified by inserting an 'object_extention_id' field into the 'additional_field' field.

FIG. 57 shows application of AL-FEC according to an embodiment of the present invention.

An OEP packet contains a header and a payload, and contains multiple transport packets. The SEP provides application information and specific parameters for AL-FEC. AL-FEC layers and objects will now be described with reference to FIG. 57 .

When applying MCASTAL-FEC, objects are fragmented into multiple source blocks. Each source block contains packets with a predetermined length. The length and number of packets are determined by MCASTAL-FEC encoding mode. After performing MCASTAL-FEC encoding, redundant packets are added. Error correction can be performed within the scope of redundant packets.

The MCAST transport packet will be described below.

58A and 58B illustrate a transport packet and a header structure of the transport packet according to an embodiment of the present invention.

Referring to FIG. 58A, a transport packet according to an embodiment of the present invention includes a basic header field, a PCR information field, a pointer field, a padding field, an LMT field, a LIT field, and a payload field.

The basic header field includes information indicating whether the transport packet is the beginning of the encapsulated packet or the last encapsulated packet, information indicating whether PCR exists, information indicating whether DCI exists in the header field of the encapsulated packet, information indicating whether there is a padding area, whether there is Information of the LMT and information indicating whether there is an LIT. These fields will be described in detail later with reference to FIG. 59 .

FIG. 58B shows the structure of a padding field of a transport packet according to an embodiment of the present invention.

The padding field of the transport packet according to the embodiment of the present invention may include padding length information and padding bytes.

The LMT field and LIT field in the transport packet are as described above with reference to FIGS. 34 to 41 .

58C and 58D illustrate a transport packet and a header structure of the transport packet according to an embodiment of the present invention.

The packets shown in FIG. 58C and FIG. 58D can be used when only one type of data is sent (for example, when only IP data is sent through the MCAST system).

FIG. 59A shows the syntax of a transport packet according to an embodiment of the present invention.

A "first_last" field indicates whether the transport packet is a start-encapsulation packet or a last-encapsulation packet. The definition of this field according to the value of this field is shown in Table 5.

A 'DC_flag' field indicates whether DCI exists in the header of the encapsulated packet. In the current embodiment, the 'decoder_configuration_information' field includes DCI.

A "pointer_flag" field indicates whether a "pointer_flag" field exists in the header of the transport packet.

A "padding_flag" field indicates whether a "padding_flag" field exists in the header of the transport packet.

The 'LMT_flag' field indicates whether the 'LMT_flag' field exists in the header of the transport packet.

The 'LIT_flag' field indicates whether the 'LIT_flag' field exists in the header of the transport packet.

The 'PCR_flag' field indicates whether the transport packet includes the 'PCR_flag' field. If the value of this field is '1', it should be understood that the transport packet includes the 'PCR_flag' field.

A 'pointer_field' field indicates a start position of the second payload when two encapsulated packets exist in one transport packet.

A "padding_length" field indicates the padding size within the packet in bytes.

A 'padding_byte' field has an 8-bit value equal to '0xFF' inserted by the encoder. The "padding_byte" field is discarded by the decoder.

From the "type_bitmap" field to the "object_channel_pointer" field has the same structure as the LMT shown in FIG. 34, and thus will be briefly described.

A 'type_bitmap' field indicates the type of data transmitted through the MCAST transport frame. Each bit of this field has a unique meaning. The first bit of this field indicates the existence of a real-time data channel, the second bit of this field indicates the existence of an IP data channel, and the third bit of this field indicates the existence of an object data channel.

A "version_number" field indicates the version number of the LMT. The version number is incremented by 1 whenever the LMT data changes.

A 'real-time_channel_number' field indicates the number of sub-data channels in a real-time media type channel.

An 'IP_channel_number' field indicates the number of sub-data channels in an IP type channel.

An 'object_channel_number' field indicates the number of sub-data channels in an object type channel.

A 'real-time_channel_pointer' field indicates a position of a sub-data channel of a real-time data type in a data channel.

The 'IP_channel_pointer' field indicates the position of the sub-data channel of the IP data type in the data channel.

An 'object_channel_pointer' field indicates a position of a sub data channel of an object data type in a data channel.

From the "service_number" field to the "LMT_index_number" field has the same structure as the LIT shown in FIG. 40, and thus will be briefly described.

A 'service_number' field indicates the number of services usable within the data channel.

A "version_number" field indicates the version number of the LIT field. The version number is incremented by 1 each time the signaling data changes.

A "service_ID" field indicates a service in a turbo channel. ID has unique value in turbo channel.

A 'next_indicator' field indicates the presence of a subsequent 'next_indicator' field and a subsequent 'LMT_index_number' field. For example, when the value of this field is '0', it means that no more 'next_indicator' field and 'LMT_index_number' field exist.

A 'LMT_index_number' field indicates a location of a sub-data channel in an LMT.

An 'index_number' field indicates a serial number of a fundamental channel associated with a service.

The 'Program_clock_reference_base'/'Program_clock_reference_extension' field includes a 42-bit PCR that is divided into two and then encoded. The first part is a 33-bit field whose value is the basic value given from the same equation defined in 2-1 of page 14 in the MPEG-213818-1 specification. The second part is a 9-bit field whose value is given from the same equation defined in 2-2 on page 14 of the MPEG-213818-1 specification.

A "data_byte" field includes 8 bits, and includes packet data.

FIG. 59B shows the structure of a transport packet according to another embodiment of the present invention.

The fields in the transport packet shown in FIG. 59B are the same as those in the transport packet shown in FIG. 59A.

FIG. 59C shows the structure of a transport packet according to another embodiment of the present invention.

The fields of the transport packet shown in FIG. 59C are the same as those in the transport packet shown in FIG. 59A except for the "Error_flag" field.

The "Error_flag" field indicates whether there is an error in the current packet. If the value of this field is "1", an error exists in the packet when the packet is unpacked.

FIG. 59D shows the structure of a transport packet according to another embodiment of the present invention.

The fields of the transport packet shown in FIG. 59D are the same as those in the transport packet shown in FIG. 59A.

60A and 60B show structures of a transport packet, a basic header and additional fields according to another embodiment of the present invention.

The transport packet shown in FIG. 60A includes a plurality of header fields and payload fields. Each header field includes basic header information, information indicating whether a pointer exists, LMT information, additional information, and payload. IP datagrams and signaling packets are transmitted through the payload field.

In detail, FIG. 60A shows the structure of a transport packet according to another embodiment of the present invention.

The "first_last" field is a 2-bit field indicating whether the transport packet is a start-encapsulation packet or a last-encapsulation packet, as defined in Table 5.

A 'signal_pkt_indicator' field indicates whether payload data is signaling data. If the value of this field is '1', it is understood that the data transferred through the 'payload' field is signaling data.

An "error_indicator" field indicates whether a packet includes an error.

An 'addition_flag' field is a 1-bit field indicating whether there is additional information. In the current embodiment, the 'addition_flag' field contains additional information. If the value of this field is "1", it is understood that the "addition_field" field exists.

A "compression_flag" field indicates whether the IP datagram is compressed. If the value of this field is "1", it means that the IP datagram transmitted through the "payload" field is compressed.

A 'pointer_flag' field indicates whether another IP datagram or signaling data exists. If the value of this field is "1", it is understood that there is another IP datagram or signaling data.

A 'continuity_flag' field is a 1-bit field indicating whether a '<tag><length><additionalfielddata>' field exists. That is to say, if the "<tag><length><additionalfielddata>" field is called the "Add.Field" field, it can be understood that the "Add.Field" field exists when the value of the "continuity_flag" field is "1", The 'Add.Field' field does not exist when the value of the 'continuity_flag' field is '0'.

The "tag" field defines the data type of additional information, as follows:

[Table 16]

tag describe 0 padding_field 1 LMT_field 2 compression_parameter_field 3-127 reserve

A "length" field indicates the length of subsequent additional information. In the current embodiment, the 'additional_field' field contains additional information such that the 'length' field indicates the length of the 'additional_field' field.

The "addition_field" field contains additional information.

A 'pointer_field' field is an 8-bit field indicating an offset from the beginning of the transport packet to the first byte of the second encapsulated packet in the transport packet when the transport packet includes two or more encapsulated packets.

The "data_byte" field contains IP datagram or signaling data. Data can be sharded.

61A and 61B illustrate the structure of the 'padding_field' field when the value of the 'tag' field shown in FIG. 60 is set to '0' according to an embodiment of the present invention.

The "tag" field indicates that a padding field will follow.

A "length" field is an 8-bit field indicating the length of a padding field. In the current embodiment, the 'padding_byte' field contains padding data such that the 'length' field indicates the length of the 'padding_byte' field.

A 'padding_byte' field has an 8-bit value equal to '0xFF' and can be inserted by an encoder. This field is discarded by the decoder.

FIG. 62 shows the structure of the 'LMT_field' field according to an embodiment of the present invention when the value of the 'tag' field shown in FIG. 60 is set to '1'.

The "tag" field indicates that LMT information will follow. In the current embodiment, the 'LMT_information' field contains LMT information.

A "length" field is an 8-bit field indicating the length of the "LMT_information" field in bytes.

The "LMT_information" field contains location information of all IP data within the IP sub-data channel and location information of all signaling data within the signaling sub-data channel. This field has been described above with reference to FIGS. 34 to 39 .

FIG. 63 shows a structure of a 'compression_field_parameter' field when the value of the 'tag' field shown in FIG. 60 is set to '2' according to an embodiment of the present invention.

The "tag" field indicates that information about the compression parameters will follow. In the current embodiment, the 'compression_parameter' field contains information on compression parameters.

The "length" field is an 8-bit field indicating the lengths of the "compression_type" field and the "compression_parameter" field in bytes.

A "compression_type" field indicates a compression type. Additional information about the compression type shall be carried by the "additional_field" field. Examples of compression types according to the value of the "compression_type" field are as follows:

[Table 17]

compression_parameter describe 0 no compression 1 ROHC 2-255 reserve

A "compression_parameter" field contains parameters related to compression of payload data. Vary the parameters according to the compression type.

64A and 64B illustrate the structure of a signaling packet according to an embodiment of the present invention.

The payload of the MCAST transport packet carries signaling data. Signaling data contains additional information about the IP datagram. The IMT information carried by the signaling packet includes link information between the IP flow and the IP sub-data channel.

The "signal_type" field indicates the type of data conveyed by the payload, as follows:

[Table 18]

value describe 0 prohibit 1 IP_mapping_table 2-31 reserve

A 'version_number' field is a 3-bit field indicating the version number of the signaling packet. The version number is incremented by 1 each time the signaling data sent through the payload changes.

A 'payload_length' field is a 16-bit field indicating the length of signaling data that follows/follows.

The 'data_byte' field contains signaling data according to the 'signal_type' field.

A method for supporting OMA-BCAST to MCAST and a relationship between OMA-BCAST and MCAST according to an embodiment of the present invention will now be described.

ATSC-M/H terminals not only support IPv6 but also support IPv4 for general encapsulation and network packet transmission. ATSC-M/H system can also use IPv6 and IPv4. The Internet Protocol allows the bearer and management layers to be abstractly and logically distinguished from each other. IP datagrams are encapsulated into MCAST transport packets. For MCAST transmission, mapping information between IP datagrams and turbo channels is required, and the IP address mapping signaling can be performed through the above-mentioned IMT.

The linkage between the OMA-BCAST service and MCAST will now be described. The most important factors of this link are signaling, discovery of entry points of service guides and discovery of transport sessions. For this, IP streams and transport channels must be linked and signaled to one another. In order to access the OMA-BCAST service, the entry point of the service announcement information must first be ensured. Service announcement information can be transmitted through more than one turbo channel. In MCAST, the location information of the turbo channel of the entry point of the service is transmitted using the IMT transmitted through the SIC. In addition, an IMT including location information of an IP flow included in a turbo channel may exist at a predetermined location of each turbo channel. For the convenience of explanation, the mapping information sent through the SIC is called "i-IMT", and the mapping information in the turbo channel for sending data is called "IMT".

In order to provide the OMA-BCAST service guide, the service guide announcement channel and the service guide transport channel are included in the turbo channel. Specifically, one of the turbo channels may transmit a plurality of information on service fragments used for service guides in all turbo channels such as aggregate ESG. In addition, this channel may provide a service announcement channel. Aggregate ESG channels provide location information of IP flows included in other turbo channels, allowing access to other turbo channels for specific IP flows.

FIG. 65 shows a process of providing OMA-BCAST service in the MCAST transmission system according to an embodiment of the present invention.

Referring to Figure 65, the SIC includes i-IMT which contains a list of all service entry points. A service entry point describes a concrete service guide or aggregate service guide channel. i-IMT contains the location information of the IP flow in the turbo channel.

The broadcast receiving device obtains i-IMT from the SCI. i-IMT includes location information of channels including specific service guides or aggregated service guide channels. The broadcast receiving device accesses a turbo channel containing a desired service from among the turbo channels based on the location information included in the i-IMT.

In each turbo channel, there is a signaling sub-data channel for transmitting signaling data, and IMT may exist in the signaling sub-data channel. The IMT may have at least one service guide announcement channel location information included in the corresponding broadcast channel, service guide delivery channel, and IP flow. The broadcast receiving device obtains a service guide based on location information included in IMT. The broadcast receiving device can access specific services based on the information in the service guide. A method of allowing a user to receive a service will now be described in detail with reference to FIG. 66 .

FIG. 66 illustrates a method of providing a service by using MCAST supporting OMA-BCAST according to an embodiment of the present invention.

First, in order to support OMA-BCAST, the Service Guide (SG) Announcement Channel and the SG Transport Channel must be transmitted through more than one channel. The broadcast receiving device must sequentially access the SG announcement channel and the SG delivery channel. The SG transport channel transmits fragments of the service guide, which provides metadata about the broadcast service (eg, the configuration of the broadcast service). The SG Announcement Channel provides information for handling the SG Transport Channel.

The broadcast receiving device first accesses the SIC to check the turbo channel through which the SG announcement channel is transmitted. The i-IMT contains the IP address of the SG announcement channel, the location information of the SG announcement channel or the channel including the IP flow. For example, i-IMT may contain mapping information between IP addresses of SG advertising channels and the number of turbo channels.

The broadcast receiving apparatus may display information on channels included in i-IMT so that a user may select a specific channel, or an announcement channel may be randomly selected as a default without user's input. If the user selects a specific channel, the selected channel is accessed using the IP address of the selected channel and information included in the i-IMT. In this way, it is possible to additionally provide a service guide or service to the user.

In a turbo channel, there is a signaling sub-data channel that transmits signaling data. In the signaling sub-data channel, there is an IMT containing position information of the stream transmitted through the current turbo channel. For example, it may include mapping information between the IP address of the IP flow transmitted through the current turbo channel and the sub-data channel.

The broadcast receiving device can obtain the location information of the SG announcement channel from the IMT. The sub-data channel including the SG announcement channel is accessed using the IP address of the SG announcement channel obtained from i-IMT and IMT. The broadcast receiving device obtains the location information of the SG delivery channel by processing the SG announcement channel. For example, the IP address of the SG delivery channel can be obtained by processing the SG advertisement channel. Since there is mapping information between the IP address and the sub-data channel in the previously obtained IMT, the broadcast receiving device accesses the SG delivery channel by using the IP address of the SG delivery channel and the IMT, and obtains the service guide from the SG delivery channel.

The service guide is metadata about broadcast services to be provided such as ESG and EPG as described above. The broadcast receiving device may provide a user with a service guide so that the user may select a desired broadcast service, or the broadcast receiving device may provide a broadcast service designated as a default. If the user selects a desired broadcast service, the selected broadcast service is provided using the service guide. For example, the service guide may include the IP addresses of the IP flows that provide the service. Since the previously obtained IMT includes mapping information between the IP address and the sub-data channel, the IP flow is obtained using the IP address of the IP flow providing the broadcast service obtained from the service guide and the IMT. The broadcast receiving device provides a selected broadcast service by using the obtained IP stream.

A brief description of the OMA-BCAST service layer will now be given.

Service guides allow descriptions of services and content that are created by service/content providers via broadcast and interactive channels or offered by subscription or purchase. In addition, the service guide describes the methods to access the service. From the perspective of the end user, the service guide is used to discover the access points that can be used or are currently being used. Additionally, the service guide provides data entry points for random, directed services.

The service guide has the following functions.

First, the service guide data model creates services, schedules, content, data provisioning and interaction data related to purchase and access in the form of service guide fragments.

Second, service guide discovery enables initial power-on and discovery of entry points to the service guide.

Third, service guide transmission is performed not only over an optional, interactive channel, but also over a broadcast channel.

Finally, Service Guide Updates, Management and Completeness is entirely sufficient to ensure that the Service Guide is up to date and available to users for browsing.

ATSC-M/H terminals shall support the mandatory part of the OMA-BCAST Service Guide for Service Guide functionality. Furthermore, in this specification, the parts related to the interaction method, transmission, and use of service guides should be interpreted as applicable even when these are specifically mandatory. Next, the transmission path and transmission according to the data format will be described.

First, real-time A/V streaming will be described.

In order to realize the real-time delivery of ATSC-M/H audio-visual broadcasting services, RTP/UDP should be used as the transport protocol. Different audio and video formats are encapsulated into RTP with specific RTP payload formats each defined for a specific decoder. The streaming level is augmented by the optional use of reception reports.

ATSC-M/H terminals shall support the mandatory part of the OMA-BCAST document and streaming distribution for real-time audiovisual streaming. In addition, the terminal may support an associated delivery procedure for OMA-BCAST file and stream publishing.

Next, transmission of an A/V stream requested through a bidirectional channel will be described.

The RTP/UDP transport protocol is also used for the delivery of audiovisual streams on interactive channels for on-demand services. Since the interactive mode is optional, ATSC-M/H terminals may support the interactive part of the OMA-BCAST stream file as specified in the specification.

Next, non-real-time content transmission through a broadcast channel will be described.

For this reason, in order to realize the delivery of non-real-time content on the broadcast channel, FLUTE/UDP is used as a transport protocol. The robustness of file transfers can be increased in two ways: by applying application-layer FEC or by applying a post-transfer (error correction) process operating on an optional return channel.

ATSC-M/H terminals shall support the mandatory part of the OMA-BCAST document and stream distribution of specifications for non-real-time audiovisual content delivery. In addition, the terminal may support an associated delivery procedure for OMA-BCAST file and stream publishing.

Next, non-real-time content transmission through an interactive channel will be described.

Since the interactive mode is optional, ATSC-M/H terminals may support the interactive part of the OMA-BCAST file as specified in the specification. Note that only mandatory parts of the specification should be supported in this case.

Finally, ATSC-M/H terminals support ancillary data, advertisements and notifications as defined in the specification.

Protection of services and content by OMA-BCAST will now be described.

FIG. 67 shows four layers for securing services and content according to an embodiment of the present invention.

For service protection, two key management systems (KMS) are supported.

One of the two KMSs is a terminal-based KMS (DRM file), which is key management performed by the terminal. Another KMS is smart card based KMS (Smart Card Profile), implemented by (U)SIM or (R)UIM/CSIM.

An ATSC-M/H terminal can support two KMSs, or not support any one of them.

If an ATSC-M/H terminal supports terminal-based KMS, it shall support the mandatory part of the DRM profile defined in the specification.

If an ATSC-M/H terminal supports smart card-based KMS, it shall support the mandatory part of the smart card profile defined in the specification.

Both KMSs above provide a high level of security for mobile device service protection, and both KMSs can be applied at the same time.

The four layers will now be described with reference to FIG. 59 .

The communication layer uses IPsec, SRTP or ISMACryp as the communication password.

IPsec is Encapsulating Security Payload (ESP) and uses AES-128-cbc with an explicit IV as the encryption algorithm in each IP packet. Authentication is optional and uses HMAC-SHA-1-96.

SRTP uses AES-128-CTR as the encryption algorithm. Authentication is optional and uses HMAN-SHA-1-80.

ISMA CCryp1.1 with OMA-BCAST is specified for codec-agnostic extensions. AES-BYTE-CTR is used as encryption algorithm. Authentication is optional and uses HMAC-SHA1.

The key management layer, rights management layer and registration layer for DRM files using Microsoft PlayReady are specified in the specification.

The key management layer, rights management layer and registration layer for DRM files using OMADRM2.0 are specified in the specification.

The key management layer, rights management layer and registration layer for smart card files are specified in the specification.

A terminal supporting interaction may support one or both of DRM files or smart card files. For DRM files, Long Term Key Message (LTKM) delivery on interactive channels shall be supported, and LTKM delivery on broadcast channels may be supported.

Terminals that do not support interaction can support DRM files. LTKM transmissions on broadcast channels shall be supported.

ATSC-M/H terminals may support content protection. If the ATSC-M/H terminal supports content protection, it shall support one or both of MicrosoftPlayReady and OMADRMv2.0.

MCAST systems according to embodiments of the present invention allow optional support for interactive channels. Support for interactive features is optional for ATSC-M/H terminals. However, if the ATSC-M/H terminal supports the interactive feature, the terminal shall support the OMABCAST1.0 specification for address interaction. For these instructions, the mandatory part is supported.

The presentation layer level of ATSC-M/H according to the embodiment of the present invention will be described below.

Regarding video codec, ATSC-M/H terminals shall support H.264/AVC video codec. In addition, ATSC-M/H terminals shall support at least one of the following five capabilities:

decoding a bitstream consistent with the baseline profile of H.264/AVC level 1b having the "constraint_set1_flag" field with value equal to "1";

decoding a bitstream consistent with the baseline profile of H.264/AVC level 1.2 having the "constraint_set1_flag" field with value equal to "1";

decoding a bitstream consistent with the baseline profile of H.264/AVC level 2 having the "constraint_set1_flag" field with value equal to "1";

decoding a bitstream consistent with the baseline profile of H.264/AVC level 3 having the "constraint_set1_flag" field with value equal to "1";

A bitstream conforming to the baseline profile of H.264/AVC level 4 having a "constraint_set1_flag" field with a value equal to "1" is decoded.

ATSC-M/H terminals optionally support more than one of these capabilities, supporting higher levels and bin decoding capabilities than those required by those capabilities.

Regarding frame rates, ATSC-M/H terminals shall decode each frame rate allowed by the H.264/AVC profile and level associated with the implemented capabilities. The frame rate may include various frame rates. The decoder does not need to decode the bitstream when the maximum distance between two pictures exceeds 0.7 seconds.

Regarding aspect ratios, ATSC-M/H terminals shall decode each aspect ratio allowed by the H.264/AVC profile and level associated with the implemented capabilities.

With respect to luma resolutions, ATSC-M/H terminals shall decode each luma resolution allowed by the H.264/AVC profile and level associated with the capabilities of the implementation.

With respect to chroma, ATSC-M/H terminals shall decode each allowed value of colour_primaries, transfer_characteristics and matrix_coefficients.

With respect to chroma formats, ATSC-M/H terminals shall decode each allowed value of chroma_sample_loc_type_top_field and chroma_sample_loc_type_bottom_field.

Regarding audio codecs, ATSC-M/H terminals shall support one or both of HEAACv2 and AMR-WB+ (extended AMR-WB).

First, HEAACv2 will be described. ATSC-M/H terminals shall support mono/parametric coding or 2-channel stereo functions defined in HEAACv2 profile level 2. ATSC-M/H terminals optionally support decoding of multi-channel audio as defined in HEAACv2 Profile Level 4.

Regarding files, ATSC-M/H terminals shall support HEAACv2 files. ATSC-M/H terminals optionally support decoding of HEAAC files.

Regarding bit rate, ATSC-M/H terminals can decode any bit rate permitted by the HEAACv2 profile and selected class.

With respect to sampling frequency, ATSC-M/H terminals shall decode each audio sampling rate permitted by the HEAACv2 profile and selected class.

Regarding dynamic range control, ATSC-M/H terminals shall support MPEG-4AAC dynamic range control tools.

Regarding down-mixing, ATSC-M/H terminals shall support matrix down-mixing as defined in MPEG-4.

AMR-WB will now be described.

Regarding audio modes, ATSC-M/H terminals shall perform decoding with mono and stereo functionality as defined in AMR-WB+.

Regarding sampling frequency, ATSC-M/H terminals shall be able to decode each audio sampling rate licensed by AMR-WB+ for mono and stereo.

Regarding subtitles, the ATSC-M/H system can provide subtitles and closed captions using the 3GPP time text format. ATSC-M/H terminals shall support the 3GPP Time Text format for subtitles.

Figure 68 illustrates a power management mechanism according to an embodiment of the present invention.

Typically, key devices that consume power are display panels (such as LCDs) and radio frequency (RF) modules. In this section, the energy-saving mechanism based on RF module control will be described.

In a general broadcast system, the RF module must be turned on and all incoming frames must be monitored for the desired frame. In ATSC-MCAST, all turbo services are combined and mapped to a sequence of frames, and information about the frames, such as the position and number of frames, is transmitted through the SIC. From the transmitted information, the broadcast receiving device can distinguish an idle time period from an on-duty time period.

Figure 68 shows an example of MCAST frame fragmentation, the frame number is used to identify the service. For example, if the user selects program #1, the RF module is operable to receive frames #1 through #4 from the set of RF frames. That is, the transport layer instructs the physical layer to receive frames #1 to #4. The number of RF frame groups and the duration of the frame fragmentation can be changed, information about the change is sent through the SIC.

A fixed number of MCAST packets is the burst unit. The number of MCAST packets varies according to the function of the turbo encoding mode. The number of MCAST packets may vary per burst.

FIG. 69 shows parameters related to MCAST frame fragmentation according to an embodiment of the present invention.

A method of transmitting data according to the burst transfer method will now be described.

Figure 69 shows parameters for time slicing. The parameters are defined as follows:

[Table 19]

parameters describe bp Burst time period (frame) Bd Burst duration (frame) Ot off time (frame) Bs Burst size (blocks) Bb Burst bandwidth (block/frame) Cb Constant bandwidth (block/frame)

The relationship among the parameters Bd, Bb, Bp and Cb is expressed as "Bd×Bb=Bp×Cb”.

FIG. 70 is a graph illustrating parameters related to energy saving according to an embodiment of the present invention.

Three phases are required to allocate bursty services to turbo channels. First, the predetermined bandwidth for each service must be calculated using the following equation (3). In Equation (3), "Tc" represents a turbo coding rate, such as 1/2, 1/3, or 1/4.

${\mathrm{<span\; class="notranslate">\; Cb</span>}}_{\mathrm{<span\; class="notranslate">\; no</span>}}<span\; class="notranslate">\; =</span>\frac{\mathrm{<span\; class="notranslate">\; DataRate</span>}<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; kbit</span>}<span\; class="notranslate">\; /</span>\mathrm{<span\; class="notranslate">\; the\; s</span>}<span\; class="notranslate">\; )</span>}{\frac{\mathrm{<span\; class="notranslate">\; 32</span>}<span\; class="notranslate">\; \&times;</span>\mathrm{<span\; class="notranslate">\; 8</span>}<span\; class="notranslate">\; \&times;</span>\mathrm{<span\; class="notranslate">\; 78</span>}}{\mathrm{<span\; class="notranslate">\; 24.2</span>}<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; ms</span>}<span\; class="notranslate">\; )</span>}<span\; class="notranslate">\; \&times;</span>\frac{\mathrm{<span\; class="notranslate">\; 188</span>}}{\mathrm{<span\; class="notranslate">\; 208</span>}}<span\; class="notranslate">\; \&times;</span>\mathrm{<span\; class="notranslate">\; Tc</span>}}<span\; class="notranslate">\; -</span><span\; class="notranslate">\; -</span><span\; class="notranslate">\; -</span><span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 3</span>}<span\; class="notranslate">\; )</span>$

Second, each service is allocated a predetermined bandwidth.

FIG. 71 is a diagram illustrating a method of allocating each service to a predetermined bandwidth for burst mode transmission according to an embodiment of the present invention.

The total bandwidth is calculated by:

CbToT=Cb1+Cb2+...+CbN(4)

Third, services #1 to #3 must be rotated 90 degrees clockwise or counterclockwise.

FIG. 72 is a diagram illustrating rotation of services for burst mode transmission according to an embodiment of the present invention.

AL-FEC according to an embodiment of the present invention will now be described.

Regarding encoding, MCASTAL-FEC is a concatenated code of two linear block codes. The inner and outer codes are defined as generator matrices or equivalent graphs. For example, the inner and outer codes have message codes (u ₁ , u ₂ ). Each of u ₁ and u ₂ represents a bit stream having a length L greater than "1". Similarly, the codewords in the code are expressed as (v ₁ , v ₂ , v ₃ , v ₄ , v ₅ , v ₆ ), and v _i {i=1, . . . 6} is a bit stream with length L.

Given the matrix G shown in equation (5), the message code (u ₁ , u ₂ ) passes v1=u1, v2=u1(+)u2, v3=u1(+)u2, v4=u2 , v5=u1 and v6=u2 are encoded as codewords (v ₁ , v ₂ , v ₃ , v ₄ , v ₅ , v ₆ ). The above operator (+) represents an XOR (exclusive OR) bit stream.

$\mathrm{<span\; class="notranslate">\; G</span>}<span\; class="notranslate">\; =</span>\begin{array}{c}\mathrm{<span\; class="notranslate">\; 123456</span>}\mathrm{<span\; class="notranslate">\; v</span>}<span\; class="notranslate">\; /</span>\mathrm{<span\; class="notranslate">\; u</span>}\\ \begin{array}{cc}\left[\begin{array}{c}\mathrm{<span\; class="notranslate">\; 111010</span>}\\ \mathrm{<span\; class="notranslate">\; 011101</span>}\end{array}\right]& \end{array}\begin{array}{c}\mathrm{<span\; class="notranslate">\; 1</span>}\\ \mathrm{<span\; class="notranslate">\; 2</span>}\end{array}\end{array}<span\; class="notranslate">\; -</span><span\; class="notranslate">\; -</span><span\; class="notranslate">\; -</span><span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 5</span>}<span\; class="notranslate">\; )</span>$

The length of the codeword is three times longer than the length of the message code. Generator matrices can be conventionally expressed as graphs.

FIG. 73 is a diagram illustrating a generator matrix according to an embodiment of the present invention. The graph of FIG. 73 represents the matrix G shown in Equation (5). The description of the graph is equivalent to the generator matrix. Each column in the graph corresponds to a codeword point v _i {i=1, ... 6}, and each row represents a message code (u ₁ , u ₂ ). The value of row x and column y of matrix G means the line between u _x and v _y in the graph. The node degree (u or v) represents the number of lines connected to the node and is denoted as deg(u or v). For example, deg(u ₁ ) is 4, and deg(v ₃ ) is 2. The generator matrix is an important element to be properly designed.

The design of the generator matrix will now be described.

Assume that the number of message nodes is k and the number of code nodes is n. The code rate is k/n. The message code is represented by (u ₁ , u ₂ , . . . , u _k ), and the code word is represented by (v ₁ , v ₂ , . . . , v _n ). First, the graph is designed, and the generator matrix is obtained through the transformation of the graph. The graph is obtained in two steps. The first step is to determine the codeword vertex degree (deg(v _i )). The second step is to connect the message node and the code node.

In detail, in the first step, given k message nodes and n alc codeword points, the codeword node degree (deg(v _i )) is determined as follows.

1. Determine d _Max from the design parameter Δ. Δ is an integral value from 1 to 16. d _Max is specified by the value of the design parameter Δ. For example, if Δ is "8", d _Max is "61".

[Table 20]

Δ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 d _Max 917 388 231 158 117 91 74 61 52 44 38 34 30 27 twenty four twenty two

2. Determine the array of integral values, {N[i]|i=1, 2,...d _Max } as follows:

If an outer code is designed, then N[1]=n and N[i]=0 (i=2, . . . , d _Max )

If the inner code is designed, then

$\mathrm{<span\; class="notranslate">\; N</span>}<span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; ]</span><span\; class="notranslate">\; =</span><span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; no</span>}<span\; class="notranslate">\; \&CenterDot;</span>\frac{\mathrm{<span\; class="notranslate">\; 2</span>}<span\; class="notranslate">\; \&CenterDot;</span>\mathrm{<span\; class="notranslate">\; \&Delta;</span>}<span\; class="notranslate">\; \&Center\; Dot;</span>{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}<span\; class="notranslate">\; -</span>\mathrm{<span\; class="notranslate">\; 100</span>}}{{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}<span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; 100</span>}<span\; class="notranslate">\; +</span>\mathrm{<span\; class="notranslate">\; 2</span>}<span\; class="notranslate">\; \&CenterDot;</span>\mathrm{<span\; class="notranslate">\; \&Delta;</span>}<span\; class="notranslate">\; )</span>}<span\; class="notranslate">\; ]</span>$

$\mathrm{<span\; class="notranslate">\; N</span>}<span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; ]</span><span\; class="notranslate">\; =</span><span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; no</span>}<span\; class="notranslate">\; \&CenterDot;</span>\frac{\mathrm{<span\; class="notranslate">\; 100</span>}}{\mathrm{<span\; class="notranslate">\; 100</span>}<span\; class="notranslate">\; +</span>\mathrm{<span\; class="notranslate">\; 2</span>}<span\; class="notranslate">\; \&CenterDot;</span>\mathrm{<span\; class="notranslate">\; \&Delta;</span>}}<span\; class="notranslate">\; \&Center\; Dot;</span>\frac{{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}<span\; class="notranslate">\; +</span>\mathrm{<span\; class="notranslate">\; 1</span>}}{{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}<span\; class="notranslate">\; -</span>\mathrm{<span\; class="notranslate">\; 1</span>}}<span\; class="notranslate">\; \&CenterDot;</span>\frac{\mathrm{<span\; class="notranslate">\; 1</span>}}{\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; \&CenterDot;</span><span\; class="notranslate">\; (</span>\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; -</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; )</span>}<span\; class="notranslate">\; ]</span><span\; class="notranslate">\; ,</span>\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; =</span>\mathrm{<span\; class="notranslate">\; 3</span>}<span\; class="notranslate">\; ,</span><span\; class="notranslate">\; .</span><span\; class="notranslate">\; .</span><span\; class="notranslate">\; .</span><span\; class="notranslate">\; ,</span>{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}$

$\mathrm{<span\; class="notranslate">\; N</span>}<span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; 2</span>}<span\; class="notranslate">\; ]</span><span\; class="notranslate">\; =</span>\mathrm{<span\; class="notranslate">\; no</span>}<span\; class="notranslate">\; -</span>\mathrm{<span\; class="notranslate">\; N</span>}<span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; 1</span>}<span\; class="notranslate">\; ]</span><span\; class="notranslate">\; -</span>\underset{\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; =</span>\mathrm{<span\; class="notranslate">\; 3</span>}}{\overset{{\mathrm{<span\; class="notranslate">\; d</span>}}_{\mathrm{<span\; class="notranslate">\; Max</span>}}}{\mathrm{<span\; class="notranslate">\; \&Sigma;</span>}}}\mathrm{<span\; class="notranslate">\; N</span>}<span\; class="notranslate">\; [</span>\mathrm{<span\; class="notranslate">\; i</span>}<span\; class="notranslate">\; ]</span>$

Among them, [x] represents the largest positive integer smaller than x or equal to x.

3. Determine the degree (deg(v ₁ ), deg(v ₂ ), . . . , deg(v _n )) of each codeword node according to the flowchart shown in FIG. 63 .

FIG. 74 is a flowchart illustrating a method of determining deg(v _i ) according to an embodiment of the present invention.

In operation 7410, integer variables (k ₁ , _{k 2} , ..., km ) are initialized to "0", that is, k1 = k2 = ... = km = 0, where m represents the largest integer , N[m] is not zero. The other integer variable j is set to "1".

In operation S7420, an index a is determined such as, $a=\underset{i}{\arg }\underset{i=1,...,m}{\min }\frac{k_i}{N\left[i\right]}.$ When there are multiple minima, a set of indices {a, b, ..., c} is determined.

In operation S7430, the degree of v _j is a, and j is incremented by 1. Also, the degree of v _j is b, and j increases by 1. This process is repeated until all indices are used.

In operation S7440, only the variables (k _a , k _b , ..., k _c ) specified in the index group {a, b, ..., c} are increased by 1.

In operation S7450, it is verified whether all degrees (deg(v _j ), j=1, . . . , n) are determined. If not completely determined, repeat operation S7420.

In the second step, given k message nodes and n code nodes, the code node degree is deg(v _i ), check the message nodes connected to the code node according to the flowchart of Fig. 64 .

FIG. 75 is a flowchart illustrating connection of a message node to a code node according to an embodiment of the present invention.

In operation S7510, the index variable _j of the codeword point vj is initialized to "1".

In operation S7520, a set of message nodes {a, b, . . . , c} to be associated with the codeword node v _j is obtained. The number of elements (|{a, b, ..., c}|) in this set shall be equal to the degree deg(v _j ) of v _j .

At operation S7530, the message nodes to be connected with {u _a , u _b , ..., u _c } to the codeword node v _j are identified.

In operation S7540, the above process is repeated for all codeword points.

FIG. 76 is a flowchart illustrating in detail operation S7520 illustrated in FIG. 75 according to an embodiment of the present invention.

In operation S7610, the message node index sets U and S are initialized as {1, . . . , k} and {}, respectively. Groups U and S are sequential groups, the sequence being defined as follows. Given the x-th element a and the y-th element b in groups U and S, if x < y, then a < b, and vice versa. This initialization is performed only once before calling the procedure.

In operation S7620, after obtaining a pseudo-random value x in {1,...,|u|}, the xth element in the group U obtains a message node index that will be returned, where |u| number of elements. Subsequently, the element is moved from group U to group S. In this way, all previously selected message node index values are included in set S, while other non-selected nodes are still in set U.

In operation S7630, it is determined whether the group U is an empty group. If the group U is empty, operation S7630 is performed to respectively initialize the groups U and S to {1, . . . , k} and {}, respectively.

The operation of obtaining the number x of message node indices in {1, . . . , |u|} is not specified in FIG. 76 . The operation is done by Mersenne Twister (MT) as a pseudo-random number generation algorithm proposed by Makoto Matsumoto and Takuji Nishimura in 1996/1997 and improved in 2002. There exists the inventor's standard C code, which is free to apply for any purpose, including commercial use.

MersenneTwister (MT) is initialized by an unmarked 32-bit integer seed (seed) before any procedure is called. Obtain the index number x in {1,...,|u|}, then generate an unmarked 32-bit integer seed, obtain the smallest integer e such as |u|<=2 ^e , obtain the largest e bits, if the If the number is greater than |u| or equal to |u|, it is discarded and the previous process is repeated again. If the number is smaller than |u|, the message node index number x is the number in {1, . . . , |u|}+1.

A method of designing a generator matrix will now be described.

Each column corresponds to a code node (v _i , i=1, . . . , n) in the graph, and each row represents a message node (u _i , i=1, . . . , k). When u _x is connected to v _y in the graph, the element at row x and column y in the generator matrix should be "1". Element should be 0 if not connected.

A predesigned AL-FEC code will now be described.

To define MCASTAL-FEC codes, two matrices are defined. One of them is used for the inner code and the other is used for the outer code.

Given a(n, k) MCASTAL-FEC code, the inner code should be a(n, k+δ _k ) code, and the outer code should be a(k+δ _k , k) code. k+δ _k is the number of code word nodes in the outer code and message nodes in the inner code.

In order to define deg(v _j ) in the inner code, a design parameter Δ needs to be provided.

In order to define the connection between u _i and v _j in the inner and outer codes, a random seed for the MersenneTwister process needs to be provided. This seed is applied to both inner and outer codes.

Therefore, the three parameters _δk , Δ and the seed are sufficient to define the MCASTAL-FEC code. For three different (n, k) MCASTAL-FEC codes, these parameters are listed as follows:

[Table 21]

(n,k) (δ _k , Δ, seed) (2880, 2304) (10, 6, 14) (1920, 1536) (3,8,6) (960,768) (1,8,8)

FIG. 77 is a block diagram of a MCAST broadcast receiving device according to an embodiment of the present invention.

Referring to FIG. 77 , the broadcast receiving device includes a signaling information extractor 7701 , a data obtaining unit 7702 and a data processing unit 7703 .

The signaling information extractor 7701 obtains signaling information required to process the transport channel. Signaling information may be conveyed over a transport channel such as SIC. The signaling information may include at least one of configuration information on the ATSCM/H stream required to process the transport channel, error correction information on the transport channel, and configuration information on the transport channel.

Signaling information may be included in the ATSC normal stream continuously or non-continuously and sent subsequently. The signaling information is included in a predetermined position of the frame, or the position information of the signaling information is included in the predetermined position of the frame, so that the signaling information extractor 7701 can identify the position of the signaling information. Furthermore, the location of the signaling information can be indicated by including a specific bit stream inside or outside of the channel through which the signaling information is transmitted.

The signaling information is important information since it contains the information needed to process other transport channels and thus may contain additional codes for error correction. Signaling information can be sent in-band, out-of-band, or through specific locations in the transport stream.

The data obtaining unit 7702 obtains packets sent through the transmission channel. The term "transport channel" used in this specification has a wider definition than that used in general broadcasting systems. That is, the term "transport channel" according to the present invention includes a simultaneously transmitted stream included in another transport stream. For example, an ATSC normal stream (MPEG-2 TS) can be transmitted by including an MPEG-2 TS stream or other type of transport stream through an additional indication in the ATSC normal stream. In the current embodiment, a broadcast receiving device obtains data by processing a transport stream included in a normal stream. Data can be obtained according to a predetermined method or by using the above-mentioned signaling information transmitted via a specific channel such as SIC. A transport stream to be received by a mobile terminal according to the present invention is inserted into another transport stream, or information indicating the insertion is transmitted through the SIC. For example, the transport stream is included in the MPEG-2TS null field or the MPEG-2TS private data field.

If a transport stream to be received by a mobile terminal according to the present invention is inserted (or added) to another transport stream, additional header or display information may also be included to handle the inserted or added stream. For example, a combination of information on the start and end positions of the added stream, information on the length of the added stream, information indicating whether the added stream exists, and other information required to process the added stream may be included.

Although not shown in the figure, the data obtaining unit 7702 may include a meta information output unit and a transport channel access unit.

The meta information output unit outputs meta data on the provided broadcast service. Metadata provides information related to the broadcast service provided, such as ESG, EPG or OMABCAST service guide. Metadata may include information needed to process the transport package. For example, metadata may also include SDP data for processing IP flows. Information indicating the location of the transport channel containing the IP stream may also be included in the metadata. That is, various information about services can be considered as metadata. Hereinafter, the present invention will be described taking OMABCAST Service Guide as an example of metadata. The Service Guide must be obtained by continuously accessing the Service Guide Advertisement Channel and the Service Guide Delivery Channel to provide services according to OMABCAST. The transport channel for transmitting the Service Guide Announcement Channel can be specified in i-IMT in the SIC as described above. Accordingly, the meta information output unit obtains meta data on services provided through the transport channel from i-IMT and then outputs it.

If the MCAST transmission system supports high-speed access such as the above-mentioned main service, it is possible to provide the main service while obtaining metadata.

The transport channel access unit accesses a transport channel selected by a user to provide a broadcast service. Alternatively, a broadcast receiving device or a broadcast service provider may automatically select a transmission channel.

If the transport channel is selected, the data sent through the transport channel is obtained. Data transmitted through the transmission channel may be structured in packet units, byte stream units, or bit stream units. Error protection codes can be added to data to correct errors therein. In this case, errors are corrected using error protection codes. As mentioned above, data sent over the transport channel may exist at a specific location or a location known to the SIC, and the transport channel access unit may process all such information. However, according to another embodiment of the present invention, the processing of such information may be performed by the data processing unit 7703 .

The data processing unit 7703 processes the obtained data. Data can be processed in packet units, byte stream units, or bit stream units. If data is handled in packet units, a header exists in each packet. Each header contains the configuration information of the packet, and restores the original data based on the configuration information.

Specifically, the MCAST transmission system according to the current embodiment segments application data into encapsulated packets and segments the encapsulated packets into transport packets. In this case, the data processing unit 7703 restores the encapsulated packet by using the header information of the transport packet and restores the original application data by using the header information of the encapsulated packet.

According to another embodiment of the present invention, data may be processed in a packet stream. In this case, configuration information (for example, the above-mentioned LMT) on the packet flow is obtained, and then, data is obtained by processing packets included in the packet flow.

The data obtained by outputting from an output device (not shown) after decoding or not being decoded. The output device processes and outputs data in access units (AUs) to provide broadcast services to users. AU represents a minimum unit that can be divided and processed by an output device or a decoding device. For example, in the case of video, I, P, and B frame packets may be AU units, and in the case of MPEG-2 transport packets, PES or segment data may be AU units.

Although not shown in the figure, the broadcast receiving device may further include a channel setting module, an RF receiver, a baseband processor, and an embedded stream information receiver. The channel setting module sets the frequency to the channel, and the RF receiving device receives a signal corresponding to the set frequency. The baseband processor processes the received signal, transforming it into a bit stream to process the subsequent part of the signal. The embedded stream information receiver receives information about the embedded stream. The information about the embedded stream can be any information required to process the embedded stream, including specifying the presence or absence of an embedded stream, the type of embedded stream, or the method of processing the embedded stream, e.g., outer interleaving, RS parity information, time interleaving Information.

If the first transport stream includes the second transport stream in the same or different format, the embedded stream described with reference to FIG. 77 is used to indicate the included second transport stream. Accordingly, information for processing the embedded stream is transmitted in-band or out-of-band, or a predetermined situation or value is used so that the broadcast receiving device can recognize the information.

FIG. 78 is a flowchart illustrating a method of receiving broadcast according to an embodiment of the present invention.

In operation S7810, the frequency of the channel is set.

In operation S7820, a signal corresponding to the set frequency is received.

In operation S7830, information on the embedded stream is received.

In operation S7840, signaling information including information for processing the one or more transport channels is obtained. In this specification, signaling information may be sent through the SIC.

In operation S7850, the information of the transmission channel is provided to the user to derive the user's selection.

In operation S7860, a transmission channel for providing a service is selected based on a user's input. Alternatively, a predetermined transmission channel may be selected as a default.

In operation S7870, data is received using one or more transmission channels.

In operation S7880, the received data is processed.

In operation S7890, the processed data is output.

The transmission frame according to the embodiment of the present invention may be transmitted through the transmission frame used in the ATSC transmission system or separately. If a transport frame containing a transport stream used in another transport system is transmitted, some operations shown in FIG. 78 may be skipped according to another embodiment of the present invention.

Fig. 79 schematically shows an A-VSBMCAST receiving system according to an embodiment of the present invention.

The broadcast signal received through the tuner is provided to a user through a physical layer, a data link layer, a transport layer, and an application layer. The operation of the layers shown in Figure 79 is inverse to those in the MCAST transport system.

The physical layer obtains the MCAST transmission frame from the received broadcast signal. The MCAST transmission frame can be inserted into a transmission frame in another transmission system and then sent. Therefore, the physical layer must obtain the MCAST transmission frame. If the MCAST transmission frame is inserted into the ATSC transmission frame and then transmitted, the MCAST transmission frame is obtained by checking a 'deterministic framesync (DFS)' field, wherein the MCAST transmission frame is divided into N packets. The MCAST transmission frame has a definite structure, so N packets can be included in the MCAST transmission frame regardless of whether there is an error or not.

The data link layer corrects errors in data sent over the turbo channel and in pieces of signaling information sent over the SIC. The sender can apply specific FEC (code rate, etc.) to each turbo channel. Specifically, robust FEC can be applied to signaling information in the SIC. The data link layer in the broadcast receiving device can perform error correction using additional codes such as FEC.

The transport layer in the broadcast receiving device includes a packetization layer and an encapsulation layer. The packaging layer processes multiplexed transport packets to create encapsulated packets, and the encapsulation layer processes encapsulated packets to restore original application data and application-specific information. Application data may include real-time media data, IP data, object data and signaling data.

The transmission frame used in the MCAST transmission system has a definite structure. That is, there are integral packets in one transmission frame. When the transmission frame has a definite structure, it is valid because the "sync" field or the "CC" field can be removed from the packet. However, in the system that multiplexes and transmits data in units of packages according to the present invention, multiplexing using packages requires all packages constituting a package to be received. If errors occur in some packets, the erroneous packets must be received to form the package. Alternatively, the sub-data channel end offset value and the location of the data in the actual packet are changed, thereby avoiding complete reception of all packets. For example, information such as LMT indicating a position of a transmission channel indicates a position of data by using an offset value in a frame, and thus, a physical layer has to transmit even an error packet to an upper layer.

Therefore, when an error occurs in a specific packet, it is necessary to indicate that the occurrence of an error in that packet is indicated or that the packet demultiplexing means be notified of this fact. The occurrence of an error can be notified as follows:

First, the occurrence of an error is indicated by the "error_indicator" field in the header. This method is used in the case of MPEG-2TS. However, packet efficiency is reduced since new fields must be added to the packet header.

Second, a hardware signal flag is used to indicate that an error has occurred in the current packet. When the 'error_indicator' field is not used, an error occurrence is indicated through additional signaling. However, overhead occurs because the signaling information must be synchronized with the packets.

Third, an additional field not specified in the standard is generated for each packet, and an "error_indicator" field is included in the additional field. However, it is inconvenient since the terminal must separately insert information indicating that an error has occurred.

In order to solve these problems, the occurrence of an error is implicitly indicated using a combination of fields showing an error according to the structure of the header. Occurrence of an error can be indicated by constructing a header of an erroneous packet that does not exist in the actual packet. That is, the header of the error packet is constructed using a combination of fields that cannot actually exist in the packet header. Since such a header structure cannot exist, the packet demultiplexing unit determines that a packet having such a header structure is an error packet.

An embodiment of the header of an error packet defined in MCAST is shown below:

First_last0x00

DC_flag0x01

These fields indicate that the encapsulated packet is not the first packet and include decoder configuration information.

Decoder configuration information is always included in the first packet where there is an encapsulating packet, and thus cannot exist in an MCAST packet. Therefore, the terminal determines that a packet showing such a header structure is an error packet.

FIG. 80 is a block diagram of a broadcast receiving device capable of indicating an error packet according to an embodiment of the present invention. Referring to FIG. 80 , the broadcast receiving device includes an RF module 8001 , a baseband processing unit 8802 , a DFS sensing unit 8003 , a front head insertion unit 8004 , a demultiplexing unit 8005 and a renderer 8006 .

The RF module 8001 receives analog broadcast signals, and the baseband processing unit 8802 generates bit streams according to ATSC and A-VSB standards. The DFS sensing unit 8003 divides the bit stream into N packets.

Preamble inserting unit 8004 inserts a preamble into each packet. According to the type of the packet, the preamble may include an identifier indicating the type of the packet, error information indicating whether there is an error in the packet, and a 'CC' field for checking whether there is continuity. By using the "CC" field, it is possible to determine whether there is packet loss.

The structure of the pre-header according to the embodiment of the present invention will be described later with reference to FIG. 82 .

The demultiplexing unit 8005 demultiplexes the transport packets. In this case, an identifier indicating the type of packet included in the preamble may be used.

The renderer 8006 processes data and outputs processing results.

FIG. 81 is a flowchart illustrating a method of receiving a broadcast indicating an error packet according to an embodiment of the present invention.

In operation S8110, a bit stream is received from the baseband processor.

In operation S8120, the bit stream is divided into N packets by using DFS. The value of N can vary according to the transmission mode.

In operation S8130, error correction is performed. The error correction method corresponds to the error protection method used at the sending end. For example, RS decoding or outer decoding may be performed.

In operation S8140, the type of the packet is identified. For example, it is determined whether the transport packet is a signaling packet containing signaling data or an ordinary data packet.

In operation S8150, an identifier is added to each packet according to the packet type. For example, "0x30" is added as an identifier to a signaling packet containing signaling information, and "0x47" is added as an identifier to a normal MCAST transport packet.

In operation S8160, it is determined whether there is an error in each packet, and when there is an error, information indicating this fact is added to the packet with the error.

In operation S8170, it is determined whether all the above operations are performed on all packets. If not, repeat the above operations.

In operation S8180, the packet is processed at the transport layer by the demultiplexer.

The above operations S8110 to S8170 are performed by the baseband processor or under the transport layer.

82A and 82B illustrate the structure of a preamble according to an embodiment of the present invention.

The preamble may include a sync byte and a CC field.

The sync byte is one byte and contains identification information identifying the packet type. For example, "0x38" may indicate a signaling packet, and "0x47" may indicate a normal data packet.

The CC field is a 1-byte field and may contain an error flag indicating whether there is an error in the packet. When there is an error, the 1-bit CC field may be used to indicate the error.

For example, "0, 1, 2, 3, 4, ..., 254, 255, 0, 1, 2, 3, ..." indicates no error, "0, 1, 2, 3, 4, . .., 126, 127, 0, 1, 2, 3, ..." indicates that there is an error.

FIG. 83 is a flowchart illustrating a method of processing DCI by a broadcast receiving device according to an embodiment of the present invention.

In operation S8310, the MCAST transmission packet is received.

In operation S8310, the RAP flag is checked.

If the RAP flag is activated, a wrapper is constructed at operation S8330.

In operation S8340, DCI is checked.

In operation S8350, the DCI field is parsed.

In operation S8360, a decoder is set to correspond to the DCI field.

FIG. 84A shows a method of updating a TCC in adaptive time slicing according to an embodiment of the present invention.

Referring to FIG. 84A, a GOF includes five frames, and numbers 0 to 5 are assigned to frames belonging to each GOF, respectively.

The "TCC_next_update_offset" field may be sent through the "serviceconfigurationinformation" field in the SIC and indicates the frame, TCC to be updated. That is, if the 'TCC_next_update_offset' field has a value of 4, it means that the TCC is updated after 4 frames.

The value of the 'Next_update_offset' field varies according to the channel type, and the 'TCC_next_update_offset' field and the 'Next_update_offset' field may be used to calculate a time point of updating the TCC in each channel. In the current embodiment, the time point of updating the TCC in the turbo channel is (TCC_next_update_offset+Next_update_offset).

First, the time point of TCC updated in the channel will be described.

When receiving a frame having a value of 1 and belonging to the first GOF, the broadcast receiving apparatus obtains the values of the 'TCC_next_update_offset' field and the 'Next_update_offset' field. In the current embodiment, the value of the 'TCC_next_update_offset' field is '4', and the value of the 'Next_update_offset' field is '0'. Accordingly, turbo channel configuration information (TCC) of channel A is updated at a time point indicated by the sum of values of the 'TCC_next_update_offset' field and the 'Next_update_offset' field (ie, after 4 frames). Therefore, the changed TCC is applied starting from the frame having the value 5 and belonging to the first GOF.

Similarly, in channel B the changed TCC is applied starting from the frame with value 2 and belonging to the second GOF, and in channel C the changed TCC is applied starting from the frame having value 5 and belonging to the second GOF.

FIG. 84B illustrates an update method using BDs in adaptive time slicing according to an embodiment of the present invention. In detail, FIG. 84B shows a method of updating IMT and channel information by using information contained in a BD. Similar to FIG. 84A , GOF is composed of 5 frames, and numbers 0 to 5 are assigned to frames belonging to each GOF, respectively.

If the assumed frame has a value of 1 and belongs to the first GOF, the broadcast receiving device obtains the value of the 'BD_next_update_offset' field. In the current embodiment, the value of the 'BD_next_update_offset' field is '4'.

In addition, the values of the "update_frame_counter" (or "channel_info_update") field included in the "channel_info_descriptor" field and the "extended_version" field included in the "IMT" field are obtained. In the current embodiment, the 'BD_next_update_offset' field has a value of '4', and the 'extendedversion' field has a value of '0'. Therefore, the IMT is updated at a time point indicated by the sum of values of the 'BD_next_update_offset' field and the 'extendedversion' field (ie, after 4 frames). Therefore, the updated IMT is applied starting from the frame with value 5 and belonging to the first GOF.

In addition, turbo channel information is updated at a time point indicated by the sum of values of the 'BD_next_update_offset' field and the 'update_frame_counter' field (ie, after 7 frames). Therefore, the updated channel information is applied starting from the frame having the value 2 and belonging to the second GOF. Updating turbo channel information refers not only to changing turbo channel configuration information, but also to adding or canceling some turbo channels.

When a BD is composed of a plurality of frames, the value of the 'update_frame_counter' field is greater than '0'.

FIG. 85 is a block diagram of an apparatus 8500 for transmitting a broadcast service according to an embodiment of the present invention.

Referring to FIG. 85 , an apparatus 8500 includes an encapsulation packet generation unit 8510 , a transport packet generation unit 8520 , and a service configuration information generation unit 8530 .

The encapsulated packet generating unit 8510 receives the application data, generates an encapsulated packet including configuration information adapted to the application data to be transmitted and the type of the application data, and outputs the encapsulated packet to the transport packet generating unit 8520 .

In an embodiment of the present invention, the application data is one of signaling data, real-time media data, IP data and object data. The information on the package is set differently according to the type of application data.

Specifically, the encapsulated packet including real-time media data according to the embodiment of the present invention includes decoder configuration information (DCI) specifying a specification of a target decoder in a header area.

The transport packet generating unit 8520 receives the encapsulated packet from the encapsulated packet generating unit 8510, divides the encapsulated packet into at least one of transport packets of a predetermined size including data of the encapsulated packet and information on the encapsulated packet itself, and outputs the transport packet to the service Configuration information generating unit 8530.

According to an embodiment of the present invention, the transport packet generating unit 8520 generates a transport packet including a base header area, a pointer area, a padding area, a location map table (LMT) area, a link information table (LIT) area, and a payload area.

The service configuration information generating unit 8530 receives the transport packet from the transport packet generating unit 8520, generates service configuration information including setting information on channels including the transport packet, and outputs the service configuration information from at least one transport channel on the transport stream to a predetermined position The SIC.

According to an embodiment of the present invention, the service configuration information generation unit 8530 includes a service configuration information determination unit for determining service configuration information including information about a turbo channel and frame group information.

FIG. 86 is a block diagram of an apparatus 8600 for receiving a broadcast service according to an embodiment of the present invention. Referring to FIG. 86 , a device 8690 includes a transport channel determination unit 8610 , a transport packet extraction unit 8620 , a transport packet information extraction unit 8630 , an encapsulation packet combination unit 8640 , and an application data combination unit 8650 .

The transport channel determining unit 8610 determines a predetermined transport channel by using service configuration information extracted from a service information channel at a predetermined position on the received frame, and outputs information on the determined transport channel to the transport packet extracting unit 8620.

According to an embodiment of the present invention, information on a turbo channel and frame group information are extracted from service configuration information.

The transport packet extraction unit 8620 extracts transport packets from the transport channel determined by the transport channel determination unit 8610 , and outputs the transport packets to the transport packet information extraction unit 8630 .

The transport packet information extraction unit 8630 extracts transport packet information from the transport packet extracted by the transport packet extraction unit 8620 , and outputs the transport packet to the encapsulation packet combining unit 8640 .

The capsule combining unit 8640 obtains a combination of capsules including at least one transport packet by using the extracted transport packet information, and outputs it to the application data generating unit 290 .

In the current embodiment, the basic configuration information, LMT, LIT and program clock reference are extracted from the transport packet.

The application data combining unit 8650 receives a combination of capsules from the capsule combining unit 8640, extracts capsule information from the capsules, and generates application data including at least one capsule by using the extracted capsule information.

FIG. 87 is a flowchart illustrating a method of transmitting a broadcast service according to an embodiment of the present invention.

In operation 8710, an encapsulation packet including configuration information adapted to the application data to be transmitted and the type of the application data is generated.

In operation 8720, a transport packet including data on the encapsulated packet is obtained by dividing the encapsulated packet into packets of a predetermined size. A transport packet includes information about the structure of the transport packet.

In operation 8730, service configuration information including setting information sets on channels including the transport packet is generated and included in the SIC at a predetermined position in at least one transport channel on the transport stream.

FIG. 88 is a flowchart illustrating a method of receiving a broadcast service for mobile communication according to an embodiment of the present invention.

In operation 8810, a predetermined transmission channel is determined by using the service configuration information extracted from the SIC.

In operation 8820, the transport packet is extracted from a predetermined transport channel.

In operation 8830, information about the transport packet is extracted from the transport packet.

At operation 8840, combinations of encapsulated packets each having at least one transport packet are generated using the information about the transport packets.

In operation 8850, a combination of application data including at least one capsule is generated using the information about the capsule extracted from the capsule.

The above embodiments of the present invention can be implemented as computer programs and realized on general-purpose digital computers that execute the programs using a computer-readable recording medium. Examples of computer-readable recording media include magnetic storage media (eg, ROM, floppy disk, hard disk, etc.), optical recording media (eg, CD-ROM or DVD), and storage media such as carrier waves (eg, transmission via the Internet).

Each block of the data fields, packet structure, API, and flowcharts used to explain the embodiments of the present invention can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing device of a manufacturing machine, and the instructions executed by the computer or other programmable data processing device create a method for executing the blocks in the flow chart device for the functions specified in . These computer program instructions can also be stored in a computer-usable or computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-usable or computer-readable memory generate A device that performs the function specified in the box. Computer program instructions may also be loaded into a computer or other programmable data processing device to cause a series of operational steps to be performed on the computer or other programmable data processing device to generate a computer-executed process, thereby making the computer or other programmable data processing device The instructions executed above provide the steps for performing the functions specified in the blocks.

Each block of the flowchart may represent a module, segment, or portion of code that includes one or more executable instructions for implementing specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the flowchart may occur out of the order. For example, two blocks shown in succession may, in fact, be executed concurrently or the blocks may sometimes be executed in the reverse order, depending upon the related functionality.

Also, the data fields and packets shown in this specification may be replaced by other data fields and packets capable of performing the same functions.

Claims (4)

1. A method for transmitting a mobile broadcast service, the method comprising: generating an encapsulation packet including application data, wherein the application data is segmented into at least one encapsulation packet; generating a transport packet having an encapsulated packet and information about the application data, wherein the information about the application data includes location information for a mobile transport channel; and generate a transport stream comprising transport packets, Wherein, one of the plurality of transport channels included in the transport stream includes link information for binding the application data with the mobile transport channel, and the other of the plurality of transport channels included in the transport stream includes link information for The location information of the mobile transmission channel. 2. A method for receiving a broadcast service for mobile communication, the method comprising: By using at least one of position information for the transport channel extracted from one of the plurality of transport channels included in the transport stream and link information extracted from another of the plurality of transport channels included in the transport stream to determine a predetermined transmission channel; Extracting transport packets from a determined transport channel; extracting information about the transport packet from the extracted transport packet; each combination of encapsulated packets having at least one transport packet is obtained by extracting information about the transport packet; and The combination having the application data fragmented into at least one capsule is obtained by using the information on the capsules from which the information on the capsules is extracted. 3. An apparatus for transmitting mobile broadcast services, the apparatus comprising: An encapsulation generating unit for generating an encapsulation including application data, wherein the application data is fragmented into at least one encapsulation; a transport packet generating unit that generates a transport packet having an encapsulation packet and information on application data, wherein the information on application data includes location information for a mobile transport channel; and a transport stream generating unit that generates a transport stream including transport packets, Wherein, one of the plurality of transport channels included in the transport stream includes link information for binding the application data with the mobile transport channel, and the other of the plurality of transport channels included in the transport stream includes link information for The location information of the mobile transmission channel. 4. A device for receiving broadcast services for mobile communications, the device comprising: a transmission channel determining unit by using position information for the transport channel extracted from one of the plurality of transport channels included in the transport stream and a link extracted from another of the plurality of transport channels included in the transport stream at least one of the information to determine a predetermined transmission channel; a transport packet extracting unit, for extracting transport packets from a determined transport channel; a transport packet information extracting unit that extracts information about the transport packet from the extracted transport packet; an encapsulation combining unit for obtaining combinations of encapsulation packets each having at least one transport packet by using information about the transport packets; and The application data combining unit obtains a combination having the application data sliced into at least one package by using information on the packages from which the information on the packages is extracted.