このドキュメントでは、無線リソース管理(RRM)の機能と運用について詳しく説明し、この機能を実現しているアルゴリズムについても詳しく説明します。
次の項目に関する知識があることが推奨されます。
Lightweight アクセス ポイント プロトコル(LWAPP)
一般的な無線 LAN(WLAN)/無線周波数(RF)設計の注意事項(Planet 3 Wireless CWNA 資格に相当する知識)
注:クライアントのアグレッシブロードバランシングおよび不正検出/抑止(およびその他のCisco Intrusion Detection System [IDS]/Cisco IOS® Intrusion Prevention System [IPS]機能)はRRMの機能ではないため、このドキュメントの範囲外です。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
表記法の詳細については、『シスコ テクニカル ティップスの表記法』を参照してください。
CLI で、次の部分を確認します。
show advanced [802.11b|802.11a] txpower
新しいデフォルト値は -70 dBM です。変更されている場合は、さまざまな条件下で最適であること証明されているので、この新しいデフォルト値に戻してください。この値は、RF グループのすべてのコントローラで同じにする必要があります。変更後は設定を忘れずに保存してください。
この値を変更するには、次のコマンドを発行します。
config advanced [802.11b|802.11a] tx-power-control-thresh 70
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 カットオフ パラメータをデフォルト値に戻す必要があります。
CLI で、次の部分を確認します。
show load-balancing
これで、ロードバランシングのデフォルトの状態が無効になりました。有効になっている場合は、デフォルトのウィンドウが 5 になります。つまり、関連付けの上でロードバランシングが発生する前に、この数のクライアントを無線に関連付ける必要があります。ロードバランシングは、高密度のクライアント環境で非常に役立ちます。この機能を使用するかどうかは管理者が決定し、クライアントの関連付けと分散の動作を理解しておく必要があります。
ヒント:
Tx 電力しきい値は、PF グループ名を共有するすべてのコントローラで同じになるように設定します。
4.1.185.0 よりも前のバージョンでは、デフォルトの Tx 電力しきい値は -65 dBm でしたが、この値は多くの導入環境において「強すぎる」ものでした。このしきい値を -68 ~ -75 dBm に設定するとより良い結果が観察されたため、バージョン 4.1.185.0 では、デフォルトの Tx 電力しきい値が -70 dBm になりました。4.1.185.0 以降では、Tx 電力しきい値を -70 に変更し、満足できる結果が得られることを確認するように強く推奨します。これは、RRM でさまざまな機能強化が行われたため、現在の設定が最適ではなくっている可能性があるからです。
原因:
RF グループ名は、ワイヤレス LAN コントローラ(WLC)ごとに設定される ASCII 文字列です。グループ化アルゴリズムは、RF グループのリーダーを選出し、次に、RF グループ全体の送信電力制御(TPC)と動的チャネル割り当て(DCA)を計算します。例外はカバレッジ ホール アルゴリズム(CHA)で、WLC ごとに実行されます。RF グループ化は動的であり、デフォルトでこのアルゴリズムは 600 秒間隔で実行されるので、新しいネイバーが受信される(または既存のネイバーが受信できなくなる)可能性があります。このため、RF グループが変更され、(1 つまたは複数の RF グループに対して)新しいリーダーが選出される場合があります。このとき、TPC アルゴリズムでは、新しいグループ リーダーの Tx 電力しきい値が使用されます。このしきい値が同じ RF グループ名を共有する複数のコントローラ間で一致しないと、TPC 実行時の結果で Tx 電力レベルの不一致が発生する可能性があります。
ヒント:
多くの導入では、カバレッジ測定を 3dB に設定します(デフォルトは 12 dB)。
注:バージョン4.1.185.0では、Txパワーアップ制御やSNRプロファイルのしきい値違反クライアント数のユーザ設定可能な設定などの拡張機能により、802.11b/gではデフォルトの12dB、802.11aではデフォルトの16dBが、ほとんどの環境で適切に機能します。
原因:
カバレッジ測定では、クライアントごとの最大許容 SNR としてデフォルトで 12 dB が使用されます。SNR がこの値を超えるクライアントが 1 台でもあると、アクセス ポイント(AP)が SNR が不適切なクライアントを検出した WLC によって CHA がトリガされます。(多くの場合、ローミング ロジックが不十分な)レガシー クライアントが存在する場合は、許容可能なノイズ フロアを調整して 3 dB まで低下させると一時的に対応できます(4.1.185.0 以降では必要ありません)。
この詳細については、「カバレッジ ホールの検出と補正アルゴリズム」セクションの「スティッキ クライアントの電力増大に関する考慮事項」に記載されています。
ヒント:
ネイバー メッセージを送信する間隔を長く設定すると、システム全体のコンバージェンスと安定化にかかる時間が長くなります。
既存のネイバーから 20 分間受信がないと、AP はネイバー リストからプルーニングされます。
注:バージョン4.1.185.0では、ネイバーリストのプルーニング間隔が延長され、ネイバーパケットが受信されなかったネイバーが最大60分間保持されるようになりました。
原因:
デフォルトで、ネイバー メッセージは 60 秒ごとに送信されます。この頻度は、[Auto RF] ページの [Monitor Intervals] セクションにある [Signal Measurement](4.1.185.0 以降では [Neighbor Packet Frequency])で制御されます(図 15 を参照)。ネイバー メッセージは AP が受信するネイバーのリストを伝達し、次にそれが対応する WLC に伝達されて、最終的にその WLC から RF グループが形成されます(RF グループ名の設定が同じであることを前提としています)。RF のコンバージェンス時間は、ネイバー メッセージの頻度によって完全に決定されるため、このパラメータを適切に設定する必要があります。
ヒント:
[On-Demand] ボタンは、より詳細な制御や確定的な RRM 動作を実行するために使用します。
注:バージョン4.1.185.0では、DCAのアンカー時間、間隔、および感度の設定を使用することで予測可能性を実現できます。
原因:
システム全体のアルゴリズム変更を予測する必要があるユーザのために、RRM をオンデマンド モードで実行できるようになりました。RRM アルゴリズムを使用すると、最適なチャネルおよび電力の設定が計算され、それらが次の 600 秒の間隔で適用されます。その後、アルゴリズムは次にオンデマンドオプションが使用されるまで休止状態になり、システムはフリーズ状態になります。詳細については、図 11 および 図 12 と、それぞれの説明を参照してください。
ヒント:
ロードバランシングのデフォルト設定は ON であり、ロードバランシング ウィンドウは 0 に設定されます。このウィンドウを 10 や 12 など大きい値に変更する必要があります。
注:リリース4.1.185.0以降では、ロードバランシングのデフォルト設定はOFFであり、これを有効にすると、ウィンドウサイズはデフォルトの5になります。
原因:
アグレッシブ ロードバランシングは 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 の故障を補正するための自動的なセルフヒーリング機能も提供されます。
このドキュメントでは、次の用語が使用されています。読者はこれらの用語を十分に理解しておく必要があります。
信号:空中を行き交うあらゆるRFエネルギー。
dBm:RF信号の強度を対数で絶対値で表したものです。dBmはミリワットに直接関連しますが、ワイヤレスネットワーキングでよく使用される非常に低い値で出力パワーを簡単に表すために一般的に使用されます。たとえば、-60 dBm は 0.000001 ミリワットに相当します。
Received Signal Strength Indicator(RSSI):信号強度を数値で測定した絶対値。802.11 のすべての無線で同じ RSSI が報告されるわけではありません。このホワイト ペーパーでは、dBm で示された受信信号と RSSI に直接的な関係があると仮定しています。
ノイズ:802.11信号としてデコードできない信号。ノイズは、802.11 以外の発信元(電子レンジや Bluetooth デバイスなど)で発生する場合、あるいは衝突や他の遅延により信号が無効にされた 802.11 の発信元で発生する場合があります。
ノイズフロア:それ以下になると受信信号を判別できなくなる既存の信号レベル(dBmで表します)。
SNR:ノイズフロアに対する信号強度の比率。この値はデシベル(dB)などで測定される相対値です。
干渉:サービスの低下や損失につながる可能性がある、同じ周波数帯域の不要なRF信号。これらの信号は、802.11 の発信元でも、802.11 以外の発信元でも発生する可能性があります。
RRM アルゴリズムの仕組みの詳細を学習する前に、まず RRM システムが連携して RF グループを形成する方法の基本的なワークフローと、そこで発生する RF 計算を理解する必要があります。これは、シスコの統合ソリューションがすべての RRM 機能を学習およびグループ化して計算するための手順の概要です。
単一のグループとして計算される RF を AP に設定する必要がある複数のコントローラが、同じ RF グループ名でプロビジョニングされます。RF グループ名とは、他の AP から信号を受信したときに自分と同じシステムに属するものかどうかを判断するため、各 AP で使用される ASCII 文字列です。
AP は、自分自身、自分のコントローラ、および自分の RF グループ名に関する情報を共有するネイバー メッセージを定期的に送出します。次に、これらのネイバー メッセージは、同じ RF グループ名を共有している他の AP によって認証されます。
ネイバー メッセージを受信し、共有されるグループ名に基づいて認証できる AP は、この情報(主にコントローラの IP アドレスとネイバー メッセージを送信している AP の情報で構成される)を接続しているコントローラに渡します。
コントローラは、RF グループの一部である他のコントローラを理解できるので、この RF 情報を共有する論理グループを形成し、続いてグループのリーダーを選出します。
RF グループ内の各 AP の RF 環境に関する詳細な情報を備えた一連の RRM アルゴリズムは、次に対する AP 設定の最適化を目的として RF グループのリーダーで実行されます(AP に対してローカルのコントローラで実行されるカバレッジ ホールの検出と補正アルゴリズムは例外)。
DCA
TPC
注:RRM(およびRFグループ化)は、コントローラ間モビリティ(およびモビリティグループ化)とは別の機能です。最初のコントローラ設定ウィザードで、両方のグループ名に割り当てられた共通の ASCII 文字列を使用するのが、唯一の類似点です。共通の文字列を使用するのはセットアップ プロセスを簡略化するためであり、後から別の文字列に変更できます。
注:複数の論理RFグループが存在することは正常です。各コントローラ上の AP がそのコントローラと他のコントローラの結合に寄与するのは、AP が他のコントローラから他の AP をヒアリングできる場合に限られます。大規模環境および大学キャンパスでは、ドメイン全体にまたがるのではなく、建物の小規模な集合に分散された複数の RF グループが存在する場合が普通です。
これらの手順を図に示すと、次のようになります。
図1:APからのネイバーメッセージにより、チャネルと出力を調整するためのシステム全体のRFビューがWLCに提供されます。表1:機能の分類のリファレンス
機能 | 実行元 |
---|---|
RF グループ化 | WLC がグループ リーダーを選出 |
動的チャネル割り当て(DCA) | グループ リーダー |
送信電力制御(TPC) | グループ リーダー |
カバレッジ ホールの検出と補正 | WLC |
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に送信されます。
すべてのコントローラが同じ RF グループ名を共有する場合は、RF グループを形成するため、WLC では 1 台の AP だけが他の WLC の AP を受信する必要があります(詳細については 図 3 を参照してください)。
図3:APはネイバーメッセージを送受信し、コントローラに転送してRFグループを形成します。
ネイバー メッセージは、受信している 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サブグループが形成されます。図5:同じ論理RFサブグループ内のAPは、単一のWLCを共有でき、各APは個別のWLC上にあるか、またはAPが混在しているWLC上にあります。RRM はシステム全体で実行されるので、AP が相互の機能にメッセージを受信できる限り、それらのコントローラは自動的にグループ化されます。この例では、WLC A と B が同じ RF グループにあり、それらの AP は別の論理 RF サブグループにあります。
多数の 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 サブグループが作成されます。’
図 7 のように、同じ RF グループ名で複数のコントローラが設定されていても、それぞれの AP がネイバー メッセージを相互に受信できないようなシナリオでは、2 つの別個の RF グループが(最上位レベルに)形成されます。
図7:WLCは同じRFグループ名を共有しますが、APは互いにヒアリングできないため、2つの別個のRFグループが形成されます。
RF グループ化がコントローラ レベルで行われると、AP が受信する他の AP(およびその AP が接続されているコントローラ)の情報を自分のコントローラに報告するので、各 WLC が直接その他の WLC と通信して、システム全体のグループ化が形成されます。単一のシステム全体のグループ、つまりRFグループ内では、APの多くのサブセットが互いに個別にRFパラメータを設定します。リモートサイトに個別のAPを持つ1つの中央WLCを検討してください。このため、各 AP は、独自の RF パラメータを他の AP とは別に持ち、各 AP は同じコントローラの RF グループ化に属しながら、(この例では)各 AP が独自の論理 RF サブグループを持ちます(図 8 を参照)。
図8:各APのRFパラメータは、ネイバーメッセージを相互に受信できないため、他のAPとは別に設定されます。
各 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 を下回った場合に限り削除します。
注:ワイヤレスLANコントローラソフトウェアリリース4.2.99.0以降では、RRMは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 では、802.11 フレームの送受信で占有された合計時間の比率が測定されます。
ノイズ:AP ではサービス対象の各チャネルでノイズ値が計算されます。
干渉:干渉する 802.11 の送信に占められているメディアのパーセンテージに関する AP レポート(これは、外部 AP に加えて非ネイバーからのオーバーラップ信号による場合があります)。
信号強度:各 AP では、サービス対象のすべてのチャネルでネイバー メッセージが受信され、これらのメッセージが受信された際の RSSI 値が記録されます。AP の信号強度に関するこの情報が、チャネル エネルギーの DCA 計算で考慮される最も重要なメトリックです。
次に、グループ リーダーがこれらの値を使用して、最もパフォーマンスが悪い AP のパフォーマンスが、別のチャネル スキーマを使用すると 5 dB(SNR)以上向上するかどうかを判断します。チャネルの変更がローカルに行われるように、動作中のチャネルの AP には重み付けが行われます。これにより変更が制限されるので、1 つの変更を契機としてシステム全体のチャネルが変更されるようなドミノ現象が防止されます。また、変更が必要な場合に、使用率が高いネイバー AP よりも使用率の低い AP のチャネルが変更される可能性が高くなるように、使用率(各 AP の負荷測定レポートによって算出)に基づいて AP に優先度が設定されます。
注:APチャネルが変更されるたびに、クライアントは短時間切断されます。クライアントは自身のローミング動作に基づいて、同じ AP に(新しいチャネルで)再度接続するか、近くの AP にローミングすることができます。互換性のあるクライアントがあれば、高速セキュア ローミング(CCKM と PKC の両方で提供)により、この短時間の中断を短縮できます。
注:APが初めて(出荷直後の)ブートアップする場合、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 は次の段階を経て送信電力の変更が必要かどうかを判断します。
3 番目のネイバーがあるかどうか、または 3 番目のネイバーが送信電力制御のしきい値を超えているかどうかを判断します。
次の式を使用して送信電力を求めます。特定のAPのTx_Max +(しきい値を超える第3の最も高いネイバーのTx電力制御しきい値 – RSSI)。
ステップ 2 の計算を現在の Tx 電力レベルと比較し、TCP ヒステリシスを超過しているかどうか検証します。
送信電力を下げる必要がある場合:少なくとも6 dBmのTPCヒステリシスを満たす必要があります。または
送信電力を増加する必要がある場合:3 dBmのTPCヒステリシスを満たす必要があります。
TPC アルゴリズムで使用されるロジックの例については、「送信電力制御アルゴリズムのワークフローの例」のセクションを参照してください。
注:すべてのAPは、(出荷直後の)最初の起動時に、最大の電力レベルで送信を行います。AP の電源が再投入された場合は、前回の電力設定が使用されますその後、必要に応じて TPC による調整が実行されます。サポートされている AP の送信電力レベルの詳細については、表 4 を参照してください。
注:TPCアルゴリズムによってトリガーされる可能性のあるTx電力の増加に関する主なシナリオが2つあります。
3 番目のネイバーがない場合。このとき、AP はデフォルトで Tx_max に戻り、すぐに実行します。
3 番目のネイバーがある場合。3 番目のネイバーが消滅し、新しい 3 番目のネイバーが存在する可能性がある場合などでは、TPC 式によって実際に推奨される Tx が Tx_max と Tx_current の間にある(むしろ Tx_current よりも低い)ことが評価されます。これにより、Tx 電力が増大します。
TPC による Tx の低下は徐々に実行されますが、Tx の増大は即座に実行される可能性があります。ただし、カバレッジ ホールのアルゴリズムにより、Tx 電力が一度に 1 レベルずつ増大するように、特別な予防策が取られています。
カバレッジ ホールの検出と補正アルゴリズムの目的は、最初にクライアントの信号レベルの品質に基づいてカバレッジ ホールを判断し、クライアントが接続される 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 MinException 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グループ名とも呼ばれる「RF-Network Name」というユーザ指定の値に基づいて形成されます。この文字列は、システム全体の RRM の運用に参加する必要があるすべての WLC で共有する必要があります。
次のセクションにおけるすべての設定の説明と例は、WLC グラフィック インターフェイスから実行されます。WLC の GUI で、[Wireless] メイン ページに移動し、左側にある WLAN 標準の選択肢から [RRM] オプションを選択します。次に、ツリーで [Auto RF] を選択します。後続のセクションでは、結果のページ [Wireless | 802.11a or 802.11b/g RRM | Auto RF…] を参照します。
[Group Mode]:[Group Mode] 設定を使用すると、RF グループ化を無効にできます。この機能を無効にすると、WLC を他のコントローラとグループ化して、システム全体で RRM 機能が実行することを防止できます。無効にした場合、RRM のすべての意思決定はコントローラに対してローカルになります。RF グループ化はデフォルトで有効になっており、同じ RF グループ内の他の WLC の MAC アドレスが、[Group Mode] チェックボックスの右側にリストされます。
[Group Update Interval]:グループの更新間隔の値は、RF グループ化アルゴリズムが実行される間隔を示しています。このフィールドは表示専用であり、変更できません。
[Group Leader]:このフィールドには、現在 RF グループ リーダーになっている WLC の MAC アドレスが表示されます。RF グループ化は AP ごと、無線ごとに実行されるので、802.11a と 802.11b/g のネットワークではこの値が異なる場合があります。
[Is this controller a Group Leader]:コントローラが RF グループ リーダーの場合、このフィールドは「Yes」になります。 WLC がリーダーではない場合は、前のフィールドにグループ内のリーダーの WLC が示されます。
[Last Group Update]:RF グループ化アルゴリズムは、600 秒(10 分)ごとに実行されます。このフィールドには、アルゴリズムが最後に実行されてからの時間(秒単位)が表示されるだけで、必ずしも新しい RF グループ リーダーが選出されてからの時間が表示されるわけではありません。
[Channel Assignment Method]:DCA アルゴリズムは、次の 3 つの方法のいずれかで設定できます。
[Automatic]:これはデフォルト設定です。 RRM が有効になると、DCA アルゴリズムが 600 秒(10 分)ごとに実行され、必要に応じてこの間隔でチャネルが変更されます。このフィールドは表示専用であり、変更できません。付録 A の 4.1.185.0 のオプションを参照してください。
[On Demand]:DCA アルゴリズムの実行を防止します。アルゴリズムを手動でトリガーするには、[Invoke Channel Update now] ボタンをクリックします。
注:On Demandを選択してからInvoke Channel Update Nowをクリックすると、チャネルの変更が必要と仮定してDCAアルゴリズムが実行され、次の600秒の間隔で新しいチャネル計画が適用されます。
[Off]:このオプションはすべての DCA 機能を無効にするので、推奨できません。一般的に、各 AP のチャネルを個別設定するために手動でサイト調査を行う際、このオプションを使用して機能を無効化します。大抵の場合、(関係はありませんが)TPC アルゴリズムも一緒に修正します。
[Avoid Foreign AP Interference]:このフィールドを使用すると、共通チャネルの干渉メトリックを DCA アルゴリズムの計算に含められます。このフィールドはデフォルトで有効になっています。
[Avoid Cisco AP Load]:このフィールドを使用すると、どの AP のチャネルを変更する必要があるか判断する際に、AP の利用率を反映させることができます。多くの場合、AP の負荷は変化するメトリックなので、これを RRM の計算に含めることが常に適切であるとは限りません。そのため、デフォルトでこのフィールドは無効になっています。
[Avoid non-802.11b Noise]:このフィールドを使用すると、各 AP の 802.11 以外のノイズ レベルを DCA アルゴリズムの構成要因にすることができます。このフィールドはデフォルトで有効になっています。
[Signal Strength Contribution]:ネイバー AP の信号強度が常に DCA の計算に含まれます。このフィールドは表示専用であり、変更できません。
[Channel Assignment Leader]:このフィールドには、現在 RF グループ リーダーになっている WLC の MAC アドレスが表示されます。RF グループ化は AP ごと、無線ごとに実行されるので、802.11a と 802.11b/g のネットワークではこの値が異なる場合があります。
[Last Channel Assignment]:DCA アルゴリズムは、600 秒(10 分)ごとに実行されます。このフィールドには、アルゴリズムが最後に実行されてからの時間(秒単位)が表示されるだけで、必ずしも新しいチャネルが割り当てられてからの時間が表示されるわけではありません。
[Power Level Assignment Method]:TPC アルゴリズムは、次の 3 つの方法のいずれかで設定できます。
[Automatic]:これはデフォルト設定です。 RRM が有効になると、TPC アルゴリズムが 10 分(600 秒)ごとに実行され、必要に応じてこの間隔で電力設定が変更されます。このフィールドは表示専用であり、変更できません。
[On Demand]:TPC アルゴリズムの実行を防止します。アルゴリズムを手動でトリガーするには、[Invoke Channel Update Now] ボタンをクリックします。
注: On Demandを選択してからInvoke Power Update Nowをクリックすると、電力の変更が必要と仮定してTPCアルゴリズムが実行され、次の600秒の間隔で新しい電力設定が適用されます。
[Fixed]:このオプションはすべての TPC 機能を無効にするので、推奨できません。一般的に、各 AP の電力を個別設定するために手動でサイト調査を行う際、このオプションを使用して機能を無効化します。大抵の場合、(関係はありませんが)DCA アルゴリズムも一緒に無効化します。
[Power Threshold]:この値(単位は dBm)は、TPC アルゴリズムが下方向に電力レベルを調整する際のカットオフ信号レベルです。そのため、この値は受信されるネイバーのうち 3 番目に強いものの値となります。AP が必要な送信電力レベルよりも高い電力で送信しているために(高密度のシナリオで発生する可能性がある)、RF 環境の電力が「強すぎる」と判断される場合がまれにあります。このような場合は、config advanced 802.11b tx-power-control-thresh コマンドを使用して、電力レベルを下げるように調整できます。これによって、3 番目に信号レベルの強いネイバー AP の信号をより高い RF セパレーションで受信できるようになり、ネイバー AP はより低い出力レベルで伝送可能になります。ソフトウェア リリース 3.2 までは、このパラメータは変更できませんでした。新しく設定可能になった値の範囲は -50dBm 〜 -80dBm で、これを変更できるのはコントローラの CLI だけです。
[Power Neighbor Count]:AP が TPC アルゴリズムを実行するために必要な最小限のネイバ-数。このフィールドは表示専用であり、変更できません。
[Power Update Contribution]:現在このフィールドは使用されていません。
[Power Assignment Leader]:このフィールドには、現在 RF グループ リーダーになっている WLC の MAC アドレスが表示されます。RF グループ化は AP ごと、無線ごとに実行されるので、802.11a と 802.11b/g のネットワークではこの値が異なる場合があります。
[Last Power Level Assignment]:TPC アルゴリズムは 600 秒(10 分)ごとに実行されます。このフィールドには、アルゴリズムが最後に実行されてからの時間(秒単位)が表示されるだけで、必ずしも新しい電力が割り当てられてからの時間が表示されるわけではありません。
Wireless Control System(WCS)で RRM しきい値と呼ばれているプロファイルしきい値は、主にアラーム目的で使用されます。ネットワークの問題の診断を容易にするために、これらの値を超過すると WCS(または任意の SNMP ベースの管理システム)にトラップが送信されます。これらの値は、アラーム目的でのみ使用され、RRM アルゴリズムの機能とはまったく関係がありません。
図13:デフォルトのアラームプロファイルしきい値。
[Interference (0 to 100%)]:この値を超えるとアラームが起動される、802.11 の干渉信号による無線メディアの占有率。
[Clients (1 to 75)]:無線あたり、AP あたりのクライアント数。これより多いとコントローラが SNMP トラップを生成します。
[Noise (-127 to 0 dBm)]:ノイズ フロアが設定レベルよりも高くなったとき、SNMP トラップを生成するために使用します。
[Coverage (3 to 50 dB)]:クライアントごとの最大許容 SNR レベル。この値は、[Coverage Exception Level] と [Client Minimum Exception Level] の両方のしきい値に対するトラップを生成するときに使用されます(4.1.185.0 以降ではカバレッジ ホール アルゴリズムのサブセクションの一部)。
[Utilization (0 to 100%)]:AP の無線が送信受信に費やす時間の最大の割合を示すアラーム値。長期的なネットワーク利用率の追跡に役立ちます。
[Coverage Exception Level (0 to 100%)]:AP の無線動作で目的のカバレッジしきい値(上記でで定義済み)を下回るクライアントの最大の割合。
[Client Min Exception Level]:SNR がカバレッジしきい値(上記でで定義済み)未満の AP に対して許容されるクライアントの最低数(4.1.185.0 以降ではカバレッジ ホール アルゴリズムのサブセクションの一部)。
シスコの AP では、クライアント データ サービスの提供と RRM(および IDS/IPS)機能の定期的なスキャンが行われています。AP にスキャンを許可するチャネルは設定で変更可能です。
チャネルリスト:ユーザは、APが定期的にモニタするチャネル範囲を指定できます。
[All Channels]:この設定では、スキャニング サイクルにすべてのチャネルを含めるように AP に指示します。この設定は主に IDS/IPS 機能に役立ちます(この機能についてはこのドキュメントでは扱っていません)。RRM の処理に関しては、[Country Channels] 設定と同等になります。
[Country Channels]:AP は、各 WLC の規制ドメイン設定で明示的にサポートされるチャネルだけをスキャンします。つまり、AP は地域の規制団体で許可されるチャネルの受信に対して定期的に時間を費やします(オーバーラップするチャネルと、一般に使用されるオーバーラップしないチャネルを含むことができます)。これはデフォルト設定です。
[DCA Channels]:DCA アルゴリズムに基づいて AP に割り当てられたチャネルのみに AP のスキャンを制限します。つまり、米国では、802.11b/g 無線はデフォルトでチャネル 1、6、11 のみをスキャンします。これは、サービスが提供されるチャネルだけにスキャンで重点を置き、不正な AP は重要視しないという考えに基づいています。
注:DCAアルゴリズムで使用されるチャネルのリスト(チャネルモニタリングと割り当ての両方)は、WLCコードバージョン4.0以降で変更できます。たとえば、米国では、DCA アルゴリズムはデフォルトで 11b/g チャネル 1、6、11 のみを使用します。この DCA リストにチャネル 4 と 8 を追加して 6 を削除するには、コマンドをコントローラ CLI で次のように入力する必要があります(この設定は単なる例であり、推奨されません)。
(Cisco Controller) >config advanced 802.11b channel add 4 (Cisco Controller) >config advanced 802.11b channel add 8 (Cisco Controller) >config advanced 802.11b channel delete 6
[All Channels] を選択するなど、より多くのチャネルをスキャンすると、データ クライアントのサービスに費やす合計時間が(スキャン プロセスに含まれるチャネルが少ない場合と比較して)わずかに減少します。ただし、([DCA Channels] 設定と比較して)より多くのチャネルの情報を蓄積することが可能です。IDS/IPS で [All Channels] を選択する必要がない場合は、デフォルト設定の [Country Channels] を使用する必要があります。また、しきい値プロファイルのアラームおよび RRM アルゴリズムの検出と補正のいずれでも、他のチャネルの詳細情報が必要ない場合もあります。この場合には、[DCA Channels] を選択するのが適切です。
図14:「Country Channels」がデフォルトの選択ですが、RRM監視チャネルは「All」または「DCA」チャネルのいずれかに設定できます。
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ミリ秒が費やされます(180/11 = ~16秒)。
図15:RRM監視間隔とそのデフォルト値
[Noise Measurement]、[Load Measurement]、[Signal Measurement]、および [Coverage Measurement] の間隔は、RRM アルゴリズムに入力する情報の密度を変更するために調整できます。これらのデフォルト値は、Cisco TAC による指示がない限り変更しないでください。
注:これらのスキャン値のいずれかが、RRMアルゴリズムが実行される間隔(DCAとTPCの両方で600秒、カバレッジホールの検出と補正で180秒)を超えるように変更された場合、RRMアルゴリズムは実行されますが、「古い」情報が含まれる可能性があります。
注:WLCがリンク集約(LAG)を使用して複数のギガビットイーサネットインターフェイスをボンディングするように設定されている場合は、ユーザアイドルタイムアウト機能をトリガーするためにカバレッジ測定間隔が使用されます。そのため、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:自動RFチャネルおよび電力更新トラップはデフォルトで有効になっています。
RF グループ リーダー(および DCA アルゴリズム)がチャネル スキーマを提案、適用、最適化した後は、[Trap Logs] サブメニューから変更を簡単にモニタできます。このようなトラップの例は、次のように表示されます。
図17:チャネル変更ログエントリには、無線のMACアドレスと新しい動作チャネルが含まれています。
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はDCAで考慮されます)。内部テストにより、このような場合のトラブルシューティングでは、3 番目のネイバーが認識する RSSI を -70 dBm に変更すると、トラブルシューティングを開始できる妥当な値になることが明らかになっています。
チャネルの変更が発生したときにトラップが生成されるのと同様に、TPC による変更でもトラップが生成され、また、新しい変更に関連した必要な情報はすべてこれらのトラップに明確に示されます。サンプル トラップは次のように表示されます。
図18:Tx電力トラップログは、指定された無線の動作の新しい電力レベルを示します。
このセクションの例では、TPC アルゴリズムで定義されている 3 つのステップと条件に基づいて、AP の 送信電力を変更する必要があるかどうかを判断する計算方法について説明します。この例では、次の値を想定しています。
Tx_Max が 20
現在の送信電力が 20 dBm
設定される TPC しきい値が -65 dBm
3 番目のネイバーの RSSI が -55 dBm
これらを TPC アルゴリズムの 3 つの段階に当てはめると、次のようになります。
条件1:3番目のネイバーがあり、送信電力制御のしきい値を超えているため、確認されます。
条件2: 20 + (-65 - (-55)) = 10
条件3:電力は1レベル低下する必要があり、条件2の10の値がTPCヒステリシスを満たしているため、Tx電力は3dB低下し、新しいTx電力は17dBmまで低下します。
TPC アルゴリズムの次の反復で、AP の Tx 電力はさらに 14 dBm まで低下します。その他のすべての条件は変わらないと仮定しますが、14 dBm のマージンが 6 dB 以上ではないので、(すべて一定のまま)Tx 電力はさらに 11 dBm まで低下することに注目してください。
カバレッジ ホールの検出と補正アルゴリズムで使用される意思決定プロセスを示すために、次の例では、最初に 1 台のクライアントで受信される SNR レベルが不適切で、システムの変更が必要かどうかと、電力がどのように変化するのかを決定する方法について説明します。
カバレッジ ホール SNR しきい値の式を思い出してください。
クライアントの SNR 遮断値(|dB|) = [AP 伝送パワー(dBm) – 定数(17 dBm) – カバレッジ プロファイル(dB)]
フロアのカバレッジが悪いエリアで信号の問題が発生しているクライアントの状況を考慮します。そのようなシナリオでは、次のことが当てはまる可能性があります。
クライアントの SNR は 13 dB である。
クライアントが接続されている AP は 11 dBm(出力レベル 4)で伝送するように設定されている。
AP の WLC の [Coverage] プロファイルしきい値はデフォルトの 12 dB に設定されている。
クライアントの AP の電力を増大させる必要があるかどうかを決定するために、これらの数字をカバレッジ ホールのしきい値の式に当てはめると、結果は次のようになります。
クライアントのSNRカットオフ値= 11 dBm(AP送信電力) – 17 dBm(定数値) – 12 dB(カバレッジしきい値)= |-18dB|。
クライアントの 13 dB という SNR は、18 dB という現在の SNR のカットオフに違反しているので、カバレッジ ホールの検出と補正アルゴリズムによって AP の送信電力が 17 dBm に上げられます。
カバレッジ ホール SNR しきい値の式を使用することで、新しい送信電力 17 dBm からクライアントの SNR カットオフ値 12 dB を算出し、クライアントの SNR レベル 13 dBm を満たします。
前のステップの計算は次のとおりです。クライアントのSNRカットオフ値= 17 dBm(AP送信電力) – 17 dBm(定数値) – 12 dB(カバレッジしきい値)= |-12dB|。
802.11b/g 周波数帯でサポートされる電力出力レベルについては、表 4 に記載されています。802.11a の電力レベル出力を決定するために、次の CLI コマンドを実行します。
show ap config 802.11a
表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 |
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 コマンドを使用すると、RRM アルゴリズムが実行されるタイミング、使用するデータ、および実行される変更(存在する場合)を特定できるすべての RRM デバッグを呼び出せます。
この例では、コマンドは RF グループ リーダー上で実行され、DCA アルゴリズムの内部の動作を把握し、次の 4 つのステップに分割できます(debug airewave-director all コマンドの出力は動的チャネル割り当てプロセスだけを示すように抜粋されています)。
アルゴリズムで実行される現在の統計情報を収集して記録します。
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)
新しいチャネル スキーマを提案して、推奨値を保存します。
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)
提案値と現在の値を比較します。
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)
必要に応じて、新しいチャネル スキーマが有効になるように変更を適用します。
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
このコマンドを使用すると、そのコントローラの RRM の動作の詳細な状況をリアルタイムで表示できます。次に、関連するメッセージについて説明します。
グループ階層を維持するためにグループ メンバーへ送信されるキープアライブ メッセージです。
Airewave Director: Sending keep alive packet to 802.11a group members
報告されたネイバーに対して計算される負荷の統計情報です。
Airewave Director: Processing Load data on 802.11bg AP 00:13:5F:FA:2E:00(0) Airewave Director: Processing Load data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Load data on 802.11bg AP 00:0B:85:23:7C:30(1)
AP から受信されたネイバー メッセージの強度を示します。
Airewave Director: Neighbor packet from 00:0B:85:54:D8:10(1) received by 00:13:5F:FA:2E:00(0)rssi -36 Airewave Director: Neighbor packet from 00:0B:85:23:7C:30(1) received by 00:13:5F:FA:2E:00(0)rssi -43
報告される無線で計算されるノイズと干渉の統計情報です。
Airewave Director: Sending keep alive packet to 802.11bg group members Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing noise data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:54:D8:10(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:23:7C:30(1) Airewave Director: Processing noise data on 802.11bg AP 00:0B:85:23:7C:30(1) Airewave Director: Processing Interference data on 802.11bg AP 00:0B:85:23:7C:30(1)
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)
他の 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
ネイバー リストの「プルーニング タイマー」
WLC ソフトウェア 4.1 の最初のメンテナンス リリースの前では、最後に受信したときから最大 20 分間、AP はネイバー リストに他の AP を維持ました。このとき、RF 環境が一時的に変更される場合に、有効なネイバーが AP のネイバー リストからプルーニングされることがありました。このような RF 環境に対する一時的な変更に対応するため、AP のネイバー リストのプルーニング タイマー(ネイバー メッセージを受信してからの時間)は 60 分間に延長されています。
チャネル割り当ての方法
Automatic モードにおける 4.1.185.0 より前のデフォルト動作は、10 分ごとに DCA チャネル計画を計算し、必要に応じてそれを適用するものでした。変化が激しい環境では、1 日のチャネル変更が非常に多く発生する可能性があります。そのため、DCA の頻度を微調整する必要が生じました。4.1.185.0 以降では、頻度を微調整する必要がある場合に、次の設定を使用できます。
[Anchor Time]:デフォルトの 10 分を変更するために、グループ リーダーが Start-up モードで実行するアンカー タイムを選択するオプションが用意されています。Start-up モードは、10 分ごとの最初の 10 回の繰り返し(100 分間)を DCA 感度 5dB で動作する期間として、DCA が 定義されています。これは、リリース 4.1 で RRM タイマーが追加される前の通常モードです。これにより、ネットワークを最初にすばやく安定させることができます。Start-up モードが終了すると、DCA はユーザが定義した間隔で動作します。Start-upモードの動作は、show advanced 802.11[a|b]コマンドを介してWLC CLIに明確に示されます。
(Cisco Controller) >show advanced 802.11a channel Automatic Channel Assignment Channel Assignment Mode........................ AUTO Channel Update Interval........................ 600 seconds [startup] Anchor time (Hour of the day).................. 0 Channel Update Contribution.................... SNI. Channel Assignment Leader...................... 00:16:46:4b:33:40 Last Run....................................... 203 seconds ago DCA Senstivity Level: ....................... MEDIUM (5 dB) Channel Energy Levels Minimum...................................... unknown Average...................................... unknown Maximum...................................... unknown Channel Dwell Times Minimum...................................... unknown Average...................................... unknown Maximum...................................... unknown Auto-RF Allowed Channel List................... 36,40,44,48,52,56,60,64,100, ............................................. 104,108,112,116,132,136,140, ............................................. 149,153,157,161 Auto-RF Unused Channel List.................... 165,20,26
[Interval]:間隔の値(時間単位)。予測可能なネットワークを構築でき、チャネル計画の評価は、設定された間隔でのみ計算されます。 たとえば、3 時間という間隔が設定されている場合、DCA は新しいチャネル計画を 3 時間ごとに計算します。
[Sensitivity]: 動的チャネル割り当てアルゴリズムのセクションで説明したように、アルゴリズムを実行してチャネル計画が向上するかどうかを評価する、アルゴリズムで考慮される 5 dB のヒステリシスをユーザが微調整できるようになりました。[Low]、[Medium]、または [High] の設定が可能で、低く設定するとアルゴリズムが影響を受けず、高く設定するとアルゴリズムが強い影響を受けます。両方の周波数帯のデフォルトのレベルは [Medium] です。
802.11aでは、感度値はLow(35dB)、Medium(20dB)、およびHigh(5dB)になります。
802.11b/gでは、感度値はLow(30dB)、Medium(15dB)、およびHigh(5dB)になります
デフォルトの送信電力制御しきい値
送信電力制御のしきい値は、常に 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:プロファイルしきい値から分離されたカバレッジホールアルゴリズムのサブセクションで、ほとんどのインストールで最適な結果を提供するデフォルト値を使用
カバレッジ ホールの緩和を開始するために必要な、違反しているクライアントの数に加えて、アルゴリズムも強化され、インテリジェントな方法で AP の送信電力を増大が考慮されるようになりました。送信電力を最大値まで上げることは、十分な緩和とオーバーラップを確実に実施する安全策ですが、ローミングが不十分なクライアントが導入されるという悪影響も及ぼします。クライアントは別の AP(一般には最も強い信号を提供する AP)に関連付けを変更するのではなく、AP 遠く離れている同じ古い AP への関連付けを維持します。結果として、このクライアントは関連付けを持つ AP から適切な信号を受け取れなくなります。ローミングが不十分なために障害が発生したクライアントは、誤検出の可能性があるカバレッジ ホール シナリオの例です。ローミングが不十分であっても、本当にカバレッジホールが存在することを示しているわけではありません。カバレッジ ホールの可能性は、次のような場合に現実となります。
そのカバレッジ ホールが目的のカバレッジ エリア内にある場合。および、
そのカバレッジ ホール内のクライアントが他の利用可能な AP に関連付けを変更された場合でも、クライアントが受信するダウンリンク信号と、クライアントからの代わりの AP へのアップリンク信号がカバレッジしきい値を引き続き下回るとき。
このようなシナリオを避けて軽減させるため、AP 送信電力は 1 度に 1 レベルだけ上昇し(1 反復あたり)、ネットワークの電力を増大させることなく、本当のカバレッジ ホールが電力増大の利点を得られるようになります(結果として共通チャネルの干渉を回避します)。
チャネル変更時に生成される SNMP トラップの機能が強化され、新しいチャネル計画を実装するための理由を説明する詳細な情報が提供されるようになりました。次の図から明らかになるように、機能強化されたトラップには DCA アルゴリズムで使用された前後のメトリックと、指定された AP のチャネル変更に関連したメトリックが含まれます。
図20:改善されたDCAトラップはチャネル変更の背後にある理由を表示します
設定を簡潔にして使いやすくするため、CHA に新しいサブセクションが作成されました。このセクションはプロファイルしきい値のサブセクションから独立して、SNMP トラップを生成するトリガーを直接制御します。
Monitor IntervalsサブセクションにあるSignalとCoverage measurementsという用語も、それぞれの適切な意味(ネイバーパケット周波数とチャネルスキャン時間)を反映するように変更されています。
4.1.185.0 以降では、ロードバランシングのデフォルト設定は OFF です。これを有効にすると、ロードバランシング ウィンドウはデフォルトで 5 クライアントに設定されます。
(Cisco Controller) >show load-balancing Aggressive Load Balancing........................ Disabled Aggressive Load Balancing Window................. 5 clients
この機能は、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] で、スキャン延期の優先順位を選択し、遅延時間をミリ秒で入力します。
注:オフチャネルスキャンは、ノイズや干渉などの代替チャネルの選択に関する情報を収集するRRMの動作に不可欠です。また、オフチャネル スキャンでは不正検出が実行されます。オフチャネル スキャンを提供する必要があるデバイスは、可能な限り、同じ WLAN を使用する必要があります。このようなデバイスが多く存在し、この機能を使用してオフチャネル スキャンが完全に無効化されている可能性がある場合は、モニタ アクセス ポイントや、その WLAN が割り当てられていない同じ位置にあるその他のアクセス ポイントなど、代わりのローカル AP で オフチャネル スキャンを実装する必要があります。
QoS ポリシー(ブロンズ、シルバー、ゴールド、プラチナ)の WLAN への割り当ては、クライアントからのアップリンクでどのように受信されたかに関係なく、パケットがアクセス ポイントからのダウンリンク接続で行われるマーキングに影響します。UP= 1、2 は最低の優先順位で、UP= 0、3 はその次に高い優先順位です。QoS ポリシーをマーキングした結果は、次のようになります。
ブロンズは、すべてのダウンリンク トラフィックを UP= 1 にマーキングします。
シルバーは、すべてのダウンリンク トラフィックを UP=0 にマーキングします。
ゴールドは、すべてのダウンリンク トラフィックを UP= 4 にマーキングします。
プラチナは、すべてのダウンリンク トラフィックを UP= 6 にマーキングします。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
07-Feb-2014 |
初版 |