以下、図面を参照して本発明を実施するための最良の形態について説明する。
なお、本実施形態では、一例として、本発明を適用した場合の移動通信システムの実施形態について、図を用いて詳細に説明する。なお、ProSeでは、non−Public SafetyとPublic Safetyがある。non−Public Safetyでは、移動通信事業者による商用サービスが想定されており、UEがLTE基地局に在圏している場合にのみ、利用可能である。一方、Public Safetyでは、防災無線による利用が想定されており、UEがLTE基地局に在圏している場合のみならず、LTE基地局(eNB)に在圏していない場合でも利用することができる。
また、LTE Directでは、商用サービス(non−Public Safety)においてLTEの通信方式を利用して、UE間において直接データの送受信を行うことができ、Public SafetyにおいてLTEの通信方式を利用して、UE間において直接データの送受信を行うことができる。
また、WLAN Directでは、商用サービスにおいてWLANの通信方式を利用して、UE間において直接データの送受信を行う方法があり、さらに、Public SafetyにおいてWLANの通信方式を利用して、UE間において直接データの送受信を行う可能性がある。
[1.第1実施形態]
なお、LTE基地局装置に在圏していることをIn coverage、LTE基地局装置に在圏していないことをOut of coverageとして説明する。まず、本発明を適用した第1実施形態について、図面を参照して説明する。
[1.1 移動通信システムの概要]
図1は、本実施形態における移動通信システム1の概略を説明するための図である。本図に示すように、移動通信システム1は、UE(移動局装置、端末装置)10Aと、UE(移動局装置、端末装置)10Bと、PDN(Packet Data Network)20とがIP移動通信ネットワーク5を介して接続されて構成されている。また、PDN20には、ProSeサーバ90およびアプリケーションサーバ95が配置されている。ここで、ProSeサーバ90は、UE10AまたはUE10Bが近隣検出を行うネットワークの移動通信事業者が管理する認証サーバであり、アプリケーションサーバ95は、UE10AまたはUE10Bが利用するアプリケーション(APP1)によるサービスを提供するサーバである。なお、本図では、ProSeサーバ90は移動通信ネットワーク5の外部の装置として記載されているが、移動通信ネットワーク内の装置であっても良い。また、ProSeサーバ90はMME40の機能の一部であっても良いし、別の装置で構成されても良い。
なお、ProSeサーバ90と、アプリケーションサーバ95は、PDN20に含まれて構成されてもよいし、コアネットワーク7に含まれて構成されてもよい。
UE10Aと、UE10Bは、同じ移動通信事業者網に接続していてもよいし、単一の国のなかの異なる移動通信事業者網に接続していてもよい。IP移動通信ネットワーク5は、例えば、移動通信事業者が運用する無線アクセスネットワークとコアネットワークによって構成されるネットワークでもよいし、固定通信事業者が運用するブロードバンドネットワークであっても良い。移動通信事業者が運用するIP移動通信ネットワークは後で詳細に説明する。
また、ブロードバンドネットワークは、ADSL(Asymmetric Digital Subscriber Line)等により接続し、光ファイバー等のデジタル回線による高速通信を提供する、通信事業者が運用するIP通信ネットワークのことである。さらに、これらに限らずWiMAX(Worldwide Interoperability for Microwave Access)等で無線アクセスするネットワークであっても良い。
UE10Aは、LTEやWLAN等のアクセスシステムを用いて接続する通信端末であり、3GPP LTEの通信インタフェースやWLANの通信インタフェース等を搭載して接続することにより、IPアクセスネットワークへ接続することが可能である。
具体的な例としては、携帯電話端末やスマートフォンであり、その他通信機能を備えたタブレット型コンピュータやパソコン、家電などである。
PDN20は、パケットでデータのやり取りを行うネットワークサービスを提供するネットワークのことであり、例えば、インターネットやIMSなどである。
PDN20は、IPアクセスネットワークへ有線回線等を利用して接続される。例えば、ADSL(Asymmetric Digital Subscriber Line)や光ファイバー等によって構築される。ただし、これに限らずLTE(Long Term Evolution)や、WLAN(Wireless LAN)、WiMAX(Worldwide Interoperability for Microwave Access)等の無線アクセスネットワークであっても良い。
[1.1.1 IP移動通信ネットワークの構成例]
図2に示すように、移動通信システム1は、UE10Aと、IP移動通信ネットワーク5と、PDN20(Packet Data Network)とから構成される。なお、UE10Bは、UE10Aとは異なるUEであり、構成はUE10Aと同様であるため説明を省略する。また、IP移動通信ネットワーク5には、UE10AやUE10B以外にも複数のUEが接続することができるが図面の簡略化のため記載を省略する。さらに、IP移動通信ネットワーク5はコアネットワーク7と各無線アクセスネットワークで構成される。コアネットワーク7の詳細な構成について図2(a)に示している。
なお、PDN20は、図1を用いて説明したパケットでデータのやり取り行うネットワークサービスを提供するネットワークのことであり、例えば、インターネットやIMSなどである。
コアネットワーク7は、PGW(アクセス制御装置)30(Packet Data Network Gateway)と、SGW35(Serving Gateway)と、MME40(Mobile Management Entity)と、HSS50(Home Subscriber Server)と、AAA55(Authentication, Authorization, Accounting)と、PCRF60(Policy and charging rules function)と、ePDG65(enhanced Packet Data Gateway)と、を含んで構成される。
無線アクセスネットワークは、複数の異なるアクセスネットワークで構成されてよい。それぞれのアクセスネットワークはコアネットワーク7に接続されている。さらに、UE10Aは無線アクセスネットワークに無線接続することができる。
無線アクセスネットワークには、LTEアクセスシステムで接続できるLTEアクセスネットワーク(LTE AN80)や、WLANアクセスシステムで接続できるアクセスネットワークを構成することができる。
さらに、WLANアクセスシステムで接続可能なアクセスネットワークは、ePDG65をコアネットワーク7への接続装置として接続するWLANアクセスネットワークb(WLAN ANb75)と、PGW30とPCRF60とAAA55とに接続するWLANアクセスネットワークa(WLAN ANa70)とが構成可能である。
なお、各装置はEPSを利用した移動通信システムにおける従来の装置と同様に構成されるため、詳細な説明は省略するが、簡単に機能を説明すると、PGW30はPDN20とSGW35とePDG65と、WLAN ANaと、PCRF60と、AAA55とに接続されており、PDN20とコアネットワーク7のゲートウェイ装置としてユーザデータ配送を行う。
SGW35は、PGW30と、MME40とLTE AN80とに接続されており、コアネットワーク7とLTE AN80とのゲートウェイ装置としてユーザデータの配送を行う。
MME40は、SGW35とLTE AN80に接続されており、LTE AN80を経由したUE10Aのアクセス制御を行うアクセス制御装置である。なお、MME40において、ProSeサーバ90の機能を保持していても良い。
HSS50は、SGW35とAAA55とに接続されており、加入者情報の管理を行う。また、AAA55は、PGW30と、HSS50と、PCRF60と、WLAN ANa70とに接続されており、WLAN ANa70を経由して接続するUE10Aのアクセス制御を行う。PCRF60は、PGW30と、WLAN ANa70と、AAA55とに接続されており、データ配送に対するQoS管理を行う。
ePDG65は、PGW30と、WLAN ANb75とに接続されており、コアネットワーク7と、WLAN ANb75とのゲートウェイ装置としてユーザデータの配送を行う。
また、図2(b)に示すように、各無線アクセスネットワークには、UE10Aが実際に接続される装置(例えば、基地局装置やアクセスポイント装置)等が含まれている。接続に用いられる装置は、無線アクセスネットワークに適応した種々の装置が考えられるが、本実施形態においては、LTE AN80はeNB45を含んで構成される。eNB45はLTEアクセスシステムでUE10Aが接続する無線基地局であり、LTE AN80には1又は複数の無線基地局が含まれて構成されてよい。
さらに、WLAN ANa70はWLAN APa72と、GW74(Gateway)とが含まれて構成される。WLAN AP72はWLANアクセスシステムでUE10Aが接続する無線基地局であり、WLAN AN70には1又は複数の無線基地局が含まれて構成されてよい。GW74はコアネットワーク7とWLAN ANa70のゲートウェイ装置である。また、WLAN APa72とGW74とは、単一の装置で構成されてもよい。
このように、WLAN ANa70に含まれるゲートウェイは複数のコアネットワーク7内装置に接続することができる。コアネットワーク7を運用する事業者とWLAN ANa70を運用する事業者が異なる場合等では、事業者間に運用上の契約や規約等により、信頼関係が結ばれている場合にこのような構成で運用することができる。言い換えると、WLAN APa72はコアネットワーク7を運用する事業者に対して信頼性のあるアクセスネットワークである。
また、WLAN ANb75はWLAN APb76を含んで構成される。WLAN AP76はWLANアクセスシステムでUE10Aが接続する無線基地局であり、WLAN AN75には1又は複数の無線基地局が含まれて構成されてよい。
このように、WLAN ANb75はコアネットワーク7に含まれる装置であるePDG65をゲートウェイとしてコアネットワーク7に接続される。ePDG65は安全性を確保するためのセキュリティ機能を持つ。コアネットワーク7を運用する事業者とWLAN ANa70を運用する事業者が異なる場合等では、事業者間に運用上の契約や規約等により、信頼関係が結ばれていない場合にこのような構成で運用する。言い換えると、WLAN APaはコアネットワーク7を運用する事業者に対して信頼性のないアクセスネットワークであり、コアネットワーク7に含まれるePDG65において安全性を提供している。
なお、本明細書において、UE10Aが各無線アクセスネットワークに接続されるとは、各無線アクセスネットワークに含まれる基地局装置やアクセスポイント等に接続されることをいい、送受信されるデータや信号等も、基地局装置やアクセスポイントを経由している。
例えば、LTE AN80にUE10Aが接続されるとは、UE10AがeNB45を介して接続されることをいい、WLAN ANa70に接続されるとは、WLAN APa72及び/又はGW74を介して接続されることをいう。また、UE10AがWLAN ANb75に接続されるとは、UE10AがWLAN APb76に接続されることを言う。
[1.2 装置構成]
続いて、各装置構成について図を用いて簡単に説明する。
[1.2.1 UEの構成]
UEは、LTEアクセス方式により、無線通信によるデータの送受信を行う携帯電話端末であっても良いし、マシーンツーマシーンと呼ばれるような形態で機器同士が相互に情報交換する端末装置であっても良い。また、これらに限られない通信端末であっても良い。図3は、本実施形態におけるUE10Aの機能構成を示す。UE10Aは、制御部100に、送受信部110と直接送受信部120と、記憶部140とがバスを介して接続されている。
制御部100は、UE10Aを制御するための機能部である。制御部100は、記憶部140に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。
送受信部110は、LTEアクセス方式により無線通信によるデータの送受信を実行する機能部である。ここで、送受信部110は、送信部と受信部から構成される。送信部はLTE基地局を介してデータや制御情報を送信することができ、受信部はLTE基地局を介してデータや制御情報を送信することができる。なお、送受信部110には、外部アンテナ112が接続されており、送信部においてLTE基地局を介してデータや制御情報の送信を行い、直接受信部においてLTE基地局を介してデータや制御情報の受信を行うことができる。UE10Aは、送受信部を介してLTE基地局に接続してIPアクセスネットワーク5に接続して通信を行うこともできる。
ここで、送受信部110は、アプリケーションの通信データであるユーザデータと制御情報の送信を行う送信部と、アプリケーションの通信データであるユーザデータと制御情報の受信を行う受信部とを分けて構成しても良い。
直接送受信部120は、LTE基地局を介さずに他のUEへデータや制御情報などで直接通信を行うことができる機能部である。ここで、直接送受信部120は、直接送信部と直接受信部から構成される。直接送信部はLTE基地局を介さずにデータや制御情報を送信することができ、直接受信部はLTE基地局を介さずにデータや制御情報を送信することができる。なお、直接送受信部110には、外部アンテナ112が接続されており、直接送信部においてLTE基地局を介さずにデータや制御情報の送信を行い、直接受信部においてLTE基地局を介さずにデータや制御情報の受信を行うことができる。
ここで、直接送受信部120は、アプリケーション(APP)の通信データであるユーザデータと制御情報の送信を行う送信部と、アプリケーション(APP)の通信データであるユーザデータと制御情報の受信を行う受信部とを分けて構成しても良い。
また、送受信部110と直接送受信部120とは一つの送受信部として構成されてもよいし、送受信部110の送信部と直接送受信部120の送信部とを一つの送信部として構成し、送受信部110の受信部と直接送受信部120の受信部とを一つの受信部として構成しても良い。
記憶部140は、UE10Aの各種動作に必要なプログラム、データ等を記憶する機能部である。記憶部140は、例えば、半導体メモリや、HDD(Hard Disk Drive)等により構成されている。さらに、記憶部140には、ProSe ID142、Group ID144、APPサーバ情報146、In coverageフラグ147、public Safety capability148、public safety enableフラグ149が記憶されている。
ProSe ID142には、UE10Aが近隣検出または、直接通信を行うことができるUEを識別する情報を記憶している。図4(a)は、ProSe ID142の一例を示した図である。図4(a)は、ProSe ID142を示した図である。図4(a)では、UE10Aを識別するための識別子(ProSe ID A)や近隣に存在し、直接通信を行うことができるUE10Bを識別するための識別子(ProSe ID B)が管理されている。また、近隣に在圏しないが、直接通信を行うことができるUE10C(識別子:ProSe ID C)やUE10D(識別子:ProSe ID D)も管理されている。
また、ProSe ID142は、UEを識別するだけでなく、特定のUEのアプリケーション毎に管理されてもよい。これにより、ProSe ID142は、UEを識別できるだけでなく、UEのアプリケーションも特定することができる。
また、ProSe ID142は、Expressionコードであっても良い。Expressionコードとは、UEを識別するための識別子である。Expressionコードは、EPSやアプリケーションサーバによって割り当てられても良い。また、UE10Aは、ExpressionコードをUE10Bに送信し、UE10BがUE10Aと近隣に存在することを検出するために、Expressionコードを利用してもよい。
Group ID144は、UE10Aが参加するグループを識別する識別子を管理している。Group ID144により、UE10Aは近隣検出や直接通信を行うUEを制限することができる。なお、Group ID144は、必ずしも利用されるものでなく、Group ID144を利用せずに、近隣検出や直接通信を開始しても良い。図4(b)では、Group ID144は、Group 1およびGroup2が管理されている。なお、Group IDは複数管理可能であり、UE10Aは複数のグループに所属することができる。
APPサーバ情報146は、アプリケーション(APP)毎に関連付けられるAPPサーバに関する情報を管理する。APPサーバは、UE10Aが利用するアプリケーションにおいて、サービスを提供するサーバのことである。UE10Aは、APPサーバから近隣検出や直接通信に必要な情報を受信し、近隣検出や直接通信を行うことができる。
図4(c)におけるAPPサーバ情報では、UE10Aが利用するアプリケーションのAPP1におけるAPPサーバ1とAPP2におけるAPPサーバ2が管理されている。
なお、APPサーバは、複数管理可能であり、UE10Aは各アプリケーションに対して、異なるAPPサーバを利用することができる。
また、アプリケーションは、VoIPまたはビデオストリーミングまたはビデオファイルまたはテキストなどのデータ種別によって異なるアプリケーションと識別されて管理しても良い。
もしくは、IMSなどのミドルウェアを用いた通信を単一のアプリケーションとして識別して管理しても良い。
もしくは、SkypeやLINEといった個別のアプリケーションをアプリケーション名やアプリケーションIDによって識別して管理しても良い。
もしくはこれらの組み合わせによってアプリケーションを異なるものとして識別して管理しても良い。
ここで、UE10が利用可能なアプリケーションは、製造段階において、インストールされていても良いし、ユーザ操作によりインストールされていても良い。
図4(d)は、近隣検出または、直接通信を行うことができるUEに対するIn coverageフラグ147の例を示した図である。図4(d)では、UE10AのIn coverageフラグ147と、UE10BのIn coverageフラグと、UE10BのIn coverageフラグと、UE10BのIn coverageフラグとが管理されている。ここでは、一例として、UE10Aに対してIn coverageフラグをIn coverageとして管理し、UE10Bに対してIn coverageフラグをOut of coverageとして管理し、UE10Cに対してIn coverageフラグをIn coverageとして管理し、UE10Dに対してIn coverageフラグをIn coverageとして管理している。
ここで、UE10Aに対してIn coverageフラグをOut of coverageとして管理し、UE10Bに対してIn coverageフラグをIn coverageとして管理し、UE10Cに対してIn coverageフラグをOut of coverageとして管理し、UE10Dに対してIn coverageフラグをOut of coverageとして管理しても良い。
図4(e)は、public safety capability148の例を示した図である。public safety capability148は、public safetyを利用することができることを示す情報を管理している。図4(e)では、UE10Aのpublic safety capabilityと、UE10Bのpublic safety capabilityと、UE10Cのpublic safety capabilityと、UE10Dのpublic safety capabilityと、を管理している。ここでは、一例として、UE10Aに対するpublic safety capabilityを可として管理し、UE10Bに対するpublic safety capabilityを可として管理し、UE10C対するpublic safety capabilityを可として管理し、UE10Dに対するpublic safety capabilityを不可として管理している。public safety capabilityが可の場合、UEはpublic safetyの機能を保持し、public safetyを利用可能であることを示し、public safety capabilityが不可の場合、UEはpublic safetyの機能を保持せず、public safetyを利用不可能であることを示している。
図4(f)は、public safety enableフラグ149の例を示した図である。public safety enableフラグ149は、public safetyを各UEが許可(またはon)していることを示す情報を管理している。図4(f)では、UE10Aのpublic safety enableフラグと、UE10Bのpublic safety enableフラグと、UE10Cのpublic safety enableフラグと、UE10Dのpublic safety enableフラグと、を管理している。ここでは、一例として、UE10Aに対するpublic safety enableフラグをonとして管理し、UE10Bに対するpublic safety enableフラグをonとして管理し、UE10Cに対するpublic safety enableフラグをoffとして管理し、UE10Dに対するpublic safety enableフラグを「―」として管理している。ここで、UE10Dは、public safetyを利用することができないため、「―」として管理しているが、offとして管理しても良い。public safety enableフラグ149において、「―」または、「off」として管理されているUEは、public safetyを利用できないUEとして管理される。
[1.2.2 ProSeサーバの構成]
図5にProSeサーバ90の機能構成を示す。なお、ProSeサーバ90とは、ProSeによる近隣検出やProSeによる通信を行う移動通信事業者で管理される認証サーバである。認証サーバ90は、制御部900に、IP移動通信ネットワークインタフェース部910と、記憶部940とがバスを介して接続されている。
制御部900は、UE10を制御するための機能部である。制御部900は、記憶部940に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。
IP移動通信ネットワークインタフェース部910は、認証サーバ90がIP移動通信ネットワーク5に接続するための機能部である。
記憶部940は、UE10の各種動作に必要なプログラム、データ等を記録する機能部である。記憶部940は、例えば、半導体メモリや、HDD(Hard Disk Drive)等により構成される。
さらに、記憶部940には、ProSe ID942と、Group ID944と、UE In coverageフラグ946と、UE public safety capability948とUE public safetyフラグ949とを管理する。
なお、以下で説明するProSe ID942、Group ID944、UE In covergeフラグ946と、UE public safety capability948と、UE public safety enableフラグ949は、外部装置により記憶されていても良い。例えば、HSS50にこれらを記憶し、必要に応じてHSS50への問い合わせを行うことで参照したり、記憶部940に登録したり更新を行ってもよい。
図6(a)に、ProSeサーバで管理されるProSe ID942の例を示す。ProSe ID942には、UE10Aが近隣検出または、直接通信を行うことができるUE識別子を記憶している。図6(a)では、UE10Aを識別するための識別子(ProSe ID A)や近隣に存在し、直接通信を行うことができるUE10Bを識別するための識別子(ProSe ID B)と、UE10C(識別子:ProSe ID C)やUE10D(識別子:ProSe ID D)とが管理されている。
なお、ProSe ID942は、アプリケーション毎に管理されていても良い。つまり、APP毎に、ProSe ID942を管理しても良い。
また、ProSe ID942は、UEを識別するための識別子であれば、Expressionコードであっても良い。Expressionコードとは、UEを識別するための識別子である。Expressionコードは、EPSやアプリケーションサーバによって割り当てられても良い。また、UE10Aは、ExpressionコードをUE10Bに送信し、UE10BがUE10Aと近隣に存在することを検出するために、Expressionコードを利用してもよい。
Group ID944は、UE10Aが参加するグループを識別する識別子を管理している。図6(b)では、Group ID944は、Group 1およびGroup2が管理されている。なお、Group IDは複数管理可能である。
図6(c)は、近隣検出または、直接通信を行うことができるUEに対するIn coverageフラグ946の例を示した図である。図6(c)では、UE10AのIn coverageフラグ147と、UE10BのIn coverageフラグと、UE10BのIn coverageフラグと、UE10BのIn coverageフラグとが管理されている。ここでは、一例として、UE10Aに対してIn coverageフラグをIn coverageとして管理し、UE10Bに対してIn coverageフラグをOut of coverageとして管理し、UE10Cに対してIn coverageフラグをIn coverageとして管理し、UE10Dに対してIn coverageフラグをIn coverageとして管理している。
ここで、UE10Aに対してIn coverageフラグをOut of coverageとして管理し、UE10Bに対してIn coverageフラグをIn coverageとして管理し、UE10Cに対してIn coverageフラグをOut of coverageとして管理し、UE10Dに対してIn coverageフラグをOut of coverageとして管理しても良い。
図6(d)は、public safety capability948の例を示した図である。public safety capability948は、public safetyを利用することができることを示す情報を管理している。図6(d)では、UE10Aのpublic safety capabilityと、UE10Bのpublic safety capabilityと、UE10Cのpublic safety capabilityと、UE10Dのpublic safety capabilityと、を管理している。ここでは、一例として、UE10Aに対するpublic safety capabilityを可として管理し、UE10Bに対するpublic safety capabilityを可として管理し、UE10C対するpublic safety capabilityを可として管理し、UE10Dに対するpublic safety capabilityを不可として管理している。
図6(e)は、public safety enableフラグ949の例を示した図である。public safety enableフラグ949は、public safetyを各UEが許可(またはon)していることを示す情報を管理している。図6(e)では、UE10Aのpublic safety enableフラグと、UE10Bのpublic safety enableフラグと、UE10Cのpublic safety enableフラグと、UE10Dのpublic safety enableフラグと、を管理している。ここでは、一例として、UE10Aに対するpublic safety enableフラグをonとして管理し、UE10Bに対するpublic safety enableフラグをonとして管理し、UE10Cに対するpublic safety enableフラグをoffとして管理し、UE10Dに対するpublic safety enableフラグを「―」として管理している。ここで、UE10Dは、public safetyを利用することができないため、「―」として管理しているが、offとして管理しても良い。public safety enableフラグ149において、「―」または、「off」として管理されているUEは、public safetyを利用できないUEとして管理される。
[1.2.3 APPサーバの構成]
図7にAPPサーバ95の機能構成を示す。なお、APPサーバ95とは、UE10Aが利用するアプリケーションにおいてサービスを提供するサーバである。
APPサーバ95は、制御部9500に、IP移動通信ネットワークインタフェース部9510と、記憶部9540とがバスを介して接続されている。
制御部9500は、UE10を制御するための機能部である。制御部9500は、記憶部9540に記憶されている各種プログラムを読みだして実行することにより各種処理を実現する。
IP移動通信ネットワークインタフェース部9510は、APPサーバ95がIP移動通信ネットワーク5に接続するための機能部である。
記憶部9540は、UE10の各種動作に必要なプログラム、データ等を記録する機能部である。記憶部9540は、例えば、半導体メモリや、HDD(Hard Disk Drive)等により構成される。さらに、記憶部9540には、ProSe ID9542とGroup ID9544が管理されている。
図8(a)に、ProSe ID9542の一例を示す。図9(a)では、APP1を利用しているUEの識別子が管理されている。図9(a)では、UE10AおよびUE10Bにおける識別子が9542の一例として、ProSe ID AおよびProSe ID Bが管理されているが、ProSe ID AおよびProSe ID Bに限るものでなく、他のUEであっても良い。
図8(b)に、Group IDの一例を示す。図8(b)では、APPサーバ95においてサービスを提供するグループIDを管理している。図8(b)では、Gruop ID9544の一例として、Group 1およびGroup2が管理されている。ここで、管理されるGroup IDはAPP1およびAPP2に限るものでなく、他のGroup IDであっても良い。
[1.3 処理の説明]
[1.3.1 近隣検出手続き]
続いて、上述した移動通信システムにおける具体的な手続きおよび処理について説明する。図9を用いて、UE10AがUE10Bを近隣検出するためにブロードキャストで送信を行う際に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含め、UE10Bは、UE10Aからの近隣検出において、in coverageフラグ147、public safety capability148、public safety enableフラグ149が含められた信号をブロードキャストで受信し、UE10Aからの信号(ブロードキャスト)に対する応答をUE10Aに送信することにより、UE10Aは、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を検出する手続きを説明する。
まず、UE10AのAPP1は、UE10Aの3GPPレイヤにExpressionコードの要求を送信する(S902)。ここで、Expressionコードとは、UE10Aを識別するための識別子である。また、Expressionコードは、UE10Aによってブロードキャストして送信され、UE10Bによって受信されることにより、UE10Aが近隣に存在することをUE10Bに検出させるための識別子である。
続いて、UE10Aの3GPPレイヤは、EPSへ問い合わせることにより、UE10AのExpressionコードの取得を行う(S904)。ここで、UE10Aは、UE10Aの識別子(ProSe ID A)を通知し、近隣検出に利用するExpressionコードを取得しても良い。なお、一度、Expressionコードの認証を受けている場合、Expressionコードの認証手続きをスキップしても良い。
次に、UE10Aの3GPPレイヤは、UE10AのExpressionコードをUE10Bのアプリケーションレイヤに通知する(S906)。一方、UE10Aの3GPPレイヤは、UE10AのExpressionコードをUE10Bへ送信する(S908)。ここで、UE10Aは、アナウンスするExpressionコードを通知する。また、UE10Bは、送信されたExpressionコードを受信し、Expressionコードをモニタリングする。なお、UE10AからUE10BへExpressionコードを送信する方法は、アプリケーションレイヤによって送受信されても良いし、3GPPレイヤによって送受信されても良い。
次に、UE10Bのアプリケーションレイヤは、UE10Bの3GPPレイヤがモニターするExpressionコードを要求する(S912).ここで、UE10Bのアプリケーションレイヤは、S908で通知されたUE10AのExpressionコードが、UE10Bの3GPPレイヤでモニターされるExpressionコードと同じであることを確認するために、Expressionコードの要求を行う。なお、UE10Bの3GPPレイヤは、このExpressionコードの要求により、UE10Aからの近隣検出するための信号の待ち受けを開始してもよい。
Expressionコードを受信したUE10Aのアプリケーションレイヤは、近隣検出の開始を3GPPレイヤに要求する(S910)。近隣検出開始の要求を受け取った3GPPレイヤは、UE10Bを近隣検出するための信号をブロードキャストで送信する(S914)。近隣検出のための信号には、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、UE10AがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。また、近隣検出を行っているUE10AのExpressionコードを含めても良い。このように、UE10Aは、UE10Aの検出を要求する信号として送信しても良い。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
なお、UE10Aの3GPPレイヤが送信する近隣検出のための信号は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
近隣検出のための信号(ブロードキャスト)を受信したUE10Bは、信号(ブロードキャスト)に含まれる近隣検出の対象であることを示すUE10BのExpressionコードを検出し、UE10Bが検出の対象であることを判断する。また、UE10Bは、信号(ブロードキャスト)に含まれるin coverageフラグ147、public safety capability148、public safety enableフラグ149を検出し、UE10Aに関する情報として格納する。
UE10Aの3GPPレイヤは、UE10AとUE10Bのカバレッジ情報を検知する(S915)。図10に、UE10AとUE10Bのカバレッジ情報を示す。図10(a)は、UE10AがIn coverageであり、UE10BがOut of coverageであることを示している。図10(b)は、UE10AがIn coverageであり、UE10BがIn coverageであることを示している。図10(c)は、UE10AがOut of coverageであり、UE10BがIn coverageであることを示している。図10(d)は、UE10AがOut of coverageであり、UE10BがOut of coverageであることを示している。図10に示すように、UE10Aにおいて、In coverageかOut of coverageであることを検出し、UE10Bからの通知により、UE10BがIn coverageかOut of coverageであることを検出することにより、UE10Aにおけるin coverageフラグ147は、図10(a)または、図10(b)または、図10(c)、図10(d)のいずれかとなる。
UE10AとUE10Bが上記の4状態のいずれかであることを検出することにより、通信路確立手続きを開始することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
ここで、UE10Aまたは、UE10Bのpublic safety capabilityが「不可」で、UE10Aまたは、UE10Bのin coverageフラグ147がout of coverageの場合、直接通信を行うことができないと判断しても良い。また、UE10Aまたは、UE10Bのpublic safety enableフラグが「off」で、UE10Aまたは、UE10Bのin coverageフラグ147がout of coverageの場合、直接通信を行うことができないと判断しても良い。
また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
UE10Aから信号(ブロードキャスト)を受信したUE10Bの3GPPレイヤは、信号(ブロードキャスト)で検出したUE10AのExpressionコードをUE10Bのアプリケーションレイヤに通知する(S916)。このとき、UE10Bは、個の通知に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。ここで、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、UE10BがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。また、近隣検出を行っているUE10BのExpressionコードや近隣検出の対象であるUE10BのExpressionコードを含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Bはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Bはpublic safetyを許可しているため、「on」として通知しても良い。
以上の手続きにより、UE10Bは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10Bは、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
ここで、UE10AはUE10Bによって検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。また、in coverageフラグ147が更新される度に送信しても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
ここで、S902からS916までの一連の手続きにおいて、UE10AとUE10Bを入れ替えて手続きを開始しても良い。つまり、UE10BのアプリケーションがExpressionコードを要求し(S902)、UE10BのExpressionコードを取得し(S904)、UE10Bの3GPPレイヤがExpressionコードをUE10Bのアプリケーションレイヤに通知し(S906)、UE10Bのアプリケーションレイヤが、UE10Bを識別するExpressionコードを送信し(S908)、UE10Aのアプリケーションレイヤが近隣検出開始の要求を送信し(S910)、UE10Aの3GPPレイヤが信号(ブロードキャスト)を送信し、UE10AのアプリケーションレイヤがモニターするExpressionコードを要求し(S912)、UE10AはUE10Bを識別するExpressionコードが含められたUE10Bを検出させるための信号をモニタリングする。UE10Bの3GPPレイヤは、近隣検出の信号(ブロードキャスト)の送信を行う(S914)。UE10Aは、この信号を受信することで、UE10Bが近隣に位置することを検出する。UE10Aの3GPPレイヤがUE10AとUE10Bのカバレッジ情報を検知し(S915)、UE10Aの3GPPレイヤがUE10AのアプリケーションレイヤにモニターしたExpressionコードを通知(S916)しても良い。なお、近隣検出の信号の送信(S914)では、近隣検出を行っているUE10BのExpressionコードを含めても良い。このように、UE10BはUE10Bの検出を要求する信号として送信しても良い。
この一連の手続きにより、UE10Aは、UE10Bの近隣を検知し、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10Aは、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
次に、UE10Bの3GPPレイヤは、UE10Aの3GPPレイヤに、近隣検出に対する応答をブロードキャストで送信しても良い(S918)。これにより、UE10Bは、UE10Aが近隣に存在すると検出したことをUE10Aに通知することができる。さらに、UE10Aはこの応答の受信することにより、UE10BがUE10Aの近隣に存在することを検知することもできる。このとき、UE10Bは、この応答に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。ここで、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
ここで、UE10BがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。また、近隣検出を行っているUE10BのExpressionコードや近隣検出の対象であるUE10BのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Bはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Bはpublic safetyを許可しているため、「on」として通知しても良い。
一方、UE10Bからの信号(ブロードキャスト)に対する応答を受信したUE10Aは、信号(ブロードキャスト)に対する応答に含まれるIn coverageフラグ147、public safety capability148、public safety enableフラグ149を検出し、格納する。
また、UE10Aは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、UE10Aは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
UE10AがUE10Bに送信するブロードキャストの送信(S914)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10BがUE10Aに送信するブロードキャストの送信(S914)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信するブロードキャストの送信(S918)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10AがUE10Bに送信するブロードキャストの送信(S918)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
以上の手続きにより、UE10B(およびUE10A)は、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10B(およびUE10A)は、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
[1.3.2 通信路確立手続き]
次に、通信路確立手続きについて示す。ここでは、近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出した。通信路確立手続きでは、UE10AとUE10Bのカバレッジ情報を利用して、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
[1.3.2.1 通信路確立手続き1]
通信路確立手続き1について説明する。本手続きでは、UE10Aは、eNB−Aに在圏し、eNB−Aは、MME−Aによって管理されている。また、UE10Bは、eNB−Bに在圏し、eNB−Bは、MME−Bによって管理されている。ここで、MME−AまたはMME−Bには、ProSeサーバ90(ProSeサーバA、ProSeサーバB)であっても良い。
[1.3.2.1.1 UE10A:In coverge UE10B:In coverage]
図11を用いて、UE10AがIn coverage、UE10BがIn coverageである1状態における通信路確立手続きについて説明する。
まず、UE10Aは、UE10Bに直接通信要求を送信する(S1002)。ここで、UE10Aは、UE10Aの管理するGroup ID(Group 1)およびProSe ID(ProSe ID A)を含める。
ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、UE10AとUE10Bが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが3GPPレイヤにUE10AとUE10B間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、UE10AとUE10Bが近隣に存在することを検出した場合であっても良い。
ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、UE10AがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45(eNB−A)から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45(eNB−A)から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、LTE Directを利用し、大容量のビデオファイルを扱うアプリケーションであれば、WLAN Directを利用するよう管理し、決定しても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、UE10Aは、Non―public safetyにおける直接通信路を確立することを要求しても良い。また、UE10Aは、直接通信路を確立するためのリソースの取得を要求しても良い。ここで、UE10Aは、直接通信路を確立するためのリソースの取得は、UE10Aが取得すると通知しても良い。
さらに、UE10Aは、Non−public safetyにおける直接通信路を確立することを示す識別子を含めても良い。また、UE10Aは、Public safetyにおける直接通信路を確立することを示す識別子を含めても良い。
ここで、UE10Aおよび、UE10Bにおいて、Public safety capability148がそれぞれ「可」になっていることを条件に、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。また、UE10Aおよび、UE10Bにおいて、Public safety enableフラグ149がそれぞれ「on」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety capability148が「不可」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety enableフラグ149が「off」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しない。 UE10Aは、UE10BがLTE Directを利用できることを検出している場合、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10BがWLAN Directを利用できることを検出している場合、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
ここで、UE10Aおよび、UE10Bにおいて、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、LTE Directの通信路の確立要求を示す識別情報を含めても良い。また、UE10Aおよび、UE10Bにおいて、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、WLAN Directの通信路の確立要求を示す識別情報を含めても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しない。
UE10Aから直接通信要求を受信したUE10Bは、直接通信要求に含められたGroup ID(Group 1)、ProSe ID(ProSe ID A)を確認する。このとき、UE10Bは、UE10AのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。 また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、LTE Directで直接通信を行うことを決定しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、WLAN Directで直接通信を行うことを決定しても良い。
直接通信要求を受信したUE10Bは、直接通信確認応答を送信する(S1004)。ここで、UE10Bは、Group ID(Group 1)、ProSe ID(ProSe ID B)を含める。このとき、UE10Aは、UE10BのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。
ここで、UE10Bは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、UE10BがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45(eNB−B)から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45(eNB−B)から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10BのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Bはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Bはpublic safetyを許可しているため、「on」として通知しても良い。
また、UE10Bは、直接通信確認応答をここで行わず、後で行っても良い。具体的には、UE10BがRRC認証直接通信承諾通知を受信した(S1024)の後や、UE10BがRRC認証直接通信完了通知を送信した(S1026)の後であっても良い。なお、直接通信確認応答を後で行う場合、UE10Bは、RRC認証直接通信要求を送信しても良い(S1006)。
次に、UE10A、UE10Bは、サービス要求手続きにより、RRC接続状態に遷移する(S1005)。なお、サービス要求手続きは、LTEにおいてデータの送受信を開始する際に、従来から利用されている手続きを利用することができる。
RRC接続状態に遷移したUE10Bは、RRC認証直接通信要求をeNB−Bに送信する(S1006)。RRC認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID(Group 1)、APPサーバ情報を含める。ProSe ID Aは、UE10Aを示すUE識別子情報であり、ProSe ID Bは、UE10Bを示すUE識別子情報である。APPサーバ情報は、直接通信を行うアプリケーションにおいてサービスを提供するサーバに関する情報である。
ここで、UE10Bは、UE10AからのNon−public safetyにおける通信リソースを示す識別子からNon―public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、UE10BはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、UE10AのIn coverageフラグ147およびUE10BのIn coverageフラグ147に応じて決定されても良い。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、eNB―BまたはMME―Bは、割り当てる通信リソースを選択しても良い。 ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
RRC認証直接通信要求を受信したeNB−Bは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知することを決定しても良い。なお、eNB−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
一方、RRC接続状態に遷移したUE10Aは、RRC認証直接通信要求をeNB−Aに送信する(S1008)。RRC認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID(Group 1)、APPサーバ情報を含める。
ここで、UE10AがIn coverage、UE10BがIn coverageである場合、UE10Aは、Non―public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、UE10AはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、UE10AのIn coverageフラグ147およびUE10AのIn coverageフラグ147に応じて決定されても良い。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、eNB―AまたはMME―Aは、割り当てる通信リソースを選択しても良い。
ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
eNB−Bは、S1−AP認証直接通信要求をMME−Bに送信する(S1010)。ここで、S1−AP認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を含める。
ここで、eNB−Bは、MME−BにNon―public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、eNB−BはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかUE10Bからの通知により決定してよい。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、MME―Bは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
S1−AP認証直接通信要求を受信したMME−Bは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、MME―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知することを決定しても良い。なお、MME−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
また、RRC認証直接通信要求を受信したeNB−Aは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Aに通知することを決定しても良い。なお、eNB−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
eNB−Aは、S1−AP認証直接通信要求をMME−Aに送信する(S1012)。ここで、S1−AP認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を含める。
ここで、eNB−Aは、MME−AにNon―public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、eNB−AはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかUE10Aからの通知により決定してよい。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、MME―Aは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
S1―AP認証直接通信要求を受信したMME−Aは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、MME―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Aに通知することを決定しても良い。なお、MME−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
次に、MMEAは直接通信を確立することを認証し、UEBがどのMMEに属しているかを識別する(S1014)。ここで、MMEAは、UEAとUEBが直接通信を確立しても良いかを確認する。また、MMEAは、MMEBを含むMME40に問合せを行い、UEBが属すMMEBを検出する。なお、各MME40がUE10Bを検出する方法は種々の方法が考えられるが、例えば、MME40において管理するUE識別子を検出することで、検出しても良い。
UEBが属すMME―Bを検出したMME−Aは、MME−BおよびeNBAにS1−AP認証直接通信の通知を送信する(S1016)。ここで、S1−AP認証直接通信の通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。ここで、送信パラメータとは、UE10AとUE10B間で直接通信を行うために必要となる情報要素のことで、例えば、通信リソースや送信範囲を示す情報(レンジクラス)を含めても良い。
MME−AからS1−AP認証直接通信の通知を受信したMME−Bは、S1−AP認証直接通信の通知を送信する(S1018)。ここで、S1−AP認証直接通信の通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。
また、S1−AP認証直接通信の通知を受信したeNB―AはUE10Aに、RRC認証直接通信承諾通知を送信する(S1020)。ここで、RRC認証直接通信承諾通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。ここで、送信パラメータとして、MME−Aが通知した送信パラメータに加え、eNB−Aにおいて、送信パラメータを加えても良い。なお、RRC認証直接通信要求(S1006)に、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知しても良い。なお、eNB−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。RRC認証直接通信承諾通知を受信したUE10Aは、直接通信で利用するGroup ID、ProSe ID A、ProSe ID B、送信パラメータを確認する。
次に、UE10Aは、RRC認証直接通信完了通知を送信する(S1022)。ここで、RRC認証直接通信完了通知には、ProSe ID A、ProSe ID B、Group IDを含める。RRC認証直接通信完了通知を送信したUE10AはUE10Bと直接通信を開始する準備を行っても良い。
一方、S1−AP認証直接通信の通知を受信したeNB―BはUE10Bに、RRC認証直接通信承諾通知を送信する(S1024)。ここで、RRC認証直接通信承諾通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。ここで、送信パラメータとして、MME―Bが通知した送信パラメータに加え、eNB−Bにおいて、送信パラメータを加えても良い。なお、RRC認証直接通信要求(S1008)に、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知しても良い。なお、eNB−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。RRC認証直接通信承諾通知を受信したUE10Bは、直接通信で利用するGroup ID、ProSe ID A、ProSe ID B、送信パラメータを確認する。
次に、UE10Bは、RRC認証直接通信完了通知を送信する(S1026)。ここで、RRC認証直接通信完了通知には、ProSe ID A、ProSe ID B、Group IDを含める。RRC認証直接通信完了通知を送信したUE10BはUE10Aと直接通信を開始する準備を行っても良い。
UE10AとUE10Bと直接通信を開始する(S1028)。このとき、UE10AとUE10BはeNB−AまたはeNB−Bから送信された送信パラメータにより、直接通信路を確立する。また、UE10Aは、UE10Bに直接通信に利用するIPアドレスを割り当てても良い。一方、UE10Bは、UE10Aに直接通信に利用するIPアドレスを割り当てても良い。
以上の手続きにより、UE10AがIn coverage、UE10BがIn coverageである1状態において通信路確立を行うことができる。
[1.3.2.1.2 UE10A:Out of coverge UE10B:Out of coverage]
次に、図11を用いて、UE10AがOut of coverage、UE10BがOut of coverageである1状態における通信路確立手続きについて説明する。UE10AがOut of coverage、UE10BがOut of coverageである場合、eNB−A、eNB−B、MME−A、MME−Bと制御情報を送受信することができない。つまり、図11において、S1005からS1026までの手続きを行わずに、通信路確立を行う。
まず、UE10AはUE10Bに直接通信要求を送信する(S1002)。このとき、直接通信要求にGroup IDとProSe ID(ProSe ID A)を含める。
ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、UE10AとUE10Bが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが3GPPレイヤにUE10AとUE10B間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、UE10AとUE10Bが近隣に存在することを検出した場合であっても良い。
ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
ここで、UE10Aは、あらかじめUE10Aが保持するリソースから直接通信路に割り当て、リソースに関する情報を含めて、直接通信路の確立要求をUE10Bに送信しても良い。
さらに、UE10AがOut of coverage、UE10BがOut of coverageであるため、UE10Aは、public safetyにおける直接通信路を確立することを決定しても良い。
さらに、UE10Aは、Public safetyにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のUEが圏外であることを検出し、この検出に基づいて、Non−public safetyを用途とした直接通信路の確立要求は送信しない。
ここで、UE10Aおよび、UE10Bにおいて、Public safety capability148がそれぞれ「可」になっていることを条件に、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。また、UE10Aおよび、UE10Bにおいて、Public safety enableフラグ149がそれぞれ「on」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety capability148が「不可」になっている場合、UE10Aは、直接通信要求を送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety enableフラグ149が「off」になっている場合、UE10Aは、直接通信要求を送信しない。直接通信要求を受信したUE10Bは、Group IDとProSe IDを確認し、UE10Aと直接通信できることを確認する。
UE10Aと直接通信できることを確認したUE10BはUE10Aに直接通信確認応答を送信する(S1004)。このとき、直接通信要求にGroup IDとProSe ID(ProSe ID B)を含める。以上により、UE10AとUE10Bは直接通信できる程度に近隣であることを検出する。
さらに、UE10Bは、UE10Aからのpublic safetyにおける通信リソースを示す情報を利用してpublic safetyにおける直接通信路を確立することを決定しても良い。
次に、UE10Aは、UE10Aと直接通信の開始を行う(S1028)。
ここで、UE10Aは、直接通信確認応答受信後(S1004)、あらかじめUE10Aが保持するリソースを直接通信路に割り当て、リソースに関する情報をUE10Bに通知しても良い。
以上の手続きにより、UE10AがOut of coverage、UE10BがOut of coverageである1状態において通信路確立を行うことができる。
[1.3.2.1.3 UE10A:Out of coverge UE10B:In coverage]
図12を用いて、UE10AがOut of coverage、UE10BがIn coverageである1状態における通信路確立手続きについて説明する。なお、本手続きでは、UE10Bは、eNB−Bに在圏し、eNB−Bは、MME−Bによって管理されている。ここで、MME−AまたはMME−Bには、ProSeサーバ90(ProSeサーバA、ProSeサーバB)であっても良い。
まず、UE10Aは、UE10Bに直接通信要求を送信する(S1202)。ここで、UE10Aは、UE10Aの管理するGroup ID(Group 1)およびProSe ID(ProSe ID A)を含める。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、UE10AとUE10Bが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが3GPPレイヤにUE10AとUE10B間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、UE10AとUE10Bが近隣に存在することを検出した場合であっても良い。 ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、UE10Aは、Public safetyにおける直接通信路を確立することを要求しても良い。また、UE10Aは、直接通信路を確立するためのリソースの取得を要求しても良い。ここで、UE10Aは、直接通信路を確立するためのリソースの取得は、UE10Aが取得すると通知しても良い。
なお、直接通信要求を送信したUE10AはUE10Bと直接通信を開始する準備を行っても良い。また、UE10AがOut of coverage、UE10BがIn coverageであるため、UE10Aは、public safetyにおける直接通信路を確立することを決定しても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、LTE Directを利用し、大容量のビデオファイルを扱うアプリケーションであれば、WLAN Directを利用するよう管理し、決定しても良い。
さらに、UE10Aは、Public safetyにおける直接通信路を確立することを要求しても良い。また、UE10Aは、直接通信路を確立するためのリソースの取得を要求しても良い。さらに、UE10Aは、Public safetyにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のUEが圏外であることを検出し、この検出に基づいて、Non−public safetyを用途とした直接通信路の確立要求は送信しない。
ここで、UE10Aおよび、UE10Bにおいて、Public safety capability148がそれぞれ「可」になっていることを条件に、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。また、UE10Aおよび、UE10Bにおいて、Public safety enableフラグ149がそれぞれ「on」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety capability148が「不可」になっている場合、UE10Aは、直接通信要求を送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety enableフラグ149が「off」になっている場合、UE10Aは、直接通信要求を送信しない。 UE10Aは、UE10BがLTE Directを利用できることを検出している場合、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10BがWLAN Directを利用できることを検出している場合、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
UE10Aから直接通信要
ここで、UE10Aおよび、UE10Bにおいて、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、LTE Directの通信路の確立要求を示す識別情報を含めても良い。また、UE10Aおよび、UE10Bにおいて、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、WLAN Directの通信路の確立要求を示す識別情報を含めても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しない。求を受信したUE10Bは、直接通信要求に含められたGroup ID(Group 1)、ProSe ID(ProSe ID A)を確認する。このとき、UE10Bは、UE10AのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。 直接通信要求を受信したUE10Aは、直接通信確認応答を送信する(S1204)。ここで、UE10Bは、Group ID(Group 1)、ProSe ID(ProSe ID B)を含める。このとき、UE10Aは、UE10BのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。
さらに、UE10Bは、UE10Aからのpublic safetyにおける通信リソースを示す情報を利用してpublic safetyにおける直接通信路を確立することを決定しても良い。
また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、LTE Directで直接通信を行うことを決定しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、WLAN Directで直接通信を行うことを決定しても良い。
次に、UE10Bは、サービス要求手続きにより、RRC接続状態に遷移する(S1206)。RRC接続状態に遷移したUE10Bは、RRC認証直接通信要求をeNB−Bに送信する(S1208)。RRC認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID(Group 1)、APPサーバ情報を含める。ProSe ID Aは、UE10Aを示すUE識別子情報であり、ProSe ID Bは、UE10Bを示すUE識別子情報である。APPサーバ情報は、直接通信を行うアプリケーションにおいてサービスを提供するサーバに関する情報である。
ここで、UE10AがIn coverage、UE10BがIn coverageである場合、UE10Bは、public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、UE10BはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、UE10AのIn coverageフラグ147およびUE10BのIn coverageフラグ147に応じて決定されても良い。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、eNB―BまたはMME―Bは、割り当てる通信リソースを選択しても良い。 ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。 RRC認証直接通信要求を受信したeNB−Bは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知することを決定しても良い。なお、eNB−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
次に、eNB−BはS1−AP認証直接通信要求をMME−Bに送信する(S1210)。ここで、S1−AP認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を含める。
ここで、eNB−Bは、MME−BにPublic safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、eNB−BはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかUE10Bからの通知により決定してよい。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、MME―Bは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
S1−AP認証直接通信要求を受信したMME−Bは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、MME―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知することを決定しても良い。なお、MME−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
次に、MME―Bは直接通信を確立することを認証する(S1212)。ここで、MMEBは、UEAとUEBが直接通信を確立しても良いかを確認する。
次に、MME−Bは、eNB−BにS1−AP認証直接通信の通知を送信する(S1214)。ここで、S1−AP認証直接通信の通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。
さらに、S1−AP認証直接通信の通知を受信したeNB―BはUE10Bに、RRC認証直接通信承諾通知を送信する(S1216)。ここで、RRC認証直接通信承諾通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。ここで、送信パラメータとして、MME−Bが通知した送信パラメータに加え、eNB−Bにおいて、送信パラメータを加えても良い。なお、RRC認証直接通信要求(S1208)に、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Bは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知しても良い。なお、eNB−Bは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。RRC認証直接通信承諾通知を受信したUE10Bは、直接通信で利用するGroup ID、ProSe ID A、ProSe ID B、送信パラメータを確認する。
次に、UE10Bは、RRC認証直接通信完了通知を送信する(S1218)。ここで、RRC認証直接通信完了通知には、ProSe ID A、ProSe ID B、Group IDを含める。RRC認証直接通信完了通知を送信したUE10AはUE10Bと直接通信を開始する準備を行っても良い。
UE10AとUE10Bと直接通信を開始する(S1220)。このとき、UE10BはeNB−Bから送信された送信パラメータをUE10Aに通知しても良い。また、UE10Bは、UE10Aに直接通信に利用するIPアドレスを割り当てても良い。
以上の手続きにより、UE10AがOut of coverage、UE10BがIn coverageである1状態において通信路確立を行うことができる。
[1.3.2.1.4 UE10A:In coverge UE10B:Out of coverage]
図13を用いて、UE10AがIn coverage、UE10BがOut of coverageである1状態における通信路確立手続きについて説明する。なお、本手続きでは、UE10Aは、eNB−Aに在圏し、eNB−Aは、MME−Aによって管理されている。ここで、MME−AまたはMME−Bには、ProSeサーバ90(ProSeサーバA、ProSeサーバB)であっても良い。
まず、UE10Aは、UE10Bに直接通信要求を送信する(S1302)。ここで、UE10Aは、UE10Aの管理するGroup ID(Group 1)およびProSe ID(ProSe ID A)を含める。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、UE10AとUE10Bが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが3GPPレイヤにUE10AとUE10B間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、UE10AとUE10Bが近隣に存在することを検出した場合であっても良い。 ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、UE10Aは、Public safetyにおける直接通信路を確立することを要求しても良い。また、UE10Aは、直接通信路を確立するためのリソースの取得を要求しても良い。ここで、UE10Aは、直接通信路を確立するためのリソースの取得は、UE10Aが取得すると通知しても良い。
なお、直接通信要求を送信したUE10AはUE10Bと直接通信を開始する準備を行っても良い。
また、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、LTE Directを利用し、大容量のビデオファイルを扱うアプリケーションであれば、WLAN Directを利用するよう管理し、決定しても良い。
さらに、UE10Aは、Non―public safetyにおける直接通信路を確立することを要求しても良い。また、UE10Aは、直接通信路を確立するためのリソースの取得は、UE10Aが取得すると通知しても良い。さらに、UE10Aは、Public safetyにおける直接通信路を確立することを示す識別子を含めても良い。また、カバレッジ情報から少なくても一方のUEが圏外であることを検出し、この検出に基づいて、Non−public safetyを用途とした直接通信路の確立要求は送信しない。
ここで、UE10Aおよび、UE10Bにおいて、Public safety capability148がそれぞれ「可」になっていることを条件に、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。また、UE10Aおよび、UE10Bにおいて、Public safety enableフラグ149がそれぞれ「on」になっている場合、UE10Aは、Public safetyの通信路確立となる直接通信要求を送信しても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety capability148が「不可」になっている場合、UE10Aは、直接通信要求を送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、Public safety enableフラグ149が「off」になっている場合、UE10Aは、直接通信要求を送信しない。
UE10Aは、UE10BがLTE Directを利用できることを検出している場合、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10BがWLAN Directを利用できることを検出している場合、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
ここで、UE10Aおよび、UE10Bにおいて、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、LTE Directの通信路の確立要求を示す識別情報を含めても良い。また、UE10Aおよび、UE10Bにおいて、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、WLAN Directの通信路の確立要求を示す識別情報を含めても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しない。
UE10Aから直接通信要求を受信したUE10Bは、直接通信要求に含められたGroup ID(Group 1)、ProSe ID(ProSe ID A)を確認する。このとき、UE10Bは、UE10AのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。
さらに、UE10AがIn coverage、UE10BがOut of coverageであるため、UE10Aは、public safetyにおける直接通信路を確立することを決定しても良い。
また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、LTE Directで直接通信を行うことを決定しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めた場合、WLAN Directで直接通信を行うことを決定しても良い。
直接通信要求を受信したUE10Bは、直接通信確認応答を送信する(S1304)。ここで、UE10Bは、Group ID(Group 1)、ProSe ID(ProSe ID B)を含める。このとき、UE10Aは、UE10BのGroup ID、ProSe IDを確認し、UE10Aと直接通信できることを確認する。
さらに、UE10Bは、UE10Aからのpublic safetyにおける通信リソースを示す情報を利用してpublic safetyにおける直接通信路を確立することを決定しても良い。
次に、UE10Aは、サービス要求手続きにより、RRC接続状態に遷移する(S1306)。RRC接続状態に遷移したUE10Aは、RRC認証直接通信要求をeNB−Aに送信する(S1308)。RRC認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID(Group 1)、APPサーバ情報を含める。RRC認証直接通信要求を送信することにより、直接通信路確立に対する許可を要求しても良い。また、RRC認証直接通信要求を送信することにより、直接通信路に対するリソースを要求することを示しても良い。
ここで、UE10AがIn coverage、UE10BがIn coverageである場合、UE10Aは、Public safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、UE10AはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかをアプリケーションに応じて管理するなどしてよい。このようにこの識別子は、アプリケーションに応じて決定されても良い。また、この識別子は、UE10AのIn coverageフラグ147およびUE10BのIn coverageフラグ147に応じて決定されても良い。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、eNB―AまたはMME―Aは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。 RRC認証直接通信要求を受信したeNB−Aは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Aに通知することを決定しても良い。なお、eNB−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
次にeNB−Aは、S1−AP認証直接通信要求をMME−Aに送信する(S1310)。ここで、S1−AP認証直接通信要求には、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を含める。
ここで、eNB−Aは、MME−AにPublic safetyで利用可能な通信リソースを要求しても良い。具体的な要求方法として、Non−pulic safetyで利用可能な通信リソースを要求するための識別子を含めても良い。また、Non−public safetyで利用可能な通信リソースではなく、Public safetyで利用可能な通信リソースを示す識別子を含めても良い。ここで、eNB−AはあらかじめPublic safetyで利用可能な通信リソースで通信をするか、Non−public safetyで利用可能な通信リソースで通信をするかUE10Aからの通知により決定してよい。
このNon−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子を利用して、MME―Aは、割り当てる通信リソースを選択しても良い。ここで、通信リソースとは、時間、周波数、符号であって良いし、その他の干渉を回避するための情報であってよい。またはこれらの時間、周波数、符号等の情報の組み合わせであっても良い。また、通信リソースに対して、送信するアンテナに関する情報や送信するために必要な送信電力情報を含んでいても良い。
S1―AP認証直接通信要求を受信したMME−Aは、Group ID、ProSe ID A、ProSe ID B、Group ID、APPサーバ情報を確認する。なお、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、MME―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Aに通知することを決定しても良い。なお、MME−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。
次に、MME―Aは直接通信を確立することを認証する(S1312)。ここで、MME―Aは、UEAとUEBが直接通信を確立しても良いかを確認する。
次に、MME―Aは、eNB−AにS1−AP認証直接通信の通知を送信する(S1314)。ここで、S1−AP認証直接通信の通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。
さらに、S1−AP認証直接通信の通知を受信したeNB―AはUE10Aに、RRC認証直接通信承諾通知を送信する(S1316)。ここで、RRC認証直接通信承諾通知には、Group ID、ProSe ID A、ProSe ID B、送信パラメータを含める。ここで、送信パラメータとして、MME−Aが通知した送信パラメータに加え、eNB−Aにおいて、送信パラメータを加えても良い。なお、RRC認証直接通信要求(S1308)に、Non−public safetyまたは、public safetyで利用可能な通信リソースを示す識別子が含まれている場合、eNB―Aは、Public safetyを用途とした通信路か、商用サービスを用途とした通信路かを識別する識別情報に基づいて通信リソースの割り当てを実行し、通信リソースに関する情報をUE10Bに通知しても良い。なお、eNB−Aは、あらかじめ、Public Safetyで利用可能な通信リソースと、Non−public safetyで利用可能な通信リソースを分けて管理し、上記決定に応じて、Public safetyで利用可能な通信リソースまたは、Non−public safetyで利用可能な通信リソースを割り当てても良い。RRC認証直接通信承諾通知を受信したUE10Aは、直接通信で利用するGroup ID、ProSe ID A、ProSe ID B、送信パラメータを確認する。
次に、UE10Aは、RRC認証直接通信完了通知を送信する(S1318)。ここで、RRC認証直接通信完了通知には、ProSe ID A、ProSe ID B、Group IDを含める。RRC認証直接通信完了通知を送信したUE10AはUE10Bと直接通信を開始する準備を行っても良い。
UE10AとUE10Bと直接通信を開始する(S1320)。このとき、UE10AはeNB−Aから送信された送信パラメータをUE10Bに通知しても良い。また、UE10Aは、UE10Bに直接通信に利用するIPアドレスを割り当てても良い。
なお、上記で説明した手続きにおいて、MME40とProSeサーバ90が異なる装置で構成された場合、MME40(MME−AまたはMME−B)の処理は、ProSeサーバ90で行っても良い。
以上の手続きにより、UE10AがIn coverage、UE10BがOut of coverageである1状態において通信路確立を行うことができる。
[1.3.2.2 通信路確立手続き2]
ここでは、通信路確立手続き1とは異なる通信路確立手続き2について説明する。通信路確立手続き1との違いは、UEが直接通信を識別するための直接通信IDを割り当てることにある。なお、通信路確立手続き2においても、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
[1.3.2.2.1 UE10A:In coverge UE10B:In coverage UE10A:In coverage UE10B:Out of coverage]
図14を用いて、UE10AがIn coverage、UE10BがIn coverageである場合の通信路確立手続きについて説明する。
なお、本手続きは、UE10AがIn coverage、UE10BがOut of coverageである場合の通信路確立手続きについても同様に利用可能である。ここで、通信路確立手続きを行うためのトリガーは、近隣検出手続きにおいて、UE10AとUE10Bが近隣であることを検出し、ユーザが直接通信を行うようアプリケーションを操作し、アプリケーションレイヤが3GPPレイヤにUE10AとUE10B間で直接通信を行うよう要求する場合であっても良い。また、通信路確立手続きのトリガーは、UE10AとUE10Bが近隣に存在することを検出した場合であっても良い。
さらに、UE10AがIn coverage、UE10BがIn coverageである場合、UE10Aは、non−public safetyにおける直接通信路を確立することを決定し、non−public safetyにおける通信路を確立するためのリソースを要求することを決定しても良い。
さらに、UE10AがIn coverage、UE10BがOut of coverageである場合、UE10Aは、public safetyにおける直接通信路を確立することを決定し、public safetyにおける通信路を確立するためのリソースを要求することを決定しても良い。
まずUE10Aは、ネットワーク認証手続きを行う(S4003)。図15を用いてネットワーク認証手続きを説明する。まず、UE10Aは、拡張したサービス要求を送信する(S5004)。ここで、UE10Aは、拡張したサービス要求に、直接通信要求、expressionコードを含めて通知する。
ここで、UE10Aは、拡張したサービス要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、UE10AがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45(eNB−A)から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45(eNB−A)から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、UE10AがIn coverage、UE10BがIn coverageである場合、UE10Aは、non−public safetyにおける直接通信路を確立することを決定し、non−public safetyにおける通信路を確立するためのリソースを要求しても良い。
さらに、UE10AがIn coverage、UE10BがOut of coverageである場合、UE10Aは、public safetyにおける直接通信路を確立することを決定し、public safetyにおける通信路を確立するためのリソースを要求しても良い。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
ここで、UE10Aおよび、UE10Bにおいて、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、LTE Directの通信路の確立要求をMME40に送信しても良い。確立要求には、LTE Directの通信路の確立要求を示す識別情報を含めても良い。また、UE10Aおよび、UE10Bにおいて、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、WLAN Directの通信路の確立要求をMME40に送信しても良い。確立要求には、WLAN Directの通信路の確立要求を示す識別情報を含めても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、LTE Directの通信路の確立要求をMME40に送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、WLAN Directの通信路の確立要求をMME40に送信しない。
拡張したサービス要求を受信したMME40は、拡張したサービス要求に直接通信要求、expressionコードを検出する。また、in coverageフラグ147が含まれている場合には、in coverageフラグ147を確認する。ここで、in coverageフラグ147には、UE10AがIn coverage、UE10BがIn coverageである場合と、UE10AがIn coverage、UE10BがOut of coverageである場合がある。
また、MME40は、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、MME40は、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
次に、MME40は、UE10AからPGW30までEPSベアラを確立する(S5006)。なお、EPSベアラの確立は、従来から利用されている手続きを利用し、UE10AとeNB45、eNB45とSGW35、SGW35とPGW30間でベアラを確立することである。
次に、MME40は、UE10Bに直接通信終端側手続きを行う(S5008)。ここで、MME40は、in coverageフラグが含められている場合であって、UE10BがOut of coverageの場合、直接通信終端手続きを行わなくても良い。一方、In coverageフラグ147が含められ、UE10AがIn coverage、UE10BがIn coverageの場合、直接通信終端手続きを行う。図16を用いて直接通信終端側手続きを説明する。まず、MME40は、UE10Bにページングを送信する(S6002)。ここで、ページングには、直接通信を示す識別子を含める。ページングを受信したUE10BはページングがUE10B宛てであることと、直接通信が要求されていることを検出する。
次に、UE10Bは拡張したサービス要求を送信する(S6004)。ここで、UE10Bは、直接通信を示す識別子を含められたため、直接通信要求を示す情報を含める。拡張したサービス要求を受信したMME40は、UE10BがUE10Aと直接通信を行うことを認証する。ここで、MME40は、UE10Bからページングの応答として拡張したサービス要求を一定時間以内に検出できない場合、UE10BはOut of coverageであると判断しても良い。UE10BがOut of coverageであると判断した場合、以降の手続きを行わず、図15におけるS5008に戻って、続くS5010の手続きを開始しても良い。続いて、MME40は、UE10BからPGW30までEPSベアラを確立する(S6006)。なお、EPSベアラの確立は、従来から利用されている手続きを利用し、UE10BとeNB45、eNB45とSGW35、SGW35とPGW30間でベアラを確立することである。
続いて、MME40は、eNB45へS1−AP直接通信確立通知を送信する(S6008)。なお、S1−AP直接通信確立通知には、直接通信有効化フラグを含める。
S1−AP直接通信確立通知を受信したeNB45は、UE10BとRRC接続再設定を行う(S6010)。eNB45はUE10とRRC接続再設定を行ったことを確認し、S1−AP直接通信確立完了通知をMME40へ送信する(S6012)。
以上の手続きにより、直接通信終端側手続きを行うことができる。S1−AP直接通信確立完了通知を受信したMME40は、eNB45へS1−AP直接通信確立通知を送信する(S5010)。なお、S1−AP直接通信確立通知には、直接通信有効化フラグを含める。
S1−AP直接通信確立通知を受信したeNB45は、UE10BとRRC接続再設定を行う(S5012)。eNB45はUE10とRRC接続再設定を行ったことを確認し、S1−AP直接通信確立完了通知をMME40へ送信する(S5014)。
以上の手続きにより、UE10AとUE10Bは直接通信を開始するためのネットワーク認証手続きを行うことができる。
次に、ネットワーク認証手続きが完了したUE10AとUE10Bは、互いに直接通信警報を送信する(S4004)。この通知により、UE10AとUE10Bは、直接通信を開始することを検出する。
次に、UE10Aは、直接通信要求をUE10Bに送信する(S4006)。
ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
ここで、UE10Aは、直接通信要求に、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含めても良い。また、in coverageフラグ147には、UE10BがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、UE10AがLTE基地局に在圏していることを検出する方法は、種々の方法が考えられるが、例えば、eNB45(eNB−A)から送信される情報を一定時間以内に受信していれば、LTE基地局に在圏していると判断し、eNB45(eNB−A)から送信される情報を一定時間以内に受信していなければ、LTE基地局に在圏していないと判断しても良い。
さらに、通信路確立要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、LTE Directを利用し、大容量のビデオファイルを扱うアプリケーションであれば、WLAN Directを利用するよう管理し、決定しても良い。
また、近隣検出を行っているUE10AのExpressionコードや近隣検出の対象であるUE10AのExpressionコードを含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知しても良い。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知しても良い。
さらに、直接通信要求には、LTE DirectまたはWLAN Directかを示す識別子を含めてもよい。この識別子に応じて直接通信路を決定しても良い。なお、この識別子の決定には、アプリケーションに応じて決定されても良い。例えば、電話のような通話のアプリケーションであれば、LTE Directを利用し、大容量のビデオファイルを扱うアプリケーションであれば、WLAN Directを利用するよう管理し、決定しても良い。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
ここで、UE10Aおよび、UE10Bにおいて、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、LTE Directの通信路の確立要求を示す識別情報を含めても良い。また、UE10Aおよび、UE10Bにおいて、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、双方が能力を有する場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しても良い。確立要求には、WLAN Directの通信路の確立要求を示す識別情報を含めても良い。
また、UE10Aまたは、UE10Bの少なくとも一方において、LTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、LTE Directの通信路の確立要求をUE10Bに送信しない。また、UE10Aまたは、UE10Bの少なくとも一方において、WLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、能力を保持しないことを検出した場合には、UE10Aは、WLAN Directの通信路の確立要求をUE10Bに送信しない。
一方、UE10Bは、直接通信要求により、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
続いて、UE10AとUE10Bはセキュリティを確保するための手続きを行う(S4008)。ここで、UE10AはUE10Bとセキュリティを確保する方法は、種々の方法が考えられるが、例えば、あらかじめUE10AとUE10B間で暗号化キーを保持し、IPsecを利用することである。
UE10AとUE10B間でセキュリティを確保した後、UE10Bは、直接通信承諾通知をUE10Aへ送信する(S4010)。直接通信承諾通知には、直接通信ID、QoS、IPアドレスを含める。ここで、直接通信IDは、UE10AとUE10Bで確立する直接通信を識別するための識別子である。また、QoSは、あらかじめ決まっているものを利用して通知しても良いし、複数の候補から選択して通知しても良い。また、IPアドレスは、種々の方法により生成する方法があるが、例えば、UE10Bにおいて、IPv6リンクローカルアドレスを生成して通知する方法がある。ここで生成したIPv6リンクローカルアドレスは、UE10Bが利用するIPアドレスとして通知しても良く、UE10Aが利用するIPアドレスとして通知しても良い。直接通信承諾通知を受信したUE10Aは、直接通信承諾通知に含まれる直接通信ID、QoS、UE10AのIPアドレスを確認する。
次に、UE10AはUE10Bへ直接通信完了通知を送信する。直接通信完了通知には、直接通信ID、QoS、UE10BのIPアドレスを含める。ここで、直接通信IDは、UE10Bが通知してきた直接通信IDである。また、QoSは、UE10Bが通知してきたQoSである。さらに、IPアドレスは、UE10Aにおいて、IPv6リンクローカルアドレスを生成して通知する。ここで生成したIPv6リンクローカルアドレスは、UE10Bが利用するIPアドレスとして通知しても良く、UE10Aが利用するIPアドレスとして通知しても良い。ただし、UE10BがUE10AのIPアドレスを通知した場合には、UE10Aは、UE10BのIPアドレスを通知する。また、UE10BがUEBのIPアドレスを通知した場合には、UE10Aは、UE10AのIPアドレスを通知する。
次に、UE10AとUE10Bは、直接通信における無線ベアラの確立を行う(S4014)。
以上の手続きにより、UE10AがIn coverage、UE10BがIn coverageである1状態において通信路確立を行うことができる。また、UE10AがIn coverage、UE10BがOut of coverageである1状態において通信路確立を行うことができる。
[1.3.2.2.2 UE10A:Out of coverge、UE10B:Out of coverage]
図14を用いて、UE10AがOut of coverage、UE10BがOut of coverageの場合における通信路確立手続きについて説明する。UE10AがOut of coverage、UE10BがOut of coverageの場合、ネットワーク認証手続き(S4003)を行わずに、直接通信警報から手続きを開始する(S4004)。
ここで、UE10Aは、あらかじめUE10Aが保持するリソースから直接通信路に割り当て、リソースに関する情報を含めて、直接通信路の確立要求をUE10Bに送信しても良い。
さらに、UE10AがOut of coverage、UE10BがOut of coverageであるため、UE10Aは、public safetyにおける直接通信路を確立することを決定しても良い。それ以外の手続きは、[1.3.2.2.1 UE10A:In coverage、UE10B:In coverage]で説明した方法と同様の方法を利用することができる。
以上の手続きにより、UE10AがOut of coverage、UE10BがOut of coverageである1状態において通信路確立を行うことができる。
[1.3.2.2.3 UE10A:Out of coverge、UE10B:In coverage]
UE10AがOut of coverage、UE10BがIn coverageの場合における通信路確立手続きについて説明する。UE10AがOut of coverage、UE10BがIn coverageの場合であっても、図14、図15で示す手続きを利用することができる。UE10AがIn coverage、UE10BがOut of coverageの場合との違いは、図15におけるUE10AがUE10Bとして動作し、UE10AがUE10Bとして動作すれば良い。 ここで、UE10AがOut of coverage、UE10BがIn coverageである場合、UE10Aは、public safetyにおける直接通信路を確立することを決定し、public safetyにおける通信路を確立するためのリソースを要求しても良い。
以上の手続きにより、UE10AがOut of coverage、UE10BがIn coverageの場合における通信路確立を行うことができる。
以上により、通信元UEおよび通信先UEがLTE基地局に在圏していることを検出することができる。通信元UEまたは通信先UEがLTE基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。
また、通信元UEおよび通信先UEがLTE基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。
[2. 第2実施形態]
続いて、第2実施形態について説明する。第2実施形態は、近隣検出手続きが異なる。本実施形態では、図1における移動通信システムの構成を利用することができるため、その詳細な説明を省略する。また、移動通信システムにおけるUEの構成やProSe Serverの構成、APPサーバの構成も同様であるため、その詳細な説明を省略する。
[2.3 処理の説明]
[2.3.1 近隣検出手続き]
図17を用いて、本実施形態における近隣検出手続きについて説明する。ここで、ProSeサーバ90は、MME40であっても良い。
まず、UE10Aは、フレンドリストを取得する(S2002)。ここでUE10Aは、あらかじめユーザの設定によりフレンドリストを保持していても良く、APPサーバ95と通信を行い、APPサーバ95からフレンドリストを取得しても良い。また、ここで取得するフレンドリストは、アプリケーションレイヤで管理される識別子情報である。識別子情報の例としては、SkypeやLINEといった個別のアプリケーションのユーザID等を用いてもよい。
次に、UE10Aのアプリケーションは、UE10Aの3GPPレイヤにExpressionコードを要求する(S2004)。この要求は、UE10がProSeのサービスを行うことに対する認証要求メッセージであっても良いし、UE10がProSeのサービスを行うことに対するサービス要求メッセージであっても良いし、UE10をProSeのサービスに登録するための登録要求メッセージであってもよい。また、対象とするProSeのサービスは、近隣端末検出に対するサービスであってもよいし、近隣通信端末との直接通信路の確立を提供するサービスであってもよいし、その両方を含んだサービスであってもよい。
Expressionコードの要求には、APPリストやフレンドリストやUE IDを含めて送信しても良い。UEIDはUE10を識別するIMSI(International Mobile Subscriber Identy)であってもよいし、アプリケーションで用いるユーザ識別情報であってもよい。ここで、UE10はAPP1において、UE10aとProSeによる通信(または近隣検出)を行うため、APPリストにはAPP1が含まれ、フレンドリストにはUE10Bが含まれる。ここで、複数のアプリケーションでProSeによる通信を行う場合、複数のアプリケーションが通知されても良い。また、複数のUEとProSeによる通信を行う場合、複数のUEの識別情報をフレンドリストに含めても良い。
なお、APPリストおよびフレンドリストはアプリケーションで管理される識別情報であってよい。
さらに、UE10Aの3GPPレイヤは、ProSeサーバ90にExpressionコードを要求する(S2006)。Expressionコードの要求には、APPリストおよびフレンドリストを含める。ここで、APPリストおよびフレンドリストはUE10AのアプリケーションがS2004で通知したAPPリストおよびフレンドリストである。
Expressionコードの要求を受信したProSeサーバ90は、Expressionコードの要求に含まれたAPPリスト(APP1)とフレンドリストを抽出する。次に、ProSeサーバ90は、APPリストを基に、APPサーバ95を探索する。APPサーバ95を探索したProSeサーバ90は、APPサーバ95と通信を行い、Expressionコードを生成するパラメータを取得する(S2008)。ここで、Expressionコードを生成するパラメータとして、例えば、Expressionコードを暗号化するための暗号化キーを取得しても良く、またExpressionコードを生成するためのアルゴリズムを取得しても良い。
続いて、ProSeサーバ90は、Expressionコードを生成する(S2010)。Expressionコードは、UE10から受信したAPPリスト142およびフレンドリスト144やAPPサーバ95から取得した情報を利用してExpressionコードを生成する。ここで、フレンドリストに含まれる通信対象UEに対するExpressionコードを生成するだけでなく、Expressionコードの要求を送信したUE10AにおけるExpressionコードを生成する。
次に、ProSeサーバ90は、Expressionコードの応答をUE10へ送信する(S2014)。ここで、ProSeサーバ90は、S2010で生成したExpressionコードを含める。また、ProSeサーバ90は、UE10が近隣端末を検出するための信号や、UE10が近隣端末に検出されるための信号を送信するための、時間や周波数に関する情報を送信しても良い。例えば、あらかじめProSeにおける近隣検出やProSeを利用する通信で利用可能な時間情報や周波数情報の候補がいくつか割り当てられており、そのうちのどれを利用するかを示す情報を通知しても良い。
なお、ProSeサーバ90は、ExpressionコードをUE10Aのみではなく、UE10Aの通信対象であるUE10Bにも通知する(S2022)。ここで、UE10Aは、アナウンスするExpressionコードを通知する。また、UE10Bは、送信されたExpressionコードを受信し、Expressionコードをモニタリングする。なお、UE10AからUE10BへExpressionコードを送信する方法は、アプリケーションレイヤによって送受信されても良いし、3GPPレイヤによって送受信されても良い。このように、UE10Aは、UE10Aの検出を要求する信号として送信する。
なお、UE10Aの3GPPレイヤが送信する近隣検出のための信号は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
また、ProSeサーバ90は、UE10Bが近隣端末を検出するための信号や、UE10Aが近隣端末に検出されるための信号を送信するための、時間や周波数に関する情報を送信しても良い。例えば、あらかじめ近隣検出やProSeを利用する通信で利用可能な時間情報や周波数情報の候補がいくつか割り当てられており、そのうちのどれを利用するかを示す情報を通知しても良い。
UE10Aは認証サーバに送信した要求に対応する応答を受信し、Expressionコードを受信する。さらにUE10Aは、アプリケーションレイヤにExressionコードを受信したことを検知させ(S2016)、アプリケーション種別を示すAPPIDとExpressionコードをマッピングして管理しておく(S2018)。
続いて、UE10Aは、ExpressionコードをUE10Bに通知する(S2024)。近隣検出のためのExpressionコードには、in coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。Expressionコードは、UE10Aによってブロードキャストして送信され、UE10Bによって受信されることにより、UE10Aが近隣に存在することをUE10Bに検出させるための識別子である。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知してもよい。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知してもよい。
また、UE10Aは、受信した情報に基づいて、ネットワークがProSeに関するサービスをサポートしているか否かを検出し、検出結果に基づいて、また、対象とするProSeのサービスは、近隣端末検出に対するサービスであってもよいし、近隣通信端末との直接通信路の確立を提供するサービスであってもよいし、その両方を含んだサービスであってもよい。
このように、接続するネットワークが近隣端末検出や近隣端末間の通信路確立などのProSeに関するサービスをサポートするか否かを示す情報をネットワークから受信し、サポートする場合にはUE10Aは要求メッセージを送信し、サポートしない場合にはUE10Aは要求メッセージを送信しないと判定しても良い。
なお、UE10Aの3GPPレイヤが送信するExpressionコードの通知は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
続いて、UE10Bは、UE10AのExpressionコードを受信する(S2026)。UE10Bは、UE10Aと直接通信を行えることを確認する。ここで、UE10Bは、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10AとUE10Bが上記の4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
UE10Aと直接通信を行えることを確認したUE10Bは、UE10AにExpressionコードの確認応答を送信しても良い。(S2028)。これにより、UE10Bは、UE10Aが近隣に存在すると検出したことをUE10Aに通知することができる。さらに、UE10Aはこの応答の受信することにより、UE10BがUE10Aの近隣に存在することを検知することもできる。この応答には、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含めても良い。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
一方、UE10Bは、UE10Aから近隣検出が行われたことをアプリケーションに通知する(S2030)。
Expressionコードの確認応答を受信したUE10Aは、UE10AとUE10B間のカバレッジ情報を検知する(S2032)。このとき、UE10Aで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
次に、UE10Aの3GPPレイヤは、UE10AおよびUE10Bのカバレッジ情報をアプリケーションレイヤに通知する(S2034)。ここで、In coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで含められるIn coverageフラグ147は、UE10Aにおいて検出したIn coverage フラグ147やUE10BにおけるExpressionコードの確認応答で含められたIn coverageフラグ147である。UE10Aの3GPPレイヤから受信したアプリケーションレイヤは、UE10AとUE10B間のカバレッジ情報を検知する(S2036)。このとき、アプリケーションレイヤで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10AはUE10Bによって検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。また、in coverageフラグ147が更新される度に送信しても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
以上の手続きにより、UE10Bは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。
ここで、S2002からS2026までとS2030の一連の手続きにおいて、UE10AとUE10Bを入れ替えて手続きを開始しても良い。つまり、UE10Aのアプリケーションはフレンドリストの取得(S2002)を行い、Expressionコードの要求(S2004)を行い、UE10Aの3GPPレイヤはExpressionコードの要求(S2006)を行い、ProSeサーバ90は、Expressionコードを生成するパラメータを取得(S2008)し、Expressionコードを生成(S2010)し、Expressionコードの応答を送信(S2014)し、UE10Bの3GPPレイヤはExpressionコードを通知(S2016)し、APPIDとExpressionコードをマッピング(S2018)し、UE10Bのアプリケーションは近隣検出の開始を要求(S2020)し、UE10Aは、Expressionコードを取得し、近隣検出を開始(S2022)し、UE10Bの3GPPレイヤはUE10Aの3GPPレイヤにExpressionコードを通知(S2024)し、Expressionコードを受信(S2026)し、近隣検出の通知(S2030)を行ってもよい。
UE10AがUE10Bに送信するブロードキャストの送信(S2024)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10BがUE10Aに送信するブロードキャストの送信(S2024)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信するブロードキャストの送信(S2028)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10AがUE10Bに送信するブロードキャストの送信(S2028)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。
以上により、通信元UEおよび通信先UEがLTE基地局に在圏していることを検出することができる。通信元UEまたは通信先UEがLTE基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。
また、通信元UEおよび通信先UEがLTE基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。
[3. 第3実施形態]
第3の実施形態について説明する。第3の実施形態と第1の実施形態、第2の実施形態との違いは、UEにおいて管理する識別子情報が異なる。また、ProSeサーバにおいて管理する識別子情報が異なる。さらに、近隣検出手続きが異なる。
[3.2 装置構成]
[3.2.1 UEの構成]
図18を用いて、第3の実施形態におけるUE10Aの構成を示す。第3の実施形態では、UE10Aは、記憶部140において管理する識別子が異なる。具体的には、記憶部140に、APP Personal ID1420、APP Group ID1440を追加で管理する。記憶部140におけるAPP Personal ID1420、APP Group ID1440以外は、第1の実施形態、第2の実施形態と同様の構成であるため、詳細な説明は省略する。
図19(a)にAPP personal ID1420の例を示す。図19(a)では、UE10Aを識別するための識別子(APP Personal ID A)やUE10Bを識別するための識別子(APP Personal ID B)が管理されている。なお、APP Personal ID1420は、アプリケーション毎に管理されていても良い。つまり、APP毎に、APP Personal ID1420を管理しても良い。
図19(b)にAPP Group ID1440の例を示す。APP Group ID1440は、UE10Aが参加するグループを識別する識別子を管理している。APP Group ID1440により、UE10Aは近隣検出や直接通信を行うUEを制限することができる。図19(b)では、APP Group ID1440は、Group 1およびGroup2が管理されている。なお、APP Group IDは複数管理可能であり、UE10Aは複数のグループに所属することができる。
[3.2.2 ProSeサーバの構成]
図20を用いて、第3の実施形態におけるProSeサーバ90の構成を示す。第3の実施形態では、ProSeサーバ90は、記憶部140において管理する識別子が異なる。具体的には、記憶部140に、APP Personal ID9420、APP Group ID9440を追加で管理する。記憶部140におけるAPP Personal ID9420、APP Group ID9440以外は、第1の実施形態、第2の実施形態と同様の構成であるため、詳細な説明は省略する。
図21(a)にAPP personal ID9420の例を示す。図21(a)では、UE10Aを識別するための識別子(APP Personal ID A)やUE10Bを識別するための識別子(APP Personal ID B)が管理されている。なお、APP Personal ID9420は、アプリケーション毎に管理されていても良い。つまり、APP毎に、APP Personal ID9420を管理しても良い。
図21(b)にAPP Group ID9440の例を示す。APP Group ID9440は、ProSeサーバ90が管理するグループを識別する識別子を管理している。APP Group ID9440により、ProSeサーバ90は近隣検出や直接通信を行うUEを制限することができる。図21(b)では、APP Group ID9440は、Group 1およびGroup2が管理されている。なお、APP Group IDは複数管理可能である。
[3.3 処理の説明]
[3.3.1 近隣検出手続き]
[3.3.1.1 近隣検出手続き1]
図22を用いて、第3実施形態における近隣検出手続きを説明する。まず、通信元であるUE10Aは、UE10Bにターゲット近隣検出要求をブロードキャストで送信する(S2502)。近隣検出要求には、APP Group ID1420、APP Personal ID(UE10A)、in coverageフラグ147、public safety capability148、public safety enable149を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
ダーゲット近隣検出要求を受信したUE10Bは、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Bは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
なお、UE10Aが送信する近隣検出要求は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。ここで、UE10AはUE10Bによって近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
UE10Aと直接通信を行えることを確認したUE10Bは、UE10Aにターゲット近隣検出応答を送信する(S2504)。この応答には、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。 また、UE10Aは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、UE10Aは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
ターゲット近隣検出応答を受信したUE10Aは、UE10AとUE10B間のカバレッジ情報を検知する(S2506)。このとき、UE10Aで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
UE10AがUE10Bに送信するブロードキャストの送信(S2502)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10BがUE10Aに送信するブロードキャストの送信(S2502)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信するブロードキャストの送信(S2504)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10AがUE10Bに送信するブロードキャストの送信(S2504)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
[3.3.1.2 近隣検出手続き2]
近隣検出手続き2について説明する。近隣検出手続き1との違いは、チャレンジ&レスポンスの認証を利用することにある。第2の実施形態では、チャレンジ&レスポンスを利用することにより、通信元UEおよび通信先UEを認証することができる。
図23を用いて、近隣検出手続き2について説明する。まず、UE10AはUE10Bにターゲット近隣検出要求を送信する(S2602)。ターゲット近隣検出には、challenge A、ProSe ID(UE10A)142、属性を示す情報、in coverageフラグ147、public safety capability148、public safety enable149を含める。
ここで、challenge Aとは、チャレンジ&レスポンス認証を行うための認証要求情報である。また、属性を示す情報とは、直接通信を行うアプリケーションの種別を示す情報である。
また、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
ダーゲット近隣検出要求を受信したUE10Bは、challenge A、ProSe ID(UE10A)、属性を示す情報、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Bは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
また、UE10Bは、UE10Aからのchallenge Aを認証し、直接通信を行えることを確認する。また、属性を示す情報を利用して、アプリケーションの種別を検出する。
なお、UE10Aが送信するターゲット近隣検出要求は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。ここで、UE10AはUE10Bによってターゲット近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
UE10Aと直接通信を行えることを確認したUE10Bは、UE10Aにターゲット近隣検出応答を送信する(S2604)。この応答には、response A、challenge B、ProSe ID(UE10B)、属性を示す情報、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。
ここで、response Aとは、UE10Aが送信したchallenge Aに対する応答であり、UE10Aからの認証要求を認証したことを示す情報である。また、challenge Bとは、チャレンジ&レスポンス認証を行うための認証要求情報である。さらに、属性を示す情報とは、直接通信を行うアプリケーションの種別を示す情報であり、UE10Aが送信した情報を利用しても良い。
また、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
また、UE10Aは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、UE10Aは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
ターゲット近隣検出応答を受信したUE10Aは、UE10AとUE10B間のカバレッジ情報を検知する(S2606)。このとき、UE10Aで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
また、UE10Aは、response Aを受信し、UE10Bに認証を受けたことを確認する。また、challenge Bを受信して、UE10Bと直接通信を行えることを確認して、認証を行う。
次に、challenge Bの認証を行ったUE10AはUE10Bにターゲット近隣検出確認応答を送信する(S2608)。ここで、UE10Aはターゲット近隣検出確認応答に、response Bを含める。response Bとは、UE10Bから送信されたchallenge Bにおける認証要求に対する応答である。
UE10Aからターゲット近隣検出確認応答を受信したUE10Bは、challenge Bに対する応答であるresponse Bを受信して、UE10Aと直接通信を行うことができることを確認する。
UE10AがUE10Bに送信するターゲット近隣検出要求(S2602)は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信するターゲット近隣検出要求(S2604)は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。 以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。
[3.3.1.3 近隣検出手続き3]
近隣検出手続き3について説明する。近隣検出手続き1、近隣検出手続き2では、特定のUEを近隣検出するターゲット近隣検出要求であったのに対し、近隣検出手続きでは、不特定のUEを近隣検出する非ターゲット近隣検出要求を行うことにある。
図24を用いて、第3実施形態における近隣検出手続き3を説明する。まず、通信元であるUE10Aは、UE10Bを含む近隣端末に非ターゲット近隣検出要求をブロードキャストで送信する(S2702)。近隣検出要求には、ProSe ID(UE10A)、in coverageフラグ147、public safety capability148、public safety enable149を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
非ダーゲット近隣検出要求を受信したUE10Bは、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Bは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
なお、UE10Aが送信する非ターゲット近隣検出要求は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。ここで、UE10AはUE10Bによって非ターゲット近隣検出要求が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
UE10Aと直接通信を行えることを確認したUE10Bは、UE10Aにターゲット近隣検出応答を送信する(S2704)。この応答には、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
また、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
非ターゲット近隣検出応答を受信したUE10Aは、UE10AとUE10B間のカバレッジ情報を検知する(S2706)。このとき、UE10Aで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
UE10AがUE10Bに送信する非ターゲット近隣検出要求(S2602)は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信する非ターゲット近隣検出要求(S2604)は、取得したリソースを利用して、ブロードキャストで送信しても、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。
以上により、通信元UEおよび通信先UEがLTE基地局に在圏していることを検出することができる。通信元UEまたは通信先UEがLTE基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。
また、通信元UEおよび通信先UEがLTE基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。
[4. 第4実施形態]
第4の実施形態について説明する。第4の実施形態と第1の実施形態、第2の実施形態、第3の実施形態との違いは、装置の構成が異なることにある。また、近隣検出を行うために、UEが直接UEを近隣検出するのではなく、移動通信事業者のネットワーク側で近隣検出し、UEに通知する方法を利用する。
[4.1 移動通信システムの概要]
図25を用いて、第4実施形態の移動通信システムの概要を説明する。本図に示すように、移動通信システム1は、UE(移動局装置)10Aと、UE(移動局装置)10Bと、PDN(Packet Data Network)20とが、RANやEPCを介して接続されて構成されている。RANとEPCは例えば、ADSL(Asymmetric Digital Subscriber Line)や光ファイバー等によって構築される。ただし、これに限らずLTE(Long Term Evolution)や、WLAN(Wireless LAN)、WiMAX(Worldwide Interoperability for Microwave Access)等の無線アクセスネットワークであっても良い。
ここで、EPCには、GMLC25、MME40、ProSeサーバ90が配置されている。なお、GMLC(Gateway Mobile Location Center)25は、UEの位置情報を取得し、管理する装置である。
ProSeサーバ90は、LCS Client27の機能を保持している。また、PDN20には、アプリケーションサーバ95が配置されている。ここで、ProSeサーバ90は、UE10AまたはUE10Bが近隣検出を行うネットワークの移動通信事業者が管理する認証サーバである。なお。ProSeサーバ90は、MME40の機能の一部として構成されても良い。
ProSeサーバ90は、LCS Clientを保持しているため、GMLC25にUEの位置情報を要求し、GMLC25からの位置情報を取得することができる。
アプリケーションサーバ95は、UE10AまたはUE10Bが利用するアプリケーション(APP1)によるサービスを提供するサーバである。
なお、ProSeサーバ90と、アプリケーションサーバ95は、PDN20に含まれて構成されてもよいし、コアネットワーク7に含まれて構成されてもよい。
UE10Aと、UE10Bは、同じ移動通信事業者網に接続していてもよいし、単一の国のなかの異なる移動通信事業者網に接続していてもよい。
PDN20は、パケットでデータのやり取りを行うネットワークサービスを提供するネットワークのことであり、例えば、インターネットやIMSなどである。
PDN20は、EPCへ有線回線等を利用して接続される。例えば、ADSL(Asymmetric Digital Subscriber Line)や光ファイバー等によって構築される。ただし、これに限らずLTE(Long Term Evolution)や、WLAN(Wireless LAN)、WiMAX(Worldwide Interoperability for Microwave Access)等の無線アクセスネットワークであっても良い。
なお、UE10AとUE10B、ProSeサーバ90、アプリケーションサーバ95、MME40は第1の実施形態で示した構成と同様の構成であるため、その説明を省略する。また、GMLC25、LCS client27は、従来から利用される装置であるため、その詳細な説明を省略する。
[4.3.1 近隣検出手続き]
図26を用いて、本実施形態における近隣検出手続きを説明する。なお、ProSeサーバ90は、MME40であっても良い。まず、UE10Aは、ProSeサーバ90へ近隣検出要求を行う(S2902)。ここで、UE10Aは、近隣検出要求に、UE10A、UE10Bの識別子を含める。UE10A、UE10Bの識別子は、ProSe ID142やAPP Personal ID1420であってよい。
次に、UE10Aは、GMLC25に位置情報の報告を行う(S2904)。ここで、位置情報の報告には、UE10Aの識別子、in coverageフラグ147、public safety capability148、public safety enable149を含める。なお、位置情報の報告は、定期的なタイミングで送信されても良いし、UE10Aが移動したことを検出して通知しても良い。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
一方、位置情報の報告を受けたGMLC25は、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、GMLC25は、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
次に、UE10Bは、GMLC25に位置情報の報告を行う(S2906)。ここで、UE10Bの識別子、in coverageフラグ147、public safety capability148、public safety enable149を含める。なお、位置情報の報告は、定期的なタイミングで送信されても良いし、UE10Bが移動したことを検出して通知しても良い。さらに、ProSeサーバ90からの問い合わせにより、位置情報を通知しても良い。UE10A、UE10Bからの報告により、GMLC25は位置情報を管理する。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
UE10Aから、S2902で近隣検出要求を受けたProSeサーバ90は、UE10A近隣検出警告を行う(S2908)。ここで、ProSeサーバ90は、UE10AとUE10Bの位置情報をGMLC25に要求し、GMLC25からUE10AとUE10Bの位置情報を検知する。ProSeサーバ90は、UE10AとUE10Bの位置情報を利用して、UE10AとUE10Bが近隣検出し、UE10AにUE10AとUE10Bが近隣であることを通知する。ここで、ProSeサーバ90は、UE10Bに、UE10AとUE10Bが近隣であることを検知しても良い。ここで、この近隣検出警告には、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を含める。ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
また、位置情報の報告を受けたGMLC25は、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、GMLC25は、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
近隣検出警告を受信したUE10Aは、UE10AとUE10B間のカバレッジ情報を検知する(S2910)。このとき、UE10Aで検出するUE10AとUE10Bのカバレッジ情報は、図10で示したように、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出し、通信路確立手続きを選択することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。
以上により、通信元UEおよび通信先UEがLTE基地局に在圏していることを検出することができる。通信元UEまたは通信先UEがLTE基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。
また、通信元UEおよび通信先UEがLTE基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。
[5. 第5実施形態]
続いて、第5実施形態について説明する。第1実施形態、第2実施形態、第3実施形態、第4実施形態と、第5実施形態との違いは、近隣検出手続きが異なる。第5実施形態における近隣検出手続きでは、近隣検出要求を送信するために、近隣検出の無線リソースを取得する。また、近隣検出要求に対する応答を送信するために、近隣検出の無線リソースを取得する。本実施形態では、図1における移動通信システムの構成を利用することができるため、その詳細な説明を省略する。また、移動通信システムにおけるUEの構成やProSe Serverの構成、APPサーバの構成も同様であるため、その詳細な説明を省略する。
[5.3 処理の説明]
[5.3.1 近隣検出手続き]
図27を用いて、近隣検出手続きについて説明する。まず、UE10Aのアプリケーションは、EPSレイヤに近隣検出要求を通知する(S3002)。ここで、近隣検出要求には、近隣検出を行う対象であるUE10Bを示す識別子を通知する。
次に、UE10AのEPSレイヤはOpen discoveryを行うか、Restrictive discoveryを行うかを決定する(S3004)。この決定には、近隣検出を行う対象に応じて決定してもよい。
[5.3.1.1 Restrictive discovery]
まず、Restrictive disocveryについて説明する。Restictive discoveryを行うことを検出したUE10Aは、まず、近隣検出を行うための無線リソースを取得する(S3006)。無線リソースを取得する方法は種々の方法が考えられるが、例えば、eNB45が定期的に送信する情報に含まれる情報から取得しても良いし、UE10AがeNB45に問い合わせることにより、取得しても良い。
次にUE10Aは、近隣検出信号をブロードキャストで送信する(S3008)。ここで、近隣検出信号には、ProSe ID(UE10B)、ProSe ID(UE10A)、in coverageフラグ147、public safety capability148、public safety enable149を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
ダーゲット近隣検出要求を受信したUE10Bは、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Bは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
なお、UE10Aが送信する近隣検出信号は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。ここで、UE10AはUE10Bによって近隣検出信号が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
さらに、UE10Aは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Aは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
一方、UE10Bは、UE10AがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがLTE Directを利用できることを検出しても良い。また、UE10Bは、UE10AがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10AがWLAN Directを利用できることを検出しても良い。
次に、UE10BのEPSレイヤは、近隣検出を受けたことをアプリケーションに通知する(S3010)。UE10Bのアプリケーションは、近隣検出に対する応答を行って良いかを確認し、近隣検出の確認をUE10BのEPSレイヤに通知する(S3012)。
近隣検出の確認を受けたUE10のEPSレイヤは、近隣検出に対する応答を送信するための無線リソースを取得する(S3014)。無線リソースを取得する方法は種々の方法が考えられるが、例えば、eNB45が定期的に送信する情報に含まれる情報から取得しても良いし、UE10AがeNB45に問い合わせることにより、取得しても良い。
次にUE10Bは、近隣検出信号をブロードキャストで送信する(S3016)。ここで、近隣検出信号には、ProSe ID(UE10B)、ProSe ID(UE10A)、in coverageフラグ147、public safety capability148、public safety enable149を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
なお、UE10Bが送信する近隣検出信号は、一定時間毎に送信されても良い。また、in coverageフラグ147が更新される度に送信しても良い。ここで、UE10AはUE10Bによって近隣検出信号が検出された後でも、近隣検出のための信号を、一定時間毎に送信し続けても良い。in coverageフラグ147は、送信時点での、圏内または、圏外の状況に応じて、更新して検出要求信号に含めて送信する。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
一方、UE10Aは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、UE10Aは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
近隣検出信号をブロードキャストで受信したUE10Aは、UE10AとUE10Bのカバレッジ情報を検出する(S3017)。つまり、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Aは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
次に、UE10AのEPSレイヤは、UE10Aのアプリケーションに近隣検出の確認を通知する(S3018)。ここで、近隣検出の確認には、ProSe ID(UE10B)を含める。
UE10AがUE10Bに送信するブロードキャストの送信(S3008)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10BがUE10Aに送信するブロードキャストの送信(S3008)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
さらに、UE10BがUE10Aに送信するブロードキャストの送信(S3016)は、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。また逆に、UE10AがUE10Bに送信するブロードキャストの送信(S3016)する場合、あらかじめ取得した通信リソースを利用して、ユニキャストで送信しても良い。ここで、取得した通信リソースとは、特定のUEに検出させるために利用することができる通信リソースであり、eNB45またはMME40によって明示的に通知されることにより割り当てられても良いし、あらかじめUE10AまたはUE10Bに通知されているものを利用しても良い。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。
[5.3.1.2 Open discovery]
Open disocveryについて説明する。Open disocveryでは、近隣検出信号をブロードキャストで近隣検出の対象であるUEに問合せる形で送信するのではなく、近隣検出の対象であるUEが定期的に近隣検出信号を送信し、その近隣検出信号を受信することで、近隣検出を行うことができる。Open discoveryを行うことを決定したUE10AのEPSレイヤは、近隣検出の無線リソースを取得する(S3020)。ここで、近隣検出の無線リソースは、UE10Bが定期的に送信する近隣検出信号に関する情報である。なお、この無線リソースを取得する方法は種々の方法が考えられるが、例えば、eNB45が定期的に送信する情報に含まれる情報から取得しても良いし、UE10AがeNB45に問い合わせることにより、取得しても良い。
続いて、UE10Aは、S3020で受信した無線リソースを利用して、近隣検出の対象であるUE10Bを検出する(S3022)。なお、UE10Bが送信する近隣検出信号には、ProSe ID(UE10B)、in coverageフラグ147、public safety capability148、public safety enable149が含まれている。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
ここで、in coverageフラグ147には、UE10AがLTE基地局に在圏していること(In coverage)(または、在圏していないこと(Out of coverage))を示す情報を含める。
また、public safety capability148は、public safetyを機能として保持していることを示す情報であり、ここでは、UE10Aはpublic safetyの機能を保持するため、「可」として通知する。
さらに、public safety enableフラグ149は、public safetyを利用することを許可することを示す情報であり、ここでは、UE10Aはpublic safetyを許可しているため、「on」として通知する。
近隣検出信号(ブロードキャスト)を受信したUE10Aは、UE10AとUE10Bのカバレッジ情報を検出する(S3017)。つまり、UE10Bのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Aは、UE10Bと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Bのpublic safety capabilityが「不可」で、UE10Bのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
さらに、UE10Bは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。また、UE10Bは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報を含めても良い。
一方、UE10Aは、UE10BがLTE Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがLTE Directを利用できることを検出しても良い。また、UE10Aは、UE10BがWLAN Directで直接通信路を確立することができる能力情報などを示す識別情報により、UE10BがWLAN Directを利用できることを検出しても良い。
近隣検出信号をブロードキャストで受信したUE10Aは、UE10AとUE10Bのカバレッジ情報を検出する(S3023)。つまり、UE10Aのin coverageフラグ147、public safety capability148、public safety enableフラグ149を確認する。
UE10Aは、UE10Aと4状態のいずれかであることを検出することができる。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のいずれかであることを検出することができる。
ここで、UE10Aのpublic safety capabilityが「不可」で、UE10Aのin coverageフラグがout of coverageの場合、直接通信を行うことができないと判断しても良い。また、public safety enableフラグが「off」で、out of coverageの場合、直接通信を行うことができないと判断しても良い。
次に、UE10AのEPSレイヤは、UE10Aのアプリケーションに近隣検出の確認を通知する(S3024)。ここで、近隣検出の確認には、ProSe ID(UE10B)を含める。
以上の手続きにより、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出することができる。つまり、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態の4状態のうち、いずれかであることを検出することができる。
近隣検出手続きにおいて、UE10Aは、UE10AおよびUE10Bにおけるカバレッジ情報を検出し、カバレッジ情報に基づいて、通信路確立手続きを行う。具体的には、UE10AがIn coverage、UE10BがIn coverageである1状態と、UE10AがOut of coverage、UE10BがIn coverageである1状態と、UE10AがIn coverage、UE10BがOut of coverageである1状態と、UE10AがOut of coverage、UE10BがOut of coverageである1状態のそれぞれの状態で、異なる通信路確立手続きを行う。通信路確立手続きは、第一の実施形態で示した方法を同様に利用可能であるため、その詳細な説明は省略する。
以上により、通信元UEおよび通信先UEがLTE基地局に在圏していることを検出することができる。通信元UEまたは通信先UEがLTE基地局に在圏する場合、移動通信事業者の制御の元、通信路確立手続きを行うことができる。
また、通信元UEおよび通信先UEがLTE基地局に在圏しない場合、通信路確立の度に、移動通信事業者の認証を得ることなく、通信路確立手続きを行うことができる。
[6.1.1.変形例1]
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。
また、各実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、CPU等を制御するプログラム(コンピュータを機能させるプログラム)である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置(例えば、RAM)に蓄積され、その後、各種ROMやHDDの記憶装置に格納され、必要に応じてCPUによって読み出し、修正・書き込みが行なわれる。
ここで、プログラムを格納する記録媒体としては、半導体媒体(例えば、ROMや、不揮発性のメモリカード等)、光記録媒体・光磁気記録媒体(例えば、DVD(Digital Versatile Disc)、MO(Magneto Optical Disc)、MD(Mini Disc)、CD(Compact Disc)、BD等)、磁気記録媒体(例えば、磁気テープ、フレキシブルディスク等)等のいずれであってもよい。また、ロードしたプログラムを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、本発明の機能が実現される場合もある。
また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバコンピュータの記憶装置も本発明に含まれるのは勿論である。
また、上述した実施形態における各装置の一部又は全部を典型的には集積回路であるLSI(Large Scale Integration)として実現しても良い。各装置の各機能ブロックは個別にチップ化しても良いし、一部、または全部を集積してチップ化しても良い。また、集積回路化の手法はLSIに限らず専用回路、または汎用プロセッサで実現しても良い。また、半導体技術の進歩によりLSIに代替する集積回路化の技術が出現した場合、当該技術による集積回路を用いることも可能であることは勿論である。
また、上述した実施形態においては、無線アクセスネットワークの例としてLTEと、WLAN(例えば、IEEE802.11a/b/n等)とについて説明したが、WLANの代わりにWiMAXによって接続されても良い。