ワイヤレスについて (Ask the Expert)

[CiscoJapanModerator]

シスコの技術サポートエンジニアへ質問して疑問を解決できる「エキスパートに質問」へようこそ！
ここでは、シスコのエキスパートからのアドバイスや最新の情報が得られる場として気軽にご質問ください。

担当エキスパート: 松村 一平(Kunitaka Matsumura)
Cisco Japan TAC のカスタマーサポートエンジニアとして、WLC, AP, Mobility Service Engine などの無線 LAN 関連製品をサポートしています。

開催期間: 1月5日（月）～1月18日（日）

[質問方法]
サポートコミュニティへ Cisco.com ID でログインすると、この説明の右下に「返信」ボタンが表示されます。クリックすると投稿欄が表示されますので、質問をご記入ください。最後に「メッセージの投稿」をクリックすると質問が送信され、完了となります。
も し１つの質疑応答が進行していても、他の新しい質問を同じスレッド内に投稿いただいて問題ありません。
ディスカッション期間を過ぎてからの投稿にはエキスパートは回答できません。事務局より、通常コミュニティへの再投稿をご案内いたしますことをご了承ください。

[エキスパートからの回答について]
質 問の投稿から原則数日以内に回答できるよう努めます。内容によっては、検証や確認に時間がかかる場合もありますのでご了承ください。質問の内容によって は、エキスパートの担当範囲外の場合もございます。その際はサポートコミュニティ事務局、もしくは適切な担当から回答いたします。
エキスパートから返信が得られた質問については、評価機能でその回答が適切であったかをエ キスパートへぜひ伝えてください。

[r-kawai01]

ユーザ先で構成しているAironet1142を用いた無線LANで、原因不明な現象があり、対処法を質問します。

　・41台のAironet1142をAPとして、イントラネットの職員用VLANとゲスト持込み端末用VLANにWiFi接続させるネットワークを構成しています。接続手順は以下の通りです。

　　-ゲスト端末→（SSID、Ｐａｓｓｗｄ）→AP→（ＤＨＣＰ要求）→ＳｏｎｉｃＷａｌｌ-NSA4500（VLANインターネット接続許可）

　　-職員端末→（SSID、Ｐａｓｓｗｄ）→AP→（ＤＨＣＰ要求）→NetAttest-EPS-ST04（ユーザ認証）→ADサーバ（認証・VLAN許可）

　・ゲストの持込み端末機種がスマホ（Andorid、iOS）やPCなど多様なために、2.4GHzと5GHzを併用して利用できるようにしていたところ、下記の不具合が発生した。

　・帯域を併用することに起因する問題かどうか切り分けるために、一部のAPでは2.4GHzをやめて5GHzのみで利用するようにして様子を見ているが、どちらの設定のAPでも同じ不具合が発生する。発生頻度は各APで月に1回程度。

【挙動パターン】

　・ユーザ持込み端末で、APにWiFi接続できなくなる。できなくなるきっかけは不明。職員の端末は基本的にPC（Windows、iOS）であるが、問題は起きない。ユーザ持込み端末はスマホが多い。

　・アンテナの電波強度は通常状態で問題はない場合と、電波が出ていない場合がある。

　・WiFi端末がAPのすぐ近くにあっても、LED表示が緑色（接続なし）のまま変化せず。

　・その状態でも、1142に対してイントラネット側から有線LAN経由で1142にブラウザやtelnetで接続できる。

　・ログの表記は不具合発生時点以降の記録が途絶えている。

【応急処置状況】

　・ログが半日以上記録されていない、アソシエーションの欄に端末のMACアドレスが上がっていない（接続がない）という条件を確　認してから、応急処置として、無線AP本体を再起動することで復旧させている。

【質問】

　・このような現象の事例はありますか？

　・AP単体の問題なのか、構成するイントラ側含めたネットワーク全体での問題なのか、切り分ける方法がありますか？

　・対処についてアドバイスいただきたい。

[Kunitaka Matsumura]

ご質問ありがとうございます。

頂いている情報からだけでは具体的にどのような問題が発生しているかは判断は難しいですが、
AP の無線インターフェースがダウンしている、或いはハングしている可能性が考えられます。

> ログの表記は不具合発生時点以降の記録が途絶えている。

> 無線AP本体を再起動することで復旧させている

--> これらの状況から、AP 自体に何かしらの問題が発生している可能性が考えられます。

認証サーバやクライアント側の問題である可能性もございますが、
申告頂いている内容から AP の問題である可能性が高い印象です。

> その状態でも、1142に対してイントラネット側から有線LAN経由で1142にブラウザやtelnetで接続できる。

--> 無線接続ができない一方で有線側での通信には問題がなさそうなことから、
  無線側のインターフェースで問題が発生している可能性が考えられます。

// ご質問への回答 //

> ・このような現象の事例はありますか？

無線インターフェースがダウン、或いはハングすることで、
ご利用頂いている端末の無線接続ができなくなる事例は様々ございます。

また無線インターフェースの問題に限らなければ、
ご申告頂いているような不定期に無線接続ができなくなる事例は多々報告されています。

>・AP単体の問題なのか、構成するイントラ側含めたネットワーク全体での問題なのか、切り分ける方法がありますか？

AP と認証サーバ間の有線パケットキャプチャから、
端末からの認証リクエストを確認することである程度の切り分けが可能です。

AP に問題があり無線インターフェースがダウンしている場合や、
AP が認証リクエストのパケットをドロップしている場合などは、
有線パケットキャプチャからこのパケットが確認できないはずです。

>・対処についてアドバイスいただきたい。

(1) まずは問題発生時の無線インターフェースの状態を確認してはどうでしょうか。

Telnet で AP にアクセスして頂き、show ip int brief コマンドにより各インターフェースの Status が
確認できます。

 [サンプル]
 > ap#sh ip int brief
 > Interface                         IP-Address      OK? Method Status                Protocol
 > BVI1                                 **.**.**.**     YES TFTP   down                  down
 > Dot11Radio0                unassigned      YES unset  administratively down down
 > Dot11Radio1                unassigned      YES unset  administratively down down
 > GigabitEthernet0           unassigned      YES TFTP   up                    down

無線インターフェースのダウンが確認できましたら、AP の問題であることがはっきりし、
問題事象もより明確になります。

(2) ソフトウェアをバージョンアップし問題が収束するかの確認

ご利用頂いているソフトウェアのバージョンは存じませんが、最新バージョンではない場合、
様々な既知の問題の修正が含まれている最新バージョンにソフトウェアを更新することも、
(1) の結果に関わらず有効な対処法のひとつとなります。

[r-kawai01]

早速の回答ありがとうございました。私自身はSEではありませんので、いただいたアドバイスを現場SEに提示して、分析してもらいます。情報や状況に進展があれば再度ご相談させていただくかもしれませんので、よろしくお願いいたします。

[yrz462]

いつもお世話になっております。
Rx SOP および CCA についてご教授お願いします。
質問の背景には、この二つの機能で何が違うのか不明なところからの質問となります。
質問の中心は RxSOPですが、CCAについても情報ございましたら合わせてお願いします。

(1) Rx SOPは、非Wi-Fi信号についても機能するものでしょうか。

(2) Wi-Fi信号においては、機能名通り、しきい値以上の信号からデコードをするなどの記載あり、
検証上の動作確認でもしきい値以下の信号を受信しないので、送信側は再送を繰り返す動きを確認しています。
この機能による送信効率メリットに関することが色々なドキュメントで読んだことがあるのですが、RxSOPは、
信号を傍受自体はしてしまうので、物理キャリアセンスの影響（傍受中の送信待機）を受けるのは同じだが、
デコードはしないので仮想キャリアセンスの影響（NAVによる待機時間）を受けず、
AP自身はより早くフレームを送信することができので、送信効率が良くなると認識していますが、
どこまで合っていますでしょうか。

(3) CCAは、Wi-Fi信号および 非Wi-Fi信号両方、またはどちらかにおいて、
    物理キャリアセンスを無視する、無条件に空きチャネル判定する機能と考えていいでしょうか。

[Kunitaka Matsumura]

ご質問ありがとうございます。

> (1) Rx SOPは、非Wi-Fi信号についても機能するものでしょうか。
機能しません。

> (2) Wi-Fi信号においては、機能名通り、しきい値以上の信号からデコードをするなどの記載あり、
> 検証上の動作確認でもしきい値以下の信号を受信しないので、送信側は再送を繰り返す動きを確認しています。
> この機能による送信効率メリットに関することが色々なドキュメントで読んだことがあるのですが、RxSOPは、
> 信号を傍受自体はしてしまうので、物理キャリアセンスの影響（傍受中の送信待機）を受けるのは同じだが、
> デコードはしないので仮想キャリアセンスの影響（NAVによる待機時間）を受けず、
> AP自身はより早くフレームを送信することができので、送信効率が良くなると認識していますが、
> どこまで合っていますでしょうか。

// キャリアセンスについて //

無線通信は半二重通信であり、事前に衝突を回避する CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) 方式を採用しています。

そのため、各無線端末はパケットを送信する前に、使用しているチャネルの空き状況を確認する必要があり、
その仕組みが言及されている(1)物理キャリアセンスと(2)仮想キャリアセンスとなります。

(1) 物理キャリアセンスは、センシングしているチャネルが利用されている場合は busy ステータスとなり、
利用されていない場合は idle ステータスとなります。利用されているかどうかの判断基準は、検知した 802.11 パケットの RSSI がしきい値を超えるかどうかです。利用されていると判断した場合は、一定期間 busy ステータスで待機をします。

(2) 仮想キャリアセンスは、Network Allocation Vector (NAV) とも呼ばれ、カウントダウンタイマー形式の仕組みとなります。保持しているタイマーがゼロではない間は、チャネルが利用されていると判断し、端末は待機し続けます。タイマーの値には、検知した 802.11 フレームヘッダに含まれる Duration Value がセットされます ( 一部フレームには例外として異なる動作をします)。 この時、検知したフレームを復調するのに十分な RSSI が得られていることが条件となります。

重要な点は、物理キャリアセンスと仮想キャリアセンスの結果がどちらも idle でなければ、
端末は送信を開始しないことです。

// Rx SOP について  //

さて、ご質問頂いている Rx SOP ですが、
上述したキャリアセンスにより検知する信号の RSSI しきい値を設定することができ、
特に高密度に AP が配置された環境において、チャネル利用率を改善し、APあたりの端末のスループットの改善が期待できる機能となります。

高密度に AP が配置されている場合問題となるのが、同一のチャネルを利用する AP の間隔が狭くなることにより、同一のチャネルを利用している他の AP が帯域を利用しているため AP が送信を待機しなければならない状況が多くなることです。その結果、AP あたりのチャネル利用率が低下し、AP あたりの端末のスループットが低下してしまいます。

チャネルが利用されているかどうかは、上述したキャリアセンスにより判断されます。
物理キャリアセンスの RSSI しきい値は -65dBm 程となりますが、仮想キャリアセンスの受信感度は AP の受信感度に依存し、例えばAP3700 の 2.4 GHz 帯なら最小 -101 dBm、5.0 GHz 帯なら最小 -90 dBm 程となり、信号検知可能な範囲が広く、同じチャネルを利用している他の AP の信号を検知しやすくなっています。

Rx SOP の設定により、例えばしきい値を -82 dBm と設定することで、チャネルセンスにより検知可能なセル範囲を狭め、同一のチャネルを利用する AP が近接する環境でも、AP あたりのチャネル利用率を高く保つことが可能となります。

> (3) CCAは、Wi-Fi信号および 非Wi-Fi信号両方、またはどちらかにおいて、
>     物理キャリアセンスを無視する、無条件に空きチャネル判定する機能と考えていいでしょうか。

Clear Channel Assessment (CCA) は物理キャリアセンスの仕組みとなります。
( 一般的には物理キャリアセンスが CCA のことだと思いますが、物理キャリアセンスを物理 CCA, 仮想キャリアセンスを仮想 CCA と表現しているものも見受けられ、定義や使われ方は曖昧な部分があるように感じてます)

Wi-Fi 信号のみに動作するものであり、具体的な動作は上述した物理キャリアセンスの説明をご参照下さい。

[yrz462]

回答ありがとうございます。
まだまだ疑問点や聞きたいことは多くありますが、
一旦こちらも検証しつつ理解し、不明点あればまた次回質問してみたいと思います。
今後ともよろしくお願い致します。

[Kouki Kimura]

周波数毎のChannelPowerについてご教授ください。

5GHz帯の最大出力は、電波法の兼ね合いもあり
W52/53/56 でそれぞれ出力が異なるかと思います。
例えば、AP2700は
W52/53/56 の最大出力が 16/12/20 dBm でした。

屋内で多くのチャネルを利用したい場合、
W52/53/56 混在で 19Channel を RRM で使うかと思いますが、
設計や事前のサーベイに懸念がございます。

例えば、事前サーベイにて
W56 Level2 (17dBm) 適切なカバレッジとして測定し終えたとして
実導入したとします。
ところが、チャネルの混雑等でそのAPがW53のチャネルに移動してしまうと
最大出力でも Level1 (12dBm) となってしまい
想定から5dBm も出力が下がってカバレッジ不足となってしまうかと思います。

設計やサーベイ時に上記のような懸念を回避する方法はございますでしょうか。

最初から W53 の MAX 値 (12dBm)を超えないように設計するのも
W52/56の高出力が使えなくて勿体無いです。
事前設計で、W52/53/56 をガチガチに固定設計するのも
せっかくのRRM機能が無駄になってしまいます。

また、AP 単体で 電力固定が PowerLevel でしかできないので、
チャネルが切り替わってしまうと上記のように
意図しない出力になってしまいます。
(Level4固定 : W52 = 7dBm → W56 = 11dBm 等)

何か設計や事前サーベイ時の注意点を
アドバイス頂ければ幸いです。

以上、よろしくお願い致します。

[Kunitaka Matsumura]

ご質問ありがとうございます。
ご返信遅くなりました。

まず、ご理解は頂けていると思いますが、
無線ネットワークのデザインは設計の要件や設置環境により様々であり、
申し訳ないのですが、この場で頂いている質問に適切な答えがお出しできるものではございません。

お伝え頂いている内容からシチュエーションをある程度想定しお答えしますが、
実際の状況とは異なる場合もございますので、あくまで参考程度に考えて頂けますと幸いです。

(1)
> 屋内で多くのチャネルを利用したい場合、
> W52/53/56 混在で 19 Channel を RRM で使うかと思いますが、

屋内で多くのチャネルが必要な場合として、会社の会議室やデスクスペースなど、
同時接続端末数が多く、AP を高密度に配置しサービスを展開したい場合がひとつ考えられます。

AP がサポートするデータレートは十分であったとしても、
AP あたりの同時接続端末数が多い場合、端末あたりのスループットが要件に満たないことがあり、
AP を高密度に配置することで端末あたりのスループットを改善させることが有効な対策のひとつとなります。

このとき問題となるのが、チャネル内干渉 ( Co-Channel Interference : CCI ) です。
通常よりも AP どうしの設置間隔が短くなるため、同じチャネルを利用する AP どうしの距離も短くなり、
AP どうしで干渉を引き起こしてしまう確率が高くなります。
利用するチャネルを出来るだけ多くすることで、同じチャネルを利用する AP の距離を広げ、
この状況をできるだけ回避することはできます。

今回想定した、高密度に AP を配置する場合は、
 - クライアントを出来るだけ最も近い AP にアソシエートさせるため
 - チャネル内干渉の影響を出来るだけおさえるため
に送信電力を抑え、AP のカバレッジを適切に抑えることが重要となります。

例えば AP 間の距離が 5 - 15 m 程の設定環境を想定し、おおまかに計算をすると、
最大でも送信電力が 9 dBm ほどあれば十分であることがわかります。

AP間距離(m)     AP-edge 間距離(m)    自由空間損失(dB)    必要送信電力(dBm)
                 5                                  3                         58.98                          1.98
                 7                                3.5                        60.68                          3.68
                10                               6.7                        62.95                          5.95
                15                             9.49                        65.97                          8.97

※ AP は 3m の高さの天井の設置されると仮定しています
※ カバレッジのオーバーラップは 20% で計算し、セル端の RSSI -67 dBm が所望と仮定しています
※ 送信アンテナ絶対利得は 0 dBi, 受信アンテナ絶対利得は -10 dBi, ケーブル損失は 0 dB, 周波数は 5 GHz で計算しています。

もちろんこれはあくまで理論上の計算であり、実際の伝搬特性などにより値は異なると思いますが、
最大 12dBm の送信電力でまかなえるのではと思います。

(2)
> 例えば、事前サーベイにてW56 Level2 (17dBm) 適切なカバレッジとして測定し終えたとして
> 実導入したとします。
> ところが、チャネルの混雑等でそのAPがW53のチャネルに移動してしまうと
> 最大出力でも Level1 (12dBm) となってしまい
> 想定から5dBm も出力が下がってカバレッジ不足となってしまうかと思います。

(1) と同じ計算式にあてはめて考えると、送信電力 17 dBm を各 AP が利用する場合、
AP 間距離はおよそ 40m とることができます。

AP 一台に同時接続するクライアントの数は少なく、出来るだけ少ない AP で広いエリアのサービスを
カバーしたい状況が想定されると思います。

AP 間の距離が長いため、チャネル内での干渉が発生する確率も低く、
高密度に配置した場合と比較し、少ないチャネル数でまかなうことが可能となります。

送信電力を維持し、AP のカバーエリアの広さを重視するのであれば、
送信電力の低い W53 のチャネルを DCA リストから除外し、
RRM により AP が W53 のチャネルに割り当てられないようにすることが
解決策になるかもしれません。

(3)
天井の高い屋内ホールでのイベントなど、
クライアント数が多いため、ある程度密度を濃く AP を配置する必要があり、
かつ高い送信電力を維持する必要がある状況が考えられます。

実際にどの程度の会場かはわかりませんが、12 dBm の送信電力では不足してしまうと想定します。

その場合は、指向性の高い送信アンテナを利用することが解決策になるかもしれません。
アンテナ利得により、送信電力が低いことによるカバレッジの不足が補えます。
また、アンテナの指向性をうまく利用することにより、チャネル内の干渉の影響も低く抑えることが可能です。

高密度なクライアント環境へのデザインガイドとして、以下のサイトも合わせてご参照ください。
http://www.cisco.com/c/en/us/products/collateral/wireless/aironet-1250-series/design_guide_c07-693245.html#wp9001287