JP7316054B2 - 同報配信システム - Google Patents

Description

この発明は携帯端末等の移動端末に音声、画像あるいは文字などのユーザデータを配信するシステムに関するものであり、特にＬＴＥ（Long Term Evolution）システムなどにおいて、上記ユーザデータを複数の移動端末に対し、より簡便な仕組みにて同報配信できる同報配信システムに関する。

移動端末の普及に伴い、災害時等の緊急情報を複数の移動端末に対して同報送信できるようにし、例えば防災無線システムとして活用する要望が高まっている。また、緊急時に限らず、比較的近距離のエリア内で移動端末同士をＰＴＴ（Press To Talk）形式の半二重通信機器として扱うこと、すなわち移動端末をＰＴＴ端末（いわゆる、トランシーバシステム）の代わりに使用したい、という要望も出されている。この場合、ＰＴＴオンにて送話中の移動端末を音声ストリームの配信元とみなせば、上記のトランシーバシステムも音声ストリームの同報配信システムとみなすことができる。

例えば、防災無線システムでは、音声ストリームの配信元となる親局装置に同報送信機能を組み込み、該親局による無線制御により複数の子局装置に音声ストリームが同報送信されることとなる（特許文献１）。一方、移動端末をＰＴＴ通信用に代用する技術として、ＭＣＰＴＴ（Mission Critical Push To Talk：例えば特許文献２）が知られている。

特開２０１８－１６６２７０号公報 ＷＯ２０１７/１２６２４６号公報

特許文献１にみられる防災無線システムは、音声ストリームの配信元装置を、同報送信機能を組み込んだ専用の親局装置として構築しなければならないため、設置コストの高騰を招く問題がある。また、一般ユーザが所持する移動端末を子局装置として利用したい場合は、親局装置との間での直接的な無線通信を行なうための子局インターフェースを組み込んでおかなければならず、非対応の移動端末では音声ストリームを同報受信することができない。すなわち、この方式は、既存のネットワークのインフラを全く活用できない、という難点がある。

一方、移動端末をＰＴＴ端末として活用できるようにする特許文献２のＭＣＰＴＴシステムは、複数の移動端末の間に介在してＰＴＴ通信を成立させるためのＭＣＰＴＴサーバを設ける必要があり、プロトコルも複雑となる欠点がある。

本発明の課題は、既存の移動通信ネットワークを活用しつつ、ユーザデータを複数の移動端末に対し、より簡便な仕組みにて同報配信できる同報配信システムを提供することにある。

上記の課題を解決するために、本発明の同報配信システムは、ユーザデータの配信元ノード装置が上位ＩＰ（Internet Protocol）ネットワークを介してコアネットワークに接続され、さらに該コアネットワークに無線基地局が接続されるとともに、配信元ノード装置からのユーザデータを、上位ＩＰネットワーク及びコアネットワークを介して無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、コアネットワークに設けられ、配信元ノード装置からユーザデータを受信するとともに、ｅＭＢＭＳ（evolved Multimedia Broadcast Multicast Service）によりユーザデータを、マルチキャストグループをなす複数の移動端末に対しマルチキャスト配信するマルチキャスト配信ノード装置と、上位ＩＰネットワーク上にて配信元ノード装置とマルチキャスト配信ノード装置と間で、ＷｅｂＲＴＣ(Web Real-Time Communication)に準拠したＰ２Ｐ(peer-to-peer)接続を確立させるＷｅｂＲＴＣサーバとを備え、配信元ノード装置はＰ２Ｐ接続によりユーザデータを、マルチキャスト配信ノード装置のＩＰアドレスを送信先ＩＰアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、マルチキャスト配信ノード装置はユニキャストパケットを、送信先ＩＰアドレスとしてマルチキャストグループのＩＰアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の移動端末に対しマルチキャスト配信することを特徴とする。

本発明の同報配信システムにおいては、ユーザデータの配信元ノード装置が、上位ＩＰ（Internet Protocol）ネットワークを介してコアネットワークに接続される。該配信元ノード装置は上位ＩＰネットワーク上のＷｅｂＲＴＣサーバが確立するＰ２Ｐ接続により、ユーザデータのＩＰパケットを、コアネットワーク上のマルチキャスト配信ノード装置を送信先とするユニキャストパケットとして送出する。マルチキャスト配信ノード装置はユニキャストのＩＰパケットをマルチキャストのＩＰパケットに変換し、マルチキャストグループをなす複数の移動端末に対しマルチキャスト配信する。ＷｅｂＲＴＣはトランスポート層のプロトコルとして、接続確認のためのステートが排除され、かつ送受信されるデータの誤りや順序の違いなどを検出する機能有さない簡便なＵＤＰ（User Datagram Protocol）が採用される。その結果として実現されるＰ２Ｐ接続によるデータ通信は、信頼性にはやや劣るが応答性やリアルタイム性は極めて良好となる。すなわち、本発明の同報配信システムにおいては、配信元ノード装置からマルチキャスト配信ノード装置へユーザデータを、ＷｅｂＲＴＣ特有のＵＤＰ上のＰ２Ｐ通信によりスムーズに送出できる。また、該送信はユニキャストパケットによりなされるので、配信元ノード装置に同報送信のための機能（インターフェース）を搭載する必要がなく、装置の大幅な簡略化を図ることができる。そしてユーザデータは、マルチキャスト配信ノード装置から先は無線リソースを効率的に活用するｅＭＢＭＳによりマルチキャストパケットの形で各移動端末に配信されるので、無線リソースの消費を最小限に抑えることができ、かつデータ配信の同時同報性も極めて良好に担保することができる。

本発明の一実施形態である同報配信システムの電気的構成を示すブロック図。 ＵＥ（移動端末）の電気的構成の一例を示すブロック図。 ＩＰパケットの概念図。 ３ＧＰＰのコントロールプレーンのプロトコルスタックを概念的に示す図。 ３ＧＰＰのユーザプレーンのプロトコルスタックを概念的に示す図。 ３ＧＰＰの下りリンクのチャネルマッピングを概念的に示す図。 同じく上りリンクのチャネルマッピングを概念的に示す図。 リソースブロックの概念図。 ユニキャストのＩＰパケットとマルチキャストのＩＰパケットとの間の変換の概念を説明する図。 ＵＥのコアネットワークへのアタッチと、Ｐ－ＧＷ／ＢＭＳＣ間のＷｅｂＲＴＣによるＰ２Ｐ接続にかかるシーケンスを示す通信フロー図。 ＵＥからユーザデータをＢＭＳＣにストリーミング送信するシーケンスを示す通信フロー図。 ＢＭＳＣからデータ配信先のＵＥにマルチキャストベアラを構築する際のセッションシーケンスを示す通信フロー図。 インターネット上の防災無線サーバとＢＭＳＣ間のＷｅｂＲＴＣによるＰ２Ｐ接続、及び防災無線サーバからユーザデータをＢＭＳＣにストリーミング送信するシーケンスを示す通信フロー図。 ＵＥのメニュー画面の一例を示す図。 ＵＥのトランシーバ通信チャネルの設定画面の一例を示す図。 ＵＥのトランシーバ通信中の画面の一例を示す図。 ＵＥの防災無線用の画面の一例を示す図。 ＵＥの映像受信画面の一例を示す図。

以下、本発明を実施するための形態を添付の図面に基づいて説明する。
（実施形態１）
図１は、本発明の一実施形態である同報配信システムの全体構成を示すブロック図である。同報配信システム１においては、上位ＩＰネットワークをなすインターネット１５に３ＧＰＰ仕様のコアネットワーク３が接続されている。コアネットワーク３には無線基地局をなすｅＮｏｄｅＢ４が接続されるとともに、ｅＮｏｄｅＢ４には複数のＵＥ５（User Equipment：移動端末）が無線接続される。また、ユーザデータの配信元ノード装置として、図１においては、後述のＰ－ＧＷ７と防災無線サーバ１８がインターネット１５（上位ＩＰネットワーク）に接続されている。つまり、これらの配信元ノード装置はインターネット１５を介してコアネットワーク３に接続されている。そして、配信元ノード装置（Ｐ－ＧＷ７と防災無線サーバー１８）からのユーザデータは、インターネット１５及びコアネットワークを介してＰ－ＧＷ７と防災無線サーバ１８に無線接続される複数のＵＥ５に同報配信される。

次に、コアネットワーク３のユニキャスト側ブロックＵＢは、コアネットワーク３のコントロールプレーン側のゲートウェイとなるＭＭＥ（Mobility Management Entity）２、ユーザプレーン側のゲートウェイとなるＳ－ＧＷ（Serving Gateway）６、外部ネットワーク（本実施形態では上位ＩＰネットワークであるインターネット１５）とコアネットワーク３との結節点に位置し、外部ネットワーク側（インターネット１５側）に向けたＩＰアドレス管理を行なうＰ－ＧＷ（PDN (Packet Data Network) Gateway）７とを有する。ユニキャスト側ブロックのコントロールプレーン側においてｅＮｏｄｅＢ４は、Ｓ１－ＭＭＥインターフェースを介してＭＭＥ２に接続される。また、ユーザプレーン側においてｅＮｏｄｅＢ４は、Ｓ１－Ｕインターフェースを介してＳ－ＧＷ６に接続される。また、Ｓ－ＧＷ６はＳ５インターフェースを介してＰ－ＧＷ７と接続される。

一方、コアネットワーク３のマルチキャスト側ブロックＭＢは、上位ＩＰネットワーク（インターネット１５）からのユーザデータの受信ノードとなるＢＭＳＣ（Broadcast Multicast Service Center）８、ＭＢＭＳにおけるコアネットワーク３のユーザプレーン側のゲートウェイとなるＭＢＭＳ－ＧＷ（Multimedia Broadcast Multicast Service Gateway）９、ユニキャスト側ブロックＵＢと共用されるＭＭＥ２、及びユーザプレーン側を送信されるマルチキャストデータのＵＥ（移動端末）５への送信制御を司るＭＣＥ（Multi-cell multicast Coordination Entity）１０を有する。ＭＢＭＳ－ＧＷ９はＭ１インターフェースを介してｅＮｏｄｅＢ４と接続され、ＳＭインターフェースを介してＭＭＥ２と接続され、さらにＳＧ－ｍｂ及びＳＧｉ－ｍｂインターフェースを介してＢＭＳＣ８と接続される。マルチキャスト側ブロックＭＢにおいてｅＮｏｄｅＢ４は、Ｍ２インターフェースを介して該ＭＣＥ１０に接続される。ＭＣＥ１０はＭ３インターフェースを介してＭＭＥ２に接続される。

ＢＭＳＣ８は、マルチキャストのユーザデータを収集し、配信先となるグループメンバーシップやＱｏＳ（Quality of Service）の管理、マルチキャスト/ブロードキャストセッションのアナウンス、セキュリティなどマルチキャスト配信全般のサービス管理を行なう。ＭＢＭＳ－ＧＷ９はユーザプレーン(U-Plane）側のゲートウェイであり、ｅＮｏｄｅＢ４に対するマルチキャストデータ伝送やセッション制御を行なう。他方、ＭＭＥ２は、コントロールプレーン（C-Plane）側のゲートウェイであり、基地局であるｅＮｏｄｅＢ４との間で通信に必要な制御信号を仲介する交換局としての機能を果たす。具体的には、ＮＡＳ（Non Access Stratum）と呼ばれるＵＥ認証制御や、ルーティング（接続経路設定）の要求、さらにはハンドオーバーの際にＵＥ５ごとのデータ送受信管理情報を異なるｅＮｏｄｅＢ４間で交換させるための仲介を行なう。ＭＣＥ１０はマルチキャスト制御装置に相当し、ＭＢＳＦＮの無線リソース管理及び割当等の機能を担うとともに、ＭＢＳＦＮを構成するｅＮｏｄｅＢ間にてデータ送信に使用する無線リソースを指定することにより、ｅＮｏｄｅＢ４が受け持つ複数のＵＥ５への、マルチキャストベアラ１１を使用したコンテンツ配信を同期させる役割を果たす。ｅＭＢＭＳ側ブロックにおいてｅＮｏｄｅＢ４は、Ｍ２インターフェースを介して該ＭＣＥ１０に接続される。ＭＣＥ１０はＭ３インターフェースを介してＭＭＥ２に接続される。

Ｍ１インターフェースは、ユーザプレーンのインターフェースであり、マルチキャストにおけるユーザデータの伝送路として機能する。一方、Ｍ２インターフェースとＭ３インターフェースはコントロールプレーンのインターフェースであり、マルチキャストにおける制御データの伝送路として機能する。また、ＳＧｍｂ/ＳＧｉｍｂインターフェースは、コアネットワーク３におけるＢＭＳＣ８とＭＢＭＳ－ＧＷ９間のコントロールプレーン及びユーザプレーンの共用インターフェースである。また、ＳＭインターフェースは、ＭＢＭＳ－ＧＷ９がＭＭＥ２（コントロールプレーン）側の制御状態に対する参照ポイントを形成するためのものである。

コアネットワーク３のマルチキャスト側ブロックＭＢの構成は、複数のＵＥ５に向け、音声、画像（静止画及び動画）、文字列ないしそれらの組み合わせからなるコンテンツデータ（ユーザデータ）が同時にストリーミング配信される、といった状況を想定して構築されている。すなわち、マルチキャスト配信されるコンテンツデータは、その収集と配信管理のためにＢＭＳＣ８を一旦経由する形でコアネットワーク３に送信される。また、コンテンツを構成するマルチキャストデータは、ユーザプレーン側のゲートウェイ装置であるＭＢＭＳ－ＧＷ９にて受信する。一方、制御データについてはコントロールプレーン側のゲートウェイ装置であるＭＭＥ２が、ＳＭインターフェースを介してＭＢＭＳ－ＧＷ９を参照する形で生成する。該制御データは、ユーザプレーンとは別の伝送経路（Ｍ３／Ｍ２インターフェース）を介して、ユーザデータから分離されつつｅＮｏｄｅＢ４に流れるようになっている。

コアネットワーク３に設けられたＢＭＳＣ８は、Ｐ－ＧＷ７又は防災無線サーバ１８（配信元ノード装置）からユーザデータを受信するとともに、マルチキャストグループをなす複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）に対し該ユーザデータをｅＭＢＭＳによりマルチキャスト配信するマルチキャスト配信ノード装置として機能する。一方、インターネット１５（上位ＩＰネットワーク）上には、配信元ノード装置（Ｐ－ＧＷ７又は防災無線サーバー１８）とＢＭＳＣ８と間でＷｅｂＲＴＣ(Web Real-Time Communication)に準拠したＰ２Ｐ(peer-to-peer)接続を確立させるＷｅｂＲＴＣサーバ１７が設けられている。

ＷｅｂＲＴＣは、クライアントがサーバにデータを要求する一般のクライアント／サーバモデルとは異なり、クライアントとなる複数の端末及びノード装置間の通信において各クライアントがデータを保持し、他のクライアントに対して直接的にデータの送信・要求を行う（Ｐ２Ｐ）。また、通信プロトコルには基本的にＴＣＰ/ＩＰ（Transmission Control Protocol / Internet Protocol）の代わりにＵＤＰ/ＩＰ（User Datagram Protocol / Internet Protocol）を用いる。

具体的には、ＴＣＰの場合、ユーザデータ本体のパケット通信以外に、開始処理と終了処理が実施されるが、ＵＤＰは開始処理及び終了処理は実施されない。また、ＴＣＰではパケットの受信に対しＡＣＫ（acknowledgement）を応答として返すが、ＵＤＰではＡＣＫを返さない。そのため、ＵＤＰのデータ送受信の信頼性はＴＣＰには及ばないが、送受信の手順が簡略化されている分、通信のリアルタイム性（同時性）が大幅に向上する。送受信の対象が音声や映像の場合、ストリーミングに多少の途切れが生じても直ちに大きな問題につながらないことから、ＵＤＰの採用により同報送信に重要な同時性が担保されることは有利であるといえる。

後述のトランシーバモードにおいては、Ｐ－ＧＷ７及びＢＭＳＣ８をクライアント・ノードとして、ＵＥ５からの上りリンクの音声データパケットをＢＭＳＣ８へ送信する処理がＷｅｂＲＴＣによるＰ２Ｐ通信により実施される。また、防災無線モードでは防災無線サーバ１８及びＢＭＳＣ８クライアント・ノードとして、防災無線サーバ１８からの防災無線データをＢＭＳＣ８へ送信する処理がＷｅｂＲＴＣによるＰ２Ｐ通信により実施される。いずれの場合もＷｅｂＲＴＣサーバ１７の仲介により、クライアント・ノード間では以下の情報が共有される。

・ＳＤＰ（Session Description Protocol）
ＵＤＰ通信に必要な各ノードの情報を示す文字列であり、セッションの属性、メディアの形式、ＩＰアドレス、ポート番号、通信帯域などを含むＷｅｂＲＴＣのＰ２Ｐ通信は双方向であるが、本実施形態では、上りリンクにおけるユーザデータパケットの送信方向はＰ－ＧＷ７からＢＭＳＣ８に向かう一方向のみであり、下りリンクはＷｅｂＲＴＣではなくｅＭＢＭＳが担う。よって、ここでは、Ｐ－ＧＷ７がＢＭＳＣ８に対しＳＤＰをOfferし、それに対してＢＭＳＣ８がAnswer SDPを返すというOffer/Answerモデルで通信が行われる。
・ＩＣＥ（Interactive Connectivity Establishment）
相手ノードに到達する可能性のある通信経路に関する情報を示すものであり、それらの経路候補をICE Candidateとしてノード間で共有している必要がある。

図２は、ＵＥ５の電気的構成の一例を示すブロック図である。ＵＥ５はマイコン１００を処理主体として備えている。該マイコン１００は、ＣＰＵ１０１、プログラム実行領域となるＲＡＭ１０２、ＲＯＭ１０３、入出力部１０４及びそれらを相互に接続するバス１０６等からなる。また、バス１０６にはフラッシュメモリ１０５が接続され、ここにＵＥ５の動作環境を構築するためのＯＳ（図示せず）と、ユーザ端末アプリ１０５ａがインストールされている。ユーザ端末アプリ１０５ａは、ＵＥ５をＰＴＴ端末（トランシーバ端末として機能させるためのＰＴＴプログラムモジュール１０５ｂと、防災無線の受信端末として機能させるための防災無線プログラムモジュール１０５ｃとを含む。また、入出力部１０４には音声入力部（あるいは送話器）としてのマイク１０７がＡ／Ｄ変換部１０７１を介して接続されている。また、音声出力部（あるいは受話器）としてのスピーカ１０８がＡ／Ｄ変換部１０８１及びアンプ１０８２を介して接続されている。

また、入出力部１０４にはグラフィックコントローラ１０９１を介してモニタ１０９が接続されている。モニタ１０９には入力部をなすタッチパネル１１０が重ね合わされ、モニタ１０９に表示形成される種々のソフト操作部（ボタンやアイコンなど：図１３～図１７参照）と協働して、ＵＥ５の動作制御に必要な種々の情報入力がなされるようになっている。タッチパネル１１０はタッチパネルコントローラ１１０１を介して入出力部１０４に接続されている。入出力部１０４には静止画ないし動画を撮影するためのカメラ１１１が接続されている。さらに、バス１０６には無線通信部１１２が接続され、該無線通信部１１２を介してｅＮｏｄｅＢ４（図１）と無線接続される。

図１に戻り、Ｐ－ＧＷ７は、複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）のうちユーザデータの送出起点となるＵＥ(I)（起点移動端末）から該コアネットワーク３の上りリンクチャネルを経由してユーザデータを受信・収集し、これをＰ２Ｐ接続によりＢＭＳＣ８（マルチキャスト配信ノード装置）に送出する役割を果たす。Ｐ－ＧＷ７をこのような形態の配信元ノード装置として機能させることで、ユーザが携帯するＵＥ５から所望のユーザデータを他のＵＥ５に対し随時同報配信できる利点が生ずる。

具体的には、マルチキャストグループをなす複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）の一つのもの（図１ではＵＥ(I)）を起点移動端末として定めることができる。ユーザデータは該起点移動端末（ＵＥ(I)）から送出される音声（例えば、通話音声）、文字列（例えば、電子メールやＳＮＳメッセージなど）及び画像（静止画又は動画）の少なくともいずれかの情報を含むものとすることができる。該ユーザデータがマルチキャストグループをなす複数のＵＥ５（移動端末）の残余をなす配信先移動端末（図１では、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）に配信されることとなる。これにより、グループ内のＵＥ５同士の間にてユーザデータを同報形態で送受信でき、簡便な装置構成によりリアルタイム性の高い情報交換を一対多の関係で容易に行うことができる。

マルチキャストグループをなす複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）の各々には、図２に示す如く、マイク１０７（音声入力部）が設けられる。起点端末装置となるＵＥ(I)のマイク１０７から音声が入力されるに伴い、配信先移動端末（ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）に該音声のストリーミングデータがユーザデータとして逐次配信される。これにより、起点端末装置となるＵＥ(I)にて入力される音声ストリームを、マルチキャストグループ内の配信先移動端末（ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）にて同時に供給することができる。

本実施形態において図１に示す同報配信システム１は、配信元ノード装置がＰ－ＧＷ７となる場合はＵＥ５がトランシーバ端末として使用され、マルチキャストグループをなす複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）間で半二重通信による交信が可能となるトランシーバモードとしての使用形態となる。一方、配信元ノード装置が防災無線サーバ１８となる場合は、複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）はいずれも、防災無線サーバ１８から音声、文字列及び画像の少なくともいずれかよりなる防災無線データをユーザデータとして受信する同報受信端末として使用され、防災無線モードでの使用形態となる。ＵＥ５をどのモードで使用するかは、ユーザ端末アプリ１０５ａの実行により、ＵＥ５のモニタ１０９に図１３のメニュー選択画面１０９ａを表示し、該画面１０９ａ上にて、モード選択ボタン１０９ａ１、１０９ａ２をタッチすることにより選択可能である。また、トランシーバモードでは、図１４に示すように、ＰＴＴ交信のチャネル設定画面１０９ｂを表示し、チャネル選択ボタン１０９ｂ１の操作により、ＰＴＴ交信のチャネル設定を行なうように構成することができる。異なるチャネル選択ボタン１０９ｂ１には互いに異なるマルチキャストグループのＩＰアドレスが割り当てられており、所望のチャネル選択ボタン１０９ｂ１を選択すると、対応するマルチキャストグループに参加するＵＥ同士のみでＰＴＴ交信が可能となる。つまり、マルチキャストグループのＩＰアドレス設定により、一般的なトランシーバの交信チャネル設定と同様の概念を実現することができる。

例えば、複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）は、上記メニュー選択画面１０９ａにてトランシーバモード選択ボタン１０９ａ１がタッチされると、図１５左のトランシーバモードのスタンバイ画面１０９ｃｓに遷移し、ＵＥ５はトランシーバモードにて機能するようになる。スタンバイ画面１０９ｃｓ上にはＰＴＴ（Press To Talk）操作部１０９ｃ１が各々設けられている。モニタ１０９に表示されるスタンバイ画面１０９ｃｓ上にて該ＰＴＴ操作部１０９ｃ１は、タッチパネル１１０の対応する領域とともにソフトボタンとして形成されている。

図１５左のスタンバイ画面１０９ｃｓにてＰＴＴ操作部１０９ｃ１がタッチ操作されると、図１５右の送信中画面１０９ｃｔに切り替わり、マイク１０７（音声入力部：図１）から入力される音声のストリーミングデータが配信先移動端末（ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）に配信される。一方、該操作が解除された状態では図１５左のスタンバイ画面１０９ｃｓに戻り、配信先移動端末（ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）のいずれかが送出起点端末装置となって配信される音声のストリーミングデータの受信スタンバイ状態となる。このとき、同じマルチキャストグループの他のＵＥ５から音声ストリームを受信すると、図１５真ん中の受信画面１０９ｃｒとなり、図２のスピーカ１０８から受信した音声が出力される。これにより、マルチキャストグループをなす複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）は、半二重通信による音声交信、すなわちトランシーバとしての交信が可能となる。なお、音声受信中となる受信画面１０９ｃｒにおいては、ＰＴＴ操作部１０９ｃ１は表示されないか、あるいは無効化され、音声送信が不能な状態となる。また、スタンバイ画面１０９ｃs又は受信画面１０９ｃｒ上に形成されたオフボタン１０９ｃ２をタッチするとトランシーバモードは解除され、図１３のメニュー画面に戻る。

なお、トランシーバモードにおいてユーザデータは、音声ストリームデータのほか、図２のカメラ１１１が撮影する動画ストリームや静止画の画像データとして同報配信することも可能である。該画像データに基づく画像は、図１７に示すように、受信画面１０９ｃ上にて画像表示領域１０９ｃｍに表示することができる。

一方、図１３のメニュー選択画面１０９ａにて防災無線モード選択ボタン１０９ａ２がタッチされると、図１６の防災無線画面１０９ｅに遷移し、ＵＥ５は防災無線モードにて機能するようになる。インターネト１５（上位ＩＰネットワーク）上に設けられた防災無線サーバ１８は、音声（あるいは画像）よりなる防災無線データをユーザデータとしてＰ２Ｐ接続によりＢＭＳＣ８（マルチキャスト配信ノード装置）に送出する。ＢＭＳＣ８は該防災無線データを複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）に同報配信する。防災無線データに含まれる音声データは、図２のスピーカ１０８から音声出力される。また、画像（動画又は静止画）データが含まれる場合は、図１６の防災無線画面１０９ｅ上にて画像出力させることができる。なお、防災無線画面１０９ｅ上に形成されたオフボタン１０９ｄ１をタッチすると防災無線モードは解除され、図１３のメニュー画面に戻る。

図１に戻り、図中、実線の矢印はユニキャストデータフローを、白抜きの矢印はマルチキャストデータフローをそれぞれ示す。また、一点鎖線の矢印は制御データフローを示し、破線の矢印はＷｅｂＲＴＣによるＰＳＰ通信となっている区間を示す。トランシーバモードにおいては、図１において、複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)：移動端末）のうちＰＴＴ操作部１０９ｃ１（図１５）が操作されることで起点移動端末となるＵＥ(I)から、音声ストリームデータ（ユーザデータ）が該コアネットワーク３の上りリンクチャネルを経由してＰ－ＧＷ７に送信される。このとき、ＵＥ(I)とｅＮｏｄｅＢ４との間の無線ベアラはユニキャストベアラ１２が使用され、Ｓ－ＧＷ６を経てＰ－ＧＷ７までの間はＳ１－Ｕ及びＳ５の各インターフェースを介した物理回線ベアラが使用される。そして、Ｐ－ＧＷ７とＢＭＳＣ８との間はインターネット１５上でのＷｅｂＲＴＣによるＰ２Ｐ接続となり、ＵＥ(I)からＢＭＳＣ８までの間を音声データ（ユーザデータ）はユニキャストのＩＰパケットによりストリーミングされる。

これに対し、防災無線モードでは配信元ノード装置となる防災無線サーバ１８自体がユーザデータ送信の起点となるため、コアネットワーク３内の上りリンク伝送路は使用されない。また、防災無線サーバ１８とＢＭＳＣ８との間はインターネット１５上でのＷｅｂＲＴＣによるＰ２Ｐ接続となり、防災無線サーバ１８からＢＭＳＣ８までの間を防災無線データがユニキャストのＩＰパケットによりストリーミングされる。

このように、Ｐ－ＧＷ７又は防災無線サーバ１８（配信元ノード装置）はＰ２Ｐ接続によりユーザデータを、ＢＭＳＣ８のＩＰアドレスを送信先ＩＰアドレスとして指定するユニキャストパケットとしＢＭＳＣ８に送信する。一方、ＢＭＳＣ８はそのユニキャストパケットを、送信先ＩＰアドレスとしてマルチキャストグループのＩＰアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数のＵＥ５（ＵＥ(I)、ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）に対しマルチキャスト配信する。コアネットワーク３のマルチキャスト側ブロックＭＢの構成は、ｅＭＢＭＳ仕様の標準的な構成であり、ｅＮｏｄｅＢ４とＵＥ５との間にマルチキャスト配信専用の無線ベアラであるマルチキャストベアラ１１を構築する前提で、ＢＭＳＣ８、ＭＢＭＳ－ＧＷ９、ＭＭＥ２、ＭＣＥ１０及びｅＮｏｄｅＢ４間の通信セッションの構築がなされる。

図３は、データ伝送に使用するＩＰパケットの構造示す模式図である。ＩＰパケット３００はＩＰヘッダ３０１とペイロード３０２とからなり、ＩＰヘッダ３０１にはＰＤＵ識別番号、データの送信元アドレス３０１ａ、送信先アドレス３０１ｂなどが書き込まれる。また、ペイロード３０２には、ユーザデータの場合は配信コンテンツの主体となるデータが、制御データの場合は種々の制御コマンドなどが書き込まれる。

図４及び図５は、ＬＴＥシステムにおける無線インターフェースのプロトコルスタックを示し、図５はユーザプレーンのプロトコルスタックを、図４はコントロールプレーンのプロトコルスタックを示している。無線インターフェースプロトコルは、ＯＳＩ参照モデルのレイヤ１～レイヤ３に区分されており、レイヤ１はＰＨＹ（物理）層である。レイヤ２は、ＭＡＣ（Medium Access Control：メディアアクセス制御）層、ＲＬＣ（Radio Link Control：無線リンク制御）層、及びＰＤＣＰ（Packet Data Convergence Protocol：パケットデータ暗号化）層を含む。レイヤ３は、ＲＲＣ（Radio Resource Control：無線リソース制御）層及びＮＡＳ（Non-Access Stratum：非アクセス）層を含む。

各層の役割は以下の通りである。
・ＰＨＹ層：符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行なう。ＵＥ５のＰＨＹ層とｅＮｏｄｅＢ４のＰＨＹ層との間では、物理チャネルを介してデータ及び制御信号が伝送される。
・ＭＡＣ層：データの優先制御、ＨＡＲＱによる再送制御処理、及びランダムアクセス手順等を行なう。ＵＥ５のＭＡＣ層とｅＮｏｄｅＢ４のＭＡＣ層との間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮｏｄｅＢ４のＭＡＣ層は、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））及びＵＥ５への割当リソースブロックを決定するスケジューラを含む。

・ＲＬＣ層：ＭＡＣ層及びＰＨＹ層の機能を利用してデータを受信側のＲＬＣ層に伝送する。ＵＥ５のＲＬＣ層とｅＮｏｄｅＢ４のＲＬＣ層との間では、論理チャネルを介してデータ及び制御信号が伝送される。
・ＰＤＣＰ層：ＰＤＵのヘッダ圧縮・伸張、及び暗号化・復号化を行なう。
・ＲＲＣ層：制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ５のＲＲＣ層とｅＮｏｄｅＢ４のＲＲＣ層との間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣ層は、無線ベアラ（マルチキャストベアラ及びユニキャストベアラ）の確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル及び物理チャネルを制御する。ＵＥ５のＲＲＣとｅＮｏｄｅＢ４のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ５はＲＲＣコネクティッドモードとなり、そうでない場合はＲＲＣアイドルモードとなる。

以上の層はコントロールプレーン及びユーザプレーンの双方にて使用される。一方、コントロールプレーンのみ、ＵＥ５及びＭＭＥ３には、ＲＲＣ層よりさらに上位にセッション管理及びモビリティ管理等を行なうＮＡＳ層が設けられる。また、ｅＮｏｄｅＢ４のコアネットワーク側とのユーザデータ伝送インターフェースには、ＧＴＰ－Ｕ（GPRS（General Packet Radio Service）Tunneling Protocol for User Plane）層が設けられている。ＧＴＰ－Ｕ層は、接続先のＵＥ５（移動端末）及び使用する無線ベアラの識別を行なうためのものである。

次に、図６Ａは、ＬＴＥシステムにおける下りリンクのチャネルマッピングを示す。ここでは、論理チャネル（Downlink Logical Channel）、トランスポートチャネル（Downlink Transport Channel）及び物理チャネル（Downlink Physical Channel）相互間のマッピング関係を示している。以下、順に説明する。
・ＤＴＣＨ（Dedicated Traffic Channel：専用トラフィックチャネル）は、データの送信のための個別論理チャネルである。ＤＴＣＨは、トランスポートチャネルであるＤＬＳＣＨ（Downlink Shared Channel：下りシェアドチャネル）にマッピングされる。
・ＤＣＣＨ（Dedicated Control Channel：専用制御チャネル）：ＵＥ５とネットワークとの間の個別制御情報を送信するための論理チャネルである。ＤＣＣＨは、ＵＥ５がＲＲＣ接続を有する場合に用いられる。ＤＣＣＨは、ＤＬＳＣＨにマッピングされる。
・ＣＣＣＨ（Common Control Channel：共通制御チャネル）：ＵＥ５とｅＮｏｄｅＢ４との間の送信制御情報のための論理チャネルである。ＣＣＣＨは、ＵＥ５がｅＮｏｄｅＢ４（ネットワーク）との間でＲＲＣ接続を有していない場合に用いられる。ＣＣＣＨは、ＤＬＳＣＨにマッピングされる。

・ＢＣＣＨ（Broadcast Control Channel：放送制御チャネル）：システム情報配信のための論理チャネルである。ＢＣＣＨは、トランスポートチャネルであるＢＣＨ（Broadcast Channel、放送チャネル）又はＤＬＳＣＨにマッピングされる。
・ＰＣＣＨ（Paging Control Channel：ページング制御チャネル）：ページング情報、及びシステム情報変更を通知するための論理チャネルである。ＰＣＣＨは、トランスポートチャネルであるＰＣＨ（Paging Channel：ページングチャネル）にマッピングされる。
・ＭＣＣＨ（Multicast Control Channel：マルチキャスト制御チャネル）：マルチキャスト伝送のための論理チャネルである。ＭＣＣＨは、通常のＭＢＭＳにおいてｅＮｏｄｅＢ４からＵＥ５へＭＢＭＳ制御データを送信するために用いられるものである。
・ＭＴＣＨ（Multicast Traffic Channel：マルチキャストトラフィックチャネル）：ｅＮｏｄｅＢ４からＵＥ５へのマルチキャストデータ（コンテンツ）を伝送するための論理チャネルである。ＭＴＣＨは、通常のＭＢＭＳ仕様ではマルチキャスト用のトランスポートチャネルであるＭＣＨ（Multicast Channel：マルチキャストチャネル）にマッピングされる。

また、トランスポートチャネルと物理チャネルとの間のマッピング関係は以下の通りである。
・ＤＬＳＣＨ及びＰＣＨ：ＰＤＳＣＨ（Physical Downlink Shared Channel：物理下りシェアドチャネル）にマッピングされる。ＤＬＳＣＨは、ＨＡＲＱ、リンクアダプテーション、及び動的リソース割当（ユニキャスト特有の部分でもある）をサポートする。
・ＢＣＨ：ＰＢＣＨ（Physical Broadcast Channel：物理ブロードキャストチャネル）にマッピングされる。
・ＭＣＨ：ＰＭＣＨ（Physical Multicast Channel：物理マルチキャストチャネル）にマッピングされる。ＭＣＨは、複数のセルによるＭＢＳＦＮ伝送をサポートする。

次に、図６Ｂは、ＬＴＥシステムにおける上りリンクのチャネルマッピングを示す。図６Ａと同様に、論理チャネル（Downlink Logical Channel）、トランスポートチャネル（Downlink Transport Channel）及び物理チャネル（Downlink Physical Channel）相互間のマッピング関係を示している。以下、順に説明する。

・ＣＣＣＨ（Common Control Channel：共通制御チャネル）：ＵＥとネットワーク間の制御情報を送信するために使用される論理チャネルであり、ネットワークと無線リソース制御（ＲＲＣ：Radio Resource Control）接続を有していないＵＥによって使用される。
・ＤＣＣＨ（Dedicated Control Channel：専用制御チャネル）：１対１（point-to-point）の双方向の論理チャネルであり、ＵＥとネットワーク間で個別の制御情報を送信するために利用するチャネルである。専用制御チャネルＤＣＣＨは、ＲＲＣ接続を有している移動局装置によって使用される。
・ＤＴＣＨ（Dedicated Traffic Channel：専用トラフィックチャネル）：１対１の双方向論理チャネルであり、１つのＵＥ置専用のチャネルであって、ユーザ情報（ユニキャストデータ）の転送のために利用される。

・ＵＬＳＣＨ（Uplink Shared Channel：上りリンク共用チャネル）：ＨＡＲＱ）、動的適応無線リンク制御、間欠送信（ＤＴＸ：Discontinuous Transmission）がサポートされるトランスポートチャネルである。
・ＲＡＣＨで（Random Access Channel：ランダムアクセスチャネル）：制限された制御情報が送信されるトランスポートチャネルである。

・ＰＵＣＣＨ（Physical Uplink Control Channel：物理上りリンク制御チャネル）：下りリンクデータに対する応答情報（ＡＣＫ(Acknowledge)/ＮＡＣＫ(Negative acknowledge)）、下りリンクの無線品質情報、および、上りリンクデータの送信要求（スケジューリングリクエスト：Scheduling Request：ＳＲ）を基地局装置に通知するために使用される物理チャネルである。
・ＰＵＳＣＨ（Physical Uplink Shared Channel：物理上りリンク共用チャネル）：上りリンクデータを送信するために使用される物理チャネルである。
・ＰＲＡＣＨ（Physical Random Access Channel：物理ランダムアクセスチャネル）：主に移動局装置から基地局装置への送信タイミング情報（送信タイミングコマンド）を取得するためのランダムアクセスプリアンブル送信に使用される物理チャネルである。ランダムアクセスプリアンブル送信はランダムアクセス手順の中で行なわれる。

次に、チャネルマッピングについて説明する。図６Ｂに示されるように、上りリンクでは、次のようにトランスポートチャネルと物理チャネルのマッピングが行われる。上りリンク共用チャネルＵＬＳＣＨは、物理上りリンク共用チャネルＰＵＳＣＨにマッピングされる。ランダムアクセスチャネルＲＡＣＨは、物理ランダムアクセスチャネルＰＲＡＣＨにマッピングされる。物理上りリンク制御チャネルＰＵＣＣＨは、物理チャネル単独で使用される。また、共通制御チャネルＣＣＣＨ、専用制御チャネルＤＣＣＨ、専用トラフィックチャネルＤＴＣＨは、上りリンク共用チャネルＵＬＳＣＨにマッピングされる。

次に、ＬＴＥシステムにおいては、ＵＥ５はｅＮｏｄｅＢ４に対してＯＦＤＭ（Orthogonal Frequency-Division Multiplexing、直交周波数分割多重）アクセス（ＯＦＤＭＡ）により無線接続する。ＯＦＤＭＡ方式は、周波数分割多重と時間分割多重とを複合させた二次元の多重化アクセス方式として特徴づけられる。具体的には、直交する周波数軸と時間軸のチャネル（サブキャリア）を分割してＵＥ５に割り振り、各サブキャリアの信号がゼロ（0点）になるように周波数軸上で直交するサブキャリアを分割する。サブキャリアを分割して周波数軸上に割り当てることにより、あるサブキャリアがフェージングの影響を受けても影響のない別のサブキャリアを選択することがでるので、ユーザは無線環境に応じてより良好なサブキャリアを使用でき、無線品質を維持できる利点が生ずる。

そして、ＯＦＤＭＡ方式においては、周波数軸と時間軸とが張る仮想平面上で定義されるリソースブロック(Resource Block：以下、ＲＢともいう）が無線リソースとして採用される。ＲＢは図７に示すように、上記平面を１８０ｋＨｚ／０．５ｍｓｅｃでマトリックスに区切ったブロックとして定義され、各ブロックは周波数軸上では１５ｋＨｚ間隔で隣接する１２個のサブキャリアを、時間軸上ではフレームの１スロット分（７シンボル）を含む。このＲＢは時間軸上で隣接する２つ（１ｍｓｅｃ）を１組としてＵＥ５に割り当てられる。

以下、図１の同報配信システム１の通信処理の流れについて図９～図１２の通信フロー図により説明する。まず、図９において、ＵＥ５とコアネットワーク３（図１）との間のアタッチシーケンスが実行される。ＴＳ１ではＵＥ５からｅＮｏｄｅＢ４を経由してＭＭＥ２に対し、アタッチ要求が出される。ＭＭＥ２はこれを受け、ＴＳ２にてＳ－ＧＷ６に対しベアラ設定要求を送信する。Ｓ－ＧＷ６はＴＳ３にて、Ｐ－ＧＷ７との間にＳ５インターフェース上に物理回線のベアラ設定処理を実行する。ベアラが設定されればＳ－ＧＷ６はＴＳ４にてＭＭＥ２に、ベアラ設定応答を送信する。ＭＭＥ２はＴＳ５にて、無線ベアラ設定要求（すなわち、アタッチ受入れ）をｅＮｏｄｅＢ４に通知する。これを受けたｅＮｏｄｅＢ４はＴＳ６にて無線ベアラ設定要求（すなわち、アタッチ受入れ）をＵＥ５に通知する。ＵＥ５は無線ベアラ（ユニキャストベアラ１２（図１））を設定し、ＴＳ７にて無線ベアラ設定応答をｅＮｏｄｅＢ４に返す。ｅＮｏｄｅＢ４は、ＴＳ８にて無線ベアラ設定応答をＭＭＥ２に通知する。以上の処理は、トランシーバモード及び防災無線モードのいずれにおいても共通に実施される。

以下、トランシーバモードが選択されている場合の通信フローについて説明する（起点移動端末がＵＥ(I)となる場合を例にとる）。まず、図９のＴＳ１０において、ＵＥ５からＰ－ＧＷ７に対し、ＢＭＳＣとの間のＰ２Ｐ制御コネクション確立が指示される。Ｐ－ＧＷ７はこれを受け、ＴＳ１１にてＢＭＳＣ８に対し、Ｐ２Ｐ制御コネクション設定要求を送信する。ＷｅｂＲＴＣサーバ１７の仲介により、以下の手順でＰ２Ｐ制御コネクション設定がなされる。
（１）Ｐ－ＧＷ７（接続する側）にてＳＤＰを作成し、自身に登録する。登録後、ＢＭＳＣ８（接続される側）にＳＤＰを、ＷｅｂＲＴＣサーバ１７を通じて送信する。ＢＭＳＣ８はこれを受け取り、ＳＤＰを登録する。
（２）同様に、ＢＭＳＣ８もＳＤＰを発行し、自身にこれを登録後、ＷｅｂＲＴＣサーバ１７を通じてＰ－ＧＷ７にＳＤＰを送る。Ｐ－ＧＷ７は受け取ったＳＤＰを登録する。
（３）以上の情報をもとに、Ｐ－ＧＷ７は自身に接続可能となりそうな接続経路の候補（ICE Candidate）をＢＭＳＣ８に送る。ＢＭＳＣ８は受け取ったICE Candidateを登録する。同様にＢＭＳＣ８もICE CandidateをＰ－ＧＷ７に送信する。Ｐ－ＧＷ７はこれを受け取って登録する。

以上で制御コネクション設定は完了し、ＢＭＳＣはＴＳ１２でＰ２Ｐ制御コネクション設定応答を返す。以降、Ｐ－ＧＷ７とＢＭＳＣ８との間にＰ２Ｐ通信が成立する。トランシーバモードを立ち上げた直後は、ＵＥ(I)は図１５の左に示すスタンバイ状態となっており、ＰＴＴ操作部１０９ｃ１は操作されていない状態となるので、ＴＳ１３にてＵＥ(I)はｅＮｏｄｅＢ４にこれを通知する。これを受けたｅＮｏｄｅＢ４はＴＳ１４にて無線ベアラ切断要求をＵＥ(I)に通知する。ＵＥ(I)は無線ベアラを切断し、ＴＳ１５にて無線ベアラ切断応答をｅＮｏｄｅＢ４に返す。このとき、コアネットワーク３内に設定されているユニキャストの物理回線ベアラは設定維持された状態になっている。

図１０に進み、ＴＳ５１にてＵＥ(I)のＰＴＴ操作部１０９ｃ１がオンになったことが検出されると、ＵＥ(I)はこれをｅＮｏｄｅＢ４に通知する。これを受けたｅＮｏｄｅＢ４はＴＳ５２にて無線ベアラ設定要求をＵＥ(I)に通知する。ＵＥ(I)は無線ベアラ（ユニキャストベアラ１２（図１））を設定し、ＴＳ５３にて無線ベアラ設定応答をｅＮｏｄｅＢ４に返す。これにより、ＵＥ(I)はマルチキャストグループ内の他のＵＥ５（ＵＥ(II)、ＵＥ(III)、ＵＥ(IV)）と交信が可能な状態となる。

ＴＳ５４～ＴＳ５６では、ＵＥ(I)から入力された音声のストリームが上りユニキャストデータパケットとして、ｅＮｏｄｅＢ４（無線ベアラ）→Ｓ－ＧＷ６（Ｓ１－Ｕ）→Ｐ－ＧＷ７（Ｓ５）の流れで送信される。図８の上段に示すように、ユニキャストのデータパケット３００のヘッダ３００には、送信元ＩＰアドレス３０１ａとしてＵＥ(I)のＩＰアドレス（11.11.15.105）が、送信先ＩＰアドレス３０１ｂとしてマルチキャストグループのＩＰアドレス（239.255.0.1）が書き込まれている。ＢＭＳＣ８との間のＰＳＰ接続が確立されているＰ－ＧＷ７では、ＴＳ５７において、ＷｅｂＲＴＣ区間をトンネリングさせるために、データパケット３００の全体をＵＤＰカプセル化するパケット変換がなされる。具体的には、図８の中段に示すように、ＵＤＰヘッダ３０１’と、新たなＩＰヘッダ３０１”が付加される。ＩＰヘッダ３０１”には、送信元ＩＰアドレス３０１” ａとしてＷｅｂＲＴＣ区間の起点ノードとなるＰ－ＧＷ７のＩＰアドレス（197.191.0.11）が、送信先ＩＰアドレス３０１” ｂとしてＷｅｂＲＴＣ区間の終点ノードとなるＢＭＳＣ８のＩＰアドレス（224.0.0.22）が書き込まれる。Ｐ－ＧＷ７は、自身に登録された前述のＩＣＥが示す通信経路を参照し、次の送信先（ネクストホッピング）のＩＰアドレスがＢＭＳＣ８となっていることにより、送信先ＩＰアドレス３０１” ｂの書き込み内容を特定することができる。

このようにしてカプセル化されたユニキャストパケットは、ＴＳ５８にてＷｅｂＲＴＣ区間をトンネリングし、ＢＭＳＣ８に送られる。ＢＭＳＣ８では、ＴＳ５９で、受信したユニキャストパケットのカプセル化解除処理を行なう。具体的には、図８の下段に示すように、カプセル化に際して付加されたＩＰヘッダ３０１”を削除する処理となる。これにより、ユニキャストパケットは再び送信元ＩＰアドレス３０１ａがＵＥ(I)（11.11.15.105）が、送信先ＩＰアドレス３０１ｂがマルチキャストグループス（239.255.0.1）のパケットとして図１のマルチキャスト側ブロックＭＢへ送出される。ＴＳ５１～ＴＳ５９の処理は、ＵＥ(I)にてＰＴＴ操作部１０９ｃ１がオフになるまで繰り返し実行される。

ＴＳ６０にてＰＴＴ操作部１０９ｃ１がオフになったことが検出されると、ＵＥ(I)はこれをｅＮｏｄｅＢ４に通知する。これを受けたｅＮｏｄｅＢ４はＴＳ６１にて無線ベアラ切断要求をＵＥ(I)に通知する。ＵＥ(I)は無線ベアラを切断し、ＴＳ６２にて無線ベアラ切断応答をｅＮｏｄｅＢ４に返す。これにより、ＵＥ(I)はスタンバイ状態に移行する。このときも、コアネットワーク３内に設定されているユニキャストの物理回線ベアラは設定維持された状態とされるが、例えば図１５にてトランシーバオフボタン１０９ｃ２がタッチされ、トランシーバモードが解除されると、コアネットワーク３内に設定されているＵＥ(I)との間の物理回線ベアラの設定も解除される。

図１１は、ユーザデータのマルチキャスト配信にかかる通信シーケンスを示すものである。ＵＥ５は、例えばユーザ端末アプリ１０５ａ（図２）の実行によりマルチキャストグループへの参加を表明しておく。参加表明のあったＵＥ５のＩＰアドレスは、ＭＭＥ２を経由してＭＢＭＳ－ＧＷ９にてマルチキャストグループリスト８ｂに登録される。ｅＮｏｄｅＢ４を立ち上げると、コントロールプレーン側の初期化処理として、該ｅＮｏｄｅＢ４を上位装置であるＭＣＥ１０とＭＭＥ２とに起動済み基地局として認識させるために、Ｍ２インターフェース及びＭ３インターフェースを介して順次セットアップ要求及び応答の手続きが実施される（ＴＳ１０１～ＴＳ１０４）。また、ＢＭＳＣ８側からｅＮｏｄｅＢ４にマルチキャストデータの無線による信号伝送路であるマルチキャストベアラを構築するセッション開始要求／応答の手続きが、ＢＭＳＣ８／ＭＢＭＳ－ＧＷ９間（ＴＳ１０５、１０６）及びＭＢＭＳ－ＧＷ９／ＭＭＥ２間（ＴＳ１０７、１０８）で同様に実施される。このセッション開始要求がマルチキャスト用無線ベアラ構築指示に相当する。

続いて、ＭＭＥ２はＭＣＥ１０にセッション開始要求を送信する（ＴＳ１０９）。これを受けたＭＣＥ１０とｅＮｏｄｅＢ４間でもセッション開始要求／応答の手続きが実行される（ＴＳ１１０、ＴＳ１１１）。これにより、ｅＮｏｄｅＢ４はコアネットワーク側からのマルチキャストデータ（コンテンツ）配信のためのセッション開始の準備が完了する。そして、ＭＣＥ１０は、種々のマルチキャストデータ（コンテンツ）配信要求を順次受けるに従い、その配信のスケジューリング（配信時刻及び配信エリア等）を行ない、そのスケジューリング情報をｅＮｏｄｅＢ４に送信する（ＴＳ１１２）。ｅＮｏｄｅＢ４では該スケジューリング情報を受信し、応答をＭＣＥ１０に返す（ＴＳ１１３）。ＭＣＥ１０はＭＭＥ２にセッション開始の応答を返す（ＴＳ１１４）。ｅＮｏｄｅＢ４は接続先となるＵＥ５に対し、通常のＬＴＥネットワークにおけるＭＢＭＳセッションでは、マルチキャストベアラの構築をＵＥ５に指示するために、ＭＣＨによるマルチキャストベアラのＲＡＮ（無線）リソースセットアップを行なう。

ユーザデータのパケットは、ＢＭＳＣ８／ＭＢＭＳ－ＧＷ９間ではＳＧｉｍｂインターフェースを経由して伝送され（ＴＳ１１５）、ＭＢＭＳ－ＧＷ９／ｅＮｏｄｅＢ４間（図１も参照）はＭ１インターフェースを経由して伝送される（ＴＳ１１６）。そして、ｅＮｏｄｅＢ４／ＵＥ５間は無線ベアラであるマルチユニキャストベアラ１２（図１）を経由して伝送される（ＴＳ１１７
）。なお、起点移動端末となるＵＥ(I)にもユーザデータのパケットはマルチユニキャストベアラ１２により伝送されるが、音声送信中のＵＥ(I)においては該ユーザデータのパケットは破棄する処理がなされる。

ＷｅｂＲＴＣはトランスポート層のプロトコルとして簡便なＵＤＰが採用され、Ｐ２Ｐ接続によるデータ通信は応答性やリアルタイム性は極めて良好となる。また、音声データ（ユーザデータ）の上りリンクの送信はユニキャストパケットによりなされるので、配信元ノード装置となるＰ－ＧＷ７に同報送信のための機能を搭載する必要がなく、ＰＴＴ通信システムの大幅な簡略化を図ることができる。また、音声データ（ユーザデータ）は、ＢＭＳＣ８（マルチキャスト配信ノード装置）から先は無線リソースを効率的に活用するｅＭＢＭＳによりマルチキャストパケットの形で各ＵＥ５に配信されるので、無線リソースの消費を最小限に抑えることができ、かつデータ配信の同時同報性も極めて良好に担保することができる。

一方、防災無線モードでは、図１２に示すように、配信元ノード装置が防災無線サーバ１８であり、ユーザデータとなる防災無線データのＩＰパケットの送信起点も防災無線サーバ１８となる。ＰＳＰ接続確立設定処理は防災無線サーバ１８とＢＭＳＣ８との間でなされる（ＴＳ２０１～２０３）。また、防災無線データのＩＰパケットは、ＷｅｂＲＴＣ区間をトンネリング可能なカプセル化が最初からなされた形で発行され、ＴＳ２０４でＢＭＳＣ８に送信されたのち、ＢＭＳＣ８ではＴＳ２０５でカプセル化解除処理がなされ、その後、各ＵＥ５にマルチキャスト配信される流れとなる。

以上、本発明の実施の形態について説明したが、あくまで例示であって、本発明はこれに限定されるものではない。

１ 同報配信システム
２ ＭＭＥ
３ コアネットワーク
４ ｅＮｏｄｅＢ
５ ＵＥ
６ Ｓ－ＧＷ
７ Ｐ－ＧＷ
８ ＢＭＳＣ
９ ＭＢＭＳ－ＧＷ
１０ ＭＣＥ
１１ マルチキャストベアラ
１２ ユニキャストベアラ
１５ インターネット
１７ ＷｅｂＲＴＣサーバ
１８ 防災無線サーバ
１００ マイクロプロセッサ
１０１ ＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ 入出力部
１０５ フラッシュメモリ
１０７ マイク
１０７１ Ａ／Ｄ変換部
１０８ スピーカ
１０８１ Ｄ／Ａ変換部
１０８２ アンプ
１０９ モニタ
１０９ａ メニュー選択画面
１０９ａ１、１０９ａ２ モード選択ボタン
１０９ｂ チャネル設定画面
１０９ｃｓ スタンバイ画面
１０９ｃｔ 送信中画面
１０９ｃｒ 受信画面
１０９ｃ１ ＰＴＴ操作部
１０９ｅ 防災無線画面
１０９１ グラフィックコントローラ
１１０ タッチパネル
１１１ カメラ
１１２ 無線通信部

Claims (6)

1. ユーザデータの配信元ノード装置が上位ＩＰ（Internet Protocol）ネットワークを介してコアネットワークに接続され、さらに該コアネットワークに無線基地局が接続されるとともに、前記配信元ノード装置からの前記ユーザデータを、前記上位ＩＰネットワーク及びコアネットワークを介して前記無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、
   前記コアネットワークに設けられ、前記配信元ノード装置から前記ユーザデータを受信するとともに、ｅＭＢＭＳ（evolved Multimedia Broadcast Multicast Service）により前記ユーザデータを、マルチキャストグループをなす複数の前記移動端末に対しマルチキャスト配信するマルチキャスト配信ノード装置と、
   前記上位ＩＰネットワーク上にて前記配信元ノード装置と前記マルチキャスト配信ノード装置と間で、ＷｅｂＲＴＣ(Web Real-Time Communication)に準拠したＰ２Ｐ(peer-to-peer)接続を確立させるＷｅｂＲＴＣサーバとを備え、
   前記配信元ノード装置は前記Ｐ２Ｐ接続により前記ユーザデータを、前記マルチキャスト配信ノード装置のＩＰアドレスを送信先ＩＰアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、前記マルチキャスト配信ノード装置は前記ユニキャストパケットを、送信先ＩＰアドレスとして前記マルチキャストグループのＩＰアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の前記移動端末に対しマルチキャスト配信することを特徴とする同報配信システム。
2. 上位ＩＰ（Internet Protocol）ネットワークとコアネットワークとが結節する位置に設けられ前記上位ＩＰネットワークに向けたＩＰアドレス管理を行なう、複数の移動端末のうちユーザデータの送出起点となる起点移動端末から前記コアネットワークの上りリンクチャネルを経由して前記ユーザデータを受信・収集し、これをＷｅｂＲＴＣ(Web Real-Time Communication)に準拠したＰ２Ｐ(peer-to-peer)接続によりマルチキャスト配信ノード装置に送出するＰ－ＧＷ（PDN (Packet Data Network) Gateway）が、ユーザデータの配信元ノード装置として前記コアネットワークに直接的に接続され、さらに前記コアネットワークに無線基地局が接続されるとともに、前記配信元ノード装置からの前記ユーザデータを、前記コアネットワークを介して前記無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、
   前記マルチキャスト配信ノード装置は前記コアネットワークに設けられ、前記配信元ノード装置から前記ユーザデータを受信するとともに、ｅＭＢＭＳ（evolved Multimedia Broadcast Multicast Service）により前記ユーザデータを、マルチキャストグループをなす複数の前記移動端末に対しマルチキャスト配信するものであり、
   前記上位ＩＰネットワーク上にて前記配信元ノード装置と前記マルチキャスト配信ノード装置と間で前記Ｐ２Ｐ(peer-to-peer)接続を確立させるＷｅｂＲＴＣサーバとを備え、
   前記配信元ノード装置は前記Ｐ２Ｐ接続により前記ユーザデータを、前記マルチキャスト配信ノード装置のＩＰアドレスを送信先ＩＰアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、前記マルチキャスト配信ノード装置は前記ユニキャストパケットを、送信先ＩＰアドレスとして前記マルチキャストグループのＩＰアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の前記移動端末に対しマルチキャスト配信することを特徴とする同報配信システム。
3. 前記マルチキャストグループをなす複数の前記移動端末の一つのものが前記起点移動端末として定められ、前記ユーザデータは該起点移動端末から送出される音声、文字列及び画像の少なくともいずれかの情報を含むものであり、該ユーザデータが前記マルチキャストグループをなす複数の前記移動端末の残余をなす配信先移動端末に配信される請求項２記載の同報配信システム。
4. マルチキャストグループをなす複数の前記移動端末に音声入力部が各々設けられ、前記起点移動端末となる移動端末の前記音声入力部から音声が入力されるに伴い、前記配信先移動端末に該音声のストリーミングデータが前記ユーザデータとして逐次配信される請求項３記載の同報配信システム。
5. マルチキャストグループをなす複数の前記移動端末にＰＴＴ（Press To Talk）操作部が各々設けられ、該ＰＴＴ操作部が操作されている状態では前記音声入力部からの音声のストリーミングデータが前記配信先移動端末に配信され、該操作が解除された状態では、前記配信先移動端末のいずれかが前記起点移動端末となって配信される前記音声のストリーミングデータの受信スタンバイ状態となる請求項４記載の同報配信システム。
6. 前記配信元ノード装置は前記上位ＩＰネットワーク上に設けられ、音声、文字列及び画像の少なくともいずれかよりなる防災無線データを前記ユーザデータとして前記Ｐ２Ｐ接続により前記マルチキャスト配信ノード装置に送出す防災無線サーバである請求項１に記載の同報配信システム。

Images