JP2016034145A - Ｌｉｐａモビリティをサポートするための方法および装置 - Google Patents

Abstract

【課題】ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法および装置が説明されている。
【解決手段】ターゲットホームＮｏｄｅＢ（ＨＮＢ）は、無線送信／受信ユニット（ＷＴＲＵ）にハンドオーバする要求メッセージをソースＨＮＢから受信することができる。ハンドオーバ要求メッセージに応答してターゲットＨＮＢに向かってダウンリンクデータパスを変更するパス切替え要求がローカルゲートウェイ（ＬＧＷ）に送信されうる。ＬＧＷは、ハンドオーバに対するモビリティ管理およびローカルモビリティアンカとして動作し、コアネットワーク（ＣＮ）トラフィックに対するダウンリンクデータパスがターゲットＨＮＢに向かって修正されるようにＨＮＢゲートウェイ（ＧＷ）にハンドオーバに関して通知することができる。
【選択図】図１９

Description

本出願は、無線通信に関する。

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

ローカルインターネットプロトコル（ＩＰ）アクセス（ＬＩＰＡ）は、ホームＮｏｄｅＢ（ＨＮＢ）またはホーム発展型ＮｏｄｅＢ（ＨｅＮＢ）（ＨｅＮＢと総称する）の無線アクセスを使用して、ローカルネットワークへのＩＰ接続を提供するために使用されることがある。ユーザがロケーションを変更する際、当該ユーザは、マクロネットワークカバレッジエリア（すなわち、ローカルネットワークの一部ではないマクロセルまたはＨｅＮＢ）を介してローカルネットワークに接続することができる。これは、マネージドリモートアクセス（ＭＲＡ：managed remote access）セッション（すなわち、リモートＬＩＰＡ（ＲＩＰＡ））と称される。ユーザがローカルネットワークのカバレッジエリア内に移動すると、ＭＲＡセッションは、ＬＩＰＡセッションとして継続される。

１つのシナリオにおいて、ユーザは、ローカルネットワークにおいてＬＩＰＡセッションを開始することができ、次いで、マクロネットワークカバレッジエリアに移動して、当該セッションをＭＲＡセッションとして継続することができ、当該セッションでは、実際のセル（マクロまたはＨｅＮＢ）は、ローカルネットワークに接続していない。例えば、ＬＩＰＡセッションを有する無線送信／受信ユニット（ＷＴＲＵ）は、ローカルネットワークの一部ではないＨｅＮＢに移動することができる。したがって、ＬＩＰＡセッションは、ターゲットＨｅＮＢにおいてＭＲＡセッションとして継続されることがある。

別のシナリオでは、ＷＴＲＵは、ローカルネットワークに接続していないサービングＨｅＮＢにおいてＭＲＡセッションを開始することができる。ユーザがローカルネットワークのカバレッジエリア内に移動し、および、ローカルネットワークの一部であるターゲットＨｅＮＢへのハンドオーバ（ＨＯ）を実行するときに、ＭＲＡセッションは、ＬＩＰＡセッションとして継続される。

しかしながら、ＷＴＲＵがローカルネットワークにとどまっている（すなわち、ローカルネットワークの一部であるＨｅＮＢに接続している）ときには、ＷＴＲＵは、特定の限定加入者グループ（ＣＳＧ）からのＬＩＰＡサービスへのアクセスを許可されない場合がある（例えば、ＷＴＲＵの加入者情報に起因して、または、ＣＳＧがＬＩＰＡサービスをサポートしていないという理由で）。

ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法および装置が説明されている。ターゲットホームＮｏｄｅＢ（ＨＮＢ）は、無線送信／受信ユニット（ＷＴＲＵ）にハンドオーバするための要求メッセージをソースＨＮＢから受信することができる。ハンドオーバ要求メッセージに応答して、ターゲットＨＮＢへのダウンリンクデータパス（path）を変更するパス切替え要求をローカルゲートウェイ（ＬＧＷ）に送信することができる。ＬＧＷは、ハンドオーバに対するモビリティ管理およびローカルモビリティアンカとして動作することができ、および、ハンドオーバに関してＨＮＢゲートウェイ（ＧＷ）に通知することによって、コアネットワーク（ＣＮ）トラフィックに対するダウンリンクデータパスがターゲットＨＮＢへ修正される。

添付図面と併せて、例として以下の説明からさらなる詳細な理解を得ることができる。
１または複数の説明されている実施形態を実装することができる例示的な通信システムを示す。 図１Ａに示されている通信システム内で使用することができる例示的な無線送信／受信ユニット（ＷＴＲＵ）を示す。 図１Ａに示されている通信システム内で使用することができる例示的な無線アクセスネットワークおよび例示的なコアネットワーク（ＣＮ）を示す。 ローカルゲートウェイ（ＬＧＷ）を通じてローカルＩＰネットワークにアクセスするための例示的なシステムを示す。 複数のホーム発展型ＮｏｄｅＢ（ＨｅＮＢ）の例示的なスタンドアロンＬＧＷアーキテクチャを示す。 複数のＨｅＮＢに対する別の例示的なスタンドアロンＬＧＷアーキテクチャを示す。 ネットワークオペレータによってトラフィックをオフロードするのにパケットデータネットワークゲートウェイ（ＰＧＷ）を選択する、セレクティドＩＰトラフィックオフロード（ＳＩＰＴＯ：selected IP traffic offload）サービスの例を示す。 ＨｅＮＢサブシステムにあるＬＧＷを介したインターネットへのユーザデータの例示的なオフロードを示す。 発展型パケットシステム（ＥＰＳ）に対するＨｅＮＢサブシステムにおける例示的なスタンドアロンＬＧＷアーキテクチャを示す。 発展型パケットシステム（ＥＰＳ）に対するＨＮＢサブシステムにおける例示的なスタンドアロンＬＧＷアーキテクチャを示す。 ユニバーサルモバイル通信システム（ＵＭＴＳ）に対する例示的なスタンドアロンＬＧＷアーキテクチャを示す。 ＥＰＳに対するＨｅＮＢサブシステムにおけるＳ１パス上の例示的なスタンドアロンＬＧＷを示す。 ＥＰＳに対するＨＮＢサブシステムにおけるＩｕｈパス上の例示的なスタンドアロンＬＧＷを示す。 ＵＭＴＳに対するＨＮＢサブシステムにおけるＩｕｈパス上の例示的なスタンドアロンＬＧＷを示す。 ユーザがローカルネットワークの一部ではないＨｅＮＢにおいてマネージドリモートアクセス（ＭＲＡ）セッションを開始し、および、ローカルネットワークの一部であるＨｅＮＢにハンドオフする、例示的なシステムおよびフローを示す。 ユーザがローカルネットワークにおいてローカルインターネットプロトコル（ＩＰ）アクセス（ＬＩＰＡ）セッションを開始し、および、ＬＩＰＡセッションがＭＲＡセッションとして継続するマクロネットワークカバレッジエリアに移動する、例示的なシステムおよびフローを示す。 Ｘ２インタフェースを使用するＨｅＮＢ間（inter-HeNB）ハンドオーバプロシージャに対する例示的なシグナルフロー図である。 ＨＮＢ−ＨＮＢ間で最適化されたハンドオーバに対する例示的なシグナルフロー図である。 ＬＩＰＡパーミッションによって、または、ＬＩＰＡパーミッションなしで、ＭＲＡセッションをローカルネットワークの外部から開始することができる第１のシナリオを示す。 同一のローカルネットワーク内でＬＩＰＡパーミッションなしでＭＲＡセッションを限定加入者グループ（ＣＳＧ）から開始することができる第２のシナリオを示す。 非サービング無線ネットワークサブシステム（ＳＲＮＳ）リロケーション（relocation）ハンドオーバの後のＵプレーンおよびＣプレーンシグナリングの例を示す。 ＳＲＮＳリロケーションハンドオーバの後のＵプレーンおよびＣプレーンシグナリングの別の例を示す。 ＳＲＮＳリロケーションハンドオーバの後のＵプレーンおよびＣプレーンシグナリングの別の例を示す。 ＬＧＷ間の例示的な直接インタフェースを示す。 Ｘ２／Ｉｕｒｈを介したデータ転送の例を示す。 例示的なＭＲＡのページングシナリオを示す。 例示的なＷＴＲＵホワイトリストを示す。

以下で参照されたときに、用語「ＨｅＮＢ」および「ＨＮＢ」は、交換可能に使用され、および、これらのいずれかへの参照は、ＨｅＮＢとＨＮＢの両方を表す。

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

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

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

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

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

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

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

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

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

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

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

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

図１Ｂは、図１Ａに例示されている通信システム１００内で使用することができる例示的なＷＴＲＵ１０２を示している。図１Ｂに示されているように、ＷＴＲＵ１０２は、プロセッサ１１８、送受信機１２０、送信／受信要素（例えば、アンテナ）１２２、スピーカ／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、着脱不能メモリ１３０、着脱可能メモリ１３２、電源１３４、グローバルポジショニングシステム（ＧＰＳ）チップセット１３６、および周辺機器１３８を含んでもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら前記の要素の部分的組合せを含んでもよいことが理解されるであろう。

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

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

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

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

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

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

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

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

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

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

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

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

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

サービングゲートウェイ１４４は、Ｓ１インタフェースを介してＲＡＮ１０４におけるｅＮＢ１４０ａ、１４０ｂ、および１４０ｃのそれぞれに接続されてもよい。サービングゲートウェイ１４４は、概して、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃへ／から、データパケットをルーティングおよび転送してもよい。サービングゲートウェイ１４４はまた、ｅＮＢ間ハンドオーバの間にユーザプレーンをアンカリングすること、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃに対してＤＬデータが利用可能になったときにページングをトリガすること、ならびに、ＷＴＲＵ１０２ａ、１０２ｂ、および１０２ｃのコンテキストを管理および格納することなど、他の機能も実行してもよい。

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

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

ローカルＩＰアクセス（ＬＩＰＡ）は、ＨｅＮＢの無線アクセスを使用してローカルネットワーク（ＬＮ）へＩＰ接続を提供してもよい。図２は、ＨｅＮＢ２１０上に同一位置に配置することができる、ローカルゲートウェイ（ＬＧＷ）２０５を通じてローカルＩＰネットワークにアクセスするための例示的なシステム２００を示している。ローカルＩＰネットワークは、例えば、ホームネットワーク２０７であってもよい。ローカルゲートウェイ（ＬＧＷ）２０５は、例えば、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）または汎用パケット無線サービス（ＧＰＲＳ）サポートノード（ＧＧＳＮ）に類似する機能を有してもよい。

システム２００は、セキュリティゲートウェイ（ＳｅＧＷ）２４２、サービングゲートウェイ（ＳＧＷ）２４４、モビリティ管理エンティティ（ＭＭＥ）２４６、およびパケットデータネットワークゲートウェイ（ＰＧＷ）２４８を含むことができるがそれらに限定されない、発展型パケットコア（ＥＰＣ）２４０を含んでもよい。ＬＧＷ２０５およびＨｅＮＢ２１０は、ホームルータ／ネットワークアドレストランスレータ（ＮＡＴ）２２０を使用して、ＩＰバックホール２３０を通じてＳｅＧＷ２４２と通信してもよい。特に、ＬＧＷ２０５およびＨｅＮＢ２１０は、ＳＧＷ２４４と通信してもよく、ならびに、ＨｅＮＢはまた、ＳｅＧＷ２４２を介してＭＭＥ２４６と通信してもよい。

本明細書において上述したように、ＬＧＷ２０５は、ＨｅＮＢ２１０と同一位置に配置されてもよい。したがって、ＷＴＲＵ２１５がＨｅＮＢ２１０のカバレッジエリアから外へ移動する場合（アイドルモードまたは接続ノードのいずれかで）、ＬＩＰＡ ＰＤＮ接続は非活性化されてもよい。さらに、接続モードにあるＷＴＲＵ２１５、および、別のセルへのハンドオーバ（ＨＯ）を実行しようとしているＷＴＲＵ２１５に対し、ＨｅＮＢ２１０は、最初に、ＨＯに関してＬＧＷ２０５に通知することによって、ＬＧＷ２０５がＬＩＰＡ ＰＤＮ接続を非活性化してもよい（このシグナリングはＭＭＥ２４６に送信されてもよい）。ＬＩＰＡ ＰＤＮ接続が非活性化された後、ＷＴＲＵ２１５は、別のセルにハンドオーバされてもよい。ＨＯの間に、ＬＩＰＡベアラ／ＰＤＮ接続が非活性化されなかったことをＭＭＥ２４６が検出した場合、ＭＭＥ２４６は、ＨＯを拒絶してもよい。

図３は、複数のホーム発展型ＮｏｄｅＢ（ＨｅＮＢ）に対する例示的なスタンドアロンＬＧＷアーキテクチャ３００を示しており、これにより、ＷＴＲＵがＨｅＮＢ間を移動するときにＬＩＰＡ ＰＤＮ接続を継続させることを可能にする。同一のＬＧＷに接続する複数のＨｅＮＢは、ＨｅＮＢサブシステムと称されることがある。この例では、スタンドアロンＬＧＷアーキテクチャ３００は、それぞれがＰＤＮ３２３およびＰＤＮ３２７と通信している、ローカルＨｅＮＢネットワーク３０５およびローカルＨｅＮＢネットワーク３１０を含んでもよい。ローカルＨｅＮＢネットワーク３０５は、ＨｅＮＢ３３０、３３２、および３３４と通信することができるＬＧＷ３１０を含んでもよく、ならびに、ローカルＨｅＮＢネットワーク３１０は、ＨｅＮＢ３３６および３３８と通信することができるＬＧＷ３２７を含んでもよい。示されているように、ＬＧＷ３１０および３１５は、これらが単一のＨｅＮＢ上に同一位置に配置されないという点で、スタンドアロンエンティティである。ＨｅＮＢサブシステムへのＬＩＰＡ ＰＤＮ接続を有するＷＴＲＵ（図示せず）は、ＬＩＰＡ ＰＤＮ接続を維持しながら接続されたすべてのＨｅＮＢにわたって移動してもよい。ＷＴＲＵがＨｅＮＢサブシステムの外に完全に移動する場合（すなわち、ＬＧＷに接続するすべてのＨｅＮＢのカバレッジの外に移動する）、ＬＩＰＡに対するＷＴＲＵのＰＤＮ接続は非活性化されてもよい。

図４は、複数のホーム発展型ＮｏｄｅＢ（ＨｅＮＢ）に対する別の例示的なスタンドアロンＬＧＷアーキテクチャ４００を示しており、これにより、ＷＴＲＵがＨｅＮＢ間を移動するときにＬＩＰＡ ＰＤＮ接続を継続させることが可能になる。上述したように、同一のＬＧＷに接続する複数のＨｅＮＢは、ＨｅＮＢサブシステムと称されることがある。この例では、スタンドアロンＬＧＷアーキテクチャ４００は、ＨｅＮＢ４２０、４２２、４２４、および４２６と通信するＬＧＷ４１０を含むことができる、ローカルＨｅＮＢネットワーク４０５を含んでもよい。示されているように、ＬＧＷ４１０は、単一のＨｅＮＢ上に同一位置に配置されないスタンドアロンエンティティである。ＨｅＮＢサブシステム４０５へのＬＩＰＡ ＰＤＮ接続を有するＷＴＲＵ４３０は、ＬＩＰＡ ＰＤＮ接続を維持しながら接続されたすべてのＨｅＮＢ４２０、４２２、４２４、および４２６にわたって移動してもよい。ＷＴＲＵがＨｅＮＢサブシステム４０５の外に完全に移動する場合（すなわち、ＬＧＷ４１０に接続するすべてのＨｅＮＢ４２０、４２２、４２４、および４２６のカバレッジの外に移動する）、ＬＩＰＡに対するＷＴＲＵ４３０のＰＤＮ接続は非活性化されてもよい。

図５は、ネットワークオペレータがインターネットへのトラフィックをオフロードするＰＧＷを選択することができる、セレクティドＩＰトラフィックオフロード（ＳＩＰＴＯ）サービスを使用する無線通信システム５００の例を示す。特に、ＷＴＲＵの物理的ロケーションまたはＩＰトポロジロケーションは、コアネットワーク（ＣＮ）ＰＧＷと異なるＰＧＷを選択することを有益とする。無線通信システム５００は、ＳＧＷ５１５と通信しているｅＮＢ５１０によって提供されるような無線アクセスネットワーク（ＲＡＮ）５０５を含んでもよい。次いで、ＳＧＷ５１５は、ローカルＰＧＷ５２０（Ｌ−ＰＧＷ、またはＬＧＷとして知られる）、ならびに、ＭＭＥ５３０およびＰＧＷ５３５を含むことができるＣＮ５２５と通信してもよい。ＷＴＲＵ５４０は、ＳＩＰＴＯ接続を使用して、ＬＧＷ５２０を介してユーザデータをインターネット（図示せず）にオフロードしてもよい。ＳＩＰＴＯは、ＲＡＮの上で、ＷＴＲＵの無線接続がｅＮＢまたはＨｅＮＢを介して取得されるか否かに関わらず、達成されてもよい。別のＰＧＷの選択は、ＷＴＲＵに知られていないことがあり、および、ＬＧＷへのＷＴＲＵのトラフィックのオフロードは、ユーザのサービス経験を低下させることがある。

図６は、ＨｅＮＢサブシステム上にあるＬＧＷを介したインターネットへのユーザデータのオフロードに対する例示的なアーキテクチャ６００を示している。エンタープライズネットワーク６０５（すなわち、ローカルネットワーク）は、エンタープライズＩＰサービス６１４を介してインターネット６１２に接続されているＨｅＮＢサブシステム６１０を含んでもよい。ＨｅＮＢサブシステム６１０は、ＨｅＮＢ６１７、ＨｅＮＢ６１８、およびＨｅＮＢ６１９と通信することができるＬＧＷ６１６を含んでもよい。モバイルオペレータネットワーク（ＭＮＯ）６２０は、ＭＭＥ６２２、ＰＧＷ６２４、およびＳＧＷ６２６を含んでもよい。ＬＴＥマクロネットワーク６３０は、ＭＭＥ６２２およびＳＧＷ６２６と通信することができるｅＮＢ６３２を含んでもよい。ＭＭＥ６２２およびＳＧＷ６２６は、両方とも、ＨｅＮＢ６１７、ＨｅＮＢ６１８、およびＨｅＮＢ６１９と通信してもよく、ならびに、ＳＧＷ６２６はまた、ＬＧＷ６１６と通信してもよい。ＷＴＲＵ６４０は、ハンドオーバの結果としてＨｅＮＢ６１８または６１９と通信してもよい。このアーキテクチャ６００では、ＬＩＰＡとＳＩＰＴＯとが両方とも可能であるが（すなわち、ＬＧＷ６１６が使用されてローカルＩＰネットワーク（すなわち、ＬＩＰＡ）にアクセスすることができるが）、同一のＬＧＷ６１６を介してＷＴＲＵ６４０のデータをインターネット６１２にオフロードすることも可能になる。

図７は、発展型パケットシステム（ＥＰＳ）に対する例示的なスタンドアロンＬＧＷアーキテクチャを示している。ＬＧＷアーキテクチャ７００は、ＨｅＮＢ７１５と通信しているＬＧＷ７１０を含むことができるＨｅＮＢサブシステム７０５を含んでもよい。ＬＧＷ７１０は、ＳｅＧＷ７２２を介してＳＧＷ７２０と通信していてもよい。ＨｅＮＢ７１５は、ＳｅＧＷ７２２およびＨｅＮＢゲートウェイ（ＧＷ）７２４を介して、ＳＧＷ７２０およびＭＭＥ７２６と通信していてもよい。ＷＴＲＵ７３０は、ＨｅＮＢ７１５と通信していてもよい。

図８は、ＥＰＳに対する例示的なスタンドアロンＬＧＷアーキテクチャ８００を示している。ＬＧＷアーキテクチャ８００は、ＨＮＢ８１５と通信しているＬＧＷ８１０を含むことができるＨＮＢサブシステム８０５を含んでもよい。ＬＧＷ８１０は、ＳｅＧＷ８２２を介してＳＧＷ８２０と通信していてもよい。ＨＮＢ８１５は、ＳｅＧＷ８２２およびＨＮＢ ＧＷ８２４を介して、ＳＧＷ８２０およびＳ４−サービングＧＰＲＳサポートノード（ＳＧＳＮ）８２６と通信していてもよい。ＷＴＲＵ８３０は、ＨＮＢ８１５と通信していてもよい。

図９は、ユニバーサルモバイル通信システム（ＵＭＴＳ）に対する例示的なスタンドアロンＬＧＷアーキテクチャ９００を示している。ＬＧＷアーキテクチャ９００は、ＨＮＢ９１５と通信しているＬＧＷ９１０を含むことができるＨＮＢサブシステム９０５を含んでもよい。ＬＧＷ９１０は、ＳｅＧＷ９２２を介してＳＧＳＮ９２０と通信していてもよい。ＨＮＢ９１５は、ＳｅＧＷ９２２およびＨＮＢ ＧＷ９２４を介してＳＧＳＮ９２０と通信していてもよい。ＷＴＲＵ９３０は、ＨＮＢ９１５と通信していてもよい。

図１０は、ＥＰＳに対するＨｅＮＢサブシステムにおけるＳ１／Ｉｕパス上の例示的なスタンドアロンＬＧＷアーキテクチャ１０００を示している。ＬＧＷアーキテクチャ１０００は、ＨｅＮＢ１０１５と通信しているＬＧＷ１０１０を含むことができるＨｅＮＢサブシステム１００５を含んでもよい。ＬＧＷ１０１０は、ＳｅＧＷ１０２０およびＨｅＮＢ ＧＷ１０２４を介してＳＧＷ１０２０およびＭＭＥ１０２６と通信していてもよい。ＷＴＲＵ１０３０は、ＨｅＮＢ１０１５と通信していてもよい。

図１１は、ＥＰＳに対するＨＮＢサブシステムにおけるＩｕｈパス上の例示的なスタンドアロンＬＧＷアーキテクチャ１１００を示している。ＬＧＷアーキテクチャ１１０５は、ＨＮＢ１１１５と通信しているＬＧＷ１１１０を含むことができるＨＮＢサブシステム１１０５を含んでもよい。ＬＧＷ１１１０は、ＳｅＧＷ１１２２およびＨＮＢ ＧＷ１１２４を介して、ＳＧＷ１１２０およびＳ４−ＳＧＳＮ１１２６と通信していてもよい。ＷＴＲＵ１１３０は、ＨＮＢ１１１５と通信していてもよい。

図１２は、ＵＭＴＳに対するＨＮＢサブシステムにおけるＩｕｈパス上の例示的なスタンドアロンＬＧＷアーキテクチャ１２００を示している。ＬＧＷアーキテクチャ１２００は、ＨＮＢ１２１５と通信しているＬＧＷ１２１０を含むことができるＨＮＢサブシステム１２０５を含んでもよい。ＬＧＷ１２１０は、ＳｅＧＷ１２２２を介して、または、ＳｅＧＷ１２２２およびＨＮＢ ＧＷ１２２４をも介して、ＳＧＳＮ１２２０と通信していてもよい。ＷＴＲＵ１２３０は、ＨＮＢ１１１５と通信していてもよい。

データセッションの継続性は、ローカルネットワークカバレッジとマクロネットワークカバレッジとの間をユーザが移動するときに望ましい場合がある。図１３は、モバイルオペレータコアネットワーク１３０５、マクロネットワーク１３１０、および、ＨｅＮＢサブシステム１３１５を含むことができる例示的なアーキテクチャ１３００を示している。モバイルオペレータコアネットワーク１３０５は、ネットワーク（ＮＷ）エンティティ１３２０を含んでもよく、マクロネットワーク１３１０は、ｅＮＢ１３３０および１３３５を含んでもよく、および、ＨｅＮＢネットワーク１３１５は、ＨｅＮＢ１３３７を含んでもよい。ＷＴＲＵ１３４０は、マクロネットワーク１３１０（すなわち、マクロセル、またはローカルネットワークの一部ではないＨｅＮＢ）を介してローカルネットワーク１３５０に接続してもよい。このことは、マネージドリモートアクセス（ＭＲＡ）またはリモートＩＰアクセス（ＲＩＰＡ）と称される。すなわち、ＭＲＡセッションは、実際のセル（マクロまたはＨｅＮＢ）がローカルネットワークに接続していないときである。ＷＴＲＵ１３４０がローカルネットワーク１３５０のカバレッジエリア内に移動するときに、ＭＲＡセッションは、ＬＩＰＡセッションとして継続されてもよい。この反対も同様に可能である。ＷＴＲＵ１３４０は、ローカルネットワーク１３５０においてＬＩＰＡセッションとして開始してもよく、および、マクロネットワーク１３１０に移動してもよく、当該マクロネットワーク１３１０では、ＬＩＰＡセッションがＭＲＡセッションとして継続される。すなわち、ＬＩＰＡセッションを有するＷＴＲＵは、ローカルネットワークの一部ではないＨｅＮＢに移動してもよい。

図１４は、モバイルオペレータＣＮ１４０５、ＨｅＮＢネットワーク１４１０、およびＨｅＮＢサブシステム１４１５を含むことができる例示的なアーキテクチャ１４００を示している。モバイルオペレータＣＮ１４０５は、ＮＷエンティティ１４２０を含んでもよく、ＨｅＮＢネットワーク１４１０は、ＨｅＮＢ１４３０を含んでもよく、および、ＨｅＮＢサブシステム１４１５は、ＨｅＮＢ１４３５を含んでもよい。ＷＴＲＵ１４４０は、ローカルネットワーク１４５０に接続していないＨｅＮＢ１４３０を使用してＭＲＡセッションを有してもよい。ＷＴＲＵ１４４０がローカルネットワーク１４５０のカバレッジ内に移動し、および、ローカルネットワーク１４５０の一部であるＨｅＮＢ１４３５にハンドオフするときに、ＭＲＡセッションは、ＬＩＰＡセッションとして継続される。上記のＬＩＰＡに関係する例はまた、ＳＩＰＴＯに適用されてもよい。

ハンドオーバプロシージャの実施形態（ＣＥＬＬ＿ＦＡＣＨにおけるモビリティを含む）、および、アーキテクチャのオプションのコンテキストにおける関連する問題について以下で説明される。

非コアネットワークに関連するモビリティ（non-core network involved mobility）をサポートするＨｅＮＢ拡張モビリティ（最適化されたモビリティとも称される）を説明する。このことは、ＨｅＮＢと同一位置に配置されたＬＧＷでＬＩＰＡおよびＳＩＰＴＯ、ならびに、ＨｅＮＢおよびＬＧＷが同一位置に配置されないアーキテクチャ構成に対するサポートを含んでもよい。

図１５は、Ｘ２インタフェースを使用するＨｅＮＢ間ハンドオーバプロシージャに対する例示的なシグナルフロー図１５００である。シグナリングは、ＷＴＲＵ１５０５と、ソースＨｅＮＢ１５１０と、ターゲットＨｅＮＢ１５１５と、ＬＧＷ１５２０と、ＭＭＥ１５２５と、ＳＧＷ１５３０との間でフローしてもよい。ダウンリンクユーザプレーンデータは、ＬＧＷ１５２０からソースＨｅＮＢ１５１０へ、および、ソースＨｅＮＢ１５１０からＷＴＲＵ１５０５へ存在してもよい。汎用パケット無線サービス（ＧＰＲＳ）トンネリングプロトコル（ＧＴＰ）ユーザプレーン（ＧＴＰ−Ｕ）は、ソースＨｅＮＢ１５１０とＬＧＷ１５２０との間で存在してもよい。Ｘ２インタフェースを介してリロケーションをトリガする決定がされてもよい（１）。ハンドオーバ要求が、ソースＨｅＮＢ１５１０からターゲットＨｅＮＢ１５１５に送信されてもよい（２）。ハンドオーバ要求肯定応答（ＡＣＫ）が、ターゲットＨｅＮＢ１５１５からソースＨｅＮＢ１５１０に送信されてもよい（３）。データが、ソースＨｅＮＢ１５１０からターゲットＨｅＮＢ１５１５に転送されてもよい。ＷＴＲＵ１５０５が、ソースＨｅＮＢ１５１０からデタッチし、および、ターゲットＨｅＮＢ１５１５と同期してもよい。パス切替え要求が、ターゲットＨｅＮＢ１５１５からＭＭＥ１５２５に送信されてもよい（４）。修正ベアラ要求が、ＭＭＥ１５２５からＳＧＷ１５３０に送信されてもよく（５）、および、修正ベアラ応答が、ＳＧＷ１５３０からＭＭＥ１５２５に送信されてもよい（６）。パス切替え要求ＡＣＫが、ＭＭＥ１５２５からターゲットＨｅＮＢ１５１５に送信されてもよい（７）。修正ベアラ要求が、ターゲットＨｅＮＢ１５１５からＬＧＷ１５２０に送信されてもよく（８）、および、修正ベアラ応答が、ＬＧＷ１５２０からターゲットＨｅＮＢ１５１５に送信されてもよい（９）。ダウンリンクユーザプレーンデータは、ＬＧＷ１５２０からターゲットＨｅＮＢ１５１５に、および、ターゲットＨｅＮＢ１５１５からＷＴＲＵ１５０５に存在してもよい。ＧＴＰ−Ｕが、ターゲットＨｅＮＢ１５１５とＬＧＷ１５２０との間で存在してもよい。ＭＭＥ１５２５およびＳＧＷ１５３０がハンドオーバプロシージャに依然として関わっていないので、シグナルフロー図１５００は、コアネットワークに対して完全に透過的ではない。

図１６は、ＨＮＢ−ＨＮＢ間で最適化されたハンドオーバに対する例示的なシグナルフロー図１６００である。シグナリングは、ＷＴＲＵ１６０５と、ソースＨＮＢ１６１０と、ターゲットＨＮＢ１６１５と、ＨＮＧ−ＧＷ１６２０との間でフローしてもよい。無線ネットワークサブシステムアプリケーションパート（ＲＮＳＡＰ）ユーザアダプテーション（ＲＮＡ）リロケーション要求メッセージが、ソースＨｅＮＢ１６１０からターゲットＨｅＮＢ１６１５に送信されてもよい（１）。ＨＮＢアプリケーションパート（ＨＮＢＡＰ）アクセス制御クエリが、ターゲットＨｅＮＢ１６１５からＨＮＢ−ＧＷ１６２０に送信されてもよく（２ａ）、および、ＨＮＢＡＰアクセス制御クエリ応答が、ＨＮＢ−ＧＷ１６２０からターゲットＨｅＮＢ１６１５に送信されてもよい（２ｂ）。ＨＮＢＡＰトランスポートネットワークレイヤ（ＴＮＬ）更新要求が、ターゲットＨｅＮＢ１６１５からＨＮＢ−ＧＷ１６２０に送信されてもよく（３ａ）、および、ＨＮＢＡＰ ＴＮＬ更新応答が、ＨＮＢ−ＧＷ１６２０からターゲットＨｅＮＢ１６１５に送信されてもよい（３ｂ）。ＲＮＡ直接転送／ＲＮＳＡＰ拡張リロケーション応答が、ターゲットＨＮＢ１６１５からソースＨＮＢ１６１０に送信されてもよく（４）、および、ＲＮＡ直接転送／ＲＮＳＡＰリロケーションコミットが、ソースＨＮＢ１６１０からターゲットＨＮＢ１６１５に送信されてもよい（５）。無線リソースコントローラ（ＲＲＣ）無線ベアラ（ＲＢ）再構成メッセージが、ソースＨＮＢ１６１０からＷＴＲＵ１６０５に送信されてもよい（６）。

ターゲットＨＮＢ１６１５は、ＷＴＲＵ１６０５同期試行を検出してもよい。ＲＲＣ ＲＢ再構成完了メッセージが、ＷＴＲＵ１６０５からターゲットＨＮＢ１６１５に送信されてもよい（７）。ＨＮＢＡＰリロケーション完了メッセージが、ターゲットＨＮＢ１６１５からＨＮＢ−ＧＷ１６２０に送信されてもよい（８）。ＨＮＢＡＰ ＷＴＲＵ登録解除メッセージが、ＨＮＢ−ＧＷ１６２０からソースＨＮＢ１６１０に送信されてもよい（９）。ＲＮＡ切断／ＲＮＳＡＰ拡張リロケーションシグナリング転送メッセージが、ソースＨＮＢ１６１０からターゲットＨＮＢ１６１５に送信されてもよい（１０）。ＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）の場合、Ｉｕｒｈインタフェースを通じてＨＮＢ−ＨＮＢ間で最適化されたハンドオーバは、ＨＮＢ−ＧＷ１６２０を通過する。

拡張モビリティ（非コアネットワークに関連するハンドオーバまたは透過的コアネットワークハンドオーバ（transparent core network handover））に対する実施形態及びプロシージャが、部分的ハンドオーバが存在する場合について説明される（すなわち、負荷条件または一部の他の理由に起因してターゲットシステムによって特定のベアラを許可することができない）。さらに、非コアネットワークに関連するモビリティのコンテキストにおける非ＷＴＲＵに関連するモビリティ（サービング無線ネットワークサブシステム（ＳＲＮＳ）リロケーションなしのモビリティ）についても説明される。

ＨｅＮＢおよびＨＮＢが同一のＬＮまたはローカルホームネットワーク（ＬＨＮ）において一緒に配置され、ならびに、同一のＬＧＷに接続することができる配備シナリオが存在してもよい。この場合、ＨｅＮＢとＨＮＢとの間でサポートされることになるシームレスＬＩＰＡモビリティに対する実施形態についても説明される。これらの無線アクセス技術（ＲＡＴ）間ハンドオーバ（inter-radio access technology handover）プロシージャは、ユーザプレーンデータにおいて途絶がなく、および、ユーザがハンドオーバの前後で同一のサービス品質（ＱｏＳ）を受けることを保証する。

ＷＴＲＵが一方のＬＧＷと別のＬＧＷと間でカバレッジエリアを移動するときのモビリティ（すなわち、ＬＧＷ間モビリティ）のサポートに対する実施形態についても説明される。ＬＧＷにおいて変更がある場合、ＷＴＲＵのＩＰアドレスは変更することが予期される。ユーザデータのフローに中断がなく、および、このような状況において一方のＬＧＷサブシステムから別のＬＧＷサブシステムにデータを転送するための実施形態についても説明される。

Ｓ１／Ｉｕｈインタフェース上の非ＷＴＲＵ関連プロシージャに対する実施形態についても説明される。これらの実施形態は、ＬＨＮ毎に１または複数のＬＧＷをサポートするという制限からの影響を考慮し、および、複数のＬＧＷを通じてトラフィックをトンネリングすること、または、特定のタイプのトラフィックに対してＬＧＷを完全にバイパスすることとは反対に、単一のＬＧＷを通じてＬＨＮにおけるすべてのＨｅＮＢからのトラフィックすべてをトンネリングするという問題を考慮している。

現在、ＷＴＲＵがＬＨＮから外へ移動するときに、ＬＩＰＡサービスを非活性化する必要性がある。この要件を実装する実施形態が説明される。ＬＨＮ識別子（ＬＨＮ−ＩＤ）が使用されると仮定して、接続モードモビリティの間にＬＨＮ−ＩＤを使用するための実施形態について説明される。

企業配備、ショッピングモール配備、または、空港ターミナルもしくは他の密集したホットスポット配備を検討するときの現在のアーキテクチャオプションは、セル密度、これらのセル間の近接（close proximity）、およびコアネットワークへのセル集約または集中（cell aggregation or concentration toward the core network）に対する機会を利用するようにさらに最適化されてもよい。

ＲＡＮ共有のユースケース（use case）に対する実施形態についても説明される。ＲＡＮ共有は、概して、ＲＡＮネットワークを共有する２以上のオペレータに関するものである。例えば、第三世代（３Ｇ）ネットワークと配備しているロングタームエボリューション（ＬＴＥ）の両方を有している２つのオペレータは、いくつかのエリアにおける取組みに、他のいくつかの地域に個別のＲＡＮを配備しながら、参加することを決定することがある。コアネットワークを有しているオペレータは、別のオペレータからＲＡＮをリースまたは共有することを決定することができる。ＨｅＮＢのコンテキストにおいて、ＲＡＮ共有は、エンタープライズまたはショッピングモールシナリオで行われてもよい。例えば、会社Ｘの従業員は、会社Ｘにフェムトセルサービスを提供するオペレータでないことがある、異なるオペレータからのセルラサービス加入を有することができる。このような場合、従業員は、ローミングアグリーメントを通じて会社Ｘの施設上にいる間に、フェムトセルからセルラサービスを受けることができる。しかし、このことは、ローミングアグリーメントが、従業員にさらなるコストとならないように、および、従業員が、サービスを会社Ｘに提供するフェムトセルネットワークプロバイダによって提供される優遇措置を得るような契約であると仮定している。

別のモデルは、オペレータ間でＲＡＮ共有を有することになる場合がある。従業員は、自分たちが選択したオペレータからサービスを自由に得ることができるが、オペレータ間のＲＡＮ共有アグリーメントを通じて限定加入者グループ（ＣＳＧ）の優遇措置および課金方式の利益を得ることができる。

ＨｅＮＢのコンテキストにおけるＲＡＮ共有の別のユースケースは、ショッピングモールシナリオである。モール全体に配置されたフェムトセルが一面を覆うことがある。数個のオペレータが、共通モールフェムトネットワークを通じてモールにおける小売店にサービスを提供することができる。

ここで考察されているＲＡＮの問題は、これが特にＬＩＰＡ・ＳＩＰＴＯサービス、および、モビリティサポートに対する構成、複数のコアネットワークの間でＬＧＷを共有することの予想される結果（implication）、ならびに、ローミングするときの予想される結果に関係するように、ＬＩＰＡ／ＳＩＰＴＯとＲＡＮ共有との間の相互のやり取りを含む。

同等のパブリックランドモバイルネットワーク（ＰＬＭＮ）（発展型ＰＬＭＮ（ｅＰＬＭＮ））のサポートに対する実施形態は、ｅＰＬＭＮにおけるＬＩＰＡ／ＳＩＰＴＯサービス（アウトバウンド／インバウンドハンドオーバを含むセッション管理およびモビリティ管理に対する影響）のサポートを含めて説明される。

これらの問題のうちの１つは、ＵＴＲＡＮにおいて発生するＣＥＬＬ＿ＦＡＣＨモビリティである。ＣＥＬＬ＿ＦＡＣＨ状態は、ＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の下位状態であり、そこでは、ＷＴＲＵは接続モードにあるが、少量のデータを送信および／または受信することができる。ＣＥＬＬ＿ＦＡＣＨ状態では、ＷＴＲＵは、セル更新などの無線リソース制御（ＲＲＣ）シグナリングプロシージャを実行することができる。このことは、ＲＲＣ更新タイマの満了、データ量の報告を実行すること、または、ＷＴＲＵが別のセルに再選択しおよび新たなセルの再選択／新たなセル内へのモビリティに関してネットワーク（ＲＡＮ）に通知することを望んでいることなどのいくつかの理由によるものとしてもよい。ＣＥＬＬ＿ＦＡＣＨでは、ＷＴＲＵは、別のセルに移動し、または、再選択する場合に、これは接続モードの間にそのようにする。このことは、アイドルモードセル再選択とは異なる。

ＣＥＬＬ＿ＦＡＣＨ状態にいる間にＷＴＲＵが別のセルを再選択した後、ターゲットセル／無線ネットワークコントローラ（ＲＮＣ）（ソースおよびターゲットＲＮＣは同一であってもよい）は、ＷＴＲＵに対するサービスが維持されるようにソースセルからＷＴＲＵのコンテキストをフェッチする必要がある場合がある。

ＷＴＲＵがＨＮＢに接続され、および、ＨＮＢにおいて確立されたＬＩＰＡ ＰＤＮ接続を有している場合、ＬＧＷは、ＨＮＢと同一位置に配置されてもよく、または、ＬＧＷはスタンドアロンである。ＬＩＰＡ ＰＤＮ接続を有しているＷＴＲＵがＣＥＬＬ＿ＦＡＣＨにおいて動作している場合、既存のプロシージャにより、ＷＴＲＵが近隣における別のマクロセルへのセル再選択を実行する可能性がある。このことが発生する場合、ＷＴＲＵは、先に説明されているように、そのモビリティ、したがって新たなセルの選択に関してＲＡＮ／ネットワークに通知するセル更新プロシージャを実行する。したがって、ＣＥＬＬ＿ＦＡＣＨモビリティは、接続モードにおいて発生するＷＴＲＵベースのモビリティであってもよい。ＬＩＰＡモビリティ（すなわち、ＬＩＰＡ ＰＤＮ接続が存在する場合のＷＴＲＵのハンドオーバ）に対して、ソースＨＮＢは、任意のハンドオーバを実行する前に、最終的なハンドオーバに関してＬＧＷに通知してもよく、および、ＬＧＷはＭＭＥへのＰＤＮ接続のリリースをトリガする。しかし、ＨＮＢは、ＣＥＬＬ＿ＦＡＣＨにおいてＷＴＲＵのモビリティに気づかないことがある。

したがって、ＬＩＰＡ ＰＤＮ接続およびリソースのリリースをトリガするＨＮＢの振舞いは、ＣＥＬＬ＿ＦＡＣＨモビリティに使用されなくてもよい。したがって、ＷＴＲＵがソースセルになくても、ＬＩＰＡ ＰＤＮ接続はセットアップのままでいることができ、および、リソースは使用中のままでいることができる。ＳＧＳＮは、ＷＴＲＵがＬＩＰＡ ＰＤＮ接続が確立された元のセルから移動したことをＳＧＳＮが知っている可能性があるので、ＣＥＬＬ＿ＦＡＣＨモビリティは、このことが発生する場合は、ＳＧＳＮをトリガしてＬＩＰＡ ＰＤＮ接続を非活性化することができるノンアクセスストラタム（ＮＡＳ）プロシージャを必ずしもトリガしなくてもよい。したがって、ＬＩＰＡ ＰＤＮ接続があるときに、ＣＥＬＬ＿ＦＡＣＨモビリティに対処する実施形態が説明される。ＬＩＰＡ ＰＤＮ接続が確立されたＨＮＢの外へのモビリティは、ＬＩＰＡ ＰＤＮ接続の非活性化につながる場合がある。しかし、ＬＧＷがスタンドアロンであるとき、別のＨＮＢもしくはマクロセルへのＣＥＬＬ＿ＦＡＣＨにおけるモビリティが、必ずしも、ＬＩＰＡ ＰＤＮの非活性化を意味することではなく、または、非活性化につながるわけではない。

ＭＲＡツーＬＩＰＡハンドオーバ（MRA to LIPA handover）、またはその逆に対して、以下のシナリオが識別されてもよい。図１７に示されている第１のシナリオ１７００において、ＷＴＲＵ１７０５はセル１７１０にある（限定加入者グループ（ＣＳＧ）のみの下で、またはハイブリッドモードのＣＳＧの下で、マクロセルまたはＨｅＮＢセルのいずれか動作している）。セル１７１０の主な特性は、それがＨｅＮＢ１７２５と同一位置に配置することができる１または複数のＬＧＷ１７２０によってサービスされるローカルネットワーク１７１５の一部でないという点である。ＭＲＡセッションは、ローカルネットワーク１７１５の外から、ＩＰＡパーミッションで、または、ＩＰＡパーミッションなしで開始されてもよい。

図１８に示されている第２のシナリオ１８００において、ＷＴＲＵ１８０５は、ローカルネットワーク１８１５の一部であるセル１８１０にあってもよい（ＣＳＧサービスを提供するＨｅＮＢセル、または、ＣＳＧサービスを提供するマクロセルのいずれか）。しかし、ＷＴＲＵ１８０５は、加入情報によりセル１８１０からＬＩＰＡアクセスを得ることを許可されない。ＷＴＲＵ１８０５は、依然として、オペレータのネットワークにアクセスし、および、通常のＰＧＷを通じてＰＤＮ接続を確立してもよい。ＭＲＡセッションは、同一のローカルネットワーク１８１５内でＬＩＰＡパーミッションなしでＣＳＧから開始されてもよい。

上記特定された２つのシナリオで多数の問題点が識別されてもよい。マクロセルまたはそのローカルネットワークの一部でないＨ（ｅ）ＮＢセルのいずれかに接続されているＷＴＲＵ（図１７に示されているように）は、ＭＲＡ特性を通じてローカルサービスにアクセスすることを試みてもよい。生じうる問題の１つは、セルがＬＩＰＡサービスをサポートしないＣＳＧで構成されている場合（すなわち、ソースＣＳＧがＬＩＰＡサービスをサポートしない）にどのようにリモートアクセスを取り扱うかである。ＷＴＲＵがＭＲＡを通じてローカルサービスにアクセスすることを試みている間にハンドオーバが発生したとする場合、ｅＮＢ／Ｈ（ｅ）ＮＢにおいて構成されているターゲットセルがＣＳＧセルとして定義されている場合にとるべきステップ、および、ＣＳＧセルがＷＴＲＵに対するＬＩＰＡサービスを提供しない（すなわち、ターゲットＣＳＧがＬＩＰＡサービスをサポートしない）ことは明らかである。ＷＴＲＵは、図１８においてＣＳＧ２ １８３０によって示されているように、このＷＴＲＵに対するＬＩＰＡサービスをサポートするＣＳＧで構成されているＨ（ｅ）ＮＢに接続されたときに、ローカルネットワーク内でＬＧＷを通じてＬＩＰＡサービスにアクセスすることができる。

同一のローカルネットワーク内に留まりながら、ＷＴＲＵ１８０５は、ＣＳＧで構成することができるが、ＷＴＲＵ１に対するＬＩＰＡサービスをサポートしないセル（例えば、ＣＳＧ１ １８２５）に移動してもよい。ＷＴＲＵがそのセル（例えば、ＣＳＧ１ １８２５）におけるＬＩＰＡサービスを利用することを試みた場合、ＣＳＧ１ １８２５がＷＴＲＵ１８０５に対するＬＩＰＡサービスを許可しないので、その要求は拒絶されることがある。しかし、ＬＩＰＡサービスの代わりにＣＳＧ１ １８２５に接続したままＷＴＲＵ１８０５がＭＲＡサービスを要求した場合に何が発生するか（すなわち、ＷＴＲＵ１８０５が許可されるべきか、および、この場合にシステムの振舞いがどのようなものか）は明確でない。加えて、ＷＴＲＵ１８０５がＣＳＧ２ １８３０においてＬＩＰＡ接続を開始し、および、それがＣＳＧ１ １８２５へのハンドオーバを試みた場合に何が発生するか（すなわち、ハンドオーバが許可されるべきか、ＬＩＰＡ接続がＭＲＡ接続として扱われるべきかどうか、および、この場合にシステムの振舞いがどのようなものであるべきか）は明確でない。

本明細書では、いくつかのシステムエリア、例えば、システムアクセスおよびモビリティ管理、または、モビリティ管理およびハンドオーバに該当し得る例示的な方法を説明する。この目的のために、本明細書において以下で説明される方法は、これらのシステムエリアの下でグループ化されているが、これらがグループ化されるシステムエリアに限定されるべきでない。さらに、グルーピングは、方法の適用可能性を特定の問題／システムエリアに限定することを意図するものではない。したがって、方法は、いくつかのシステムエリア／プロシージャ（すなわち、ＲＲＣ、ノンアクセスストラタム（ＮＡＳ）、または、他の組合せもしくはレイヤ）に適用可能であり、他のシステムエリアの下にある他の方法と組み合わせても適用されてもよい。

本明細書では以下でＬＩＰＡ ＰＤＮ接続による拡張されたＨｅＮＢモビリティに対する実施形態について説明される。

上述のアーキテクチャ構成において、ユーザパスはＨｅＮＢからＨｅＮＢローカルネットワークに配置されたＬＧＷに直接進む。さらに、ＬＮの地理的エリア（企業、ショッピングモール、および、空港など）内で、ユーザは、ＨｅＮＢのカバレッジエリア間を頻繁に移動してもよい。コアネットワーク上のシグナリング負荷を制限するために、そのようなローカルネットワーク内シグナリング（intra-local network signaling）またはフェムトネットワークのホスティングパーティ施設（hosting party premise）の境界内のシグナリングは、コアネットワークが関わることなくローカルノード内に含まれてもよい。ＷＴＲＵが同一のＬＧＷのカバレッジ内で一方のＨｅＮＢから他方に移動したときに、図１５に示されているようにシグナリングがコアネットワーク（ＣＮ）を通ることなくハンドオーバプロシージャが実行されてもよい。

ソースＨｅＮＢは、ハンドオーバを要求するハンドオーバ要求メッセージをターゲットＨｅＮＢに送信してもよい。このメッセージにおいて、ＨｅＮＢは、相関ＩＤ、ＬＧＷ Ｓ５トンネルエンドポイント識別子（ＴＥＩＤ）、または、ターゲットＨｅＮＢとＬＧＷとの間で直接ユーザパスを可能にする他の情報とともに、ターゲットＨｅＮＢにおいて接続をセットアップするために必要なＷＴＲＵコンテキスト情報を送信してもよい。このメッセージを受信すると、ターゲットＨｅＮＢは、ハンドオーバ要求肯定応答で応答し、および、どのベアラを受け付けることができるかをＨｅＮＢに通知してもよい。次いで、ターゲットＨｅＮＢは、パス切替え要求を直接ＬＧＷに送信して、ダウンリンクデータパスをターゲットＨｅＮＢに変更してもよい。この場合、ＬＧＷは、レガシーパス切替えプロシージャの間に、モビリティ管理の役割およびＭＭＥ−ＳＧＳＮの対が行うローカルモビリティアンカリングポイントの役割の両方を行う。ターゲットＨｅＮＢはまた、ハンドオーバに関してＨｅＮＢ ＧＷに通知することによって、ＣＮトラフィックに対するダウンリンクデータパスがターゲットＨｅＮＢに修正されてもよい。

ＨｅＮＢ ＧＷが配備されていないケースでは、ＭＭＥ／ＳＧＷは、ハンドオーバに関して通知されることによって、ＣＮダウンリンクトラフィックに対するデータパスを切り替えてもよい。このことは、ＬＧＷがパス切替え要求を受信したときに、ＬＧＷがメッセージをＳＧＷに送信して、ユーザパスをターゲットＨｅＮＢに修正することによって達成されてもよい。ＬＧＷは、そのユーザパスをＳＧＷが修正したことのインジケーションを受信した後に、パス切替え応答メッセージを送信してもよい。

別の代替的形態において、ならびに、ＬＧＷを通じてルーティングされるトラフィックが存在し（ＬＩＰＡおよび非ＬＩＰＡトラフィック）、および、ＣＮに配置された別のＰＧＷを通じてルーティングされるトラフィックが存在するシナリオについて、２つのパス切替えプロシージャが実行されてもよい（必要ならば同時に）。一方のパス切替えプロシージャがＬＧＷに実行され、および、他方のパス切替えプロシージャがＭＭＥに実行されてもよい。このことは、ベアラ修正プロシージャがＳＧＷおよびＰＧＷに実行されることにつながる。

拡張モビリティプロシージャは、ＬＧＷがＳ１パス上に配置されるアーキテクチャシナリオに適用されてもよい。このケースにおけるＬＧＷは、ＨｅＮＢのコンセントレータ（concentrator）として動作してもよい。パス切替え要求メッセージは、そのまま、ＬＧＷに進んでもよく、および、ＬＧＷは、ＬＩＰＡ ＰＤＮ接続に対してデータパスを切り替えてもよい。ＬＧＷはＳ１パス上にあるので、これはまた、ＣＮにおける任意のエンティティに通知することなくＷＴＲＵが有することができる他のＣＮ ＰＤＮ接続のユーザデータパスを変更してもよい。

ＨｅＮＢとＬＧＷとの間で直接的にパス切替えプロシージャが実行される場合、ＣＮ（すなわち、ＭＭＥ、ＳＧＷ、およびＳＧＳＮなど）は、ＷＴＲＵの新たなセルに気づかないことがある。このことは以下の問題を引き起こすことがある。ＣＮは、ＣＮがサービングセルを知らないので、セッション管理、および、ＷＴＲＵにサービスを提供する正しいセルへのモビリティ管理プロシージャを実行することができない場合がある。この問題は、図７および８に関して説明されているスタンドアロンＬＧＷのケースにおいて特に深刻である。

この問題に対処するための一実施形態では、サービング無線ネットワークサブシステム（ＳＲＮＳ）リロケーションなしのハンドオーバ、すなわち、ＷＴＲＵのＳＲＮＳがそのハンドオーバまたは類似のハンドオーバプロシージャの前後において同一のままでいる、ハンドオーバプロシージャが実行されてもよい。図１９は、ＳＲＮＳリロケーションなしのハンドオーバ後のＵプレーンおよびＣプレーンの例示的なシグナリング図１９００を示しており、そこでは、制御シグナリングパスは変更されないが、ユーザデータパスはターゲットＨｅＮＢ１９０５へ切り替えられる。ＷＴＲＵ１９１０は、無線リソース割り当てに関してターゲットＨｅＮＢ１９０５にハンドオーバされてもよく（すなわち、ターゲットＨｅＮＢ１９０５はドリフト無線ネットワークサブシステム（ＤＲＮＳ）の役割を果たし、および、ＷＴＲＵ１９１０によって使用される無線リソースを制御する）、および、ＳＲＮＳ１９１５とＷＴＲＵ１９１０との間の接続に対し、これらの無線リソースでＳＲＮＳ１９１５をサポートする。ハンドオーバの後、ＳＲＮＳ１９１５は、ＷＴＲＵ１９１０とＲＡＮ（例えば、ＥＵＴＲＡＮ、およびＵＴＲＡＮなど）との間の無線接続を担当することを継続する。ＳＲＮＳ１９１５は、Ｓ１またはＩｕ／Ｉｕｈを終了してもよい。この実施形態では、ＣＮ１９２０とＲＡＮとの間の制御プレーンにおけるシグナリング（Ｓ１−ＭＭＥ、およびＩｕ／Ｉｕｈ上のトラフィック）は、ＳＲＮＳ１９１５（ソースおよびサービングＨｅＮＢ）を通じてルーティングされ続けてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザトラフィック（Ｓ１−Ｕ、Ｉｕ／Ｉｕｈ上のユーザプレーントラフィック）は、ＬＧＷ１９２５から直接、ターゲットＨｅＮＢへルーティングされてもよい。

代わりに、図２０は、ＳＲＮＳリロケーションなしのハンドオーバ後のＵプレーンおよびＣプレーンの例示的なシグナリング図２０００を示しており、そこでは、制御シグナリングおよびデータパスは両方とも同一のままであり、ならびに、ＳＲＮＳ／ソースＨｅＮＢ２００５を通じてルーティングされる。ＷＴＲＵ２０１０は、ターゲットＨｅＮＢ２０１５にハンドオーバされてもよい。ハンドオーバの後、ＳＲＮＳ２００５は、ＷＴＲＵ２０１０とＲＡＮ（例えば、ＥＵＴＲＡＮ、およびＵＴＲＡＮなど）との間の無線接続を担当することを継続する。ＳＲＮＳ２００５は、Ｓ１またはＩｕ／Ｉｕｈを終了してもよい。この実施形態では、ＣＮ２０２０とＲＡＮとの間の制御プレーンにおけるシグナリング（Ｓ１−ＭＭＥ、および、Ｉｕ／Ｉｕｈ上のトラフィック）は、ＳＲＮＳ２００５（ソースおよびサービングＨｅＮＢ）を通じてルーティングされてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザトラフィックは、ＳＲＮＳ２００５（ソースおよびサービングＨｅＮＢ）を通じて、ＬＧＷ２０２５にルーティングされてもよい。

ＳＲＮＳリロケーションなしのモビリティに対する実施形態および関連する実施形態は、図７〜図１２に示されているアーキテクチャ構成に適用されてもよい。さらに、図１０乃至図１２に示されているアーキテクチャ構成のケースでは、制御プレーンパスおよびユーザプレーンパスは、ＣＮが関わることなくＬＧＷによって終了される単一のパス切替えプロシージャを使用して切り替えられてもよい。

別の実施形態では、図２１は、ＳＲＮＳリロケーションなしのハンドオーバ後のＵプレーンおよびＣプレーンのシグナリングの例示的なシグナリング図２１００であり、そこでは、制御シグナリングパスは同一のままであるが、一部のデータパスは同一のままであり、および、一部のデータパスは切り替えられる。ＷＴＲＵ２１１０は、ターゲットＨｅＮＢ２１０５にハンドオーバされる。ハンドオーバの後、ＳＲＮＳ２１１５は、ＷＴＲＵ２１１０とＲＡＮ（例えば、ＥＵＴＲＡＮ、およびＵＴＲＡＮなど）との間の無線接続を担当することを継続する。ＳＲＮＳ２１１０は、Ｓ１またはＩｕ／Ｉｕｈを終了してもよい。この実施形態では、ＣＮ２１２０とＲＡＮとの間の制御プレーンにおけるシグナリング（Ｓ１−ＭＭＥ、およびＩｕ／Ｉｕｈなどの上のトラフィック）は、ＳＲＮＳ２１１５（ソースおよびサービングＨｅＮＢ）を通じてルーティングされ続けてもよく、制御プレーンにおいてパス切替えは存在しない。ユーザプレーンパスは、同一のままであり、および、ＬＧＷ２１２５にルーティングされてもよく、または、またはＣＮ２１２０に切り替えられてもよい。非ＳＲＮＳリロケーション（ＷＴＲＵは関わらない）ハンドオーバは、ＬＩＰＡベアラまたはベアラの組（すなわち、ユーザプレーン２１４０）に対して実行されてもよく、一方、ＳＲＮＳリロケーションハンドオーバは、他のベアラ（すなわち、ユーザプレーン２１５０）に対して実行されてもよい。このようなケースでは、２つのＲＮＳは、ＳＲＮＳの役割を実行しており、各ＲＮＳはベアラまたはＰＤＮ接続の所与のサブセットに対するものである。

ＬＩＰＡ ＰＤＮは、ＣＳＧ毎の加入者ごとをベースに許可されてもよい。このケースでは、加入者チェックは、ハンドオーバプロシージャの前またはハンドオーバプロシージャの間にローカルで実行されてもよい。システムは、ＷＴＲＵ加入者情報がターゲットＣＳＧにおいてＬＩＰＡサービスを許可することを保証する必要がない場合がある。加入者情報は、ＣＳＧ内ハンドオーバのケースではチェックされなくてもよい。

ローカル加入者チェックは、以下の例示的な方法を使用して実行されてもよい。１つの例示的方法において、ＬＧＷは、ＬＩＰＡ ＰＤＮ接続を確立すると、ＣＮノードから加入者情報を取得してもよい。ＬＧＷは、パス切替え要求メッセージを受信したときに加入者をチェックしてもよい。ＬＩＰＡ接続がターゲットＨｅＮＢにおいて許可されない場合、パス切替え失敗メッセージがターゲットＨｅＮＢに送信されてもよい。別の例示的な方法では、加入者情報において更新がある場合、新たな情報がＣＮによってＬＧＷに送信されてもよい。ソースまたはターゲットＨｅＮＢは、加入者情報を有していてもよい。これらのノードは、ＬＧＷが加入者情報を有している事象において、ＣＮから直接的に、または、ＬＧＷからのいずれかで、この情報を取得してもよい。

図１４に示されているハンドオーバプロシージャは、ＨＮＢがＬＧＷに接続され、および、ＷＴＲＵがアクティブなＬＩＰＡ ＰＤＮ接続を有しているときに修正されてもよい。ターゲットＨＮＢが、ハンドオーバに対する要求を受信するときに、ＬＩＰＡが（２ａ）および（２ｂ）においてターゲットセルで許可されているかをＨＮＢーＧＷにクエリしてもよい。このことは、ＨＮＢ−ＧＷがＣＮからのＬＩＰＡ ＣＳＧおよびＬＩＰＡ加入者情報をすでに有していると想定することができる。（３）では、ターゲットＨＮＢは、ＴＮＬ更新要求をＬＧＷに送信して、ターゲットＨＮＢとＬＧＷとの間でトンネルを作成してもよい。（４−６）において、ソースＨＮＢおよびＷＴＲＵは、ハンドオーバ、および、ターゲットＨＮＢに転送されることになるベアラに関して通知されてもよい。ＬＩＰＡベアラをターゲットＨＮＢに転送することができない場合、ＷＴＲＵは、（６）において通知されてもよく、および、ＬＩＰＡ ＰＤＰのコンテキストを非活性化するよう要求されてもよい。

ＷＴＲＵが（６）でハンドオーバコマンドを受信した後、それはターゲットＨＮＢに接続してもよい。次いで、ターゲットＨＮＢは、リロケーションメッセージをＨＮＢ−ＧＷに送信して、ユーザパスをターゲットＨＮＢへ切り替えてもよい。ＬＩＰＡ ＰＤＰコンテキストがまたハンドオーバされるケースでは、パス切替えはＬＧＷにおいて実行されてもよい。このことは、以下の例示的な方法によって実行されてもよい。１つの例示的方法では、ターゲットＨＮＢは、（８）において、２つのリロケーション完了メッセージ、１つはＨＮＢ−ＧＷに、および、他方はＬＧＷに、を送信してもよい。ＬＧＷがこのメッセージを受信するときに、それはデータパスをターゲットＨＮＢに変更してもよい。代わりに、ＨＮＢ−ＧＷがリロケーション完了メッセージを受信するときに、それは、このメッセージまたはインジケーションをＳＧＳＮに転送してもよい。次いで、ＳＧＳＮが、パスをターゲットＨＮＢへ切り替えるようにＬＧＷに要求してもよい。

ＬＩＰＡがアクセス可能でないときのモビリティの間にＬＩＰＡベアラの処理に対する実施形態が本明細書で説明される。モビリティの間に、および、ＬＩＰＡベアラがターゲットセルにおいてサポートされていないときに、ＨｅＮＢは、ノード内シグナリングを使用して、同一位置に配置されたＬＧＷに、ＬＩＰＡ ＰＤＮ接続を解放するよう要求してもよい。ＨｅＮＢは、ＷＴＲＵがＬＩＰＡ ＰＤＮ接続を有していることを、ＷＴＲＵ（発展型）無線アクセスベアラ（（Ｅ）ＲＡＢ）コンテキストにおける相関ＩＤの存在から判定してもよい。次いで、ＬＧＷは、ＰＧＷ開始ベアラ非活性化プロシージャを使用してＬＩＰＡ ＰＤＮ接続の解放を開始し、および、完了してもよい。ＨｅＮＢは、ＷＴＲＵの（Ｅ）ＲＡＢコンテキストが相関ＩＤに対して明確になるまで、ターゲットＲＡＮへのハンドオーバ準備プロシージャを続行しなくてもよい。同一位置に配置されないＬＧＷのケースでは、非活性化は、ターゲットセル、ＬＧＷ、またはＣＮ（例えば、ＭＭＥ、ＳＧＳＮ、およびＨｅＮＢ−ＧＷなど）によって開始されてもよい。例えば、ＷＴＲＵがＬＩＰＡサービスに対する認可されていないとき、ＷＴＲＵがＬＨＮの外へ移動し、または、ターゲットセルの中に移動するときに、ＬＩＰＡベアラは、ターゲットセル、ＬＧＷ、もしくはＣＮ（例えば、ＭＭＥ、ＳＧＳＮ、およびＨ（ｅ）ＮＢ−ＧＷなど）によって非活性化されてもよい。ＷＴＲＵがＬＨＮの外へ移動したことの検出は、ＬＨＮ識別の変更に基づいてもよい。

代替的実施形態において、ソースＨｅＮＢ（またはターゲットＨｅＮＢもしくは任意の他のノード）は、ベアラがターゲットセルにおいてサポートされているかいないかに関わらず、ＬＩＰＡベアラを非活性化しなくてもよい。代わりに、本明細書で以下において説明されているＬＩＰＡベアラサスペンションおよび再開に対する実施形態が使用されてもよい。

本明細書では、ＣＥＬＬ＿ＦＡＣＨにおけるＬＩＰＡ ＰＤＮ接続非活性化に対する例示的な方法が説明される。第１の例示的な方法は、ＣＥＬＬ＿ＦＡＣＨ状態にあるＷＴＲＵが、ＬＩＰＡ ＰＤＮ接続が存在するＨＮＢの外へ移動するときに（例えば、マクロセルに）、ＬＩＰＡ ＰＤＮ非活性化を求めてもよい。

ネットワーク（例えば、ＵＴＲＡＮおよび／またはＳＧＳＮ）は、セル更新プロシージャの間、または、ＣＥＬＬ＿ＦＡＣＨモビリティの間に、ＬＩＰＡ ＰＤＮ接続を非活性化してもよい。代わりに、非活性化は、モビリティが実行された後に行われてもよい。

ＷＴＲＵが、それがＬＩＰＡ ＰＤＮ接続を有していることを知っている場合、ＷＴＲＵは、ルーティングエリア識別が変化していなかった場合でさえも、ＣＥＬＬ＿ＦＡＣＨモビリティの結果として、セル更新プロシージャの間にルーティングエリア更新（ＲＡＵ）を実行してもよい（すなわち、セル更新の代わり、または、セル更新に加えてＲＡＵ送信する）。ＷＴＲＵが、それがＬＩＰＡ ＰＤＮ接続を有していることを知っている場合（セッション管理メッセージ／プロシージャにおけるＳＧＳＮなどのネットワークから受信されたインジケーションに基づいて）、ＲＡＵは、ＣＥＬＬ＿ＦＡＣＨモビリティが発生し、および、ＷＴＲＵが別のセル（マクロまたはＨＮＢ）を移動／再選択した後に、送信されてもよい。

ＳＧＳＮは、ＲＮＣリロケーションプロシージャの結果として（リロケーションが完了しようとしている間、または、完了した後）、ＷＴＲＵのモビリティに気がつくことがある。次いで、ＳＧＳＮは、ＬＩＰＡ ＰＤＮ接続の非活性化をトリガしてもよく、したがって、ＣＮにおいて（すなわち、ＬＧＷへ）、またＷＴＲＵへリソースを解放してもよい。

ＳＧＳＮが、ターゲットＲＮＣからＲＮＣリロケーションに対する要求を受信するときに、ＳＧＳＮは、ＷＴＲＵが新たなセルに移動しているかを検証してもよい（ＷＴＲＵのコンテキストをチェックし、および、潜在的／ターゲットＲＮＣ／ターゲットセルとソースＲＮＣ／セルとを比較してこれが変化しているかを確認することによって）。代わりに、または、加えて、ＳＧＳＮは、ターゲットセル識別（リロケーション要求を介して提供される）を、ＬＩＰＡ ＰＤＮ接続が確立されたソースセルのセル識別と比較してもよい。これら２つの識別子が一致しない場合、ＳＧＳＮは、ＷＴＲＵが移動した（または移動している）と結論付けてもよい。あるいは、ＲＮＣのリロケーションに対する要求が、ＬＧＷおよびＷＴＲＵへのＬＩＰＡ ＰＤＮ接続を非活性化するようＳＧＳＮをトリガしてもよい。

代わりに、ＳＧＳＮは、ＬＧＷアドレスがＲＮＣリロケーション要求において提供されているかを検証してもよい。そうである場合は、ＳＧＳＮは、ＬＧＷアドレスをＷＴＲＵのＬＩＰＡ ＰＤＮ接続に使用されているＬＧＷと比較してもよい。これが同一で場合は、または、ＬＧＷのアドレスが提供されていなかった場合、ＳＧＳＮは、ＷＴＲＵがソースセルの外へ移動したと結論付けてもよい。ＬＴＥリリース１０の仕様では、ＬＧＷアドレスは、ＲＮＣリロケーションを実行するためのＳＧＳＮに関する要求に含まれていない。一実施形態では、このようなメッセージ／要求はまた、ターゲットセル（例えば、ターゲットＨＮＢ）が接続するＬＧＷアドレスを含んでもよい。ＳＧＳＮに関するリロケーション要求は、ターゲットセル／ＲＮＣにおいてＷＴＲＵから受信されたセル更新（ソースへの、したがってＳＧＳＮへのリロケーション要求をトリガする）に起因して、ソースＲＮＣによって送信されてもよい。実施形態は、ＳＧＳＮへのリロケーション要求がソースＲＮＣまたはターゲットＲＮＣによって送信されるかに関わらず適用されてもよい。さらに、ターゲットセル／ＲＮＣは、ターゲットセルがＬＧＷに接続しているかをソースに示してもよく、そうである場合は、ＬＧＷアドレスを提供してもよい。

さらに、ソースＲＮＣ／ＨＮＢが、ターゲットＲＮＣ／セルがＬＩＰＡモビリティをサポートしていないことを知っている場合、ソースＲＮＣ／ＨＮＢは、リロケーションプロシージャの一部としてＳＧＳＮにこのインジケーションを提供してもよい。ソースＲＮＣ／ＨＮＢはまた、ターゲットＲＮＣ／ＨＮＢがＬＧＷに接続しているかをＳＧＳＮに示してもよく、および、場合によっては、ターゲットＲＮＣ／セル／ＨＮＢによって示されるようにＬＧＷのアドレスを提供してもよい。

ＳＧＳＮが、ＷＴＲＵが移動し、または、移動していると結論付ける／気づいた場合（すなわち、ＲＮＣリロケーションを実行する要求の間に）、ＳＧＳＮは、ＬＩＰＡ ＰＤＮ接続を非活性化し、および、ＬＧＷおよび／またはＨＮＢ（ＬＩＰＡ ＰＤＮ接続が確立されれた）にリソースを解放してもよい。あるいは、ＳＧＳＮは、ＨＮＢ（ＬＩＰＡ ＰＤＮ接続が確立された）にリソースを解放してもよく、次いで、ＬＧＷにリソースを解放してもよい。ＳＧＳＮはまた、ＲＮＣリロケーションが実行されている間、または、完了した後に、ＬＩＰＡ ＰＤＮ接続を非活性化するようＷＴＲＵに要求してもよい。

本明細書全体を通じて、ＲＮＣリロケーション要求は、ＲＮＣリロケーションプロシージャを指す。ＲＮＣとＳＧＳＮとの間の実際のメッセージは、異なって識別されてもよいが、プロシージャは同一であってもよい。例えば、実際に使用されるＲＮＣリロケーションメッセージは、「ｒｅｌｏｃａｔｉｏｎ ｒｅｑｕｉｒｅｄ」と呼ばれてもよい。

代替的一実施形態では、ソースＲＮＣは、Ｒｅｌｏｃａｔｉｏｎ ＲｅｑｕｉｒｅｄメッセージをＳＧＳＮに送信する前に、最初に、潜在的モビリティについてＬＧＷに通知してもよい。次いで、ＬＧＷは、ＬＩＰＡ ＰＤＮ接続を非活性化してもよく、および、ＳＧＳＮに、非活性化に対する理由が、ソースＨＮＢ／ＲＮＣによって示されるように、モビリティ、ＲＮＣリロケーション、または、セル更新に起因していることを示してもよい。

本明細書全体を通じて、ソースＲＮＣは、ソースＨＮＢを指してもよい（すなわち、これらは、同一のノードであり、および、ソースＲＮＣは、ソースＨＮＢ、ソースＨＮＢ ＧＷ、またはソースＲＮＣノードを指すために使用されてもよい）。本明細書全体を通じて、ＲＮＣを指すことは、ソースＲＮＣが、あるメッセージをＳＧＳＮに送信している（例えば、「リロケーションが要求された」）実際のエンティティであってもよい、ＨＮＢに要求を往復して中継するかのように解釈されてもよい。したがって、ソースＨＮＢ ＧＷは、ソースＲＮＣであるが中継ノードとして動作していてもよい。あるいは、ＲＮＣの役割は、ＨＮＢ ＧＷによって引き受けられてもよく、当該ＨＮＢ ＧＷは、他のメッセージを介して、もしくは、同一のメッセージを使用することによって、進行中であるメッセージ／プロシージャについて、ＨＮＢが実際のＲＮＤ、および、中継ノードであったＨＮＢ ＧＷであったかのようにＨＮＢに通知してもよい。ＨＮＢおよび／またはＲＮＣは、ハンドオーバ／ＲＮＣリロケーションについて、ならびに、ＭＭＥへのＬＩＰＡ ＰＤＮ接続、および、ＬＧＷとソースＨＮＢ／ＲＮＣ／ＨＮＢ ＧＷとの間のＬＩＰＡ ＰＤＮ接続を解放する必要性について、ＬＧＷに通知する役割を担ってもよい。

ＨＮＢ／ソースＲＮＣは、ＬＩＰＡ ＰＤＮ接続を、接続モードハンドオーバが発生されることになるかのように扱ってもよい（すなわち、ＬＩＰＡ ＰＤＮ接続はリロケーションの前に非活性化される）。さらに、ＬＧＷはまた、ソースＨＮＢ／ＲＮＣ／ＨＮＢ ＧＷをトリガしてリロケーション要求を継続する非活性化の完了についてＨＮＢに通知してもよい（すなわち、ＬＩＰＡ ＰＤＮ非活性化が行われた後）。ＨＮＢは、リロケーション要求メッセージをＳＧＳＮに送信してもよい。ＳＧＳＮは、リロケーション要求の受信がされると（ＬＧＷへの、および／または、Ｓ４インタフェースが存在する場合には、ＷＴＲＵへの）、ＬＩＰＡ ＰＤＮ接続を非活性化してもよく、したがって、ターゲットＲＮＣへのＬＩＰＡコンテキストを含まなくてもよい。

あるいは、ＬＩＰＡ ＰＤＮの非活性化が、ＳＧＳＮへのリロケーションに対する要求が送信される前に行われる場合、ＳＧＳＮは、ＬＩＰＡ ＰＤＮ接続がソースＲＮＣ／ＨＮＢによって解放されたかを検証してもよい。そうでない場合、ＳＧＳＮはそのする動作を行ってもよく、または、リロケーションを拒絶し、および、ソースＲＮＣ／ＨＮＢに、拒絶の理由がＬＩＰＡ ＰＤＮ接続が非活性化されていないことであることを示してもよい。次いで、ソースＲＮＣ／ＨＮＢは、最初に、ＬＩＰＡ ＰＤＮ接続を非活性化し（接続モードハンドオーバに使用されるのと同一のプロシージャにより）、および、ソースＲＮＣ／ＨＮＢは、ＳＧＳＮへのリロケーションプロシージャを再試行してもよい。

あるいは、ＳＧＳＮは、ソースＲＮＣに、リロケーションコマンドを介して、ＬＩＰＡ ＰＤＮ接続が非活性化されたことを示してもよく、および、ＨＮＢは、次いで、ＬＩＰＡリソースを解放するようにＬＧＷに通知してもよい。あるいは、ＳＧＳＮは、ソースＲＮＣに（またはソースＨＮＢ）、リロケーションコマンドを介して、ＬＩＰＡ ＰＤＮ接続がハンドオーバの前に解放される必要があることを通知してもよく、および、ＨＮＢは、次いで、ＬＩＰＡ ＰＤＮ接続を非活性化する必要性についてＬＧＷに通知することを進めてもよい。あるいは、ソースＲＮＣ／ＨＮＢ／ＳＧＳＮは、最初に、ＬＩＰＡコンテキストをターゲットＲＮＣに含めることなく、ハンドオーバ／リロケーションを進めてもよく、次いで、リロケーションと並行して、またが、リロケーションが完了した後に、ソースＨＮＢ／ＲＮＣは、ＬＩＰＡ ＰＤＮ接続を非活性化するようにＬＧＷに通知してもよい。

ＷＴＲＵのＣＥＬＬ＿ＦＡＣＨモビリティが完了した後、ＳＧＳＮは、ＷＴＲＵへのＬＩＰＡ ＰＤＮ接続の非活性化をトリガしてもよい。例えば、ＳＧＳＮがターゲットＲＮＣからリロケーション完了メッセージを受信するときに、ＳＧＳＮは、ＬＧＷへの接続を非活性化してもよく（すでにそうしていなければ）、および、ＷＴＲＵへのＬＩＰＡ ＰＤＮ接続を非活性化してもよい。

ＣＥＬＬ＿ＦＡＣＨモビリティ（例えば、セル更新プロシージャ）が、ＳＧＳＮの変更つながる場合、古い／ソースＳＧＳＮは、ＬＩＰＡコンテキストをターゲット／新ＳＧＳＮに転送しなくてもよく（例えば、リロケーション転送要求において）、および、ソースＳＧＳＮは、ＬＩＰＡベアラまたはコンテキストを含まなくてもよい。

ＷＴＲＵは、それがＬＩＰＡ ＰＤＮ接続が存在することを知っている場合にＣＥＬＬ＿ＦＡＣＨモビリティを無効化してもよい。

あるいは、ソースＲＮＣ／ＨＮＢがＲＮＣリロケーションを実行する要求を受信したときに、ソースＲＮＣ／ＨＮＢは、対象のＷＴＲＵに対するアクティブなＬＩＰＡ ＰＤＮ接続が存在する場合に、リロケーションを実行しないことを選択してもよい。したがって、ソースＲＮＣは、制御パスとデータパスの両方に対するアンカリングポイントのままであってもよい。さらに、ソースＲＮＣは、確立されたトンネルを介してＬＩＰＡデータをターゲットＲＮＣに転送することを維持してもよく、および、ＬＩＰＡ ＰＤＮ接続が維持されてもよい。ＳＧＳＮは、例えば、リロケーション要求を拒絶し、ならびに、新たな原因コードを使用してソースＲＮＣ／ＨＮＢに、アンカリングポイントを維持し、および、ＬＩＰＡデータをターゲットＲＮＣへ転送するように通知することによって、ソースＲＮＣ／ＨＮＢにそうするように通知してもよい。

あるいは、ＷＴＲＵが非ＬＩＰＡベアラを有している場合、ネットワークは、ＲＮＣリロケーションが実行されていない場合でさえも、ＬＩＰＡベアラを非活性化し、および、非ＬＩＰＡベアラを維持することを決定してもよい。このことは、ソースＲＮＣ／ＨＮＢにおける決定／構成に基づいてもよく、または、ＳＧＳＮにおける決定／構成に基づいていてもよい。

別の実施形態では、ＵＰＬＩＮＫ ＳＩＧＮＡＬＩＮＧ ＴＲＡＮＳＦＥＲメッセージが、ターゲットＲＮＣによって使用されて、共通制御チャネル（ＣＣＣＨ）上で受信されたＵｕメッセージをサービングＲＮＣ（ＳＲＮＣ）に転送してもよい。セル更新は、これらのメッセージのうちの１つである。セル更新プロシージャの間に、ＵＰＬＩＮＫ ＳＩＧＮＡＬＩＮＧ ＴＲＡＮＳＦＥＲメッセージを受信すると、ソースＲＮＣは、ＳＲＮＣ無線ネットワーク一時識別子（Ｓ−ＲＮＴＩ）を検証してもよく、および、ターゲットＲＮＣに移動したＷＴＲＵがＬＩＰＡベアラを有していたかを判定してもよい。Ｓ−ＲＮＴＩによって識別されたＷＴＲＵがＬＩＰＡベアラを有していた場合、ソースＲＮＣは、これらのベアラをリリースすることができることを同一位置に配置されたＬＧＷに通知してもよい。

実施形態は、選択されたアーキテクチャに依存してもよい。例えば、ＨＮＢは、Ｓｘｘインタフェースを使用して、ＬＧＷにおけるＬＩＰＡリソースを解放してもよい。図７乃至図９で表されているようなアーキテクチャソリューション１について、新たな制御プロトコルが導入されてもよく、または、ＩｕｈもしくはＩｕｈｒプロトコルが修正されてＨＮＢ ＧＷまたはＨＮＢ自体がＬＧＷにおけるＬＩＰＡリソースの開放を要求することを可能にすることができる。

上記の実施形態すべては、ソースＲＮＣおよびターゲットＲＮＣが同一のノードである場合、または、これらが異なるノードである場合に適用してもよい。

ＬＴＥリリース１１では、ＬＧＷは、ローカルネットワーク（ＬＮ）においてスタンドアロンであってもよく、そのため、ＨｅＮＢ間のＷＴＲＵモビリティは、ＬＩＰＡ ＰＤＮ接続の非活性化を必ずしもトリガしなくてもよい。ＷＴＲＵがＬＮからマクロレベルに移動するときのケースについて、ＬＩＰＡサービス継続性がそのマクロセルから提供されない場合、ＬＩＰＡ ＰＤＮ接続非活性化が行われてもよい。このケースでは、ＬＴＥリリース１０について本明細書において上述されたＣＥＬＬ＿ＦＡＣＨモビリティに対する実施形態が実装されてもよい。

以下の実施形態は、ＷＴＲＵがＬＮ ＰＤＮ接続においてＬＩＰＡまたはＳＩＰＴＯを有していると仮定して、１つのＨｅＮＢから他方へのＣＥＬＬ＿ＦＡＣＨモビリティに対して以下の実施形態が提供される。

ＷＴＲＵが、それがＬＩＰＡ ＰＤＮ接続を有していることを知っている場合、ＷＴＲＵは、このインジケーションをセル更新メッセージに含めてもよい（これは、セル更新がＣＥＬＬ＿ＦＡＣＨにおけるモビリティに起因する場合であっても適用してもよい）。ターゲットセル（ソースセルがターゲットセルであってもよい）が、セル更新メッセージを受信するときに（単に、ＣＥＬＬ＿ＦＡＣＨにおけるモビリティに起因するものではなく）、ターゲットセル／ＨｅＮＢは、ＣＮ（例えば、ＳＧＳＮ）に、ＷＴＲＵがセル更新を送信するターゲットセルのセルＩＤについて通知してもよい。このことは、ＲＮＣを介して行われてもよい。次いで、ＣＮ／ＳＧＳＮは、この情報を使用して、ＬＩＰＡベアラ／サービスが例えば加入者情報に基づいて、ターゲットＨｅＮＢで継続されてもよいか否かを決定してもよい。ターゲットセルは、コンテキストのフェッチ（fetching）が実行される前に（例えば、必要であれば、ＨＮＢ間のフォワードアクセスチャネル（ＦＡＣＨ）モビリティに起因して）この情報をＣＮに送信してもよい。あるいは、このことは、ＷＴＲＵコンテキストがソースＨＮＢからフェッチされた後に行われてもよい。

セル更新プロシージャの間に（例えば、ＣＥＬＬ＿ＦＡＣＨにおけるＷＴＲＵのモビリティに起因して）、ＷＴＲＵコンテキストがフェッチされ、および、ターゲットセルに転送される前に、ローカルネットワークサービスにおけるＬＩＰＡ／ＳＩＰＴＯサービスをターゲットセルにおいて継続することができるか否かを検証してもよい。このチェックは、ソースセルと通信することによって、またはＣＮ（ＳＧＳＮであってもよい）と通信することによってターゲットセルにより行われてもよい。例えば、ターゲットＨＮＢは、対象のＷＴＲＵに対してセル更新プロシージャが差し迫っていることをＣＮ／ＳＧＳＮに通知してもよい。次いで、ＳＧＳＮは、ＬＩＰＡ／ＳＩＰＴＯサービスが、ＷＴＲＵに対してそれがもし存在する場合は、ターゲットセルにおいて継続することができるか否かを検証してもよい。ＳＧＳＮはまた、ターゲットＨＮＢに応答してもよく、ならびに、セル更新を受け付けることができるかを示してもよく、または、ＬＩＰＡ／ＳＩＰＴＯサービスを継続することができるか否かを示してもよい。ＳＧＳＮはまた、ＬＧＷアドレスおよび／またはＬＩＰＡ／ＳＩＰＴＯサービスを継続するために必要な他の情報を提供してもよい。この情報は、例えば、相関ＩＤであってもよい。ＣＮによるこのチェックは、コンテキストがＷＴＲＵに対してフェッチされた後に実行されてもよい。ＳＧＳＮからのこのようなアドレス情報の存在は、ＬＩＰＡ／ＳＩＰＴＯがＷＴＲＵに対して維持されてもよいことをターゲットセルに暗示するものであってもよい。ＣＮは、サービスがＬＩＰＡ、ＳＩＰＴＯ、またはその両方であるかを示す情報をターゲットセルに提供してもよい。ルール／加入者が、ＷＴＲＵがターゲットにおいてサービス継続性を有することができることを示す場合、ＣＮ／ＳＧＳＮはセル更新を拒絶してもよい。このことは、プロシージャの失敗、または、ＷＴＲＵをソースセルに戻すリダイレクションをつながってもよい。

ＣＮは、セル更新プロシージャの前または後にチェックを実行してもよい。ＣＮによって行われる検証は、ローカルネットワークにおけるＬＩＰＡ／ＳＩＰＴＯがターゲットにおいて提供されてもよいかを判定することを含んでもよい。このことは、ＷＴＲＵ加入者情報、および／または、ターゲットセルがＨＮＢに接続するか否かなどに基づいていてもよい。ＣＮは、例えば、サービスをターゲットにおいて維持することができない場合に、ＬＩＰＡ／ＳＩＰＴＯ ＰＤＮ接続を非活性化することを決定してもよい。この非活性化は、セル更新プロシージャが完了する前または後に行われてもよい。

ソースセルは、ターゲットセルがＷＴＲＵに対してＬＩＰＡ／ＳＩＰＴＯサービス継続性を提供することができるかを検証してもよい。このことは、ターゲットセルがＬＧＷに接続するか、および／または、ＷＴＲＵの加入者がターゲットセルにおけるこのサービス継続性を許可するかに基づいていてもよい。この情報は、ソースセルにおいてすでに利用可能であってもよい。あるいは、ソースセルは、ＣＮノード（ＳＧＳＮまたはＬＧＷであってもよい）をプローブ（probe）して、このＬＩＰＡ／ＳＩＰＴＯ ＰＤＮ接続をターゲットセルにおいて維持することができるかを検証してもよい。ソースは、このインジケーションをＳＧＳＮに送信し、ならびに、ターゲットセルおよびＬＧＷの識別を提供することによって、ＳＧＳＮがソースセルに応答し、ならびに、ＬＩＰＡ／ＳＩＰＴＯをターゲットセルにおいて維持することができるかを示すようにしてもよい。ＳＧＳＮ／ＣＮが、このサービスを維持することができることを示す場合、ソースは、コンテキストをターゲットセルに提供し、および、ＬＩＰＡ／ＳＩＰＴＯコンテキスト／ベアラ／情報を含めてもよい。

あるいは、ＣＮ／ＳＧＳＮが、サービスをターゲットセルにおいて維持することができないことを示す場合、ソースセルは、ＬＩＰＡ／ＳＩＰＴＯ ＰＤＮ接続を非活性化することをＬＧＷに通知してもよい。ＳＧＳＮはまた、この非活性化も実行し、および、それをソースＨＮＢに示してもよい。ソース／ターゲットセルおよびＣＮ／ＳＧＳＮは、これらのノード間の通信に使用されるインタフェース上で既存のメッセージまたは新たなメッセージを使用することによって、本明細書で上述された要求／応答を介して情報を交換してもよい。このことは、本明細書で上述されているすべての実施形態に適用可能である。したがって、ソースセルは、ローカル情報またはＣＮ／ＳＧＳＮからの情報に基づいて、ＬＩＰＡ／ＳＩＰＴＯコンテキスト／ベアラ／情報をセル交信プロシージャの一部としてターゲットセルに含めるか、または、含めないかを決定してもよい。サービスを維持することができる場合、ターゲットセルは、ＬＩＰＡ／ＳＩＰＴＯトラフィックに対するトンネル／ユーザパスを作成することをＬＧＷに通知してもよい。あるいは、ＣＮまたはソースＨＮＢは、サービスをターゲットセルにおいて維持することができるかの決定に基づいて、ターゲットＨＮＢへのデータパスを更新することをＬＧＷに通知してもよい。

ＬＩＰＡベアラのサスペンションおよび再開に対する実施形態について以下で説明される。シームレスなＬＩＰＡモビリティは、ＬＩＰＡベアラのサスペンションおよび再開を通じて遂行されてもよい。ＷＴＲＵがＬＩＰＡカバレッジの外へ移動するときに、ＬＩＰＡベアラはサスペンドされてもよい。ＬＩＰＡベアラは、ＷＴＲＵがＬＩＰＡをサポートする別のセルに戻るときに再開されてもよい。ソースセルが、ＬＩＰＡベアラをターゲットセルにハンドオーバすることができないと判定したときのハンドオーバプロシージャの間に、ソースセルはこれらのベアラに対するコンテキストを取り除き、および、ＬＩＰＡ ＰＤＮ接続を非活性化することをＬＧＷ、ＭＭＥ、または他のノードに通知しない。それは、ＰＤＮ接続がまだアクティブであるが、ターゲットセルにおいてはベアラが現在セットアップされていないことを示す特別なインジケーションをＬＧＷおよびＣＮノードに送信してもよい。このインジケーションを受信すると、ＬＧＷは、ＷＴＲＵに対するすべてのダウンリンク（ＤＬ）トラフィックをバッファリングすることを開始してもよい。バッファリングされたトラフィックは、ＷＴＲＵがＬＩＰＡカバレッジに入り、および、ＬＩＰＡベアラがＬＩＰＡトラフィックに再開されるときに、ＷＴＲＵに送信されてもよい。ＬＩＰＡベアラがサスペンドされたときに開始するタイマがネットワークにおいて存在してもよく、および、ＷＴＲＵが、タイマが満了する前にＬＩＰＡカバレッジに戻らない場合に、ＬＩＰＡ ＰＤＮ接続は非活性化され、および、ＬＧＷにおいてバッファリングされているすべてのデータが破棄されてもよい。この実施形態はまた、ＷＴＲＵがＬＮ内で移動するときのシナリオに適用されてもよい。ＬＩＰＡベアラは、ＷＴＲＵがＬＮの外に移動し、または、マクロネットワークのカバレッジ内に移動するときに、非活性化されてもよい。

ＷＴＲＵがアイドルモードに入り、および、それがＬＩＰＡベアラをサスペンドしている場合、以下のアクションのうちの１または複数が実行されてもよい。１つのアクションにおいて、タイマは停止されてもよく、および、ＷＴＲＵが接続モードに戻ったときにそれは再開してもよい。別のアクションでは、ＷＴＲＵがトラッキングエリア更新（ＴＡＵ）／ルーティングエリア更新（ＲＡＵ）を実行するときに、ネットワークは、ＷＴＲＵがキャンプオンするセルがＬＩＰＡをサポートしているかをチェックしてもよい。そのセルがＬＩＰＡをサポートしている場合、ベアラは再開され、および、ＬＧＷはバッファリングされているデータをＷＴＲＵに送信してもよい。ネットワークは、ＷＴＲＵがＬＮカバレッジの外へ移動したことを認識すると、ＬＩＰＡ ＰＤＮ接続は非活性化されてもよい。別のアクションでは、ネットワークがページングメッセージを送信したとき、または、サービス要求が存在するときに、ネットワークは、現在のセルがＬＩＰＡをサポートしている場合にＬＩＰＡベアラを再開し、および、バッファリングされたデータを送信することを試みえもよい。ネットワークは、ＷＴＲＵがＬＩＰＡカバレッジの外へ移動した場合にベアラを非活性化してもよい。

ＬＩＰＡベアラのサスペンションに対するトリガは、ＷＴＲＵがＬＮの外へ移動したことを検出すること、ターゲットセルがＬＩＰＡをサポートしていることを検出すること、ベースとなっているネットワークポリシ（network policy based）、ネットワークインジケーション、および、ユーザインジケーションなどを含んでもよいが、それらに限定されない。

ＬＩＰＡベアラの再開に対するトリガは、ＷＴＲＵがＬＮカバレッジに戻り、および、ＬＮにおけるＬＩＰＡへのアクセス権を有していることを検出すること、ターゲットセルがＬＩＰＡをサポートしており、および、ＷＴＲＵがターゲットセルにおいてＬＩＰＡへのアクセス権を有していることを検出すること、ベースとなっているネットワークポリシ、ネットワークインジケーション、ＬＩＰＡベアラ再開タイマの満了、ならびに、ユーザインジケーションなどを含むが、これらに限定されない。

ＬＩＰＡベアラのサスペンションのイニシエータは、ソースセルであってもよい。例えば、非コアネットワークが関わるモビリティの間に、ソースセルはＬＩＰＡのサスペンションを開始してもよい。ＬＩＰＡサスペンション要求またはインジケーションは、ハンドオーバ要求メッセージの一部として、他のリロケーションメッセージもしくはコンテキスト転送応答メッセージの一部として、または、別のメッセージにおいてターゲットセルに送信されてもよい。次いで、ターゲットセルは、そのようなインジケーションを、例えば、パス切替え要求メッセージにおいて、ＬＧＷに中継してもよい。ソースセルは、ＷＴＲＵコンテキストを保持し、ならびに、ＬＩＰＡベアラ構成および／またはコアネットワーク（および／またはＬＧＷ）へ割り当てられたリソースを削除せずに、そのようなベアラをサポートしてもよい。ソースセルは、構成可能なタイマを開始してもよい。ソースセルがＷＴＲＵコンテキストおよび関連付けられたＬＩＰＡベアラを保持する期間は、そのようなタイマによって制御されてもよい。

ＬＩＰＡベアラの一時停止のイニシエータは、ターゲットセルであってもよい。例えば、非コアネットワークが関わるモビリティにおいて、ターゲットセルは、例えば、ＷＴＲＵがターゲットセルにおいてＬＩＰＡアクセス権を有していないと判定された後に、ＬＩＰＡの一時停止を開始することができる。次いで、ターゲットセルは、そのような指示を、例えば、パス切替え要求メッセージに入れて、ＬＧＷに送信することができる。

ＬＩＰＡベアラのサスペンションのイニシエータは、ＬＧＷであってもよい。ＬＧＷは、ＬＩＰＡはベアラのサスペンションを開始するために、ユーザＬＩＰＡ加入者情報を含む必要なすべての情報を有するように構成されてもよい。

ＬＩＰＡベアラのサスペンションのイニシエータは、ＨｅＮＢ ＧＷを含むコアネットワークであってもよい。例えば、コアネットワークが関わるハンドオーバ／リロケーションの間に、コアネットワークはベアラのサスペンションを開始してもよい。

ターゲットセルは、ＬＩＰＡサスペンション要求またはインジケーションを受信してもよい。非コアネットワークが関わるモビリティの間に、ＬＩＰＡベアラサスペンション要求／インジケーションを受信すると、ターゲットセルは、ＬＩＰＡベアラリソースを割り当てなくてもよい。加えて、ターゲットセルは、ＷＴＲＵへのこのような要求／インジケーションを（明示的に、または黙示的に）ハンドオーバコマンドコンテナ（ソースセルを介してＷＴＲＵに送信される）内に含めてもよい。ターゲットセルは、例えば、パス切替え要求メッセージにおいて、ベアラサスペンション要求／インジケーションをＬＧＷ（またはＨｅＮＢ ＧＷもしくはコアネットワークが関わるハンドオーバのケースではコアネットワーク）に中継してもよい。ターゲットセルは、その後のハンドオーバまたはリロケーションの間に、後続のターゲットセルにＬＩＰＡベアラ構成情報を転送してもよい。

ＷＴＲＵは、他のＲＲＣメッセージのようにハンドオーバコマンドの一部としてＬＩＰＡサスペンション要求／インジケーションを受信してもよい。ＬＩＰＡベアラサスペンション要求／インジケーションを受信すると、ＷＴＲＵは、アプリケーションレイヤに通知してもよい。そして、アップリンクＬＩＰＡベアラトラフィックがサスペンドされてもよい。ＷＴＲＵはまた、コアネットワークまたはピアＷＴＲＵにそのようなサスペンションを通知してもよい。ＷＴＲＵはまた、そのＣＳＧホワイトリストを更新し、したがって、ＷＴＲＵがターゲットセルにおいてＬＩＰＡアクセス権を有していないという事実を反映してもよい。

ＬＧＷは、Ｓｘｘインタフェース、Ｓ１インタフェース、Ｉｕｈインタフェース、Ｓ５インタフェース、または他のインタフェース上でＬＩＰＡベアラサスペンション要求／インジケーションを受信してもよい。ＬＩＰＡベアラサスペンション要求／インジケーションを受信すると、ＬＧＷは、ダウンリンクＬＩＰＡベアラトラフィックをバッファリングしてもよい。ＬＧＷは、その後のハンドオーバまたはリロケーションの間に、後続のターゲットセルにＬＩＰＡベアラ構成情報を転送してもよい。ＬＧＷは、ＬＩＰＡベアラをサスペンドすると、タイマを起動してもよい。

ソースセルは、ＬＩＰＡベアラサスペンション要求／インジケーションを受信してもよい。ＬＩＰＡベアラサスペンション要求／インジケーションを受信すると、ソースセルは、ＷＴＲＵコンテキストを保持し、および、ＬＩＰＡベアラ構成および／またはコアネットワーク（および／またはＬＧＷ）へ割り当てられたリソースを削除せず、そのようなベアラをサポートしてもよい。ソースセルは、構成可能なタイマを開始してもよい。ソースセルがＷＴＲＵコンテキストおよび関連付けられたＬＩＰＡベアラを保持する期間は、そのようなタイマによって制御されてもよい。

ＣＮは、ＬＩＰＡベアラサスペンション要求／インジケーションを受信してもよい。ＣＮは、ＨｅＮＢ−ＧＷ、ＭＭＥ／Ｓ−ＧＷ／ＰＧＷ、およびＳＧＳＮ／ＧＧＳＮなどを含んでもよいが、それらに限定されない

本明細書では、ＬＩＰＡ ＰＤＮ接続によるＲＡＴ間ハンドオーバに対する実施形態について説明される。ＲＡＴ間ハンドオーバは、ＨｅＮＢおよびＨＮＢが同一のＬＧＷの下に配備されたときに、ＬＩＰＡ ＰＤＮで実行されてもよい。ＷＴＲＵは、ＨｅＮＢとＨＮＢとの間を移動するときに、ＬＧＷを通してローカルネットワークまたはインターネットへのシームレスなデータ接続性を維持してもよい。このタイプのハンドオーバは２つの異なるシステムの間のハンドオーバなので、シグナリングはＣＮを通ってもよい。ソースセルがハンドオーバプロシージャをトリガすることに決めたときに、それはハンドオーバ要求メッセージをその各ＣＮネットワークノードに送信する。例えば、ＨｅＮＢは、メッセージをＭＭＥに送信し、および、ＨＮＢは、メッセージをＳＧＳＮに送信する。このメッセージにおいて、ソースセルは、アクティブなＬＩＰＡ ＰＤＮ接続が存在し、および、ＬＩＰＡベアラがターゲットセルに転送される必要があることを示してもよい。ソースシステムは、ＬＩＰＡベアラをハンドオーバすることができるかを要求するメッセージをターゲットシステムに送信し（例えば、ＭＭＥはメッセージをＳＧＳＮに送信する）。ソースシステムは、ＷＴＲＵコンテキスト情報を、相関ＩＤまたはＬＧＷ Ｓ５トンネルエンドポイントＩＤ（ＴＥＩＤ）とともにターゲットシステムに送信してもよい。ＬＧＷアドレスまたは一部の他のＬＧＷＩＤはまた、両方のセルが同一のＬＧＷに接続されていることを保証するためターゲットシステムに転送されてもよい。

ベアラ情報、相関ＩＤ、および／またはＬＧＷアドレス（もしくはＩＤ）は、それがＬＩＰＡベアラを受け付けるか否かを決定することができる、ターゲットセルに送信されてもよい。そして、受け付けられたベアラ情報がソースシステムに送信されることによって、いくつかのベアラが受け付けられない場合に、ソースおよびＬＧＷがベアラに対するリソースを解放してもよい。ターゲットセルは、ＬＧＷとのユーザプラン接続を作成し、および、アップリンク（ＵＬ）ＴＥＩＤをＵＬデータに対するＬＧＷと交換してもよい。

ＨｅＮＢからＨＮＢへのハンドオーバのケースでは、ＬＧＷは、ＳＧＳＮとの接続を作成してもよい。この接続は、直接ＬＧＷ−ＳＧＳＮ間インタフェースを通じて、または間接的にＳＧＷを介して作成されてもよい。第１のケースでは、新たなトンネルが、ハンドオーバの間にＬＧＷとＳＧＳＮとの間に作成されてもよい。このトンネルに関して新たなＬＧＷ ＴＥＩＤが存在してもよい。ＳＧＳＮは、このＴＥＩＤを相関ＩＤとして送信して、ＨＮＢとＬＧＷとの間の直接ユーザパスを有効にしてもよい。第２のケースでは、ＬＧＷとＳＧＷとの間のＳ５インタフェースはハンドオーバの間に変化せず、したがって同一のＬＧＷ Ｓ５ＴＥＩＤは相関ＩＤとして使用されてもよい。ＳＧＷは、そのそれぞれのＨＮＢに転送するハンドオーバプロセスの間に、このＴＥＩＤをＳＧＳＮに転送してもよい。上述の２つの実施形態はまた、ＨＮＢからＨｅＮＢへのハンドオーバに適用してもよい。

ＬＧＷ間モビリティに対する実施形態が本明細書において説明される。中断なしのモビリティは、ＷＴＲＵが１つのＬＧＷのカバレッジから別のＬＧＷのカバレッジへと移動するときにサポートされてもよい。ＬＧＷに変化があるときに、ＷＴＲＵ ＩＰアドレスまたはＩＰアクセスポイント（ＰＯＰ）は変化してもよい。このことは、ユーザプレーンデータにおける途絶を引き起こすことがある。これを回避するために、ソースＬＧＷシステムからターゲットＬＧＷシステムへのデータ転送がサポートされてもよい。

図２２は、ソースＬＧＷ２２０５とターゲットＬＧＷ２２１０との間の直接インタフェース２２００に対する実施形態を示している。特に、直接インタフェース２２００は、シームレスなＬＧＷ間モビリティに対するデータ転送のために、ソースＬＧＷ２２０５とターゲットＬＧＷ２２１０との間で提供されてもよい。ハンドオーバプロシージャの間に、ソースＨｅＮＢ２２１５は、異なるＬＧＷ、すなわち、ＬＧＷ２２１０によってターゲットＨｅＮＢ２２２５にサービスされることを気付いてもよい。ソースＨｅＮＢ２２１５は、ＭＭＥ（図示せず）、ＬＧＷ２２０５、またはターゲットＨｅＮＢ２２２５からこの情報を取得してもよい。ソースＨｅＮＢ２２１５はまた、ターゲットＬＧＷ２２１０のアドレスまたは一部の他のタイプの識別を取得してもよい。ターゲットＨｅＮＢ２２２５は、ソースＨｅＮＢ２２１５に、それがＬＩＰＡベアラとのＬＧＷ間ハンドオーバをサポートしているかを通知してもよい。ハンドオーバがサポートされ、および、ターゲットＨｅＮＢ２２２５が２つのＬＧＷ間のトンネルの確立をサポートしている場合、ソースＨｅＮＢ２２１５は２つのＬＧＷの間の直接トンネルの確立を続行してもよい。ソースＬＧＷ２２０５は、ソースＨｅＮＢ２２１５またはＭＭＥによって提供されるターゲットＬＧＷ２２１０のアドレスを使用して、直接トンネルを確立してもよい。直接トンネルが確立された後、ソースＬＧＷ２２０５は、ユーザデータをターゲットＬＧＷ２２１０に転送してもよく、そして、ターゲットＬＧＷ２２１０はターゲットＬＧＷ２２１０とターゲットＨｅＮＢ２２２５との間の直接パスを介してデータをＷＴＲＵ２２３０に送信する。

ターゲットＨｅＮＢ２２２５へ転送されたデータは、多数の方法を使用して行われてもよい。例えば、ソースＬＧＷ２２０５は、ＩＰ ＰＯＰのままでもよい。ＷＴＲＵ２２３０が、新たなＬＧＷ（すなわち、ターゲットＬＧＷ２２１０）に移動するときに、ＷＴＲＵ２２３０のＩＰアドレスは変更しなくてもよい。ソースＬＧＷ２２１５がＷＴＲＵ２２３０に対するデータを受信したときにはいつでも、それは、データをターゲットＬＧＷ２２１０に転送してもよい。ターゲットＬＧＷ２２１０は、元のＬＧＷ（すなわち、ソースＬＧＷ２２０５）とターゲットＨｅＮＢ２２２５との間の中継器として動作してもよい。

あるいは、ＷＴＲＵ２２３０は、ターゲットＬＧＷ２２１０との新たなＰＤＮ接続を確立してもよい。ターゲットＬＧＷ２２１０は、新たなＩＰアドレスをＷＴＲＵ２２３０に提供してもよく、したがって、このことはＷＴＲＵ２３００のＩＰ ＰＯＰとなってもよい。ソースＬＧＷ２２０５は、ターゲットＬＧＷ２２１０にデータを転送してもよく、および、ターゲットＬＧＷ２２１０は、このデータを新たなＰＤＮ接続を介してＷＴＲＵ２２３０に送信してもよい。

図２３は、Ｘ２／Ｉｕｒｈインタフェース２３００を介してデータ転送が行われる別の実施形態を示している。特に、Ｘ２／Ｉｕｒｈインタフェース２３００は、シームレスなＬＧＷ間モビリティに対するデータ転送に使用されてもよい。Ｘ２またはＩｕｒｈインタフェース２３００を介してのデータ転送は、システムのタイプに依存することがある。ＷＴＲＵ２３０５が異なるＬＧＷ２３１５でターゲットＨｅＮＢ２３１０に移動するときに、ソースＨｅＮＢ２３２０は、ターゲットＨｅＮＢ２３１０に、それがＸ２またはＩｕｒｈインタフェース２３００を介してＬＩＰＡ ＰＤＮ接続に対してデータ継続性を維持することができるかを要求してもよい。ターゲットＨｅＮＢ２３１０は、ハンドオーバ要求肯定応答メッセージにおいてソースＨｅＮＢ２３２０からの問い合わせを通知／応答してもよい。そして、ターゲットＨｅＮＢ２３１０は、パス切替え要求をＣＮ（図示せず）に送信してもよく、および、ＬＩＰＡベアラに対するパスを切り替えるためのパラメータを含まない。ハンドオーバプロシージャの完了のときに、ソースＨｅＮＢ２３２０は、Ｘ２またはＩｕｒｈインタフェース２３００を介してＬＩＰＡ ＰＤＮ接続に対するデータをターゲットＨｅＮＢ２３１０に転送するために必要なすべての情報を有してもよい。あるいは、データは、ソースＨｅＮＢ２３２０からターゲットＬＧＷ２３１５に転送されてもよく、そして、ターゲットＬＧＷ２３１５からＷＴＲＵ２３０５に、ターゲットＨｅＮＢ２３１０を介して転送されてもよい。

上述の実施形態は、ターゲットＨｅＮＢ２３１５がソースＬＧＷ２３２５またはターゲットＬＧＷ２３１５または任意のＬＧＷに接続されることを必要とせず、および、当該実施形態は、ＨｅＮＢ２３２０とＨｅＮＢ２３１０との間のＸ２／Ｉｕｒｈインタフェースを通じてソースＬＧＷ２３２５を介して、ローカルネットワークへのリモートアクセスを提供するために使用されてもよい。

別の実施形態では、データ転送は、シームレスなＬＧＷ間モビリティに対するＳＧＷを通じて実行されてもよい。ＬＧＷとＳＧＷとの間の既存のＳ５インタフェースは、ソースＬＧＷシステムからターゲットＬＧＷシステムにデータを転送するために使用されてもよい。この実施形態は、ソースおよびターゲットＬＧＷの両方が同一のＳＧＷによりサービスされることを仮定している。ＬＧＷ間ハンドオーバの間に、ソースＨｅＮＢは、ＷＴＲＵがソースＬＧＷのカバレッジの外へ移動するときに、ＬＩＰＡ ＰＤＮ接続を非活性化しなくてもよく、代わりに、ソースＨｅＮＢが、アクティブなＬＩＰＡベアラをターゲットＨｅＮＢに通知してもよい。ターゲットＨｅＮＢがＬＧＷ間ハンドオーバをサポートする能力を有している場合、それは、ＬＧＷとのセッションを、それが他のＰＧＷとのセッションを作成するのと同様に作成することをＳＧＷに要求してもよい。ＳＧＷは、ＷＴＲＵトラフィックが直接パスを通じてルーティングされる代わりに、ＳＧＷを通じてルーティングされてもよいことをＬＧＷに通知してもよい。

ＳＧＷの機能性は修正されてもよく、それは、現在、ＳＧＷがＬＧＷからデータを受信したときに、それはダウンリンクデータ通知をＭＭＥに送信することによって、ＭＭＥがＷＴＲＵをページングしてそれを接続モードにするようにできるからである。しかし、この実施形態では、ＳＧＷは、データを直接ＷＴＲＵに転送してもよい。この問題は、Ｓ５インタフェースが確立されたときに、いくつかの情報要素（ＩＥ）を交換することによって解決されてもよい。これらのＩＥは、Ｓ５トンネルがユーザプレーン用であるか、またはネットワーク開始サービス要求プロシージャを容易にするためのものであるかをＳＧＷおよびＬＧＷに通知してもよい。

一部のＬＧＷの機能性はまた、この実施形態をサポートするために変更されてもよい。現在、ＬＧＷはＨｅＮＢからＵＬデータを受信するが、この実施形態では、ＬＧＷはまた、ＳＧＷからアップリンクデータも受信してもよい。したがって、データがＨｅＮＢによって送信されるか、または、ＳＧＷによって送信されるかを区別することが必要になることがある。このことは、２つの異なる相関ＩＤを使用することによって達成されてもよい。１つの相関ＩＤはＨｅＮＢとＬＧＷとの間の直接的パスに対するものであり、および、他方の相関ＩＤはＳＧＷを通るデータに対するものである。

本明細書における上述の実施形態は、ターゲットＨｅＮＢがＬＧＷに接続されることを必要としないことがある。したがって、この実施形態はまた、ソースＬＧＷを介してローカルネットワークへのリモートアクセスを提供するためにも使用されてもよい。

本明細書において上述されているすべての実施形態では、ネットワークは、ＷＴＲＵがアイドルモードに移行するとき、または、ＷＴＲＵにおけるすべてのデータセッションが非アクティブであるときに、そのＰＤＮ接続をターゲットＬＧＷに変更することを決定してもよい。

ＬＩＰＡ／ＳＩＰＴＯ間のインタラクションに対する実施形態、および、同等のＰＬＭＮおよびＲＡＮの共有に対するサポートについて、本明細書で説明される。ＬＩＰＡは、オペレータがＣＳＧ毎のユーザ加入者毎に、ＬＩＰＡを有効化／無効化することができることが必要である。この要件は、現在、加入者ユーザプロファイルにおいてＷＴＲＵが特定のＣＳＧに接続されるときに有効であるアクセスポイントネーム（ＡＰＮ）に対するＬＩＰＡのサポートを定義する、オペレータによって実装される。ＣＳＧは、ＰＬＭＮベースで指定されている。現在、すべてのｅＰＬＭＮが、ＰＬＭＮ選択、セル選択／再選択、およびハンドオーバについて互いに同等であるものとみなされる。このことは、すべてのｅＰＬＭＮが、同一のＣＳＧエントリを有するホワイトリストに格納されることを意味する。

すべてのｅＰＬＭＮがホワイトリストに格納されているわけではないことが仮定されている。これに基づいて、以下では、どれが同等のＰＬＭＮに対するサポートと必ずしも後方互換性を必要としなかの説明がなされた。ＷＴＲＵベースのモビリティ（すなわち、ＩＤＬＥおよびＵＭＴＳ ＰＣＨ）の間のメンバシップチェックに対し、ＷＴＲＵは、すべてのブロードキャストＰＬＭＮのＣＳＧ−ＩＤ部分を考慮してもよい。適切なチェックは、登録されているＰＬＭＮ（ｒＰＬＭＮ）／サービングＰＬＭＮ（ｓＰＬＭＮ）／ｅＰＬＭＮが（ｒＰＬＭＮ／ｓＰＬＭＮ／ｅＰＬＭＮ，ＣＳＧ−ＩＤ）がホワイトリストに存在するかを考慮する。接続モードでは、ＷＴＲＵが、それがメンバであるか、または、非メンバであるかを報告することを求められたときに、ＷＴＲＵはそれ自体を、ｒＰＬＭＮがセルによってブロードキャストされ、および、（ｒＰＬＭＮ，ＣＳＧ−ＩＤ）がＷＴＲＵのホワイトリストにある場合にのみメンバであるとみなす。

一実施形態では、同等のＰＬＭＮへのサポートとの後方互換性を提供するために、ＷＴＲＵベースのモビリティ（すなわち、ＩＤＬＥおよびＵＭＴＳ ＰＣＨ）の間に、または、ＷＴＲＵが接続モードである間のモビリティの間のメンバシップチェックについて、ＰＬＭＮ（ｓＰＬＭＮ、ｒＰＬＭＮ、他の任意のＰＬＭＮ）がセルによってブロードキャストされ、および、ＷＴＲＵがそのホワイトリスト上にこのＰＬＭＮを有していないが、むしろセルによってブロードキャストされるＣＳＧ ＩＤに関連付けられているｅＰＬＭＮを有しているときに、ＷＴＲＵはそれ自体をメンバであるとみなして、ｅＰＬＭＮを含むようにそのホワイトリストを更新してもよい。ＷＴＲＵは、そのホワイトリストの更新をネットワーク（ＭＭＥ、ＳＧＳＮ、ＨｅＮＢ）に通知してもよい。ＷＴＲＵは、トラッキングエリア識別子（ＴＡＩ）、ルーティングエリア識別子（ＲＡＩ）、またはＴＡＵ／ＲＡＵタイマの満了に変更がない場合であっても、ホワイトリストの更新の結果としてＴＡＵ／ＲＡＵを開始してもよい。ネットワークは、ホワイトリストの更新を元に戻すようＷＴＲＵに要求してもよい。

加えて、ＷＴＲＵは、ＣＳＧセルによってブロードキャストされるＰＬＭＮの代わりに、同等のＰＬＭＮをＷＴＲＵが使用することを許可されるかに関するパーミッションでネットワークによって構成されてもよく、および、それ自体をＣＳＧのメンバであるとみなしてもよい。格納されているリストにあるすべてのＰＬＭＮは、ＰＬＭＮによってサポートされているすべてのアクセス技術において、ＰＬＭＮ選択、セル選択／再選択、およびハンドオーバに対して互いに同等であるものとみなされてもよい。このコンテキストでは、同等のＰＬＭＮは、ＣＳＧセルによってブロードキャストされるＰＬＭＮと同等であるとみなされてもよい。

加えて、パーミッションはまた、＜ＣＳＧ＿ＩＤ，ｅＰＬＭＮ＞組合せをＣＳＧセルによってブロードキャストされる＜ＣＳＧ＿ＩＤ，ＰＬＭＮ＞組合せの代わりに使用して、ＷＴＲＵがそのメンバシップ状態を「メンバ」として報告することを許可されるかを示してもよい。図２５は、このプロシージャを実行するために使用される例示的なＷＴＲＵのホワイトリスト２５００を示している。

このパーミッションは、ＮＡＳシグナリング（例えば、Ａｔｔａｃｈ Ａｃｃｅｐｔ）、およびＲＲＣシグナリング（例えば、システム情報メッセージ）などを使用してシグナリングされてもよい。このパーミッションはまた、さらに、ネットワークオペレータのサービスセンタで事前構成されてもよく、あるいは、オープンモバイルアライアンス（ＯＭＡ）デバイス管理（ＤＭ）を通じて、または、アクセスネットワーク発見・選択機能（ＡＮＤＳＦ）を使用して、このパーミッションをプッシュもしくはプルすることでオーバーザエア（ＯＴＡ）プロシージャを介してオペレータによって構成されてもよい。このパーミッションはまた、ホーム加入者サーバ（ＨＳＳ）／ホームロケーションレジスタ（ＨＬＲ）に典型的に格納されている加入者プロファイルの一部であってもよい。例えば、このパーミッションは、移動先ネットワークによって検索（retrieve）されてもよく、および、例えば、ネットワークアタッチメントプロシージャの間にＷＴＲＵを構成するために使用されてもよい。

このパーミッションで構成されているＷＴＲＵは、それ自体をＣＳＧセルによるＣＳＧのブロードキャスト、および、同等のＰＬＭＮの任意の組合せのメンバとして（この組合せがそのホワイトリストの一部である限り）、みなしてもよい。ネットワークによってすでに構成されているＣＳＧ ＩＤ／ｅＰＬＭＮの組合せのメンバであると主張（claim）するＷＴＲＵに対してアクセスチェックおよびメンバシップ検証を実行する、関連するＰＬＭＮ内のネットワークエンティティ（例えば、モビリティ管理エンティティ（ＭＭＥ）またはＨｅＮＢ）は、この目的のためにすでに構成されている許可に基づいて、そのような組合せを提供するＷＴＲＵへのネットワークアクセスを許可してもよい。

加えて、セル再選択プロシージャの間に、ＷＴＲＵは、＜ＣＳＧ＿ＩＤ，ＰＬＭＮ＞の組合せを、そのような組合せがＷＴＲＵのホワイトリストに含まれていない場合であっても、ブロードキャストするＣＳＧセルに再選択してもよい。ＷＴＲＵは、このプロシージャを、セルの＜ＣＳＧ＿ＩＤ，ｅＰＬＭＮ＞の組合せがＷＴＲＵのホワイトリストに含まれている限り、実行してもよい。さらに、ＷＴＲＵが、例えば、異なるトラッキングエリア（ＴＡ）／ロケーションエリア（ＬＡ）ルーティングエリア（ＲＡ）にアクセスすることに起因して、または定期的な更新の要件に起因して、ロケーション更新プロシージャを実行する必要がない場合であっても、ＷＴＲＵは、ロケーション更新プロシージャを実行して、ネットワークがメンバシップ証明を検証し、したがって、ＷＴＲＵのシステムアクセスの受け入れまたは拒絶を許可してもよい。

別の実施形態では、ＷＴＲＵは、ＲＡＵ／ＴＡＵ（または他の適切なＮＡＳプロシージャ）を開始して、ＰＬＭＮの変更およびこのＰＬＭＮへの登録をネットワークに通知してもよい。登録が受け付けられた場合、ＷＴＲＵは、そのホワイトリストを、ｅＰＬＭＮとセルによってブロードキャストされたＣＳＧ ＩＤとの間の関連付けで更新してもよい。ＲＡＮ共有のコンテキストでは、セルは、複数のＰＬＭＮ ＩＤをブロードキャストしてもよい。一部のオペレータはＣＳＧセルに対してＬＩＰＡを提供してもよく、一部のほかのオペレータは同一のＣＳＧセル上でＬＩＰＡを提供しなくてもよい。さらに、ｅＰＬＭＮの間で、サービスの識別が存在してもよい。オペレータは、与えられたＰＬＭＮの下で与えられたＡＰＮ／ＣＳＧの組合せについてＬＩＰＡサービスを加入者に提供してもよく、その一方で、同一の加入者は、両方のＰＬＭＮがｅＰＬＭＮであるという事実があるにもかかわらず異なるＰＬＭＮの下で同一のＡＰＮ／ＣＳＧの組合せについてＬＩＰＡサービスへの認可がされない。ＷＴＲＵがＬＩＰＡサービスに対するＰＤＮ接続要求を送信したときに、それはＭＭＥへの要求において、セルにおいて可能なＣＳＧ＿ＩＤ／ＰＬＭＮまたはＣＳＧ／ｅＰＬＭＮ組合せのリストをそのセルに含めてもよい。そして、ＭＭＥは、ＷＴＲＵがそのＨｅＮＢからＬＩＰＡサービスにアクセスすることを許可するＣＳＧ＿ＩＤ／ＰＬＭＮを選択してもよい。

これらの可能性を考慮するために、一実施形態では、ＬＩＰＡサービスアクセス認可は、ＡＰＮ、ＣＳＧ、およびＰＬＭＮの組合せに基づいて、定義されてもよい。別の実施形態では、セルは、ＰＬＭＮ毎をベースに複数のＣＳＧ ＩＤをブロードキャストしてもよい。例えば、セルを共有するＰＬＭＮ毎に１つのＣＳＧ ＩＤブロードキャストが存在する。

一実施形態では、非ＳＲＮＳリロケーションハンドオーバが、リモートＩＰアクセス（ＲＩＰＡ）のサポートにおいて使用されてもよい。ＷＴＲＵが所与のセルのカバレッジの下にあり、および、ＲＩＰＡサービスを必要としているときに、接続は、ＷＴＲＵのローカルネットワークに配置されているサービングＲＮＳ（ＨｅＮＢサブシステム）、および、ドリフトＲＮＳ（ＨｅＮＢ、ｅＮＢ、およびＲＮＣ／ＮＢなど）を使用してセットアップされてもよく、ＷＴＲＵにカバレッジを提供する。サービングＲＮＳは、ＷＴＲＵの接続を管理してもよく、ドリフトＲＮＳは、無線リソースを提供してもよい。ＳＲＮＳおよびＤＲＮＳの両方は、同一のＬＮ内にあり、または、異なるＬＮにあってもよい。同様に、ＳＲＮＳおよびＤＲＮＳの両方は、同一のＬＧＷの下にあり、または、異なるＬＧＷの下にあってもよい。

ＳＲＮＳとＤＲＮＳとの間のアクセス制御ルールに関して、一実施形態では、ＷＴＲＵは、ＷＴＲＵがＳＲＮＳ、ＤＲＮＳ、および／または関係するＣＳＧにおいてアクセス証明を有する場合にアクセスすることを許可されてもよい。別の実施形態では、ＷＴＲＵは、ＷＴＲＵがＳＲＮＳおよび／または関係するＣＳＧにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。別の実施形態では、ＷＴＲＵは、ＷＴＲＵがＳＲＮＳ／ＤＲＮＳおよび／または関係するＣＳＧにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。別の実施形態では、ＷＴＲＵは、ＷＴＲＵがＳＲＮＳおよび／もしくは関係するＣＳＧ、またはＤＲＮＳおよび／もしくは関係するＣＳＧにおいてアクセス証明を有している限りアクセスすることを許可されてもよい。

ＭＲＡおよびＭＲＡ−ＬＩＰＡ間転送を有効化する、ならびに、その逆が説明される。第１のプロシージャにしたがって、スタンドアロンまたはアタッチプロシージャの一部としてのいずれかのＰＤＮ接続性要求は、ＬＩＰＡがＷＴＲＵに提供されないセルから送信されてもよい。したがって、ＬＧＷへの接続は、ＭＲＡ接続として実装されてもよい。

ＷＴＲＵが、ＭＲＡセッションに対するＰＤＮ接続要求を開始するときに、このＰＤＮ接続がＭＲＡセッションに対するものであることを示すために、ローカルネットワークに対する適切に定義されたＡＰＮ、および、ＭＲＡインジケーションが含まれてもよい。ＰＤＮ接続性要求を搬送するＮＡＳメッセージは、ＬＧＷ ＩＰアドレス（ＣＮによって認識される）、または、ＬＧＷ識別を含んでもよい。このアドレス／識別子は、適切なＬＧＷを選択するためにＭＭＥによって使用されてもよい。ＷＴＲＵは、例えば、ユニバーサル加入者識別モジュール（ＵＳＩＭ）においてこの情報で構成されてもよく、または、ＣＮノード、例えば、ＡＮＤＳＦ、ドメインネームサーバ（ＤＮＳ）、もしくは、一部のほかのＭＲＡアプリケーションサーバなどからこの情報を取得してもよい。識別は、例えば、ローカルホームネットワーク（ＬＨＮ）ＩＤであってもよい。あるいは、ＲＡＮノードは、この情報で構成されてもよい。ＲＡＮノードは、この情報をすべてのＵＬ ＮＡＳトランスポートメッセージ（Ｓ１ＡＰ）またはＲＡＮＡＰにおける同等のメッセージに含めてもよい。

ＭＲＡに対するＰＤＮ接続を受信すると、ＭＭＥはＷＴＲＵのＭＲＡ認可を実行して、ＷＴＲＵ加入者データおよびＨｅＮＢ／ＨＮＢもしくはＬＧＷのＭＲＡ能力に従って、ＷＴＲＵがＭＲＡサービスを使用することを許可されているかを判定してもよい。ＭＭＥは、ＭＲ認可が失敗した場合に、ＰＤＮ接続性要求を拒絶してもよい。成功したＭＲＡ認可の後に、ＭＭＥは、ＬＧＷのアドレスまたは／およびローカルネットワークにおいてＬＧＷ選択するために提供されるＬＨＮ ＩＤを使用してもよい。

セットアップされた各ＰＤＮ接続に対し（アタッチプロシージャの一部として、またはスタンドアロンのＰＤＮ接続性要求プロシージャの間のいずれかで）、ＭＭＥ／ＳＧＳＮは、接続が例えばＬＩＰＡ接続、ＭＲＡ接続、または、他のＣＮ ＰＤＮ接続であるかをＬＧＷ／ＧＧＳＮ／ＰＧＷに示すべきである。このことは、接続性タイプのＩＥまたは任意の他の形態のインジケーションを導入することによって行われてもよい。ＬＴＥに対して、このことはＳＧＷを介して行われてもよい。接続性タイプ（または任意の他の同様のＩＥ）は、ＭＭＥから、インジケーションをＬＧＷ／ＰＧＷへ転送するＳＧＷに送信されるセッション作成要求に含まれてもよい。加えて、このインジケーションはまた、ＰＤＮ接続性要求において、または、任意のシグナリングの間のいずれかにおいて、ＭＭＥによってＳＧＷに送信されてもよい。例えば、それは、ハンドオーバプロシージャの一部として送信されてもよい。

このインジケーションは、ＨｅＮＢまたはＳＧＷのいずれかによって使用されるＵＬトンネルエンドポイントを指定するために、相関ＩＤまたはＳ５ ＰＧＷ ＴＥＩＤが提供される必要があるか否かを判定するために（例えばＬＧＷによって）使用される。言い換えると、相関ＩＤは、直接パスがＬＧＷとＨｅＮＢ／ＨＮＢとの間でセットアップされることになる場合にのみ、必要とされる。したがって、セッションがＬＩＰＡである場合、ＬＧＷは、セッション作成応答メッセージにおいて相関ＩＤを提供すべきである。一方、セッションがＭＲＡである場合、ＨｅＮＢ／ＮＢとＬＧＷとの間では直接パスは必要でない。そのため、相関ＩＤは、セッション作成応答においてＬＧＷによって提供される必要はなく、その代わりに、Ｓ５ ＰＧＥ ＴＥＩＤが提供される必要がある。

加えて、ＬＧＷは、セッションがＬＩＰＡ／ＭＲＡであること（例えば、接続性タイプまたは任意の他の同等のＩＥ）に関するインジケーションを使用して、ＷＴＲＵがページングされるときにダミーパケットが使用されるべきか、または、コアネットワークＰＧＷによって行われるように実際のダウンリンクデータがＳＧＷに転送されるべきかを判定してもよい。

図２４は、例示的なＭＲＡのページングのシナリオ２４００を示している。ＬＮ２４０５内のエンティティは、対象のＷＴＲＵ２４１０に対するダウンリンクデータを送信してもよい（１）。ＬＧＷ２４１５は、ＷＴＲＵ２４１０がアイドルモードに有ることを認識していると仮定される。ＬＧＷ２４１５は、ＨｅＮＢ２４１７またはスタンドアロンエンティティと同一位置に配置されてもよい。ＰＤＮ接続の確立の間に提供される、ＰＤＮ接続がＭＲＡであることに関するインジケーションに基づいて（例えば、接続性タイプを使用して）、ＬＧＷ２４１５は、ユーザデータがＳ５ ＤＬデータ接続上でＳＧＷ２４２０に送信されるべきかを判定してもよい（２）。このことは、ＬＧＷ２４１５がダミーパケットをＳＧＷ２４２０に送信してページングをトリガすることができるＬＩＰＡセッションとは異なっていてもよい。そして、通常のページングプロシージャが、ＭＭＥ２４２２によって実行されてもよく、ＭＭＥ２４２２では、ＷＴＲＵはマクロネットワークにおいて（またはＬＮ２４０５のＨｅＮＢ／ＨＮＢ２４１７において）ページングされ、したがって、それが応答した場合（３〜４）、ＳＧＷ２４２０は、ＷＴＲＵ２４１０宛てのバッファリングされているデータを転送してもよい（５）。

あるいは、少なくとも１つの相関ＩＤがＬＧＷによって提供されてもよい。このことは、ＭＲＡセッションがＬＩＰＡセッションとして継続される場合に使用されてもよい。このことは、例えば、ＬＩＰＡセッションが対象のＷＴＲＵに対して許可されているＬＮ／セル内に、ＭＲＡを有するＷＴＲＵが移動した後に発生してもよい。次いで、直接パスが、ＨｅＮＢ／ＨＮＢと、その後すでに割り当てられている相関ＩＤを使用するＬＧＷとの間で確立されてもよい。相関ＩＤは、ＭＲＡセッションのセットアップの間に提供される場合、潜在的ＬＩＰＡセッションが開始されるまで（すなわち、ＭＲＡセッションがＬＩＰＡセッションとして継続されるまで）、ＭＭＥ／ＳＧＳＮに格納されることに留意されたい。その時点において、ＭＭＥ／ＳＧＳＮは、相関ＩＤを、ハンドオーバの一部として実行されるシグナリングメッセージにおいてＨｅＮＢ／ＨＮＢに転送されてもよく、これについては以下で説明する。ＭＲＡセッションの間に相関ＩＤの値が変化するケースでは、新たな相関ＩＤがＭＭＥ／ＳＧＳＮに送信されてもよい。このことは、ＳＧＷが、変更することができる相関ＩＤの一部であってもよいＳ５ ＴＥＩＤを変更したときに発声してもよい。

ＭＭＥ／ＳＧＳＮはまた、サービングセルに、そのセッションがＭＲＡセッションであることを示してもよい。このインジケーションは、例えば、ＭＲＡセッションがＬＩＰＡセッションとして継続することができるセルを選択するために、ハンドオーバの間にセルによって使用されてもよい。隣接に関する情報が、すべてのセル（ソース、ターゲット、マクロ、およびＨｅＮＢ／ＮＢなど）に提供されてもよい。このことは、例えば、ＬＩＰＡが全般にサポートされているか否か、または、特定のＷＴＲＵに対してサポートされているか否か、したがって、どのＷＴＲＵに対してサポートされているか、ならびに、ＭＲＡが全般にサポートされているか否か、または、特定のＷＴＲＵに対してサポートされているか否か、したがって、どのＷＴＲＵに対してサポートされているかを含んでもよい。この情報は、ＣＮノード、例えば、ＭＭＥ／ＳＧＳＮ／ＨＳＳ／ＬＧＷまたは他のノード、例えば、ＲＮＣまたはＨＮＢ ＧＷによって提供されてもよい。

あるいは、ＣＮによって認識されるようなローカルホームネットワーク（ＬＨＮ）ＩＤまたはＬＧＷのアドレスはまた、ＬＧＷによって提供されてもよく、および、これは、ＷＴＲＵが、ＬＩＰＡを許可することができるＬＨＮ内に移動したときに、ＭＲＡセッションがＬＩＰＡセッションとして継続することを保証するために使用されるべきである。このＬＨＮ ＩＤまたはＬＧＷアドレスは、サービングＭＭＥまたはサービングｅＮＢ／ＨｅＮＢに格納されてもよい。これらのパラメータはまた、アクティブなＭＲＡセッションが存在するハンドオーバの間にターゲットｅＮＢ／ＨｅＮＢへのインジケーションとして使用されてもよい。また、ローカルネットワークへのハンドオーバのケースでは、ターゲットは、ＬＨＮ ＩＤまたはＬＧＷのアドレスをそれらの自身のアドレスと比較し、および、それが一致すれば、ＭＲＡセッションは、以下で指定されているようなアクティブなＬＩＰＡセッションとして継続されてもよい。

ここでは、ローカルネットワークに入り、ローカルネットワークから出る（すなわち、ＭＲＡからＬＩＰＡ／ＬＩＰＡからＭＲＡの）ハンドオーバについて説明される。考慮する２つのモビリティシナリオが存在する。第１のシナリオでは、ローカルネットワークにおけるＷＴＲＵは、ＬＩＰＡセッションを有する。次いで、ＷＴＲＵは、接続モードでＬＮの一部でないターゲットセルにハンドオーバされることによって、ＬＩＰＡセッションを維持することができるが、ＭＲＡセッションとして維持することができる。第２のシナリオでは、ＷＴＲＵは、ＬＮの外にあるときにＭＲＡセッションを有する。次いで、接続モードにおいて、ＷＴＲＵは、ＷＴＲＵに対してＬＩＰＡが許可されているＬＮ内のセルにハンドオーバされる。こうして、ＭＲＡセッションは、ＬＮにおけるＬＩＰＡセッションとして継続される。

第１のシナリオについて、ＬＩＰＡツーＭＲＡセッション転送（ＬｔＭ：LIPA to MRA session transfer）は、Ｓ１もしくはＸ２ハンドオーバ、または３Ｇシステムにおける類似のモビリティに適用されてもよい。ハンドオーバの間に、ソースまたはターゲットＭＭＥは、ＷＴＲＵがターゲットセルにおいてＭＲＡセッションを有することを許可されているかを検証する。ターゲットセルは、ＬＮに属さない任意のセル、または、ＬＮに属するが、例えば、ＬＩＰＡが加入情報に起因して許可されていないセルであってもよい。ＭＭＥ間ＨＯが存在してもよいが、ＭＭＥ内（intra-MME）に対しては、ターゲットはまたソースＭＭＥである。

Ｓ１ハンドオーバの間に、ターゲットＭＭＥは、ＭＲＡがターゲットセルにおけるＷＴＲＵに対して許可されているかを検証してもよい。この検証は、ハンドオーバの完了前に、または、ＭＭＥが、リソースがターゲットセルにおいてセットアップされるべきか否かを認識することができるようなハンドオーバシグナリングの間に行われてもよい。例えば、ＭＭＥがＳ１ ＨＯプロシージャの一部としてソースセルから「ｈａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄ」メッセージを受信したときに、ＭＭＥは、進行中のＬＩＰＡセッションをターゲットセルにおいてＭＲＡとして維持することができるかを検証してもよい。

ＭＲＡが許可される場合、ＭＭＥはハンドオーバを完了することを可能にするが、そうでなければ、ＭＭＥはハンドオーバを拒絶し、および、ソース／ターゲットセルに、拒絶の理由が進行中のセッションをＭＲＡセッションとしてターゲットセルにおいて維持することができないことであることを通知してもよい。この情報は、対象のＷＴＲＵの今後のハンドオーバに対してソース／ターゲットセルによって使用されてもよい。拒絶原因はまた、ＭＲＡがすべてのＷＴＲＵに対してターゲットから許可されていないことも示してもよい。したがって、ソースセルは、この情報を今後のハンドオーバに対して考慮することによって、ターゲットセル上でＭＲＡセッションが試みられないようにすることができる。

あるいは、ＭＭＥは、ハンドオーバおよびＭＲＡセッションとしてのＬＩＰＡセッションの継続を許可してもよい。ハンドオーバの後、ＭＭＥは検証を実行して、ＷＴＲＵがターゲットセルからのＭＲＡセッションを有することを許可されているか否かを検証してもよい。そうでない場合、ＭＭＥは、他のＣＮノードおよび／またはＲＡＮノードへのＭＲＡで必要とされるリソースの解放を開始してもよい。

ＳＧＳＮなどのＣＮノードへのＭＭＥ間ハンドオーバまたはＲＡＴ間ハンドオーバが存在する場合、ＬＩＰＡセッションの存在に関してそれに通知するインジケーションが、ターゲットＭＭＥに送信されてもよい。次いで、ターゲットＭＭＥは、このインジケーションを使用して、ＬＩＰＡセッションをターゲットセルにおいてＬＩＰＡまたはＭＲＡとして維持することができるかを検証してもよい。

検証は、ソースまたはターゲットセルによって実行されてもよく、および、上記の他の提案すべても同様にソース／ターゲットセルに対して適用される。これがソース／ターゲットによって行われる場合、ソース／ターゲットセル（例えば、ＨｅＮＢ／ＨＮＢ）は、ＷＴＲＵがＭＲＡセッションを有することが許可されている潜在的ターゲットセルに関する情報を提供されるべきである。この情報は、ＣＮ（ＭＭＥ／ＳＧＳＮ、またはＬＧＷ、またはＯＭＡを介して）によって、または、それが対象のＷＴＲＵに対してそのような情報を有している場合にはターゲットセルそれ自体によって、ソース／ターゲットに提供されてもよい。例えば、ターゲットセルは、ソースセルに送り返されるそのような情報を、ハンドオーバシグナリングの間に提供してもよく、および、ソースセルはこの情報を今後のハンドオーバに使用してもよい。ハンドオーバの間に、ソース／ターゲットセルは、ターゲットセル／ターゲットＭＭＥに、ＷＴＲＵがＭＲＡセッションとして維持されるべきＬＩＰＡセッションを有していることを示してもよい（新たなＩＥまたは既存のＩＥを介して）。次いで、ターゲットセル／ターゲットＭＭＥは、このＩＥが、セッションがＭＲＡセッションとして処理されるべきであり、および、リソースはＬＧＷへの直接パスを有するのとは反対にＳＧＷへセットアップされるべきであることを認識していることを検証してもよい。ターゲットは、別のＬＮの一部であるＨｅＮＢ／ＨＮＢであってもよい。

ソースセルが、セッションがターゲットセルにおいてＬＩＰＡまたはＭＲＡとして継続されるかを認識していない場合、ソースセルはそのまますべてのＬＩＰＡ関連情報を保持してもよい。これは、ＬＩＰＡベアラ、および相関ＩＤなどをハンドオーバメッセージに含めてもよい。次いで、ターゲット／ソースＭＭＥまたはターゲットセルは、そのセッションをＬＩＰＡとして保持し、または、それをＭＲＡとして再開するか、もしくは、ＬＩＰＡベアラのいずれもハンドオーバしないことを判定してもよい。ＬＩＰＡベアラおよび関連するパラメータは、ターゲットセル／ＭＭＥが、どのベアラがＬＩＰＡまたはＭＲＡとして継続すべきであるかを認識することができるように識別されてもよい。

ＭＭＥがハンドオーバの完了に関するインジケーションをターゲットセルから受信したときに、および、セッションがＭＲＡセッションとして継続されることになる場合に、ＭＭＥは、ＬＧＷからの／ＬＧＷへのローカルネットワークデータの受信／送信を開始することをＳＧＷに通知してもよい。これは、修正ベアラ要求メッセージまたは他のメッセージで示されてもよい。次いで、ＳＧＷは、ローカルネットワークデータに対するデータパスの変更に関して、それに通知するメッセージをＬＧＷに送信してもよい。これは、修正ベアラ要求メッセージまたはその他を使用して行われてもよい。ＳＧＷはまた、ダウンリンクデータに対してＬＧＷによって使用されることになるＴＥＩＤを含む。ＬＧＷはまた、アップリンクにおいてＳＧＷによって使用されることになるＴＥＩＤで応答する。さらに、ＬＧＷは、古いセル（すなわち、直接パス）とともにリソースを解放する。次いで、ＭＭＥは、リソースのセットアップの完了に関して通知される。ＷＴＲＵが、新たなセルに接続されている間にアイドルモードに入った場合、および、ユーザデータがこのＷＴＲＵに対して受信された場合、ＬＧＷは、本明細書で説明されているようなプロシージャを実行することが必要になることがある。例えば、ＬＧＷは、接続性タイプ（または他の同等のＩＥ）に基づいて、ダミーパケット送信する代わりに、ユーザデータがＳＧＷに転送されるべきであることを判定する必要があることがある。

ハンドオーバの前にＷＴＲＵに対してＣＮとＬＩＰＡとの両方のトラフィック（すなわち、２つのＰＤＮ接続）が存在することがある。そのため、ハンドオーバの間に、ＣＮとのＰＤＮ接続に関連付けられているベアラは、現在のプロシージャに関してハンドオーバされる。ＬＩＰＡベアラは、上記説明されているように処理される。さらに、ＭＲＡベアラ／ＰＤＮ接続は、セッションをＬＩＰＡとして再開することができるＬＮへの今後のハンドオーバが、その後正しいベアラ上で、すなわち、ＭＲＡベアラ上で行われるように識別されてもよい。

上述のプロシージャおよびシナリオはまた、３ＧシステムにおけるＸ２ハンドオーバまたは類似のハンドオーバプロシージャのケースに適用されてもよい。Ｘ２ハンドオーバでは、ＭＭＥは、ターゲットセルからパス切替え要求を受信すると、本明細書で説明されている方法を実行してもよい。ソースセルは、ＬＩＰＡベアラを含み、したがって、これがＬＩＰＡまたはＭＲＡとして継続することができるかを検証することをＭＭＥに依存するすべてのベアラを含み、ならびに、上述のような必要な処置を講じることができる。ソースセルは、ＬＩＰＡベアラおよび関連する情報を識別してもよく、ならびに、ターゲットセルはまた、上述のように検証を実行してもよい。上述のプロシージャは、任意の組合せで適用してもよく、および、３Ｇ、または、類似のもしくは同一の機能性を有する他のシステムに適用可能であってもよい。

第２のシナリオでは、ＭＲＡツーＬＩＰＡセッション転送（MRA to LIPA session transfer）は、Ｓ１またはＸ２ハンドオーバ（ＨＯ）、または３Ｇシステムにおける類似のモビリティの両方に適用されてもよい。上述のプロシージャは、同様にこのケースにも適用することができる。しかし、ソースセルのセッションはＭＲＡセッションであり、および、ターゲットセルのセッションはＬＩＰＡセッションである。

ＭＲＡセッションを有するＷＴＲＵの、ＬＩＰＡをサポートすることができるターゲットセルへのハンドオーバの間に、ソース／ターゲットセルまたはＭＭＥ／ＳＧＳＮは、ＭＲＡがターゲットセルにおいてＬＩＰＡセッションとして継続されるようにＷＴＲＵに対してＬＩＰＡが許可されているかをチェックしてもよい。この判定は、上述のように実行されてもよい。ＭＭＥ間またはＣＮ間ＨＯ（例えば、ＭＭＥツーＳＧＳＮ、または、ＳＧＳＮツーＭＭＥ）が存在する場合、ソースＭＭＥは、対応するターゲットノードに、ＷＴＲＵのセッションがＭＲＡセッションであり、および、ＭＲＡに使用されるベアラおよび他の必要なパラメータも識別されるべきであることを示してもよい。ターゲットＭＭＥ／ＳＧＳＮは、この情報を使用して、ターゲットセルがセッションをＬＩＰＡ、ＭＲＡとして継続することができるか否かを検証してもよい。既存のＭＲＡセッション、ＭＲＡベアラ、および他のＭＲＡパラメータに関するインジケーションは、ハンドオーバメッセージにおいてソースセルからターゲットセルにも送信されてもよい。

ＬＩＰＡセッションとして継続することができるＭＲＡセッションのハンドオーバの間に（またはオプションで、ハンドオーバの後に）、ターゲットＨｅＮＢ／ＨＮＢとＬＧＷとの間のＬＩＰＡデータに対する直接パスがセットアップされるべきである。ＬＧＷとＨｅＮＢとの間における直接パスのセットアップはまた、ＷＴＲＵがアイドルモードに入り、ＤＬデータがこのＷＴＲＵに対して受信される場合に、実際のユーザプレーンパケットをＳＧＷに転送する代わりに、ＬＧＷがＳ５ ＤＬインタフェースを通じてダミーパケットまたは第１のパケットを送信する必要がある場合があることを意味する。さらに、ユーザプレーンに対するＳＧＷとＬＧＷとの間のリソースは、解放されるべきである。しかし、一部の通信およびリソースは、ＷＴＲＵがアイドルモードにあるときに、現在のプロシージャに関して、これら２つのノードの間で維持されて、ＬＩＰＡトラフィックに対するページングを有効化する。セッションは、短い時間の間、ＭＲＡセッションとして続行し、次いで、ＬＩＰＡセッションに変換してもよい。すなわち、ＭＲＡセッションは、ＬＩＰＡトラフィックがアップリンク方向ではそのままＳＧＷおよびＬＧＷを通り、ダウンリンクについてはその逆であることを意味する、ＷＴＲＵのハンドオーバの間に、ターゲットセルで継続してもよい。ハンドオーバが完了した後、セッションは、ＬＩＰＡに変更され、および、直接データパスがセットアップされてもよい。

ハンドオーバの間に、ＷＴＲＵがターゲットセルにおいてＬＩＰＡを許可されている場合、ソースセル／ＭＭＥは、ターゲットセルに転送される、ハンドオーバ要求メッセージにインジケーションを含めてもよく、それによって、ＨｅＮＢ／ＨＮＢとＬＧＷとの間で直接パスが確立される。少なくとも１つの相関ＩＤがまた含まれてもよく、および、このＩＤは、ＷＴＲＵに対する最初のＰＤＮ接続確立の間にＬＧＷによって割り当てられてもよい。あるいは、ＭＭＥはまた、ＬＧＷとともに少なくとも１つの相関ＩＤを割り当ててもよい。

あるいは、ターゲットＭＭＥ／ＳＧＳＮがハンドオーバ要求を受信するときに（例えば、Ｓ１ ＨＯに対する「ｈａｎｄｏｖｅｒ ｒｅｑｕｉｒｅｄ」メッセージ、またはＸ２ ＨＯプロシージャに対するパス切替え要求）、ＭＭＥ／ＳＧＳＮは、ＬＧＷにコンタクトし、および、ＭＲＡの潜在的変更をＬＩＰＡセッションに示してもよい。このことは、ＳＧＷを介して実行されてもよい。したがって、ＬＧＷは、このインジケーションを受信すると、ＬＩＰＡベアラに対する少なくとも１つの相関ＩＤを、オプションでＳＧＷを介して、ＭＭＥ／ＳＧＳＮに提供してもよい。したがって、ＭＭＥは、少なくとも１つの相関ＩＤをターゲットセルへのハンドオーバ要求またはパス切替え要求肯定応答メッセージ内に含めてもよい。ソースセル／ＭＭＥ／ＳＧＳＮはまた、あるベアラがＬＩＰＡに関連していることを通知するためのターゲットセルへの明示的なインジケーションを含んでもよい。

ターゲットセルによってハンドオーバ要求またはパス切替え要求肯定応答メッセージを受信すると、ターゲットセルは、任意の相関ＩＤまたは明示的なＬＩＰＡもしくはＭＲＡインジケーションが存在するかを検証してもよい。少なくとも１つの相関ＩＤが存在する場合、ターゲットセルはＬＧＷにコンタクトして、ＬＩＰＡトラフィックに使用されることになる直接パスに対するリソースをセットアップしてもよい。このインジケーションは、セッションがＬＩＰＡセッションであるべきであるというインジケーションを含んでもよい。ＬＧＷは、ＨｅＮＢ／ＨＮＢがそれとコンタクトして直接パスをセットアップした後に、直接パスを介してＨｅＮＢ／ＨＮＢへのダウンリンクＬＩＰＡベアラの転送を開始してもよい。

あるいは、ＭＭＥは、ＳＧＷに、修正ベアラ要求メッセージまたは他のメッセージを使用して、セッションがＬＩＰＡセッションとして維持されるべきであることを示してもよい。次いで、このＳＧＷは、ＬＩＰＡトラフィックに使用されるリソースをクリアしてもよい。このことは、ＬＧＷとＨｅＮＢ／ＨＮＢとの間の直接パスがセットアップされた後に行われてもよい。さらに、ＳＧＷはまた、対象のセッションがＬＩＰＡセッションとして継続されるべきであるということをＬＧＷに転送／通知してもよい。ＬＧＷは、ＬＩＰＡとしてセッションを継続するインジケーションを受信すると、直接パスをセットアップするために使用される少なくとも１つの相関ＩＤを割り当ててもよい。この情報は、ＭＭＥ／ＳＧＳＮに送信し返される。このことは、ＳＧＷを介して行われてもよい。ＭＭＥ／ＳＧＳＮはまた、この情報をターゲットＨｅＮＢ／ＨＮＢに転送してもよい。この明示的なインジケーションは、一部のベアラがＬＩＰＡセッションに対するものであることを指定してもよい。直接パスがセットアップされていない場合、ＨｅＮＢ／ＨＮＢは、少なくとも１つの相関ＩＤまたはＬＩＰＡに対する他の明示的なインジケーションを受信すると、ＬＧＷで直接パスをセットアップしてもよい。

あるいは、ＬＧＷはまた、例えば、修正ベアラ要求メッセージを使用して、ＭＭＥ／ＳＧＳＮによって提供されるＴＥＩＤ情報を使用してターゲットＨｅＮＢ／ＨＮＢと直接コンタクトしてもよい。このことは、ＳＧＷを介して行われてもよい。ＭＭＥ／ＳＧＳＮ／ＳＧＷは、前のステップでターゲットＨｅＮＢ／ＨＮＢから受信されたＴＥＩＤ情報を含んでもよい。これは、メッセージでＬＧＷに送信されるＬＩＰＡに関するインジケーションとともに使用されてもよく、当該メッセージは修正ベアラ要求メッセージであってもよい。次いで、ＬＧＷは、この情報を使用してＨｅＮＢ／ＨＮＢにコンタクトすることによって、直接パスがＬＩＰＡベアラに対してセットアップされるようにしてもよい。ＬＧＷはまた、ＬＩＰＡトラフィックに使用されることになる相関ＩＤを、ターゲットＨｅＮＢ／ＨＮＢに直接提供してもよい（ＬＧＷはまた、この情報をＭＭＥ／ＳＧＳＮに提供してもよい）。これは、修正ベアラ応答メッセージを使用してＳＧＷを介して行われてもよい。

上記のプロシージャのすべては、ＬＴＥシステム、３Ｇシステム、および、類似の機能性を有する任意の他のシステムに適用可能であってもよい。さらに、使用されているシグナリングメッセージおよび例は、ＬＴＥのコンテキストにおけるものであるが、同じことが類似のメッセージを使用する他のシステムにも適用可能であってもよい。本明細書で説明されているプロシージャは、ＬＩＰＡに関して説明されているが、同一のプロシージャをローカルネットワークにおけるＳＩＰＴＯに適用可能であってもよい。本明細書で説明されているすべての実施形態は、３Ｇ、ＬＴＥシステム、および任意の他の無線システムに等しく適用可能である。

実施形態

１．ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続モビリティのための、ターゲットホームＮｏｄｅＢ（ＨＮＢ）において実行される方法であって、無線送信／受信ユニット（ＷＴＲＵ）にハンドオーバするハンドオーバ要求メッセージをソースＨＮＢから受信するステップを備える方法。

２．ハンドオーバ要求メッセージに応答して、ターゲットＨＮＢへのダウンリンクデータパスを変更するパス切替え要求をローカルゲートウェイ（ＬＧＷ）に送信するステップをさらに備え、ＬＧＷはハンドオーバに対するモビリティ管理およびローカルモビリティアンカとして動作する、実施形態１に記載の方法。

３．ＨＮＢゲートウェイ（ＧＷ）にハンドオーバに関して通知することによって、コアネットワーク（ＣＮ）トラフィックに対するダウンリンクデータパスがターゲットＨＮＢに修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。

４．モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（ＳＧＷ）にハンドオーバに関するパス切替え要求を送信することによって、ＣＮトラフィックに対するダウンリンクデータパスがターゲットＨＮＢに修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。

５．サービング無線ネットワークサブシステム（ＳＲＮＳ）として動作するＨＮＢは、ハンドオーバ後に、ＷＴＲＵと無線アクセスネットワーク（ＲＡＮ）との間の無線接続を担当するように継続する上記実施形態のいずれかに記載の方法。

６．制御プレーンシグナリングはＳＲＮＳとして動作するＨＮＢにおいて維持される、上記実施形態のいずれかに記載の方法。

７．ＷＴＲＵが限定加入者グループ加入者リスト上にないという条件で、ＨＮＢはＳＲＮＳとして動作する、上記実施形態のいずれかに記載の方法。

８．ＬＩＰＡ ＰＤＮ接続がターゲットＨＮＢによってサポートされないという条件で、ＬＩＰＡ ＰＤＮサスペンションを開始するステップをさらに備える、上記実施形態のいずれかに記載の方法。

９．ＣＥＬＬ＿ＦＡＣＨモビリティの間、ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続を処理するための、ネットワークノードにおいて実行される方法であって、無線送信／受信ユニット（ＷＴＲＵ）からセル更新メッセージを受信するステップを備える方法。

１０．セル更新メッセージに応答して、ターゲットセルにおいてＬＩＰＡ ＰＤＮ接続のサポートを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１１．ターゲットセルがＬＩＰＡ ＰＤＮ接続をサポートしてないという条件で、ＬＩＰＡ ＰＤＮ接続を非活性化するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１２．セル更新メッセージは、既存のＬＩＰＡ ＰＤＮ接続のインジケーションを含む、上記実施形態のいずれかに記載の方法。

１３．ＬＩＰＡ ＰＤＮのサポートの判定は、ターゲットセル、ソースセル、または、コアネットワークのうちの少なくとも１つによって行われる、上記実施形態のいずれかに記載の方法。

１４．ＷＴＲＵは、アクティブなＬＩＰＡ ＰＤＮ接続の状態でのＣＥＬＬ＿ＦＡＣＨモビリティを無効化する、上記実施形態のいずれかに記載の方法。

１５．ローカルゲートウェイ（ＬＧＷ）間モビリティのための、ソースホームＮｏｄｅＢ（ＨＮＢ）において実行される方法であって、ターゲットＨＮＢがソースＬＧＷに接続されていないと判定するステップを備える方法。

１６．ソースＬＧＷおよびターゲットＬＧＷを接続することができることを検証するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１７．ソースＬＧＷおよびターゲットＬＧＷを接続することができるという条件で、ソースＬＧＷとターゲットＬＧＷとの間でトンネルを確立するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１８．トンネルが確立されるという条件で、データをターゲットＬＧＷに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１９．Ｘ２またはＩｕｒｈインタフェースを介して、ソースＨＮＢからターゲットＨＮＢにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

２０．ネットワークノードは、ＷＴＲＵからの情報に基づいて、ターゲットＬＧＷを選択する、上記実施形態のいずれかに記載の方法。

２１．メンバシップを検証するための、無線送信／受信ユニット（ＷＴＲＵ）において実行される方法であって、ブロードキャストパブリックランドモバイルネットワーク（ＰＬＭＮ）を受信するステップを備える方法。

２２．ホワイトリスト上のブロードキャストＰＬＭＮの存在を判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

２３．ブロードキャスト限定加入者グループ（ＣＳＧ）ＩＤがホワイトリスト上にあり、および、ホワイトリストＣＳＧ ＩＤに関連付けられたＰＬＭＮがブロードキャストＰＬＭＮと同等であるという条件で、ブロードキャストＰＬＭＮを含むようにホワイトリストを修正するステップをさらに備える、上記実施形態のいずれかに記載の方法。

２４．ＷＴＲＵは、修正情報をネットワークに送信する、上記実施形態のいずれかに記載の方法。

２５．マネージドリモートアクセス（ＭＲＡ）セッションを有効化する方法であって、モビリティ管理エンティティ（ＭＭＥ）がＭＲＡセッションに対するパケットデータネットワーク（ＰＤＮ）接続要求を受信するステップを備える方法。

２６．ＭＭＥが、ＰＤＮ接続要求を送信した無線送信／受信ユニット（ＷＴＲＵ）がＭＲＡサービスを使用することを許可されるか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

２７．ＰＤＮ接続要求は、ローカルネットワークに対するアクセスポイントネーム（ＡＰＮ）を含む、上記実施形態のいずれかに記載の方法。

２８．ＰＤＮ接続要求は、ノンアクセスストラタム（ＮＡＳ）メッセージによって伝達される、上記実施形態のいずれかに記載の方法。

２９．ＮＡＳメッセージは、ローカルゲートウェイ（ＬＧＷ）識別情報のＬＧＷインターネットプロトコル（ＩＰ）アドレスを含む、上記実施形態のいずれかに記載の方法。

３０．ＬＧＷ識別情報は、ローカルホームネットワーク（ＬＨＮ）識別を含む、上記実施形態のいずれかに記載の方法。

３１．ＭＭＥは、ＷＴＲＵが、ＷＴＲＵ加入者データ、および、ホームＮｏｄｅＢ（ＨＮＢ）、ホーム発展型ＮｏｄｅＢもしくはローカルゲートウェイ（ＬＧＷ）のＭＲＡ能力に基づいて、ＭＲＡサービスを使用することを許可するか否かを判定する、上記実施形態のいずれかに記載の方法。

３２．ＭＭＥがローカルゲートウェイ（ＬＧＷ）のアドレスまたはローカルホームネットワーク（ＬＨＮ）識別のうちの少なくとも１つを使用して、ローカルネットワークにおけるＬＧＷを選択するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３３．ＭＭＥが、ＷＴＲＵがＭＲＡサービスを使用することを許可されると判定するという条件で、ＰＤＮ接続を確立するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３４．ＭＭＥが、ＰＤＮ接続がローカルインターネットプロトコル（ＩＰ）アクセス（ＬＩＰＡ）接続またはＭＲＡ接続であるかのインジケーションを送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３５．インジケーションは、接続性タイプ情報要素（ＩＥ）に含まれる、上記実施形態のいずれかに記載の方法。

３６．ローカルゲートウェイ（ＬＧＷ）がインジケーションを受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３７．ＬＧＷが、相関識別（ＩＤ）を含む作成セッション応答メッセージを生成するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３８．ローカルホームネットワーク（ＬＨＮ）が、ＷＴＲＵに対するダウンリンクデータをサービングゲートウェイ（Ｓ−ＧＷ）に送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

３９．ＬＩＰＡ接続のインジケーションがＬＧＷによって受信されるという条件で、ＬＧＷがダミーパケットをサービングゲートウェイ（Ｓ−ＧＷ）に送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４０．ローカルホームネットワーク（ＬＨＮ）が、ＷＴＲＵに対するダウンリンクデータをＬＧＷに送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４１．ＭＲＡ接続のインジケーションがＬＧＷによって受信されるという条件で、ＬＧＷがダウンリンクデータをサービングゲートウェイ（Ｓ−ＧＷ）に転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４２．マクロネットワークにある間に、ＷＴＲＵをページングするステップをさらに備える、上記実施形態のいずれかに記載の方法。

４３．ＷＴＲＵがページングに応答するときに、ダウンリンクデータをＷＴＲＵに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４４．進行中のＬＩＰＡセッションによる無線送信／受信ユニット（ＷＴＲＵ）のハンドオーバの間に、ローカルインターネットプロトコル（ＩＰ）アクセス（ＬＩＰＡ）セッションを転送する方法であって、モビリティ管理エンティティ（ＭＭＥ）が、ＷＴＲＵがターゲットセルにおいてマネージドリモートアクセス（ＭＲＡ）セッションを有することを許可されるかを判定するステップを備える方法。

４５．ＭＭＥが、ハンドオーバを完了し、または、拒絶するかを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４６．ＭＭＥが、進行中のＬＩＰＡセッションをターゲットセルにおいてＭＲＡセッションとして継続することができるか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４７．ＷＴＲＵがターゲットセルにおいてＭＲＡセッションを有することを許可されるという条件で、ＭＭＥがハンドオーバを完了することを許可するステップをさらに備える、上記実施形態のいずれかに記載の方法。

４８．進行中のＭＲＡセッションによる無線送信／受信ユニット（ＷＴＲＵ）のハンドオーバの間に、マネージドリモートアクセス（ＭＲＡ）セッションを転送する方法であって、ソースモビリティ管理エンティティ（ＭＭＥ）が、ＷＴＲＵがＭＲＡセッションに加わっていることをターゲットＭＭＥに示すステップを備える方法。

４９．ターゲットＭＭＥが、ＷＴＲＵがターゲットセルにおいてローカルインターネットプロトコル（ＩＰ）アクセス（ＬＩＰＡ）セッションを有することを許可されると判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

５０．ターゲットセルにおいてＭＲＡセッションをＬＩＰＡセッションとして継続するステップをさらに備える、上記実施形態のいずれかに記載の方法。

５１．マネージドリモートアクセス（ＭＲＡ）セッションを有効化する方法であって、無線送信／受信ユニット（ＷＴＲＵ）がＭＲＡセッションに対するパケットデータネットワーク（ＰＤＮ）接続要求を開始するステップを備え、ＰＤＮ接続要求はローカルネットワークに対するアクセスポイントネーム（ＡＰＮ）を含む方法。

５２．モビリティ管理エンティティ（ＭＭＥ）が、ＰＤＮ接続要求を受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

５３．ＷＴＲＵがＭＲＡサービスを使用することを許可されているか否かを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

５４．ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法であって、ソースＨＮＢがＷＴＲＵに対するハンドオーバを要求するハンドオーバ要求メッセージをターゲットＨＮＢに送信するステップを備え、ハンドオーバ要求メッセージは、ターゲットＨＮＢとローカルゲートウェイ（ＬＧＷ）との間で直接ユーザパスを有効化するＵＥコンテキスト情報を含む方法。

５５．ハンドオーバ要求メッセージは、相関識別（ＩＤ）またはＬＧＷトンネルエンドポイント識別（ＴＥＩＤ）を含む、上記実施形態のいずれかに記載の方法。

５６．ＬＧＷは、ソースＨＮＢまたはターゲットＨＮＢと同一位置に配置される、上記実施形態のいずれかに記載の方法。

５７．ＬＧＷは、スタンドアロンデバイスである、上記実施形態のいずれかに記載の方法。

５８．ターゲットＨＮＢへダウンリンクデータパスを変更するパス切替え要求をＬＧＷに送信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

５９．ＨＮＢゲートウェイ（ＧＷ）にハンドオーバに関して通知することによって、コアネットワーク（ＣＮ）トラフィックに対するダウンリンクデータパスがターゲットＨＮＢに向かって修正されるステップをさらに備える、上記実施形態のいずれかに記載の方法。

６０．モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（Ｓ−ＧＷ）にハンドオーバに関して通知して、コアネットワーク（ＣＮ）ダウンリンクトラフィックに対するデータパスを切り替えるステップをさらに備える、上記実施形態のいずれかに記載の方法。

６１．ハンドオーバの後、サービング無線ネットワークサブシステム（ＳＲＮＳ）が、ＵＥと無線アクセスネットワーク（ＲＡＮ）との間の無線接続を担当することを継続する、上記実施形態のいずれかに記載の方法。

６２．ＳＲＮＳは、Ｓ１またはＩｕ／Ｉｕｈを終了する、上記実施形態のいずれかに記載の方法。

６３．コアネットワークと無線アクセスネットワーク（ＲＡＮ）との間の制御プレーンにおけるシグナリングは、サービング無線ネットワークサブシステムを通じてルーティングされることを継続する、上記実施形態のいずれかに記載の方法。

６４．ハンドオーバ後に、ユーザプレーントラフィックは、ＬＧＷからターゲットＨＮＢへルーティングされる、上記実施形態のいずれかに記載の方法。

６５．ハンドオーバ後に、ユーザプレーントラフィックは、サービング無線ネットワークサブシステム（ＳＲＮＳ）を通じてルーティングされる、上記実施形態のいずれかに記載の方法。

６６．ハンドオーバ後に、制御シグナリングパスおよびＬＩＰＡデータパスは同一のままであるが、非ＬＩＰＡデータパスが切り替えられる、上記実施形態のいずれかに記載の方法。

６７．ハンドオーバの前、または、ハンドオーバの間に、ＵＥに対して加入者チェックを実行して、ＷＴＲＵがターゲットセルにおいてＬＩＰＡサービスに対して許可されるかを保証するステップをさらに備える、上記実施形態のいずれかに記載の方法。

６８．ＬＧＷは、ＬＩＰＡ ＰＤＮ接続を確立すると、コアネットワーク（ＣＮ）ノードから加入者情報を取得する、上記実施形態のいずれかに記載の方法。

６９．ＬＧＷは、それがパス切替え要求メッセージを受信したときに、サブスクリプションをチェックする、上記実施形態のいずれかに記載の方法。

７０．ＬＩＰＡベアラがターゲットセルにおいてサポートされない場合に、ＬＩＰＡ ＰＤＮ接続を解放するステップをさらに備える、上記実施形態のいずれかに記載の方法。

７１．ターゲットＨＮＢが、ＷＴＲＵがＬＩＰＡ ＰＤＮ接続を有していることを、ＷＴＲＵ無線アクセスベアラコンテキストにおける相関ＩＤの存在から判定する、上記実施形態のいずれかに記載の方法。

７２．ＬＩＰＡ ＰＤＮ接続の解放は、ターゲットセル、ＬＧＷ、または、コアネットワークによって開始される、上記実施形態のいずれかに記載の方法。

７３．ＬＩＰＡがターゲットセルにおいてサポートされているか否かでも、ソースＨＮＢがＬＩＰＡ ＰＤＮ接続を非活性化しない、上記実施形態のいずれかに記載の方法。

７４．ＷＴＲＵがＣＥＬＬ＿ＦＡＣＨ状態にある、上記実施形態のいずれかに記載の方法。

７５．ネットワークは、セル更新プロシージャに間に、または、ＣＥＬＬ＿ＦＡＣＨモビリティの間もしくはその後に、ＬＩＰＡ ＰＤＮ接続を非活性化する、上記実施形態のいずれかに記載の方法。

７６．ＷＴＲＵがセル更新プロシージャの間に、ルーティングエリア更新（ＲＡＵ）を実行するステップをさらに備える、上記実施形態のいずれかに記載の方法。

７７．ルーティングエリア識別が変化しなかった場合でも、ＷＴＲＵがＲＡＵを実行する、上記実施形態のいずれかに記載の方法。

７８．サービングＧＰＲＳサポートノード（ＳＧＳＮ）がＬＩＰＡ ＰＤＮ接続の非活性化をトリガするステップをさらに備える、上記実施形態のいずれかに記載の方法。

７９．ＳＧＳＮが無線ネットワークコントローラ（ＲＮＣ）リロケーションに対する要求を受信した場合に、ＷＴＲＵが新たなセルに移動したかを検証する、上記実施形態のいずれかに記載の方法。

８０．ＳＧＳＮが、ターゲットセル識別子を、ＬＩＰＡ ＰＤＮ接続が確立されたソースセルのセル識別と比較する、上記実施形態のいずれかに記載の方法。

８１．ＬＧＷのアドレスは、無線ネットワークコントローラ（ＲＮＣ）リロケーションを実行するＳＧＳＮへの要求に含まれる、上記実施形態のいずれかに記載の方法。

８２．要求は、ターゲットＨＮＢが接続するＬＧＷのアドレスを含む、上記実施形態のいずれかに記載の方法。

８３．ＳＧＳＮが、ＬＧＷのアドレスをＬＩＰＡ ＰＤＮ接続に使用されているＬＧＷと比較する、上記実施形態のいずれかに記載の方法。

８４．無線ネットワークコントローラ（ＲＮＣ）のリロケーションに対する要求は、ＳＧＳＮがＬＧＷおよびＷＴＲＵへのＬＩＰＡ ＰＤＮ接続を非活性化するようにトリガする、上記実施形態のいずれかに記載の方法。

８５．ＳＧＳＮへのリロケーション要求が、ソース無線ネットワークコントローラ（ＲＮＣ）によって送信される、前記実施形態のいずれかに記載の方法。

８６．ソースＨＮＢは、ＬＩＰＡ ＰＤＮ接続を、接続モードのハンドオーバが行われるかのように処理する、上記実施形態のいずれかに記載の方法。

８７．ＬＩＰＡ ＰＤＮの非活性化が、ＳＧＳＮへのリロケーションに対する要求が送信される前に行われる場合、ＳＧＳＮは、ＬＩＰＡ ＰＤＮ接続がソースＨＮＢによってリリースされているかどうかを検証する、上記実施形態のいずれかに記載の方法。

８８．ＳＧＳＮが、ＬＩＰＡ ＰＤＮ接続が非活性化されているか、または、非活性化される必要があることをソース無線ネットワークコントローラ（ＲＮＣ）に示す、上記実施形態のいずれかに記載の方法。

８９．ＬＩＰＡ ＰＤＮ接続が存在する場合に、ＷＴＲＵがＣＥＬＬ＿ＦＡＣＨモビリティを無効化する、上記実施形態のいずれかに記載の方法。

９０．ＷＴＲＵに対したアクティブなＬＩＰＡ ＰＤＮ接続が存在する場合に、ソースＨＮＢがサービング無線ネットワークコントローラ（ＲＮＣ）リロケーションを実行しない、上記実施形態のいずれかに記載の方法。

９１．ソースＲＮＣが、確立されたトンネルを介してＬＩＰＡデータをターゲットＲＮＣに転送することを保持し、および、ＬＩＰＡ ＰＤＮ接続が維持される、上記実施形態のいずれかに記載の方法。

９２．無線ネットワークコントローラ（ＲＮＣ）リロケーションが実行されない場合でも、ＬＩＰＡベアラは非活性化され、および、非ＬＩＰＡベアラは維持される、上記実施形態のいずれかに記載の方法。

９３．ＵＰＬＩＮＫ ＳＩＧＮＡＬＬＩＮＧ ＴＲＡＮＳＦＥＲメッセージがターゲット無線ネットワークコントローラ（ＲＮＣ）によって使用されて、共通制御チャネル（ＣＣＣＨ）上で受信されたメッセージをサービングＲＮＣに転送する、上記実施形態のいずれかに記載の方法。

９４．ソースＲＮＣは、ＳＲＮＣ無線ネットワーク一時識別（Ｓ−ＲＮＴＩ）を検証し、および、ＷＴＲＵがＬＩＰＡベアラを有していたか否かを判定し、ＷＴＲＵがＬＩＰＡベアラを有していた場合に、ソースＲＮＣは、ＬＩＰＡベアラを解放することをＬＧＷに通知する、上記実施形態のいずれかに記載の方法。

９５．ＵＥが、ＷＴＲＵがセル更新メッセージにＬＩＰＡ ＰＤＮ接続を有しているというインジケーションを含める、上記実施形態のいずれかに記載の方法。

９６．ＷＴＲＵコンテキストがフェッチされ、および、ターゲットセルに転送される前に、ローカルネットワークにおけるＬＩＰＡをターゲットセルにおいて継続することができるか否かを検証するステップをさらに備える、上記実施形態のいずれかに記載の方法。

９７．ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法であって、ＷＴＲＵがＬＩＰＡカバレッジの外へ移動するときに、ＬＩＰＡベアラをサスペンドするステップを備える方法。

９８．ＵＥがＬＩＰＡをサポートするセルに戻ったときに、ＬＩＰＡベアラを再開するステップをさらに備える、上記実施形態のいずれかに記載の方法。

９９．ソースセルが、ＬＩＰＡベアラをターゲットセルにハンドオーバすることができないと判定した場合に、ソースセルはＬＩＰＡベアラに対するコンテキストを除去し、ＬＩＰＡ ＰＤＮ接続を非活性化することを他のノードに通知しない、上記実施形態のいずれかに記載の方法。

１００．ソースセルは、ＬＩＰＡ ＰＤＮ接続がアクティブであるが、ターゲットセルにおいて現在ＬＩＰＡベアラがセットアップされていないという特別なインジケーションを、ローカルゲートウェイ（ＬＧＷ）およびコアネットワーク（ＣＮ）ノードに送信する、上記実施形態のいずれかに記載の方法。

１０１．特別なインジケーションを受信すると、ＬＧＷがＷＴＲＵに対するすべてのダウンリンクトラフィックをバッファリングするステップをさらに備える、上記実施形態のいずれかに記載の方法。

１０２．ＷＴＲＵがＬＩＰＡカバレッジに入り、および、ＬＩＰＡベアラが再開されたときに、バッファリングされたトラフィックがＷＴＲＵに送信される、上記実施形態のいずれかに記載の方法。

１０３．ＷＴＲＵが、タイマが満了するまでＬＩＰＡカバレッジに戻らない場合に、バッファリングされているデータを破棄するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１０４．ＷＴＲＵがアイドルモードに入るステップをさらに備え、ＷＴＲＵがサスペンドされたＬＩＰＡベアラを有している場合、バッファリングされているデータを破棄するためのタイマが停止される、上記実施形態のいずれかに記載の方法。

１０５．ＷＴＲＵが接続モードに戻ったときに、タイマが再開する、上記実施形態のいずれかに記載の方法。

１０６．ＷＴＲＵがトラッキングエリア更新（ＴＡＵ）またはルーティングエリア更新（ＲＡＵ）を実行するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１０７．ＷＴＲＵがキャンプオンしているセルがＬＩＰＡをサポートしているかをチェックするステップをさらに備える、上記実施形態のいずれかに記載の方法。

１０８．セルがＬＩＰＡをサポートしている場合に、ＬＩＰＡベアラは再開され、および、ローカルゲートウェイ（ＬＧＷ）はバッファリングされているデータをＷＴＲＵに送信する、上記実施形態のいずれかに記載の方法。

１０９．ＬＩＰＡベアラのサスペンションは、ソースセル、ターゲットセル、ローカルゲートウェイ、またはコアネットワークによって開始される、上記実施形態のいずれかに記載の方法。

１１０．ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法であって、ＬＩＰＡ ＰＤＮ接続による無線アクセス技術（ＲＡＴ）間ハンドオーバに対するハンドオーバ要求メッセージをコアネットワークノードに送信するステップを備える方法。

１１１．ＲＡＴ間ハンドオーバは、ホームＮｏｄｅＢ（ＨＮＢ）とホーム発展型ＮｏｄｅＢ（ＨｅＮＢ）との間である、上記実施形態のいずれかに記載の方法。

１１２．ＲＡＴ間ハンドオーバは、ホーム（発展型）ＮｏｄｅＢ（Ｈ（ｅ）ＮＢ）とマクロネットワークＮｏｄｅＢとの間である、上記実施形態のいずれかに記載の方法。

１１３．ハンドオーバ要求メッセージは、アクティブなＬＩＰＡ ＰＤＮ接続が存在し、および、ＬＩＰＡベアラはターゲットセルに転送される必要があることを示す、上記実施形態のいずれかに記載の方法。

１１４．ＷＴＲＵコンテキスト情報は、相関ＩＤまたはローカルゲートウェイ（ＬＧＷ）トンネルエンドポイント識別（ＴＥＩＤ）とともにターゲットセルに送信される、上記実施形態のいずれかに記載の方法。

１１５．ＬＩＰＡベアラをターゲットセルにおいて受け付けることができるかを判定するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１１６．ターゲットセルがローカルゲートウェイ（ＬＧＷ）とのユーザプレーン接続を作成するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１１７．ターゲットセルがＬＧＷとトンネルエンドポイント識別子（ＴＥＩＤ）を交換するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１１８．ＬＧＷがサービングＧＰＲＳサポートノード（ＳＧＳＮ）との接続を作成するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１１９．ローカルＩＰアクセス（ＬＩＰＡ）パケットデータネットワーク（ＰＤＮ）接続によるホームＮｏｄｅＢ（ＨＮＢ）モビリティのための方法であって、ソースローカルゲートウェイ（ＬＧＷ）からターゲットＬＧＷにＬＩＰＡ ＰＤＮ接続によるハンドオーバに対するハンドオーバ要求メッセージを送信するステップを備える方法。

１２０．ソースＬＧＷとターゲットＬＧＷとの間の直接インタフェースを介してソースＬＧＷからターゲットＬＧＷにデータを転送するステップをさらに備える、実施形態６５に記載の方法。

１２１．ソースＨｅＮＢが、モビリティ管理エンティティ（ＭＭＥ）、ターゲットＬＧＷ、または、ターゲットＨＮＢからターゲットＬＧＷに関する情報を取得する、上記実施形態のいずれかに記載の方法。

１２２．ソースＨＮＢが、ターゲットＨｅＮＢがＬＩＰＡベアラとのＬＧＷ間ハンドオーバをサポートしているというインジケーションをターゲットＨＮＢから受信する、上記実施形態のいずれかに記載の方法。

１２３．ソースＬＧＷが、ＩＰポイントオブプレゼンス（ＩＰ ＰＯＰ）に留まり、および、ＷＴＲＵのＩＰアドレスはハンドオーバ後も変化しない、上記実施形態のいずれかに記載の方法。

１２４．ＵＥが、ハンドオーバ後に、新たなＩＰアドレスを取得する、上記実施形態のいずれかに記載の方法。

１２５．Ｘ２またはＩｕｒｈインタフェースを介してソースＨＮＢからターゲットＨＮＢにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１２６．データをソースＨＮＢからターゲットＬＧＷに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１２７．ターゲットＬＧＷがターゲットＨＮＢを介してデータをＷＴＲＵに転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１２８．サービングゲートウェイ（Ｓ−ＧＷ）を介してソースＬＧＷからターゲットＬＧＷにデータを転送するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１２９．ＷＴＲＵがソースＬＧＷのカバレッジの外へ移動するときに、ソースＨＮＢがＬＩＰＡ ＰＤＮ接続を非活性化しない、上記実施形態のいずれかに記載の方法。

１３０．セルのパブリックランドモバイルネットワーク（ＰＬＭＮ）識別を含むセルからブロードキャストを受信するステップをさらに備える、上記実施形態のいずれかに記載の方法。

１３１．ＰＬＭＮ ＩＤがＷＴＲＵのホワイトリストに含まれていないが、同等のＰＬＭＮである場合、ＷＴＲＵがＰＬＭＮを含むようにホワイトリストを更新する、上記実施形態のいずれかに記載の方法。

１３２．ＷＴＲＵが、ホワイトリストの更新の結果として、トラッキングエリア更新（ＴＡＵ）またはルーティングエリア更新（ＲＡＵ）を開始する、上記実施形態のいずれかに記載の方法。

１３３．トラッキングエリア識別（ＴＡＩ）もしくはルーティングエリア識別（ＲＡＩ）、または、ＴＡＵ／ＲＡＵタイマの満了の変更がない場合であっても、ＷＴＲＵがＴＡＵまたはＲＡＵを開始する、上記実施形態のいずれかに記載の方法。

１３４．ＬＩＰＡサービスアクセス認可（authorization）は、アクセスポイントネーム（ＡＰＮ）、限定加入者グループ（ＣＳＧ）、および、パブリックランドモバイルネットワーク（ＰＬＭＮ）の組合せに基づいて定義される、上記実施形態のいずれかに記載の方法。

１３５．セルは、パブリックランドモバイルネットワーク（ＰＬＭＮ）毎に複数の限定加入者グループ（ＣＳＧ）識別子（ＩＤ）をブロードキャストする、上記実施形態のいずれかに記載の方法。

１３６．セルを共有する各ＰＬＭＮ毎に１つのＣＳＧ ＩＤがブロードキャストされる、上記実施形態のいずれかに記載の方法。

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

Claims (6)

1. セレクティドＩＰトラフィックオフロード（ＳＩＰＴＯ）接続モビリティのための、ユニバーサルモバイル通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）または発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）ホームＮｏｄｅＢ（ＨＮＢ）において実行される方法であって、
   無線送信／受信ユニット（ＷＴＲＵ）をもう一つのＮｏｄｅＢにハンドオーバするメッセージを受信するステップであって、前記ＷＴＲＵは、ローカルホームネットワーク識別（ＩＤ）を有するローカルホームネットワーク、およびローカルゲートウェイアドレスとローカルゲートウェイＩＤとを有するローカルゲートウェイとのＳＩＰＴＯを使用するように構成されている、ステップと、
   前記ＷＴＲＵがＳＩＰＴＯを使用するように構成されていることを条件に、少なくとも前記ローカルホームネットワークＩＤを含むＳ１ＡＰメッセージをネットワークノードに送信するステップと
   を備えたことを特徴とする方法。
2. 前記ネットワークノードは、モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（ＳＧＷ）であることを特徴とする請求項１に記載の方法。
3. 前記メッセージは、Ｓ１インタフェース上で送信されることを特徴とする請求項１に記載の方法。
4. ユニバーサルモバイル通信システム（ＵＭＴＳ）地上波無線アクセス（ＵＴＲＡ）または発展型ＵＴＲＡ（Ｅ−ＵＴＲＡ）ホームＮｏｄｅＢ（ＨＮＢ）であって、
   無線送信／受信ユニット（ＷＴＲＵ）をもう一つのＮｏｄｅＢにハンドオーバするメッセージを受信するように構成された受信機であって、前記ＷＴＲＵは、ローカルホームネットワーク識別（ＩＤ）を有するローカルホームネットワーク、およびローカルゲートウェイアドレスとローカルゲートウェイＩＤとを有するローカルゲートウェイとのＳＩＰＴＯを使用するように構成されている、受信機と、
   前記ＷＴＲＵがＳＩＰＴＯを使用するように構成されていることを条件に、少なくとも前記ローカルホームネットワークＩＤを含むＳ１ＡＰメッセージをネットワークノードに送信するように構成された送信機と
   を備えたことを特徴とするＨＮＢ。
5. 前記ネットワークノードは、モビリティ管理エンティティ（ＭＭＥ）／サービングゲートウェイ（ＳＧＷ）であることを特徴とする請求項４に記載のＨＮＢ。
6. 前記メッセージは、Ｓ１インタフェース上で送信されることを特徴とする請求項４に記載のＨＮＢ。

Images