JP2014512762A - ローカル／リモートｉｐトラフィックアクセスおよび選択的ｉｐトラフィックオフロードサービス継続性 - Google Patents

Abstract

本明細書では、限定加入者グループ（ＣＳＧ）ベースのローカル／リモートＩＰトラフィックオフロードおよび選択的ＩＰトラフィックオフロードを処理するシステムおよび方法が開示される。一態様によれば、方法が、ユーザ機器（ＵＥ）で実行されてもよい。この方法は、ＵＥへのサービスが所定のサービス品質（ＱｏＳ）を要求することを判定することを含んでもよい。この方法はまた、ＵＥへのサービスが所定のＱｏＳを要求することの判定に応答して、複数のゲートウェイの中からゲートウェイを選択することを含んでもよい。

Description

本発明は、無線通信に関する。

本願は、２０１１年４月１日に出願された米国仮特許出願第６１／４７１，００２号（Ａｔｔｏｒｎｅｙ Ｒｅｆ Ｎｏ．１０９８０）、２０１１年４月４日に出願された米国仮特許出願第６１／４７１，６２１号（Ａｔｔｏｒｎｅｙ Ｒｅｆ Ｎｏ．１０９８７）、２０１１年５月６日に出願された米国仮特許出願第６１／４８３，４９４号（Ａｔｔｏｒｎｅｙ Ｒｅｆ Ｎｏ．１１０４３）、および２０１１年１０月７日に出願された米国仮特許出願第６１／５４４，９１１号（Ａｔｔｏｒｎｅｙ Ｒｅｆ Ｎｏ．１１１８１）の利益を主張するものであり、それらの出願は、参照によって本明細書に完全に示されるように組み込まれる。

ローカルゲートウェイ（ＬＧＷ）およびホーム発展型ＮｏｄｅＢ（Ｈ（ｅ）ＮＢ）は、一般に、ネットワークにおける同一ノード内に、同一位置に配置されてきた。スタンドアロン（standalone）ＬＧＷの導入は、ローカルネットワークにおいてローカルＩＰアクセス（ＬＩＰ Ａ）および選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ：Selective IP Traffic Offload）に対するモビリティを可能にすることがある。しかし、Ｈ（ｅ）ＮＢとＬＧＷとの間の接続は、ＬＧＷおよびＨ（ｅ）ＮＢが、必ずしも互いのＩＰアドレスを知っていないため、もはや些細な問題ではない。したがって、システムが構築されており、および、新たなノードの電源が入れられる時に、これらのＬＧＷおよびＨ（ｅ）ＮＢが互いを発見するための手段が存在しなければならない。

加えて、加入者は、自らが要求するサービスの特定の要件に適したＩＰトラフィックオフロードポイントを利用することを望むことがある。システムが提供する現在の粒度は、ＡＰＮごとをベースとしている。このことは、同一のＡＰＮを使用してＳＩＰＴＯ固有の区別されたサービス能力を提供することを許可しない。さらに、ＡＰＮベースのＳＩＰＴＯアソシエーション（association）は、ＳＩＰＴＯ（またはＬＩＰ Ａ）サービスに対するユーザベースのプリファレンス構成（preference configuration）、ロケーションアウェアネス（awareness）アソシエーション、動的／オンザフライ（on-the-fly）または静的な課金制度主導のＳＩＰＴＯサービス選択（billing regime driven SIPTO service selection）を許可しない。さらに、現在のシステムは、ＳＩＰＴＯまたはＬＩＰＡを使用するシームレスモビリティを許可しない。

本明細書で開示されるのは、限定加入者グループ（ＣＳＧ）ベースのローカル／リモートＩＰトラフィックオフロードおよび選択的ＩＰトラフィックオフロードを処理するためのシステムおよび方法である。実施形態は、たとえば、加入者が、自ら要求するサービスの特定の要件に適したＩＰトラフィックオフロードポイントを使用することを可能にするために使用されてもよい。加えて、実施形態は、同一のＡＰＮを使用してＳＩＰＴＯ固有の識別されたサービス能力を提供することを可能にし、および、ＳＩＰＴＯ（またはＬＩＰ Ａ）サービスに対するユーザベースのプリファレンス構成、ロケーションアウェアネスアソシエーション、動的／オンザフライまたは静的な課金制度主導のＳＩＰＴＯサービス選択を許可することができる。さらに、実施形態は、ＳＩＰＴＯまたはＬＩＰＡを使用したシームレスモビリティを提供する。

一態様にしたがって、ハンドオーバに対するターゲットＨｅＮＢを選択する方法が使用されてもよい。無線送信／受信ユニット（ＷＴＲＵ）との接続が確立されてもよい。接続は、セッションであってもよく、セッションは、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）セッションまたはローカルＩＰアクセス（ＬＩＰ Ａ）セッションのいずれかを備えてもよい。ターゲットＨｅＮＢは、セッションをサポートするためのターゲットＨｅＮＢの能力に基づいてハンドオーバに対して選択されてもよい。セッションは、ターゲットＨｅＮＢにハンドオーバされてもよい。

別の態様にしたがって、ＷＴＲＵは、ＬＧＷがＳＩＰＴＯとＬＩＰＡとを識別することを可能にしてもよい。１つまたは複数のアクティブインターフェースにまたがってＵＩＰトラフィックをルーティングするためのルールのセットを提供することができる、インター（inter）アクセスポイントネーム（ＡＰＮ：access point name）のルーティングポリシー（ＩＡＲＰ）が受信されてもよい。好ましいＡＰＮは、ＩＡＲＰからのＡＰＮの優先付けされたリストを使用して判定されてもよい。ＩＰインターフェースが選択されて、好ましいＡＰＮに基づいてＩＰフローをルーティングしてもよい。ＩＰフローは、選択されたＩＰインターフェースを使用して送信されてもよい。

別の態様にしたがって、ハンドオーバを提供する方法が使用されてもよい。ＨｅＮＢは、ハンドオーバインジケーションを受信してもよい。セッションをサポートすることができるＷＴＲＵへの接続が確立されるかの判定がされてもよい。セッションは、ＳＩＰＴＯセッションまたはＬＩＰＡセッションのいずれかを備えてもよい。ＷＴＲＵとの接続が確立されてもよい。セッションハンドオーバが受信されてもよい。

一態様にしたがって、方法がユーザ機器（ＵＥ）において実施されてもよい。当該方法は、ＵＥへのサービスが、所定のサービス品質（ＱｏＳ）を要求するかを判定することを含んでもよい。当該方法はまた、ＵＥへのサービスが所定のＱｏＳを要求することを判定することに応答して、複数のゲートウェイの中からゲートウェイを選択することを含んでもよい。

別の態様にしたがって、一方法がＵＥにおいて実施されてもよい。当該方法は、限定加入者グループ識別子（ＣＳＧ ＩＤ）のユーザ選択を受信することを含んでもよい。当該方法はまた、ユーザ選択の受信に応答して、ＣＳＧ ＩＤに関連付けられたゲートウェイへのトラフィックオフロードを実施することを含んでもよい。

加えて、本明細書で開示されるのは、ＬＩＰ ＡおよびＳＩＰＴＯに対するモビリティおよびサービス継続性を提供するためのシステムおよび方法である。実施形態は、ホームＮｏｄｅＢ（ＨＮＢ）または発展型ＵＴＲＡＮホームＮｏｄｅＢ（ＨｅＮＢ）サブシステムに適用可能であってもよい。したがって、本明細書では、用語ＨＮＢが、ＨｅＮＢまたはＨ（ｅ）ＮＢと交換可能に使用されてもよい。実施形態は、Ｓ１インターフェースまたはＸ２インターフェースを介してＨＯを提供してもよい。

この「発明の概要」は、以下の「発明を実施するための形態」でさらに説明される概念の選択を単純化された形式で紹介するために提供されるものである。この「発明の概要」は、特許請求される主題の主要な特徴または本質的特徴を識別することを意図されたものではなく、特許請求される主題の範囲を限定するのに使用されることも意図されていない。さらに、特許請求される主題は、本開示のいずれかの部分に示された任意のまたはすべてのデメリットを解決するいずれの限定にも限定されない。

より詳細な理解が、添付図面に関連して例として与えられる、以下の説明から得られる。
１つまたは複数の開示される実施形態を実装することができる通信システムを示すシステム図である。 図１Ａに示される通信システム内で使用することができる無線送信／受信ユニット（ＷＴＲＵ）を示すシステム図である。 図１Ａに示される通信システム内で使用することができる無線アクセスネットワークおよびコアネットワークを示すシステム図である。 図１Ａに示される通信システム内で使用することができる無線アクセスネットワークおよび別のコアネットワークを示すシステム図である。 図１Ａに示される通信システム内で使用することができる無線アクセスネットワークおよび別のコアネットワークを示すシステム図である。 限定加入者グループ（ＣＳＧ）ベースのローカルＩＰアクセス（ＬＩＰ Ａ）、リモートＩＰアクセス（ＲＩＰ Ａ）、および／または選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）を提供することができる通信ネットワークを示すブロック図である。 ローカルゲートウェイ（ＬＧＷ）アーキテクチャにおいてＳＩＰＴＯモビリティおよび／またはＬＩＰＡモビリティを提供することができる通信ネットワークを示すブロック図である。 ＬＧＷをＨ（ｅ）ＮＢと同一位置に配置することができる通信ネットワークを示すブロック図である。 ＬＧＷの使用を通じてローカルＩＰネットワークへのアクセスを提供することができる通信ネットワークを示すブロック図である。 ユーザ機器（ＵＥ）が、Ｈ（ｅ）ＮＢにハンドオフされながらＬＧＷヘの接続を維持することができる通信ネットワークを示すブロック図である。 ネットワークオペレータがパブリックデータネットワーク（ＰＤＮ）ゲートウェイ（ＧＷ）を選択してトラフィックをオフロードすることができる通信ネットワークを示すブロック図である。 ＬＧＷを使用してユーザデータをオフロードすることができる通信ネットワークを示すブロック図である。 ハンドオフ中にＬＧＷ配置に関してモビリティ管理エンティティ（ＭＭＥ）に通知するのに使用することができる方法を示す図である。 ハンドオフの後にソースＨ（ｅ）ＮＢとＬＧＷとの間でＬＩＰＡリソースおよび／またはＳＩＰＴＯリソースの解放を処理することができる通信ネットワークを示す図である。 ＬＧＷトラフィックにおいてＬＩＰＡおよび／またはＳＩＰＴＯに対してＵＥをページングすることができる通信ネットワークを示す図である。

本明細書で開示されるは、限定加入者グループ（ＣＳＧ）ベースのローカル／リモートＩＰトラフィックオフロードおよび選択的ＩＰトラフィックオフロードを処理するためのシステムおよび方法である。一態様にしたがって、方法がユーザ機器（ＵＥ）において実施されてもよい。当該方法は、ＵＥへのサービスが所定のサービス品質（ＱｏＳ）を要求することを判定することを含んでもよい。当該方法はまた、ＵＥへのサービスが所定のＱｏＳを要求することを判定することに応答して、複数のゲートウェイの中から１つのゲートウェイを選択することを含んでもよい。

３ＧＰＰロングタームエボリューション（ＬＴＥ）プログラムに対する現在の取り組みは、新たな技術、新たなアーキテクチャおよび新たな技法を新たなＬＴＥセッティングおよび構成にもたらして、改善されたスペクトル効率、軽減された待ち時間、および無線リソースのよりよい利用を提供し、より高速のユーザ経験、ならびに、より少ないコストでより豊かなアプリケーションおよびサービスをもたらすことである。

これらの取り組みの一部として、３ＧＰＰは、ＬＴＥにおいて（また、場合により他のセルラ標準規格で）ホームＮｏｄｅＢまたはホーム拡張ＮｏｄｅＢ（ＨｅＮＢ）の概念を導入してきた。ＨｅＮＢは、無線ローカルエリアネットワーク（ＷＬＡＮ）アクセスポイント（ＡＰ）と同等の物理デバイスを指してもよい。ＨｅＮＢは、ユーザに、家庭または小規模オフィスなどの小規模サービスエリア上でのＬＴＥサービスへのアクセスを提供してもよい。ＨｅＮＢは、たとえばパブリックインターネット接続を使用することによって、オペレータのコアネットワークに接続することを意図されてもよい。このことは、ＬＴＥが展開されていないことがあり、および／または、レガシ３ＧＰＰ無線アクセス技術（ＲＡＴ）カバレージが既に存在していることがあるエリアにおいて特に有用である場合がある。このことはまた、たとえば地下鉄またはショッピングモールにいる間に発生する、無線伝送問題に対して、ＬＴＥカバレージが弱く、または、存在しないことがあるエリアにおいて有用である場合がある。

セルは、ＨｅＮＢによって提供される無線カバレージが利用可能なエリアを指してもよい。ＨｅＮＢによって展開されるセルは、当該セルのサービスへのアクセスを有する加入者のグループ（たとえば、家族）によってのみアクセスされる場合があり、および、そのようなセルは、ＨｅＮＢセルまたはより一般的に限定加入者グループ（ＣＳＧ）セルと称されてもよい。ＨｅＮＢが使用されて、ＬＴＥカバレージが望まれるエリア上で１つまたは複数のＣＳＧセルを展開してもよい。用語ＣＳＧセルは、ＬＴＥサービスに対してＨｅＮＢによって展開されるセル、または、ＷＣＤＭＡ（登録商標）もしくは他のレガシ３ＧＰＰ ＲＡＴサービスに対してＨＮＢによって展開されるセルに使用されてもよい。

ＨｅＮＢは、ホームベースのネットワークに接続されたＩＰ対応デバイスへのアクセスを提供するために、ＣＳＧメンバに対して、無線送信／受信ユニット（ＷＴＲＵ）またはユーザ機器（ＵＥ）から公衆交換電話網（ＰＬＭＮ）を介してホームベースのネットワークへのリモートアクセスをサポートしてもよい。ホームベースのネットワークへのアクセスは、加入者ごとをベースに制限されてもよい。さらに、ＨＰＬＭＮは、特定のユーザに対する情報（１）ユーザのＩＰトラフィックが、移動先ネットワークにおける選択的ＩＰトラフィックオフロードにしたがうことになることを許可されるかのインジケーション、および、（２）選択的ＩＰトラフィックオフロードが許可される定義されたＩＰを、移動先ＰＬＭＮ（ＶＰＬＭＮ）に提供してもよい。ローカルネットワークにおけるローカルＩＰアクセス（ＬＩＰＡ）および選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）のアーキテクチャ的な態様は、ＵＥがアタッチされるＨｅＮＢとは別々のスタンドアロンローカルゲートウェイを使用するローカルネットワークに位置するＨｅＮＢの間のＬＩＰＡに対するモビリティのサポートを含んでもよい。

上記説明した機能の態様を考慮すると、ユーザはおそらく、ホームネットワークまたは移動先ネットワークのどちらにいるのかにかかわりなく、自らのローカルデバイスにアクセスしたいと思うであろう。加えて、ユーザは、正確なもしくは最適のオフロードポイントの正確な判定に要求されるＬＩＰＡパラメータもしくはＳＩＰＴＯパラメータを構成することができない場合があり、または、これらを構成しもしくは定義しようとしない場合がある。

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

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

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

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

基地局１１４ａおよび１１４ｂは、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄのうちの１つまたは複数と通信してもよく、エアインターフェース１１６は、任意の適切な無線通信リンク（たとえば、無線周波数（ＲＦ)、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってもよい。エアインターフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。

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

別の実施形態では、基地局１１４ａ、ならびに、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、発展型ＵＭＴＳ地上波無線アクセス（Ｅ-ＵＴＲＡ）などの無線技術を実装してもよく、Ｅ−ＵＴＲＡは、ロングタームエボリューション（ＬＴＥ）および／またはＬＴＥ−Ａｄｖａｎｃｅｄ（ＬＴＥ-Ａ）を使用してエアインターフェース１１６を確立してもよい。

他の実施形態では、基地局１１４ａ、ならびに、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ＥＶ−ＤＯ、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ２０００（ＩＳ-２０００）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ９５（ＩＳ-９５）、Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ８５６（ＩＳ-８５６）、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ：登録商標）、Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。

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

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

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

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄの一部またはすべては、マルチモード能力を含んでもよく、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃおよび１０２ｄは、異なる無線リンク上で異なる無線ネットワークと通信する複数の送受信機を含んでもよい。たとえば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラベース無線施術を採用することができる基地局１１４ａ、および、ＩＥＥＥ８０２無線技術を採用することができる基地局１１４ｂと通信するように構成されてもよい。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および他の周辺機器１３８を含んでもよい。ＷＴＲＵ１０２が、実施形態と一貫したままでありながら前述の要素の任意のサブコンビネーションを含んでもよいことを理解されたい。

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

送信／受信要素１２２は、エアインターフェース１１６上で基地局（たとえば、基地局１１４ａ）へ信号を送信しまたは当該基地局から信号を受信するように構成されてもよい。たとえば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信し、および／または、受信するように構成されたアンテナであってもよい。別の実施形態では、送信／受信要素１２２は、たとえばＩＲ、ＵＶ、もしくは可視光信号を送信し、および／または、受信するように構成されたエミッタ／ディテクタであってもよい。さらなる別の実施形態では、送信／受信要素１２２は、ＲＦ信号と光信号との両方を送信し、および、受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組合せを送信し、および／または、受信するように構成されてもよいことを理解されたい。

加えて、送信／受信要素１２２は、図１Ｂでは単一の要素として示されるが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでもよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を採用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインターフェース１１６上で無線信号を送信し、および、受信する複数の送信／受信要素１２２（たとえば、複数のアンテナ）を含んでもよい。

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

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

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

プロセッサ１１８はまた、ＧＰＳチップセット１３６に結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（たとえば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはその代わりに、ＷＴＲＵ１０２は、基地局（たとえば、基地局１１４ａ、１１４ｂ）からエアインターフェース１１６上で位置情報を受信してもよく、および／または、複数の近接の基地局から受信されている信号のタイミングに基づいて、その位置を判定してもよい。ＷＴＲＵ１０２が、実施形態と一貫したままで任意の適切な位置判定方法によって位置情報を獲得してもよいことを理解されたい。

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

図１Ｃは、一実施形態にしたがった、ＲＡＮ１０４およびコアネットワーク１０６ａのシステム図である。上述したように、ＲＡＮ１０４は、ＵＴＲＡ無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信してもよい。ＲＡＮ１０４はまた、コアネットワーク１０６ａと通信していてもよい。図１Ｃに示されるように、ＲＡＮ１０４は、ＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃを含んでもよく、このＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、それぞれ、エアインターフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと通信する１つまたは複数の送受信機を含んでもよい。ＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、それぞれ、ＲＡＮ１０４内の特定のセル（図示せず）に関連付けられてもよい。ＲＡＮ１０４はまた、ＲＮＣ１４２ａおよび１４２ｂを含んでもよい。ＲＡＮ１０４が、実施形態と一貫したまま任意の数のＮｏｄｅＢおよびＲＮＣを含んでもよいことを理解されたい。

図１Ｃに示されるように、ＮｏｄｅＢ１４０ａおよび１４０ｂは、ＲＮＣ１４２ａと通信していてもよい。加えて、ＮｏｄｅＢ１４０ｃは、ＲＮＣ１４２ｂと通信していてもよい。ＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃは、Ｉｕｂインターフェースを介してそれぞれのＲＮＣ１４２ａおよび１４２ｂと通信してもよい。ＲＮＣ１４２ａおよび１４２ｂは、Ｉｕｒインターフェースを介して互いに通信していてもよい。ＲＮＣ１４２ａおよび１４２ｂのそれぞれは、それが接続されるそれぞれのＮｏｄｅＢ１４０ａ、１４０ｂおよび１４０ｃを制御するように構成されてもよい。加えて、ＲＮＣ１４２ａおよび１４２ｂのそれぞれは、アウターループ電力制御、負荷制御、アドミッション制御、パケットスケジューリング、ハンドオーバ制御、マクロダイバーシティ、セキュリティ機能、およびデータ暗号化などの他の機能を実行し、または、サポートするように構成されてもよい。

図１Ｃに示されたコアネットワーク１０６ａは、メディアゲートウェイ（ＭＧＷ）１４４、モバイルスイッチングセンタ（ＭＳＣ）１４６、サービングＧＰＲＳサポートノード（ＳＧＳＮ）１４８、および／または、ゲートウェイＧＰＲＳサポートノード（ＧＧＳＮ）１５０を含んでもよい。前述した要素のそれぞれが、コアネットワーク１０６ａの一部として示されているが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有され、および／または、運営されてもよいことを理解されたい。

ＲＡＮ１０４におけるＲＮＣ１４２ａは、ＩｕＣＳインターフェースを介してコアネットワーク１０６ａにおけるＭＳＣ１４６に接続されてもよい。ＭＳＣ１４６は、ＭＧＷ１４４に接続されてもよい。ＭＳＣ１４６およびＭＧＷ１４４は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃにＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃと従来型有線通信デバイスとの間の通信を容易にしてもよい。

ＲＡＮ１０４におけるＲＮＣ１４２ａはまた、ＩｕＰＳインターフェースを介してコアネットワーク１０６ａにおけるＳＧＳＮ１４８に接続されてもよい。ＳＧＳＮ１４８は、ＧＧＳＮ１５０に接続されてもよい。ＳＧＳＮ１４８およびＧＧＳＮ１５０は、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ａ、１０２ｂおよび１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。

上述したように、コアネットワーク１０６ａはまた、ネットワーク１１２に接続されてもよく、ネットワーク１１２は、他のサービスプロバイダによって所有され、および／または運営される他の有線ネットワークもしくは無線ネットワークを含んでもよい。

図１Ｄは、一実施形態にしたがったＲＡＮ１０４ｂおよびコアネットワーク１０６ｂのシステム図である。上述したように、ＲＡＮ１０４ｂは、Ｅ−ＵＴＲＡ無線技術を採用して、エアインターフェース１１６上でＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆと通信してもよい。ＲＡＮ１０４ｂはまた、コアネットワーク１０６ｂと通信していてもよい。

ＲＡＮ１０４ｂは、ｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆを含んでもよいが、ＲＡＮ１０４ｂが、実施形態と一貫したまま任意の数のｅＮｏｄｅＢを含んでもよいことを理解されたい。ｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆは、それぞれ、エアインターフェース１１６を上でＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆと通信する１つまたは複数の送受信機を含んでもよい。一実施形態では、ｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆは、ＭＩＭＯ技術を実装してもよい。したがって、ｅＮｏｄｅＢ１４０ｄは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ｄに無線信号を送信し、および、ＷＴＲＵ１０２ｄから無線信号を受信してもよい。

ｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆのそれぞれは、特定のセル（図示せず）に関連付けられてもよく、ならびに、無線リソース管理決定、ハンドオーバ決定、アップリンクおよび／またはダウンリンクでのユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｄに示されるように、ｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆは、Ｘ２インターフェース上で互いに通信してもよい。

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

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

サービングゲートウェイ１４５は、Ｓ１インターフェースを介してＲＡＮ１０４ｂにおけるｅＮｏｄｅＢ１４０ｄ、１４０ｅおよび１４０ｆのそれぞれに接続されてもよい。サービングゲートウェイ１４５は、概して、ＷＴＲＵ１０２ｄ、１０２ｅ、１０２ｆへ／からユーザデータをルーティング、および、転送してもよい。サービングゲートウェイ１４５はまた、ｅＮｏｄｅＢ間ハンドオーバ（inter-eNode B handovers）の間のユーザプレーンのアンカリング、ダウンリンクデータがＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆに対して利用可能であるときのページングのトリガリング、ならびに、ＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆのコンテキストの管理および記憶などの、他の機能を実行してもよい。

サービングゲートウェイ１４５はまた、ＰＤＮゲートウェイ１４７に接続されてもよく、ＰＤＮゲートウェイ１４７は、ＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆにインターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ｄ、１０２ｅおよび１０２ｆとＩＰ対応デバイスとの間の接続を容易にしてもよい。

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

図１Ｅは、一実施形態にしたがったＲＡＮ１０４ｃおよびコアネットワーク１０６ｃのシステム図である。ＲＡＮ１０４ｃは、ＩＥＥＥ８０２．１６無線技術を採用して、エアインターフェース１１６を介してＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉと通信するアクセスサービスネットワーク（ＡＳＮ）であってもよい。以下でさらに述べるように、ＷＴＲＵ１０２ｇ、１０２ｈ、１０２ｉおよびＲＡＮ１０４ｃ、ならびに、コアネットワーク１０６ｃの異なる機能エンティティの間の通信リンクは、基準ポイントとして定義されてもよい。

図１Ｅに示されるように、ＲＡＮ１０４ｃは、基地局１４０ｇ、１４０ｈおよび１４０ｉ、ならびに、ＡＳＮゲートウェイ１４１を含んでもよいが、ＲＡＮ１０４が、実施形態と一貫したまま任意の数の基地局およびＡＳＮゲートウェイを含んでもよいことを理解されたい。基地局１４０ｇ、１４０ｈおよび１４０ｉは、それぞれ、ＲＡＮ１０４ｃにおける特定のセル（図示せず）に関連付けられてもよく、ならびに、エアインターフェース１１６上でＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉと通信する１つまたは複数の送受信機を含んでもよい。一実施形態では、基地局１４０ｇ、１４０ｈおよび１４０ｉは、ＭＩＭＯ技術を実装してもよい。したがって、基地局１４０ｇは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ｇに無線信号を送信し、および、ＷＴＲＵ１０２ｇから無線信号を受信してもよい。基地局１４０ｇ、１４０ｈおよび１４０ｉはまた、ハンドオフトリガリング、トンネル確立、無線リソース管理、トラフィック分類、およびサービス品質（ＱｏＳ）ポリシー実施などのモビリティ管理機能を提供してもよい。ＡＳＮゲートウェイ１４１は、トラフィックアグリゲーションポイントとしてサービスしてもよく、および、ページング、加入者プロファイルのキャッシュ、およびコアネットワーク１０６ｃへのルーティングなどに関与してもよい。

ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉとＲＡＮ１０４ｃとの間のエアインターフェース１１６は、ＩＥＥＥ８０２．１６仕様を実装するＲ１基準ポイントとして定義されてもよい。加えて、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉのそれぞれは、コアネットワーク１０６ｃとの論理インターフェース（図示せず）を確立してもよい。ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉとコアネットワーク１０６ｃとの間の論理インターフェースは、Ｒ２基準ポイントとして定義されてもよく、Ｒ２基準ポイントは、認証、認可、ＩＰホスト構成管理、および／またはモビリティ管理に使用されてもよい。

基地局１４０ｇ、１４０ｈおよび１４０ｉのそれぞれの間の通信リンクは、ＷＴＲＵハンドオーバおよび基地局間のデータの転送を容易にするプロトコルを含む、Ｒ８基準ポイントとして定義されてもよい。基地局１４０ｇ、１４０ｈおよび１４０ｉとＡＳＮゲートウェイ１４１との間の通信リンクは、Ｒ６基準ポイントとして定義されてもよい。Ｒ６基準ポイントは、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉのそれぞれに関連付けられたモビリティイベントに基づいてモビリティ管理を容易にするプロトコルを含んでもよい。

図１Ｅに示されるように、ＲＡＮ１０４は、コアネットワーク１０６ｃに接続されてもよい。ＲＡＮ１０４ｃとコアネットワーク１０６ｃとの間の通信リンクは、たとえばデータ転送およびモビリティ管理能力を容易にするプロトコルを含む、Ｒ３基準ポイントとして定義されてもよい。コアネットワーク１０６ｃは、モバイルＩＰホームエージェント（ＭＩＰ−ＨＡ）１５４、認証・認可・アカウンティング（ＡＡＡ）サーバ１５６、およびゲートウェイ１５８を含んでもよい。前述の要素のそれぞれは、コアネットワーク１０６ｃの一部として示されるが、これらの要素の任意の１つが、コアネットワークオペレータ以外のエンティティによって所有、および／または運営されてもよいことを理解されたい。

ＭＩＰ−ＨＡは、ＩＰアドレス管理に関与してもよく、ならびに、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉが異なるＡＳＮ、および／または、異なるコアネットワークの間でローミングすることを可能にしてもよい。ＭＩＰ−ＨＡ１５４は、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉに、インターネット１１０などのパケット交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉとＩＰ対応デバイスとの間の通信を容易にしてもよい。ＡＡＡサーバ１５６は、ユーザ認証に関与してもよく、および、ユーザサービスをサポートすることに関与してもよい。ゲートウェイ１５８は、他のネットワークとのインターワーキングを容易にしてもよい。たとえば、ゲートウェイ１５８は、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉに、ＰＳＴＮ１０８などの回線交換ネットワークへのアクセスを提供して、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉと従来型有線通信デバイスとの間の通信を容易にしてもよい。加えて、ゲートウェイ１５８は、ＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉに、ネットワーク１１２へのアクセスを提供してもよく、ネットワーク１１２は、他のサービスプロバイダによって所有され、および／または、運営される他の有線もしくは無線ネットワークを含んでもよい。

図１Ｅには示されないが、ＲＡＮ１０４ｃは他のＡＳＮに接続されてもよく、および、コアネットワーク１０６ｃは他のコアネットワークに接続されてもよいことを理解されたい。ＲＡＮ１０４ｃと他のＡＳＮとの間の通信リンクは、Ｒ４基準ポイントとして定義されてもよく、Ｒ４基準ポイントは、ＲＡＮ１０４ｃと他のＡＳＮとの間でＷＴＲＵ１０２ｇ、１０２ｈおよび１０２ｉのモビリティを調節するためのプロトコルを含んでもよい。コアネットワーク１０６ｃと他のコアネットワークとの間の通信リンクは、Ｒ５基準ポイントとして定義されてもよく、Ｒ５基準ポイントは、ホームコアネットワークと移動先コアネットワークとの間のインターワーキングを容易にするためのプロトコルを含んでもよい。

一態様にしたがって、方法は、ハンドオーバに対するターゲットＨｅＮＢを選択するために使用されてもよい。無線送信／受信ユニット（ＷＴＲＵ）との接続が確立されてもよい。接続は、セッションであってもよく、セッションは、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）セッション、または、ローカルＩＰアクセス（ＬＩＰＡ）セッションのいずれかを備えてもよい。ターゲットＨｅＮＢは、セッションをサポートするためのターゲットＨｅＮＢの能力に基づいて、ハンドオーバに対して選択されてもよい。例えば、ＷＴＲＵがターゲットＨｅＮＢにアクセスすることを許可されることの判定は、ＣＳＧサブスクリプション情報に基づいて行われてもよい。ターゲットＨｅＮＢが、ＷＴＲＵに対するセッションを提供するローカルゲートウェイ（ＬＧＷ）に接続されることを検証してもよい。ＷＴＲＵがターゲットＨｅＮＢからサービスを受信することを許可されることの判定がまた行われてもよい。別の例として、セッションがターゲットＨｅＮＢ上でサポートされることのインジケーションをＷＴＲＵから受信することによって、ターゲットＨｅＮＢは、セッションをサポートするためのターゲットＨｅＮＢの能力に基づいて、ハンドオーバに対して選択されてもよい。別の例として、パーソナルデータネットワーク（ＰＤＮ）を指定し、または、ＬＧＷを識別するターゲットＨｅＮＢからの識別子が使用されて、ターゲットＨｅＮＢを選択してもよい。加えて、情報がコアネットワークから受信されてもよく、または、ターゲットＨｅＮＢは、セッションをサポートすることを示す要素が使用されて、ターゲットＨｅＮＢを選択してもよい。

セッションは、ターゲットＨｅＮＢにハンドオーバされてもよい。例えば、ＬＧＷトランスポートレイヤアドレスおよびトンネルエンドポイントＩＤ（ＴＥＩＤ）が判定されてもよい。ＬＧＷトランスポートレイヤアドレスおよびＴＥＩＤがターゲットＨｅＮＢに提供されて、ターゲットＨｅＮＢがセッションを継続することを可能にしてもよい。

別の態様にしたがって、ＷＴＲＵは、ＬＧＷがＳＩＰＴＯとＬＩＰＡとを区別することを可能にしてもよい。ＵＩＰトラフィックを１つまたは複数のアクティブインターフェースにまたがってルーティングするためのルールのセットを提供することができるインターアクセスポイントネーム（ＡＰＮ）ルーティングポリシー（ＩＡＲＰ）は、たとえば、アクセスネットワーク発見・選択機能（ＡＮＤＳＦ：access network discovery and selection function）から受信されてもよい。好ましいＡＰＮは、ＩＡＲＰからのＡＰＮの優先順位付けされたリストを使用して判定されてもよい。ＩＰインターフェースが選択されて、好ましいＡＰＮに基づいてＩＰフローをルーティングしてもよい。選択されたＩＰインターフェースは、専用パケットデータネットワーク（ＰＤＮ）接続であってもよい。ＩＰフローがＳＩＰＴＯまたはＬＩＰＡであることのインジケーションは、ネットワークエンティティに送信されてもよい。ネットワークエンティティは、ＭＭＥ、ＳＧＷ、ＬＧＷ、またはＰＧＷなどであってもよい。インジケーションは、たとえば、ＬＧＷがＳＩＰＴＯまたはＬＩＰＡとしてＩＰフローを識別することを可能にするＩＰアドレス情報を含んでもよい。インジケーションは、ＬＧＷがＳＩＰＴＯまたはＬＩＰＡとしてＩＰフローを識別することを可能にするＡＰＮ値を含んでもよい。ＩＰフローは、選択されたＩＰインターフェースを使用して送信されてもよい。

別の態様にしたがって、ハンドオーバを提供する方法が使用されてもよい。ＨｅＮＢは、ハンドオーバインジケーションを受信してもよい。セッションをサポートすることができる、ＷＴＲＵヘの接続を確立することができるかに関する判定がされてもよく、セッションは、ＳＩＰＴＯセッションまたはＬＩＰＡセッションのいずれかを含んでもよい。パーソナルデータネットワーク（ＰＤＮ）を指定し、または、ＬＧＷを識別する識別が送信されてもよい。情報がコアネットワークおよび／またはＷＴＲＵに送信されて、ＨｅＮＢがセッションをサポートすることができることを示してもよい。ＬＧＷトランスポートレイヤアドレスおよびトンネルエンドポイントＩＤ（ＴＥＩＤ：tunnel endpoint identification）が判定されてもよい。ＷＴＲＵとの接続が確立されてもよい。セッションハンドオーバが受信されてもよい。

図２は、限定加入者グループ（ＣＳＧ）ベースのローカルＩＰアクセス（ＬＩＰＡ）、リモートＩＰアクセス（ＲＩＰ Ａ）、および／または、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）を提供することができる通信ネットワークのブロック図を示す。図２に示されるように、ＵＥ２０５は、ＣＳＧ−Ｈｏｍｅ２２０と通信してもよく、および、２１５においてＣＳＧ−Ｖｉｓｉｔ２１５と通信してもよい。このことは、たとえば、ＵＥ２０５がＣＳＧ−Ｈｏｍｅ２２０からＣＳＧ−Ｖｉｓｉｔ２１５にハンドオーバすることを可能にするために行われてもよい。

ＣＳＧ−Ｈｏｍｅ２２０は、ＨＮＢ２２５およびＨＮＢ２３０などの１つまたは複数のＨ（ｅ）ＮＢを含んでもよい。ＣＳＧ−Ｈｏｍｅ２２０はまた、ＳＧＷとして動作することができるＬＧＷ２４５を含んでもよい。ＬＧＷ２４５は、ローカルネットワーク２０２、ＰＧＷ２６５、ＨＮＢ２２５、およびＨＮＢ２３０に動作可能に接続されてもよい。ＰＧＷ２６５は、ＰＤＮ２８５に動作可能に接続されてもよく、および、ＣＳＧ−Ｈｏｍｅ２２０がＬＧＷ２４５を介してＰＤＮ２８５と通信することを可能にしてもよい。ＰＤＮ２８５は、ＣＳＧ−Ｈｏｍｅ２２０の一部でなくてもよい。

Ｈ（ｅ）ＮＢ−ＧＷ２５０は、ＨＮＢ２２５、ＨＮＢ２４０、およびＳＧＳＮ／ＭＭＥ２７０に動作可能に接続されてもよい。Ｈ（ｅ）ＮＢ−ＧＷ２５０は、ＣＳＧ−Ｈｏｍｅ２２０の一部であってもよい。

ＣＳＧ−Ｖｉｓｉｔ２１５は、Ｈ（ｅ）ＮＢ２３５およびＨ（ｅ）ＮＢ２４０などの１つまたは複数のＨ（ｅ）ＮＢを含んでもよい。ＣＳＧ−Ｖｉｓｉｔ２１５はまた、ＳＧＷとして動作することができるＬＧＷ２５５を含んでもよい。ＬＧＷ２５５は、ローカルネットワーク２０３、Ｈ（ｅ）ＮＢ２３５、およびＨ（ｅ）ＮＢ２４０に動作可能に接続されてもよい。

Ｈ（ｅ）ＮＢ−ＧＷ２６０は、Ｈ（ｅ）ＮＢ２３５、Ｈ（ｅ）ＮＢ２４０、およびＳＧＳＮ／ＭＭＥ２７５に動作可能に接続されてもよい。Ｈ（ｅ）ＮＢ−ＧＷ２６０は、ＣＳＧ−Ｖｉｓｉｔ２１５の一部であってもよい。

ＨＨＳ／ＨＬＲ２８０は、ＳＧＮ／ＭＭＥ２７５およびＳＧＮＳＮ／ＭＭＥ２７０に動作可能に接続されてもよい。このことは、たとえば、ＣＳＧ−Ｈｏｍｅ２２０がＣＳＧ−Ｖｉｓｉｔ２１５と通信することを可能にするために行われてもよい。たとえば、ＣＳＧ−Ｈｏｍｅ２２０は、ＨＨＳ−ＨＬＲ２８０を使用して、ＣＳＧ−Ｖｉｓｉｔ２１５と通信して、ＵＥ２０５をＣＳＧ−Ｈｏｍｅ２２０からＣＳＧ−Ｖｉｓｉｔ２１５にハンドオーバしてもよい。

ＳＩＰＴＯサービスおよびＬＩＰＡサービスのアクティブ化または要求が提供されてもよい。加入者は、単純にそのようなサービスをサポートする利用可能なネットワークを選択することによって、自らのＵＥにおいてローカルＩＰアクセスを構成してもよい。ＵＥがサポートすることができる多数の特徴を考慮すると、加入者は、加入者既知のＣＳＧに同様の方法でネットワークを選択することができる。このことは、たとえば、加入者が新しいアイコンまたはメニューに慣れなければならないことを防ぐために行われてもよい。

加入者はまた、加入者が自らのホームネットワークまたは移動先ネットワークに接続されているか否かに関わらず、加入者ローカルＧＷ（ＬＧＷ）とすることができる特定のＰＤＮゲートウェイ（ＰＧＷ）を選択することを許可されてもよい。このことは、たとえば、ユーザが要求しているセッションが、特定のＬＧＷに向けてセットアップされることを保証することができるＣＳＧの集合から、同一のＣＳＧまたは特定のＣＳＧを選択することによって行われてもよい。

ネットワークは、ユーザによって選択されたＣＳＧに関連付けられたＬＧＷのグループから選択されてもよい。ＣＳＧのユーザによる手動選択を通じてトリガされる、ＬＧＷの選択は、ＣＳＧを特定のＡＰＮと関連付けることに依存する必要がなくてもよい。

ＵＥは、ＣＳＧとシームレスモビリティを可能にすることが望まれるサービスのタイプもしくはサービスのレベルとの間の関連付けのユーザセッティングまたは構成に基づいて、ＳＩＰＴＯ／ＬＩＰＡのアクティブ化／非アクティブ化を自律的に選択してもよい。たとえば、ユーザは、特定のＣＳＧの傘下のＮＢまたはＨ（ｅ）ＮＢに接続されるときに、ＳＩＰＴＯ機構の使用を手動でブラックリストに入れてもよい。加えて、ユーザは、ＳＩＰＴＯまたはＬＩＰＡを提供することができるＣＳＧを手動で構成してもよい。ネットワークは、ユーザによって選択されたとしてのパーミッションが特定のＣＳＧに対して有効とすることができる場合に、ＳＩＰＴＯサービスまたはＬＩＰＡサービスを提供することを試みてもよい。

サービス固有の選択的ＩＰトラフィックオフロードが提供されてもよい。加入者は、自らが要求するサービスの特定の要件に適合するＩＰトラフィックオフロードポイントを使用してもよい。

現在のシステムでは、提供される粒度は、ＡＰＮごとをベースにしているが、このことは、同一のＡＰＮを使用してＳＩＰＴＯ固有の区別されたサービス能力を提供することを可能にしない。ＵＥは、ＰＤＮ接続性要求（PDN CONNECTIVITY REQUEST）メッセージを通じて、特定の接続に対する所望のＱｏＳを提供することができる場合がある。しかし、現在のネットワークは、ＨＳＳにおける加入者レコードに格納されたＡＰＮをいまだに使用して、パケットデータ接続性を提供するのにどのＰＧＷが使用されるべきかを判定するであろう。

したがって、現在の解決策は、特定のＡＰＮに接続するＬＧＷを通じて何のサービスをサポートすることができるかに関わらず、選択をこのＡＰＮに制限する。この制限は、ロケーションアウェアネス（awareness）アソシエーションおよび動的／オンザフライもしくは静的な課金制度など、特定のサービスの配信を保証する手段として、ユーザ構成可能なＳＩＰＴＯ／ＬＩＰＡ選択を可能にしない。ユーザによるＬＧＷの選択は、必ずしも、ユーザがＩＰアドレスまたは任意の他のアドレッシング機構をサービス方式ごとに手動で構成することを意味しない。ユーザは、単に、サービスを選択してもよく、および、サービスロジック自体は、サービスの満足な配信を保証することができる、要求されるＱｏＳを提供することによって、適切なＬＧＷ／ＰＧＷの選択をトリガしてもよい。

サービス固有の選択的ＩＰトラフィックオフロードおよびローカルＩＰアクセスが提供されてもよい。本開示の実施形態にしたがって、サービスが特定のサービス品質（ＱｏＳ）を要求するときに、ＵＥは、どの論理ゲートウェイ（ＬＧＷ）またはパケットデータネットワークゲートウェイ（ＰＧＷ）が選択されて、このサービスを提供することができるかを指定してもよい。このことは、オペレータのネットワーク内の深いところにあるローカルゲートウェイまたはパケットデータネットワークゲートウェイであってもよい。したがって、ＵＥは、本明細書で説明するように、その選択を複数の方法で指定してもよい。たとえば、ＵＥは、特定のＡＰＮおよびＣＳＧ ＩＤの組合せを指定してもよく、これによって、同一のＡＰＮによって提供されるサービスの異なるレベルの分離を可能にする。別の例では、ＵＥは、ＣＳＧ ＩＤのみを指定してもよい。別の例では、ＵＥは、ワイルドカードＡＰＮなどのダミーＡＰＮと、ＱｏＳクラスなどの要求されるＱｏＳとを指定してもよい。ＱｏＳクラスは、会話、ストリーミング、対話、およびバックグラウンドであってもよい。別の例では、ＵＥは、ＣＳＧタイプ（たとえば、ハイブリッドまたはクローズド（closed））を指定してもよい。ＣＳＧタイプが定義されて、課金モードを反映してもよい。ＣＳＧタイプがまた定義されて、ＱｏＳプリファレンスを反映してもよい。別の例では、ＵＥは、ワイルドカードＣＳＧ ＩＤを指定してもよい。たとえば、ＳＬＡアグリーメントに基づいて、未知の位置におけるユーザが、ユーザがそのメンバであってもよいＣＳＧ、または、ワイルドカードＣＳＧ ＩＤと一致してもよいＣＳＧを使用して、ＳＩＰＴＯを実行するようにそのＵＥを構成してもよい。ワイルドカードＣＳＧは、特定の属性（たとえば、デフォルトＱｏＳ属性）を有するＬＧＷまたはＰＧＷに関連付けられてもよい。さらなる別の例では、たとえば、ホームＵＥは、特定のＣＳＧ ＩＤに基づいてトラフィックをオフロードするように構成されてもよく、オフィスでは、ＵＥはＣＳＧタイプまたはワイルドカードＣＳＧに基づいてトラフィックをオフロードするように構成されてもよいなど、ＵＥは、前述の例のうちの１つまたは複数を指定してもよい。さらに、前述の例のうちの複数が同時に使用されてもよく、すなわち、ＳＩＰＴＯオプションが各アプリケーションに対してまたは各サービスに対して別々に構成されてもよい。たとえば、ＨｅＮＢは複数のＬ−ＧＷに接続されてもよく、Ｌ−ＧＷは、同一のＣＳＧまたは異なるＣＳＧに関連付けられてもよい。そして、ＳＩＰＴＯは、ＬＧＷのプールからのＬＧＷの動的選択で、ユーザセッティングまたは表されたプリファレンスに依存して実行されてもよい。

加入者固有の選択されたＩＰトラフィックおよびローカルＩＰアクセスが提供されてもよい。加入者は、たとえば特定のＩＰトラフィックオフロードポイント（たとえば、特定のＬＧＷまたは特定のＰＧＷ）を選択することから生じる場合がある利点に起因して、特定のＬＧＷまたはＰＧＷを選択してもよい。この利点は、自らのホームオペレータプロバイダデータプランを使用して、データサービスにアクセスする可能性、または、企業ゲートウェイもしくは限定グループゲートウェイ（closed group gateway）にアクセスする可能性を含む、よりよい使用料金または特殊なサービスを提供されることを含んでもよい。

ＣＳＧ ＩＤは、ＵＥによって選択され、および、使用されて、加入者の代わりに特定のゲートウェイにアクセスするようにネットワークにシグナリングしてもよい。ＣＳＧは、現在の３ＧＰＰプロシージャを使用してネットワークによってブロードキャストされるＣＳＧ ＩＤ、または、加入者が、ＵＥが表示してもよいＣＳＧの近隣にいるかに関わらず表示されるように、ホームオペレータによって構成された静的ＣＳＧのいずれかであってもよい。言い換えると、デフォルトＣＳＧ−Ｉｄは、ホームネットワークにおけるＨｅＮＢ／ＬＧＷペアに対するホームＣＳＧ−Ｉｄ、または、ＵＥのホワイトリストにおける第１のＣＳＧ−Ｉｄであっってもよい。ＵＥは、これがホームネットワークであるか、または、移動先ネットワークであるかに関わらず、ネットワークによってブロードキャストされたＣＳＧ−Ｉｄブロードキャストを表示してもよく、および、加入者ホームＣＳＧ−ＩｄがブロードキャストＣＳＧ−Ｉｄの一部ではない場合であっても、ブロードキャストされた他のＣＳＧとともに、加入者ホーム（ｅ）ＮＢによってブロードキャストＣＳＧ−Ｉｄを含んでもよい。

ＣＳＧが完全修飾ドメイン名（ＦＱＤＮ）として使用されて、ＬＧＷまたはＰＧＷのアドレスを判定してもよい。したがって、トラフィックオフロードに対するＣＳＧを選択することは、サービス要求プロシージャをトリガしてもよく、このサービス要求プロシージャは、選択されたＣＳＧを含んでもよい。たとえば、ＰＤＮ ＣＯＮＮＥＣＴＩＶＩＴＹ ＲＥＱＵＥＳＴメッセージは、Ｌ−ＧＷであれ他のＰＧＷであれ、関連するＰＧＷが存在するＣＳＧ−Ｉｄを搬送してもよい。メンバシップ検証プロシージャはまた、選択されたＣＳＧをＦＱＤＮまたは関連するオフロードポイントＩＰアドレスへのキーとして使用して、オフロードポイントに対するルーティング可能アドレスの判定を含んでもよい。

ＣＳＧまたはＣＳＧリストはまた、登録（たとえば、ＨＳＳへの格納）またはローミングのときに、ホームＰＬＭＮによって移動先ＰＬＭＮに提供されてもよい。移動先ＰＬＭＮは、たとえば登録アクセプトプロシージャの間に選択することができる特定のＰＧＷまたはＬＧＷに関連付けられた、利用可能なＣＳＧのリストをＵＥに提供してもよい。ＵＥは、このリストに含まれるＣＳＧ ＩＤを表示してもよく、それによって、これらのＣＳＧ ＩＤが手動で選択されて、ＰＧＷまたはＬＧＷの再配置をトリガすることができる。ＵＥおける選択プロシージャは、ユーザが、ＶＰＬＭＮがＵＥまたはユーザに提示したリスト内にない場合がある特定のＣＳＧ ＩＤを入力することを可能にしてもよい。選択プロシージャは、入力されたＣＳＧ−Ｉｄに関連付けられたＬＧＷの可用性または到達可能性をテストしてもよい。このことは、たとえば、ＶＰＬＭＮからＨＰＴＬＭへの経路を使用して行われてもよい。調査（probe）が成功した場合は、テストされたＣＳＧ ＩＤが次回に表示されてもよい。

ユーザがＣＳＧを選択すると、ＣＳＧは、ルーティング可能アドレスに変換されてもよい。たとえば、ＣＳＧは、トラフィックを特定のＰＧＷまたはＬＧＷに対してルーティングするサービングシステムによって使用されるＦＱＤＮであってもよい。加えて、ＣＳＧ−ＩｄまたはＱｏＳ要件などの他の情報と組み合わされたＡＰＮの選択は、ＰＣＲＦ機能によって使用されて、オペレータポリシーを通じて、特定のサービス要求をサポートするのに使用することができるＬＧＷまたはＰＧＷのタイプを判定してもよい。現在選択されているＰＧＷが、関連するＰＣＲＦとコンタクトするときに、ＰＣＲＦは、ＩＰ接続アクセスネットワーク（ＩＰ−ＣＡＮ）セッション確立変更（Session Establishment Modification）プロシージャを通じて、新たなＬＧＷもしくはＰＧＷを提案し、または、提唱してもよい。現在のＰＧＷは、セッション作成応答（Create Session Response）メッセージまたはこの目的に適する任意の他のメッセージを通じて、この情報を現在のＳＧＷに中継してもよい。このことは、ＬＧＷ／ＰＧＷ再配置をトリガすることができる。

本明細書で説明されるシステムおよび方法の実施形態のいくつかを使用して、移動先システムは、加入者ＨＳＳから、加入者がアクセスすることを許可されてもよいＣＳＧのリストを取得することができる。このことは、たとえば、ＨＳＳに格納された加入者プロファイル情報を使用して行われてもよい。ＣＳＧのリストは、特定のＬＧＷまたはＰＧＷの選択をトリガすることができるＣＳＧを含んでもよい。たとえば、図２に示されるように、ＵＥ２０５は、ＣＳＧ−Ｖｉｓｉｔ２１５の近隣をローミングしてもよく、このＣＳＧ−Ｖｉｓｉｔ２１５は、「ＣＳＧ−ＶＩＳＩＴ」によって識別される限定加入者グループであってもよい。ＵＥ２０５は、「ＣＳＧ−ＶＩＳＩＴ」名と「ＣＳＧ−ＨＯＭＥ」との両方を表示してもよい。このことは、加入者が、ＬＧＷ２４５を使用することができることをネットワークに指示することができる「ＣＳＧ−ＨＯＭＥ」ＣＳＧ−Ｉｄを選択することを可能にすることができる。

図２に示されように、ＬＧＷ２４５またはＬＧＷ２５５などのＬＧＷは、特定のセクションにアクセスする加入者に、ＰＧＷ能力とＳＧＷ能力との両方を提供してもよい。ＵＥは、同一のＬＧＷに属するＨｅＮＢの間、または、Ｈ（ｅ）ＮＢと通常の（ｅ）ＮＢとの間で移動してもよい。たとえば、ＵＥ２０５は、ＨＮＢ２２５からＨＮＢ２３０へ、Ｈ（ｅ）ＮＢ２３５からＨ（ｅ）ＮＢ２４０へ移動してもよく、または、同一のＬＧＷに属する任意のＨ（ｅ）ＮＢと通常の（ｅ）ＮＢとの間で移動してもよい。ＬＧＷは、ＰＧＷ機能性とＳＧＷ機能性との両方をハウジング（house）してもよく、最初から、ＵＥが特定のＣＳＧにアクセスする場合に、ＳＧＷの選択は、ＣＳＧ−ＩＤ、要求されたＡＭＢＲ、または提供されるＬＩＰアドレスなどを考慮することができる。たとえば、ＬＧＷ２４５は、ＰＧＷ機能性とＳＧＷ機能性との両方をハウジングしてもよい。このことは、ＵＥ２０５が、ＣＳＧ−Ｈｏｍｅ２２０などの特定のＣＳＧにアクセスし、または、選択することを可能にすることができる。ＵＥ２０５による選択は、ローカルＩＰトラフィックオフロードおよびパブリックＩＰトラフィックオフロードの両方へのアクセスを提供する、ＬＧＷとＰＤＧとの両方に接続することができる特定のＳＧＷの選択につながってもよい。たとえば、ＵＥ２０５がＣＳＧ−Ｈｏｍｅ２２０を選択するときに、ＳＧＷは、ＬＧＷ２４５およびＰＧＷ２６５に接続して、ＰＤＮ２８５およびローカルネットワーク２０２へのアクセスを提供してもよい。

ＭＭＥにおけるＳＧＷの選択は、ＳＩＰＴＯが許可されるか否かを考慮してもよい。ＭＭＥは、ユーザによって提供される１つまたは複数のＣＳＧ ＩＤを考慮して、それによって、共通のＳＧＷがパブリックトラフィックオフロードおよびローカルトラフィックオフロードの両方に対して選択されてもよい。選択されるＳＧＷは、本明細書で提案される、同一位置に配置されたＬＧＷ／ＳＧＷであってもよい。共通のＳＧＷのＭ選択は、異なるＳＧＷへの再配置を必要とせずに、スタンドアロンＬＧＷ／ＳＷに接続されたＨｅＮＢにまたがるユーザプレーン内のハンドオーバに対してサポートすることを可能にすることができる。

別の例の実施形態では、ユーザは、ＬＩＰＡおよび／またはＳＩＰＴＯ ＰＧＷ／ＬＧＷ／ＳＧＷリソースの両方の同時セットアップ、ならびに、構成を可能にすることができる情報を提供してもよい。たとえば、ユーザは、ＳＩＰＴＯとＬＩＰＡとの両方に対するＬＧＷとＰＧＷとの両方に関連付けられたＣＳＧ−Ｉｄの集合を提供してもよい。このことは、ＵＥによって提供されるＣＳＧ ＩＤ、またはＱｏＳ要件などの選択基準を使用して、これらのゲートウェイに対する複数同時接続のセットアップを可能にすることができる。一方はローカル、もう一方はリモート（または従来の）の２つのゲートウェイが、共通のＳＧＷを使用してセットアップされるときに、ＮＡＴまたはＩＰ変換ポイントとして共通のＳＧＷを使用することが可能であってもよい。加えて、ＩＰ保存およびハンドオーバ（ＨＯ）を容易にすることが可能であってもよい。

本明細書で開示されるＬＧＷ／ＳＧＷコンビネーションは、リモートＬＩＰＡ（ＲＩＰ Ａ）をサポートしてもよい。たとえば、ＵＥが、ＨｅＮＢサブシステムの外へ移動するときに、ＵＥのユーザプレーンは、同一のＳＧＷにアンカリングされたままであってもよい。たとえば、ＵＥは、ＬＧＷと同一位置に配置することができるＳＧＷにおいてアンカリングされたままであってもよい。ＳＧＷが、ＮＡＴ機能性を提供できる場合に、ＵＥは、ＨｅＮＢからマクロネットワークに移動するときに、そのＬＩＰＡ ＰＤＮ接続をティアダウン（tear down）する必要がない場合がある。加えて、ＵＥは、ローカルネットワークにリモートに接続することが可能である場合がある。初期アタッチ中または別のＰＤＮ／ＰＤＰ接続要求の間に、ＭＭＥは、ＳＧＷを選択するべきか、またはそのＳＧＷを同一位置に配置されたＬＧＷ／ＳＧＷに再配置すべきかを決定してもよい。たとえば、ＭＭＥは、初期アタッチ中またはＰＤＮ／ＰＤＰ接続要求中に、ＵＥがローカルネットワークに接続したいことを示す場合に、ＳＧＷを選択するべきか、またはそのＳＧＷを同一位置に配置されたＬＧＷ／ＳＧＷに再配置すべきかを決定してもよい。

本開示の実施形態にしたがって、ＭＭＥは、ＳＧＷ選択機能の一部として、初期接続をセットアップするためのＳＧＷ能力を有するＬＧＷを使用することを決定してもよく、および、ＳＧＷ再配置を回避してもよい。

シームレスモビリティがサポートされてもよい。シームレスモビリティをサポートするために、自律的ＣＳＧ選択は、ＣＳＧとＬ−ＧＷ／Ｐ−ＧＷとの間の関連付けに基づいて、ユーザＳＩＰＴＯ／ＬＩＰＡサービスプリファレンスを考慮してもよい。ＣＳＧホワイトリストは、本明細書で上記定義されたＳＩＰＴＯサポートもしくはＬＩＰＡサポート、および、ユーザプリファレンスセッティングなどの追加エントリを含んでもよい。同様に、近接性インジケーションが更新されて、本明細書で上記定義されたＬＧＷもしくはＰＧＷ、および、ユーザプリファレンスセッティングとの関連付けに基づいて、ＳＩＰＴＯ／ＬＩＰＡオフロードポイントに関して、ユーザプリファレンスについての情報を提供してもよい。

図３は、ローカルゲートウェイ（ＬＧＷ）アーキテクチャにおけるＳＩＰＴＯモビリティおよび／またはＬＩＰＡモビリティを提供することができる通信ネットワークのブロック図を示す。図３に示されるように、ＵＥ３００は、Ｈ（ｅ）ＮＢ３０５およびＨ（ｅ）ＮＢ３１０など、１つまたは複数のＨ（ｅ）ＮＢと通信してもよい。Ｈ（ｅ）ＮＢ３０５およびＨ（ｅ）ＮＢ３１０は、お互いに動作可能に接続されてもよい。加えて、Ｈ（ｅ）ＮＢ３０５および／またはＨ（ｅ）ＮＢ３１０は、ＭＭＥ３３５、ＳＧＷ３２３、ＬＧＷ３２５、および／またはＳＧＷ３１５に動作可能に接続されてもよい。たとえば、ＭＭＥ３３５は、３６５におけるＳ１−ＭＭＥインターフェースを使用してＨ（ｅ）ＮＢ３０５と通信してもよく、ならびに、３８０におけるＳ１−ＭＭＥインターフェースを使用してＨ（ｅ）ＮＢ３１０と通信してもよい。

本明細書で説明されるのは、ローカルネットワークにおけるローカルＩＰアクセス（ＬＩＰ Ａ）および選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ）に対するアーキテクチャ的態様である。本明細書で説明される実施形態は、ローカルネットワークに位置するＨ（ｅ）ＮＢの間のＬＩＰＡに対するモビリティをサポートすることができる。たとえば、ＵＥがアタッチされるＨ（ｅ）ＮＢとは別のスタンドアロンＬＧＷが使用されてもよい。加えて、モビリティを含むことができるローカルネットワークにおいてトラフィックオフローディングをサポートする機能性を説明することができる。

ローカルネットワークにおけるＬＩＰＡおよび／またはＳＩＰＴＯに対するモビリティの導入、ならびに、本明細書で開示されるアーキテクチャ的変更は、スタンドアロンＬＧＷが、コアネットワーク（ＣＮ）へのＨ（ｅ）ＮＢの接続を可能にすることができるプロシージャおよび／または概念における変更を課すことを可能にすることができる。

スタンドアロンＬＧＷに加えて、ＬＧＷ内にＳＧＷをハウジングする能力（すなわち、同一位置に配置されたＬＧＷ／ＳＧＷエンティティ）ならびに／または、モビリティプロシージャおよび／もしくはＥＰＳベアラ確立プロシージャに対するその影響などの能力が含まれてもよい。スタンドアロンＬＧＷおよび／またはローカルネットワークにおけるモビリティ能力の導入はまた、追加の機能を提供することができる。

本明細書で説明されるシステム、方法、および装置は、ＬＧＷによるＨ（ｅ）ＮＢの発見、および／または、Ｈ（ｅ）ＮＢによるＬＧＷの発見を可能にしてもよい。スタンドアロンＬＧＷの導入は、Ｈ（ｅ）ＮＢとＬＧＷとの間の接続に影響する場合がある。たとえば、ＬＧＷが、Ｈ（ｅ）ＮＢのＩＰアドレスを知らない場合があり、および／または、Ｈ（ｅ）ＮＢが、ＬＧＷのＩＰアドレスを知らない場合がある。

発見は、ＬＧＷおよび／またはＨ（ｅ）ＮＢが事前に構成されることを許可することによって、接続（たとえば、ＳｘｘまたはＳ１’）がオペレーションプロシージャおよび／または管理プロシージャを通じて確立されてもよい。

発見はまた、動的機構が使用されることを許可することによって、可能としてもよい。たとえば、３ＧＰＰの概念、または、たとえば３ＧＰＰ仕様の範囲外でとなる場合があるＩＴと同等（IT-like）な概念が使用されてもよい。ノード選択の目的に対して一般的に使用される３ＧＰＰベースの機構、たとえばＰＧＷ選択機能またはＭＭＥ選択機能が、スタンドアロンＬＧＷおよび／もしくはＨ（ｅ）ＮＢノードの相互発見または独立発見に使用されてもよい。これらの機構はまた、たとえばＬＩＰＡ／ＳＩＰＴＯセッションの持続時間に、この２つの間の一時的接続を動的に確立するのに使用されてもよい。

Ｈ（ｅ）ＮＢは、スタンドアロンＬＧＷを発見してもよい。たとえば、Ｈ（ｅ）ＮＢは、ＵＥがＥＰＳベアラを確立することを望む場合があるときに、ＬＧＷを動的に発見してもよい。ＵＥは、たとえばアタッチ要求（Attach Request）および／またはＰＤＰ接続性要求（PDP Connectivity Request）などのＮＡＳプロシージャを支援し、適切なＬＧＷの発見をトリガしてもよい。初期ＵＥメッセージ（INITIAL UE MESSAGE）および／またはアップリンクＮＡＳトランスポート（UPLINK NAS TRANSPORT）メッセージがＭＭＥで受信されるときに、ＭＭＥは、ＨＳＳに格納されたＵＥプロファイル内の情報を使用して、ＵＥを要求するためにＬＧＷを解決してもよい。このプロシージャは、特定のＰＧＷのアドレスを与えることができる、ＡＰＮのプロビジョニングに依存してもよい。トポロジ情報および／または地理的情報がＨＳＳに提供されて、ＵＥに対する適切なアドレスを判定してもよい。

アクセスネットワーク発見・選択機能（ＡＮＤＳＦ：Access Network Discovery and Selection Function）が使用されて、ＵＥの地理的アドレスおよび／またはトポロジアドレスにしたがって、ＵＥにＬＧＷのアドレスを提供してもよい。ＵＥは、モバイルネットワークオペレータコアネットワーク（ＭＮＯ ＣＮ）接続を使用することによって、ＡＮＤＳＦとコンタクトしてもよい。ＵＥはまた、非３ＧＰＰアクセスを通じてＡＮＤＳＦとコンタクトしてもよい。

Ｈ（ｅ）ＮＢは、Ｈ（ｅ）ＮＢ登録プロシージャの間にＬＧＷを発見してもよい。このことは、Ｈ（ｅ）ＮＢがＨ（ｅ）ＮＢ ＧＷに登録することを可能にすることができる。この場合、ＬＧＷは、Ｈ（ｅ）ＮＢ ＧＷと同一位置に配置されていてもよく、または、同一位置に配置されていなくてもよい。Ｈ（ｅ）ＮＢ ＧＷはまた、ＬＧＷアドレスをプロビジョニングされてもよい。Ｈ（ｅ）ＮＢ ＧＷからの登録応答は、Ｈ（ｅ）ＮＢへのＬＧＷアドレスを含んでもよい。

ＬＧＷ選択プロシージャが提供されてもよい。たとえば、ＬＧＷ選択プロシージャが、初期システム選択において、および／または、ハンドオーバにおいて提供されてもよい。

初期システム選択において、Ｈ（ｅ）ＮＢは、ＬＧＷのプールから、この接続をサービスするＬＧＷを選択してもよい。Ｈ（ｅ）ＮＢは、選択されたＬＧＷを使用するように、コアネットワークに要求してもよい。ＬＧＷは、Ｈ（ｅ）ＮＢ ＧＷを接続することができる複数のＬＧＷのうちの１つであってもよい。

ＬＧＷが、Ｈ（ｅ）ＮＢ ＧＷと同一位置に配置されているときに、Ｈ（ｅ）ＮＢ ＧＷは、コアネットワーク（たとえば、ＭＭＥ、ＳＧＳＮなど）にＬＧＷトランスポートレイヤアドレス（たとえば、ＩＰアドレス）を提供してもよい。たとえば、Ｈ（ｅ）ＮＢ ＧＷは、ＬＧＷトランスポートレイヤアドレスがＨ（ｅ）ＮＢ ＧＷトランスポートレイヤアドレスとは異なる場合に、コアネットワークにＬＧＷトランスポートレイヤアドレスを提供してもよい。Ｈ（ｅ）ＮＢ ＧＷは、トンネルエンドポイントＩＤ（ＴＥＩＤ：tunnel endpoint identification）または確立されているＥ−ＲＡＢ／ＲＡＢの相関ＩＤをＨ（ｅ）ＮＢに中継してもよい。

ＡＰＮは、ＬＧＷおよび／またはＬＧＷのセットにマッピングされてもよい。同様に、ＬＧＷは、複数のＡＰＮをサポートしてもよい。これらのシナリオの下では、ベアラ（たとえば、Ｅ−ＲＡＢ、ＲＡＢ）は、リアルタイムベースで、たとえばＳＩＰＴＯゲートウェイおよび／または非ＳＩＰＴＯゲートウェイにマッピングされてもよい。ＳＩＰＴＯトラフィックに対する複数のＬＧＷが、たとえば１つまたは複数のＰＤＮ接続の下にある、同一のまたは類似する動的ＳＩＰＴＯトラフィックオフロード決定が実行されてもよい。ＳＩＰＴＯトラフィックに対する複数のＬＧＷが、１つのＰＤＮ接続の下にあるときに、Ｈ（ｅ）ＮＢは、個々のＬＧＷ負荷に基づいてＬＧＷプールから選択してもよい。Ｈ（ｅ）ＮＢは、ＬＧＷをスケジューリングして、負荷状況を周期的に、または１回の報告ベースで報告してもよい。Ｈ（ｅ）ＮＢはまた、認可されたＬＧＷのプールからＬＧＷを動的に（たとえば、ベアラベース、ＧＴＰ ＰＤＵベースなど）選択し、または認可されたＬＧＷの間で利用可能なトラフィックを分割してもよい。同一または類似する方法が、複数のＬＧＷがＵＥに割り当てられるときに使用されてもよい。ＬＧＷの各サブグループは、異なるＩＰアドレスをＵＥに提供してもよい。接続中にまたはオペレータポリシーに基づいて確立される異なるレベルのＱｏＳターゲットベースでそれぞれ異なって管理することができる複数のＳＩＰＴＯ例があってもよい。ユーザは、たとえば、使用するＬＧＷおよび／または関連するＣＳＧを推奨してもよい。その場合に、複数のＬＧＷトランスポートレイヤアドレス（たとえば、ＩＰアドレス）は、たとえばＨ（ｅ）ＮＢ ＧＷを含むコアネットワークにＨ（ｅ）ＮＢによって、または代わりにＨ（ｅ）ＮＢにコアネットワークによって、提供されてもよい。各ＬＧＷトランスポートレイヤアドレスと各Ｅ＿ＲＡＢ／ＲＡＢとの間でマッピングが作成されてもよく、または、コアネットワークとＨ（ｅ）ＮＢとの間で交換されてもよい。

ＬＧＷ選択は、ハンドオーバ中に実行されてもよい。たとえば、ＬＧＷ選択は、ターゲットＨ（ｅ）ＮＢによるハンドオーバの間に実行されてもよい。代わりに、ソースＨ（ｅ）ＮＢは、ターゲットがＬＧＷを使用することを推奨してもよく、または、要求してもよい。ＬＧＷトランスポートレイヤアドレスおよび／またはアップリンクＴＥＩＤは、Ｘ２メッセージ上でなど、ターゲットＨ（ｅ）ＮＢに転送されてもよい。たとえば、図３に示されるように、Ｈ（ｅ）ＮＢ３０５は、ＬＧＷトランスポートレイヤアドレスおよび／またはアップリンクＴＥＩＤを、３５０においてＸ２メッセージ上で転送してもよい。

ハンドオーバが、ＣＮを介して実行されるときに、ＣＮは、ＬＧＷトランスポートレイヤアドレスをターゲットＨ（ｅ）ＮＢに提供してもよい。そのような情報は、たとえば経路切替えのときに提供されてもよい。Ｓｘｘ（またはたとえばＳ１’）プロシージャ（たとえば、初期確立）に対して、本明細書で説明される方法がまた使用されてもよい。

ハンドオーバにおいて実行されるＬＧＷ選択プロシージャは、たとえばＳ１インターフェースプロシージャであってもよい。初期セッション確立に対して説明されるプロシージャに加えて、以下のプロシージャが、モビリティのサポートにおいてＳｘｘインターフェース上で定義されてもよい。たとえば、データバイキャスティング（bi-casting）は、ハンドオーバ／再配置の間に実行されてもよい。経路切替えプロシージャは、ハンドオーバ実行の一部として使用されてもよい。ターゲットＨ（ｅ）ＮＢは、ＤＬ ＴＥＩＤ（各ベアラに対して、すなわちたとえばＥ−ＲＡＢ／ＲＡＢ）および／またはそのトランスポートレイヤアドレスをＬＧＷと交換してもよい。ＬＧＷは、オプションで、代わりにアップリンクＴＥＩＤおよび／またはそのトランスポートレイヤアドレスを提供してもよい。たとえば、図３を参照すると、Ｈ（ｅ）ＮＢ３１０は、ＤＬ ＴＥＩＤおよび／またはそのトランスポートレイヤアドレスを、３４０でＳ１’を介してＳＧＷ３１５および／またはＬＧＷ３２５と交換してもよい。ＳＧＷ３１５および／またはＬＧＷ３２５は、オプションで、アップリンクＴＥＩＤおよび／またはトランスポートレイヤアドレスを、３４０でＳ１’を介してＨ（ｅ）ＮＢ３１０に提供してもよい。

ハンドオーバにおいて実行されるＬＧＷ選択プロシージャは、Ｘ２インターフェースプロシージャであってもよい。Ｘ２インターフェースプロシージャは、たとえばＬＧＷ内プロシージャ（intra-LGW procedure）および／またはＬＧＷ間プロシージャ（inter-LGW procedure）であってもよい。図３は、ＬＧＷ内ハンドオーバプロシージャ（intra-LGW handover procedure）の一例を示す。図３を参照すると、ＬＧＷ内ハンドオーバプロシージャの間に、ＵＥ３００がＨ（ｅ）ＮＢ３０５からＨ（ｅ）ＮＢ３１０に移動するときに、Ｘ２ハンドオーバプロシージャが、３５０で使用されてもよい。相関ＩＤが、通常のＳＧＷ ＴＥＩＤの代わりに使用される場合に、Ｈ（ｅ）ＮＢ３１０などのターゲットＨ（ｅ）ＮＢは、Ｘ２ハンドオーバ要求（X2 HANDOVER REQUEST）メッセージ中に、相関ＩＤをＳＧＷ３１５およびＬＧＷ３２５などのＳＧＷ／ＬＧＷエンティティに提供してもよい。

ＬＧＷ間ハンドオーバ（inter-LGW handover）が実行される場合に、Ｈ（ｅ）ＮＢは、ターゲットＨ（ｅ）ＮＢに対して十分な情報を提供して、サービングＧＷ、ならびに／または、たとえばサービングＬＧＷアドレス、相関ｉｄ、および／もしくはＳＧＷ ＴＥＩＤなどのユーザプレーン経路に関係する関連した詳細（details）を識別してもよい。ターゲットＨ（ｅ）ＮＢは、Ｘ２経路切替え要求（X2 PATH SWITCH REQUEST）メッセージを通じて経路切り替えを要求するときに、この情報を使用してもよい。ターゲットＨ（ｅ）ＮＢは、ターゲットＨ（ｅ）ＮＢアドレスおよびＳｘｘに対するＴＥＩＤ、ならびに／または、ＬＧＷ Ｓ５ ＴＥＩＤを使用して、ターゲットＬＧＷとの新たなセッションを作成してもよい。ソースＨ（ｅ）ＮＢはまた、変更ベアラ要求（Modify Bearer Request）メッセージを送信することによって、ソースＬＧＷとのＳｘｘユーザ経路を解放してもよい。

図３に示されるように、Ｓ１’などのＳｘｘインターフェースプロシージャが提供されてもよい。たとえば、Ｓ１’インターフェースプロシージャは、３４０および３４５で提供されてもよい。Ｓｘｘインターフェースプロシージャは、たとえばＨ（ｅ）ＮＢの間および／またはＨ（ｅ）ＮＢとマクロネットワークとの間などの初期セッション確立、ベアラ変更、および／またはモビリティをサポートするものであってもよい。

Ｈ（ｅ）ＮＢとＬＧＷとの間のトンネルは、たとえばハンドオーバの場合などに、確立され、変更され、解放され、および／または、再確立されてもよい。Ｈ（ｅ）ＮＢとＬＧＷとの間のトンネルが確立され、変更され、解放され、および／もしくは、再確立されるときに、ＣＮが関わってもよく、または、関わらなくてもよい。ＵＥは、ＭＮＯ ＣＮおよびＬＩＰＡ／ＳＩＰＴＯローカルネットワークへの同時接続を有してもよく、ＨＯをそのような状況でどのように処理することができるのかを、本明細書で説明する。たとえば、メッセージが交換されてもよく、および、関連付けられたパラメータが定義されてもよい。これらのプロシージャは、Ｈ（ｅ）ＮＢ ＧＷにより、または、Ｈ（ｅ）ＮＢ ＧＷによらずに動作してもよい。

下記で説明するのは、図３でたとえば３４０および３４５に示されているように使用することができる、Ｓ１’プロシージャなどのＳｘｘプロシージャである。制御プレーンシグナリングベアラは、ＬＧＷトランスポートレイヤアドレスを使用して作成されてもよい。Ｈ（ｅ）ＮＢは、所定のＳＣＴＰ宛先ポート番号を有するＬＧＷに対してＳＣＴＰアソシエーションを確立してもよい。Ｈ（ｅ）ＮＢは、ハンドシェークメッセージをＬＧＷと交換して、両端がシグナリングを開始し、および／または、データパケット交換を実行する準備ができていることを保証してもよい。Ｈ（ｅ）ＮＢからＬＧＷへのＤＬ ＴＥＩＤ転送に対するサポートがあってもよい。たとえば、ＵＴＲＡＮでは、ＬＧＷおよびＨＮＢは、たとえば初期化メッセージおよび／または必要なパラメータを含むＩＵＰフレームプロトコル制御メッセージを交換してもよい。さらに、ＬＧＷは、Ｈ（ｅ）ＮＢトランスポートレイヤアドレスを獲得してもよい。トンネル確立／定義が完了されることになるために、Ｈ（ｅ）ＮＢは、ＬＧＷトランスポートレイヤアドレスおよび／またはＴＥＩＤ（アップリンクＴＥＩＤ）を知っていてもよい。Ｈ（ｅ）ＮＢトランスポートレイヤアドレスは、ＬＧＷに知られてもよい。これは、たとえばＳ１／Ｉｕ／ＩｕｒｈインターフェースまたはＳｘｘインターフェースを上で交換されてもよい。

下記で説明するのは、図３でたとえば３７０および３６０に示されているように使用することができる、Ｓ１（Ｉｕ／Ｉｕｒｈ）プロシージャである。ＬＧＷが、コアネットワークによって選択されるときに、ＬＧＷトランスポートレイヤアドレスＩＥが、Ｅ＿ＲＡＢセットアップ要求（E_RAB SETUP REQUEST）またはＲＡＢ割当要求（RAB ASSIGNMENT REQUEST）に含まれてもよい。複数のアドレスが、ＣＮから提供されてもよい。たとえば初期ＵＥメッセージ、初期コンテキストセットアップ応答（INITIAL Context setup response）、ＵＬ ＮＡＳトランスポートメッセージ、または任意の他の同等のメッセージにおいて、Ｈ（ｅ）ＮＢは、ＣＮに対するＤＬ ＴＥＩＤを提供してもよい。

下記で説明するのは、ベアラ変更プロシージャである。ベアラ変更プロシージャは、Ｓｘｘ（たとえば、Ｓ１’）固有および／またはＳ１（Ｉｕ／Ｉｕｂ）固有であってもよい。たとえば、ベアラ変更プロシージャは、図３の３４０、３４５、および３７０で使用されてもよい。

Ｓｘｘプロシージャは、ＬＧＷとＨ（ｅ）ＮＢとの間でベアラ変更プロシージャをサポートしてもよい。Ｓｘｘプロシージャは、３４０および３４５で使用されてもよい。このことは、ＳＧＷおよび／またはＭＭＥ（たとえば、Ｈ（ｅ）ＮＢ ＧＷの中央の）をバイパスする形式であってもよい。代わりに、ＬＧＷは、Ｈ（ｅ）ＮＢに直接に向かうベアラ調停プロシージャ（bearer mediation procedure）をトリガしてもよく、および、並列に、そのようなプロシージャの通知をサービングＧＷおよび／またはＭＭＥに送信してもよい。そのようなプロシージャをサポートして、ベアラ変更要求／応答またはベアラ更新要求／応答などのメッセージが、Ｈ（ｅ）ＮＢとＬＧＷとの間で交換されてもよい。

Ｓ１／Ｉｕ／Ｉｕｂは、ベアラ変更プロシージャをサポートしてもよい。たとえば、初期セッション確立に対して説明されたプロシージャに加えて、以下のプロシージャが、モビリティをサポートしてＳｘｘインターフェース上で定義されてもよい。Ｅ−ＲＡＢ／ＲＡＢが削除され、および／または、追加されるときに、ＭＭＥは、各Ｅ−ＲＡＢ／ＲＡＢに対する更新されたＴＥＩＤをＨ（ｅ）ＮＢに通信してもよい。代わりに、ＭＭＥは、新たに削除または追加されたＥ−ＲＡＢ／ＲＡＢのＴＥＩＤおよび／または相関ＩＤをＨ（ｅ）ＮＢに示してもよい。たとえば、Ｅ−ＲＡＢ変更要求／応答（E-RAB MODIFY REQUEST/RESPONSE）などのメッセージが使用されて、情報を交換してもよい。

アクセス制御プロシージャが提供されてもよい。アクセス制御プロシージャは、たとえば、ＣＳＧ内（intra-CSG）またはＣＳＧ間（inter-CSG）であってもよい。

ＬＩＰＡ能力のブロードキャストが使用されて、ＬＩＰＡハンドオーバを実行してもよい。ＣＳＧ内および／またはＣＳＧ間では、モビリティの間に、ソースＨ（ｅ）ＮＢは、ターゲットＨ（ｅ）ＮＢがＬＩＰＡおよび／またはＳＩＰＴＯをサポートすることを検証してもよい。ＬＩＰＡ能力は、たとえば、セルによってブロードキャストされてもよく、および／または、ＵＥ測定の一部としてソースＨ（ｅ）ＮＢに報告されてもよい。そのような能力はまた、３５０でなど、Ｘ２／Ｉｕｒインターフェース上でセルの間で交換されてもよい。Ｈ（ｅ）ＮＢ３０５などのソースＨ（ｅ）ＮＢは、メンバシップ情報検証の一部として、ＵＥ３００などのＵＥが、Ｈ（ｅ）ＮＢ３１０などのターゲットＨ（ｅ）ＮＢにおいてＬＩＰＡ／ＳＩＰＴＯサービスを有することを許可されてもよいことを検証してもよい。Ｈ（ｅ）ＮＢはまた、たとえばハンドオーバ要求メッセージの初期コンテキストセットアップ要求メッセージまたは再配置要求メッセージの間などに、コアネットワークからこの情報を受信してもよい。複数のセル（たとえば、ソースＨ（ｅ）ＮＢおよび隣接Ｈ（ｅ）ＮＢ）に関するメンバシップ情報は、Ｈ（ｅ）ＮＢとコアネットワークとの間で同時に交換されてもよい。ＬＩＰＡおよび／またはＳＩＰＴＯサービスをターゲットＨ（ｅ）ＮＢにおいて提供することができないソースＨ（ｅ）ＮＢによる判定のときに、ソースＨ（ｅ）ＮＢは、以下のアクションのうちの少なくとも１つを実行してもよい。たとえば、ソースＨ（ｅ）ＮＢは、ＬＩＰＡおよび／もしくはＳＩＰＴＯを非アクティブ化し、ＬＩＰＡ／ＳＩＰＴＯベアラをサービスすることを継続しながら非ＬＩＰＡ／ＳＩＰＴＯトラフィックをハンドオーバし、ハンドオーバを中断し、および、ＬＩＰＡ／ＳＩＰＴＯ対応である別のＨ（ｅ）ＮＢの選択を行い、ならびに／またはＣＳＧ内ＬＩＰＡ／ＳＩＰＴＯ対応モビリティがサポートされる場合にハンドオーバを中断してもよい。

下記で説明するのは、たとえばＳ１’、Ｓ１、Ｘ２、および／またはＳ５インターフェースなど、本明細書で説明されるインターフェースの間のさまざまなインタラクションである。

本明細書で説明される実施形態は、Ｓ１’、Ｓ１、Ｘ２、および／またはＳ５のインターフェースプロシージャに影響する場合がある。たとえば、説明される実施形態は、ＬＧＷ選択がどのように実行されるのかに影響する場合がある。たとえばＨ（ｅ）ＮＢとＬＧＷとの間のセッション管理およびモビリティ管理を可能にする、Ｓ１（Ｉｕ／Ｉｕｈインターフェース）インターフェースまたはＸ２（Ｉｕｒ、Ｉｕｒｈ）インターフェースに対する影響がある場合がある。

ＬＧＷ（またはたとえばＧＧＳＮ）とＳＧＷ（またはたとえばＳＧＳＮ）との間で、呼確立の間、ベアラ変更の間、および／またはハンドオーバの間に通信が存在してもよい。ＬＧＷ（またはたとえばＧＧＳＮ）とＳＧＷ（またはたとえばＳＧＳＮ）との間にトンネル確立が存在してもよい。呼確立の間および／またはトンネル確立の間に通信が存在する場合に、コアネットワークを経由せずにセッションが確立されると、Ｈ（ｅ）ＮＢがＬＧＷと直接に通信し、および／または、データを転送することができるように、Ｓ１インターフェースまたはＸ２インターフェースに影響がある場合がある。一例にしたがって、ＬＧＷアップリンクＴＥＩＤ／相関ＩＤが、コアネットワーク（たとえば、ＭＭＥおよび／またはＳＧＳＮ／ＭＳＣ）によってＨ（ｅ）ＮＢに提供されてもよい。ＣＮからＨ（ｅ）ＮＢに提供される他のパラメータが存在してもよい。この情報は、スタンドアロンＬＧＷのコンテキストで使用されてもよい。

ＬＧＷ（またはたとえばＧＧＳＮ）とＳＧＷ（またはたとえばＳＧＳＮ）との間にトンネル確立の必要がない場合には、コアネットワークを経由せずにセッションが確立されると、Ｈ（ｅ）ＮＢがＬＧＷと直接に通信し、および／または、データを転送することできるように、Ｓ１インターフェースまたはＸ２インターフェースに対する影響がある場合がある。

ＬＧＷとＳＧＷ（またはたとえばＳＧＧＳＮ）との間の通信コンテキスト（たとえば、ＴＥＩＤ／相関ＩＤなど）が、Ｈ（ｅ）ＮＢに知られるようにしてもよい。たとえば、Ｓ１インターフェースプロシージャおよび／またはＸ２インターフェースプロシージャとＳｘｘ（図１ではＳ１’）インターフェースプロシージャとの間でインタラクションが存在してもよい。

Ｓ５プロシージャが提供されてもよい。Ｓ５プロシージャが、たとえば図３に示された３７５で使用されてもよい。Ｓ５プロシージャは、非ＬＧＷ選択関連（non-LGW selection related）である他のプロシージャを含んでもよい。ＭＭＥは、それが通常のＳＧＷであり、および／もしくは、ＴＥＩＤ情報を取得したかのように、ＬＧＷ／ＳＧＷエンティティとコンタクトし、または、既存の相関ＩＤを提供するかのいずれかの選択が与えられてもよい。ＭＭＥは、特定のＬＧＷアドレスが与えられるのか、または、キーが提供されるのかに基づいて、この判断を行ってもよい。このことは、ＭＭＥが、たとえばこのキーの特性に基づいてＬＧＷを選択することを可能にすることができる。

ＩＰ保存プロシージャ（IP preservation procedure）はまた、本明細書で説明される。たとえば、ＩＰアドレスは、加入者が中断されたサービスを有することなく、加入者がローカルネットワークの外に移動するときに保存されてもよい。ＩＰ保存は、異なるＬＧＷに接続されたＨ（ｅ）ＮＢの間でのモビリティの間、または、Ｈ（ｅ）ＮＢとマクロネットワークとの間のモビリティの間に保証されてもよい。

一実施形態にしたがって、組み合わされたＬＧＷ／ＳＧＷエンティティは、ＩＰ保存のためにＩＰ割当てを実行してもよい。たとえば、ＵＥは、ＬＧＷ／ＳＧＷエンティティからプライベートＩＰアドレスを割り当てられてもよい。このことは、ＭＭＥによって選択された（たとえば、上記で説明したプロシージャに基づいて）ＬＧＷに対応してもよい。このＬＧＷ／ＳＧＷエンティティがＵＥからメッセージを受信するときに、プライベートＵＥ ＩＰアドレスをルーティング可能なＩＰアドレスに置き換えてもよく、このことは、ネットワークアドレス変換（ＮＡＴ）によって提供される機能に類似してもよい。ＭＭＥがＬＧＷ／ＳＧＷエンティティとコンタクトするときに、ＬＧＷ／ＳＧＷエンティティは、ＭＭＥに、グローバルにルーティング可能なＩＰアドレスを提供してもよい。ＭＭＥは、ルーティング可能なＩＰアドレスを、ＨＳＳによって提供されたかのようにＰＧＷに渡してもよい。このことは、たとえば、セッション作成要求（CREATE SESSION REQUEST）メッセージを使用して行われてもよい。ＬＧＷ／ＳＧＷエンティティは、ＳＧＷ能力とＰＧＷ能力との両方を有することができるので、パブリックＩＰアドレスを割り当てることができる可能性がある。

図３を参照すると、ＳＧＷ３１５が、３９０のＳ５’インターフェースを通じてＰＧＷ３３０に接続される場合に、インバウンドハンドオーバプロシージャとアウトバウンドハンドオーバプロシージャとの両方が、ＬＧＷ／ＳＧＷエンティティでユーザ経路をアンカリングすることによって実行されてもよい。たとえば、ＳＧＷ３１５がＬＧＷ３２５に接続され、または、その一部であってもよいので、インバウンドハンドオーバプロシージャとアウトバウンドハンドオーバプロシージャとの両方が、ＳＧＷ３１５およびＬＧＷ３２５でユーザ経路をアンカリングすることによって実行されてもよい。ＬＧＷ３２５は、３５５のＳ５’インターフェースを通じてＳＧＷ３１５と通信してもよく、および、３７５のＳ５インターフェースを使用してＳＧＷ３２３と通信してもよい。ＳＧＷ３２３は、３８５のＳ１１インターフェースを使用してＭＭＥ３３５と通信してもよい。

別の実施形態では、ＩＰ割当ては、ＰＧＷ／ＬＧＷマスタ−スレーブ機構を通じて実行されてもよい。たとえば、マスタＰＧＷおよびＬＧＷ選択が実行されてもよい。マスタＬＧＷは、スレーブＬＧＷを使用してＩＰ割当てを制御してもよい。ＩＰアドレス割当てプロシージャは、ＬＧＷとマスタＰＧＷとの間で定義されてもよく、および／または、使用されてもよい。ＬＧＷの間でのモビリティの間に、ＬＧＷ（またはたとえばコアネットワークＰＧＷまたはＭＭＥにおいて指定されたエンティティ）は、モビリティがマスタＰＧＷ内（intra-master PGW）とすることができ、および、別のＩＰアドレスを割り当ててはならないことを考慮してもよい。初期ＬＧＷによって割り当てられたＩＰアドレスは、ハンドオーバプロシージャの間に、ＬＧＷの間、ソースとＨ（ｅ）ＮＢとの間、またはＬＧＷとＨ（ｅ）ＮＢとの間で交換されてもよい。

初期アタッチプロシージャの間に、デフォルトＥＰＳベアラが確立されてもよく、および、ＩＰアドレスが割り当てられてもよい。ＩＰアドレスの割当てでは、ＵＥは、静的ＩＰアドレスをプロビジョニングされてもよい。静的ＩＰアドレスは、たとえばＬＧＷアドレスから導出されてもよい。ＵＥは、セッション作成プロシージャの間に、スタンドアロンＬＧＷによって動的に割り当てられたＩＰアドレスを割り当てられてもよい。

スタンドアロンＬＧＷが、たとえばＨ（ｅ）ＮＢ ＧＷ、企業ＧＷ、および／またはＡＮＤＳＦなどの他のノードとインタラクトするときに対し、シナリオおよびアーキテクチャが本明細書で説明される。たとえば、企業シナリオで、ＬＧＷは、コアネットワークエンティティ（たとえば、ＭＭＥ）に登録してもよい。企業ＧＷは、オペレータではなくプライベートホストによって配置されてもよい。ＬＧＷは、ＣＮに登録してもよく、および、それ自体を認証してもよい。

図４は、ＬＧＷの使用を通じてローカルＩＰネットワークへのアクセスを提供することができる通信ネットワークのブロック図を示す。図４に示されるように、ＬＩＰＡ接続は、パケットデータネットワークゲートウェイＰＤＮ ＧＷ（またはＧＧＳＮ）に類似する機能を有するローカルゲートウェイ（ＬＧＷ）の使用によって達成されてもよく、ここで、ＬＧＷは、ＨｅＮＢ上で同一位置に配置されてもよい。ＬＧＷがＨｅＮＢと同一位置に配置された状態で、ＵＥがＨｅＮＢのカバレージの外に移動するときに（アイドルモードまたは接続モードのいずれかで）、ＬＩＰＡ接続は非アクティブ化されてもよい。ＵＥが、接続モードであり、および、別のセルへのハンドオーバ（ＨＯ）を実行しようとしているときに、ＨｅＮＢは、そのＨＯに関してＬＧＷに通知してもよく、それによって、ＬＧＷを、ＬＩＰＡ ＰＤＮ接続を非アクティブ化することができる。このシグナリングは、ＭＭＥに対して行われてもよい。ＬＩＰＡ ＰＤＮ接続が非アクティブ化された後に、ＵＥは、別のセルにハンドオーバされてもよい。ＨＯの間に、ＭＭＥが、ＬＩＰＡベアラ／ＰＤＮ接続が非アクティブ化されなかったことを知る場合には、ＭＭＥは、ＨＯをリジェクト（reject）してもよい。

図５は、ＬＧＷがＨ（ｅ）ＮＢと同一位置に配置される通信ネットワークのブロック図を示す。図６は、ユーザ機器（ＵＥ）が、Ｈ（ｅ）ＮＢにハンドオフされながらＬＧＷヘの接続を維持することができる通信ネットワークのブロック図を示す。スタンドアロンＬＧＷが使用されて、ＵＥがＨｅＮＢの間を移動するときに、ＬＩＰＡ ＰＤＮ接続の継続性を許可することができる。スタンドアロンＬＧＷは、ＨｅＮＢ上で同一位置に配置されないＬＧＷであってもよい。このことは、たとえば、ＬＧＷが、同一のＬＧＷに接続できる複数のＨｅＮＢによって使用されることを許可するために行われてもよい。ＬＩＰＡ ＰＤＮ接続を有するＵＥは、そのＬＩＰＡ ＰＤＮ接続を維持しながら、これらのＨｅＮＢにまたがって移動してもよく、これらのＨｅＮＢは、ＨｅＮＢサブシステムと称される場合がある。ＵＥがＬＧＷに接続するすべてのＨｅＮＢのカバレージの外に移動するときなど、ＵＥが、ＨｅＮＢサブシステムから完全に外に移動する場合には、ＬＩＰＡに対するＵＥのＰＤＮ接続が非アクティブ化されてもよい。

図７は、ネットワークオペレータがパブリックデータネットワーク（ＰＤＮ）ゲートウェイ（ＧＷ）を選択して、トラフィックをオフロードすることができる通信ネットワークのブロック図を示す。図７に示されるように、ＳＩＰＴＯ（選択的ＩＰトラフィックオフロード）は、ネットワークオペレータが、トラフィックをインターネットにオフロードするのに使用することができるＰＤＮ ＧＷを選択するときに、実行されてもよい。このことは、たとえば、ＵＥの物理位置またはＩＰトポロジ位置がそれを行うのに好ましいものであるときに、コアネットワークの（ＣＮ）ＰＤＮ ＧＷとは異なるＰＤＮ ＧＷを使用することを可能にするために行われてもよい。ＳＩＰＴＯは、ＵＥの無線接続がｅＮＢまたはＨｅＮＢを介して取得されるかに関わらず、実行されてもよい。別のＰＤＮ ＧＷの選択は、ＵＥに知られない場合があり、および、Ｌ−ＰＧＷへのＵＥのトラフィックのオフロードは、ユーザのサービス経験を悪化させる場合がある。インターネットへのユーザデータのオフロードは、下記で示すようにＨｅＮＢサブシステム上にあるＬＧＷを介して行われてもよい。

図８は、ＬＧＷを使用してユーザデータをオフロードすることができる通信ネットワークのブロック図を示す。別の実施形態にしたがって、ＳＩＰＴＯおよびＬＩＰＡトラフィックは、ＬＧＷなどのＨ（ｅ）ＮＢサブシステムで区別されてもよい。図８に示されるように、ＳＩＰＴＯとＬＩＰＡとの両方は、Ｈ（ｅ）ＮＢサブシステムにおいて提供されてもよい。８２０では、ＵＥ８０５は、ローカル企業ＩＰサービス８４０へのローカル接続を有してもよく、および、インターネット８４５への非ローカル接続を有してもよく、このインターネット８４５への非ローカル接続は、ＬＧＷ８２５からトラフィックをオフロードすることによって使用可能とされてもよい。ＬＧＷ８２５は、ローカルトラフィックをインターネットトラフィックから区別してもよい。ＬＧＷ８２５は、１つのＰＤＮ接続をＬＩＰトラフィックとインターネットトラフィック（すなわち、ＳＩＰＴＯ）との両方に対して使用することができるときに、生じる可能性がある問題にも対処する。

下記で説明するのは、ＬＧＷ８２５などのＬＧＷでＳＩＰＴＯをＬＩＰＡトラフィックから区別するためのさまざまな方法である。これらの方法は、任意の組合せで任意のシステムにおいて使用されてもよい。さらに、下記の例は、ＭＭＥ８３０およびＳＧＷ８３５などのＭＭＥ／ＳＧＷを使用して与えられるが、これらは、たとえばＲＮＣまたはＨ（ｅ）ＮＢ ＧＷなど、通信システムにおけるＳＧＳＮまたは他のノードに適用することができる。

ＬＧＷ８２５は、ＳＩＰＴＯをＬＩＰＡトラフィックから区別するためにＰＤＮ接続を使用してもよい。ＵＥ８０５などのＵＥは、ＬＩＰＡおよび／またはＳＩＰＴＯ対して専用ＰＤＮ接続を使用してもよい。専用ＰＤＮ接続を、ＡＰＮ値とともに使用することは、ＬＧＷがＳＩＰＴＯをＬＩＰＡトラフィックから区別することを可能にする。たとえば、ＬＧＷ８２５は、ＵＥ８０５によって使用される専用ＰＤＮ接続およびＡＰＮ値を使用して、ＳＩＰＴＯをＬＩＰＡトラフィックから区別することができる。ＵＥ８０５が、ＡＰＮ値を含まない場合、または、ＵＥ８０５がＳＩＰＴＯもしくはＬＩＰＡにつながるＡＰＮ値の情報を有しない場合には、ＭＭＥ８３０および／またはＳＧＷ８３５は、ＰＤＮ接続がＳＩＰＴＯまたはＬＩＰＡのいずれかについて確立されていることをＬＧＷ８２５に通知してもよい。このことは、たとえば、ＳＧＷ８３５からＬＧＷ８２５に送信することができるセッション作成要求（Create Session Request）において行われてもよい。これは、ＭＭＥ８３０からＳＧＷ８３５に送信できるセッション作成要求におけるインジケーションによってトリガされてもよい。ＭＭＥ８３０が、ＬＩＰＡまたはＳＩＰＴＯに対してセットアップされることになるＰＤＮを知っている場合には、ＭＭＥ８３０は、このインジケーションをＳＧＷ８３５に提供してもよい。ＳＧＷ８３５は、当該インジケーションをＬＧＷ８２５に提供してもよい。ＬＧＷ８２５に到着するトラフィックは、ＳＩＰＴＯまたはＬＩＰＡのいずれかに属することが知られていてもよい。ＭＭＥ８３０は、この情報を、両方のエンティティの間のシグナリングを介してＬＧＷ８２５に提供してもよい。

ＬＧＷ８２５は、ＩＰアドレッシング情報に基づいて、ＬＩＰＡまたはＳＩＰＴＯとしてトラフィックを識別してもよい。たとえば、宛先ＩＰアドレスが、ローカル宛先のＩＰアドレス（たとえば、プライベートＩＰアドレス）である場合には、ＬＧＷ８２５は、このトラフィックをＬＩＰＡトラフィックとして処理してもよく、および、このトラフィックをローカルネットワークにルーティングしてもよい。代わりに、宛先ＩＰアドレスが、インターネットにおけるノードのアドレス（たとえば、パブリックＩＰアドレス）である場合には、ＬＧＷは、関連するＩＰパケットをインターネットにルーティングしてもよい（すなわち、トラフィックはＳＩＰＴＯである）。たとえば、ＬＧＷ８２５は、関連するＩＰパケットをインターネット８４５にルーティングしてもよい。

ＵＥ８０５は、ＩＰトラフィックのフローがＬＩＰＡまたはＳＩＰＴＯとすることができることを、ＭＭＥ８３０、ＳＧＷ８３５、および／またはＬＧＷ８２５に示してもよい。このことは、トラフィックがたとえばＬＩＰＡまたはＳＩＰＴＯになるように、確立されたベアラを変更してパケットフィルタをインストールすることによって行われてもよい。たとえば、パケットフィルタは、ＩＰのあるフローがＬＩＰＡまたはＳＩＰＴＯであることのインジケーションを、ＩＰアドレスのタイプに基づいて作成してもよい。ＬＩＰＡまたはＳＩＰＴＯに対するインジケーションは、任意のＮＡＳセッション管理メッセージの一部であってもよい。たとえば、プロトコル構成オプションＩＥ（Protocol Configuration Options IE）は、特定のフローがＬＩＰＡまたはＳＩＰＴＯであるのかに関する情報を含んでもよい。ＵＥ８０５は、たとえば、各ＮＡＳセッション管理シグナリングメッセージにおいてこの情報を提供してもよい。ＵＥ８０５は、たとえば宛先ＩＰアドレスに関する情報を提供することができる、上位レイヤ（たとえば、アプリケーションレイヤ）との情報交換などによって、この情報を取得してもよい。宛先ＩＰアドレスに関する情報は、たとえば、宛先アドレスがプライベートまたはパブリックであるかを示してもよい。ＵＥ８０５は、ＡＮＤＳＦからあるポリシーを使用して、あるフローがＬＩＰＡまたはＳＩＰＴＯトラフィックとされることを示すかを知ることができる。このことは、期待されるＱｏＳ、アプリケーションのタイプ、またはアプリケーションの特性などのオペレータポリシーに基づいてもよい。たとえば、ＵＥ８０５は、リアルタイム対非リアルタイムトラフィックを使用してもよい。ＵＥ８０５からのインジケーションは、ＭＭＥ８３０および／またはＳＧＷ８３５によってＬＧＷ８２５に転送されてもよく、それによって、ＩＰフローがＬＩＰＡまたはＳＩＰＴＯとして識別されてもよい。

ＵＥ８０５は、異なるサービスに対する異なるベアラを使用してもよい。たとえば、ＵＥ８０５は、ＬＩＰＡトラフィックに対する専用ベアラとＳＩＰＴＯトラフィックに対する異なる専用ベアラとを使用してもよい。ＵＥ８０５は、ＬＩＰＡトラフィックおよびＳＰＩＴＯトラフィックが同一のＱｏＳレベルを要求する場合であっても、異なる専用ベアラを使用してもよい。ベアラが確立されると、ＵＥ８０５は、確立されており、または、変更されているベアラが、ＬＩＰＡトラフィックまたはＳＩＰＴＯトラフィックに対するものであることを示すことができるインジケーションを、ＮＡＳセッション管理メッセージ（たとえば、ＥＰＳベアラリソース割当要求（EPS Bearer Resource Allocation Request）メッセージまたはＥＰＳベアラ変更要求（EPS Bearer Modification Request）メッセージ）において提供してもよい。このインジケーションは、インタラクションに基づいてもよく、または、アプリケーションレイヤからの受信された情報に基づいてもよい（たとえば、特定のアプリケーション、または、アプリケーションが、ベアラまたはＩＰフローがＬＩＰＡトラフィックまたはＳＩＰＴＯトラフィックに対して確立されていることを示してもよい）。ＭＭＥ８３０またはＳＧＷ８３５は、これを、変更ベアラ要求（Modify Bearer Request）メッセージなど、これらのノードの間で交換することができるメッセージにおいて、ＬＧＷ８２５に転送してもよい。このインジケーションによって、ＬＧＷ８２５は、ＩＰフローまたはベアラを、ローカルに（すなわちＬＩＰＡトラフィック）またはインターネットへ（すなわち、ＳＩＰＴＯトラフィック）のいずれかでルーティングしてもよい。

上記で説明したように、図８は、ＬＧＷを使用してユーザデータをオフロードすることができる通信ネットワークのブロック図を示す。この通信ネットワークは、ＬＩＰＡおよびＳＩＰＴＯを許可してもよい。ＬＧＷが使用されて、ローカルＩＰネットワーク（ＬＩＰＡ）にアクセスしてもよく、および、同一のＬＧＷを介してＵＥからのデータをインターネットにオフロードしてもよい。

下記の説明は、ＬＩＰＡモビリティおよびＳＩＰＴＯサービス継続性に関する。たとえば、下記の説明は、ＬＩＰＡモビリティおよびＳＩＰＴＯサービス継続性を達成する方法およびシステムを議論するものである。

ＬＩＰＡ ＰＤＮ接続を有するＵＥに対して、ターゲットＨｅＮＢへのハンドオーバが発生することになる場合に、ソースＨｅＮＢは、同一のＬＧＷに接続することができるターゲットＨｅＮＢを選択してもよく、当該ＬＧＷでは、ＬＩＰＡ ＰＤＮ接続がセットアップされてもよい。さらに、ＵＥは、ＵＥが無線の観点からターゲットＨｅＮＢにアクセスすることを可能にする、ＣＳＧアクセスサブスクリプションを有してもよい。このことは、ターゲットセルによってブロードキャストすることができるＣＳＧ ＩＤに基づいてもよい。このことはまた、ＵＥがオペレータＣＳＧリスト（ＯＣＬ：Operator CSG List）または許可されたＣＳＧリスト（ＡＣＬ：Allowed CSG List）によってキャンプオン（camp on）することを許可することができる、潜在的なＣＳＧ（ＨｅＮＢ）のＩＤに基づいてもよい。したがって、ソースは、ＵＥがターゲットＨｅＮＢ上で許可され得るかどうかを判定する必要がある場合があり、および、ＬＩＰＡ ＰＤＮ接続を提供することができる同一のＬＧＷに接続することができるターゲットセルを判定する必要がある場合がある。このことはまた、ＳＩＰＴＯにも適用可能であってもよい。

ＵＥが、ターゲットＨｅＮＢにアクセスすることを許可され、および、そのＨｅＮＢからＬＧＷへの接続が存在してもよい場合に、ＵＥは、サービスの観点から、そのＨｅＮＢ（ＣＳＧ）からＬＩＰＡサービスにアクセスすることを許可されない場合がある。これは、オペレータポリシーまたはＵＥのサブスクリプション情報によって定義されてもよい。そのような情報は、ＭＭＥに対して利用可能であってもよく、および、このノードは、ＬＩＰＡモビリティ／ＳＩＰＴＯサービス継続性が発生し得ない場合に、あるＨＯが発生することを許可しなくてもよい。

ルールが確立されることによって、ＨｅＮＢサブシステム内のＨＯが、ＬＩＰＡモビリティ／ＳＩＰＴＯサービス継続性を保証しなければならない場合がある。ターゲットＨｅＮＢは、ＬＧＷに接続してもよく、および、ＵＥは、そのセルからＣＳＧおよびＬＩＰＡへのアクセスを有してもよい。しかし、ターゲットＨｅＮＢは、負荷状態に起因して、あるベアラを許可しない場合がある。許可されないベアラがＬＩＰＡベアラである場合には、ＨＯは進行してもよく、または、取り消されてもよい。

ターゲットＨｅＮＢは、ＬＩＰＡトラフィックと非ＬＩＰＡトラフィックとの間で区別することができる。このことは、たとえば、非ＬＩＰＡトラフィックがＣＮを介して提供される場合に、実行されてもよい。ターゲットＨｅＮＢがＬＩＰＡベアラを許可することができない場合には、ターゲットＨｅＮＢは、どのベアラがＬＩＰＡ ＰＤＮ接続に関係するのかを知る必要がある場合がある。これらのベアラは、ターゲットで維持されない場合がある。

ＭＭＥは、ＬＩＰＡ ＰＤＮ接続が、ＨＯ開始の前に解放されない場合があることを知る場合に、ＨＯをリジェクトしてもよい。ＭＭＥは、Ｒ１１シナリオにおいてＬＩＰＡセッションに対するＨＯをリジェクトしないように、Ｒ１０のＬＩＰＡモビリティシナリオとＲ１１のＬＩＰＡモビリティシナリオとの間で区別することができる。

ＬＩＰＡ／ＳＩＰＴＯユーザプレーンおよびリソースは、ＨＯの間に処理されてもよい。たとえば、ＬＩＰＡサービスを維持することができるところから、ターゲットセルへのＨＯの後に、データ経路をＬＧＷからターゲットＨｅＮＢに切り替える必要がある場合がある。さらに、ＨＯの間に、ＬＧＷがいまだに、ＤＬパケット（ＬＩＰＡ関連パケットまたはＳＩＰＴＯ関連パケット）を受信している場合がある。ＬＧＷ、ソースＨｅＮＢ、またはＬＧＷとソースＨｅＮＢとの両方が、バッファリングを実行する場合がある。ＨＯの後に、ノードが、ＬＧＷとソースＨｅＮＢとの間でリソースの解放を開始する場合がある。

ＨｅＮＢサブシステムから外への接続されたモードのモビリティに対して、ＬＧＷ（ＬＩＰＡまたはＳＩＰＴＯ）からのダウンリンク（ＤＬ）パケットは、ＨＯが進行中である間に処理されてもよい。たとえば、ＬＧＷなどのノードが、これらのパケットをバッファリングしてもよい。パケットは、ターゲットＨｅＮＢに転送されてもよい。

トンネルエンドポイントＩＤ（ＴＥＩＤ：tunnel endpoint ID）は、ＬＧＷとＨｅＮＢとの間で使用されてもよい。ＴＥＩＤは、２つのノードの間の（すなわち、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷトラフィックに対して）直接経路を提供してもよい。

複数のＬＧＷおよびＨｅＮＢが存在する場合がある。ＵＥが、アイドルモードである間にページングされる場合に、ＵＥは、ＨｅＮＢからのページングに応答してもよい。ＨｅＮＢは、ＵＥがＬＩＰＡ ＰＤＮ接続を有することができるＬＧＷに接続されていなくてもよい。ＨｅＮＢはまた、トラフィックをオフロードするのにＵＥが使用することができるＬＧＷに接続されていなくてもよい。ユーザが、任意のＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷトラフィック／セッションをアクセプトすることを望まない場合もある。

ＬＩＰＡに対するＲｅｌ−１０展開において、ＬＩＰＡ ＰＤＮ接続は、ＬＩＰＡモビリティの欠如に起因してハンドオーバされない。Ｒｅｌ−１０におけるハンドオーバでは、ソースＭＭＥは、ＬＩＰＡ ＰＤＮ接続が解放されているかをチェックする。それが解放されておらず、および、ハンドオーバがＳ１ベースのハンドオーバまたはＲＡＴ間ハンドオーバ（inter-RAT handover）である場合には、ソースＭＭＥは、ハンドオーバをリジェクトしてもよい。ＬＩＰＡ ＰＤＮが解放されておらず、および、ハンドオーバがＸ２ベースのハンドオーバである場合には、ＭＭＥは、ターゲットＨｅＮＢに経路切替え要求障害（Path Switch Request Failure）メッセージを送信してもよい。ＭＭＥは、ＭＭＥによって開始されたデタッチプロシージャで説明されるように、ＵＥの明示的デタッチを実行する。

Ｒｅｌ−１０において、ＭＭＥは、ＬＩＰＡ ＰＤＮ接続／ベアラが解放されていないことを検出する場合に、ＨＯを常にリジェクトする。しかし、ＵＥは、一方はＬＩＰＡに対し、他方は非ＬＩＰＡセッションに対する２つのＰＤＮ接続を有する場合がある。したがって、ＨＯをリジェクトすることは、特にＸ２ベースのＨＯに対して、ＵＥのＲＲＣ接続のとり得る解放をすることを暗示することになるであろう。この場合に、非ＬＩＰＡセッションおよび他のユーザ経験は、悪影響を受ける場合がある。

実施形態は、ＬＩＰＡおよび／またはＳＩＰＴＯモビリティを保証することができる。ソースＨｅＮＢは、ＬＩＰＡセッションまたはＳＩＰＴＯセッションが存在するときにはいつでも、ルールを使用することができる。これらのルールは、ＨｅＮＢにおいて構成されてもよく、または、ＭＭＥによってもしくはＯ＆Ｍプロシージャを介してのいずれかで提供されてもよい。これらのルールはまた、ユーザサブスクリプションによって促進（drive）されてもよい。たとえば、いくつかのユーザが、ＨｅＮＢサブシステム内のターゲットＨｅＮＢに対するＬＩＰＡモビリティを保証することができるサブスクリプションを有してもよく、他のユーザは、そのＨｅＮＢサブシステム内の選択されたＨｅＮＢからのＬＩＰＡサービスにアクセスすることを許可されてもよい。実施形態では、ＨｅＮＢは、ＨｅＮＢサブシステム内でのＬＩＰＡおよび／またはモビリティを保証することができ、ＬＩＰＡモビリティのみを保証することができ、ＳＩＰＴＯモビリティのみを保証することができ、または、その任意の組合せを保証することができる。ターゲットＨｅＮＢが、ＬＧＷに接続し、および、ＵＥがそのＨｅＮＢにアクセスすることを許可される場合に、ＨｅＮＢは、最初にＳＩＰＴＯベアラを優先する（すなわち、許可する）ことができ、最初にＬＩＰＡベアラを優先する（すなわち、許可する）ことができ、または、ユーザ合意に基づいて、もしくは、サブスクリプション情報に基づいてＳＩＰＴＯＰベアラもしくはＬＩＰＡベアラのいずれかの優先順位を判定することができる。

ルールが、ソースＨｅＮＢ、ターゲットＨｅＮＢ、またはＭＭＥによって実施されてもよい。ＭＭＥによって提供される場合に、プロビジョニングが、任意のＳ１−ＡＰメッセージを介して行われてもよい。さらに、既にソースＨｅＮＢで利用可能である場合に、ルールがプロビジョニングされて、ターゲットが任意の後続のＨＯをどのように処理するべきかを知るために、ＨＯの間にターゲットに提供されてもよい。

ＬＩＰＡモビリティを行うために、満たされる必要がある条件がある場合がある。たとえば、ＵＥは、ターゲットＨｅＮＢにアクセスすることを許可される必要がある場合がある（ＣＳＧサブスクリプション情報に基づいて）。ターゲットＨｅＮＢは、該当のＵＥに対してＬＩＰＡ ＰＤＮ接続を提供する同一のＬＧＷに接続することが必要である場合がある。ＵＥは、ターゲットＨｅＮＢからＬＩＰＡサービスを取得することを許可される必要がある場合がある。この条件は、ソースＨｅＮＢ、ターゲットＨｅＮＢ、ＭＭＥ、またはＬＧＷでチェックされてもよい。ＭＭＥは、識別された条件、ソースＨｅＮＢ、ＬＧＷ、およびターゲットＨｅＮＢに関連した情報などの情報を提供してもよい。ＬＧＷはまた、ＭＭＥの代わりにまたはこれとの組み合わせで、ソース／ターゲットＨｅＮＢにそのような情報を提供してもよい。

そのような情報のプロビジョニングは、システム上で許可することができるＵＥに対して行われてもよい。このことは、これらのＵＥのいくつかがまだ登録されていない場合であっても行うことができる。代わりに、そのような情報は、ＰＤＮ接続が確立されるときに、または、ＵＥがＨｅＮＢサブシステムに、もしくは当該サブシステムの外に移動するときに、あるノードから別のノードに提供されてもよい。

条件およびサービスルールは、ソースＨｅＮＢによって実施されてもよい。ソースＨｅＮＢは、利用可能な情報を使用して、ある条件を満たすことができるターゲットＣＳＧを選択してもよい。たとえば、ソースＨｅＮＢは、ターゲットＣＳＧを選択してもよく、それによって、ＵＥがターゲットＨｅＮＢにアクセスできるようにしてもよく、ターゲットＨｅＮＢは、ＵＥに対してＬＩＰＡ ＰＤＮ接続を提供する同一のＬＧＷに接続してもよく、および、ＵＥは、ターゲットＨｅＨＢからＬＩＰＡサービスを取得することを許可されてもよい。代わりに、ソースＨｅＮＢは、ＨＯに対するトリガの時に、ＭＭＥまたはＬＧＷを調査（probe）して、そのような情報を取得してもよい。したがって、ソースＨｅＮＢは、ＬｌＰＡおよび／またはＳＩＰＴＯサービス継続性を保証することができるターゲットＨｅＮＥＢを選択してもよい。ソースＨｅＮＢはまた、ターゲットＨｅＮＢを選択するときに、サービスルールを考慮してもよい。加えて、ソースＨｅＮＢは、特定のＨｅＮＢ上のＵＥから測定を要求して、無線接続がＬＩＰＡまたはＳＩＰＴＯサービスを継続するのに十分であることを保証することができる。ＵＥまたはネットワークは、ＬＩＰＡおよび／またはＳＩＰＴＯのサービス継続性を提供することができるターゲットＨｅＮＢへのＨＯを有利にするために、測定にバイアスを適用してもよい。したがって、ソースＨｅＮＢは、ＵＥを別のＨｅＮＢにハンドオーバする前に、ＵＥがターゲットＣＳＧにアクセスすることを許可されてもよいことを考慮してもよく、ターゲットＨｅＮＢは、ＬＩＰＡ ＰＤＮ接続が確立されるＬＧＷと接続してもよく、および、ＵＥは、ターゲットＨｅＮＢからのＬＩＰＡサービスを得ることを許可されてもよい。ソースはまた、ネットワークオペレータポリシーに基づいて、これらの条件のサブセットを考慮してもよく、または、検証してもよい。ソースＨｅＮＢは、これらの条件のすべてもしくはサブセットが満たされるＨｅＮＢセルを選択してもよい。代わりに、ＵＥの無線状態が、ＨＯが必要とされるものである場合に、ソースＨｅＮＢは、これらの状態のすべてもしくはサブセットを無視してもよい。さらに、ソースＨｅＮＢは、上記定義されたサービスルールに関わらず、非ＬＩＰＡベアラのＨＯを実行すると決定してもよい。たとえば、サービスルールは、できる限りＬＩＰＡモビリティを達成するように定義されてもよいが、これが要求されるものでなくてもよい。ソースＨｅＮＢは、ＬＧＷまたはＭＭＥを調査して、ＨＯ開始の際に検証される必要がある条件またはルールのサブセットについて発見してもよい。

サービスルールに依存して、ソースＨｅＮＢは、ＭＭＥまたは個々の潜在的なターゲットＨｅＮＢを調査して、ある条件に関する情報を要求してもよい。たとえば、ターゲットＨｅＮＢが調査されて、それが特定のＬＧＷに接続されるかどうかを知ることができる。ターゲットＨｅＮＢは、特定のＬＧＷへの接続が要求される場合であっても、それが接続されるＬＧＷに関する情報を提供してもよい。そのような情報はまた、ＨＯの間にＨｅＮＢの間で提供されてもよい。これは、ＭＭＥを介して行われてもよい。たとえば、ターゲットＨｅＮＢが、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷとすることができるベアラをリジェクトする場合であっても、ターゲットはいまだに、これらのＬＧＷのアドレッシング情報とともに、それが接続するＬＧＷに関する情報を提供してもよく、または、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷに関連するすべての他の情報を提供してもよい。

潜在的なターゲットＨｅＮＢがいかなる理由に対してＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷサービス継続性を維持するのに使用されることがないことを、ソースが知る場合には、ソースＨｅＮＢは、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラを含めずにＨＯを開始してもよい。Ｒ１０とは異なり、一実施形態では、ソースＨｅＮＢは、ＨＯに関して進行する前に、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラ／ＰＤＮ接続の解放を待つ必要がない場合がある。たとえば、ＨｅＮＢは、ＵＥに対する既存のＩＭＳ緊急呼出が存在する場合に、解放を待たなくてもよい。リソース（ベアラ／ＰＤＮ接続）は、ＭＭＥ／ＳＧＷまたはソースＨｅＮＢのいずれかによるＨＯの後に解放されてもよい。リソース解放を、本明細書でさらに説明される。

既存のＩＭＳ緊急呼出またはＵＥに関する任意の緊急ＶｏＩＰ呼出が存在する場合に、ソース／ターゲットＨｅＮＢまたはＭＭＥ／ＳＧＷは、サービスルールに関わらず、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラをハンドオーバしなくてもよい。このことは、たとえば、ＨＯに対する遅延および緊急呼出の潜在的なドロップ（drop）を回避するために行われてもよい

条件およびサービスルールは、ターゲットＨｅＮＢによって実施されてもよい。ソースＨｅＮＢは、いかなる条件に対してチェックしなくてもよく、および、ＵＥからの測定報告に基づいて、最良のターゲットＨｅＮＢを選択してもよい。たとえば、ソースＨｅＮＢは、現在のＨＯプロシージャ、または、ある形式のバイアスされた測定に基づいて、ターゲットＨｅＮＢを選択してもよい。ソースＨｅＮＢは、条件のサブセットに対してチェックしてもよく、および、他の条件がターゲットＨｅＮＢによって実施されることにしてもよく、または、検証されることにすることができる。たとえば、ソースＨｅＮＢは、ＣＳＧアクセスチェックを実行してもよく、または、ターゲットがＬＧＷに接続できるかを判定してもよい。任意の使用可能な情報を使用して、または、ＨＯ要求を受信した後にＭＭＥを調査することによって、ターゲットＨｅＮＢは、ＬＩＰＡベアラをＨＯ時に転送することができるか否かをチェックしてもよい。ターゲットＨｅＮＢは、上記説明したものなど、すべての条件に対してチェックしてもよく、または、ソースＨｅＮＢがこれらの条件のいずれかに対するチェックを既に実行し終えている場合であっても、それらのサブセットをチェックしてもよい。ターゲットＨｅＮＢは、ソースＨｅＮＢ、ＬＧＷ、またはＭＭＥを調査して、ＨＯ開始時に検証される必要がある可能性がある条件またはルールのサブセットについて発見してもよい。

条件およびサービスルールは、ＭＭＥによって実施されてもよい。たとえば、ＭＭＥは、ターゲットＣＳＧを選択してもよく、それによってＵＥがターゲットＨｅＮＢへのアクセスを有することができ、ターゲットＨｅＮＢは、ＵＥに対するＬＩＰＡ ＰＤＮ接続を提供する同一のＬＧＷに接続してもよく、および、ＵＥは、ターゲットＨｅＮＢからＬＩＰＡサービスを取得することを許可されてもよい。ＭＭＥは、条件のすべてまたはサブセットを実施してもよい。ターゲットＨｅＮＢまたはソースＨｅＮＢに関して説明される実施形態はまた、ＭＭＥに適用されてもよい。ＭＭＥは、条件およびサービスルールに基づいて、ＨＯ要求（Ｓ１ ＨＯによる）または経路切替え要求（Ｘ２ ＨＯによる）をリジェクトしてもよい。ＭＭＥは、ＬＧＷでのＬＩＰＡまたはＳＩＰＴＯに対するＰＤＮ接続の登録時または確立時に、ＨＳＳからこの情報を取得することができる。ＬＧＷは、ノードのいずれかでこれらのルールを実施することができる。たとえば、ソースＨｅＮＢ、ターゲットＨｅＮＢ、またはＭＭＥは、ＬＧＷが調査されて、サービスルールおよび条件を取得することができる。

あるＨＯのシナリオまたはサービスルールに対して、ＭＭＥは、所与のＵＥまたはユーザに対する要求されたルールまたはサブスクリプションに合致するＨＯメッセージを変更してもよい。たとえば、ルールまたはサブスクリプションが、ユーザが所与の選択されたターゲットＨｅＮＢからＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷを受信することを許可されないことがある場合に、ＭＭＥは、ＨＯメッセージを（たとえば、Ｓ１ＡＰ上で）変更して、許可されることになる要求されたベアラから、ＬＩＰＡベアラを除去することができる。したがって、ターゲットＨｅＮＢは、それらが実際にソースによって含められたという事実を認識しない場合がある。ＭＭＥはまた、ターゲットからの応答を変更して、ＭＭＥがメッセージを変更した場合があることを示すことができる原因コードを含めることができる。原因コードはまた、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラがターゲットにおいて含まれなかった、または、許可されなかった理由を示してもよい。ＭＭＥは、変更についてターゲットに通知することができ、および、ターゲットは、説明された適当な原因コードを含めることができる。

ソースＨｅＮＢおよび／またはターゲットＨｅＮＢは、スタートアップにおいて、ＨＭＳシステムから条件またはサービスルールに関する情報をダウンロードしてもよい。ソースおよび／またはターゲットが接続することができるＬＧＷは、その情報に含まれてもよい。複数の方法が使用されて、Ｈ（ｅ）ＮＢの間でのこの情報の交換を可能にすることができる。Ｈ（ｅ）ＮＢは、Ｘ２セットアッププロシージャの間、ＥＮＢ構成更新プロシージャの間、またはＩｕｒｈライクなプロシージャの間に、この情報を交換することができる。Ｈ（ｅ）ＮＢは、ＬＧＷに登録することができ、その後、登録要求または登録応答など、登録プロシージャを通じて、同一のＬＧＷに接続された他のＨｅＮＢのリストを取得することができる。Ｈ（ｅ）ＮＢは、隣接Ｈ（ｅ）ＮＢが発見されると、ＬＧＷとＨ（ｅ）ＮＢとの間の構成転送プロシージャなどのプロシージャを使用して情報を交換することができる。

ＨｅＮＢは、ＬＧＷが接続するＰＤＮを指定することができ、または、ＬＧＷ自体を識別することができる識別をブロードキャストすることができる。すべてのＨｅＮＢが、少なくとも１つのＬＧＷに接続されている場合に、そのようなＩＤをブロードキャストすることができる。さらに、ＨｅＮＢが複数のＬＧＷに接続する場合に、これらのＬＧＷのそれぞれのＩＤがブロードキャストされてもよい。ＵＥは、ＬＧＷまたはＰＤＮに、隣接ＨｅＮＢによってブロードキャストすることができるＩＤを報告することができる。このことは、たとえば、関係する所与のＬＧＷに接続することができるターゲットＨｅＮＢを判定するために行われてもよい。ＵＥは、ＬＧＷまたはＰＤＮに、ＵＥによって提供される測定報告またはスタンドアロンＲＲＣメッセージにおいて、ＩＤを報告することができる。ＵＥがそのようなＩＤを報告する場合に、ソースＨｅＮＢは、このＩＤを使用して、ＬＩＰＡ／ＳＩＰＴＯサービス継続性を提供することができる潜在的なＨＯを決定することができる。代わりに、ＵＥは、ブロードキャスト情報に基づいて、ターゲットが同一である少なくとも１つのＬＧＷに接続されてもよいことをソースＨｅＮＢに示すことができる。これは、ＵＥが、ソースおよびターゲットでブロードキャストされるＬＧＷ ＩＤを比較することによって達成されてもよい。したがって、ＵＥは、１ビット位置を介してこのインジケーションを提供することができ、ここで、たとえば、１の値は、ターゲットＨｅＮＢがソースによってブロードキャストされるものと同一のＬＧＷに接続することを示してもよく、および、０の値は、ターゲットを問題のＬＧＷに接続しないことを示してもよい。２ビット情報要素が使用されてもよい。たとえば、１の値は、ターゲットＨ（ｅ）ＮＢがソースによってブロードキャストされたものと同一のＬＧＷに接続できることを示してもよく、２の値は、ターゲットＨ（ｅ）ＮＢがソースによってブロードキャストされたものとは異なるＬＧＷに接続することを示してもよく、および、０の値は、どのターゲットＬＧＷヘの接続もないことを示してもよい。

識別された条件またはサービスルールに関連する情報の任意のサブセットは、ＡＮＤＳＦを介してソースＨｅＮＢまたはターゲットＨｅＮＢに提供されてもよい。また、この方法が使用されて、その情報をソースＨｅＮＢ、ターゲットＨｅＮＢ、またはＭＭＥなどに中継することができるＵＥに、そのような情報が提供されてもよい。これは、ＲＲＣメッセージまたはＮＡＳメッセージを介して行われてもよい。ＵＥは、ハンドオーバの前またはハンドオーバプロセスの間に、この情報をＨｅＮＢに転送してもよい。

上記説明した実施形態に対して、ノードがＨＯをリジェクトする場合には、原因コードが、ＨＯリジェクションに対する理由を示すために含まれてもよい。たとえば、原因コードは、ターゲットＨｅＮＢがＬＧＷに接続できない理由を示してもよい。別の例として、原因コードは、サービスの観点から、ＬＧＷノードとターゲットＨｅＮＢノードとの両方が接続される場合であっても、ターゲットＨｅＮＢからＬＧＷにアクセスすることをＵＥが許可されない理由を示してもよい。原因コードは、ターゲットＨｅＮＢとソースＨｅＮＢとの間で、ターゲットＨｅＮＢとＭＭＥとの間で、またはＭＭＥとソースＨｅＮＢとの間で交換することができる任意のＳ１関連またはＸ２関連のＨＯメッセージにあってもよい。

ＬＩＰＡベアラまたはＬＩＰＡ ＰＤＮ接続をターゲットセルにおいて割り当てることができない場合であっても、ハンドオーバプロシージャは、たとえば少なくとも別の追加の非ＬＩＰＡ ＰＤＮ接続が存在するときに、ＨＯを処理しているノードによってリジェクトされなくてもよい。たとえば、Ｓ１／Ｘ２ハンドオーバプロシージャの間に、ターゲットＭＭＥが、ＬＩＰＡモビリティが許可されず、および、ＬＩＰベアラがＨＯの間に解放されなかったことを検出する場合に、ＭＭＥは、いまだに、ＨＯプロシージャをアクセプトすることができるが、非ＬＩＰＡベアラのみを許可することができる。さらに、ＭＭＥは、非ＬＩＰＡベアラが許可されてもよいことをソース／ターゲットセルに通知することができる。ターゲットセルはまた、ＬＩＰＡベアラが解放されてもよいことをソースに通知することができる。ターゲットはまた、ベアラが解放された理由に関して、ＣＮから受信してもよい原因コードを含めてもよい。ターゲットセルは、ＵＥコンテキスト解放（UE Context Release）メッセージ（Ｘ２メッセージ）、または、Ｓ１／Ｘ２ ＨＯプロシージャに対して定義されてもよい（または既存の）任意の同等のメッセージを使用して、それを行ってもよい。ターゲットセルは、ターゲットで許可されなかったベアラのリストを含めてもよい。したがって、ソースは、このインジケーション（解放されたベアラおよび／または原因コード）を使用して、たとえば許可されなかったベアラをソースでのＬＩＰＡベアラ識別と比較することによって、ＬＧＷでのリソースを解放してもよい。加えて、ＭＭＥは、ＵＥおよびＬＧＷまたはＬＧＷに接続されたソースセルに対するＬＩＰＡ ＰＤＮ接続を解放してもよい。そして、次に、ＬＧＷがＬＧＷでのその接続／リソースを解放してもよい。

たとえば、ＬＩＰＡ ＰＤＮ接続と、少なくとも追加の非ＬＩＰＡ ＰＤＮ接続とを有するＵＥを考慮すると、ＭＭＥが、問題のＵＥに対するＸ２ ＨＯプロシージャの間にターゲットセルから経路切替え要求（Path Switch Request）メッセージを受信する場合に、ＭＭＥは、ＬＩＰＡベアラが解放されたかを検証してもよい。そうではない場合には、ＭＭＥは、ＨＯをアクセプトしてもよいが、経路切替え要求肯定応答（Path Switch Request Acknowledge）メッセージにおいて、ＬＩＰＡベアラが許可され（allowed）なくてもよいこと、または、認められ（admitted）なくてもよいことをターゲットセルに示してもよい。たとえば、ＭＭＥは、これらのベアラを非アクティブ化してもよく、および、これらのベアラを、解放されることになるＩＥのＥ−ＲＡＢに含めてもよく、このＥ−ＲＡＢは、これらのベアラがターゲットセルによって許可されなくてもよいことを通知してもよい。加えて、ＭＭＥは、ＬＩＰＡ ＰＤＮ接続が解放されてもよいことを、ＬＧＷおよび／またはターゲットセルに通知してもよい。これらのノードは、ＬＩＰＡ ＰＤＮ接続に対して使用されたリソースを解放してもよい。上記説明したように、ターゲットセルはまた、ＬＩＰＡベアラなど、あるベアラの非アクティブ化に関してソースセルに通知してもよい。そのようなインジケーションを受信すると、ソースセルは、ＬＧＷでのリソースを解放してもよい。実施形態を、ＭＭＥを使用して説明されたが、同一のアクションが、他のノード、たとえばターゲットセル、またはＬＧＷなどによって行われてもよい。

ターゲットＨｅＮＢは、ＬＩＰＡベアラまたはＳＩＰＴＯベアラに関して通知されてもよい。ソースＨｅＮＢ（またはＭＭＥ）は、ベアラのどれがＬＧＷで確立されてもよいことに関するインジケーションを（潜在的な）ターゲットＨｅＮＢに提供してもよい。このインジケーションは、高レベルにあってもよく、そこでは、利用可能なベアラのサブセット（またはすべて）が、ＬＧＷで確立されるようにタグ付けされてもよい。たとえば、ＨｅＮＢからＬＧＷへの直接経路が存在してもよい。代わりに、このインジケーションは、より細かな粒度であってもよく、そこでは、各ベアラがＬＩＰＡトラフィック、ＳＩＰＯトラフィック、非ＬＩＰＡトラフィック、または非ＳＩＰＯトラフィックになるようにタグ付けされてもよい。どのベアラにもタグ付けしないことは、ターゲットＨｅＮＢによって、サービングゲートウェイ（ＳＧＷ）に対するＳ１−Ｕインターフェース上で転送されてもよいベアラと解釈されてもよい。

そのようなベアラのタグ付けが、複数の方法で行われてもよい。たとえば、すべてのアクティブベアラに対してビットマップが定義されてもよく、そこでは、１の値が、ＬＧＷに対するＬＩＰＡベアラまたはＳＩＰＴＯベアラなど、ベアラがＬＧＷに対して処理されてもよいことを示してもよい。０の値は、ベアラがＳＧＷに対して処理されてもよいことを意味してもよい。たとえば、ＬＧＷに対する、対応するベアラに対する直接経路でなくてもよい。そのようなビットマップはまた、ＬＩＰＡおよびＳＩＰＴＯに対して、またはＬＩＰＡもしくはＳＩＰＴＯに対して個別に、定義されてもよい。代わりに、すべてのベアラが、ＬＩＰＡ、ＳＩＰＴＯ、またはＣＮベアラとしてそれを識別するためにそれ自体のビットマップを有してもよい。

ターゲットは、あるベアラを許可するときに、このインジケーション（識別またはタグ付け）を考慮してもよい。たとえば、ターゲットＨｅＮＢが、当該のＬＧＷに接続しない場合に、ターゲットＨｅＮＢは、本明細書で提案される識別を使用して、ＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラを許可しなくてもよい。

代わりに、ＨｅＮＢの無線負荷が、これらのベアラのサブセットのみが許可されてもよいものである場合に、ターゲットＨｅＮＢは、上記提案された識別を使用して、ＬＩＰＡ／ＳＩＰＴＯベアラを許可してもよいが、ＣＮベアラを許可しなくてもよい。これは、たとえば、ＬＩＰＡ／ＳＩＰＴＯサービス継続性を保証することができるサービスルールに基づいて行われてもよい。

上記実施形態は、Ｓ１ハンドオーバまたはＸ２ハンドオーバ（または、ＵＴＲＡＮにおける任意の同等のＨＯシグナリング／プロシージャ）に適用される。

識別またはタグ付けはまた、Ｓ１ ＨＯの場合に、ＭＭＥによって実行されてもよい。ＭＭＥは、この情報を、ＭＭＥがターゲットセルに転送するＨＯ要求メッセージ（Ｓ１ＡＰ）に含めてもよい。ターゲットはまた、許可され、または解放されてもよい任意のベアラに対して、このタグ付けを維持してもよい。したがって、ＭＭＥまたはソースＨｅＮＢは、たとえばサービスルールがこのＵＥに対して満たされない場合に、許可されるベアラに基づいてＨＯを継続してもよく、または、中断してもよい。

ＬＧＷ内ハンドオーバ（intra-LGW handover）の場合に、ＰＤＮ接続セットアップの間に受信される相関ＩＤは、各ＬＩＰベアラに対して、ハンドオーバ要求メッセージまたは任意の他の同等のメッセージにおいてターゲットに渡されてもよい。ターゲットＨＮＢは、ハンドオーバ要求メッセージにおける関連付けられた相関ＩＤの存在に基づいて、ベアラがＬＩＰＡベアラまたは非ＬＩＰＡベアラであるのかの判定を行ってもよい。ＬＧＷ間ハンドオーバ（inter-LGW handover）の場合に、相関ＩＤがまた使用されて、ＬＩＰＡベアラを非ＬＩＰＡベアラと区別してもよい。相関ＩＤは、ＳＧＷを介する間接経路に、直接経路Ｈ（ｅ）ＮＢ⇔ＬＧＷベアラを相関させることに関する意味を有してもよい。

ＬＧＷが、ＳＩＰＴＯトラフィックからＬＩＰＡトラフィックを区別することが有用である場合もある。ＬＩＰＡベアラおよびＳＩＰＴＯベアラは、ＴＥＩＤ範囲の別個の範囲からのＴＥＩＤを割り当てられてもよい。ＬＩＰＡベアラおよびＳＩＰＴＯベアラのＴＥＩＤは、別個の登録された宛先ＴＥＩＤ値が割り当てられてもよい。たとえば、ＬＩＰＡベアラＴＥＩＤは、登録された宛先ＴＥＩＤを使用してもよく、一方、ＳＩＰＴＯベアラは、別の特定の登録された宛先ＴＥＩＤを使用してもよい。一方はＬＩＰＡベアラのマッピングに対し、他方はＳＩＰＴＯベアラのマッピングに対する、２つの別個の相関ＩＤが定義されてもよい。

ＭＭＥは、ＨＯの間にＬＧＷ展開に関して通知されてもよい。ソースＨｅＮＢ（Ｓ１ ＨＯの場合）またはターゲットＨｅＮＢ（Ｘ２ ＨＯの場合）は、ＬＩＰＡ ＰＤＮ接続を有する所与のＵＥに対して、ＨＯが、Ｒ１１展開／ＨＯシナリオにしたがってもよいことを通知してもよい。たとえば、このＨＯは、スタンドアロンＬＧＷでのシナリオ／展開に対するものであってもよい。したがって、このインジケーションで、ＭＭＥは、Ｒ１０とＲ１１とのＬＩＰＡモビリティシナリオを区別して、それによってＲ１１ ＬＩＰＡ ＨＯは、Ｒ１０に対するケースであるかのようにリジェクトされてもよい。

インジケーションは、ＨＯメッセージにおける新たなＩＥを追加するなど、明示的なインジケーションであってもよい。代わりに、ＭＭＥは、Ｒ１０に含まれなくてもよい任意の追加情報を使用して、このＬＩＰＡモビリティがＲ１１展開シナリオに対するものであると結論付けてもよい。そのような情報の例は、ＨＯメッセージ（Ｓ１またはＸ２、たとえば、ＨＯ要求（HO Request）または経路切替え要求（Path Switch Request）に含めることができるＬＧＷアドレスを含んでもよい。

図９は、ハンドオフの間のＬＧＷ展開に関してモビリティ管理エンティティ（ＭＭＥ）に通知するのに使用することができる方法を示す。ＬＧＷ能力は、近接機能（proximity function）を使用してターゲット候補Ｈ（ｅ）ＮＢで提供されてもよい。ＵＥが、Ｈ（ｅ）ＮＢのカバレージエリアに近接している場合があるときに、現在のモビリティプロシージャは、Ｈ（ｅ）ＮＢネットワークの存在をシグナリングするための近接性インジケーションメッセージの使用を含んでもよい。一実施形態では、同様のプロシージャが使用されて、Ｈ（ｅ）ＮＢの存在、および、そのＬＧＷ能力をシグナリングしてもよい。この情報は、ターゲットＨ（ｅ）ＮＢがソースと同一のＬＧＷに属してもよいかを判定するために、ソースｅＮＢ／Ｈ（ｅ）ＮＢで有用であってもよい。

たとえば、図９の９０５に示されるように、ロケーションベースのプロシージャを使用して既知の位置に入ると、ＵＥは、既知のＬＧＷに関連付けられたＣＳＧを検出するのに自律的検索機能を使用することができる。９１０では、ＵＥは、システム情報ブロック（System Information Block）を読み込んで、特定のＣＳＧに関連付けられたＬＧＷ ｉｄ、またはその代わりに、ＳＩＢをブロードキャストするＨ（ｅ）ＮＢに関連付けられたＬＧＷ ｉｄを取り出してもよい。９１５で、ＵＥが測定を報告することを求められるときに、ＵＥは、現在のＣＳＧ情報とともに、その測定が報告される候補セルに関連付けられたＬＧＷの識別を含めることができる。これによって、マクロｅＮＢに接続されたＵＥについて近接（proximity）が使用される、現在のＲ１０プロシージャとは異なり、近接機能の概念が、Ｈ（ｅ）ＮＢにも拡張されてもよい。したがって、ＵＥは、近接インジケーションをＨ（ｅ）ＮＢにも提供して、それが接続できるＬＧＷに関する周囲のＨ（ｅ）ＮＢの特性または能力をシグナリングすることができる。代わりとして、ＬＧＷ ｉｄが、周囲のＨ（ｅ）ＮＢによってブロードキャストされる場合に、Ｈ（ｅ）ＮＢ自体は、ＵＥからの報告の必要なしに、周囲のＨ（ｅ）ＮＢのＬＧＷ能力を読みとることができる。しかし、これは、Ｈ（ｅ）ＮＢが、ＵＥとＨ（ｅ）ＮＢとの両方にチューニングすることができる受信器を有することを仮定してもよい。加えて、Ｈ（ｅ）ＮＢが、Ｈ（ｅ）ＮＢ ＧＷに接続される場合に、Ｈ（ｅ）ＮＢ ＧＷは、ＬＧＷ Ｉｄ特性を取り出すことができる、セットアップされることになるリストのＥ−ＲＡＢの一部として接続されたＨ（ｅ）ＮＢのＬＧＷ能力をコンパイルすることができる。これは、たとえば、ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰメッセージの受信時に行われてもよい。Ｈ（ｅ）ＮＢは、ターゲットＨ（ｅ）ＮＢからのＬＧＷ情報を使用して、ＳＩＰＴＯハンドオーバまたはＬＩＰＡハンドオーバを進行することができるかを判定することができる。

ＬＩＰＡ／ＳＩＰＴＯユーザプレーンデータおよびリソースは、ＨＯの間に、および、ＨＯ後に処理されてもよく、すなわち、バッファリングし、経路を切り替え、ソースＨｅＮＢでリソースを解放することができる。ＤＬ ＬＩＰＡ／ＳＩＰＴＯトラフィックは、ＨＯの間にバッファリングされてもよい。ソースＨｅＮＢは、ＨＯの開始に関してＬＧＷに通知してもよく、および、ＬＧＷは、所与のＵＥに対してＤＬパケットのバッファリングを開始してもよい。ソースＨｅＮＢは、選択されたターゲットＨｅＮＢに関して（たとえば、グローバルセルＩＤ、物理セルＩＤ、ＣＳＧ ＩＤ、アクセスモードなど）ＬＧＷに通知してもよく、および、ＬＧＷは、その後、この情報を使用して、それ（すなわち、ターゲットＨｅＮＢ）に対する経路を切り替えるためのターゲットＨｅＮＢからの要求を検証してもよい。これに加えて、ソースＨｅＮＢはまた、バッファリングがまたソースＨｅＮＢで行われる場合があるかどうかに関わらず、ＬＩＰＡ／ＳＩＰＴＯデータのバッファリングを実行してもよい。

ＨＯの終了の後に、ソースＨｅＮＢは、ＳＧＷ（間接転送経路）またはＸ２インターフェース（直接転送経路）のいずれかを介して、ターゲットにＬＩＰＡ／ＳＩＰＴＯパケットを転送してもよい。これが行われる場合に、ソースＨｅＮＢは、ＬＩＰＡ／ＳＩＰＴＯになる転送されるパケットをタグ付けしてもよく、または、またはＬＧＷからの直接経路上にある場合があるパケットとしてタグ付けしてもよい。ソースＨｅＮＢはまた、ＬＧＷから直接に入来しないパケットなど、ＨｅＮＢでバッファリングされてもよい任意のＣＮ転送されたパケットをタグ付けしてもよい。

ソースＨｅＮＢは、ＨＯプロシージャの開始またはＨＯプロシージャの失敗またはＨＯプロシージャの中断についてＬＧＷに通知してもよい。したがって、ＬＧＷは、パケットのバッファリングを停止することを決定してもよく、および、ソースＨｅＮＢへのパケットの転送を継続してもよい。これは、たとえば、ＵＥがソースＨｅＮＢセルに返ってもよいＨＯの中断またはＨＯの失敗のときに行われてもよい。

ＬＧＷでのバッファリングの終了が、ＨＯが完了した後に、ソースＨｅＮＢによって明示的にシグナリングされてもよい。代わりに、ＬＧＷは、ターゲットＨｅＮＢ（またはＭＭＥ、ＳＧＷ、ソースＨｅＮＢ）から要求を受信するときに、バッファリングの終了を完了して、データ経路をＬＧＷに対して切り替えてもよい。

ＬＧＷ（ＬＩＰＡまたはＳＩＰＴＯ＠ＬＧパケット）に対して直接に進むベアラが、ターゲットで許可されない場合は、ソースＨｅＮＢは、いまだに、ＬＧＷからターゲットへの経路が作成されていない場合であっても、すべてのバッファリングされたパケットを転送することができる。これは、ＵＥが、ＬＧＷに接続されていない場合がある別のＨｅＮＢに移動した場合であっても、ＬＩＰＡまたはＳＩＰＴＯ＠ＬＧＷセッション継続性を維持する方法としてＳＧＷを介して行われてもよい。さらに、これは、ＵＥがＨｅＮＢサブシステムからマクロセルにハンドオーバされてもよいアウトバウンドモビリティに使用されてもよい。転送は、ＳＧＷを介して行われてもよく、および、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷパケットは、ＵＥのＣＮ ＰＤＮ接続のデフォルトベアラに対応するＳ１−Ｕおよび無線ベアラ上など、既存のＣＮ ＰＤＮ接続のデフォルトベアラ上で扱われてもよい。

データ経路は、ＨＯの後にＬＧＷから切り替われてもよい。経路切替えは、Ｓ１ ＨＯで行われてもよい。ターゲットＨｅＮＢは、ＬＧＷに対する経路切替えを実行してもよい。これは、ターゲットＨｅＮＢとＬＧＷとの間に接続が存在し、および、少なくとも１つのＬＩＰＡベアラまたはＳＩＰＴＯ＠ＬＧＷベアラがターゲットＨｅＮＢにおいて許可されたことを仮定してもよい。経路切替えを開始するトリガは、ＨＯの後の最初のＲＲＣメッセージ、たとえばＲＲＣ接続再構成完了（RRC Connection Reconfiguration Complete）の受信であってもよい。ターゲットＨｅＮＢは、許可することができるベアラのリスト、および、解放することができるベアラのリストを、解放の原因とともに提供してもよい。ＬＧＷは、ターゲットＨｅＮＢによって解放されたものとしてタグ付けされたベアラを解放してもよい。経路切替えは、ＳｘｘインターフェースまたはＬＧＷとＨｅＮＢとの間で定義されてもよい任意の他のインターフェースを介して行われてもよい。

代わりに、ターゲットＨｅＮＢは、許可することができ、または、解放することができるすべてのベアラを含むハンドオーバ通知（Handover Notify）（Ｓ１ＡＰ）メッセージを、ＭＭＥに送信してもよい。ターゲットＨｅＮＢは、ＬＩＰＡまたはＳＩＰＴＯ＠ＬＧＷであるものとしてこれらのベアラにタグ付けしてもよい。さらに、ターゲットＨｅＮＢは、ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷサービスを維持するのに必要とされる場合がある任意の他のアドレッシング情報とともに、ＤＬ ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷトラフィックを転送するためにＬＧＷによって使用されてもよい、少なくとも１つのＤＬ ＴＥＩＤを含めてもよい。ＭＭＥは、変更ベアラ要求（Modify Bearer Request）メッセージをＳＧＷに送信してもよい。このメッセージにおいて、ＭＭＥは、許可することができたＬＧＷからのベアラと、解放することができたすべてのベアラとを示してもよい。ＭＭＥはまた、ＬＩＰＡベアラまたはＳＩＰＴＯ＠ＬＧＷベアラがあるかどうかを示してもよい。この情報で、ＳＧＷはまた、ＬＧＷへの変更ベアラ要求（Modify Bearer Request）メッセージを開始して、ターゲットＨｅＮＢに対する経路切替えに関してＬＧＷに通知してもよい。ＬＧＷからのベアラのどれもが許可されないことが可能である場合がある。この場合には、ＭＭＥは、ＬＧＷに対するＰＤＮ接続の解放を開始してもよい。

ＬＧＷが、ＨＯの後に経路切替え要求またはＰＤＮ接続の解放のインジケーションを受信するときに、ＬＧＷはまた、ソースＨｅＮＢに対するリソースの解放を開始してもよい。ソースＨｅＮＢはまた、ソースＨｅＮＢが、ターゲットによって許可されたベアラを知っている可能性がある場合に、ＬＧＷに対するリソースを解放してもよい。たとえば、ＨｅＮＢは、解放されることになるベアラなど、Ｓ１ＡＰインターフェース上でＨＯコマンド（HO Command）メッセージを検証してもよい。ソースＨｅＮＢとＬＧＷとの間のリソースは、任意のＨＯ障害に対してＨＯが準備中である後に、解放されてもよく、それによって、ＵＥがそのセルに帰る場合に、当該ＵＥがソースＨｅＮＢからそのＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷサービスを継続することを可能にする。これは、どのノードがソースＨｅＮＢとＬＧＷとの間のリソースの解放を開始するのかに関わらず行われてもよい。

ＨＯが完了した後に、ＬＧＷとソースＨｅＮＢとの間のリソースは、ソースＨｅＮＢまたはＬＧＷのいずれかによって解放されてもよく、または、これは、ＭＭＥ／ＳＧＷによって開始されてもよい。ソースＨｅＮＢとＬＧＷとの間のリソースは、Ｓｘｘインターフェースまたは両方のノードをともに接続することができる任意の他のインターフェースのいずれかの上のメッセージを使用して解放されてもよい。このインターフェースがＳ１またはＸ２である場合に、既存のメッセージまたは新たなメッセージが、この目的に対して定義されてもよく、または、使用されてもよい。

原因コードが、任意のリソースを解放することができる理由を説明するのみ含まれてもよい。たとえば「成功して完了したＨＯ：HO completed successfully」と定義される原因コードは、ＨＯの成功した完了の後、ＨｅＮＢ−ＬＧＷリソースを解放するときに使用されてもよい。

ＨＯの任意のステージにおいて、たとえばＬＧＷヘの接続の欠如に起因してＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラを許可することができないことをターゲットが示す場合に、ソースＨｅＮＢは、このＵＥまたは任意の他のＵＥに対する後続のＨＯでの使用のためにこの情報を保存してもよい。これはまた、Ｘ２ハンドオーバに適用されてもよい。

ＬＧＷが、任意のノードから（たとえば、ターゲットＨｅＮＢから）の経路を切り替えるインジケーションを受信するときに、ＬＧＷは、ＨＯの完全性を検証してもよい。これは、たとえば、ソースＨｅＮＢが既に起こり得るＨＯのフラグをたてたかをチェックすることによって、または、ソースＨｅＮＢを調査して、ＨＯが問題のＵＥに対して行われているかを検証することによって、行われてもよい。経路切替えを要求するノードは、ソースノード、および、問題のＵＥに対するＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷサービスを識別するのに必要な情報を含めてもよい。提供される情報が、ＬＧＷの情報と一致しない場合には、ＬＧＷは、経路切替え要求をリジェクトし、および、ＨＯ障害に関してソースＨｅＮＢに通知してもよい。ＬＧＷはまた、ＨＯ障害または経路切替え障害に関してＭＭＥ／ＳＧＷに通知してもよく、および、ＭＭＥは、ＨＯ障害についてソースＨｅＮＢに通知してもよい。ＨＯは、必要な場合に再開始されてもよく、または、ＵＥが、無線状態がそれを許可する場合に、ソースＨｅＮＢにおいて再開してもよい。上記説明された実施形態は、ＨＯがＸ２インターフェースを介して実行される場合にも適用されてもよい。

データ経路は、ＨＯの後にＬＧＷから切り替わってもよい。経路切替えは、Ｘ２ ＨＯで行われてもよい。ターゲットＨｅＮＢは、上記Ｓ１ ＨＯの場合について説明されたように、経路切替えを実行するためにＬＧＷに直接にコンタクトしてもよい。したがって、同一の実施形態が、Ｘ２ ＨＯで使用されてもよい。代わりに、ターゲットＨｅＮＢからの経路切替え要求が、ＭＭＥに進んでもよい。これは、ＳＧＷに対する変更ベアラ要求（Modify Bearer Request）をトリガしてもよく、このＳＧＷは、ＬＧＷに対する変更ベアラ要求メッセージを送信してもよい。上記Ｓ１ ＨＯにおいて、受信側ノードのコンテンツおよびアクションに関して定義された実施形態は、Ｘ２ハンドオーバに適用されてもよい。

リソースは、ＨＯの後にソースＨｅＮＢとＬＧＷとの間で解放されてもよい。ソースＨｅＮＢとＬＧＷとの間のリソースは、ＨＯ完了の後に解放されてもよい。リソースは、ソースＨｅＮＢまたはＬＧＷのいずれかによって解放されてもよい。そのような解放は、ＳＧＷまたはＭＭＥによってトリガされてもよい。たとえば、ＨＯの間に、ＭＭＥ／ＳＧＷが、ＬＧＷに変更ベアラ要求（Modify Bearer Request）を送信して、ターゲットＨｅＮＢへのＨＯに起因してベアラのサブセットを解放する場合に、ＬＧＷは、このメッセージをターゲットに対するＨＯの完了と解釈してもよい。ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷベアラがターゲットＨｅＮＢに転送されたか否かに関わらず、ターゲットへのＨＯ完了が、ソースＨｅＮＢとＬＧＷとの間のリソースセットアップを使用しない場合があるので、ＬＧＷは、このメッセージを、ソースＨｅＮＢに対するリソースの解放を開始するトリガとして使用してもよい。

ＬＧＷが、以前に提案されたように潜在的なＨＯに関して通知された場合に、ＬＧＷは、タイマを始動して、成功したＨＯの持続時間を保護してもよい。このタイマが、ＬＧＷで満了し、および、ノードのいずれか（ソースＨｅＮＢ、ターゲット、またはＭＭＥ／ＳＧＷ）から経路切替え、サービスの解放、またはサービスの再開に関するいかなるインジケーションも受信しなかった場合には、ＬＧＷは、このＵＥに対してリソースを自律的に解放してもよい。ＬＧＷはまた、ＭＭＥに対するＰＤＮ接続の非アクティブ化を開始してもよく、および、ソースＨｅＮＢに対するリソースを解放してもよい。原因コードは、解放が開始された理由を説明するために、任意の受信側（ＭＭＥ／ＳＧＷまたはソース／ターゲットＨｅＮＢ）に対する任意のメッセージに含まれてもよい。

図１０は、ハンドオフの後にソースＨ（ｅ）ＮＢとＬＧＷとの間のＬＩＰＡリソースおよび／またはＳＩＰＴＯリソースの解放を処理することができる通信ネットワークを示す。ＵＥ送信元ＩＰアドレスが、複数のＬＧＷ／ＰＧＷにまたがるＨＯの時に保存されてもよい。これは、たとえば、初期システムアタッチ（Initial System Attach）に関連付けられた初期ＰＤＮ接続または後続の専用ＰＤＮ接続の確立の間に行われてもよい。

ＭＭＥは、ＳＧＷを指示して、ＳＧＷ自体または任意の他の選択されたＰＧＷのいずれかに関連付けられた、異なるオフロードポイントをセットアップしてもよい。この指示は、たとえば、ＴＡＩ、ＣＳＧ、または任意の他のロケーションタグなどのロケーション情報に基づいてもよい。図１０に示されるように、ＭＭＥ１０００は、使用可能なアンカＧＷ（ＡＧＷ）のプールから、ＡＧＷまたはオフロードポイントを選択してもよく、および、この情報をセッション作成要求（CREATE SESSION REQUEST）メッセージを通じてＰＧＷに通信してもよい。ＰＧＷは、セッション作成要求メッセージをＡＧＷに中継してもよく、および、それ自体のアドレス（ＰＧＷアドレス）を提供してもよい。

別の実施形態では、ＭＭＥ１０００は、セッション作成要求メッセージを通じて、ＳＧＷ１００５に関連付けることができるＡＧＷを選択するように、ＳＧＷ１００５に要求してもよい。セッション作成要求メッセージを使用して、ＳＧＷ１００５は、ＡＧＷからのＰＤＮ接続（PDN Connection）を要求してもよく、および、それ自体のアドレス（ＳＧＷ１００５アドレス）を提供してもよい。

ＵＥ１０１０が、マクロネットワークに戻るＨＯになる必要がある場合に、ＳＧＷまたはＰＧＷのアドレスが使用されてもよい。ＵＥ１０１０に提供されるＩＰアドレスは、ＡＧＷのＩＰアドレスであってもよい。ＵＥ１０１０が、Ｈ（ｅ）ＮＢ１０１５およびＨ（ｅ）ＮＢ１０２０などのＨ（ｅ）ＮＢの間で、または異なるＬＧＷもしくはＰＧＷに接続されたＨ（ｅ）ＮＢの間で移動するときに、データ経路は、関連するＳＧＷまたは別のＬＧＷのいずれかに対して確立されてもよい。

アドレッシング情報は、ＬＧＷとＨｅＮＢとの間で交換されてもよい。確立されたＥＰＳベアラおよび関連付けられた直接経路（ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷトラフィックに対して）の各々に対して、ＬＧＷとＨｅＮＢとの間で２つの関連付けられた有向トンネル、すなわち、ＬＧＷからＨｅＮＢへの直接経路ＤＬトンネルと、ＨｅＮＢからＬＧＷへの有向経路トンネル（ＵＬトンネル）とが存在してもよい。ＨｅＮＢおよびＬＧＷは、いくつかの方法でＴＥＩＤを交換してもよい。ＤＬ ＴＥＩＤおよびＵＬ ＴＥＩＤの交換は、Ｓｘｘ ＡＰ（アプリケーション）プロシージャ、および、ＧＴＰプロトコルが新たなＳｘｘインターフェース上で使用されることを仮定しているＧＴＰ制御プレーン（ＧＴＰ−Ｃ）におけるプロシージャ、を使用して、Ｓｘｘインターフェース上で行われてもよい。Ｓ１ ＡＰアプリケーション（Ｈ（ｅ）ＮＢ⇔ＳＧＷ）、ＲＡＮＡＰプロシージャ（Ｈ（ｅ）ＮＢ⇔ＳＧＷ）もしくはＧＴＰ−Ｃプロシージャ（ＳＧＷ⇔ＬＧＷ）、または、それらの組合せを使用した、たとえば経路Ｈ（ｅ）ＮＢ⇔ＳＧＷ⇔ＬＧＷ上などの、Ｓ１−Ｓ５インターフェース上で、ＤＬ ＴＥＩＤおよびＵＬ ＴＥＩＤの交換、たとえば、Ｈ（ｅ）ＮＢは、Ｓ１１インターフェース上でＳＧＷに転送されてもよい（変更ベアラ要求（Modify Bearer request）メッセージ）ＭＭＥ（またはＭＳＣ／ＳＧＳＮ）への経路切替え要求（Path Switch Request）（または拡張再配置完了要求（Enhanced Relocation Complete Request））メッセージにおいてＤＬ ＴＥＩＤを提供してもよい。次に、これは、Ｓ５インターフェース（変更ベアラ要求メッセージ）上でＬＧＷに従って渡されてもよい。

ＬＧＷ内ハンドオーバ（intra-LGW handover）シナリオに対し、このプロシージャは、ハンドオーバ要求（Handover Request）または拡張再配置要求（Enhanced Relocation Request）をターゲットＨＮＢに送信した後すぐに、ソースＨｅＮＢによって開始されてもよい。このメッセージを早期に送信することの１つの利点は、これが、ハンドオーバプロシージャが進行中であるという事実をＬＧＷに通知することを可能にすることである。このことは、ＬＧＷが、ＤＬトラフィックデータのバッファリングなど、アクションを行うことを可能にする。このプロシージャを、ハンドオーバの後のステージでソースによって開始されてもよい。このプロシージャはまた、ハンドオーバ要求（または拡張再配置要求）メッセージを受信するときに、ターゲットによって開始されてもよい。このプロシージャは、ＵＥ同期を検出するとき、または、ＲＲＣ接続再構成完了（RRC Connection reconfiguration complete）メッセージを受信するときなど、ハンドオーバプロシージャの後の段階で開始されてもよい。ＬＧＷ間ハンドオーバ（inter-LGW handover）シナリオに対し、このプロシージャが、ＬＧＷ内の場合と同様の方法でターゲットＨｅＮＢによって開始されてもよい。

別の実施形態では、相関ＩＤが、ＬＧＷによってＳＧＷに提供されてもよく（変更ベアラ応答（Modify bearer response））、ＳＧＷは、情報をＭＭＥに転送してもよい（変更ベアラ応答）。ＭＭＥは、この情報を、経路切替え肯定応答メッセージを使用してターゲットＨＭＢに転送してもよい。相関ＩＤが使用されて、Ｈ（ｅ）ＮＢ⇔ＳＧＷ⇔ＬＧＷトンネルを、Ｈ（ｅ）ＮＢとＬＧＷとの間の直接経路トンネルに相関させてもよい。たとえば、相関ＩＤが、Ｈ（ｅ）ＮＢとコアネットワークとの間で交換する後の経路管理またはベアラ管理について使用されてもよい。

ＵＥは、ＤＬ ＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷトラフィックに対してページングされてもよい。ＵＥは、アイドルモードでのページングがＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷに起因する場合があることを通知されてもよい。このインジケーションに基づいて、ＵＥは、ＬＧＷからのページングが存在することをユーザ／上位レイヤに表示してもよい。ＵＥはまた、オプションで、サービスのタイプ、たとえばＬＩＰＡとＳＩＰＴＯに関する詳細と、ＬＧＷによって提供され識別のいくつかのタイプなど、呼び出すエンティティに関する情報を表示してもよい。ユーザは、ＬＧＷからのセッションがＬＧＷから継続することを許可する前に、ページングを受け入れまたはリジェクトしてもよい。

ダウンリンクパケットがＨｅＮＢに到着するときに、ＧＷ／ＬＧＷ／ＳＧＷアンサンブル（単純さのために、ＨＧＷと称する）は、相関ＩＤまたはＤＬ ＴＥＩＤ Ｓ１接続が存在するかを判定する。接続が存在しない場合には、ＨＧＷは、ＣＳＧ ＩｄまたはＰＬＭＮが、ＳＩＰＴサービスまたはＬＩＰＡサービスを許可することができるＨｅＮＢ（１つまたは複数）対するＰＡＧＥメッセージを生成してもよい。ＨＧＷは、ＨＧＷでの構成選択にしたがってＰａｇｅメッセージを生成してもよい。ＬＩＰＡまたはＳＩＰＴＯを許可することができないＣＧＳ ＩｄでのＨｅＮＢのページングは、その呼をセットアップすることができないので、浪費的である場合がある。接続が存在しない場合には、ＨＧＷは、ＭＭＥにダウンリンクデータ通知（DOWNLINK DATA NOTIFICATION）メッセージを送信して、ページングをトリガしてもよい。このことは、ＨＧＷがＳＧＷ機能性を提供することができ、および、現在のＲ１０プロシージャによってＳＧＷにダウンリンクデータを送信する必要がない場合があることを仮定してもよい。ＨＧＷが、ＳＧＷに第１のパケットを送信して、ページングプロシージャをトリガする場合に、このパケットは、最終的にＨＧＷへのＭＭＥからのＰＡＧＩＮＧメッセージをトリガすることになる場合がある。ＭＭＥがＵＥをページングする前に、ＭＭＥは、ＳＩＰＴＯおよびＬＩＰＡが許可されないＣＳＧ Ｉｄを除去してもよい。代わりに、ＳＧＷ機能性が、ＨＧＷまたはＬＧＷによって提供されない場合に、ＭＭＥは、ＬＧＷに接続されていることを知っているＨｅＮＢに単にページングメッセージを送信してもよい。

図１１は、ＬＧＷトラフィックにおいてＬＩＰＡおよび／またはＳＩＰＴＯに対してＵＥをページングすることができる通信ネットワークを示す。ＭＭＥは、ページングがＬＩＰＡ／ＳＩＰＴＯサービスをセットアップする（すなわち、ＬＩＰＡ／ＳＩＰＴＯ ＰＤＮ接続を確立する）ことを意図されているかどうかをＨｅＮＢに示してもよい。ＨｅＮＢは、ページングメッセージにおいてこのフラグ／インジケータを送信してもよい。ページングメッセージ内で一緒に渡されているＬＩＰＡ／ＳＩＰＴＯインジケータに基づいて、ＵＥは、たとえば、呼がＬＩＰＡ接続またはＳＩＰＴＯ接続をセットアップすることを意図されているかどうかを表示してもよい。ＵＥはまた、発信者端末ＩＤ（Calling Line ID）情報を表示してもよい。ユーザは、呼／接続をリジェクトまたは許可する、自らの要望を示してもよい。

エリア内の複数のＨＧＷまたはＬＧＷが、ＨｅＮＢまたはＨｅＮＢ ＧＷからのリソースを共有する場合に、ＵＥが、同一のＣＳＧ ＩｄでＨｅＮＢにおけるページングを回答してもよいが、オリジナルＤＬパケットが受信されたものとは異なるＳＧＷに接続されてもよい。このシナリオに対処するために、初期Ｓ１ＡＰセットアップの間に、Ｈ（ｅ）ＮＢは、ＬＧＷのアドレスを取得してもよく、あるいは、ＵＥは、ＲＲＣ接続要求（RRC CONNECTION REQUEST）メッセージの間にＬＧＷ ｉｄをＨ（ｅ）ＮＢに提供してもよい。ＨｅＮＢは、たとえばＳ１ＡＰ初期コンテキストセットアップ要求（S1AP INITIAL CONTEXT SETUP REQUEST）メッセージにおいてＭＭＥによって提供された情報に基づいて、潜在的なＬＧＷのリストを作成してもよい。ページングプロシージャの間に、ＨｅＮＢ／ＨｅＮＢＧＷは、ＭＭＥに、パケットがＳ１−ＡＰ初期ＵＥメッセージ（S1-AP INITIAL UE MESSAGE）内でルーティングされてもよいＬＧＷ／ＳＧＷのアドレスを提供してもよい。ＭＭＥは、この情報を使用して、ページが受信されたＨ（ｅ）ＮＢにサービスするＳＧＷ、または、オリジナルＬＧＷにＨ（ｅ）ＮＢによって提供されるＬＧＷのいずれかのアドレスを提供してもよい。ＭＭＥは、この情報を、セッション作成要求（CREATE SESSION REQUEST）メッセージを使用して、関連するＳＧＷに対して中継してもよい。次に、ＳＧＷは、それ自体のアドレスを使用してもよく、または、ＬＧＷ１２００などのＬＧＷ−１に中継されるセッション作成要求メッセージ内のＬＧＷ１２０５などのＬＧＷ−２のアドレスを提供してもよい。

図１１に示されるように、ＵＥ１２１０は、当初は、Ｈ（ｅ）ＮＢ１２１５およびＬＧＷ１２００に接続されてもよい。アイドルモードである間に、ＵＥ１２１０は、ＬＧＷ１２０５に接続されてもよいＨ（ｅ）ＮＢ１２２０のカバレージエリアに移動してもよい。ページングメッセージの受信時に、ＵＥ１２１０は、Ｈ（ｅ）ＮＢ１２２０を通じてそのページングに応答してもよく、および、このプロセスは、上記説明したように継続してもよい。１２４０では、ＭＭＥ１２２５は、ＳＧＷ１２３０のアドレスを提供してもよい。１２３５では、ＭＭＥ１２２５は、ＬＧＷ１２０５のアドレスを提供してもよい。

複数のＬＧＷの場合に、少なくとも、少なくとも２つのＬＧＷの間で接続が存在してもよい。このことは、たとえば、ＨｅＮＢが、所与のＵＥに対するＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷを提供しているＬＧＷ１２００に接続しない場合に、ＬＧＷ１２００からのパケットが１２４５（提案されるトンネル／接続）を介してＬＧＷ１２０５に転送されることを保証するために行われてもよい。ＬＧＷ１２０５は、現在のサービングＨｅＮＢが接続するところであってもよい。これは、別のレベルのＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷモビリティを提供してもよい。ＬＧＷ１２００に接続しない所与のＨｅＮＢの無線カバレージの下のＵＥに対するＵＬまたはＤＬのいずれかのＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷデータ交換に対し、ＭＭＥ１２２５は、ＬＧＷ１２００とＬＧＷ１２０５との間のトンネルの確立を調整してもよい。このことは、たとえば、所望のＤＬパケットが、１２４５でＬＧＷ１２００からＬＧＷ１２０５へ、１２３５を介してＨｅＮＢ１２２０へ転送され、および、最後にＵＥ１２１０へ転送されることを保証するために行われてもよい。任意のＵＬパケットは、逆の順序で転送されてもよい。トンネルの確立を調整するために、ＭＭＥは、現在のＨｅＮＢが接続するＬＧＷ、および問題のＵＥに対するＬＩＰＡ／ＳＩＰＴＯ＠ＬＧＷを提供していたＬＧＷに関する情報を使用してもよい。ＭＭＥは、たとえば、ベアラ変更要求などの既存のメッセージ、またはＬＧＷへの新たなメッセージを使用して、ＳＧＷを介してこのトンネルの確立をトリガしてもよい。

ＬＩＰＡ／ＳＩＰＴＯパーミッションが、ＨＯで使用されてもよい。実施形態は、Ｈ（ｅ）ＮＢターゲットでのＳＩＰＴＯ／ＬＩＰＡパーミッションを考慮してもよい。たとえば、ＭＭＥまたはＬＧＷは、ターゲットセル／ＨｅＮＢがＬＩＰＡ／ＳＩＰＴＯサービスをサポートしないかを決定してもよい。ターゲットＨ（ｅ）ＮＢにおけるＳＩＰＴＯサービスに対するＰＬＭＮベースのパーミッションがまた、考慮してもよい。ＳＩＰＴＯパーミッションに関するＣＳＧメンバシップがまた、考慮されてもよい。たとえば、ＵＥがこのＣＳＧのメンバである場合に、ＣＳＧは、ＳＩＰＴＯサービスを許可してもよい。

ハンドオーバ制限リストが、ＭＭＥによって、ハンドオーバ要求（HANDOVER REQUEST）メッセージ、初期コンテキストセットアップ（INITIAL CONTEXT SETUP）メッセージ、またはダウンリンクＮＡＳトランスポート（DOWNLINK NAS TRANSPORT）メッセージにおいてｅＮＢに提供されてもよい。ハンドオーバ制限リストが使用されて、ＬＩＰＡパーミッション構成またはＳＩＰＴＯパーミッション構成に起因するＨＯ制限を考慮してもよい。ｅＮＢは、この情報を使用して、測定報告を提供するときに、ＵＥがよい無線状態を報告した場合であっても、候補隣接を除去してもよい。ターゲットｅＮＢは、この情報を使用して、要求がリジェクトされるかを判定してもよい。

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

Claims (28)

1. ハンドオーバに対するターゲットＨｅＮＢを選択するための方法であって、
   無線送信／受信ユニット（ＷＴＲＵ）との接続を確立するステップであって、前記接続は、セッションをサポートし、前記セッションは、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ：selective IP traffic offload）セッションまたはローカルＩＰアクセス（ＬＩＰＡ）セッションのいずれかを備える、ステップと、
   前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップと、
   前記セッションを前記ターゲットＨｅＮＢにハンドオーバするステップと
   を備えることを特徴とする方法。
2. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、ＣＳＧサブスクリプション情報に基づいて、前記ＷＴＲＵが前記ターゲットＨｅＮＢにアクセスすることを許可されることを判定するステップを備えることを特徴とする請求項１に記載の方法。
3. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、前記ターゲットＨｅＮＢが、前記セッションを前記ＷＴＲＵに対して提供するローカルゲートウェイ（ＬＧＷ）に接続されていることを検証するステップを備えることを特徴とする請求項１に記載の方法。
4. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、前記ＷＴＲＵが、前記ターゲットＨｅＮＢからサービスを受信することを許可されることを判定するステップを備えることを特徴とする請求項１に記載の方法。
5. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、
   ＣＳＧサブスクリプション情報に基づいて、前記ＷＴＲＵが、前記ターゲットＨｅＮＢにアクセスすることを許可されることを判定するステップと、
   前記ターゲットＨｅＮＢが、前記ＷＴＲＵに対する前記セッションを提供するローカルゲートウェイ（ＬＧＷ）に接続されていることを検証するステップと、
   前記ＷＴＲＵが、前記ターゲットＨｅＮＢからサービスを受信することを許可されることを判定するステップと
   を備えることを特徴とする請求項１に記載の方法。
6. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、
   前記ターゲットＨｅＮＢに対する前記ＷＴＲＵから測定を受信するステップと、
   前記測定を分析して、前記ＷＴＲＵと前記ターゲットＨｅＮＢとの間の無線状態が前記セッションをサポートするかを判定するステップと
   を備えることを特徴とする請求項１に記載の方法。
7. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、
   オペレータポリシーを受信するステップと、
   前記オペレータポリシーを使用して、前記セッションに対する前記サポートを示す１つまたは複数の条件を判定するステップと、
   前記１つまたは複数の条件が満たされたときを判定するステップと
   を備えることを特徴とする請求項１に記載の方法。
8. 前記１つまたは複数の条件が満たされたときを判定するステップは、
   オペレータポリシーを受信するステップと、
   前記オペレータポリシーを使用して、前記セッションに対する前記サポートを示す１つまたは複数の条件を判定するステップと、
   前記ＷＴＲＵから前記ターゲットＨｅＮＢに対する測定を受信するステップであって、前記測定は、前記ＷＴＲＵと前記ターゲットＨｅＮＢとの間の無線状態が前記セッションをサポートするかを示している、ステップと、
   前記測定が、前記ＷＴＲＵと前記ターゲットＨｅＮＢとの間の前記無線状態が前記セッションをサポートすることを示すときに、前記１つまたは複数の条件が満たされたときを判定するステップと
   を備えることを特徴とする請求項１に記載の方法。
9. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、前記セッションが前記ＷＴＲＵから前記ターゲットＨｅＮＢ上でサポートされることのインジケーションを受信するステップを備えることを特徴とする請求項１に記載の方法。
10. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、パーソナルデータネットワーク（ＰＤＮ）を指定し、または、ＬＧＷを識別する識別を、前記ターゲットＨｅＮＢから受信するステップを備えることを特徴とする請求項１に記載の方法。
11. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、Ｘ２インターフェースを介して前記ターゲットＨｅＮＢとコンタクトするステップを備えることを特徴とする請求項１に記載の方法。
12. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、前記ターゲットＨｅＮＢが、前記セッションをサポートすることを示す情報をコアネットワークから受信するステップを備えることを特徴とする請求項１に記載の方法。
13. 前記セッションをサポートする前記ターゲットＨｅＮＢの能力に基づいて、前記ハンドオーバに対するターゲットＨｅＮＢ選択するステップは、前記ターゲットＨｅＮＢが、前記セッションをサポートすることを示す情報をＭＭＥまたはＬＧＷから受信するステップを備えることを特徴とする請求項１に記載の方法。
14. 前記セッションを前記ターゲットＨｅＮＢにハンドオーバするステップは、
    ＬＧＷトランスポートレイヤアドレスおよびトンネルエンドポイントＩＤ（ＴＥＩＤ）を判定するステップと、
    前記ＬＧＷトランスポートレイヤアドレスおよび前記ＴＥＩＤを前記ターゲットＨｅＮＢに提供して、前記ターゲットＨｅＮＢが前記セッションを継続することを可能にするステップと
    を備えることを特徴とする請求項１に記載の方法。
15. ＷＴＲＵとの接続を確立するステップは、
    所定のＳＣＴＰ宛先ポート番号で、ＬＧＷに対するＳＣＴＰアソシエーションを確立するステップと、
    ダウンリンクＴＥＩＤに対するサポートを前記ＬＧＷに転送するステップと、
    ＨｅＮＢトランスポートレイヤアドレスを送信するステップと、
    ＬＧＷトランスポートレイヤアドレスを受信するステップと
    を備えることを特徴とする請求項１に記載の方法。
16. 無線送信／受信ユニット（ＷＴＲＵ）を介して、１つまたは複数のアクティブインターフェースにわたってＩＰトラフィックをルーティングするためのルールのセットを提供する、インターアクセスポイントネーム（ＡＰＮ）のルーティングポリシー（ＩＡＲＰ）を受信するステップと、
    前記ＩＡＲＰからのＡＰＮの優先付けされたリストを使用して、優先されるＡＰＮを判定するステップと、
    前記優先されるＡＰＮに基づいて、ＩＰインターフェースを選択して、ＩＰフローをルーティングするステップと、
    選択されたＩＰインターフェースを使用して、前記ＩＰフローを送信するステップと
    を備えることを特徴とする方法。
17. 前記ＩＰフローが、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ：selective IP traffic offload）またはローカルＩＰアクセス（ＬＩＰＡ）であることのインジケーションを、ネットワークエンティティに送信するステップをさらに備えることを特徴とする請求項１６に記載の方法。
18. 前記インジケーションは、ローカルゲートウェイ（ＬＧＷ）が、前記ＩＰフローをＳＩＰＴＯまたはＬＩＰＡとして識別することを可能にするＩＰアドレス情報を備えることを特徴とする請求項１７に記載の方法。
19. 前記インジケーションは、ＬＧＷが、前記ＩＰフローをＳＩＰＴＯまたはＬＩＰＡとして識別することを可能にするＡＰＮ値を備えることを特徴とする請求項１７に記載の方法。
20. 前記ネットワークエンティティは、モビリティ管理エンティティ（ＭＭＥ）、サービングゲートウェイ（ＳＧＷ）、またはＬＧＷを備えることを特徴とする請求項１７に記載の方法。
21. 前記選択されたＩＰインターフェースは、専用パケットデータネットワーク（ＰＤＮ）接続であることを特徴とする請求項１６に記載の方法。
22. 前記ＩＡＲＰは、アクセスネットワーク発見・選択機能（ＡＮＤＳＦ：access network discovery and selection function）から受信されることを特徴とする請求項１６に記載の方法。
23. ハンドオーバを提供するための方法であって、
    ハンドオーバインジケーションを、ＨｅＮＢを介して受信するステップと、
    無線送信／受信ユニット（ＷＴＲＵ）との接続を確立することができるかを判定するステップであって、前記接続は、セッションをサポートし、前記セッションは、選択的ＩＰトラフィックオフロード（ＳＩＰＴＯ：selective IP traffic offload）セッションまたはローカルＩＰアクセス（ＬＩＰＡ）セッションのいずれかを備える、ステップと、
    前記ＷＴＲＵとの接続を確立するステップと、
    セッションハンドオーバを受信するステップと
    を備えることを特徴とする方法。
24. ＷＴＲＵとの接続を確立することができるかを判定するステップは、
    ＣＳＧサブスクリプション情報に基づいて、前記ＷＴＲＵが前記ＨｅＮＢへのアクセスを許可されるかを判定するステップと、
    前記ＨｅＮＢが、前記ＷＴＲＵに対する前記セッションを提供するローカルゲートウェイ（ＬＧＷ）に接続されることを検証するステップと、
    前記ＷＴＲＵが、ターゲットＨｅＮＢからサービスを受信することを許可されると判定するステップと
    を備えることを特徴とする請求項２３に記載の方法。
25. パーソナルデータネットワーク（ＰＤＮ）を指定し、または、前記ＬＧＷを識別する識別を送信するステップをさらに備えることを特徴とする請求項２４に記載の方法。
26. 前記ＨｅＮＢが前記セッションをサポートすることを示す情報を、コアネットワークに送信するステップをさらに備えることを特徴とする請求項２４に記載の方法。
27. 前記ＨｅＮＢが前記セッションをサポートすることを示す情報を、前記ＷＴＲＵに送信するステップをさらに備えることを特徴とする請求項２４に記載の方法。
28. ＬＧＷトランスポートレイヤアドレスおよびトンネルエンドポイントＩＤ（ＴＥＩＤ）を判定するステップをさらに備えることを特徴とする請求項２３に記載の方法。

Images