JP2020501415A - ネットワークインフラストラクチャ監視の装置側テスト及びレポート - Google Patents

Abstract

種々の実施形態は、（患者監視装置）のようなネットワーク装置及び関連方法及び非一時的媒体に関し、以下：無線通信インタフェースと、患者の少なくとも１つの生理的パラメータを測定する患者監視ハードウェアと、プロセッサであって、前記無線通信インタフェースを介する通信を可能にするプロトコルスタックを提供し、前記プロトコルスタック及び前記無線通信インタフェースを介して前記少なくとも１つの生理的パラメータを送信し、前記プロトコルスタックから複数のＡＰに関する無線アクセスポイント（ＡＰ）情報を要求し、前記ＡＰ情報に基づき接続レポートを生成し、前記プロトコルスタック及び前記無線通信インタフェースを介してリモートサーバへ前記接続レポートを送信する、よう構成されるプロセッサと、のうちの１又は複数を含む。

Description

ここに記載される種々の実施形態は、コンピュータネットワークに関し、より詳細には、排他的ではなく、病院及び他の医療環境内のネットワークインフラストラクチャを監視することに関する。

容易且つフレキシブルな展開は、ほぼユビキタスな無線ネットワーク（特にＷｉＦｉ）をもたらした。しかしながら、有線ネットワークと比べて、無線ネットワークは、例えばチャネル干渉、低信号強度、高無線ノイズ、カバレッジギャップ、及びアクティブ接続の数に対する物理的制限の除去に起因するクライアント過負荷を含む様々な根本的原因から生じる接続上の問題の影響を受けやすい。これらの問題は、比較的頻繁に生じ得、接続が切れると送信のためのデータを失ってしまう、一時的に止まる又は不安定な接続をもたらす。これは大部分のアプリケーション（例えば、ウェブブラウジング、メッセージング、及びクライアント側バッファリングのような他の手段が利用されるときのマルチメディアストリーミング）で許容可能なソリューションであるが、他のアプリケーションは遙かに高い信頼性接続を要求する。

例えば、無線患者監視の分野では、患者の発作を検出する際の遅延が悪影響をもたらし、生死の差を意味する場合さえあるので、患者データがリアルタイムに中央装置へストリーミングされることが重要である。事業無線システムは、病院（又は接続の重要なアプリケーションの展開される他の場所）中の接続の品質を管理するツールを提供することを主張しているが、これらのシステムは、閉じられることが多く、サポートされている特定のアプリケーションにとって不完全である。例えば、このようなシステムは、非タイムクリティカルなアプリケーションに適するがリアルタイムの重要なアプリケーションに対して不利益をもたらす広範な一般的な且つ頻繁なネットワーク変更を通じて、オンサイト無線ネットワークを編成しようと試みることがある。

以上に鑑み、無線ネットワークインフラストラクチャのアプリケーション特有の監視を実行する方法及びシステムを提供することが望ましい。このようなネットワークでは、しかしながら、ネットワーク監視を実行する目的で、ネットワークハードウェア自体の機能を定め又は変更することができない場合がある。代わりに、多くのネットワークは、これらの態様においてカスタマイズされたソリューションを提供できない市販ハードウェア又はベンダからのハードウェアを利用し得る。したがって、本願明細書に記載の種々の実施形態は、ネットワークインフラストラクチャのクライアント側監視を提供し、ネットワークのアプリケーションレベルのビューを与え、アプリケーション特有要件の観点で最適な再構成を識別する。

本願明細書に記載の種々の実施形態は、患者監視装置であって、無線通信インタフェースと、患者の少なくとも１つの生理的パラメータを測定する患者監視ハードウェアと、プロセッサであって、前記無線通信インタフェースを介する通信を可能にするプロトコルスタックを提供し、前記プロトコルスタック及び前記無線通信インタフェースを介して前記少なくとも１つの生理的パラメータを送信し、前記プロトコルスタックから複数のＡＰに関する無線アクセスポイント（ＡＰ）情報を要求し、前記ＡＰ情報に基づき接続レポートを生成し、前記プロトコルスタック及び前記無線通信インタフェースを介してリモートサーバへ前記接続レポートを送信する、よう構成されるプロセッサと、を含む患者監視装置に関する。

本願明細書に記載の種々の実施形態は、無線ネットワーク接続装置のプロセッサにより実行される装置側ネットワーク監視の方法であって、前記方法は、前記無線ネットワーク接続装置の無線通信インタフェースを介する通信を可能にする前記プロセッサにより実装されるプロトコルスタックから複数の無線アクセスポイント（ＡＰ）に関するＡＰ情報を要求するステップと、前記ＡＰ情報に基づき前記複数のＡＰのうちの少なくとも１つのＡＰの現在状態に関する接続レポートを生成するステップと、前記プロトコルスタック及び前記無線通信インタフェースを介して、リモートサーバへ前記接続レポートを送信するステップと、を含む方法に関する。

本願明細書に記載の種々の実施形態は、無線ネットワーク接続装置のプロセッサにより実行される装置側ネットワーク監視のために、プロセッサにより実行される命令をエンコードされた非一時的機械可読媒体であって、前記非一時的機械可読媒体は、前記無線ネットワーク接続装置の無線通信インタフェースを介する通信を可能にする前記プロセッサにより実装されるプロトコルスタックから複数の無線アクセスポイント（ＡＰ）に関するＡＰ情報を要求し、前記ＡＰ情報に基づき前記複数のＡＰのうちの少なくとも１つのＡＰの現在状態に関する接続レポートを生成し、前記プロトコルスタック及び前記無線通信インタフェースを介して、リモートサーバへ前記接続レポートを送信する、ための命令を含む非一時的機械可読媒体に関する。

種々の実施形態が記載され、前記プロセッサは、前記複数のＡＰのうちの少なくとも１つのＡＰを重要ＡＰとして識別するよう更に構成され、前記接続レポートは前記重要ＡＰを識別する。

種々の実施形態が記載され、前記複数のＡＰのうちの前記少なくとも１つのＡＰを重要ＡＰとして識別する際に、前記プロセッサは、前記ＡＰの接続期間が接続期間閾を超えるか否かを決定し、前記プロセッサは前記の要求されたＡＰ情報に基づき前記接続期間を決定し、前記接続期間は、接続が前記プロトコルスタックと前記ＡＰとの間に確立される時間期間を示すこと、前記ＡＰのロームテーブル期間がロームテーブル期間閾を超えるか否かを決定し、前記の要求されたＡＰ情報は前記プロトコルスタックにより維持されるロームテーブルを含み、前記ロームテーブル期間は、前記ＡＰが前記プロトコルスタックにより前記ロームテーブル内に保持される時間期間を示すこと、ロームテーブル出現カウントがロームテーブル出現カウント閾を超えるか否かを決定し、前記ロームテーブル出現カウントは、前記ＡＰが前記ＡＰ情報を要求するステップの一連の実行に渡り前記ロームテーブル内で観察される回数を示すこと、のうちの少なくとも１つを実行するよう構成される。

種々の実施形態が記載され、前記プロセッサは、前記重要ＡＰのみに関して少なくとも１つのテストを実行し、前記少なくとも１つのテストからの結果を前記接続レポートに含める、よう更に構成される。

種々の実施形態が記載され、前記プロセッサは、前記複数のＡＰに関する少なくとも１つのテストを実行し、前記少なくとも１つのテストは、重要ＡＰに対して第１方法で実行され、前記少なくとも１つのテストは、重要ＡＰ以外のＡＰに対して前記第１方法と異なる第２方法で実行され、前記少なくとも１つのテストからの結果を前記接続レポートに含める、よう更に構成される。

種々の実施形態が記載され、前記プロセッサは、前記重要ＡＰのみに関して少なくとも１つのテストを実行し、前記少なくとも１つのテストからの結果を前記接続レポートに含める、よう更に構成される。

種々の実施形態が記載され、前記少なくとも１つのテストを実行する際に、前記プロセッサは、前記要求されたＡＰ情報を分析して、ネットワークインフラストラクチャに関する警告が前記リモートサーバに上げられるべきか否かを決定するよう構成される。

種々の実施形態が記載され、前記少なくとも１つのテストは、前記ＡＰの低信号対雑音比のテスト、ＡＰ間の同一チャネル干渉のテスト、ＡＰ間の隣接チャネル干渉のテスト、いかなるＡＰのネットワークカバレッジ外での経過期間のテスト、ＡＰからの低ネットワークカバレッジのテスト、ＡＰにおけるチャネル変化のテスト、ＡＰのクライアント密度のテスト、のうちの少なくとも１つを含む。

種々の実施形態が記載され、前記要求されたＡＰ情報は前記ＡＰの８０２．１１ビーコンであり、前記接続レポートは前記８０２．１１ビーコンからの情報の少なくとも一部を含む。

種々の例示的な実施形態をより良好に理解するために、添付の図面が参照される。

装置側監視及びレポートを提供するネットワーク環境の一例を示す。

患者監視装置及びインフラストラクチャ監視サーバを実装するハードウェアシステムの一例を示す。

装置側監視及びレポートを実行する方法の一例を示す。

知られているアクセスポイント（ＡＰ）リストの一例を示す。

知られているＡＰリストを更新する方法の一例を示す。

重要ＡＰを識別する方法の一例を示す。

同一チャネル及び隣接チャネル干渉をテストする方法の一例を示す。

低カバレッジをテストする方法の一例を示す。

カバレッジ外インスタンスを追跡する方法の一例を示す。

低信号対雑音比（ＳＮＲ）をテストする方法の一例を示す。

重要ＡＰの高クライアント密度をテストする方法の一例を示す。

ネットワーク管理者への提示のために接続レポートを処理する方法の一例を示す。

ここに提示される記載及び図面は種々の原理を示す。当業者は、本願明細書に明示的に記載又は示されないが、上述の原理を具現化し本開示の範囲に包含される種々のアレンジを考案できることが理解される。本願明細書で使用されるように、本願明細書で使用される用語「又は」は、特に断らない限り（例えば、「又はその他の場合（or else）」、又は「又は代替として」）、非排他的論理和（つまり、及び／又は）を表す。さらに、本願明細書に記載の種々の実施形態は、必ずしも相互に排他的ではなく、本願明細書に記載の原理を組み込む追加の実施形態を生成するために結合されて良い。

図１は、装置側監視及びレポートを提供するネットワーク環境１００の一例を示す。ネットワーク環境１００は、少なくとも部分的に、病院施設、家庭監視施設、又はネットワーク環境１００の少なくとも１つのアプリケーション（臨床／医療特性又はその他であるかに拘わらず）が高信頼無線通信からの利益を得る他の場所において、展開されて良い。例えば、ネットワーク環境１００は、無線患者監視アプリケーションの特定の実施形態を示す。したがって、環境１００は、個々の患者の生理的パラメータ（例えば、心拍、血圧、パルス酸素濃度、等）を監視し及び該情報を集約制御センタサーバ１４０に報告する１又は複数の無線患者モニタ１１０ａ、ｂ、ｃを含む。集約制御センタサーバ１４０では、医師、看護職員、又は他の職員が、各患者を監視し、必要に応じて措置を取り得る。

図示のように、無線患者モニタ１１０ａは、アンテナ１１１、ネットワークインタフェース１１２，及びプロトコルスタック１１３を含み、無線患者モニタ１１０ａが１又は複数の無線アクセスポイント１２０ａ、ｂ、ｃへ情報を無線で送信することを可能にする。ネットワークインタフェース１１２は、選択された周波数（又はその範囲）でアンテナを介してデジタル情報を送信し及び受信する種々のハードウェアを含み得る。プロトコルスタック１１３は、送信のために情報を提供すること及び受信した情報を解釈することを含む、ネットワークインタフェース１１２を制御する（プロセッサのようなハードウェア上で実行する）種々のソフトウェアを含み得る。送信されるべき何らかのこのような情報は、無線患者モニタ１１０ａの他のコンポーネント１１４−１１６から受信された「ペイロード」情報であって良いが、他のこのような情報は、ヘッダ及びフレーミングデータのような「プロトコルオーバヘッド」を含み得る。したがって、プロトコルスタック１１３は、無線媒体上で通信するための種々の標準プロトコルを実装して良い。例えば、幾つかの実施形態では、プロトコルスタック１１３は、ＩＥＥＥ８０２．１１、ＩＰ（Internet Protocol）、ＴＣＰ（Transmission Control Protocol）、及び／又はＵＤＰ（User Datagram Protocol）の１又は複数の変形を実装して良い。ＩＥＥＥ８０２．１１（又は他のプロトコル）を実装する際に、プロトコルスタック１１３は、アクセスポイント１２０ａ、ｂ、ｃ発見、認証、暗号化、チャネル選択、及びネットワークインタフェース１１２等へのその通信のような種々の機能を実行するソフトウェアを含み得る。プロトコルスタック１１３は、また、信号強度、アクセスポイント遅延、試行リトライ数、送信失敗数、動作チャネル（又は周波数）、等のような、（例えばネットワークインタフェース１１２を制御することにより）ネットワーク統計情報を追跡する種々のソフトウェアツールを含み得る。（例えば、発見したＡＰ及びその統計情報を追跡し続けることにより）これらの機能をサポートするために、プロトコルスタック１１３は、この情報を格納し又は編成するロームテーブルを維持して良い。用語「ロームテーブル」が本願明細書で使用されるが、ロームテーブルは、実施祭にはテーブルとして編成されなくて良く、１又は複数の他のデータ構造の形式を取って良い。したがって、本願明細書で使用されるように、用語「ロームテーブル」は、無線アクセスポイントに関するプロトコルスタックにより保持されるいかなるデータセットを表すことが理解される。

図示のように、無線患者モニタ１１０ａは、患者に関する種々の情報を監視し及び集約制御センタサーバ１４０のような別の装置にレポートする、患者監視ソフトウェア１１４及び患者監視ハードウェア１１５も含む。例えば、無線患者モニタが患者の心拍をレポートするよう適応される場合、患者監視ハードウェア１１５は、患者の皮膚に光を当てるＬＥＤ、及びＬＥＤからの反射光に基づき信号を生成するフォトダイオードを含み得る。この信号は、次に、パルスが抽出され得る光電脈波（photoplethysmogram：ＰＰＧ）信号を導出するために患者監視ハードウェア１１５により（例えば、１又は複数の特定用途向け集積回路により）又は患者監視ソフトウェア１１４により更に処理されて良い。患者監視ソフトウェア１１４は、次に、連続的、周期的、オンデマンドで、パルスが閾を横切ることに応答して、又は他のときに、情報を宛先装置の識別情報と共にプロトコルスタック１１３へ渡すことにより、パルス値を集約制御センタサーバ１４０へ送信して良い。これは、パルスをどのように取得するかの単なる一例であり、パルスはネットワーク環境で通信され得る患者パラメータの単なる一例であることが理解される。種々の追加又は代替の患者監視ハードウェア１１５又は患者監視ソフトウェアが明らかである。幾つかの実施形態では、収集され又は通信されるべき情報は、実際は臨床的／医療的なものでなくて良い。患者監視コンポーネント１１４、１１５は、ネットワークインタフェース１１２を介して提供される無線接続に依存する別のアプリケーションを提供する又はその中で動作する幾つかの実施形態では他のコンポーネントで置き換えられて良い。

無線患者モニタ１１０ａは、無線患者モニタ１１０ａに利用可能な無線接続を監視する上位レイヤ（例えばアプリケーションレイヤ）を実行するよう適応されたソフトウェア又はハードウェアを含み得るネットワークモニタ１１６を含む。例えば、幾つかの実施形態では、プロトコルスタック１１３は、適切な接続を選択するために接続の何からの管理を実行して良い。このようなアプローチは、幾つかのアプリケーション（例えば、高ネットワーク利用可能性を要求するアプリケーション）にとっては完全に適するものではないことがある。したがって、ネットワークモニタ１１６は、プロトコルスタック１１３と通信して、発見されたアクセスポイント二関する情報を収集し、追加ネットワーク統計情報を収集するため又はネットワークの適合性に関する結論を引き出すために１又は複数のテストを実行し、このような発見を「接続レポート」としてプロトコルスタック１１３を介してインフラストラクチャモニタ１５０へ送信して良い。このようなテスト及び結論の種々の例は、以下に詳述される。明らかなように、１つの無線患者モニタ１１０ａは環境１００全体に関する限られた情報（例えば、モニタ１１０ａの範囲内にあるアクセスポイント１２０ａ、ｂ、ｃに関する情報）しか収集できなくて良いが、環境１００全体に渡り同じ又は同様のクライアント側監視を実行する複数の無線患者モニタ１１０ｂは、分散型方法でネットワークのより完全なピクチャを収集できて良い。

アクセスポイント１２０ａ、ｂ、ｃは、プロトコルスタック１１３により実装される無線プロトコルに従い通信し、それにより更に広域なネットワーク１３０への無線アクセスを提供する、１又は複数のアクセスポイントであって良い。ネットワーク１３０は、（例えば、クラウドコンピューティング環境又は病院の）ローカルエリアネットワーク、キャリアネットワーク、又はインターネットのような、データを通信するいかなるネットワーク（又はその部分）を含み得る。集約制御センタサーバ１４０及びインフラストラクチャモニタ１５０は、したがって、それぞれ、患者も似た１１０ａ、ｂ、ｃを備えるサイトに（例えば、看護ステーションに又は病院のＩＴオフィスに）、又はそれらから離れた、別個のサービス位置、ホーム監視制御センタ、又はクラウドコンピューティングデータセンタのようなサイトに置かれて良い。集約制御センタサーバ１４０及びインフラストラクチャモニタ１５０は、したがって、サーバ、ブレード、又はクラウドコンピューティングアーキテクチャ内のハードウェアで動作する仮想機械のような種々の方法で実装されて良い。

インフラストラクチャモニタ１５０は、１又は複数の無線患者モニタ１１０ａから接続レポートを収集し、それらに基づき種々のネットワーク監視機能を実行して良い。例えば、幾つかの実施形態では、インフラストラクチャモニタは、過負荷アクセスポイント１２０ａ、ｂ、ｃ、又は低又は非接続に苦しむ病院又は他の場所のエリアを識別して良い。幾つかの実施形態では、インフラストラクチャモニタ１５０は、モニタ１１０ａ、ｂ、ｃによりレポートされた干渉を解決するために、１又は複数のアクセスポイント１２０ａ、ｂ、ｃの動作チャネルを変更するような、ネットワークへの変更を実施し又は（例えばネットワーク管理者に）推奨して良い。したがって、種々の実施形態では、アクセスポイント１２０ａ、ｂ、ｃは、例えばソフトウェア定義ネットワーキング（software−defined networking：ＳＤＮ）制御部により遠隔で構成可能であって良い。幾つかの実施形態では、インフラストラクチャモニタ１５０は、このような変更を実施するために、ＳＤＮ制御部を実装し又は通信して良い。幾つかの実施形態では、アクセスポイント１２０ａ、ｂ、ｃ及びインフラストラクチャモニタ１５０は、閉じられた又は独自仕様システムに属して良い。ここで、独自仕様プロトコルが、インフラストラクチャモニタ１５０のために、ＡＰ１２０ａ、ｂ、ｃの種々の特徴を構成するために使用される。幾つかの実施形態では、インフラストラクチャモニタ１５０は、人間のネットワーク管理者への報告インタフェースを提供し、インフラストラクチャモニタ１５０は、いかなる警告が管理者に上げられるべきか否かを決定するために、接続レポートを分析して良い。

図２は、患者モニタ装置（例えば、要素２６１〜２７０のうちの１又は複数を含む、図１の患者監視装置１１０ａ、ｂ、ｃ）又はインフラストラクチャモニタサーバ（例えば、要素２７１〜２７８のうちの１又は複数を含む、図１のインフラストラクチャ監視サーバ１５０）を実装するハードウェアシステム２００の一例を示す。図示のように、装置２００は、１又は複数のシステムバス２１０を介して相互接続された、プロセッサ２２０、メモリ２３０、ユーザインタフェース２４０、ネットワークインタフェース２５０、及び記憶装置２６０を含む。図２は、幾つかの点で抽象化を構成すること、及び実際の装置２００のコンポーネントの編成は図示のものより複雑であり得ることが理解される。さらに、本例は種々の特徴をスマート装置により及び他のものをサーバにより実装されるとして記載するが、これは単なる例示的な実施形態であることが理解される。上述のように、種々の機能は１又は複数の装置の間で多くの異なる構成で分散されて良く、ソフトウェア及び記憶装置２６０のコンテンツに対する変更がこのような代替の構成を可能にすることが理解される。

プロセッサ２２０は、メモリ２３０又は記憶装置２６０に格納された命令又は他の場合に処理データを実行可能ないかなるハードウェア装置であって良い。＋したがって、プロセッサは、マイクロプロセッサ、ＦＰＧＡ（field programmable gate array）、ＡＳＩＣ（application−specific integrated circuit）、又は他の同様の装置を含んで良い。プロセッサが、本願明細書に記載の機能のうちの１又は複数をハードウェアで実施する１又は複数のＡＳＩＣ（又は他の処理装置）を含む場合、他の実施形態ではこのような機能に対応するとして記載されるソフトウェアは省略され得ることが理解される。

メモリ２３０は、例えばＬ１、Ｌ２、又はＬ３キャッシュ又はシステムメモリのような種々のメモリを含み得る。したがって、メモリ２３０は、ＳＲＡＭ（static random access memory）、ＤＲＡＭ（dynamic RAM）、フラッシュメモリ、ＲＯＭ（read only memory）、又は他の同様のメモリ装置を含み得る。

ユーザインタフェース２４０は、管理者のようなユーザとの通信を可能にする１又は複数の装置を含み得る。例えば、ユーザインタフェース２４０は、ディスプレイ、マウス、タッチスクリーン、又はユーザコマンドを受信するキーボードを含み得る。幾つかの実施形態では、ユーザインタフェース２４０は、通信インタフェース２５０を介してリモート端末に提示され得るコマンドラインインタフェース又はグラフィカルユーザインタフェースを含み得る。ハードウェア２００が無線患者モニタを実装するような幾つかの実施形態では、ユーザインタフェース２４０は、１又は複数のセンサ、又は患者の１又は複数の生理的パラメータを監視する他のハードウェアを含む。例えば、ユーザインタフェースは、加速度計、ＬＥＤ、フォトダイオード、温度センサ、又は患者生理的パラメータを監視するために有用な他のハードウェアを含み得る。

通信インタフェース２５０は、他のハードウェア装置との通信を可能にする１又は複数の装置を含み得る。例えば、通信インタフェース２５０は、他の装置と通信するよう構成される有線又は無線ネットワークインタフェースカード（ＮＩＣ）を含み得る。追加又は代替として、通信インタフェース２５０は、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ−Ｆｉ又は他のローカル無線若しくは有線プロトコルに従う通信のためのハードウェアのような近傍装置との通信のためのハードウェアを含み得る。通信インタフェース２５０のための種々の代替又は追加ハードウェア又は構成は明らかである。

記憶装置２６０は、ＲＯＭ（read−only memory）、ＲＡＭ（random−access memory）、磁気ディスク記憶媒体、光記憶媒体、フラッシュメモリ素子、又は同様の記憶媒体のような、１又は複数の機械可読記憶媒体を含み得る。種々の実施形態では、記憶装置２６０は、プロセッサ２２０による実行のための命令、又はプロセッサ２２０がデータに基づき動作し得る該データを格納して良い。

例えば、ハードウェア２００が患者監視装置を実装する場合、記憶装置は、装置２００の基本機能を調整するオペレーティングシステム２６１、及び１又は複数のプロトコルに従い通信インタフェース２５０を介して通信を可能にするプロトコルスタック２６２を含み得る。例えば、スタック２６２は、通信のためにＴＣＰ／ＷｉＦｉスタックを実装して良い。幾つかの実施形態では、スタック２６２は、オペレーティングシステム２６１の部分として実施されて良い。幾つかの実施形態では、スタック２６２は、発見されたアクセスポイントに関する情報を収集するロームテーブル２６３、及びアクセスポイント又は他のネットワークハードウェアの状態をテストする１又は複数のネットワーク統計情報ツールを含む。記憶装置１６０は、ユーザインタフェース２４０内のセンサにより提供された情報を解釈し及びプロトコルスタック２６２を介して集約制御センタにレポートする患者監視ソフトウェア２６５も含み得る。

記憶装置２６０は、クライアント側監視を実行し及びインフラストラクチャモニタによる使用のための接続レポートを送信するために、プロトコルスタック２６２と別個のネットワーク監視ソフトウェア２６６も含む。したがって、ネットワーク監視ソフトウェアは、装置の動作に対して（例えば、患者監視ソフトウェア２６５の動作に対して）どの知られているＡＰが重要（critical）と考えられるかを識別する重要ＡＰ識別命令２６７、装置２００の観点からネットワークの種々のテストを実行する１又は複数の装置側テスト命令セット、及びインフラストラクチャモニタにプロトコルスタック２６２を介して接続レポートを送信するレポート命令２６９を含み得る。これらの命令を実現するために、ネットワーク監視ソフトウェア２６６は、知られているＡＰに関連する情報を追跡するための、知られているＡＰリスト２７０を含み得る。このような知られているＡＰリスト内の情報は、ロームテーブル２６３内のものを含み得るが、重要ＡＰ識別命令２６７又は装置側テスト命令２６８により認識される情報のような追加情報を含んで良い。

ハードウェア２００がインフラストラクチャモニタを実装する場合、記憶装置２６０は、装置２００の基本機能を調整するオペレーティングシステム２７１を含み得る。さらに、患者監視リスト２７２は、例えばＰＵＳＨ又はＰＵＬＬ方法で接続レポート２７４がレポート収集命令２７３を介して受信され得る患者モニタの指示を格納して良い。レポート分析命令２７５は、追加統計情報を引き出し及びネットワーク管理者のために視覚化を生成することにより、受信したレポート２７４を分析して良い。いかなる警告閾２７７が横切られた場合（例えば、いかなる単独装置の通信リンクの最小許容停止時間、単独ＡＰに接続される装置の最大数、重要ＡＰの信号強度が、最小閾より下に降下する、等）、警告命令２７６に従い１又は複数の警告先２７８（例えば、ネットワーク管理者）への警告を（例えば、テキスト、電子メール、又は連絡先によるウェブポータルへの次のアクセス）プッシュする。

記憶装置２６０に格納されるとして記載された種々の情報は追加又は代替としてメモリ２３０に格納されて良い。これに関して、メモリ２３０は、「記憶装置」を構成するとしても考えられ、記憶装置２６０は「メモリ」と考えられて良い。種々の他の構成が明らかである。さらに、メモリ２３０及び記憶装置２６０は、両方とも、「非一時的機械可読媒体」と考えられて良い。本願明細書で使用されるように、用語「非一時的」は、一時的信号を排除せず、揮発性及び不揮発性メモリの両者を含む全ての記憶形態を含むと理解される。

ホスト装置２００は、各記載されたコンポーネントのうちの１つを含むとして示されるが、種々のコンポーネントが種々の実施形態において複製されて良い。例えば、プロセッサ２２０は、本願明細書に記載の方法を独立して実行するよう構成される又は本願明細書に記載の方法のステップ又はサブルーチンを独立して実行するよう構成される複数のプロセッサを含み得、複数のプロセッサが本願明細書に記載の機能を達成するために協働するようにする。更に、装置２００がクラウドコンピューティングシステムで実装される場合、種々のハードウェアコンポーネントは別個の物理システムに属して良い。例えば、プロセッサ２２０は、第１サーバ内に第１プロセッサを、及び第２サーバ内に第２プロセッサを含んで良い。

図３は、装置側監視及びレポートを実行する方法３００の一例を示す。方法は、図１の無線患者モニタ１１０ａ、ｂ、ｃのうちの１又は複数のようなネットワーク環境内に展開される装置により実行されて良い。方法は、図２のネットワーク監視ソフトウェア２６６に対応して良い。方法は本願明細書に開示された原理に従い監視及び報告を実行する方法の一例であること、及び代替方法が使用され得ることが理解される。例えば、幾つかのステップは、示されたものと異なる順序で、互いに並列に、別個の方法の部分として実行されて良い（例えば、ステップ３１５〜３３０を含むテストのための第１方法が周期的に実行されて良く、一方でステップ３１０及び３５５を含む報告のための第２方法がインフラストラクチャモニタによる要求により実行されて良い）。さらに、他の実施形態では、代替又は追加ステップが含まれて良い。

図示の例では、方法３００は、周期的に実行し、したがって方法３００はステップ３０５で周期的タイマの終了により開始する。方法３００を開始する他のトリガ（例えば、別の装置から要求を受信する、又はプロトコルスタックから新情報を受信する）が明らかである。方法は、ステップ３１０に進み、装置は接続レポートを初期化する。例えば、幾つかの実施形態では、方法は、新しいデータ構造を生成し、又はその他の場合、インフラストラクチャモニタに報告されるべきアクセスポイントに関する一群の情報を格納するメモリを割り当てて良い。次に、ステップ３１５で、装置は、自身のプロトコルスタックに、自身の収集した情報をクエリする。例えば、種々の実施形態では、プロトコルスタック（又はその個々のレイヤ）は、（接続又はリンク統計情報を含む）ロームテーブルの内容のような種々の情報を要求し及び受信するＡＰＩ（application programmer interface）を実装して良い。幾つかの実施形態では、ステップ３１５は、（例えば、ＡＰＩを介して）プロトコルスタックに、それに実装されたツール（例えば、ネットワーク統計情報ツール２６４）を使用して１又は複数のテストを実行するよう、及び更なる分析のために結果を返すよう、指示するステップを含んで良い。幾つかの実施形態では、１又は複数の所望の情報片は、プロトコルスタックのＡＰＩを介してアクセス可能でなくて良く、ステップ３１５は、ロームテーブルデータを取得するための他の方法を利用して良い。例えば、幾つかの実施形態では、ステップ３１５は、プロトコルスタックに割り当てられたメモリの一部に直接アクセスし、情報をプロトコルスタックの構成の所定構成指示に基づき又は該情報の位置を識別するために分析を実行することにより（例えば、ロームテーブルの開始及び終了の知られているマーカについてスキャンする、テーブルの通常領域を特定するために知られているＡＰ名を検索する、又はメモリを分析しネットワーク統計情報を指摘するために訓練されたモデル（例えば、分類器又は他の機械学習技術）を適用する）読み出して良い。幾つかの実施形態では、ステップ３１５は、さらに、新しい情報に基づき知られているＡＰリストを更新するステップを含んで良い。知られているＡＰリストの一例は、図４に関して更に後述される。知られているＡＰリストを更新する方法の一例は、図５に関して更に後述される。

ロームテーブルが取得されると、方法は、ステップ３２０に進み、装置は、ロームテーブル内のＡＰに対して通常インフラストラクチャテストを実行する。このようなテストは、ロームテーブル内で未だ利用可能でない追加情報を取得するために、他のコンポーネント（例えば、ＡＰ、無線患者モニタのような他の装置、又はプロトコルスタック）と通信するために追加ツールを利用して、ロームテーブル内のＡＰに関する既に利用可能な情報を分析するステップを含み得る。通常インフラストラクチャテストの種々の例は、図７〜１０に関して更に後述する。

ステップ３２５で、装置は、装置によりサポートされるアプリケーションの動作に対して、どの知られているＡＰが「重要」と考えられるかを識別して良い。例えば、重要ＡＰは、装置が、接続された多くの時間を費やすＡＰ、又はそのＡＰ無しでは装置が少なくとも１つの訪問領域で代替アクセスポイントを有しないＡＰであって良い。重要ＡＰを識別する方法の一例は、図６に関して更に詳述される。どのＡＰがクライアント装置により重要と考えられるかの情報は、インフラストラクチャモニタが、状態及びネットワークに対する可能な変化を考慮するときを考慮するのに有用であり得る。ステップ３３０で、より徹底的な又は他の追加テストが、接続レポートへの追加情報の包含のために、（全ての知られているＡＰではなく）このような重要ＡＰに関して実行されて良い。このような重要なインフラストラクチャテストの一例は、図１１に関して記載される。

重要ＡＰのみに適用すべき図７〜１０の例示的な通常インフラストラクチャテストに対する種々の変更、及び全ての知られているＡＰに適用すべき図１１の例示的な重要インフラストラクチャテストに対する変更は、明らかである。さらに、幾つかの実施形態では、単一の方法が、通常及び重要インフラストラクチャテストの両方を定めて良い（例えば、方法は、他のＡＰと比べて重要ＡＰに異なる警告又は他の閾を提供して良い）。このような実施形態では、ステップ３２０、３３０は、実際には、ステップ３２５で重要ＡＰが識別された後に生じ得る同じステップであって良い。

幾つかの実施形態では、１又は複数のインフラストラクチャテストは、方法３００内で実行されなくて良く、代わりに、別個の方法の部分として実行されて良い（例えば、方法は、異なる周期で又は接続断のようなイベントが生じるときの接続断のようなイベントに応答して実行される）。幾つかの実施形態では、このような他の方法は、データを直接現在オープンな接続レポートに書き込んで良く、又はテストから生じたデータを、それが取得され及びステップ３２０又は３３０が実行されると接続レポートに入力され得る場所に格納して良い。

ステップ３３５で、装置は、接続レポートを１又は複数のインフラストラクチャモニタへ送信する。幾つかの実施形態では、装置は、各々の接続レポートを、それが形成されたとき送信しなくて良く、代わりに、本願明細書に記載の方法に従い生成された複数のレポートを集約し、それらを例えばインフラストラクチャ監視装置による要求により又はより低速な周期に基づき（例えば、毎時間又は毎日）送信して良い。幾つかの実施形態では、装置が低又は非接続であるとき接続レポートが生成された場合、ステップ３３５は、接続レポートを送信するために接続が回復するまで待機して良い。次に、方法３００はステップ３４０で終了して良い。

情報を接続レポートに含める種々の方法が後述されるが、種々の追加又は代替方法又は情報が接続レポートを構成するために使用され得ることが理解される。例えば、幾つかの実施形態では、ネットワークモニタは、１又は複数の８０２．１１ビーコンからのデータを接続レポートに含めて良い。例えば、各可視ビーコン、重要であると指定されたＡＰのビーコン、新たに接続されたＡＰのビーコン、装置がローミングしているＡＰのビーコン、装置が再接続しているビーコン、等が、（例えばプロトコルスタックから）収集されレポートに挿入されて良い。このような情報は、サポートされる変調方式、サポートされるデータレート、アクティブな調節領域、チャネル利用率のようなＡＰ負荷情報、８０２．１ｎ／ａｃ／等の能力（例えば、サポートされるチャネル幅、未開発モード状態、短保護間隔サポート、Block−ACK機能、トランジットビームフォーミング機能サポート、等）、又は他のベンダ固有機能を含み得る。更なる例として、接続レポートは、装置状態及び統計情報、複数のＡＰに関する情報、及びアプリケーション接続状態のような情報を含み得る。

図４は、知られているアクセスポイント（ＡＰ）リスト４００の一例を示す。種々の実施形態において、クライアント装置のネットワークモニタコンポーネントが構築され、ネットワークの装置ビューの分析及び接続レポートの生成をサポートするために、知られているＡＰリスト４００を維持して良い。幾つかの実施形態では、知られているＡＰリスト４００は、図２の知られているＡＰリスト２７０に対応して良い。知られているＡＰリスト４００は、事実上、データベース、テーブル、アレイ、リンク付きリスト、等のようないかなるデータ構造であって良い。図示のように、知られているＡＰリスト４０５−４４０は複数のフィールドを含み、幾つかの実施形態は、アクセスポイントに関する情報を収集するための追加又は代替フィールドを使用し得ることが明らかである。

アクセスポイント名フィールド４０５は、各知られているＡＰの識別子を格納する。例えば、フィールド４０５は、ロームテーブル内で見付かった各ＡＰのＢＳＳＩＤ又はＭＡＣアドレスを格納して良い。重要フィールド４１０は、ＡＰが、（例えば、図５を参照して後述する例のような方法の動作により）知られているＡＰリスト４００の属する装置にとって重要ＡＰとして識別されたか否かを示す指示（例えば、ブール値）を格納して良い。接続期間フィールド４１５は、装置がアクセスポイントに接続されて費やした期間を格納して良い。ロームテーブルフィールド内期間４２０は、ＡＰがプロトコルスタックのロームテーブル内に存在した期間を格納して良い。インスタンスフィールド４２５は、後のクエリによりＡＰがプロトコルスタックのロームテーブル内に現れた回数を追跡して良い。期間及びインスタンスは、装置の寿命の間（つまりリセットされない）、装置起動から、患者への装置割り当てから、時間期間の間（例えば、時間毎、日にち毎、等にリセットされる）、定期的に（例えば、１時間又は日より前の期間の部分が値から差し引かれて良い）追跡されて良い。ＳＮＲフィールド４３０は、ＡＰに関連する１又は複数の信号対雑音比値を格納して良い。例えば、このような値は、現在又は最近のＳＮＲ、又は観察されたＳＮＲの平均、中間、モード最小値、又は最大値、を含み得る。ここでも、このようなＳＮＲ値は、装置の寿命に又は期間値に関して上述したような他の期間に適用されて良い。チャネルフィールド４３５は、ＡＰの動作する（又は前に動作した）チャネルの指示を格納して良い。上述のように、ＡＰリスト４００は、多数の追加フィールド４４０を含み得る。

幾つかの代替の実施形態では、ＡＰリスト４００は、観察された全てのＡＰを含まなくて良く、代わりに、観察されたＡＰの部分集合のみがリストされ追跡されて良い。例えば、幾つかの実施形態では、ＡＰリスト４００は、所定数のエントリを含み、プロトコルスタックのロームテーブル内で新しいＡＰが発見されたときはいつでも、最も古いＡＰ、最も短い接続期間のＡＰ、ランダムな非重要ＡＰ、又は他のＡＰのレコードがＡＰリスト４００からの削除のために識別されて良い。

一例として、第１レコード４５０は、装置が現在接続されていない重要アクセスポイント「ＡＰ」を記述する。ＡＰ Ａは、ロームテーブル内で４３２回現れ、合計２時間２１分の間、ロームテーブル内で連続して見られる。ＡＰ Ａは、比較的強力な信号を示す６０のＳＮＲを有する。ＡＰ Ａは、現在、チャネル１で動作している。

別の例として、第２レコード４５５は、装置が合計１時間１４分接続されている別の重要ＡＰ「Ｂ」を記述する。ＡＰ Ｂは、ロームテーブル内で２３８０回現れ、合計１時間１９分の間、ロームテーブル内で連続して見られる。ＡＰ Ｂは、３２のＳＮＲを有し、現在、チャネル７で動作しているが、過去にはチャネル１及び６でも観察されている。

第３レコード４６０は、現在の装置に対して重要と考えられないＡＰ「Ｃ」を記述する。環境内に複数の同様の装置を含む配置では、別の装置（例えば、別の患者モニタ装置）が、例えばそのような装置によるＡＰ Ｃの頻繁な使用により、ＡＰ Ｃをそれ自身の動作に対して重要であると見なし得ることが明らかである。しかしながら、ＡＰリスト４００の属する装置では、装置は現在ＡＰ Ｃに接続されていない。ＡＰ Ｃは、ロームテーブル内で５０回しか現れず、現在ロームテーブル内に存在しない。ＳＮＲは、ＡＰ Ｃについて、０である（ＡＰ Ｃが現在範囲外である可能性が高いことを示す）。ＡＰ Ｃは、また、チャネル７で動作することが示される。前述の説明によれば、残りの例示的なレコード４６５、４７０、４７５の意味は明らかである。

図５は、図２の知られているＡＰリスト２７０又は図４の知られているＡＰリスト４００のような、知られているＡＰリストを更新する方法５００の一例を示す。方法５００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２のネットワークモニタソフトウェア２６６に対応して良い。方法５００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（図３のステップ３１５と独立して又はその部分として）実行されて良い。

方法５００は、ステップ５０５で開始し、ステップ５１５に進み、ネットワークモニタは、先ずプロトコルスタックのロームテーブルからロームテーブルエントリを読み出すことにより知られているＡＰリスト内に反映されたＡＰを更新し始める。例えば、幾つかの実施形態では、ネットワークモニタは、（例えば、ＡＰＩを介して又はメモリ空間内の各連続レコードを識別することを通じてプロトコルスタックのメモリ空間に直接アクセスすることにより）エントリ毎にロームテーブルにアクセスして良い。別の例として、幾つかの実施形態では、ネットワークモニタは、ロームテーブル自体のコピーを生成し、コピーのエントリを通じて反復して良い。このようなアプローチは、例えばプロトコルスタックのＡＰＩが要求により、個々の要求されたエントリではなく完全なロームテーブルのみを提供することができる場合、有用であり得る。次に、ステップ５１５で、ネットワークモニタは、知られているＡＰリストが既に現在のロームテーブルエントリにリストされたＡＰに対応するエントリを含むか否かを決定する。例えば、ステップ５１５は、ロームテーブルエントリのＡＰ名を知られているＡＰリスト内の各ＡＰ名と比較するステップを含み得る。一致がない場合、方法５００は、ステップ５２０に進み、ネットワークモニタは新しいＡＰの新しいエントリを知られているＡＰリストに追加する。知られているＡＰリストが固定長を有する実施形態では、ステップ５２０は、古いエントリ（例えば、最も古い又は最もアクティブでないエントリ）を知られているＡＰリストから除去して、新しいＡＰエントリの余地を生成するステップを更に含み得る。ステップ５２５で、ネットワークモニタは、現在のロームテーブルエントリがプロトコルスタックのロームテーブル内の最後のエントリか否かを決定する。最後ではない場合、方法５００は、ステップ５１０に戻り、追加ロームテーブルエントリを処理する。

知られているＡＰリスト内のＡＰがロームテーブル全体に基づき更新されると、方法５００は、ステップ５３０に進み、ネットワークモニタは、先ず分析するためにリストからＡＰを選択することにより、知られているＡＰの統計情報を更新し始める。ステップ５３５で、ネットワークモニタは、（例えば、ＡＰＩ、メモリに直接アクセス、等を介して）現在ＡＰがロームテーブル内に存在するか否かを決定する。存在しない場合、ステップ５４０、５７５で、ネットワークモニタは、ロームテーブル期間及び接続期間値（それぞれ、図４のフィールド４２０、４１５に対応し得る）をリセットする。ＡＰがロームテーブル内に現在存在する場合、方法５００は、代わりにステップ５３５からステップ５４５に進み、ＡＰのロームテーブルインスタンス（図４のフィールド４２５に対応し得る）がインクリメントされる。ステップ５５０で、ネットワークモニタは、現在ＡＰのロームテーブル期間を増大する。例えば、種々の実施形態では、ネットワークモニタは、方法５００の後の実行同士の間に経過した時間を追跡し、最後の実行からの時間をＡＰエントリ内の現在のロームテーブル期間値に加算して良い。別の例として、方法５００が周期的に実行する幾つかの実施形態では、ネットワークモニタは、所定位置をロームテーブル期間に加算して良い（例えば、方法５００の実行の期間と等しい値）。ステップ５５２で、ネットワーク装置は、現在ＡＰのＡＰリストエントリを、プロトコルスタックによりレポートされた現在のＳＮＲ（図３のフィールド４３０に対応し得る）で更新する。

ステップ５５５で、ネットワークモニタは、現在チャネルを前に記録されたチャネルと比較することにより、ＡＰがロームテーブルに現れた最後のときからＡＰのチャネルが変化したか否かを決定する。変化した場合、ステップ５６０で、ネットワークモニタは、ＡＰの新しいチャネルをＡＰリストに記録し、チャネル変化の指示を現在構成中の接続レポートに記録し、又は次の接続レポートが生成されるとき（例えば、幾つかの実施形態では、方法５００は方法３００の部分とis手実行しない）、接続レポートに含めるために指示を記録する。

次に、ネットワークモニタは、ステップ５７０で、プロトコルスタック及びネットワークインタフェースが現在ＡＰに現在接続されているか否かを決定する。この情報は、ロームテーブルに格納され、又は（例えば、ＡＰＩを介して）プロトコルスタックからアクセス可能であって良い。装置が現在ＡＰに接続されていない場合、方法５００はステップ５７５に進む。他方で、装置が現在ＡＰに接続されている場合、ネットワークモニタは、現在ＡＰエントリの接続期間を（例えば、ステップ５５０に関して上述したものと同じ値のうちの１つにより）増大する。ステップ５８５で、ネットワークモニタは、現在ＡＰが知られているＡＰリスト内の最後のＡＰか否かを決定する。最後ではない場合、方法は、ステップ５３０にループし、リスト内の残りのＡＰを処理する。知られているＡＰリスト内の全てのＡＰが更新されると、方法５００は、ステップ５９０に進み終了する。

図４に関して上述したように、種々の代替又は追加フィールドがＡＰリストに含められて良い。このような追加フィールドをサポートするための方法５００に対する種々の変形（例えば、追加、変更、又は省略されたステップ）が明らかである。

図６は、重要ＡＰを識別する方法６００の一例を示す。方法６００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の重要ＡＰ識別命令２６７に対応して良い。方法６００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（図３のステップ３２５と独立して又はその部分として）実行されて良い。

方法６００は、ステップ６０５で開始し、ステップ６１０に進み、ネットワーク装置は、ＡＰのエントリを知られているＡＰリスト（例えば、知られているＡＰリスト２７０又は４００）から検討のために読み出す。ステップ６１５で、ネットワークモニタは、エントリに格納された接続期間が第１接続期間閾ｔ１を超えるか否かを決定する。第１接続期間閾ｔ１（及び本願明細書に記載の他の閾）は、予め定められて良く、又は設定可能であって良い（例えば、インフラストラクチャモニタは、環境内の各ネットワークモニタに、特定閾を利用するよう指示して良い）。一例として、ｔ１は１時間の値に設定されて良い。閾が通過されると、方法６００は、ステップ６７０に進み、現在ＡＰのＡＰリストエントリが重要としてマークされる（例えば、図４のフィールド４１０に対応するフィールド内で）。その他の場合、方法６００は、ＡＰ重要性を判断する他の指標をテストすることに進む。

ステップ６２０で、ネットワークモニタは、ＡＰのロームテーブル期間が第１ロームテーブル期間閾ｔ２（例えば、４時間）を超えたか否かを決定する。超えた場合、方法６００はステップ６７０へ進む。その他の場合、ステップ６２５で、ネットワークモニタは、ＡＰのロームテーブル出現カウントが第１ロームテーブル出現閾（例えば、１０００）を超えたか否かを決定する。超えた場合、方法はステップ６７０へ進む。その他の場合、方法６００はステップ６３０へ進む。したがって、方法６００により検討される３つの統計情報のうちのいかなるものも、単独で、ＡＰを重要と満たすために（適切な閾ｔ１、ｔ２、又はｔ３を超えることにより）十分に高くて良い。

この例示的な実施形態によると、いかなる単一の値も十分に高くない場合でも、一緒に取り入れられる値は依然として重要指定を正当化し得る。ステップ６３０で、ネットワークモニタはスコア値を０に初期化する。次に、ステップ６３５で、ネットワークモニタは、接続期間が、第１接続期間閾ｔ１より小さくて良い第２接続期間閾ｔ４を通過したか否かを決定する。例えば、ｔ４は１０分であって良く、一方、ｔ１は１時間であって良い。超えた場合、接続期間重みｗ１（例えば４０）がスコアに加算されて良い。図示のように、重みは定数であって良いが、他の実施形態では、スコアに加算される量は接続期間値に依存して良い（例えば、量は、接続期間又は閾ｔ４を超える接続期間の部分によりスケーリングされて良い）。

次に、ステップ６４５で、ネットワークモニタは、ロームテーブル期間が、第１ロームテーブル期間閾ｔ２より小さくて良い第２ロームテーブル期間閾ｔ５を通過したか否かを決定する。例えば、ｔ５は１時間であって良く、一方でｔ２は４時間であって良い。超えた場合、ロームテーブル期間重みｗ２（例えば２０）がスコアに加算されて良い。図示のように、重みは定数であって良いが、他の実施形態では、スコアに加算される量はロームテーブル期間値に依存して良い（例えば、量は、ロームテーブル期間又は閾ｔ５を超えるロームテーブル期間の部分によりスケーリングされて良い）。ステップ６５５で、ネットワークモニタは、ロームテーブル出現値が、第１ロームテーブル出現閾ｔ６より小さくて良い第２ロームテーブル出現閾ｔ６を通過したか否かを決定する。例えば、ｔ５は５００インスタンスであって良く、一方でｔ２は１０００インスタンスであって良い。超えた場合、ロームテーブル出現重みｗ３（例えば２０）がスコアに加算されて良い。図示のように、重みは定数であって良いが、他の実施形態では、スコアに加算される量はロームテーブル出現値に依存して良い（例えば、量は、ロームテーブル出現又は閾ｔ６を超えるロームテーブル出現の部分によりスケーリングされて良い）。

スコアが計算されると、ネットワークモニタは、スコアがスコア閾ｔ７を超えるか否かを決定して、ＡＰが重要であると指定されるようにする。例えば、ｔ７は５０（接続期間及びロームテーブル期間又はロームテーブル出現が重要を示さなければならないことを示す）又は７０（３個全ての指標が重要を示さなければならないことを示す）の値に設定されて良い。ｔ７が超えられた場合、方法はステップ６７０に、次にステップ６７５に進む。その他の場合、方法は、ステップ６７５に直接進み、ネットワークモニタは、追加ＡＰが重要性評価のために残っているか否かを決定する。現在ＡＰがリスト内の最後のＡＰではない場合、方法６００は、ステップ６１０にループバックし、知られているＡＰリスト内の残りのＡＰを分析する。その他の場合、方法はステップ６８０に進み終了する。

本例に記載されたように、ＡＰは、接続期間、ロームテーブル期間、又はロームテーブル出現に単独に基づき、又はそれらの組み合わせに基づき、重要ＡＰとしての資格を取得し得る。ＡＰを重要としてマークする種々の代替統計情報及びアプローチが明らかである。例えば、幾つかの実施形態では、ステップ３３０〜３６５は、省略されて良く、又はステップ３１５〜５２５が省略されて良い。種々の他の変更が明らかである。

図７は、同一チャネル及び隣接チャネル干渉をテストする方法７００の一例を示す。方法７００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の装置側テスト命令２６８の１又は複数のセットに対応して良い。方法７００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（方法３００と独立して又はその部分として）実行されて良い。

方法７００は、ステップ７０５で開始し、ステップ７１０に進み、ネットワークモニタは、ＡＰのエントリを知られているＡＰリスト（例えば、知られているＡＰリスト２７０又は４００）から検討のために読み出す。ステップ７１５で、ネットワークモニタは、（例えば、読み出したＡＰエントリからチャネルを読み出すことにより）現在ＡＰに関連するチャネルを決定する。ステップ７２０で、ネットワークモニタは、ロームテーブル（又は幾つかの実施形態では、最終的な又はその他の場合包括的な知られているＡＰリストのような、知られているＡＰリスト）を、現在同じチャネル又は隣接チャネル（例えば、１チャネル離れている、２チャネル離れている、等）に存在するいかなる他のＡＰについて、検索する。ステップ７２５で、ネットワーク装置は、ステップ７２０でいかなる追加ＡＰも識別されたか否かを決定する。識別されていない場合、ネットワーク装置は、現在ＡＰについて同一チャネル又は隣接チャネル干渉が存在しないことを決定して良く、方法７００はステップ７８０に進んで良い。その他の場合、少なくとも１つの他のＡＰが識別された場合、方法７００はステップ７３０に進む。最後にロームテーブル／知られているＡＰリストが更新されて以来の可能なチャネル変化を考慮するために、ネットワークモニタは、（例えば、プロトコルスタックにＡＰＩを介してそうするよう指示することにより）チャネル又は隣接チャネルグループを探索して、いかなるＡＰが現在チャネル上に見えるか否かを決定して良い。ステップ７３５で、ネットワークモニタは、ステップ７３０におけるチャネル探索が、対象ＡＰ又は識別された他のＡＰの全部のいずれかがもはや見えないことを明らかにしたか否かを決定し、方法７００はステップ７８０に進む。その他の場合、ネットワークモニタは、干渉の可能性を識別し、問題の大きさを分析するためにステップ７４５に進む。

ステップ７４５で、ネットワーク装置は、対象ＡＰの信号レベル（例えば、ＳＮＲ値）が現在のテストを適用するのに十分強いか否かを決定する。具体的に、対象ＡＰが遠くにあり、干渉に拘わらず低信号を有する場合、干渉は容認されて良く、環境内のネットワークＡＰの配置及び構成が過度に制限されないようにする。したがって、ステップ７４５で、ネットワークモニタは、対象ＡＰ信号レベルが主信号レベル閾ＭＳＬｔ（例えば３０ｄＢ）を超えたか否かを決定する。超えない場合、方法７００はステップ７８０へ進んで良い。その他の場合、ステップ７５０で、ネットワークは、各々の識別された他のＡＰとの干渉の危険を分析することに進む。

ネットワークモニタは、ステップ７５０で識別された他のＡＰのうちの１つを読み出し、ステップ７５５で該他のＡＰの信号レベルを決定する。ステップ７６０で、ネットワーク装置は、２つの信号レベル間の差を計算する。例えば、ネットワーク装置は、単に、他のＡＰの信号レベルを対象ＡＰの信号レベルから減算して良い。幾つかの実施形態では、このステップは、チャネル間の距離を考慮して良い。例えば、２つのＡＰが１チャネル離れたチャネル上にあるとき、値（例えば、１０又は２０）が差に加算されて良い。チャネル間隔を考慮する他の方法が明らかである。ステップ７６５で、ネットワークモニタは、計算した差が信号レベル差閾ＳＬＤｔ（例えば２０ｄＢ）より下にあるか否かを決定し、それにより、チャネル干渉の相当の可能性又は影響を示す。幾つかの実施形態では、異なる閾が、同一チャネル及び隣接チャネル（又は各々の可能なチャネル距離）干渉テストのために設定されて良い。差が閾を通過するのに十分大きい場合、ネットワークモニタは、このＡＰペアが干渉の十分なリスクを引き起こさないと決定して良く、方法はステップ７５５にジャンプして良い。その他の場合、ネットワークモニタは、可能なチャネル衝突の指示を接続レポートに（例えば、現在構成中の接続レポートに、又は将来接続レポートを構成する別の処理によりアクセスされるべきメモリ内のスポットに）追加する。

ステップ７５５で、ネットワークモニタは、（ステップ７２０で識別されたような）いかなる他のＡＰが現在の対象ＡＰと一緒に検討するために残っているか否かを決定する。現在の他のＡＰが検討されるべき最後のものではない場合、方法７００はステップ７５０にループバックして良い。その他の場合、方法は、ステップ７８０に進み、ネットワークモニタは、いかなる追加の知られているＡＰが対象ＡＰとして分析されるために残っているか否かを決定する。現在の対象ＡＰが知られているＡＰリスト内の最後のものではない場合、方法７００は、ステップ７１０にループバックする。その他の場合、方法はステップ７８５に進み終了する。

図８は、低カバレッジをテストする例示的な方法８００を示す。低カバレッジは、例えば、接続のために使用されているＡＰが比較的低い信号レベルを有する場合、又は全ての見えるＡＰが比較的低い信号レベルを有する場合に、存在し得る。方法８００は、図示のように、両方の可能性についてテストして良いが、これらのうちの１つのみのテストに対する種々の変形が明らかである。方法８００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の装置側テスト命令２６８の１又は複数のセットに対応して良い。方法８００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（方法３００と独立して又はその部分として）実行されて良い。

方法８００はステップ８０５で開始し、ステップ８１０に進み、ネットワークモニタは、知られているＡＰから現在接続ＡＰのエントリを読み出す。次に、ステップ８１５で、ネットワークモニタは、読み出したエントリから接続ＡＰの信号レベルを読み出す。ステップ８２０で、ネットワークモニタは、例えば、接続ＡＰの信号レベルを「接続ＡＰに対する低接続テスト閾」（ＬＣＴ＿Ｃ＿ｔ）（例えば、−７０ｄＢｍ）と比較することにより、接続ＡＰが低信号レベルを有するか否かを決定する。信号レベルが低くない場合、ネットワークモニタは、方法８００の連続実行に渡り追跡される「接続ＡＰに対する低接続テスト期間」（ＬＣＴ＿Ｃ期間）をゼロにリセットする。言い換えると、信号レベルが閾より高い場合、接続ＡＰは、方法８００の現在の実行の、低接続状態で連続０秒を費やしたとしてマークされる。方法は、次に、ステップ８４５で非接続ＡＰを分析することに進む。

他方で、ネットワークモニタが、ステップ８２０で、接続ＡＰが低信号強度を現在有すると決定した場合、方法８００は、ステップ８３０に進み、ネットワークモニタは、追跡されたＬＣＴ＿Ｃ期間を、方法８００の最後の実行以来の時間に基づき（例えば、方法８００が周期的に実行されると分かっている場合に固定時間だけ、又は最後の実行からの時間を追跡する追跡変数により）増大させる。ステップ８３５で、ネットワークモニタは、接続ＡＰが、フラグを立てることを正当化するのに十分長い時間の間、低信号を有したか否かを決定する。このステップは、例えば、信号強度の短い又は一時的降下が偽アラームを生じないことを保証するために実行され得る。幾つかの実施形態では、ステップ８３５は完全に省略されても良い。低接続期間が「低接続テスト接続期間閾」（ＬＣＴ＿ＣＤｕｒ＿ｔ）（例えば１０分）より下に降下した場合、ネットワークモニタは、発見を記述する低接続エントリを、現在の接続レポートに（例えば、構成中の接続レポートに、又は将来に接続エントリを構成する別の処理により読み出され得るメモリ内の場所に）追加して良い。その他の場合、方法８００は、ステップ８４０（これは、ＬＣＴ＿Ｃ期間が最終的にＬＣＴ＿ＣＤｕｒ＿ｔを通過した場合に方法８００の将来の実行で実行され得る）をスキップする。

ネットワークモニタは、次に、ステップ８４５で追跡ブール変数ａｌｌＬｏｗを真に初期化することにより、非接続ＡＰを分析することを開始する。次に、ステップ８５０で、ネットワークモニタは、知られているＡＰリストから、範囲内のＡＰに対応する（例えば、非ゼロ信号レベルに関連する、非ゼロロームテーブル期間を有する、又は現在ロームテーブル内に存在する）レコードを読み出す。ステップ８５５で、ネットワークモニタは、読み出したエントリから現在ＡＰの信号レベルを読み出す。ステップ８６０で、ネットワークモニタは、例えば、接続ＡＰの信号レベルを「非接続ＡＰに対する低接続テスト閾」（ＬＣＴ＿ＮＣ＿ｔ）（例えば−７５ｄＢｍ）と比較することにより、現在ＡＰが低信号レベルを有するか否かを決定する。幾つかの実施形態では、ＬＣＴ＿ＮＣ＿ｔ及びＬＣＴ＿Ｃ＿ｔは同じ閾であって良い。信号レベルが低くない場合、ネットワークモニタは、方法８００の連続実行に渡り追跡される現在ＡＰの「非接続ＡＰに対する低接続テスト期間」（ＬＣＴ＿ＮＣ期間）をゼロにリセットする。言い換えると、信号レベルが閾より高い場合、現在ＡＰは、方法８００の現在の実行の、低接続状態で連続０秒を費やしたとしてマークされる。ネットワークモニタは、次に、ステップ８８０で、ａｌｌＬｏｗ変数を偽に設定し、少なくとも１つの非接続ＡＰが方法８００の現在の実行において低信号を有しないと見なされたことを示す。

他方で、ネットワークモニタが、ステップ８６０で、現在ＡＰが低信号強度を現在有すると決定した場合、方法８００は、ステップ８７０に進み、ネットワークモニタは、追跡されたＬＣＴ＿ＮＣ期間を、方法８００の最後の実行以来の時間に基づき（例えば、方法８００が周期的に実行されると分かっている場合に固定時間だけ、又は最後の実行からの時間を追跡する追跡変数により）増大させる。ステップ８８５で、ネットワークモニタは、現在ＡＰが、フラグを立てることを正当化するのに十分長い時間の間、低信号を有していたか否かを決定する（他の非接続の場合、範囲内Ａは同様にフラグを正当化する）。このステップは、例えば、信号強度の短い又は一時的降下が偽アラームを生じないことを保証するために実行され得る。幾つかの実施形態では、ステップ８７５は完全に省略されても良い。定説属の期間が「低接続テスト非接続期間閾」（ＬＣＴ＿ＮＣＤｕｒ＿ｔ）（例えば５分）より下に降下した場合、方法はステップ８８５に進み（ｓｌｌＬｏｗは真に設定されたまま）、その他の場合、方法８００はステップ８８０に進み得る。幾つかの実施形態では、ＬＣＴ＿ＮＣＤｕｒ＿ｔ及びＬＣＴ＿ＣＤｕｒ＿ｔは同じ閾であって良い。

ステップ８８５で、ネットワークモニタは、追加非接続、範囲内APが検討のために残っているか否かを決定する。現在ＡＰが範囲内の最後ではないが非接続ＡＰである場合、方法８００は、ステップ８５０にループバックする。その他の場合、方法８００は、ステップ８９０に進み、ネットワークモニタは、追跡変数ａｌｌＬｏｗが方法８００の実行中、真のままであるか否かを決定する。真のままである場合、ネットワークモニタは、全ての範囲内非接続ＡＰが、フラグを立てるのに十分長い間、低信号強度状態にあったと決定して良い。ネットワークモニタは、ステップ８９５で、発見を記述する低接続エントリを現在接続レポートに（例えば、構成中の接続レポートに、又は将来に接続エントリを構成する別の処理により読み出され得るメモリ内の場所に）追加して良い。次に、方法８００はステップ８９９に進み終了する。

図９は、カバレッジ外インスタンスを追跡する方法９００の一例を示す。カバレッジ外イベントは、例えば、装置がいかなるＡＰも（又は装置が接続するよう構成されるいかなるＡＰも）見えない領域に入る場合に存在して良い。方法９００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の装置側テスト命令２６８の１又は複数のセットに対応して良い。方法９００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（方法３００と独立して又はその部分として）実行されて良い。

方法９００は、ステップ９０５で開始し、ステップ９１０に進み、ネットワークモニタは、（例えば、ロームテーブルをクエリすることにより、又は非ゼロ接続期間を有するＡＰについて知られているＡＰリストを調べることにより）装置がＡＰに現在接続されているか否かを決定する。装置がＡＰに現在接続されていない場合、カバレッジ外イベントが存在し得、方法９００は、ステップ９１５に進み、ネットワークモニタは、ロームテーブルが現在空であるか（又は幾つかの実施形態では、装置が接続できないＡＰのみを含むか）否かを決定する。ロームテーブルが空である場合、ネットワークモニタは、カバレッジ外イベントが進行中であると決定して良い。このような場合には、方法９００は、ステップ９２０に進み、ネットワークモニタは、カバレッジ外イベントの長さを測定する時間が既に開始されているか否かを決定する。開始されていない場合、ネットワークモニタは、ステップ９２５で、別のステップ（例えばステップ９３０）の動作により停止されるまで方法９００の連続実行に渡り動作し続ける新しいタイマを開始する。

他方で、ネットワークモニタが、ステップ９１５でロームテーブルは空ではないと決定した場合、方法９００は、ステップ９３０に進み、（ロームテーブルが再投入されると、いかなる既存のカバレッジ外イベントも終了し得るので）ネットワークモニタはタイマを停止する。ステップ９３５で、ネットワークモニタは、イベントが、開始から終了までタイマにより追跡された期間をカバレッジ外閾（ＯＯＣ）（例えば５分）と比較することにより、フラグを立てるのに十分長く継続したか否かを決定する。イベントが十分長く継続した場合、ネットワークモニタは、接続レポートに含めるために、ステップ９４０でカバレッジ外エントリを準備する。このエントリは、カバレッジ外イベントの期間、又はイベント中の装置のＧＰＳ座標、のような種々の情報を含み得る。接続レポートを送信するためのいかなる接続も（未だ）存在しないので、ネットワークモニタは、本ステップで、エントリを接続レポートに直接追加しなくて良い。他の実施形態では、ネットワークモニタは、構成中の接続レポートに、それが送信され得るまで保持するために、情報を直接追加して良い。

装置がＡＰに再度接続されると、方法９００は、ステップ９１０からステップ９４５へ進み、ネットワークモニタは、（例えば、方法９００の前の実行のステップ９４０の実行により）１又は複数のカバレッジ外エントリが構成されたか否かを決定する。構成された場合、エントリ（又は複数のエントリ）は、ステップ９５０で接続レポートに追加される。次に、方法９００はステップ９５５に進み終了する。

方法９００に対する種々の変更が明らかである。例えば、幾つかの実施形態では、方法９００は、ロームテーブルが再投入されたときと装置がＡＰに再接続されるときとの間に少なくとも１回実行すると仮定しなくて良い。このような実施形態では、ステップ９３０〜９４０は、ステップ９１０が装置はＡＰに接続されると決定するときに訪れられる方法９００のブランチに複製して移動されて良い。

図１０は、低信号対雑音比（ＳＮＲ）をテストする方法１０００の一例を示す。方法１０００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の装置側テスト命令２６８の１又は複数のセットに対応して良い。方法１０００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（方法３００と独立して又はその部分として）実行されて良い。図示のように、方法１０００は、重要ＡＰに対して、非重要ＡＰに対する動作と異なる方法で動作し得る。したがって、方法１０００は、通常インフラストラクチャテスト及び重要インフラストラクチャテストの両方を構成し得る。非重要ＡＰ及び重要ＡＰに対する異なる動作を示すための本願明細書に記載された他の方法に対する種々の変更が明らかである。

方法１０００はステップ１００５で開始し、ステップ１０１０に進み、ネットワークモニタは、信号強度の分析のために、知られているＡＰリストからＡＰを読み出す。ステップ１０１５で、ネットワークモニタは、（例えば、ＳＮＲ値が存在するか又は非ゼロであるか、期間が非ゼロであるか否か、又はＡＰがロームテーブルに現在存在するか否か、を決定することにより）ＡＰが現在、範囲内か否かを決定する。ＡＰが範囲内にない場合、信号強度テストは、ＡＰに適用されなくて良く、方法１０００はステップ１０５０へスキップして良い。

ネットワークモニタが範囲内にいるＡＰを見付けると、方法１０００は、ステップ１０２０に進み、ネットワークモニタは、知られているＡＰリスト内の（又はロームテーブルから又は新しい探索を要求する）ＡＰのマークされたＳＮＲを読み出し、ステップ１０２５で、（例えば、知られているＡＰリスト内の現在ＡＰのエントリからの指示を読み出すことにより）ＡＰが重要ＡＰであるか否かを決定する。現在ＡＰが重要ＡＰである場合、ネットワークモニタは、ＳＮＲが重要ＡＰについて設定された閾（ＣｒｉｔＳＮＲｔ）（例えば４０）より下に降下したか否かを決定する。ＳＮＲが重要閾より低い場合、ネットワークモニタは、ステップ１０３５で、低ＳＮＲ状態を記述する情報を接続レポートに（例えば、構成中の接続レポートに直接、又は次回接続レポートが生成されるときに読み出されるメモリ内の領域に）追加する。

他方で、現在ＡＰが重要ではない場合、同様の処理が続くが、通常に適用可能なＳＮＲ閾（ＧＥＮＳＮＲｔ）（例えば３０）に基づく。例えば、高信号強度を有することは、他の知られているＡＰと比べて重要ＡＰに対する方がより重要であると考えられ、したがって、信号強度の降下をレポートする制約はより高く設定されて良いので、重要閾は通常閾より高く設定されて良い。ステップ１０４０で、ＳＮＲがＧｎｅＳＮＲｔより下に降下したと決定された場合、ネットワークモニタは、ステップ１０４５で、低ＳＮＲ状態を記述する情報を接続レポートに（例えば、構成中の接続レポートに直接、又は次回接続レポートが生成されるときに読み出されるメモリ内の領域に）追加する。ステップ１０５０で、ネットワークモニタは、現在ＡＰが処理されるべき最後のＡＰか否かを決定する。現在ＡＰが知られているＡＰリスト内の最後のＡＰではない場合、方法１０００は、ステップ１０１０にループバックし、リスト内の残りのＡＰを処理する。知られているＡＰリスト全体が検討されると、方法１０００は、ステップ１０５５に進み終了する。

図１１は、重要ＡＰの高クライアント密度をテストする方法１１００の一例を示す。方法１１００は、図１のネットワークモニタ１１６のようなクライアント装置のネットワークモニタにより実行されて良く、図２の装置側テスト命令２６８の１又は複数のセットに対応して良い。方法１１００は、周期的に（例えば、毎分又は５分毎）、インフラストラクチャモニタのような別の装置による要求により、ロームテーブルが更新されたプロトコルスタックからの指示により、のような種々のときに（方法３００と独立して又はその部分として）実行されて良い。図示のように、方法１１００は重要ＡＰに対してのみテストを実行して良い。重要ＡＰに対してのみ適用するための本願明細書に記載された他の方法に対する種々の変更が明らかである。

方法１１００はステップ１１０５で開始し、ステップ１１１０に進み、ネットワークモニタは、知られているＡＰリストから（存在する場合）第１重要ＡＰを読み出して良い。ステップ１１１５で、ネットワークモニタは、現在重要ＡＰに接続された現在クライアントカウントを読み出して良い。この情報は、例えば、プロトコルスタックから（例えば、ロームテーブル内、他のメモリ部分、又はプロトコルスタックに利用可能な１又は複数のネットワークツールの使用を要求することを介して）利用可能であって良い。代替として、ネットワークモニタは、情報を直接ポーリングするために、重要ＡＰへメッセージを送信して良い。更な代替として、情報は、ネットワークモニタソフトウェア自体により、ＡＰのビーコン又は探査応答に含まれるＱＯＳ拡張基本サービスセット（QOS enhanced basic service set：ＱＢＳＳ）情報要素（ＩＥ）からマイニングされて良い。ステップ１１２０で、ネットワークモニタは、重要ＡＰのクライアントカウントが、クライアントカウントをクライアントカウント閾（ＣＣｔ）（例えば５０クライアント）と比較することにより、（例えば、ＡＰの見込み負荷として）インフラストラクチャモニタにレポートするのほど高いか否かを決定する。クライアントカウントが十分に高い場合、ネットワークモニタは、（例えば、接続レポートに追加する前述の方法のうちの１又は複数に従い）高クライアント密度を記述する情報を接続レポートに追加する。その他の場合、方法１１００は、先にスキップして、別個の利用テストを開始する。

ステップ１１３０で、ネットワークモニタは、重要ＡＰに関連するネットワーク利用率を読み出す。ここでも、これは、例えば、プロトコルスタックから（例えば、ロームテーブル内、他のメモリ部分、又はプロトコルスタックに利用可能な１又は複数のネットワークツールの使用を要求することを介して）利用可能であって良い。代替として、ネットワークモニタは、情報を直接ポーリングするために、重要ＡＰへメッセージを送信して良い。ステップ１１３５で、ネットワークモニタは、重要ＡＰの利用率が、利用率を利用率閾（Ｕｔ）（例えば９０％）と比較することにより、（例えば、ＡＰの見込み負荷として）インフラストラクチャモニタにレポートするのほど高いか否かを決定する。利用率が十分に高い場合、ネットワークモニタは、（例えば、接続レポートに追加する前述の方法のうちの１又は複数に従い）高クライアント密度を記述する情報を接続レポートに追加する。その他の場合、方法１１００はステップ１１４５にスキップする。

ステップ１１４５で、ネットワークモニタは、追加重要APがテストのために残っているか否かを決定する。現在重要ＡＰが知られているＡＰリスト内の最後のＡＰではない場合、方法１１００は、ステップ１１１０にループバックし、残りの重要ＡＰを処理する。その他の場合、方法１１００はステップ１１５０に進み終了する。

本願明細書に記載された種々の実施形態は多くの別個の方法の間で別個の複数のテストを記載したが、他の実施形態は、このような方法を１つのアルゴリズムに凝縮して良いことに留意する。例えば、幾つかの実施形態では、ステップ８４５〜８９５及びステップ１０１５〜１０４５は、方法７００に（例えばステップ７１０の直後に）挿入されて良く、ステップ７１０及び７８０により既に生成されたループを利用するようにして良い。別の例として、幾つかの実施形態では、ステップ１１１５〜１１４０は、方法６００に（例えばステップ６７０の後に）挿入されて良く、重要ＡＰを識別した直後に、重要ＡＰ固有テストを直ちに実行するようにして良い。本願明細書に記載した方法の種々の他の変更が明らかである。

図１２は、ネットワーク管理者への提示のために接続レポートを処理する方法１２００の一例を示す。方法１２００は、インフラストラクチャモニタ（例えば、図１のインフラストラクチャモニタ１５０）により実行されて良く、図２の報告収集命令２７３、報告分析命令２７５、及び警告命令２７６に対応して良い。方法１２００は、周期的に（例えば、５分毎、１時間毎、等）、接続レポートを受信すると（例えば、新しい接続レポートの度に、５個の接続レポートを受信すると、各アクティブネットワークモニタから少なくとも１つの接続レポートを受信すると、等）、又は何からの他の基準で、実行されて良い。

方法１２００は、ステップ１２０５で開始し、ステップ１２１０に進み、インフラストラクチャモニタは、１又は複数の接続レポートをシステムのクライアント装置に展開されたネットワークモニタから受信する。ステップ１２１５で、インフラストラクチャモニタ装置は、追加統計情報（例えば、平均ＡＰ負荷、重要とマークされた全てのＡＰのリスト、カバレッジ外イベントのマップ、低接続イベントのタイムライン、等のような複数の接続レポートに渡り認められる種々の統計情報）を導出する。ステップ１２２０で、インフラストラクチャモニタは、接続レポートの１又は複数の視覚化を提示する（又は後の要求による提示のために生成する）。

インフラストラクチャモニタは、ステップ１２２５で、いかなる警告が上げられるべきか否かを決定し始め、（接続レポート内で配信された又はそれらから導出された）統計情報を１又は複数の所定の警告ルールと比較する。例えば、ルールは、少なくとも１０個の装置（例えば、患者モニタ）により重要とマークされたＡＰが７０％の利用率に達した場合、警告が上げられるべきであると定めて良い。以下の表１は、接続レポート内でレポートされたイベントに基づき上げられるべき複数の助言ルールの別の例を含む。

ステップ１２３０で、インフラストラクチャモニタは、助言ルールのうちの１又は複数が満たされたと決定する。次にステップ１２３５で、インフラストラクチャモニタは、（例えば、管理者によりアクセスされるとき管理ポータル／ウェブサイトのホームページ又は助言ページ上で助言のリストをレンダリングすることにより）ネットワーク管理者に利用可能なこれらの助言の識別を行う。インフラストラクチャモニタは、次に、ステップ１２４０で、ステップ１２２５の結果として生じた助言のうちのいかなる助言が重要か否かを決定することにより、助言のうちのいかなる助言が１又は複数のネットワーク管理者に通知をプッシュするに値するか否かを決定することに進む。助言は、例えば関連するルールが重要であると見なされることに基づき、特定の重要閾又は他の重要基準がルール内で満たされることに基づき（例えば、ルールが通常閾及び重要閾を含み得る）、助言が存在していた期間に基づき、１又は複数の重要ＡＰが影響されていること等に基づき、重要と見なされて良い。重要と満たされた場合、インフラストラクチャモニタは、ステップ１２４５で、警告（例えば、テキストメッセージ、電子メール、電話呼、等）をネットワーク管理者へ送信して良い。方法１２００はステップ１２５０に進み終了して良い。

以上により、種々の実施形態は、より堅牢な利用可能性及び性能のために、無線ネットワークインフラストラクチャの監視の拡張を可能にし及び適用する。例えば、標準的なプロトコルにより実行されるタスクを超えて、ネットワークのクライアント装置に少なくとも何らかの監視及びレポートを実行することを任せることにより、監視全体が、１又は少数の中央装置ではなく、複数の（場合によっては多数の）装置の間で分散でき、ネットワーク状態を学習するためにネットワークを繰り返し探索する。さらに、重要ノードを識別するクライアント装置を提供することにより、（どのＡＰが重要であると見なされるかを学習する利益自体と共に）このような分散システムにおいて実行される冗長処理及びレポートの量が削減できる。種々の追加の利益が、以上の観点から明らかである。

本発明の種々の例示的な実施形態がハードウェア又はファームウェアで実装され得ることが前述の記載から明らかである。さらに、種々の例示的な実施形態は、本願明細書に詳細に記載した動作を実行するために少なくとも１つのプロセッサにより読み出され実行され得る、機械可読記憶媒体に格納された命令として実施されて良い。機械可読記憶媒体は、パーソナル又はラップトップコンピュータ、サーバ、又は他のコンピューティング装置のような機械により読み取り可能な形式で情報を格納するいかなる媒体も包含し得る。したがって、機械可読記憶媒体は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置及び同様の記憶媒体を包含しうる。

本願明細書で提示されるいかなるブロック図も本発明の原理を具現化する説明のための回路の概念図を提示するものであることが当業者により理解されるべきである。同様に、いかなるフローチャート、フロー図、状態遷移図、擬似コード等も種々の処理を表し、機械可読媒体に実質的に表現されて良く、従ってコンピュータ又はプロセッサにより実行されて良く、該コンピュータ又はプロセッサが明示されているか否かを問題としないことが理解される。

種々の例示的な実施形態がその特定の例示的な態様を特に参照して詳述されたが、本発明は他の実施形態が可能であり、その詳細は種々の明らかな観点で変更が可能であることが理解されるべきである。当業者に直ちに明らかなように、本発明の精神及び範囲内に留まりながら、変形及び変更が可能である。したがって、以上の開示、説明、及び図面は、単なる説明目的であり、請求項によってのみ定められる本発明をいかなる方法でも制限しない。

例えば、無線患者監視の分野では、患者の発作を検出する際の遅延が悪影響をもたらし、生死の差を意味する場合さえあるので、患者データがリアルタイムに中央装置へストリーミングされることが重要である。事業無線システムは、病院（又は接続の重要なアプリケーションの展開される他の場所）中の接続の品質を管理するツールを提供することを主張しているが、これらのシステムは、閉じられることが多く、サポートされている特定のアプリケーションにとって不完全である。例えば、このようなシステムは、非タイムクリティカルなアプリケーションに適するがリアルタイムの重要なアプリケーションに対して不利益をもたらす広範な一般的な且つ頻繁なネットワーク変更を通じて、オンサイト無線ネットワークを編成しようと試みることがある。
親出願であるＷＯ２０１６／１２５０５５Ａ１（「Method for testing client roaming」）、ＷＯ２０１１／１０３５１５Ａ１（「Controlling access point transmit power based on access terminal ranking」）、及びＵＳ２０１２／１７０４７４Ａ１（「System and Method of Adaptive Roaming for WLAN Clients」）を参照のこと。

Claims (15)

1. 患者監視装置であって、
   無線通信インタフェースと、
   患者の少なくとも１つの生理的パラメータを測定する患者監視ハードウェアと、
   プロセッサであって、
   前記無線通信インタフェースを介する通信を可能にするプロトコルスタックを提供し、
   前記プロトコルスタック及び前記無線通信インタフェースを介して前記少なくとも１つの生理的パラメータを送信し、
   前記プロトコルスタックから複数のＡＰに関する無線アクセスポイント（ＡＰ）情報を要求し、
   前記ＡＰ情報に基づき接続レポートを生成し、
   前記プロトコルスタック及び前記無線通信インタフェースを介してリモートサーバへ前記接続レポートを送信する、
   よう構成されるプロセッサと、
   を含む患者監視装置。
2. 前記プロセッサは、
   前記複数のＡＰのうちの少なくとも１つのＡＰを重要ＡＰとして識別するよう更に構成され、
   前記接続レポートは前記重要ＡＰを識別する、請求項１に記載の患者監視装置。
3. 前記複数のＡＰのうちの前記少なくとも１つのＡＰを重要ＡＰとして識別する際に、前記プロセッサは、
   前記ＡＰの接続期間が接続期間閾を超えるか否かを決定し、前記プロセッサは前記の要求されたＡＰ情報に基づき前記接続期間を決定し、前記接続期間は、接続が前記プロトコルスタックと前記ＡＰとの間に確立されている時間期間を示すこと、
   前記ＡＰのロームテーブル期間がロームテーブル期間閾を超えるか否かを決定し、前記の要求されたＡＰ情報は前記プロトコルスタックにより維持されるロームテーブルを含み、前記ロームテーブル期間は、前記ＡＰが前記プロトコルスタックにより前記ロームテーブル内に保持されている時間期間を示すこと、
   ロームテーブル出現カウントがロームテーブル出現カウント閾を超えるか否かを決定し、前記ロームテーブル出現カウントは、前記ＡＰが前記ＡＰ情報を要求するステップの一連の実行に渡り前記ロームテーブル内で観察される回数を示すこと、
   のうちの少なくとも１つを実行するよう構成される、請求項２に記載の患者監視装置。
4. 前記プロセッサは、
   前記重要ＡＰのみに関して少なくとも１つのテストを実行し、
   前記少なくとも１つのテストからの結果を前記接続レポートに含める、
   よう更に構成される、請求項２に記載の患者監視装置。
5. 前記プロセッサは、
   前記複数のＡＰに関する少なくとも１つのテストを実行し、
   前記少なくとも１つのテストは、重要ＡＰに対して第１方法で実行され、
   前記少なくとも１つのテストは、重要ＡＰ以外のＡＰに対して前記第１方法と異なる第２方法で実行され、
   前記少なくとも１つのテストからの結果を前記接続レポートに含める、
   よう更に構成される、請求項２に記載の患者監視装置。
6. 前記プロセッサは、
   前記複数のＡＰに関して少なくとも１つのテストを実行し、
   前記少なくとも１つのテストからの結果を前記接続レポートに含める、
   よう更に構成される、請求項１に記載の患者監視装置。
7. 前記少なくとも１つのテストを実行する際に、前記プロセッサは、前記要求されたＡＰ情報を分析して、ネットワークインフラストラクチャに関する警告が前記リモートサーバに上げられるべきか否かを決定するよう構成される、請求項４乃至６のいずれかに記載の患者監視装置。
8. 前記少なくとも１つのテストは、
   前記ＡＰの低信号対雑音比のテスト、
   ＡＰ間の同一チャネル干渉のテスト、
   ＡＰ間の隣接チャネル干渉のテスト、
   いかなるＡＰのネットワークカバレッジ外での経過期間のテスト、
   ＡＰからの低ネットワークカバレッジのテスト、
   ＡＰにおけるチャネル変化のテスト、
   ＡＰのクライアント密度のテスト、
   のうちの少なくとも１つを含む、請求項４乃至６のいずれかに記載の患者監視装置。
9. 前記要求されたＡＰ情報は前記ＡＰの８０２．１１ビーコンであり、前記接続レポートは前記８０２．１１ビーコンからの情報の少なくとも一部を含む、請求項１に記載の患者監視装置。
10. 無線ネットワーク装置のプロセッサにより実行される装置側ネットワーク監視の方法であって、前記方法は、
    前記無線ネットワーク装置の無線通信インタフェースを介する通信を可能にする前記プロセッサにより実装されるプロトコルスタックから複数の無線アクセスポイント（ＡＰ）に関するＡＰ情報を要求するステップと、
    前記ＡＰ情報に基づき前記複数のＡＰのうちの少なくとも１つのＡＰの現在状態に関する接続レポートを生成するステップと、
    前記プロトコルスタック及び前記無線通信インタフェースを介して、リモートサーバへ前記接続レポートを送信するステップと、
    を含む方法。
11. 前記複数のＡＰのうちの少なくとも１つのＡＰを重要ＡＰとして識別するステップ、を更に含み、
    前記接続レポートは前記重要ＡＰを識別する、請求項１０に記載の方法。
12. 前記複数のＡＰのうちの少なくとも１つのＡＰを重要ＡＰとして識別するステップは、
    前記ＡＰの接続期間が接続期間閾を超えるか否かを決定するステップであって、プロセッサが前記の要求されたＡＰ情報に基づき前記接続期間を決定し、前記接続期間は、接続が前記プロトコルスタックと前記ＡＰとの間に確立されている時間期間を示す、ステップ、
    前記ＡＰのロームテーブル期間がロームテーブル期間閾を超えるか否かを決定するステップであって、前記の要求されたＡＰ情報は前記プロトコルスタックにより維持されるロームテーブルを含み、前記ロームテーブル期間は、前記ＡＰが前記プロトコルスタックにより前記ロームテーブル内に保持されている時間期間を示す、ステップ、
    ロームテーブル出現カウントがロームテーブル出現カウント閾を超えるか否かを決定するステップであって、前記ロームテーブル出現カウントは、前記ＡＰが前記ＡＰ情報を要求するステップの一連の実行に渡り前記ロームテーブル内で観察される回数を示す、ステップ、
    のうちの少なくとも１つを含む、請求項１１に記載の方法。
13. 前記複数のＡＰに関する少なくとも１つのテストを実行するステップであって、
    前記少なくとも１つのテストは、重要ＡＰに対して第１方法で実行され、
    前記少なくとも１つのテストは、重要ＡＰ以外のＡＰに対して前記第１方法と異なる第２方法で実行される、ステップと、
    前記少なくとも１つのテストからの結果を前記接続レポートに含めるステップと、
    を更に含む請求項１２に記載の方法。
14. 前記少なくとも１つのテストを実行するステップは、前記要求されたＡＰ情報を分析して、ネットワークインフラストラクチャに関する警告が前記リモートサーバに上げられるべきか否かを決定するステップを含む、請求項１３に記載の方法。
15. 前記少なくとも１つのテストは、
    前記ＡＰの低信号対雑音比のテスト、
    ＡＰ間の同一チャネル干渉のテスト、
    ＡＰ間の隣接チャネル干渉のテスト、
    いかなるＡＰのネットワークカバレッジ外での経過期間のテスト、
    ＡＰからの低ネットワークカバレッジのテスト、
    ＡＰにおけるチャネル変化のテスト、
    ＡＰのクライアント密度のテスト、
    のうちの少なくとも１つを含む、請求項１３に記載の方法。

Images