لن يكون PATENTSCOPE متاحًا لعدة ساعات لأسباب الصيانة على الثلاثاء 19.11.2019 16:00 CET
البحث في مجموعات البراءات الوطنية والدولية
بعض محتويات هذا التطبيق غير متوفرة في الوقت الحالي.
إذا استمرت هذه الحالة ، يرجى الاتصال بنا علىتعليق وإتصال
1. (JP2008517516) 媒体非依存事前認証改善策のフレームワーク
Document

Description

Title of Invention 媒体非依存事前認証改善策のフレームワーク US 60/698,949 20050714 US 11/279,856 20060414 20110810 H04W4/00-H04W99/00 H04B7/24-H04B7/26 特開2004−007576(JP,A) 特開2003−284117(JP,A) 特表2007−511147(JP,A) 国際公開第01/058182(WO,A1) 国際公開第2005/051026(WO,A1) 米国特許第06879830(US,B1) W. Teerapabkajorndet el at.,Comaprison of Performance of Location-Aware and Traditional Handoff-Decision Algorithm in CDPD Networks,IEEE VTC conference 2001,米国,IEEE,2001年,VOl.1,PP212-216 W. Teerapabkajorndel et al.,Throughput consideration for location-aware handoff in mobile data networks,IEEE International Symposium in Personal, Indoor and Mobile Radio Communications,米国,IEEE,2002年 9月15日,VOL.5,PP2223-2227 S. Kyriazakos et al.,Optimization of the handover algorithm based on the position of the mobile terminals,IEEE Symposium on Communications and Vehicular Technology,米国,IEEE,2000年10月19日,PP155-159 Hyunjeong Kang et al.,Resource Remain type for Drop or Ping Pong Call Recovery,Contiribution IEEE 802.16e/D1-2004 ,IEEE,2004年 3月 5日,PP0-4,http://grouper.ieee.org/groups/802//16/tge/contrib/C80216e-04_25.pdf Wen-Tsuen Chen et al.,Active Application Oriented Vertical Handoff in Next-Generation Wireless Networks,IEEE Conference on Wireless Communications and Networking ,米国,IEEE,2005年 3月13日,Vol.3,PP1383-1388 JP2006314312 20060713 WO2007007914 20070118 2008517516 20080522 20070417 望月 章俊

Technical Field

0001  

Background Art

0002   0003   0004   0005   0006   0007   0008   0009   0010   0011   0012   0013   0014   0015   0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100   0101   0102   0103   0104   0105   0106   0107   0108   0109   0110   0111   0112   0113   0114   0115   0116   0117   0118   0119  

Disclosure of Invention

Technical Problem

0120  

Technical Solution

0121   0122   0123   0124   0125  

Best Mode for Carrying out the Invention

0126   0127   0128   0129   0130   0131   0132   0133   0134   0135   0136   0137   0138   0139   0140   0141   0142   0143   0144   0145   0146   0147   0148   0149   0150   0151   0152   0153   0154   0155   0156   0157   0158   0159   0160   0161   0162   0163   0164   0165   0166   0167   0168   0169   0170   0171   0172   0173   0174   0175   0176   0177   0178   0179   0180   0181   0182   0183  

Brief Description of Drawings

0184  

Claims

1   2   3   4   5   6   7   8   9   10   11   12   13  

Drawings

1   2   3   4    

Description

媒体非依存事前認証改善策のフレームワーク

US 60/698,949 20050714 US 11/279,856 20060414 20110810 H04W4/00-H04W99/00 H04B7/24-H04B7/26 patcit 1 : 特開2004−007576(JP,A)
patcit 2 : 特開2003−284117(JP,A)
patcit 3 : 特表2007−511147(JP,A)
patcit 4 : 国際公開第01/058182(WO,A1)
patcit 5 : 国際公開第2005/051026(WO,A1)
patcit 6 : 米国特許第06879830(US,B1)
nplcit 1 : W. Teerapabkajorndet el at.,Comaprison of Performance of Location-Aware and Traditional Handoff-Decision Algorithm in CDPD Networks,IEEE VTC conference 2001,米国,IEEE,2001年,VOl.1,PP212-216
nplcit 2 : W. Teerapabkajorndel et al.,Throughput consideration for location-aware handoff in mobile data networks,IEEE International Symposium in Personal, Indoor and Mobile Radio Communications,米国,IEEE,2002年 9月15日,VOL.5,PP2223-2227
nplcit 3 : S. Kyriazakos et al.,Optimization of the handover algorithm based on the position of the mobile terminals,IEEE Symposium on Communications and Vehicular Technology,米国,IEEE,2000年10月19日,PP155-159
nplcit 4 : Hyunjeong Kang et al.,Resource Remain type for Drop or Ping Pong Call Recovery,Contiribution IEEE 802.16e/D1-2004 ,IEEE,2004年 3月 5日,PP0-4,http://grouper.ieee.org/groups/802//16/tge/contrib/C80216e-04_25.pdf
nplcit 5 : Wen-Tsuen Chen et al.,Active Application Oriented Vertical Handoff in Next-Generation Wireless Networks,IEEE Conference on Wireless Communications and Networking ,米国,IEEE,2005年 3月13日,Vol.3,PP1383-1388
JP2006314312 20060713 WO2007007914 20070118 2008517516 20080522 20070417 望月 章俊

Technical Field

[0001]
本願は、例えば媒体非依存事前認証等のための方法を含む、事前認証のための方法に関する。

Background Art

[0002]
最も有名なインターネット(登録商標)とともに多様な種類のコンピュータネットワークがある。インターネットはコンピュータネットワークの世界的なネットワークである。今日、インターネットは何百万ものユーザが使用できる公開された自立したネットワークである。インターネットはTCP/IP(つまり伝送制御プロトコル/インターネットプロトコル)と呼ばれている一式の通信プロトコルを使用して、ホストを接続する。インターネットはインターネットバックボーンとして公知の通信インフラストラクチャを有する。インターネットバックボーンに対するアクセスは、主として企業及び個人のアクセスをリセールするインターネットサービスプロバイダ(ISP)によって制御されている。
[0003]
IP(インターネットプロトコル)に関して、これは、あるデバイス(例えば、電話、PDA[パーソナルデジタルアシスタント]、コンピュータ等)からネットワーク上の別のデバイスにデータを送信できるプロトコルである。今日では、IPv4、IPv6等を含む種々のバージョンのIPがある。ネットワーク上の各ホストデバイスは、独自の一意の識別子である少なくとも1つのIPアドレスを有する。IPはコネクションレスプロトコルである。通信中のエンドポイント間の接続は連続ではない。ユーザがデータ又はメッセージを送信又は受信すると、このデータ又はメッセージはパケットとして知られている構成要素に分割される。あらゆるパケットはデータの独立した単位として取り扱われる。
[0004]
インターネット又は類似するネットワーク上でポイント間の伝送を標準化するために、OSI(開放型システム間相互接続)モデルが確立された。OSIモデルは、ネットワークの中の2つのポイントの間の通信プロセスを7つの積み重ねられた層に切り離し、それぞれの層が独自の機能のセットを追加する。各デバイスは、送信側エンドポイントにある各層を通る下降流と、受信側エンドポイントにある層を通る上昇流が存在するようにメッセージを処理する。機能の7つの層を提供するプログラミング及び/又はハードウェアは、通常は、デバイスオペレーティングシステム、アプリケーションソフトウェア、TCP/IP及び/又は他のトランスポートプロトコル及びネットワークプロトコル、ならびに他のソフトウェアとハードウェアの組み合わせである。
[0005]
通常、メッセージがユーザから又はユーザに渡されるときには上部4つの層が使用され、メッセージがデバイス(例えばIPホストデバイス)を通過するときには下部の3つの層が使用される。IPホストは、サーバ、ルータ、又はワークステーション等の、IPパケットを送信及び受信できるネットワーク上の任意のデバイスである。なんらかの他のホストに向けられるメッセージは上位層まで渡されないが、他のホストに転送される。OSIモデルの層は以下に一覧表示される。第7層(つまり、アプリケーション層)は、例えば通信パートナーが特定され、サービスの質が特定され、ユーザ認証とプライバシーが考慮され、データ構文に対する制約が特定される等の層である。第6層(つまり、プレゼンテーション層)は、例えば入信データと発信データをあるプレゼンテーションフォーマットから別のプレゼンテーションフォーマットに変換する等の層である。第5層(つまり、セッション層)は、例えばアプリケーション間の会話、交換及びダイアログをセットアップし、調整し、終了する等の層である。第4層(つまり、トランスポート層)は、例えばエンドツーエンド制御及びエラーチェックを管理する等の層である。第3層(つまり、ネットワーク層)は、例えばルーティングと転送を処理する等の層である。第2層(つまり、データリンク層)は、例えば物理レベルに同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識と管理を提供する等の層である。電気電子技術者協会(IEEE)は、データリンク層を2つの追加の副層、つまり物理層への及び物理層からのデータ転送を制御するMAC(媒体アクセス制御)層と、ネットワーク層と接続し、コマンドを解釈し、エラー回復を実行するLLC(論理リンク制御)層に再分割する。第1層(つまり、物理層)は、物理レベルでネットワークを通してビットストリームを伝達する等の層である。IEEEは、物理層をPLCP(物理層収束手順)副層と、PMD(物理媒体依存)副層に再分割する。
[0006]
無線ネットワーク:
無線ネットワークは、例えばセルラー電話と無線電話、PC(パソコン)、ラップトップコンピュータ、ウェアラブルコンピュータ、コードレスフォン、ページャ、ヘッドホン、プリンタ、PDA等の種々のタイプのモバイル機器を組み込むことができる。例えば、モバイル機器は、音声及び/又はデータの高速無線伝送を確保するためにデジタルシステムを含んでよい。典型的なモバイル機器は、以下の構成要素のいくつか又はすべてを含む。つまり、トランシーバ(つまり、例えば送信機、受信機、及び所望される場合他の機能が統合されたシングルチップトランシーバ等を含む送信機と受信機)、アンテナ、プロセッサ、1台又は複数台の音声トランスデューサ(例えば、音声通信用のデバイスにおいてのようなスピーカ又はマイク)、(例えば、ROM、RAM、データ処理が提供されるデバイスにおいてのようなデジタルデータ記憶装置等の)電磁データ記憶装置、メモリ、フラッシュメモリ、フルチップセット又は集積回路、(例えばUSB、CODEC、UART、PCM等の)インタフェース、及び/又は類似物である。
[0007]
携帯電話利用者が無線接続を通してローカルエリアネットワーク(LAN)に接続できる無線LAN(WLAN)は、無線通信のために利用されてよい。無線通信は、例えば、光、赤外線、無線、マイクロ波等の電磁波を介して伝搬する通信を含むことができる。ブルートゥース(登録商標)、IEEE802.11、及びHomeRF等、現在存在する種々のWLAN規格がある。
[0008]
一例として、ブルートゥース製品は、モバイルコンピュータ、携帯電話、ポータブル携帯端末、パーソナルデジタルアシスタント(PDA)及び他のモバイル機器の間にリンクを、インターネットに接続性を提供するために使用されてよい。ブルートゥースは、モバイル機器が短距離無線接続を使用して互いに、及び非モバイル機器とどのように容易に相互接続できるのかを詳説するコンピュータ電気通信業界の仕様である。ブルートゥースは、ある装置から別の装置でデータを同期及び一貫させる必要がある多様なモバイル機器の拡散から生じるエンドユーザ問題に対処するためにデジタル無線プロトコルを作成し、それにより様々なベンダの装置がともにシームレスに動作できるようにする。ブルートゥースデバイスは共通の命名概念に従って名前が付けられてよい。例えば、ブルートゥースデバイスはブルートゥースデバイス名(BDN)又は一意のブルートゥースデバイスアドレス(BDA)と関連付けられた名称を持つことができる。また、ブルートゥースデバイスは、インターネットプロトコル(IP)ネットワークに参加することもできる。ブルートゥースデバイスがIPネットワーク上で機能する場合、それにはIPアドレスとIP(ネットワーク)名が与えられてよい。したがって、IPネットワーク上で参加するように構成されたブルートゥースデバイスは、例えばBDN、BDA、IPアドレス、及びIP名を含んでよい。用語「IP名」はインタフェースのIPアドレスに対応する名称を指す。
[0009]
IEE規格であるIEEE802.11は、無線LANとデバイスのための技術を規定する。802.11を使用して、複数のデバイスをサポートしているそれぞれ単一の基地局との無線ネットワーキングが達成されてよい。いくつかの例では、デバイスは無線ハードウェアを事前に装備して納品されてよい、又はユーザがアンテナを含んでよいカード等の別個のハードウェアをインストールしてよい。一例として、802.11で使用されるデバイスは、通常、デバイスがアクセスポート(AP)であるのか、移動局(STA)であるのか、ブリッジであるのか、PCMCIAカードであるのか、又は別のデバイス、つまり無線トランシーバ、アンテナ及びネットワーク内のポイントの間のパケットの流れを制御するMAC(媒体アクセス制御)層であるのかに関係なく3つの注目すべき要素を含む。
[0010]
更に、いくつかの無線ネットワークではマルチプルインタフェースデバイス(MIDs)が活用されることがある。MIDはブルートゥースインタフェースと802.11インタフェース等の2つの独立したネットワークインタフェースを含んでよく、このようにしてMIDはブルートゥースデバイスと接続するだけではなく2つの別々のネットワークで参加することもできるようになる。MIDはIPアドレスと、このIPアドレスと関連付けられた共通IP(ネットワーク)名を有してよい。
[0011]
無線ネットワークデバイスは、ブルートゥースデバイス、マルチプルインタフェースデバイス(MID)、802.11xデバイス(例えば802.11a、802.11b及び802.11gのデバイスを含むIEEE 802.11デバイス)、HomeRF(ホーム無線周波数)デバイス、Wi−Fi(ワイヤレスフィディリティー)デバイス、GPRS(ジェネラルパケットラジオサービス)デバイス、3Gセルラーデバイス、2.5Gセルラーデバイス、GSM(グローバルシステムフォーモバイルコミュニケーションズ)デバイス、EDGE(Enhanced Data for GSM Evolution)デバイス、TDMAタイプ(時分割多元接続)デバイス、又はCDMA2000を含むCDMAタイプ(符号分割多元接続)デバイスを含んでよいが、これらに限定されない。それぞれのネットワークデバイスは、IPアドレス、ブルートゥースデバイスアドレス、ブルートゥース共通名、ブルートゥースIPアドレス、ブルートゥースIP共通名、802.11IPアドレス、802.11IP共通名、又はIEEE MACアドレスを含むが、これらに限定されない様々なタイプのアドレスを含んでよい。
[0012]
無線ネットワークは、例えばモバイルIP(インターネットプロトコル)システムにおいて、PCSシステムにおいて、及び他の携帯電話ネットワークシステムにおいて見られる方法及びプロトコルも含むことがある。モバイルIPに関して、これはインターネットエンジニアリングタスクフォース(IETF)により作成された標準通信プロトコルを含む。モバイルIPを使用すると、モバイル機器ユーザは、一度割り当てられた自分のIPアドレスを維持しながらネットワーク全体で移動することができる。リクエストフォーコメント(RFC)3344を参照されたい。注意:RFCはインターネットエンジニアリングタスクフォース(IETF)の公式文書である。モバイルIPはインターネットプロトコル(IP)を強化し、自らのホームネットワークの外部で接続するときにインターネットトラフィックをモバイル機器に転送する手段を追加する。モバイルIPは、各モバイルノードに、そのホームネットワークでのホームアドレスと、ネットワーク及びそのサブネットの中でのデバイスの現在位置を特定する気付アドレス(CoA)とを割り当てる。デバイスは別のネットワークに移動すると、それは新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは各ホームアドレスをその気付アドレスと関連付けることができる。モバイルノードは、それがその気付アドレスを例えばインターネットコントロールメッセージプロトコル(ICMP)を使用して変更するたびにホームエージェントにバインディングアップデートを送信できる。
[0013]
基本IPルーティング(例えば、モバイルIP外部)では、ルーティング機構は、各ネットワークノードが常に、例えばインターネットに対する一定の接続点を有し、それぞれのノードのIPアドレスが、それが接続されるネットワークリンクを特定するという仮定に依存している。本明細書では、用語「ノード」は、例えばデータ伝送のための再分布点又はエンドポイントを含むことがあり、他のノードへの通信を認識する、処理する、及び/又は転送することができる接続点を含む。例えば、インターネットルータは、デバイスのネットワークを特定する、例えばIPアドレス接頭辞等を見ることができる。次にルータは、ネットワークレベルで、特定のサブネットを特定するビットのセットを見ることができる。次にルータは、サブネットレベルで、特定のデバイスを特定するビットのセットを見ることができる。典型的なモバイルIP通信を用いる場合、ユーザが例えばインターネットからモバイル機器を切断し、新しいサブネットでそれを再接続しようと試みる場合、デバイスは新しいIPアドレス、適切なネットマスク及びデフォルトルータで再構成されなければならない。それ以外の場合、ルーティングプロトコルはパケットを適切に配信できないであろう。
[0014]
図4は、クライアントデバイスが通信する無線アクセスポイントを含む、いくつかの例示的且つ非限定的なインプリメンテーションで利用できるいくつかの例示的なアーキテクチャ構成要素を描いている。この点で、図4は、一般的に21で示される無線ローカルエリアネットワーク(WLAN)に接続されている例示的な有線ネットワーク20を示している。WLAN21はアクセスポイント(AP)22と、多くのユーザ局23、24を含む。例えば、有線ネットワーク20は、インターネット又は企業データ処理ネットワークを含むことがある。例えば、アクセスポイント22は、無線ルータである場合があり、ユーザ局23、24は例えば、ポータブルコンピュータ、デスクトップパソコン、PDA、ポータブルボイスオーバIP電話及び/又は他のデバイスである場合がある。アクセスポイント22は有線ネットワーク21にリンクされるネットワークインタフェース25と、ユーザ局23、24と通信する無線トランシーバとを有する。例えば、無線トランシーバ26は、ユーザ局23、25との無線通信又はマイクロ波振動数通信のためのアンテナ27を含むことがある。アクセスポイント22は、プロセッサ28と、プログラムメモリ29と、ランダムアクセスメモリ31も有する。ユーザ局23はアクセスポイント局22との通信用のアンテナ36を含む無線トランシーバ35を有する。同様に、ユーザ局24は、アクセスポイント22への通信用の無線トランシーバ38とアンテナ39を有する。
[0015]
本明細書に説明されている好ましい実施形態のいくつかでは、システム及び方法が様々な媒体のさらに高い層及びさらに低い層のコンテキストを積極的に確立するために説明されている。ここでは媒体は、例えばモバイル機器がアクセス可能な、使用可能なネットワーク(例えば、有線、認可された無線、無認可の無線等)を含む。例えば、I.E.E.E.802.21を含む、I.E.E.E.802に説明されている媒体を参照されたい。媒体は、例えば無線LAN(例えばI.E.E.E.802.11)、I.E.E.E.802.16、I.E.E.E.802.20、ブルートゥース等を含んでよい。いくつかの例示的な例は、1)例えば、セルラーインタフェースと無線インタフェース付きの、無線インタフェースを同時に確立するよりむしろ初期にセルラーネットワーク上で情報(例えば、キー等)を取得することによってWIFIアクセスを得ようとする、セルラーネットワークから無線又はWIFIネットワークに切り替えるモバイル機器、2)モバイル機器が現在無線又はWIFI接続性を有する場合、無線LANが潜在的に迅速に停止してよい等、その場合一例として、モバイル機器がセルラーネットワークを介して積極的に事前認証を行うことができる場合を含む。いくつかの例示的な場合、単一IEEE802.xxインタフェース付きのモバイルノードは複数のサブネットと複数の管理ドメインの間でローミングしてよい。複数のインタフェースを常時オンにしておくことは1つの選択肢であるが、モバイルノードは(例えば、節電するため等の)いくつかの例では使用されていないインタフェースを非活性化することを望む場合がある。加えて、MPAは、とりわけ、複数のインタフェースの使用だけではなくサブネット間のハンドオフ、ドメイン間のハンドオフ、技術間のハンドオフ等にも役立つ安全且つ途切れのないモビリティ最適化を実現できる。
[0016]
PANA:
参考のために、P.Jayaraman、「PANA Framework」、Internet-Draft、draft-ietf-pana-framework-01.txt、work in progress、2004年7月からのPANAに関する情報が本明細書の本項に組み込まれている。この点で、PANAは、ネットワークにアクセスを希望するノードとネットワーク側のサーバの間で実行するリンク層にとらわれないネットワークアクセス認証プロトコルである。PANAは新しいEAPを定義する[B.Abobaら、「Extensible Authentication Protool(EAP)」、RFC3748、2004年6月]、Aboba,B.、Blunk L.、Vollbrecht,J.、Carison,J.及びH.Levkowetz、Extensible Authentication Protocol(EAP)」、2004年6月、プロトコルエンドポイント間でIPを使用する下位層を参照されたい。
[0017]
このようなプロトコルと要件を定義するための動機は、Yegin,A.及びY.Ohba、Protocol for Carrying Authentication for Network Access(PANA)Requirements、draft-ietf-pana-requirements-08(work in progress)、2004年に説明されている。プロトコルの詳細は、Forsberg、D.、Ohba,Y.、Patil,B.、Tschofenig,H.及びA.Yegin、Protocol for Carrying Authentication for Network Access(Forsberg,D.、Ohba,Y.、Patil,B.、Tschofenig,H.及びA.Yegin、Protocol for Carrying Authentication for Network Access(PANA)、draft-ietf-pana-pana-04(work in progress)、2004年5月に文書化されている。Parthasarathy,M.、PANA Enabling IPsec Based Access Control、draft-ietf-pana-ipsec-03(work in progress)、2004年5月は、PANAをベースにした認証に続くアクセス制御のためのIPsecの使用を説明する。IPsecは、パケット単位のアクセス制御に使用できるが、それにも関わらずそれはこの機能性を達成する唯一の方法ではない。代替策は物理的セキュリティ及びリンク層暗号化を信頼することを含む。アクセス制御を施行しているエンティティからPANAサーバを分離することは、オプションの配備の選択肢として想定されてきた。SNMP[Mghazli,Y.、Ohba,Y.及びJ.Bournelle、SNMPUsage for PAA-2-EP Interface、draft-ietf-pana-snmp-00(work in progress)、2004年4月が、別々のノードの間で関連した情報を伝搬するためのプロトコルとして選ばれた。
PANA設計は、多様なタイプの配備にサポートを提供する。アクセスネットワークは、より下位の層のセキュリティの可用性、PANAエンティティの設置、クライアントIP構成の選択、及び認証方法等に基づいて異なることがある。
[0018]
PANAは根本的なセキュリティに関わりなく任意のアクセスネットワークで使用できる。例えば、ネットワークは物理的に保護される、つまりクライアント−ネットワークの認証が成功した後に暗号機構によって保護される可能性がある。
[0019]
PANAクライアント、PANA認証エージェント、認証サーバ、及び施行ポイントはこの設計では機能上のエンティティであった。PANA認証エージェント及び施行ポイントは、アクセスネットワーク内の多様な要素に(例えば、アクセスポイント、アクセスルータ、専用ホスト等)対して設置できる。
[0020]
IPアドレス構成機構も変化する。静的構成、DHCP、ステートレスアドレス自動構成が選ぶために考えられる機構である。クライアントがパケット単位のセキュリティを可能にするためにIPsecトンネルを構成する場合、該トンネルの内部でIPアドレスを構成することに意味があるようになり、これらに対してIKE等の追加の選択肢が存在する。
[0021]
PANAプロトコルはアクセスネットワークにおけるクライアントの認証と承認を容易にすることを目的としている。PANAはEAP[Aboba,B.、Blunk,L.、Vollbrecht,J.、Carlson,J.、及びH.Levkowetz、Extensible Authentication Protocol(EAP)、2004年6月である。Aboba,B.、Blunk,L.、Vollbrecht,J.、Carlson,J.及びH.Levkowetz、Extensible Authentication Protocol(EAP)、RFC3748、2004年6月、クライアントホストとアクセスネットワーク内のエージェントの間のEAPの内部にカプセル化されるEAP認証方法を搬送する下位層を参照されたい。PANAはこの2つのエンティティの間で認証プロセスを可能にするが、それは全体的なAAA及びアクセス制御フレームワークの一部にすぎない。PANAを使用するAAAとアクセス制御フレームワークは、後述されるように、及び図1(A)〜図1(C)に概略で描かれている4つの機能エンティティを含む。
[0022]
第1の機能エンティティはPANAクライアント(PaC)であり、PANAプロトコルのクライアントインプリメンテーションである。このエンティティは、ネットワークアクセスを要求しているエンドホスト上に常駐する。エンドホストは、例えば、ラップトップコンピュータ、PDA、携帯電話、デスクトップPC、及び/又は有線インタフェース又は無線インタフェースを介してネットワークに接続される類似物を含むことがある。PaCは、ネットワークアクセスを要求し、PANAプロトコルを使用して認証プロセスに従事することに関与する。
[0023]
第2の機能エンティティはPANA認証エージェント(PAA)であり、PANAプロトコルのサーバインプリメンテーションである。PAAはネットワークアクセスサービスについてそれらを認証し、承認するためにPaCと接続することを担当する。PAAはPaCの信用証明書及び権利を検証するために認証サーバに相談する。認証サーバがPAAと同じホストに常駐する場合は、アプリケーションプログラムインタフェース(API)がこの相互作用に十分である。それらが分離されると(パブリックアクセスネットワークではより一般的な場合)、プロトコルがこの2つの間で実行するために使用される。LDAPプロトコル[Hodges,J.、及びR.Morgan、Lightweight Directory Access Protocol(v3):Technical Specification、2002年9月を参照されたい。Hodges,J.及びR.Morgan、Lightweight Directory Access Protocol(v3):Technical Specification、RFC3377、2002年9月を参照されたい。]、及びRADIUS[Rigney,C.、Willens,S.、Rubens,A.及びW.Simpson、Remote Authentication Dial In User Service(RADIUS)、2000年6月。Rigney,C.、Willens,S.、Rubens,A.及びW.Simpson、Remote Authentication Dial In User Service(RADIUS)、RFC2865、2000年6月を参照されたい]のようなAAAプロトコル、及びDiameter[Calhoun,P.、Loughney,J.、Guttman,E.、Zorn,G.及びJ.Arkko、Diameter Base Protcol、2003年9月、Calhoun,P.、Loughney,J.、Guttman,E、Zorn,G.及びJ.Arkko、Diameter Base Protocol、RFC3588、2003年9月を参照されたい]が、この目的に一般的に使用されている。
[0024]
PAAは、認証状態の作成及び削除に応じてアクセス制御状態(つまり、フィルタ)を更新することにも関与する。PAAは更新された状態をネットワーク内の施行ポイントに通信する。PAAとEPが同じホスト上に常駐している場合、APIがこの通信にとって十分である。それ以外の場合、プロトコルはPAAからEPに許可されたクライアント属性を搬送するために使用される。他のプロトコルを禁止していないが、現在のSNMP[Mghazli,Y.、Ohba,Y.及びJ.Bournelle、SNMP Usage for PAA-2-EP Interface、draft-ietf-pana-snmp-00(work in progress)、2004年4月]がこのタスクに提案されていた。
[0025]
PAAは、通常、ローカルエリアネットワークの中のネットワークアクセスサーバ(NAS)と呼ばれるノードに常駐する。PAAはPaCと同じIPサブネット上の任意のIPによって可能にされたノード上で動作できる。例えば、DSLネットワークのBAS(ブロードバンドアクセスサーバ)で、又は3GPP2ネットワークのPDSNで等で動作できる。
[0026]
第3の機能エンティティは、ネットワークアクセスサービスを要求しているPaCの信用証明書の検証を担当するサーバインプリメンテーションである、認証サーバ(AS)である。ASはPaCの代わりにPAAから要求を受け取り、認証パラメータ(例えば、許可された帯域幅、IP構成等)とともに検証の結果をもって応答する。ASはPAAと同じホストで、アクセスネットワーク上の専用ホストで、あるいはインターネット上のどこかのセントラルサーバで動作できる可能性がある。
[0027]
第4の機能エンティティは、他者によるアクセスを妨げる一方で許可されたクライアントへのアクセスの許可を担当するアクセス制御インプリメンテーションである施行ポイント(EP)である。EPはPAAから許可されたクライアントの属性を学習する。EPは、非暗号フィルタ又は暗号フィルタを使用して選択的にデータパケットを許可し、廃棄する。これらのフィルタはリンク層又はIP層で適用されてよい。暗号アクセス制御を使用する場合、安全な関連プロトコルがPaCとEPの間で実行する必要がある。安全な関連プロトコルが完全性保護、データ発信元認証、再生保護及び任意に機密性保護を可能にするために必要なセキュリティ関連付け(security association)を確立した後、リンク又はネットワーク層保護(例えば、TKIP、IPsec ESP)が使用される。EPは、許可されていないクライアントのネットワークへのアクセスを最小限に抑えるためにローカルエリアネットワーク内に戦略的に配置されなければならない。例えば、EPは、有線ネットワーク内のクライアントに直接的に接続されているスイッチ上で動作できる。そのようにして、EPは、それらが他のクライアントホストに到達する前に、又はローカルエリアネットワークを越える前に許可されていないパケットを削除できる。
[0028]
エンティティのいくつかは、配備シナリオに応じて同一位置に配置されてよい。例えば、PAAとEPは、DSLネットワーク内の同じノード上にある可能性がある。その場合、PAAとEPの間では単一APIで十分である。小企業の配備ではPAAとASは、この2つの間で実行されるプロトコルに対する必要性を排除する同じノード(例えば、アクセスルータ)の上で動作してよい。これらのエンティティを同一位置に配置するという決定、又はそれ以外の場合、及びネットワークトポロジーの中のそれらの正確な位置が配備の決定である。
[0029]
安全な関連付けのためのIKE又は4通りのハンドシェイクプロトコルを使用すると、PANAを実行する前に任意の下位層セキュリティがない場合にだけ必要とされていた。(例えば、DSL等の)物理的に保護されたネットワーク又はPANAの前にリンク層ですでに暗号により保護されているネットワーク(例えば、cdma2000)は安全な関連付け及びパケット単位の暗号化を必要としない。これらのネットワークはPANAの認証と承認を、すでに使用できる下位層安全チャネルに結び付けることができる。
[0030]
アクセスネットワーク上のEPが任意の許可されたPaCからの一般的なデータトラフィックを可能にするのに対し、それは許可されていないPaCのための限られたタイプのトラフィック(例えば、PANA、DHCP、ルータ発見)だけを可能にする。これにより、新規に接続されたクライアントがPANAに従事するための最小のアクセスサービスを有し、無制限のサービスに対して許可されることが確実になる。
[0031]
PaCはPANAを実行する前にIPアドレスを構成する必要がある。PANA認証が成功した後、配備シナリオに応じて、PaCはそのIPアドレスを構成し直す、又は追加のIPアドレス(複数の場合がある)を構成する必要がある場合がある。追加のアドレス構成は、安全関連プロトコル実行の一部として実行されてよい。
[0032]
最初に許可されていないPaCは、アクセスネットワーク上でPAAを発見し、後にPANA上でのEAPの交換が続くことによってPANA認証を開始する。PAAはこのプロセスの間にASと相互に作用する。認証及び許可の結果をASから受信すると、PAAはPaCにそのネットワークアクセス要求の結果について知らせる。
[0033]
PaCがネットワークにアクセスすることを許可されている場合、PAAはSNMPを使用することによりEPにPaC特有の属性(例えば、IPアドレス、暗号キー等)も送信する。EPはPaCから及びPaCへのデータトラフィックが通過できるようにするためにそのフィルタを改変するためにこの情報を使用する。
[0034]
PANA認証後に暗号アクセス制御が可能にされる必要がある場合、安全関連プロトコルがPaCとEPの間で実行する。PaCはPANA交換が成功した結果としてすでにこのプロセスに対して入力パラメータを持つ必要がある。同様に、EPはSNMPを介してPAAからそれらを取得するべきだった。安全な関連付けの交換により、PaCとEPの間に必要とされるセキュリティ関連付けが生じ、暗号データトラフィック保護を可能にする。パケット単位の暗号データトラフィック保護が追加のパケット単位のオーバヘッドを導入するが、オーバヘッドはPaCとEPの間だけに存在し、EPを超えて通信に影響を及ぼさないであろう。この意味で、ネットワークの端の可能な限り近くにEPを配置することが重要である。
[0035]
最後に、データトラフィックが新規に許可されたPaCから及びPaCに流れ始めることができる。
[0036]
本発明への導入
セルラー及び無線LANを含む無線技術が一般的に使用されているので、例えば無線LANからCDMAに、又はGPRSに等の異なるタイプのアクセスネットワーク全体で端末ハンドオーバをサポートすることは明確な課題として考えられている。他方、同じタイプのアクセスネットワーク間で端末ハンドオーバをサポートすることは、特にハンドオーバがIPサブネット又は管理ドメインに渡るときには依然としてより挑戦的である。それらの課題に取り組むために、理不尽な複雑さを生じさせずに最適化され且つ安全な様式でリンク層技術にとらわれない端末移動性(terminal mobility)を与えることが重要である。本明細書では、低遅延及び低損失のシームレスハンドオーバを提供する端末移動性を論じる。シームレスハンドオーバは、以下の性能要件と題される次項に説明されるような性能要件に関して特徴付けられる。
[0037]
端末移動性の基本的な部分は、携帯端末のロケータと識別子の間のバインディングを維持する移動性管理プロトコルによって達成され、このバインディングは移動性バインディングと呼ばれる。モバイルノードのロケータは、携帯端末の移動があるときに動的に変化することがある。ロケータの変化を引き起こす該移動は物理的にだけではなく、論理的にも発生してよい。移動性管理プロトコルは任意の層で定められてよい。本明細書の残りでは、用語「移動性管理プロトコル」はネットワーク層又はさらに上位層で動作する移動性管理プロトコルを指す。
[0038]
様々な層にいくつかの移動性管理プロトコルがある。モバイルIP[RFC3344]及びモバイルIPv6[RFC3775]は、ネットワーク層で動作する移動性管理プロトコルである。IETFではネットワーク層より上位の層で移動性管理プロトコルを定義するためのいくつかの継続中の活動がある。例えば、MOBIKE(IKEv2 Mobility and Multihoming)[I-D.ietf-mobike-design]は、IKEv2エンドポイントのIPアドレスの変化に対応する能力を与えるIKEv2の拡張である。HP(ホストアイデンティティプロトコル)[I-D.ietf-hip-base]は、ネットワーク層とトランスポート層の両方にとってトランスペアレントであるように端末移動性を与えるためにネットワーク層とトランスポート層の間に新しいプロトコル層を定義する。また、SIP−モビリティは、SIPユーザエージェント[SIPMM]の移動性バインディングを維持するためのSIPに対する拡張である。
[0039]
移動性管理プロトコルは移動性バインディングを維持するが、それらをそれらの現在の形式だけで使用することは、シームレスハンドオーバを実現するために十分ではない。移動性バインディングを更新しながら、送信された未決パケットの損失を妨ぐために携帯端末のアクセスしたネットワークで作用する追加の最適化機構が、シームレスハンドオーバを達成するために必要とされる。このような機構が移動性最適化機構と呼ばれる。例えば、移動性最適化機構[I-D.ietf-mobileip-lowlatency-handoffs-v4]及び[I-D.ietf-mipshop-fast-mipv6]が、隣接するアクセスルータが携帯端末についての情報を通信し、搬送できるようにすることによって、それぞれモバイルIPv4とモバイルIPv6に定義される。
[0040]
移動性最適化機構の「ヘルパー」と見なされるプロトコルがある。CARD(候補アクセスルータ発見機構)プロトコル[I-D.ietf-seamoby-card-protocol]が近接するアクセスルータを発見するように設計される。CTP(コンテキスト転送プロトコル)[I-D.ietf-seamoby-ctp]は、アクセスルータの間で、携帯端末のために提供されるサービスに関連している状態、つまりコンテキストを搬送するように設計される。
[0041]
既存の移動性最適化機構(mobility optimization mechanisms)にはいくつかの問題点がある。第1に、既存の移動性最適化機構は特定の移動性管理プロトコルと密に結合している。例えば、MOBIKE用に、モバイルIPv4又はモバイルIPv6のために設計された移動性最適化機構を使用することはできない。強く所望されていることは、任意の移動性管理プロトコルと連動する単一の統一された移動性最適化機構である。第2に、管理ドメインの間で事前に確立されたセキュリティ関連付けを想定することなく、管理ドメイン全体でハンドオーバを容易にサポートする既存の移動性最適化機構はない。移動性最適化機構は、モバイルノードと各管理ドメインの間の信頼関係だけに基づいて安全に管理ドメイン全体で作用するべきである。第3に移動性管理機構は、マルチインタフェースを通じた複数の同時接続性を予想できるマルチインタフェース端末だけではなく、単一インタフェース端末もサポートする必要がある。
[0042]
本明細書は、それらすべての問題点に取り組む可能性がある新しいハンドオーバ最適化機構である媒体に依存しない事前認証(MPA)のフレームワークを説明している。MPAは任意のリンク層の上で、モバイルIPv4、モバイルIPv6、MOBIKE、HIP、SIPモビリティ等を含む任意の移動性管理プロトコルと連動するモバイル支援安全ハンドオーバ最適化方式である。MPAでは、IEEE 802.11i事前認証の概念がさらに上位の層で働くために拡張され、追加の機構が、携帯端末が依然として現在のネットワークに接続されている間のネットワークへの先を見越したハンドオーバだけではなく、携帯端末が移動するネットワークからのIPアドレスの早期獲得も実行する。本明細書はMPAフレームワークに焦点を当てている。このようなフレームワークを利用する際に、MPAのために選ばれるプロトコルの実際のセット、及び詳細な動作は本明細書に基づいて当業者により実現できる。以下に識別されている文献[I-D.ohba-mobopts-mpa-implementation]は、使用及びMPA機能性を達成するための既存のプロトコル間での相互作用を説明する1つの方法を提供している。
[0043]
性能要件
対話型VoIP及びストリーミングトラフィックに望ましいサービスの質を与えるために、エンドツーエンド遅延、ジッタ及びパケット損失の値を特定の閾値レベルに制限する必要がある。ITU−T規格とITU−E規格は、これらのパラメータの許容できる値を定めている。例えば、一方向遅延について、ITU−T G.114はアプリケーションの大部分に対する上限として150msを、一般的に許容できない遅延として400msを推奨している。ビデオ会議の一方向遅延公差は200から300msの範囲内にある。また、特定の閾値の後に順序が狂ったパケットが受信されると、それは損失と見なされる。以下に一覧表示される参考文献[RFC2679]、[RFC2680]及び[RFC2681]は、遅延とジッタのための測定技法のいくつかを説明している。
[0044]
エンドーツーエンド遅延は、通常、ネットワーク遅延、オペレーティングシステム(OS)遅延、CODEC遅延及びアプリケーション遅延等の複数の要素を含む。ネットワーク遅延は伝送遅延、伝搬遅延、及び中間ルータでの待ち行列遅延を含む。オペレーティングシステムに関連した遅延は送信機と受信機におけるオペレーティングシステムのスケジューリング動作からなる。CODEC遅延は、送信機端と受信機端で、一般的にはパケット化と逆パケット化(depacketization)のために引き起こされる。
[0045]
アプリケーション遅延は主にネットワーク内の遅延変動を補償するのに役立つプレイアウト(playout)遅延に起因している。エンドツーエンド遅延及びジッタの値は受信機端部でのプレイアウトバッファの適切な値を使用して調整できる。例えば、対話型VoIPトラフィックの場合、エンドツーエンド遅延はジッタ値に影響を及ぼし、検討すべき重要な問題である。携帯電話の頻繁なハンドオーバの間、過渡的なトラフィックがこの携帯電話に到達することができず、これもジッタに貢献する。
[0046]
エンドシステムがプレイアウトバッファを有する場合には、このジッタはプレイアウトバッファ遅延により包含されるが、それ以外の場合これは対話型トラフィックのための遅延を増加させる。パケット損失は、通常、輻輳、ルーティングの不安定性、リンク故障、無線リンク等の損失の多いリンクにより引き起こされる。携帯電話のハンドオーバの間、携帯電話はそのネットワークへの接続の変化のためにパケット損失にさらされる。したがって、ストリーミングトラフィックとVoIP対話型トラフィックの両方について、パケット損失がリアルタイムアプリケーションのサービス品質の一因となる。
[0047]
損失したパケットの数はハンドオーバの間の遅延及び携帯電話が受信するトラフィックの速度に比例する。損失パケットは再送のためにTCPトラフィックの場合には輻輳の一因となるが、それはRTP/UDPベースであるストリーミングトラフィックの場合には輻輳を増加しない。したがって、任意の移動性管理方式でパケット損失とハンドオーバ遅延の影響を削減することが必須である。既存作業高速ハンドオーバと題される次項2では、ハンドオーバの削減を試みた高速ハンドオーバ方式のいくつかを説明する。
[0048]
ETSI TR 101、以下の参考文献[ETSI]に従って、通常の音声会話は最高2%のパケット損失に耐えることができる。携帯電話が会話の間に頻繁なハンドオフにさらされる場合、各ハンドオフがハンドオフ期間のパケット損失の一因となる。したがって、会話の間の最大損失を許容できるレベルに削減する必要がある。
[0049]
ストリーミングアプリケーションの場合のパケット損失に明確な閾値はないが、それは特定のアプリケーションにさらに優れたサービスの品質を提供するために可能な限り多く削減する必要がある。
[0050]
既存作業高速ハンドオーバ
例えばモバイルIP(以下の参考文献[RFC3344]を参照されたい)、モバイルIPv6(以下の参考文献[RFC3775]を参照されたい)及びSIPモビリティ(以下の参考文献[SIPMM]を参照されたい)等の基本的な移動性管理プロトコルはTPCとRTPトラフィックに連続性を与えるための解決策を提供するが、これらはサブネットとドメイン間の携帯電話の頻繁な移動中ハンドオーバ待ち時間を削減するために最適化されていない。一般的には、これらの移動性管理プロトコルは第2層、第3層、及び携帯電話の移動性バインディングを更新するためのアプリケーション層等の複数の層で生じるハンドオーバ遅延に苦労する。
[0051]
携帯電話のセル、サブネット及びドメイン間での移動中のハンドオーバ遅延及びパケット損失を削減しようと試みる現在の移動性管理方式に適用する複数の最適化技法があった。マイクロモビリティ管理方式(例えば、以下の参考文献[CELLIP]及び参考文献[HAWAII]を参照されたい)、及びドメインの中のシグナリング更新を制限することにより高速ハンドオーバを提供する(例えば以下の参考文献[IDMP]及び[I-D.ietf-mobileip-reg-tunnel]に見られるような)ドメイン内移動性管理方式はほとんどない。IPv4ネットワークとIPv6ネットワーク(以下の参考文献[I-D.ietf-mobileip-lowlatency-handooffs-v4]及び[I-D.ietf-mipshop-fast-mipv6]を参照されたい)のための高速モバイルIPプロトコルは、リンク層トリガにより入手可能になる移動性情報を活用する高速ハンドオーバ技法を提供する。Yokotaら(以下の参考文献[YOKOTA]を参照されたい)は、MIPv4仕様を改変することなく高速ハンドオーバを提供するために、アクセスポイントと専用MACブリッジの協働使用を提案している。MACD方式(以下の参考文献[MACD]を参照されたい)は、キャッシュをベースにしたアルゴリズムを提供することによりMAC層ハンドオフによる遅延を削減する。
[0052]
移動性管理方式のいくつかは二重インタフェースを使用するため、メークビフォアブレークシナリオ(make-before-break scenario)を実現する(以下の参考文献[SUM]を参照されたい)。メークビフォーブレーク状況では、二次インタフェースが接続される過程にあるときに、通信は通常1つのインタフェースと続行する。IEEE 802.21作業部会はこれらのシナリオを詳細に検討している。
[0053]
単一インタフェースを使用して高速ハンドオーバを提供することは、複数のインタフェースを用いるクライアントにとってよりさらに注意深い設計技法を必要とする。以下の参考文献[SIPFAST]は、SIPをベースにした移動性管理の最適化ハンドオーバ方式を提供し、過渡的なトラフィックはアプリケーション層転送方式を使用することにより古いサブネットから新しいサブネットに転送される。以下の参考文献[MITH]は、旧外部エージェント(old foreign agent)と新外部エージェント(new foreign agent)間での携帯電話により開始されたトンネリングを使用する単一インタフェースケースのための高速ハンドオーバ方式を提供する。以下の参考文献[MITH]は、Pre−MITとPost−MITという2種類のハンドオーバ方式を定める。
[0054]
提案MPA方式はいくつかの点で一般的に、携帯電話が実際に新しいネットワークに移動する前に外部エージェントと通信するMITHの予測方式に類似した性質である。しかしながら、とりわけ、本明細書に説明されている提案MPA方式はMIPタイプの移動性プロトコルだけに限定されない。更にこの方式はドメイン間の移動を処理し、先を見越したハンドオーバに加えて事前認証を実行する。したがって、提案されている方式は、とりわけリンク層ハンドオーバ遅延の近くまで全体的な遅延を削減できる。
[0055]
用語
本明細書では、以下の用語が利用されている。
[0056]
移動性バインディング:
携帯端末のロケータと識別子の間のバインディング。
[0057]
移動性管理プロトコル(MMP):
携帯端末のロケータと識別子の間でバインディングを維持するためにネットワーク層又はさらに上位層で動作するプロトコル。
[0058]
バインディング更新:
移動性バインディングを更新するための手順。
[0059]
媒体に依存しない事前認証モバイルノード(MN):
任意のリンク層にわたって、かつ任意の移動性管理プロトコルを用いて機能する、モバイル支援安全ハンドオーバ最適化方式である媒体に依存しない事前認証(MPA)の携帯端末。MPAモバイルノードはIPノードである。本明細書では、用語「モバイルノード」つまり修飾子の付かない「MN」は「MPAモバイルノード」を指す。MPAモバイルノードは、通常移動性管理プロトコルのモバイルノードの機能性も有する。
[0060]
候補ターゲットネットワーク(CTN):
携帯電話が近い将来に移動してよいネットワーク。
[0061]
ターゲットネットワーク(TN):
携帯電話が移動することを決定したネットワーク。ターゲットネットワークは1つ又は複数の候補ターゲットネットワークから選択される。
[0062]
先行ハンドオーバトンネル(PHT):
MAPモバイルノードと候補ターゲットネットワークのアクセスルータの間に確立される双方向IPトンネル。本明細書では、修飾子が付かない用語「トンネル」は「先行ハンドオーバトンネル」を指す。
[0063]
接続ポイント(PoA):
ネットワークへのMPAモバイルノード用のリンク層接続ポイントとして機能するリンク層デバイス(例えば、スイッチ、アクセスポイント又は基地局等)。
[0064]
気付アドレス(CoA):
移動性管理プロトコルによりMPAモバイルノードのロケータとして使用されるIPアドレス。
[0065]
MPAフレームワーク
媒体非依存事前認証(Media-independent Pre-Authentication(MPA))フレームワークの例示的且つ非限定的な態様は以下のサブセクションで説明される。
[0066]
1.概観
媒体非依存事前認証(MPA)は、任意のリンク層にわたり、任意の移動性管理プロトコルを用いて機能する、モバイル支援安全ハンドオーバ最適化方式である。MPAを用いると、モバイルノードはIPアドレスと、候補ターゲットネットワーク(CTN)のための他の構成パラメータを安全に取得できるだけではなく、それが実際にCTNに接続する前に取得されたIPアドレスを使用してIPパケットを送受できる。これにより、モバイルノードは任意の移動性管理プロトコルのバインディング更新を完了し、リンク層でハンドオーバを実行する前に新しいCoAを使用できる。
[0067]
この機能性は、現在のネットワークに対する接続性を有するが、まだCTNに接続していないモバイルノードが(i)以後のプロトコルシグナリングを保護するためにCTNとセキュリティ関連付けを確立し、次に(ii)モバイルノードとCTNのアクセスルータの間で先行ハンドオーバトンネル(PHT)を確立するために実行トンネル管理プロトコルだけではなく、CTNからIPアドレスと他のパラメータも取得するために構成プロトコルを安全に実行し、次に(iii)移動性管理プロトコル(MMP)のバインディング更新のためのシグナリングメッセージを含むIPパケットと、トンネル内部アドレスとして取得されたIPアドレスを使用してPHT上でバインディング更新の完了後に送信されるデータパケットを送受し、最後に(iv)それがターゲットネットワークになるときにCTNに接続する直前にPHTを削除する又は無効にし、次に、モバイルノードがインタフェースを通してターゲットネットワークに接続された直後に、削除された又は無効にされたトンネルの内部アドレスをその物理インタフェースに割り当てし直すことができるようにすることによって提供される。ターゲットネットワークに接続する前にトンネルを削除する、又は無効にする代わりに、トンネルがターゲットネットワークに接続した直後に削除される、又は無効にされてよい。
[0068]
特に、第3の手順により、携帯電話はリンク層ハンドオーバを開始する前にさらに上位層のハンドオーバを完了できる。つまり、携帯電話は、それが依然としてトンネル外でのバインディング更新の完了前に送信されたデータパケットを送受できる一方、トンネルでのバインディング更新の完了後に送信されたデータパケットを送受できる。
[0069]
MPAの前記4つの基本的な手順では、第1の手順が「事前認証」と呼ばれ、第2の手順は「事前構成」と呼ばれ、第3の手順と第4の手順の組み合わせが「安全先行ハンドオーバ」と呼ばれている。事前認証により確立されるセキュリティ関連付けは、「MPA−SA」と呼ばれる。前記に示されたように、事前構成によって確立されたトンネルは「先行ハンドオーバトンネル」(PHT)と呼ばれる。
[0070]
2.機能要素
好ましい実施形態のMPAフレームワークでは、以下の機能要素はモバイルノードと通信するために各CTNに常駐する。つまり、認証エージェント(AA)、構成エージェント(CA)及びアクセスルータ(AR)である。それらの要素のいくつか又はすべては、単一のネットワークデバイスに、若しくは別々のネットワークデバイスに設置できる。
[0071]
認証エージェントは事前認証に関与する。認証プロトコルを、モバイルノードと認証エージェントの間で実行し、MPA−SAを確立する。認証プロトコルは、モバイルノードと認証ノードの間でキーを導出できる必要があり、相互認証を提供できなければならない。認証プロトコルは、AAAインフラストラクチャの中の適切な認証サーバに認証信用証明書を搬送するために、RADIUSとDiameter等のAAAプロトコルと対話できなければならない。該導出されたキーは事前構成及び安全先行ハンドオーバに使用されるメッセージ交換を保護するために使用されるキーをさらに導出するために使用される。リンク層及び/又はネットワーク層暗号をブートスするために使用される他のキーもMPA−SAから導出されてよい。EAP(例えば、以下の参考文献[RFC3748]を参照されたい)を搬送できるプロトコルはMPA用の認証プロトコルとして適切であろう。
[0072]
構成エージェントは、事前構成の一部、すなわちIPアドレスと他の構成パラメータをモバイルノードに安全に配信するために構成プロトコルを安全に実行することに関与する。構成プロトコルのシグナリングメッセージは、MPA−SAに対応するキーから導出されるキーを使用して保護される必要がある。
[0073]
アクセスルータは、事前構成の他の部分、つまりモバイルノードへの先行ハンドオーバトンネルを確立し、該先行ハンドオーバを該先行ハンドオーバトンネルを使用して保護するためにトンネル管理プロトコルを安全に実行することに関与するルータである。構成プロトコルのシグナリングメッセージは、MPA−SAに対応するキーから引き出されるキーを使用して保護される必要がある。先行ハンドオーバトンネル上で送信されるIPパケットは、MPA−SAに対応するキーから導出されるキーを使用して保護されなければならない。
[0074]
3.基本通信の流れ
モバイルノードがすでに接続ポイント、例えばPoA(旧接続ポイント)に接続され、気付アドレス、例えばoCoA(旧気付アドレス)を割り当てられていると仮定する。MPAの通信フローは後述されるとおりである。通信フロー全体で、データパケット損失はステップ5の切り替え手順中の期間以外では発生してはならず、この期間中にパケット損失を最小限に抑えることはリンク層ハンドオーバの責任である。
[0075]
ステップ1(事前認証段階):
モバイルノードはなんらかの発見プロセスを通してCTNを見つけ、何らかの手段によりCTN内でIPアドレス、認証エージェント、構成エージェント及びアクセスルータを取得する。モバイルノードは認証エージェントと事前認証を実行する。事前認証が無事終了すると、モバイルノードと認証エージェントの間にMPA−SAが作成される。2つのキーが、MPA−SA、つまりそれぞれ構成プロトコルとトンネル管理プロトコルの以後のシグナリングメッセージを保護するために使用されるMN−CAキーとMN−ARキーから導出される。MN−CAキーとMN−ARキーは、次にそれぞれ構成エージェントとアクセスルータに安全に配信される。
[0076]
ステップ2(事前構成段階):
モバイルノードは、その接続ポイントがoPoAから新しいもの、例えばnPoA(新接続ポイント)に変化する可能性があることを理解している。次に、モバイルノードは事前構成を実行し、構成エージェントが構成プロトコルを使用して、IPアドレス、例えばnCoA(新気付アドレス)、及び他の構成パラメータをCTNから取得し、アクセスルータがトンネル管理プロトコルを使用して、先行ハンドオーバトンネルを確立する。トンネル管理プロトコルでは、モバイルノードはnCoAとnCoAを、それぞれトンネル外部アドレスとトンネル内部アドレスとして登録する。事前構成プロトコルのシグナリングメッセージは、MN−CAキーとMN−ARキーを使用して保護される。構成とアクセスルータが同じデバイスの中で同一位置に配置されると、2つのプロトコルがIKEv2のような単一プロトコルに統合されてよい。トンネル確立の完了後、モバイルノードはステップ4の最後までにoCoAとnCoAの両方を使用して通信できる。
[0077]
ステップ3(安全先行ハンドオーバ主要段階):
モバイルノードは何らかの手段によって新しい接続ポイントに切り替わることを決定する。モバイルノードは、新しい接続点に切り替わる前に、移動性管理プロトコルのバインディング更新を実行し、以後のデータトラフィックをトンネル上で送信することによって安全先行ハンドオーバを開始する(主要段階)。場合によっては、それは複数のnCoAアドレスをキャッシュに格納し、コレスポンデントホスト(Correspondent Host(CH))又はホームエージェント(Home Agent(HA))と同時バインディングを実行する(例えば、モバイルIPv6仕様RFC3775において、モバイルノードは、それが異種ネットワークにローミングするときに気付アドレス(CoA)を割り当てられ、モバイルノードはバインディング更新プロセスを通してその新しいCoAについてそのホームエージェント(HA)とコレスポンデントノード(CN)に知らせる)。
[0078]
ステップ4(安全先行ハンドオーバ事前切り替え段階):
モバイルノードはバインディング更新を完了し、新しい接続ポイントに切り替わる準備が完了している。携帯電話は先行ハンドオーバトンネルを削除する、又は無効にするためにトンネル管理プロトコルを実行し、トンネルの削除又は無効の後にnCoAをキャッシュに入れてよい。いつもモバイルノードが新しい接続ポイントに切り替わる準備ができているのかに関する決定はハンドオーバ方針に依存している。
[0079]
ステップ5(切り替え):
リンク層ハンドオーバがこのステップで発生すると予想される。
[0080]
ステップ6(安全先行ハンドオーバ切り替え後段階):
モバイルノードは切り替え手順を実行する。切り替え手順が無事完了すると、モバイルノードはキャッシュ化nCoA(cached nCoA)をただちに復元し、それを新しい接続ポイントに接続されている物理インタフェースに割り当てる。先行ハンドオーバトンネルがステップ4で削除又は無効にされなかった場合、トンネルも削除される、又は無効にされる。この後、先行ハンドオーバトンネルを使用せずに、nCoAを使用するデータパケットを直接伝送することが可能である。
[0081]
アクセスルータは、事前構成の他の部分、つまりモバイルノードへの先行ハンドオーバトンネルを確立し、該先行ハンドオーバトンネルを使用して先行ハンドオーバを保護するためにトンネル管理プロトコルを安全に実行することに関与するルータである。構成プロトコルのシグナリングメッセージはMPA−SAに対応するキーから導出されるキーを使用して保護されなければならない。先行ハンドオーバトンネル上で送信されるIPパケットは、MPA−SAに対応するキーから導出されるキーを使用して保護されなければならない。
[0082]
参考文献
本発明は、その参考文献の全体的な開示が参照してここに組み込まれる、とりわけ以下の参考文献に説明されるシステム及び方法に優る種々の利点及び改善を提供する。
[0083]
1.Bradner,S.、「The Internet Standards Process-Revision 3」、BCP 9、RFC 2026、1996年10月。[RFC2026]として本明細書で参照。
[0084]
2.Bradner,S.、「IETF Rights in Contributions」、BCP 78、RFC 3978、2005年3月。[RFC3978]として本明細書で参照。
[0085]
3.Perkins,C.、「IP Mobility Support for IPv4」、RFC 3344、2002年8月。[RFC3344]として本明細書で参照。
[0086]
4.Aboba,B.、Blunk,L.、Volbrecht,J.、Carlson,J.、及びH.Levkowetz、「Extensible Authentication Protocol(EAP)」、RFC 3748、2004年6月。[RFC3748]として本明細書で参照。
[0087]
5.Johnson,D.、Perkins,C.、及びJ.Arkko、「Mobility Support in IPv6)」、RFC 3775、2004年6月。[RFC3775]として本明細書で参照。
[0088]
6.Malki,K.、「Low latency Handoffs in Mobile IPv4」、draft-ietf-mobileip-lowlatency-handoffs-v4-09(work in progress)、2004年6月。本明細書では[I-D.ietf-mobileip-lowlatency-handoffs-v4]として参照。
[0089]
7.Koodli,R.、「Fast Handovers for Mobile IPv6」、draft-ietf-mipshop-fast-mipv6-03(work in progress)、2004年10月。本明細書では[I-D.ietf-mipshop-fast-mipv6]として参照。
[0090]
8.Liebsch,M.、「Candidate Access Router Discovery」、draft-ietf-seamoby-card-protocol-08(work in progress)、2004年9月。本明細書では[I-D.ietf-seamoby-card-protocol]として参照。
[0091]
9.Loughney,J.、「Context Transfer Protocol」、draft-ietf-seamoby-ctp-11(work in progress)、2004年8月。本明細書では[I-D.ietf-seamoby-ctp]として参照。
[0092]
10.Aboba,B.、「Extensible Authentication Protocol(EAP)Key Management Framework)」、draft-ietf-eap-keying-06(work in progress)、2005年4月。本明細書では[I-D.ietf-eap-keying]として参照。
[0093]
11.Forsberg,D.、「Protocol for Carrying Authentication for Network Access(PANA)」、draft-ietf-pana-pana-08(work in progress)、2005年5月。本明細書では[I−D.−pana−pana]として参照。
[0094]
12.ITU-T、「General Characteristics of International Telephone Connections and International Telephone Circuits:One-Way Transmission Time」、ITU-T Recommendation G.114、1998年。本明細書では[RG98]として参照。
[0095]
13.ITU-T、「The E-Model,a computational model for use in transmission planning」、ITU-T Recommendation G.107、1998年。本明細書では[ITU98]として参照。
[0096]
14.ETSI、「Telecommunications and Internet Protocol Harmonization Over Networks(TIPHON)Release 3:End-to-end Quality of Service in TIPHON systems;Part 1:General Aspects of Quality of Service」、ETSI TR 101 329-6 V2.1.1。本明細書では[ETSI]として参照。
[0097]
15.Kivinen,T.及びH.Tschofenig、「Design of the MOBIKE protocol」、draft-ietf-mobike-design-02(work in progress)、2005年2月。本明細書では[I-D.ietf-mobike-design]として参照。
[0098]
16.Moskowitzh,R.、「Host Identity Protocol」、draft-ietf-hip-base-03(work in progress)、2005年6月。本明細書では[I-D.ietf-hip-base]として参照。
[0099]
17.Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A One-way Delay Metric for IPPM」、RFC 2679、1999年9月。本明細書では[RFC2679]として参照。
[0100]
18.Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A One-way Packet Loss Metric for IPPM」、RFC 2680、1999年9月。本明細書では[RFC2680]として参照。
[0101]
19.Almes,G.、Kalidindi,S.、及びM.Zekauskas、「A Round-trip Delay Metric for IPPM」、RFC 2681、1999年9月。本明細書では[RFC2681]として参照。
[0102]
20.Simpson,W.、「IP in IP Tunneling」、RFC 1853、1995年10月。本明細書では[RFC1853]として参照。
[0103]
21.Patrik,M.、「DHCP Relay Agent Information Option」、RFC 3046、2001年1月。本明細書では[RFC3046]として参照。
[0104]
22.Kim,P.,Volz,B.、及びS.Park、「Rapid Commit Option for DHCPv4」、draft-ietf-dhc-rapid-commit-opt-05(work in progress)、2004年6月。本明細書では[I-D.ietf-dhc-rapid-commit-opt]として参照。
[0105]
23.Ohba,Y.、「Media-Independent Pre-Authentication(MPA)Implementation Results」、draft-ohba-mobopts-mpa-implementation-00(work in progress)、2005年6月。本明細書では[I-D.ohba-mobopts-mpa-implementation]として参照。
[0106]
24.Schulzrine,H.、「Appliation Layer Mobility Using SIP」、MC2R。本明細書では[SIPMM]として参照。
[0107]
25.Cambell,A.、Gomez,J.、Kim,S.、Valko,A.、及びC.Wan、「Design,Implementation,and Evaluation of Cellular IP」、IEEE Personal communication、2000年8月。本明細書では[CELLIP]として参照。
[0108]
26.Ramjee,R.、Porta,T.、Thuel,S.、Varadhan,K.、及びS.Wang、「HAWAII:A Domain-based Approach for Supporting Mobility in Wide-area Wireless networks」、International Conference on Network Protocols、ICNP‘99。本明細書では「HAWAII」として参照。
[0109]
27.Das,S.、Dutta,A.、Misra,A.及びS.Das、「IDMP:An Intra-Domain Mobility Management Protocol for Next Generation Wireless Networks」、IEEE Wireless Communication Magazine、2000年10月。本明細書では「IDMP」として参照。
[0110]
28.Calhoun,P.、Montenegro,G.、Perkins,C.、及びE.Gustafsson、「Mobile IPv4 Regional Registration」、draft-ietf-mobileip-reg-tunnel-09(work in progress)、2004年7月。本明細書では[I-D.ietf-mobileip-reg-tunnel]として参照。
[0111]
29.Yokota,H.、Idoue,A.、及びT.Hasegawa、「Link Layer Assisted Mobile IP Fast Handoff Method over WirelessLAN Networks」、Proceedings of ACM Mobicom。本明細書では[YOKOTA]として参照。
[0112]
30.Shin,S.、「Reducing MAC Layer Handoff Latency in IEEE 802.11 Wireless LANs」、MOBIWAC Workshop。本明細書では[MACD]として参照。
[0113]
31.Dutta,A.、Zhang,T.、Madhani,S.、Taniuchi,K.、Ohba,Y.、及びH.Schulzrinne、「Secured Universal Mobility」、WMASH 2004年。本明細書では[SUM]として参照。
[0114]
32.Dutta,A.、Madhani,S.及びH.Schulzrinne、「Fast handoff Schemes for Application Layer Mobility Management」、PIMRC 2004年。本明細書では[SIPFAST]として参照。
[0115]
33.Gwon,Y.、Fu,G.、及びR.Jain、「Fast Handoffs in Wireless LAN Networks using Mobile initiated Tunneling Handoff Protocol for IPv4(MITHv4)」、Wireless Communications and Networking 2003、2005年1月。本明細書では[MITH]として参照。
[0116]
34.Anjum,F.、Das,S.、Dutta,A.、Fajardo,V.、Madhani,S.、Ohba,Y.、Taniuchi,K.、Yaqub,R.、及びT.Zhang、「A proposal for MIH function and Information Service」、IEEE 802.21作業部会に対する寄稿。2005年1月。本明細書では[NETDISC]として参照。
[0117]
35.「IEEE Wireless LAN Edition A compilation based on IEEE Std 802.11-1999(R2003)」、電気電子技術者協会(Institute of Electrical and Electtoniccs Engineers)2003年9月。本明細書では[802.11]として参照。
[0118]
36.Dutta,A.、「GPS-IP based fast-handoff for Mobiles」、NYMAN2003。本明細書では[GPSIP]として参照。
[0119]
37.Vatn,J.及びG.Maguire、「The effect of using co-located care-of-address on macro handover latency」、14th Nordic Teletraffic Seminar、1998年。本明細書では[MAGUIRE]として参照。

Disclosure of Invention

Technical Problem

[0120]
本発明は、前記及び/又は他の背景技術及び/又はその中の課題を改良する。

Technical Solution

[0121]
媒体非依存事前認証フレームワークにおける、第1のネットワークと第2のネットワークの間でのモバイルノードの切り替え復帰に関するハンドオフ決定を制御する方法は、a)近接するネットワークにおけるアクセスポイントに関して位置決定を行うように構成される位置決定モジュールをモバイルノードに設けることと、b)位置決定モジュールの出力に少なくとも部分的に基づいて、第1のネットワークと第2のネットワーク間での発振を回避するために位置をベースにしたアルゴリズムを使用することとを備える。
[0122]
いくつかの例では、方法はさらに、位置をベースにしたアルゴリズムがモバイルノードの位置とこのモバイルノードの従前のハンドオーバ活動に関してキャッシュに入れられたデータ(キャッシュ化データ(cached data))の間の相関関係に少なくとも部分的に基づくことをさらに含む。いくつかの例では、方法は、キャッシュに入れられたデータがモバイルノード上のデジタルデータ記憶装置の中に記憶されることをさらに含む。いくつかの例では、方法は、位置をベースにしたアルゴリズムが、該モバイルノードが第1のネットワークと第2のネットワークの他方に切り替わった過去の例に関するデータに基づいて第1のネットワークと第2のネットワークの他方に切り替えることに備えることを含むこと、をさらに含む。いくつかの例では、方法は、位置をベースにしたアルゴリズムが、該モバイルノードが第1のネットワークと第2のネットワークの他方に切り替わらなかった過去の例に関するデータに基づいて第1のネットワークと第2のネットワークの他方に切り替わらないことに備えることを含むこと、をさらに含む。いくつかの例では、方法は、位置決定モジュールがGPS受信機を含むことをさらに含む。いくつかの例では、方法は、第1のネットワークと第2のネットワークの間の発信を回避するために位置をベースにしたアルゴリズムを使用することをさらに含み、少なくとも一つの非位置決めインジケータ(non-location indicator)に少なくとも部分的に基づいたアルゴリズムを有することを含む。いくつかの例では、前記少なくとも1つの非位置決めインジケータは信号対雑音比のインジケータを含む。いくつかの例では、方法は、第1のネットワークが第1の媒体用であり、第2のネットワークが別の媒体用であることを含み、第1の媒体がセルラーで、該別の媒体は無線LANであるか、又は第1の媒体が無線LANで、該別の媒体がセルラーであるかのどちらかである。
[0123]
他のいくつかの実施形態に従って、媒体に依存しない事前認証フレームワークにおいて第1のネットワークと第2のネットワークの間のモバイルノードの望ましくない切り替え復帰の影響を緩和する方法は、a)第1のネットワークに関連するコンテキストを、該コンテキストが、携帯電話が第1のネットワークに戻ると迅速に回復できるようにある期間維持することと、b)該モバイルノードに第1のネットワークに戻るとコンテキストを使用させることとを含む。いくつかの例では、方法は、コンテキストがモバイルノード上のデジタルデータに記憶され、確立されたセキュリティ関連付け、IPアドレス又はトンネルに関するデータを含むことをさらに含む。いくつかの例では、第1のネットワークは第1の媒体用であり、第2のネットワークは別の媒体用であり、第1の媒体がセルラーで、該別の媒体が無線LANであるか、又は第1の媒体が無線LANで、該別の媒体がセルラーであるかのどちらかである。
[0124]
いくつかの他の実施形態に従って、媒体に依存しない事前認証フレームワークにおいて前のネットワークと新しいネットワークの間でのモバイルノードの望ましくない切り替え復帰の影響を緩和する方法は、モバイルノードが新しいネットワークから前のネットワークも戻る場合にパケットの損失を回避するために一時期前のネットワークと新しいネットワークの両方にデータパケットを送信することを含む。いくつかの例では、データパケットを送信する該ステップは、該データパケットをバイキャスティング(bicasting)することを含む。いくつかの例では、前のネットワークは第1の媒体用であり、新しいネットワークは別のネットワーク用であり、第1の媒体がセルラーで、別の媒体が無線LANであるか、あるいは第1の媒体が無線LANで、別の媒体がセルラーであるかのどちらかである。
[0125]
多様な実施形態の前記の及び/又は他の態様、特長及び/又は利点は、添付図面に関連して以下の説明を鑑みるとさらに理解されるであろう。多様な実施形態は、当てはまる場合、様々な態様、特長、及び/又は利点を含む、及び/又は除くことができる。加えて、多様な実施形態は、当てはまる場合、他の実施形態の1つ又は複数の態様又は特長を組み合わせることができる。特定の実施形態の態様、特長、及び/又は利点の説明は、他の実施形態又は請求項を制限するとして解釈されてはならない。

Best Mode for Carrying out the Invention

[0126]
本発明の好ましい実施形態は、制限ではなく一例として添付図に示されている。
[0127]
本発明は多くの異なる形式で具現化されてよいが、多くの例示的な実施形態は、本開示が本発明の原則の例を提供すると見なされるべきである旨、及びこのような例が、本明細書に説明されている、及び/又は本明細書に描かれている好ましい実施形態に本発明を制限することを目的としていない旨を理解した上で本明細書に説明されている。
[0128]
詳細な説明
迅速なサブネットとドメインのハンドオーバを経験する携帯電話に最適化されたハンドオーバを提供するために、いくつかの問題点に取り組む。これらの問題点は近接ネットワーキング要素の発見、特定の方針に基づいて接続先の正しいネットワークを選ぶこと、第2層接続ポイントを変更すること、DHCPサーバ又はPPPサーバからIPアドレスを取得すること、該IPアドレスの一意性を確認すること、例えば特定のドメインのAAAサーバのような認証エージェントと事前認証すること、一致するホストにバインディング更新を送信し、新しい接続ポイントへのリダイレクトされたストリーミングトラフィックを取得することと、ピンポン減少、及び複数のネットワークに移動する蓋然性を含む。例えばMPAをベースにした安全先行ハンドオーバの関連で、これらの問題点及びこれらに対処する又は最適化するための方法が後述される。
[0129]
1.発見
アクセスポイント、アクセスルータ、認証サーバ等の近接するネットワーキング要素を発見すると、携帯電話がネットワーク間で急速に移動する際にハンドオーバプロセスを迅速に処理するのに役立つ。所望される座標のセットでネットワーク近隣を発見することにより、携帯電話の機能及びパラメータは事前認証、先行IPアドレス獲得、先行アドレス解決、及びバインディング更新等の作業の多くを、前のネットワークの間に実行できる。
[0130]
携帯電話が近接するネットワークを発見できるいくつかの方法がある。候補アクセスルータ発見プロトコル(前記参考文献[I-D.ietf-seamoby-card-protocol]を参照されたい)は、近接するネットワークにおいて候補アクセスルータを発見するのに役立つ。特定のネットワークドメインを考慮すると、サービスロケーションプロトコル(SLP)とドメイン名サービス(DNS)は、特定のドメインでのサービスの既定のセットにネットワーキング構成要素のアドレスを与えるのに役立つ。場合によっては、ネットワーク層と上位層のパラメータの多くが、携帯電話が近接するネットワークの近傍に近づくと、ビーコン等のリンク層管理フレーム上で送信されてよい。IEEE 802.11uはリンク層に含まれる情報を使用して近隣を発見すること等の問題点を検討している。しかしながら、リンク層管理フレームがなんらかのリンク層セキュリティ機構により暗号化されている場合には、モバイルノードはアクセスポイントへのリンク層接続性を確立する前に必要な情報を得ることはできない可能性がある。さらに、これは帯域幅が制限された無線媒体に重荷を追加することがある。このような場合、近接する要素に関する情報を取得するためにさらに上位層のプロトコルが好まれる。近接するネットワークについてのこれらの情報をモビリティサーバから取得するのに役立つ、例えば前記参考文献[NETDISC]においてのようななんらかの提案がある。形態電話の移動が差し迫っているときには、それは特定のサーバに問合せを行うことによって発見プロセスを開始し、アクセスポイントのIPアドレス、その特徴、ルータ、近接ネットワークのSIPサーバ又は認証サーバ等の必要とされるパラメータを得る。ネットワークが複数の場合には、それは複数の近接ネットワークから必要とされるパラメータを取得し、これらをキャッシュに保存してもよい。ある時点で、携帯電話は多くの有望なネットワークの中から複数のCTNを見出し、CTNにおいて必要とされるエンティティと通信することによって事前認証プロセスを開始する。このシナリオは、以下の第2項にさらに詳細に述べられている。
[0131]
2.複数のCTN環境での事前認証
場合によっては、携帯電話がターゲットネットワークとなる特定のネットワークを決定しても、それは実際には、携帯電話の制御を超えている要因のためにターゲットネットワーク以外の近接するネットワークに移動して終わることがある。したがって、いくつかの有望な候補ターゲットネットワークと事前認証を実行し、それらのネットワークの中でそれぞれのターゲットルータと期限を定めたトンネルを確立することが役立つ場合がある。したがって、携帯電話が以前に決定されたとおりにターゲットネットワークに移動しない場合、それは、結局は別のターゲットネットワークに移動するため、事後認証及びIPアドレス獲得遅延のためのパケット損失を受けない。多くの候補ターゲットネットワークと事前認証し、IPアドレスを確保することによって、携帯電話はそれ以外の場合使用できたであろうリソースを供給しているように見える。しかし、これは限られた期間に起こるため、それは大きな問題となってはならない。携帯電話は先行してIPアドレスを取得し、ターゲットアクセスルータと期限を定めたトンネルをセットアップするために事前認証手順を使用する。
[0132]
通常のシナリオでは、携帯電話は仮想インタフェースに新しいIPアドレスを割り当てる。しかし、隣接ネットワークから複数のIPアドレスを取得する場合には、それは2つのことを行うことができる。それは携帯電話が移動することを決定したネットワークのIPアドレスとの1つの仮想インタフェースを作成できるか、又はそれは隣接ネットワークから取得されるそれぞれのIPアドレスを使用して複数の仮想インタフェースを作成できるかのいずれかである。携帯電話は、バインディング更新アドレスとしてこれらのアドレスの内の1つを選び、それを一致するホスト(CH)に送信してよく、このようにして前のネットワークにいる間にターゲットネットワークを介してトンネルを行うトラフィックを受信するだろう。しかし、いくつかの例では、携帯電話は、結局ターゲットネットワーク以外のネットワークに移動する可能性がある。したがって、携帯電話は新しいIPアドレスを割り当て、バインディング更新を再度送信するプロセスを経なければならないため、携帯電話が新しいネットワークに移動するとトラフィックに混乱が生じる。この問題を処理するために2つの解決策を提案できる。携帯電話は同時移動性バインディングを利用し、複数のバインディング更新を対応するホストに送信できる。したがって、対応するホストは特定の期間、仮想インタフェースに割り当てられた複数のIPアドレスにトラフィックを送信する。このバインディング更新は、携帯電話が新しいネットワークに移動し、したがって他の候補ネットワークへの流れを停止した後にCHで新しくされる。特定の移動性方式で同時バインディングがサポートされていない場合は、前のターゲットネットワークからのトラフィックの転送が、新しいバインディング更新が新しいネットワークから出るまで過渡的なトラフィックを処理するのに役立つであろう。
[0133]
3.先行IPアドレス獲得
一般的には、移動性管理プロトコルは外部エージェント(FA)と関連して、又は同位置アドレスモードで機能する。我々のMPA手法は同位置アドレスモード(co-located address mode)と外部エージェントアドレスモードの両方とも使用できる。ここでは、同位置アドレスモードで使用されるアドレス割り当て構成要素を説明する。モバイルノードがIPアドレスを取得し、それ自体を構成できるいくつかの方法がある。最も一般的には、携帯電話はネットワーク内のサーバ又はルータ等の任意の構成要素がない場合に静的にそれ自体を構成できる。IETF Zeroconf作業部会は、携帯電話が特別に構成され、169.254.x.x.のような指定された範囲から一意のアドレスを選ぶ自動IP機構を定める。LAN環境では、携帯電話は動的ホスト構成プロトコル(DHCP)サーバからIPアドレスを取得できる。IPv6ネットワークの場合、携帯電話は無国籍自動設定(stateless auto-configuration)又はDHCPv6を使用してIPアドレスを取得する選択肢を有する。広域ネットワーキング環境では、携帯電話はPPPを使用して、ネットワークアクセスサーバ(NAS)と通信することによってIPアドレスを取得する。
[0134]
これらのプロセスはそれぞれ、IPアドレス獲得プロセスのタイプと、クライアントとサーバのオペレーティングシステムに応じてほぼ数百ミリ秒から数秒を要する。
[0135]
IPアドレス獲得はハンドオーバプロセスの一部であるため、それはハンドオーバ遅延を増加し、したがってこのタイミングを可能な限り多く短縮することが望ましい。例えば、IPアドレス獲得時間のためにハンドオーバ時間を短縮しようと試みる、使用可能なDHCP高速コミット(例えば、前記参考文献[I.D.ietf-dhc-rapid-commit-opt]を参照されたい)及びGPS座標をベースにしたIPアドレス(例えば前記の参考文献[GPSIP]を参照されたい)等の最適化された技法はほとんどない。しかしながら、これらすべての場合で、携帯電話は、モバイルノードとDHCPサーバの間のシグナリングハンドシェイクのために、新しいサブネットに移動し、遅れを被った後にIPアドレスを取得する。
下記パラグラフでは、モバイルノードがCTNから先行してIPアドレスを取得することができる多くの方法及び関連付けられたトンネルセットアップ手順を説明する。これらはPANA支援先行IPアドレス獲得、IKE支援先行IPアドレス獲得、DHCPだけを使用する先行IPアドレス獲得及びステートレス自動構成等の4つのカテゴリに幅広く定義できる。
[0136]
3.1 PANA支援先行IPアドレス獲得
PANA支援先行IPアドレス獲得の場合、モバイルノードはCTNから先行してIPアドレスを取得する。モバイルノードはCTN内のアクセスルータ内のPANA認証エージェントと同一位置に配置するDHCP中継エージェントでアドレス獲得プロセスをトリガするためにPANAメッセージを利用する。モバイルノードからPANAメッセージを受信すると、DHCP中継エージェントはCTN内のDHCPサーバからIPアドレスを取得するために通常のDHCPメッセージ交換を実行する。このアドレスはPANAメッセージの中でピギーバックされ、クライアントに配信される。ステータス自動構成のMIPv6の場合は、新しいターゲットネットワークからのルータ広告がPANAメッセージの一部としてクライアントに渡される。携帯電話は、それが新しいネットワークにおいて行うであろうように、一意のIPv6アドレスを構築するためにこの接頭語とMACアドレスを使用する。ステートフルモードのモバイルIPv6はDHCPv4と非常に類似して作用する。
[0137]
3.2 IKEv2支援先行IPアドレス獲得
IKEv2支援先行IPアドレス獲得は、IPsecゲートウェイとDHCP中継エージェントがCTN内の各アクセスルータの中に常駐しているときに作用する。この場合、IPsecゲートウェイとCTNの中のDHCP中継エージェントは、モバイルノードがCTN内のDHCPサーバからIPアドレスを獲得するのに役立つ。事前認証段階の間に確立されたMN−ARキーは、モバイルノードとアクセスルータの間でIKEv2を実行するために必要とされるIKEv2事前共用秘密として使用される。CTNからのIPアドレスは、標準的なIKEv2手順として取得され、標準DHCPを使用してターゲットネットワーク内のDHCPサーバからIPアドレスを取得するために同一位置に配置されたDHCP中継エージェントを使用する。取得されたIPアドレスはIKEv2構成ペイロード交換でクライアントに送り返される。この場合、IKEv2は先行ハンドオーバトンネル(以下の第5項を参照されたい)のためのトンネル管理プロトコルとしても使用される。
[0138]
3.3 DHCPを単独で使用する先行IPアドレス獲得
別の代替策として、PANAをベースにした又はIKEv2をベースにした手法に依存せずに、モバイルノードとCTNの中のDHCPリレー又はDHCPサーバの間の直接的なDHCP通信を可能にすることによって、CTNからIPアドレスを先行して取得するためにDHCPが使用されてよい。この場合、モバイルノードは、要求のソースアドレスとして現在の物理インタフェースと関連付けられたアドレスを使用する一方で、アドレスを要求しているCTN内のDHCP中継エージェント又はDHCPサーバにユニキャストDHCPメッセージを送信する。
[0139]
メッセージがDHCP中継エージェントに送信されると、DHCP中継エージェントはDHCPメッセージをモバイルノードとDHCPサーバの間で往復で中継する。DHCP中継エージェントがない場合には、携帯電話はターゲットネットワーク内のDHCPサーバとじかに通信することもできる。クライアントのユニキャストDISCOVER(発見)メッセージの中の放送オプションは、中継エージェント又はDHCPサーバがモバイルノードのソースアドレスを使用して携帯電話に直接応答を送り返すことができるように0に設定されなければならない。この仕組みは、ステートフル構成を使用するIPv6に対しても作用する。
[0140]
悪意のあるノードがDHCPサーバからIPアドレスを取得するのを妨げるために、DHCP認証が使用されなければならない、又はアクセスルータが事前認証されていないモバイルノードからリモートDHCPサーバに送信されるユニキャストDHCPメッセージを遮断するためにフィルタをインストールしなければならない。DHCP認証を使用する場合、DHCP認証キーがモバイルノードと候補ターゲットネットワーク内の認証エージェントの間で確立されるMPA−SAから導出されてよい。
[0141]
先行して取得されたIPアドレスは、携帯電話が新しいネットワークに移動しなくなるまでモバイルノードの物理インタフェースに割り当てられない。このようにしてターゲットネットワークから先行して取得されたIPアドレスは物理インタフェースに割り当てられるのではなく、むしろクライアントの仮想インタフェースに割り当てられる必要がある。したがって、モバイルノードと、CTN内のDHCPリレー又はDHCPサーバの間の直接的なDHCP通信を介してこのような先行して獲得されたIPアドレスは、それを物理インタフェースに割り当てられた他のアドレスと区別するために使用される追加情報とともに搬送されてよい。
[0142]
3.4 ステートレス自動構成を使用する先行IPアドレス獲得
IPv6の場合、ネットワークアドレス構成はDHCPv6又はステートレス自動構成のどちらかを使用して行われる。新IPアドレスを先行して取得するために、次のホップルータのルータ通知が確立されたトンネル上で送信することができ、新IP6アドレスは携帯電話の局番とMACアドレスに基づいて生成される。このアドレスはクライアントの仮想アドレスに割り当てられ、ホームエージェント又は一致するノードにバインディング更新として送信される。通常は詳しく調べられた(scoped)マルチキャストアドレスで送信されるこのルータ通知は、携帯電話のoCoAに容易にトンネルを行うことができる。これにより、IPアドレスを取得し、二重アドレス検出を実行するために要する時間が回避されるだろう。
[0143]
携帯電話が新ネットワークに入ると、モバイルノードは、例えばDHCP INFORMを使用することによりSIPサーバ、DNSサーバ等の他の構成パラメータを取得するために物理インタフェース上で新ネットワークに対してDHCPを実行することができる。これは、携帯電話と一致するホスト間の継続中の通信に影響を及ぼしてはならない。また、モバイルノードは新しいネットワークに入る前に先行して取得されたアドレスの賃貸を延長するために、新ネットワークに対して物理インタフェース上でDHCPを実行できる。
[0144]
モバイルノードのためのDHCPバインディングを維持し、安全先行ハンドオーバの前後に分配されたIPアドレスを追跡調査するために、先行IPアドレス獲得のためのDHCPと、モバイルノードがターゲットネットワークに入った後に実行されたDHCPの両方について、同じDHCPクライアント識別子がモバイルノードに使用される必要がある。DHCPクライアント識別子は、モバイルノードのMACアドレス又は他のなんらかの識別子であってよい。ステートレス自動構成の場合では、携帯電話は新しいネットワークでのルータ広告の接頭語を確かめ、それを新規に割り当てられたIPアドレスの局番と突き合せる。これらが同じであることが判明すると、携帯電話はIPアドレス獲得段階を再度経過しない。
[0145]
4.アドレス解決問題
4.1 先行二重アドレス検出
DHCPサーバがIPアドレスを分配するとき、それはその賃貸表を更新し、その結果この同じアドレスはその特定の期間別のクライアントに与えられない。同時に、クライアントは、それが必要に応じて更新できるように賃貸表を局所的に保存する。ネットワークがDHCPでイネーブルされたクライアントとDHCPでイネーブルされていないクライアントの両方からなる場合は、LANを使う別のクライアントがDHCPアドレスプールからのIPアドレスで構成されたかもしれない蓋然性がある。
[0146]
このようなシナリオでは、サーバは、IPアドレスを割り当てる前に、ARP(アドレス解決プロトコル)又はIPv6近傍発見に基づいて二重アドレス検出を行う。検出手順は最高4秒から15秒を要することがあり(例えば、下記の参考文献[MAGUIRE]を参照されたい)、したがってさらに大きなハンドオーバ遅延の一因となる。先行IPアドレス獲得プロセスの場合は、この検出は事前に行われるため、ハンドオーバ遅延にまったく影響を及ぼさない。二重アドレス検出を事前に行うことにより、ハンドオーバ遅延係数を削減する。
[0147]
4.2 先行アドレス解決更新
事前認証のプロセスの間、ターゲットネットワークに接続してからターゲットネットワーク内のノードと通信するためにモバイルノードにより必要とされるアドレス解決マッピングも公知であり、ノードはアクセスルータ、認証エージェント、構成エージェント及び一致するノードであってよい。このような先行アドレス解決を実行する多くの方法がある。
[0148]
1.ノードのMACアドレスを解決するために情報サービス機構(例えば、前記参考文献[NETDISC]を参照されたい)を使用する。これにより、ターゲットネットワークの中の各ノードが、情報サービスのサーバが先行アドレス解決のデータベースを構築できるように情報サービスに関与することが必要である可能性がある。
[0149]
2.先行アドレス解決をサポートするために、事前認証のために使用される認証プロトコル又は事前構成に使用される構成プロトコルを拡張する。例えば、PANAが認証プロトコルとして事前認証に使用される場合、PANAメッセージは先行アドレス解決に使用されるAVPを搬送してよい。この場合、ターゲットネットワーク内のPANA認証エージェントはモバイルノードの代わりにアドレス解決を実行してよい。
[0150]
3.ターゲットネットワークのネットワーク要素の特定のIPアドレスと関連付けられた特定のインタフェースのMACアドレスをマッピングするためにDNSを利用することもできる。ターゲットネットワークのノードのMACアドレスを先行して解決するために新しいDNSリソースレコード(RR)を定義してよい。ただし、MACアドレスはドメインネームに直接結び付けられるのではなく、IPアドレスに結び付けられるリソースであるため、この手法には独自の制限がある。
[0151]
モバイルノードがターゲットネットワークに接続すると、それはターゲットネットワーク内のノードに対するアドレス解決照会を必ずしも実行せずに先行して取得されたアドレス解決マッピングをインストールする。
[0152]
他方、ターゲットネットワークに属し、モバイルノードと通信しているノードも、モバイルノードがターゲットネットワークに接続するとすぐにモバイルノードのためのそのアドレス解決マッピングを更新する必要がある。前記の先行アドレス解決方法は、モバイルノードがターゲットネットワークに接続する前にモバイルノードのMACアドレスを先行して解決するために、それらのノードに対して使用することもできる。しかしながら、それらのノードは先行して解決されたアドレス解決マッピングを採用する前にターゲットネットワークへのモバイルノードの接続を検出する必要があるため、これは役に立たない。さらに優れた手法は、接続検出及びアドレス解決マッピング更新の統合であろう。これは、ターゲットネットワーク内のノードがモバイルノードのアドレス解決マッピングを迅速に更新できるようにモバイルノードが新ネットワークに接続される直後に、モバイルノードが、IPv4の場合にはアドレス解決プロトコル(ARP)ARP要求又はARP応答を送り、又はIPv6の場合には近傍通知を送るアドレス解決(上記参考文献[RFC3344]及び[RFC3775]参照)を不当に実行することに基づいている。
[0153]
5.トンネル管理
IPアドレスがCTN内のDHCPサーバから先行して獲得された後、先行ハンドオーバトンネルがモバイルノードとCTN内のアクセスルータの間で確立される。モバイルノードはトンネル内部アドレスとして獲得されたIPアドレスを使用し、たぶん仮想インタフェースにそのアドレスを割り当てる。
[0154]
先行ハンドオーバトンネルがトンネル管理プロトコルを使用して確立される。IKEv2が先行IPアドレス獲得に使用されると、IKEv2もトンネル管理プロトコルとして使用される。
[0155]
また、PANAが先行IPアドレス獲得に使用される場合、PANAは安全なトンネル管理プロトコルとして使用されてよい。
[0156]
いったん先行ハンドオーバトンネルがモバイルノードと候補ターゲットネットワーク内のアクセスルータの間に確立されると、アクセスルータは、それがモバイルノードの新しいアドレスに宛てられるあらゆるパケットを捕捉できるようにモバイルノードの代わりにプロキシアドレス解決を実行する必要もある。
[0157]
携帯電話は前のネットワークにいる間に一致するノードと通信できる必要があるため、バインディング更新と、一致するノードからモバイルノードへのデータのいくつかの部分又はすべての部分が先行ハンドオーバトンネル上でモバイルノードに送り返される必要がある。セッション開始プロトコル(SIP)モビリティが移動性管理プロトコルに使用されると、連絡アドレスとしての新しいアドレスがSIP Re−INVITEを使用して一致するノードに報告される。いったん一致するノードのSIPユーザエージェントが新しい連絡アドレスを取得すると、それはターゲットネットワークに実際に属する新しい連絡アドレスにOKを送信する。ターゲットネットワーク内のアクセスルータは、それが新しい連絡アドレスに向けられていたのでOK信号を獲得し、それをその前のネットワークの携帯電話にトンネルを行う。最終的なACKメッセージは携帯電話から一致するノードに受信される。携帯電話から一致するノードへのデータは進入フィルタリング(ingress filtering)がない場合にはトンネルを行う必要がない場合もある。SIP Re−INVITEシグナリングハンドシェイクの完了後、一致するノードからのデータが先行ハンドオーバトンネルを介して携帯電話に送信される。
[0158]
モバイルノードがターゲットネットワークに接続した後にトラフィックがモバイルノードに向けられるためには、先行ハンドオーバトンネルが削除される又は無効にされる必要がある。トンネルを確立するために使用されるトンネル管理プロトコルは、この目的に使用される。
[0159]
また、PANAが認証プロトコルとして使用される場合、アクセスルータでのトンネルの削除又は無効は、携帯電話がターゲットネットワークに移動するとすぐにPANA更新機構によってトリガできる。リンク層トリガは、モバイルノードが実際にターゲットネットワークに接続され、トンネルを削除する、又は無効にするためのトリガとして使用することもできることを確実にする。
[0160]
6.バインディング更新
様々な移動性管理方式のためのいくつかの種類のバインディング管理機構がある。ROのないモバイルIPv4等の場合には、バインディング更新はホームエージェント(HA)だけに送信され、モバイルIPv6の場合にはバインディング更新がホームエージェントと対応するホストの両方に送信される。SIPをベースにした端末モビリティの場合には、携帯電話はRe−INVITEを使用してバインディング更新を一致するノードに、REGISTERメッセージを登録機関に送信する。携帯電話と一致するノードの間の距離に基づき、バインディング更新はハンドオーバ遅延の一因となる場合がある。SIP高速ハンドオーバ(例えば[SIPFAST]を参照されたい)は、バインディング更新に起因するハンドオーバ遅延を削減するいくつかの方法を提供する。SIPベースのモビリティ管理を使用する安全先行ハンドオーバの場合には、それは前のネットワークで起こるため、バインディング更新に起因する遅延を完全に排除する。したがって、本方式は、一致するノードが通信するモバイルノードから遠すぎるときにより魅力的に見える。
[0161]
7.パケット損失の妨害
MPAの場合には、IPアドレス獲得、保護された認証、及びバインディング更新のためのパケット損失を認めなかった。しかしながら、モバイルノードがターゲットネットワークに接続できる前にモバイルノードに向けられるリンク層ハンドオーバ中のいくつかの過渡的なパケットがある場合がある。それらの過渡的なパケットは損失することがある。
[0162]
アクセスルータで過渡的なパケットをバイキャスティングする、又はバッファに入れることは、パケット損失を最小限に抑える又は排除するために使用できる。ただし、リンク層ハンドオーバがシームレスに実行されない場合には、バイキャスティングはパケット損失を排除しない。他方、バッファリングはパケット遅延を削減しない。パケット遅延はストリーミング用途の場合受信機側でプレイアウトバッファ(playout buffer)によって補償できるが、プレイアウトバッファは大きな遅延ジッタに耐えることのできない対話型のVoIP用途ではあまり役に立たない。したがって、いずれにせよリンク層ハンドオーバを最適化することは依然として重要である。
[0163]
さらに、MNは古い接続ポイントから切り替わる前に新しい接続ポイントへの到達可能性を保証してもよい。これは、リンク層管理フレームを新しい接続ポイントと交換することによって行うことができる。この到着可能性チェックは可能な限り迅速に実行されなければならない。到着可能性チェックの間のパケット損失を妨ぐために、MNと古い接続ポイントの間のリンク上でのパケットの伝送は、到着可能性チェックの間リンクの両端でパケットをバッファに入れることにより保留されなければならない。本明細書に基づいて理解されるように、このバッファリングは種々の方法で実行できる。
[0164]
8.切り替えの失敗及び切り替え復帰のための考慮事項
ピンポン現象は、ハンドオーバシナリオの間に見られる共通の問題の1つである。このようなピンポン現象は、携帯電話がセル又は決定ポイントの境界線に位置し、ハンドオーバ手順が頻繁に実行されるときに生じる。
[0165]
とりわけ、この結果、呼中止確率(call drop probability)の上昇、接続品質の低下、シグナリングトラフィックとリソースの無駄の増加が生じる。これらのすべてが移動性最適化に影響を及ぼす。ハンドオフアルゴリズムはネットワーク間でハンドオフを実行するための決定要因である。従来、これらのアルゴリズムはハンドオフに関して決定するために様々な測定基準の値を比較するために閾値を利用する。これらの測定基準は信号強度、経路損失、搬送波対干渉比(CIR)、信号対干渉比(SIR),ビット誤り率(BER)、電力予算等を含む。
[0166]
ピンポン現象を回避するために、いくつかの追加のパラメータが、ヒステリシスマージン、ドウェルタイマー、及び平均化ウィンドウ等の決定アルゴリズムによって利用される。高い移動車両の場合、モバイルホスト(MH)と接続点間の距離、携帯電話の速度、携帯電話の位置、トラフィックと帯域幅特性等の他のパラメータもピンポン現象を削減するために考慮に入れられる。
[0167]
さらに最近では、仮説検証、動的プログラミング等の技法及びパターン認識技法に基づいている異機種ネットワーク環境でのピンポン現象を削減するのに役立つ他のハンドオフアルゴリズムがある。ピンポン現象を削減するためにハンドオフアルゴリズムを実現することは重要であるが、この現象から回復するための方法を実現することも重要である。
[0168]
MPAフレームワークの場合には、ピンポン現象は現在のネットワークとターゲットネットワークの間、及び候補ターゲットネットワーク間での携帯電話の前後運動を生じさせる。その現在の形式でのMPAは、多数のトンネルセットアップ、バインディング更新の数、及び関連付けられたハンドオフ待ち時間のために影響を受ける。ピンポン現象はハンドオフ速度に関連しているため、それも遅延とパケット損失の一因となる可能性がある。
[0169]
いくつかの実施形態において、ピンポンの確率を削減するのに役立てるために実行できる複数のアルゴリズムをここで説明する。さらに、ピンポン現象から生じるパケット損失からの回復を可能にするMPAフレームワークのためのいくつかの方法もここで説明する。
[0170]
いくつかの実施形態では、MPAフレームワークは、グローバルポジショニングシステム(GPS)を使用して近接するネットワーク内のAPに関して携帯電話のジオロケーションを利用できる。この点で、例示的なGPSシステムは地球を軌道に乗せ、GPS受信機がその地理的な位置を正確に示すことができるようにする様々な衛星を含む。ネットワーク間の発振を回避するために、位置をベースにしたインテリジェントアルゴリズムはユーザの位置と、前のハンドオーバ試行からキャッシュに入れられたデータの相関関係を使用することにより導出できる。場合によっては、位置だけがハンドオフ決定のための唯一のインジケータではないことがある。例えば、マンハッタン(Manhattan)タイプのネットワークでは、携帯電話はAPに近いけれども、それは良好な接続を行うほど十分な信号対雑音比(SNR)を有さないことがある。したがって、モビリティパターン及び経路特定がピンポン現象の回避に役立つことがある。
[0171]
ピンポン現象を回避できる良好なハンドオフアルゴリズムがない場合には、ピンポンの影響を緩和するために優れた回復機構を適所に配置することが必要とされることがある。携帯電話が、コンテキストが前回試用されたネットワークに戻るときにそれが迅速に回復できるように、確立されたコンテキストをある期間現在のネットワークに保持しなければならない場合がある。これらのコンテキストはセキュリティ関連付け、使用IPアドレス、確立されたトンネル等を含んでよい。また、所定の期間、データを前のネットワークと新しいネットワークの両方にバイキャスティングすると、携帯電話がネットワーク間で前後に移動する場合に損失したパケットを処理するのに役立つであろう。携帯電話は、それがピンポン状況に関して安定した状態にあるかどうかを判断できなければならない。
[0172]
9.リンク層セキュリティ及び移動性
事前認証段階の間にモバイルノードとCTN内の認証エージェントの間で確立されたMPA−SAを使用すると、モバイルノードが以下のように現在のネットワークにある間にCTN内のリンク層セキュリティをブートすることができる。
[0173]
1.CTN内の認証エージェントとモバイルノードは、事前認証が成功した結果確立されるMPA−SAを使用してPMK(ペアワイズマスタキー)(前記参考資料[I-D.ietf-eap-keying]を参照されたい)を導出する。EAPとAAAプロトコルの実行は、MPA−SAを確立するための事前認証の間に必要となる可能性がある。PMKからは、モバイルノードのための別々のTSK(過渡的セッションキー)(前記[I-D.ietf-eap-keying]を参照されたい)がCTNの各接続点に直接的に又は間接的に導出される。
[0174]
2.認証エージェントはPMKから導出され、接続ポイントへの安全な関連付けのために使用されるキーをインストールしてよい。導出されたキーはTSK又はTSKが導出される中間キーであってよい。
[0175]
3.モバイルノードがターゲットネットワークとしてCTNを選び、(ここでモバイルノードの新しいネットワークになる)ターゲットネットワーク内の接続ポイントに切り替わった後に、それは、モバイルノードと接続ポイント間のリンク層パケットを保護するために使用されるPTK(ペアワイズ過渡的キー)とGTK(グループ過渡的キー)(前記参考文献[I−D.ietf−eap−keying]を参照されたい)を確立するために、PMKを使用してIEEE 802.11i4通りハンドシェイク[802.11i]等の安全関連プロトコルを実行する。EAP認証の追加の実行はここで必要とされない。
[0176]
4.モバイルノードが新しいネットワークの中でローミングしている間、モバイルノードは、その接続ポイントと安全関連プロトコルを実行しさえすればよく、EAP認証の追加の実行は必要とされない。MPAの、802.11r等のリンク層ハンドオーバ最適化機構の統合は、このように達成できる。
[0177]
モバイルノードはTSKを導出するためにCTN内の接続ポイントのリンク層アイデンティティを知る必要がある場合がある。PANAが事前認証のための認証プロトコルとして使用される場合、これはPAA(前記参考文献[I-D.ietf-pana-pana]を参照されたい)から送信されるPANA−Bind−Requestの中でDevice−Id AVPを搬送することにより可能であり、それぞれの属性値組(AVP)は異なったアクセスポイントの基本サービスセット識別子(BSSID)を含む。
[0178]
図3を参照すると、図はいくつかの例示的な実施形態に従ってリンク層セキュリティをブートすることを図表で描いている。
[0179]
10.初期ネットワーク接続での認証
モバイルノードが最初にネットワークに接続すると、ネットワークアクセス認証はMPAを使用するかどうかに関係なく発生するであろう。MPAがハンドオーバ最適化のために使用されるときにネットワークアクセス認証のために使用されるプロトコルは、IEEE 802.1X等のリンク層ネットワークアクセス認証プロトコル、又はPANA等のさらに上位層のネットワークアクセス認証プロトコルである場合がある。
[0180]
11.セキュリティの考慮事項
本明細書は、モバイルノードと、モバイルノードが将来移動する可能性のある1つ又は複数の候補ターゲットネットワーク間でハンドオーバに関連するシグナリングを実行することに基づいた安全ハンドオーバ最適化機構のフレームワークを説明している。このフレームワークは、モバイルノードが物理的にそれらのCTNの内の1つに接続する前のCTNから現在のネットワーク内のモバイルモードへのデータパケットリダイレクトだけではなく、CTNからのリソースの獲得も必要とする。
[0181]
候補ターゲットネットワークからのリソースの獲得は、許可されていないモバイルノードがリソースを取得するのを防ぐために適切な認証手順及び許可手順を伴わなくてはならない。このため、MPAフレームワークがモバイルノードと候補ターゲットネットワークの間で事前認証を実行することが重要である。事前認証の結果として生成されたMN−CAキー及びMN−ARキーは、以後のハンドオーバシグナリングパケットと、モバイルノードとCTNの中のMPA機能要素の間で交換されるデータパケットとを保護できる。
[0182]
MPAフレームワークは、ハンドオーバが複数の管理ドメイン全体で実行されるときにもセキュリティ問題に取り組む。MPAを用いると、モバイルノードと、候補ターゲットネットワーク内のルータ又はモビリティエージェントの間の直接的な通信に基づいてハンドオーバシグナリングを実行できる。これにより、セキュリティ(前記参考文献[I-D.ietf-eap-keying]を参照されたい)に関して公知の制限が存在するコンテキスト転送プロトコルに対する必要性が排除される。このため、MPAフレームワークは管理ドメイン又はアクセスルータ間の信頼関係を必要とせず、モバイル環境でのセキュリティを傷つけずに、フレームワークをインターネットの中でさらに配備しやすくする。
[0183]
本発明の幅広い範囲
本発明の例示的な実施形態を本明細書に説明してきたが、本開示に基づいて当業者により理解されるように、本発明は本明細書に説明されている多様な好ましい実施形態に限定されるのではなく、同等な要素、変型、省略、(例えば、多様な実施形態全体での態様の)組み合わせ、適応、及び/又は改変を有するあらゆるすべての実施形態を含む。(例えば、後に加えられるものを含む)請求項における制限は請求項で利用される言語に基づいて幅広く解釈されるべきであり、本明細書に、あるいは出願の手続き追行の間に説明される例に限定されず、その例は包括的と解釈されるべきである。例えば、本開示では、用語「好ましくは」包括的であり、「好ましいが、限定されない」を意味する。本開示では、及び本開示の手続き追行中、手段プラス機能(means-plus-function)又はステッププラス機能(step-plus-function)の制限は、特定の請求項の制限について、以下の条件のすべてがその制限内に存在する場合にだけ利用される。つまりa)「のための手段」又は「のためのステップ」は、明示的に列挙され、b)対応する機能は明示的に列挙され、及びc)その構造をサポートする構造、材料又は行為が列挙される。本開示において、及び本出願の手続き追行中、用語「本発明」又は「発明」は、本開示の中で1つ又は複数の態様に対する参照として使用されてよい。言語本発明又は発明は、臨界の識別として理解されてはならず、すべての態様又は実施形態全体で当てはまると不適切に解釈されてはならず(つまり、本発明は多数の態様と実施形態を有することが理解されるべきである)、出願つまり請求項の範囲を制限すると不適切に解釈されてはならない。本開示では、及び本願の手続き追行の間、用語「実施形態」は任意の態様、特徴、プロセス又はステップ、その組み合わせ、及び/又はその任意の部分等を説明するために使用できる。いくつかの例では、多様な実施形態は重複する特長を含むことがある。本開示では、以下の省略された用語、つまり「例えば」を意味する「e.g.」が利用されてよい。

Brief Description of Drawings

[0184]
[fig. 1] いくつかの例示的な実施形態に従って基本的な通信の流れを描く流れ図であり、流れ図は図2で続行する。
[fig. 2] 図1に示される流れ図の続きの基本的な通信の流れを描く流れ図である。
[fig. 3] いくつかの例示的な実施形態に従ってリンク層セキュリティをブートすることを描く図である。
[fig. 4] 本発明のいくつかの例示的な実施形態に従って、例示的なアクセスポイント及び例示的なクライアントデバイス又はユーザ局の典型的なサブコンポーネントを示すアーキテクチャ図である。

Claims

[1]
媒体非依存事前認証フレームワークにおいて第1のネットワークと第2のネットワーク間でのモバイルノードの切り替え復帰に関連するハンドオフ決定を制御する方法であって、
a)隣接ネットワーク内のアクセスポイントに関して位置決定をするように構成される位置決定モジュールをモバイルノードに提供することと、
b)少なくとも前記位置決定モジュールの出力に基づいて、前記第1のネットワークと第2のネットワーク間の発振を回避するために 、前記モバイルノードの事前ハンドオーバアクティビティに関して、少なくともモバイルノード位置とキャッシュ化データとの相関関係、モビリティパターン及び経路特定に部分的に基づいた位置をベースにしたアルゴリズムを使用することと、
を有する、方法。
[2]
前記事前ハンドオーバアクティビティは事前認証、事前構成、安全先行ハンドオーバの手順を含み、前記キャッシュ化データは少なくともアクセスポイントのIPアドレスを含む、請求項1に記載の方法。
[3]
前記キャッシュ化データは、前記モバイルノード上のデジタルデータ記憶装置に記憶される、請求項2に記載の方法。
[4]
前記位置ベースのアルゴリズムは、前記モバイルノードが前記第1のネットワークと前記第2のネットワークの他方に切り替わった過去事例に関連するデータに基づき前記第1のネットワークと前記第2のネットワークの前記他方への切換を規定することを含む、請求項2に記載の方法。
[5]
前記位置ベースのアルゴリズムは、前記モバイルノードが前記第1のネットワークと前記第2のネットワークの他方に切り替わらなかった過去事例に関連するデータに基づき前記第1のネットワークと前記第2のネットワークの前記他方に切り替わらないことを規定することを含む、請求項2に記載の方法。
[6]
前記位置決定モジュールはGPS受信機を含む、請求項1に記載の方法。
[7]
前記少なくとも1つの非位置決めインジケータは信号対雑音比のインジケータを含む、請求項1に記載の方法。
[8]
前記アルゴリズムは前記モバイルノード内でのプログラミングを介して実行される、請求項1に記載の方法。
[9]
前記アルゴリズムは、前記モバイルノードにとって外部のプログラミングを介して少なくとも部分的に実行される、請求項1に記載の方法。
[10]
前記モバイルノードと前記第2のネットワーク上の認証エージェントとの間にリンク層にとらわれないネットワークアクセス認証プロトコルを使用して事前認証を実行することをさらに含む、請求項1に記載の方法。
[11]
複数の管理ドメイン全体で事前認証を実行することをさらに含む、請求項1に記載の方法。
[12]
前記第1のネットワークは第1の媒体用であり、前記第2のネットワークは別の媒体用であり、前記第1の媒体がセルラーで、前記別の媒体が無線LANであるか、または前記第1の媒体が無線LANで、前記別の媒体がセルラーであるかのどちらかである、請求項1に記載の方法。
[13]
ネットワークアクセス認証プロトコルとしてPANAをさらに利用する、請求項2に記載の方法。

Drawings

[ Fig. 1]

[ Fig. 2]

[ Fig. 3]

[ Fig. 4]