[go: up one dir, main page]

WO2013129781A1 - 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법 - Google Patents

모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법 Download PDF

Info

Publication number
WO2013129781A1
WO2013129781A1 PCT/KR2013/000755 KR2013000755W WO2013129781A1 WO 2013129781 A1 WO2013129781 A1 WO 2013129781A1 KR 2013000755 W KR2013000755 W KR 2013000755W WO 2013129781 A1 WO2013129781 A1 WO 2013129781A1
Authority
WO
WIPO (PCT)
Prior art keywords
emergency alert
service
mobile
fic
field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2013/000755
Other languages
English (en)
French (fr)
Inventor
오세진
김정우
곽민성
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Priority to KR1020137011187A priority Critical patent/KR101448663B1/ko
Priority to KR1020137011383A priority patent/KR101947554B1/ko
Priority to CN201380000196.8A priority patent/CN103416080B/zh
Priority to KR1020197016622A priority patent/KR102114625B1/ko
Priority to KR1020197003570A priority patent/KR101989900B1/ko
Priority to US13/882,940 priority patent/US9219556B2/en
Priority to CA2815707A priority patent/CA2815707C/en
Priority to US13/875,838 priority patent/US9236964B2/en
Publication of WO2013129781A1 publication Critical patent/WO2013129781A1/ko
Anticipated expiration legal-status Critical
Priority to US14/962,737 priority patent/US9516486B2/en
Priority to US15/336,560 priority patent/US9929820B2/en
Priority to US15/894,200 priority patent/US10171192B2/en
Priority to US16/216,761 priority patent/US10615896B2/en
Priority to US16/806,725 priority patent/US11032015B2/en
Priority to US17/329,642 priority patent/US11515954B2/en
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/53—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers
    • H04H20/59—Arrangements specially adapted for specific applications, e.g. for traffic information or for mobile receivers for emergency or urgency
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • G—PHYSICS
    • G08—SIGNALLING
    • G08B—SIGNALLING OR CALLING SYSTEMS; ORDER TELEGRAPHS; ALARM SYSTEMS
    • G08B27/00—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations
    • G08B27/006—Alarm systems in which the alarm condition is signalled from a central station to a plurality of substations with transmission via telephone network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/65—Arrangements characterised by transmission systems for broadcast
    • H04H20/71—Wireless systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04H—BROADCAST COMMUNICATION
    • H04H20/00—Arrangements for broadcast or for distribution combined with broadcast
    • H04H20/65—Arrangements characterised by transmission systems for broadcast
    • H04H20/71—Wireless systems
    • H04H20/72—Wireless systems of terrestrial networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
    • H04L1/0041—Arrangements at the transmitter end
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/488—Data services, e.g. news ticker
    • H04N21/4882—Data services, e.g. news ticker for displaying messages, e.g. warnings, reminders
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8126—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts
    • H04N21/814—Monomedia components thereof involving additional data, e.g. news, sports, stocks, weather forecasts comprising emergency warnings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/30—Resource management for broadcast services

Definitions

  • the present invention relates to a mobile broadcast system. More particularly, the present invention relates to an apparatus and a method for providing an emergency alert service through a mobile broadcasting system.
  • An object of the present invention is to solve the above problems, and to provide an emergency alert service in a mobile broadcasting system.
  • a method for providing an emergency alert service through a mobile broadcast includes generating an RS frame which is a two-dimensional data frame by encoding an ensemble Reed-Solomon (CR)-Cyclic Redundancy Check (CRC).
  • the ensemble includes a service signaling channel including mobile data for a mobile broadcast service and access information for the mobile broadcast service, wherein the generated RS frame comprises a plurality of RS frames.
  • Dividing into portions generating signaling data including a transmission parameter channel (TPC) for signaling transmission parameters of a mobile broadcast, and a fast information channel (FIC) including connection information between the ensemble and the broadcast service; Step, a portion of the signaling data and data including the RS frame portion Generating a group, and generating a mobile broadcast signal including the data group, wherein the service signaling channel includes a service map table including attribute information on a mobile service transmitted by the ensemble; Map table) and a mobile emergency alert table including information for transmitting an emergency alert service to a mobile broadcast, wherein the mobile emergency alert table includes an emergency alert message transmission type field indicating a manner in which the emergency alert message is transmitted. It is characterized by including.
  • TPC transmission parameter channel
  • FAC fast information channel
  • the emergency alert message transmission type field indicates that the emergency alert message is included in the mobile emergency alert table and transmitted, or that the emergency alert message is transmitted through an IP datagram.
  • the mobile emergency alert table further comprises an autotuning channel number field indicating a physical RF channel number for autotuning to a physical RF channel providing the emergency alert service.
  • the mobile emergency alert table further comprises an emergency alert subject type field indicating a recipient of the emergency alert message.
  • the mobile emergency alert table further comprises an emergency situation type field for identifying an emergency situation that is the target of the emergency alert.
  • the mobile emergency alert table further comprises an NRT service identifier field identifying an NRT service that provides additional information related to the emergency alert message.
  • the FIC is included in the data group and transmitted in the form of a plurality of FIC segments, wherein the FIC segment includes an FIC segment header and an FIC segment payload, and the FIC segment header performs a wake-up function. It is characterized in that it comprises a wake-up indicator field indicating whether the mobile broadcast receiver should automatically power on and provide an emergency alert message.
  • the FIC comprises an FIC header and an FIC payload, wherein the FIC payload includes an EAT_ensemble_indicator field indicating whether the mobile emergency alert table is transmitted through a service signaling channel included in the ensemble. And a num_MH_services field indicating the number of mobile services transmitted through the ensemble, and an MH_service_signaling_channel_version field indicating version information of a service signaling channel included in the.
  • the FIC header includes an EAS_wake_up_extended_info_Tag field identifying whether a byte of the extended FIC header includes information for a wake-up function and an EAS_wake_up_version_number field indicating version information of signaling of the wake-up.
  • an apparatus for providing an emergency alert service through a mobile broadcast is an RS for generating an RS frame which is a two-dimensional data frame by encoding an ensemble RS (Reed-Solomon)-CRC (Cyclic Redundancy Check)
  • a frame encoder wherein the ensemble comprises a service signaling channel comprising mobile data for a mobile broadcast service and access information for the mobile broadcast service; Signaling including an RS frame divider for splitting into RS frame portions, a Transmission Parameter Channel (TPC) for signaling transmission parameters of mobile broadcasts, and a Fast Information Channel (FIC) including connection information between the ensemble and the broadcast service
  • TPC Transmission Parameter Channel
  • FIC Fast Information Channel
  • a signaling encoder for generating data, a portion and phase of the signaling data A data group formatter for generating a data group including an RS frame portion, and a broadcast signal generator for generating a mobile broadcast signal including the data group, wherein the service signaling channel is connected to a mobile service transmitted by the ensemble.
  • FIG. 1 is a diagram illustrating a transmission system according to an embodiment of the present invention.
  • FIG. 2 illustrates a signaling encoder according to an embodiment of the present invention.
  • FIG. 3 is a diagram illustrating a structure of an ensemble according to an embodiment of the present invention.
  • FIG. 4 is a diagram illustrating emergency alert data processing using a mobile emergency alert table according to an embodiment of the present invention.
  • FIG. 5 is a diagram illustrating syntax of a mobile emergency alert table according to an embodiment of the present invention.
  • FIG. 6 is a diagram illustrating the meaning according to each value of a type_of_responder field, a type_of_disciplines field, an EAS_message_transfer_type field, and an EAS_message_encoding_type field according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating syntax of an IP datagram when it is identified that an emergency alert message is transmitted through an IP datagram according to an embodiment of the present invention.
  • FIG. 8 is a diagram illustrating syntax of an FIC segment header according to an embodiment of the present invention.
  • FIG. 9 is a diagram illustrating syntax of an FIC chunk payload according to an embodiment of the present invention.
  • FIG. 10 is a flowchart illustrating a data processing for performing a wake-up function according to an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating syntax of an FIC chunk header according to an embodiment of the present invention.
  • FIG. 12 is a diagram illustrating a procedure for processing version information of wake-up signaling through extension of an FIC Chunk header according to an embodiment of the present invention.
  • FIG. 13 is a diagram illustrating processing of automatic tuning of a wake-up operation to a critical emergency alert according to an embodiment of the present invention.
  • FDT FLUTE File Delivery Table
  • FIG. 15 is a diagram illustrating syntax of a TPC for wake-up signaling using a TPC according to another embodiment of the present invention.
  • 16 is a diagram illustrating syntax of an FIC segment header according to another embodiment of the present invention.
  • FIG. 17 is a diagram illustrating an ESG content fragment according to another embodiment of the present invention.
  • FIG. 18 is a diagram illustrating an emergency alert system according to an embodiment of the present invention.
  • 19 is a diagram illustrating a scene for providing additional information of an emergency alert message using an NRT according to an embodiment of the present invention.
  • FIG. 20 is a diagram illustrating a scene for providing additional information of an emergency alert message using an NRT according to another embodiment of the present invention.
  • 21 is a diagram illustrating a UI of a mobile emergency alert system according to an embodiment of the present invention.
  • FIG. 22 is a diagram illustrating syntax of a mobile emergency alert table according to another embodiment of the present invention.
  • FIG. 22 is a diagram illustrating syntax of a mobile emergency alert table according to another embodiment of the present invention.
  • FIG. 23 is a diagram illustrating definitions of values of an event_urgency field, an event_severity field, an event_certainty field, and an EAS_message_type field according to another embodiment of the present invention.
  • FIG. 23 is a diagram illustrating definitions of values of an event_urgency field, an event_severity field, an event_certainty field, and an EAS_message_type field according to another embodiment of the present invention.
  • FIG. 24 is a diagram illustrating a mobile emergency alert table according to another embodiment of the present invention.
  • 25 is a diagram illustrating a mobile emergency alert table according to another embodiment of the present invention.
  • FIG. 26 is a diagram illustrating a descriptor for signaling an emergency alert service through extension of an SMT according to an embodiment of the present invention.
  • FIG. 27 illustrates a descriptor for signaling an emergency alert service according to another embodiment of the present invention.
  • 28 is a diagram illustrating signaling for providing an emergency alert service to one component according to an embodiment of the present invention.
  • FIG. 29 is a diagram illustrating an emergency_alert_IP_datagram () descriptor for emergency alert service transmission according to an embodiment of the present invention.
  • FIG. 30 is a diagram illustrating an emergency_alert_IP_datagram () descriptor for emergency alert service transmission according to another embodiment of the present invention.
  • FIG. 31 is a view showing a content fragment of an ESG for emergency alert service according to another embodiment of the present invention.
  • the main service data corresponds to data received by a fixed broadcast receiving system and may include audio / video data.
  • the main service data may include high definition (HD) or standard definition (SD) audio / video data, and may include various kinds of data for broadcasting.
  • Known data corresponds to data known in advance according to an appointment between the broadcast receiving system and the broadcast transmitting system.
  • MH is a term corresponding to mobile / handheld, as opposed to a fixed type system.
  • the MH service data (or mobile service data) may include any kind of data used in a mobile or portable system. Therefore, mobile service data according to an embodiment of the present invention is not limited to MH service data.
  • Mobile service data may include information such as program executable files or stock information.
  • Mobile service data may include audio / video data.
  • the mobile service data may correspond to audio / video data having a lower resolution and a lower data rate when compared to the main service data.
  • the MPEG-2 codec is used as the audio / video codec for the main service
  • the MPEG-2 codec, MPEG-4 advanced video coding (AVC), or scalable video coding (AVC) for mobile services
  • Higher image compression audio / video codecs such as scalable video coding (SVC) may be used.
  • the mobile service data may include TPEG data (transport protocol expert group data) for real time traffic broadcasting.
  • the mobile service data may include broadcast services / programs such as weather information service, traffic information service, stock information service, viewer participation quiz program, real time voting, interactive educational broadcast program, game service, or music program.
  • a data group means a set of data packets transmitted through a data slot (or MH slot).
  • the data group division represents a set of data group regions within one slot.
  • the data group division may be divided into a primary data group division or a secondary data group division.
  • the collection of primary data group divisions in an MH frame forms a primary parade, and the secondary data group divisions form a secondary parade.
  • the parade (or MH parade) represents a set of data groups having the same FEC parameters.
  • the parade may represent a set of data group divisions of data groups having the same data group type.
  • RS frame (Reed-Solomon Frame) is a two-dimensional data frame.
  • the payload of the RS frame is encoded by RS-CRC (Reed Solomon-Cyclic Redundancy Check) coding.
  • An ensemble represents a set of RS frames to which the same FEC (Forward Error Correction) code is applied.
  • each RS frame includes a compressed set of IP streams.
  • the ensemble may include mobile service data channels for mobile service data and mobile service signaling for mobile services.
  • the mobile service data for the mobile service may be transmitted through a part of a transport channel for transmitting the main service data to the main service.
  • the mobile service data for the mobile service may be transmitted through the entire transmission channel used for the main service.
  • data necessary for the mobile service may be referred to as mobile service data.
  • mobile service data may include known data, signaling data, and / or RS parity data.
  • the mobile service data may be classified into mobile service data of core mobile mode (CMM) and mobile service data of scalable full channel mobile mode (SFCMM).
  • CMS core mobile mode
  • SFCMM scalable full channel mobile mode
  • the CMM is a broadcast mode for transmitting main service data and mobile service data together.
  • the CMM may use at least 38 packets of the 156 packets in each slot to transmit main service data for the existing broadcast.
  • the SFCMM is a broadcast mode for transmitting only mobile service data or transmitting main service data with a smaller amount of the main service data than the CMM.
  • the SFCMM may use less than 38 packets of the 156 packets in each slot for the transmission of main service data.
  • the SFCMM parade represents a parade that is backward compatible with existing CMM systems / decoders but is not recognized by existing CMM systems / decoders.
  • the data group area represents a collection of data blocks or extended data blocks.
  • the data group area represents a certain area within the data group.
  • Each data group area may contain mobile service data for different purposes.
  • Transmission Parameter Channel may be included in each data group, and transmits information about a data frame or data group to a receiver and provides a transmission parameter.
  • FIC Fast information channel transmits cross layer information (or inter-layer information).
  • the FIC may include connection information between the ensemble and the mobile service.
  • FIG. 1 is a diagram illustrating a transmission system according to an embodiment of the present invention.
  • a transmission system includes a packet adjustment unit 101, a pre-processor 102, a data frame encoder 103, a block processor; 104), signaling encoder 105, group formatter 106, packet formatter 107, packet multiplexer 108, post-processor 109, Modified data randomizer (110), systematic / non-systematic RS encoder (systematic / non-systematic RS encoder; 111), data interleaver (112), non-systematic RS encoder (non-systematic RS) encoder; 113, parity replacer 114, modified trellis encoder 115, synchronization multiplexer 116, pilot inserter 117, VSB demodulator ( VSB modulator: 118), and / or ex Include; (119 transmission unit) unit.
  • the transmission system according to the present invention may further include a pre-equalizer filter 120.
  • the packet adjustment unit 101 may compensate for a location difference that may occur between a service stream that includes a mobile service stream and a service stream that does not include a mobile service stream.
  • the pre-processor 102 may serve to form mobile service data into a mobile service structure for transmitting mobile service data.
  • the preprocessor 102 can perform additional FEC coding on the mobile service data.
  • Preprocessor 102 can insert known data into a data group.
  • the preprocessor 102 improves the stability of the transmission and reception performance of mobile service data in a mobile environment.
  • the preprocessor 102 may include a data frame encoder 103, a block processor 104, a signaling encoder 105, a group formatter 106, and a packet formatter; 107), and / or a packet multiplexer 108.
  • the data frame encoder 103 randomizes mobile service data and performs RS encoding and cyclic redundancy check (CRC) encoding on the mobile service data.
  • the data frame encoder 103 generates an RS frame containing mobile service data.
  • the data frame encoder 103 may include an RS frame divider (not shown) that separates an RS frame to generate an RS frame portion.
  • a block processor 104 converts the RS frame portion into a serial concatenated convolutional coding (SCCC) block.
  • the block processor 104 converts a byte of mobile service data included in the SCCC block into mobile service data in units of bits.
  • the block processor 104 performs convolutional coding at 1/2, 1/3, or 1/4 rate on the mobile service data in units of bits. In this case, 1/2 rate means two bits are output when one bit is input, 1/3 rate means three bits are output when one bit is input, 1/4 Rate means that once one bit is entered, four bits are output.
  • the output bits are included in the symbol.
  • the block processor 104 performs interleaving on symbols that are convolutionally encoded and output.
  • the block processor 104 converts the interleaved symbols into data in bytes.
  • the block processor 104 converts the SCCC block into a data block.
  • the signaling encoder 105 generates signaling information for signaling at the receiving side.
  • the signaling encoder 105 performs FEC coding and Parallel Concatenated Convolutional Code (PCCC) encoding on the signaling information.
  • the signaling information includes TPC data and / or FIC data.
  • the group formatter 106 forms a data group containing mobile service data.
  • Group formatter 106 inserts the FEC coded mobile service data into an interleaved data group.
  • the group formatter 106 inserts initialization data bytes for initializing the memory of the signaling data modification trellis encoder 115, and / or known data strings (a set of contiguous known data) into the data group.
  • Group formatter 106 inserts a location holder for main service data, a location holder for MPEG-2 header and / or a location holder for non-systematic RS parity into the data group.
  • the group formatter 106 may insert dummy data to generate a group of data of a desired type.
  • the group formatter 106 After inserting various kinds of data, the group formatter 106 performs de-interleaving on the data in the data group of the interleaved form. After deinterleaving is performed, the data group is output as a data group in the form before being interleaved.
  • the data group generated in the group formatter 106 includes mobile service data corresponding to one RS frame portion.
  • the packet formatter 107 converts the output data of the group formatter 106 into a Transport Stream (TS) packet.
  • TS Transport Stream
  • the TS packet may be referred to as a mobile service data packet.
  • the packet formatter 107 outputs (118 + M) mobile service data packets for one data group. M is an integer of 38 or less here.
  • the packet multiplexer 108 multiplexes a packet including mobile service data processed by the preprocessor 102 and a packet including main service data.
  • the multiplexed packet contains (118 + M) mobile service data and L main service data packets.
  • M is an integer of 0 or more and 38 or less, and the sum of M and L is 38.
  • only the mobile service data is processed by the packet multiplexer 108.
  • the post-processor 109 processes the mobile service data so that the mobile service data is backward compatible with the existing broadcasting system. In this process, main service data can be processed together.
  • the post processor 109 may include a modified data randomizer 110, a systematic / non-systematic RS encoder 111, a data interleaver interleaver 112, a non-systematic RS encoder 113, a parity replacer 114, and / or a modified trellis encoder 115.
  • the modified data randomizer 110 bypasses the mobile service data packet without performing randomization on the mobile service data packet.
  • the revised data randomizer 110 performs rendering on the main service data packet.
  • the modified data randomizer 110 may not perform the rendering process.
  • the systematic / non-systematic RS encoder 111 performs systematic RS encoding on the main service data when the input data is a main service data packet.
  • the systematic / non-systematic RS encoder 111 performs non-systematic RS encoding on the mobile service data when the input data is a mobile service data packet.
  • Systematic / non-systematic RS parity generated by systematic / non-systematic RS encoding can be inserted at a predefined position in the data group.
  • the systematic / non-systematic RS encoder 111 does not need to perform RS encoding for the main service data. In this case, the systematic / non-systematic RS encoder 111 may not generate non-systematic RS parity for backward compatibility.
  • the data interleaver 112 performs interleaving on data including main service data and mobile service data.
  • the non-systematic RS encoder 113 receives the memory value of the modified trellis encoder 115, Mobile service data is received from the data interleaver 112 to convert the initialization data of the mobile service data into a memory value.
  • the non-systematic RS encoder 113 outputs the RS parity generated by performing non-systematic RS encoding on the changed mobile service data to the parity substituter 114.
  • the parity substituent 114 receives the mobile service data from the data interleaver 112 and converts the non-systematic RS parity of the mobile service data into a non-systematic RS encoder. Replace with the non-systematic RS parity generated by 113.
  • the packet multiplexed in the packet multiplexer 108 does not include the main service data packet, there is no need to include RS parity in the data group for backward compatibility. Accordingly, according to an embodiment of the present invention, in this case, the non-systematic RS encoder 113 and the parity substituent 114 do not perform the above-described operation, but perform an operation of bypassing the received data. Can be.
  • a modified trellis encoder 115 performs trellis encoding on the output of the data interleaver 112. After trellis encoding, in order to output known data in the form promised by the broadcast transmitting side and the broadcasting receiving side, the memory included in the trellis encoder 115 needs to be initialized before starting trellis encoding. have.
  • the above-described initialization operation may be started by the initialization data included in the data group.
  • a synchronization multiplexer 116 inserts the field synchronization signal and the segment synchronization signal into the output data of the modified trellis encoder 115 and multiplexes these data.
  • the pilot inserter 117 receives the multiplexed data at the synchronous multiplexer 116 and transmits the pilot signal used as a carrier phase for demodulation of the channel signal to the multiplexed data. Insert it.
  • the VSB demodulator 118 performs VSB modulation to transmit broadcast data.
  • a transmission unit 119 performs frequency up conversion on the modulated data and transmits the data on which the conversion has been performed.
  • FIG. 2 illustrates a signaling encoder according to an embodiment of the present invention.
  • the signaling encoder may include a first RS encoder 2100, a second RS encoder 2200, a block interleaver 2300, a multiplexer 2400, a signaling randomizer 2500, and / or a PCCC. Perform encoder 2600.
  • the first RS encoder 2100 performs RS encoding on the TPC data.
  • the second RS encoder 2200 performs RS encoding on the FIC data.
  • the first RS encoder and the second RS encoder perform RS encoding at different rates. That is, the TPC data and the FIC data are RS encoded at different rates.
  • the block interleaver 2300 performs block interleaving on RS encoded FIC data.
  • Block interleaving is to interleave FIC data in blocks.
  • the multiplexer 2400 multiplexes the RS encoded TPC data and the block interleaved FIC data.
  • the signaling randomizer 2500 renders the multiplexed data.
  • PCCC encoder 2600 PCCC encodes the rendered data.
  • FIG. 3 is a diagram illustrating a structure of an ensemble according to an embodiment of the present invention.
  • the ensemble transmits mobile service data constituting the mobile service.
  • the ensemble may include a Service Signaling Channel (SSC) for signaling mobile services.
  • SSC Service Signaling Channel
  • the service signaling channel may be defined to be transmitted through a specific IP address and a UDP port. That is, the receiving side may obtain service signaling channel data by parsing data of the corresponding IP address and the UDP port.
  • the service signaling channel includes a service map table (SMT) including attribute information on mobile services transmitted by an ensemble, and a guide access table including information on service guide data for mobile services.
  • SMT service map table
  • GAT Global System for Mobile communications
  • CIT Cell Information Table
  • Emergency Alert Table-MH Emergency Alert Table-MH; EAT-MH
  • FIG. 4 is a diagram illustrating emergency alert data processing using a mobile emergency alert table according to an embodiment of the present invention.
  • a Common Alerting Protocol (CAP) alert message may be compressed.
  • a mobile receiver (M / H receiver) capable of identifying the mobile emergency alert table may extract a compressed CAP alert message.
  • the mobile receiver may decompress the CAP alert message and quickly display the emergency alert message without referring to the SMT.
  • the mobile emergency alert table may transmit NRT_service_id for an entry of an emergency alert message, and NRT_service_id indicates that additional content related to an emergency alert message is transmitted through a non-real-time (NRT) broadcast service.
  • NRT non-real-time
  • a broadcast receiver capable of receiving an NRT broadcast service may display an additional emergency alert message with reference to an SMT, a Service Guide (SG), and / or a FLUTE (File Delivery over Unidirectional Transport) session signaled for the NRT service. Can be.
  • the number of repeated receptions of the mobile emergency alert table may vary depending on the importance of the emergency alert message.
  • the emergency alert message of highest importance may be repeated every MH frame.
  • the broadcast receiver identifies an IP address and a UDP port number of a corresponding service in the SMT with reference to MH_service_id of the GAT, parses the FLUTE data transmitted through the SMT, and provides an electronic service guide (ESG). It may display that the emergency alert content is included through.
  • the broadcast receiver refers to the EAS_NRT_service_id of the mobile emergency alert table, identifies an ip address and a UDP port number for transmitting a service including an emergency alert message transmitted to the NRT, and parses the FLUTE data transmitted through the emergency alert message. Can be displayed.
  • the mobile emergency alert table may include an emergency alert message. In this case, the emergency alert message may be directly parsed and displayed through a CAP parser.
  • FIG. 5 is a diagram illustrating syntax of a mobile emergency alert table according to an embodiment of the present invention.
  • the mobile emergency alert table of the present invention includes a table_id field, an EAT_MH_protocol_version field, an ensemble_id field, an automatic_tuning_channel_number field, an automatic_tuning_ts_id field, an automatic_tuning_ensemble_id field, an automatic_tuning_service_id field, an num_EAS_message_ field, an EAS_message_id field, a type_type_file_of_field_disp_file_of_field field It may include an EAS_message_length field, an EAS_message_bytes field, and / or an EAS_NRT_service_id field.
  • table_id field Identifies the type of current table.
  • the broadcast receiver may identify a table_id field of a specific value and identify that this table is a mobile emergency alert table.
  • the EAT_MH_protocol_version field identifies version information for these when the structure of the mobile emergency alert table is changed.
  • the ensemble_id field represents an ID of an ensemble associated with this table.
  • the automatic_tuning_channel_number field represents a physical RF channel number for automatic tuning. For example, when forced tuning is necessary to a channel number on which an emergency alert message is broadcasted, the above field may be referred to.
  • the automatic_tuning_ts_id field represents a transport stream ID for automatic tuning. For example, if a transport stream including an emergency alert message needs to be parsed, the stream can be identified through the above ID.
  • the automatic_tuning_ensemble_id field represents an ID of an ensemble for automatic tuning. For example, an ensemble including an emergency alert message may be identified through the above field.
  • the automatic_tuning_service_id field represents a target A / V service of automatic tuning. If automatic tuning is specified in the mobile emergency alert table, the emergency alert table may or may not include an alert message. If auto tuning is specified, the broadcast receiver will ignore the message and tune to the target channel number.
  • the num_EAS_messages field represents the number of emergency alert messages included in the mobile emergency alert table.
  • the EAS_message_id field identifies a unique ID for sending an emergency alert message. This field may be changed if a previous emergency alert message is updated or canceled. In another embodiment, this field may be extracted from the CAP message ID.
  • the type_of_responder field represents a broadcast target of an emergency alert message.
  • the type_of_disciplines field represents information on an emergency situation that is the subject of an emergency alert.
  • the EAS_IP_version_flag field indicates that the IP_address field includes an IPv4 address when set to '0', and indicates that the IP_address field is for IPv6 when set to '1'.
  • the EAS_message_transfer_type field represents a transmission type of an emergency alert message.
  • the EAS_message_encoding_type field represents an encoding plan of an emergency alert message.
  • the EAS_message_length field represents the compression length of the compressed emergency alert message including the emergency alert.
  • the EAS_message_bytes field represents the size of a compressed emergency alert message including an emergency alert.
  • the EAS_NRT_service_id field identifies a service ID of an NRT service that provides additional content associated with an emergency alert message. This field may also be inserted in the SMT included in the ensemble for transmitting the emergency alert table.
  • FIG. 6 is a diagram illustrating the meaning according to each value of a type_of_responder field, a type_of_disciplines field, an EAS_message_transfer_type field, and an EAS_message_encoding_type field according to an embodiment of the present invention.
  • the type_of_responder field indicates, depending on the value of this field, that the viewer of the emergency alert message has not been identified, that the viewer is not public, that the viewer is the public, or that the viewer is the public and the public. If not, it can be included.
  • the type_of_disciplines field indicates the status of an emergency alert system invocation, an explosion event, a fire situation, a hazardous material occurrence event, law enforcement, or life saving situation. Can be represented.
  • the EAS_message_transfer_type field indicates that, according to the value of this field, the transmission type of the emergency alert message is not identified, an NRT file containing no alert message is transmitted, or an emergency alert message is transmitted in a mobile emergency alert table. It may indicate that an emergency alert message is transmitted through an IP datagram.
  • the EAS_message_encoding_type field indicates that no encoding plan is identified, that no encoding (or compression) has been performed for an emergency alert message, or that an emergency alert message is compressed using the gzip algorithm. It may indicate that
  • FIG. 7 is a diagram illustrating syntax of an IP datagram when it is identified that an emergency alert message is transmitted through an IP datagram according to an embodiment of the present invention.
  • the IP datagram may include an EAS_message_id field, an EAS_message_length field, and / or an EAS_message_bytes field.
  • the EAS_message_id field corresponds to a value corresponding to an entry of an emergency alert message in the mobile emergency alert table.
  • the EAS_message_length field represents the length of each emergency alert message.
  • the EAS_message_bytes field represents the size of the compressed emergency alert message.
  • FIG. 8 is a diagram illustrating syntax of an FIC segment header according to an embodiment of the present invention.
  • the mobile broadcast receiver may operate in a standby mode and perform a response to an emergency alert message through a wake up function.
  • the mobile broadcast receiver capable of performing the wake up function may not monitor the broadcast service but may monitor the broadcast signal transmitted from the broadcaster even in the standby mode.
  • Wakeup refers to switching the broadcast receiver to the active mode (or the active mode) even when the broadcast receiver is in the sleeping mode (or the standby mode) for the emergency alert message.
  • the smallest unit for signaling in the mobile broadcast service is the FIC segment header included in the FIC segment, but in order to obtain the FIC segment, the broadcast receiver needs to receive at least one RS frame.
  • Changes in FIC chunks can be detected by monitoring the TPC. For example, when the value of the FIC_version field included in the TPC changes, it can be seen that there is a change in the FIC chunk.
  • the broadcast receiver detects a change in the FIC_version field in the TPC, the broadcast receiver receives an RS frame to turn on the broadcast receiver and collect FIC segments. If there is a wakeup signal in the FIC Chunk, a wakeup indicator in the FIC segment header may be used to determine if the mobile broadcast receiver should wake up.
  • the FIC Chunk is divided into a plurality of FIC segment payloads and transmitted.
  • the FIC segment includes an FIC segment header and an FIC segment payload.
  • the FIC segment is transmitted through one data group.
  • the FIC segment header includes a FIC_segment_type field, wake_up_indicator field, FIC_chunk_major_protocol_version field, current_next_indicator field, error_indicator field, FIC_segment_num field, and / or FIC_last_segment_num field.
  • the FIC_segment_type field indicates the type of data transmitted by the FIC segment.
  • the FIC_segment_type field may indicate that the FIC segment payload carries a portion of the FIC Chunk, or that the FIC segment payload does not contain meaningful data, depending on its value.
  • the wake_up_indicator field indicates whether a mobile broadcast receiver capable of performing a wake-up function should automatically turn on the power and provide an emergency alert message. For example, according to the value of the wake_up_indicator field, the mobile broadcast receiver may be controlled to ignore the wake-up process and continue to perform the previous function or to immediately perform the wake-up function.
  • the FIC_chunk_major_protocol_version field indicates a major protocol version of FIC Chunk partially transmitted through the FIC segment. This value may be set equal to the value of the FIC_chunk_major_protocol_version field included in the FIC Chunk header.
  • the current_next_indicator field represents the current or next state of the FIC chunk partially transmitted through the FIC segment.
  • the error_indicator field indicates whether an error is detected in the FIC segment.
  • the FIC_segment_num field indicates the number of an FIC segment.
  • the FIC segment including the FIC segment payload included in the FIC chunk may indicate the number of FIC segments.
  • the FIC_last_segment_num field indicates the number of the last FIC segment.
  • the FIC segment may indicate which FIC segment is the last FIC segment among the FIC segments including the FIC segment payload included in the FIC chunk.
  • FIG. 9 is a diagram illustrating syntax of an FIC chunk payload according to an embodiment of the present invention.
  • the mobile broadcast receiver capable of performing the wake up function will be monitoring the FIC_version field in the TPC. If a change in the FIC_version field is detected, the mobile broadcast receiver will begin collecting FIC segments. If the wake_up_indicator field of the FIC segment header indicates that the wake up function should be performed, the mobile broadcast receiver will receive an ensemble that includes the mobile emergency alert table in the service signaling channel. In this case, the ensemble may be identified by the EAT_ensemble_indicator field.
  • the FIC Chunk payload includes an ensemble_id field, an ensemble_protocol_version field, an SLT_ensemble_indicator field, a GAT_ensemble_indicator field, an EAT_ensemble_indicatoer field, an MH_service_signaling_channel_version field, a num_MH_services field, an MH_service_id_service_id_service_id_service_id_service_id field, and a multi-service field.
  • the ensemble_id field identifies an ensemble signaled by the corresponding FIC.
  • the ensemble_protocol_version field represents version information of the structure of an ensemble.
  • the SLT_ensemble_indicator field indicates whether a service signaling channel included in an ensemble includes a service labeling table.
  • the GAT_ensemble_indicator field indicates whether a service signaling channel included in an ensemble includes a guide access table.
  • the EAT_ensemble_indicatoer field indicates whether the service signaling channel included in the ensemble includes the mobile emergency alert table. Or EAT_ensemble_indicator indicates that the mobile emergency alert table is transmitted in the signaling stream of this ensemble.
  • the MH_service_signaling_channel_version field indicates the version of the service signaling channel included in the ensemble.
  • the num_MH_services field represents the number of MH services signaled through the ensemble.
  • the MH_service_id field identifies MH service.
  • the multi-ensemble_service field indicates whether an MH service is transmitted through one or more ensemble.
  • the MH_service_status field represents the status of an MH service.
  • the MH_service_status field indicates whether the MH service is activated and / or whether the MH service is 'hidden' according to the value of this field.
  • the SP_indicator field represents whether service protection has been applied to at least one or more components for providing an MH service.
  • FIG. 10 is a flowchart illustrating a data processing for performing a wake-up function according to an embodiment of the present invention.
  • the mobile broadcast receiver monitors the FIC segment header or the TPC. If there is no change in the FIC_version field, the mobile broadcast receiver continues the above monitoring. If there is a change in the FIC_version field, the mobile broadcast receiver checks the FIC segment header (10010). If the wake_up_indicator field in the FIC segment header indicates no wake-up function, the mobile broadcast receiver continues to monitor the FIC segment header or TPC, and if the wake_up_indicator field indicates to perform the wake-up function (10020), The FIC segments are collected to complete the FIC chunk (10030). The mobile broadcast receiver checks EAT_ensemble_indicator of the FIC Chunk payload (10040).
  • the mobile broadcast receiver starts parsing / decoding the ensemble (10060) if the EAT_ensemble_indicator points to an ensemble that transmits the mobile emergency alert table (10050), and starts an application if an application for providing an emergency alert message is needed. (10070).
  • the mobile broadcast receiver obtains a mobile emergency alert table from the ensemble (10080), and parses and displays an emergency alert message using the table (10090). When the above-described process is finished, the mobile broadcast receiver turns off the power (10100).
  • FIG. 11 is a diagram illustrating syntax of an FIC chunk header according to an embodiment of the present invention.
  • the broadcast receiver needs to ignore repeated transmissions for the same wakeup event.
  • FIC Chunk header may include a field FIC_chunk_major_protocol_version, FIC_chunk_minor_protocol_version field, FIC_chunk_header_extension_length field, ensemble_loop_header_extension_length field, MH_service_loop_extension_length field, current_next_indicator field, transport_stream_id field, EAS_wake_up_extended_info field, EAS_wake_up_extended_info_Tag field, EAS_wake_up_version_number field, and / or num_ensembles field.
  • the FIC_chunk_major_protocol_version field represents a major version of syntax of FIC Chunk.
  • a major level change represents a change in the syntax of the FIC Chunk in a range where backward compatibility is not maintained.
  • the FIC_chunk_minor_protocol_version field represents a minor version of the syntax of FIC Chunk.
  • a change in the minor level represents a change in syntax of the FIC Chunk in the range in which backward compatibility is maintained.
  • the FIC_chunk_minor_protocol_version field may indicate that a wakeup signaling extension for an emergency alert system exists in FIC Chunk.
  • the FIC_chunk_header_extension_length field indicates the length in fields extended in the FIC Chunk header due to a change in the minor level in the syntax of the FIC Chunk.
  • the FIC_chunk_header_extension_length field may indicate the length of a field extended by wakeup signaling extension.
  • the ensemble_loop_header_extension_length field represents the length of the extension field of the header of the num_ensemble loop in the FIC Chunk payload added by the change of the minor level of the syntax of the FIC Chunk.
  • the MH_service_loop_extension_length field represents the length of the extension field of the num_MH_services loop entry in the FIC Chunk payload added by the change of the minor level of the syntax of the FIC Chunk.
  • the current_next_indicator field indicates whether the FIC Chunk is applicable to the current MH frame or the next MH frame.
  • the transport_stream_id field serves as a label for identifying a mobile broadcast.
  • the EAS_wake_up_extended_info field includes information on an extended field for the wakeup function.
  • the EAS_wake_up_extended_info_Tag field indicates the type of the extended FIC Chunk header.
  • the EAS_wake_up_extended_info_Tag field may indicate the size of the extended field for the wakeup function.
  • the EAS_wake_up_version_number field represents version information of wakeup signaling.
  • the num_ensembles field indicates the number of ensembles transmitted through a physical transport channel with respect to the FIC Chunk.
  • FIG. 12 is a diagram illustrating a procedure for processing version information of wake-up signaling through extension of an FIC Chunk header according to an embodiment of the present invention.
  • the broadcast receiver checks the FIC segment header when the FIC_version field is changed while monitoring the FIC_version field included in the TPC.
  • the broadcast receiver indicates that the wake_up_indicatoer field will perform a wake-up function
  • the broadcast receiver receives the FIC Chunk and checks the FIC_chunk_minor_protocol_version field and / or the FIC_chunk_header_extension_length field in the FIC Chunk header.
  • the broadcast receiver parses the FIC_chunk_header_extension_length field if the FIC_chunk_minor_protocol_version field indicates a change in the FIC Chunk for wakeup signaling, and if the FIC_chunk_header_extension_length field indicates that there is an extension of the FIC Chunk header for wakeup signaling, the EAS_wake_up_extended_extended_ext_up Check the field.
  • the broadcast receiver checks the extended field through the EAS_wake_up_extended_info_Tag field and determines whether there is a change in the version of the wakeup signaling through the EAS_wake_up_version_number field.
  • the broadcast receiver checks the EAT_ensemble_indicator field in the FIC Chunk payload when the version of the wake-up signaling changes, and obtains the mobile emergency alert table from the ensemble transmitting the mobile emergency alert table.
  • the broadcast receiver processes the emergency alert system using the obtained mobile emergency alert table.
  • FIG. 13 is a diagram illustrating processing of automatic tuning of a wake-up operation to a critical emergency alert according to an embodiment of the present invention.
  • the broadcast receiver may provide automatic tuning as an important emergency alert as part of the wake-up operation.
  • the broadcast receiver checks the FIC segment header when the FIC_version field is changed while monitoring the FIC_version field included in the TPC.
  • the broadcast receiver receives the FIC Chunk and checks the version of the wakeup signaling when the wake_up_indicatoer field indicates to perform the wakeup function.
  • the fields included in the automatic_tuning_info field in the mobile emergency alert table indicate that automatic tuning to another channel is required Perform tuning at the frequency of. Acquire an ensemble at the frequency and execute the emergency alert system using the mobile emergency alert table included in the ensemble.
  • FDT FLUTE File Delivery Table
  • an FDT instance needs to be modified to allow zero files to be transmitted through a FLUTE session for transmitting an NRT file.
  • the element of the FLUTE FDT instance transmitted in the NRT broadcast service for emergency alert follows the content of OMA BCAST.
  • FIG. 15 is a diagram illustrating syntax of a TPC for wake-up signaling using a TPC according to another embodiment of the present invention.
  • wake_up_indicator and wake_up_version_number may be added to the TPC data.
  • the broadcast receiver may determine whether to perform a wake-up function for an emergency alert even by watching only the TPC data.
  • the wake-up function may be performed by adding wake_up_indicator and wake_up_version_number information to TPC data (Transmission Parameter Channel Data) described in ATSC A / 153 Part 2. Therefore, although some fields in the TPC are omitted in FIG. 15, this may refer to ATSC A / 153 Part 2.
  • TPC data Transmission Parameter Channel Data
  • FIG. 15 the fields of the field included in the TPC illustrated in FIG. 15 without further description may refer to the contents described in ATSC A / 153 Part 2.
  • the TPC data may include a wake_up_indicator field and / or a wake_up_version_number field.
  • the wake_up_indicator field allocates 1-bit using an existing reserved bit.
  • the wake_up_indicator field indicates whether a broadcast receiver should perform a wake up function. For example, if this value is '0', the broadcast receiver should perform a wake up function in the standby mode, and if it is '1', it maintains the existing state. That is, when the broadcast receiver is in the standby mode, the TPC may be continuously monitored, and when the A / V is reproduced, the A / V may be continuously reproduced.
  • the wake_up_version_number field represents version information of wakeup signaling.
  • the broadcast receiver may compare the value of the wake_up_version_number field with the value of the previously received wake_up_version_number field to change from a standby mode to an active mode to determine whether a new wakeup is received before receiving the FIC.
  • 16 is a diagram illustrating syntax of an FIC segment header according to another embodiment of the present invention.
  • the mobile broadcast receiver may correspond to two wakeups.
  • wakeup signaling corresponding to the same wake-up 1 may be continuously transmitted.
  • the broadcast receiver may determine whether the wake-up is delivered after the user forcibly terminates by using the 2-bit wake_up_indicator field. That is, when a strong disaster corresponding to a later wake-up 2 is issued and signaling of the wake-up 2 is transmitted, the broadcast receiver may be forcibly turned on again. Accordingly, a function of distinguishing a previously received wakeup from a newly received wakeup may be necessary by allocating 2 bits to the wake_up_indicator field.
  • FIG. 17 is a diagram illustrating an ESG content fragment according to another embodiment of the present invention.
  • the emergency alert system may use one same NRT service for all emergency alert messages without using different NRT services for each emergency alert message.
  • the content fragment of the ESG may include a new element to find out which message each NRT content is associated with.
  • the ESG content fragment may include an EAS_Content_message_ID field and / or an EAS_Content_message_TAG field.
  • the EAS_Content_message_ID field may have a value equal to the ID of the emergency alert message specified in the mobile emergency alert table.
  • the EAS_Content_message_TAG field is a value that can be used when showing an NRT list. For example, if the emergency alert message is for 'Typhoon', the TAG may have a value of "Typhoon Alert". The value of this TAG is assigned to the ESG server installed in the local station.
  • FIG. 18 is a diagram illustrating an emergency alert system according to an embodiment of the present invention.
  • the Public Broadcasting Service obtains an emergency alert message through the Secure Line from the Integrated Public Alert and Warning System (IPAWS) -OPEN and sends the message to the local PBS station through the satellite network.
  • the emergency alert message delivered to the local PBS station is made from the Mobile Digital Television (MDTV) signaling server into a mobile emergency alert table, which is sent to the MDTV network through the multiplexer and the exciter.
  • MDTV Mobile Digital Television
  • the MDTV receiver parses the mobile emergency alert cable using a signaling decoder, parses the emergency alert message existing inside the mobile emergency alert table, and extracts the text of the emergency alert message to be displayed on the screen.
  • the flow of additional information on the emergency alert message through the NRT may proceed as follows.
  • the local PBS station creates additional information files related to the disaster and stores them in the NRT file repository used by the MDTV NRT server.
  • the MDTV NRT server forms signaling information related to the files stored in the NRT file repository. Will be sent in non-real-time. This is also transmitted through MDTV network using multiplexer and exciter, and the broadcast receiver finds out the information about the files transmitted to NRT by using FLUTE / ESG function and receives the file. Can show on
  • an NRT file is not generated at each local PBS station, but a URI information indicating additional information is included in the CAP message when an emergency alert message is issued from IPAWS-OPEN.
  • a ⁇ uri> element that is a sub element of the ⁇ resource> element of the CAP may be used.
  • the MDTV signaling server extracts the URI information of the CAP message to get a resource file, which is transmitted through the MDTV network through the NRT.
  • the emergency alert message recipients of the mobile emergency alert system can be divided into public and non-public.
  • Non-public users are defined as First Responders.
  • First Responder refers to those who have the capacity to handle each disaster. For example, in the event of a fire, 911 would be the first responder.
  • the mobile emergency alert table defines the type of receiver / receiver to which an emergency alert message should be delivered. It also defines what discipline should be delivered if the receiver is a first responder. Information on this replaces the above description.
  • 19 is a diagram illustrating a scene for providing additional information of an emergency alert message using an NRT according to an embodiment of the present invention.
  • the broadcast receiver may display additional information related to the disaster by using files transmitted in non-real-time.
  • the mobile emergency alert system it is possible to send several emergency alert messages at the same time.
  • each emergency alert message may have different NRT side information.
  • all information related to NRT can be included in ESG. Therefore, all MDTV receivers must have ESG functionality, and additional information can be shown to the user after updating the ESG. After updating the ESG, the MDTV receiver reads the name of each NRT service from the ESG's Service Fragment and displays it on the screen. Referring to FIG.
  • FIG. 20 is a diagram illustrating a scene for providing additional information of an emergency alert message using an NRT according to another embodiment of the present invention.
  • the receiver may display a list of contents associated with the service on the screen.
  • Information related to the content may be included in the ESG and transmitted.
  • the NRT content information is recorded in the content fragment of the ESG, and the receiver searches for content items referring to the service selected by the user, and forms a list of information such as the name of the content and / or expiration date on the screen Can be.
  • Each NRT file providing additional information of the emergency alert message is transmitted to the broadcast receiver via FLUTE and stored in a storage inside the broadcast receiver. If the user wants to view the additional information, the broadcast receiver reads the file and displays the additional information.
  • 21 is a diagram illustrating a UI of a mobile emergency alert system according to an embodiment of the present invention.
  • the mobile broadcast receiver receives relevant signaling information, completes the extraction of the emergency alert message, and displays the emergency alert message.
  • the mobile broadcast receiver may create and display a menu under the name of EAS in order to show additional information of the emergency alert message.
  • NRT service list related to emergency alert is displayed.
  • mobile broadcasting receiver displays related contents list by name, expiration date, and / Alternatively, the information may be displayed on the screen by configuring information such as a reception state of a file. Referring to FIG. 21, when a user selects an evacuation map from a content list, the corresponding map is displayed on the screen.
  • FIG. 22 is a diagram illustrating syntax of a mobile emergency alert table according to another embodiment of the present invention.
  • FIG. 22 is a diagram illustrating syntax of a mobile emergency alert table according to another embodiment of the present invention.
  • the mobile emergency alert table includes an event_code field, an event_urgency field, an event_severity field, an event_certainty field, an EAS_message_type field, a num_referenced_messages field, a referenced_message_id field, an event_expiry_time field, a num_geo_code field, a geo_code field, an alert_text_length field, and / or Alternatively, it may include an alert_text () descriptor.
  • the event_code field represents a code for an event associated with an emergency alert message.
  • the event_urgency field represents the urgency of the response to the event associated with the emergency alert message.
  • the event_severity field represents the severity of the event associated with the emergency alert message.
  • the event_certainty field represents the degree of certainty of the event associated with the emergency alert message.
  • the EAS_message_type field represents the type of emergency alert message.
  • the num_referenced_messages field represents the number of messages referenced by the current emergency alert message among emergency alert messages that have already been transmitted.
  • the referenced_message_id field represents the ID of the emergency alert message referenced by the current emergency alert message.
  • the event_expiry_time field represents a time when information included in an emergency alert message is valid.
  • the num_geo_code field represents the number of codes indicating an area to which an emergency alert message affects.
  • the geo_code field represents a code indicating the area where the emergency alert message affects.
  • the alert_text_length field represents the length of text of an emergency alert.
  • alert_text () field indicates the text of the emergency alert.
  • alert_text () may be defined in the form of a descriptor, and in this case, may be defined as a descriptor including additional information regarding the text of the emergency alert.
  • the emergency alert message can be used even in a mobile broadcast receiver in which the parser of the emergency alert message file does not exist. It works.
  • FIG. 23 is a diagram illustrating definitions of values of an event_urgency field, an event_severity field, an event_certainty field, and an EAS_message_type field according to another embodiment of the present invention.
  • FIG. 23 is a diagram illustrating definitions of values of an event_urgency field, an event_severity field, an event_certainty field, and an EAS_message_type field according to another embodiment of the present invention.
  • the event_urgency field indicates that an emergency alert is about a past event, an emergency alert is about a future event, an event about which an emergency alert is expected, or an emergency alert. May indicate that the event is currently occurring, or that the urgency for the event indicated by the emergency alert is unknown.
  • the event_severity field indicates that the severity of the emergency alert event is low, the severity of the emergency alert event is medium, or the severity of the emergency alert event, depending on the value of this field. Alternatively, it may indicate that the severity of the event of the emergency alert is of extreme severity, or that the severity of the event of the emergency alert is unknown.
  • the event_certainty field indicates that, depending on the value of this field, it is unlikely that an event related to an emergency alert will occur, that an event related to an emergency alert is likely to occur, or that an event related to an emergency alert may occur. It may indicate that it is high, that an event related to an emergency alert is currently being observed, or that there is no known information about the likelihood that an event related to an emergency alert will occur.
  • EAS_message_type field Depending on the value of this field, it indicates that the transmitted emergency alert message is an emergency alert message for a new event or updates a message having a specific referenced_message_id value among the messages in which the transmitted emergency alert message was previously transmitted. Indicates that the message is an emergency alert message sent, that an emergency alert message that cancels a message with a specific referenced_message_id value, that the transmitted emergency alert message is a response message to a specific request, or It may indicate that there is an error or that the type of the emergency alert message transmitted is not identified.
  • FIG. 24 is a diagram illustrating a mobile emergency alert table according to another embodiment of the present invention.
  • Emergency alert messages should be able to be delivered precisely to the areas where events related to emergency alerts are affected. Therefore, the broadcast receiver needs to review the suitability of the message before parsing the transmitted emergency alert message.
  • the mobile emergency alert table may include a num_FIPS_codes field, a FIPS_codes field, an EAS_event_code field, a content_coding field, a content_type field, and / or an NRT_service_id field.
  • the num_FIPS_codes field represents the number of FIPS codes indicating the regions where emergency alert messages affect.
  • the FIPS_codes field represents a code indicating the area where the emergency alert message affects. The value of this field may be expressed in FIPS code.
  • the EAS_event_code field represents a code for an event associated with an emergency alert message. This field can be represented as 3 letters encoded in UTF-8.
  • the content_coding field represents an encoding scheme of an emergency alert message.
  • the content_coding field may indicate that the emergency alert message is plain text or may indicate that the emergency alert message is compressed in gzip according to the value of this field.
  • the content_type field represents the type of emergency alert message.
  • the content_type field may indicate that it is an emergency alert message used by the CMAS according to a value of this field, or may indicate that it is an emergency alert message that follows the criteria of the CAP.
  • the NRT_service_id field identifies an NRT service including additional information about an emergency alert message or an emergency alert message.
  • the broadcast receiver may examine whether the message is a message suitable for the region where the broadcast receiver is located, so that only the necessary emergency alert message is delivered to the viewer. have.
  • the emergency alert message is not suitable for the region, there is an effect of reducing unnecessary processing procedures in the broadcast receiver.
  • 25 is a diagram illustrating a mobile emergency alert table according to another embodiment of the present invention.
  • the mobile emergency alert table may include an NRT_service_IP_address_flag field, and / or an SG_bootstrap_data () field / descriptor.
  • the NRT_service_IP_address_flag field indicates whether there is IP information associated with an NRT service that transmits additional content for an emergency alert message.
  • the SG_bootstrap_data () field may define a syntax including IP information for acquiring the NRT service when the NRT_service_IP_address_flag field indicates that there is IP information associated with an NRT service that transmits additional content for an emergency alert message.
  • SG_bootstrap_data () may be defined in the form of a descriptor and include a syntax including IP information for obtaining an NRT service. It may include syntax when SG_delivery_network_type defined in Part 3 of ATSC A / 153 is '0x02'.
  • NRT service that provides additional information on an emergency alert message without using SMT.
  • FIG. 26 is a diagram illustrating a descriptor for signaling an emergency alert service through extension of an SMT according to an embodiment of the present invention.
  • Disaster alert service can be sent to individual service like A / V service in one ensemble. In this case, it is necessary to perform signaling for the disaster alert service in the SMT.
  • the descriptor for signaling an emergency alert service may include a descriptor_tag field, a descriptor_length field, a priority_level field, an EAS_message_sent_type field, an IP_address field, a UDP_port_num field, and / or a service_related_nrt_service_id field.
  • the descriptor_tag field represents that the descriptor is a descriptor for a disaster alert service.
  • the descriptor_length field represents the total length of the descriptor after this field.
  • the priority_level field represents an important level of emergency alert message.
  • the priority_level field depending on the value of this field, indicates that an emergency alert message should be processed first, that an emergency alert message should be processed according to a normal processing procedure, or It may indicate that it is not defined.
  • the EAS_message_sent_type field represents a transmission type of an emergency alert message.
  • the EAS_message_sent_type field indicates that an emergency alert message is sent through a separate table, i.e., a mobile emergency alert table, that a method of sending an emergency alert message is not defined, or an emergency alert. It may indicate that a message is transmitted through an IP datagram.
  • the IP_address field indicates an IP address of an IP datagram including an emergency alert message when the EAS_message_sent_type field indicates that an emergency alert message is transmitted through an IP datagram.
  • the UDP_port_num field indicates a port number of a UDP / IP stream for transmitting an IP datagram including an emergency alert message when the EAS_message_sent_type field indicates that an emergency alert message is transmitted through an IP datagram.
  • the service_related_nrt_service_id field represents an ID of an NRT service that transmits content associated with a transmitted emergency alert message.
  • the descriptor according to the embodiment of the present invention may be included in the extended area for the descriptor included in the SMT.
  • SMT can be described with reference to the form described in ATSC A / 153.
  • FIG. 27 illustrates a descriptor for signaling an emergency alert service according to another embodiment of the present invention.
  • Descriptors for signaling for the emergency alert service may be defined at the ensemble level.
  • the descriptor for signaling for an emergency alert service may include an IP_version_flag field and / or an ensemble_related_nrt_service_id field.
  • the description of other fields included in this descriptor is replaced with the description of the fields of the above-described descriptor.
  • the IP_version_flag field indicates the IP address format of the IP datagram including the emergency alert message when the 'EAS_message_sent_type field indicates that an emergency alert message is transmitted through the IP datagram.
  • the IP_version_flag field may indicate that an IP address format of an IP datagram uses an IPv4 format or an IPv6 address format according to a value of this field.
  • the ensemble_related_nrt_service_id field represents an ID of an NRT service for transmitting content associated with an emergency alert message to be transmitted.
  • 28 is a diagram illustrating signaling for providing an emergency alert service to one component according to an embodiment of the present invention.
  • a new M / H component descriptor may be defined by adding a definition of a new component_type and extracting only a field that is actually used among FLUTE component data.
  • the component_type field may indicate that an M / H component is a component for an emergency alert service according to its value.
  • the TSI field of the MH_component_data () descriptor may be defined, where the TSI field represents an identifier of a transport session of a FLUTE session for transmitting NRT content.
  • FIG. 29 is a diagram illustrating an emergency_alert_IP_datagram () descriptor for emergency alert service transmission according to an embodiment of the present invention.
  • the IP_header field represents an IP header of an IP datagram.
  • the UDP_header field represents a UDP header of an IP datagram.
  • the payload_type_indicator field represents a payload type of an IP datagram for transmitting an emergency alert message.
  • the payload_type_indicator field indicates that, depending on the value of this field, the payload of the IP datagram contains a separate syntax that contains the information of the emergency alert message, or the payload of the IP datagram contains the emergency alert message file itself. In this case, the payload type of the IP datagram may not be defined.
  • the payload of the IP datagram when the payload_type_indicator field indicates that the payload of the IP datagram includes a separate syntax including information of the emergency alert message, the payload of the IP datagram is the aforementioned mobile emergency alert tables. It may include any type of table.
  • FIG. 30 is a diagram illustrating an emergency_alert_IP_datagram () descriptor for emergency alert service transmission according to another embodiment of the present invention.
  • the payload of the IP datagram may include text or / and compressed emergency alert message file (s).
  • the payload contains a series of message_header and message_body sets.
  • the message_header may include detailed information (message_body_length, message_gzipped_flag, etc.) about the message_body as shown in FIG. 30.
  • the emergency_alert_IP_datagram () descriptor may include a message_body_length field and / or a message_gzipped_flag field.
  • the message_body_length field represents the length of the message_body. The length of message_body cannot exceed the total length of the IP datagram.
  • the message_gzipped_flag field represents whether a compressed emergency alert message is included in the message_body.
  • the message_gzipped_flag field may indicate that an emergency alert message included in the payload is compressed by gzip according to a value of this field.
  • FIG. 31 is a view showing a content fragment of an ESG for emergency alert service according to another embodiment of the present invention.
  • the content related to the emergency alert message may be transmitted through the NRT service.
  • the content transmitted through the NRT service may deliver detailed information through a content fragment of the ESG.
  • the content fragment of the ESG may include an emergency element and / or a weight element.
  • the emergency element indicates whether the corresponding content is content related to an emergency alert situation.
  • the value of the emergency element may be set to true to indicate that the content is content associated with an emergency alert situation.
  • the weight element determines the display order of contents belonging to the same service. For example, as the value of the corresponding element is lower, the corresponding content may be preferentially displayed on the screen. Therefore, in order to preferentially display content on the screen, the value of the weight element should be set low. In the case of content that is to be forcibly displayed on the receiver screen, the value of this element may be set to zero.
  • the broadcast receiver may perform fast processing on content associated with an emergency alert message by using a content fragment of the ESG.
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the image processing method of the present invention can be implemented as a processor-readable code on a processor-readable recording medium provided in the network device.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor. Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet. .
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention can use mobile broadcasting throughout the industry.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Emergency Management (AREA)
  • Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
본 발명은 모바일 방송 시스템에 관한 것이다. 보다 상세하게는, 모바일 방송 시스템을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법에 관한 것이다.
휴대기기의 발전에 따라, 모바일 기기에서도 방송의 송/수신이 가능하게 되었다. 따라서, 모바일 방송 환경에 적합한 방송 신호 송신 시스템이 구축되고 있다. 아울러, 전세계적으로 인위적 혹은 자연적인 재난이 발생하고 있다. 이러한 재난에 대하여는 신속한 재난 정보의 제공이 필요하다. 모바일 방송의 경우, 사용자가 방송을 수신하는 위치가 가변적일 수 있고, 재난은 위치와 연관성이 크므로, 모바일 방송을 통하여 재난에 대한 정보를 제공하는 것이 효과적이다. 그러나, 현재 모바일 방송 시스템에서 재난에 대한 정보를 제공하는 기술은 개발되어 있지 않은 상황이다.
본 발명이 이루고자 하는 과제는, 전술한 문제점을 해결하기 위한 것으로, 모바일 방송 시스템에서 긴급 경보 서비스를 제공하는 것이다.
본 발명의 일 실시예에 따른, 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법은 앙상블을 RS (Reed-Solomon) - CRC (Cyclic Redundancy Check) 인코딩하여 2차원의 데이터 프레임인 RS 프레임을 생성하는 단계, 여기서 상기 앙상블은 모바일 방송 서비스를 위한 모바일 데이터, 및 상기 모바일 방송 서비스에 대한 어세스 (access) 정보를 포함하는 서비스 시그널링 채널을 포함하는 것을 특징으로 하고, 상기 생성된 RS 프레임을 복수의 RS 프레임 포션으로 분할하는 단계, 모바일 방송의 전송 파라미터를 시그널링하기 위한 TPC (Transmission Parameter Channel), 및 상기 앙상블과 상기 방송 서비스 사이의 연결 정보를 포함하는 FIC (Fast Information Channel) 를 포함하는 시그널링 데이터를 생성하는 단계, 상기 시그널링 데이터의 일부 및 상기 RS 프레임 포션을 포함하는 데이터 그룹을 생성하는 단계, 및 상기 데이터 그룹을 포함하는 모바일 방송 신호를 생생하는 단계를 포함하며, 상기 서비스 시그널링 채널은, 상기 앙상블에 의하여 전송되는 모바일 서비스에 대한 속성 정보를 포함하는 서비스 맵 테이블 (Service Map Table) 및 긴급 경보 서비스를 모바일 방송으로 전송하기 위한 정보를 포함하는 모바일 긴급 경보 테이블을 포함하며, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지가 전송되는 방식을 가리키는 긴급 경보 메시지 전송 타입 필드를 포함하는 것을 특징으로 한다.
바람직하게는, 상기 긴급 경보 메시지 전송 타입 필드는, 상기 긴급 경보 메시지가 상기 모바일 긴급 경보 테이블 내에 포함되어져 전송되거나, 상기 긴급 경보 메시지가 IP 데이터그램을 통하여 전송되는 것을 가리키는 것을 특징으로 한다.
바람직하게는, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 서비스를 제공하는 물리적 RF 채널로 자동 튜닝을 하기 위한 물리적 RF 채널 번호를 가리키는 자동 튜닝 채널 번호 필드를 더 포함하는 것을 특징으로 한다.
바람직하게는, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지의 수신 대상자를 나타내는 긴급 경보 대상자 타입 필드를 더 포함하는 것을 특징으로 한다.
바람직하게는, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보의 대상이 되는 긴급 상황을 식별하는 긴급 상황 타입 필드를 더 포함하는 것을 특징으로 한다.
바람직하게는, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지와 관련한 부가 정보를 제공하는 NRT 서비스를 식별하는 NRT 서비스 식별자 필드를 더 포함하는 것을 특징으로 한다.
바람직하게는, 상기 FIC는, 복수의 FIC 세그먼트 형태로 상기 데이터 그룹에 포함되어 전송되며, 상기 FIC 세그먼트는 FIC 세그먼트 헤더와 FIC 세그먼트 페이로드를 포함하며, 상기 FIC 세그먼트 헤더는, 웨이크업 기능을 수행 가능한 모바일 방송 수신기가 자동으로 전원을 ON 하고, 긴급 경보 메시지를 제공하여야 하는지를 가리키는 웨이크업 지시자 필드를 포함하는 것을 특징으로 한다.
바람직하게는, 상기 FIC는, FIC 헤더 및 FIC 페이로드를 포함하고, 상기 FIC 페이로드는, 상기 앙상블 내에 포함되는 서비스 시그널링 채널을 통하여 상기 모바일 긴급 경보 테이블이 전송되는지 여부를 나타내는 EAT_ensemble_indicator 필드, 상기 앙상블에 포함되는 서비스 시그널링 채널의 버전 정보를 나타내는 MH_service_signaling_channel_version 필드, 및 상기 앙상블을 통하여 전송되는 모바일 서비스의 개수를 나타내는 num_MH_services 필드를 포함하는 것을 특징으로 한다.
바람직하게는, 상기 FIC 헤더는, 확장된 FIC 헤더의 바이트가 웨이크업 기능을 위한 정보를 포함하는지 식별하는 EAS_wake_up_extended_info_Tag 필드 및 상기 웨이크업의 시그널링의 버전 정보를 나타내는 EAS_wake_up_version_number 필드를 포함하는 것을 특징으로 한다.
본 발명의 일 실시예에 따른, 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치는 앙상블을 RS (Reed-Solomon) - CRC (Cyclic Redundancy Check) 인코딩하여 2차원의 데이터 프레임인 RS 프레임을 생성하는 RS 프레임 인코더, 여기서 상기 앙상블은 모바일 방송 서비스를 위한 모바일 데이터, 및 상기 모바일 방송 서비스에 대한 어세스 (access) 정보를 포함하는 서비스 시그널링 채널을 포함하는 것을 특징으로 하고, 상기 생성된 RS 프레임을 복수의 RS 프레임 포션으로 분할하는 RS 프레임 디바이더, 모바일 방송의 전송 파라미터를 시그널링하기 위한 TPC (Transmission Parameter Channel), 및 상기 앙상블과 상기 방송 서비스 사이의 연결 정보를 포함하는 FIC (Fast Information Channel) 를 포함하는 시그널링 데이터를 생성하는 시그널링 인코더, 상기 시그널링 데이터의 일부 및 상기 RS 프레임 포션을 포함하는 데이터 그룹을 생성하는 데이터 그룹 포맷터, 및 상기 데이터 그룹을 포함하는 모바일 방송 신호를 생생하는 방송 신호 생성부를 포함하며, 상기 서비스 시그널링 채널은, 상기 앙상블에 의하여 전송되는 모바일 서비스에 대한 속성 정보를 포함하는 서비스 맵 테이블 (Service Map Table) 및 긴급 경보 서비스를 모바일 방송으로 전송하기 위한 정보를 포함하는 모바일 긴급 경보 테이블을 포함하며, 상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지가 전송되는 방식을 가리키는 긴급 경보 메시지 전송 타입 필드를 포함하는 것을 특징으로 한다.
본 발명에 따르면, 모바일 방송 환경에서도 긴급 경보 서비스를 제공할 수 있는 효과가 있다.
도 1은 본 발명의 일 실시예에 따른, 전송 시스템을 나타낸 도면이다.
도 2는 본 발명의 일 실시예에 따른, 시그널링 인코더를 나타낸 도면이다.
도 3은 본 발명의 일 실시예에 따른, 앙상블의 구조를 나타낸 도면이다.
도 4는 본 발명의 일 실시예에 따른, 모바일 긴급 경보 테이블을 이용한 긴급 경보 데이터 처리를 나타낸 도면이다.
도 5는 본 발명의 일 실시예에 따른, 모바일 긴급 경보 테이블의 신택스를 나타낸 도면이다.
도 6은 본 발명의 일 실시예에 따른, type_of_responder 필드, type_of_disciplines 필드, EAS_message_transfer_type 필드, EAS_message_encoding_type 필드의 각 값에 따른 의미를 나타낸 도면이다.
도 7은 본 발명의 일 실시예에 따른, 긴급 경보 메시지가 IP 데이터 그램을 통해 전송되는 것이 식별되는 경우, IP 데이터 그램의 신택스를 나타낸 도면이다.
도 8은 본 발명의 일 실시예에 따른, FIC 세그먼트 헤더의 신택스를 나타낸 도면이다.
도 9는 본 발명의 일 실시예에 따른, FIC Chunk 페이로드의 신택스를 나타낸 도면이다.
도 10은 본 발명의 일 실시예에 따른, 웨이크업 기능 수행을 위한 데이터 처리 흐름도 있다.
도 11은 본 발명의 일 실시예에 따른, FIC Chunk 헤더의 신택스를 나타낸 도면이다.
도 12는 본 발명의 일 실시예에 따른, FIC Chunk 헤더의 확장을 통한 웨이크업 시그널링의 버전 정보를 처리하는 절차를 나타낸 도면이다.
도 13은 본 발명의 일 실시예에 따른, 웨이크업 동작의 중요 긴급 경보로의 자동 튜닝을 처리하는 것을 나타낸 도면이다.
도 14는 본 발명의 일 실시예에 따른, FLUTE FDT (File Delivery Table) 인스턴스 (instance)를 나타낸 도면이다.
도 15는 본 발명의 다른 실시예에 따른, TPC를 이용한 웨이크업 시그널링을 위한 TPC의 신택스를 나타낸 도면이다.
도 16은 본 발명의 다른 실시예에 따른, FIC 세그먼트 헤더의 신택스를 나타낸 도면이다.
도 17은 본 발명의 다른 실시예에 따른, ESG 컨텐츠 프래그먼트 (Fragment)를 나타낸 도면이다.
도 18은 본 발명의 일 실시예에 따른, 긴급 경보 시스템을 나타낸 도면이다.
도 19는 본 발명의 일 실시예에 따른, NRT를 이용한 긴급 경보 메시지의 부가 정보를 제공하는 장면을 나타낸 도면이다.
도 20은 본 발명의 다른 실시예에 따른, NRT를 이용한 긴급 경보 메시지의 부가 정보를 제공하는 장면을 나타낸 도면이다.
도 21은 본 발명의 일 실시예에 따른, 모바일 긴급 경보 시스템의 UI를 나타낸 도면이다.
도 22는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블의 신택스를 나타낸 도면이다.
도 23은 본 발명의 다른 실시예에 따른, event_urgency 필드, event_severity 필드, event_certainty 필드, 및 EAS_message_type 필드가 가질 수 있는 값에 대한 정의를 나타낸 도면이다.
도 24는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블을 나타낸 도면이다.
도 25는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블을 나타낸 도면이다.
도 26은 본 발명의 일 실시예에 따른, SMT의 확장을 통하여, 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터를 나타낸 도면이다.
도 27은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터를 나타낸 도면이다.
도 28은 본 발명의 일 실시예에 따른, 하나의 컴포넌트로 긴급 경보 서비스를 제공하기 위한 시그널링을 나타낸 도면이다.
도 29는 본 발명의 일 실시예에 따른, 긴급 경보 서비스 전송을 위한 emergency_alert_IP_datagram () 디스크립터를 나타낸 도면이다.
도 30은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스 전송을 위한 emergency_alert_IP_datagram () 디스크립터를 나타낸 도면이다.
도 31은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스를 위한 ESG의 콘텐츠 프래그먼트를 나타낸 도면이다.
이하 첨부 도면들 및 첨부 도면들에 기재된 내용들을 참조하여 본 발명의 실시예를 상세하게 설명하지만, 본 발명이 실시예들에 의해 제한되거나 한정되는 것은 아니다.
본 명세서에서 사용되는 용어는 본 발명에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어를 선택하였으나, 이는 당분야에 종사하는 기술자의 의도 또는 관례 또는 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 발명의 설명 부분에서 그 의미를 기재할 것이다. 따라서 본 명세서에서 사용되는 용어는, 단순한 용어의 명칭이 아닌 그 용어가 가지는 실질적인 의미와 본 명세서의 전반에 걸친 내용을 토대로 해석되어야 함을 밝혀두고자 한다.
본 발명의 대한 이해와 설명의 편의를 위하여, 용어 및 약어에 대하여 아래와 같이 정의한다.
발명에 상세한 설명에서 사용되는 용어 중, 메인 서비스 데이터 (main service data) 는 고정 방송 수신 시스템 (fixed broadcast receiving system)에 의하여 수신되는 데이터에 해당하고, 오디오/비디오 데이터를 포함할 수 있다. 보다 상세히는, 메인 서비스 데이터는 고화질 (HD; High Definition) 또는 일반화질 (SD; Standard Definition) 오디오/비디오 데이터를 포함할 수 있고, 방송을 위한 다양한 종류의 데이터를 포함할 수 있다.
기지 데이터 (known data)는 방송 수신 시스템과 방송 송신 시스템 사이에 약속에 따라 미리 알려진 데이터에 해당된다.
“MH” 라는 용어는, mobile/handheld에 해당되는 용어로, 고정 타입 시스템에 반대되는 용어이다. 보다 상세히는, MH 서비스 데이터 (또는 모바일 서비스 데이터)는 모바일 또는 포터블 시스템에서 사용되는 어떠한 종류의 데이터를 포함할 수 있다. 따라서, 본 발명의 일실시예에 따른 모바일 서비스 데이터는 MH 서비스 데이터에 한정되지 않는다.
모바일 서비스 데이터는 프로그램 실행 파일, 또는 주식 정보와 같은 정보를 포함할 수 있다. 모바일 서비스 데이터는 오디오/비디오 데이터를 포함할 수 있다. 보다 상세히는, 모바일 서비스 데이터는 메인 서비스 데이터와 비교할 때 보다 낮은 해상도 (resolution)과 낮은 데이터 레이트 (rate)를 가지는 오디오/비디오 데이터에 해당될 수 있다. 예를 들어, MPEG-2 코덱이 메인 서비스를 위한 오디오/비디오 코덱으로 사용된다면, 모바일 서비스를 위하여 MPEG-2 코덱, MPEG-4 어드밴스 비디오 코딩 (AVC: advanced video coding), 또는 스캐일러블 비디오 코딩 (SVC: scalable video coding)과 같은 보다 이미지 압축률이 높은 오디오/비디오 코덱이 사용될 수 있다.
모바일 서비스 데이터는 실시간 교통 방송을 위한 TPEG 데이터 (transport protocol expert group data)를 포함할 수 있다. 또는 모바일 서비스 데이터는 기상 정보 서비스, 교통 정보 서비스, 주식 정보 서비스, 시청자 참여 퀴즈 프로그램, 실시간 투표, 양방향 교육 방송 프로그램, 게임 서비스, 또는 음악 프로그램과 같은 방송 서비스/프로그램을 포함할 수 있다.
본 발명에서 데이터 그룹 (또는 MH 그룹)은 데이터 슬롯 (또는 MH 슬롯)을 통하여 전송되는 데이터 패킷의 집합을 의미한다.
데이터 그룹 디비젼은 하나의 슬롯 내에서 데이터 그룹 영역의 세트를 나타낸다. 여기서, 데이터 그룹 디비젼은 프라이머리 데이터 그룹 디비젼 또는 세컨더리 데이터 그룹 디비젼을 구분될 수 있다. MH 프레임 (MH frame)내의 프라이머리 데이터 그룹 디비젼의 집합은 프라이머리 퍼레이드 (parade)를 형성하고, 세컨더리 데이터 그룹 디비젼은 세컨더리 퍼레이드를 형성한다.
퍼레이드 (또는 MH 퍼레이드)는 동일한 FEC 파라미터를 가지는 데이터 그룹의 집합을 나타낸다. 또는, 퍼레이드는 동일한 데이터 그룹 타입을 가지는 데이터 그룹의 데이터 그룹 디비젼의 집합을 나타낼 수 있다.
RS 프레임 (Reed-Solomon Frame)은 2차원의 데이터 프레임이다. 여기서 RS 프레임의 페이로드는 RS-CRC (Reed Solomon - Cyclic Redundancy Check) 코딩으로 인코딩 된다.
앙상블 (MH 앙상블)은 동일한 FEC (순방향 에러 정정; Forward Error Correction) 코드가 적용된 RS 프레임의 집합을 나타낸다. 여기서 각각의 RS 프레임은 IP 스트림의 집합을 압축하여 포함하고 있다. 앙상블에는 모바일 서비스를 위한 모바일 서비스 데이터 및 모바일 서비스의 시그널링을 위한 모바일 서비스 시그널링 채널을 포함할 수 있다.
본 발명의 일실시예에 따르면, 모바일 서비스를 위한 모바일 서비스 데이터는 메인 서비스를 메인 서비스 데이터의 전송을 위한 전송 채널의 일부를 통하여 전송될 수 있다. 또는 모바일 서비스를 위한 모바일 서비스 데이터는 메인 서비스를 위하여 사용되던 전송 채널 전체를 통하여 전송될 수 있다. 여기서, 모바일 서비스를 위하여 필요한 데이터를 모바일 서비스 데이터로 칭할 수 있다. 따라서, 모바일 서비스 데이터는 기지 데이터, 시그널링 데이터, 또는/및 RS 패리티 데이터를 포함할 수 있다.
모바일 서비스 데이터는 CMM (Core Mobile Mode)의 모바일 서비스 데이터와 SFCMM (Scalable Full Channel Mobile Mode)의 모바일 서비스 데이터로 구분될 수 있다.
CMM은 메인 서비스 데이터와 모바일 서비스 데이터를 함께 전송하는 방송 모드이다. 일 예로, CMM은 각각의 슬롯 내의 156개의 패킷 중, 적어도 38개 패킷을 기존 방송을 위한 메인 서비스 데이터의 전송에 사용할 수 있다.
SFCMM은 모바일 서비스 데이터만을 전송하거나, CMM 보다 적은 양의 메인 서비스 데이터를 모바일 서비스 데이터와 함께 전송하는 방송 모드이다. 예를 들어, SFCMM은 각각의 슬롯 내의 156개의 패킷 중, 38개 보다 적은 패킷을 메인 서비스 데이터의 전송을 위하여 사용할 수 있다.
SFCMM 퍼레이드는 기존의 CMM 시스템/디코더와 역호환성은 유지되나, 기존의 CMM 시스템/디코더에 의하여 인식될 수 없는 퍼레이드를 나타낸다.
데이터 그룹 영역은 데이터 블록 또는 확장 데이터 블록의 집합을 나타낸다. 데이터 그룹 영역은 데이터 그룹 내의 일정한 영역을 나타낸다. 각각의 데이터 그룹 영역은 각각 다른 용도의 모바일 서비스 데이터를 포함할 수 있다.
TPC (Transmission Parameter Channel)은 각각의 데이터 그룹에 포함될 수 있으며, 데이터 프레임 또는 데이터 그룹에 관한 정보를 수신 측에 전달하고, 전송 파라미터를 제공한다.
FIC (Fast information channel)는 크로스 레이어 (cross layer) 정보 (또는 계층 간 정보)를 전송한다. FIC는 앙상블과 모바일 서비스 사이의 연결 정보를 포함할 수 있다.
도 1은 본 발명의 일 실시예에 따른, 전송 시스템을 나타낸 도면이다.
본 발명의 일 실시예에 따른 전송 시스템은, 패킷 정정 유닛 (packet adjustment unit; 101), 프리 프로세서 (pre-processor; 102), 데이터 프레임 인코더 (data frame encoder; 103), 블록 프로세서 (block processor; 104), 시그널링 인코더 (signaling encoder; 105), 그룹 포맷터 (group formatter; 106), 패킷 포맷터 (packet formatter; 107), 패킷 다중화기 (Packet multiplexer; 108), 포스트 프로세서 (post-processor; 109), 수정 데이터 랜더마이저 (modified data randomizer; 110), systematic / non-systematic RS 인코더 (systematic / non-systematic RS encoder; 111), 데이터 인터리버 (data interleaver; 112), non-systematic RS 인코더 (non-systematic RS encoder; 113), 패리티 치환기 (parity replacer; 114), 수정 트렐리스 인코더 (modified trellis encoder; 115), 동기 다중화기 (synchronization multiplexer; 116), 파일럿 삽입기 (pilot inserter; 117), VSB 복조기 (VSB modulator: 118), 및/또는 전송 유닛 (transmission unit; 119)을 포함한다. 본 발명에 따른 전송 시스템은 프리 이퀄라이저 필터 (pre-equalizer filter; 120) 를 더 포함할 수 있다.
패킷 정정 유닛 (packet adjustment unit; 101)는 모바일 서비스 스트림을 포함하는 서비스 스트림과 모바일 서비스 스트림을 포함하지 않는 서비스 스트림 사이에 발생할 수 있는 위치 차이를 보상할 수 있다.
프리 프로세서 (pre-processor; 102) 는 모바일 서비스 데이터를, 모바일 서비스 데이터를 전송하기 위한 모바일 서비스 구조로 형성하는 역할을 수행할 수 있다. 프리 프로세서 (102) 는 모바일 서비스 데이터에 추가적인 FEC 코딩을 수행할 수 있다. 프리 프로세서 (102) 는 기지 데이터를 데이터 그룹에 삽입할 수 있다. 프리 프로세서 (102)는 모바일 환경에서 모바일 서비스 데이터의 송신 및 수신 성능의 안정성을 향상시킨다.
프리 프로세서 (102)는 데이터 프레임 인코더 (data frame encoder; 103), 블록 프로세서 (block processor; 104), 시그널링 인코더 (signaling encoder; 105), 그룹 포맷터 (group formatter; 106), 패킷 포맷터 (packet formatter; 107), 및/또는 패킷 다중화기 (Packet multiplexer; 108)를 포함할 수 있다.
데이터 프레임 인코더 (data frame encoder; 103)는 모바일 서비스 데이터를 랜더마이즈하고, 모바일 서비스 데이터에 대하여 RS 인코딩과 CRC (Cyclic Redundancy Check) 인코딩을 수행한다. 데이터 프레임 인코더(103)는 모바일 서비스 데이터를 포함하는 RS 프레임을 생성한다. 데이터 프레임 인코더(103)는 RS 프레임을 분리하여 RS 프레임 포션 (RS Frame Portion)을 생성하는 RS 프레임 디바이더 (미도시)를 포함할 수 있다.
블록 프로세서 (block processor; 104)는 RS 프레임 포션을 SCCC (Serial Concatenated Convolutional Coding) 블록으로 변환한다. 블록 프로세서 (104)는 SCCC 블록에 포함된 모바일 서비스 데이터의 바이트를 비트 단위의 모바일 서비스 데이터로 변환한다. 블록 프로세서 (104)는 비트 단위의 모바일 서비스 데이터에 대하여 1/2, 1/3, 또는 1/4 레이트 (rate)의 컨볼루셔널 코딩 (Convolutional Coding)을 수행한다. 이 경우, 1/2 레이트는 하나의 비트가 입력되면, 두 개의 비트가 출력되는 것을 의미하며, 1/3 레이트는 하나의 비트가 입력되면, 세 개의 비트가 출력되는 것을 의미하며, 1/4 레이트는 하나의 비트가 입려되면, 네 개의 비트가 출력되는 것을 의미한다. 출력되는 비트들은 심볼에 포함되어 진다. 블록 프로세서 (104)는 컨볼루셔널 인코딩되어 출력되는 심볼에 대하여 인터리빙 (interleaving)을 수행한다. 블록 프로세서 (104)는 인터리빙된 심볼을 바이트 단위의 데이터로 변환한다. 블록 프로세서 (104)는 SCCC 블록을 데이터 블록으로 변환한다.
시그널링 인코더 (signaling encoder; 105)는 수신 측에서의 시그널링을 위한 시그널링 정보를 생성한다. 시그널링 인코더 (105)는 시그널링 정보에 대하여 FEC 코딩과 PCCC (Parallel Concatenated Convolutional Code) 인코딩을 수행한다. 시그널링 정보는 TPC 데이터 및/또는 FIC 데이터를 포함한다.
그룹 포맷터 (group formatter; 106)는 모바일 서비스 데이터을 포함하는 데이터 그룹을 형성한다. 그룹 포맷터 (106)는 FEC 코딩된 모바일 서비스 데이터를 인터리빙된 형태의 데이터 그룹에 삽입한다. 그룹 포맷터 (106)는 시그널링 데이터 수정 트렐리스 인코더 (115)의 메모리를 초기화 하기 위한 초기화 데이터 바이트, 및/또는 기지 데이터 열 (연속되는 기지 데이터의 집합)을 데이터 그룹에 삽입한다. 그룹 포맷터 (106)는 메인 서비스 데이터를 위한 위치 홀더, MPEG-2 헤더를 위한 위치 홀더 및/또는 non-systematic RS 패리티를 위한 위치 홀더를 데이터 그룹에 삽입한다. 그룹 포맷터 (106)는 원하는 형태의 데이터 그룹을 생성하기 위하여 더미 데이터를 삽입할 수 있다. 여러 종류의 데이터를 삽입한 후, 그룹 포맷터 (106)는 인터리빙된 형태의 데이터 그룹 내의 데이터에 대하여 디인터리빙 (de-interleaving)을 수행한다. 디인터리빙이 수행되고 난 후, 데이터 그룹은 인터리빙되기 전의 형태의 데이터 그룹으로 출력된다. 그룹 포맷터 (106)에서 생성되는 데이터 그룹은 하나의 RS 프레임 포션에 해당하는 모바일 서비스 데이터를 포함한다.
패킷 포맷터 (packet formatter; 107)는 그룹 포맷터 (106)의 출력 데이터를 트랜스포트 스트림 (TS; Transport Stream) 패킷으로 변환한다. 이 경우, TS 패킷은 모바일 서비스 데이터 패킷으로 칭할 수 있다. 패킷 포맷터 (107)는 하나의 데이터 그룹에 대하여 (118+M) 개의 모바일 서비스 데이터 패킷을 출력한다. 여기서 M은 38 이하의 정수이다.
패킷 다중화기 (Packet multiplexer; 108)는 프리 프로세서 (102)에 의하여 프로세싱된 모바일 서비스 데이터를 포함하는 패킷과 메인 서비스 데이터를 포함하는 패킷을 다중화한다. 하나의 슬롯에서, 다중화된 패킷은 (118+M)개의 모바일 서비스 데이터와 L 개의 메인 서비스 데이터 패킷을 포함한다. M은 0 이상, 38 이하의 정수 이며, M과 L의 합은 38인 것을 본 발명의 일 실시예로 한다. 다른 실시예로, 패킷 다중화기 (108)는 메인 서비스 데이터 패킷의 개수가 ‘0’인 경우 (L=0), 모바일 서비스 데이터 만이 패킷 다중화기 (108)에 의하여 처리된다.
포스트 프로세서 (post-processor; 109) 는 모바일 서비스 데이터가 기존의 방송 시스템과 역호환성을 가질 수 있도록 모바일 서비스 데이터를 처리한다. 이 과정에서 메인 서비스 데이터가 함께 처리 될 수 있다. 본 발명의 일 실시예에 따르면, 포스트 프로세서 (109)는 수정 데이터 랜더마이저 (modified data randomizer; 110), systematic / non-systematic RS 인코더 (systematic / non-systematic RS encoder; 111), 데이터 인터리버 (data interleaver; 112), non-systematic RS 인코더 (non-systematic RS encoder; 113), 패리티 치환기 (parity replacer; 114), 및/또는 수정 트렐리스 인코더 (modified trellis encoder; 115)를 포함할 수 있다.
수정 데이터 랜더마이저 (modified data randomizer; 110)는 모바일 서비스 데이터 패킷에 대하여는 랜더마이징을 수행하지 않고, 모바일 서비스 데이터 패킷을 바이패스(bypass) 한다. 수정 데이터 랜더마이저 (110)는 메인 서비스 데이터 패킷에 대하여 랜더마이징을 수행한다. 본 발명의 일 실시예에 따르면, 프리 프로세서 (102)에서 생성된 데이터 그룹이 메인 서비스 데이터를 포함하고 있지 않는 경우, 수정 데이터 랜더마이저 (110)는 랜더마이징 과정을 수행하지 않을 수 있다.
systematic / non-systematic RS 인코더 (systematic / non-systematic RS encoder; 111)는 입력되는 데이터가 메인 서비스 데이터 패킷인 경우, 메인 서비스 데이터에 대하여 systematic RS 인코딩을 수행한다. systematic / non-systematic RS 인코더 (111)는 입력되는 데이터가 모바일 서비스 데이터 패킷인 경우, 모바일 서비스 데이터에 대하여 non-systematic RS 인코딩을 수행한다. systematic / non-systematic RS 인코딩에 의하여 생성된 systematic / non-systematic RS 패리티는 데이터 그룹 내에서 기 정의된 위치에 삽입될 수 있다. 패킷 다중화기 (108)에서 다중화되는 서비스 데이터 패킷에 메인 서비스 데이터 패킷이 포함되지 않는 경우, systematic / non-systematic RS 인코더 (111)는 메인 서비스 데이터를 위한 RS 인코딩을 수행할 필요가 없다. 이 경우, systematic / non-systematic RS 인코더 (111)는 역호환성을 위한 non-systematic RS 패리티를 생성하지 않을 수 있다.
데이터 인터리버 (data interleaver; 112)는 메인 서비스 데이터와 모바일 서비스 데이터를 포함하는 데이터에 대한 인터리빙을 수행한다.
수정 트렐리스 인코더 (modified trellis encoder; 115)를 초기화할 필요가 있는 경우, non-systematic RS 인코더 (non-systematic RS encoder; 113)는 수정 트렐리스 인코더 (115)의 메모리 값을 수신하고, 데이터 인터리버 (112) 로부터 모바일 서비스 데이터를 수신하여 모바일 서비스 데이터의 초기화 데이터를 메모리 값으로 바꾼다. non-systematic RS 인코더 (113)는 바뀐 모바일 서비스 데이터에 대하여 non-systematic RS 인코딩을 수행하여 생성된 RS 패리티를 패리티 치환기 (114)로 출력한다.
수정 트렐리스 인코더 (115)가 초기화될 필요가 있는 경우, 패리티 치환기 (114)는 데이터 인터리버 (112)로부터 모바일 서비스 데이터를 수신하고, 모바일 서비스 데이터의 non-systematic RS 패리티를 non-systematic RS 인코더 (113)에 의하여 생성된 non-systematic RS 패리티로 치환한다.
패킷 다중화기(108)에서 다중화된 패킷이 메인 서비스 데이터 패킷을 포함하지 않는 경우, 역호환성을 위한 RS 패리티를 데이터 그룹에 포함시킬 필요가 없다. 따라서, 본 발명의 일 실시예에 따르면, 이 경우 non-systematic RS 인코더 (113)와 패리티 치환기 (114)는 전술한 동작을 수행하지 않고, 수신한 데이터를 바이패스 (bypass) 하는 동작을 수행할 수 있다.
수정 트렐리스 인코더 (modified trellis encoder; 115)는 데이터 인터리버 (112)의 출력에 대하여 트렐리스 인코딩을 수행한다. 트렐리스 인코딩 후에, 방송 송신 측과 방송 수신 측에 의하여 약속된 형태의 기지 데이터를 출력하기 위하여, 트렐리스 인코딩을 시작하기 전에 트렐리스 인코더 (115)에 포함된 메모리가 초기화될 필요가 있다. 전술한 초기화 동작이 데이터 그룹에 포함된 초기화 데이터에 의하여 시작될 수 있다.
동기 다중화기 (synchronization multiplexer; 116) 는 수정 트렐리스 인코더 (115)의 출력 데이터에 필드 동기 신호와 세그먼트 동기 신호를 삽입하고, 이들 데이터를 다중화한다.
파일럿 삽입기 (pilot inserter; 117)는 동기 다중화기 (116)에서 다중화된 데이터를 수신하고, 수신 측에서 채널 신호의 복조를 위하한 캐리어 페이즈 (carrier phase)로 사용되는 파일럿 신호를 다중화된 데이터에 삽입한다.
VSB 복조기 (VSB modulator: 118)는 방송 데이터를 전송하기 위하여 VSB 변조를 수행한다.
전송 유닛 (transmission unit; 119)은 변조된 데이터에 대하여 주파수 업(up) 변환을 수행하고, 변환이 수행된 데이터를 전송한다.
도 2는 본 발명의 일 실시예에 따른, 시그널링 인코더를 나타낸 도면이다.
본 발명의 일 실시예에 따른 시그널링 인코더는 제 1 RS 인코더 (2100), 제 2 RS 인코더 (2200), 블록 인터리버 (2300), 다중화기 (2400), 시그널링 랜더마이저 (2500), 및/또는 PCCC 인코더 (2600)을 수행한다.
제 1 RS 인코더 (2100) 는 TPC 데이터에 대하여 RS 인코딩을 수행한다.
제 2 RS 인코더 (2200) 는 FIC 데이터에 대하여 RS 인코딩을 수행한다. 제 1 RS 인코더와 제 2 RS 인코더는 서로 다른 레이트 (rate)로 RS 인코딩을 수행하는 것을 본 발명의 일 실시예로 한다. 즉, TPC 데이터와 FIC 데이터는 서로 다른 레이트로 RS 인코딩된다.
블록 인터리버 (2300)는 RS 인코딩된 FIC 데이터에 대하여 블록 인터리빙을 수행한다. 블록 인터리빙은 FIC 데이터를 블록 단위로 인터리빙하는 것이다.
다중화기 (2400)는 RS 인코딩된 TPC 데이터와 블록 인터리빙된 FIC 데이터를 다중화한다.
시그널링 랜더마이저 (2500)는 다중화된 데이터를 랜더마이징한다.
PCCC 인코더 (2600)은 랜더마이징된 데이터를 PCCC 인코딩한다.
도 3은 본 발명의 일 실시예에 따른, 앙상블의 구조를 나타낸 도면이다.
앙상블은 모바일 서비스를 구성하는 모바일 서비스 데이터를 전송한다. 앙상블은 모바일 서비스를 시그널링하기 위한 서비스 시그널링 채널 (Service Signaling Channel; SSC)를 포함할 수 있다. 서비스 시그널링 채널은 특정 IP 주소와 UDP port를 통하여 전송되도록 정의할 수 있다. 즉 수신측에서는 해당 IP 주소와 UDP port의 데이터를 파싱하여 서비스 시그널링 채널 데이터를 획득할 수 있다.
서비스 시그널링 채널은 앙상블에 의하여 전송되는 모바일 서비스에 대한 속성 정보를 포함하는 서비스 맵 테이블 (Service Map Table; SMT), 모바일 서비스에 대한 서비스 가이드 데이터에 대한 정보를 포함하는 가이드 어세스 테이블 (Guide Access Table; GAT), 유사한 서비스를 전송하는 인접하는 셀 (cell)에 대한 케리어 주파수 정보를 제공하는 셀 정보 테이블 (Cell Information Table; CIT), 수신 측에서의 빠른 모바일 서비스 스캔을 위한 정보를 포함하는 서비스 라벨링 테이블 (Service Labeling Table; SLT), 모바일 서비스에 대한 시청 등급 정보를 포함하는 레이팅 영역 테이블 (Rating Region Table; RRT), 및/또는 긴급 경보 서비스를 모바일 방송으로 전송하기 위한 정보를 포함하는 모바일 긴급 경보 테이블 (Emergency Alert Table-MH; EAT-MH)을 포함할 수 있다.
도 4는 본 발명의 일 실시예에 따른, 모바일 긴급 경보 테이블을 이용한 긴급 경보 데이터 처리를 나타낸 도면이다.
본 발명의 일실시예에 따르면, 모바일 긴급 경보 테이블의 사이즈를 줄이기 위하여, CAP (Common Alerting Protocol) 경보 메시지가 압축 되어질 수 있다. 모바일 긴급 경보 테이블을 식별할 수 있는 모바일 수신기 (M/H 수신기)는 압축된 CAP 경보 메시지를 추출할 수 있다. 이 경우, 모바일 수신기는 CAP 경보 메시지에 대한 압축을 풀고, SMT를 참조하지 않은 상태에서 빠르게 긴급 경보 메시지를 디스플레이 할 수 있다.
모바일 긴급 경보 테이블은 긴급 경보 메시지의 엔트리에 대한 NRT_service_id 를 전송할 수 있고, NRT_service_id는 긴급 경보 메시지와 관련된 추가 내용이 NRT (Non-Real-Time) 방송 서비스를 통하여 전송되는 것을 가리킨다. NRT 방송 서비스를 수신할 수 있는 방송 수신기는 SMT, 서비스 가이드 (Service Guide; SG), 및/또는 NRT 서비스를 위하여 시그널링 되는 FLUTE (File Delivery over Unidirectional Transport) session를 참조하여 추가 긴급 경보 메시지를 디스플레이 할 수 있다.
모바일 긴급 경보 테이블의 반복 수신 횟수는 긴급 경보 메시지의 중요도에 따라 달라질 수 있다. 중요도가 최고인 긴급 경보 메시지는 하나의 MH 프레임 마다 반복될 수 있다.
도 4를 참조하면, 방송 수신기는 GAT의 MH_service_id를 참조하여 SMT에서 해당 서비스의 ip 주소와 UDP port 번호를 식별하고, 이를 통하여 전송되는 FLUTE 데이터를 파싱하여, 전자 서비스 가이드 (ESG; Electronic Service Guide) 를 통하여 긴급 경보 컨텐츠가 포함되어 있음을 디스플레이 할 수 있다. 방송 수신기는 모바일 긴급 경보 테이블의 EAS_NRT_service_id를 참조하여, NRT로 전송되는 긴급 경보 메시지를 포함하는 서비스를 전송하는 ip 주소와 UDP port 번호를 식별하고, 이를 통하여 전송되는 FLUTE 데이터를 파싱하여, 긴급 경보 메시지를 디스플레이할 수 있다. 혹은, 모바일 긴급 경보 테이블은 긴급 경보 메시지를 포함하고 있을 수 있으며, 이 경우, CAP 파서를 통하여 이 긴급 경보 메시지를 바로 파싱하여 디스플레이할 수 있다.
도 5는 본 발명의 일 실시예에 따른, 모바일 긴급 경보 테이블의 신택스를 나타낸 도면이다.
본 발명의 모바일 긴급 경보 테이블은 table_id 필드, EAT_MH_protocol_version 필드, ensemble_id 필드, automatic_tuning_channel_number 필드, automatic_tuning_ts_id 필드, automatic_tuning_ensemble_id 필드, automatic_tuning_service_id 필드, num_EAS_messages 필드, EAS_message_id 필드, type_of_responder 필드, type_of_disciplines 필드, EAS_IP_version_flag 필드, EAS_message_transfer_type 필드, EAS_message_encoding_type 필드, EAS_message_length 필드, EAS_message_bytes 필드, 및/또는 EAS_NRT_service_id 필드를 포함할 수 있다.
table_id 필드 현재 테이블의 종류를 식별한다. 방송 수신기는 특정한 값의 table_id 필드를 식별하여, 본 테이블이 모바일 긴급 경보 테이블임을 식별할 수 있다.
EAT_MH_protocol_version 필드는 모바일 긴급 경보 테이블의 구조가 변경되는 경우, 이들에 대한 버전 정보를 식별한다.
ensemble_id 필드는 본 테이블과 관련된 앙상블의 ID를 나타낸다.
automatic_tuning_channel_number 필드는 자동 튜닝을 위한 물리적 RF 채널 번호를 나타낸다. 예를 들면, 긴급 경보 메시지가 방송되는 채널 번호로 강제 튜닝이 필요한 경우, 위 필드가 참조될 수 있다.
automatic_tuning_ts_id 필드는 자동 튜닝을 위한 트랜스포트 스트림 ID를 나타낸다. 예를 들면, 긴급 경보 메시지를 포함하는 트랜스포트 스트림을 파싱해야 하는 경우, 위 ID를 통하여 해당 스트림을 식별할 수 잇다.
automatic_tuning_ensemble_id 필드는 자동 튜닝을 위한 앙상블의 ID를 나타낸다. 예를 들면, 긴급 경보 메시지를 포함하는 앙상블을 위 필드를 통하여 식별할 수 있다.
automatic_tuning_service_id 필드는 자동 튜닝의 타겟 A/V 서비스를 나타낸다. 모바일 긴급 경보 테이블에서 자동 튜닝이 지정된 경우, 긴급 경보 테이블은 경보 메시지를 포함할 수도 있고, 포함하지 않을 수도 있다. 자동 튜닝이 지정된 경우, 방송 수신기는 해당 메시지를 무시하고, 타겟 채널 번호로 튜닝할 것이다.
num_EAS_messages 필드는 모바일 긴급 경보 테이블에 포함된 긴급 경보 메시지의 개수를 나타낸다.
EAS_message_id 필드는 긴급 경보 메시지의 전송을 위한 고유의 ID를 식별한다. 이 필드는 이전 긴급 경보 메시지가 업데이트 되거나, 취소되는 경우에는 그 값이 변경될 수 있다. 다른 실시예로, 이 필드는 CAP 메시지 ID로부터 추출될 수 있다.
type_of_responder 필드는 긴급 경보 메시지의 방송 대상자를 나타낸다.
type_of_disciplines 필드는 긴급 경보의 대상이 되는 긴급 상황에 대한 정보를 나타낸다.
EAS_IP_version_flag 필드는, ‘0’으로 셋팅되는 경우 IP_address 필드가 IPv4 주소를 포함함을 나타내고, ‘1’으로 셋팅되는 경우 IP_address 필드가 IPv6를 위한 것임을 나타낸다.
EAS_message_transfer_type 필드는 긴급 경보 메시지의 전송 타입을 나타낸다.
EAS_message_encoding_type 필드는 긴급 경보 메시지의 인코딩 계획을 나타낸다.
EAS_message_length 필드는 긴급 경보를 포함하는 압축된 긴급 경보 메시지의 압축 길이를 나타낸다.
EAS_message_bytes 필드는 긴급 경보를 포함하는 압축된 긴급 경보 메시지의 크기를 나타낸다.
EAS_NRT_service_id 필드는 긴급 경보 메시지와 연관된 추가 컨텐츠를 제공하는 NRT 서비스의 서비스 ID를 식별한다. 이 필드는 긴급 경보 테이블을 전송하는 앙상블에 포함된 SMT에도 삽입될 수 있다.
도 6은 본 발명의 일 실시예에 따른, type_of_responder 필드, type_of_disciplines 필드, EAS_message_transfer_type 필드, EAS_message_encoding_type 필드의 각 값에 따른 의미를 나타낸 도면이다.
type_of_responder 필드는 이 필드의 값에 따라, 긴급 경보 메시지의 시청 대상자가 식별되지 않았거나, 시청 대상자가 대중이 아닌 경우를 나타내거나, 시청 대상자가 대중인 경우를 나타내거나, 시청 대상자가 대중과 대중이 아닌 경우를 모두 포함하는 것을 나타낼 수 있다.
type_of_disciplines 필드는 이 필드의 값에 따라, 긴급 경보 시스템 발동의 상황을 나타내거나, 폭발 사건을 나타내거나, 화재 상황을 나타내거나, 위험 물질 발생 사건을 나타내거나, 법률 집행을 나타내거나, 인명 구조 상황을 나타낼 수 있다.
EAS_message_transfer_type 필드는 이 필드의 값에 따라, 긴급 경보 메시지의 전송 타입이 식별되지 않았거나, 경보 메시지가 포함되지 않은 NRT 파일이 전송됨을 나타내거나, 긴급 경보 메시지가 모바일 긴급 경보 테이블에 포함되어 전송되거나, 긴급 경보 메시지가 IP 데이터 그램을 통해 전송되는 경우를 나타낼 수 있다.
EAS_message_encoding_type 필드는 이 필드의 값에 따라, 인코딩 계획이 식별되지 않은 경우를 나타내거나, 긴급 경보 메시지에 대한 인코딩(또는 압축)이 수행되지 않았음을 나타내거나, gzip 알고리즘을 이용하여 긴급 경보 메시지가 압축되었음을 나타낼 수 있다.
도 7은 본 발명의 일 실시예에 따른, 긴급 경보 메시지가 IP 데이터 그램을 통해 전송되는 것이 식별되는 경우, IP 데이터 그램의 신택스를 나타낸 도면이다.
IP 데이터 그램에는 EAS_message_id 필드, EAS_message_length 필드, 및/또는 EAS_message_bytes 필드가 포함될 수 있다.
EAS_message_id 필드는 모바일 긴급 경보 테이블 내의 긴급 경보 메시지의 엔트리에 해당되는 값에 대응된다.
EAS_message_length 필드는 각각의 긴급 경보 메시지의 길이를 나타낸다.
EAS_message_bytes 필드는 압축된 긴급 경보 메시지의 크기를 나타낸다.
도 8은 본 발명의 일 실시예에 따른, FIC 세그먼트 헤더의 신택스를 나타낸 도면이다.
모바일 방송 수신기는 스탠바이 모드로 동작할 수 있고, 웨이크업 기능을 통하여 긴급 경보 메시지에 대한 반응을 수행할 수 있다. 웨이크업 기능을 수행할 수 있는 모바일 방송 수신기는 모바일 서비스를 제공하지 않고, 스탠바이 모드에 있는 경우에도, 방송사로부터 전송되는 방송 신호를 모니터링하고 있을 수 있다.
웨이크업이란, 긴급 경보 메시지를 위하여 방송 수신기가 sleeping 모드 (혹은 대기 모드) 에 있는 경우라도, 해당 방송 수신기를 active 모드 (혹은 활성 모드)로 전환하는 것을 말한다.
모바일 방송 수신기사 방송 신호를 지속적으로 모니터링하는 것은 배터리의 소모를 촉진시킨다. 따라서, 배터리의 소모를 줄이기 위한 시그널링이 필요하다. 모바일 방송 서비스에서 시그널링을 위한 가장 작은 유닛은 FIC 세그먼트에 포함되는 FIC 세그먼트 헤더이나, FIC 세그먼트를 획득하기 위하여, 방송 수신기는, 적어도 하나의 RS 프레임을 수신하는 것이 필요하다. FIC Chunk의 변화는 TPC를 모니터링함으로써 감지할 수 있다. 예를 들어, TPC에 포함되는 FIC_version 필드의 값이 변화하면 FIC Chunk에 변화가 있음을 알 수 있다. 방송 수신기는 TPC에 FIC_version 필드에 변화가 감지되면, 방송 수신기의 전원을 ON 시키고 FIC 세그먼트를 모으기 위하여 RS 프레임을 수신한다. FIC Chunk에 웨이크업 신호가 존재하는 경우, FIC 세그먼트 헤더 내의 웨이크업 지시자 (indicatoer)는 모바일 방송 수신기가 웨이크업되어야 하는지를 판단하기 위하여 사용될 수 있다.
FIC Chunk는 복수의 FIC 세그먼트 페이로드로 분할되어 전송된다. FIC 세그먼트는 FIC 세그먼트 헤더와 FIC 세그먼트 페이로드를 포함한다. FIC 세그먼트는 하나의 데이터 그룹을 통하여 전송된다.
FIC 세그먼트 헤더는 FIC_segment_type 필드, wake_up_indicator 필드, FIC_chunk_major_protocol_version 필드, current_next_indicator 필드, error_indicator 필드, FIC_segment_num 필드, 및/또는 FIC_last_segment_num 필드를 포함한다.
FIC_segment_type 필드는 FIC 세그먼트에 의하여 전송되는 데이터의 종류를 가리킨다. FIC_segment_type 필드는 그 값에 따라, FIC 세그먼트 페이로드가 FIC Chunk의 일부를 전송한다는 것을 가리킬 수 있고, 혹은 FIC 세그먼트 페이로드가 의미있는 데이터는 포함하고 있지 않다는 것을 가리킬 수 있다.
wake_up_indicator 필드는 웨이크업 기능을 수행 가능한 모바일 방송 수신기가 자동으로 전원을 ON 하고, 긴급 경보 메시지를 제공하여야 하는지를 가리킨다. 예를 들면, wake_up_indicator 필드의 값에 따라, 모바일 방송 수신기는 웨이크업 과정을 무시하고 예전 기능을 계속 수행하거나, 혹은 웨이크업 기능을 즉시 수행하도록 제어될 수 있다.
FIC_chunk_major_protocol_version 필드는 FIC 세그먼트를 통하여 일부 전송되는 FIC Chunk의 메이저 프로토콜 버전을 가리킨다. 이 값은 FIC Chunk header에 포함되는 FIC_chunk_major_protocol_version 필드의 값과 동일하게 셋팅될 수 있다.
current_next_indicator 필드는 FIC 세그먼트를 통하여 일부 전송되는 FIC Chunk의 현재 또는 다음 상태를 나타낸다.
error_indicator 필드는 FIC 세그먼트에 에러가 검출되었는지 여부를 가리킨다.
FIC_segment_num 필드는 FIC 세그먼트의 번호를 가리킨다. FIC Chunk에 포함되는 FIC 세그먼트 페이로드를 포함하는 FIC 세그먼트가 몇 번째 FIC 세그먼트인지를 나타낼 수 있다.
FIC_last_segment_num 필드는 마지막 FIC 세그먼트의 번호를 가리킨다. FIC Chunk에 포함되는 FIC 세그먼트 페이로드를 포함하는 FIC 세그먼트 중 마지막 FIC 세그먼트가 몇 번째 FIC 세그먼트인지를 나타낼 수 있다.
도 9는 본 발명의 일 실시예에 따른, FIC Chunk 페이로드의 신택스를 나타낸 도면이다.
웨이크업 기능을 수행 가능한 모바일 방송 수신기는 TPC 내의 FIC_version 필드를 모니터링하고 있을 것이다. FIC_version 필드의 변화가 감지되면, 모바일 방송 수신기는 FIC 세그먼트를 모으는 작업을 시작할 것이다. FIC 세그먼트 헤더의 wake_up_indicator 필드가 웨이크업 기능을 수행하여야 함을 가리키면, 모바일 방송 수신기는 서비스 시그널링 채널 내의 모바일 긴급 경보 테이블을 포함하는 앙상블을 수신할 것이다. 이때, 해당 앙상블은 EAT_ensemble_indicator 필드에 의하여 식별될 수 있다.
FIC Chunk 페이로드는 ensemble_id 필드, ensemble_protocol_version 필드, SLT_ensemble_indicator 필드, GAT_ensemble_indicator 필드, EAT_ensemble_indicatoer 필드, MH_service_signaling_channel_version 필드, num_MH_services 필드, MH_service_id 필드, multi-ensemble_service 필드, MH_service_status 필드, 및/또는 SP_indicator 필드를 포함한다.
ensemble_id 필드는 해당 FIC에 의하여 시그널링 되는 앙상블을 식별한다.
ensemble_protocol_version 필드는 앙상블의 구조의 버전 정보를 나타낸다.
SLT_ensemble_indicator 필드는 앙상블에 포함되는 서비스 시그널링 채널이 서비스 라벨링 테이블을 포함하는지 여부를 나타낸다.
GAT_ensemble_indicator 필드는 앙상블에 포함되는 서비스 시그널링 채널이 가이드 어세스 테이블을 포함하는지 여부를 나타낸다.
EAT_ensemble_indicatoer 필드는 앙상블에 포함되는 서비스 시그널링 채널이 모바일 긴급 경보 테이블을 포함하는지 여부를 나타낸다. 또는 EAT_ensemble_indicator는 이 앙상블의 시그널링 스트림내에 모바일 긴급 경보 테이블이 전송됨을 가리킨다.
MH_service_signaling_channel_version 필드는 앙상블에 포함되는 서비스 시그널링 채널의 버전을 나타낸다.
num_MH_services 필드는 앙상블을 통하여 시그널링되는 MH 서비스의 개수를 나타낸다.
MH_service_id 필드는 MH 서비스를 식별한다.
multi-ensemble_service 필드는 MH 서비스가 하나 이상의 앙상블을 통하여 전송되는지 여부를 나타낸다.
MH_service_status 필드는 MH 서비스의 상태를 나타낸다. 예를 들면, MH_service_status 필드는 이 필드가 가지는 값에 따라, MH 서비스가 활성화 되었는지 여부 및/또는 MH 서비스가 ‘hidden’ 되었는지 여부를 나타낸다.
SP_indicator 필드는 MH 서비스를 제공하기 위한 컴포넌트 중 적어도 하나 이상에 서비스 프로텍션 (service protection)이 적용되었는지 나타낸다.
도 10은 본 발명의 일 실시예에 따른, 웨이크업 기능 수행을 위한 데이터 처리 흐름도 있다.
모바일 방송 수신기는 FIC 세그먼트 헤더 또는 TPC를 모니터링한다. 모바일 방송 수신기는 FIC_version 필드에 변화가 없으면, 위 모니터링을 계속 수행하고, FIC_version 필드에 변화가 있으면, FIC 세그먼트 헤더를 체크한다(10010). FIC 세그먼트 헤더 내의 wake_up_indicator 필드가 웨이크업 기능을 수행하지 않는 것을 가리키는 경우, 모바일 방송 수신기는 FIC 세그먼트 헤더 또는 TPC에 대한 모니터링 계속 수행하고, wake_up_indicator 필드가 웨이크업 기능을 수행할 것을 가리키는 경우(10020), FIC 세그먼트를 모아, FIC Chunk를 완성한다(10030). 모바일 방송 수신기는 FIC Chunk 페이로드의 EAT_ensemble_indicator를 체크한다(10040). 모바일 방송 수신기는 EAT_ensemble_indicator가 모바일 긴급 경보 테이블을 전송하는 앙상블을 가리키는 경우(10050), 해당 앙상블에 대한 파싱/디코딩을 시작하고 (10060), 긴급 경보 메시지 제공을 위한 어플리케이션이 필요한 경우, 이러한 어플리케이션을 시작한다(10070). 모바일 방송 수신기는 해당 앙상블로부터 모바일 긴급 경보 테이블을 얻고(10080), 이 테이블을 이용하여 긴급 경보 메시지를 파싱하여 디스플레이한다(10090). 전술한 과정이 종료하면, 모바일 방송 수신기는 전원을 Off 한다(10100).
도 11은 본 발명의 일 실시예에 따른, FIC Chunk 헤더의 신택스를 나타낸 도면이다.
웨이크업 지시자가 사용자에 의하여 무시된 경우, 방송 수신기는 동일한 웨이크업 이벤트에 대하여 반복되는 전송을 무시할 필요성이 있다.
FIC Chunk 헤더는 FIC_chunk_major_protocol_version 필드, FIC_chunk_minor_protocol_version 필드, FIC_chunk_header_extension_length 필드, ensemble_loop_header_extension_length 필드, MH_service_loop_extension_length 필드, current_next_indicator 필드, transport_stream_id 필드, EAS_wake_up_extended_info 필드, EAS_wake_up_extended_info_Tag 필드, EAS_wake_up_version_number 필드, 및/또는 num_ensembles 필드를 포함할 수 있다.
FIC_chunk_major_protocol_version 필드는 FIC Chunk의 신택스에 대한 메이저 버전을 나타낸다. 메이저 레벨의 변화는 역호환성이 유지되지 않는 범위의 FIC Chunk의 신택스 변화를 나타낸다.
FIC_chunk_minor_protocol_version 필드는 FIC Chunk의 신택스에 대한 마이너 버전을 나타낸다. 마이너 레벨의 변화는 역호환성이 유지되는 범위의 FIC Chunk의 신택스 변화를 나타낸다. 본 발명의 일 실시예에서는 FIC_chunk_minor_protocol_version 필드는 긴급 경보 시스템을 위한 웨이크업 시그널링 확장이 FIC Chunk에 존재함을 나타낼 수 있다.
FIC_chunk_header_extension_length 필드는 FIC Chunk의 신택스에 마이너 레벨의 변화에 의한 FIC Chunk 헤더에서 확장된 필드들에 길이를 나타낸다. FIC_chunk_header_extension_length 필드는 웨이크업 시그널링 확장에 의하여 확장된 필드의 길이를 나타낼 수 있다.
ensemble_loop_header_extension_length 필드는 FIC Chunk의 신택스의 마이너 레벨의 변화에 의하여 추가된 FIC Chunk 페이로드 내의 num_ensemble 루프의 헤더의 확장 필드의 길이를 나타낸다.
MH_service_loop_extension_length 필드는 FIC Chunk의 신택스의 마이너 레벨의 변화에 의하여 추가된 FIC Chunk 페이로드 내의 num_MH_services 루프 엔트리의 확장 필드의 길이를 나타낸다.
current_next_indicator 필드는 FIC Chunk가 현재 MH 프레임에 적용 가능한 것인지, 다음 MH 프레임에 적용 가능한 것인지 나타낸다.
transport_stream_id 필드는 모바일 방송을 식별하기 위한 라벨 (label) 역할을 수행한다.
EAS_wake_up_extended_info 필드는 웨이크업 기능을 위하여 확장된 필드에 대한 정보를 포함한다.
EAS_wake_up_extended_info_Tag 필드는 확장된 FIC Chunk 헤더의 타입(type)을 가리킨다. 예를 들어, EAS_wake_up_extended_info_Tag 필드는 웨이크업 기능을 위하여 확장된 필드의 크기를 가리킬 수 있다.
EAS_wake_up_version_number 필드는 웨이크업 시그널링의 버전 정보를 나타낸다.
num_ensembles 필드는 FIC Chunk와 관련하여, 물리적 전송 채널을 통하여 전송되는 앙상블의 개수를 나타낸다.
도 12는 본 발명의 일 실시예에 따른, FIC Chunk 헤더의 확장을 통한 웨이크업 시그널링의 버전 정보를 처리하는 절차를 나타낸 도면이다.
방송 수신기는 TPC에 포함된 FIC_version 필드를 모니터링하면서, FIC_version 필드가 변경된 경우 FIC 세그먼트 헤더를 체크한다. 방송 수신기는 wake_up_indicatoer 필드가 웨이크업 기능을 수행할 것임을 나타내는 경우, FIC Chunk를 수신하고, FIC Chunk 헤더 내의 FIC_chunk_minor_protocol_version 필드, 및/또는 FIC_chunk_header_extension_length 필드를 체크한다. 방송 수신기는 FIC_chunk_minor_protocol_version 필드가 웨이크업 시그널링을 위한 FIC Chunk에 변화가 있다고 나타내는 경우, FIC_chunk_header_extension_length 필드를 파싱하고, FIC_chunk_header_extension_length 필드가 웨이크업 시그널링을 위한 FIC Chunk 헤더의 확장이 있다는 것을 가리키는 경우, FIC Chunk 헤더에서 EAS_wake_up_extended_info 필드를 체크한다. 방송 수신기는 EAS_wake_up_extended_info_Tag 필드를 통하여 확장된 필드를 확인하고, EAS_wake_up_version_number 필드를 통하여 웨이크업 시그널링의 버전에 변화가 있는지 판단한다. 방송 수신기는 웨이크업 시그널링의 버전에 변화가 있는 경우, FIC Chunk 페이로드 내의 EAT_ensemble_indicator 필드를 체크하고, 모바일 긴급 경보 테이블을 전송하는 앙상블로부터 모바일 긴급 경보 테이블을 획득한다. 방송 수신기는 획득한 모바일 긴급 경보 테이블을 이용하여 긴급 경보 시스템을 처리한다.
도 13은 본 발명의 일 실시예에 따른, 웨이크업 동작의 중요 긴급 경보로의 자동 튜닝을 처리하는 것을 나타낸 도면이다.
방송 수신기는 자동 튜닝 정보가 제공되는 경우, 웨이크업 동작의 일부분으로 중요한 긴급 경보로 자동 튜닝을 제공할 수 있다.
방송 수신기는 TPC에 포함된 FIC_version 필드를 모니터링하면서, FIC_version 필드가 변경된 경우 FIC 세그먼트 헤더를 체크한다. 방송 수신기는 wake_up_indicatoer 필드가 웨이크업 기능을 수행할 것임을 나타내는 경우, FIC Chunk를 수신하고, 웨이크업 시그널링의 버전을 체크한다. 웨이크업 시그널링의 버전에 변화가 있는 경우, 모바일 긴급 경보 테이블을 포함하는 앙상블을 수신하고, 모바일 긴급 경보 테이블 내의 automatic_tuning_info 필드에 포함되는 필드들이 다른 채널로의 자동 튜닝이 필요함을 나타내는 경우, 자동 튜닝 대상의 주파수로 튜닝을 수행한다. 해당 주파수에서 앙상블을 획득하고, 앙상블에 포함된 모바일 긴급 경보 테이블을 이용하여 긴급 경보 시스템을 실행한다.
도 14는 본 발명의 일 실시예에 따른, FLUTE FDT (File Delivery Table) 인스턴스 (instance)를 나타낸 도면이다.
본 발명의 일 실시예는 NRT 파일을 전송하는 FLUTE 세션을 통하여, 0개의 파일이 전송되는 것을 허용하도록 FDT 인스턴스가 수정될 필요가 있다.
긴급 경보를 위한 NRT 방송 서비스에서 전송되는 FLUTE FDT 인스턴스의 엘레먼트 (element) 는 OMA BCAST의 내용을 따른다.
도 15는 본 발명의 다른 실시예에 따른, TPC를 이용한 웨이크업 시그널링을 위한 TPC의 신택스를 나타낸 도면이다.
본 발명의 다른 실시예에 따르면, TPC 데이터에 wake_up_indicator와 wake_up_version_number를 추가할 수 있다. 이 경우, 방송 수신기는 TPC data만 보고도 긴급 경보를 위한 웨이크업 기능을 수행하여야 할지를 판단할 수 있다. 이 경우, 전술한 FIC Chunk를 이용한 웨이크업 기능 수행 보다 배터리 소모를 줄일 수 있는 효과가 있다. 즉, 방송 수신기는 FIC 세그먼트를 모아 FIC Chunk를 완성시킬 필요가 없으므로, 이러한 동작이 생략될 수 있고, 이로 인하여, 배터리 소모가 줄어들 수 있다.
본 발명의 일 실시예에 따르면, ATSC A/153 Part 2에 기술되어 있는 TPC data(Transmission Parameter Channel Data)에 wake_up_indicator와 wake_up_version_number 정보를 추가하여 웨이크업 기능을 수행할 수 있다. 따라서, 도 15에서는 TPC에 포함되는 필드는 일부 필드는 생략하였으나, 이는 ATSC A/153 Part 2를 참조할 수 있다. 또한, 도 15에 도시된 TPC에 포함되는 필드 중 별도의 설명이 없는 필드는 ATSC A/153 Part 2에 기재된 내용을 참조할 수 있다.
TPC 데이터는 wake_up_indicator 필드, 및/또는 wake_up_version_number 필드를 포함할 수 있다.
wake_up_indicator 필드는 기존의 reserved bit을 사용하여 1-bit를 할당한다. wake_up_indicator 필드는 방송 수신기가 웨이크업 기능을 수행하여야 하는지 여부를 가리킨다. 예를 들어, 이 값이 ‘0’이면 방송 수신기가 스탠바이 모드인 경우에는 웨이크업 기능을 수행해야 하며, ‘1’인 경우에는 기존의 상태를 유지하도록 한다. 즉, 방송 수신기가 스탠바이 모드인 경우에는 계속 TPC를 monitoring 하는 상태로, A/V를 재생하고 있었던 경우에는 A/V를 계속 재생하도록 제어될 수 있다.
wake_up_version_number 필드는 웨이크업 시그널링의 버전 정보를 나타낸다. 방송 수신기는 wake_up_version_number 필드의 값을 기 수신한 wake_up_version_number 필드의 값과 비교하여 스탠바이 모드에서 액티브(active) 모드로 바꿔서 FIC를 받기 전에 새로운 웨이크업 인지 아닌지를 판단할 수 있다.
도 16은 본 발명의 다른 실시예에 따른, FIC 세그먼트 헤더의 신택스를 나타낸 도면이다.
본 발명의 다른 실시예는, FIC 세그먼트 헤더에 포함되는 wake_up_indicator 필드에 2bit를 할당함으로써, 모바일 방송 수신기에서 두 개의 웨이크업에 대응할 수 있다.
FIC 세그먼트 헤더의 신택스의 내용은 전술한 내용으로 대체한다.
웨이크업을 수행하도록 할 정도의 강력한 재난이 발령할 가능성은 매우 적다. 하나의 웨이크업 (wake-up 1)이 수신기에 전달되었을 경우 수신기는 강제로 켜질 것이고, 사용자는 프로그램을 보다가 wake-up 1을 강제 종료할 수 있다. 이 때에도 계속 같은 wake-up 1에 해당하는 웨이크업 시그널링이 계속 전송될 수 있다. 이 때 방송 수신기는 2 bit의 wake_up_indicator 필드를 이용하여 사용자가 강제 종료한 후에 전달된 웨이크업인지 아닌지를 판단할 수 있다. 즉, 추후에 전달된 wake-up 2에 해당하는 강력한 재난이 발령하여 wake-up 2의 시그널링이 전송되는 경우, 방송 수신기를 다시 강제로 켜지게 할 수 있다. 따라서, wake_up_indicator 필드에 2 bit를 할당하여, 이전에 수신한 웨이크업과 새로 수신한 웨이크업을 구분하는 기능이 필요할 수 있다.
도 17은 본 발명의 다른 실시예에 따른, ESG 컨텐츠 프래그먼트 (Fragment)를 나타낸 도면이다.
본 발명의 다른 실시예에 따르면, 긴급 경보 시스템은 각각의 긴급 경보 메시지에 대하여 각기 다른 NRT 서비스를 사용하지 않고, 모든 긴급 경보 메시지에 대하여 하나의 동일한 NRT 서비스를 사용할 수 있다. 이러한 경우, 각각의 NRT 컨텐츠들이 어떤 메시지와 연관되는지 알아내기 위해서 ESG의 컨텐츠 프래그먼트 새로운 element를 포함시킬 수 있다.
본 발명의 다른 실시예에 따른, ESG 컨텐츠 프래그먼트는 EAS_Content_message_ID 필드, 및/또는 EAS_Content_message_TAG 필드를 포함할 수 있다.
EAS_Content_message_ID 필드는 모바일 긴급 경보 테이블에서 명시한 긴급 경보 메시지의 ID와 같은 값을 가질 수 있다.
EAS_Content_message_TAG 필드는 NRT 리스트를 보여줄 때, 사용할 수 있는 값이다. 예를 들어, 긴급 경보 메시지가 ‘태풍’에 대한 것이면, TAG는 “태풍 경보”이라는 값을 가질 수 있다. 이 TAG의 값은 지역 스테이션에 설치된 ESG 서버에 할당된다.
도 18은 본 발명의 일 실시예에 따른, 긴급 경보 시스템을 나타낸 도면이다.
PBS (Public Broadcasting Service)는 IPAWS (Integrated Public Alert and Warning System)-OPEN에서 Secure Line을 통해 긴급 경보 메시지를 가져와서 위성망을 통해서 지역 PBS 스테이션으로 해당 메시지를 보낸다. 지역 PBS 스테이션으로 전달된 긴급 경보 메시지는 MDTV (Mobile Digital Television) 시그널링 서버에서 모바일 긴급 경보 테이블로 만들어지고, 이는 다중화기와 익사이터 (Exciter) 를 통해서 MDTV 네트워크로 송출된다.
MDTV 수신기는 이 신호를 수신하면 시그널링 디코더를 이용하여 모바일 긴급 경보 케이블을 파싱하고, 모바일 긴급 경보 테이블 내부에 존재하는 긴급 경보 메시지를 파싱하여 화면에 보여줄 긴급 경보 메시지의 텍스트를 추출해낸다.
NRT를 통한 긴급 경보 메시지에 대한 부가 정보의 흐름은 아래와 같이 진행될 수 있다.
첫 번째 방법으로, 지역 PBS 스테이션에서는 재난과 관련된 부가정보 파일들을 만들어서 MDTV NRT 서버가 사용하는 NRT 파일 저장소에 저장하고, MDTV NRT 서버는 NRT 파일 저장소에 저장된 파일들과 관련된 시그널링 정보를 형성하고, 파일들을 Non-Real-Time으로 전송하게 된다. 이 또한 다중화기와 익사이터 (exciter)를 이용하여 MDTV 네트워크를 통해서 전달되며, 방송 수신기는 FLUTE/ESG 기능을 이용하여 NRT로 전송되는 파일들에 대한 정보를 알아내어 파일을 전송 받은 후, 방송 수신기 화면에 보여줄 수 있다.
또는, 두 번째 방법으로, NRT 파일이 각 지역 PBS 스테이션에서 생성되는 것이 아니라, IPAWS-OPEN에서 긴급 경보 메시지를 발령할 때에 CAP 메시지 내부에 부가 정보를 가리키는 URI 정보를 포함하여 보내는 방법이 있다. 이때, CAP의 <resource> element 의 sub element인 <uri> element가 이용될 수 있다. MDTV 시그널링 서버에서는 CAP 메시지의 URI 정보를 추출하여 리소스 파일 (Resource file)을 가져올 수 있고, 이를 NRT를 통해 MDTV 네트워크를 통해 송출한다. 그 후 진행되는 흐름은 전술한 첫 번째 방법과 같다.
모바일 긴급 경보 시스템의 긴급 경보 메시지 수신자는 퍼블릭 (Public)과 논 퍼블릭 (Non-public)으로 나눌 수 있다. Non-public인 사용자는 First Responder로 정의된다. First Responder는 각 재난을 처리할 수 있는 능력을 가지고 있는 사람들을 일컫는다. 예를 들면 화재 발생시 911이 first responder에 해당할 것이다. 모바일 긴급 경보 테이블에는 긴급 경보 메시지가 전달되어야 하는 수신기/수신자 타입을 정의하고 있으며, 수신자가 First responder인 경우에는 어떠한 discipline으로 전달되어야 하는지에 대해서도 정의하고 있다. 이에 대한 내용은 전술한 내용을 대체한다.
도 19는 본 발명의 일 실시예에 따른, NRT를 이용한 긴급 경보 메시지의 부가 정보를 제공하는 장면을 나타낸 도면이다.
전술한 바와 같이, 모바일 긴급 경보 시스템에서는, 방송 수신기가 Non-Real-Time으로 전송되는 파일들을 이용하여 재난과 관련된 부가 정보를 디스플레이할 수 있다. 모바일 긴급 경보 시스템에서는 여러 개의 긴급 경보 메시지가 동시에 보내지는 것이 가능한데, 이러한 경우 각각의 긴급 경보 메시지에 대하여 각기 다른 NRT 부가 정보를 가질 수 있다. 모바일 NRT 환경에서는 NRT와 관련된 모든 정보가 ESG 내부에 포함될 수 있다. 따라서, 모든 MDTV 수신기는 ESG 기능을 보유하고 있어야 하며, 부가 정보는 ESG를 업데이트한 후에 사용자에게 보여질 수 있다. ESG를 업데이트 한 후, MDTV 수신기는 ESG의 서비스 프래그먼트 (Service Fragment)에서 각각의 NRT 서비스의 이름을 읽어와서 화면에 보여준다. 도 19를 참조하면, Hurricane, Typhoon 두 개의 긴급 경보 메시지가 발령되었을 경우, 각각의 메시지와 관련된 NRT 서비스의 리스트를 보여주기 위해서 수신기에서 읽어오는 ESG의 서비스 프래그먼트가 개시되어 있다. 각각의 프래그먼트의 명칭이 나타내는 정보가 긴급 경보 메시지의 부가 정보로 제공될 수 있다.
도 20은 본 발명의 다른 실시예에 따른, NRT를 이용한 긴급 경보 메시지의 부가 정보를 제공하는 장면을 나타낸 도면이다.
긴급 경보 메시지와 관련된 NRT 서비스의 목록에서 사용자가 하나의 서비스를 선택하면, 수신기는 그 서비스와 연계된 컨텐츠의 목록을 화면에 보여줄 수 있다. 컨텐츠와 관련된 정보는 ESG 내부에 포함되어 전송될 수 있다. NRT 컨텐츠 정보는 ESG의 컨텐츠 프래그먼트 (content fragment)에 기록되어 있으며 수신기는 사용자가 선택한 서비스를 참조하는 컨텐츠 항목들을 검색하여 화면에 컨텐츠의 이름, 및/또는 유효 기간 등의 정보를 목록을 구성하여 보여줄 수 있다.
긴급 경보 메시지의 부가 정보를 제공하는 각각의 NRT 파일들은 FLUTE을 통하여 방송 수신기로 전송되고, 방송 수신기 내부의 저장소에 저장된다. 사용자가 해당 부가 정보를 보기를 원하는 경우, 방송 수신기는 해당 파일을 읽어 해당 부가 정보를 디스플레이한다.
도 21은 본 발명의 일 실시예에 따른, 모바일 긴급 경보 시스템의 UI를 나타낸 도면이다.
긴급 경보 메시지의 텍스트는 모바일 긴급 경보 테이블을 통해 전송되므로, 모바일 방송 수신기는 관련 시그널링 정보를 수신하여, 긴급 경보 메시지에 대한 추출 작업을 완료한 후, 긴급 경보 메시지를 디스플레이 한다.
모바일 방송 수신기는, 긴급 경보 메시지의 부가 정보를 보여주기 위해서, EAS라는 이름으로 menu를 생성하여 디스플레이할 수 있다. NRT 서비스가 여러 개 있는 경우, EAS menu 선택 시, 긴급 경보와 관련한 NRT 서비스 목록을 보여주며, 사용자가 하나의 Service를 선택하면, 모바일 방송 수신기는 그와 관련된 컨텐츠 목록을 이름, 유효 기간, 및/또는 파일의 수신 상태 등의 정보들로 구성하여 화면에 디스플레이한다. 도 21을 참조하면, 사용자가 컨텐츠 목록에서 대피 지도 (evacuation map)를 선택한 경우, 해당 지도가 화면에 디스플레이된다.
도 22는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블의 신택스를 나타낸 도면이다.
모바일 방송 수신기 내에 긴급 경보 메시지 파일을 파싱할 수 있는 파서가 존재 하지 않는 다면 해당 파일에 포함된 정보를 해석할 수 없을 것이다. 그러나, 이러한 경우에도 긴급 경보 메시지를 해당 모바일 방송 수신기로 전달할 필요성이 있다.
본 발명의 다른 실시예에 따른 모바일 긴급 경보 테이블은, event_code 필드, event_urgency 필드, event_severity 필드, event_certainty 필드, EAS_message_type 필드, num_referenced_messages 필드, referenced_message_id 필드, event_expiry_time 필드, num_geo_code 필드, geo_code 필드, alert_ text_length 필드, 및/또는 alert_text() 디스크립터를 포함할 수 있다.
event_code 필드는 긴급 경보 메시지와 연관된 이벤트에 대한 코드를 나타낸다.
event_urgency 필드는 긴급 경보 메시지와 연관된 이벤트에 대한 응답의 긴급한 정도를 나타낸다.
event_severity 필드는 긴급 경보 메시지와 연관된 이벤트의 심각한 정도를 나타낸다.
event_certainty 필드는 긴급 경보 메시지와 연관된 이벤트의 확실성 정도를 나타낸다.
EAS_message_type 필드는 긴급 경보 메시지의 타입을 나타낸다.
num_referenced_messages 필드는 이미 전송되었던 긴급 경보 메시지들 중 현재 긴급 경보 메시지가 참조하는 메시지의 수를 나타낸다.
referenced_message_id 필드는 현재 긴급 경보 메시지가 참조하는 긴급 경보 메시지의 아이디를 나타낸다.
event_expiry_time 필드는 긴급 경보 메시지에 포함된 정보가 유효한 시간을 나타낸다.
num_geo_code 필드는 긴급 경보 메시지가 영향을 미치는 지역을 가리키는 코드의 수를 나타낸다.
geo_code 필드는 긴급 경보 메시지가 영향을 미치는 지역을 가리키는 코드를 나타낸다.
alert_ text_length 필드는 긴급 경보의 텍스트의 길이를 나타낸다.
alert_text() 필드는 긴급 경보의 텍스트를 가리킨다. 또는 alert_text()는 디스크립터 형태로 정의될 수 있으며, 이 경우, 긴급 경보의 텍스에 관한 추가 정보를 포함하는 디스크립터로 정의될 수 있다.
도 22에 도시되었으나, 설명되지 않은 모바일 긴급 경보 테이블의 다른 필드들에 대한 설명은, 전술한 본 발명의 일 실시예에 대한 설명으로 대체한다.
본 발명의 다른 실시예에 따르면, 긴급 경보 메시지 파일 내에 명시된 정보 자체를 포함하는 새로운 테이블을 정의하고 이를 전송함으로써, 긴급 경보 메시지 파일의 파서가 존재하지 않는 모바일 방송 수신기에서도 긴급 경보 메시지를 이용할 수 있는 효과가 있다.
도 23은 본 발명의 다른 실시예에 따른, event_urgency 필드, event_severity 필드, event_certainty 필드, 및 EAS_message_type 필드가 가질 수 있는 값에 대한 정의를 나타낸 도면이다.
event_urgency 필드는, 이 필드가 가지는 값에 따라, 긴급 경보가 과거의 이벤트에 관한 것을 나타내거나, 긴급 경보가 미래의 이벤트에 관한 것을 나타내거나, 긴급 경보가 예상되는 이벤트에 관한 것을 나타내거나, 긴급 경보가 현재 발생하고 있는 이벤트에 관한 것을 나타내거나, 긴급 경보가 나타내는 이벤트에 대한 긴급도가 알려지지 않았음을 나타낼 수 있다.
event_severity 필드는, 이 필드가 가지는 값에 따라, 긴급 경보의 이벤트의 심각성이 낮은 것을 나타내거나, 긴급 경보의 이벤트의 심각성이 중간 정도인 것을 나타내거나, 긴급 경보의 이벤트의 심각성이 심각한 정도인 것을 나타내거나, 긴급 경보의 이벤트의 심각성이 극도로 심각한 정도인 것을 나타내거나, 긴급 경보의 이벤트의 심각성이 알려지지 않았다는 것을 나타낼 수 있다.
event_certainty 필드는, 이 필드가 가지는 값에 따라, 긴급 경보와 관련된 이벤트가 발생할 가능성이 거의 없다는 것을 나타내거나, 긴급 경보와 관련된 이벤트가 발생할 가능성이 있다는 것을 나타내거나, 긴급 경보와 관련된 이벤트가 발생할 가능성이 높다는 것을 나타내거나, 긴급 경보와 관련된 이벤트가 현재 관측되고 있다는 것을 나타내거나, 긴급 경보와 관련된 이벤트가 발생할 가능성에 대하여 알려진 내용이 없다는 것을 나타낼 수 있다.
EAS_message_type 필드 이 필드가 가지는 값에 따라, 전송된 긴급 경보 메시지가 새로운 이벤트에 대한 긴급 경보 메시지임을 나타내거나, 전송된 긴급 경보 메시지가 이전에 전송되었던 메시지들 중 특정 referenced_message_id의 값을 가지는 메시지를 갱신하는 메시지임을 나타내거나, 전송된 긴급 경보 메시지가 특정 referenced_message_id의 값을 가지는 메시지를 취소하는 긴급 경보 메시지임을 나타내거나, 전송된 긴급 경보 메시지가 특정한 요청에 대한 응답 메시지임을 나타내거나, 전송된 긴급 경보 메시지에 에러가 있음을 나타내거나, 전송된 긴급 경보 메시지의 종류가 식별되지 않았음을 나타낼 수 있다.
도 24는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블을 나타낸 도면이다.
긴급 경보 메시지는 긴급 경보와 관련한 이벤트가 영향을 미치는 지역에 정확하게 전달될 수 있어야 한다. 따라서, 방송 수신기는 전송된 긴급 경보 메시지를 파싱하기 이전에 해당 메시지의 적합성을 검토할 필요성이 있다.
본 발명의 다른 실시예에 따른 모바일 긴급 경보 테이블은 num_FIPS_codes 필드, FIPS_codes 필드, EAS_event_code 필드, content_coding 필드, content_type 필드, 및/또는 NRT_service_id 필드를 포함할 수 있다.
num_FIPS_codes 필드는 긴급 경보 메시지가 영향을 미치는 지역을 가리키는 FIPS 코드의 수를 나타낸다.
FIPS_codes 필드는 긴급 경보 메시지가 영향을 미치는 지역을 가리키는 코드를 나타낸다. 해당 필드의 값은 FIPS 코드로 표현될 수 있다.
EAS_event_code 필드는 긴급 경보 메시지와 연관된 이벤트에 대한 코드를 나타낸다. 해당 필드는 UTF-8로 인코딩 된 3글자로 나타낼 수 있다.
content_coding 필드는 긴급 경보 메시지의 인코딩 스키마 (scheme)를 나타낸다. content_coding 필드는 이 필드가 가지는 값에 따라, 긴급 경보 메시지가 플레인 텍스트 (plain text) 임을 나타내거나, 긴급 경보 메시지가 gzip으로 압축되었음을 나타낼 수 있다.
content_type 필드는 긴급 경보 메시지의 형태를 나타낸다. content_type 필드는 이 필드가 가지는 값에 따라, CMAS 에서 사용하는 긴급 경보 메시지임을 나타내거나, CAP의 기준을 따르는 긴급 경보 메시지임을 나타낼 수 있다.
NRT_service_id 필드는 긴급 경보 메시지 또는 긴급 경보 메시지에 대한 부가 정보를 포함하는 NRT 서비스를 식별한다.
도 24에 도시되었으나, 설명되지 않은 모바일 긴급 경보 테이블의 다른 필드들에 대한 설명은, 전술한 본 발명의 다른 실시예에 대한 설명으로 대체한다.
본 발명의 다른 실시예에 따르면, 방송 수신기는 전송된 긴급 경보 메시지를 파싱하기 이전에 해당 메시지가 방송 수신기가 위치한 지역에 적합한 메시지인지 검토할 수 있으므로, 필요한 긴급 경보 메시지만을 시청자에게 전달하는 효과가 있다. 또한, 긴급 경보 메시지가 해당 지역에는 적합하지 않은 경우, 방송 수신기에서 불필요한 프로세싱 절차를 줄이는 효과가 있다.
도 25는 본 발명의 다른 실시예에 따른, 모바일 긴급 경보 테이블을 나타낸 도면이다.
긴급 경보 메시지와 연관된 콘텐츠를 NRT 서비스를 통하여 전송하기 위하여, SMT 에서 연관된 NRT 서비스에 대한 정보를 정의하는 것이 일반적이다. 그러나, SMT를 이용할 수 없는 경우에도 긴급 경보 메시지와 연관된 콘텐츠를 제공하는 NRT 서비스에 접근할 수 있는 방법이 필요하다.
본 발명의 다른 실시예에 따른 모바일 긴급 경보 테이블은 NRT_service_IP_address_flag 필드, 및/또는 SG_bootstrap_data() 필드/디스크립터를 포함할 수 있다.
NRT_service_IP_address_flag 필드는 긴급 경보 메시지에 대한 부가 콘텐츠를 전송하는 NRT 서비스와 연관된 IP 정보가 존재하는지 여부를 나타낸다.
SG_bootstrap_data() 필드는 NRT_service_IP_address_flag 필드가 긴급 경보 메시지에 대한 부가 콘텐츠를 전송하는 NRT 서비스와 연관된 IP 정보가 존재하는 것을 나타내는 경우, NRT 서비스를 획득하기 위한 IP 정보를 포함하는 신택스를 정의할 수 있다. SG_bootstrap_data()는 디스크립터 형태로 정의되어, NRT 서비스를 획득하기 위한 IP 정보를 포함하는 신택스를 포함할 수 있다. ATSC A/153의 Part 3에서 정의된 SG_delivery_network_type이 ‘0x02’ 이었을 때의 신택스를 포함할 수 있다.
본 발명의 다른 실시예에 따르면, SMT를 이용하지 않고도, 긴급 경보 메시지에 대한 부가 정보를 제공하는 NRT 서비스에 접근할 수 있는 효과가 있다.
도 26은 본 발명의 일 실시예에 따른, SMT의 확장을 통하여, 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터를 나타낸 도면이다.
하나의 ensemble 내에 A/V 서비스와 같이 개별 서비스로 재난 경보 서비스를 전송할 수 있다. 이 경우, SMT에서 재난 경보 서비스에 대한 시그널링을 수행할 필요가 있다.
본 발명의 일 실시예에 따른 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터는 descriptor_tag 필드, descriptor_length 필드, priority_level 필드, EAS_message_sent_type 필드, IP_address 필드, UDP_port_num 필드, 및/또는 service_related_nrt_service_id 필드를 포함할 수 있다.
descriptor_tag 필드는 해당 디스크립터가 재난 경보 서비스에 대한 디스크립터 임을 나타낸다.
descriptor_length 필드는 해당 필드 이후 해당 디스크립터의 전체 길이를 나타낸다.
priority_level 필드는 긴급 경보 메시지의 중요한 정도를 나타낸다. priority_level 필드는 이 필드가 가지는 값에 따라, 긴급 경보 메시지가 우선적으로 처리되어야 하는 메시지임을 나타내거나, 긴급 경보 메시지가 일반적은 처리 절차에 따라 처리되어야 하는 메시지임을 나타내거나, 긴급 경보 메시지의 처리에 대한 정의가 되지 않았음을 나타낼 수 있다.
EAS_message_sent_type 필드는 긴급 경보 메시지의 전송 형태를 나타낸다. EAS_message_sent_type 필드는 이 필드가 가지는 값에 따라, 긴급 경보 메시지가 별도의 테이블, 즉, 모바일 긴급 경보 테이블을 통해 전송됨을 나타내거나, 긴급 경보 메시지가 전송되는 방법이 정의되지 않았음을 나타내거나, 긴급 경보 메시지가 IP 데이터그램을 통해 전송됨을 나타낼 수 있다.
IP_address 필드는 EAS_message_sent_type 필드가 긴급 경보 메시지가 IP 데이터그램을 통해 전송됨을 나타내는 경우, 긴급 경보 메시지를 포함하는 IP 데이터그램의 IP 주소를 나타낸다.
UDP_port_num 필드는 EAS_message_sent_type 필드가 긴급 경보 메시지가 IP 데이터그램을 통해 전송됨을 나타내는 경우, 긴급 경보 메시지를 포함하는 IP 데이터그램을 전송하는 UDP/IP 스트림의 포트번호를 나타낸다.
service_related_nrt_service_id 필드는 전송되는 긴급 경보 메시지와 연관된 콘텐츠를 전송하는 NRT 서비스의 아이디를 나타낸다.
SMT에 포함된 디스크립터를 위한 확장 영역에 본 발명의 일 실시예에 따른 디스크립터가 포함될 수 있다. 여기서, SMT는 ATSC A/153에 기재된 형태를 참고하여 설명될 수 있다.
도 27은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터를 나타낸 도면이다.
긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터는 앙상블 레벨에서 정의될 수 있다.
본 발명의 다른 실시예에 따른 긴급 경보 서비스에 대한 시그널링을 하기 위한 디스크립터는 IP_version_flag 필드, 및/또는 ensemble_related_nrt_service_id 필드를 포함할 수 있다. 본 디스크립터에 포함되는 다른 필드들에 대한 설명은 전술한 디스크립터의 필드들에 대한 설명으로 대체한다.
IP_version_flag 필드는 ‘EAS_message_sent_type 필드가 긴급 경보 메시지가 IP 데이터그램을 통해 전송됨을 나타내는 경우, 긴급 경보 메시지를 포함하는 IP 데이터그램의 IP 주소 형식을 나타낸다. IP_version_flag 필드는 이 필드가 가지는 값에 따라, IP 데이터그램의 IP 주소 형식이 IPv4 형식 또는 IPv6 주소 형식을 사용함을 나타낼 수 있다.
ensemble_related_nrt_service_id 필드는 전송되는 긴급 경보 메시지와 연관된 콘텐츠를 전송하는 NRT 서비스의 아이디를 나타낸다.
본 발명에 따르면, 하나의 앙상블에 디스크립터를 정의하여 긴급 경보 서비스를 시그널링하여, SMT의 크기가 커지는 현상을 방지할 수 있는 효과가 있다.
도 28은 본 발명의 일 실시예에 따른, 하나의 컴포넌트로 긴급 경보 서비스를 제공하기 위한 시그널링을 나타낸 도면이다.
서비스 또는 앙상블 레벨뿐 아니라 하나의 컴포넌트로 긴급 경보 서비스를 전송할 수 있다. 이 경우, 새로운 component_type의 정의를 추가하고 FLUTE 컴포넌트 데이터 중 실질적으로 사용하는 필드만을 추출하여 새로운 M/H 컴포넌트 디스크립더를 정의할 수 있다.
component_type 필드는 그 값에 따라, M/H 컴포넌트가 긴급 경보 서비스에 대한 컴포넌트 임을 나타낼 수 있다.
MH_component_data() 디스크립터의 TSI 필드를 정의할 수 있으며, 이때, TSI 필드는 NRT 콘텐츠를 전송할 FLUTE 세션의 트랜스포트 세션에 대한 식별자를 나타낸다.
본 발명에서는 M/H 컴포넌트로서 긴급 경보 서비스를 전송하는 경우, 불필요한 필드는 전송하지 않음으로서, SMT 또는 앙상블 레벨의 시그널링을 위한 데이터 전송이 증대되는 현상을 방지할 수 있다.
도 29는 본 발명의 일 실시예에 따른, 긴급 경보 서비스 전송을 위한 emergency_alert_IP_datagram () 디스크립터를 나타낸 도면이다.
IP 데이터그램을 통해 전달되는 긴급 경보 서비스와 관련된 데이터를 수신기에서 정상적으로 분석하기 위하여, 해당 데이터는 일정한 형태를 가져야 한다. 그러므로 도 29에서 보는 바와 같은 신택스를 구성하는 것을 본 발명의 일 실시예로 한다.
IP_header 필드는 IP 데이터그램의 IP 헤더를 나타낸다.
UDP_header 필드는 IP 데이터그램의 UDP 헤더를 나타낸다.
payload_type_indicator 필드는 긴급 경보 메시지 전송을 위한 IP 데이터그램의 페이로드 타입을 나타낸다. payload_type_indicator 필드는 이 필드가 가지는 값에 따라, IP 데이터그램의 페이로드가 긴급 경보 메시지의 정보를 포함하는 별도의 신택스를 포함함을 나타내거나, IP 데이터그램의 페이로드가 긴급 경보 메시지 파일 자체를 포함하고 있음을 나타내거나, IP 데이터그램의 페이로드의 종류가 정의되지 않았음을 나타낼 수 있다.
본 발명의 일 실시예에서는, payload_type_indicator 필드가 IP 데이터그램의 페이로드가 긴급 경보 메시지의 정보를 포함하는 별도의 신택스를 포함함을 나타내는 경우, IP 데이터그램의 페이로드는 전술한 모바일 긴급 경보 테이블들 중 어느 하나의 형태의 테이블을 포함할 수 있다.
도 30은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스 전송을 위한 emergency_alert_IP_datagram () 디스크립터를 나타낸 도면이다.
payload_type_indicator 필드가 IP 데이터그램의 페이로드가 긴급 경보 메시지 파일 자체를 포함하고 있음을 나타내 경우, IP 데이터그램의 페이로드는 텍스트 또는/및 압축된 긴급 경보 메시지 파일(들)을 포함할 수 있다. 이와 같은 경우 페이로드는 일련의 message_header와 message_body 집합을 포함한다. message_header 는, 도 30에 도시된 바와 같이, message_body에 대한 상세한 정보 (message_body_length, message_gzipped_flag 등)을 포함할 수 있다.
본 발명의 다른 실시예에 따른, emergency_alert_IP_datagram () 디스크립터는 message_body_length 필드 및/또는 message_gzipped_flag 필드를 포함할 수 있다.
message_body_length 필드는 message_body의 길이를 나타낸다. message_body의 길이는 IP 데이터그램의 전체 길이를 초과할 수 없다.
message_gzipped_flag 필드는 message_body에 압축된 긴급 경보 메시지가 포함되었는지의 여부를 나타낸다. message_gzipped_flag 필드는 이 필드가 가지는 값에 따라, 페이로드에 포함된 긴급 경보 메시지가 gzip으로 압축되었음을 가리킬 수 있다.
emergency_alert_IP_datagram () 디스크립터에 포함되는 다른 필드 및/또는 디스크립터에 대한 설명은 전술한 emergency_alert_IP_datagram () 디스크립터에 대한 설명으로 대체한다.
도 31은 본 발명의 다른 실시예에 따른, 긴급 경보 서비스를 위한 ESG의 콘텐츠 프래그먼트를 나타낸 도면이다.
전술한 바와 같이, 긴급 경보 메시지와 관련된 콘텐츠를 NRT 서비스를 통해 전송할 수 있다. 이 경우, NRT 서비스를 통해 전송되는 콘텐츠는 ESG의 콘텐츠 프래그먼트 (content fragment) 를 통해 상세 정보를 전달할 수 있다.
ESG의 콘텐츠 프래그먼트는 emergency 엘레먼트 (element), 및/또는 weight 엘레먼트를 포함할 수 있다.
emergency 엘레먼트는 해당 콘텐츠가 긴급 경보 상황과 연관된 콘텐츠인지 여부를 나타낸다. 예를 들어, 이 콘텐츠가 긴급 경보 상황과 연관된 콘텐츠임을 나타내기 위하여 emergency 엘레먼트의 값이 true 로 설정될 수 있다.
weight 엘레먼트는 동일한 서비스에 속한 콘텐츠들의 표시 순서를 결정한다. 예를 들어, 해당 엘레먼트의 값이 낮을수록 해당 콘텐츠가 우선적으로 화면 상에 표시될 수 있다. 그러므로 화면 상에 우선적으로 콘텐츠를 표시하기 위하여는 웨이트 (weight) 엘레먼트의 값이 낮게 설정되어야 한다. 강제적으로 수신기 화면에 표시되어야 하는 콘텐츠의 경우, 이 엘레먼트의 값이 0으로 설정될 수 있다.
도 31에 도시되어 있으나, 설명되지 않은 엘레먼트들은 ATSC의 ESG 관련 내용을 참조하여 보충될 수 있다.
본 발명에 따르면, 방송 수신기는 ESG의 콘텐츠 프래그먼트를 이용하여, 긴급 경보 메시지와 연관된 콘텐츠에 대한 신속한 처리를 수행할 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 당업자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명의 영상 처리 방법은 네트워크 디바이스에 구비된 프로세서가 읽을 수 있는 기록매체에 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
그리고, 당해 명세서에서는 물건 발명과 방법 발명이 모두 설명되고 있으며, 필요에 따라 양발명의 설명은 보충적으로 적용될 수가 있다.
발명의 실시를 위한 형태는 전술한 바와 같이, 발명의 실시를 위한 최선의 형태로 상술되었다.
본 발명은 모바일 방송을 산업 전반에서 이용 가능하다.

Claims (18)

  1. 앙상블을 RS (Reed-Solomon) - CRC (Cyclic Redundancy Check) 인코딩하여 2차원의 데이터 프레임인 RS 프레임을 생성하는 RS 프레임 인코더, 여기서 상기 앙상블은 모바일 방송 서비스를 위한 모바일 데이터, 및 상기 모바일 방송 서비스에 대한 어세스 (access) 정보를 포함하는 서비스 시그널링 채널을 포함하는 것을 특징으로 함;
    상기 생성된 RS 프레임을 복수의 RS 프레임 포션으로 분할하는 RS 프레임 디바이더;
    모바일 방송의 전송 파라미터를 시그널링하기 위한 TPC (Transmission Parameter Channel), 및 상기 앙상블과 상기 방송 서비스 사이의 연결 정보를 포함하는 FIC (Fast Information Channel) 를 포함하는 시그널링 데이터를 생성하는 시그널링 인코더;
    상기 시그널링 데이터의 일부 및 상기 RS 프레임 포션을 포함하는 데이터 그룹을 생성하는 데이터 그룹 포맷터; 및
    상기 데이터 그룹을 포함하는 모바일 방송 신호를 생생하는 방송 신호 생성부;
    를 포함하며,
    상기 서비스 시그널링 채널은, 상기 앙상블에 의하여 전송되는 모바일 서비스에 대한 속성 정보를 포함하는 서비스 맵 테이블 (Service Map Table) 및 긴급 경보 서비스를 모바일 방송으로 전송하기 위한 정보를 포함하는 모바일 긴급 경보 테이블을 포함하며,
    상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지가 전송되는 방식을 가리키는 긴급 경보 메시지 전송 타입 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  2. 제 1 항에 있어서, 상기 긴급 경보 메시지 전송 타입 필드는,
    상기 긴급 경보 메시지가 상기 모바일 긴급 경보 테이블 내에 포함되어져 전송되거나, 상기 긴급 경보 메시지가 IP 데이터그램을 통하여 전송되는 것을 가리키는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  3. 제 1 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 서비스를 제공하는 물리적 RF 채널로 자동 튜닝을 하기 위한 물리적 RF 채널 번호를 가리키는 자동 튜닝 채널 번호 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  4. 제 1 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 메시지의 수신 대상자를 나타내는 긴급 경보 대상자 타입 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  5. 제 1 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보의 대상이 되는 긴급 상황을 식별하는 긴급 상황 타입 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  6. 제 1 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 메시지와 관련한 부가 정보를 제공하는 NRT 서비스를 식별하는 NRT 서비스 식별자 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  7. 제 1 항에 있어서, 상기 FIC는,
    복수의 FIC 세그먼트 형태로 상기 데이터 그룹에 포함되어 전송되며,
    상기 FIC 세그먼트는 FIC 세그먼트 헤더와 FIC 세그먼트 페이로드를 포함하며,
    상기 FIC 세그먼트 헤더는, 웨이크업 기능을 수행 가능한 모바일 방송 수신기가 자동으로 전원을 ON 하고, 긴급 경보 메시지를 제공하여야 하는지를 가리키는 웨이크업 지시자 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  8. 제 1 항에 있어서,
    상기 FIC는, FIC 헤더 및 FIC 페이로드를 포함하고,
    상기 FIC 페이로드는, 상기 앙상블 내에 포함되는 서비스 시그널링 채널을 통하여 상기 모바일 긴급 경보 테이블이 전송되는지 여부를 나타내는 EAT_ensemble_indicator 필드, 상기 앙상블에 포함되는 서비스 시그널링 채널의 버전 정보를 나타내는 MH_service_signaling_channel_version 필드, 및 상기 앙상블을 통하여 전송되는 모바일 서비스의 개수를 나타내는 num_MH_services 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  9. 제 8 항에 있어서, 상기 FIC 헤더는,
    확장된 FIC 헤더의 바이트가 웨이크업 기능을 위한 정보를 포함하는지 식별하는 EAS_wake_up_extended_info_Tag 필드 및 상기 웨이크업의 시그널링의 버전 정보를 나타내는 EAS_wake_up_version_number 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치.
  10. 앙상블을 RS (Reed-Solomon) - CRC (Cyclic Redundancy Check) 인코딩하여 2차원의 데이터 프레임인 RS 프레임을 생성하는 단계, 여기서 상기 앙상블은 모바일 방송 서비스를 위한 모바일 데이터, 및 상기 모바일 방송 서비스에 대한 어세스 (access) 정보를 포함하는 서비스 시그널링 채널을 포함하는 것을 특징으로 함;
    상기 생성된 RS 프레임을 복수의 RS 프레임 포션으로 분할하는 단계;
    모바일 방송의 전송 파라미터를 시그널링하기 위한 TPC (Transmission Parameter Channel), 및 상기 앙상블과 상기 방송 서비스 사이의 연결 정보를 포함하는 FIC (Fast Information Channel) 를 포함하는 시그널링 데이터를 생성하는 단계;
    상기 시그널링 데이터의 일부 및 상기 RS 프레임 포션을 포함하는 데이터 그룹을 생성하는 단계; 및
    상기 데이터 그룹을 포함하는 모바일 방송 신호를 생생하는 단계;
    를 포함하며,
    상기 서비스 시그널링 채널은, 상기 앙상블에 의하여 전송되는 모바일 서비스에 대한 속성 정보를 포함하는 서비스 맵 테이블 (Service Map Table) 및 긴급 경보 서비스를 모바일 방송으로 전송하기 위한 정보를 포함하는 모바일 긴급 경보 테이블을 포함하며,
    상기 모바일 긴급 경보 테이블은, 상기 긴급 경보 메시지가 전송되는 방식을 가리키는 긴급 경보 메시지 전송 타입 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  11. 제 10 항에 있어서, 상기 긴급 경보 메시지 전송 타입 필드는,
    상기 긴급 경보 메시지가 상기 모바일 긴급 경보 테이블 내에 포함되어져 전송되거나, 상기 긴급 경보 메시지가 IP 데이터그램을 통하여 전송되는 것을 가리키는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  12. 제 10 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 서비스를 제공하는 물리적 RF 채널로 자동 튜닝을 하기 위한 물리적 RF 채널 번호를 가리키는 자동 튜닝 채널 번호 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  13. 제 10 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 메시지의 수신 대상자를 나타내는 긴급 경보 대상자 타입 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  14. 제 10 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보의 대상이 되는 긴급 상황을 식별하는 긴급 상황 타입 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  15. 제 10 항에 있어서, 상기 모바일 긴급 경보 테이블은,
    상기 긴급 경보 메시지와 관련한 부가 정보를 제공하는 NRT 서비스를 식별하는 NRT 서비스 식별자 필드를 더 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  16. 제 10 항에 있어서, 상기 FIC는,
    복수의 FIC 세그먼트 형태로 상기 데이터 그룹에 포함되어 전송되며,
    상기 FIC 세그먼트는 FIC 세그먼트 헤더와 FIC 세그먼트 페이로드를 포함하며,
    상기 FIC 세그먼트 헤더는, 웨이크업 기능을 수행 가능한 모바일 방송 수신기가 자동으로 전원을 ON 하고, 긴급 경보 메시지를 제공하여야 하는지를 가리키는 웨이크업 지시자 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  17. 제 10 항에 있어서,
    상기 FIC는, FIC 헤더 및 FIC 페이로드를 포함하고,
    상기 FIC 페이로드는, 상기 앙상블 내에 포함되는 서비스 시그널링 채널을 통하여 상기 모바일 긴급 경보 테이블이 전송되는지 여부를 나타내는 EAT_ensemble_indicator 필드, 상기 앙상블에 포함되는 서비스 시그널링 채널의 버전 정보를 나타내는 MH_service_signaling_channel_version 필드, 및 상기 앙상블을 통하여 전송되는 모바일 서비스의 개수를 나타내는 num_MH_services 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
  18. 제 17 항에 있어서, 상기 FIC 헤더는,
    확장된 FIC 헤더의 바이트가 웨이크업 기능을 위한 정보를 포함하는지 식별하는 EAS_wake_up_extended_info_Tag 필드 및 상기 웨이크업의 시그널링의 버전 정보를 나타내는 EAS_wake_up_version_number 필드를 포함하는 것을 특징으로 하는 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 방법.
PCT/KR2013/000755 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법 Ceased WO2013129781A1 (ko)

Priority Applications (14)

Application Number Priority Date Filing Date Title
KR1020137011187A KR101448663B1 (ko) 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
KR1020137011383A KR101947554B1 (ko) 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
CN201380000196.8A CN103416080B (zh) 2012-03-02 2013-01-30 经由移动广播提供紧急报警服务的方法及其设备
KR1020197016622A KR102114625B1 (ko) 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
KR1020197003570A KR101989900B1 (ko) 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
US13/882,940 US9219556B2 (en) 2012-03-02 2013-01-30 Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
CA2815707A CA2815707C (en) 2012-03-02 2013-01-30 Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
US13/875,838 US9236964B2 (en) 2012-03-02 2013-05-02 Providing an emergency alert service via a mobile broadcasting
US14/962,737 US9516486B2 (en) 2012-03-02 2015-12-08 Apparatus and method for processing an emergency alert service
US15/336,560 US9929820B2 (en) 2012-03-02 2016-10-27 Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
US15/894,200 US10171192B2 (en) 2012-03-02 2018-02-12 Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
US16/216,761 US10615896B2 (en) 2012-03-02 2018-12-11 Providing an emergency alert service via a mobile broadcasting
US16/806,725 US11032015B2 (en) 2012-03-02 2020-03-02 Method and apparatus for providing an emergency alert service via a mobile broadcasting
US17/329,642 US11515954B2 (en) 2012-03-02 2021-05-25 Method and apparatus for providing an emergency alert service via a mobile broadcasting

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261605769P 2012-03-02 2012-03-02
US61/605,769 2012-03-02
US201261617654P 2012-03-29 2012-03-29
US61/617,654 2012-03-29
US201261643354P 2012-05-07 2012-05-07
US61/643,354 2012-05-07

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US13/882,940 A-371-Of-International US9219556B2 (en) 2012-03-02 2013-01-30 Method of providing an emergency alert service via a mobile broadcasting and apparatus therefor
US13/875,838 Continuation US9236964B2 (en) 2012-03-02 2013-05-02 Providing an emergency alert service via a mobile broadcasting

Publications (1)

Publication Number Publication Date
WO2013129781A1 true WO2013129781A1 (ko) 2013-09-06

Family

ID=49082937

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2013/000755 Ceased WO2013129781A1 (ko) 2012-03-02 2013-01-30 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법

Country Status (5)

Country Link
US (8) US9219556B2 (ko)
KR (4) KR102114625B1 (ko)
CN (3) CN103338093B (ko)
CA (1) CA2815707C (ko)
WO (1) WO2013129781A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016182358A1 (ko) * 2015-05-12 2016-11-17 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9843845B2 (en) 2012-11-28 2017-12-12 Sinclair Broadcast Group, Inc. Terrestrial broadcast market exchange network platform and broadcast augmentation channels for hybrid broadcasting in the internet age
KR102129804B1 (ko) * 2013-02-03 2020-07-03 엘지전자 주식회사 방송 시스템을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
US9191209B2 (en) 2013-06-25 2015-11-17 Google Inc. Efficient communication for devices of a home network
US9531704B2 (en) 2013-06-25 2016-12-27 Google Inc. Efficient network layer for IPv6 protocol
JP2015061195A (ja) * 2013-09-18 2015-03-30 ソニー株式会社 送信装置及び送信方法、受信装置及び受信方法、並びにコンピューター・プログラム
GB2519140B (en) * 2013-10-11 2021-03-10 Advanced Risc Mach Ltd Cumulative error detection in data transmission
JP2015104055A (ja) * 2013-11-27 2015-06-04 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2015102395A1 (en) 2014-01-02 2015-07-09 Lg Electronics Inc. Broadcast receiving device and operating method thereof
KR20150088485A (ko) * 2014-01-24 2015-08-03 한국전자통신연구원 방송 시스템을 이용한 재해 조기경보 방법 및 시스템
EP3103205A4 (en) 2014-02-03 2017-06-28 LG Electronics Inc. Broadcast receiving device and operating method thereof
EP3108464A4 (en) * 2014-02-20 2018-05-02 LG Electronics Inc. Broadcast reception device and operating method thereof, and broadcast transmission device and operating method thereof
KR101823481B1 (ko) * 2014-03-03 2018-03-14 엘지전자 주식회사 방송 신호를 송신 및 수신하기 위한 장치 및 방법
KR20150120598A (ko) * 2014-04-17 2015-10-28 한국전자통신연구원 방송 시스템을 이용한 재난 방송 중계 방법 및 장치
WO2015199468A1 (ko) * 2014-06-26 2015-12-30 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
US10582255B2 (en) 2014-06-30 2020-03-03 Lg Electronics Inc. Broadcast receiving device, method of operating broadcast receiving device, linking device for linking to broadcast receiving device, and method of operating linking device
KR101779434B1 (ko) 2014-07-17 2017-09-18 엘지전자 주식회사 방송 송신 장치, 방송 송신 장치의 데이터 처리 방법, 방송 수신 장치 및 방송 수신 장치의 데이터 처리 방법
KR20170051437A (ko) 2014-08-07 2017-05-11 코히어런트 로직스, 인코포레이티드 멀티-파티션 라디오 프레임
KR102248699B1 (ko) 2014-08-07 2021-05-07 원 미디어, 엘엘씨 유연한 직교 주파수 분할 멀티플렉싱 물리 전송 데이터 프레임의 동적 구성 방법
CN110266426B (zh) 2014-08-25 2021-03-05 第一媒体有限责任公司 灵活的正交频分复用phy传输数据帧前导码的动态配置
US10079649B2 (en) 2014-09-11 2018-09-18 Lg Electronics Inc. Broadcast signal transmission apparatus, broadcast signal receiving apparatus, broadcast signal transmission method, and broadcast signal receiving method
KR101812186B1 (ko) * 2014-09-25 2017-12-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
EP3211905B1 (en) * 2014-10-21 2019-04-03 Sony Corporation Reception device, reception method, transmission device, and transmission method
WO2016068406A1 (en) * 2014-10-27 2016-05-06 Samsung Electronics Co., Ltd. Additional channels using preamble symbols
GB2531725B (en) * 2014-10-27 2017-10-18 Samsung Electronics Co Ltd Additional channels using preamble symbols
US10637595B2 (en) 2015-03-01 2020-04-28 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
CN112737727B (zh) 2015-03-09 2024-04-02 第一媒体有限责任公司 系统发现与信令
JP6913633B2 (ja) 2015-04-08 2021-08-04 ワン メディア，エルエルシー 先進的なデータ・セル・リソース・マッピング
US9826483B2 (en) * 2015-06-22 2017-11-21 Intel Corporation Apparatus, system and method of communicating a wakeup packet
WO2017038482A1 (ja) * 2015-09-01 2017-03-09 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
TW201725878A (zh) * 2015-09-14 2017-07-16 Sony Corp 受訊裝置、送訊裝置及資料處理方法
US9693210B2 (en) 2015-10-16 2017-06-27 At&T Intellectual Property I, L.P. Customizing wireless emergency alert messages using network analytics
US9820121B2 (en) 2015-12-15 2017-11-14 At&T Intellectual Property I, L.P. Processing wireless emergency alert messages with uniform resource locators to reduce cellular network load
KR102512346B1 (ko) 2016-04-07 2023-03-22 싱클레어 브로드캐스트 그룹, 인코포레이티드 인터넷과 연계되고 신흥 5g 네트워크 아키텍처들을 향하는 차세대 지상 브로드캐스팅 플랫폼
CA3035658C (en) * 2016-09-09 2023-01-24 Sharp Kabushiki Kaisha Systems and methods for signaling of emergency alert messages
US11281993B2 (en) 2016-12-05 2022-03-22 Apple Inc. Model and ensemble compression for metric learning
US10338188B2 (en) * 2017-06-22 2019-07-02 Microsoft Technology Licensing, Llc Location assistance with a dynamically updated beacon payload from an electronic device
CN110969817A (zh) * 2018-09-28 2020-04-07 比亚迪股份有限公司 列车报警处理方法、装置及移动设备
RU2697823C1 (ru) * 2018-12-24 2019-08-21 Общество с ограниченной ответственностью "Научно-производственная фирма "САД-КОМ" Способ оповещения населения, система оповещения населения для реализации этого способа и радиоприемное устройство для реализации этого способа
EP3716479A1 (en) 2019-03-26 2020-09-30 Bang & Olufsen A/S A method for sampling rate conversion
KR102384207B1 (ko) * 2019-04-25 2022-04-07 한국전자통신연구원 재난 경보 시스템 및 그 방법
US10805982B1 (en) * 2019-04-29 2020-10-13 Blackberry Limited Supported extended emergency information type
KR102557447B1 (ko) 2021-10-26 2023-07-19 서울시립대학교 산학협력단 재난경보 서비스 방법 및 시스템
KR102431442B1 (ko) * 2021-12-22 2022-08-11 한국방송공사 사용자 환경에 따라 사용자에게 표시할 재난정보를 분류할 수 있는 재난정보 수신장치
KR102658009B1 (ko) * 2022-10-25 2024-04-15 동아대학교 산학협력단 이종 통신 기반 재난 상황 알림 방법 및 이를 지원하는 시스템
KR102757451B1 (ko) * 2023-03-30 2025-01-21 주식회사 모우씨앤아이 재난경보 서비스를 위한 aeat 수신기 및 그를 위한 제어방법

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090011138A (ko) * 2007-07-25 2009-02-02 주식회사 원포유텔레콤 지상파 디엠비를 이용한 재난경보 방법 및 시스템
KR20090031267A (ko) * 2007-09-21 2009-03-25 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR20100126192A (ko) * 2009-05-21 2010-12-01 삼성전자주식회사 디지털 방송 송신기, 디지털 방송 수신기 및 그들의 스트림 구성 및 처리 방법
US20110081882A1 (en) * 2009-10-01 2011-04-07 At&T Mobility Ii, Llc Systems and Methods for Mapping Commercial Mobile Alert Service Message Attributes to a Cell Broadcast Interface
KR20110105951A (ko) * 2010-03-22 2011-09-28 삼성전자주식회사 모바일 디지털 방송 시스템에서 경보 서비스 제공 방법 및 장치

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6543051B1 (en) * 1998-08-07 2003-04-01 Scientific-Atlanta, Inc. Emergency alert system
KR100585933B1 (ko) * 2003-08-20 2006-06-01 한국전자통신연구원 디지털 멀티미디어 방송 시스템 및 그 방법
US20050086685A1 (en) * 2003-10-20 2005-04-21 New Technology Management Inc. Method and system for providing emergency alert system messages in an internet protocol
US7119675B2 (en) * 2004-01-27 2006-10-10 Matsushita Electric Industrial Co., Ltd. Emergency alert service
US20060026227A1 (en) * 2004-07-30 2006-02-02 Jay Shaughnessy Agent administration console software for servicing failed requests
US7616942B2 (en) * 2004-08-23 2009-11-10 Karl Maurice W Alert system and personal apparatus
WO2008008408A2 (en) * 2006-07-12 2008-01-17 Spectrarep System and method for managing emergency notifications over a network
KR101259118B1 (ko) * 2007-02-23 2013-04-26 엘지전자 주식회사 방송 신호 송신 장치 및 방법
US8027659B1 (en) * 2007-07-27 2011-09-27 At&T Mobility Ii Llc Configuration of alert messages for emergency alert system broadcast
JP4555393B2 (ja) 2008-10-29 2010-09-29 日本放送協会 地上デジタルテレビジョン放送における緊急速報の受信機
US8813121B2 (en) * 2008-12-02 2014-08-19 At&T Intellectual Property I, L.P. Delaying emergency alert system messages
US20100162300A1 (en) * 2008-12-19 2010-06-24 At&T Intellectual Property I,L.P. Methods And Systems For Creating An Emergency Alert Channel
US8336067B2 (en) * 2009-02-13 2012-12-18 Centurylink Intellectual Property Llc System and method for bypassing an emergency alert break-in
WO2010107213A2 (ko) * 2009-03-15 2010-09-23 엘지전자 주식회사 송/수신 시스템 및 방송 신호 처리 방법
WO2011053603A1 (en) * 2009-10-26 2011-05-05 Channel One, LLC Alert network systems and methods
CN101866972A (zh) 2010-05-18 2010-10-20 扬州旭博光伏科技有限公司 太阳能电池与散热器一体化组件
US8949885B2 (en) * 2010-07-30 2015-02-03 Echostar Technologies L.L.C. Systems, methods and apparatus for transmitting weather information in a television distribution network

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20090011138A (ko) * 2007-07-25 2009-02-02 주식회사 원포유텔레콤 지상파 디엠비를 이용한 재난경보 방법 및 시스템
KR20090031267A (ko) * 2007-09-21 2009-03-25 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR20100126192A (ko) * 2009-05-21 2010-12-01 삼성전자주식회사 디지털 방송 송신기, 디지털 방송 수신기 및 그들의 스트림 구성 및 처리 방법
US20110081882A1 (en) * 2009-10-01 2011-04-07 At&T Mobility Ii, Llc Systems and Methods for Mapping Commercial Mobile Alert Service Message Attributes to a Cell Broadcast Interface
KR20110105951A (ko) * 2010-03-22 2011-09-28 삼성전자주식회사 모바일 디지털 방송 시스템에서 경보 서비스 제공 방법 및 장치

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016182358A1 (ko) * 2015-05-12 2016-11-17 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법

Also Published As

Publication number Publication date
US20160094970A1 (en) 2016-03-31
KR101448663B1 (ko) 2014-10-08
US9236964B2 (en) 2016-01-12
KR20130117778A (ko) 2013-10-28
KR20190017060A (ko) 2019-02-19
US20180175952A1 (en) 2018-06-21
CN103338093A (zh) 2013-10-02
KR101989900B1 (ko) 2019-06-17
KR102114625B1 (ko) 2020-05-25
US11032015B2 (en) 2021-06-08
US9929820B2 (en) 2018-03-27
CN106998536A (zh) 2017-08-01
US11515954B2 (en) 2022-11-29
CN106998536B (zh) 2020-06-16
US20130242847A1 (en) 2013-09-19
CN103416080B (zh) 2016-10-19
CA2815707C (en) 2016-07-05
US9219556B2 (en) 2015-12-22
CN103338093B (zh) 2017-07-21
US20170048012A1 (en) 2017-02-16
CN103416080A (zh) 2013-11-27
KR101947554B1 (ko) 2019-02-13
US20210281338A1 (en) 2021-09-09
US20190109657A1 (en) 2019-04-11
US10171192B2 (en) 2019-01-01
CA2815707A1 (en) 2013-09-02
US10615896B2 (en) 2020-04-07
KR20190069612A (ko) 2019-06-19
US9516486B2 (en) 2016-12-06
US20200204278A1 (en) 2020-06-25
KR20140120809A (ko) 2014-10-14
US20150036586A1 (en) 2015-02-05

Similar Documents

Publication Publication Date Title
WO2013129781A1 (ko) 모바일 방송을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
WO2014119961A1 (ko) 방송 시스템을 통하여 긴급 경보 서비스를 제공하는 장치 및 방법
WO2012161552A2 (ko) 송/수신 시스템 및 방송 신호 처리 방법
WO2011056025A2 (en) Mobile service reception method and mobile service receiver
WO2017204546A1 (ko) 방송 신호 송수신 장치 및 방법
WO2010021526A2 (en) A method for processing additional information related to an announced service or content in an nrt service and a broadcast receiver
WO2010107167A1 (en) Transmitting/receiving system and method of processing data in the transmitting/receiving system
WO2009151266A2 (ko) 서비스 제공 방법 및 모바일 방송 수신기
WO2009154418A2 (en) Transmitting/receiving system and method of processing data in the transmitting/receiving system
WO2010068043A2 (en) Method for processing targeting descriptor in non-real-time receiver
WO2014025207A1 (en) A method and an apparatus for processing a broadcast signal including an interactive broadcast service
WO2012091371A1 (en) Method for transmitting broadcast service, method for receiving the broadcasting service, and apparatus for receiving the broadcasting service
WO2015008986A1 (ko) 하이브리드 방송 시스템의 방송 신호를 송신/수신하는 방법 및 장치
WO2009151267A2 (ko) 서비스 제공 방법 및 방송 수신기
WO2014209057A1 (ko) 지상파 방송망과 인터넷 프로토콜망 연동 기반의 하이브리드 방송 시스템에서 방송 서비스의 송수신 방법 및 장치
WO2010058958A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2017014586A1 (ko) 방송 신호 송수신 장치 및 방법
WO2010068033A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010082783A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2010068040A2 (ko) 비실시간 서비스 처리 방법 및 방송 수신기
WO2017007224A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
WO2016186407A1 (ko) 방송 신호 송수신 장치 및 방법
WO2016171496A1 (ko) 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
EP3114814A1 (en) Apparatus and methods for transmitting / receiving a broadcast signal
WO2017209514A1 (ko) 방송 신호 송수신 장치 및 방법

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 20137011187

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13882940

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2815707

Country of ref document: CA

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13755227

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13755227

Country of ref document: EP

Kind code of ref document: A1