KR20090031329A - Digital broadcasting receiver and method for controlling the same - Google Patents

Abstract

A digital broadcast receiver and a control method thereof for transmitting and receiving service data of the other format formality except the MH format are provided to select the service by offering various services to a user by performing various services through an MH system. A baseband process(100) receives mobile service data and the broadcast signal in which main service data is included. Mobile service data comprises first service data and second service data of the other format. The RS frame is comprised second service data. A table handler extracts signaling information of the second service data by parsing the table from the RS frame. The service handler parses the second service data from the RS frame based on signaling information of the second service data.

Description

Digital broadcast receiver and its control method {DIGITAL BROADCASTING RECEIVER AND METHOD FOR CONTROLLING THE SAME}

The present invention relates to a digital broadcast system, and more particularly, to a digital broadcast receiver and a control method thereof.

The digital broadcast system may include a digital broadcast transmitter and a digital broadcast receiver. The digital broadcast transmitter digitally processes data such as a broadcast program and transmits the data to the digital broadcast receiver. Such digital broadcasting systems are gradually replacing analog broadcasting systems due to various advantages such as efficiency of data transmission.

However, since the VSB (Vestigial Sideband) transmission method adopted as a digital broadcast standard in North America and Korea among digital broadcasts is a single carrier method, reception performance of a reception system may be degraded in a poor channel environment. In particular, in the case of a portable or mobile broadcast receiver, since the robustness against channel change and noise is further required, when the mobile service data is transmitted through the VSB transmission method, the reception performance is further deteriorated.

In addition, in the conventional mobile digital broadcasting environment, there is no specific technique for setting or releasing a reception restriction for a specific service. This is especially true if the service transmits, sets or cancels the reception of a service of a different data format.

An embodiment of the present invention is to provide a digital broadcast receiver resistant to channel changes and noise and a control method thereof.

Another embodiment of the present invention is to provide a data processing method for setting or releasing a reception restriction for a specific service in a mobile digital broadcasting environment.

In the data processing method of the reception system according to an embodiment of the present invention, a broadcast signal including mobile service data and main service data is received, and the mobile service data has a format different from the first service data and the first service data. A second service data of which may constitute an RS frame, the RS frame including a table describing second service data and signaling information of the second service data; Parsing the table from the RS frame to extract signaling information of the second service data; And parsing the second service data from the RS frame based on the extracted signaling information.

At least one data group constituting the RS frame includes a plurality of known data sequences, and includes a signaling information region between a first known data sequence and a second known data sequence among the known data sequences. The signaling information region may include transmission parameter channel (TPC) signaling and fast information channel (FIC) signaling.

The RS frame may include an RS frame header and an RS frame payload, and the RS frame payload may include a transport packet configured by packetizing at least one data for the second service.

The RS frame header may include first information for identifying a type of data in a transport packet transmitted through the payload, second information indicating whether an error exists in a transport packet transmitted through the payload; At least one of third information indicating whether a stuffing byte is included in a corresponding RS frame and fourth information indicating a start point of new data in a transport packet transmitted through the payload may be included.

The first information may be classified into a type of data in the transport packet, and the type may be divided into data for the first service and data for the second service.

In addition, the transport packet transmitted through the RS payload may include a flow packet including data for the second service.

The flow packet includes a flow packet header and a flow packet payload, and the flow packet payload includes length information regarding a layer packet and a length of the layer packet packetized in at least one layer for the second service. It may include.

The flow packet header may include identification information for identifying a layer packet included in the flow packet, information indicating whether the flow packet is transmitted over one or more RS frames, and whether a CRC is applied to the flow packet. Information indicating whether or not, and information indicating the number of layer packets included in the flow packet may include at least one.

The reception system according to an embodiment of the present invention receives a broadcast signal including mobile service data and main service data, and the mobile service data includes a first service data and a second service having a different format from the first service data. A baseband processor comprising data, wherein the second service data may constitute an RS frame, the RS frame including a second service data and a table in which signaling information of the second service data is described; A table handler which parses the table from the RS frame and extracts signaling information of the second service data; And a service handler for parsing the second service data from the RS frame based on the extracted signaling information of the second service data.

At least one data group constituting the RS frame includes a plurality of known data sequences, and includes a signaling information region between a first known data sequence and a second known data sequence among the known data sequences. The signaling information region may include transport parameter channel (TPC) signaling and fast information channel (FIC) signaling.

The baseband processor may further include a known data detector configured to detect a known data sequence included in the data group, and the detected known data sequence may be used for demodulation and channel equalization of mobile service data.

Further, the table handler extracts a table including signaling information of the second service data from the RS frame including an RS frame header and an RS frame payload, wherein the RS frame payload is at least for the second service. One data may include a transport packet configured to be packetized.

The table handler may include first information identifying a type of data in a transport packet transmitted through the payload, second information indicating whether an error exists in a transport packet transmitted through the payload, and a corresponding RS. Extracting the RS frame header information including at least one of third information indicating whether a stuffing byte is included in a frame and fourth information indicating a start point of new data in a transport packet transmitted through the payload; The service handler may be selected by identifying whether the type of data in the transport packet includes first service data or second service data from the extracted first information.

The selected service handler may also process a transport packet transmitted through the RS frame payload, wherein the transport packet includes a flow packet including data for the second service, and the flow packet is a flow packet. And a flow packet payload including a layer header packetized in at least one layer for the second service and length information regarding a length of the layer packet.

The service handler may include identification information for identifying a layer packet included in the flow packet, information indicating whether the flow packet is transmitted over one or more RS frames, and whether CRC is applied to the flow packet. The flow packet header including at least one of the information indicating and the information indicating the number of layer packets included in the flow packet may be processed.

According to an embodiment of the present invention, a digital broadcast receiver resistant to channel changes and noise and a control method thereof may be provided.

According to another embodiment of the present invention, service data of a format different from the existing MH system format may be transmitted and received in a mobile digital broadcasting environment.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention that can specifically realize the above object will be described. At this time, the configuration and operation of the present invention shown in the drawings and described by it will be described by at least one embodiment, by which the technical spirit of the present invention and its core configuration and operation is not limited.

Definition of terms used in the present invention

The terminology used in the present invention was selected as widely used as possible in the present invention in consideration of the functions in the present invention, but may vary according to the intention or custom of the person skilled in the art or the emergence of new technology. In addition, in certain cases, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the corresponding description of the invention. Therefore, it is intended that the terms used in the present invention should be defined based on the meanings of the terms and the general contents of the present invention rather than the names of the simple terms.

Among the terms used in the present invention, the main service data is data that can be received by the fixed receiving system and may include audio / video (A / V) data. That is, the main service data may include A / V data of a high definition (HD) or standard definition (SD) level, and may include various data for data broadcasting. Known data is data known in advance by an appointment of a transmitting / receiving side.

Among the terms used in the present invention, MH is the first letter of each of mobile and handheld, and is a concept opposite to a fixed form. The MH service data includes at least one of mobile service data and handheld service data. In the present invention, MH service data may be referred to as mobile service data for convenience of description. In this case, the mobile service data may include not only MH service data but also any service data indicating movement or portability, and thus the mobile service data will not be limited to the MH service data.

The mobile service data defined as described above may be data having information such as a program execution file, stock information, or the like, or may be A / V data. In particular, the mobile service data may be A / V data having a smaller resolution and a smaller data rate than the main service data as service data for a portable or mobile terminal (or broadcast receiver). For example, if the A / V codec used for the existing main service is an MPEG-2 codec, the MPEG-4 codec that has better image compression efficiency as the A / V codec for mobile services. AVC (Advanced Video Coding), SVC (Scalable Video Coding), or the like may be used. In addition, any kind of data may be transmitted as the mobile service data. For example, TPEG (Transport Protocol Expert Group) data for broadcasting traffic information in real time may be transmitted as mobile service data.

In addition, as a data service using the mobile service data, weather services, transportation services, securities services, viewer participation quiz program, real-time polls, interactive educational broadcasts, game services, drama plot, characters, background music, shooting location Providing information on the program, service history, the profile and performance of the athletes, and information on the program by service, media, time, or subject to enable product information and ordering. Services, etc., but the present invention is not limited thereto.

The transmission system of the present invention enables multiplexing of main service data and mobile service data on the same physical channel without backward affecting the reception of main service data in an existing receiving system.

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

When the transmission system according to the present invention is used, the reception system enables mobile reception of mobile service data, and also enables stable reception of mobile service data against various distortions and noises generated in a channel.

Receiving system

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

The receiving system according to the present embodiment includes a baseband processor 100, a management processor 200, and a presentation processor 300.

The baseband processor 100 includes an operation controller 110, a tuner 120, a demodulator 130, an equalizer 140, and a known data detector. 150, Mobile Handheld Block Decoder 160, Primary Reed Solomon Frame Decoder 170, Secondary RS Frame Decoder 180, and Signaling Decoder 190 It may include.

The operation controller 110 controls the operation of each block of the baseband processor 100.

The tuner 120 serves to receive main service data, which is a broadcast signal for a fixed broadcast receiver, and mobile service data, which is a broadcast signal for a mobile broadcast receiver, by tuning the reception system to a frequency of a specific physical channel. . In this case, the tuned frequency of the specific channel is down-converted to an intermediate frequency (IF) signal and output to the demodulator 130 and the known data detector 140. The passband digital IF signal output from the tuner 120 may include only main service data, only mobile service data, or may include both main service data and mobile service data.

The demodulator 130 performs automatic gain control, carrier recovery, and timing recovery on the digital IF signal of the pass band input from the tuner 120 to form a baseband signal, and then the equalizer 140 and the known data detector ( The demodulator 130 may improve demodulation performance by using a known data symbol string received from the known data detector 150 during timing restoration or carrier recovery.

The equalizer 140 compensates for the distortion on the channel included in the signal demodulated by the demodulator 130 and outputs the same to the block decoder 160. The equalizer 140 may improve equalization performance by using a known data symbol string received from the known data detector 150. In addition, the equalizer 140 may improve the equalization performance by receiving feedback of the decoding result of the block decoder 150.

The known data detector 150 detects the known data position inserted by the transmitting side from the input / output data of the demodulator 130, that is, the data before the demodulation is performed or the data of which the demodulation is partially performed, and the position along with the position information. And outputs a sequence of known data generated by the signal to the demodulator 130 and the equalizer 140. The known data detector 150 is further subjected to additional encoding and additional encoding by the mobile service data. Information for distinguishing the main service data from the block decoder 160 is output to the block decoder 160.

The block decoder 160 transmits if the data input after channel equalization in the equalizer 140 is data in which both block encoding and trellis encoding are performed at the transmitting side (that is, data in RS frame and signaling data). Inversely, trellis decoding and block decoding are performed, and if trellis encoding is performed without block encoding and only trellis encoding is performed (ie, main service data), only trellis decoding is performed.

The signaling decoder 190 decodes the input signaling data after channel equalization in the equalizer 140. It is assumed that signaling data input to the signaling decoder 190 is data in which both block encoding and trellis encoding are performed in the transmission system. Such signaling data may be, for example, Transmission Parameter Channel (TPC) data and Fast Information Channel (FIC) data. Each data is described in detail below. The FIC data decoded by the signaling decoder 190 is output to an FIC handler 215, and the decoded TPC data is output to a TPC handler 214.

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

The primary RS frame decoder 170 receives an output of the block decoder 160 as an input. At this time, the primary RS frame decoder 170 receives only mobile service data encoded with Reed Solomon (RS) encoding and / or cyclic redundancy check (CRC) encoding from the block decoder 160. That is, the primary RS frame decoder 170 receives only mobile service data, not main service data. The primary RS frame decoder 170 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the primary RS frame. That is, the primary RS frame decoder 170 collects a plurality of data groups to form a primary RS frame, and then performs error correction on a primary RS frame basis. In other words, the primary RS frame decoder 170 decodes the primary RS frame transmitted for the actual broadcast service.

The secondary RS frame decoder 180 receives an output of the block decoder 160 as an input. In this embodiment, the secondary RS frame decoder 180 receives only RS encoded and / or CRC encoded mobile service data. That is, the secondary RS frame decoder 180 receives only mobile service data, not main service data. The secondary RS frame decoder 180 performs an inverse process of an RS frame encoder (not shown) of the transmission system to correct errors in the secondary RS frame. That is, the secondary RS frame decoder 180 collects a plurality of data groups to form a secondary RS frame and then performs error correction on a secondary RS frame basis. In other words, the secondary RS frame decoder 180 decodes the secondary RS frame transmitted for mobile audio service data, mobile video service data, guide data, and the like.

Meanwhile, the management processor 200 according to an embodiment of the present invention may include an MH Physical Adaptation Processor 210, an IP network stack 220, and a streaming handler 230. ), SI handler 240, file handler 250, MIME type handler (MIME (multipurpose Internet Mail Extensions) type handler) 260, ESG handler (270), An ESG decoder 280 and a storage 290 may be included.

The MH physical adaptation processor 210 may include a primary RS frame handler 211, a secondary RS frame handler 212, and an MH-TP handler 213. ), A TPC handler 214, an FIC handler 215, and a Physical Adaptation Control Signal Handler 216.

The TPC handler 214 receives and processes baseband information required by modules corresponding to the MH physical adaptation processor 210. The baseband information is input in the form of TPC data, and the TPC handler 214 The FIC data received from the baseband processor 100 is processed using this information.

The TPC data is transmitted from the transmitting system to the receiving system through a predetermined area of the data group. The TPC data may include at least one of an MH-Ensemble ID, an MH-Subframe Number, a Total Number of MH-Groups (TNoG), an RS frame Continuity Counter, a Column Size of RS-frame (N), and an FIC Version Number. have.

The MH-Ensemble ID refers to an identification number for each MH ensemble transmitted on the corresponding physical channel (Identification number for each MH-Ensemble carried in this physical channel).

The MH-Subframe Number is a number indicating a subframe in an MH frame (A number that identifies the MH-Subframe number in an MH-frame, where each MH-Group associated with this MH-Ensemble is transmitted).

The total number of MH-Groups (TNoG) represents the total number of data groups belonging to all MH parades in one subframe (Total Number of MH-Groups including all the MH-Groups belonging to all the MH-Parades in one MH-Subframe).

The RS frame continuity counter is a number indicating a continuous indicator of the RS frame transmitted in the corresponding MH frame, and increases by 1 while adopting modulo 16 for each consecutive RS frame. frames carrying this MH-Ensemble.The value shall be incremented by 1 modulo 16 for each successive RS-frame).

The column size of RS-frame (N) is a column size of an RS frame belonging to the corresponding MH ensemble, and the size of each transport packet (MH-TP) is determined by this value (The column size of the RS-frame that belongs to this MH-Ensemble.This value determines the size of each MH-TP).

The FIC Version Number represents a version number of the FIC transmitted on the corresponding physical channel.

As described above, the above TPC data is input to the TPC handler 214 through the signaling decoder 190 of FIG. 1 and processed by the TPC handler 214 and also used by the FIC handler 215 to process the FIC data. do.

The FIC handler 215 processes the FIC data received from the baseband processor 100 in association with the TPC data received from the TPC handler 214.

The physical adaptive control signal handler 216 collects the FIC data received through the FIC handler 215 and the SI data received through the RS frame, and configures the access data of the IP datagram and the mobile broadcast service using the same. The process is stored in the storage unit 290.

The primary RS frame handler 211 configures MH-TP by dividing the primary RS frame received from the primary RS frame decoder 170 of the baseband processor 100 in units of rows, and MH-TP. Output to the handler 213.

The secondary RS frame handler 212 configures the MH-TP by dividing the secondary RS frame received from the secondary RS frame decoder 180 of the baseband processor 100 in units of rows, and MH-TP handler 213. )

The MH-TP handler 213 extracts each header of the MH-TP received from the primary and secondary RS frame handlers 211 and 212 to determine data included in the corresponding MH-TP. If the determined data is SI data, it is output to the physical adaptive control signal handler 216 (that is, the SI data is not encapsulated as an IP datagram), and in the case of the IP datagram, the IP network stack ( 220).

The IP network stack 220 processes broadcast data transmitted in the form of an IP datagram. That is, the IP network stack 220 includes User Datagram Protocol (UDP), Real-time Transport Protocol (RTP), Real-time Transport Control Protocol (RTC), Asynchronous Layered Coding / Layered Coding Transport (FLC), and FLUTE. Processes input data such as (File Delivery over Unidirectional Transport). At this time, if the processed data is streaming data, it is output to the streaming handler 230, if the data of the file (File) type is output to the file handler 250, and if the data for SI is output to the SI handler 240. .

The SI handler 240 receives and processes SI data in the form of an IP datagram input to the IP network stack 220.

The SI handler 240 outputs to the MIME type handler 260 when the data on the input SI is a MIME type.

The MIME type handler 260 receives and processes SI data of a MINE type output from the SI handler 240.

The file handler 250 receives data from the IP network stack 220 in the form of an object according to ALC / LCT, FLUTE structure. The file handler 250 collects the received data and configures the file in a file form. When the file includes the ESG (Electronic Service Guide), the file handler 250 outputs the data to the ESG handler 270. In one case, the output is output to the presentation controller 330 of the presentation processor 300.

The ESG handler 270 processes the ESG data received from the file handler 250 and stores the ESG data in the storage unit 290 or outputs the ESG decoder 280 to use the ESG data in the ESG decoder 280. do.

The storage unit 290 stores the system information (SI) received from the physical adaptive control signal handler 216 and the ESG handler 270, and transmits the stored data to each block.

The ESG decoder 280 restores the ESG data and the SI data stored in the storage unit 290 or the ESG data received from the ESG handler 270 to the presentation controller 330 as a format for outputting to the user. Output

The streaming handler 230 receives data from the IP network stack 220 in the form of RTP and RTCP structures. The streaming handler 230 extracts an audio / video stream from the received data and outputs it to the audio / video decoder 310 of the presentation processor 300. The audio / video decoder 311 decodes the audio stream and the video stream received from the streaming handler 230, respectively.

The display module 320 of the presentation processor 300 receives the audio and video signals decoded by the A / V decoder 310 and provides them to the user through a speaker and / or a screen.

The presentation controller 330 is a controller in charge of modules outputting data received by a receiving system to a user.

The channel service manager 340 is in charge of the interface with the user in order to enable the user to use a broadcast service transmitted on a channel basis, such as channel map management and channel service access.

The application manager 350 manages an interface with a user for using an application service, not an ESG display or other channel service.

Data format structure

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

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

In the data configuration according to FIG. 2, an example of dividing a data group into ten MH blocks BM to B10 is shown. Each MH block has a length of 16 segments. In FIG. 2, the first 5 segments of the MH block B1 and the 5 segments after the MH block B10 allocate only RS parity data to a part of the data, and exclude the data from the A region and the D region of the data group.

That is, assuming that one data group is divided into areas A, B, C, and D, each MH block may be included in any of areas A through D according to the characteristics of each MH block in the data group. . At this time, according to an embodiment of the present invention, each MH block is included in any one of the A region and the D region according to the degree of interference of the main service data.

Here, the reason why the data group is divided into a plurality of areas is used for different purposes. That is, an area where there is no or little interference of the main service data may exhibit stronger reception performance than an area that is not. In addition, when applying a system for inserting and transmitting known data known to the data group by the promise of the transmitting / receiving party, when a long period of continuous data is to be inserted periodically into the mobile service data, the main service It is possible to periodically insert known data of a certain length into an area where data does not interfere (that is, an area where main service data is not mixed). However, it is difficult to periodically insert known data into the region where the main service data interferes with the interference of the main service data, and also to insert long known data continuously.

The MH blocks B4 to MH blocks B7 in the data group of FIG. 2 show an example in which a long known data string is inserted before and after each MH block as an area without interference of main service data. In the present invention, the MH blocks B4 to MH blocks B7 will be referred to as an A region (= B4 + B5 + B6 + B7). As described above, in the case of the region A having the known data sequence back and forth for each MH block, the receiving system can perform the equalization using the channel information obtained from the known data, thereby providing the strongest equalization performance among the regions A to D. You can get

In the data group of FIG. 2, the MH block B3 and the MH block B8 are regions in which main service data has little interference, and a long known data string is inserted into only one side of both MH blocks. That is, due to the interference of the main service data, the long known data string may be inserted in the MH block B3 only after the corresponding MH block, and the long known data string may be inserted in the MH block B8 only in front of the corresponding MH block. In the present invention, the MH block B3 and the MH block B8 are referred to as a B region (= B3 + B8). As described above, in the case of the B region having only one known data sequence for each MH block, the receiving system can perform equalization using channel information obtained from the known data, which is more robust than the C / D region. You can get

The MH block B2 and the MH block B9 in the data group of FIG. 2 have more interference of the main service data than the B area, and both MH blocks cannot insert a long known data stream back and forth. In the present invention, the MH block B2 and the MH block B9 are referred to as a C region (= B2 + B9).

The MH block B1 and the MH block B10 in the data group of FIG. 2 have more interference of the main service data than the C region, and likewise, both MH blocks cannot insert a long known data stream back and forth. In the present invention, the MH block B1 and the MH block B10 will be referred to as a D region (= B1 + B10). Since the C / D region is far from the known data stream, the reception performance may be poor when the channel changes rapidly.

The data group also includes a signaling information area to which signaling information is allocated.

According to the present invention, a part of the first segment to the second segment of the MH block B4 in the data group may be used as the signaling information region.

According to an embodiment of the present invention, 276 (= 207 + 69) bytes of the MH block B4 of each data group are used as the signaling information region. That is, the signaling information area consists of 207 bytes, which is the first segment of the MH block B4, and the first 69 bytes of the second segment. The first segment of the MH block B4 corresponds to the 17th or 173th segment of the VSB field.

The signaling information can be largely divided into two types of signaling channels. One is the Transmission Parameter Channel (TPC) and the other is the Fast Information Channel (FIC).

The TPC data may include at least one of an MH-Ensemble ID, an MH-Subframe Number, a Total Number of MH-Groups (TNoG), an RS frame Continuity Counter, a Column Size of RS-frame (N), and an FIC Version Number. have. The TPC information is only an embodiment for better understanding of the present invention, and the present invention is not limited to the above embodiment because addition and deletion of signaling information included in the TPC can be easily changed by those skilled in the art. The FIC data is provided to enable fast service acquisition at the receiver, and includes cross layer information between a physical layer and an upper layer.

For example, when the data group includes six known data columns as shown in FIG. 2, the signaling information area is located between the first known data row and the second known data row. That is, the first known data string is inserted into the last two segments of the MH block B3 in the data group, and the second known data string is inserted into the second and third segments of the MH block B4. The third to sixth known data columns are inserted into the last two segments of the MH blocks B4, B5, B6, and B7, respectively. The first, third to sixth known data columns are spaced 16 segments apart.

In addition, in accordance with another embodiment of the present invention, MH data is transmitted to a data area for an interface of data for a MediaFLO service, which will be described later, and control data related to the media flow service is also transmitted to the data area. Can be sent. A more detailed description thereof will be described later in the corresponding sections and a detailed description thereof will be omitted.

3 is a diagram illustrating an RS frame according to an embodiment of the present invention.

The RS frame shown in FIG. 3 is a collection of one or more data groups. After receiving and processing the FIC, the RS frame is received for each MH frame while being switched to the time slicing mode to receive the MH ensemble including the ESG entry point. One RS frame may include IP streams of each service or ESG, and all RS frames may have SMT section data.

RS frame according to an embodiment of the present invention consists of at least one MH TP (Transport Packet). This MH TP consists of an MH header and an MH payload.

The MH payload may include signaling data as well as mobile service data. That is, one MH payload may include only mobile service data, may include only signaling data, or may include both service data and signaling data.

According to an embodiment of the present invention, data included in an MH payload is distinguished by an MH header. That is, when the MH TP has a first MH header, it indicates that the MH payload includes signaling data. In addition, when the MH TP has a second MH header, it indicates that the MH payload includes signaling data and service data. If the MH TP has a third MH header, it indicates that the MH payload contains service data.

3 shows an example of allocating IP datagrams (ie, IP Datagram 1 and IP Datagram 2) for two types of services.

Data transfer structure

4 is a diagram illustrating an example of an MH frame structure for transmission of mobile service data according to the present invention.

4 shows an example in which one MH frame consists of five subframes and one subframe consists of 16 slots. In this case, one MH frame means five subframes and 80 slots.

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

5 illustrates an example of a VSB frame structure, in which one VSB frame includes two VSB fields (ie, odd field and even field). Each VSB field consists of one field sync segment and 312 data segments.

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

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

On the other hand, when the slots are assigned to VSB frames, they have offsets in their positions.

FIG. 6 shows an example of mapping of the first 4 slot positions of a subframe to a VSB frame in a spatial domain. FIG. 7 shows an example of mapping of the first four slot positions of a subframe with respect to one VSB frame in the time domain.

6 and 7, the 38th data packet # 37 of the first slot (Slot # 0) is mapped to the first data packet of the odd VSB field and the 38th data of the second slot (Slot # 1). Packet # 37 is mapped to the 157th data packet of the order VSB field. In addition, the 38th data packet (# 37) of the third slot (Slot # 2) is mapped to the first data packet of the even VSB field, and the 38th data packet (# 37) of the fourth slot (Slot # 3) is It is mapped to the 157th data packet of the even VSB field. Similarly, the remaining 12 slots in that subframe are mapped in the same way to subsequent VSB frames.

FIG. 8 shows an example of a data group allocation order allocated to one subframe among five subframes constituting an MH frame. For example, the method of allocating data groups may be equally applied to all MH frames or may be different for each MH frame. In addition, the same may be applied to all subframes in one MH frame, or may be differently applied to each subframe. At this time, assuming that data group allocation is equally applied to all subframes in the MH frame, the number of data groups allocated to one MH frame is a multiple of five.

According to an embodiment of the present invention, a plurality of consecutive data groups are allocated as far apart from each other as possible in a subframe. This makes it possible to respond strongly to burst errors that can occur within one subframe.

For example, assuming that three groups are allocated to one subframe, the first slot (Slot # 0), the fifth slot (Slot # 4), and the ninth slot (Slot # 8) in the subframe are allocated. do. FIG. 8 shows an example in which 16 data groups are allocated to one subframe by applying such an allocation rule, and include 8, 4, 12, 1, 9, 5, 13, 2, 10, 6, 14, It can be seen that each of 16 slots is allocated in the order of 3, 11, 7, 15.

Equation 1 below expresses a rule for allocating data groups to one subframe as described above.

j = (4i + O) mod 16

Where O = 0 if i <4,

O = 2 else if i <8,

O = 1 else if i <12,

O = 3 else.

In addition, j is a slot number in one subframe and may have a value between 0 and 15. I is a group number and may have a value between 0 and 15.

In the present invention, a collection of data groups included in one MH frame will be referred to as a parade. The parade transmits data of one or more specific RS frames according to the RS frame mode.

Mobile service data in one RS frame may be allocated to all of the A / B / C / D areas in the data group or may be allocated to at least one of the A / B / C / D areas. According to an embodiment of the present invention, all mobile service data in one RS frame is allocated to the A / B / C / D region or only to one of the A / B region and the C / D region. That is, in the latter case, the RS frame allocated to the A / B area in the data group and the RS frame allocated to the C / D area are different. According to an embodiment of the present invention, the RS frame allocated to the A / B region in the data group is called a primary RS frame, and the RS frame allocated to the C / D region is a secondary RS frame. frame). The primary RS frame and the secondary RS frame form one parade. That is, if the mobile service data in one RS frame are all allocated to the A / B / C / D areas in the data group, one parade transmits one RS frame. In contrast, if the mobile service data in one RS frame is allocated to the A / B area in the data group and the mobile service data in the other RS frame is allocated to the C / D area in the data group, Up to RS frames can be transmitted.

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

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

RS frame mode Description 00 There is only a primary RS frame for all Group Regions 01 There are two separate RS frames -Primary RS frame for Group Region A and B -Secondary RS frame for Group Region C and D 10 Reserved 11 Reserved

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

Like the data group allocation, the parades may be allocated as far apart from each other as possible in the subframe. This makes it possible to respond strongly to burst errors that can occur within one subframe.

In addition, the method of allocating parades may be differently applied to every MH frame and may be equally applied to all MH frames. In addition, the same may be applied to all subframes in one MH frame, or may be differently applied to each subframe. The present invention may vary for each MH frame, and the same applies to all subframes in one MH frame. That is, the MH frame structure may vary in units of MH frames, which allows the MH ensemble data rate to be flexibly adjusted.

9 is a diagram illustrating an example of allocating a single parade to one MH frame. That is, FIG. 9 illustrates an embodiment of allocating a single parade having the number of data groups included in one subframe to three MH frames.

According to FIG. 9, if three data groups are sequentially allocated to one subframe at four slot periods, and this process is performed for five subframes in the corresponding MH frame, 15 data groups are allocated to one MH frame. do. The 15 data groups are data groups included in one parade. Therefore, one subframe is composed of four VSB frames, but one subframe includes three data groups. Therefore, one VSB frame among four VSB frames in one subframe is assigned a data group of the corresponding parade. It doesn't work.

For example, one parade transmits one RS frame, and RS encoding is performed by the RS frame encoder (not shown) of the transmitting system on the RS frame to add 24 bytes of parity data to the RS frame. Assuming transmission, in this case, the parity data occupies about 11.37% (= 24 / (187 + 24) x 100) of the length of all RS code words. Meanwhile, when three data groups are included in one subframe, and 15 data groups form one RS frame when data groups in one parade are allocated, one group is all caused by burst noise generated in a channel. Even in the event of an error, the proportion is 6.67% (= 1/15 x 100). Therefore, in the receiving system, all errors can be corrected by erasure RS decoding. That is, since erasure RS decoding can correct channel errors as many as the number of RS parities, all byte errors less than or equal to the number of RS parities in one RS codeword can be corrected. This allows the receiving system to correct errors in at least one data group in one parade. As such, the minimum burst noise length correctable by a RS frame is over 1 VSB frame.

Meanwhile, when data groups for one parade are allocated as shown in FIG. 9, main service data may be allocated between the data group and the data group, and data groups of another parade may be allocated. That is, data groups for a plurality of parades may be allocated to one MH frame.

Basically, the allocation of data groups for multiple parades is no different than for a single parade. In other words, data groups in the other parade allocated to one MH frame are also allocated in four slot periods.

In this case, the data group of another parade may be allocated in a kind of circular manner from the slot to which the data group of the previous parade is not allocated.

For example, assuming that data group allocation for one parade is performed as shown in FIG. 9, the data group for the next parade is allocated from the 12th slot in one subframe. This is an embodiment, and for example, the data group of the next parade may be sequentially allocated to another slot, for example, a third slot to a four slot period, in one subframe.

FIG. 10 shows an example of transmitting three parades (Parade # 0, Parade # 1, Parade # 2) in one MH frame, and in particular, parade transmission of one subframe among five subframes constituting the MH frame. An example is shown.

If the first parade includes three data groups per subframe, the positions of the data groups in the subframe can be obtained by substituting 0 to 2 for the i value of Equation 1 above. That is, data groups of the first parade are sequentially allocated to the first, fifth, and ninth slots (Slot # 0, Slot # 4, Slot # 8) in the subframe.

If the second parade includes two data groups per subframe, the positions of the data groups in the subframe can be obtained by substituting 3 to 4 into the i value of Equation 1 above. That is, data groups of the second parade are sequentially allocated to the second and twelfth slots #Slot # 11 in the subframe.

In addition, if the third parade includes two groups per subframe, the positions of the data groups in the subframe may be obtained by substituting 5 to 6 for the i value of Equation 1 above. That is, data groups of the third parade are sequentially allocated to the seventh and eleventh slots (Slot # 6 and Slot # 10) in the subframe.

As such, data groups for a plurality of parades may be allocated to one MH frame, and data group allocation in one subframe is performed serially from left to right with a group space of 4 slots.

Accordingly, the number of groups of one parade per a sub-frame (NOG) that may be allocated to one subframe may be any one of integers from 1 to 8. In this case, since one MH frame includes five subframes, this means that the number of data groups of one parade that can be allocated to one MH frame may be any one of multiples of 5 to 40. it means.

FIG. 11 illustrates an example in which the allocation process of the three parades of FIG. 10 is extended to five subframes in one MH frame.

FIG. 12 is a diagram illustrating a data transmission structure according to an embodiment of the present invention and illustrates a state in which signaling data is included and transmitted in a data group.

As described above, the MH frame is divided into five subframes, and data groups corresponding to several parades exist in each subframe, and data groups corresponding to each parade are grouped into MH frame units. Will make up the parade. In FIG. 12, three parades exist, one EDC Dedicated Channel (EDC) parade (NoG = 1), and two service parades (NoG = 4, NoG = 3). In addition, a portion of each data group (e.g. 37 bytes / data group) is used to convey encoded FIC information separately from RS encoding for mobile service data. The FIC region allocated to each data group constitutes one FIC segment, which is interleaved for each MH subframe to form one complete FIC. However, if necessary, these FIC segments may be interleaved in units of MH frames instead of subframes, and may have completeness in each MH frame.

Meanwhile, in the present embodiment, a set of services is defined by introducing an MH ensemble concept. One MH ensemble has the same QoS and is coded with the same FEC code. In addition, one MH ensemble has the same unique identifier (ie, ensemble id) and corresponds to consecutive RS frames.

As shown in FIG. 12, the FIC segment corresponding to each data group describes service information of the MH ensemble to which the data group belongs. When the FIC segments in one subframe are collected, all service information of the physical channel through which the corresponding FIC is transmitted can be obtained. Therefore, the receiving system can acquire channel information of the corresponding physical channel during the sub frame period after the physical channel tuning.

In FIG. 12, an EDC parade separate from the service parade is shown, and the electronic service guide (ESG) data is transmitted to the first slot position of each subframe.

Layered signaling structure

13 illustrates a layered signaling structure according to an embodiment of the present invention. As shown in FIG. 13, the mobile broadcasting technology according to the present embodiment employs a signaling method using FIC and SMT. This is called a layered signaling structure in the present invention.

Hereinafter, a description will be given of how the receiving system accesses the virtual channel by FIC and SMT using FIG. 13.

FIC, the physical channel level signaling data, indicates the physical location of each data stream for each virtual channel. The FIC defined in MH Transport (M1) identifies the physical location of each the data stream for each virtual channel and provides very high level descriptions of each virtual channel.

SMT, which is MH ensemble level signaling data, provides MH ensemble level signaling information. Each SMT provides IP access information of each virtual channel belonging to the corresponding MH ensemble in which each SMT is included. The SMT provides the Ensemble level signaling information.The SMT provides the IP access information of each virtual channel belonging to the MH Ensemble within which the SMT is carried, and all the IP stream component level information necessary for the virtual channel service acquisition.).

In brief, each MH ensemble (Ensemble 0, 1, ..., K) is a stream information (for example, Virtual Channel 0 IP Stream, Virtual Channel 1 IP Stream, Virtual Channel 2) for each associated virtual channel IP Stream). For example, Ensemble 0 includes Virtual Channel 0 IP Stream and Virtual Channel 1 IP Stream. In addition, each MH ensemble includes a variety of information on the associated virtual channel (Virtual Channel 0 Table Entry, Virtual Channel 0 Access Info., Virtual Channel 1 Table Entry, Virtual Channel 1 Access Info., Virtual Channel 2 Table Entry, Virtual Channel 2 Access. Info., Virtual Channel N Table Entry, Virtual Channel N Access Info.).

The FIC includes information about the MH ensemble (Ensemble Location in the figure, such as the ensemble_id field) and information about the virtual channel associated with the MH ensemble (major channel num field and minor channel num field, and the like. ., N).

Finally, the application in the receiving system is as follows.

When the user selects a channel that he wants to watch (referred to as 'channel θ' for convenience of explanation), the receiving system first parses the received FIC. The receiving system acquires information on the MH ensemble (called 'MH ensemble θ' for convenience of description) related to the virtual channel corresponding to the channel θ. The receiving system acquires only the slot corresponding to the MH ensemble θ by the time slicing method to configure the ensemble θ. The configured ensemble θ includes the SMT for the associated virtual channels (including channel θ) and the IP stream for the corresponding virtual channels, as described above. Accordingly, the receiving system obtains various information about the channel θ (Virtual Channel θTable Entry) and stream access information on the channel θ using the SMT included in the configured MH ensemble θ. The receiving system receives only the relevant IP stream using the stream access information on the channel θ and provides a service for the channel θ to the user.

Fast Information Channel (FIC)

In addition, the reception system according to the present invention introduces a fast information channel (FIC) to allow faster access to the currently broadcast service.

That is, the FIC is parsed by the FIC handler 215 of FIG. 1 and the result is output to the physical adaptive control signal handler 216.

14 illustrates an embodiment of an FIC format according to the present invention. According to the present embodiment, the FIC format includes a FIC body header and an FIC body.

Meanwhile, according to the present embodiment, data transmitted through the FIC body header and the FIC body are transmitted in units of FIC segments. Each FIC segment unit is 37 bytes in size, and each FIC segment consists of a 2-byte FIC segment header and a 35-byte FIC segment payload. That is, one FIC format consisting of an FIC body header and an FIC body is segmented by 35 bytes and carried in an FIC segment payload in one or more FIC segments.

In the present invention, one FIC segment is inserted into one data group and transmitted. In this case, the receiving system receives a slot corresponding to each data group by a time slicing method.

Meanwhile, the signaling decoder 190 in the reception system of FIG. 1 collects each FIC segment inserted into each data group. The signaling decoder 190 configures one FIC format using each collected FIC segment. Subsequently, the signaling decoder 190 performs a decoding operation on the FIC body of one FIC format corresponding to the encoding of the signaling encoder (not shown) in the transmission system, and the decoded FIC body is the FIC handler 215. Will output The FIC handler 215 parses the FIC data in the FIC body and outputs the parsed FIC data to the physical adaptive control signal handler 216. The physical adaptive control signal handler 216 performs an operation related to an MH ensemble, a virtual channel, an SMT, etc. using the input FIC data.

Meanwhile, according to an embodiment, when segmenting one FIC format, if the last segmented portion is 35 bytes or less, stuffing bytes in the remaining portion of the FIC segment payload to make the size of the last FIC segment 35 bytes. It can be assumed to fill.

Each byte value (FIC segment: 37 bytes, FIC segment header: 2 bytes, FIC segment payload: 35 bytes) described above is just one embodiment, and the present invention is not limited thereto.

15 is a diagram illustrating an embodiment of a data structure of an FIC segment according to the present invention. Here, the FIC segment refers to a unit used for transmitting FIC data.

The FIC segment consists of an FIC segment header and an FIC segment payload, and according to FIG. 15, the FIC segment payload may be referred to as a portion below a for loop. Meanwhile, the FIC segment header may include an FIC_type field, an error_indicator field, an FIC_seg_number field, and an FIC_last_seg_number field. Description of each field is as follows.

The FIC_type field (2 bits) indicates a type of the corresponding FIC.

The error_indicator field (1 bit) indicates whether an error occurs in the FIC segment during transmission, and is set to '1' when an error occurs. That is, when there is an error that cannot be recovered in the process of configuring the FIC segment, this field is set to '1'. Through this field, the receiving system can recognize whether there is an error in the FIC data.

The FIC_seg_number field (4 bits) indicates the number of the corresponding FIC segment when the corresponding FIC format is divided into several FIC segments and transmitted.

The FIC_last_seg_number field (4 bits) indicates the number of the last FIC segment of the corresponding FIC format.

FIG. 16 illustrates an embodiment of a bit stream syntax structure for a payload of an FIC segment when the FIC type field value is '0' according to the present invention.

In this embodiment, the payload of the FIC segment is divided into three regions.

The first region exists only when the FIC_seg_number is '0' and may include a current_next_indicator field, an ESG_version field, and a transport_stream_id field. However, according to an embodiment, it may be assumed that the above three fields are present regardless of FIC_seg_number.

The current_next_indicator field (1 bit) is an indicator for identifying whether the corresponding FIC data contains MH ensemble configuration information of an MH frame including a current FIC segment or MH ensemble configuration information of a next MH frame. Indicator).

The ESG_version field (5 bits) indicates version information of the ESG. The ESG_version field (5 bits) provides a version of the service guide providing channel of the corresponding ESG, and plays a role of informing the receiving system whether the ESG is updated.

A transport_stream_id field (16 bits) means a unique identifier of a broadcast stream in which a corresponding FIC segment is transmitted.

The second region is an ensemble loop region and may include an ensemble_id field, an SI_version field, and a num_channel field.

The ensemble_id field (8 bits) indicates an identifier of an MH ensemble in which MH services described later are transmitted. This field binds the MH services and the MH ensemble.

The SI_version field (4 bits) indicates version information of SI data of a corresponding ensemble transmitted in an RS frame.

The num_channel field (8 bits) indicates the number of virtual channels transmitted through the ensemble.

The third region may be a channel loop region and may include a channel_type field, a channel_activity field, a CA_indicator field, a stand_alone_service_indicator field, a major_channel_num field, and a minor_channel_num field.

The channel_type field (5 bits) indicates a service type of a corresponding virtual channel. For example, this field may indicate an audio / video channel, an audio / video and data channel, an audio dedicated channel, a data dedicated channel, a file download channel, an ESG delivery channel, a notification channel, and the like.

The channel_activity field (2 bits) indicates activity information of the corresponding virtual channel, and it can be known whether the corresponding virtual channel provides a current service.

The CA_indicator field (1 bit) indicates whether to apply Conditional Access (CA) to the corresponding virtual channel.

The stand_alone_service_indicator field (1 bit) indicates whether a service of a corresponding virtual channel is a stand alone service.

The major_channel_num field (8 bits) indicates a major channel number of the corresponding virtual channel.

The minor_channel_num field (8 bits) means a minor channel number of the corresponding virtual channel.

Service Map Table

FIG. 17 is a diagram illustrating an embodiment of a bit stream syntax of a service map table (hereinafter, referred to as "SMT") according to an embodiment of the present invention.

The SMT according to the present embodiment is written in the form of MPEG-2 Private Section, but the scope of the present invention is not limited thereto. The SMT according to the present embodiment includes description information of each virtual channel in one MH ensemble, and other additional information may be included in the descriptor area.

The SMT according to the present embodiment includes at least one field and is transmitted from the transmitting system to the receiving system.

As described above with reference to FIG. 3, the SMT section may be included in the MH TP in the RS frame and transmitted. In this case, the RS frame decoders 170 and 180 of FIG. 1 decode the input RS frame, and the decoded RS frame is output to the corresponding RS frame handlers 211 and 212. Each of the RS frame handlers 211 and 212 divides the input RS frame into rows to form an MH TP and outputs the MH TP to the MH TP handler 213.

When the MH TP handler 213 determines that the corresponding MH TP includes an SMT section based on the header of each MH TP input, the MH TP handler 213 parses the included SMT section to physically control SI data in the parsed SMT section. Output to handler 216. In this case, however, the SMT is not encapsulated into an IP datagram.

On the other hand, when the SMT is encapsulated into an IP datagram, the MH TP handler 213 determines that the MH TP includes an SMT section based on the header of each MH TP input. 220). The IP network stack 220 then outputs to the SI handler 240 after performing the IP and UDP processing on the SMT section. The SI handler 240 parses the input SMT section and controls the parsed SI to be stored in the storage unit 290.

Meanwhile, examples of fields that can be transmitted through SMT are as follows.

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

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

The num_channels field (8 bits) indicates the number of virtual channels in the SMT section.

Meanwhile, the SMT according to the present embodiment provides information about a plurality of virtual channels using a for loop.

(This 8-bit unsigned integer field in the range 0x00 to 0xFF shall represent the major channel number associated with this virtual. The major_channel_num field (8 bits) indicates the major channel number associated with the virtual channel. channel.).

The 8_bit unsigned integer field in the range 0x00 to 0xFF shall represent the minor channel number associated with this virtual channel.).

The short_channel_name field represents a short name of a virtual channel.

A service_id field (16 bits) indicates a value for identifying a virtual channel service (A 16-bit unsigned integer number that identifies the virtual channel service).

A 6-bit enumerated type field that shall identify the type of service carried in this virtual as defined in Table 2 below. channel as defined in Table 2).

0x00 [Reserved] 0x01 MH_digital_television-The virtual channel carries television programming (audio, video and optional associated data) conforming to ATSC standards 0x02 MH_audio-The virtual channel carries audio programming (audio service and optional associated data) conforming to ATSC standards 0x03 MH_data_only_service-The virtual channel carries a data service conforming to ATSC standards, but no video or audio component 0x04 to 0xFF [Reserved for future ATSC use]

The virtual_channel_activity field (2 bits) distinguishes whether the corresponding virtual channel is activated. If the most significant bit (MSB) of the virtual_channel_activity field is '1', this indicates that the virtual channel is active. If the MSB is '0', this indicates that the virtual channel is not active. In addition, when the LSB (least significant bit) is '1', it indicates that the corresponding virtual channel is a hidden channel, and when the LSB is '0', it indicates that the corresponding virtual channel is not a hidden channel (A 2-bit enumerated). field that shall identify the activity of this virtual channel.The most significant bit indicates whether this virtual channel is active (when set to 1) or inactive (when set to 0) and the least significant bit indicates whether this virtual channel is hidden (when set to 1) or not (when set to 0).).

A num_components field (5 bits) indicates the number of IP stream components on the corresponding virtual channel (This 5-bit field specifies the number of IP stream components in this virtual channel.).

The IP_version_flag field (1 bit) indicates that the source_IP_address field, the virtual_channel_target_IP_address field, and the component_target_IP_address field are IPv6 addresses when set to '1', and that the source_IP_address field, virtual_channel_target_IP_address field, and component_target_IP_address field are set to '0'. (A 1-bitindicator, which when set to '1' indicates that source_IP_address, virtual_channel_target_IP_address and component_target_IP_address fields if exist, are IPv6 addresses, and when set to '0' indicates that source_IP_address, virtual_channel_target_IP_address and component_target_IP_address fields are IPv4 addresses.).

When a source_IP_address_flag field (1 bit) is set, it indicates that a source IP address of a corresponding virtual channel exists for a specific multicast source (A 1-bit Boolean flag that indicates, when set, a source IP address of this virtual channel is present for source specific multicast.).

When the virtual_channel_target_IP_address _flag field (1 bit) is set, this indicates that the corresponding IP stream component is transmitted through an IP datagram having a target IP address different from the virtual_channel_target_IP_address. Therefore, when this flag is set, the receiving system uses component_target_IP_address as target_IP_address to access the corresponding IP stream component and ignores the virtual_channel_target_IP_address field in the num_channels loop (A 1-bit Boolean flag that indicates, when set, this IP stream). component is delivered through IP datagrams with target IP addresses different from virtual_channel_target_IP_address.When this flag is set, then the receiver shall utilize the component_target_IP_address as the target_IP_address to access this IP stream component and shall ignore the virtual_channel_target_IP_address field in the num_channels loop.).

The source_IP_address field (32 or 128 bits) needs to be interpreted when the source_IP_address_flag is set to '1', but does not need to be interpreted when the source_IP_address_flag is not set to '0'. When source_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit IPv4 address indicating a source of the corresponding virtual channel. If the IP_version_flag field is set to '1', this field shall indicate a 32-bit IPv6 address indicating the source of the virtual channel (This field shall present if the source_IP_address_flag is set to '1' and shall not present if the source_IP_address_flag is set to '0'.If present, when IP_version_flag field is set to' 0 ', this field specifies 32-bit IPv4 address indicating the source of this virtual channel.When IP_version_flag field is set to' 1 ', this field specifies 128- bit IPv6 address indicating the source of this virtual channel.).

The virtual_channel_target_IP_address field (32 or 128 bits) needs to be interpreted when the virtual_channel_target_IP_address_flag is set to '1', but does not need to be interpreted when the virtual_channel_target_IP_address_flag is set to '0'. If virtual_channel_target_IP_address_flag is set to '1' and the IP_version_flag field is set to '0', this field indicates a 32-bit target IPv4 address for the corresponding virtual channel. When virtual_channel_target_IP_address_flag is set to '1' and the IP_version_flag field is set to '1', this field indicates a 64-bit target IPv6 address for the corresponding virtual channel. If the virtual_channel_target_IP_address cannot be resolved, the component_target_IP_address field in the num_channels loop must be resolved, and the receiving system must use component_target_IP_address to access the IP stream component (This field shall present if the virtual_channel_target_IP_address_flag is set to '1' and shall not present if the virtual_channel_target_IP_address_flag is set to '0'.If present, when IP_version_flag field is set to' 0 ', this field specifies 32-bit target IPv4 address for this virtual channel.When IP_version_flag field is set to' 1 ', this field specifies 128-bit target IPv6 address for this virtual channel.If this virtual_channel_target_IP_address doesn't present, then the component_target_IP_address field in the num_channels loop shall present and the receiver shall utilize the component_target_IP_address to access IP stream components.).

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

An RTP_payload_type field (7 bits) indicates the encoding format of the component according to Table 3 below. This 7-bit field identifies the encoding format of the component, according to Table 3.If the IP stream component is not encapsulated in RTP, this field shall be deprecated.).

Table 3 below shows an example of the RTP payload type.

RTP_payload_type Meaning 35 AVC video 36 MH audio 37-72 [Reserved for future ATSC use]

A component_target_IP_address _flag field (1 bit) indicates that when a flag is set, the corresponding IP stream component is transmitted through an IP datagram having a target IP address different from the virtual_channel_target_IP_address. If this flag is set, the receiving system uses component_target_IP_address as the target IP address to access the corresponding IP stream component and ignores virtual_channel_target_IP_address in the num_channels loop (A 1-bit Boolean flag that indicates, when set, this IP stream component). is delivered through IP datagrams with target IP addresses different from virtual_channel_target_IP_address.When this flag is set, then the receiver shall utilize the component_target_IP_address as the target IP address to access this IP stream component and shall ignore the virtual_channel_target_IP_address field in the num_channels loop.).

When the component_target_IP_address field (32 or 128 bits) is set to '0' in the IP_version_flag field, this field indicates a 32-bit target IPv4 address for the corresponding IP stream component. When the IP_version_flag field is set to '1', this field indicates a 128-bit target IPv6 address for the corresponding IP stream component (When IP_version_flag field is set to '0', this field specifies 32-bit target IPv4 address for this IP stream component.When IP_version_flag field is set to '1', this field specifies 128-bit target IPv6 address for this IP stream component.).

A port_num_count field (6 bits) indicates the number of UDP ports associated with the corresponding IP stream component. The target UDP port number is incremented by 1 starting from the value of the target_UDP_port_num field. For RTP streams, the target UDP port number is increased by 2 starting from the value of the target_UPD_port_num field, because this field indicates the number of UDP ports associated with this IP stream component. values of the target UDP port numbers shall start from the target_UDP_port_num field and shall be incremented by one.For RTP streams, the target UDP port numbers shall start from the target_UPD_port_num field and shall be incremented by two, to incorporate RTCP streams associated with the RTP streams.).

A target_UDP_port_num field (16 bits) indicates a target UDP port number for the corresponding IP stream component. For RTP streams, the value of target_UDP_port_num is an even number, and the next higher value indicates the target UDP port number of the associated RTCP stream (A 16-bit unsigned integer field, that represents the target UDP port number for this IP stream component.For RTP streams , the value of target_UDP_port_num shall be even, and the next higher value shall represent the target UDP port number of the associated RTCP stream.).

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

virtual_channel_level_descriptor () represents a zero or more descriptors providing additional information for this virtual channel, may be included.

ensemble_level_descriptor () is a zero or more descriptors providing additional information for the MH Ensemble which this SMT describes, may be included.

18 is a diagram illustrating syntax of an MH audio descriptor according to an embodiment of the present invention.

MH_audio_descriptor () should be used as component_level_descriptor in SMT when one or more audio services exist as components of the current event. This descriptor can tell you the type of audio language and whether it is in stereo mode. The MH_audio_descriptor shall be used as a component_level_descriptor of the SMT when there is one or more audio services present as a component of the current event.This enables, for example, announcement of audio language and stereo mode.If there is no audio service associated with the current event, then the MH_audio_descriptor shall not be present for that event.).

Each field illustrated in FIG. 18 is described in detail as follows.

A descriptor_tag field (8 bits) indicates that the descriptor is MH_audio_descriptor () (This 8-bit unsigned integer shall have the value TBD, identifying this descriptor as MH_audio_descriptor.).

This 8-bit unsigned integer specifies the length (in bytes) immediately following this field up to the end of this descriptor.

A channel_configuration field (8 bits) indicates the number and configuration of the audio channel. Values 1 through 6 indicate the number and configuration of the audio channel specified in "Default bit stream index number" on Table 42 of ISO / IEC 13818-7: 2006 (This 8-bit field indicates the number and configuration of audio channels.Values in the range from 1 to 6 indicate the number and configuration of audio channels as given for "Default bit stream index number" in Table 42 of ISO / IEC 13818-7: 2006.All other values indicate that the number and configuration of audio channels is undefined.).

This is a 3-bit field which indicates the sample rate of the encoded audio.The indication may be of one specific sample rate, or may be of a set of values that include the sample rate of the encoded audio as defined in Table A3.3 of ATSC A / 52B.).

The lower 5 bits of the bit_rate_code field (6 bits) indicate the nominal bit rate, and if the most significant bit is '0', it means that the corresponding bit rate is correct, and if the most significant bit is '1', the corresponding bit This is a 6-bit field.The lower 5 bits indicate a nominal bit rate.The MSB indicates whether the indicated bit rate is exact (MSB = 0) or an upper limit (MSB = 1) as defined in Table A3.4 of ATSC A / 53B.).

An ISO_639_language_code field (3 bytes: 24 bits) indicates a language used for an audio stream component. If there is no language specific to the audio stream component, this byte value is set to 0x00 (This 3-byte (24 bits) field, in conformance with ISO 639.2 / B [x], specifies the language used for the audio stream component.In case of no language specified for this audio stream component, each byte shall have the value 0x00.).

19 is a diagram illustrating syntax of an MH RTP payload type descriptor according to an embodiment of the present invention.

The MH_RTP_payload_type_descriptor () indicates the type of the RTP payload, and is present only when the RTP_payload_type value in the num_components loop of the SMT has a value of 96 to 127. And this descriptor is used as component_level_descriptor of SMT.

MH_RTP_payload_type_decriptor matches the RTP_payload_type value to the MIME type. As a result, the receiving system can collect the encoding format of the IP stream component encapsulated with RTP (The MH_RTP_payload_type_descriptor shall present if and only if the value of RTP_payload_type in the num_components loop of the SMT is a dynamic value in the range When present, the MH_RTP_payload_type_decriptor shall be used as an component_level_descriptor of the SMT.The MH_RTP_payload_type_decriptor translates a dynamic RTP_payload_type value into a MIME type, so that the receiver can gather the encoding format of the IP stream component, encapsulated in RTP.).

Detailed descriptions of the fields included in the MH_RTP_payload_type_descriptor () are as follows.

A descriptor_tag field (8 bits) indicates that the descriptor is MH_RTP_payload_type_descriptor (). (This 8-bit unsigned integer shall have the value TBD, identifying this descriptor as MH_RTP_payload_type_descriptor.).

This 8-bit unsigned integer specifies the length (in bytes) immediately following this field up to the end of this descriptor.

(This 7-bit field identifies the encoding format of the IP stream component, where the value of this RTP_payload_type is). The RTP_payload_type field (7 bits) indicates the encoding format of the IP stream component. in the dynamic value range 96-127.).

This field specifies the length (in bytes) of the MIME_type.

The MIME_type field indicates the MIME type corresponding to the encoding format of the IP stream component described by this MH_RTP_payload_type_descriptor ().

20 is a diagram illustrating syntax of an MH Current Event Descriptor according to an embodiment of the present invention.

The MH_current_event_descriptor () is used as a virtual_channel_level_descriptor in SMT. This descriptor provides basic information about the current event transmitted on the virtual channel (for example, the current event start time, duration time, and title). The MH_current_event_descriptor provides the basic information on the current event carried through this virtual channel (current event start time, duration and title).).

A detailed description of each field included in the MH_current_event_descriptor is as follows.

A descriptor_tag field (8 bits) is a field indicating that the present descriptor is MH_current_event_descriptor () (This 8-bit unsigned integer shall have the value TBD, identifying this descriptor as MH_current_event_descriptor.).

This 8-bit unsigned integer specifies the length (in bytes) immediately following this field up to the end of this descriptor.

A current_event_start_time field (32 bits) indicates the start time of this event (A 32-bit unsigned integer quantity representing the start time of the current event as the number of GPS seconds since 00:00:00 UTC, January 6, 1980).

A current_event_duration field (24 bits) indicates the duration of this event (A 24-bit field containing the duration of the current event in hours, minutes, seconds.Format: 6 digits, 4-bit BCD = 24 bit.).

This field specifies the length (in bytes) of the title_text.Value 0 means that no title exists for this event.

The title_text field indicates the title of the event (The event title in the format of a multiple string structure as defined in ATSC A / 65C [x].).

21 is a diagram illustrating syntax of an MH Next Event Descriptor according to an embodiment of the present invention.

The MH_next_event_descriptor () is used as a virtual_channel_level_descriptor of SMT. The MH_next_event_descriptor () provides basic information (eg, future event start time, duration, title) on a future event transmitted through the corresponding virtual channel (The optional MH_next_event_descriptor, may present as a virtual_channel_level_descriptor of the SMT.The MHnext event descriptor provides the basic information on the next event carried through this virtual channel (next event start time, duration and title).).

A detailed description of each field included in the MH_next_event_descriptor is as follows.

A descriptor_tag field (8 bits) indicates that this descriptor is MH_next_event_descriptor () (This 8-bit unsigned integer shall have the value TBD, identifying this descriptor as MH_next_event_descriptor.).

This 8-bit unsigned integer specifies the length (in bytes) immediately following this field up to the end of this descriptor.

A 32-bit unsigned integer quantity representing the start time of the next event as the number of GPS seconds since 00:00:00 UTC, January 6, 1980. The next_event_start_time field (32 bits) indicates the start time of the future event.

The next_event_duration field (24 bits) indicates the duration of a future event (A 24-bit field containing the duration of the next event in hours, minutes, seconds.Format: 6 digits, 4-bit BCD = 24 bit.).

This field specifies the length (in bytes) of the title_text.Value 0 means that no title exists for this event.

The title_text field indicates the title of the event (The event title in the format of a multiple string structure as defined in ATSC A / 65C [x].).

22 is a diagram illustrating syntax of an MH system time descriptor according to an embodiment of the present invention.

The MH_system_time_descriptor () is used as ensemble_level_descriptor of SMT. The MH_system_time_descriptor () provides current time and date information. In addition, MH_system_time_descriptor provides time zone information on a transmission system that transmits a received broadcast stream in consideration of a mobile environment. (The MH_system_time_descriptor, when present, shall be used as an ensemble_level_descriptor of the SMT. In addition, taking the mobile / portable characteristic of MH, the MH system time descriptor provides the time zone information for where the transmitter of this broadcast stream is located.).

A detailed description of each field included in the MH_system_time_descriptor () is as follows.

A descriptor_tag field (8 bits) indicates that this descriptor is MH_system_time_descriptor () (This 8-bit unsigned integer shall have the value TBD, identifying this descriptor as MH_system_time_descriptor.).

This 8-bit unsigned integer specifies the length (in bytes) immediately following this field up to the end of this descriptor.

A 32-bit unsigned integer quantity representing the current system time as the number of GPS seconds since 00:00:00 UTC, January 6th, 1980.

A GPS_UTC_offset field (8 bits) indicates the current offset between GPS and UTC. (An 8-bit unsigned integer that defines the current offset in whole seconds between GPS and UTC time standards.To convert GPS time to UTC, the GPS_UTC_offset is subtracted from GPS time.Whenever the International Bureau of Weights and Measures decides that the current offset is too far in error, an additional leap second may be added (or subtracted), and the GPS_UTC_offset will reflect the change.).

A time_zone_offset_polarity field (1 bit) indicates whether the time for the time zone of the broadcasting station position is ahead or behind UTC. If this field is '0', since the time on the current time zone is earlier than UTC, the time_zone_offset value is added to UTC. On the other hand, if this field is '1', it means that the time on the current time zone is behind UTC, and thus time_zone_offset is summed from UTC (An one-bit indicator that indicates whether the time of the time zone where the broadcast station is located leads or lags UTC.When set to '0', this field indicates that the time of current time zone is leads the UTC (ie, the time_zone_offset is added to UTC) and when set to '1', this field indicates that the time of current time zone lags UTC.).

A 31-bit unsigned integer quantity representing the time offset of the time zone in GPS seconds, where the broadcast station is located, compared to UTC .).

Daylight Savings Time control bytes.Refer to Annex A of ATSC-A / 65C with amd. # 1 [x], for the use of these two bytes. .

A time_zone field (5x8 bits) indicates a time zone for a transmission system transmitting a received broadcast stream.

FIG. 23 is a diagram illustrating segmentation and encapsulation of an SMT according to the present invention. FIG.

According to the present invention, the SMT is encapsulated in UDP with a target IP address and a target UDP port number on the IP datagram. That is, the SMT is segmented into a predetermined number of sections, then encapsulated in a UDP header, and then encapsulated in an IP header.

In addition, the SMT section provides signaling information for all virtual channels included in the MH ensemble including the corresponding SMT section. At least one SMT section describing the MH ensemble is included in each RS frame belonging to the corresponding MH ensemble. Each SMT section is distinguished by ensemble_id included in each section. According to an embodiment of the present invention, the target IP address and the target UDP port number are known to the receiving system so that the receiving system can parse them without requiring additional information.

24 is a flowchart illustrating access to a virtual channel using FIC and SMT according to an embodiment of the present invention.

That is, if one physical channel is tuned (S501) and an MH signal exists in the tuned physical channel (S502), the MH signal is demodulated (S503). The FIC segments are collected in subframe units from the demodulated MH signal (S504 and S505).

In the present invention, one FIC segment is inserted into one data group and transmitted. That is, the FIC segment corresponding to each data group describes service information of the MH ensemble to which the data group belongs. When the FIC segments are collected and deinterleaved in units of subframes, all service information of a physical channel through which the corresponding FIC segment is transmitted can be obtained. Accordingly, the receiving system can acquire channel information of the corresponding physical channel during the sub frame period after tuning the physical channel. When the FIC segments are collected by S504 and S505, the broadcast stream in which the corresponding FIC segment is transmitted is identified (S506). For example, the broadcast stream can be identified by parsing the transport_stream_id field of the FIC body formed by collecting the FIC segments.

In addition, an ensemble identifier, major channel number, minor channel number, channel type information, etc. are extracted from the FIC body (S507). The ensemble is configured by acquiring only slots corresponding to the ensemble desired to be received by the time slicing method using the extracted ensemble information (S508).

Subsequently, the RS frame corresponding to the desired ensemble is decoded (S509), and an IP socket is opened for receiving an SMT (S510).

According to an embodiment of the present invention, the SMT is encapsulated in UDP while having a target IP address and a target UDP port number on an IP datagram. That is, the SMT is segmented into a predetermined number of sections, then encapsulated in a UDP header, and then encapsulated in an IP header. In the embodiment according to the present invention, the target IP address and the target UDP port number are known to the receiving system so that the receiving system parses the SMT section and descriptors of each SMT section without requiring additional information (S511).

The SMT section provides signaling information for all virtual channels included in the MH ensemble including the corresponding SMT section. At least one SMT section describing the MH ensemble is included in each RS frame belonging to the corresponding MH ensemble. Each SMT section is distinguished by ensemble_id included in each section.

In addition, each SMT provides IP access information of each virtual channel belonging to a corresponding MH ensemble including each SMT. In addition, the SMT provides IP stream component level information required for service of a corresponding virtual channel.

Therefore, the IP stream component belonging to the virtual channel desired to be received is accessed using the information parsed from the SMT (S513), and a service for the corresponding virtual channel is provided to the user (S514).

Hereinafter, another embodiment of the present invention will be described for transmitting and receiving service data having a format different from that of the existing MH format data in the MH system. In this case, the service of the other format includes a MediaFLO service that performs a mobile broadcast service of a subscription base through a single physical channel. The flow will be described as an example. However, the present invention is not limited thereto.

In this regard, in order to transmit and receive data for a media flow service in an MH system, data for a media flow service must be changed to a format for transmission and reception in an MH system. To this end, an interface should be established between the layers on the existing MH system and the layers for the media flow service.

Hereinafter, a protocol stack for transmitting and receiving data for a media flow service in an MH system will be described.

25 illustrates a protocol stack of an MH system according to an embodiment of the present invention.

Hereinafter, referring to FIG. 25, an interface is defined between an MH transport layer and a media adaptation layer of a media flow to transmit and receive the media flow service data in an MH system. It defines signaling data related to.

According to an embodiment of the protocol stack in the MH system illustrated in FIG. 25, the data for the mediaflow service may include a sync layer, a file delivery layer, and an IP adaptation in association with the mediaflow service. The interface is interfaced through an IP Adaptation Layer and transmitted through an MH transport layer and an MH physical layer. Here, the protocol stack also deals with signaling, that is, MH signaling layer in relation to an interface in the MH system of media flow service data.

The protocol stack shown in FIG. 25 includes a Media Codecs Layer, a Non Real Time Files Layer, and an IPv4 / IPv6 Layer that transmits data for a MediaFlow Service. And a sync layer, a file delivery layer, and an IP adaptation layer for interfacing data for the media flow service downloaded from the layers with the MH system. ).

In the above, the media codex layer is a layer for service for real time applications, the non-real time files layer is a layer for service for file-based applications, and the IPv4 / IPv6 layer is IP datacast applications. Layers for services to. In this case, a detailed description of each layer related to the media flow service is referred to, for example, TIA-1130 (Media Adaptation Layer), and will be omitted herein for convenience of description. However, in relation to the media flow service, a non real time files layer and a file delivery layer, an IPv4 / IPv6 layer and an IP adaptation layer (IP). Adaptation Layer) may be defined and transmitted in the existing MH format.

In the protocol stack, the FIC layer and the MH-signaling layer are layers for signaling in the MH system. In addition, the MH transport layer and the MH physical layer are layers for packetizing and transmitting data for the media flow service interfaced.

The detailed description of the interface stack and signaling related to the protocol stack of the MH system will be described later in the relevant part.

26 is a conceptual block diagram of an MH receiver according to another embodiment of the present invention.

Referring to FIG. 26, an MH receiver according to another embodiment of the present invention includes a flow packet handler 2621, an RS frame handler 2620, and a physical parameter handler 2621. , FIC Handler 2622, Non-IP MH-Signaling Decoder 2625, IP-Based MH-Signaling Decoder 2626 ), Sync Layer Handler 2632, File Delivery Layer Handler 2633, IP Adaptation Layer Handler 2634, MH-Signaling Database DB (2627), Channel Manager (2629) and Service Manager (Service Manager) 2630.

Hereinafter, a process and a configuration of receiving and processing data for a media flow service transmitted according to the protocol stack shown in FIG. 25 in the MH system will be described. The configuration of the MH receiver according to an embodiment of the present invention shown in FIG. The descriptions of the parts common to the above use the foregoing. Here, in FIG. 26, the dotted line represents the flow of control data, and the solid line represents the flow of actual data. In the above description, the control data refers to an expression collectively representing various additional information used for processing data for a media flow service. In addition, each layer described below refers to a layer on the protocol stack of FIG. 25 described above.

The RS-frame handler 2620 processes an RS-Frame, which is an output of the MH Physical Layer. Here, signaling information related to the media flow service in the processed RS-frame is transmitted to the non-IP MH signaling buffer 2623, and flow packets related to the media flow service are transmitted to the flow packet handler 2619.

The flow packet handler 2621 receives the flow packet from the RS-frame handler 2620, extracts information about the type in the header of the received flow packet, and describes a sink layer handler 2632 described later according to the extracted type information. From among the file delivery layer handler 2633 and the IP adaptation layer handler 2634, a handler related to the flow packet is selected. And the flow packet handler 2619 transmits the received flow packet for processing in the selected handler.

The physical parameter handler 2621 is responsible for processing physical layer parameters required in the management layer or more.

FIC handler 2622 processes FIC data. In this case, in order to process the FIC data, parameters of a physical layer are needed, and the parameters of the physical layer are decoded by a signaling decoder 2616 in the physical parameter handler 2621. And from the transmitted TPC data.

Non-IP MH-signaling decoder 2625 includes MH-Signaling information transmitted via FIC handler 2622 and non-IP MH-Signaling transmitted in RS-frame. Receive and process information.

The IP-based MH-signaling decoder 2626 processes MH-signaling information transmitted through the FIC handler 2622 and IP-based MH-Signaling information transmitted in the RS-frame. do.

The sync layer handler 2632 receives and processes a flow packet including data transmitted from a sync layer among the flow packets constituting the RS-frame from the flow packet handler 2619.

The file delivery layer handler 2633 receives and processes a flow packet including data transferred from a file delivery layer of the flow packets constituting the RS-frame from the flow packet handler 2621.

The IP adaptation layer handler 2634 receives and processes a flow packet including data transmitted from an IP adaptation layer among the flow packets constituting the RS-frame from the flow packet handler 2619.

The MH-signaling database 2627 serves as a database that stores signaling data received in non-IP or IP form and uses it when necessary.

The channel manager 2629 manages user input such as channel setting through an MH user interface.

The service manager 2630 manages user input such as service setting through an EPG display and an MPG through the MH user interface.

The control data may be included in, for example, a service map table or an electronic service guide (ESG) to be described later, but the present invention is not limited thereto and may be transmitted by other methods. In addition, the MH receiver according to another embodiment of the present invention may obtain information required for the control data configuration from other data transmitted. In this regard, the control data may be stored in, for example, the MH-signaling database 2627, stored in a separate storage space, or received and used in real time depending on characteristics of the control data. For example, when the MH receiver uses the media flow service according to a user's request, the MH receiver stores the control data related to the service in the above-described MH-signaling database 2627, a separate secure storage space, or extracts the data in real time. The packet may be extracted and transmitted to the flow packet handler 2619 or the RS-frame handler 2620. Accordingly, the flow packet handler 2619 or the RS-frame handler 2620 may process the media flow service data using the extracted control data.

Next, an RS frame structure and data packet multiplexing according to another embodiment of the present invention will be described. FIG. 27 illustrates a structure of an RS frame including a multiplexed data packet according to another embodiment of the present invention.

FIG. 27 is a format of an RS frame that transmits data corresponding to an MH ensemble for every MH frame, for example, as an output of the MH Physical Layer Subsystem. can see.

One RS frame may transmit a plurality of MH services. Data constituting one MH service may be transmitted by forming one area continuously in an RS frame. In addition, one MH service may be composed of a plurality of flow packets.

Here, the RS frame is configured in the form of a two dimensional byte array of 187 x N bytes. Accordingly, in the MH transport layer, each row of the RS frame constitutes an MH transport packet (MH TP).

28 illustrates a structure of an MH transport packet (MH TP) according to an embodiment of the present invention.

Referring to FIG. 28, one MH transport packet (MH TP) includes an MH TP header (2 bytes) and an MH transport packet payload (MH TP MH TP Payload) (N-2 bytes). It consists of

The MH TP Header includes, for example, a Type Indicator field, an Error Indicator field, a Stuff Indicator field, and a Pointer field. Hereinafter, the fields will be described.

First, the Type Indicator field (3 bits) indicates the type of data carried in the payload portion of the MH transport packet. In this case, the field value and its meaning may be defined, for example, as shown in Table 4 below.

Type Indicator Meaning 000 MH Signaling Data 001 IP Datagram 010 Sync Layer Data 011 File Delivery Layer Data 100 IP Adaptation Layer Data 101-111 Reserved

Referring to Table 4, if the value of the Type Indicator field is '000', it means that the data type carried in the payload of the MH transport packet is MH signaling data, and the value of the Type Indicator field is '001'. If, the data type carried in the payload of the MH transport packet is an IP datagram. If the value of the Type Indicator field is '010', the data type carried in the payload of the MH transport packet is sink. When the value of the Type Indicator field is '011', it means that the data type carried in the payload of the MH transport packet is file delivery layer data, and the value of the Type Indicator field is '100'. In this case, the data type carried in the payload of the corresponding MH transport packet is IP adaptation layer data. Here, when the value of the Type Indicator field is '101-111', it is reserved for future use.

In addition, the type of the service transmitted and received in the MH system may be distinguished from the value of the Type Indicator field. For example, when the value of the Type Indicator field is '010' to '100', the receiver may know that data for a media flow service is transmitted from the field value through a corresponding MH transport packet. In this regard, the field value is '000', i.e., MH signaling data, or '001', i.e., in case of an IP datagram, the field value is included in the MH transport packet in a conventional MH format format. To use.

An Error Indicator field (1 bit) is an indicator indicating the presence or absence of an error in the corresponding MH transport packet. In this case, when the value of the Error Indicator field is '0', for example, an error may not be found, and '1' may be defined as indicating that an error has been found and may indicate whether an error exists.

A Stuff Indicator field (1 bit) is an indicator indicating whether stuffing bytes are present in a corresponding MH transport packet. In this case, if the Stuff Indicator field value is '0', for example, there is no stuffing byte, and if it is '1', the stuff indicator field is defined as indicating that the start of the packet payload is a stuffing field. It can be instructed to identify whether or not. Here, the stuffing byte indicates K bytes of stuffing present in one MH transport packet if necessary, and the stuffing field including the K bytes may be the start of a packet payload. If the length of the stuffing field is 1 byte, the value of the first byte of the stuffing field will be set to '0xFF'. If the length of the stuffing field is 2 bytes, the value of the first byte of the stuffing field may be set to '0xFE', and the value of the second byte may be '0xFF'. In addition, if the length of the stuffing field is 2 bytes or more, the value of the first two bytes of the field may indicate the number of bytes in the stuffing byte field.

A Pointer field (11 bits) indicates the starting point of a new packet in the payload of the corresponding MH transport packet. Here, the starting point of the new packet may indicate, for example, the starting point of the flow packet header.

However, the values of each field in the aforementioned MH transport packet header are illustrated for convenience of description and the present invention is not limited thereto.

Next, the one MH transport packet (MH TP) includes a stuffing part (K byte) and a payload part (N-2-K byte) in addition to the MH transport packet header part described above. In this case, the stuffing part and the payload part may be referred to as a payload.

Referring to an RS frame structure in which a plurality of data packets for a media flow service shown in FIG. 27 are multiplexed, data packets classified A to K are multiplexed in the RS frame.

In the RS frame structure, a column named an RS frame header on the left side describes a type of a data packet included in an RS frame payload portion of a corresponding row. For example, in the case of the RS frame illustrated in FIG. 27, the RS frame header portion of the first row is indicated by A, which includes a signaling data packet A ′ in the payload portion of the first row. It means. In the same manner as described above, when B to D are indicated in the RS frame header of a specific row of an RS frame, the RS frame payload of the corresponding row may include a data packet represented by B to D.

In addition, FIG. 27 shows an example of multiplexing data (Data for Service 1-4) for four services. That is, service 1 describes a sync layer packet, service 2 a file delivery layer packet, service 3 an IP adaptation layer packet, and service 4 describe services including each layer packet. In addition, each service packet can be distinguished from being transmitted through a different flow packet.

Next, a description will be given of packetizing and transmitting data related to a sink layer in relation to a media flow service. 29 is a diagram illustrating a packetization process in a sink layer according to one embodiment of the present invention.

As described above, the sync layer serves as an interface between the media codec layer and the MH transport layer for data transmission for real-time applications in the MH system. . In this case, the real time application includes, for example, video, audio, and timed text.

FIG. 29 illustrates a process of packetizing a media frame downloaded from a media codec layer in a sync layer.

The sync layer downloads media frames of variable length from the media codec layer. The sync header packet is configured by attaching a sync header to each downloaded media frame. In this case, if necessary, a packet formed by attaching a header to a Sync Layer Adaptation Frame (SLAF) may be inserted between the sync layer packets.

Here, the sync header includes information indicating a media type (MT: Media Type), information on a general media header (MCH: Media Common Header), media specific header information (MSH: Media Specific Header), and a sync layer. Adaptation type information (SLAT: Sync Layer Adaptation Type) may be included. For example, in FIG. 29, in the case of a header attached in the process of packetizing a media frame, information (MT) indicating a media type, information on a general media header (MCH), and media specific header information (MSH) are included. do. In the header for packetization of the sync layer adaptation frame SLAF, the information MT indicating the media type and the sync layer adaptation type information SLAT are included.

30 illustrates a process of packetizing sync layer packets in an MH transport layer according to an embodiment of the present invention.

30 illustrates a process of packetizing data for real-time applications through a media codec layer at a sync layer and packetizing a packet in a transport format suitable for an MH system at an MH transport layer according to the present invention. In this case, the above-described information is used in FIG. 29 until the process of interfacing. Hereinafter, a process of packetizing a packet for transmission in the MH transport layer after the interface will be described.

Referring to FIG. 30, the MH transport layer attaches an MH transport packet header (2 bytes) to at least one flow packet (N-2 bytes) to packetize one MH transport packet (N bytes). Here, the flow packet is further divided into a flow packet header and a flow packet payload. The flow packet header (5 bytes) will be described later with reference to FIG. 31, and the flow packet payload (N-2-5 bytes) has a variable length. Thus, the sync layer packet packetized in the sink layer of FIG. 29 is divided. One flow packet payload may be configured, or as shown, several sink layer packets corresponding to the corresponding length may be configured as one flow packet payload. In addition, the flow packet payload may include a length field (16 bits) regarding the length of each sync layer packet included in the corresponding flow packet payload.

The header of the first MH transport packet among the MH transport packets configured as described above may have, for example, a Type Indicator field. In addition, when the flow packet divided above is N-2 bytes or less, stuffing bytes may be added. Here, the pointer field of the MH transport packet header may indicate the starting point of the flow packet header.

In addition, the flow packet is divided into a flow packet header and a flow packet payload, as will be described later, and the flow packet payload is packetized in the sink layer, that is, a sync layer data packet composed of a sync packet header and a media frame. Contains length information about the length.

Referring to FIG. 30, one MH transport packet (MH TP) may include at least one flow packet, and one flow packet may include a plurality of sink layer data packets.

In this case, the length value cannot be processed even if the receiving side does not know the length of each sink layer data packet. Therefore, the length value includes information about the length of each sync layer data packet packetized for the processing. It is to give.

FIG. 31 illustrates a format of a flow packet according to an embodiment of the present invention. As described above, a flow packet is divided into a flow packet header and a flow packet payload.

The flow packet header will be described below. The flow packet header includes a Flow_ID (enter) field (20 bits) for identifying a flow packet to which the flow packet belongs, a CHECKSUM_ACTIVE field (1 bit) indicating whether a cyclic redundancy check (CRC) has been applied to the flow packet, NUM_SYNC_PKTS field (1 bit) indicating the number of sink layer packets transmitted through the flow packet payload, FD_FLOW_TYPE field (1 bit) indicating the type of the flow packet, and the flow packet is transmitted over one or more RS frames FASB_ALLOWED field (1 bit) indicating whether or not, and STREAM_ENCRYPTION_ACTIVE field (16 bits) indicating whether encryption is applied to the flow packet payload. In this case, in relation to the FASB_ALLOWED field, when the flow packet is a real time application flow packet, the field value may be set to 'FALSE'.

In the above, in connection with the present invention, it is apparent that values of each field are arbitrarily determined by the applicant, and may be represented by using a value different from the above.

The above-described flow packet is packetized from the MH transport layer into an MH transport packet (MH TP) and transmitted through an MH physical layer.

Accordingly, the RS frame handler 2620 of the receiver illustrated in FIG. 26 searches for an MH transport packet header configured as described above, parses an MH transport packet having a Type Indicator of '001' in the header, and stores the corresponding packet. And the flow packet handler 2619 extracts the corresponding sink layer packets and delivers the same to the sink layer handler 2632.

Following packetization of the above-mentioned Sync Layer Packets, a packetization process of File Delivery Layer Packets will be described next. FIG. 32A illustrates a configuration in which a File Delivery Protocol (FDP) and a File Delivery Control Protocol (FDCP) data packet are packetized in an MH transport layer according to an embodiment of the present invention.

The file delivery layer includes a non-real time files layer and an MH transport layer for data transmission for a non-real time application. ) Serves as an interface between

Herein, the file delivery layer may transmit an FDP packet and an FDCP packet for file delivery control to different flow packets to the MH transport layer. In this case, each of the FDP and FDCP packets is packetized into an MH transport packet (MH TP), and each configuration is the same as that of FIG. 32A (FDP packet and FDCP packet).

Herein, the processes and methods of packetizing the FDP and FDCP packets in the MH transport layer are similar to those described above with respect to the sync layer packet in FIGS. The description of the part uses the above-mentioned content, and detailed description is abbreviate | omitted here. Accordingly, referring to FIG. 32B, field values of a flow packet header will be applied similarly to the aforementioned sync layer. In addition, a flow packet payload having a variable length includes a length and an FDP packet or a length and an FDCP packet.

Finally, a packetization process of the IP adaptation layer packet (IP adaptation layer packet) is described next to the above-described packet regarding the sync layer and the file delivery layer. 33 illustrates packetization of an IP datagram packet in an MH transport layer according to an embodiment of the present invention.

The IP adaptation layer is an interface between an IPv4 / IPv6 layer and an MH transport layer for data transmission for an IP datacast application. Interface) role.

The IP adaptation layer may deliver IP datagrams in different flow packets to the MH transport layer. Here, the IP datagram is packetized into an MH transport packet (MH TP). 33 shows the configuration of the packetized IP datagram.

In the method of packetizing the IP datagram in the MH transport layer, the same content as described above with respect to the sync layer packet is used, and detailed description thereof is omitted. Each value constituting the header of FIG. 34 will also be defined as an appropriate value according to the corresponding IP datagram. The flow packet payload also includes an IP datagram and length information about the IP datagram.

Next, a service map table (SMT-MH) according to another embodiment of the present invention will be described with respect to the signaling information about the data for the media flow service described above. 35 is a diagram illustrating a bitstream syntax of a service map table according to another embodiment of the present invention.

Of the MH transport packets (MH TP) transmitted through the RS frame configured as shown in FIG. 27, the MH transport packet (MH TP) set to "Type Indicator = '000'" is usually located at the beginning of the RS frame. In the MH transport packet located at the beginning of the RS frame, a service map table including signaling data describing the data structure of the corresponding RS frame is transmitted.

The service map table transmits information on flow packets belonging to MH services transmitted through the corresponding RS frame to the receiver. In this case, the service map table may be processed in, for example, a “Non-IP MH Signaling Decoder 2625” of the MH receiver structure of FIG. 26 described above.

In addition, the service map table transmits information about the start and end of the MH transport packet belonging to the MH services transmitted through the corresponding RS frame, so that even if there is no ID value corresponding to the corresponding MH services, the RS frame handler (RS) Frame Handler) 2620 may extract desired MH service data.

Another embodiment of the service map table of FIG. 35 is written according to the MPEG-2 short form, but may not follow the short form. However, the description of the overlapping parts of the above-described contents in the service map table of FIG. 17, which is an embodiment of the present invention, is used here, and the description will be given based on the parts related to the present embodiment.

Referring to FIG. 35, a first_MH_TP_num field indicates a first starting MH transport packet among a plurality of MH transport packets including a flow packet, and a last_MH_TP_num field indicates a last MH transport packet.

Hereinafter, a process of extracting and processing data transmitted to an MH TP layer in order to provide a broadcast or service in an MH receiver will be described. 36 to 38 illustrate one embodiment of a data processing process according to the present invention.

When the power of the MH receiver is turned on, the broadcast or the RS frame in the service received for the service is decoded (S3601).

In operation S3602, a service map table SMT-MH including signaling information of data for a media flow service is extracted from the decoded RS frame.

Here, in the configuration of the MH receiver illustrated in FIG. 26, for example, steps 3601 to 3602 may be performed by the RS frame handler 2620.

When the service map table including the signaling information is extracted in step S3602, first_MH_TP_num and last_MH_TP_num fields are parsed from the extracted service map table section (S3503).

Here, for example, among the configuration of the MH receiver illustrated in FIG. 26, the non-IP MH signaling decoder 2625 may perform step S3603.

In operation S3602 and S3603, MH transport packets are extracted from an RS frame based on the extracted service map table and information about the parsed first_MH_TP_num and last_MH_TP_num fields (S3604).

The header of the extracted MH transport packet is parsed (S3605).

Here, in the configuration of the MH receiver illustrated in FIG. 26, for example, the steps S3604 to S3605 may be performed by the RS frame handler 2620.

In step S3605, a type indicator in a header of the parsed MH transport packet is extracted. The flow packet header is extracted and parsed based on the extracted type indicator (S3606). For example, if the value of the extracted Type Indicator is '010', it indicates a flow packet including a sync layer packet. If the value of the extracted Type Indicator is '011', a flow including FDP and FDCP packets is included. Indicate a packet, and if the value of the extracted Type Indicator is '100', it indicates a flow packet including IP datagram packets.

In the case of FIG. 36, a value of the Type Indicator is '010', that is, a flow packet including a sync layer packet.

From the flow packet header parsed in step S3606, length information of each sink layer packet included in the corresponding flow packet payload is extracted, and each sink layer packet is extracted according to the extracted length information (S3607).

Here, in the configuration of the MH receiver of FIG. 26, for example, steps 3606 to 3607 may be performed by the flow packet handler 2619.

A sync layer action is performed using the sync layer packets extracted in step S3607 (S3608).

Here, for example, in the configuration of the MH receiver of FIG. 26, the sink layer handler 2632 may perform step 3608.

By going through the above process, it is possible to process and provide the sink layer packet for the media flow service included in the MH transport packet according to the protocol stack of the MH system.

Next, FIG. 36 illustrates a case where the value of the extracted Type Indicator indicates '011', that is, a flow packet including FDP and FDCP packets. Before step 3706 in FIG. 37 is the same, the above description of FIG. 36 is used. The following description is made from step 3706.

Accordingly, when the flow packet includes FDP and FDCP packets other than sink layer packets according to the extracted Type Indicator value, the header of the flow packet including the FDP and FDCP packets is extracted and parsed (S3706). .

From the flow packet header parsed in step S3706, length information about each FDP and FDCP packets included in the flow packet payload is extracted, and each FDP and FDCP packets are extracted according to the extracted length information (S3707). .

Here, in the configuration of the MH receiver illustrated in FIG. 26, for example, steps 3706 to 3707 may be performed by the flow packet handler 2619.

A file delivery layer action is performed using the FDP and FDCP packets extracted in step S3707 (S3708).

Here, in the MH receiver configuration shown in FIG. 26, for example, the file delivery layer handler 2633 may perform step 3708.

By going through the above-described process, the FDP and FDCP layer packets for the media flow service included in the MH transport packet can be processed and provided to the user according to the protocol stack of the MH system.

Finally, FIG. 38 illustrates a case where the value of the extracted Type Indicator indicates '100', that is, a flow packet including IP datagrams. Before step 3806 in FIG. 38 is the same, the above description of FIG. 36 is used. The following description is made from step 3806.

If the flow packet indicated by the value of the extracted Type Indicator includes IP datagrams that are not sync layer packets or FDP and FDCP packets, the header of the flow packet including the IP datagrams is extracted and parsed (S3806).

From the flow packet header parsed in step S3806, length information regarding each IP datagram included in the corresponding flow packet payload is extracted, and each IP datagram is extracted using the extracted length information (S3807).

An IP adaptation layer action is performed using the IP datagrams extracted in step 3807 (S3808).

By going through the above process, the IP datagram for the mediaflow service included in the MH transport packet can be processed and provided to the user according to the protocol stack of the MH system.

In FIG. 38, the MH receiver configuration block that performs each step is the same as the configuration block described with reference to FIG.

According to the present invention, it is possible to define a protocol stack capable of transmitting and receiving service data in a format other than the existing MH format.

As a result, according to the present invention, various broadcasting services are possible through the MH system, thereby providing a wide range of choices by providing various services to the user.

As described above, although the present invention has been described with reference to the limited embodiments and the drawings, the present invention is not limited to the above embodiments, and those skilled in the art to which the present invention pertains various modifications and variations from such descriptions. This is possible.

Therefore, the scope of the present invention should not be limited to the described embodiments, but should be determined not only by the claims below but also by the equivalents of the claims.

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

2 illustrates an embodiment of a structure of a data group according to the present invention.

3 illustrates an RS frame according to an embodiment of the present invention.

4 illustrates an example of an MH frame structure for transmission of mobile service data according to the present invention.

5 illustrates an example of a VSB frame structure.

FIG. 6 shows an example of mapping of the first four slot positions of a subframe in a spatial domain with respect to one VSB frame. FIG.

FIG. 7 illustrates an example of mapping of the first four slot positions of a subframe in a time domain with respect to one VSB frame. FIG.

8 is an example of a data group allocation order allocated to one subframe among five subframes constituting an MH frame.

9 illustrates an example of assigning a single parade to one MH frame.

FIG. 10 illustrates an example of transmitting three parades (Parade # 0, Parade # 1, and Parade # 2) in one MH frame.

FIG. 11 illustrates an example in which the allocation process of the three parades of FIG. 10 is extended to five subframes in one MH frame.

FIG. 12 is a diagram illustrating a data transmission structure according to an embodiment of the present invention, and shows a state in which signaling data is included and transmitted in a data group.

13 illustrates a layered signaling structure according to an embodiment of the present invention.

14 illustrates an embodiment of an FIC format according to the present invention.

15 illustrates an embodiment of a data structure of an FIC segment according to the present invention.

FIG. 16 illustrates an embodiment of a bit stream syntax structure for a payload of an FIC segment when the FIC type field value is '0' according to the present invention; FIG.

17 illustrates an example of bit stream syntax of a service map table according to an embodiment of the present invention.

18 is a diagram illustrating syntax of an MH audio descriptor according to an embodiment of the present invention.

19 is a diagram illustrating syntax of an MH RTP payload type descriptor according to an embodiment of the present invention.

20 is a diagram illustrating syntax of an MH current event descriptor according to an embodiment of the present invention.

21 is a diagram illustrating syntax of an MH Next Event Descriptor according to an embodiment of the present invention.

22 is a diagram illustrating syntax of an MH system time descriptor according to an embodiment of the present invention.

23 is a diagram for explaining segmentation and encapsulation of an SMT according to the present invention;

24 is a flowchart illustrating access to a virtual channel using FIC and SMT according to an embodiment of the present invention.

25 illustrates a protocol stack of an MH system according to an embodiment of the present invention.

26 is a conceptual block diagram of an MH receiver according to another embodiment of the present invention.

27 illustrates a structure of an RS frame including a multiplexed data packet according to another embodiment of the present invention.

28 illustrates a structure of an MH transport packet (MH TP) according to an embodiment of the present invention.

29 illustrates a process of packetizing in a sink layer according to an embodiment of the present invention.

30 illustrates a process of packetizing sync layer packets in an MH transport layer according to an embodiment of the present invention.

31 illustrates a format of a flow packet according to an embodiment of the present invention.

FIG. 32A illustrates a configuration in which a File Delivery Protocol (FDP) and a File Delivery Control Protocol (FDCP) data packet are packetized in an MH transport layer according to an embodiment of the present invention.

33 illustrates packetization of an IP datagram packet in an MH transport layer according to an embodiment of the present invention.

35 illustrates bitstream syntax of a service map table according to another embodiment of the present invention.

36 to 38 illustrate an embodiment of a data processing process according to the present invention.

<Explanation of symbols for the main parts of the drawings>

100: MH Baseband Processor

200: MH Management Processor

300: MH Presentation Processor

Claims (15)

Receives a broadcast signal including mobile service data and main service data, wherein the mobile service data includes first service data and second service data in a format different from the first service data, wherein the second service data is RS A frame, wherein the RS frame includes second service data and a table in which signaling information of the second service data is described; Parsing the table from the RS frame to extract signaling information of the second service data; And And parsing the second service data from the RS frame based on the extracted signaling information. The method of claim 1, At least one data group constituting the RS frame includes a plurality of known data sequences, and includes a signaling information region between a first known data sequence and a second known data sequence among the known data sequences. The signaling information area includes transmission parameter channel (TPC) signaling and fast information channel (FIC) signaling. The method of claim 1, The RS frame consists of an RS frame header and an RS frame payload. The RS frame payload includes a transport packet configured by packetizing at least one data for the second service. The method of claim 3, wherein The RS frame header may include first information identifying a type of data in a transport packet transmitted through the payload, second information indicating whether an error exists in a transport packet transmitted through the payload, and a corresponding RS. And at least one of third information indicating whether a stuffing byte is included in a frame and fourth information indicating a start point of new data in a transport packet transmitted through the payload. Treatment method. The method of claim 4, wherein The first information is, And classifying a type of data in the transport packet, wherein the type is divided into data for the first service and data for a second service. The method of claim 3, The transport packet transmitted through the RS payload includes a flow packet including data for the second service. The method of claim 6, The flow packet, Consisting of a flow packet header and a flow packet payload, The flow packet payload includes a layer packet packetized in at least one layer for the second service and length information regarding a length of the layer packet. The method of claim 7, wherein The flow packet header, Identification information for identifying a layer packet included in the flow packet, information indicating whether the flow packet is transmitted over one or more RS frames, information indicating whether a CRC has been applied to the flow packet, and the flow And at least one of information indicating the number of layer packets included in the packet. Receives a broadcast signal including mobile service data and main service data, wherein the mobile service data includes first service data and second service data in a format different from the first service data, wherein the second service data is RS A baseband processor comprising a table describing second service data and signaling information of the second service data; A table handler which parses the table from the RS frame and extracts signaling information of the second service data; And And a service handler for parsing the second service data from the RS frame based on the extracted signaling information of the second service data. The method of claim 9, At least one data group constituting the RS frame includes a plurality of known data sequences, and includes a signaling information region between a first known data sequence and a second known data sequence among the known data sequences. The signaling information area includes transmission parameter channel (TPC) signaling and fast information channel (FIC) signaling. The method of claim 9, wherein the baseband processor unit, And a known data detector for detecting a known data sequence included in the data group, wherein the detected known data sequence is used for demodulation and channel equalization of mobile service data. The method of claim 9, The table handler is Extracting a table including signaling information of the second service data from the RS frame including an RS frame header and an RS frame payload, The RS frame payload includes a transport packet configured by packetizing at least one data for the second service. The method of claim 12, The table handler is First information identifying a type of data in a transport packet transmitted through the payload, second information indicating whether an error exists in a transport packet transmitted through the payload, and stuffing bytes in a corresponding RS frame Extract and use the RS frame header information including at least one of third information indicating whether or not, and fourth information indicating a start point of new data in a transport packet transmitted through the payload; And selecting the service handler by identifying from the extracted first information whether the type of data in the transport packet includes first service data or second service data. The method of claim 13, The selected service handler, Process transport packets transmitted through the RS frame payload, The transport packet includes a flow packet including data for the second service, and the flow packet includes a layer packet packetized in a flow packet header and at least one layer for the second service, and the layer packet. And said flow packet payload comprising length information about a length. The method of claim 14, The service handler, Identification information for identifying a layer packet included in the flow packet, information indicating whether the flow packet is transmitted over one or more RS frames, information indicating whether a CRC has been applied to the flow packet, and the flow And receiving the flow packet header including at least one of information indicating the number of layer packets included in a packet.

Images