Source: https://patents.google.com/patent/US8185925B2/en
Timestamp: 2018-09-23 09:10:49
Document Index: 278649981

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 61', 'Application No. 61', 'Application No. 10']

US8185925B2 - Digital broadcasting system and method of processing data in the digital broadcasting system - Google Patents
US8185925B2
US8185925B2 US12197896 US19789608A US8185925B2 US 8185925 B2 US8185925 B2 US 8185925B2 US 12197896 US12197896 US 12197896 US 19789608 A US19789608 A US 19789608A US 8185925 B2 US8185925 B2 US 8185925B2
US12197896
US20090055875A1 (en )
A digital broadcasting system and a data processing method are disclosed. A receiving system of the digital broadcasting system includes a baseband processor, a first table handler, an audio/video processor, and a content processor. The baseband processor receives a broadcast signal including mobile and main service data. The mobile service data may configure an RS frame, and the RS frame may include mobile service data for mobile audio and/or video broadcasting, a first table describing at least one channel configuration information on the mobile service data, and a second table transmitting content for data casting service. The first table handler parses the first table from the RS frame, thereby acquiring at least one channel configuration information on the mobile service data. The audio/video processor extracts mobile service data of a mobile broadcast program requested for viewing from the RS frame, by referring to the channel configuration information of the first table handler, and decodes the extracted mobile service data, thereby outputting the decoded data to a speaker and/or a display screen. And, the content processor parses the second table from the RS frame to extract content, and processes the extracted content based upon an information associated with the extracted content.
This application claims the benefit of U.S. Provisional Patent Application No. 60/957,714, filed on Aug. 24, 2007, U.S. Provisional Patent Application No. 60/974,084, filed on Sep. 21, 2007, U.S. Provisional Patent Application No. 60/977,379, filed on Oct. 4, 2007, U.S. Provisional Patent Application No. 61/044,504 filed on Apr. 13, 2008, U.S. Provisional Patent Application No. 61/076,686, filed on Jun. 29, 2008 and Korean Patent Application No. 10-2008-0082427, filed on Aug. 22, 2008, which are hereby incorporated by reference as if fully set forth herein.
Another object of the present invention is to provide a digital broadcasting system and a data processing method that can receive and process content for a data casting service, which is transmitted in a table format.
To achieve these objects and other advantages and in accordance with the purpose of the invention, as embodied and broadly described herein, a digital broadcast receiving system includes a baseband processor, a first table handler, an audio/video processor, and a content processor. The baseband processor receives a broadcast signal including mobile service data and main service data. Herein, the mobile service data may configure an RS frame, and the RS frame may include mobile service data for at least one of mobile audio broadcasting and mobile video broadcasting, a first table describing at least one channel configuration information on the mobile service data, and a second table transmitting content for data casting service. The first table handler parses the first table from the RS frame, thereby acquiring at least one channel configuration information on the mobile service data. The audio/video processor extracts mobile service data of a mobile broadcast program requested for viewing from the RS frame, by referring to the channel configuration information of the first table handler, and decodes the extracted mobile service data, thereby outputting the decoded data to at least one of a speaker and a display screen. And, the content processor parses the second table from the RS frame, so as to extract a content, and processes the extracted content based upon an information associated with the extracted content.
Herein, at least one data group configuring the RS frame may each include a plurality of known data sequences, wherein a signaling information region may be included between a first known data sequence and a second known data sequence, and wherein the signaling information region may include transmission parameter channel (TPC) signaling data and fast information channel (FIC) signaling data.
The baseband processor may further include a known sequence detector detecting known data sequences included in the data group. Herein, the detected known data sequence may be used for demodulation and channel-equalization of the mobile service data.
The information associated with the content may be included in at least one of the first table and the second table.
Also, the information associated with the content may include synchronization identification information identifying a synchronization status with a mobile broadcast program.
Herein, when the synchronization identification information indicates the content extracted from the second table to be in synchronization with the mobile broadcast program, the content processor may either immediately process the content based upon a display information from the information associated with the corresponding content, thereby outputting the processed content to a display screen, or store the extracted content and process the corresponding content at a designated trigger time, thereby outputting the processed content to the display screen.
Alternatively, when the synchronization identification information indicates the content extracted from the second table to not be in synchronization with the mobile broadcast program, the content processor may store the extracted content and delete the stored content when a content deletion time is expired.
In another aspect of the present invention, a data processing method of a digital broadcast receiving system includes the steps of receiving a broadcast signal including mobile service data and main service data, wherein the mobile service data configures an RS frame, and wherein the RS frame include mobile service data for at least one of mobile audio broadcasting and mobile video broadcasting, a first table describing at least one channel configuration information on the mobile service data, and a second table transmitting content for data casting service, parsing the first table from the RS frame, thereby acquiring at least one channel configuration information on the mobile service data, extracting mobile service data of a mobile broadcast program requested for viewing from the RS frame, by referring to the channel configuration information of the first table handler, and decoding the extracted mobile service data, thereby outputting the decoded data to at least one of a speaker and a display screen, and parsing the second table from the RS frame, so as to extract a content, and processing the extracted content based upon an information associated with the extracted content.
FIG. 26 illustrates an exemplary syntax structure of a data casting table according to a first embodiment of the present invention;
FIG. 27 illustrates an exemplary syntax structure of a data cast descriptor according to a second embodiment of the present invention;
FIG. 28 illustrates an exemplary syntax structure of a data casting table according to a second embodiment of the present invention;
FIG. 29 to FIG. 33 respectively illustrate exemplary data casting service screens according to the present invention;
FIG. 34 illustrates a flow chart showing process steps of a data casting service method according to the present invention; and
FIG. 35 illustrates a block view showing a structure of a digital broadcast receiving system for data casting service according to another embodiment of the present invention.
More specifically, 276 (=207+69) bytes of the 4th MH block (B4) in each data group are assigned as the signaling information area. In other words, the signaling information area consists of 207 bytes of the 1st segment and the first 69 bytes of the 2nd segment of the 4th MH block (B4). The 1st segment of the 4th MH block (B4) corresponds to the 17th or 173rd segment of a VSB field.
Basically, the method of assigning data groups corresponding to multiple parades is very similar to the method of assigning data groups corresponding to a single parade. In other words, data groups included in other parades that are to be assigned to an MH frame are also respectively assigned according to a cycle period of 4 slots. At this point, data groups of a different parade may be sequentially assigned to the respective slots in a circular method. Herein, the data groups are assigned to slots starting from the ones to which data groups of the previous parade have not yet been assigned.
Therefore, a number of groups of one parade per sub-frame (NoG) may correspond to any one integer from ‘1’ to ‘8’. Herein, since one MH frame includes 5 sub-frames, the total number of data groups within a parade that can be allocated to an MH frame may correspond to any one multiple of ‘5’ranging from ‘5’ to ‘40’.
A component_level_descriptor ( ) represents zero or more descriptors providing additional information on the corresponding IP stream component.
A virtual_channel_level_descriptor ( ) represents zero or more descriptors providing additional information for the corresponding virtual channel.
An ensemble_level_descriptor ( ) represents zero or more descriptors providing additional information for the MH ensemble, which is described by the corresponding SMT.
When at least one audio service is present as a component of the current event, the MH_audio_descriptor ( ) shall be used as a component_level_descriptor of the SMT. The MH_audio_descriptor ( ) may be capable of informing the system of the audio language type and stereo mode status. If there is no audio service associated with the current event, then it is preferable that the MH_audio_descriptor ( ) is considered to be insignificant (or absent) for the current event.
A descriptor_tag field is an 8-bit unsigned integer having a TBD value, which indicates that the corresponding descriptor is the MH_audio_descriptor ( ).
A descriptor_length field is also an 8-bit unsigned integer, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_audio_descriptor ( ).
The MH_RTP_payload_type_descriptor ( ) specifies the RTP payload type. Yet, the MH_RTP_payload_type_descriptor ( ) exists only when the dynamic value of the RTP_payload_type field within the num_components loop of the SMT is in the range of ‘96’ to ‘127’. The MH_RTP_payload_type_descriptor ( ) is used as a component_level_descriptor of the SMT.
The fields included in the MH_RTP_payload_type_descriptor ( ) will now be described in detail.
A descriptor_tag field corresponds to an 8-bit unsigned integer having the value TBD, which identifies the current descriptor as the MH_RTP_payload_type_descriptor ( ).
A descriptor_length field also corresponds to an 8-bit unsigned integer, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_RTP_payload_type_descriptor ( ).
The MIME_type field indicates the MIME type corresponding to the encoding format of the IP stream component, which is described by the MH_RTP_payload_type_descriptor ( ).
The MH_current_event_descriptor ( ) shall be used as the virtual_channel_level_descriptor ( ) within the SMT. Herein, the MH_current_event_descriptor ( ) provides basic information on the current event (e.g., the start time, duration, and title of the current event, etc.), which is transmitted via the respective virtual channel.
The fields included in the MH_current_event_descriptor ( ) will now be described in detail.
A descriptor_tag field corresponds to an 8-bit unsigned integer having the value TBD, which identifies the current descriptor as the MH_current_event_descriptor ( ).
A descriptor_length field also corresponds to an 8-bit unsigned integer, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_current_event_descriptor ( ).
The optional MH_next_event_descriptor ( ) shall be used as the virtual_channel_level_descriptor ( ) within the SMT. Herein, the MH_next_event_descriptor ( ) provides basic information on the next event (e.g., the start time, duration, and title of the next event, etc.), which is transmitted via the respective virtual channel.
The fields included in the MH_next_event_descriptor ( ) will now be described in detail.
A descriptor_tag field corresponds to an 8-bit unsigned integer having the value TBD, which identifies the current descriptor as the MH_next_event_descriptor ( ).
A descriptor_length field also corresponds to an 8-bit unsigned integer, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_next_event_descriptor ( ).
The MH_system_time_descriptor ( ) shall be used as the ensemble_level_descriptor ( ) within the SMT. Herein, the MH_system_time_descriptor ( ) provides information on current time and date. The MH_system_time_descriptor ( ) also provides information on the time zone in which the transmitting system (or transmitter) transmitting the corresponding broadcast stream is located, while taking into consideration the mobile/portable characteristics of the MH service data.
The fields included in the MH_system_time_descriptor ( ) will now be described in detail.
A descriptor_tag field corresponds to an 8-bit unsigned integer having the value TBD, which identifies the current descriptor as the MH_system_time_descriptor ( ).
A descriptor_length field also corresponds to an 8-bit unsigned integer, which indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_system_time_descriptor ( ).
Also, the above-described EMT (or SMT according to the second embodiment of the present invention) may be divided into constant units, such as section units. Herein, each of the constant units may describe an ensemble.
Meanwhile, by receiving and processing mobile service data for data casting, the present invention may provide data casting service to the user. The present invention may transmit mobile service data for data casting service in a table format. In the description of the present invention, such table will be referred to as a data casting table (DCT). Hereinafter, the mobile service data for data casting service will be referred to as “content” or “multimedia” and “data file” for simplicity. The content may have a single file structure, and a file may be divided into at least one fragment. Herein, the file will be assigned to the data casting table in fragment units, thereby being transmitted.
At this point, the content being included in the DCT and received by the receiving system may correspond to data synchronized with a mobile A/V broadcast program currently being broadcasted or to non-synchronized data. If the content corresponds to the data synchronized with a mobile A/V broadcast program, the data casting service may be provided by being interconnected with the mobile A/V broadcast program. On the other hand, if the content corresponds to data non-synchronized with a mobile A/V broadcast program, the data casting service may be provided independently.
According to a first embodiment of the present invention, information associated with content, which includes identification information for identifying synchronization status and display information, is included in the DCT transmitting the corresponding content.
According to a second embodiment of the present invention, information associated with content, which includes identification information for identifying synchronization status and display information, is included in at least one of an SMT and an EMT in a descriptor format.
According to a first embodiment of the present invention, content for the data casting service and information associated with content are included in the DCT, thereby being received.
FIG. 26 illustrates an exemplary syntax structure of a data casting table (DCT) according to the first embodiment of the present invention. Herein, the DCT is configured in an MPEG-2 private section format. However, this will not limit the scope and spirit of the present invention. Referring to FIG. 26, the table_ID field indicates that the corresponding table is a DCT. The section_syntax_indicator field may be set to have a value of ‘1’. This may indicate that a general MPEG-2 section syntax may follow the section_length field. The private_indicator field indicates whether or not the DCT is in accordance with a private section. The section_length field indicates the length of the SCT section in byte units. The transport_stream_id field indicates a transport_stream identifier of a physical channel through which the corresponding DCT is being transmitted.
The version_number field indicates the version number of the corresponding DCT. The current_next_indicator field indicates whether or not the data included in the following DCT section are currently applicable. The section_number field indicates the section number of the corresponding DCT. The last_section_number field indicates the last section number of a completed DCT. The protocol_version field indicates the protocol version of the corresponding DCT. The content_id field indicates an identification value for identifying the content being transmitted to the corresponding DCT. The content_name field is repeated as many times as the content_name_length field value, thereby indicating the name of the content being transmitted to the corresponding DCT.
The MIME_type( ) field is repeated as many times as the MIME_type_length field value, thereby indicating a MIME type of the content being transmitted to the corresponding DCT. The sync_type field indicates whether or not the content being transmitted to the corresponding DCT is synchronized with the mobile A/V broadcast program. For example, if the sync_type field value is equal to ‘00’, this indicates that the content is synchronized with the mobile A/V broadcast program. Conversely, if the sync_type field value is equal to ‘01’, this indicates that the content is not synchronized (or non-synchronized).
When the sync_type field type value is equal to ‘00’, the sync_type field may include the major_channel_number field, the minor_channel_number field, the now_flag field, and the trigger_duration field. Herein, the sync_type field may further include a trigger_time field based upon the now_flag field value. When the sync_type field type value is equal to ‘00’, the major_channel_number field indicates a major channel number of the mobile A/V broadcast program synchronized with the content. Alternatively, when the sync_type field type value is equal to ‘00’, the minor_channel_number field indicates a minor channel number of the mobile A/V broadcast program synchronized with the content.
The now_flag field indicates a display type of the content received by the corresponding DCT. For example, when the now_flag field value is equal to ‘1’, the received content is displayed immediately. On the other hand, when the now_flag field value is equal to ‘0’, the received content is displayed in accordance with a trigger time. When the now_flag field value is equal to ‘0’, the trigger_time field indicates the start time of the current content as the number of GPS seconds since 00:00:00 UTC, Jan. 6, 1980. When the sync_type field value is equal to ‘00’, the trigger_duration field indicates the display duration time of the received content in ms units. For example, when the now_flag field value is equal to ‘1’, the received content is immediately displayed, and the duration time of the display is maintained in accordance with the trigger_duration field value. Alternatively, when the now_flag field value is equal to ‘0’, the received content is displayed at the time indicated by the trigger_time field value, and the duration time of the display is maintained in accordance with the trigger_duration field value.
The expire_time field is included, when the sync_type field value is equal to ‘01’. More specifically, when the sync_type field value is equal to ‘01’, the expire_time field indicates that the content received by the DCT is deleted by force. The URI_flag field indicates whether a content position is designated by a uniform resource identifier (URI). For example, when the URI_flag field value is equal to ‘1’, this indicates that the position of the content is designated by the URI. On the other hand, when the URI_flag field value is equal to ‘0’, this indicates that the corresponding content is carried in a content_raw_data field so as to be delivered (or transmitted).
When the URI_flag field value is equal to ‘1’, the URI_length field indicates the length of a URI text. Herein, the URI_text ( ) field indicates the URI of the position wherein the corresponding content is located. When the URI_flag field value is equal to ‘0’, the content_length field indicates the length of the content_raw_data field. And, in the content_raw_data actual content is fragmented. According to the first embodiment of the present invention, the now_flag field, the trigger_time field, the trigger_duration field, and the expire_time field will be collectively referred to as “display information”.
According to a second embodiment of the present invention, content for the data casting service and information associated with content are included in the DCT, thereby being received. Herein, the content-associated information is included in at least one of the SMT of FIG. 17 and the EMT of FIG. 26 in a descriptor format, thereby being received. According to the second embodiment of the present invention, the above-described descriptor will be referred to as the data cast descriptor. FIG. 27 illustrates an exemplary syntax structure of a data cast descriptor MH_DataCast_descriptor( ) according to the second embodiment of the present invention.
Referring to FIG. 27, the descriptor_tag field indicates that the corresponding descriptor is a data cast descriptor MH_DataCast_descriptor ( ). The descriptor_length field indicates the indicates the length (in bytes) of the portion immediately following the descriptor_length field up to the end of the MH_DataCast_descriptor ( ). The content_id field indicates an identification value for identifying (or distinguishing) the content being transmitted to the DCT. More specifically, the content_id field value is used as link information for linking the information associated with the corresponding content to the DCT transmitting the corresponding content. Therefore, the content_id field value is also included in the DCT, which transmits the corresponding content. The content_id field of the DCT has the same field value as that of the content_id field of the MH_DataCast_descriptor ( ).
The content_name field is repeated as many times as the content_name_length field value, thereby indicating the name of the content being transmitted to the corresponding DCT. The MIME_type( ) field is repeated as many times as the MIME_type_length field value, thereby indicating a MIME type of the content being transmitted to the corresponding DCT. The sync_type field indicates whether or not the content being transmitted to the corresponding DCT is synchronized with the mobile A/V broadcast program. For example, if the sync_type field value is equal to ‘00’, this indicates that the content is synchronized with the mobile A/V broadcast program. Conversely, if the sync_type field value is equal to ‘01’, this indicates that the content is not synchronized (or non-synchronized).
When the sync_type field type value is equal to ‘00’, the sync_type field may include the now_flag field and the trigger_duration field. Herein, the sync_type field may further include a trigger_time field based upon the now_flag field value. When the sync_type field value is equal to ‘00’, the now_flag field indicates a display type of the content received by the corresponding DCT. For example, when the now_flag field value is equal to ‘1’, the received content is displayed immediately. On the other hand, when the now_flag field value is equal to ‘0’, the received content is displayed in accordance with a trigger time. When the now_flag field value is equal to ‘0’, the trigger_time field indicates the start time of the current content as the number of GPS seconds since 00:00:00 UTC, Jan. 6, 1980.
When the sync_type field value is equal to ‘00’, the trigger_duration field indicates the display duration time of the received content in ms units. For example, when the now_flag field value is equal to ‘1’, the received content is immediately displayed, and the duration time of the display is maintained in accordance with the trigger_duration field value. Alternatively, when the now_flag field value is equal to ‘0’, the received content is displayed at the time indicated by the trigger_time field value, and the duration time of the display is maintained in accordance with the trigger_duration field value. The expire_time field is included, when the sync_type field value is equal to ‘01’. More specifically, when the sync_type field value is equal to ‘01’, the expire_time field indicates that the content received by the DCT is deleted by force.
FIG. 28 illustrates an exemplary syntax structure of a data casting table (DCT) according to the second embodiment of the present invention. Herein, the DCT is configured in an MPEG-2 private section format. However, this will not limit the scope and spirit of the present invention. Referring to FIG. 28, the table_ID field indicates that the corresponding table is a DCT. The section_syntax_indicator field may be set to have a value of ‘1’. This may indicate that a general MPEG-2 section syntax may follow the section_length field. The private_indicator field indicates whether or not the DCT is in accordance with a private section. The section_length field indicates the length of the DCT section in byte units. The transport_stream_id field indicates a transport_stream identifier of a physical channel through which the corresponding DCT is being transmitted.
The version_number field indicates the version number of the corresponding DCT. The current_next_indicator field indicates whether or not the data included in the following DCT section are currently applicable. The section_number field indicates the section number of the corresponding DCT. The last_section_number field indicates the last section number of a completed DCT. The protocol_version field indicates the protocol version of the corresponding DCT. The content_id field indicates an identification value for identifying the content being transmitted to the corresponding DCT.
As described above, the content_id field value is used as link information for linking the information associated with the corresponding content to the data cast descriptor transmitting the corresponding content. More specifically, the information associated with the content is required for extracting and processing the content received through the DCT. Accordingly, the content_id field value is used as information for searching the data cast descriptor, which transmits the information associated with the corresponding content.
The URI_flag field indicates whether or not the position of the content is designated by using the URI. For example, when the URI_flag field value is equal to ‘1’, this indicates that the position of the content is designated by the URI. Alternatively, when the URI_flag field value is equal to ‘0’, this indicates that the corresponding content is carried in the content_raw_data field, thereby being transmitted. When the URI_flag field value is equal to ‘1’, the URI_length field indicates the length of the URI text. Herein, the URI_text ( ) field indicates the URI of the position where the content is located. When the URI_flag field value is equal to ‘0’, the content_length field indicates the length of the content_raw_data field. Actual content is fragmented in the content_raw_data field.
The mobile A/V broadcast program may correspond to a mobile audio-specific broadcast program, or to a mobile video-specific broadcast program, or to a mobile audio/video-integrated broadcast program.
For example, when the mobile A/V broadcast program corresponds to a mobile audio-specific broadcast program, content including still images is delivered through the DCT. Accordingly, while listening to the audio content, the user may be provided with background images, such as studio images, traffic information, weather forecast, stock information, lyrics, music album cover, and so on through the display screen. Furthermore, by sequentially and continuously delivering still images through the DCT, the images may be provided to the user in a slideshow mode.
Alternatively, in case of music programs, by delivering contents including the music currently being broadcasted through the DCT in an mp3 file format, the corresponding content may be executed (or played) later on. The content according to the present invention may also be applied in a variety of other data broadcast programs. More specifically, the content may be equally applied in mobile video-specific broadcast programs or in mobile audio/video-integrated broadcast programs.
FIG. 29 illustrates a background image showing an audio output power status on a mobile audio transmission screen. Thus, the user may be able to verify the output power status of the audio content that is currently being played.
FIG. 30 illustrates a background image showing studio images on the mobile audio transmission screen. Thus, the user may be informed of the ambience of the studio via which the audio content is being provided.
FIG. 31 illustrates a background image showing a music album cover on the mobile audio transmission screen. Thus, the user may be able to view the music album cover image of the song, which the user is listening to.
FIG. 32 illustrates a background image showing traffic information on the mobile audio transmission screen. Thus, the user may be provided with traffic information while listening to his/her music program.
FIG. 33 illustrates a background image showing cooking information on the mobile audio transmission screen. Thus, the user may be provided with cooking information while listening to his/her music program.
If background images including at least one of the images shown in FIG. 29 to FIG. 33 are delivered (or transmitted) through the DCT at a constant interval, since the images may switch in accordance with the constant interval, the present invention may provide the images to the user in a slideshow format.
FIG. 34 illustrates a flow chart of a data casting service method according to an embodiment of the present invention. Particularly, FIG. 34 illustrates a data casting service method that can be applied when content and information associated with the content are received through the DCT shown in FIG. 26. More specifically, when a DCT section is received (S701), at least one DCT section is collected so as to configure a complete DCT (S702). Herein, the table_id field, the section_number field, and the last_section_number field within the DCT may indicate whether a single DCT is configured of a single DCT section or multiple DCT section. When the DCT is completed, in step 702, the content_id field, the content_name field, the MIME_type field, the sync_type field of the DCT are parsed, so that content identification information (content_id), content name (content_name), MIME type information (MIME_type), and synchronization identification information (sync_type) can be acquired (S703). When the synchronization identification information indicates that the content received by the DCT is synchronized with the mobile A/V broadcast program, (i.e., when the sync_type field value is equal to ‘00’) (S704), a major channel number (major_channel_number) and a minor channel number (minor_channel_number) of the mobile A/V broadcast program synchronized with the corresponding content are acquired (S705).
Then, the system verifies whether or not the major channel number (major_channel_number) and the minor channel number (minor_channel_number), which are acquired in step 705, are identical to the mobile A/V broadcast program that is currently being viewed (S706). If it is determined that the data are identical to one another, the system verifies whether the URI_flag field value within the DCT is equal to ‘1’, i.e., whether the position of the content is designated by the URI (S707). In step 707, when the URI_flag field value is equal to ‘1’ (i.e., when the position of the content is designated by the URI), the URI_length field and the URI_text ( ) field are parsed so that the corresponding content can be acquired from the designated URI (S708). Also, in step 707, when the URI_flag field value is equal to ‘0’ (i.e., when the position of the content is not designated by the URI), the content_length field and the content_raw_data field are parsed so that the content transmitted to the DCT can be acquired.
At this point, the content configured of a single file is divided into at least one fragment. Herein, since each fragment unit is included in the DCT and received, the fragments corresponding to a content file are collected to configure the content file. Also, the system verifies whether the now_flag field value of the DCT is equal to ‘0’ (S710). For example, when the now_flag field value is equal to ‘1’, the received content is immediately displayed. And, when the now_flag field value is equal to ‘0’, the received content is displayed in accordance with the trigger time. Therefore, in step 710, when the now_flag field value is equal to ‘1’, the content acquired in step 708 or in step 709 is immediately displayed. Thereafter, the duration of the content display is maintained in accordance with the trigger_duration field value (S711). Also, in step 710, when the now_flag field value is equal to ‘0’, the content acquired in step 708 or in step 709 is displayed at the time indicated by the trigger_time field value. Thereafter, the duration of the content display is maintained in accordance with the trigger_duration field value (S712).
Meanwhile, in step 704, when the synchronization identification information indicates that the content received by the DCT is not synchronized with the mobile A/V broadcast program, (i.e., when the sync_type field value is equal to ‘01’), the system verifies whether or not the URI_flag field value within the DCT is equal to ‘1’ (i.e., whether the position of the content is designated by the URI) (S713). In step 713, when the URI_flag field value is equal to ‘1’ (i.e., when the position of the content is designated by the URI), the URI_length field and the URI_text ( ) field are parsed so that the corresponding content can be acquired from the designated URI (S714). Also, in step 713, when the URI_flag field value is equal to ‘0’ (i.e., when the position of the content is not designated by the URI), the content_length field and the content_raw_data field are parsed so that the content transmitted to the DCT can be acquired (S715). Furthermore, after storing the content acquired in step 714 or step 715 in a non-volatile memory (S716), when the time designated by the expire_time field value within the DCT is expired (or passed), the corresponding content is deleted from the non-volatile memory (S717). At this point, when the user inputs a request within the time designated by the expire_time field value, the corresponding content is read and outputted from the non-volatile memory so as to be processed and displayed to the display screen.
The digital broadcast receiving system of FIG. 1 may further include a DCT handler processing content for the above-described data casting service. If the DCT is transmitted via an IP-based channel, the DCT handler may be provided between the IP network stack 220 and the storage unit 290. The operation of the DCT handler will be described in detail later on. Furthermore, if the content for the data casting service is received via an IP-based channel, the digital broadcast receiving system may further include a URI handler acquiring and processing content from the designated URI. Herein, the URI handler may also be provided between the IP network stack 220 and the storage unit 290.
FIG. 35 illustrates a block view showing the structure of a receiving system according to another embodiment of the present invention. The receiving system shown in FIG. 35 includes a host 800, a baseband processor 801, an RS frame handler 802, an A/V decoder 803, a display module 804, an FIC handler 806, an SMT handler 807, a channel/service map database (DB) 808, a DCT handler 809, a URI handler 810, a content storage unit 811, and a content processor 812. The host 800 may be a CPU, or an operation controller 110 shown in FIG. 1, or a physical adaptation control signal handler 216. The baseband processor 100 shown in FIG. 1 may be directly applied as the baseband processor 801 without modification. The SMT handler 807 may include an EMT handler. More specifically, the RS frame demodulated and error-corrected by the baseband processor 801 is outputted to the RS frame handler 802, and the FIC is outputted to the FIC handler 806.
The RS frame handler 802 identifies (or distinguishes) a mobile audio stream and a mobile video stream from the RS frame transmitted from the baseband processor 801 at a constant time interval (e.g., MH frame) determined by the host 800 and respectively outputs the identified mobile audio/video streams to the A/V decoder 803. When only the mobile audio stream is outputted from the RS frame handler 802, the A/V decoder 803 performs audio decoding using an audio decoding algorithm. And, when only the mobile video stream is outputted from the RS frame handler 802, the A/V decoder 803 performs video decoding using a video decoding algorithm. Finally, when both the mobile audio stream and the mobile video stream are outputted from the RS frame handler 802, the A/V decoder 803 performs audio decoding and video decoding using the audio decoding algorithm and the video decoding algorithm, respectively. Thereafter, the audio and/or video data decoded by the A/V decoder 803 are provided to the user through a display screen and/or speaker of the display module 804.
Additionally, when an SMT section is included in the RS frame, the RS frame handler 802 outputs the SMT section to the SMT handler 807. If the EMT section is included in the SMT section, the EMT section is also outputted to the SMT handler 807. The SMT handler 807 collects (or gathers) at least one SMT section so as to complete an SMT. Thereafter, the SMT handler 807 parses the completed SMT and stores the parsed result in the channel/service map DB 808 through the host 800. When the SMT is parsed, MH ensemble level signaling information, IP access information on each virtual channel belonging to the corresponding MH ensemble including each SMT, and IP stream component level information required for servicing (or providing) the corresponding virtual channel may be acquired. Furthermore, the SMT handler 807 collects (or gathers) at least one EMT section so as to complete an EMT. Thereafter, the SMT handler 807 parses the completed EMT and stores the parsed result in the channel/service map DB 808 through the host 800.
If a data cast descriptor shown in FIG. 27 is included in the parsed SMT or EMT, the SMT handler 807 outputs the data cast descriptor to the DCT handler 809. Also, if a DCT section is included in the RS frame, the RS frame handler 802 outputs the DCT section to the DCT handler 809. The DCT handler 809 collects at least one DCT section, so as to complete a single DCT. Thereafter, the DCT handler 809 parses the completed DCT. Herein, the content for data casting service may be included in the DCT and received. The information associated with the content may either be included in the DCT and then received, or be included in the SMT or EMT as the data cast descriptor and then received.
Accordingly, when the content for the data casting service and the information associated with the content are included in the DCT and then received, according to the first embodiment of the present invention, the DCT is parsed so as to extract the content and information associated with the content. Then, based upon the extracted information associated with the content, the corresponding content is either immediately displayed on the display screen or displayed on the display screen at a designated time.
Alternatively, when the content for the data casting service is included, and when the information associated with the content is included in the SMT or EMT as the data cast descriptor and then received, according to the second embodiment of the present invention, the data cast descriptor is parsed so as to extract information associated with the content, and the DCT is parsed so as to extract the content. Herein, the content_id field value may be used as information for linking the data cast descriptor to the DCT. Also, based upon the information associated with the extracted information, the corresponding content is immediately displayed on the display screen during a predetermined trigger duration period. Alternatively, the corresponding content is displayed on the display screen at a designated trigger time during a predetermined trigger duration period.
Meanwhile, when the URI_flag field value in the DCT is equal to ‘1’ (i.e., when the position of the content is designated by the URI), this indicates that the content for the data casting service is received via an IP-based channel having the URI. In this case, based upon the control of the host 800, the URI handler 810 acquires content of the designated URI from the RS frame, thereby outputting the acquired content to the DCT handler 809. Based upon the information associated the content extracted from any one of the tables DCT, SMT, and EMT, the DCT handler 809 either immediately displays the corresponding content on the display screen or displays the content on the display screen at a designated time.
More specifically, among the information associated with the content, when the display type information (i.e., now_flag field) designates immediate display, the corresponding content is inputted to the content processor 812, so as to be processed to fit the required display format. Afterwards, the processed content is outputted to the display screen through the display module 804 during the predetermined trigger duration. Meanwhile, when the display type information (i.e., now_flag field) designates a specific display trigger time, the corresponding content is stored in the content storage unit 811, which is a non-volatile memory unit. Subsequently, at the designated display trigger time, the stored content is inputted to the content processor 812, so as to be processed to fit the required display format. Thereafter, the processed content is outputted to the display screen through the display module 804 during the predetermined trigger duration.
receiving a broadcast signal, the broadcast signal comprising mobile service data, a service map table (SMT) including access information of the mobile service data, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data, wherein the FIC data includes information for rapid mobile service acquisition, and wherein the TPC data includes FIC version information for indicating an update of the FIC data;
building Reed-Solomon (RS) frames including the mobile service data from the received broadcast signal, the RS frames belonging to an ensemble, the ensemble including the SMT;
obtaining the SMT from the ensemble; and
processing the mobile service data based on the access information of the SMT,
wherein a size of at least one of the RS frames is L (rows)×N (column size of a payload of the RS frame) bytes, each row having an M-byte header leaving the rest of the row available for data, wherein the data in the rows are packed into the rows end-to-end, with possible wrapping around at the end of each row to the next row, wherein L, M, and N are integers, and
wherein the FIC data and the SMT further include an ensemble identifier for identifying the ensemble, respectively.
4. The method of claim 1, wherein the header includes at least one of type information indicating a type of data in the row, information indicating whether or not an error is included in the row, and information indicating whether or not stuffing bytes are included in the row.
5. The method of claim 4, further comprising determining a type of the mobile service data included in the row based upon the type information included in the header.
a tuner for receiving a broadcast signal, the broadcast signal comprising mobile service data, a service map table (SMT) including access information of the mobile service data, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data, wherein the FIC data includes information for rapid mobile service acquisition, and wherein the TPC data includes FIC version information for indicating an update of the FIC data;
a decoder for building Reed-Solomon (RS) frames including the mobile service data from the received broadcast signal, the RS frames belonging to an ensemble, the ensemble including the SMT;
a handler for obtaining the SMT from the ensemble; and
a processor for processing the mobile service data based on the access information of the SMT,
7. The broadcast receiver of claim 6, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
9. The broadcast receiver of claim 6, wherein the header includes at least one of type information indicating a type of data in the row, information indicating whether or not an error is included in the row, and information indicating whether or not stuffing bytes are included in the row.
10. The broadcast receiver of claim 9, wherein the decoder determines a type of the mobile service data included in the row based upon the type information included in the header.
performing, by a Reed Solomon (RS) encoder, RS encoding and Cyclic Redundancy Check (CRC) encoding on mobile service data to build RS frames, the RS frames belonging to an ensemble, wherein the ensemble includes a service map table (SMT) including access information of the mobile service data;
mapping each of the RS frames into a plurality of groups, wherein each group includes a portion of data included in a corresponding RS frame, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data, wherein the FIC data includes information for rapid mobile service acquisition, and wherein the TPC data includes FIC version information for indicating an update of the FIC data; and
wherein the FIC data and SMT further include an ensemble identifier for identifying the ensemble, respectively.
12. The method of claim 11, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
14. The method of claim 11, wherein the header includes type information indicating a type of data in the row and information indicating whether or not an error is included in the row.
15. The method of claim 14, wherein the header further includes information indicating whether or not stuffing bytes are included in the row.
a Reed Solomon (RS) encoder for performing RS encoding and Cyclic Redundancy Check (CRC) on mobile service data to build RS frames, the RS frames belonging to an ensemble, wherein the ensemble includes a service map table (SMT) including access information of the mobile service data,
wherein each of the RS frames is mapped into a plurality of groups, wherein each group includes a portion of data included in a corresponding RS frame, known data sequences, fast information channel (FIC) data, and transmission parameter channel (TPC) data, wherein the FIC data includes information for rapid mobile service acquisition, and wherein the TPC data includes FIC version information for indicating an update of the FIC data; and
a transmission unit for transmitting a broadcast signal including the plurality of groups,
17. The broadcast transmitter of claim 16, wherein the FIC data and the TPC data are positioned between a first known data sequence and a second known data sequence of the known data sequences.
19. The broadcast transmitter of claim 16, wherein the header includes type information indicating a type of data in the row and information indicating whether or not an error is included in the row.
20. The broadcast transmitter of claim 19, wherein the header further includes information indicating whether or not stuffing bytes are included in the row.
US12197896 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system Active 2031-02-14 US8185925B2 (en)
KR10-2008-0082427 2008-08-22
KR20080082427A KR101582149B1 (en) 2007-08-24 2008-08-22 The digital broadcasting system and a data processing method
US12197896 US8185925B2 (en) 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system
US20090055875A1 true US20090055875A1 (en) 2009-02-26
US8185925B2 true US8185925B2 (en) 2012-05-22
ID=40506450
US12197896 Active 2031-02-14 US8185925B2 (en) 2007-08-24 2008-08-25 Digital broadcasting system and method of processing data in the digital broadcasting system
US (1) US8185925B2 (en)
ESTI TS 102 470 V1.1.1, Digital Video Broadcasting (DVB); IP Datacast over DVB-H; Program Specific Information (PSI)/Service Information (SI), Apr. 2000.
US20090055875A1 (en) 2009-02-26 application
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LEE, SANG HYUP;CHOI, IN HWAN;KIM, JEONG WOO;AND OTHERS;REEL/FRAME:021836/0161;SIGNING DATES FROM 20081013 TO 20081020
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LEE, SANG HYUP;CHOI, IN HWAN;KIM, JEONG WOO;AND OTHERS;SIGNING DATES FROM 20081013 TO 20081020;REEL/FRAME:021836/0161