JP2012524424A - 移動通信システムにおけるローカルデバイスアクセスの管理装置 - Google Patents

Abstract

本発明は、ＨＮＢ又はＨｅＮＢによって行われる理にかなった切り替えを通じて、ユーザのローカルデバイスアクセストラフィックに用いられるルートの管理に好都合である方法を提供する。このスイッチングを行うための情報は、選択された通信チャンネルを用いてトークンの伝達を通じて得られる。本発明では、トークンやチャンネルの選択、構成に関する様々な態様が可能である。
【選択図】図１

Description

本発明は、移動データ通信ネットワークに関し、特に移動通信システムにおけるローカルデバイスへのアクセス管理に関する。

移動通信の進歩に伴って、第三世代パートナーシッププログラム：3rd Generation Partnership Program（３ＧＰＰ）では、小型化されたアクセスノードとして配置されるホーム・ノードＢ：Home NodeB（ＨＮＢ）やホーム・イーノードＢ：Home eNodeB（ＨｅＮＢ）の概念が導入された。これらの小型アクセスノードの使用により、端末のユーザに、サービス範囲の拡張や、非常に高速度でより低コストの新たなサービスの提供をもたらす。そのようなノードは、従来のユーザのブロードバンドネットワークに影響を与え、携帯電話オペレータにとって合法的通信傍受の必要性が緩和されるだけでなく、低リソースコストをもたらす。ユーザにとっては、ＨＮＢ又はＨｅＮＢを介した接続は、通常は料金の減額と付加的なサービスの提供とを意味する。

利用者宅内・構内向けアクセスノードの導入により、３ＧＰＰはローカルＩＰアクセス（下記の非特許文献１を参照）における利用ケースをも生み出した。ローカルＩＰアクセス：Local IP Access（ＬＩＡ）により、ＨＮＢ／ＨｅＮＢのクローズド・サブスクライバー・グループ：Closed Subscriber Group（ＣＳＧ）セルにアクセスするユーザ装置：User Equipment（ＵＥ）は、オペレータのコアネットワークのほか、ＨＮＢ／ＨｅＮＢに接続されたネットワークにアクセスできる。このＬＩＡは、オペレータのコアネットワークを通ることなく、家庭（ホーム）内ネットワークへのアクセスやインターネットへのアクセスを含む。ＵＥが同時にＬＩＡとオペレータのコアネットワークにアクセスすることが求められていた。３ＧＰＰはさらにＵＥがマクロセルを経由してＬＩＡにアクセスできるケースを導入した。

これらの新たな利用ケースは展開される潜在的なサービスの価値を大きく高めるとともに、コアネットワークからのトラフィックをオフロードするのに役立つ。下記の非特許文献２に規定される従来のオペレーション手続はこれらのシナリオを実現するために再利用できる。

Vesterinen, Aalto, Kekki, “Method, Radio System, Mobile Terminal and Base Station for Providing Local Break-out Service”, WIPO Patent Application WO 2008/125729 A1, 23 October 2008.

Service requirements for Home NodeB (HNB) and Home eNodeB (HeNB), 3GPP TS22.220 v1.0.1 Release 9, 2008-12. General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access, 3GPP TS23.401 v8.4.0 Release 8, 2008-12.

しかしながら、ＨＮＢ／ＨｅＮＢ向けのアーキテクチャは特殊であることから、ＬＩＡには非効率性の問題が存在する。例えば、ＨＮＢ／ＨｅＮＢはＩＳＰネットワークを介してオペレータのコアネットワークに接続されるので、例えば帯域や遅延などの面で、このリンクを通しての性能には制限が生じる。非特許文献１に規定されるアーキテクチャによれば、ＵＥからのすべてのトラフィックは、ＰＤＮ（パケットデータネットワーク）ゲートウェイ：Gateway（ＰＧＷ）とあて先に到着する前にサービングゲートウェイ：Serving Gateway（ＳＧＷ）を通らなければならない。これは、ＵＥがリモートの位置でＬＩＡを行うとき、移動オペレータのネットワークを横断するデータの合法的通信傍受の必要性のためと、アカウンティングの目的の双方のために行われる。しかし、この必要性は、ユーザ自身のＨＮＢ又はＨｅＮＢのもとでＵＥがローカルにＬＩＡを行っているときにはさほど意味を有さない。そのようなシナリオでは、ＥＰＣ（Evolved Packet Core）を通過することは、コストがかかり、非効率で効果的ではない。

非特許文献３に規定される発明において、ＵＥは、ＵＥの基地局によってアナウンスされるＩＰ（インターネットプロトコル：Internet Protocol）ゲートウェイにローカルブレイクアウトサービスが利用できるか検出する構成とされている。ＵＥは、３ＧＰＰサービスを使用し続けると同時に、インターネットにローカルブレイクアウトサービスを利用するためのインターネットプロトコルスタックを形成することができる。しかし、この解法は、影響を与えずにそれぞれのモードの利益を最大化しようとする限り、リモートからローカル状態（その逆も同様）へＬＩＡサービスをシームレスに移動する問題を解くことはできない。

上記に基づき、前記問題に対するよりよい解決方法が必要であることは明らかである。

本発明の目的は上述した問題を解くことであり、特に必要であることを行う方法を提供することがねらいである。

上記目的を達成するために、本発明はＨｅＮＢを提供する。ＵＥがローカルでＬＩＡを行うときにはプロキシＰＧＷとして機能し、ＵＥがリモートでアクセスするときにはシームレスにＥＰＣのＰＧＷに機能を切り換えることを可能とするＨｅＮＢ用の装置が提供される。

本発明は、ＨＮＢ又はＨｅＮＢによって行われる理にかなった切り替えを通じて、ユーザのローカルデバイスアクセストラフィックに用いられるルートの管理に好都合である。

本発明が適用され得るネットワーク構成の一例を示す図 本発明のリモート初期化における動作シーケンスの一例を示す図 本発明のリモート初期化における他の動作シーケンスの一例を示す図 本発明のローカル初期化における動作シーケンスの一例を示す図 本発明の外向きハンドオーバにおける動作シーケンスの一例を示す図 本発明の内向きハンドオーバにおける動作シーケンスの一例を示す図 本発明を実施するＨｅＮＢの構成の一例を示す図 本発明のホーム・イーノードＢ（ＨｅＮＢ）によってなされるロジックの一例を示す図 本発明が適用され得る他のネットワーク構成の一例を示す図 本発明を実施する他のホーム・イーノードＢ（ＨｅＮＢ）の構成の一例を示す図 本発明が適用され得るネットワーク構成の一例を示す図 本発明が適用され得るネットワーク構成の一例（ＬＧＷとＨ（ｅ）ＮＢの双方が企業ネットワークに属する）を示す図 本発明が適用され得るＬＩＡドメインのネットワーク構成の一例を示す図

以下の記述において、数、時間、構造、プロトコル、他のパラメータは、本発明の理解を促すために与えられたものである。しかし、当業者であれば、これらの詳細なものがなくても本発明を理解できるのは明らかである。

以下の記述において、3GPP ロング・ターム・エボリューション：Long Term Evolution（ＬＴＥ）はアクセステクノロジの一例として用いられる。しかし、当業者であれば、同じ原理の下で、他のアクセステクノロジにより本発明が実現できることは明らかである。

＜第１の実施の形態＞
図１は、ここで説明される発明の最適な動作のためのネットワークエンティティ（実体）とユーザ装置：User Equipment（ＵＥ）の特定の配置を示す図である。この配置においては、ＨｅＮＢ１２３は、ユーザのホームネットワーク１１４へのアクセスを提供する。本発明は、プロキシＰＧＷ（ＰＤＮゲートウェイ）動作として後述される好ましい動作を考慮に入れている。

プロキシＰＧＷ動作により、ローカルＩＰアクセスサービス（リモートかローカルかどちらか）にアクセスするＵＥは、ＰＧＷとして役目を果たすエンティティの変化に気づかないことがあり、現在の位置にかかわらずサービスを開始する共通の手続を用いることがある。ネットワークの視点からは、ＵＥにサービスを提供するＰＧＷはＰＧＷ１３３である。しかし、ネットワークは、ローカルＵＥ１０３からのローカルＩＰアクセスサービスのためのプロキシＰＧＷとして動作することによりＨｅＮＢ１２３によってローカルのＵＥに提供される最適化サービスを認める選択肢を有する。ネットワークにとってのメリットは、ＵＥがより遅延が少なく可能な限り高いスループットを有するトラフィックを享受し、経路１５２、１５３に沿ったリソースを節約できることである。

リモートの位置からローカルＩＰデバイスにアクセスするＵＥ（例えば、ＵＥ１０１、１０２）に関して、ホームネットワーク１１４からのトラフィックは、経路１５４を通ってＨｅＮＢ１２３へ届き、ＨｅＮＢ１２３は、これを経路１５３を介してＰＧＷ１３３に転送し、次には経路１５７を介してＳＧＷ１３２に転送される。ＵＥの位置によって、ＳＧＷ１３２はｅＮＢ１２１又はＨｅＮＢ１２２のどちらかにトラフィックを転送する。この方法において、ユーザトラフィックがＥＰＣ１１５を横断するとき、ネットワークはＰＧＷ１３３とＳＧＷ１３２を介して正確なアカウント情報を得ることができ、必要であれば合法的な通信傍受の需要を満たすこともできる。

プロキシＰＧＷの動作の必要条件は、ＨｅＮＢ１２３とＰＧＷ１３３との間の通信チャンネルの存在である。この通信チャンネルは様々な態様があり、ここで用いられる例はＩＰ（Internet Protocol）トンネルである。ＩＰトンネルは、オリジナルのＩＰパケットのエンドツーエンド経路に沿って、２つの中間ノード間を中間ルーティングするため、外部ＩＰパケットで内部ＩＰパケットをカプセル化するという単なる方法である。

リモートの位置のＵＥへと指定され、ホームネットワーク１１４に源を発するデータパケットは、トンネル１５３を通ってＨｅＮＢ１２３によってＰＧＷ１３３へ転送される。リモートの位置のＵＥからホームネットワーク１１４へと指定されたトラフィックも同様に、ＨｅＮＢ１２３によって最終目的地（例えば、ＴＶ１０４）に送信される前に、トンネル１５３を介してＰＧＷ１３３によってＨｅＮＢ１２３へ転送される。

ＰＧＷ１３３とＨｅＮＢ１２３との間の通信チャンネルの生成は、様々な状況下で開始され得る。１つの可能性としては、ＰＧＷ１３３とＨｅＮＢ１２３との間でＩＰトンネルが常に生成され、維持されている場合である。例えば、ＨｅＮＢ１２３の起動及びＥＰＣ１１５への登録があると、オペレータポリシやサブスクリプションサービスプランによりＰＧＷ１３３がトンネルの確立を開始する。この場合、ＩＰトンネルは異なる複数のＵＥによってシェア（共有）される。

他の可能性としては、ＵＥから実際の要求があったときに、この通信トンネルが動的に初期化され、維持されることがある。要求を出すＵＥは、ＩＰアドレスなど、ＨｅＮＢ１２３にいかに接触するかに関する情報をＰＧＷ１３３に送るか、あるいは、かかる情報はホーム・サブスクライバー・サーバ：Home Subscriber Server（ＨＳＳ）又はモビリティ管理エンティティ：Mobility Management Entity（ＭＭＥ）内のＵＥのユーザプロファイルに格納される。この場合、ＵＥごとに１つのＩＰトンネルが確立される。

ＵＥがＨｅＮＢ１２３に関する情報をＰＧＷ１３３に提供する場合のシナリオの特定された１つの実現としては、例えば、非特許文献２で規定されるプロトコル・コンフィグレーション・オプション：Protocol Configuration Option（ＰＣＯ）情報内にＨｅＮＢ１２３のフリー・クオリファイド・ドメイン・ネーム：Fully Qualified Domain Name（ＦＱＤＮ）という形式をとって要求された情報を送信することである。ＰＧＷ１３３はＦＱＤＮをＨｅＮＢ１２３の実際のアドレスに分解することができ、それによりＩＰトンネルを確立することができる。

他の可能性としては、ＵＥがＮＡＳシグナリングメッセージに含まれるＡＰＮ（アクセスポイントネーム：Access Point Name）内で特定のサービス情報を指摘することである。ＭＭＥはＵＥのサブスクリプション情報に基づいてＨｅＮＢ１２３のドメイン情報をＡＰＮに付加する。ＰＧＷ１３３は、この付加されたＡＰＮを用いてＨｅＮＢ１２３のアドレスを解決することができる。

これは、ＵＥがローカルＩＰアクセスサービスを要求するときのＰＤＮ接続確立において実施できる。非特許文献２では、ＵＥ要求ＰＤＮ接続手続（UE Requested PDN Connectivity）同様に、サービス要求手続（Service Request）が規定される。ＨｅＮＢ１２３をＰＧＷ１３３が識別するための他のタイプの情報、例えばＨｅＮＢ１２３のＩＰアドレス、をＵＥが選択できることは当業者であれば自明である。

ＰＧＷ１３３とＨｅＮＢ１２３との間の通信チャンネルの確立が開始されると、ＰＧＷ１３３は与えられた情報を用いてSet-Up-Request（確立要求）メッセージをＨｅＮＢ１２３に送信する。Set-Up-Requestメッセージの受信により、ＨｅＮＢ１２３はオプションとして更なる認証（authentication）と認可（authorisation）のチェックを行う。

例えば、ＩＰトンネルがＵＥの要求に基づいて動的に確立される場合、Set-Up-Requestは、ＨｅＮＢ１２３とのセキュリティアソシエーションから得られるＵＥからの付加情報を送信する。この情報は、ＰＣＯに入れられＰＧＷ１３３によって転送される。ＨｅＮＢ１２３は、ＵＥがローカルＩＰアクセスサービスに接続することを認めるかを決定するためにこの情報を用いることができる。

ＨｅＮＢ１２３がSet-Up-Requestを受信すると、ＨｅＮＢ１２３はSet-Up-Response（確立応答）メッセージを送信する。確立メッセージが交換された後、セキュリティアソシエーションがＰＧＷ１３３とＨｅＮＢ１２３との間に確立され、それらの間で交換されるメッセージが保護される。

ＨｅＮＢ１２３は、ＨｅＮＢ１２３自身とＰＧＷ１３３との間のトンネルを一意に識別できるユニークなトークン（Ｔｏｋｅｎ）を送信する。このトークンは、ＨｅＮＢ１２３がトンネルとＰＧＷ１３３を的確に識別するために用いることができるのであれば、テキスト配列、整数やハッシュ配列などの形式をとることができる。２つのエンティティ間で通信チャンネルを確立するために様々な交換がなされ、本発明にとって重要なことはＨｅＮＢ１２３からＰＧＷ１３３へトークンが送信されることにある。

ＵＥ１０１はリモートの位置、すなわちｅＮＢ１２１経由でローカルＩＰアクセスサービスへの接続要求を発行する。１つの実施例として、ＰＧＷ１３４が３Ｇサービスに用いられ、ＵＥ１０１はこのサービスへの要求のためにＵＥ要求ＰＤＮ接続（UE Requested PDN Connectivity）手続を利用すると仮定する。図２を用いて本発明の動作を説明する。ＵＥ１０１はＰＤＮ接続要求（PDN Connectivity Request）２００を開始し、ＰＧＷ１３３に向けてＰＣＯにＨｅＮＢ１２３のＦＱＤＮを含める。

ＭＭＥ１３１は、必要であればＵＥ１０１の関連する認証（authentication）チェックを行い、ＵＥ１０１のリモートでのローカルＩＰアクセスサービスが許されるかを決定するためのアクセス制御も行う。ＨｅＮＢ１２３へのアクセスがＵＥ１０１の許可ＣＳＧリストに依存し、ＭＭＥ１３１が必要なチェックを行うことは可能であって、そのように行われるであろう。ＵＥ１０１が要求したサービスに必要な権限を有すると仮定すると、ＭＭＥ１３１はデフォルトベアラ生成要求（Create Default Bearer Request）２０５をＳＧＷ１３２に送信し、ＳＧＷ１３２はＰＧＷ１３３へCreate Default Bearer Request２１０を転送する。

ＰＧＷ１３３はＰＣＯからＨｅＮＢ１２３のＦＱＤＮを抽出し、ＨｅＮＢ１２３の（ＩＰ）アドレスを得るためにＦＱＤＮを解析する。ＰＧＷ１３３はＨｅＮＢ１２３との通信チャンネルが存在するかをチェックする。トンネルは存在しないため、ＰＧＷ１３３は上述したように、ＨｅＮＢ１２３との通信チャンネルを確立する（２１５）。この間に、セキュリティ鍵が交換され（２２０）、ＨｅＮＢ１２３はＰＧＷ１３３へユニークなトークン（２２５）を渡す。

ＰＧＷ１３３は、この通信チャンネルでのトークンをＨｅＮＢ１２３と関連つける。ＨｅＮＢは、プロキシＰＧＷとしての機能を確実に行うために（もしあれば）それぞれのＵＥとＰＧＷ１３３との間で共有されるセキュリティ鍵の知識（情報）を必要とする。ＰＧＷ１３３がＵＥのセキュリティ鍵と異なるものを用いる場合、関連する鍵（２２０）でＨｅＮＢ１２３を更新しなければならない。

ＰＧＷ１３３は、ＵＥ１０１のためにホームネットワーク１１４からＩＰアドレスを得る。ＨｅＮＢ１２３は、ＤＨＣＰ（ダイナミック・ホスト・コンフィグレーション・プロトコル：Dynamic Host Configuration Protocol）メッセージを中継することによってＰＧＷ１３３のプロキシＤＨＣＰエージェントとし動作し、ホームネットワーク１１４からメッセージも中継する。ＨｅＮＢ１２３はＤＨＣＰアック（DHCP Ack）メッセージ２３６のyiaddrとchaddrのフィールドを記録する。chaddrはＩＰアドレスを要求するクライアント（ＵＥ１０１）のＭＡＣアドレスを有し、yiaddrはクライアントへ割り当てられるＩＰアドレスを有する。

ＨｅＮＢ１２３はＰＧＷ１３３へ送られるそれぞれのDHCP Ackのchaddrとyiaddrのペアを格納する。ＨｅＮＢ１２３は格納されたyiaddrに相当するＩＰアドレスあてにメッセージを転送する。yiaddrエントリに相当するメッセージは経路１５３を介してＰＧＷ１３３へ送られる。しかし、プロキシＰＧＷ機能がＨｅＮＢ１２３で作動していれば、メッセージは対応するＵＥに直接送信される。

chaddrフィールドがＵＥ１０１のＭＡＣアドレスになる必要がないことに言及する価値がある。実施可能なものとして、ＵＥ１０１のＩＭＳＩ（インターナショナル・モバイル・サブスクライバー・アイデンティティ：International Mobile Subscriber Identity）又はＭＳＩＳＤＮ（モバイル・サブスクライバー・ＩＳＤＮ・ナンバー：Mobile Subscriber ISDN (Integrated Services Digital Network) number）を使用したものをchaddrフィールドに含めるものがある。

主要な基準は、ＵＥが同じＨｅＮＢ１２３からのローカルＩＰアクセスサービスを利用している限りchaddrフィールドの値を維持することである。ＧＵＴＩ（グローバリー・ユニーク・テンポラリー・アイデンティティ：Globally Unique Temporary Identity）又はＴＭＳＩ（テンポラリー・モバイル・サブスクライバー・アイデンティティ：Temporary Mobile Subscriber identity）のような値は、ＵＥのサービングＭＭＥに依存し、サービングＭＭＥが変わるとローカルＩＰアクセスサービスを実施してる間であっても値が変わり得るため採用できない。

本発明の実施において、ＤＨＣＰｖ６を利用することも可能である。そのような実施において、ＤＨＣＰｖ４メッセージの機能はＤＨＣＰｖ６の対応する機能として実施される。重要な違いはＵＥを識別するためのＤＵＩＤ（DHCPユニークID：DHCP Unique ID）の有用性と使い方である。それは上述したＵＥ ＩＤとして用いられる。

考えられる他のものはＩＡＩＤ（アイデンティティ・アソシエーション・ＩＤ：Identity Association ID）であり、それはＵＥがアドレスを得ようとするそれぞれのインタフェースに用いられる。この識別情報は、ＵＥがＤＨＣＰｖ６を用いて複数のインタフェースを形成する場合にＨｅＮＢ１２３によって記録され、トラフィックフローを識別するために用いられる。

アドレス割り当て手続のバリエーションとして、ＮＡＴ（ネットワーク・アドレス・トランスファー：Network Address Translator）サーバ機能をＰＧＷ１３３かつ／又はＨｅＮＢ１２３が付加的に実行することが可能である。この場合、ＨｅＮＢ１２３は送信元アドレスをホームネットワーク１１４内の関連するＩＰアドレスに変換する。あて先アドレスも同様に、ＨｅＮＢ１２３は、ＬＴＥで割り当てられたUEのＩＰアドレスにあて先アドレスを変える。ある実施例においては、ＰＧＷ１３３はＵＥが３ＧＰＰ ＥＰＣサービスで与えられたＩＰアドレス（若しくはプレフィクス）を再利用する。

これは、ＰＧＷ１３３がＬＩＡサービスを提供することに加え、３ＧＰＰ ＥＰＣサービスのＰＧＷであるシナリオに特に関連する。そのような場合、ＰＧＷ１３３は、３ＧＰＰサービスとLIAで用いるＩＰアドレスを一つだけＵＥに割り当てることができる。この実施例において、ＮＡＴ機能は、正常に動作するために上述した発明のＨｅＮＢ１２３、ＰＧＷ１３３又は両方に配置することができる。

ＨｅＮＢ１２３がＮＡＴ機能を実装する場合、ＨｅＮＢ１２３はフィルタリングを行うためにＰＧＷ１３３がＵＥに割り当てたＩＰアドレスを記憶し、ＵＥ ＩＤをそのＩＰアドレスをとすることによってＨｅＮＢ１２３はプロキシＰＧＷ機能を正しく見つけ、動作させることができる。

第２の実施例においては、ＰＧＷ１３３はＮＡＴ機能を有し、ＵＥのＩＰアドレスを隠蔽する。その代わり、ホームネットワーク１１４と通信するときにはＰＧＷ１３３自身のＩＰアドレスを用いる。この場合、ＨｅＮＢ１２３は上述した解法で述べられたようにふるまうことができ（ＤＨＣＰプロキシ）、ＰＧＷ１３３がホームネットワーク１１４で付与されるＩＰアドレスを取得することができる。ＰＧＷ１３３は、ホームネットワーク１１４からのＬＩＡサービスを利用するそれぞれのＵＥのＩＤを、経路１５３を介してＨｅＮＢ１２３に知らせなければならない。

この場合に用いられるＵＥ ＩＤの一例はＵＥのＩＰアドレスであり、ＩＤはＴＣＰ（トランスミッション・コントロール・プロトコル：Transmission Control Protocol）ポート番号又は他の識別情報になり、ＰＧＷ１３３がＵＥのトラフィックを区別するために用いる。ＨｅＮＢ１２３は、ＵＥのＩＰアドレス、ＴＣＰポート番号、ＰＧＷ１３３のホームドメインアドレス間のマッピングを格納する。ＵＥがローカルＬＩＡサービスのためＨｅＮＢ１２３に移動すると、ＨｅＮＢ１２３はそのＵＥに対して特別のＮＡＴサービスを作動させる。

ＨｅＮＢ１２３は、ＰＧＷ１３３のホームドメインＩＰアドレスと特定のＩＤとして与えられる識別情報に合致するホームネットワーク１１４から受信したパケットを、あて先アドレスをＵＥのＩＰアドレスに変換することによって転送する。ＵＥからホームネットワーク１１４へのトラフィックは、特定のＩＤとして与えられる前記識別情報にもとづいてＰＧＷ１３３のホームドメインアドレスに変換される。これにより、ＨｅＮＢ１２３はプロキシＰＧＷ機能をうまく作動させることが可能となる。

第３の実施例においては、ＨｅＮＢ１２３とＰＧＷ１３３の両方がＮＡＴ機能を有している場合である。この場合、ＰＧＷ１３３はホームネットワーク１１４のドメインのＩＰアドレスを得る必要はないが、ホームネットワーク１１４からＬＩＡサービスを利用するそれぞれのＵＥのＵＥ ＩＤを、経路１５３を介してＨｅＮＢ１２３に通知しなければならない。これにより、ＨｅＮＢ１２３はプロキシＰＧＷ機能をうまく使いこなすことが可能となる。

ＩＰｖ６では、プレフィックス割り当て処理を用いたステートレスアドレス自動形成が可能であり、その際は、ＤＨＣＰ（バージョン６）の代わりにルーター・ソリシテーション（Router Solicitation）メッセージとルーター・アドバタイズメント（Router Advertisement）メッセージを用いる。しかし、解法は実質上同じ方法で行うことができ、記述されたものが直接適用される。

１つ異なるのは、ＵＥ ＩＤの選択がＰＧＷ１３３によって送信されるRouter SolicitationメッセージのＩＰヘッダ内の送信元アドレスになることである。ＨｅＮＢ１２３は、アドレスプレフィックスを提供し続け、ＵＥのＩＰｖ６アドレスを生成するためにＵＥのインタフェース識別情報を記憶する。

ＤＨＣＰ手続の完了に基づいて、ＰＧＷ１３３はデフォルトベアラ生成応答（Create Default Bearer Response）２４０を生成しＳＧＷ１３２に送信する。Create Default Bearer Response２４０は、ＨｅＮＢトークンとＵＥ ＩＤ（ＤＨＣＰ手続の間にchaddrに用いられたもので、例えばＵＥ１０１のＭＡＣアドレス）の２つの新たな情報を含む。ＳＧＷ１３２は、ＭＭＥ１３１へCreate Default Bearer Response２４５を転送する。

Create Default Bearer Response２４５を受信すると、ＭＭＥ１３１はＨｅＮＢトークンとＵＥ ＩＤとをＥＰＳベアラＩＤのもとにＵＥコンテキスト内に格納する。ベアラ確立要求（Bearer Setup Request）２５０を送信する前に、ＭＭＥ１３１はＵＥが接続するセル（例えば、ＣＳＧセル）がローカルＩＰアクセスサービスを提供するものであるかをチェックする。

ｅＮＢ１２１がＣＳＧセルでないため、ＭＭＥ１３１はBearer Setup Requestメッセージを生成するが、先の２つの新たな情報は含めない。他の実施例においては、新たな情報をメッセージに含めるが、それらの情報は受信ノードによって理解されない場合には無視させることも可能である。

ＨｅＮＢトークンとＵＥ ＩＤの情報を送信するために、Ｓ１−ＡＰコンテキストトランスファーやＳＡＥ（システム・アーキテクチャー・エボリューション：System Architecture Evolution）ベアラ管理メッセージ（例えば、確立、修正、開放など）などがBearer Setup Request２５０の代わりに用いられてもよい。

別の動作として、ＵＥ１０２がリモートでホームネットワーク１１４にローカルＩＰアクセスを行う場合が述べられている。重要な違いは、ＰＤＮ接続手続が完了した（図３の３３５）後（外部のＰＤＮアドレス割り当て）、ＤＨＣＰ手続が起こることである。ステップ３００、３０５、３１０はステップ２００、２０５、２１０に相当するため、ここでは説明を省略する。

デフォルトベアラ生成要求（Create Default Bearer Request）３１０を受信した後、ＰＧＷ１３３は、ＨｅＮＢトークンに関連するＨｅＮＢ１２３との間に既にトンネルが存在しているかチェックし検出する。しかし、この場合、ＰＧＷ１３３はＤＨＣＰ手続を開始せず、デフォルトベアラ生成応答（Create Default Bearer Response）３１５によりＨｅＮＢトークンのみを送信する。ＭＭＥ１３１は、この時点でＵＥコンテキスト内にこのＥＰＳベアラＩＤのもとにＨｅＮＢトークンを格納する処理だけ行う。

ＭＭＥ１３１は、ＵＥがＣＳＧセルに接続しているかチェックし、ここでは正判定を得る（ＨｅＮＢ１２２がＣＳＧセルであるため）。ＭＭＥ１３１は、ＨｅＮＢ１２２へのBearer Setup Requestメッセージ３２５内に、新たな情報としてＨｅＮＢトークンを付加する。ＨｅＮＢトークンを送信するために、Ｓ１−ＡＰコンテキストトランスファーやＳＡＥベアラ管理メッセージ（確立、修正、開放など）などがベアラ構築要求（Bearer Setup Request）３２５の代わりに用いられてもよい。

ＨｅＮＢ１２２はトークンをチェックし、そのトークンが自身に属しないとわかる。この時点でＨｅＮＢ１２２は、ローカルＩＰアクセスがリモートで行われていることをＲＲＣ接続再構成（RRC Connection Reconfiguration）メッセージ３３０を用いてＵＥ１０２にオプションとして通知する。これにより、ＵＥはトラフィックやアプリケーションを最適に設定することができる。例えば、ＵＥ１０２はアプリケーションのタイムアウトを緩やかにしたり、コーデックパラメータを調整したりすることを決定することができる。

ＰＤＮ接続手続が完了した（３３５）後、ＵＥ１０２はＰＧＷ１３３へ向けてＤＨＣＰ手続を開始する。ＰＧＷ１３３は、ＤＨＣＰ発見（DHCP Discovery）メッセージ３４０を受信すると、ホームネットワークク１１４へ向けてＤＨＣＰ手続を開始する。ＤＨＣＰ手続のためのステップは図２に示すものと同様であり、ここでは説明を省略する。

唯一の違いは、ＰＧＷ１３３が、ＵＥ１０２がＩＰアドレスを取得しているＤＨＣＰサーバに見えると同時に、ホームネットワーク１１４のＤＨＣＰサーバの視点からするとＰＧＷ１３３がＤＨＣＰクライアントに見えることである。DHCP Ack３５１がＵＥ１０２に送信された後、ＰＧＷ１３３は、新たに得られたＵＥ ＩＤによりＭＭＥ１３１内のＵＥコンテキストを更新するためにＰＤＮ ＧＷ 主導ベアラ修正（PDN GW Initiated Bearer Modification）を開始する。これはベアラ更新要求（Update Bearer Request）３５５内にＵＥ ＩＤを入れて送信することによって行われる。

ＭＭＥ１３１は、ダウンリンクＮＡＳトランスポート（Downlink NAS (Non Access Stratum) Transport）メッセージ３６５を用いてベアラのＵＥ ＩＤをＨｅＮＢ１２２へ通知する。しかし、ＨｅＮＢ１２２はＨｅＮＢトークンのオーナーではないため、更なる行動を起こさない。

図４において、ＵＥ１０３は、ホームネットワーク１１４にローカルＩＰアクセスを行うことを決定する。ステップ４００から４２５は上述したものと同様であるため説明を省略する。ＨｅＮＢ１２３は、ベアラ構築要求（Bearer Setup Request）４２５を受信し、その中のＨｅＮＢトークンをチェックすると、ＵＥ１０３の現在のベアラがホームネットワーク１１４へローカルＩＰアクセスを行うために利用されているとわかる。

ＨｅＮＢ１２３は、このベアラにおけるプロキシＰＧＷ機能を作動させ、このベアラ上のＵＥ１０３からのパケットの取得を開始し、パケットをホームネットワーク１１４へ直接転送する。ＵＥ１０３によって開始されるＤＨＣＰ手続は、ＥＰＣネットワークを介さず、ホームネットワーク１１４と直接やりとりされる。ＤＨＣＰ手続の最後に、ＨｅＮＢ１２３は、得られたＵＥ１０３のＩＰアドレスにより更新させるためにＰＧＷ１３３へプロキシ更新（Proxy Update）４５０を送信する。

ＰＧＷ１３３が用いるＵＥ ＩＤの値をメッセージに含め、ＭＭＥ１３１に格納させてもよい（ステップ４５５、４６０）。しかし、ＨｅＮＢ１２３はＤＨＣＰ処理の間で得られた情報（ＵＥ１０３のＩＰアドレス）に基づいて、ホームネットワーク１１４から来るどのトラフィックがＵＥ１０３へ直接送信されるものであるかが既にわかっているので、実質的にこの処理は必須ではない。

ＵＥ１０３がＨｅＮＢ１２２へ向けて移動することにより、ＨｅＮＢ１２３からＨｅＮＢ１２２へのハンドオーバが起こる場合の扱いについて以下に示す。図５に示すように、ＨｅＮＢ１２３は、まずＭＭＥ１３１へハンドオーバ要望（Handover Required）メッセージ５００を送信する。ＭＭＥ１３１はＨｅＮＢ１２２上のターゲットセルがＣＳＧセルであると検出すると、ＨｅＮＢ１２２に送信されるハンドオーバ要求（Handover Request）メッセージ５０５内に、ＨｅＮＢトークンと、関連するＥＰＳベアラのＵＥ ＩＤとを挿入する。

ＨｅＮＢ１２２はＨｅＮＢトークンのオーナーでなく、特に何もする必要はない。ＨｅＮＢ１２２は、ハンドオーバ要求が受理される場合、ハンドオーバ要求アック（Handover Request Ack）メッセージ５１０によりＭＭＥ１３１に応答する。Handover Request Ack５１０の受信を受けて、ＭＭＥ１３１はＨｅＮＢ１２３へハンドオーバコマンド（Handover Command）５１５を送信する。

ＭＭＥ１３１は、ＨｅＮＢ１２３がＣＳＧノードであると検出するため、ＭＭＥ１３１は関連するＥＰＳベアラに対するＨｅＮＢトークンとＵＥ ＩＤをメッセージ内に挿入する。ＨｅＮＢ１２３は、メッセージ内に自身のＨｅＮＢトークンがあるとわかるため、ＵＥ１０３がＨｅＮＢ１２３から切断された時に、ＵＥ１０３に関連するトラフィックをＰＧＷ１３３へ転送し始める。あるいは、ＭＭＥ１３１は、Handover Commandメッセージ５１５内において新たな情報のチェックと送信を省くことができ、その代わり、ＵＥ１０３がハンドオーバの準備をしているときに、ＨｅＮＢ１２３による推論に頼ってもよい。

図６では、ＵＥ１０２がＨｅＮＢ１２２からＨｅＮＢ１２３へ移動するシナリオが示されている。図６に示すように、ＨｅＮＢ１２２は、ハンドオーバターゲットとしてＨｅＮＢ１２３を明示して、ＭＭＥ１３１へハンドオーバ要望（Handover Required）メッセージ６００を送信する。ＭＭＥ１３１はＨｅＮＢ１２２がＣＳＧノードであり、ＨｅＮＢ１２３へ送信されるハンドオーバ要求（Handover Request）メッセージ６０５内に、ＨｅＮＢトークンと関連するＥＰＳベアラのＵＥ ＩＤとが含まれることを検出する。

ＨｅＮＢ１２３は、ＨｅＮＢトークンのオーナーであると認識し、ＵＥ１０２のＩＰアドレス（yiaddr）を得るためにＵＥ ＩＤ（chaddr）とマッチングする。ＵＥ１０２がハンドオーバし、ＨｅＮＢ１２３に接続した後、ＨｅＮＢ１２３は、ＰＧＷ１３３に経路１５３を介してトラフィックを送信する代わりにホームネットワーク１１４からＵＥ１０２にトラフィックを直接転送するためにプロキシＰＧＷ機能を起動する。

本発明の動作に必要とされるＨｅＮＢ１２３内の新たな機能が図７に示されている。プロキシＰＧＷ機能部７００は、非特許文献２に規定されるＰＧＷ機能を果たす。プロキシＰＧＷ機能部７００は、主にユーザプレーンデータに関するものであり、セキュリティ鍵管理、レート制御、受信したパケットの操作と処理を行うものである。プロキシＰＧＷ機能部７００は、さらに３つの主要な部門から構成されており、それはインターセプトフィルタ部７０５、ＵＥ ＩＤマッピング部７１０、トンネル管理部７１５である。

インターセプトフィルタ部７０５は２つまたである。ホームネットワーク１１４側では、それぞれのＵＥに転送されるアドレスリストを管理する。ＣＳＧセル１１３側では、プロキシＰＧＷ機能部が動作し、ＥＰＣ（進化型パケットコア：Evolved Packet Core）内ではなく直接ホームネットワーク１１４へユーザプレーンパケットを向け直すために、関連するベアラを監視する。

ＵＥ ＩＤマッピング部７１０は、インターセプトフィルタ部７０５のホームネットワーク１１４側でのエントリにＵＥ ＩＤをマッピングするため、インターセプトフィルタ部７０５のデータベースを共有する。これは、プロキシＰＧＷ機能部７００からの要求に対する応答として提供される。インターセプトフィルタ部７０５データベース内のフィルタリストエントリの転送ターゲットを修正することも可能である。

トンネル管理部７１５は、それぞれのトンネルに対するトークンと鍵を管理する。また、トンネル管理部７１５は、ＨｅＮＢ１２３がＥＰＣ内の、ローカルＩＰアクセスサービスを提供する１つ以上のＰＧＷに接続する場合も管理する。

ＨｅＮＢ１２３の動作が図８のフローチャートに示されている。このフローチャートでは、ＨｅＮＢ１２３がＰＧＷ１３３と通信チャンネルを確立すると仮定している。いずれにせよ、ＨｅＮＢ１２３は、通信チャンネルがＰＧＷとの間で利用可能なときにプロキシＰＧＷ機能を起動させると仮定する。

そのような通信チャンネルが存在しない場合（例えば、トンネルがアドホックベースで確立されている）、ＨｅＮＢ１２３はプロキシＰＧＷ機能を動作させる必要はない（ＥＰＣ１１５とホームドメイン１１４との間でトラフィックを確認したり転送したりする）。ＨｅＮＢ１２３は、まずＰＧＷ１３３と通信チャンネルを確立する（ステップ８０５）。ここではＩＰトンネル確立の形式をとるが、他の形式や方法でも適用できる。この通信チャンネル確立のタイミングは、静的に（例えば、ＨｅＮＢの起動に基づくもの）、又は要求がされてから（ＵＥの要求による動的なもの）であってもよい。

ＰＧＷ１３３との通信チャンネルが確立されると、ＨｅＮＢ１２３は、この通信チャンネルの唯一のトークンを生成し、それをＰＧＷ１３３に送信する（ステップ８１０）。その後、ＨｅＮＢ１２３はプロキシＰＧＷモードになり、ＭＭＥ１３１だけでなく、ＰＧＷ１３３からの入力も動的に確認する。ＭＭＥ１３１からのメッセージの場合には、ＨｅＮＢ１２３はベアラ確立メッセージだけでなく、ハンドオーバメッセージにも特別な注意を払う。

ＨｅＮＢ１２３がＰＧＷ１３３によって開始されるＤＨＣＰ手続を検出する（ステップ８１１）、又はアドレス割り当て手続の形式を検出する場合、ＨｅＮＢ１２３はそのような手続の結果を監視し、記録し続ける。特に、ＨｅＮＢ１２３はＵＥ−specific identity（ＵＥ ＩＤ）だけでなく、割り当てられたＩＰアドレスを記録する（ステップ８１５）。

割り当てられたＩＰアドレスは、ホームネットワーク１１４からのパケットがＰＧＷ１３３へ転送されるべきか決定するためにフィルタリストで用いられる。例えば、フィルタエントリコードは以下のようなものである。フィルタリストエントリ＝［あて先ＩＰ］、［ＵＥ ＩＤ］、［次のホップ］、［付加的なＩＤ］。あて先ＩＰのフィールドはＨｅＮＢ１２３が３Ｇネットワークへ転送するためのＩＰアドレスを含む。

［ＵＥ ＩＤ］はＵＥ−specific identifierを含み、それはパケットを送信すべきＵＥを決定する際に探すものである。［次のホップ］のフィールドは、ＰＧＷ１３３へパケットを転送するかローカルにアタッチするＵＥにパケットを送信するかをＨｅＮＢ１２３に示すものである。［付加的なＩＤ］のフィールドは、ＰＧＷ１３３がＮＡＴ機能を実施しているときなど、１つのＵＥ ＩＤがＵＥを識別するのに十分でないときに用いられるものである。

ＨｅＮＢ１２３は、ＭＭＥ１３１によって送信されるＳ１−ＡＰメッセージに含まれるＨｅＮＢトークン（ステップ８２５）とＵＥ ＩＤ（ステップ８４０）とを探す。メッセージがＵＥ ＩＤを伴わずにＨｅＮＢトークンのみを含むことは可能であるが、その逆（ＨｅＮＢトークンがなく、ＵＥ ＩＤのみがある）はエラー状態となる。

メッセージがＨｅＮＢトークンを含むが、そのトークンがＨｅＮＢ１２３に属さない場合、ＨｅＮＢは、ローカルＩＰアクセスの状態をＵＥに知らせるオプション、例えばＵＥがリモート位置からローカルＩＰアクセスを行っていることを知らせるオプションのステップをとる（ステップ８３０）。なお、このステップの実施は個々の実施者に託される。

ＨｅＮＢ１２３に属するＨｅＮＢトークンがＭＭＥ１３１からのメッセージで見つかった場合、ＨｅＮＢ１２３は、あるベアラ（ＭＭＥメッセージのコンテキストから推測されるか、明らかに明言された）でのＵＥによって送信されるパケットをインターセプトし始め（ステップ８３５）、ホームネットワーク１１４に向けてＵＥのプロキシＰＧＷとして動作する。

ＵＥ ＩＤが同じメッセージに存在する場合、ＨｅＮＢ１２３は、ＭＭＥ１３１からのメッセージに存在するＵＥ ＩＤにマッチする［ＵＥ ＩＤ］フィールドを見つけるためにフィルタリストエントリを探す。見つかると、ＨｅＮＢ１２３は、ホームネットワーク１１４からのパケットがＰＧＷ１３３に転送される代わりに直接ＵＥに送信されるようエントリの［次のホップ］フィールドを変える（ステップ８５０）。

ＵＥ ＩＤが検出されない場合、ＨｅＮＢ１２３は、オプション的に、ＵＥによって開始されるアドレス割り当て手続（DHCP Discoveryのようなもの）を確認し、インターセプトする。この形態が実施されるかは実施の場面に託される。この場合、ＨｅＮＢ１２３は、アドレス割り当て手続の結果（例えば、割り当てられたＩＰアドレス）のみをＰＧＷ１３３に通知する必要があり、ＵＥ ＩＤの使用はオプションである。

＜第２の実施の形態＞
第２の実施の形態では、ＰＧＷ１３３とＨｅＮＢ１２３との間で通信チャンネル又はトンネルが１つではなく、複数存在する。このシナリオにおいて、ホームネットワーク１１４へローカルＩＰアクセスを利用したいというＵＥの要求によりトンネルが確立され、ＨｅＮＢ１２３はトンネルごとに唯一のＨｅＮＢトークンを発行する。ＵＥ ＩＤを必要とせず、ＵＥ ＩＤを伴う上述の手続を省略することができる。

これは、ＨｅＮＢ１２３が、ＨｅＮＢトークンに基づいてホームネットワーク１１４からのトラフィックのフローを正確に識別することができ、制御メッセージ（例えば、ハンドオーバ要求、ベアラ確立要求など）内のＨｅＮＢトークンポジションに基づいてＵＥの正確なベアラを識別することができるためである。このシナリオは、図８のフローチャートに示すようなＨｅＮＢ１２３の動作例のようになる。

＜第３の実施の形態＞
第３の実施の形態では、ＨｅＮＢ１２３はＰＧＷ機能を含まないが、ネットワーク設定ルータやエージェントのようなものである。トラフィック転送ポリシは、経路１５２、１５３を介してＥＰＣ１１５のＰＧＷ１３３やＭＭＥ１３１から送信される。本発明の動作は上述したものと本質的に変わっていない。

＜第４の実施の形態＞
第４の実施の形態では、ＨｅＮＢ１２３はＰＧＷの全ての機能を実装している。このシナリオでは、ＨｅＮＢ１２３はこのドキュメントで述べられたようなＰＧＷ１３３の動作を実際に行う。この場合、ストリームライン（stream-lined）アドレス割り当て手続のように、最適な動作が可能である。

ＥＰＣ１１５内に１つのＰＧＷのみがあるのか、もしくは２つのＰＧＷがあるのか、例えば１つはＥＰＣ１１５内に、他はＨｅＮＢ１２３と一緒に配置されているということは、上述した発明の動作に影響を与えるものではない。

＜第５の実施の形態＞
第５の実施の形態では、ＰＧＷ機能は、ＥＰＣ１１５にＨｅＮＢ１２３を接続するゲートウェイに配置することができる。例えば、ＰＧＷ１３３はＨｅＮＢゲートウェイ、もしくはセキュリティゲートウェイ上に配置することができる。この場合、ＭＭＥはローカルＩＰアクセスのためにＰＧＷを割り当てる静的な情報を簡単に用いることができる。

＜第６の実施の形態＞
第６の実施の形態では、ＰＧＷ１３３が、ＥＰＣサービスと、デバイスやインターネットへのローカルＩＰアクセスとの両方を提供する。そのような実施の形態において、ＥＰＣサービスとローカルＩＰアクセスにおけるＰＤＮ接続が同じであることは起こり得る。この場合、ＵＥ１０３は、同じＰＧＷからのローカルＩＰアクセスサービスの要求のために、イニシャルアタッチ（initial Attach）又はサービス要求（Service Request）の３ＧＰＰ手続を代わりに利用することができる。

この実施の形態では、ＰＧＷの特性により、ＵＥ１０３がＥＰＣサービスのために割り当てられたＩＰアドレスをローカルＩＰアクセスに再利用することは可能である。そのようなシナリオにおいて、ＵＥ１０３はホームネットワーク１１４のトラフィックと同様、ＥＰＣ１１５のトラフィックにおいて同じＥＰＳベアラを同じように利用する。そのため、ＨｅＮＢ１２３は、ＳＧＷ１３２にパケットを転送するかホームネットワーク１１４に直接パケットを転送するか決定する際に、ホームネットワークＩＰドメインに対するあて先アドレス比較を行う。

ＭＭＥ１３１は、各ＵＥについてローカルＩＰアクセスサービスが許可されるべきかＨｅＮＢ１２３へ通知するが、これはベアラ確立若しくは修正手続の間に簡単なフラグの形式をとることによって行われる。これは、ＨｅＮＢがハイブリッドモードで運用され、ＵＥごとに異なるアクセスレベルが提供されているような場合に特に役立つ。例えば、ＨｅＮＢ１２３は、ＵＥ１０３がＨｅＮＢ１２３のメンバーであれば直接ホームネットワーク１１４とＵＥ１０３との間でトラフィックを転送し、ＵＥ１０３がＨｅＮＢ１２３のメンバーでなければＳＧＷ１３２にすべてのトラフィックを転送する。これは、メンバーと非メンバーとの間で区別されたアカウンティングと課金構造によるものであったり、他のアクセス権利に関する事項によるものであったりする。

＜第７の実施の形態＞
第７の実施の形態において、ＥＰＣサービスを提供するＰＧＷ１３４は、ＵＥがデバイスやインターネットへのローカルＩＰアクセスを行う際に利用される。この実施の形態において、ＥＰＣサービスとローカルＩＰアクセスにおけるＰＤＮ接続を同じものとすることができる。そのような場合、ＨｅＮＢは、ＵＥからのＩＰパケットのあて先ＩＰアドレスを見ることによって、ローカルＩＰあて先にＵプレーントラフィックの経路最適化を行うことができる。

ＵＥがＥＰＣサービスのために割り当てられた同じＩＰアドレスをローカルＩＰアクセスに利用するため、ＨｅＮＢは、ホームドメインへのパケットとホームドメインからのパケットがうまく送受信されるためにＮＡＴ機能を働かせる。インターネットへのローカルＩＰアクセスが利用できる、又はＥＰＣサービスとホームドメインとの間でオーバーラップするアドレススペースがあるときのシナリオにおいて、Ｕプレーンパケットを正確に転送するためにオペレータネットワークによってＰＤＰかＴＦＴ（フィルタルール）のどちらかでＨｅＮＢを設定することができる。

しかし、ＵＥが属するオペレータが、ＨｅＮＢのオペレータとローミング契約を有していない場合（図９参照）、外部のオペレータに属するＰＧＷ９１０にパケットを正確に転送するためにＨｅＮＢがどのように設定され得るかという問題が生じる。第一に、ＨｅＮＢ９２０が転送で用いるフィルタをインストールするために用いられるＨｅＮＢとＰＧＷ９１０間の直接インタフェースが存在しない。第二に、ホームオペレータは、ホームオペレータに属するデバイスが外部のオペレータによって直接制御されることを受け入れないかもしれない。第三に、外部オペレータ９００は、ホームオペレータにＩＰサービスの内部作業を不必要にさらすフィルタをインストールすることを望まないかもしれない。

そのような場合において、上述した発明は、Ｕプレーンのあて先を正確に切り替えることを目的として、ＰＧＷ９１０がＨｅＮＢ９２０にルール又はポリシを伝達するために用いられる。本発明によれば、ＨｅＮＢ９２０は、ＰＧＷ９１０へＵプレーン上で特別なメッセージを送信することを誘発（トリガ）される。このトリガはポリシに依存し、一例としては、ＵＥ１０３がアクティブモードになったときや、ＵＥがＵプレーントラフィックを開始したとき、ホームネットワーク１１４に属するあて先ＩＰアドレスを検出したとき、ＵＥ１０３のローミング特性や必要な手続がＥＰＣからＨｅＮＢ９２０に通知されたときなどがある。

ＰＧＷ９１０に送信される特別なメッセージは、ＰＧＷ９１０とホームネットワーク１１４にＵプレーンパケットを転送するときにＨｅＮＢ９２０が正確な動作をするためのパラメータの伝達をＰＧＷ９１０に開始させるものである。特別なメッセージはＰＧＷ９１０によって認識され、そのメッセージは、例えば特別な送信元アドレス（ＩＰｖ４における０．０．０．０や、ＩＰｖ６における０：：０など空のアドレス）を有する明らかに作られたＩＰアドレスの形式をとり、ＨｅＮＢ自身とＵＥとを認識させ、識別させるためのパラメータを含む。一例として、ＨｅＮＢ９２０のＥＣＧＩ、ＵＥのＥＰＳベアラＩＤ又はＵＥのローカル識別子を含む。

これは上述したＨｅＮＢトークンに相当する。ＰＧＷ９１０は、受信されるメッセージのベアラに基づいてＵＥを識別することができ、受信されるメッセージに基づいてＨｅＮＢを識別することができる。

ＰＧＷ９１０は、ＩＰサービスの継続動作のため、外部のオペレータネットワークから取得したルール、ポリシ、又はフィルタを用いて必要な例外でＨｅＮＢ９２０を更新することができる。この通信は、ＨｅＮＢ９２０へ到達するため、経路９１１（例えば、３ＧＰＰ Ｓ８インタフェース）、１５８（例えば、３ＧＰＰ Ｓ１１ インタフェース）を介する経路をとり、経路１５２（例えば、３ＧＰＰ Ｓ１−ＡＰインタフェース）を通る。そのような通信の一例は、３ＧＰＰ修正ＥＰＳベアラコンテキスト手続になり得る。

修正ＥＰＳベアラコンテキスト要求（Modify EPS Bearer Context Request）メッセージの中に、ＰＧＷ９１０は、ＨｅＮＢ９２０が従うべきポリシルール（ＩＰアドレスのリストなど）を含める。例えば、経路１５３（例えば、３ＧＰＰ Ｓ１−Ｕインタフェース）経由でＰＧＷに対象とするあて先アドレスを転送するといったポリシルールなどである。ＭＭＥ１３１は、ＨｅＮＢ９２０に中継する前に、あるＩＰアドレスを付加するか削除するかなど、転送するＩＰアドレスのリストを修正するなどして、経路１５８を介して受信する外部オペレータ９００のポリシでメッセージを処理することができる。外部オペレータポリシの修正は、内部ポリシによったり、オペレータ間でのローミング契約に従ったりする。

外部オペレータ９００のルール又はポリシを含むメッセージを受信すると、ＨｅＮＢ９２０は、ルールを適用する関連のＵＥをメッセージを受信したベアラにもとづいて識別することができる。ＨｅＮＢ９２０は、例えば、ＰＧＷ９１０に送信すべきあて先ＩＰアドレスのリストとパケットのあて先ＩＰアドレスとを比較することによって、ＳＧＷ９１５とホームネットワーク１１４の間でＵプレーンパケットを正しくスイッチングさせることができる。

図１０は、主要なブロックにより構成されたＨｅＮＢ９２０の構成図の一例である。プロキシＰＧＷ機能部７００は、大きくは変わらず、ユーザプレーンデータに関するものであり、受信したパケットの操作及び処理をする。プロキシＰＧＷ機能部７００は、３つの主な部門、インターセプトフィルタ部７０５、ＵＥ ＩＤマッピング部７１０、トンネル管理部７１５から構成される。これらは上述した同じ役目を果たすため、説明を省略する。

ＨｅＮＢ９２０は、さらに、ベアラ管理部１０００、ルータ機能部１００５、ＮＡＴ１０１０のそれぞれを有している。ベアラ管理部１０００は、３ＧＰＰ プロトコルスタックの部門であるが、経路１００１を介してルータ機能部１００５に、受信したベアラ確立や修正メッセージからのパラメータを伝える。

ルータ機能部１００５は、受信したパケットの次のホップ（ホームネットワーク１１４又はＳＧＷ１３１）を決定し、ベアラ管理部１０００から得られる情報に加えて、ポリシ、ルール、フィルタに相当するルーティングテーブルを更新するためにプロキシＰＧＷ機能部７００と相互に作用しあう（経路１００６を介して）。ＮＡＴ１０１０は、ＵＥのＩＰアドレスがホームネットワーク内で利用できない場合に必要とされ、シームレスオペレーションにおけるネットワークアドレス変換に必要である。

＜第８の実施の形態＞
第８の実施の形態において、ＨｅＮＢ９２０は、ＵＥから受信したすべてのパケットをＰＧＷ９１０にまず転送する。ＰＧＷ９１０は、あるパケットがローカルＩＰアクセスあてであると検出する。ＰＧＷ９１０は、様々な方法でこの検出を行うことができる。アドレスが、実際には家庭内ネットワーク又はインターネットへのローカルＩＰサービスにアクセスするものであると気づくように、ルーティングテーブルやポリシルール機能に情報を含める。

例えば、ＵＥがプライベートＩＰアドレス（ＩＰｖ４）又はリンクローカルやサイトローカル（ＩＰｖ６）アドレスにアクセスしようとしているか。あて先アドレスに関して、従来のＧｘインタフェースを通じて、ＰＣＲＦ（ポリシー・コントロール・アンド・チャージング・ルール・ファンクション：Policy Control and Charging Rules Function）のような関連するＰＣＣ（ポリシ・アンド・チャージング・コントロール：Policy and Charging Control）エンティティに問い合わせることは可能である。あるいは、ＰＧＷ９１０がＳＧｉインタフェースを介してＩＰサービスに問い合わせる（クエリーする）ことが考えられる。また、アドレスがホームネットワーク１１４あてであることをＰＧＷ９１０が検出する方法としては、関連するあて先ノードにＵプレーンパケットを転送しようとするときに受信されるエラーメッセージ（例えば、ＩＣＭＰによるあて先に届かない、ホストがみつからないなどのメッセージ）によるものが考えられる。

ＨｅＮＢ９２０によって最適化されるべきアドレスを検出すると、ＨｅＮＢ９２０に適したフィルタルールをインストールするために、ＰＧＷ９１０は上述した方法（3GPPベアラコンテキスト修正：3GPP Bearer Context Modification）を実施する。この実装は、処理の大部分をネットワークサイドで実施でき、ＨｅＮＢを複雑にすることなく低コストに抑えることができるため、ＨｅＮＢをかなり単純に実装できるという利益をもたらす。

＜第９の実施の形態＞
第９の実施の形態では、ＨｅＮＢ９２０はＵＥからのＵプレーンパケットを検出する。ホームネットワーク１１４に属するあて先アドレスを有するパケットは、ＰＧＷ９１０に中継される前にＨｅＮＢ９２０によってマーキングされる。このマーキングは、追加のＩＰヘッダや、従来のヘッダ内に付加的なフラグを定義するなど様々な形式がとられる。

マーキングされたパケットを受信したＰＧＷ９１０は、あて先アドレスが外部のオペレータが提供するＩＰサービスのものと一致するかどうかを検出する。これは、上述した方法と似たものである。ＰＧＷ９１０は、上述したような方法でＨｅＮＢ９２０にルール、ポリシ、フィルタなどをインストールする。

＜第１０の実施の形態＞
第１０の実施の形態では、ＰＧＷ９１０を通じて提供されたＩＰサービスとホームネットワーク１１４のデバイスを通じて提供されたＩＰサービスとの間で、アドレススペースがオーバーラップすることもあり得る。そのようなシナリオにおいて、従来のＵＥ（３ＧＰＰ リリース８又はそれよりも前）にとって、とられるデフォルト決定は、常にＰＧＷ９１０にそのようなパケットを送信するかＨｅＮＢ９２０を介してローカルＩＰアクセスに送信するかである。

能力の高いターミナルの場合、ＰＧＷ９１０が、ホームネットワーク１１４におけるトラフィックとＥＰＣサービスにおけるトラフィックの区別を明らかにさせるためにデディケイティド・ベアラ・クリエーション（dedicated bearer creation）を開始する可能性がある。ＵＥがＵプレーンパケットを送信するときに用いる正しいベアラ（ＰＧＷ９１０又はホームネットワーク１１４）を決定するのに、ユーザ入力が求められたり、プロファイルや他の好みのセッティングが適用されたりする。また、ＨｅＮＢ９２０は、そのスイッチング動作を決定するために、到来するＵプレーントラフィックが送信されるベアラに依存する。

＜第１１の実施の形態＞
＜ＰＧＷからＨｅＮＢへＬＧＷトークンを通すためにＭＭＥを用いるデフォルト操作＞
他の好ましい実施の形態として、配置シナリオが図１１で述べられ、示されている。この配置では、ローカルネットワークサービス（又はローカルＩＰアクセスサービス）１１０１、１１０２へのアクセスは、ローカルアクセスゲートウェイ又はローカルゲートウェイ（ＬＧＷ）１１３０、１１３１を介しており、それらはＩＰルータ又はレイヤ２スイッチであってもよい。ローカルブレイクアウトは、ＨｅＮＢ１１２０のような選択的なノードで可能である。ｅＮｏｄｅ Ｂ、Ｎｏｄｅ Ｂ、ホームＮｏｄｅ Ｂ（Ｈｏｍｅ Ｎｏｄｅ Ｂ）のようなタイプの他のノードは、上述した解法の操作に著しい変更を与えることなく、ＨｅＮＢ１１２０の代わりになることに留意すべきである。

ＰＧＷ１１１０はＬＧＷ１１３１への経路１１５１及びＬＧＷ１１３０への経路１１５２を介したローカルアクセスゲートウェイへのインタフェースを有していることがわかる。これらのインタフェースは、３ＧＰＰ規定のもとで定義されたＰＧＷ（ＰＤＮ Ｇａｔｅｗａｙ）とＰＤＮ（Ｐａｃｋｅｔ Ｄａｔａ Ｎｅｔｗｏｒｋ）の間でＳＧｉ又はＧｉインタフェースになる。この配置に関して、経路１１５１と経路１１５２が３ＧＰＰコアネットワーク（例えば、ＥＰＣ）又はシステムの完全に外側に位置する外部経路であると仮定しているが、配置の際、それらの経路が仮想的なパスであり、ＨｅＮＢ１１２０のような近隣の３ＧＰＰエンティティを介したトンネリングによってＰＧＷ１１１０がアクセスできるようにすることが可能である。

＜ＰＧＷとＬＧＷの間でのリンク生成＞
ＬＧＷ１１３０とＬＧＷ１１３１に関する情報がＰＧＷ１１１０によって得られうる様々な実現方法がある。この情報は、あらかじめ設定されているか、ユーザのサブスクリプションのもとに格納されているか、又はＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｅｒｖｉｃｅ）サーバのようなデータベースを介して動的に得られ、又はＵＥ１１４０からの要求により得られる。その情報があらかじめ設定されている場合、ＰＧＷ１１１０は、ＬＧＷによって提供されるサービスにアクセスするための要求をＬＧＷから受信した時に、その情報を見る。ＵＥが明示する方法に関しては、ＵＥはＰＧＷ１１１０に送信されるＰＣＯ内にＩＥ（Ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ）としてその情報を格納し得る。ＰＧＷ１１１０は、ＵＥがＡＰＮ（Ａｃｃｅｓｓ Ｐｏｉｎｔ Ｎａｍｅ）のようなサービス名のみを明示し、特定のサーバを明示しない場合、適当なＬＧＷのサーチと選択を行う。

この実施の形態ではＬＧＷ１１３０とＬＧＷ１１３１が手続きを実行することが述べられているが、ＬＧＷ１１３０かＬＧＷ１１３１のいずれか１つのみが行うようにしてもよい。

＜サポートされたＡＰＮ情報とともにＰＧＷへのＬＧＷ登録、トンネル構築を開始するＬＧＷ＞
ＬＧＷ１１３０、１１３１は、ＰＧＷ１１１０に対する登録を行うことをあらかじめ設定され、プログラム化されていてもよい。例えば、ＵＥへのＰＧＷ１１１０を介するローカルＩＰアクセスサービスを提供するため、ＬＧＷ１１３０、１１３１は、立ち上げ（ブートアップ）時に、ＰＧＷ１１１０に向けて又は中間のセキュリティゲートウェイを介して、認証及びトンネル構築処理を開始する。これは、例えば、ＩＰｓｅｃ（ＩＰ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）セキュリティアソシエーションの構築、トンネリングプロトコルのネゴシエーション、プロテクションのためのキーの取得などを含むことができる。トンネル構築の開始は、ＰＧＷ１１１０によって行われても、又はトリガされてもよい。ＬＧＷ１１３０、１１３１は、ＰＧＷ１１１０や中間のセキュリティゲートウェイの識別子及びアドレスを、あらかじめ格納されたコンフィグレーション、例えばコンフィグレーションファイルやＳＩＭ／ＵＳＩＭなどによって取得する。操作及びメンテナンスシステムは、そのような情報を設定するために用いられることができる。ＬＧＷ１１３０、１１３１の所有者又はオペレータが、ローカル又はリモートでユーザインタフェースを介して手動でそのような情報を設定することも可能である。

トンネル構築は、ローカルネットワークへのＵＥの接続構築より前に行われてもよく、ＵＥが関連するＰＤＮ接続の構築を開始すると同時に行われてもよい。正当な手続きで、ＬＧＷ１１３０、１１３１は、サポートされたローカルＩＰアクセスサービスをＰＧＷ１１１０に示すことができる。例えばＡＰＮを形成して、ＰＧＷ１１１０に登録することである。ＡＰＮは、ローカルＩＰアクセスのドメイン情報、サービス情報、あらかじめ設定された所有権情報を含むことによって形成される。例えば、ＬＧＷ１１３０、１１３１がローカルプリントサービスを提供するために企業アカウントによりオペレータに登録される場合、ＡＰＮは“service-printing.acc-CompanyA.mnc-xyz.mcc-lmn.3gpp.org”のように形成され得る。ＰＧＷ１１１０は、ＬＧＷからのそのようなＡＰＮ情報をシステムデータベースに格納し、ＰＧＷ選択処理の際に、３ＧＰＰシステムはＡＰＮ情報を用いてＵＥを収容するＰＧＷを正確に選択することができる。

ＬＧＷ登録処理の時に構築されるトンネルがある場合、複数又はすべてのＵＥによって共有されてもよい。ＰＧＷとＬＧＷによって収容される新たなＵＥがある場合、選択的に、ＰＧＷとＬＧＷは、例えばチャイルドセキュリティアソシエーションをフォーキングするなど、新たなトンネルを構築することができる。これは、以下で述べられるように、ＰＧＷ起動トンネル構築処理を実行することによって達成され得る。

＜ＰＧＷからのＵＥ特定接続構築処理＞
ＵＥ１１４０は、ＰＧＷ１１１０に要求を送信することによってローカルＩＰアクセスサービスの要求をする。１つの実装の形態として、ＵＥ１１４０がすでに３Ｇサービスの少なくとも１つのＰＤＮ接続を有し、ＵＥ１１４０はコアネットワークを越えてＰＤＮに接続している、又はＵＥ１１４０が他のローカルＩＰアクセスサービスを有しており、それゆえに、ＵＥ１１４０はこのサービスの要求のためにUE Requested PDN接続手続きを利用すると仮定する。ＵＥ１１４０がデフォルトのＰＤＮ接続の構築と一緒にローカルＩＰアクセスサービスを要求する、例えば、ＵＥ１１４０がローカルアクセスサービスをサポートするセル内でアタッチ手続きを開始することも可能である。この場合、ＵＥ１１４０は、ネットワークに送信するアタッチ要求メッセージに必要な情報を含める。この場合、ネットワークは、ローカルＩＰアクセスサービスのための付加的なＰＤＮ接続の構築を開始する。以前に述べた手続きと同様に、ＭＭＥ１１１２は、必要であればＵＥ１１４０のための関連セキュリティチェックをし、ＵＥ１１４０がローカルＩＰアクセスサービスに許可されるかどうかを決定するためにアクセス制御を実行する。ＵＥ１１４０が要求されたサービスに必要な権利を有していると仮定すると、ＭＭＥ１１１２は、Create Default Bearer RequestをＳＧＷ１１１１に送信し、ＳＧＷ１１１１はＰＧＷ１１１０へCreate Default Bearer Requestを中継する。

ＰＧＷ１１１０は、ＰＣＯからＩＥを回収し、関連するＬＧＷ１１３０の（ＩＰ）アドレスを得るためにそれを分析する。他に、ＰＧＷ１１１０は、ＡＰＮ／ＡＰＮｓを要求したＵＥをチェックすることによってＬＧＷ１１３０を決定し、登録したＬＧＷとサポートされたＡＰＮについての情報を格納してもよい。

ＰＧＷ１１１０は、既存のＬＧＷ１１３０との通信チャンネル（例えば、トンネル）があるかどうかをチェックする。チャンネルが存在しない場合、ＰＧＷ１１１０は、先の記述で概説されたように、ＬＧＷ１１３０との通信チャンネル１１５２のセットアップを続行する。この間、セキュリティキーは交換され、ＬＧＷ１１３０はＰＧＷ１１１０へローカルにＬＧＷ１１３０に関連するトークンを渡す。このトークンはＰＧＷ１１１０との通信チャンネルを識別するためにＬＧＷ１１３０によって用いられる情報を含む。

オペレータのネットワークとＬＧＷ１１３０の接続形態に応じて、ＬＧＷ１１３０は、効率よくＬＧＷ１１３０を発見するためにＨｅＮＢ１１２０によって後に用いられる適切なアドレス又は識別子（ＬＧＷ ＩＤ）を加えてもよい。オペレータがすでにＬＧＷ１１３０の十分な情報を有している、例えばＬＧＷ１１３０がすでにＰＧＷ１１１０に登録されている場合、ＰＧＷは格納されたＬＧＷの情報を介してＬＧＷのアドレス又はＬＧＷ ＩＤを得ることができる。

＜ＬＧＷとＰＧＷとの間にＮＡＴがある場合＞
図１２はＬＧＷ１２３０とＨ（ｅ）ＮＢ１２２０の両方が企業ネットワーク１２００に属する場合の配置を示している。この場合、ＬＧＷ１２３０とＰＧＷ１２４０との間にＮＡＴ（Network Address Translation）サーバ１２１０があってもよい。そのため、ＰＧＷ１２４０は、外部通信のためにＮＡＴ変換されたアドレスで、グローバル又はプライベートアドレスになり得るＬＧＷ１２３０の外部（パブリック）アドレスを知るのみである。

このアドレスは、ＮＡＴサーバ１２１０の背後にあるＨ（ｅ）ＮＢ１２２０にとって役に立たず、Ｈ（ｅ）ＮＢ１２２０は、プライベート又はグローバルアドレスになり得る内部（プライベート）アドレスからＬＧＷ１２３０を知るのみである。この場合、Ｈ（ｅ）ＮＢ１２２０が必要とするものはＬＧＷ１２３０の内部アドレスである。この場合、ＬＧＷ１２３０自身によって提供されるＬＧＷ ＩＤは、Ｈ（ｅ）ＮＢ１２２０が拒絶されることを回避し、効率よくＬＧＷ１２３０とコンタクトできるように、Ｈ（ｅ）ＮＢ１２２０がＮＡＴドメイン１２００内でＬＧＷ１２３０とコンタクトするための内部アドレスを得るのに役立つ。

＜ＳＡ識別子としてのＬＧＷ ＩＤ＞
ＰＧＷ１２４０とＬＧＷ１２３０との間で簡単なトンネル管理プロトコルのみが実装されている場合、ＬＧＷ１２３０がＰＧＷ１２４０にＬＧＷ ＩＤを運ぶための特別なメッセージがない。この場合、ＬＧＷ１２３０は、例えばＳＡ識別子のように、ＳＡ（Security Association）内にＬＧＷ ＩＤを入れて運ぶことができる。ＬＧＷ ＩＤはローカルに重要な情報を含む必要があるのみであるので、ＬＧＷ ＩＤは、例えばネットワークプレフィックス情報の代わりにホストＩＤを含むだけのように圧縮させることができる。

＜ＰＧＷへのＬＧＷ情報がＨｅＮＢに暗号化される、例えばＰＧＷへのトランスペアレント＞
ＬＧＷ１１３０がＬＧＷ１１３０のネットワークコンフィグレーションの情報をオペレータが有することを望まず、企業ネットワークのようにネットワークの背後にある場合、ＨｅＮＢ１１２０に知られるだけのセキュリティキーを用いて情報を暗号化することが可能である（そのキーはＬＧＷ１１３０とＨｅＮＢ１１２０との間で静的に又は動的に共有される）。暗号化された情報は、ＨｅＮＢ１１２０がＤＮＳのようなローカルドメイン情報サービスを問い合わせるのに用いるローカルドメインシグニフィカンス（Significance）の識別情報であってもよい。例えば、ローカル識別情報はＬＧＷの別名、ＬＧＷのレイヤ２アドレス（例えば、ＭＡＣアドレス）、又はＶＬＡＮ（Virtual Local Area Network）タグなどになる。あるいは、ＬＧＷ ＩＤは、ＨｅＮＢとＬＧＷとの間で接続、例えば特定のＩＰトンネル、レイヤ２ＶＬＡＮ、又はＧＴＰトンネルなどを構築する方法を示す情報を含んでもよい。

＜トンネル構築後、ＰＧＷがＨｅＮＢにＬＧＷトークンとＩＤを渡す＞
ＰＧＷ１１１０は、上述した非特許文献２に開示されるように、３ＧＰＰ手続きごとにＳＧＷ１１１１にCreate Default Bearer Responseを生成し、送信する。Create Default Bearer Responseは、ＬＧＷトークンとＬＧＷ ＩＤ（入手可能であれば）の２つの新たな要素を含む。これを受けてＳＧＷ１１１１は、Create Default Bearer ResponseをＭＭＥ１１１２に中継する。ＭＭＥ１１１２は、受信したCreate Default Bearer Responseに基づいて、ＵＥコンテキスト内にＥＰＳベアラＩＤ（ローカルＩＰアクセスサービスがＰＤＮ接続上にあればデフォルトベアラ、さもなければローカルＩＰアクセスサービスが専用（dedicated）ベアラ上にあれば専用ベアラ）のもとにＬＧＷトークンとＬＧＷ ＩＤを格納する。Bearer Setup Requestを送信する前に、ＭＭＥ１１１２はＵＥ１１４０が接続しているセルがローカルＩＰアクセスサービスを提供することができるかチェックする。

ＨｅＮＢ１１２０がローカルＩＰアクセスサービスに対応し、その提供を許可されるので、ＭＭＥ１１１２は２つの新たな要素を含むBearer Setup Requestメッセージを生成する。異なる実装の形態では、２つの新たな要素がメッセージ内に常に含まれ、受信ノード（例えば、ＨｅＮＢ１１２０）は可能であれば常にローカルアクセスサービスの提供を試み、可能でなければオプションを無視することは可能である。このステップで、ＭＭＥ１１１２は、後で使用するために、例えばＵＥがハンドオーバ又はサービス要求をするときのための情報を格納する。S1-AP context transfer又はSAE bearer managementメッセージ（例えば、セットアップ、修正、解放など）のいずれかがＬＧＷトークンとＬＧＷ ＩＤの要素を運ぶためにBearer Setup Requestの代わりに用いられてもよい。

＜ＨｅＮＢとＬＧＷの間でのリンクのセットアップ＞
ＬＧＷトークンとＬＧＷ ＩＤを運ぶBearer Setup Requestを受信すると、ＨｅＮＢ１１２０は、ローカルＩＰアクセスを行うための適切なベアラを記憶し（メッセージ内のＬＧＷトークンとＬＧＷ ＩＤや他の方法によって指示される）、ＬＧＷ ＩＤによって識別されるＬＧＷ１１３０と通信を開始する。以前に示した方法（ＬＧＷ ＩＤに含まれるＩＰアドレスを用いて直接的に、又はＬＧＷ ＩＤ内に格納された識別子を用いてローカルネットワーク１１０１上で実施するＤＮＳクエリーを介して）のいずれかによってこれを行うことも可能で、必要に応じて復号化を行う。

ＬＧＷ１１３０の位置に基づいて、ＨｅＮＢ１１２０はＬＧＷトークンを運ぶSetup Requestメッセージを送信することによって通信チャンネル（ショートカット経路）１１５４のセットアップ（一例としてはＩＰトンネル）を開始する。ＬＧＷトークンをベアリングするメッセージを受信するＬＧＷ１１３０は、トークンの正確性を確認し、ＬＧＷトークンによって示される通信チャンネル１１５２の位置を発見する。通信チャンネル１１５２を正確に識別することにより、ＬＧＷ１１３０は、このチャンネルと新たに生成された通信チャンネル１１５４との間でのペアリングを記録する。

ＨｅＮＢ１１２０が、ＨｅＮＢ１１２０によって直接アクセス可能なＬＧＷのＬＧＷ ＩＤを保有しているが、ＭＭＥを介して提供されるＬＧＷ ＩＤが既知でない場合、ＨｅＮＢ１１２０はそれを無視し、ＬＧＷ１１３０との通信チャンネル１１５２構築を行わない。また、ＨｅＮＢ１１２０がＬＧＷによってＰＧＷに提供される前にＬＧＷトークンをすでに共有している、又はＬＧＷトークンの内容をＨｅＮＢ１１２０が知っている場合、ＨｅＮＢ１１２０はトークンを確認することができ、トークンが正当であれば、ＨｅＮＢ１１２０は単にＬＧＷ１１３０などに向けたＵＥに関するルーティングテーブルを更新する。ＨｅＮＢ１１２０はＬＧＷとの通信チャンネルを構築する。これは、ＬＧＷにおける修正がほとんどなく、普及のためのコストを低く抑えることができる。

さらに、ＰＧＷ１１１０（又は３Ｇコアネットワーク、例えばＡＡＡサーバ又はＨＳＳで他の信頼されたノード）が、ＬＧＷトークンの内容を知っている場合、又はＰＧＷ１１１０がＨｅＮＢ１１２０（又はＨｅＮＢ１１２０が接続できるローカルネットワーク内の他のエンティティ）だけが知っているＬＧＷ１１１３０に関連する情報（例えば、ＬＧＷ ＩＰアドレス（外部使用）、ＬＧＷ１１３０におけるＡＰＮ、又はいくつかの他のキー）を保有している場合、ＰＧＷ１１１０はＨｅＮＢ１１２０へのＬＧＷトークンを生成して提供し、ＨｅＮＢ１１２０はそのトークンを確認し、トークンが正当であればＬＧＷ１１３０との通信チャンネルを構築し、例えばＬＧＷ１１３０へ向けた経路におけるＵＥに関するルーティングテーブルを単に更新する。ＬＧＷ１１３０がトークン又は他の情報を送信、受信、確認をする必要がないようであり、ＬＧＷは修正なしに完全に既存（既に展開された）のＩＰルータになり得るので有利である。

＜ＬＧＷ上でＵＥトラフィックを結合するためのＤＨＣＰの使用＞
ＵＥ１１４０がＨｅＮＢ１１２０を介してＭＭＥ１１１２にNAS PDN Connectivity Completeメッセージを送信した後、ＵＥ１１４０はアップリンクデータを送信することができ、ローカルネットワーク１１０１からＩＰアドレスを取得する。ＵＥ１１４０はローカルネットワーク１１０１内で使用するためのアドレス（ローカルネットワークアドレス）を取得するためにＤＨＣＰ手続きを開始するが、ＤＨＣＰメッセージ（DHCP Discoverメッセージ又はDHCP Requestメッセージ）内に特別なオプションを含める。ＨｅＮＢ１１２０は、この特別なＵＥベアラがローカルＩＰアクセスのために形成されたのでＬＧＷ１１３０へ直接ＤＨＣＰメッセージを転送する。ＬＧＷ１１３０はプロキシＤＨＣＰエージェント又はＤＨＣＰサーバとして動作し、ＤＨＣＰパケットをインターセプトし、特別なオプションをとりこむ。

このオプションは、あて先アドレスとしてＤＨＣＰメッセージ内に示されたアドレスを有するfutureデータが、このＤＨＣＰパケットが受信される経路に沿って転送されるべきであるとＬＧＷ１１３０に気づかせる。これは、単なるＩＰフィルタルールの手段を通じてもたらされてもよい。ＵＥ１１４０がＤＨＣＰを介してローカルネットワークアドレスを取得した後、ＬＧＷ１１３０は取得されたアドレスと通信チャンネル１１５２、１１５４との間で関係を記録する。このアドレスあてのデータパケットはこの現在の地点で通信チャンネル１１５４を通して転送されるべきであることにも気づく。

ＨｅＮＢ１１２０が上述したようにＬＧＷトークンをすでに確認していた場合、ＵＥ１１４０はローカルネットワーク１１０１へ特別なオプションなしで通常のＤＨＣＰメッセージ（DHCP Discover又はDHCP Request）を送信する。ＬＧＷ１１３０は、ＤＨＣＰメッセージを受信し、ＵＥ１１４０へＩＰアドレスを割り当て、最終的にDHCP Ackメッセージを送信する、又はローカルネットワーク１１０１内のＤＨＣＰサーバにＤＨＣＰメッセージを転送する。ＵＥ１１４０へのDHCP Ackメッセージの送信又は転送中に、ＬＧＷ１１３０は、DHCP AckメッセージのＭＡＣヘッダに記述されたＭＡＣアドレスとDHCP AckメッセージのＩＰヘッダに記述されたＩＰアドレスとを用いてルーティングテーブル又は近隣キャッシュを更新する（ルーティングテーブル更新のために潜在的にＨｅＮＢ１１２０に接続するインタフェースＩＤを用いる）。

そのような方法で、ＵＥ１１４０はＬＧＷトークンを転送するのに特別なオプションを含む必要はなく、またＬＧＷ１１３０はＤＨＣＰメッセージ内で特別なオプションを認識する必要もない。これは、ＬＧＷがほとんど又はまったくの修正なしに既存（すでに配置された）のＩＰルータになり得るため有利である。

ＨｅＮＢ１１２０は、ＬＧＷトークンを確認する他の方法として、例えばＤＨＣＰパケットをインターセプトし、特別なオプション内に含められたＬＧＷトークンを取得し、確認する方法を用いてもよい。

＜ＩＰｖ６自動生成サポート＞
上述したようなＤＨＣＰバージョン４が上述した発明を実装するのに唯一の可能な方法ではないことに注意すべきである。その解法は、ＲＳ（Router Solicitations）とＲＡ（Router Advertisements）が利用される場合、又はＤＨＣＰバージョン６が代わりに用いられる場合にも同じように十分に機能する。

例えば、ＩＰｖ６ ＲＳ／ＲＡがアドレスの自動生成に用いられる場合、ＵＥは自身の識別子、例えばＭＡＣアドレスとＲＡでアナウンスされるプレフィックスを用いることによってアドレスを生成する。この場合、機能する解法のために、ＲＡをアナウンスするルータ、例えばＰＧＷ又はＬＧＷは、アドレス生成のためＤＨＣＰメッセージを送信することをＵＥに強制するように、ネットワーク制御フラグをセットすることができる。

あるいは、解法を実装するＵＥは、アドレス自動生成後に、生成されたアドレスを運ぶＤＨＣＰメッセージを送信することができる。そのような場合、ＤＨＣＰメッセージを用いてアドレスを更新しているように動作する。ＬＧＷはこのメッセージをインターセプトし、フィルタとＵＥのローカルＩＰアクセストラフィックのバインディングを生成する。

＜ＮＡＳにおけるＰＧＷ割り当てアドレス＞
ある操作において、ＵＥのアドレス／プレフィックスが、ＮＡＳ（Non-Access Stratum）手続きの間に割り当てられる。上記で紹介した解法が機能する場合、ＰＧＷはアドレス、例えば０．０．０．０としてあらかじめ定義された値を含めることができ、これは接続構築手続き後のアドレスとユーザプレーンの利用可能性を取得するためのＤＨＣＰ手続きを実行することをＵＥに強制できる。

＜移動後、ＵＥはＬＩＰＡトラフィック再結合を更新するためにＬＧＷにトリガするＤＨＣＰを送信する＞
ＵＥ１１４０は、ＨｅＮＢ１１２１に向けて動いている。以前に記述したプロセス（図６）と同様、ＨｅＮＢ１１２０は、ハンドオーバターゲットとしてＨｅＮＢ１１２１を特定してＭＭＥ１１１２にHandover Requiredメッセージを送信する。ＭＭＥ１１１２は、ＨｅＮＢ１１２１に送信されるHandover Requestメッセージ内に、関連するＥＰＳベアラのＬＧＷトークンとＬＧＷ ＩＤの要素を含める。ＨｅＮＢ１１２１は、ＬＧＷ１１３０との通信チャンネル１１５８を配置してセットアップする新たな情報要素を認識する。ＵＥ１１４０がハンドオーバ成功後にＨｅＮＢ１１２１へHandover Confirmメッセージを送信した後に、ローカルネットワーク１１０１と既存のセッションがあると理解する。

この場合、ＤＨＣＰ手続きを用いてＬＧＷ１１３０に知らせるが、ローカルネットワーク１１０１から得られたアドレスを使用しており、特別のオプションを含んでいるDHCP Refreshメッセージを代わりに利用してもよい。特別のオプションを有するDHCP Refreshメッセージを受信すると、ＬＧＷ１１３０は、ＵＥ１１４０のローカルネットワークアドレスのもと、通信チャンネル１１５２と以前の通信チャンネル１１５４に代わった新たな通信チャンネル１１５８で記録（例えば、ルーティングテーブル又は近隣キャッシュ）を更新する。このアドレスあてのデータパケットは、この現時点で通信チャンネル１１５８を通じて転送されるべきであることにも注意する。

ＵＥ１１４０はｅＮＢ１１１３に向けて移動している。ＵＥ１１４０がハンドオーバの成功後にＨｅＮＢ１１２１へHandover Confirmメッセージを送信した後に、ローカルネットワーク１１０１と既存のセッションがあると理解する。しかし、ｅＮＢ１１１３はＬＧＷ１１３０との直接の通信チャンネルを有しておらず（おそらく物理的又はポリシ制限によるもの）、ＬＧＷトークンとＬＧＷ ＩＤの新たな情報要素を受信できない、又は受信されてもアクションを起こせない。この場合、ＵＥ１１４０がローカルネットワーク１１０１から取得したソースアドレスセットを有し、特別なオプションを含むDHCP Refreshメッセージを送信すると、ｅＮＢ１１１３はＳＧＷ１１１１を介してＰＧＷ１１１０にそのメッセージを代わりに転送する。

ＰＧＷ１１１０は通信チャンネル１１５２を介してＬＧＷ１１３０にDHCP Refreshメッセージを転送する。特別なオプションを有するDHCP Refreshメッセージの受信に基づいて、ＬＧＷ１１３０は、他の通信チャンネル１１５８を取り除いて、ＵＥ１１４０のローカルネットワークアドレスのもと、通信チャンネル１１５２で記録を更新する。ＬＧＷ１１３０は、このアドレスあてのデータパケットがこの時点でＰＧＷ１１１０へ通信チャンネル１１５２を通じて転送されることに気づく。

＜ＭＭＥでトークンの格納をしない：ＰＧＷはＵＥの位置更新を要求する、そのためハンドオーバ後、ＭＭＥは修正ベアラ要求を用いてＰＧＷを更新し、ＰＧＷは修正ベアラ応答を用いてＭＭＥを介してトークンを再送信する＞
他の操作において、ＭＭＥ１１１２はＬＧＷについてのトークン情報を格納する必要がない。この場合、ＰＧＷはＰＤＮ接続又はローカルＩＰアクセスのベアラが構築されると、ＵＥの位置情報の更新を要求する旨を指示する。

ＵＥのサービングセルの変更によるあらゆるモビリティイベント後に、ＭＭＥ１１１２はＳＧＷ１１１１にModify Bearer Requestを開始し、ＰＧＷ１１１０に向けて送信する。そのような更新を受信するＰＧＷは、現在のセルがＵＥにローカルＩＰアクセスのためのダイレクトコネクションを提供することを許されているのか（セル情報を用いて（例えば、ＥＣＧＩ））決定することができる。ＰＧＷがセルからローカルＩＰアクセスのダイレクトコネクションが許されていると決定すると、Modify Bearer Responseメッセージ内にＬＧＷトークンとＬＧＷ ＩＤを提供する。これはサービングセル、例えば適切なＳ１ ＡＰメッセージを介してｅＮｏｄｅ Ｂ又はＨ（ｅ）ＮＢなどに送信される。

あるいは、ＰＧＷはModify Bearer Responseメッセージにトークン又はＬＧＷ ＩＤを含めない。その代わりに、Modify Bearer Responseメッセージ後、即座にＰＧＷは、トークンとＬＧＷ ＩＤを運ぶUpdate Bearer Requestをトリガする。これは、ｅＮｏｄｅ Ｂ又はＨ（ｅ）ＮＢに転送されるトークンとＬＧＷ ＩＤと同様である。

＜第１２の実施の形態＞
＜ＬＧＷトークンとＩＤをＨｅＮＢへ中継するためのＵＥの使用＞
他の好ましい実施の形態として、ＵＥ１１４０はＰＧＷ１１１０へ要求を送信することによってローカルアクセスサービスの要求をする。ＬＧＷトークンとＬＧＷ ＩＤの情報要素は、ＰＧＷ１１１０によって生成されたCreate Session Responseメッセージで運ばれるＰＣＯの使用を通じてＰＧＷ１１１０からＵＥ１１４０へ送信される。RRC Connection Reconfigurationメッセージ内で運ばれるＰＣＯ内のＬＧＷトークンとＬＧＷ ＩＤを受信すると、ＵＥ１１４０はＨｅＮＢ１１２０へ送信されるRRC Connection Reconfiguration CompleteメッセージにＬＧＷ ＩＤの情報要素を加える。

ＬＧＷ ＩＤを受信すると、ＨｅＮＢ１１２０は、RRC Connection Reconfigurationメッセージ内のＬＧＷ ＩＤによって識別されるような適切なＵＥ（ユーザプレーン）ベアラに関してＬＧＷ１１３０と通信チャンネル（ショートカット経路）１１５４を生成する。ＵＥは、ローカルネットワーク１１０１アドレスを要求するときＤＨＣＰ特別オプションにＬＧＷトークンを加える。ＬＧＷ１１３０は、関連するＰＧＷ１１１０通信チャンネル１１５２を確認し決定するために、特別オプション内に格納されたＬＧＷトークンを照合することができる。

ＵＥ１１４０は、接続チャンネルの生成が保証されるように、ＨｅＮＢ１１２０がトークンを確認するためにRRC Connection Reconfigurationメッセージ内にＬＧＷ ＩＤに加えてＬＧＷトークンを含めてもよい。この場合、ＵＥ１１４０はＤＨＣＰメッセージ内にＬＧＷ１１３０へトークンを送信しない。

そして、ハンドオーバすると、ｅＮｏｄｅ Ｂ又はＨ（ｅ）ＮＢがＬＧＷに向けてローカルＩＰアクセスのダイレクトコネクションを提供することができると決定する場合、ＵＥは、ｅＮｏｄｅ Ｂ又はＨ（ｅ）ＮＢ宛のRRC Connection Reconfiguration（Handover Complete）メッセージ内にＬＧＷ ＩＤとＬＧＷトークンを含める。これにより、対応するｅＮｏｄｅ Ｂ又はＨ（ｅ）ＮＢに、ＵＥのローカルＩＰアクセストラフィックのためのＬＧＷと接続するダイレクトコネクションを確立することをトリガする。

＜第１３の実施の形態＞
＜３ＧアクセスとＬＩＡアクセスにおけるＰＧＷ共有ケース：ＰＤＮ接続内でＬＩＡを管理するためＵＥが要求したBearer Resource Modificationを利用＞
他の好ましい実施の形態として、その方法は、ＰＧＷ１１１０がローカルアクセスサービスだけでなく３Ｇも利用する場合における解法のオペレーションについて述べられている。１つの実装の形態として、ＵＥ１１４０は、ローカルアクセスサービスを開始するため既存のＰＧＷ（ＰＧＷ１１１０）にトリガするためにローカルアクセスサービス要求として非特許文献２に開示されているＵＥが要求したbearer resource modificationを利用する。ＰＧＷ１１１０へのトリガメッセージは、ＭＭＥ１１１２とＳＧＷ１１１１によって透過的に（トランスペアレントリーに）運ばれるRequest Bearer Resource ModificationメッセージのＰＣＯ内の付加的なフィールド又はオプションとして運ばれてもよい。ローカルアクセスサービス要求を受信すると、ＰＧＷ１１１０はＵＥ１１４０がこのサービスへのアクセスが許されるかどうか決定する（ユーザサブスクリプション情報叉はオペレータポリシをチェックするなどして決定する）。

アクセスが許されると仮定すると、ＰＧＷ１１１０は、ＵＥ１１４０が既存のＰＤＮ接続上で複数のＩＰアドレスを効率よく利用できるように、例えば宅内と宅外同時に利用できるように、ＵＥ１１４０のモビリティサービスのための準備を行う。ＰＧＷ１１１０は、ローカルＩＰアクセスサービスのためＬＧＷからＩＰアドレスを取得するのにＵＥを支援するプロキシアドレス割り当て処理を開始する。新たなＩＰアドレスはケアオブアドレスとしてホームエージェント（この場合、ＰＧＷ１１１０）に登録される。

ＰＧＷ１１１０は、ＵＥ１１４０のため、直接のローカルアクセスサービスを実現するために適切なノード（ＨｅＮＢ１１２０とＬＧＷ１１３０など）上にローカルドメイントラフィックのための適切なパケットフィルタ（例えば、ＴＦＴ（Traffic Flow Template））をインストールする。これは、ＭＭＥを介してＨ（ｅ）ＮＢにUpdate Bearer Request (Bearer Modify Request)でそのフィルタを運ぶことによって実行される。ＵＥの新たなＩＰアドレスは、Session Management Requestで、例えばＴＦＴとともに運ばれる。

＜外部ＰＤＮ割り当て手続きを用いて割り当てられるＩＰアドレス、例えばＵＥはＰＧＷを介してＰＤＮから要求する＞
外部ＰＤＮ割り当て手続きを介してローカルネットワーク１１０１からのＩＰアドレスをＵＥ１１４０が要求することは可能であり、それによって、ＰＧＷ１１１０はＵＥ１１４０に対してＤＨＣＰサーバとして、ローカルネットワーク１１０１に対してＤＨＣＰクライアントとして動作する。この場合、ＵＥはローカルネットワークアドレス要求と３ＧＰＤＮアドレス要求を区別するべきである。これは、いくつかのフィールドの変更（３ＧとローカルネットワークサービスにおけるCHADDRフィールドの違いを用いるなど）を通じた構成や、違いを示すためにＤＨＣＰメッセージ内にオプションを含めたりする（例えば、この接続に以前に割り当てられたＩＰアドレスを要求する）構成によりなされる。

図１１を参照するに、ＵＥ１１４０は、ローカルネットワーク１１０２へローカルアクセスサービスを実行するためにＰＧＷ１１１０との既存のＰＤＮ接続の利用を望む。この配置において、ＰＧＷ１１１０はＵＥ１１４０へ３Ｇサービスを提供するＰＤＮ接続である。ＰＧＷ１１１０が上述したように単にローカルアクセスサービスのために利用され、ＵＥ１１４０が追加のローカルネットワークへの接続の要求をするためにこの方法を用いることが可能であることにも注意する価値がある。この場合、ＵＥ１１４０がＰＧＷ１１１０のアドレスプールからＩＰアドレスを割り当てられるか、ホームアドレスとして用いられるＰＤＮ内部から割り当てられるか、又はローカルネットワーク（１１０１、１１０２）から得られたＩＰアドレスの１つを動的に利用して割り当てられるかはＰＧＷ１１１０の実装による。

ローカルアクセスサービストリガを有するＰＣＯを運ぶBearer Resource Commandメッセージを受信すると（ローカルネットワーク１１０２のＡＰＮ又はＦＱＤＮであってもよい）、ＰＧＷ１１１０はＬＧＷ１１３１と通信チャンネル１１５１を構築するための上述された手続きに従う。ＰＧＷ１１１０がＵＥ１１４０のためにローカルネットワーク１１０２からＩＰアドレスを取得すると、ＰＧＷ１１１０は自動的に非特許文献２に開示された通常の手続きを介してＵＥ１１４０に通知する前に追加のケアオブアドレスとして新たに得られたアドレスを登録する。ＵＥ１１４０が自身の新たなＩＰアドレスを取得すると、ＵＥ１１４０は、ホームエージェントとして動作するＰＧＷ１１１０へのユーザプレーンベアラにケアオブアドレスとして新たなローカルネットワーク１１０２ＩＰアドレスを登録するバインディングアップデートを送信すべきである。

ＰＧＷ１１１０がケアオブアドレス登録を取得した後、ＰＧＷ１１１０はＨｅＮＢ１１２１とＬＧＷ１１３１に新たなケアオブアドレスのためのパケットフィルタのインストールをするべきである。ＬＧＷ１１３１へのパケットフィルタのインストールは、通信チャンネル１１５１上に送信されるＵＥ１１４０の位置に依存する既存のルーティングエントリを付加又は修正するコマンドを伴う。ＨｅＮＢ１１２１へのパケットフィルタのインストールは、ＨｅＮＢ１１２１にインストールされる必要があるパケットフィルタを運ぶために、非特許文献２に開示されたようなＰＤＮ ＧＷ initiated bearer modification手続きを再利用することによって成し遂げられる。

ＨｅＮＢ１１２１では、ローカルアクセスデータパケットを適切に直接転送するためにパケットフィルタの受信に基づいてＬＧＷ１１３１との通信チャンネル１１５９の生成が開始される。この配置では、ＰＧＷ１１１０は、ＵＥ１１４０のローカルアクセスサービスを実現するためにパケットフィルタの更新をタイムリーに行う。

＜ＰＧＷがハンドオーバ後ＬＩＡサービスアクセス制御を行うときのシーケンスの違い＞
ＵＥ１１４０が他のＨ（ｅ）ＮＢ又はマクロセルなどの他の接続ポイントに移動するとき、ローカルネットワーク（１１０１、１１０２）の直接転送するデータのローカルコンテキストを新たな接続ポイントに送信させることは可能である。この場合、ＵＥ１１４０は、ＰＧＷ１１１０がＵＥの新たな位置情報に関してＭＭＥから通知を受け取る間に、ＬＩＡサービスを即座に受ける。ＰＧＷは新たな接続ポイント上でそのフィルタに必要な交換をしてもよい。

あるいは、ＬＩＡサービスコンテキストは、ハンドオーバの間、移動されない。ＵＥは、外部ＰＤＮアドレス割り当て手続きと同様にＰＧＷ１１１０にDHCP Refreshメッセージを送信すべきである。ＰＧＷ１１１０は、ＬＩＡサービスが新たな接続ポイントで提供される前に適切なフィルタをインストールするための必要な決定及び行動をとることができる。

＜第１４の実施の形態＞
＜ホームエージェントとしてのＬＧＷのメイキング：ＬＧＷ管理のためＤＨＣＰの代わりにＢＵを利用＞
選択的な実施の形態において、ＵＥは、コアネットワークとローカルＩＰアクセスサービスによって提供される３ＧＰＰサービスにアクセスするために同じ又は異なるＰＤＮ接続を利用することができる。この場合、ＬＧＷ１１３１はＵＥのモバイルＩＰホームエージェントとして動作する。

ＵＥは、まず非特許文献２に開示されている手続き、例えばAttach又はUE requested PDN connection setupを用いてＰＧＷにＰＤＮ接続を構築する。通常通りアドレスがＵＥに割り当てられる。このアドレスはコアネットワークによって提供される３ＧＰＰサービスにＵＥがアクセスするために用いられる。モバイルＩＰの意味においては、これはＵＥのケアオブアドレス（CoA）である。

同時に、ＵＥはＬＧＷへの接続を試みる。これはモバイルＩＰブートストラップ処理を介するものになり得る。あるいは、そのベアラがＬＧＷにトラフィックが転送されることをＰＧＷは知るなどのやり方で、ＵＥはＬＩＡサービスのためにＰＧＷへの特別なベアラを構築することができる。

ＰＤＮコネクションを確立すると、ＵＥは、ＬＧＷを介してローカルＩＰアクセスドメインからアドレスを取得しようとする。このアドレスはローカルＩＰアクセスサービスへのＵＥのアクセスのためのものである。モバイルＩＰの意味においては、これはＵＥのホームアドレス（HoA）である。

ＬＧＷからＨｏＡを取得する処理において、ＬＧＷトークンとＬＧＷ ＩＤがＵＥに提供される。通常のトークンとＬＧＷ ＩＤのほかに、ＨｏＡに基づくフィルタも関連付けられている。例えば、この場合、フィルタは、ソースアドレスＨｏＡを有するパケットがローカルのダイレクトコネクション（ＨｅＮＢとＬＧＷとの間の通信チャンネル）を介してＬＧＷに転送されるものであることをＨ（ｅ）ＮＢに知らせることができる。ＵＥは、トークン、ＬＧＷ ＩＤ、関連するフィルタを適切な無線レイヤ管理メッセージ、例えばMeasurement Report、RRC Connection Reconfiguration、self-configuration and self optimisation relatedメッセージを用いてＨｅＮＢへ渡すことができる。あるいは、ＰＤＮ管理又はベアラ管理手続きがローカルＩＰアクセス構築を開始するために用いられる場合、トークン、ＬＧＷ ＩＤ、関連するフィルタはＰＧＷによってＭＭＥを介してＨ（ｅ）ＮＢへ直接渡され得る。

この後、ＵＥは２つのバインディングアップデートメッセージを形成しようとする。１つはＬＧＷにＣｏＡを登録するためのもので、送信アドレスとしてＣｏＡを用いている。１つは、ホームネットワークに戻った場合にバインディングを消去するもので、送信アドレスにはＨｏＡを用いる。シーケンス番号は登録消去バインディングアップデートがＣｏＡ登録メッセージに優先する形で割り当てられているとＵＥは確認する。ＵＥは使用されるリソースを減らすために、同時に２つのバインディングアップデートメッセージを送信したり、登録バインディングアップデートメッセージよりわずかに早く登録消去バインディングアップデートメッセージを送信したり、登録消去バインディングアップデートメッセージよりわずかに早く登録バインディングアップデートメッセージを送信したりする。

Ｈ（ｅ）ＮＢがＬＧＷにダイレクトコネクションできる場合、メッセージがソースアドレスとしてＨｏＡを用いており、そのＨｏＡがフィルタに適合したため、ローカル接続を介して直接ＬＧＷに登録消去バインディングアップデートを転送する。バインディングアップデートメッセージを受信すると、ＬＧＷはローカルなダイレクトコネクションを介して直接ＵＥのすべてのトラフィック（アドレスＨｏＡを有する）をＨ（ｅ）ＮＢへ切り替える。ＰＧＷを介してルートされた登録バインディングアップデートはＬＧＷによって静かに破棄される。

Ｈ（ｅ）ＮＢがＬＧＷへダイレクトコネクションをサポートすることができない場合、登録消去バインディングアップデートは、アドレスが正当ではないので、Ｈ（ｅ）ＮＢ又はＰＧＷによって破棄される。この場合、登録バインディングアップデートは通過してＬＧＷに届く。これは、ＣｏＡのバインディングキャッシュをＬＧＷが生成し、ＰＧＷに向けてＵＥのトラフィックをルートすることによるものである。

＜Ｈ（ｅ）ＮＢがＬＧＷからのＲＡを転送し、ＵＥが直接ＨｏＡを形成する＞
ＵＥが、現在のセルが例えばＥＣＧＩリストをチェックすることにより又は他の手段によりＬＧＷへのダイレクトコネクションをサポートしているかどうかを知っている場合、ＵＥは２つのバインディングアップデートの代わりに１つの適切なバインディングアップデート（登録ＢＵ又は登録消去ＢＵ）を送信すればよい。例えば、ローカルＩＰアクセスをサポートするＨ（ｅ）ＮＢはＬＧＷからのＲＡメッセージを転送する。これは、上述の実施の形態（第１から第１４の実施の形態）に示されるように、Ｈ（ｅ）ＮＢとＬＧＷとの間でダイレクトリンク構築後に即座に開始される。ＬＧＷからのＲＡは、ＵＥが異なるＬＧＷから異なるＲＡを区別することができるように、このＬＩＰＡアクセスを特定するベアラ上を転送されてもよい。例えば、ＵＥは２つの異なるＲＡ、例えばＰＧＷとＬＧＷからのＲＡに気づく。ＵＥはそれが宅内（ホーム）と宅外（アウェイ）であることを知っている。ＵＥはいずれかのＢＵか、ローカルＩＰアクセスの両方の経路を用いることを許す特別なフラグとフィルタを有するものを送信することを選択できる。

プロキシモバイルＩＰの意味においてＨｅＮＢがＭＡＧ（Mobile Access Gateway）になり得る場合、ＨｅＮＢは、ＵＥが登録消去バインディングアップデートメッセージを送信するために用いられる無線リソースを減らすことができるように、ＵＥの登録消去バインディングアップデートメッセージの送信の代わりにＬＧＷへＰＢＵ（Proxy Binding Update）メッセージを送信することができる。

＜第１５の実施の形態＞
＜マクロセルに同じ解法を当てはめる＞
上述した解法において、ネットワークへのＵＥのアクセスノードはＨｅＮＢである。しかしながら、同じ解法がマクロセル又はアクセスポイント、例えばeNodeB、NodeB、BSなどに当てはめられることは当業者であれば自明である。

＜トークンは範囲を制限するためにＴＡＩを含む＞
上述した解法において、トークン情報がＴＡＩ（Tracking Area IDs）又はeven cell ID（例えば、ＥＣＧＩ）のリストを含むことは可能である。これは、アクセス制御の特定の形がコアネットワーク内で、例えばＰＧＷ又はＭＭＥで行われることを許す。この場合、許されたＴＡＩ又はＥＣＧＩにある場合（通知されるトークンに含まれるものとしてＴＡＩ又はＥＣＧＩと同じ）、トークン又はＬＧＷ ＩＤはｅＮｏｄｅＢ又はＨ（ｅ）ＮＢに転送されるのみである。これは、ネットワーク側で過度のシグナリングを避けることができる。

上述の解法において、ＬＧＷ ＩＤとＬＧＷトークンは異なる情報であるが、それらは１つの情報、例えばＬＧＷ ＩＤを含むＬＧＷトークン、トークン部分を含むＬＧＷ ＩＤ、又はトークンとＬＧＷ ＩＤを同時に含む他の名前の情報にまとめられてよい。

＜第１６の実施の形態＞
＜モビリティでのローカルアクセスの動的ＱｏＳ調整＞
ＵＥがローカルＩＰアクセスサービスのＰＤＮ接続（又は専用ベアラ）を開始するとき、又はローカルＩＰアクセスサービスにおいてローカルネットワークへのショートカット経路を提供するＨｅＮＢへＵＥがハンドオーバするとき、ショートカット経路上でのＨｅＮＢとローカルネットワーク（又はＬＧＷ）との間のローカルアクセス経路が内部ネットワーク（例えば、イーサネット（登録商標）、ＷＬＡＮ、ＰＬＣなど）を通じてより広帯域となるため、ＰＧＷ（又はＨｅＮＢ／ＬＧＷ）は通常の３Ｇアクセス（例えば、ＥＰＣを超えてＰＤＮにアクセス）よりその接続を広帯域アクセスに動的にするために、その接続かつ／又はベアラのＱｏＳコンテキストを修正する。

ＰＧＷが、上述した非特許文献２に開示されているように、手続き（Attachment procedure、UE requested PDN connectivity procedure、Handover procedure）の間、ＵＥの接続の構築又はハンドオーバを認識すると、ＰＧＷはポリシーサーバ（例えば、３ＧＰＰコアネットワークでのＰＣＲＦ）によって提供される又はＰＧＷ自身によって所有されるルールに基づくＱｏＳポリシをコネクションに適用する。ルールが基本的にサブスクリプションベース（すなわち、静的に定義される）であるので、ＵＥのユーザは、ローカルネットワーク内での通信であるためローカルＩＰアクセスサービスのためにより多くのリソースを必要とするかもしれない。

ローカルＩＰアクセスサービスにとって、接続がＨｅＮＢ／ＬＧＷとローカルネットワークとの間（例えば、ＨｅＮＢ又はＬＧＷでプロキシＰＧＷ機能によってトリガされる）でのショートカット通信経路であるとＰＧＷが認識する場合、ＰＧＷはローカルアクセスサービスのためにＨｅＮＢ（プロキシＰＧＷ機能）／ＬＧＷから新たなルールを取得し、接続／ベアラのルールを適用する（例えば、上述した非特許文献２に開示されるPDN GW initiated bearer modification手続きを用いて）。ＰＧＷは、ローカルＩＰアクセスサービスのＱｏＳ実施に関してＵＥのサブスクリプションを考慮することができる。

例えば、ＰＧＷはＵＥのサブスクリプションに基づいてそれぞれのＵＥにおける異なるＱｏＳポリシ／ルールを実施する。ＵＥ（Ａ）はＨｅＮＢとローカルネットワークが配置された家の顧客であるので、ＵＥ（Ａ）には低いビットレート、ＵＥ（Ｂ）はＨｅＮＢ（そしてローカルネットワーク）の所有者であるのでＵＥ（Ｂ）には高いビットレート、ＵＥ（Ｃ）は所有者によって良好なＱｏＳパラメータを有するローカルＩＰアクセスサービスを用いることが許された特別な顧客であるのでＵＥ（Ｃ）には高いビットレートとする。ＵＥは、付加的な属性（例えば、通常の顧客、特別な顧客、所有者など）を手続きのためのメッセージに含めてＰＧＷ（又は他のエンティティ）への提供することができる。

ＨｅＮＢからローカルＩＰアクセスサービスの接続／ベアラをハンドオーバしているとき、ＰＧＷは、通信／セッションが他の接続や他のＵＥを害さないように、ＵＥとその接続におけるＱｏＳレベルを小さくしてもよい（例えば、ショートカット通信より帯域を狭くする）。

適切なＱｏＳポリシ／ルールが接続構築の間に当てはめられることができるように、ＵＥは、はじめから適切なＱｏＳで通信／セッションを開始する（例えば、通信／セッション開始した後に調整が必要ない）。これにより、ユーザの利便性を増すことができる。

ネットワーク態様（ショートカット経路又は通常のＥＰＣアクセスを通じたローカルネットワーク）に応じたＱｏＳ制御は、ＨｅＮＢ又はＬＧＷが実施してもよい（例えば、非特許文献２に開示されたＰＤＮ ＧＷ initiated bearer modification手続きを用いて）。そのＱｏＳ制御は、接続構築手続き又はハンドオーバを実施してから、ＵＥが通信／セッションを開始するまでの間に実施され、それによってＰＧＷがローカルＩＰアクセスサービスのケーパビリティを意識する必要がなくなり、ＰＧＷにおける動作負荷を低減することができる。

＜第１７の実施の形態＞
あるサービスやアプリケーションにおいては、ユーザ（ＵＥ）の在圏位置に適応して、接続先となるローカルネットワーク（ローカルＩＰアクセスネットワーク）やＬＧＷを選択したり、提供サービス内容やシステム／ネットワークのケーパビリティ、ＱｏＳ保証内容、セキュリティレベルなどを変化させることで、システム上での拡張性を有するサービスやアプリケーションの提供が可能となる。例えば、企業情報システムでは、情報保護や情報漏洩防止の観点から、社外のアクセス系から企業ネットワークに接続する従業員には、セキュリティレベルの高いデータやファイルへのアクセスに制限をかけることがある。一方で、社内のアクセス系から接続している時は、ユーザ認証によって得られた権限の範囲で秘匿データやファイルへのアクセスを許可する。詳細には、社内の基地局（例えばその企業向けＣＳＧセル）やアクセスシステム以外から企業ネットワーク（ローカルネットワーク）にリモートアクセスする従業員には、より高いセキュリティレベルを課したり、リモートアクセス専用のローカルネットワークに接続させたりして、情報漏洩を回避しようとする。

本実施の形態では適応サービス提供方法について開示し、ＵＥが、ローカルネットワークに最適経路を確立することができる基地局（例えば、Ｈ（ｅ）ＮＢ：ＨＮＢまたはＨｅＮＢ）を介してローカルネットワーク（ＬＩＡネットワーク；企業ネットワーク、ホームネットワークなど）に接続するＬＩＡ（ローカルＩＰアクセス）を行うか、ローカルネットワークに最適経路を確立することができない基地局を介して接続するＲＩＡ（リモートＩＰアクセス）を行うかに依存し、ＵＥの在圏位置に応じて、サービス内容、システム／ネットワークのケーパビリティ、ＱｏＳ保証内容、サービス及びアプリケーションのセキュリティレベルを変えることができる。

図１３は本実施の形態を説明するための、ＬＩＡドメインの構成例を示す図であり、複数のローカルネットワーク、複数のＬＧＷ、複数のＨｅＮＢがＬＩＡドメインに配置される。ローカルネットワークは、ＬＩＡ接続用とＲＩＡ用に分けて配置される。ＬＧＷは、複数のローカルネットワークを収容（複数のローカルネットワークに接続）するものもあれば（ＬＧＷ３）、単一のローカルネットワークを収容するだけのものもある（ＬＧＷ１、ＬＧＷ２）。同様に、ＨｅＮＢも複数のＬＧＷに接続し、それぞれとＬＩＡ接続のための最適化経路を構築することができる。ＬＧＷがＨｅＮＢ内に一緒に配置される場合も同様であり、ＨｅＮＢによっては複数のローカルネットワークを収容することもある（ＨｅＮＢ３）。なお、上記構成は、本実施の形態を説明するための想定であり、必ずしも同一の構成をとる必要はなく、実際の構成はシステムの要求や性質に応じて変更又は修正されるものである。

上記構成において、ＵＥが宅外、すなわちローカルネットワーク、エリア、基地局を含むネットワークに向けて、ＬＩＡ接続のための経路最適化を実施できない基地局（ＬＩＡドメインに属しないｅＮＢやＨｅＮＢ４）からリモートにローカルネットワークへの接続を試みる。なお、上述の実施の形態（第１から第１６の実施の形態）に示したように、ＵＥは、接続を試みている基地局が、ＬＩＡ接続のための経路最適化を実施できる基地局であるかどうかを意識する必要はなく、ＬＩＡ接続、ＲＩＡ接続のいずれの場合も同じＬＩＡ用ＡＰＮ（ＬＩＡ−ＡＰＮ）を用いることができる。これにより、ユーザがＬＩＡ接続とＲＩＡ接続のいずれかを実施すべきかの判断が不要となり、ユーザ負担を軽減できるとともに、ローカルネットワークへのアクセスに対する自由度を知識なしに容易に向上させることができる。

ＵＥの接続要求（Attach Request、Service Requestなど）はＭＭＥに転送され、ＭＭＥはCreate Bearer Requestメッセージを送信する。Create Bearer Requestメッセージは、ＳＧＷを介してＬＧＷに転送される。しかし、同じ解放がCreate Session Requestメッセージのケースに適用されることは当業者であれば自明である。この実施の形態では、一例として、Create Bearer Requestメッセージのケースについて述べる。ＭＭＥは、ＵＥの位置情報として、セルＩＤ、基地局ＩＤ（例えば、（Ｅ）ＣＧＩ（E-UTRAN Cell Global ID or Cell Global ID））、ＣＳＧ ＩＤ、トラッキングエリアＩＤ（Tracking Area ID: TAI）、ルーティングエリアＩＤ（Routing Area ID: RAI）、ロケーションエリアＩＤ（Location Area ID: LAI）などを含む。位置情報は、上述のＩＤのうち１つ以上になり得る。ＰＧＷはＵＥの位置情報を得るためにCreate Bearer Requestメッセージを処理し、既に構築された、又は新しくこの時点で構築されたＰＧＷとＬＧＷの間のトンネルを通して位置情報についてＬＧＷ（例えば、ＬＧＷ３）に通知する。

ＬＧＷは、ＵＥのリクエストがＬＧＷ自身（他のＬＧＷに移転され得るケースである点に注意）に最適化経路を構築することができる基地局（例えば、この場合、ＨｅＮＢ２）からの接続構築に関するものであるかどうか検出し、そうであれば、ＬＧＷはＬＩＡのローカルネットワーク（ローカルネットワーク３）への接続構築を継続することを決定し、ローカルネットワーク３へ向けてＬＩＡ接続の経路を構築する。構築された経路は、最適化経路を構築する際に、ＵＥの無線ベアラとＨｅＮＢ（例えば、ＨｅＮＢ２）によってバインドされるものである。ここで、ＬＧＷは、検出の目的のためにＬＩＡドメイン内で自身を含むＬＧＷへ最適化経路を構築することができる基地局のリストを維持する。ＬＧＷは、ＵＥが接続を試みようとする基地局がそのリストに含まれるかチェックする。さもなければ、ＬＧＷは、ＵＥの位置情報、例えばセルＩＤ、（Ｅ）ＣＧＩ、ＴＡＩなどにて示された基地局に、経路最適化の実施可能性を問い合せるものであってもよい。

また、ＬＧＷ（ＬＧＷ３）は、ＵＥが経路最適化を実施可能な基地局以外からの接続（例えば、ｅＮＢやＨｅＮＢ４からの接続）であることを確認すると、ＬＧＷ３は、ＲＩＡ（例えば、ローカルネットワーク４）のローカルネットワークへの接続構築を継続することを決定し、ローカルネットワーク４に向けてＲＩＡ接続用の経路を構築する。ローカルネットワーク４への構築された経路は、現在確立しているＵＥのＥＰＳベアラとＬＧＷ３によってバインドされる。

ここで、ＬＧＷは、ＵＥの在圏位置に応じて、サービス内容、システム／ネットワークのケーパビリティ、ＱｏＳ保証内容、サービス及びアプリケーションのセキュリティレベルを制御（アレンジ）することができる。例えば、ＵＥがＬＩＡ接続可能な位置から接続している場合は、ＬＧＷは、ＬＩＡ接続用パスを確立するとともに、ＵＥにすべてのサービスを許可する。また、ＬＧＷは、ＵＥのアクセスレベルを高めることを承認（Authorization）サーバに要求し、承認サーバがそれを承認する。これにより、ＵＥのＬＩＡ接続のデータパスがローカルエリア（例えば、構内、宅内、会社内など）に維持されるため、ユーザがローカルネットワークへアクセスする制限が緩和され、ユーザの利益が保証される。

また、他の一例として、ブロードキャストやマルチキャストトラフィックがＬＩＡ接続上でＵＥに転送されるよう、ＬＧＷ内に経路表やパケットフィルタが構成されてもよい。これにより、多くのプロトコルがサービスやアプリケーションによって利用され、様々なサービスやアプリケーションがユーザに提供される。

また、他の一例としては、ＬＩＡアクセス用のスループットが向上し保証されるように、ＬＩＡアクセス用の接続がよりよいＱｏＳパラメータで構成されるものであってもよい。ローカルアクセスの特徴にもなりうるスループットを向上させるために、ローカルネットワークとＬＧＷの間、ＬＧＷとＰＧＷの間、及びＰＧＷとＵＥの間のＱｏＳ設定を、よりよいパラメータ、例えば高く設定したＭＢＲ／ＧＢＲ（Maximum Bit Rate／Guaranteed Bit Rate）や高く設定したＡＲＰ（Allocation and Retention Priority）などを用いて行うようにしてもよい。さらには、ＵＥでのスループット及びパフォーマンスが向上するように、追加的なセキュリティプロトコル（例えば、IPsecトンネル等）がＵＥへ要求されないようにすることもできる。

対して、ＵＥがＬＩＡ接続できない基地局を介して接続している場合（すなわち、基地局が最適化ＬＩＡ接続を構築することができない）、ＬＧＷは、ＲＩＡ接続用パスを確立するとともに、ＵＥに一部のサービスのみ許可する。また、ＬＧＷは、ＵＥのアクセスレベルを低く設定することを承認サーバに要求し、承認サーバがそれを承認する。

また、他の一例として、ブロードキャストやマルチキャストトラフィックがＲＩＡ接続上でＵＥに転送されないよう、ＬＧＷ内に経路表やパケットフィルタが構成される。これにより、不必要なトラフィックと情報漏洩が回避される。

また、他のケースでは、ＲＩＡアクセスのスループットが適度に維持され、ユーザ利益が保証されるように、ＲＩＡアクセス用の接続が適当なＱｏＳパラメータで構成されることもできる。適正なスループットを維持させるために、ローカルネットワークとＬＧＷの間、ＬＧＷとＰＧＷの間、及びＰＧＷとＵＥの間のＱｏＳ設定を適正に設定する（例えば、ＥＰＳベアラと他の経路の間でＱｏＳパラメータをあわせるなど）こともできる。さらに、セキュリティ要求が妥協されないように、追加的なセキュリティプロトコル（例えば、IPsecトンネル等）がＵＥへ要求されるようにすることもできる。

また、ＵＥがＬＩＡ接続可能な基地局から、それ以外の基地局へのハンドオーバ、すなわちＬＩＡ接続からＲＩＡ接続に（あるいはその逆向き）ハンドオーバする際は、ＵＥの位置情報の更新を理由に、ＭＭＥがModify Bearer RequestメッセージにＵＥの位置情報を含め、そのメッセージをＵＥを収容するＳＧＷを介してＰＧＷに送信する。ＰＧＷは、そのメッセージからＵＥの位置情報を取得し、ＬＧＷへその情報を転送する。提供されたＵＥの位置情報に基づいて、ＬＧＷは、上記説明したのと同様の方法により、ＵＥによってアクセスされるターゲットローカルネットワーク（ＬＩＡかＲＩＡ）を選択し、そのローカルネットワークへＵＥの接続のための経路を構築する。すなわち、ハンドオーバがＲＩＡへＵＥの接続を切り替える場合、ＬＧＷはＲＩＡ接続のためのローカルネットワークを選択し、ＬＩＡへのハンドオーバの場合、ＬＧＷはＬＩＡ接続のためのローカルネットワークを選択し、ＵＥの適当な接続のため経路構築を行う。

ＵＥのＬＩＡ接続の構築の間、ＬＧＷがＬＩＡ接続用ローカルネットワークに対してＵＥのＬＩＡ接続用パスを構築したが、所定時間経過してもＨｅＮＢから最適経路が確立されない（すなわち、最適経路確立処理が開始されない）ときや、他ノードからの指示を受けたとき、ＬＧＷは先に構築したＬＩＡ接続用パスを解消し、ＲＩＡ接続用ローカルネットワークへのＲＩＡ接続用パスを構築する（ＵＥ向けのパスをＬＩＡ接続用からＲＩＡ接続用に切り替える）。このとき、ＬＧＷがＲＩＡ接続用ローカルネットワークへのパスを確立できない場合（例えば、ＬＧＷがＲＩＡ接続用ローカルネットワークに接続することができない場合や、そのＬＧＷはＲＩＡ接続用ローカルネットワークに接続できるが、ＵＥがＲＩＡ接続用ローカルネットワークへのアクセスあるいはＲＩＡ接続が許可されていない場合など）、ＬＧＷはその指示（ＵＥによる接続）を拒否して、処理を終了する。また、そのＬＧＷはＲＩＡ接続用ローカルネットワークに接続できないが、他にＲＩＡ接続用ローカルネットワークに接続できるＬＧＷを知っている場合（データベース問い合わせや、事前設定によって）、ＬＧＷリロケーション処理を実施してもよい。具体的には、ＬＧＷは、ＳＧＷを介してＭＭＥにリロケーション要求（切替先ＬＧＷのアドレス等の情報を含む）を送信し、ＭＭＥがＵＥのＥＰＳベアラを切替先のＬＧＷに向けて確立し、それまでのＬＧＷとの間のＥＰＳベアラをリリースする。なお、他ノードからの指示とは、例えばＭＭＥやＨｅＮＢからのＬＧＷリロケーション指示（あるいは要求）である。

サービス内容がアレンジ（変更又は修正）されると、それに伴って追加のサービス承認や、追加のアクセス認証かつ／又は認証／承認の再構成が要求されたりする場合がある。特に、ＲＩＡ接続の場合、より厳格性を問われる承認や付加的な認証が、アタッチ、サービスリクエスト、ＲＩＡ接続を構築又は切り替えるハンドオーバ手続きの間に行われ得る。そのような承認／認証はユーザパスワード、アクセスクレデンシャル、セキュリティトークンなどを必要とされることがある。さもなければ、アタッチ手続きの間に要求されるＳＩＭデータやサブスクリプションデータ利用に基づくＵＥ認証手続きが、特にハンドオーバ等でＬＩＡ接続からＲＩＡ接続に切り替わる際に、あらためて実施される。

また、ＬＧＷ、ＰＧＷ、又はＰＣＲＦ（Policy and Charging Rules Function）は、課金データの収集ポリシをＲＩＡ接続とＬＩＡ接続で変更してもよい。例えば、オペレータコアネットワークリソースをより消費する傾向にあるＲＩＡ接続をＬＩＡ接続より高いレートで課金するポリシを適用する。ここで、ＬＧＷ又はＰＧＷは、ＬＩＡ接続からＲＩＡ接続への切り替えをＳＧＷに通知（あるいはＳＧＷが自発的にそれらの切り替えを検出）して、ＵＥのＲＩＡ接続時の課金データの収集をＳＧＷにて実施してもよい。なお、課金ポリシとルールは、ＬＩＡ／ＲＩＡ接続の切替時にＰＣＲＦから取得したり、ＵＥのサブスクリプションデータ等に事前に設定されたポリシを使用したりする。

これにより、システムがサービス内容やケーパビリティ等を切り替えることが可能となり、ユーザに様々なサービスやアプリケーションを提供することができる。このことは、サービスプロバイダあるいはアプリケーションプロバイダの利便性を保証し、最終的にユーザの利便性向上にも貢献するものである。

他のケースでは、ＬＧＷは、ローカルネットワークへの接続に関しＵＥの位置に基づいて適当に選択される。ＵＥが接続要求（Attach Request、Service Requestなど）をすると、ＭＭＥは要求を受信し、ＵＥを収容するＰＧＷを選択する。ＭＭＥはＵＥコンテキスト（例えば、MM context）、サブスクリプションデータ、ローカルデータなどに基づいて、ＭＭＥは、構築される接続がＬＩＡ、例えばＬＩＡ接続可能な基地局（例えば、ＨｅＮＢ）やＣＳＧセルを介する接続か、又はＬＩＡ接続不可能な基地局やＣＳＧセルを介する接続かを検出する。その接続がＬＩＡ接続と検出されると、ＭＭＥは、ＬＩＡ接続用ＬＧＷ（例えば、ＬＧＷ１）に接続を有するＰＧＷを割り当てる。一方、ＲＩＡ接続と検出されると、ＭＭＥは、ＲＩＡ接続用ＬＧＷ（例えば、ＬＧＷ２）を割り当てる。ＭＭＥは、双方のケースにおいて、ＬＩＡ接続用とＲＩＡ接続用のＬＧＷ（例えば、ＬＧＷ３）に接続を有する他のＰＧＷを割り当ててもよい。この場合、上述したように、ＬＧＷ３は、ＵＥのローカルネットワークへの接続に関し適したローカルネットワークをさらに選択する。

あるいは、ＭＭＥがＡＰＮ（例えば、ＬＩＡ−ＡＰＮ）からＬＧＷアドレスを導出する際に、ＵＥの位置情報を付加して名前サーバ（例えば、ＤＮＳ：Domain Name Server）に問い合わせてもよい。例えば、ＵＥの位置情報（例えば、(E)CGI、CSG ID、TAI、RAI、LAIなど）は、ＵＥのローカルアクセス（ＬＩＡ）又はリモートアクセス（ＲＩＡ）のＰＧＷのＦＱＤＮを構成するＡＰＮストリングの最後、最初、又は中間に付加され得る。名前サーバは、ＬＧＷ、例えばＬＩＡ又はＲＩＡのローカルネットワークへ接続するＬＧＷへの接続又は接続可能性を有するＰＧＷのアドレスを提供する。名前サーバは、ＬＧＷ又はＲＩＡ接続のＬＧＷに接続している又は接続可能性のあるＰＧＷのエントリを含むデータベースを既に有しており、また最適化方法、例えば複数のエリアを結合するアグリゲートエリアで記述され得るＬＩＡ−ＡＰＮと位置情報を含むＦＱＤＮを有している。

さらには、ＰＧＷは、ＡＰＮ（ＬＩＡ−ＡＰＮ）とＵＥの位置情報、例えばＡＰＮとＵＥの位置情報又は（E）CGI、TAIなどの位置ＩＤを含むＦＱＤＮからターゲットＬＧＷに問い合わせてもよい。また、ターゲットＬＧＷの情報は、静的又は動的データ、例えばＨＳＳ又はＡＡＡサーバでのサブスクリプションデータとして提供され、ターゲットＬＧＷのＩＤは、位置ＩＤごとに定義され得る。ターゲットＬＧＷが選択されると、ＵＥのベアラ（例えば、ＥＰＳベアラ、ＰＤＰコンテキストなど）又はＰＤＮ接続はＰＧＷでターゲットＬＧＷにバインドされる。

さらに、ＭＭＥは、適したＬＧＷに接続を有するＰＧＷのアドレス又は識別子（例えば、ＦＱＤＮ）について、接続構築の要求又はハンドオーバの要求を通じて基地局（例えば、ＨｅＮＢ、ｅＮＢ）に問い合わせてもよい。基地局が、ＬＩＡ接続のＬＧＷの情報、かつ／又はＬＩＡ接続のＬＧＷと接続を有する又は接続可能性を有するＰＧＷの情報を有している場合、基地局はＭＭＥにＰＧＷのアドレス又は識別子を提供する。また、基地局が、ＲＩＡ接続のＬＧＷの情報、かつ／又はＲＩＡ接続のＬＧＷと接続を有する又は接続可能性を有するＰＧＷの情報を有している場合、基地局はＭＭＥにＰＧＷのアドレス又は識別子を提供する。さもなければ、基地局は何も応答しない。ＰＧＷの識別子（例えば、ＦＱＤＮ）が基地局から提供されると、ＭＭＥはＰＧＷアドレスを取得するために名前サーバ（例えば、ＤＮＳサーバ）に識別子を問い合わせる。基地局から何も情報を提供されない場合、ＭＭＥは名前サーバを通じてＬＩＡ−ＡＰＮを利用してＰＧＷアドレスを取得する。

また、基地局が、接続先となる（ターゲット）ローカルネットワーク種別、例えば、構築されるＵＥのＬＩＡ接続を示すＬＩＡ指示情報（LIA indication）又は構築されるＵＥのＲＩＡ接続を示すＲＩＡ指示情報（RIA indication）をＭＭＥに指示してもよい。ＭＭＥは、ＳＧＷを介してＰＧＷに送信されるCreate Bearer Requestにいずれかの情報を含め、ＰＧＷはＬＧＷにその指示情報を転送し、指示情報を確認し、適したローカルネットワーク、例えば、ＬＩＡ指示情報を受信したときにはＬＩＡのローカルネットワーク、ＲＩＡ指示情報を受信したときにはＲＩＡのローカルネットワークへの経路を構築する。ＭＭＥは、シグナリング内でのオーバヘッドを減らすためにいずれかの指示情報を送信することを省くことも可能である。例えば、ＲＩＡ又はＬＩＡ指示情報のいずれかのみが送信される。

これらの指示情報は、ＭＭＥ又はＰＧＷが上述した実施の形態（第１から第１６の実施の形態）で説明したようにＬＩＡ接続が構築され得るかどうかを検出する際に、ＭＭＥ又はＰＧＷによって生成され、メッセージ内に含めてもよい。また、ＨｅＮＢは、ＬＩＡ接続が構築され得るかどうかをアタッチ、サービス要求、又はハンドオーバの手続きの間に検出する場合、ＭＭＥに指示情報を送信するものであってもよい。

さらには、例えば、確立された接続の種別（ＬＩＡ接続又はＲＩＡ接続）、又は接続したローカルネットワークの種別（ＬＩＡ接続用又はＲＩＡ接続用）を、ＵＥに通知してもよい。ＵＥへの通知は、ＭＭＥ、ＬＧＷ、ＨｅＮＢのいずれかのノードによって、アタッチ手続き、サービス要求手続き、ハンドオーバ手続きのいずれかの中で実施する。ＡＰＮは、手続きの間、ＵＥへのメッセージ内で情報として用いられてもよい。例えば、接続の種別（ＬＩＡ接続又はＲＩＡ接続）又はローカルネットワークの種別（ＬＩＡ接続用又はＲＩＡ接続用）を示す情報又は識別子が、ＦＱＤＮの一部としてＡＰＮストリングに付加されてもよい。さもなければ、接続の種別を表示するための指示フラグが、手続きの間、ＵＥへのメッセージ内に用いられてもよい。これにより、ＵＥは、接続の種別又はローカルネットワークの種別に応じてＬＩＡ接続（例えば、ＥＰＳと無線ベアラ）のＱｏＳ設定を調整（変更又は修正）する、例えばＬＩＡ接続をよりよい品質に向けることができたり、接続の種別又はネットワークの種別に応じて設定を調整する、例えばアプリケーションサーバのアドレスを変更するために、アプリケーションに通知することができたりする。

なお、ＬＧＷは、ＵＥから／への最後のトラフィックの後、一定の期間、ＵＥから／へのトラフィックがないと検出すると、ＬＧＷは、その接続をＬＩＡからＲＩＡへ切り替えてもよい。すなわち、ＬＧＷは、ＬＩＡ接続用ローカルネットワークの経路を解放し、ＲＩＡ接続用ローカルネットワークの経路を構築する。これによって、悪意のある者がＬＩＡ用ローカルネットワークにアクセスし、ＵＥを用いて機密データや機密情報を取得するという企業内部でのＵＥの悪用を回避することができる。この場合、例えばユーザＩＤとパスワードを用いる認証手続きでは、ＬＩＡ接続を再開させるために要求されるものであってもよい。

また、ＵＥのＬＩＡ接続に対する最適パスを有する基地局（例えば、ＨｅＮＢ）が、ＵＥのＬＩＡ接続の無線ベアラがリリースされた（ただし、ＥＰＳベアラは残る）ことを検出すると、基地局は、そのＵＥに関するＬＩＡ接続をＲＩＡ接続に切り替えることをＬＧＷに指示してもよい。そして、ＬＧＷはＬＩＡ接続からＲＩＡ接続への接続を切り替える。あるいは、ＭＭＥは、ＭＭＥがＵＥのアイドルモード（idle mode）遷移を検出したとき（さもなければ、ＬＧＷがＵＥのアイドルモード遷移について暗黙の指示を受け、自身が認めた場合）に、ＬＩＡ接続からＲＩＡ接続へ接続を切り替えることをＬＧＷに指示してもよい。そして、ＬＧＷはＬＩＡ接続からＲＩＡ接続に接続を切り替える。

この実施の形態では、本発明の説明を簡単にするためＨｅＮＢを含むＬＴＥアーキテクチャの一例について記載したが、本発明は、ＵＭＴＳあるいはＧＰＲＳなどの他のアーキテクチャにも同様に適用することができる。そのような場合（ＵＭＴＳあるいはＧＰＲＳアーキテクチャの場合）、ＨｅＮＢ、ＳＧＳＮ、ＰＤＰコンテキストは、ＨｅＮＢ、ＭＭＥ、ＥＰＳベアラそれぞれの代わりに用いられる。

なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（ラージ・スケール・インテグレーション：Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（インテグレイティド・サーキット：Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（フィールド・プログラマブル・ゲート・アレイ：Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。

本発明は、ＨＮＢ又はＨｅＮＢによって行われる理にかなった切り替えを通じて、ユーザのローカルデバイスアクセストラフィックに用いられるルートの管理に好都合である。そのため、本発明は、移動通信システムにおけるローカルデバイスへのアクセス管理に有利である。

Claims (7)

1. ローカルＩＰネットワークにアクセスしているＵＥのプロキシとして機能するホーム基地局における装置であって、
   通信チャンネルの確立時にＰＧＷと前記ホーム基地局との間の前記通信チャンネルを識別するトークンを生成し、前記トークンを前記ＰＧＷへ送信するトークン生成部と、
   ＭＭＥを介してＰＧＷから送信された前記トークンを検証し、最適化経路を確立させるかどうかを決定する決定部と、
   前記ホーム基地局と前記ローカルＩＰネットワークとの間の前記最適化経路を確立し、前記ＵＥから受信したパケットを前記最適化経路を用いて前記ローカルＩＰネットワークへ転送するプロキシ機能と、
   前記決定部が前記最適化経路を確立させると決定するときに前記プロキシ機能を起動させる起動部とを、
   備える装置。
2. 前記プロキシ機能が、
   インターセプトフィルタと、ＵＥ ＩＤマッピング部と、トンネル管理部との構成要素を備える請求項１に記載のホーム基地局における装置。
3. 前記ローカルＩＰネットワークへＩＰアドレス要求を送信し、前記ローカルＩＰネットワーク内の前記ＩＰアドレスを取得する取得部と、
   前記取得したＩＰアドレスを前記ＵＥへ送信する送信部とを、
   更に備える請求項１に記載のホーム基地局における装置。
4. 前記ＵＥが前記ホーム基地局と異なる基地局に無線接続されているときに前記送信部が前記取得したＩＰアドレスを前記通信チャンネルを用いて前記ＰＧＷと前記ＭＭＥとを介して前記ＵＥへ送信する請求項３に記載のホーム基地局における装置。
5. ローカルＩＰネットワークにアクセスしているＵＥのプロキシとして機能するホーム基地局における経路最適化方法であって、
   通信チャンネルの確立時にＰＧＷと前記ホーム基地局との間の前記通信チャンネルを識別するトークンを生成し、前記トークンを前記ＰＧＷへ送信するトークン生成ステップと、
   ＭＭＥが前記ＰＧＷから前記トークンを受信した後、前記ＭＭＥから送信された前記トークンを検証し、最適化経路を確立させるかどうかを決定する決定ステップと、
   前記決定ステップで前記最適化経路を確立させると決定するときにプロキシ機能を起動させる起動ステップと、
   前記プロキシ機能の起動により、前記ホーム基地局と前記ローカルＩＰネットワークとの間の前記最適化経路を確立し、前記ＵＥから受信したパケットを前記最適化経路を用いて前記ローカルＩＰネットワークへ転送する転送ステップとを、
   有する経路最適化方法。
6. 前記最適化経路が確立されているか否かにより、前記ＵＥが前記ローカルＩＰネットワークに接続している方法を前記ＵＥに示す指示ステップを更に有する請求項５に記載のホーム基地局における経路最適化方法。
7. 前記ホーム基地局に無線接続された前記ＵＥが前記ホーム基地局と異なる基地局へハンドオーバを実行するときに、前記プロキシ機能を終了させるために前記プロキシ機能を起動させない不起動ステップを更に有する請求項５に記載のホーム基地局における経路最適化方法。