JP2014194782A - 警報メッセージの配信をサポートする方法 - Google Patents

Abstract

【課題】警報メッセージの配信をサポートする方法を提供する。
【解決手段】ＮＧＮ（次世代ネットワーク）インフラストラクチャが配信のために使用される。インフラストラクチャは、エンドポイントを有する複数のネットワーク要素を含む。階層的アーキテクチャがネットワーク要素に対して定義される。特定の特性のエンドポイントを有するネットワーク要素からなるグループが定義され、ネットワーク要素のそれぞれが、少なくとも１つの上位ネットワーク要素に自己のグループメンバシップ情報を提供する。少なくとも１つのグループ警報コントローラが設けられ、グループ警報コントローラは、ソースノードから要求を受信した後、１つ以上のターゲットグループに対する警報メッセージを生成し、警報メッセージを、エンドポイントへ向かって、それぞれのターゲットグループの下位ネットワーク要素へ転送する。
【選択図】図２

Description

本発明は、警報メッセージの配信をサポートする方法に関する。

自然災害、事故、テロ攻撃等のような事象では、影響を受けるできるだけ多くの人間および機械に、できるだけ正確な情報を通知する必要がある。ほとんどの場合、特定の地点の近くの人間または機械が影響を受け、最高の優先度で迅速に情報を配信する必要がある。

例えば、図１に示す発電所事故の例が考えられる。このような場合、必要なアクションは、以下のプロセスおよびステップを含むであろう。
１．ゾーンＡ内の人に対して、ｘｙｚ病院へ行くように通知する。
２．ゾーンＢ内の人に対して、窓を閉め、テレビでニュースを見るように通知する。
３．ゾーンＢ内の機械（例えば、地元の発電所や工業生産ライン）に対して、緊急事態の影響を悪化させないために停止するように通知する。

サイレン、ラジオ放送等のような従来の警報システムは、それぞれの受信エリア内に位置する全員に対して直ちに連絡を行う。例えば、現在、さまざまな解決法が使用されており、例えば日本のＪＭＡ（気象庁、ＪＭＡ、非特許文献１および非特許文献２）、米国のＥＡＳ（Emergency Alert System, ＥＡＳ、非特許文献３および非特許文献４）、あるいはドイツのＳａｔＷａＳ（Satellitengestutzten Warnsystem SatWaS, 非特許文献５および非特許文献６）がある。これらのシステムはすべて、主に衛星通信を用いたテレビまたはラジオ放送により警報メッセージを配信するものであるため、現在進行中の番組を中断する。しかし、これらすべてのシステムは、緊急自然災害や防衛有事の場合等における、国内の全員に対する全国的な情報を目的としている。このことは、従来技術では、特定の集団の人々に連絡をする選択的方法が不可能であることを意味する。

３ＧＰＰ ＥＷＴＳ（Earthquake and Tsunami Warning System）の研究（Technical Report 23.828 に文書化されている）には、例えばＣＢＳ（Communication and Broadcast Service）やＭＢＭＳ（Multimedia Broadcast Multicast Service）のように、さまざまなローカルブロードキャスト技術を用いて、アタッチされた端末へブロードキャストメッセージを送信するための可能な解決法が記述されている。その実装はすべてレイヤ２に基づいているので、この場合も、警報メッセージの受信者を選択する手段は提供されていない。

地震に対する警報システムのもう１つの例として、ＮＴＴによって開発されたものは、ベストエフォート型伝送に基づいている（非特許文献７を参照）。このシステムは、ＩＰｖ６対応コンピュータの画面に表示されるインターネットベースの早期警報を提供するために、ＩＰｖ６マルチキャスト技術を使用する。同様に、ＣＷａｒｎ．ｏｒｇが、グローバルな津波警報通知システム（www.cwarn.org）として開発されている。ＣＷａｒｎは、グローバルな地震活動を監視し、会員の地点で津波のおそれが予報された場合には、その会員に対して、その会員の携帯電話にＳＭＳテキストメッセージを通じて警報を行う。どちらのシステムも、警報メッセージ配信プロセスのパーソナル化には対応していない。また、どちらのシステムも、使用される通信技術、すなわち、それぞれＩＰｖ６マルチキャストメッセージまたはＳＭＳテキストメッセージに、固く縛られている。

http://www.itu.int/ITU-D/tech/StandardizationGap/Tokyo2007/Presentations/9.MIC%20Murakami.pdf http://www.jma.go.jp/jma/en/Activities/telecommunications.html http://en.wikipedia.org/wiki/Emergency_Alert_System http://www.fema.gov/media/fact_sheets/eas.shtm http://de.wikipedia.org/wiki/SatWaS http://www.bbk.bund.de/cln_007/nn_401590/DE/02_Themen/11_Zivilschutztechnik/04_Warnsyst/01_SatWas/SatWas_node.html_nnn=true https://506506.ntt.com/internet/jishin/

したがって、本発明の目的は、頭書のような警報メッセージの配信をサポートする方法において、個別の警報メッセージに対して特定の受信者グループの生成が容易に可能となるようにすると同時に、配信プロセスができるだけフレキシブルかつ経済的になるような改良およびさらなる展開を行うことである。

本発明によれば、上記の目的は、請求項１の構成を備えた方法によって達成される。この請求項に記載の通り、本方法は、以下のことを特徴とする。すなわち、ＮＧＮ（次世代ネットワーク）インフラストラクチャが配信のために使用される。前記インフラストラクチャは、エンドポイントを有する複数のネットワーク要素を含む。階層的アーキテクチャが前記ネットワーク要素に対して定義される。特定の特性のエンドポイントを有するネットワーク要素からなるグループが定義され、前記ネットワーク要素のそれぞれが、少なくとも１つの上位ネットワーク要素に自己のグループメンバシップ情報を提供する。少なくとも１つのグループ警報コントローラが設けられる。該グループ警報コントローラは、ソースノードから要求を受信した後、１つ以上のターゲットグループに対する警報メッセージを生成し、該警報メッセージを、エンドポイントへ向かって、それぞれのターゲットグループの下位ネットワーク要素へ転送する。

本発明によって認識されたこととして、従来のメカニズム（例えばサイレン）に代えて、または加えて、特定のグループに通知または警報メッセージを配信するために次世代ネットワーク（ＮＧＮ）インフラストラクチャを使用することにより、サービスにアタッチしているユーザであってグループメンバシップ情報によって定義されるある特定の基準を満たすユーザに受信者グループをフレキシブルに限定することが可能となるという効果が得られる。この点に関して、単なる位置情報以外の特性を用いてグループを定義することにより、配信プロセスのパーソナル化が達成される。また、本発明による方法は、ＮＧＮがサポートするいかなるタイプのマルチメディアストリーム／メッセージを使用することも可能なので、高いフレキシビリティが得られる。その結果、配信プロセスが特定の通信技術に縛られることはない。さらに、警報メッセージは、ＮＧＮによって提供される保証付きＱｏＳ（サービス品質）で配信されることが可能である。

本発明において、ＮＧＮという用語は広義に解すべきであり、基本的には、ＩＴＵ−Ｔによって与えられた次の定義に従う。すなわち、次世代ネットワーク（ＮＧＮ）とは、電気通信サービスを含むサービスを提供可能であり、複数のブロードバンド、ＱｏＳ対応トランスポート技術を利用可能なパケット方式のネットワークであって、サービス関連機能は下位のトランスポート関連技術から独立している。ＮＧＮは、相異なるサービスプロバイダへのユーザによる無制限アクセスを提供する。ＮＧＮは、ユーザに対してサービスを整合的かつ普遍的に提供可能な一般化されたモビリティをサポートする。

本発明によるアーキテクチャでは、ＮＧＮ内のどこか（ユーザの自宅からコアネットワークまで）に位置するネットワーク要素が上位のグループ警報コントローラにアタッチし、グループ警報コントローラからのメッセージを、それぞれの要素にアタッチされたネットワーク要素およびその能力に従って配信する。その結果、警報メッセージは、エンドポイントへ向かって、それぞれのターゲットグループの下位ネットワーク要素へ転送されるため、下位ネットワーク要素は、その警報メッセージをレンダリングし、さらに配信することが可能である。一般的に、各ネットワーク要素自体は、メッセージを受信し、アタッチされているネットワーク要素から受信される情報に従ってそのメッセージを配信すること、および／または、シンクとして作用すること、すなわち、マルチメディアコンテンツをレンダリングすることができる。その限りにおいて、本発明は、テキスト、音声、画像、動画、およびサウンドのような通常のメディアレンダリングをサポートする任意のデバイスとともに動作する。

また、本発明は、緊急関連でない追加的サービスを可能にする。

好ましい実施形態によれば、ソースノード（これは、ネットワークベースのものであっても、ローカルセンサでも、あるいはそれらの組合せでもよく、例えば津波警報管理システムとすることが可能である）の要求が優先度情報を含むようにしてもよい。例えば、要求に、例えば１から１０までのスケールの優先度値を割り当て、１は最低優先度値（例えば花粉症に対する花粉の警報に用いられる）を示し、１０は最高優先度値（例えば津波や地震の警報に用いられる）を示すものとしてもよい。これに加えて、または別法として、要求は、メディアタイプを指定してもよく、および／または、警報メッセージを取得可能なメディアソースへのリンクを含んでもよい。テキスト情報のみの場合には、要求は、メッセージ自体を含むようにしてもよい。メディアソースへのリンクは、ローカルに、もしくは中央に蓄積されたコンテンツまたはマルチキャストストリームを参照してもよい。中央に蓄積されたコンテンツにおけるスケーラビリティの問題を避けるため、ソースノードは、ＮＧＮインフラストラクチャ内に分散されてもよい。

また、要求は、どの特定のターゲットグループがアドレス指定されているかに関する情報を含んでもよい。この点に関して、場所情報が、グループに含まれるか、または、何らかの適当なフォーマットで別個に伝送されるようにしてもよい。この場所情報は、例えばネットワークトポロジー情報または地理的座標に基づいてもよい。後者の場合、グループ警報コントローラは、地理的座標をネットワーク座標（例えばＤＳＬＡＭ ｘｙｚ等）にマッピングすることになる。

警報メッセージを配信するための効率的で正確な選択メカニズムとして、ターゲットグループは、ネットワーク要素の位置に基づいて定義されるようにしてもよい。例えば、グループは、特定の建物内に位置するすべてのネットワーク要素によって、あるいは、東京首都圏に位置するすべてのネットワーク要素によって形成されてもよい。ネットワーク要素の位置は、ネットワーク管理データベースによって識別されてもよい。エンドポイントであるネットワーク要素（すなわち、電話機、ラップトップコンピュータ、セットトップボックス、テレビ等のような、コンテンツをレンダリングすることのみが可能なＵＥ（ユーザ機器））の位置は、（例えば Broadband Forum TR-101 に記載されるような）ネットワークアタッチメント機能に基づいてもよい。この情報は、サービスプロバイダの顧客サービス・課金データベース内の情報と対応させることが可能である。これにより、特定の郵便アドレス（例えば、大規模なオフィスビル内のすべてのフロアのうちの一部であってもよい）に属するすべてのアクセス回線を識別することが可能である。

別法として、またはこれに加えて、ターゲットグループは、例えばユーザの疾病、ユーザの社会的特性、および／または受信能力（人間であれば見ること／聞くことや振動を感じることができるか、機械であればオフ／オンにすることができるか）を考慮して、ネットワーク要素の属性、プロファイルおよび／または能力に基づいて定義されてもよい。すなわち、グループは、実装に基づいて定義されてもよく、グループ警報コントローラで定義された意味に対応する一般的識別子によって表現されてもよい。グループメンバシップを組み合わせることも可能である。例えば、ホームゲートウェイＡは２つのターゲットグループのメンバであり、第１のターゲットグループは｛小さい子供のいる家庭｝として定義され、第２のターゲットグループは｛花粉症の人がいる家庭｝として定義され、エンドポイントＢはグループ｛盲人｝のメンバであり、ホームゲートウェイＡ、ＢおよびＣはグループ｛「メインストリート１５番地２階」に所在｝のメンバであってもよい。そして、グループメンバシップに基づいて、グループ警報コントローラによって生成された警報メッセージは、特定のグループに送られることが可能である。例えば、地震警報は、特定の地域内のすべてのネットワーク要素へ送信され、花粉症の人々に対する花粉警報は、対応するグループタグを有するエリア内のネットワーク要素へ送信される。いずれの場合でも、ターゲットグループを定義することにより、インテリジェントなグループ警報メッセージ配信が実現される。ターゲットグループは、位置、属性／プロファイル／能力により、メッセージを受け取る必要のある受信者のみを含み、むやみなブロードキャストは回避される。利用可能な（そして能力の変動し得る）デバイスに即座に適応することが可能である。

警報メッセージの効果的で高速な配信を達成するため、ネットワーク要素は、受信した警報メッセージを自らレンダリングすること、および／またはアタッチされているネットワーク要素へ転送することが可能である。警報メッセージを転送するか否かの決定は、それぞれのレンダリングまたは転送する側のネットワーク要素のローカルポリシーに基づいてもよい。上位ネットワーク要素は、アタッチされている下位ネットワーク要素のグループメンバシップを知っているので、上位ネットワーク要素は、アタッチされているどのネットワーク要素が警報メッセージを受信すべきであり、どのネットワーク要素が受信すべきでないかを決定することが可能となる。

グループメンバシップに加えて、ネットワーク要素は、上位ネットワーク要素にアタッチする際に、自己の能力のリストおよび／または自己の位置に関する情報を提供するようにしてもよい。これにより、上位ネットワーク要素は、例えば警報メッセージのフォーマットや品質を適応させることによって、下位ネットワーク要素の能力に適合する適当な形式で警報メッセージを転送することが可能となる。

各ネットワーク要素は、ローカルにアタッチされたセンサからグループ警報を受信することも可能である。そのようなグループ警報は、未承認のまま、アタッチされたネットワーク要素およびエンドポイントへ向かって下流側にのみ送信されるようにしてもよい。この場合の妥当な例として、公共建築物やオフィスビルのようなあらゆる大規模ビルディングに存在する火災報知器ボタンがある。センサにアタッチされたネットワーク要素は、階層の上方の管理システム、特にグループ警報コントローラへ警報を送信して、ローカルな事故について通知してもよい。このようなメッセージを受信したシステムは、ローカルポリシーや、さらにはユーザとのインタラクションに基づいて、この情報から他のネットワーク要素に対するグループ警報を作成すべきかどうかを決定することができる。例えば、建物Ａにおける火災の場合、システムは、近隣の建物ＣおよびＤへ、そしてさらに消防署へ、警報メッセージを送信することに決定してもよい。

有利な態様として、できるだけフレキシブルな解決法を達成するため、ネットワーク要素は、警報メッセージのコンテンツを拡充することが可能とされてもよい。すなわち、それぞれのレンダリングまたは転送する側のネットワーク要素は、ローカルポリシーに基づいて、情報の追加、置換または変更（例えば、ローカルにのみ意義を有するローカルに蓄積されている情報を追加すること）によって、緊急警報メッセージのコンテンツを拡充することに決定してもよい。標準化の観点から、そのような機能は、ＥＴＳＩ ＴＩＳＰＡＮ、Broadband Forum および３ＧＰＰによって規定されたネットワークアタッチメントサブシステムにおいて統合可能である。具体的な応用場面として、例えば、ホームゲートウェイは、緊急警報メッセージに対する画像として、当該建物に対して有効なローカルな非常出口または避難路の最新画像を（インラインで、またはダウンロードリンクとして）追加してもよい。この情報は、例えば施設管理チームによって、ローカルに蓄積・管理されることが可能である。画像は、建物内のエンドポイントへ向かって下流側にのみ送信される。ただし、追加される情報のタイプは、それぞれのグループと対応させる必要がある。

好ましい実施形態によれば、ネットワーク要素は、コンテンツをレンダリングするために、階層的アーキテクチャのエンドポイントを起動する（例えばテレビをつける）ようにしてもよい（ただし、エンドポイントがこの機能をサポートしている場合）。この目的のため、存在はしているがアクティブではないデバイスを始動させるための wake on LAN やその他の適当な手段を利用してもよい。デバイスが起動したら、例えばＵＰｎＰ（Universal Plug and Play）レンダラ等を利用することにより、デバイスの能力に応じて警報メッセージのコンテンツを再生させることができる。

別の好ましい実施形態によれば、階層的アーキテクチャのエンドポイントは、警報メッセージを受信もしくは再生／レンダリングしたこと、または適当なアクションを実行したことについてフィードバックをするようにしてもよい。緊急時には、通知が宛先に到達したかどうかのフィードバックを取得することが重要である。例えば、フィードバックメカニズムにより、当局は、警報システムの有効性パラメータを判定し、改良を行うことが可能となる。具体的応用場面として、例えば、消防隊は、建物に進入する前に、緊急警報がローカルエンドポイントによって肯定応答されたフロアおよびされたなかったフロアがあるかどうかを知っておくべきである。エンドツーエンドの用語では、宛先は、緊急手続きを実行する必要がある機械であるか、または人間であるかのいずれかである。人間の場合、受信者のコミットメントを待機することが実行可能とは限らないので、フィードバックは、コンテンツをレンダリングするエンドポイントによって提供されてもよい。フィードバックメッセージは、メッセージの識別子と、それを受信したデバイスおよびそれが実行したアクションの特性を含んでもよい。人間からのフィードバックの場合、「インタラクション」に関する具体的情報が含まれてもよい。

フィードバック通知の効率的でスケーラブルな処理に関して、ネットワーク要素は、受信したフィードバックを集約し、集約したフィードバックを上位ネットワーク要素に報告するようにしてもよい。

配信プロセスの信頼性および安全性を向上させるため、高優先度警報メッセージ（例えば地震警報）は、特定のグループ情報が利用可能でない場合には、インフラストラクチャのすべての登録されたネットワーク要素へブロードキャストされてもよい。これにより、警報システムは、中心的な構成ブロック、すなわちグループ情報提供が停止しても依然として動作することが保証される。

人間に対して警報メッセージを配信するメディアとして、ＮＧＮによってサポートされるすべての種類のメディアが使用可能である。特に、テレビ／動画ストリーム、テキストメッセージ（例えば携帯電話上でレンダリングされる）、音声メッセージおよび／または機械的メッセージ（例えば障害者のための振動等）が使用可能である。機械宛の警報メッセージの場合、メディアを表示する必要がないので、単純なコマンドをメディアとして使用してもよい。

場合によっては（例えば、火災が局所的に消火され、人々が自室に所在または帰還できる場合の火災報知）、ネットワーク要素、特にエンドポイントは、緊急警報を発する前に、以前に表示していたコンテンツの表示に戻ることが必要となる。このため、エンドポイントは、警報メッセージが受信される前に動作していた動作状態をキャッシュするための蓄積手段を備えてもよい。これにより、各ネットワーク要素は、警報メッセージをそれ以上レンダリングする必要がない場合に、通常動作を再開することが可能となる。

具体的実施形態において、キャッシュメカニズムは、シグナリングセッションを失わずに緊急警報配信のためのネットワーク内のリソースを解放して、後で継続することを暗黙的に考慮しつつ現在のアクションを中断することとして実現してもよい。別法として、新たなシグナリングを含むアクションの再開を実施してもよい。どちらの方法も、緊急警報の優先度に基づいて実施してよい。例えば、地震の場合、時間を浪費するのは無用であり、復旧のような手続きは後回しでよい。どちらの方法においても、二重のセッション課金を防止するために、セッションが既存のものの再開であるかどうかを課金システムが検出することを可能にするセッションキーを有することができる。

有利な態様として、警報メッセージは、メッセージおよびストリームの保証付き配信のため、ＮＧＮインフラストラクチャのＱｏＳシステムおよび／またはリソース制御システムとの相互作用により、適当なＱｏＳ優先順位（これは、例えば、経路上（オンパス）または経路外（オフパス）のいずれかの方法を用いて、ネットワーク内のリソース予約をトリガしている）を付けて送信される。フレームワークおよび機能は、ＱｏＳ制御システム、ローカル配信プロトコル（例えば、ＵＰｎＰやＳＩＰ）との相互作用による従来の標準の拡張に基づく。メディアトラフィックの優先順位付けを可能にするため、メッセージは、それが通る各ネットワーク要素上でＱｏＳ予約およびポリシー施行を暗黙的にトリガしてもよく、あるいは、リソースおよびアドミッション制御システム（例えば、ＥＴＳＩ ＴＩＳＰＡＮ ＲＡＣＳ）を明示的にトリガして、リソースの予約および割当を行うか、ネットワーク要素／エンドポイントが経路上でリソースを要求することを可能にするトークンを生成して伝達してもよい。リソースが不十分な場合、警報のほうが優先度が高ければ、既存のセッションを中断してもよい。メッセージ優先度はソースによって設定される。ソースは、中央のグループ警報コントローラであるか、またはシグナリング経路におけるネットワーク要素である。ただし、ＱｏＳおよびアドミッション制御を担当するシステムは、自己のポリシーに基づいて独立の決定を実行する。

本発明を好ましい態様で実施するにはいくつもの可能性がある。このためには、一方で請求項１に従属する諸請求項を参照しつつ、他方で図面により例示された本発明の好ましい実施形態についての以下の説明を参照されたい。図面を用いて本発明の好ましい実施形態を説明する際には、本発明の教示による好ましい実施形態一般およびその変形例について説明する。

従来技術による緊急警報メッセージを配信するための相異なるゾーンを一般的に例示する模式図である。 ＮＧＮベースのグループ警報を生成し配信するための本発明による方法の一実施形態を一般的に例示する模式図である。 図２に例示した実施形態で使用されるグループ警報メッセージを示す図である。

図２は、経済的かつインテリジェントな方法で警報メッセージを配信するために使用される、本発明による階層的ＮＧＮアーキテクチャを例示している。ネットワークアーキテクチャは、矩形のボックスで模式的に図示した複数のネットワーク要素を含む。右から左へ向かって、これらのネットワーク要素は、コアノード（その１つをセクタ１に例示）、エッジノード（その２つをセクタ２に例示）、アクセスノード（その２つをセクタ３に例示）、ホームゲートウェイ（その１つをセクタ４に例示）、そしてエンドポイントである。エンドポイントは、コンテンツをレンダリングすることのみが可能なネットワーク要素、すなわち、電話機、テレビ等のようなＵＥ（ユーザ機器）である。ＵＥは、人間ユーザとのインタフェースを有しない機械であってもよい。

各ネットワーク要素またはエンドポイントは、グループ警報メッセージサービスに加入する必要がある。そのために、階層内で１層上位に位置するネットワーク要素へ自己のアイデンティティおよび能力を送信する。サービスに明示的に加入していないネットワーク要素またはエンドポイントであっても、グループ警報メッセージの到達可能性を拡大するために、グループ警報メッセージを受信してもよい。これにより、例えば地震警報の場合には、ローカルなブロードキャストとなり得る。

図２の上部の実線矢印は、ネットワーク要素が上位ネットワーク要素にアタッチすることを例示しており、これにより、それぞれの能力およびグループメンバシップを示している。能力は、従来のＮＡＳＳ機能（例えば、ＥＴＳＩ ＴＩＳＰＡＮのｅ３′およびｅ３参照ポイント）を用いて、可能な限り交換されるべきである。３ＧＰＰ手順への本方法の拡張も可能である。ネットワーク要素の能力およびグループを上位ネットワーク要素にアドバタイズすることは、初期ネットワークアタッチメント中に実行可能であり、必要に応じて更新可能である。この目的のため、アクセスネットワークにおいては従来のプロトコルを再利用することが可能であるが、コアネットワーク内では、修正されたプロトコルが必要とされる。ネットワークに静的に接続されたネットワーク要素（アクセスノード、ルータ、スイッチ等）は、特定のプロトコルによって自己の能力をアドバタイズしてもよい。変更は、それぞれの場合に、暫定的な更新メッセージを用いて送信される。別法として、各ネットワーク要素は、静的なコンフィグレーションまたは自己検出に基づいて、メッセージを受信しレンダリングすることが可能な下位レベルのデバイスを識別することも可能である。

グループ警報機能は通常、ＮＡＳＳ機能に基づいてデータを拡充し転送することが可能なローカル配信およびＭＳＡＮ／ＢＲＡＳを保証するために、ホームゲートウェイで実施される必要がある。エンドポイントの場合、初期ネットワークアタッチメントにおいて、デバイスは、グループ警報コンテンツをレンダリングする能力を、ネットワークアタッチメントサブシステム（ＮＡＳＳ（network attachment subsystem）、例えばホームゲートウェイ、ＤＳＬＡＭ／ＭＳＡＮまたはＢＲＡＳ）へ送信されるメッセージに含める。可能な実装として、ＤＨＣＰオプションまたはＰＰＰベンダタグに基づくものが挙げられる。ホームゲートウェイやフェムトセルのようなネットワーク要素は、動的にネットワークにアタッチすることにより、エンドポイントにおいてそれらに類似の機能を実施する必要がある。

図２の下部の破線矢印は、警報メッセージ配信ツリーを例示している。図２の具体的実施形態では、コアノードはソースノードからトリガを受信する。ソースノードは、特定のエリアにおける地震を検出した地震警報システムである。トリガは、警報の優先度情報、メディアタイプ、警報メッセージを取得可能なメディアソースへのリンク、およびどのターゲットグループがアドレス指定されるかに関する情報を含む要求メッセージである。コアノードは、グループ警報コントローラを有する。グループ警報コントローラは、ソースノードから受信した要求メッセージに含まれる情報に基づいて、適当なグループ警報メッセージを生成する。この警報メッセージは、アドレス指定されたターゲットグループの下位ネットワーク要素へ段階的にレンダリングされる。すなわち、まずエッジノードへレンダリングされ、そこからアクセスノードへレンダリングされ、最後にインフラストラクチャのエンドポイントに到達する。ここで、「レンダリング」とは、機械の場合にはメディアの再生／表示またはアクションの実行のいずれか（例えば、グループ警報メッセージを下位ネットワーク要素へ転送すること）を意味する。配信の程度は、能力、グループ定義、登録、および／または警報のタイプに基づいて限定される。

前述したように、エンドデバイス（例えば、電話機、ＳＴＢ等）へ向かうネットワーク経路は、ネットワークのアーキテクチャおよびタイプに応じた複数のネットワーク要素を含む。例示した実施形態では、各エンドポイントまたはネットワーク要素は以下の機能を実施する。

１．アタッチされたネットワーク要素またはエンドポイントへ、それらのデバイスの能力、グループメンバシップおよび位置（またはその他の属性）に基づいて、メッセージを転送する。例：ＤＳＬＡＭ（Digital Subscriber Line Access Multiplexer）は、そのラインカード５、ポート９〜１２にアタッチされたデバイスがすべて、火災になっている建物に所在するので、それらのすべてのデバイスへ警報メッセージを転送する。

２．特定のグループ情報が利用可能でない場合、すべての登録されたネットワーク要素へ高優先度メッセージ（例えば地震警報）をブロードキャストする。

３．自己の能力に基づいてコンテンツをレンダリングする。例えば、地震が通知された場合に、ＤＳＬＡＭは警報サウンドを再生し、テレビは動画を表示し、ピクチャフレームはテキストメッセージを表示し、ＨｉＦｉシステムは音声シンセサイザでメッセージを読み上げてもよい。

４．上位レベルのグループ警報コントローラから対応する要求を受信した場合、コンテンツのレンダリングを停止する。前の動作に復帰する。例えば、花粉が飛散しているので花粉症の方々は窓を閉めるようにとのメッセージを表示した後、映画を続行する。

５．中断したサービスに対して顧客が支払をせずに済むように、実施したアクションに関して事業者の課金システムに通知する。

上に列挙したすべてのアクションは、デバイスのポリシーに基づいて設定可能である。デバイスを認証しその動作を標準化することが必要な場合もある。

図３は、ソースノードによってグループ警報コントローラＧＷＣへ送信された要求の例示的なメッセージフォーマットを示すスクリーンショットである。ソースノードは、例えば、津波警報センターである。この例は、ＸＭＬを用いてメッセージタイプを記述するデモンストレータから取られている。図３から分かるように、最初に、要求メッセージは、緊急メッセージが、「１０．２１．１．１」にあるＭＳＡＮ（Multi Service Access Node, マルチサービスアクセスノード）へ送信されることを示す通知を含む。「１０．２１．１．１」は、グループ警報コントローラＧＷＣのＩＰアドレスである。ターゲットの宛先を指定するため、要求メッセージはさらに、ターゲットのホームゲートウェイＨＧＷのＩＰアドレスを含む受信者リストを含む。さらに、要求メッセージは、緊急警報の分類を指定する。これは、図示した例では津波警報である。図３には明示的には示していないが、分類は、優先度指示を含んでもよい。最後に、要求メッセージは、関連する緊急動画メッセージのＵＲＬを含む。こうして、受信者リストに含まれているためにグループ警報メッセージを受信するユーザは、メッセージに示されているリンクをたどるだけで、それぞれのデバイス上に表示される動画を取得することができる。

なお、本発明は、例えばＷｉＭＡＸのような非固定回線アクセスでも動作する。この場合、基地局は、例えば、帯域制限と、できるだけ多くのユーザに連絡する必要性とから、テキスト警報のみを転送することに決定してもよい。また、本発明は、モバイルネットワーク、特に、アクセスドメインにおいてＩＰに基づくＬＴＥ（Long Term Evolution）ソリューションにも適用可能である。

上記の説明および添付図面の記載に基づいて、当業者は本発明の多くの変形例および他の実施形態に想到し得るであろう。したがって、本発明は、開示した具体的実施形態に限定されるものではなく、変形例および他の実施形態も、添付の特許請求の範囲内に含まれるものと解すべきである。本明細書では特定の用語を用いているが、それらは総称的・説明的意味でのみ用いられており、限定を目的としたものではない。

Claims (16)

1. 警報メッセージの配信をサポートする方法において、
   ＮＧＮ（次世代ネットワーク）インフラストラクチャが配信のために使用され、
   前記インフラストラクチャが、エンドポイントを有する複数のネットワーク要素を含み、
   階層的アーキテクチャが前記ネットワーク要素に対して定義され、
   特定の特性のエンドポイントを有するネットワーク要素からなるグループが定義され、前記ネットワーク要素のそれぞれが、少なくとも１つの上位ネットワーク要素に自己のグループメンバシップ情報を提供し、
   少なくとも１つのグループ警報コントローラが設けられ、該グループ警報コントローラは、ソースノードから要求を受信した後、１つ以上のターゲットグループに対する警報メッセージを生成し、該警報メッセージを、エンドポイントへ向かって、それぞれのターゲットグループの下位ネットワーク要素へ転送することを特徴とする、警報メッセージの配信をサポートする方法。
2. 前記ソースノードの要求が、優先度情報、メディアタイプ情報、メディアソースへのリンク、および／またはどのターゲットグループがアドレス指定されるかに関する情報を含むことを特徴とする請求項１に記載の方法。
3. 前記ターゲットグループが、前記ネットワーク要素の位置、属性、プロファイルおよび／または能力に基づいて定義されることを特徴とする請求項１または２に記載の方法。
4. 前記ネットワーク要素が、アタッチされているネットワーク要素へ、受信した警報メッセージを配信することを特徴とする請求項１ないし３のいずれか１項に記載の方法。
5. 前記ネットワーク要素が、自己の能力のリストおよび／または自己の位置に関する情報とともに、上位ネットワーク要素にアタッチすることを特徴とする請求項１ないし４のいずれか１項に記載の方法。
6. 前記ネットワーク要素は、ローカルセンサから警報メッセージを受信した後、アタッチされているネットワーク要素へ前記警報メッセージを配信することを特徴とする請求項１ないし５のいずれか１項に記載の方法。
7. 前記ネットワーク要素は、前記警報メッセージのコンテンツを拡充することが可能とされることを特徴とする請求項１ないし６のいずれか１項に記載の方法。
8. 前記ネットワーク要素が、前記階層的アーキテクチャのエンドポイントを起動することを特徴とする請求項１ないし７のいずれか１項に記載の方法。
9. 前記階層的アーキテクチャの前記エンドポイントが、警報メッセージを受信したことおよび／または適当なアクションを実行したことに関するフィードバックを提供することを特徴とする請求項１ないし８のいずれか１項に記載の方法。
10. 前記ネットワーク要素が、受信したフィードバックを集約し、集約したフィードバックを上位ネットワーク要素に報告することを特徴とする請求項９に記載の方法。
11. 特定のグループ情報が利用可能でない場合、高優先度警報メッセージが、前記インフラストラクチャのすべてのネットワーク要素へ配信されることを特徴とする請求項１ないし１０のいずれか１項に記載の方法。
12. 前記警報メッセージのメディアとして、テレビ／動画ストリーム、テキストメッセージ、音声メッセージおよび／または機械的メッセージが使用されることを特徴とする請求項１ないし１１のいずれか１項に記載の方法。
13. 前記ネットワーク要素は、前記警報メッセージが受信される前に動作していた動作状態をキャッシュする蓄積手段を備えることを特徴とする請求項１ないし１２のいずれか１項に記載の方法。
14. 前記エンドポイントは、警報メッセージを受信した後、現在のアクションを中断し、同じシグナリングセッションに基づいて後で該アクションを続行することを特徴とする請求項１３に記載の方法。
15. 前記エンドポイントは、警報メッセージを受信した後、現在のアクションを中止し、新たなシグナリングセッションを含む再開に基づいて後で該アクションを続行することを特徴とする請求項１３に記載の方法。
16. 前記警報メッセージが、適当なＱｏＳ（サービス品質）優先順位を付けて送信されることを特徴とする請求項１ないし１５のいずれか１項に記載の方法。

Images