特許 6571732 近接データパスセットアップを最適化するための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6571732

(24)【登録日】2019年8月16日

(45)【発行日】2019年9月4日

(54)【発明の名称】近接データパスセットアップを最適化するための方法および装置

(51)【国際特許分類】

   H04W 8/00 20090101AFI20190826BHJP

   H04W 88/06 20090101ALI20190826BHJP

   H04W 92/18 20090101ALI20190826BHJP

   H04W 84/12 20090101ALI20190826BHJP

   H04W 12/04 20090101ALI20190826BHJP

   H04W 76/14 20180101ALI20190826BHJP

【ＦＩ】

   H04W8/00 110

   H04W88/06

   H04W92/18

   H04W84/12

   H04W12/04

   H04W76/14

【請求項の数】6

【外国語出願】

【全頁数】66

(21)【出願番号】特願2017-167578(P2017-167578)

(22)【出願日】2017年8月31日

(62)【分割の表示】特願2015-509199(P2015-509199)の分割

【原出願日】2013年4月26日

(65)【公開番号】特開2017-225188(P2017-225188A)

(43)【公開日】2017年12月21日

【審査請求日】2017年10月2日

(31)【優先権主張番号】61/639,352

(32)【優先日】2012年4月27日

(33)【優先権主張国】US

(31)【優先権主張番号】61/645,335

(32)【優先日】2012年5月10日

(33)【優先権主張国】US

(31)【優先権主張番号】61/645,282

(32)【優先日】2012年5月10日

(33)【優先権主張国】US

(31)【優先権主張番号】61/653,769

(32)【優先日】2012年5月31日

(33)【優先権主張国】US

(31)【優先権主張番号】61/720,640

(32)【優先日】2012年10月31日

(33)【優先権主張国】US

【前置審査】

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】ラヴィクマール ブイ．プラガダ

(72)【発明者】

【氏名】サード アーマッド

(72)【発明者】

【氏名】バラジ ラゴサマン

(72)【発明者】

【氏名】ユリシーズ オルベラ−ヘルナンデス

(72)【発明者】

【氏名】デン ジュオロン

(72)【発明者】

【氏名】パスカル エム．アドジャクプル

(72)【発明者】

【氏名】グレゴリー エス．シュテルンベルク

(72)【発明者】

【氏名】ワン グワンジョウ

(72)【発明者】

【氏名】アレクサンダー レズニック

【審査官】 古市 徹

(56)【参考文献】

【文献】 特開２００９−１１１７７６（ＪＰ，Ａ）

【文献】 特開２００９−０１７５５９（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／０２５８３２７（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１１／０１０３３１８（ＵＳ，Ａ１）

【文献】 国際公開第２０１１／０５２１３６（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

２重無線アクセス技術（２重ＲＡＴ）ワイヤレス送受信ユニット（ＷＴＲＵ）により実施される方法であって、
前記２重ＲＡＴ ＷＴＲＵにより、セルラＲＡＴで、セルラネットワークへ登録メッセージを送信することであり、前記登録メッセージは、前記２重ＲＡＴ ＷＴＲＵと関連付けられた無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス識別（ＩＤ）を含んでいる、ことと、
前記２重ＲＡＴ ＷＴＲＵにより、前記セルラＲＡＴで前記セルラネットワークから、前記２重ＲＡＴ ＷＴＲＵが第１のＷＴＲＵと直接に通信することを許可する応答メッセージを受信することと、
前記２重ＲＡＴ ＷＴＲＵにより、前記セルラＲＡＴで前記セルラネットワークから、ＷＬＡＮのためのセキュリティ鍵を含む補助情報を受信することであり、前記２重ＲＡＴ ＷＴＲＵが前記第１のＷＴＲＵに接近しているという判定に基づいて、前記補助情報が直接通信エンティティを介して受信される、ことと、
前記２重ＲＡＴ ＷＴＲＵにより、ＷＬＡＮ ＲＡＴで、前記ＷＬＡＮデバイスＩＤおよび前記ＷＬＡＮのための前記セキュリティ鍵を使用して直接発見を実行することと、
を含む、方法。

【請求項2】

前記セルラＲＡＴは前記セルラネットワークのためのものであり、前記ＷＬＡＮ ＲＡＴは前記ＷＬＡＮのためのものである、請求項１に記載の方法。

【請求項3】

前記セルラネットワークは３ＧＰＰ（third generation partnership project）ネットワークであり、前記ＷＬＡＮは８０２．１１ネットワークである、請求項１に記載の方法。

【請求項4】

２重無線アクセス技術（２重ＲＡＴ）ワイヤレス送受信ユニット（ＷＴＲＵ）であって、
セルラＲＡＴで、セルラネットワークへ登録メッセージを送信する手段であり、前記登録メッセージは、前記２重ＲＡＴ ＷＴＲＵと関連付けられた無線ローカルエリアネットワーク（ＷＬＡＮ）デバイス識別（ＩＤ）を含んでいる、手段と、
前記セルラＲＡＴで前記セルラネットワークから、前記２重ＲＡＴ ＷＴＲＵが第１のＷＴＲＵと直接に通信することを許可する応答メッセージを受信する手段と、
前記セルラＲＡＴで前記セルラネットワークから、ＷＬＡＮのためのセキュリティ鍵を含む補助情報を受信する手段であり、前記２重ＲＡＴ ＷＴＲＵが前記第１のＷＴＲＵに接近しているという判定に基づいて、前記補助情報が直接通信エンティティを介して受信される、手段と、
ＷＬＡＮ ＲＡＴで、前記ＷＬＡＮデバイスＩＤおよび前記ＷＬＡＮのための前記セキュリティ鍵を使用して直接発見を実行する手段と、
を備えた、２重ＲＡＴ ＷＴＲＵ。

【請求項5】

前記セルラＲＡＴは前記セルラネットワークのためのものであり、前記ＷＬＡＮ ＲＡＴは前記ＷＬＡＮのためのものである、請求項４に記載の２重ＲＡＴ ＷＴＲＵ。

【請求項6】

前記セルラネットワークは３ＧＰＰ（third generation partnership project）ネットワークであり、前記ＷＬＡＮは８０２．１１ネットワークである、請求項４に記載の２重ＲＡＴ ＷＴＲＵ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、近接データパスセットアップを最適化するための方法および装置に関する。

【背景技術】

【0002】

関連出願の相互参照
本出願は、２０１２年４月２７日に出願された米国特許仮出願第６１／６３９，３５２号明細書、２０１２年５月１０日に出願された米国特許仮出願第６１／６４５，３３５号明細書、２０１２年５月１０日に出願された米国特許仮出願第６１／６４５，２８２号明細書、２０１２年５月３１日に出願された米国特許仮出願第６１／６５３，７６９号明細書、および２０１２年１０月３１日に出願された米国特許仮出願第６１／７２０，６４０号明細書の利益を主張するものであり、これらの仮出願の内容の全体は参照により本明細書に組み込まれる。

【0003】

デバイス同士のデバイス間通信（Ｄ２Ｄ）は、Ｄ２Ｄ対応デバイスが、その付近の他のピアデバイスの存在と、それらのデバイスが提供および／または参与するサービスとに気付いた後で、行うことができる。この発見プロセスは、データ通信プロセス自体とは別個のものと見なすことができる。無線の観点からは、デバイス発見は、通信と比較して、異なる周波数において行うことができる可能性がある（この場合、発見周波数におけるＤ２Ｄリンクの品質の判断が、対応するＤ２Ｄデータリンク周波数の判断に変換されなければならないであろう）。デバイス間の物理リンクを介した発見があり、その後に、直接物理Ｄ２Ｄリンクを含まないローカルパスを介した通信が続くと想定することができる。

【0004】

近年、直接Ｄ２Ｄ通信が重要性を増しつつある。このため、新しいノードおよびインタフェースを追加することによって現在の第３世代パートナーシッププロジェクト（３ＧＰＰ）アーキテクチャを変更することが必要とされる。オペレータネットワーク内から、または３ＧＰＰネットワーク外部の第三者アプリケーションによって、Ｄ２Ｄ通信の協調を容易にするアーキテクチャが必要である。サービス発見が完了すると、ユニキャストと、マルチキャスト／ブロードキャストとの両方のＤ２Ｄセッションで、呼確立および維持のためのプロシージャが必要である。サービス発見および呼確立プロシージャはまた、Ｄ２Ｄサービスが市場で勢いをつけるためのオペレータ間Ｄ２Ｄ通信を可能にするためにも必要である。

【発明の概要】

【0005】

近接データパスセットアップを最適化するための方法および装置について述べる。非アクセス層（ＮＡＳ）レイヤにおける様々なポリシ、規則、および許可を使用して、近接サービスが可能かどうか、また可能ならどの近接サービスが可能かを決定することができる。ポリシおよび許可がどのようにネットワーク中で構成されるかを決定するためのプロシージャを実施することができる。ポリシおよび許可は、様々なネットワークノードにまたがって展開することができる。

【0006】

最適化された近接データパスの確立をトリガするためのＮＡＳメッセージおよびプロシージャについて述べる。加えて、最適化された近接データパスを可能にするのに使用できる新しいデータ通信レイヤ代替形態についても述べる。

【図面の簡単な説明】

【0007】

添付の図面と共に例として提供する後続の記述から、より詳細な理解を得ることができる。

【図1A】１または複数の開示される実施形態をその中で実現できる例示的な通信システムを示す図である。

【図1B】図１Ａに示す通信システム内で使用できる例示的なワイヤレス送受信ユニット（ＷＴＲＵ）を示す図である。

【図1C】図１Ａに示す通信システム内で使用できる例示的な無線アクセスネットワークおよび例示的なコアネットワークを示す図である。

【図2A】相互に近接する２つのＷＴＲＵによる、それぞれの進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）を介した、コアネットワーク（ＣＮ）ノード（例えばサービングゲートウェイ（ＳＧＷ）またはパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ））への通信の例を示す図である。

【図2B】ｅＮＢを介してローカルにルーティングされる２つのＷＴＲＵ間の近接通信のためのデータパスの例を示す図である。

【図2C】直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ（すなわちｅｎｄ−ｔｏ−ｅｎｄ）データパスの例を示す図である。

【図3A】中間ノードが含まれない直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを確立する例を示す図である。

【図3B】ｅＮＢまたはホームｅＮＢ（ＨｅＮＢ）の中を通るＷＴＲＵ−ｔｏ−ＷＴＲＵベアラの例を示す図である。

【図3C】通常の進化型パケットシステム（ＥＰＳ）ベアラを使用するパス中のｅＮＢまたはＨｅＮＢを介してＷＴＲＵ−ｔｏ−ＷＴＲＵ接続を確立する例を示す図である。

【図3D】２つのＷＴＲＵが２つの異なるｅＮＢまたはＨｅＮＢのカバレッジ下にあるときに、ＳＧＷの中を通るｅｎｄ−ｔｏ−ｅｎｄベアラを確立する例を示す図である。

【図4】直接モデルの要約図としてのデバイスｔｏデバイス（デバイス間（Ｄ２Ｄ））アーキテクチャを示す図である。

【図5】直接モデルの展開図としてのＤ２Ｄアーキテクチャを示す図である。

【図6】Ｄ２Ｄプロトコルスタック図である。

【図7】通常のＥＰＳベアラと、Ｄ２Ｄ ＥＰＳベアラとを対比させて示す図である。

【図8】ｅＮＢ内ユニキャストＤ２Ｄサービス要求プロシージャの流れ図である。

【図9A】ｅＮＢ間／モビリティ管理エンティティ（ＭＭＥ）間Ｄ２Ｄサービス要求プロシージャの信号流れ図である。

【図9B】ｅＮＢ間／モビリティ管理エンティティ（ＭＭＥ）間Ｄ２Ｄサービス要求プロシージャの信号流れ図である。

【0008】

【図10A】オペレータ間ユニキャストの場合のサービス要求プロシージャの信号流れ図である。

【図10B】オペレータ間ユニキャストの場合のサービス要求プロシージャの信号流れ図である。

【図11】複数のインタフェースにわたってセットアップされたＥＰＳベアラの例を示す図である。

【図12】ベアラ確立プロシージャの例示的な信号流れ図である。

【図13】ＷＴＲＵ−ｔｏ−ＷＴＲＵパケットデータネットワーク（ＰＤＮ）接続のためのＰＤＮ接続セットアッププロシージャの例示的な信号流れ図である。

【図14】ＷＴＲＵ−ｔｏ−ＷＴＲＵ専用ベアラ確立プロシージャの例示的な信号流れ図である。

【図15】ＳＧＷのケースのＰＤＮ接続セットアッププロシージャの例示的な信号流れ図である。

【図16A】一意のＤ２Ｄ識別子を使用するｅＮＢ内、ＭＭＥ内２重無線アクセス技術（ＲＡＴ）の場合の例示的なサービス要求プロシージャの信号流れ図である。

【図16B】一意のＤ２Ｄ識別子を使用するｅＮＢ内、ＭＭＥ内２重無線アクセス技術（ＲＡＴ）の場合の例示的なサービス要求プロシージャの信号流れ図である。

【図17】近接サービスを求める要求をＷＴＲＵが開始する例を示す図である。

【図18】近接サービスに関するポリシおよび課金制御モデルを示す図である。

【図19】ネットワークベースの近接トリガプロシージャの信号流れ図である。

【図20】特定のアプリケーションについての近接情報の登録および交換を示す図である。

【図21A】セルラトリガ式デバイス発見を伴うｅＮＢ内、ＭＭＥ内２重ＲＡＴの場合の例示的なサービス要求プロシージャの信号流れ図である。

【図21B】セルラトリガ式デバイス発見を伴うｅＮＢ内、ＭＭＥ内２重ＲＡＴの場合の例示的なサービス要求プロシージャの信号流れ図である。

【図22A】ｅＮＢ内ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。

【図22B】ｅＮＢ内ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。

【図23A】ｅＮＢ間ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。

【図23B】ｅＮＢ間ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。

【図24】パケットデータ収束プロトコル（ＰＤＣＰ）レイヤまでのアクセス層データプレーンプロトコルスタックレイヤがＷＴＲＵとｅＮＢとの間で終端するときの、例示的なプロトコルアーキテクチャを示す図である。

【図25】Ｄ２Ｄローカルパスについての例示的なデータプレーンプロトコルスタックを示す図である。

【発明を実施するための形態】

【0009】

図１Ａに、１または複数の開示される実施形態をその中で実現できる例示的な通信システム１００を示す。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを複数のワイヤレスユーザに提供する多元接続システムとすることができる。通信システム１００は、複数のワイヤレスユーザが、ワイヤレス帯域幅を含めたシステムリソースの共有を通してこのようなコンテンツにアクセスするのを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）など、１または複数のチャネルアクセス方法を採用することができる。

【0010】

図１Ａに示すように、通信システム１００は、ワイヤレス送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、無線アクセスネットワーク（ＲＡＮ）１０４と、コアネットワーク１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでよいが、開示する実施形態が任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を企図することは理解されるであろう。各ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス環境で動作および／または通信するように構成された任意のタイプのデバイスとすることができる。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、ワイヤレス信号を送信および／または受信するように構成されてよく、ユーザ機器（ＵＥ）、移動局、固定またはモバイルの加入者ユニット、ページャ、セルラ電話機、パーソナルディジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、ワイヤレスセンサ、消費者電子機器などを含んでよい。

【0011】

通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでよい。各基地局１１４ａ、１１４ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つとワイヤレスにインタフェースして、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２など、１または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスとすることができる。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバステーション（ＢＴＳ）、Ｎｏｄｅ−Ｂ、進化型ＮｏｄｅＢ（ｅＮＢ）、Ｈｏｍｅ ＮｏｄｅＢ（ＨＮＢ）、Ｈｏｍｅ ｅＮＢ（ＨｅＮＢ）、サイトコントローラ、アクセスポイント（ＡＰ）、ワイヤレスルータなどとすることができる。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として描かれているが、基地局１１４ａ、１１４ｂが任意の数の相互接続された基地局および／またはネットワーク要素を含んでよいことは理解されるであろう。

【0012】

基地局１１４ａはＲＡＮ１０４の一部とすることができ、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）や無線ネットワークコントローラ（ＲＮＣ）や中継ノードなど、他の基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理領域内でワイヤレス信号を送信および／または受信するように構成されてよく、この地理領域はセル（図示せず）と呼ばれることもある。セルはさらに、セルセクタに分割することができる。例えば、基地局１１４ａに関連付けられたセルを、３つのセクタに分割することができる。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタにつき１つの送受信機を備えることができる。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用することができ、したがって、セルの各セクタにつき複数の送受信機を利用することができる。

【0013】

基地局１１４ａ、１１４ｂは、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数と通信することができ、エアインタフェース１１６は、任意の適切なワイヤレス通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立することができる。

【0014】

より具体的には、上記のように、通信システム１００は、多元接続システムとすることができ、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなど、１または複数のチャネルアクセス方式を採用することができる。例えば、ＲＡＮ１０４中の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装することができ、これにより、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１６を確立することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでよい。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）および／または高速アップリンク（ＵＬ）パケットアクセス（ＨＳＵＰＡ）を含んでよい。

【0015】

別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＴＲＡ（Ｅ−ＵＴＲＡ）などの無線技術を実装することができ、これにより、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立することができる。

【0016】

他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちワールドワイドインターオペラビリティフォーマイクロウェーブアクセス（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００エボリューションデータオプティマイズド（ＥＶ−ＤＯ）、暫定標準２０００（ＩＳ−２０００）、暫定標準９５（ＩＳ−９５）、暫定標準８５６（ＩＳ−８５６）、グローバルシステムフォーモバイルコミュニケーションズ（ＧＳＭ（登録商標））、エンハンストデータレートフォーＧＳＭエボリューション（ＥＤＧＥ）、ＧＳＭ／ＥＤＧＥ ＲＡＮ（ＧＥＲＡＮ）などの無線技術を実装することができる。

【0017】

図１Ａ中の基地局１１４ｂは、例えばワイヤレスルータ、ＨＮＢ、ＨｅＮＢ、またはＡＰとすることができ、事業所、家庭、車両、キャンパスなどの局所化されたエリア中でのワイヤレス接続性を容易にするために任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、ワイヤレスパーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立することができる。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有することができる。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることは必要とされなくてよい。

【0018】

ＲＡＮ１０４は、コアネットワーク１０６と通信してよく、コアネットワーク１０６は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１または複数に提供するように構成された、任意のタイプのネットワークとすることができる。例えば、コアネットワーク１０６は、呼制御、料金請求サービス、モバイル位置ベースサービス、前払い電話、インターネット接続性、ビデオ配信などを提供することができ、かつ／または、ユーザ認証など、高レベルのセキュリティ機能を実施することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６が、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的または間接的に通信してもよいことは理解されるであろう。例えば、コアネットワーク１０６は、Ｅ−ＵＴＲＡ無線技術を利用しているであろうＲＡＮ１０４に接続されるのに加えて、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。

【0019】

コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての働きをすることができる。ＰＳＴＮ１０８は、プレーンオールドテレフォンサービス（ＰＯＴＳ）を提供する回路交換電話網を含んでよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート中の、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスの地球規模のシステムを含んでよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線またはワイヤレス通信ネットワークを含んでよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴまたは異なるＲＡＴを採用するであろう１または複数のＲＡＮに接続された、別のコアネットワークを含んでよい。

【0020】

通信システム１００中のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつかまたは全ては、マルチモード能力を備えることができる。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々のワイヤレスリンクを介して種々のワイヤレスネットワークと通信するために、複数の送受信機を備えることができる。例えば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用するであろう基地局１１４ａと、また、ＩＥＥＥ８０２無線技術を採用するであろう基地局１１４ｂと、通信するように構成されてよい。

【0021】

図１Ｂに、図１Ａに示した通信システム１００内で使用できる例示的なＷＴＲＵ１０２を示す。図１Ｂに示すように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送受信要素（例えばアンテナ）１２２、スピーカ／マイクロホン１２４、キーパッド１２６、表示装置／タッチパッド１２８、非取外し可能メモリ１３０、取外し可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および周辺装置１３８を備えてよい。ＷＴＲＵ１０２が、実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを備えてよいことは理解されるであろう。

【0022】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、マイクロプロセッサ、ＤＳＰコアに関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、集積回路（ＩＣ）、状態機械などとすることができる。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２がワイヤレス環境で動作できるようにする他の任意の機能を実施することができる。プロセッサ１１８は送受信機１２０に結合されてよく、送受信機１２０は送受信要素１２２に結合されてよい。図１Ｂではプロセッサ１１８と送受信機１２０とを別々のコンポーネントとして描いているが、プロセッサ１１８と送受信機１２０とは共に電子パッケージまたはチップ中で統合されてもよい。

【0023】

送受信要素１２２は、エアインタフェース１１６を介して基地局（例えば基地局１１４ａ）との間で信号を送信または受信するように構成されてよい。例えば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナとすることができる。別の実施形態では、送受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された、エミッタ／検出器とすることができる。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号の両方を送受信するように構成されてよい。送受信要素１２２は、任意の組合せのワイヤレス信号を送信および／または受信するように構成されてよい。

【0024】

加えて、図１Ｂでは送受信要素１２２が単一の要素として描かれているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を備えてよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用することができる。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６を介してワイヤレス信号を送受信するために、２つ以上の送受信要素１２２（例えば複数のアンテナ）を備えることができる。

【0025】

送受信機１２０は、送受信要素１２２によって送信されることになる信号を変調し、送受信要素１２２によって受信された信号を復調するように構成されてよい。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有することができる。したがって、送受信機１２０は、ＷＴＲＵ１０２が複数のＲＡＴ（例えばＵＴＲＡおよびＩＥＥＥ８０２．１１など）を介して通信できるようにするために、複数の送受信機を備えることができる。

【0026】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８（例えば液晶表示装置（ＬＣＤ）表示ユニットもしくは有機発光ダイオード（ＯＬＥＤ）表示ユニット）に結合されてよく、これらからユーザ入力データを受け取ることができる。プロセッサ１１８はまた、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、表示装置／タッチパッド１２８にユーザデータを出力することができる。加えて、プロセッサ１１８は、非取外し可能メモリ１３０および／または取外し可能メモリ１３２など、任意のタイプの適切なメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。非取外し可能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含んでよい。取外し可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアディジタル（ＳＤ）メモリカードなどを含んでよい。他の実施形態では、プロセッサ１１８は、サーバやホームコンピュータ（図示せず）上のメモリなど、ＷＴＲＵ１０２上に物理的に位置しないメモリからの情報にアクセスすること、およびそのようなメモリにデータを記憶することができる。

【0027】

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２中の他のコンポーネントへの電力を分配および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスとすることができる。例えば、電源１３４は、１または複数の乾電池バッテリ（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含んでよい。

【0028】

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されてよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度と緯度）を提供するように構成されてよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６を介して位置情報を受信することができ、かつ／または、２つ以上の近隣基地局から受信されている信号のタイミングに基づいてその位置を決定することができる。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、任意の適切な位置決定方法を用いて位置情報を取得することができる。

【0029】

プロセッサ１１８はさらに、他の周辺装置１３８にも結合されてよく、周辺装置１３８は、追加の特徴、機能、および／または有線もしくはワイヤレス接続性をもたらす、１または複数のソフトウェアおよび／またはハードウェアモジュールを含んでよい。例えば、周辺装置１３８は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、ディジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザなどを含んでよい。

【0030】

図１Ｃに、図１Ａに示した通信システム１００内で使用できる例示的なＲＡＮ１０４および例示的なコアネットワーク１０６を示す。上記のように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４はまた、コアネットワーク１０６と通信することができる。

【0031】

ＲＡＮ１０４は、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃを含んでよいが、ＲＡＮ１０４が実施形態との整合性を維持しながら任意の数のｅＮＢを含んでよいことは理解されるであろう。ｅＮＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインタフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するために、１または複数の送受信機を備えることができる。一実施形態では、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装することができる。したがって、例えばｅＮＢ１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間でワイヤレス信号を送受信することができる。

【0032】

各ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、特定のセル（図示せず）に関連してよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてよい。図１Ｃに示すように、ｅＮＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インタフェースを介して相互と通信することができる。

【0033】

図１Ｃに示すコアネットワーク１０６は、モビリティ管理エンティティ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでよい。前述の各要素はコアネットワーク１０６の一部として描かれているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことは理解されるであろう。

【0034】

ＭＭＥ１４２は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅＮＢ１４２ａ、１４２ｂ、１４２ｃに接続されてよく、制御ノードとしての働きをすることができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラをアクティブ化／非アクティブ化すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初のアタッチ中に特定のサービングゲートウェイを選択することなどを担うことができる。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭやＷＣＤＭＡなど他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供することもできる。

【0035】

サービングゲートウェイ１４４は、Ｓ１インタフェースを介してＲＡＮ１０４中の各ｅＮＢ１４０ａ、１４０ｂ、１４０ｃに接続されてよい。サービングゲートウェイ１４４は一般に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送することができる。サービングゲートウェイ１４４はまた、ｅＮＢ間ハンドオーバ中にユーザプレーンをつなぎ留めること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実施することもできる。

【0036】

サービングゲートウェイ１４４はまた、ＰＤＮゲートウェイ１４６に接続されてよく、ＰＤＮゲートウェイ１４６は、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる。

【0037】

コアネットワーク１０６は、他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にすることができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインタフェースとしての働きをするＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、またはそのようなＩＰゲートウェイと通信することができる。加えて、コアネットワーク１０６は、他のサービスプロバイダによって所有および／または運営される他の有線またはワイヤレスネットワークを含みうるネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供することができる。

【0038】

ＧＰＳ技術および／または関連する標準は、デバイス間における近接ベースの発見および通信を可能にするための、かつ、将来のより進歩した多数の近接ベースのアプリケーションおよびサービスを促進するための、最適なプラットフォームになる好機を有する。

【0039】

近接ベースのサービスには、かなりの関心が持たれてきた。デバイス（継続的なネットワーク制御下で近接している、かつ／または３ＧＰＰ ＬＴＥネットワークカバレッジ下にある）の間における、オペレータネットワーク制御による発見および通信に関して、使用事例が研究されつつあり、潜在的な要件および機能が識別されつつある。３ＧＰＰ近接ベースのサービスは、以下の目的で可能にすることができる。すなわち、商業／ソーシャル使用、ネットワークオフローディング、公共安全、および現行インフラストラクチャサービスの統合（到達可能性およびモビリティの側面を含めたユーザ体験の一貫性を保証するための）、ならびに、進化型ユニバーサルモバイルテレコミュニケーションズシステム地上無線アクセスネットワーク（ＥＵＴＲＡＮ）カバレッジがない場合の公共安全（地域的規制およびオペレータポリシに従った、かつ、公共安全に指定される特定の周波数帯域および端末に限定された）の目的である。

【0040】

これらの近接ベースのサービスの一般的なシナリオは、ＷＴＲＵ近接発見と、発見可能または接触可能または会話可能になることに対するＷＴＲＵ同意と、近接ＷＴＲＵ−ｔｏ−ＷＴＲＵ（すなわちｅｎｄ−ｔｏ−ｅｎｄ）通信と、発見および発見可能性および後続の通信形式に対する、ネットワークまたはオペレータによる制御可能性およびポリシと、を含むことがある。

【0041】

図２Ａに、相互に近接する２つのＷＴＲＵ２０５₁および２０５₂による、それぞれの進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）２１０₁および２１０₂を介した、コアネットワーク（ＣＮ）ノード２１５（例えばサービングゲートウェイ（ＳＧＷ）またはパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ））への通信の例を示す。ＷＴＲＵ２０５同士がたまたま相互に近くなったならば、これらのＷＴＲＵ２０５間のどんな通信も、ＣＮノード２１５を介してルーティングされなければならないであろう。

【0042】

近接の検討項目（ＳＩ）の導入により、近接ＷＴＲＵ間の通信を、直接（例えば一定距離内の認可／無認可スペクトル中の直接無線パス）または間接（ネットワーク要素経由（セル内／間、または、ｅＮＢもしくはＳＧＷ内／間など））等の、他のパスをとるように向上させることができ、これはネットワークまたはオペレータによって制御することができる。

【0043】

図２Ｂに、ｅＮＢ２２５を介してローカルにルーティングされる２つのＷＴＲＵ２２０₁および２２０₂間の近接通信のためのデータパスの例を示す。

【0044】

図２Ｃに、エアインタフェースを直接介した直接ＷＴＲＵ−ｔｏ−ＷＴＲＵデータパス２３０の例を示す。

【0045】

近接サービスデータパス選択（直接、またはインフラストラクチャ中の何らかのパスを介した間接）は、無線もしくはネットワークカバレッジ、負荷条件、または、ネットワークもしくはオペレータにより設定されたポリシによって決定することができる。近接ベースのサービスは、ネットワーク共有展開においてサポートすることができる。

【0046】

様々な技法を使用して、ＷＴＲＵ−ｔｏ−ＷＴＲＵ近接サービスを可能にすることに対する１または複数の困難に対処することができる。例えば、ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続またはベアラの場合のページングプロシージャは、現在のＳ１ページングプロシージャとは異なる可能性がある。ＷＴＲＵのうちの１つは、それが他方のＷＴＲＵへのデータを持っていることを何とかしてＭＭＥに通知する必要があることがあり、この他方のＷＴＲＵは、アイドルモードであるかもしれず、また、別のＭＭＥのカバレッジ下にあるかもしれない。また、現在のページングプロシージャは、リソースのいくらかまたは全てをセットアップする（例えばＷＴＲＵとネットワークとの間の全ての既存の進化型パケットシステム（ＥＰＳ）ベアラを戻す）ことがある。しかし、ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続の場合、これは必要なくてよく、リソース、または直接通信に必要なリソースをセットアップすればよく、したがって、このプロシージャは修正する必要があろう。さらに、ＭＭＥは、ＷＴＲＵをページングしてその位置を決定することができる。したがって、おそらくユーザプレーンを確立するためではなくセルレベルの位置を決定するだけのためにＷＴＲＵを接続モードにするためのメカニズムを定義することができる。

【0047】

ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信が開始する前に、両方のＷＴＲＵは、相互を発見し、それらが直接通信可能なくらい十分に近いと判定することができる。このタイプの発見は、プロトコルスタック中のいくつかのレベルまたはレイヤで可能とすることができる。ＮＡＳ方法を実施してＷＴＲＵを発見することができる。したがって、発見近接関連情報をネットワークに送るための種々のＮＡＳプロシージャを定義することができる。発見プロシージャは、ネットワークまたはＷＴＲＵによって開始されてよく、ケースごとに異なる場合がある。さらに、この発見はまた、ＷＴＲＵがＷＴＲＵのグループを発見できるケースに、または両方のＷＴＲＵが異なる公衆陸上モバイルネットワーク（ＰＬＭＮ）に属する場合のあるケースに拡張させることができる。両方のケースで、ＷＴＲＵがグループを発見するため、グループに参加するため、またはグループを離脱するための方法を定義することができる。さらに、近接グループ（以下、近接サービス（ＰｒｏＳｅ）グループと呼ぶ）を動的に形成し解散させることができる。このようなグループの属性が何であるか、このようなグループがどのように形成されるか、誰がいつどのようにグループの形成をトリガしたかについて、決定を行うことができる。

【0048】

いくつかのサービスを可能にするために通常リストすることのできる規則およびポリシがありうる。いくつかのまたはあらゆるサービスは、使用を可能にするためにＣＮによって検証できる規則および条件を有してよい。近接は、規則およびポリシを定義する必要がある可能性のあるもう１つのサービスとすることができ、したがって、ネットワークは、そのようなサービスを制御することができ、様々な基準に基づいてその使用に料金を課すことが可能であってよい。

【0049】

近接サービスニーズをリストできるようにするために、関連する規則およびポリシが必要であろう。これらの規則は、種々の要因（例えば、ＷＴＲＵ位置、加入、ＰＬＭＮ、優先ユーザなど）を考慮することができる。

【0050】

非常時の近接シナリオの場合は、緊急状況の間に送達されるかまたは公衆サービスに使用されるように近接サービスを使用することに対して、規則およびポリシの別個のセットを適用することができる（例えば警察隊員のためのＤ２Ｄ通信）。ＷＴＲＵとネットワークの両方で、何らかの異常アクションがあることがある。したがって、異常規則およびアクションの概要をまとめることができる。

【0051】

これらの規則は、種々のノード（例えばｅＮＢ、ＭＭＥ、ＷＴＲＵなど）において施行することができる。また、これらの規則をＷＴＲＵとネットワークとの間で交換するためのメカニズムがあってよく、したがって、これらの規則を交換するためのプロシージャを定義することが望ましいであろう。

【0052】

オペレータはこのサービスを導入するために収益を必要とするので、特にオペレータにとっては、課金は重要な側面であろう。したがって、通信方法（例えば、直接、またはＲＡＮ経由、またはＲＡＮよりも上のノード経由）に応じて、課金を適用できるための方法を定義することができる。

【0053】

直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラまたはＰＤＮ接続をセットアップできる方法として、種々の方法がありうる。このベアラは、一方のＷＴＲＵから開始することができ、他方のＷＴＲＵまでずっと続くことができる。ネットワークがどのようにこのＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを確立するか、および関与するＷＴＲＵの能力に応じて、このベアラは、２つのＷＴＲＵ間の直接ベアラである場合もあり、または、このベアラのパス中に何らかの中間ＲＡＮまたはＣＮノードがある場合もある。

【0054】

図３Ａ（ケース１）に、中間ノードが含まれない直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラ（すなわちｅｎｄ−ｔｏ−ｅｎｄベアラ）を確立する例を示す。図３Ａは、ＷＴＲＵ３００₁と３００₂の両方が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信をサポートするならば、２つのＷＴＲＵ３００₁と３００₂の間でローカルベアラ３０５を確立できることを示す。このタイプのベアラは、２つのＷＴＲＵ３００₁と３００₂の間の無線ベアラを含むが、両方のＷＴＲＵ中でＮＡＳレベルのベアラコンテキストを依然として有する場合がある。したがって、現在のベアラセットアップのケースのＥＰＳベアラＩＤと同様のＮＡＳ識別子（ＩＤ）を、このベアラに割り当てることができる。別法としてまたは追加で、この新しいベアラは、ＮＡＳコンテキストを有さず、一方のＷＴＲＵ３００₁のパケットデータ収束プロトコル（ＰＤＣＰ）レイヤから開始して他方のＷＴＲＵ３００₂のＰＤＣＰレイヤで終わるかまたはその逆である場合がある。このシナリオでは、このベアラをＲＡＢ ＩＤによって識別することができる。

【0055】

前述のように、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラは、ＲＡＮまたはＣＮノードの中を通る場合がある。図３Ｂ（ケース２）に、ｅＮＢまたはホームｅＮＢ（ＨｅＮＢ）の中を通るＷＴＲＵ−ｔｏ−ＷＴＲＵベアラの例を示す。このベアラは、２つの無線ベアラ（ＲＡＢ）３１５₁および３１５₂を含んでよい。ＲＡＢ３１５₁はＷＴＲＵ−２とｅＮＢ／ＨｅＮＢ３２０との間にあってよく、ＲＡＢ３１５₂はＷＴＲＵ−１とｅＮＢ／ＨｅＮＢ３２０との間にあってよい。このシナリオではどんなＳ１およびＳ５リソースも確立されなくてよいので、これらのタイプのベアラは、ＲＡＢ３１５とＳ１ベアラとの間の１対１マッピングを有さなくてよい。その代わり、それぞれのベアラの各側のＲＡＢ３１５間で１対１マッピングがあってよい（例えば、ＲＡＢ３１５₁とｅＮＢ／ＨｅＮＢ３２０との間、およびＲＡＢ３１５₂とｅＮＢ／ＨｅＮＢ３２０との間に、１対１マッピングがあってよい）。

【0056】

図３Ｃ（ケース３）に、通常のＥＰＳベアラを使用するパス中のｅＮＢまたはＨｅＮＢを介してＷＴＲＵ−ｔｏ−ＷＴＲＵ接続を確立する例を示す。各ＷＴＲＵは、通常のＰＤＮ接続を確立することができる（例えば、図３Ｃに示すように、両方のＷＴＲＵがＳ１およびＳ５リソースを確立することができる。）しかし、これらのリソースは、ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信に使用されなくてよい。というのは、データがｅＮＢ／ＨｅＮＢに到着したとき、ｅＮＢ／ＨｅＮＢは、データをＳ１−Ｕトンネルに送る代わりに、受信側ＷＴＲＵを接続するＲＡＢに向けてデータをルーティングすることができるからである。ケース３に提示する解決法はまた、ＳＧＷレベルにおける以下のシナリオにも適用することができる。

【0057】

図３Ｄ（ケース４）に、２つのＷＴＲＵが２つの異なるｅＮＢ／ＨｅＮＢ３３５₁および３３５₂のカバレッジ下にあるときに、ＳＧＷ３３０の中を通るｅｎｄ−ｔｏ−ｅｎｄベアラを確立する例を示す。このシナリオでは、図３Ｄに示すように、ｅｎｄ−ｔｏ−ｅｎｄベアラは、２つのＲＡＢ３４０₁および３４０₂と、２つのＳ１−Ｕトンネル３４５₁および３４５₂とを含んでよい。ＷＴＲＵ−１とｅＮＢ／ＨｅＮＢ３３５₂との間に、ＲＡＢ３４０₂があり、他方のｅＮＢ／ＨｅＮＢ３３５₂とＳＧＷ３３０との間に、対応するＳ１−Ｕ接続がある。また、ＷＴＲＵ−２とＳＧＷ３３０との間にも、同じ構成が存在する。ＲＡＢとＳ１−Ｕ接続との間には、１対１マッピングがあってよい。また、図３Ｄに示すように、２つのＳＩ−Ｕトンネル３４５間には、１対１マッピングがあってよい。

【0058】

アタッチプロシージャを実施してデバイス間（Ｄ２Ｄ）サービスを得て、Ｄ２Ｄサービス広告および発見を実施するための、方法および装置について述べる。モビリティ管理エンティティ（ＭＭＥ）が、アタッチ要求非アクセス層（ＮＡＳ）メッセージをワイヤレス送受信ユニット（ＷＴＲＵ）から受け取り、Ｄ２Ｄ ＷＴＲＵ能力メッセージをＤ２Ｄサーバに送ることができる。Ｄ２Ｄサーバは、Ｄ２ＤサーバがＷＴＲＵにＤ２Ｄサービスを承認するという条件で、一意のＤ２Ｄデバイス識別子をＭＭＥに送ることができる。ＭＭＥは、一意のＤ２Ｄデバイス識別子を含むアタッチ受諾ＮＡＳメッセージを、ＷＴＲＵに送ることができる。Ｄ２Ｄ ＷＴＲＵは、一般アラートメッセージを、アクセスネットワーク発見および選択機能（ＡＮＤＳＦ）に送ることができ、ＡＮＤＳＦは、Ｄ２Ｄ ＷＴＲＵに関連付けられたＡＮＤＳＦ管理オブジェクト（ＭＯ）を、新しいＤ２Ｄ発見情報で更新することができる。Ｄ２Ｄ ＷＴＲＵは、新しいＤ２Ｄ発見情報を使用して、通信相手となる別のＷＴＲＵを見つけることができる。

【0059】

Ｄ２Ｄ通信のための呼確立を可能にするためのプロシージャ、ならびに、Ｄ２Ｄ通信のためのプロトコルスタックアーキテクチャ、オペレータ内（ｅＮＢ内およびｅＮＢ間を含む）ユニキャストおよびマルチキャストセッションのためのサービス要求プロシージャ、オペレータ間ユニキャストおよびマルチキャストセッションのためのサービス要求プロシージャ、サービス解体およびＤ２Ｄ登録解除プロシージャについて、本明細書に述べる。これらのプロシージャは、ネットワークと、Ｄ２Ｄ通信において動作するＷＴＲＵとの両方に適用可能とすることができる。

【0060】

ワイヤレスモバイルデータに対する需要は爆発的に増加し続けており、これは、世界中で使用されるスマートフォンの数の急増につながっている。遠隔通信業界はこれまで、よりよい多元接続と変調と符号化技法およびマルチアンテナ技法とを使用することでスペクトル効率の増大をもたらす、より新しい標準によって、需要に応えてきた。

【0061】

容量改善のための別の局面は、配置の密度を増大させ、それに対応してセル半径を低減することによるものであった。加えて、異種トポロジがますます使用されており、この場合、スモールセル（マイクロ／ピコ／フェムト）がマクロセルと共に配置される。リモート無線ヘッドおよび分散アンテナを使用して屋内カバレッジを改善することもまた急増している。しかし、これらの手法には、制限および欠点がある。スモールセル配置は、モビリティイベントの大幅な増加につながり、付随する干渉管理問題は複雑である。上記の技法の最大の欠点は、大容量インターネットバックホール、電源、および無線周波数（ＲＦ）機器など、維持しなければならない大量の追加インフラストラクチャが必要なことである。

【0062】

可能な代替解決法の１つは、スマートフォン革命の力を創造的なやり方で使用することである。スマートフォンは、ますます強力なデバイスになりつつあり、複数の広帯域無線機およびモデムを備え、大量のデータを処理する能力ならびに複数の同時アプリケーションを実行する能力を有する。これらのスマートフォンが、必要かつ可能なときに相互と直接に通信することが可能になれば、従来のセルラ配置と共存できる代替トポロジが生み出されるであろう。

【0063】

このような直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信によって可能になることだが、アドバンストトポロジ（ＡＴ）応用例は、ＡＴ中継（ＡＴ−Ｒ）およびＡＴローカルオフロード（ＡＴ−ＬＯ）を含みうる。ＡＴ−Ｒ応用例では、端末ＷＴＲＵ（Ｔ−ＷＴＲＵ）が、中継ノードを介してデータをネットワークと交換することができ、中継ノードはヘルパＷＴＲＵ（Ｈ−ＷＴＲＵ）である。ＡＴ−ＬＯ応用例は、中央ネットワークの制御下で近接するＷＴＲＵ間の直接データ通信を可能にすることができる。

【0064】

ＡＴ−Ｒ応用例は、容量モードおよびカバレッジモードを含んでよい。容量モードでは、Ｔ−ＷＴＲＵは、ネットワークに関連付けられ、無線リンク容量を増強しデータ伝送容量を改善するようＨ−ＷＴＲＵに協力を求める。一方、カバレッジモードでは、Ｔ−ＷＴＲＵは、ネットワークカバレッジ外にあり、Ｈ−ＷＴＲＵに依拠してネットワーク関連付けを達成することができる。これらのモードは両方とも、低モビリティＷＴＲＵに向けて想定される。

【0065】

ＡＴ−ＬＯ応用例では、近接するＷＴＲＵは、交換される情報のソースとシンクとのいずれかとすることができる。ＡＴ−ＬＯ応用例におけるＷＴＲＵ間の無線リンクは、認可セルラスペクトル、または無認可もしくは軽度認可スペクトルを使用することができる。

【0066】

ＷＴＲＵ間の通信は、従来型無線リンク（ＴＲＬ）を介して行われるｅＮＢとＷＴＲＵとの間の従来の通信とは対照的に、クロスリンク（ＸＬ）と呼ばれる専用チャネル中で行うことができる。ＸＬは、別個の帯域中にある場合もあり（帯域外解決法）、または、従来型リンク（ＴＲＬ）と同じ帯域中にある場合もあり、隣接する周波数サブキャリア中にある場合すらある。Ｈ−ＷＴＲＵとＴ−ＷＴＲＵは、周波数分割複信（ＦＤＤ）方式と時分割複信（ＴＤＤ）方式のいずれかで相互と通信することができ、関連する構成はネットワークによって定義されてよい。ネットワークは、ＸＬについて粗いリソース割振りを提供することができ、ＷＴＲＵは、送信タイミング間隔（ＴＴＩ）ごとのリソース割振りを扱う自由を有することができる。

【0067】

ＳＡ１グループにおける近接サービス（ＰｒｏＳｅ）検討項目の導入により、Ｄ２Ｄ通信は、３ＧＰＰにおける議論の主題となってきた。物理通信が直接にＤ２Ｄデバイス間である「直接パス」も、両デバイスが接続されたｅＮＢを通信が経由できる「ローカルパス」も両方とも、ＰｒｏＳｅの範囲内のシナリオである。

【0068】

ＰｒｏＳｅの一部として取り組まれるべきいくつかの使用事例がこれまでに定義されており、各使用事例は、システム設計に対する異なる要件セットを提起する。これらは、ソーシャル安全および公共安全の下に大きくカテゴリ化することができる。

【0069】

基本的なソーシャル使用事例では、Ｄ２Ｄユーザは、そのユーザグループ（例えば友達リスト）に属する他のＤ２Ｄユーザを発見することが可能であるとともに他のＤ２Ｄユーザによって発見されることが可能であってよく、次いで、Ｄ２Ｄリンクを介してソーシャルネットワークアプリケーションを使用することができる。発見は、どんなＷＴＲＵ位置情報もなしに実施することができる。公共発見のケースでは、Ｄ２Ｄユーザは、事前許可を必要とすることなく任意の他のＤ２Ｄユーザによって発見可能であってよい。異なる公衆陸上モバイルネットワーク（ＰＬＭＮ）での発見の場合、異なるＰＬＭＮに属するＤ２Ｄユーザは、相互にとって発見可能であってよい。このサブセットは、Ｄ２Ｄユーザがローミングもしているときである。サービス継続性のために、Ｄ２Ｄユーザは、ユーザによって知覚できる劣化なしに、直接パスとインフラストラクチャモードとの間で移行することができる。ロケーションおよびプレゼンスのために、オペレータは、それらの位置および存在情報をＰｒｏＳｅプロシージャで向上させることができる。

【0070】

基本的な公共安全使用事例では、２人の許可された公共安全ユーザが、Ｄ２Ｄリンクを介して直接に通信することができる。公共安全Ｄ２Ｄユーザは、種々のＤ２Ｄ公共安全ユーザと、同時に複数の１対１のＤ２Ｄセッションを維持することができる。

【0071】

Ｄ２Ｄ発見の目的は、デバイス発見およびサービス発見によってそれぞれ達成することができる。デバイス発見（すなわち近傍発見）プロセスは、ユーザデバイスがデバイス識別に基づいて相互を見つけるように導く。これらのデバイス識別は、物理レイヤシーケンス、無線アクセスネットワーク（ＲＡＮ）識別、またはより高いレイヤの識別子の形とすることができる。デバイス発見は、デバイス間の物理的通信を伴うことがある。デバイス（または近傍）発見プロセスにおいて、近傍を探すＷＴＲＵ（近傍を求めるＷＴＲＵ（ＮＳＷＴＲＵ））は、ネットワークから提供されたスケジュールに基づいて、特定の時間−周波数リソース中で発見シーケンスを送信することができる。他のＷＴＲＵ（近傍にあるＷＴＲＵ（ＮＰＷＴＲＵ）は、これらの期間中にリッスンしてこれらのシーケンスを受け取ることができる。ＮＰＷＴＲＵは、それらの測定値に基づいて、ＮＳＷＴＲＵに直接に応答し返すこともでき、または、さらに他のアクションのためにネットワークに測定値を報告し返すこともでき、その後にＷＴＲＵ間の関連付けプロセスが続く。

【0072】

各Ｄ２Ｄデバイスは、１または複数のサービスを有することができ、したがって複数のサービス識別を有することができる。これらのサービス識別は、提供されるサービスのパラメータと共に、サービス発見の一部として発見することができる。サービス発見は、デバイスと、別の３ＧＰＰノード、３ＧＰＰネットワーク外の何らかのノードとの間の通信によって、または、デバイス発見の完了後にデバイス間のサービス情報の直接交換によって、実施することができる。サービス発見は、デバイス発見の前と後のいずれでも行うことができる。

【0073】

Ｄ２Ｄ通信を３ＧＰＰ進化型パケットコア（ＥＰＣ）に組み込むために、アーキテクチャ上の向上が必要である。既存のアーキテクチャに対するこれらの変更および追加は、ネットワーク中の多数のＤ２Ｄ対応デバイスの効率的な動作を可能にするため、従来のセルラーリンクとのＤ２Ｄリンクの共存を可能にするため、３ＧＰＰ ＰｒｏＳｅフィーチャに向けて想定される全ての配置構成を満たすため、および、３ＧＰＰによって計画されるＤ２Ｄ通信についての全てのサービス要件を満たすために、必要な場合がある。

【0074】

図４に、直接モデルの要約図としてのＤ２Ｄアーキテクチャ４００を示す。この直接モデルでは、Ｄ２Ｄサーバ４０５が、３ＧＰＰネットワーク境界４１０内に位置することができる。Ｄ２Ｄサーバ４０５は、複数のオペレータに共通でありこれらのオペレータによって合同で管理される単一のエンティティとして位置してもよく、または、各オペレータの領域に部分的に位置する複数のエンティティとして実現されてもよい。

【0075】

図５に、直接モデルの展開図としてのＤ２Ｄアーキテクチャ５００を示す。Ｄ２Ｄサーバ５０５は、Ｄ２Ｄのための直接パス手法とローカルパス手法の両方について、Ｄ２Ｄサービスを管理することができる。Ｄ２Ｄサーバ５０５は、オペレータ内とオペレータ間の両方のＤ２Ｄサービスを管理することができる。Ｄ２Ｄサービスは、集中型、階層型、または分散型の管理手法を使用して管理することができる。Ｄ２Ｄサーバ５０５の物理的位置は、使用されるＤ２Ｄ管理手法のタイプに依存する場合がある。集中型手法では、全てのオペレータにわたる３ＧＰＰネットワーク全体に対するＤ２Ｄサーバ５０５が、１つのエンティティ中に位置してよい。階層型手法では、Ｄ２Ｄサーバは、異なる領域ごとに複製されてよく（領域は、ＰＬＭＮとして、またはＰＬＭＮ内のＭＭＥプールなどとして定義することができる）、より高いレベルのＤ２Ｄサーバエンティティによって協調がとられてよい。複数の階層レベルが可能である。分散型手法では、複数のピアＤ２Ｄエンティティが、種々の領域に位置することができ、必要時に相互と通信することができる。

【0076】

呼確立プロシージャについて、本明細書に述べる。最初に、制御プレーンとデータプレーンの両方についてのプロトコルスタックアーキテクチャについて述べ、その後、ｅＮＢ内およびｅＮＢ間、オペレータ内およびオペレータ間、ユニキャストおよびマルチキャストを含めた複数のシナリオの場合のサービス要求プロシージャについて述べる。

【0077】

図６に、直接パスの場合の、２つのＤ２Ｄ ＷＴＲＵ（すなわちＤ２Ｄ−ＷＴＲＵ−１とＤ２Ｄ−ＷＴＲＵ−２）の間のＤ２ＤベアラについてのＤ２Ｄプロトコルスタック図を示す。このシナリオでは、Ｄ２Ｄ−ＷＴＲＵ−１は、ｅＮＢ−１およびＭＭＥ−１に関連してよく、Ｄ２Ｄ−ＷＴＲＵ−２は、ｅＮＢ−２およびＭＭＥ−２に関連してよい。

【0078】

Ｄ２Ｄベアラについての制御プレーン終端は、ＬＴＥ Ｒ８／Ｒ１０（中継なし）と同様とすることができる。無線リソース制御（ＲＲＣ）レイヤはｅＮＢで終端することができ、非アクセス層（ＮＡＳ）レイヤはＭＭＥで終端することができる。データプレーンレイヤは、対応するＤ２Ｄ ＷＴＲＵ中で終端することができる。データプレーンについてのプロトコルレイヤは、ｅＮＢでは維持されなくてよい。ローカルパスの場合は、制御プレーンとデータプレーンの両方のプロトコルスタック終端ポイントは、ＬＴＥ Ｒ８／Ｒ１０と同様とすることができる。

【0079】

サービス発見およびデバイス発見の後、Ｄ２Ｄ対応ＷＴＲＵは、サービス要求プロシージャを使用してＤ２Ｄサービスを確立することができる。ＭＭＥに送られるサービス要求メッセージは、サービスタイプ（「Ｄ２Ｄのみ」または「ベースラインおよびＤ２Ｄ」）、ならびにＤ２Ｄサービスが１人のユーザに対するものかユーザのグループに対するものかなど、プロセスを補助できる情報を含んでよい。Ｄ２Ｄサービスが何人のユーザを対象とするかに応じて、Ｄ２ＤユニキャストサービスまたはＤ２Ｄマルチキャストサービスを確立することができる。個々のユーザがどこでネットワークに接続されているかに応じて、Ｄ２Ｄサービスは、ｅＮＢ内、ｅＮＢ間、またはＰＬＭＮ間サービスとすることができる。サービスを確立するためのプロシージャは、上記のケースの各々で異なる場合がある。まず、ターゲットＷＴＲＵが遊休である場合、これらを最初に必要に応じてページングおよび接続確立プロシージャを介してＲＲＣ接続状態にすることができると仮定する。

【0080】

最初に、サービス要求の中のＤ２Ｄサービス関連パラメータをＭＭＥが調べて、ターゲットＷＴＲＵが同じＭＭＥに属するかどうか判定することができる。Ｄ２ＤサービスがＭＭＥ内である場合は、ターゲットｅＮＢ情報もまたＭＭＥにおいて利用可能とすることができる。ターゲットがＭＭＥ内にあることが見出されない場合は、パラメータをＤ２Ｄサーバに送ることができる。Ｄ２Ｄサーバは、ターゲットＷＴＲＵが現在アタッチしているＭＭＥの識別（ＭＭＥのＩＰアドレスなど）を有することができ、Ｄ２Ｄサーバはまた、このサービスがＰＬＭＮ間動作を必要とするかどうか検証することができる。

【0081】

Ｄ２Ｄサービスのために、新しい種類のＥＰＳベアラ（すなわちＤ２Ｄ ＥＰＳベアラ）を確立することができる。Ｄ２Ｄサービスではデータを直接パスまたはローカルパス上で交換できるので、Ｄ２Ｄ ＥＰＳベアラは、ｅＮＢとサービングゲートウェイ（ＳＧＷ）との間のＳ１インタフェース、およびＳＧＷとパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）との間のＳ５／Ｓ８インタフェースを有さなくてよい。

【0082】

図７に、通常のＥＰＳベアラと、Ｄ２Ｄ ＥＰＳベアラとを対比させて示す。ユーザ間の直接パスのための無線ベアラ確立は、ベースラインＬＴＥシステムと同様とすることができる。関連するｅＮＢは、互換性のある構成を有する無線ベアラをＤ２Ｄピア上で確実に確立できるようにすることを担うことができる。例えば、このＤ２ＤサービスのためにＷＴＲＵによって使用される無線ベアラ識別（ＩＤ）、ＴＤＤ構成、最大許容データレート、変調符号化方式（ＭＣＳ）などが合致しうる。既存のＸ２インタフェースに対する変更を回避するために、通信／協調は、ＭＭＥ間レベルとすることができる。複数のオペレータからｅＮＢ間のＸ２インタフェースに何らかの変更があるならば、ｅＮＢは、相互と通信して協調を実施することができる。

【0083】

ｅＮＢ内ユニキャストＤ２Ｄサービスでは、関与する２人のユーザは、同じｅＮＢのカバレッジ下にある。サービス要求メッセージには、ターゲットであるＷＴＲＵのＤ２Ｄデバイス識別子、および一時サービス名が含まれてよい。当該ｅＮＢは、両方のＷＴＲＵの能力を意識しており、それらのＤ２Ｄベアラを相応に構成することが可能であってよい。Ｓ１およびＳ５インタフェースのない新しいタイプのＥＰＳベアラを使用して、２人のユーザ間のＤ２Ｄサービスを表すことができる。

【0084】

図８は、第１のＷＴＲＵ８０５、第２のＷＴＲＵ８１０、ｅＮＢ８１５、ＭＭＥ／ＳＧＷ８２０、Ｄ２Ｄサーバ８２５、およびアプリケーションサーバ（ＡＳ）８３０を含むワイヤレス通信システム８００における、ｅＮＢ内ユニキャストＤ２Ｄサービス要求プロシージャの流れ図である。ＷＴＲＵ８０５がＷＴＲＵ８１０とのＤ２Ｄサービスを持ちたいとき、ＷＴＲＵ８０５は、ＷＴＲＵ８１０のＤ２ＤデバイスＩＤと一時サービス名とを含むサービス要求８３５を、ｅＮＢ８１５を介してＭＭＥ／ＳＧＷ８２０に送ることができる。ＭＭＥ／ＳＧＷ８２０は、Ｄ２Ｄサービス要求８３５をＤ２Ｄサーバ８２５に転送することができる。Ｄ２Ｄサーバ８２５は、ポリシおよび課金規則機能（ＰＣＲＦ）８４０と共にＤ２Ｄサービス要求８３５を承諾し、ターゲットＷＴＲＵのＭＭＥのＩＤをソースＭＭＥに送ることができる（８４５）。このケースでは、ＷＴＲＵ８１０に対するＭＭＥは、ＷＴＲＵ８０５に対するＭＭＥ／ＳＧＷと同じ（すなわちＭＭＥ／ＳＧＷ８２０）とすることができる。ＭＭＥ／ＳＧＷ８２０は、ＷＴＲＵ８１０がＷＴＲＵ８０５と同じｅＮＢのカバレッジ下にあると判定することができ、したがって、ＷＴＲＵ８０５と８１０との間のデフォルトＤ２Ｄ ＥＰＳベアラをセットアップするための無線構成を実施するようｅＮＢ８１５に通知することができる。ｅＮＢ８１５は、無線ベアラ（ＲＢ）再構成プロシージャを使用して、ＷＴＲＵ８０５と８１０の両方について無線を構成することができる。デフォルトＤ２Ｄ ＥＰＳベアラが確立された後は、ソースＭＭＥは、Ｄ２Ｄサービスが他の専用Ｄ２Ｄ ＥＰＳベアラを必要とする場合に、同様のやり方でそれらを確立することができる。

【0085】

必要なＤ２Ｄ ＥＰＳベアラが確立された後、ソースＭＭＥ／ＳＧＷ（ＭＭＥ／ＳＧＷ８２０）は、メッセージ８５０をＤ２Ｄサーバ８２５に送って、ＷＴＲＵ８０５と８１０との間の直接パスが利用可能であることを示すことができる。Ｄ２Ｄサーバ８２５は、この情報をメッセージ８５５としてＡＳ８３０に転送することができる。ＡＳ８３０は、ＷＴＲＵ８０５および８１０へのアプリケーションレイヤシグナリングを介して、この時点の後で直接パスを使用することになるＷＴＲＵ８０５および８１０上のアプリケーションを制御するのを開始することができる。

【0086】

図９Ａおよび９Ｂは共に、ワイヤレス通信システム９００中のｅＮＢ間のＸ２インタフェース上でのｅＮＢ協調を伴う、ｅＮＢ間／ＭＭＥ間Ｄ２Ｄサービス要求プロシージャの信号流れ図である。図９Ａに示すように、ワイヤレス通信システム９００は、ＷＴＲＵ９０５、第２の２ＴＲＵ９１０、ソースｅＮＢ９１５、ターゲットｅＮＢ９２０、ソースＭＭＥ／ＳＧＷ９２５、ターゲットＭＭＥ／ＳＧＷ９３０、Ｄ２Ｄサーバ９３５、およびアプリケーションサーバ（ＡＳ）９４０を含んでよい。ｅＮＢ間ユニキャストでは、ＷＴＲＵ９０５および９１０は、異なるｅＮＢ９１５および９２０に接続されてよく、２つの異なるＭＭＥ／ＳＧＷ９２５および９３０を伴ってよい（ＭＭＥ／ＳＧＷ間）。この２つのｅＮＢ９１５と９２０との間で、協調が必要であろう。協調は、直接パスについての無線リソース構成、直接パスについての無線リソーススケジューリング、およびＲＲＣのための「マスタ」の確立を含んでよいが、これらに限定されない。

【0087】

協調は、ｅＮＢ９１５と９２０との間のＸ２インタフェースが存在すればそれを介して直接に行われてもよく、または、ＭＭＥ／ＳＧＷ９２５および９３０、ならびにそれらの間のＳ１０インタフェース（図示せず）を介して行われてもよい。

【0088】

このケースでは、ＷＴＲＵ９０５がＷＴＲＵ９１０とのＤ２Ｄサービスを要求したいものとすることができる。したがって、ＷＴＲＵ９０５は、ＷＴＲＵ９１０のＤ２ＤデバイスＩＤと一時サービス名とを含むＤ２Ｄサービス要求９４５を、ソースｅＮＢ９１５を介してＭＭＥ／ＳＧＷ９２５に送ることができる。ソースＭＭＥ／ＳＧＷ９２５は、Ｄ２Ｄサービス要求９４５をＤ２Ｄサーバ９３５に転送することができる。Ｄ２Ｄサーバ９３５は、ＰＣＲＦ９５０と共にＤ２Ｄサービス要求９４５を承諾し、ターゲットＷＴＲＵのＭＭＥ９３０のＩＤをソースＭＭＥ／ＳＧＷ９２５に送ることができる（９５５）。ソースＭＭＥ／ＳＧＷ９２５は、ＷＴＲＵ９１０のＤ２ＤデバイスＩＤを含むｅＮＢ ＩＤ要求９６０を、ターゲットＭＭＥ９３０に送ることができる。ターゲットＭＭＥ９３０は、ターゲットｅＮＢ９２０のＩＤを含むｅＮＢ ＩＤ応答９６２で応答し返すことができる。ソースＭＭＥ／ＳＧＷ９２５は、ターゲットｅＮＢ９２０のＩＤを含むＤ２Ｄ ＥＰＳベアラセットアップ要求９６４を、ソースｅＮＢ９１５に送ることができる。ソースｅＮＢ９１５は、Ｄ２Ｄリンクに使用されるリソースの提案リストを含むＤ２Ｄセットアップ要求９６６を、Ｘ２インタフェース上でターゲットｅＮＢ９２０に送ることができる。ターゲットｅＮＢ９２０は、マスタになり、ソースｅＮＢ９１５からのリソースの提案リストのサブセットを使用することに関する決定を行うことができる（９６８）。ターゲットｅＮＢ９２０は、その決定を搬送するＤ２Ｄセットアップ応答９７０を、Ｘ２インタフェース上でソースｅＮＢ９１５に送り返すことができる。ソースｅＮＢ９１５とターゲットｅＮＢ９２０の両方は、無線構成を実施して、ターゲットｅＮＢ９２０によって指定されたリソースを使用してＷＴＲＵ９０５と９１０との間のデフォルトＤ２Ｄ ＥＰＳベアラをＲＢ再構成プロシージャに従ってセットアップすることができる。

【0089】

デフォルトＤ２Ｄ ＥＰＳベアラは、前述のプロシージャによって確立することができる。Ｄ２Ｄサービスが他の専用Ｄ２Ｄ ＥＰＳベアラを必要とする場合、ソースＭＭＥ／ＳＧＷ９２５は、同様のやり方で、またはＤ２ＤデフォルトＥＰＳベアラを使用して、それらを確立することができる。後者の場合、ソースｅＮＢ９１５およびターゲットｅＮＢ９２０は、Ｄ２Ｄリンク中のＤ２ＤデフォルトＥＰＳベアラを介して作業の協調をとることができる。

【0090】

図９Ｂに示すように、必要なＤ２Ｄ ＥＰＳベアラが確立された後、ソースＭＭＥ／ＳＧＷ９２５は、メッセージ９８０をＤ２Ｄサーバ９３５に送って、ＷＴＲＵ９０５と９１０との間の直接パスが利用可能であることを示すことができる。Ｄ２Ｄサーバ９３５は、メッセージ９８０をＡＳ９４０に転送することができる。ＡＳ９４０は、ＷＴＲＵ９０５および９１０へのアプリケーションレイヤシグナリングを介して、この時点の後で直接パスを使用することになるＷＴＲＵ９０５および９１０上のアプリケーションを制御するのを開始することができる（９８５）。

【0091】

Ｄ２Ｄにおけるマルチキャスト／ブロードキャストサービスでは、全てのユーザが、スケジューリングされているトラフィックの送信側になることができる。ＷＴＲＵは、マルチキャストＤ２Ｄサービスを要求するために、特定のユーザ識別の代わりに一時サービス名を含むサービス要求メッセージを送ることができる。ＭＭＥおよびＤ２Ｄサーバの助けにより、ｅＮＢは、それがｅＮＢ内サービスであることを認識することができる。ｅＮＢは、無線構成を選択するためおよびＤ２Ｄリンクに関与する全てのＷＴＲＵを相応に構成するためのプロシージャを使用することができる。ｅＮＢはこれを、リソース使用に基づいて最小限の構成で行うこともでき、または、Ｄ２Ｄサーバに依拠して、関与する全てのＷＴＲＵの能力に関する知識に基づいて最小限の可能な構成を提供することもでき、相応に無線構成を実施することができる。互換性のある構成を有する無線ベアラが、全てのユーザに対して確立される。

【0092】

マルチキャスト／ブロードキャストの場合の無線リソーススケジューリングは、半持続的な承諾メカニズムをマルチキャストユーザに拡張することによって実施することができる。スケジューリングは、マスタ（例えばｅＮＢ）によって、一定期間の呼スケジューリングウィンドウについて決定することができる。ｅＮＢは、全てのユーザからバッファステータスを得ることができ、次いで、各スケジューリングウィンドウの始めに、スケジュールを割り振ることができる。ユーザは、スケジューリングウィンドウの始めに、既存のサービスへの加入および既存のサービスからの離脱が可能であってよく、その時点で、ｅＮＢはリソースを再割振りすることができる。

【0093】

ｅＮＢ間ユニキャストと同様、ｅＮＢ間マルチキャスト／ブロードキャストは、Ｘ２インタフェースを介した２つのｅＮＢ間の協調を必要とするであろう。Ｄ２Ｄサーバは、ＷＴＲＵによるＤ２Ｄサービス要求がｅＮＢ間のケースであると認識することができ、サービスに参与する他のＷＴＲＵにどのｅＮＢが関連付けられているかをＷＴＲＵのＭＭＥに通知することができる。次いで、ＷＴＲＵのｅＮＢは、これらのｅＮＢと通信することができる。

【0094】

互換性のある構成を有する無線ベアラを、サービスに参与する全てのＷＴＲＵに対して確立することができる。これは、事前定義済みの最小限の構成によって実施することもでき、または、Ｄ２Ｄサーバによって、全てのＷＴＲＵの能力に関する知識に基づいて最小限の可能な構成を提供することによって協調させることもできる。

【0095】

エアリソーススケジューリングは、ｅＮＢ内のケースと同じやり方で実施することができる。しかし、ｅＮＢ間のケースでは、スケジューリングは、ｅＮＢ間の協調を必要とするであろう。

【0096】

オペレータ間Ｄ２Ｄサービスでは、Ｄ２Ｄサーバは、Ｄ２Ｄサービスに関与するＷＴＲＵが種々のオペレータからのものであることを意識している。既存のＸ２インタフェースに対する変更を回避するために、２つのオペレータのネットワーク間の通信／協調は、ＭＭＥ間レベルとすることができる。また、複数のオペレータからｅＮＢ間のＸ２インタフェースに何らかの変更があるならば、ｅＮＢが相互に話しかけて協調を実施できる可能性もある。

【0097】

図１０Ａおよび１０Ｂは共に、無線通信システム１０００におけるオペレータ間ユニキャストの場合のサービス要求プロシージャの信号流れ図である。図１０Ａに示すように、ワイヤレス通信システム１０００は、第１のＷＴＲＵ１００５、第２のＷＴＲＵ１０１０、ソースｅＮＢ１０１５、ターゲットｅＮＢ１０２０、ソースＭＭＥ／ＳＧＷ１０２５、ターゲットＭＭＥ／ＳＧＷ１０３０、Ｄ２Ｄサーバ１０３５、およびＡＳ１０４０を含んでよい。オペレータ間ユニキャストＤ２Ｄサービスを開始するために、ＷＴＲＵ１００５は、ターゲットＷＴＲＵ１０１０のＤ２Ｄデバイス識別子を含むＤ２Ｄサービス要求１０４２を、ソースＭＭＥ／ＳＧＷ１０２５に送ることができる。ソースＭＭＥ１０２５は、Ｄ２Ｄデバイスに関するそれ自体のデータリストをチェックして、ターゲットＷＴＲＵ１０１０がリスト上にあるかどうか確認することができる。ない場合は、ＭＭＥ／ＳＧＷ１０２５は、ターゲットＭＭＥ／ＳＧＷ１０３０のＤ２Ｄデバイス識別子をＤ２Ｄサーバ１０３５に送ることができる。Ｄ２Ｄサーバ１０３５は、Ｄ２ＤデバイスＩＤとＭＭＥ／ＳＧＷ１０３０との間のマッピングを維持することができ、どのＭＭＥ／ＳＧＷ（ターゲットＭＭＥ／ＳＧＷ１０３０）にターゲットＷＴＲＵ１０１０がアタッチするかをソースＭＭＥ／ＳＧＷ１０２５に通知することができる。

【0098】

図１０Ｂに示すように、次いで、ＷＴＲＵ１００５と１０１０との間でデフォルトＤ２Ｄ ＥＰＳベアラ１０５０を確立することができ、それに続いて、必要ならいくつかの専用Ｄ２Ｄ ＥＰＳベアラを確立することができる。例えば、無線ベアラ構成は、最小限の構成を有するデフォルトベアラの確立を含んでよい。Ｄ２Ｄサーバ１０３５は、マスタとしての一方のＭＭＥ／ＳＧＷに、ＷＴＲＵ能力を提供することができ、次いでこのＭＭＥ／ＳＧＷは、スレーブである他方のＭＭＥ／ＳＧＷに構成を示すことができる。次いでこれらのＭＭＥ／ＳＧＷは、無線ベアラを確立するために、構成をｅＮＢに渡すことができる。ソースＭＭＥ／ＳＧＷ１０２５は、ＷＴＲＵ１００５および１０１０からＷＴＲＵ能力を取得して、これを、コンテナ中で、ターゲットＭＭＥ／ＳＧＷ１０３０に渡し、さらにターゲットｅＮＢ１０２０に回すことができ、それにより無線ベアラ構成の協調がとられてよい。

【0099】

２つのオペレータは、無線構成を協調させることができる。前述のように、この協調は、ｅＮＢ間レベルとＭＭＥ間レベルのいずれかで実施することができる。ｅＮＢ間レベルの協調が使用される場合、ソースＭＭＥは、ターゲットＭＭＥに、ターゲットＷＴＲＵのＤ２Ｄデバイス識別子を使用して識別されるよう要求することができる。ターゲットＭＭＥは、ターゲットｅＮＢを識別する情報をソースＭＭＥに送ることができ、ソースＭＭＥは、この情報をソースｅＮＢに転送することができ、それにより、ソースｅＮＢがＸ２インタフェースを介して誰と協調できるかが、ソースｅＮＢにわかるようにすることができる。

【0100】

ＭＭＥ間レベルの協調では、ソースＭＭＥは、Ｄ２Ｄリソース要求メッセージをソースｅＮＢに送って、Ｄ２Ｄリンクのために利用可能な無線リソースを要求することができる。ソースｅＮＢは、提案されるＤ２Ｄ無線リソースリストを含むＤ２Ｄリソース応答メッセージで、ソースＭＭＥに応答することができる。次いでソースＭＭＥは、Ｓ１０インタフェース上でＤ２Ｄセットアップ要求メッセージをターゲットＭＭＥに送って、提案されるリソースリストでＤ２ＤリンクをセットアップするようターゲットＭＭＥに要求することができる。ターゲットＭＭＥは、ソースｅＮＢからの提案されるリソースリストを、Ｄ２Ｄリソース指示メッセージ中でターゲットｅＮＢに転送することができる。ターゲットｅＮＢは、提案されるリソースリストからリソースのサブセットを選択することができ、Ｄ２Ｄリソース割当てメッセージ中で、その選択でターゲットＭＭＥに応答することができる。このケースでは、マスタになって使用Ｄ２Ｄリソースを選ぶのは、ターゲットｅＮＢである。別の実施形態では、いくらかの信号変形を伴って、ソースｅＮＢがマスタになることができる。このシナリオを続けるが、ターゲットＭＭＥは、どのリソースを使用できるかに関するターゲットｅＮＢの決定を搬送するＤ２Ｄセットアップ応答メッセージを、Ｓ１０インタフェース上でソースＭＭＥに送り返すことができる。ソースｅＮＢとターゲットｅＮＢの両方は、ＲＢ再構成プロシージャを使用して、ソースＷＴＲＵ上とターゲットＷＴＲＵ上の両方の無線インタフェースを、Ｄ２Ｄ通信を実施できるように再構成することができる。ターゲットＭＭＥは、Ｄ２Ｄ無線構成が完了したことの確認をターゲットｅＮＢから受け取った後、Ｓ１０インタフェースのＤ２Ｄセットアップ完了メッセージをソースＭＭＥに送って、Ｄ２Ｓ ＥＰＳベアラセットアップを完了させることができる。

【0101】

デフォルトＤ２Ｄ ＥＰＳベアラは、前述のプロシージャによって確立することができる。Ｄ２Ｄサービスが他の専用Ｄ２Ｄ ＥＰＳベアラを必要とする場合、ソースＭＭＥは、それらを同様のやり方で確立することもでき、または、Ｄ２ＤデフォルトＥＰＳベアラを使用することもできる。後者の場合、ソースｅＮＢおよびターゲットｅＮＢは、Ｄ２Ｄリンク中のＤ２ＤデフォルトＥＰＳベアラを介してプロセスを協調させることができる。

【0102】

必要なＤ２Ｄ ＥＰＳベアラが確立された後、ソースＭＭＥは、メッセージをＤ２Ｄサーバに送って、２つのＷＴＲＵ間の直接パスが利用可能であることを示すことができる。Ｄ２Ｄサーバは、この情報をＡＳに転送することができる。ＡＳは、アプリケーションレイヤシグナリングを介して、この時点の後で直接パスを使用することになる２つのＷＴＲＵ上のアプリケーションを制御するのを開始することができる。

【0103】

マルチキャスト／ブロードキャストＤ２Ｄサービスプロシージャは、ｅＮＢ間マルチキャスト／ブロードキャストおよびオペレータ間ユニキャストの場合のプロシージャの、組合せ／修正である。オペレータ間マルチキャスト／ブロードキャストサービスを開始するために、ＷＴＲＵは、Ｄ２Ｄサービスの一時サービス名を含むサービス要求メッセージを、ＭＭＥ（ソースＭＭＥ）に送ることができる。ＭＭＥは、この要求をＤ２Ｄサーバに転送することができる。Ｄ２Ｄサーバは、このサービスに関与するＷＴＲＵがアタッチするＭＭＥを決定することができ、これらのＭＭＥのリストをソースＭＭＥに送ることができる。ソースＭＭＥは、リスト上の他のＭＭＥとの通信を介してＤ２Ｄリンクの無線構成において協調するよう、全てのｅＮＢに通知することができる。ソースｅＮＢと各ターゲットｅＮＢとの間にＸ２インタフェースが存在する場合、ｅＮＢ間の協調はまた、ｅＮＢ間レベルでＸ２インタフェースを介して達成することもできる。

【0104】

ＷＴＲＵがＤ２Ｄサービスを終了したいとき、ＷＴＲＵは、サービス解体要求をそのＭＭＥに送ることができる。ＭＭＥは、この要求をＤ２Ｄサーバに転送することができる。Ｄ２Ｄサーバは、関係するエンティティに、このＷＴＲＵに対するＤ２Ｄ ＥＰＳベアラを除去するよう通知することができる。関係するＤ２Ｄサービスに対して残されたＷＴＲＵが１つしかない場合、Ｄ２Ｄサーバは、このＷＴＲＵに対するＤ２Ｄサービスの終了、およびそのサービスに関係するＥＰＳベアラの除去を要求することができる。

【0105】

Ｄ２Ｄサービスを登録解除する前に、ＷＴＲＵは、サービスがこのＷＴＲＵ上でアクティブである場合はサービス解体プロシージャを実施してサービスを終了することができる。

【0106】

ＷＴＲＵは、登録解除したいサービスの一時サービス識別子を含むアプリケーション登録解除ＮＡＳメッセージをＭＭＥに送ることによって、サービスを登録解除することができる。ＭＭＥは、一時サービス識別子とＷＴＲＵのＤ２Ｄデバイス識別子とを含むこの要求を、Ｄ２Ｄサーバに送ることができる。Ｄ２Ｄサーバは、このアプリケーションを、このＷＴＲＵの利用可能サービスリストから除去することができる。必要なら、Ｄ２Ｄサーバは、この変更をＡＳに通知することができる。

【0107】

ＥＰＳは、実質上、接続指向の伝送ネットワークである。ＥＰＳは、２つのエンドポイント（例えばＷＴＲＵとＰＧＷ）間で何らかのトラフィックを送れるようになる前に、これらの間で「仮想」接続の確立を必要とするであろう。ＥＰＳにおいて、この仮想接続は「ＥＰＳベアラ」と呼ばれ、これは、仮想接続が「ベアラサービス」（すなわち特定のＱｏＳ属性を有するトランスポートサービス）を提供することを強調する用語である。しかし、２つのＷＴＲＵ間の直接通信へのパラダイムシフトがある可能性、および、これがシステムに対して有する影響がある可能性がある。

【0108】

第１のＷＴＲＵと第２のＷＴＲＵとの間でＷＴＲＵ−ｔｏ−ＷＴＲＵベアラ／ｅｎｄ−ｔｏ−ｅｎｄ ＰＤＮ接続を確立するための方法および装置について述べる。直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラまたはＰＤＮ接続が、一方のＷＴＲＵから開始して他方のＷＴＲＵで終わることができる。このベアラは、２つのＷＴＲＵ間の直接ベアラである場合もあり、または、ベアラのパス中に何らかの中間ネットワークがある場合もある。

【0109】

ＷＴＲＵ中では、任意の時点で、異なるＱｏＳ要件をそれぞれが有する複数のアプリケーションが実行されていることがある。複数のＱｏＳ要件をサポートするために、ＱｏＳにそれぞれ関連付けられる種々のベアラをＥＰＳ内でセットアップすることができる。ベアラは、それらが提供できるＱｏＳの性質に基づいて２つのカテゴリに分類することができる。すなわち、最低保証ビットレート（ＧＢＲ）ベアラ、および非ＧＢＲベアラである。

【0110】

基地局は、無線インタフェースを介して、ベアラに対する必要なＱｏＳを保証することができる。各ベアラは、関連するＱｏＳクラス識別子（ＱＣＩ）と、割振り保持優先順位（ＡＲＰ）とを有することができる。各ＱＣＩは、優先順位、パケット遅延予算、および許容可能なパケット損失レートを特徴とすることができる。ＱＣＩは、ベンダが、基礎をなすサービス特性に関する同じ理解を持つことができ、したがって対応する処理（キュー管理、条件付け、およびポリシング戦略を含む）を提供することができるように、標準化されたものとすることができる。ベアラのＡＲＰは、呼許可制御に使用することができ、また、新規ベアラ確立要求に関するプリエンプションのためのベアラの優先順位付けを管理することもできる。

【0111】

図１１に、複数のインタフェースにわたるＥＰＳベアラセットアップの例を示す。図１１に示すように、ＰＧＷ１１０５とＳＧＷ１１１０との間で、Ｓ５／Ｓ８インタフェースを確立することができ、ＳＧＷ１１１０とｅＮＢ（すなわち基地局）１１１５との間で、Ｓ１インタフェースを確立することができ、ｅＮＢ１１１５とＷＴＲＵ１１２０との間で、無線インタフェースを確立することができる。各インタフェースにわたり、ＥＰＳベアラを、それ自体のベアラ識別をそれぞれ使用して、より低いレイヤのベアラにマッピングすることができる。各ノードは、その異なるインタフェースにわたるベアラＩＤ間の結合を常に把握していることができる。

【0112】

ｅＮＢ１１１５は、無線ベアラＩＤとＳ１ベアラとの間の１対１マッピングを記憶して、この２つの間のマッピングを生み出すことができる。同じＥＰＳベアラにマッピングされるＩＰパケットは、同じベアラレベルのパケット転送処理を受けることができる。異なるベアラレベルのＱｏＳフローを提供するには、各ＱｏＳフローにつき別々のＥＰＳベアラが確立されてユーザＩＰパケットが種々のＥＰＳベアラにフィルタリングされることが必要であろう。種々のベアラへのパケットフィルタリングは、トラフィックフローテンプレート（ＴＦＴ）に基づくことができる。

【0113】

図１２に、ＷＴＲＵ１２０５、ｅＮＢ１２１０、ＭＭＥ１２１５、ＳＧＷ１２２０、ＰＧＷ１２２５、およびＰＣＲＦ１２３０を含むワイヤレス通信システム１２００中で実施されるベアラ確立プロシージャの例示的な信号流れ図を示す。ベアラが確立されるとき、上に論じたインタフェースの各々にわたるベアラが確立されてよい。ＰＣＲＦ１２３０は、ベアラの必要ＱｏＳを示すポリシ制御および課金（ＰＣＣ）決定プロビジョンメッセージを、ＰＧＷ１２２５に送ることができる。ＰＧＷ１２２５は、このＱｏＳポリシを使用して、ベアラレベルＱｏＳパラメータを割り当てることができる。次いでＰＧＷ１２２５は、ベアラに関連付けられたＱｏＳと、ＷＴＲＵ１２０５中で使用されることになるアップリンクＴＦＴとを含む専用ベアラ生成要求メッセージ１２４０を、ＳＧＷ１２２０に送ることができる。ＳＧＷ１２２０は、専用ベアラ生成要求メッセージ１２４５（ベアラＱｏＳ、ＵＬ ＴＦＴ、およびＳ１−ベアラＩＤを含む）をＭＭＥ１２１５に転送することができる。次いでＭＭＥ１２１５は、ＵＬ ＴＦＴとＥＰＳベアラ識別とを含むセッション管理構成情報のセットを構築し、これをベアラセットアップ要求メッセージ１２５０に含めて、ｅＮＢ１２１０に送ることができる。セッション管理構成は、非アクセス層（ＮＡＳ）情報であり、ｅＮＢ１２１０によってトランスペアレントにＷＴＲＵ１２０５に送ることができる。

【0114】

ベアラセットアップ要求メッセージ１２５０はまた、ベアラのＱｏＳをｅＮＢ１２１０に提供することができる。この情報は、呼許可制御のためにｅＮＢ１２１０によって使用されてよく、また、ユーザのＩＰパケットの適切なスケジューリングによって必要ＱｏＳを保証することもできる。ｅＮＢ１２１０は、ＥＰＳベアラＱｏＳを無線ベアラＱｏＳにマッピングすることができ、ＲＲＣ接続再構成メッセージ１２５５（無線ベアラＱｏＳ、セッション管理構成、およびＥＰＳ無線ベアラ識別を含む）をＷＴＲＵ１２０５にシグナリングして、無線ベアラをセットアップすることができる。ＲＲＣ接続再構成メッセージ１２５５は、無線インタフェースに関する全ての構成パラメータを含んでよい。これは、レイヤ２（パケットデータ収束プロトコル（ＰＤＣＰ）、無線リンク制御（ＲＬＣ）、および媒体アクセス制御（ＭＡＣ）パラメータ）の構成のためであり、また、ＷＴＲＵ１２０５がプロトコルスタックを開始するためのレイヤ１パラメータの構成のためでもある。次いで、上記のパスに沿ったノード（ただしＷＴＲＵ１２０５からＰＣＲＦ１２３０に戻る逆方向の）は、対応する応答メッセージ（ＲＲＣ接続再構成完了メッセージ１２６０）を生成して、ベアラが正しくセットアップされたことを確認することができる。

【0115】

ＰＧＷ１２２５は、ＷＴＲＵ１２０５に対するＩＰアドレス割振り、ならびに、ＰＣＲＦ１２３０からの規則に従ったＱｏＳ施行およびフローベースの課金を担うことができる。ＰＧＷ１２２５は、ダウンリンクユーザＩＰパケットを種々のＱｏＳベースベアラにフィルタリングするのを担うことができる。これは、ＴＦＴに基づいて実施することができる。ＰＧＷ１２２５は、保証ビットレート（ＧＢＲ）ベアラに対するＱｏＳ施行を実施することができる。

【0116】

２つのＷＴＲＵ間の直接通信へとパラダイムが変化するのに伴い、新しいｅｎｄ−ｔｏ−ｅｎｄベアラ概念の定義を修正する必要があるであろう。この新しいタイプのベアラは、複数のシステム影響を有する場合がある。

【0117】

例えば、無線ベアラ（ＲＢ）とバックホール（ＲＡＮおよび／またはＣＮ）ベアラ（ＥＰＳベアラと総称される）との間には、１対１のマッピングがある。１対１マッピングがもはや当てはまらない場合、ＮＡＳレイヤおよびＮＡＳプロシージャが影響を受けることがある。

【0118】

別の例では、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のための新しいベアラは、２つのＷＴＲＵ間のＲＢに過ぎないものとすることができる。この場合、Ｓ１およびＳ５リソースが必ずしもセットアップされることなくＷＴＲＵおよびＭＭＥ中で新しいベアラ（ＲＢのみ）を扱うための方法について、本明細書に述べる。新しいタイプのベアラをより低いレイヤ（ＰＤＣＰ、ＲＬＣなど）で定義できる場合は、ＩＰアドレスはもはや必要とされなくてよいので、アドレス指定方式を修正する必要があるであろう。

【0119】

直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続は、ネットワーク中の基地局または他の何らかのエンティティの中を通ることができる。この場合、ネットワークエンティティ（ＲＡＮおよび／またはＣＮ）の中を通る新しいｅｎｄ−ｔｏ−ｅｎｄベアラを、ＷＴＲＵ間で定義することができる。この場合、ユーザプレーンリソースのいくつか（Ｓ１−Ｕトンネル）を確立する必要はあるであろうが、他のリソース（Ｓ５／Ｓ８トンネル）は必要とされなくてよい。したがって、このタイプのベアラをセットアップするためのプロシージャを定義することができ、このようなベアラのコンテキストがどのように種々のネットワークノード（例えば基地局、ＭＭＥ、ＳＧＷなど）によって保持されるかを決定することができる。

【0120】

ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続では、ＰＤＮ−ＧＷがユーザパス中にない場合があるか、または、ＰＤＮ−ＧＷはユーザプレーントンネルのエンドポイントではない。このＷＴＲＵ−ｔｏ−ＷＴＲＵ通信モデルでは、ＰＤＮ−ＧＷ機能に関する影響に対処する必要がある。これは例えば、どの／どんなエンティティがＰＤＮ−ＧＷ機能を実施するか、ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のコンテキストにおけるＰＤＮ−ＧＷ機能の関連性、および、追加のＰＤＮ−ＧＷ機能の必要性を含むことがある。

【0121】

前述のケース１、ケース２、ケース３、およびケース４の各々の場合のＷＴＲＵ−ｔｏ−ＷＴＲＵベアラの確立について、本明細書に述べる。

【0122】

図１３に、第１のＷＴＲＵ１３０５、ｅＮＢ１３１０、ＭＭＥ１３１５、および第２のＷＴＲＵ１３２０を含むワイヤレス通信システム１３００中で実施される、ケース１の場合のＷＴＲＵ間ＰＤＮ接続のためのＰＤＮ接続セットアッププロシージャの例示的な信号流れ図を示す。ＷＴＲＵは、ＷＴＲＵがネットワークにアタッチしたときに確立されたデフォルトベアラを有することができる。

【0123】

図１３に示すように、ケース１におけるＷＴＲＵ−ｔｏ−ＷＴＲＵ ＰＤＮ接続は、ＷＴＲＵ１３０５がＰＤＮ接続要求メッセージ１３２５をＭＭＥ１３１５に送ることによって開始することができる。このＰＤＮ接続要求メッセージ１３２５は、ＭＭＥ１３１５がＷＴＲＵ−ｔｏ−ＷＴＲＵ ＰＤＮ接続を確立するのを補助できる追加の情報要素（ＩＥ）を含んでよい。例えば、追加のＩＥは、ＰＤＮ接続のタイプを示すことができるか、またはＰＤＮ接続のタイプであってよい（すなわち、ＷＴＲＵ１３０５は、このＰＤＮ接続が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ間通信のためのものであることを、ＭＭＥ１３１５に通知したいものとすることができる）。別の例示的なＩＥは、接続パスの選好のリストであってよい（すなわち、ＷＴＲＵ１３０５は、それが好むＰＤＮ接続のパスをＭＭＥ１３１５に通知したいものとすることができる）。例えば、ＷＴＲＵ１３０５は、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵパス（ケース１）、ｅＮＢ１３１０経由（ケース２）、またはＳＧＷ（図示せず）経由（ケース３）を好む場合がある。別の例示的なＩＥは、名前、エイリアス、移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）、アクセスポイント名（ＡＰＮ）、パブリックユーザ識別（ＰＵＩ）、または、ＷＴＲＵ１３２０についての他の何らかの形の識別であってよい。要求元ＷＴＲＵ１３０５は、ＰＤＮ接続を確立したい相手であるＷＴＲＵの識別を、ＭＭＥ１３１５に示すことができる。ＭＭＥ１３１５は、この情報を使用して、ＰＤＮ接続確立に向けてネットワーク中の正しいＷＴＲＵを選択することができる。

【0124】

図１３を参照すると、ＭＭＥ１３１５は、ＰＤＮ接続要求１３２５をＷＴＲＵ１３０５から受け取ると、ＷＴＲＵ１３０５から受け取った情報を使用して接続をセットアップすることができる。ＭＭＥ１３１５は、ＷＴＲＵ１３０５および１３２０ならびにネットワークの能力に基づいて、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ ＰＤＮ接続をセットアップすると決定することができる。ＭＭＥ１３１５はまた、セル位置、測定値、加入情報などを使用して、セットアップされるベアラのタイプ（すなわちケース１、ケース２、ケース３など）を識別することもできる。次いでＭＭＥ１３１５は、ベアラセットアップ要求メッセージ１３３０をｅＮＢ１３１０に送ることができ、このメッセージは、カプセル化されたベアラアクティブ化ＮＡＳメッセージを含んでよい。ベアラセットアップ要求メッセージ１３３０はまた、このベアラセットアップ要求メッセージ１３３０が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続のためのものであることをｅＮＢ１３１０に示すこともでき、したがって、ｅＮＢ１３１０は、直接接続のセットアップに関する必要な情報をＷＴＲＵ１３２０に送ることができる。この情報は、ｅＮＢからＷＴＲＵ１３２０に送られるＲＲＣ再構成要求メッセージ１３３５に含まれる、ＷＴＲＵ１３０５の無線ネットワーク一時識別子（ＲＮＴＩ）または他の何らかのレイヤ２識別、スケジューリング情報、このベアラの寿命の間にＷＴＲＵ１３０５によって使用されることになるＱｏＳパラメータ、および他のレイヤ２接続セットアップパラメータを含んでよい。ベアラセットアップ要求メッセージ１３３０は、ＳＧＷ（図示せず）とのＳ１トンネルを生み出すのに必要とされるトンネリングエンドポイントＩＤ（ＴＥＩＤ）および他のパラメータ（例えばＩＰアドレス、ポート番号など）は含まなくてよい。

【0125】

ＷＴＲＵ１３２０が、ＲＲＣ再構成要求メッセージ１３３５と、このＲＲＣ再構成要求メッセージ１３３５中にカプセル化されたベアラアクティブ化ＮＡＳメッセージとを受け取ると、ＷＴＲＵ１３２０は、ＲＲＣ再構成要求メッセージ１３３５を受諾または拒否することができる。ＲＲＣ再構成要求メッセージ１３３５は、ＷＴＲＵ１３２０とｅＮＢ１３１０との間で無線ベアラを確立するために通常のケースで送出されるパラメータを含まなくてよい。ＷＴＲＵ１３２０が要求を受諾する場合、ＷＴＲＵ１３２０はＲＲＣ再構成応答メッセージ１３４０を送ることができ、このメッセージは、ＲＲＣ再構成応答メッセージ１３４０のＮＡＳトランスポートコンテナに含まれるベアラアクティブ化受諾メッセージを含んでよい。

【0126】

ＷＴＲＵ１３２０はＰＧＷ（図示せず）の機能のいくつかを有することができるので、ＷＴＲＵ１３２０はまた、ＷＴＲＵ１３０５についての割り振られたＩＰアドレス（このＰＤＮ接続にＩＰアドレスが割り振られる場合）を、ＲＲＣ再構成応答メッセージ１３４０のＮＡＳトランスポートコンテナに含まれるＮＡＳメッセージに含めることもできる。次いで、このＮＡＳメッセージは、ｅＮＢ１３１０によって、Ｓ１−ＡＰベアラセットアップ応答メッセージ１３４５中でＭＭＥ１３１５に転送することができる。ＭＭＥ１３１５は今や、Ｓ１−ＡＰベアラセットアップ要求メッセージ１３５０中にカプセル化されたＰＤＮ接続受諾メッセージを、ＷＴＲＵ１３０５に送ることができる。Ｓ１−ＡＰベアラセットアップ要求メッセージ１３５０は、本明細書に述べるような直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続のための必要なレイヤ２パラメータをＷＴＲＵ１３０５に送るよう、ｅＮＢ１３１０をトリガすることができる。これらのパラメータおよびＮＡＳ ＰＤＮ接続受諾メッセージは、ＲＲＣ再構成要求メッセージ１３５５中でＷＴＲＵ１３０５に送ることができる。

【0127】

ＰＤＮ接続受諾メッセージは、ＷＴＲＵ１３２０によってこのＰＤＮ接続に割り当てられたＩＰアドレスと、ＱｏＳパラメータ（この特定のＰＤＮ接続に使用されることになるＴＦＴおよびパケットフィルタを含む）とを含んでよい。ＷＴＲＵ１３２０はそれ自体のＩＰアドレスを含めることもでき、このＩＰアドレスは、ＷＴＲＵ１３０５において実行されるピアツーピア（Ｐ２Ｐ）／ＰｒｏＳｅアプリケーションによって使用することができる。図１３に示すように、次いでＷＴＲＵ１３０５は、ＲＲＣ再構成応答メッセージ１３６０をｅＮＢ１３１０に送ることができ、したがってｅＮＢ１３１０は、ベアラセットアップ応答メッセージ１３６５をＭＭＥ１３１５に送ることができる。プロシージャを完了させるために、次いでＷＴＲＵ１３０５は、ＰＤＮ接続性完了メッセージ１３７０をアップリンク直接転送メッセージ中でＭＭＥ１３１５に送って、ＷＴＲＵ１３０５とＷＴＲＵ１３２０との間の直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ ＰＤＮ接続をうまく確立できたことをＭＭＥ１３１５に示すことができる。次いで、ＷＴＲＵ１３０５とＷＴＲＵ１３２０の両方は、この直接ＰＤＮ接続を介して相互にデータを送ることができる。

【0128】

ＷＴＲＵ１３０５がＷＴＲＵ１３２０へのＰＤＮ接続要求メッセージ１３２５を送ったとき、ＭＭＥ１３１５は、ＰＤＮ接続確立プロシージャによって続行するのではなく、ＰＤＮ接続拒否メッセージをＷＴＲＵ１３０５に送る場合がある。これは、以下の理由のうちの１または複数によって生じることがあり、この理由は拒否メッセージに含めることができる。すなわち、１）ＷＴＲＵ１３２０のユーザが、入来した近接接続を受諾しなかった場合があるか、２）ＷＴＲＵ１３２０が、もはや同じｅＮＢ／ＨｅＮＢに近接していないかもしくは同じｅＮＢ／ＨｅＮＢのカバレッジ下にない場合があるか、または、３）ＷＴＲＵ１３２０が、近接接続の最大数に達しており新しい接続を受諾できない場合がある。

【0129】

ＷＴＲＵ−ｔｏ−ＷＴＲＵ ＰＤＮ接続の代替として、ケース１における直接ｅｎｄ−ｔｏ−ｅｎｄベアラを、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ専用ベアラを使用して達成することができる。この場合、ＷＴＲＵ１３０５と１３２０の両方が、デフォルトベアラを有することができる（すなわち、ＰＧＷとのデフォルトＰＤＮ接続がすでにセットアップされていてよく、ＷＴＲＵ１３０５と１３２０の両方が、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためにそれらの間で直接専用ベアラをセットアップしていてよい）。

【0130】

図１４に、上記のケースの接続確立プロシージャの例示的な信号流れ図を示すが、このプロシージャにより、ＷＴＲＵ１３０５は、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ専用ベアラをセットアップするために、ベアラリソース割振り要求ＮＡＳメッセージ１４００をＭＭＥ１３１５に送ることができる。ＷＴＲＵ１３０５は、ベアラリソース割振り要求ＮＡＳメッセージ１４００に、前述のようなＰＤＮ接続要求メッセージに含まれうる追加の情報要素（ＩＥ）のうちの１または複数を含めることができる。ベアラリソース割振り要求ＮＡＳメッセージ１４００中ではまた、リンクトＥＰＳベアラＩＤ（ＬＢＩ）を、空白ＩＥとしてまたは特別な予約符号によって送ることができる。これは、専用ベアラが元のデフォルトベアラにリンクされなくてよいことを、ＭＭＥ１３１５に示すことができる。さらに、ＷＴＲＵ１３０５は、そのＩＰアドレスをベアラリソース割振りＮＡＳメッセージ１４００に含めることができ、ＭＭＥ１３１５によってこのＩＰアドレスがＷＴＲＵ１３２０に送られてよい。または、ＭＭＥ１３１５自体が、ＷＴＲＵ１３０５のＩＰアドレスをＷＴＲＵ１３２０に送ってもよい。このＩＰアドレスは、ＷＴＲＵ１３２０上で実行されるＰ２ＰまたはＰｒｏＳｅアプリケーションによって使用することができる。これは、ＩＰアドレスがＷＴＲＵ１３２０によって割り当てられていないために必要なことがある。図１４に示すプロシージャの残りの部分は、図１３に示したプロシージャと同様である。

【0131】

ケース２の場合のｅｎｄ−ｔｏ−ｅｎｄ ＰＤＮ接続のセットアップのためのプロシージャについて、本明細書に述べる。このプロシージャは、図１３に示したようなケース１に関連するプロシージャに類似するが、各メッセージの内容は、ケース１におけるメッセージの内容とは異なる場合がある。図１３を再び参照すると、ケース２の場合のＰＤＮ接続要求メッセージは、ケース１の場合のＰＤＮ接続要求メッセージ１３２５と同様とすることができる。ＭＭＥ１３１５は、ｅＮＢ１３１０を介したＷＴＲＵ−ｔｏ−ＷＴＲＵ接続のためにこのベアラを確立できることを、ベアラセットアップ要求メッセージ１３３０中でｅＮＢ１３１０に通知することができる。これは、ｅＮＢ１３１０がマッピングＩＤを送ることによって、または、ベアラセットアップ要求メッセージ１３３０中で明示的な指示を送ることによって、達成することができる。ケース２では、ＭＭＥ１３１５によって進化型無線アクセスベアラ（Ｅ−ＲＡＢ）ＩＤを送ることができる。ｅＮＢ１３１０がＲＲＣ構成要求メッセージ１３３５をＷＴＲＵ１３２０に送ると、ｅＮＢ１３１０とＷＴＲＵ１３０５との間でＲＡＢを確立することができる。ＭＭＥ１３１５は、同じマッピングＩＤを、ベアラセットアップ要求メッセージ１３５０中でｅＮＢ１３１０に送ることができる。これは、第１のＲＡＢからのデータを、ＳＧＷ（図示せず）に送る代わりに、確立されているこのＲＡＢ上で送ることができることを、ｅＮＢ１３１０に示すことができる。これは、ＭＭＥ１３１５が明示的な指示を送ることによって達成することができる。

【0132】

次いで、ｅＮＢ１３１０は、ＲＲＣ再構成要求メッセージ１３５５をＷＴＲＵ１３０５に送って、ＷＴＲＵ１３０５とｅＮＢ１３１０との間でＲＡＢを確立することができる。ＲＡＢが確立されると、ＷＴＲＵ１３０５は、ＰＤＮ接続性完了メッセージ１３７０をＭＭＥ１３１５に送ることができ、ＷＴＲＵ１３０５と１３２０は、このＰＤＮ接続を介してデータを交換可能とすることができる。

【0133】

通常のＰＤＮ接続または通常のＥＰＳベアラが各ＷＴＲＵとＰＧＷとの間で確立された（すなわち、各ＷＴＲＵが、ＲＡＢならびに対応するＳ１およびＳ５ベアラを有する）ケースについて、本明細書に述べる。しかし、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信の場合、図３Ｃに示すように、ｅＮＢにおいてデータを一方のＲＡＢから他方のＲＡＢに直接に転送することができる。このタイプのＰＤＮ接続は、デフォルトＰＤＮ接続または専用ベアラとすることができる。

【0134】

このようなＰＤＮ接続がデフォルトＰＤＮ接続である場合、ケース１に関して上述したように、ＷＴＲＵのうちの一方（ＷＴＲＵ−１またはＷＴＲＵ−２）が、ＰＤＮ接続要求ＮＡＳメッセージをＭＭＥに送ることができる。ＭＭＥは、このメッセージを受け取ると、やはりケース１に関して上述した様々な考慮事項に基づいて、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためのこの種類の接続（ケース２）を確立すると決定することができる。次いでＭＭＥは、ＷＴＲＵからのＰＤＮ接続要求をトリガするための指示／メッセージを送ることができる。ＭＭＥは、このメッセージに、以下のパラメータのうちの１または複数を含めることができる。すなわち、１）ＱｏＳパラメータ（ＱＣＩなど）、２）ＰＤＮ接続が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためのものであることを示す指示、３）特定のアクセスポイント名（ＡＰＮ）情報、４）ＷＴＲＵ−１のＩＰアドレス、などである。次いで、ＷＴＲＵ−２は、これらのパラメータに基づいてＰＤＮ接続を要求することができる。あるいは、ＭＭＥが、上記のパラメータを含んでよいデフォルトＥＰＳベアラアクティブ化メッセージをＷＴＲＵに送ることによって、ＷＴＲＵ−２に対するＰＤＮ接続確立プロシージャを開始することも可能であろう。

【0135】

ＷＴＲＵ−１およびＷＴＲＵ−２に対するこれらのＰＤＮ接続のセットアッププロセス中に、またはこれらのＰＤＮ接続の各々が確立された後で、ＭＭＥは、ベアラセットアップ要求メッセージまたはいずれか他のダウンリンクＳ１−ＡＰメッセージ中で、各ベアラについてのマッピングＩＤをｅＮＢに送ることができる。このマッピングＩＤは、これらのベアラの各々が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のために確立されたことをｅＮＢに示すことができ、ｅＮＢがＷＴＲＵ−１のＲＡＢ上で送信されたデータをＷＴＲＵ−２のＲＡＢに送るのを、かつその逆を補助することができる。したがって、パケットは、Ｓ１およびＳ５トンネルの中を通らなくてよい。

【0136】

ｅＮＢを介した直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信（ケース３）もまた、専用ベアラ確立によって達成することができる。ＷＴＲＵ−１は、専用ベアラアクティブ化要求を、この要求が直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためのものであることを示す指示と共に、ＭＭＥに送ることができる。この要求は、前述のＰＤＮ接続要求の中のパラメータのいくつかまたは全てを含んでよい。あるいは、ＷＴＲＵは、ＭＭＥにメッセージを送って、特定のＷＴＲＵとの直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ接続を望んでいることを示すことができ、ＭＭＥは、各ＷＴＲＵにおける専用ベアラ確立プロシージャを開始することによって応答することができる。ＷＴＲＵがＭＭＥに送るメッセージは、他方のＷＴＲＵの何らかの形の識別（例えばＩＰアドレス、発見エイリアスなど）を含んでよい。

【0137】

これらの専用ベアラの各々を確立する間、ＭＭＥは、本明細書に述べるように、ＷＴＲＵ−１からＲＡＢ上で入来するパケットをｅＮＢがＷＴＲＵ−２に対するＲＡＢにマッピングできるように、マッピングＩＤをｅＮＢに送ることができ、したがって、パケットはＳ１およびＳ５トンネルの中を通る必要はない。

【0138】

各専用ベアラが確立されたとき、ＷＴＲＵのＮＡＳレイヤにおけるデフォルトベアラと、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のために確立された対応する専用ベアラのＱＣＩが、同じである場合がある。これは、ＷＴＲＵのＮＡＳレイヤでいくらかの混乱を引き起こす可能性がある。しかし、この混乱は、両方のＷＴＲＵについてのアップリンクとダウンリンクの両方向でパケットフィルタおよびＴＦＴを正しくセットアップすることによって、回避することができる。このような混乱を回避するために、パケットフィルタを、各ＷＴＲＵの正しいＩＰアドレス、および／または特定のポート番号で構成する必要があるであろう。

【0139】

ケース３の別の例では、ＷＴＲＵは、２つ以上のＷＴＲＵとの近接接続を有することがある。このような場合、基地局は、パケットを正しい宛先ＷＴＲＵにルーティングできるように、パケットの宛先アドレスまたは他の何らかの宛先識別をチェックしてパケットを適切なＲＡＢに送る必要があるであろう。この場合の基地局は、ディープパケットインスペクションまたは他の何らかの宛先アドレスチェック方法を利用してパケットの宛先アドレスをチェックする能力を有することができる。何らかのレイヤ２またはレイヤ３アドレス指定方式、例えばＲＮＴＩまたは何らかの特定の近接アドレスなどを使用することが可能であろう。この場合、基地局は、レイヤ２またはレイヤ３メッセージ中でこのような宛先アドレスを見つけたとき、このアドレスを使用してパケットを正しい宛先にルーティングすることができる。

【0140】

図３Ｄに示すようなＳＧＷ３３０の中を通る直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためのｅｎｄ−ｔｏ−ｅｎｄベアラについて、本明細書に述べる。このベアラ確立プロシージャは、関与するＷＴＲＵのいずれか（すなわちＷＴＲＵ−１またはＷＴＲＵ−２）によって開始することができる。

【0141】

図１５に、第１のＷＴＲＵ１５０５、ｅＮＢ１５１０、ＭＭＥ１５１５、ＳＧＷ１５２０、および第２のＷＴＲＵ１５２５を含むワイヤレス通信システム１５００中で実施される、ケース４でＷＴＲＵ−１がＰＤＮ接続要求を開始する場合の例示的な信号流れ図を示す。ＷＴＲＵ１５０５は、ＰＤＮ接続要求メッセージ１５３０を送ることができる。ＭＭＥ１５１５は、ＰＤＮ接続要求メッセージ１５３０を受け取ると、ＳＧＷ１５２０を介してこのベアラを確立すると決定することができる。次いでＭＭＥ１５１５は、ベアラセットアップ要求メッセージ１５３５をｅＮＢ１５１０に送ることができ、このメッセージは、前述のようなＩＥを含んでよく、追加で、ＳＧＷ１５２０とのユーザプレーントンネルをセットアップするための他のパラメータも含んでよい。例えば、ベアラセットアップ要求メッセージ１５３５は、ＴＥＩＤ、ＩＰアドレス、ポート番号などを含んでよい。次いで、ｅＮＢ１５１０は、ＲＲＣ再構成要求メッセージ１５４０を送るために無線ベアラを生み出すことができる。

【0142】

ＷＴＲＵ１５２５は、このケースではＰＧＷとしての役割を果たすこともでき、本明細書に述べるようにこのＰＤＮ接続のためのＩＰアドレスをＷＴＲＵ１５０５に割り当てることができる。このＩＰアドレスは、ベアラセットアップ応答メッセージ１５４５中でＭＭＥ１５１５に送ることができる。ベアラセットアップ応答メッセージ１５４５はまた、ＳＧＷ１５２０とのユーザプレーントンネルをセットアップするための、ｅＮＢ１５１０からのパラメータを含んでもよい。

【0143】

次いで、ＭＭＥ１５１５は、セッション生成要求メッセージ１５５０をＳＧＷ１５２０に送ることによってＳ１−Ｕトンネルをセットアップすることに進むことができる。ＭＭＥ１５１５は、ＳＧＷ１５２０とｅＮＢ１５１０との間の各Ｓ１−Ｕトンネルにつき、２つの別々のセッション生成要求メッセージ１５５０を送ってもよく、または、ＭＭＥ１５１５は、１つのセッション生成要求メッセージ１５５０をｅＮＢ１５１０に送るだけでもよい。後者の場合、ＭＭＥ１５１５は、セッション生成要求メッセージ１５５０が２つのＳ１−Ｕトンネルを確立でき、各Ｓ１−Ｕトンネルの確立に必要なパラメータを含みうることを、ＳＧＷ１５２０に示すことができる。また、いずれの場合も、セッション生成要求メッセージ１５５０は、通常のＥＰＳベアラを確立する際にＳＧＷ１５２０に送られるものとは異なってもよい。

【0144】

例えば、ＭＭＥ１５１５によって送られるセッション生成要求メッセージ１５５０は、このトンネルを直接ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のために確立できること、およびこのトンネルからＳＧＷ１５２０に到着するどんなデータもＳ５トンネルではなく対応するＳ１−Ｕトンネルにルーティングされてよいことを、ＳＧＷ１５２０に示すための、マッピングＩＤ、指示、または何らかの類似するものを含んでよい。ＭＭＥ１５１５はまた、セッション生成要求メッセージをＰＧＷに送る（すなわちＳ５トンネルを生成するために）ことをしないよう、ＳＧＷ１５２０に示すこともできる。

【0145】

別の例では、セッション生成要求メッセージ１５５０は、対応するＳ１トンネルのパラメータ（対応するＳ１−ＵトンネルのＳ１−ＵベアラＩＤ）を含んでよい。

【0146】

別の例では、ＭＭＥ１５１５は、このＷＴＲＵ−ｔｏ−ＷＴＲＵ ｅｎｄ−ｔｏ−ｅｎｄベアラのベアラＩＤを割り当て、これをセッション生成要求メッセージ１５５０中でＳＧＷ１５２０に送ることができる。このベアラＩＤは、両方のセッション生成要求メッセージ１５５０中で同じとすることができる。

【0147】

別の例では、セッション生成要求メッセージ１５５０は、ＰＧＷまたはＰＤＮアドレスを含まなくてよい。

【0148】

ＭＭＥ１５１５がセッション生成応答メッセージ１５５５をＳＧＷ１５２０から受け取ると、次いでＭＭＥ１５１５は、ベアラセットアップ要求メッセージ１５６０をｅＮＢ１５１０に送ることができ、このメッセージは、ＷＴＲＵ１５０５に対するＰＤＮ接続性受諾メッセージを含んでよい。これは、ｅＮＢ１５１０とＷＴＲＵ１５０５との間のＲＡＢの確立をトリガすることができる。また、ＭＭＥ１５１５がセッション生成応答メッセージ１５５５をＳＧＷ１５２０から受け取ると、ＭＭＥ１５１５は、ＷＴＲＵ１５２５にサービスするｅＮＢ１５１０にＳ１−Ｕユーザプレーントンネルパラメータをまだ送っていない場合には、そうすることができる。

【0149】

さらに、本明細書に述べるように、このタイプのＷＴＲＵ−ｔｏ−ＷＴＲＵ接続のために専用ベアラをセットアップすることが可能であろう。このプロシージャは、メッセージの変更を伴って、このケースに関して上述したのと同様とすることができる。加えて、この場合、パケットがＳＧＷ１５２０によってルーティングされる、ケース３と同様のケースも可能であろう。

【0150】

近年、直接デバイス間通信は重要性を増しつつある。これにより、現在の３ＧＰＰアーキテクチャおよび呼管理プロシージャの変更が必要となる。ローカルパスと２重無線アクセス技術（ＲＡＴ）の両方のケースで、呼管理のためのプロシージャが必要とされる。ｅＮＢ間、ＭＭＥ間、およびＰＬＭＮ間のケースをサポートする必要もある。

【0151】

Ｄ２Ｄベアラが管理されるために、呼管理のためのプロシージャを作る必要がある。いくつかの実施形態について以下に述べる。

【0152】

Ｄ２Ｄ構成およびベアラセットアップ、Ｄ２Ｄベアラ再構成、ならびにＤ２Ｄベアラ解体に関係する、ローカルパスのケースと２重ＲＡＴのケースの呼管理プロシージャについて、本明細書に述べる。また、２重ＲＡＴとローカルパスの両方の、ＰＬＭＮ内およびＰＬＭＮ間のケース（ｅＮＢ内、ｅＮＢ間、およびＭＭＥ間のケースを含む）についても、本明細書に述べる。ＲＲＣおよびＮＡＳメッセージならびにインタフェース（Ｓ１−ＡＰインタフェース更新、Ｘ２インタフェース更新、およびＳ１０インタフェース更新）に関係する、プロシージャの詳細ならびに対応する更新についても述べる。Ｄ２Ｄを可能にするためのシステム情報更新についても述べる。

【0153】

Ｄ２Ｄベアラ呼確立の前に、２つのＤ２Ｄ対応ＷＴＲＵが、ネットワークカバレッジ下にありネットワークに登録しているものとすることができ、Ｄ２Ｄベアラセットアップの前に、各ＷＴＲＵによって個別にＮＡＳシグナリング接続およびＲＲＣ接続セットアップが完了しているものとすることができる。

【0154】

以下に述べるプロシージャは３ＧＰＰ ＬＴＥおよびＩＥＥＥ８０２．１１に関して説明するが、これらのプロシージャは、ＷＣＤＭＡ、ＩＥＥＥ８０２．１６、ＣＤＭＡ２０００など（ただしこれらに限定されない）任意のワイヤレス通信技術に適用可能とすることができることに留意されたい。

【0155】

以下、２重ＲＡＴの場合の呼管理に関する実施形態を開示する。

【0156】

このケースでは、Ｄ２Ｄリンクは、３ＧＰＰ ＲＡＴ以外の技術に基づく。便宜上、この別のＲＡＴを８０２．１１ベースのものとして言及するが、他の任意の技法を、この別のＲＡＴとして等しく適切に利用することもできる（例えばブルートゥース（登録商標）など）。２重ＲＡＴの場合、以下のプロシージャは、Ｄ２Ｄ直接パスに当てはまり、ＰＬＭＮ内およびＰＬＭＮ間のケース（ｅＮＢ内、ｅＮＢ間、およびＭＭＥ間のケースを含む）をカバーする。

【0157】

２重ＲＡＴのケースの、いくつかの発見および通信メカニズムを以下に提示する。発見メカニズム（デバイス発見とサービス発見の両方）は、２つのＤ２Ｄ対応ＷＴＲＵ間の通信プロシージャから独立したものとすることができる。以下の発見および通信メカニズムの任意の組合せが可能であることに留意されたい。

【0158】

セルラベースのデバイス発見においては、最初に、Ｄ２Ｄデバイス発見をセルラＲＡＴ上で実施することができる。セルラ上でのデバイス発見は、８０２．１１ＲＡＴベースのＤ２Ｄリンク上での通信のためのサービス発見と、８０２．１１ＲＡＴ上での後続のデバイス発見との、いずれかをトリガすることができる。セルラＲＡＴ上でのＤ２Ｄデバイス発見は、位置情報（ＬＴＥ測位プロトコル、ＧＰＳ、または他の方法に基づく）、セル識別子、セクタ識別子などから導出される情報に限定されることがある。

【0159】

このケースでは、セルラＲＡＴがＤ２Ｄデバイス発見を実施して８０２．１１ＲＡＴベースのＤ２Ｄリンクが実現可能であろうと識別する前には、８０２．１１ＲＡＴ無線はオンにトリガすらされなくてよい。Ｄ２Ｄ対応ＷＴＲＵは、セルラＲＡＴベースのＤ２Ｄデバイス発見結果をネットワークに提供することができる。次いで、ネットワークエンティティ（１または複数）は、Ｄ２Ｄ対応ＷＴＲＵがデバイス発見結果をサービス発見に変換するのを補助することができる。関与する可能性のあるＥＰＣエンティティは、ＭＭＥ、Ｄ２Ｄサーバ、ＨＳＳ、アクセスネットワーク発見および選択機能（ＡＮＤＳＦ）、ポリシ制御および規則機能（ＰＣＲＦ）などを含むが、これらに限定されない。その後、８０２．１１ＲＡＴは、８０２．１１ベースのデバイス発見を実施して、セルラＲＡＴ上でのＤ２Ｄ発見から見つかった結果を増強することができる。別の実施形態では、セルラＲＡＴ上で実施されたＤ２Ｄデバイス発見に基づいて、８０２．１１ＲＡＴ上での通信のためのサービス発見プロシージャがトリガされてよい。

【0160】

ネットワークは、Ｄ２Ｄ対応ＷＴＲＵに対して、その現在のポリシまたはプライバシ側面と、どのユーザをＤ２Ｄ対応ＷＴＲＵが意識していることが可能かとに基づいて、フィルタを提供することができる。

【0161】

別の実施形態では、デバイス発見は、一意の他ＲＡＴ Ｄ２Ｄ識別子を使用して実施することができる。８０２．１１ＲＡＴは、３ＧＰＰ（ＬＴＥ）ネットワークからのトリガなしでデバイス発見を実施することができる。他方のＲＡＴ上に、一意であり改ざんできない一意のデバイス識別子（例えば８０２．１１ＭＡＣアドレス）があってよい。この一意のデバイス識別子は、３ＧＰＰネットワークに知られているものとすることができる。この一意の識別子は、ユーザがデバイスを購入したときに登録されてもよく、または、Ｄ２Ｄ対応ＷＴＲＵから他ＲＡＴ情報の一部としてネットワークに通信される。

【0162】

Ｄ２Ｄ対応ＷＴＲＵは、まだ接続されていなければ、３ＧＰＰネットワークに接続する。Ｄ２Ｄ対応ＷＴＲＵは、ＬＴＥリリース８以降のリリースのベースラインプロシージャと同様のユニバーサル加入者識別モジュール（ＵＳＩＭ）情報に基づいて認証されてよい。一実施形態では、他方のＲＡＴの認証プロシージャは、セルラネットワークによって提供される認証に「依存」してよい。

【0163】

Ｄ２Ｄ対応ＷＴＲＵは、デバイス発見結果をネットワークに提供することができる。次いで、ネットワークエンティティ（複数可）は、Ｄ２Ｄ対応ＷＴＲＵがデバイス発見結果をサービス発見に変換するのを補助することができる。関与する可能性のあるＥＰＣエンティティは、ＭＭＥ、Ｄ２Ｄサーバ、ＨＳＳ、ＡＮＤＳＦ、ＰＣＲＦなどを含むが、これらに限定されない。他方のＲＡＴ上には、各２重ＲＡＴ Ｄ２Ｄ対応ＷＴＲＵについてネットワークにおいて利用可能な一意のデバイス識別子があるので、ネットワークは、Ｄ２Ｄデバイス識別子をサービス識別子に変換することができる。

【0164】

ネットワークは、Ｄ２Ｄ対応ＷＴＲＵに対して、その現在のポリシまたはプライバシ側面と、どのユーザをＤ２Ｄ対応ＷＴＲＵが意識していることが可能かとに基づいて、フィルタを提供することができる。

【0165】

別の実施形態では、他方のＲＡＴに対するＤ２Ｄ識別子は、セルラネットワークによって割り振られてよい。Ｄ２Ｄ対応ＷＴＲＵは、３ＧＰＰネットワークに接続する。登録／アタッチまたは後続のＮＡＳプロシージャの一部として、Ｄ２Ｄ対応ＷＴＲＵは、他方のＲＡＴ中でのＤ２Ｄ動作が可能であることをネットワークに示すことができる。また、一意のＤ２Ｄデバイス識別子をセルラネットワークが割り振ることを必要とすることも示すことができる。次いで、ネットワークは、一意のＤ２Ｄデバイス識別子を他方のＲＡＴに対して割り振ることができる。関与する可能性のあるＥＰＣエンティティは、ＭＭＥ、Ｄ２Ｄサーバ、ＨＳＳ、ＡＤＮＳＦ、ＰＣＲＦなどを含むが、これらに限定されない。

【0166】

他方のＲＡＴは、そのＤ２Ｄデバイス発見プロシージャの一部として割り振られたこの一意のＤ２Ｄ識別子を使用する。他方のＲＡＴ上のデバイス発見メッセージは、発見のための「より高いレイヤの」メッセージとして見られることがある。デバイス発見が完了すると、Ｄ２Ｄ対応ＷＴＲＵは、デバイス発見結果をネットワークに提供することができる。次いで、ネットワークは他方のＲＡＴのＤ２Ｄデバイス識別子とサービスレベルマッピングとの間のマッピングを完全に意識しているので、ネットワークエンティティ（複数可）は、Ｄ２Ｄ対応ＷＴＲＵがデバイス発見結果をサービス発見に変換するのを補助することができる。

【0167】

ネットワークは、Ｄ２Ｄ対応ＷＴＲＵに対して、その現在のポリシまたはプライバシ側面と、どのユーザをＤ２Ｄ対応ＷＴＲＵが意識していることが可能かとに基づいて、フィルタを提供することができる。

【0168】

別の実施形態では、デバイス発見は、セルラネットワークによってトリガされてよい。例えば、８０２．１１ＲＡＴ Ｄ２Ｄ対応ＷＴＲＵ−１が、ベースラインインフラストラクチャモードを介して、８０２．１１ＲＡＴ Ｄ２Ｄ対応ＷＴＲＵ−２に接続される。セルラネットワークは、他方のＲＡＴ上でのＤ２ＤがＷＴＲＵ−１とＷＴＲＵ−２との間の通信に可能であることを検出する。これは、位置情報、測定値、セルＩＤ、セクタＩＤなど（ただしこれらに限定されない）に基づくことができる。セルラネットワークは、ＷＴＲＵ−１およびＷＴＲＵ−２に、それらの他方のＲＡＴ無線機をオンにして他方のＲＡＴ上でのＤ２Ｄデバイス発見を開始するよう、要求することができる。他方のＲＡＴは、一意のＤ２Ｄデバイス識別子に基づいて、または、８０２．１１ＲＡＴ上でセルラネットワークによって割り振られたＤ２Ｄデバイス識別子を使用して、デバイス発見を実施する。デバイス発見結果は、サービス発見に変換することができる。

【0169】

８０２．１１ＲＡＴベースのＤ２Ｄリンクを使用した通信のために、２つのデータプレーンプロトコル代替形態が考えられる。

【0170】

一実施形態では、ＩＰが８０２．１１ＭＡＣ／ＰＨＹの上に位置することができる。この実施形態では、ＩＰパケットは、８０２．１１ベースのＭＡＣおよびＰＨＹプロトコルを介して直接に搬送される。セルラネットワークは、他方のＲＡＴベースのＤ２Ｄリンクの構成を補助することができる。これは、ＮＡＳまたはＲＲＣメッセージによって可能にすることができる。

【0171】

Ｄ２Ｄ ＷＴＲＵの８０２．１１ＲＡＴ呼管理のための、セルラネットワークからの補助は、８０２．１１ベースのＤ２Ｄリンクのための協調に必要とされる構成時間およびリソースを低減することができる。例えば、２つのトライモード（tri-mode）８０２．１１ＲＡＴ対応Ｄ２Ｄ ＷＴＲＵが関与する場合、セルラネットワークは、対応するｅＮＢ−ＷＴＲＵリンクを介して、８０２．１１ｎを使用するようこれらのＷＴＲＵに示すことができ、また、使用すべきチャネルおよび他の関連する構成パラメータを示すこともできる。

【0172】

セルラネットワークは、呼に関与するＤ２Ｄ対応ＷＴＲＵが、８０２．１１ＲＡＴベースのＤ２Ｄ直接パスを介した通信に使用される鍵を導出することができる、という情報を提供することができる。あるいは、８０２．１１ベースのセキュリティを利用することもできる。セルラネットワークは、Ｄ２Ｄ８０２．１１ＲＡＴベースの直接パスのための新しいＩＰアドレスを割り振るのを補助することができる。あるいは、Ｄ２Ｄリンクとインフラストラクチャリンクとに別々の論理インタフェースを定義することもできる。論理インタフェース定義は、別々のＤ２Ｄリンクおよびインフラストラクチャリンクに拡張することができる。これらは、ＷＴＲＵがＤ２Ｄ直接パス、Ｄ２Ｄローカルパス、およびインフラストラクチャリンクを有することができるケースに適用することができる。

【0173】

別の実施形態では、セルラ無線リンク制御（ＲＬＣ）およびパケットデータ収束プロトコル（ＰＤＣＰ）レイヤが、８０２．１１ＭＡＣ／ＰＨＹの上に位置することができる。セルラＲＬＣ／ＰＤＣＰプロトコルデータユニット（ＰＤＵ）は、８０２．１１ベースのＭＡＣおよびＰＨＹプロトコルを介して直接に搬送される。セルラネットワークは、８０２．１１ＭＡＣ／ＰＨＹの最上部にＲＬＣおよび／またはＰＤＣＰレイヤを構成することができ、８０２．１１ベースのＤ２Ｄリンクの構成を補助することができる。これは、ＮＡＳまたはＲＲＣメッセージを使用して可能にすることができる。

【0174】

ＰＤＣＰレイヤが構成される場合、セルラレイヤは、ベースラインと同様の、８０２．１１ＲＡＴ Ｄ２Ｄ直接パス伝送のためのセキュリティを提供することができる。新しいセキュリティ鍵を導出または定義することができ、この鍵は、インフラストラクチャリンクに使用される鍵とは異なってもよい。

【0175】

この実施形態では、Ｄ２Ｄリンクに対する新しいＩＰアドレスの割振りは必要ない。ＩＰアドレス割振りのためのアンカポイントはＰＧＷとすることができ、このことは、Ｄ２Ｄベアラがインフラストラクチャモードに移行されるときにモビリティの助けとなることができる。

【0176】

図１６Ａおよび１６Ｂは共に、第１のＷＴＲＵ１６０５、第２のＷＴＲＵ１６１０、ｅＮＢ１６１５、ＭＭＥ１６２０、およびＤ２Ｄサーバ１６２５を含むワイヤレス通信システム１６００における、一意のＤ２Ｄ識別子を使用するｅＮＢ内、ＭＭＥ内２重ＲＡＴの場合のサービス要求プロシージャについての例示的なプロシージャの信号流れ図である。この例では、ＷＴＲＵ１６０５と１６１０は両方とも、Ｄ２Ｄ８０２．１１ＲＡＴ対応とすることができ、ネットワークに登録されていてよい。ＷＴＲＵ１６０５と１６１０は両方とも、ＲＡＴ上でのそれら自体のＤ２Ｄ識別子を有することができ、デバイスおよびサービス発見（１６３０、１６３５）を実施することができる。デバイス発見（１６３０）が完了すると、関連するアプリケーションは、サービス発見を意識していることができ、Ｄ２Ｄベアラ確立のためのサービス要求プロシージャをトリガすることができる。図１６Ａおよび１６Ｂの例は、セルラＲＬＣおよび／またはＰＤＣＰレイヤが８０２．１１ＲＡＴ（ＷｉＦｉ）ＭＡＣ／ＰＨＹの最上部に構成された場合を示す。

【0177】

図１６Ａに示すように、ＷＴＲＵ１６０５が、８０２．１１ＲＡＴを使用してＷＴＲＵ１６１０とのＤ２Ｄサービスを持ちたい場合、ＷＴＲＵ１６０５は、ＷＴＲＵ１６１０のＤ２ＤデバイスＩＤと一時サービス名とを含むサービス要求１６４０を、ｅＮＢ１６１５を介してＭＭＥ１６２０に送ることができる。ＭＭＥ１６２０は、サービス要求１６４５をＤ２Ｄサーバ１６２５に転送することができる。Ｄ２Ｄサーバ１６２５は、ＰＣＲＦ（図示せず）で要求を検証することができ、必要とされるポリシ情報があればそれを提供することができる。

【0178】

図１６Ｂに示すように、ＭＭＥ１６２０は、ＷＴＲＵ１６０５と１６１０との間で専用Ｄ２Ｄ ＥＰＳベアラ１６５０をセットアップするための無線構成を実施するよう、ｅＮＢ１６１５に通知することができる。ｅＮＢ１６１５は、無線ベアラ（ＲＢ）再構成プロシージャを使用して、ＷＴＲＵ１６０５および１６１０のためにＲＬＣおよび／またはＰＤＣＰレイヤを構成することができる。ＭＭＥ１６２０またはｅＮＢ１６１５はまた、８０２．１１ベースのＭＡＣおよびＰＨＹプロトコルを構成するのを補助することもできる。

【0179】

図１７に、近接サービスを求める要求をＷＴＲＵ１７００が開始する例を示す。近接サービスベアラの確立は、ＷＴＲＵ１７００またはネットワークによって開始することができる。ＷＴＲＵ１７００は、近接フィーチャＩＤと、最適化された近接接続（ＯＰＣ）を確立することにＷＴＲＵ１７００が関心を有するであろう対象のバディ（buddy）のリストと、バディ近接性を決定することを求める要求と、のうちの少なくとも１つと共に、特定のサービス品質（ＱｏＳ）要件を有するリソースを要求することができる。ＷＴＲＵ１７００は、周囲のＷＴＲＵからブロードキャストされた値を使用して、かつ／または、アプリケーション機能によって提供された識別子を明示的に使用して、適切な情報要素（ＩＥ）をＭＭＥに送ることができる。ＷＴＲＵ１７００は、Ｄ２Ｄベアラが同じＱｏＳクラス識別子（ＱＣＩ）特性を共有できるかどうかを示す指示、発信ＷＴＲＵと終端ＷＴＲＵとが同じＱｏＳパラメータを有することができるかどうかを示す指示、および／または要求元ＷＴＲＵが一時スポンサリング属性を呈することができるかどうかを示す指示と共に、特定のＱｏＳ要件を有するリソースを要求することができる。

【0180】

ＷＴＲＵ１７００は、ネットワークおよび無線リソースのセットアップを確立することができる。これは、ベアラリソース割振り要求またはベアラリソース修正を介して実施することができる。ネットワークは、近接プロシージャが特定のＷＴＲＵによってトリガされうるかどうかを受諾または拒否することが可能であってよい。ＷＴＲＵが本明細書に記載のメカニズムを使用してネットワークリソースを要求すると、ネットワークは、特定のアプリケーションの要件に基づいて、その最も実行可能なプロシージャがどんなものであろうかを決定して、最適化された接続を確立し位置情報を渡すことができる。

【0181】

アプリケーションが、近接ベアラの確立を保証するリソースを要求することができる。例えば、アプリケーションは、Ｒｘインタフェースを介してサービスまたはアクションを要求することができ、これらのサービスまたはアクションは、ベアラの確立を、またはＯＰＣをサポートするのに使用できるベアラの確立をトリガする規則を設定するよう、ポリシおよび課金規則機能（ＰＣＲＦ）に促すことができる。ＯＰＣをサポートするベアラの確立をトリガできるサービスまたはアクションについては、本明細書に述べる。

【0182】

あるいは、近接サービスを提供するアプリケーションが、ＯＰＣをサポートするためのベアラの確立を要求することができる（例えばＲｘインタフェースを介して）。理由の完全なリストではないが、なぜＯＰＣをサポートするためのリソースをアプリケーションが要求することがあるかに関する可能性のある理由について、本明細書に述べる。あるいは、近接サービスを要求するアプリケーションが、近接サーバまたは中央近接機能に近接サービスを要求することができ、近接サーバまたは中央近接機能は、前述の方法のいずれかを使用してｅｎｄ−ｔｏ−ｅｎｄ近接ベアラを確立することができる。あるいは、ＷＴＲＵ内のアプリケーションが、ＯＰＣをサポートするのに使用されるベアラの確立を必要とするであろうリソースを要求することができる。

【0183】

図１８に、近接サービスに関するポリシおよび課金制御モデル１８００を示すが、このモデルにより、ＰＣＲＦベースの近接駆動型ベアラを確立することができる。アプリケーション機能（ＡＦ）１８０５（例えば近接サーバ）は、ベアラを介してトランスポートされるデータフローのニーズをサポートするためにこれらのベアラが準拠しなければならない特性および／または要件を、ＰＣＲＦ１８１０に提供することができる。したがって、ＡＦ１８０５は、近接サポートを必要とするであろうアプリケーションの「サポートされるフィーチャ」または「アプリケーション識別」を、ＰＣＲＦ１８１０に明示的に示すことができる。これは、認証許可要求（ＡＡＲ）ｄｉａｍｅｔｅｒメッセージにすでに含まれる既存の属性値パラメータ（ＡＶＰ）を使用して実施することができる。ＰＣＲＦ１８１０は、ポリシを使用して、「アプリケーション識別」または「サポートされるフィーチャ」を、特定のＱｏＳ、ならびに／またはポリシおよび課金制御（ＰＣＣ）規則、ならびに／または単一近接サービスＩＤと「バインド」することができる。

【0184】

ポリシおよび課金制御モデル１８００はさらに、加入者プロファイルリポジトリ（ＳＰＲ）１８１５と、オンライン課金システム（ＯＣＳ）１８２０₁および１８２０₂と、ベアラ構築およびイベント報告機能（ＢＢＥＲＦ）１８２５と、トラフィック検出機能１８３０と、ポリシ課金施行機能（ＰＣＥＦ）１８３５とを含んでよい。

【0185】

単一近接サービスＩＤを使用して、近接サービスを必要とするであろうアプリケーションに加入する他の任意のメンバを関連付けることができる。これらのメンバは、ＯＰＣを介して接続されうる、グループの一部または個別ＷＴＲＵであってよく、このＯＰＣは、ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信のためのより短いパスをとる接続（例えば、ケース３におけるｅＮＢを介した近接接続）である。

【0186】

近接サービスＩＤは、近接サポートを必要とするアプリケーションまたはサービスに関連するグループＩＤまたはアプリケーションＩＤから導出することができる。単一近接サービスＩＤ（ＳＰＳＩ）を使用して、単一のＴＦＴに関連しうる少なくとも２つのＷＴＲＵの接続を管理することができ、いつ、および／またはどこでこの接続を確立するかについての決定は、３ＧＰＰネットワークに完全に委ねられる。ＰＣＲＦは、関連するＰＧＷを介して、単一近接サービスＩＤをＭＭＥに渡すことができる。ＭＭＥは、この識別を使用して、ＯＰＣを使用して接続されうる、近接サービスをサポートするＷＴＲＵがあるかどうか判定することができる。同じ近接サービスＩＤを有する２つ以上のＷＴＲＵをＭＭＥが識別した場合、ＭＭＥは、これらのＷＴＲＵがＯＰＣを介して接続されうるかどうか判定することができる。ＯＰＣは、同じＰＧＷ、同じＬＧＷ、同じｅＮＢ／ＨｅＮＢ／ＨｅＮＢ、または、同じ近接ベアラＩＤを介した直接ルーティングをサポートできるいずれか他のノードを含めた、種々のレベルで定義することができる。

【0187】

ＳＰＳＩを使用することの他に、ＭＭＥは、いくつかの他の基準（候補ＯＰＣ ＷＴＲＵの近接性をシグナリングする修正されたＷＴＲＵ近接指示を含めた）を使用して、ＯＰＣを許可／実行できるかどうか判定することもできる。

【0188】

加えて、２つ以上のＷＴＲＵが候補ＯＰＣノードに接続されているとＭＭＥが判定できる限り、ＯＰＣを実行する候補ノードのノードＩＤを使用することができる。ＭＭＥは、ＷＴＲＵベアラコンテキストから候補ＯＰＣノードＩＤを得ることができ、この情報は、ＭＭＥ間およびＭＭＥ内ハンドオーバを含めたハンドオーバプロシージャ中に転送することができる。例えば、ベアラコンテキストをｈａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄ（ハンドオーバ必要）メッセージおよびｆｏｒｗａｒｄ ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｅｓｔ（再配置転送要求）メッセージ中で転送することができる。あるいは、グローバルｅＮＢ ＩＤを使用して、２つ以上の近接対応ＷＴＲＵが同じｅＮＢに接続されているかどうか識別することができる。さらに、クローズド加入者グループ（ＣＳＧ）ＩＤおよびローカルＨ（ｅ）ＮＢ）ネットワーク（ＬＨＮ）ＩＤを使用することもできる。

【0189】

図１９に、ネットワークベースの近接トリガプロシージャの信号流れ図を示す。近接サーバとしての役割を果たす可能性のあるアプリケーション機能（ＡＦ）１９０５が、近接サービス要求１９１０をＰＣＲＦ１９１５に送ることができる。近接サービス要求１９１０は、近接サービスをＡＦ１９０５に要求する別個のＡＦによってトリガされたものとすることができる。サービス情報は、とりわけ、アプリケーションＩＤまたはフィーチャＩＤ、および単一近接サーバＩＤを含んでよい。ＰＣＲＦ１９１５は、加入者プロファイル要求メッセージ１９２０を、ホーム加入者サーバ（ＨＳＳ）／加入者プロファイルリポジトリ（ＳＰＲ）１９２５に送って、アプリケーションＩＤ／フィーチャＩＤを渡すことができる。ＨＳＳ／ＳＰＲ１９２５は、この情報を使用して、潜在的な近接バディとして加入者によって定義されてよい加入者のリストを取り出すことができる。このリストは、ＨＳＳ／ＳＰＲ１９２５によって送られるプロファイル応答メッセージ１９３０中で提供することができる。近接バディリストは、アプリケーション／フィーチャＩＤと共に、メッセージチェーンを介してＭＭＥ１９３５に渡すことができる。ＭＭＥ１９３５は、この情報を使用して、ＯＰＣを確立できるかどうか判定することができる。

【0190】

一方または両方のＷＴＲＵがアイドルモードに移ったときの、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラ上でのプロシージャおよび影響について、本明細書に述べる。さらに、他方のＷＴＲＵがアイドルモードで送るべきデータを有するときに一方のＷＴＲＵを接続モードに移行させることができるページングプロシージャについても述べる。プロシージャおよび方法は、本明細書に述べるＷＴＲＵ−ｔｏ−ＷＴＲＵベアラケースに応じて異なる場合がある。

【0191】

図３Ａに示すケース１では、一方のＷＴＲＵがアイドルモードになったとき、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラは解体されてよい（すなわち無線ベアラは解放されてよい）。しかし、ベアラのコンテキストは、両方のＷＴＲＵ中に留まることができる。ベアラコンテキストは、無線ベアラコンテキスト、または完全もしくは部分的なＥＰＳベアラコンテキストからなるものとすることができる。したがって、両方のＷＴＲＵが接続モードに戻ったとき、同じベアラを再確立することができる。

【0192】

図３Ａに示す例では、一方のＷＴＲＵがアイドルモードである場合、ＷＴＲＵ−１とＷＴＲＵ−２との間のＲＡＢは解体されてよい。しかし、ＷＴＲＵ−２は、ＷＴＲＵ−１に送るべきいくらかのピアデータを有することがあるが、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラが解体されているので、ＷＴＲＵ−２はしたがって、ＷＴＲＵ−１がアイドルモードであることを知ることができ、したがってＷＴＲＵ−２は、デフォルトＰＤＮ接続を介して、またはＰＤＮ接続へのデフォルトベアラを介して、第１のパケットを送ることができる。この第１のパケットの宛先ＩＰアドレスはＷＴＲＵ−１のアドレスとすることができるので、第１のパケットは、ＰＧＷに、そして最終的にはＷＴＲＵ−１のＳＧＷにルーティングされることが可能である。これにより、ＷＴＲＵ−１を接続モードに移行させるためのＭＭＥによる通常のページングをトリガすることができる。ＷＴＲＵ−１が接続モードになると、残りのパケットは、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介して送ることができる。あるいは、ページングをトリガする第１のパケットはｅＮＢまたはＳＧＷによって廃棄され、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラが再確立された後は、第１のパケットを含めた全てのパケットが直接ベアラを介して送られてもよい。

【0193】

図３Ｂに示す例（ケースＢ）では、一方のＷＴＲＵがアイドルモードに移行したとき、ｅｎｄ−ｔｏ−ｅｎｄベアラは解体されてよい（すなわち両方のＲＡＢは解放されてよい）。しかし、ＲＡＢのコンテキストは、ＷＴＲＵ−１、ＷＴＲＵ−２、およびｅＮＢ中に留まることができる。この場合、一方のＷＴＲＵが、アイドルモードであろう他方のＷＴＲＵに送るべきパケットを有する場合は、前述の解決法がこのケースにも当てはまるであろう。

【0194】

一方のＷＴＲＵがアイドルモードである場合、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラの全体が解放されなくてもよく、ベアラのうちで特定のＷＴＲＵに接続された部分だけが解放されればよい。

【0195】

図３Ｂに示す例（ケースＢ）では、ＷＴＲＵ−１がアイドルモードに移行した場合、ＷＴＲＵ−１からｅＮＢへのＲＡＢは解放されてよいが、ＷＴＲＵ−２からｅＮＢへのＲＡＢは、ＷＴＲＵ−２が接続モードに留まるならば解放されなくてよい。ＷＴＲＵ−２が、ＷＴＲＵ−１に送るべきいくらかの近接またはピアツーピアパケットを有する場合、ＷＴＲＵ−２は、ＷＴＲＵ−１がアイドルモードであることを知らない可能性がある。というのは、ＷＴＲＵ−２からｅＮＢへのＷＴＲＵ−ｔｏ−ＷＴＲＵベアラのためのＲＡＢは依然としてアクティブだからである。したがって、ＷＴＲＵ−２は、このＲＡＢ上でパケットを送ることができる。第１のパケットがｅＮＢに到着したとき、ｅＮＢは、ＷＴＲＵ−１がアイドルモードであると知る。ｅＮＢは、ＷＴＲＵを接続モードにするよう、ＭＭＥに通知を送ることができ、ＭＭＥから応答を受け取ると、ＲＡＢを再構築するための無線リソース制御（ＲＲＣ）再構成要求を送ることができる。ｅＮＢとＷＴＲＵ−１との間でＲＡＢが再確立されると、次いでｅＮＢは第１のパケットをＷＴＲＵに転送することができ、次いで、残りのパケットのいくつかまたは全ては、ｅＮＢに対してトランスペアレントにＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介して送信されてよい。ｅＮＢは第１のパケットを廃棄することもでき、ベアラが再確立された後で、第１のパケットを含めた全てのパケットがＷＴＲＵ−２によって送られてもよい。

【0196】

図３Ｃには、パス中のｅＮＢまたはＨｅＮＢを介してベアラを確立する例を示す。図３Ｃに示す例（ケース３）では、各ＷＴＲＵは、ＰＧＷまたはＰｒｏＳｅ−ＧＷへの別個のベアラを有することができるが、データパケットは、両方のＷＴＲＵに接続されたｅＮＢまたはＨｅＮＢにおいて、一方のＲＡＢから他方のＲＡＢに直接に転送することができる。したがって、このケースでは、一方のＷＴＲＵがアイドルモードに移った（例えばユーザが非アクティブである結果として）とき、このＷＴＲＵに関連する全てのＲＡＢおよびＳ１−Ｕベアラは解体されてよく、ｅＮＢまたはＨｅＮＢ中で、全てのＷＴＲＵ関連のコンテキスト情報は削除されてよい。しかし、ＥＰＳベアラコンテキストは、ＷＴＲＵおよびＭＭＥ中に留まることができる。

【0197】

図３Ｃを参照すると、ＷＴＲＵ−１がアイドルモードになった場合、ｅＮＢ／ＨｅＮＢは、ＷＴＲＵ−１コンテキスト情報の削除の一部として、このベアラまたはＲＡＢの最適化されたパスに関連付けられたマッピングＩＤを除去または非アクティブ化することができる。したがって、ＷＴＲＵ−１に送るべきデータをＷＴＲＵ−２が有する場合、ｅＮＢ／ＨｅＮＢは、データがｅＮＢ／ＨｅＮＢに到着したであろうとき、このベアラまたはＲＡＢにマッピングＩＤが割り当てられていないと判定する。次いで、このデータは、通常の（すなわち最適化されない）プロシージャに従って、最適化されたパスを可能にするために対応するＳ１−Ｕトンネルに転送することができ、次いで、データは最終的に、Ｓ５／Ｓ８トンネルに転送することができる。データは、ＷＴＲＵ−１のＰＧＷ／ＰｒｏＳｅ−ＧＷおよびＳＧＷにルーティングし返すことができ、これにより、通常のページングプロシージャをトリガして、ＷＴＲＵ−１を接続モードに移行させることができる。このページングプロシージャの間、新しいマッピングＩＤ、または、古いマッピングＩＤを再アクティブ化する指示を、ｅＮＢ／ＨｅＮＢに送ることができる。したがって、ＷＴＲＵ−１が接続モードに戻ると、ｅＮＢ／ＨｅＮＢは、このベアラに対するｅＮＢ／ＨｅＮＢを介したローカルパスを可能にすることができ、全てのピアツーピアデータは、ＷＴＲＵ−１からこのパスを介してＷＴＲＵ−２に送ることができる。ケース４は、ケース２について述べた状況と同様とすることができるが、ケース４の場合、一方のＷＴＲＵがアイドルモードに移行したとき、ｅｎｄ−ｔｏ−ｅｎｄベアラ全体が非アクティブ化されてもよく、または、ベアラのうちでアイドルモードに移行したＷＴＲＵに関連付けられた部分が非アクティブ化されてもよく、この部分は、このケースでは、ＲＡＢおよび対応するＳ１−Ｕベアラとすることができる。例えば、ＷＴＲＵ−１がアイドルモードに移行した場合、ＷＴＲＵ−１とｅＮＢ／ＨｅＮＢとの間のＲＡＢ、およびｅＮＢ／ＨｅＮＢとＳＧＷとの間のトンネルが非アクティブ化されてよいが、ＳＧＷとＷＴＲＵ−２にサービスするｅＮＢ／ＨｅＮＢとの間のＳ１−Ｕトンネル、および対応するＲＡＢは、アクティブのままとすることができる。

【0198】

同様に、ＷＴＲＵ−２がＷＴＲＵ−１へのピアツーピアまたはＰｒｏＳｅパケットを有するが、ＷＴＲＵ−１がアイドルモードである場合、パケットは、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラ全体が非アクティブ化されているという条件で、前述のようにデフォルトＰＤＮ接続を介して送ることができる。あるいは、パケットは、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラがＷＴＲＵ−２から見て依然としてアクティブである間に、ＷＴＲＵ−２によってＷＴＲＵ−ｔｏ−ＷＴＲＵベアラ上で送ることができる。この場合、パケットがＲＡＢおよびＳ１−Ｕトンネルを使用してＳＧＷに到着したとき、ＳＧＷは、通常のページングプロシージャをトリガして、ＷＴＲＵ−１を接続モードに移行させることができる。ＷＴＲＵ−１が接続モードになると、パケットは、ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介してＷＴＲＵ−１に送ることができる。

【0199】

近接性に関する非アクセス層（ＮＡＳ）発見方法について、本明細書に述べる。近接発見のためのＷＴＲＵの登録は、近接発見サービスを使用して他のＷＴＲＵを探したいという意向、および／または、他のＷＴＲＵによって発見可能または発見不可能として自身を識別したいという意向を含んでよい。発見可能である場合、ユーザはまた、ネットワークが他のユーザに対して表示するための「ニックネーム」を提供することもでき、ユーザはまた、性別や関心のような、ネットワークが他のユーザに対して表示するための他の情報を提供することもできる。ネットワークが発見サービスの使用をＷＴＲＵに対して承諾するかどうかは、加入プロファイルに基づくことができる。

【0200】

さらに、ＷＴＲＵはまた、使用している周知のアプリケーション（すなわちアプリケーション）を登録メッセージに含めることもできる。周知のアプリケーションは、ボイスオーバインターネットプロトコル（ＶｏＩＰ）クライアント（Ｓｋｙｐｅ、Ｖｏｎａｇｅ）および／またはソーシャルネットワーク（ＳＮＳ）アプリケーション（例えばＦａｃｅｂｏｏｋ）など、近接サービスから利益を得ることのできる広く使用されているスマートフォンアプリケーションである。情報は、さらに他の近接ベースサービスのために、ネットワークまたはアプリケーションサーバによって使用することができる。ネットワークは、ＷＴＲＵの近接発見登録情報と、周知アプリケーション情報と、関連する位置情報（全地球測位システム（ＧＰＳ）座標、セルＩＤ、ｅＮＢ ＩＤ、ＣＳＧなど）を記録することができる。

【0201】

登録のために、新しい情報要素（ＩＥ）を、アタッチまたはトラッキングエリア更新（ＴＡＵ）メッセージ中で追加することができる。ネットワークは、登録結果を応答メッセージ中でＷＴＲＵに通知することができる。この目的で、新しいＮＡＳメッセージを考案することもできる。

【0202】

システムが近接発見をサポートする場合、セルは、ＲＲＣレベルでブロードキャストすることができる。

【0203】

アプリケーション特有情報を要求することができる。周知アプリケーション登録が実施される場合、ＭＭＥは、ニックネーム、ログインＩＤ、パスワードなど、いくらかのアプリケーション特有情報を送るようＷＴＲＵに要求することができる。情報は、近接ベースサービスのために、ネットワークによって使用されるか、またはさらにアプリケーションサーバに提供されてよい。この目的で、新しいＮＡＳメッセージを考案することもできる。

【0204】

ＷＴＲＵは、その近接登録情報を修正する（例えば、発見可能から発見不可能に変更する）ことができる。位置移動（例えば別のセルへの再選択もしくはＨＯ）、または新しいエリアでのＴＡＵの際、システムは、元のＭＭＥにおけるこのＷＴＲＵの近接情報を更新もしくは削除することが可能であるかまたは更新もしくは削除すべきである。ＷＴＲＵがＧＰＳ対応である場合、ＷＴＲＵは、ＮＡＳを介してＧＰＳ座標を定期的に送って、位置情報を更新するように構成されてよい。

【0205】

近接発見情報を要求することができる。ＷＴＲＵは、近接発見情報（付近の発見可能になっている全てのＷＴＲＵ、または、特定の周知のアプリケーションについて付近にいるこのアプリケーションの他ユーザなど）を、ネットワークに要求することができる。この目的で、新しいＮＡＳメッセージを考案することもできる。

【0206】

システム間の近接情報交換を行うことができる。ＭＭＥは、近接情報（例えば、発見情報、位置情報、近接能力情報、および／または近接ＱｏＳ情報など）を、サービング汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＳＧＳＮ）など他のシステム要素と交換することができる。ＭＭＥは、ある位置に関する近接関連情報（例えば、ＧＰＳ座標、セル、またはトラッキングエリア）を送るようＳＧＳＮに要求することができる。ＳＧＳＮは、位置をそれ自体の位置（セルまたはルーティングエリア）にマッピングし、その位置における全ての発見可能なＷＴＲＵ、またはアプリケーション特有情報を返すことができる。ＭＭＥはまた、他のシステムにも同様の情報を提供することができる。新しいシステム間メッセージを考案することもできる。

【0207】

ＭＭＥとアプリケーションサーバとの間で通信を確立することができる。ＭＭＥは、現在の近接情報を周知アプリケーションサーバに提供することができ、それにより、サーバは近接情報を有することができる。ユーザがアプリケーションに対してオンラインになったとき、アプリケーションは、関連する近接情報をユーザに対して表示することができる。ＭＭＥは、要求時にまたは定期的に、ＷＴＲＵの現在のトラッキングエリアＩＤまたはｅＮＢ ＩＤを送ることができ、これらは、アプリケーションサーバおよび／または近接サーバに登録されてよい。あるいは、近接サーバは、２つのＷＴＲＵが近接サーバを介して通信したいと望んでいるか否かをＭＭＥに通知することができる。第１のケースでは、アプリケーションサーバ／近接サーバが、この情報を使用することができる（例えば、近接サービスを要求した、かつ／または特定のアプリケーションを使用しているであろう、２つのＷＴＲＵが、同じエリア内にあるか否かを識別するために、ＷＴＲＵのトラッキングエリアＩＤを使用することができる）。これらのＷＴＲＵが同じエリア内にあるとアプリケーションサーバが判定した場合、アプリケーションサーバまたは近接サーバは、２つ以上のＷＴＲＵ間で近接接続を確立するよう、ＭＭＥおよび／またはネットワークに要求することができる。

【0208】

第２のケースでは、アプリケーションサーバが情報をＭＭＥに送ることができ、ＭＭＥは、アプリケーションサーバ／近接サーバからの情報に基づいて、同じトラッキングエリア中にある２つのＷＴＲＵが相互に通信したいと思っているかどうか判定することができる。ＷＴＲＵが近接通信を望んでいるであろうこと、および／またはＷＴＲＵが近接通信を実施できることが、ＭＭＥによって結論付けられた場合は、これらのＷＴＲＵ間で近接接続を確立することができる。

【0209】

図２０に示すように、アプリケーションゲートウェイ２００５をＭＭＥ２０１０に組み込んで、アプリケーションサーバ２０１５との通信を可能にすることができる。

【0210】

ＰｒｏＳｅ（ＷＴＲＵ−ｔｏ−ＷＴＲＵ近接サービス）を実現し、ＷＴＲＵ−ｔｏ−ＷＴＲＵ通信を可能にするために、新しい論理ノードを設けることができる（本明細書では近接サービスゲートウェイ（ＧＷ）（すなわちＰｒｏＳｅ−ＧＷ）と呼ぶ）。ＰｒｏＳｅ−ＧＷは、ネットワークオペレータによって、または独立したＰｒｏＳｅサービスプロバイダによって、または企業によって配置することができる。ＰｒｏＳｅ−ＧＷは、複数のローカルホームネットワークおよび関連するローカルＧＷ（ＬＧＷ）にわたることがある。同様に、ＰｒｏＳｅ−ＧＷは、複数の企業ローカルネットワークにわたることがある。ＰｒｏＳｅ−ＧＷは、ＰｒｏＳｅ ＰＤＮ接続によって使用されるＩＰアドレス割振りと、ＱｏＳ施行をサポートするためのポリシ制御施行機能（ＰＣＥＦ）、およびＰＣＲＦ規則に従ったフローベース課金機能とを含んでよい。

【0211】

ＰｒｏＳｅ−ＧＷが企業または独立したＰｒｏＳｅプロバイダによって配置される場合は、ＰＣＥＦおよびフローベース課金機能は、ＰｒｏＳｅ−ＧＷ中に位置しなくてよい。このような場合、ＰｒｏＳｅは、ユーザサービスレベル合意による事前定義済みのＱｏＳレベルにより、ＰＤＮ接続またはベアラ（ＷＴＲＵデフォルトベアラなど）を使用してサポートされてよい。

【0212】

ＰｒｏＳｅ−ＧＷはまた、近接サービスに関与するＷＴＲＵに向けた以下の機能を含んでよく、これらはＳＧＷ機能とすることもできる。ＷＴＲＵがＰｒｏＳｅ ＰＤＮ接続のみを有するとき、ＷＴＲＵがｅＮＢ間またはＨｅＮＢ間で移動する際にデータベアラと共にローカルモビリティアンカを使用することができる。ＷＴＲＵが遊休状態（例えば、ＥＰＳモビリティ管理（ＥＭＭ）遊休、またはＥＰＳ接続管理（ＥＣＭ）遊休）のときであって、ＭＭＥがＷＴＲＵのページングを開始してベアラを再確立する間にダウンリンクデータを少なくとも一時的にバッファリングするとき、ベアラに関する情報を保持することができる。ローミングしているＷＴＲＵについて、課金のための情報（例えばユーザとの間で送受信されるデータのボリューム）および合法的傍受のための情報を収集することができる。

【0213】

例えば、近接サービス（ＰｒｏＳｅ）エリアを、セルの集まり（例えば、同じＣＳＧ ＩＤを有するセル、またはＣＳＧ ＩＤのリストに属するセル）と、ローカルホームネットワークまたはローカル企業ネットワークの集まりと、のうちの１または複数として定義することができる。ＰｒｏＳｅエリアは複数のＰＬＭＮからのセルにわたることもあり、または、ＰｒｏＳｅエリアは複数のＣＳＧにわたることもある。

【0214】

ＰｒｏＳｅエリアは、グローバル一意識別子とすることのできる識別子に関連してよい。このような識別子は、このＰｒｏＳｅエリア中のセルによってブロードキャストすることができる。ＰｒｏＳｅエリア識別子はまた、ＷＴＲＵ間で、またはＷＴＲＵとネットワークエンティティとの間で、専用ＲＲＣメッセージまたはＮＡＳメッセージ中で交換することができる。ＰｒｏＳｅエリア識別子は、ＰｒｏＳｅ発見、またはＰｒｏＳｅピアＷＴＲＵもしくはＷＴＲＵグループの発見をサポートするために、ＷＴＲＵまたはネットワークエンティティ（ＭＭＥ、ｅＮＢ／ＨｅＮＢ、ＧＷ（ＰｒｏＳｅ ＧＷを含む））によって使用することができる。同じＰｒｏＳｅエリア中のＷＴＲＵは、ＰｒｏＳｅ通信に携わることができる。

【0215】

ＰｒｏＳｅアクセスは、アクセシビリティ制御と、アクティブ化トリガと、いつどのようにＰｒｏＳｅアクセスを提供できるかを決定するための決定ノードとを使用して提供することができる。ＰｒｏＳｅ制御では、おそらくはＰｒｏＳｅを使用可能にし制御するために、以下の情報を、ＷＴＲＵにまたはユーザの加入プロファイルに組み込むことができる。

【0216】

ＰｒｏＳｅ許可は、ＷＴＲＵがＰｒｏＳｅに携わるための許可として定義することができる。さらに、ＨＳＳにおけるＰＤＮ加入コンテキストは、以下のような様々な粒度のＰｒｏＳｅ許可を含んでよい。すなわち、アクセスポイント名（ＡＰＮ）、および、ＰｒｏＳｅがＡＰに対して可能とされるか禁止されるかを示すＡＰＮに関する指示；ＡＰＮ、および、このＡＰＮに対してＰｒｏＳｅのみがサポートされるかどうかを示す指示；ＡＰＮ、および、サポートされるＰｒｏＳｅが条件付き（例えばＰｒｏＳｅ条件付き）かどうかを示す指示；ＰＧＷもしくはＰｒｏＳｅ ＧＷ（例えばデフォルトＰｒｏＳｅ ＧＷ）の識別、およびＡＰＮ；ＰｒｏＳｅエリア（例えばＰｒｏＳｅエリアのリスト）およびＡＰＮ；ＰｒｏＳｅがローミング中に可能かどうか（例えば、訪問先公衆陸上モバイルネットワーク（ＶＰＬＭＮ）中で）；ＰｒｏＳｅがローミング中に訪問先ネットワークＰｒｏＳｅ ＧＷまたはＰＧＷを介して可能かどうか；ＰｒｏＳｅが特定のＰｒｏＳｅグループ（オープングループ、クローズグループ、私的グループ、公開グループ）に対して可能かどうか；ＡＰＮ、および、ＰｒｏＳｅが特定のＰｒｏＳｅグループまたはグループタイプに対して可能かどうかを示す指示；ＷＴＲＵが別のＷＴＲＵをＰｒｏＳｅ通信に招待することが可能かどうか（招待されるＷＴＲＵがＰｒｏＳｅに加入していなくても）；ならびに／または、ＡＰＮ、および、可能とされるＰｒｏＳｅサービスレベルを示す指示（それにより、多くのＰｒｏＳｅサービスレベルがありうる）；ＰｒｏＳｅがデフォルトＰＤＮ接続ベアラ上で確立されることが可能か、または専用ベアラもしくは専用ＰＤＮ接続上で確立されることが可能か；ＰｒｏＳｅが発信呼のみに可能とすることができるか終端呼のみに可能とすることができるか、またはその両方か；許可は、特定のＱｏＳ属性および関連しきい値（最大ビットレート、ＱｏＣクラス識別子（ＱＣＩ）、割振りおよび保持優先順位（ＡＲＰ）など）について承諾されうる；許可の有効性；許可は、特定のサービスタイプについて承諾されうる；ならびにユーザ同意（これは上記と同じ粒度レベルを有してよい）などである。

【0217】

このような情報は、ＨＳＳ中にあってよい。さらに、この情報は、ＣＮノード（ＭＭＥ、ＳＧＳＮ、ＳＧＷ、またはＰＧＷなど）に提供することができる（例えばＨＳＳによって）。情報はまた、本明細書に述べるＰｒｏＳｅ ＧＷに提供することもできる。

【0218】

加えて、ＰｒｏＳｅは、同じローカルネットワーク下のＷＴＲＵ間で、または、定義されたローカルネットワークのリストに属するＷＴＲＵ間で、可能とすることができる。ＰｒｏＳｅは、同じＣＳＧに属するＷＴＲＵ間で可能とすることができる。許可は、常に可能、常に禁止、かつ／または条件付きとすることができる。

【0219】

ＰｒｏＳｅ通信のサポートはまた、ネットワーク構成および能力の影響を受けることがある。同様に、ＰｒｏＳｅ通信のサポートは、ＷＴＲＵ構成、ならびに、その能力、およびプロトコル／ハードウェアバージョンまたはリリースの影響を受けることがある。例えば、ＭＭＥ、ＳＧＷ、およびＰＧＷの中には、ＰｒｏＳｅをサポートするものもあればサポートしないものもあるであろう。同様に、ｅＮＢまたはＨｅＮＢの中には、ＰｒｏＳｅをサポートするものもあればサポートしないものもあるであろう。

【0220】

モビリティの間、サービングネットワークまたはネットワークノード（ＭＭＥ、ＳＧＷ／ＰＧＷ、またはｅＮＢもしくはＨｅＮＢ）は、ターゲットネットワークまたは特定のターゲットネットワークノードにおけるＰｒｏＳｅのサポートを検証することができる。ターゲットネットワーク（または、ＷＴＲＵにサービスしていることになる特定のターゲットネットワークノード）がＰｒｏＳｅをサポートしない場合、サービングネットワークは、ＰｒｏＳｅ ＰＤＮ接続を非アクティブ化することができる。非アクティブ化は、ｅＮＢもしくはＨｅＮＢ、ＭＭＥ、および／または、ＳＧＷ、ＰＧＷ、もしくはＰｒｏＳｅ−ＧＷによって開始することができる。

【0221】

ＰｒｏＳｅへのトリガ、およびＰｒｏＳｅをトリガできる時点について、本明細書に述べる。ＰｒｏＳｅは、近くの友達が発見されたとき、または友達または関心ポイントが近いことが通知されたときに、トリガされてよい。通知は、ネットワークからまたはＷＴＲＵからユーザに向けて送ることができる。例えば、ユーザは、ユーザ友達リスト上にまだないであろう友達または関心ポイントが発見されたときに通知を発行するよう、ＷＴＲＵを構成することができる。

【0222】

通知は、ＷＴＲＵに向けて送ることができる。例えば、ＷＴＲＵは、ネットワークまたはピアＷＴＲＵまたは関心ポイントから通知があると、何らかのアクションを自律的に行う（例えば友達リストを更新する）ように構成されてよい。

【0223】

ＰｒｏＳｅは、ＰｒｏＳｅエリアに入ったとき、またはＰｒｏＳｅエリアＩＤをシステム情報ブロードキャストから読み取ったときにトリガされてよい。

【0224】

ＰｒｏＳｅは、ユーザからの要求時にトリガされてよい。例えば、ユーザは、近くの友達を検出するようＷＴＲＵをトリガすることができる。「友達」という用語は、例えば、それが近くにある場合にユーザがそれとの接触を確立したいであろう個別エンティティ（例えば人物、店など）、加入者のグループまたはソーシャルネットワークグループ、ＰｒｏＳｅエリアサーバまたはＰｒｏＳｅ−ＧＷ、ローカルネットワークをとりわけ指す。

【0225】

ＰｒｏＳｅは、ネットワークからのページング時またはＰｒｏＳｅ開始要求時にトリガされてよい。例えば、ページングは、ＰｒｏＳｅ通信を確立したい友好的なＷＴＲＵの結果である場合がある。

【0226】

ＰｒｏＳｅは、ＰｒｏＳｅ可能リストが更新されたとき、近接性指示があったとき、ネットワークによってフィーチャがアクティブ化されたとき、ＰｒｏＳｅをサポートするセルを選択したときもしくはＰｒｏＳｅをサポートするセルへのハンドオーバを選択したとき、ＰｒｏＳｅをサポートするネットワークを選択したときもしくはＰｒｏＳｅをサポートするセルかＰｒｏＳｅ ＧＷのカバレッジに入ったとき、特定のＣＳＧ ＩＤもしくは特定のＡＰＮかＧＷ識別を選択したとき、ローカルＩＰアクセス（ＬＩＰＡ）サービス、管理されるリモートアクセス（ＭＲＡ）サービス、もしくは選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）サービスをアクティブ化したとき、または、ＰｒｏＳｅ制御セクションで述べたＰｒｏＳｅ許可制御パラメータのいずれかを選択したときに、トリガされてよい。

【0227】

ＷＴＲＵまたはネットワークは、ＰｒｏＳｅをトリガする決定を行うことができる。例えば、ＰｒｏＳｅは、ＷＴＲＵによってまたはユーザによって、別のユーザに向けて、または、別のユーザもしくはユーザグループもしくはソーシャルグループもしくは店などからの要求に応答して、トリガされてよい。

【0228】

ＰｒｏＳｅは、ネットワーク（またはＰｒｏＳｅサービスプロバイダ）からのプッシュサービスとすることができる。ネットワークは、ＰｒｏＳｅを自律的に開始することができる。例えば、ネットワークは、広告サービスを提供することができる。広告サービスを提供できるユーザが関心ポイントに近接すると、ネットワークオペレータまたはサービスプロバイダは、（例えばユーザプロファイルおよび事前に打ち合わせられた同意に基づいて）、ＰｒｏＳｅをトリガして、ＷＴＲＵ画面上に表示されるべき広告情報をプッシュすることができる。このような広告情報はまた、情報が依然としてＷＴＲＵの位置に関連があると仮定した場合にＷＴＲＵによっていつでも表示されるように利用可能な、ＷＴＲＵへのプッシュとすることもできる。このようなＰｒｏＳｅ開始は、ＭＭＥ、ＳＧＷ、ＰＧＷ、ＰｒｏＳｅ−ＧＷ、またはｅＮＢ／ＨｅＮＢによってトリガすることができる。

【0229】

ＰｒｏＳｅの終了、および、ＰｒｏＳｅベアラまたは接続の解放を行うことができる。ＰｒｏＳｅは、ＰｒｏＳｅ許可制御パラメータのいずれかに変化があり、それによりＰｒｏＳｅがもはや可能でなくなったときに、終了させることができる。例えば、ＰｒｏＳｅ通信は、ネットワークによって承諾された有効時間が切れたとき、ネットワーク構成もしくはＷＴＲＵ構成が変化したとき、または、ＰｒｏＳｅがサポートされないネットワーク部分もしくはネットワークへのモビリティがあったとき（ネットワークの全体もしくは当該部分がＰｒｏＳｅをサポートしないかＰｒｏＳｅをサポートするように構成されていないため、または新しいネットワークがＰｒｏＳｅをサポートしないため、または新しいｅＮＢ、ＨｅＮＢ、ＭＭＥ、ＳＧＷ、もしくはＰＧＷがＰｒｏＳｅをサポートしないため）、または、ネットワーク、ＷＴＲＵもしくはユーザがＰｒｏＳｅを終了すると決定したときに、終了してよい。ＷＴＲＵは、近接データを送るために、許容しきい値に達すればよい。

【0230】

課金モデルは、ＰｒｏＳｅをサポートするネットワークアーキテクチャに影響を及ぼすことがある。オペレータは、ＰｒｏＳｅサービスと、独立ＰｒｏＳｅプロバイダと、企業によって配置されるＰｒｏＳｅと、家庭によって配置されるＰｒｏＳｅとを配置することができる。課金は、固定レート（例えば月ごと）の課金に基づくことができる。

【0231】

事前合意済み／事前構成済みＱｏＳ属性を有するデフォルトＷＴＲＵベアラもしくはデフォルトＰＤＮ接続、または、事前合意済み／事前構成済みＱｏＳ属性を有する専用ＰＤＮを確立して、ＰｒｏＳｅ通信をサポートすることができる。この方式では、ＰｒｏＳｅ−ＧＷ、または、ネットワークオペレータによって信頼されるいずれか他のノード（ＳＧＷもしくはＰＧＷなど）が使用される場合は、ダウンリンクにおけるＱｏＳ（例えばＡＰＮ ＡＭＢＲに基づくレートポリシング）のためのポリシ制御施行機能（ＰＣＥＦ）が、ｅＮＢまたはＨｅＮＢ中にあってよい。

【0232】

また、消費されるデータボリュームを、Ｓ１アプリケーションプロトコル（Ｓ１−ＡＰ）メッセージを使用してネットワークに報告するための機能を、ｅＮＢまたはＨｅＮＢにおいて指定することもできる。

【0233】

ＡＦは、近接サポートを必要とするアプリケーションの「サポートされるフィーチャ」または「アプリケーション識別」をＰＣＲＦに明示的に示すことができる。これらは、ＡＡＲ ｄｉａｍｅｔｅｒメッセージにすでに含まれる既存の属性値パラメータ（ＡＶＰ）を使用して実施することができる。

【0234】

単一近接サービスＩＤを使用して、近接サービスを必要とするであろうアプリケーションに加入する他の任意のメンバを関連付けることができる。これらのメンバは、最適化された近接接続（ＯＰＣ）を介して接続されうる、グループの一部または個別ＷＴＲＵとすることができる。

【0235】

ＷＴＲＵのうちの一方がアイドルモードになったときの１または複数のシナリオでは、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラは解体されてよいが、ベアラのコンテキストは両方のＷＴＲＵ中に留まることができる。したがって、両方のＷＴＲＵが接続モードに戻ったとき、同じベアラを再確立することができる。また、一方のＷＴＲＵがアイドルモードである場合、ｅｎｄ−ｔｏ−ｅｎｄベアラの全体が解放されなくてもよく、ベアラのうちでこの特定のＷＴＲＵに接続された部分だけが解放されればよいことも可能であろう。

【0236】

このページングプロシージャ中に、これまで未知の「マッピングＩＤ」、または、古いマッピングＩＤを再アクティブ化するようｅＮＢに示す指示を、ｅＮＢに送ることができる。したがって、ＷＴＲＵ−１が接続モードに戻ると、ｅＮＢは、このベアラに対するｅＮＢを介したローカルパスを使用可能にすることができ、全てのピアツーピアデータは、このパス上でＷＴＲＵ−１からＷＴＲＵ−２に行くことができる。

【0237】

ＷＴＲＵは、使用している周知のアプリケーションを、登録メッセージに含めることができる。周知のアプリケーションは、ＶｏＩＰクライアント（Ｓｋｙｐｅ、Ｖｏｎａｇｅ）またはＳＮＳアプリケーション（Ｆａｃｅｂｏｏｋ）など、近接サービスから利益を得ることのできる広く使用されているスマートフォンアプリケーションとすることができる。情報は、さらに他の近接ベースサービスのために、ネットワークまたはアプリケーションサーバによって使用することができる。

【0238】

ＷＴＲＵは、ネットワークおよび無線リソースのセットアップを確立することができる。これは、ベアラリソース割振り要求またはベアラリソース修正を介して実施することができる。ネットワークは、近接プロシージャが特定のＷＴＲＵによってトリガされうるかどうかを受諾または拒否することが可能であってよい。

【0239】

図２１Ａおよび２１Ｂは共に、第１のＷＴＲＵ２１０５、第２のＷＴＲＵ２１１０、ｅＮＢ２１１５、ＭＭＥ２１２０、Ｄ２Ｄサーバ２１２５、およびＰＧＷ２１３０を含むワイヤレス通信システム２１００における、セルラトリガ式デバイス発見を伴うｅＮＢ内、ＭＭＥ内２重ＲＡＴの場合の例示的なサービス要求プロシージャの信号流れ図である。ＮＡＳレイヤアタッチプロシージャの一部としての登録（２１３５）の間、両方のＷＴＲＵ２１０５および２１１０は、８０２．１１ＲＡＴを使用してそれらがＤ２Ｄ対応であることを示すことができ、それぞれのＤ２Ｄ能力をＭＭＥ２１２０またはＤ２Ｄサーバ２１２５に送ることができる。ＭＭＥ２１２０は、ＷＴＲＵの登録時に、またはいずれか後の更新時に例えばトラッキングエリア更新（ＴＡＵ）プロシージャを使用して、ＷＴＲＵ２１０５および２１１０のＤ２Ｄ能力でＤ２Ｄサーバ２１２５を更新することができる。

【0240】

ＷＴＲＵ２１０５は、ベースラインプロシージャにより、ＷＴＲＵ２１１０への公共安全（ＰＳ）呼を確立することを試みることができる。ＷＴＲＵ２１０５および２１１０は、ベースラインＬＴＥプロシージャによりセットアップされたデフォルトＥＰＳベアラを確立することができる。ＷＴＲＵ２１０５は、ランダムアクセスチャネル（ＲＡＣＨ）および接続セットアッププロシージャを使用して、ＲＲＣ接続状態に移ることができる。ＷＴＲＵ２１１０がまだＲＲＣ接続状態でない場合、ＭＭＥ２１２０は、ページングプロシージャを使用して、ＷＴＲＵ２１１０をＲＲＣ接続状態にすることができる。この段階の後には、ＷＴＲＵ２１０５とＷＴＲＵ２１１０は両方とも、ＰＧＷ２１３０に接続されたデフォルトＥＰＳベアラ２１４０を有することができる。

【0241】

ＭＭＥ２１２０は、単独で、またはＤ２Ｄサーバ２１２５（もしくはＡＮＤＳＦやＰＣＲＦなど他のＥＰＣエンティティ）と協働して、ＷＴＲＵ２１０５および２１１０がＤ２Ｄ対応であること、およびそれらが８０２．１１ＲＡＴベースのＤ２Ｄリンクを使用して通信可能であろうことを識別することができる（２１４５）。これは、位置情報、測定値、セルＩＤ、セクタＩＤなど（ただしこれらに限定されない）に基づくことができる。ＷＴＲＵ２１０５および２１１０は、デバイスおよびサービス発見を実施することができる。

【0242】

図２２Ａおよび２２Ｂは共に、第１のＷＴＲＵ２２０５、第２のＷＴＲＵ２２１０、ｅＮＢ２２１５、ＭＭＥ２２２０、およびＤ２Ｄサーバ２２２５を含むワイヤレス通信システム２２００における、ｅＮＢ内ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。ローカルパス（単一ＲＡＴ）の呼管理のために、登録時（アタッチプロシージャ中で）、ＷＴＲＵ２２０５および２２１０は、それらがＤ２Ｄ対応であることを示すことができ、それぞれのＤ２Ｄ能力を送ることができる。ＭＭＥ２２２０は、ＷＴＲＵの登録時に、またはいずれかの後続の更新時に例えばＴＡＵプロシージャを使用して、ＷＴＲＵ２２０５および２２１０のＤ２Ｄ能力でＤ２Ｄサーバ２２２５を更新することができる。

【0243】

ＷＴＲＵ２２０５は、ＷＴＲＵ２２１０のＩＰアドレス、または別の特定の識別子を、セッション開始プロトコル（ＳＩＰ）プロシージャ（ＩＰマルチメディアサブシステム（ＩＭＳ）を含む）を介して得ることができる。ＷＴＲＵ２２０５は、サービス要求ＮＡＳメッセージに、ＷＴＲＵ２２１０のＩＰアドレス、ＳＩＰユニフォームリソース識別子（ＵＲＩ）、移動局国際加入者ディレクトリ番号（ＭＳＩＳＤＮ）、または、ＷＴＲＵ２２１０を識別するのに使用できる他の一時識別子を含めることができる。

【0244】

図２２Ａを参照すると、ＷＴＲＵ２２０５は、ベースラインプロシージャにより、ＷＴＲＵ２２１０へのＰＳ呼を確立することを試みる。ＷＷＴＲＵ２２０５および２２１０は、ベースラインＬＴＥプロシージャによりセットアップされたデフォルトＥＰＳベアラを確立することができる。ＷＴＲＵ２２０５は、ＲＡＣＨおよび接続セットアッププロシージャ２２３０を使用して、ＲＲＣ接続状態に移ることができる。ＷＴＲＵ２２１０がまだＲＲＣ接続状態でない場合、ＭＭＥ２２２０は、ページングプロシージャを使用して、ＷＴＲＵ２２１０をＲＲＣ接続状態にすることができる。この段階の後には、ＷＴＲＵ２２０５および２２１０は、ＰＧＷ（図示せず）に接続されたデフォルトＥＰＳベアラを有することができる。

【0245】

ＭＭＥ２２２０は、単独で、またはＤ２Ｄサーバ２２２５（もしくはＡＮＤＳＦ、ＰＣＲＦ、ＨＳＳなど、他のＥＰＣエンティティ）と協働して、ＷＴＲＵ２２０５と２２１０が両方ともＤ２Ｄ対応であること、およびそれらが同じｅＮＢ２２１５とのローカルパスの範囲内であろうことを識別することができる（２２３５）。Ｄ２Ｄサーバ２２２５は、論理エンティティとすることができ、その機能は種々のＥＰＣノード中で実行されてよい。

【0246】

図２２Ｂを参照すると、ＭＭＥ２２２０は、ＷＴＲＵ２２０５と２２１０との間のローカルパスを表すＤ２Ｄ ＥＰＳベアラに対応する２つの無線ベアラ２２４５をセットアップするために、１または複数の修正Ｓ１−ＡＰ Ｅ−ＲＡＢベアラセットアップ要求メッセージ２２４０をｅＮＢ２２１５に送ることができる。Ｄ２Ｄ ＥＰＳベアラは、ｅＮＢ２２１５とＳＧＷとの間のＳ１ベアラと、ＳＧＷとＰＧＷとの間のＳ５／Ｓ８ベアラとを有さない、特別なＥＰＳベアラである。

【0247】

ローカルパスを有するＥＰＳベアラ（Ｄ２Ｄ ＥＰＳベアラ）に対するＰＣＥＦ機能を、ｅＮＢ２２１５において実行することができる。ＰＧＷおよびＳＧＷはもはやＤ２Ｄローカルパスのデータ転送に関与しないであろうから、これは有益であろう。また、これにより、ＰＧＷがローカルパスに対応するＤ２Ｄ ＥＰＳベアラのセットアップに関与する必要性をなくすことができる。

【0248】

図２２Ｂを再び参照するが、ｅＮＢ２２１５は、Ｓ１−ＡＰ Ｅ−ＲＡＢベアラセットアップ要求メッセージ２２４０を受け取った後、ベースラインＬＴＥプロシージャにより無線ベアラをセットアップするために、ＲＲＣ接続再構成要求メッセージ２２５０をＷＴＲＵ２２０５および２２１０に送ることができる。ＷＴＲＵ２２０５および２２１０は、ＲＲＣ接続再構成完了メッセージ２２５５で応答して、無線ベアラがうまく確立されたことを示すことができる。ｅＮＢ２２１５は、２つのそれぞれの無線ベアラを介してＷＴＲＵ２２０５と２２１０との間でデータを中継して、特定のＤ２Ｄ接続のためのローカルパスを形成することができる。

【0249】

ローカルパスを有することについての決定は、例えばＭＭＥ２２２０、Ｄ２Ｄサーバ２２２５、および／または他のＥＰＣノードとの協調により、ｅＮＢ２２１５によって行うことができる。

【0250】

図２３Ａおよび２３Ｂは共に、第１のＷＴＲＵ２３０５、第２のＷＴＲＵ２３１０、第１のｅＮＢ２３１５、第２のｅＮＢ２３２０、ＭＭＥ２３２５、およびＤ２Ｄサーバ２３３０を含むワイヤレス通信システム２３００における、ｅＮＢ間ローカルパスをセットアップするための例示的なプロシージャの信号流れ図である。ｅＮＢ間ローカルパスは、ｅＮＢ２３１５と２３２０との間にＸ２インタフェースがあることを必要とする。

【0251】

ｅＮＢ内のケースと同様、ＭＭＥ２３２５が、ＷＴＲＵ２３０５および２３１０が呼に関与しておりＤ２Ｄローカルパス接続を有することができると識別したとき、ＭＭＥ２３２５は、ＷＴＲＵ２３０５および２３１０に対するローカルパスをセットアップする決定を行うことができる。ＭＭＥは、２つのＷＴＲＵに対する２つの無線ベアラをセットアップするために、修正Ｓ１−ＡＰ Ｅ−ＲＡＢベアラセットアップ要求メッセージ２３３５をｅＮＢ２３１５および２３２０の各々に送ることができる。

【0252】

図２３Ｂに示すように、ＷＴＲＵ２３０５と２３１０との間でローカルパスデータを交換するために、ｅＮＢ２３１５と２３２０との間でＧＰＲＳトンネリングプロトコル（ＧＴＰ）トンネル２３４０をセットアップすることができる。対応するｅＮＢのｅＮＢ特有識別子を、修正Ｓ１−ＡＰ Ｅ−ＲＡＢベアラセットアップ要求メッセージ２２３５中で搬送することができる。

【0253】

図２３Ａおよび２３Ｂを参照すると、アクセス層スタックプロトコルのデータプレーンレイヤ（例えばＰＤＣＰ、ＲＬＣ、ＭＡＣ、ＰＨＹ）は、ＷＴＲＵ２３０５および２３１０上で終端することができる。ｅＮＢ２３１５および２３２０は、協調して、これらのプロトコルレイヤに使用されるパラメータを決定することができる。ＷＴＲＵ２３０５に対するｅＮＢ２３１５は、確立されつつあるこの特定のＤ２Ｄローカルパスのための制御ｅＮＢになることができる。ｅＮＢ２３１５は、Ｄ２Ｄローカルパスに使用されることになるパラメータを協調させることおよび決定することを担うことができる。ローカルパスに関与するＷＴＲＵ２３１０に対するｅＮＢ２３２０は、Ｘ２−ＡＰインタフェースを介してＷＴＲＵ無線アクセス能力情報要素（ＩＥ）を搬送する新しいメッセージを使用することによって、ＷＴＲＵ２３１０の無線アクセス能力をｅＮＢ２３１５に送って決定の実施を補助することができる。

【0254】

Ｘ２−ＡＰインタフェースを介してＷＴＲＵ無線セットアップパラメータＩＥを搬送するメッセージによって、ｅＮＢ２３１５からの構成情報をｅＮＢ２３２０に送ってＷＴＲＵ２３１０の構成を可能にすることができる。これにより、ＷＴＲＵ２３０５についてのＤ２Ｄ構成情報が、ＷＴＲＵ２３１０についての構成情報と合致すること、およびその逆であることを、確実にすることができる。

【0255】

ローカルパスに関与するＷＴＲＵ２３０５および２３１０が２つの異なるＭＭＥを伴う場合（すなわちＭＭＥ間のケース）、２つのＭＭＥは、協調して、ＷＴＲＵ２３０５および２３１０がローカルパスを有することができると識別することができる。これは、Ｄ２Ｄサーバ２３３０および／または他のＥＰＣノードからの補助を必要とする場合がある。ＷＴＲＵ２３０５に対するＭＭＥ２３２５は、確立されつつあるこの特定のＤ２Ｄローカルパスのための制御ＭＭＥになることができる。

【0256】

ＭＭＥ２３２５は、ｅＮＢ２３１５と２３２０との間でローカルパスを確立できる可能性について、他方のＭＭＥと交渉することができる。これは、これらの交渉を可能にするようにＳ−１０インタフェースを拡張することによって、実施することができる。他方のＭＭＥがＭＭＥ２３２５と合意する場合は、他方のＭＭＥは、ｅＮＢ２３１５と協調して前述と同じかまたは同様のやり方でＷＴＲＵのためのローカルパス無線ベアラを構成するよう、ｅＮＢ２３２０に通知することができる。

【0257】

ＰＬＭＮ間ローカルパス呼の場合のローカルパスセットアッププロシージャは、異なるＰＬＭＮからのｅＮＢ２３１５と２３２０との間にＸ２インタフェースがあるという条件で、ｅＮＢ間ローカルパスについて上述したものと同様とすることができる。

【0258】

図２４に、パケットデータ収束プロトコル（ＰＤＣＰ）レイヤまでのアクセス層データプレーンプロトコルスタックレイヤがＷＴＲＵとｅＮＢとの間で終端するときの、例示的なプロトコルアーキテクチャを示す。このケースでは、ローカルパス無線ベアラについてのプロトコルアーキテクチャは、ベースラインＬＴＥにおけるものと同様とすることができる。データパケットは、ＷＴＲＵ−１からＷＴＲＵ−２に、ｅＮＢにおいてＩＰレベルでルーティングすることができる。ローカルＩＰゲートウェイ機能をｅＮＢにおいて追加して、ローカルパスのためのＩＰレベルルーティングを可能にすることができる。

【0259】

別の実施形態では、ＰＨＹおよびＭＡＣレイヤ以外のアクセス層データプレーンプロトコルレイヤは、ローカルパスに関与する２つのＷＴＲＵ間で直接に終端することができる。

【0260】

図２５に、Ｄ２Ｄローカルパスについての別の例示的なデータプレーンプロトコルスタックを示す。この例では、関与するｅＮＢは、ＭＡＣサービスデータユニット（ＳＤＵ）とＲＬＣ ＳＤＵとのいずれかとすることのできるデータパケットを中継することができる。このケースでは、ＩＰレベルルーティングは必要ない。

【0261】

このプロトコルアーキテクチャは、ローカルパスの動作に対して以下の影響を有することがある。このプロトコルアーキテクチャは、ある無線ベアラ（例えばｅＮＢ−１とＷＴＲＵ−１との間）からのペイロードが別の無線ベアラ（例えばｅＮＢ−２とＷＴＲＵ−２との間）上で送信されるようにするために、対応するｅＮＢにおいてＭＡＣセグメント化またはＲＬＣ再セグメント化を必要とする場合がある。追加のプロシージャをｅＮＢにおいて実行し、ベースラインＰＤＣＰ廃棄プロシージャと同様のプロシージャに準拠して、第２のリンク上の輻輳の後でｅＮＢのバッファの中に立ち往生したデータがあればそれをクリーンアップすることができる。ソースＷＴＲＵから宛先ＷＴＲＵまでｅｎｄ−ｔｏ−ｅｎｄでＲＬＣ再送を実施することができ、これはまた、再送に関連する遅延に影響を及ぼすことがある。これは、アクセス層データプレーンレイヤがＷＴＲＵとｅＮＢとの間で終端される場合と比較して、ｅＮＢ上の処理オーバヘッドおよび遅延を緩和することができる。

【0262】

ＬＴＥ Ｄ２Ｄ直接パスベアラを利用できるアプリケーションは、２つのグループに分類される。すなわち、Ｄ２Ｄを意識しているアプリケーションと、Ｄ２Ｄを意識していないアプリケーションである。

【0263】

Ｄ２Ｄを意識しているアプリケーションは、Ｄ２Ｄ接続を使用することの潜在的な利益を意識している。Ｄ２Ｄを意識しているアプリケーションは、Ｄ２Ｄ接続をセットアップするようセルラモデムに要求することができる。Ｄ２Ｄを意識しているアプリケーションはまた、それが接続のセットアップを要求している場合に、Ｄ２Ｄパス（および／または直接パスもしくはローカルパスに対する選好）が利用可能かどうか、またはＤ２Ｄパスが好まれるかどうかを示すこともできる。

【0264】

Ｄ２Ｄを意識しているアプリケーションのためのサービス登録を実施することができ、一時サービス名を割り振ることができる。Ｄ２Ｄを意識しているアプリケーションは、Ｄ２Ｄサービス発見プロシージャに登録して、Ｄ２Ｄサービス発見の結果を利用することができる。Ｄ２Ｄデバイス発見は、Ｄ２Ｄサービス発見の前に完了させることができる。

【0265】

セルラモデムは、Ｄ２Ｄアプリケーションに代わって、呼の間によりよい体感品質（ＱｏＥ）を得るために、Ｄ２Ｄサービスが実現可能なときにＤ２Ｄサービスを持つことをサービス要求メッセージ中で明示的に要求することができる。このメッセージは、利用可能なら相手のＤ２Ｄデバイス識別子および一時サービス名を含んでよい。

【0266】

Ｄ２Ｄを意識しているアプリケーションは、Ｄ２Ｄ接続アプリケーションを使用することの潜在的な利益を知らないか、または、サービスがベースラインＬＴＥベアラによって提供されるかそれともＤ２Ｄベアラを介して提供されるかを気にしない。

【0267】

このような場合、オペレータは、接続を最適化する機会を認識することができ、元の呼がベースラインＬＴＥプロシージャを介して確立された後で、２つの通信側の間でＤ２Ｄ接続を構成することができる。

【0268】

ベースライン／インフラストラクチャ呼がベースラインＬＴＥにより確立され、オペレータは、２つの通信側の間でＤ２Ｄ直接パス接続を有する機会を見出す。オペレータは、Ｄ２Ｄ直接パスサービスハンドオーバのためのインフラストラクチャのためのプロシージャを開始することができる。

【0269】

以下、Ｄ２Ｄ呼管理を可能にするためのメッセージングおよびインタフェース更新についての実施形態を開示する。これらの更新は、ネットワーク中のＵｕインタフェースならびに他のいくつかのインタフェース（Ｘ２インタフェース、Ｓ１−ＡＰインタフェース、およびＳ１０インタフェースを含むがこれらに限定されない）上のいくつかのＲＲＣおよびＮＡＳメッセージに影響を及ぼす。

【0270】

Ｄ２Ｄ構成は、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを介して提供することができる。一実施形態では、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージによって、Ｄ２Ｄ直接パスリンクを構成することができる。Ｄ２Ｄリンクは、２次セルに類似する別のキャリアと考えることができる。これは、ｓＣｅｌｌＴｏＡｄｄＭｏｄＬｉｓｔ−ｒ１０中のｓＣｅｌｌＴｏＡｄｄＭｏｄの新しいＤ２Ｄ要素を使用してＤ２Ｄリンクを表すことによって、達成することができる。Ｄ２Ｄリンクの新しいフィールドをｓＣｅｌｌＴｏＡｄｄＭｏｄに加えて、追加されることになる新しいキャリアがＤ２Ｄ直接パスリンクであることを示すことができる。

【0271】

Ｄ２Ｄリンクの無線リソース構成情報など、他の構成情報は、従来のフィールド中で搬送することができる。直接パス通信の目的で、１または複数の新しい無線ベアラが各ＷＴＲＵ中でセットアップされる。直接パスを介して種々のＱｏＳ要件を有する種々のフローを通信する必要がある場合は、複数のベアラを構成することができる。ベアラセットアップは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ中のｄＴｂ−ｔｏＡｄｄＭｏｄＬｉｓｔ ＩＥを使用して行うことができる。

【0272】

Ｄ２Ｄリンクを含むｄｒｂ−ＴｏＡｄｄＭｏｄＬｉｓｔを使用して確立されたＤ２Ｄ無線ベアラは、Ｄ２Ｄ直接無線ベアラと考えることができる。あるいは、Ｄ２Ｄ直接パス無線ベアラは、Ｄ２Ｄリンクを新しいキャリアとして追加せずに、ｄｒｂ−ＴｏＡｄｄＭｏｄＬｉｓｔへの拡張を使用して確立することもできる。新しいフィールドであるＤ２Ｄ−Ｃｏｎｆｉｇを、ｄｒｂ−ＴｏＡｄｄＭｏｄＬｉｓｔ中のＤＲＢ−ＴｏＡｄｄＭｏｄ要素に追加することができ、このフィールドは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージに含まれるＲａｄｉｏＲｅｓｏｕｒｃｅＣｏｎｆｉｇＤｅｄｉｃａｔｅｄ ＩＥ中のＤ２Ｄ無線ベアラを表すことができる。Ｄ２Ｄ−Ｃｏｎｆｉｇは、無線ベアラに関するＤ２Ｄ特有情報を含むことができ、この情報は、Ｄ２Ｄ ＲＢのタイプ：直接パス、および、Ｄ２Ｄに関係する一連の構成要素（例えば、ＸＰＳＣＨ＿ｃｏｎｆｉｇ：スケジューリングや基準シンボル電力など、ＸＰＦＢＣＨ＿ｃｏｎｆｉｇ：電力やリソースなど、Ｍｅａｓｕｒｅｍｅｎｔ＿ｃｏｎｆｉｇ：Ｄ２Ｄについての新しい測定タイプ）を含むが、これらに限定されない。

【0273】

Ｄ２Ｄローカルパスリンクを構成するためのＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージは、ベースライン無線ベアラをセットアップするのに使用されるものと、ある程度同一であってよい。

【0274】

ｍｏｂｉｌｉｔｙＣｏｎｔｒｏｌＩｎｆｏ ＩＥを使用して、または異なるＩＥによって、直接パスに関する周波数帯域情報をＷＴＲＵに通信することができる。これは例えば、直接パス通信が発見プロセスとは異なる帯域で行われる場合に、または、ＰＬＭＮ間のケースで２つのＰＬＭＮが異なる帯域を直接パス通信に使用する場合に、必要であることがある。

【0275】

無線構成パラメータは、ＷＴＲＵ−１とＷＴＲＵ−２との間で合致してよい。例えば、ＴＤＤ−Ｃｏｎｆｉｇ ＩＥ中でＷＴＲＵ−１に対して指定されたｓｕｂｆｒａｍｅＰａｔｔｅｒｎは、ＷＴＲＵ−２についての対応する構成をミラーリングすることができ、したがって、一方のＷＴＲＵの送信間隔は、他方のＷＴＲＵの受信間隔に対応する。

【0276】

アクセス層上のセキュリティを提供するために、ＲＲＣ再構成プロセスの一部として、直接パスベアラをそれ自体の暗号化鍵で構成することができる。これらの鍵は、インフラストラクチャ通信に使用される鍵とは異なってもよい。というのは、後者は、ネットワークにとっては利用可能だが他のＷＴＲＵにとっては利用不可能なＷＴＲＵの秘密データから導出されるからである。異なる無線ベアラ（インフラストラクチャベアラと直接パス）に対して異なる鍵を使用することは、ベースラインＲ８／Ｒ１０ ＬＴＥ標準からの逸脱である。この目的で、ｋｅｙＣｈａｎｇｅＩｎｄｉｃａｔｏｒの代わりに、Ｄ２Ｄベアラに対する新しいｋｅｙＡｄｄＩｎｄｉｃａｔｏｒを、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ内のｓｅｃｕｒｉｔｙＣｏｎｆｉｇＨＯ ＩＥに追加することができる。

【0277】

ＷＴＲＵは、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受け取って処理した後、直接パス上でハンドシェーク信号を交換する。これらのハンドシェーク信号は、物理レイヤにおけるものとすることができる。ＷＴＲＵは、これらのハンドシェーク信号を受け取ると、ＲＲＣ Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ ＣｏｍｐｌｅｔｅメッセージをｅＮＢに送信することができる。この後には、ＷＴＲＵは、直接パス上でデータを送受信する準備ができている。

【0278】

ネットワークは、ＷＴＲＵのＤ２Ｄ能力情報を得ることができる。例えばこれは、ＷＴＲＵＣａｐａｂｉｌｉｔｙＥｎｑｕｉｒｙメッセージ中で搬送されるｕｅ−ＣａｐａｂｉｌｉｔｙＲｅｑｕｅｓｔ中のＵＥ−Ｄ２Ｄ−Ｃａｐａｂｉｌｉｔｙの新しいフィールドを追加して、ＷＴＲＵ Ｄ２Ｄ無線アクセス能力を返すようＷＴＲＵをトリガするようにすることによって、達成することができる。

【0279】

Ｄ２Ｄ対応ＷＴＲＵは、そのＤ２Ｄ能力についてネットワークに通知することができ、これは例えば、ＷＴＲＵＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎメッセージを使用して、ＵＥ−ＣａｐａｂｉｌｉｔｙＲＡＴ−ＣｏｎｔａｉｎｅｒＬｉｓｔ中のＵＥ−ＥＵＴＲＡ−Ｃａｐａｂｉｌｉｔｙ ＩＥと同様のＵＥ−Ｄ２Ｄ−Ｃａｐａｂｉｌｉｔｙ ＩＥを含めて、ＷＴＲＵのＤ２Ｄ無線アクセス能力を搬送することによって、行うことができる。ＷＴＲＵ能力情報は、Ｄ２Ｄ対応ＷＴＲＵが動作できる帯域内／帯域外キャリア周波数を含んでよい。ＷＴＲＵ能力情報は、Ｄ２Ｄ ＷＴＲＵが単一ＲＡＴ（例えば３ＧＰＰ ＲＡＴ）を使用して動作できるかどうか、およびＲＡＴに対するいずれかの関連する制限、または、異なるＲＡＴ（例えば、８０２．１１やＢｌｕｅｔｏｏｔｈなどの非３ＧＰＰ ＲＡＴ）上で動作できるかどうかを含んでよい。Ｄ２Ｄリンクの３ＧＰＰ ＲＡＴ能力は、ＦＤＤおよび／またはＴＤＤに対するサポート、ならびに、ＰＨＹ、ＭＡＣ、ＲＬＣ、およびＰＤＣＰレイヤの無線アクセス能力などを含んでよい。Ｄ２Ｄリンクの非３ＧＰＰ ＲＡＴ能力は、例えば、８０２．１１のどの改正か（ａ、ｂ、ｅ、ｇ、ｎ、ａｃ、ａｄなど）を含んでよい。ＷＴＲＵ能力情報はまた、以下のうちの少なくとも１つを含んでよい。すなわち、シームレスなハンドオーバサポートに関係する能力；インフラストラクチャ、Ｄ２Ｄ直接パス、および／またはＤ２Ｄローカルパスにわたる集約に対するサポート；単方向Ｄ２Ｄに対するサポート；Ｄ２Ｄリンクを介してサポートされる暗号化およびセキュリティプロトコル；ＷＴＲＵ中でのＰＣＥＦ実行のための信頼ゾーン能力；デバイス発見に関係するサポート；Ｄ２Ｄリンクについての最大送信電力能力；Ｄ２Ｄリンクについての最大バッファリング能力；ＩＰの下の論理インタフェースサポートに関係する能力；Ｄ２Ｄポリシに関係する選好；Ｄ２Ｄマルチキャストに対するサポートなどである。

【0280】

Ｄ２Ｄサービスをサポートするために、ＮＡＳメッセージに対する更新を行うことができる。サービス要求メッセージは、以下のＤ２Ｄパラメータを含んでよい。すなわち、宛先ＵＥのＤ２Ｄデバイス識別子と、選択されたもしくは好ましいＤ２Ｄ関連サービス（Ｄ２Ｄ直接パス、Ｄ２Ｄローカルパス、他ＲＡＴ直接パスなど）を示すための、Ｓｅｒｖｉｃｅ Ｔｙｐｅ ＩＥの新しい値とである。または、サービス要求メッセージは、Ｄ２Ｄパス選好を示すための、Ｄ２Ｄ Ｐｒｅｆｅｒｒｅｄ Ｐａｔｈの新しいＩＥタイプを定義することができる。

【0281】

ＷＴＲＵから受け取ったＤ２Ｄ無線能力は、ＷＴＲＵ Ｃａｐａｂｉｌｉｔｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｄｉｃａｔｉｏｎ Ｓ１−ＡＰメッセージに含めることができる。直接パスは、ユーザプレーンデータのみ、または、ユーザプレーンと制御プレーンの両方のデータ（例えばＲＲＣおよびＮＡＳ）を搬送することができる。これらの目的の各々で、別々のセキュリティ鍵を構成することができる。ＮＡＳ Ｓｅｃｕｒｉｔｙ Ｍｏｄｅ Ｃｏｍｍａｎｄを使用して、ＮＡＳのためのセキュリティをセットアップすることができる。

【0282】

Ｓ１−ＡＰ Ｅ−ＲＡＢ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージに対する更新を行って、Ｄ２ＤベアラをセットアップするようＭＭＥがｅＮＢに通知できるようにすることができる。新しいフィールドであるＤ２Ｄ−Ｔｙｐｅを、Ｅ−ＲＡＢ Ｔｏ Ｂｅ Ｓｅｔｕｐ Ｉｔｅｍ ＩＥに追加することができる。このフィールドが存在する場合、このフィールドは、セットアップされることになる無線ベアラがＤ２Ｄ直接パスまたはＤ２Ｄローカルパス無線ベアラであることを示す。

【0283】

追加の情報をＭＭＥからｅＮＢに提供して、Ｄ２Ｄ直接パスとＤ２Ｄローカルパスの両方の場合のｅＮＢ間、ＭＭＥ間、またはＰＬＭＮ間のケースを容易にすることができる。これらは、対応するｅＮＢのｅＮＢ識別子（例えばＧＵＭＭＥＩ＋ｅＮＢ ＩＤ）、宛先ＷＴＲＵの一時ＷＴＲＵ識別、リモートＷＴＲＵのＷＴＲＵ Ｄ２Ｄ能力情報、リモートＷＴＲＵのポリシ情報（適用可能なら）、リモートＷＴＲＵの発見可能性選好、一時サービス名（適用可能なら）、このサービスがｅＮＢ中でいずれかによってすでに使用されているかどうかチェックするための一時サービス名に関係するクエリ、などを含んでよいが、これらに限定されない。

【0284】

２つのｅＮＢ間のＸ２−ＡＰインタフェースに対する更新を行って、Ｄ２Ｄベアラをセットアップするための協調、Ｄ２Ｄリンクスケジューリングを実施するための協調、ローカルパスに関係するデータ交換などを含めた（ただしこれらに限定されない）フィーチャをサポートすることができる。

【0285】

以下の新しいメッセージを追加することができる。Ｄ２Ｄ ＲＡＢ Ｓｅｔｕｐ Ｒｅｑｕｅｓｔメッセージは、Ｄ２Ｄ直接パスＲＢ構成に関する協調を要求するために、制御（マスタ）ｅＮＢによって、協働する（スレーブ）ｅＮＢに送ることができる。このメッセージは、以下のパラメータを搬送することができる。すなわち、制御ｅＮＢのｅＮＢ識別子、ならびに、ソースおよびターゲットＷＴＲＵのＤ２Ｄデバイス識別子、提案されるＤ２Ｄリンク構成（例えば、アンテナ、帯域幅、周波数帯域、多元接続方式、スケジューリングオプション等）、ＱｏＳパラメータ、サポートされるセキュリティパラメータなどである。

【0286】

Ｄ２Ｄ ＲＡＢ Ｓｅｔｕｐ Ｒｅｓｐｏｎｓｅメッセージは、協働するｅＮＢによって制御ｅＮＢに送ることができる。このメッセージは、以下のパラメータを搬送することができる。すなわち、制御ｅＮＢによってＤ２Ｄ Ｓｅｔｕｐ ｒｅｑｕｅｓｔメッセージ中で提供された提案されるＤ２Ｄリンク構成からのターゲットｅＮＢの選好、セキュリティパラメータに関するターゲットｅＮＢの選好、Ｄ２Ｄリンクに利用できる無線リソースに関する選好である。

【0287】

Ｄ２Ｄ Ｓｃｈｅｄｕｌｅ Ｒｅｑｕｅｓｔメッセージは、ＸＬ上の新しいスケジューリングが必要なときに、制御ｅＮＢによって、協働するｅＮＢに送ることができる。このメッセージは、提案されるスケジューリングパラメータ（例えば、ＲＢ割振り、最大Ｔｘ電力レベル、期間など）を含んでよい。

【0288】

Ｄ２Ｄ Ｓｃｈｅｄｕｌｅ Ｒｅｓｐｏｎｓｅメッセージは、Ｄ２Ｄ Ｓｃｈｅｄｕｌｅ Ｒｅｑｕｅｓｔメッセージに応答するために、協働するｅＮＢによって制御ｅＮＢに送ることができる。このメッセージは、ターゲットｅＮＢによって好まれるスケジューリングパラメータを含んでよい。

【0289】

Ｄ２Ｄ ＷＴＲＵ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｃａｐａｂｉｌｉｔｙメッセージは、協働するｅＮＢによって制御ｅＮＢに送ることができ、Ｄ２Ｄ ＷＴＲＵの無線アクセス能力（ＵＥからのＵＥ−Ｄ２Ｄ−Ｃａｐａｂｉｌｉｔｙ ＩＥ）を搬送することができる。

【0290】

Ｓ１０インタフェースを更新して、Ｄ２ＤサービスをサポートするようにＭＭＥ間およびＰＬＭＮ間のケースを処理することができる。Ｄ２Ｄベアラ確立に潜在的に関与する可能性のあるＭＭＥは、以下の情報を交換することができる。すなわち、Ｄ２ＤがターゲットＭＭＥによってサポートされる場合に、ターゲットＭＭＥによってサポートされるＤ２Ｄサービス、対応するｅＮＢのｅＮＢ識別子（例えばＧＵＭＭＥＩ＋ｅＮＢ ＩＤ）、宛先ＷＴＲＵの一時ＷＴＲＵ識別、リモートＷＴＲＵのＷＴＲＵ Ｄ２Ｄ能力情報、リモートＷＴＲＵのポリシ情報（適用可能なら）、リモートＷＴＲＵの発見可能性選好、一時サービス名（適用可能なら）、このサービスがｅＮＢ中でいずれかによってすでに使用されているかどうかチェックするための一時サービス名に関係するクエリなどだが、これらに限定されない。

【0291】

２つのｅＮＢ間で利用可能なＸ２−ＡＰインタフェースがない場合、Ｄ２Ｄ無線ベアラおよびＤ２Ｄスケジューリングを構成する協調は、Ｓ１０インタフェースを介してＭＭＥの助けにより達成することができる。Ｘ２−ＡＰインタフェースについて上に指定したのと同様のメッセージを、Ｓ１０インタフェース上で使用されるＧＴＰｖ２−Ｃ仕様に追加することができる。

【0292】

Ｄ２Ｄサポートのためにシステム情報を更新することができる。以下の情報をシステム情報に含めることができる。すなわち、Ｄ２Ｄ動作が現在可能かどうかを示すインジケータ；Ｄ２Ｄについての負荷インジケータ；Ｄ２Ｄマルチキャストサービスがサポートされるかどうかを示すためのインジケータ；２重ＲＡＴ Ｄ２Ｄリンクに対するサポートおよび他のＲＡＴ詳細、Ｄ２Ｄローカルパスに対するサポート；Ｄ２Ｄ直接パスに対するサポート；Ｄ２Ｄリンクのキャリア周波数および対応する帯域幅（リソースは動的にスケジュールされることがある）ならびに近傍発見ゾーン帯域幅および位置（例えばＵＳＩＭ中で事前定義済みであることがある）を含めた、帯域内情報；Ｄ２Ｄリンクのキャリア周波数および対応する帯域幅（リソースは動的にスケジュールされることがある）ならびに近傍発見ゾーン帯域幅および位置（例えばＵＳＩＭ中で事前定義済みであることがある）を含めた、帯域外情報などだが、これらに限定されない。

【0293】

実施形態
１．データを転送するために第１のワイヤレス送受信ユニット（ＷＴＲＵ）によって実施される方法であって、
第１のＷＴＲＵがアイドルモードに移行することであって、第１のＷＴＲＵと第２のＷＴＲＵとの間に接続された直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラが解体されること、および、
第１のＷＴＲＵがページング信号の受信に応答して接続モードに移行することであって、ページング信号は、デフォルトパケットデータネットワーク（ＰＤＮ）接続を介してまたはＰＤＮ接続へのデフォルトベアラを介して第１のＷＴＲＵに送信された複数のパケットのうちの第１のパケットによってトリガされ、第１のパケットは第１のＷＴＲＵの宛先インターネットプロトコル（ＩＰ）アドレスを有することを含む方法。

【0294】

２．第１のＷＴＲＵがＰＤＮ接続のＩＰアドレスを受信することをさらに含み、ＰＤＮ接続のＩＰアドレスは、第１のパケットを送信した第２のＷＴＲＵによって割り当てられる、実施形態１の方法。

【0295】

３．第１のＷＴＲＵが、新たに確立された直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介して、第２のＷＴＲＵから複数のパケットのうちの残りのパケットを受信することをさらに含む、実施形態１〜２のいずれか１つにおける方法。

【0296】

４．第１のパケットは廃棄され、
第１のＷＴＲＵが、新たに確立された直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介して、複数のパケットのうちの第１のパケットおよび残りのパケットを受信することをさらに含む、実施形態１〜３のいずれか１つにおける方法。

【0297】

５．ページング信号は、進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）またはサービングゲートウェイ（ＳＧＷ）からトリガメッセージを受信するのに応答してモビリティ管理エンティティ（ＭＭＥ）においてトリガされる、実施形態１〜４のいずれか１つにおける方法。

【0298】

６．第１のＷＴＲＵが、少なくとも１つの近接対応デバイスを接続するための複数のリソースを要求するベアラリソース割振り要求メッセージを生成することをさらに含む、実施形態１〜５のいずれか１つにおける方法。

【0299】

７．ベアラリソース割振り要求メッセージは近接ＷＴＲＵユーザのリストを含み、第１のＷＴＲＵは、最適なデバイス間（Ｄ２Ｄ）通信をサポートするための最適化された近接接続（ＯＰＣ）を近接ＷＴＲＵユーザと確立することができる、実施形態６の方法。

【0300】

８．第１のＷＴＲＵおよび第２のＷＴＲＵは、同じトラッキングエリア中にあり相互に通信したいと望んでいると決定される、実施形態１〜７のいずれか１つにおける実施形態１の方法。

【0301】

９．データを転送するためにネットワークノードによって実施される方法であって、
ネットワークノードが、ワイヤレス送受信ユニット（ＷＴＲＵ）がアイドルモードに移行するのに応答して、ネットワークノードとＷＴＲＵとの間に接続されたｅｎｄ−ｔｏ−ｅｎｄベアラの第１の部分を解体すること、
ネットワークノードがｅｎｄ−ｔｏ−ｅｎｄベアラの第２の部分を介して複数のパケットのうちの第１のパケットを受信すること、
ネットワークノードが、接続モードに移行するようＷＴＲＵをトリガするための第１のメッセージを送信すること、および、
ネットワークノードが、ｅｎｄ−ｔｏ−ｅｎｄベアラの第１の部分を再確立するための第２のメッセージを送信することを含む方法。

【0302】

１０．第１のメッセージはモビリティ管理エンティティ（ＭＭＥ）に送信される、実施形態９の方法。

【0303】

１１．第２のメッセージは無線リソース制御（ＲＲＣ）再構成要求メッセージである、実施形態９の方法。

【0304】

１２．ネットワークノードは進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）である、実施形態９の方法。

【0305】

１３．別のＷＴＲＵがｅｎｄ−ｔｏ−ｅｎｄベアラを介して残りのパケットを送信する、実施形態９〜１２のいずれか１つにおける方法。

【0306】

１４．第１のパケットは廃棄され、
ネットワークノードがｅｎｄ−ｔｏ−ｅｎｄベアラを介して複数のパケットのうちの第１のパケットおよび残りのパケットを受信することをさらに含む、実施形態９〜１３のいずれか１つにおける方法。

【0307】

１５．データを転送するために第１のネットワークノードによって実施される方法であって、
第１のネットワークノードが、第１のワイヤレス送受信ユニット（ＷＴＲＵ）がアイドルモードに移行するのに応答して、第２のＷＴＲＵと通信するために第１のＷＴＲＵによって使用される第１のベアラに関連付けられた第１のマッピング識別（ＩＤ）を非アクティブ化すること、
第１のネットワークノードが第２のベアラを介して複数のパケットのうちの第１のパケットを受信すること、および、
第１のネットワークノードが第１のパケットを第２のネットワークノードに転送することであって、第１のパケットは、第１のＷＴＲＵに送信されるページング信号をトリガすることを含む方法。

【0308】

１６．ページング信号は第１のＷＴＲＵを接続モードに移行させる、実施形態１５の方法。

【0309】

１７．第２のマッピングＩＤに応答して、または第１のマッピングＩＤを再アクティブ化する指示に応答して、第１のＷＴＲＵと第２のＷＴＲＵとの間でデータを転送する際に経由できるローカルパスが確立される、実施形態１６の方法。

【0310】

１８．第１のネットワークノードはパケットデータネットワークゲートウェイ（ＰＧＷ）またはサービングゲートウェイ（ＳＧＷ）である、実施形態１５〜１７のいずれか１つにおける方法。

【0311】

１９．第１のネットワークノードは近接サービス（ＰｒｏＳｅ）ゲートウェイである、実施形態１５〜１８のいずれか１つにおける方法。

【0312】

２０．第２のネットワークノードは進化型Ｎｏｄｅ−Ｂ（ｅＮＢ）である、実施形態１５〜１９のいずれか１つにおける方法。

【0313】

２１．第１のワイヤレス送受信ユニット（ＷＴＲＵ）であって、
デフォルトパケットデータネットワーク（ＰＤＮ）接続を介してまたはＰＤＮ接続へのデフォルトベアラを介して複数のパケットのうちの第１のパケットを第２のＷＴＲＵに送信するようにさらに構成された回路を備え、第１のパケットは第２のＷＴＲＵの宛先インターネットプロトコル（ＩＰ）アドレスを有し、
回路は、ＰＤＮ接続にＩＰアドレスを割り当て、ＰＤＮ接続のＩＰアドレスを第２のＷＴＲＵに送信するようにさらに構成された、第１のＷＴＲＵ。

【0314】

２２．回路は、直接ＷＴＲＵ−ｔｏ−ＷＴＲＵベアラを介して残りのパケットを送信するようにさらに構成された、実施形態２１の第１のＷＴＲＵ。

【0315】

２３．回路は、少なくとも１つの近接対応デバイスを接続するための複数のリソースを要求するベアラリソース割振り要求メッセージを生成するようにさらに構成された、実施形態２１〜２２のいずれか１つにおける第１のＷＴＲＵ。

【0316】

２４．ワイヤレス送受信ユニット（ＷＴＲＵ）がアイドルモードに移行するのに応答して、ネットワークノードとＷＴＲＵとの間に接続されたｅｎｄ−ｔｏ−ｅｎｄベアラの第１の部分を解体するように構成された回路と、
ｅｎｄ−ｔｏ−ｅｎｄベアラの第２の部分を介して複数のパケットのうちの第１のパケットを受信するように構成された回路と、
接続モードに移行するようＷＴＲＵをトリガするための第１のメッセージを送信するように構成された回路と、
ｅｎｄ−ｔｏ−ｅｎｄベアラの第１の部分を再確立するための第２のメッセージを送信するように構成された回路とを備えるネットワークノード。

【0317】

２５．パケットデータネットワークゲートウェイ（ＰＧＷ）またはサービングゲートウェイ（ＳＧＷ）である、実施形態２４のネットワークノード。

【0318】

２６．近接サービス（ＰｒｏＳｅ）ゲートウェイである、実施形態２４のネットワークノード。

【0319】

以上では特徴および要素を特定の組合せで述べているが、各特徴または要素は、単独で、または他の特徴および要素との任意の組合せで使用できることを、当業者なら理解するであろう。加えて、本明細書に述べた方法は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み入れられたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実施することができる。コンピュータ可読媒体の例としては、電子信号（有線またはワイヤレス接続を介して伝送される）、およびコンピュータ可読記憶媒体が挙げられる。コンピュータ可読記憶媒体の例としては、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、磁気媒体（例えば内蔵ハードディスクまたは取外し可能ディスク）、光磁気媒体、および、コンパクトディスク（ＣＤ）またはディジタル多用途ディスク（ＤＶＤ）などの光学媒体が挙げられるが、これらに限定されない。ＷＴＲＵ、ＵＥ、端末、基地局、Ｎｏｄｅ−Ｂ、ｅＮＢ、ＨＮＢ、ＨｅＮＢ、ＡＰ、ＲＮＣ、ワイヤレスルータ、または任意のホストコンピュータ中で使用するための、無線周波数送受信機を、プロセッサをソフトウェアと共に使用して実現することができる。

【図1A】

【図1B】

【図1C】

【図2A】

【図2B】

【図2C】

【図3A】

【図3B】

【図3C】

【図3D】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9A】

【図9B】

【図10A】

【図10B】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16A】

【図16B】

【図17】

【図18】

【図19】

【図20】

【図21A】

【図21B】

【図22A】

【図22B】

【図23A】

【図23B】

【図24】

【図25】