JP2011501923A - Ｍｂｍｓにおける緊急警報の配信 - Google Patents

Abstract

本発明は、マルチメディア放送マルチキャストサービス（ＭＢＭＳ）を動作させる、ネットワークにおいて緊急警報を配信する方法及び装置を提供する。ネットワークは、ＭＢＭＳセッションをリスンしている端末へ向けて、ペイロードチャネルを用いてＭＢＭＳコンテンツデータを配信するサーバを備える。サーバにおいて緊急警報が受信されると、緊急警報はＭＢＭＳ緊急コンテンツデータとして符号化され、他のコンテンツデータとは異なるデータとして緊急コンテンツデータにラベルが付けられる。次いで、緊急コンテンツデータは既存のペイロードチャネルで端末へ伝送される。

Description

本発明は、マルチメディア放送マルチキャストサービス（ＭＢＭＳ）における緊急サービスの提供に関する。特に本発明はＭＢＭＳにおける緊急メッセージの配信に関する。

マルチメディア放送／マルチキャストサービスがますます重要性を増してきている。移動携帯型デバイスが無線ネットワークを介してマルチメディアコンテンツを受信できるようになって以来、この重要性はさらに高まってきている。

しかし、無線チャネルを介する携帯型デバイスへのマルチメディアの配信は非常に重要なタスクである。加入者は、同じコンテンツを受信しながら異なるチャネル品質を経験することができる。さらに、個々のユーザは配信メディアの可能な最高品質を所望する。

ＵＭＴＳ地上無線接続（ＵＴＲＡ）におけるマルチメディア放送マルチキャストサービス（ＭＢＭＳ）（３ＧＰＰ ＴＳ２３．２４６）の導入によって、ポイント・ツー・マルチポイント伝送のようなＭＢＭＳベアラサービス（bearer servuce)の最適化された伝送と、選択的組み合わせと、ポイント・ツー・マルチポイント（ＰＴＭ）ベアラとポイント・トゥー・ポイント（ＰＴＰ）ベアラ間での伝送モード選択とのための技術が提供されることになる。ＭＢＭＳ論理伝送チャネルが定義され、物理チャネルにマップされる。基本論理チャネルは以下のようになる：
（ａ）ＭＢＭＳポイント・ツー・マルチポイント制御チャネル（ＭＣＣＨ）：この論理チャネルは、ネットワークとユーザ機器（ＵＥ）間での制御プレーン情報のＰＴＭダウンリンク伝送のために用いられる。
（ｂ）ＭＢＭＳポイント・ツー・マルチポイントトラフィックチャネル（ＭＴＣＨ）：この論理チャネルはネットワークとＵＥ間でのユーザプレーン情報のＰＴＭダウンリンク伝送のために用いられる。
（ｃ）ＭＢＭＳ通知インジケータチャネル（ＭＩＣＨ）：この論理チャネルは、ＭＣＣＨで提供される情報の変更について、リッスン中のＵＥに通知を行うために用いられる。
（ｄ）ＭＢＭＳポイント・ツー・マルチポイントスケジューリングチャネル（ＭＳＣＨ）：この論理チャネルは、ネットワークとＵＥ間でのＭＢＭＳサービス伝送スケジュールのＰＴＭダウンリンク伝送のために用いられる。

したがって、ＭＢＭＳによって、単一ソースから複数の受け手へのデータの伝送が可能となる。このデータ伝送は（移動ＴＶなどの）データのストリーミングによって、あるいは、（ポッドキャストなどの）ファイルのダウンロードによって実現され得る。

ＭＢＭＳサービスはその一時的モバイルグループアイデンティティ（ＴＭＧＩ）によって一意に特定することができる。使用する配信方法がファイルのダウンロードである場合、「サービス」という用語は通常会員登録モデルに従って相互に関係する１組のファイルを表すものとする。例えば、ユーザが特定のショーの視聴を申し込んだり、ユーザの会員登録期間の間定期的にそのショーのエピソードを受信したりする場合が考えられる。次いで、すべてのエピソードが同じＴＭＧＩを共有することになる。

３ＧＰＰにおいて、放送／マルチキャストサービスセンタ（ＢＭ−ＳＣ）と呼ばれる論理コンポーネントが、サービスを実現するサービスレイヤ内のＭＢＭＳ機能を提供する。ＢＭ−ＳＣは、５つの主要な機能、すなわち、メンバーシップと、セキュリティと、セッション＆伝送と、プロキシ＆トランスポートと、サービスアナウンスとを提供する。新規ファイル又は１組のファイルが特定のサービス用としてコンテンツプロバイダによって利用できるようになる度に、ＢＭ−ＳＣは、対応するＴＭＧＩ用のＭＢＭＳセッションをオープンし、ファイル／１組のファイルを伝送し、ＭＢＭＳセッションを閉じる。サービスの有効期間中ＭＢＭＳセッションをオープン状態のままにしておくことも可能である（これはストリーミングによってデータが配信される場合である）ことは理解できよう。但し、これは、ファイルデータフローが連続しなくなるのでファイルのダウンロード用としては避けるべきである。

無線インタフェース上で、ＭＢＭＳペイロード（実際のメディアコンテンツ）がＭＴＣＨでトランスポートされるのに対して、セル内の進行中のＭＢＭＳセッションに関する情報（ＭＢＭＳセッションのＴＭＧＩを含む）はＭＣＣＨで運ばれる。これに関連して、ペイロードは他の層から得られるヘッダを含んでもよいことは理解されよう。ＭＢＭＳはＩＰ層の上方にある任意のものをペイロードと見なすからである。

ＵＥは利用可能なサービスリスト及び関連するＴＭＧＩをサービスアナウンス段の間に取得する。この取得は通常アプリケーションの起動時に行われる。ＴＭＧＩは１組のセッション記述プロトコル（ＳＤＰ）ファイルの中に埋め込まれる。ＵＥは、ユーザの会員登録に関連するＴＭＧＩ用のＭＣＣＨをリスンし、次いで、１つのＴＭＧＩがマッチすると、ＵＥは実際のコンテンツを受信するためにＭＴＣＨチャネルに同調する。これについては３ＧＰＰ ＴＳ２６．３４６、「マルチメディア放送／マルチキャストサービス（ＭＢＭＳ）；プロトコル及びコーデック」にさらに詳細に記載されている。

ＭＢＭＳを介して提供される「緊急警報サービス」を定義し、これをサポートしたいという要望がある。緊急警報が出されると、その緊急警報を受信し、直ちにこれを表示することが好まれる。通信事業者による至急原稿の受信と、エンドユーザのスクリーン上でのファイルの表示との間の経過時間は数秒以下であることが望ましい。さらに、緊急警報を事前にスケジュールできないことは明らかである。

上記表示を実行する１つの方法として、特定のＴＭＧＩによって同定される専用のＭＢＭＳベアラを介して緊急警報サービスを提供する方法がある。警報が出されると、ＵＥは、緊急警報サービスに対応するＴＭＧＩをＭＣＣＨ上で検出し、任意の進行中のダウンロードセッションやストリーミングセッションを停止し、緊急ファイルを受信して、該緊急ファイルを即座に表示することになる。上記を行うには、ＵＥがＭＣＣＨを連続的にモニタして、ＵＥがＭＢＭＳを介して他のサービスを受信しているときでさえ、（緊急セッションの起動を検出するために）緊急警報サービスに関連づけられたＴＭＧＩの存否をチェックするようにすることが要件とされる。これは、特にＭＢＭＳの初期の段階では、必ずしもすべての端末によりサポートされている機能というわけではない場合も考えられる。さらに、これは、端末が一度に１つのＭＢＭＳしか受信できない場合、他のいずれかの進行中のＭＢＭＳセッションがドロップされることを要件とするものとなる。

この問題に対する１つの解決策として、緊急警報が受信されると、ネットワーク内の進行中のＭＢＭＳセッションのすべてをＵＥに停止させるという解決策がある。これは、ＵＥの現在のダウンロード（何らかのダウンロードが存在する場合）をすべてのＵＥに停止させることを目的とするものである。次いで、緊急セッションが開始され、この新しく開かれた緊急セッションを用いて緊急警報メッセージが伝送される。それまでアクティブであったダウンロードが失敗し、ＵＥの緊急セッションへの切り替えと緊急警報の表示とが可能になる。しかし、この解決策はエレガントでも効率的でもない解決策であり、ファイルのダウンロードが急に停止されることになって、重いリカバリ処理手順の発生が考えられる。さらに、この処理全体が数秒間よりもはるかに長い時間を要するものとなることが推定され、このような長時間の処理は容認できるものではない。

本発明の１つの側面によれば、ネットワークにおいて緊急警報を配信する方法が提供され、該方法は、マルチメディア放送マルチキャストサービス（ＭＢＭＳ）を動作させものである。ネットワークは、ＭＢＭＳセッションをリスンしている端末へ向けて、ペイロードチャネル（ＭＢＭＳベアラ）を用いてＭＢＭＳコンテンツデータを配信するサーバを備える。サーバにおいて緊急警報が受信されると、別のＭＢＭＳコンテンツデータとは異なるラベルをこの緊急警報につけることによって、緊急警報はＭＢＭＳ緊急コンテンツデータとして符号化される。次いで、緊急コンテンツデータはすべての確立されたＭＢＭＳベアラ上で伝送される。

好適には、他のサービスのためのＭＢＭＳコンテンツデータをまだ受信していない任意の端末に対して緊急コンテンツデータを伝送するために、特定のＴＭＧＩによって同定される専用のＭＢＭＳベアラが確立されることも望ましい。

端末は、緊急コンテンツデータを受信すると、この緊急コンテンツデータが緊急警報に関するものである旨を特定することが可能であり、次いで、この緊急警報を復号して、他のいずれのコンテンツデータよりも高い優先順位で該緊急警報をユーザに提示しなければならない。ユーザへの本提示は、例えばグラフィカルな表示と音声警報の少なくともいずれかの形の提示であってもよい。

緊急コンテンツデータは他のコンテンツデータとインタリーブされることが望ましい。但し、いくつかの実施形態では、緊急コンテンツデータが単一のファイル形式又は隣接するデータブロック形式を得ることは理解できよう。この場合「インタリーブされる」という表現は、他のコンテンツデータのペイロードよりも先に、後に、あるいは該ペイロードと同時に伝送されることを単に意味するものとする。

好適な実施形態では、他のコンテンツデータに対して割り当てられたポート番号とは異なる緊急用ポート番号が緊急コンテンツデータに対して割り当てられる。このことは、端末が緊急コンテンツデータと他のコンテンツデータとを容易に区別できること、及び、１つのかつ同じペイロードチャネルを用いて上記両方のコンテンツデータの伝送が可能であることを意味する。

上記緊急用ポート番号は、端末内のＭＢＭＳクライアントの起動時にサーバによって示されるようにしてもよい。例えば、緊急用ポート番号はセッション記述プロトコル（ＳＤＰ）ファイルの形で伝送されてもよい。上記とは別に、緊急用ポート番号は、すべてのＭＢＭＳセッションで用いられる標準ポート番号として予め定義されていてもよいし、あるいは、（工場設定値としての又は無線（ＯＴＡ）構成を介するような）アドホックな手段によって端末の中で構成されてもよい。

緊急コンテンツデータ及び他のコンテンツデータは端末によってダウンロードされたファイルの形やストリームデータの形のものであってもよい。

本発明の別の側面によれば、マルチメディア放送マルチキャストサービス（ＭＢＭＳ）を動作させる、ネットワークにおいて用いられるサーバが提供される。サーバは送信機を備え、該送信機は、ＭＢＭＳセッションをリスンしている端末へ向けて、ペイロードチャネルを用いてＭＢＭＳコンテンツデータを配信するように構成される。受信機が外部発信元から緊急警報を受信するように構成される。プロセッサは、送信機及び受信機と動作可能に接続され、かつ、ＭＢＭＳ緊急コンテンツデータとして緊急警報を符号化すると共に、他のコンテンツデータとは異なるデータとしてこの緊急コンテンツデータにラベルを付けるように構成される。送信機はペイロードチャネルを用いて緊急コンテンツデータを端末へ伝送するように構成される。

本発明のさらに別の側面によれば、ネットワークにおいて用いられる端末が提供され、該端末は、マルチメディア放送マルチキャストサービス（ＭＢＭＳ）を動作させる。端末は、ＭＢＭＳ緊急コンテンツデータ及び他のコンテンツデータをサーバから受信するように構成された受信機をペイロードチャネルの中に備える。プロセッサは、受信機と動作可能に接続され、かつ、緊急コンテンツデータと他のコンテンツデータとを区別するように構成されると共に、緊急警報を元に戻すためにＭＢＭＳ緊急コンテンツデータの復号を行う。（ディスプレイなどの）表示装置はプロセッサと動作可能に接続され、かつ、ユーザに対して緊急警報を提示するように構成される。

ＭＢＭＳにおいて従来技術により緊急警報を伝送する方法でサーバとＵＥ間で行われるトラフィックを示す概略表示図である。 緊急警報を伝送し、表示する際にサーバとＵＥ間で行われるトラフィックを示す概略表示図である。 ＭＢＭＳサーバの概略表示である。 ＵＥの概略表示図である。 緊急警報の配信及び表示を示すフローチャートである。

ＭＢＭＳのサービス配信の側面については、３ＧＰＰ ＴＳ２６．３４６に詳細な記載があるので、この記載を本明細書で再現する必要はない。しかしファイル配信については簡単に解説する。放送（Broadcast）及びマルチキャストはダウンリンクでの一方向の伝送である。したがって、伝送制御プロトコル（ＴＣＰ）が採用されることはあり得ない。なぜなら伝送制御プロトコルは双方向のユニキャスト接続を必要とするからである。しかし、インターネット技術標準化委員会（ＩＥＴＦ）は１方向のトランスポートを介するファイル配信（ＦＬＵＴＥ）という名称の、ユニキャストを介するファイル配信用フレームワークを提供している。そして放送の場合にもこのフレームワークを再利用することができる。ＦＬＵＴＥはそのベースとなるトランスポートプロトコルとしてユーザデータグラムプロトコル（ＵＤＰ）を採用している。

図１は緊急警報を配信するための１つの可能なシステムを示す図である。図１はサーバ１とＵＥ２との間のトラフィックを示す概略表示図である。図１に示されているように、ＭＢＭＳセッションは最初アクティブであり（３）、（ファイルのダウンロードの形やストリーミングデータの形に関らず）ＵＥ２へのコンテンツデータの転送を可能にする。サーバにおいて緊急警報が受信される（４）と、すべてのユーザに彼らの現在のダウンロード（何らかのダウンロードが存在する場合）を停止させるために、ネットワーク内のすべての進行中のＭＢＭＳセッションが停止される（５）。次いで、緊急セッションがサーバにより開始される（６）。本例ではこのセッションはＴＭＧＭとラベルが付けられている。次いで、新しく開かれた緊急セッションを用いて緊急警報メッセージが伝送される（７）。それまでアクティブであったダウンロードは失敗し、ＵＥの緊急セッションへの切り替えと緊急警報の表示とが可能になる。前述したように、この解決策はエレガントでも効率的でもない解決策であり、ファイルのダウンロードが急に停止されることになって、重いリカバリ処理手順の発生が考えられる。さらに、この処理全体が数秒間よりもはるかに長い時間を要するものとなることが推定され、このような解決策は容認できるものではない。

図２は緊急警報を配信するための好適なシステムを示す図であり、ＭＢＭＳを用いてコンテンツデータを配信する際のサーバ２１とＵＥ２２との間のトラフィックを示す概略図である。他のノード（図示せず）がサーバ２１とＵＥ２２間でのデータの配信に関与できることは理解できよう。サーバ２１から同じデータを受信する２以上のＵＥが存在し得ることも理解されるであろう。まず最初に、ＵＥ２２がリスンしているＭＢＭＳセッション２３がアクティブになる。図２はこのようなセッションをセットアップするために要求されるシグナリングを示すものではなく、この図は３ＧＰＰ ＴＳ２６．３４６に記載されているものである。

ここで、当局から出された緊急警報２４がサーバ２１において受信されたと仮定する。政府関連機関から緊急ファイルを受信すると、サーバ２１はこの緊急ファイルを複製し、（現在ＭＢＭＳセッションをリスンしていないユーザのために専用のＭＢＭＳ緊急セッションをセットアップするステップに加えて）個々のアクティブなＭＢＭＳセッション時にコピーを伝送する。本例では、図はＵＥ２２がリスンしているアクティブなＭＢＭＳセッション２３を示す。したがって緊急警報はアクティブなセッションを用いてＵＥ２２へ伝送される（２５）。アクティブなセッションのＴＭＧＩは元のままであるが、緊急警報は別のポート番号で伝送される。図２に示す例では、緊急用ポート番号は［１２３４６］である。ＵＥはこのポート番号で受信されたメッセージが緊急メッセージであり、これらのメッセージが即座にユーザに提示されることを認知している（２６）。ユーザへのこの提示が、例えばグラフィカルな表示や可聴信号などの任意の好適な形のものであってもよいことは理解できよう。

サーバが多数の異なるサービスを様々なユーザへ提供できるため、（単複の）緊急ファイルは、当該緊急ファイルがどのＭＢＭＳセッションで伝送されるかに対応して種々のＴＭＧＩに関連づけられる場合があることに留意されたい。

ポート番号［１２３４６］で受信されたメッセージが緊急メッセージである旨をＵＥが認知することを保証するために、２つの主要な選択肢が提供される。最初に、サービスアナウンス時にＵＥへ伝送されるセッション記述ファイルには、緊急ファイルが、該緊急ファイルに関連づけられたポート番号と共に、アクティブなセッション内にいつでも伝送できる旨の可能性に関する情報が含まれていなければならない。次いで、ＵＥは当該ポート番号で受信されたファイルを優先し、かつ、これらのファイルを即座にユーザに提示することが望ましい。第２の選択肢では、ポート番号はＵＥによって事前に認知されている。これは、インターネット・アサインド・ナンバー・オーソリティ（ＩＡＮＡ）によるポート番号の事前割当てにより実現可能であり、それによって割り当てられたポート番号で伝送されるすべてのメッセージが緊急メッセージとなると共に、ＵＥはこれらのメッセージを優先させる方法を知っている。上記とは別に、ポート番号は工場設定値又は無線（ＯＴＡ）構成のようなアドホックな手段によって構成してもよい。

次にこれら２つの選択肢についてさらに詳細に解説する。

［１：ＳＤＰファイルにおけるポートネゴシエーション］
サービスアナウンス中に（すなわち一般にＵＥにおいてＭＢＭＳサービスがアクティブにされているとき（図２には図示せず））、ＵＥはサービスについて記載されているＳＤＰファイルを受信する。３ＧＰＰ ＴＳ２６．３４６からとられた一例は以下のようになる：
v=0：
o=userl23 2890844526 2890842807 IN IP6 2201 : 056D : : 112E : 144A: 1E24
s=FiIe delivery session example
t=2873397496 2873404696
a=mbms-mode: broadcast 1234 1 // 1234 is the TMGI
a=FEC-declaration : 0 encodmg-id=l
a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9
a=flute-tsi:3
m=application 54321 FLUTE/UDP 0 // port number 4321
c=IN IP6 FFlE: 03AD: : 7F2E: 172A: 1E24/1
b=64

緊急サービスをサポートするために、ＳＤＰファイルは以下の例示の行を追加することにより更新されることが望ましい。
m=emergency 12346 FLUTE/UDP 0 // port number for emergency 12346
c=IN IP6 FFlE: 03AD: : 7F2E: 172A: 1E24/1

この行は、ポート番号１２３４６へ伝送される任意のメッセージが緊急メッセージであること、及び、これらのメッセージが即座にユーザに提示されることが望ましいことを確認するものである。この緊急用ポート番号はサーバによって選択され、次いで、すべてのユーザへ放送されることに留意されたい。

（図２に記載のような）ＭＢＭＳサービスを受信すると、ＵＥは、（通常のコンテンツデータが配信される）ポート５４３２１と、ポート１２３４６との両方をリスンしなければならない。

［２：事前割当てポート］
ＩＡＮＡが緊急サービス用としてある特定のポート番号を割り当てる得ることが想定されている。

ＭＢＭＳサービスを受信すると、エンドユーザは、（上述のような）ＳＤＰファイルの形で示されるようなコンテンツデータ用の標準ポートと、ＩＡＮＡによって割り当てられている緊急用ポートとの両方をリスンすることになる。

別の代替例として、工場設定値やＯＴＡ構成のようなアドホックな手段によって事前割当てポートを端末内に構成することができる。

図３はＭＢＭＳサービスを提供するサーバ３１の概略表示図である。サーバは図２に示すサーバ２１であってもよい。サーバには、コンテンツデータを格納するためのメモリ３２と、データを符号化するためのマイクロプロセッサ３３が含まれる。送信機３４は受け手へ向けてデータを伝送する。受信機３５は当局から緊急警報を受信し、次いで、この緊急警報はマイクロプロセッサ３３によって認識される。アクティブなセッションのペイロードの内部において、並びに、受信機３５による緊急警報の受信時に確立される専用セッションで緊急警報は送信機３４により伝送される。緊急警報ファイル（又はデータ）はこれらに関連づけられたポート番号によって他のファイル又はデータと区別される。

図４はＭＢＭＳサービスを受信するＵＥ４１の概略表示である。ＵＥは図２に示すＵＥ２２であってもよい。ＵＥ４１はサーバからのファイルのダウンロードを受信する受信機４３を含む。ファイルはメモリ４４に記憶されると共に、ディスプレイ４６又は他のプレゼンテーションインタフェースを介してユーザに提示される前にマイクロプロセッサ４５により処理されてもよい。任意のアクティブなＭＢＭＳセッションに対して、ＵＥは２つのポート、すなわち「通常のコンテンツ用」ポートと、「緊急事態用」ポートとをモニタする。通常のコンテンツポートへ配信されるデータは通常データとして保存され、処理され、次いで、表示される。緊急用ポートへ配信されたデータは優先され、即座にユーザに提示される。

図５は、緊急警報をＵＥへ伝送するステップに関与する主要処理を示すフローチャートである。

Ｓ１：ＭＢＭＳサーバは緊急用ポート番号を割り当て、サービスアナウンス（すなわちすべてのＭＢＭＳサービスのＳＤＰファイル）の中にこの緊急用ポート番号を含める。緊急用ポート番号がＩＡＮＡによってすでに割り当てられていたり、すべてのＵＥにおいてアドホックな手段によって供給されていたりすればこのステップは不要である。

Ｓ２：ＭＢＭＳサーバにおいて当局から緊急警報が受信される。

Ｓ３：緊急警報は、緊急コンテンツデータとして符号化され、発信データフローの中へ挿入可能な状態になる。

Ｓ４：サーバによって伝送される他のコンテンツデータとは異なるデータとして緊急コンテンツデータにラベルが付けられる。このラベル付けは緊急用ポート番号を緊急コンテンツデータと関連付けることによって行われることが望ましい。緊急用ポート番号は、サーバによって伝送される他のコンテンツデータに関連づけられた（単複の）ポート番号とは異なる番号となる。

Ｓ５：緊急コンテンツデータはすべてのアクティブなＭＢＭＳセッションの発信データフローの中へ挿入される。配信方法がファイルのダウンロードであれば、この配信方法には、新規ファイルが（例えばファイル転送テーブル（ＦＤＴ）などによって）利用可能である旨の情報をＵＥに通知するステップが含まれ、かつ、ＵＥはサーバから上記ファイルを受信することになる。

Ｓ６：サーバは（「緊急事態」ＴＭＧＩによって識別される）専用のＭＢＭＳセッションを確立し、それによってＭＢＭＳセッションに何ら関わりのないＵＥまでも緊急警報を受信することになる。実際にはこのステップはステップＳ５と並行して行われる。

Ｓ７：緊急警報は関連付けられた緊急用ポート番号を有する個々のリスン中のＵＥによって受信される。

Ｓ８：個々のＵＥは、緊急用ポート番号で受信されたファイルが緊急警報であることを認知する。したがってファイルは即座にユーザに提示される。

したがって、ＭＢＭＳセッションが進行中であるとき、複数のＴＭＧＩをモニタする機能に関する端末の制限にかかわりなく、かつ、いずれのアクティブなＭＢＭＳセッションの急激な解除も行う必要なく、ユーザがＭＢＭＳを介して緊急警報メッセージを受信することがわかる。

さらに、ＵＥがファイルを受信するよりも前にＭＢＭＳセッションを確立しなければならない場合に比べて、ＵＥがＭＢＭＳセッションを予めアクティブにしているときの方が、通信事業者（サーバ）による緊急ファイルの受信とユーザへの実際の表示との間の時間が大幅に短縮される。

上記実施形態からの変更例が本発明の範囲に含まれ得ることは理解できよう。例えば、緊急警報ファイル又はデータはアクティブなＭＢＭＳセッションのデータフローの中へ挿入される。さらに、記載の実施形態には、ＵＤＰポート番号を用いることによって緊急警報ファイル又はデータの識別子が含まれる。緊急警報を特定する別の方法も想定可能であることは理解できよう。例えば、コンテンツタイプを示すフィールドなどによって、ＵＤＰ／ＩＰの上方にある層において緊急メッセージを潜在的に特定することも可能である。ＦＬＵＴＥセッション時に、コンテンツファイルの伝送の方が、転送される（単複の）データファイルの属性について記述しているファイル転送テーブル（ＦＤＴ）の伝送よりも常に先行して行われる。これらの属性のうちの１つの属性としてコンテンツタイプがある。したがって、例えば、即座に提示されなければならない緊急メッセージとしてファイルを明瞭に特定する、「緊急事態」などのような新しいコンテンツタイプの指定も可能であることが想定できる。しかし、このような指定を行うには、ファイルの性質を確認できようになる前にＦＤＴの受信と処理とを行うことが要件となる。

さらに、緊急ファイルは他のコンテンツファイルとは異なるフォーマットとなる場合もあることは理解できよう。例えば、他のコンテンツファイルがビデオファイルであるのに対して、緊急ファイルがオーディオファイルである場合も考えられる。緊急ファイルのフォーマットはＳＤＰファイルの形で示されることも可能である。但し、ファイルのダウンロードの場合、ファイルは通常ＦＤＴの形で示される。ファイルタイプをＦＤＴの形で示すさらなる利点として、個々の緊急事態間でのファイルタイプの変更が可能であるという点が挙げられる。しかし、ここでもまた、このような変更を行うには、ファイルの性質を確認できるようになる前にＦＤＴの受信と処理とを行うことが要件となる。

いずれにせよ、ＦＬＵＴＥ受信機は、ファイルの受信を行うためにどのポートでリッスンすべきかを認知する必要がある。ＵＤＰ層において緊急メッセージを直接特定することによって、プロトコルスタックにおいて可能なかぎり早く特定を行うことが可能となり、それによって、さらに効率のよい実行が可能となる。

上記の実施形態は、緊急警報がファイルとして伝送される場合のファイルのダウンロードに関連して一般的に説明されたものであることも理解されるであろう。本発明がストリーミングデータの配信に対しても同様に適用可能であることは理解できよう。緊急警報が符号化されて入れられるパケットに別のポート番号でラベルが付けられると共に、受信機はこれらのパケットを即座に復号する方法を知っていて、パケットの形で符号化された警報を提示する。

さらに、ＵＥによる緊急警報の表示又はプレゼンテーションについて言及した。警報がオーディオデータ又はビジュアルデータの形あるいはこれら両方のデータを組み合わせた形であってもよいこと、並びに、このようなデータの「表示」はオーディオとビジュアルの少なくともいずれかのデータの再生の包含を意図するものであることは理解できよう。この「表示」という用語はデータの表示のみに限定されるわけではない。

各種の実施形態を示して詳細に説明したが、請求項は、いかなる特定の実施形態または実施例にも限定されない。上記の説明はいずれも、いかなる特定の要素、ステップ、または機能が必須であって、その結果それが含まれなければならないことを示唆していると解釈されるべきではない。本発明の範囲は請求項によって定義される。

Claims (30)

1. マルチメディア放送マルチキャストサービス「ＭＢＭＳ」を動作させる、ネットワークにおいて緊急警報を配信する方法であって、前記ネットワークは、ペイロードチャネルを用いてＭＢＭＳセッションをリスンしている端末へコンテンツデータを配信するネットワークサーバを備え、
   前記サーバにおいて緊急警報を受信するステップと、
   前記緊急警報を緊急コンテンツデータとして符号化するステップと、
   他のコンテンツデータとは異なるデータとして前記緊急コンテンツデータにラベルを付けるステップと、
   前記ペイロードチャネルで前記緊急コンテンツデータを前記端末へ伝送するステップと、
   を有することを特徴とする方法。
2. 前記緊急コンテンツデータは他のコンテンツデータとインタリーブされることを特徴とする請求項１に記載の方法。
3. 前記端末は前記緊急コンテンツデータを受信して、該緊急コンテンツデータが前記緊急警報に関するものであることを特定すると共に、該緊急警報を復号し、かつ、前記他のコンテンツデータよりも高い優先順位でこの警報を即座にユーザに提示することを特徴とする請求項１又は２に記載の方法。
4. 前記緊急警報はグラフィカルな表示と音声警報の少なくともいずれかの形でユーザに提示されることを特徴とする請求項３に記載の方法。
5. 他のコンテンツデータに割り当てられたポート番号とは異なる緊急用ポート番号に関連づけられることによって、前記他のコンテンツデータとは異なるデータとして前記緊急コンテンツデータにラベルが付けられることを特徴とする請求項１乃至４のいずれか１項に記載の方法。
6. 前記緊急用ポート番号は前記サーバによって示されることを特徴とする請求項５に記載の方法。
7. 前記緊急用ポート番号は、セッション記述プロトコル「ＳＤＰ」ファイルの形で前記サーバから前記端末へ伝送されることを特徴とする請求項６に記載の方法。
8. 前記緊急用ポート番号はすべてのＭＢＭＳセッションにおいて用いるための標準ポート番号として定義されることを特徴とする請求項５に記載の方法。
9. 前記緊急用ポート番号はアドホックな手段によって前記端末において構成されることを特徴とする請求項５に記載の方法。
10. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかは、前記端末によるファイルのダウンロードの形のデータであることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
11. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかは、ストリーミングデータのデータパケットの形のデータであることを特徴とする請求項１乃至９のいずれか１項に記載の方法。
12. 他のサービスのためのＭＢＭＳペイロードをまだ受信していない任意の端末へ前記緊急コンテンツデータを伝送するためのある特定の一時的モバイルグループアイデンティティ「ＴＭＧＩ」によって識別される専用のＭＢＭＳベアラを確立するステップをさらに有することを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
13. マルチメディア放送マルチキャストサービス「ＭＢＭＳ」を動作させる、ネットワークにおいて用いるサーバであって、
    ＭＢＭＳセッションをリスンしている端末へ、ペイロードチャネルを用いてコンテンツデータを配信するように構成された送信機と、
    緊急警報を受信するように構成された受信機と、
    前記送信機及び受信機と動作可能に接続されると共に、前記緊急警報を緊急コンテンツデータとして符号化し、かつ、他のコンテンツデータとは異なるデータとして前記緊急コンテンツデータにラベルを付けるように構成されたプロセッサと、を備え、
    前記送信機は、前記ペイロードチャネルを用いて前記緊急コンテンツデータを前記端末へ伝送するようにさらに構成される
    ことを特徴とするサーバ。
14. 前記送信機は前記他のコンテンツデータとインタリーブされた前記緊急コンテンツデータを伝送するように構成されることを特徴とする請求項１３に記載のサーバ。
15. 前記プロセッサは、前記他のコンテンツデータに割り当てられたポート番号とは異なる緊急用ポート番号と前記緊急コンテンツデータを関連付けるように構成されることを特徴とする請求項１３又は１４に記載のサーバ。
16. 前記緊急用ポート番号は前記サーバによって割り当てられることを特徴とする請求項１５に記載のサーバ。
17. 前記緊急用ポート番号は、セッション記述プロトコル「ＳＤＰ」ファイルの形で前記サーバから前記端末へ伝送されることを特徴とする請求項１６に記載のサーバ。
18. 前記緊急用ポート番号は、すべてのＭＢＭＳセッションにおいて用いるための標準ポート番号として定義されることを特徴とする請求項１５に記載のサーバ。
19. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかは、前記端末によるファイルのダウンロードの形のデータであることを特徴とする請求項１３乃至１８のいずれか１項に記載のサーバ。
20. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかは、ストリーミングデータのデータパケットの形のものであることを特徴とする請求項１３乃至１８のいずれか１項に記載のサーバ。
21. マルチメディア放送マルチキャストサービス「ＭＢＭＳ」を動作させる、ネットワークにおいて用いられる端末であって、
    ペイロードチャネルでサーバからコンテンツデータを受信するように構成された受信機と、
    前記受信機と動作可能に接続されると共に、緊急コンテンツデータと他のコンテンツデータとを区別し、かつ、緊急警報を元に戻すために前記緊急コンテンツデータを復号するように構成されたプロセッサと、
    前記プロセッサと動作可能に接続されると共に、前記緊急警報をユーザに提示するように構成されたユーザインタフェースと、
    を備えることを特徴とする端末。
22. 前記プロセッサは、他のコンテンツデータよりも、緊急コンテンツデータの方により高い優先順位を割り当てるように構成されることを特徴とする請求項２１に記載の端末。
23. 前記緊急コンテンツデータは他のコンテンツデータとインタリーブされることを特徴とする請求項２１又は２２に記載の端末。
24. 前記緊急コンテンツデータが前記他のコンテンツデータに関連づけられたポート番号とは異なる緊急用ポート番号に関連づけられていることに起因して、前記プロセッサは前記緊急コンテンツデータと他のコンテンツデータとを区別することを特徴とする請求項２１、２２又は２３に記載の端末。
25. 前記緊急用ポート番号はＭＢＭＳサービスの起動時に前記端末によって受信されることを特徴とする請求項２４に記載の端末。
26. 前記緊急用ポート番号は、セッション記述プロトコル「ＳＤＰ」ファイルの形で前記サーバから受信されることを特徴とする請求項２５に記載の端末。
27. 前記緊急用ポート番号は、すべてのＭＢＭＳセッションにおいて用いるための標準ポート番号として定義されることを特徴とする請求項２４に記載の端末。
28. 前記緊急用ポート番号は、すべてのＭＢＭＳセッションにおいて用いられるアドホックな手段によって前記端末において構成されることを特徴とする請求項２４に記載の端末。
29. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかは、ストリーミングデータのデータパケットの形のデータであることを特徴とする請求項２１乃至２８のいずれか１項に記載の端末。
30. 前記緊急コンテンツデータと他のコンテンツデータの少なくともいずれかはストリーミングデータのデータパケットの形であることを特徴とする請求項２１乃至２８のいずれか１項に記載の端末。

Images