JP5438209B2 - ルート最適化エージェントを使用した通信ノード間のデータパスのルート最適化 - Google Patents

ルート最適化エージェントを使用した通信ノード間のデータパスのルート最適化 Download PDF

Info

Publication number
JP5438209B2
JP5438209B2 JP2012505095A JP2012505095A JP5438209B2 JP 5438209 B2 JP5438209 B2 JP 5438209B2 JP 2012505095 A JP2012505095 A JP 2012505095A JP 2012505095 A JP2012505095 A JP 2012505095A JP 5438209 B2 JP5438209 B2 JP 5438209B2
Authority
JP
Japan
Prior art keywords
communication node
gateway
tunnel
address
node
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
JP2012505095A
Other languages
English (en)
Other versions
JP2012524437A (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 Corp
Panasonic Holdings Corp
Original Assignee
Panasonic Corp
Matsushita Electric Industrial Co Ltd
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 Corp, Matsushita Electric Industrial Co Ltd filed Critical Panasonic Corp
Publication of JP2012524437A publication Critical patent/JP2012524437A/ja
Application granted granted Critical
Publication of JP5438209B2 publication Critical patent/JP5438209B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/02Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08Mobility data transfer
    • H04W8/082Mobility data transfer for traffic bypassing of mobility servers, e.g. location registers, home PLMNs or home agents
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W48/00Access restriction; Network selection; Access point selection
    • H04W48/16Discovering, processing access restriction or access information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、第2の通信ノードのネットワーク内でルート最適化エージェントを介して最適なデータルートを確立する2つの通信ノード間のデータパスを最適化する方法に関する。さらに、本発明は、本発明に関与するモバイルノード、ルート最適化エージェント、及びゲートウェイに関する。
通信システムはインターネットプロトコル(IP)ベースのネットワークの方にますます進化している。これらは通常、音声及びデータがばらばらに、いわゆるパケットで1つの端末から別の端末に送信される多くの相互接続ネットワークから構成される。IPパケットは、ルータによってコネクションレス方式で宛先にルーティングされる。したがって、パケットはIPヘッダとペイロード情報とによって構成され、ヘッダは特に送信元及び宛先のIPアドレスから構成されている。
スケーラビリティの理由から、IPネットワークは階層アドレス指定方式を採用している。したがって、IPアドレスは対応する端末を特定するだけではなく、それに加えてこの端末に関する位置情報も含んでいる。ルーティングプロトコルにより提供される追加情報により、ネットワーク内のルータは特定の宛先に向けた次のルータを特定することができる。
トンネリングはデータパケットを別のデータパケットのペイロードとして送信するために、すなわち、同じ特定のOSI層の別のプロトコルでカプセル化されたデータパケットを伝送するために利用されるメカニズムである。カプセル化するデバイスと非カプセル化するデバイスとの間にトンネルと呼ばれる論理構成体が確立され、このプロセス自体がトンネリングと呼ばれている。異なるネットワークプロトコルを支援するネットワークを介してデータパケットを送信するためにトンネリングを利用してもよく、例えば、IPv4ネットワークを介して伝送するためには、IPv6パケットをIPv4パケット内にカプセル化する必要がある。トンネリングは、安全ではないと見なされるネットワークを介しての安全な伝送を提供するために利用されてよい。例えば、認証されたエンティティ間でデータを両方のエンティティを接続する下層のネットワークに対して透明な形(transparently)でトンネリングするために、IPセキュリティプロトコル(IPsec)を使用することができる。
通常、端末の電源をオンにすると、それはアクセスネットワークのIPアドレスプレフィックスに基づくIPアドレスを構成する。端末がモバイル(いわゆるモバイルノード、MN)であり、IPプレフィックスアドレスが異なるサブネット間を移動する場合は、階層IPアドレス指定方式であるため、そのIPアドレスをトポロジー的に正しいアドレス(topological correct address)に変更しなければならない。しかし、TCP接続などのトランスポート層接続は通信ノードのIPアドレス(及びポート)にバインドされているので、ノードの1つが例えば移動によりIPアドレスを変更されると、アクティブなIPセッションへの接続が切断される。このような問題に対処する可能なプロトコルの1つがMIPv6プロトコルである。
●モバイルIPv6(MIPv6)
MIPv6とも言われるモバイルIPv6(参照により本明細書に組み込むものとするD.Johnson、C.Perkins,J.Arkko著「IPv6でのモビリティサポート」IETF RFC3775、2004年6月、http://www.ietf.orgにて利用可能であり、参照により本明細書に組み込まれる)は、高位層及びアプリケーションに対しての透過的(transparent)な方法、すなわち高位層の接続を遮断せずに、モバイルノードがサブネット間を移動できるようにするIPベースのモビリティプロトコルである。すなわち、モバイルノードはIPv6インターネットネットワーク間を移動中に到達可能状態を保つ。MIPv6の基本原理は、モバイルノードがインターネット内のトポロジー的な位置(topological location)に関わりなく、常にそのホームアドレス(HoA)によって特定され、一方、モバイルノードの気付アドレス(CoA)がモバイルノードの現在のトポロジー的な位置(current topological location)に関する情報を提供する。MIPv6プロトコルは通常、非3GGPネットワーク内で使用される。
より詳細には、モバイルノードは、構成された2つのIPアドレス、すなわち気付アドレス及びホームアドレスを有している。モバイルノードの高位層は、以下では、通信相手ノード(CN)と呼ばれる通信相手(宛先端末)と通信するためにホームアドレスを使用する。このアドレスは変らず、モバイルノードを特定する目的をもつ。これはトポロジー的にはモバイルノードのホームネットワーク(HN)に属する。これに対して、気付アドレスは、サブネット変更(subnet change)を引き起こすすべての移動で変化し、かつ、ルーティングインフラストラクチャ(routing infrastructure)用のロケータとして使用される。トポロジー的には、これはモバイルノードが目下、在圏(visit)しているネットワークに属する。ホームリンク上に位置するホームエージェント(HA)セットのうちの1つは、モバイルノードのホームアドレスへのモバイルノードの気付アドレスのマッピングを保持し、モバイルノード用の入トラフィック(incoming traffic)をその現在の位置にリダイレクト(redirect)する。単一のホームエージェントではなくホームエージェントのセットを配備する理由は、冗長性及び負荷分散のためである。
モバイルIPv6は現在、双方向トンネリング(図1)とルート最適化(図2)の2つの動作モードを定義している。双方向トンネリングを利用して、通信相手ノード101によって送信され、モバイルノード102のホームアドレスにアドレス指定されたデータパケットは、ホームネットワーク110内のホームエージェント111によって傍受され、外部ネットワーク120にアンカされているモバイルノード102の気付アドレスにトンネリングされる。モバイルノード102によって送信されたデータパケットは、ホームエージェント111に逆トンネリングされ、これがパケットを非カプセル化し、これらを通信相手ノード101に送信する。逆トンネリングとは、モバイルノードを始端とし、ホームエージェントで終端する(「通常」トンネリングを補完する)補足的な逆トンネルを介してパケットが送信されることを意味する。
MIPv6でのこの動作では、モバイルノード102の気付アドレスはホームエージェント111のみに通知される。したがって、モバイルノードはホームエージェントにバインディング更新(BU)メッセージを送信する。これらのメッセージはIPsecセキュリティアソシエーションを経て送信され、そして、認証され、かつ、完全性が保護されている。
欠点は、モバイルノードがホームネットワークと遠距離にあり、通信相手ノードがモバイルノードに近い場合は通信経路が不要に長く、その結果、ルーティングが非効率になり、パケット遅延が増大することである。
MNがHAとともにIPsecアソシエーションを有するには、MNは事前にブートストラップを実行する必要がある。ブートストラップは、少なくとも以下の情報を得るプロセスである。すなわち、ホームアドレス、ホームエージェントのアドレス、及びホームエージェントをもつセキュリティアソシエーションである。この情報は、MNがホームエージェントに対してCoAを登録する前に必要である。MNとHAとの間には数秒の往復時間を要するので、このプロセスは数秒間持続してもよい。
ルート最適化モード(図2を参照)は、通信相手ノードとモバイルノードの間の直接経路を利用することにより、双方向トンネリングモードの非効率性を防ぐことができる。ROは、気付アドレスに対してのホームアドレスの現在のバインディングをCNに登録することをMNに対して要求する。これに対応して、CNはバインディングキャッシュエントリ(binding cache entry)を確立するので、MN1のHAを経て迂回せずにCNからのパケットをMNのCoAに直接ルーティングすることができる。パケットをいずれかのIPv6の宛先に送信する場合、CNはパケットの宛先アドレスのエントリのためにキャッシュされたバインディングをチェックする。
ルート最適化を使用する場合、モバイルノードはモビリティをサポートするためにバインディング更新メッセージを通信相手ノードに送り、それはデータパケットをモバイルノードに直接送ることができる。(モバイルノードのホームアドレスに宛てたパケットを直接経路でモバイルノードの気付アドレスに送るために、タイプ2のルーティングヘッダが使用される。)
通信相手ノードに送られたバインディング更新を保護するには、セキュリティアソシエーションの構成、又はモバイルノードと通信相手ノードの間に認証基盤が存在する必要はない。その代わり、正しいモバイルノードが確実にメッセージを送るようにするため、リターンルータビリティ(Return Routability)(RR)手順が用いられる。
リターンルータビリティ手順によって、通信相手ノードは、請求されている気付アドレス並びにホームアドレスに実際にアドレス指定可能であることのある程度の合理的な保証を得ることができる。この保証によってのみ、通信相手ノードは、通信相手ノードに対して、そのモバイルノードのデータトラフィックを請求されている気付アドレスに送るように指示するモバイルノードからバインディング更新を受信することができる。
これは、請求されている2つのアドレスにアドレス指定されたパケットがモバイルノードにルーティングされているか否かをテストすることによって行われる。モバイルノードは、通信相手ノードがこれらのアドレスに送るあるデータ(「キージェントークン(keygen tokens)」)を受信したことを証明できる場合のみ、テストに合格できる。暗号トークンの交換は、交換されたHoTi/HoT及びCoTi/CoTメッセージに基づく。これらのデータは、モバイルノードによってバインディングマネジメントキーに組み合わさられる。通信相手ノードへのバインディング更新メッセージの完全性と認証はバインディングマネジメントキーを用いて保護される。
したがって、HoAのCNへの、及びMNのCoAへのマッピングを可能にし、CNがMNと直接通信できるようにすることにより、MIPv6によってCNとMN間のルート最適化が可能になる。
モバイルノードは幾つかのホームエージェントを有してもよい、したがって、対応するIPsecトンネル用に各ホームエージェントの1つに、幾つかのセキュリティアソシエーションを確立してもよい。モバイルノードはホームエージェントごとに、通信に用いられる異なるホームアドレスを構成する。したがって、データパケットの送信元アドレス(source address)に応じて、データパケットが適切なIPsecトンネルを経て対応するホームエージェントに送信される。
モビリティ関連シグナリング(mobility-related signaling)がホスト(又はクライアント)とHAとの間で行われるため、モバイルIPはホストベース(又はクライアントベース)のモビリティマネジメントの範疇にある。したがって、これはクライアントモバイルIP(CMIP)と呼ばれることがある。
●プロキシMIPv6(PMIPv6)
限定された地理領域でのIPモビリティマネジメントを対象とする別のアプローチはネットワークによって管理されており、したがってMNに対して透過的(transparent)である。このアプローチはネットワークベースのローカルライズしているIPモビリティと呼ばれている。
ネットワークベースモビリティの1つの主な特徴は、アクセスネットワークエンティティがMNの移動を検出し、MNの現在地に関する情報を交換するように適切に構成されているので、MNはモビリティプロセスに関与する必要がないことである。したがって、ワイヤレスインタフェイスを経たモビリティ関連シグナリングが避けられる。ネットワークベースのモビリティマネジメントの別の利点は、MIPv6のカプセル化の必要がなく、単純なIPノード(すなわちMIP能力がないノード)用のモビリティサポートが不要であるので、無線通信によるパケットオーバーヘッドが少ないことである。インターネット技術標準化タスクフォース(IETF)機構は、モバイルIPプロトコルに基づくローカライズしているモビリティマネジメントのこのようなアプローチに取り組んでいる。ネットワークエンティティはMNのためのプロキシとして機能しているので、このプロトコルはプロキシモバイルIP(PMIP)と呼ばれている。PMIPv6と呼ばれるIPv6の変化形態や、PMIPv4と呼ばれるIPv4の変化形態がある。本発明の実施形態のほとんどがネットワークベースのモビリティマネジメントのプロトコルとしてPMIPv6を想定しているが、本発明はPMIPv6に限定されない。これはPMIPv4などの別のネットワークベースのモビリティマネジメントにも応用できる。
限定的に、かつ、トポロジー的にローカライズされているネットワークの部分にあって、ホストの関与を必要とせずに、いずれかのIPv6に対するサポートをモビリティに提供するため、プロキシモバイルIP(PMIP)は、アクセスリンクにアタッチ(接続)されるモバイルノードのモビリティ関連シグナリングを管理するMNネットワーク内のプロキシモビリティエージェントである、モバイルアクセスゲートウェイ(MAG)と呼ばれる新規の論理エンティティを導入している。これは、リンクへのモバイルノードのアタッチメント(attachment)をトラッキングし、かつ、モバイルノードのローカルモビリティアンカをシグナリングする役割を担うエンティティである。MAGは通常は、アクセスルータ(AR)と共存し、かつ、モバイルノードにモバイルIPv6のシグナリングを行っており、例えば、MNにBUメッセージを送ることができる。これらのBUメッセージにはフラグがマークされるので、プロキシBU(PBU)メッセージであることが特定できる。
ローカルモビリティアンカ(LMA)はプロキシモバイルIPv6ドメイン内のモバイルノードのためのホームエージェントである。これは、モバイルノードのホームプレフィックス用のトポロジー的なアンカポイントであり、モバイルノードの到達可能性の状態を管理するエンティティである。LMAはモバイルIPv6の基本仕様で定義されるホームエージェントの機能的能力を有し、かつ、プロキシモバイルIPv6をサポートする必要な補足的能力を有していることを理解することは重要である。通常、1つのLMAが安全なIPsecトンネルによって複数のMAGに接続される。
PMIPv6を使用する場合、ホームネットワークプレフィックスがLMAによってモバイルノードに割り当てられる。次いで、モバイルノードは、このプレフィックスに基づいてIPアドレス、例えばホームアドレスを構成することができる。このホームアドレスはすべての通信セッションに使用され、モバイルノードが現在のPMIPドメインに留まっている間は変わらない。モバイルノードと通信する通信相手ノードは、モバイルノードのホームアドレスを宛先とするデータパケットを送信する。ホームアドレスはLMAのIPプレフィックスを有している。したがって、データパケットはLMAにルーティングされ、次いで、PMIPトンネルを経てデータパケットをMAGにトンネリングする。MAGはこれらのデータパケットを非カプセル化し、かつ、対応するルーティングエントリから、モバイルノードのホームアドレスを宛先とするデータパケットが、このホームアドレスのIPプレフィックスがLMAに割り当てられているにもかかわらず、モバイルノードに転送されることを認知する。
●IPsecプロトコル及びセキュリティアソシエーション
一般に、IPsecは高位のプロトコル及びアソシエーション用のIP層で、これらが安全に通信するようにセキュリティサービスを提供する。すなわち、IPsecは安全ではない中間システムを経た2つの通信ノード間に安全な経路をセットアップする。この点に関して、IPsecはセキュリティサービスを提供するための幾つかのコンポーネントから構成され、2つの主要なものは認証ヘッダ(AH)プロトコル及びカプセル化セキュリティペイロード(ESP)プロトコルである。これらはIPデータパケットに特定のヘッダを追加することによって認証及びプライバシーを提供する。
IPsecには2つの動作モードがある。一方はトランスポート動作モードであり、他方はトンネル動作モードである。トランスポートモードでは、データパケットのペイロードだけが暗号化される。IPヘッダがプレーンテキストとして送られるため、これは完全なルーティングが可能である。トンネルモードでは、IPパケット全体が暗号化される。次いで、それはルーティングプロセスのために、新たなIPパケットにカプセル化されなければならない。トンネルモードは、ネットワーク間通信のために、すなわちルータ間に安全なトンネルをセットアップするために、使用される。
IPsecは、例えばモバイルノードとホームエージェントとの間で使用される。モバイルノードがHAをもつIPsecセキュリティアソシエーションを有するためには、MNは事前にブートストラップを実行する必要がある。したがって、モバイルノードが外部ネットワークにアタッチされても、(例えば安全なトンネルを通って)ホームエージェントとモバイルノードとの間の暗号化及び/又は認証/認可された通信が確保されてもよい。
IKEv2は、相互認証を行い、かつ、IPsecセキュリティアソシエーション(SA)を確立し、維持するために用いられる。IKEv2の基本プロトコルでは、IKE_SAが確立される際に用いられるIPアドレス間に、IKE SAとトンネルモードのIPsec SAとが暗黙に作成される。IKE_SAは通信相手どうしで共有鍵をネゴシエートするために用いられる。次いで、これらの共有鍵が、IPsec SAのネゴシエーションに用いられる。さらに、IPsec SAは通信相手、どのパケットがどのIPアドレスに送信されるべきであるか、及びこのパケットの送信に用いられる暗号などを定義する。次いで、これらのIPアドレスはトンネルモードのIPsecパケット用の外部(トンネルヘッダ)アドレスとして用いられる。
前記によって明らかなように、セキュリティアソシエーションに基づくIPsecトンネルは通常は、例えばホームエージェントのアドレスなどのエンドポイントのアドレスと、例えばMIPv6の場合の気付アドレスなどのモバイルノードのアドレスの1つとの間に確立される。他方では、モバイルノードのホームアドレスは、セキュリティアソシエーションの識別子として、又はIPsec(又はMIP)トンネルの識別子として用いられる。通常は、ホームアドレスはホームエージェントによって割り当てられ、これはホームエージェントのアドレススペースから導出される、すなわち、ホームアドレスはホームエージェント内でトポロジー的に正しいアドレスである。
●LTE−ロングタームエボリューション
3GPP(第三世代パートナシッププロジェクト)は「ロングタームエボリューション(LTE)」としての方が良く知られている研究項目「進化型(Evolved)UTRA及びUTRAN」に着手した。この研究においては、サービス供給の改善、及び、利用者とオペレータのコストの軽減のためにパフォーマンスの大幅な向上を達成する手段について検討を行っている。加えて、他の無線アクセス技術との相互作用を可能とする必要があるため、新しい進化型(evolved)パケットコアネットワークの必要性が高まった。
E−UTRANアーキテクチャの例を図3に示す。E−UTRANは進化型(evolved)ノードB(eNB又はeNodeB)からなり、モバイルノードに対してE−UTRAユーザプレーン(PDCP/RLC/MAC/PHY)及びコントロールプレーン(RRC)でのプロトコル終端を提供する。
eNBは、ユーザプレーンのヘッダ圧縮及び暗号化の機能を含む、物理(PHY)、メディアアクセス制御(MAC)、無線リンク制御(RLC)、及び、パケットデータ制御プロトコル(PDCP)の各レイヤをホストしている。eNBはまた、コントロールプレーンに対応する無線リソース制御(RRC)機能を提供する。さらに、eNBは、無線リソースマネジメント、アドミッション制御、スケジューリング、ネゴシエートされたUL−QoS(Uplink Quality of Service:アップリンクにおけるサービス品質)の実施、セル情報の報知、ユーザ及びコントロールプレーンデータの暗号化及び復号化、DL/UL(ダウンリンク/アップリンク)ユーザプレーンパケットヘッダの圧縮と解凍を含む多くの機能を実行する。eNBはまた、S1−Uインタフェイスによりサービングゲートウェイ(S−GW)にそれぞれ接続される。
S−GWは、ユーザデータパケットを経路設定並びに転送する一方で、eNB間ハンドオーバ中のユーザプレーンのモビリティアンカとして、あるいは、LTEと他の3GPP技術との間のモビリティのためのアンカとして(S4インタフェイスを終了させ、2G/3Gシステムとパケットデータネットワークゲートウェイとの間のトラフィックを中継する)の機能も果たす。アイドル状態のUEに対しては、S−GWはDLデータパスを終了させ、UEのためのDLデータが到達するとページングをトリガする。それは、IPベアラサービスのパラメータや、ネットワーク内部ルーティング情報等のUEコンテキストを管理及び保存する。それはまた、合法的な傍受の場合にはユーザトラフィックの複製を実行する。
モビリティマネジメントエンティティ(MME)は、MNのモビリティマネジメント及びセッションマネジメントの役割を担う3GPPセルラネットワークの進化型(evolved)パケットコアネットワークからのエンティティである。モビリティマネジメントはMNの以下の両方の状態で処理される。すなわち、接続状態(MNが(e)NBに接続されている場合、すなわち、MNと(e)NBの間にRRC接続と無線ベアラが確立されている場合)、又はIDLE状態(MNはPLMN(公衆地上移動体ネットワーク)に登録されているが、特定の(e)NBに接続されていない場合)である。MMEはMN用のPGWとSGWの発見、及び(e)NBとSGW/PGW間のトンネル確立を管理する。MMEは、メッセージ交換のためのS1−AP(アプリケーション)プロトコルを適用するS1−MMEインタフェイスを介してeNBに接続される。さらに、MMEはS11インタフェイスを介してSGWに接続される。
パケットデータネットワークゲートウェイ(PDN−GW又はPGW)は、UEのトラフィックの出入りポイントであることで、外部パケットデータネットワークに対するUEの接続性を提供する。UEは複数のPDNにアクセスするための2つ以上のPDN−GWとの接続性を同時に有することができる。PDN−GWは、MNのトラフィックを適切なQoSレベルにマッピングするために各ユーザに対してMN IPアドレスの割り当て、ポリシーエンフォースメント、パケットフィルタリング(例えばディープパケットインスペクション、パケットスクリーニング)を実行する。PMIPv6プロトコルがモビリティに使われる場合、PGWは、PMIPv6並びにLMAに対してのHAのファンクションマネジメントを行う。SGWが同じPLMNに位置している場合はS5インタフェイスを介して、又はSGWが外部の(在圏)PLMNに位置している場合はS8インタフェイスを介して、PGWはSGWに接続される。
PDN−GWの別の重要な役割は、3GPP技術と非3GPP技術との間のモビリティのためのアンカとして機能することである。3GPP LTEシステムは3GPPアクセスネットワークと非3GPPアクセスネットワークとで異なっている。3GPPアクセスネットワークは、3GPP機関によって標準化されたアクセス技術に基づいている。3GPPアクセスネットワーク内のMNのモビリティは通常、例えば前記PMIPv6などのネットワークベースのメカニズムによって管理される。非3GPPアクセスネットワークは、電気電子技術学会(IEEE)及び第三世代パートナシッププロジェクト2(3GPP2)などの機関によって定義されるアクセス技術に基づいている。非3GPPアクセスネットワーク内のMNのモビリティは、ホストベースのモビリティメカニズム(例えばMIPv6)、又はネットワークベースのメカニズム(例えばPMIPv6)のいずれかによって管理することができる。
モバイル端末が非3GPPアクセスネットワーク内でアクティブである場合、非3GPPアクセス内でモバイル端末にパケットをルーティングするために使用されるローカルIPアドレスが存在する。このIPアドレスは、モバイルIP用語では気付アドレスである。DSMIPv6の場合は、アドレスはモバイル端末に割り当てられ、モバイル端末は、その気付アドレスを用いてPDN−GWにバインディング更新を送っており、それはホームエージェント(HA)の機能を有している。PMIPv6の場合は、気付アドレスは、非3GPPアクセスネットワーク内に位置するモバイルアクセスゲートウェイ(MAG)のアドレスであり、MAGは、その(プロキシ)気付アドレスを用いて3GPPネットワークのPDN−GWにプロキシバインディング更新を送っており、それはローカルモビリティアンカ(LMA)の機能を有している。しかし、MNはPMIP内に唯一のアドレス、すなわちLMAで割り当てられるIPアドレスのみを有している。
●公衆地上移動体ネットワーク
公衆地上移動体ネットワーク(PLMN)は、管理機関によって、又は携帯電話サービス(land mobile telecommunications services)を提供する認可通信事業者(recognized operating agency)によって確立され、かつ、運営されるネットワークである。PLMNは、電話連絡のための別のPLMN及び公衆交換電話網(PSTN)、又はデータ及びインターネットアクセスのサービスプロバイダと相互接続する。PLMNは、例えば公衆交換電話網(PSTN)などの固定ネットワークの拡張、又はPSTNの統合部門(integral part)であると見なすことができる。これはPLMNの1つの見方であるに過ぎない。ほとんどの場合、PLMNは、サービスエリア又はサービスプロバイダに関わりなく、無線通信を可能にするハードウェアとソフトウェアのシステム全体を意味する。国別に、又はサービスプロバイダ別に別個のPLMNが定義されてもよい。
すべてのPLMN機関は、独自の管理基盤を有しており、それは、果たされる役割や、そのエンティティが使用する装備に応じて異なる機能を実行する。
しかし、PLMN機関の核心となるマネジメントアーキテクチャは、以下の通り同様である。
−顧客へのサービスの提供
−サービスを満たす基盤(広告、発注、制作、提供など)
−サービスの保証(運営、サービスの品質、不具合通報及び修理など)
−サービスの請求書送付(格付け、値引きなど)
すべてのPLMN機関の運営が完全なマネジメントアーキテクチャや関連するプロセスを実施するわけではない。特定の機関が実施する役割に応じてあるプロセスを省いてもよい。特定の機関によって実施されないプロセスは別の機関に相互接続を介してアクセスされる、これは、それらのプロセスを既に実施している。マネジメントアーキテクチャ自体は外部インタフェイスと内部インタフェイスとを区別しない。
3GPPサービスに加入しているMNは、加入データ及び認可されたサービス及びQoSレベルを維持するホームPLMN(HPLMN)を有している。MNがHPLMNとは別のネットワークにアタッチされると、そのMNはローミングノードとして表示され、在圏ネットワークは在圏PLMN(VPLMN)と呼ばれる。
一般に、「ローミング」は、携帯電話の顧客が、ホームネットワークの地理的なサービスエリア外を移動中に、在圏ネットワークを利用して自動的に音声通話の送受信、データの送受信、又はホームデータサービスを含む別のサービスへのアクセスが可能であることを定義することができる。
HPLMNとVPLMNとの差異は、特定のネットワークの加入者エントリのタイプによって技術的に生じる。モバイルデバイスが新たな在圏ネットワークに入り、ネットワークのホーム加入者レジスタ(例えばGSM(登録商標)ネットワーク内のホームロケーションレジスタ、HLR、又は、WLAN内のローカルの顧客データベース)内にエントリを有していない場合は、加入者を認証でき、ネットワークサービスを利用するどの認可もチェックできるように、まず必要な加入者データが在圏ネットワークによって、例えば加入者のホームネットワークから要求されなければならない。「訪問」加入者は在圏ネットワークのユーザデータベース(例えば在圏ロケーションレジスタ、VLR)内にエントリを取得して、認可されたネットワークサービスが利用可能にされる。2つのネットワーク、すなわちHPLMNとVPLMN間でローミング合意がない場合は、サービスの保持は不可能であり、サービスは在圏ネットワークによって拒否される。
ホーム進化型ノードB、ローカルIPアクセス(LIPA)、及び選択されたIPトラフィックオフロード(SIPTO)
3GPP仕様のベースステーションに用いられる用語は、Node B(UMTS無線アクセスネットワークの場合は、NB)、又は進化型(evolved)Node B(LTE無線アクセスネットワークの場合は、eNB)である。NB/eNBのサービスエリアはNB/eNBセル、又はマクロセルと呼ばれる。最新の進化型3GPPでは、民間団体又は企業のネットワークによって配備可能なホーム(e)Node B(H(e)NBと略称)と呼ばれるベースステーションが指定された。これらのH(e)NBは、DSL、又はその他の安全な固定回線接続を介してオペレータのコアネットワークに接続可能である。
H(e)NBは、H(e)NBと関連づけることが許可された限定されたユーザだけにサービスを提供する。H(e)NBアクセスによって提供されるこのサービスは、限定加入者グループ(CSG)サービスと呼ばれる。これには、(e)NBが接続されているPLMNにアタッチすることが許可されていればすべてのユーザが(e)NBにアタッチすることができる、通常の(e)NBマクロセルとは大きな差異がある。
このセルラネットワークの更なる新たな特徴は、無線アクセスネットワークがオペレータのコアネットワークを横断せずに、MNのIPトラフィックを直接インターネット(又は通信相手ノード)にルーティングできることである。この新たな特徴は、MNが通常のマクロ(e)NBセル、又はミクロH(e)NBセルのいずれかにアタッチされる場合に活用できる。3GPPでは、MNのIPトラフィックがコアネットワークを横断せずに直接ルーティングされる場合に、ローカルIPアクセス(LIPA)及び選択されたIPトラフィックオフロード(SIPTO)が定義される。
MNが通常の(e)NBセルにアタッチされる場合は、3GPP仕様はSIPTOについて記載する。通常、LIPAという用語は、UEが居住又は企業のIPネットワークのミクロH(e)NBセルにアタッチされる際に、MN発呼ローカルIPトラフィックのルーティング(MN-initiated local IP traffic routing)の場合に用いられる。これに対して、SIPTOという用語は、MNがミクロH(e)NBセル、又はマクロ(e)NBセルにアタッチされる際に、ネットワークサイドがローカルIPトラフィックのルーティングを実行することを決定する場合に用いられる。
LIPA又はSIPTOを実行するために、(本明細書ではL−PGWと呼ばれる)ローカルゲートウェイが使用されるものと想定されている。MNのトラフィックはL−PGWを介して宛先IPネットワーク、又は通信相手ノードに送られる。L−PGWは、アクセスネットワーク内に、又はアクセスネットワークの上位に位置することができる。しかし、L−PGWは、コアネットワークがオフロードされるように位置することが重要である。
幾つかの態様では、LIPA/SIPTOのローカル転送は、ローミングシナリオから知られるローカルブレークアウト(LBO)と同じ概念を有しており、在圏PLMN(VPLMN)内のローカル(在圏)PGWも配備される。LIPA/SIPTOとLBOとの主な差異の1つは、LBOが在圏PLMN内のモバイルノードをローミングするためにだけ用いられる用語であるのに対して、LIPA/SIPTOは1つのPLMNのアクセスネットワーク内の、又はその上位のローカルルーティングであることである。さらに、主な差異は、LBOの場合のPGWはコアネットワーク内に位置しているのに対して、LIPA/SIPTOの場合のローカルPGWは通常はアクセスネットワーク(RAN)内、又はアクセスネットワークの近傍に位置しており、LIPAの場合は、居住/企業のIPネットワーク内に位置していることである。言い換えると、LBOはHPLMNのコアネットワークのみをオフロードするが、MNのトラフィックはVPLMNのコアネットワークを横断する。
●ルート最適化
リアルタイムのIPベースのアプリケーションに対する需要と、膨大なユーザトラフィックを処理する必要性が高まっているため、効率的なパケットルーティングはますます重要になっている。例えば対話型アプリケーションの要件を満たすため、ユーザトラフィックの端末間レイテンシー(latency)を最短にすることが望ましい。
図4は、両方のモバイルノードが同じVPLMN内にある2つのモバイルノードMN1とMN2が互いに通信する例示的シナリオを示している。しかし、データトラフィックはMNのホームエージェントを介して、すなわちHPLMN1ではMN1のHA、PGW1を、又は、HPLMN2ではMN2のHA、PGW2を介して送信される。これは連続する太線で示されている。このシナリオでは、MN1はモビリティマネジメントのためにMIPv6を使用し、MN2はPMIPv6を使用するものと想定されている。したがって、MIPv6のトンネルはMN1からVPLMNを経てPGW1まで及んでいる。3GPPでは、MIPv6のインタフェイスはS2cインタフェイスと呼ばれている。同様に、PMIPv6のトンネルはMN2のMAGであるサービングゲートウェイからMN2のLMAであるPGW2まで及んでいる。
例えば、MN1及びMN2のHPLMNが1つの大陸(欧州)に位置しており、両方のノードが現在、別の大陸(米国)にローミングしているものとする。この場合、2つのノード間で交換されるデータパケットは極めて長距離を横断し、その結果、長い遅延が生じ、ルーティングは非効率になる。
図2を参照して上述したように、MIPv6はルート最適化を行うメカニズムである。MN1がMIPv6に利用しているので、MIPv6用のRR/ROを実行できる。このようにして最適化されたルートが図5に示されている。しかし、MN2はそのHPLMNに位置していないので、MIPv6のRO手順の完了は、データトラフィックがHPLMN1を流れることを回避するだけであるが、トラフィックは依然としてVPLMN(米国)からHPLMN2(欧州)に、かつ、VPLMN(米国)に戻って流れる。このことから明らかなように、データルートは最適ではなく、依然として長い遅延があり、非効率なルーティングである。
さらに、MN2はMIPv6のルート最適化に関与する必要があり、ひいてはMIPv6をサポートする必要がある。また、MN2はモビリティマネジメントのために既にPMIPv6を使用しているので、MN2はHPLMN2内のHAを経た迂回を避けるためにMIPv6のROを実行できないことを留意することが望ましい。したがって、最適なルートを得るには、別方向でのRR/RO手順も実行できるために、MN2がMIPv6を利用することが必要である。
モバイルノードが在圏ネットワーク(PLMN)にアタッチされる場合は、データトラフィックの転送に関して2つの動作モード、すなわちホーム経由のトラフィック(home-routed traffic)及びローカルブレークアウトが可能である。ホーム経由のトラフィックとは、MNがそのHPLMNからIP構成を取得し、すべてのトラフィックが常にVPLMNを経てMNとHPLMNとの間を経由することを意味する。ホーム経由のトラフィックモードは、VPLMNとHPLMNとの間に(前記でS8インタフェイスとして示されている)PMIPトンネルを確立することによって実施される。LBOの場合は、MNはVPLMNからIP構成を取得し、データトラフィックはHPLMNを経由せず、MNからVPLMNを経て通信相手ノードに直接ルーティングされる。アタッチ手順中に、MNは特定のアクセスポイント名に接続することを要求するので(PDN接続とも呼ばれる)、この動作モードはMNによって開始される。要求されたAPNのPGWがHPLM内に位置する場合は、MNのPDN接続はホーム経由(home-routed)と呼ばれる。要求されたAPNに対応するPGWがVPLMN内に位置する場合は、MNのPDN接続はLBOと呼ばれる。
MN1がLBOを使用する場合、最適なデータルートが図5に示されており、これはMN1によって実行されるMIPv6のROと事実上同一である。この場合もルートは最適ではない。
さらに、MN2はLBO動作モードを使用してもよく、それはまさに図4に点線で示す最適なデータルートを生じるであろう。両方のノードとも、VPLMN内に位置する新たなPGWへの新たなPDN接続を確立するであろう。例えば、AGWがVPLMNのコアネットワーク内に位置し、対応するPGWの機能を提供すれば、MN1はこれをLBO用のローカルPGWとして使用できる。同様に、SGWがPGWの機能を提供すれば、MN2はこれをLBO用のVPLMN内のローカルPGWとして使用できる。
しかし、LBO動作には重大な欠点がある。
例えば、モバイルノードはトポロジー的に正しい新たなIPアドレスをVPLMN内に構成し、これらのIPアドレスはモバイルノード間の通信用に使用されるので、新たなローカルPGWへの接続の確立はデータ通信の開始前に完了しなければならない。したがって、MN2のホームアドレスを用いて既に確立されたセッションは、前記アドレス変更により中断される。その結果、データ通信の開始前にLBOを実行する必要があり、それにはモバイルノード間の同期化、及びHPLMN間の調整さえも必要になる。さらに、LBOのセットアップは時間とシグナリングを要するプロセスである。実際の通信中、又は通信前のどの時間でも実行可能なルート最適化ができれば有利であろう。
データ通信の開始前にLBOをセットアップするためにモバイルノード間の同期化を行う一例は、例えばセッション開始プロトコル(SIP)などのアプリケーション層プロトコルなどの高位層プロトコルを用いることである。アプリケーション層プロトコルとネットワーク層プロトコルとの同期化には、両方のモバイルノードで特殊な実施メカニズムが必要であり、その結果、後方互換性が失われる。また、アプリケーション層シグナリングを使用することの別の欠点は、アプリケーション層シグナリングが例えばSIPベースのアプリケーションのみを必要とされるために、ROパスは、これらの種類のアプリケーションのみでセットアップできることである。
さらに、ルート最適化がなされたパスをセットアップするためにシグナリング負荷と遅延とが低減されるルート最適化が有利であろう。
したがって、従来技術の前記問題点に照らして、本発明の目的の1つは、通信ノードの少なくとも1つが現在の外部ネットワーク内に位置する2つの通信ノード間のデータパスを最適化する、改良された方法、すなわちローミングを提供することにある。
前記の目的の少なくとも1つは、独立クレームの主題によって解決される。本発明の有利な実施形態は従属クレームの主題である。
本発明の第1の実施形態によれば、通信システムの第1の通信ノードと第2の通信ノードとの間でデータパケットが交換されるデータパスを最適化する方法が提供される。少なくとも第1の通信ノードは外部ネットワーク内に位置している。第1の通信ノードは外部ネットワーク内の第1の通信ノードのマネジメントエンティティに対して、第2の通信ノードの識別情報を含むローカル接続要求を送信する。受信したローカル接続要求に応答して、外部ネットワーク内のマネジメントエンティティは第2の通信ノードの識別情報に基づいて外部ネットワーク内のローカルデータゲートウェイを決定する。このローカルゲートウェイは、外部ネットワーク内の第2の通信ノードのゲートウェイ、又は外部ネットワーク内の第1の通信ノードのゲートウェイであることが決定される。第1及び第2の通信ノード間のすべてのデータパケットはこのローカルデータゲートウェイを介して交換される。
本発明の有利な実施形態によれば、ローカルデータゲートウェイは第2の通信ノードにより使用されるゲートウェイであり、第1の通信ノードが外部ネットワーク内にアタッチされる無線制御エンティティとローカルデータゲートウェイとの間にトンネルが確立される。データパケットは確立されたトンネルを経て、無線制御エンティティとローカルデータゲートウェイとの間に転送される。
本発明のさらに別の実施形態に関しては、外部ネットワーク内のマネジメントエンティティが無線制御エンティティ及びローカルデータゲートウェイに対して双方の間にトンネルを確立するように指示する。
本発明の別の実施形態では、外部ネットワーク内のマネジメントエンティティが、第2の通信ノードの識別情報に基づいて、第2の通信ノードによって使用されるゲートウェイを決定する。
本発明の有利な実施形態によれば、第2の通信ノードの識別情報がIP(インターネットプロトコル)アドレスであり、外部ネットワーク内のマネジメントエンティティが第2の通信ノードによって使用されるゲートウェイを第2の通信ノードのIPアドレスのIPプレフィックスから推測する。
本発明のさらなる実施形態を参照すると、外部ネットワーク内のマネジメントエンティティは、第2の通信ノードのマネジメントエンティティに要求を送信し、それに応答して、第2の通信ノードにより使用されるゲートウェイの情報を第1の通信ノードのマネジメントエンティティに送信する。
本発明の別の実施形態は、第1の通信ノードが第2の通信ノードにゲートウェイ検出メッセージを送信することを提案している。第1の通信ノードと第2の通信ノード間のデータパス上の傍受エンティティがゲートウェイ検出メッセージを傍受し、それに応答して、第2の通信ノードが使用してゲートウェイに関する情報を含むゲートウェイ検出応答メッセージを第1の通信ノードに送信する。第1の通信ノードから第1の通信ノードのマネジメントエンティティに送信されるローカルゲートウェイ要求が、第2の通信ノードのゲートウェイに関する受信した情報を含む。第2の通信ノードによって使用されるゲートウェイが、ローカルゲートウェイ要求で受信した第2の通信ノードによって使用されるゲートウェイの情報に基づいてマネジメントエンティティによって決定される。
本発明のさらなる実施形態では、第2の通信ノードから発信され、かつ、第1の通信ノードのホームアドレスを宛先とするデータパケットを、確立されたトンネルを使用してローカルデータゲートウェイから無線制御エンティティに転送するために、第1の通信ノードのホームアドレスを無線制御エンティティへの確立されたトンネルと関連付けるルーティングエントリがローカルデータゲートウェイ内で定義される。
本発明のさらなる実施形態によれば、ローカルデータゲートウェイは第2の通信ノードによって使用されるゲートウェイであり、第1の通信ノードのサービングゲートウェイは、マネジメントエンティティによって第1の通信ノードのローカルサービングゲートウェイであることが決定される。外部ネットワーク内の第1の通信ノードのサービングゲートウェイとローカルゲートウェイとの間にトンネルが確立される。データパケットが、確立されたトンネルを経て、サービングゲートウェイとローカルデータゲートウェイとの間に転送される。第1の通信ノードが外部ネットワーク内にアタッチされる無線制御エンティティと第1の通信ノードのサービングゲートウェイとの間に第2のトンネルが確立され、データパケットが、確立された第2のトンネルを経て、無線制御エンティティと第1の通信ノードのサービングゲートウェイとの間に転送される。
本発明の別の実施形態では、第1の通信ノードのマネジメントエンティティはサービングゲートウェイに対してローカルデータゲートウェイとのトンネルを確立するように指示し、かつ、サービングゲートウェイ及び無線制御エンティティに対して第2のトンネルを確立するように指示する。
本発明の有利な実施形態に関しては、第2の通信ノードから発信され、かつ、第1の通信ノードのホームアドレスを宛先とするデータパケットを、確立されたトンネルを使用してローカルデータゲートウェイからサービングゲートウェイに転送するために、第1の通信ノードのホームアドレスをサービングゲートウェイへの確立されたトンネルと関連付けるルーティングエントリが、ローカルデータゲートウェイ内で定義される。第1の通信ノードのホームアドレスを無線制御エンティティへの確立された第2のトンネルと関連付ける別のルーティングエントリが第1の通信ノードのサービングゲートウェイ内で定義される。
第2の通信ノードのホームアドレスをローカルデータゲートウェイへの確立されたトンネルと関連付ける別のルーティングエントリが、第1の通信ノードのサービングゲートウェイ内で定義される。第2の通信ノードのホームアドレスを第1の通信ノードのサービングゲートウェイへの確立された第2トンネルと関連付ける別のルーティングエントリが、無線制御エンティティ内で定義される。
本発明の別の実施形態によれば、第1の通信ノードが中継ノードにアタッチされ、第1の通信ノードから及び第1の通信ノードへのデータパケットが、中継ノードと、第1の通信ノードのサービングゲートウェイである中継ノードゲートウェイとの間でトンネリングされる。ローカルデータゲートウェイは第2の通信ノードによって使用されるゲートウェイであることが決定される。中継ノードゲートウェイは、第1の通信ノードのマネジメントエンティティによって、ローカルデータゲートウェイへのトンネルを確立するように指示される。
本発明のさらなる実施形態では、第1の通信ノード又は中継ノードが第1の通信ノードのマネジメントエンティティに、中継ノードにアタッチされる第1の通信ノードに関する情報を送信する。したがって、中継ノードゲートウェイは、受信した中継ノードに関する情報に基づいて第1の通信ノードのマネジメントエンティティによって決定される。
本発明の別の実施形態によれば、マネジメントエンティティの情報伝達には、第1の通信ノードのマネジメントエンティティに中継ノードのアクセスポイント名を送信することが含まれる。さらに、中継ノードゲートウェイの決定は中継ノードのアクセスポイント名に基づいて行われる。
本発明のさらなる実施形態では、ローカルデータゲートウェイは、外部ネットワーク内の第1の通信ノードの位置に関する情報に基づいて、外部ネットワーク内の第1の通信ノードによって使用されるゲートウェイであることが決定される。第1の通信ノードのマネジメントエンティティは、第2の通信ノードの識別情報に基づいて、外部ネットワーク内の第2の通信ノードのゲートウェイを決定する。データパケットをローカルデータゲートウェイと第2の通信ノードのゲートウェイの間に転送するため、外部ネットワーク内の第2の通信ノードのゲートウェイとローカルデータゲートウェイの間にトンネルが確立される。
本発明は、通信ノードが外部ネットワーク内に位置する通信システム内の第2の通信ノードとデータパケットを交換する通信ノードを提供する。通信ノードの送信機が、ローカル接続要求を外部ネットワーク内の通信ノードのマネジメントエンティティに送信し、そのローカル接続要求は第2の通信ノードの識別情報を含む。外部ネットワーク内のローカルデータゲートウェイが第2の通信ノードのゲートウェイであるか、又は外部ネットワーク内の第1の通信ノードのゲートウェイであるかを決定するため、ローカル接続要求及びこれに含まれる第2の通信ノードの識別情報がマネジメントエンティティによって使用される。
本発明の有利な実施形態によれば、通信ノードは、ホームIPアドレスを有し、さらに、ローカルデータゲートウェイ又はローカルデータゲートウェイに関するマネジメントエンティティのIP アドレス情報を受信する受信機を備えている。通信ノードのプロセッサは、ローカルデータゲートウェイに関するIPアドレス情報に基づいて、通信ノードのための新たなローカルIPアドレスを構成する。送信機は、ホームIPアドレスを用いて第2の通信ノードにデータパケットを送信し、そして、通信ノードのローカルIPアドレスを用いて別の通信ノードにデータパケットを送信する。
本発明の別の実施形態によれば、マネジメントエンティティに送信されるローカル接続要求には、通信ノードがアタッチされるセルのセル識別子がさらに含まれる。
本発明の追加の実施形態では、通信ノードが中継ノードにアタッチされ、通信ノードへ及び通信ノードからのデータパケットは中継ノードと中継ノードゲートウェイ間でトンネリングされる。送信機は、中継ノードにアタッチされる通信ノードに関する情報を通信ノードのマネジメントエンティティに送信する。
本発明はさらに、通信システム内の第1の通信ノードと第2の通信ノードの間でデータパケットが交換されるデータパスを最適化する方法を提供する。少なくとも第1の通信ノードは外部ネットワーク内に位置している。第1の通信ノードは、データパケットを第2の通信ノードと交換するために外部ネットワーク内のローカルデータゲートウェイからのローカルアドレスを使用する。第2の通信ノードが現在アタッチされているネットワーク内のルート最適化エージェントが決定される。第1の通信ノードとルート最適化エージェントとの間にIPトンネルが確立される。これは、第1の通信ノードのローカルアドレスに基づいて、第1の通信ノードとルート最適化エージェントの間にセキュリティアソシエーションを確立することを含む。すべてのデータパケットが、第1の通信ノードのローカルアドレスを使用して、ルート最適化エージェントを経た上で、確立されたIPトンネルを介して、第1の通信ノードと第2の通信ノード間で交換される。
本発明のさらなる実施形態では、ルート最適化エージェントは第2の通信ノードのゲートウェイであり、ルート最適化エージェントを決定は、外部ネットワーク内の第2の通信ノードのゲートウェイを要求するために、ドメイン名システムを使用することを含む。
本発明の1つの態様によれば、2つの通信ノードがデータパスに沿って現在通信しており、第1の通信ノードは、第1の通信ノードがそのホームネットワーク内には現在ないものと想定して、データパケットをモバイルノードと交換するために、そのホームアドレスを使用する。第1の通信ノードが実際にそのホームネットワーク内にある場合は、「ホームアドレス」という用語は、第1の通信ノードがそのホームネットワーク内で使用するIPアドレスであるものと理解される。
ルート最適化エージェントを介して新たなより短いデータパスを提供するように、第2の通信ノードのネットワーク内のルート最適化エージェントが決定される。ルート最適化エージェントは第2の通信ノードの現在のネットワーク内に位置しており、2つの通信ノード間のデータパス上にあってもなくてもよい。ルート最適化エージェントの決定は、第1の通信ノード、MN1とMN2との間のデータパス上の何らかの別のエンティティ、又は第1の通信ノードのホームエージェントと通信ノード自体のような1つ以上のエンティティによって行うことができる。
この目的を達成するため、第1の通信ノードから「ルート最適化検出メッセージ」を第2の通信ノードの方向に送信してもよい。次いで、前記ROメッセージは第2の通信ノードへのデータパス上のエンティティで傍受され、「RO応答メッセージ」の応答をトリガする。ルート最適化エージェントの決定がどのように、また、何によって行われるかに応じて、「RO応答メッセージ」は決定されたルート最適化エージェントに関する情報、又は第1の通信ノードが可能性のあるルート最適化エージェントを決定することに役立つ別の情報を既に含み得る。
ルート最適化エージェントを使用してデータパケットを第1の通信ノードと第2の通信ノードの間に転送するために、第1の通信ノードとルート最適化エージェントの間にIPトンネルを確立できる。この目的を達成するため、第1の通信ノードは、通信ノードのホームアドレスに基づき、決定されたルート最適化エージェントとセキュリティアソシエーションを確立する。言い換えると、セキュリティアソシエーションは、セキュリティアソシエーション用の新たなホームアドレスを構成するのではなく、通信ノードが既に構成したものと同じホームアドレスと確立される。通信ノードは、そのホームアドレスとの間のMIPトンネル用に同じホームアドレスを使用している可能性もある。その結果、通信ノードとルート最適化エージェントの間のIPトンネルは前記ホームアドレスに基づくものであり、言い換えれば、IPトンネル(例えばMIPトンネル)はホームアドレスによって特定される。
第2の通信ノードを宛先とするすべてのデータパケットは、IPトンネルを介してルート最適化エージェントに送信され、次いで、それはパケットを第1の通信ノードに転送する。逆に、第2の通信ノードから発信され、かつ、第1の通信ノードを宛先とするすべてのデータパケットは、ルート最適化エージェントによって傍受され、IPトンネルを介して第1の通信ノードに送信される。
ルート最適化エージェントでは、第1の通信ノードに確立されたIPトンネルと第1の通信ノードのホームアドレスとを関連付けるルーティングエントリが定義される。したがって、第1の通信ノードのホームアドレスを宛先とするデータパケットは、次のルータに同じように転送するのではなく、通常のルーティングテーブルエントリに従って、IPトンネルのインタフェイスを経て第1の通信ノードに転送される。
さらに、第1の通信ノードがそのホームネットワーク内に位置していない場合は、ルート最適化エージェントのバインディングキャッシュエントリが第1の通信ノードのホームアドレスを第1の通信ノードのローカル依存のアドレス(locally-dependent address)と関連付ける。したがって、ルート最適化エージェントは、宛先アドレスとして第1の通信ノードのローカル依存のアドレスを有するデータパケットを補足的にカプセル化することができる。
ルート最適化エージェントの別のルーティングエントリは、第2の通信ノードのアドレスを、第2の通信ノードが到達するための適切なインタフェイスと関連付ける。その結果、第1の通信ノードからIPトンネルを経てくるデータパケットは、ルート最適化エージェントによって第2の通信ノードに転送される。
第1の通信ノードは、第2の通信ノード用のデータパケットを、前記データパケットがIPトンネルを経てルート最適化エージェントに送信される前に、送信元アドレスを用いて生成し続ける。同じホームアドレスにバインドされた幾つかのIPトンネルが存在することがあるので、第1の通信ノードはデータパケットの送信元アドレスに基づいて正しいIPトンネルを選択する必要がある。同様に、ルート最適化は第2の通信ノードに対して透過的(transparent)であるため、第2の通信ノードも、そのデータパケットのターゲットアドレスとして第1の通信ノードのホームアドレスを使用し続ける。
第2の通信ノードが本発明によるルート最適化には関与しない。したがって、前記ルート最適化の適用は、第2の通信ノードがいずれかの種類のプロトコルをサポートするか否かによって左右されない。さらに、前記ルート最適化には第2の通信ノードの無線資源は使用されない。本発明のルート最適化のさらなる利点の1つは、MIPv6の場合のように一方向のみではなく、データ交換のダウンリンク及びアップリンクの方向が最適化されることである。さらに、ルート最適化のために新たなホームアドレスが確立されないので、新しいホームアドレスのために幾つかのさらなる修正を必要とせずに、進行中のセッションのデータパスは、容易に最適化できる。また、MN1の位置がMN2に明らかにされることはない。
本発明は、通信システム内の第1の通信ノードと第2の通信ノードの間でデータパケットが交換されるデータパスを最適化する方法を提供する。第1の通信ノードと第2の通信ノードのうちの少なくとも1つは外部ネットワーク内に位置しており、第1の通信ノードはクライアントベースのモビリティをサポートし、データパケットを第2の通信ノードと交換するためにそのホームネットワークからのホームアドレスを使用する。第2の通信ノードが現在アタッチされているネットワーク内でルート最適化エージェントが決定される。次いで、第1の通信ノードとルート最適化エージェントの間にIPトンネルが確立される。IPトンネルの確立には、第1の通信ノードのホームアドレスに基づく第1の通信ノードとルート最適化エージェントの間のセキュリティアソシエーションの確立が含まれる。
その結果、第1の通信ノードのホームアドレスを使用することによって、すべてのデータパケットが、ルート最適化エージェントを経て、確立されたIPトンネルを介して第1の通信ノードと第2の通信ノードの間で交換される。
本発明の有利な実施形態によれば、最適化方法は第2の通信ノードに対して透過的(transparent)である。
本発明のさらなる実施形態によれば、第1の通信ノードは、ルート最適化エージェントとセキュリティアソシエーションを確立するためのブートストラップ手順をルート最適化エージェントと共に実行するために、そのホームネットワークからのホームアドレスを用いる。
本発明の別の実施形態では、第2の通信ノードから発信され、かつ、第1の通信ノードのホームアドレスを宛先とするデータパケットを、確立されたトンネルを使用してルート最適化エージェントから第1の通信ノードのホームアドレスに転送するために、第1の通信ノードのホームアドレスを、第1の通信ノードへの確立されたIPトンネルと関連付けるルーティングエントリがルート最適化エージェント内で定義される。
本発明の有利な実施形態に関して、第1の通信ノードは第1の外部ネットワーク内に位置し、前記第1の外部ネットワーク内のローカル依存のアドレスが割り当てられる。この場合は、第1の通信ノードのホームアドレスを第1の通信ノードのローカル依存のアドレスと関連付けるバインディングキャッシュエントリが、第1の通信ノードのホームアドレスを宛先とするデータパケットを、IPトンネルを経て第1の通信ノードに送信するためにルート最適化エージェント内で定義される。
本発明の有利な実施形態によれば、IPトンネルを経て第1の通信ノードから受信され、第2の通信ノードを宛先とするデータパケットは、ルート最適化エージェント内の第2のルーティングエントリに基づいてルート最適化エージェントによって第2の通信ノードに転送される。
本発明の別の実施形態を参照すると、第1の通信ノードは第1の外部ネットワーク内に位置し、かつ、そのホームネットワーク内の第1の通信ノードの第1のホームアドレスとともに、第1の通信ノードのホームアドレスに基づいて、対応するモバイルIPセキュリティアソシエーションを含めてモバイルIPトンネルを経て接続される。さらに、送信元アドレスとしての第1の通信ノードのホームアドレスと、宛先アドレスとしての第2の通信ノードのアドレスとを有する第2の通信ノード用に、データパケットは第1の通信ノードによって生成される。次いで、前記データパケットは、第2の通信ノードのアドレスであるデータパケットの宛先アドレスに基づいて、第1の通信ノードによりIPトンネルを経てルート最適化エージェントに送信される。したがって、別の通信ノード用の別のデータパケットは、第2の通信ノードのアドレスではない宛先アドレスに基づいて、第1の通信ノードによりモバイルIPトンネルを経て第1の通信ノードの第1のホームエージェントに送信される。
本発明のさらなる実施形態では、第2の通信ノードは第2の外部ネットワーク内に位置し、第2の通信ノードのホームネットワーク内のモビリティアンカを介してネットワークベースのモビリティを使用する。第2の外部ネットワーク内のゲートウェイが第2の通信ノードからのすべてのデータパケットを受信し、ゲートウェイと第2の通信ノードのホームエージェント間でデータパケットを交換するため、前記ゲートウェイとモビリティアンカの間のネットワークベースのモビリティトンネルが確立される。さらに、ゲートウェイはルート最適化エージェントであることが決定される。
本発明の有利な実施形態によれば、ルート最適化エージェントを決定するステップは、第2の通信ノードの現在のネットワーク内の可能性のあるルート最適化エージェントの候補を決定することを含んでいる。また、可能性のあるルート最適化エージェントの候補の中から、ルート最適化エージェントの候補は、第1の通信ノードと第2の通信ノードの間のデータパス上にあるルート最適化エージェントとして選択される。
本発明の別の実施形態に関して、ルート最適化エージェントを決定するステップは、第1の通信ノードによってルート最適化検出メッセージを第2の通信ノードに送信することを含んでいる。ルート最適化検出メッセージが、第1の通信ノードと第2の通信ノードの間のデータパス上の傍受エンティティ(intercepting entity)によって傍受され、それは、第2の通信ノードが現在アタッチされているネットワーク内の可能性のあるルート最適化エージェントの候補を決定する。傍受エンティティはルート最適化応答メッセージを第1の通信エンティティに送信しており、それにはオプションとして可能性のあるルート最適化エージェントの候補に関する情報、及び第2の通信ノードが現在アタッチされているネットワークに関する情報が含まれる。
本発明の別の実施形態によれば、決定されたルート最適化エージェントは第1の通信ノードと第2の通信ノードの間のデータパス上にはない。この場合には、第1の通信ノードと第2の通信ノードの間のデータパス上の第2の通信ノードの第1のルータであるエンティティと、第2の通信ノードが現在アタッチされているネットワーク内にあるエンティティとの間に、かつ、ルート最適化エージェントの間に、第2のIPトンネルが確立される。したがって、第2の通信ノードから発信され、かつ、第1の通信ノードを宛先とするすべてのデータパケットが、第2のIPトンネルを経てルート最適化エージェントに転送される。
本発明の1つの実施形態はさらに、データパケットを通信システム内の第2の通信ノードと交換する通信ノードを備えている。通信ノードと第2の通信ノードのうちの少なくとも1つは外部ネットワーク内に位置しており、通信ノードはクライアントベースのモビリティをサポートし、かつ、データパケットを第2の通信ノードと交換するためにそのホームネットワークからのホームアドレスを使用する。さらに、通信ノードと第2の通信ノードとの間のデータパスを最適化するため、第2の通信ノードが現在アタッチされているネットワーク内でルート最適化エージェントが決定される。通信ノードのプロセッサは、決定されたルート最適化エージェントとIPトンネルを確立する、それは、通信ノードのホームアドレスに基づいてルート最適化エージェントとセキュリティアソシエーションを確立することを含む。通信ノードの受信機及び送信機は、通信ノードのホームアドレスを使用することによって、通信ノードと第2の通信ノードとの間で、すべてのデータパケットを、ルート最適化エージェントを経て、確立されたIPトンネルを介して交換する。
本発明のさらなる実施形態では、通信ノードのプロセッサが第2の通信ノードの現在のネットワーク内のルート最適化エージェントを決定する。
本発明の別の実施形態によれば、プロセッサは、ルート最適化エージェントとセキュリティアソシエーションを確立するために、ルート最適化エージェントとブートストラップ手順を実行する、通信ノードのホームアドレスを使用する。
本発明の有利な実施形態に関しては、通信ノードは、第1の外部ネットワーク内に位置し、かつ、モバイルIPトンネルを介してそのホームネットワーク内の通信ノードの第1のホームエージェントに接続される。ルート最適化エージェントへのIPトンネルとモバイルIPトンネルの双方、及びモバイルIPトンネルのモバイルIPセキュリティアソシエーションは、第1の通信ノードのホームアドレスに基づくものである。
本発明のさらなる実施形態によれば、通信ノードのプロセッサは、送信元アドレスとしての通信ノードのホームアドレスと、宛先アドレスとして第2の通信ノードのアドレスとを有する第2の通信ノード用のデータパケットを生成する。次いで、通信ノードの送信機が、第2の通信ノードのアドレスであるデータパケットの宛先アドレスに基づいて、IPトンネルを経て、ルート最適化エージェントに前記データパケットを送信する。逆に、送信機は、第2の通信ノードのアドレスではないデータパケットのアドレスに基づいて、IPトンネルを経て、通信ノードの第1のホームエージェントに別の通信ノード用の別のデータパケットを送信する。
本発明のさらなる実施形態では、通信ノードの受信機は、少なくともルート最適化応答メッセージ内の可能性のあるルート最適化エージェントの候補に関する情報を受信する。プロセッサは、可能性のあるルート最適化エージェントの候補の中から第1の通信ノードと第2の通信ノードの間のデータパス上にあるルート最適化エージェントの候補をルート最適化エージェントとして選択する。オプションとして、プロセッサはさらに、ルート最適化エージェントとセキュリティアソシエーションを確立することが可能か否かを決定してもよい。
本発明のより有利な実施形態に関して、通信ノードの送信機は、第2の通信ノードのネットワークに関する情報と、第2の通信ノードの現在のネットワーク内のルート最適化エージェントの候補に関するオプション情報とを要求するため、ルート最適化検出メッセージを第2の通信ノードに送信する。
次に本発明の別の実施形態を参照すると、通信ノードの受信機は、第2の通信ノードの現在のネットワークに関する情報と、ルート最適化エージェントの候補に関するオプション情報を含むルート最適化応答メッセージを受信する。通信ノードのプロセッサは、前記受信した情報に基づいてルート最適化エージェントを決定する。
本発明の有利な実施形態によれば、決定されたルート最適化エージェントは通信ノードと第2の通信ノードの間のデータパス上にない。この場合は、通信ノードの送信機は、通信ノードと第2の通信ノード間のデータパス上の第2の通信ノードの第1のルータであるエンティティと、第2の通信ノードの現在のネットワーク内にあるエンティティとの間に、かつ、ルート最適化エージェント間に第2のIPトンネルを確立するため、トンネル確立メッセージを第2の通信ノードに送信する。したがって、第2の通信ノードから発信され、かつ、通信ノードを宛先とするすべてのデータパケットは、第2のIPトンネルを経てルート最適化エージェントに転送される。
本発明の1つの実施形態は、通信システム内の第1の通信ノードと第2の通信ノードの間でデータパケットが交換されるデータパスを最適化するルート最適化エージェントを提供する。第1の通信ノードと第2の通信ノードのうちの少なくとも1つは、外部ネットワーク内に位置しており、第1の通信ノードは、クライアントベースのモビリティをサポートし、かつ、データパケットを第2の通信ノードと交換するためにそのホームネットワークからのホームアドレスを使用する。ルート最適化エージェントは、第2の通信ノードが現在アタッチされているネットワーク内に位置する。ルート最適化エージェントのプロセッサは、IPトンネルを第1の通信ノードと確立する、それは、第1の通信ノードのホームアドレスに基づいて第1の通信ノードとセキュリティアソシエーションを確立することを含む。ルート最適化エージェントの受信機及び送信機は、第1の通信ノードのホームアドレスを使用することによって、第1の通信ノードと第2の通信ノードとの間で、すべてのデータパケットを、ルート最適化エージェントを経て、確立されたIPトンネルを介して交換する。
本発明の別の実施形態によれば、第1の通信ノードのホームアドレスは、第1の通信ノードのホームネットワークに割り当てられ、そして、ルート最適化エージェントの観点からトポロジー的に正しくない。さらに、ルート最適化エージェントのプロセッサは、第1の通信ノードとセキュリティアソシエーションを確立するために、第1の通信ノードのトポロジー的に正しくないホームアドレスを使用する。
本発明の別の実施形態では、ルート最適化エージェントのプロセッサは、第1の通信ノードのホームアドレスを第1の通信ノードへの確立されたIPトンネルと関連付けるルート最適化エージェント内のルーティングエントリを定義する。その結果、第2の通信ノードから受信され、第1の通信ノードのホームアドレスを宛先とするデータパケットは、確立されたIPトンネルを使用して、ルート最適化エージェントから第1の通信ノードに転送される。
本発明の別のより有利な実施形態に関して、第1の通信ノードは、第1の外部ネットワーク内にあり、かつ、前記第1の外部ネットワーク内のローカル依存のアドレスを割り当てられる。この場合は、ルート最適化エージェントのプロセッサは、ルート最適化エージェント内で、第1の通信ノードを第1の通信ノードのローカル依存のアドレスと関連付けるバインディングキャッシュエントリを定義する。このようにして、第1の通信ノードのホームアドレスを宛先とするデータパケットはIPトンネルを経て第1の通信ノードに送信される。
本発明の異なる実施形態を参照すると、ルート最適化エージェントの送信機は、第1の通信ノードからIPトンネルを経て受信して第2の通信ノードを宛先とするデータパケットを、ルート最適化エージェント内の第2のルーティングエントリに基づいて第2の通信ノードに転送する。
本発明のさらなる実施形態では、第2の通信ノードは、第2の外部ネットワーク内に位置し、かつ、第2の通信ノードのホームネットワーク内のモビリティアンカを介してネットワークベースのモビリティを利用する。ネットワークベースのモビリティのモバイルアクセスゲートウェイは、第2の通信ノードからのすべてのデータパケットを受信し、ルート最適化エージェントはモバイルアクセスゲートウェイ内に位置している。
本発明の別の実施形態によれば、ルート最適化エージェントは、第1の通信ノードと第2の通信ノード間のデータパス上に位置していない。この場合は、ルート最適化エージェントのプロセッサは、第1の通信ノードと第2の通信ノードの間のデータパス上の第2の通信ノードの第1のルータであるエンティティと、第2の通信ノードの現在のネットワーク内のエンティティとの間に、かつ、ルート最適化エージェント間に、第2のIPトンネルを確立する。したがって、第1の通信ノードを宛先とする第2の通信ノードからすべてのデータパケットは、第2のIPトンネルを経てルート最適化エージェントに転送される。
本発明の有利な実施形態では、ルート最適化エージェントの受信機は、第1の通信ノードからのルート最適化検出メッセージを受信する。ルート最適検出メッセージに応答して、ルート最適化エージェントのプロセッサは、第2の通信ノードの現在のネットワークに関する情報、及びオプションとして可能性のあるルート最適化エージェントの候補に関する情報を収集する。次いで、送信機は、収集された情報を含むルート最適化応答メッセージを第1の通信ノードに送信できる。
本発明の1つの実施形態は、ホームエージェント機能を有するパケットデータネットワークゲートウェイを備えている、そこにおいて、パケットデータネットワークゲートウェイは、データパケットが第1の通信ノードと第2の通信ノードの間で交換されるデータパス上に位置する。さらに、パケットデータゲートウェイは、第1の通信ノードと第2の通信ノードのうちの1つのためにモビリティメカニズムに関与し、かつ、第1の通信ノードと第2の通信ノードの間のデータパスを最適化するために可能性のあるルート最適化エージェントの候補に関する情報を要求するルート最適化検出メッセージを第1の通信ノードから受信する受信機を備えている。パケットデータゲートウェイのプロセッサは、第2の通信ノードの現在のネットワーク内のルート最適化エージェントを決定する。次いで、パケットデータゲートウェイの送信機は、決定されたルート最適化エージェントに関する情報を含むルート最適化応答メッセージを第1の通信ノードに送信する。
以下に、添付図面を参照して本発明の実施形態をより詳細に説明する。図中、同様の又は対応する詳細部分には同じ参照番号が付されている。
MIPv6によるモバイルノードと通信相手ノード間の通信用の双方向トンネリングの使用を示す MIPv6によるモバイルノードと通信相手ノード間の通信用のルート最適化の使用を示す LTEシステムの高レベルアーキテクチャを図示する データパケットがMN1とMN2の間の長距離データルートを経て交換される例示的シナリオを図示し、最適なデータルートも図示されている 図4の例示的シナリオ、及び通常のMIPv6のROがMN1によって実行される場合の最適なデータルートを図示する 図4の例示的シナリオを図示するが、本発明の1つの実施形態により最適化されたデータパスと、前記実施形態を実施するための対応する幾つかのメッセージが示されている 本発明の1つの実施形態によるルート最適化のためのシグナリング、及びこれによって最適化されたデータパスを経たデータ交換の結果を示すシグナリング図 本発明の異なる実施形態が利用される場合、特にルート最適化エージェントがMN1とMN2の間の元のデータパス上にない場合の図4のネットワーク配備を示す 本発明の幾つかの実施形態によるMN1によって実行される幾つかのステップを示すフローチャートを示す MN1がそのホームネットワーク HPLMN1内にあり、最適化されたデータパスが本発明の1つの実施形態により確立される別のネットワーク配備を示す MN1が3GPPネットワークにアタッチされ、本発明のさらなる実施形態により最適化されたデータパスが確立される別のネットワーク配備を示す 図11と同様であるが、本発明の実施形態によりL−PGWが決定されたネットワーク配備を示す 本発明のさらなる実施形態により確立される最適化されたデータパスが、MN1とMN2のSGW間の追加のトンネル、及びMN1のeNB1とMN1のSGW1間のトンネルによって構成されるさらなるネットワーク配備を示す MN1がRNを介してネットワークにアタッチされ、最適化されたデータパスが本発明のさらなる実施形態により確立される別のネットワーク配備を示す L−SGW及びL−PGWの決定が図14の場合と異なる、図14と同類のネットワーク配備を示す L−SGW及びL−PGWの決定が図14及び図15の決定とは異なる、図14及び図15と同類のネットワーク配備を示す
定義
以下に、本明細書で頻繁に用いられる幾つかの用語の定義を記載する。
モバイルノードは、通信ネットワーク内の物理的エンティティである。1つのノードが幾つかの機能的エンティティを有することができる。機能エンティティとは、ノード又はネットワークの別の機能エンティティに所定の機能のセットを実行及び/又は提供するソフトウェア又はハードウェアのことである。ノードは、ノードが通信可能な通信設備又は媒体にノードをアタッチする1つ又は複数のインタフェイスを有することができる。同様に、ネットワークエンティティは、別の機能的エンティティ又は通信相手ノードと通信できる通信設備又は媒体に機能的エンティティをアタッチする論理インタフェイスを有することができる。
通信ノードは、携帯電話やラップトップなどのモバイルノード、又はサーバなどの固定ノードのいずれかであってよい。
IPトンネルは、対応する送信元及び宛先アドレスとしてIPトンネルの終端ポイントを有するIPヘッダを有するデータパケットの補足的なカプセル化であると定義できる。
ルート最適化エージェント(ROA)は、第2の通信ノードのネットワーク内のエンティティ、又はエンティティ内の機能であると理解できる。これは第1の通信ノードと第2の通信ノード間のデータパス上に位置してもしなくてもよい。データパス上のエンティティと前記データパスの外部のルート最適化エージェントとの間に追加のトンネルが不要であるため、ROAはデータパス上にある方がより好ましい。ルート最適化エージェントは、MIPv6と同様の能力を包含していてもよく、かつ、ルート最適化エージェント内のトポロジー的に正しくないモバイルノードによって要求されるホームアドレスに基づいてIPトンネルの確立を受け入れるなどのさらなる機能を補足的にサポートする必要がある。例えば、ルート最適化エージェントは、SGW内に位置してもよく、また、オプションとしてPGWの機能をサポートしてもよい(PGWとSGWとの共存)。
セキュリティアソシエーション(SA)は、安全な通信をサポートするために、2つのノード又は機能エンティティが共有するセキュリティ情報のセットであると定義できる。例えば、セキュリティアソシエーションは、データ暗号化アルゴリズム、(1つ又は複数の)データ暗号化鍵(例えば秘密鍵又は公開鍵/秘密鍵のペア、(1つ又は複数の)初期化ベクトル、デジタル証明など)を含み得る。一般的には、外部ネットワーク内のモバイルノードとホームネットワーク内のホームエージェントの間にセキュリティアソシエーションが提供される。したがって、モバイルノードが外部ネットワークにアタッチされても、ホームエージェントとモバイルノード間の暗号化/認証/認可された通信が(例えば安全なトンネル)が確保されてもよい。セキュリティアソシエーションは一般的に、終端ポイントのアドレス、すなわちホームエージェントのアドレス及びモバイルノードの1つのアドレス(一般的にはホームアドレス)にバインドされる。
パケットデータネットワーク(PDN)接続は、特定のアクセスポイント名(APN)によって特定される、(1つのIPv4アドレス及び/又は1つのIPv6プレフィックスによって表される)MNとPDN間のアソシエーション(論理接続)であると定義できる。通常は、これは、その特定のAPNに割り当てられるPDNゲートウェイ(PGW)とMNの間のアソシエーションである。
以下に、本発明の1つの特定の実施形態を詳細に説明する。説明は本発明を限定するものとしてではなく、本発明の基本原理の例として理解されるべきである。クレームに記載の本発明の基本原理は別のシナリオにも、本明細書には明確に記載しない方法で応用できることを当業者は認識されるべきである。
この特定の実施形態では、2つの通信モードがモバイルノードであり、それらのホームネットワーク内にはなく、外部ネットワーク内にあるものと想定する。さらに、第1のモバイルノード、MN1は、現在位置しているVPLMN内のMIPv6などのクライアントベースのモビリティをサポート、かつ、使用するものと想定されている。第2のモバイルノード、MN2は、同じVPLMN内のPMIPなどのネットワークベースのモビリティメカニズムを使用する。
この例示的シナリオは、図4についての導入部で既に説明した通りである。MN1は、アクセスポイント(AP)を通してVPLMNにアタッチされ、かつ、MN1のホームネットワークHPLMN1内にMIPv6のホームエージェントPDN−GW1(PGW1)を有している。MN1は、データパケットを別のモバイルノードと交換するために、そのホームエージェントPGW1によって割り当てられたHoAを使用する。したがって、着信・送信されたすべてのデータパケットはホームエージェントPGW1を経て送信される。アクセスゲートウェイ(AGW)は、モバイルノードの認証及びIP構成に関与できる非3GPPアクセスネットワーク内に通常は位置するエンティティである。MNPv6に従って、MIPトンネルが、MN1とHPLMN1内のホームエージェントPGW1との間に確立される。MN2は、3GPPアクセスと、サービングゲートウェイを介してそのホームネットワークHPLMN2及びそのローカルモビリティエージェント(LMA)であるPGW2とにアタッチされる。PMIPに従って、PMIPトンネルは、MN2のMAGであるサービングゲートウェイ(SGW)と、データパケットが送信されるMN2のLMAであるPGW2との間に存在する。
MIPトンネル及びPMIPトンネルは、それぞれのMIPの一部、及びPMIPモビリティプロトコルとして既に確立されている。本発明によれば、これらのトンネルはさらに、MN1やMN2とは異なる別のモバイルノードと通信するためにも使用できる。
図6は、本発明のルート最適化によるMN1とMN2との間の最適化されたデータパスを示している。最適化されたデータパスに到達するために実行される様々なステップを以下に説明する。
MN1はルート最適化を開始し、実行するが、MN2はルート最適化を認知しないものと想定されている。本発明のROの解決策によれば、MN1が開始するルート最適化手順の完了後、ルート最適化は両方向、すなわちMN1からMN2への方向と、MN2からMN1への方向にセットアップされる。この解決策では、ルート最適化手順でMN2の関与をする必要はなく、したがって提案される解決策はあらゆるタイプの通信相手ノードに応用できる。
以下で明らかにしているように、MN1は、ホームネットワークHPLMN1で現在使用しているMIPv6などのクライアントベースのモビリティをサポートする。本発明のルート最適化を開始するMN1は通常、MN2の現在の位置を認識せず、MN2のHoAのみを認識する。したがって、MN1は、MN2がそのホームネットワークHPLMN2内にあるのか、在圏PLMN内にあるのかを認識しない。この例示的シナリオによれば、MN2はMN1と同じPLMN内に位置している。当然、MN2はその代わりに別の外部ネットワーク内にあってもよい。
MN1はまず、ROが実際に必要であるか否かを判定する。例えば、MN1がそのホームネットワークHPLMN1内にあり、MN2もそのホームネットワークHPLMN2(この場合については図示せず)内にあってもよい。この場合は、データパスが既に最適化されているのでルート最適化は必要ない。しかし、MN2がそのホームネットワーク内に位置しておらず、外部ネットワーク内に位置している場合は、MN1は、MN2のホームネットワークを経た迂回を避けるために、ルート最適化を実行することを決定する。MN2が例えばMIPv6からの別のどのルート最適化もサポートしない場合も、本発明のルート最適化を適用できる。一般に、ROが有益であるには、MN1又はMN2の少なくとも一方は外部ネットワーク内に位置していることが望ましい。
あるいは、本発明のルート最適化を実行するか否かの決定はMN1で行うのではなく、MN1のホームエージェントPGW1などのMN1とMN2との間のデータパス上の別の適切なエンティティ、又はMN2及びその現在のネットワークを認識するより可能性が高いMN2のホームエージェントPGW2で行ってもよい。この場合は、MN1は、得られた決定だけを報知され、それに従って動作する。
図6のシナリオでは、MN1は、MN2がそれ自体と同じ外部ネットワーク内に位置していることを認知し、そして、ルート最適化の実行を決定する。最初に、新たに最適化されるデータパス用に使用されるルート最適化エージェント(ROA)を決定する必要がある。ROAはMN1とMN2との間のデータパス上に有利に位置している。以下で詳細に説明するように、前記データパス上に位置しておらず、MN2と同じネットワーク内に位置しているだけのROAを使用することも可能である。この場合は、MN2から発信され、かつ、MN1を宛先とするすべてのデータパケットが、ROAによって受信され、次いで前記データパケットをMN1に転送することを確実にするため、MN2から発信されるデータパケットは、データパスからまずROAにルーティングされる必要がある。
図6の例示的実施形態では、VPLMN内のサービングゲートウェイ(SGW)がルート最適化エージェントとして選択される。ROAを選択するため、ROAを決定され、かつ、MN1であってよいエンティティは、MN2のネットワーク内の適切なROA候補に関する情報を要求する。ROAは、新たな最適化されたデータパス用の媒介として動作する特別の特性を有する必要がある。特に、例えばROAとMN1との間にトンネルを確立するため、ROAがMIPホームエージェントの能力を有することが有利である。さらに説明を続けるように、ROAによってさらなる機能がサポートされてもよい。
トンネルがROAとMN1との間に確立されるものと想定する。MIPv6用に規定されているIPsecプロトコルに基づいてROAとMN1との間にトンネルを確立するため、MN1はROAとブートストラップ手順を実行し、そこでまずROAのアドレスを取得し、次いでROAとセキュリティアソシエーションをセットアップする。セキュリティアソシエーションの確立の間、MN1はそのホームネットワークHPLMN1から既に構成されているホームアドレスを使用することを要求する。言い換えると、ROAとセキュリティアソシエーションのために、通常はROA用のトポロジー的に正しいIPアドレスである新たなホームアドレスをROAと構成するのではなく、旧来のMN1のホームアドレスが使用される。これに対応して、次いでデータパケットがROAとMN1との間で両方向にトンネルリングされてもよい。セキュリティアソシエーションの完了後、MN1は、その現在のCoA、例えば現在の非3GPPアクセスシステムで使用されるIPアドレスを登録するために、バインディング更新メッセージをROAに送る。
MN1とROAとの間のトンネルは、MIPv6内のIPsecとは異なる別のプロトコルによって生成され、保持されてもよいことを当業者は留意することが望ましい。例えば、IPsec、又はIKEv2モビリティ及びマルチホーミングプロトコル(MOBIKE)、又はクライアントとネットワークゲートウェイの間の他のトンネリングプロトコルをサポートするMIPv4がある。
いずれの場合も、データパケットをトンネリングするため、それらはROA及びMN1においてヘッダでカプセル化され、このヘッダは送信元アドレス及び宛先アドレスとしてトンネルの終端ポイントを含んでいる。オプションとして、例えばトンネルモードでIPsecプロトコルを使用する場合、元のデータパケット(トンネリングされたデータパケットのペイロード)を暗号化してもよい。
本発明の幾つかの実施形態によれば、ルート最適化はMN2に対して透過的(transparent)である、すなわちMN2はルート最適化に関与せず、かつ、認識していない。したがって、MN2は、MN1のHoAを宛先とするデータパケットを送信し続け、送信元アドレスとしてMN1のHoAを有していることをMN1からのデータパケットを待機する。そのため、MN1のHoAはさらに、MN1とMN2との間でデータパケットの交換するために使用される。
最適化されたデータパスを使用可能にするため、MN1のホームアドレスを、MN1への確立されたIPトンネルに対応するインタフェイスと関連付ける特別のルーティングエントリがROA内で定義される。したがって、宛先アドレスフィールド内のHPLMN1からのMN1のHoAを有する、MN2からROAに着信するすべてのデータパケットは前記トンネルインタフェイスに転送される。トンネリングのために外側ヘッダを構築するため、MN1のHoAをVPLMN内のMN1のCoAと関連付けるバインディングキャッシュエントリはROA内に確立される。これに対応して、外部トンネルヘッダの宛先アドレスフィールドはMN1のCoAを含み、一方、内側ヘッダの宛先アドレスフィールドはMN1のHoAを含んでいる。外側ヘッダの送信元アドレスはROAのアドレスである。MN1は、データパケットを受信し、これらを非カプセル化し、格納されたペイロードを処理する。
MN2を宛先とするMN1からのデータパケットは、確立されたルーティングエントリに従ってROAによってMN2に転送される。ROAがMN1とMN2との間の元のデータパス上にある場合は、前記ルーティングエントリは既に構成されている可能性がある。ROAが元のデータパスの外側にある場合は、バインディングキャッシュエントリと共に前記ルーティングエントリが確立される必要がある(後に説明する)。
その結果、MN1とMN2との間に最適化されたデータパスが確立され、通信モバイルノードのホームネットワークを経た迂回が回避される。
以下に、本発明の実施形態による最適化されたデータパスを確立する各々のステップをより詳細に説明する。3つの主要段階に区分できる。最初に、「ルート最適化の検出」は、データパスが最適化されるべきか否かを決定し、もしそのケースである場合は、最適化されたデータパスが進むルート最適化エージェントを決定する。次に、新たなデータパスをセットアップすることが必要である、それにはMN1とROAとの間のトンネル、及びROAとMN1内の必要なルーティングエントリ及びバインディングキャッシュエントリの確立が含まれる。最後に、本発明のルート最適化が適用されない別のモバイルノードとのデータ交換と比較してより十分に実際のデータ交換が説明される。
●「ルート最適化の検出」
ROAの検出手順の目的は以下の通りである。
1)MN1とMN2との間のルート最適化が有益であるか否かを検出する。
2)ルート最適化が有益である場合は、どのタイプのROが実行されるべきであるかを検出する。例えば、本発明のルート最適化をデフォルトで実行することができる。しかし、場合によっては、その代わりに通常のMIPv6ベースのROを実行してもよい。
3)本発明のルート最適化を実行すべき場合は、ルート最適化エージェントを発見し、そのIDを知ること。ROA−IDはIPアドレス、又はROAを一意的に特定する完全修飾ドメイン名(FQDN)であってもよい。
最初に、ROの必要性を検出するために、MN1はMN2の方向に「RO検出メッセージ」を送信する。「RO検出メッセージ」への応答はMN1に対してROが有利であるか否かを判定するための適切な情報を送る。
例えば、MN1はRO応答メッセージを通して収集された情報に基づいて、ルート最適化が有利ではないと判定してもよい。これは、MN1がそのホームネットワークHPLMN1内にあり、MN2もそのホームネットワークHPLMN2内にあることを認識する場合であろう。2つのモバイルノード間には既に最適なパスが存在するので、それ以上のルート最適化は有益ではないであろう。
本発明のルート最適化を実行すべきではあるが、通常のMIPv6のROの方がより適している場合もあり得る。例えば、MN2もMIPv6などのクライアントベースのモビリティプロトコルを使用している場合、最適化されたデータルートを達成するために2つのモバイルノードが各々MIPv6のROを実行してもよい。
MN1が、RO検出手順によって、MN1が現在位置しているVPLMNと同じVPLMNにMN2がアタッチされていることを認識する場合は、本発明のルート最適化は好適である。
「RO検出メッセージ」は異なる方法で実施可能であり、補足的に、例えば「ROA発見」メッセージの役割を果たしてもよい、すなわち、通常のMIPv6のブートストラッププロトコルで行われるような補足的なROA発見手順を実行する必要はない。このような「RO検出メッセージ」は、MN1によって、元のデータパスを経て、(存在するMIPトンネルを含む)MN2に送られることができる、すなわち、「RO検出メッセージ」はPGW1とPGW2とを横断する。一般に、MN1とMN2との間のデータパス上のどのルーティング又はモビリティアンカエンティティも「RO応答メッセージ」で「RO検出メッセージ」に応答することができる。RO応答メッセージはROA発見の情報を含み得ることに留意されたい。「RO応答メッセージ」の送信側には、ROが有益であり得るか否か、かつオプションとしてどのROを実行すべきかをMN1に指示できるRO関連情報を含んでいてもよい。この情報は、例えばMN2が現在どのPLMNにアタッチされているかに関する情報を含んでいてもよい。
「RO検出メッセージ」を実現可能な1つの方法は、僅かに修飾されたHoTi又はCoTiメッセージを使用することである。MN1が「RO検出メッセージ」として修飾されたHoTiを使用する場合は、MN1は、どのタイプのROが必要であるのか、又はROがそもそも必要であるのかをまず検出するため、CoTiメッセージの送信を遅延させてもよい。次いで、本発明のルート最適化ではなく通常のMIPv6のROを実行すべき場合は、MN1はCoTiメッセージを送信することによってリターンルータビリティ手順を継続してもよい。
「RO検出メッセージ」は、応答の送信側により破棄されてもよいが、MN2である最終宛先にさらに転送されてもよい。例えば、SGWがRO検出メッセージをさらにMN2に転送した場合は、MN2は、MN2がHoTiメッセージに応答してスタックするMIPv6を実施していないのでそのメッセージを破棄してもよく、又は、例えばメッセージを解読できるならば応答してもよい。MN1が幾つかの「RO応答メッセージ」をMN2からも受信すると、MN1はどのタイプのROを開始すべきかを決定する手段を実施することができる。
別なオプションは、「RO検出メッセージ」の目的を満たすために特別の新たなメッセージを定義することであろう。「RO検出メッセージ」の実現の別のオプションは、新たなIPヘッダのオプション、又はIPヘッダ内の「ROA」フラグなどの新たなフラグとするデータパケットであろう。そこで、MN1とMN2との間のデータパス上のルータ又はモビリティアンカはその新たなIPヘッダ又は新たなフラグに応答してMN1への応答を生成できる。
前記のように、RO検出メッセージは、MN1とMN2との間のデータパス上の様々なエンティティによって傍受されてもよい。別の可能性は、ホームエージェントの機能を有するエンティティだけが、MN2用のバインディングキャッシュエントリ(BCE)を有するMN1からのRO検出メッセージに応答することである。「RO検出メッセージ」の宛先アドレスはMN2のIPアドレスであるため、どのエンティティもそのMN2用のBCEを有しているか否かを容易に検出できる。
「RO検出メッセージ」は「発信元PLMN ID」(例えばHPLMN1)、又は、MN1のHPLMN1と、ROAが位置しているPLMNとの間にローミング合意が存在するか否かを応答エンティティがそこから推定できる「発信元ノードID」(例えば、ネットワークアクセス識別子、NAI、これは、RFC4282に記載されているようなネットワーク認証中にユーザによってそのアイデンティティ(identity)として提出されるものである)を含んでいてもよい。後に説明するように、ルート最適化エージェントがアタッチされるネットワークとMN1のネットワークとの間のローミング合意は、トンネル確立のためにROAとMN1との間にセキュリティアソシエーションを確立するために必要である。このようにして、応答エンティティは、本発明のルート最適化が可能であるか否かを判定できる。
PGW2が「RO検出メッセージ」を受信し、「HPLMN ID」に基づいてVPLMNとHPLMN1との間にローミング合意が存在しない(すなわちUE1がSGWでブートストラップすることができない)ことを検出しても、PGW2はHPLMN1とVPLMNとの間にローミング合意があることを認識しない。ネットワーク構成により、本発明のROがMN2に対して許可されない場合は、PGW2は「RO検出メッセージ」を破棄することを決定してもよい。そうではなく、ROがMN2に対して許可される場合は、PGW2には、1)PGW2が応答せず、「RO検出メッセージ」をさらに転送する、又は2)PGW2がSGW ID(及び対応するVPLMN ID)を含む「RO応答メッセージ」を送信するという2つの可能性がある。PGW2が「RO検出メッセージ」を転送し、VPLMN内のSGWがこれを受信すると、SGWはローミング合意に基づいて応答するか否かも判定できる。
PGW2又はデータパス上の何らかの別のエンティティによって、MN1とMN2との間のROが有益であり得るか否かを判定するために、RO検出メッセージはMN1の現在のVPLMN IDを含んでいてもよい。
一般に、RO検出メッセージに含まれる情報は、どのエンティティがRO及びルート最適化エージェントの必要性を判定するかによって左右される。例えば、すべての決定がMN1によってなされた場合は(MN中心の決定と呼んでもよい)、MN2、MN2の現在のネットワーク、及び可能性のあるROA候補に関するすべての情報を収集し、そして、MN1に返送される前記すべての情報を含むRO応答を生成するため、RO検出メッセージは応答エンティティ用に必要なメッセージだけを含んでいてもよい。
逆に、PGW2などのいずれかの他のエンティティが決定を行うべき場合は(PGW2中心の決定と呼んでもよい)、RO検出メッセージは、PGW2がこの決定を行うために必要なMN1のネットワーク、HPLMN1などへの情報を含むことが望ましい。
MN1が本発明の1つの実施形態によるROを実行することを決定すると、MN1はルート最適化エージェントの探索も行い得る。例えば、RO検出メッセージが応答エンティティ(例えばPGW2)によって受信されると、前記エンティティはルート最適化が実際に有効であるか否かを判定するための情報を取得するだけではない。それに加えて、応答エンティティは、MN2が現在アタッチされているネットワーク内で適切なルート最適化エージェント(1つ又は複数)を探索できる。SGWが応答エンティティである場合は、SGWは、それ自体がルート最適化エージェントの機能を実行できることを認識し、かつ、前記情報をRO応答メッセージに含める。SGWは可能性のある別のルート最適化エージェントの候補を認識できる。あるいは、RO検出メッセージを受信可能なルート最適化エージェントのすべてが、MN1に対してルート最適化エージェントとして利用可能であることを報知するために、RO応答メッセージで別個に応答してもよい。
MN1が決定を行うべきか否かに応じて、「RO応答メッセージ」に応答してMN1とMN2との間のデータパス上のエンティティによって送信される「RO応答メッセージ」は、MN2が位置するPLMN IDを含んでいてもよい。これに対応して、MN1は次いで、ROが有益であるか否か、又は、どのROを実行すべきかを決定できる。
さらに、RO応答メッセージが、PGW2などのMN1とMN2との間のデータパス上の別のエンティティによって判定されたルート最適化エージェントのアイデンティティを既に含んでいてもよい。あるいは、MN1は、1つ又は複数のRO応答メッセージを通して、MN1がルート最適化エージェントとなる1つを決定しなければならない幾つかのROA候補を受信してもよい。
RO検出メッセージが修飾されたHoTi又はCoTiメッセージであることに対応して、RO応答メッセージを修飾されたHoT又はCoTメッセージとして実施してもよい。
MN2がPMIPv6などのネットワークベースのモビリティを使用している場合、ローカルHAがMAG機能(本説明では、SGW)を実行するエンティティとコロケートされることが有利であることに留意することが重要である。また、SGWという用語は特に3GPPのLTEアーキテクチャに適用されることにも留意することが望ましい。しかし、本発明はLTEアーキテクチャに限定されるものではなく、別のネットワークに応用可能である。その場合は、SGWはMN2用の第1の(又はデフォルトの)ルータを表している。
前記の説明から、ルート最適化を行うべきか否か、また、どのルート最適化を行うべきであるかを決定する様々な方法があることが当業者には明らかであろう。本発明の前記の実施形態は単なる例示としてのものであり、異なる方法で変更し、又は組み合わせることができる。いずれの場合も、ROAとトンネリングを確立するため、MN1はROAのアイデンティティを知る必要がある。
図6及び図7には、前記例示的シナリオによるRO検出メッセージ及びRO応答メッセージの送信が示されている。以下の説明を分かりやすくするため、MN1がルート最適化の必要性、及び使用されるルート最適化エージェントに関する決定を行うものと想定される。
MN1はRO検出メッセージ(1)を送信し、これはPGW1、PGW2、及びSGWを介してMN2に転送される。上述のように、RO検出メッセージは、拡張HoTiメッセージとして実施することができる、それは、上述のようにMN1のHPLMN及び/又はVPLMNをオプションで含んでいてもよい。その結果、ホームエージェント(又はLMA)のPGW1及びPGW2は拡張されたHoTiをMN2に適正に転送するであろう。さらに、この例示的シナリオでは、SGWがRO検出メッセージを傍受するものと想定される。それに応答して、SGWは、MN2が現在アタッチされているネットワークに関する情報(VPLMN−ID)を収集し、その独自のアイデンティティを可能性のあるROA候補としてRO応答メッセージに含める。SGWは、前記情報を含む対応するRO応答メッセージ(2)をMN1に送る。この場合は、RO応答メッセージは拡張HoTメッセージとして実施される。
MN1はRO応答メッセージと格納された情報とを受信し、これによってMN2は、それ自体と同じVPLMN内に位置していることを認識する。その結果、MN1はルート最適化が有益であると判定する。VPLMN1−IDに従って、MN1はVPLMN(ROAとMN2とが位置するネットワーク)とHPLMN1との間にローミング合意があるか否かも判定できる。VPLMN内のROAとMN1との間にセキュリティアソシエーションを確立するため、ROAは、MN1のホームネットワークHPLMN1、及びHPLMN1により提供される適切な認証サービスを介してMN1を認証することが必要である。VPLMNとHPLMN1との間にローミング合意がなされていない場合は、ROAはMN1を認証することができず、したがって、MN1と前記ネットワーク内の可能性のあるROAとの間のセキュリティアソシエーションを確立することができない。この場合は、MN1は本発明のルート最適化は不可能であるものと判定できる。
ローミング合意が、決定されたROAとセキュリティアソシエーションをMN1が生成できるように、VPLMNとHPLMN1との間に確立されているものと想定されている。
MN1はMN2のネットワーク内のルート最適化エージェントを決定する必要がある。RO応答メッセージは、可能である1つ又は複数のROA候補に関する情報を含んでいてもよい。代替的に又は追加的に、MN1は、MN1とMN2との間のデータ上の異なるエンティティから幾つかのRO応答メッセージを受信していてもよい。例えば、ROAとして動作可能であり、かつ、RO検出メッセージを受信する各々のエンティティが、それ自体を可能性のあるROA候補として特定するRO応答メッセージで応答してもよい。一般に、ROA候補(1つ又は複数)は、それらがMN2のネットワーク内にある限り、データパス上にあってもなくてもよい。
データパス上のどのエンティティもROAとして動作することができないために、RO応答メッセージでMN1に対して候補を特定できない場合は、MN1は、特定のネットワーク内の可能性のあるすべてのホームエージェントを決定できる既知のホームエージェント発見メカニズムを実行してもよい。そこで、選択されたホームエージェントが本発明によるROAとなるために必要な機能をサポートするという条件で、MN1は特定されたこれらのホームエージェントの1つをルート最適化エージェントとして選択してもよい。
MN1は、MN1とMN2との間のデータパス上のROAを有利的に決定する。いずれの場合も、RO検出手順の終わりに、MN1は、MN2のネットワーク内のROAのアイデンティティを認識することが望ましい。
これまでの記載では、MN1が、その現在のVPLMN−IDを認知し、かつ、ROの必要性の判定するために、データパス上のネットワークエンティティを補助するように、それを「RO検出メッセージ」に含めるものと想定されている。しかし、MN1がVPLMN−IDを知る必要はなく、MN1がその現在のPLMN IDを如何にして認知するかの問題が生じる。可能な解決策の1つは、PGW1がVPLMN IDをRO応答メッセージに挿入することである。問題は、PGW1がMN1の現在のVPLMN IDも知らない場合に要約することができる。簡単な解決策の1つは、AGWがVPLMN IDに関する情報を挿入できるようにすることであろう。しかし、RO検出/応答メッセージはMIPトンネルにトンネリングされているので、これらはAGWに対して透過的(transparent)である。したがって、代替方法の1つは、メッセージを検査し、かつ、VPLMN IDをRO検出メッセージ内の対応するフィールドに挿入するために、MN1が、AGWに指示するために、特定のフラグを外部のMIPv6トンネルのIPヘッダにセットアップすることである。
「RO検出メッセージ」を投入することで生じる可能性がある問題の1つは、悪意があるノード(例えばMN1)がサービス不能化(DOS)攻撃を行うことがあることである。このような攻撃がなされると、MN1は何百万ものRO検出メッセージ送信することがあり、通信相手ノードがアタッチされるエンティティ(HA、PGW、SGW)の処理量が増大する可能性がある。可能な解決策は、(MN2用のモビリティアンカポイントである)PGW2がMN2の宛先アドレスに送られる「RO検出メッセージ」に、MNごとに例えば毎秒、又は毎分1msgの速度制限をかけることであろう。このようにして、「RO検出メッセージ」はHPLMN2、及びMN2がアタッチされている可能性のあるVPLMN内で溢れることがないであろう。
●最適化されたデータパスの確立
ROA−ID(それは、ROA IPアドレス又はFQDNであってよい)を使用して、MN1は、決定されたROAとIPトンネルを確立する必要があり、これにより、ROAとセキュリティアソシエーションを確立するため、かつ、必要ならばオプションとしてROAアドレスを取得する(図7を参照)ために、ブートストラップ手順を開始する。ブートストラップ手順を開始する前に、発見されたROAが、MN2が現在位置しているアクセスネットワーク内に位置することをMN1は確認してもよい。MN1はROAから新たなホームアドレスを要求せず、ROAとセキュリティアソシエーションを確立するために、HPLMN1からの既に構成されているホームアドレスを使用する。したがって、ROAと、HPLMN1に割り当てられたMN1のHoAにバインドされたMN1との間にIPsecトンネルが確立される。
宛先アドレスフィールド内にMN2のアドレスを有するデータパケットをROAへのMIPトンネルと関連付けるためには、MN1内にルーティングエントリが必要である。その理由は、ROAへのMIPトンネルが、PGW1へのMIPトンネルがバインドされている同じHoAに基づいて確立されるからである。両方のトンネルを区別するため、MN1内のルーティングエントリは宛先アドレスに基づいて、特定のデータパケットがどのMIPトンネルを経て送信されるべきかを決定する。
MN1の元のHoAはROAに対してトポロジー的に正しくないものの、ROAは、MN2からMN1に送信されるデータパケット用の前記の特別のルーティングエントリを確立する必要があり、特別のルーティングエントリは依然としてMN1のHoAを確立されたトンネルと関連付けている。より詳細には、ルータの通常のルーティング機能によれば、宛先アドレスとしてMN1のHoAを有するデータパケットは、ルーティングテーブルエントリに従って次のルータにルーティングされる、すなわち、パケットはローカル処理されないことである。通常は、宛先アドレスのIPプレフィックスがルータ/HA自体によってホストされている場合は、データパケットはルータ内のHA機能によってのみ処理される。しかしながら、この場合は、ROAに割り当てられていないMN1のHoAを宛先とするデータパケットを、IPトンネルを経てMN1に送信するために、ROAはデータパケットをそのHA機能に送ることが望ましい。したがって、ROA機能が動作するエンティティは、MN1のHoAアドレスを宛先とするパケットがルータ機能によって処理されるべきではなく、宛先アドレスのIPプレフィックスはROAによってホストされていないものの、HA機能によって処理されなければならないことを含むルーティングエントリを有しなければならない。
図7からわかるように、MNIのHoAをMN1のCoAと関連付けるために、ROA内にバインディングキャッシュエントリも確立される。したがって、HA機能は、MN1のHoAを宛先とするデータパケットをMN2からMN1にトンネリングする際にMN1のCoAを使用するためのバインディングキャッシュエントリを適用してもよい。
さらに、MN2のアドレスをMN2に到達するインタフェイスと関連付けており、MN2を宛先とするデータパケット用のさらなるルーティングエントリがSGW/ROA内に既に構成されている。このルーティングエントリは、PGW2からPMIPトンネルを経て受信され、かつ、非カプセル化されるデータパケットをさらにMN2に転送できるように、ルーティングエントリはPMIPで最初に確立された。非カプセル化の後に同じ宛先アドレスがデータパケット内にあるので、このルーティングエントリは、MN1からIPsecトンネルを経て受信されたデータパケットにも適用されてもよい。したがって、MN1から最適化されたデータパスを経て着信するデータパケット用のルーティングエントリをROA内に補足的に確立する必要はない。
前記の説明は、MN1とMN2との間のデータパス上に位置し、これにより、すべてのデータパケットをMN2から受信することをROAは想定している。しかし、既に記載したように、ROAはデータパス上にある必要はない。しかし、この場合は、MN2からMN1へのすべてのデータパケットがROAを経て送信される必要がある。それを達成するため、MN1を宛先とするすべてのデータパケットは、MN2の第1の(デフォルト)ルータとROAとの間でトンネリングされなければならない。
図8は、ROAがMN1とMN2との間のデータパス上にないが、VPLMN内のどこかにあるPGW3内に位置している場合を示している。最適化されたデータパスはROA及びMN2の第1のルータを経てSGWに向かう。ROAとしてPGW3を決定した後、MN1は、セキュリティアソシエーションを確立し、ひいてはMN1とPGW3とIPsecトンネルを確立するために、PGW3のブートストラップ手順を開始する。上述のように、ROAとセキュリティアソシエーションを生成するために、HPLMN1からの既に構成されたMN1のHoAが使用される。さらに、ROAがSGW内にある場合と同様に、MN2から送信され、MN1のHoAを宛先とするデータパケットをMN1にMIPトンネルを経て直接転送するため、MN1のHoAをMN1へのトンネルインタフェイスと関連付ける特別のルーティングエントリがROA内に確立される必要がある。MN1のHoAをMN1のCoAと関連付けるROA内のバインディングキャッシュエントリによって、ROAのHA機能はトンネルカプセル化を生成すること、すなわち、MN1のCoAを外部トンネルのヘッダの宛先アドレスとして含めることが可能になる。
既に記載したように、SGWとROAとの間にトンネルを確立する必要がある。そのために、MN1はPGW3−IDを含む特別のメッセージをMN2に送信できる。この特別のメッセージは例えば、ROメッセージでROA候補が応答されない場合、可能性のあるROAの探索に関して先述したものと同様の「HA発見メッセージ」であってよい。例えば、MN2のアンカポイント(この場合は例えばPGW2)又はSGWは、特別のメッセージを傍受し、これによってMN1が既にROAを構成済みであることを知ってもよい。したがって、PGW2は、PGW3/ROAへのPMIPトンネルを確立するために、MN2のSGWをトリガする。
PMIPトンネルはSGWとPGW3/ROAとの間にセットアップされる。ROAがSGWである場合とは異なり、MN1から送信され、MN2を宛先とするデータパケット用のルーティングエントリをROA内に構成する必要がある。このルーティングエントリはMN2のアドレスをSGWへのPMIPトンネルインタフェイスと関連付ける。これによってROAはデータパケットをSGWにトンネリングするために外部トンネルのヘッダを構築することが可能になる。
さらに、宛先アドレスとしてMN1のHoAを有するデータパケットをPGW3にPMIPトンネルを経てルーティングするため、ルーティングエントリ及びこれに対応するバインディングキャッシュエントリをSGW内に確立する必要がある。
PGW3とMN2のSGWとの間にPMIPトンネルを確立する可能性のある別の手順は、以下のとおり実行される。MN1がMn2のSGW IDを知っている場合は(例えばSGW−IDをRO応答メッセージに含めてもよい)、MN1は、MN1とPGW3/ROAとの間にMIPv6のトンネルを確立するブートストラップ手順の間に、このIDをPGW3に信号報知することができる。次いで、PGW3は、MN1とMN2との間のデータトラフィック用のPMIPトンネルの確立をSGW2とPGW3との間に開始するために、SGW2(又はコアネットワーク内の別のモビリティマネジメントエンティティ(MME))にコンタクトしてもよい。
ブートストラップの成功の直後に、MN1がPGW3へのデータパケットの送信を開始することができ、PMIPトンネルを経てデータパケットをSGWに転送し、これをMN2のIPプレフィックスがホストされているPGW2にルーティングしないように、確立されたルーティングエントリをPGW3は有することが望ましいので、ブートストラップ手順の終了前に、PMIPトンネルを確立することが有利となる。
このようにして、ROAはMN1とMN2との間の元のデータパス上ないが、最適化されたデータパスが達成される。
これまで、ネットワークベースのモビリティはPMIPv6プロトコルに基づくものと想定されている。しかし、本発明はPMIPv6プロトコルに限定されず、PGW3/PGW2とSGWとの間にGTPなどの別のプロトコルを適用することができる。
●データ交換の詳細
図7は、説明してきた本発明の実施形態によるルート最適化実行後のMN1とMN2との間で交換されたデータパケットのヘッダ構造を下部に示している。
MN2は、送信元アドレスとしてのMN2のアドレスと、宛先アドレスとしてのMN1のHoAとを有する対応するヘッダを有するデータパケットを生成する。このデータパケットは、第1のルータに送信される、それは、SGWであり、このシナリオではROAでもある。ルーティングエントリ及び対応するバインディングキャッシュエントリに従って、データパケットは別のヘッダでカプセル化され、その際、SGWのアドレスは送信元アドレスであり、MN1のCoAは外側ヘッダの宛先アドレスである。したがって、データパケットは、データパケットを非カプセル化し、さらに処理できるMN1に転送される。
MN2は別のモバイルノードとのさらなるセッションを有してもよい。これらのデータパケットは宛先アドレスとしてMN1のHoAを有しておらず、別のアドレスを有している。したがって、これらはMIPを経てMN1に転送されるのではなく、PMIPを経てPGW2に転送される。言い換えると、以前確立された特別のルーティングエントリは、宛先アドレスとしてMN1のHoAを有するデータパケットのみ適用できる。
MN1は、送信元アドレスフィールド内にMNIのHoAを含み、かつ、宛先フィールド内にMN2のアドレスを含む対応するヘッダを有するデータパケットを生成する。通常、すべてのMIPトンネルは異なるホームアドレスに基づいているので、MN1は通常、データパケットの送信元アドレスフィールドに従って、前記データパケットがどのMIPを経て送信されるかを選択する。しかし、この場合は、MN1の同じホームアドレスに基づく2つのMIPトンネルがMN1内に存在する。HPLMN内のそのホームエージェントPGW1へのトンネルと、その他のトンネルはVPLMN内のROAに向かっている。したがって、MNは、宛先アドレスとしてMIPトンネルへのMN2のアドレスを有するデータパケットをROAへと向けるルーティングエントリを必要とする。対応するバインディングキャッシュエントリによって、MNIは、送信元アドレスとしてのMN1のCoAと、宛先アドレスとしてのROAのアドレスとを有する外側ヘッダを構築される。
このように、データパケットは適切なMIPトンネルを経てROAに送信され、これがデータパケットを非カプセル化する。ROAは、データパケットの宛先アドレスフィールド内のMN2のアドレスを、MN2に向かう適切なインタフェイスと関連付けるルーティングエントリに従って、非カプセル化されたデータパケットをMN2に転送する。
MN1は別のモバイルノードとのさらなるセッションを有してもよい。しかし、宛先アドレスはMN2のアドレスではないので、MN1内の特別のルーティングエントリは適用されず、データパケットはMIPトンネルを経てHPLMN1内のPGW1へと送信される。
図9は、本発明の幾つかの実施形態によるROを実行するためにMN1が講じる幾つかのステップを図示するフローチャートを示す。MN1は「RO検出メッセージ」をMN2に送信することでRO検出手順を開始する。MN1は、(1つ又は複数の)RO応答メッセージを受信し、かつ、格納された情報を取出す、それは、例えばMN2の現在のネットワーク(VPLMN−ID)及び/又は可能性のあるROA候補を含んでいてもよい。このようにして、MN1はルート最適化を実行するか否かを決定することができる。
ROが実行されるべきであることが想定され、この場合は、MN1はMN2がMIPv6をサポートするか否か、かつ、可能ならば本発明によるルート最適化によってMIPv6のROが本当に有益であるかを判定する。
MIPv6がサポートされ、MIPv6のROが有益である場合は、MN1はMN2とMIPv6のRR/RO手順を実行する。他方では、MN2のVPLMNとMN1のホームネットワーク、HPLMN1との間にローミング合意が存在するか否かを判定する必要がある。ローミング合意が存在しない場合は、本発明によるルート最適化は実行されない。
ローミング合意が得られている場合は、ルート最適化エージェントが判定され、特に、MN1とMN2との間のデータパス上でルート最適化エージェントが可能であるか否かが判定される。
判定されたROAが前記データパス上にあるか否かに応じて、本発明の異なる2つの実施形態が実行される。第1の実施形態は、図6及び図7を参照して記載された、ROAがデータパス上にあるシナリオである。第2の実施形態は、ROAがPGW3内の元のデータパス外にあり、SGWとROAとの間に追加のトンネルが必要な、図8に関連して記載されたシナリオである。このようにして、MN1とMN2との間に新たな最適化されたデータパスが確立される。
以下では、MN1がそのホームネットワークHPLMN1内に位置している場合、本発明の別の実施形態によるルート最適化を記載する。このシナリオは、ROAとMN1との間の双方向のパケットヘッダフォーマットを含めて図10に示されている。このシナリオのルート最適化は、多くの態様で図6及び図7に関して詳細に記載したものに対応している。主な相違点は、ROA/SGW内にバインディングキャッシュエントリの確立にある。通常、ホームエージェント機能はMNのホームネットワーク内に位置し、MNは外部ネットワークからのCoAを有しているので、通常は、MIPv6内のバインディングキャッシュエントリはMNのHoAを前記MNの対応するCoAと関連付ける。しかし、このシナリオでは、ホームネットワークにアタッチされるMN(ホームリンクとしても知られている)は、(ホームリンク上の)MNのホームネットワーク内に存在しないホームエージェントの機能(すなわちROA)を有するエンティティでMIPトンネルを構成する。このようなシナリオは、MIPv6仕様の基準から修正された機能を実施するMN及びホームエージェントでのみ可能である。本発明の別の部分で記載したように、MNとホームエージェントとは、ホームエージェントにとってトポロジー的に正しくないホームアドレス用にMIPトンネルを確立できるように修正されることが望ましい。したがって、この場合は、ROAが、カプセル化されたデータパケットを、MIPトンネルを経てHPLMN1内のMN1に送信できるように、ROA内のバインディングキャッシュエントリはMN1のHoAをMN1のHoAと関連付ける。
バインディングキャッシュエントリが存在しないとすれば、ROAは、MNがそのリンク、すなわちVPLMNの3GPPにアタッチされるものと想定されるであろうが、そうではない。したがって、MN2からMN1に送信されるデータパケットは、外側トンネルヘッダ及び内側ヘッダに同じ宛先アドレス、すなわちMN1のHoAを含んでいる。これに対応して、MN1からMIPトンネルを経てROAに送信されるデータパケットは、外側トンネルヘッダと内側ヘッダの両方に同じ送信元アドレスであるMN1のHoAを有している。
本発明のルート最適化が実行された後、MN1とMN2との間のセッションの継続性を保つための追加のメカニズムが必要である。MN2が通信セッション中にそのSGWから離れた場合、データパケットは依然として旧来のSGWに着信され、したがって、MN2には到達しないであろう。異なる2つの場合が区分され、以下に検討する。
MN2は同じPLMN内の別のSGWに移動することがあり、その場合の2つのサブケースを記載する。
ルート最適化エージェントにSGWが割り当てられると、MN2が新たなSGWに移動した後、ROA切り換え手順を実行しなければならない。
先行技術では、旧来のROAが「HA切り換え」メッセージをMN1に送るHA切り換え手順が知られている。しかし、先行技術のHA切り換えメッセージは常時送られることができないので、ROAがMNを別のROAに積極的に移動する場合に、HA切り換え手順を適用することはできない。したがって、本発明の目的のために新規のタイプのROA切り換え手順が必要である。
ROAは、新たなROAをMN1に通知するために、IKEv2プロトコルメッセージを使用してもよい。例えば、IKEv2 INFORMATIONAL交換手順によれば、ROAは新たなROAのためのアドレス情報を含むIKEv2メッセージをMN1に送ってもよい。したがって、MN1は、MN1のROAへのMIPトンネルを更新してもよく、データパケットは新たなROAに適正に送信される。
ROAにSGWが割り当てられず、MN2のVPLMN内のローカルPSW(例えば図8のPGW3を参照)が割り当てられる場合は、新たなSGWとROAとの間にPMIPトンネルを確立できる限りはROAを変更する必要はない。新たなPMIPトンネルの確立をトリガする手順は、PLMNへのSGW再割り当て手順の一部であってもよい。
MN2が別のPLMNに移動する場合、第1に、ROAに新たなMN2の位置が報知されず、及び/又は、第2に、何らかの方法でROAに新たなMN2の位置が報知されたとしても、ROAは、それが別のPLMN内にあるので、新たなMN2のアクセスゲートウェイへのトンネルを確立することができないため、PGW内、又はSGW内に位置する(旧来のPLMN内の)ROAはもはや使用できない。(ROAがSGWにある場合)MN2がROAに直接アタッチされるので、又は(ROAがPGW3にある場合)ROAへのPMIPトンネルが解体されるので、ROAはMN2の移動を認識する。これらの場合は、ROAはMIPv6をMN1からデタッチする手順を開始する必要がある。デタッチ後、MNIはその元のHA(すなわちPGW1)を経て双方向MIPv6トンネルを使用することができ、又は、ROが必要であるか否か、及び/又はどのタイプのROが有益であるか否か、及び/又は必要である場合は、新たなPLMN内の新たなROAを発見するために、MN1は新たなRO検出手順を開始することができる。
前記のシナリオでは、仮定が、MN1が非3GPPアクセスシステムにアタッチされ、MN1はROAへのMIPトンネルの確立を実行できることである。
以下では、別のシナリオ、すなわち、MN1が3GPPベースのアクセス技術、すなわち、UMTS又はLTEアクセスシステムにアタッチされる場合を考慮する。3GPPアクセス技術はマクロ(e)NBセル、又はミクロH(e)NBセル、又はワイヤレス中継ノードによって提示されてもよい。一般に、基地局の(H)(e)NBの表記は、基地局が以下の1つ、NB、HNB、eNB、又はHeNBであることを意味している。
本発明の以下の実施形態では、図11に示すシナリオが考慮される。MN1が民間企業ネットワーク内のHeNB1に接続され、MN2と通信し、一方、それは同じVPLMN内のeNB2又はHeNBにアタッチされてもよいものと想定される。最初に、MN1とMN2との間のデータは、それぞれのホームネットワークHPLMN1及びHPLMN2を経て交換される。MN1は、ローカル接続を確立することを決定してもよく、ローカルIPアクセス(LIPA)を実行してもよい。これに対応して、MN1はそのMMEにPDN接続性要求(PDN connectivity request)を送信し、次いで、それはMN1のローカルPDN接続のためのローカルゲートウェイ(L−PGW)を決定する。例えば、L−PGWにHeNB1を割り当ててもよい。L−PGWはローカルPDN接続の確立中にMN1のMMEによって決定される。L−PGW選択手順をサポートするため、HeNB1は例えば、PDN接続確立手順中にL−PGWの機能をサポートする旨をMMEに対して指示してもよい。MN1はローカルPDN接続用の(HeNBである)L−PGWから新たなIPアドレスを構成する。したがって、MN1からMN2へのデータパケットは、HPLMN1(PGW1)及びVPLMN内のその他のコアネットワークエンティティにルーティングされず、MN2のホームアドレス(図11には図示せず)に基づいて、HeNB1/L−PGWからHPLMN2に直接ルーティングされる。図11は、前記のルーティングの最適化を、すなわち、トンネルはL−PGWを通過するので、MN1はローカルPDN接続を利用してMN2のゲートウェイ(例えばSGW2)へのトンネルを確立できることを示している。これについては後に詳述する。
図11はさらに、MN1が別のモバイルノードと通信するためのHPLMN(ホーム経由のトラフィック)へのPDN接続と、MN2と通信するためのL−PGWとのローカルPDN接続を同時に有することができることを示している。
本発明の実施形態によれば、RO検出メッセージが、本発明のこれまでの実施形態で上述したように、ROAを決定するために、MN1からMN2に送信される(ステップ(1))。この場合は、傍受エンティティ、この場合、SGW2がRO応答メッセージで応答し(ステップ(2))、SGW2がROAとして動作可能である旨を示す。したがって、MN1は、ROAとしてのMN2のSGW2を発見し、そして、SGW2のブートストラップを開始する(ステップ(3))。MN1は、ROAへのトンネルを確立するために、L−PGW(HeNB)から取得したローカルIPアドレスを使用する。トンネルの確立中に、MN1は、MN2から送信されるデータパケットの宛先アドレスがMN1のHPLMNからのホームアドレスである場合は、これらのデータパケットはトンネルを経て転送されるべきである旨を、ROAに対して報知することができる。このようにして、MN2から送信され、トンネルを経てMN1を宛先とするパケットを転送するために、特別のルーティングエントリがROA/SGW2内に確立される。言い換えると、ROA(SGW2)とMN1との間に確立されるセキュリティアソシエーションは、MN1のホームアドレスではなく、MN1のローカルアドレスに基づくものである。これに対応して、MN1とROAとの間にIPトンネルが確立される(ステップ(4))。
さらに、データパケットがMN1とMN2との間でのデータパケットの適正な転送を確実にするため、それに従ってROA内のルーティングエントリ及びバインディングキャッシュエントリが定義される必要がある。
図11は、本発明の実施形態で実行されるステップを示し、かつ、本発明の実施形態を実行した後のデータパケットの交換を示している。より詳細には、MN1はMN2のホームアドレスを宛先とするデータパケットを、確立されたIPトンネルを経てROAに送信する。ROAは、MN2のホームアドレスをeNB2へのGTPトンネルと関連付ける対応するルーティングエントリに基づいて、これらのデータパケットをさらなるGTPトンネルを経てMN2のeNB2に転送する。次いで、eNB2は無線リンクを経てデータパケットをMN2に転送する。逆に、ROA内のMN2(SGW2)から着信し、MN1のローカルアドレスを宛先とするデータパケットは、IPトンネルを経てMN1に転送される。
本発明の実施形態は、多くの点で、図6に関連して記載した前記実施形態と同様である。例えば、ROAの発見及びトンネルの確立の手順は同一であってもよい。
MN1とSGW2との間で使用されるデータパケットのヘッダの構造は、図7に示したヘッダと同様である。相違点は、MIPトンネルの代わりにIPsecトンネル又はIP−in−IPトンネルを使用できることと、内側IPヘッダが元のMN1のIPアドレス(図7のMN1のHoAと同様の、PGW1からの)を含むことと、外側IPヘッダがMN1のローカルアドレス(図7のMN1のCoAと同様の、L−PGW/HeNBからの)を含んでいることである。
図11のシナリオでは、MN1が3GPPアクセスに接続されるものと想定されている。現在の3GPP標準化に基づき、3GPPネットワークにアタッチされるMNはMIPv6シグナリングを実行することが許可されていない。ROAへのMIPトンネルを確立できないという点で、このことは本発明の実施形態にとって意味を有する。このことで今後の標準化が変更されるかもしれないが、現時点での代替解決策は、L−PGW(HeNB)を経たROAへの仮想プライベートネットワーク(VPN)の場合のように、MN1はIPsecトンネルを確立することであり得る。
現在説明している本発明の実施形態では、図11に示すように、RO検出メッセージ及びRO応答メッセージを使用してSGW2が発見されるものと記載されている。あるいは、MN1が、VPLMN内のMN2のローカルセキュリティ/サービングゲートウェイを要求するDNS要求をMN1がDNSサーバに送信するドメイン名システム(DNS)を使用して、SGW2はMN1によって発見することができる。次いで、DNSサーバが、MN1によってROAとして使用されるSGW2のIPアドレスで応答する。さらなる代替は、ダイナミックホスト構成プロトコル(DHCP)シグナリングの使用に関連する。特定のVPLMN内のMN2のトラフィックのデータパスに属するROAエンティティを発見するためにDHCPを使用する場合は、MN1は例えば、情報要求メッセージのホームネットワーク識別子フィールド内に所望のROA名(例えばMN2_ID.Data_Gateway.VPLMN.org)を含むことができる。MN2が同じDHCPサーバを用いるので、DHCPサーバはMN2を認知してもよい。したがって、DHCPサーバは、MN1の要求に対して、(利用できる場合は)ROAエンティティのIPアドレス、又はMN1がDNS要求のために後に使用可能なFQDNで応答することができる。
ルーティングパス上の、又はMN2の近隣にあるSGW2を発見するため、DNS及びDHCPプロトコルは、対応する要求に何らかの特定の情報(例えばMN2のIPアドレス)を含めるように、拡張する必要がある。
以下に、本発明のさらなる実施形態を提示する。これらの本発明のさらなる実施形態は、MN1がローカルにルーティングされるトラフィックを有することを希望し、そのためにLBOを実行するシナリオに対処するものである。図11のシナリオと同様に、MN1はミクロH(e)NB又はマクロ(e)NBを経て3GPP技術にアタッチされる。LIPAは、MNがH(e)NB(すなわちミクロセル)にアタッチされ、(e)NB(すなわちマクロセル)にアタッチされない場合だけ適用可能である。
通常、MN1がLBO(又はLIPA)を実行する際に、ネットワークに要求メッセージを送信することによって、VPLMN内のローカルPDN接続が確立される。特に、PDN接続要求は、MN1のMMEに送信され、これはEPSベアラのアイデンティティ、PDNのタイプ、アクセスポイント名(APN)及びMN1が確立したい新たなPDN接続を特定するために使用されるその他の情報を含んでいてもよい。MN1がLBOを実行したい場合、すなわちVPLMN内にローカルにアンカされるPDN接続を確立したい場合、MN1は適切な情報、例えばAPNはMMEに対して、PDN接続をローカルな接続にするべきであることを明確に指示すべきであるという適切な情報を含むことができる。また、MN1は、ローカル又はホーム経由のトラフィック及びネットワーク(例えばポリシー設定に基づくMME及び/又はHSS)がローカル又はホームPGWを選択するという指示なしで、APNを含む要求を送ることも可能である。
MMEが新たなPDN接続のためにPDN接続性要求を受信する後、MMEは、PDN接続のための適切なL−PGWを決定するため、AAA(認証、認可及び課金)サーバ又はホーム加入者サーバ、HSSなどの加入者データベースを要求してもよい。幾つかのネットワーク展開では、MMEは場合によっては別のネットワークエンティティからの情報を要求せずにL−PGWを決定してもよい。最後に、MMEは、VPLMN内にL−PGWを割り当て、そして、選択されたPGWを使用するために、このPDN接続用の選択されたSGWに、かつ、eNB1に指示する。LBOの場合、ローカル/在圏PGW(L−PGW)は通常はコアネットワーク内に位置するのに対して、LIPAの場合は、L−PGWは、(例えば図11の場合のようにHeNBとコロケートされた)アクセスネットワーク内に位置する。
しかし、選択されたL−PGWは、特にLBOの場合は、MN2又はMN1の位置に関して最適ではないかもしれない。例えば、MN1とMN2とがVPLMNの近隣に位置しているにも関わらずデータパケットは依然として長距離を移動することがあるように、選択されたL−PGWはVPLMN内に位置している。
したがって、本発明の以下の実施形態によれば、MN1とMN2の間のデータパケット交換にとって最適であるL−PGWが決定される。
図12を参照して、本発明の以下の実施形態を説明する、それは、MN1がeNB1に接続され、LBOを実行したいシナリオを示す。MN1はそのMMEにPDN接続性要求を送信できる(ステップ(1))。この実施形態によれば、PDN接続性要求は、MN2とのデータ交換のためにMN1が使用する適切なL−SPGWを決定する際に使用されるMN2のIPアドレスを付加的に含んでいる。言い換えると、最適なL−SPGWを決定する際にMMEがMN2の位置を考慮できるように、MN1はMN2に関する情報を送信する。
MMEはそれに従って、MN2で受信した情報に基づいて、MN2へのMN1の接続のために、L−SPGWを決定する。有利に、MMEは、MN2のSGW2とコロケートするようにL−PGWを決定する、なぜなら、これによって関与するデータパス上のエンティティ数が最小限になるからである。
MMEは、MN2がVPLMNにアタッチされているか否かをチェックする手段を有するべきである。もしそうならば、MMEは、MN2のゲートウェイ、すなわちPGW又はSGWを決定し、そして、ローカルPDN接続のためにL−SPGWとしてSGW2をMN1に割り当てる。MN2がVPLMNに属しておらず、又はMMEがMN2に関連する適当なゲートウェイを決定できない場合は、すなわち、MN2が登録/接続されているVPLMN内にSGWもPGWも存在しない場合は、MMEは従来技術と同様にいずれかのPGWをMN1に割り当てる。
SGW2がコロケートされたローカルSGW及びPGW(すなわちL−SPGW)の機能を実行できることをMMEが判定した後、MMEはSGW2に対して、SGW2がMN1のローカルPDN接続用のL−SPGWになるべきであることを報知する。この報知は、ステップ(2)で、セッション作成要求メッセージ(create session request message)をL−SPGW(SGW2)に送信することによって行うことが可能であろう。SGW2は、IPv6プレフィックスなどのMN1のローカルPDN接続のためのIPアドレス情報を含むかもしれないベアラセットアップ応答でMMEに応答する。
次いで、MMEはステップ(3)で、eNB1とL−SPGW(SGW2)との間のトンネルの確立を開始するために、(例えばベアラセットアップ要求メッセージを送信することによって)eNB1に報知する。ベアラセットアップ要求メッセージ(bearer setup request message)はさらに、PDN接続性要求受け入れメッセージ(PDN connectivity accept message)をアタッチされてもよく、これによって、MN2へのデータパケットのローカルルーティングのための要求されたローカルPDN接続が成功したことをMN1に通知するために、MMEはMN1に応答してもよい。したがって、ベアラセットアップ要求メッセージはeNB1によって受信され、アタッチされたPDN接続性受け入れメッセージはさらにMN1に転送される。
MN1の新たなIPアドレスを構成するため、PDN接続性要求受け入れメッセージは、ベアラセットアップ応答メッセージ内にMMEによって受信されたL−SPGW(SGW2)のIPプレフィックスを含んでいてもよい。SGW2のIPプレフィックスを受信すると、MN1はMN2との通信にさらに使用する新たなIPアドレスを構成する。追加的に又は代替的に、SGW2(L−SPGW)は、それがMN1のローカルゲートウェイになる旨を報知された後、HPLMN1内のPGW1に割り当てられたホームアドレスの代わりにMN1によって使用される新たなIPアドレスを構成するため、ルータ広告がSGW2からMN1に送信されてもよい。
(例えば図6又は図11に示したような)前記実施形態とは対照的に、トンネル(例えばGTP/PMIP)はMN1とSGW2との間にではなくeNB1とSGW2(L−SPGW)との間であることに留意されることが望ましい。したがって、eNB1とL−SPGWとの間のトンネルが確立される。
MN2への変更が必要ないように、すなわちMN1が新たなローカルPDN接続を使用するように、MN1とMN2との間で通信ができる異なる方法が可能であろう。第1の通信オプションでは、MN1は、送信元アドレスとしてローカルPDN接続の新たに構成されたIPアドレスを使用して、MN2へのデータパケットの送信を開始してもよい。次いで、L−SPGWはMN1からMN2へのパケットの送信元IPアドレスを交換する特別の機能を実施することが望ましいので、その際、ローカルPDN接続のIPアドレスはホーム経由PDN接続(ホーム経由のトラフィック)のIPアドレスと交換される。送信元アドレスを交換するこの機能は、コンピュータネットワークで実行される、いわゆる送信元ネットワークアドレス変換(送信元NAT)処理と比較可能である。L−SPGW内でのこの機能は、PDN接続確立段階中、すなわちステップ(2)の間に、MMEによって起動可能である。類推的に、MN2はパケットの宛先を旧来のMN1のIPアドレスにしているので、MN2からMN1へのパケットの宛先IPアドレスも交換される必要がある。この宛先IPアドレス交換プロセスは、宛先NATプロセスと同一である。L−SPGWは宛先アドレスをローカルPDN接続用に構成されたIPアドレスと交換するべきである。
MN1とMN2との間の通信を行う第2の通信オプションは、ローカルPDN接続を経てMN2に送るパケット用の送信元IPアドレスとして旧来のホーム経由のPDN接続のIPアドレスを使用し続けることである。通常、MN1がローカルPDN接続を介して別の通信相手ノードと通信する場合、MN1はローカルPDN接続にとって正しいIPアドレス、すなわちL−PGWによって割り当てられるIPプレフィックスに基づくIPアドレスを使用する。しかし、MN1は、(MN2などの)既存の通信セッションへのデータパケット用にだけ、旧来の(すなわちホーム経由の)PDN接続を介して構成されたIPアドレスを使用する。これは、MN1とMN2との間の通信セッションの継続性を保つために必要である。この第2のオプションは、eNB1が(無線リンクを経て)論理チャネルのID、及び(L−SPGWへのS1−Uインタフェイスを経て)ベアラIDに基づいて、パケットをMN1へ及びMN1から転送するので、eNB1にとっての新たな問題を引き起こすことはない。この第2の通信オプションを使用して、L−SPGWは、(それがそもそも適用されている場合)MN1のパケットにイングレスフィルタリング(ingress filtering)を適用しない、すなわち、L−SPGW(又はVPLMN内の別のルーティングエントリ)は、MN1に割り当てられたIPプレフィックスとは異なる送信元アドレスを有するデータパケットにフィルタリングを行わない。(必要な場合は)イングレスフィルタリングの機能停止をローカルPDN接続の確立中、例えばステップ(2)の間にMMEによって行ってもよい。さらに、MN2から送信され、MN1を宛先とするデータパケットを、トンネルを経てeNB1へとルーティングするために、特別のルーティングエントリをL−SPGW内に備えてもよい。この特別のルーティングエントリは、MMEがL−SPGWに対してPDN接続に関して報知する際にステップ(2)の間に確立することができる。MMEは、MN1から受信され、MN2のID(例えばIPアドレス)を含むPDN接続性要求に基づいてこの特別のルーティングエントリの必要性を認識する。
第2のオプションは、送信元/宛先IPアドレスを交換するための新たなNAT(ネットワークアクセス変換)機能がL−SPGWに必要ないため、好適である。さらに、幾つかのIPアプリケーションではIPアドレスの交換は望ましくない。
eNB1はトンネルを経て前記データパケットをL−SPGWへと転送する。データパケットは、宛先としてはL−SPGWアドレスで、また、送信元アドレスとしてはeNB1アドレスでカプセル化される。
L−SPGWに着信したデータパケットは非カプセル化され、GPTトンネルを経てeNB2に、又は、最終的には無線リンクを経てMN2に転送される。必要なルーティングエントリはL−SPGW内に既に存在する。MN1とMN2との間の通信の第1の通信オプションでは、L−SPGWは、MN1からMN2に送信されるデータパケットの送信元IPアドレスを交換するいわゆるNAT機能を実施する。MN2からMN1に送信されるパケットの場合は、L−SPGWは宛先IPアドレスを交換することになる。
本発明の実施形態によるLBOを認知しないMN2は、データパケットをMN1のホームアドレスに送信し続ける。これらはeNB2からSGW2にGTPトンネリングされる。MN1とMN2との間の通信の好適な第2の通信オプションによれば、SGW2は、MN1のホームアドレスを確立されたeNB1へのトンネルと関連付けるルーティングエントリを有しており、したがって、これらのデータパケットはeNB1に転送され、ここからMN1に送信される。
L−SPGW内の必要なルーティングエントリは、ステップ(2)のセッション作成要求メッセージを使用して構成することができる。
以下に、MN1のMMEが、PDN接続性要求メッセージ内の送信されたMN2のIPアドレスに基づいて、特にIPプレフィックスに基づいて、どのようにMN2のSGWを発見するかを説明する。通常はMN2のIPアドレスはPGWのIPプレフィックスに基づいて構築されるので、特にMN2のPGWがMMEと同じVPLMN内に位置し、MN2のSGW2とコロケートされる場合は、MMEはMN2のPGWを発見する手段を有することができる。
しかし、MN2のPGWがVPLMN内(すなわちMN1のMME PLMN内)に位置しない場合は、MMEがMN2のPGW/SGWを決定することは不可能であろう。この場合は、MN1のMMEは、MN2のMMEを発見することを試み、MMEに対してMN2のPGW/SGWのアイデンティティを要求できる。例えば、MN1のMMEは、利用できるMN2のエントリがある場合は要求するために、VPLMN内の加入者/ロケーションサーバ(HSSなど)にコンタクトしてもよい。MN2がVPLMN内に登録されている場合は、加入者/ロケーションサーバは、エントリを有することが望ましく、かつ、MN2のMME及び対応するSGW及び/又はPGWを認知することが望ましい。MN2のMMEは、MN2がアイドル状態にあるか又は接続状態にあるかに関わりなく、MN2のPGW/SGWを認知しており、SGW2に関する情報でMN1のMMEに応答する。
本発明の代替的な実施形態によれば、MN1は、MN2の位置、又はMN1との通信に使用されるMN2のPDN接続に関する情報を得るために、前記実施形態のRO検出メッセージ及びRO応答メッセージを適用することができる。特に、傍受エンティティは、適切な情報を有することができ、かつ、MN2のAPN、又はMN2用に現在使用されているPDN接続に関する他の情報、PGW2の情報(例えばPGW2のIPアドレス、名前又はID)、及び/又はSGW2の情報(例えばSGW2のIPアドレス、名前又はID)を含むRO応答メッセージを生成できる。
さらに、MN2は(図12に示すようなeNB2の代わりにHeNB2にアタッチされる場合は)、LIPAを適用することも可能であり、この場合は、RO応答メッセージはMN2のローカルゲートウェイ(MN2のL−PGW)に関する情報も含んでもよい。例えば、MN2がVPLMN内にローカルPDN接続(標準のLBO又はLIPA)を有している場合は、MMEはMN1用のL−SPGWとしてMN2のL−PGWさえ割り当てることも可能である。
MN1が「RO応答メッセージ」を受信するとき、MN1はステップ(1)のPDN接続性要求に含まれる発見されたMN2の情報をMMEに信号で伝えることが望ましい。言い換えると、MN1は、MN2と接続中のMN1にとって最適なL−PGWの決定に関する、RO応答メッセージから得た情報でMMEを支援することができる。
以下では、何らかの理由でeNB1とSGW2との間の直接のトンネル接続が不可能であるシナリオが想定される。例えば、MN1のeNB2が、ネットワーク内の位置次第によってSGW2へのトンネル確立ができないことがある。この場合は、本発明の前記実施形態は適用できず、その変化形態を以下に説明する。
前記例によりMN2のIPアドレスに基づいてMN1にとって最適なL−PGW(例えばSGW2)を決定する際に、MMEは、eNB1とSGW2との間の直接のトンネル接続が不可能であることを、又は、ネットワーク構成又は地理的な距離のためにMN1用のSGWとしてSGW2を使用できないことを認識する。これに対応して、MMEは、eNB1用にアクセス可能なL−PGW、例えば、MN1のホーム経由PDN接続に使用されるSGW1を決定する。さらに、前記実施形態と同様に、SGW2とコロケートされるL−PGWがMMEによって決定される。
図13は、このシナリオ及び対応するネットワーク構成を示している。ステップ(1)で、MN1はMN2のIPアドレスを含むPDN接続性要求メッセージをMMEに送信する。ステップ(2)は、MMEから、PDN接続性要求に応答してMMEによってSGW1として決定されたL−SGWへのメッセージ(例えばセッション作成要求)の送信に関する。セッション作成要求メッセージは、SGW2 SGW2のIPアドレス、及びMN1がアタッチされているeNBのID(例えばeNB1)を含んでいる。SGW1もL−SPGWとして、図13のステップ(3)で示したように、SGW2とコロケートされたL−PGWとのS5インタフェイスを経てトンネルを確立するように指示される。例えば、MMEは、L−SGWに対してS5トンネル及び関連情報を報知するために、セッション作成要求メッセージを使用してもよい。トンネルの確立中、L−PGW(SGW2)はL−SGW(SGW1)に対して、ローカルPDN接続のためにMN1に割り当てられるIPv6プレフィックスに関して報知する。次いで、SGW1は、MMEに対して、SGW2から得たMN1のIPv6プレフィックス情報を含め、(例えばセッション作成要求メッセージで)L−SGWへのトンネルの確立が成功した旨を確認応答する。
次いで、ステップ(4)により、MMEは、S1−Uインタフェイスを経て、eNB1とSGW1との間にトンネルが確立されるために、(例えばベアラセットアップ要求メッセージを送信して)eNB1に指示する。ベアラセットアップ要求メッセージは、MN1が新たなIPアドレスを構成するために上述のように、アタッチされたSGW2のIPプレフィックスを含む(MN1への)PDN接続性受け入れメッセージを含んでいてもよい。
eNB1はL−SGWとのトンネルの確立を開始し、セッション作成要求メッセージ内の送信された情報に基づいていることは、て、eNB1とのトンネル確立を確認し、実行することができる。
あるいは、eNB1とSGW1(L−SGW)との間でデータパケットを交換するために、ホーム経由のトラフィック用の既に確立されたトンネルが再使用されてもよい。この場合は、選択されたL−PGW(SGW2)に基づいてMN1のために確立された新しいIPアドレスにより、eNB1及びSGW1内に新たなルーティングエントリを定義する必要があろう。eNB1は、IPアドレスに基づいてではなく、無線インタフェイス及びS1−Uインタフェイスを経て使用されるベアラ識別子に基づいてMN1のデータパケットを転送してもよいことに留意されたい。より詳細には、(新たなローカルIPアドレスである)MN1の新たな宛先IPアドレスを既に確立されたeNBへのトンネルと関連付けるダウンリンクトラフィック用のルーティングエントリをSGW1内に定義することが可能である。アップリンクでは、SGW1は、それらがPGW1に送られるべきかSGW2に送られるべきかを判定するために、MN1から送信されるパケットを区別するべきである。そのために、SGW1は送信元IPアドレスを検査する、例えば送信元IPアドレスがホーム経由PDN接続に属していればパケットはPGW1に送信され、そして、送信元IPアドレスがローカルPDN接続に属していればパケットはPGW1に送信される。以下に記載するように、使用される通信オプションに応じてMN1からMN2へのデータパケットには1つの例外が実行されることが望ましい。
MN1とMN2との間の通信は、図12の実施形態について上述したものと同様に行うことができる。言い換えると、第1の通信オプションと第2の通信オプションとを適用できる。以下では、MN1とMN2との間のローカルルーティングのために、S1−Uインタフェイスを経たさらなるトンネルが確立されるものと想定される。
データパケットをMN1とMN2との間で正しく転送するため、SGW1及びSGW2内の対応するルーティングエントリが定義される。詳細には、L−PGWとしてのSGW2は、(MN2はMN1のホームアドレスにデータパケットを送信し続けるので)第1の通信ノードのホームアドレスをL−SGWとしてのSGW1への確立されたトンネルと関連付けるルーティングエントリを有している。SGW1とSGW2との間のS5トンネルの確立中に、対応する指示に応じてSGW2内のルーティングエントリを確立してもよい。
一方、SGW1内では、MN1のホームアドレスである宛先アドレスと、S1−Uインタフェイスを経てeNB1へのトンネルと接続するルーティングエントリが構成される。SGW1内の別のルーティングエントリは、MN2のホームアドレスを宛先アドレスとしてSGW2(L−PGW)へのトンネルと関連する。eNB1では、MN2のホームアドレスを宛先として、確立されたL−SGW、SGW1へのトンネルと関連付ける。
したがって、ローカルにルーティングされた最適なデータパスは、MN1とMN2との間のトラフィック用に、SGW1及びSGW2を介して定義される。
図12の第1の通信オプション及び第2の通信オプションの代替として、MN1は新たなIPアドレスの構成後にMN2への接続を再確立してもよい。これによって、前記特別のルーティングエントリが不要となる、それは、(MN2よってさらに使用される)以前使用されたMN1のホームアドレスと、(L−PGWのIPプレフィックスで構成される)新たに構成されたMN1のローカルアドレスとの間でのIPアドレスを「変換」又は交換と定義される。しかし、MN1が別のPLMNに変わった場合に、MN1とMN2との間の必要なエンドツーエンド(end-to-end)シグナリングと、可能性のある限定的なモビリティは、前記観点から不利である。これに対応して、この代替案は、図12に示す実施形態に、図14、図15、及び図16に示すその後の実施形態にも同じように、適用される。
以下に、SIPTOがLBO又はLIPAの代わりにネットワークによって実行されるシナリオ、すなわち、ネットワークがMN1の関与なしでMN1のトラフィックをローカルにルーティングすることを決定する場合について記載する。したがって、例えばSGW1などのVPLMN内のエンティティが、MN1のトラフィックをモニタし、そして、MN1が同じPLMNにアタッチされているMN2と通信しているものと判定する。その結果、VPLMN内のエンティティ(例えばSGW1)は、データパケットをそれぞれのHPLMNにルーティングせずに、MN1とMN2との間にトラフィックをローカルにルーティングすることを決定する。この場合は、SGW1はMN1のMMEに対して可能性のある最適化を報知してもよい。MMEはSGW1とSGW2との間にトンネルを確立することを決定してもよく、したがって、MN1とMN2との間でデータパケットを交換する適切なルーティングエントリを確立するようにそれらを指示する。SIPTOはネットワーク制御されるので、MN1又はMN2へのシグナリングは必要ない。
上述の実施形態では、L−PGW又はL−SGWとしてSGW2を選択できるものと想定されている。しかし、SGW2を選択できない場合は、SGW1をL−SPGW、すなわち複合されたL−SGWとL−PGWとして使用できる。しかし、この場合は、MMEは、ローカルSGWとローカルPGWを発見するために、MN1の位置も考慮することが望ましい。MMEは通常、MN1のSGW1を認知するが、MMEがMN1の位置を実際に考慮し、したがってL−SPGWとしてどのゲートウェイでもなくSGW2を選択することを確実にするために、MN1は、またPDN接続性要求メッセージでMN1のセルTAI(トラッキングエリア識別子)をMMEに送信してもよい。
中継ノード機能のLTE−Aサポート
(中継ノードによって実施される)中継は、例えば、高いデータ伝送速度の受信可能範囲、グループモビリティ、暫定ネットワーク展開、セルエッジスループットを改善するため、及び/又は新たなエリアに受信可能範囲を提供するためのツールとしてLTEアドバンス用に検討されている。したがって、eNBセルの受信可能範囲を拡張するためのワイヤレス中継ノード(RN)エンティティを導入する、3GPPの最近の活動がある。RNは独立した物理セルを形成できる。
中継ノードは、ドナーセル(donor cell)を介して無線アクセスネットワークにワイヤレスに接続され、かつ、固定でもモバイルでもよい。
接続は、
−インバンドであってもよく、この場合はネットワークからリレーへのリンクはドナーセル内のネットワークからユーザ機器への直接リンクと同じバンドを共用する。この場合、リリース8のユーザ機器がドナーセルに接続可能であることが望ましい。
−アウトバンドであってもよく、この場合はネットワークからリレーへのリンクはドナーセル内のネットワークからユーザへの直接リンクと同じバンドでは動作しない。
ユーザ機器内の知識に関して、リレーを、
−ユーザ機器がリレーを介してネットワークと通信するか否かを認知できない場合の透過性(transparent)と、
−ユーザ機器がリレーを介してネットワークと通信するか否かを知っている場合の非透過性(non-transparent)と、
に分類できる。
通常、RNアーキテクチャの展開は、RNがeNBをUEにエミュレートすることを予見する、すなわち、UEはRNを通常のeNBであると見なすはずである。ネットワークサイドからは、RNはeNBによって通常のUEと見なされる。
本発明の実施形態が適用される以下のシナリオは、図14に例示的に示されているように、MN1がRNにアタッチされるという想定に基づいている。このことから明らかなように、RNはDeNBを介してVPLMNにワイヤレスでアタッチされる。さらに、3GPPの仕様によれば、RNはネットワークによって通常のMNであると見なされることができるので、RNがRNのPGWへの自身のPDN接続を有しており、これは簡略化のためにRNのSGWとコロケートされるものと想定されており、したがってSPGW_RNと呼ばれる。さらに、SPGW_RNはMN1のSGWとコロケートされると想定されており、そのため、通常はVPLMN内のMN1のSGWとHPLMN内にPGWとの間でセットアップされるS8インタフェイスは、SPGW_RNとPGW1との間のトンネルとして示される。RNのトラフィックは、「中継ノードトンネル」又はRN用のS1−Uトンネルと呼ばれるように、(RN用のeNBである)DeNBからSPGW_RNへとトンネリングされる。さらに、MN1トラフィックはGTPトンネル内でRNからSGW1にトンネリングされ、SPGW_RNとコロケートされる。本発明の実施形態を適用する前に、MN1のデータパケットはPMIPトンネルを介してHPLMN1でPGW1にトンネリングされ、そこからさらにPGW2及びMN2(図14には図示せず)に転送される。
本発明のさらなる実施形態によれば、MN1はPDN接続性要求メッセージをMMEに送信することによってLBOを開始する(ステップ(1))。図14で示されるように、PDN接続性要求メッセージはRNトンネル内でSPGW_RNに送信され、そこからMN1のMMEに転送される。また、PDN接続性要求メッセージはMN2のIPアドレスを含んでいてもよく、これは(1つ又は複数)適切なローカルゲートウェイ(L−SGW及びL−PGW)を決定する際にMMEによって考慮される。MN2のIPアドレスに基づいて、MMEは可能なL−SPGWとしてSGW2を発見するが、RNトンネルがあるため、RN又はDeNBとの間でのSGW2との直接トンネル接続は不可能であると判定する。
この点に関して、MMEは、MN1がRNに接続され、固定eNBには接続されないことを認知することが望ましい。既に上述したように、MN1のネットワーク視点から、RNはeNBであるように思われる。しかし、MN1が(例えばRNによって広告される特別なフラグによって)RNに接続されていることを認識していれば、MN1はステップ(1)のPDN接続性要求メッセージ内の対応する情報を含んでいてもよい。あるいは、RNは、MN1がRNに接続されていることをMMEに対して報知するために、RNとMMEとの間で(S1−APシグナリングと呼ばれる)特定のシグナリングを使用してもよい。
MN1がRNにアタッチされており、DeNBからSGW2への直接的な接続が不可能であることを認知した後、MMEはRNからアクセス可能なローカルPDN接続用のL−SGWを決定することが望ましい。より詳細には、MMEはまずMN1が(シナリオで想定される)ローミングであるか否か、及びLBOが実行されるか否かを判定してもよい。この条件が満たされない場合、例えばMN1がホーム経由のトラフィックの確立を望んでいる場合は、通常はMMEがSPGW_RNを解決する理由はない、なぜなら、MN1のPGWはHPLMN1によって割り当てられるからである(MMEは、SGWだけをMN1に割り当てる必要がある)。しかし、HPLMN1とVPLMNは、ホーム経由のPDN接続が確立された後、後の段階でLBOを実行したい場合は、SPGW_RNとコロケートされるMN1のSGWを割り当てることが有利である。
逆に、前記の条件が満たされる場合は、SPGW_RNはローカル経由のトラフィックのためにL−SGWとしてMN1に割り当てられることである。
本発明の実施形態によれば、MMEは、L−SGWとしてMN1に割り当てるため、SPGW_RNの解決を開始する。MMEがSPGW_RNを解決できる様々な方法があり、それらを以下に提示する。
1つの実施形態によれば、RNはMN1のMMEへのS1−APメッセージ内にそれ自体のMMEのIDを含んでいてもよい。それで、MN1のMMEはRNのMMEにコンタクトし、RN用に使用されるSPGW_RNについて質問することになる。
さらなる実施形態によれば、MN1のMMEは、例えばRNから送られたS1−APメッセージからの、RNのIPアドレスを認知する。RNのIPアドレスはRNのPGWプレフィックスに基づいて構築されるので、MN1のMMEはRNのIPアドレスに基づいてSPGW_RNを解決する手段を有することができる。
さらに別の実施形態によれば、RNは、MN1のMMEへのS1−APメッセージ内にそのAPNを含んでいる、それは、SPGW_RNを解決するためにRNのAPNを使用する。有利には、RNのAPNの存在は、UEがRNにアタッチされる指示として、MN1のMMEに利用でき、この情報は上述のようにMMEにとっても必要である。さらに、RNのAPNを使用したSPGW_RNの解決はRNのIPアドレスを使用するよりも容易であり、それは、MMEがPGWによって使用されるIPプレフィックスを認知してないことがあるが、APNを知ればMMEはPGWを解決するためのDNSを適用できるからである。このような理由から、APNを使用することは本発明の有利な実施形態になり得る。
要約すると、MMEはSPGW_RNも決定することができ、次いでSPGW_RNとコロケートされるL−SGWを割り当てる。SGW2をL−PGWとすることが決定される。
次いで、MMEはRN及びL−SGW(SPGW_RN)に対して、LBO PDN接続のためにS1−Uトンネルを相互の間に確立するよう指示する。それぞれは、L−SGWはSGW2内にL−PGWとS5トンネルを確立するようにも指示される。
したがって、MN1とMN2との間のトラフィックはRN、L−SGW及びL−PGWの間のローカルルーティング用に確立されたトンネルを経て転送される。そのために、図13の実施形態に関連して説明したルーティングエントリと同様な、ルーティングエントリが必要である。あるいは、MN1の新たなIPアドレスを使用して、MN1とMN2との間の通信セッションを再確立してもよい。しかし、この場合はMN2へ及びMN2からのシグナリングが行える。ローカルPDN接続の新たなIPアドレスを使用してMN1とMN2とのセッションを再確立するためのエンドツーエンドシグナリングを避けるため、図12について説明したように、MN1とMN2の間での第1通信オプション及び第2の通信オプションが適用される。
ローカル経由のトラフィック用の新たなGTPトンネルがRNとL−SGWとの間に確立されるものと想定されている。しかし、前記実施形態について既に記載したように、その代わりにホーム経由のトラフィック用トンネルを再使用してもよい。この場合は、RN及びSPGW_RN内に適切なルーティングエントリを定義する必要がある。
図15及び図16に、図14のひとつの代替形態が提示されている。このシナリオは極めて類似しているが、以下にさらに詳細に説明するようにL−SGW及びL−PGWに関してMMEによってなされる決定は異なっている。
図15に示した実施形態によれば、MMEはSPGW_RNとコロケートされるL−SGWとL−PGWとを決定してもよい。この場合は、L−PGWがSPGW_RNとコロケートされるため、MN1のIPアドレスはSGW2のIPプレフィックス上にではなく、SPGW_RNのIPプレフィックス上に構成される。この相違点を除けば、本発明の実施形態は、同一であり、ローカル経由のデータパスを経てデータパケットをMN1とMN2との間に転送するための2つのトンネルが確立されることである。
図16の実施形態では、MMEがL−PGW及びL−SGWとしてSGW2を決定するものと想定されている。この場合は、MMEは依然としてRNに対してMN1のトラフィック用のS1−Uトンネルを確立するように指示しなければならないが、この場合はL−SPGW(SGW2)とトンネルが確立される。MN1のトラフィックのS1−Uトンネルは依然としてDeNBとSPGW_RNとの間のRN1のS1トンネルを飛び越える。
前述の「背景技術」の項における説明は、本願で説明されている特定の実施形態の例をよりよく理解できるようにすることを目的としており、ここで説明されている移動通信ネットワークの処理と機能の特定の実施内容に本発明を限定するものと解釈すべきではない。しかし、本願で提案されている改良は「背景技術」の項で説明しているアーキテクチャ/システムに容易に適用でき、本発明の一部の実施形態においてはこれらのアーキテクチャ/システムの標準的な手順及び改良された手順を利用できる。当業者は、本発明に対する特定の実施形態に示されているように、広く知られている本発明の精神及び範囲を逸脱することなく、各種の変更や修正が本発明に対して行われていることを理解するだろう。
本発明の別の実施形態は、ハードウェア及びソフトウェアを使用した、上述の様々な実施形態の実施に関する。演算装置(プロセッサ)を使用して本発明の様々な実施形態を実施又は実行できることが分かる。演算装置又はプロセッサは、例えば汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、又はその他のプログラム可能論理デバイスなどであってもよい。さらに、本発明の様々な実施形態は、これらの装置の組合せによって実行又は実施してもよい。
さらに、本発明の様々な実施形態は、ソフトウェアモジュールによって実施してもよい、それは、プロセッサ又は直接的にハードウェアで実行される。また、ソフトウェアモジュールとハードウェアの実装の組合せも可能である。ソフトウェアモジュールは、例えばRAM、EPROM、EEPROM、フラッシュメモリ、レジスタ、ハードディスク、CD−ROM、DVDなどのあらゆる種類のコンピュータで読取り可能な記憶媒体に格納してもよい。

Claims (19)

  1. データパケットを通信システム内の第2の通信ノードと交換する通信ノードであって、前記通信ノードが外部ネットワーク内に位置し、前記通信ノードは、
    前記ローカル接続要求を前記外部ネットワーク内の前記通信ノードのマネジメントエンティティに送信し、前記ローカル接続要求は前記第2の通信ノードの識別情報を含んでおり、特に、前記外部ネットワーク内のローカルデータゲートウェイが前記第2の通信ノードのゲートウェイであるか、前記外部ネットワーク内の前記第1の通信ノードのゲートウェイであるかを判定するため、前記ローカル接続要求及び前記第2の通信ノードの構成識別情報が前記マネジメントエンティティによって使用されることを適合した送信機を備える通信ノード。
  2. 前記通信ノードがホームIPアドレスを有し、前記ローカルデータゲートウェイ又は前記マネジメントエンティティから前記ローカルデータゲートウェイに関するIPアドレス情報を受信するように適用された受信機をさらに備え、
    前記通信ノードのプロセッサが、前記ローカルデータゲートウェイに関する前記IPアドレス情報に基づいて、前記通信ノードのための新たなローカルIPアドレスを構成するように適用され、
    前記送信機が、前記ホームIPアドレスを用いて前記第2の通信ノードにデータパケットを送信し、かつ、前記通信ノードの前記ローカルIPアドレスを用いて別の通信ノードにデータパケットを送信するようにさらに適用される、請求項に記載の通信ノード。
  3. 前記マネジメントエンティティに送信される前記ローカル接続要求が、前記通信ノードがアタッチされるセルのセル識別子をさらに含む、請求項又はに記載の通信ノード。
  4. 前記通信ノードが中継ノードにアタッチされ、前記通信ノードから及び前記通信ノードへのデータパケットが前記中継ノードと中継ノードゲートウェイの間でトンネリングされ、前記通信ノードは、
    前記中継ノードにアタッチされる前記通信ノードに関する情報を前記通信ノードの前記マネジメントエンティティに送信するように適用される前記送信機と、を含む請求項に記載の通信ノード。
  5. 通信システムの第1の通信ノードと第2の通信ノードとの間でデータパケットが交換されるデータ経路を最適化する方法であって、少なくとも前記第1の通信ノードは外部ネットワーク内に位置しており、当該方法は、
    前記第1の通信ノードから、前記外部ネットワーク内の前記第1の通信ノードのマネジメントエンティティに対して、前記第2の通信ノードの識別情報を含むローカル接続要求を送信するステップと、
    前記受信したローカル接続要求に応答して、前記外部ネットワーク内の前記マネジメントエンティティが前記第2の通信ノードの前記識別情報に基づいて前記外部ネットワーク内のローカルデータゲートウェイを決定するステップであって、前記ローカルデータゲートウェイが、前記外部ネットワーク内の前記第2の通信ノードのゲートウェイ、又は前記外部ネットワーク内の前記第1の通信ノードのゲートウェイであることが決定されるステップと、
    前記第1及び第2の通信ノード間のすべてのデータパケットを、前記ローカルデータゲートウェイを介して交換するステップと、
    を含む方法。
  6. 前記ローカルデータゲートウェイが前記第2の通信ノードにより使用される前記ゲートウェイであり、当該方法は、
    前記第1の通信ノードが、前記外部ネットワーク内にアタッチされる無線制御エンティティと前記ローカルデータゲートウェイとの間にトンネルを確立するステップであって、前記データパケットが、前記確立されたトンネルを経て、前記無線制御エンティティと前記ローカルデータゲートウェイとの間で転送されるステップと、
    をさらに含む、請求項に記載の方法。
  7. 前記外部ネットワーク内の前記マネジメントエンティティが、前記無線制御エンティティ及び前記ローカルデータゲートウェイに対して双方の間に前記トンネルを確立するように指示する、請求項に記載の方法。
  8. 前記外部ネットワーク内の前記マネジメントエンティティが、前記第2の通信ノードの前記識別情報に基づいて、前記第2の通信ノードによって使用される前記ゲートウェイを決定する、請求項又はに記載の方法。
  9. 前記第2の通信ノードの前記識別情報がIP(インターネットプロトコル)アドレスであり、前記外部ネットワーク内の前記マネジメントエンティティが、前記第2の通信ノードによって使用されるゲートウェイを前記第2の通信ノードの前記IPアドレスの前記IPプレフィックスから推測する、請求項に記載の方法。
  10. 前記外部ネットワーク内の前記マネジメントエンティティが、前記第2の通信ノードのマネジメントエンティティに要求を送信し、前記第2の通信ノードの前記マネジメントエンティティが、前記第2の通信ノードにより使用される前記ゲートウェイの情報を前記第1の通信ノードの前記マネジメントエンティティに送信する、請求項に記載の方法。
  11. 前記第1の通信ノードによって前記第2の通信ノードにゲートウェイ検出メッセージを送信するステップと、
    前記第1の通信ノードと前記第2の通信ノードの間の前記データ経路上の傍受エンティティによって前記ゲートウェイ検出メッセージを傍受し、それに応答して、前記第2の通信ノードが使用する前記ゲートウェイに関する情報を含む前記第1の通信ノードにゲートウェイ検出応答メッセージを送信するステップとをさらに含み、
    前記第1の通信ノードから前記第1の通信ノードの前記マネジメントエンティティに送信される前記ローカルゲートウェイ要求が、前記第2の通信ノードによって使用される前記ゲートウェイに関する前記受信した情報を含み、
    前記第2の通信ノードによって使用される前記ゲートウェイが、前記ローカルゲートウェイ要求で受信した前記第2の通信ノードによって使用される前記ゲートウェイの情報に基づいて前記マネジメントエンティティによって決定される、
    請求項に記載の方法。
  12. 前記第2の通信ノードから発信され、かつ、前記第1の通信ノードの前記ホームアドレスを宛先とするデータパケットを、前記確立されたトンネルを使用して前記ローカルデータゲートウェイから前記無線制御エンティティに転送するために、前記無線制御エンティティへの前記確立されたトンネルと前記第1の通信ノードの前記ホームアドレスとを関連付けるルーティングエントリを、前記ローカルデータゲートウェイ内で定義するステップをさらに含む、請求項から11のいずれか1つに記載の方法。
  13. 前記ローカルデータゲートウェイが前記第2の通信ノードによって使用されるゲートウェイであり、前記第1の通信ノードのサービングゲートウェイが、前記マネジメントエンティティによって前記第1の通信ノードの前記ローカルサービングゲートウェイであることが決定され、
    前記外部ネットワーク内の前記第1の通信ノードの前記サービングゲートウェイと前記ローカルデータゲートウェイとの間にトンネルを確立するステップであって、前記データパケットが、前記確立されたトンネルを経て、前記サービングゲートウェイと前記ローカルデータゲートウェイとの間に転送されるステップと、
    前記第1の通信ノードが前記外部ネットワーク内にアタッチされる無線制御エンティティと前記第1の通信ノードの前記サービングゲートウェイとの間に第2のトンネルを確立するステップであって、前記データパケットが、前記確立された第2のトンネルを経て、前記無線制御エンティティと前記第1の通信ノードの前記サービングゲートウェイとの間に転送されるステップと、
    をさらに含む、請求項に記載の方法。
  14. 前記第1の通信ノードの前記マネジメントエンティティが、前記ローカルデータゲートウェイとの前記トンネルを確立するように、前記サービングゲートウェイに指示し、かつ、前記第2のトンネルを確立するように、前記サービングゲートウェイ及び前記無線制御エンティティに指示する、請求項13に記載の方法。
  15. 前記第2の通信ノードから発信され、かつ、前記第1の通信ノードの前記ホームアドレスを宛先とするデータパケットを、前記確立されたトンネルを使用して前記ローカルデータゲートウェイから前記サービングゲートウェイに転送するために、前記第1の通信ノードの前記ホームアドレスを、前記サービングゲートウェイへの前記確立されたトンネルと関連付けるルーティングエントリを前記ローカルデータゲートウェイ内で定義するステップと、
    前記第1の通信ノードの前記ホームアドレスを前記無線制御エンティティへの前記確立された第2のトンネルと関連付ける別のルーティングエントリを前記第1の通信ノードの前記サービングゲートウェイ内で定義するステップと、
    前記第2の通信ノードの前記ホームアドレスを前記ローカルデータゲートウェイへの前記確立されたトンネルと関連付ける別のルーティングエントリを前記第1の通信ノードの前記サービングゲートウェイ内で定義するステップと、
    前記第2の通信ノードの前記ホームアドレスを前記第1の通信ノードの前記サービングゲートウェイへの前記確立された第2のトンネルと関連付ける別のルーティングエントリを前記無線制御エンティティ内で定義するステップと、
    をさらに含む、請求項13又は14に記載の方法。
  16. 前記第1の通信ノードが中継ノードにアタッチされ、前記第1の通信ノードから及び前記第1の通信ノードへのデータパケットが、前記中継ノードと、前記第1の通信ノードの前記サービングゲートウェイである中継ノードゲートウェイとの間でトンネリングされ、前記ローカルデータゲートウェイが前記第2の通信ノードによって使用される前記ゲートウェイであることが決定されており、当該方法は、
    前記第1の通信ノードの前記マネジメントエンティティによって前記ローカルデータゲートウェイへのトンネルを確立するように、前記中継ノードゲートウェイに指示するステップをさらに含む、請求項に記載の方法。
  17. 前記第1の通信ノード又は前記中継ノードによって、前記第1の通信ノードのマネジメントエンティティに、前記中継ノードにアタッチされる前記第1の通信ノードに関する情報を送信するステップと、
    前記中継ノードに関する受信した情報に基づいて、前記第1の通信ノードの前記マネジメントエンティティによって前記中継ノードゲートウェイを決定するステップと、
    をさらに含む、請求項16に記載の方法。
  18. 前記マネジメントエンティティに報知するステップが、前記第1の通信ノードの前記マネジメントエンティティに前記中継ノードのアクセスポイント名を送信することを含み、前記中継ノードゲートウェイを決定するステップが、前記中継ノードの前記アクセスポイント名に基づいて行われる、請求項17に記載の方法。
  19. 前記ローカルデータゲートウェイが、前記外部ネットワーク内の前記第1の通信ノードの位置に関する情報に基づいて、前記外部ネットワーク内の前記第1の通信ノードによって使用される前記ゲートウェイであることが決定されており、当該方法は、
    前記第1の通信ノードの前記マネジメントエンティティによって、前記第2の通信ノードの前記識別情報に基づいて、前記外部ネットワーク内の前記第2の通信ノードのゲートウェイを決定するステップと、
    データパケットを前記ローカルデータゲートウェイと前記第2の通信ノードの前記ゲートウェイの間に転送するため、前記ローカルデータゲートウェイと前記外部ネットワーク内の前記第2の通信ノードの前記ゲートウェイの間にトンネルを確立するステップと、
    をさらに含む、請求項に記載の方法。
JP2012505095A 2009-04-20 2010-04-19 ルート最適化エージェントを使用した通信ノード間のデータパスのルート最適化 Expired - Fee Related JP5438209B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20090005529 EP2244495B1 (en) 2009-04-20 2009-04-20 Route optimazion of a data path between communicating nodes using a route optimization agent
EP09005529.4 2009-04-20
PCT/EP2010/002389 WO2010121771A2 (en) 2009-04-20 2010-04-19 Route optimization of a data path between communicating nodes using a route optimization agent

Publications (2)

Publication Number Publication Date
JP2012524437A JP2012524437A (ja) 2012-10-11
JP5438209B2 true JP5438209B2 (ja) 2014-03-12

Family

ID=41087400

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012505095A Expired - Fee Related JP5438209B2 (ja) 2009-04-20 2010-04-19 ルート最適化エージェントを使用した通信ノード間のデータパスのルート最適化

Country Status (4)

Country Link
US (1) US8737371B2 (ja)
EP (2) EP2244495B1 (ja)
JP (1) JP5438209B2 (ja)
WO (1) WO2010121771A2 (ja)

Families Citing this family (60)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2091204A1 (en) 2008-02-18 2009-08-19 Panasonic Corporation Home agent discovery upon changing the mobility management scheme
US10893556B2 (en) 2009-04-30 2021-01-12 Samsung Electronics Co., Ltd Method and apparatus for supporting local IP access in a femto cell of a wireless communication system
EP2443897A1 (en) * 2009-06-18 2012-04-25 Telefonaktiebolaget L M Ericsson (PUBL) Method and arrangements in a mobile telecommunications system
US20130104207A1 (en) * 2010-06-01 2013-04-25 Nokia Siemens Networks Oy Method of Connecting a Mobile Station to a Communcations Network
KR101696472B1 (ko) * 2010-06-18 2017-01-16 삼성전자주식회사 이동 통신 시스템에서 로컬 라우팅 장치 및 방법
US10028138B2 (en) * 2010-09-29 2018-07-17 Cassidian Sas Method for attachment and authentication of a user terminal with a visited network
EP2625826B1 (en) * 2010-10-06 2016-01-06 Nokia Solutions and Networks Oy Subscriber handling in radio telecommunication networks
US9596597B2 (en) * 2010-11-05 2017-03-14 Nokia Technologies Oy Mobile security protocol negotiation
US9668199B2 (en) * 2010-11-08 2017-05-30 Google Technology Holdings LLC Wireless communication system, method of routing data in a wireless communication system, and method of handing over a wireless communication device, having an established data connection to a local network
US9743286B2 (en) * 2010-12-13 2017-08-22 Nec Corporation Gateway relocation control method and control device in mobile communication system
CN107750050B (zh) * 2011-01-06 2022-03-04 北京三星通信技术研究有限公司 一种支持用户设备ue移动性的方法和设备
EP2480045B1 (en) * 2011-01-13 2015-04-08 Alcatel Lucent Arrangement for providing functions of a mobile IP-CAN gateway and use of such arrangement for offloading traffic from said mobile IP-CAN
CN102158915B (zh) * 2011-02-17 2014-07-09 大唐移动通信设备有限公司 在切换时保持选择性ip流量分流连接的方法及装置
FR2973977B1 (fr) * 2011-04-07 2014-04-25 Commissariat Energie Atomique Procede et dispositif d'optimisation du routage d'un flux
US9014023B2 (en) 2011-09-15 2015-04-21 International Business Machines Corporation Mobile network services in a mobile data network
US20130070727A1 (en) * 2011-09-19 2013-03-21 Alcatel-Lucent Usa Inc. Mechanism to improve handover speed in small cells
EP2764641B1 (en) * 2011-10-03 2019-12-18 Intel Corporation Device to device (d2d) communication mechanisms
WO2013060488A1 (en) * 2011-10-24 2013-05-02 Nec Europe Ltd. Per - host locator to enable mobility gateway relocation
EP2795933A4 (en) * 2011-12-23 2015-12-30 Nokia Technologies Oy METHOD AND DEVICE FOR TRAFFIC DISCHARGE
FR2987540B1 (fr) * 2012-02-28 2016-05-13 Commissariat Energie Atomique Methode et systeme de gestion de la mobilite d'un reseau mobile
US9094309B2 (en) * 2012-03-13 2015-07-28 International Business Machines Corporation Detecting transparent network communication interception appliances
US10051686B2 (en) 2012-05-04 2018-08-14 Qualcomm Incorporated Charging over a user-deployed relay
EP2683211B1 (en) * 2012-07-02 2021-04-07 Alcatel Lucent Support of data transmission in a packet mobile network
US8897160B2 (en) 2012-07-06 2014-11-25 International Business Machines Corporation IP flow based offload for subscriber data optimization and scheduling at the basestation in a mobile data network
EP2883384B1 (en) 2012-08-10 2019-10-16 iBasis, Inc. Signaling traffic reduction in mobile communication systems
CN103686671B (zh) * 2012-09-14 2019-01-18 中兴通讯股份有限公司 一种通知接入网位置信息的方法和系统
JP5483657B1 (ja) * 2012-09-28 2014-05-07 ソフトバンクモバイル株式会社 通信システム、ggsn、pgw、及びプログラム
CN104205949B (zh) * 2012-11-28 2018-07-13 华为技术有限公司 一种移动网络通信方法、通信装置及通信系统
JP5958315B2 (ja) * 2012-12-07 2016-07-27 富士通株式会社 ネットワークシステム、オフロード装置、及びネットワークシステムにおけるトラヒックの制御方法
US9788188B2 (en) 2012-12-14 2017-10-10 Ibasis, Inc. Method and system for hub breakout roaming
US9060308B2 (en) 2013-01-11 2015-06-16 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Avoiding network address translation in a mobile data network
US9871766B2 (en) 2013-03-15 2018-01-16 Hewlett Packard Enterprise Development Lp Secure path determination between devices
US10027586B2 (en) * 2013-03-15 2018-07-17 Star2Star Communications, LLC Network address family translation method and system
KR102054195B1 (ko) * 2013-07-02 2019-12-11 삼성전자 주식회사 이동 통신 시스템에서 데이터 경로 최적화 방법 및 장치
US9398515B2 (en) * 2013-10-17 2016-07-19 Telefonaktiebolaget L M Ericsson (Publ) VPNv4 route control for LTE X2 SON using import route maps and outbound route filtering
US9264971B2 (en) 2013-10-17 2016-02-16 Telefonaktiebolaget L M Ericsson (Publ) VPNv4 route control for LTE X2 son using unique route targets
US9294986B2 (en) 2013-10-17 2016-03-22 Telefonaktiebolaget L M Ericsson (Publ) Topology discovery based on explicit signaling
US9641422B2 (en) 2013-10-17 2017-05-02 Telefonaktiebolaget Lm Ericsson (Publ) X2 son for LTE networks through automated X2 address discovery
US9288686B2 (en) 2013-10-17 2016-03-15 Telefonaktiebolaget L M Ericsson (Publ) Topology discovery based on SCTP/X2 snooping
EP3086599A4 (en) * 2013-12-20 2017-06-07 Kyocera Corporation Communication control method, gateway device, and user terminal
US9602343B1 (en) 2013-12-30 2017-03-21 Google Inc. System and method for establishing connection with network controller
US9380513B2 (en) 2014-05-16 2016-06-28 Qualcomm Incorporated Reducing broadcast duplication in hybrid wireless mesh protocol routing
US9392525B2 (en) 2014-05-16 2016-07-12 Qualcomm Incorporated Establishing reliable routes without expensive mesh peering
CN105324971B (zh) * 2014-05-23 2019-03-08 华为技术有限公司 一种绑定注册和数据转发方法、相关设备及网络系统
US10575165B2 (en) * 2014-09-01 2020-02-25 Telefonaktiebolaget Lm Ericsson (Publ) Routing based on access point name (APN) information
US10356689B2 (en) 2015-03-06 2019-07-16 Futurewei Technologies, Inc. Method and system with separation of session anchor and forwarding anchor
JP2018093252A (ja) * 2015-04-07 2018-06-14 シャープ株式会社 端末装置、mme、pgw、及び通信制御方法
JP6451850B2 (ja) * 2015-07-17 2019-01-16 日本電気株式会社 通信システム、通信装置、通信方法、端末、プログラム
WO2017018968A1 (en) * 2015-07-24 2017-02-02 Intel IP Corporation Apparatus, system and method of communicating between a cellular manager and a user equipment (ue) via a wlan node
US10298489B2 (en) * 2015-07-24 2019-05-21 International Business Machines Corporation Adding multi-tenant awareness to a network packet processing device on a software defined network (SDN)
US9723155B2 (en) * 2015-07-27 2017-08-01 Verizon Patent And Licensing Inc. Systems and method for offloading communication sessions to local network resources
US10470031B2 (en) 2016-05-20 2019-11-05 Ibasis, Inc. Voice over IMS roaming gateway
KR102198409B1 (ko) * 2016-06-08 2021-01-05 후아웨이 테크놀러지 컴퍼니 리미티드 사용자 평면 베어러 셋업 방법, 장치, 및 시스템
KR102408155B1 (ko) 2016-07-18 2022-06-14 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘) 비밀 식별자를 사용하는 사용자 장비에 관련된 동작
US10172067B2 (en) * 2016-09-07 2019-01-01 Nokia Of America Corporation Bypassing external packet data networks in mobile-to-mobile communication
US10263951B2 (en) * 2017-01-09 2019-04-16 Star2Star Communications, LLC Network address family translation method and system
US9924344B1 (en) * 2017-06-14 2018-03-20 Syniverse Technologies, Llc Method for providing roaming services in which the home network uses S8HR model for out-bound roaming while the visited network uses LBO model for in-bound roaming
WO2020146328A1 (en) * 2019-01-08 2020-07-16 Mavenir Networks, Inc. Method and apparatus for user plane resource selection for 5g core
CN112887209B (zh) * 2019-11-30 2023-06-20 华为技术有限公司 关于数据传输的表项建立方法及相关设备
US11671818B1 (en) * 2021-04-29 2023-06-06 T-Mobile Usa, Inc. Reliable local breakout for roaming devices

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3636637B2 (ja) * 2000-05-30 2005-04-06 三菱電機株式会社 経路最適化方法
US7349377B2 (en) * 2001-11-09 2008-03-25 Nokia Corporation Method, system and system entities for providing location privacy in communication networks
WO2004064337A1 (de) * 2003-01-09 2004-07-29 Siemens Aktiengesellschaft Verfahren und mobilfunktelekommunikationsnetz zur übertragung von paketdaten
GB2403097A (en) * 2003-06-16 2004-12-22 Orange Personal Comm Serv Ltd Communicating internet packets having care-of-address as destination address to a mobile node
EP1863252B1 (en) * 2006-05-29 2010-03-17 Panasonic Corporation Mobile IP route optimisation in IP protocol version transition scenarios
JP5048761B2 (ja) * 2006-05-29 2012-10-17 パナソニック株式会社 通信セッションのためのロケーション・プライバシーとルート最適化とを同時に実施する方法及び装置
ATE522065T1 (de) * 2006-05-29 2011-09-15 Panasonic Corp Verfahren und vorrichtung zur routen-optimierung in mobile ipv6 ohne bekanntgabe des aufenthaltsortes
WO2009024182A1 (en) 2007-08-20 2009-02-26 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for providing local breakout in a mobile network

Also Published As

Publication number Publication date
WO2010121771A2 (en) 2010-10-28
EP2244495B1 (en) 2012-09-19
US20120044949A1 (en) 2012-02-23
EP2422535B1 (en) 2017-04-05
EP2244495A1 (en) 2010-10-27
EP2422535A2 (en) 2012-02-29
WO2010121771A3 (en) 2010-12-16
JP2012524437A (ja) 2012-10-11
US8737371B2 (en) 2014-05-27

Similar Documents

Publication Publication Date Title
JP5438209B2 (ja) ルート最適化エージェントを使用した通信ノード間のデータパスのルート最適化
US8804682B2 (en) Apparatus for management of local IP access in a segmented mobile communication system
US8781474B2 (en) Non-3GPP to 3GPP network handover optimizations
EP2353271B1 (en) Secure tunnel establishment upon attachment or handover to an access network
US8964695B2 (en) Optimization of handovers to untrusted non-3GPP networks
US9769852B2 (en) Maintaining current cell location information in a cellular access network
US20110103260A1 (en) Binding cache creating method, binding cache creating system, home agent, and mobile node
JP2012531770A (ja) ハンドオーバープロキシノードを介したvplmn間ハンドオーバー
US20110299463A1 (en) Optimized home link detection
US20100097992A1 (en) Network controlled overhead reduction of data packets by route optimization procedure
EP1884089A2 (en) METHOD, SYSTEM AND APPARATUS FOR LOAD BALANCING OF WIRELESS SWITCHES TO SUPPORT LAYER 3 ROAMING IN WIRELESS LOCAL AREA NETWORKS (WLANs)
US20100046558A1 (en) Header reduction of data packets by route optimization procedure
WO2010146815A1 (ja) 移動管理プロトコル選択方法、移動管理プロトコル選択システム、モバイルノード、ホームエージェント及び代理ノード
Ali-Yahiya et al. Mobility

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130125

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: 20131126

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131212

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees