(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-19
(45)【発行日】2023-07-27
(54)【発明の名称】同報配信システム
(51)【国際特許分類】
H04W 76/40 20180101AFI20230720BHJP
H04W 4/10 20090101ALI20230720BHJP
H04W 4/06 20090101ALI20230720BHJP
H04W 80/04 20090101ALI20230720BHJP
H04M 11/00 20060101ALI20230720BHJP
H04M 11/04 20060101ALI20230720BHJP
【FI】
H04W76/40
H04W4/10
H04W4/06 171
H04W80/04
H04M11/00 302
H04M11/04
H04W4/06 150
(21)【出願番号】P 2019016527
(22)【出願日】2019-01-31
【審査請求日】2022-01-20
(73)【特許権者】
【識別番号】000004330
【氏名又は名称】日本無線株式会社
(74)【代理人】
【識別番号】110002516
【氏名又は名称】弁理士法人白坂
(72)【発明者】
【氏名】北田 大己
(72)【発明者】
【氏名】新井 国充
(72)【発明者】
【氏名】勝又 貞行
【審査官】田部井 和彦
(56)【参考文献】
【文献】特表2016-535963(JP,A)
【文献】特表2016-537920(JP,A)
【文献】米国特許出願公開第2017/0295475(US,A1)
【文献】特開2018-160879(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04W 4/00-99/00
H04M 11/00
H04M 11/04
DB名 3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
ユーザデータの配信元ノード装置が上位IP(Internet Protocol)ネットワークを介してコアネットワークに接続され、さらに該コアネットワークに無線基地局が接続されるとともに、前記配信元ノード装置からの前記ユーザデータを、前記上位IPネットワーク及びコアネットワークを介して前記無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、
前記コアネットワークに設けられ、前記配信元ノード装置から前記ユーザデータを受信するとともに、eMBMS(evolved Multimedia Broadcast Multicast Service)により前記ユーザデータを、マルチキャストグループをなす複数の前記移動端末に対しマルチキャスト配信するマルチキャスト配信ノード装置と、
前記上位IPネットワーク上にて前記配信元ノード装置と前記マルチキャスト配信ノード装置と間で、WebRTC(Web Real-Time Communication)に準拠したP2P(peer-to-peer)接続を確立させるWebRTCサーバとを備え、
前記配信元ノード装置は前記P2P接続により前記ユーザデータを、前記マルチキャスト配信ノード装置のIPアドレスを送信先IPアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、前記マルチキャスト配信ノード装置は前記ユニキャストパケットを、送信先IPアドレスとして前記マルチキャストグループのIPアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の前記移動端末に対しマルチキャスト配信することを特徴とする同報配信システム。
【請求項2】
上位IP(Internet Protocol)ネットワークとコアネットワークとが結節する位置に設けられ前記上位IPネットワークに向けたIPアドレス管理を行なう、複数の移動端末のうちユーザデータの送出起点となる起点移動端末から前記コアネットワークの上りリンクチャネルを経由して前記ユーザデータを受信・収集し、これをWebRTC(Web Real-Time Communication)に準拠したP2P(peer-to-peer)接続によりマルチキャスト配信ノード装置に送出するP-GW(PDN (Packet Data Network) Gateway)が、ユーザデータの配信元ノード装置として前記コアネットワークに直接的に接続され、さらに前記コアネットワークに無線基地局が接続されるとともに、前記配信元ノード装置からの前記ユーザデータを、前記コアネットワークを介して前記無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、
前記マルチキャスト配信ノード装置は前記コアネットワークに設けられ、前記配信元ノード装置から前記ユーザデータを受信するとともに、eMBMS(evolved Multimedia Broadcast Multicast Service)により前記ユーザデータを、マルチキャストグループをなす複数の前記移動端末に対しマルチキャスト配信するものであり、
前記上位IPネットワーク上にて前記配信元ノード装置と前記マルチキャスト配信ノード装置と間で前記P2P(peer-to-peer)接続を確立させるWebRTCサーバとを備え、
前記配信元ノード装置は前記P2P接続により前記ユーザデータを、前記マルチキャスト配信ノード装置のIPアドレスを送信先IPアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、前記マルチキャスト配信ノード装置は前記ユニキャストパケットを、送信先IPアドレスとして前記マルチキャストグループのIPアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の前記移動端末に対しマルチキャスト配信することを特徴とする同報配信システム。
【請求項3】
前記マルチキャストグループをなす複数の前記移動端末の一つのものが前記起点移動端末として定められ、前記ユーザデータは該起点移動端末から送出される音声、文字列及び画像の少なくともいずれかの情報を含むものであり、該ユーザデータが前記マルチキャストグループをなす複数の前記移動端末の残余をなす配信先移動端末に配信される請求項2記載の同報配信システム。
【請求項4】
マルチキャストグループをなす複数の前記移動端末に音声入力部が各々設けられ、前記起点移動端末となる移動端末の前記音声入力部から音声が入力されるに伴い、前記配信先移動端末に該音声のストリーミングデータが前記ユーザデータとして逐次配信される請求項3記載の同報配信システム。
【請求項5】
マルチキャストグループをなす複数の前記移動端末にPTT(Press To Talk)操作部が各々設けられ、該PTT操作部が操作されている状態では前記音声入力部からの音声のストリーミングデータが前記配信先移動端末に配信され、該操作が解除された状態では、前記配信先移動端末のいずれかが前記起点移動端末となって配信される前記音声のストリーミングデータの受信スタンバイ状態となる請求項4記載の同報配信システム。
【請求項6】
前記配信元ノード装置は前記上位IPネットワーク上に設けられ、音声、文字列及び画像の少なくともいずれかよりなる防災無線データを前記ユーザデータとして前記P2P接続により前記マルチキャスト配信ノード装置に送出す防災無線サーバである請求項1に記載の同報配信システム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は携帯端末等の移動端末に音声、画像あるいは文字などのユーザデータを配信するシステムに関するものであり、特にLTE(Long Term Evolution)システムなどにおいて、上記ユーザデータを複数の移動端末に対し、より簡便な仕組みにて同報配信できる同報配信システムに関する。
【背景技術】
【0002】
移動端末の普及に伴い、災害時等の緊急情報を複数の移動端末に対して同報送信できるようにし、例えば防災無線システムとして活用する要望が高まっている。また、緊急時に限らず、比較的近距離のエリア内で移動端末同士をPTT(Press To Talk)形式の半二重通信機器として扱うこと、すなわち移動端末をPTT端末(いわゆる、トランシーバシステム)の代わりに使用したい、という要望も出されている。この場合、PTTオンにて送話中の移動端末を音声ストリームの配信元とみなせば、上記のトランシーバシステムも音声ストリームの同報配信システムとみなすことができる。
【0003】
例えば、防災無線システムでは、音声ストリームの配信元となる親局装置に同報送信機能を組み込み、該親局による無線制御により複数の子局装置に音声ストリームが同報送信されることとなる(特許文献1)。一方、移動端末をPTT通信用に代用する技術として、MCPTT(Mission Critical Push To Talk:例えば特許文献2)が知られている。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2018-166270号公報
【文献】WO2017/126246号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
特許文献1にみられる防災無線システムは、音声ストリームの配信元装置を、同報送信機能を組み込んだ専用の親局装置として構築しなければならないため、設置コストの高騰を招く問題がある。また、一般ユーザが所持する移動端末を子局装置として利用したい場合は、親局装置との間での直接的な無線通信を行なうための子局インターフェースを組み込んでおかなければならず、非対応の移動端末では音声ストリームを同報受信することができない。すなわち、この方式は、既存のネットワークのインフラを全く活用できない、という難点がある。
【0006】
一方、移動端末をPTT端末として活用できるようにする特許文献2のMCPTTシステムは、複数の移動端末の間に介在してPTT通信を成立させるためのMCPTTサーバを設ける必要があり、プロトコルも複雑となる欠点がある。
【0007】
本発明の課題は、既存の移動通信ネットワークを活用しつつ、ユーザデータを複数の移動端末に対し、より簡便な仕組みにて同報配信できる同報配信システムを提供することにある。
【課題を解決するための手段】
【0008】
上記の課題を解決するために、本発明の同報配信システムは、ユーザデータの配信元ノード装置が上位IP(Internet Protocol)ネットワークを介してコアネットワークに接続され、さらに該コアネットワークに無線基地局が接続されるとともに、配信元ノード装置からのユーザデータを、上位IPネットワーク及びコアネットワークを介して無線基地局に無線接続される複数の移動端末に配信するように構成されるとともに、コアネットワークに設けられ、配信元ノード装置からユーザデータを受信するとともに、eMBMS(evolved Multimedia Broadcast Multicast Service)によりユーザデータを、マルチキャストグループをなす複数の移動端末に対しマルチキャスト配信するマルチキャスト配信ノード装置と、上位IPネットワーク上にて配信元ノード装置とマルチキャスト配信ノード装置と間で、WebRTC(Web Real-Time Communication)に準拠したP2P(peer-to-peer)接続を確立させるWebRTCサーバとを備え、配信元ノード装置はP2P接続によりユーザデータを、マルチキャスト配信ノード装置のIPアドレスを送信先IPアドレスとして指定するユニキャストパケットとして該マルチキャスト配信ノード装置に送信する一方、マルチキャスト配信ノード装置はユニキャストパケットを、送信先IPアドレスとしてマルチキャストグループのIPアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数の移動端末に対しマルチキャスト配信することを特徴とする。
【発明の効果】
【0009】
本発明の同報配信システムにおいては、ユーザデータの配信元ノード装置が、上位IP(Internet Protocol)ネットワークを介してコアネットワークに接続される。該配信元ノード装置は上位IPネットワーク上のWebRTCサーバが確立するP2P接続により、ユーザデータのIPパケットを、コアネットワーク上のマルチキャスト配信ノード装置を送信先とするユニキャストパケットとして送出する。マルチキャスト配信ノード装置はユニキャストのIPパケットをマルチキャストのIPパケットに変換し、マルチキャストグループをなす複数の移動端末に対しマルチキャスト配信する。WebRTCはトランスポート層のプロトコルとして、接続確認のためのステートが排除され、かつ送受信されるデータの誤りや順序の違いなどを検出する機能有さない簡便なUDP(User Datagram Protocol)が採用される。その結果として実現されるP2P接続によるデータ通信は、信頼性にはやや劣るが応答性やリアルタイム性は極めて良好となる。すなわち、本発明の同報配信システムにおいては、配信元ノード装置からマルチキャスト配信ノード装置へユーザデータを、WebRTC特有のUDP上のP2P通信によりスムーズに送出できる。また、該送信はユニキャストパケットによりなされるので、配信元ノード装置に同報送信のための機能(インターフェース)を搭載する必要がなく、装置の大幅な簡略化を図ることができる。そしてユーザデータは、マルチキャスト配信ノード装置から先は無線リソースを効率的に活用するeMBMSによりマルチキャストパケットの形で各移動端末に配信されるので、無線リソースの消費を最小限に抑えることができ、かつデータ配信の同時同報性も極めて良好に担保することができる。
【図面の簡単な説明】
【0010】
【
図1】本発明の一実施形態である同報配信システムの電気的構成を示すブロック図。
【
図2】UE(移動端末)の電気的構成の一例を示すブロック図。
【
図4】3GPPのコントロールプレーンのプロトコルスタックを概念的に示す図。
【
図5】3GPPのユーザプレーンのプロトコルスタックを概念的に示す図。
【
図6A】3GPPの下りリンクのチャネルマッピングを概念的に示す図。
【
図6B】同じく上りリンクのチャネルマッピングを概念的に示す図。
【
図8】ユニキャストのIPパケットとマルチキャストのIPパケットとの間の変換の概念を説明する図。
【
図9】UEのコアネットワークへのアタッチと、P-GW/BMSC間のWebRTCによるP2P接続にかかるシーケンスを示す通信フロー図。
【
図10】UEからユーザデータをBMSCにストリーミング送信するシーケンスを示す通信フロー図。
【
図11】BMSCからデータ配信先のUEにマルチキャストベアラを構築する際のセッションシーケンスを示す通信フロー図。
【
図12】インターネット上の防災無線サーバとBMSC間のWebRTCによるP2P接続、及び防災無線サーバからユーザデータをBMSCにストリーミング送信するシーケンスを示す通信フロー図。
【
図14】UEのトランシーバ通信チャネルの設定画面の一例を示す図。
【
図15】UEのトランシーバ通信中の画面の一例を示す図。
【発明を実施するための形態】
【0011】
以下、本発明を実施するための形態を添付の図面に基づいて説明する。
(実施形態1)
図1は、本発明の一実施形態である同報配信システムの全体構成を示すブロック図である。同報配信システム1においては、上位IPネットワークをなすインターネット15に3GPP仕様のコアネットワーク3が接続されている。コアネットワーク3には無線基地局をなすeNodeB4が接続されるとともに、eNodeB4には複数のUE5(User Equipment:移動端末)が無線接続される。また、ユーザデータの配信元ノード装置として、
図1においては、後述のP-GW7と防災無線サーバ18がインターネット15(上位IPネットワーク)に接続されている。つまり、これらの配信元ノード装置はインターネット15を介してコアネットワーク3に接続されている。そして、配信元ノード装置(P-GW7と防災無線サーバー18)からのユーザデータは、インターネット15及びコアネットワークを介してP-GW7と防災無線サーバ18に無線接続される複数のUE5に同報配信される。
【0012】
次に、コアネットワーク3のユニキャスト側ブロックUBは、コアネットワーク3のコントロールプレーン側のゲートウェイとなるMME(Mobility Management Entity)2、ユーザプレーン側のゲートウェイとなるS-GW(Serving Gateway)6、外部ネットワーク(本実施形態では上位IPネットワークであるインターネット15)とコアネットワーク3との結節点に位置し、外部ネットワーク側(インターネット15側)に向けたIPアドレス管理を行なうP-GW(PDN (Packet Data Network) Gateway)7とを有する。ユニキャスト側ブロックのコントロールプレーン側においてeNodeB4は、S1-MMEインターフェースを介してMME2に接続される。また、ユーザプレーン側においてeNodeB4は、S1-Uインターフェースを介してS-GW6に接続される。また、S-GW6はS5インターフェースを介してP-GW7と接続される。
【0013】
一方、コアネットワーク3のマルチキャスト側ブロックMBは、上位IPネットワーク(インターネット15)からのユーザデータの受信ノードとなるBMSC(Broadcast Multicast Service Center)8、MBMSにおけるコアネットワーク3のユーザプレーン側のゲートウェイとなるMBMS-GW(Multimedia Broadcast Multicast Service Gateway)9、ユニキャスト側ブロックUBと共用されるMME2、及びユーザプレーン側を送信されるマルチキャストデータのUE(移動端末)5への送信制御を司るMCE(Multi-cell multicast Coordination Entity)10を有する。MBMS-GW9はM1インターフェースを介してeNodeB4と接続され、SMインターフェースを介してMME2と接続され、さらにSG-mb及びSGi-mbインターフェースを介してBMSC8と接続される。マルチキャスト側ブロックMBにおいてeNodeB4は、M2インターフェースを介して該MCE10に接続される。MCE10はM3インターフェースを介してMME2に接続される。
【0014】
BMSC8は、マルチキャストのユーザデータを収集し、配信先となるグループメンバーシップやQoS(Quality of Service)の管理、マルチキャスト/ブロードキャストセッションのアナウンス、セキュリティなどマルチキャスト配信全般のサービス管理を行なう。MBMS-GW9はユーザプレーン(U-Plane)側のゲートウェイであり、eNodeB4に対するマルチキャストデータ伝送やセッション制御を行なう。他方、MME2は、コントロールプレーン(C-Plane)側のゲートウェイであり、基地局であるeNodeB4との間で通信に必要な制御信号を仲介する交換局としての機能を果たす。具体的には、NAS(Non Access Stratum)と呼ばれるUE認証制御や、ルーティング(接続経路設定)の要求、さらにはハンドオーバーの際にUE5ごとのデータ送受信管理情報を異なるeNodeB4間で交換させるための仲介を行なう。MCE10はマルチキャスト制御装置に相当し、MBSFNの無線リソース管理及び割当等の機能を担うとともに、MBSFNを構成するeNodeB間にてデータ送信に使用する無線リソースを指定することにより、eNodeB4が受け持つ複数のUE5への、マルチキャストベアラ11を使用したコンテンツ配信を同期させる役割を果たす。eMBMS側ブロックにおいてeNodeB4は、M2インターフェースを介して該MCE10に接続される。MCE10はM3インターフェースを介してMME2に接続される。
【0015】
M1インターフェースは、ユーザプレーンのインターフェースであり、マルチキャストにおけるユーザデータの伝送路として機能する。一方、M2インターフェースとM3インターフェースはコントロールプレーンのインターフェースであり、マルチキャストにおける制御データの伝送路として機能する。また、SGmb/SGimbインターフェースは、コアネットワーク3におけるBMSC8とMBMS-GW9間のコントロールプレーン及びユーザプレーンの共用インターフェースである。また、SMインターフェースは、MBMS-GW9がMME2(コントロールプレーン)側の制御状態に対する参照ポイントを形成するためのものである。
【0016】
コアネットワーク3のマルチキャスト側ブロックMBの構成は、複数のUE5に向け、音声、画像(静止画及び動画)、文字列ないしそれらの組み合わせからなるコンテンツデータ(ユーザデータ)が同時にストリーミング配信される、といった状況を想定して構築されている。すなわち、マルチキャスト配信されるコンテンツデータは、その収集と配信管理のためにBMSC8を一旦経由する形でコアネットワーク3に送信される。また、コンテンツを構成するマルチキャストデータは、ユーザプレーン側のゲートウェイ装置であるMBMS-GW9にて受信する。一方、制御データについてはコントロールプレーン側のゲートウェイ装置であるMME2が、SMインターフェースを介してMBMS-GW9を参照する形で生成する。該制御データは、ユーザプレーンとは別の伝送経路(M3/M2インターフェース)を介して、ユーザデータから分離されつつeNodeB4に流れるようになっている。
【0017】
コアネットワーク3に設けられたBMSC8は、P-GW7又は防災無線サーバ18(配信元ノード装置)からユーザデータを受信するとともに、マルチキャストグループをなす複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)に対し該ユーザデータをeMBMSによりマルチキャスト配信するマルチキャスト配信ノード装置として機能する。一方、インターネット15(上位IPネットワーク)上には、配信元ノード装置(P-GW7又は防災無線サーバー18)とBMSC8と間でWebRTC(Web Real-Time Communication)に準拠したP2P(peer-to-peer)接続を確立させるWebRTCサーバ17が設けられている。
【0018】
WebRTCは、クライアントがサーバにデータを要求する一般のクライアント/サーバモデルとは異なり、クライアントとなる複数の端末及びノード装置間の通信において各クライアントがデータを保持し、他のクライアントに対して直接的にデータの送信・要求を行う(P2P)。また、通信プロトコルには基本的にTCP/IP(Transmission Control Protocol / Internet Protocol)の代わりにUDP/IP(User Datagram Protocol / Internet Protocol)を用いる。
【0019】
具体的には、TCPの場合、ユーザデータ本体のパケット通信以外に、開始処理と終了処理が実施されるが、UDPは開始処理及び終了処理は実施されない。また、TCPではパケットの受信に対しACK(acknowledgement)を応答として返すが、UDPではACKを返さない。そのため、UDPのデータ送受信の信頼性はTCPには及ばないが、送受信の手順が簡略化されている分、通信のリアルタイム性(同時性)が大幅に向上する。送受信の対象が音声や映像の場合、ストリーミングに多少の途切れが生じても直ちに大きな問題につながらないことから、UDPの採用により同報送信に重要な同時性が担保されることは有利であるといえる。
【0020】
後述のトランシーバモードにおいては、P-GW7及びBMSC8をクライアント・ノードとして、UE5からの上りリンクの音声データパケットをBMSC8へ送信する処理がWebRTCによるP2P通信により実施される。また、防災無線モードでは防災無線サーバ18及びBMSC8クライアント・ノードとして、防災無線サーバ18からの防災無線データをBMSC8へ送信する処理がWebRTCによるP2P通信により実施される。いずれの場合もWebRTCサーバ17の仲介により、クライアント・ノード間では以下の情報が共有される。
【0021】
・SDP(Session Description Protocol)
UDP通信に必要な各ノードの情報を示す文字列であり、セッションの属性、メディアの形式、IPアドレス、ポート番号、通信帯域などを含むWebRTCのP2P通信は双方向であるが、本実施形態では、上りリンクにおけるユーザデータパケットの送信方向はP-GW7からBMSC8に向かう一方向のみであり、下りリンクはWebRTCではなくeMBMSが担う。よって、ここでは、P-GW7がBMSC8に対しSDPをOfferし、それに対してBMSC8がAnswer SDPを返すというOffer/Answerモデルで通信が行われる。
・ICE(Interactive Connectivity Establishment)
相手ノードに到達する可能性のある通信経路に関する情報を示すものであり、それらの経路候補をICE Candidateとしてノード間で共有している必要がある。
【0022】
図2は、UE5の電気的構成の一例を示すブロック図である。UE5はマイコン100を処理主体として備えている。該マイコン100は、CPU101、プログラム実行領域となるRAM102、ROM103、入出力部104及びそれらを相互に接続するバス106等からなる。また、バス106にはフラッシュメモリ105が接続され、ここにUE5の動作環境を構築するためのOS(図示せず)と、ユーザ端末アプリ105aがインストールされている。ユーザ端末アプリ105aは、UE5をPTT端末(トランシーバ端末として機能させるためのPTTプログラムモジュール105bと、防災無線の受信端末として機能させるための防災無線プログラムモジュール105cとを含む。また、入出力部104には音声入力部(あるいは送話器)としてのマイク107がA/D変換部1071を介して接続されている。また、音声出力部(あるいは受話器)としてのスピーカ108がA/D変換部1081及びアンプ1082を介して接続されている。
【0023】
また、入出力部104にはグラフィックコントローラ1091を介してモニタ109が接続されている。モニタ109には入力部をなすタッチパネル110が重ね合わされ、モニタ109に表示形成される種々のソフト操作部(ボタンやアイコンなど:
図13~
図17参照)と協働して、UE5の動作制御に必要な種々の情報入力がなされるようになっている。タッチパネル110はタッチパネルコントローラ1101を介して入出力部104に接続されている。入出力部104には静止画ないし動画を撮影するためのカメラ111が接続されている。さらに、バス106には無線通信部112が接続され、該無線通信部112を介してeNodeB4(
図1)と無線接続される。
【0024】
図1に戻り、P-GW7は、複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)のうちユーザデータの送出起点となるUE(I)(起点移動端末)から該コアネットワーク3の上りリンクチャネルを経由してユーザデータを受信・収集し、これをP2P接続によりBMSC8(マルチキャスト配信ノード装置)に送出する役割を果たす。P-GW7をこのような形態の配信元ノード装置として機能させることで、ユーザが携帯するUE5から所望のユーザデータを他のUE5に対し随時同報配信できる利点が生ずる。
【0025】
具体的には、マルチキャストグループをなす複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)の一つのもの(
図1ではUE(I))を起点移動端末として定めることができる。ユーザデータは該起点移動端末(UE(I))から送出される音声(例えば、通話音声)、文字列(例えば、電子メールやSNSメッセージなど)及び画像(静止画又は動画)の少なくともいずれかの情報を含むものとすることができる。該ユーザデータがマルチキャストグループをなす複数のUE5(移動端末)の残余をなす配信先移動端末(
図1では、UE(II)、UE(III)、UE(IV))に配信されることとなる。これにより、グループ内のUE5同士の間にてユーザデータを同報形態で送受信でき、簡便な装置構成によりリアルタイム性の高い情報交換を一対多の関係で容易に行うことができる。
【0026】
マルチキャストグループをなす複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)の各々には、
図2に示す如く、マイク107(音声入力部)が設けられる。起点端末装置となるUE(I)のマイク107から音声が入力されるに伴い、配信先移動端末(UE(II)、UE(III)、UE(IV))に該音声のストリーミングデータがユーザデータとして逐次配信される。これにより、起点端末装置となるUE(I)にて入力される音声ストリームを、マルチキャストグループ内の配信先移動端末(UE(II)、UE(III)、UE(IV))にて同時に供給することができる。
【0027】
本実施形態において
図1に示す同報配信システム1は、配信元ノード装置がP-GW7となる場合はUE5がトランシーバ端末として使用され、マルチキャストグループをなす複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV))間で半二重通信による交信が可能となるトランシーバモードとしての使用形態となる。一方、配信元ノード装置が防災無線サーバ18となる場合は、複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV))はいずれも、防災無線サーバ18から音声、文字列及び画像の少なくともいずれかよりなる防災無線データをユーザデータとして受信する同報受信端末として使用され、防災無線モードでの使用形態となる。UE5をどのモードで使用するかは、ユーザ端末アプリ105aの実行により、UE5のモニタ109に
図13のメニュー選択画面109aを表示し、該画面109a上にて、モード選択ボタン109a1、109a2をタッチすることにより選択可能である。また、トランシーバモードでは、
図14に示すように、PTT交信のチャネル設定画面109bを表示し、チャネル選択ボタン109b1の操作により、PTT交信のチャネル設定を行なうように構成することができる。異なるチャネル選択ボタン109b1には互いに異なるマルチキャストグループのIPアドレスが割り当てられており、所望のチャネル選択ボタン109b1を選択すると、対応するマルチキャストグループに参加するUE同士のみでPTT交信が可能となる。つまり、マルチキャストグループのIPアドレス設定により、一般的なトランシーバの交信チャネル設定と同様の概念を実現することができる。
【0028】
例えば、複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)は、上記メニュー選択画面109aにてトランシーバモード選択ボタン109a1がタッチされると、
図15左のトランシーバモードのスタンバイ画面109csに遷移し、UE5はトランシーバモードにて機能するようになる。スタンバイ画面109cs上にはPTT(Press To Talk)操作部109c1が各々設けられている。モニタ109に表示されるスタンバイ画面109cs上にて該PTT操作部109c1は、タッチパネル110の対応する領域とともにソフトボタンとして形成されている。
【0029】
図15左のスタンバイ画面109csにてPTT操作部109c1がタッチ操作されると、
図15右の送信中画面109ctに切り替わり、マイク107(音声入力部:
図1)から入力される音声のストリーミングデータが配信先移動端末(UE(II)、UE(III)、UE(IV))に配信される。一方、該操作が解除された状態では
図15左のスタンバイ画面109csに戻り、配信先移動端末(UE(II)、UE(III)、UE(IV))のいずれかが送出起点端末装置となって配信される音声のストリーミングデータの受信スタンバイ状態となる。このとき、同じマルチキャストグループの他のUE5から音声ストリームを受信すると、
図15真ん中の受信画面109crとなり、
図2のスピーカ108から受信した音声が出力される。これにより、マルチキャストグループをなす複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV))は、半二重通信による音声交信、すなわちトランシーバとしての交信が可能となる。なお、音声受信中となる受信画面109crにおいては、PTT操作部109c1は表示されないか、あるいは無効化され、音声送信が不能な状態となる。また、スタンバイ画面109cs又は受信画面109cr上に形成されたオフボタン109c2をタッチするとトランシーバモードは解除され、
図13のメニュー画面に戻る。
【0030】
なお、トランシーバモードにおいてユーザデータは、音声ストリームデータのほか、
図2のカメラ111が撮影する動画ストリームや静止画の画像データとして同報配信することも可能である。該画像データに基づく画像は、
図17に示すように、受信画面109c上にて画像表示領域109cmに表示することができる。
【0031】
一方、
図13のメニュー選択画面109aにて防災無線モード選択ボタン109a2がタッチされると、
図16の防災無線画面109eに遷移し、UE5は防災無線モードにて機能するようになる。インターネト15(上位IPネットワーク)上に設けられた防災無線サーバ18は、音声(あるいは画像)よりなる防災無線データをユーザデータとしてP2P接続によりBMSC8(マルチキャスト配信ノード装置)に送出する。BMSC8は該防災無線データを複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV))に同報配信する。防災無線データに含まれる音声データは、
図2のスピーカ108から音声出力される。また、画像(動画又は静止画)データが含まれる場合は、
図16の防災無線画面109e上にて画像出力させることができる。なお、防災無線画面109e上に形成されたオフボタン109d1をタッチすると防災無線モードは解除され、
図13のメニュー画面に戻る。
【0032】
図1に戻り、図中、実線の矢印はユニキャストデータフローを、白抜きの矢印はマルチキャストデータフローをそれぞれ示す。また、一点鎖線の矢印は制御データフローを示し、破線の矢印はWebRTCによるPSP通信となっている区間を示す。トランシーバモードにおいては、
図1において、複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV):移動端末)のうちPTT操作部109c1(
図15)が操作されることで起点移動端末となるUE(I)から、音声ストリームデータ(ユーザデータ)が該コアネットワーク3の上りリンクチャネルを経由してP-GW7に送信される。このとき、UE(I)とeNodeB4との間の無線ベアラはユニキャストベアラ12が使用され、S-GW6を経てP-GW7までの間はS1-U及びS5の各インターフェースを介した物理回線ベアラが使用される。そして、P-GW7とBMSC8との間はインターネット15上でのWebRTCによるP2P接続となり、UE(I)からBMSC8までの間を音声データ(ユーザデータ)はユニキャストのIPパケットによりストリーミングされる。
【0033】
これに対し、防災無線モードでは配信元ノード装置となる防災無線サーバ18自体がユーザデータ送信の起点となるため、コアネットワーク3内の上りリンク伝送路は使用されない。また、防災無線サーバ18とBMSC8との間はインターネット15上でのWebRTCによるP2P接続となり、防災無線サーバ18からBMSC8までの間を防災無線データがユニキャストのIPパケットによりストリーミングされる。
【0034】
このように、P-GW7又は防災無線サーバ18(配信元ノード装置)はP2P接続によりユーザデータを、BMSC8のIPアドレスを送信先IPアドレスとして指定するユニキャストパケットとしBMSC8に送信する。一方、BMSC8はそのユニキャストパケットを、送信先IPアドレスとしてマルチキャストグループのIPアドレスが指定されたマルチキャストパケットに変換し、該マルチキャストパケットを複数のUE5(UE(I)、UE(II)、UE(III)、UE(IV))に対しマルチキャスト配信する。コアネットワーク3のマルチキャスト側ブロックMBの構成は、eMBMS仕様の標準的な構成であり、eNodeB4とUE5との間にマルチキャスト配信専用の無線ベアラであるマルチキャストベアラ11を構築する前提で、BMSC8、MBMS-GW9、MME2、MCE10及びeNodeB4間の通信セッションの構築がなされる。
【0035】
図3は、データ伝送に使用するIPパケットの構造示す模式図である。IPパケット300はIPヘッダ301とペイロード302とからなり、IPヘッダ301にはPDU識別番号、データの送信元アドレス301a、送信先アドレス301bなどが書き込まれる。また、ペイロード302には、ユーザデータの場合は配信コンテンツの主体となるデータが、制御データの場合は種々の制御コマンドなどが書き込まれる。
【0036】
図4及び
図5は、LTEシステムにおける無線インターフェースのプロトコルスタックを示し、
図5はユーザプレーンのプロトコルスタックを、
図4はコントロールプレーンのプロトコルスタックを示している。無線インターフェースプロトコルは、OSI参照モデルのレイヤ1~レイヤ3に区分されており、レイヤ1はPHY(物理)層である。レイヤ2は、MAC(Medium Access Control:メディアアクセス制御)層、RLC(Radio Link Control:無線リンク制御)層、及びPDCP(Packet Data Convergence Protocol:パケットデータ暗号化)層を含む。レイヤ3は、RRC(Radio Resource Control:無線リソース制御)層及びNAS(Non-Access Stratum:非アクセス)層を含む。
【0037】
各層の役割は以下の通りである。
・PHY層:符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行なう。UE5のPHY層とeNodeB4のPHY層との間では、物理チャネルを介してデータ及び制御信号が伝送される。
・MAC層:データの優先制御、HARQによる再送制御処理、及びランダムアクセス手順等を行なう。UE5のMAC層とeNodeB4のMAC層との間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。eNodeB4のMAC層は、上下リンクのトランスポートフォーマット(トランスポートブロックサイズ、変調・符号化方式(MCS))及びUE5への割当リソースブロックを決定するスケジューラを含む。
【0038】
・RLC層:MAC層及びPHY層の機能を利用してデータを受信側のRLC層に伝送する。UE5のRLC層とeNodeB4のRLC層との間では、論理チャネルを介してデータ及び制御信号が伝送される。
・PDCP層:PDUのヘッダ圧縮・伸張、及び暗号化・復号化を行なう。
・RRC層:制御信号を取り扱う制御プレーンでのみ定義される。UE5のRRC層とeNodeB4のRRC層との間では、各種設定のためのメッセージ(RRCメッセージ)が伝送される。RRC層は、無線ベアラ(マルチキャストベアラ及びユニキャストベアラ)の確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル及び物理チャネルを制御する。UE5のRRCとeNodeB4のRRCとの間に接続(RRC接続)がある場合、UE5はRRCコネクティッドモードとなり、そうでない場合はRRCアイドルモードとなる。
【0039】
以上の層はコントロールプレーン及びユーザプレーンの双方にて使用される。一方、コントロールプレーンのみ、UE5及びMME3には、RRC層よりさらに上位にセッション管理及びモビリティ管理等を行なうNAS層が設けられる。また、eNodeB4のコアネットワーク側とのユーザデータ伝送インターフェースには、GTP-U(GPRS(General Packet Radio Service)Tunneling Protocol for User Plane)層が設けられている。GTP-U層は、接続先のUE5(移動端末)及び使用する無線ベアラの識別を行なうためのものである。
【0040】
次に、
図6Aは、LTEシステムにおける下りリンクのチャネルマッピングを示す。ここでは、論理チャネル(Downlink Logical Channel)、トランスポートチャネル(Downlink Transport Channel)及び物理チャネル(Downlink Physical Channel)相互間のマッピング関係を示している。以下、順に説明する。
・DTCH(Dedicated Traffic Channel:専用トラフィックチャネル)は、データの送信のための個別論理チャネルである。DTCHは、トランスポートチャネルであるDLSCH(Downlink Shared Channel:下りシェアドチャネル)にマッピングされる。
・DCCH(Dedicated Control Channel:専用制御チャネル):UE5とネットワークとの間の個別制御情報を送信するための論理チャネルである。DCCHは、UE5がRRC接続を有する場合に用いられる。DCCHは、DLSCHにマッピングされる。
・CCCH(Common Control Channel:共通制御チャネル):UE5とeNodeB4との間の送信制御情報のための論理チャネルである。CCCHは、UE5がeNodeB4(ネットワーク)との間でRRC接続を有していない場合に用いられる。CCCHは、DLSCHにマッピングされる。
【0041】
・BCCH(Broadcast Control Channel:放送制御チャネル):システム情報配信のための論理チャネルである。BCCHは、トランスポートチャネルであるBCH(Broadcast Channel、放送チャネル)又はDLSCHにマッピングされる。
・PCCH(Paging Control Channel:ページング制御チャネル):ページング情報、及びシステム情報変更を通知するための論理チャネルである。PCCHは、トランスポートチャネルであるPCH(Paging Channel:ページングチャネル)にマッピングされる。
・MCCH(Multicast Control Channel:マルチキャスト制御チャネル):マルチキャスト伝送のための論理チャネルである。MCCHは、通常のMBMSにおいてeNodeB4からUE5へMBMS制御データを送信するために用いられるものである。
・MTCH(Multicast Traffic Channel:マルチキャストトラフィックチャネル):eNodeB4からUE5へのマルチキャストデータ(コンテンツ)を伝送するための論理チャネルである。MTCHは、通常のMBMS仕様ではマルチキャスト用のトランスポートチャネルであるMCH(Multicast Channel:マルチキャストチャネル)にマッピングされる。
【0042】
また、トランスポートチャネルと物理チャネルとの間のマッピング関係は以下の通りである。
・DLSCH及びPCH:PDSCH(Physical Downlink Shared Channel:物理下りシェアドチャネル)にマッピングされる。DLSCHは、HARQ、リンクアダプテーション、及び動的リソース割当(ユニキャスト特有の部分でもある)をサポートする。
・BCH:PBCH(Physical Broadcast Channel:物理ブロードキャストチャネル)にマッピングされる。
・MCH:PMCH(Physical Multicast Channel:物理マルチキャストチャネル)にマッピングされる。MCHは、複数のセルによるMBSFN伝送をサポートする。
【0043】
次に、
図6Bは、LTEシステムにおける上りリンクのチャネルマッピングを示す。
図6Aと同様に、論理チャネル(Downlink Logical Channel)、トランスポートチャネル(Downlink Transport Channel)及び物理チャネル(Downlink Physical Channel)相互間のマッピング関係を示している。以下、順に説明する。
【0044】
・CCCH(Common Control Channel:共通制御チャネル):UEとネットワーク間の制御情報を送信するために使用される論理チャネルであり、ネットワークと無線リソース制御(RRC:Radio Resource Control)接続を有していないUEによって使用される。
・DCCH(Dedicated Control Channel:専用制御チャネル):1対1(point-to-point)の双方向の論理チャネルであり、UEとネットワーク間で個別の制御情報を送信するために利用するチャネルである。専用制御チャネルDCCHは、RRC接続を有している移動局装置によって使用される。
・DTCH(Dedicated Traffic Channel:専用トラフィックチャネル):1対1の双方向論理チャネルであり、1つのUE置専用のチャネルであって、ユーザ情報(ユニキャストデータ)の転送のために利用される。
【0045】
・ULSCH(Uplink Shared Channel:上りリンク共用チャネル):HARQ)、動的適応無線リンク制御、間欠送信(DTX:Discontinuous Transmission)がサポートされるトランスポートチャネルである。
・RACHで(Random Access Channel:ランダムアクセスチャネル):制限された制御情報が送信されるトランスポートチャネルである。
【0046】
・PUCCH(Physical Uplink Control Channel:物理上りリンク制御チャネル):下りリンクデータに対する応答情報(ACK(Acknowledge)/NACK(Negative acknowledge))、下りリンクの無線品質情報、および、上りリンクデータの送信要求(スケジューリングリクエスト:Scheduling Request:SR)を基地局装置に通知するために使用される物理チャネルである。
・PUSCH(Physical Uplink Shared Channel:物理上りリンク共用チャネル):上りリンクデータを送信するために使用される物理チャネルである。
・PRACH(Physical Random Access Channel:物理ランダムアクセスチャネル):主に移動局装置から基地局装置への送信タイミング情報(送信タイミングコマンド)を取得するためのランダムアクセスプリアンブル送信に使用される物理チャネルである。ランダムアクセスプリアンブル送信はランダムアクセス手順の中で行なわれる。
【0047】
次に、チャネルマッピングについて説明する。
図6Bに示されるように、上りリンクでは、次のようにトランスポートチャネルと物理チャネルのマッピングが行われる。上りリンク共用チャネルULSCHは、物理上りリンク共用チャネルPUSCHにマッピングされる。ランダムアクセスチャネルRACHは、物理ランダムアクセスチャネルPRACHにマッピングされる。物理上りリンク制御チャネルPUCCHは、物理チャネル単独で使用される。また、共通制御チャネルCCCH、専用制御チャネルDCCH、専用トラフィックチャネルDTCHは、上りリンク共用チャネルULSCHにマッピングされる。
【0048】
次に、LTEシステムにおいては、UE5はeNodeB4に対してOFDM(Orthogonal Frequency-Division Multiplexing、直交周波数分割多重)アクセス(OFDMA)により無線接続する。OFDMA方式は、周波数分割多重と時間分割多重とを複合させた二次元の多重化アクセス方式として特徴づけられる。具体的には、直交する周波数軸と時間軸のチャネル(サブキャリア)を分割してUE5に割り振り、各サブキャリアの信号がゼロ(0点)になるように周波数軸上で直交するサブキャリアを分割する。サブキャリアを分割して周波数軸上に割り当てることにより、あるサブキャリアがフェージングの影響を受けても影響のない別のサブキャリアを選択することがでるので、ユーザは無線環境に応じてより良好なサブキャリアを使用でき、無線品質を維持できる利点が生ずる。
【0049】
そして、OFDMA方式においては、周波数軸と時間軸とが張る仮想平面上で定義されるリソースブロック(Resource Block:以下、RBともいう)が無線リソースとして採用される。RBは
図7に示すように、上記平面を180kHz/0.5msecでマトリックスに区切ったブロックとして定義され、各ブロックは周波数軸上では15kHz間隔で隣接する12個のサブキャリアを、時間軸上ではフレームの1スロット分(7シンボル)を含む。このRBは時間軸上で隣接する2つ(1msec)を1組としてUE5に割り当てられる。
【0050】
以下、
図1の同報配信システム1の通信処理の流れについて
図9~
図12の通信フロー図により説明する。まず、
図9において、UE5とコアネットワーク3(
図1)との間のアタッチシーケンスが実行される。TS1ではUE5からeNodeB4を経由してMME2に対し、アタッチ要求が出される。MME2はこれを受け、TS2にてS-GW6に対しベアラ設定要求を送信する。S-GW6はTS3にて、P-GW7との間にS5インターフェース上に物理回線のベアラ設定処理を実行する。ベアラが設定されればS-GW6はTS4にてMME2に、ベアラ設定応答を送信する。MME2はTS5にて、無線ベアラ設定要求(すなわち、アタッチ受入れ)をeNodeB4に通知する。これを受けたeNodeB4はTS6にて無線ベアラ設定要求(すなわち、アタッチ受入れ)をUE5に通知する。UE5は無線ベアラ(ユニキャストベアラ12(
図1))を設定し、TS7にて無線ベアラ設定応答をeNodeB4に返す。eNodeB4は、TS8にて無線ベアラ設定応答をMME2に通知する。以上の処理は、トランシーバモード及び防災無線モードのいずれにおいても共通に実施される。
【0051】
以下、トランシーバモードが選択されている場合の通信フローについて説明する(起点移動端末がUE(I)となる場合を例にとる)。まず、
図9のTS10において、UE5からP-GW7に対し、BMSCとの間のP2P制御コネクション確立が指示される。P-GW7はこれを受け、TS11にてBMSC8に対し、P2P制御コネクション設定要求を送信する。WebRTCサーバ17の仲介により、以下の手順でP2P制御コネクション設定がなされる。
(1)P-GW7(接続する側)にてSDPを作成し、自身に登録する。登録後、BMSC8(接続される側)にSDPを、WebRTCサーバ17を通じて送信する。BMSC8はこれを受け取り、SDPを登録する。
(2)同様に、BMSC8もSDPを発行し、自身にこれを登録後、WebRTCサーバ17を通じてP-GW7にSDPを送る。P-GW7は受け取ったSDPを登録する。
(3)以上の情報をもとに、P-GW7は自身に接続可能となりそうな接続経路の候補(ICE Candidate)をBMSC8に送る。BMSC8は受け取ったICE Candidateを登録する。同様にBMSC8もICE CandidateをP-GW7に送信する。P-GW7はこれを受け取って登録する。
【0052】
以上で制御コネクション設定は完了し、BMSCはTS12でP2P制御コネクション設定応答を返す。以降、P-GW7とBMSC8との間にP2P通信が成立する。トランシーバモードを立ち上げた直後は、UE(I)は
図15の左に示すスタンバイ状態となっており、PTT操作部109c1は操作されていない状態となるので、TS13にてUE(I)はeNodeB4にこれを通知する。これを受けたeNodeB4はTS14にて無線ベアラ切断要求をUE(I)に通知する。UE(I)は無線ベアラを切断し、TS15にて無線ベアラ切断応答をeNodeB4に返す。このとき、コアネットワーク3内に設定されているユニキャストの物理回線ベアラは設定維持された状態になっている。
【0053】
図10に進み、TS51にてUE(I)のPTT操作部109c1がオンになったことが検出されると、UE(I)はこれをeNodeB4に通知する。これを受けたeNodeB4はTS52にて無線ベアラ設定要求をUE(I)に通知する。UE(I)は無線ベアラ(ユニキャストベアラ12(
図1))を設定し、TS53にて無線ベアラ設定応答をeNodeB4に返す。これにより、UE(I)はマルチキャストグループ内の他のUE5(UE(II)、UE(III)、UE(IV))と交信が可能な状態となる。
【0054】
TS54~TS56では、UE(I)から入力された音声のストリームが上りユニキャストデータパケットとして、eNodeB4(無線ベアラ)→S-GW6(S1-U)→P-GW7(S5)の流れで送信される。
図8の上段に示すように、ユニキャストのデータパケット300のヘッダ300には、送信元IPアドレス301aとしてUE(I)のIPアドレス(11.11.15.105)が、送信先IPアドレス301bとしてマルチキャストグループのIPアドレス(239.255.0.1)が書き込まれている。BMSC8との間のPSP接続が確立されているP-GW7では、TS57において、WebRTC区間をトンネリングさせるために、データパケット300の全体をUDPカプセル化するパケット変換がなされる。具体的には、
図8の中段に示すように、UDPヘッダ301’と、新たなIPヘッダ301”が付加される。IPヘッダ301”には、送信元IPアドレス301” aとしてWebRTC区間の起点ノードとなるP-GW7のIPアドレス(197.191.0.11)が、送信先IPアドレス301” bとしてWebRTC区間の終点ノードとなるBMSC8のIPアドレス(224.0.0.22)が書き込まれる。P-GW7は、自身に登録された前述のICEが示す通信経路を参照し、次の送信先(ネクストホッピング)のIPアドレスがBMSC8となっていることにより、送信先IPアドレス301” bの書き込み内容を特定することができる。
【0055】
このようにしてカプセル化されたユニキャストパケットは、TS58にてWebRTC区間をトンネリングし、BMSC8に送られる。BMSC8では、TS59で、受信したユニキャストパケットのカプセル化解除処理を行なう。具体的には、
図8の下段に示すように、カプセル化に際して付加されたIPヘッダ301”を削除する処理となる。これにより、ユニキャストパケットは再び送信元IPアドレス301aがUE(I)(11.11.15.105)が、送信先IPアドレス301bがマルチキャストグループス(239.255.0.1)のパケットとして
図1のマルチキャスト側ブロックMBへ送出される。TS51~TS59の処理は、UE(I)にてPTT操作部109c1がオフになるまで繰り返し実行される。
【0056】
TS60にてPTT操作部109c1がオフになったことが検出されると、UE(I)はこれをeNodeB4に通知する。これを受けたeNodeB4はTS61にて無線ベアラ切断要求をUE(I)に通知する。UE(I)は無線ベアラを切断し、TS62にて無線ベアラ切断応答をeNodeB4に返す。これにより、UE(I)はスタンバイ状態に移行する。このときも、コアネットワーク3内に設定されているユニキャストの物理回線ベアラは設定維持された状態とされるが、例えば
図15にてトランシーバオフボタン109c2がタッチされ、トランシーバモードが解除されると、コアネットワーク3内に設定されているUE(I)との間の物理回線ベアラの設定も解除される。
【0057】
図11は、ユーザデータのマルチキャスト配信にかかる通信シーケンスを示すものである。UE5は、例えばユーザ端末アプリ105a(
図2)の実行によりマルチキャストグループへの参加を表明しておく。参加表明のあったUE5のIPアドレスは、MME2を経由してMBMS-GW9にてマルチキャストグループリスト8bに登録される。eNodeB4を立ち上げると、コントロールプレーン側の初期化処理として、該eNodeB4を上位装置であるMCE10とMME2とに起動済み基地局として認識させるために、M2インターフェース及びM3インターフェースを介して順次セットアップ要求及び応答の手続きが実施される(TS101~TS104)。また、BMSC8側からeNodeB4にマルチキャストデータの無線による信号伝送路であるマルチキャストベアラを構築するセッション開始要求/応答の手続きが、BMSC8/MBMS-GW9間(TS105、106)及びMBMS-GW9/MME2間(TS107、108)で同様に実施される。このセッション開始要求がマルチキャスト用無線ベアラ構築指示に相当する。
【0058】
続いて、MME2はMCE10にセッション開始要求を送信する(TS109)。これを受けたMCE10とeNodeB4間でもセッション開始要求/応答の手続きが実行される(TS110、TS111)。これにより、eNodeB4はコアネットワーク側からのマルチキャストデータ(コンテンツ)配信のためのセッション開始の準備が完了する。そして、MCE10は、種々のマルチキャストデータ(コンテンツ)配信要求を順次受けるに従い、その配信のスケジューリング(配信時刻及び配信エリア等)を行ない、そのスケジューリング情報をeNodeB4に送信する(TS112)。eNodeB4では該スケジューリング情報を受信し、応答をMCE10に返す(TS113)。MCE10はMME2にセッション開始の応答を返す(TS114)。eNodeB4は接続先となるUE5に対し、通常のLTEネットワークにおけるMBMSセッションでは、マルチキャストベアラの構築をUE5に指示するために、MCHによるマルチキャストベアラのRAN(無線)リソースセットアップを行なう。
【0059】
ユーザデータのパケットは、BMSC8/MBMS-GW9間ではSGimbインターフェースを経由して伝送され(TS115)、MBMS-GW9/eNodeB4間(
図1も参照)はM1インターフェースを経由して伝送される(TS116)。そして、eNodeB4/UE5間は無線ベアラであるマルチユニキャストベアラ12(
図1)を経由して伝送される(TS117
)。なお、起点移動端末となるUE(I)にもユーザデータのパケットはマルチユニキャストベアラ12により伝送されるが、音声送信中のUE(I)においては該ユーザデータのパケットは破棄する処理がなされる。
【0060】
WebRTCはトランスポート層のプロトコルとして簡便なUDPが採用され、P2P接続によるデータ通信は応答性やリアルタイム性は極めて良好となる。また、音声データ(ユーザデータ)の上りリンクの送信はユニキャストパケットによりなされるので、配信元ノード装置となるP-GW7に同報送信のための機能を搭載する必要がなく、PTT通信システムの大幅な簡略化を図ることができる。また、音声データ(ユーザデータ)は、BMSC8(マルチキャスト配信ノード装置)から先は無線リソースを効率的に活用するeMBMSによりマルチキャストパケットの形で各UE5に配信されるので、無線リソースの消費を最小限に抑えることができ、かつデータ配信の同時同報性も極めて良好に担保することができる。
【0061】
一方、防災無線モードでは、
図12に示すように、配信元ノード装置が防災無線サーバ18であり、ユーザデータとなる防災無線データのIPパケットの送信起点も防災無線サーバ18となる。PSP接続確立設定処理は防災無線サーバ18とBMSC8との間でなされる(TS201~203)。また、防災無線データのIPパケットは、WebRTC区間をトンネリング可能なカプセル化が最初からなされた形で発行され、TS204でBMSC8に送信されたのち、BMSC8ではTS205でカプセル化解除処理がなされ、その後、各UE5にマルチキャスト配信される流れとなる。
【0062】
以上、本発明の実施の形態について説明したが、あくまで例示であって、本発明はこれに限定されるものではない。
【符号の説明】
【0063】
1 同報配信システム
2 MME
3 コアネットワーク
4 eNodeB
5 UE
6 S-GW
7 P-GW
8 BMSC
9 MBMS-GW
10 MCE
11 マルチキャストベアラ
12 ユニキャストベアラ
15 インターネット
17 WebRTCサーバ
18 防災無線サーバ
100 マイクロプロセッサ
101 CPU
102 RAM
103 ROM
104 入出力部
105 フラッシュメモリ
107 マイク
1071 A/D変換部
108 スピーカ
1081 D/A変換部
1082 アンプ
109 モニタ
109a メニュー選択画面
109a1、109a2 モード選択ボタン
109b チャネル設定画面
109cs スタンバイ画面
109ct 送信中画面
109cr 受信画面
109c1 PTT操作部
109e 防災無線画面
1091 グラフィックコントローラ
110 タッチパネル
111 カメラ
112 無線通信部