radio resource management に関するホワイトペーパー -...

Radio Resource Management に関するホワイトペーパー初版：2016年 02月 18日

最終更新：2016年 06月 14日

シスコシステムズ合同会社〒107-6227 東京都港区赤坂9-7-1 ミッドタウン・タワーhttp://www.cisco.com/jpお問い合わせ先：シスココンタクトセンター

0120-092-255 （フリーコール、携帯・PHS含む）電話受付時間：平日 10:00～12:00、13:00～17:00http://www.cisco.com/jp/go/contactcenter/

【注意】シスコ製品をご使用になる前に、安全上の注意（ www.cisco.com/jp/go/safety_warning/ ）をご確認ください。本書は、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきま

しては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容

については米国サイトのドキュメントを参照ください。また、契約等の記述については、弊社販

売パートナー、または、弊社担当者にご確認ください。

このマニュアルに記載されている仕様および製品に関する情報は、予告なしに変更されることがあります。このマニュアルに記載されている表現、情報、および推奨

事項は、すべて正確であると考えていますが、明示的であれ黙示的であれ、一切の保証の責任を負わないものとします。このマニュアルに記載されている製品の使用

は、すべてユーザ側の責任になります。

対象製品のソフトウェアライセンスおよび限定保証は、製品に添付された『Information Packet』に記載されています。添付されていない場合には、代理店にご連絡ください。

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain versionof the UNIX operating system.All rights reserved.Copyright © 1981, Regents of the University of California.

ここに記載されている他のいかなる保証にもよらず、各社のすべてのマニュアルおよびソフトウェアは、障害も含めて「現状のまま」として提供されます。シスコお

よびこれら各社は、商品性の保証、特定目的への準拠の保証、および権利を侵害しないことに関する保証、あるいは取引過程、使用、取引慣行によって発生する保証

をはじめとする、明示されたまたは黙示された一切の保証の責任を負わないものとします。

いかなる場合においても、シスコおよびその供給者は、このマニュアルの使用または使用できないことによって発生する利益の損失やデータの損傷をはじめとする、

間接的、派生的、偶発的、あるいは特殊な損害について、あらゆる可能性がシスコまたはその供給者に知らされていても、それらに対する責任を一切負わないものと

します。

このマニュアルで使用している IPアドレスおよび電話番号は、実際のアドレスおよび電話番号を示すものではありません。マニュアル内の例、コマンド出力、ネットワークトポロジ図、およびその他の図は、説明のみを目的として使用されています。説明の中に実際のアドレスおよび電話番号が使用されていたとしても、それは意

図的なものではなく、偶然の一致によるものです。

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries.To view a list of Cisco trademarks, go to this URL: http://www.cisco.com/go/trademarks.Third-party trademarks mentioned are the property of their respective owners.The use of the word partner does not imply a partnershiprelationship between Cisco and any other company.(1110R)

© 2016 Cisco Systems, Inc. All rights reserved.

http://www.cisco.com/go/trademarks

http://www.cisco.com/go/trademarks

目次

Radio Resource Management 1

はじめに 1

シスコの RRMの歴史的経緯 2

Radio Resource Managementの概念 7

前提条件と想定対象者 7

主な用語 8

RRMデータ収集アクティビティ 11

RRMデータ収集アクティビティ 11

RFグループ化 15

RFグループの形成方法 16

Neighbor Discovery Protocol（NDP） 17

NDPと DFS 21

NDPの用途 21

RFグループリーダーの選定 22

RFグループ化自動モード 25

静的 RFグループ化 26

RFグループの拡張性 27

RFグループの後方互換性 29

WSSI、WSM、WSM2モジュールと RRM 29

RFグループ化のトラブルシューティング 30

RRMデータの収集 30

RFグループ化の問題 31

理由コードの概要 34

フレキシブルラジオアサインメント（FRA）と重複したラジオ 37

FRA：カバレッジオーバーラップファクタ（COF） 39

FRA：無線 Roleの割り当て 43

FRA：クライアントネットワーク優先度 45

Radio Resource Management に関するホワイトペーパーiii

FRA：定常状態動作 47

FRAとデュアル 5 GHz動作 48

802.11v BSS Transition -デフォルトで有効 49

802.11k -デフォルトで有効 49

プローブ抑制 -デフォルトで無効 49

FRA：トラブルシューティング 50

FRA - CLIおよびデバッグコマンド 52

FRA -ベストプラクティス 55

動的チャネル割り当て（DCA） 57

動的チャネル割り当ての機能 57

動的チャネル割り当て（DCA）アルゴリズム 59

DCAの概要 60

DCA感度しきい値 61

DCAの動作モード 62

スケジュール DCA 62

起動モード 63

安定状態モード 63

DCAでの 20/40/80/160 MHzのサポート 65

DCA：OBSSと構造的共存 66

動的チャネル幅選択 - DBS 70

Flex DFS：柔軟な動的周波数選択 72

デバイス認識型 RRM 73

永続的デバイスの回避（Persistent Device Avoidance） 73

ED-RRM 76

伝送パワーコントロール（TPC）アルゴリズム 79

TPCの機能 79

TPCv1 80

Tx_Ideal理想電力の計算 81

TPCv1変更推奨の評価 81

推奨電力変更の実装 81

TPCv2 83

TPCの最小/最大 86

カバレッジホール検出軽減アルゴリズム 89

Radio Resource Management に関するホワイトペーパーiv

目次

カバレッジホールの検出（CHD） 90

カバレッジホールの軽減 91

ローミングの最適化 91

RFプロファイル 93

TPC 94

DCA 95

カバレッジホール検出 95

トラップのプロファイルしきい値 96

Radio Resource Management に関するホワイトペーパーv

目次

Radio Resource Management に関するホワイトペーパーvi

目次

第 1 章

Radio Resource Management

• はじめに, 1 ページ

• シスコの RRMの歴史的経緯 , 2 ページ

はじめにワイヤレス接続はまさにユビキタスで、Wi-Fiは常に最も急成長の見込まれる無線テクノロジーの1つです。すべてのものにWi-Fiのチップセットやクライアントがインストールされ、IoTの準備が整いつつあります。2011年のアナリストのレポートを振り返ると、インターネットにおける無線ステーションの数と有線ステーションの数は 2015年までに反転し、無線のユーザ数が有線のノード数を超えるとされていました。シスコは、2014年にはその想定に先んじ、状況はさらに加速すると将来を見越していました。かつて、私たちはキャパシティを評価するために座席の数を

数えていました。しかし今では、ほとんどのユーザが常に稼働するアクティブなデバイスを複数

持っています。席に着いてこの文章を書いている私の周りにも、デバイスが 3台あります。この文章を書いているラップトップ、スマートフォン、今は休止モードになっているタブレットです。

私はどのデバイスの電源も切りません。おそらくみなさんもそうでしょう。このような永続的な

接続では、十分な帯域幅とその見直しが必要です。無線のスペクトルが以前よりも貴重なものと

なって、使用可能なスペクトルの確保が常に求められ、片時も緊張を緩めることができないよう

です。いまだに大きく変更されていないのはスペクトルです。これに取り組む必要があります。

これらがすべて関連して、無線管理者やネットワークオペレータの主要な任務が成り立つことに

なります。

これまでのところ、最も過密になっているのは 2.4 GHzスペクトルですが、近いうちに 5 GHz帯にも対象が広がることとなるでしょう（まだそうなっていなければ）。この無線周波数（RF：Radio Frequency）の物理層の世界は、深遠で不可思議なものですが、初めて関わる場合も不安に思うことはありません。定期的にルールがかなり変更されており、あなたは遅れているのではな

く、むしろ間に合ったのです。作業のほとんどはあなたのために行われますが、マネージャの常

としてチームの目標や個人の強みなどをあらかじめ把握しておくことをお勧めします。そのため

に、RadioResourceManagementの内容、機能、動作の仕組みについて確認します。また、RRMに関して適切に検討できるよう、運用環境の特性を把握する方法についても説明します。

Radio Resource Management に関するホワイトペーパー1

なぜ、こうしたことが重要なのでしょうか。スペクトルは物理層です。有線ネットワークとは異

なり、スペクトルはすべての方向に自由に伝播します。つまり、同一チャネル上で、2つのセルが互いに重複する場合、通常はそれぞれに割り当てられたスペクトルが共有されていることにな

ります。それぞれのセルのユーザが使用可能なスペクトルを単一チャネルで共有するということ

だけでなく、管理トラフィックも倍になります。その結果として、通信時間がより多く消費され、

スループットも低下します。これが一般に、同一チャネル干渉と呼ばれるものです。すべてのワ

イヤレスデバイスがネットワーク上で動作しており、隣接するネットワークでは動作していない

と仮定した場合、同一チャネル干渉に対してある特定のセルを調整するために操作できるのは次

の 2つのみです。

•チャネル計画：1つのアクセスポイント（AP）から別の APへの距離を最大限とれるようにチャネル計画を調整します

•電力レベル：電力レベルの増加および削減により、効果的なセルのサイズを決定します。

それぞれは別の引数となりますが、有効なソリューションを作成する上で、互いに関連します。

Cisco Radio Resource Management（RRM）により、シスコの統合型WLANアーキテクチャで、既存のRFの状況を継続的に分析し、各APの電力やチャネル設定を自動的に調整して、共同チャネル干渉や信号カバレッジ問題を軽減することができます。RRMは、労力のともなうサイト調査の実施の必要性を軽減し、システムキャパシティの増加や、RFのデッドゾーンや APの故障を補正する自動セルフヒーリング機能を提供します。

このホワイトペーパーでは、RRMの機能と運用について詳しく説明し、同機能の背後にあるアルゴリズムの詳細について解説します。

シスコの RRM の歴史的経緯RRMはAireSpace APとコントローラの機能として初めて導入され、2005年のAireSpaceの買収により、シスコ CUWNの一部になりました。

2005年当時、ネットワークに APが 150台あれば、それは大規模なWi-Fiネットワークとされました。今日では、3000台から 5000台規模のRFの導入はごくありふれたもので、キャンパス、スタジアム環境、会議センター、地下鉄や病院などにおいては、さらに多くの APが導入されています。短い期間の間に多くの変化が起こり、検討されるべき内容も変わりました。そして、1つの回答として、RRMが必要だということになってきています。2007年以降、CUWN（CiscoUnifiedWirelessNetwork）のコードがリリースされるたびに、RRMに関連した複数の機能が盛り込まれ、周波数帯の効率性と RRMの効力を向上させるための機能が含まれるようになりました。

AP同士の間隔が狭くなっていくにつれ、導入の際には、単にカバレッジのモデルを提示するだけでなく、エッジ側の技術だけで数千のデバイスを扱うための高密度の容量確保が求められるよう

になりました。コアテクノロジーとしての RRMへの投資も、そうした変化に追随しました。有線での接続をしないスマートフォンやタブレットが単なるアクセサリであった時代は過ぎ去り、

それらはユーザにとって主要なコンピューティングプラットフォームとなっています。ネット


Radio Resource Managementシスコの RRM の歴史的経緯

ワーク設計の方法論やネットワーク全体が、これまでとは異なる目標や、技術、戦略に対応せざ

るを得なくなっており、負担が増大しています。

図 1：図解で見る Wi-Fi のタイムライン

ワイヤレスオフィスは、今では単なる優れたアイデアということではなく、業務を行い、コア

サービスを提供する上で必須となる多様なデバイスを繋ぐことができる唯一のネットワーク接続

として世界中で導入されています。Wi-Fiはもはやミッションクリティカルなのです。

RRMは、テクノロジーの変化に対応してきました。シスコでは、過去 5年のうちに、古い単一無線インターフェイスから、80MHzの空間ストリーム 4つを備えた 802.11acにまで対応してきました。これらの変更は、効率性の面での発展を取り入れるためのものですが、新しい無線通信を必

要とします。コアネットワークのアップグレードだけでなく、クライアントへのこれらの変更は

運用環境に影響を及ぼします。2003年に、802.11nが登場した際、シスコでは、OBSS（OverlappingBase Service Set）の概念の検討が始まり、単一の半二重無線ストリームを調整する代わりに、同時空間ストリームの調整と既存の 20 MHzチャネルへのリンクを開始し、チャネル幅と空間効率双方の増加を図りました。

表 1：現在の Wi-Fi プロトコルと機能の比較

20 MHz チャネル空間ストリーム特性日付プロトコル

111、2Mbps、赤外線、拡散および DSSS、802.11FH2.4 GHz

1997802.11

111、2、5.5、11 Mbps、DSSS 2.4 GHz

1999802.11b

116、9、12、18、36、48、54 Mbps - OFDM - 5 Ghz

1999802.11a

116、9、12、18、36、48、54 Mbps - OFDM - 5 Ghz

2003802.11g



20 MHz チャネル空間ストリーム特性日付プロトコル

1～ 21～ 3MCS 1-15-23 1-3 SS、OFDM、20、40MHz、2.4および 5 GHz

2005802.11n

1～ 81～ 81-8 SSMCS 1-9、OFDM、20-40-80-160MHz、5GHz

2012/15802.11ac

人々のスマートフォンやその機能への依存が少しずつ進んだことから、クライアント市場での

802.11nの浸透にも時間がかかりました。当時の主要なスマートフォンクライアントでは、その性能が厳密に 2.4 GHzに制限されていました。その後、時間が経つにつれ、より多くの機能が普及するようになりました。BYODなど、職場に自分の好みのプラットフォームを持ち込むことが始まると、ハードウェア技術の改善が求められるようになり、市場ではデュアルバンドのスマー

トデバイスへの変更が始まりました。こうした変革のピーク時に、802.11ACが登場し、シスコではすぐに対応を始めました。こうした動きに市場も追随し、少なくとも 5 GHzをサポートするデバイスが必要だということに、完全ではないながらも広く支持が得られたのは、喜ばしいことで

す。

ネットワークを最新で最も標準的なものに更新したとしても、クライアント市場やネットワーク

でのサポート対象に関して選択肢が残り、原則として同じスペクトルを使えるということを、効

率性の面で評価できるということが重要です。下位互換性は常にネットワークテクノロジーの一

部です。ワイヤレス通信においては通信時間に限界のあることから、限られた時間の中での効率

性は、サポート対象のクライアント数に左右されるのと同様に、使用しているテクノロジーの影

響を受けます。

802.11nでは重要な進展がありましたが、最も要求の厳しい事例で必要となる条件をなんとか満たしたに過ぎず、最悪の場合には要求を下回ることがあります。すべてのデバイスで、2つ以上の空間ストリームやボンディングチャネルがサポートされたわけではありません。40 MHzのボンディングチャネルを使用できる機能では、すべてのユーザがラップトップだけを使用していなけ

れば、チャネル空間に無駄が発生しました。

そこで、802.11acによる進歩です。WFAの認定を受けるには、すべてのクライアントで最大 80MHzまでのチャネルをサポートする必要があり、条件が若干平準化されます。空間ストリームの機能は異なりますが、実装されているデバイスの規模と電力に一致する傾向があります。それぞ

れの空間ストリームには追加の無線が必要で、対応する電力の要件も依然として限定されますが、

可能となることが増えました。SSを1つしかサポートできないような比較的小さなエントリレベルのデバイスで設計する場合は、バッテリの効率と容量が、設計を左右する要素となります。し

かし、Wave 2として実装された規格に沿って、すべてのデバイスで拡大されたチャネル幅を活用すれば、同一 BSS内の個々のシングル空間ストリームデバイスとデュアル空間ストリームデバイスを同時に扱うことができ、Multiple-InputMultiple-Output（MU-MIMO）を実現できます。複数ユーザ、つまり、Multiple-Input Multiple-Outputによる無線通信により、空間ストリームの多様性を使用して、同じタイムブロック名の複数のシングル空間ストリームクライアントが使用できる

ようになります。大半のクライアントが 802.11acの無線規格でリリースされるようになったことで、通信時間の効率性を制御し、ほんの数年前には不可能だった大きな性能の向上が得られる、

またとない好機が訪れました。



ほとんどの環境で、最低限の 802.11nのクライアントサポートですら非常に大変なものでした。そしてさらに、それ以外のレガシークライアントが残っています。それらの大半は、スキャナ、

プリンタなどの特定のデバイス用のアプリケーションや小売業や流通業向けに構築された業界独

自のタスク用デバイスに限定されます。BYODにより、ユーザを継続的な更新サイクルに巻き込むことで、ユーザが最新のテクノロジートレンドについていくことが可能となりました。もし、

依然としてレガシークライアントに頼った実装となっているのなら、実施可能となり次第、これ

らのデバイスを更新するべきです。新しいテクノロジーが後方互換性を実現している一方、レガ

シークライアントはより多くの通信時間と、スペクトルの浪費の大きな要因となります。なおも

動作はします。ただ、古い非効率な無線通信と設計をサポートしても、現在の仕様における利点

のほとんどは享受することができないでしょう。ほとんどのユーザの場合、こうした状況に関連

するのは 802.11nで、新しい状況は好ましいはずです。802.11nと 802.11acの混在環境には、非常に大きな能力があり、適切に設計すれば広範囲にわたる要件を満たした上で、クライアントのニー

ズに応えられます。

もちろん、すべての人に同じ使用例を想定しているわけではありません。RRMでは、潜在的なRFの問題の把握がユーザにとって負担とならないよう、今日の複数の使用例に合致させられる柔軟な設計になっています。RRMは、RFプロファイルの使用により、複数の利用形態にインテリジェントに適用できます。HDX（High Density Experience）の見出しには多くの機能を見つけることができますが、これらの機能はすべて、より広い条件下で、RRMがより適切に機能できるようにするためのものです。ユーザのアーキテクチャの管理に適用できるよう、本書の中でも一部に

ついて触れていますが、これらの機能に関する完全なドキュメントについては、『HDX HighDensityExperience deployment guide』を参照してください。また、『AirTimeFairness (ATF) deploymentguide』も参照してください。導入時の複数の役割に対して通信時間の公平性（ATF：Air TimeFairness）を確保する上で実装できる、追加的な保護について説明しています。

RRMに関する問題の大半は、特定のサイトのアプリケーションに利用される APもしくはチャネルが多すぎるか十分でないかのいずれかを原因としています。また、ここ数年の RFに関する障害レポートは、ほとんどが 2.4 GHz帯の飽和に関連しています。これは驚くべきことではありません。増大する密度が、たった 3つのチャネルで、チャネルの分離によって軽減されているのです。チャネルが 3つしかないために、これらのチャネルをより迅速に再利用する必要があり、同一チャネル干渉の起こる確率も高くなります。2.4 GHzは、今ではほとんどのWi-Fiユーザから価値のない帯域とみなされています。同様に、Wi-Fiを使用しない多くのデバイス、また実装の容易さや無線伝播時の電力特性が有利なことからこの帯域を使う IoTデバイスにとっても、あまり価値はありません。これらのデバイスには、通常はデータクライアントや音声クライアントと同じ

ような要件がないため、2.4GHzで問題なく機能します。ただ、これらのデバイスの使用頻度は増加しており、ほとんどのインフラストラクチャのユーザにとって、2.4GHzの必要性は低下し続けていくでしょう。

非常に近接した範囲の中で動作する無線通信の数には、上限があります。多くの新しいデバイス

がこの市場に参入していますが、RFの設計能力を超えることがありふれたものとなってきました。これが、最初に RRMの責任にされることもありますが、RRMで管理できるのは関連するリソースだけです。アーキテクチャや無線の導入に関しては、全体設計の一環として考慮される必

要があります。わずか 5年前に実施されたサイト調査であっても、現在のユーザのニーズが満たされていると想定するのは適切ではないと思われます。ただ、密度の割り当てと設計上の判断が、

今日の増大するネットワーク要件に見合うよう調節されれば、RRMは非常に適切な結果をもたらします。不十分な計画により、RRMは意図しない結果をもたらす可能性があります。診断や実装



http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-1/HDX-DG/b_hdx_dg_final.html


http://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Air_Time_Fairness_Phase1_and_Phase2_Deployment_Guide.html

http://www.cisco.com/c/en/us/td/docs/wireless/technology/mesh/8-2/b_Air_Time_Fairness_Phase1_and_Phase2_Deployment_Guide.html

を改善することにより、こうした情報がより明確に理解しやすくなり、あらゆるレベルの組織が

利用できるようになります。

このドキュメントは、アーキテクトや技術者に、RRMの決定理由や過程の詳細について提供することを狙いとしています。こうした点を把握することで、より良い設計上の判断や迅速な問題の

解決につながります。シスコの優れた RF性能に注力し続けることで、ユーザエクスペリエンスに継続的に価値をもたらすことができます。変化に対応してきた実績と先を見越した継続的な開

発により、RRMは、絶え間ない成長の必要性に対応する継続的な RFの管理において、その立場を確立しています。



第 2 章

Radio Resource Management の概念

RRMは、連携して包括的な管理ソリューションを実現するアルゴリズムの集合です。ここでは、以下の主要なアルゴリズムグループについて説明します。

• RFグループ化：RFグループリーダーとメンバーの決定を担うアルゴリズム

• FRA（フレキシブルラジオアサインメント）：重複したラジオリソースの特定および適切な Roleへのリソースの再割り当てを担う新しいアルゴリズム（厳密には、スロット 0にXOR無線を備えた 2800および 3800シリーズの APに適用可能）

• DCA：グローバルアルゴリズム（RFグループリーダーで実行）

• TPC：グローバルアルゴリズム（RFグループリーダーで実行）

• CHDM：ローカルアルゴリズム（個々のコントローラで実行）

RRMに加えて、特定のトラフィックタイプやクライアントタイプを管理する複数の機能があります。これらの機能はスペクトル効率を大幅に向上させ、RRMがユーザに優れたエクスペリエンスを提供するのを支援します。これらの機能については、アルゴリズムとの関連で説明しま

す。

RRMは次のような階層に体系化されています。

RFグループ名→ RFグループリーダー→ RFネイバーフッド

RFグループ名に対して複数の RFグループリーダーが存在することもあります（その場合は、少なくとも 2つ（2.4 GHz用と 5GHz用に必ず 1つずつ）が存在します）。RFグループリーダーは複数の RFネイバーフッドを管理します。

• 前提条件と想定対象者, 7 ページ

• 主な用語 , 8 ページ

前提条件と想定対象者読者に次の項目に関する詳細な知識があることを前提としています。


•一般的なWLAN/RFの設計時の考慮事項に関する知識および経験（CWNA認定の内容に相当する知識）

•ユニファイドワイヤレスアクセスに関する方法論とハードウェア

主な用語読者はシスコの RRMアルゴリズムに関して、このドキュメントで使用される次の用語を理解する必要があります。

1 信号：シスコの APまたは同一の RFグループ属する APから発信される RFを意味します。

2 干渉：シスコのネットワークに属していないWi-Fi信号（不正）。

3 ノイズ：802.11の信号として復調できないすべての信号。これには、802.11に準拠していない発信元（電子レンジや Bluetoothデバイスなど）からの信号や、発信元が 802.11に準拠していても、信号が受信側の感度のしきい値に達していなかったり、もしくは競合や干渉により信号

が破損したりしている場合が挙げられます。

4 dBm：RF信号の強度を対数表現であらわした絶対値。dBmはミリワットに直接関連づけられますが、ワイヤレスネットワーキングの分野によくみられる非常に小さな値の送出電力を容易

に表すものとして、一般的に使われます。

5 RSSI（受信信号強度インジケータ）：チャネルの信号強度を数値計測した絶対値。

6 ノイズフロア：周囲の RFのノイズレベル（dBmで表示される絶対値）。受信される信号がこのレベルを下回ると、信号が判別できなくなります。

7 SNR：ノイズフロアに対する信号強度の比率。この値は相対値で、デシベル（dB）などで測定されます。

8 RFグループ：RRMのインスタンスが設定される論理コンテナ。単一の RFネットワークに属するすべてのデバイスが、特定の RFグループのメンバーとして設定されます。

9 RFグループリーダー：RFグループのアルゴリズムを実行するデバイス。RFグループリーダーは、選出プロセスによって自動的に選択するか、場合によっては、設定によって手動で割

り当てることができます。2つ必要です。つまり 2.4 GHz、5GHzのスペクトル帯域ごとに 1つです。使用される規模と設備によっては、さらに多くを用意することもできます。

10 近隣 RF：-80 dBm以上で互いにヒアリング可能な同じ RFグループに属する APのグループ。これは RFのプロキシミティに基づく物理グループです。

11 TPC：伝送パワーコントロール（Transmit Power Control）は、RFグループ内のすべてのAPの伝送電力レベルを監視、制御する RRMアルゴリズムです。2つのバージョンがあります。それぞれに強みがあり、推奨事項とともに両方に触れています。

12 DCA：動的チャネル割り当て（Dynamic Channel Assignment）は、RFグループ内のすべてのAPの動作チャネルを選択するための RRMアルゴリズムです。

13 CHDM：カバレッジホール検出/軽減（Coverage Hole Detection andMitigation）は、カバレッジホールの検出アルゴリズム（CHD）とカバレッジホールの軽減アルゴリズム（CHM）から構


Radio Resource Management の概念主な用語

成されています。CHDで測定された内容に依存しており、最適化ローミングのHDX機能と内容が共通しています。

14 CM：コストメトリック（Cost Metric）。有効なチャネルスループットの可能性を評価するために、DCAによって使用されるメトリック。APの負荷、同一チャネル干渉、隣接チャネルの干渉、非Wi-Fi発信源による干渉を適切なメトリックにまとめたもの。

15 COF：カバレッジのオーバーラップ要因（CoverageOverlapFactor）。FRAアルゴリズムによって求められるもので、他の 2.4 GHz無線により、-67 dBmでカバーされるセルの割合を示します。

16 FRA：フレキシブルラジオアサインメント。フレキシブルラジオを管理する RRMアルゴリズムで、カバレッジの重複やカバレッジ要求と密度に基づくフレキシブルラジオの最適な動作

を決定します。

（注） • RRM（およびRFのグループ化）は、コントローラ間のモビリティ（およびモビリティのグループ化）とは別の機能です。最初のコントローラ設定ウィザードでは、RFグループとモビリティグループの両方の名前に、同じ ASCII文字列がデフォルトで割り当てられるようになっており、これが混乱の元です。これはセットアッププロセスを簡素化する

ためのものであり、後で変更が可能です。

•複数の論理RFグループリーダーが存在するのは正常なことです。あるコントローラ配下の APが、別のコントローラへの参加を支援するのは、その APが別のコントローラ配下のAPと互いに通信できる場合だけです。大規模なキャンパス環境では、小さな建物のクラスタが散らばっており、複数の近隣 RFが存在するのはきわめて正常なことです。

RRMは何を行っているか、またどのように機能するか。

RRMの概要は非常に簡単なものです。通信に関する情報のとりまとめや分析用の保存のために使用されるサービスのフレームワークです。各 APが環境内でリスニングに時間を費やし、さまざまな使用率の統計情報を収集します。収集された情報が、複数のアルゴリズムによって利用され

ます（wIDSや不正検出は、RRMアルゴリズムの対象外です）。各 APは、Neighbor DiscoveryProtocol（NDP）に基づき、ネイバーチャネルの状況に関する情報（負荷、干渉、ノイズ）を収集します。こうした情報は、RFグループ全体に対するRFグループリーダーによって収集され、RFドメイン構造の最初の決定と、近隣RFへのドメイン分割に使用されます。近隣RFとは、互いに通信可能な APのグループで、そのようなグループ内がまとめられて、チャネルや電力の計算が実施されます。

つまり、RFグループリーダーは、メンバーのコントローラから取得した情報を、RRMアルゴリズムに基づいて処理する専用のコントローラです。物理的に互いに十分近接しているAPのグループを最初に特定し、それらを近隣RFのグループとして組織します。また、RFグループリーダーは、チャネルや電力に関するRRMの設定内容のレポジトリでもあり、その設定内容が、RFグループのアルゴリズムの設定に使用されます。



第 3 章

RRM データ収集アクティビティ

• RRMデータ収集アクティビティ , 11 ページ

RRM データ収集アクティビティRRMプロセスは、RRM体系で使用するデータと共に、接続している APのチャネルと電力の選択を処理するためのデータを収集します。RRMが情報を取得する場所と方法を理解することは、アルゴリズムを理解する上で不可欠です。ここでは、監視タスクの設定方法と設定場所、および

それが運用環境でどのように変換されるかについて説明します。各RRMアルゴリズムに対して、使用されるデータおよびデータの使用方法をディスカッションで扱います。


監視するチャネルリストは、[Wireless] > [802.11a/b] > [RRM] >[General–Noise/Interference/Rogue/CleanAir Monitoring Channels]で設定します。

図 2：RRM の一般設定ダイアログ

選択できる監視対象は以下のとおりです。

1 [All Channels]：選択した無線でサポートされているすべてのチャネルで、RRMによるチャネルスキャンが実行されます。使用国で有効ではないチャネルも対象となります。（パッシブの

み）。

2 [Country Channels]：使用国内のデータチャネルでのみ、RRMによるチャネルスキャンが実行されます。これがデフォルトの設定です。

3 [DCA Channels]：DCAアルゴリズムによって定義されたチャネルセットでのみ、RRMによるチャネルスキャンが実行されます。デフォルトでは、使用国で有効なオーバーラップしない

チャネルすべてが対象となります。ただし、必要に応じて、DCAで使用されるチャネルセットを変更できます。

次の 2種類のオフチャネルイベントが定義されています。

1 [Passive Dwell]：不正行為の検出およびノイズと干渉のメトリック収集に使用されます。滞留時間は 50 msです。

2 [NeighborDiscoveryProtocolTx]：モニタ設定で定義されているすべてのチャネルからNDPメッセージを送信するために使用されます。


RRM データ収集アクティビティRRM データ収集アクティビティ

[Channel Scan Frequency ]（[Wireless] > [802.11a/b] > [RRM] > [General]）は 180秒（デフォルト値）です。つまり、すべてのチャネルの滞留を180秒以内に完了させる必要があります。したがって、[Monitor]リストでの選択により定義されたチャネルの数に応じて、滞留間隔が増減します。たとえば、次のような場合です。

• [Channel List] = [DCA]、スロット = 0（2.4 GHz）の場合、DCAは合計 3つのチャネルに対してチャネル 1、6、11を定義します。したがって、180（秒）/3（チャネル）= 60となり、APは 60秒ごとにオフチャネルになりリッスンします。

• UNii 2e対応の規制ドメイン（米国）で [Channel List] = [Country]、スロット = 1（5 GHz）の場合、22のチャネルが定義されるので、180（秒）/22（チャネル）= 8.18となり、APは 8秒ごとにオフチャネルになり、50 ms間リッスンします

同じページで [Neighbor Packet Frequency]も定義します。7.6以前のデフォルト値は 60秒です。つまり、60秒以内に、無線をオフチャネルにして、チャネル監視リストで定義されているチャネルごとに1つのNDPパケットを送信する必要があります。上記と同じ例（[ChannelList] = [Country]、スロット = 1（5 GHz））を使用した場合、60（秒）/21（チャネル）= 3秒となり、3秒ごとに、現在実行しているチャネル以外のチャネルに無線で NDPパケットを送信します。

8.0以降では、[Neighbor Packet Frequency]は 180秒に設定されます。これはオフチャネルの頻度と同じです。パケットの頻度は、今後のリリースで同時に廃棄される可能性があります。現在の

デフォルト値は180秒なので、上記と同様の計算を行うと180/21=8.57となります。したがって、9秒ごとに（オフチャネルにして）、チャネルあたり 1 NDPパケットが送信されます。NDPの機能の詳細については、「NeighborDiscoveryProtocol（NDP）」（16ページ）を参照してください。

[Channel Scan Interval]と [Neighbor Packet Frequency]はどちらもデフォルト値のままにしてください。[Monitoring Channels]リストは、デフォルトで [Country Channels]を使用するように設定されます。この設定はwIPS構成に最適です。ただし、wIPSが一番の関心事でない場合は、[DCA]チャネルを選択して、オフチャネルアクティビティの対象を使用チャネルだけに絞ることができま

す。



第 4 章

RF グループ化

RRM RFグループ化は RRMの中心的機能です。RFグループ化は、RFネットワーク内に 2つの管理ドメイン（管理および物理）の基盤を形成します。

•管理ドメイン：RRMが適切に動作するには、管理制御下にある APとコントローラを把握する必要があります。RFグループ名は、グループ内のすべてのコントローラと APによって共有されるアスキー文字列です。

•物理 RFドメイン：チャネル計画と電力設定を計算するには、RRMが APの RFロケーションと相互関係を認識していることが不可欠です。ネイバーメッセージングでは、特別なブ

ロードキャストメッセージで RFグループ名が使用されます。これにより、RFグループ内の APが相互に識別して、RFプロキシミティを測定できるようになります。さらに、この情報を使用して、RFグループ内に RFネイバーフッド（-80 dBmを上回る互いのネイバーメッセージを物理的に認識できる同じ RFグループに属する APのグループ）が形成されます。

各RFグループには、帯域ごとに 1つ以上のRFグループリーダーが必要です。RFグループリーダーは、以下を担う物理デバイスです。

•設定

•アクティブなアルゴリズムの実行

• RFグループデータとメトリックの収集および格納

802.11bと 802.11a（2.4および 5 GHz）の各バンドに 1ずつ、少なくとも 2つの RFグループリーダーがあります。異なる帯域の RFグループリーダーを同じ物理WLC上に共存させることができますが、多くの場合そのような共存は行われません。また、地理的多様性がある大規模システ

ムでは、帯域ごとに複数のグループリーダーが存在することも珍しくありません。

現在システムには、RFグループ化アルゴリズムに 2つのモードがあります。RFグループリーダーは、自動的に選択（レガシーモード）することもできますし、静的に割り当てることもで

きます。どちらの割り当て方法も、CUWNコードのバージョン 7.0で静的 RFグループ化が追加されたことよってオーバーホールされました。

• RFグループの形成方法 , 16 ページ


• Neighbor Discovery Protocol（NDP） , 17 ページ

• RFグループリーダーの選定 , 22 ページ

• RFグループの拡張性 , 27 ページ

• RFグループの後方互換性 , 29 ページ

• WSSI、WSM、WSM2モジュールと RRM , 29 ページ

• RFグループ化のトラブルシューティング , 30 ページ

RF グループの形成方法WLCが新しく初期化されると、WLCの IPアドレスとプライオリティコードを使用して一意のグループ IDを作成します。プライオリティコードは、コントローラモデルと階層型モデル作成の際の最大ライセンス数（ハードウェアの制限）に基づいて割り当てられます。また、最も処理能

力の高いコントローラに、GL（グループリーダー）のジョブが割り当てる際にも用いられます。グループ IDと RFグループ名の両方が、他のWLCや APへのメッセージの中で、それらを特定するために使用されます。RFグループ名が同じになっているデバイスは、同じ RFグループ内のメンバーとして相互運用が可能です。

現行のコントローラの階層は次のようになっています。

8500 > 7500 > vWLC（大）> 5520 > 5760 > WiSM2 > 5508 > vWLC（小）> 3850 > 2500

下のRFグループの拡張性番号と併せて、下の表 2：RRMの動作に必要なポートを参照してください。

（注）

リーダーの選択に際し、グループ IDを比較する場合、プライオリティコードがプライマリの基準となり、IPアドレスはセカンダリになります。たとえば、他の 3つのコントローラがあり、プライオリティコードが自身よりも高いかまたは同じであるコントローラがない場合は、自身がグ

ループリーダーになります。その 3つのコントローラのプライオリティコードがすべて自身と同じ場合は、IPアドレスの値が最も高いものが、GL Roleを獲得すると想定されます。

2台のWLCで 1つの RFグループを形成する場合には、OTA（Over The Air）コンポーネントと同様のインフラストラクチャがあります。

•各WLCは、ディストリビューションネットワーク上で互いに到達可能である必要があります

•さらに、他の APの -80 dBmを上回る NDPメッセージを受信できる APが、少なくとも 1台必要です

ディストリビューションネットワークは、UDPユニキャストで通信します。


RF グループ化RF グループの形成方法

表 2： RRM の動作に必要なポート

宛先ポート送信元ポート

12124(12125)12134(12135)RRMマネージャ 11b（11a）

12134(12135)12124(12125)RRMクライアント11b（11a）

OTAのコンポーネントは、Neighbor Discovery Protocolの 2つの機能に依存します。NDPと、オフチャネルメトリックの収集です。NDPをオフチャネル TXサイクルとして考え、オフチェネルメトリックの監視をオフチャネルRXサイクルとして考えます。NDPとモニタリングは共に、RFのグループ化と RRMを理解する上で重要です。したがって、深く掘り下げる前に次で詳細について説明します。

Neighbor Discovery Protocol（NDP）シスコの RRM実装において最も特徴的なことの 1つは、OTA（Over The Air）メッセージを使用し、大規模な導入においてでさえ、一元化された動作をすることです。それにより、ネットワー

ク上のシングルポイントから、すべての APとそれらの RFエクスペリエンスを監視して対応できるという利点があります。また、管理だけでなく、すべてのAPがRFグループや近隣の中で、他の APとどのように連携しているかが把握できます。これは業界で唯一のものです。他のほとんどの場合においては、分散型の方式で、エッジ部分のAPがAPごとに設定要素として実装されており、集中管理できるのはその設定要素のみです。

NeighborDiscovery Protocol（NDP）は、60秒ごともしくはより短い間隔で、すべてのAP、無線通信、チャネルに送信されます。NDPパケットは特別なブロードキャストメッセージで、各 APですべて受信され、チャネル上の無線通信が他の無線とどのように通信しているかを、すべて網羅

的に把握できます。また、AP間の実際の RFのパス損失も把握できます。

ネイバーメッセージは、特別なマルチキャストアドレスである 01:0B:85:00:00:00に送信され、次の条件で実行されます。

•チャネル/帯域に許可される最大電力

•帯域でサポートされる最低データレート

802.11bの場合、これは、1Mbpsに対しては電力レベル 1（一定の無線通信に対して常に最大電力が供給される）で送信され、6Mbpsに対しては 5 GHz無線通信で送信されることを意味します。この機能は無線機器のファームウェアにハードコードされており、ユーザで制御することはでき

ません。NDPの電力や変調が、ユーザの設定するデータレートや電力レベルによって変更されることはありません。

NDPのメッセージには、次の情報が含まれます。


RF グループ化Neighbor Discovery Protocol（NDP）

表 3： NDP パケットの内容

説明フィールド名

無線送信用のスロット ID無線識別子

送信側WLCの IPアドレスとプライオリティコード

グループ ID

RFグループ名から変換された認証用ハッシュハッシュ

送信側APの RRMグループリーダーの IPアドレス

IPアドレス

暗号化 NDPを使用していますか?暗号化?

NDPバージョンバージョン

送信側無線通信の動作チャネルAPチャネル

キーの長さ暗号化キー長

キー名暗号化キー名

NDPが送信されたチャネルメッセージチャネル

メッセージが送信された際の電力（dBm）メッセージ電力

無線送信時のアンテナパターンアンテナ

APが NDPメッセージを受信した場合：

•メッセージが、RFグループ（ハッシュ）のメンバーからのものであることを検証（ドロップされていない場合）

•有効なものであった場合は、受信チャネルとコントローラまでの RSSIに応じてメッセージを転送

転送メッセージは、RFグループリーダーに対して定期的に順次転送され、ネイバーデータベースに追加されます。各APでは、それぞれの無線通信ごとに、RSSIの降順に基づいて、最大 34のネイバーを保存できます。

この情報の後処理に関連して、2つの異なる方法が編み出されています。

• RXネイバー：他の APからの通信の受信方法

• TXネイバー：他の APへの通信の送信方法



コントローラのネイバーのエントリは、コードリリースごとによって異なるデフォルト間隔でプ

ルーニングされます。8.0より前では、プルーニング間隔は 60分に固定されています。8.0では、15分間にハードコードされています。8.1以降では、[Neighbor Timeout Factor]という新しい機能があります。ワイヤレス機器の GUI上で、[802.11a/802.11b] > [RRM] > [General]と進んでください。

[Neighbor Timeout Factor]により、コントローラのネイバーリストをどれくらいの期間維持するかを、ユーザが直接設定することができるようになります。

[Neighbor Timeout Factor]は、[Neighbor Packet Frequency]（秒）に適用される乗数です。つまり、NTF x NPF =プルーニング間隔（秒）となります。上記の例では、[Neighbor Packet Frequency]が180秒で、[Neighbor Timeout Factor]が 5です。したがって、5 x 180 = 900秒/15分（デフォルト設定）となります。



15分はWLCバージョン 8.0以降のデフォルトプルーニング間隔です。ほとんどの導入で、これで問題ありません。高い負荷が長時間続く状況下（高クライアント密度、チャネル使用率が

常に 60 %以上）、もしくは多数のネイバー干渉の生じる環境においては、確実にネイバーの解決を安定させるには、これでも不十分である可能性があります。DCAサイクル（デフォルトは 10分）の中で、NDPが変更される場合、チャネル変更が増加します。APのネイバーが変更される場合、DCAは新しい数式に別の応答を提供します。[Neighbor Timeout Factor]を 20へ変更すると、以前の古い間隔である 3600秒（1時間）に戻ります。

（注）

ネイバーのプルーニング間隔は、ネイバー情報の表示や使用に関係するすべての安定性に影響し

ます。Cisco PRIMEのマップや、自動 RF出力の表示に、ネイバーリストが使用されます。NDPは無線インターフェイスで送信されるパケットで、オフチャネル伝送が中断されている場合は、

チャネルに戻り、オフチャネルTxを再開するまで、180秒（デフォルト値、これ以上は長くするべきではありません）待機します。過密なネットワークでチャネル使用率が高く SNRが低い場合、NDPの送信の必要となる機会が少なくなります。直近の100ミリ秒内で、音声QOSのキューにトラフィックが存在する場合はいつでも、Voice SSIDがオフチャネルアクティビティを延期します。期間を超えて履歴情報を保持する場合、短期間の不一致は補正されます。

これは、パフォーマンスのモニタリングにおいては、何を意味するでしょうか。無線機器の管理

者が無効となっているか、切断されている場合、その無線機器はNDPのプルーニング間隔の開始までネイバーリストに存在し、間隔が終了するまですべてのリストとレポートが確認できます。

新しいネイバーがリストに確認された場合は、リストがすべて書き込まれ、新しいネイバーの提

供する内容を取り込むために、全体が更新されます。

これが何を意味するか説明します。つまり、変更する必要がなければ、デフォルトの値のままに

する必要があるということです。また、15分を超える変更は可能ですが、15分より短くする変更は避ける必要があります。また、間隔を長く設定する必要があるのは、次のような時です。7.xから 8.xにアップグレードし、安定稼動状態に達した後で、チャネル変更において明らかな増加が確認された場合（新たな帯域幅の変更がなく、DBSが追加され、DCAスタートアップが動作していない）は、[Neighbor Timeout Factor]を、「自環境」の正常な運用が確認できるまで、5（5を追加するごとに 15分増えます）ずつ増加させてください。

パケットキャプチャツールを使用して、マルチキャストアドレス 01:0B:85:00:00:00をフィルタリングすることで、無線中のネイバーメッセージを確認することができます。

図 3： NDP メッセージングのサンプルパケットキャプチャ



パケットのキャプチャに APスニファモードを使用していないと、キャプチャツール内で確認できるRSSI値が、ネイバーリストに記録される内容と異なる可能性があります。また、ネイバーリストのエントリが、送信できるエントリよりも相当多くなる場合があります。これ

は、APの無線感度や位置（天井）が、一般にモバイルツールに好都合なためです。

注意

NDP と DFSNDPは監視チャネルのリストで選択されたすべての規制チャネルで送信されます。ただし、DFSチャネルはDFSチャネルで伝送するための特殊なケースについて説明するものであり、端末がマスターになるか、クライアントの場合は適法なマスターと直接連携している必要があります。マ

スターになるには、APがチャネルを 60秒間監視し、チャネルを送信する前に、レーダーが存在しないことを確認する必要があります。クライアントがDFSチャネル上でビーコンを受信することで、チャネルがマスターに所有されており、マスターに送信することを推測できます。自身が

DFS帯域のマスターでない場合に、DFS帯域内のチャネル上でNDPを送信するには、まずビーコンもしくはクライアントからの直接のプローブを受信して、チャネルをクリアなものとしてマー

クする必要があります。その後、5秒以内に、NDPパケットの送信を続けることができます。他の APがなく、他の DFSチャネルにもクライアントがなければ、自身がマスターであるチャネル以外の DFSチャネルでは、NDPが一切送信されません。

NDP の用途NDPは、展開内で遭遇するRF伝播ドメインや固有のパス損失を理解するための基礎となります。NDPは RRMにとってきわめて重要であるため、NDPが破損すると RRMが崩壊します。NDPは主に RFグループ化アルゴリズムによって使用されますが、以下によっても使用されます。

• TPC（伝送パワーコントロール）：NDPに対する 3番目のネイバーによる評価、またはTPCv2などでの計算の基礎

• FRA（フレキシブルラジオアサインメント）：すべての APからの NDPメッセージがカバレッジオーバーラップファクタのベースになります。

•不正検出：NDPを送信しないAPや不可解なNDPを送信するAPは、不正と見なされます。

• CleanAirマージと PMAC機能：CleanAirは隣接関係を使用して、干渉報告が同じ干渉デバイスを完全に認識できるほど近い APから送信されたどうかを判断します。

• CMX：AP RFの距離とパス損失の測定

これらはすべて、RFでの相互関係における APの位置を詳細に把握する必要があります。また、NDPの動作も把握する必要があります。


RF グループ化NDP と DFS

システム内の複数の場所における隣接関係を表示するには、WLCで [Monitor] > [Access Points] >[802.11a/b] > [details] > [RX Neighbors Information]を選択します。

図 4： AP ごとの隣接関係の表示方法の例

または、コマンドラインで以下を入力します。(Cisco Controller) show ap auto-rf 802.11a/b {AP_Name}(Cisco Controller) show ap auto-rf 802.11-abgn {AP_Name} (for Flexible Radios)

RF グループリーダーの選定これまでコンポーネントについて説明してきました。ここでは、新しいコントローラが初期化さ

れ、RFグループが形成される際にどのようになるかについて説明します。自動グループ化につい


RF グループ化RF グループリーダーの選定

て概観した後、静的グループ化の割り当てとの相違を確認します。RRMステートマシンの初期化に関する下記のフローチャートをご覧ください。

図 5： RF グループ化プロセスのフローチャート

WLCが初めて初期化されたとき、そのWLCが認識するWLCは自身だけです。WLCはグループIDを生成し、当初はグループリーダーの役割を果たします。初期スタートアップの設定時に入力された RFグループ名を取得して、接続している APに渡し、APがネイバー文字列で使用できるようにします。この新しいリーダーは自身をメンバーとします。WLCは helloタイマーを初期化



し、把握している他のWLCへの送信を開始します。Helloメッセージは、RFグループ履歴に保存されているすべてのWLCに送信されるユニキャストです。自動グループ化の場合は、初期化直後、このリストは空です。静的設定の場合、リストは手動割り当てによって入力済みか、または

入力されます。

自動グループ化の場合、受信した OTA NDPメッセージには、送信元のWLCグループ IDと RFグループハッシュ、および送信元のRFグループリーダーの IPアドレスが含まれています。新しいWLCは受信したすべてのグループ IDを比較し、その結果、現在の値よりも大きい値を持つものがグループリーダーになります。RFグループ化が完了し、選択プロセスが終了します。RFグループのハートビートとして機能するグループリーダーから、10秒ごとに Helloメッセージを受信します。Helloメッセージの送信が停止すると、RFグループが変更され、選定プロセスが再び開始されたと見なされます。通常はこの時点で、Helloパケットの送信先となるWLCのリストが完成します。

グループリーダーが確定すると、そのグループリーダーにすべてのメンバーからネイバーリス

トが送信され、グループ内の APは RFネイバーフッド（RF電力とチャネルの合算が必要な近い範囲内にある APのグループ）を形成します。ネイバーフッドに属する別の APについては、-80dBm以上で送信された APネイバーメッセージを参照する必要があります。APをネイバーフッドに追加すると、-85dBm以上で送信されたネイバーメッセージを見る限り、そのAPはネイバーフッドの一部になります。-85dBmを下回るネイバーメッセージはすべて廃棄されます。ネイバーリストは、バージョン 8.0コードによって 60分ごとに消去されます。8.1では、ネイバー保持時間がスキャン間隔の5倍になるように調整されました（したがって、デフォルトの180秒の場合、ネイバーリストは 15分ごとに消去されます）。一貫して -85 dBmを下回る APは、ネイバーリストとネイバーフッドから消去されます。このようにして、同じ地域にある APグループが特定されます。

図 6： RF グループとネイバーの例



RFネイバーフッドは複数のコントローラにまたがることができ、また、単一のコントローラで複数のネイバーを制御することもできます。下記にその例を示します。

図 7： RF ネイバーフッドの構成例

RF グループ化自動モードRFグループ化のデフォルトモードは、RFグループを形成するレガシーな方式です。RFグループ化アルゴリズムの現在のステータスを表示したり、グループリーダーとメンバーの IDを知ることができます。また、RFグループリーダーのWLCについて、WLC上の現在グループに含まれているWLCと APの数を表示できます。


RF グループ化RF グループ化自動モード

[Wireless] > [802.11a/b] > [RRM] > [RF Grouping] > [Group Mode]

図 8： RF グループ化設定ダイアログ

静的 RF グループ化バージョン 7.0では、RFグループリーダーを選定するスタティック方式が導入されました。この方法を使用すると、より確定的な結果をグループ化プロセスにもたらすことができます。ここで

はグループ ID（WLCのプライオリティコードと IPアドレス）は必須ではありませんが、プライオリティコードがメンバーと比較されます。これによって、低容量のWLCが大容量のWLCのグループリーダーになることが回避されます。

2504をグループリーダーとして割り当てることはできず、5508をメンバーとして追加することもできません。

（注）

静的グループ化では、特定のWLCをスタティックリーダーとして指定し、管理対象のメンバーを手動で追加できます。メンバーは、自動モードで RRMの互換バージョンを実行している必要があります。スタティックリーダーを割り当てると、それにメンバーが割り当てられ、参加見込

みメンバーに特別な参加メッセージが送信されます。このメッセージは、自動機能を無効にして、

新しいグループリーダーの割り当てをメンバーに通知します。


RF グループ化静的 RF グループ化

[Wireless] > [802.11a/b] > [RRM] > [RF Grouping]で、以下を実行します。

図 9：静的および自動 RF グループ化の設定例

[Group Mode]を [leader]に変更して [Apply]をクリックすると、メンバー割り当てダイアログが開きます。メンバーを割り当てて選択が完了したら、再起動して、新しい割り当てに対するグルー

プリーダーの選定を再初期化します。メンバーを追加するには、参加見込みメンバーが自動グ

ループ化モードになっている必要があります。このモードになっていない場合、メンバーは自身

が自身のリーダーであると想定します。新しいグループリーダーコントローラは、最初のメン

バーとして自動的に追加されます。いつでもメンバーを手動で追加できます。RFグループを再起動すると、メンバーコントローラは 10分ほどで安定します。

スペクトラムにはルールがありません。つまり、5GHzは自動モード、2.4GHzは静的モードのままにしておくのが適切です。または、異なるコントローラで両方を静的モードにします。両方の

インターフェイスは異なる RFグループインスタンスであるため、制限はありません。ただし、これはいつでも該当する適切な提言ですが、シスコのベストプラクティスはシンプルな状態にし

ておくことです。

RF グループの拡張性RFグループの最大サイズは、コントローラのモデルおよび物理的に接続している APの数に応じて異なります。RFグループの最大サイズは、次のルールを使用して計算できます。RFグループには最大20台のWLCを含めることができ、記載されている最大数のAPを持つことができます。

表 4： WLC RF グループ化の階層と拡張性

RF グループごとの最大 AP 数最大 AP 数グループリーダー WLC

500752500

50050WLCM2

500503850

1000200vWLC（小）


RF グループ化RF グループの拡張性

RF グループごとの最大 AP 数最大 AP 数グループリーダー WLC

10005005508

300015005520

20001000WiSM2

200010005760

20002000vWLC（大）

600060007500

600060008500 /8540

RFグループサイズを超過してしまった場合はどうなるのか。これはよくある質問ですが、それですべてが終わるわけではありません。安心して、先をお読みください。

特定の RFグループの最大許容 AP数を超過してしまった場合は、APの参加によって超過状態になっているコントローラで、グループを分割し、同じRFグループ名を使用して新しいRFグループリーダーを作成します。このように説明すると実際よりも悪い印象を与えかねませんが、実際

には、RFグループリーダーを探して 1つの帯域に複数のリーダーが存在していることに気づくまで、大部分のユーザは通常、意識すらしません。

複数の RFグループが存在することの欠点は何でしょうか。設定の変更が必要になったときに対処すべき RFグループリーダーの数が増加します（デュアル無線 APを想定した場合、802.11aと802.11bの両方にグループリーダーが追加されます）。このことによって複雑さが増しますが、コントローラテンプレートと設定監査ツールを使用して簡単に対処できます。2つの異なる RFグループに属する 2つのAPは、同じRFグループ名の異なるハッシュを持っているので、互いをネイバーとして認識しません。そのため、どの APをどのコントローラに割り当てるかを計画することが重要になります。同じコントローラ上または同じ RFグループリーダーの下に共存するAPについて計画すること推奨します。

RFグループリーダーには RFグループの RRMグローバルパラメータが格納されており、新しいグループリーダーを作成した場合は、その新しいWLCの RRM設定によってグローバルグループ設定が制御されます。NCSまたは Prime Infrastructureの [Monitor] >[ RRM]で設定監査機能を利用していない場合は、新しいグループリーダーに異なる設定を指定することが可能です（最悪の

シナリオ）。これは、設定の不一致が著しい場合に混乱を招く可能性があります。ただし、設定

が一致している場合は、DCAと TPCによって境界がかなりシームレスに緩和されます。

ネットワークを計画する際には、以下の点に留意してください。

1 互いをネイバーとして認識できる距離（-80 dBm以上）にある APのグループは、同じ RFグループに含める必要があります。

2 複数のコントローラがある場合は、コントローラのRFグループなどに、APを地理的にグループ化します。設定によっては、グループリーダーとメンバーの静的割り当てが最適な方法とな

る場合もあります。


RF グループ化RF グループの拡張性

3 2つの多様な APグループの場合は、共通の 1つの APを参加させてネイバーフッドを形成することのみが必要です。

4 2つの APグループがごく少数の APによって結合している場合は、2番目の RFグループを作成して分割することができます。これにより、NDPメッセージでアドバタイズされる RFグループが変更され、2つのグループが分離されます。

RF グループの後方互換性バージョン 7.2で RFプロファイルが導入されました。これは、RRM動作の大きな変化を表します。APグループに割り当てられる RFプロファイルは、グローバルな RFグループとは異なる方法で設定できます。7.2以降のバージョンでは、古いバージョンの RFグループと互換性がありません。ほぼ同時期に、コンバージドアクセスが導入されましたが、機能パリティ（RFプロファイル）はすぐには実現されませんでした。異なるリリースの組み合わせ時の互換性については、

『Cisco Wireless Solutions Software Compatibility Matrix』の Inter Release Controller Mobilityテーブルを参照し、確認してください。また、注意事項を必ず確認してください。バージョン7.5からは、機能上の違いがありますが、すべて単一の RFグループ化に問題なく含めることができます。

WSSI、WSM、WSM2 モジュールと RRM3つのシリーズのAP（3600、3700、3800）を所有しており、モジュールを設置できる場合、追加されるすぐれた機能の 1つとして、監視専用の無線を含むワイヤレスセキュリティモジュールがあります。このモジュールには 2つのモデルがありますが、どちらも RRMに対して同様に動作します。これらは、モジュールに無線を供給するオフチャネル機能の負荷を軽減します。これに

より、供給対象のチャネルに引き続き無線を供給しながら、滞留の役割（オフチャネル、場所、

wIPS、CleanAir）に基づいて各チャネルでの滞留時間を増加できます。この負荷軽減はほとんどすべての状況で役立ちます。収集での滞留がより長く頻繁になり、収集するデータの精度がさら

に高まるからです。モジュールでは収集に固有の内部アンテナが使用され、アンテナパターンが

内部アンテナ APモデルと照合されます。

ただし、このアプローチの欠点は、高密度設計で外部指向性アンテナが使用されることです（ほ

とんどの無指向性パッチアンテナには問題がなく、このことは該当しません）。収集されるデー

タは、APとサービスインターフェイスで実際に観察されたものと一致した地上波の結果に基づきます。スタジアムアンテナを使用する高密度ソリューションでは、これは著しく異なります。

そのため、設計で使用されているアンテナに適したチャネル計画を実現するには、モジュールを

シャットダウンし、APのネイティブインターフェイスとアンテナにより地上波メトリックを収集して、適切なチャネルソリューションを作成する必要があります。これが完了すると DCAが停止し、モジュールは、チャネルと電力ソリューションに影響を与えることなく、引き続き利点

を活用できます。


RF グループ化RF グループの後方互換性

http://www.cisco.com/c/en/us/td/docs/wireless/compatibility/matrix/compatibility-matrix.html

RF グループ化のトラブルシューティング

RRM データの収集APレベルでのデータ収集は、debugコマンドを使用して表示できます。

debug capwap rm measurements：出力は一目瞭然です。このコマンドは、APでのさまざまなインターバルの間隔を比較する上で役立ちます。

AP44d3.ca42.30aa#deb capwap rm measurementsCAPWAP RM Measurements display debugging is onAP44d3.ca42.30aa#

*Jan 14 11:36:57.403: CAPWAP_RM: Timer expiry*Jan 14 11:36:57.403: CAPWAP_RM: Interference onchannel timer expired, slot 1, band 0*Jan 14 11:36:57.403: CAPWAP_RM: Starting rx activity timer slot 1 band 0*Jan 14 11:36:57.419: CAPWAP_RM: RRM measurement completed. Request 2003, slot 1 statusTUNED*Jan 14 11:36:57.483: CAPWAP_RM: RRM measurement completed. Request 2003, slot 1 statusSUCCESS*Jan 14 11:36:57.483: CAPWAP_RM: noise measurement channel 48 noise 93*Jan 14 11:37:06.355: CAPWAP_RM: Timer expiry*Jan 14 11:37:06.355: CAPWAP_RM: Interference onchannel timer expired, slot 1, band 0*Jan 14 11:37:06.355: CAPWAP_RM: Starting rx activity timer slot 1 band 0*Jan 14 11:37:06.423: CAPWAP_RM: RRM measurement completed. Request 2004, slot 1 statusTUNED*Jan 14 11:37:06.487: CAPWAP_RM: RRM measurement completed. Request 2004, slot 1 statusSUCCESS*Jan 14 11:37:06.487: CAPWAP_RM: noise measurement channel 52 noise 92*Jan 14 11:37:08.711: CAPWAP_RM: Timer expiry*Jan 14 11:37:08.711: CAPWAP_RM: Neighbor interval timer expired, slot 0, band 0*Jan 14 11:37:08.711: CAPWAP_RM: Scheduling neighbor request on ch index:*Jan 14 11:37:08.711: CAPWAP_RM: Sending neighbor packet #2 on channel 11 with power 1slot 0*Jan 14 11:37:08.823: CAPWAP_RM: Request id: 4011, slot: 0, status 1

特に APでのネイバーのアクティビティについて詳細を表示する場合：debug capwap rm neighbors*Jan 14 17:29:36.683: LWAPP NEIGHBOR: NDP Rx: From 64d9.8946.7fb0 RSSI[raw:norm:avg]=[-37:-39:-38] Channel [Srv:Tx]=[1 :6 ] TxPower [Srv:Tx]=[4 :22 ]

この debugコマンドは、ネイバーから受信した NDPに関するものです。

NDP RX from x.x.x.x RSSI (raw:norm:avg) = (n:n:n) Channel (Srv:Tx) SRV：送信元 APがクライアントにサービスを提供するチャネル。TX：メッセージが送信されたチャネル。TxPower (Srv:Tx)SRV：現在 APがクライアントにサービスを提供している電力（dBm単位）。Tx：NDPメッセージが送信された電力（dBm単位）。*Jan 14 17:29:37.007: LWAPP NEIGHBOR: NDP Tx: Channel [Srv:Tx]=[64 :64 ] TxPower [Srv:Tx]=[2:17 ]

NDP TX：NDPメッセージの送信元。channel (Srv:Tx) Srv：クライアントにサービスを提供しているチャネル。Tx：NDPメッセージを送信したチャネル。TxPower (Srv:Tx) Srv：クライアントにサービスを提供している電力（dBm単位）。Tx：メッセージを送信した電力（dBm単位）。*Jan 14 17:29:40.007: LWAPP NEIGHBOR: skipping chan 100; not clear for DFS*Jan 14 17:29:43.007: LWAPP NEIGHBOR: skipping chan 104; not clear for DFS*Jan 14 17:29:46.007: LWAPP NEIGHBOR: skipping chan 108; not clear for DFS

DFSの伝送に対してクリアされていないチャネル。*Jan 14 17:29:48.299: LWAPP NEIGHBOR: Updating existing neighbor 34a8.4eba.194f(1), rssi-51 on channel: 48 with encryption: 0


RF グループ化RF グループ化のトラブルシューティング

*Jan 14 17:29:48.299: LWAPP NEIGHBOR: Neighbor update 34a8.4eba.194f(avg -45), new rssi-45, channel 48

ネイバー情報の変更に関する更新がコントローラに送信され、最終的に RFグループリーダーに送信される。

ネイバーメッセージングの問題は簡単に検出できます。NDPが破損している場合、隣り合っている APに隣接関係はありません。

RF グループ化の問題多くの場合、RFグループに関する問題の原因は単に互換性に関係しています。バージョン 7.0コードと静的グループ化の導入以降、RRMとその動作の仕組みに多くの変更が加えられました。可能な場合は後方互換性が維持されますが、それらの変更の一部については、実装するために

RRMヘッダーでの変更が必要です。また、グループ化する際にヘッダーのバージョン番号がチェックされます。

RRMヘッダーのバージョン 30.0はバージョン 7.0で使用され、リリース 7.2および RFプロファイルではバージョン 30.1が導入されました。7.3ではRFプロファイルにさらに多くの構造が追加され、コンバージドアクセスアーキテクチャの導入や、ヘッダーバージョンの 30.2への変更も行われました。当面は、これが必要な最終変更となります。

表 5： IRCM RRM の互換性マトリクスの抜粋

7.4.x.xCA10.17.3.x.x7.2.x.x7.0x.x6.0x5.1x5.0x4.2xCUWNサービス

-2-3-2-1XX––XRadioResourceManagement（RRM）

（注） 1 リリース 7.2.x.xでは、RFグループとプロファイルが導入されました。リリース 7.2.x.x以降の RRMは、以前のリリースの RRMと互換性がありません。

2 リリース 7.3.x.xでは RFプロファイルに変更が加えられ、7.2との後方互換性がなくなりました。

3 CA 10.1リリースは 7.3.101.0で RFグループを形成しますが、RFプロファイルに対するサポートはありません。

「sh advanced 802.11a/b group」コマンドを使用して、コントローラのRFグループ化機能を確認できます。

(controller) > show advanced 802.11b groupRadio RF Grouping802.11b Group Mode............................. STATIC802.11b Group Update Interval.................. 600 seconds802.11b Group Leader....................... GRP_Leader (1.2.3.4)


RF グループ化RF グループ化の問題

802.11b Group Member..................... GRP_Member (1.2.3.4)802.11b Group Member..................... GRP_Member (1.2.3.5)

802.11b Last Run............................... 594 seconds ago

[Wireless] > [802.11a/b] > [RRM] > [RF Grouping]を使用して、WLCGUIで以下のステータスを確認できます。

図 10： WLC GUI の RF グループ化情報

自動 RFグループ化において、RFグループ内に存在しているはずのWLCが何らかの形でグループに参加していない場合は、次のいずれかの原因が該当します。

• RFグループのサイズが許容量を超えている

• WLCに割り当てられている RFグループ名が異なっている

• Helloメッセージのネットワークパスがない

静的 RFグループ化で、割り当て済みのメンバーが静的に割り当てられたグループリーダーに参加していない場合、最も一般的な原因はバージョンの互換性です。RFグループ名とコントローラ階層は評価するリストの最上位にあります。

WLCコンソールでの有用なデバッグ

• debug airwave-director error：RRMと RFグループ化のすべてのエラーを表示します。



• debug airwave-director group：定常状態のネットワークにおけるRFグループ化アクティビティを表示します。これは、RFグループがサイズと隣接関係の条件を満たしていることを確認する分割の計算と同じです。

[Wireless] > [802.11a/b] > [RRM] > [RF Grouping]メニューでリセットボタンをクリックすると、再グループ化を実行できます。

RFグループ形成の監視*emWeb: Jan 16 18:46:49.717: Airewave Director: Group 802.11bg attempting to remove entryC0.A8.0A.14.00.4B, IP Addr 192.168.10.20*emWeb: Jan 16 18:46:49.717: Airewave Director: removing entry C0.A8.0A.14.00.4B from802.11bg group*emWeb: Jan 16 18:46:49.719: Airewave Director: Group 802.11bg attempting to remove entryC0.A8.0A.1E.00.32, IP Addr 192.168.10.30*emWeb: Jan 16 18:46:49.719: Airewave Director: removing entry C0.A8.0A.1E.00.32 from802.11bg group

現在のメンバーの削除

*RRM-MGR-2_4: Jan 16 18:46:49.746: Airewave Director: adding entry C0.A8.0A.08.01.F4 (500)to 802.11bg group

自身をメンバーとして追加している現在のグループリーダー

*RRM-MGR-2_4: Jan 16 18:49:03.614: Airewave Director: Group received Join Request from802.11bg group C0.A8.0A.14.00.4B(63131),IP addr 192.168.10.20

RFグループリーダーが参加要求を受信*RRM-MGR-2_4: Jan 16 18:49:03.614: Airewave Director: Deny join request from IP addr192.168.10.20 to 802.11bg group C0.A8.0A.14.00.4B(63131)with reason Non matching group ID

グループ IDの不一致により、参加を拒否*RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: Group received Join Request from802.11bg group C0.A8.0A.14.00.4B(63131),IP addr 192.168.10.20

2番目の参加要求を受信*RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: Member in join request from sourceIP addr 192.168.10.20 to 802.11bg group, memberIP 192.168.10.20our Id 500 srcType 75*RRM-MGR-2_4: Jan 16 18:51:07.651: Airewave Director: adding entry C0.A8.0A.14.00.4B (75)to 802.11bg group

要求が承認され、グループにそのWLCを追加*RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: Group received Join Request from802.11bg group C0.A8.0A.1E.00.32(63131),IP addr 192.168.10.30

2番目のWLCが参加要求を送信*RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: Member in join request from sourceIP addr 192.168.10.30 to 802.11bg group, memberIP 192.168.10.30our Id 500 srcType 50*RRM-MGR-2_4: Jan 16 18:56:59.958: Airewave Director: adding entry C0.A8.0A.1E.00.32 (50)to 802.11bg group

それをグループに追加（完了）

*RRM-MGR-2_4-GRP: Jan 16 18:57:20.909: Airewave Director: prep to join 802.11bg groupC0.A8.0A.65.03.E8(63126) due to rssi -8*RRM-MGR-2_4: Jan 16 18:57:36.839: Airewave Director: Group 802.11bg attempting to joingroup IP Address 192.168.10.101, ctrl count 3



次に、グループリーダーは、グループ IDの値がより高く、コントローラ数が 3（グループリーダーと新たに追加された 2台）の別のWLCへの参加を試みます。*RRM-MGR-2_4: Jan 16 18:57:36.857: Airewave Director: Group received join failure from802.11bg C0.A8.0A.65.03.E8(63126) (192.168.10.101)for reasonNot a configured static member*RRM-MGR-2_4: Jan 16 18:57:36.857: Airewave Director: Group validated join failure from802.11bg C0.A8.0A.65.03.E8(63126) for reason Not a configuredstatic member

しかし、アクセスは拒否されます。192.168.10.101は静的グループリーダーとして設定されており、当該グループはそのグループのメンバーとして設定されていないからです。

理由コードの概要

1 Invalid IP：コントローラ IPが無効、またはコントローラのシステム名と一致しないことを示しています。

2 GroupSizeexceeded：APの数または追加されたメンバーコントローラの数が原因で、リーダーコントローラの動作限界に達した場合、リーダーはそれ以上のコントローラの追加を拒否し、

拒否の理由を表示します。

3 InvalidGrouporder：メモリ破損などの原因によってグループ化の順序がグループが形成された方法と異なる場合、伝送中にデータ構造が破損した場合、または未知のコントローラタイプが

参加を試みた場合に、このエラーメッセージが表示されます。

4 Source Not Included：送信元 IDが無効。

5 Weak Signal Strength：最も近いネイバーとの距離が遠すぎる場合（静的 RFグループ化には該当しない）。

6 Join Pending：メンバーコントローラがメンバーとして参加できるときに、完了して別の RRMステータスに移行するのを待機している場合。

7 Not a Manager：想定外のシナリオ。誤って RFグループメンバーが RFリーダーとして確認応答を受けた場合。

8 RRM Assigning：進行中

9 Grouping disabled：設定されたメンバーで RFグループ化が「OFF」になっている場合。

10 Invalid ProtocolVersion：RFメンバーコントローラのイメージが非互換バージョンである場合、またはバージョンの不一致がある場合。

11 Country code mismatch：設定されている国コードの不一致

12 Invalid hierarchy：優先順位が下位のコントローラが上位コントローラの追加を試みている場合。

13 Already a static leader：静的リーダーとして手動で設定済みのメンバーの追加を試みた場合。

14 Already StaticMember：他のRFリーダーの静的メンバーとして承認されているメンバーの追加を試みた場合。

15 Non-Static Member：


RF グループ化理由コードの概要

16 Not Intended：

17 Member Deletion Error：エラーの発生が、割り当て解除の不適切なメモリ割り当てに起因すると明確に判明している場合。

18 RF-domainmismatch：設定されているメンバーとRFリーダーのRFドメインが異なっている場合。

19 Split for invalid-state request：予期しない RRMの状態遷移によってメンバーが分割された場合のエラー状態。

20 Transitioning to static from auto：自動から静的ステータスに移行中。

21 Split due to user action：国コードやシステム名などの変更中に、ユーザによるリセットで遷移が引き起こされた場合。

22 Switch Size Exceeded：



第 5 章

フレキシブルラジオアサインメント（FRA）と重複したラジオ

FRAは何を行うか。

シスコのフレキシブルラジオアーキテクチャは、Cisco AP 3800/2800でリリースされたハードウェアを使用するために、8.2MR1で導入された新機能です。FRAは、NDPの測定値を分析するために、RRMに追加された新しいコアアルゴリズムで、新しいフレキシブルラジオ（2.4GHz、5 GHz、モニター）がネットワークで果たす役割を決定するために使われるハードウェアを制御します。多くの新しい機能と既存の機能が RRMに統合されており、それらについてすべてここで説明します。

説明の前に、デュアルバンドラジオについて触れます。デュアルバンドラジオは、フレキシブ

ルAPハードウェアアーキテクチャを作成する新しい製品コンセプトです。従来のレガシーデュアルバンドAPでは、常にラジオスロットが 2つあり、周波数帯ごとに 1つ割り当てられています。割り当てられた周波数帯は、次のようにサービスされます。スロット0=802.11b、g、n。スロット 1 = 802.11a、n、ac。デュアルバンド（XOR）ラジオは、2.4 GHz帯の利用、5 GHz帯の利用、もしくは同一 AP上での両周波数帯の受動的な監視の機能を提供します。提供される APモデルは、専用のマクロ/マイクロアーキテクチャをサポートする Iモデルとマクロ/マクロをサポートする Eおよび Pモデルを使用してデュアル 5 GHzの動作に対応できるように設計されています。これについては後ほど詳しく説明します。現時点では、対象となる使用用途向けにそれぞれ

別個に設計されたモデルが提供されていることを把握してください。

シスコの FRAでは、次の 3点が行われます。

• 2.4 Ghzラジオの重複性の測定値の計算や維持を行い、COF（Coverage Overlap Factor）と呼ばれる新しい測定メトリックとして示す

•重複インターフェイスとして設定されているインターフェイスの再割り当て、またはラジオの役割の割り当ての管理

•マクロ/マイクロの実装（2800/3800 Iモデル）向けに FRA管理クライアントのデュアル 5GHzインターフェイス間のロードバランシング（マクロ/マイクロ遷移）

詳細説明に入る前に、いくつかの名称変更を理解する必要があります。FRAは既存のRRMと緊密に統合され、レガシーAPとの混在環境で動作する必要があります。新しい運用を明確に理解


するために、概念的に取り上げるべき新しい命名規則と動作があります。APのモード（Mode）は既存の概念ですが、何点かの変更が入りました。今までの APのモード（Mode）選択では、AP（スロット 0およびスロット 1）を複数の動作モードのうちから 1つに設定します。

• Local Mode

• Monitor Mode

• Flex Connect Mode

• Sniffer Mode

• Spectrum Connect Mode

新しいFRAアーキテクチャの下でも、これらの「APのモード（Mode）」が依然として存在し、従来どおり機能しています。しかし APのモード（Mode）を変更すると、変更が AP（スロット1およびスロット）だけでなく、スロット 0だけに適用できることがあります。これは、2800および 3800APでの変更です。スロット 0の位置にフレキシブル（XOR）ラジオを追加することによって、以前のAP全体のモードからスロット 0の単一のラジオインターフェイスのみに動作させるRole機能を得ました。もはやすべてのAPにモードを設定する必要はありません。この概念をスロット 0の単一のラジオインターフェイスレベルで適用するために、ロール（Role）という概念が導入されました。なお、製品リリースの時点で割り当てられる3つのRoleがあります。

• Client Serving

◦ 2.4 GHz（1）または 5 GHz（2）

• Monitor - Monitor Mode（3）

Client Servingは Local Modeと同じです。選択された周波数帯でクライアントをサポートします。Client Servingというロール（Role）に変更することは FCS後にもサポートされます。FlexConnectModeがロール（Role）としてサポートされる際には、FlexConnectAP全体が選択される必要のあったものが、ローカルおよびリモートインターフェイスという用語を使って置き

換えられるようになり、ClientServingのロール（Role）に統合されます。注意の必要な内容は次のとおりです。

（注）

•「モード（Mode）」は、AP全体（スロット 0および 1）に割り当てられます

•「ロール（Role）」は、単一のラジオインターフェイス（スロット0）に割り当てられます。

• FRA：カバレッジオーバーラップファクタ（COF） , 39 ページ

• FRA：無線 Roleの割り当て, 43 ページ

• FRA：クライアントネットワーク優先度, 45 ページ

• FRA：定常状態動作, 47 ページ

• FRA：トラブルシューティング, 50 ページ


フレキシブルラジオアサインメント（FRA）と重複したラジオ

FRA：カバレッジオーバーラップファクタ（COF）ここでは、動作理論と FRAの実際の動作について少し詳しく説明します。まず、FRAは 2.4 GHzカバレッジだけを評価し、干渉を発生させるカバレッジの重複があるかどうかを判別します。AP3800/2800は、レガシーの APと同様に、1つの 2.4 GHzラジオインターフェイスと 1つの5 GHzラジオインターフェイスが初期値として設定されています。FRAが分析を完了すると、重複であると判断されたラジオには、ネットワークの目標をサポートする上でより有益な役割が割り当て

られます。

（注） •ここでは、動作理論と FRAの実際の動作について少し詳しく説明します。まず、FRAは2.4GHzカバレッジだけを評価し、干渉を発生させるカバレッジの重複があるかどうかを判別します。AP 3800/2800は、レガシーの APと同様に、1 X 2.4 GHzのインターフェイスと 5 X GHzのインターフェイスをデフォルトで初期化します。FRAが分析を完了すると、重複であると判断された無線には、ネットワークの目標をサポートする上でより有

益な役割が割り当てられます。

• SSIDの割り当てを管理するために APグループを使用しているお客様は、異なる APグループをサポートする同一のエリアで、APを混在させていることがあります。FRAはこのようなシナリオに基づいて入念に評価される必要があります。マニュアルモードのAPを使用して、非連続にグループ化がなされている場合の COFの正確性を評価します。これは完全なカバレッジを評価する上で適切な方法です。しかし、SSIDが 1台の APだけに追加されている場合は、追加または単一の SSIDで、その 1台のAPの代わりとなるAPがありません。

FRAは、確立した Neighbor Discovery Protocolの RPMからの出力を RFの間隔における各ラジオの位置を特定するのに使用し、セルごとに重複するカバレッジを評価します。最初に、APからのNDPの測定値を使用して、FRAはソリューションセット（APグループ、物理ネイバー）に含まれる、他のすべての APに関連する X Y座標を描画します。各セルの円周は、各 APのその時点の送信電力レベルに基づいて計算されます。これにより、APのカバレッジの重複部分に関する論理マトリックスが作成されます。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：カバレッジオーバーラップファクタ（COF）

この情報に基づいて、FRAがマルチポイント分析を使用し、それぞれの評価対象の APごとに重複しているカバレッジの割合を判定します。

この計算による出力結果が COF（Coverage Overlap Factor %）です。Coverage Overlap Factorは、-67 dBmもしくはそれより高い RSSI（受信信号強度）（既存の動作中の無線通信に使われる）で



カバーされる分析対象のセルの割合です。このカバレッジの計算の過程において、FRAは他の無線のCOFの範囲へ影響を及ぼしている無線通信の経過を記録し、重複とマークされた無線が影響を及ぼしている間は、その無線通信を許可しません。すべての無線が -80dBm（システム最小値）を上回る RSSI（受信信号感度）で NDPを送信していることが、FRAで確認される場合、その計算には、最も RSSI（受信信号感度）の高い 4つのネイバーのみが使われます。

8.2MR1および 8.3では、COFで評価されるのは、2.4 GHz無線のみです。無線に重複のマークがつけられた場合、別の Roleを割り当てることができます。無線が別の Roleに遷移すると、評価の計算された範囲では、もはや 2.4 GHzで動作しなくなることから、その無線の COFは最終的に利用できなくなります。

（注）

RRMや FRAでは Prime Infrastructureのようにマップに関する情報を保持していません。そのため、カバレッジの外側を意味する壁、つまりカバレッジエリア境界の概念などを利用し、これは

FRAの結果とは関連がありません。NDPが既知の電力レベルで送られる場合の RFの距離については実際の情報が把握されており、受信したパケットは実際のRSSIで報告されることから、障害物の存在はすべて RFの範囲として表示されます。この点を理解しておくのが重要です。COFが示しているのは、理論上の 360度のセルのカバレッジなのです。

APが広い部屋の中央に位置している場合、カバレッジの推測値と、COFの報告する内容はほぼ合致します。APが 8階の長い廊下の外の壁に配置されており、外側までカバーできているか考慮する必要がなければ、まだCOFを使って評価することができます。ただし、必要とされる実際のカバレッジエリアについては、見込みを調整してください。次を参照してください。

上記の例では、4台のAPが廊下や似た特徴をもった建築物内で、互い違いの状態で設置されています。これらの APでは、いずれも 100 %の COFは確認できません。理由は以下です。

• AP 1と AP 3は、AP 2で計算されたセルカバレッジの約 60 %だけを対象としています

• AP 2と AP 4も、AP 3で計算されたセルの約 60 %だけを対象としてます

図の中に引かれた線が把握される外側の壁を示しており、この線の内側に関しては、各 APに必要なカバレッジが明らかとなります。各 APは、計算されたカバレッジの約 30 %を使用して、実際に必要なカバレッジエリアを提供しています。COFをガイダンスとして使用し、ローカルの情



報と組み合わせることで、適切な意思決定を下すことができます。AP2とAP4で必要なカバレッジエリアの約 95%を占めているため、AP 3については、他のRoleに変更するべきでしょう。AP1と AP 4は中心からはずれていますが、この特定の廊下により多くのアクセスポイントが配置されれば、より多くの APが重複するのは明らかです。そして、これをガイダンスとして実施することが必要となります。

もう1つの例は、APが外部の壁に設置される企業向けロケーションでの設計です。やはり、これらの壁を越えるカバレッジを考慮する必要はないと思われます。壁の外のカバレッジについても

考慮する場合は、そのままにしておくか、屋外向けのAPを検討します。屋外向けのAPを使わない、もしくは COFが 90 %から 100 %のカバーを示さない場合でも心配はありません。COFが 65%を示しているセルの 50 %だけが必要だということが分かっているのであれば、新しい Roleを手動で割り当てる前に、簡単に二、三の測定を行うべきです。

計算されたカバレッジがFRAの感度のしきい値に一致もしくは超える場合に、無線が重複とマークされます。

• Low：COF 100 %

• Medium：COF 95 %

• High：COF 90 %

アルゴリズムを有効にする前に、すべてのFRA対応 APを FRAの手動モードで設定することを推奨します。これにより、テスト中やコマンドの設定作業中に、無線が再割り当てされるこ

とを防ぎます。

（注）

FRAアルゴリズムを有効にする必要があります。FRAがすでに有効になっていなければ、有効にされるまでCOFが生成されることはありません。デフォルトで無効となっています。GUI上で、[Wireless] > [Advanced] > [Flexible Radio Assignment]に進んでください。CLIの場合は、configadvanced fra enable/disableです。



• FRAアルゴリズムを有効または無効にします。デフォルトでは無効になっています。

• FRAの感度のしきい値を調整します。ここで、無線を重複なものとして判断するために必要となる COFの割合を設定します。サポートされている値の範囲には、Low（100 %デフォルト）、Medium（95 %）、High（90 %）があります。

• FRAの実行間隔を設定します（1から 24時間の範囲の変更が有効です。DCAの間隔に一致もしくはそれ以上である必要があります）

FRAの実行間隔はデフォルトで1時間です。最大24時間まで選択できます。ただし、FRAはDCAに大きく依存しているため、FRAの間隔は、DCAの間隔を下回ることはできません。以下のRoleの割り当てを参照してください。

FRA：無線 Role の割り当て無線が重複とマークされた場合、次に何が行われるかは、ラジオの設定により決まります。フレ

キシブルラジオが割り当てられる動作状態は 2つあり、自動（デフォルト値）もしくは手動のいずれかとなります。自動の場合、ラジオはユーザの介入なしで計算されたCOFに基づいてFRA/DCAによって直接割り当てられます。手動の場合は、FRAはそのラジオ用のCOFで生成されますが、どのラジオに割り当てるかはユーザがすべて手動で制御します。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：無線 Role の割り当て

（注） • FRAの自動または手動の選択は、FRAのラジオへの割り当てにのみ適用されます。RRMでのチャネルと送信出力は別々であり、ユーザはこの 2つを混同しないようにする必要があります。自動と手動のいずれでも、ユーザはチャネルと送信出力のグローバルな割

り当て（RRM）や、カスタム設定（RRMなしの手動/カスタム割り当て）を使うことができます。

• 2802/3802モデルでは、5GHzモードで表示されるエラーメッセージがない場合には、100MHzチャネルの強制分離が適用できます。

「FRA - Auto」のラジオを使用して、FRAはその時点の重複しているラジオを「何」に使用するか決定するために、DCAを参照します。DCAのプライオリティはシンプルです。

1 5 GHzに重複しているラジオを割り当て、キャパシティの増加を図る

2 すでに 5 GHzのカバレッジが最大であることが DCAにより確定した場合は、そのように示された上で、代わりにMonitor Roleが割り当てられる

この計算結果は、「推奨モード」として、[Monitor] > [Access Points] > [Dual Band Radios]の下のGUIに表示されます。

FRA-Autoが選択されていない場合、推奨モードでは、ラジオが手動モードであることを示す（静的な）情報が報告されます。

（注）

Cisco Controller) >show advanced fra

FRA State........................................ EnabledFRA Sensitivity.................................. high (90)FAR Interval..................................... 1 Hour(s)Last Run....................................... 304 seconds agoLast Run Time.................................. 0 seconds

AP Name MAC Address Slot Current Band COF %Suggested Mode

-------------------------------- ----------------- ---- -------------- ---------------------------------3802_i.D9A0 58:ac:78:df:9c:20 0 2.4GHz 842.4GHz

AP00F2.8B26.89D0 00:f2:8b:26:ed:d0 0 2.4GHz 762.4GHz

3800_e_BC80 58:ac:78:df:7e:e0 0 2.4GHz 462.4GHz


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：無線 Role の割り当て

COF : Coverage Overlap Factor

フレキシブルラジオ用の推奨 Roleは次のとおりです。

• 2.4 GHz

• 5 GHz

• 5 GHz/Monitor

•ラジオの設定レベルで選択した手動割り当て（スタティック）

CiscoAP 2802/3802 eモデルおよび pモデルには、2番目のビルトインアンテナはありません。これらの APには、DARTコネクタと 2番目のアンテナが必要です。DARTコネクタが挿入されていない状態で、重複とマークされたモデルは、Role選択アルゴリズムを使用することができません。

（注）

FRA：クライアントネットワーク優先度これは、Roleの「推奨」に関わるものです。ただし、遷移がいつ実施されるかという点は、8.2MR1および 8.3のソフトウェアリリースのもう 1つの新しい機能であるクライアントネットワーク優先度によって管理されます。これは、ネットワークサービスに合わせた個別の調整機能と考

えてください。これにより、エンドユーザが RRMの動作をどのように優先順位付けするかを示すことができるようになります。FRAには次のようなエントリがあります。

デフォルトスループット接続RRM アルゴリズム

現行の DCAと同じ動作

現行チャネルでのより

低いバイアス

DCA用の高感度（DCAでの上書き）

全 11n対応クライアント

現行チャネルより高い

バイアス

DCA用の低感度（DCAでの上書き）

音声/ビデオの際は、現行チャネルを好む

DCA

現行のTPCと同じ動作クライアント数が設定

された最大しきい値を

超える場合、DTPCは電力を増加させない

弱い信号（-79未満）のクライアントが検出

された場合、DTPCは電力を低下させない

DTPC


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：クライアントネットワーク優先度

デフォルトスループット接続RRM アルゴリズム

現行のDBSと同じ動作より高いチャネル幅を

好む

大容量（11n、11ac）のクライアントタイプが

存在する場合により高

いバイアス

現行の帯域幅を好む

現行のプライマリチャ

ネルを好む

クライアントタイプで

より低いバイアス

音声/ビデオクライアントの使用割合を増加

DBS

現行の

FlexDFS/ED-RRMと同じ動作

より高い帯域幅のチャ

ネル幅を優先

プライマリチャネルの

維持を優先

音声/ビデオクライアントの使用割合を増加

FlexDFS/ED-RRM

connectivity profileに対するデフォルト

クライアントに関わら

ず、チャンネル幅を変

更

3台以上のクライアントが存在する場合、周

波数帯・Roleの変更なし

FRA

このコマンドは、今のところ CLIレベルだけです。しかし、さまざまなユーザが異なる動作を実行したい場合のプロセスのカスタマイズが可能となります。FRAのコンテキストの範囲内で、2.4GHzインターフェイスに接続されているクライアントが、5 GHzに変更された場合、何が起こるかを確認します。デフォルトを含め 3つのオプションがあり、基本的には顧客用にそのままの状態が残りますが、接続設定をデフォルトで使う FRAの場合は例外です。(Cisco Controller) >config/show advanced 802.11a/b client-network-preference ?

•接続：接続を優先

•デフォルト：クライアントネットワーク優先度を適用しない

•スループット：スループットを優先

この場合、ラジオは条件（接続するクライアントが 3台以下）に一致するまで Roleの変更を待機し、次のDCAの実行の際に変更を処理します。クライアントネットワーク優先度で「スループット」オプションを選択して、これをバイパスできます。

ラジオは、（CLIで）戻されるか、GUI/CLIで手動設定されるまで 2.4GHzには戻りません。自動反転は、カバレッジを使用する元のラジオでカバレッジホールアラートの出る状況でのみ発生し

ます。つまり、ラジオに別のRoleが設定された場合、カバレッジを使用しているラジオで代わりとなるRoleにカバレッジホールアラートの受信が許可されていると、フレキシブルラジオが 2.4GHzに即座に戻されます。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：クライアントネットワーク優先度

3802i APには、デュアルバンド用アンテナと5GHz用マイクロセルアンテナの 2セットがあります。3802iは、マクロ・マイクロセルとしてデュアル 5 Ghz、またはMonitorインターフェイスとして動作させるために特別に開発されたものです。詳細については別途記します。

（注）

3802の eモデルと pモデルには、外部アンテナアダプタが 1つあります。そのため、フレキシブルラジオのRoleをサポートするための内蔵の追加アンテナがありません。同じ周波数帯で同時に動作する 2つのラジオを、同じアンテナで使用することはできません。デュアル 5 GHzでの運用には、フレキシブル（スロット 0）ラジオ専用の 2番目のアンテナをサポートするための DARTコネクタが必要です。

APを標準デュアルバンド APとして扱う場合は、DARTコネクタは必要ありません。これはフレキシブルラジオ用のデュアル 5 GHzとMonitor Roleをサポートする場合にのみ必要となります。

（注）

これらの APはマクロ/マクロ、もしくは 2つのセルのフル利用をサポートするように設計されています。DARTコネクタのない場合は、 Roleの再割り当てをしないということができます。COFは表示されますが、サポートするハードウェアがない限り、別のRoleを割り当てることはできません。

FRA：定常状態動作FRAは初期リリースにおいて、2.4 GHzスペクトルでの過密状態を評価して修復するように設計されています。5 GHzで最適化するようにネットワークを設計している場合、多くの場合、2.4GHzインターフェイスでは重複が発生します。また、重複している無線の選択、遷移、割り当てが管理されます。

いったん動作し始めると、ネットワーク設計や AP数は変更されないものと仮定され、監視以外で FRAが行うことは多くはありません。2.4 GHzの Roleに含まれていない APが、COFで表示されていなくても、 Role選択の部分と DCAはアクティブのままであることに留意してください。つまり、APを追加したり、使用する帯域幅を変更したりする場合、5GHzが割り当てられていないと、FRAがフレキシブルラジオに異なる Roleを選択する可能性があり、複数の稼働中のインターフェイスの安定を保つことが難しくなるということです。5GHzインターフェイスが、MonitorModeに変更される可能性があります。これを防止する確実な方法は、手動に変更することによってラジオにロックをかけることです。これで、FRAが代理で処理することを防ぐことができます。スペクトルのバランスを変えるような変更をする際には、問題が発生する可能性があるというこ

とに留意してください。帯域幅の変更などは、常にメジャーなアップグレードと見なす必要があ

ります（実際そういうものなのです）。

このリビジョンのコードでは、フレキシブルインターフェイスが 2.4 GHzのRoleにない場合、しばらくの間、COFが「使用不可」となります。FRAをリセットし、計算を最初から再実行したい場合は、ラジオを単に元に戻します。(Cisco Controller) >config advanced fra revert Auto-only/All Static/Auto


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：定常状態動作

ラジオを選択して自動にすることができます。または、すべてのラジオを自動かスタティックに

戻すことができます。自動に戻ると、自動的に 2.4 GHzの Client Serving Roleが割り当てられます。

FRA とデュアル 5 GHz 動作デュアル 5 GHzのセルの管理は、FRAが行うことの中でも最も重要なものの 1つです。デュアル5 GHzの APには、次の 2種類の動作モードがあります。

•マクロ/マイクロ：より小さなセルが内部にある大きなセル。単一セルの範囲内でキャパシティを倍にします。

•マクロ/マクロ：独立した 5 GHzのデュアルセル。単一の従来のデュアルバンド APのカバレッジを倍にします。

マクロ/マイクロを使用できるのは、Cisco AP 3800/2800の Iモデルのみです。このAPのアンテナは、セル配置内のセルをサポートするように設計されています。この機能を効果的なものとする

ために、シリコンのレベルから 2つのセルを分離させることに設計上の多くの労力が傾けられました。その結果、アンテナ極性の分離と周波数の分離が実現しました。

FRA、DCAでは、デュアル 5 GHzマクロ/マイクロとして動作する際に、多くの設定要件が適用されます。

•最小 100 MHzでチャネルを分離（周波数の多様性）

•ミクロセル電力を最小に制限

•各セルで同じ SSID

マクロ/マイクロセルアーキテクチャの導入は魅力的です。非常に多様なクライアントエクスペリエンスを実現できる広範囲なセルを使用する際の問題が解決できるからです。APに近いクライアントほど、より高いデータレートを使用でき、セルのエッジ部分にあるクライアントよりも高

い SNRで動作できます。マクロ/マクロでは、セル内でそれぞれのクライアントを分離でき、全体的な効率性を向上させることで、通信時間を保持し、セルを最適な状態で使用できます。

FRAも 2つのセルを監視し、動作するクライアントがスループットを最大化し続けられるよう、2セル間のクライアント接続を最適化します。マクロセルとマイクロセルの間をクライアントが遷移する方法は、現在 3つあります。

• 802.11v BSS Transition

• 802.11k

•プローブ抑制

遷移のしきい値はユーザが設定できますが、デフォルト値が強く推奨されます。シスコのテスト

やベータ版ではデフォルト値でうまく機能しました。

(Cisco Controller) >show advanced client-steeringClient Steering Configuration Information1 Macro to micro transition threshold............ -55 dBm2 micro to Macro transition threshold............ -65 dBm3 micro-Macro transition minimum client count.... 3


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA とデュアル 5 GHz 動作

4 micro-Macro transition client balancing win.... 3<snip>

CLIでコマンドを使用して、次の値を調整できます。(Cisco Controller) >config advanced client-steering transition-threshold ?

balancing-window Configures micro-Macro client load balancing windowmacro-to-micro Configures Macro to micro transition RSSImicro-to-macro Configures micro to Macro transition RSSImin-client-count Configures micro-Macro minimum client count for transition802.11v BSS Transition – enabled by default

802.11v BSS Transition - デフォルトで有効802.11v対応クライアントは、アソシエーション時に APによって認識されます。802.11v対応クライアントがはじめに誤ったセルに接続した場合（マクロの可能性が最も高いが）、APはネイバーとしてのターゲットセルの BSSIDと共に、802.11v BSSの Transitionメッセージを送信します。その後、強制的な De-auth（40秒）が送信される。シスコのテストとベータ版で、すべての802.11v対応クライアントでマクロ・マイクロセルの遷移が適切に動作していることを確認しています。

802.11k - デフォルトで有効802.11vと同様に、ターゲットのセルの BSSIDのリストと共にサイトレポートメッセージを使用します。この方式に付随する問題は、最終的にはクライアントがサイトレポートを要求する必要

があることです。

プローブ抑制 - デフォルトで無効

アソシエーションしていないクライアントは、通常、アソシエーションシーケンスを開始するた

めに、すべてのチャネルにプローブリクエストを送ります。マイクロおよびマクロセルのラジオ

が短時間の内にアソシエーションしていないクライアントからのプローブリクエストを受信し、

クライアントがマイクロまたはマクロセルのカバレッジエリア内にいれば、APは接続してほしくないラジオからクライアントへのプローブレスポンスを抑制できます。これは効果的にクライ

アントからセルを「隠す」ことから、クライアントがレスポンスのあったセルでのアソシエーショ

ンシーケンスを開始する可能性が高くなります。クライアントの「反応がにぶく」、そのチャネ

ルでプローブリクエストを受信しない場合に、別のセルへのアソシエーションを試みる場合は、

動作モードによっては、APはそのセルへの単一の認証レスポンスを抑制することもでき、望ましいセルへのアソシエーションを試みるように、クライアントに強制することができます。

同様に、アソシエーションしているクライアントは、通常、より高い送信電力のラジオへ移行す

るために、すべてのチャネルにプローブリクエストを送ります。APの両方の無線がどちらかのセルとアソシエーションするクライアントからのプローブリクエストを受信すると、その高い送

信電力を起因とする他のセルへの早まったローミングを防ぐために、クライアントがターゲット

セルのカバレッジエリアにいる間、APは他のセルのクライアントへのプローブレスポンスを抑制し続けます。

クライアント操縦の他の 2つの方式と同様に、カバレッジセルを対象とする上で、同じクライアントのRSSIしきい値に依存します。先述の2つとは異なり、この方式はデフォルトで無効になっています。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA とデュアル 5 GHz 動作

マイクロからマクロ、またマクロからマイクロへのクライアントのしきい値以外に、80-2.11vまたは 802.11k方式で設定すべき、もしくは設定が必要な項目は多くありません。プローブ抑制には、ここで扱ういくつかのオプションがあります。

•動作モード：このパラメータでは、APのマイクロ/マクロのプローブ抑制機能の動作モードを管理します。次のオプションを使用できます。

◦ Disable：APのマイクロ/マクロのプローブ抑制機能を無効にします

◦ Probe Only：マクロセルのプローブのみが抑制されます

◦ Probe And Auth：単一の認証に沿うマクロセルのプローブのみが抑制されます

•プローブの有効期間ウィンドウ：このパラメータでは、マクロセルで受信されるプローブに関連して有効とみなされるマイクロセルのプローブ用の時間間隔を指定します

• RSSIしきい値を抑制：マクロセルからのプローブレスポンスのクライアントのRSSIしきい値が抑制されます

• RSSIしきい値を有効化：マクロセルからのプローブレスポンスを超えたクライアントのRSSIしきい値は抑制されません

•プローブ集約ウィンドウ：クライアントは、時々、短時間のうちに複数のプローブリクエストを送信できます。このパラメータは、クライアントからのプローブが明確に区別されない

間の時間間隔を指定します

•遷移の即応性：このパラメータは、抑制されているマクロセルのプローブ用の接続が中断されたプローブ集計ウィンドウの数を指定します。

(Cisco Controller) >config advanced client-steering probe-suppression ?

disable Disables micro-Macro probe suppressionenable Enables micro-Macro probe suppressionhysteresis Configures hysteresistransition-aggressiveness Configures probe cycles to be suppressed

すべてのマクロ/マイクロ遷移のしきい値は、CLIで、show advanced client-steeringを使って表示することができます。

(Cisco Controller) >show advanced client-steering

Client Steering Configuration Information

Macro to micro transition threshold............ -55 dBmmicro to Macro transition threshold............ -65 dBmmicro-Macro transition minimum client count.... 3micro-Macro transition client balancing win.... 3Probe suppression mode......................... probe-and-authProbe suppression validity window.............. 100 sProbe suppression aggregate window............. 200 msProbe suppression transition aggressiveness.... 3Probe suppression hysteresis................... -6 dBm

FRA：トラブルシューティングFRAは、DCAに著しく依存します。これは、DCAが Roleの選択の評価とラジオへのチャネルおよび周波数帯の割り当てに使用されるためです。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：トラブルシューティング

つまり、DCAは少なくとも FRAと同程度に実行される必要があります。また、FRAが推奨をする際、それを実行し管理することが、DCAには求められます。こうしたことから、DCA、FRAの設定とその予期される動作を把握していないと、多くの混乱が引き起こされる可能性があります。

次の例を参照して、想定されるシナリオについて把握してください。

1 FRAが実行され、ラジオが重複であることを確認します

2 重複とマークされたラジオが、DCAによる Roleの割り当てを待ちます

3 DCAが動作すると、DCAのチャネルプラン・チャネル幅・チャネル干渉などの評価に応じて、5 GHzまたはMonitorが割り当てられます

a これはラジオが戻されたためです（2.4GHzで動作していて、以前は 5GHzチャネルが割り当てられていない状態。また、5 GHz用のデフォルトのチャネルは 36のため、ラジオには5 GHzの 36チャネルが割り当てられます）

4 次に、DCAが動作すると、5GHzのラジオにはネイバーができ、チャネルが割り当てられます

5 これらのラジオのネイバーが、2.4 GHzのカバレッジホールを表示すると、報告された FRAは、 Roleが 2.4 GHzに切り替えられていたすべてのラジオを元に戻し、FRAが再び実行されます

DCAが 12時間の間隔に設定される場合、FRAも 12時間（最小）に設定される必要があり、その場合、第 2の DCAサイクルは 24時間になります。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA：トラブルシューティング

FRA - CLI およびデバッグコマンドshow Advanced fraコマンドは、現在の FRA状態（有効/無効）、感度、現在の実行間隔、最後の実行時間など、すべてのフレキシブルラジオのステータスと状況を示します

(Cisco Controller) >show advanced fra

FRA State........................................ EnabledFRA Sensitivity.................................. high (90)FAR Interval..................................... 1 Hour(s)Last Run....................................... 620 seconds agoLast Run Time.................................. 0 seconds

AP Name MAC Address Slot Current Band COF % SuggestedMode-------------------------------- ----------------- ---- -------------- -----------------------3800_e_BC80 58:ac:78:df:7e:e0 0 2.4GHz 46 2.4GHz

2802_i.89D0 00:f2:8b:26:ed:d0 0 5GHz 84 5G/Monitor

3802_i.D9A0 58:ac:78:df:9c:20 0 5GHz 100 5G/Monitor

COF : Coverage Overlap Factor

show advanced 802.11a/b summaryコマンドは、802.11aの Roleが割り当てられた際にスロット 0に現れる特定の周波数帯、フレキシブルラジオ内のすべてのラジオを表示します。show advanced802.11-abgn summaryコマンドで、フレキシブルラジオだけを表示することもできます(Cisco Controller) >show advanced 802.11-abgn sumMember RRM InformationAP Name MAC Address Slot Admin Oper Channel TxPower

-------------------------------- ----------------- ---- -------- ------- ---------------------3800_e_BC80 58:ac:78:df:7e:e0 0 ENABLED UP 1* *8/8 (2 dBm)2802_i.89D0 00:f2:8b:26:ed:d0 0 ENABLED UP (56,52)* *7/7 (2 dBm)3802_i.D9A0 58:ac:78:df:9c:20 0 ENABLED UP (36,40)* *7/7 (2 dBm)

config advanced fra revertコマンドは、2.4 GHz client servingのデフォルト状態に自動で戻るものすべて、もしくはフレキシブルラジオだけを素早く閲覧したり、それらを自動FRAもしくはマニュアル FRAにマークづけしたりする場合に使われます（APの追加や移動後の COFの計算に有用です）。(Cisco Controller) >config advanced fra revert all auto

Reverting XOR radios can cause disruption for associated clients. Are you sure you want tocontinue? (y/n)y

(Cisco Controller) >show advanced fra<snip>AP Name MAC Address Slot Current Band COF % SuggestedMode-------------------------------- ----------------- ---- -------------- ------ ----------------

3800_e_BC80 58:ac:78:df:7e:e0 0 2.4GHz 46 2.4GHz

2802_i.89D0 00:f2:8b:26:ed:d0 0 2.4GHz 84 5G/Monitor

3802_i.D9A0 58:ac:78:df:9c:20 0 2.4GHz 100 5G/Monitor


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA - CLI およびデバッグコマンド

Debug airewave-director fra enableコマンドで、FRAのデバッグを開始します。このセクションでは、その重要性について説明します。このコマンドの内容は多岐にわたりますが、開発者向けの

内容であり、簡潔にするために、重複する内容を省きます。

デバッグコマンドの出力は非常に多いため、FRAのデバッグは、すべての APに対して、フルローディングされた本稼動システムで実行してはなりません。debug mac addr<mac1,mac2,mac3>を使用して、対象のデバイスだけにデバッグを限定することができます。

警告

デバッグの最初の部分では、ソリューションセットに含まれるラジオと RRF（Redundant RadioFlexibleもしくは 2800/3800）の対象である場合のラジオが、すべて一覧表示されます。表示される APが、2.4 GHzインターフェイスの設定されている APでなければならないことに注意してください。最後の列のNDM（Network Density Metric）は非常に便利です。これは、インデックスされた各 APが、-67 dBm以上で受信できるネイバーとして持つ APの台数です。この台数が多いほど、ネットワークの密度が高くなります（AP同士の距離が近くなります）。(Cisco Controller) >debug airewave-director fra enable*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: Executing FRA on 802.11bg*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: ----------------------------------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014:*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: RDCI List :*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: ------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: Index AP RRF Candidate

NDM*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: ------ ------------------- --------

-----*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: 0 58:AC:78:DF:9C:20(0) YES

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: 1 00:F2:8B:26:ED:D0(0) YES

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: 2 F0:7F:06:5E:FD:C0(0) NO

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.014: 3 E4:C7:22:AA:38:20(0) NO

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 4 E4:C7:22:AA:34:40(0) NO

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 5 08:CC:68:B4:20:00(0) NO

6*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 6 58:AC:78:DF:7E:E0(0) NO

5*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 7 64:D9:89:46:7F:B0(0) NO

4

次の手順で、上のリストの RRF対象の各 APの計算が開始されます。この例では、2台の APが[Yes]になっています。3800iが 1台、2800iが 1台、DARTケーブルが接続していない 3800eが 1台ありますが、この時点でフレキシブルではなく、リスト上に残っているAPは3500、3600、3700です。

APのインデックス 0には、APのMACアドレス（58:AC:78:DF:9C:20）が表示され、すぐに近隣の一覧が取得されます。これは、APのインデックス 0の計算で使用される対象の APへのネイバーの一覧です。ここでは、問題となるネイバーを確認できます。最も通信量の多い 4つのネイバーのみが使用され、すべて同じAPグループである必要があります。APが近接しており通常はリストに含まれるべきものがリストに含まれていない場合は、対象 APとの通信量の多い 4つのAPとして認識されていません。これは別のAPグループに属しているか、そのネイバーの情報が利用可能になっていないことが原因として考えられます（電源を新たに投入したため）。

出力においては、リスト上でインデックス 0に指定された最初のAPと、そのAPとの通信量の多い4つのネイバーが、ネイバーのRSSIと送信電力と共に表示されます（軽微な不具合のため、最



新の送信電力は正確でなく、リリース 8.2 MR1では常に最大電力として表示されます。ただし、アルゴリズムにおいては、最新の送信電力が使用されます）。これにより、AP58:AC:78:DF:9C:20のカバレッジエリアのカバレッジに想定される APが確立されます。*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 58:ac:78:df:9c:20---------------------------------------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 58:ac:78:df:9c:20 Redundancy Iteration 0 , RDCI0*RRM-MGR-2_4-GRP: Jun 07 16:22:05.015: 58:ac:78:df:9c:20---------------------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.029: 58:ac:78:df:9c:20 Neighborhood list for AP 0*RRM-MGR-2_4-GRP: Jun 07 16:22:05.029: 58:ac:78:df:9c:20---------------------------------------Jun 07 16:22:05.029: 58:ac:78:df:9c:20 RDCI Index AP RSSI TxPower(dBm)Jun 07 16:22:05.029: 58:ac:78:df:9c:20 ----------- ------- ------------------Jun 07 16:22:05.029: 58:ac:78:df:9c:20 0 58:AC:78:DF:9C:20(0) 023Jun 07 16:22:05.029: 58:ac:78:df:9c:20 2 F0:7F:06:5E:FD:C0(0) -1422Jun 07 16:22:05.029: 58:ac:78:df:9c:20 7 64:D9:89:46:7F:B0(0) -3022Jun 07 16:22:05.029: 58:ac:78:df:9c:20 5 08:CC:68:B4:20:00(0) -3123Jun 07 16:22:05.029: 58:ac:78:df:9c:20 4 E4:C7:22:AA:34:40(0) -4320Jun 07 16:22:05.029: 58:ac:78:df:9c:20 3 E4:C7:22:AA:38:20(0) -4820Jun 07 16:22:05.029: 58:ac:78:df:9c:20 6 58:AC:78:DF:7E:E0(0) -6623Jun 07 16:22:05.029: 58:ac:78:df:9c:20*RRM-MGR-2_4-GRP: Jun 07 16:22:05.029: 58:ac:78:df:9c:20 Neighborhood Path Loss Matrix*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 -----------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 0 37 52 53 5466 71 89<snip> Calculating every AP to every AP’s path loss*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 Neighborhood Distance Matrix*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 -----------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 0 0 4 5 514 17<snip>Calculating RF distances between AP’s*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 Unable to triangulateneighborhood, assigning single axis coordinates <normal behavior– perfectly fine we areoperating in 2D>*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 Computed Coordinates*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 ---------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.030: 58:ac:78:df:9c:20 X Y R*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 ---- ---- -----*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 0 0 18<snip> many lines of X, Y positions – and calculated radius of each cell*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 Neighborhood Multi-Point Check*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 Using 4 neighbors for overlapcomputation*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 Point Coordinates CoverageScore*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 --------------------------------*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 0 , 0 2<snip> Many more lines – deleted for brevity. This is the output and score from themultipoint overlap calculation.<comment> followed by the RDCI Overlap Factor for this radio and it’s conclusion*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 RDCI Overlap Factor : 92 %*RRM-MGR-2_4-GRP: Jun 07 16:22:05.031: 58:ac:78:df:9c:20 RDCI is redundant*RRM-MGR-2_4-GRP: Jun 07 16:22:05.032: 00:f2:8b:26:ed:d0 Redundancy Iteration 1 , RDCI1(00:F2:8B:26:ED:D0(0))<snip> Redundancy iterations continue for each radio marked as Yes for RRF candidate*RRM-MGR-2_4-GRP: Jun 07 16:22:05.034: 58:ac:78:df:7e:e0 Redundancy Iteration 2 , RDCI6(58:AC:78:DF:7E:E0(0))*RRM-MGR-2_4-GRP: Jun 07 16:22:05.037: Redundancy Identification Complete*RRM-MGR-2_4-GRP: Jun 07 16:22:05.037: ----------------------------------------------------



*RRM-MGR-2_4-GRP: Jun 07 16:22:05.037:<snip> The last entry below – is the output you see in show advanced fra*RRM-MGR-2_4-GRP: Jun 07 16:22:05.037: RDCI List :*RRM-MGR-2_4-GRP: Index AP Overlap % Redundant overlapContributor*RRM-MGR-2_4-GRP: ------ ------- -------- ------------------------------*RRM-MGR-2_4-GRP:0 58:AC:78:DF:9C:20(0) 92 YES NO*RRM-MGR-2_4-GRP:1 00:F2:8B:26:ED:D0(0) 69 NO YES*RRM-MGR-2_4-GRP:6 58:AC:78:DF:7E:E0(0) 53 N/A NO

デバッグは、計算によって結論づけられます。APのインデックス0が、重複とマーク付けされても、カバレッジのオーバーラップの原因であるわけではないことに注意ください。現在のFRAのしきい値は High（90 %）で、92 %は 90 %を超えています。感度が medium（85 %）に設定されている場合は、重複とはマークされないでしょう。

また、APのインデックス1が重複の原因としてマークされていることにも注意してください。つまり、COFの割合に関係なく、この APの 2.4 GHzインターフェイスが、すでに重複とマーク付けされた別のラジオ（APインデックス 0）にカバレッジを提供するものとして数えられています。

RFAは重複しているインターフェイスを特定するだけであり、特定された場合、DCAが新しいRoleの割り当てを実行する必要があることを思い出してください。次のように、ラジオに新しいRoleが割り当てられるのを防ぎます。

•クライアントネットワーク優先度：FRA用のデフォルトで、接続プロファイルのみが使用されます。ラジオとアソシエーションする 3台ないしはそれ以上のクライアントに適用されます。遷移ではありません。DCAの実行時に評価されます。

• DCAを実行しない：評価がされていないために、showコマンドの出力中に推奨 Roleが含まれない場合には、DCAが実行されません。

FRA - ベストプラクティスFRAは新機能です。自動的に他の Roleを 2.4 Ghzラジオに割り当てる能力があり、完全に自動です。この運用について習熟することを強く推奨します。APにおける手動周波数帯選択での運用は完全に安全ですが、FRAアルゴリズムの動作を妨げます。これはCOFの表示と検証を可能とし、結果の理解を深めます。FRAは基本的に安全を重視するものです。

手動モードでの実行：

1 config advanced fra revert all static

2 config advanced fra enable

COFの結果を表示し、周波数帯を変えることなく検証することができます。後で手動で変更したいラジオを選択するか、自動を有効にし、ラジオがシフトするのにまかせます。


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA - ベストプラクティス


フレキシブルラジオアサインメント（FRA）と重複したラジオFRA - ベストプラクティス

第 6 章

動的チャネル割り当て（DCA）

• 動的チャネル割り当ての機能 , 57 ページ

• 動的チャネル割り当て（DCA）アルゴリズム , 59 ページ

• DCAの概要, 60 ページ

• DCAの動作モード, 62 ページ

• DCAでの 20/40/80/160 MHzのサポート , 65 ページ

• 動的チャネル幅選択 - DBS , 70 ページ

• デバイス認識型 RRM, 73 ページ

動的チャネル割り当ての機能• RFグループへのチャネル割り当てを動的に管理します。

•無線単位で APごとに割り当てを評価します。

• RSSIベースのコストメトリック機能を使用して決定を行います。この機能は、利用可能な各チャネルに対する干渉に基づいてパフォーマンスを評価します。

•チャネルプランを動的に調整して、個々の無線のパフォーマンスを維持します。

• 20/40/80/160 MHz帯域幅 OBSSをアクティブに管理します。


•各 AP（DBS v.8.1）の最適な帯域幅を動的に決定できます。

図 11：新しい AP の追加により、その AP の無線と既存 AP の無線が競合して争いが発生。DCA は、新しい APに最適なソリューションを得るためにチャネル計画を調整

DCAの役割は、RFグループで使用可能なチャネルを監視して、状況の変化を追跡することです。物理的に多様なチャネルを選択することにより、AP間の RF分離を最適化し（同一チャネル干渉を最小化）、RF効率を最大化します。DCAはすべての使用可能なチャネルを監視し、さまざまなチャネルプランオプションの評価に使用されるコストメトリック（CM）を作成します。CMは、干渉、ノイズ、定数（ユーザ感度しきい値）、および負荷（有効な場合）から構成される

RSSI値です。コストメトリックは、重み付けられた SNIR（信号対ノイズ干渉比）と同等です。詳細については、「RRMデータ収集アクティビティ」の項を参照してください。

競合システムについて：決定に使用する情報を充実させるために、競合他社の無線管理システム

もオフチャネルを監視する必要があります。シスコの RRM実装は、中断が最小であるという一貫したテスト結果を得ています。スループットテストの実施により、Cisco APが情報フローの流動性を維持することを実証できます。競合製品は、同じテストを実施してみると、一般にスルー

プットにおいて明らかな低下が見られます。Arubaは、デフォルトでは、110 msの滞留オフチャネルを必要とします。オフチャネルスキャンは多岐にわたって使用できます。通常、wIDS/wIPSの実装では広範なオフチャネルスキャンが必要であり、DCAチャネルだけではなく、非常に膨大な数のカントリーチャネルに対しても実施する必要があります。RRMをオフにすると、これらのオフチャネルスキャンが無効になりますが、wIDSと不正検出機能も使用できなくなります。

DCAはこれらの測定をすべて使用して、方程式で使用される RRSIベースのコストメトリックにそれらを加算します。コスト機能はRSSIで表される単一の数値であり、特定のチャネルオプションの総合的利点を示します。

APのチャネルを変更すると、中断が発生する可能性があります。明らかな改善に関する評価に注意を払わなければなりません。次世代DCAが優れているのはこの点です。近隣のネイバーに悪影響を与えることなく APのパフォーマンスを向上できるかを、多段階のプロセスで判断します。


動的チャネル割り当て（DCA）動的チャネル割り当ての機能

動的チャネル割り当て（DCA）アルゴリズムグループリーダーはRFグループ内のすべてのAPのネイバーリストを保持し、これらのネイバーを RFネイバーフッドに組織化します。RFグループ内の各 APに対して次のメトリックが追跡されます。

1 同一チャネル競合：同じチャネル上の他のAP/クライアント。同一チャネル干渉またはCCIとも呼ばれます。

2 外部チャネル（不正）：APが使用しているチャネルで動作している、またはチャネルとオーバーラップしている RFグループ外の他の AP。

3 ノイズ：Bluetooth、アナログビデオ、コードレス電話などの非Wi-Fi干渉源。CleanAirによるノイズ源検出に関する有用な情報については、CleanAirを参照してください

4 チャネル負荷：業界標準のQBSS測定を使用（これらのメトリックは物理レイヤから収集されます）。CAC負荷測定に非常に類似しています。

5 DCA感度：ユーザが選択可能な感度しきい値。チャネル変更の評価にヒステリシスを適用します。

これらの要因による影響を組み合わせて、コストメトリック（CM）と呼ばれる単一のRSSIベースのメトリックが形成されます。CMは特定チャネルの総合的なSNIRを表し、他のチャネルに対するチャネルのスループットのポテンシャルを評価するために使用されます。目標は、干渉を最

小限に抑えて、特定の APまたは無線に応じた最適なチャネルの選択を可能にすることです。グループリーダーは CMを使用してあらゆる APとチャネルを評価し、最大効率を実現できます。もちろん、RFにおける状態の変化も、これらの統計情報を動的に収集して週 7日 24時間体制で監視されます。

図 12：コントローラの無線ページでの干渉とノイズの表示

RFグループリーダーは、APで現在使用されているローカルチャネルに対してCMを使用し、ランク付けしたリストを作成します。このリストが、RFグループにおいて最悪のパフォーマンスによる影響を受けるAPを示すCPCIリスト（Channel Plan Change Initiator）になります。説明をシン


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

プルにするために、1つの APを取り上げて DCAの動作を説明します。その後、チャネルボンディングや複数の AP機能と共に、その概念を RFグループ全体のさらに複雑な役割に適用します。

DCA の概要DCAの実行は、デフォルトでは CPCIの選択から始まります。DCAは常に開始対象の APの中で最もCMの低いものを選択し、ランダムなAP選択と、リストの残りからのCMの低いAPの選択とを交互に繰り返し続けます。DCAは、チャネルプランが計算される場合には、第1ホップと第2ホップのネイバーをグループとみなして CPCIを扱うことで、その時点での CPCIをより適切に選択します。

第 1ホップのネイバーは、CPCIの直接観察（隣接関係）により確認できる APで、第 2ホップのネイバーは、第 1ホップとの関係から確認できる近隣内の APです。評価においては、CPCI用のチャネルとすべての第 1ホップネイバーが、ソリューションの達成のために変更される可能性があります。第 2ホップネイバー用のチャネルは、影響の評価の間には、変更できません。これにより、APのローカルグループの分離と、変更の影響が RFグループ全体の APに及ぶことを防ぎます。

計算が完了すると、結果には、CPCIを改善する複数のチャネルプランが示されます。改善を生じさせる各チャネルプランは、NCCF（Normalized Cumulative Cost Function）と呼ばれる別のゲーティング関数に適用されます。この非 RSSIベースの関数は、全体的な CPCIグループの利点に関するチャネルプランの結果を評価します。つまり、CPCIはそのネイバーだけでなくグループと


動的チャネル割り当て（DCA）DCA の概要

して改善された CMと認識すべきで、推奨されたチャネルプランを改善するか、もしくは同じものとなります。

図 13：第 1 および第 2 ホップ RF ネイバーでの CPCI

計算が完了すると、CPCIおよび第 1ホップネイバーが CPCIのリストから削除され、次の計算がリストの残りの APからランダムに選択されて始まります。DCAの処理は、CMリストがすべて空になるまでランダムからの選択と、最低値の選択を交互に繰り返します。このように、通信が

可能なすべての他のAPに照らして、すべてのAPを評価します。CMのリストが空になり、DCAが完了すると、NCCFが完了し、チャネル変更が処理されます。

DCA 感度しきい値Wi-Fiはバースト性をもったメディアです。つまり、短期的には低性能に見えても、総合的には非常に良好な場合があります。APのチャネルの変更は潜在的に混乱を生じさせる可能性があり、変更が実施される場合は注意が必要です。これは軽微なパフォーマンスの改善や短期的なトレンド

に対する反射的な対応ではありません。ユーザに選択可能な感度のしきい値が提供されることで、

チャネル変更アルゴリズムの勢いを弱めることが可能となります。デフォルト値は medium（10dB）で、これは基本的にはチャネル変更を行うためのものです。新しいチャネルが推奨されるには、そのチャネルの CMの値が 10 dBよりも良好になっている必要があります。低感度の値は 20dBで、中感度の場合は周波数帯によって 10～ 15 dBになります。NCCFは推奨されるチャネルプランを最後に評価するものであるため、NCCFがこのしきい値を処理します。この基準に合致しないチャネルプランは、APでは処理されません。


動的チャネル割り当て（DCA）DCA 感度しきい値

表 6：周波数帯ごとの DCA 感度のしきい値

HighMediumLow周波数帯

20 dB10 dB5 dB2.4 GHz

20 dB15 dB5 dB5 GHz

評価はシンプルなものです。NCCFが求めるのは、現在のチャネルコストメトリックと提案されたチャネルコストメトリックが、DCA感度のしきい値の値と等しいか、大きいか、小さいかです。等しいか大きければ、チャネル変更が提案されます。これは、クライアントの接続に悪影響

を及ぼす負荷への対応として、一時的に勢いを弱めたり、短期的なチャネルの増加や停止を行う

際に役立ちます。

DCA の動作モード

スケジュール DCADCAは、デフォルトでは 10分（600秒）ごとに動作します。他の間隔が定義され、DCAがスケジュールモードで動作しない限り、初期設定後の安定状態ではデフォルトで動作します。スケ

ジュールDCAにより、お客様がチャネルの変更に伴う潜在的な中断を回避する計画をたてることができます。しかし、DCAアルゴリズムは選択した時間にのみ動作し、負荷がピークに達した際のユーザ環境を考慮していない可能性があることに注意してください。クライアントによる負荷

がかかった環境では、同じ環境であっても大きく異なる可能性があります。効果を上げるために

は、オフピーク時に行った変更を最大化するような最も高い感度レベルを選択することが、お客

様に推奨されます。また、定期的にチャネル変更の耐障害性に関して環境の再評価を実施するこ

ともお勧めします。クライアントが更新されるにつれ、こうした点が向上し、最新のクライアン

トで正常にチャネル変更の管理が行われます。

APのチャネルが変更されるたびに、クライアントは一時的に切断されます。クライアントのローミング動作により、クライアントは同じ AP（新しいチャネル）に再接続するか、付近のAPにローミングする可能性があります。クライアントが適切にローミングする機能は、チャネル変更の間にその効果が決まります。

（注）


動的チャネル割り当て（DCA）DCA の動作モード

起動モード

初めてAPがブートアップする場合（新規出荷状態）、サポート対象の周波数帯（11b/g/nチャネルおよび 11a/n/ac用の 36チャネル）で最初の非オーバーラップチャネルを送信します。APの電源が再投入される場合は、前回のチャネル設定が使用されます（APのメモリに保存されています）。動的チャネル割り当ての調整が必要に応じて行われます。

（注）

RFグループのコントローラが RFグループに加わるか離れる際（もしくはリブートの際）には、起動モードであることが想定されます。つまり、コントローラがRFグループリーダーであるか、また RFグループリーダーとして戻る場合は、ユーザ設定（次の 100分間は 10分おき）に関わらずDCAは起動モードを実行します。このように、これはコントローラのリブートの前に考慮されるべき内容ですが、想定されるほど不適切なものでもありません。以前にネットワークが安定状

態だったのであれば、APのチャネル割り当てがすでに最適化されているはずです。コントローラを新しく追加し、APが追加されていた場合は、DCAが必要な新しいチャネル割り当てを最適化するために実行される必要があります。適宜計画してください。

起動モードはアグレッシブで、NCCFとユーザ感度のしきい値を無視します。これにより、ライブネットワークの変化の速度を落とすように設計されたダンプニング機能に関係なく、AP間のRF間隔を最大化するようなチャネルプランが作成されます。

コードバージョン 7.3以降、DCAの起動モードを初期化するコマンドライン引数があります。これは、RFグループ内のすべてのコントローラにあり、RFグループリーダーであるコントローラのDCAモードだけに影響します。グループリーダーのコマンドラインから config802.11a/b channelglobal restartコマンドを実行すると、RRMの DCAが再初期化され、無線の測定値に基づいて最適な回答を提供します。

安定状態モード

DCAがデフォルトで 10分ごとに使用されます。ユーザが起点時間と間隔をDCAでスケジュールすると、DCAはスケジュールされた間隔で実行されます。1日の間隔に 1を設定して実行することも可能ですが、シスコでは最小でも 2を設定することを推奨しています。そのほかの考慮事項については、上記のスケジュール DCAについて参照してください。

時間の経過とともに、特にネットワークアーキテクチャの変更にともない、ユーザ感度のしきい

値（ダンプニング）を、最適なサブチャネルの割り当てにつなげることができます。ほとんどの

ネットワークアーキテクチャは、時間の経過にともない変更され、DCAのルールでは、安定状態のネットワークが想定されます。APが追加もしくは削除されたり、チャネル幅がネットワーク全体で変更されたりした場合に、APのコストメトリックが 9 dB向上することは十分考えられることです。しかし、ヒステリシスが 10 dB（デフォルト）であるため、変化は生じません。

アーキテクチャを変更するときは、起動モードにしてDCAアルゴリズムの再起動を行うのがベストプラクティスです。その場合は、すべてのユーザ設定（感度しきい値）とNCCF機能が中断さ


動的チャネル割り当て（DCA）起動モード

れ、新しいアーキテクチャでの適切なベースラインに対してアグレッシブチャネル検索を行うこ

とができます。

図 14： DCA の動作例

上の図 12を使って、AP-1がチャネル 6にあり、グループで最も低い CMである -60 dBmだと仮定してみましょう（低ければ低いほど良いということを思い出してください。CMが低ければ、ノイズフロアも低く、スループットが向上します）。

1 DCAは、AP-1の位置に対してチャネル 1とチャネル 11を評価し、チャネル 11では CMが -80dBmである可能性があることを確認します

2 これは、AP-1をチャネル 11からチャネル 6に変更すれば、潜在的に Δ（CM）= 20 dBとなることを示しています。

3 感度が High/Medium/Low（5、15、20）で、すべて 20以下に設定される場合、DCAはチャネルを変更します。

4 チャネル 11の CMが -75で、差分が 15 dBmである場合、感度のしきい値が HighもしくはMedium（5もしくは 15 dBm）の時しか変更が実施されません。Lowの場合の 20 dBのヒステリシスが、15 dBに合致しないためです。

5 さらに、新しいチャネルプランの結果、ネイバーが変更され、ネイバーの CMがより低くなると、NCCFはチャネルプランの実行を推奨しません


動的チャネル割り当て（DCA）安定状態モード

数学的に高度になることなしに、NCCFは CPCI用の CMデータと第 1ホップネイバーを正規化し、CPCIがネイバーに悪影響を及ばすのであれば、チャネル変更の実施を防ぎます。NCCFはグループの変更の全体的な「有益さ」を評価するものとお考えください。これは、次のように分類

されます。

NCCFは推奨された変更の影響を受ける各無線に対してそのまま適用されます（CPCIおよび第 1ホップネイバー、第 2ホップネイバー）

• +1：CMが +5 dBm以上増加する場合

• 0：CM =/4 dBmの場合

• -1：CMが 5 dBm以上低下する場合

NCCFが、推奨された変更をCPCIとのそのネイバーにとって有益なものとして評価する場合、変更が実行されます。

DCA での 20/40/80/160 MHz のサポートRRMによって評価される内容はすべて実際の無線通信の観測に基づいていることに留意してください。RRMが 20/40/80/160MHzのOBSSチャネルの選択における共存と課題を扱う方法について説明します。802.11a/n/acが混在して配置される場合（もしくは 802.11aの無線がネイバーとして存在する場合など）、RRMの DCAがどのように処理するかについてです。複雑になりますが、DCAの目標は、常に望ましい建設的な共存状態を指向するチャネルプランを作成することです。建設的な共存が意味するのは、他の無線通信が削除できるということではありません。通常、そ

れらは存在し、法的権利も有しています。建設的な共存とは、むしろ補完的な要素を強化し、共

有されたメディアへの平等なアクセスの供給と必要性を主張する全員のサポートを行うというこ

とです。


動的チャネル割り当て（DCA）DCA での 20/40/80/160 MHz のサポート

DCA：OBSS と構造的共存

図 15： OBSS チャネルアーキテクチャ

OBSSおよびオーバーラップBSSは、802.11nと続く 802.11acの導入により現実的なものとなりました。両方のプロトコルにより、複数の 20 MHzチャネルを動的にリンクし、より多くのデータを同時に送信できる幅広いチャネルの形成が可能となります。すべてのチャネルが同じように動

作するわけではないため、束ねられたチャネル内のチャネルの位置が重要です。

表 7： OBSS の束ねられたチャネルのセグメント名と機能

機能と注意事項正式名称省略形

すべての制御とシグナリング

フレーム、HTおよびVHTヘッダーは P20のみ

プライマリチャネルP20

プライマリに追加のキャパシ

ティを加え、40 MHzチャネルを形成、プライマリチャネル

位置の +/-である可能性があります

セカンダリ 20S20

P20および S20を追加し、80MHzチャネルを生成束ねられたチャネルは、同じ周波数帯

（Unii 1、2、2e、3）となります



動的チャネル割り当て（DCA）DCA：OBSS と構造的共存

機能と注意事項正式名称省略形

P20および S20を追加し、80MHzチャネルを生成束ねられたチャネルは、同じ周波数帯

（Unii 1、2、2e、3）となります


ここでは説明の目的に合わせて、5GHzに重点を置きます。802.11nBSSで 2.4GHzの 40MHzチャネルを使用することは仕様に準拠していますが、シスコではこれをサポートしていません。2.4GHzスペクトルには、有効に動作させられる十分なチャネルがないためです。802.11acは 5 GHzスペクトルでのみ動作します。

802.11aのクライアントは 802.11nの HTヘッダーを認識しません。また、802.11aと 802.11nは両方とも 802.11acのVHTヘッダーを認識しません。後方互換性を維持し、3つのプロトコル要件を満たすためには、3つすべてで、プライマリチャネルアーキテクチャと定義を 802.11aプロトコルを使用する共通チャネル信号として共有します。802.11nおよび802.11acは共に、標準の802.11aフレーム形式に追加ヘッダー（HTおよび VHT）を加え、そのヘッダーがチャネル、選択チャネル幅、各プロトコル用のサポート対象のデータレートなどの詳細を 802.11nおよび 802.11acクライアントに通知するために使用されます。すべての管理（ブロードキャスト）トラフィックは、

プライマリチャネルで 802.11aプロトコルを使用します。802.11aデバイスに対しては、すべて802.11aです。

Wi-Fiでは競合が基本です。各ステーションは通信のない時間帯を判別するために、チャネルをリッスンします（通信もしくは LBTの前にリッスンします）。ただし、束ねられたチャネル内で、すべての 20 MHzセグメントが均等に処理されるわけではありません。プライマリチャネルがクリアな場合、セカンダリチャネルも高い確率でクリアであることを確実にするために、セカ

ンダリチャネルでは競合が少なくなっています。こうした理由から、複数のプロトコルがサポー

トされる設計においてはこれらの影響を把握することが重要です（少なくとも現在、インフラス

トラクチャまたは不正なネイバーとして 802.11nや 802.11acの APが存在するでしょう）。

下の表は CCAのしきい値の例です。RSSIの値はチャネルがビジーかアイドル状態かを判別するためにレシーバが受け取る必要のあるしきい値になります。CCAの評価はセグメント単位で実行され、最初のセグメントがクリアでない場合は、残りのチャネルセグメントのチェックが中断さ

れ、クリアでないことがホストにレポートされます。エネルギーがしきい値と同等もしくはそれ

以上ということは、キャリアがビジーか、クリアでないか、TXがない状態が生じていることを示しています。エネルギーがしきい値を下回る場合は、ステーションとの距離があることを意味し、

チャネルのアイドル状態を考慮して、次のセグメントをクリアするか、すべてが完了された場合

は送信することができます。

3つのプロトコルはすべて、プライマリチャネルの同じ値を共有することに注意してください。つまり、競合に関してはすべて平等に扱われ、メディアへのアクセスはすべて公平なものとなり

ます。また、セカンダリ20用の値も確認することができます。他のセカンダリの値にはすべて余裕があります（しきい値が高いということは競合が少ないということを意味します。低い値でリッ

スンしているステーションよりも、競合時に優先される確率が高くなります）。



表 8：CCA のしきい値の例

CCAのしきい値の例

S80S40S20P20プロトコル

———-82802.11a

——-62-82802.11n

-76/-79-76/-79-72-82802.11ac

DCAの役割は、個々のAP周辺の無線に関連する変数用のチャネルプランの計算を提供することです。利用可能なチャネルの総数を把握するにはこれが不可欠です。また、その数は機器上の制

約や選択したチャネル幅に基づいて変化します。80 MHzチャネルは 4 X 20 MHzチャネルであることから、制約に依存します。つまり、チャネル全体について非常に素早く考慮でき、効率的な

ネットワークを構築するのに十分なスペクトルのないままでいることができます。また、仕様の

異なる状況や何かが欠けたまま進められる状況の中で、建設的な共存を推進もしくはサポートす

るような方法で、これらを決定する必要もあります。

たとえば、上記の表の CCAしきい値を参照して、802.11ac（この場合は 802.11nでも可）の S20チャネル上に、802.11nの 40 MHzの P20チャネルを設置する場合、蓄積されたデッキから通信時間を確保するために 802.11nの APを使用する必要があります。なぜなら、802.11nの APが競合時に帯域を取得するには、チャネルの通信レベルが -82 dBmとなるまで待つ必要があるのに対して、802.11acのAPでは -72 dBmに低下するまで同じチャネルをクリアするだけでよいからです。こうした理由により、非常に不公平な状況が生じます。つまり、どちらも常にチャネルを必要と

しているため、802.11acのAPにより802.11nのAPの帯域幅が不足するということが起こります。802.11acのAPの方が帯域幅を得やすいのです。こうしたことから、-74 dBmの影響範囲で互いに通信するには、2台のAPが十分に近接していることが前提となります（適度な密度のネットワークでは、これらの多くは十分に近接しているでしょう）。

図 16：有害な共存の例



下の図は、平均的なデバイス（クライアント）で 10 dBmの電力を使用して生成した 2つの RFカバレッジを描画したものです。-82 dBm（P20用の CCA）でリスニングしている APが、-82 dBmのプロットエリア内のすべてのステーションと競合しています。-76 dBm（S20チャネル用のCCA）のカバレッジエリアはより小さく、より競合しにくいステーションが多くなることを表しています。

図 17：競合ウィンドウの可視化

DCAアルゴリズムは、AP、ネイバー、不正チャネルのいずれにも配慮した3つのソリューションを模索しています。DCAが使用できる空きチャネルがない場合の、優先順位が以下です

1 揃えられたプライマリチャネル = P20から P20 =最適

2 セカンダリ 40もしくは 80に揃えられたプライマリチャネル = P20から S40/S80 =問題はない

3 セカンダリ 20に揃えられたプライマリチャネル = P20から S20 =ないよりはよい

その後、DCAは通常どおり動作し、与えられたラジオの組み合わせでチャネルプランを解決しようとします。いずれかの 20 MHzチャネルがセカンダリチャネルとして割り当てられた場合、ドメイン内のすべての無線が有効な割り当てとして選択される可能性を軽減するために、より高い

コストメトリックが与えられます。

RRMでは、DCA対話から 20/40/80 MHzチャネルのいずれかを選択できますが、無線が 802.11a無線の場合は、20MHzチャネルのみがサポートされ、受信するのみとなります。同様に、802.11n無線では、80 MHzが選択された場合、40 MHzチャネルが割り当てられます。

40もしくは 80MHzチャネルのサポートなしを選択しつつも、802.11nまたは 802.11acプロトコルを実行する利点はあるでしょうか。確かに、レガシーまた 802.11n/acクライアントで享受できる3つの大きな利点として、より高いデータレート、優れたマルチパス耐性、クライアントリンクが挙げられます。すべて利点で、インフラストラクチャでのクライアント運用に関しては、802.11nもしくは acでの実装に不都合な点はありません。ネットワーキングにおいてはあまりないことです。



動的チャネル幅選択 - DBSDBS機能はコードバージョン 8.0で導入され、チャネル幅の追加によりメリットの得られるクライアントとアソシエーションしている APに対して、RRMによって柔軟かつインテリジェントにチャネル幅を割り当てる方法のことを意味します。このアプローチは動的なもので、クライアン

トの能力や実行内容の分析に基づいているため、RRMがネットワークチャネルに対して適切なサイズを適用できるようになります。

先に説明したように、広範なチャネルを持つことのメリットは明らかです。伝送ごとにより多く

のデータが送信できます。ただし、これは競合のニーズやスペクトルの可用性に関してバランス

を取ることができる場合にだけあてはまります。伝送のたびにより多くのデータを移動すること

は、1つのパケットの送信に 3倍長く待機する必要があるという場合、効果的とはいえません。より小さいビット数で、より頻繁に送信する場合よりも結果が良好でなくなる可能性もあります。

すべてのアプリケーションが、束ねられたチャネルから実際にメリットが得られるわけではあり

ません。たとえば音声は時間的制約のある小さなパケット（ジッター）に依存します。ビデオに

は大きなメリットがありますが、状況によっては、ジッターに関連する制約があります（リアル

タイムビデオ）。どちらも機能面で等しい束ねられたチャネル内のチャネルではありません。プ

ライマリチャネルは、他の束ねられたチャネルがシグナリングチャネル上で定義されたパケット

に関連するペイロードを単に送信する中で、シグナリング情報を送信する唯一のものです。ルー

ルとして、各セカンダリはプライマリよりも負荷が低くなります。

今日のほとんどの企業にとってのベストプラクティスは、企業の導入環境で 40 MHz未満を使用しないことです。しかし、これは実際には、保有するチャネル数や各 AP間の近接度合いに関連します。したがって、他の制約との組み合わせの中で、チャネル幅を動的に調整するために、DBSは RRMで使用できる相当量の情報に依存します。

DBSは次の項目を評価します。

•アソシエーションするクライアントの機能とタイプ

• RFネイバーチャネル幅

• OBSSチャネルのオーバーラップ率

•チャネル使用率

•非Wi-Fiノイズ


動的チャネル割り当て（DCA）動的チャネル幅選択 - DBS

• Wi-Fi干渉

図 18： DBS 用デバッグチャネル出力

上の図（debug airwave-director channel enableからの出力）では、DBS bsの行の ac/n/a/vo/viは、802.11ac/802.11n/802.11a/音声/ビデオを表し、2/0/0/0/0は 802.11acにアソシエートするクライアントが 2台あり、802.11n、802.11a、音声、ビデオにはない、ということを意味しています。

この数値の次にあるのが、バイアススコアです。バイアスは特定のチャネル幅に対しコストメト

リックに追加され、バイアスが大きければ、より選択されにくくなります。

80/40/20/vo/viは 80 MHz/40 MHz/20 MHz/音声/ビデオが 0/6/6/0/0であり、つまり、80 MHzにはバイアスがかからず、40 MHzと 20 MHzにはバイアスがかかり、音声とビデオにはバイアスがかからないことを意味します。これは、RRMにとっては、80 MHzチャネルを推奨する結果となります。なぜなら、そのクライアントだけが802.11acで動作するからです。つまり、80MHzチャネルが取得されるということかというと、そうではありません。可能性は増大します。環境内の他の

要素に比べて重要視する必要があります。

ネットワーク全体を見る場合も、小さいネットワークが確実です。無線ごとに、同じデバッグ結

果と推奨結果が、上記で展開された出力と同じようなものとなります。

図 19：チャネルデバッグからの DBS の結果 - 抜粋

上記の設定例においては、他のAPに 802.11acクライアントがないか、単一の 802.11acと 802.11nクライアントの間で分割がされていません。チャネル幅がチャネルと使用中の APに適宜設定さ


動的チャネル割り当て（DCA）動的チャネル幅選択 - DBS

れます。議論の余地はあるかもしれませんが、これは単純な構成であり、使用されているロジッ

ク自体は適切なロジックですが、規模が大きくなると複雑になります。どのようなタイプのクラ

イアントをどれくらいの数サポートしているかという点に基づいた推奨がベストプラクティスに

一致します。すべてに 80MHzチャネルを設定すると、クライアントのほとんどが 802.11nである場合、802.11nクライアントが使用できない多くの帯域幅を無駄にしていることになります。実際のところ、802.11nクライアントにとって、束ねられたチャネルのサポートはオプションです。ほとんどのスマートフォンはサポートしておらず、一般的にはラップトップや上位機種のタブレッ

トだけがサポートするものです。

そのため、この機能には「80MHzチャネルが必要ですが提供されていません」という反論がありました。この機能は上書きでき、APに手動でチャネル幅を設定することができます。ただし、RRMでは適切とはみなされないことに注意してください。これらのことは、通常は非常に適切なことなのです。

Flex DFS：柔軟な動的周波数選択DBSを取り入れることで、最新の OBSSの分野でよくみられるもう 1つの課題も解決されます。チャネル定義が 80 MHzの場合、4 X 20 MHzセグメントで構成され、UNII 2チャネル（DFS）が使用されます。そして、レーダーがいずれかの 4x 20MHzセグメントで検出されると、APとユーザによってチャネル全体の中断が適用されます。DBSとFlexDFSが使用されていなければ、これは、80MHzのスペクトルが30分間使用不能なものとしてマークされるのと同じことになります。DBSと Flex DFSが使用されていれば、影響を受ける 20 MHzチャネルにだけマークが付けられ、残りの 40 MHzチャネルと 20 MHzチャネルを使用するために、APが適宜再設定されます。いずれにしても、もはやAPとクライアントを切り替える必要はなく、APがその場所であまり適切でない領域を探す必要がありません。失うのは 20 MHzだけで、80 MHzのスペクトルを失うことはありません。

図 20： Flex DFS チャネルオプションの例

これは単純なことのようで、理にかなっています。しかし、システムに割り当てられるのが 80MHzチャネルだけだとすると、必要なものとなるでしょう。DBSと Flex DFSを使用すれば、コンプライアンスを維持しながらシステムに最適な役割を持たせることができます。


動的チャネル割り当て（DCA）Flex DFS：柔軟な動的周波数選択

デバイス認識型 RRMCleanAirは RRMと、通常のWi-Fi無線通信ではアクセスもできない物理層での情報を共有します。非Wi-Fi無線通信の干渉（Wi-Fiノイズ）は、場合によっては、RRMにとって実用的な情報です。たとえば、電子レンジはほとんどのオフィスに1台はあり、Wi-Fiにとって重大なノイズの発生源となります。CleanAirには、さまざまな方法でRRMと対話する 2つの機能があり、ここではその機能について説明します。

永続的デバイスの回避（Persistent Device Avoidance）永続的デバイスの回避（Persistent Device Avoidance）では、設置場所で頻繁に発生するWi-Fi干渉源を特定し、頻繁でないものも一部扱います。発生する場合、これらのデバイスが要因です。た

だ、場合によっては一定しない場合もあり、干渉の生じるチャネルすべてで否定的な影響が生じ

ます。そうした結果は回避されるべきです。RRMの通常のデータ収集と運用サイクルでは、干渉が認識され、それを回避します。ただし、干渉源の通信が収まると、回避されたチャネルがRRMからは再び問題ないようにみえ、そうした場合、RRMは前回問題のあったチャネルに無線を再割り当てします。電子レンジ、屋外のイーサネットブリッジの 2つは、永続的として評価される分類のデバイスです。一度検出されれば、これらのデバイスは継続的に無作為なタイミングで問題

となり、移動することもないと考えられるからです。これらのタイプのデバイスに関しては、検

出されたチャネルの検出された APにおいてクライアントに影響する干渉の発生する可能性が高いことを RRMが「覚えておける」ように、RRMに影響を受けたチャネルの検出とバイアスの適用を指示できます。

電子レンジを使用例として使います。ほとんどの職場に少なくとも 1つがあり、中には複数あるところもあるでしょう。稼働中の電子レンジは、高いデューティサイクルノイズで 2.4 GHz帯に影響を及ぼします。電子レンジは、民間設備用では 700から 1200ワットのどこでも動作し、商用グレードの設備向けにはより高い範囲で動作します。電子レンジは有害な電磁波の漏出を避ける

ように遮断されていますが、ここでの問題とされているのは人体への影響で、Wi-Fiへの影響ではありません。わずかなワット数で動作していても、通信へ影響を及ぼすには深刻な量のエネルギー


動的チャネル割り当て（DCA）デバイス認識型 RRM

が残されています。電子レンジは、2.4GHzスペクトル内のどこでも、一般的にはハイエンド（チャネル 11）で動作しますが、チャネル 11,6または周波数帯全体に頻繁に影響を及ぼします。

図 21：電子レンジの影響 - Channelizer Pro

電子レンジは継続的に動作しません。通常は朝一番と、昼食前後の数時間に電源が入ったり切ら

れたりし、午後の間食時にも動かされます。永続的デバイスの回避（PersistentDeviceAvoidance）により、APと検出チャネルにマーク付けし、RRMにデバイスの存在を認識させることができます。PDAは干渉を登録し、新しい検出のたびに更新されるカウントダウンタイマーを開始します。7日が経過した時点で、再び処理が検出されなければ、バイアスが削除され PDAの検出はリセットされます。

影響を受けた APとチャネルにバイアスをかけることは、RRMがその AP用にチャネルを使用しないことを保障するわけではありません。しかし、コストメトリックの増加に伴う可能性を低減

します。最終的な結果は、コストメトリックバイアスがかかっていたとしても、DCA次第であり、これにより最適なチャネルが利用できる可能性があります。


動的チャネル割り当て（DCA）永続的デバイスの回避（Persistent Device Avoidance）

APの PDAのステータスは、コントローラの [Wireless] > [802.11b/g/n]（または[802.11a/n/ac]）>[Details]で表示させることができます。[Details]ページの下部に、現在追跡対象となっているPDAデバイスと最終検出日が表示されます。

図 22： MMAP 用永続型デバイス（Persistent Device）テーブル

CleanAir PDAデバイスは次のとおりです。

•電子レンジ

• WiMax Fixed

• WiMax Mobile

• Motorola Canopy

PDAは実際のデバイスの分類に基づいているため、そのデバイスが存在し、どのAPが影響のあったレベルで通信することができたかを把握します。これにより、RRMはこれらのデバイスを回避し、問題のあるエリアの該当するチャネルを回避できるような代替チャネルプランを考案しま

す。PDAはデバイスを検出した APだけに影響します。

PDAの二次的な機能として、PDP（Persistent Device Propagation：永続型デバイス伝達）と呼ばれる機能が追加されました。この機能は、RRMを通じて、CleanAir情報と非 CleanAir AP情報を共有できるように設計されました。この機能はデフォルトでは無効ですが、有効にすると、検出し

ている APのネイバーと PDAのレポートを共有し、検出している APのネイバーの同じチャネルには同じバイアスを適用します。これは二次的な機能であり、完全に CleanAirの外部で生じるものです。CleanAir APのログインが検出されると、RRMは同じバイアスを伝達します。このバイアスは検出している APと -70 dBm以上で連携しているすべてのネイバーに適用されます。


動的チャネル割り当て（DCA）永続的デバイスの回避（Persistent Device Avoidance）

この機能の最大の注意点は、一部の設置場所では、-70 dBm以上で通信できる多数のネイバーの APを保持することができ、潜在的には、近隣 RF全体からチャネルを除外できる可能性があるということです。

（注）

この機能は、CleanAirの APを実装中のお客様が使用するための暫定策として作られました。CleanAirの動作に深く習熟し、リスクを把握している場合を除き、CleanAirの APと既存の非CleanAirの APを混在させた計画の一環として使うのは避けるべきです。

PDAに関連したチャネル変更トラップには、理由コードとして「デバイス認識」が含まれる予定です。

ED-RRMED-RRMは、RRMとは直接の関係はありませんが、呼び出された場合にチャネル変更が発生します。ED-RRMは Event Driven-RRM（イベント駆動型 RRM）を意味し、致命的な干渉イベントを即座に解決することを目的としています。Wi-Fiは通信の前にリッスンする方式（LBT：ListenBefore Talk）であるため、チャネルに CCAのしきい値を超えるエネルギーがある場合、すべてのステーションがクリアされるまで使用を中断します。特定の非Wi-Fiデバイスは継続的なものとして分類されます。つまり、100 %もしくは 100 %に近いデューティサイクル、言い換えれば決して電源が切られないということを意味します。こうしたデバイスの例にはアナログビデオカメ

ラがあります。このデバイスがある場合、APまたはそれと通信するクライアントは、エネルギーが常にあることから送信しようとしません。これは通常の RRM DCAのアクティビティによって修正されます。しかし、修正には最長で 10分（DCA間隔）を要する可能性があります。DCAのタイミングが変更された場合はそれ以上になる可能性があります。

APの CleanAirにより、そのようなデバイスを認識し、確実に分類することができます（通常のWi-Fiのオーバーサチュレーションとは混同されません）。これは明確な利点です。このデバイスが存在する場合はチャネルを発生させないか、無効でない場合は自身で改善することが確実で

あるからです。APのインターフェイスで迅速に検出し、APが一時的なチャネル変更をできるようにして、すばやくエネルギーを回避し、サービスを復元します。この変更に次いで、通常の

DCAサイクルが、その場所で使用できなくなったチャネルを回避している AP用に、より適した永続的なホームをみつけます。

ED-RRMは、APの電波品質メトリックに完全に基づいています。電波品質（AQ：Air Quality）は、CleanAirの分類した非Wi-Fi干渉メトリックに基づいて構成されており、そのため、未分類


動的チャネル割り当て（DCA）ED-RRM

もしくはノイズ関連の通常のWi-Fiでは動作させることができません。このために単純にノイズに依存することは非常に問題です。なぜならWi-Fiのノイズは非常に強い短時間のピークの後に相対的な平穏状態が続くことがあります（しかもこれは通常のことです）。しかし、AQのメトリックに依存する場合は、これらをすべて回避できます。なぜなら単純にはおさまらない問題で

あることが確実にわかるからです。

バージョン8.0では、ED-RRM機能に新しいコンポーネントが含まれました。不正コントリビューションは、特定の不正チャネルの使用率に基づいた ED-RRMのトリガーを可能とするもので、CleanAirのメトリックとは完全に分離されたものです。不正なデューティサイクルは、通常のオフチャネル RRMメトリックからとられ、隣接する不正な干渉に基づいてチャネル変更を呼び出すことができます。RRMメトリックからとられており、CleanAirからではないため、通常 180秒のオフチャネル間隔と想定されるタイミングは、長くとも 3分（180秒）以内です。これは、CleanAir ED-RRMとは別に設定されており、デフォルトでは無効になっています。これにより、自身のネットワーク以外で発生し、個々の APで測定されるWi-Fiの干渉に、APが反応できるようになります。ソーストリガー以外においては、ED-RRMの不正コントリビューションは、CleanAirコントリビューションと同じルールに従います。

APは 15秒のローリングウィンドウでAQを計算し、2連続のAPレベルAQしきい値違反で、設定されたED-RRMをトリガーします（デフォルトでは無効）。この機能には次の保護策があります。

1 トリガーされると、即時のフラッピングを防ぐために、APが新しいチャネルの ED-RRMの感度を 60秒間低下させます。

2 チャネルがED-RRMのトリガーイベントで特定されると、そのチャネルは 60分間ロックされます。

例として 2.4 GHzを使用します。チャネル 1で ED-RRMチャネルの変更がトリガーされ、チャネル 6にスイッチされるとします。干渉が 2.4 GHz帯全体で発生しており、60秒後にチャネル 6で再びトリガーされ、チャネル 11に移動すると仮定します。このシナリオでは、チャネル 11も影響を受けるため、60秒後に、ED-RRMのアラートもトリガーされます。この時点では、チャネル1とチャネル 6の両方が 60分間ロックされるため、移動できる別のチャネルもありません。その時間と 60分タイマーがクリアされるまで、もしくは干渉が取り消されるか修正されるまで、APはチャネル11に留まり続けます。これにより、フラッピングまたはランナウェイ状態が防がれます。



ED-RRMの設定は、[Wireless] > [802.11a/b] > [DCA configuration dialogue]で実施できます。

図 23： ED-RRM の設定ダイアログ - WLC GUI

設定は、ED-RRM（デフォルトでは無効）の有効化と AQのしきい値レベルの選択から成り立っています。

低感度 = AQ 35 %

中感度 = AQ 50 %

高感度 = AQ 60 %

カスタム =カスタム、ただし、ここでは細心の注意が必要です

AQは、すべての CleanAirによって分類された干渉の総合的な影響を示すスケールであることを思い出してください。高い AQは 100 %で、非常に低い AQは 0 %です。

不正コントリビューションを有効にして使用するには、まずED-RRMを有効にする必要があります。次に不正コントリビューションを有効にします。不正デューティサイクルはデフォルトで80です。つまり、不正なデバイスがチャネルキャパシティの 80 %を使用している場合、そのチャネルを離れ、新しいチャネルを探す必要が生じます。

これらのトリガーや応答はいずれもDCAによって動作しているものではありませんが、トリガーイベントの後に生じる可能性のある周辺のAPのバランスを再度とる際のチャネル変更やDCAによって参照されます。ED-RRMのトリガーの結果発生するチャネル変更トラップには、理由コードとして「主要 AQイベント」が含まれる予定です。



第 7 章

伝送パワーコントロール（TPC）アルゴリズム

最適な SNR（信号対ノイズ比）を備えた APの動作チャネルを選択することは重要です。しかし、ネットワークの大きな干渉源の 1つはクライアントと APであるため、伝送パワーコントロールも同様に重要です。DCAと TPCは連携して環境内の RFを管理します。セル境界は主に電力によって決まります。その他の変数もありますが（『High Client Density Design Guide』を参照）、電力は主要な決定要因の1つです。目標は、同一チャネル干渉を引き起こさずに、環境内の RFカバレッジを最大化することです。これは微妙なバランス調整のようなものです。なぜなら、クライアントの送信電力は制御できず（すべてのクライアントが CCX仕様のオプション部分である DTPCをサポートしているわけではありません）、扱うことができるのは APだけだからです。APのカバレッジを最大化し、その干渉を最小限に抑えるのは TPCの仕事です。

• TPCの機能, 79 ページ

• TPCv1 , 80 ページ

• TPCv2 , 83 ページ

• TPCの最小/最大, 86 ページ

TPC の機能TPCは、NDPプロセスで生成された TXネイバーリストと RFネイバーリストを使用します。RSSIは、他の AP（RXネイバー）を認識したり他の APがこちら（TXネイバー）を認識する方法に基づいてリストを体系化し、RFネイバーフッドと RFグループ内のすべての APが他のすべてのAPを認識する方法を示します。TPCはこの情報に基づいて各APの送信電力を設定し、カバレッジを最大化して、同一チャネル干渉を最小化します。TPCは、TPCしきい値によって示された必要なカバレッジレベルに合わせて、送信電力を上下に調整します。

DCAと同様に、TPCは RFグループリーダーで動作するグローバルアルゴリズムであり、APグループ内の APの RFプロファイルにサブ設定できます。


http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.pdf

バージョン 7.2以降、このアルゴリズムには、TPCv1（または TPC）および TPCv2と呼ばれる 2つのバージョンがあります。これら 2つのアルゴリズムの目的は基本的に同じですが、その計算と実装方法は大きく異なります。以下でそれぞれについて説明し、その長所と注意点を示します。

図 24： TPC によるカバレッジの最大化と CCI の最小化

TPCアルゴリズムは、DCAと同時に RFグループリーダーで実行されます。ただし、DCAとは別に設定され、実行されます。次の 3つのモードを設定できます。

• Automatic：10分ごとに実行します。

• On Demand：電力レベルの変更を呼び出した後、次の要求まで停止します。

• Fixed：ユーザが選択した電力レベルを RFグループ内のすべての APに適用できます。

TPCv1TPCv1はカバレッジ最適モードと呼ばれる、RRMにおけるデフォルトの電力制御方式です。このアルゴリズムはRFグループリーダーで実行され、RFグループのすべてのメンバーについて、無線別に APごとの送信電力を計算します。TPCv1に対する制御は、ユーザが調整可能な設定である RRM電力しきい値に基づいています。このしきい値は、APネイバーリストの 3番目のネイバーから収集した情報と組み合わされ、APの送信電力の決定に使用されます。

RF電力しきい値は APのセル境界の制御に使用され、さらに、システムのカバレッジ動作の制御にも使用されます。リリース 4.1.85.0（4.1 MR1）まではデフォルト値として -65 dBmが設定されていましたが、-70 dBmに変更されました。有効な入力値は -50～ -80 dBmです。RF電力しきい値はコントローラに設定し、RFグループ内のどのコントローラでも同じでなければなりません。一般的には、-68 dBm～-75 dBmの間の値で適切な結果が観察されています。ただし、一部の状況ではより高いまたは低い値を設定する必要があります。RF電力しきい値は、当該 APを他の APが認識する方法に応じて、当該 APが実行する動作を決定します。天井が高い場所などでは、AP相互の認識は良好ですが、フロアのクライアント側で問題が発生していることがあります。


伝送パワーコントロール（TPC）アルゴリズムTPCv1

2.4 GHzで使用可能な非オーバーラップチャネルの数は 3であるため、3番目に信号レベルが強いTXネイバーが使用されます。余談として、テストは 8番目のネイバーを使用して実施されました。5Ghzのほうが理にかなっているようですが、実質的な利点は認められません。また、ごく少数の規制ドメインでは、許可するチャネルの数が「3」と取り決められています。

Tx_Ideal 理想電力の計算TPCv1アルゴリズムは 2段階のプロセスとして実行されます。最初に、無線の理想送信電力（Tx_Ideal）が決定されます。

Tx_ideal = Tx_max + (TPCv1_Threshold - RSSI_3rd)

1 Tx_Max：特定の無線に対してサポートされる最大電力

2 TPCv1_Threshold：選択可能な RRM電力しきい値。バージョン 4.2以降は -70 dBm、それよりも前は -65 dB。

3 RSSI_Third：AP TXネイバーリストの 3番目に信号レベルが強い AP

これは RXネイバーではなく TXです（上記を参照）。（注）

Tx_Idealが Tx_currentよりも大きい場合は、電力を上げることを推奨します。

Tx_Idealが Tx_currentよりも小さい場合は、電力を下げることを推奨します。

TPCv1 変更推奨の評価プロセスの第 2段階では、第 1段階で推奨された結果を評価し、それを実行するかどうか決定します。APの Tx電力を変更するとセルの境界も変更されるため、クライアントの混乱を招く可能性があります。変更が必要であることを確認するには、ヒステリシスを適用します。

• Tx電力の増大には、ヒステリシス = 3 dB

• Tx電力の低下には、ヒステリシス = 6 dB

Txの変更が推奨されるかどうかの判断は、このようになります。

現在の Tx -理想の Tx = N

• N =/<ヒステリシスの場合は、変更は推奨されません

• N >ヒステリシスの場合は、変更が推奨されます

推奨電力変更の実装

電力変更が推奨されると、次のルールによって実行されます。


伝送パワーコントロール（TPC）アルゴリズムTx_Ideal 理想電力の計算

•電力の削減：TPCv1のインターバル（デフォルト 600秒）ごとに、1レベル（3 dB）ずつ削減されます。効果は段階的な削減となり、環境に沈静化の余裕をもたらします。

•電力の増強：電力レベルが Txの理想値かヒステリシスに達するまで、TPCv1の反復ごとに1レベル（3 dB）ずつ増加するように設定されます。

電力の変更が推奨される前に、近隣RFの有効性に関して健全性がチェックされます。例として、設定されている APに 3番目のネイバーがないケースを使用します（古くに終了した平滑化前の電力レベル 1の割り当ては、RRMアルゴリズムのバージョン 6.1で導入されました）。APに新しい電力レベルを適用する前に、APのネイバーが何で動作しているかを確認するためのチェックが行われます。3番目のネイバーがあるケースでは、既存の2つのネイバーを確認し、それらのネイバーと自身に適合した電力レベルが推奨されていることを保障します。

図 25： TPCv1 平滑化アルゴリズム機能

推奨内容は、ネイバーの APのネイバーリストに使われる電力リストに合わせられます。また、平均の平均がリスト中の TPCv1のしきい値（デフォルト -70 dBm）以上のネイバー用に作成されます。

推奨内容が検証されると、TPCv1での実装のために APに渡されます。Txの現在値を Txの理想値に合わせるには、電力が 12 dB削減される必要があるとします。すべてのケースにおいて、各TPCv1サイクル中に、電力が 3 dB（1ステップ）ずつ削減されます。そして、TPCv1の次の実行で、プロセス全体が繰り返され、まだ電力の変更が必要な場合は、3 dBの手順がもう一度適用されます。プロセスは、TXの増強を実施する際も同じです。1回の繰り返しごとに電力レベルが 1つ適用され、評価されます。

DCAのように、TPCv1は RFグループリーダー上で実行され、DCAの変更は TPCv1の変更に影響し、またその逆も起こります。したがって、インフラストラクチャのバランスを取るためにそ

れらを連携させることをお勧めします。TPCv1は DCAと同じ間隔で動作し、デフォルトでは 10分ごとです。TPCv1にはチャネルの情報がなく、ネイバーエントリは常に同じチャネル内にあると仮定します（DCAは独立して動作するので、合理的です）。


伝送パワーコントロール（TPC）アルゴリズム推奨電力変更の実装

オンデマンドモードでは、定期的にスケジュールされた次の区切りでTPCv1が動作するようにスケジュールされます。TPCv1が次の 10分間に実行されますが、計算は保留され、TPCv1が実行されないか、再度オンデマンドが選択されるまで更新されません。

すべてのAPが最初に起動する（新規に初期設定される）際には、最大電力レベル（電力レベル 1）で送信されます。APの電源が再投入されたりリブートされたりすると、前回設定された電力設定を使用します。伝送パワーコントロールによる調整が、その後必要に応じて実施

されます。

（注）

TPCv2外見上、TPCv2はユーザからはほとんど見えず、実際、GUIでは TPCv1に関連する同じ設定パラメータを共有しています。ただし、内部では大きく異なります。まず、第 3ネイバー方式は使用されず、TPCv1のネイバーリスト以外は何も使用されません。主な相違点は、TPCv1が隣接 APで測定された受信エネルギーに基づいていることです。TPCv2は、2つの AP間で測定された RFの距離に基づいて AP間のセル境界を計算し、その計算に基づいてカバレッジを最適化します。

図 26： TPCv2 の例：2 つの AP がある場合

解決すべき問題は、箱をボールで満たす問題に似ています。大きなボールを詰めると箱はすぐに

満たされますが、ボールとボールの間には、さらにボールを詰めることができる大きな隙間が残

ります。そのため、より小さいボールをさらに詰めて隙間を満たすことになります。これは基本

的に、最大セルラーカバレッジを知ることで解決できる問題と同じです。大きなボールを使用す

ると箱はすぐに満たされますが、大きな隙間が残ります。したがって、提供されるカバレッジを

最大化するために、式を使ってすべてのボールの最適なサイズを求めます。このソリューション



では、セルサイズを増減し、オーバーラップを考慮することで、可変サイズのセルを配置して最

適なカバレッジを求めます。

図 27： TPCv2 の例：複数の AP に関する結果

TPCv2の実行が完了すると、電力の変化が継続的に処理されます。1つのサイクルで特定のAPの電力を増加または低減する必要があると判断された場合、アルゴリズムは Ideal_TXに達するまで電力の調整を続行し、結果を再確認します。TPCv2は、チャネルに関係なく、すべての APのネイバーが同等であると見なして動作します（デフォルトモード）。チャネルモードでは、解決す

るAPと「同じ」チャネル上にあるAPのみが考慮されます。チャネルモードはRFグループリーダーのコマンドラインでのみ有効になります。チャネルモードは高密度展開に適しています。同

じチャネル上にある 2つの AP間のカバレッジと信号が最大化されると同時に、同一チャネル干渉が最小化されるからです。隣接チャネル干渉は DCAによって対処されます。(Cisco Controller) >config advanced 802.11a tpcv2-per-chan enable/disable (disabled bydefault).

チャネルモードを使用すると、電力が大幅に増加します。

TPCv2は無線ユーティリティ機能も追加します。このアルゴリズムを実行すると、解決に至るさまざまな電力の組み合わせがモデル化されます。その際に、アルゴリズムは特定の無線のユーティ

リティを追跡します。TPCv2の実行は、TPCインターバル（600秒）ごとに 10回繰り返されます。特定の無線が 10のソリューションのうち 3つだけを必要としている場合、その無線は 30 %



ユーティリティとしてマークされます。show advanced 802.11a/b sumコマンドを使用して、この結果を確認できます。

(Cisco Controller) >show advanced 802.11b sumLeader RRM Information----------------------AP_1 : [b2:8d:80] Ch 6* TxPower 1dBm (Level 8)* CHDM 0dBm AP Util 0% dBm[22/19/16/13/10/7/4/1]

RxNbrs:: total 5[ 3:-20][ 6:-27][ 5:-30][ 4:-41][ 2:-49]TxNbrs:: total 5[ 3:-23][ 6:-23][ 5:-28][ 4:-44][ 2:-46]

AP_2 : [43:4d:50] Ch 1* TxPower 7dBm (Level 6)* CHDM 0dBm AP Util 30% dBm[22/19/16/13/10/7/4/.]


AP_3 : [ba:19:40] Ch 11 TxPower 7dBm (Level 6) CHDM 0dBm AP Util 100% dBm[22/19/16/13/10/7/./.]


AP_4 : [b4:20:60] Ch 6* TxPower 20dBm (Level 2)* CHDM 0dBm AP Util 70% dBm[23/20/17/14/11/8/5/2]


AP_5 : [b4:20: 0] Ch 1 TxPower 20dBm (Level 2) CHDM 0dBm AP Util 100% dBm[23/20/17/14/11/8/5/2]


AP_6 : [cc:d4:20] Ch 6* TxPower -1dBm (Level 8)* CHDM 0dBm AP Util 0% dBm[20/17/14/11/8/5/2/-1]


この showコマンドで表示されるその他のデータとして、APBSSIDの最後の 3オクテット、各APのRXネイバーおよびTXネイバーの数と値などがあります。たとえば、AP_1に合計5つのRxNbrsがあり、最も近い RXネイバーが -21 dBmの AP3であると想定します。これは非常に有用な出力結果です。上記の例のような過度に高密度の状況で 2.4 GHz無線を遮断する場合に、この出力を使用して APを選択することができます。上記の例の場合は、6つの APのうち 3つを使用して最適なカバレッジを得ることができます。

無線を遮断する前に、必要なカバレッジ要件を十分に理解し、マッピングにおけるAPの位置とカバレッジを確認することを強く推奨します。この情報は単なるガイドとして使用してくだ

さい。

（注）

知る必要があるその他の showコマンドは次のとおりです。show advanced 802.11a/b txpower

(Cisco Controller) >show advanced 802.11b txpower

Leader Automatic Transmit Power AssignmentTransmit Power Assignment Mode................. AUTOTransmit Power Update Interval................. 600 secondsTransmit Power Threshold....................... -70 dBmTransmit Power Neighbor Count.................. 3 APsMin Transmit Power............................. -10 dBmMax Transmit Power............................. 30 dBmUpdate ContributionNoise........................................ EnableInterference................................. EnableLoad......................................... DisableDevice Aware................................. Disable

Transmit Power Assignment Leader............... Cisco_69:9a:64 (192.168.10.8) (::)Last Run....................................... 539 seconds agoLast Run Time.................................. 0 secondsTPC Mode....................................... Version 2 Per-Channel NOTPCv2 Target RSSI.............................. -67 dBm



TPCv2 VoWLAN Guide RSSI........................ -67.0 dBmTPCv2 SOP...................................... -85.0 dBmTPCv2 Default Client Ant Gain.................. 0.0 dBiTPCv2 Path Loss Decay Factor................... 3.6TPCv2 Search Intensity......................... 10 Iterations

TPCv2 Plan Quality Index.................. Overall -0.5 Coverage 33.2 CCI 3.0 Ratio 1.0TPCv2 Target Plan.............................. To be reached in 7 TPC runs

AP Name Channel TxPower Allowed Power Levels-------------------------------- ---------- ------------- ------------------------upstairs_3602e *1 *7/7 ( 4 dBm) [22/19/16/13/10/7/4/4]AP_2702E *6 *8/8 ( 1 dBm) [22/19/16/13/10/7/4/1]downac 1 2/8 (20 dBm) [23/20/17/14/11/8/5/2]upac *6 *2/8 (20 dBm) [23/20/17/14/11/8/5/2]NOS_3600 1 6/7 ( 7 dBm) [22/19/16/13/10/7/4/4]AP_3502 *6 *8/8 (-1 dBm) [20/17/14/11/8/5/2/-1]1602I_.560e.1b97 11 6/6 ( 7 dBm) [22/19/16/13/10/7/7/7]

このコマンドはTPCv1とTPCv2の両方の設定を表示し、どちらが使用されているかを識別します（1つだけ使用可能）。また、グローバル設定の場合には、TPCのしきい値と TPCv2ターゲットRSSIが設定されている個所も識別します。TPCv1しきい値と TPCv2ターゲット RSSIは RFプロファイル内に別々に設定できますが、このコマンドでは表示されません。また、showコマンドは、使用可能電力と現在の電力レベルと共に、すべてのAPを一覧表示します。留意すべき点は、使用可能電力は現在のチャネル割り当てを対象にしているということです。次の例は、5Ghzでの相違を示しています。

AP Name Channel TxPower Allowed Power Levels-------------------------------- ---------- ------------- ------------------------upstairs_3602e *(36,40) *2/5 (11 dBm) [14/11/8/5/2/2/2/2]AP_2702E *(64,60,52,56) *1/6 (17 dBm) [17/14/11/8/5/2/2/2]downac *(149,153,157,161) *1/8 (23 dBm) [23/20/17/14/11/8/5/2]upac *(149,153,157,161) *4/8 (14 dBm) [23/20/17/14/11/8/5/2]NOS_3600 *36 5/5 ( 2 dBm) [14/11/8/5/2/2/2/2]AP_3502 *(36,40) *6/7 ( 2 dBm) [17/14/11/8/5/2/-1/0]1602I_.560e.1b97 *(100,104) *1/4 (17 dBm) [17/14/11/8/8/8/8/8]

TPC の最小/最大選択した TPC方式に関係なく、使用可能な最大電力設定または最小電力設定を制限することができます。TPCの最小/最大は、TPCとは異なり、すべてのコントローラで実行される設定です。この機能は、電力の過剰な上昇や低下を防ぐ安全策として設計されました。この機能を使用すると、

TPCが無線に供給している電力に関係なく、電力が最大を上回る場合や最小を下回る場合に、グローバル割り当てよりも TPCの最大値または最小値が優先されます。

なぜこれを実行する必要があるのでしょうか。それは、希望する場所に常に APが設置されているわけではないからです。この機能の作成対象となった標準的な使用事例では、すべての APが中央廊下に設置され、ホールの両側が対象カバレッジとなっています。廊下では APが互いを適切に認識できるという理由で、AP間の条件に合わせて電力を低減すると、強度不足によりホールの両側にある部屋の端まで電力が達しなくなる可能性があります。APを部屋に移動し、ホールの下にずらして配置するのは適切な解決策ですが、さまざまな理由によってそれが不可能な場合が

あります。そのような場合は、TPCの最小値を使用すると、ユーザに到達するために必要な電力レベルを維持させることができます。これによって廊下での同一チャネル干渉は増加しますが、

廊下にいるユーザはごく少数です。

この機能の使用に適した場所のもう 1つの例は、高密度用に設定されている講堂や教室です。RFが使い尽くされ、部屋が満員になると、フロアでの RFエネルギーの量が 5 dB減衰され、非常に


伝送パワーコントロール（TPC）アルゴリズムTPC の最小/最大

高密度なケースでは 10 dBほど減衰されます。部屋が空になると、伝搬が改善されるのでAPの電力レベルが低下し、部屋が満員になると、より多くの電力（5～10dB以上）が必要になります。ガイドラインなしで TPCによってこれに対処すると、最終的には十分な電力が供給されますが、1時間のクラスへの供給に 30分かかる可能性があります。満員のクラスに必要なレベルでTPCを最小に設定すると、クラスの開始時に十分な信号を確保できます。それ以外の場合は常に APの信号レベルが強くなりますが、その間は未使用の APのみがビーコンを送信し、干渉が最小限になるので問題ありません。

TPCの最小および最大の設定は、電力レベルインデックスではなく、dBm単位で入力します。そのためには、設定する APモデルの使用可能電力を把握しておく必要があります。電力レベルインデックスの範囲は 1～ 8です（APの最大電力（1）から最小電力（8）まで）。一部の APは電力レベル 8に対応していません。APが送信できる最大電力は帯域に応じて異なり、5 GHzでは、UNii1帯域（チャネル 36～ 48）で最小、Unii2と Unii2e（52～ 64、100～ 140）で増加し、Unii3（149～ 165）で最大になります。3つの範囲すべてにおいて選択がサポートされると想定した場合、この値を dBm単位で入力する利点は、チャネルに関係なく、すべての APで同じ電力が示されることです。それ以外の場合、APは、入力された dBm値に最も近い帯域で APがサポート可能な電力レベルに設定されます。APで使用可能な電力のリストは、APでサポート可能な電力レベルです。ネットワーク上の APの使用可能電力を確認するには、コントローラの CLIで詳細な802.11a/bサマリーを表示します。APのチャネルと使用可能電力の両方が表示されます。AP CLIで、コントローラ d0/d1を表示します（d0=2.4と d1=5 GHz）。

AP 2702e：このリストは以下のようになります。

UNii1–15,12,9,6,3 dBm (5 levels 1-5 supported)

UNii2/e–17,14,11,8,5,2 dBm (6 levels 1-6 supported)

UNii3–17,14,11,8,5,2 dBm (6 levels 1-6 supported)

3702eは次のようになります。

UNii1–15,12,9,6,3 dBm (5 levels 1-5 supported)

UNii2/e–17,14,11,8,5,2 dBm (6 levels 1-6 supported)

UNii3–23,20,17,14,11,8,5,2 dBm (8 levels 1-8 supported)

電力レベル 1は、6Mbpsで実施可能な最大電力に常に関連しています（BF（ビーム形成）以外）



TCPの最小値または最大値は、GUIの [Wireless] > [ 802.11a] > [RRM] > [Tx Power Control(TPC)]で入力できます。

図 28： TPC 設定ダイアログ（WLC GUI）

これは、RRMの RFプロファイル内でもサポートされています。

図 29： RRM 設定ダイアログの RF プロファイル（WLC）

TPCの最小/最大値は、使用しているTPCバージョンに関係なく適用されます。上記の例では、デフォルト値として、最大値 = 30 dBm、最小値 = -10 dBmとなっていますが、APがこれらの電力レベルをサポートしていない場合はオフになります。

これはコントローラ/RFプロファイル単位の設定です。RFグループ内のすべての APに適用されるわけではなく、設定が行われたコントローラのローカル APにのみ適用されます。



第 8 章

カバレッジホール検出軽減アルゴリズム

カバレッジホール検出軽減アルゴリズムは、4つの機能を担っています。

1 カバレッジホールの検出

2 カバレッジホールの検証

3 軽減（将来に備える場合）

最優先事項はカバレッジホールの検出です。その次が、電力/カバレッジを増加してカバレッジホールを軽減することです（可能かつ適切な場合）。CHDMは、RRMや RFグループリーダーとは無関係に実行されます。ローカルレベルでの決定を促すために、すべてのコントローラ上

で実行されます。個々のコントローラは、関連するすべてのAPを監視するだけではなく、すべての接続クライアントとそれらの受信信号レベルも監視して、カバレッジホールの検出を実行

します。軽減するには、APまたは APグループの電力を増加して、クライアント信号がカスタマー選択可能しきい値を下回るエリアのカバレッジレベルを改善する必要があります。

当初、カバレッジホールアルゴリズムは、ネットワークの拡大と変化に合わせて、管理者がカ

バレッジ要件を評価するための手段として設計されました。カバレッジホールの警告を監視す

ることにより、管理者は、APの追加や既存インベントリの再割り当てが必要なネットワーク領域を効率的に追跡して特定することができます。ネットワーク拡大の動的な特性を考えると、こ

れは有益です。カバレッジホールの軽減は、カバレッジの短時間の低下に対処する方法として

構想されました。必要に応じて既存アセットの到達範囲を拡大して、必要なカバレッジを一時的

に増加することにより対処します。これによりAPが故障した場合の耐障害性が向上するので、適切に設計された十分な高密のネットワークに信頼性という利点が加わります。

• カバレッジホールの検出（CHD） , 90 ページ

• カバレッジホールの軽減 , 91 ページ

• ローミングの最適化, 91 ページ


カバレッジホールの検出（CHD）カバレッジホールの検出は、APで保持される各クライアントの受信 RSSI値の 5秒間（CHD測定期間）のヒストグラムに基づいています。-90 dBmから -60 dBmの間の値が 1 dB間隔のヒストグラムで収集されます。5秒間の間に、設定されたRSSIしきい値を下回ったクライアントが、プレカバレッジホールイベントとしてマークされます。プレカバレッジホールは即座にWLCに報告され、Primeによってアップストリームが追跡されます。Primeでは、管理者がプレカバレッジホールアラームを参照し、ロケーションアプライアンスでマップ上のプレカバレッジホールの

場所を確認できます。

プレカバレッジホールの段階では、軽減のアクションは実施されません。プレカバレッジホール

は、WLCで 90秒間の累積ヒストグラムで追跡されます。プレプレカバレッジホールは、90秒間の間すべてでしきい値未満での動作が継続された場合、カバレッジホールと見なされます。

カバレッジホールの検出は、APによって監視されるアップストリームの RSSIメトリックに基づきます。設定可能な値は次のとおりです。

•データ RSSI（- 60から -90 dBm）デフォルト -80

•音声 RSSI（- 60から -90 dBm）デフォルト -75

• APごとの障害クライアントの最小数（1 - 75）デフォルト 3

• APごとのカバレッジ例外レベル（1 - 100 %）デフォルト 25 %

RSSIの値では、受信しきい値の最小値が音声とデータの両方でそれぞれに設定されます。APごとの障害クライアントの最小数は、カバレッジ例外レベルを用いて軽減が判断される以前に、カ

バレッジホール内に必要とされるクライアントの最小数で決定されます。カバレッジ例外レベル

には、軽減が判断される上で、カバレッジホール名に必要となるクライアント全体の割合が設定

されています。軽減が判断されるには、カバレッジホールで、障害クライアントの最小数とカバ

レッジ例外レベルの両方の条件が満たされる必要があります。

（障害クライアント数 >= 3）かつ（障害クライアント>= 25 %）=軽減

これは、カバレッジホールの検出の際に、それが最適であることを確認し、誤検知でないことを

保障する上で重要です。誤検出は、単にローミングロジックの精度が低く、適切な APオプションに移ることを拒むクライアントが原因で起こります。これはスティッキクライアントと呼ばれ

ます。

個々のクライアントのしきい値の設定には、追加の粒度の設定もあります。APで追跡されるのは、アルゴリズムによって確立されたRSSIのしきい値を下回るパケットの総数です。2つの値がWLCから APに渡され、しきい値を満たさないパケットの評価に使用されます。

• Num_Failed_Packets：5秒間の CHD測定期間中に、関連する音声またはデータクライアントタイプの RSSIしきい値を下回った受信パケットの数

• %_failed_Packets：CHD測定期間中に、しきい値を下回った総受信パケット数の割合



カバレッジホールの検出（CHD）

プリカバレッジホールアラームの状態にあると見なされるには、これらの条件の両方がクライア

ントで満たされている必要があります。これらの値は CLIでのみ設定可能で、変更すべき明確な理由がない限りデフォルト値を使用するべきです。

音声クライアントとデータクライアントが、WMMUP（ユーザプライオリティ）に基づいて別々に追跡されることに注意くださいクライアントから受信される各パケットが評価されます。これ

は、CLIで使用できる追加の設定値を通じて実行されます。

APでは、5秒間の結果が、90秒の累積ヒストグラムで収集され、90秒ごとに、この情報が IAPPメッセージでWLCに送信され、ヒストグラムがリセットされます。クライアントが 90秒間、プリアラーム状態のままである場合は、WLCでカバレッジホールと見なされます。次に、WLCは、クライアントに使用されていないローミングオプションがあるかどうかを最初に確認して、その

カバレッジホールが軽減可能かどうか、または軽減すべきかを判断します。これは、クライアン

トの場所の判断、および受信できる他の APの RSSIを評価することで確認されます。他の APがしきい値を超えるクライアントと通信する場合、レポートには誤りのマークが付けられ、アラー

ムがリセットされます。

カバレッジホールの軽減カバレッジホールの軽減は、一度軽減が決定されれば非常にシンプルなプロセスです。カバレッ

ジホールが存在し、かつ軽減の基準（クライアントの最小の数および最小の割合）が満たされて

いれば、一度の手順で APの電力が増加します。その後、CHDMが動作し続け、追加の軽減が求められた場合は、再度評価が行われ、電力が 1回の手順で再び増やされます。これにより、電力の極端な変動や不安定な変動を防ぎます。カバレッジホールの軽減は、RRMのDCAやTPCとは独立して動作し、周囲のAPや環境内のRFのバランスに大きな影響を与えます。軽減の決定に際しては、軽減が成功するかどうかの評価も必要です。RFグループのメトリックを考慮せずに特定のAPの電力を増大させると、周囲のAPに悪影響を及ぼす可能性があります。したがって、軽減は慎重に適用されます。新しい検出メトリックと軽減による電力制限を組み合わせることで、非

常に安定したアルゴリズムとなります。

ローミングの最適化ローミングの最適化はバージョン 8.0のコードで導入されました。ここでは機能の詳細には触れません（『High Density Experience deployment guide』を参照してください）が、CHDMからデータ RSSIのしきい値設定を参照し、クライアントが現在のAPの無線との連携を段階的に中断するための最適化されたローミングのしきい値を設定します。ローミングの最適化を有効にすると、

データ RSSIカバレッジホール検出を無効にします。



カバレッジホールの軽減




ローミングの最適化

第 9 章

RF プロファイル

このドキュメントでは、さまざまなアルゴリズムおよびそれらの機能との関連において RFプロファイルを説明しています。ここでは、重要事項である RFプロファイルとそれらの使用ルールについて簡単に説明します。まず、システムに実装されている制御の階層に立ち返ってみると、

WLCまたは RFグループに接続しているすべての APに影響する機能を含むグローバルレベルがあります。RRMではその下には RFプロファイルがあります。RFプロファイルはグローバルレベルでの選択からプロパティを継承しますが、APグループ内のアクセスポイントのグループに対する動作を制限したり変更することができます。RFプロファイルで、またはRFプロファイルに対してオプションを使用可能にするには、多くの場合、最初にグローバルレベルでオプショ


ンを有効にする必要があります。ここでは、RRMおよびその機能との関連においてRFプロファイルを説明します。

図 30： RF プロファイル：RRM 設定ダイアログ（WLC）

• TPC , 94 ページ

• DCA, 95 ページ

• カバレッジホール検出 , 95 ページ

• トラップのプロファイルしきい値 , 96 ページ

TPCRFプロファイルレベルで、最小と最大の TPC電力レベルを個別に割り当てることができます。これは、プロファイルが割り当てられている APグループ内の APにのみ影響します。このアプローチを使用すると、最小または最大の TPCエントリの値を増減することによって、一度に AP


RF プロファイルTPC

グループ全体の電力を増減することができます。TPC自体の役割は、標準的な設置環境に適したレベルに電力を調整して維持することです。これは、収容ユーザの増加に合わせてSNRが変化する新しい高密度実装を調整する上で非常に役立ちます。

また、TPCv1またはTPCv2での使用に対して異なる電力しきい値を割り当てることもできます。TPCバージョンの選択はグローバルRFグループレベルでのみ行うことができ、一度決定すると、同じバージョンが RFグループ全体で使用されます。RFプロファイルではグローバル設定とは異なる TPCバージョンを実行できません。ただし、環境の要件に合わせて対象の RSSIまたはしきい値を調整できます。これは、天井が他よりも著しく高いエリア（倉庫など）が設置環境内にあ

る場合に役立ちます。天井が高い環境に合わせてTPC電力しきい値を増加すると、フロアレベルで必要なカバレッジを実現することができます。

DCADCAアルゴリズムへの外部のAP干渉による影響の回避を有効もしくは無効にできます。これは、不正な干渉源が多数をしめるエリアにおいて非常に有用です。

また、DCAが特に APグループのみに割り当てる帯域幅の選択を変更できます。たとえば、ほとんどの導入で設定が 40 MHzチャネル用になっている一方、特定の領域では、20 MHz（高密度環境など）や80MHz（サーバに大きなファイルが保存されている教室など）だけをサポートしなければならず、結果的にそうしたい場合などです。

また、DCAチャネルのリストを変更することもできます。チャネルはカスタマイズできますが、まず、RFグループリーダーであるWLCで、グローバル DCAアルゴリズムを有効にする必要があります。同様に、RFプロファイルで利用可能とするために、RFプロファイルを実行しているローカルのWLCでも有効にする必要があります（GLとは異なる場合）。これには、複数の実用的な用途があります。

1 複数の国に導入する場合の管理

2 使用例に基づいたチャネルグループの割り当て

3 ローカルで問題のあるチャネルの削除（干渉の回避など）

4 状況に応じた UNii2eチャネルの許可または禁止

カバレッジホール検出カバレッジホールを定義することは、目的のカバレッジエリアに問題が存在する際にアラートを

出すことを目的としているため、アーキテクチャに非常に依存します。カバレッジエリアはアー

キテクチャによって大きく異なります。RFプロファイルを通じて、異なるアーキテクチャに合わせてこれらの値をカスタマイズできます。

ローミングの最適化機能を使用する場合は、しきい値をカスタマイズして、インストールの密度

と一致するようにできます。RFプロファイルを通じてしきい値と機能を適用するには、ローミングの最適化をグローバルレベルで有効にする必要があります。


RF プロファイルDCA

トラップのプロファイルしきい値RRMが監視するメトリック用のトラップしきい値を、RFプロファイルを通じて同様にカスタマイズすることができます。トラップのしきい値はトラップの生成にのみ影響を与え、RRMの動作には影響しないことに注意してください。


RF プロファイルトラップのプロファイルしきい値

radio resource management に関するホワイトペーパー -...

Documents