JP2009515381A - マネージド・バッファ・ノードによるハンドオフ中のパケットロス防止 - Google Patents

マネージド・バッファ・ノードによるハンドオフ中のパケットロス防止 Download PDF

Info

Publication number
JP2009515381A
JP2009515381A JP2008535730A JP2008535730A JP2009515381A JP 2009515381 A JP2009515381 A JP 2009515381A JP 2008535730 A JP2008535730 A JP 2008535730A JP 2008535730 A JP2008535730 A JP 2008535730A JP 2009515381 A JP2009515381 A JP 2009515381A
Authority
JP
Japan
Prior art keywords
node
buffer node
buffer
network
access point
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.)
Granted
Application number
JP2008535730A
Other languages
English (en)
Other versions
JP4991733B2 (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.)
Iconectiv LLC
Original Assignee
Telcordia Technologies Inc
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
Priority claimed from US11/456,807 external-priority patent/US7826424B2/en
Application filed by Telcordia Technologies Inc filed Critical Telcordia Technologies Inc
Publication of JP2009515381A publication Critical patent/JP2009515381A/ja
Application granted granted Critical
Publication of JP4991733B2 publication Critical patent/JP4991733B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/10—Flow control between communication endpoints
    • H04W28/14—Flow control between communication endpoints using intermediate storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/02—Buffering or recovering information during reselection ; Modification of the traffic flow during hand-off

Abstract

好ましい実施形態において、ワイヤレス・ネットワーク・システムは、モバイル・ノードに送信されたデータパケットをバッファリングすることを特徴とする。そのシステムは、モバイル・ノードには見えないため、モバイル・ノードは、ネットワークからのサービスを要求する必要がない、すなわちネットワークとサービスパラメータを交渉する必要がない。ＥＡＰＯＬ−Ｓｔａｒｔとバインディング更新メッセージが、バッファリングを起動させかつ終了させ、また事前認証とスムーズなハンドオフ報告をそれぞれ開始する。

Description

本発明は、概ねワイヤレス・ネットワーキングに関するものであり、幾つかの好ましい実施形態においてはネットワーク層およびリンク層転移に起因するパケット紛失の防止に関するものである。
本出願は「マネージド・バッファ・ノード・アーキテクチャーによるハンドオフ中のパケットロス防止」と題する２００５年１０月１１日付け出願に係る米国仮出願第６０／５９６，６６０号の優先権の主張を伴うものであり、その開示内容はレファレンスとしてそっくりそのまま本願に導入される。本出願は、［１］２００５年１０月１１日付け出願に係る米国仮出願第６０／５９６，６５９号、［２］メディア独立型事前認証のフレームワークと題する２００６年３月９日付け出願に係る米国仮出願第１１／３０８，１７５号、［３］２００１年６月１日付け出願に係る米国特許出願第０９／８７２，２１３号に関するものであり、［１］から［３］の各出願の開示内容は、レファレンスとしてそっくりそのまま本願に導入される。以下のＩＥＴＦ文献の開示内容もレファレンスとしてそっくりそのまま本願に導入される（ｗｗｗ．ｉｅｔｆ．ｏｒｇを参照）：［１］ｄｒａｆｔ−ｋｒｉｓｈｎａｍｕｒｔｈｉ−ｍｏｂｉｌｅｉｐ−ｂｕｆｆｅｒ６−００．ｔｘｔ、［２］ｄｒａｆｔ−ｉｅｔｆ−ｍｉｐｓｈｏｐ−ｆａｓｔ−ｍｉｐｖ６−０３．ｔｘｔ、［３］ｄｒａｆｔ−ｍｋｈａｌｉｌ−ｍｏｂｉｌｅｉｐ−ｂｕｆｆｅｒ−００．ｔｘｔ、［４］ｄｒａｆｔ−ｍｏｏｒｅ−ｍｏｂｏｐｔｓ−ｔｕｎｎｅｌ−ｂｕｆｆｅｒｉｎｇ−００．ｔｘｔ
モバイルネットワークは、セキュリティー、およびスムースなハンドオフを確保し、データロスを最小限に抑え、かつ遅延を最小
限に抑える必要がある。既存のネットワークはその多くがモバイル・ノード（MN）とバッファリング・ノード（BN）との間で通信をしている。このようなバッファリング・サービスは、モバイル・ノード(MN)が明確にサービスを要請することが必要であるため不十分である。その結果、ワイヤレス信号のトラフィック量が多く、モバイル・ノード(MN)のエネルギー使用量も多いため、合意が得られるまでのメッセージの送信及び受信のためのエネルギー量が低減する。
既存のネットワークの幾つかの問題点について以下に詳述する。
１つの問題点は、ＩＰｖ６ルーターへの拡張に関連するものであり、それはバッファリングをサポートする能力を通知することをルーターに求め、モバイル・ノード(MN)が望ましいバッファサイズをバッファリング・ノード(BN)に求めることを必要とするため、大量のメッセージが必要となる。サービスに関する調査と応答及びサービス・ネゴシエーションはもとより、バッファリング・ノード(BN)・ディスカバリーに関する大量のメッセージは、不十分なネットワーク資源を消費するだけではなく、追加的な待ち時間をネットワークに加える。
もう一つの問題点は、バッファサイズに関連するものである。モバイル・ノード
(MN)がひとたびバッファリング・サービスが利用可能であるという公示を受けたら、モバイル・ノード (MN)は、特定のバッファサイズを要求する。利用可能な資源に応じて、バッファリング・ノード(BN)は、その要求に応じたり応じなかったりする。バッファリング・ノード(BN)は、バッファプロトコルによって拘束されることがあり、その場合、モバイル・ノード (MN)の要求が上限を超えた場合は、バッファリング・ノード(BN)は、より小さなバッファーサイズを提供する可能性がある。更に、バッファリング・ノード(BN)の利用可能な資源が非常に少ない場合、快適なバッファサイズを求めてモバイル・ノード(MN)にメッセージを行ったり来たりして送信し、妥協状況に到達しようとする。そのような交渉にもかかわらず、サービスの要求は結果的に却下される場合もある。このプロセスによると、バッファリング・ノード(BN)が主導権を持ち、モバイル・ノード(MN)はバッファリング・ノード(BN)に送信しようとしているデータパケットを保護するオプションを持たないということになる。バッファリング・ノード(BN)がサービスを拒否した場合には、モバイル・ノード(MN)には別の方法がないため、モバイル・ノード(MN)は、バッファリング・ノード(BN)との通信を確立できず、時間とエネルギーを無駄にする。
もう一つの問題点は、ルーターが、資源不足の理由でバッファリングの新たなリクエストを受け付けることが出来なくても、バッファ可能であると通知し続け、初期設定リクエストに拒否応答する場合が生じることである。ルーターは、ハンドオフ・オペレーションに悪影響を及ぼすためバッファリングできない場合でも通知を中断する機能をもたない。この状況は、ネットワークに不必要な負担を与えるうえ、提供できないサービスを宣伝するため非合理的でもある。
もう一つの問題点は、ネットワーク・コントロールド・モバイル・アシステッド（ＮＣＭＡ）ハンドオフモードにおいて制御プロトコルのバッファリングに関するモバイル・ノード(MN)の動きのネットワーク認識に関するものである。その場合、前のルーターが、ハンドオフが実際に行われる前に新しいルーターにモバイル・ノード(MN)の現状情報を提供し、またモバイル・ノード(MN)の干渉なしに新しいルーターにバッファされたパケットを転送する。従って、モバイル・ノード(MN)は、ネットワークと交渉しあるいはバッファリングの初期化とその後のバッファされたパケットの転送を積極的にリクエストする必要はない。しかしながら、多くの場合、モバイル・ノード(MN)は、プロトコルがモバイル・ノード(MN)にそうすることを要求するため依然として交渉を行なわなければならない。従って、ネットワーク・コントロールド・モバイル・アシステッド（ＮＣＭＡ）の場合でも、モバイル・ノード(MN)は、ルーターのサービスの通知を受け取るために、新しいルーターにスムーズ・ハンドオフ・イニシャリゼーション（ＳＨＩＮ）を常に発行する必要がある。
更に他の問題点は、モバイル・ノード(MN)に予測されるバッファ・サイズとバッファ使用時間の送信を要求するバッファリング・コントロール・プロトコルに関するものである。インターネット・プロトコル（ＩＰ）のトラフィックは、バースト性、即ち、データが1つのデバイスから他のデバイスに継続的に絶え間なく転送されるものであるため、モバイル・ノード(MN)の予測は正確ではないことがあり、事前バッファリング・サイズを大きくあるいは小さく見積もってしまう結果となる。たとえ仮にモバイル・ノード(MN)が正確に予測したとしても、モバイル・ノード(MN)が要求するバッファ・サイズが直ちに利用できず、バッファリング・ノード(BN)が他のモバイル・ノード(MN)のサービスを終えて少したってから利用可能になる場合もある。この瞬時の決定（許容、拒否、あるいは妥協）は、その瞬間に存在する状態だけに基づくものであり、近い将来の状況を考慮していない。
更にもう一つの問題点は、バッファリング・ノード(BN)が自動的にモバイル・ノード(MN)からメッセージ（即ち、ＢＲｅｑ［ｓｔｏｐ］）を受信しないままバッファリングを終了するため、モバイル・ノード(MN)とバッファリング・ノード(BN)の双方の効率的な動作に影響を及ぼす「時限タイムアウト」事態が発生することである。事実、ＢＲｅｑ［ｓｔｏｐ］というメッセージには、二つの目的がある。第１は、そのメッセージは、バッファリングを終了させることであり、第２は、バッファリング・ノード(BN)に新しい気付アドレスＣｏＡ（ケア・オブ・アドレス）を知らせることである。時限タイムアウトが発生した場合、バッファリング・ノード(BN)は、ＢＲｅｑ［ｓｔｏｐ］メッセージとフラッシング・デスティネーション（ＣｏＡ）を受信しないままバッファリングを終了する。この事態を乗り越えるには、モバイル・ノード(MN)は、バッファリング・ノード(BN)と新しい気付アドレスＣｏＡに別の「ＢＲｅｑ［ｅｘｔ］」メッセージを送信してバッファ時間の延長を要求する必要がある。このような事態が繰り返し発生する場合、バッファリング・ノード(BN)は、（データパケットをフラッシュするのに最後の気付アドレスＣｏＡを使用するが）複数の気付アドレスＣｏＡを受信することになる。この事態の全容は、必要とされるシグナルの負担を増やして幾つかの気付アドレスＣｏＡの不必要な情報を保持するために必要なメモリーを無駄にするため、望ましくはない。また、モバイル・ノード(MN)は、時限タイムアウト期間が終了する前にＢＲｅｑ［ｅｘｔ］メッセージを送信する必要があるため、モバイル・ノード(MN)のバッテリー寿命は悪影響を受ける。
前述の説明に鑑みて、ハンドオフ中の移動におけるパケットロス防止を提供する総合的なバッファリング・サービスを提供するのに使用される完全なアーキテクチャーを含む改良されたバッファリング・サービスがワイヤレス・ネットワーク技術において必要とされる。特に、本発明の改良されたバッファリング・サービスは、懇請あるいは交渉なしでモバイル・ノード(MN)の必要性に最も合う最大バッファ・サイズを提供するように利用される上手く管理されたバッファリング・アーキテクチャーを提供し、またモバイル・ノード(MN)の現在のアプリケーション、モバイル・ノード(MN)がローミングしているネットワーク速度、及び近い将来の需要及び資源予測を含む複数のエレメントに基づいてバッファ・サイズを確保し、またバッファリング・ノード(BN)が、モバイル・ノード(MN)の援助なしで他のピアバッファリング・ノード(BN)とネットワーク・エンティティーと通信してタスクを実行できるように完全に自立し、またモバイル・ノード(MN)が特定のサービスと通信することを可能にする新たなプロトコルを導入しないで実行する。
本発明の好ましい実施形態は、先行技術を大幅に改善することができ、ハンドオフ中に移動するパケットにパケットロス防止を提供する総合的バッファリングサービスを提供するように利用される完全アーキテクチャーを含むワイヤレス・ネットワーク技術において必要とされる改良されたバッファリングサービスの問題の解決法を提供するものである。
本発明の一つの側面によると、コントローリング・バッファ・ノード（ＣBN）、トランジション・バッファ・ノード（ＴBN）、及びフラッシング・バッファ・ノード（ＦBN）の機能エンティティーを含むマネージド・バッファ・ノード・アーキテクチャーが提供される。前記コントローリング・バッファ・ノードは、管理的な機能を実行し、前記トランジション・バッファ・ノードは、移動中のデータを保持し、そして前記フラッシング・バッファ・ノードは、データパケットの配信を手助けする。更に、本発明のこの実施形態によると、これらノードは、内部でお互いに通信し（即ち、例えば、モバイル・ノード(MN)などの外部エレメントと直接通信しない）、セキュリティーの侵害の傾向が低い。アクセスポイント（ＡＰ）は、複数のアクセスポイントと通信する特別な機能を持つ制御的な役割を果たす。
本発明の一つの側面によると、制御する権限を持ち複数の機能を実行するコントローリング・バッファ・ノード(ＣBN)が提供される。コントローリング・バッファ・ノード(ＣBN)は、モバイル・ノード(MN)が現在位置するアクセスポイント（ＡＰ）からＥＡＰＯＬ−Ｓｔａｒｔ（エクステンシブル・オソリゼーション・プロトコル・オーバー・ＬＡＮ）メッセージのコピーを受信し、情報を引き出すことができ、またそれ自身のデータベースから、トランジション・バッファ・ノード(ＴBN)のＩＰアドレスを取り出してそのトランジション・バッファ・ノード(ＴBN)にバッファリングを開始させることができ、また前のルーターを介してモバイル・ノード(MN)からバインディングアップデートのコピーを受信して、新しいネットワークにおけるモバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）を引き出すことができ、また管理的理由でトランジション・バッファ・ノード(ＴBN)とフラッシング・バッファ・ノード(ＦBN)から情報を収集することができる。
本発明の一つの実施形態によると、トランジション・バッファ・ノード(ＴBN)は、モバイル・ノード(MN)がハンドオフするのを示すコントローリング・バッファ・ノード(ＣBN)からメッセージを受信し、またユーザーのアプリケーション、現在利用可能資源、及びデータ転送速度により更に決定される、適切なバッファ・リース・タイム（ＢＬＴ）を割り当て、また必要な場合にバッファ・リース・タイム（ＢＬＴ）を延長し、またメモリー容量を効果的に配分する圧縮アルゴリズムを実行し、またモバイル・ノード(MN)がハンドオフを完了したという第２メッセージをコントローリング・バッファ・ノード(ＣBN)から受信し、またサービスが上手く送信できななかった場合にバッファ・パケットをドレインさせ、アプリケーションに従って受信パケットを保存し、また管理機能を実行する際にコントローリング・バッファ・ノード(ＣBN)を補助し、また管理機能を実行する際にコントローリング・バッファ・ノード(ＣBN)に連絡する、という複数の機能を実行することができる。
本発明の一つの実施形態によると、フラッシング・バッファ・ノード（ＦBN)）は、トンネル・ターミネーション・ポイントの役目をしてトランジション・バッファ・ノード(ＴBN)からパケットを受信し、またパケットをカプセル解除して、それらを更にモバイル・ノード(MN)に送信されるように直ちにアクセスポイント（ＡＰ）に送り出し、また、ピア・バッファリング・ノードからパケットを受信する、ことを含む複数の機能を実行することができる。
本発明の他の実施形態によると、コントローリング・バッファ・ノード(ＣBN)は、アクセスポイント（ＡＰ）の宛先アドレスを受信した後、トランジション・バッファ・ノード(ＴBN)に「リリース・バッファ」のトリガーを発行して特定のフラッシング・バッファ・ノード(FBN)へのパケットのトンネリングを始動させる。コントローリング・バッファ・ノード(CBN)，トランジション・バッファ・ノード(TBN)及びフラッシング・バッファ・ノード(FBN)のＩＰアドレスは、静的あるいは動的に割り当てられても良く、追加的なセキュリティーのために非公開でネットワークの外部からは見えないものとしても良い。
本発明の他の実施形態によると、バッファリング資源の需要を予測するのにＡＲＩＭＡ（オートリグレッシブ・インテグレーテッド・ムービング・アベレージ）モデルを使用し、そのモデルを適用して将来のバッファリング資源需要を予測するものであり、各コントローリング・バッファ・ノード(CBN)は、正確、精密、かつ効果的にバッファリング資源を予測して十分な量を確保できるように備える。
本発明の好ましい実施形態は、添付図面において、限定としてではなく、例示として示されている。
図１は、本発明の実施形態に係るマネージド・バッファ・ノード・アーキテクチャーの図である。 図２（ａ）は、本発明の実施形態に係るコントローラー・バッファ・ノード・タスクの図である。 図２（ｂ）は、本発明の実施形態に係る図１（ａ）のタスクごとのコントローリング・バッファ・ノードにより構成された表である。 図３（ａ）は、本発明の実施形態に係るトランジット・バッファ・ノード・タスクの図である。 図３（ｂ）は、本発明の実施形態に係るプロセッサ機能のチャートである。 図４は、本発明の実施例に係るフラッシング・バッファ・ノード（FBN)）タスクの図である。
本発明は、多数の異なる形態で具体化されているが、多数の実施例は、本開示は本発明の原理の例を提供するものであり、その実施例は本発明を本書に説明及び/又は図解された好ましい実施形態に限定するものではないという了解の下で、本書において説明されている。
図１は、本発明の実施形態に係るマネージド・バッファ・ノード・アーキテクチャーの概要を示すものである。アーキテクチャーは、以下の機能エンティティーで構成されている。即ち、コントローリング・バッファ・ノード（CBN)）、トランジット・バッファ・ノード（TBN)及びフラッシング・バッファ・ノード（FBN）である。それぞれのエンティティー即ちノードは、特定タスクを行う。例えば、コントローリング・バッファ・ノード(CBN)は、管理的機能を実行し、トランジション・バッファ・ノード(TBN)はトランジット中のパケットを保持し、フラッシング・バッファ・ノード(FBN)は、パケットの転送を円滑にする。セキュリティーを高めるために、これらノードは、内部でお互いに通信する。このアプローチは、外部エレメントがノードと通信しないため、外部からのセキュリティー攻撃の恐れを低減させる。コントローリング機能を持つアクセスポイント（ＡＰ）は、他のアクセスポイント（ＡＰ）と通信することができる特別な機能をも持っている。各ノードの特有のタスクを、以下に詳述する。
コントローリング・バッファ・ノード（CBN)）の主要タスクは、コントロール・オソリティーとしての役目である。図２に表示されているように、コントローリング・バッファ・ノード(CBN)は、モバイル・ノード（MN)）の位置について報告するアクセスポイント（ＡＰ）からＥＡＰＯＬ−Ｓｔａｒｔメッセージのコピーを受信する（即ち、新しいネットワークに移動する前に）。そのメッセージを受信した後、コントローリング・バッファ・ノード（ＣＮＢ）は、それ自身のディレクトリーに保存されている、以下の情報を引き出す。即ち、（ＥＡＰＯＬ−Ｓｔａｒｔメッセージが受信される）アクセスポイント（ＡＰ）のソースアドレス、（モバイル・ノード(MN)が現在位置するネットワークに指定される）モバイル・ノード(MN)の現在のアドレス、及び（モバイル・ノード(MN)が事前認証をリクエストして移動しようとしている）アクセスポイント（ＡＰ）の宛先アドレスである。
コントローリング・バッファ・ノード(CBN)は、モバイル・ノード(MN)が現在位置するネットワークを扱うトランジション・バッファ・ノード(TBN)のＩＰアドレスを含む多様な情報を受信して処理する。コントローリング・バッファ・ノード(CBN)は、次に、バッファリングを開始するように（モバイル・ノード(MN)と関連する）トランジション・バッファ・ノード(TBN)に指示を出す。その指示は、モバイル・ノード(MN)が位置するアクセスポイントのＭＡＣ層マネージメント・エンティティー（ＭＬＭＥ）からＥＡＰＯＬ−Ｓｔａｒｔメッセージが受信された時にトランジション・バッファ・ノード(TBN)に発行される。
更に、コントローリング・バッファ・ノード(CBN)は、前のルーター（あるいはＩＰｖ４の場合、フォーリン・エージェント）を通じてモバイル・ノード(MN)からバインディング・アップデートのコピーを受信する。バインディング・アップデート・メッセージを受信した後、コントローリング・バッファ・ノード(CBN)は、モバイル・ノード(MN)が新しいネットワークに移動した後、そのネットワークのモバイル・ノード(MN)の新しいアドレス（新しいＣｏＡとも称される）を取り出す。
コントローリング・バッファ・ノード(CBN)は、モバイル・ノード(MN)の気付アドレス（ＣｏＡ）をモバイル・ノード(MN)のホームアドレスと結合あるいは登録するバインディング・アップデートにおいて受信したアドレスで正規にマップされたフラッシング・バッファ・ノード(FBN)の自身のデータベースから正確なフラッシング・バッファ・ノード(FBN)のＩＰアドレスを取り出す。
更にもう一つの機能において、コントローリング・バッファ・ノード(CBN)は、管理機能のためにトランジション・バッファ・ノード(TBN)とフラッシング・バッファ・ノード(FBN)から情報を収集する。コントローリング・バッファ・ノード(CBN)管理は、望まれた方針に従って決定されるため、ユーザーは、利用可能な容量、使用容量、予測される需要を含む多様な情報をトランジション・バッファ・ノード(TBN)とフラッシング・バッファ・ノード(FBN)から反復的に収集するようにコントローリング・バッファ・ノード(CBN)に指示する。コントローリング・バッファ・ノード(CBN)は、その後、効率的に管理されたネットワークを保証して最適なバッファリングを実現するためのロード・バッファリングにその情報を使用する。
トランジション・バッファ・ノード(TBN)は、以下に詳述する多様な機能を実行する。図３に示すように、トランジション・バッファ・ノード(TBN)の機能の一つは、モバイル・ノード(MN)がハンドオフを実行しようとしていることをトランジション・バッファ・ノード(TBN)に知らせるメッセージをコントローリング・バッファ・ノード(CBN)から受信することである。ある場合には、そのメッセージは、「バッファ開始」のトリガーとして解釈される。コントローリング・バッファ・ノード(CBN)は、前の情報と共に、アクセスポイントから受信されたＥＡＰＯＬ−Ｓｔａｒｔメッセージから抽出されたモバイル・ノード(MN)の現在のアドレスの情報を含む。次に、トランジション・バッファ・ノード(TBN)は、モバイル・ノード(MN)行きの全種類のトラフィックパケットをインターセプトし保存し始める。また、トランジション・バッファ・ノード(TBN)は、積極的にモバイル・ノード(MN)とバッファリング条件あるいは能力について交渉しないため、トランジション・バッファ・ノード(TBN)は、透過的そして効果的に機能する。
トランジション・バッファ・ノード(TBN)は、トランジション・バッファ・ノード(TBN)がバッファリングサービスを提供できる時間である適切なバッファ・リース・タイム（ＢＬＴ）を配分する。バッファ・リース・タイム（ＢＬＴ）は、以下の幾つかの要因に基づいてトランジション・バッファ・ノード(TBN)によって決定される。即ち、ユーザー・アプリケーションの種類（リアルタイムあるいはリアルタイムではない）、現在利用可能な資源／近い将来に要求される資源（統計模型に基づく需要予測により決定される）、およびネットワークが提供するデータ速度である。
トランジション・バッファ・ノード(TBN)は、必要な場合、バッファ・リース・タイム（ＢＬＴ）自体を延長する。バッファ・リース・タイム（ＢＬＴ）の延長は、上記要因（ユーザー・アプリケーションの種類、現在利用可能な資源／近い将来に要求される資源、及びデータ速度）に基づいてトランジション・バッファ・ノード(TBN)によって計算される。許される延長の数値及びそれぞれの延長に割り当てられる時間は、例えば、サービス・プロバイダーが制定するポリシーに従う。一例が図３（ａ）に示されており、その延長ポリシーは、ＢＬＴ＝２／３ＢＬＴ（ｘ−ｙ）で定義される。但し、ｘはポリシー依存、ｘは、許される延長の最大数、そしてｙは、許可された延長の数である。
トランジション・バッファ・ノード(TBN)は、また、利用可能な幾つかの圧縮アルゴリズムあるいはプロトコルを使用してメモリー機能を効果的に利用するためにアルゴリズムを実行する。例えば、トランジション・バッファ・ノード(TBN)は、モバイル・ノード(MN)の現在のアドレスに相当する名前のディレクトリーを作成し、各パケットから同一の情報（例えば、ソース及び宛先アドレス）を取り除きながらパケットを保存し、そしてリリース時に更新アドレスヘッダーを再び付ける。上記に詳細に説明したアルゴリズム／プロトコルを実行することで、トランジション・バッファ・ノード(TBN)は、各アプリケーションに十分な量のメモリーを用意する。
トランジション・バッファ・ノード(TBN)は、ハンドオフが実行されたことを示すコントローリング・バッファ・ノード(CBN)から第２のメッセージを受信することがある。その第２メッセージも、「リリースバッファ」トリガーとして解釈され得る。トランジション・バッファ・ノード(TBN)への第２メッセージの一部分として、コントローリング・バッファ・ノード(CBN)は、モバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）及び扱っているフラッシング・バッファ・ノード(FBN)アドレスを含む。コントローリング・バッファ・ノード(CBN)は、前のネットワークルーターが送信したバインディング・アップデートからモバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）を入手し、モバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）でマップされた自身のデーターベースからフラッシング・バッファ・ノード(FBN)のアドレスを入手する。パケットをフラッシュする責任があるフラッシング・バッファ・ノード(FBN)は、モバイル・ノード(MN)が最近入ったネットワークにある。そのメッセージを受信すると、トランジション・バッファ・ノード(TBN)は、場合によってはＦＩＦＯ（先入れ先出し）方法で、各パケットにモバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）を加えてフラッシング・バッファ・ノード(FBN)に向ける。
トランジション・バッファ・ノード(TBN)は、サービスが上手くモバイル・ノード(MN)に配信されなかった場合、バッファパケットをドレインすることができる。配信が不可能であるとトランジション・バッファ・ノード(TBN)が決定すると直ちに、不必要なバッファパケットのメモリーをクリアすることで、トランジション・バッファ・ノード(TBN)は、他のモバイル・ノード(MN)への他のパケットの配信のために利用可能なメモリーを最大限にする。
トランジション・バッファ・ノード(TBN)は、アプリケーションに従って受信パケットも保存する。例えば、時間依存のアプリケーションが関係する場合、トランジション・バッファ・ノード(TBN)は、そのアプリケーションをそれほど時間依存でない他のアプリケーションより先に進めて優先させる。例えば、「最優先パケット」、「中間優先パケット」、そして「低優先パケット」の３つのカテゴリーを使用することがある。それらのパケットは、所定の方針あるいはプロトコルに従ってトランジション・バッファ・ノード(TBN)で処理される。最優先パケットの場合、これらは、最も時間に依存するパケットであり、最優先で配信される。優先度が中間のパケットは、許される延長の数が多数あるものであり、各延長に割り当てられた時間が制限される（例えば、一回限りのＢＬＴ延長）可能性がある。優先度の低いパケットは、配信の遅延を容認するものである。バッファ容量が使い果たされた場合、それらのパケットは、まず別のコントローリング・バッファ・ノード(CBN)に移動あるいは移転させられることがある。それらの組み合わせあるいは他のあらゆる組み合わせが異なる種類のパケット配信を行うのに使用されることがある。
トランジション・バッファ・ノード(TBN)も、利用可能容量、使用容量、予測される需要、そしてサービス配信報告に関する情報をコントローリング・バッファ・ノード(CBN)に提供するなどの、コントローリング・バッファ・ノード(CBN)の管理機能実行を直接補助する。コントローリング・バッファ・ノード(CBN)は、トランジション・バッファ・ノード(TBN)が提供するその情報を、負荷バランシングと効果的バッファリング情報に利用する。
更に、トランジション・バッファ・ノード(TBN)は、利用可能容量、使用容量、予測される需要、及びサービス配信報告に関する情報をコントローリング・バッファ・ノード(CBN)に提供するなどの管理機能に関連する情報をもった、補助するコントローリング・バッファ・ノード(CBN)に提供する。コントローリング・バッファ・ノード(CBN)は、負荷バランシングと効果的バッファリング情報にトランジション・バッファ・ノード(TBN)が提供するその情報を利用する。
本発明の一つの実施形態によると、フラッシング・バッファ・ノードは、図４にも説明されている以下の機能を実行する。即ち、フラッシング・バッファ・ノード(FBN)は、トランジション・バッファ・ノード(TBN)からパケットを受信してトンネル目的地点の役割をする。更に、フラッシング・バッファ・ノード(FBN)は、受信したパケットをカプセル解除してモバイル・ノード(MN)に送信されるようにすぐにアクセスポイント（ＡＰ）に発送する。フラッシング・バッファ・ノード(FBN)は、ピア・バッファ・ノードから配信のためだけのパケットも受信するうえ、対応するノード、アプリケーション・サーバーなどの外部エンティティーからパケットを受信するようになっている。しかしながら、フラッシング・バッファ・ノード(FBN)は、必要な場合、望ましい方針を反映、あるいはネットワーク内の必要性を満たすように設定することができる。
本発明の他の実施形態によると、コントローリング・バッファ・ノード(CBN)は、アクセスポイントＡＰ（モバイル・ノード(MN)が事前認証をリクエストして移動しようとしているＡＰ）の宛先アドレスを受け取ったとき、特定のフラッシング・バッファ・ノード(FBN)にパケットのトンネリングを開始するためにトランジション・バッファ・ノード(TBN)にリリース・バッファ・トリガー・メッセージを発行することができる。従って、トランジション・バッファ・ノード(TBN)は、仮気付アドレス（ＣｏＡ）を用意して、フラッシング・バッファ・ノード(FBN)は、その仮気付アドレス（ＣｏＡ）を、後でトランジション・バッファ・ノード(TBN)によりフラッシング・バッファ・ノード(FBN)に通信された最初の気付アドレス（ＣｏＡ）に置き換える。このプロセスは、パケット配信時間（「ジッター(jitter)」とも呼ばれる）を大幅に短縮するが、フラッシング・バッファ・ノード(FBN)がより効果的にストレージ容量を利用することも可能にする。更にセキュリティーを高めるために、コントローリング・バッファ・ノード(CBN)、トランジション・バッファ・ノード(TBN)、及びフラッシング・バッファ・ノード(FBN)に割り当てられたＩＰアドレスは、静的あるいは動的に割り当てられる。それらのアドレスは、非公開であり、外部には見えない。
本発明の他の実施形態によると、バッファ資源需要を予測する方法にＡＲＩＭＡプロセスが利用される。ＡＲＩＭＡプロセスは、確率変数の将来値が、現在の値にしか依存しないＷｅｉｎｅｒプロセスの一種である。ＡＲＩＭＡプロセスは、自己相関コンポーネントを含むものであり、確率変数の将来値は、過去の値に対する相関関係と、過去の変数の観察結果の誤差測定をフィルターする移動平均コンポーネントに基づく。ＡＲＩＭＡプロセスを応用することにより、トランジション・バッファ・ノード(TBN)は、モバイル・ノード（MN）のパケットをバッファするために必要なバッファリング資源Ｒ（ｔ）の量を局所的に予測する。
ＡＲＩＭＡプロセスは、本発明にとって有益な幾つかの利点がある。その１つの利点は、コントローリング・バッファ・ノード(CBN)が、他のコントローリング・バッファ・ノード(CBN)との通信を要求することなく、コントローリング・バッファ・ノード(CBN)に局所的予測を実行することを許容する、モバイル・ノード(MN)のバッファリング資源需要Ｒ（ｔ）を予測することである。ＡＲＩＭＡプロセスは、Ｒ（ｔ）の将来値が、他の変数に関係なく現在及び過去の値だけに依存するという原理に基づいている。これは、効率性と信頼性を向上させ、不要な通信を低減しバッファ資源需要を正確に予測することによって価格と複雑性を低減させる。
ＡＲＩＭＡプロセスのもう一つの利点は、コントローリング・バッファ・ノード(CBN)が平均ネットワーク資源需要ではなく、瞬間的なバッファリング資源需要を決定することを可能にするバッファリング資源需要Ｒ（ｔ）を予測することにあり、それによって将来のバッファリング資源需要の予測をより的確及び正確にする。
ＡＲＩＭＡプロセスの更に他の利点は、この予測モデルは、全ての確率予測に共通する２つの基本ステップを使用することである。第１ステップは、特定及び予測段階を実行することを含み、必要な自己回帰及び移動平均変数「ｐ」と「ｑ」がそれぞれ特定され、ＡＲＩＭＡ（ｐ、１、ｑ）の実際の自己回帰及び移動平均変数が推定される。第２ステップは、予測段階を実行することを含み、前記特定及び予測段階で構成されたＡＲＩＭＡ（ｐ、１、ｑ）モデルが、バッファリング資源需要の過去の観察に基づいて将来のバッファリング資源需要を予測するのに使用される。
ＡＲＩＭＡ（ｐ、１、ｑ）モデルは、結果的には、バッファリング資源需要を予測して、将来の需要を予測するのにそのモデルを使用して、それぞれのコントローリング・バッファ・ノード(CBN)が、十分な量のバッファリング資源を正確、明確及び効果的に予測して確保する。
正確な予測プロセスの必要性の一例として、期間「ｔ」のハンドオフ中のパケットロスを防止するには、トランジション・バッファ・ノード(TBN)が、「ｒｔ」の値までバッファできることが必要である。但し、「ｒ」は媒体の送信速度、「ｔ」はハンドオフの時間である。従って、送信速度が１１Ｍｂｐｓでハンドオフが４秒を必要とする場合、４４Ｍｂのバッファが必要である。送信速度とハンドオフ期間が大きくなるにつれて、必要なバッファサイズも大きくなる。「高速ハンドオフ」の場合でも、大量のバッファリングが必要であり、正確な予測プロセスが必要とされる。
新しいアクセスポイント（ＡＰ）と結合する前のモバイル・ノード(MN)
図１を参照して、ステップ１は、モバイル・ノード（MN）がビーコンを受信して新しいアクセスポイント（ＡＰ）を探しているのを示すものである。通常のビーコンのフレームは、以下の情報を持っている。即ち、サポートされるデータフローの速度（例えば、８０２．１１ｂでは１１Ｍｂｐｓなど）、サービスセット・アイデンティファイヤ（ＳＳＩＤ、特定のワイヤレスＬＡＮに属する）、機能情報（ＬＡＮに属すること望むステーションの必要条件）、ビーコンインターバル（送信間の時間）、タイムスタンプ（アクセスポイント（ＡＰ）の関係するステーション同士の同期化を可能にする）、パラメータ集合（例えば、特定のシグナリング方法に関する情報など）、及び／又はトラフィック・インディケーション・マップ（ＴＩＭ）である。
ステップ２では、図１に示すように、モバイル・ノード（MN)）は、８０２．１ｘ基準に従って、現在関連するアクセスポイント（ＡＰ）にＥＡＰＯＬ−Ｓｔａｒｔ（エクステンシブル・オーゼンティケーション・プロトコル）メッセージを送信する。そのメッセージは、１つのアクセスポイント（ＡＰ）の地域から他のアクセスポイント（ＡＰ）の地域に移動する予定があり、次のアクセスポイント（ＡＰ）の事前認証を望むモバイル・ノード(MN)によって起動される。ＥＡＰＯＬ−Ｓｔａｒｔメッセージは、そら自身のアドレスと、ビーコンフレームに含まれる次のアクセスポイント（ＡＰ）のＭＡＣ（メディア・アクセス・コントロール）アドレスを宛先ＭＡＣアドレスに設定する。この実施例においては、モバイル・ノード(MN)は、実際に次のアクセスポイント（ＡＰ）（本例では、サブネットＢのアクセスポイント１（ＡＰ１））と結合する前に、次のアクセスポイント（ＡＰ）と事前認証を行うために現在のアクセスポイント（ＡＰ）（本例では、サブネットＡのアクセスポイント１（ＡＰ１））を通じてＥＡＰＯＬ−Ｓｔａｒｔメッセージを起動する。現在のアクセスポイント（ＡＰ）は、例えば、バックエンドに接続されたＬＡＮを通じて、新しいアクセスポイント（ＡＰ）にＥＡＰＯＬ−Ｓｔａｒｔフレームを転送する。
更に、ＥＡＰＯＬ−Ｓｔａｒｔメッセージのコピーは、アクセスポイント（ＡＰ）におけるＭＬＭＥ（ＭＡＣ層マネージメント・エンティティー）によるコントローリング・バッファ・ノード(CBN)にも転送される。このメッセージは、モバイル・ノード(MN)が移動性でありセッションを継続するつもりであることをコントローリング・バッファ・ノード(CBN)に通知するうえ、バッファリングサービスを開始するように、コントローリング・バッファ・ノード(CBN)に伝える。コントローリング・バッファ・ノード(CBN)は、次に、ソースＡＰ情報（本例では、サブネットＡのＡＰ１）、宛先アクセスポイント（ＡＰ）（本例では、サブネットＢのＡＰ１）、及びモバイル・ノード(MN)のアドレスをＥＡＰＯＬ−Ｓｔａｒｔメッセージから抽出し、それらをデータベースに保存し、そして、特定されたモバイル・ノード(MN)に向かうパケットをインターセプトしてメモリーに保存し始めるように（「バッファ開始」トリガーを通じて）トランジション・バッファ・ノード(TBN)に指示する。トランジション・バッファ・ノード(TBN)は、コントローリング・バッファ・ノード(CBN)からパケットをフラッシュする第２の指示を受け取るまでパケットを保存し続ける。
コントローリング・バッファ・ノード(CBN)にＥＡＰＯＬ−Ｓｔａｒｔメッセージを送信することは、認証コードのＭＡＣアドレスを見つけるためにアクセスポイント（ＡＰ）に送信される最初のメッセージであるため、セキュリティーのリスクとは解釈されるべきではない。本発明の一つの実施例によると、アクセスポイント（ＡＰ）は、モバイル・ノード(MN)の信用状を確認した後、一時的にコントローリング・バッファ・ノード(CBN)のサービスを認証する。モバイル・ノード(MN)の信用証明は、異なる質のサービスによってユーザーの要望に従って、アップグレードあるいは修正しても良い。
図１のステップ３は、サブネットＡからサブネットＢへのモバイル・ノード(MN)の動きを表示するものである。より詳細には、サブネットＡのＡＰ１からサブネットＢのＡＰ１の無線範囲のモバイル・ノード(MN)の動きである。
図１のステップ４は、上記ステップ２に詳細に説明された暗号解読の鍵を使用して、モバイル・ノード(MN)とアクセスポイント（ＡＰ）の結合が表示されている。図１の実施例において、８０２．１１ｉの暗号解読の鍵が、８０２．１１ｆ、即ちＩＡＰＰ（インター・アクセス・ポイント・プロトコル）が新しいアクセスポイント（ＡＰ）と古いアクセスポイント（ＡＰ）との間で使用されていない限り、事前認証により新しいアクセスポイント（ＡＰ）とモバイル・ノード(MN)との間でも確立される。アクセスポイントＡＰ２は、前のアクセスポイント（ＡＰ）を通じて行われた最初の認証中になされたのと同じようにモバイルステーションを認証するのに、認証サーバー即ちＡＡＡサーバーに連絡する必要がある。ＩＥＥＥ８０２．１ｘはＬＡＮ内で機能するように作られているため、ＩＥＥＥ８０２．１ｘの事前認証の適用性はイントラサブネット・ハンドオフに限定されるが、モバイルステーションが、例えば、複数のＷＬＡＮの間で移動性であるように設定されている場合、事前認証の拡張概念が適用され得る。
新しいアクセスポイント（ＡＰ）と結合した後のモバイル・ノード(MN)
モバイル・ノード(MN)が新しいアクセスポイント（ＡＰ）と結合すると、モバイル・ノード(MN)の新たな移動のバインディングの通知が（前のチャンネルを通じてパケットを送信した）前回のルーター・アクセスポイント（ＡＰ）に送信される。このモビリティ・バインディング即ち「バインディング・アップデート」は、モバイル・ノード(MN)が、ＩＥＴＦ MobileIPv6基準に定義される経路最適化に着手することを可能にする。経路最適化の主な目的は、以下の通りである。１）モバイル・ノード(MN)の前のルーターに送信されたデータグラムを新しい気付アドレス（ＣｏＡ）に転送することを可能にすること、２）新しい気付アドレス（ＣｏＡ）に転送されるあらゆるデータグラムをモバイル・ノード(MN)の古いバインディング・キャッシュ入力をもつ対応するノードから、モバイル・ノード(MN)の前のルーターにトンネルすることを可能にすること、そして３）前のルーターにリンクされたときに、モバイル・ノード(MN)によって消費されたあらゆる資源（ラジオ・チャンネル・リザベーション、バッファ・リザベーションなど）が、やがて登録期限が切れるのを待つのではなく直ちに解除されることを可能にすることである。次に、バインディング・アップデートは、すぐに前の気付アドレス（ＣｏＡ）をモバイル・ノード(MN)の新しい気付アドレス（ＣｏＡ）と関連付けて、前のセキュリティーレベルを維持しながらＩＰｖ６の認証ヘッダーを使用して認証される。
更に、バインディング・アップデートは、コントローリング・バッファ・ノード(CBN)に通信されて、コントローリング・バッファ・ノード(CBN)は、受信後、モバイル・ノード(MN)の新しい宛先アドレスを抽出し、自身のデータベースにてフラッシング・バッファ・ノード(FBN)のアドレスを見つけてフラッシング・バッファ・ノード(FBN)へパケットをフラッシュするためのトランジション・バッファ・ノード(TBN)へのリリース・バッファ・トリガーにそのアドレスを含める。モバイル・ノード(MN)の新しい宛先アドレスも、コントローリング・バッファ・ノード(CBN)のデータベースに正規にマップしてある。トランジション・バッファ・ノード(TBN)は、フラッシング・バッファ・ノード(FBN)に全てのパケットを転送することでコントローリング・バッファ・ノード(CBN)に応答する。フラッシング・バッファ・ノード(FBN)は、次に、トランジション・バッファ・ノード(TBN)が送信したパケットをカプセル解除して、パケットを新しく到着したモバイル・ノード(MN)に送信する新しいアクセスポイント（ＡＰ）に発送する。
本発明の一つの実施例によると、バインディング・アップデートは、コントローリング・バッファ・ノード(CBN)にも拡張される必要がある。それを達成する一つの方法は、利益としてより高いサービスの質（ＱｏＳ）を利用してユーザーから加入金を徴収してバッファリング・サービスを提供することである。その加入は、サービス・プロバイダーの方針に従って無料、均一料金、あるいは他の測定手段で定められる。加入サービスの一例において、加入者の信用証明は、移動中、加入者がより高いＱｏＳ（最小限あるいはパケットロスなし）を求めるということを示すようにアップグレード／修正される。そうである場合、バインディング・アップデート・パッケージは、拡張についてコントローリング・バッファ・ノード(CBN)に通知するのに使用されたリザーブのビットのどれかを使用して、わずかに修正される。また、モバイル・ノード(MN)とバッファリング・ノード(BN)が同一のＩＰサブネットにある場合、トランジション・バッファ・ノード(TBN)は、アドレス解決プロトコル（ＡＲＰ）を使用して局所的にバッファされたパケットをモバイル・ノード(MN)に送信する。
本発明は、既知のワイヤレスネットワークに優る以下の利点を提供するものである。透過性バッファリングサービス：モバイル・ノード(MN)は、サービスを求めることを必要とされないうえ、サービス条件交渉で時間とエネルギーを無駄にしない。ネットワーク上でのシグナリング負担が軽い：サービスは、サービス前のやりとりなしで設定されるため、ネットワークのシグナリング・トラフィックの量が低減される。モバイル・ノードのバッテリー寿命の延長：モバイル・ノードは、発見、請求、交渉あるいは初期計算を行わなくてもよいため、短くなるはずのモバイル・ノード(MN)のバッテリー寿命が延長される。即時のバッファリング初期化：ネットワークサービスが提供され、宣伝なしで、候補が探求され、需要が見積もられ、ネットワーク制限に対するモバイル・ノード(MN)の需要が決定され、そしてネットワークのサービスがすぐに提供される。効率的なパケットロス防止： 予測方法を使用して、バッファ・ノードのトランジット及びフラッシング・バッファ・ノードで完全なアーキテクチャーが管理され、モバイル・ノード(MN)に効率的なサービスを提供する。改良された資源とネットワークの利用：総合的なアーキテクチャーのデザインが、優れたネットワーク資源利用を提供する。バッファ・ノードは内部でお互いと通信し、ネットワークセキュリティーが改良される。
発明の幅広い範囲
本発明の実施形態が本書において説明されているが、本発明は、本書において説明される多様な好ましい実施形態に限定されるものではなく、本開示に基づいて当業者が予期すると思われる均等なエレメント、修正、削除、（例えば多様な実施形態の態様の）組み合わせ、適応及び/又は変更されたいずれかのあるいはあらゆる全ての実施形態を含むものである。請求項における限定は、請求項の用語に基づいて幅広く解釈されるものであり、非独占的に解釈されるべきであり、本明細書あるいは本出願の出願手続き中に説明された例に限定されるものではない。例えば、本開示において、「好ましい」という用語は、非独占的であり、「好ましいものではあるが、それに限定されるものではない」という意味を持つ。本開示及び本出願の手続中は、ミーンズ・プラス・ファンクションあるいはステップ・プラス・ファンクション限定は、特定の請求項限定に以下の全ての条件が揃った時にだけ適用される、ａ）「（何々）する手段」あるいは「（何々）するステップ」が明示されている、ｂ）対応する機能が明示されている、及びｃ）構造をサポートする構造、内容あるいは行動が明示されていない場合である。本開示及び本出願の手続中において、「本発明」あるいは「発明」という用語は、本開示内の１つあるいは１つ以上の態様の参考として使用される。本発明あるいは発明という用語は、臨界の特定であると不適切に解釈されるべきではなく、全ての態様あるいは実施形態に適用されるものと不適切に解釈されるべきではなく（即ち、本発明は、当然ながら多数の態様及び実施形態を持つものである）、出願あるいは請求項の範囲を限定するものだと不適切に解釈されるべきではない。本開示及び出願の手続中において、「実施形態」という用語は、態様、特徴、プロセスあるいはステップ、それらのあらゆる組み合わせ、及び/又はそれらのあらゆる部分等を説明するのに使用される。幾つかの例において、多様な実施形態は、重複する特徴を含む場合がある。本開示において、以下の省略された用語が使用されることがある。「e.g.」は「例えば」という意味である。

Claims (21)

  1. マネージド・バッファ・ノード・アーキテクチャーを備えたワイヤレス通信ネットワークであって、
    少なくとも１つのコントローリング・バッファ・ノードと、
    少なくとも１つのトランジション・バッファ・ノードと、
    総合的バッファリングサービスを提供してデータパケットのロスを防ぐ、少なくとも１つのフラッシング・バッファ・ノードと
    を備えた、ワイヤレス通信ネットワーク。
  2. 前記コントローリング・バッファ・ノードが管理的機能を実行し、前記トランジション・バッファ・ノードが移動中のデータパケットを保持し、前記フラッシング・バッファ・ノードが前記データパケットの送信を促進する、請求項１に記載のネットワーク。
  3. 前記コントローリング・バッファ・ノード、前記トランジション・バッファ・ノード、および前記フラッシング・バッファ・ノードが、ワイヤレスで互いに通信し、ネットワーク・セキュリティーを強化する、請求項１に記載のネットワーク。
  4. 更に、他のアクセスポイントと通信する能力を有する少なくとも１つのアクセスポイントを備えた、請求項１に記載のネットワーク。
  5. 前記コントローリング・バッファ・ノードが、更に、複数の機能を実行するコントローリング・オソリティーを有する、請求項１に記載のネットワーク。
  6. 前記フラッシング・バッファ・ノードが、前記トランジション・バッファ・ノードからパケットを受信すること、トンネル目的地点として機能すること、受信したパケットをカプセル解除して、当該モバイル・ノードに送信するためにそのデータパケットを前記アクセスポイント（ＡＰ）に直ちに送信すること、そして前記バッファ・ノードから前記データパケットを受信すること、を含む複数の機能を実行することができる、請求項１に記載のネットワーク。
  7. 前記コントローリング・バッファ・ノードが、前記アクセスポイントの宛先アドレスを受け取った後、リリース・バッファ・コマンドを発行する、請求項１に記載のネットワーク。
  8. 前記コントローリング・バッファ・ノード、トランジション・バッファ・ノード、およびフラッシング・バッファ・ノードが静的あるいは動的にインターネット・プロトコル・アドレスを割り当てられ、前記アドレスも非公開で前記ネットワークの外部から見えない、請求項１に記載のネットワーク。
  9. 前記ネットワークが将来の前記バッファリング資源需要を予測するのに使用する自己回帰統合移動平均モデルが、バッファリング資源需要を予測する、請求項１に記載のネットワーク。
  10. 前記ノードが、前記ネットワーク内で互いにワイヤレスで通信し合い、前記ネットワーク外のノードが当該ノードと通信することを防ぐ、請求項１に記載のネットワーク。
  11. ワイヤレス通信ネットワークであって、
    管理機能を実行するコントローリング・バッファ・ノードと、
    移動中のデータパケットを保持するトランジション・バッファ・ノードと、
    データパケットの送信を促進するフラッシング・バッファ・ノードとを備え、
    前記ネットワークは、ハンドオフ中のデータパケットロスを防止するための総合的バッファリングサービスを提供し、前記ノードが、ワイヤレスで内部的に互いに通信し合う、
    ワイヤレス通信ネットワーク。
  12. 更に、少なくとも１つのアクセスポイントを備え、該アクセスポイントは、少なくとも１つの他のアクセスポイントと通信することができる、請求項１１に記載のネットワーク。
  13. 前記コントローリング・バッファ・ノードは、コントローリング・オソリティーである、請求項１１に記載のネットワーク。
  14. 前記コントローリング・バッファ・ノードは、前記アクセスポイントの宛先アドレスを受け取った後、リリース・バッファ・コマンドを発行する、請求項１１に記載のネットワーク。
  15. 前記コントローリング・バッファ・ノード、トランジション・バッファ・ノード、及びフラッシング・バッファ・ノードが、静的あるいは動的にインターネット・プロトコル・アドレスを割り当てられ、そのアドレスも非公開でネットワークの外部には見えない、請求項１１に記載のネットワーク。
  16. 前記ネットワークが将来の前記バッファリング資源需要を予測するのに使用する自己回帰統合移動平均モデルが、バッファリング資源需要を予測する、請求項１１に記載のネットワーク。
  17. マネージド・バッファ・ノード・アーキテクチャーを備えたワイヤレス通信ネットワークを提供する方法であって、
    モバイル・ノードがアクセスポイントを発見し、前記モバイル・ノードと前記アクセスポイントとの間でデータを交換し、前記モバイル・ノードを第２アクセスポイントに近づけ、前記モバイル・ノードを第２アクセスポイントで認証を行ない、前記モバイル・ノードと前記第２アクセスポイントとの間でバインディング・アップデートを実行する。
  18. 更に、アクセスポイントが、少なくとも１つのフラッシング・バッファ・ノード、少なくとも１つのトランジット・バッファ・ノード、及び少なくとも１つのコントローリング・バッファ・ノードとデータを交換し、前記モバイル・ノードの移動をサポートする、請求項１７の方法。
  19. 更に、前記コントローリング・バッファ・ノードが開始メッセージを受信し、前記トランジット・バッファ・ノードにバッファリングの開始するように指示し、バインディング・アップデートを受信し、前記フラッシング・バッファ・ノードにデータを前記トランジット・バッファ・ノードにフラッシュするように指示する、請求項１７の方法。
  20. 更に、前記トランジット・バッファ・ノードが前記コントローリング・バッファ・ノードからトリガーを受信し、前記モバイル・ノード(MN)のためにディレクトリーを作成し、バッファ・リリース・タイムのためのタイマーをセットし、前記モバイル・ノード(MN)のためにデータをインターセプトし保持し、前記フラッシング・バッファ・ノードのアドレスを受信し、扱っているフラッシング・バッファ・ノードに前記モバイル・ノード(MN)のためにデータを転送し、前記トランジット・バッファ・ノードのメモリーを消去し、そして、前記コントローリング・バッファ・ノードに報告する、請求項１７の方法。
  21. 前記フラッシング・バッファ・ノードが、前記トランジション・バッファ・ノードからパケットを受信すること、トンネル目的地点として機能すること、受信したパケットをカプセル解除して、当該モバイル・ノードに送信するためにそのデータパケットを前記アクセスポイントに直ちに送信すること、そして前記バッファ・ノードから前記データパケットを受信すること、を含む複数の機能を実行することができる、請求項１７の方法。
JP2008535730A 2005-10-11 2006-10-11 マネージド・バッファ・ノードによるハンドオフ中のパケットロス防止 Expired - Fee Related JP4991733B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US59666005P 2005-10-11 2005-10-11
US60/596,660 2005-10-11
US11/456,807 2006-07-11
US11/456,807 US7826424B2 (en) 2005-10-11 2006-07-11 Packet loss prevention during handoff through managed buffer nodes architecture
PCT/US2006/040161 WO2007044914A2 (en) 2005-10-11 2006-10-11 Packet loss prevention during handoff through managed buffer nodes

Publications (2)

Publication Number Publication Date
JP2009515381A true JP2009515381A (ja) 2009-04-09
JP4991733B2 JP4991733B2 (ja) 2012-08-01

Family

ID=37943561

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008535730A Expired - Fee Related JP4991733B2 (ja) 2005-10-11 2006-10-11 マネージド・バッファ・ノードによるハンドオフ中のパケットロス防止

Country Status (4)

Country Link
EP (1) EP1935189B1 (ja)
JP (1) JP4991733B2 (ja)
CA (1) CA2626083C (ja)
WO (1) WO2007044914A2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20220091193A (ko) * 2020-12-23 2022-06-30 현대자동차주식회사 Vcrm 전송 데이터 최적화 방법 및 그를 위한 장치
EP4305874A1 (en) * 2021-03-10 2024-01-17 Telefonaktiebolaget LM Ericsson (publ) Data buffer based connection reconfiguration control

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002125254A (ja) * 2000-10-18 2002-04-26 Mitsubishi Electric Corp ハンドオフ方法およびエージェント装置
WO2003071749A1 (fr) * 2002-02-20 2003-08-28 Mitsubishi Denki Kabushiki Kaisha Reseau d'elements mobiles
JP2005064877A (ja) * 2003-08-12 2005-03-10 Matsushita Electric Ind Co Ltd 移動無線端末装置、エリア通知サーバ装置及び無線アクセスネットワーク切り替え方法
JP2005160053A (ja) * 2003-11-04 2005-06-16 Matsushita Electric Ind Co Ltd 移動通信方法、移動通信装置、ホームエージェント装置、アクセスルータ情報サーバ装置、および移動通信システム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6434620B1 (en) * 1998-08-27 2002-08-13 Alacritech, Inc. TCP/IP offload network interface device
US7089326B2 (en) * 1997-10-14 2006-08-08 Alacritech, Inc. Fast-path processing for receiving data on TCP connection offload devices
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US7308524B2 (en) * 2003-01-13 2007-12-11 Silicon Pipe, Inc Memory chain
US20050216770A1 (en) * 2003-01-24 2005-09-29 Mistletoe Technologies, Inc. Intrusion detection system
US6996070B2 (en) * 2003-12-05 2006-02-07 Alacritech, Inc. TCP/IP offload device with reduced sequential processing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002125254A (ja) * 2000-10-18 2002-04-26 Mitsubishi Electric Corp ハンドオフ方法およびエージェント装置
WO2003071749A1 (fr) * 2002-02-20 2003-08-28 Mitsubishi Denki Kabushiki Kaisha Reseau d'elements mobiles
JP2005064877A (ja) * 2003-08-12 2005-03-10 Matsushita Electric Ind Co Ltd 移動無線端末装置、エリア通知サーバ装置及び無線アクセスネットワーク切り替え方法
JP2005160053A (ja) * 2003-11-04 2005-06-16 Matsushita Electric Ind Co Ltd 移動通信方法、移動通信装置、ホームエージェント装置、アクセスルータ情報サーバ装置、および移動通信システム

Also Published As

Publication number Publication date
CA2626083A1 (en) 2007-04-19
WO2007044914A3 (en) 2009-05-07
JP4991733B2 (ja) 2012-08-01
WO2007044914A2 (en) 2007-04-19
EP1935189B1 (en) 2016-12-21
CA2626083C (en) 2014-11-25
EP1935189A4 (en) 2009-12-02
EP1935189A2 (en) 2008-06-25

Similar Documents

Publication Publication Date Title
JP4651713B2 (ja) インターフェースデータ経路の確立をネゴシエートするための方法およびシステム
JP4251500B2 (ja) Ｗｌａｎからセルラネットワークへのインタテクノロジ・ハンドオフを実行する方法および装置
EP2109985B1 (en) Multi-link support for network based mobility management systems
AU2005222894B2 (en) Method, apparatus and computer program product providing quality of service support in a wireless communications system
US7561692B2 (en) Method of authenticating mobile terminal
CN101212461B (zh) 异构ip网络切换时的数据传输方法及系统和核心网网关
US20070147320A1 (en) Access router selection method
US20060120171A1 (en) Seamless handoff of mobile terminal
JP5511783B2 (ja) 一時登録および拡張バインディング破棄メッセージを用いるマルチホーミング・プロトコルのサポート
JP2007536787A (ja) Ｉｐアドレス設定の遅延によるハンドオーバー実行方法
US20100062760A1 (en) Data communications
EP2028814A1 (en) Method of performing a handover and corresponding network units
US20060002345A1 (en) Handover mechanism for mobile IP
JP2006506930A5 (ja)
US20060050674A1 (en) Handoff system and method between mobile communication network and wireless LAN
US7496363B2 (en) Method of changing access point for a mobile node in a wireless access network
WO2007052720A1 (ja) 通信装置及び通信方法
US20060098651A1 (en) Method and system for managing IP address assigned to mobile station
US7826424B2 (en) Packet loss prevention during handoff through managed buffer nodes architecture
WO2004114632A1 (en) Methods and apparatuses for optimizing resource management in cdma2000 wireless ip networks
WO2007006224A1 (fr) Procédé et système destinés à réaliser la translation de l’interface r3
CN101155126A (zh) 一种实现移动性管理的系统、装置和方法
JP4991733B2 (ja) マネージド・バッファ・ノードによるハンドオフ中のパケットロス防止
JP4684331B2 (ja) 移動通信システムにおけるＱｏＳサーバ
WO2010139261A1 (zh) 一种资源控制的方法及系统

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091008

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101220

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20110803

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110809

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20111108

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20111115

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120209

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

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120507

R150 Certificate of patent or registration of utility model

Ref document number: 4991733

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150511

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees