(57)【要約】【解決手段】好ましい実施形態には、管理モードにおいて動作するモバイルまたは他の非アクセスポイントステーション（例えば８０２．１１の非アクセスポイントステーション）からの「リンクダウン」指示を判定する最適化された方法が記載される。好ましい実施形態において、この方法はアクセスポイントとの伝達性の確認についてＭＡＣ層動作を使用する。この好ましい方法は、例えば、高速な「リンクダウン」イベント指示を提供するため用いることができ、Ｌ３プロトコルが必要な動作を迅速に取れるよう支援することができる。【選択図】図１
2009533890.tif 000002
【特許請求の範囲】
【請求項１】
モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法であって、
１）前記モバイルノードに、前記アクセスポイントからのビーコンをモニタさせ、前記モバイルノードが期間内にビーコンを受信しない場合に、ビーコンが欠失であると前記モバイルノードに判定させることを含み、前記モバイルノードに認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンさせるステップと、
２）前記モバイルノードに、前記アクセスポイントからのビーコンをモニタさせ、前記モバイルノードが期間内にビーコンを受信しない場合に、ビーコンが欠失であると前記モバイルノードに判定させることを含み、前記モバイルノードに、プローブ要求を送信させ、前記アクセスポイントからのプローブ応答をアクティブにスキャンさせるステップと、
３）通常はステップ１）のパッシブスキャンを前記モバイルノードに行わせ、前記パッシブスキャンが失敗の場合、前記モバイルノードにステップ２）の前記アクティブスキャンを行なわせることをさらに含む方法。
【請求項２】
前記モバイルノードに、前記ステップ１）または前記ステップ２）に独自モディファイアのモニタリングを結合させることをさらに含む請求項１の方法。
【請求項３】
独自モディファイアの前記モニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む請求項２の方法。
【請求項４】
モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法であって、
１）前記モバイルノードに、前記アクセスポイントからのビーコンをモニタさせ、前記モバイルノードが期間内にビーコンを受信しない場合に、ビーコンが欠失であると前記モバイルノードに判定させることを含み、モバイルノードに認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンさせるステップと、
２）前記モバイルノードに、前記アクセスポイントからのビーコンをモニタさせ、前記モバイルノードが期間内にビーコンを受信しない場合に、ビーコンが欠失であると前記モバイルノードに判定させることを含み、前記モバイルノードに、プローブ要求を送信させ、前記アクセスポイントからのプローブ応答をアクティブにスキャンさせるステップと、
３）前記モバイルノードに、前記ステップ１）または前記ステップ２）に独自モディファイアのモニタリングを結合させることをさらに含む方法。
【請求項５】
独自モディファイアの前記モニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む請求項５の方法。
【請求項６】
前記モバイルノードに、パッシブおよびアクティブスキャン閾値に達する前であっても何らかのフレームがアクセスポイントから受信される場合、スキャンは成功であると判定させ、何らフレームを受信することなくパッシブおよびアクティブスキャンが失敗の場合、スキャンは失敗であると判定させることをさらに含む請求項５の方法。
【請求項７】
前記モバイルノードに、パッシブおよびアクティブスキャン閾値に達した前であってもアプリケーションデータ送信が失敗の場合、スキャンは失敗であると判定させ、パッシブおよびアクティブスキャン閾値に達した前であっても、アプリケーションデータ送信が成功の場合、スキャンは成功であると判定させることをさらに含む請求項５の方法。
【請求項８】
請求項４の方法実行するように構成されたモバイルノードであって、認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンし、プローブ要求を送信し、前記アクセスポイントからのプローブ応答をアクティブにスキャンするように構成されたモバイルノード。
【請求項９】
モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法であって、
１）モバイルノードに認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンさせるステップと、
２）前記モバイルノードに、前記ステップ１）に独自モディファイアのモニタリングを結合させるステップとを含む方法。
【請求項１０】
独自モディファイアの前記モニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む請求項９の方法。
【請求項１１】
前記モバイルノードに、閾値に達する前であっても何らかのフレームが期間内にアクセスポイントから受信される場合、パッシブスキャンは成功であると判定させ、何らフレームを受信することなく閾値に達した場合、パッシブスキャンは失敗であると判定させることをさらに含む請求項１０の方法。
【請求項１２】
前記モバイルノードに、アプリケーションデータ送信が失敗の場合にパッシブスキャンは失敗であると判定させ、ある一定の閾値に達していなくてもアプリケーションデータ送信が成功の場合、パッシブスキャンは成功であると判定させることをさらに含む請求項１０の方法。
【請求項１３】
前記モバイルノードに、アプリケーションデータ送信が失敗の場合にパッシブスキャンは失敗であると判定させ、ある一定の閾値に達していなくてもアプリケーションデータ送信が成功の場合、パッシブスキャンは成功であると判定させることをさらに含む請求項１１の方法。
【請求項１４】
請求項９の方法を実行するように構成されたモバイルノードであって、認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンし、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックをモニタリングするように構成されたモバイルノード。
【請求項１５】
モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法であって、
１）前記モバイルノードに、プローブ要求を送信させ、前記アクセスポイントからのプローブ応答をアクティブにスキャンさせるステップと、
２）前記モバイルノードに、前記ステップ１）に独自モディファイアのモニタリングを結合させるステップとを含む方法。
【請求項１６】
独自モディファイアの前記モニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む請求項１５の方法。
【請求項１７】
前記モバイルノードに、閾値に達する前であっても何らかのフレームがアクセスポイントから受信される場合、アクティブスキャンは成功であると判定させ、何らフレームを受信することなく閾値に達した場合、アクティブスキャンは失敗であると判定させることをさらに含む請求項１５の方法。
【請求項１８】
前記モバイルノードに、アプリケーションデータ送信が失敗の場合にアクティブスキャンは失敗であると判定させ、閾値に達していなくてもアプリケーションデータ送信が成功の場合、アクティブスキャンは成功であると判定させることをさらに含む請求項１５の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、とりわけ、無線通信におけるリンクダウンまたは障害を判定する方法に関し、例えば、無線アクセスポイントとの通信における、リンクダウンまたは障害を判定する方法に関する。
【背景技術】
【０００２】
ネットワークとインターネットプロトコル:
多様なコンピュータネットワークがあり、インターネットは最も有名である。インターネットは、コンピュータネットワークの世界規模のネットワークである。今日、インターネットは、何百万人ものユーザが利用可能な、公衆の自律的ネットワークである。インターネットは、TCP/IP(すなわち、伝送制御プロトコル/インターネットプロトコル)と呼ばれる1組の通信プロトコルを使って各ホストを接続する。インターネットは、インターネットバックボーンとして呼ばれる通信インフラストラクチャを有する。インターネットバックボーンへのアクセスは大部分企業および個人へのアクセスを再販するインターネットサービスプロバイダ(ISP)によって制御される。
【０００３】
IP(インターネットプロトコル)に関して、これは、ネットワーク上である装置(電話機、PDA[携帯情報端末]、コンピュータなど)から別の装置にデータを送るためのプロトコルである。今日、IPv4、IPv6などを含む様々なバージョンのIPがある。ネットワーク上の各ホスト装置は、独自の一意の識別子である少なくとも1つのIPアドレスを有する。IPはコネクションレス型プロトコルである。通信時の端点間接続は連続的ではない。ユーザがデータまたはメッセージを送信し、または受信するとき、データまたはメッセージは、パケットと呼ばれる構成要素に分割される。各パケットは、独立のデータ単位として扱われる。
【０００４】
インターネットなどのネットワークを介した各点間の伝送を標準化するために、OSI(開放型システム間相互接続)モデルが確立された。OSIモデルは、ネットワーク中の2点間の通信プロセスを7つの階層に分け、各層(レイヤ)は独自の機能セットを付加する。各装置は、送信側端点では各層を通る下方への流れがあり、受信側端点では各層を通る上方への流れがあるようにメッセージを処理する。7つの機能層を提供するプログラミングおよび／またはハードウェアは、通常、デバイスオペレーティングシステム、アプリケーションソフトウェア、TCP/IPおよび／または他のトランスポートおよびネットワークプロトコル、ならびに他のソフトウェアおよびハードウェアの組み合わせである。
【０００５】
通常、上位4層は、メッセージがユーザから、またはユーザへ渡されるときに使用され、下位3層は、メッセージが装置(IPホスト装置など)を通過するときに使用される。IPホストは、サーバ、ルータ、ワークステーションなど、IPパケットを送受信することのできるネットワーク上の任意の装置である。他の何らかのホストに向けられているメッセージは、各上位層には渡されず、この他のホストに転送される。OSIモデルの各層を以下に列記する。第7層(すなわち、アプリケーション層)は、例えば、通信相手が識別され、サービス品質が識別され、ユーザ認証およびプライバシが考慮され、データ構文に対する制約条件が識別される層である。第6層(すなわち、プレゼンテーション層)は、例えば、着信および発信データをあるプレゼンテーション形式から別の形式に変換する層である。第5層(すなわち、セッション層)は、例えば、アプリケーション間の会話、交換およびダイアログをセットアップし、調整し、終了させる層である。第4層(すなわち、トランスポート層)は、例えば、エンドツーエンド制御および誤りチェックなどを管理する層である。第3層(すなわち、ネットワーク層)は、例えば、経路指定や転送などを処理する層である。第2層(すなわち、データリンク層)は、例えば、物理レベルでの同期を提供し、ビットスタッフィングを行い、伝送プロトコルの知識および管理などを提供する層である。米国電気電子技術者協会(IEEE)では、データリンク層を、物理層との間のデータ転送を制御するMAC(媒体アクセス制御)層と、ネットワーク層とのインターフェースを取り、コマンドを解釈し、誤り回復を行うLLC(論理リンク制御)層という、2つのさらなる副層(サブレイヤ)に細分する。第1層(すなわち、物理層)は、例えば、物理レベルにおいてネットワークを介してビットストリームを伝達する層である。IEEEでは、物理層を、PLCP(物理層収束手順)副層とPMD(物理媒体依存)副層とに細分する。
【０００６】
無線ネットワーク:
無線ネットワークは、例えば、セルラおよび無線電話機、PC(パーソナルコンピュータ)、ラップトップコンピュータ、装着型コンピュータ、コードレス電話機、ポケットベル、ヘッドセット、プリンタ、PDAなど、多種多様なモバイルデバイスを組み込むことができる。例えば、モバイルデバイスは、音声および／またはデータの高速無線伝送を確保するデジタルシステムを含むことができる。典型的なモバイルデバイスは、トランシーバ（すなわち、送信機と受信機、送信機と受信機および必要に応じて他の機能が統合されたシングルチップトランシーバを含む）、アンテナ、プロセッサ、1つ以上のオーディオトランスデューサー(例えばオーディオ通信用機器に見られるようなスピーカまたはマイクロホン)、電磁気データ記憶装置(例えばデータ処理を提供する機器に見られるようなROM、RAM、デジタルデータ記憶装置など）、メモリ、フラッシュメモリ、完全チップセットまたは集積回路、インターフェース(例えばUSB、COD EC、UART、PCM)等の構成要素のいくつかまたはすべてを含んでいる。
【０００７】
モバイルユーザが無線接続を介してローカルエリアネットワーク(LAN)に接続することのできる無線LAN(WLAN)が、無線通信に用いられ得る。無線通信には、例えば、光、赤外線、電波、マイクロ波などの電磁波を介して伝搬する通信などが含まれ得る。現在、ブルートゥース(登録商標)、IEEE802.11、HomeRFなど、様々なWLAN標準が存在する。
【０００８】
一例として、ブルートゥース製品は、モバイルコンピュータ、モバイル電話機、携帯式ハンドヘルド機器、携帯情報端末(PDA)、および他のモバイルデバイスの間のリンク、ならびにインターネットへの接続を提供するのに使用できる。ブルートゥースは、モバイルデバイスが、短距離無線接続を使って、相互に、また非モバイルデバイスと、どのようにして容易に相互接続し合うことができるかを詳述するコンピュータおよび電気通信業界仕様である。ブルートゥースは、ある機器と別の機器との間でデータを同期させ、整合させ続けることを必要とする、様々なモバイルデバイスの普及から生じるエンドユーザ問題に対処して、異なるベンダからの装置を相互にシームレスに動作させるデジタル無線プロトコルを作成する。ブルートゥース機器は、共通の命名概念に従って命名できる。例えば、ブルートゥース機器は、ブルートゥース機器名(BDN)または一意のブルートゥース機器アドレス(BDA)に関連付けられた名前を持ち得る。また、ブルートゥース機器は、インターネットプロトコル(IP)ネットワークに参加することもできる。ブルートゥース機器がIPネットワーク上で機能する場合、この機器は、IPアドレスおよびIP(ネットワーク)名を備え得る。よって、IPネットワークに参加するように構成されたブルートゥース機器は、BDN、BDA、IPアドレスおよびIP名などを含むことができる。「IP名」という用語は、インターフェースのIPアドレスに対応する名前を指す。
【０００９】
IEEE標準であるIEEE802.11は、無線LANおよび機器の技術の仕様を定める。802.11を使えば、各単一基地局がいくつかの機器をサポートする無線ネットワークが実現できる。いくつかの例では、機器に無線ハードウェアが事前装備されていることもあり、ユーザが、アンテナを含み得る、カードなどの別個のハードウェアをインストールすることもできる。例えば、802.11で使用される機器は、通常、機器がアクセスポイント(AP)であるか、移動局(STA)であるか、ブリッジであるか、PCMCIAカードであるか、それとも別の機器であるか否かを問わず、注目すべき以下の3つの要素すなわちトランシーバー、アンテナ、およびネットワークの中で地点間のパケットフローを制御するMAC(媒体アクセス制御)層を含む。
【００１０】
更に、いくつかの無線ネットワークでは、複数インターフェース機器(MID)が利用できる。MIDは、ブルートゥースインターフェースと802.11インターフェースなど、2つの独立のネットワークインターフェースを含むことができ、よって、MIDが2つの別個のネットワーク上に参加すると同時に、ブルートゥース機器ともインターフェースすることが可能になる。MIDは、IPアドレス、およびIPアドレスに関連付けられた共通IP(ネットワーク)名を持つことができる。
【００１１】
無線ネットワーク機器には、それだけに限らないが、ブルートゥース機器、複数インターフェース機器(MID)、802.11機器(802.11a、802.11b、802.11g機器などを含む、IEEE802.11機器)、HomeRF(家庭内無線周波数)機器、Wi-Fi(Wireless Fidelity)機器、GPRS(汎用パケット無線システム)機器、3Gセルラ機器、2.5Gセルラ機器、GSM(移動通信用グローバルシステム)機器、EDGE(Enhanced Data for GSM Evolution)機器、TDMA型(時分割多重接続)機器、またはCDMA2000を含むCDMA型(符号分割多重接続)機器が含めることができる。各ネットワーク機器は、それだけに限らないが、IPアドレス、ブルートゥース機器アドレス、ブルートゥース共通名、ブルートゥースIPアドレス、ブルートゥースIP共通名、802.11IPアドレス、802.11IP共通名、IEEE MACアドレスを含む、様々な種類のアドレスを含むことができる。
【００１２】
また、無線ネットワークは、例えば、モバイルIP(インターネットプロトコル)システム、PCSシステム、および他のモバイルネットワークシステムにおいて見られる方法およびプロトコルも関与できる。モバイルIPでは、これに、インターネット技術標準化委員会(IETF)によって作成された標準通信プロトコルが関与する。モバイルIPでは、モバイルデバイスユーザは、これらの一旦割り当てられたIPアドレスを維持しつつ、各ネットワークにまたがって移動することができる。コメント要求(RFC)3344を参照されたい。(注:RFCはインターネット技術標準化委員会(IETF)の公式文書である。モバイルIPは、インターネットプロトコル(IP)を拡張し、モバイルデバイスのホームネットワーク外部に接続するときに、モバイルデバイスにインターネットトラフィックを転送する手段を付加する。モバイルIPは、各モバイルノードに、これのホームネットワーク上のホームアドレスと、ネットワークおよびこれのサブネット内の機器の現在位置を識別する気付アドレス(CoA)を割り当てる。機器が異なるネットワークに移動すると、機器は、新しい気付アドレスを受け取る。ホームネットワーク上のモビリティエージェントは、各ホームアドレスを、これの気付アドレスと関連付けることができる。モバイルノードは、例えば登録要求メッセージインターネット制御メッセージプロトコル(ICMP)などを使って、これの気付アドレスを変更する都度ホームエージェントにバインディング更新を送ることができる。
【００１３】
(例えば、モバイルIP外部などの)基本的なIP経路指定において、経路指定機構は、各ネットワークノードが、常に、インターネットなどへの一定の接続点を有し、かつ各ノードのIPアドレスが、これが接続されているネットワークリンクを識別するという仮定を利用する。本明細書において、「ノード」という用語は、例えば、データ伝送のための再配信点や端点などを含むことができ、他のノードへの通信を認識し、処理し、および／または転送することのできる接続点を含む。例えば、インターネットルータは、機器のネットワークを識別する例えばIPアドレスなどを調べることができる。次いで、ネットワークレベルにおいて、ルータは、特定のサブネットを識別する例えばビットセットを調べることができる。次いで、サブネットレベルにおいて、ルータは、特定の機器を識別する例えばビットセットを調べることができる。典型的なモバイルIP通信の場合、ユーザが、例えば、インターネットなどからモバイルデバイスを切断し、これを新しいサブネットで再接続しようとする場合、機器は、新しいIPアドレス、適正なネットマスクおよびデフォルトのルータを用いて再構成する必要がある。そうでなければ、経路指定プロトコルは、パケットを適正に配信することができないはずである。
【００１４】
リンク層イベント通知:
「ネットワークアタッチメント（ＤＮＡ）を検知するためのリンク層イベント通知」，ｄｒａｆｔ−ｉｅｔｆ−ｄｎａ−ｌｉｎｋ−ｉｎｆｏｒｍａｔｉｏｎ−０３．ｔｘｔ，  Ｉ．Ｅ．Ｔ．Ｆ．，  Ａ．  Ｙｅｇｉｎ，  Ｏｃｔｏｂｅｒ，  ２００５には次の通り記載されている。「ノードがネットワークへの接続点を変更することは珍しいことではない。これは、モバイル使用（例えば基地局間を移動する携帯電話）または遊動使用（例えば外回りの営業マンの場合）により起こり得る。ネットワークへの接続点を変更するノードは最終的にはそのＩＰサブネットを変更することがあり、このためＩＰアドレス、デフォルトゲートウェイ情報およびＤＮＳサーバアドレスのようなＩＰ層パラメータの再構成を必要とする。サブネット変更の検知は、通常、広告された接頭辞の変更(すなわち接頭辞の出現および消失)のようなネットワーク層指示を用いるかもしれない。しかし、一般に、これらの指示は、ノードがアタッチメントポイントを変更するときに容易に利用可能ではないことから、そのような指示を頼りにしても迅速な検出は行えない。下層にあるリンク層ステータスへの変更はリンク層イベント通知の形式でIPに対して中継することが可能である。リンク層接続の確立と切断は２つの基本的なイベント型である。ネットワークアタッチメントポイントの識別子（例えばＩＥＥＥ  ８０２．１１のＢＳＳＩＤおよびＳＳＩＤ）、または利用可能であればリンク層アタッチメントプロセスを介して得られたネットワーク層構成パラメータのように、追加情報がイベント型に加えて伝えることが可能である。サブネット間移動検出および再コンフィギュレーションプロセスを促進するために、ある状況においてそのようなイベント通知を用いることが可能であることが意図される。例えば、ノードが新しいリンク層接続を確立したことを示す通知が、可能な構成変更用のネットワークを直ちに調べることのために用いられてもよい。リンク層からのそのような通知がない状態において、ＩＰは、直ちに利用可能でない次のスケジューリングされたルータ広告の受信、デフォルトゲートウェイへの不到達性などのような指示を待たなければならない。リンク層イベント通知がサブネット変更に必ずしも変わるとは限らないことに留意されたい。ノードが１つのアタッチメントポイントとのリンク層接続を切断しており、別のものとの新しい接続を確立したとしても、それが同一のＩＰサブネットにさらに接続されてもよい。例えば、数個のＩＥＥＥ  ８０２．１１アクセスポイントが同一のＩＰサブネットに接続することが可能である。これらのアクセスポイント間で移動することはＩＰ層構成変更を正当としない。」
この論文ではさらに「サブネットの変更を検知する、向上させられた方式を可能にするために、我々は様々なアクセス技術から現実的に期待することが可能なリンク層イベント通知を定義する必要がある。」と説明されている。
【００１５】
この論文ではさらに次の通り説明されている。「それらは（例えばアクセスポイントおよびルータ上の）ネットワーク側で利用可能かもしれないが、これらのイベント通知はホストを念頭に考慮される。この情報を伝えるために、ＡＰＩまたはプロトコルに基づいた標準インターフェースがリンク層およびＩＰの間で定義されてもよい。・・・リンク層イベント通知はＤＮＡプロセスへの入力のうちの１つであると考えられる。DNAプロセスは、IP層構成が更新されなければならないかどうか判定する前に、他の入力(例えば広告された接頭辞、デフォルトゲートウェイの到達可能性の存在)をとるだろう。それらがIPに対して利用可能になる場合、DNAプロセスがリンク層通知を利用することが可能であることが期待される。リンク層通知が単独ですべての入力DNAニーズを構成するとは限らないが、詳細(すなわちプロセスに他の入力)を収集するようにDNAプロセスに促すことは、少なくとも有用である。例えば、新しいリンク層接続が確立されることを知るとすぐに、ノードはルータ懇請を送ってもよい。」
この論文ではさらに次の通り説明されている。「2つの基本的なリンク層イベントがDNAプロセス：リンクアップおよびリンクダウンに対して潜在的に有用であると考えられる。これらのイベントは両者ともに決定論的であり、イベントが正常に終わった後、それらの通知がIP層に対して提供される。これらのイベントと通知は、ノード上のネットワークインターフェースに関係している。IPモジュールはノード上のネットワークインターフェースの各1つから、同時に独立した通知を受信してもよい。「リンク」とはネットワーク・ノードが伝達することが可能な通信機能または媒体のことである。リンクはそれぞれ最低2つのエンドポイントに関係している。「アタッチメントポイント」は、アクセスポイント、基地局または有線のスイッチのように、ノードが現在接続されるリンク上のリンクエンドポイントである。「リンクアップ」はデータパケットを通信することが可能となるインターフェースに関連した状態変更を示すリンク層により提供されるイベントである。このイベントは、ノードとアタッチメントポイントの間のリンク層接続に関係している。実際のイベントは、リンク層プロトコルおよびメカニズムの実行を通じてノードのリンク層によって管理される。イベントがリンク層内で正常に終了すれば、その通知がＩＰ層に送られなければならない。通知が送達される時までに、ノードのリンク層は、ＩＰおよび物理層からＩＰパケットを受け取る準備ができていなければならない。リンクはアップだがデータ送信はネットワークにおいてブロックできることを示したいという実装の要請に適合するリンクアップ通知の非決定論的な使用法がある（ＩＥＥＥ  ８０２．３議題を参照）。リンクアップ通知は、イベントを伝えるために適切な属性（例えばＲフラグによって指示された「リスク」）と共に生成されてもよい。あるいは、リンク層実装は、リスク条件が存在するのがやむまでリンクアップ通知を遅らせることに決めてもよい。Ｒフラグセットを持ったリンクアップが生成された場合、リンク層が決定論的な通知を生成することが可能になるとすぐに別のリンクアップが対応しなければならない。リンク層が正確な条件を決定することが可能であった場合、イベント属性は、直前の通知の後に送信されたパケットが、ネットワークによってブロックされる（Ｂフラグ）と推定されたか、許可される（Ａフラグ）と推定されたかを示さなければならない。リンク層がこれらのパケットの確信についての決定をなすことが可能でない場合、追加の指示(フラグセット無し)でリンクアップを生成しなければならない。」
この論文ではさらに次の通り説明されている。「「リンクダウン」は、インターフェースがもはやデータパケットを通信することが可能でないことに関連付けられた状態変更を示すリンク層により提供されるイベントである。リンクダウンイベントはリンクが使用不可能であるとリンク層が見なし、高フレーム損失のトランジェント期間が十分でないときにのみ生成される。リンク層接続が物理的にまたは論理的に切断され、もはやデータパケットを運べない場合、これはリンクダウンイベントと見なされる。これらの２つのイベント中で、インターフェースが可能になった後起こる最初のものはリンクアップイベントでなければならない。ネットワークインターフェースは、それが可能になる間、一連のリンクアップイベントおよびリンクダウンイベントを経る。インターフェースがその接続点を変更するごとに、新しいアタッチメントポイントを持ったリンクアップイベントが、直前のアタッチメントポイントを持ったリンクダウンイベントに続かなければならない。最終的にネットワークインターフェースが無効になる場合、これはリンクダウンイベントを生成しなければならない。これらのイベントの各々が生じる順序で通知は生成されなければならない。リンク層接続が同一にとどまる場合でさえ、ノードはそのＩＰ層構成を変更しなければならないかもしれない。具体例シナリオはIPv6サブネットリナンバリング[RFC2461]である。したがって、リンクアップ通知を受信するＩＰ層が無い場合であってもＩＰ層構成を変更しなければならないかも知れないという場合がある。したがって、リンク層通知はサブネット変更の必須指示ではない。リンク層通知が、イベント（リンクアップ、リンクダウン）の型に加えてアタッチメントポイントに関する情報を任意に送達してもよい。そのような副情報は、アタッチメントポイントのアイデンティティ(例えば基地局識別子)、または付属のサブネットに組み合わせたIP層構成パラメータ(例えばサブネット接頭辞、デフォルトゲートウェイアドレスなど)を含んでいてもよい。新しいリンク層接続が確立されたことを知っているに過ぎないので、ＤＮＡプロセスに対し、ネットワークコンフィギュレーション変更を検知するための他の手がかりを直ちに見つけ出すよう促すが、副情報がさらなる手がかり（および、しばしば最終的な応えさえも）を構成してもよい。アタッチメントポイント識別子およびＩＰ層構成の間に１対１写像がある場合、前者を知ることで後者が明らかになるかもしれない。更に、リンク層接続の間に得られたＩＰ層構成パラメータは、ＤＮＡプロセスがまさに発見しようとしているもの（例えばＰＰＰリンク確立中に構成されたＩＰアドレス）かもしれない。リンクアップイベントまたはリンクダウンイベントをもたらすリンク層プロセスはリンク技術に依存する。リンク層通知はイベント型を常に指示していなければならないが、アタッチメントポイントに関する副情報および有効性はまたリンク層技術に依存する。」
参考文献
本発明は、とりわけ以下の参考文献（その全開示はここに参照導入される）に記載されたシステムおよび方法に対する様々な進歩および改良を提供する。
【００１６】
[1] "Link Layer Hints for Detecting Network Attachement," draft-yegin-dna-l2-hints-00.txt, Alper Yegin, Eric Njedjou, Siva Veerepalli, Nicolas Montavont, Thomas Noel, I.E.T.F., April 2004.
[2] "Link Triggers Assisted Optimizations for Mobile IPv4/v6 Vertical Handovers," Nicolas Montavont, Eric Njedjou, Franck Lebeugle, Thomas Noel, IEEE Computer, Society, Oct 2005.
[3] "Link Level Measurement for 802.11b Mesh Networks," Daniel Aguayo, John Bicket, Sanjit Biswas, Glenn Judd, Robert Morris, MIT Computer Science and Artificiall Intelligence Labs, June 2004.
[4] "Link Adaptation Strategy for 802.11 WLAN via Receive Signal Strength Measurement," Javier Del Prado Pavon, Sunghyun Choi, 2001.
[5] "IEEE 802.11b, Part 11 Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) specification," IEEE-SA Standard Board, 1999.
[6] "IEEE 802.11g, Part 11 Wireless LAN Media Access Control (MAC) and Physical Layer (PHY) specification," IEEE-SA Standard Board, 2003.
[7] "Techniques to recduce IEEE 802.11b MAC layer handover time," Hector Velayos, Gunnar Karlsson, KTH Royal Institute of Technology, April 2003.
[8] "An empirical analysis of 802.11b MAC layer handover process," Arunesh Mishra, Minho Shin, William Aurbaugh, University of Maryland Technical Report, 2002.
[9] "Link-layer Event Notifications for Detecting Network Attachments," draft-ietf-dna-link-information-03.txt, I.E.T.F., A. Yegin, October, 2005.
【発明の開示】
【００１７】
本発明は、上記他の背景技術および／または背景技術の問題を改良する。
【００１８】
いくつかの実施形態によれば、モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法は、１）モバイルノードに認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンさせること、および２）前記モバイルノードに、プローブ要求を送信させ、前記アクセスポイントからのプローブ応答をアクティブにスキャンさせることを含む。具体例において、前記ステップ１）は、前記モバイルノードに、前記アクセスポイントからのビーコンをモニタさせること、前記モバイルノードが期間内にビーコンを受信しない場合に、ビーコンが欠失であると前記モバイルノードに判定させることを含む。またいくつかの具体例において前記ステップ２）は、前記モバイルノードに、一定の時間間隔でプローブ要求を送信させ、前記プローブ要求に対する前記アクセスポイントからのプローブ応答をアクティブにスキャンさせることを含む。またいくつかの具体例において、前記方法は、通常はステップ１）のパッシブスキャンを前記モバイルノードに行わせること、前記パッシブスキャンが失敗の場合、前記モバイルノードにステップ２）の前記アクティブスキャンを行なわせることをさらに含む。またいくつかの具体例において、前記方法は、前記モバイルノードに、前記ステップ１）または前記ステップ２）に独自モディファイアのモニタリングを結合させることをさらに含む。さらにいくつかの具体例において、独自モディファイアのモニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む。さらに、いくつかの具体例において、前記方法は、前記モバイルノードに、パッシブおよびアクティブスキャン閾値に達する前であっても何らかのフレームがアクセスポイントから受信される場合、スキャンは成功であると判定させ、何らフレームを受信することなくパッシブおよびアクティブスキャンが失敗の場合、スキャンは失敗であると判定させることをさらに含む。さらに、いくつかの具体例において、前記方法は、前記モバイルノードに、パッシブおよびアクティブスキャン閾値に達した前であってもアプリケーションデータ送信が失敗の場合、スキャンは失敗であると判定させ、パッシブおよびアクティブスキャン閾値に達した前であっても、アプリケーションデータ送信が成功の場合、スキャンは成功であると判定させることを含む。
【００１９】
他の実施形態によれば、モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法は、１）モバイルノードに認証およびアソシエーションを行ったアクセスポイントからの送信をパッシブにスキャンさせること、および２）前記モバイルノードに、前記ステップ１）に独自モディファイアのモニタリングを結合させることを含む。いくつかの具体例において、独自モディファイアのモニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む。さらに、いくつかの具体例において、前記方法は、前記モバイルノードに、パッシブおよびアクティブスキャン閾値に達する前であっても何らかのフレームが期間内にアクセスポイントから受信される場合、パッシブスキャンは成功であると判定させ、何らフレームを受信することなく閾値に達した場合、パッシブスキャンは失敗であると判定させることをさらに含む。さらに、いくつかの具体例において前記方法は、前記モバイルノードに、アプリケーションデータ送信が失敗の場合にパッシブスキャンは失敗であると判定させ、ある一定の閾値に達していなくてもアプリケーションデータ送信が成功の場合、パッシブスキャンは成功であると判定させることをさらに含む。さらに、いくつかの具体例において前記方法は、前記モバイルノードに、アプリケーションデータ送信が失敗の場合にパッシブスキャンは失敗であると判定させ、ある一定の閾値に達していなくてもアプリケーションデータ送信が成功の場合、パッシブスキャンは成功であると判定させることをさらに含む。
【００２０】
他のいくつかの実施形態によれば、モバイルノードが迅速にリンクダウン指示を伝播するためにアクセスポイントからの突然の切断イベントを高速に判定する方法は、１）前記モバイルノードに、プローブ要求を送信させ、前記アクセスポイントからのプローブ応答をアクティブにスキャンさせること、および２）前記モバイルノードに、前記ステップ１）に独自モディファイアのモニタリングを結合させることを含む。いくつかの具体例において、独自モディファイアのモニタリングは、前記モバイルノードとアクセスポイントの間のアプリケーションデータトラヒックのモニタリングを含む。さらに、いくつかの具体例において、前記方法は、前記モバイルノードに、閾値に達する前であっても何らかのフレームがアクセスポイントから受信される場合、アクティブスキャンは成功であると判定させ、何らフレームを受信することなく閾値に達した場合、アクティブスキャンは失敗であると判定させることをさらに含む。さらに、いくつかの具体例において前記方法は、前記モバイルノードに、アプリケーションデータ送信が失敗の場合にアクティブスキャンは失敗であると判定させ、閾値に達していなくてもアプリケーションデータ送信が成功の場合、アクティブスキャンは成功であると判定させることをさらに含む。
【００２１】
様々な実施形態の上記他の態様、特徴および／または利点は、以下の説明を添付の図と併せて考察すればさらに理解されるであろう。様々な実施形態は、妥当な場合には、異なる態様、特徴および／または利点を含み、かつ/または除外することができる。加えて、様々な実施形態は、妥当な場合には、別の実施形態の1つまたは複数の態様または特徴を組み合わせることもできる。個々の実施形態の態様、特徴および／または利点の記述は、別の実施形態または特許請求の範囲を限定するものと解釈すべきではない。
【発明を実施するための最良の形態】
【００２２】
本発明の好ましい実施形態を、限定としてではなく例として、添付の図に示す。本発明は、多くの異なる形で実施できるが、本明細書では、本開示が、本発明の原理の例を提供するものとみなされるべきであり、かかる例は、本発明を、本明細書で説明し、かつ/または本明細書で図示する好ましい実施形態だけに限定するためのものではないという了解の下で、いくつかの例示的実施形態について説明する。
【００２３】
実例アーキテクチャ
図１は、クライアントデバイスが通信する無線アクセスポイントを含む、いくつかの例示で制限しない実装において使用することが可能であるいくつかの例示構成上のコンポーネントを示す。そして図１では、総称して２１に示す無線ローカルエリアネットワーク（ＷＬＡＮ）に例示のワイヤーラインネットワーク２０が接続されたことを示している。WLAN 21はアクセスポイント(AP)22、幾つかのユーザステーション23、24を含んでいる。例えば、ワイヤーラインネットワーク20はインターネットまたは企業データ処理ネットワークを含むことが可能である。例えば、アクセスポイント22は無線ルータになりえる。また、ユーザステーション23および24は、例えばポータブル・コンピューター、個人のデスクトップコンピュータ、PDA、ポータブルのボイスオーバーIP電話および／または他の機器になりえる。アクセスポイント22はワイヤーラインネットワーク21にリンクされたネットワークインターフェース25、およびユーザステーション23および24と通信する無線トランシーバを有する。例えば、無線トランシーバ２６は、ユーザステーション２３および２５との無線またはマイクロ波周波数通信用のアンテナ２７を含むことが可能である。アクセスポイント２２はまたプロセッサ２８、プログラムメモリ２９およびランダムアクセスメモリ３１を有する。ユーザステーション２３はアクセスポイントステーション２２との通信用のアンテナ３６を含む無線トランシーバ３５を有する。同様に、ユーザステーション２４は、アクセスポイント２２との通信用の無線トランシーバ３８およびアンテナ３９を有している。
【００２４】
図２は、例えば本発明のいくつかの実施形態におけるアクセスポイントおよび／またはユーザステーションのような装置によって実行される、コンピュータ化された工程ステップを実装するために用いることが可能な、例示的なコンピュータまたは制御ユニットを示す。いくつかの実施形態では、コンピュータまたは制御ユニットは、バス326上の一組の入出力(I/O)デバイス324と通信することが可能な中央処理装置(CPU)322を含んでいる。Ｉ／Ｏデバイス３２４は例えば、キーボード、モニタ、および／または他のデバイスを含むことが可能である。ＣＰＵ３２２は、バス３２６上のコンピュータ可読媒体（例えば従来の揮発性または不揮発性データ記憶装置）３２８（以下「メモリ３２８」）と通信することが可能である。ＣＰＵ３２２とＩ／Ｏデバイス３２４、バス３２６およびメモリ３２８の間のインタラクションは、当該技術分野で知られたものと同様である。メモリ３２８は、例えば、データ３３０を含むことが可能である。メモリ328はソフトウェア338を格納することが可能である。ソフトウェア３３８はプロセスステップのインプリメントのためのいくつかのモジュール３４０を含むことが可能である。従来のプログラミング技術がこれらのモジュールを実装するために用いられてもよい。メモリ328は上記データファイルおよび／または他のデータファイルを格納することが可能である。実施形態においては、ここに記述された様々な方法が、コンピュータシステムでの使用のためのコンピュータ・プログラム製品を通じて実現されてもよい。この実装は、例えば、（例えばディスケット、ＣＤ−ＲＯＭ、ＲＯＭ等）のコンピュータ可読媒体に固定され、またはモデム等のようなインタフェース装置を介してコンピュータシステムに伝達可能な一連のコンピュータ命令を含んでいてもよい。通信メディアは実質的に有形（例えば通信線）かもしれないし、および／または実質的に無形（例えばマイクロ波、光、赤外線などを用いる無線メディア）としても良い。コンピュータ命令は種々のプログラミング言語で記述することが可能であり、および／または半導体素子（例えばチップまたは回路）、磁気デバイス、光学デバイスおよび／または他のメモリ・デバイスのようなメモリ・デバイスに格納することが可能である。様々な実施形態において、適切なあらゆる通信技術を用いて伝送を行ってもよい。
【００２５】
好ましい実施形態の論究
好ましい実施形態は、管理されたモードにおいて動作している（例えば８０２．１１のモバイルノードまたは他の非アクセスポイントステーションのような）モバイルノードまたは他の非アクセスポイントステーションからの「リンクダウン」指示を判定する、最適化された方法に関する。好ましい実施形態では、該方法はアクセスポイント(AP)との伝達性確認のためのMAC層動作を用いる。この好ましい方法は例えば高速の「リンクダウン」イベント指示の提供に用いることが可能であり、３つの（Ｌ３）層プロトコルが必要なアクションを取れるように迅速に支援を行うことが可能である。
【００２６】
本出願では、以下の用語が使用される。
【００２７】
「非アクセスポイントステーション」（非ＡＰ  ＳＴＡ）は、上で示したように、（例えばモバイルノードまたはステーションのような）ステーションとして作動するがアクセスポイントとしては作動しないノードを含む。例えば、非ＡＰステーションは例えばステーションとして作動するがアクセスポイントとして作動しない８０２．１１ノード含むことが可能である。
【００２８】
「アクセスポイント（ＡＰ）」は、例えば、アクセスポイントとして作動するノードを含んでいる。例えばＡＰは、アクセスポイントとして作動する例えば８０２．１１ノードを含むことが可能である。
【００２９】
「分散協調機能（ＤＣＦ）」は、例えば８０２．１１の例えば媒体アクセス・プロトコルを含んでいる。参照導入される参考文献[5]および[6]を参照されたい。「ラウンドトリップ時間（ＲＴＴ）」は、パケットが宛先ノードに向けてソースノードから送信されたときから、宛先ノードからの送達確認がソースノードにより受信されるときまでの継続期間を含んでいる。
【００３０】
1. 序論
通常動作において、現時点であるＡＰに関係する非ＡＰ  ＳＴＡは、（ａ）ＡＰにおける装置障害、（ｂ）非ＡＰ  ＳＴＡ自体における装置障害、または（ｃ）ＡＰの範囲から外れる非ＡＰ  ＳＴＡの予期せぬ迅速な移動により、突然の切断を経験することがある。非ＡＰ  ＳＴＡは、最後に受信したフレームに基づいたリンククオリティしか記録しないことから、これらのシナリオにおいて非ＡＰ  ＳＴＡにおける「リンクダウン」イベントを直ちに決定するために信号品質を用いることはミスをリードすることかもしれない。したがって、リンククオリティはヒストリカルデータを表わすが、幾つかの予期されたビーコンフレームが受信されていなかった後にリセットされるものでしかない。他の実装は失敗した送信イベント（ＲＴＳ／ＣＴＳ）を用いて接続性を確認する（参照導入される上記参考文献［７］を参照）。しかしながら、これらの実装は、アプリケーションが実際にデータを送っているかどうかに依存しているため、信頼できない。参考までに、種々のインプレイメンタが提供しているリンク切断検出の詳細な測定方法が、本明細書に参照導入される上記参考文献［８］に示されている。
【００３１】
ここに検討されていた好ましい実施形態のうちのいくつかに従って、例えば非ＡＰ  ＳＴＡにおいて存在してもよいモバイルＩＰ（例えば、本明細書に参照導入される上記参考文献［２］を参照）のようなＬ３プロトコルに対する「リンクダウン」指示を迅速に伝播するため、突然の切断イベントの迅速な判定を可能にする方法が開示される。いくつかの好ましい実施形態において、この方法は、例えば、例えばネットワークアタッチメント（ＤＮＡ）の検知のような特殊動作を行なうためにもっぱらこれらの指標に依存するＬ３プロトコルを迅速に支援することが可能である（例えば、本明細書に参照導入される上記参考文献［１］参照）。とりわけ、迅速な指示はＬ３ハンドオフプロシジャに、より好ましいパフォーマンスを提供することが可能である。いくつかの好ましい実施形態において、この方法は（例えば８０２．１１のフレーム−例えば、本明細書に参照導入される参考文献［５］および［６］参照）のパッシブなモニタリングのみならず、一定条件でのＡＰのアクティブなプロービングを組み合わせたスキームを使用する。いくつかの好ましい実施形態において、これらのスキームを組合せて使用することが可能である。さらにいくつかの別の好ましい実施形態において、種々のシナリオに適用可能ないくつかのリンクダウン検出変形例を提供する、独自の指標のモニタリングが使用される。
【００３２】
本書において、リンクダウンイベントとは、例えば、リンクが、ＩＰトラヒックに対処できないリンク層プロトコル状態に入るか、リンク品質の一定の下落がある場合（例えばモバイルノードがアクセスポイントの範囲から外れてさまようような場合）の状況のことをいう。
【００３３】
２．  好ましいアルゴリズム
いくつかの好ましい実施形態において、高速の切断アルゴリズムは、完全なリンク損失が短期間内で生じた旨の決定的な測定を提供する。歴史上、無線ネットワーク（例えば８０２．１１のネットワーク）において非常に短い時間制約（ミリ秒オーダ）を考慮する場合、決定的な指標は例えば以下の要因で曖昧であった。
【００３４】
ｉ．  ほんの短距離（例えば数メータ）移動する場合でさえ信号強度が例えば数デシベル（デシベル）の単位で変動することがある。その変動の最低状態が、短期間におけるリンク損失の「誤りの」指示を生じさせる場合がある。
【００３５】
ｉｉ．  安定していないパケット損失レートが「誤りの」指示を生じさせる場合もある。例えば、ほとんどの８０２．１１リンクの損失率は、恐らくトラヒック要求の増加または集中により損失率の集中的な期間があることが予想されるにしても、安定している（例えば、本明細書に参照導入される上記参考文献［３］を参照）。
【００３６】
ｉｉｉ．  非ＡＰ  ＳＴＡ送信チャネル内またはそのチャネル近くの隣接ＡＰからの伝播干渉。これは、高安定レベルで直上（ｉｉ）のパケット損失率に関係する。これは例えば８０２．１１ＭＡＣのＤＣＦアルゴリズムによっていっそう悪化し（例えば、本明細書に参照導入される上記参考文献［４］）、ＡＣＫを必要とするあらゆるフレームの遅延を生じさせるかもしれない。
【００３７】
ｉｖ．  マルチパスフェージング
これは、直上（ｉｉｉ）の一因となり得るが、つい最近のディジタル信号処理（ＤＳＰ）／チップセット実装ではこの影響を補うことが可能であり、あまり生じそうにない。
【００３８】
前述および他の要因が、リンクダウンイベントの「誤りの」指示の原因となり得る。好ましい実施形態において、例えば、ＡＰを持った合理的なレベルの「伝達性」を確立し、リンク切断の判定についてこの「レベル」をベースラインとして定義するＭＡＣ層機能により、これらの影響を補うアルゴリズムが用いられる。これを、好ましい実施形態の方法は以下の仮定に基づき非常に短い時間フレーム以内で行う。
【００３９】
ｉ．  非ＡＰ  ＳＴＡは、ＡＰとのアソシエーションおよび／または認証に既に成功している。好ましい実施形態、アルゴリズムは、本明細書に参照導入される参考文献［５］および［６］に記載された「認証および接続（associated）」の状態においてのみ動作する。
【００４０】
ｉｉ．  非ＡＰ  ＳＴＡは、ネゴシエートされたトラヒック率以内で制御およびデータフレームを送信／受信可能であること。これは非ＡＰ  ＳＴＡとＡＰの間で合理的なＲＴＴ（ラウンドトリップ時間）を決定しようとする場合に重要になる。特定時点における非ＡＰ  ＳＴＡからＡＰへのＲＴＴを近似する手段として、送達確認（ＡＣＫ）を必要とする制御およびデータフレームを用いることができる。
【００４１】
ｉｉｉ．  ＡＰが既知の間隔でビーコンフレームを送っていること。認証および／またはアソシエーションフェーズ中に、非ＡＰ  ＳＴＡおよびＡＰはコンフィギュレーション変数を交換する（例えば、本明細書に参照導入される参考文献［５］および［６］を参照）。これは、例えばＡＰからのビーコンフレームの使用を含み、ＡＰからのビーコンフレーム到着時を近似するため非ＡＰ  ＳＴＡが用いることが可能なビーコンインターバル（ターゲットビーコン伝送時間（ＴＢＴＴ））を広告する。
【００４２】
ｉｖ．  リアソシエーション、ディスアソシエーションおよび／またはデオーセンティケーション処理が、リンクダウン検出アルゴリズムを無効にすること。この処理に関する指標は、正式のリアソシエーション、ディスアソシエーションおよび（または）デオーセンティケーションプロシジャに関係する非ＡＰ  ＳＴＡによって送られたか受信されたいかなるフレームをも含む。
【００４３】
これらを想定し、高速のリンクダウン検出アルゴリズムは、スキームの基本集合および１セットの独自モディファイアの組合せに基づいて形成することが可能である。種々の実施形態において、これらのスキームおよびモデファィアの種々の組合せは、システムにより何がサポートされ得るかに依存して用いられ得る種々のリンクダウン検出バリアントを形成する。以下の項では、特に、１セットの基本的なアルゴリズム、アルゴリズムパラメータ、および近似検知時刻、およびそれらの使用に関係する問題について説明する。加えて、ここに下記に続く項では、モデファィアの集合が基本的なアルゴリズムに適用される場合、使用することが可能ないくつかの組合せについて説明する。
【００４４】
ここで図４を参照すると、詳しくは下に説明するように、いくつかの好ましい実施形態において、リンクダウン判定の最適化を達成する新しい態様でパッシブスキャン機能１、アクティブスキャン機能２および／または独自モディファイア（例えばアプリケーションデータトラヒックのモニタリング）機能３を用いる高速リンクダウン検出アルゴリズムが使用される。
【００４５】
２．１．  基本的なアルゴリズム
２．１．１．  パッシブスキャン
非ＡＰ  ＳＴＡは、連続するビーコン損失の数を数える。好ましい実施形態において、最後にビーコンを受信または損失して以来、非ＡＰ  ＳＴＡが期間（Ｔ＿Ｂ）にわたりビーコンを受信しない場合、ビーコンは欠失したものと見なす。好ましくは、連続するビーコン損失の数がある閾値（Ｎ＿Ｂ）に達する場合、パッシブなスキャンは失敗であると判定する。実施形態においては、パッシブなスキャンが失敗の場合、リンクはダウンであると見なす。参考を容易にするため、図３に、例示のモバイルノードＭＮおよび例示のアクセスポイントＡＰを示し、ビーコン伝送を概略的に示す。ひいては、これら実施形態において、１）期間Ｔ＿Ｂ  （ＴＢＴＴに依存する）および２）閾値Ｎ＿Ｂというパラメータが重要である。ここで、検知時刻はＴ＿Ｂ＊Ｎ＿Ｂのように書ける。
【００４６】
これらの実施形態において、以下の問題点がある。
【００４７】
ａ．Ｔ＿ＢまたはＮ＿Ｂが大きすぎる場合に、検出速度の低下が起こる。
【００４８】
ｂ．Ｔ＿Ｂが小さすぎる場合に、余計なビーコンが生じる。
【００４９】
ｃ．Ｎ＿Ｂが小さすぎる場合に、リンクダウン検出の誤りの見込みが高くなる。
【００５０】
２．１．２．  アクティブスキャン
具体例によっては、非ＡＰ  ＳＴＡはインターバル時間（Ｔ＿Ｐ）おきにプローブ要求を送信（例えばユニキャスト）する（例えば時間間隔Ｔ＿Ｐの定期的な方式で、非ＡＰ  ＳＴＡはプローブ要求を連続的に再送する）。好ましくは、送信数が閾値数（Ｎ＿Ｐ）に達してもプローブ応答が受信されていない場合に、アクティブスキャンは失敗したものと判定される。Ｎ＿Ｐに達する前に少なくとも１つのプローブ応答が受信された場合、アクティブスキャンは成功したものと判定される。一方、アクティブスキャンが失敗する場合、リンクは、ダウンであると見なされる。参考を容易にするため、図３に、例示のモバイルノードＭＮおよび例示のアクセスポイントＡＰを示し、プローブ要求およびプローブ応答を概略的に示す。
【００５１】
ひいては、これら実施形態において、１）期間Ｔ＿Ｐ（ＲＴＴに依存する）および２）閾値Ｎ＿Ｐというパラメータが重要である。ここで、検知時刻はＴ＿Ｐ＊Ｎ＿Ｐのように書ける。
【００５２】
これらの実施形態において、以下の問題点がある。
【００５３】
ａ．Ｔ＿Ｐが小さすぎる場合、余分なプローブトラヒックがある。
【００５４】
ｂ．Ｎ＿Ｐが小さすぎる場合に、リンクダウン検出の誤りの見込みが高くなる。
【００５５】
ｃ．Ｔ＿ＰまたはＮ＿Ｐが大きすぎる場合に、検出速度の低下が起こる。
【００５６】
２．１．３．  ハイブリッドスキャン
実施形態においては、非ＡＰ  ＳＴＡは、通常、パッシブスキャンを行なう。その結果パッシブスキャンが失敗を報告する場合、非ＡＰ  ＳＴＡは、リンクがダウンであると直ちに判定せずにアクティブスキャンを開始する。好ましくは、アクティブスキャンが失敗の場合、リンクはダウンであると見なす。一方、アクティブスキャンが成功の場合、非ＡＰ  ＳＴＡは好ましくはパッシブスキャンに切り替える。
【００５７】
これらの実施形態において、次にＴ＿Ｂ、Ｎ＿Ｂ、Ｔ＿Ｐ、およびＮ＿Ｐのパラメータが重要である。ここで、Ｔ＿ＢはＴＢＴＴとは独立していてもよいことに留意されたい。
【００５８】
さらにこれらの実施形態において、検知時刻の合計は＝Ｔ＿Ｂ＊Ｎ＿Ｂ＋Ｔ＿Ｐ＊Ｎ＿Ｐとして書ける。
【００５９】
これらの実施形態において、以下の問題点がある。この組合せは、パッシブスキャンまたはアクティブスキャン単独と比較して誤りの検出の機会を減少させるものの、重度の負荷条件では、Ｎ＿ＢとＮ＿Ｐの同一組についての軽度な負荷条件よりも多く、誤り検出の機会を増加させる場合がある。
【００６０】
２．２．  独自モディファイア
実施形態においては、独自モディファイアは判定処理を強化するために使用される。いくつかの典型的な実施形態において、トラフィックフローは、それが直接アルゴリズムの基本的な集合に影響を与えるので独自モディファイアと見なす。この点で、トラフィックフローは、非ＡＰ  ＳＴＡとＡＰの間のアプリケーショントラヒック送信を含むことができる。参考までに、モバイルノード（例えば非ＡＰ  ＳＴＡ）とＡＰの間の実例となるアプリケーショントラヒック伝送を概略的に図２に示す。いくつかの好ましい実施形態において、これらのモデファィアは、送信および／または受信されたフレーム、または例えば以下で述べるような、例えばビーコンおよび／またはプローブ応答に関する置換指標としての他の送信を使用するバリアントを生成するために、例えば基本的なアルゴリズムに追加される。参考までに、フレームは、例えば、ネットワーク地点間に送信されるデータを含んでおり、典型的には、アドレスおよび必要なプロトコル制御情報を含んでいる。通常、フレームは、データを「構成(frame)する」ヘッダーおよびトレーラーを含んでいる。具体例では、いくつかの制御フレームはデータを含んでいない。
【００６１】
２．２．１．  受信フレーム
実施形態においては、何らかのフレームを受信したら、これをビーコンフレームまたはプローブ応答の受信と見なすことができる。したがって、なんらかのフレームをアクセスポイント（ＡＰ）から受信した場合、パッシブまたはアクティブなスキャンは成功であると見なせる。このことは、特に、ビーコンまたはプローブ応答が欠失し、誤りのリンクダウンイベントのきっかけとなる高負荷の状態を引き起こす。
【００６２】
２．２．２．  送信失敗
いくつかの好ましい実施形態において、データフレームの送信失敗が、リンク失敗の指示として使用されるかもしれない。例えば８０２．１１のＭＡＣの下では、非ＡＰ  ＳＴＡによって送られたデータフレームはそれぞれ、アクセスポイント（ＡＰ）からの送達確認（ＡＣＫ）を必要とする。ＡＣＫがある一定の時間内に（通常、実装で固有）受信されない場合、非ＡＰ  ＳＴＡはデータフレームを再送する。好ましくは、試みまたはリトライの数が設定閾値（実装で固有）を超過する場合、リンクはダウンと見なされる。
【００６３】
２．３．  好ましいバリアントアルゴリズム
好ましい実施形態において、独自モディファイアは、データトラヒックを生成するアプリケーションに依存するので、完全に独立した解決法として使用されない。独自モディファイアは、これを用いる好ましい実施形態において、さまざまなバリアントを１つ以上を生成するために、基本的なアルゴリズムと組み合わせられる。種々の実施形態において、これら１つまたは複数のバリアントは、プリファレンス、スケーラビリティ、および／または実装検討に基づいて、高速のリンクダウン検出の実際の解決法として用いられる。これらのバリアントの使用は、例えば進行中のトラヒック交換を利用するので、例えば高トラヒック状態によって起こったリンクダウンの誤検出を低減することに役立つ。いくつかの例示の実施形態において、これらのモデファィアは下のように示されるような、個々の基本的なアルゴリズムと組み合わせることが可能である。
【００６４】
２．３．１．  モデファィアと組み合わせたパッシブスキャン
いくつかの好ましい実施形態において、両方のモデファィアと組み合わせたパッシブスキャンは、１つ以上の以下に示すバリアントを実現することができる。
【００６５】
ａ．  受信フレーム（２．２．１）バリアント
実施形態においては、フレームがＴ＿Ｂ＊Ｎ＿Ｂ以内でアクセスポイント（ＡＰ）から受信される場合に、パッシブスキャンは成功したものと判定することができる。そうでなければ、何らフレームを受信することなくＮ＿Ｂ閾値に達する場合、パッシブなスキャンは失敗する。ここで、あらゆる受信フレームも予期されたビーコンフレームの代わりになる。
【００６６】
ｂ．  送信失敗（２．２．２）バリアント。
【００６７】
実施形態においては、Ｎ＿Ｂにまだ達していなくても、データ送信が失敗の場合、パッシブスキャンは失敗である。同様に、Ｎ＿Ｂにまだ達していなくても、データ送信が成功の場合、パッシブスキャンは成功である。非ＡＰ  ＳＴＡアプリケーションがデータを生成していない場合、パッシブスキャンはいつものように始まる（２．１．１を参照）。
【００６８】
ｃ．  受信フレーム（２．２．１）および送信失敗（２．２．２）バリアント
実施形態においては、この項において上記の（ａ）または（ｂ）が失敗の場合、パッシブスキャンは失敗である。同様に、（ａ）または（ｂ）が成功の場合、パッシブスキャンは成功である。好ましくは、失敗が最初に生じる検知時刻が判定される（すなわち、（ａ）または（ｂ））。
【００６９】
２．３．２．  モデファィアと組み合わせたアクティブスキャン
いくつかの好ましい実施形態において、両方のモデファィアと組み合わせたアクティブスキャンは、以下のバリアントの１つ以上を実現することが可能である。
【００７０】
ａ．  受信フレーム（２．２．１）バリアント
実施形態においては、Ｎ＿Ｐに達する前であっても、何らかのフレームをＡＰから受信した場合、アクティブスキャンは成功と見なされる。そうでなければ、何らフレームを受信することなくＮ＿Ｐ閾値に達する場合、アクティブスキャンはむしろ失敗である。この点で、あらゆる受信フレームもこのように、予期されたプローブ応答に対する代用になる。
【００７１】
ｂ．  送信失敗（２．２．２）バリアント
実施形態においては、アクティブスキャンはＮ＿Ｐにまだ達していなくても、データ送信が失敗する場合に失敗と見なされる。同様に、アクティブスキャンはＮ＿Ｐにまだ達していなくても、データ送信が成功の場合は成功と見なされる。むしろ非ＡＰ  ＳＴＡのアプリケーションがデータを生成していない場合、アクティブスキャンをいつものように始める（２．１．２を参照）。
【００７２】
ｃ．  受信フレーム（２．２．１）および送信失敗（２．２．２）バリアント
実施形態においては、アクティブスキャンはこの項の（ａ）または（ｂ）が失敗する場合に失敗と判定される。同様に、アクティブスキャンは（ａ）または（ｂ）が成功する場合には成功と判定される。好ましくは、失敗が最初に生じる検知時刻が判定される（例えば、（ａ）または（ｂ））。
【００７３】
２．３．３．  モデファィアと組み合わせたハイブリッドスキャン
実施形態においては、項目２．１．３に上記された検出スキームは、１つ以上の下記バリアントを生じるように前述のモデファィアと組み合わせることが可能である。
【００７４】
ａ．  受信フレーム（２．２．１）バリアント
実施形態においては、ハイブリッドスキャンは、パッシブおよびアクティブスキャン閾値に達する前であっても、フレームをＡＰから受信した場合は、成功と見なされる。ここで、何らかのフレームの受信は、むしろ予期されたビーコンまたはプローブ応答の受信を構成する。好ましくは、パッシブスキャンおよび続くアクティブスキャンが何らフレームを受信することなく失敗する場合、ハイブリッドスキャンは失敗と見なされる。
【００７５】
ｂ．  送信失敗（２．２．２）バリアント
実施形態においては、ハイブリッドスキャンは、パッシブおよびアクティブスキャン閾値に達する前であっても、データ送信が失敗の場合には失敗と判定される。同様に、ハイブリッドスキャンは、パッシブスキャンおよびアクティブスキャン閾値に達する前であっても、データ送信が成功の場合には成功と判定される。好ましくは、非ＡＰ  ＳＴＡのアプリケーションがデータを生成していない場合、ハイブリッドスキャンがいつものように始まる（２．１．３を参照）。
【００７６】
ｃ．  受信フレーム（２．２．１）および送信失敗（２．２．２）バリアント
実施形態においては、ハイブリッドスキャンはこの項の（ａ）または（ｂ）が失敗の場合に失敗と判定される。同様に、ハイブリッドスキャンは好ましくは（ａ）または（ｂ）が成功の場合に成功と判定される。ここで、失敗が最初に生じる検知時刻が判定される（例えば、（ａ）または（ｂ））。
【００７７】
本発明の概略的な範囲：
本明細書では、本発明の例示的実施形態を説明しているが、本発明は、本明細書で説明した様々な好ましい実施形態だけに限定されず、本開示に基づけば当分野の技術者によって理解されるはずの、等価の要素、改変、省略、（様々な実施形態にまたがる態様などの）組合せ、適合および／または変更を有するありとあらゆる実施形態を含むものである。特許請求の範囲における限定は、特許請求の範囲で用いられる言葉に基づいて幅広く解釈されるべきであり、本明細書において、または本出願の出願中において記述される例だけに限定されず、これらの例は、非排他的であると解釈されるべきである。例えば、本開示において、「好ましくは」という用語は、非排他的であり、「それだけに限らないが、好ましくは」を意味する。本開示において、かつ本出願の出願中において、手段プラス機能またはステッププラス機能限定は、特定のクレーム限定について、この限定において以下の条件すべてが存在する場合に限り用いられる：ａ）「〜の手段」または「〜のステップ」が明記されている、ｂ）対応する機能が明記されているc)構造、材料またはこの構造をサポートする動作が記載されていない本開示において、かつ本出願の出願中において、「本発明」または「発明」という用語は、本開示内の１つまたは複数の態様を指すものとして使用され得る。本発明または発明という言葉は、誤って重要度の識別と解釈されるべきではなく、誤ってすべての態様または実施形態にわたって適用されるものと解釈されるべきではなく（すなわち、本発明はいくつかの態様および実施形態を有すると理解されるべきであり）、また、誤って本出願または特許請求の範囲を限定するものと解釈されるべきではない。本開示において、かつ本出願の出願中において、「実施形態」という用語は、任意の態様、特徴、プロセスまたはステップ、これらの任意の組合せ、および／またはこれらの任意の部分などを記述するのに使用され得る。いくつかの例では、様々な実施形態が重なり合う特徴を含み得る。本開示では、以下の省略用語が用いられ得る。「e.g.」は「例えば」を意味する。
【図面の簡単な説明】
【００７８】
【図１】図１は、実例となるアクセスポイントおよび実例となるクライアントデバイス、または本発明のいくつかの実例となる実施形態によるユーザステーションの模範的なサブコンポーネントを示す構成上のブロック図である。
【図２】図２は、発明のいくつかの実施形態の中で例えばアクセスポイントおよび／またはユーザステーションのように機器によって実行されるためにコンピュータ化された工程ステップを実装するために用いることが可能である実例となるコンピュータまたは制御を示す構成上のブロック図である。
【図３】図３は、いくつかの実例となる実施形態による、モバイルノードおよびアクセスポイントの間のいくつかの送信交換を示す構成上のブロック図である。
【図４】図４は、いくつかの実例となる実施形態におけるプロセスの一般的な概観を示す概略図である。
【図１】
2009533890.tif 000003
【図２】
2009533890.tif 000004
【図３】
2009533890.tif 000005
【図４】
2009533890.tif 000006
【国際調査報告】
2009533890.tif 000007
2009533890.tif 000008
2009533890.tif 000009