LL Planetsで実現した無線LANインターネットの開放

大盛況ののちに幕を閉じた今年のLL Planetsでは、新しい試みとして無線LANによるインターネット接続を観客へ提供しました。

LLPLanetsのネットワーク構築にあたり、協賛ベンダ様よりネットワーク機材や回線を提供していただけたこと、ネットワークスタッフによる入念な計画・準備、そして本番運用中にきめ細かな調整を行ったことにより、観客へ安定した無線LAN接続を提供することができました。

本稿ではLL Planetsのネットワーク構築経験と、無線のノウハウを共有したいと思います。

2010年LL Tigerでの課題

2010年に開催されたLL Tigerでは、機材や準備の都合上、観客へのネット接続は提供することができず、観客がネット接続するには各自で回線を準備する必要がありました。そのため、近年流行しているポータブル無線APが予想以上に多く持ち込まれてしまい、最大で150局以上の無線APを観測しました。この状態は会場内の無線LANの帯域(802.11b/g)を枯渇させ、スタッフ・発表者用ネットワークに大きな影響を与えました。発表者はインターネット接続を用いたデモンストレーションを行うことが不可能となってしまい、LL Tigerの運営に支障をきたしてしまう事態となりました。

このことからLL Planetsでは、⁠安定した無線ネットワークの提供」について検討を重ねた結果、観客にネットワーク接続を提供することで、ポータブル無線APの電源をOFFにしてもらうしかないという結論に至りました。

LL Planetsの企画とIPv6

LL Planetsのセッションの1つとして、⁠IPv6ハッカソン」という企画がありました。この「IPv6ハッカソン」とは、IPv6ならではの面白いプログラムをLL Planetsの開催中に会場内で開発するというものです。このプログラムを開発・実行するには、IPv4だけでなくIPv6も同時利用できるネットワークが必須です。そこでLL Planetsでは、IPv4/v6の両方が使えるDualStackネットワークをNTT東日本 光フレッツネクストのIPv6接続サービスを用いて構築しました。

残念ながら、今回入手できたIPv6トンネル装置はコンシューマ向け製品であったため、観客へのIPv6ネットワーク提供は断念しました。そのためIPv4/v6のDualStackネットワークは、スタッフ・IPv6ハッカソン専用となりました。

無線機材準備

LL Planetsのスタッフ・登壇者の人数であれば、コンシューマ用の無線APでも性能的に問題はありません。しかし、観客全体を収容するとなれば話は違ってきます。会場には約300人を収容できますが、スマートフォンやタブレット端末が爆発的に普及しているので、1人あたり2端末と考えるのが妥当でしょう。

つまり、約600もの無線LAN端末を許容できる無線LANネットワークを構築する必要があります。他にも、同じ空間内で複数の無線APを設置するには欠かせない電波の出力調整機能や、レートリミット機能が必要であり、それらすべて管理するためにSNMPもサポートした高性能な業務用無線APが必須となりました。

LL Planetsはボランティアベースのイベントで、ほとんどの機材は個人所有機器の寄せ集めです。高性能な業務用無線APを何台も持っているスタッフなど見つかるわけもなく「今年も観客の無線LAN提供は難しいか」と、ネットワーク設計当初では諦めかけていました。そんな矢先、大手ネットワーク機器ベンダであるアライドテレシス様より、

  • 「高性能な無線APを提供できます。何台必要ですか?」

と、大変ありがたい声を掛けていただきました。また、無線LAN設置場所は電源確保が難しい場所だったこともあり、

  • 「お貸しいただける無線APはPoE[1]給電対応ですが、PoE給電スイッチも貸していただけないでしょうか?」

という、大変厚かましいお願いにも快諾していただけました。

こうして、無線AP10台、PoE給電L3S/W2台を借用できることになり、⁠IPv4/v6 DualStackネットワーク」「会場全員が利用できる無線ネットワーク」の2つの要件を満たすネットワーク構成を、図1のように構築することにしました。

図1 会場ネットワーク概要図
図1 会場ネットワーク概要図

無線の設計

安定した無線ネットワークを提供するには、設計をきちんとしておく必要があります。まずは、LL Tigerで経験したポータブル無線AP乱立による無線帯域の枯渇問題対策です。この問題に対して解決策は2つ考えられます。1つはポータブル無線APの持ち込みを制限すること、もう1つはポータブル無線APが使用する周波数帯域と異なる周波数帯域で無線ネットワークを構築することです。

前者の方法は現実的な解決方法ではないため、今回は後者の方法を実施しました。多くのポータブル無線APは802.11b/g(2.4GHz)を使用するため、802.11a(5.2GHz)を使用することにしました。しかし、単純に802.11aを用いるだけでは安定したネットワーク構築は難しく、いくつか注意すべき点があります。

802.11aを用いる場合の注意点

802.11aの周波数規格はW52、W53、W56の3つに分類されており、それぞれ周波数や屋内/屋外使用の可否、チャンネル数などが違います。屋内利用であればどの規格でも良さそうですが、実際に安定して使える規格はW52に限られます。これはW53,W56で用いられる周波数の一部が気象レーダの無線[2]と干渉してしまうためです。

W53、56を運用している無線APは気象レーダの電波を検出した際に「DFS(Dynamic Frequency Selection⁠⁠」機能により自動的に周波数を変更することが義務づけられています。この周波数の変更が行われた場合、一時的に通信が停止してしまうため、W53、W56の規格は安定した無線LANの構築には向いていません。表1はそれぞれの規格を比較したものです。

表1 802.11a周波数規格の比較
規格気象レーダとの干渉屋外利用Ch数
W52不可4
W53不可4
W5611

以上のことから、LL Planetsでは、802.11aのW52の規格のみを使用して図2のように配置しました。

図2 会場無線AP配置図
図2 会場無線AP配置図

図2のようにWAP-4とWAP-3、そしてWAP-1とWAP-6が同じチャンネルを使用しているため、できるだけ物理的に離れた場所に配置し、電波出力調整機能にて電波出力を最弱にすること、またレートリミット機能[3]を使用して接続スピードに制限を施すことにより、観客は物理的に最も近い無線APに繋がるよう配慮しました。

ネットワーク構築

LL Planetsのネットワーク構築はいかに素早く構築できるかが勝負でした。というのも、前日に会場でネットワーク構築ができる時間は無く、機材搬入・機器の配置・配線・疎通試験という一連の作業に与えられた時間は当日朝の50分だけだったのです。そのため、ルータ、L3スイッチ、PoEスイッチ、無線APは前日に全ての設定と接続テストを行っておくことで、ネットワーク構築時間をできる限り短縮しました。

また、当日の人員配置も入念に検討し、各機器、各場所ごとに担当を割り振り、設定した機器の設置および導通チェックを行いました。ステージだけは朝から使用するため、ネットワークスタッフ全員の手により最優先で構築を行い、その後にIPv6ハッカソン部屋、控え室の順にネットワークを提供しました。観客用のネットワークのみ、朝の時間帯だけでは無線APや配線を客席に設置する時間が足りなかったため昼からの提供となりましたが、その他のネットワークについては無事構築することができました。

写真1 準備風景
写真1 準備風景

無線ネットワーク

無線APの設置場所は壁際や床下を避け、なるべく人より高い位置に設置するのが理想とされていますが、テンポラリな環境で無線APを壁に設置することはできませんでした。この課題は計画当初は「諦めて座席に設置する」としていましたが、会場設営時に舞台裏で譜面台があるのを発見して「これは使える!」ということで採用しました。譜面台APの誕生です。

当日にすべてのネットワーク構築を行うため、無線APの電波出力をどの程度に設定するかは現地で運用中に調整するしかありません。そこで段階的に無線の電波出力を下げつつ、スタッフがPCを片手に電波出力を測定し、1つの無線APに接続が集中しないよう細かい調整を行いました。最終的には無線APの電波出力を1%にしてもまだ電波が強かったので、アンテナを物理的に寝かせてみたり、譜面台の高さを低くしたり、またレートリミット機能の接続スピードしきい値を54Mbpsのみに限定することで、最適なコンディションを作ることができました。

この電波出力の調整に手間取ってしまい、観客に無線LAN接続を提供できたのは前述した通り、お昼ごろまでずれ込みました。調整中にTwitter経由で「無線LAN接続はまだですか?」といった催促もあり、申し訳ない気持ちでいっぱいでした。

写真2 運用中の譜面台AP
写真2 運用中の譜面台AP

当日の運用

ネットワーク監視は、コアスイッチのsflowやMACアドレス登録数、DHCPのリース数、トラフィック量などの項目を対象としました。さらに、観客のネットワークに対する要望や状況をモニタする手段としてTwitterを活用しました。

Twitterでのネットワークモニタリングは大変有効であり、DHCPからIPが降ってこないといったトラブルの報告に、ネットワークスタッフは即座に原因究明を行うことができました。Twitterを一方的にモニタするだけでなく、会場無線LANの構築状況やSSID/Key情報などの情報発信も行いました。とくに「ネットワーク安定しています。ありがとう!」というような「お褒めツイート」をもらった時は非常に嬉しかったです。次回はホットステージの状況や、当日の構築状況・運用状況をより細かく、リアルタイムで報告することを検討しています。

無線LANを観客に提供するまでは、会場内ポータブル無線APは100局を超えている状態でしたが、提供開始から次第に減少して最終的に6局にまで減りました。この程度であれば無線帯域が枯渇することは無いと考え、また802.11b/gしか対応していない端末があるという声がTwitterで挙がっていた為、ネットワーク設計当初の予定になかったの802.11a,b/gの両方の無線規格を提供することができました。最終的に全体の接続数は平均170程度となり、十分な余力がある状態が続き、安定した無線ネットワークを提供することができました。

LL Planets閉会時には機材の回収・梱包・発送などを行わなければなりません。そのため閉会時から撤収作業を開始しても、時間が足りなかったので、閉会宣言の30分前から撤収を始めました。撤収作業には、無線APの回収も含まれていますが、セッションの最中にすべての無線APを撤去することは避けたかったので、ネットワークの輻輳覚悟で無線AP2台のみを残し、それ以外の無線APをすべて撤去しました。結果的に特に目立った通信トラブルは無く、たった2台になっても持ちこたえてくれました。改めて無線APの性能の高さを実感しました。

まとめ

無線は難しい

無線LANの回線は、LANケーブルのように目に見えるわけではなく、L1の段階で非常に気を遣いました。とくに下記の事項については慎重に検討する必要があります。

  • 使用する無線規格の選択(802.11a,b/g,n)
  • 観客が持ち込む大量のポータブル無線APによる周波数枯渇対策
  • 802.11aの周波数規格の選択(W52以外は気象レーダ(ISMバンド)干渉を考慮)
  • 複数無線AP設置による負荷分散
  • 無線電波出力を落とす方法もあらかじめ考えておくこと
  • レートリミット機能の活用
  • 会場の無線状態をこまめに監視すること
  • できる限り人の身長よりAPを高く設置すること

準備8割、実行2割

LL Planetsのネットワークは前述した通り、当日の僅かな時間で構築する必要がありました。その場でトラブルシュートや構成変更を行う余裕は皆無であり「誰が、どの機器を、どこに設置し、どのケーブルを用いて、どのポートに接続する」という単純作業のみ注力できるよう、事前計画・準備時間を入念に行いました。

スタッフの1人が「準備8割、実行2割」と、まるでお経のように唱えていましたが、本当にその通りだと思います。

今後の取り組み

LL Planetsでは、初の取り組みとして観客にインターネット接続を提供させていただいた訳ですが、実際にやってみないと判らない事ばかりでNOCチーム一同、貴重な経験をさせていただくことができました。

実は、今回の「観客へ無線LANを提供」という試みは、後にフィードバックを行うため、時系列で観客のトラフィック量や持ち込まれたポータブル無線AP数の観測を行う予定でしたが、データ収集端末のトラブルにより失敗してしまいました。次回はこれらのデータを取得・分析を行いフィードバックに活用していきたいと考えています。

最後に、LL Planetsはボランティアベースのイベントであり、スタッフ有志一同と、LL Planetsの意義に理解を示していただける企業様により支えられています。これらの協力無くしてLL Planetsは成立しませんでした。この場を借りてお礼申し上げます。

おすすめ記事

記事・ニュース一覧

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy