Nothing Special   »   [go: up one dir, main page]

JP5688016B2 - 通信システム、移動端末、ネットワークノード並びに基地局装置 - Google Patents

通信システム、移動端末、ネットワークノード並びに基地局装置 Download PDF

Info

Publication number
JP5688016B2
JP5688016B2 JP2011519536A JP2011519536A JP5688016B2 JP 5688016 B2 JP5688016 B2 JP 5688016B2 JP 2011519536 A JP2011519536 A JP 2011519536A JP 2011519536 A JP2011519536 A JP 2011519536A JP 5688016 B2 JP5688016 B2 JP 5688016B2
Authority
JP
Japan
Prior art keywords
communication
network
node
interface
mobile terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2011519536A
Other languages
English (en)
Other versions
JPWO2010146816A1 (ja
Inventor
平野　純
純 平野
モハナ ダマヤンティ ジャヤタラン
モハナ ダマヤンティ ジャヤタラン
ンー　チャン　ワー
チャン ワー ンー
チュン キョン ベンジャミン リム
チュン キョン ベンジャミン リム
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Priority to JP2011519536A priority Critical patent/JP5688016B2/ja
Publication of JPWO2010146816A1 publication Critical patent/JPWO2010146816A1/ja
Application granted granted Critical
Publication of JP5688016B2 publication Critical patent/JP5688016B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/14—Access restriction or access information delivery, e.g. discovery data delivery using user query or user detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

本発明は、インターネットプロトコル（ＩＰ：Internet Protocol）を利用した通信技術に係る通信システム、移動端末、ネットワークノード並びに基地局装置に関し、特に、ネットワークベースのローカルモビリティ管理ドメイン（Network based Local Mobility Management Domain）内で複数のインタフェースを有する移動端末に係る通信の効率化又は最適化を実現するための通信システム、移動端末、ネットワークノード並びに基地局装置に関する。
現在、多数のデバイスが、インターネットプロトコルを使用して、互いに通信を行っている。モバイル機器にモビリティサポートを提供するために、ＩＥＴＦ（Internet Engineering Task Force）では、下記の非特許文献１において、ＩＰｖ６におけるモビリティサポートが規定されている。
非特許文献１では、ホームネットワークにホームエージェント（ＨＡ：Home Agent）を導入することによって、モビリティサポートが実現される。モバイルノードは、外部リンクで取得した気付アドレス（ＣｏＡ：Care-of Address）をＢＵ（バインディングアップデート）メッセージを利用してホームエージェントに登録する。そして、ＢＵによって、ホームエージェントは、ホームリンクで取得される長期的なアドレスであるホームアドレス（ＨｏＡ）と気付アドレスとの間のバインディングを作成することが可能となる。
ホームエージェントは、モバイルノードのホームアドレスに向けられたメッセージを受信（intercept）し、パケットのカプセル化（あるパケットを新たなパケットのペイロードとすることであり、パケットトンネリングとしても知られている）を用いて、そのパケットをモバイルノードの気付アドレスに転送する機能を担っている。
ＭＩＰｖ６（Mobile IPv6）の問題の１つは、ネットワーク接続ポイントを変更するために、あるいは、バインディングのライフタイムが満了した場合に、ＭＮは、１つ以上のＨＡ及びＣＮ（Correspondent Node：コレスポンデントノード）にアップデートを行う必要がある点であり、特に高速で移動しているＭＮに関して、無線アクセスネットワークへのシグナリングの負荷が高くなる。さらに、ＣＮとの間で経路最適化（ＲＯ：Route Optimization）を使用している場合には、ネットワーク接続の変更時にＲＲ（Return Routability：リターンルータビリティ）やＢＵメッセージの送信を行う必要があり、ネットワーク接続の変更時の平均ハンドオフ時間が大きくなってしまう。
したがって、フローや接続に関連するセッションにおいて、ハンドオフ処理にかなりの時間が費やされ、その結果、メディアパケットに関するエンドトゥーエンドの遅延増大、ジッタやパケットロスが生じてしまう場合がある。このようなエンドトゥーエンドの遅延、ジッタ、パケットロスは、ボイスオーバＩＰ（ＶｏＩＰ）やマルチメディアストリーミング、ビデオストリーミングなどの即時性の高いアプリケーションにとっては好ましいものではなく、パケットロスは重要なテキスト／データ情報を伝送するフローにとって好ましいものではない。さらに、ＴＣＰ（Transmission Control Protocol：送信制御プロトコル）を利用してセッションを確立するデータアプリケーションにおいても、パケットロスによって、特に無線アクセスネットワークにおけるＴＣＰのスループットや帯域効率が低下してしまう。
このようなＭＩＰｖ６の問題を解決するため、現在、ネットワークベースのローカルモビリティ管理（ＮｅｔＬＭＭ：Network-based Local Mobility Management）プロトコルが注目されている。ネットワークベースのローカルモビリティ管理プロトコルでは、少なくともローカルドメインにおいて、ＭＮのシグナリングに関する問題は完全に解消される。さらに、こうしたネットワークベースのメカニズムによって、ＭＮが同一プレフィックスであることを確実に確認できるようにすることで、ハンドオフ処理による遅延も低減されるようになる。ネットワークベースのメカニズムでは、ＭＮはＣＮに対してアドレス更新を行う必要がなく、ローカルモビリティアンカ（ＬＭＡ）において実行されるネットワークベースのシグナリングによって、ＭＮの到達性は維持される。
ＩＥＴＦのネットワークベースのローカルモビリティ管理（ＮｅｔＬＭＮ）ワーキンググループでは、ＭＮに透過（トランスペアレント：transparent）な方法でモビリティ管理が実行されるネットワークベースの方法を用いて、ＭＮに対するモビリティ管理を提供するためのプロトコルが開発されている。ネットワークベースのローカルモビリティ管理は、トポロジカルに局在するネットワークセグメント内のノードのモビリティを、モバイルノード自体ではなくネットワークエンティティが管理することである。ＭＮに透過なネットワークベースのモビリティ管理の目的を達成するためには、ＭＮはローカルドメイン内で同一プレフィックスを確認できる必要がある。このプレフィックスは、ローカルモビリティ管理による利益が得られるように、ルーティング階層の高い位置（望ましくは、ローカルドメイン内のすべてのＭＮのデフォルトルーティングパス上）に存在するルータから得られる必要がある。このプレフィックスの基点（root）となるルータは、このプレフィックス（プレフィックスベースの経路）への到達性に関する情報を有する必要があり、最終的に、このプレフィックスベースの経路がネットワークエンティティによって作成される必要がある。
ＮｅｔＬＭＭワーキンググループによって標準化されたネットワークベースのローカルモビリティ管理プロトコルは、プロキシモバイルＩＰｖ６（ＰＭＩＰｖ６：Proxy Mobile IPv6）であり、下記の非特許文献２に開示されている。ＰＭＩＰｖ６は、主に、通常のＩＰｖ６ホスト（クライアントモバイルＩＰｖ６（ＣＭＩＰｖ６：Client Mobile IPv6）スタックを持たない）に対してネットワークの局所的な場所におけるモビリティ管理サービスを提供するよう設計されたものである。なお、ＣＭＩＰｖ６は、非特許文献１に開示されているＭＩＰｖ６（Mobile IPv6）、及びＭＩＰｖ６をＩＰｖ４対応とするために拡張された、非特許文献６に開示されているＤＳＭＩＰｖ６（Dual Stack Mobile IPv6）によって実現される。例えば、ＭＮが外部ＰＭＩＰｖ６ドメインに存在し、あるインタフェースを経由してローカルドメインにおける同一プレフィックスを確認する場合、ＭＮは、１つ又は複数のホームエージェント、あるいは、１つ又は複数のＣＮに対してグローバルなバインディング登録を行う必要がない。これは、ＣＭＩＰｖ６スタックを有するノードにとっても有用である。さらに、モビリティ管理能力を有するＭＮがホームドメインへ移動した場合においても、ＭＮは、ホームネットワークプレフィックス／ホームプレフィックスを確認し続けることができるので、位置登録を実行する必要はない。
ＰＭＩＰｖ６の仕様に従えば、ＬＭＡ（Local Mobility Anchor：ローカルモビリティアンカ）は、２つの機能を有している。すなわち、ＬＭＡは、ＰＭＩＰｖ６動作及びＭＩＰｖ６動作の両方をサポートしている。なお、ＬＭＡがＨＡとしての機能を持ち得ることから、以降では、ＬＭＡをＬＭＡ／ＨＡと記載することもある。ＰＭＩＰｖ６において、ＭＮがＰＭＩＰｖ６ドメインに接続した場合、ＭＮは、ＭＡＧ（Mobile Access Gateway：モバイルアクセスゲートウェイ）に対して、接続中のネットワークアクセス識別子（ＮＡＩ：Network Access Identifier）を提供する。なお、ＭＡＧは、直接接続しているＭＮ、あるいは、管理下にあるＭＮに代わって、ローカルモビリティアンカへプロキシローカル登録を行うルータである。また、ＮＡＩは、認証のために、ＡＡＡ（Authentication, Authorization and Accounting：認証、認可、課金）サーバへ渡される。
ＡＡＡは、ＭＮのネットワーク接続を認証すると、認証成功を通知する応答をＭＡＧへ送信する。さらに、ＡＡＡは、ＬＭＡアドレス及びある特定のＭＮのプロファイル（例えば、アドレス構成モードやＭＮがローカルドメインを移動する間にＭＮに対して実施される必要のある特別なポリシ）をＭＡＧへ提供する。ＭＡＧは、これらのＭＮのパラメータを取得すると、プロキシＢＵ（ＰＢＵ：Proxy BU）をＬＭＡへ送信する。ＭＡＧは、プロキシバインディング応答（ＰＢＡ：Proxy BA）によって、接続しているＭＮのインタフェースに関連付けられているユニークなプレフィックスを取得した後、ホームリンク又はローカルホームリンク（もし訪問ドメインであれば）の役割を実行する。ＭＡＧによって実行されるＰＢＵ（あるいはローカル登録）は、これがプロキシＢＵであることを示す「Ｐ」フラグを除いてＭＩＰｖ６のＢＵと同一である。
ＰＢＵを実行することによって、ＭＮに関する到達可能状態（reachability）がＬＭＡに作成される。基本的に、ＬＭＡは、ＰＭＩＰｖ６ドメインで取得されるＭＮのユニークなプレフィックス（各ＭＮに固有のプレフィックス）に関する到達可能状態を有する。このユニークなプレフィックスに関連した到達可能アドレスはＭＡＧのアドレスである。ＭＮは、ステートフル又はステートレスのアドレス構成モードを使用して、ＰＭＩＰｖ６ドメインにおいて受信したユニークなプレフィックスを使用してアドレスを構成する。各ＭＮがユニークなプレフィックスが取得するので、ＬＭＡにおけるプレフィックスに基づくキャッシュによって、ＭＮは到達可能な状態となる。
また、ＬＭＡに届くすべてのデータパケットは、ＭＮへ接続されているＭＡＧへトンネルされ、逆に、ＭＮからＭＡＧに届くすべてのデータパケットは、ＬＭＡへトンネルされる。ＭＡＧの近隣キャッシュテーブルには、ＭＮのＰＭＩＰｖ６ローカルアドレスと、ＭＮへパケットを伝送するために使用されるそのリンクレイヤアドレスとのバインディングが含まれている。このＰＭＩＰｖ６ローカルアドレスは、ローカルドメインでＭＮへ提供されるユニークプレフィックスから得られるアドレスである。
非特許文献２に開示されているＰＭＩＰｖ６は、透過なプロキシモビリティサービスを提供することに加えて、マルチホーミングサポートも提供する。ここでは、複数インタフェースのＭＮ（マルチインタフェースＭＮ）はすべてのインタフェースを介してＰＭＩＰｖ６ドメインに接続可能である。このとき、ＭＮは、プロトコルスタックのレイヤ３のプロトコルでの変更を必要とせず、モビリティ関連シグナリングを実行せずにドメイン内を移動することが可能である。基本的に、マルチホーミングは、ＬＭＡがＭＮのインタフェースごとにユニークなプレフィックスを提供して、ＭＮのインタフェースに関連するＰＭＩＰｖ６バインディングを独立したモビリティセッションとして維持することによってサポートされる。ＰＭＩＰｖ６マルチホーミングプロトコルは、最初の接続の際にインタフェースごとにユニークなプレフィックスを割り当てることに加えて、完全に透過なモビリティ管理を提供するために、提供したプレフィックス及びこれらのプレフィックスを使用して確立されたセッションを、複数インタフェースのＭＮがローカルドメイン内を移動する際にセッション品質（ＱｏＳ：Quality of Service）に障害をもたらすことなく維持する必要がある。
また、ＩＥＴＦのモビリティ拡張（ＭＥＸＴ：Mobility Extensions）ワーキングショップにおいても、マルチホーミングサポートが議論されている。このワーキングショップの課題は、モバイルノードが、単一又は複数のインタフェースを使用して異なる気付アドレスを構成することであり、さらに、すべてのインタフェース又は気付アドレス経由で単一の長期アドレス（ホームアドレス）あてのパケットを受信できるようにすることである。この方法の詳細は、下記の非特許文献３に説明されている。
この非特許文献３に開示されている技術は、３ＧＰＰ（第３世代パートナーシッププロジェクト：3rd Generation Partnership Project）に関連している説明されているが、この技術は他の公衆ネットワーク（例えば、３ＧＰＰ２、ＷｉＭＡＸフォーラム、広帯域フォーラムなど）にも適用可能である。
３ＧＰＰでは、例えばＷＬＡＮ（ワイヤレスローカルエリアネットワーク）、セルラネットワーク、第３世代ネットワーク（３Ｇネットワーク）、ワイアレスＷＡＮ（ワイドエリアネットワーク）などを始めとする様々なタイプの無線アクセスネットワーク（すなわち、ＥＰＣ（拡張パケットコアネットワーク：Evolved Packet Core network）に接続可能なすべてのネットワーク）を有するグローバル異種アーキテクチャへの適用が模索されている。
このグローバル異種アーキテクチャは、一般に、ＰＬＭＮ（パブリックランドモバイルネットワーク：Public Land Mobile Network）と呼ばれ、垂直ハンドオフ処理時や異なるアクセス技術を通じた同時アクセス時のシームレスなモビリティを実現するために有用である。また、非常に高いＱｏＳを有する異種タイプのアプリケーションサービス（例えば、リアルタイムビデオ、ＶｏＩＰ、情報クリティカルデータなど）をサポートするために有用である。
非特許文献３には、３Ｇアクセスネットワーク経由のＭＮによる接続に関して、ＰＭＩＰｖ６が、ＧＰＲＳ（General Packet Radio System）トンネリングプロトコル（ＧＴＰ）であることに加えてモビリティを管理する主要なモビリティ管理プロトコルであることが開示されている。３Ｇアクセスを通じたＭＩＰｖ６の使用は制限され、ホームに戻った際やＨＡとのセキュリティアソシエーションを得るために動的なブートストラッピング機能を実行する際に登録解除のＢＵを送信するためにのみ使用される。ＭＮは、例えばＷｉＭＡＸアクセスやＷＬＡＮアクセスなどの他のアクセス経由することで、ＭＩＰｖ６、ＰＭＩＰｖ６あるいはＭＩＰｖ４を使用することが可能である。例えば、ＭＮがＷｉＭＡＸ経由で３ＧＰＰコアネットワークへ接続する際のモビリティ管理メカニズムは、ＭＩＰｖ４、ＭＩＰｖ６、あるいはＰＭＩＰｖ６であってもよく、ＭＮがＷＬＡＮアクセス経由で３ＧＰＰコアへ接続する際のモビリティ管理メカニズムは、ＭＩＰｖ６又はＰＭＩＰｖ６であってもよい。モビリティ管理メカニズムがこうした広範囲の技術が利用可能であっても、システムには、そのときにあるアクセス技術タイプ経由で特定のモビリティ管理メカニズムを使用するという制限が課せられる。
将来的には、複数の異種タイプインタフェースを有するＭＮが、３ＧＰＰネットワーク内を移動し、異なるタイプのインタフェース経由で同時接続を行って、マルチホーミングの利益（例えば、負荷共有、負荷バランス、フォールトトレランス、到達可能性、プレファレンス設定）を得る必要があるであろう。なお、このとき、インタフェースのモビリティは異なるモビリティ管理プロトコルによって管理されるかもしれない。
ＭＩＰｖ６（すなわちＣＭＩＰｖ６）及びＰＭＩＰｖ６の２つの主要なモビリティ管理プロトコルが存在しているので、３ＧＰＰでは、将来、これらのプロトコルが混在して展開されることになるであろう。例えば、あるアクセスドメインでは、複数インタフェースのＭＮがすべてのインタフェースの管理を行い、また、あるアクセスドメインでは、複数インタフェースのＭＮのモビリティは、ＰＭＩＰｖ６メカニズムを使用するネットワークによって完全に取り扱われることになる。また、いくつかのアクセス領域で可変的に、複数インタフェースのＣＮのあるインタフェースのモビリティがネットワークによって管理され、別のインタフェースのモビリティはＭＮ自身によって管理されることになる。このような異なる管理は、経路最適化に基づくＭＮのプレファレンス、及び／又は、負荷バランスに基づくネットワークによるプレファレンスなどによって行われる。
非特許文献３に開示される３ＧＰＰでは、特定のアクセス技術経由でＭＮのネットワーク接続に関するモビリティ管理メカニズムが、静的な構成方法又は動的な構成方法によって決定されてもよい。静的な構成方法においては、例えば、モバイルノードの特定のインタフェースに関連するモビリティ管理モードが事前に構成されていてもよく、ＭＮが、この情報を事前に把握しているか、あるいは、接続の際にネットワークがこの情報を通知して、モビリティモードのタイプの決定を変更できないようにしてもよい。あるインタフェース経由での特定のモビリティモードは、アクセス技術タイプ及びローミング協定に基づいて決定される。一方、動的な構成モードが使用される場合には、ＭＮ又はユーザ端末（ＵＥ：User Equipment）は、特定のアクセスネットワークに接続されているインタフェース経由で使用される好適なモビリティモードを交渉することが可能である。なお、本明細書では、ＵＥ及びＭＮの用語は互換性を有し、両方共、移動端末を示している。
米国特許公開２００４／０２１３１８１ 米国特許公開２００５／００８８９９４ 米国特許公開２００８／０２８５５１８ 国際公開公報ＷＯ２００７／１３７７６５ 国際公開公報ＷＯ２００８／１０４１３２ 国際公開公報ＷＯ２００８／１３４３９４ 米国特許公開２００８／０２８５４９２ 国際公開公報ＷＯ２００９／０９７９１４ 国際公開公報ＷＯ２００９／０８４９８９
Johnson, D. B., Perkins, C. E., and Arkko, J., "Mobility Support in IPv6", Internet Engineering Task Force Request For Comments 3775, June 2004. Gundavelli, S., et. al., "Proxy Mobile IPv6", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 5213, August 2008. "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402, V8.3.0, September 2008. Wakikawa, et. al., "Multiple care-of addresses Registration", Internet Engineering Task Force Draft: draft-ietf-monami6-multiplecoa-10.txt, November 2008. Hinden, et. al., "IPv6 Global Unicast Address Format", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 3587, August 2003. Soliman, et. al., "Mobile IPv6 Support for Dual Stack Hosts and Routers", Internet Engineering Task Force (IETF) Internet Engineering Task Force Request For Comments 5555, June 2009.
従来の技術によれば、ＵＥがＣＮとの効率的な通信（経路最適化又はシグナリングメッセージを低減させる効率的なモビリティ管理）を実現するために、どのインタフェースを使用すべきかを選択するために十分な情報を持っていないという問題がある。具体的には、従来の技術によれば、ＵＥがＣＮと通信するための正しいインタフェース又はモビリティモードを選択する際に、ＵＥがＣＮの場所や、ＣＮの状態（ＣＭＩＰｖ６状態、ＰＭＩＰｖ６状態、静的なモビリティ構成モード、動的なモビリティ構成モードなど）を特定し、こうした情報に基づいて、ＵＥが使用すべきインタフェースの選択を行うことができないという課題がある。
以下、複数インタフェースのＣＮ（マルチインタフェースＣＮ）がアクセスネットワーク経由して３ＧＰＰ ＥＰＣに接続されており、あるインタフェース経由で特定のモビリティ管理メカニズムを使用するよう制限されている場合における問題について説明する。
以下、図１Ａ及び図１Ｂを参照しながら、この問題について説明する。この問題が生じる原因は、主に、ＭＮがＣＮの正確な場所を把握しておらず、ＣＮとの通信にどのインタフェースを使用して経路最適化及び効率的なモビリティ管理を実現すべきかを確実に把握できないことにある。
なお、効率的なモビリティ管理は、ＣＮとの間で行うシグナリングの量を少なくするようにＣＮとのデータ通信を行うことを意味している。本明細書では、ＣＮはＲＲを実行する機能を有しており、さらに、ＭＩＰｖ６スタックを実装していると仮定し、ＣＮが単純なＩＰｖ６ホストである場合にはその旨を説明する。
図１Ａでは、ＵＥ１０４はアクセスネットワーク１０３及びアクセスネットワーク１０２を経由してＥＰＣ１００へ接続可能な２つのインタフェースを有している。アクセスネットワーク１０３は、例えばＬＴＥ（Long Term Evolution）ネットワークなどの３Ｇアクセスネットワークであり、アクセスネットワーク１０２は、例えばＷｉＭＡＸアクセスネットワークである。さらに、ＵＥ１０４は、アクセスリンク１０５によってＳ−ＧＷ（Serving Gateway：サービングゲートウェイ）１０８へ接続されており、また、アクセスリンク１０６によってアクセスゲートウェイ（ＡＧＷ：Access Gateway）１０９に接続されているものとする。
さらに、Ｓ−ＧＷ１０８及びＡＧＷ１０９は共に、ＭＡＧの機能が実装されているとする。また、Ｐ−ＧＷ１１１は、ＵＥ１０４のモビリティを管理するモビリティアンカである。Ｐ−ＧＷ（ＬＭＡ／ＨＡと記載することもある）１１１は、上述のＬＭＡ／ＨＡとほぼ同一の機能を有しており、ＵＥ１０４のモバイルＩＰｖ６ホームエージェントであるとする。
また、ＵＥ１０４は、ＭＩＰｖ６ホームアドレスを１つ構成しているとする。なお、このホームアドレスは、例えば、Ｐ−ＧＷ１１１から動的なブートストラッピングメカニズム、又は、任意の他のアクセス技術特有のメカニズムを使用して得られたものである。
ＵＥ１０４のモビリティは、３Ｇインタフェースに関してはＰＭＩＰｖ６メカニズムによって管理されており、ＷｉＭＡＸインタフェースに関してはＣＭＩＰｖ６メカニズムによって管理されている。また、ＵＥ１０４の各インタフェースに割り当てられているモビリティ管理モードは変更不可能であり、静的であるとする。すなわち、３ＧＰＰにおけるモビリティモード割り当ての静的な構成により、ＵＥ１０４は、ＵＥ１０４の各インタフェースに割り当てられているモビリティモードを変更することはできない。３Ｇインタフェースを通じて確認できるホームネットワークプレフィックス（すなわち、ＰＭＩＰｖ６モードで割り当てられたプレフィックス）は、ＵＥ１０４のＭＩＰｖ６ホームプレフィックスである。また、ＬＭＡ／ＨＡ１１１は、マルチホーミング機能を有しており、ＰＭＩＰｖ６バインディング及びＣＭＩＰｖ６バインディングの両方を維持することが可能である。さらに、ＬＭＡ／ＨＡ１１１は、等しい優先度又は重み付け条件を課してプレフィックスベースの検索（ＰＭＩＰｖ６キャッシュ）及びアドレスベースの検索（ＣＭＩＰｖ６キャッシュ）を行い、ＵＥ１０４へパケットを発送することが可能である。
ＵＥ１０４がＷｉＭＡＸインタフェースに関してＬＭＡ／ＨＡ１１１にＣＭＩＰｖ６登録を行うと、ホームタイプ及びアウェイタイプのバインディングが同時に使用されるようになる。ＵＥ１０４は、非特許文献４に説明されているＭｏＮＡＭＩ６（Mobile Nodes and Multiple Interfaces in IPv6）機能を用いてＣＭＩＰｖ６を実行することが可能であると考えられる。しかしながら、当業者であれば、ＬＭＡ／ＨＡ１１１に同時バインディングを行う代わりに、ＵＥ１０４が、Ｐ−ＧＷ１１１にＣＭＩＰｖ６登録を行わずにＰ−ＧＷ１１１にＰＭＩＰｖ６バインディングを行うだけでよいことは明らかである。ＵＥ１０４は、単にＣＮと経路最適化を行うためにＷｉＭＡＸインタフェースを用いるだけで、同様のシナリオが実現される。
このような構成において、ＵＥ１０４は、ＣＮ１１２とデータ通信セッションを有しているとする。ＣＮ１１２は、ＰＭＩＰｖ６モード又はＣＭＩＰｖ６モードで動作可能である。なお、ドメイン１００はＣＮ１１２のホームドメインであってもよく、あるいはホームドメインでなくてもよい。あるノードがＰＭＩＰｖ６モビリティ管理モードを使用している場合、そのノードのホームドメインは、ホームネットワークプレフィックスを割り当てるＬＭＡが配置されているドメインである。また、あるノードがＣＭＩＰｖ６メカニズムを使用している場合、そのノードのホームドメインは、そのホームエージェントが位置するドメインである。
さらに、ＣＮ１１２では１つのインタフェースが起動されており、ＷｉＭＡＸインタフェースを使用しているとする。このＷｉＭＡＸインタフェースは、アクセスリンク１０７を使用してＡＧＷ１１０にリンクされている。ＣＮ１１２が接続されているＷｉＭＡＸアクセスネットワークは、図１Ａのアクセスネットワーク１０１によって示されている。
ドメイン１００がＣＮ１１２のホームドメインであり、モビリティがＰＭＩＰｖ６メカニズムによって管理されている場合、ＵＥ１０４は、ＣＮ１１２のアドレスを把握できるだけで、ＣＮ１１２が接続されている場所に関する情報を把握できず、大きな問題となる。ＣＮ１１２のＩＰｖ６アドレスのプレフィックス部とＵＥ１０４のＩＰｖ６アドレス（ホームアドレス）のプレフィックスとを単に比較するだけでは、ＣＮ１１２がＵＥ１０４と同一のドメインに配置されているかどうかを結論付けることは不可能である。
非特許文献５に開示されているようにルーティングプレフィックスの階層構造を参照した場合には、ＵＥ１０４は、ルーティングプレフィックスに関連した階層やプレフィックス分割を把握できないかもしれず、この比較では、ＣＮ１１２が同一のドメインに接続されているかどうかを判断することはできないかもしれない。このように、ＣＮ１１２がＵＥ１０４と同一のドメインに配置されているかどうかを判断するための情報がないことで、ＵＥ１０４が例えば３Ｇインタフェースを用いてＣＮ１１２へデータパケットを送信する場合には、データパケットのルーティングパスは、メッセージ１２６に示されているパスを経由することになる。すなわち、ＣＮ１１２へ送信されたデータパケットはＳ−ＧＷ１０８からＰ−ＧＷ１１１へトンネルされ、Ｐ−ＧＷ１１１でデカプセル化された後、さらにＡＧＷ１１０あてにカプセル化されてＣＮ１１２へ到達すると考えられる。
基本的に、このメッセージ１２６が辿るパスには２つの欠点がある。第１の欠点は、パケットが２回カプセル化されて２つのトンネルを通ることである。第２の欠点は、ＵＥ１０４及びＣＮ１１２のプレフィックスは両方共、Ｐ−ＧＷ１１１を基点としているので、データパケットはＰ−ＧＷ１１１を経由してルーティングされる必要があり、完全に最適ではない経路を通ることである。一方、ＵＥ１０４が、ＣＮ１１２と通信を行うために、ＣＭＩＰｖ６モードで動作しているＷｉＭＡＸインタフェースを使用した場合には、ＣＮ１１２もＣＭＩＰｖ６にモビリティモードを切り換えることができれば、データパケットのルーティングパスはいかなるタイプのトンネリングを受けることもなく、冗長なルーティングも行われないようになる。
また、様々なシナリオにおいて、ＣＮ１１２がＭＩＰｖ６を使用して、そのモビリティを管理しており、そのホームドメイン１００に接続されているのであれば、ＣＮ１１２へデータパケットを送信するために使用されるアドレスはＣＮ１１２の気付アドレスとなる（ＣＮ１１２との間でＲＯが実行されていれば）。ＵＥ１０４が３Ｇインタフェースを使用するのであれば、ＣＮ１１２の気付アドレスのプレフィックスがＡＧＷ１１０から取得されるとすると、パケットのルーティングパスは図１Ａのメッセージ１２７に示されているようになる。
ＵＥ１０４は、ＣＮ１１２が同一のモビリティアンカ（Ｐ−ＧＷ１１１）の配下の同一管理ドメイン内に存在しているかどうかが分からず、３Ｇインタフェースを使用してデータパケットを送信する。この場合、データパケットはまずＳ−ＧＷ１０８によってＰ−ＧＷ１１１あてにカプセル化され、イングレスフィルタリングをくぐり抜ける。Ｐ−ＧＷ１１１においてパケットは適切に発送され、ＣＮ１１２の現在のアドレスへ届く。この現在のアドレスのプレフィックスはＡＧＷ１１０を基点とするので、Ｐ−ＧＷ１１１からのデータパケットは、ＣＮ１１２へ更にトンネリングされることなく直接発送される。すなわち、この場合のデータパケットのルーティングパスを示すメッセージ１２７には、トンネリングは１つのみ存在する。
しかしながら、もしＵＥ１０４がＣＮ１１２と通信するためにＷｉＭＡＸインタフェースを使用した場合には、通信フローの両方のエンドポイントは最も近くに存在するルータ（アクセスルータ）に所有されているプレフィックス（あるいは、アクセスルータを基点とするプレフィックス）から得られるアドレスを使用し、より最適化された経路が実現されるようになる。すなわち、ＣＮ１１２と通信を行うためにＵＥ１０４が３Ｇインタフェースを使用した場合には、データパケットのルーティングパスは最適化されない。ＣＮ１１２がＣＭＩＰｖ６モードの場合、ＬＭＡ／ＨＡ１１がＣＮ１１２のホームエージェントではない場合に考慮すべき問題が生じる。
次に、図１Ｂを参照しながら、別のシナリオにおける同様の問題について説明する。ここで、ＣＮ１２２は、ＵＥ１１３のドメイン（ＥＰＣ）１２０とは異なる別の管理ドメイン（ＥＰＣ）１２５に接続されているとする。ここでも、図１Ａにおいて適用したＵＥ１０４に対する仮定を適用する。基本的に、ＵＥ１１３は、３Ｇインタフェース及びＷｉＭＡＸインタフェースの両方を通じてＥＰＣ１２０へ接続されており、ＣＮ１２２と通信を行っているとする。ＣＮ１２２はＰＭＩＰｖ６モードを用いて動作しているかもしれず、あるいは、ＭＩＰｖ６モビリティ管理モードを用いて動作しているかもしれない。また、ＣＮ１２２のホームドメインは、ドメイン１２０であってもよく、別のドメインであってもよい。
本発明に係る問題を説明するため、まず、ＣＮ１２２がＰＭＩＰｖ６モビリティ管理メカニズムを使用しており、ＣＮ１２０のホームドメインがドメイン１２０であると仮定する。このシナリオは、グローバルなＰＭＩＰｖ６動作などのメカニズムによって外部にローミングしたときにホームネットワークプレフィックス（ＨＮＰ）が参照される、３ＧＰＰホーム経由の場合における妥当なシナリオである。
基本的に、外部ドメインがホームドメインのＬＭＡとＰＢＵ/ＰＢＡを行うことで、ローミングしているＵＥは、外部ドメインで常にＨＮＰを確認することが可能である。非特許文献３には、このメカニズムの詳細が開示されている。このシナリオでは、ＣＮ１２２のアドレスはＵＥ１１３のアドレスと類似しているであろう。ＣＮ１２２がＵＥ１１３と同一のドメインに存在していると仮定し、ＵＥ１１３がＷｉＭＡＸインタフェースを使用する場合には、ＵＥ１１３はＣＭＩＰｖ６モビリティ管理メカニズムを使用し、データパスはメッセージ１２８に示されるようになる。しかしながら、外部ドメイン１２５に配置されているＣＮ１２２にとっては、ＣＭＩＰｖ６メカニズムを用いて経路最適化を実現する必要はない。この場合、ＣＮ１２２との経路最適化通信を実現するため、ＣＭＩＰｖ６インタフェース（すなわち、ＷｉＭＡＸインタフェース）を使用することで、ＵＥ１１３へのモビリティシグナリングが増えてしまうことになる。Ｐ−ＧＷ１２１はドメイン１２０の出口に位置するルータなので、ＵＥ１１３によって使用されているインタフェースによらず、データパケットは同一のルーティングパスを経由してＣＮ１２２に届く。ＵＥ１１３がＣＭＩＰｖ６インタフェースを選択した場合には、ＵＥ１１３が新たなアクセスルータに接続を変更する移動を行うと、モビリティ管理シグナリング（ＲＲ及びＢＵ）が行われる必要があり、その結果、効率的なモビリティ管理が実現されなくなる。
また、ＣＮ１２２のホームドメインがドメイン１２０ではなくドメイン１２５である場合には、ＰＭＩＰｖ６モビリティ管理がＣＮ１２２によって使用されている場合であっても、上述の問題が生じることが重要である。さらに、ＣＮ１２２がＭＩＰｖ６を使用し、かつ、ＣＮ１２２のホームドメインがドメイン１２０である場合や、ＣＮ１２２がＭＩＰｖ６を使用し、かつ、ＣＮ１２２のホームドメインがドメイン１２０ではない場合においても同様に、上述の問題が生じる。上述のような簡単なシナリオを分析するだけで、ＵＥ１１３が、経路最適化通信や効率的なモビリティ管理を実現するために理想的なインタフェースを選択するためのＣＮ１２２に関する情報を把握していないことによって、問題が生じてしまうことが分かる。
ＣＮ１２２との効率的なモビリティ管理シグナリングによって経路最適化された通信を行うためにＵＥ１１３が理想的なインタフェースを選択するための情報は、ＣＮの場所に関する情報に限定される必要はない。ＵＥがネットワークの何らかの動作メカニズムに関する情報を把握していない場合や、あるいは、ＵＥがＣＮの特性に関する情報を把握していない場合においても、同様の問題が起こり得る。次に、このようなタイプの問題について説明する。
以下、図２Ａ及び図２Ｂを参照しながら、本発明に係る問題について説明する。図２Ａにおいて、ネットワークでＭＡＧ間経路最適化（ＭＡＧ間ＲＯ）が行われる場合の問題について説明する。また、図２Ｂにおいて、ＣＮがＰＭＩＰｖ６モビリティモードを使用しており、ネットワークポリシによって変更不可能な場合の問題について説明する。
図２Ａでは、ＵＥ２０４は２つのインタフェース（３Ｇインタフェース及びＷｉＭＡＸインタフェース）を有しており、それぞれゲートウェイ（Ｓ−ＧＷ２０８、ＡＧＷ２０９）に接続されている。また、図２Ａにおいても、図１ＡでのＵＥ１０４に関する仮定を適用する（説明は省略する）。
基本的に、ＵＥ２０４は３Ｇインタフェースを経由してＰＭＩＰｖ６メカニズムを使用しており、ＷＩＭＡＸインタフェースを経由してＣＭＩＰｖ６メカ二ズムを使用している。さらに、Ｐ−ＧＷ２１１はＵＥ２０４のホームエージェントであるとする。また、ＵＥ２０４は、ＣＮ２１３とデータ通信セッションが有しているとする。例えば、ＣＮ２１３は、たとえＭＩＰｖ６スタックが実装されており、ドメイン（ＥＰＣ）２００がホームドメインであったとしてもＰＭＩＰｖ６モードで動作しているかもしれない。また、さらに、Ｐ−ＧＷ２１１がＣＮ２１３のホームモビリティアンカであるとする。
ＵＥ２０４がＣＮ２１３と通信を行うためにＷｉＭＡＸインタフェースを使用することを決定したとする。しかしながら、ＲＲが完了する前に、ＵＥ２０４が３Ｇインタフェースを使用してＣＮ２１３へデータパケットを送信すると仮定する。このデータパケットは、Ｓ−ＧＷ２０８からＰ−ＧＷ−２１１へトンネルされ、その後、Ｐ−ＧＷ２１１からＡＧＷ２１０へトンネルされる。
なお、ネットワーク構成は将来的に、レガシＩＰｖ６ノード（モビリティを管理できないノード、ＲＯシグナリングを実行できないノード）の経路最適化サポートが行えるように、ＭＡＧ間経路最適化メカニズムが実装されるかもしれない。ドメイン２００は、こうしたＭＡＧ間ＲＯを実装しているとする。最初のデータパケットがＣＮ２１３へ送信されると、Ｐ−ＧＷ２１１は、データパケットを送信したＭＡＧ（すなわち、Ｓ−ＧＷ２０８）及びデータパケットを受信するＭＡＧ（すなわち、ＡＧＷ２０９）を特定して、これらのＭＡＧに対して、ＭＡＧ間のトンネルを形成するよう要求してもよい。このとき、Ｐ−ＧＷ２１１は、保持するＰＭＩＰｖ６バインディングキャッシュテーブルからトンネルエンドポイントを形成する関連ＭＡＧを特定することが可能である。このようにして形成された図２Ａのトンネル２１２は、サードパーティ（例えばＰ−ＧＷ２１１）から提供される事前共有鍵や、ＭＡＧ（Ｓ−ＧＷ２０８及びＡＧＷ２０９）間ＲＲメカニズムなどの動的鍵生成メカニズムによって形成可能であることは明らかである。
トンネル２１２が動作していることを知らないＵＥ２０４は、ＲＲ処理が完了した後、ＣＮ２１３との通信にＣＭＩＰｖ６インタフェースを使用するかもしれない。この場合、ＣＮ２１３はＣＭＩＰｖ６モードに切り換えると、ルーティングパスはメッセージ２１４に示されるようになる。なお、ＵＥ２０４がＣＮ２１３との通信に３Ｇインタフェースを使用した場合には、メッセージ２１４に示されるルーティングパスはルーティングパス２１４Ａのようになる。したがって、特にＩＰｖ６ホストのために構成されているネットワークで経路最適化メカニズムが動作していることを的確に把握できないＵＥ２０４は、ＣＮ２１３との通信に好ましくないモビリティ管理モード（効率的なモビリティ管理が実現されないモビリティ管理モード）を選択してしまうことになる。この場合、ＣＭＩＰｖ６モード（すなわち、ＷＩＭＡＸインタフェース）を使用することによって、更なるモビリティ管理シグナリングがＣＮ２１３との間で実行される必要があり、モビリティ管理の効率が低下する。上述のように、ＣＭＩＰｖ６モードでは、アクセスルータが変更された場合には、ＣＮ２１３への適切なバインディング登録が行われる必要があり、シグナリング負荷が増大してしまう。
また、図２Ｂでは、ＣＮ２２６がＵＥ２１８と同一のドメインに位置しているが、ＰＭＩＰｖ６モードを使用しておりモード変更ができない場合の問題について説明する。Ｐ−ＧＷ２２２は、ＣＮ２２６に関するＰＭＩＰｖ６バインディングを有しているとする。以下、本発明に係る問題を説明するため、図２Ｂに示される構成における動作について説明する。
ＵＥ２１８は、ＵＥ１０４と同一であり、同様の仮定が適用される。また、ＣＮ２２６のホームドメインはドメイン２１５である。ＵＥ２１８がＣＮ２２６と通信を行うためにＣＭＩＰｖ６インタフェース（すなわちＷＩＭＡＸインタフェース）を使用する場合には、データパケットのルーティングパスはメッセージ２２８に示すようになる。ＵＥ２１８は、ＣＮ２２６とのＲＲ処理を完了したとすると、ＵＥ２１８からＣＮ２２６へのデータパケットのあて先アドレスはＣＮ２２６のアドレスを有し、このデータパケットはＰ−ＧＷ２２２経由で発送され、最適化されていない経路が生じる。このような経路が生じる理由は、ＣＮ２２６がＰＭＩＰｖ６モードで動作していることによる。
ＣＮ２２６がＣＭＩＰｖ６モードへ変更することができないので、ＵＥ２１８がＣＭＩＰｖ６モード（すなわち、ＷＩＭＡＸインタフェース）を使用した場合でも、経路最適化が関連する利益が得られないことは明らかである。なお、ＣＮ２２６がＣＭＩＰｖ６モードへ切り換えることが可能であれば、メッセージ２２７に示される最適化された経路が実現可能である。すなわち、ＵＥ２１８は、ＣＮ２２６の状態を把握せずに、ＣＮ２２６と通信を行うために好ましくないインタフェースを選択してしまったことになる。また、もしＵＥ２１８が３Ｇインタフェースを使用していたならば、ネットワークがモビリティ管理シグナリングを行うので、多数のモビリティ管理シグナリングの送受信は回避できたはずである。以上のように、このシナリオでは、どのインタフェースを使用したとしても、完全なＲＯは実現されないが、ＵＥ２１８が３Ｇインタフェースを使用することで、確実にモビリティ管理シグナリングの増大を防ぐことができるようになる。すなわち、３Ｇインタフェースが最も適切なインタフェースであると言える。
また、特許文献１には、ＵＥが複数ＢＵによって現在の位置／アドレスをアップデートするかどうかを決定する方法、あるいは単一のＢＵによって現在のアドレスを以前のアクセスルータ（接続変更前に接続されていたアクセスルータ）に通知するかどうかを決定する方法について開示されている。基本的に、以前のアクセスルータはＢＵが送信されるアンカポイントとして特定される。ＵＥの現在の位置を誰にアップデートするかに関しては、例えばＵＥが通信しているピアノードの数、ピアノード間のトラフィック、ＵＥとアクセスルータ及び／又はピアノードの間のシグナリング量又はトラフィック負荷、下位レイヤの状態、モバイルノードの状態、ハンドオーバの頻度などに基づいて決定される。すなわち、この特許文献１に開示されている技術では、ＵＥが多数のピアノードと通信しており、かつ、最適化を必要としている際に行われる必要がある頻繁なバインディングアップデートシグナリングに係る問題を解決する。
しかしながら、ＢＵシグナリングを減らす処理では、データパケットは以前のアクセスルータから届くので経路最適化は相殺され、現在のアクセスルータから複数ホップ離れた古いアクセスルータへＢＵが送信されてしまうのであれば、直接のパス（最適化されたパス）の形成は妨げられてしまう。さらに、ＢＵを送信する場所はピアノードごとに決定されるわけではない。ＵＥの現在位置がすべてのピアノードに更新されない場合もあり、また、すべてのピアノードにＵＥの現在位置が更新される場合もある。この特許文献１は、動きの速いＵＥにおけるシグナリングの低減の問題を解決するためのものであり、この特許文献１の開示技術を組み合わせたとしても、ＲＯ及び効率的なモビリティ管理を本当に実現することはできない。
また、特許文献２に説明されている方法は、ＵＥが配置されているローカルドメインの外にＣＮが存在している場合に、ハイブリッドタイプのモビリティ管理方法を使用することによって、単一インタフェースを有するＵＥの効率的なモビリティ管理及び経路最適化を実現することを目的としている。すなわち、ローカルドメイン内では、ＵＥは、モビリティ関連シグナリングに関与せず、ネットワークがモビリティを完全に管理する。ローカルドメインで確認されるプレフィックスは一定に保たれており、ネットワークプロキシはこのプレフィックスに関するルーティングパスを維持する。さらに、この特許文献２には、ローカルドメイン内のＵＥのモビリティが、例えばセルラアクセスポイント（ＣＡＰ）などのプロキシエンティティによって完全に管理されることが開示されている。ローカルドメインで得られるこのプレフィックスは、ローカルモビリティアンカから取得される。ローカルドメイン内では、ＵＥはいかなるモビリティシグナリングも行わず、現在のアドレスがホームアドレスと異なる場合にのみ、例えばＨＡやＣＮなどのピアノードへ現在のアドレスを提供することが必要となる。特許文献２に開示されている方法では、たとえ２つのインタフェースが接続されている場合でも、どのインタフェースが選択されるべきかに関して混乱することはなく、両方のインタフェースが同一のモビリティモードを使用するので、どちらのインタフェースを使用した場合であっても違いはない。
また、特許文献３に開示されている方法は、ＬＭＡが、同一のローカルドメインに接続されているＩＰｖ６ホスト間、あるいは、ＰＭＩＰｖ６が実装されている異なるローカルドメインに接続されているＩＰｖ６ホスト間における経路最適化処理を援助するものである。特許文献３に開示されている方法は、特に、２つのＭＡＧのどちらがデータパケットのルーティングパスにおけるトンネリング処理に関与するかを最初にＬＭＡが特定することによって、経路最適化を実現するものである。ＬＭＡによる特定後、ＬＭＡは、これらのＭＡＧに対して、ＭＡＧ間トンネルの形成を要求する。この方法は、ＬＭＡで利用可能な通信フローの両方のエンドのキャッシュが存在する場合にのみ、経路最適化の実現が援助される。さらに、この方法は、特に、レガシＩＰｖ６ホストをサポートするように構成されている。
特許文献３に開示されている方法は、例えば、ＵＥが各インタフェース経由で異なるモビリティ管理モードを使用しており、異なるモビリティ管理モードでもＣＮとの通信のために使用可能な正しいモードを特定するなどのような複雑なシナリオの経路最適化をサポートするものではない。さらに、この方法は、経路最適化を行うためにＬＭＡのキャッシュエントリを用いることに関連しており、ＬＭＡで利用可能なキャッシュエントリが存在しない場合には経路最適化の援助は失敗に終わる。
また、特許文献４には、位置プライバシ及び経路最適化が共に実現される経路最適化メカニズムが説明されている。経路最適化を実現するために使用される方法は、例えば、ＵＥが、ＣＮによって使用されているＨＡを特定し、そのＨＡでブートストラップするものであり、これによって、データパケットのルーティングパスが短縮される。
しかしながら、特許文献４に記載の技術では、完全なＲＯは実現されない。さらに、非常に高度な技術によって複数のＨＡからＨＡを選択することは、より良い経路の選択処理に似てはいるが、より良い経路のために理想的なインタフェースを選択するものではない。また、この特許文献４で議論されているメカニズムは、ＣＮとのＲＯ及び効率的なモビリティ管理を実現するために静的な構成条件における理想的なモビリティモード及びインタフェースに選択することに関連するものではない。
また、特許文献５には、純粋なＰＭＩＰｖ６環境でＲＯを実現するための方法が開示されている。この方法は、ＲＯを実現し、ＰＭＩＰｖ６の効率的な管理の利点を得ることを目的としている。特許文献５で説明されている方法は、ＭＡＧがＲＲ処理を実現してトンネルを確立するものである。このトンネルのトンネルエンドポイントは、直接ＵＥに接続されているＭＡＧと、直接ＣＮに接続されているＭＡＧである。ＭＡＧは、以前のＭＡＧ（接続変更前のＭＡＧ）からのコンテキストトランスファーによって転送される属性に基づいてトンネルを構築する。
しかしながら、特許文献５に開示されている方法は、ＵＥ及びＣＮが独立したドメインに存在しており、ＵＥ及びＣＮの両方がホームドメインから離れている際に有用ではあっても、ＵＥ及びＣＮが同一のローカルドメインに配置されている場合には理想的ではない。また、ＵＥがＣＭＩＰｖ６メカニズムを実現できる場合には、ローカルドメインにおいて純粋なＭＩＰｖ６メカニズム（ＲＯに基づくＭＩＰｖ６メカニズムに関連したトンネルではない）を使用することが有用であるが、特許文献５に説明されている方法はＲＯを図るトンネルについて開示されていない。さらに、ＵＥ及びＣＮは独立したドメインに存在し、かつホームドメインに存在している場合には、ＭＡＧ間ＲＯは効率的ではない。通常のＰＭＩＰｖ６メカニズムであれば、このようなＭＡＧ間ＲＯが存在する環境で十分であるが、特許文献５には、このＭＡＧ間ＲＯに関する開示もない。さらに、ＵＥ及びＣＮが両方共ＰＭＩＰｖ６モードの場合には、ＭＡＧ間ＲＯのみが効率的であるが、ＵＥ又はＣＮがＣＭＩＰｖ６モードの場合には、ＭＡＧ間ＲＯは使用不可能であり、オプションのみで、最適化された通信とするためにピアノードに関連する正しいモビリティ管理モードの識別が可能な状態となる。
さらに、特許文献６には、ピアノードがＲＲシグナリングを実行しないで経路最適化を実現するために使用される方法が開示されている。特許文献６に開示されている方法は、ＭＩＰｖ６メカニズムで実行される過剰なモビリティ管理シグナリングを行わずに、ＲＯを実現することを目的としている。
しかしながら、特許文献６に開示されている方法は、ＭＩＰｖ６のＲＯの最適化に焦点を当てており、ＣＮと通信するために異なるインタフェース間を特定あるいは選択する必要はない。この特許文献６で開示されている方法の１つは、ＵＥ及びＣＮの両方が同一のＨＡを有する場合のものであり、ＨＡはＣＮの現在のアドレスをＵＥへ渡すとともに、このＨＡはＵＥの現在の気付アドレスをＵＥへ渡して、ＵＥ及びＣＮの両方が直接通信を実現できるようになる。こうした方法は、すべてのキャッシュ（ＵＥ及びＣＮの両方のバインディングキャッシュ）がＨＡで利用可能な場合には可能であるが、ＣＮのバインディングをＨＡで利用できない場合には適用されない。
また、特許文献６には、ＵＥ及びＣＮが異なるＨＡに属しており、ＵＥ及びＣＮのＨＡがバインディングキャッシュをお互いに渡して、ＲＯがＵＥとＣＮとの間で実現可能な場合の別な方法が開示されている。この方法は、ＵＥのＨＡがＵＥのキャッシュをＣＮのＨＡへ渡すとともに、ＣＮのＨＡがＣＮのキャッシュをＵＥのＨＡへ渡し、最終的に、ＵＥのＨＡがＣＮのキャッシュをＵＥへ渡すとともに、ＣＮのＨＡがＵＥのキャッシュをＣＮへ渡すものである。
しかしながら、この方法は、インフラストラクチャのサポートを必要とし、関連するすべてのバインディングがＨＡで利用可能である必要がある。これは、複数インタフェースのノードが、インタフェースごとに割り当てられている堅固（rigid）なモビリティ管理モードを有しており、異なるタイプの制限あるいはドメイン配置位置を有しているＣＮと通信を行っている場合の問題を解決するものではない。
従来の技術の動作における上述の議論から、従来の技術に開示されている方法では、各インタフェースが異なるモビリティ管理モードを使用する複数インタフェースのＵＥが正しいインタフェースを選択できるようにする十分な方法は提供されないことは明らかである。従来の技術に開示されている方法では、ＭＡＧ間ＲＯがサポートされているシナリオであっても、ＭＡＧ間ＲＯがサポートされていないシナリオであっても、ＣＮとの通信に関連したエンドツゥーエンドのＲＯ及び効率的なモビリティ管理を実現することはできない。
さらに、上記従来の技術の方法では、ＣＮと通信するための正しいインタフェース又はモビリティモードを選択する際に、ＵＥがＣＮの場所を特定できず、さらに、ＣＮの状態（ＣＭＩＰｖ６状態、ＰＭＩＰｖ６状態、静的なモビリティ構成モード、動的なモビリティ構成モードなど）を特定できない。
また、３ＧＰＰでは、家庭内環境又は中小企業環境で使用されるフェムトセル（フェムト基地局、Home enhanced Node B（Home eNB又はＨｅＮＢ）とも呼ばれる）がサポートする別のシナリオが考察されている。フェムトセルは、例えば、ブロードバンド（例えば、デジタル加入者ライン）経由でサービスプロバイダのネットワークへ接続される小規模のセルラ基地局によって管理されており、家庭内又は企業内の環境にあるモバイルフォンをサポートする。サービスプロバイダは、フェムトセルによって、特に、アクセスが限定されているか又は利用できないエリアなど、屋内でのサービス範囲を拡張することが可能となる。
フェムトセルの概念は、通常の基地局の機能を導入するものであるが、より単純な機能内蔵型の構成を実現するよう拡張するものである。ユーザの既存リソース経由で電力やバックホール（backhaul）を利用する小規模基地局を導入することで、セルラのオペレータは、ネットワーク敷設費を抑えつつ、ネットワーク範囲をより広くすることが可能となる。
また、フェムトセルを使用することによって、ユーザが完全なセルラモバイルネットワークと同等の環境を極めて低電力で得ることができるという利点もある。これにより、既存の端末のバッテリ寿命を劇的に増加させることができるようになる。また、フェムトセルの概念では、モバイル装置のセルラ無線を使用するので、モバイル装置の使用者は、モバイル装置において無線アクセス技術（例えば、ＷｉＭＡＸ）をサポートしないようにするオプションを有する。
３ＧＰＰにおけるフェムトセルの際立った特徴は、ローカルＩＰアドレス（ＬＩＰＡ：Local IP Address）を使用することである。ＬＩＰＡによって、ＵＥは、フェムトセル内のＩＰ機能を有する他の装置に対してＩＰ経由で直接アクセスできるようになる。ＵＥと他のＩＰ機能を有する他の装置との間における直接アクセスによるトラフィックは、ＥＰＣを通過しないことが予測される。
図１３は、３ＧＰＰ内にフェムトセルが配置された概要を説明するネットワーク構成図である。図１３では、ＵＥ１３５０の加入者は、フェムトセルをホームネットワーク１３０１としてセットアップする。加入者のネットワークオペレータによって提供された基地局（ＨｅＮＢ１３５２）は、ホームネットワーク１３０１を管理する。ＨｅＮＢ１３５２は、外部ネットワークへ複数のリンク（すなわち、ＥＰＣ１３５５へアクセスするためのＳ−ＧＷ１３０４へのセルラリンク１３５３、サービスプロバイダ１３５７へのＤＳＬリンク１３５６）を有している。なお、実際の産業上の適用においては、セルラリンク１３５３は、物理的なＤＳＬリンク１３５６を通過する論理リンクであると想定される。また、図１３には、サービスプロバイダへのＤＳＬリンク１３５６を管理する基地局ＨｅＮＢ１３５２が図示されているが、ＨｅＮＢ１３５２はＤＳＬリンク１３５６を管理するＤＳＬルータに接続可能であると想定される。
ＥＰＣ１３５５内のモビリティアンカ（Ｐ−ＧＷ１３５８）は、ＵＥ１３５０のアンカポイントとして機能する。Ｐ−ＧＷ１３５８は、外部ネットワークへの複数のリンク（すなわち、別のオペレータネットワークＥＰＣ１３６０への専用オペレータリンク１３５９、インターネット１３６２への専用データリンク１３６１を有している。なお、実際の産業上の適用においては、オペレータが、各オペレータとの間でいくつかの専用オペレータリンク１３５９を相互に持っている。
また、サービスプロバイダ１３５７は、インターネット１３６２への専用サービスリンク１３６３を有している。また、コレスポンデントノード（ＣＮ１３６４〜１３６６）は、ＵＥ１３５０と通信セッションを有する端末である。ＵＥ１３５０は、セルラリンク１３５３又はＤＳＬリンク１３５６あるいはその両方を使用して、ＣＮと通信を行うことが可能である。なお、実際の産業上の適用においては、ＣＮ１３６４〜１３６６はＵＥ１３５０と同様にモバイル端末であることが想定される。以下の例では、ＵＥ１３５０がＣＮ１３６４〜１３６６と通信を行うために複数のＩＰアドレスを取得する方法について説明する。
ＵＥ１３５０は、現在、セルラ無線のみを使用している。ＵＥ１３５０は、ＨｅＮＢ１３５２に接続し、サービスを受けるためにＥＰＣ１３５５へアクセスする。Ｐ−ＧＷ１３５８は、ＵＥ１３５０がＥＰＣ１３５５へのアクセスに使用するＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０、以下、３Ｇ．ＩＰと記載することもある）を割り当てる。同様に、ＨｅＮＢ１３５２は、Ｐ−ＧＷ機能を有しており、ホームネットワーク１３５１内でローカルブレイクアウトサービスを受けるためのＩＰアドレス（ＨＮ．ＩＰ．ＵＥ１３５０、以下、ＨＮ．ＩＰと記載することもある）をＵＥ１３５０へ割り当てる。
ＨｅＮＢ１３５２はセルラネットワーク１３５３を通じて、３Ｇ．ＩＰへの／からのパケットの転送／受信を行う。同様に、ＨｅＮＢ１３５２は、ＤＳＬリンク１３５６を通じて、ＨＮ．ＩＰへの／からのパケットの転送／受信を行う。したがって、ＵＥ１３５０は、ＣＮ１３６４〜１３６６と通信を行うために、３Ｇ．ＩＰ又はＨＮ．ＩＰのどちらかを使用することができる。
図１３において提供されるシナリオでは、ＵＥ１３５０がＣＮ１３６６と通信を行うために使用すべきリンクはどれかを決定するための十分な情報を、ＵＥ１３５０が有していないという点で、上述のシナリオで説明したものと同じ問題を抱える。ＵＥ１３５０がＣＮ１３６６に対してサブオプティマルな通信経路を選択した場合には、ＵＥ１３５０は、サービス低下を受けてしまう可能性がある。
例えば、ＵＥ１３５０及びＣＮ１３６６は、実際に同一のドメイン（すなわち、ホームネットワーク）に位置しているとする。ＵＥ１３５０はセルラリンク１３５３を使用してＣＮ１３６６と通信を行い、そのパケットは、ＥＰＣ１３５５を通過してホームネットワーク１３５１へ戻ることになる。なお、ＵＥ１３５０とＣＮ１３６６との間のルーティングのホップ数増加は、ＵＥ１３５０からのパケットがＣＮ１３６６に到達する際に（あるいはその逆も）遅延することを意味している。
特許文献１２に開示されている方法では、ＵＥが、ローカルブレイクアウトサービスへのＥＰＣアクセスのために使用する異なるＩＰアドレスを取得することが可能なシナリオが説明されている。ＵＥは、どこにアプリケーションがホスティングされているかに基づいて、どのＩＰアドレスがアプリケーションに関連付けられているかを判断する。例えば、ＵＥは、ローカルブレイクアウトサービスにおいてＰ−ＧＷによってホスティングされるボイスオーバＩＰ（ＶｏＩＰ：Voice over IP）を開始する。この場合には、ＵＥは、ＶｏＩＰセッション、ローカルブレイクアウト用に取得したＩＰアドレスと関連付ける。
この特許文献１２に開示されている従来技術では、アプリケーションがどこにホスティングされているかをＵＥが既に知っていると仮定しており、アプリケーションサーバが静的な場合には合理的である。しかしながら、アプリケーションサーバ（すなわち、モバイル端末）が移動している場合には、アプリケーションがどこにホスティングされているかという情報は、必ずしも正確ではない。したがって、アプリケーションがどこにホスティングされているかという知識がＵＥに事前に構成されているという従来技術の仮定は、本発明が課題としている問題を解決するために有用なものではない。
また、特許文献１３に開示されている方法は、２つのＭＮ間の通信経路が最適化可能であることをＬＭＡが検出するものである。したがって、ＬＭＡは、ＭＮが接続しているＭＡＧに対して、相互の間の経路を作成し、最適化するよう指示する。また、この従来技術では、さらに、各ＭＮが異なるＬＭＡに接続されている場合には、ＬＭＡが取り扱うＩＰアドレス範囲がどれかをＬＭＡが把握していると仮定される。したがって、特許文献１３に開示されている従来技術は、ＬＭＡがトリガする点においては利用可能であるが、各ＬＭＡが相互に関する情報を交換する必要があり、実際の構成においては実現不可能かもしれないと言及されている。特に、モバイルノードの加入者同士がそれぞれ異なるセルラオペレータに関係しているようなシナリオにおいては、従来技術による解決方法の適用可能性はとても少ないものとなる。
また、特許文献１４に開示されている方法では、ＭＮがＨＡに２つのアクティブなリンク（すなわち、気付アドレスを使用する外部リンクと、ホームアドレスを使用するホームリンク）を有している場合のシナリオが説明されている。ＭＮは、ルーティングのコスト（すなわち、時間遅延）をテストするために、各リンクを経由してＨＡへメッセージを送信する。各リンクにおけるルーティングコストに基づいて、ＭＮは、ＨＡと通信を行うための最小ルーティングコストを選択する。ＭＮの複数のリンクのそれぞれをテストすることによって、ＭＮは各リンクのコストを把握し、どのリンクが最適であるかを判断することが可能である。
しかしながら、ルーティングコストを調べるために各リンクを通じてＭＮがパケットを送信することは、ネットワークのシグナリング負荷を著しく増大させてしまう可能性がある。一方、本発明の好適な実施の形態の１つは、ルーティングコストを調べるために端末が各リンク経由でパケットを送信することを必要とせずに、どのリンクが最適であるかを端末が把握できるようにすることを目的とする。従来技術の動作に係る説明から、従来技術の開示内容はどれも、端末において利用可能な複数の通信経路の中から最適な通信経路を端末が選択することができないものであることは明らかである。
上述の問題を解決するため、本発明は、ＵＥがＣＮとの効率的な通信を実現するために、どのインタフェースを使用すべきかを選択するために十分な情報を持っていない場合に生じる問題を解決することを目的とする。
上記の問題を解決するため、本発明は、少なくとも上述した従来の技術における問題や欠点を改善することを目的とする。特に、本発明は、各インタフェースで異なるモビリティ管理メカニズムが使用されている複数インタフェースのＵＥが適切なインタフェースを選択し、その結果、モビリティ管理の利点を保ちながら、最適な経路を使用してＣＮと通信を行うことを可能にすることを目的とする。また、本発明は、複数のアドレスを有するＵＥが適切なアドレスを選択し、その結果、モビリティ管理の利点を保ちながら、最適な経路を使用してＣＮと通信を行うことを可能にすることを目的とする。また、本発明は、ネットワーク内のシグナリング負荷を著しく増加させることなく、端末で利用可能な複数の通信経路の中から最適な通信経路を端末が選択できるようにすることを目的とする。
上記の目的を達成するため、本発明の通信システムは、異なるアクセス技術を用いた複数のインタフェースを使用してネットワークベースのモビリティ管理ドメインへ接続可能であり、通信相手である通信相手ノードとの間に複数の通信経路を有する移動端末と、前記ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードとを有する通信システムであって、
前記ネットワークノードが前記通信相手ノードから前記移動端末へ送信されるパケットの監視を行って、前記通信相手ノードから前記移動端末へ送信される前記パケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断して、その判断結果を前記移動端末へ通知し、
前記移動端末は、前記判断結果に基づいて、前記通信相手ノードとの通信に使用する通信経路を選択するよう構成されている。
この構成により、複数の通信経路（複数のインタフェース又は複数のアドレス）を有する移動端末は、適切な通信経路を選択して通信相手ノードと通信を行えるようになる。
また、上記の目的を達成するため、本発明の移動端末は、ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードが配置されている前記ネットワークベースのモビリティ管理ドメインへ接続可能であり、通信相手である通信相手ノードとの間に複数の通信経路を有する移動端末であって、
前記ネットワークノードが前記通信相手ノードから前記移動端末へ送信されるパケットの監視を行って、前記通信相手ノードから前記移動端末へ送信されるパケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断した判断結果を受信する受信手段と、
前記判断結果に基づいて、前記通信相手ノードとの通信に使用する通信経路を選択する通信経路選択手段とを、
有している。
この構成により、複数の通信経路（複数のインタフェース又は複数のアドレス）を有する移動端末は、適切な通信経路を選択して通信相手ノードと通信を行えるようになる。
また、上記の目的を達成するため、本発明のネットワークノードは、ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードであって、
前記ネットワークベースのモビリティ管理ドメインへ接続可能であり、通信相手である通信相手ノードとの間に複数の通信経路を有する移動端末に関して、前記移動端末の通信相手である通信相手ノードから前記移動端末へ送信されるパケットの監視を行うパケット監視手段と、
前記通信相手ノードから前記移動端末へ送信される前記パケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断する判断手段と、
前記判断手段による判断結果を前記移動端末へ通知する通知手段とを、
有している。
この構成により、複数の通信経路（複数のインタフェース又は複数のアドレス）を有する移動端末は、適切な通信経路を選択して通信相手ノードと通信を行えるようになる。
また、上記の目的を達成するため、本発明の基地局装置は、移動端末と無線接続を行う基地局装置であって、
前記基地局装置に接続されており、通信相手である通信相手ノードとの間に複数の通信経路を有する移動端末に関して、前記移動端末の通信相手である前記通信相手ノードから前記移動端末へ送信されるパケットの監視を行うパケット監視手段と、
前記通信相手ノードから前記移動端末へ送信される前記パケットを検出した場合に、前記通信相手ノードが同一の前記基地局装置に接続されているかどうかを判断する判断手段と、
前記判断手段による判断結果を前記移動端末へ通知する通知手段とを、
有している。
この構成により、複数の通信経路（複数のインタフェース又は複数のアドレス）を有する移動端末は、適切な通信経路を選択して通信相手ノードと通信を行えるようになる。
本発明は上記の構成を有しており、各インタフェースで異なるモビリティ管理メカニズムが使用されている複数インタフェースのＵＥが適切なインタフェースを選択し、その結果、モビリティ管理の利点を保ちながら、最適な経路を使用してＣＮと通信を行うことを可能にするという効果を有している。
従来の技術におけるネットワーク構成及びパケットの流れの第１の例を示す図 従来の技術におけるネットワーク構成及びパケットの流れの第２の例を示す図 従来の技術におけるネットワーク構成及びパケットの流れの第３の例を示す図 従来の技術におけるネットワーク構成及びパケットの流れの第４の例を示す図 本発明の実施の形態におけるネットワーク構成及びパケットの流れの第１の例を示す図 本発明の実施の形態におけるメッセージの流れの第１の例を示すシーケンスチャート 本発明の実施の形態におけるメッセージの流れの第２の例を示すシーケンスチャート 本発明の実施の形態におけるメッセージの流れの第３の例を示すシーケンスチャート 本発明の実施の形態におけるＵＥの処理の第１の例を示すフローチャート 本発明の実施の形態におけるネットワーク構成及びパケットの流れの第２の例を示す図 本発明の実施の形態におけるネットワーク構成及びパケットの流れの第３の例を示す図 本発明の実施の形態におけるＵＥの構成の一例を示す図 本発明の実施の形態におけるＰ−ＧＷの構成の一例を示す図 本発明の実施の形態において、ＣＮが同一ドメインに存在していることを示すマークを伝送するためのフレーム構造又はパケット構造の例を示す図 本発明の実施の形態におけるネットワーク構成及びパケットの流れの第４の例を示す図 本発明の実施の形態におけるメッセージの流れの第４の例を示すシーケンスチャート 本発明の実施の形態におけるメッセージの流れの第５の例を示すシーケンスチャート 本発明の実施の形態におけるメッセージの流れの第６の例を示すシーケンスチャート 本発明の実施の形態におけるメッセージの流れの第７の例を示すシーケンスチャート 本発明の実施の形態におけるＵＥの処理の第２の例を示すフローチャート 本発明の実施の形態におけるネットワーク構成の別の一例を示す図 本発明の実施の形態におけるＵＥの処理の第３の例を示すフローチャート 本発明の実施の形態におけるＵＥの処理の第４の例を示すフローチャート 本発明の実施の形態におけるＨｅＮＢの構成の一例を示す図 本発明の実施の形態において、ＵＥからＨｅＮＢへ送信される通知リクエストメッセージのフォーマットの一例を示す図 本発明の実施の形態におけるネットワーク構成のさらに別の一例を示す図 本発明の実施の形態において、ＲＲシグナリングを利用してＰ−ＧＷがＵＥへ通知を行う一例を示すシーケンスチャート
以下、図面を参照しながら、本発明の実施の形態について説明する。
本発明は、ネットワークエンティティから提供される情報に加えて、さらに選択処理に対する別の判断基準を用いて、ＭＮがＣＮとの通信に理想的なインタフェースを選択するものである。以下、本発明の好適な実施の形態を挙げながら、本発明について説明する。
＜第１の実施の形態：ＣＮがＣＭＩＰｖ６モードである場合の本発明の概念＞
本発明の第１の実施の形態では、ＣＮが同一ドメインに存在する場合に、ＵＥが使用すべき正しいインタフェースを特定できるようにネットワークエンティティが援助を行うシナリオについて説明する。
以下、図３Ａを参照しながら、本発明の第１の実施の形態について説明する。図３Ａでは、ＵＥ３０４Ａは２つのインタフェースを有している。ＵＥ３０４Ａが有する２つのインタフェースは、例えば、Ｅ−ＵＴＲＡＮ（Evolved Universal Terrestrial Radio Access Network）３０３Ａに接続されている３Ｇ ＬＴＥタイプのインタフェース、及び、ＷｉＭＡＸアクセスネットワーク３０２Ａに接続されているＷｉＭＡＸタイプのインタフェースなどである。
ＵＥ３０４Ａは、アクセスリンク３１１Ａを経由してＳ−ＧＷ３０５Ａへ接続されており、リンク３１２Ａを経由してＡＧＷ３０６Ａへ接続されている。また、ＵＥ３０４Ａの３ＧインタフェースのモビリティはＰＭＩＰｖ６メカニズムで管理されており、ＵＥ３０４ＡのＷｉＭＡＸインタフェースのモビリティはＣＭＩＰｖ６メカニズムで管理されている。また、ＵＥ３０４Ａはそのホームドメイン内に存在しており、３Ｇインタフェース経由で検出したＰＭＩＰｖ６のホームネットワークプレフィックス（ＨＮＰ：Home Network Prefix）がＭＩＰｖ６ホームプレフィックスであり、Ｐ−ＧＷ３１６ＡがそのＨＡであるとする。
また、ＵＥ３０４Ａは、例えば、ＣＮ３０８Ａ、ＣＮ３０９Ａ、ＣＮ３１０Ａの３つのＣＮと通信を行っているとする。これらすべてのＣＮ３０８Ａ、３０９Ａ、３１０ＡはＭＩＰｖ６又はＤＳＭＩＰｖ６を実装しているノードであり、ＵＥ３０４Ａとの間でＲＲシグナリングを行って、経路最適化通信を実現することが可能である。また、ＣＮ３０８Ａ、３０９Ａ、３１０Ａは、ＷｉＭＡＸアクセスネットワーク３０１Ａに接続されており、ＷｉＭＡＸアクセスネットワーク３０１Ａ及びＵＥ３０４Ａが接続されているアクセスネットワークはすべて同一のＥＰＣ３００Ａに接続されている。また、初期状態として、すべてのＣＮ３０８Ａ、ＣＮ３０９Ａ、ＣＮ３１０ＡのＨＡがＰ−ＧＷ３１６Ａであると仮定する。なお、ＵＥ３０４Ａと、ＣＮ３０８Ａ、ＣＮ３０９Ａ、ＣＮ３１０Ａは、同一のホームドメイン（Home Public Land Mobile Network (HPLMN)）に属しているか、又は、外部ドメイン（Visited Public Land Mobile Network (VPLMN)）においてローカルブレイクアウトを利用している場合を想定してもよい。ローカルブレイクアウトについては、非特許文献３に開示されている。
以下、図３Ａにおける動作を説明しながら、本発明に係る動作シーケンス及び本発明の実現方法について説明する。図３Ａにおいて、最初に、ＣＮ３０８ＡがＵＥ３０４Ａへデータパケットの送信を開始したとする。ＲＲ処理が実行される前の段階では、ＣＮ３０８Ａは、ＵＥ３０４Ａのホームアドレスのみを把握している。このデータパケットが送信される場合、データパケットの送信元アドレスはＣＮ３０８Ａのホームアドレスとなる。なお、ＣＮ３０８Ａは、最初のパケットとしてＨｏＴＩメッセージを送信することも考えられるが、この説明では、最初のパケットがデータパケットであると仮定する。
図３Ａにおいて、このデータパケット又はデータメッセージは、メッセージ３１５Ａによって示されている。このメッセージ３１５Ａは、ＣＮ３０８ＡからＰ−ＧＷ３１６Ａへトンネルされる。このとき、トンネルパケットの送信元アドレスはＣＮ３０８Ａの気付アドレスであり、あて先アドレスはＰ−ＧＷ３１６Ａのアドレスである。
Ｐ−ＧＷ３１６Ａはメッセージ３１５Ａをデカプセル化すると、バインディングキャッシュを参照して、内部パケットのあて先アドレスがＰＭＩＰｖ６バインディングに、内部パケットの送信元アドレスがＣＭＩＰｖ６バインディングにそれぞれ格納されていることを確認する。これによって、Ｐ−ＧＷ３１６Ａはこのデータフローに関連するピアノードが同一ドメイン３００Ａに位置していることを把握することが可能である。また、このメッセージ３１５ＡはＰ−ＧＷ３１６Ａのイングレスインタフェース経由で届き、Ｐ−ＧＷ３１６Ａのイングレスインタフェース経由で発送されるので、Ｐ−ＧＷ３１６Ａはこのデータフローに関連するピアノードが同一ドメイン３００Ａに位置していることを把握してもよい。このように、Ｐ−ＧＷ３１６ＡがＣＮ３０８Ａの位置を特定するための処理を行うことが、本発明にとって重要である。
Ｐ−ＧＷ３１６Ａはこのような検出を行った後、さらにメッセージ３１５ＡをＳ−ＧＷ３０５Ａへトンネリングすることによって、メッセージ３１５ＡはＵＥ３０４Ａの３Ｇインタフェースへ発送される。Ｐ−ＧＷ３１６Ａは、ＵＥ３０４ＡのＨＮＰに関するＰＭＩＰｖ６バインディングを有しているので、このようなトンネリングを行うことが可能である。
Ｐ−ＧＷ３１６Ａはメッセージ３１５Ａをトンネリングする際、トンネリングヘッダにマーク又はトリガを埋め込むことが可能であり、ＣＮ３０８Ａが同一ドメイン３００Ａに存在することをＳ−ＧＷ３０５Ａへ通知することが可能である。こうしたマーク又はトリガの渡し方としては、多数の方法が考えられる。例えば、Ｐ−ＧＷ３１６Ａは、明示的なメッセージ（なお、後述するが、本明細書における明示的とは、データパケットと関連付けられていない独立したメッセージで通知されることを意味する）を送信してもよく、データパケットにマークを付加してもよい。なお、その他の方法に関しては、別の実施の形態として後で説明する。さらに、既存のメッセージを利用してマークを送信する方法に関しても、別の実施の形態として後で説明する。
例えばＰ−ＧＷ３１６Ａが、ＣＮ３０８Ａが同一ドメイン３００Ａに存在することを示すマークをメッセージ３１５Ａのトンネリングヘッダに埋め込んだ場合、Ｓ−ＧＷ３０５Ａは、このマークが埋め込まれているメッセージ３１５Ａを受信すると、Ｓ−ＧＷ３０５Ａは、デカプセル化を行った後、Ｅ−ＵＴＲＡＮ特有の方法を用いてＵＥ３０４Ａへメッセージ３１５Ａを発送する。さらに、Ｓ−ＧＷ３０５Ａは、Ｐ−ＧＷ３１６Ａから受信したマークを通知するために、新たなメッセージによってＵＥ３０４Ａへトリガを渡す。
なお、Ｓ−ＧＷ３０５Ａが、Ｓ−ＧＷ３０５ＡとＵＥ３０４Ａとの間のパス上に存在するすべてのノードのＭＡＣ（Media Access Control）アドレスを把握しているのであれば、この新たなメッセージはレイヤ２（Ｌ２）メッセージによって送信されてもよく。また、新たなレイヤ３（Ｌ３）メッセージによって、このマークがＳ−ＧＷ３０５ＡからＵＥ３０４Ａへ送信されてもよい。
Ｓ−ＧＷ３０５Ａから送信されたマークをＵＥ３０４Ａが検出すると、ＵＥ３０４Ａは、ＣＮ３０８Ａも同一ドメイン３００Ａに存在していることを把握し、ＣＮ３０８Ａとのデータ通信にＷｉＭＡＸインタフェースを使用することを決定する。なお、ＣＮ３０８Ａが同一ドメイン３００Ａに存在してＭＩＰｖ６メカニズムを使用する場合には、ＵＥ３０４Ａも、ＭＩＰｖ６メカニズムによってモビリティが管理されているＷｉＭＡＸインタフェースを使用することが有用である。
ここで、ＵＥ３０４Ａが十分なバッテリ電力を有しており、アクセスネットワーク３０２Ａのネットワーク輻輳状態がまだ飽和していないとすると、ＵＥ３０４Ａは、ネットワークエンティティから提供される情報（すなわち、ＣＮ３０８Ａが同一ドメイン３００Ａに存在することを示すマーク）に基づいて、その決定を変更することなく正しいインタフェース（ここでは、ＷｉＭＡＸインタフェース）を選択する。なお、後述するが、本明細書では、正しいインタフェースとは、ＵＥ３０４ＡとＣＮ３０８Ａとの通信において経路最適化を実現できるインタフェース、あるいは、過剰なシグナリングメッセージの送受信を防いで効率的なモビリティ管理を実現できるインタフェースである。この正しいインタフェースは、適切なインタフェース、あるいは、理想的なインタフェースと記載することもある。
また、ＵＥ３０４Ａ及びＣＮ３０８Ａが、最適なパスを相互に実現するためにお互いに双方向ＲＲを行う場合、双方向ＲＲが完了すると、本発明によって実現されるデータ通信パスは、図３Ａのメッセージ３１４Ａに示されているようになる。なお、本発明の第１の実施の形態では、理想的なインタフェースの決定がＵＥ３０４Ａによって行われ、ＣＮ３０８Ａは単にＵＥ３０４Ａの決定をそのまま受け入れているに過ぎない。この第１の実施の形態では、ＣＮ３０８Ａがモビリティ管理モードにおいて柔軟性を有し、フローに関連するＱｏＳ要件に関して特に制限されていないと仮定している。したがって、ＣＮ３０８Ａは、単に相手ノード（すなわち、ＵＥ３０４Ａ）によって行われた決定に従うだけである。
＜第２の実施の形態：ＣＮがＰＭＩＰｖ６モードである場合の本発明の概念＞
次に、本発明の第２の実施の形態について説明する。本発明の第２の実施の形態においても、図３Ａに図示されているシナリオを用いて説明を行うが、上述の本発明の第１の実施の形態におけるＣＮ３０８Ａのモビリティ管理モードに関して若干の変更を加える。すなわち、本発明の第２の実施の形態では、ＣＮ３０８ＡがＰＭＩＰｖ６モードである場合を考える。ＣＮ３０８ＡがＰＭＩＰｖ６モードを利用しているという点以外は、すべて上述の本発明の第１の実施の形態と同一の仮定を行うため、ここでは説明を省略する。
本発明の第２の実施の形態においても、ＣＮ３０８Ａの位置（すなわち、同一ドメイン３００Ａに存在していること）がＰ−ＧＷ３１６ＡからＵＥ３０４Ａへ通知されると、ＵＥ３０４ＡはＲＲ処理を開始する。図３Ａのメッセージ３１４Ａによって示されている完全に最適化されたパスを得るためには、ＣＮ３０８ＡもＭＩＰｖ６モードに従った動作を行う必要があるが、この本発明の第２の実施の形態では、ＣＮ３０８ＡがＰＭＩＰｖ６モードであると仮定する。
このような場合、ＣＮ３０８Ａは、ＵＥ３０４ＡからＲＲメッセージを取得した場合に、２つの動作のうちのいずれかを行うことが可能である。第１の動作は、ＣＮ３０８Ａが、気付アドレスを構成するためのプレフィックスを提供するようＡＧＷ３０７Ａへ要求するものである。これによって、ＣＮ３０８Ａは、プレフィックスの取得及び気付アドレスの構成が可能となり、ＲＲシグナリングを実行することが可能となる。また、第２の動作は、ＣＮ３０８Ａが、モビリティモードをＣＭＩＰｖ６モードへ切り換えるようネットワークへ要求するものである。ＣＮ３０８Ａは、ＰＭＩＰｖ６モードの場合には、これらの第１及び第２の動作のいずれかを実行することが可能である。
なお、ＵＥ３０４Ａは、ＲＲメカニズムを実行する際、ＵＥ３０４ＡとＣＮ３０８Ａとの間で最適なルーティングパスを実現するために、ＲＲに関するモビリティヘッダメッセージにトリガ又はオプションを埋め込んで、気付アドレスの構成動作やＣＭＩＰｖ６モードへの切り換え動作をＣＮ３０８Ａへ要求してもよい。また、Ｐ−ＧＷ３１６Ａが、モビリティモードをＣＭＩＰｖ６へ切り換えるようＣＮ３０８Ａへ要求してもよい。
＜第３の実施の形態：Ｐ−ＧＷがＣＮのホームモビリティアンカではない場合の本発明の概念＞
次に、本発明の第３の実施の形態について説明する。本発明の第３の実施の形態においても、図３Ａに図示されているシナリオを用いて説明を行うが、上述の本発明の第１の実施の形態におけるＣＮ３０８Ａのホームエージェントに関する仮定に関して若干の変更を加える。すなわち、本発明の第３の実施の形態では、ＣＮ３０８ＡのホームエージェントがＰ−ＧＷ３１６Ａではないと仮定する。ＣＮ３０８ＡのホームエージェントがＰ−ＧＷ３１６Ａではないという点以外は、すべて上述の本発明の第１の実施の形態と同一の仮定を行うため、ここでは説明を省略する。
本発明の第３の実施の形態では、ＣＮ３０８ＡのホームエージェントがＰ−ＧＷ３１６Ａではなく、かつ、ＣＮ３０８ＡがＣＭＩＰｖ６モードで動作を行うとする。さらに、ＣＮ３０８ＡがＵＥ３０４Ａへデータを送信しようとしており、ＵＥ３０４Ａに対してＲＲメカニズムが既に実行されていると仮定する。したがって、ＵＥ３０４Ａは、ＣＮ３０８ＡのＨｏＡとＣＮ３０８Ａの気付アドレスとの関連付けを示すバインディングを有している。なお、ＣＮ３０８Ａの気付アドレスは、ＡＧＷ３０７Ａから取得されたものである。
また、ＣＮ３０８Ａからのデータパケットは、メッセージ３１５Ａに示されるパスを通じて伝送される。ＲＲ後のデータパケットの送信元アドレスは、ＣＮ３０８Ａの気付アドレスであり、パケットのあて先アドレスはＵＥ３０４Ａのホームアドレスである。したがって、ＣＮ３０８ＡからＵＥ３０４Ａへ送信されるデータパケットは、メッセージ３１５Ａに示されているように、Ｐ−ＧＷ３１６Ａのイングレスインタフェースを通じて受信され、Ｐ−ＧＷ３１６ＡのイングレスインタフェースからＳ−ＧＷ３０５Ａへのトンネリングによって発送される。
さらに、本発明の第１の実施の形態で説明したように、Ｓ−ＧＷ３０５Ａへトンネリングされるメッセージには、ＣＮ３０８Ａが同一ドメイン３００Ａに存在していることを示すマークが埋め込まれる。なお、当業者にとって、ＵＥ３０４ＡがＷｉＭＡＸインタフェースに関連するＣＭＩＰｖ６バインディングをＰ−ＧＷ３１６Ａに登録できることは明らかである。このような場合には、ＰＭＩＰｖ６バインディング及びＣＭＩＰｖ６バインディングの両方が、Ｐ−ＧＷ３１６Ａに存在することになる。
ＵＥ３０４ＡのＣＭＩＰｖ６バインディングがＰ−ＧＷ３１６Ａに登録されている場合には、上述のマークが、ＵＥ３０４Ａへのトンネリング処理を利用してＵＥ３０４へ直接送信されてもよい。このとき、Ｐ−ＧＷ３１６Ａは、ＣＮ３０８ＡからＵＥ３０４Ａへ送信されるデータパケットのあて先アドレスを調べる。データパケットはＵＥ３０４Ａのホームアドレスあてなので、Ｐ−ＧＷ３１６Ａは、ＵＥ３０４Ａの気付アドレスあてにデータパケットをトンネリングしてもよい。このトンネルは、ＵＥ３０４Ａ及びＣＮ３０８Ａが同一ドメイン３００Ａ内に存在することを示すマークを通知するためのヘッダやフラグを有しており、このマークによって、ＵＥ３０４Ａは、ＣＮ３０８Ａが同一ドメイン３００Ａに存在していると把握することが可能となる。
上述の本発明の第１の実施の形態では、Ｐ−ＧＷ３１６ＡがＣＮ３０８Ａに関するバインディングを参照してＣＮ３０８Ａの位置を把握することが可能であるが、本発明の第３の実施の形態のように、たとえＰ−ＧＷ３１６ＡがＣＮ３０８Ａに関するバインディングを有していなくても、ＵＥ３０４ＡとＣＮ３０８Ａとの間で容易に経路最適化が実現可能である。
＜第４の実施の形態：ＣＮがモビリティ状態の場合の本発明の概念＞
次に、本発明の第４の実施の形態について説明する。本発明の第４の実施の形態では、ＣＮがＣＭＩＰｖ６モードであり、ＭＮが存在するドメインから出た後に再び同一ドメインに戻ってくる場合のＣＮのモビリティの取り扱い方法について説明する。
以下、図３Ｂを参照しながら、本発明の第４の実施の形態について説明する。図３Ｂにおいても、ＵＥ（ＵＥ／ＭＮ）３１３Ｂは２つのインタフェースを有しており、３Ｇインタフェース経由でＳ−ＧＷ３１４Ｂに、ＷｉＭＡＸインタフェース経由でＡＧＷ３１５Ｂにそれぞれ接続されている。また、Ｐ−ＧＷ３１７ＢがＵＥ３１３Ｂのホームエージェントであり、３ＧインタフェースのモビリティはＰＭＩＰｖ６メカニズムによって、ＷｉＭＡＸインタフェースのモビリティはＣＭＩＰｖ６メカニズムによってそれぞれ管理されているとする。さらに、ＵＥ３１３ＢがＣＮ３１８Ｂと通信を行おうとしているとする。また、初期状態として、ＣＮ３１８ＢはＵＥ３１３Ｂと同じドメイン内に存在し、ＣＭＩＰｖ６メカニズムを使用しているとする。
ＵＥ３１３Ｂは、Ｐ−ＧＷ３１７Ｂへ明示的な要求メッセージ３００Ｂを送信し、Ｐ−ＧＷ３１７Ｂが、ＵＥ３１３Ｂに関する動作（ＵＥ３１３Ｂがより良いデータ通信を行うための動作）を行うように要求する。要求メッセージ３００Ｂは、ＵＥ３１３ＢがＰ−ＧＷ３１７Ｂに対して、そのホームアドレス（ＭＮ．ＨｏＡ／ＨｏＡ）をあて先とするあらゆるＣＮからのパケットの監視を行うよう要求するものである。また、要求メッセージ３００Ｂは、例えば、パケットが内部ドメイン（すなわち、ＵＥ３１３Ｂが存在するドメインと同一のドメイン）から届いた場合には、ＭＮ．ＨｏＡあてのパケットにマークを付けるようＰ−ＧＷ３１７Ｂへ要求するものである。
このとき、ＵＥ３１３Ｂにとっては、ＷｉＭＡＸインタフェースの気付アドレスやすべてのＣＮのアドレスを提供してもよいが、ＵＥ３１３ＢのＨｏＡを提供するほうが有益である。ＵＥ３１３ＢがすべてのＣＮのアドレスを提供する場合には、メッセージ３００Ｂに関連する帯域消費が大きくなり、さらに、Ｐ−ＧＷ３１７ＢがこれらのＣＮのアドレスを格納する容量も大きくなる。また、ＵＥ３１３ＢがＷｉＭＡＸインタフェースの気付アドレスを提供する場合には、ＣＮ３１８ＢがＵＥ３１３Ｂの気付アドレスの通知を受けるまでＰ−ＧＷ３１７ＢがＣＮ３１８Ｂの位置を特定することは不可能である。また、ＵＥ３１３Ｂの気付アドレスがＣＮ３１８Ｂへ通知されない場合には、Ｐ−ＧＷ３１７ＢはＣＮ３１８Ｂの正しい位置（すなわち、同一ドメインに存在するか、あるいは異なる外部ドメインに存在するか）を特定することはできない。
最初、ＣＮ３１８Ｂからのデータパケットは、ＵＥ３１３Ｂのホームアドレスあてであるとする。また、ＵＥ３１３Ｂがメッセージ３００Ｂを送信した後、ＣＮ３１８ＢがＨｏＴＩ又はデータパケット３０１ＢをＵＥ３１３Ｂへ送信すると仮定する。このＨｏＴＩ又はデータパケットは、Ｐ−ＧＷ３１７Ｂによって受信（intercept）される。上述の本発明の第１の実施の形態のように、このＨｏＴＩ又はデータパケット３０１Ｂはトンネリングメッセージ３０３Ｂに示されるようにＳ−ＧＷ３１４Ｂへトンネルされるか、あるいは、メッセージ３０４Ｂに示されるようにＵＥ３１３Ｂへ直接トンネリングによって送信される。
一方、Ｐ−ＧＷ３１７Ｂは、ＣＮ３１８ＢからＵＥ３１３Ｂへ送信されるパケットに対して、ＣＮの位置の検出処理３０２Ｂを行う。ここでは、ＣＮ３１８Ｂからのデータパケットがイングレスインタフェースから届くので、Ｐ−ＧＷ３１７Ｂはメッセージ３０３Ｂによって示されるトンネル、又は、メッセージ３０４Ｂによって示されるトンネルに、ＣＮ３１８Ｂが同一ドメインに存在することを示すマークを挿入する。ＵＥ３１３Ｂは、メッセージ３０３Ｂから抽出されたＳ−ＧＷ３１４Ｂによるマークの通知メッセージ、又は、メッセージ３０４Ｂを受信すると、受信したマークによってＣＮ３１８Ｂが同一ドメインに接続されていることを検出する検出処理３０５Ｂを行う。この検出処理３０５Ｂにより、ＷｉＭＡＸインタフェースがＣＮ３１８Ｂと通信を行うために選択される。
そして、最適化されたルートを経由する最適化通信を行うため、ＵＥ３１３及びＣＮ３１８Ｂは相互に双方向ＲＲを実行する。ＲＲシグナリング交換３０６Ｂの後、ＵＥ３１３ＢとＣＮ３１８Ｂとの間で交換されるデータパケット３０６Ｂは、Ｐ−ＧＷ３１７Ｂを経由せずに伝送されるようになる。なお、ＨｏＴＩメッセージがＵＥ３１３ＢのＨｏＡあてではないか、あるいは、ＨｏＴＩメッセージの送信元アドレスがＣＮ３１８ＢのＨｏＡに設定されない場合には、ＨｏＴＩメッセージでさえＰ−ＧＷ３１７Ｂ経由で伝送されない。
次に、ＣＮ３１８Ｂがドメイン外へ移動して別の外部ドメインへ移動３０７Ｂしたとする。ＣＮ３１８は外部ドメインへ移動すると、新たにＨｏＴＩメッセージ３０８ＢをＵＥ３１３Ｂへ送信する必要がある。ＨｏＴＩメッセージ３０８Ｂは、ＵＥ３１３Ｂの気付アドレスをあて先アドレスとして送信され、Ｐ−ＧＷ３１７Ｂは、このＨｏＴＩメッセージ３０８Ｂをイグレスインタフェースから受信する。
Ｐ−ＧＷ３１７Ｂは、ＵＥ３１３ＢのＷｉＭＡＸインタフェースに関連するバインディング（ＣＭＩＰｖ６バインディング）のバインディングキャッシュエントリを調べることによって、あて先アドレス（すなわち、ＵＥ３１３Ｂの気付アドレス）に関連したＨｏＡを容易に特定することが可能である。ＵＥ３１３ＢのＨｏＡを特定した後（あるいは特定前又は同時であってもよい）、Ｐ−ＧＷ３１７Ｂは、比較処理３０９Ｂを実行して、このパケットが監視対象のパケットであること、さらに、パケットが外部ドメインから届いていたことを特定する。
ＨｏＴＩメッセージ３０８ＢはＷｉＭＡＸインタフェースあてなので、Ｐ−ＧＷ３１７ＢはこのＨｏＴＩパケット３０８ＢをＳ−ＧＷ３１４Ｂへトンネルする必要がある。そして、ＨｏＴＩパケットはトンネリングメッセージ３１０Ｂに示すようにＳ−ＧＷ３１４Ｂへトンネルされるが、この場合、トンネルには、ＣＮ３１８Ｂが同一ドメインに存在することを示すマークが挿入されない。Ｓ−ＧＷ３１１Ｂは、トンネリングメッセージ３１０Ｂのデカプセル化後、ＨｏＴＩメッセージ３１１ＢをＵＥ３１３Ｂへ転送する。
ＵＥ３１３Ｂは、ＣＮ３１８Ｂから３Ｇインタフェース経由で届くＨｏＴＩパケットを取得するが、このＨｏＴＩパケットに関連してマークに関する情報をＳ−ＧＷ３１４Ｂから受信することはない。これにより、ＵＥ３１３Ｂは、ＣＮ３１８Ｂが別のドメイン（外部ドメイン）へ移動したことを検出することが可能となる。このような場合には、ＵＥ３１３Ｂは、最適化されたルーティング及び効率的なモビリティ管理を実現するため、３Ｇインタフェースを使用するよう決定する。上述のように、ＣＮ３１８Ｂが外部ドメインに存在し、かつＣＭＩＰｖ６モードの場合には、３Ｇインタフェースの使用によって理想的なパスが実現される。
ＨｏＴＩメッセージ３０８ＢがＳ−ＧＷ３１４へトンネルされる場合には、Ｓ−ＧＷ３１４ＢがＰ−ＧＷ３１７Ｂから提供されるサインされたトークン（ＷｉＭＡＸインタフェースに関連付けられているＨｏＡ及びＣｏＡの両方が存在していることを保証するトークン）に基づいて、ＵＥ３１３Ｂへパケットを発送してもよく、あるいは、ＵＥ３１３Ｂが、ＨｏＡ及びＣｏＡのバインディングを埋め込んで、Ｓ−ＧＷ３１４Ｂに登録してもよい。また、ＣＭＩＰｖ６バインディングを直接使用してＨｏＴＩメッセージ３０８ＢがＵＥ３１３Ｂへトンネルされ、このパケットにマークが存在しない場合においても、ＵＥ３１３Ｂは、ＣＮ３１８Ｂが別の外部ドメインへ移動したことを容易に把握することができる。
本発明では、ＵＥ３１３Ｂが、Ｐ−ＧＷ３１７Ｂへの要求（ＣＮ３１８Ｂの位置の問い合わせ）を絶えず行う必要はないという利点がある。すなわち、Ｐ−ＧＷ３１７Ｂは、メッセージ３００Ｂによって提供される初期パラメータを単に使用することで、ＣＮ３１８Ｂの位置を間単に検出することが可能であり、適切なマーク又はトリガをＵＥ３１３Ｂへ送信して、ＵＥ３１３Ｂが最適なインタフェースを選択できるようにすることが可能である。
ここで、同一ドメイン（ＵＥ３１３Ｂが存在しているドメイン）を離れたＣＮ３１８Ｂが再びそのドメインに戻ってくるとする。この場合、ＵＥ３１３Ｂがこの移動を把握するか、あるいは、この移動が行われたことを通知されることで、最適化された経路の実現が再び可能となる。
ＣＮ３１８Ｂが外部ドメインに存在している際は、ＵＥ３１３Ｂは、３Ｇインタフェースを使用している。ここで、ＣＮ３１８Ｂが同一ドメインに戻ってきた場合には、Ｐ−ＧＷ３１７Ｂは、ＣＮ３１８Ｂが戻ってきたことを検出し（例えば、ＣＮ３１８Ｂから送信されたＨｏＴＩメッセージの検出などによって）、ＣＮ３１８Ｂが同一ドメインに存在していることを示すマークを埋め込んでＵＥ３１３Ｂへ通知する。
ＣＮ３１８Ｂは、ホームドメイン（この場合、同一ドメイン）に戻ると、ＨｏＴＩメッセージをＵＥ３１３Ｂへ送信する。このＨｏＴＩメッセージは、Ｐ−ＧＷ３１７Ｂのイングレスインタフェースから受信され、Ｐ−ＧＷ３１７Ｂは、ＣＮ３１８Ｂがホームドメインに戻ってきたことを検出し、帯域内シグナリング又は帯域外シグナリングを使用してマークを埋め込んでＵＥ３１３Ｂへ通知する。ＵＥ３１３Ｂはこのマークを検出すると、ＣＮ３１８Ｂとの通信に関してＷｉＭＡＸインタフェースの使用へ切り換えるとともに、ＣＭＩＰｖ６モビリティ管理を使用することで、ＣＮ３１８ＢとのＲＯを実現する。なお、ネットワークエンティティが適切なインタフェースに関する情報（どのタイプのインタフェースが適切か）を提供してもよいが、最終的にどのインタフェースを使用するかは、ＵＥによって決定される。同様の決定は、ＣＮ３１８ＢがＰＭＩＰｖ６を使用していて、かつホームドメインから別のドメインへ移動しているときにも実行される。ホームドメインは、ＵＥ３１３ＢとＣＮ３１８ＢのＨＰＬＭＮである。ＣＮ３１８ＢがＵＥ３１３Ｂと同じドメインにいる際には、ＣＮ３１８ＢがＵＥ３１３Ｂと同じドメインにいることが、埋め込まれたマークによってＵＥ３１３Ｂへ通知される。ＣＮ３１８Ｂが位置するドメインやモビリティ管理モードを使うことで、ＵＥ３１３Ｂは適切なインタフェースやモビリティ管理モードを使うことができる。
なお、ここでＣＮが同一ドメインに存在する場合にマークを挿入し、ＣＮが同一ドメインに存在しない場合にマークを挿入しないようにしているが、その逆（ＣＮが外部ドメインに存在する場合にマークを挿入し、ＣＮが外部ドメインに存在しない場合にマークを挿入しない）や、それぞれ異なる意味を持つマークを挿入する（ＣＮが同一ドメインに存在する場合にＣＮが同一ドメインに存在することを意味するマークを挿入し、ＣＮが外部ドメインに存在する場合にＣＮが外部ドメインに存在することを意味するマークを挿入する）こともできる。マークの種別が増えると通知する情報が増加する反面、より細かな状態（ＭＡＧ間ＲＯが存在（後述）の場合など）を個別に表現できるようになる。
＜第５の実施の形態：過渡的な条件におけるＵＥのインタフェース選択処理＞
本発明の第５の実施の形態では、ＵＥが既存のＣＮに加えて、新たなＣＮと通信を開始することを決定した場合の処理（以下、第１の過渡的な処理と呼ぶ）、又は、ＵＥが複数のＣＮに対して既存のセッションを有している状態から、既存のＣＮとの間で新たなセッションを開始することを決定した場合の処理（以下、第２の過渡的な処理と呼ぶ）において、ＵＥが行うインタフェース選択処理について説明する。
以下、ＵＥが通信を行うためのインタフェースを選択する際に用いる方法について、図３Ｃ及び図３Ｄに示すメッセージシーケンスチャートを参照しながら説明する。図３Ｃに図示されているメッセージシーケンスチャートは、第１の過渡的な処理を示しており、図３Ｄに図示されているメッセージシーケンスチャートは、第２の過渡的な処理を示している。
本発明の第５の実施の形態では、ＵＥが、理想的なインタフェースを選択する際の決定処理に多くの基準を用いることが可能であることについて説明する。図３Ｃ及び図３Ｄにおいて、ＵＥ１３００及びＵＥ１３１３は、ＣＮとの間のセッションに関するインタフェースの選択の際に、例えば、ネットワークから提供された情報、負荷バランスに関する情報又はポリシ、フロー特性、フローのＱｏＳ要件などを選択基準として使用することが可能である。ＵＥ１３００、１３１３は、選択処理（インタフェース決定処理）において負荷バランスを重要視する場合であっても、ＵＥ１３００、１３１３が負荷バランスのみを重要視する場合や（あるいは、その電力に関してのみ重要視する場合）、電力及び負荷バランスの両方を重要視する場合などが起こり得る。本発明の第５の実施の形態では、ＵＥ１３００、１３１３が負荷バランスに関する問題のみを考慮する場合の選択処理について説明するが、インタフェースを選択する際に電力に関する問題を考慮する場合や、その他様々な基準を用いた場合においても適用可能である。
まず、第１の過渡的な処理について図３Ｃを参照しながら説明する。図３ＣのＵＥ１３００は、例えば、ＬＴＥインタフェース１３００Ａ及びＷｉＭＡＸインタフェース１３００Ｂなどの２つのインタフェースを有している。ＵＥ１３００のＬＴＥインタフェース１３００Ａのモビリティは、ＰＭＩＰｖ６メカニズムによって管理されており、ＵＥ１３００のＷｉＭＡＸインタフェース１３００ＢのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。また、ＵＥ１３００のＬＴＥインタフェース１３００ＡはＳ−ＧＷ１３０１に接続されており、ＵＥ１３００のＷｉＭＡＸインタフェース１３００ＢはＡＧＷ１３０２に接続されているとする。
また、初期状態として、ＵＥ１３００がＣＮ１３０５及びＣＮ１３０６と通信を行っており、その後、ＣＮ１３０７との通信を開始するとする。また、ＣＮ１３０５は、ＵＥ１３００が配置されているドメインとは別の管理ドメインに配置されているとし、ＣＮ１３０６は、ＵＥ１３００と同一の管理ドメインに配置されているとする。
ＣＮ１３０５は、別の管理ドメインに配置されているので、ＵＥ１３００と同一の管理ドメインに配置されているＰ−ＧＷ１３０３は、上述の実施の形態で説明した動作に基づいて、ＣＮ１３０５から届く最初のパケットにはマークの埋め込みを行わない。したがって、ＵＥ１３００は、ＣＮ１３０５との通信に、ＰＭＩＰｖ６によって管理されているインタフェース（ＬＴＥインタフェース１３００Ａ）を使用する。なお、このとき、ＵＥ１３００は、ネットワーク情報（ネットワークから提供される情報）のみを使用して、適切なインタフェースを決定する。ＣＮ１３０５と通信を行う場合のデータメッセージは、メッセージ１３０８によって示されている。
また同様に、Ｐ−ＧＷ１３０３は、上述の実施の形態で説明した動作に基づき、ＣＮ１３０６に関してはＣＮ１３０６からの最初のデータパケットにマークを埋め込むことによって、このＣＮ１３０６が同一ドメイン内に存在することを通知する。この場合、ＵＥ１３００は、ＷｉＭＡＸインタフェース１３００Ｂを使用してＣＮ１３０６と通信を行う。ＣＮ１３０６と通信を行う場合のデータメッセージは、メッセージ１３０９によって示されている。
さらに、新たなＣＮ１３０７がＵＥ１３００と通信を開始しようとしており、このＣＮ１３０７がＵＥ１３００のドメインとは別の外部ドメインに配置されているとする。ＣＮ１３０７からＵＥ１３００へ送信される最初のデータパケットは、メッセージ１３１０によって示されている。このメッセージ１３１０は、図３Ｃに示すように、Ｐ−ＧＷ１３０３によって受信（intercept）される。ＣＮ１３０７からのデータパケットは外部ドメインからＰ−ＧＷ１３０３へ届くので、Ｐ−ＧＷ１３０３は、マークを埋め込まずに、メッセージ１３１０をＳ−ＧＷ１３０１へトンネルして、ＵＥ１３００まで運ばれる。ＵＥ１３００は、このデータパケットに関連するマークを検出しないので、ＣＮ１３０７が外部ドメインに配置されていることを把握する。
ＵＥ１３００は、ＣＮ１３０７が配置されている場所（すなわち、外部ドメイン）を把握すると、インタフェース決定処理を開始する。ＵＥ１３００のフローの中には既にインタフェース間で分散されているものも存在するので、ＵＥ３００は、このインタフェース決定処理において負荷バランスを考慮し、特定のインタフェースにおけるアクセスの過負荷を防ぐことが可能である。
ＵＥ１３００が、例えばＬＴＥインタフェース１３００Ａを使用してＣＮ１３０７と通信を行うことを決定した場合には、ＷｉＭＡＸ経由のフローが１つであるのに対して、ＬＴＥアクセス経由のフローが２つとなるので、ＬＴＥアクセス経由の負荷が増大する。この場合には、ＵＥ１３００は、例えばアクセスネットワークの状態情報及びＵＥのポリシなどに基づいて、ＬＴＥアクセスの過負荷を避けることが考えられる。
ＵＥ１３００がＬＴＥインタフェース１３００ＡでＣＮ１３０７のフローを受け入れるならば、例えば、既に存在するフローをＬＴＥアクセスからＷｉＭＡＸアクセスへ移す必要があると判断してもよい。また、例えば、ＣＮ１３０５に関連するフローの平均帯域幅はさほど大きくなく、フローはハンドオフによって発生し得る遅延に耐えられると考えられるような場合には、ＵＥ１３００は、帯域幅やＱｏＳ要件などに基づいて、ＣＮ１３０５に関連するフローをＷｉＭＡＸインタフェース１３００Ｂへ移すことができると判断してもよい。この場合、ＣＮ１３０５に関連するフローをＷｉＭＡＸインタフェース１３００Ｂへ移しても、ＷｉＭＡＸアクセスは過負荷とならず、ＷｉＭＡＸインタフェース１３００Ｂへ容易に移すことが可能である。なお、ＣＭＩＰｖ６メカニズムによれば、フローを移すことでＲＯシグナリングによって大きなハンドオフ遅延が生じる可能性がある。
ＣＮ１３０５とのデータフローをＷｉＭＡＸアクセス経由に切り換えた場合には、ＣＮ１３０５とのデータフローはメッセージ１３１１によって示されるようになる。そして、ＵＥ１３００は、既に存在するＣＮ１３０５のフローの切り換えを行えたので、理想的なインタフェース（ＬＴＥインタフェース１３００Ａ）経由でＣＮ１３０７のフローを受け入れることを決定し、ＣＮ１３０７とのデータフローはメッセージ１３１２によって示されるようになる。以上のように、ＵＥ１３００は、負荷バランスなどを始めとする多数の条件に基づいて、ＣＮと通信を行うためのインタフェースを決定する方法を実行する。
次に、第２の過渡的な処理について図３Ｄを参照しながら説明する。図３Ｄにおいて、ＵＥ１３１３は、例えば、ＬＴＥインタフェース１３１３Ａ及びＷｉＭＡＸインタフェース１３１３Ｂなどの２つのインタフェースを有している。ＵＥ１３００のＬＴＥインタフェース１３１３ＡはＳ−ＧＷ１３１４へ接続されており、ＵＥ１３００のＬＴＥインタフェース１３１３ＡのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。また、ＵＥ１３００のＷｉＭＡＸインタフェース１３１３ＢはＡＧＷ１３１５へ接続されており、ＵＥ１３００のＷｉＭＡＸインタフェース１３１３ＢのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。
また、ＵＥ１３１３はＣＮ１３１８、ＣＮ１３１９、ＣＮ１３２０の３つのＣＮと通信を行うとし、初期状態として、ＵＥ１３１３がＣＮ１３１９及びＣＮ１３２０と通信を行っているとする。さらに、これらのＣＮ１３１９、１３２０はＵＥ１３１３と同一のドメインに存在しており、ＵＥ１３１３は、これらのＣＮ１３１９、１３２０とＷｉＭＡＸインタフェース１３１３Ｂを用いて通信を行っているとする。ＵＥ１３１３がＣＮ１３１９、１３２０と通信を行っていることを示すデータメッセージは、メッセージ１３２１、１３２２によって示されている。
このとき、ＵＥ１３１３が新たなＣＮ１３１８と通信を開始する場合を考える。なお、このＣＮ１３１８もＵＥ１３１３と同一のドメインに配置されているとする。このとき、ＷｉＭＡＸアクセスネットワークで何らかの輻輳が起こっているとすると、ＵＥ１３１３はＣＮ１３１８に関連したフローに関してはＬＴＥインタフェース１３１３Ａを使用することを決定する。このＵＥ１３１３による決定は、ＣＮ１３１８から送信されるフローに関するＱｏＳレベルを考慮して行われる。すなわち、ＣＮ１３１８に関連するフローに関してＲＯが行われる必要があったとしても、そのフローは、ＲＯによって受ける不利益を許容することが可能だと判断されてもよく、ＱｏＳ要件に関連して、インタフェース選択の際に負荷バランスのみ考慮されてもよい。このＬＴＥインタフェース１３１３Ａを使用するＣＮ１３１８とのデータメッセージは、メッセージ１３２３によって示されている。
その後、ＵＥ１３１３は、ＣＮ１３２０との間で新たなフロー（新たなセッション）を開始する場合を考える。この新たなフローがＵＥ１３１３のホームアドレスへ送信される場合には、そのフローはＰ−ＧＷ１３１６経由で到達することになる。このときの新たなフローの最初の通信は、メッセージ１３２４、１３２５によって示されるものとなる。
ここで、ＣＮ１３２０からの新たなフローに必要となるＱｏＳレベルが、ＣＮ１３１８に関連するフローが必要とするＱｏＳレベルより小さいと仮定する。この場合、負荷バランスを維持するために、ＵＥ１３１３は、例えば、ＣＮ１３１８のフローをＷｉＭＡＸインタフェース１３１３Ｂ（ＣＮ１３１８のフローにとっては好適なインタフェース）へ切り換えて、ＣＮ１３２０からの新たなフローをＬＴＥインタフェース１３１３Ａ経由で受け入れることを決定することが可能である。
なお、ＣＮ１３２０からの新たなフローにとって、ＬＴＥインタフェース１３１３Ａは好適なインタフェースではない。しかしながら、負荷バランスの考慮及びフローのＱｏＳレベルの差などを考慮して、ＵＥ１３１３はこのような決定を行ってもよい。なお、本明細書では説明しないが、ＵＥ１３１３がこれらのフローに関してＱｏＳレベルの調整を行うことも可能である。ＣＮ１３１８のフローがＷｉＭＡＸインタフェース１３１３Ｂへ切り換えられると、データメッセージはメッセージ１３２６に示されるようになり、ＣＮ１３２０に関連する新たなフローのデータメッセージは、メッセージ１３２７によって示されるようにＬＴＥインタフェース１３１３Ａ経由となる。
また、単にネットワークの接続状態から導かれる好適なインタフェースではなくＵＥ１３１３内の独自の考慮により使用するインタフェースを選択した場合（ＵＥ１３１３から見て好適なインタフェース選択になっている）、必ずしも通信相手であるＣＮ１３２０から見た場合の好適なインタフェース選択ではないかもしれない。このような場合に、ＣＮ１３２０が使用するインタフェースを変更したり（ＣＮ１３２０も複数インタフェースを使用できる場合）、ＵＥ１３１３に使用するインタフェースを変えるように働きかけたりするかもしれない。このような動作は必ずしも効率的ではないので、ＵＥ１３１３はこのような決定を行った旨をＣＮ１３２０に通知することが望ましい場合がある（詳細な例は後述の実施例にも含まれる）。
＜第６の実施の形態：ＵＥの動作＞
次に、本発明の第６の実施の形態として、ＵＥが多数のＣＮと通信している場合に理想的なインタフェースを選択するために実行する方法について説明する。
本発明に係るＵＥの動作のポイントは、ネットワークエンティティから受信する情報だけではなく、ＵＥが独立した決定処理を行ってＣＮとの通信に使用する理想的なインタフェースを選択することにある。
この理想的なインタフェースは、ＵＥが接続されているアクセスネットワーク間での負荷バランスのレベルを下げずに、あるいは、ＵＥにおける電力使用の質を低下させずに、経路最適化及び効率的なモビリティ管理を実現することを意味している。
本発明の第６の実施の形態においても、上述の第１の実施の形態で用いられる仮定が適用される。ＵＥが理想的なインタフェースを使用する追加基準は、例えば、バッテリ電力消費などのＵＥの電力状態、接続しているアクセスネットワークの輻輳状態、さらには、ＣＮに関連するフローのＱｏＳ要件などに基づくものである。
ＣＮ１に属するフロー１は、例えばＶｏＩＰなどのように、遅延やジッタを非常に低くする必要があるかもしれない。また、ＣＮ２に属する別のフロー２は、例えば非対話型（非インタラクティブ）のビデオオンデマンドなどのように、遅延に対してはある程度許容できるがジッタに関しては許容されないかもしれない。このような場合、ＵＥはＣＮ１のフローの経路最適化を犠牲にしたくはなく、一方、フロー２の経路最適化であれば、ある程度は犠牲にしてもよいかもしれない。
また、別の例では、ＵＥの電力状態が低く、かつ、ＵＥがＣＭＩＰｖ６インタフェースを使用してＣＮと通信を行うべきであることがネットワークエンティティから通知された場合には、ＵＥは、追加のシグナリングやＣＭＩＰｖ６に関連したシグナリングによる電力消費を抑えるために、ＣＮのフローに関して厳しい要件がない場合にはネットワークによる指示に従わないかもしれない（例えば、非対話型のビデオオンデマンドのフローはある程度の遅延が許容可能である)。
また、別の例では、ＣＮが内部ドメインに存在し、かつ、ネットワークエンティティによって埋め込まれたマークから３Ｇインタフェースを使用した方がよいとＵＥが推定した場合には、ＵＥは、３Ｇアクセスネットワークのトラフィック状態に基づいてＷｉＭＡＸインタフェースを選択し、ＣＭＩＰｖ６シグナリングを実行するかもしれない。ＵＥによるこうした決定は、例えば、３Ｇアクセスネットワークが輻輳しているという情報があり、ＵＥがＣＮのフローに関して厳しい要件がない場合（遅延に関しては許容できないが、ジッタはある程度許容されるようなフローの場合）などに行われる。この場合には、ＵＥは、より良い負荷バランスを実現するために、ネットワークから提供される情報に単純に基づいて選択されるインタフェースとは異なるインタフェースを選択することになる。
また、ＵＥは理想的なインタフェースを決定する際に、負荷バランスの問題と共に電力状態を考慮する場合もある。このように、理想的なインタフェースを選択する際に複数のパラメータを使用する場合には、理想的なインタフェースを決定する際のパラメータに重み付けが行われてもよい。ＣＮのフローがＲＯを必要としているか、あるいは、どのアクセス媒体が望ましいかなどのＣＮの要件に関する情報をＵＥが保持している場合には、ＵＥは、各ＣＮに優先度を与え、各ＣＮに対して適切にインタフェースの割り当てを行う必要がある。
例えば、ＵＥが６つのＣＮと通信しており、単にＲＯ及び効率的なモビリティ管理を得ようとしているのであれば、ネットワークは、３つのＣＮがＷｉＭＡＸインタフェースを用いて通信を行い、他の３つのＣＮが３Ｇインタフェースを通じて通信を行う必要があると判断する。ここで、電力状態が低い（使用可能な電力が少ない）とＵＥが判断した場合、ＵＥは、あるＣＮをＰＭＩＰｖ６メカニズムへ切り換えて、ＷｉＭＡＸ経由のシグナリングを低減させる必要が生じるかもしれない。
ＷｉＭＡＸインタフェースを通じて通信を行うと判断された３つのＣＮの中からどのＣＮを３Ｇインタフェースに切り換えるべきかを決定するために、ＵＥは、ＷｉＭＡＸインタフェースを使用している各ＣＮのフローに関連するＱｏＳ要件をチェックする必要がある。そして、ＵＥは、どのＣＮがハンドオフによる遅延がクリティカルとなるフローを有しているかに関して、ＷｉＭＡＸインタフェースを使用している３つのフローのチェックを行う。このとき、ＵＥは、各ＣＮのフローに優先度を付けることができるのであれば、ＰＭＩＰｖ６モビリティ管理メカニズムを使用するインタフェース又は３Ｇインタフェースへ、要件の厳しくないフローを単に移すだけでよい。このように、ＣＮに関するインタフェースの選択は、多数の条件（ネットワーク情報、ＵＥの電力状態、負荷バランス状態、ＵＥが通信している他のＣＮなど）に基づいて行われてもよい。
次に、図４に示すフローチャートを参照しながら、ＵＥの動作の一例について説明する。最初のステップＳ４００において、ＵＥは、ＵＥが通信しているＣＮがＲＯを必要としているかどうかを判断する。この判断を行うためには、例えばＱｏＳ要件が参照される。
ステップＳ４００においてＣＮがＲＯを必要していると判断された場合には、後述するステップＳ４０２に進む。
一方、ステップＳ４００においてＣＮがＲＯを必要としていないと判断された場合には、ステップＳ４０１に示すように通常の動作が実行される。ステップＳ４０１における通常の動作は、ＵＥがＲＯに適切なインタフェースに関して考慮しないことを示している。
ステップＳ４０２では、ＵＥは、最初の要求メッセージにホームアドレスを挿入してＰ−ＧＷへ送信し、すべてのＣＮの探知（監視）を要求する。このＰ−ＧＷによる探知は、どのインタフェース経由でＣＮのパケットがＰ−ＧＷへ届くかを特定することを示している。すなわち、Ｐ−ＧＷは、ＣＮのパケットがイングレスインタフェース又はイグレスインタフェースのどちらから届くかを特定する。ＣＮのパケットがイングレスインタフェースを経由して届く場合には、ＣＮが外部ドメインに存在していることを意味し、ＣＮのパケットがイグレスインタフェースを経由して届く場合には、ＣＮがＵＥと同一のドメインに存在していることを意味している。なお、上述のステップＳ４０２に関連した探知要求において、ＵＥがＨｏＡ（あるいはＣｏＡ）又はＣＮのアドレスを提供するが可能である。
ステップＳ４０２の処理後、ステップＳ４０３における制御処理が行われる。ステップＳ４０３では、Ｐ−ＧＷから新たな通知（例えば、ＣＮが同一ドメインに存在しているという通知）を受信するかどうかのチェックが行われる。この通知は、様々な形式によって可能であるが、こうした様々な形式に関しては後で例示する。この通知によって、ＣＮとのＲＯがＰＭＩＰｖ６モード又はＣＭＩＰｖ６モードを利用して実現されたほうがよいかどうかに関する重要な情報が送られる。
ステップＳ４０３において、Ｐ−ＧＷから新たな通知を受信しない場合には、ステップＳ４０４において、Ｐ−ＧＷからの標準シグナリングメッセージの処理などの通常の動作が行われる。
一方、ステップＳ４０３で新たな通知を受信した場合には、ステップＳ４０５の処理が行われる。このステップ４０５では、以下に説明するいくつかの詳細な方法を行うことが可能である。ステップＳ４０５では、ＵＥがＣＮと通信するための適切なインタフェースに関する情報を取得し、さらに、ＵＥにおけるローカルポリシを適用して適切なインタフェースを決定する処理が行われる。
ここで、ステップＳ４０５に関連した詳細な方法についていくつか説明する。なお、ステップＳ４０５で採用可能な方法は、以下に説明するいくつかの方法に限定されるものではない。
このステップＳ４０５では、例えば、ＵＥが、ネットワークによって特定（指定）されたインタフェースに基づいて、ＲＯを必要とするＣＮを分類することが可能である。例えば、３Ｇインタフェースが適切であることがネットワークから通知されると、３Ｇインタフェースに対して設定されているカウンタを１つ以上増加する。こうした分類の後、ＵＥは、理想的なインタフェースに関するネットワークからの情報によってアクセスネットワーク間の負荷バランスが影響を受けるかどうかの特定を試みる。負荷バランスが影響を受ける場合には、ＵＥは、ネットワーク側から提示されたインタフェースとは異なるインタフェースの決定を行う必要があるかもしれない。
ＵＥは、多くのポリシを適用したうえで、理想的なインタフェースに関するネットワークからの情報に従おうとするが、もし、ＵＥがネットワークからの情報に従うことができないのであれば、ＵＥは、ネットワークによって特定されたインタフェースの選択を行わない。
また、ＲＯが必要なＣＮすべてが非常に高いＱｏＳ要件を有している場合には、ＵＥは、ネットワークによって特定されたインタフェースとは異なるインタフェースを選択することはできないかもしれない。このような場合、ＲＯを必要としない何らかのＣＮ（例えばレガシのＣＮ）が存在するのであれば、ＲＯを必要としないＣＮを利用して負荷バランス条件を調整し、ＲＯを必要とするＣＮに関してネットワークによって特定されたインタフェースに従うようにする。なお、レガシのＣＮやＲＯを必要としないＣＮが得られない場合には、ＵＥはネットワークによって特定されたインタフェースに従わない決定を行うかもしれない。
また、レガシのＣＮが存在しない場合やＲＯを必要としないＣＮが存在せず、かつ、ＲＯを必要とするＣＮに関するＱｏＳ要件がそれぞれ異なっているような場合には、ＵＥは、あまりＱｏＳを必要としないＣＮを別のインタフェースへ移して、ネットワークによって特定されるインタフェースに従う必要がある。
以上のように、負荷バランス条件がより重要であり、ＣＮを移すことができないとＵＥが決定した場合には、ＵＥは、ネットワークによって提案されたインタフェースとは異なるインタフェースを選択することが可能である。このように負荷バランスに関連した問題を考慮した後、さらに、追加のチェックが実行される。例えば、ＵＥの電力状態が評価される。
ＵＥは、負荷バランスの問題を評価することで行われた決定がＵＥの電力状態に影響を及ぼすかどうかをチェックする。ＵＥの電力状態に影響を及ぼさないのであれば、その前までに選択されたインタフェース（すなわち、ネットワークによって特定された情報、及び、負荷バランスを考慮して選択されたインタフェース）が使用されることになる。
一方、ＵＥの電力状態に影響を及ぼすのであれば、ＵＥは、１つ又はいくつかのＣＮを３Ｇインタフェースへ移すとともに、ネットワークによって特定されたものに関してはＣＭＩＰｖ６インタフェースを使用するように試みる。このようなインタフェースの移し変えを行うことができない場合には、ＵＥは、電力の問題を満足するようにインタフェースを選択することになる。なお、電力状態及び負荷バランスの両方が考慮される場合には、これらの処理（これらのパラメータ）に重み付けが行われてもよい。
＜第７の実施の形態：ＭＡＧ間ＲＯが存在する場合の本発明の動作及び効果＞
本発明の第７の実施の形態では、ＭＡＧ間ＲＯが存在する場合の本発明の動作及び効果、ＣＮが堅固な特性（rigid characteristics：すなわち、状態を柔軟には変えられない特性）を持つ場合の本発明の動作及び効果について説明する。
以下、図５Ａを参照しながら、本発明の第７の実施の形態について説明する。図５Ａは、ＭＡＧ間ＲＯが存在する場合の動作を示しており、図５Ｂは、ＣＮが堅固なモビリティ管理モードを有しておりモード変更不可能な場合の動作を示している。
まず、図５Ａについて説明する。図５Ａでは、ＵＥ５０４は、例えば３Ｇインタフェース及びＷｉＭＡＸインタフェースなどの２つのインタフェースを有しており、それぞれアクセスネットワーク５０３及びアクセスネットワーク５０２を介してＥＰＣ５００へ接続されている。なお、ＵＥ５０４に関する仮定は上述の本発明の第１の実施の形態で説明したものと同様であり、説明を省略する。基本的に、ＵＥ５０４は３Ｇインタフェース経由でＰＭＩＰｖ６メカニズムを使用し、ＷｉＭＡＸインタフェース経由でＣＭＩＰｖ６メカニズムを使用している。
また、Ｐ−ＧＷ５１１がＵＥ５０４のホームエージェントであり、ドメイン５００がＵＥ５０４のホームドメインであるとする。また、ＵＥはＣＮ５１３との間でデータ通信を行っているとする。また、ＣＮ５１３はＰＭＩＰｖ６メカニズムを使用しており、ＣＮ５１３のホームドメインはドメイン５００又は別のドメインであってもよいとする。さらに、ドメイン５００にはＭＡＧ間ＲＯ（例えば、Ｓ−ＧＷ５０８とＡＧＷ５１０との間のＲＯ）が存在しているとする。なお、シグナリング５１４は、例えば、Ｐ−ＧＷ５１１によってＭＡＧ間ＲＯが確立可能であることを示している。すなわち、シグナリング５１４に示されるようなクエリを使用して、トンネル５１２の設立が必要なＭＡＧ間が特定される。ＣＮ５１３が別のホームドメインに属している場合には、Ｐ−ＧＷ５１１は、別のＰ−ＧＷと相互作用して、ＡＧＷ５１０（すなわちＭＡＧ）を特定する必要がある。また、ＭＡＧ間ＲＯは、ＲＲを用いることによって、Ｐ−ＧＷ５１１の関与を受けずに、確立することができる。
ＭＡＧ間トンネル５１２が設立される前は、データパケットがＰ−ＧＷ５１１経由で発送されると仮定すると、ＣＮ５１３がＵＥ５０４へ最初のデータパケットを送信した場合、そのデータパケットは、Ｐ−ＧＷ５１１のイングレスインタフェース経由でＵＥ５０４へ到達する。この場合、Ｐ−ＧＷ５１１は、ＭＡＧ間ＲＯが存在していることを把握しており（Ｐ−ＧＷ５１１がＭＡＧ間ＲＯの確立を援助すると仮定する）、トンネルパケットにはマークを付けない。データパケットにマークが付けられていないことから、ＵＥ５０４は、本発明の動作に従って、３Ｇインタフェースを使用してＣＮ５１３との通信を行う。なお、３Ｇインタフェースは、ＭＡＧ間ＲＯが存在する場合に理想的なインタフェースである。
一方、Ｐ−ＧＷ５１１がＭＡＧ間ＲＯを援助しない場合には、最初のデータパケットは、Ｐ−ＧＷ５１１を経由せずにＭＡＧ間で伝送されるかもしれず、その結果、Ｐ−ＧＷ５１１はマークを付けることができない。このような場合であっても、最初のデータパケットにマークが付けられていないことから、ＵＥは、ＣＮ５１３と通信を行うために理想的なインタフェース（すなわち、３Ｇインタフェース）を選択することが可能である。
なお、ここでは、Ｐ−ＧＷ５１１の動作は、上述した実施の形態で説明したものと異なっていることが重要である。
次に、図５Ｂについて説明する。ここでは、上述の図５Ａと同様の仮定を行うが、ＣＮ５２６のホームドメインがホームドメイン５１５であると仮定する。また、ＣＮ５２６のモビリティはＰＭＩＰｖ６メカニズムによって管理され、このモビリティ管理モードが静的であるとする。
図５Ｂ中のメッセージ５５６は、ＣＮ５２６からＵＥ５１６へ送信される最初のデータパケットを示している。このメッセージ５５６は、Ｐ−ＧＷ５２２経由でトンネルされる。Ｐ−ＧＷ５２２はＣＮ５２６がＰＭＩＰｖ６メカニズムを使用していることを特定し、さらに、ＣＮ５２６へ割り当てられた静的モビリティモードに関する情報を保持しているかもしれないことを特定する。このような場合には、データパケットがＰ−ＧＷ５２２のイングレスインタフェース経由で伝送されるとしても、Ｐ−ＧＷ５２２はデータパケットにマークを付けない。
ＵＥ５１６は、メッセージ５５６のデータパケットを受信したとき、データパケットに明示的に付けられているマーク、あるいは、明示的に通知されるマークを確認することはない。したがって、ＵＥ５１６は、ＰＭＩＰｖ６メカニズム、すなわち３Ｇインタフェースを使用する。ＣＮ５２６はＣＭＩＰｖ６モードへ切り換えることができないので、ＵＥ５１６に対してＣＭＩＰｖ６インタフェースを使用することはない。したがって、本発明の動作によって実現される理想的なパスは図５Ｂのメッセージ５２７によって示されるものとなる。
また、Ｐ−ＧＷ５２２はＣＮ５２６がモビリティ管理モードを切り換えることができないという情報をＵＥ５１６へ提供してもよい。これによって、ＵＥ５１６が、ＣＮ５２６に対してモビリティ管理モードの切り換えを要求しないようにすることが可能となる。
＜第８の実施の形態：ＵＥの機能アーキテクチャ＞
本発明の第８の実施の形態では、本発明を実行するＵＥの機能アーキテクチャの一例について説明する。図６には、本発明を実現するために必要なＭＩＰｖ６機能を有するＵＥの機能アーキテクチャ６００の一例が図示されている。
図６に図示されている機能アーキテクチャ６００は、下位レイヤプロトコルモジュール６０８、レイヤ３プロトコルモジュール６０２、上位レイヤプロトコルモジュール６０１の３つの主要な機能モジュールを有している。
下位レイヤプロトコルモジュール６０８は、ＵＥのインタフェースに直接関連する複数の下位レイヤプロトコルモジュールを有している。例えば、ＵＥがｎ個のインタフェースを有している場合には、下位レイヤプロトコルモジュールも同一の個数ｎだけ存在する。この下位レイヤプロトコルモジュール６０８には、信号変調、エンコード圧縮、メディアアクセス制御、リンクレイヤ制御などのメカニズムなどを始めとする基本的なデータ通信に必要な機能、及び、ＵＥの複数インタフェース（マルチインタフェース）に必要な機能などを始めとする物理層及びデータリンク層全体の機能が実装されている。
この下位レイヤプロトコルモジュール６０８は、さらに、下位レイヤシグナル受信部６０７を有している。下位レイヤシグナル受信部６０７は、本発明に係る主要な信号処理をサポートしており、例えば、Ｓ−ＧＷ（あるいはＰ−ＧＷ）から受信したマークを受け取る受信機能を有している。例えば、第１の実施の形態で説明したマークに関してＰ−ＧＷからＳ−ＧＷへ通知が行われた場合、Ｓ−ＧＷは、Ｌ２の方法を利用して、ＵＥへその情報を渡すことが可能である。このマークの情報は、Ｌ２トンネルでデータパケットをカプセル化し、Ｌ２トンネルにマークを挿入することによって送信可能である。なお、ＰＭＩＰｖ６メカニズムを使用するインタフェースへ接続されているＳ−ＧＷがＵＥへの最初のホップのルータである場合には、単純なＬ２シグナリングを使用してマークの情報がＵＥへ送信されてもよい。
下位レイヤシグナル受信部６０７はＬ２信号を受信し、シグナリングインタフェース６０６によって、レイヤ３プロトコルモジュール６０２へ必要な情報を渡すことが可能である。レイヤ３へ渡された情報には、マークをＰ−ＧＷから受信したかどうかを示す情報が含まれている。例えば、このマークの情報は、インタフェースの選択を行うＭＮ処理部（インタフェース選択に関するＭＮ処理部６０３）であるＬ３サブモジュールへ送信される。
機能アーキテクチャ６００の中間層は、図６中のレイヤ３プロトコルモジュール６０２である。レイヤ３プロトコルモジュール６０２は、例えば、ＩＰｖ６ルーティング部６０５、ＭＩＰｖ６モビリティ管理部６０４、ＭＮインタフェース選択に関するＭＮ処理部６０３、マルチインタフェースＣＮとのＲＯに関するＭＮ処理部６１５、ＣＮデータベース６１４を有している。
ＩＰｖ６ルーティング部６０５はシグナリングインタフェース６０９によって、ＭＩＰｖ６モビリティ管理部６０４はシグナリングインタフェース６１０によって、インタフェース選択に関するＭＮ処理部６０３へ接続されている。さらに、ＩＰｖ６ルーティング部６０５はシグナリングインタフェース６１１によって、ＭＩＰｖ６モビリティ管理部６０４はシグナリングインタフェース６１２によって、下位レイヤプロトコルモジュール６０８へ接続されている。また、インタフェース選択に関するＭＮ処理部６０３はインタフェース６１３によってＣＮデータベース６１４へ接続されている。
ＩＰｖ６ルーティング部６０５の主要な機能は、パケットの発送、アドレス構成、近隣探索などである。ＭＩＰｖ６モビリティ管理部６０４は、単一又は複数のインタフェースに関して、モバイルノードのモビリティ管理を行うことが可能であり、ＭｏＮＡＭＩ６タイプのバインディングの処理を行うことも可能である。ＭＩＰｖ６モビリティ管理部６０４は、Ｐ−ＧＷから送信されたマークを特定し（例えば、ＵＥのＷｉＭＡＸインタフェースへマークが直接送信された場合）、インタフェース選択に関するＭＮ処理部６０３へ通知する。この情報に基づいて、インタフェース選択に関するＭＮ処理部６０３は、ネットワークによって選択されたインタフェースを把握する。
なお、Ｐ−ＧＷは、トンネルにマークを挿入し、ＷｉＭＡＸインタフェースへデータパケットをトンネルしてもよい。例えば、ＩＣＭＰｖ６メッセージなどのＬ３メッセージ（明示的なメッセージであり、データパケットとは関連していないメッセージ）を用いてＳ−ＧＷ又はＰ−ＧＷからＵＥへ直接マークが送信された場合には、ＩＰｖ６ルーティング部６０５がマーク又はそのメッセージをインタフェース選択に関するＭＮ処理部６０３へ渡す。また、マークが新たなオプションを有するモビリティヘッダメッセージやモビリティヘッダによって送信された場合も、ＭＩＰｖ６モビリティ管理部６０４で処理されてから、同様にインタフェース選択に関するＭＮ処理部６０３へ送られる。なお、インタフェースを選択する際に行われるＵＥの詳細な動作について説明したように、ＵＥは多くの基準を利用して理想的なインタフェース（正しいインタフェース）の選択を行う。
インタフェース選択に関するＭＮ処理部６０３が行う主要な決定処理のいくつかは、マークが存在しているかどうかをＵＥがチェックする処理に関連している。インタフェース選択に関するＭＮ処理部６０３は、ＵＥのホームアドレスあてのパケットにマークが存在していない場合は、ネットワークによって３Ｇインタフェースが特定（指定）されていることを把握し、一方、マークが存在している場合には、ネットワークによってＷｉＭＡＸインタフェースが特定（指定）されていることを把握する。
また、マークがデータパケットに埋め込まれずに独立したメッセージとして送信される場合には、このメッセージはＣＮに関連するパラメータを有する必要がある。なお、メッセージ形式の詳細に関しては後述する。ネットワークによって指定されたインタフェースが特定されると、インタフェース選択に関するＭＮ処理部６０３は、ＣＮデータベース６１４を使用してもよい。
また、ＣＮデータベース６１４は、ＣＮに関連する異なるすべてのＱｏＳパラメータを有している。ＣＮデータベース６１４は、例えば、ＱｏＳ要件に基づいてＣＮ又はフローの優先度を分離できる情報を有していてもよい。
また、マルチインタフェースＣＮとのＲＯに関するＭＮ処理部６１５は、複数インタフェースのＣＮとの間におけるＲＯ処理を行う機能を有している。このマルチインタフェースＣＮとのＲＯに関するＭＮ処理部６１５は、複数インタフェースのＣＮと通信を行う際に必要となる追加のシグナリングの処理のみを行う。マルチインタフェースＣＮとのＲＯに関するＭＮ処理部６１５は、主に、どのエンティティがＣＮへネットワーク状態を通知するかを交渉する機能を有している。マルチインタフェースＣＮとのＲＯに関するＭＮ処理部６１５は、特定のインタフェースの使用をＵＥが複数インタフェースのＣＮに対して要求するシグナリングを行う機能を有しており、また、選択されたインタフェース、ネットワーク情報、ＣＮに対して特定のインタフェースの使用の要求などを、例えば、単一のシグナリングメッセージを用いて送信する機能を有している。
なお、図６に図示されているＵＥに実装された機能は一例であり、本発明の範囲を逸脱しない別の機能実装方法が存在し得ることは当業者にとって明らかである。
＜第９の実施の形態：ＬＭＡ／Ｐ−ＧＷのアーキテクチャ＞
本発明の第９の実施の形態では、本発明を実行するＰ−ＧＷ（あるいはＬＭＡ／ＨＡ）の機能アーキテクチャの一例について説明する。図７には、本発明を実現するために必要なＭＩＰｖ６機能を有するＰ−ＧＷの機能アーキテクチャ７００の一例が図示されている。
図７に図示されている機能アーキテクチャ７００は、下位レイヤプロトコルモジュール７０６、レイヤ３プロトコルモジュール７０１を有している。
下位レイヤプロトコルモジュール７０６は、すべてのデータリンクレイヤに関する機能や帯域幅レベルに関する機能を有している。
また、レイヤ３プロトコルモジュール７０１は、ＩＰｖ６ルーティング部７０５、ＭＩＰｖ６モビリティ管理部７０４、経路最適化支援部７０３、ＰＭＩＰｖ６モビリティ管理部７０２を有している。なお、図７ではこれらのモジュール間における適切なインタフェースは明示されていないが、こうしたインタフェースが存在しており、モジュール間でパラメータの受け渡しを行うことが可能である。
ＩＰｖ６ルーティング部７０５は、例えば、基本的なルーティング、アドレス構成、近隣探索などの標準のＩＰｖ６メカニズムの機能を有している。
また、ＭＩＰｖ６モビリティ管理部７０４は、ＭｏＮＡＭＩ６機能を付加的にサポートするＭＩＰｖ６ホームエージェントと同一の機能を実現する。ＭＩＰｖ６モビリティ管理部７０４は、例えば、ＣＭＩＰｖ６バインディングアップデートの処理、バインディングアップデートに関するＡＣＫ信号の送信、データパケットのトンネリング、バインディングキャッシュの維持などを行う。
また、ＰＭＩＰｖ６モビリティ管理部７０２は、ＰＭＩＰｖ６に関連する文献（非特許文献２など）に開示されている基本的なＬＭＡ機能を実装している。
また、経路最適化部７０３は、例えば、以下の機能を有している。経路最適化部７０３は、ＵＥから送信される新たなメッセージを処理する機能を有している。この新たなメッセージは、ホームアドレスあてに送られてくるパケットやあるＣＮ（あるいは、ＣＮのグループ）から送られてくるパケットの探知（監視）を要求するためのものである。
また、経路最適化部７０３は、ＭＡＧ間トンネルが存在しない場合やＣＮで静的なモビリティモードが構成されていない場合に、データパケットがイングレスインタフェース経由で発送されたかどうかを検出する機能を有している。
また、経路最適化部７０３は、独立したメッセージを用いてＣＮが同一ドメインに存在していることを示すマークを明示的にＵＥへ通知する機能、又は、ＭＡＧ経由でデータパケットがトンネルされる場合やＣＮが同一ドメイン内に存在する場合にＵＥへトンネリングされるデータパケットにマークを挿入して暗示的に通知する機能を有している。
また、経路最適化部７０３は、ＭＡＧ間ＲＯが存在する場合やＣＮが静的なモビリティ管理モードである場合には、たとえ最初のデータパケットがＰ−ＧＷのイングレスインタフェース経由で発送されていたとしても、マークを送信しないようにする機能を有している。
＜第１０の実施の形態：マークの挿入が可能なメッセージのタイプ＞
本発明の第１０の実施の形態では、上述の第１の実施の形態で説明したマークをＵＥに送信可能とする様々なメッセージについて説明する。
例えば、ＣＮが同一ドメインに存在していることを示すマークは、明示的なメッセージによって、あるいは、データパケットに付加されて送信可能である。データパケットにマークが付加されて送信される場合には、付加的なシグナリング（すなわち、明示的なメッセージ）は不要になるという利点がある。しかしながら、追加情報が挿入されることでデータパケットが大きくなってしまうという問題もある。例えば、拡大されたデータパケットが経路上で破棄されたり断片化されたりするおそれが生じる。
Ｐ−ＧＷは、マークの挿入が必要であることを検出した場合には、Ｓ−ＧＷへトンネルされるデータパケットにマーク情報を添付することが可能である。マークは、例えば、追加拡張ヘッダとしてトンネルヘッダに挿入され、このパケットは、例えば図８に図示されているパケット８１４のようになる。
例えば、図３ＡのＰ−ＧＷ３１６Ａは、ＵＥのホームアドレスあての最初のパケットを取得する。ＰＭＩＰｖ６バインディングがＰ−ＧＷに存在していると仮定すると、データパケットは、ＰＭＩＰｖ６バインディングを使用して作成されるＳ−ＧＷとＰ−ＧＷとの間のトンネルを用いて、Ｓ−ＧＷへトンネリングされることになる。
このトンネリングされるデータパケットは、ＩＰｖ６ヘッダ８１５、トンネルを有効にする認証ヘッダ８１６、トンネルエンドポイントが参照可能なあて先オプションヘッダ８１７を有している。なお、トンネルエンドポイントは、図３ＡのＭＡＧ又はＳ−ＧＷを示している。また、トンネルヘッダに続いて、トンネルされるデータパケットが埋め込まれている。このデータパケットには、通常のＩＰｖ６ヘッダ８１８及びデータパケット８１９そのものが含まれている。
あて先オプションヘッダ８１７は、マークを示す新たなオプションを有している。このマークを受信したＳ−ＧＷは、トンネルをデカプセル化した後、Ｌ２トンネリング又はＥ−ＵＴＲＡＮで現在使用されているＧＴＰタイプのトンネリングを使用して、内部データパケットをＵＥの３Ｇインタフェースへトンネルする必要がある。Ｓ−ＧＷとＵＥとの間のトンネルによってこのマークを運ぶことが可能である。なお、当業者であれば、パケット８１４としてデータパケットを使用する際には、ＣＮアドレスを含ませる必要がないことは明らかである。すなわち、ＣＮアドレスはＩＰｖ６ヘッダ８１８に挿入されている。なお、ＣＮアドレスは、ネットワークによって選択されたインタフェースがどのＣＮと関連付けられているかをＵＥが特定するために必要不可欠な情報である。
また、別の方法として、Ｓ−ＧＷでデータパケットのデカプセル化を行った後、Ｓ−ＧＷがＬ２ヘッダを使用して、アクセスに特有のメカニズムによってＵＥへデータパケットを送信することも可能である。例えば、ＵＥが直接Ｓ−ＧＷ（ＭＡＧ）へ接続されている場合には、こうしたパケット転送が起こり得る。
このＬ２ヘッダは、Ｓ−ＧＷが特定したマークを伝送することが可能であり、例えば図８に示すフレーム８０７によって実現可能である。フレーム８０７は、マークに関する情報を運ぶ上述のＬ２メッセージのフレーム構造の一例である。フレーム８０７において、最初のフィールドは、フレームの開始を示すフラグフィールド８００である。また次のフィールドは、メディアアクセス制御アドレス（ＭＡＣアドレス）フィールド８０１である。このＭＡＣアドレスフィールド８０１には、Ｌ２ヘッダの送信元及びあて先アドレスが記載される。例えば、送信元アドレスはＭＡＧ（Ｓ−ＧＷ）のイングレスインタフェースのＭＡＣアドレスであり、あて先アドレスはＵＥのＭＡＣアドレスである。
続くフィールドは、使用される特定のタイプのフレームを識別するための制御フィールド８０２である。この制御フィールド８０２は、受信者がＬ２フレームを正しく処理するために必要不可欠である。基本的に、制御フィールド８０２によって、フレームのタイプ又はメッセージのタイプが特定される。
続くフィールドはプロトコルＩＤフィールド８０３であり、より高いレイヤで生み出されたパケットに関する値が記載される。また、続くフィールドは情報フィールド８０４であり、この情報フィールド８０４によってマークの情報が運ばれる。
フィールド８０４に続いて、フレームチェックシーケンスフィールド８０５が存在する。送信者及び受信者はフレームチェックシーケンスフィールド８０５の値を計算する。この値は、フレームが改ざん無く伝送されていることを確認するために使用される。そして、最後のフィールドは、フレームの区切り（基本的に、フレームの終わりを特定する）として使用されるフラグフィールド８０６である。なお、フレーム８０７の構造は一例であり、このフレーム８０７の構造とは異なる別のフレーム構造を用いて送信されてもよい。なお、Ｌ２ヘッダは、リンクレイヤ特有の構造を有しており、フレーム８０７は一般的な構造を利用したものである。
また、Ｐ−ＧＷがマークを通知するための明示的なシグナリングを使用する場合には、メッセージ８１３、８３１、あるいは８４１が使用可能である。
ＵＥに関連するあるＣＮに関してマークの通知が必要であるとＰ−ＧＷが判断した場合、例えば、メッセージ８１３又はメッセージ８３１がＳ−ＧＷへ直接送信されるシグナリングメッセージとして利用可能である。
メッセージ８１３は新たなモビリティ拡張ヘッダ８１０を有する新たなシグナリングメッセージである。新たなモビリティ拡張ヘッダ８１０にはマークを特定する情報が挿入される。さらに、ＵＥがＣＮを特定することが可能なＣＮ識別子（ＣＮアドレス又はその他のＣＮ識別情報）がＣＮ識別子フィールド８１２によって運ばれる。
Ｓ−ＧＷは、このメッセージ８１３を受信すると、ＩＣＭＰｖ６制御メッセージ８４１を使用してＵＥへＣＮ情報を送信する。このＩＣＭＰｖ６制御メッセージ８４１には、メッセージにＣＮ識別子が挿入される。この場合、新たなタイプのＩＣＭＰｖ６制御メッセージが使用される必要があるかもしれない。また、Ｐ−ＧＷは、メッセージ８４１のフォーマットのＩＣＭＰｖ６制御メッセージをＵＥへ直接送信することも可能である。この場合、ＩＣＭＰｖ６制御メッセージのあて先アドレスはＵＥのホームアドレスとなり、送信元アドレスはＰ−ＧＷアドレスとなる。また、ＩＣＭＰｖ６制御メッセージによってマークが通知されるが、このときマークが挿入されてもよく、あるいは、例えばＣＮ識別子の存在がマークの通知を意味するよう定められてもよい。
また、明示的なメッセージを送信する別の方法として、ＰＭＩＰｖ６タイプのメッセージフォーマットを使用したメッセージ８３１が送信されてもよい。しかしながら、この場合には、ＣＮアドレスは、オプション８３６で示されるような新たなモビリティオプションを使用して埋め込まれる。Ｓ−ＧＷがこの新たなモビリティオプション８３６の処理を行うとき、マークは潜在的に埋め込まれることを意味する（すなわち、新たなモビリティオプション８３６の存在がマークを意味する）。しかしながら、このメッセージ８３１はＳ−ＧＷまでしか有効ではないので、ＵＥへマークを伝送するためには別の独立したメッセージがＵＥへ送信される必要があり、Ｓ−ＧＷからＵＥへのマークの通知は、例えば、上述したものが使用可能である。
また、ＣＭＩＰｖ６バインディングがＰ−ＧＷで利用可能であれば、別のタイプのメッセージを利用して、マークの通知が行われてもよい。これらのメッセージの一例は、図８のメッセージ８５１、８２５に図示されている。メッセージ８５１及び８２５は共に、明示的なメッセージのフォーマットの一例を示している。なお、本明細書における「明示的」とは、データパケットに挿入されずに、独立したメッセージによってマークが送信されることを意味している。
メッセージ８５１、８２５は両方共、ＵＥの気付アドレスをあて先とする。また、マークは、ＢＵモビリティ拡張ヘッダを使用して伝送される。メッセージ８５１では、ＣＮアドレスは新たなモビリティオプション８２４によって伝送される。さらに、この新たなモビリティオプション８２４によってマークが特定される。
また、メッセージ８２５が使用される場合には、マークはフィールド８２９のフラグによって特定される。また、メッセージ８２５では、ＣＮ識別子は標準のモビリティオプション８３０に挿入される。なお、明示的にマークを有するメッセージがＷｉＭＡＸインタフェースを利用するメッセージ８４１によって送信されてもよいことは明らかである。また、ＵＥのホームアドレスをあて先とするＣＮのデータパケットはＰ−ＧＷからＵＥの気付アドレスへ送信されてもよく、このトンネルヘッダが、パケット８１４と同様にマークの情報を運ぶあて先オプションヘッダを有していてもよい。
＜第１１の実施の形態：Ｐ−ＧＷがプレフィックスリストを提供する別の方法＞
本発明の第１１の実施の形態では、本発明を実現するための別の方法について説明する。この別の方法は、主に、ＵＥがＣＮの位置に関する情報を持っておらず、ＲＯ及びＣＮとの効率的なモビリティ管理を実現するために理想的なインタフェースを選択できない場合の問題を解決するために用いられる。この場合、ＵＥは、ＣＮが配置されているネットワークから提供される情報を用いることを決定して、理想的なインタフェースを選択する。
本発明の方法の一例は、上述のように、ネットワークが同一ドメインから届くパケットにマークを付けるものであるが、別の方法として、ドメインで所有されているプレフィックスをＵＥがＰ−ＧＷから取得する方法を行うことも可能である。ＵＥは、Ｐ−ＧＷへ明示的に要求することで、これらのプレフィックスを取得することが可能である。Ｐ−ＧＷから取得されたプレフィックスリストに基づいて、ＵＥはＣＮアドレスプレフィックスをＵＥで参照可能な上記プレフィックスリストと比較する。ＣＮのプレフィックスに関して一致するエントリが存在する場合には、ＵＥは、ＣＮが同一ドメインに存在していることを把握し、第１の実施の形態で説明されているように、ＣＭＩＰｖ６インタフェース（あるいは、ＷｉＭＡＸインタフェース）を選択的に使用する。一方、ＣＮのプレフィックスに関して一致するエントリが存在しない場合には、ＵＥは、ＣＮが外部ドメインに存在していることを把握し、ＰＭＩＰｖ６インタフェース（あるいは、３Ｇインタフェース）を使用する。
上述の別の方法によれば、ネットワークエンティティにおいて、ＣＮの位置を探知するための処理（ＣＮからのパケットの監視）の負荷が軽減されるという利点がある。すなわち、ＣＮの位置を探知するための処理のほとんどがＵＥによって行われる。この方法は、オペレータがネットワークエンティティの処理負荷を低減させようとした場合に有用であり、本発明に係る効果も実現可能である。
＜第１２の実施の形態：ＣＮのＰ−ＧＷがＵＥのＰ−ＧＷを援助する別の方法＞
次に、本発明の第１２の実施の形態として、本発明を実現するための別の派生例について説明する。この別の派生例は、ＣＮが外部ドメインに配置されている場合にのみ適用される。以下、ＣＮが外部ドメインに配置されている図１Ｂを参照しながら、第１２の実施の形態に係る派生例について説明する。
ＣＮが外部ドメインであってそのホームドメインに存在する場合（例えば、ドメイン１２５がホームドメインである場合）、Ｐ−ＧＷ又はＣＮのホームモビリティアンカはデータパケット（ＣＮのＨｏＡからＵＥのＨｏＡへ送信されるデータパケット）をＵＥのホームモビリティアンカ（Ｐ−ＧＷ１２１）へトンネルすることが可能である。このようなトンネルは、マークの必要性を判断するためにこのパケットを精査する必要があることを、Ｐ−ＧＷ１２１が把握できるように作成される。ＣＮのＰ−ＧＷは、ＣＮ１２２に関連するＣＮを探知（監視）する機能を有しており、これによって、ＣＮのＰ−ＧＷは、ＵＥのＨｏＡを特定して特別なトンネルを挿入する。
このトンネル（トンネルのソースはＣＮのＰ−ＧＷであり、トンネルのあて先はＵＥのＰ−ＧＷである）を監視することで、ＵＥのＰ−ＧＷは、格納情報を検索することなく、このパケットにマークをつける必要がないことを特定することが可能である。このように、ＣＮのＰ−ＧＷのサポートによって、ＵＥのＰ−ＧＷの処理負荷は低減される。一方、Ｐ−ＧＷ間で何らかのタイプの協働があるのであれば、さらに本発明に係る概念をサポートして、ネットワークエンティティの処理負荷を著しく低減させることが可能なメカニズムの実装が可能である。
＜第１３の実施の形態：ＣＮも複数インタフェースを有する場合の拡張方法＞
本発明の第１３の実施の形態では、本発明が動作し得る様々なシナリオ、及び、本発明の様々な動作についても説明する。なお、本発明の第１３の実施の形態で説明する様々なシナリオは、ＣＮも複数インタフェースを有しており、本発明の第１の実施の形態に係る機能を実装し得る場合である。
以下、図９を参照しながら、本発明の第１３の実施の形態に係るシナリオを説明する。ＵＥ９０５は２つのインタフェースを有しており、ＵＥ９０５の３ＧインタフェースはＳ−ＧＷ９０７に接続されており、ＷｉＭＡＸインタフェースはＡＧＷ９０８に接続されているとする。また、ＵＥ９０５の３ＧインタフェースのモビリティはＰＭＩＰｖ６メカニズムによって管理されており、ＵＥ９０５のＷｉＭＡＸインタフェースのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。さらに、Ｐ−ＧＷ９１５がホームモビリティアンカポイントであるか、あるいはＵＥ９０５のＨＡであると仮定する。
また、ＵＥ９０５は、このＣＮ９０６と通信を行っているとする。このＣＮ９０６も複数インタフェース（３Ｇインタフェース及びＷｉＭＡＸインタフェース）を有しており、ＣＮ９０６の３ＧインタフェースはＳ−ＧＷ９０９に接続されており、ＷｉＭＡＸインタフェースはＡＧＷ９１０に接続されているとする。また、図９のＵＥ９０５及びＣＮ９０６は両方共、同一ドメイン９００に接続されているとする。さらに、ＣＮ９０６のホームエージェントはＰ−ＧＷ９１５であると仮定する。また、ＣＮ９０６は、本発明の機能として説明した、マークを要求する機能、マークを処理して理想的なインタフェースを選択する機能を有しているとする。
このような環境では、ＵＥ９０５及びＵＥ９０６の両方が他のノードの探知（監視）を要求した場合には、無駄なシグナリングが発生する。すなわち、ＵＥ９０５がＣＮ９０６の探知をＰ−ＧＷ９１１へ要求すると同時に、ＣＮ９０６がＵＥ９０５の探知をＰ−ＧＷ９１１へ要求するような場合には、無駄なシグナリングが発生する。この場合には、任意のフローのピアであるノードの一方がこのような本発明に係るシグナリングを実行し、他のピアにその結果を渡すことが望ましい。
例えば、図９のＵＥ９０５及びＣＮ９０６の両方がＲＯ及び効率的なモビリティ管理を行おうとしている場合に、ＵＥ９０５及びＣＮ９０６は、まずどちらが理想的なインタフェースの探索を行うかを調整することが可能である。このような調整は、例えば、帯域シグナリング、帯域外シグナリング、手動構成などによって行われてもよい。
こうした調整の後（例えば、ＵＥ９０５がインタフェースの探索を行うと仮定する）、ＵＥ９０５は、上述の動作によって、ネットワークから通知されるマークから、ＣＮ９０６が同一ドメインに存在することを特定することが可能である。この場合には、両者共に同一ドメインに存在しており、ＣＮ９０６がＣＭＩＰｖ６インタフェースを使用すべきであるという最終的な通知をＣＮ９０６に対して送信することが可能である。このようにＵＥ９０５によって行われたシグナリングによって、ＣＮ９０６が理想的なインタフェースの選択処理を積極的に行わずに済み、ＣＮ９０６に関連する処理負荷やシグナリングは低減され得る。
また、ＵＥ９０５が、ネットワークによって特定されたインタフェースではなく、別のインタフェースを発見した場合には、ＵＥ９０５は、ネットワークが選択したインタフェース及びＵＥが選択したインタフェースの両方をＣＮ９０６に対して提供してもよい。ＣＮ９０６がネットワークによって特定されたインタフェースの方がより安定するという情報を有している場合には、ＣＮ９０６は、自身のインタフェースを選択する際にネットワークによって特定されたインタフェースを選択し、そうでなければ、ＣＮ９０６は、ＵＥ９０５によって選択されたインタフェースに基づいたインタフェースの選択を行う。
ネットワークによって選択された情報を使用する場合、例えば、ＣＮ９０６は、ＣＭＩＰｖ６インタフェースを使用する。一方、ＣＮ９０６は、ＵＥによって選択されたインタフェースに基づいて、ネットワークによって特定されたインタフェースとは異なるインタフェースを選択する場合には、ＣＮ９０６は３Ｇインタフェースを使用してもよい。
また、ＣＮ９０６は、ＣＮ９０６によるインタフェースの決定結果によってＵＥ９０５が影響を受けると予測した場合には、ＵＥ９０５に対してこのＣＮ９０６によるインタフェースの決定結果を通知してもよい。
例えば、ＵＥ９０５がネットワークによって選択されたインタフェースに従わないインタフェースを選択した場合、ＵＥ９０５は、ＵＥ−ＣＮ通信に望ましいインタフェースの選択をＣＮ９０６に対して要求する場合が考えられる。例えば、このトラフィックフローがジッタを許容しない場合には、ドメイン内のピアノードの移動の間に生じるシグナリングの遅延を低減させるために、ＵＥ９０５は、ＣＮ９０６もＰＭＩＰｖ６モードを使用することを望むとする。しかしながら、ＣＮ９０６は、何らかの条件に基づいて、ＭＩＰｖ６モードを使用するかもしれない。このように、ＵＥ９０５が、ＣＮ９０６がどちらのインタフェースを使用すべきか（どちらがＵＥ９０５にとって望ましいか）を示すプレファレンスを通知し、ＣＮ９０６は、その申し出（ＵＥ９０５のプレファレンス）を受け入れるかどうかを判断することが可能である。
＜第１４の実施の形態：複数インタフェースのＵＥと複数インタフェースのＣＮがインタフェースを選択する際にネットワークによって提供された情報に従う例＞
本発明の第１４の実施の形態では、複数インタフェースのＵＥ及び複数インタフェースのＣＮによる調整方法、相互に通信を行うための理想的なインタフェースの決定方法について説明する。
ＵＥ及びＣＮの両方が、ネットワークによって提供される情報にのみ基づいて、ＵＥ−ＣＮ通信のインタフェースを決定する場合が考えられる。以下、図１０Ａに示すメッセージシーケンスチャートを参照しながら、この動作について説明する。
ＵＥ１０００Ａ及びＣＮ１００８Ａが同一管理ドメインに配置されており、相互にデータ通信を行おうとしていると仮定する。また、このピアノードは両方共、相互の通信に関連してＲＯ及び効率的なモビリティ管理を実現するために、互いのルーティングトポロジ上の位置の特定、及び、理想的なインタフェースの使用を望んでいると仮定する。
ＵＥ１０００Ａは、例えば、ＬＴＥインタフェース１００１Ａ及びＷｉＭＡＸインタフェース１００２Ａの２つのインタフェースを有しているとする。ＵＥ１０００ＡのＬＴＥインタフェース１００１ＡはＳ−ＧＷ１００３Ａに接続されており、ＷｉＭＡＸインタフェース１００２ＡはＡＧＷ１００４Ａに接続されているとする。また、Ｐ−ＧＷ１００５Ａは、ＵＥ１０００Ａに関するバインディング登録を有しているとする。
また、ＣＮ１００８Ａは、例えば、ＬＴＥインタフェース１００９Ａ及びＷｉＭＡＸインタフェース１０１０Ａの２つのインタフェースを有しているとする。ＣＮ１００８ＡのＬＴＥインタフェース１００９Ａは、Ｓ−ＧＷ１００６Ａに接続されており、ＷｉＭＡＸインタフェース１０１０ＡはＡＧＷ１００７Ａに接続されているとする。また、Ｐ−ＧＷ１００５ＡはＣＮ１００８Ａに関するバインディング登録を有しているとする。
また、ＵＥ１０００Ａ及びＣＮ１００８Ａの両方のＬＴＥインタフェース（ＬＴＥインタフェース１００１Ａ、１００９Ａ）のモビリティは、ＰＭＩＰｖ６メカニズムによって管理されており、ＵＥ１０００Ａ及びＣＮ１００８Ａの両方のＷｉＭＡＸインタフェース（ＷｉＭＡＸインタフェース１００２Ａ、１０１０Ａ）のモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。
ここで、ＵＥ１０００Ａ及びＣＮ１００８Ａが、ＲＯに関する理想的なインタフェースをどのエンティティが特定するかに関して、相互に調整を行う方法について説明する。このような交渉は、多数のノードがそれぞれ独立して探索を行ってしまわないようにすることできるという点で有用である。また、特にグループ通信（ＣＮのグループが通信を行うような場合）において、通信ノード間で交渉を行うことは有用である。
このような交渉は、図１０Ａのメッセージ１０１１Ａに示されている。例えば、ＵＥ１０００Ａは、ＵＥ１０００Ａが通信に関する理想的なインタフェースを特定することを、メッセージ１０１１ＡによってＣＮ１００８Ａに通知する。ＣＮ１００８Ａは、このメッセージ１０１１Ａを受信した場合には、ＵＥ１０００Ａに関する情報をＰ−ＧＷ１００５Ａに要求しない。このような交渉メッセージ１０１１Ａによって、多数のシグナリングが節約されるようになる。
さらに、ＵＥ１０００Ａが、ＣＮ１００８Ａに関する情報を提供するようＰ−ＧＷ１００５Ａに要求したとする。Ｐ−ＧＷ１００５Ａは、ＣＮ１００８Ａが同一ドメインに存在していることをマークによってＵＥ１０００Ａへ通知する。さらに、ＣＮ１００８ＡのどのインタフェースでＰ−ＧＷ１００５Ａにパケットが届いたかに関しても通知する。なお、Ｐ−ＧＷ１００５Ａは、ＣＮ１００８のパケットがＣＮのＰＭＩＰｖ６インタフェースか届いたかどうかを容易に特定することが可能である（例えば、ＰＭＩＰｖ６パケットがＭＡＧ経由でトンネルされてくる）。
ＣＮ１００８Ａに関する情報は、メッセージ１０１２ＡによってＵＥ１０００Ａに提供される。ＵＥ１０００Ａは、このメッセージ１０１２Ａを受信すると、どのインタフェースを選択すべきかに関する決定処理を開始する。ここで、ＵＥ１０００Ａがネットワークから通知されたインタフェースに従うと決定し、ＷｉＭＡＸインタフェース１００２Ｂを用いてＣＮ１００８Ａと通信を行うことを決定したと仮定する。しかしながら、ＵＥ１０００ＡはＣＮ１００８ＡのＷｉＭＡＸアクセスに関しては何も把握していない。ＵＥ１０００ＡとＣＮ１００８Ａとの間で完全なＲＯを実現するためには、両方のエンティティが、ＣＭＩＰｖ６モードで用いられるＷｉＭＡＸインタフェースを使用する必要がある。したがって、ＵＥ１０００Ａは、メッセージ１０１３によって、ＣＭＩＰｖ６を有しているのであれば使用するようＣＮ１００８Ａに要求する。なお、メッセージ１０１３によって、ＵＥ１０００Ａ及びＣＮ１００８Ａは両方共、同一ドメインに存在していることを通知することも可能である。
メッセージ１０１３に対して否定の応答がない場合には、ＣＮ１００８ＡはＷｉＭＡＸインタフェース１０１０Ａの使用を決定したと考えられる。一方、ＣＮ１００８ＡがＷｉＭＡＸインタフェースは使用しないことを決定した場合（あるいは、ＣＮ１００８ＡがＣＭＩＰｖ６インタフェースを有していない場合）には、何らかの否定の応答がＣＮ１００８ＡからＵＥ１０００Ａへ送信されることが望ましい。ＵＥ１００Ａ及びＣＮ１００８Ａが両方共ＷｉＭＡＸインタフェースを使用した場合には、メッセージ１０１４に示される経路最適化のパスを通じて双方向データ通信が行われるようになる。
＜第１５の実施の形態：複数インタフェースのＵＥがネットワークによって提供される情報に従おうとするが、ＣＮは従わず、その結果、ＵＥがインタフェースの選択を再考する例＞
本発明の第１５の実施の形態では、複数インタフェースのＣＮと通信を行うために複数インタフェースのＵＥが実行するインタフェース選択が、結果的にＣＮによるインタフェース選択に基づいて行われる場合について説明する。以下、図１０Ｂに示すメッセージシーケンスチャートを参照しながら、この動作について説明する。
ここでは、ＵＥ１０００Ｂ及びＣＮ１００８Ｂの両方が同一の管理ドメインに存在しているとする。また、ＵＥ１０００Ｂ及びＣＮ１００８Ｂの両方が、それぞれ両方のインタフェースを介してネットワークに接続されているとする。ＵＥ１０００ＢのＬＴＥインタフェース１００１Ｂは、Ｓ−ＧＷ１００３Ｂに接続されており、ＬＴＥインタフェース１００１ＢのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。また、ＵＥ１０００ＢのＷｉＭＡＸインタフェース１００２Ｂは、ＡＧＷ１００４Ｂに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。
同様に、ＣＮ１００８ＢのＬＴＥインタフェース１００９ＢはＳ−ＧＷ１００６Ｂに接続されており、そのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。さらに、ＣＮ１００８ＢのＷｉＭＡＸインタフェース１０１０Ｂは、ＡＧＷ１００７Ｂに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。また、上述の第１４の実施の形態と同様、Ｐ−ＧＷ１００５ＢはＵＥ１０００Ｂ及びＣＮ１００８Ｂの両方のモビリティアンカポイントであるとする。
例えば、ＵＥ１０００Ｂは、ＵＥ１０００Ｂが通信に関する理想的なインタフェースを特定することを、メッセージ１０１５ＢによってＣＮ１００８Ａに通知する。すなわち、ＵＥ１０００Ｂが最適化された通信を行うために適切なインタフェースに関する情報をＣＮ１００８Ｂへ通知することをＣＮ１００８Ｂに対して通知する。
一方、上述の第１４の実施の形態で説明したように、Ｐ−ＧＷ１００５Ｂはメッセージ１０１６Ｂによって、ＣＮの位置（同一ドメインか否か）及びＣＮによって使用されているインタフェース（ＰＭＩＰｖ６インタフェース又はＣＭＩＰｖ６インタフェース）をＵＥ１０００Ｂに対して通知すると仮定する。さらに、ＵＥ１０００Ｂがネットワークによって提供された情報に従うことを決定し、ＣＮ１００８Ｂが同一ドメインに存在することからＷｉＭＡＸインタフェースを使用することを決定したと仮定する。
ＵＥ１０００Ｂは、このインタフェース選択を行った後、メッセージ１０１７ＢをＣＮ１００８Ｂへ送信して、ＣＭＩＰｖ６インタフェース（すなわち、ＷｉＭＡＸインタフェース１００２Ｂ）を使用することをＣＮ１００８Ｂに通知する。なお、Ｐ−ＧＷ１００５Ｂは、ＣＮ１００８Ｂも複数インタフェースを有していることをＵＥ１０００Ｂに通知したとする。
しかしながら、この実施の形態では、ＣＮ１００８Ｂが、例えばＣＭＩＰｖ６インタフェースを使用しないことを決定すると仮定する。このような場合、ＣＮ１００８ＢはＵＥに対してシグナリングメッセージ１０１８Ｂを返送し、ＰＭＩＰｖ６メカニズムによって管理されているＯＭＩＰｖ６インタフェース（ＬＴＥインタフェース１００９Ｂ）の使用を通知する。
ＵＥ１０００Ｂは、このメッセージ１０１８Ｂを受信すると、ＷｉＭＡＸインタフェース１００２Ｂを使用するかどうかを決定し、ＣＭＩＰｖ６シグナリングを行うか、あるいは、決定を再度考慮する。
ＣＮ１００８Ｂが異なる決定を下したので、ＵＥ１０００Ｂは、ＣＮ１００８Ｂからの通知に従ってＣＮ１００８Ｂとの通信にＬＴＥインタフェース１００１Ｂを使用し、電力の節約を行うことを決定する。この場合、ＵＥ−ＣＮ通信のデータパスはメッセージ１０１９Ｂによって示されるように、ＬＴＥインタフェース１００１ＢとＬＴＥインタフェース１００９Ｂとを用いた双方向データ通信となる。
ここでは、両方のピアノードが同一ドメイン内に存在していたとしても、両方共ＬＴＥインタフェースを使用することを決定したことが重要である。なお、この第１５の実施の形態に示すシグナリングメッセージはデータメッセージに関連する帯域内シグナリングであってもよく、データメッセージと関連しない帯域外シグナリングであってもよい。また、こうしたメッセージは、任意の方法によって送信可能である。
＜第１６の実施の形態：複数インタフェースのＵＥが適切なインタフェースに関してネットワークから提供された情報に従わず、ＵＥ選択及びネットワーク情報の両方をＣＮへ提供する例＞
本発明の第１６の実施の形態では、複数インタフェースのＵＥが複数インタフェースのＣＮと通信を行うためのインタフェース選択処理を各ＵＥの選択基準に基づいて行うが、ＵＥは、ネットワークによって特定された実際の状態情報、及び、ＵＥによって決定されたインタフェースをＣＮに通知する。この通知情報に基づいて、ＣＮは適切なインタフェースに関する決定を行うことができる。以下、図１１Ａに示すメッセージシーケンスチャートを参照しながら、この動作について説明する。
ここで、ＵＥ１１００Ａ及びＣＮ１１０８Ａの両方が同一の管理ドメインに存在しているとする。また、ＵＥ１１００Ａ及びＣＮ１１０８Ａの両方が、それぞれ両方のインタフェースを介してネットワークに接続されているとする。ＵＥ１１００ＡのＬＴＥインタフェース１１０１ＡはＳ−ＧＷ１１０３Ａに接続されており、ＬＴＥインタフェースのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。また、ＷｉＭＡＸインタフェース１１０２ＡはＡＧＷ１１０４Ａに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されている。
また同様に、ＣＮ１１０８ＡのＬＴＥインタフェース１１０９ＡはＳ−ＧＷ１１０６Ａに接続されており、そのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。さらに、ＣＮ１１０８ＡのＷｉＭＡＸインタフェース１１１０ＡはＡＧＷ１１０７Ａに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。また、上述の第１４及び第１５の実施の形態のように、Ｐ−ＧＷ１１０５ＡはＵＥ１１００Ａ及びＣＮ１１０８Ａの両方のモビリティアンカポイントであると仮定する。
ＵＥ１１００Ａはメッセージ１１１１ＡをＣＮ１１０８Ａへ送信し、どちらのエンティティが適切なインタフェースを特定するかに関して交渉を行う。このメッセージ１１１１Ａは、上述の第１４及び第１５の実施の形態で詳細に説明したものと同一である。
Ｐ−ＧＷ１１０５Ａはメッセージ１１１２Ａによって、ＣＮ１１０８ＡがＵＥ１１００Ａと同一のドメインに存在していることをＵＥ１１００Ａへ通知する。しかしながら、ＵＥ１１００Ａは、ＣＮ１１０８Ａが同一ドメインに存在しているにもかかわらず、ＬＴＥインタフェース１１０１Ａを使用することを決定したとする。このとき、ＵＥ１１００Ａは、メッセージ１１１３Ａによって、ネットワークによって提供された情報やＵＥ１１００Ａによって選択されたインタフェースの情報などをＣＮ１１０８Ａへ提供する。
ＵＥ１１００Ａが上記の情報をＣＮ１１０８Ａに提供することによって、ＣＮ１１０８Ａは実際のネットワーク状態（すなわち、ＵＥ１１００Ａの配置場所における状態）、及び、ＵＥ１１００Ａが従う状態（すなわち、ＵＥによって選択されたインタフェース）を把握することが可能となる。
ＣＮ１１０８Ａは、ネットワーク状態（ネットワークから提供された情報）に従うことを望んでいる場合もあり、また、ＵＥ１１００Ａ決定パターンに従うことを望んでいる場合もある。また、適切なインタフェースに関するＵＥ１１００Ａの決定結果が変動し続けるような場合には、ＣＮ１１０８Ａは、インタフェースを選択する際に実際のネットワーク状態に従うことによって、インタフェース選択に関連する処理負荷を低減させることを望むかもしれない。しかしながら、ＣＮ１１０８Ａが、フローの性能に関してＵＥ１１００Ａの状態を把握することが不可欠であると判断した場合には、ＣＮ１１０８Ａは、適切なインタフェースを決定するためにＵＥ１１００Ａの状態情報を必要とする。したがって、ＣＮ１１０８Ａはネットワーク状態及びＵＥ１１００Ａが選択した結果の両方の状態を把握する必要があり、これらの情報に基づいてインタフェースの選択を行うことが可能となる。
さらに、ＣＮ１１０８Ａは、適切なインタフェースに関する決定を行うと、メッセージ１１１４Ａによってその決定をＵＥ１１００Ａへ通知する。なお、ＣＮ１１０８Ａによって決定されたインタフェースを把握することによって、ＵＥ１１００Ａが、インタフェースの選択をさらに再調整できることが重要である。例えば、ＣＮ１１０８ＡがＰＭＩＰｖ６インタフェースを使用することを決定して、メッセージ１１１４ＡによりＵＥ１１００Ａへ通知し、ＵＥ１１００Ａはその決定を適切であると判断して、その決定に従うという動作が可能となる。
＜第１７の実施の形態：複数インタフェースのＵＥは、適切なインタフェースに関してネットワークから提供された情報に従わないが、ＵＥによる選択及びネットワーク情報の両方をＣＮへ提供し、さらにそのプレファレンスをＣＮへ通知する例＞
本発明の第１７の実施の形態においても、複数インタフェースのＵＥが複数インタフェースのＣＮと通信を行うためのインタフェース選択が、各ＵＥの選択基準に基づいて行われる場合について説明する。ただし、ＵＥは、ネットワークによって提供された実際の状態情報と共に、ＵＥが決定したインタフェース、さらにはＵＥのプレファレンス（ＣＮによって選択されることが望ましいインタフェース）をＣＮへ提供し、その結果、ＣＮがＵＥにとって適切なインタフェースを選択できるようにする。以下、図１１Ｂに示すメッセージシーケンスチャートを参照しながら、この動作について説明する。
ここでは、ＵＥ１１００Ｂ及びＣＮ１１０８Ｂの両方が同一の管理ドメインに存在しているとする。また、ＵＥ１１００Ｂ及びＣＮ１１０８Ｂの両方が、それぞれ両方のインタフェースを介してネットワークに接続されているとする。ＵＥ１１００ＢのＬＴＥインタフェース１１０１Ｂは、Ｓ−ＧＷ１１０３Ｂに接続されており、ＬＴＥインタフェース１１０１ＢのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。また、ＵＥ１１０１ＢのＷｉＭＡＸインタフェース１１０２Ｂは、ＡＧＷ１１０４Ｂに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。
同様に、ＣＮ１１０８ＢのＬＴＥインタフェース１１０９ＢはＳ−ＧＷ１１０６Ｂに接続されており、そのモビリティはＰＭＩＰｖ６メカニズムによって管理されているとする。さらに、ＣＮ１１０８ＢのＷｉＭＡＸインタフェース１１１０Ｂは、ＡＧＷ１１０７Ｂに接続されており、そのモビリティはＣＭＩＰｖ６メカニズムによって管理されているとする。また、上述の第１４〜第１６の実施の形態のように、Ｐ−ＧＷ１１０５ＢはＵＥ１１００Ｂ及びＣＮ１１０８Ｂの両方のモビリティアンカポイントであると仮定する。
ＵＥ１１００Ｂはメッセージ１１１６ＢをＣＮ１１０８Ｂに送信し、どちらのエンティティが適切なインタフェースを特定するかに関して交渉を行う。このメッセージ１１１６Ｂは、上述の第１４〜第１６の実施の形態で詳細に説明したものと同一である。
Ｐ−ＧＷ１１０５Ｂはメッセージ１１１７Ｂによって、ＣＮ１１０８ＢがＵＥ１１００Ｂと同一のドメインに存在していることをＵＥ１１００Ｂへ通知する。しかしながら、ＵＥ１１００Ｂは、ＣＮ１１０８Ｂが同一ドメインに存在しているにもかかわらず、ＬＴＥインタフェース１１０１Ｂを使用することを決定したとする。このとき、ＵＥ１１００Ｂは、メッセージ１１１８Ｂによって、ネットワークによって提供された情報やＵＥによって選択されたインタフェースの情報などに加えて、さらにＣＮ１１０８Ｂが使用すべき好適なインタフェースを示すＵＥ１１００ＢのプレファレンスをＣＮ１１０８Ａへ提供する。
メッセージ１１１８Ｂは重要なトリガを伝送し、特定のインタフェースを使用するようＣＮ１１０８Ｂへ要求するものである。特に、ＵＥ１１００Ｂのプレファレンスによって、ＵＥ１１００ＢがＣＮ１１０８Ｂに使用してもらいたい特定のインタフェースが通知される。ＣＮ１１０８Ｂは、メッセージ１１１９Ｂによる特定のインタフェースの使用要求に従うか、あるいは従わないかを示す応答を通知する。ＣＮ１１０８Ｂが、例えば、その要求に従う旨を通知した場合には、ＵＥ１１００Ｂ及びＣＮ１１０８Ｂの両方が同一タイプのインタフェース（例えばＬＴＥインタフェース）を使用することが可能となる。なお、本発明の第１７の実施の形態では、ＣＮ１１０８Ｂが、適切なインタフェースの決定処理の際に３つのパラメータ（ネットワーク状態、ＵＥ１１００Ｂの選択結果、ＵＥ１１００Ｂのプレファレンス）を使用することが重要である。
＜第１８の実施の形態＞
本発明の第１８の実施の形態では、複数インタフェースのＣＮと通信をする際のＵＥの動作について、図１２を参照しながら説明する。図１２には、本発明に係るＵＥの動作の概要を示すフローチャートが図示されている。
ＵＥは、まずステップＳ１２００において、理想的なインタフェースを通知するノードに関する交渉を行う。なお、ここでは、ＵＥが理想的なインタフェースを通知するノードとなった場合について説明する。ステップＳ１２００の後、ＵＥは、ステップＳ１２０１において、ネットワークによって提供された情報（Ｐ−ＧＷからの情報）のみを使用して適切なインタフェースを決定することが可能かどうかをチェックする。
ステップＳ１２０１でネットワークによって提供された情報に従ってもよいと判断された場合には、ステップＳ１２０２において、ＵＥはネットワークによって提供された情報、ＣＮによって選択されるべき好適なインタフェースをＣＮへ通知する。このステップＳ１２０２の後、ステップＳ１２０３において、ＵＥによって提案されたインタフェース（ネットワークによって提供された情報に従ったインタフェース）にＣＮが従ったかどうかのチェックが行われる。
ステップＳ１２０３でＣＮが従ったと判断される場合には更なる処理は行われず、ステップＳ１２０４において、これまでの決定に従って通信が行われる。一方、ステップＳ１２０３でＣＮが従わなかったと判断される場合には、ステップＳ１２０５において、ＵＥはインタフェース選択に関する決定を再評価する。このときＵＥは、基本的に、ＣＮによって選択されたインタフェースに基づいて、インタフェースに関する決定を再評価する。
一方、ステップＳ１２０１でネットワークによって提供された情報に従わないと判断された場合には、ステップＳ１２０６において、ＵＥは、ネットワークによって提供された情報に加えて、例えば負荷バランスや電力問題などの他の基準に基づいてインタフェースの選択を行う。
そして、ステップＳ１２０６の処理後、ステップＳ１２０７において、ある特定のインタフェースを使用するようＣＮへ要求する必要があるかどうかがチェックされる。ステップ１２０７で、特定のインタフェースを使用するようＣＮへ要求する必要があると判断された場合には、ステップ１２０９において、ＵＥは、ＣＮに対して特定のインタフェースを使用するよう要求する。また、ステップ１２０７で、特定のインタフェースを使用するようＣＮへ要求する必要がないと判断された場合には更なる処理は行われず、ステップＳ１２０９において、これまでの決定に従って（あるいは、ネットワークによって提供された情報を無視して）通信が行われる。
＜第１９の実施の形態：ＨｅＮＢマルチＰＤＮシナリオへのマーク付けの適用＞
以下、本発明の第１９の実施の形態では、ＵＥへ送信されるパケットへＰ−ＧＷがマーク付けを行う解決方法が、図１３に図示されているフェムトセルシナリオに適用可能であることを説明する。
例えば、ＵＥ１３５０には、ＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）がＰ−ＧＷ１３５８から割り当てられる。ＵＥ１３５０は、Ｐ−ＧＷ１３５８に対して、ＣＮ１３６４からどのようにパケットを受信するかについてＵＥ１３５０へ通知するよう依頼する。Ｐ−ＧＷ１３５８は、上述の実施の形態で説明した検出メカニズムを実行して、ＣＮ１３６４の位置を特定する。
ＣＮ１３６４の位置がＥＰＣ１３５５の外部であると特定すると、Ｐ−ＧＷ１３５８は、ＣＮ１３６４からＵＥ１３５０へのデータパケットにマークを付けることによって、ＵＥ１３５０に対してＣＮ１３６４に関する通知を行う。このマークによって、ＵＥ１３５０は、ＣＮ１３６４がＥＰＣ１３５５内に存在していないことを把握できるようになる。なお、このマークは、Ｐ−ＧＷ１３５８から直接ＵＥ１３５０へ送信されるＬ２／Ｌ３メッセージで伝送されてもよいが、これに限定されるものではない。
また、図１４を参照しながら、端末が、受信した通知に基づいて、どのＩＰアドレスを用いるかを決定する方法についてフローチャートを用いて説明する。ＵＥ１３５０が通知を受信すると（ステップＳ１４００）、ＵＥ１３５０は、Ｐ−ＧＷ１３５８から提供される通知のタイプについてチェックする（ステップＳ１４０１）。
その通知が、パケットがＥＰＣ１３５５内から受信したことをＵＥ１３５０へ通知するものである場合には、ＵＥ１３５０は、パケットの送信者と更に通信を行うために、ＥＰＣアクセスのために割り当てられたＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）を使用する決定を行う（ステップＳ１４０３）。この決定が行われると、処理は終了となる（ステップ１４０５）。
また、その通知が、パケットがＥＰＣ１３５５外部から受信したことをＵＥ１３５０へ通知するものである場合には、ＵＥ１３５０は、パケットの送信者と更に通信を行うために、ホームネットワークアクセスのために割り当てられたＩＰアドレス（ＨＮ．ＩＰ．ＵＥ１３５０）を使用する決定を行う（ステップＳ１４０４）。この決定が行われると、処理は終了となる（ステップ１４０５）。
＜第２０の実施の形態：ＣＮがＥＰＣ内に存在する場合のＵＥからＨｅＮＢへの決定＞
次に、本発明の第２０の実施の形態において、端末がコレスポンデントノードの位置を決定するために行う方法について説明する。図１３を参照すると、コレスポンデントノードがＥＰＣ１３５５内に存在することをＰ−ＧＷ１３５８がＵＥ１３５０へ通知する場合に、ＵＥ１３５０は、どちらのＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０又はＨＮ．ＩＰ．ＵＥ１３５０）をコレスポンデントノードとの通信に使用すべきであるか迷う可能性がある。
例えば、ＣＮ１３６６もＥＰＣ１３５５の加入者であり、３Ｇ．ＩＰ．ＣＮ１３６６経由でＥＰＣにアクセスするためのＩＰアドレスを持っているとする。ＣＮ１３６６がＵＥ１３５０あてのパケットを送信すると、そのパケットはＥＰＣ１３５５内へルーティングされる（すなわち、ＨｅＮＢ１３５２→Ｓ−ＧＷ１３５４→ＣＮ１３６６のＰ−ＧＷ→Ｐ−ＧＷ１３５８）。Ｐ−ＧＷ１３５８は、このパケットを受信して、送信元（ソース）がＥＰＣ１３５５内に存在することを把握する。Ｐ−ＧＷ１３５８は、このパケットにマークを挿入し、ＥＰＣ１３５５内からこのパケットを受信したことをＵＥ１３５０が把握できるようにする。ＵＥ１３５０は、これを把握することで、ＣＮ１３６６と通信を行うために３Ｇ．ＩＰ．ＵＥ１３５０を使用することを決定する。
しかしながら、実際には、ＨＮ．ＩＰ．ＵＥ１３５０がＵＥ１３５０とＣＮ１３６６との間の最短往復時間をもたらすので、ＵＥ１３５０は、ＣＮ１３６６と通信を行うためにＨＮ．ＩＰ．ＵＥ１３５０を使用すべきである。したがって、この場合には、ＵＥ１３５０はＨｅＮＢ１３５２に対して、ＥＰＣ１３５５内のＣＮ１３６６の位置に関してＵＥ１３５０に通知するよう依頼することが望ましい。
図１５において、端末が、コレスポンデントノードの位置を端末に通知するようにＨｅＮＢに依頼する決定方法に関してフローチャートを用いて説明する。ＵＥ１３５０は、ＥＰＣ１３５５内からパケットを受信したことを示すマークが挿入されたタイプの通知をＰ−ＧＷ１３５８から受信すると（ステップＳ１５００）、ＨｅＮＢ１３５２に対して、同様のパケットをＨｅＮＢ１３５２が受信する方法についてＵＥ１３５０に通知するよう要求する（ステップＳ１５０１）。
ＨｅＮＢ１３５２は同様のパケットを受信すると、ＵＥ１３５０に対して、パケットの受信方法について通知する。ＵＥ１３５０は、ＨｅＮＢ１３５２からの通知を受信すると、通知のタイプをチェックする（ステップＳ１５０２）。
この通知が、パケットが外部（ホームネットワーク１３５１外部）からホームネットワーク１３５１へ受信されたことを通知するものである場合には、ＵＥ１３５０は、パケットの送信者と更に通信を行うために、ＥＰＣアクセスのために割り当てられたＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）を使用する決定を行う（ステップＳ１５０３）。この決定が行われると、処理は終了となる（ステップＳ１５０５）。
また、この通知が、パケットが内部（ホームネットワーク１３５１内部）からホームネットワーク１３５１へ受信されたことをＵＥ１３５０へ通知するものである場合には、ＵＥ１３５０は、パケットの送信者と更に通信を行うために、ホームネットワークアクセスのために割り当てられたＩＰアドレス（ＨＮ．ＩＰ．ＵＥ１３５０）を使用する決定を行う（ステップＳ１５０４）。この決定が行われると、処理は終了となる（ステップ１５０５）。
以下、図１５に示す処理の具体的な一例について説明する。図１３において、ＵＥ１３５０とＣＮ１３６６とは通信セッションを有している。ＣＮ１３６６は、３Ｇ．ＩＰ．ＣＮ１３６６から３Ｇ．ＩＰ．ＵＥ１３５０あてにパケットを送信する。パケットは、ＨｅＮＢ１３５２及びＳ−ＧＷ１３５４を通じてＵＥ１３５０のＰ−ＧＷ（Ｐ−ＧＷ１３５８）へルーティングされる。Ｐ−ＧＷ１３５８は、受信したパケットがＥＰＣ１３５５内からのものであることを把握し、ＣＮ１３６６がＥＰＣ１３５５内に位置していることをＵＥ１３５０に対して通知する。
ＵＥ１３５０は、ＥＰＣ１３５５内のＣＮ１３６６の正確な位置を更に把握することを決定し、ＨｅＮＢ１３５２に対して、ＣＮ１３６６からのパケットをＨｅＮＢ１３５２がどのように受信するかについてＵＥ１３５０へ通知するよう依頼する。続いて、ＣＮ１３６６が別のパケットをＵＥ１３５０へ送信すると、パケットは、まずＨｅＮＢ１３５２に送られる。
ＨｅＮＢ１３５２は、送信者（ソース）であるＣＮ１３６６からＵＥ１３５０あてに送信されるパケットをホームネットワーク１３５１内で受信すると、ＵＥ１３５０に対して、ＣＮ１３６６がホームネットワーク１３５１内に位置していることを通知する。これにより、ＵＥ１３５０は、ＨＮ．ＩＰ．ＵＥ１３５０を使用してＣＮ１３６６と通信を行うことを決定し、ＣＮ１３６６との最適化通信を実現する。
なお、ＨｅＮＢ１３５２は、ソースアドレスが３Ｇ．ＩＰ．ＣＮ１３６６であるＣＮ１３６６からのパケットを２回受信（intercept：インターセプト）する。最初のインターセプトは、ＣＮ１３６６が無線ベアラを通じてＨｅＮＢ１３５２へパケットを転送するときである。このパケットは、セルラリンク１３５３を通じて、ＥＰＣ１３５５内のＣＮ１３６６のＰ−ＧＷへ転送される。次に、パケットは、ＵＥ１３５０のモビリティアンカであるＰ−ＧＷ１３５８へ転送される。ＨｅＮＢ１３５２による２回目のインターセプトは、このパケットがＥＰＣ１３５５内部（すなわち、ＥＰＣ１３５５内のＰ−ＧＷ）から受信される場合に行われる。
なお、本発明では、ＨｅＮＢ１３５２は、ＣＮ１３６６のパケットの１回目のインターセプトでパケットのチェックをトリガし、パケットがホームネットワーク１３５１内のＣＮ１３６６からのものであるかどうかを判断することが望ましい。ＨｅＮＢ１３５２が２回目のインターセプトでこのパケットを受信する際、パケットは論理セルラリンク１３５３を通じて到達するので、ＨｅＮＢ１３５２は、このパケットのチェックがトリガされない。
＜第２１の実施の形態：ＨｅＮＢの装置構成−アプリケーション制御レイヤにおけるチェック＞
次に、本発明の第２１の実施の形態において、本発明の好適な実施の形態で用いられる装置の機能アーキテクチャについて説明する。
図１６には、本発明で用いられるＨｅＮＢの好適な機能アーキテクチャの一例が図示されている。図１６に図示されているＨｅＮＢの好適な機能アーキテクチャ１６００は、ネットワークインタフェースモジュール１６０１、無線制御レイヤ１６０２、アプリケーション制御レイヤ１６０３、アプリケーションレイヤ１６０６を有している。
ネットワークインタフェースモジュール１６０１は、好適な装置が任意の通信媒体を通じて別のノードと通信を行うために必要なすべてのハードウェア及びソフトウェアを包含する機能ブロックである。関連技術分野で周知の用語を用いると、ネットワークインタフェースモジュール１６０１は、レイヤ１（物理レイヤ）とレイヤ２（データリンクレイヤ）の通信コンポーネント、ファームウェア、ドライバ、及び通信プロトコルを示している。なお、当業者にとって、機能アーキテクチャ１６００が１つ以上のネットワークインタフェースモジュール１６０１を有していてもよいことは明らかである。例えば、一例として、ＨｅＮＢはデジタル加入者回線ルータ（ＤＳＬルータ）に統合されており、セルラ無線インタフェースとデジタル加入者回線リンクインタフェースを有している。
また、ネットワークインタフェースモジュール１６０１は、シグナル／データパス１６０７を通じて、トリガ／パケットを無線制御レイヤ１６０２へ伝送することが可能である。例えば、ネットワークインタフェースモジュール１６０１は、コレスポンデントノードの位置を決定するための検索を行えるようにするため、無線制御レイヤ１６０２へパケットを転送する。
無線制御レイヤ１６０２は、ネットワークインタフェースモジュール１６０１に対して必要な制御を行う。例えば、セルラ無線インタフェースを制御するため、３ＧＰＰによって定義されたアクセスストラタム（ＡＳ：Access Stratum）を用いて、ＨｅＮＢとＵＥとの間で無線リンクが確実に確立できるようにする。同様に、無線制御レイヤ１６０２は、ネットワークインタフェースモジュール１６０１で受信したアプリケーション特有のメッセージを、アプリケーション制御レイヤ１６０３へ渡すためのプロキシとして機能する。無線制御レイヤ１６０２は、シグナル／データパス１６０８を通じて、トリガ／パケットをアプリケーション制御レイヤ１６０３へ伝送することが可能である。例えば、無線制御レイヤ１６０２は、コレスポンデントノードの位置を決定するための検索を行えるようにするため、ネットワークインタフェースモジュール１６０１から受信したパケットをアプリケーション制御レイヤ１６０３へ転送する。
また、アプリケーションレイヤ１６０６は、通信プロトコルスタックのネットワークレイヤの上位に存在するすべてのプロトコル及びプログラムを包含する機能ブロックを表している。これは、ＴＣＰ（Transmission Control Protocol）、ＳＣＴＰ（Stream Control Transport Protocol）、ＵＤＰ（User Datagram Protocol）、あるいは他のノードとの通信に必要なプログラム又はソフトウェアなど、トランスポートレイヤプロトコル又はセッションレイヤプロトコルを含んでいる。アプリケーションレイヤ１６０６は、シグナル／データパス１６０９を通じて、トリガ／パケットをアプリケーション制御レイヤ１６０３に伝送することが可能である。アプリケーションが接続設定を必要とする場合（例えば、ＶｏＩＰなど）には、アプリケーションレイヤ１６０６は、アプリケーション制御レイヤ１６０３をトリガし、ＶｏＩＰセッションに関する適切な接続を設定させる。
アプリケーション制御レイヤ１６０３は、アプリケーションに関する接続を設定するために必要なサポートを提供する。例えば、ＵＥ１３５０がＶｏＩＰセッションを開始するために、３ＧＰＰで定義されているノンアクセスストラタム（ＮＡＳ：Non-Access Stratum）を用いて、ＵＥ１３５０とＰ−ＧＷ１３５８との間で必要な通信パスが確実にセットアップされるようにする。
本発明では、位置通知機能１６０４及び位置チェック機能１６０５が導入される。位置通知機能１６０４は、コレスポンデントノードの特定の位置をＵＥに通知する通知メッセージを作成する機能を有している。通知メッセージの作成は、位置チェック機能１６０５によってトリガされる。また、位置チェック機能は、コレスポンデントノードの位置を把握するために、コレスポンデントノードからのパケットがＨｅＮＢによってどのように受信されるかを判断するものである。その位置が分かると、位置チェック機能１６０５は、位置通知機能１６０４に対して、コレスポンデントノードの特定の位置をＵＥに通知するための通知メッセージを送信するよう指示する。位置チェック機能１６０５は、例えば、特定のコレスポンデントノードの位置を把握するよう要求するリクエストをＵＥから受信することでトリガされる。
以下、この好適な機能アーキテクチャのさまざまなレイヤ間でのインタラクションを明確にするための一例について説明する。ネットワークインタフェースモジュール１６０１は、ＣＮ１３６６の位置を決定するようＵＥ１３５０からリクエストを受信する。この要求には、どのパケットをモニターしたらよいかをＨｅＮＢが把握できるようにするための情報（例えば、ＣＮ１３６６を送信者（ソース）とするパケット）と、ＵＥ１３５０によって使用されている対応ＩＰアドレス（例えば、３Ｇ．ＩＰ．ＵＥ１３５０）とが含まれる。
ネットワークインタフェースモジュール１６０１は、無線制御レイヤ１６０２を通じてアプリケーション制御レイヤ１６０３へこのリクエストを転送する。アプリケーション制御レイヤ１６０３は、位置チェック機能１６０５をトリガして、ＣＮ１３６６を送信者（ソース）とするパケットがどのように受信されるかのチェックを開始させる。位置チェック機能１６０５は、相互レイヤ通信方法に基づいて、ＣＮ１３６６の位置を決定する。例えば、ネットワークインタフェースモジュール１６０１がパケットをアプリケーション制御レイヤ１６０３に転送する際、パケットがどのインタフェースから受信されたかをアプリケーション制御レイヤ１６０３に知らせるための情報がパケットに埋め込まれる。アプリケーション制御レイヤ１６０３は、どのインタフェースからパケットが受信されたかに基づいて、ＣＮ１３６６の位置を決定することができる。
位置チェック機能１６０５は、ＣＮ１３６６の位置を決定すると、位置通知機能１６０４に対して、ＵＥ１３５０へ通知メッセージを送信するよう指示する。例えば、ＵＥ１３５０への通知メッセージのフォーマットは、図８に図示されているフォーマットと同様であってもよい。
＜第２２の実施の形態：アプリケーション制御レイヤのタイプ通知メッセージ＞
次に、本発明の第２２の実施の形態において、端末から送信される通知リクエスト（通知要求、あるいは通知依頼）のフォーマットの一例について説明する。図１７には、本発明の好適な一実施の形態で使用される通知リクエストのフォーマットの一例が図示されている。通知リクエストのフォーマットは、メッセージタイプ１７０１及びトラフィックフローテンプレート１７０２を有している。
メッセージタイプ１７０１はメッセージの目的（このメッセージの用途）を表している。例えば、メッセージタイプは、３ＧＰＰ ＴＳ２４．３０１で用いられるベアラリソース修正リクエスト（Bearer Resource Modification Request）であってもよいが、これに限定されるものではない。また、ＵＥは、トラフィックフローテンプレート１７０２によって、ＨｅＮＢが監視すべきパケットのタイプに関する情報をＨｅＮＢへ伝えることができる。例えば、トラフィックフローテンプレート１７０２は、ＵＥのＩＰアドレスフィールド１７０３及びＣＮのＩＰアドレスフィールド１７０４を更に有している。ＵＥは、ＵＥのＩＰアドレスフィールド１７０３によって、ＵＥが持っている現在のＩＰアドレスをＨｅＮＢへ通知することが可能である。また同様に、ＵＥは、ＣＮのＩＰアドレスフィールド１７０４によって、どの送信者（ソース）からのパケットが監視されるべきかをＨｅＮＢへ通知することが可能である。
以下、本発明の実施の形態に記載されている通知メッセージの使用を明確にするための一例である。ＵＥ１３５０は、２つのＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０、及び、ＨＮ．ＩＰ．ＵＥ１３５０）を有しており、ＣＮ１３６６は、ＩＰアドレス（３Ｇ．ＩＰ．ＣＮ１３６６）を使用している。ＵＥ１３５０は、ＣＮ１３６６の位置を決定しようとし、ＣＮ１３６６の位置をＵＥ１３５０へ通知するようＨｅＮＢ１３５２に依頼しようとする。このとき、ＵＥ１３５０は、通知リクエスト１７００をＨｅＮＢ１３５２へ送信し、ＵＥのＩＰアドレスフィールド１７０３において、ＵＥ１３５０がＥＰＣ１３５５のＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）を有していると指定する。なお、ＵＥ１３５０がＨＮ．ＩＰ．ＵＥ１３５０を指定する必要はない理由は、このＩＰアドレス（ＨＮ．ＩＰ．ＵＥ１３５０）がＨｅＮＢ１３５２によって割り当てられており、ＨｅＮＢ１３５２は既に把握しているはずだからである。同様に、ＣＮのＩＰアドレスフィールド１７０４において、ＵＥ１３５０はＣＮ１３６６（３Ｇ．ＩＰ．ＣＮ１３６６）のＩＰアドレスを指定する。
＜第２３の実施の形態：ＨｅＮＢの装置構成−無線制御レイヤにおけるチェック＞
次に、本発明の第２３の実施の形態では、別の好適な機能アーキテクチャの一例について説明する。図１６において、位置通知機能１６０４及び位置チェック機能１６０５が、アプリケーション制御レイヤ１６０３ではなく、無線制御レイヤ１６０２に実装されてもよい。この構成の利点は、コレスポンデントノードの位置を決定するために、無線制御レイヤ１６０２が任意のパケットをアプリケーションレイヤ１６０３へ転送する必要がない点である。この構成では、無線制御レイヤ１６０２がＩＰメッセージを理解するように実装される。ＵＥは、図１７に図示されている通知要求を使用して、どのパケットを監視すべきかをＨｅＮＢへ通知する。この場合も同様に、どのインタフェースからパケットを受信したかをネットワークインタフェースモジュール１６０１が位置チェック機能１６０５へ通知することによって、位置チェック機能１６０５は、コレスポンデントノードの位置を決定することができる。
＜第２４の実施の形態：ＨｅＮＢの装置構成−アプリケーションレイヤにおけるチェック＞
次に、本発明の第２４の実施の形態では、更に別の好適な機能アーキテクチャの一例について説明する。図１６において、位置通知機能１６０４及び位置チェック機能１６０５が、アプリケーション制御レイヤ１６０３ではなく、アプリケーションレイヤ１６０６に実装されてもよい。この構成の利点は、本発明をサポートするために制御レイヤ（無線制御レイヤ１６０２及びアプリケーション制御レイヤ１６０３）を変更する必要がない点である。これは、様々な制御レイヤに影響を与えることなく、アプリケーションを端末にインストールすることによって、レガシ端末が本発明を使用できるようになることを意味する。また、この場合も同様に、どのインタフェースからパケットを受信したかをネットワークインタフェースモジュール１６０１が位置チェック機能１６０５へ通知することによって、位置チェック機能１６０５は、コレスポンデントノードの位置を決定することができる。
＜第２５の実施の形態：ＨｅＮＢが、無線制御プレーンを用いてＵＥへ通知する＞
次に、本発明の第２５の実施の形態として、コレスポンデントノードの位置をＵＥへ通知するために、ＨｅＮＢが無線制御プレーンメッセージを使用する方法について説明する。ＨｅＮＢは、無線制御プレーンメッセージを用いて、コレスポンデントノードからのパケットがＨｅＮＢによってどのように受信されたかについて、ＵＥへ通知することが可能である。このメッセージを実現する典型的な例は、３ＧＰＰ ＴＳ３６．３３１に記載されているDLInformationTransferの拡張であるが、これに限定されるものではない。例えば、新たな情報要素がＤＬ情報転送に付加されて、コレスポンデントノードからのパケットをＨｅＮＢがどのように受信したかをＵＥに通知する。
＜第２６の実施の形態：ＨｅＮＢが、アプリケーションレイヤを用いてＵＥへ通知する＞
次に、本発明の第２６の実施の形態として、コレスポンデントノードの位置をＵＥへ通知するために、ＨｅＮＢがコレスポンデントノードからのデータパケットを使用する方法について説明する。ＨｅＮＢは、コレスポンデントノードからのデータパケットに対して、パケットの受信方法を付加することが可能である。そして、ＨｅＮＢは、コレスポンデントノードからのパケットがＨｅＮＢによってどのように受信されたかをＵＥへ通知するために、このマーク付けされたデータパケットをＵＥへ転送する。この方法の利点は、本発明をサポートするように無線制御レイヤの変更を行う必要がない点である。
＜第２７の実施の形態：ＨｅＮＢが、アプリケーション制御プレーンを用いてＵＥへ通知する＞
次に、本発明の第２７の実施の形態として、コレスポンデントノードの位置をＵＥへ通知するために、ＨｅＮＢがアプリケーション制御プレーンメッセージを使用する方法について説明する。ＨｅＮＢは、アプリケーション制御プレーンメッセージを使用して、コレスポンデントノードからのパケットの受信方法をＵＥへ通知することが可能である。このメッセージを実現する典型的な例は、３ＧＰＰ ＴＳ２４．３０１に記載されているＥＰＳベアラコンテキスト変更メッセージの拡張であるが、これに限定されるものではない。例えば、プロトコル構成オプション要素に新たな情報要素が含まれるようにし、コレスポンデントノードからのパケットがどのようにＨｅＮＢで受信されたかをＵＥに通知する。アプリケーション制御プレーンを使用して通知を行う方法の利点は、アプリケーションレイヤがある状況下ではその通知を伝送することができないかもしれない点にある。例えば、ＣＮ１３６６は、データパケットをＣＮ１３６６のＰ−ＧＷに向けてカプセル化する場合がある。ＣＮ１３６６とＰ−ＧＷとの間でカプセル化が行われているので、ＨｅＮＢはカプセル化されたパケットにマーク（タグ）を付加することができない。ＨｅＮＢがカプセル化パケットの外部にタグを付加すると、データパケットがＰ−ＧＷに到達した際に、Ｐ−ＧＷは、カプセルを取り除いてしまい、その結果、タグも取り除かれてしまう。このような場合に、アプリケーション制御プレーンを使用して通知を行うことが有効である。
＜第２８の実施の形態：複数のモビリティプロトコルを有する単一のインタフェース（非３Ｇ）の場合＞
次に、本発明の第２８の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、非３ＧＰＰアクセスにおいて複数のモビリティプロトコルを動作している単一インタフェースのＵＥに対しても適用可能であることについて説明する。
図１８は、本発明を使用しながら複数のモビリティプロトコルを動作している単一インタフェースの端末を含むネットワーク図である。図１８では、ＵＥ１８００は、単一の無線アクセスのみを使用して、ＥＰＣ１８０１へアクセスする。ＵＥ１８００は、ＥＰＣ１８０１へアクセスするために、ｅＰＤＧ１８０３とのセキュアな接続１８０２を確立する。セキュアな接続１８０２において、ＵＥ１８００は、２つのタイプのモビリティ管理プロトコルを動作させている。
第１のモビリティプロトコルはＰＭＩＰであり、ｅＰＤＧ１８０３はＰ−ＧＷ１８０４に対してＰＢＵ（Proxy Binding Update）を送信する。ＰＭＩＰでは、ｅＰＤＧ１８０３が、ＵＥ１８００の移動に関してＵＥ１８００のＰ−ＧＷ１８０４へ更新（通知）する。
第２のモビリティプロトコルはＣＭＩＰであり、ＵＥ１８００がＰ−ＧＷ１８０４へＢＵ（Binding Update）を送信する。ＣＭＩＰでは、ＵＥ１８００が、ＥＰＣ１８０１内でまだアクティブであることをＰ−ＧＷ１８０４へ更新（通知）する。
また、ここでは、ＣＮ１８０５も、セキュアな接続１８０６を通じて、ｅＰＤＧ１８０３に接続されている。ＵＥ１８００は本発明を利用し、ＣＮ１８０５がＥＰＣ１８０１内に位置することをＵＥ１８００に通知する通知メッセージをＰ−ＧＷ１８０４から受信する。また、ＵＥ１８００は、ＣＮ１８０５のパケットを監視するようｅＰＤＧ１８０３に要求することも可能であり、ＣＮ１８０５が同一のｅＰＤＧ（すなわち、ｅＰＤＧ１８０３）に接続されているかどうかをＵＥ１８００に通知するよう要求することも可能である。
以下、上記のステップの一例について具体的に説明する。ＵＥ１８００は、ＷＬＡＮインタフェースを使用して、ｅＰＤＧ１８０３との間で接続１８０２を確立する。ＵＥ１８００は、ｅＰＤＧ１８０３との間の接続１８０２において、ＰＭＩＰ及びＣＭＩＰの両方を起動し、２つのＩＰアドレス（ＰＭＩＰ．ＩＰ．ＵＥ１３５０及びＣＭＩＰ．ＩＰ．ＵＥ１３５０）を取得する。
ＣＮ１８０５は、パケットをＵＥ１８００へ送信し、Ｐ−ＧＷ１８０４によって受信される。Ｐ−ＧＷ１８０４は、ＣＮ１８０５がＥＰＣ１８０１内に位置していることをＵＥ１８００へ通知する。さらに、ＵＥ１８００は、ＣＮ１８０５のパケットがｅＰＤＧ１８０３によって受信される方法についてチェックするようｅＰＤＧ１８０３へ依頼する。ｅＰＤＧ１８０３は、接続１８０６を通じてＣＮ１８０５からパケットを受信すると、ＣＮ１８０５がｅＰＤＧ１８０３に接続されていることをＵＥ１８００へ通知する。
ｅＰＤＧ１８０３がＵＥ１８００へ通知可能な方法の一例は、プロトコル構成オプション（Protocol Configuration Option）を使用するか、あるいは、ＩＫＥ（Internet Key Exchange）通知メッセージを送信することであるが、これらに限定されるものではない。ＵＥ１８００は、ＣＮ１８０５がｅＰＤＧ１８０３に接続されていることを把握すると、ＩＰ．ＣＭＩＰ．ＵＥ１８００を使用して、ＣＮ１８０５との間で経路最適化通信に係るパスを確立する。
なお、ｅＰＤＧ１８０３は、ＣＮ１８０５からのパケットを２回インターセプトすることが可能である。最初のインターセプトは、ＣＮ１８０５が無線リンク接続１８０６を通じてｅＰＤＧ１８０３へパケットを転送するときである。このパケットは、ＥＰＣ１３５５内で転送され、ＵＥ１８００のモビリティアンカであるＰ−ＧＷ１８０３に到達する。ｅＰＤＧ１８０３による２回目のインターセプトは、ＥＰＣ１８０１内（すなわち、ＥＰＣ１８０１内のＰ−ＧＷ）からパケットを受信するときである。なお、本発明に関して、パケットがｅＰＤＧ１８０３に接続されているＣＮ１８０５からのものであるかどうかを判断するように、ｅＰＤＧ１８０３においてパケットのチェックがトリガされることが望ましい。このパケットを２回目のインターセプトにおいて受信した際には、パケットがＥＰＣ１８０１から到達しているので、ｅＰＤＧ１８０３では、このパケットのチェックがトリガされない。
＜第２９の実施の形態：単一のＰＤＮ ＨｅＮＢシナリオ＞
次に、本発明の第２９の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＨｅＮＢがＰ−ＧＷ機能を実装しないときにおいても適用可能であることについて説明する。
ここでは、ＥＰＣ内のＰ−ＧＷが、異なるタイプのアクセスに関して、ＵＥに複数のＩＰアドレスを割り当てると仮定する。例えば図１３において、Ｐ−ＧＷ１３５８は、ＵＥ１３５０がＥＰＣ１３５５へアクセスするための３Ｇ．ＩＰ．ＵＥ１３５０を割り当てる。さらに、同様に、Ｐ−ＧＷ１３５８は、ＵＥ１３５０がホームネットワーク１３５１へアクセスするためのＨＮ．ＩＰ．ＵＥ１３５０を割り当てる。
ＨｅＮＢ１３５２が、受信したパケットのソースアドレスに基づいて、フィルタベースのルーティングを実行する。例えば、ＨｅＮＢ１３５２は、３Ｇ．ＩＰ．ＵＥ１３５０のソースＩＰアドレスを有するパケットを受信すると、このパケットを接続１３５３を通じてＥＰＣ１３５５へ転送する。同様に、ＨｅＮＢ１３５２は、ＨＮ．ＩＰ．ＵＥ１３５０のソースＩＰアドレスを有するパケットを受信すると、あて先アドレスがホームネットワーク１３５１でなければこのパケットを接続１３５６を通じて転送するか、あるいは、ホームネットワーク１３５１へ直接転送する。このような場合には、コレスポンデントノードの位置をＵＥ１３５０へ通知するようＨｅＮＢ１３５２におけるフィルタルールを設定することによって、ＵＥ１３５０は、本発明を使用することができる。
以下、上記のステップの一例について具体的に説明する。ＵＥ１３５０は、ＣＮ１３６６がＥＰＣ１３５５内に位置していることを通知する通知メッセージをＰ−ＧＷ１３５８から受信すると、フィルタルール要求を送信して、ＨｅＮＢ１３５２に対して、３Ｇ．ＩＰ．ＵＥ１３５０あてのＣＮ１３６６からのパケットを監視するよう指示する。このフィルタルールが設定されたＨｅＮＢ１３５２は、ＣＮ１３６６からパケットを受信すると、ＵＥ１３５０に対して、パケットがホームネットワーク１３５１内から受信されたことを通知する。これにより、ＵＥ１３５０は、 ＣＮ１３６６がホームネットワーク１３５１内に存在することを把握し、ＣＮ１３６６と通信を行うためにＨＮ．ＩＰ．ＵＥ１３５０を使用して、最適化されたパスを実現する。ＵＥとＨｅＮＢの両方がフィルタルールを実装する方法は、例えば、フローフィルタリング拡張を有するモバイルＩＰｖ６プロトコルをサポートすることによって実現可能である。
なお、３Ｇ．ＩＰ．ＣＮ１３６６のソースアドレスを有するＣＮ１３６６からのパケットは、ＨｅＮＢ１３５２において２回インターセプトされる。最初のインターセプトは、ＣＮ１３６６がパケットを無線ベアラを通じてＨｅＮＢ１３５２へ転送するときである。このパケットは、ＥＰＣ１３５５内のＣＮ１３６６のＰ−ＧＷへセルラリンク１３５３を通じて転送され、ＵＥ１３５０のモビリティアンカであるＰ−ＧＷ１３５８へ送信される。ＨｅＮＢ１３５２による２回目のインターセプトは、このパケットがＥＰＣ１３５５内（すなわち、ＥＰＣ１３５５内のＰ−ＧＷ）から受信されるときである。なお、本発明では、ＨｅＮＢ１３５２は、ＣＮ１３６６のパケットの最初のインターセプトの際に、そのパケットがホームネットワーク内のＣＮ１３６６からのものであるかどうかを判断するように、ＨｅＮＢ１３５２においてパケットのチェックがトリガされることが望ましい。このパケットの２回目のインターセプトでは、パケットは論理的なセルラリンク１３５３を通じて到達するので、ＨｅＮＢ１３５２において、このパケットのチェックはトリガされない。
＜第３０の実施の形態：複数ＰＤＮ ｅＮＢ ＳＩＰＴＯ（Selective IP Traffic Offloading）シナリオ＞
次に、本発明の第３０の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＵＥがｅＮＢ（マクロ基地局、マクロセルとも呼ばれる）に接続されている場合においても適用可能であることについて説明する。
例えば図１３において、ＨｅＮＢ１３５２をｅＮＢに置き換え、ホームネットワーク１３５１はｅＮＢによって管理されるマクロセルであるとする。また、ここでは、ｅＮＢがＰ−ＧＷ機能を実装しており、ローカルブレイクアウト用アドレスをＵＥ１３５０へ割り当てるとする。ＵＥ１３５０は本発明を利用して、コレスポンデントノードの位置についてＵＥ１３５０へ通知するよう、Ｐ−ＧＷ１３５８又はｅＮＢのどちらか、あるいは両方に依頼することが可能である。
以下、上記のステップの一例について具体的に説明する。ＵＥ１３５０は、Ｐ−ＧＷ１３５８から、ＥＰＣ１３５５へのアクセス用のＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）を取得する。同様に、ＵＥ１３５０は、ｅＮＢによって管理されているマクロセルにおけるアクセス用のＩＰアドレス（ｅＮＢ．ＩＰ．ＵＥ１３５０）をｅＮＢから取得する。ＵＥ１３５０は、ＣＮ１３６６がＥＰＣ１３５５内に位置していることを、Ｐ−ＧＷ１３５８から通知される。ＵＥ１３５０は、ＣＮ１３６６のアドレスから３Ｇ．ＩＰ．ＵＥ１３５０へのパケットがどのように受信されるかを監視するよう、ｅＮＢへ要求するリクエストを送信する。ｅＮＢは、マクロセル内部からパケットを受信すると、ＣＮ１３６６がマクロセル内に位置していることをＵＥ１３５０へ通知する。これにより、ＵＥ１３５０は、ｅＮＢ．ＩＰ．ＵＥ１３５０を利用してＣＮ１３６６と通信を行うことで、最適化されたパスを実現する。
なお、３Ｇ．ＩＰ．ＣＮ１３６６のソースアドレスを有するＣＮ１３６６からのパケットは、ｅＮＢによって２回インターセプトされる。最初のインターセプトは、ＣＮ１３６６がパケットを無線ベアラを通じてｅＮＢへ転送するときである。このパケットは、ＥＰＣ１３５５内で転送され、ＵＥ１３５０のモビリティアンカであるＰ−ＧＷ１３５８で受信される。ｅＮＢによる２回目のインターセプトは、このパケットをＥＰＣ１３５５内部（すなわち、ＥＰＣ１３５５内のＰ−ＧＷ）から受信するときである。なお、本発明では、ｅＮＢは、ＣＮ１３６６のパケットの最初のインターセプトの際に、そのパケットがホームネットワーク内のＣＮ１３６６からのものであるかどうかを判断するように、ｅＮＢにおいてパケットのチェックがトリガされることが望ましい。このパケットの２回目のインターセプトでは、パケットはＥＰＣ１３５５内から到達するので、ｅＮＢにおいてこのパケットを受信した際には、パケットのチェックはトリガされない。
＜第３１の実施の形態：単一のＰＤＮ ｅＮＢ ＳＩＰＴＯシナリオ＞
次に、本発明の第３１の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＵＥがマクロセルｅＮＢに接続されている場合においても適用可能であることについて説明する。
例えば図１３において、ＨｅＮＢ１３５２をｅＮＢに置き換え、ホームネットワーク１３５１はｅＮＢによって管理されるマクロセルであるとする。また、ここでは、ｅＮＢはＰ−ＧＷ機能を実装しておらず、ＥＰＣ１３５５内のＰ−ＧＷは、ローカルブレイクアウト用のＩＰアドレスをＵＥ１３５０へ割り当てるとする。ＵＥ１３５０は本発明を利用して、コレスポンデントノードの位置についてＵＥ１３５０へ通知するよう、Ｐ−ＧＷ１３５８又はｅＮＢのどちらか、あるいは両方に依頼することが可能である。ｅＮＢに要求を行う場合は、ＵＥは、上述したフィルタベースの方法を利用する。
以下、上記のステップの一例について具体的に説明する。ＵＥ１３５０は、Ｐ−ＧＷ１３５８から、ＥＰＣ１３５５へのアクセス用のＩＰアドレス（３Ｇ．ＩＰ．ＵＥ１３５０）を取得する。同様に、ＵＥ１３５０は、ｅＮＢによって管理されているマクロセルにおけるアクセス用の別のＩＰアドレス（ｅＮＢ．ＩＰ．ＵＥ１３５０）をＰ−ＧＷ１３５８から取得する。ＵＥ１３５０は、ＣＮ１３６６がＥＰＣ１３５５内に位置していることを、Ｐ−ＧＷ１３５８から通知される。ＵＥ１３５０は、フィルタルール要求を送信して、ＣＮ１３６６のアドレスから３Ｇ．ＩＰ．ＵＥ１３５０へのパケットがどのように受信されるかを監視するよう、ｅＮＢへ依頼する。ｅＮＢは、マクロセル内部からパケットを受信すると、ＣＮ１３６６がマクロセル内部に位置していることをＵＥ１３５０へ通知する。これにより、したがって、ＵＥ１３５０は、ｅＮＢ．ＩＰ．ＵＥ１３５０を利用してＣＮ１３６６と通信を行うことで、最適化されたパスを実現する。
なお、３Ｇ．ＩＰ．ＣＮ１３６６のソースアドレスを有するＣＮ１３６６からのパケットは、ｅＮＢによって２回インターセプトされる。最初のインターセプトは、ＣＮ１３６６がパケットをｅＮＢの無線ベアラを通じてｅＮＢへ転送するときである。このパケットは、ＥＰＣ１３５５内で転送され、ＵＥ１３５０のモビリティアンカであるＰ−ＧＷ１３５８で受信される。ｅＮＢによる２回目のインターセプトは、このパケットをＥＰＣ１３５５内部（すなわち、ＥＰＣ１３５５内のＰ−ＧＷ）から受信するときである。なお、本発明では、ｅＮＢは、ＣＮ１３６６のパケットの１回目のインターセプトの際に、パケットがＣＮ１３６６からのものであるかどうかを判断するように、ｅＮＢにおいてパケットのチェックがトリガされることが望ましい。このパケットの２回目のインターセプトでは、パケットはＥＰＣ１３５５内から到達するので、ｅＮＢにおいてこのパケットを受信した際には、パケットのチェックはトリガされない。
＜第３２の実施の形態：ｅＮＢシナリオのグループ−複数ＰＤＮ＞
次に、本発明の第３２の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＵＥがマクロセルｅＮＢに接続されており、ローカルブレイクアウト用に割り当てられているＩＰアドレスがｅＮＢのグループで保持可能である場合にも適用可能であることについて説明する。
例えば図１３において、ＨｅＮＢ１３５２をｅＮＢに置き換え、ホームネットワーク１３５１はｅＮＢによって管理されるマクロセルであるとする。また、ここでは、ｅＮＢがＰ−ＧＷ機能を実装し、ローカルブレイクアウト用のＩＰアドレスをＵＥ１３５０へ割り当てるとする。ＵＥ１３５０は本発明を利用して、コレスポンデントノードの位置についてＵＥ１３５０に通知するよう、Ｐ−ＧＷ１３５８又はｅＮＢのいずれかあるいは両方に依頼することができる。さらに、ＵＥ１３５０がｅＮＢのグループ内で移動する際には、ローカルブレイクアウト用にＵＥ１３５０に割り当てられたＩＰアドレスも使用可能となる。例えば、ＵＥ１３５０には、ローカルブレイクアウト用ＩＰアドレス（ｅＮＢ１．ＩＰ．ＵＥ１３５０）がｅＮＢ１から割り当てられるとする。ここで、ＵＥ１３５０がｅＮＢ２へ移動するとき、ｅＮＢ２がｅＮＢ１と関係を有している場合（例えば、同一ｅＮＢのグループである場合）には、ＵＥ１３５０は、ｅＮＢ２へ接続された場合であっても引き続き、ｅＮＢ１．ＩＰ．ＵＥ１３５０を使用し続けることができる。データの転送は、両方のｅＮＢ（上記のｅＮＢ１とｅＮＢ２）がＸ２インタフェースを通じてデータトンネルを作成することによって実現可能であり、これによって、ＵＥ１３５０に関するＩＰアドレスが保持可能となる。
＜第３３の実施の形態：ｅＮＢグループのシナリオ−単一のＰＤＮ＞
次に、本発明の第３３の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＵＥがマクロセルｅＮＢ（Ｐ−ＧＷ機能を実装していない）に接続されており、ローカルブレイクアウト用に割り当てられているＩＰアドレスがｅＮＢのグループで保持可能である場合にも適用される。
例えば図１３において、ＨｅＮＢ１３５２をｅＮＢに置き換え、ホームネットワーク１３５１はｅＮＢによって管理されるマクロセルである。また、ここでは、ｅＮＢがＰ−ＧＷ機能を実装しておらず、ローカルブレイクアウト用のＩＰアドレスをＵＥ１３５０へ割り当てるとする。ＵＥ１３５０は本発明を利用して、コレスポンデントノードの位置をＵＥ１３５０へ通知するよう、Ｐ−ＧＷ１３５８又はｅＮＢのいずれかあるいは両方に対して依頼することができる。ｅＮＢに要求を行う場合は、ＵＥは、上述したフィルタベースの方法を利用する。さらに、ＵＥ１３５０がｅＮＢのグループ内で移動する際には、ローカルブレイクアウト用にＵＥ１３５０に割り当てられたＩＰアドレスも使用可能となる。例えば、ＵＥ１３５０には、ローカルブレイクアウト用ＩＰアドレス（ｅＮＢ１．ＩＰ．ＵＥ１３５０）がｅＮＢ１から割り当てられるとする。ここで、ＵＥ１３５０がｅＮＢ２へ移動するとき、ｅＮＢ２がｅＮＢ１と関係を有している場合（例えば、同一ｅＮＢのグループである場合）には、ＵＥ１３５０は、ｅＮＢ２へ接続された場合であっても引き続き、ｅＮＢ１．ＩＰ．ＵＥ１３５０を使用し続けることができる。データの転送は、両方のｅＮＢ（上記のｅＮＢ１とｅＮＢ２）がＸ２インタフェースを通じてデータトンネルを作成することによって実現可能であり、これによって、ＵＥ１３５０に関するＩＰアドレスが保持可能となる。
＜第３４の実施の形態：ＡＮＤＳＦ（Access Network Discovery Selection Function）がＵＥの決定を支援する−ポリシ制限＞
次に、本発明の第３４の実施の形態では、ＡＮＤＳＦ（Access Network Discovery Selection Function：アクセスネットワーク探索選択機能）サーバが、コレスポンデントノードへの最適な通信パスを実現するためには、ＵＥのＩＰアドレスのどれを使用すべきかをＵＥが決定できるよう支援することが可能である。ここでは、ＡＮＤＳＦサーバがポリシをＵＥへ送信することが可能である。このポリシは、コレスポンデントノードに対してＵＥが使用すべきＩＰアドレスはどれかについて、ＵＥが決定する際に影響を与えるものである。
例えば図１３において、ＥＰＣ１３５５内には、ＵＥ１３５０がセキュアな通信を行っているＡＮＤＳＦサーバが存在している。ＵＥ１３５０は、ＥＰＣ１３５５内に位置しており、３Ｇ．ＩＰ．ＵＥ１３５０を用いてＣＮ１３６６との間で通信セッションを有している。ＵＥ１３５０は、ＵＥ１３５０の加入者ポリシに基づいてＵＥがホームネットワーク１３５１に存在する間はローカルブレイクアウトを実行できないというポリシを、ＡＮＤＳＦサーバから取得する。ＵＥ１３５０がホームネットワーク１３５１へ移動すると、たとえＰ−ＧＷ１３５８がＵＥ１３５０に対して、ＣＮ１３６６がＥＰＣ１３５５内に存在すると通知する場合であっても、ＵＥ１３５０はホームネットワーク１３５１に対して、ローカルブレイクアウトＩＰアドレスの要求は行わない。その結果、ＵＥ１３５０は、ホームネットワーク１３５１内に存在する間は、３Ｇ．ＩＰ．ＵＥ１３５０を使用し続けて、ＣＮ１３６６との通信を行う。
また、さらに、上記の方法は、ＵＥが非３ＧＰＰアクセスにおいて複数のモビリティプロトコルを動作している場合のシナリオに適用可能である。例えば図１８において、ＡＮＤＳＦサーバはＵＥ１８００に対して（ポリシによって）、ＵＥ１８００が非３ＧＰＰアクセスに存在する間（すなわち、ｅＰＤＧ１８０３に接続されている間）は、ローカルブレイクアウトを実行できないことを通知する。これにより、ＵＥ１８００はｅＰＤＧ１８０３にからのローカルブレイクアウト用ＩＰアドレスを要求せず、非３ＧＰＰアクセスに存在する間は、３Ｇ．ＩＰ．ＵＥ１８００を使用し続けて、ＣＮ１８０５との通信を行う。
また、上記の方法は、ＵＥがマクロセルｅＮＢ内に存在しており、マクロセルにおいてローカルブレイクアウト用のＩＰアドレスが割り当てられるシナリオに適用可能である。例えば、ＡＮＤＳＦサーバはＵＥに対して（ポリシによって）、マクロセル内に存在する間はローカルブレイクアウトを実行することができないと通知することが可能である。その結果、ＵＥは、ローカルブレイクアウト用のＩＰアドレスを要求せず、マクロセル内に存在する間は、ＥＰＣアクセス用に割り当てられたＩＰアドレスを使用し続けて、コレスポンデントノードと通信を行う。
＜第３５の実施の形態：ＡＮＤＳＦがＵＥの決定を支援する−ポリシ制限＞
次に、本発明の第３５の実施の形態では、ＡＮＤＳＦサーバは、コレスポンデントノードとの間の通信セッションのうちのどれが最適化されるべきかをＵＥが決定するための支援を行うことが可能である。ここでは、ＡＮＤＳＦサーバはポリシをＵＥへ送信する。このポリシは、各コレスポンデントノードに対してＵＥが使用すべきＩＰアドレスはどれかについて、ＵＥが決定する際に影響を与えるものである。
例えば図１３において、ＵＥ１３５０がセキュアな通信を有するＡＮＤＳＦサーバがＥＰＣ１３５５内に存在する。ＵＥ１３５０は、ＥＰＣ１３５５内に位置しており、３Ｇ．ＩＰ．ＵＥ１３５０を使用して、ＣＮ１３６４、１３６５との間で通信セッションを有している。ＵＥ１３５０は、ホームネットワーク１３５１に存在する間はＣＮ１３６６とのセッションに関してのみローカルブレイクアウトが許可される旨を通知するポリシを、ＡＮＤＳＦサーバから取得する。ＵＥ１３５０がホームネットワーク１３５１へ移動すると、ＣＮ１３６５はＥＰＣ１３５５内に存在していることをＰ−ＧＷ１３５８がＵＥ１３５８へ通知した場合であっても、ＵＥ１３５０は、ＨｅＮＢ１３５２に対して、ＣＮ１３６５からのパケットを監視するよう要求しない。その結果、ＵＥ１３５０は、ホームネットワーク１３５１に存在し続ける間は、引き続き３Ｇ．ＩＰ．ＵＥ１３５０を使用してＣＮ１３６５と通信を行う。ＣＮ１３６６に関しては、ＣＮ１３６６がホームネットワーク１３５１内に存在しているとＨｅＮＢ１３５２がＵＥ１３５０へ通知する場合には、ＵＥ１３５０はＨＮ．ＩＰ．ＵＥ１３５０を使用してＣＮ１３６６と通信を行う。
さらに、上記の方法は、ＵＥが非３ＧＰＰアクセスにおいて複数のモビリティプロトコルを動作している場合のシナリオに対しても適用可能である。例えば、図１８を参照すると、ＡＮＤＳＦサーバはＵＥ１８００に対して（ポリシによって）、非３ＧＰＰアクセスに存在する間（すなわち、ｅＰＤＧ１８０３に接続されている間）は、ＣＮ１８０５とのセッションはローカルブレイクアウトが許可されていないことを通知することが可能である。その結果、ＵＥ１８００は、ｅＰＤＧ１８０３に対してローカルブレイクアウト用ＩＰアドレスを要求せず、非３ＧＰＰアクセス内に存在する間は、引き続き３Ｇ．ＩＰ．ＵＥ１８００を使用し続けて、ＣＮ１８０５と通信を行う。
また、上記の方法は、ＵＥがマクロセルｅＮＢ内に存在しており、マクロセルにおいて、ローカルブレイクアウト用ＩＰアドレスが割り当てられている場合に適用可能である。例えば、ＡＮＤＳＦサーバはＵＥに対して（ポリシによって）、特定のコレスポンデントノードとのセッションに関して、ＵＥはマクロセルに存在する間はローカルブレイクアウトの実行が許可されていると通知することが可能である。その結果、ＵＥは、まずコレスポンデントノードの位置を決定し、ローカルブレイクアウト経路が最適であると考えられる場合は、マクロセル内に存在する間はコレスポンデントノードと通信を行うためのローカルブレイクアウト用ＩＰアドレスを要求する。
＜第３５の実施の形態：ＲＲメッセージのマーク付け−キャッシュ＞
次に、本発明の第３５の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法が、ＵＥがモバイルＩＰｖ６の経路最適化処理を実行する際にも適用可能であることについて説明する。例えば、Ｐ−ＧＷがマーク付けするパケットは、モバイルＩＰｖ６経路最適化処理（例えば、気付アドレステスト）に関与しているパケットである。
図１９は、Ｐ−ＧＷによるマーク付けの方法がどのようにモバイルＩＰｖ６経路最適化処理に適用されるかの一例を示すシーケンスチャートである。図１９において、ＵＥ１９００はｅＰＤＧ１９０１に接続されており、２つのタイプのモビリティ管理プロトコルを動作している。第１のモビリティプロトコルはＰＭＩＰであり、ｅＰＤＧ１９０１がＰＢＵをＰ−ＧＷ１９０２へ送信する。ＰＭＩＰでは、ｅＰＤＧ１９０１がＵＥ１９００の移動に関する情報をＰ−ＧＷ１９０２へ更新（通知）する。第２のモビリティプロトコルはＣＭＩＰであり、ＵＥ１９００がＢＵをＰ−ＧＷ１９０２へ送信する。ＣＭＩＰでは、ＵＥ１９００は、ＵＥ１９００がまだＥＰＣ内でアクティブであることをＰ−ＧＷ１９０２へ更新（通知）する。
ＵＥ１９０３はｅＰＤＧ１９０４に接続されており、２つのタイプのモビリティ管理プロトコルを動作している。第１のモビリティプロトコルはＰＭＩＰであり、ｅＰＤＧ１９０４がＰＢＵをＰ−ＧＷ１９０２へ送信する。ＰＭＩＰでは、ｅＰＤＧ１９０４は、ＵＥ１９０３の移動に関する情報をＰ−ＧＷ１９０２へ更新（通知）する。第２のモビリティプロトコルはＣＭＩＰであり、ＵＥ１９０３がＢＵをＰ−ＧＷ１９０２へ送信する。ＣＭＩＰでは、ＵＥ１９０３が、ＵＥ１９０３がまだＥＰＣ内でアクティブであることをＰ−ＧＷ１９０２へ更新（通知）する。ここで、ｅＰＤＧ１９０１及びｅＰＤＧ１９０４に関して、デフォルトの次ホップがＰ−ＧＷ１９０２であると仮定する。
ＵＥ１９００は、ＵＥ１９０３との最適化通信を開始するよう決定し、モバイルＩＰｖ６経路最適化処理を実行する。ＵＥ１９００は、気付アドレステストイニット（ＣｏＴｉ：care-of address test）メッセージをＵＥ１９０３へ送信する（ステップＳ１９０５）。ここで、ｅＰＤＧ１９０１はＵＥ１９００の次ホップであり、ｅＰＤＧ１９０１は、ｅＰＤＧ１９０１の次ホップであるＰ−ＧＷ１９０２へＣｏＴｉメッセージを渡す（ステップＳ１９０６）。Ｐ−ＧＷ１９０２はｅＰＤＧ１９０４へＣｏＴｉメッセージを渡し（ステップＳ１９０７）、ｅＰＤＧ１９０４は、ＵＥ１９０３へＣｏＴｉメッセージを渡す（ステップＳ１９０８）。
ＵＥ１９０３は、ＣｏＴｉメッセージに応答して、ＵＥ１９００へ気付アドレステスト（ＣｏＴ：Care-of test）メッセージを送信する（ステップＳ１９０９）。ここで、ｅＰＤＧ１９０４はＵＥ１９０３の次ホップであり、ｅＰＤＧ１９０４は、ｅＰＤＧ１９０４の次ホップであるＰ−ＧＷ１９０２へＣｏＴメッセージを渡す（ステップＳ１９１０）。Ｐ−ＧＷ１９０２は、ＵＥ１９０３の位置をＵＥ１９００へ通知するよう指示されているので、ＣｏＴメッセージに通知を挿入し、そのＣｏＴメッセージをｅＰＤＧ１９０１へ渡す（ステップＳ１９１１）。ｅＰＤＧ１９０１は、通知付きＣｏＴメッセージをＵＥ１９００へ渡す（ステップＳ１９１２）。この通知によって、ＵＥ１９００は、モバイルＩＰｖ６の経路最適化を利用した場合でも、ＵＥ１９０３からのパケットがｅＰＤＧ１９０１を経由することを把握する。すなわち、ＵＥ１９００は、モバイルＩＰｖ６経路最適化の恩恵を受けない。ＵＥ１９００は、その代わりに、ＰＭＩＰのために割り当てられたＩＰアドレスを使用して、ＵＥ１９０３との通信を行う。ＰＭＩＰを使用することによって、ＵＥ１９００は、ＵＥ１９００のモビリティをＰ−ＧＷ１９０２へ更新する負荷が軽減される。
また、ＵＥ１９００がＰＭＩＰを使用すると決定することに加えて、ＵＥ１９００は、この決定結果をＵＥ１９００の揮発性メモリにキャッシュする。これは、ＵＥ１９００がＵＥ１９０３からのパケットがＰ−ＧＷ１９０２を通過するという通知をＰ−ＧＷ１９０２から引き続き受信した場合には、ＵＥ１９００は、モバイルＩＰｖ６経路最適化を開始しないことを意味する。キャッシュを行う利点は、ＵＥ１９００がモバイルＩＰｖ６の経路最適化を行って、ＵＥ１９００が以前の試行と同一の結果（すなわち、ＵＥ１９０３からのパケットがＰ−ＧＷ１９０２を通過するのでＰＭＩＰを使用するという結果）を取得する必要性をなくす点である。
＜第３６の実施の形態：ＲＲメッセージのマーク付け−キャッシュの寿命＞
次に、本発明の第３６の実施の形態では、ＵＥがモバイルＩＰｖ６の経路最適化をキャッシュする方法において、キャッシュされた結果が有限時間内でのみ有効であるようにしてもよいことについて説明する。
例えば、ＵＥ１９００は、モバイルＩＰｖ６の経路最適化の結果を１０分間のみキャッシュする。１０分後、ＵＥ１９００は、モバイルＩＰｖ６の経路最適化を再試行し、ＵＥ１９００がＵＥ１９０３への最適化経路を実現できるかどうかを判断する。また、別の例では、ＵＥ１９００は、ＵＥ１９０３がそのＩＰアドレスを変更した旨を検出すると、モバイルＩＰｖ６の経路最適化を再試行し、ＵＥ１９００がＵＥ１９０３への最適化経路を実現できるかどうかを判断する。ＵＥ１９００がＩＰアドレスの変更を検出する方法は、例えば、ＵＥ１９０３がモビリティに従ってそのＩＰアドレスをＵＥ１９００へアップデートすることであるが、これに限定されるものではない。無限の時間ではなく有限時間だけキャッシュする利点は、ＵＥ１９００がＵＥ１９０３への最適化経路をセットアップできる別の位置にＵＥ１９０３が移動した場合に、再試行によって、ＵＥ１９００による早期の通知で最適化経路が確実にセットアップされる点にある。
＜第３７の実施の形態：Ｐ−ＧＷからのマークを利用して、フローフィルタリングのフィルタルールをどこに設定するかを判断する＞
次に、本発明の第３７の実施の形態において、Ｐ−ＧＷがＵＥに送信するパケットにマークを付ける方法によって、フローフィルタリングによってＵＥを支援するネットワークエンティティがどれかを、ＵＥが決定できるようにすることも可能である。
例えば図１８において、ＵＥ１８００は、ＣＮ１８０５が直接ｅＰＤＧ１８０３に接続されているという通知をｅＰＤＧ１８０３から受信する。これにより、ＣＮ１８０５からのフローをフィルタリングするために、Ｐ−ＧＷ１８０４にフィルタリングルールを設定するより、ＵＥ１８００は、ｅＰＤＧ１８０３にフィルタリングルールを設定する。この方法の利点は、ｅＰＤＧ１８０３にフィルタリングルールを設定することで、パケットがｅＰＤＧ１８０３で折り返され、Ｐ−ＧＷ１８０４とｅＰＤＧ１８０３との間を通過するために必要な一往復時間を節約する点にある。
なお、本発明は、最も実用的かつ好適な実施の形態と思われるものを考えて説明されているが、本発明の範囲を逸脱しない程度の派生例が可能である。例えば、上述のすべての実施の形態において、３Ｇインタフェース及びＷｉＭＡＸインタフェースが考慮されているが、本発明はインタフェースのタイプが３Ｇインタフェース及びＷｉＭＡＸインタフェースに限定されるものではなく、ＵＥが異なるタイプのアクセス技術を有し、異なるタイプのインタフェースを用いてネットワークへ接続する場合においても適用可能である。また、上述の実施の形態では、ネットワークベースのモビリティ管理プロトコルとしてＰＭＩＰｖ６を参照しているが、これに限定されず、ＧＴＰを用いてもよい。また、使用するＩＰプロトコルのバージョンとしてＩＰｖ６を前提としているが、これに限定されず、ＩＰｖ４を用いてもよい。
また、物理的に異なるインタフェースに限らず、物理的なインタフェースが同一（共用されている）でも使用するプロトコルが違う（ネットワーク内でのトンネリングの構成が異なるなどの要因により異なる選択の結果が異なる）ような論理的なインタフェースの選択の場合においても適用可能である。物理的なインタフェースを共用する一例としては、ＵＥは本発明を実施するうえでの論理的なインタフェースが複数あればよく、例えば、１つの無線部を複数の接続方式で共用し、ネットワークインタフェースの観点からはその変化が問題にならない程度の速度で切り替えたり、レイヤ２で論理的なリンクを維持したりすることにより、ネットワーク部からは複数のインタフェースを介してネットワークに接続している場合と同等に動作できるよう構成されていてもよい。
また、通信相手との接続の状態や経路を示すマークは、特定のマークの有無による指示は一例であり、マークの有無の論理が逆であってもよく、複数のマークを用いてより多くの状態を区別できるようになっていてもよい。このようなマークの意味内容自体は本発明を実施するうえで変更可能である。
また、ＵＥ（移動端末）は複数の通信デバイスから構成されるものであってもよく、例えばパーソナルコンピュータなどの電子計算機に外挿型あるいは組み込み型の３ＧＰＰ通信用デバイスモジュールや非３ＧＰＰ通信デバイスモジュールを装着するものであってもよい。こうした多様な移動端末においても本発明は同等の効果を有するものである。
さらに、上述のシナリオはすべて３ＧＰＰアーキテクチャに関連しているが、本発明は、異種アクセスネットワークが配置されており、任意のモビリティ管理メカニズムが任意のアクセス技術タイプを通じて使用されるよう制限されているすべての技術に対して適用可能である。
また、上述の実施の形態では、ローカルモビリティ管理の環境であることが仮定されているが、モバイルルータ（ＭＲ：Mobile Router)（及びその配下のノード）により構成されたモバイルネットワーク（Mobile Network)（若しくは階層化されたモバイルネットワーク）に本発明を適用することも可能である。
例えば、モバイルネットワークの構成方法の１つであるＮＥＭＯ（Network Mobility)はＭＲがＨＡ（Home Agent）に移動ネットワーク（及び端末）の移動登録を行うことにより、移動端末に対するモビリティサポートが提供されるが、本明細書におけるＭＡＧはＭＲに対応する形で適用可能である。この場合、ＬＭＡはＭＲのＨＡに対応すると考えることができる。さらに、ＰＭＩＰを用いたネットワークを提供するネットワークオペレータがローミング関係などにより、ＰＭＩＰで構成しているＭＡＧ−ＬＭＡ間のトンネルを多段に用いるような場合は階層化されたモバイルネットワークに相当する。
さらに、オーバレイネットワークの環境に本発明を適用することも可能である。例えば、ＭＡＧによる移動端末に対するモビリティサポートをｐＨＡ（Proxy HA）に対応する形で適用可能である。この場合、モバイルノードの移動の起点（ある時点を基準とするものであったり（相対的）、ネットワークオペレータへの登録の状態（確定的）であったり、様々な場合があり得る）となるホームエージェント若しくはモバイルノードの接続先であるホームエージェントから登録情報を受信する他のホームエージェントはＬＭＡに対応すると考えることができる。
また、上記の本発明の実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるＬＳＩ（Large Scale Integration）として実現される。これらは個別に１チップ化されてもよいし、一部又はすべてを含むように１チップ化されてもよい。なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ（Integrated Circuit）、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。
本発明の通信システム、移動端末、ネットワークノード並びに基地局装置は、各インタフェースで異なるモビリティ管理メカニズムが使用されている複数インタフェースのＵＥが適切なインタフェースを選択するか、あるいは、複数のアドレスを有するＵＥが適切なアドレスを選択するし、その結果、最適な経路を使用してＣＮと通信を行うことを可能にするという効果を有しており、パケット交換型データ通信ネットワークのシステム（特に、ＰＭＩＰなどのネットワークベースのローカルモビリティ管理プロトコルが実装されているネットワークシステム）及びクライアントベースのモビリティ管理プロトコルが実装されている移動端末における通信技術分野に適用可能である。

Claims (20)

  1. 異なるアクセス技術を用いた複数のインタフェースを使用してネットワークベースのモビリティ管理ドメインへ接続可能であり、通信相手である通信相手ノードとの間に前記複数のインタフェースに対応した複数の通信経路を有する移動端末と、前記ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードとを有する通信システムであって、
    前記ネットワークノードが前記通信相手ノードから前記移動端末へ送信されるパケットの監視を行って、前記通信相手ノードから前記移動端末へ送信される前記パケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断して、その判断結果を前記移動端末へ通知し、
    前記移動端末は、前記判断結果に基づいて、前記通信相手ノードとの通信に使用する通信経路を選択するよう構成されている通信システム。
  2. 前記ネットワークノードは、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていると判断した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていることを前記判断結果として前記移動端末へ通知するよう構成されている請求項１に記載の通信システム。
  3. 前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていないと判断した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていないことを前記判断結果として前記移動端末へ通知するよう構成されている請求項１に記載の通信システム。
  4. 前記ネットワークノードは、ネットワークベースのモビリティ管理に係る前記移動端末のバインディング情報と、前記移動端末によるクライアントベースのモビリティ管理に係る前記移動端末のバインディング情報とを保持し、両方のバインディング情報を参照することによって、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断するよう構成されている請求項１に記載の通信システム。
  5. 前記ネットワークノードは、前記通信相手ノードから前記移動端末へ送信されるパケットが前記ネットワークベースのモビリティ管理ドメイン内から届き、かつ、前記ネットワークベースのモビリティ管理ドメイン内へ転送することを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていることを前記判断結果として前記移動端末へ通知するよう構成されている請求項１に記載の通信システム。
  6. 前記ネットワークノードは、前記判断結果を前記移動端末へ送信されるデータパケットに埋め込んで通知するよう構成されている請求項１に記載の通信システム。
  7. 前記移動端末が前記ネットワークノードに対して、前記通信相手ノードから前記移動端末へ送信されるパケットの検出要求を送信し、前記ネットワークノードは、前記パケットの検出要求を受信した場合に前記パケットの監視を開始するよう構成されている請求項１に記載の通信システム。
  8. 前記通信相手ノードが前記移動端末に対して複数の通信経路を有し、かつ、前記移動端末から前記通信相手ノードへ送信されるパケットの検出要求を送信することが可能な場合には、前記移動端末及び前記通信相手ノードはどちらが前記パケットの検出要求を行うかを交渉によって決定するよう構成されている請求項７に記載の通信システム。
  9. 前記移動端末が複数のインタフェース又は複数のアドレスを有しており、前記インタフェース又は前記アドレスを選択することによって前記通信経路を選択するよう構成されている請求項１に記載の通信システム。
  10. ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードが配置されている前記ネットワークベースのモビリティ管理ドメインへ異なるアクセス技術を用いた複数のインタフェースを使用して接続可能であり、通信相手である通信相手ノードとの間に前記複数のインタフェースに対応した複数の通信経路を有する移動端末であって、
    前記ネットワークノードが前記通信相手ノードから前記移動端末へ送信されるパケットの監視を行って、前記通信相手ノードから前記移動端末へ送信されるパケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断した判断結果を受信する受信手段と、
    前記判断結果に基づいて、前記通信相手ノードとの通信に使用する通信経路を選択する通信経路選択手段とを、
    有する移動端末。
  11. 前記通信相手ノードから前記移動端末へ送信されるパケットの監視を前記ネットワークノードに開始させるために、前記通信相手ノードから前記移動端末へ送信されるパケットの検出要求を前記ネットワークノードへ送信するパケット検出要求手段を有する請求項１０に記載の移動端末。
  12. 前記通信相手ノードが前記移動端末に対して複数の通信経路を有し、かつ、前記通信相手ノードが前記移動端末から前記通信相手ノードへ送信されるパケットの検出要求を送信することが可能な場合には、前記移動端末及び前記通信相手ノードのどちらが前記パケットの検出要求を行うかを前記通信相手ノードとの間における交渉によって決定する交渉手段を有する請求項１１に記載の移動端末。
  13. 前記交渉によって前記移動端末が前記パケットの検出要求を行い、かつ、前記判断結果に基づいて前記通信相手ノードとの通信に使用する通信経路を選択した場合に、前記通信相手ノードが選択すべき通信経路に関する情報を前記通信相手ノードへ通知し、その許諾を前記通信相手ノードから受信する選択結果送受信手段を有する請求項１２に記載の移動端末。
  14. 前記選択結果送受信手段が、前記通信相手ノードが選択すべき通信経路に関する情報と共に、前記判断結果を前記通信相手ノードへ通知するよう構成されている請求項１３に記載の移動端末。
  15. 前記交渉によって前記通信相手ノードが前記パケットの検出要求を行い、かつ、前記判断結果に基づいて前記通信相手ノードとの通信に使用する通信経路を選択した場合に、前記移動端末が選択すべき通信経路に関する情報を前記通信相手ノードから受信し、その許諾を前記通信相手ノードへ送信する選択結果送受信手段を有する請求項１２に記載の移動端末。
  16. 前記選択結果送受信手段が、前記移動端末が選択すべき通信経路に関する情報と共に、前記通信相手ノード側のネットワークノードによって判断された判断結果を前記通信相手ノードから受信するよう構成されている請求項１５に記載の移動端末。
  17. 複数のインタフェース又は複数のアドレスを有しており、前記通信経路選択手段は、前記インタフェース又は前記アドレスを選択することによって前記通信経路を選択するよう構成されている請求項１０に記載の移動端末。
  18. 前記通信経路選択手段が、
    前記通信相手ノードから前記移動端末へ送信されるパケットの監視を、前記移動端末が接続している基地局装置に開始させるために、前記通信相手ノードから前記移動端末へ送信されるパケットの検出要求を前記基地局装置へ送信する第２のパケット検出要求手段と、
    前記基地局装置が前記移動端末の通信相手である通信相手ノードから前記移動端末へ送信されるパケットの監視を行って、前記通信相手ノードから前記移動端末へ送信されるパケットを検出した場合に、前記通信相手ノードが同一の前記基地局装置に接続されているかどうかを判断した第２の判断結果を受信する第２の受信手段とを有し、
    前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されていることを示す判断結果を前記ネットワークノードから受信した場合に、前記第２のパケット検出要求手段によって前記パケットの検出要求を前記基地局装置へ行い、前記第２の受信手段によって受信した前記第２の判断結果に基づいて、前記通信相手ノードとの通信に使用する通信経路を選択するよう構成されている請求項１０に記載の移動端末。
  19. 前記通信経路の選択に係るポリシを取得するポリシ取得手段を有し、
    前記通信経路選択手段は、前記判断結果に加えて、前記ポリシ取得手段で取得された前記ポリシに基づいて、前記通信相手ノードとの通信に使用する通信経路を選択するよう構成されている請求項１０に記載の移動端末。
  20. ネットワークベースのモビリティ管理ドメインに接続されている端末の位置管理を行うネットワークノードであって、
    異なるアクセス技術を用いた複数のインタフェースを使用して前記ネットワークベースのモビリティ管理ドメインへ接続可能であり、通信相手である通信相手ノードとの間に前記複数のインタフェースに対応した複数の通信経路を有する移動端末に関して、前記移動端末の通信相手である通信相手ノードから前記移動端末へ送信されるパケットの監視を行うパケット監視手段と、
    前記通信相手ノードから前記移動端末へ送信される前記パケットを検出した場合に、前記通信相手ノードが同一の前記ネットワークベースのモビリティ管理ドメインに接続されているかどうかを判断する判断手段と、
    前記判断手段による判断結果を前記移動端末へ通知する通知手段とを、
    有するネットワークノード。
JP2011519536A 2009-06-17 2010-06-11 通信システム、移動端末、ネットワークノード並びに基地局装置 Expired - Fee Related JP5688016B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2011519536A JP5688016B2 (ja) 2009-06-17 2010-06-11 通信システム、移動端末、ネットワークノード並びに基地局装置

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2009144033 2009-06-17
JP2009144033 2009-06-17
JP2010050056 2010-03-08
JP2010050056 2010-03-08
PCT/JP2010/003906 WO2010146816A1 (ja) 2009-06-17 2010-06-11 通信システム、移動端末、ネットワークノード並びに基地局装置
JP2011519536A JP5688016B2 (ja) 2009-06-17 2010-06-11 通信システム、移動端末、ネットワークノード並びに基地局装置

Publications (2)

Publication Number Publication Date
JPWO2010146816A1 JPWO2010146816A1 (ja) 2012-11-29
JP5688016B2 true JP5688016B2 (ja) 2015-03-25

Family

ID=43356149

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011519536A Expired - Fee Related JP5688016B2 (ja) 2009-06-17 2010-06-11 通信システム、移動端末、ネットワークノード並びに基地局装置

Country Status (3)

Country Link
US (1) US8774039B2 (ja)
JP (1) JP5688016B2 (ja)
WO (1) WO2010146816A1 (ja)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8631101B2 (en) * 2010-11-09 2014-01-14 Cisco Technology, Inc. Dynamic address assignment for address aggregation in low power and lossy networks
CN102595386A (zh) * 2011-01-06 2012-07-18 北京三星通信技术研究有限公司 一种支持用户设备ue移动性的方法
SG10201403161UA (en) * 2011-02-11 2014-07-30 Interdigital Patent Holdings Systems and methods for extended/enhanced logical interface behavior
JP5809295B2 (ja) * 2011-02-24 2015-11-10 インターデイジタル パテント ホールディングス インコーポレイテッド 安定なローカルブレークアウトの概念および使用
US20120230269A1 (en) * 2011-03-08 2012-09-13 Electronics And Telecommunications Research Institute Integrated access apparatus for all-ip converged network
US9344874B2 (en) 2011-03-15 2016-05-17 Nec Corporation Mobility management system, mobility management method, access GW apparatus, mobility management control apparatus, and computer-readable medium
WO2012142105A1 (en) * 2011-04-11 2012-10-18 Interdigital Patent Holdings, Inc. Session manager and source internet protocol (ip) address election
EP2603046B1 (en) * 2011-12-05 2014-08-06 Alcatel Lucent Communication process and communication network comprising a local access network discovery and selection function, L-ANDSF
CN103312441B (zh) * 2012-03-15 2017-11-17 华为技术有限公司 数据包传输方法及系统、发送端设备与接收端设备
EP2685664A1 (en) * 2012-07-12 2014-01-15 Thomson Licensing Multicast transmission using a unicast protocol
EP3474607A1 (en) * 2012-08-31 2019-04-24 Sony Corporation Communication control apparatus, terminal apparatus, communication control method, program, and communication control system
CN103686671B (zh) * 2012-09-14 2019-01-18 中兴通讯股份有限公司 一种通知接入网位置信息的方法和系统
US10356640B2 (en) 2012-11-01 2019-07-16 Intel Corporation Apparatus, system and method of cellular network communications corresponding to a non-cellular network
US9414392B2 (en) 2012-12-03 2016-08-09 Intel Corporation Apparatus, system and method of user-equipment (UE) centric access network selection
BR112015014223A2 (pt) 2013-01-17 2017-07-11 Intel Ip Corp aparelho, sistema e método para comunicar informações de rede de acesso não celular através de uma rede celular
US9160515B2 (en) 2013-04-04 2015-10-13 Intel IP Corporation User equipment and methods for handover enhancement using scaled time-to-trigger and time-of-stay
US10237681B2 (en) * 2017-02-06 2019-03-19 Samsung Electronics Co., Ltd. Registration management method for terminal accessing 5G network on non-3GPP access
US11218949B2 (en) 2017-03-20 2022-01-04 Motorola Mobility Llc Accessing a local data network via a mobile data connection

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003249939A (ja) * 2002-02-22 2003-09-05 Mitsubishi Electric Corp 通信システムおよび通信方法
WO2008116494A1 (en) * 2007-03-23 2008-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Proxy mobile ip routing
WO2009044539A1 (ja) * 2007-10-05 2009-04-09 Panasonic Corporation 通信制御方法及びネットワークノード並びに移動端末

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60113735T2 (de) 2001-10-11 2006-06-29 Nokia Corp. Verfahren und system zum verwalten von datenflüssen zwischen mobilen knoten, zugangsroutern und gleichrangigen knoten
US7539164B2 (en) 2002-06-14 2009-05-26 Nokia Corporation Method and system for local mobility management
KR100617733B1 (ko) * 2005-01-22 2006-08-28 삼성전자주식회사 통신 시스템에서 네트워크 재진입 시스템 및 방법
US20070110035A1 (en) * 2005-11-14 2007-05-17 Broadcom Corporation, A California Corporation Network nodes cooperatively routing traffic flow amongst wired and wireless networks
JP2007208762A (ja) * 2006-02-03 2007-08-16 Hitachi Communication Technologies Ltd 基地局
JP5048761B2 (ja) 2006-05-29 2012-10-17 パナソニック株式会社 通信セッションのためのロケーション・プライバシーとルート最適化とを同時に実施する方法及び装置
EP1933520A1 (en) 2006-12-15 2008-06-18 Matsushita Electric Industrial Co., Ltd. Local mobility anchor relocation and route optimization during handover of a mobile node to another network area
US9516495B2 (en) 2007-03-01 2016-12-06 Futurewei Technologies, Inc. Apparatus and methods of PMIPv6 route optimization protocol
EP1986392B1 (en) 2007-04-26 2012-10-03 Motorola Solutions, Inc. Method for route optimization between mobile entities
JP4794520B2 (ja) 2007-05-16 2011-10-19 Ｋｄｄｉ株式会社 ネットワーク主導型移動管理プロトコルにおける通信経路を最適化するシステム、アクセスゲートウェイ、ホームエージェント、およびプログラム
EP2147541B1 (en) 2007-05-18 2016-08-31 Nokia Technologies Oy System and method for providing local ip breakout services employing access point names
WO2009084989A1 (en) 2007-12-31 2009-07-09 Telefonaktiebolaget Lm Ericsson (Publ) Optimized mobile internet access
CN101940014B (zh) 2008-02-04 2013-10-23 爱立信电话股份有限公司 用于提供路由优化的方法和设备
JP4602432B2 (ja) * 2008-03-21 2010-12-22 京セラ株式会社 基地局
CN101873674B (zh) * 2009-04-21 2013-03-27 财团法人资讯工业策进会 移动装置、基站、后端网络装置及用于移动装置的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003249939A (ja) * 2002-02-22 2003-09-05 Mitsubishi Electric Corp 通信システムおよび通信方法
WO2008116494A1 (en) * 2007-03-23 2008-10-02 Telefonaktiebolaget Lm Ericsson (Publ) Proxy mobile ip routing
JP2010521908A (ja) * 2007-03-23 2010-06-24 テレフオンアクチーボラゲット エル エム エリクソン（パブル） プロキシ・モバイルｉｐルーティング
WO2009044539A1 (ja) * 2007-10-05 2009-04-09 Panasonic Corporation 通信制御方法及びネットワークノード並びに移動端末

Also Published As

Publication number Publication date
WO2010146816A1 (ja) 2010-12-23
US8774039B2 (en) 2014-07-08
JPWO2010146816A1 (ja) 2012-11-29
US20120155313A1 (en) 2012-06-21

Similar Documents

Publication Publication Date Title
JP5688016B2 (ja) 通信システム、移動端末、ネットワークノード並びに基地局装置
US10484920B2 (en) Mobile terminal
US9929952B2 (en) Methods and apparatus for data transfer in a packet-switched data network
US8861426B2 (en) Path switching system, path switching method, and mobile terminal
WO2009153943A1 (ja) バインディングキャッシュ生成方法、バインディングキャッシュ生成システム、ホームエージェント及びモバイルノード
US9949238B2 (en) Method and apparatus for data transfer in a packet-switched network
US8891432B2 (en) Routing method, routing system, mobile node, home agent, and home base station
US20120063428A1 (en) Interface Switching System, Mobile Node, Proxy Node, and Mobile Management Node
US20110134869A1 (en) Prefix allocation administration system and mobile terminal, and prefix allocation administration device
US20110002248A1 (en) Mobile terminal and network node
JP4834133B2 (ja) 電気通信
WO2010146815A1 (ja) 移動管理プロトコル選択方法、移動管理プロトコル選択システム、モバイルノード、ホームエージェント及び代理ノード
WO2011055525A1 (ja) 通信システム及び移動端末並びにモビリティ管理ノード
EP2068527A1 (en) Network control of an MAP selection and of a route selection in a Mobile IP environment

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130109

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140304

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140428

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20140610

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140630

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20141224

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20150123

R150 Certificate of patent or registration of utility model

Ref document number: 5688016

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees