2013 年 12 月 11 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2010 年 5 月 17 日) | フィードバック

目次

      要件
      表記法
      重要な用語
      RRM の鳥瞰図

概要

このドキュメントでは、無線リソース管理(RRM)の機能と運用について詳しく説明します。また、この機能を実現しているアルゴリズムの詳細についても説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

注: クライアントのアグレッシブ ロード バランシングと不正検出/抑止(その他の Cisco 侵入検知システム(IDS)や Cisco IOS® 侵入防御システム(IPS)の機能)は、RRM の機能ではなく、このドキュメントの範囲外です。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。

4.1.185.0 以降へのアップグレード:変更または確認すべき点

  1. CLI で、次の部分を確認します。

    show advanced [802.11b|802.11a] txpower

    新しいデフォルト値は -70 dBM です。変更されている場合は、さまざまな条件下で最適であること証明されているので、この新しいデフォルト値に戻してください。この値は、RF グループのすべてのコントローラで同じにする必要があります。変更後は設定を忘れずに保存してください。

    この値を変更するには、次のコマンドを発行します。

    config advanced [802.11b|802.11a] tx-power-control-thresh 70
  2. CLI で、次の部分を確認します。

    show advanced [802.11a|802.11b] profile global

    結果は次のようになります。

    802.11b Global coverage threshold.............. 12 dB for 802.11b
    802.11a Global coverage threshold.............. 16 dB for 802.11a

    結果が異なる場合は、次のコマンドを使用します。

    config advanced 802.11b profile coverage global 12
    config advanced 802.11a profile coverage global 16

    最適な結果を得るためには、クライアントが違反しているかどうかや、(カバレッジと呼ばれる)カバレッジ ホール アルゴリズムの緩和が開始されているかどうかを判断する、クライアントの SNR カットオフ パラメータをデフォルト値に戻す必要があります。

  3. CLI で、次の部分を確認します。

    show load-balancing

    これで、ロードバランシングのデフォルトの状態が 無効になりました。有効になっている場合は、デフォルトのウィンドウが 5 になります。つまり、関連付けの上でロードバランシングが発生する前に、この数のクライアントを無線に関連付ける必要があります。ロードバランシングは、高密度のクライアント環境で非常に役立ちます。この機能を使用するかどうかは管理者が決定し、クライアントの関連付けと分散の動作を理解しておく必要があります。

無線リソース管理:ヒントとベスト プラクティス

RF グループ化と Tx 電力しきい値

ヒント:

原因:

RF グループ名は、ワイヤレス LAN コントローラ(WLC)ごとに設定される ASCII 文字列です。グループ化アルゴリズムは、RF グループのリーダーを選出し、次に、RF グループ全体の送信電力制御(TPC)と動的チャネル割り当て(DCA)を計算します。例外はカバレッジ ホール アルゴリズム(CHA)で、WLC ごとに実行されます。RF グループ化は動的であり、デフォルトでこのアルゴリズムは 600 秒間隔で実行されるので、新しいネイバーが受信される(または既存のネイバーが受信できなくなる)可能性があります。このため、RF グループが変更され、(1 つまたは複数の RF グループに対して)新しいリーダーが選出される場合があります。このとき、TPC アルゴリズムでは、新しいグループ リーダーの Tx 電力しきい値が使用されます。このしきい値が同じ RF グループ名を共有する複数のコントローラ間で一致しないと、TPC 実行時の結果で Tx 電力レベルの不一致が発生する可能性があります。

カバレッジ プロファイルと SNR カットオフ

ヒント:

原因:

カバレッジ測定では、クライアントごとの最大許容 SNR としてデフォルトで 12 dB が使用されます。SNR がこの値を超えるクライアントが 1 台でもあると、アクセス ポイント(AP)が SNR が不適切なクライアントを検出した WLC によって CHA がトリガされます。(多くの場合、ローミング ロジックが不十分な)レガシー クライアントが存在する場合は、許容可能なノイズ フロアを調整して 3 dB まで低下させると一時的に対応できます(4.1.185.0 以降では必要ありません)。

この詳細については、「カバレッジ ホールの検出と補正アルゴリズム」セクションの「スティッキ クライアントの電力増大に関する考慮事項」に記載されています。

ネイバー メッセージの頻度(RF グループの形成)

ヒント:

原因:

デフォルトで、ネイバー メッセージは 60 秒ごとに送信されます。この頻度は、[Auto RF] ページの [Monitor Intervals] セクションにある [Signal Measurement](4.1.185.0 以降では [Neighbor Packet Frequency])で制御されます(図 15 を参照)。ネイバー メッセージは AP が受信するネイバーのリストを伝達し、次にそれが対応する WLC に伝達されて、最終的にその WLC から RF グループが形成されます(RF グループ名の設定が同じであることを前提としています)。RF のコンバージェンス時間は、ネイバー メッセージの頻度によって完全に決定されるため、このパラメータを適切に設定する必要があります。

オンデマンド オプションの使用

ヒント:

原因:

システム全体のアルゴリズム変更を予測する必要があるユーザのために、RRM をオンデマンド モードで実行できるようになりました。RRM アルゴリズムを使用すると、最適なチャネルおよび電力の設定が計算され、それらが次の 600 秒の間隔で適用されます。このとき、アルゴリズムは次にオンデマンド オプションが使用されるまで休止状態になり、システムはフリーズ状態になります。詳細については、図 11 および 図 12 と、それぞれの説明を参照してください。

ロードバランシング ウィンドウ

ヒント:

原因:

アグレッシブ ロードバランシングは RRM と連携していないものの、ローミング ロジックが不十分なレガシー クライアントでは、クライアントのローミングが最適化されずスティッキ クライアントになる可能性があります。このことは、CHA では逆効果になる場合があります。WLC のロードバランシング ウィンドウはデフォルトで 0 に設定されますが、これは適切ではありません。この値は、ロードバランシング メカニズムを開始するために必要な AP 上のクライアントの最低数として解釈されます。内部調査と実験により、このデフォルト値をより現実的な値(10 や 12 など)に変更する必要があることが明らかになりました。当然ながら、導入ごとにニーズが異なるため、ウィンドウを適切に設定する必要があります。コマンドライン構文は次のとおりです。

(WLC) >config load-balancing window ?            
<client count> Number of clients (0 to 20)

高密度の実稼働ネットワークでは、ロードバランシングを ON、ウィンドウ サイズを 10 に設定するとコントローラが最適に動作することが確認されています。つまり、具体的には、会議室やオープンなエリア(ミーティングまたはクラス)で多くの人が集まる場合に限り、ロードバランシング動作が有効になることを意味します。ロードバランシングは、このようなシナリオで利用可能な各 AP 間にユーザを分散させる場合にたいへん便利です。

注: ユーザがワイヤレス ネットワークから切断されることはありません。ロードバランシングは関連付け上でのみ発生し、システムは負荷が軽い AP を利用するようにクライアントへ働きかけます。クライアントが常駐する場合は参加を許可され、取り残されることはありません。

無線リソース管理:概要

WLAN テクノロジーの採用がめざましい広がりをみせるにつれて、導入に関する問題も増加しています。本来、802.11 の仕様は、家庭用の単一セルを主な対象として設計されていました。1 台の AP に対するチャネルと電力の設定を考えることは簡単な課題でしたが、今では広範な WLAN カバレッジがユーザの要望の 1 つになり、各 AP 設定を判断するために詳細なサイト調査が必要になりました。802.11 の帯域幅は共用できるため、ワイヤレス セグメントでさまざまなアプリケーションが実行されるようになり、お客様はキャパシティ指向の導入形態に移行しつつあります。有線ネットワークの場合は、問題が発生したところに帯域幅を追加していくのが一般的ですが、WLAN にキャパシティを追加するときには別の問題があります。WLAN にキャパシティを追加するには AP を追加する必要がありますが、AP の設定が適切でないと、干渉その他の要因により、実際にはシステムのキャパシティが低下する場合があるのです。大規模な高密度の WLAN が標準になるに従って、管理者は、運用コストを増加させる可能性があるこれらの RF 設定の問題に関する課題を継続的に抱えています。不適切な処理を行うと、WLAN が不安定になり、エンド ユーザに影響を及ぼします。

スペクトルに限りがあり、オーバーラップなしで使用できるチャネル数も制限されているうえに、RF の特性として壁や床を通り抜ける傾向があるので、どのようなサイズの WLAN を設計するにしても、非常に困難な作業になります。サイトの調査を不備なく実施した場合でも、RF は常に変化しています。ある時点では最適な AP チャネルと出力スキーマであっても、次の瞬間にはうまく機能しない可能性もあるのです。

ここで、シスコの RRM を使用します。RRM では、Cisco Unified WLAN Architecture によって既存の RF 環境が継続的に分析され、AP の出力レベルとチャネル設定が自動的に調整されるので、共通チャネルの干渉やシグナル カバレッジの問題などを緩和するために役立ちます。また、RRM によって、面倒なサイト調査の必要性が軽減され、システム キャパシティが増加し、RF のデッド ゾーンや AP の故障を補正するための自動的なセルフヒーリング機能も提供されます。

無線リソース管理:コンセプト

重要な用語

このドキュメントでは、次の用語が使用されています。読者はこれらの用語を十分に理解しておく必要があります。

RRM の鳥瞰図

RRM アルゴリズムの仕組みの詳細を学習する前に、まず RRM システムが連携して RF グループを形成する方法の基本的なワークフローと、そこで発生する RF 計算を理解する必要があります。これは、シスコの統合ソリューションがすべての RRM 機能を学習およびグループ化して計算するための手順の概要です。

  1. 単一のグループとして計算される RF を AP に設定する必要がある複数のコントローラが、同じ RF グループ名でプロビジョニングされます。RF グループ名とは、他の AP から信号を受信したときに自分と同じシステムに属するものかどうかを判断するため、各 AP で使用される ASCII 文字列です。

  2. AP は、自分自身、自分のコントローラ、および自分の RF グループ名に関する情報を共有するネイバー メッセージを定期的に送出します。次に、これらのネイバー メッセージは、同じ RF グループ名を共有している他の AP によって認証されます。

  3. ネイバー メッセージを受信し、共有されるグループ名に基づいて認証できる AP は、この情報(主にコントローラの IP アドレスとネイバー メッセージを送信している AP の情報で構成される)を接続しているコントローラに渡します。

  4. コントローラは、RF グループの一部である他のコントローラを理解できるので、この RF 情報を共有する論理グループを形成し、続いてグループのリーダーを選出します。

  5. RF グループ内の各 AP の RF 環境に関する詳細な情報を備えた一連の RRM アルゴリズムは、次に対する AP 設定の最適化を目的として RF グループのリーダーで実行されます(AP に対してローカルのコントローラで実行されるカバレッジ ホールの検出と補正アルゴリズムは例外)。

    • DCA

    • TPC

注: RRM(および RF グループ化)は、コントローラ間のモビリティ(およびモビリティ グループ化)とは別の機能です。最初のコントローラ設定ウィザードで、両方のグループ名に割り当てられた共通の ASCII 文字列を使用するのが、唯一の類似点です。共通の文字列を使用するのはセットアップ プロセスを簡略化するためであり、後から別の文字列に変更できます。

注: 複数の論理 RF グループが存在することは正常です。各コントローラ上の AP がそのコントローラと他のコントローラの結合に寄与するのは、AP が他のコントローラから他の AP をヒアリングできる場合に限られます。大規模環境および大学キャンパスでは、ドメイン全体にまたがるのではなく、建物の小規模な集合に分散された複数の RF グループが存在する場合が普通です。

これらの手順を図に示すと、次のようになります。

図 1:AP からのネイバー メッセージにより、チャネルと出力を調整するためのシステム全体にわたる RF ビューが WLC に与えられます。

rrm-new1.gif

表 1:機能分割のリファレンス

機能 実行元
RF グループ化 WLC がグループ リーダーを選出
動的チャネル割り当て(DCA) グループ リーダー
送信電力制御(TPC) グループ リーダー
カバレッジ ホールの検出と補正 WLC

RF グループ化アルゴリズム

RF グループとは、同じ RF グループ名を共有しているだけでなく、配下の AP も相互に信号を受信できるコントローラのクラスタのことです。

AP の論理コロケーションと、結果的にはコントローラの RF グループ化が、他の AP のネイバー メッセージを受信する AP によって判別されます。これらのメッセージには、送信している AP とその WLC の情報(および表 1 に記載されているその他の情報)が含まれ、ハッシュによって認証されます。

表 2:ネイバー メッセージには、受信先のコントローラが送信元の AP と接続しているコントローラを理解するために役立つ情報要素が含まれています。

フィールド名 説明
無線 ID 複数の無線を装備した AP では、ネイバー メッセージの送信に使用されている無線を識別するために、このフィールドが使用されます。
グループ ID カウンタと WLC の MAC アドレス
WLC の IP アドレス RF グループ リーダーの管理 IP アドレス
AP のチャネル ネイティブ チャネル。AP は、このチャネルでクライアントにサービスを提供します。
ネイバー メッセージのチャネル ネイバー パケットが送信されるチャネル
電力 現在使用されていません。
アンテナ パターン 現在使用されていません。

AP がネイバー メッセージ(最大出力およびサポートされている最低速度により、サービス対象のすべてのチャネルで 60 秒ごとに送信される)を受信すると、AP はそのフレームを自分の WLC に送信して埋め込まれたハッシュを確認し、その AP が同じ RF グループかどうかを判断します。解読できないネイバー メッセージ(外部の RF グループ名が使用されていることを示す)を送信する AP か、またはネイバー メッセージを一切送信しない AP が存在する場合、その AP は不正 AP と見なされます。

図 2:ネイバー メッセージは 60 秒ごとにマルチキャスト アドレス 01:0B:85:00:00:00 に送信されます。

rrm-new2.gif

すべてのコントローラが同じ RF グループ名を共有する場合は、RF グループを形成するため、WLC では 1 台の AP だけが他の WLC の AP を受信する必要があります(詳細については 図 3 を参照してください)。

図 3:AP はネイバー メッセージを送受信し、自分のコントローラに転送して RF グループを形成します。

rrm-new3.gif

ネイバー メッセージは、受信している AP とその WLC によって使用され、WLC 間の RF グループの作成方法を決定し、互いのメッセージを受信できる AP のみで構成される論理 RF サブグループも作成します。これらの論理 RF サブグループは、RF グループ リーダーによって行われた各 RRM 設定を持ちますが、RF サブグループ間ではワイヤレス接続されていないので、互いに独立しています(図 4 および 5 を参照)。

図 4:すべての AP は論理的に 1 台の WLC へ接続されていますが、AP 1、2、3 は AP 4、5、および 6 を受信できないので(逆も同様)、2 つの独立した論理 RF サブグループが形成されます。

rrm-new4.gif

図 5:同じ論理 RF サブグループ内の AP は、1 台の WLC を共有でき、それぞれは別の WLC に置くことも、混在した複数の WLC に置くこともできます。RRM はシステム全体で実行されるので、AP が相互の機能にメッセージを受信できる限り、それらのコントローラは自動的にグループ化されます。この例では、WLC A と B が同じ RF グループにあり、それらの AP は別の論理 RF サブグループにあります。

rrm-new5.gif

多数の WLC と多数の AP が存在する環境では、システム全体で 1 つの RF グループを形成するため、すべての AP が相互にメッセージを受信する必要があるわけではありません。コントローラごとに少なくとも 1 台の AP が、他の WLC の別の AP からのメッセージを受信する必要があります。そのようにして、各コントローラのネイバー AP のローカル ビューに関わりなく、多数のコントローラ(WLC)間で RF のグループ化が可能になります(図 6 を参照)。

図 6:この例では、WLC A と C に接続された AP はネイバー メッセージを相互に受信できません。WLC B は WLC A と C の両方からメッセージを受信でき、他方の情報をもう一方と共有できるので、単一の RF グループが形成されます。ネイバー メッセージを相互に受信できる AP のグループごとに、別個の論理 RF サブグループが作成されます。

rrm-new6.gif

図 7 のように、同じ RF グループ名で複数のコントローラが設定されていても、それぞれの AP がネイバー メッセージを相互に受信できないようなシナリオでは、2 つの別個の RF グループが(最上位レベルに)形成されます。

図 7:WLC は同じ RF グループ名を共有しますが、AP は互いに受信できないので、2 つの別個の RF グループが形成されます。

rrm-new7.gif

RF グループ化がコントローラ レベルで行われると、AP が受信する他の AP(およびその AP が接続されているコントローラ)の情報を自分のコントローラに報告するので、各 WLC が直接その他の WLC と通信して、システム全体のグループ化が形成されます。システム全体を表す 1 つのグループまたは RF グループ内で、AP の多くのサブセットは独立した自分の RF パラメータ セットを持ちます。中心となる WLC が 1 台で、離れた場所に個別の AP を持つ場合を考えてください。このため、各 AP は、独自の RF パラメータを他の AP とは別に持ち、各 AP は同じコントローラの RF グループ化に属しながら、(この例では)各 AP が独自の論理 RF サブグループを持ちます(図 8 を参照)。

図 8:他のネイバー メッセージを受信できないため、各 AP の RF パラメータは、他の AP から独立したセットになります。

rrm-new8.gif

各 AP は、最大 34 台のネイバー AP のリスト(無線ごとに)をコンパイルして保持し、対応するコントローラに報告します。各 WLC では、各 AP から送信されるネイバー メッセージに基づいて、AP の無線ごとに 24 台のネイバー AP のリストが保持されます。コントローラ レベルでは、この AP ごと、無線ごとに最大 34 台 のネイバー リストがプルーニングされ、信号が最も弱い 10 台の AP がドロップされます。次に、WLC から RF グループ リーダー(RRM 設定の意思決定を行うように RF グループによって選出された WLC)に AP のネイバー リストが転送されます。

ここで、RF グループ化は、無線の種類ごとに動作する点に注意することが非常に重要です。グループ化のアルゴリズムは、802.11a と 802.11b/g の無線ごとに別個に実行されます。つまり、実行は AP ごと、無線ごとに行われるので、ネイバー リストへのデータの設定は各 AP の無線が行うことになります。フラッピングを制限するため、AP は頻繁にこのリストから追加およびプルーニングされ、WLC は -80 dBm 以上で受信されたネイバーをリストに追加し、信号が -85 dBm を下回った場合に限り削除します。

注: Wireless LAN Controller ソフトウェア リリース 4.2.99.0 以降では、RRM は、1 つの RF グループで最大 20 台のコントローラと 1000 台のアクセス ポイントをサポートします。たとえば、Cisco WiSM コントローラでは最大 150 台のアクセス ポイントをサポートするので、1 つの RF グループに最大 6 台の WiSM コントローラを配置できます(150 台のアクセス ポイント X 6 台のコントローラ = 900 台のアクセス ポイントなので、1000 未満です)。同様に、4404 コントローラでは、最大 100 台のアクセス ポイントをサポートするので、1 つの RF グループに最大 10 台の 4404 コントローラを配置できます(100 X 10 = 1000)。2100 シリーズ ベースのコントローラは、最大 25 個のアクセス ポイントをサポートするので、1 つの RF グループに最大 20 台のコントローラを配置できます。この 1000 台の制限は、コントローラに関連付けられる実際の AP の数ではなく、特定のコントローラ モデルがサポートできる AP の最大数に基づいて計算されます。たとえば、8 台の WiSM コントローラ(WiSM X 4)があり、それぞれに 70 台の AP がある場合、実際の AP の数は 560 です。ただし、アルゴリズムでは、8 * 15 0= 1200(150 は各 WiSM コントローラによってサポートされる AP の最大数)として計算されます。そのため、コントローラは 2 つのグループに分割され、 6 台のコントローラと、2 台のコントローラのグループに分けられます。

RF グループ リーダーとして機能するコントローラは、システム全体で DCA アルゴリズムと TPC アルゴリズムの両方を実行するので、ネイバー メッセージが他のコントローラ上の AP によって受信されることが予想される場合は、コントローラに RF グループ名を設定する必要があります。(別のコントローラ上の)AP が、ネイバー メッセージを -80 dBm 以上で受信できないほど地理的に離れている場合は、コントローラを RF グループに設定するのは現実的ではありません。

RF グループ化アルゴリズムの上限に達すると、グループ リーダー のコントローラは新しいコントローラまたは AP が既存のグループに追加されたり、チャネルまたは電力の計算に加えられたりすることを許可しません。このような状況は、新しい論理 RF サブグループと新しいメンバがこの新しい論理グループに追加され、同じグループ名に設定されたとシステムで判断されます。環境が動的な場合は、RF の変動によりネイバーの認識が定期的な間隔で変更されるので、グループ メンバの変更やそれに続くグループ リーダーの選出が発生する可能性が増大します。

グループ リーダー

RF グループ リーダーは、RF グループ内で選出されたコントローラで、論理 RF グループごとに AP の RF データを分析し、AP の電力レベルとチャネルの設定を行います。カバレッジ ホールの検出と補正はクライアントの SNR に基づくので、 各ローカル コントローラでは RRM 機能のみが実行されます。

各コントローラは、各ネイバー メッセージ内のグループ ID 情報要素に基づいて、グループ リーダーの最高優先順位がどの WLC に設定されているかを判断します。各ネイバー メッセージでアドバタイズされるグループ ID 情報要素は、カウンタ値(各コントローラは 16 ビットのカウンタを持ち、カウンタは 0 から始まって RF グループからの脱退や WLC の再起動などのイベントで増加)とコントローラの MAC アドレスで構成されます。各 WLC は、まずこのカウンタ値に基づいてネイバー WLC からのグループ ID 値の優先度を決定します。さらにカウンタ値が同じ場合は、MAC アドレスに基づいて決定します。各 WLC は、最高のグループ ID 値が設定された 1 台のコントローラ(ネイバー WLC または自分自身)を選択します。その後、各コントローラは、どのコントローラのグループ ID が最高かを判断するために相互に協議します。WLC は、次に RF グループ リーダーを選出します。

RF グループ リーダーがオフラインになると、グループ全体が解散され、既存の RF グループ メンバはグループ リーダーの選出プロセスに戻って新しいリーダーが選出されます。

RF グループ リーダーは、10 分ごとにグループ内の各 WLC に対し、AP の統計情報と受信されたすべてのネイバー メッセージ情報をポーリングします。グループ リーダーはこの情報に基づいてシステム全体の RF 環境を把握し、DCA アルゴリズムと TPC アルゴリズムを使用して AP のチャネルと出力の設定を継続的に調整できるようになります。グループ リーダーはこれらのアルゴリズムを 10 分ごとに実行しますが、カバレッジ ホールの検出と補正アルゴリズムの場合と同様に、変更が実施されるのは必要と判断される場合だけです。

動的チャネル割り当てアルゴリズム

RF グループ リーダーによって実行される DCA アルゴリズムは、すべての RF グループの AP に最適な AP チャネルの設定を決定するため、RF グループごとに適用されます(このドキュメントで論理 RF サブグループと呼ばれる、ネイバー メッセージを相互に受信できる AP の各セットでは、他の論理 RF サブグループとは信号がオーバーラップしないため、独立したチャネル設定が行われます)。DCA プロセスでは、チャネルに必要な変更を決定する際に、リーダーは AP に固有ないくつかのメトリックを考慮します。次のようなメトリックが対象になります。

次に、グループ リーダーがこれらの値を使用して、最もパフォーマンスが悪い AP のパフォーマンスが、別のチャネル スキーマを使用すると 5 dB(SNR)以上向上するかどうかを判断します。チャネルの変更がローカルに行われるように、動作中のチャネルの AP には重み付けが行われます。これにより変更が制限されるので、1 つの変更を契機としてシステム全体のチャネルが変更されるようなドミノ現象が防止されます。また、変更が必要な場合に、使用率が高いネイバー AP よりも使用率の低い AP のチャネルが変更される可能性が高くなるように、使用率(各 AP の負荷測定レポートによって算出)に基づいて AP に優先度が設定されます。

注: AP のチャネル変更時には、常にクライアントが短時間切断されます。クライアントは自身のローミング動作に基づいて、同じ AP に(新しいチャネルで)再度接続するか、近くの AP にローミングすることができます。互換性のあるクライアントがあれば、高速セキュア ローミング(CCKM と PKC の両方で提供)により、この短時間の中断を短縮できます。

注: AP は(新品の状態から)初めて起動されたとき、それ自体がサポートしている周波数帯の中の最初の非オーバーラップ チャネル(11b/g ではチャネル 1、11a ではチャネル 36)を送信に使用します。AP の電源が再投入されると、(AP のメモリに保存されている)前回のチャネル設定が使用されます。その後、必要に応じて DCA による調整が実行されます。

送信電力制御アルゴリズム

TPC アルゴリズムは、デフォルトで固定された 10 分間隔で実行されます。アルゴリズムは RF グループ リーダーによって使用され、AP の RF の近接度を判断し、各周波数帯の送信電力を低く調整してセルの過度なオーバーラップと共通チャネルの干渉を制限します。

注: TPC アルゴリズムでは、電力レベルを低下させる調整だけを実行できます。送信電力を増大させる調整はカバレッジ ホールの検出と補正アルゴリズムの一部です。これについては、次のセクションで説明します。

各 AP から、すべてのネイバー AP を RSSI 順に示すリストが報告されます。AP に 3 台以上のネイバー AP がある場合は(TPC が機能するには最低で 4 台の AP が必要)、ヒアリング結果のうち 3 番目にラウドネスが高いネイバー AP が -70 dBm(またはデフォルト値の -70 dBm 以外の任意の設定値)以下の信号レベルでヒアリングされ、TCP ヒステリシス条件が満たされるようにするため、RF グループ リーダーが周波数帯別、AP 別に TPC アルゴリズムを適用して、AP の送信電力レベルを下方調整します。そのため、TCP は次の段階を経て送信電力の変更が必要かどうかを判断します。

  1. 3 番目のネイバーがあるかどうか、または 3 番目のネイバーが送信電力制御のしきい値を超えているかどうかを判断します。

  2. 次の式を使用して送信電力を決定します: 指定された AP の Tx_max +(Tx 電力制御しきい値 – 上記しきい値を超えた 3 番目に高いネイバーの RSSI)

  3. ステップ 2 の計算を現在の Tx 電力レベルと比較し、TCP ヒステリシスを超過しているかどうか検証します。

    • Tx 電力を低下させる必要がある場合:最低でも 6 dBm の TCP ヒステリシスを満たす必要があります。または

    • Tx 電力を増大させる必要がある場合:3 dBm の TPC ヒステリシスを満たす必要があります。

TPC アルゴリズムで使用されるロジックの例については、 「送信電力制御アルゴリズムのワークフローの例」のセクションを参照してください。

注: どの AP も、(新品の状態から)初めて起動されたとき、それ自体がサポートしている最大送信電力レベルを送信に使用します。AP の電源が再投入された場合は、前回の電力設定が使用されます その後、必要に応じて TPC による調整が実行されます。サポートされている AP の送信電力レベルの詳細については、表 4 を参照してください。

注: TPC アルゴリズムによって Tx 電力が増大するシナリオには、主に次の 2 つがあります。

カバレッジ ホールの検出と補正アルゴリズム

カバレッジ ホールの検出と補正アルゴリズムの目的は、最初にクライアントの信号レベルの品質に基づいてカバレッジ ホールを判断し、クライアントが接続される AP の送信電力を増大させることです。このアルゴリズムにはクライアントの統計情報が関係しているので、各コントローラで独立してこのアルゴリズムが実行されます。システム全体に対して RF グループ リーダーで実行されることはありません。

このアルゴリズムでは、クライアントの SNR レベルが特定の SNR しきい値を下回ったときに、カバレッジ ホールが存在するかどうかが判断されます。この SNR しきい値は、個々の AP に対して考慮され、主に各 AP の送信電力レベルに基づいて設定されます。AP の電力レベルが高くなると、クライアント信号の強度と比較してノイズの許容量が増え、その結果 SNR 値の許容量が低くなります。

この SNR しきい値は、AP の送信電力とコントローラのカバレッジ プロファイル値という 2 つの値に基づいて変化します。しきい値は、各 AP の送信電力(dBm 単位)から定数値 17 dBm を減算し、さらにユーザが設定可能なカバレッジ プロファイル値を減算した値として定義されています(20 ページに記載されているように、デフォルトではカバレッジ プロファイル値は 12 dB に設定されます)。クライアントの SNR しきい値は、次の式で計算される絶対値(正数)です。

カバレッジ ホール SNR しきい値の式

クライアントの SNR 遮断値(|dB|)= [AP 送信電力(dBm)– 定数(17 dBm)– カバレッジ プロファイル(dB)]

設定された数のクライアントの平均 SNR が 60 秒間以上、この SNR しきい値を下回ると、SNR 違反を軽減してカバレッジ ホールを補正するために、値を下回っているクライアントの AP の送信電力が増大されます。各コントローラでは、自分の AP の無線ごとにカバレッジ ホールの検出と補正アルゴリズムが 3 分間隔で実行されます(デフォルト値の 180 秒は変更可能です)。変化が激しい環境では、次に TPC アルゴリズムが実行されたときに、出力が低下する場合があることに注意してください。

「スティッキ クライアント」の電力増大に関する考慮事項

レガシー クライアント ドライバでローミングを実装すると、RSSI、スループット、クライアントの全体的な環境の面で最適な AP がほかに存在する場合でも、クライアントが既存の AP に「スティッキング」することがあります。その結果、このような動作がワイヤレス ネットワークに組織的な影響を与えてクライアントの SNR が不適切であると認識され(ローミングに失敗するため)、最終的にカバレッジ ホールが検出される場合があります。このような状況では、アルゴリズムによって AP の送信電力が増大し(動作が不適切なクライアントのカバレッジを提供するため)、送信電力のレベル望ましくない(通常よりも高い)値になることがあります。

ローミング ロジックが本質的に向上するまで、[Client Min Exception Level] を高くして(デフォルトは 3)許容可能なクライアントの SNR 値も増大させると(デフォルトの 12 dB を 3 dB に変更すると改善が見られる)、このような状況を軽減させられます。コード バージョン 4.1.185.0 以降を使用すれば、大部分の環境において、デフォルト値で最適な結果を得ることが可能です。

注: これらの推奨事項は内部テストに基づくものであり、各導入状況によって異なりますが、変更に関するロジックは適用できます。

トリガーに使用されるロジックの例については、「カバレッジ ホールの検出と補正アルゴリズムの例」のセクションを参照してください。

注: カバレッジ ホールの検出と補正アルゴリズムには、AP の故障によるカバレッジの消滅を検出し、必要に応じて近くの AP の電力を増大させる機能もあります。この機能により、ネットワークのサービス停止を防止できます。

無線リソース管理:設定パラメータ

RRM とそのアルゴリズムについて理解したので、次のステップでは、必要なパラメータを解釈して変更する方法を学習します。このセクションでは、RRM の設定操作の詳細について説明し、基本的なレポート設定の概要も示します。

RRM を設定する最初のステップは、各 WLC を同じ RF グループ名で構成することです。このためには、コントローラの Web インターフェイスで、[Controller] --> [General] を選択し、共通のグループ名を入力します。同じ RF グループ内の WLC 間が IP 接続されていることも必要です。

図 9:RF グループはユーザが指定した [RF-Network Name](このドキュメントでは RF グループ名とも呼ばれる)に基づいて形成されます。この文字列は、システム全体の RRM の運用に参加する必要があるすべての WLC で共有する必要があります。

rrm-new9.gif

次のセクションにおけるすべての設定の説明と例は、WLC グラフィック インターフェイスから実行されます。WLC の GUI で、[Wireless] メイン ページに移動し、左側にある WLAN 標準の選択肢から [RRM] オプションを選択します。次に、ツリーで [Auto RF] を 選択します。後続のセクションでは、結果のページ [Wireless | 802.11a or 802.11b/g ? RRM | Auto RF…] を参照します。

WLC GUI からの RF グループ化設定

図 10:RF グループのステータス、更新、およびメンバーシップの詳細が、[Auto RF] ページの上部に強調表示されます。

rrm-new10.gif

WLC GUI からの RF チャネル割り当て設定

図 11:動的チャネル割り当てアルゴリズムの設定

rrm-new11.gif

WLC GUI からの Tx 電力レベル割り当ての設定

図 12: 送信電力制御アルゴリズムの設定

rrm-new12.gif

プロファイルしきい値:WLC GUI

Wireless Control System(WCS)で RRM しきい値と呼ばれているプロファイルしきい値は、主にアラーム目的で使用されます。ネットワークの問題の診断を容易にするために、これらの値を超過すると WCS(または任意の SNMP ベースの管理システム)にトラップが送信されます。これらの値は、アラーム目的でのみ使用され、RRM アルゴリズムの機能とはまったく関係がありません。

図 13:デフォルトのアラーム プロファイルしきい値

rrm-new13.gif

[Noise/Interference/Rogue Monitoring Channels]

シスコの AP では、クライアント データ サービスの提供と RRM(および IDS/IPS)機能の定期的なスキャンが行われています。AP にスキャンを許可するチャネルは設定で変更可能です。

[Channel List]:AP が定期的にモニタするチャネル範囲を指定できます。

[All Channels] を選択するなど、より多くのチャネルをスキャンすると、データ クライアントのサービスに費やす合計時間が(スキャン プロセスに含まれるチャネルが少ない場合と比較して)わずかに減少します。ただし、([DCA Channels] 設定と比較して)より多くのチャネルの情報を蓄積することが可能です。IDS/IPS で [All Channels] を選択する必要がない場合は、デフォルト設定の [Country Channels] を使用する必要があります。また、しきい値プロファイルのアラームおよび RRM アルゴリズムの検出と補正のいずれでも、他のチャネルの詳細情報が必要ない場合もあります。この場合には、[DCA Channels] を選択するのが適切です。

図:デフォルトでは [Country Channels] が選択されていますが、RRM のモニタリング チャネルは [All Channels] または [DCA Channels] に設定することもできます。

rrm-new14.gif

[Monitor Intervals (60 to 3600 secs)]

Cisco LWAPP ベースの AP はすべて、ユーザにデータを配信しながら定期的にチャネルを停止させて RRM 測定を実行します(IDS/IPS やロケーション タスクなど、その他の機能も実行します)。このオフチャネル スキャンはユーザに対して透過的に実行され、パフォーマンスは最大でも 1.5 % しか制限されません。また、最後の 100 ms の音声キューにトラフィックが存在する状態で次の間隔までスキャンを遅らせる、組み込みのインテリジェンス機能を備えています。

モニタ間隔を調整すると、AP が RRM 測定を実行する頻度が変更されます。RF グループ情報を制御する最も重要なタイマーは、[Signal Measurement](4.1.185.0 以降では [Neighbor Packet Frequency])です。ここに指定された値は、ネイバー メッセージが送信される頻度に直接関係しています。ただし EU およびその他の 802.11h のドメインは例外です。これらのドメインでは [Noise Measurement] の間隔も考慮に入れられます。

規制区域にかかわらず、スキャン処理全体では(無線ごと、チャネルごとに)約 50 ms かかり、180 秒のデフォルト間隔で実行されます。この間隔は、[Coverage Measurement](4.1.185.0 以降では [Channel Scan Duration])の値で変更可能です。各チャネルの受信に費やす時間は、設定では変更できない 50 ms というスキャン時間(およびチャネルの切り替えに必要な 10 ms)とスキャンするチャネルの数の関数として求めることができます。たとえば、米国では、クライアントにデータを配信する 1 つのチャネルを含むすべての 11 802.11b/g チャネルは、180 秒の間隔内で 50 ms ずつスキャンされます。つまり、米国の 802.11b/g ではスキャンされる各チャネルに対して、16 秒ごとに 50 ms がスキャンされる各チャネルの受信に費やされます(180/11 = およそ 16 秒)。

図 15:RRM モニタリング間隔とそのデフォルト値

rrm-new15.gif

[Noise Measurement]、[Load Measurement]、[Signal Measurement]、および [Coverage Measurement] の間隔は、RRM アルゴリズムに入力する情報の密度を変更するために調整できます。これらのデフォルト値は、Cisco TAC による指示がない限り変更しないでください。

注: これらのスキャン値が変更され、RRM アルゴリズムが実行される間隔を超えた場合(DCA と TPC の両方で 600 秒、カバレッジ ホールの検出と補正で 180 秒)、RRM アルゴリズムは引き続き実行されますが、情報が「新鮮ではない」可能性があります。

注: リンク集約(LAG)を使用して複数のギガビット イーサネット インターフェイスを集約するように WLC が設定されている場合は、ユーザ アイドル タイムアウト機能を起動するために [Coverage Measurement] の間隔が使用されます。そのため、LAG が有効になっている場合、[Coverage Measurement] に指定された間隔と同じ頻度でユーザ アイドル タイムアウトが実行されます。リリース 4.1 では、アイドル タイムアウト機能はコントローラからアクセス ポイントに移行されたため、これは、バージョン 4.1 よりも前のファームウェアを実行している WLC にのみ適用されます。

工場出荷時のデフォルト

RRM 値をデフォルト設定にリセットするには、 ページの下部にある [Set to Factory Default] ボタンをリセットします。

無線リソース管理:トラブルシューティング

必要な SNMP トラップを有効にすると、RRM による変更を簡単にモニタできます。これらの設定は、WLC GUI の [Management] --> [SNMP] --> [Trap Controls] からアクセスできます。このセクションで説明する、その他の関連する SNMP トラップ設定は、[Management] --> [SNMP] ページにあり、[Trap Receivers]、[Controls]、[Logs] のリンクが用意されています。

図 16:[Auto RF Update Traps] の [Channel Update] と [Tx Power Update] は、デフォルトで有効になっています。

rrm-new16.gif

動的チャネル割り当ての確認

RF グループ リーダー(および DCA アルゴリズム)がチャネル スキーマを提案、適用、最適化した後は、[Trap Logs] サブメニューから変更を簡単にモニタできます。このようなトラップの例は、次のように表示されます。

図 17:チャネル変更ログのエントリには、無線の MAC アドレスと新しい動作チャネルの情報が含まれています。

rrm-new17.gif

DCA 変更の間に AP がチャネル設定を維持した期間の詳細な統計情報を表示するため、この CLI 専用コマンドは、コントローラごとにチャネルの滞留時間の最小値、平均値、最大値を提供します。

(Cisco Controller) >show advanced 802.11b channel 

Automatic Channel Assignment
  Channel Assignment Mode........................ AUTO
  Channel Update Interval........................ 600 seconds
  Anchor time (Hour of the day).................. 0 
  Channel Update Contribution.................... SNI.
  Channel Assignment Leader...................... 00:16:46:4b:33:40
  Last Run....................................... 114 seconds ago

  DCA Senstivity Level: ....................... MEDIUM (15 dB)
  Channel Energy Levels 
    Minimum...................................... unknown
    Average...................................... unknown
    Maximum...................................... unknown
  Channel Dwell Times 
    Minimum...................................... 0 days, 09 h 25 m 19 s
    Average...................................... 0 days, 10 h 51 m 58 s
    Maximum...................................... 0 days, 12 h 18 m 37 s
  Auto-RF Allowed Channel List................... 1,6,11
  Auto-RF Unused Channel List.................... 2,3,4,5,7,8,9,10

送信電力制御の変更の確認

コントローラの CLI で次のコマンドを使用すれば、前述の tx-power-control-thresh を含む現在の TPC アルゴリズムの設定を確認できます(次に示すのは 802.11b の例です)。

(Cisco Controller) >show advanced 802.11b txpower 

Automatic Transmit Power Assignment
  Transmit Power Assignment Mode................. AUTO
  Transmit Power Update Interval................. 600 seconds
  Transmit Power Threshold....................... -70 dBm
  Transmit Power Neighbor Count.................. 3 APs
  Transmit Power Update Contribution............. SNI.
  Transmit Power Assignment Leader............... 00:16:46:4b:33:40
  Last Run....................................... 494 seconds ago

このドキュメントで前述したように、高密度の導入では、共通チャネルの干渉が増えることによってセルのオーバーラップが増加し、衝突とフレーム リレー レートが高くなってクライアントのスループット レベルが実質的に減少することから、新しく導入された tx-power-control-thresh コマンドを使用する必要があります。このような一般的ではない変則的なシナリオでは、(信号の伝搬の特性が一定のままであると仮定した場合)クライアントの受信方法と比較して AP ではより良好に相互の信号を受信できます。

カバレッジ エリアを縮小して、共通チャネルの干渉とノイズ フロアを減らすと、クライアントの動作効率を向上させることができます。ただし、このコマンドは、システムの AP 上の高い再試行率と衝突カウント、クライアントのス低いループット レベル、および全体的に向上した共通チャネルの干渉などの症状を慎重に分析して実行する必要があります(不正 AP は DCA で考慮されます)。内部テストにより、このような場合のトラブルシューティングでは、3 番目のネイバーが認識する RSSI を -70 dBm に変更すると、トラブルシューティングを開始できる妥当な値になることが明らかになっています。

チャネルの変更が発生したときにトラップが生成されるのと同様に、TPC による変更でもトラップが生成され、また、新しい変更に関連した必要な情報はすべてこれらのトラップに明確に示されます。サンプル トラップは次のように表示されます。

図 18:Tx 電力トラップのログに、指定された無線で動作している新しい出力レベルが示されています。

rrm-new18.gif

送信電力制御アルゴリズムのワークフローの例

このセクションの例では、TPC アルゴリズムで定義されている 3 つのステップと条件に基づいて、AP の 送信電力を変更する必要があるかどうかを判断する計算方法について説明します。この例では、次の値を想定しています。

これらを TPC アルゴリズムの 3 つの段階に当てはめると、次のようになります。

カバレッジ ホールの検出と補正アルゴリズムのワークフローの例

カバレッジ ホールの検出と補正アルゴリズムで使用される意思決定プロセスを示すために、次の例では、最初に 1 台のクライアントで受信される SNR レベルが不適切で、システムの変更が必要かどうかと、電力がどのように変化するのかを決定する方法について説明します。

カバレッジ ホール SNR しきい値の式を思い出してください。

クライアントの SNR 遮断値(|dB|)= [AP 送信電力(dBm)– 定数(17 dBm)– カバレッジ プロファイル(dB)]

フロアのカバレッジが悪いエリアで信号の問題が発生しているクライアントの状況を考慮します。そのようなシナリオでは、次のことが当てはまる可能性があります。

クライアントの AP の電力を増大させる必要があるかどうかを決定するために、これらの数字をカバレッジ ホールのしきい値の式に当てはめると、結果は次のようになります。

802.11b/g 周波数帯でサポートされる電力出力レベルについては、表 4 に記載されています。802.11a の電力レベル出力を決定するために、次の CLI コマンドを実行します。

show ap config 802.11a <ap name>

表 4:1000 シリーズの AP では、最大 5 までの出力レベルがサポートされており、1100 シリーズと 1200 シリーズの AP では、最大 8 までの出力レベルが 802.11b/g の周波数帯でサポートされています。

サポートされている出力レベル Tx 電力(dBm) Tx 電力(mW)
1 20 100
2 17 50
3 14 25
4 11 12.5
5 8 6.5
6 5 3.2
7 2 1.6
8 -1 0.8

debug コマンドと show コマンド

RRM の動作をさらにトラブルシューティングして確認するため、airewave-director debug コマンドを使用できます。debug airewave-director コマンドの最上位のコマンドライン階層は、次のように表示されます。

(Cisco Controller) >debug airewave-director ?

all       Configures debug of all Airewave Director logs
channel   Configures debug of Airewave Director channel assignment protocol
error     Configures debug of Airewave Director error logs
detail    Configures debug of Airewave Director detail logs
group     Configures debug of Airewave Director grouping protocol
manager   Configures debug of Airewave Director manager
message   Configures debug of Airewave Director messages
packet    Configures debug of Airewave Director packets
power     Configures debug of Airewave Director power assignment protocol
radar     Configures debug of Airewave Director radar detection/avoidance protocol
rf-change Configures logging of Airewave Director rf changes
profile   Configures logging of Airewave Director profile events

一部の重要なコマンドについては、次のサブセクションで説明します。

debug airewave-director all

debug airewave-director all コマンドを使用すると、RRM アルゴリズムが実行されるタイミング、使用するデータ、および実行される変更(存在する場合)を特定できるすべての RRM デバッグを呼び出せます。

この例では、コマンドは RF グループ リーダー上で実行され、DCA アルゴリズムの内部の動作を把握し、次の 4 つのステップに分割できます(debug airewave-director all コマンドの出力は動的チャネル割り当てプロセスだけを示すように抜粋されています)。

  1. アルゴリズムで実行される現在の統計情報を収集して記録します。

    Airewave Director: Checking quality of current assignment for 802.11a
    Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, 
    after -128.00)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87)
    ( 48, -81.87)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90)
    ( 64, -81.69)
    Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87)
    (161, -86.91)
  2. 新しいチャネル スキーマを提案して、推奨値を保存します。

    Airewave Director: Searching for better assignment for 802.11a
    Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, 
    after -128.00)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87)
    ( 48, -81.87)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90)
    ( 64, -81.69)
    Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87)
    (161, -86.91)
  3. 提案値と現在の値を比較します。

    Airewave Director: Comparing old and new assignment for 802.11a
    Airewave Director: 802.11a AP 00:15:C7:A9:3D:F0(1) ch 161 (before -86.91, 
    after -86.91)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 36, -76.00)( 40, -81.75)( 44, -81.87)
    ( 48, -81.87)
    Airewave Director: 00:15:C7:A9:3D:F0(1)( 52, -81.87)( 56, -81.85)( 60, -79.90)
    ( 64, -81.69)
    Airewave Director: 00:15:C7:A9:3D:F0(1)(149, -81.91)(153, -81.87)(157, -81.87)
    (161, -86.91)
  4. 必要に応じて、新しいチャネル スキーマが有効になるように変更を適用します。

    Airewave Director: Before -- 802.11a energy worst -86.91, average -86.91,
    best -86.91
    Airewave Director: After -- 802.11a energy worst -86.91, average -86.91, 
    best -86.91

debug airewave-director detail(説明)

このコマンドを使用すると、そのコントローラの RRM の動作の詳細な状況をリアルタイムで表示できます。次に、関連するメッセージについて説明します。

debug airewave-director power

debug airewave-director power コマンドは、カバレッジ ホールの補正をモニタする AP に対してローカルの WLC で実行する必要があります。コマンドによる出力は、この例の目的に合わせて抜粋されています。

802.11a 用に実行されたカバレッジ ホール アルゴリズムの監視

Airewave Director: Coverage Hole Check on 
  802.11a AP 00:0B:85:54:D8:10(0)
Airewave Director: Found 0 failed clients on 
802.11a AP 00:0B:85:54:D8:10(0)
Airewave Director: Found 0 clients close to coverage edge on 
802.11a AP 00:0B:85:54:D8:10(0)
Airewave Director: Last power increase 549 seconds ago on 
802.11a AP 00:0B:85:54:D8:10(0)
Airewave Director: Set raw transmit power on 
802.11a AP 00:0B:85:54:D8:10(0) 
to (  20 dBm, level  1)

802.11b/g 用に実行されたカバレッジ ホール アルゴリズムの監視

Airewave Director: Coverage Hole Check on 802.11bg AP 00:13:5F:FA:2E:00(0)
Airewave Director: Found 0 failed clients on 802.11bg AP 00:13:5F:FA:2E:00(0)
Airewave Director: Found 0 clients close to coverage edge on 802.11bg 
AP 00:13:5F:FA:2E:00(0)
Airewave Director: Last power increase 183 seconds ago on 802.11bg 
AP 00:13:5F:FA:2E:00(0)
Airewave Director: Set raw transmit power on 802.11bg AP 00:13:5F:FA:2E:00(0)
to (  20 dBm, level  1)
Airewave Director: Set adjusted transmit power on 
802.11bg AP 00:13:5F:FA:2E:00(0) to (  20 dBm, level  1)

show ap auto-rf

他の AP に隣接する AP を把握するには、コントローラ CLI からコマンド show ap auto-rf を使用します。このコマンドの出力に、Nearby RAD というフィールドがあります。このフィールドは、付近の AP の MAC アドレスと、AP 間の信号強度(RSSI)を dBm 単位で提供します。

コマンドの構文は次のとおりです。

show ap auto-rf {802.11a | 802.11b} Cisco_AP 

次に例を示します。

> show ap auto-rf 802.11a AP1

Number Of Slots.................................. 2
Rad Name......................................... AP03
MAC Address...................................... 00:0b:85:01:18:b7
  Radio Type..................................... RADIO_TYPE_80211a
  Noise Information
    Noise Profile................................ PASSED
    Channel 36...................................  -88 dBm
    Channel 40...................................  -86 dBm
    Channel 44...................................  -87 dBm
    Channel 48...................................  -85 dBm
    Channel 52...................................  -84 dBm
    Channel 56...................................  -83 dBm
    Channel 60...................................  -84 dBm
    Channel 64...................................  -85 dBm
  Interference Information
    Interference Profile......................... PASSED
    Channel 36...................................  -66 dBm @  1% busy
    Channel 40................................... -128 dBm @  0% busy
    Channel 44................................... -128 dBm @  0% busy
    Channel 48................................... -128 dBm @  0% busy
    Channel 52................................... -128 dBm @  0% busy
    Channel 56...................................  -73 dBm @  1% busy
    Channel 60...................................  -55 dBm @  1% busy
    Channel 64...................................  -69 dBm @  1% busy
  Load Information
    Load Profile................................. PASSED
    Receive Utilization.......................... 0%
    Transmit Utilization......................... 0%
    Channel Utilization.......................... 1%
    Attached Clients............................. 1 clients
  Coverage Information
    Coverage Profile............................. PASSED
    Failed Clients............................... 0 clients
  Client Signal Strengths
    RSSI -100 dBm................................ 0 clients
    RSSI  -92 dBm................................ 0 clients
    RSSI  -84 dBm................................ 0 clients
    RSSI  -76 dBm................................ 0 clients
    RSSI  -68 dBm................................ 0 clients
    RSSI  -60 dBm................................ 0 clients
    RSSI  -52 dBm................................ 0 clients
  Client Signal To Noise Ratios
    SNR    0 dBm................................. 0 clients
    SNR    5 dBm................................. 0 clients
    SNR   10 dBm................................. 0 clients
    SNR   15 dBm................................. 0 clients
    SNR   20 dBm................................. 0 clients
    SNR   25 dBm................................. 0 clients
    SNR   30 dBm................................. 0 clients
    SNR   35 dBm................................. 0 clients
    SNR   40 dBm................................. 0 clients
    SNR   45 dBm................................. 0 clients
  Nearby RADs
    RAD 00:0b:85:01:05:08 slot 0.................  -46 dBm on 10.1.30.170
    RAD 00:0b:85:01:12:65 slot 0.................  -24 dBm on 10.1.30.170
  Channel Assignment Information
    Current Channel Average Energy...............  -86 dBm 
    Previous Channel Average Energy..............  -75 dBm 
    Channel Change Count.........................  109 
    Last Channel Change Time..................... Wed Sep 29 12:53e:34 2004
    Recommended Best Channel..................... 44 
  RF Parameter Recommendations
    Power Level.................................. 1
    RTS/CTS Threshold............................ 2347
    Fragmentation Threshold...................... 2346
    Antenna Pattern.............................. 0

付録 A:WLC リリース 4.1.185.0 – RRM の機能強化

RF グループ化アルゴリズム

ネイバー リストの「プルーニング タイマー」

WLC ソフトウェア 4.1 の最初のメンテナンス リリースの前では、最後に受信したときから最大 20 分間、AP はネイバー リストに他の AP を維持ました。このとき、RF 環境が一時的に変更される場合に、有効なネイバーが AP のネイバー リストからプルーニングされることがありました。このような RF 環境に対する一時的な変更に対応するため、AP のネイバー リストのプルーニング タイマー(ネイバー メッセージを受信してからの時間)は 60 分間に延長されています。

動的チャネル割り当てアルゴリズム

チャネル割り当ての方法

Automatic モードにおける 4.1.185.0 より前のデフォルト動作は、10 分ごとに DCA チャネル計画を計算し、必要に応じてそれを適用するものでした。変化が激しい環境では、1 日のチャネル変更が非常に多く発生する可能性があります。そのため、DCA の頻度を微調整する必要が生じました。4.1.185.0 以降では、頻度を微調整する必要がある場合に、次の設定を使用できます。

Tx 電力制御アルゴリズム

デフォルトの送信電力制御しきい値

送信電力制御のしきい値は、常に AP がネイバーを受信する方法を決定し、AP の送信電力を決定するためにも使用されます。WLC ソフトウェア 4.1 メンテナンス リリースで RRM アルゴリズムに加えられた全体的な機能強化の結果、デフォルト値の -65 dBm も見直され、 ほとんどの導入で電力が強すぎると思われたデフォルト値は -70 dBm に変更されました。このため、特別な設定を行わなくても、ほとんどの屋外環境で最適なセルのオーバーラップを利用できるようになりました。ただし、4.1.171.0 以前のリリースからアップグレードされた場合、コントローラはあらかじめ設定された値を維持するので、このデフォルトは新しいインストールにのみ影響を与えます。

カバレッジ ホール アルゴリズム

最低クライアント数

リリース 4.1.185.0 まで、カバレッジ ホールが検出されて緩和メカニズムが開始されるには、1 台 のクライアントだけが条件(設定された値やデフォルト値 16 dB(802.11a)または 12 dB(802.11b/g)よりも SNR しきい値が悪い)を満たす必要がありました。現在、[Client Minimum Exception Level] フィールドが直接 CHA に結び付けられて(新しく作成された CHA のサブセクションに適切に配置される)、設定値により、何台のクライアントが SNR しきい値を満たしたら(AP の送信電力が増大する)緩和メカニズムが開始されるのかを定義できるようになっています。大部分の導入ではデフォルト値(802.11b/g では 12 dB、802.11a では 16 dB、[Client Minimum Exception Level] は 3)から開始し、必要な場合に限り調整してください。

図 19:プロファイルしきい値から独立した [Coverage Hole Algorithm] サブセクション。大部分のインストールでは、デフォルト値で最適な結果を得ることができます。

rrm-new19.gif

Tx-Power-Up 制御

カバレッジ ホールの緩和を開始するために必要な、違反しているクライアントの数に加えて、アルゴリズムも強化され、インテリジェントな方法で AP の送信電力を増大が考慮されるようになりました。送信電力を最大値まで上げることは、十分な緩和とオーバーラップを確実に実施する安全策ですが、ローミングが不十分なクライアントが導入されるという悪影響も及ぼします。クライアントは別の AP(一般には最も強い信号を提供する AP)に関連付けを変更するのではなく、AP 遠く離れている同じ古い AP への関連付けを維持します。結果として、このクライアントは関連付けを持つ AP から適切な信号を受け取れなくなります。ローミングが不十分なために障害が発生したクライアントは、誤検出の可能性があるカバレッジ ホール シナリオの例です。ローミングが不十分であっても、本当にカバレッジホールが存在することを示しているわけではありません。カバレッジ ホールの可能性は、次のような場合に現実となります。

このようなシナリオを避けて軽減させるため、AP 送信電力は 1 度に 1 レベルだけ上昇し(1 反復あたり)、ネットワークの電力を増大させることなく、本当のカバレッジ ホールが電力増大の利点を得られるようになります(結果として共通チャネルの干渉を回避します)。

SNMP トラップの機能強化

チャネル変更時に生成される SNMP トラップの機能が強化され、新しいチャネル計画を実装するための理由を説明する詳細な情報が提供されるようになりました。次の図から明らかになるように、機能強化されたトラップには DCA アルゴリズムで使用された前後のメトリックと、指定された AP のチャネル変更に関連したメトリックが含まれます。

図 20:機能強化された DCA トラップではチャネル変更の理由が示されます。

rrm-new20.gif

表面的なその他の機能強化

ロードバランシングの変更

4.1.185.0 以降では、ロードバランシングのデフォルト設定は OFF です。これを有効にすると、ロードバランシング ウィンドウはデフォルトで 5 クライアントに設定されます。

(Cisco Controller) >show load-balancing 

Aggressive Load Balancing........................ Disabled
Aggressive Load Balancing Window................. 5 clients

付録 B:WLC リリース 6.0.188.0 – RRM の機能強化

医療デバイス向けの RRM 機能修正

この機能は、QoS と RRM スキャン延期機能との相互作用の方法を向上させます。特定の省電力モードのクライアントが導入される環境で、小容量クライアント(省電力モードを使用し、定期的にテレメトリ情報を送信する医療用デバイスなど)からの重要情報の欠落を防ぐために、場合によっては、RRM の正常なオフチャネル スキャンを延期する必要があります。

クライアントの WMM UP マーキングを使用すると、UP としてマーキングされたパケットを受信したらオフチャネル スキャンを設定可能な期間だけ延期するように、アクセスポイントへ指示することができます。特定の WLAN に対してこの機能を設定するには、次のコントローラ CLI コマンドを使用します。

config wlan channel-scan defer-priority priority [enable | disable] WLAN-id

priority は、0 〜 7 で、ユーザの優先順位を示します。クライアントと WLAN では、この値を 6 に設定する必要があります。

次のコマンドを使用して、キュー内の UP パケットを受けてスキャンが延期される時間を設定します。

config wlan channel-scan defer-time msec WLAN-id 

時間の値をミリ秒(ms)で入力します。有効な範囲は、100(デフォルト)〜 60000(60 秒)です。この設定は、お使いの無線 LAN 装置の要件に一致させる必要があります。

この機能は、コントローラの GUI でも設定可能です。WLAN を選択し、既存の WLAN を編集するか、新しい設定を作成します。[WLANs] --> [Edit] ページで [Advanced] タブをクリックします。[Off Channel Scanning Defer] で、スキャン延期の優先順位を選択し、遅延時間をミリ秒で入力します。

注: [Off-Channel Scanning Defer] は、ノイズや干渉など、代替チャネル選択に関する情報を収集する RRM の使用時に重要となります。また、オフチャネル スキャンでは不正検出が実行されます。オフチャネル スキャンを提供する必要があるデバイスは、可能な限り、同じ WLAN を使用する必要があります。このようなデバイスが多く存在し、この機能を使用してオフチャネル スキャンが完全に無効化されている可能性がある場合は、モニタ アクセス ポイントや、その WLAN が割り当てられていない同じ位置にあるその他のアクセス ポイントなど、代わりのローカル AP で オフチャネル スキャンを実装する必要があります。

QoS ポリシー(ブロンズ、シルバー、ゴールド、プラチナ)の WLAN への割り当ては、クライアントからのアップリンクでどのように受信されたかに関係なく、パケットがアクセス ポイントからのダウンリンク接続で行われるマーキングに影響します。UP= 1、2 は最低の優先順位で、UP= 0、3 はその次に高い優先順位です。QoS ポリシーをマーキングした結果は、次のようになります。

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 71113