(57)【特許請求の範囲】
【請求項１】
無線送信／受信ユニット（ＷＴＲＵ）によって実行される方法であって、
前記ＷＴＲＵによって、ロングタームエボリューション（ＬＴＥ）無線アクセス技術（ＲＡＴ）を使用して、非ＬＴＥ  ＲＡＴを使用するための情報を受信するステップと、
前記ＷＴＲＵによって、前記非ＬＴＥ  ＲＡＴを使用して、発見情報を受信するステップと、
前記ＷＴＲＵによって、前記発見情報に基づいて、デバイスツーデバイス（Ｄ２Ｄ）通信についての前記非ＬＴＥ  ＲＡＴを監視するステップと、
前記ＷＴＲＵによって、前記ＬＴＥ  ＲＡＴを使用して、前記発見情報に基づいて報告を送信するステップと、
前記ＷＴＲＵによって、前記ＬＴＥ  ＲＡＴを使用して、前記ＷＴＲＵが前記非ＬＴＥ  ＲＡＴを使用して別のＷＴＲＵとのＤ２Ｄ通信リンクを確立することを可能にするメッセージを受信するステップと、
前記ＷＴＲＵによって、前記非ＬＴＥ  ＲＡＴを使用して、前記受信されたメッセージに基づいて前記Ｄ２Ｄ通信リンク上で別のＷＴＲＵと通信するステップと
を備えたことを特徴とする方法。
【請求項２】
前記ＷＴＲＵによって、近接検出構成をｅＮＢから受信するステップをさらに備えたことを特徴とする請求項１に記載の方法。
【請求項３】
前記Ｄ２Ｄ通信リンクは、少なくとも１つの無線リソース制御（ＲＲＣ）接続再構成メッセージをｅＮＢから受信することにさらに基づいていることを特徴とする請求項１に記載の方法。
【請求項４】
前記ＷＴＲＵによって、少なくとも１つの発見信号プロパティが閾値を下回っていると検出するステップと、
前記ＷＴＲＵによって、インフラストラクチャパスへのハンドオーバを開始するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項５】
前記ＷＴＲＵによって、Ｄ２Ｄ通信についてのセキュリティ構成を受信するステップと、
前記ＷＴＲＵによって、前記Ｄ２Ｄ通信に適用可能なセキュリティパラメータを決定するステップと、
前記ＷＴＲＵによって、前記Ｄ２Ｄ通信についてのセキュリティをアクティブ化するステップと
をさらに備えたことを特徴とする請求項１に記載の方法。
【請求項６】
無線送信／受信ユニット（ＷＴＲＵ）であって、
ロングタームエボリューション（ＬＴＥ）無線アクセス技術（ＲＡＴ）を使用して、非ＬＴＥ  ＲＡＴを使用するための情報を受信する手段と、
前記非ＬＴＥ  ＲＡＴを使用して、発見情報を受信する手段と、
前記発見情報に基づいて、デバイスツーデバイス（Ｄ２Ｄ）通信についての前記非ＬＴＥ  ＲＡＴを監視する手段と、
前記ＬＴＥ  ＲＡＴを使用して、前記発見情報に基づいて報告を送信する手段と、
前記ＬＴＥ  ＲＡＴを使用して、前記ＷＴＲＵが前記非ＬＴＥ  ＲＡＴを使用して別のＷＴＲＵとのＤ２Ｄ通信リンクを確立することを可能にするメッセージを受信する手段と、
前記非ＬＴＥ  ＲＡＴを使用して、前記受信されたメッセージに基づいて前記Ｄ２Ｄ通信リンク上で別のＷＴＲＵと通信する手段と
を備えたことを特徴とするＷＴＲＵ。
【請求項７】
近接検出構成をｅＮＢから受信する手段をさらに備えたことを特徴とする請求項６に記載のＷＴＲＵ。
【請求項８】
前記Ｄ２Ｄ通信リンクは、少なくとも１つの無線リソース制御（ＲＲＣ）接続再構成メッセージをｅＮＢから受信することにさらに基づいていることを特徴とする請求項６に記載のＷＴＲＵ。
【請求項９】
少なくとも１つの発見信号プロパティが閾値を下回っていると検出する手段と、
インフラストラクチャパスへのハンドオーバを開始する手段と
をさらに備えたことを特徴とする請求項６に記載のＷＴＲＵ。
【請求項１０】
Ｄ２Ｄ通信についてのセキュリティ構成を受信する手段と、
前記Ｄ２Ｄ通信に適用可能なセキュリティパラメータを決定する手段と、
前記Ｄ２Ｄ通信についてのセキュリティをアクティブ化する手段と、
をさらに備えたことを特徴とする請求項６に記載のＷＴＲＵ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は無線通信に関する。
【背景技術】
【０００２】
関連出願の相互参照
本出願は、２０１２年５月３１日に出願された米国仮特許出願第６１／６５３，６４３号、および２０１３年５月１日に出願された米国仮特許出願第６１／８１８，１８２号の利益を主張するものであり、これらの出願の内容は参照により本明細書に組み込まれる。
【０００３】
無線モバイルデータに対する需要は爆発的に増加し続けており、このことは、世界中で使用されるスマートフォンの数の急増につながっている。電気通信業界はこれまで、よりよい多元接続、変調および符号化ならびにマルチアンテナ技術の使用を通じて、スペクトル効率の増大を提供することができる、より新たな標準で需要に応えてきた。容量改善のための別の局面は、配置の密度を増大させ、それに対応してセル半径を低減することによるものであった。加えて、異種（heterogeneous）トポロジがますます使用されており、この場合、スモールセル（マイクロ／ピコ／フェムト）がマクロセルと共に配置される。リモート無線ヘッドおよび分散アンテナの使用を通じた屋内カバレッジの改善がまた、急増していることがある。しかし、スモールセル配置は、モビリティイベントの大幅な増加につながることがあり、付随する干渉管理問題は複雑であることがある。大容量インターネットバックホール、電源、および無線周波数（ＲＦ）機器などの、維持される必要がある大量の追加インフラストラクチャが必要なことがある。
【発明の概要】
【０００４】
デバイスツーデバイス（Ｄ２Ｄ）通信に対するモビリティのための方法および装置が開示される。ＷＴＲＵは、少なくとも１つの発見信号プロパティ（discovery signal property）に対応する測定オブジェクトを含む、近接検出構成（proximity detection configuration）を記憶してもよい。ＷＴＲＵは、近接検出測定を実行して、発見信号プロパティを検出し、次いで、発見信号プロパティを検出したことに基づいて、Ｄ２Ｄ通信を確立してもよい。無線リソース制御（ＲＲＣ）測定報告が、ＷＴＲＵから受信されてもよい。直接パスからもしくは直接パスへ、ローカルパスからもしくはローカルパスへ、インフラストラクチャパスからもしくはインフラストラクチャパスへのモビリティ、サービングセル変更、およびセル再選択を含む、Ｄ２Ｄモビリティプロシージャのための方法がまた開示される。他の実施形態は、モビリティ障害、無線リンク障害、および直接リンク障害のときの挙動を含む。セキュリティ構成およびアクティブ化方法および装置がまた開示される。ｅＮＢ間管理（inter-eNB management）のためのネットワーク方法がまた開示される。最後に、直接パス近接検出測定、ならびに、Ｄ２Ｄセッションをトリガおよび確立するための方法および装置が開示される。
【図面の簡単な説明】
【０００５】
添付の図面と共に例として提供される以下の説明から、より詳細な理解が得られるであろう。
【０００６】
【図１Ａ】１または複数の開示される実施形態を実装することができる例示的な通信システムのシステム図である。
【図１Ｂ】図１Ａに示された通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）のシステム図である。
【図１Ｃ】図１Ａに示された通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。
【図２】直接モデルの要約図を有するデバイスツーデバイス（Ｄ２Ｄ）アーキテクチャの例の図である。
【図３】直接モデルの展開図を有するＤ２Ｄアーキテクチャの例の図である。
【図４】ｅＮＢ内ケース（intra-eNB case）に対するデータパスオプションの例の図である。
【図５Ａ】ｅＮＢ内ケースに対するインフラストラクチャツーロングタームエボリューション（ＬＴＥ）直接パスの例の図である。
【図５Ｂ】ｅＮＢ内ケースに対するインフラストラクチャツーロングタームエボリューション（ＬＴＥ）直接パスの例の図である。
【図６Ａ】ｅＮＢ間ケースに対するインフラストラクチャツーＬＴＥ直接パスの例の図である。
【図６Ｂ】ｅＮＢ間ケースに対するインフラストラクチャツーＬＴＥ直接パスの例の図である。
【図７】ＷＴＲＵが直接パスをアクティブ化することの失敗を認識する能力を有する例のフローチャートである。
【図８】ｅＮＢ内ケースに対するインフラストラクチャへのＬＴＥ直接パスの例の図である。
【図９】直接パス上の非ＬＴＥ  ＲＡＴからインフラストラクチャパスへのオフロードに対する高レベルのコールフローチャートである。
【図１０】ｅＮＢ間ケースに対するインフラストラクチャツーローカルパスへの例である。
【図１１Ａ】直接パスコールの間のインフラストラクチャハンドオーバの例の図である。
【図１１Ａ１】直接パスコールの間のインフラストラクチャハンドオーバの例の図である。
【図１１Ｂ】ＷＴＲＵがハンドオーバの間に実行することができるプロシージャの例に対する高レベルのコールフローチャートである。
【図１１Ｃ】ＷＴＲＵがハンドオーバなどのモビリティプロシージャの完了に続いて実行することができるプロシージャの例のフローチャートである。
【図１２】セル再選択またはアイドルモードモビリティに対する、第３のモビリティイベントタイプに対する例示的な方法のフローチャートである。
【図１３Ａ】ＷＴＲＵが、ベースラインＲＬＦ処理に対して本明細書で説明されたプロシージャを始める（undertake）ことに加えて、無線リンク障害（ＲＬＦ）を処理することができる、高レベルのコールフローチャートである。
【図１３Ｂ】別のＲＬＦ処理プロシージャに対する高レベルのコールフローを示す図である。
【図１３Ｃ】ＲＬＦを処理するためのさらに別の高レベルのコールフローチャートである。
【図１４Ａ】直接リンク障害（ＤＬＦ）に関するプロシージャに対する例のフローチャートである。
【図１４Ｂ】直接リンク障害（ＤＬＦ）に関するプロシージャに対する例の別のフローチャートである。
【図１５】Ｄ２Ｄ通信に対する、セキュリティプロシージャに対する例のフローチャートである。
【図１６】モビリティおよび測定イベントに対するトリガを使用することができるプロシージャに対する例のフローチャートである。
【図１７Ａ】十分な条件が存在するときに直接パスを確立するのにインバウンドモビリティトリガを使用することができるときの例のフローチャートである。
【図１７Ｂ】不十分な条件が存在するときに直接パスから切り替えるのにアウトバウンドモビリティトリガを使用することができるときの例のフローチャートである。
【発明を実施するための形態】
【０００７】
図１Ａは、１または複数の開示される実施形態を実装することができる例示的な通信システム１００の図である。通信システム１００は、音声、データ、ビデオ、メッセージング、ブロードキャストなどのコンテンツを、複数の無線ユーザに提供する多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、このようなコンテンツにアクセスすることを可能にしてもよい。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの、１または複数のチャネルアクセススキームを採用してもよい。
【０００８】
図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、無線アクセスネットワーク（ＲＡＮ）１０４と、コアネットワーク１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態が任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を意図していることが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境で動作および／または通信するように構成された任意のタイプのデバイスであってもよい。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話機、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、家庭用電化製品などを含んでもよい。
【０００９】
通信システム１００はまた、基地局１１４ａおよび基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線にインタフェースして、コアネットワーク１０６、インターネット１１０、および／または他のネットワーク１１２などの、１または複数の通信ネットワークへのアクセスを容易にするように構成された、任意のタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ基地局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどであってもよい。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂが、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されるであろう。
【００１０】
基地局１１４ａはＲＡＮ１０４の一部であってよく、ＲＡＮ１０４はまた、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどの、他の基地局および／またはネットワーク要素（図示せず）を含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、特定の地理的領域内で無線信号を送信および／または受信するように構成されてもよく、この地理領域はセル（図示せず）と称されることがある。セルはさらに、セルセクタに分割されてもよい。例えば、基地局１１４ａに関連付けられたセルは、３つのセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、３つの送受信機、すなわちセルの各セクタにつき１つの送受信機を含んでもよい。別の実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を採用してもよく、したがって、セルの各セクタにつき複数の送受信機を利用してもよい。
【００１１】
基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）とすることができる、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数と通信してもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
【００１２】
特に、上述したように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの、１または複数のチャネルアクセススキームを採用してもよい。例えば、ＲＡＮ１０４における基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））を使用してエアインタフェース１１６を確立することができる、ユニバーサルモバイルテレコミュニケーションズシステム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでもよい。ＨＳＰＡは、高速ダウンリンクパケットアクセス（ＨＳＤＰＡ）および／または高速アップリンクパケットアクセス（ＨＳＵＰＡ）を含んでよい。
【００１３】
別の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥアドバンスト（ＬＴＥ−Ａ）を使用してエアインタフェース１１６を確立することができる、進化型ＵＭＴＳ地上無線アクセス（Ｅ−ＵＴＲＡ）などの無線技術を実装してもよい。
【００１４】
他の実施形態では、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわちＷｏｒｌｄｗｉｄｅ  ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ  ｆｏｒ  Ｍｉｃｒｏｗａｖｅ  Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００  １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ２０００（ＩＳ−２０００）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ９５（ＩＳ−９５）、Ｉｎｔｅｒｉｍ  Ｓｔａｎｄａｒｄ８５６（ＩＳ−８５６）、Ｇｌｏｂａｌ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｍｏｂｉｌｅ  ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））、Ｅｎｈａｎｃｅｄ  Ｄａｔａ  ｒａｔｅｓ  ｆｏｒ  ＧＳＭ  ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、ＧＳＭ  ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【００１５】
図１Ａにおける基地局１１４ｂは、例えば無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、事業所、家庭、車両、キャンパスなどの局所化されたエリアにおいて無線接続性を容易にするための任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。さらに別の実施形態では、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えばＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接接続を有してもよい。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスすることは必要とされなくてもよい。
【００１６】
ＲＡＮ１０４は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１または複数に提供するように構成された、任意のタイプのネットワークとすることができる、コアネットワーク１０６と通信してよい。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルロケーションベースサービス、プリペイドコーリング、インターネット接続性、ビデオ配信などを提供してもよく、ならびに／または、ユーザ認証など、高レベルのセキュリティ機能を実行してもよい。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用する他のＲＡＮと、直接的または間接的に通信してもよいことが理解されるであろう。例えば、コアネットワーク１０６は、Ｅ−ＵＴＲＡ無線技術を利用することができるＲＡＮ１０４に接続されることに加えて、ＧＳＭ無線技術を採用する別のＲＡＮ（図示せず）と通信してもよい。
【００１７】
コアネットワーク１０６はまた、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしてサービスしてもよい。ＰＳＴＮ１０８は、従来型電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含んでもよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートにおける、伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの、共通通信プロトコルを使用する相互接続されたコンピュータネットワークおよびデバイスのグローバルシステムを含んでもよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営された、有線または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４と同一のＲＡＴまたは異なるＲＡＴを採用することができる、１または複数のＲＡＮに接続された別のコアネットワークを含んでもよい。
【００１８】
通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部または全ては、マルチモード能力を含んでもよい。すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、種々の無線リンク上で種々の無線ネットワークと通信するための複数の送受信機を含んでもよい。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用することができる基地局１１４ａと、また、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと、通信するように構成されてもよい。
【００１９】
図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送受信要素１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２が、実施形態との整合性を維持しながら前述の要素の任意のサブコンビネーションを含んでよいことが理解されるであろう。
【００２０】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、ディジタルシグナルプロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１または複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、状態機械などであってもよい。プロセッサ１１８は、信号符号化、データ処理、電力制御、入出力処理、および／または、ＷＴＲＵ１０２が無線環境で動作することを可能にする他の任意の機能を実行してもよい。プロセッサ１１８は送受信機１２０に結合されてもよく、送受信機１２０は送受信要素１２２に結合されてもよい。図１Ｂはプロセッサ１１８と送受信機１２０とを別々のコンポーネントとして示しているが、プロセッサ１１８および送受信機１２０が共に電子パッケージまたはチップに統合されてもよいことが理解されるであろう。
【００２１】
送受信要素１２２は、エアインタフェース１１６上で基地局（例えば基地局１１４ａ）との間で信号を送信または受信するように構成されてもよい。例えば、一実施形態では、送受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。別の実施形態では、送受信要素１２２は、例えばＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された、エミッタ／ディテクタであってもよい。さらに別の実施形態では、送受信要素１２２は、ＲＦ信号と光信号との両方を送信および受信するように構成されてもよい。送受信要素１２２が無線信号の任意の組合せを送信および／または受信するように構成されてもよいことが理解されるであろう。
【００２２】
加えて、図１Ｂでは送受信要素１２２が単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送受信要素１２２を含んでもよい。特に、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上で無線信号を送信および受信するための、２つ以上の送受信要素１２２（例えば複数のアンテナ）を含んでもよい。
【００２３】
送受信機１２０は、送受信要素１２２によって送信されることになる信号を変調し、および送受信要素１２２によって受信された信号を復調するように構成されてもよい。上述したように、ＷＴＲＵ１０２は、マルチモード能力を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含んでもよい。
【００２４】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８（例えば液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、これらからユーザ入力データを受信してもよい。プロセッサ１１８はまた、スピーカ／マイクロホン１２４、キーパッド１２６、および／または、ディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、着脱不能メモリ１３０および／または着脱可能メモリ１３２などの、任意のタイプの適切なメモリからの情報にアクセスし、およびそのようなメモリにデータを記憶してもよい。着脱不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含んでもよい。着脱可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアディジタル（ＳＤ）メモリカードなどを含んでもよい。他の実施形態では、プロセッサ１１８は、サーバおよびホームコンピュータ（図示せず）上のメモリなど、ＷＴＲＵ１０２上に物理的に位置しないメモリからの情報にアクセスし、およびそのようなメモリにデータを記憶してもよい。
【００２５】
プロセッサ１１８は、電源１３４から電力を受信してもよく、ＷＴＲＵ１０２における他のコンポーネントへ電力を分配および／または制御するように構成されてよい。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１または複数の乾電池（例えばニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル金属水素化物（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、および燃料電池などを含んでもよい。
【００２６】
プロセッサ１１８はまた、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば経度および緯度）を提供するように構成することができる、ＧＰＳチップセット１３６に結合されてよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれに代えて、ＷＴＲＵ１０２は、基地局（例えば基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上で位置情報を受信してもよく、および／または、２つ以上の近隣基地局から受信された信号のタイミングに基づいてその位置を判定してもよい。ＷＴＲＵ１０２が、実施形態との整合性を維持しながら任意の適切な位置判定方法によって位置情報を取得してもよいことが理解されるであろう。
【００２７】
プロセッサ１１８はさらに、追加の特徴、機能、および／または有線もしくは無線接続性を提供する、１または複数のソフトウェアおよび／またはハードウェアモジュールを含むことができる、他の周辺機器１３８に結合されてよい。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星送受信機、ディジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビジョン送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、およびインターネットブラウザなどを含んでもよい。
【００２８】
図１Ｃは、一実施形態に従ったＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述したように、ＲＡＮ１０４は、Ｅ−ＵＴＲＡ無線技術を採用して、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０６と通信してもよい。
【００２９】
ＲＡＮ１０４は、ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃを含んでもよいが、ＲＡＮ１０４が実施形態との整合性を維持しながら任意の数のｅＮｏｄｅＢを含んでもよいことを理解されるであろう。ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃはそれぞれ、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１または複数の送受信機を含んでもよい。一実施形態では、ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、例えばｅＮｏｄｅＢ１４０ａは、複数のアンテナを使用して、ＷＴＲＵ１０２ａとの間で無線信号を送受信することができる。
【００３０】
各ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは、特定のセル（図示せず）に関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示されるように、ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インタフェース上で相互に通信してもよい。
【００３１】
図１Ｃに示されるコアネットワーク１０６は、モビリティ管理エンティティゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含んでもよい。上述した各要素はコアネットワーク１０６の一部として示されているが、これらの要素のいずれか１つがコアネットワークオペレータ以外のエンティティによって所有および／または運営されてもよいことが理解されるであろう。
【００３２】
ＭＭＥ１４２は、Ｓ１インタフェースを介してＲＡＮ１０４における各ｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃに接続されてもよく、制御ノードとして動作してもよい。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラをアクティブ化／非アクティブ化すること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチの間に特定のサービングゲートウェイを選択することなどを担当してもよい。ＭＭＥ１４２はまた、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供してもよい。
【００３３】
サービングゲートウェイ１４４は、Ｓ１インタフェースを介してＲＡＮ１０４におけるｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃの各々に接続されてよい。サービングゲートウェイ１４４は一般的に、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間でユーザデータパケットをルーティングおよび転送してもよい。サービングゲートウェイ１４４はまた、ｅＮｏｄｅＢ間ハンドオーバの間にユーザプレーンをアンカリングすること、ダウンリンクデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどの、他の機能を実行してもよい。
【００３４】
サービングゲートウェイ１４４はまた、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にすることができる、ＰＤＮゲートウェイ１４６に接続されてもよい。
【００３５】
コアネットワーク１０６は、他のネットワークとの通信を容易にしてもよい。例えば、コアネットワーク１０６は、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信デバイスとの間の通信を容易にしてもよい。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８との間のインタフェースとしてのサービスするＩＰゲートウェイ（例えばＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでもよく、または、そのようなＩＰゲートウェイと通信してもよい。加えて、コアネットワーク１０６は、他のサービスプロバイダによって所有および／または運営される他の有線または無線ネットワークを含むことができる、ネットワーク１１２へのアクセスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよい。
【００３６】
ますます強力なデバイスになってきたスマートフォンは、複数の広帯域無線およびモデムと、大量のデータを処理する能力ならびに複数の同時アプリケーションを実行する能力とを有するように設計されていることがある。スマートフォンが、可能なときに相互に直接に通信することを可能にすることは、スマートフォンが直接に通信することを可能にするとともに、従来のセルラ配置とも共存することを可能にする、代替ネットワークトポロジを生み出すことを可能にすることがある。デバイスツーデバイス（Ｄ２Ｄ）アーキテクチャは、このような代替トポロジの例である。
【００３７】
図２は、デバイスツーデバイス（Ｄ２Ｄ）アーキテクチャ２００の例である。図２は、Ｄ２Ｄサーバ２０２が３ＧＰＰネットワーク２０３の境界内に位置してもよいことを示す。Ｄ２Ｄサーバ２０２は、複数のオペレータに共通である単一のエンティティとして維持されてもよく、およびそれらによって合同で管理されてもよく、または、各オペレータの領域に部分的に位置する、複数のエンティティとして分散されてもよい。Ｄ２Ｄサーバ２０２は、Ｄ２Ｄアプリケーション２０１へのアクセスをＷＴＲＵ２０４に提供してもよい。
【００３８】
このような直接ＷＴＲＵツーＷＴＲＵ通信によって有効とされる、アドバンストトポロジ（ＡＴ）応用例は、アドバンストトポロジ−リレー（ＡＴ−Ｒ）およびアドバンストトポロジ−ローカルオフロード（ＡＴ−ＬＯ）を含んでもよい。ＡＴ−Ｒ応用例では、端末ＷＴＲＵ（Ｔ−ＷＴＲＵ）が、ヘルパＷＴＲＵ（Ｈ−ＷＴＲＵ：Helper-WTRU）とすることができる、リレーノードを通じてデータをネットワークと交換することが可能である。ＡＴ−ＬＯ応用例は、相互に近接しており中央ネットワークの制御下にあるＷＴＲＵの間で直接データ通信を可能にしてもよい。
【００３９】
ＡＴ−Ｒ応用例は、２つのモード、容量（capacity）モードおよびカバレッジモードを含んでもよい。容量モードでは、Ｔ−ＷＴＲＵは、ネットワークに関連付けられてもよく、ＷＴＲＵに協力を求めて（enlist）、無線リンク容量を増強し、およびデータ送信容量を改善してもよい。一方、カバレッジモードでは、Ｔ−ＷＴＲＵは、ネットワークカバレッジの外にあってもよく、Ｈ−ＷＴＲＵに依存して、ネットワーク関連付けを達成してもよい。両モードは、低モビリティＷＴＲＵに対して想定されてもよい。
【００４０】
ＡＴ−ＬＯ応用例では、近接するＷＴＲＵは、交換される情報に対するソースまたはっ受信側（sink）のいずれかであってもよい。ＡＴ−ＬＯ応用例におけるＷＴＲＵ間の無線リンクは、認可セルラスペクトル、または無認可もしくは軽度認可スペクトル（lightly-licensed spectrum）を使用してもよい。
【００４１】
ＷＴＲＵ間の通信は、無線リンク上で発生することができるｅＮＢツーＷＴＲＵ通信とは対照的に、クロスリンク（ＸＬ）と称される専用チャネルにおいて行われてもよい。ＸＬは、別個の帯域にあってもよく（帯域外ソリューション）、または、無線リンクと同一の帯域にあってもよく、隣接する周波数サブキャリアにさえあってもよい。Ｈ−ＷＴＲＵおよびＴ−ＷＴＲＵは、周波数分割複信（ＦＤＤ）方式または時分割複信（ＴＤＤ）方式のいずれかで相互に通信してもよい。関連する構成はネットワークによって定義されてもよい。ネットワークは、ＸＬに対する粗いリソース割り当てを提供してもよく、ＷＴＲＵは、ＴＴＩごとのリソース割り当てを扱う自由を有してもよい。
【００４２】
図３は、例示的なＤ２Ｄアーキテクチャの展開図である。ＷＴＲＵ３０１Ａは、データプレーン上でＲＡＮ３０２Ａ、ＳＧＷ３０５Ａ、およびＰＧＷ３０６Ａを介してＤ２Ｄアプリケーション３１１に接続してもよい。同様に、ＷＴＲＵ３０１Ｂは、データプレーン上でＲＡＮ３０２Ｂ、ＳＧＷ３０５Ｂ、およびＰＧＷ３０６Ｂを介してＤ２Ｄアプリケーション３１１に接続してもよい。Ｄ２Ｄサーバ３１２は、制御プレーンインタフェースを介して、ＡＮＤＳＦ３０４Ａおよび３０４Ｂ、ＭＭＥ３０７Ａおよび３０７Ｂ、ＨＳＳ３０３Ａおよび３０３Ｂ、ＰＣＲＦ３０８Ａおよび３０８Ｂ、ＯＦＣＳ３０９Ａおよび３０９Ｂ、ならびにＥ−ＳＭＬＣ３１０Ａおよび３１０Ｂに接続してもよい。
【００４３】
図４は、ｅＮＢ内のケースに対し、Ｄ２Ｄ通信に対するローカルパスオプションと直接パスオプションとの両方に対する高レベルアーキテクチャ４００を提供する。図４は、セルラインフラストラクチャパス４０１と、ローカルパス４０２と、直接パス４０３との間の対比（contrast）を示す。ＷＴＲＵ１  ４０４ＡおよびＷＴＲＵ２  ４０４Ｂは、直接パス４０３またはローカルパス４０２上で、ｅＮＢ４０９を介したＤ２Ｄセッションにおいて、それらの送信機および受信機を介して通信してもよい。ＷＴＲＵ１  ４０４ＡおよびＷＴＲＵ２  ４０４ＢがｅＮＢ４０９を介してインフラストラクチャパス４０１上で通信するときは、それらの通信は、ＧＴＰ−Ｕトンネル４０５Ａおよび４０５Ｂ、ＳＧＷ４０６、ＧＴＰ−Ｕトンネル４０７Ａおよび４０７Ｂ、ならびにＰＤＮ−ＧＷ４０８を通じてルーティングされてもよい。
【００４４】
ＳＡ１グループにおける近接サービス（ＰｒｏＳｅ）検討項目の導入に伴い、Ｄ２Ｄ通信は、３ＧＰＰにおける議論の主題となった。ＰｒｏＳｅの範囲は、直接パスとローカルパスとの両方を含むことがある。直接パスでは、物理通信は直接にＤ２Ｄデバイス間であってよい。ローカルパスでは、通信は、両デバイスが接続されたｅＮＢを通じてでもよい。
【００４５】
ＰｒｏＳｅの一部としていくつかの使用事例も定義されており、各使用事例は、システム設計に対する異なる要件セットを提起することがある。これらは、社会的および公共安全の下、広くカテゴリ化されてもよい。
【００４６】
社会的使用事例の例が以下に提供される。基本的な社会的使用事例に対し、Ｄ２Ｄユーザは、そのユーザグループ（例えば友達リスト）に属する他のＤ２Ｄユーザを発見することが可能であり、および他のＤ２Ｄユーザによって発見可能であってもよく、次いで、Ｄ２Ｄリンクを介してソーシャルネットワークアプリケーションを使用することが可能であってもよい。発見は、いかなるＷＴＲＵ位置情報もなしに実行されてもよい。公共発見に対し、Ｄ２Ｄユーザは、事前許可を必要とすることなく、任意の他のＤ２Ｄユーザによって発見可能であってもよい。異なる公衆陸上モバイルネットワーク（ＰＬＭＮ）発見に対し、異なるＰＬＭＮに属するＤ２Ｄユーザは、相互に発見可能であってもよい。このサブセットは、Ｄ２Ｄユーザがまたローミングしているときであってもよい。サービス継続性の使用事例では、Ｄ２Ｄユーザは、ユーザによって認識可能な悪化なしに、直接パスとインフラストラクチャモードとの間を移動することが可能であってもよい。ロケーションおよび存在（presence）の使用事例では、オペレータは、それらの位置および存在情報をＰｒｏＳｅプロシージャで向上させることが可能であってもよい。
【００４７】
公共安全（ＰＳ）使用事例の例は以下を含んでもよい。基本的なＰＳ使用事例に対し、２の許可されたＰＳユーザが、Ｄ２Ｄリンク上で直接に通信することが可能であってもよい。ＰＳ  Ｄ２Ｄユーザは、異なるＤ２Ｄ  ＰＳユーザと、同時に複数の１対１のＤ２Ｄセッションを維持することが可能であってもよい。
【００４８】
Ｄ２Ｄ通信をセルラ通信のフレームワークに含めることのできる統合システムアーキテクチャを達成するために、モビリティプロシージャは、セルラ通信とＤ２Ｄ通信との間の正常な（graceful）遷移を可能にしてもよい。モビリティプロシージャの目的は、ＷＴＲＵが、合理的な遅延で、およびプロセスにおいてデータが損失することなしに、効率的な方式でインフラストラクチャリンクから直接リンクに移行することを可能にすることであってもよい。Ｄ２Ｄリンクの適切に測定、およびこれをネットワークに報告することは、この目的で使用されてよい。他の考慮事項と共にこれらの報告に基づいて、ネットワークおよび／またはＷＴＲＵによってモビリティ決定をトリガするがまた使用されてよい。
【００４９】
プロシージャは、ローカルパスと、直接パスＬＴＥと、他の無線アクセス技術（ＲＡＴ）を使用した直接パスとを含む、Ｄ２Ｄに対する考えられる全てのアーキテクチャオプションを含んでもよい。プロシージャはまた、Ｄ２Ｄ通信に使用することができる様々なプロトコルアーキテクチャを考慮してもよく、これらとベースライン３ＧＰＰプロトコルアーキテクチャとの間の遷移を提供することができる。
【００５０】
Ｄ２Ｄ通信を３ＧＰＰ進化型パケットコア（ＥＰＣ）に組み込むために、アーキテクチャ上の向上（architectural enhancement）が使用されてよい。既存のアーキテクチャに対するこれらの変更および追加を使用して、以下のように、ネットワークにおける多数のＤ２Ｄ対応デバイスの効率的な動作を有効にすること、Ｄ２Ｄリンクが従来のセルラリンクと共存することを可能にすること、３ＧＰＰ  ＰｒｏＳｅ機能に対して想定される全ての配置構成を満たすこと、および、３ＧＰＰによって設計（laid out）されるＤ２Ｄ通信に対する全てのサービス要件を満たすこと、を達成することができる。
【００５１】
ｅＮＢ内およびｅＮＢ間、ＰＬＭＮ内およびＰＬＭＮ間を含む、複数のシナリオに対するＤ２Ｄモビリティプロシージャが開示される。使用されるＤ２Ｄモビリティプロシージャは、システムアーキテクチャおよび特定のモビリティシナリオに基づいてもよい。
【００５２】
Ｄ２Ｄコンテキストにおけるモビリティは、いくつかの異なるタイプから構成されてもよい。第１のタイプは、通信パスの変更を指す（オフロードシナリオ）。
【００５３】
このタイプは、Ｄ２Ｄセッションおよび／またはサービスで構成することができるＲＲＣ  ＣＯＮＮＥＣＴＥＤモードにあるＷＴＲＵに対する再構成としてモデル化されてよい。再構成は、１または複数のＷＴＲＵ間でのデータが、直接通信パス、ローカル通信パス、またはインフラストラクチャパスに切り替えることができるように、通信パスを開始または修正してもよい。
【００５４】
第２のタイプは、サービングセルの変更を指す（ハンドオーバシナリオ）。このタイプは、１つのサービングセルから別のサービングセルへのハンドオーバなどのモビリティイベントを含んでもよい。このハンドオーバは、Ｄ２Ｄセッションおよび／またはサービスで構成されるＲＲＣ  ＣＯＮＮＥＣＴＥＤモードにあるＷＴＲＵに対するｅＮＢ間であってもよい。
【００５５】
第３のタイプは、セル再選択を指す（ＩＤＬＥモードモビリティ）。ＲＲＣ  ＩＤＬＥモードにあるＷＴＲＵが、Ｄ２Ｄセッションおよび／またはサービスで構成されてもよい。例えば、ＷＴＲＵは、ＷＴＲＵがＩＤＬＥモードに移動する前の専用シグナリングによって、またはブロードキャストされたシグナリングの受信によって、事前に構成された、Ｄ２Ｄリンク上でデータ送信を受信していてもよい。このシナリオでは、ＷＴＲＵは、ＲＲＣ  ＩＤＬＥにある間に、異なるセルを再選択してもよい。
【００５６】
最初の２つのタイプ間の重要な違いは、オフロードシナリオにおいて、例えばＵｕインタフェースとすることができる、同一のインフラストラクチャリンクが、イベント後も引き続き使用されてもよいことである。対照的に、ハンドオーバシナリオは、イベント後に異なるインフラストラクチャモードを使用することを含んでもよい。別の差異化する態様は、ハンドオーバシナリオにおいて、ハンドオーバプロセスの間の障害が、無線リンク障害につながることがあり、無線リンク障害は再確立プロシージャにつながることがあることである。しかし、オフロードシナリオでは、通信パスの再構成における障害は、最適には及ばない性能（sub-optimal performance）につながることがあるが、ＲＲＣ接続性の観点から、無線リンク障害の状態に必ずしもつながるわけではない。
【００５７】
一部のサービスに対し、Ｄ２Ｄリンクからインフラストラクチャパスへ、ローカル通信パスへ、などの、通信パスの変更は、最初にトリガされるＤ２Ｄサービスが、ＷＴＲＵ間の無線近接性に依存し、またはＷＴＲＵ間の無線近接性により提供されることがあることから、望ましくないことがある。
【００５８】
ＲＲＣ接続性に対するアプローチ（Ｌ３態様）、およびサービス接続を維持するためのアプローチ（Ｌ２態様）（該当の無線ベアラの処理、および／または、適用可能なサービスに対するＩＰフローを含むがこれらに限定されない）が、以下に説明される。
【００５９】
本明細書における例は、２つのＷＴＲＵを対象とすることがあるが、Ｄ２Ｄ通信を含む所与のサービスに対してアクティブである複数のＷＴＲＵにも等しく一般化されてもよい。説明される例における、ベースライン呼（baseline call）または直接パス呼（direct path call）に接続される第１のＷＴＲＵおよび第２のＷＴＲＵは、本明細書ではそれぞれＷＴＲＵ１およびＷＴＲＵ２と称されてもよい。同様に、説明される例における第１のｅＮＢ、第２のｅＮＢ、および第３のｅＮＢは、本明細書ではそれぞれｅＮＢ１、ｅＮＢ２、およびｅＮＢ３と称されてもよい。本明細書における例は、開示される方法および装置において使用されるＷＴＲＵ、ｅＮＢ、または他のネットワーク要素の数を限定することを意図していない。
【００６０】
図５Ａ乃至５Ｂは、インフラストラクチャがＬＴＥ直接パスにインフラストラクチャにトラフィックをオフロードするオフロードシナリオ（Ｕｕのアクティブ化＋ＣＮオフロード）のための方法５００に対する高レベルコールフローチャート５００である。図５Ａ乃至５ＢはｅＮＢ内ケースを示すが、このシナリオは、複数のｅＮＢが存在するときに適用してもよい。さらに、複数のｅＮＢは、同一のＰＬＭＮ内の同じＭＭＥの下にあってもよい。加えて、２つのｅＮＢからのデータパスが同一のＰＧＷにつながってもよい。
【００６１】
ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、ｅＮＢ５０３に接続されて、相互にベースライン呼５１０に携わってもよい。ＷＴＲＵ１  ５０１は、周期的な、またはトリガされる発見プロセス５１１で、ＷＴＲＵ２  ５０２とのベースライン呼５１０をＬＴＥ直接パスにオフロードするのを開始してもよい。周期的な発見プロセス５１１では、ＷＴＲＵ１  ５０１またはＷＴＲＵ２  ５０２は、所定の時間インスタンスの間に、他のＷＴＲＵによる発見シーケンス送信を探索してもよい。それらはまた、他のＷＴＲＵによって発見されるために、それらの割り当てられたタイムスロットの間にこのようなシーケンスを送信してもよい。周期的な発見は、ＷＴＲＵがそれらの近接している全ての発見可能なＷＴＲＵを発見するのを補助するように設計されてよい。ＷＴＲＵの１つからの、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２が無線近接にあることを示す、発見／測定報告５１２が生成されてよく、ｅＮＢは、協調して、信頼できるレイヤ３（Ｌ３）測定を生成するために、明示的な測定プロセスをセットアップしてもよい。ＭＭＥ５０５はまた、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２の識別を、メッセージ５１３Ａを介してｅＮＢ５０３に送信し、メッセージ５１３Ｂを介してＤ２Ｄサーバ５０６に送信してもよい。
【００６２】
ネットワークは、代わりに、トリガされる発見を有効にしてもよい。例えば、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、相互のデバイスアドレスならびに発見送信パターンが提供されることによって、相互に発見するように構成されてもよい。このモードは、ＷＴＲＵが、相互により早く発見することを可能にする。ネットワークは、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２がＤ２Ｄ通信可能であることを保証した後で、このトリガされる発見モードを有効にしてもよい。トリガされる発見に対し、位置または他の情報が使用されてよい。例えば、発見は、ＷＴＲＵが、同一のｅＮＢまたは地理的に隣接するｅＮＢに接続されたときにトリガされてもよい。代わりに、発見は、Ｗｉ−Ｆｉ直接（Wi-Fi Direct）などの、非ＬＴＥである他のＲＡＴによってトリガされてもよい。トリガされる発見は、各ＷＴＲＵの直接パスリンクを反復的に測定する機会を含んでもよく、それにより、複数の個別測定にわたるレイヤ３（Ｌ３）フィルタリング５１５の後で、信頼できる測定報告５１６Ａおよび５１６Ｂが生成されてもよい。
【００６３】
発見に続いて、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、直接パス測定に対する拡張を含むことができる、測定構成５１４Ａおよび５１４Ｂを受信してもよく、およびｅＮＢ５０３の制御下にあってよい。ＭｅａｓＣｏｎｆｉｇ  ＩＥにおける要素に対する要素または拡張が、Ｄ２Ｄ特有の測定に対して定義されてもよい。これらの要素は、ＭｅａｓＯｂｊｅｃｔＤ２ＤまたはＲｅｐｏｒｔＣｏｎｆｉｇＤ２Ｄの少なくとも１つを含んでもよい。測定構成５１４Ａおよび５１４Ｂでは、ネットワークは、Ｄ２Ｄリンクの帯域外測定、または帯域内測定機会のための測定ギャップ、に対する搬送波周波数を提供してもよい。
【００６４】
ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、測定報告５１６Ａおよび５１６ＢをｅＮＢ５０３に送信することによって、測定構成５１４Ａおよび５１４Ｂに応答してもよい。測定報告が受信されると、インフラストラクチャパスから直接パスにオフロードする決定は、測定報告５１６Ａおよび５１６Ｂに基づいてもよい。測定閾値がまた、構成されてもよく、この測定閾値に基づいてオフロード決定が行われる。オフロードは、単一のＷＴＲＵの測定に基づいてトリガされてもよく、代わりに、ｅＮＢは、他方のＷＴＲＵの報告を待機してもよい。例えば、ネットワークは、所与の期間内に、２以上のＷＴＲＵ間での直接パスに適用可能な測定報告５１２が、少なくとも２つのＷＴＲＵによって受信されたとき、直接パスがそのような報告の受信に応じて構成されてもよいと判定してもよい。
【００６５】
ネットワーク制御エンティティは、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２の直接パス能力を判定してもよい。例えば、ｅＮＢ５０３は、ＷＴＲＵ  Ｄ２Ｄ能力要求５１７Ａを行うために、ＭＭＥ５０５を通じてＤ２Ｄサーバ５０６と通信してもよく、および最適なＤ２Ｄ構成を取得するために、ＷＴＲＵ  Ｄ２Ｄ能力応答５１７Ｂを受信してもよい。Ｄ２Ｄ能力はとりわけ、ＷＴＲＵが直接パス通信を実行することが可能な帯域／チャネルを含んでもよい。Ｄ２Ｄセッションを確立するＷＴＲＵは、マスタまたはスレーブロールにおいて構成されてもよい。このロールは、Ｄ２Ｄリソース管理、セキュリティ、Ｄ２Ｄアクセス制御などに対するＷＴＲＵの振る舞いに影響を与えることがある。ＷＴＲＵはさらに、その現在のロールに基づいてＤ２Ｄモビリティプロシージャを選択するように構成されてもよい。Ｄ２Ｄグループセッションでは、１つのＷＴＲＵがマスタロールにおいて構成されてもよい。
【００６６】
ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、確立されたＲＲＣ接続を使用して、直接パス構成を受信してもよい。Ｄ２Ｄ構成は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ５１８Ａおよび５１８Ｂを通じて提供されてもよい。ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２はまた、ＮＡＳまたはＲＲＣメッセージ（例えばＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）から、インフラストラクチャおよびＤ２Ｄパスに対する新たなフィルタリングルールを取得するように構成されてもよい。別の例では、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、ＮＡＳメッセージ５１９Ａおよび５１９ＢをＭＭＥ５０５から受信してもよい。ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、ＮＡＳメッセージ５２０Ａおよび５２０ＢをＭＭＥ５０５に送信することによって、応答してもよい。これらのメッセージは、Ｄ２Ｄセッション確立後に使用されることになる新たなアップリンクトラフィックフローテンプレート（ＵＬ  ＴＦＴ）を含んでもよい。
【００６７】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ５１８Ａおよび５１８Ｂを通じて直接パス構成を受信して、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ５１８Ａおよび５１８Ｂを処理するのに続いて、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、対応するＤ２Ｄリンクの確立をトリガしてもよい。ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、物理レイヤにあってもよい直接パス上で、ハンドシェイク信号５２１を交換してもよい。これらのハンドシェイク信号５２１を受信すると、ＷＴＲＵは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ５２２Ａおよび５２２ＢをｅＮＢに送信してもよく、ならびに、Ｄ２Ｄセッションにおいてデータを送信および受信する準備ができてもよい。
【００６８】
ＩＰアドレスの新たなセットが、Ｄ２Ｄセッションに使用されてよい。このＩＰアドレスのセットは、インフラストラクチャパスとは異なるサブネットに属してもよい。Ｄ２Ｄ  ＷＴＲＵは、Ｄ２Ｄ  ＩＰアドレスをＰｒｏＳｅサーバから取得するように構成されてもよい。別の解決策では、Ｄ２ＤセッションマスタＷＴＲＵとして構成されたＷＴＲＵは、ローカルＤＨＣＰサーバとして動作するように構成されてもよく、およびこのＤ２Ｄセッションに関連するＩＰアドレスを割り当ててもよい。
【００６９】
インフラストラクチャパス無線ベアラ、ならびに、直接パスにハンドオーバされたフローに関連するＥＰＳベアラは、管理される必要があることがある。適用可能なＥＰＳ  ＲＡＢは、該当のＷＴＲＵに適用可能なＳ１−ｕから除去されてもよい。インフラストラクチャパス無線ベアラは削除されてもよい。ＥＰＳベアラは、Ｓ１およびＳ５インタフェースコンポーネントを削除することによって、純粋なＤ２Ｄ  ＥＰＳベアラとして再構成されてもよい。
【００７０】
ｅＮＢとＳ−ＧＷとの間のＳ１−Ｕベアラ、ならびに、ＳＧＷとＰＧＷ５０４との間のＳ５ベアラの削除は、ＭＭＥによって開始される専用ベアラ非アクティブ化プロシージャの修正によって達成されてもよい。ベースラインＬＴＥシステムにおいて説明されるこのプロシージャは、ＷＴＲＵとｅＮＢとの間の無線ベアラを解放することも含むが、これは、本明細書で説明されるＤ２Ｄベアラ修正のコンテキストでは行われる必要はない。
【００７１】
適用可能なＥＰＳ  ＲＡＢは、該当のＷＴＲＵに適用可能なＳ１−ｕに対して維持されてもよい。代わりに、インフラストラクチャ無線ベアラは、直接パスとインフラストラクチャパスとの間のフローの動的な切替えの可能性を考慮するように保持されてよい。例えばマルチパス送信がサポートされうるように、所与のサービスからのトラフィックはいずれかのパスにマッピングされてもよい。ＥＰＳベアラは、インフラストラクチャパスデータ無線ベアラ（ＤＲＢ）および直接パスＤＲＢの両方（それらに関連付けられている）を有する、特別なＤ２Ｄ  ＥＰＳベアラとして再構成されてもよい。
【００７２】
適用可能なＥＰＳ  ＲＡＢに対するコアネットワークコンテキストが維持されてもよいが、Ｓ１−ｕは削除されてもよい。代わりに、コアネットワークにおける該当のＷＴＲＵに対する適用可能なＤ２Ｄセッションに対するサービスに関連付けられたＥＰＳベアラが維持されてよいが、それらのベアラに対するＳ１−ｕ通信パスは解体されてもよい。インフラストラクチャパスに再び切り替わると、ベアラは、例えば、ＷＴＲＵがＮＡＳサービス要求またはＮＡＳサービス更新プロシージャを実行する必要なしに、再アクティブ化されてもよい。
【００７３】
ＲＬＣ  ＡＭベアラでデータ送信のシームレスなオフロードを保証するために、ＷＴＲＵ１  ５０１からＷＴＲＵ２  ５０２へのデータパスを使用して、以下のアクションがとられてもよい。
【００７４】
ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、アップリンク（ＵＬ）、ダウンリンク（ＤＬ）、または両方に対する直接パスに関連付けられたサービスに適用可能な任意のＤＲＢをサスペンドしてもよく、次いで、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ５２２Ａおよび５２２Ｂをそれぞれ、ｅＮＢ５０３に送信してもよい。次いで、ｅＮＢ５０３は、明示的なＲＲＣメッセージ５２３Ａおよび５２３Ｂを送信し、直接パスにリダイレクトされることになる任意のデータのインフラストラクチャ送信をそれぞれ停止するようＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２に命令してもよい。ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２はまた、ＤＲＢに対するＤＬにおいて、ＰＤＣＰステータスＰＤＵを受信してもよい。
【００７５】
ｅＮＢ５０３はまた、ｅＮＢ５０３からの現在のＰＤＣＰステータス５２４Ａおよび５２４Ｂを、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２にそれぞれ提供してもよく、したがって、ｅＮＢ５０３において成功して受信された、連続した最後の（last in-sequence）ＰＤＣＰ  ＰＤＵのシーケンス番号をＷＴＲＵ５０１および５０２に通知することができる。このことは、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２は、直接パス送信に対する開始点（すなわちＰＤＣＰ  ＳＤＵ）を確認することを可能にする。ＷＴＲＵは、ＤＲＢに対するデータを受信してもよい。
【００７６】
ｅＮＢ５０３は、その送信バッファに残っているデータをＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２に送信することを継続してもよい（５２５Ａ）。ｅＮＢ５０３は、連続しているＰＤＣＰ  ＳＤＵからのその受信されたＰＤＵを、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２からＳＧＷ／ＰＧＷ５０４に転送することを継続してもよい（５２５Ｂ）。
【００７７】
全てのデータをＳＧＷ／ＰＧＷ５０４に転送した後、ｅＮＢ５０３は、ｅＮＢ５０３とＳＧＷ／ＰＧＷ５０４との間のＧＴＰ−Ｕトンネル上で、エンドマーカパケットを送信してもよい。エンドマーカは、ＧＴＰ−Ｕプロトコルを使用して、ＷＴＲＵ１  ５０１のＧＴＰトンネル５２６Ａを通じて、ＳＧＷ／ＰＧＷ５０４に、次いでｅＮＢ５０３に転送されてもよい。エンドマーカはまた、ＧＴＰ−Ｕプロトコルを使用して、ＷＴＲＵ２  ５０２のＧＴＰトンネル５２６Ｂを通じて、ＳＧＷ／ＰＧＷ５０４に、次いでｅＮＢ５０３に転送されてもよい。このエンドマーカの転送は、エンドマーカにおけるプライベート拡張を使用して実施されてもよい。これらのプライベート拡張が使用されて、ＧＴＰ−Ｕプロトコルにとってネイティブ（native）でなくてもよい追加の機能を定義してもよい。ベースラインＬＴＥプロシージャでは、エンドマーカ機能は、データパスにおける切替えをソースｅＮＢからターゲットｅＮＢに指定するのに使用されてよく、したがって、ＰＧＷからｅＮＢへのエンドマーカの転送を伴ってもよい。対照的に、直接パス通信モビリティに対し、ソースｅＮＢからターゲットｅＮＢへのエンドマーカの送信／転送は、ＰＧＷを通じてでもよい。また、ＷＴＲＵ５０１およびＷＴＲＵ５０２が２つの異なるＰＧＷに属することが可能であり、ＰＧＷ間にＧＴＰトンネル接続性が存在しなくてもよい。この場合は、エンドマーカアプローチは使用されなくてもよく、他の手段が採用されてもよい。このことは、以下のＰＬＭＮ間のケースでより詳細に論じられる。エンドマーカの受信は、（１）確認応答をソースｅＮＢに送信すること、（２）ＷＴＲＵに信号を送信して、エンドマーカにおいて指示されたＰＤＣＰシーケンス番号（ＳＮ）から開始する直接パス上で信および受信を開始すること、を含んでもよいが、これらに限定されない。
【００７８】
ｅＮＢ５０３におけるエンドマーカの受信は、直接パスに切り替えられることになる無線ベアラ通信に関係する、ｅＮＢ５０３からのデータパケットがそれ以上存在しなくてもよいこと（例えば、インフラストラクチャベース無線ベアラに関連付けられた全てのデータが、ＷＴＲＵ５０１および５０２に送信されたこと）のインジケーションであってもよい。ｅＮＢ５０３は、残りのデータをＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２に送信することを完了してもよく、次いで、エンドマーカの受信に対する確認応答を、ｅＮＢ１に送信してもよい。
【００７９】
次いで、ｅＮＢ５０３は、Ｄ２Ｄ送信５２７Ａおよび５２７Ｂを開始するようＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２にそれぞれ命令してもよい。次いで、直接パス呼５２８送信が、ＰＤＣＰステータス報告に基づいて、ｅＮＢ５０３によって受信された、連続した最後のＰＤＣＰ  ＰＤＵの後の１つである、適切なＰＤＣＰ  ＰＤＵから開始してもよい。このプロシージャは、ＷＴＲＵ１  ５０１およびＷＴＲＵ２  ５０２が、直接パス上で、冗長なまたは順序を誤ったデータを相互に受信しないことを保証することができる。新たな直接パス呼５２８送信は、既存のＰＤＣＰ  ＳＤＵキューからであってもよく、または、異なる関連しないＰＤＣＰ  ＳＮから開始してもよい。例えば、ＷＴＲＵは現在、異なる暗号化メカニズムで構成された新たなベアラに関係していてもよいので、ＷＴＲＵは、ＳＮ＝０から開始してもよい。ＷＴＲＵはまた、上位レイヤによって配信された同期メッセージに基づいて、データパス切替え（インフラストラクチャとＤ２Ｄとの間）を完了するように構成されてもよい。例えば、Ｄ２Ｄセッションが既存のＩＭＳセッションに関係し、及び、ＷＴＲＵが異なるＩＰサブネットを使用するように構成されている場合、ＩＮＦＯ、ｒｅ−ＩＮＶＩＴＥ、ＯＫ、およびＡＣＫなどのＳＩＰメッセージが、ＩＰアドレス間の切替えを同期および完了するように使用されてもよい。
【００８０】
直接パス呼５２８の確立に続いて、ｅＮＢ５０３は、パス切替え要求５２９をＭＭＥ５０５に送信してもよい。ＳＧＷ／ＰＧＷ５０４は、ベアラ修正メッセージ５３０を送信してもよく、および、ｅＮＢ５０３は、インフラストラクチャベアラを削除するためのメッセージ５３１Ａおよび５３１Ｂを送信してもよい。
【００８１】
図６Ａ乃至６Ｂは、ｅＮＢ間のケースに対する、インフラストラクチャツーＬＴＥ直接パスオフロードシナリオ（Ｕｕのアクティブ化＋ＣＮオフロード）に対するトラフィックのオフロードのための方法６００の高レベルのコールフローチャートである。このモビリティ状況では、図６に示されるように、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２が、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂにそれぞれ接続されてもよく、相互にベースライン呼６１０に携わってもよい。
【００８２】
ＷＴＲＵ１  ６０１は、周期的なまたはトリガ式の発見プロセス６１１とともに、ＷＴＲＵ２  ６０２とのベースライン呼６１０をＬＴＥ直接パスにオフロードすることを開始してもよい。周期的な発見プロセス６１１では、ＷＴＲＵは、所定の時間インスタンスの間に、他のＷＴＲＵによる発見シーケンス送信を探索してもよい。それらはまた、他のＷＴＲＵによって発見されるために、それらの割り当てられたタイムスロットの間に、このようなシーケンスを送信してもよい。周期的な発見は、ＷＴＲＵがそれらの近接している全ての発見可能なＷＴＲＵを発見することを補助するように設計されてもよい。ＷＴＲＵ２が無線で近接していることを示す、ＷＴＲＵ１  ６０１からの発見／測定報告６１２が生成されてよく、および、ｅＮＢ１  ６０３Ａは、ｅＮＢ２  ６０３Ｂと協調して、信頼できるレイヤ３（Ｌ３）測定を生成するために、明示的な測定プロセスをセットアップしてもよい。ＭＭＥ６０４Ａはまた、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２の識別を、メッセージ６１３Ａを介してｅＮＢ１  ６０３Ａに送信してもよく、およびメッセージ６１３Ｂを介してＤ２Ｄサーバ６０６に送信してもよい。
【００８３】
代わりに、ネットワークは、トリガされる発見を有効にしてもよい。例えば、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、各デバイスアドレスならびに発見送信パターンが提供されることによって、相互に発見するように構成されてよい。このモードは、ＷＴＲＵが、相互により早く発見することを可能にする。ネットワークは、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２がＤ２Ｄ通信可能であることを保証した後で、このトリガされる発見モードを有効にしてもよい。位置または他の情報が、トリガされる発見に使用されてもよい。例えば、発見は、ＷＴＲＵが、同一のｅＮＢまたは地理的に隣接するｅＮＢに接続されたときにトリガされてもよい。代わりに、発見は、Ｗｉ−Ｆｉ直接などの非ＬＴＥ他のＲＡＴによってトリガされてもよい。トリガされる発見は、各ＷＴＲＵの直接パスリンクを反復測定に対する機会を含んでもよく、それにより、複数の個別測定にわたるレイヤ３（Ｌ３）フィルタリング６１５の後で、信頼できる測定報告６１６Ａおよび６１６Ｂが生成されてもよい。
【００８４】
発見に続いて、ＷＴＲＵは、測定構成を受信してもよい。ＷＴＲＵ１  ６０１は、測定構成６１４ＡをｅＮＢ１  ６０３Ａから受信してもよく、ＷＴＲＵ２  ６０２は、測定構成６１４ＢをｅＮＢ２  ６０３Ｂから受信してもよい。測定構成６１４Ａおよび６１４Ｂは、直接パス測定に対する拡張を含んでもよく、ならびにｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂの制御下にあってもよい。ＭｅａｓＣｏｎｆｉｇ  ＩＥにおける新たな要素が、または、既存の要素に対する拡張が、Ｄ２Ｄ特有の測定に対して定義されてもよい。これらの新たな要素は、ＭｅａｓＯｂｊｅｃｔＤ２ＤまたはＲｅｐｏｒｔＣｏｎｆｉｇＤ２Ｄの少なくとも１つを含んでもよい。測定構成６１４Ａおよび６１４Ｂにおいて、ネットワークはまた、Ｄ２Ｄリンクの、帯域外測定に対するキャリア周波数、または帯域内測定機会に対する測定ギャップを提供してもよい。
【００８５】
測定構成６１４Ａおよび６１４Ｂは、バックホールインタフェース上で交換されてもよい。ｅＮＢ間のケースに対し、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、測定構成要求６１４Ｃおよび６１４Ｄを相互に送信することによって、Ｘ２インタフェース上で構成を協調しなければならないことがある。ｅＮＢ１  ６０３ＡとｅＮＢ２  ６０３Ｂとの間にＸ２インタフェースが存在しない場合、これらは、Ｓ１０インタフェースを介して、ＭＭＥ１  ６０４ＡおよびＭＭＥ２  ６０４Ｂをそれぞれ介して協調してもよい。ｅＮＢ６０３ＡおよびｅＮＢ６０３Ｂはまた、インフラストラクチャ接続の間に、ＷＴＲＵのデバイス発見識別子と、インフラストラクチャ接続の間に使用されるＲＮＴＩなどの他の識別子との間のマッピングを取得するために、Ｄ２Ｄサーバ６０６に問い合わせてもよい。
【００８６】
代わりに、ｅＮＢ間のケースに対し、単一のネットワークノードが、測定構成６１４Ａおよび６１４Ｂを判定してもよい。例えば、対応するセッションおよび／または直接パスに対する無線リソースのスケジューリングを後に割り当て、構成し、および制御することができるノードは、測定構成６１４Ａおよび６１４Ｂを判定してもよい。このようなネットワークノードは、サービスのローカライゼーション（localization）に応じて選択されてもよく、それによって、ノードは、そのカバレッジエリアを理由に選択される。複数のＷＴＲＵの場合、最良の無線リンク品質を有し、最も多くのＷＴＲＵを管理するノードが選択されてもよい。
【００８７】
ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、測定報告６１６Ａおよび６１６ＢをｅＮＢ６０３Ａおよび６０３Ｂにそれぞれ送信することによって、測定構成６１４Ａおよび６１４Ｂに応答してもよい。測定報告が受信されると、インフラストラクチャパスから直接パスにオフロードする決定は、測定報告６１６Ａおよび６１６Ｂに基づいてもよい。測定閾値が構成されてもよく、この測定閾値に基づいてオフロード決定が行われる。オフロードは、単一のＷＴＲＵの測定に基づいてトリガされてもよく、代わりに、ｅＮＢは、他のＷＴＲＵの報告を待機してもよい。例えば、２つ以上のＷＴＲＵ間での直接パスに適用可能な測定報告６１６Ａおよび６１６Ｂの少なくとも１つが、所与の期間内に少なくとも２つのＷＴＲＵによって受信されるとき、ネットワークは、そのような報告の受信に応じて、直接パスを構成することができると判定してもよい。
【００８８】
ネットワーク制御エンティティは、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２の直接パス能力を判定してもよい。例えば、ｅＮＢ６０３Ａおよび６０３Ｂは、ＷＴＲＵ  Ｄ２Ｄ能力要求６１７Ａを行うために、ＭＭＥ１  ６０４ＡおよびＭＭＥ２  ６０４Ｂを通じてＤ２Ｄサーバ６０６と通信してもよく、および最適なＤ２Ｄ構成を取得するために、ＷＴＲＵ  Ｄ２Ｄ能力応答６１７Ｂを受信してもよい。Ｄ２Ｄ能力はとりわけ、ＷＴＲＵが直接パス通信を実行することが可能な帯域／チャネルを含んでもよい。Ｄ２Ｄセッションを確立するＷＴＲＵは、マスタまたはスレーブロールにおいて構成されてもよい。このロールは、Ｄ２Ｄリソース管理、セキュリティ、Ｄ２Ｄアクセス制御などに対する、ＷＴＲＵの振る舞いに影響を与えることがある。ＷＴＲＵはさらに、その現在のロールに基づいて、Ｄ２Ｄモビリティプロシージャを選択するように構成されてもよい。Ｄ２Ｄグループセッションでは、１つのＷＴＲＵがマスタロールにおいて構成されてもよい。
【００８９】
次いで、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、確立されたＲＲＣ接続を使用して、直接パス構成を受信してもよい。Ｄ２Ｄ構成は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ６１８Ａおよび６１８Ｂを通じて提供されてもよい。ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２はまた、ＮＡＳまたはＲＲＣメッセージ（例えばＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ）から、インフラストラクチャおよびＤ２Ｄパスに対する新たなフィルタリングルールを取得するように構成されてもよい。別の例では、ｅＮＢ１  ６０３Ａは、Ｄ２Ｄ  ＮＡＳ確立およびセキュリティメッセージ６１９Ａを、ＷＴＲＵ１  ６０１およびＭＭＥ６０４Ａに送信してもよい。同様に、ｅＮＢ２  ６０３Ｂは、Ｄ２Ｄ  ＮＡＳ確立およびセキュリティメッセージ６１９Ｂを、ＷＴＲＵ６０２およびＭＭＥ６０４Ｂに送信してもよい。
【００９０】
これらのメッセージは、Ｄ２Ｄセッション確立後に使用されることになる新たなアップリンクトラフィックフローテンプレート（ＵＬ  ＴＦＴ）を含んでもよい。
【００９１】
ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ６１８Ａおよび６１８Ｂを通じて直接パス構成を受信し、およびＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ６１８Ａおよび６１８Ｂを処理するのに続いて、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、対応するＤ２Ｄリンクの確立をトリガしてもよい。ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、物理レイヤとすることができる直接パス上で、ハンドシェイク６２１信号を交換してもよい。これらのハンドシェイク６２１信号を受信すると、ＷＴＲＵは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ６２２Ａおよび６２２Ｂを、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂにそれぞれ送信してもよく、ならびにＤ２Ｄセッションにおいて、データを送信および受信する準備をしてもよい。
【００９２】
ＲＬＣ  ＡＭベアラでのデータ送信のシームレスなオフロードを保証するために、ＷＴＲＵ１  ６０１からＷＴＲＵ２  ６０２へのデータパスを使用して、以下のアクションがとられてもよい。
【００９３】
ＷＴＲＵは、アップリンク（ＵＬ）、ダウンリンク（ＤＬ）、または両方に対する直接パスに関連するサービスに適用可能な任意のＤＲＢもサスペンドしてもよい。次いで、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ６２２Ａおよび６２２Ｂを、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂにそれぞれ送信してもよい。次いで、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、直接パスにリダイレクトされることになる任意のデータのインフラストラクチャ送信それぞれ停止するようＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２に命令する、明示的なＲＲＣメッセージ６２３Ａおよび６２３Ｂを送信してもよい。ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２はまた、ＤＲＢに対するＤＬにおいて、ＰＤＣＰステータスＰＤＵを受信してもよい。
【００９４】
ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂはまた、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂからの現在のＰＤＣＰステータス６２４Ａおよび６２４Ｂを、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２にそれぞれ提供してもよく、したがって、各ｅＮＢにおいて成功して受信された、連続した最後のＰＤＣＰ  ＰＤＵのシーケンス番号をＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２に通知することができる。このことは、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２が、直接パス送信に対する開始点（すなわちＰＤＣＰ  ＳＤＵ）を確認することを可能にする。ＷＴＲＵは、ＤＲＢについてのデータを受信してもよい。
【００９５】
ｅＮＢ１  ６０３Ａは、その送信バッファに残っている任意のデータを、ＷＴＲＵ１  ６０１に送信することを継続してもよい（６２５Ａ）。同様に、ｅＮＢ２  ６０３Ｂは、データをＷＴＲＵ２  ６０２に送信することを継続してもよい（６２５Ｃ）。
【００９６】
ｅＮＢ１  ６０３Ａはまた、連続したＰＤＣＰ  ＳＤＵからのその受信されたＰＤＵを、ＷＴＲＵ１  ６０１から、ＳＧＷ／ＰＧＷ６０５に転送することを継続してもよい（６２５Ｂ）。同様に、ｅＮＢ２  ６０３Ｂはまた、連続したＰＤＣＰ  ＳＤＵからのその受信されたＰＤＵを、ＷＴＲＵ２  ６０２から、ＳＧＷ／ＰＧＷ６０５に転送することを継続してもよい（６２５Ｄ）。ネットワークは、ソースｅＮＢ６０３とターゲットｅＮＢ６０３との間でエンドマーカを使用してもよい。
【００９７】
全てのデータをＳＧＷ／ＰＧＷ６０５に転送した後、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、ｅＮＢとＳＧＷ／ＰＧＷ６０５との間のＧＴＰ−Ｕトンネル上で、エンドマーカパケットを送信してもよい。エンドマーカは、ＧＴＰ−Ｕプロトコルを使用して、ＷＴＲＵ１  ６０１のＧＴＰトンネル６２６Ａを通じてＳＧＷ／ＰＧＷ６０５に、次いでｅＮＢ２  ６０３Ｂに転送されてもよい。エンドマーカはまた、ＧＴＰ−Ｕプロトコルを使用して、ＷＴＲＵ２  ６０２のＧＴＰトンネル６２６Ｂを通じてＳＧＷ／ＰＧＷ６０５に、次いでｅＮＢ１  ６０３Ａに転送されてもよい。
【００９８】
ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂにおけるエンドマーカの受信は、直接パスに切り替えられることになる無線ベアラ通信に関連するｅＮＢからのデータパケットがそれ以上存在しないことがあること（例えば、インフラストラクチャベース無線ベアラに関連付けられた全てのデータがＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２に送信されたこと）のインジケーションであってもよい。ｅＮＢ１  ６０３Ａは、ＷＴＲＵ１  ６０１への任意の残りのデータの送信を完了してもよく、ｅＮＢ２  ６０３Ｂは、ＷＴＲＵ２  ６０２への任意の残りのデータの送信を完了してもよい。次いで、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、Ｘ２インタフェース上で、エンドマーカの受信に対する肯定応答を相互に送信してもよい（６２７Ｃおよび６２７Ｄ）。
【００９９】
次いで、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、Ｄ２Ｄ送信を開始するようＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２にそれぞれ命令してもよい（６２７Ａおよび６２７Ｂ）。次いで、直接パス呼送信６２８は、ＰＤＣＰステータス報告に基づいている、ｅＮＢによって受信された連続した最後のＰＤＣＰ  ＰＤＵの後の１つである、適切なＰＤＣＰ  ＰＤＵから開始してもよい。このプロシージャは、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２が、直接パス上で冗長なまたは順序を誤ったデータを相互に受信しないことを保証する。
【０１００】
直接パス呼６２８の確立に続いて、ｅＮＢ１  ６０３Ａは、パス切替え要求６２９をＭＭＥ６０４Ａに送信してもよく、ＭＭＥ６０４Ａは、パス切替え要求６３２をＭＭＥ６０４Ｂに転送してもよい。ＳＧＷ／ＰＧＷ６０５は、ベアラ修正メッセージ６３０Ａを送信してもよく、ＭＭＥ６０４Ｂは、ベアラ修正メッセージ６３０Ｂを送信してもよい。ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂは、インフラストラクチャベアラを削除するためのメッセージ６３１Ａおよび６３１Ｂをそれぞれ送信してもよい。
【０１０１】
ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂが異なるＭＭＥに属する場合は、オフロードプロセスの一部として、Ｄ２Ｄ能力およびポリシを調停（reconcile）するために、Ｓ１０インタフェース上で、ＭＭＥ間で追加の通信が行われてよい。ｅＮＢ１  ６０３ＡとｅＮＢ２  ６０３Ｂとの間にＸ２インタフェースが存在しない場合は、Ｓ１０インタフェースを通じてＭＭＥを介した通信が行われてよい。
【０１０２】
ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２が異なるＰＬＭＮに属する場合は、インフラストラクチャパスから直接パスへのオフロードが実行される前に考慮すべきいくつかの追加の要素があることがある。
【０１０３】
まず、２つのＷＴＲＵオペレータが、異なる周波数帯域／チャネルを直接パス通信に使用する可能性が非常に高いことがある。よって、直接パスの構成の間に、２つのＰＬＭＮは、どの直接パス周波数が使用されるかにに合意し、この情報を、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージ６１８Ａおよび６１８Ｂの一部として、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２に提供しなければならないことがある。また、直接パスの２つの方向に、異なる周波数が使用される可能性もある。例えば、１つ周波数が、ＷＴＲＵ１  ６０１からＷＴＲＵ２  ６０２へのパスに使用され、別の周波数が、ＷＴＲＵ２  ６０２からＷＴＲＵ１  ６０１へのパスに使用されることがある。
【０１０４】
加えて、ＷＴＲＵ１  ６０１およびＷＴＲＵ２  ６０２からのデータは、同一または異なるＰＬＭＮに属することができる２つのＰＧＷを通じて流れることがある。ＰＧＷ間に直接ＧＴＰ−Ｕトンネルがないことがあり、データは、通常のＩＰデータとして、パブリックまたはプライベートインターネットクラウドを通じてルーティングされることがある。この状況では、エンドマーカがＧＴＰ−Ｕプロトコルを通じて提供されないことがある。このメカニズムがない場合、一部の他の方法が使用されて、ｅＮＢ１  ６０３ＡおよびｅＮＢ２  ６０３Ｂからの、およびその逆の送信の終了を判定してもよい。１つの考えられる技術は、ＷＴＲＵユーザからのパケットにおけるＴＣＰまたはＩＰヘッダデータを調べることに基づいてもよい。Ｘ２インタフェース上で、ｅＮＢ１  ６０３ＡとｅＮＢ２  ６０３Ｂとの間で一部のヘッダ情報が搬送されてよく、ターゲットｅＮＢは、最後のパケットを判定するために、そのＳＧＷからの着信パケットにおいて、この情報を探すことができる。
【０１０５】
代替方法は、単純に、インフラストラクチャパスの途中にある（en-route）全てのパケットを考慮することなしに、インフラストラクチャから直接パスに切り替えることであってもよい。このシナリオでは、ＴＣＰレイヤは、それが通常のように、連続しないイベントを扱ってもよい。
【０１０６】
図７は、ＷＴＲＵが直接パスのアクティブ化の失敗を認識する能力を有するフローチャート７００を示す。オフロードプロセス（例えば直接パスの確立および／またはアクティブ化）は、何らかの理由で失敗することがある。ＷＴＲＵは、オフロードプロセスの間、無線リンクを監視してもよい（７０１）。次いでＷＴＲＵは、オフロードが失敗したと判定してもよい。失敗を判定する１つの方法は、直接パスの無線リンク品質が、ある閾値未満であると判定すること（７０２）を含むが、これに限定されない。他の方法は、直接パスが、無線リンク障害の状態にあり、または、セキュリティが成功してアクティブ化されなかったと判定することを含んでもよい。セキュリティアクティブ化の不成功は、同一のセッションおよび／または直接パスの別のＷＴＲＵからの送信を認証することに失敗すること、またはヘッダ圧縮の失敗が繰り返されることを含むが、これらに限定されない。ＷＴＲＵは、オフロードプロシージャの開始時に始動されたタイマの満了からなどの、ある構成可能な時間の後に、または再構成プロシージャの受信後に、または再構成プロシージャの完了を示すメッセージの送信後に、このような失敗を判定してもよい。
【０１０７】
ＷＴＲＵが、プロセスが不成功であると判定したとき、ＷＴＲＵは、インフラストラクチャパス上でセッションを再確立するためのプロシージャを開始してもよい。インフラストラクチャから直接パスオフロードプロセスに関連付けられた異なるエアインタフェース、ネットワーク、および処理遅延を考慮するために、Ｔ３０４と異なるが同等であるオフロード失敗タイマが定義される必要があることがある。ＷＴＲＵが、失敗が発生したと判定すると、ＷＴＲＵは、失敗をｅＮＢに通知し（７０３）、次いでインフラストラクチャセッションを再確立してもよい（７０４）。
【０１０８】
図８は、ＬＴＥ直接パスからインフラストラクチャパスへのオフロードに対するｅＮＢ内ケースのモビリティプロシージャ８００についての、高レベルのコールフローチャートを示す。ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２は、直接パス呼８１０において接続されてもよい。ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２はすでにｅＮＢ８０３への接続性を有していてよいので、これらはすでに、インフラストラクチャパスに対するシグナリングおよびデータ無線ベアラを確立していてもよい。適切なＮＡＳおよびＡＳセキュリティ情報もまた、すでにＷＴＲＵに提供されていてもよい。
【０１０９】
Ｄ２Ｄサーバ８０６を介した直接パス呼８１０の過程で、ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２は、直接パス無線リンクの品質を常に監視してもよい。低下がある場合、測定イベント８１１がトリガされてよく、これにより、ＷＴＲＵ１  ８０１またはＷＴＲＵ２  ８０２が、測定イベント８１１に応答してｅＮＢ８０３へのＲＲＣ測定報告８１２をトリガするようになる。ｅＮＢ８０３は、通信をインフラストラクチャパスに切り替えることを決定し、オフロードプロセスを開始してもよい。ｅＮＢ８０３は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ要求メッセージ８１３および８１４を、ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２にそれぞれ送信してもよい。オフロードプロセスの一部として、その構成がｅＮＢ８０３と、インフラストラクチャリンク上でのＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２の能力との両方を考慮する、新たなＤＲＢが生成されてもよい。これらの新たなＤＲＢは、既存のインフラストラクチャパスＤＲＢにすでに利用可能なセキュリティ鍵を使用してもよく、または、ＡＳセキュリティが新たに確立されてもよい。
【０１１０】
直接パス呼８１０から切り替える前に、ＷＴＲＵ１  ８０１は、直接パス上で、ＰＤＣＰステータスＰＤＵ８１５をＷＴＲＵ２  ８０２に送信してもよい。同様に、ＷＴＲＵ２  ８０２は、直接パス上で、ＰＤＣＰステータスＰＤＵ８１６をＷＴＲＵ１  ８０１に送信してもよい。ＰＤＣＰステータスＰＤＵ８１５および８１６は、それぞれの最後に受信された連続したＰＤＣＰ  ＰＤＵを相互に通知してもよい。このことは、ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２が、データ損失も回避するために、適切なキュー位置において開始するインフラストラクチャパス上で送信を継続することを可能にする。ＰＤＣＰステータスＰＤＵ８１５および８１６の送信に続いて、ＷＴＲＵ１  ８０１は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ８１７ＡをｅＮＢ８０３に送信してもよく、同様に、ＷＴＲＵ２  ８０２は、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージ８１７ＢをｅＮＢ８０３に送信してもよい。直接パス切替え要求８１８はまた、ＣＮにおいてＭＭＥ８０５に送信されてもよく、ならびに、修正されたデータ無線ベアラに対応するＥＰＳベアラへのＳ１およびＳ５コンポーネントを確立することになる（８１９）。ＷＴＲＵ１  ８０１およびＷＴＲＵ２  ８０２が直接パス通信のみに携わるときは、ＳＧＷ／ＰＧＷ８０４のいずれかにおける、対応するＥＰＳベアラ要素がないことがあり、その場合は、対応するＳ１およびＳ５トンネルはないことに留意されたい。よって、これらのＥＰＳベアラ要素をセットアップするために、修正専用ベアラアクティブ化プロシージャが使用されてもよい。プロシージャは、確立されたインフラストラクチャパス呼８２０で終了してもよい。
【０１１１】
非ＬＴＥ  ＲＡＴ直接パスを伴うモビリティプロシージャに対する解決策は、特定のＲＡＴに使用されるプロトコルアーキテクチャに依存することがある。解決策は、３ＧＰＰ  ＬＴＥプロトコルスタックを、ＭＡＣおよびＰＨＹを含む非ＬＴＥ  ＲＡＴに重ねる（superimpose）ことを含むが、これに限定されない。このアプローチでは、非ＬＴＥ  ＲＡＴ  ＷＴＲＵ接続は、このＷＴＲＵのＬＴＥ接続と同一のＩＰアドレスを共有してもよく、このＩＰアドレスは、ＬＴＥにおいて定義されるようにモビリティアンカとしてサービスすることができるＰＧＷによって割り当てられてもよい。
【０１１２】
非ＬＴＥ  ＲＡＴに必要とされる逸脱（deviation）は、直接パスに対するＭＡＣおよびＰＨＹのＲＲＣ構成（非ＬＴＥ  ＲＡＴに特有のパラメータを含むが、これらに限定されない）を含んでよい。同様に、非ＬＴＥ  ＲＡＴの測定が構成されなければならないことがある。ＬＴＥネットワークは、非ＬＴＥ  ＲＡＴ構成の詳細の多くを認識してもよい。
【０１１３】
代わりに、ＩＰは、非ＬＴＥ  ＲＡＴ  ＭＡＣ＋ＰＨＹの最上部で直接に使用されてもよい。この解決策では、非ＬＴＥ  ＲＡＴのプロトコルは、ＬＴＥプロトコルスタックから完全に分離（disjoint）されてよい。上述したＬＴＥ直接パスとは対照的に、ｅＮＢのＲＲＣエンティティは直接パス通信を制御しなくてもよく、また、ｅＮＢはスケジューリングまたはリソース割り当てに参加しなくてもよい。ＷＴＲＵの非ＬＴＥ  ＲＡＴ接続は、ＬＴＥ接続とは異なるＩＰアドレスを有することもでき、または同一のＩＰアドレスを有することもできる。後者の場合、インフラストラクチャパス（ＬＴＥ）または直接パス（非ＬＴＥ  ＲＡＴ）を通じたトラフィックのフローは、論理インタフェース（ＬＩＦ）の構成に統制（govern）されてよい。ＬＩＦは、物理インタフェースとＩＰレイヤとを相互に隠すインタフェースであり、ＩＰフローモビリティのコンテキストにおいて使用されるように提案されたものである。後述する１つのアプローチは、３ＧＰＰネットワークが制御プレーンシグナリングを使用してＬＩＦの構成を変更することができるものである。この構成では、直接パスへのモビリティへのインフラストラクチャに対するモビリティプロシージャは、以下のように要約されてもよい。
【０１１４】
図９は、直接パス上での非ＬＴＥ  ＲＡＴからインフラストラクチャパスへのオフロード９００のためのプロシージャ９００の、高レベルのコールフローチャートを示す。ＷＴＲＵ１  ９０１は、ＬＴＥまたは非ＬＴＥ  ＲＡＴのいずれかにおいて、ＷＴＲＵ２  ９０２を発見してもよい（９１０）。ＬＴＥ発見に続いて、非ＬＴＥ  ＲＡＴ発見／測定９１１が、Ｄ２Ｄサーバ９０４などの、３ＧＰＰネットワークによってトリガされてもよい。加えて、Ｄ２Ｄサーバまたは他の３ＧＰＰネットワークエンティティは、ＬＴＥ発見または一部の他の近接の判定（ＷＴＲＵ１  ９０１およびＷＴＲＵ２  ９０２が、同一または隣接するｅＮＢに接続されているときなど）に基づいて、非ＬＴＥ  ＲＡＴ無線をアクティブ化してもよい（９１２）。非ＬＴＥ  ＲＡＴの無線パラメータに関する一部の情報はまた、３ＧＰＰネットワークによって提供されて、効率的な発見を促進してもよい。ＷＴＲＵ１  ９０１は、非ＬＴＥ  ＲＡＴチャネル品質を含む測定報告９１３を、ｅＮＢ９０３に送信してもよい。
【０１１５】
ｅＮＢは、通信を直接パスに移行させると決定してもよい（９１４）。直接パスの構成は、上記論じられたように、適切な論理インタフェースを提供することを構成してもよい。このプロシージャは、ＩＰルーティングテーブル更新に類似してもよい。
【０１１６】
非ＬＴＥ  ＲＡＴプロトコルスタックは、ＷＴＲＵ１  ９０１またはＷＴＲＵ２  ９０２においてアプリケーションから到着することができる、直接パス上でＩＰパケットを処理してもよい（９１５）。関係するインフラストラクチャパスＤＲＢおよびＥＰＳベアラ要素は削除されてよい（９１６）。直接パスからインフラストラクチャへのオフロードに対し、逆のプロセスが続いてもよい。インフラストラクチャパスが直接パスよりも高品質であることを示すことができる、ＷＴＲＵ１  ９０１またはＷＴＲＵ２  ９０２からの測定イベントは、ＬＩＦの再構成、ならびに適切な無線およびＥＰＳベアラのセットアップにつながる。
【０１１７】
図１０は、インフラストラクチャパスからローカルパスへのオフロードの方法１０００についての、高レベルのコールフローチャートを示す。インフラストラクチャからローカルパスへのオフロードは、ＷＴＲＵ１  １００１およびＷＴＲＵ２  １００２に対して透過的であってよい。関連するオーバジエア（over the air）リンクがないときは、Ｄ２Ｄサーバは、このオフロードにおいてロールを有さなくてよい。ｅＮＢ内とｅＮＢ間の両方のプロシージャが本明細書において説明される。
【０１１８】
ＷＴＲＵ１  １００１およびＷＴＲＵ２  １００２は、ｅＮＢ１  １００３ＡおよびｅＮＢ２  １００３Ｂをそれぞれ通じて、インフラストラクチャ呼１０１０に接続されてよい。ローカルパスにオフロードする決定がされたとき、ｅＮＢ１  １００３Ａは、ローカルパスをＸ２インタフェース上でセットアップするためのローカルパスセットアップ要求１０１１をｅＮＢ２  １００３Ｂに出してもよい。ローカルパスセットアップ応答１０１２を受信した後、ｅＮＢ１  １００３Ａは、追加パケットをＳＧＷ１００４に転送することを停止し、ＧＴＰ−Ｕトンネル上でエンドマーカ１０１３を送信してもよい。このエンドマーカは、Ｌｏｃａｌ  Ｐａｔｈ  Ｓｔａｒｔ１０１５メッセージの形式で、Ｘ２インタフェース上で肯定応答をｅＮＢ１  １００３Ａに送信することができる、ｅＮＢ２  １００３Ｂに到達する。同様に、ｅＮＢ２  １００３Ｂは、追加パケットをＳＧＷ１００４に転送するのを停止し、ＧＴＰ−Ｕトンネル上でエンドマーカ１０１４を送信してもよい。このエンドマーカは、ｅＮＢ１  １００３Ａは、Ｌｏｃａｌ  Ｐａｔｈ  Ｓｔａｒｔ１０１６メッセージの形式で、Ｘ２インタフェース上で肯定応答をｅＮＢ２  １００３Ｂに送信することができる、ｅＮＢ１  １００３Ａに到達する。
【０１１９】
ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ要求１０１８Ａおよび１０１８Ｂは、ｅＮＢ１  １００３ＡからＷＴＲＵ１  １００１に、およびｅＮＢ２  １００３ＢからＷＴＲＵ２  １００２に、それぞれ送信されてもよい。ＷＴＲＵ１  １００１は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ応答１０１９Ａを、ｅＮＢ１  １００３Ａに送信してもよい。同様に、ＷＴＲＵ２  １００２は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ応答１０１９Ｂを、ｅＮＢ２  １００３Ｂに送信してもよい。パス切替え要求１０２０は、ＭＭＥ１００５に送信されてもよい。ＭＭＥ１００５は、メッセージ１０２１および１０２２を介して、関連するＤＲＢに対応するＥＰＳベアラに対するＳ１、Ｓ５リンクを削除してもよい。代わりに、ｅＮＢは、ユーザデータプロトコルスタックをＩＰレイヤよりも下で終了（terminate）させてもよい（１０１７）。例えば、ユーザデータプロトコルスタックは、ＭＡＣレイヤよりも下で終了されてもよい。この設計では、ＰＤＣＰ／ＲＬＣ送信は、ＷＴＲＵ間であってよく、ｅＮＢは、ＭＡＣレイヤにおいてリレーとして動作してもよい。
【０１２０】
次いで、ローカルパス呼１０２３が開始してもよく、パケットはＸ２インタフェース上でルーティングされる。ソースｅＮＢは、ユーザパケットをＩＰレイヤにおいて終了させ、ローカルパスルート上でそれらをターゲットｅＮＢに転送する。
【０１２１】
ローカルパスから再びインフラストラクチャパスにオフロードすることは、Ｓ１およびＳ５インタフェースセットアップを含むようにＥＰＳベアラを修正することを伴ってもよい。適切な場合、ｅＮＢにおいて、ＩＰよりも下の終端（termination）からＩＰ終端に切り替えるために、ＲＲＣ再構成が必要とされてよい。
【０１２２】
ローカルからＬＴＥ直接パスへのオフロードに対するプロシージャは、上述したインフラストラクチャパスから直接パスへの場合と同様である。ＷＴＲＵ間での周期的またはトリガされる発見の後に、直接パスベアラに対する無線再構成が続いてよい。Ｘ２上でのローカルパスが使用されて、インフラストラクチャケースにおけるエンドマーカと等価なものを送信してもよいので、データ処理はより単純である。これは、Ｘ２上での新たなメッセージの定義を必要とする。これらのエンドマーカが肯定応答されると、直接パス送信が進行してもよい。
【０１２３】
ＬＴＥ直接パスからローカルパスへのオフロードは、本明細書に記載の他のものと同様である。この場合のパス切替えオプションは、データ転送のためのＸ２パイプがまだ存在しない場合、それを生成するオプションによって置き換えられる。
【０１２４】
ＬＴＥ直接パスと非ＬＴＥ直接パスとの間のオフロードは、ＷＴＲＵがそれらのハードウェア構成において両方の直接パスオプションをサポートするときに発生することがある。ＷＴＲＵは、一部の事前構成されたシーケンスにおいて、両方の直接パスの発見および測定を実行してもよい。両方のＲＡＴにおけるデバイス識別子、およびそれらの間のマッピングは、３ＧＰＰネットワークによって管理されてもよい。発見／測定報告がｅＮＢに提供されると、ｅＮＢは、１つの直接ＲＡＴから他方の直接ＲＡＴに通信をオフロードすることを決定してもよい。ＬＴＥ互換の非ＬＴＥ  ＲＡＴプロトコルの場合は、プロシージャは、主にＲＲＣ接続再構成プロシージャになって、無線ベアラ構成を変更してもよい。ＬＴＥ非互換の非ＬＴＥ  ＲＡＴの場合は、ＬＩＦを再構成し、無線ベアラおよびＥＰＳベアラを追加／削除することが望ましいことがある。
【０１２５】
別のモビリティイベントタイプは、サービングセルの変更（ハンドオーバシナリオ）を含む。図１１Ａ乃至１１Ａ１は、直接パス通信の間のインフラストラクチャハンドオーバ（ＨＯ）１１００に対する高レベルのコールフローチャートである。図１１Ａ乃至１１Ａ１におけるプロシージャは、ＷＴＲＵが、それらの直接パス通信を最小限の乱れ（disruption）で継続することを可能にする。このプロシージャがない場合、ＷＴＲＵは、それらの直接パス接続を閉じ、インフラストラクチャハンドオーバが完了した後でそれを再確立してもよい。
【０１２６】
このシナリオでは、ＷＴＲＵ１  １１０１がｅＮＢ１  １１０３Ａに接続され（１１１０）、ＷＴＲＵ２  １１０２がｅＮＢ２  １１０３Ｂに接続される（１１１０）。ＷＴＲＵ１  １１０１とＷＴＲＵ２  １１０２との間の直接パス呼１１１１が構成されてもよく、および進行中であってもよい。ＷＴＲＵ２  １１０２がｅＮＢ３  １１０３Ｃの近くに移動するとき、測定イベント１１１２が発生する。ＷＴＲＵ２  １１０２は、測定報告１１１３をｅＮＢ２  １１０３Ｂに送信して、インフラストラクチャパスに対するハンドオーバをトリガしてもよい。ｅＮＢ２  １１０３Ｂは、ハンドオーバ要求１１１４をＸ２インタフェース上でｅＮＢ３  １１０３Ｃに送信してもよく、また、ハンドオーバコマンド１１１５をＷＴＲＵ２  １１０２に送信してもよい。ハンドオーバコマンドの受信に続いて、ＷＴＲＵ２  １１０２は、ランダムアクセスチャネル（ＲＡＣＨ）プロセス１１１６を開始し、ハンドオーバ確認メッセージ１１１７をｅＮＢ２  １１０３Ｂに送信してもよい。
【０１２７】
ハンドオーバ要求１１１４はまた、直接パスの現在の構成を含んでもよい。このような構成は、１または複数の識別を含んでもよい。例えば、このような識別は、ＷＴＲＵ１  １１０１の識別、ｅＮＢ１  １１０３Ａの識別、および／またはＤ２Ｄ通信識別と称されてもよいＤ２Ｄセッション識別であってもよい。ｅＮＢ３  １１０３Ｃは、Ｄ２Ｄサーバ１１０５およびＭＭＥ１１０６とともに、ＷＴＲＵのＤ２Ｄ能力およびＤ２Ｄポリシを検証してもよい（１１１８）。ｅＮＢ３  １１０３Ｃは、Ｘ２上で、Ｄ２Ｄ構成要求１１１９でｅＮＢ１  １１０３Ａに接触してもよく、ｅＮＢ１  １１０３Ａは、Ｄ２Ｄ構成応答１１２０で応答してもよい。ｅＮＢ１  １１０３ＡおよびｅＮＢ３  １１０３ＣがＤ２Ｄ構成をネゴシエートした後は、ｅＮＢ１  １１０３Ａは、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ要求１１２１Ａを、ＷＴＲＵ１  １１０１に送信してもよく、ｅＮＢ３  １１０３Ｃは、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ要求１１２１Ｂを、ＷＴＲＵ２  １１０２に送信してもよい。結果的な構成はまた、ｅＮＢ１  １１０３ＡおよびｅＮＢ３  １１０３Ｃがピア関係を確立するか、または、ｅＮＢの１つがこの特定の直接パスに関してマスタロールを担うかに依存する。
【０１２８】
ＷＴＲＵ１  １１０１およびＷＴＲＵ２  １１０２はまた、通信を適切なキュー位置で継続することができるように、それぞれＰＤＣＰステータス１１２２Ａおよび１１２２Ｂを相互に提供してもよい。ＷＴＲＵはまた、上述したような発見または近接プロセスをトリガするシグナリングを受信してもよく、これは、直接パスが、１または複数の物理レイヤパラメータ（周波数またはリソース割り当てを含むがこれに限定されない）の再構成を必要とする場合に有意である。新たな直接パスが異なる周波数帯域にある場合は、ＷＴＲＵは、この新たな直接パスの周波数にそれぞれ同調してもよい（１１２３Ａおよび１１２３Ｂ）。次いで、ＷＴＲＵ１  １１０１およびＷＴＲＵ２  １１０２は、新たな帯域におけるそれらの直接パス関連付けを再確認するために、ＰＨＹハンドシェイクプロセスを完了（go through）してもよい。
【０１２９】
次いで、ＷＴＲＵ１  １１０１は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ応答１１２５Ａを、ｅＮＢ１  １１０３Ａに送信してもよい。同様に、ＷＴＲＵ２  １１０２は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ応答１１２５Ｂを、ｅＮＢ３  １１０３Ｃに送信してもよい。次いで、直接パス呼１１２６が再確立されてよい。
【０１３０】
ＷＴＲＵはまた、モビリティイベントによってトリガされるプロシージャを実行してもよい。このようなモビリティイベントは、ＷＴＲＵが、インフラストラクチャパスに戻るＤ２Ｄセッションの再確立を開始することと、使用される直接パスを再構成する制御シグナリング、またはＷＴＲＵのＲＲＣ接続のモビリティを示す制御シグナリングを、ＷＴＲＵがネットワークから受信するハンドオーバプロシージャと、セキュリティ再構成および／または再開と、モビリティプロシージャの間の遷移状態とみなされる他の類似するイベントとを含むが、これらに限定されない。
【０１３１】
図１１Ｂは、ＷＴＲＵがハンドオーバの間に実行することができるプロシージャ１１３０の例に対する高レベルのコールフローチャートを示す。ＷＴＲＵ１  １１０１およびＷＴＲＵ２  １１０２は、直接パス呼１１３１などのＤ２Ｄセッションに関与してもよい。次いで、ＷＴＲＵ１  １１０１は、ＨＯ準備メッセージ１１３２を送信することによって、そのＨＯステータスをＷＴＲＵ２  １１０２に通知してもよい。ＷＴＲＵ２  １１０２はまた、Ｄ２Ｄリンク上でＤ２Ｄセッションサスペンドメッセージ１１３３を送信してもよい。したがって、ＷＴＲＵ１  １１０１は、Ｄ２Ｄリンク上でのデータおよび制御シグナリングの送信および／または受信をサスペンドしてもよい。Ｄ２Ｄリンクアクセスが分散され、および、共通セル間リソースがＤ２Ｄチャネル（帯域内または帯域間）に使用される場合、ＷＴＲＵ１  １１０１は、Ｄ２Ｄセッションを継続してもよい。ＷＴＲＵ１  １１０１によるこれらのメッセージの使用は、構成可能であってよい。代わりに、または追加的に、ＨＯ準備メッセージ１１３５またはＤ２Ｄセッションサスペンドメッセージ１１３６は、ｅＮＢ１１０３によって送信されてもよい。ＷＴＲＵ１  １１０１はまた、Ｄ２Ｄセッションに対するそのマスタ／スレーブ構成を切り替えてもよい。ＷＴＲＵ２  １１０２はまた、ＷＴＲＵ１  １１０１からのＨＯ完了メッセージ１１３４を、直接パスリンク上でネットワークから受信することによって、プロシージャ１１３０の完了のインジケーションを受信するまで、ＷＴＲＵ１  １１０１へのＤ２Ｄ送信をサスペンドしてもよい。
【０１３２】
ＷＴＲＵ１  １１０１がＤ２Ｄセッションマスタとして構成された場合、ＷＴＲＵ２  １１０２は、セッションに対するマスタロールを引き継ぐように構成されてもよく（例えば１対１セッションの場合）、または、ＷＴＲＵ２  １１０２は、同一のＤ２Ｄセッションからの他のＷＴＲＵと、新たなマスタ選出を開始するように構成されてもよい（例えばグループセッションに対して）。
【０１３３】
半静的Ｄ２Ｄリソースは、ＷＴＲＵ間の通信に割り当てられてもよい。この場合、ＷＴＲＵは、直接パス上のモビリティの開始が示されると、割り当てられたリソースが無効であるとみなしてもよい。１つの解決策は、ＷＴＲＵ２  １１０２がＨＯ準備メッセージ１１３２を受信すると、ＷＴＲＵ２  １１０２が、割り当てられたリソースが解放されるとみなすことであってもよい。ＷＴＲＵ２  １１０２はまた、ＷＴＲＵ１  １１０１との通信に対するｅＮＢ１１０３からの新たなリソース割り当てを取得するために、リソースに対してスキャンをする（１１３７）ように構成されてもよい。別の解決策は、割り当てられたリソースが最大継続時間（タイマＴ１）にわたって保持されてもよく、ＷＴＲＵ２  １１０２がこれらのリソース上でのＨＯ完了メッセージ１１３４に対してスキャンするように構成されてもよいことであってもよい。タイマ満了時にメッセージが受信されていない場合は、リソースは解放されたとみなされてもよい。代替解決策では、ＨＯ完了メッセージ１１３４はネットワークから受信されてもよい。ＷＴＲＵ２  １１０２は、ＷＴＲＵ１  １１０１に関係するタイミング情報をリセットしてもよい（ＷＴＲＵ１自体が、ターゲットセルにおけるそのタイミング参照を更新することがあるので）。このタイミング情報は、Ｄ２Ｄタイミングアドバンス、またはＷＴＲＵ１メッセージ受信に対する受信ウィンドウを開くための参照時間、などに関係してもよい。
【０１３４】
図１１Ｃは、ＷＴＲＵがハンドオーバなどのモビリティプロシージャの完了に続いて実行するプロシージャ１１４０のフローチャートを示す。ＷＴＲＵは、発見されたサービスおよびＤ２Ｄ  ＷＴＲＵのそのリストをリセットしてもよい（１１４１）。ＷＴＲＵはさらに、前のセルにおいて発見され、および／または進行中の発見プロセスにあった１または複数のサービスに対する新たな発見プロセスを、そのサービングｅＮＢに要求してもよい（１１４２）。代わりに、ｅＮＢは、このサービスのリストをすでに知っている（例えばＰｒｏＳｅサーバまたはソースｅＮＢによって通信された）場合があり、新たな発見プロセスを開始するようにＷＴＲＵを直接に構成してもよい（１１４３）。ＷＴＲＵは、その前のサービングセルからの、発見されたサービス／ＷＴＲＵのリストを維持してもよい。ＨＯの後、ＷＴＲＵは、発見されたサービス／ＷＴＲＵのリストを、その新たなサービングセルに送信してもよい（１１４４）。代わりに、ｅＮＢは、このリストがＰｒｏＳｅサーバまたはソースｅＮＢによって通信された場合があるので、このリストをすでに有していることがある。ＷＴＲＵはまた、サービングセルにおいて取得されたタイミングアドバンスに基づいている、直接パスに対するタイミング情報を更新してもよい（１１４５）。ＷＴＲＵは、直接パスに対する更新された送信電力情報を取得してもよく（１１４６）、この情報は、セルにおいて許容される最大電力値を含むがこれに限定されない。ＷＴＲＵは、バッファステータス報告を送信することができ（１１４７）、この報告は、Ｄ２Ｄセッションに対する送信に利用可能であり、および／または直接パス上での送信に対するリソースを要求するのに利用可能なデータの量を含んでもよい。ＨＯの間にサスペンドされたマルチキャストＤ２Ｄセッションの場合、ＷＴＲＵは、マルチキャストトラフィックに再同期することができるように、セッションマスタメッセージから、またはそのサービングｅＮＢからのデータフローに関連付けられたＣＯＵＮＴ（ＨＦＮ＋ＳＮ）値を取得してもよい（１１４８）。さらに、セッションマスタＷＴＲＵは、データフローに関連付けられたＣＯＵＮＴ（ＨＦＮ＋ＳＮ）値を、モビリティプロシージャを実行していたことを以前に示すことができるＷＴＲＵとすることができる、別のＷＴＲＵに送信するように構成されてもよい（１１４９）
【０１３５】
図１２は、セル再選択またはＩＤＬＥモードモビリティである第３のモビリティイベントタイプに対する例示的な方法１２００のフローチャートを示す。ＲＲＣアイドルモードにあるＷＴＲＵが、Ｄ２Ｄセッションおよび／またはサービスで構成されてもよい。例えば、ＷＴＲＵが、Ｄ２Ｄリンク上でデータ送信を受信していてよく、このＤ２Ｄリンクは、ＷＴＲＵがＩＤＬＥモードに移動する前に専用シグナリングによって事前に構成され、または、ブロードキャストされたシグナリングの受信から構成されている。ＷＴＲＵは、ＲＲＣ  ＩＤＬＥにある間に、異なるセルを再選択してもよい。ＲＲＣ  ＩＤＬＥモードにあるＷＴＲＵは、Ｄ２Ｄセッションを維持する可能性に応じて、最良の適切なセルを選択してもよい（１２１０）。ＷＴＲＵは、選択されたセルにおいて、Ｄ２Ｄリンクが有効であるか否か判定してもよい（１２１１）。有効でない場合は、ＷＴＲＵは、直接パスからインフラストラクチャパスに移動することができるように、選択されたセルにおいてＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔプロシージャを開始してもよい（１２１２）。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｅｓｔａｂｌｉｓｈｍｅｎｔメッセージは、ＷＴＲＵによって送信されてもよい。次いでＷＴＲＵは、選択されたセルにおいて異なるＤ２Ｄリンクが使用されるように、Ｄ２Ｄセッションに関係するパラメータを再取得してもよい（１２１３）。
【０１３６】
上述した３つのモビリティイベントタイプの各々では、ＷＴＲＵおよびネットワークは、無線リンクを測定および監視しなければならないことがあり、また、リンクの突然の悪化に起因して発生することがある障害を管理しなければならないこともある。Ｄ２Ｄセッションの間、ベースラインセルラネットワークにおけるインフラストラクチャ無線リンク障害（ＲＬＦ）に加えて、Ｄ２Ｄシステムはまた、直接パス無線リンク障害（直接リンク障害（ＤＬＦ）と称されてもよい）の追加のケースになりやすい（prone to）。
【０１３７】
ＷＴＲＵが直接パス通信に携わるとき、インフラストラクチャ無線リンクは機能しないことがある（fail）。１つの例は、ＲＬＦが発生したときである。図１３Ａは、ＷＴＲＵが、ベースラインＲＬＦ処理に対して本明細書で説明されるプロシージャに取り組むことに加えて、ＲＬＦ障害を処理することができる、例示的な方法１３００を示す。ＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２は、直接パス呼において接続される（１３１０）。次いで、ＷＴＲＵ１  １３０１は即座に、直接パス上の全ての通信を中断してもよい（１３１１）。このことは最終的には、ＷＴＲＵ２  １３０２が、直接リンク上でＲＬＦを検出することにつながることがある（１３１２）。この場合、Ｕｕ  ＲＬＦのときに、割り当てられたリソースがｅＮＢ１３０３によって取り消されてもよい（１３１３）。
【０１３８】
図１３Ｂは、別のＲＬＦ処理プロシージャ１３１８に対する高レベルのコールフローを示す。ＷＴＲＵ１  １３０１は、直接パス上で、ＲＬＦメッセージ１３２１などの、ＲＬＦが発生したことを示すＤ２Ｄリンク障害メッセージをＷＴＲＵ２  １３０２に送信してもよい。次いで、ＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２は、通信を中断して（１３２２）、Ｄ２Ｄリンクの適切な切断を可能にする（１３２３）。
【０１３９】
図１３Ｃは、ＲＬＦを処理するためのさらに別のプロシージャ１３３０を示す。ＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２は、ｅＮＢ１  １３０３からのその現在のリソース許可が許可する限り、その直接パス呼１３３１を継続してもよい。ｅＮＢ１  １３０３は、ＵＬまたはＤＬ障害があると、直接パスに対する新たなリソースの割り当てをサスペンドしてもよい（１３３２Ａおよび１３３２Ｂ）。ＷＴＲＵがそれらの直接呼１３３１を継続している間、ＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２は、ネットワークへの接続性を再確立し、および／または、直接パスを再確立してもよい（１３３３）、これは、Ｖａｒ  ＲＬＦ  Ｒｅｐｏｒｔ  ＩＥに記憶された、最後の直接パス測定値、および他のＷＴＲＵの物理的な識別を使用することができる。ＲＲＣ再確立プロシージャは、ＲＬＦ状態が検出される前の任意の進行中のＤ２Ｄセッションに関する通知情報を含んでもよい。ベースラインＲＬＦ処理の一部として、ＷＴＲＵ１  １３０１は、適切なセルを短期間で発見することが可能である場合に、Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔプロシージャを完了して、直接パスを再確立してもよい（１３３３）。直接パスを再確立する（１３３３）ために、ＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２は、それらの前の物理的セルＩＤをｅＮＢ２  １３０４に提供してもよい（１３３４）。Ｄ２Ｄ呼もまた進行中であったことをｅＮＢ２  １３０４に通知する追加のフィールドが、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ要求に挿入されてもよい。このことはまた、ｅＮＢ２  １３０４が、Ｘ２インタフェース上でｅＮＢ１  １３０３にクエリして（１３３５）、前のＤ２Ｄ構成を取得し、および、場合によっては、新たな構成をネゴシエートすることを可能にする。次いで、これは、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージの一部としてＷＴＲＵ１  １３０１およびＷＴＲＵ２  １３０２に提供されてもよく、Ｄ２Ｄ呼は継続することができる。
【０１４０】
図１４Ａは、直接リンク障害（ＤＬＦ）処理（Ｄ２Ｄリンク障害と称されてもよい）に関するプロシージャ１４００についてのフローチャートを示す。ＷＴＲＵは、種々の直接パスリンクイベントに対し、直接パスを監視してもよい（１４１０）。次いで、ＷＴＲＵは、ＤＬＦを判定し（１４１１Ａ）、直接パス上での送信をサスペンドしてもよい（１４１２）。
【０１４１】
ＲＲＣ接続モードにあるＷＴＲＵは、ｅＮＢへの報告（測定報告、ＤＬＦ報告、近接検出報告のいずれか）をトリガしてもよく（１４１３）、および／または、モビリティプロシージャを開始して、Ｄ２Ｄセッションを継続してもよい。ＷＴＲＵは、有効な送信パスがＤ２Ｄセッションに対して確立されるまで、該当のＤ２Ｄセッションに対する直接パス上での送信をサスペンドしてもよい（１４１２）。
【０１４２】
直接リンク上でＤ２Ｄセッションにおいて送信しているＷＴＲＵに対し、それは、ＤＬＦがＵＬ、ＤＬ、または両方の上にあるかを判定してもよい（１４１１Ｂ）。例えば、ＷＴＲＵがＤＬＦを判定し（１４１１Ａ）、それ以上の送信が行われないようにしたとき、それは、ネットワークによって指示されない限り、ならびに／または、近接性が検出される間、および／もしくは、Ｄ２Ｄセッションが有効である間は、Ｄ２Ｄリンク上で他のＷＴＲＵとの送信の受信を試みることを継続してもよい。別の例では、ＷＴＲＵがＵＬ  ＤＬＦのみを判定した場合、それは、直接パス上で送信の受信を試みることを継続するが、何らかの条件が満たされるまで、直接パス上での送信をサスペンドしてもよい。条件は、ＷＴＲＵが有効なタイミング調整を再取得すること、および／または、ＷＴＲＵが、Ｄ２Ｄリンク上での送信をＷＴＲＵが実行することを可能にするＲＲＣシグナリングを受信すること、を含んでもよいが、これらに限定されない。ＷＴＲＵはまた、可能である場合、ＷＴＲＵの構成に基づいて、インフラストラクチャパス上でＤ２Ｄセッションに対するデータを送信してもよい。
【０１４３】
代わりに、または追加的に、ＷＴＲＵが報告をトリガしたとき、ＤＬＦはＷＴＲＵによってｅＮＢに示されてもよい（１４１３）。１つの例では、「直接パス障害」などを示す原因を有するＲＲＣ接続再確立などのＲＲＣシグナリングが、ＷＴＲＵによって使用されてもよい。ＷＴＲＵは、依然としてインフラストラクチャリンク上で接続性を有してもよく、したがってそのようなシグナリングを使用してもよい。ｅＮＢはまた、通信がインフラストラクチャパス上で継続することを可能にする。Ｘ２インタフェース上でのｅＮＢ間のこのプロセスの協調は、ｅＮＢ間のケースで使用されてもよい。このプロシージャは、上述した直接パスからインフラストラクチャへのハンドオーバと同様である。１つの逸脱は、ＤＬＦに起因して、直接パス上でのＷＴＲＵ間でＰＤＣＰステータスを交換することができず、これにより、ハンドオーバの間にＰＤＣＰ  ＰＤＵが順序どおりでなくなり、または消失する可能性があることである。代替手段は、ＷＴＲＵに、インフラストラクチャパス上でｅＮＢにＰＤＣＰステータスを報告させ、および、ハンドオーバの完了前にこれをピアＷＴＲＵに通信することでであってもよい。
【０１４４】
ＷＴＲＵは、直接パスリンクイベント１４１０に従ってＤＬＦを判定してもよい。これは、以下の技術のいずれかを含むが、これらに限定されない。
【０１４５】
ある技術に従って、直接パスに対する物理レイヤ非同期インジケーションが使用されてもよい。ＷＴＲＵは、直接パスに対する物理レイヤからいくつかの連続した非同期インジケーションが受信されたとき、Ｄ２Ｄリンクが障害を経験していると判定してもよく、例えば、非同期は、物理レイヤにおいて説明されたような参照シグネチャシーケンスを受信することに失敗したとして定義される。この数は構成可能であってよい。
【０１４６】
別の技術に従って、ＲＬＣ障害検出が使用されてもよい。ＷＴＲＵは、少なくとも１つのＲＬＣ再送が失敗したとき、または、いくつかのＲＬＣ再送が失敗した可能性がある（例えば再送の最大数のＲＬＣに到達した）とき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。この数は構成可能であってよい。このことはまた、ＲＬＣ再送が直接パスプロトコル機能の一部として定義されるときに当てはまることがある。ＷＴＲＵは、この場合、ＤＬＦのみのＵＬ、ＤＬＦのみのＤＬ、またはＵＬおよびＤＬのＤＬＦを判定してもよい。
【０１４７】
別の技術に従って、ＨＡＲＱ障害検出が使用されてもよい。ＷＴＲＵは、少なくとも１つの（または構成された数の）ＨＡＲＱプロセスが失敗したとき、および／またはいくつかのＨＡＲＱ再送が失敗した可能性がある（例えばＨＡＲＱ再送の最大数に到達した）とき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。この数は構成可能であってよい。これは、ＲＬＣが直接パスプロトコル機能の一部としてサポートされておらず、または、Ｄ２Ｄセッション／Ｄ２Ｄリンクに対して構成されていないときに、適用可能であることがある。ＷＴＲＵは、この場合、ＤＬＦのみのＵＬ、ＤＬＦのみのＤＬ、またはＵＬおよびＤＬのＤＬＦを判定してもよい。
【０１４８】
別の技術に従って、直接パス上のピアから受信されたインジケーションが使用されてもよい。ＷＴＲＵは、例えば１または複数のピアＷＴＲＵが直接パス通信および／またはＤ２Ｄセッションを離れていることのインジケーションをＷＴＲＵが受信とき、Ｄ２Ｄリンクが障害を経験していると判定してもよく、例えば、ＷＴＲＵがこのセッションに対してアクティブなＷＴＲＵが存在しないことを検出することができる。このことは、セッションにおける送信ＷＴＲＵのみを考慮することによって可能となることがある。
【０１４９】
別の技術に従って、不成功なサービス発見／近接検出が使用されてもよい。ＷＴＲＵは、１または複数のＷＴＲＵに対する発見／近接検出が不成功であると判定したとき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。例えば、継続的な近接を評価することができるように、このような検出は、ＷＴＲＵが直接パス上でアクティブである間に周期的に使用されてもよい。検出が失敗した場合、ＷＴＲＵは、直接パスリンクに対するＮＷによって割り当てられたリソースがもはや有効でないと判定してもよい。このことは、セッションに対してアクティブなＷＴＲＵが存在しないことをＷＴＲＵが検出したときに可能となることがある。このことは、セッションにおける送信ＷＴＲＵのみを考慮することによって可能となることがある。
【０１５０】
別の技術に従って、無効なセッションパラメータが使用されてもよい。ＷＴＲＵは、直接パスリンクに対するネットワークによって割り当てられたリソースがもはや有効でないと判定したとき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。例は以下を含むが、これらに限定されない。すなわち、割り当てられたリソースの有効性の時間満了、ならびに、直接パスのリソースに対応する、サービングセルに対して受信されたスケジューリング情報の変更が検出されること（Ｄ２Ｄリソースが、Ｄ２Ｄセッションおよび／または直接パスへのリソースの割り当てに専用のブロードキャストシグナリング、ブロードキャストチャネルによって割り当てられる場合）、である。ＷＴＲＵは、このような場合、特に、リソースが、専用シグナリングによって割り当てられたとき、または該当のＷＴＲＵのみに専用であったときに、ＵＬ  ＤＬＦのみを判定してもよい。
【０１５１】
別の技術に従って、無効なセキュリティ状態が使用されてもよい。ＷＴＲＵは、Ｄ２Ｄリンクおよび／またはＤ２Ｄセッションのセキュリティに問題があると判定したとき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。例えば、ＷＴＲＵは、セキュリティアクティブ化が失敗したこと、セキュリティ状態がもはや有効でないこと、または／および、セキュリティがもはや同期されないことを判定してもよい。ＷＴＲＵはまた、インフラストラクチャリンクおよび／または確立されたＲＲＣ接続に関係する以下のイベントのうちの少なくとも１つに従って、ＤＬＦを判定してもよい。
【０１５２】
別の技術に従って、ＲＲＣ接続状態遷移が使用されてもよい。ＷＴＲＵは、インフラストラクチャとの接続に対しＲＲＣ  ＩＤＬＥへの遷移を実行するとき（例えば、ＲＲＣ接続解放を受信すると）、Ｄ２Ｄリンクが障害を経験していると判定してもよい。場合によっては、ＷＴＲＵは、このような場合、ＵＬ  ＤＬＦのみを判定する。
【０１５３】
セルがもはやＷＴＲＵにアクセス可能でない：ＷＴＲＵは、Ｄ２Ｄリンクに割り当てられたリソースに対応するサービングセルがもはやアクセス可能でないと判定したとき（例えば、セルがＷＴＲＵのクラスに対して禁じられているか、または、セルが緊急サービスのみを受け入れ、Ｄ２Ｄセッションがそのようなサービスクラスのものでない）、Ｄ２Ｄリンクが障害を経験していると判定してもよい。
【０１５４】
アップリンクタイミング同期がもはや有効でない：ＷＴＲＵは、サービングセルにおける送信に対してアップリンクタイミング調節がもはや有効でないとき、Ｄ２Ｄリンクが障害を経験していると判定してもよい。ＷＴＲＵは、このような場合、ＵＬ  ＤＬＦのみを判定する。
【０１５５】
ＷＴＲＵはまた、以下の条件（ただしこれらに限定されない）のうちの少なくとも１つを検出したとき、Ｄ２Ｄセッションが障害を起こしている／終了していると判定してもよい。すなわち、ＷＴＲＵが、上述したような、直接パスに対するＤＬＦ、またはそれにつながる可能性のあるいずれかの条件を判定すること、ＷＴＲＵが、モビリティが障害を起こし（例えばＨＯが失敗した）、または、直接パスに対するモビリティが障害を起こしていると判定すること、および、ＷＴＲＵが、直接パスに対する構成を有さないｍｏｂｉｌｉｙｔ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ  ＩＥ（例えばＨＯコマンド）を有するＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信し、ＷＴＲＵがソースセルにおいて直接パス上の通信でアクティブであったこと、である。
【０１５６】
図１４Ｂは、直接リンク障害（ＤＬＦ）（Ｄ２Ｄリンク障害とも称される）に関係するプロシージャ１４１８に対する別のフローチャートを示す。ＷＴＲＵは、ＲＲＣ  ＩＤＬＥモードであってもよく、様々な直接パスリンクイベントに対し、直接パスを監視してもよい（１４２０）。次いでＷＴＲＵは、ＤＬＦを判定し（１４２１）、インフラストラクチャパス上でのサービス継続性の目的で、ＲＲＣ接続確立を開始してもよい（１４２２）。ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  ＥｓｔａｂｌｉｓｈｍｅｎｔメッセージがＷＴＲＵによって送信されてもよい。
【０１５７】
ＬＴＥシステムでは、ＷＴＲＵは、ＲＲＣ接続に関連付けられた単一のセキュリティコンテキストを維持してもよい。ＷＴＲＵは追加で、Ｄ２Ｄサービス、Ｄ２Ｄセッション、またはＤ２Ｄリンクに関連付けられたセキュリティコンテキストを維持してもよい。これらのセキュリティコンテキストは、鍵および／または暗号化アルゴリズムなど、いくつかのセキュリティパラメータを含んでもよい。図１５は、Ｄ２Ｄ通信に対するセキュリティプロシージャ１５００についてのフローチャートを示す。
【０１５８】
Ｄ２Ｄ通信では、ＣＯＮＮＥＣＴＥＤモードにあるＷＴＲＵは、例えばＤ２Ｄリンクの構成と共に、セッション特有のセキュリティ構成をネットワークから受信してもよい（１５１０）。代わりにまたは追加的に、ＣＯＮＮＥＣＴＥＤモードにあり、セッションにおいてデータを送信するように構成されたＷＴＲＵは、確立されたインフラストラクチャリンク上でそのセキュリティパラメータを提供してもよく、それにより、Ｄ２Ｄセッションの受信側とすることができる任意のＷＴＲＵは、セキュリティパラメータを受信し、その後、それらを、このＷＴＲＵから受信された任意のデータに適用してもよい。複数の送信ＷＴＲＵを有するセッションに対し、セッションの間に受信するＷＴＲＵは、ＷＴＲＵ当たり１つのセキュリティ構成で構成されてよい（１５１０）。例えば、受信ＷＴＲＵは、送信ＷＴＲＵの識別を使用して、どのセキュリティコンテキストを適用するかを判定してもよい。
【０１５９】
次いで、ＷＴＲＵは、アプリケーションに応じて、どのセキュリティパラメータを適用するかを判定してもよい（１５１１）。代わりにまたは追加的に、ＷＴＲＵは、対応するＤ２Ｄセッションに対するデータを生成するアプリケーションによって、関連するセキュリティパラメータで構成されてもよい。このようなパラメータは、固定であってもよく（例えば、加入者の情報、サービスグループなどの一部として）、または、上位レイヤによって取得されてもよい。
【０１６０】
次いで、ＷＴＲＵは、特定の鍵セットまたは鍵階層を使用して、セキュリティ鍵を導出してもよい（１５１２）。ＷＴＲＵは、以下を含む（ただしこれらに限定されない）エンティティの１つまたは組合せに基づいて、Ｄ２Ｄセッションに対するセキュリティ鍵を導出するように構成されてもよい。すなわち、ＮＡＳレベルのＫASME（アクセスセキュリティ管理エンティティ）、ＡＳレベルのＫeNB、ＰｒｏＳｅサーバによって生成されるＫProSe（例えばサービスに関連する鍵）、ネットワークによって生成されるＫDirectPath（例えばＤ２ＤリンクまたはＤ２Ｄ接続に関連する鍵）である。例えば、上記の鍵の１または複数は、Ｄ２Ｄ通信のセキュリティコンテキストの一部であってよい。次いで、ＷＴＲＵは、直接パス上で交換されるデータおよび／または制御シグナリングに使用される暗号化および認証鍵に対し、後者の２つのパラメータを使用して鍵導出を実行してもよい。
【０１６１】
上述した鍵の各々に対し、鍵の有効性は、地理的エリアに関連付けられてもよい。例えば、ＷＴＲＵは、セキュリティ関連プロシージャを実行してもよい。ＷＴＲＵは、所与のＤ２Ｄ接続／リンクに特有の鍵を使用してもよい。ＷＴＲＵは、ＫeNB鍵を少なくとも部分的に使用して、またはより一般的には、１または複数のｅＮＢに関連付けられ、および／または１または複数のｅＮＢによって割り当てられた鍵を使用して、Ｄ２Ｄセッションに対するセキュリティ鍵を導出する（１５１２）ように構成されてもよい。このセキュリティ鍵は、ＲＡＮ鍵と称されてもよい。ＷＴＲＵはさらに、ＫeNBがもはや有効でない場合にＷＴＲＵのサービングセルを変更したときにＤ２Ｄセッションを解放するように構成されてもよい。さらに別の例では、ＷＴＲＵはさらに、セッションマスタとして構成された場合にはＤ２Ｄセッションを維持するように、または、セッションスレーブとして構成された場合にはＤ２Ｄセッションを解放するように構成されてもよい。Ｄ２Ｄセッションが維持される場合、セッションマスタは、そのサービングセルからの新たなＫeNBに基づいて、鍵更新を要求するように構成されてもよい。
【０１６２】
ＫeNB鍵は、直接パスおよび／またはＤ２Ｄ通信の、物理リソースに関連してもよい。したがって、ＫeNB鍵は、インフラストラクチャパスに使用される鍵とは異なってよい（すなわち、ＲＡＮに向けたセキュリティをアクティブ化するのに使用される鍵とは異なってもよい）。鍵は、リソースのセットを割り当てることができ、および／または物理レイヤパラメータまたはスケジューリングを制御することができる任意のｅＮＢを含む、１または複数のｅＮＢに共通であってもよい。鍵はまた、所与のセッションおよび／または所与の直接パスに対するリソースのセット上でアクティブに送信および／または受信している任意のＷＴＲＵを含む、関与する任意のＷＴＲＵに共通であってよい。
【０１６３】
ＷＴＲＵは、ＫASME鍵を少なくとも部分的に使用して、または、ＮＡＳレイヤに関連付けられ、またはＮＡＳレイヤによって割り当てられた鍵を使用して、Ｄ２Ｄに対するセキュリティ鍵を導出してもよい（１５１２）。例えば、これはＣＮ鍵であってよい。ＷＴＲＵはさらに、ＫASMEがもはや有効でないことから、そのサービングＭＭＥを変更したときに、Ｄ２Ｄセッションを解放するように構成されてもよい。ＷＴＲＵはさらに、セッションマスタとして構成された場合にはＤ２Ｄセッションを維持するように、または、セッションスレーブとして構成された場合にはＤ２Ｄセッションを解放するように構成されてもよい。Ｄ２Ｄセッションが維持される場合、セッションマスタは、そのサービングセルからの新たなＫASMEに基づいて、鍵更新を要求するように構成されてもよい。
【０１６４】
ＫASME鍵は、特定のＤ２Ｄセッション、サービス、および／または、同一の加入および／またはパブリックセーフティユニット（Public Safety unit）などの能力を共有するＷＴＲＵのグループに関連付けられてもよい。したがって、ＫASME鍵は、インフラストラクチャパスに使用される鍵とは異なってもよく、よって、ネットワークサービスにアクセスするためにＷＴＲＵによって使用される鍵とは異なってもよい。鍵は、１または複数のネットワークノードによって知られてもよい。例えば、リソースのセットを割り当てることができ、および／もしくは物理レイヤパラメータまたはスケジューリングを制御することができる任意のｅＮＢ、ならびに／または、Ｄ２Ｄセッションに関与し、所与のセッションおよび／もしくは所与の直接パスに対するリソースのセット上でアクティブに送信および／もしくは受信している任意のＷＴＲＵによって知られてよい。
【０１６５】
ＷＴＲＵは、所与のＤ２Ｄセッションに特有の鍵を使用してもよい。ＷＴＲＵは、ＫProSe鍵を少なくとも部分的に使用して、Ｄ２Ｄに対するセキュリティ鍵を導出してもよい（１５１２）。１つの解決策では、ＷＴＲＵはさらに、サーバ変更に続いてＫProSeが有効でないことから、そのサービングＰｒｏＳｅサーバを変更したときに、Ｄ２Ｄセッションを解放するように構成されてもよい。ＷＴＲＵはさらに、セッションマスタとして構成された場合にはＤ２Ｄセッションを維持するように、または、セッションスレーブとして構成された場合にはＤ２Ｄセッションを解放するように構成されてもよい。Ｄ２Ｄセッションが維持される場合、セッションマスタは、そのサービングセルからの新たなＫProSeに基づいて、鍵更新を要求してもよい。Ｄ２Ｄセッションが維持される場合、セッションマスタは、そのサービングセルからの新たなＫProSeに基づいて、鍵更新を要求するように構成されてよい。
【０１６６】
ＫProSe鍵は、特定のＤ２Ｄ通信サービスに関連付けられてもよい。鍵は、リソースのセットを割り当ててもよく、ならびに／または物理レイヤパラメータもしくはスケジューリングを制御することができる任意のｅＮＢ、および／もしくは、Ｄ２Ｄセッションに関与し、所与のセッションおよび／もしくは所与の直接パスに対するリソースのセット上でアクティブに送信および／もしくは受信している任意のＷＴＲＵなど、１または複数のネットワークノードによって知られてもよい。
【０１６７】
ＷＴＲＵは、所与のＤ２Ｄセッションに特有の鍵を使用してもよい。ＷＴＲＵは、ＫDirectPathからＤ２Ｄに対するセキュリティ鍵を導出する（１５１２）ように構成されてもよい。ＫDirectPath鍵は、特定の直接パスに関連付けられてもよい。鍵は、リソースのセットを割り当ててもよく、ならびに／または物理レイヤパラメータまたはスケジューリングを制御することができる任意のｅＮＢ、および／もしくは、Ｄ２Ｄ通信セッションに関与し、所与のセッションおよび／もしくは所与の直接パスに対するリソースのセット上でアクティブに送信および／または受信している任意のＷＴＲＵなど、１または複数のネットワークノードによって知られてもよい。ＫDirectPath鍵はまた、対応する無線リソースが有効である間のみ、有効であってもよい。
【０１６８】
認証付きセキュリティが構成された場合、および、セキュリティがアクティブ化を必要とする場合、ＷＴＲＵは、ＷＴＲＵがアルゴリズムおよびセキュリティコンテキストから取り出された鍵を使用して認証を検証することができるＤ２Ｄリンク上でデータを受信したとき、最初にセキュリティをアクティブ化してもよい（１５１３）。セキュリティアクティブ化は、セキュリティコンテキストがＤ２Ｄリンクに対する全ての送信ＷＴＲＵに共通であるとき、Ｄ２Ｄリンクに適用可能であってもよい。セキュリティアクティブ化はまた、セキュリティコンテキストがセッションにおける全ての送信ＷＴＲＵに共通であるとき、Ｄ２Ｄセッションに共通であってもよい。セキュリティアクティブ化はまた、データがそこから受信されるＷＴＲＵごとに適用可能であってもよい。このような認証情報は、任意の受信されたＰＤＵに対して、または特定のＰＤＵに対して存在してもよい。このようなＰＤＵは、Ｄ２Ｄリンクを介して交換される制御ＰＤＵであってよく、または、特定のシーケンス番号を有する任意のＰＤＵ（例えば、セッションにおける最初のＰＤＵ、または、ＳＮ  ｍｏｄ（ｘ）＝０に対応するものなど、所与の期間ｘを有する任意のＰＤＵ）であってもよい。ＰＤＣＰが、Ｄ２Ｄリンク上で交換されるトラフィックに対して構成されるとき、ＰＤＣＰは、本明細書で説明されるようにセキュリティ機能を実行してもよい。
【０１６９】
セキュリティのアクティブ化１５１３の障害、またはセキュリティ障害は、本明細書で説明されるようにサービス再確立につながることがある。ＷＴＲＵは、セキュリティのアクティブ化に失敗することがあり、または、同期を失ってセキュリティのアクティブ化１５１３に失敗することがある。ＷＴＲＵが障害を検出したとき、ＷＴＲＵは、新規セッションセットアップなど、直接パス通信から離れたモビリティイベントとしてサービスを再確立することができるように、プロシージャを開始してもよく、または、本明細書で説明されたモビリティイベントタイププロシージャにおけるように、Ｄ２Ｄセッション全体を終了させてもよい。
【０１７０】
モビリティイベントが発生したとき、ＷＴＲＵは、以下の少なくとも１つを実行してもよい。すなわち、ＷＴＲＵは、ＷＴＲＵに、モビリティイベントが発生したときに、直接パスに対してセキュリティをアクティブ化させ（１５１３）、新たなセキュリティ構成をセキュリティ構成１５１０後の最初の送信に適用させる（１５１０）ことを含むことができる、セキュリティセキュリティを再開始してもよい。ＷＴＲＵは、モビリティイベントが上述したようなインフラストラクチャからトランスペアレントなローカルパスへのものであるときに、セキュリティをアクティブ化してもよく（１５１３）、これは、パス特有のセキュリティコンテキストが存在するときの、ネットワークによるトランスペアレントな転送を含んでもよい。ＷＴＲＵは、モビリティイベントが上述したようなインフラストラクチャから直接パスへのものであるときに、セキュリティをアクティブ化してもよい（１５１３）。ＷＴＲＵはまた、モビリティイベントが本明細書で説明されたような直接パスからローカルパスへのものであるとき（ネットワークがデータを復号化し、これをＷＴＲＵ特有のセキュリティコンテキストを使用して送信するときを含む）、またはその逆のときに、セキュリティをアクティブ化してもよい（１５１３）。
【０１７１】
他の場合には、ＷＴＲＵは、リンクの再構成の後、いかなる修正なしにセキュリティを継続してもよい。これは、モビリティイベントがインフラストラクチャからローカルパスへのものであるとき（ネットワークがデータを復号化し、これをＷＴＲＵ特有のセキュリティコンテキストを使用して送信するときを含む）、またはその逆のときなどである。ＷＴＲＵはまた、モビリティイベントが本明細書で説明されたような直接パスからトランスペアレントなローカルパスへのものであるとき（パス特有のセキュリティコンテキストが存在するときにネットワークによってトランスペアレントな転送が使用されるときを含む）、またはその逆のときに、いかなる修正なしにセキュリティを継続してもよい。
【０１７２】
図１６は、モビリティおよび測定イベントに対してトリガを使用することができるプロシージャ１６００についてのフローチャートを示す。ＷＴＲＵは、近接検出構成（測定構成と称されてもよい）によって構成されてもよく、および近接検出構成を維持してもよい（１６１０）。このような構成は、少なくとも１つの測定識別を含んでよく、これは、測定構成および／または発見信号プロパティにリンクされた、測定オブジェクトを含むが、これに限定されない。測定は、基準信号など、Ｄ２Ｄリンクに対して受信された送信に対して実行されてもよく、または、同一のＤ２Ｄセッションの他のＷＴＲＵに関連付けられた発見信号に関して実行されてもよく、または、本明細書で説明された物理レイヤ測定値など、リンク利用可能性および／またはリンク品質を評価するのに適した任意の他の信号に関して実行されてもよい。
【０１７３】
直接パスに対する測定構成および報告が、本明細書に説明される。ＷＴＲＵによるｅＮＢへのＤ２Ｄ測定の報告を補助するために、ＭｅａｓＲｅｓｕｌｔｓＤ２Ｄなどの追加のＩＥが、既存のＭｅａｓＲｅｓｕｌｔｓ  ＩＥに追加されてもよい。Ｏｔｈｅｒ−ＲＡＴ測定値がまた、このＩＥに収容されてよい。同様に、Ｄ２Ｄに対する測定報告構成を指定するために、ＲｅｐｏｒｔＣｏｎｆｉｇＥＵＴＲＡ  ＩＥに追加が行われてよく、または、別個のＲｅｐｏｒｔＣｏｎｆｉｇＤ２Ｄ  ＩＥが生成されてもよい。Ｄ２Ｄ測定値に対するＬ３フィルタリングパラメータが、例えばｆｉｌｔｅｒＣｏｅｆｆｉｃｉｅｎｔＤ２Ｄ  ＩＥとして、別個に指定されてもよい。
【０１７４】
ＷＴＲＵからｅＮＢへの検出報告をトリガする（１６１１）新たな測定イベントが生成されてもよい。ＷＴＲＵは、Ｄ２Ｄ特有のイベントで構成されてよく、これらのイベントは、直接パスが絶対閾値よりも高いこと、直接パスが絶対閾値よりも悪いこと、直接パスが閾値の分、インフラストラクチャパスよりもよいこと、を含むがこれらに限定されない。
【０１７５】
Ｄ２Ｄ測定の報告をトリガもしくは制御（gate）するのに使用することができ、またはモビリティ決定に対するトリガとして使用することができる、他のいくつかの基準が、以下に列挙される。
【０１７６】
ＷＴＲＵにおいてＤ２Ｄ周波数で検出される干渉レベルがまた基準であってもよい。干渉レベルは、パス損失測定よりも、配信可能データ容量をより示してもよい。例えば、潜在的なＤ２Ｄリンク上で測定されたＲＳＲＱが考慮されてよい。それはまた、ＲＳＲＱがある閾値未満のときであり、実際の構成されたＤ２ＤリンクのＲＳＲＰが別の閾値よりも高いときなどのような、２ステップ基準であってもよい。ＲＳＲＱ閾値はまた、ＲＳＲＱが閾値よりも高くなったときなど、Ｄ２Ｄリンクが確立および使用されているときに、構成および報告されてもよい。
【０１７７】
ＷＴＲＵの現在のモビリティ状態（速度）がまた基準であってもよい。例えば、ＷＴＲＵが高速で移動している場合、Ｄ２Ｄリンクへの切替えが遅延されてもよい。このことは、リンクの頻繁な切替え、ゆえにデータ損失を回避することができる。しかし、予期されるＤ２Ｄリンクにおける両方のＷＴＲＵが高速で移動しているが、これら間のＤ２Ｄリンクの良好な測定値一貫して報告する場合、１つの含意（implication）は、これらは同一の方向に移動しており（おそらく、グループモビリティシナリオにおいてのように、一緒に）、よってこれらの間でＤ２Ｄリンクが確立されてもよい。モビリティ推定は、ドップラ測定または既存のモビリティ状態推定（ＭＳＥ：Mobility State Estimation）アルゴリズムに基づいてよく、または、ネットワークによって追跡されるように（例えばマクロモビリティを追跡することによって）推定されてもよい。
【０１７８】
代わりにまたは追加的に、ＷＴＲＵは、他の品質測定とは別個の近接検出構成１６１０を有してもよい。ＷＴＲＵは、別のＷＴＲＵの近接性の検出（近接検出とも称される）に関係する信号の受信に対して構成されてもよい。代わりにまたは追加的に、ＷＴＲＵは、近接報告構成で構成されてもよい。このような構成は、近接検出が成功すると、検出報告をトリガする（１６１１）か否かを判定する能力をＷＴＲＵに提供することを含んでもよい。これは、例えば、受信信号自体に応じたものであってよく、例えば、信号の時間および／または周波数におけるリソースに応じたものであり、またはこの信号において受信された署名に応じたものであってよい。
【０１７９】
ＷＴＲＵは、ＷＴＲＵおよび／またはサービスに対応する検出オブジェクトのリストを有してよく、このリストは、識別を含むことができるパラメータを使用して索引付けされてもよい。このような識別は、潜在的なピアＷＴＲＵおよび／またはＤ２Ｄ通信識別と称されてもよい、Ｄ２Ｄセッションに対応してもよい。ＷＴＲＵは、近接検出構成１６１０のアクティブ化状態を修正する制御シグナリングを受信してもよい。例えば、このような制御シグナリングは、ＰＤＣＣＨ上のＤＣＩ（場合によっては、ＷＴＲＵのグループ（例えば、Ｄ２Ｄ対応可能な、および／または特定のサービスに関心があるＷＴＲＵ）に適用可能なＲＮＴＩによってスクランブルされた）において、またはＭＡＣ  ＣＥとして、またはＲＲＣシグナリングとして、受信されてもよい。それはまた、所与のエリア／セルにおける利用可能なＤ２Ｄセッションに関する情報を提供することになる、ブロードキャストまたはグループキャストチャネル上で受信されてよい。制御シグナリングは、適用可能な近接検出オブジェクトに対する索引を含んでもよい。
【０１８０】
ＷＴＲＵは、その近接検出構成１６１０に対応する信号を受信した場合に、検出報告をトリガしてもよい（１６１１）。例えば、ＷＴＲＵは、検出された近接信号が、特定の信号、ＷＴＲＵ、および／またはＤ２Ｄセッション、の少なくとも１つに対応すると判定した場合に、検出構成に基づいて検出報告をトリガしてもよい（１６１１）。これは、以下を含むもの（ただしこれらに限定されない）に基づいてよい。すなわち、信号において受信された署名、識別、信号および近接検出に対する構成されたリソースセットに応じて判定された索引、セッションＩＤなど、検出された信号に関連付けられた特定のセッション、または、検出された信号に関連付けられたリンクのタイプ（例えばリンクがインフラストラクチャサポートを有するか）、である。
【０１８１】
近接検出構成１６１０は、以下のオブジェクト（ただしこれらに限定されない）を含んでよい。
【０１８２】
近接検出オブジェクト：このようなオブジェクトは、信号の１または複数のプロパティを含んでもよい。例えば、これは、周波数、および／またはリソースに対する索引の少なくとも１つを含んでもよい。ＷＴＲＵは、オブジェクト構成を使用して、どこで近接検出を試みることができるかを判定してもよい。例えば、オブジェクトは、Ｄ２Ｄサービスおよび／またはセッションの識別に関連付けられた、信号および／または識別のリストを含んでもよい。
【０１８３】
近接報告構成：報告構成は、報告基準のリストに対応してもよい。例えば、これは、リソースに対する索引（近接検出オブジェクトによって提供されない場合）、ＷＴＲＵ識別、サービス識別、および／または直接パスタイプを含んでもよいが、これらに限定されない。このような構成は、追加的に、近接検出が成功したかを判定するために追加の測定が必要とされか否かを含んでもよい。ＷＴＲＵは、近接報告構成を使用して、検出が成功すると、検出構成１６１１に基づいて検出報告をトリガするか否かを判定してもよい。追加の基準は、周期的なまたは単一のイベントの記述を含んでもよい。このような構成は、追加的に、例えば、報告するための検出された信号および／またはＷＴＲＵ／サービスの番号を含むことができる、報告フォーマットを追加的に含んでもよい。
【０１８４】
近接検出識別は、検出オブジェクトを近接検出構成１６１０とリンクさせることができる識別のリストに対応してもよい。例えば、ＷＴＲＵは、どの特定の信号が報告されているかをネットワークが判定することができるように、このような識別を検出報告に含めてもよい（または、場合によっては、本明細書に説明されたような測定報告にも）。
【０１８５】
近接測定ギャップ構成：このような構成は、検出プロセスに関連付けられてもよい。例えばこれは、マクロレイヤのみに接続され、および／または近接検出構成１６１０の周波数／帯域において構成されたセルを有していない、ＷＴＲＵに有用であることがあり、それにより、ＷＴＲＵは、インフラストラクチャパス上のデータ転送を逃すことがなく、単に近接検出の目的で、追加の送受信機チェーン（transceiver chain）をオンにすることも必要とされなくてよい。
【０１８６】
ＷＴＲＵは、以下のイベントを含む（ただしこれらに限定されない）イベントが発生したときに、近接検出報告をトリガしてもよい（１６１１）。
【０１８７】
ＷＴＲＵは、近接検出構成１６１０を使用して、所与の周波数における１または複数のＷＴＲＵの存在を検出するように構成されてもよく、ならびに、受信された信号強度が不十分であり、および／またはＤ２Ｄセッションがアクティブでないときなど、十分な測定値が利用可能でない。
【０１８８】
ＷＴＲＵは、近接検出構成１６１０を使用して、所与の周波数における１または複数のＷＴＲＵの存在を検出するように構成されてよく、および、関連付けられた測定が構成されない。
【０１８９】
ＷＴＲＵが近接検出報告１６１１をトリガしたとき、ＷＴＲＵは、ＷＴＲＵの構成のＳＲＢ上で、ＲＲＣ  ＳＤＵの送信を開始してもよい。
【０１９０】
ネットワークは、直接パスおよび／または関連付けられた基準信号を構成することによって応答してもよい。ネットワーク側に対し、ネットワークノードは、近接検出報告１６１１の受信から、検出された信号に対応する１または複数の直接パスが構成およびアクティブ化されるべきか否かを判定してもよい。例えば、ＷＴＲＵは、その後、直接パスに対する構成を受信してもよく（１６１２）、無線品質測定（例えばＲＳＲＰまたは類似のもの）に適切な追加の基準信号の送信を開始して、さらなる測定を有効にしてもよく、ならびに／または、本明細書で説明される方法に従って、ハンドシェイクプロシージャを開始してＤ２Ｄリンクを確立してもよい。
【０１９１】
ネットワークは、本明細書で説明された任意の他の方法に従って、直接パスおよび／または関連付けられた基準信号に対する測定を構成することによって応答してもよい。ネットワークノードはまた、近接検出報告１６１１の受信から、以下の動作を含む（ただしこれらに限定されない）少なくとも１つの動作を実行するようＷＴＲＵに命令することができるか否かを判定してもよい。
【０１９２】
検出された信号に対応することができる直接パス（またはその対応する基準信号）に対し、それらが、そのＷＴＲＵに対してまだ構成されていない場合、および／またはそのような測定報告が検出報告と共に受信されなかった場合に、測定を実行する。
【０１９３】
本明細書で説明された任意の他の方法に従って、ＷＴＲＵの構成（例えば、受信された測定報告が十分な無線品質を示す場合に）に対する直接パス（および／またはその対応する基準信号）を構成できるＲＲＣ再構成を実行する。
【０１９４】
図１７Ａ乃至Ｂは、ＷＴＲＵがトリガに対する測定と共に近接検出を考慮することができるプロシージャ１７００および１７１８についてのフローチャートを示す。ＷＴＲＵは、Ｄ２Ｄセッション当たり、および／または所与のＤ２Ｄセッションに対するピアＷＴＲＵ当たりに、１つの測定オブジェクトで構成されてよい。Ｄ２Ｄセッションは、単一のＤ２Ｄリンクに対応してもよい。測定オブジェクトは、１または複数のエントリのリストを含んでもよく、各エントリは、少なくとも１つの発見信号プロパティを構成することができる。測定オブジェクト構成の、考えられる各ピアに対して、１つのこのようなエントリが存在してもよい。例えば、Ｄ２Ｄ対応可能なＷＴＲＵは、確立することに関心があってもよく、または、所与のＤ２Ｄセッションにおいてすでにアクティブであってよい。発見信号プロパティは、ＷＴＲＵ識別または書名、発見信号などに対する時間ドメイン位置および／または周波数ドメイン位置などの、近接検出情報に対応してもよい。このようなリストは、所与のＤ２Ｄセッションに対するＷＴＲＵのセットなど、ホワイトリスト登録された（whitelisted）ＷＴＲＵのセットに対応してよい。このような構成はまた、発見信号に関連するサービスのタイプなど、または直接パスのタイプなどの、情報を含んでもよい。例えば、構成は、直接パスがインフラストラクチャモードを使用するか否かに対応する情報、あるいは、ＲＳＲＰ測定に使用することができる基準信号のタイプに関する一部の情報を含んでもよい。
【０１９５】
図１７Ａは、十分な条件が存在するときに、直接パスを確立するのにインバウンドモビリティトリガが使用するときについてのフローチャートを示す。例えば、ＷＴＲＵは、対応するサービスに対する直接パスの確立に関心があるときに、Ｄ２Ｄ測定拡張を含む測定オブジェクトに対し、近接検出測定の実行を開始してもよい（１７１０）。この近接検出測定１７１０は、例えば上述したように、受信された基準信号に関するものであってよい。代わりにまたは追加的に、ＷＴＲＵは、対応するＤ２Ｄサービスに対する直接パスの確立に関心があるときに、Ｄ２Ｄ測定拡張を含む測定オブジェクトに対し、測定報告をトリガしてもよい（１７１２）。次いで、ＷＴＲＵは、Ｄ２Ｄサービスに対し、少なくとも１つの対応するピアＷＴＲＵを成功して検出することができる（１７１１）。近接検出測定が開始され（１７１０）、測定がトリガ基準を満たすとき、ＷＴＲＵは、インフラストラクチャモードなどの場合に、測定報告をトリガしてもよい（１７１２）。代わりにまたは追加的に、ＷＴＲＵは、Ｄ２Ｄリンクの取得を開始して（１７１３）、本明細書で説明された任意の他の方法に従って、Ｄ２Ｄ通信を確立してもよい。
【０１９６】
図１７Ｂは、不十分な条件が存在するときに直接パスから切り替えるのにアウトバウンドモビリティトリガが使用されうるときについてのフローチャートを示す。例えば、直接パス上でアクティブである間に、ＷＴＲＵは、進行中のＤ２Ｄセッションに対応するＤ２Ｄ測定拡張を含む測定オブジェクトに対し、測定を実行してもよい（１７２０）。このような場合、ＷＴＲＵが、測定イベントが発生した（例えばリンクの品質がある閾値未満であることを示すなど）と判定し（１７２１）、測定報告をトリガした（１７２２）とき、それはもはや、Ｄ２Ｄセッションにおける少なくとも１つの他のＷＴＲＵの近接性を成功して検出しないことがある。この場合、次いでＷＴＲＵは、本明細書で説明された任意の他の方法に従って、Ｄ２Ｄセッションから移動またはハンドオーバするための、および／またはＤ２Ｄセッションを再確立するためのプロシージャを開始してもよい（１７２３）。
【０１９７】
実施形態
１．デバイス間（Ｄ２Ｄ）通信におけるモビリティのための方法。
【０１９８】
２．モビリティは、あるｅＮＢから別のｅＮＢへの、Ｄ２Ｄセッションにおけるユーザのハンドオーバを含む、実施形態１における方法。
【０１９９】
３．モビリティは再構成を含み、再構成は、通信パスの変更、サービングセルの変更、またはセル再選択を含む、前述の実施形態のいずれかにおける方法。
【０２００】
４．再構成は直接通信パスを開始または変更する、前述の実施形態のいずれかにおける方法。
【０２０１】
５．再構成の場合に、イベント後に同じインフラストラクチャリンクが引き続き使用される、前述の実施形態のいずれかにおける方法。
【０２０２】
６．ハンドオーバの場合に、イベント後に異なるインフラストラクチャノードが使用される、前述の実施形態のいずれかにおける方法。
【０２０３】
７．ハンドオーバの場合に、障害が、再確立を必要とする無線リンク障害につながる、前述の実施形態のいずれかにおける方法。
【０２０４】
８．再構成の場合に、障害が、最適には及ばない性能につながるが無線リンク障害にはつながらない、前述の実施形態のいずれかにおける方法。
【０２０５】
９．第１の無線送信／受信ユニット（ＷＴＲＵ）であるＷＴＲＵ１が、第１の進化型ノードＢ（ｅＮＢ）であるｅＮＢ１に接続され、第２のＷＴＲＵであるＷＴＲＵ２が、第２のｅＮＢであるｅＮＢ２に接続される、前述の実施形態のいずれかにおける方法。
【０２０６】
１０．ｅＮＢ内の場合に、同じｅＮＢが使用される、前述の実施形態のいずれかにおける方法。
【０２０７】
１１．ｅＮＢ間の場合に、異なるｅＮＢが使用される、前述の実施形態のいずれかにおける方法。
【０２０８】
１２．２つのｅＮＢが、同じ公衆地上モバイルネットワーク（ＰＬＭＮ）内の同じモビリティ管理エンティティ（ＭＭＥ）の下にある、前述の実施形態のいずれかにおける方法。
【０２０９】
１３．２つのｅＮＢからのデータパスが、同じパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）につながる、前述の実施形態のいずれかにおける方法。
【０２１０】
１４．２つのＷＴＲＵは、周期的な発見の間に、またはトリガ式の発見プロセスによって、直接パスリンク上で相互を発見する、前述の実施形態のいずれかにおける方法。
【０２１１】
１５．周期的な発見の間に、ＷＴＲＵは、所定の時間インスタンスの間に他のＷＴＲＵによる発見シーケンス送信を探す、前述の実施形態のいずれかにおける方法。
【０２１２】
１６．ＷＴＲＵは、他のＷＴＲＵによって発見されるように、割り当てられたタイムスロットの間に発見シーケンスを送信する、前述の実施形態のいずれかにおける方法。
【０２１３】
１７．周期的な発見は、ＷＴＲＵが近くの全ての発見可能なＷＴＲＵを見つけるのを補助する、前述の実施形態のいずれかにおける方法。
【０２１４】
１８．トリガ式の発見プロセスの場合に、ＷＴＲＵ１およびＷＴＲＵ２には、他方のデバイスのアドレスおよび発見送信パターンが提供される、前述の実施形態のいずれかにおける方法。
【０２１５】
１９．トリガ式の発見は、ネットワークによって、ＷＴＲＵがＤ２Ｄ通信可能であることを識別した後で可能にされる、前述の実施形態のいずれかにおける方法。
【０２１６】
２０．場所情報が発見をトリガする、前述の実施形態のいずれかにおける方法。
【０２１７】
２１．トリガ式の発見は、ＷＴＲＵの直接パスリンクの反復的な測定を含む、前述の実施形態のいずれかにおける方法。
【０２１８】
２２．２つのｅＮＢは、協調して、周期的な発見のための明示的な測定プロセスをセットアップする、前述の実施形態のいずれかにおける方法。
【０２１９】
２３．ネットワークは、帯域外の場合にＤ２Ｄリンクについて測定が実施されなければならないキャリア周波数を提供する、前述の実施形態のいずれかにおける方法。
【０２２０】
２４．ネットワークは、帯域内の場合に測定機会を可能にするための測定ギャップを提供する、前述の実施形態のいずれかにおける方法。
【０２２１】
２５．バンド内の場合に、測定構成は一方のｅＮＢの制御下にある、前述の実施形態のいずれかにおける方法。
【０２２２】
２６．バンド間の場合に、測定構成はｅＮＢ１とｅＮＢ２との間の協調を必要とする、前述の実施形態のいずれかにおける方法。
【０２２３】
２７．ｅＮＢ１とｅＮＢ２との間の協調はＸ２インタフェースを介して行われる、前述の実施形態のいずれかにおける方法。
【０２２４】
２８．ｅＮＢ１とｅＮＢ２との間の協調は、ＭＭＥの助けによりＳ１０インタフェースを介して行われる、前述の実施形態のいずれかにおける方法。
【０２２５】
２９．ｅＮＢは、ＷＴＲＵのデバイス発見識別子間のマッピングをＭＭＥサーバに照会する、前述の実施形態のいずれかにおける方法。
【０２２６】
３０．単一のネットワークノードが測定構成を決定する、前述の実施形態のいずれかにおける方法。
【０２２７】
３１．インフラストラクチャパスから直接パスにハンドオーバする決定は、測定結果に基づいて行われる、前述の実施形態のいずれかにおける方法。
【０２２８】
３２．測定閾値が構成される、前述の実施形態のいずれかにおける方法。
【０２２９】
３３．ハンドオーバは単一のＷＴＲＵの測定に基づいてトリガされる、前述の実施形態のいずれかにおける方法。
【０２３０】
３４．ｅＮＢは、ＭＭＥを介してＤ２Ｄサーバと通信してＷＴＲＵのＤ２Ｄ能力を決定する、前述の実施形態のいずれかにおける方法。
【０２３１】
３５．Ｄ２Ｄ能力は、ＷＴＲＵが直接パス通信を実施できる帯域またはチャネルを含む、前述の実施形態のいずれかにおける方法。
【０２３２】
３６．ｅＮＢ間のケースで、ｅＮＢ１およびｅＮＢ２は、Ｘ２を介して通信してＤ２Ｄ構成の詳細を決定する、前述の実施形態のいずれかにおける方法。
【０２３３】
３７．Ｄ２Ｄセッションを確立するＷＴＲＵがマスタまたはスレーブとして構成される、前述の実施形態のいずれかにおける方法。
【０２３４】
３８．新たなＩＰアドレスがＤ２Ｄセッションに使用される、前述の実施形態のいずれかにおける方法。
【０２３５】
３９．Ｄ２Ｄ構成はＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを介して提供される、前述の実施形態のいずれかにおける方法。
【０２３６】
４０．ＷＴＲＵは、ＮＡＳまたはＲＲＣメッセージに対して、インフラストラクチャパスおよびＤ２Ｄパスについての新たなフィルタリング規則を取得するように構成された、前述の実施形態のいずれかにおける方法。
【０２３７】
４１．ＷＴＲＵは直接パス上でハンドシェイク信号を交換する、前述の実施形態のいずれかにおける方法。
【０２３８】
４２．ハンドシェイク信号は物理レイヤにおけるものである、前述の実施形態のいずれかにおける方法。
【０２３９】
４３．ＷＴＲＵは、ＲＲＣＣｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  ＣｏｍｐｌｅｔｅメッセージをｅＮＢに送信する、前述の実施形態のいずれかにおける方法。
【０２４０】
４４．インフラストラクチャ無線ベアラおよびＥＰＳベアラが管理される、前述の実施形態のいずれかにおける方法。
【０２４１】
４５．インフラストラクチャ無線ベアラは削除される、前述の実施形態のいずれかにおける方法。
【０２４２】
４６．インフラストラクチャ無線ベアラは保持される、前述の実施形態のいずれかにおける方法。
【０２４３】
４７．ＥＰＳベアラは純粋なＤ２Ｄ  ＥＰＳベアラとして再構成される、前述の実施形態のいずれかにおける方法。
【０２４４】
４８． ＥＰＳベアラは、Ｓ１インタフェースコンポーネントおよびＳ５インタフェースコンポーネントを削除することによって再構成される、前述の実施形態のいずれかにおける方法。
【０２４５】
４９．Ｓ１インタフェースコンポーネントおよびＳ５インタフェースコンポーネントの削除は、ＭＭＥによって開始される専用ベアラ非アクティブ化プロシージャによって達成される、前述の実施形態のいずれかにおける方法。
【０２４６】
５０．専用ベアラ非アクティブ化プロシージャは、ＷＴＲＵとｅＮＢとの間の無線ベアラを解放することを含む、前述の実施形態のいずれかにおける方法。
【０２４７】
５１．ＥＰＳベアラは、インフラストラクチャパスデータ無線ベアラ（ＤＲＢ）と直接パスＤＲＢの両方を有する特別なＤ２Ｄ  ＥＰＳベアラとして再構成される、前述の実施形態のいずれかにおける方法。
【０２４８】
５２．サービスに関連するＥＰＳベアラは、コアネットワーク（ＣＮ）中のＷＴＲＵのＤ２Ｄセッションのために維持される、前述の実施形態のいずれかにおける方法。
【０２４９】
５３．ＥＰＳベアラについてのＳ１−Ｕ通信パスが解体される、前述の実施形態のいずれかにおける方法。
【０２５０】
５４．ｅＮＢ１は、無線リソース制御（ＲＲＣ）メッセージをＷＴＲＵ１に送信して、直接パスにリダイレクトされるどんなデータの送信も停止する、前述の実施形態のいずれかにおける方法。
【０２５１】
５５．ｅＮＢ１は、現在のパケットデータ収束プロトコル（ＰＤＣＰ）ステータスをＷＴＲＵ１に提供する、前述の実施形態のいずれかにおける方法。
【０２５２】
５６．ＰＤＣＰステータスは、ｅＮＢ１においてうまく受信された順序どおりの最後のＰＤＣＰプロトコルデータユニット（ＰＤＵ）のシーケンス番号をＷＴＲＵ１に知らせる、前述の実施形態のいずれかにおける方法。
【０２５３】
５７．ＷＴＲＵ１は開始点を確認する、前述の実施形態のいずれかにおける方法。
【０２５４】
５８．ｅＮＢ１は、ｅＮＢ１の送信バッファ中の残りのデータをＷＴＲＵ１に送信する、前述の実施形態のいずれかにおける方法。
【０２５５】
５９．ｅＮＢ１は、順序どおりのＰＤＣＰサービスデータユニット（ＳＤＵ）からの受信されたデータパケットをＷＴＲＵ１からサービングゲートウェイ（ＳＧＷ）に転送する、前述の実施形態のいずれかにおける方法。
【０２５６】
６０．ｅＮＢ１は、ｅＮＢ１とＳＧＷとの間の一般パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）−ユーザプレーン（ＧＴＰ-Ｕ）上でエンドマーカパケットを送信する、前述の実施形態のいずれかにおける方法。
【０２５７】
６１．エンドマーカは、ＧＴＰ−Ｕプロトコルを使用してＷＴＲＵ１のＧＴＰトンネルを介してＰＧＷに転送される、前述の実施形態のいずれかにおける方法。
【０２５８】
６２．エンドマーカは、ＷＴＲＵ２のＧＴＰトンネルを介してｅＮＢ２に転送される、前述の実施形態のいずれかにおける方法。
【０２５９】
６３．エンドマーカは、プライベート拡張を使用して施行される、前述の実施形態のいずれかにおける方法。
【０２６０】
６４．プライベート拡張は追加の機能を定義する、前述の実施形態のいずれかにおける方法。
【０２６１】
６５．ＷＴＲＵ１およびＷＴＲＵ２は２つの異なるＰＧＷに属する、前述の実施形態のいずれかにおける方法。
【０２６２】
６６．ＰＧＷ１とＰＧＷ２との間にＧＴＰトンネル接続性がない、前述の実施形態のいずれかにおける方法。
【０２６３】
６７．ｅＮＢ２におけるエンドマーカの受信は、ｅＮＢ１からのデータがそれ以上ないことを示す、前述の実施形態のいずれかにおける方法。
【０２６４】
６８．ｅＮＢ２は、ＷＴＲＵ２への残りのデータの送信を完了する、前述の実施形態のいずれかにおける方法。
【０２６５】
６９．ｅＮＢ２は、ｅＮＢ２へのエンドマーカの受信に対する肯定応答を送信する、前述の実施形態のいずれかにおける方法。
【０２６６】
７０．ｅＮＢ１間のケースで、肯定応答はＸ２インタフェースを介して送信される、前述の実施形態のいずれかにおける方法。
【０２６７】
７１．ｅＮＢ１は、送信されたＰＤＣＰステータス報告に基づいて直接パス上の送信を開始するようＷＴＲＵ１に命令する、前述の実施形態のいずれかにおける方法。
【０２６８】
７２．直接パス上の送信は、ｅＮＢ１によって受信された順序どおりの最後のＰＤＣＰ  ＰＤＵの後のＰＤＣＰ  ＰＤＵから始まる、前述の実施形態のいずれかにおける方法。
【０２６９】
７３．ＷＴＲＵは、より高いレイヤによって送達された同期メッセージに基づいてデータパス切替えを完了するように構成された、前述の実施形態のいずれかにおける方法。
【０２７０】
７４．ＷＴＲＵはハンドオーバ失敗を検出する、前述の実施形態のいずれかにおける方法。
【０２７１】
７５．ＷＴＲＵは、無線リンク品質、無線リンク障害、セキュリティ構成の不成功、またはヘッダ圧縮失敗に基づいてハンドオーバ失敗を検出する、前述の実施形態のいずれかにおける方法。
【０２７２】
７６．ハンドオーバが失敗した場合に、ＷＴＲＵ１とＷＴＲＵ２との間の呼はインフラストラクチャパスを介して継続される、前述の実施形態のいずれかにおける方法。
【０２７３】
７７．ハンドオーバ失敗タイマを使用して、種々のエアインタフェース遅延、ネットワーク遅延、および処理遅延が反映される、前述の実施形態のいずれかにおける方法。
【０２７４】
７８．ｅＮＢ１およびｅＮＢ２は異なるＭＭＥに属する、前述の実施形態のいずれかにおける方法。
【０２７５】
７９．ＷＴＲＵ１およびＷＴＲＵ２は２つの異なるＰＬＭＮに属する、前述の実施形態のいずれかにおける方法。
【０２７６】
８０．２つのオペレータが、異なる周波数帯域を直接パス通信に使用する、前述の実施形態のいずれかにおける方法。
【０２７７】
８１．２つのＰＬＭＮは、どの直接パス周波数を使用するかについて合意する、前述の実施形態のいずれかにおける方法。
【０２７８】
８２．２つのＰＬＭＮは、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎの一部として直接パス周波数をＷＴＲＵに提供する、前述の実施形態のいずれかにおける方法。
【０２７９】
８３．直接パスの２つの方向に異なる周波数が使用される、前述の実施形態のいずれかにおける方法。
【０２８０】
８４．データが公衆または私設インターネットクラウドを介して通常のＩＰデータとしてルーティングされる、前述の実施形態のいずれかにおける方法。
【０２８１】
８５．ユーザからのパケット中のＩＰヘッダデータが調べられる、前述の実施形態のいずれかにおける方法。
【０２８２】
８６．ヘッダ情報がｅＮＢ１とｅＮＢ２との間でＸ２インタフェースを介して搬送される、前述の実施形態のいずれかにおける方法。
【０２８３】
８７．ターゲットｅＮＢが、ＳＧＷからの入来パケット中の情報を探して最後のパケットを決定する、前述の実施形態のいずれかにおける方法。
【０２８４】
８８．インフラストラクチャは、インフラストラクチャを介した途中のパケットを考慮することなしに直接パスに切り替えられる、前述の実施形態のいずれかにおける方法。
【０２８５】
８９．伝送プロトコル（ＴＣＰ）レイヤが、順序どおりでないイベントを処理する、前述の実施形態のいずれかにおける方法。
【０２８６】
９０．ＷＴＲＵ１およびＷＴＲＵ２は、直接パス無線リンクの品質を監視する、前述の実施形態のいずれかにおける方法。
【０２８７】
９１．直接パス無線リンクの劣化があった場合に測定イベントがトリガされる、前述の実施形態のいずれかにおける方法。
【０２８８】
９２．測定イベントのトリガによりＲＲＣ測定報告がｅＮＢに送信される、前述の実施形態のいずれかにおける方法。
【０２８９】
９３．ｅＮＢは、通信を第１のインフラストラクチャパスに切り替えることを決定してハンドオーバを開始する、前述の実施形態のいずれかにおける方法。
【０２９０】
９４．ｅＮＢは、ＲＲＣ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージをＷＴＲＵに送信する、前述の実施形態のいずれかにおける方法。
【０２９１】
９５．新たなＤＲＢが再構成の一部として生み出される、前述の実施形態のいずれかにおける方法。
【０２９２】
９６．新たなＤＲＢは、既存のインフラストラクチャパスＤＲＢに利用可能なセキュリティ鍵を使用する、前述の実施形態のいずれかにおける方法。
【０２９３】
９７．ＷＴＲＵ１およびＷＴＲＵ２は、直接パスを介してＰＤＣＰステータスＰＤＵを交換する、前述の実施形態のいずれかにおける方法。
【０２９４】
９８．ＷＴＲＵは、適切なキュー位置からインフラストラクチャを介して送信を継続してデータ損失を回避する、前述の実施形態のいずれかにおける方法。
【０２９５】
９９．パス切替えは、新たなＤＲＢに対応するＥＰＳベアラにＳ１コンポーネントおよびＳ５コンポーネントを追加することによってコアネットワークに反映される、前述の実施形態のいずれかにおける方法。
【０２９６】
１００．ＷＴＲＵが直接パス通信のみに携わるとき、対応するＥＰＳベアラ要素がＳＧＷ中にもＰＧＷ中にもない、前述の実施形態のいずれかにおける方法。
【０２９７】
１０１．修正された専用ベアラアクティブ化プロシージャを使用してこれらのＥＰＳベアラ要素がセットアップされる、前述の実施形態のいずれかにおける方法。
【０２９８】
１０２．別のＲＡＴのＷＴＲＵ接続が、ＷＴＲＵのＬＴＥ接続と同じＩＰアドレスを共有する、前述の実施形態のいずれかにおける方法。
【０２９９】
１０３．別のＲＡＴに対する逸脱が、直接パスについてのＭＡＣおよびＰＨＹのＲＲＣ構成を含む、前述の実施形態のいずれかにおける方法。
【０３００】
１０４．別のＲＡＴのＭＡＣおよびＰＨＹの最上部でＩＰが直接に使用される、前述の実施形態のいずれかにおける方法。
【０３０１】
１０５．別のＲＡＴのプロトコルがＬＴＥプロトコルスタックから分離される、前述の実施形態のいずれかにおける方法。
【０３０２】
１０６．ｅＮＢのＲＲＣエンティティは直接パス通信を制御しない、前述の実施形態のいずれかにおける方法。
【０３０３】
１０７．ＷＴＲＵの別のＲＡＴの接続は、ＬＴＥ接続とは異なるＩＰアドレスを有する、前述の実施形態のいずれかにおける方法。
【０３０４】
１０８．ＷＴＲＵの別のＲＡＴの接続は、ＬＴＥ接続と同じＩＰアドレスを有する、前述の実施形態のいずれかにおける方法。
【０３０５】
１０９．インフラストラクチャパスまたは直接パスを介したトラフィックのフローは、論理インタフェース（ＬＩＦ）の構成に支配される、前述の実施形態のいずれかにおける方法。
【０３０６】
１１０．ＬＩＦは、物理レイヤインタフェースとＩＰレイヤとを相互から隠すインタフェースである、前述の実施形態のいずれかにおける方法。
【０３０７】
１１１．ＬＩＦはＩＰモビリティフローのコンテキストで使用される、前述の実施形態のいずれかにおける方法。
【０３０８】
１１２．ＷＴＲＵ１は、ＬＴＥ中または別のＲＡＴ中でＷＴＲＵ２を発見する、前述の実施形態のいずれかにおける方法。
【０３０９】
１１３．ＬＴＥ発見の後に、ネットワークによってトリガされる別のＲＡＴの発見が続く、前述の実施形態のいずれかにおける方法。
【０３１０】
１１４．別のＲＡＴの識別がＤ２Ｄサーバによって提供される、前述の実施形態のいずれかにおける方法。
【０３１１】
１１５．別のＲＡＴは、ＬＴＥ発見に基づいてネットワークによってアクティブ化される、前述の実施形態のいずれかにおける方法。
【０３１２】
１１６．ＷＴＲＵ１は、別のＲＡＴのチャネル品質を含む測定報告を送信する、前述の実施形態のいずれかにおける方法。
【０３１３】
１１７．ｅＮＢは、通信を直接パスに移行させることを決定する、前述の実施形態のいずれかにおける方法。
【０３１４】
１１８．直接パスの構成は、適切な論理インタフェースを提供することからなる、前述の実施形態のいずれかにおける方法。
【０３１５】
１１９．ＷＴＲＵ中のアプリケーションから到着したさらに他のＩＰパケットが、別のＲＡＴのプロトコルスタックによって処理され、直接パスを介して送信される、前述の実施形態のいずれかにおける方法。
【０３１６】
１２０．当該インフラストラクチャパスＤＲＢおよびＥＰＳベアラ要素は削除される、前述の実施形態のいずれかにおける方法。
【０３１７】
１２１．ローカルパスにハンドオーバする決定が行われる、前述の実施形態のいずれかにおける方法。
【０３１８】
１２２．ハンドオーバする決定が行われたとき、ｅＮＢ１は、ローカルパスをセットアップするようＸ２インタフェースを介してｅＮＢ２に要求する、前述の実施形態のいずれかにおける方法。
【０３１９】
１２３．ｅＮＢ２は、応答を受信した後、ＳＧＷへのパケットの転送を停止し、ＧＴＰ−Ｕトンネルを介してエンドマーカを送信する、前述の実施形態のいずれかにおける方法。
【０３２０】
１２４．エンドマーカはｅＮＢ２に到達する、前述の実施形態のいずれかにおける方法。
【０３２１】
１２５．ｅＮＢ２は、ローカルパス開始メッセージの形で、Ｘ２インタフェースを介してｅＮＢ１に肯定応答を送信する、前述の実施形態のいずれかにおける方法。
【０３２２】
１２６．ソースｅＮＢがユーザパケットをＩＰレイヤで終端してローカルパスルートを介してこれらをターゲットｅＮＢに転送した場合に、ローカルパス通信が開始する、前述の実施形態のいずれかにおける方法。
【０３２３】
１２７．ｅＮＢは、ユーザデータプロトコルスタックをＩＰレイヤよりも下で終端する、前述の実施形態のいずれかにおける方法。
【０３２４】
１２８．ＷＴＲＵとｅＮＢとの間のＰＤＣＰおよびＲＬＣ送信は、ＭＡＣレイヤで中継としての役割を果たす、前述の実施形態のいずれかにおける方法。
【０３２５】
１２９．当該ＤＲＢに対応するＥＰＳベアラについてのＳ１およびＳ５リンクは削除される、前述の実施形態のいずれかにおける方法。
【０３２６】
１３０．パス切替えオプションは、データ転送のためのＸ２パイプを作成するオプションで置き換えられる、前述の実施形態のいずれかにおける方法。
【０３２７】
１３１．ＷＴＲＵは、ＬＴＥおよび非ＬＴＥ  ＲＡＴ直接パスをサポートする、前述の実施形態のいずれかにおける方法。
【０３２８】
１３２．ネットワークは、全てのＲＡＴにおけるデバイス識別子、およびそれらの間のマッピングを管理する、前述の実施形態のいずれかにおける方法。
【０３２９】
１３３．ＷＴＲＵは、全ての直接パスにおける発見および測定を実施する、前述の実施形態のいずれかにおける方法。
【０３３０】
１３４．ハンドオーバ決定の基礎として使用するための発見報告がｅＮＢに提供される、前述の実施形態のいずれかにおける方法。
【０３３１】
１３５．無線ベアラ再構成プロシージャはＲＲＣ接続再構成である、前述の実施形態のいずれかにおける方法。
【０３３２】
１３６．再構成は、ＬＩＦの再構成、無線ベアラ削除、ならびにＥＰＲベアラ追加および削除を含む、前述の実施形態のいずれかにおける方法。
【０３３３】
１３７．ＷＴＲＵ２がｅＮＢ３に近づいたときにモビリティイベントが発生し、ハンドオーバがインフラストラクチャパスに対してトリガされる、前述の実施形態のいずれかにおける方法。
【０３３４】
１３８．ＷＴＲＵは、それらの直接パス接続を閉じ、ハンドオーバ完了後にそれを再確立する、前述の実施形態のいずれかにおける方法。
【０３３５】
１３９．ｅＮＢ２は、Ｘ２インタフェースを介してｅＮＢ３にＤ２Ｄハンドオーバ要求を送信する、前述の実施形態のいずれかにおける方法。
【０３３６】
１４０．Ｄ２Ｄハンドオーバ要求は、直接パスの現在の構成、ならびにＷＴＲＵ１およびｅＮＢ１の識別を含む、前述の実施形態のいずれかにおける方法。
【０３３７】
１４１．構成は、複数の識別のうちの少なくとも１つを含む、前述の実施形態のいずれかにおける方法。
【０３３８】
１４２．ｅＮＢ３が、ＷＴＲＵの能力およびＤ２ＤポリシをＤ２Ｄサーバと共に検証する、前述の実施形態のいずれかにおける方法。
【０３３９】
１４３．ハンドオーバ完了後、ｅＮＢ３は、Ｘ２インタフェースを介してｅＮＢ１に接触してＤ２Ｄ構成を交渉する、前述の実施形態のいずれかにおける方法。
【０３４０】
１４４．結果的な構成は、ｅＮＢ１とｅＮＢ３との間の関係に依存する、前述の実施形態のいずれかにおける方法。
【０３４１】
１４５．ｅＮＢ１およびｅＮＢ３は、ＲＲＣ  ＲｅｃｏｎｆｉｇｕｒａｔｉｏｎをＷＴＲＵ１およびＷＴＲＵ２にそれぞれ送信して直接パスを再構成する、前述の実施形態のいずれかにおける方法。
【０３４２】
１４６．ＷＴＲＵは、Ｄ２Ｄセッションに使用されるパスを再構成するかまたはＷＴＲＵのＲＲＣ接続のモビリティを示す制御シグナリングをネットワークから受信した後、インフラストラクチャパスに戻るＤ２Ｄセッションの再確立を開始する、前述の実施形態のいずれかにおける方法。
【０３４３】
１４７．ＷＴＲＵは、そのハンドオーバステータスをＤ２Ｄセッションの中の他のＷＴＲＵに知らせる、前述の実施形態のいずれかにおける方法。
【０３４４】
１４８．ｅＮＢは、他のＷＴＲＵのハンドオーバステータスをＤ２Ｄセッションの中の他のＷＴＲＵに知らせる、前述の実施形態のいずれかにおける方法。
【０３４５】
１４９．ＷＴＲＵは、モビリティプロシージャに関連するＤ２Ｄリンクについてのデータおよび／または制御シグナリングの送受信をサスペンドする、前述の実施形態のいずれかにおける方法。
【０３４６】
１５０．ＷＴＲＵは、その構成役割をマスタからスレーブに切り替える、前述の実施形態のいずれかにおける方法。
【０３４７】
１５１．ＷＴＲＵは、その構成役割をマスタに切り替える、前述の実施形態のいずれかにおける方法。
【０３４８】
１５２．ＷＴＲＵは、ハンドオーバ準備およびセッションサスペンドメッセージを別のＷＴＲＵから受信する、前述の実施形態のいずれかにおける方法。
【０３４９】
１５３．ＷＴＲＵは、発見検出プロセスをトリガするシグナリングを受信する、前述の実施形態のいずれかにおける方法。
【０３５０】
１５４．ＷＴＲＵは、近接検出プロセスをトリガするシグナリングを受信する、前述の実施形態のいずれかにおける方法。
【０３５１】
１５５．新たな直接パスが異なる周波数帯域にある場合、ＷＴＲＵは、その周波数に同調し、ＰＨＹハンドシェイクプロセスを経て新たな帯域における直接パス関連付けを再確認する、前述の実施形態のいずれかにおける方法。
【０３５２】
１５６．ＷＴＲＵは、ＰＤＣＰステータスを交換して適切なキュー位置で通信を継続する、前述の実施形態のいずれかにおける方法。
【０３５３】
１５７．ＷＴＲＵは、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージを送信する、前述の実施形態のいずれかにおける方法。
【０３５４】
１５８．ＷＴＲＵは、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｃｏｍｐｌｅｔｅメッセージの受信および送信に続いて送受信を再開する、前述の実施形態のいずれかにおける方法。
【０３５５】
１５９．ＷＴＲＵは、発見されたサービスおよびＷＴＲＵに関するそのリストをリセットする、前述の実施形態のいずれかにおける方法。
【０３５６】
１６０．ＷＴＲＵは、別のセルからの発見されたサービスおよびＷＴＲＵのリストを維持する、前述の実施形態のいずれかにおける方法。
【０３５７】
１６１．ＷＴＲＵは、直接パスについてのタイミング情報を更新する、前述の実施形態のいずれかにおける方法。
【０３５８】
１６２．ＷＴＲＵは、直接パスについての送信電力情報を得る、前述の実施形態のいずれかにおける方法。
【０３５９】
１６３．ＷＴＲＵは、送信またはＤ２Ｄセッションのためのデータの量を含むバッファステータス報告（ＢＳＲ）を送信する、前述の実施形態のいずれかにおける方法。
【０３６０】
１６４．ＷＴＲＵは、マルチキャストトラフィックを再同期させるための基礎として使用する、データフローに関連するＣＯＵＮＴ値を取得する、前述の実施形態のいずれかにおける方法。
【０３６１】
１６５．ＷＴＲＵは、ＣＯＵＮＴ値を別のＷＴＲＵに送信する、前述の実施形態のいずれかにおける方法。
【０３６２】
１６６．ＷＴＲＵは、セル再選択プロシージャを実施する、前述の実施形態のいずれかにおける方法。
【０３６３】
１６７．ＷＴＲＵは、Ｄ２Ｄセッションを維持する可能性に基づいてセルを選択する、前述の実施形態のいずれかにおける方法。
【０３６４】
１６８．ＷＴＲＵは、選択されたセル上でＤ２Ｄセッションが有効かどうか判定する、前述の実施形態のいずれかにおける方法。
【０３６５】
１６９．ＷＴＲＵは、異なるＤ２Ｄリンクが使用可能なように、Ｄ２Ｄセッションに関係するパラメータを取得する、前述の実施形態のいずれかにおける方法。
【０３６６】
１７０．ＷＴＲＵおよびネットワークは、無線リンクを測定および監視する、前述の実施形態のいずれかにおける方法。
【０３６７】
１７１．ＷＴＲＵおよびネットワークは、リンクの突然の劣化によって発生する障害を管理する、前述の実施形態のいずれかにおける方法。
【０３６８】
１７２．直接パス無線リンク障害（ＲＬＦ）がＤ２Ｄにおいて発生する、前述の実施形態のいずれかにおける方法。
【０３６９】
１７３．直接リンク障害（ＤＬＦ）がＤ２Ｄにおいて発生する、前述の実施形態のいずれかにおける方法。
【０３７０】
１７４．ＷＴＲＵ１は、直接パス上の全ての通信をすぐに中止する、前述の実施形態のいずれかにおける方法。
【０３７１】
１７５．ＷＴＲＵ２は、ＷＴＲＵ１が直接パス上の全ての通信を中止するのに基づいて、直接リンク障害を検出する、前述の実施形態のいずれかにおける方法。
【０３７２】
１７６．ＷＴＲＵ１は、通信を中止する前に、ＲＬＦを示すメッセージを直接パス上でＷＴＲＵ２に送信する、前述の実施形態のいずれかにおける方法。
【０３７３】
１７７．ＷＴＲＵ１は、ｅＮＢ１からの現在のグラントが許可する限り、直接パス送信を継続する、前述の実施形態のいずれかにおける方法。
【０３７４】
１７８．ＷＴＲＵ１は、ＶａｒＲＬＦＲｅｐｏｒｔの一部として、最後の直接パス測定値、およびＷＴＲＵ２の物理識別を記憶する、前述の実施形態のいずれかにおける方法。
【０３７５】
１７９．ＷＴＲＵ１は、接続が再確立されるとＶａｒＲＬＦＲｅｐｏｒｔをＷＴＲＵ２に送信する、前述の実施形態のいずれかにおける方法。
【０３７６】
１８０．ＷＴＲＵ１は、ベースラインＲＬＦ処理の一部として、適切なセルを短期間で見つけることができる場合に接続再確立プロシージャを経る、前述の実施形態のいずれかにおける方法。
【０３７７】
１８１．再確立の一部として、ＷＴＲＵ１は、ＷＴＲＵ１の前の物理セルＩＤを新たなｅＮＢに提供する、前述の実施形態のいずれかにおける方法。
【０３７８】
１８２．Ｄ２Ｄ呼が進行中であったことをｅＮＢ２に知らせる追加のフィールドがＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔ要求に挿入される、前述の実施形態のいずれかにおける方法。
【０３７９】
１８３．ｅＮＢ２は、Ｘ２インタフェースを介してｅＮＢ１に照会して前のＤ２Ｄ構成を得ることが可能にされる、前述の実施形態のいずれかにおける方法。
【０３８０】
１８４．ｅＮＢ２は、新たなＤ２Ｄ構成をｅＮＢ１と交渉する、前述の実施形態のいずれかにおける方法。
【０３８１】
１８５．新たなＤ２Ｄ構成は、ＲＲＣ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｒｅｅｓｔａｂｌｉｓｈｍｅｎｔメッセージの一部としてＷＴＲＵ１に提供される、前述の実施形態のいずれかにおける方法。
【０３８２】
１８６．ＷＴＲＵは、ＤＬＦを決定し、直接パス上の送信をサスペンドする、前述の実施形態のいずれかにおける方法。
【０３８３】
１８７．ＲＲＣアイドルモードのＷＴＲＵは、インフラストラクチャパスを介したサービス継続性のためにＲＲＣ接続確立を開始する、前述の実施形態のいずれかにおける方法。
【０３８４】
１８８．ＤＬＦは、アップリンクおよびダウンリンクで別々に決定される、前述の実施形態のいずれかにおける方法。
【０３８５】
１８９．Ｄ２Ｄ呼が継続する、前述の実施形態のいずれかにおける方法。
【０３８６】
１９０．ＤＬＦは、直接パスについての構成可能な数の連続した非同期指示である、前述の実施形態のいずれかにおける方法。
【０３８７】
１９１．ＤＬＦは、ＲＬＣ再送失敗である、前述の実施形態のいずれかにおける方法。
【０３８８】
１９２．ＤＬＦは、ＷＴＲＵによってｅＮＢに対して示される、前述の実施形態のいずれかにおける方法。
【０３８９】
１９３．ｅＮＢ間のケースで、Ｘ２インタフェースを介してｅＮＢ間で協調が必要とされる、前述の実施形態のいずれかにおける方法。
【０３９０】
１９４．ＷＴＲＵは、インフラストラクチャパスを介してｅＮＢにＰＤＣＰステータスを報告する、前述の実施形態のいずれかにおける方法。
【０３９１】
１９５．ＷＴＲＵは、直接パスリンクに関連する以下のイベント、すなわち、ＲＬＣ障害、ＨＡＲＱ障害、直接パス上のピアからの障害指示、発見検出の不成功、近接検出の不成功、無効なセッションパラメータ、無効なセキュリティ状態、ＲＲＣ接続状態遷移、アクセス不可能なセル、無効なアップリンクタイミング同期、のうちの少なくとも１つに基づいて、ＤＬＦを決定する、前述の実施形態のいずれかにおける方法。
【０３９２】
１９６．ＷＴＲＵは、セッション特有のセキュリティ構成を受信する、前述の実施形態のいずれかにおける方法。
【０３９３】
１９７．ＷＴＲＵは、Ｄ２Ｄセッションの受信側になることが可能にされるように、確立されたインフラストラクチャリンクを介してそのセキュリティパラメータを提供する、前述の実施形態のいずれかにおける方法。
【０３９４】
１９８．ＷＴＲＵは、セキュリティパラメータを使用してＤ２Ｄセッションについてのデータを生成する、前述の実施形態のいずれかにおける方法。
【０３９５】
１９９．ＷＴＲＵは、ＮＡＳレベルのＫＡＳＭＥ（アクセスセキュリティ管理エンティティ）、ＡＳレベルのＫｅＮＢ、ＰｒｏＳｅサーバによって生成されるＫＰｒｏＳｅ（例えばサービスに関連する鍵）、またはネットワークによって生成されるＫＤｉｒｅｃｔＰａｔｈ（例えばＤ２ＤリンクまたはＤ２Ｄ接続に関連する鍵）、のうちの１つからセキュリティ鍵を導出する、前述の実施形態のいずれかにおける方法。
【０３９６】
２００．鍵の有効性は地理エリアに関連する、前述の実施形態のいずれかにおける方法。
【０３９７】
２０１．ＷＴＲＵは、ＷＴＲＵがセキュリティコンテキストから取り出されたアルゴリズムおよび鍵を使用して認証を検証するＤ２Ｄリンク上でデータを受信したときに、最初にセキュリティをアクティブ化する、前述の実施形態のいずれかにおける方法。
【０３９８】
２０２．ＰＤＣＰはセキュリティ機能を実施する、前述の実施形態のいずれかにおける方法。
【０３９９】
２０３．ＷＴＲＵは、セキュリティアクティブ化失敗の後で再確立プロシージャを開始する、前述の実施形態のいずれかにおける方法。
【０４００】
２０４．ＷＴＲＵは、ＤＬＦを決定したとき、ハンドオーバが失敗したと決定したとき、ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｃｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信したとき、のうちの少なくとも１つで、Ｄ２Ｄセッションが終了しつつあると決定する、前述の実施形態のいずれかにおける方法。
【０４０１】
２０５．ＷＴＲＵは測定構成で構成される、前述の実施形態のいずれかにおける方法。
【０４０２】
２０６．測定構成は追加の情報要素（ＩＥ）を含む、前述の実施形態のいずれかにおける方法。
【０４０３】
２０７．既存のＭｅａｓＲｅｓｕｌｔｓ情報要素（ＩＥ）にＭｅａｓＲｅｓｕｌｔｓＤ２Ｄが追加される、前述の実施形態のいずれかにおける方法。
【０４０４】
２０８．既存のＲｅｐｏｒｔＣｏｎｆｉｇＥＵＴＲＡ  ＩＥにＲｅｐｏｒｔＣｏｎｆｉｇＤ２Ｄが追加される、前述の実施形態のいずれかにおける方法。
【０４０５】
２０９．ＷＴＲＵにおいてＤ２Ｄ周波数で検出される干渉レベルが、Ｄ２Ｄ測定の報告をトリガするための基準である、前述の実施形態のいずれかにおける方法。
【０４０６】
２１０．干渉レベルは、送達可能データ容量を示す、前述の実施形態のいずれかにおける方法。
【０４０７】
２１１．ＷＴＲＵの現在のモビリティ速度が、Ｄ２Ｄ測定の報告をトリガするための基準である、前述の実施形態のいずれかにおける方法。
【０４０８】
２１２．ＷＴＲＵが高速モビリティにあるとき、ＷＴＲＵはＤ２Ｄリンクの切替えを控える、前述の実施形態のいずれかにおける方法。
【０４０９】
２１３．ＷＴＲＵは近接検出構成を有する、前述の実施形態のいずれかにおける方法。
【０４１０】
２１４．ＷＴＲＵは、ＷＴＲＵおよびサービスに関連する検出オブジェクトの、索引付けされたリストを有する、前述の実施形態のいずれかにおける方法。
【０４１１】
２１５．ＷＴＲＵは、検出構成を受信したときに検出報告をトリガする、前述の実施形態のいずれかにおける方法。
【０４１２】
２１６．検出構成は、近接検出オブジェクト、近接報告構成、近接検出識別、近接測定ギャップ構成を含む、前述の実施形態のいずれかにおける方法。
【０４１３】
２１７．ＷＴＲＵは、ＷＴＲＵの構成のＳＲＢを介してＲＲＣ  ＳＤＵの送信を開始する、前述の実施形態のいずれかにおける方法。
【０４１４】
２１８．ネットワークは、直接パスを構成することによって検出報告に応答する、前述の実施形態のいずれかにおける方法。
【０４１５】
２１９．ＷＴＲＵは、トリガのために測定と共に近接検出を考慮する、前述の実施形態のいずれかにおける方法。
【０４１６】
２２０．ＷＴＲＵは、直接パスのための条件が十分であるときにインバウンドモビリティトリガを受け取る、前述の実施形態のいずれかにおける方法。
【０４１７】
２２１．ＷＴＲＵは、直接パスのための条件が不十分であるときにアウトバウンドモビリティトリガを送る、前述の実施形態のいずれかにおける方法。
【０４１８】
２２２．受信機と、
送信機と、
受信機および送信機と通信するプロセッサとを備える、前述の実施形態のいずれかにおける方法を実施するように構成されたＷＴＲＵ。
【０４１９】
２２３．実施形態１乃至２２１のいずれかにおける方法を実施するように構成された基地局。
【０４２０】
２２４．実施形態１乃至２２１のいずれかにおける方法を実施するように構成された集積回路。
【０４２１】
２２５．実施形態１乃至２２１のいずれかにおける方法を実施するように構成されたアクセスポイント（ＡＰ）。
【０４２２】
２２６．実施形態１乃至２２１のいずれかにおける方法を実施するように構成されたネットワーク。
【０４２３】
２２７．第１の進化型ＮｏｄｅＢ（ｅＮＢ）におけるデバイス間（Ｄ２Ｄ）通信のためのモビリティの方法であって、
無線リソース制御（ＲＲＣ）測定報告を第１の無線送信／受信ユニット（ＷＴＲＵ）から受信すること、
第２のＷＴＲＵの能力の要求をＤ２Ｄサーバに送信すること、
第２のＷＴＲＵの能力の応答をＤ２Ｄサーバから受信すること、
Ｄ２Ｄ構成要求を第２のｅＮＢに送信すること、
Ｄ２Ｄ構成応答を第２のｅＮＢから受信すること、
直接パス開始メッセージを第２のｅＮＢに送信すること、および
パス切替え要求をモビリティ管理エンティティ（ＭＭＥ）に送信することを含む方法。
【０４２４】
以上では特徴および要素が特定の組合せで説明されているが、各特徴または要素は、単独で、または他の特徴および要素との任意の組合せで使用されてもよいことを、当業者なら理解するであろう。加えて、本明細書で説明された方法は、コンピュータまたはプロセッサによって実行されるようにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実行されてもよい。コンピュータ可読媒体の例は、電子信号（有線または無線接続を介して伝送される）、およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、光学磁気媒体、ならびに、ＣＤ−ＲＯＭディスクおよびディジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、これらに限定されない。プロセッサがソフトウェアと共に使用されて、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータ中で使用される無線周波数送受信機が実現されてよい。
【図１Ａ】
0006568978.tif 000002
【図１Ｂ】
0006568978.tif 000003
【図１Ｃ】
0006568978.tif 000004
【図２】
0006568978.tif 000005
【図３】
0006568978.tif 000006
【図４】
0006568978.tif 000007
【図５Ａ】
0006568978.tif 000008
【図５Ｂ】
0006568978.tif 000009
【図６Ａ】
0006568978.tif 000010
【図６Ｂ】
0006568978.tif 000011
【図７】
0006568978.tif 000012
【図８】
0006568978.tif 000013
【図９】
0006568978.tif 000014
【図１０】
0006568978.tif 000015
【図１１Ａ】
0006568978.tif 000016
【図１１Ａ１】
0006568978.tif 000017
【図１１Ｂ】
0006568978.tif 000018
【図１１Ｃ】
0006568978.tif 000019
【図１２】
0006568978.tif 000020
【図１３Ａ】
0006568978.tif 000021
【図１３Ｂ】
0006568978.tif 000022
【図１３Ｃ】
0006568978.tif 000023
【図１４Ａ】
0006568978.tif 000024
【図１４Ｂ】
0006568978.tif 000025
【図１５】
0006568978.tif 000026
【図１６】
0006568978.tif 000027
【図１７Ａ】
0006568978.tif 000028
【図１７Ｂ】
0006568978.tif 000029