(57)【要約】リモートUE（３００）は、当該リモートUE（３００）をMCPTTサーバ（１００）にユーザ登録するための第１シグナリングを送信し、MCPTTサーバ（１００）は、第１シグナリングを送信したリモートUE（３００）と、当該リモートUE（３００）が接続しているリレーUE（２００）との接続関係を検出し、発言権が与えられたUEから音声データを受信した場合、接続関係を有するリレーUE（２００）及びリモートUE（３００）のうち何れか１つのUEのみを音声データの送信先UEに決定し、送信先UE用のユニキャストベアラを用いて、音声データを送信し、リレーUE（２００）は、MCPTTサーバ（１００）から送信される音声データを、当該リレーUE（２００）に接続された全てのリモートUE（３００）へ送信する。
2017051503.tif 000002
【特許請求の範囲】
【請求項１】
複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムであって、
前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、
前記リモート端末は、
当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、
前記通信ノードは、
前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、
前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、
前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、
前記リレー端末は、
前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する、
通信システム。
【請求項２】
前記リモート端末が送信する前記第１のシグナリングには、当該リモート端末が接続するリレー端末の情報が含まれ、
前記通信ノードは、前記リレー端末の情報を用いて前記接続関係を検出する、
請求項１に記載の通信システム。
【請求項３】
前記リレー端末は、前記リモート端末から送信される前記第１のシグナリングに、当該リレー端末の情報を含め、
前記通信ノードは、前記リレー端末の情報を用いて前記接続関係を検出する、
請求項１に記載の通信システム。
【請求項４】
前記第１のシグナリングは、ＳＩＰ（Session Initiation Protocol）シグナリングであって、
前記リレー端末の情報は、viaヘッダ又はＳＤＰ（Session Description Protocol）の中に含まれる、
請求項２又は３に記載の通信システム。
【請求項５】
前記リモート端末は、前記通信ノードへの登録後に、通信を開始するための第２のシグナリングを送信し、
前記通信ノードは、前記接続関係に基づいて、前記第２のシグナリングを送信した前記リモート端末へ前記音声データを送信するためのユニキャストベアラを確立する必要があるか否かを判断し、確立が必要と判断した場合、前記ユニキャストベアラの確立を要求する、
請求項１に記載の通信システム。
【請求項６】
前記送信先端末は、前記リレー端末である、
請求項１に記載の通信システム。
【請求項７】
前記送信先端末は、１つのリモート端末であって、
前記リレー端末は、前記１つのリモート端末宛ての前記音声データをインターセプトし、前記インターセプトした音声データを前記全てのリモート端末へ送信する、
請求項１に記載の通信システム。
【請求項８】
前記リレー端末は、前記音声データを前記全てのリモート端末が受信できるように、当該音声データのヘッダ情報を変更する、
請求項１に記載の通信システム。
【請求項９】
前記リモート端末は、前記リレー端末から送信される前記音声データが自機から送信されたデータである場合、当該音声データを破棄する、
請求項１に記載の通信システム。
【請求項１０】
複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおけるリレー端末であって、
前記音声データの送信先端末用のユニキャストベアラを用いて、前記通信ノードから送信される前記音声データを受信し、前記送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリモート端末のうち何れか１つの端末であり、前記リモート端末は前記リレー端末を介して前記通信ノードと通信する、受信部と、
前記受信された前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する送信部と、
を具備するリレー端末。
【請求項１１】
複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける、リレー端末を介して前記通信ノードと通信するリモート端末であって、
当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信する送信部と、
前記リレー端末から送信される前記音声データを受信し、前記通信ノードから送信される前記音声データの送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリレー端末のうち何れか１つの端末であり、前記音声データは、前記送信先端末用のユニキャストベアラを用いて前記通信ノードから前記リレー端末へ送信される、受信部と、
を具備するリモート端末。
【請求項１２】
複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける通信制御方法であって、
前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、
前記リモート端末において、
当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、
前記通信ノードにおいて、
前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、
前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、
前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、
前記リレー端末において、
前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する、
通信制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信システム、リレー端末、リモート端末及び通信制御方法に関する。
【背景技術】
【０００２】
現在、３ＧＰＰ（3rd Generation Partnership Project）において、MCPTT（Mission Critical Push To Talk）の標準化が進められている。【０００３】
非特許文献１には、MCPTTのサービス及びシステムの詳細を策定する上での要求条件が記載されている。非特許文献１によると、MCPTTのサービスとしては、on-networkサービス、off-networkサービス、又は、on-networkサービス及びoff-networkサービスの両方を使用したサービスが考えられている。【０００４】
on-networkサービスは、LTE（Long Term Evolution）の無線アクセスネットワーク（eUTRAN：evolved Evolved Universal Terrestrial Radio Access Network）とコア網（EPC: Evolved Packet Core）とから成るEPS（Evolved Packet System）を利用して通信を行う、GCSE_LTE（Group Communication System Enablers for LTE：例えば、非特許文献２及び非特許文献３を参照）を使用したサービスである。非特許文献２及び非特許文献３によると、GCSE_LTEを用いた通信では、MCPTT等のグループサービスに参加している各端末（UE:User Equipment）に対して、非特許文献１０又は非特許文献１１に記載のEPSベアラを用いたユニキャスト通信を行ってもよく、非特許文献１２に記載のMBMS（Multimedia Broadcast and Multicast Service）ベアラを用いたMBMS通信を行ってもよい。【０００５】
また、off-networkサービスは、端末間直接通信であるProSe（Proximity Services：例えば、非特許文献４、非特許文献５、非特許文献６、非特許文献７を参照）を使用したサービスである。Prose通信は、サイドリンク（Sidelink）通信と呼ばれることもある。【０００６】
On-networkサービス及びoff-networkサービスの両方を使用したサービスとして、例えば、非特許文献１，非特許文献６，非特許文献９などに記載されているUE-to-Networkリレー（relay）を使用したサービスがある。UE-to-Networkリレーを使用したサービスとは、基地局（eNB：eNode B）のカバレッジ（coverage）内に存在するUEが、eNBのカバレッジ外に存在するUE（リモート（remote）UE）とEPCとの通信を中継するリレー（relay）UEとして機能するサービスである。このサービスでは、リレーUEとリモートUEとの間ではProSe通信を用いたoff-networkサービスが行われ、リレーUEとEPCとの間ではGCSE_LTEを用いたon-networkサービスが行われる。【０００７】
また、非特許文献１によると、MCPTTサービス提供を受けるユーザのUEは、MCPTTサービスのグループに所属する。UEが所属するグループは同時に複数であってもよい。【０００８】
MCPTTサービスでは、発言権制御（Floor Control）をサポートする事が要求されており、グループ内で発言権（Floor grant）を与えられたユーザのみが発言することが許される。また、この発言権が与えられる時間に制限をつけてもよい。また、緊急事態発生時などには、優先割込み（Pre-emption）を許可する事が要求されている。優先割込みが発生した場合には、現行のMCPTTサービスは一時中断され、発言権を優先割込みに譲る。非特許文献８及び非特許文献９には、MCPTTサービスグループへの登録、発言権制御、ネットワークへのリソース割当などを含むMCPTTサービスのアーキテクチャ（architecture）及びシグナリング（signaling）の例が開示されている。【０００９】
図１は、非特許文献１，非特許文献６，非特許文献９などより考えられる、UE-to-Networkリレーを用いたMCPTTサービスのアーキテクチャ（architecture）及び音声データ（音声パケット）の通る経路の一例を示している。【００１０】
図１に示すMCPTTサーバ（MCPTT Server）は、MCPTTサービスに参加するユーザの登録又はMCPTTセッションの制御を行うSIP（Session Initiation Protocol）サーバ、発言権制御を行う発言権制御サーバ（Floor Control Server）、発言者からの音声データを一旦終端し、MCPTTサービス参加者に転送するメディア配布機能（Media Distribution Function），非特許文献６に記載のProSe機能などを有する。これらのサーバ及び機能は別の名称を持つ他のノードに分散して存在する可能性もあるが、本開示では図の簡略化のため、MCPTTサーバの機能の一部として存在すると仮定する。【００１１】
図１において、UE1，UE2，UE3，UE4，UE5は同一のMCPTTサービスに参加しているUEであり、UE1及びUE2はeNBのカバレッジ内に存在しており、UE3，UE4，UE5はeNBのカバレッジ外に存在している。また、UE2はリレーUEとしての機能を有し、UE3，UE4，UE5はリモートUEとしてUE2を介してMCPTTサービスに参加している。図１に示す例では、現在、UE1が発言権（Floor Grant）を与えられて発言し、UE2〜UE5がUE1の発言（音声パケット）を受信している。【００１２】
また、リレーUE（UE2）にリモートUE（UE3，UE4，UE5）が接続する際、非特許文献６及び非特許文献９などに記載された以下の手順が用いられる。【００１３】
１．リレーUEはリモートUEにIPアドレスを割り当てる。IPアドレスがIPv4の場合、リレーUEは、リモートUEに対してNAT（Network Address Translation）の機能を有する。【００１４】
２．リモートUEはリレーUE経由でSIPサーバに対してユーザ登録（registration）を行う。【００１５】
３．リモートUEはSIPサーバにSIP呼制御シグナリングであるINVITEを送り、MCPTTの通信を開始する。
【先行技術文献】
【非特許文献】
【００１６】
【非特許文献１】3GPP TS 22.179 v13.2.0、 “Mission Critical Push to Talk (MCPTT) over LTE; Stage 1”
【非特許文献２】3GPP TS 22.468 v13.0.0、 “Group Communication System Enablers for LTE (GCSE_LTE)”
【非特許文献３】3GPP TS 23.468 v13.1.0、 “Group Communication System Enablers for LTE (GCSE_LTE); Stage 2”
【非特許文献４】3GPP TS 22.278 v13.2.0、 “Service requirements for the Evolved Packet System (EPS)”
【非特許文献５】3GPP TR 23.713 v1.5.0、 “Study on extended architecture support for proximity services”
【非特許文献６】3GPP TS 23.303 v13.0.0、 “Proximity-based services (ProSe); Stage 2”
【非特許文献７】3GPP TR 36.321 v12.6.0、 “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification”
【非特許文献８】3GPP TR 23.779 v1.1.0、 “Study on application architecture to support Mission Critical Push To Talk over LTE (MCPTT) services”
【非特許文献９】3GPP TS 23.179 v0.3.0、 “Functional architecture and information flows to support mission critical communication services; Stage 2”
【非特許文献１０】3GPP TS 23.401 v13.3.0、 “General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access”
【非特許文献１１】3GPP TS 36.300 v13.0.0、 “Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2”
【非特許文献１２】3GPP TS 23.246 v13.1.0、 “Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description”
【非特許文献１３】3GPP S2-151810，“LS reply on ProSe Priorities”
【発明の概要】
【００１７】
図１に示す例では、リモートUEであるUE3〜UE5の各々は、独立してMCPTTサーバにユーザ登録を行い、独立してMCPTT通信を開始している。
【００１８】
また、非特許文献６によると、リレーUEは、EPCからのユニキャスト通信のパケットのみをリモートUEに対して転送（relay）し、MBMS通信のパケットを転送しない。すなわち、各リモートUEはリレーUE経由でEPCとの間にEPSベアラを確立し、ユニキャスト通信を行う必要がある。
【００１９】
したがって、図１に示す例では、MCPTTサーバは、UE1がMCPTTサーバに送信した音声パケットを、UE3，UE4，UE5それぞれに対して複製し、UE3，UE4，UE5それぞれのIP/UDPヘッダを付加して送信する。また、図１においてリレーUEであるUE2は、ProSe通信を用いて、UE3，UE4，UE5それぞれに送られたパケットをUE3，UE4，UE5に送信する。
【００２０】
しかしながら、非特許文献６、非特許文献７、非特許文献１１によると、ProSe通信では、同一のグループID（ProSe Layer-2 Group ID）が割り当てられているUEに対して同報配信（broadcast）が行われる。すなわち、同じMCPTTサービスに参加しているUE3，UE4，UE5に同一のグループIDが割り当てられていた場合、UE3，UE4，UE5の各々に送られるパケットが、UE3，UE4，UE5の全てに配信されることになる。
【００２１】
通常、同報配信を用いて送られたパケットをUEが受信した場合、UE側で自機宛のパケットか否かを確認し、自機宛では無い場合にはそのパケットを破棄するという処理を行う。しかし、音声パケットに対して、例えば3GPPの音声コーデックである、AMR（Adaptive MultiRate）又はAMR-WB（AMR-WideBand）などが用いられる場合、通常、20msec毎にパケットが発生するため、UEがパケットの宛先を確認し、不要なパケットを破棄する頻度は高くなってしまう。また、同一のグループIDが割り当てられたリモートUEの数が大きいほど、リモートUEが確認・破棄するパケット数は増加し、リモートUEの処理負荷が増加する。また、リレーUEからリモートUEへ不要なパケットを多く送信することにより、無線リソースを無駄に消費することにもなる。
【００２２】
本開示の一態様は、リレーUEの処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる通信システム、リレー端末、リモート端末及び通信制御方法を提供することである。
【００２３】
本開示の一態様に係る通信システムは、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムであって、前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、前記リモート端末は、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、前記通信ノードは、前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、前記リレー端末は、前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する。
【００２４】
本開示の一態様に係るリレー端末は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおけるリレー端末であって、前記音声データの送信先端末用のユニキャストベアラを用いて、前記通信ノードから送信される前記音声データを受信し、前記送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリモート端末のうち何れか１つの端末であり、前記リモート端末は前記リレー端末を介して前記通信ノードと通信する、受信部と、前記受信された前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する送信部と、を具備する構成を採る。
【００２５】
本開示の一態様に係るリモート端末は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける、リレー端末を介して前記通信ノードと通信するリモート端末であって、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信する送信部と、前記リレー端末から送信される前記音声データを受信し、前記通信ノードから送信される前記音声データの送信先端末は、前記発言権が与えられた端末から音声データを受信した場合に前記通信ノードにおいて決定され、前記リレー端末、及び、当該リレー端末に接続しているリレー端末のうち何れか１つの端末であり、前記音声データは、前記送信先端末用のユニキャストベアラを用いて前記通信ノードから前記リレー端末へ送信される、受信部と、を具備する構成を採る。
【００２６】
本開示の一態様に係る通信制御方法は、複数の端末のうち、発言権が与えられた端末が音声データを通信ノードに送信し、他の端末が前記通信ノードから当該音声データを受信する通信システムにおける通信制御方法であって、前記複数の端末は、リレー端末、及び、前記リレー端末を介して前記通信ノードと通信するリモート端末を含み、前記リモート端末において、当該リモート端末を前記通信ノードにユーザ登録するための第１のシグナリングを送信し、前記通信ノードにおいて、前記第１のシグナリングを送信したリモート端末と、当該リモート端末が接続しているリレー端末との接続関係を検出し、前記発言権が与えられた端末から音声データを受信した場合、前記接続関係を有する前記リレー端末及び前記リモート端末のうち何れか１つの端末のみを前記音声データの送信先端末に決定し、前記送信先端末用のユニキャストベアラを用いて、前記音声データを送信し、前記リレー端末において、前記通信ノードから送信される前記音声データを、当該リレー端末に接続された全てのリモート端末へ送信する。
【００２７】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【００２８】
本開示の一態様によれば、リレーUEの処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる。
【００２９】
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【００３０】
【図１】図１は、実施の形態１に係る通信システムの構成例を示す図である。
【図２】図２は、実施の形態１に係るMCPTTサーバの構成例を示す図である。
【図３】図３は、実施の形態１に係るリレーUEの構成例を示す図である。
【図４】図４は、実施の形態１に係るリモートUEの構成例を示す図である。
【図５】図５は、実施の形態１に係るリモートUEの登録処理時の動作をシーケンスチャートにより示す図である。
【図６】図６は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース１）により示す図である。
【図７】図７は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース２）により示す図である。
【図８】図８は、実施の形態１に係る音声通信時の動作をシーケンスチャート（ケース３）により示す図である。
【図９】図９は、実施の形態２に係る音声通信時の動作をシーケンスチャートにより示す図である。
【図１０】図１０は、sidelink用MACサブヘッダの一例を示す図である。
【発明を実施するための形態】
【００３１】
以下、本開示の各実施の形態について、図面を参照して詳細に説明する。なお、本開示の各実施の形態について、パケットの送信元・送信先を「ユニキャストIPアドレス」、「ブロードキャストIPアドレス/マルチキャストアドレス/ ProSe Group IP multicast address」などと特に明記していない場合には、ユニキャストIPアドレスを意味する。
【００３２】
（実施の形態１）
本実施の形態に係る通信システムは、図１に示す構成を採る。本実施の形態に係る通信システムは、少なくとも、MCPTTサーバ１００（通信ノードに相当）、リレーUE２００、リモートUE３００を備える。
【００３３】
また、図１に示すPDN GW（Packet Data Network GateWay）４００、及び、Serving GW）は、非特許文献１０に記載されたノードであり、１対１配信の場合に音声データが通る経路である。また、eNBは、非特許文献１０などに記載されたノードであり、EPSにおける基地局である。
【００３４】
図１では、eNBのカバレッジ内に存在するUE2がリレーUE２００に対応し、eNBのカバレッジ外に存在するUE3〜UE5がリモートUE３００に対応する。
【００３５】
また、前述した通り、図１に示すMCPTTサーバ１００は、MCPTTサービスに参加するUEの登録又はMCPTTセッションの制御を行うSIPサーバ、発言権制御を行う発言権制御サーバ、MCPTTサービスの参加者にデータを転送するメディア配布機能，非特許文献６に記載のProSe機能などを有すると仮定するが、実際には、これらのサーバ及び機能は、別々の名称を有するノード又は機能に分散して存在することも可能である。
【００３６】
［各装置の構成］
図２〜図４は、それぞれ、図１に示すMCPTTサーバ１００、リレーUE２００、リモートUE３００の構成例を示すブロック図である。なお、MCPTTサーバ１００、リレーUE２００、リモートUE３００には、図２〜図４に示す構成以外にも非特許文献１〜１１に記載されているような機能を有するが、ここではその説明を省略する。
【００３７】
図２に示すMCPTTサーバ１００は、受信部１０１、検出部１０２、格納部１０３、判断部１０４、パケット生成部１０５、及び送信部１０６を含む。
【００３８】
MCPTTサーバ１００において、受信部１０１は、UEのSIPサーバへのユーザ登録時にUEから送信されるSIPシグナリングを受信し、MCPTTサービスの通信開始時にはUEから送信されるSIP INVITEシグナリングを受信する。また、受信部１０１は、音声通信時には、発言権（Floor grant）が与えられたUE（図１ではUE1）から送信された音声パケットを受信する。
【００３９】
検出部１０２は、受信部１０１から受け取るユーザ登録時のSIPシグナリング、又は、既に登録されているUEの情報を用いて、MCPTTサービスにおいて同一グループサービスに参加しているリレーUE２００とリモートUE300との関係（接続関係）を検出する。格納部１０３は、検出部１０２で検出された上記関係を格納する。
【００４０】
判断部１０４は、リモートUE３００からの通信開始時に、当該リモートUE３００用のベアラ確立の要否を判断する。また、判断部１０４は、MCPTTサービスにおける音声通信時に、格納部１０３に格納された情報（リレーUE２００とリモートUE300との関係）に基づいて、音声パケットの送信先UEを決定する。例えば、判断部１０４は、格納部１０３に格納された接続関係を有するリレーUE２００（図１ではUE2）及びリモートUE３００（図１ではUE3〜UE5）のうち何れか１つのUEのみを音声データの送信先UEに決定する。
【００４１】
パケット生成部１０５は、判断部１０４での判断結果（送信先UEの決定）に基づいてパケットを生成し、送信部１０６は、パケット生成部１０５で生成されたパケットを送信する。
【００４２】
図３に示すリレーUE２００は、受信部２０１、パケット生成部２０２及び送信部２０３を含む。
【００４３】
リレーUE２００において、受信部２０１は、リモートUE３００から送信される信号、又は、MCPTTサーバ１００から送信される信号を受信する。
【００４４】
パケット生成部２０２は、受信部２０１から受け取る信号を用いてパケットを生成する。例えば、パケット生成部２０２は、MCPTTサーバ１００から送信される音声パケットを、リレーUE２００に接続された全てのリモートUE３００が受信できるように、当該音声パケットのヘッダ情報を変更して、リモートUE３００宛のパケットを生成してもよい。
【００４５】
送信部２０３は、パケット生成部２０２で生成されたパケットを送信する。
【００４６】
図４に示すリモートUE３００は、受信部３０１、判断部３０２、処理部３０３、及び送信部３０４を含む。
【００４７】
リモートUE３００において、受信部３０１は、ユーザ登録時又は通信開始時のSIPシグナリング、又は、通信時の音声パケットを受信する。
【００４８】
判断部３０２は、受信部３０１から受け取る音声パケットが自機宛てであるか否かを判断する。例えば、判断部３０２は、リレーUE２００から送信される音声パケットが自機から送信された音声パケットである場合には、音声パケットが自機宛てではないと判断する。
【００４９】
処理部３０３は、自機宛ての音声パケットに対して処理（例えば、上位レイヤ処理部（図示せず）へのデータの受け渡しなど）を行う。一方、処理部３０３は、自機宛てではない音声パケット（例えば、自機が送信した音声パケット）を破棄する。
【００５０】
送信部３０４は、ユーザ登録時又は通信開始時のSIPシグナリング、又は、発言権が付与された時の音声パケットを送信する。
【００５１】
以上の構成を有する通信システムにおける動作について詳細に説明する。
【００５２】
［リモートUEの登録処理］
図２及び図５を用いて、リモートUE３００の登録処理（registration）時の各装置の動作について説明する。
【００５３】
図５は、本実施の形態に係るリモートUE３００の登録処理時の動作の一例を示すシーケンスチャートである。なお、図５において、例えば、リモートUE３００は、図１に示すUE3〜UE5であり、リレーUE２００は、図１に示すUE2である。
【００５４】
図５において、リモートUE３００は、非特許文献９等に記載の通り、リレーUE２００に接続する（ステップ（以下、「ＳＴ」と表す）１０１）。リモートUE３００がリレーUE２００に接続すると、リモートUE３００には、リレーUE２００からIPアドレス（又はIPアドレスのプレフィックス）が割り当てられる。リモートUE３００は、割り当てられたIPアドレス（又は割り当てられたIPアドレスのプレフィックスから生成されたIPアドレス）を用いて、MCPTTサーバ１００に対してSIPシグナリングを用いた登録処理を行う（ＳＴ１０２）。
【００５５】
登録処理を行う際、リモートUE３００は、接続しているリレーUE２００の情報を、登録処理のSIPシグナリングに明示的に含めてもよい。例えば、リモートUE３００は、接続しているリレーUE２００の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDP（Session Description Protocol）の中に含めてもよい。また、リモートUE３００は、前述のグループID又は、非特許文献６に記載された、グループIDと共に割り当てられるProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに含める事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
【００５６】
なお、登録処理のSIPシグナリングに対して、リレーUE２００によってパラメータの変更又は追加が行われてもよい。この場合、前述のようにリモートUE３００において、接続しているリレーUE２００の情報を、登録処理のSIPシグナリングに明示的に含めるのではなく、リレーUE２００が自機の情報を登録処理のSIPシグナリングに明示的に含める。例えば、リレーUE２００は、自機の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDPの中に含めてもよい。また、リレーUE２００は、前述のグループID又は、ProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに追加する事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
【００５７】
また、登録処理のSIPシグナリングは、リモートUE３００からMCPTTサーバ１００へ直接送信される場合に限定されない。例えば、リモートUE３００からリレーUE２００に登録処理のSIPシグナリングが送信され、リレーUE２００で一旦終端されてから、リレーUE２００がリモートUE用の登録処理のSIPシグナリングを新たに生成し、MCPTTサーバ１００に送信してもよい。この場合、前述のようにリモートUE３００が接続しているリレーUE２００の情報をリモートUE３００が生成する登録処理のSIPシグナリングに明示的に含めるのではなく、リレーUE２００が自機の情報を、リモートUE用の登録処理のSIPシグナリングに明示的に含めてもよい。例えば、リレーUE２００は、自機の情報を、SIPヘッダの一部、例えばviaヘッダなどに含めてもよく、SDPの中に含めてもよい。また、リレーUE２００は、前述のグループID又は、非特許文献６に記載されたProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方をSIPシグナリングに追加する事により、リモートUE３００とリレーUE２００の関係をSIPサーバに伝えても良い。
【００５８】
MCPTTサーバ１００において、受信部１０１が登録処理のSIPシグナリングを受け取ると、検出部１０２は、当該SIPシグナリングを送信したリモートUE３００と、そのリモートUE３００が接続しているリレーUE２００との関係（接続関係）を検出する（ＳＴ１０３）。リレーUE２００とリモートUE３００との関係の検出方法としては、例えば、SIPシグナリングに含まれるリレーUE２００の情報を用いてもよく、既に登録されている他のリモートUE３００とのIPアドレスの比較を用いてもよい。IPアドレスの比較を用いる場合、検出部１０２は、IPアドレス（IPv4の場合）又はIPアドレスのプリフィックス（IPv6の場合）を比較することにより、リレーUE２００とリモートUE３００との関係を検出してもよい。また、SIPヘッダのviaヘッダなどにリレーUE２００の情報が含まれている場合でも、MCPTTサーバ１００は、既に登録されているリレーUE２００の情報を照会し、viaヘッダに含まれている情報が本当にリレーUE２００の情報であるか否かを確認してもよい。またSIPシグナリングにグループID又は、ProSe Group IP multicast address、又はグループID及びProSe Group IP multicast addressの両方が含まれている場合には、MCPTTサーバ１００は、この情報を用いてリモートUE３００と、そのリモートUE３００が接続しているリレーUE２００との関係（接続関係）を検出しても良い。
【００５９】
例えば、図１に示す例では、リモートUE３００であるUE3〜UE5がユーザ登録を行った場合には、MCPTTサーバ１００の検出部１０２は、UE2がリレーUE２００であり、UE3，UE4，UE5がUE2に接続されたリモートUE３００であるという関係を検出する。
【００６０】
MCPTTサーバ１００の格納部１０３は、ＳＴ１０３において検出部１０２が検出した、リレーUE２００とリモートUE３００との関係を示す情報を格納する（ＳＴ１０４）。格納部１０３は、SIPシグナリングにグループIDやProSe Group IP multicast addressが含まれている場合には、このグループIDやProSe Group IP multicast addressの情報も格納する。
【００６１】
次いで、リモートUE３００は、非特許文献９等に記載の通り、MCPTTサービスの通信開始処理を行う（ＳＴ１０５）。例えば、リモートUE３００は、SIP INVITEシグナリングをMCPTTサーバ１００に送信する。
【００６２】
この際、MCPTTサーバ１００の判断部１０４は、SIP INVITEシグナリングを送信したリモートUE３００用のベアラ（ユニキャストベアラ）を確立（又は更新）する必要があるか否かを判断する（ＳＴ１０６）。そして、判断部１０４は、ベアラ確立（又は更新）が必要な場合、非特許文献１０等に記載の通り、PCRF（Policy and Charging Rules Function。図示せず）などを通じて、PDN GW４００に対してリモートUE３００用のベアラ確立（又は更新）を要求する（ＳＴ１０７）。PDN GW４００は、リモートUE３００用のベアラ確立の要求を受け取ると、リモートUE３００用のEPCベアラを確立（更新）する（ＳＴ１０８）。
【００６３】
例えば、判断部１０４は、格納部１０３に格納された情報（リレーUE２００とリモートUE３００との関係）に基づいて、既存ベアラの更新又はベアラの新規確立の際に必要となる情報（例えば、非特許文献１０等に記載のTFT（Traffic Flow Template）など）の設定の有無を判断する。判断部１０４は、この判断の際に他の情報、例えばMCPTTサーバ１００などにプリセットされたオペレータのポリシーなどの情報を用いてもよい。
【００６４】
具体的には、判断部１０４は、リレーUE２００用の音声パケット用EPSベアラが既に存在している場合に、このEPSベアラにリモートUE３００用TFTを追加してもよい。この場合、判断部１０４は、上り（UEからPDN GW４００への方向）のTFT（UL TFT）を追加する。一方、判断部１０４は、下り（PDN GW４００からUEへの方向）に関しては、当該リモートUE３００宛てのパケットを送る場合にのみ下りのTFT（DL TFT）を追加し、当該リモートUE３００宛てのパケットを送らない場合には下りのTFTを追加しないと判断してもよい。また、判断部１０４は、下りのTFTを追加する際、TFTの送信先IPアドレスとして、リモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
【００６５】
また、判断部１０４は、リレーUE２００用の音声パケット用EPSベアラが既に存在している場合に、リモートUE３００用の音声パケット用EPSベアラを新たに確立してもよい。この場合、判断部１０４は、上りのTFTを設定する。一方、判断部１０４は、下りに関しては、当該リモートUE３００宛てのパケットを送る場合にのみ下りのTFTを設定し、当該リモートUE３００宛てのパケットを送らない場合には下りのTFTを設定しないと判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リレーUE２００又はリモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
【００６６】
また、判断部１０４は、リレーUE２００が音声パケットをMBMSで受信しており、音声パケットのユニキャスト受信用（下り用）のEPSベアラが確立されていない場合（又はTFTが設定されていない場合）には、リレーUE２００用に下りのEPSベアラも同時に確立する（又はTFTを設定する）とともに、前述のように、リモートUE３００用TFTの追加を行うと判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リレーUE２００又はリモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
【００６７】
また、判断部１０４は、リレーUE２００が音声パケットをMBMSで受信しており、音声パケットのユニキャスト受信用（下り用）のEPSベアラが確立されていない場合（又はTFTが設定されていない場合）には、リレーUE２００用に下りのEPSベアラを確立（又はTFTを設定）せずに、前述のように、リモートUE３００用ベアラを確立すると判断してもよい。また、判断部１０４は、下りのTFTを設定する際、TFTの送信先IPアドレスとして、リモートUE３００のユニキャストIPアドレスを用いても良いし、ProSe Group IP multicast addressを用いてもよい。
【００６８】
なお、このEPSベアラ確立処理は、登録処理の後に行われてもよい。登録処理の後に行われるベアラ確立は、例えば、SIPシグナリング用ベアラ確立である。
【００６９】
［音声パケット通信処理］
次に、図５で説明した、登録処理、通信開始処理、ベアラ確立処理の完了後における音声パケットの通信処理について説明する。
【００７０】
［ケース１：リレーUE２００及びリモートUE３００以外のUEからの音声パケット］
まず、図２〜図４、図６を用いて、図１のように、リレーUE２００（UE2）及びリモートUE３００（UE3〜UE5）以外のUE（UE1）がMCPTTサーバ１００から発言権（Floor Grant）を与えられて、発言を開始した場合の処理について説明する。
【００７１】
図６は、ケース１に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
【００７２】
図６において、MCPTTサーバ１００の受信部１０１は、上りの音声パケット（発言権を与えられたUE（図１ではUE1）から送信される音声パケット）を受け取る（ＳＴ２０１）。上りの音声パケットを受け取ると、MCPTTサーバ１００の判断部１０４は、格納部１０３に格納された情報（リレーUE２００とリモートUE３００との関係）に基づいて、この音声パケットの送信先としてどのUEに送信するかを判断する（ＳＴ２０２）。具体的には、判断部１０４は、格納部１０３に格納された上記関係におけるリレーUE２００及びリモートUE３００のうち何れか１つのUEのみを音声データの送信先UEに決定する。判断部１０４は、この判断の際、他の情報、例えばMCPTTサーバ１００などにプリセットされたオペレータのポリシーなどの情報なども一緒に用いてもよい。
【００７３】
具体的には、判断部１０４は、図１に示すUE3〜UE5のように、リレーUE２００（UE2）配下のリモートUE３００にはパケットを送信せず、代わりにリモートUE３００が接続しているリレーUE２００（UE2）にパケットを送信すると判断する。または、判断部１０４は、リレーUE２００に接続して同一のMCPTTサービスを受けているリモートUE３００のうちの１つのUEにパケットを送信すると判断してもよい。つまり、判断部１０４は、リレーUE２００及びリモートUE３００を含む複数のUEに対して、複数のUEの各々を送信先とせずに、リレーUE２００又は１つのリモートUE３００のみを送信先UEに決定する。
【００７４】
また、判断部１０４は、リレーUE２００及びリモートUE３００、又はリモートUE３００のみに割り当てられている、ProSe Group IP multicast address宛にパケットを送信すると判断してもよい。また、ＳＴ２０２では、判断部１０４は、図５において確立されたEPSベアラの内容と合致するように、送信先UE（宛先）を判断する。例えば、判断部１０４は、図５のＳＴ１０６において設定した下りのTFTの送信先IPアドレス（例えば、リレーUE２００又はリモートUE３００のユニキャストIPアドレス、又は、ProSe Group IP multicast address）を用いて、パケットの送信先UEを決定する。
【００７５】
MCPTTサーバ１００のパケット生成部１０５は、判断部１０４の判断結果に基づいて、下りパケットを生成する（ＳＴ２０３）。すなわち、パケット生成部１０５は、判断部１０４において決定された送信先UEを宛先とするヘッダ情報又はProSe Group IP multicast addressを宛先とするヘッダ情報を付加した音声パケットを生成する。生成されたパケット（下り）は、送信部１０６を介して送信先のUE（図６ではリレーUE２００。図１ではUE2）へ送信される（ＳＴ２０４）。送信されるパケットは、図５において確立又は更新されたEPSベアラ（ユニキャスト）を用いて送信される。
【００７６】
リレーUE２００の受信部２０１は、MCPTTサーバ１００から送信された音声パケットを受信する（ＳＴ２０４）。または、リレーUE２００は、音声パケットの宛先がリモートUE３００宛ての場合でも、当該音声パケットをインターセプト（intercept）する。リレーUE２００は、受信した信号が音声パケットであるか否かに関して、EPSベアラのQCI（QoS Class Identifier。非特許文献１０などに記載）などで判断する。そして、リレーUE２００の受信部２０１は、受信した音声パケット又はインターセプトした音声パケットの宛先がリレーUE２００又はリモートUE３００のユニキャストIPアドレス宛であった場合、この音声を、パケット生成部２０２に出力する。また、受信部２０１は、受信した音声パケットの宛先がProSe Group IP multicast addressであった場合には音声パケットをパケット生成部２０２には出力せず、送信部２０３を介して送信する。
【００７７】
パケット生成部２０２は、同一のグループIDが割り当てられた全てのリモートUE３００が音声パケットを自機（各リモートUE３００）宛として受信できるように、受信部２０１から受け取った音声パケットのヘッダ情報を変更して、リモートUE３００用のパケットを生成する（ＳＴ２０５）。
【００７８】
例えば、パケット生成部２０２は、受け取った音声パケットのIPヘッダをブロードキャストアドレス又はマルチキャストアドレスに書き換える。なお、マルチキャストアドレスを用いる場合には、リモートUE３００が通信開始処理を完了するまでの間に、リレーUE２００とリモートUE３００との間でマルチキャストグループ参加に関する処理を行う必要がある。また、リレーUE２００は、音声パケットの送信に用いる送信先ポート番号に関しても、リモートUE３００との間で予め取り決めを行ってもよい。また、宛先アドレスとしてはProSe Group IP multicast addressを用いても良い。
【００７９】
パケット生成部２０２で生成されたパケット（リモートUE３００宛てのパケット）は送信部２０３を介して送信される（ＳＴ２０６）。このように、リレーUE２００は、MCPTTサーバ１００から送信される音声パケットを、同一のグループIDが割り当てられた、当該リレーUE２００に接続された全てのリモートUE３００へ送信する。
【００８０】
なお、リレーUE２００は、自機に接続されているリモートUE３００が１つである場合には、ブロードキャストアドレス又はマルチキャストアドレス、ProSe Group IP multicast addressなどを用いずに、リモートUE３００のユニキャストアドレス宛てにパケットを送信してもよい。
【００８１】
リモートUE３００の受信部３０１は、リレーUE２００から送信されたパケットを受信する（ＳＴ２０６）。
【００８２】
リモートUE３００の判断部３０２は、受信したパケット（リモートUE用）に対して処理を行うか否かを判断する（ＳＴ２０７）。具体的には、判断部３０２は、受信したパケットが自機宛の音声パケットであるか否かを、パケットのヘッダ情報より判断する。判断部３０２における音声パケットの判断には、非特許文献１３などに記載のパケット毎の優先度（PPP: Per Packet Priority）などを用いてもよい。また、判断部３０２は、現在自機に発言権が与えられていないこと、又は、他のUEに発言権が与えられていることを確認した場合、受け取った音声データを、自機が生成・送信した音声データではないと判断する。
【００８３】
図６では、判断部３０２は、受信したパケットが自機宛ての音声パケットであり、自機に発言権が与えられていないので、受信したパケットに対して処理を行うと判断する。
【００８４】
リモートUE３００の処理部３０３は、判断部３０２の判断に基づいてパケットを処理する。例えば、図６のように、判断部３０２の判断結果が、自機宛のパケットであり、かつ自機が生成・送信したパケットではないという判断である場合、処理部３０３は、受信したパケットを受け付け、データ（RTPパケット）を上位レイヤ（RTPレイヤ）に渡す処理などを行う（ＳＴ２０８）。
【００８５】
［ケース２：リモートUE３００からの音声パケット］
次に、図２〜図４、図７を用いて、リモートUE３００（UE3〜UE5）のうちいずれかのUEがMCPTTサーバ１００から発言権（Floor Grant）を得て、発言を開始した場合の処理について説明する。
【００８６】
図７は、ケース２に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。なお、図７において、図６と同一の処理には同一の符号を付し、その説明を省略する。
【００８７】
図７において、リモートUE３００は、音声パケットを生成し、リレーUE２００を介してMCPTTサーバ１００へ音声パケット（上り）を送信する（ＳＴ３０１）。
【００８８】
この際、同一のグループIDが割り当てられた、発言権を得ていないリモートUE３００へ音声パケット（上り）が送られるが、発言権を得ていないリモートUE３００の判断部３０２は、宛先IPアドレスなどから自機宛ての音声パケットでは無い事を判断し、処理部３０３はパケットを破棄する。
【００８９】
MCPTTサーバ１００は、リレーUE３００から送信された上りの音声パケットを受け取ると（ＳＴ３０１）、ケース１と同様、当該音声パケットの送信先UE（リレーUE２００又は１つのリモートUE３００、又はProSe Group IP multicast addressを宛先とするUE群）を決定し（ＳＴ２０２）、下りのパケットを生成し（ＳＴ２０３）、パケット（下り）を送信する（ＳＴ２０４）。
【００９０】
なお、MCPTTサーバ１００の判断部１０４は、格納部１０３の情報に基づいて、パケットを送信してきたUEがリモートUE３００であり、当該リモートUE３００がリレーUE２００に接続された唯一のリモートUE３００である場合、かつ、リレーUE２００がこのパケットを受け取る必要が無い場合（例えば、リレーUE２００がMBMSで音声パケットを受け取っている場合など）には、リレーUE２００にパケットを送信しないと判断してもよい。
【００９１】
また、ケース１と同様、リレーUE２００は、MCPTTサーバ１００から送信された音声パケットを受信し（ＳＴ２０４）、音声パケットを自機配下のリモートUE３００が受信できるように音声パケットのヘッダ情報を変更し（ＳＴ２０５）、生成したリモートUE用パケットを送信する（ＳＴ２０６）。又は、受信した音声パケットの宛先がProSe Group IP multicast addressであった場合は、リレーUE２００の受信部２０１は、音声パケットをパケット生成部２０２には出力せず、送信部２０３を介して送信する。
【００９２】
リモートUE３００の判断部３０２は、受信したパケット（リモートUE用）に対して処理を行うか否かを判断する（ＳＴ２０７）。具体的には、判断部３０２は、受信したパケットが自機宛の音声パケットであるか否かを、パケットのヘッダ情報より判断する。また、判断部３０２は、現在自機に発言権が与えられていないこと、又は、他のUEに発言権が与えられていることを確認した場合、受け取った音声データを自機が生成・送信した音声データではないと判断する。
【００９３】
図７では、判断部３０２は、自機宛てのパケットであるが、自機に発言権が与えられているので、受信したパケットが自機で生成・送信した音声パケットであると判断する。つまり、判断部３０２は、受信したパケットに対して処理を行わずに破棄すると判断する。
【００９４】
リモートUE３００の処理部３０３は、判断部３０２の判断に基づいてパケットを処理する。図７では、処理部３０３は、受信したパケットが自機で生成・送信した音声パケットであると判断されたので、当該音声パケットを破棄する処理を行う（ＳＴ３０２）。
【００９５】
［ケース３：リモートUE３００からの音声パケット］
次に、図２〜図４、図８を用いて、リモートUE３００（UE3〜UE5）のうちいずれかのUEがMCPTTサーバ１００から発言権（Floor Grant）を得て、発言を開始した場合のケース２とは別の処理について説明する。
【００９６】
図８は、ケース３に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
【００９７】
図８において、リモートUE３００は、ブロードキャストアドレス、マルチキャストアドレス、又はProSe Group IP multicast addressなどを宛先とした音声パケットを生成し、同一グループIDを持つリレーUE２００及びリモートUE３００に送信する（ＳＴ４０１）。
【００９８】
ここで、発言権を得ていないリモートUE３００の判断部３０２は、自機宛ての音声パケットである事を判断し、処理部３０３は、受信したパケットを受け付け、データ（RTPパケット）を上位レイヤ（RTPレイヤ）に渡す処理などを行う。
【００９９】
リレーUE２００の受信部２０１は、リモートUE３００から送信された音声パケットを受信する（ＳＴ４０１）。リレーUE２００は、受信した信号が音声パケットであるか否かに関して、非特許文献１３に記載のPer Packet Priorityなどで判断する。そして、リレーUE２００の受信部２０１は、受信した音声パケットを、パケット生成部２０２に出力する。
【０１００】
パケット生成部２０２は、受信部２０１から受け取った音声パケットのヘッダの宛先をMCPTTサーバ１００に変更するなどの必要な処理を行い、リモートUE３００を送信元、MCPTTサーバ１００を送信先とするパケットを生成する（ＳＴ４０２）。
【０１０１】
パケット生成部２０２で生成されたパケット（MCPTTサーバ１００宛てのパケット）は送信部２０３を介して送信される（ＳＴ４０３）。このように、リレーUE２００は、リモートUE３００から送信される音声パケットを、MCPTTサーバ１００へ送信する。
【０１０２】
MCPTTサーバ１００がリレーUE２００から送信された上りの音声パケットを受け取ると（ＳＴ４０３）、MCPTTサーバ１００の判断部１０４は、格納部１０３の情報に基づいて、パケットを送信してきたUEがリモートUE３００であり、同一グループIDを持つUE（リレーUE２００，リモートUE３００）が既にこの音声パケットを受け取っていると判断し、リレーUE２００又はリモートUE３００にパケットを送信しないと判断してもよい（ＳＴ４０４）。
【０１０３】
以上、本実施の形態に係る動作について説明した。
【０１０４】
このように、本実施の形態に係る通信システムでは、MCPTTサーバ１００は、MCPTTのグループサービスに参加するUEにおけるリレーUE２００とリモートUE３００との関係を保持する。そして、MCPTTサーバ１００は、音声通信時には、リレーUE２００（又はリモートUE３００の何れか１つのUE）、又はProSe Group IP multicast addressを宛先とするUE群に対してのみ音声パケットを送信する。そして、リレーUE２００は、受け取った音声パケットを、自機配下のリモートUE３００へ送信する。
【０１０５】
これにより、EPS内では、MCPTTのグループサービスに参加するリモートUE３００が存在する場合でも、１つのUE（リレーUE２００）向けのパケットのみが送信されるので、EPS（コア網）でのリソースが無駄に消費されることを防ぐことができる。
【０１０６】
また、リレーUE２００は、MCPTTサーバ１００が１つのUE向けに送信した音声パケットを、自機配下の全てのリモートUE３００（同一のグループIDが割り当てられたUE）へそれぞれ配信する。これにより、リレーUE２００とリモートUE３００との間のProSe通信でもUE毎のパケットが全てのUEに無駄に配信されることなく、無線リソースが無駄に消費されることを防ぐことができる。
【０１０７】
また、リレーUE２００は、MCPTTサーバ１００から送信される音声パケットを、同一のグループIDが割り当てられた全てのリモートUE３００へ配信すればよく、リモートUE３００毎のグループIDの管理する必要が無いので、リレーUE２００の処理負荷の増加を抑えることができる。
【０１０８】
以上より、本実施の形態によれば、MCPTTサービスにおいて、リレーUE２００の処理負荷の増加を抑えつつ、コア網のリソース及び無線リソースの消費を抑えることができる。
【０１０９】
（実施の形態２）
本実施の形態では、リレーUE２００と個々のリモートUE３００がグループIDを用いずに直接(one to one)通信する方法について説明する。
【０１１０】
MCPTTサーバ１００内のProSe機能は、リレーUE２００及びリモートUE３００に対して、グループIDに加え、UE-to-Network relayの際の直接通信に必要なLayer2 ID（以下直接通信IDと言う）を付与する。この直接通信IDは、リレーUE２００とリモートUE３００がリレーUE及びリモートUEの関係になった際に配布されても良いし、リレーUE及びリモートUEの関係になる前に予め配布されていても良い。また、この直接通信IDは、同じMCPTTサービスに参加する全UEに重複せずに与えられるIDであっても良いし、リレーUE及び同じリレーUEに繋がるリモートUE間に重複せずに与えられるものであっても良い。また、直接通信IDは、MCPTTサーバ１００内のProSe機能ではなく、リレーUEがリモートUEに対し付与しても良い。また、この直接通信IDは、非特許文献６に記載のProSe UE IDであっても良い。
【０１１１】
［リモートUEの登録処理］
本実施の形態におけるリモートUEの登録処理に関し、リモートUE３００、リレーUE２００及びMCPTTサーバ１００に新たな機能追加する必要は無い。登録処理、通信開始処理、ベアラ確立処理などは、リレーUE２００とリモートUE３００の関係を意識せずに処理が行われる。
【０１１２】
［音声パケット通信処理］
図１〜図４及び図９，図１０を用いて本実施の形態の音声パケット通信処理を説明する。
【０１１３】
図９は、本実施の形態に係る音声パケット通信処理の動作の一例を示すシーケンスチャートである。
【０１１４】
図９において、MCPTTサーバ１００の受信部１０１は、上りの音声パケット（発言権を与えられたUE（図１ではUE1）から送信される音声パケット）を受け取る（ＳＴ５０１）。上りの音声パケットを受け取ると、MCPTTサーバ１００の判断部１０４は、上りの音声パケットを送信したUE以外で、EPSベアラで下りの音声パケットを受け取る全てのUEに対し、音声パケットを送るよう判断する（ＳＴ５０２）。なお、この判断は上りの音声パケットの送信元がリモートUE３００であっても同じである。MCPTTサーバ１００のパケット生成部１０５は、判断部１０４の判断結果に基づいて、下りパケットを生成する（ＳＴ５０３）。生成されたパケット（下り）は、送信部１０６を介して送信先のUEへ送信される（ＳＴ５０４）。
【０１１５】
リレーUE２００の受信部２０１は、MCPTTサーバ１００から送信された音声パケットを受信する（ＳＴ５０４）。
【０１１６】
リレーUE２００のパケット生成部２０２は、直接通信IDを用いてリモートUE３００向けのパケットを生成する（ＳＴ５０５）。具体的には、パケット生成部２０２は、リモートUE３００のIPアドレスと、リモートUE３００の直接通信IDが合致するように、非特許文献１１及び非特許文献７に記載の通りLayer2の処理を行う。なお、リレーUE２００及びリモートUE３００間の直接通信IDの交換(exchange)は、リモートUE３００がリレーUE２００を発見(Discovery)し、接続する際に行われても良いし、前述のように、リモートUE３００がリレーUE２００に接続した際に、リレーUE２００がリモートUE３００に直接通信IDを割り当てても良い。
【０１１７】
図１０は非特許文献７に記載のsidelink用MAC(Medium Access Control)サブヘッダを示す。パケット生成部２０２は、図１０に示すDST欄に、グループIDの代わりにリモートUE３００のIPアドレスと対応付けられている直接通信ID又はその一部を入力する。リレーUE２００は、直接通信ID（又はその一部）の大きさが図１０のように16ビットに合わないようであれば、DST欄の大きさを変更してもよい。また、リレーUE２００は、通常のグループIDを使った通信と区別するために、図１０に示すV欄(MAC PDU format version number)の値を直接通信用に設定しても良い。また、リレーUE２００は、SRC欄に関しても、リレーUE２００の直接通信IDを用いても良いし、直接通信IDの大きさが24ビットに合わないようであれば、SRC欄の大きさを変更しても良い。また、本実施の形態では、既存のsidelink用MACサブヘッダを変更するのではなく、直接通信用に全く新しいMACサブヘッダを定義しても良い。
【０１１８】
リレーUE２００の送信部２０３から送信されたパケットは、リモートUE３００の受信部３０１によって受信される（ＳＴ５０６）。リモートUE３００のMACサブレイヤは、宛先の直接通信IDにより自機宛である事を確認し、受信処理を行う（ＳＴ５０７）。
【０１１９】
上述した直接通信処理は、リモートUE３００からリレーUE２００にパケット送信を行う場合も同様である。
【０１２０】
以上、本実施の形態に係る動作について説明した。
【０１２１】
これにより、リレーUE２００及びリモートUE３００のLayer 2（非特許文献１１記載）のみを変更する事により、リレーUE２００、リモートUE３００、MCPTTサーバ１００への変更を抑えつつ、リレーUE２００とリモートUE３００との間の無線リソースの無駄な消費を抑える事ができる。
【０１２２】
以上、本開示各実施の形態について説明した。
【０１２３】
なお、上記実施の形態で説明したリモートUE３００において、自機が発信したパケットを破棄するメカニズム（例えば、図７を参照）は、ブロードキャスト又はマルチキャストを用いたグループ通信で適用してもよい。
【０１２４】
また、上記実施の形態では、音声パケットの通信を行う通信システムについて説明したが、通信システムは、音声パケット以外の他のパケット、例えば発言権制御（Floor Control）のパケットに対して適用してもよい。また、音声以外のメディア（映像など）のパケットに適用してもよい。
【０１２５】
また、上記実施の形態ではMCPTTを例として説明したが、同様のアーキテクチャを用いる他のサービスに対して適用しても良い。
【０１２６】
また、本開示の一態様は、上記各実施の形態に限定されず、種々変更して実施することが可能である。
【０１２７】
また、上記各実施の形態では、本開示の一態様をハードウェアで構成する場合を例にとって説明したが、本開示はハードウェアとの連携においてソフトウェアでも実現することも可能である。
【０１２８】
また、上記各実施の形態の説明に用いた各機能ブロックは、典型的には、入力端子及び出力端子を有する集積回路であるＬＳＩとして実現される。集積回路は、上記実施の形態の説明に用いた各機能ブロックを制御し、入力端子と出力端子を備えてもよい。これらは個別に１チップ化されてもよいし、一部又は全てを含むように１チップ化されてもよい。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１２９】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）または、ＬＳＩ内部の回路セルの接続若しくは設定を再構成可能なリコンフィギュラブル／プロセッサを利用してもよい。
【０１３０】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【産業上の利用可能性】
【０１３１】
本開示の一態様は、MCPTTのサービスを提供する通信システム及び通信システムを利用するユーザ端末に有用である。
【符号の説明】
【０１３２】
１００  MCPTTサーバ
１０１，２０１，３０１  受信部
１０２  検出部
１０３  格納部
１０４，３０２  判断部
１０５，２０２  パケット生成部
１０６，２０３，３０４  送信部
２００  リレーUE
３００  リモートUE
３０３  処理部
４００  PDN GW
【図１】
2017051503.tif 000003
【図２】
2017051503.tif 000004
【図３】
2017051503.tif 000005
【図４】
2017051503.tif 000006
【図５】
2017051503.tif 000007
【図６】
2017051503.tif 000008
【図７】
2017051503.tif 000009
【図８】
2017051503.tif 000010
【図９】
2017051503.tif 000011
【図１０】
2017051503.tif 000012
【国際調査報告】
2017051503.tif 000013
2017051503.tif 000014