特許 6204502 放送システムを介して緊急警報サービスを提供する装置及び方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6204502

(24)【登録日】2017年9月8日

(45)【発行日】2017年9月27日

(54)【発明の名称】放送システムを介して緊急警報サービスを提供する装置及び方法

(51)【国際特許分類】

   H04N 21/434 20110101AFI20170914BHJP

   H04N 21/488 20110101ALI20170914BHJP

   H04H 20/59 20080101ALI20170914BHJP

   H04H 20/93 20080101ALI20170914BHJP

   H04H 60/37 20080101ALI20170914BHJP

   H04H 60/42 20080101ALI20170914BHJP

   G08B 27/00 20060101ALI20170914BHJP

   H04H 60/82 20080101ALI20170914BHJP

   H04W 4/06 20090101ALI20170914BHJP

【ＦＩ】

   H04N21/434

   H04N21/488

   H04H20/59

   H04H20/93

   H04H60/37

   H04H60/42

   G08B27/00 C

   H04H60/82

   H04W4/06 110

【請求項の数】4

【全頁数】29

(21)【出願番号】特願2015-555918(P2015-555918)

(86)(22)【出願日】2014年2月3日

(65)【公表番号】特表2016-514386(P2016-514386A)

(43)【公表日】2016年5月19日

(86)【国際出願番号】KR2014000908

(87)【国際公開番号】WO2014119961

(87)【国際公開日】20140807

【審査請求日】2015年8月3日

(31)【優先権主張番号】61/760,158

(32)【優先日】2013年2月3日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】502032105

【氏名又は名称】エルジー エレクトロニクス インコーポレイティド

(74)【代理人】

【識別番号】100099759

【弁理士】

【氏名又は名称】青木 篤

(74)【代理人】

【識別番号】100092624

【弁理士】

【氏名又は名称】鶴田 準一

(74)【代理人】

【識別番号】100114018

【弁理士】

【氏名又は名称】南山 知広

(74)【代理人】

【識別番号】100165191

【弁理士】

【氏名又は名称】河合 章

(74)【代理人】

【識別番号】100151459

【弁理士】

【氏名又は名称】中村 健一

(72)【発明者】

【氏名】カク ミンソン

(72)【発明者】

【氏名】キム チョンウ

【審査官】 富樫 明

(56)【参考文献】

【文献】 国際公開第２０１２／１６１５５２（ＷＯ，Ａ２）

【文献】 特開２００７−０８１５１６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２００９／０１７０４６７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２００９／０２５２２５３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００−２１／８５８

Ｇ０８Ｂ ２７／００

Ｈ０４Ｈ ２０／５９

Ｈ０４Ｈ ２０／９３

Ｈ０４Ｈ ６０／３７

Ｈ０４Ｈ ６０／４２

Ｈ０４Ｈ ６０／８２

Ｈ０４Ｗ ４／０６

(57)【特許請求の範囲】

【請求項1】

放送受信機において放送信号を処理する方法であって、
前記放送信号を受信するステップと、
前記放送信号に含まれた緊急警報テーブルをパーシングするステップであって、前記緊急警報テーブルは、緊急警報メッセージ、前記緊急警報メッセージ内で参照されるリッチメディアコンテンツにアクセスするためのアクセス情報、及び前記緊急警報メッセージを識別するためのメッセージ識別情報を含む、ステップと、
前記メッセージ識別情報に基づいて、前記緊急警報テーブルから前記緊急警報メッセージを獲得するステップと、
前記アクセス情報に基づいて、前記放送信号から前記リッチメディアコンテンツを獲得するステップと、
を有し、
前記緊急警報テーブルは、前記リッチメディアコンテンツのサイズ情報と前記リッチメディアコンテンツのコンテンツタイプ情報を更に含む、放送信号処理方法。

【請求項2】

前記リッチメディアコンテンツは、前記緊急警報メッセージに関連した追加情報を含む、請求項１に記載の放送信号処理方法。

【請求項3】

前記リッチメディアコンテンツは、イメージ、オーディオ、ビデオの少なくとも１つを含む、請求項２に記載の放送信号処理方法。

【請求項4】

前記リッチメディアコンテンツは、放送ネットワークを介して受信される、請求項１に記載の放送信号処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、放送システムに関する。より詳細には、本発明は、放送システムを介して緊急警報サービスを提供する装置及び方法に関する。

【背景技術】

【0002】

携帯機器の発展とともに、モバイル機器でも放送の送／受信が可能になった。したがって、モバイル放送環境に適した放送信号送信システムが構築されている。併せて、全世界的に人為的あるいは自然的な災難が発生している。このような災難に対しては、迅速な災難情報の提供が必要である。モバイル放送の場合、ユーザーが放送を受信する位置が可変的であり、災難は位置との連関性が大きいので、モバイル放送を介して災難に対する情報を提供することが効果的である。しかし、現在のモバイル放送システムにおいては、災難に対する情報を提供する技術が開発されていない状況にある。

【0003】

また、放送受信機の特性上、一定のサービスを受信できない場合が発生し得る。例えば、最近開発されるＮＲＴ（Ｎｏｎ Ｒｅａｌ Ｔｉｍｅ）放送サービス及び／またはＥＳＧ（Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）サービスは、該当のサービスが開発されて商用化される前に製作された旧式の放送受信機ではサービスされ得ない。このようなサービスを介して災難に対する情報を提供する技術は考慮されているが、この場合、旧式の放送受信機では災難に対する情報を全く受信できないという問題がある。

【発明の概要】

【発明が解決しようとする課題】

【0004】

本発明が達成しようとする課題は、上述した問題を解決するためのものであって、放送システムで効率的な緊急警報サービスを提供することにある。

【0005】

さらに、本発明が達成しようとする課題は、固定放送及びモバイル放送が統合された放送システムで効率的な緊急警報サービスを提供することにある。

【0006】

さらに、本発明が達成しようとする課題は、旧式の放送受信機でも緊急警報サービスを受けられるようにすることにある。

【課題を解決するための手段】

【0007】

本発明の一実施例に係る放送システムを用いた緊急警報コンテンツ受信方法は、放送信号を受信すること、放送信号に含まれた緊急警報テーブルをパーシングすること―ここで、前記緊急警報テーブルは、緊急警報メッセージ、及び前記緊急警報メッセージと関連する緊急警報コンテンツに対する情報をシグナリングする緊急警報コンテンツ伝送構造ディスクリプタを含み、ここで、前記緊急警報コンテンツ伝送構造ディスクリプタは、前記緊急警報コンテンツを伝送するＩＰデータグラムのＩＰ住所情報を含む。―、前記ＩＰ住所情報のＩＰデータグラムを受信すること、及び前記ＩＰデータグラムをデコーディングすることによって前記緊急警報コンテンツを再生することを含む。

【0008】

好ましくは、前記緊急警報コンテンツ伝送構造ディスクリプタは、前記緊急警報メッセージと関連する前記緊急警報コンテンツを識別するコンテンツＩＤ情報、前記緊急警報コンテンツの有効期間情報、及び前記緊急警報メッセージと関連する緊急警報コンテンツの個数を示す個数情報をさらに含む。

【0009】

好ましくは、前記緊急警報コンテンツ伝送構造ディスクリプタは、前記緊急警報コンテンツが提供されるべき地域を識別する地域情報、及び前記地域情報の個数を示す地域個数情報をさらに含む。

【0010】

好ましくは、前記緊急警報コンテンツを伝送するＩＰデータグラムは、前記緊急警報コンテンツと関連する緊急警報メッセージを識別する緊急警報メッセージＩＤ情報をさらに含む。

【0011】

好ましくは、前記緊急警報コンテンツを伝送するＩＰデータグラムは、前記緊急警報コンテンツを識別するコンテンツＩＤ情報、及び前記緊急警報コンテンツのデータをさらに含む。

【0012】

好ましくは、前記緊急警報コンテンツを伝送するＩＰデータグラムは、前記ＩＰデータグラムのシーケンス番号を示す現在のシーケンス番号情報、及び前記緊急警報コンテンツのためのＩＰデータグラムの最後のシーケンス番号を示す最後のシーケンス番号情報をさらに含む。

【0013】

本発明の他の実施例に係る放送システムを用いた緊急警報コンテンツ受信方法は、放送信号を受信すること、放送信号に含まれた緊急警報テーブルをパーシングすること―ここで、前記緊急警報テーブルは、緊急警報メッセージを伝送する第１のＩＰデータグラムのＩＰ住所を識別する第１のＩＰ住所情報を含み、前記第１のＩＰ住所情報を用いて前記第１のＩＰデータグラムを受信すること―ここで、前記第１のＩＰデータグラムは、前記緊急警報メッセージと関連する緊急警報コンテンツに対する情報をシグナリングする緊急警報コンテンツ伝送構造エレメントを含み、ここで、前記緊急警報コンテンツ伝送構造エレメントは、前記緊急警報コンテンツを伝送する第２のＩＰデータグラムのＩＰ住所を識別する第２のＩＰ住所情報を含む。―、前記第２のＩＰ住所情報を用いて前記第２のＩＰデータグラムを受信すること、及び前記第２のＩＰデータグラムをデコーディングすることによって前記緊急警報コンテンツを再生することを含む。

【0014】

好ましくは、前記緊急警報コンテンツ伝送構造エレメントは、前記緊急警報メッセージと関連する前記緊急警報コンテンツを識別するコンテンツＩＤ情報、前記緊急警報コンテンツの有効期間情報、及び前記緊急警報メッセージと関連する緊急警報コンテンツの個数を示す個数情報をさらに含む。

【0015】

好ましくは、前記緊急警報コンテンツ伝送構造エレメントは、前記緊急警報コンテンツが提供されるべき地域を識別する地域情報、及び前記地域情報の個数を示す地域個数情報をさらに含む。

【0016】

好ましくは、前記第１のＩＰデータグラムは、前記緊急警報メッセージを識別する第１の緊急警報メッセージＩＤ情報、前記緊急警報メッセージの長さを示す長さ情報、及び前記緊急警報メッセージのデータをさらに含む。

【0017】

好ましくは、前記第２のＩＰデータグラムは、前記緊急警報コンテンツと関連する緊急警報メッセージを識別する第２の緊急警報メッセージＩＤ情報をさらに含む。

【0018】

好ましくは、前記第２のＩＰデータグラムは、前記緊急警報コンテンツを識別するコンテンツＩＤ情報、及び前記緊急警報コンテンツのデータをさらに含む。

【0019】

好ましくは、前記第２のＩＰデータグラムは、前記第２のＩＰデータグラムのシーケンス番号を示す現在のシーケンス番号情報、及び前記緊急警報コンテンツのための第２のＩＰデータグラムの最後のシーケンス番号を示す最後のシーケンス番号情報をさらに含む。

【0020】

好ましくは、前記緊急警報コンテンツ伝送構造エレメントは、前記第２のＩＰデータグラムがＦＬＵＴＥ方式で伝送されるか否かを識別する緊急警報コンテンツＩＰデータグラムタイプ情報をさらに含む。

【0021】

好ましくは、前記緊急警報コンテンツ伝送構造エレメントは、前記緊急警報コンテンツの原本状態のサイズ情報、前記緊急警報コンテンツの原本状態のコンテンツタイプ情報、前記緊急警報コンテンツが伝送のために変形した状態のサイズ情報、及び前記緊急警報コンテンツが伝送のために変形した状態のコンテンツタイプ情報をさらに含む。

【0022】

本発明の一実施例に係る緊急警報コンテンツを受信する受信機は、上述したそれぞれの方法を行う一つ以上の装置またはユニットを含む。

【発明の効果】

【0023】

本発明によると、ＥＳＧ／ＮＲＴを支援しない受信機（または旧式の受信機）で緊急警報サービスを含む双方向コンテンツを受信／再生できるという効果がある。

【0024】

本発明によると、既存の他のシグナリングテーブル（例えば、ＳＭＴ（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ））のサイズを減少させるという効果がある。

【図面の簡単な説明】

【0025】

【図1】本発明の一実施例に係る統合公共警報システムの構造を示した図である。

【図2】本発明の一実施例に係る警報ネットワークを示した図である。

【図3】本発明の一実施例に係る伝送システムを示した図である。

【図4】本発明の一実施例に係るシグナリングエンコーダーを示した図である。

【図5】本発明の一実施例に係るアンサンブルの構造を示した図である。

【図6】本発明の一実施例に係るモバイル緊急警報テーブルのシンタックスを示した図である。

【図7】本発明の一実施例に係るＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値による説明を示した図である。

【図8】本発明の一実施例に係る緊急警報コンテンツを伝送するＩＰデータグラムの構造を示した図である。

【図9】本発明の一実施例に係る緊急警報コンテンツをシグナリングするシンタックスを示した図である。

【図10】本発明の他の実施例に係る緊急警報テーブルを示した図である。

【図11】本発明の他の実施例に係るＥＡＳ＿ｍａｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値による説明を示した図である。

【図12】本発明の一実施例に係る緊急警報ＩＰデータグラムを示した図である。

【図13】本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）を示した図である。

【図14】本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントの値による説明を示した図である。

【図15】本発明の一実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【図16】本発明の他の実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【図17】本発明の他の実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【図18】本発明の一実施例に係る放送受信機を示した図である。

【発明を実施するための形態】

【0026】

以下、添付の各図面及び添付の各図面に記載した各内容を参照して本発明の実施例を詳細に説明するが、本発明が各実施例によって制限または限定されることはない。

【0027】

本明細書で使用される用語としては、本発明での機能を考慮しながら可能な限り現在広く使用される一般的な用語を選択したが、これは、当分野に携わる技術者の意図、慣例または新たな技術の出現などによって変わり得る。また、特定の場合は、出願人が任意に選定した用語もあり、この場合、該当する発明の説明部分でその意味を記載すべきであろう。したがって、本明細書で使用される用語は、単純な用語の名称ではなく、その用語が有する実質的な意味と本明細書の全般にわたった内容に基づいて解釈すべきであることを明らかにしておく。

【0028】

本発明に対する理解と説明の便宜のために、用語及び略語に対して下記のように定義する。

【0029】

発明の詳細な説明で使用される用語のうち、メインサービスデータ（ｍａｉｎ ｓｅｒｖｉｃｅ ｄａｔａ）は、固定放送受信システム（ｆｉｘｅｄ ｂｒｏａｄｃａｓｔ ｒｅｃｅｉｖｉｎｇ ｓｙｓｔｅｍ）によって受信されるデータに該当し、オーディオ／ビデオデータを含むことができる。より詳細には、メインサービスデータは、高画質（ＨＤ；Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）または一般画質（ＳＤ；Ｓｔａｎｄａｒｄ Ｄｅｆｉｎｉｔｉｏｎ）オーディオ／ビデオデータを含むことができ、放送のための多様な種類のデータを含むことができる。

【0030】

既知データ（ｋｎｏｗｎ ｄａｔａ）は、放送受信システムと放送送信システムとの間の約束によって予め知られているデータに該当する。

【0031】

「ＭＨ」という用語は、ｍｏｂｉｌｅ／ｈａｎｄｈｅｌｄに該当する用語であって、固定タイプシステムとは反対の用語である。より詳細には、ＭＨサービスデータ（またはモバイルサービスデータ）は、モバイルまたはポータブルシステムで使用されるいずれかの種類のデータを含むことができる。したがって、本発明の一実施例に係るモバイルサービスデータはＭＨサービスデータに限定されない。

【0032】

モバイルサービスデータは、プログラム実行ファイル、または株式情報などの情報を含むことができる。モバイルサービスデータは、オーディオ／ビデオデータを含むことができる。より詳細には、モバイルサービスデータは、メインサービスデータと比較すると、より低い解像度（ｒｅｓｏｌｕｔｉｏｎ）と低いデータレート（ｒａｔｅ）を有するオーディオ／ビデオデータに該当し得る。例えば、ＭＰＥＧ―２コーデックがメインサービスのためのオーディオ／ビデオコーデックとして使用される場合、モバイルサービスのためにＭＰＥＧ―２コーデック、ＭＰＥＧ―４アドバンスビデオコーディング（ＡＶＣ：ａｄｖａｎｃｅｄ ｖｉｄｅｏ ｃｏｄｉｎｇ）、またはスケーラブルビデオコーディング（ＳＶＣ：ｓｃａｌａｂｌｅ ｖｉｄｅｏ ｃｏｄｉｎｇ）などのよりイメージ圧縮率が高いオーディオ／ビデオコーデックを使用することができる。

【0033】

モバイルサービスデータは、リアルタイム交通放送のためのＴＰＥＧデータ（ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌ ｅｘｐｅｒｔ ｇｒｏｕｐ ｄａｔａ）を含むことができる。または、モバイルサービスデータは、気象情報サービス、交通情報サービス、株式情報サービス、視聴者参加クイズプログラム、リアルタイム投票、双方向教育放送プログラム、ゲームサービス、または音楽プログラムなどの放送サービス／プログラムを含むことができる。

【0034】

本発明において、データグループ（またはＭＨグループ）は、データスロット（またはＭＨスロット）を介して伝送されるデータパケットの集合を意味する。

【0035】

データグループディビジョンは、一つのスロット内でのデータグループ領域のセットを示す。ここで、データグループディビジョンは、プライマリーデータグループディビジョンまたはセカンダリーデータグループディビジョンを区分することができる。ＭＨフレーム（ＭＨ ｆｒａｍｅ）内のプライマリーデータグループディビジョンの集合はプライマリーパレード（ｐａｒａｄｅ）を形成し、セカンダリーデータグループディビジョンはセカンダリーパレードを形成する。

【0036】

パレード（またはＭＨパレード）は、同一のＦＥＣパラメーターを有するデータグループの集合を示す。または、パレードは、同一のデータグループタイプを有するデータグループのデータグループディビジョンの集合を示すことができる。

【0037】

ＲＳフレーム（Ｒｅｅｄ―Ｓｏｌｏｍｏｎ Ｆｒａｍｅ）は、２次元のデータフレームである。ここで、ＲＳフレームのペイロードは、ＲＳ―ＣＲＣ（Ｒｅｅｄ Ｓｏｌｏｍｏｎ Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）コーディングでエンコーディングされる。

【0038】

アンサンブル（ＭＨアンサンブル）は、同一のＦＥＣ（順方向エラー訂正；Ｆｏｒｗａｒｄ Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｏｎ）コードが適用されたＲＳフレームの集合を示す。ここで、それぞれのＲＳフレームは、ＩＰストリームの集合を圧縮して含んでいる。アンサンブルは、モバイルサービスのためのモバイルサービスデータ、及びモバイルサービスのシグナリングのためのモバイルサービスシグナリングチャンネルを含むことができる。

【0039】

本発明の一実施例によると、モバイルサービスのためのモバイルサービスデータは、メインサービスデータの伝送のための伝送チャンネルの一部を介して伝送することができる。または、モバイルサービスのためのモバイルサービスデータは、メインサービスのために使用されていた伝送チャンネル全体を介して伝送することができる。ここで、モバイルサービスのために必要なデータをモバイルサービスデータと称することができる。したがって、モバイルサービスデータは、既知データ、シグナリングデータ、または／及びＲＳパリティデータを含むことができる。

【0040】

モバイルサービスデータは、ＣＭＭ（Ｃｏｒｅ Ｍｏｂｉｌｅ Ｍｏｄｅ）のモバイルサービスデータとＳＦＣＭＭ（Ｓｃａｌａｂｌｅ Ｆｕｌｌ Ｃｈａｎｎｅｌ Ｍｏｂｉｌｅ Ｍｏｄｅ）のモバイルサービスデータとに区分することができる。

【0041】

ＣＭＭは、メインサービスデータとモバイルサービスデータを共に伝送する放送モードである。一例として、ＣＭＭは、それぞれのスロット内の１５６個のパケットのうち、少なくとも３８個のパケットを既存の放送のためのメインサービスデータの伝送に使用することができる。

【0042】

ＳＦＣＭＭは、モバイルサービスデータのみを伝送したり、ＣＭＭより少ない量のメインサービスデータをモバイルサービスデータと共に伝送する放送モードである。例えば、ＳＦＣＭＭは、それぞれのスロット内の１５６個のパケットのうち、３８個より少ないパケットをメインサービスデータの伝送のために使用することができる。

【0043】

ＳＦＣＭＭパレードは、既存のＣＭＭシステム／デコーダーとの逆互換性は維持されるが、既存のＣＭＭシステム／デコーダーによって認識され得ないパレードを示す。

【0044】

データグループ領域は、データブロックまたは拡張データブロックの集合を示す。データグループ領域は、データグループ内の一定の領域を示す。それぞれのデータグループ領域は、それぞれ異なる用途のモバイルサービスデータを含むことができる。

【0045】

ＴＰＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐａｒａｍｅｔｅｒ Ｃｈａｎｎｅｌ）は、それぞれのデータグループに含ませることができ、データフレームまたはデータグループに関する情報を受信側に伝達し、伝送パラメーターを提供する。

【0046】

ＦＩＣ（Ｆａｓｔ ｉｎｆｏｒｍａｔｉｏｎ ｃｈａｎｎｅｌ）はクロスレイヤー（ｃｒｏｓｓ ｌａｙｅｒ）情報（または層間情報）を伝送する。ＦＩＣは、アンサンブルとモバイルサービスとの間の連結情報を含むことができる。

【0047】

本発明において、緊急警報メッセージは、災難及び危急状況を知らせるテキスト、または災難及び危急状況を識別可能な簡単なイメージを示す。

【0048】

本発明において、緊急警報コンテンツは、イメージ、オーディオ、ビデオ、テキストなどのように、ユーザーに災難及び危急状況に対する詳細な情報を提供できる全てのファイルを意味する。緊急警報コンテンツは、ＥＡＳリッチメディアコンテンツ（Ｒｉｃｈ Ｍｅｄｉａ Ｃｏｎｔｅｎｔｓ）として伝送することができる。リッチメディアコンテンツは、双方向サービスが可能なコンテンツを意味することができる。したがって、ＥＡＳリッチメディアコンテンツは、双方向サービスが可能な緊急警報コンテンツを意味することができる。緊急警報コンテンツは緊急警報メッセージを含むことができる。

【0049】

図１は、本発明の一実施例に係る統合公共警報システムの構造を示した図である。

【0050】

本発明の一実施例に係る統合公共警報システム（ＩＰＡＷＳ；Ｉｎｔｅｇｒａｔｅｄ Ｐｕｂｌｉｃ Ａｌｅｒｔ ａｎｄ Ｗａｒｎｉｎｇ Ｓｙｓｔｅｍ）は、ＦＥＭＡ（Ｆｅｄｅｒａｌ Ｅｍｅｒｇｅｎｃｙ Ｍａｎａｇｅｍｅｎｔ Ａｇｅｎｃｙ）の緊急警報管理体系が適用され得る警報システムである。

【0051】

ＦＥＭＡ（Ｆｅｄｅｒａｌ Ｅｍｅｒｇｅｎｃｙ Ｍａｎａｇｅｍｅｎｔ Ａｇｅｎｃｙ）は、北米の連邦サービスとしての災難管理機構であって、現在、多様な通信方式を通じて効果的且つ信頼性の高い災難警報を提供するための統合された形態のシステム構造を設計及び開発している。

【0052】

図１に示したように、災難が発生したり、あるいは災難が発生する可能性がある場合、災難警報発生に対する権限を有する団体（Ａｌｅｒｔｉｎｇ ａｕｔｈｏｒｉｔｉｅｓ）において警報メッセージの共用的なフォーマットであるＣＡＰ（Ｃｏｍｍｏｎ Ａｌｅｒｔｉｎｇ Ｐｒｏｔｏｃｏｌ）を基盤にして警報（ａｌｅｒｔ）メッセージを生成する。このように生成されたＣＡＰメッセージは、ＩＰＡＷＳで開発している多様な警報メッセージ伝達の統合ネットワークであるＯＰＥＮ（Ｏｐｅｎ Ｐｌａｔｆｏｒｍ ｆｏｒ Ｅｍｅｒｇｅｎｃｙ Ｎｅｔｗｏｒｋｓ）を介してＣＭＡＳ（Ｃｏｍｍｅｒｃｉａｌ Ｍｏｂｉｌｅ Ａｌｅｒｔ Ｓｙｓｔｅｍ）などの多様な災難警報システムに伝達する。そして、各災難警報システムは、システムの目的と用途に応じて該当のＣＡＰメッセージを処理し、それによる災難警報サービスを提供する。

【0053】

例えば、ＣＭＡＳの場合、伝達された警報メッセージのうち該当の事業者網に適したメッセージを選別した後、該当のメッセージから９０字以下のテキストを抽出し、文字メッセージ形態の災難警報サービスを提供することができる。

【0054】

図２は、本発明の一実施例に係る警報ネットワークを示した図である。

【0055】

本発明の一実施例に係る警報ネットワークは、ＰＢＳ ＷＡＲＮ（Ｐｕｂｌｉｃ Ｂｒｏａｄｃａｓｔｉｎｇ Ｓｅｒｖｉｃｅ Ｗａｒｎｉｎｇ、Ａｌｅｒｔ、ａｎｄ Ｒｅｓｐｏｎｓｅ Ｎｅｔｗｏｒｋ）に従うことができる。

【0056】

ＰＢＳは、ＦＥＭＡから生成されたＣＭＡＳ（Ｃｏｍｍｅｒｃｉａｌ Ｍｏｂｉｌｅ Ａｌｅｒｔ Ｓｙｓｔｅｍ）の警報メッセージを受け取り、これを放送媒体及び通信事業者に中継する。通信事業者達は、伝達された警報メッセージから９０字以下のテキストを抽出し、文字メッセージの形態で災難警報サービスを提供する。

【0057】

ＣＭＡＳは、ＦＥＭＡから生成された警報メッセージを受け取り、９０字以下のテキスト基盤の災難警報文字サービスを提供する。ＣＭＡＳの警報メッセージ伝達のバックアップ網として、ＰＢＳは、ネットワークオペレーションセンター（Ｎｅｔｗｏｒｋ Ｏｐｅｒａｔｉｏｎ Ｃｅｎｔｅｒ）を通じて放送電波の一部として警報メッセージを含ませて伝送する。ＰＴＶステーション（ｓｔａｔｉｏｎ）は、該当の放送信号と共に警報メッセージを受け取り、これを再び地域放送網に再送出する。そして、これに対する処理が可能なＷＡＲＮ―使用可能なレシーバー（Ｅｎａｂｌｅｄ Ｒｅｃｅｉｖｅｒ）を通じて再送出された警報メッセージを受け取り、これからテキストを抽出し、通信網内のユーザー達に文字メッセージ基盤の災難警報サービスを提供する。

【0058】

図３は、本発明の一実施例に係る伝送システムを示した図である。

【0059】

本発明の一実施例に係る伝送システムは、パケット訂正ユニット（ｐａｃｋｅｔ ａｄｊｕｓｔｍｅｎｔ ｕｎｉｔ）１０１、プリプロセッサ（ｐｒｅ―ｐｒｏｃｅｓｓｏｒ）１０２、データフレームエンコーダー（ｄａｔａ ｆｒａｍｅ ｅｎｃｏｄｅｒ）１０３、ブロックプロセッサ（ｂｌｏｃｋ ｐｒｏｃｅｓｓｏｒ）１０４、シグナリングエンコーダー（ｓｉｇｎａｌｉｎｇ ｅｎｃｏｄｅｒ）１０５、グループフォーマッター（ｇｒｏｕｐ ｆｏｒｍａｔｔｅｒ）１０６、パケットフォーマッター（ｐａｃｋｅｔ ｆｏｒｍａｔｔｅｒ）１０７、パケット多重化器（Ｐａｃｋｅｔ ｍｕｌｔｉｐｌｅｘｅｒ）１０８、ポストプロセッサ（ｐｏｓｔ―ｐｒｏｃｅｓｓｏｒ）１０９、修正データランダマイザー（ｍｏｄｉｆｉｅｄ ｄａｔａ ｒａｎｄｏｍｉｚｅｒ）１１０、組織的／非組織的ＲＳエンコーダー（ｓｙｓｔｅｍａｔｉｃ／ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１１、データインターリーバー（ｄａｔａ ｉｎｔｅｒｌｅａｖｅｒ）１１２、非組織的ＲＳエンコーダー（ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１３、パリティ置換器（ｐａｒｉｔｙ ｒｅｐｌａｃｅｒ）１１４、修正トレリスエンコーダー（ｍｏｄｉｆｉｅｄ ｔｒｅｌｌｉｓ ｅｎｃｏｄｅｒ）１１５、同期多重化器（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｍｕｌｔｉｐｌｅｘｅｒ）１１６、パイロット挿入器（ｐｉｌｏｔ ｉｎｓｅｒｔｅｒ）１１７、ＶＳＢ復調器（ＶＳＢ ｍｏｄｕｌａｔｏｒ）１１８、及び／または伝送ユニット（ｔｒａｎｓｍｉｓｓｉｏｎ ｕｎｉｔ）１１９を含む。本発明に係る伝送システムは、プリイコライザーフィルター（ｐｒｅ―ｅｑｕａｌｉｚｅｒ ｆｉｌｔｅｒ）１２０をさらに含むことができる。

【0060】

パケット訂正ユニット（ｐａｃｋｅｔ ａｄｊｕｓｔｍｅｎｔ ｕｎｉｔ）１０１は、モバイルサービスストリームを含むサービスストリームと、モバイルサービスストリームを含まないサービスストリームとの間に発生し得る位置差を補償することができる。

【0061】

プリプロセッサ（ｐｒｅ―ｐｒｏｃｅｓｓｏｒ）１０２は、モバイルサービスデータを、モバイルサービスデータを伝送するためのモバイルサービス構造に形成する役割をすることができる。プリプロセッサ１０２は、モバイルサービスデータに追加的なＦＥＣコーディングを行うことができる。プリプロセッサ１０２は、既知データをデータグループに挿入することができる。プリプロセッサ１０２は、モバイル環境でモバイルサービスデータの送信及び受信性能の安定性を向上させる。

【0062】

プリプロセッサ１０２は、データフレームエンコーダー（ｄａｔａ ｆｒａｍｅ ｅｎｃｏｄｅｒ）１０３、ブロックプロセッサ（ｂｌｏｃｋ ｐｒｏｃｅｓｓｏｒ）１０４、シグナリングエンコーダー（ｓｉｇｎａｌｉｎｇ ｅｎｃｏｄｅｒ）１０５、グループフォーマッター（ｇｒｏｕｐ ｆｏｒｍａｔｔｅｒ）１０６、パケットフォーマッター（ｐａｃｋｅｔ ｆｏｒｍａｔｔｅｒ）１０７、及び／またはパケット多重化器（Ｐａｃｋｅｔ ｍｕｌｔｉｐｌｅｘｅｒ）１０８を含むことができる。

【0063】

データフレームエンコーダー（ｄａｔａ ｆｒａｍｅ ｅｎｃｏｄｅｒ）１０３は、モバイルサービスデータをランダマイズし、モバイルサービスデータに対してＲＳエンコーディングとＣＲＣ（Ｃｙｃｌｉｃ Ｒｅｄｕｎｄａｎｃｙ Ｃｈｅｃｋ）エンコーディングを行う。データフレームエンコーダー１０３は、モバイルサービスデータを含むＲＳフレームを生成する。データフレームエンコーダー１０３は、ＲＳフレームを分離し、ＲＳフレームポーション（ＲＳ Ｆｒａｍｅ Ｐｏｒｔｉｏｎ）を生成するＲＳフレームディバイダー（図示せず）を含むことができる。

【0064】

ブロックプロセッサ（ｂｌｏｃｋ ｐｒｏｃｅｓｓｏｒ）１０４は、ＲＳフレームポーションをＳＣＣＣ（Ｓｅｒｉａｌ Ｃｏｎｃａｔｅｎａｔｅｄ Ｃｏｎｖｏｌｕｔｉｏｎａｌ Ｃｏｄｉｎｇ）ブロックに変換する。ブロックプロセッサ１０４は、ＳＣＣＣブロックに含まれたモバイルサービスデータのバイトをビット単位のモバイルサービスデータに変換する。ブロックプロセッサ１０４は、ビット単位のモバイルサービスデータに対して１／２、１／３、または１／４レートのコンボリューショナルコーディング（Ｃｏｎｖｏｌｕｔｉｏｎａｌ Ｃｏｄｉｎｇ）を行う。この場合、１／２レートは、一つのビットが入力されると二つのビットが出力されることを意味し、１／３レートは、一つのビットが入力されると三つのビットが出力されることを意味し、１／４レートは、一つのビットが入力されると四つのビットが出力されることを意味する。出力される各ビットはシンボルに含まれる。ブロックプロセッサ１０４は、コンボリューショナルエンコーディングされて出力されるシンボルに対してインターリービング（ｉｎｔｅｒｌｅａｖｉｎｇ）を行う。ブロックプロセッサ１０４は、インターリービングされたシンボルをバイト単位のデータに変換する。ブロックプロセッサ１０４は、ＳＣＣＣブロックをデータブロックに変換する。

【0065】

シグナリングエンコーダー（ｓｉｇｎａｌｉｎｇ ｅｎｃｏｄｅｒ）１０５は、受信側でのシグナリングのためのシグナリング情報を生成する。シグナリングエンコーダー１０５は、シグナリング情報に対してＦＥＣコーディングとＰＣＣＣ（Ｐａｒａｌｌｅｌ Ｃｏｎｃａｔｅｎａｔｅｄ Ｃｏｎｖｏｌｕｔｉｏｎａｌ Ｃｏｄｅ）エンコーディングを行う。シグナリング情報は、ＴＰＣデータ及び／またはＦＩＣデータを含む。

【0066】

グループフォーマッター（ｇｒｏｕｐ ｆｏｒｍａｔｔｅｒ）１０６は、モバイルサービスデータを含むデータグループを形成する。グループフォーマッター１０６は、ＦＥＣコーディングされたモバイルサービスデータをインターリービングされた形態のデータグループに挿入する。グループフォーマッター１０６は、シグナリングデータ修正トレリスエンコーダー１１５のメモリを初期化するための初期化データバイト、及び／または既知データ列（連続する既知データの集合）をデータグループに挿入する。グループフォーマッター１０６は、メインサービスデータのための位置ホルダー、ＭＰＥＧ―２ヘッダーのための位置ホルダー及び／または非組織的ＲＳパリティのための位置ホルダーをデータグループに挿入する。グループフォーマッター１０６は、所望の形態のデータグループを生成するためにダミーデータを挿入することができる。多くの種類のデータを挿入した後、グループフォーマッター１０６は、インターリービングされた形態のデータグループ内のデータに対してデインターリービング（ｄｅ―ｉｎｔｅｒｌｅａｖｉｎｇ）を行う。デインターリービングが行われた後、データグループは、インターリービングされる前の形態のデータグループに出力される。グループフォーマッター１０６で生成されるデータグループは、一つのＲＳフレームポーションに該当するモバイルサービスデータを含む。

【0067】

パケットフォーマッター（ｐａｃｋｅｔ ｆｏｒｍａｔｔｅｒ）１０７は、グループフォーマッター１０６の出力データをトランスポートストリーム（ＴＳ；Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ）パケットに変換する。この場合、ＴＳパケットは、モバイルサービスデータパケットと称することができる。パケットフォーマッター１０７は、一つのデータグループに対して（１１８＋Ｍ）個のモバイルサービスデータパケットを出力する。ここで、Ｍは、３８以下の整数である。

【0068】

パケット多重化器（Ｐａｃｋｅｔ ｍｕｌｔｉｐｌｅｘｅｒ）１０８は、プリプロセッサ１０２によってプロセッシングされたモバイルサービスデータを含むパケットとメインサービスデータを含むパケットを多重化する。一つのスロットにおいて、多重化されたパケットは、（１１８＋Ｍ）個のモバイルサービスデータとＬ個のメインサービスデータパケットを含む。Ｍは、０以上、３８以下の整数であって、ＭとＬの和は３８であることを本発明の一実施例とする。他の実施例において、パケット多重化器１０８は、メインサービスデータパケットの個数が「０」である場合（Ｌ＝０）、モバイルサービスデータのみがパケット多重化器１０８によって処理される。

【0069】

ポストプロセッサ（ｐｏｓｔ―ｐｒｏｃｅｓｓｏｒ）１０９は、モバイルサービスデータが既存の放送システムとの逆互換性を有し得るようにモバイルサービスデータを処理する。この過程において、メインサービスデータを共に処理することができる。本発明の一実施例によると、ポストプロセッサ１０９は、修正データランダマイザー（ｍｏｄｉｆｉｅｄ ｄａｔａ ｒａｎｄｏｍｉｚｅｒ）１１０、組織的／非組織的ＲＳエンコーダー（ｓｙｓｔｅｍａｔｉｃ／ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１１、データインターリーバー（ｄａｔａ ｉｎｔｅｒｌｅａｖｅｒ）１１２、非組織的ＲＳエンコーダー（ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１３、パリティ置換器（ｐａｒｉｔｙ ｒｅｐｌａｃｅｒ）１１４、及び／または修正トレリスエンコーダー（ｍｏｄｉｆｉｅｄ ｔｒｅｌｌｉｓ ｅｎｃｏｄｅｒ）１１５を含むことができる。

【0070】

修正データランダマイザー（ｍｏｄｉｆｉｅｄ ｄａｔａ ｒａｎｄｏｍｉｚｅｒ）１１０は、モバイルサービスデータパケットに対してはランダマイジングを行わず、モバイルサービスデータパケットをバイパス（ｂｙｐａｓｓ）する。修正データランダマイザー１１０は、メインサービスデータパケットに対してランダマイジングを行う。本発明の一実施例によると、プリプロセッサ１０２で生成されたデータグループがメインサービスデータを含んでいない場合、修正データランダマイザー１１０はランダマイジング過程を行わないこともある。

【0071】

組織的／非組織的ＲＳエンコーダー（ｓｙｓｔｅｍａｔｉｃ／ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１１は、入力されるデータがメインサービスデータパケットである場合、メインサービスデータに対して組織的ＲＳエンコーディングを行う。組織的／非組織的ＲＳエンコーダー１１１は、入力されるデータがモバイルサービスデータパケットである場合、モバイルサービスデータに対して非組織的ＲＳエンコーディングを行う。組織的／非組織的ＲＳエンコーディングによって生成された組織的／非組織的ＲＳパリティは、データグループ内で既に定義された位置に挿入することができる。パケット多重化器１０８で多重化されるサービスデータパケットにメインサービスデータパケットが含まれない場合、組織的／非組織的ＲＳエンコーダー１１１は、メインサービスデータのためのＲＳエンコーディングを行う必要がない。この場合、組織的／非組織的ＲＳエンコーダー１１１は、逆互換性のための非組織的ＲＳパリティを生成しないこともある。

【0072】

データインターリーバー（ｄａｔａ ｉｎｔｅｒｌｅａｖｅｒ）１１２は、メインサービスデータ及びモバイルサービスデータを含むデータに対するインターリービングを行う。

【0073】

修正トレリスエンコーダー（ｍｏｄｉｆｉｅｄ ｔｒｅｌｌｉｓ ｅｎｃｏｄｅｒ）１１５を初期化する必要がある場合、非組織的ＲＳエンコーダー（ｎｏｎ―ｓｙｓｔｅｍａｔｉｃ ＲＳ ｅｎｃｏｄｅｒ）１１３は、修正トレリスエンコーダー１１５のメモリ値を受信し、データインターリーバー１１２からモバイルサービスデータを受信し、モバイルサービスデータの初期化データをメモリ値に変える。非組織的ＲＳエンコーダー１１３は、変わったモバイルサービスデータに対して非組織的ＲＳエンコーディングを行い、生成されたＲＳパリティをパリティ置換器１１４に出力する。

【0074】

修正トレリスエンコーダー１１５が初期化される必要がある場合、パリティ置換器１１４は、データインターリーバー１１２からモバイルサービスデータを受信し、モバイルサービスデータの非組織的ＲＳパリティを非組織的ＲＳエンコーダー１１３によって生成された非組織的ＲＳパリティに置換する。

【0075】

パケット多重化器１０８で多重化されたパケットがメインサービスデータパケットを含まない場合、逆互換性のためのＲＳパリティをデータグループに含ませる必要がない。したがって、本発明の一実施例によると、この場合、非組織的ＲＳエンコーダー１１３とパリティ置換器１１４は上述した動作を行わず、受信したデータをバイパスする動作を行うことができる。

【0076】

修正トレリスエンコーダー（ｍｏｄｉｆｉｅｄ ｔｒｅｌｌｉｓ ｅｎｃｏｄｅｒ）１１５は、データインターリーバー１１２の出力に対してトレリスエンコーディングを行う。トレリスエンコーディング後、放送送信側と放送受信側によって約束された形態の既知データを出力するために、トレリスエンコーディングを開始する前にトレリスエンコーダー１１５に含まれたメモリが初期化される必要がある。上述した初期化動作は、データグループに含まれた初期化データによって開始することができる。

【0077】

同期多重化器（ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｍｕｌｔｉｐｌｅｘｅｒ）１１６は、修正トレリスエンコーダー１１５の出力データにフィールド同期信号とセグメント同期信号を挿入し、これらデータを多重化する。

【0078】

パイロット挿入器（ｐｉｌｏｔ ｉｎｓｅｒｔｅｒ）１１７は、同期多重化器１１６で多重化されたデータを受信し、受信側でチャンネル信号の復調のためのキャリアフェーズ（ｃａｒｒｉｅｒ ｐｈａｓｅ）として使用されるパイロット信号を多重化されたデータに挿入する。

【0079】

ＶＳＢ変調器（ＶＳＢ ｍｏｄｕｌａｔｏｒ）１１８は、放送データを伝送するためにＶＳＢ変調を行う。場合に応じて、ＶＳＢ変調器（ＶＳＢ ｍｏｄｕｌａｔｏｒ）１１８はＯＦＤＭ変調器に取り替えることができる。すなわち、ＶＳＢ方式でないＯＦＤＭ方式で変調が行われる場合、ＯＦＤＭ変調器を本伝送システムに含ませることができる。

【0080】

伝送ユニット（ｔｒａｎｓｍｉｓｓｉｏｎ ｕｎｉｔ）１１９は、変調されたデータに対して周波数アップ（ｕｐ）変換を行い、変換が行われたデータを伝送する。

【0081】

本発明の一実施例に係る伝送システムにおいては、上述したそれぞれの装置のうち一部を省略したり、他の装置に取り替えることができ、装置処理の順序も変更可能である。

【0082】

図４は、本発明の一実施例に係るシグナリングエンコーダーを示した図である。

【0083】

本発明の一実施例に係るシグナリングエンコーダーは、第１のＲＳエンコーダー４１００、第２のＲＳエンコーダー４２００、ブロックインターリーバー４３００、多重化器４４００、シグナリングランダマイザー４５００、及び／またはＰＣＣＣエンコーダー４６００を含む。

【0084】

第１のＲＳエンコーダー４１００は、ＴＰＣデータに対してＲＳエンコーディングを行う。

【0085】

第２のＲＳエンコーダー４２００は、ＦＩＣデータに対してＲＳエンコーディングを行う。第１のＲＳエンコーダーと第２のＲＳエンコーダーは、互いに異なるレートでＲＳエンコーディングを行うことを本発明の一実施例とする。すなわち、ＴＰＣデータとＦＩＣデータは、互いに異なるレートでＲＳエンコーディングされる。

【0086】

ブロックインターリーバー４３００は、ＲＳエンコーディングされたＦＩＣデータに対してブロックインターリービングを行う。ブロックインターリービングは、ＦＩＣデータをブロック単位でインターリービングすることである。

【0087】

多重化器４４００は、ＲＳエンコーディングされたＴＰＣデータとブロックインターリービングされたＦＩＣデータを多重化する。

【0088】

シグナリングランダマイザー４５００は、多重化されたデータをランダマイジングする。

【0089】

ＰＣＣＣエンコーダー４６００は、ランダマイジングされたデータをＰＣＣＣエンコーディングする。

【0090】

図５は、本発明の一実施例に係るアンサンブルの構造を示した図である。

【0091】

アンサンブルは、モバイルサービスを構成するモバイルサービスデータを伝送する。アンサンブルは、モバイルサービスをシグナリングするためのサービスシグナリングチャンネル（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ；ＳＳＣ）を含むことができる。サービスシグナリングチャンネルは、ＩＰデータグラムに含ませることもできる。サービスシグナリングチャンネルは、特定のＩＰ住所とＵＤＰポート（ｐｏｒｔ）を介して伝送されるように定義することができる。すなわち、受信側では、該当のＩＰ住所とＵＤＰポートのデータをパーシングし、サービスシグナリングチャンネルデータを獲得することができる。

【0092】

サービスシグナリングチャンネルは、アンサンブルによって伝送されるモバイルサービスに対する属性情報を含むサービスマップテーブル（Ｓｅｒｖｉｃｅ Ｍａｐ Ｔａｂｌｅ；ＳＭＴ）、モバイルサービスに対するサービスガイドデータに対する情報を含むガイドアクセステーブル（Ｇｕｉｄｅ Ａｃｃｅｓｓ Ｔａｂｌｅ；ＧＡＴ）、類似するサービスを伝送する隣接するセル（ｃｅｌｌ）に対するキャリア周波数情報を提供するセル情報テーブル（Ｃｅｌｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ；ＣＩＴ）、受信側での速いモバイルサービススキャンのための情報を含むサービスラベリングテーブル（Ｓｅｒｖｉｃｅ Ｌａｂｅｌｉｎｇ Ｔａｂｌｅ；ＳＬＴ）、モバイルサービスに対する視聴等級情報を含むレーティング領域テーブル（Ｒａｔｉｎｇ Ｒｅｇｉｏｎ Ｔａｂｌｅ；ＲＲＴ）、及び／または緊急警報サービスをモバイル放送で伝送するための情報を含むモバイル緊急警報テーブル（Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ―ＭＨ；ＥＡＴ―ＭＨ）を含むことができる。

【0093】

図６は、本発明の一実施例に係るモバイル緊急警報テーブルのシンタックスを示した図である。

【0094】

本発明のモバイル緊急警報テーブルは、固定放送システムで使用される場合、緊急警報テーブルと命名することもできる。

【0095】

本発明のモバイル緊急警報テーブルは、ｔａｂｌｅ＿ｉｄフィールド、ＥＡＴ＿ＭＨ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールド、ｅｎｓｅｍｂｌｅ＿ｉｄフィールド、ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールド、ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｔｓ＿ｉｄフィールド、ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｅｎｓｅｍｂｌｅ＿ｉｄフィールド、ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｓｅｒｖｉｃｅ＿ｉｄフィールド、ｎｕｍ＿ＥＡＳ＿ｍｅｓｓａｇｅｓフィールド、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄフィールド、ｔｙｐｅ＿ｏｆ＿ｒｅｓｐｏｎｄｅｒフィールド、ｔｙｐｅ＿ｏｆ＿ｄｉｓｃｉｐｌｉｎｅｓフィールド、ＥＡＳ＿ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールド、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールド、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｅｎｃｏｄｉｎｇ＿ｔｙｐｅフィールド、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｌｅｎｇｔｈフィールド、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｂｙｔｅｓフィールド、ＩＰ＿ａｄｄｒｅｓｓフィールド、ＵＤＰ＿ｐｏｒｔ＿ｎｕｍフィールド及び／またはＥＡＳ＿ＮＲＴ＿ｓｅｒｖｉｃｅ＿ｉｄフィールドを含むことができる。

【0096】

ｔａｂｌｅ＿ｉｄフィールドは、現在のテーブルの種類を識別する。放送受信機は、特定の値のｔａｂｌｅ＿ｉｄフィールドを識別し、本テーブルがモバイル緊急警報テーブルであることを識別することができる。

【0097】

ＥＡＴ＿ＭＨ＿ｐｒｏｔｏｃｏｌ＿ｖｅｒｓｉｏｎフィールドは、モバイル緊急警報テーブルの構造が変更される場合、これらに対するバージョン情報を識別する。

【0098】

ｅｎｓｅｍｂｌｅ＿ｉｄフィールドは、本テーブルと関連するアンサンブルのＩＤを示す。

【0099】

ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｃｈａｎｎｅｌ＿ｎｕｍｂｅｒフィールドは、自動チューニングのための物理的ＲＦチャンネル番号を示す。例えば、緊急警報メッセージが放送されるチャンネル番号に強制チューニングが必要な場合、前記のフィールドを参照することができる。

【0100】

ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｔｓ＿ｉｄフィールドは、自動チューニングのためのトランスポートストリームＩＤを示す。例えば、緊急警報メッセージを含むトランスポートストリームをパーシングしなければならない場合、前記のＩＤを通じて該当のストリームを識別することができる。

【0101】

ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｅｎｓｅｍｂｌｅ＿ｉｄフィールドは、自動チューニングのためのアンサンブルのＩＤを示す。例えば、緊急警報メッセージを含むアンサンブルを前記のフィールドを通じて識別することができる。

【0102】

ａｕｔｏｍａｔｉｃ＿ｔｕｎｉｎｇ＿ｓｅｒｖｉｃｅ＿ｉｄフィールドは、自動チューニングのターゲットＡ／Ｖサービスを示す。モバイル緊急警報テーブルで自動チューニングが指定された場合、緊急警報テーブルは警報メッセージを含むこともでき、警報メッセージを含まないこともある。自動チューニングが指定された場合、放送受信機は該当のメッセージを無視し、ターゲットチャンネル番号にチューニングする。

【0103】

ｎｕｍ＿ＥＡＳ＿ｍｅｓｓａｇｅｓフィールドは、モバイル緊急警報テーブルに含まれた緊急警報メッセージの個数を示す。

【0104】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄフィールドは、緊急警報メッセージの伝送のための固有のＩＤを識別する。このフィールドは、以前の緊急警報メッセージがアップデートされたり、取り消される場合はその値が変更され得る。他の実施例において、このフィールドは、ＣＡＰメッセージＩＤから抽出することができる。

【0105】

ｔｙｐｅ＿ｏｆ＿ｒｅｓｐｏｎｄｅｒフィールドは、緊急警報メッセージの放送対象者を示す。

【0106】

ｔｙｐｅ＿ｏｆ＿ｄｉｓｃｉｐｌｉｎｅｓフィールドは、緊急警報の対象になる緊急状況に対する情報を示す。

【0107】

ＥＡＳ＿ＩＰ＿ｖｅｒｓｉｏｎ＿ｆｌａｇフィールドは、「０」にセッティングされる場合はＩＰ＿ａｄｄｒｅｓｓフィールドがＩＰｖ４住所を含むことを示し、「１」にセッティングされる場合はＩＰ＿ａｄｄｒｅｓｓフィールドがＩＰｖ６のためのものであることを示す。

【0108】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドは、緊急警報メッセージの伝送タイプを示す。

【0109】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｅｎｃｏｄｉｎｇ＿ｔｙｐｅフィールドは、緊急警報メッセージのエンコーディング計画を示す。

【0110】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｌｅｎｇｔｈフィールドは、緊急警報を含む圧縮された緊急警報メッセージの圧縮長さを示す。

【0111】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｂｙｔｅｓフィールドは、緊急警報を含む圧縮された緊急警報メッセージのサイズを示す。

【0112】

ＩＰ＿ａｄｄｒｅｓｓフィールドは、緊急警報メッセージがＩＰデータグラムを介して伝送される場合、該当のＩＰ住所を示す。

【0113】

ＵＤＰ＿ｐｏｒｔ＿ｎｕｍフィールドは、緊急警報メッセージがＩＰデータグラムを介して伝送される場合、該当のＵＤＰ住所を示す。

【0114】

ＥＡＳ＿ＮＲＴ＿ｓｅｒｖｉｃｅ＿ｉｄフィールドは、緊急警報メッセージと関連する追加コンテンツを提供するＮＲＴサービスのサービスＩＤを識別する。このフィールドは、緊急警報テーブルを伝送するアンサンブルに含まれたＳＭＴにも挿入することができる。

【0115】

図７は、本発明の一実施例に係るＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値による説明を示した図である。

【0116】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドは、このフィールドの値によって、緊急警報メッセージの伝送タイプが識別されていないか、警報メッセージが含まれていないＮＲＴファイルが伝送されることを示すこともでき、または、緊急警報メッセージがモバイル緊急警報テーブルに含まれて伝送されたり、緊急警報メッセージがＩＰデータグラムを通じて伝送される場合を示すこともできる。

【0117】

図８は、本発明の一実施例に係る緊急警報コンテンツを伝送するＩＰデータグラムの構造を示した図である。

【0118】

本発明の一実施例によると、モバイル緊急警報システムにおいてＥＳＧ／ＮＲＴを使用せず、ＥＡＳリッチメディアコンテンツ（または緊急警報コンテンツ）をＩＰデータグラムで伝送する。本発明の一実施例によると、緊急警報コンテンツと関連する情報をＥＡＴ―ＭＨ（またはＥＡＴ；Ｅｍｅｒｇｅｎｃｙ Ａｌｅｒｔ Ｔａｂｌｅ）を通じてシグナリングし、ＥＳＧ／ＮＲＴを支援しない受信機でもＥＡＳリッチメディアコンテンツを受信し、それと関連する情報をユーザーに提供することができる。

【0119】

ＥＡＳリッチメディアコンテンツは、イメージ、オーディオ、ビデオなどのユーザーに豊かな災難情報を提供できる全てのファイルを意味する。ＥＡＳリッチメディアコンテンツには緊急警報コンテンツを含ませることができる。リッチメディアコンテンツは、双方向サービスが可能なコンテンツを意味することができる。したがって、ＥＡＳリッチメディアコンテンツは、双方向サービスが可能な緊急警報コンテンツを意味することができる。緊急警報コンテンツは緊急警報メッセージを含むことができる。

【0120】

モバイル放送システムにおいて、緊急警報メッセージまたは緊急警報コンテンツはＮＲＴを用いて伝送することができ、この場合、ＦＬＵＴＥタイプのＩＰデータグラムを通じて緊急警報メッセージまたは緊急警報コンテンツを伝送することができる。しかし、本発明では、ＮＲＴを支援しない受信機にも緊急警報メッセージまたは緊急警報コンテンツが提供されるべきであるので、ＥＡＳリッチメディアコンテンツを伝送できるＩＰデータグラムの構造を新たに定義する必要がある。

【0121】

本発明に係る緊急警報コンテンツを伝送するＩＰデータグラムは、ＩＰ＿ｈｅａｄｅｒエレメント、ＵＤＰ＿ｈｅａｄｅｒエレメント、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄエレメント、ｃｕｒｒｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒエレメント、ｌａｓｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒエレメント、ｃｏｎｔｅｎｔ＿ＩＤエレメント、及び／またはｃｏｎｔｅｎｔ＿ｐａｙｌｏａｄ（）エレメントを含むことができる。

【0122】

ＩＰ＿ｈｅａｄｅｒエレメントにはＩＰヘッダーが含まれる。

【0123】

ＵＤＰ＿ｈｅａｄｅｒエレメントにはＵＤＰヘッダーが含まれる。

【0124】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄエレメントは、伝送されるＥＡＳリッチメディアコンテンツと関連する緊急警報メッセージ（ＥＡＳメッセージ）の識別子（ＩＤ）を示す。

【0125】

ｃｕｒｒｅｎｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒエレメントは、受信したＩＰデータグラムの現在のシーケンス番号（ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）を示す。

【0126】

ｌａｓｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒエレメントは、受信したＩＰデータグラムの最後のシーケンス番号を示す。

【0127】

ｃｏｎｔｅｎｔ＿ＩＤエレメントは、受信したＩＰデータグラムを集めて作られるコンテンツの識別子（ＩＤ）を示す。

【0128】

ｃｏｎｔｅｎｔ＿ｐａｙｌｏａｄ（）エレメントは、実際のコンテンツのデータを伝送する。ｌａｓｔ＿ｓｅｑｕｅｎｃｅ＿ｎｕｍｂｅｒエレメントが識別する個数だけのシーケンスを集めると、一つのコンテンツを作ることができる。

【0129】

図９は、本発明の一実施例に係る緊急警報コンテンツをシグナリングするシンタックスを示した図である。

【0130】

ＥＡＳリッチメディアコンテンツをＩＰデータグラムで伝送すると、これと関連する情報をシグナリングしたときに受信機でコンテンツを受信することができる。本発明の一実施例によると、モバイル放送システムの緊急警報システムにおいて緊急警報メッセージと関連する情報を提供するＥＡＴ―ＭＨ（またはＥＡＴ）にＥＡＳリッチメディアコンテンツと関連する情報を追加することができる。

【0131】

本発明の一実施例に係る緊急警報コンテンツをシグナリングするＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）は、ｎｕｍ＿ｏｆ＿ｃｏｎｔｅｎｔｓフィールド、ｃｏｎｔｅｎｔ＿ＩＤフィールド、ＩＰ＿ａｄｄｒｅｓｓフィールド、Ｐｏｒｔ＿ｎｕｍｂｅｒフィールド、ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｅｘｔ＿ｌｅｎｇｔｈフィールド、ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｅｘｔ＿ｂｙｔｅｓ（）フィールド、ｅｘｐｉｒａｔｉｏｎ＿ｔｉｍｅフィールド、ｇｅｏｃｏｄｅ＿ｃｏｕｎｔフィールド及び／またはｇｅｏｃｏｄｅフィールドを含むことができる。

【0132】

ｎｕｍ＿ｏｆ＿ｃｏｎｔｅｎｔｓフィールドは、伝送されるＥＡＳリッチメディアコンテンツの個数を示す。

【0133】

ｃｏｎｔｅｎｔ＿ＩＤフィールドは、伝送される緊急警報コンテンツの固有のＩＤを示す。

【0134】

ＩＰ＿ａｄｄｒｅｓｓフィールドは、緊急警報コンテンツのあて先ＩＰ住所（ｄｅｓｔｉｎａｔｉｏｎ ＩＰ ａｄｄｒｅｓｓ）値を示す。

【0135】

Ｐｏｒｔ＿ｎｕｍｂｅｒは、緊急警報コンテンツのあて先ポート（ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ）値を示す。

【0136】

ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｅｘｔ＿ｌｅｎｇｔｈフィールドは、緊急警報コンテンツの名前と拡張子名ストリング（ｓｔｒｉｎｇ）の長さを示す。

【0137】

ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｅｘｔ＿ｂｙｔｅｓ（）フィールドは、緊急警報コンテンツの名前及び／または拡張子名を示す。例えば、「ｅｘａｍｐｌｅ．ｔｘｔ」のように「．」名前と拡張子名とを区分することができる。

【0138】

ｅｘｐｉｒａｔｉｏｎ＿ｔｉｍｅフィールドは、緊急警報コンテンツの有効期間を示す。

【0139】

ｇｅｏｃｏｄｅ＿ｃｏｕｎｔフィールドは、緊急警報コンテンツが示されるべき場所を意味するｇｅｏｃｏｄｅ値の個数を示す。

【0140】

ｇｅｏｃｏｄｅフィールドは、緊急警報コンテンツが示されるべき場所を意味するジオコード（ｇｅｏ ｃｏｄｅ）を示す。例えば、ジオコードは、ＦＩＰＳコードと定義することができる。

【0141】

図面には示していないが、本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）は、ｃｏｎｔｅｎｔ＿ｔｙｐｅフィールド、及び／またはｒｅｌａｔｅｄ＿ｃｏｎｔｅｎｔフィールドをさらに含むことができる。

【0142】

ｃｏｎｔｅｎｔ＿ｔｙｐｅフィールドは、緊急警報コンテンツのタイプを示す。例えば、緊急警報コンテンツがオーディオコンテンツであるか、ビデオコンテンツであるか、及び／または文字コンテンツであるかを示すことができる。

【0143】

ｒｅｌａｔｅｄ＿ｃｏｎｔｅｎｔ（）フィールドは、ｃｏｎｔｅｎｔ＿ＩＤによって識別される緊急警報コンテンツと関連する緊急警報コンテンツに対する情報を含む。例えば、ｒｅｌａｔｅｄ＿ｃｏｎｔｅｎｔ（）フィールドには、ｒｅｌａｔｅ＿ｃｏｎｔｅｎｔ＿ａｄｄｒｅｓｓフィールド及び／またはｒｅｌａｔｅ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅフィールドを含ませることができる。ｒｅｌａｔｅ＿ｃｏｎｔｅｎｔ＿ａｄｄｒｅｓｓフィールドは、ｃｏｎｔｅｎｔ＿ＩＤによって識別される緊急警報コンテンツと関連する緊急警報コンテンツを伝送するＩＰ住所及び／またはＵＤＰポート住所を示す。ｒｅｌａｔｅ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅフィールドは、ｃｏｎｔｅｎｔ＿ＩＤによって識別される緊急警報コンテンツと関連する緊急警報コンテンツのタイプを示す。

【0144】

ｒｅｌａｔｅｄ＿ｃｏｎｔｅｎｔ（）フィールドの情報を用いて、視覚情報を認識できない障害者のために、ビデオ、オーディオ要素が結合された形態の緊急警報コンテンツと関連して、オーディオ形態で全ての情報を示す緊急警報コンテンツを提供する住所に接続し、該当の緊急警報コンテンツを受信することができる。その一方、オーディオ情報を認識できない障害者のために、ビデオ、オーディオ要素が結合された形態の緊急警報コンテンツと関連して、ビデオ形態で全ての情報を示す緊急警報コンテンツを提供する住所に接続し、該当の緊急警報コンテンツを受信することができる。

【0145】

図１０は、本発明の他の実施例に係る緊急警報テーブルを示した図である。

【0146】

本発明の他の実施例によると、ＩＰデータグラムを介して伝送されるＥＡＳリッチメディアコンテンツの関連情報を緊急警報テーブルを通じてシグナリングすることができる。本発明によると、ＩＰデータグラムを介して緊急警報コンテンツを伝送し、該当の緊急警報コンテンツに関する情報は緊急警報テーブルを通じてシグナリングすることができる。

【0147】

本発明の他の実施例に係る緊急警報テーブルに含まれる各フィールドに対する説明は、図６における各フィールドに対する説明と同様であるので省略する。

【0148】

ただし、本発明の他の実施例に係る緊急警報テーブルは、図９を参照して説明したＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）を含むことができる。

【0149】

図１１は、本発明の他の実施例に係るＥＡＳ＿ｍａｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値による説明を示した図である。

【0150】

本発明の他の実施例によると、ＥＡＳリッチメディアコンテンツを伝送するために緊急警報テーブルのＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅに「０ｘ０４」値を追加することができる。ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅの値が「０ｘ０４」である場合、ＥＡＳメッセージ、コンテンツ及び関連情報（及び／または伝送情報）が緊急警報テーブルの内部に記述されていることを意味する。

【0151】

本発明の他の実施例によると、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドは、このフィールドの値により、緊急警報メッセージの伝送タイプが識別されていないか、警報メッセージが含まれていないリッチメディアコンテンツファイルが伝送されることを示すこともでき、または、緊急警報メッセージが緊急警報テーブルに含まれて伝送されたり、緊急警報メッセージがＩＰデータグラムを通じて伝送されたり、緊急警報メッセージと共にＥＡＳリッチメディアコンテンツが伝送されることが分かる。

【0152】

図１２は、本発明の一実施例に係る緊急警報ＩＰデータグラムを示した図である。

【0153】

上述したように、ＥＡＴ―ＭＨ（または緊急警報テーブル）のＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドは、緊急警報システムにおいて緊急警報メッセージがＩＰデータグラムを介して伝送されていることを示すことができる。この場合、緊急警報テーブルには、緊急警報メッセージを伝送するＩＰデータグラムの構造をシグナリングした。

【0154】

本発明の一実施例では、ＩＰデータグラム自体が緊急警報メッセージまたは緊急警報コンテンツに対する情報をシグナリングすることができる。このとき、ＩＰデータグラムは、ＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｅｔｕｒｅ（）構造を含むことができる。

【0155】

本発明の一実施例に係る緊急警報メッセージまたは緊急警報コンテンツに対する情報をシグナリングするＩＰデータグラムは、ＩＰ＿ｈｅａｄｅｒエレメント、ＵＤＰ＿ｈｅａｄｅｒエレメント、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄエレメント、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｌｅｎｇｔｈエレメント、ＥＡＳ＿ｍｅｓｓａｇｅ＿ｂｙｔｅｓ（）エレメント、及び／またはＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）エレメントを含むことができる。

【0156】

ＩＰ＿ｈｅａｄｅｒエレメントにはＩＰヘッダーが含まれる。

【0157】

ＵＤＰ＿ｈｅａｄｅｒエレメントにはＵＤＰヘッダーが含まれる。

【0158】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｉｄエレメントは、伝送されるＥＡＳリッチメディアコンテンツと関連する緊急警報メッセージ（ＥＡＳメッセージ）の識別子（ＩＤ）を示す。

【0159】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｌｅｎｇｔｈエレメントは、緊急警報メッセージの長さを示す。

【0160】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｂｙｔｅｓ（）エレメントは、緊急警報メッセージのデータを伝送する。

【0161】

ＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）エレメントは、図９を参照して説明したＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）を含むことができる。

【0162】

図１３は、本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）を示した図である。

【0163】

本発明の一実施例によると、ＥＡＳリッチメディアコンテンツは、ファイル形態で伝送されるので、ＦＬＵＴＥという伝送方式に従って伝送することも可能である。この場合、緊急警報コンテンツがＦＬＵＴＥ方式のＩＰデータグラムで伝送されるか否かが識別可能でなければならない。したがって、本発明の一実施例では、上述したＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｓｔｒｕｃｔｕｒｅ（）の拡張されたシグナリング構造を提案する。

【0164】

本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）は、シグナリングのための別途のＩＰデータグラムを定義し、該当のＩＰデータグラムを通じてシグナリングすることができる。または、ＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）は緊急警報テーブルに含ませることができる。

【0165】

本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）は、ｎｕｍ＿ｏｆ＿ｃｏｎｔｅｎｔｓエレメント、ＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメント、ＴＳＩエレメント、ＴＯＩエレメント、ｃｏｎｔｅｎｔ＿ＩＤエレメント、ｏｒｉｇｉｎａｌ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈエレメント、ｏｒｉｇｉｎａｌ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅエレメント、ｔｒａｎｓｆｅｒ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈエレメント、ｔｒａｎｓｆｅｒ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅエレメント、ｅｎｃｒｙｐｔｅｄ＿ｆｌａｇエレメント、ｅｎｃｒｙｐｔｉｏｎ＿ｍｅｔｈｏｄエレメント、ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈエレメント、ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｂｙｔｅｓ（）エレメント、ＩＰ＿ａｄｄｒｅｓｓエレメント、Ｐｏｒｔ＿ｎｕｍｂｅｒエレメント、ｅｘｐｉｒａｔｉｏｎ＿ｔｉｍｅエレメント、ｇｅｏｃｏｄｅ＿ｃｏｕｎｔエレメント及び／またはｇｅｏｃｏｄｅエレメントを含むことができる。

【0166】

ｎｕｍ＿ｏｆ＿ｃｏｎｔｅｎｔｓエレメントは、伝送されるＥＡＳリッチメディアコンテンツの個数を示す。

【0167】

ＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントは、ＥＡＳリッチメディアコンテンツを載せて伝送するＩＰデータグラムの構造方式を示す。これについては、後でより詳細に説明する。

【0168】

ＴＳＩエレメントは、ＦＬＵＴＥ方式に従うＩＰデータグラムでＥＡＳリッチメディアコンテンツが伝送される場合、ＦＤＴ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ Ｔａｂｌｅ）に記述されたＴＳＩと一致する値を示す。ＴＳＩエレメントは、ＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）が含まれるシグナリング構造とＦＤＴとを連結する役割をすることができる。

【0169】

ＴＯＩエレメントは、ＦＬＵＴＥ方式に従うＩＰデータグラムでＥＡＳリッチメディアコンテンツが伝送される場合、ＦＤＴに記述されたＴＯＩと一致する値を示す。ＴＯＩエレメントは、ＥＡＳ＿ｃｏｎｔｅｎｔ＿ｔｒａｎｓｆｅｒ＿ｅｘｔｅｎｄｅｄ＿ｓｔｒｕｃｔｕｒｅ（）が含まれるシグナリング構造とＦＤＴとを連結する役割をすることができる。

【0170】

ｃｏｎｔｅｎｔ＿ＩＤエレメントは、伝送されるＥＡＳリッチメディアコンテンツ（またはコンテンツ）の固有のＩＤを示す。

【0171】

ｏｒｉｇｉｎａｌ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈエレメントは、ＥＡＳリッチメディアコンテンツ（またはコンテンツ）の原本の長さ（ｏｒｉｇｉｎａｌ ｌｅｎｇｔｈ）を示す。

【0172】

ｏｒｉｇｉｎａｌ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅエレメントは、ＥＡＳリッチメディアコンテンツの原本のタイプ（ｏｒｉｇｉｎａｌ ｔｙｐｅ）を示す。ｏｒｉｇｉｎａｌ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅエレメントは、ＥＡＳリッチメディアコンテンツに適用された圧縮方式またはコンテンツの種類（オーディオ、ビデオ、またはイメージ）を示すことができる。

【0173】

ｔｒａｎｓｆｅｒ＿ｃｏｎｔｅｎｔ＿ｌｅｎｇｔｈエレメントは、伝送されるＥＡＳリッチメディアコンテンツの長さ（ｌｅｎｇｔｈ）を示す。

【0174】

ｔｒａｎｓｆｅｒ＿ｃｏｎｔｅｎｔ＿ｔｙｐｅエレメントは、伝送されるＥＡＳリッチメディアコンテンツのタイプ（ｔｙｐｅ）を示す。ＥＡＳリッチメディアコンテンツはＧｚｉｐの形態で伝送することができる。

【0175】

ｅｎｃｒｙｐｔｅｄ＿ｆｌａｇエレメントは、ＥＡＳリッチメディアコンテンツが暗号化されたか否かを示す。

【0176】

ｅｎｃｒｙｐｔｉｏｎ＿ｍｅｔｈｏｄエレメントは、ＥＡＳリッチメディアコンテンツが暗号化されている場合、該当の暗号化方法を識別する情報を含む。

【0177】

ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｌｅｎｇｔｈエレメントは、ＥＡＳリッチメディアコンテンツの名前ストリングの長さを示す。

【0178】

ｃｏｎｔｅｎｔ＿ｎａｍｅ＿ｂｙｔｅｓ（）エレメントは、ＥＡＳリッチメディアコンテンツの名前を示す。

【0179】

ＩＰ＿ａｄｄｒｅｓｓエレメントは、ＥＡＳリッチメディアコンテンツのあて先ＩＰ住所値を示す。

【0180】

Ｐｏｒｔ＿ｎｕｍｂｅｒエレメントは、ＥＡＳリッチメディアコンテンツのあて先ポート値を示す。

【0181】

ｅｘｐｉｒａｔｉｏｎ＿ｔｉｍｅエレメントは、ＥＡＳリッチメディアコンテンツの有効期間を示す。

【0182】

ｇｅｏｃｏｄｅ＿ｃｏｕｎｔエレメントは、ＥＡＳリッチメディアコンテンツが示されるべき場所を意味するジオコード値の個数を示す。

【0183】

ｇｅｏｃｏｄｅエレメントは、ＥＡＳリッチメディアコンテンツが示されるべき場所を意味するジオコードを示す。例えば、ｇｅｏｃｏｄｅエレメントはＦＩＰＳコードと定義することができる。

【0184】

図１４は、本発明の一実施例に係るＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントの値による説明を示した図である。

【0185】

ＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントの値が「０ｘ００」である場合、ＥＡＳリッチメディアコンテンツを伝送するＩＰデータグラムの構造が定義されていないことを示す。

【0186】

ＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントの値が「０ｘ０１」である場合、ＥＡＳリッチメディアコンテンツを伝送するＩＰデータグラムがＦＬＵＴＥ（Ｆｉｌｅ ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）で伝送されることを示す。

【0187】

ＥＡＳ＿ｃｏｎｔｅｎｔ＿ＩＰ＿ｄａｔａｇｒａｍ＿ｔｙｐｅエレメントの値が「０ｘ０２」である場合、ＥＡＳリッチメディアコンテンツを伝送するＩＰデータグラムは、本発明で説明した形態のＩＰデータグラムで伝送されることを示す。

【0188】

図１５は、本発明の一実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【0189】

本発明の一実施例によると、モバイル緊急警報テーブルのサイズを減少させるために、ＣＡＰ（Ｃｏｍｍｏｎ Ａｌｅｒｔｉｎｇ Ｐｒｏｔｏｃｏｌ）警報メッセージが圧縮され得る。モバイル緊急警報テーブルを識別できるモバイル受信機（Ｍ／Ｈ受信機）は、圧縮されたＣＡＰ警報メッセージを抽出することができる。この場合、モバイル受信機は、ＣＡＰ警報メッセージに対する圧縮を解いた後、ＳＭＴを参照していない状態で迅速に緊急警報メッセージをディスプレイすることができる。

【0190】

モバイル緊急警報テーブルは、緊急警報メッセージのエントリーに対するＮＲＴ＿ｓｅｒｖｉｃｅ＿ｉｄを伝送することができ、ＮＲＴ＿ｓｅｒｖｉｃｅ＿ｉｄは、緊急警報メッセージと関連する追加内容がＮＲＴ（Ｎｏｎ―Ｒｅａｌ―Ｔｉｍｅ）放送サービスを介して伝送されることを示す。ＮＲＴ放送サービスを受信できる放送受信機は、ＳＭＴ、サービスガイド（Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ；ＳＧ）、及び／またはＮＲＴサービスのためにシグナリングされるＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）セッションを参照して追加緊急警報メッセージをディスプレイすることができる。

【0191】

モバイル緊急警報テーブルの反復受信回数は、緊急警報メッセージの重要度に応じて変わり得る。重要度が最高である緊急警報メッセージは、一つのＭＨフレームごとに反復することができる。

【0192】

図１５を参照すると、放送受信機は、ＧＡＴのＭＨ＿ｓｅｒｖｉｃｅ＿ｉｄを参照してＳＭＴにおいて該当のサービスのＩＰ住所とＵＤＰポート番号を識別し、これを通じて伝送されるＦＬＵＴＥデータをパーシングし、電子サービスガイド（ＥＳＧ；Ｅｌｅｃｔｒｏｎｉｃ Ｓｅｒｖｉｃｅ Ｇｕｉｄｅ）を通じて緊急警報コンテンツが含まれていることをディスプレイすることができる。放送受信機は、モバイル緊急警報テーブルのＥＡＳ＿ＮＲＴ＿ｓｅｒｖｉｃｅ＿ｉｄを参照して、ＮＲＴに伝送される緊急警報メッセージを含むサービスを伝送するＩＰ住所とＵＤＰポート番号を識別し、これを通じて伝送されるＦＬＵＴＥデータをパーシングし、緊急警報メッセージをディスプレイすることができる。あるいは、モバイル緊急警報テーブルは、緊急警報メッセージを含んでいる場合もあり、この場合は、ＣＡＰパーサーを通じて、この緊急警報メッセージを直ぐパーシングしてディスプレイすることができる。

【0193】

本実施例においては、ＥＡＳリッチメディアコンテンツを提供するために、ＥＳＧ／ＮＲＴを使用する。すなわち、ＥＡＴ―ＭＨは、ＥＡＳメッセージバイトと共に、リッチメディアコンテンツを受信できるＥＡＳ ＮＲＴサービスＩＤを含む。受信機は、ＮＲＴサービスＩＤをＳＭＴで探し、該当のｆｌｕｔｅコンポーネントのＩＰ住所とポート番号を探し出すことによってＥＡＳリッチメディアコンテンツを受信することができる。また、各ファイルと関連する情報は、ＥＳＧの内部に含まれて伝送されるので、関連する情報を探し出すためにＧＡＴのプロバイダサービスＩＤを探し出し、ＳＭＴでＥＳＧデータを伝送するＩＰとポート番号を探すことによってＥＳＧデータを受信することができる。このような過程を行ってＥＡＳメッセージとリッチメディアコンテンツを提供するためには、受信機でＥＳＧとＮＲＴサービスを支援しなければならない。

【0194】

図１６は、本発明の他の実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【0195】

本発明の他の実施例においては、ＥＳＧ／ＮＲＴを利用せず、緊急警報メッセージとＥＡＳリッチメディアコンテンツを伝送してシグナリングする方法を提示する。本発明の他の実施例によると、ＥＳＧ／ＮＲＴサービスを支援しない受信機でもＥＡＳリッチメディアコンテンツを受信処理することができる。

【0196】

本発明の他の実施例においては、緊急警報テーブルのＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値が０ｘ０４である場合を例に挙げて説明する。

【0197】

緊急警報テーブルに含まれたＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値が０ｘ０４である場合、緊急警報メッセージとＥＡＳリッチメディアコンテンツに対する伝送情報を緊急警報テーブルに埋め込んで（ｅｍｂｅｄｄｉｎｇ）伝送することを示す。例えば、緊急警報メッセージとＥＡＳリッチメディアコンテンツが４個である場合、各ＥＡＳリッチメディアコンテンツが伝送されるＩＰ／ポート情報と共に、各ＥＡＳリッチメディアコンテンツを区分できるＩＤ情報、そして、受信後にユーザーに見せるべきであるか否かに対する情報を示すｅｘｐｉｒａｔｉｏｎ、ｇｅｏｃｏｄｅ情報、及び／またはＥＡＳリッチメディアコンテンツの名前と拡張子を緊急警報テーブルを通じてシグナリングすることができる。

【0198】

ＥＡＳリッチメディアコンテンツは、緊急警報テーブルで記述されたＩＰデータグラムで伝送される。緊急警報テーブルは、ＥＡＳリッチメディアコンテンツを伝送するＩＰデータグラムを獲得できる情報を含む。

【0199】

図１６を参照すると、受信機は、緊急警報テーブルで緊急警報メッセージをパーシングして画面にディスプレイする。一方、受信機は、該当の緊急警報テーブルと関連する緊急警報コンテンツの個数及び該当のコンテンツを伝送するＩＰデータグラムの住所（ＩＰ＿ａｄｄｒｅｓｓ、Ｐｏｒｔ＿ｎｕｍｂｅｒ）を獲得し、該当の住所に接続する。受信機は、該当の住所で緊急警報コンテンツを含むＩＰデータグラムを受信し、これをパーシングすることによって緊急警報コンテンツをディスプレイする。

【0200】

図１７は、本発明の他の実施例に係る緊急警報テーブルを用いた緊急警報データ処理を示した図である。

【0201】

本発明の他の実施例においては、ＥＳＧ／ＮＲＴを利用せず、緊急警報メッセージとＥＡＳリッチメディアコンテンツを伝送してシグナリングする方法を提示する。本発明の他の実施例によると、ＥＳＧ／ＮＲＴサービスを支援しない受信機でもＥＡＳリッチメディアコンテンツを受信処理することができる。

【0202】

本発明の他の実施例においては、緊急警報テーブルのＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅフィールドの値が０ｘ０３である場合を例に挙げて説明する。

【0203】

ＥＡＳ＿ｍｅｓｓａｇｅ＿ｔｒａｎｓｆｅｒ＿ｔｙｐｅの値が０ｘ０３である場合は、緊急警報メッセージが緊急警報テーブルに含まれず、緊急警報テーブルでは、緊急警報メッセージが伝送されるＩＰデータグラムのＩＰ／ポート情報が記述される。

【0204】

この場合、緊急警報テーブルは、緊急警報メッセージとＥＡＳリッチメディアコンテンツが伝送されるＩＰ／ポート情報を含み、ＩＰ／ポート情報によって識別されるＩＰデータグラムの構造は、ＥＡＳ＿ｍｅｓｓａｇｅ＿ＩＤ、ＥＡＳ＿ｍｅｓｓａｇｅの長さ、及び実際のＥＡＳ＿ｍｅｓｓａｇｅのデータを含み、ＥＡＳリッチメディアコンテンツの個数、各ＥＡＳリッチメディアコンテンツに対する伝送情報／記述情報をさらに含むことができる。ＥＡＳリッチメディアコンテンツが伝送されるＩＰデータグラムの構造は、上述した通りである。

【0205】

図１８は、本発明の一実施例に係る放送受信機を示した図である。

【0206】

本発明の一実施例に係る放送受信機は、ＩＰインターフェース、放送インターフェース、シグナリングデコーダー、Ａ／Ｖデコーダー及び／またはディスプレイプロセッサを含むことができる。

【0207】

ＩＰインターフェースは、ＩＰ基盤のデータを受信処理する。例えば、上述したＩＰデータグラムを受信する役割をする。ＩＰインターフェースは、シグナリングデコーダーによって識別されたＩＰデータグラムを受信する役割をすることができる。

【0208】

放送インターフェースは、放送信号を受信処理する。放送インターフェースは、地上波放送、衛星放送、及び／またはケーブル放送信号を受信処理することができ、放送信号が変調された方式に従って、ＶＳＢ及び／またはＯＦＤＭ方式の復調を行う。

【0209】

シグナリングデコーダーは、上述したシグナリングと関連するデータ／情報をパーシングする。シグナリングデコーダーは、シグナリング情報がＩＰデータグラムを介して伝送される場合、ＩＰデータグラムをパーシングすることができる。シグナリングデコーダーは、放送信号に含まれたＰＳＩ（Ｐｒｏｇｒａｍ Ｓｐｅｃｉｆｉｃ ｉｎｆｏｒｍａｔｉｏｎ）、ＰＳＩＰ（Ｐｒｏｇｒａｍ ａｎｄ Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、及び／またはＳＳＣ（Ｓｅｒｖｉｃｅ Ｓｉｇｎａｌｉｎｇ Ｃｈａｎｎｅｌ）などのシグナリング情報をパーシングすることができる。シグナリングデコーダーは、シグナリング情報を各ユニットに伝送し、受信機が適切なデータをパーシング／デコーディングできるようにする。

【0210】

Ａ／Ｖデコーダーは、オーディオ／映像データをデコーディングする。

【0211】

ディスプレイプロセッサは、放送コンテンツ、緊急警報メッセージ、及び／または緊急警報コンテンツをディスプレイ処理する。

【0212】

説明の便宜のために各図面を分けて説明したが、各図面に敍述されている各実施例を併合し、新たな実施例を具現するように設計することも可能である。そして、当業者の必要に応じて、以前に説明した各実施例を実行するためのプログラムが記録されているコンピューターで読み取り可能な記録媒体を設計することも本発明の権利範囲に属する。

【0213】

本発明に係る装置及び方法は、上述した各実施例の構成と方法が限定されるように適用され得るものではなく、上述した各実施例は、多様な変形が可能になるように各実施例の全部または一部が選択的に組み合わされて構成されることもある。

【0214】

一方、本発明の映像処理方法は、ネットワークデバイスに備えられたプロセッサで読み取り可能な記録媒体にプロセッサで読み取り可能なコードとして具現することが可能である。プロセッサで読み取り可能な記録媒体は、プロセッサによって読まれるデータが格納される全ての種類の記録装置を含む。プロセッサで読み取り可能な記録媒体の例としては、ＲＯＭ、ＲＡＭ、ＣＤ―ＲＯＭ、磁気テープ、フロッピーディスク、光データ格納装置などがあり、また、インターネットを介した伝送などのキャリアウェーブの形態で具現されることも含む。また、プロセッサで読み取り可能な記録媒体は、ネットワークに連結されたコンピューターシステムに分散され、分散方式でプロセッサで読み取り可能なコードが格納されて実行され得る。

【0215】

また、以上では、本発明の好ましい実施例に対して図示して説明したが、本発明は、上述した特定の実施例に限定されるものではなく、特許請求の範囲で請求する本発明の要旨から逸脱することなく、当該発明の属する技術分野で通常の知識を有する者によって多様な変形実施が可能であることは当然であり、このような変形実施は、本発明の技術的思想や展望から個別的に理解されてはならない。

【0216】

そして、当該明細書では、物件発明と方法発明が全て説明されており、必要に応じて両発明の説明は補充的に適用され得る。

【0217】

発明を実施するための形態は、上述したように、発明を実施するための最善の形態で説明した。

【産業上の利用可能性】

【0218】

本発明は、放送産業全般で利用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】