ワイヤレス : Cisco 5500 シリーズ ワイヤレス コントローラ

Cisco Unified Wireless Network ソリューション: VideoStream 導入ガイド

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2011 年 11 月 24 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

Cisco Unified Wireless Network(CUWN)に、エンタープライズ規模での展開用として VideoStream という新機能が導入されました。 この機能を使用すると、エンタープライズ全体でワイヤレス クライアントへのマルチキャスト ビデオ ストリーミングを展開するワイヤレス アーキテクチャが実現します。 この機能は、企業ネットワークに合わせてストリームおよびクライアントの規模を拡張することでビデオ配信の品質が低下するという欠点を相殺します。 VideoStream により、ワイヤレス クライアントへのビデオ マルチキャストの信頼性が高まり、帯域幅およびスペクトルをより効率的に使用できるようになります。 この機能では、マルチストリーミングの企業ネットワークでストリームに優先度を割り当て、優先ストリームにより多くの重み付け時間を提供します。 また、ワイヤレス クライアントへのビデオ配信を保証し、チャネル使用率が高い状態での新規クライアント サブスクリプションへのビデオを拒否します。

要件

Cisco Unified Wireless LAN ソリューションについての知識。

使用するコンポーネント

VideoStream 機能は Cisco Unified 無線ネットワーク ソフトウェア バージョン 7.2 の Cisco Unified 無線ネットワーク ソフトウェア バージョン 7.0with 機能拡張で利用できます。 この機能は、すべての Wireless LAN Controller(WLAN; ワイヤレス LAN コントローラ)および新しい世代の屋内 Access Point(AP; アクセス ポイント)でサポートされています。 この機能は、Autonomous アクセス ポイントおよび屋外アクセス ポイントでは利用できません。

関連製品

サポートされているワイヤレス ハードウェアとソフトウェア

VideoStream は、すべてのワイヤレス LAN コントローラでサポートされています。 これには、Cisco 5500 Controller、Cisco 4400 Controller、Cisco 2100 Controller および WiSM が含まれます。 また、VideoStream は Cisco 2504 スタンドアロンおよび Cisco WiSM-2 Controller でもサポートされています。 IGMPv2 はすべてのコントローラでサポートされているバージョンです。

VideoStream はすべてのアクセス ポイントでサポートされます。 これには Cisco Aironet 3600 シリーズ アクセス ポイント、Cisco Aironet 3500 シリーズ アクセス ポイント、Cisco Aironet 1260 シリーズ アクセス ポイント、Cisco Aironet 1250 シリーズ アクセス ポイント、Cisco Aironet Cisco Aironet 1140 シリーズ アクセス ポイントおよび Cisco Aironet 1040 シリーズ アクセス ポイントで構成されているアクセス ポイントのすべての 802.11n モデルが含まれています。 VideoStream はまた Cisco Aironet 1240AG* シリーズ アクセス アクセス・ポイントおよび Cisco Aironet 1130AG* シリーズ アクセス アクセス・ポイントでサポートされます。

VideoStream 機能はコントローラ コードの CUWN 7.0 バージョンで導入され、機能拡張のコントローラ ソフトウェアの以降のバージョンでサポートされました。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

動作理論

VideoStream 機能の詳細を説明する前に、Wi-Fi マルチキャストの欠点をいくつか理解しておく必要があります。 802.11n は、屋内のワイヤレス展開で特によく検討されるワイヤレス テクノロジーです。 同様に顕著な要件が、企業のワイヤレス ネットワークのマルチメディア サービス(特にビデオ)で見られます。 ビデオ サービスのユニキャストは企業全体のストリーミングの規模に合わせて拡張されないため、大規模な企業ネットワークでは、マルチキャスト ビデオ ストリーミングがコスト効率の高いソリューションとなります。 マルチキャストでは、マルチキャスト フレームおよびブロードキャスト フレームでの MAC レイヤ リカバリは行われません。 マルチキャストおよびブロードキャスト パケットには Acknowledgement(ACK; 確認応答)が存在せず、すべてのパケット配信はベスト エフォートです。 802.11a/b/g/n を使用したワイヤレス上のマルチキャストでは、信頼性の高い伝送メカニズムは提供されません。

企業のワイヤレス展開では、干渉、高いチャネル使用率、互換性のないクライアント、セルのエッジでの低 SNR などが発生しやすい傾向があります。 ワイヤレス クライアントへのビデオ配信は、各チャネルで最大の必須データ レートを使用します。 また、同一のチャネルを共有しながら、チャネル条件、電力制限、およびクライアント処理機能が異なるクライアントも多くあります。 したがって、下の図に示されているように、各クライアントのチャネル条件が異なるため、マルチキャストは同一チャネル内のすべてのクライアントに対する信頼性の高い伝送プロトコルではありません。

ワイヤレス マルチキャストでは、ビデオ サーバによってマーキングされた Differentiated Service Code Point(DSCP)であっても、ビデオ トラフィックは優先されません。 アプリケーションは ACK がないことでパケットの損失を認識し、配信を再試行してもうまくいきません。 信頼性の高いマルチキャスト パケットの伝送を実現するには、ネットワークで Quality of Service(QoS)によってキューおよびプロビジョンを分類することが必要です。 これにより、ドロップ パケットを除去することで実質的に信頼性の低さの問題を排除し、パケットをマーキングして適切なキューにソートすることにより、ホストへのパケットの遅延をなくします。

802.11n の適応がネットワークおよびクライアントの両方で盛んに行われても、ワイヤレス マルチキャストでは 802.11n データ レートを使用できませんでした。 これも、ワイヤレス マルチキャストの伝播に代わるメカニズムの要因の 1 つです。

レガシー マルチキャスト

マルチキャストの実装は、CUWN のリリースに伴って進化しました。 CUWN 7.0 よりも前のコードで、マルチキャスト パフォーマンスが最適化されており、コントローラからアクセス ポイントにマルチキャスト トラフィックを配信する効率的な方法が導入されました。

このプロセスでは、アクセス ポイントを登録してマルチキャスト パケットを配信するように、コントローラ上でマルチキャスト グループが設定されます。 この実装では、ユニキャストを使用して Lightweight Access Point Protocol(LWAPP)トンネルを介してマルチキャスト パケットを各アクセス ポイントに配信することで、コントローラのプロセスをドロップしました。 この設定では、マルチキャスト パケットを複製してアクセス ポイントに配信するために、基盤となるネットワーク コンポーネントがコントローラによって使用されます。 コントローラは設定されている LWAPP/CAPWAP グループのマルチキャストの送信元となり、アクセス ポイントはマルチキャストのレシーバとなります。 アクセス ポイントは、アップストリーム ルータからの Internet Group Management Protocol(IGMP; インターネット グループ管理プロトコル)クエリと、送信元 IP アドレスが関連するコントローラであるマルチキャスト パケットを受け入れます。 これにより、マルチキャスト パフォーマンスが大幅に向上します。 IGMP クエリは、メンバーおよびクライアントに送信され、これによりデータベースがアップデートされ続けます。

また、IGMP スヌーピング設定によっても、パケットのマルチキャスト配信が向上しました。 アップストリーム マルチキャスト ルータおよびネイバーからのクエリに対しては、コントローラのグループ設定に基づいて、IGMP レポートで応答します。 L3 マルチキャスト アドレスおよび VLAN 番号のチェック後、IGMP レポートからのコントローラにより、一意の Multicast Group ID(MGID; マルチキャスト グループ ID)が作成され、これにより IGMP レポートがアップストリームの L3 スイッチまたはネイバーにアップデートされます。 クライアントからのレポートの受信にインターフェイス アドレスが使用されるため、コントローラはレポートと一緒に送信元アドレスを送信します。 クライアントの MAC アドレスを使用して、アクセス ポイント上で MGID の表が作成またはアップデートされます。

コントローラが特定のグループに対するマルチキャスト参加応答を受け取ると、コントローラはそのグループのアクセス ポイントすべてに応答を転送します。 ただし、マルチキャスト トラフィックを送信するのは、そのマルチキャスト グループをサブスクライブしているアクティブなクライアントが存在するアクセスポイントのみになります。 キャプチャで示されているように、マルチキャスト トラフィックは最大必須データ レートでクライアントに流れます。 クライアントは、5 GHz 無線上で、802.11n レートでアクセス ポイントに関連付けられています。

cuwns-vidstrm-guide-01.gif

VideoStream

VideoStream は、マルチキャスト グループに参加しているクライアントがあるかどうかにかかわらず、AP のすべての WLAN に対してマルチキャスト パケットをブロードキャストする必要性をなくすことにより、帯域幅の使用を効率化しています。 この問題を回避するためには、AP はクライアントが参加している WLAN 上のみで、クライアントが参加しているデータ レートでユニキャスト転送を使用してホストにマルチキャスト トラフィックを送信できる必要があります。 VideoStream を設定する前に、VideoStream が通常のマルチキャスト導入(マルチキャスト/ブロードキャスト)とどのように異なるかの概要を理解する必要があります。

VideoStream は、ワイヤレス システムでは初めて、コントローラとアップストリーム スイッチまたはルータ間の帯域幅を損なうことなくマルチキャスト ソリューションを設計して実装する、シームレスな方法をエンジニアに提供しています。

Cisco VideoStream テクノロジーは、システム全体での新しい Cisco Unified Wireless Network の機能セットで、優れた品質でビデオを配信するための主要な拡張機能が組み込まれています。 Cisco VideoStream は、さまざまなタイプのビデオすべてに対して信頼性の高い、一定したプラットフォームを提供する、シスコの RF およびビデオの専門知識を体現しています。 このテクノロジーでは、ワイヤレス LAN の物理レイヤ、MAC レイヤ、アプリケーション レイヤが考慮されています。 以降のセクションでは、VideoStream 機能の一部を紹介し、その機能が Wi-Fi を使用したビデオの配信、およびユーザ エクスペリエンスの品質をどのように独自に向上しているかについて説明します。 次に、VideoStream の簡単なネットワーク図を示して、導入されているコンセプトを説明します。

cuwns-vidstrm-guide-02.gif

VideoStream のプロセス フローの概要は、以降のセクションで説明している機能の理解に役立ちます。 また、プロセス フローは、ストリーム アドミッション、ストリーム プライオリティ設定、無線予約制御、マルチキャスト ツー ユニキャスト、および自動 QoS などのモジュールも紹介しています。

cuwns-vidstrm-guide-03.gif

VideoStream は、コントローラ上でグローバルにイネーブルにできます。 この機能は無線レベル(2.4 GHz と 5 GHz)、および WLAN または SSID レベルでイネーブルにできます。管理者はこの機能を使用することで、優先 QoS 処理を実行する特定のビデオ ストリームの識別を、より細かく制御できるようになります。

ストリーム アドミッションおよびプライオリティ設定

前述のとおり、ビデオは効率が良く、影響力の強い通信手段ですが、帯域幅には高い負荷がかかります。またここで見られるように、すべてのビデオ コンテンツが同様に優先されるものではありません。 前述の説明からも明らかですが、ビデオに投資する組織は、ビジネスクリティカルなメディアをプライオリティ設定せずにネットワーク帯域幅を消費する余裕はありません。

ストリーム アドミッションは、ネットワーク管理者がネットワーク内のすべてのマルチキャスト ビデオ ストリーミングを管理できるようにするものです。 ストリーム アドミッションを使用することで、ネットワーク管理者は簡単に入力マルチキャスト ストリーム用の事前定義されたテンプレートを使用できるようになります、 300 Kbps、500 Kbps、1 Mbps、3 Mbps、および 5 Mbps のストリーム帯域幅用に、いくつかの事前定義されたテンプレートが用意されています。 ビデオの経験の浅いネットワーク管理者は、事前定義されたテンプレートを使用することもできます。

cuwns-vidstrm-guide-04.gif

cuwns-vidstrm-guide-05.gif

それは必要設定する前に特性ストリーミング ビデオの基本的な知識があるためにです。 たとえば、上記の 2 つの設定について考えます。 ビデオのビット レートが 4 Mbps 程度の場合、上記の 2 つのテンプレートはいずれも使用せずに、手動で設定を追加する必要があります。 Stream-Less3Mbps を使用した場合、ビデオ フレームの不足により、ビデオの品質が低下します。 ワイヤレス クライアントでビデオのピクセレーションや、一定のフリーズが見られます。 Stream-Less5Mbps が使用される場合、ビデオ クライアントの数はビデオ ビットレートが 4 つのただ M ビットの間、各無線クライアントが 5Mbps の保証されるようにより少しです。 ワイヤレス I クライアントが 10 個の場合、集約クライアント帯域幅は 40 Mbps 程度でなければいけません。 Stream-Less5Mbps を使用すると、コントローラは 50 Mbps を使用するため、ビデオのワイヤレス クライアントを 3 つ奪うことになります。

ストリーム プライオリティでは、企業ネットワーク内での重要性に基づいて、メディア ストリームに異なるプライオリティを設定できます。 RRC プライオリティは、ワイヤレス アクセス ポイントに輻輳またはコンテンションが発生している場合のみ、動作します。

cuwns-vidstrm-guide-06.gif

輻輳が発生しており、ビデオ マルチキャスト ストリームおよびクライアントが多すぎる場合、ストリーム 4 がその他の設定されているストリームよりも優先されます。 ビデオ ストリームのプライオリティは、音声よりも低く、ベスト エフォート トラフィックよりも高く設定されています。 その他のすべてのマルチキャスト トラフィックは、ビデオ用 QoS プライオリティがマークされている場合でも、ベスト エフォート トラフィックとして受け入れられます。

リソース予約コントロール

Wi-Fi エンドポイント上のワークプレースでビデオを利用するユーザは増えていくため、時間や場所に関係なく変動するユーザ グループに高品質のエクスペリエンスを継続的に提供できるよう、適切に管理し、拡張できることが重要です。 コントローラおよびアクセス ポイントには、Resource Reservation Control(RRC; リソース予約コントロール)という非常に重要な意思決定アルゴリズムが含まれており、この拡張機能によりアドミッション コントロールおよびポリシー コントロールを管理できます。 アドミッションおよびポリシーの決定は、無線リソースの測定、トラフィックの統計情報測定、およびシステム設定に基づいて行われます。 コントローラは、IGMP 参加用のアクセス ポイントに対して RRC 要求を開始します。 アクセス ポイントでは、次の図にリストされているすべてのパラメータに対する要求が処理されます。

cuwns-vidstrm-guide-07.gif

上記の応答では、すべてのパラメータはポリシー設定をコントローラに渡しました。 そのアクセス ポイント上のクライアントからの IGMP 参加要求は許可されます。 RRC 要求に対して次に示す応答が返された場合は、参加要求が調査され、再度 RRC アルゴリズムのポリシー設定がチェックされます。 クライアントは、ベスト エフォート クライアントとして許可されます。 ただし、RRC チェックが複数回試行されると、そのクライアントはよりプライオリティの高い QoS として許可されます。

cuwns-vidstrm-guide-08.gif

RRC は、ストリームへの IGMP 参加時にクライアントで開始され、定期的にチェックされるように設定できます。 ワイヤレス特性の変化により、RRC のメトリック応答が大幅に変更された場合は、クライアントはストリームから拒否されます。

cuwns-vidstrm-guide-09.gif

RRC は、サブスクリプション過多を引き起こす要求を拒否するというビデオ クライアント用の帯域幅保護機能があります。 チャネル使用率は、容量を識別し、アドミッション コントロールを実行するメトリックとして使用されます。 図は RRC がどのように動作するかを示しています。 音声 CAC との統合により、ビデオ品質および音声のプライオリティが保証されます。

マルチキャスト ツー ユニキャスト

802.11n データ レートを有効にし、パケット エラーを修正することで、Cisco VideoStream のマルチキャスト ツー ユニキャスト機能により、Wi-Fi 上でストリーミング ビデオを配信する信頼性は、従来のワイヤレス ネットワークのベスト エフォート機能よりも向上します。

ワイヤレス クライアント アプリケーションは、IGMP 参加メッセージを送信することで IP マルチキャスト ストリームをサブスクライブします。 信頼できるマルチキャストによって、インフラストラクチャはこの要求をスヌーピングし、IGMP メッセージからデータを収集します。 システムにより、ストリームのサブスクリプションと設定がチェックされ、要求したストリームのメトリックとトラフィック ポリシーが収集されます。 要求したストリームがポリシーで許可されている場合、ストリームが到着すると、アクセス ポイントに接続しているワイヤレス クライアントに応答が送信され、信頼できるマルチキャストが開始されます。 また、新しいサブスクリプションをサポートできる十分な通信時間があるかどうかを決定するために、空き帯域幅と設定済みのストリーム メトリックがシステムにより確認されます。 さらに、アドミッションを決定する前に、無線にかかる一般的な負荷とメディアの健全性についてもシステムで考慮されます。 上記の基準がすべて満たされると、参加応答がアクセス ポイントに送信されます。 このとき、アクセス ポイントがマルチキャスト フレームを複製し、それを 802.11 ユニキャスト フレームに変換します。 最後に、信頼性の高いマルチキャスト サービスによって、ビデオ ストリームはユニキャストとしてクライアントに直接配信されます。

クライアントに対する高度なビデオの拡張性

Wi-Fi プレースを使用したビデオにアクセスするクライアント数の増加は、ネットワークに対するプレッシャと要求の増加につながります。 これは、パフォーマンスと品質の両方に影響があります。 高度なビデオの拡張性は、有線ネットワークからワイヤレス ネットワークへのトラフィック フローを最適化しながら、各コントローラがサポートできるクライアント数で測定されます。 Cisco VideoStream テクノロジーを使用すると、すべての複製は(アクセス ポイントの)エッジで実行されるため、ネットワーク全体を効率的に使用できます。

どの時点でも、ネットワークを通過する設定済みメディア ストリームしかありません。これは、ビデオ ストリームはクライアントが開始した IGMP 要求に基づいてアクセス ポイントでユニキャストに変換されるためです。 他のベンダーの実装でもマルチキャストからユニキャストに変換する同様の処理を行っていますが、ストリームをサポートする有線ネットワークにかかる負荷が高いため、非効率的です。

理論的には、2.4 GHz クライアントおよび 5 GHz クライアントの両方が関連付けられた非 802.11n ネットワークでは、3 または 4 個までのクライアントで、5 M ビットのビデオ ストリームを見ることができます。 ビデオ クライアントがこれよりも増えると、チャネル使用率が最大化し、クライアントが接続性をドロップまたは喪失する可能性が高くなります。

802.11n ネットワークでは、空き帯域幅の大きさにより、クライアントの拡張性が大幅に高くなります。 また、802.11n ネットワークでは、チャネル ボンディングの有無に応じて、クライアント拡張性が変化します。 これは、レガシーまたは非 802.11n ネットワークには存在しません。

コンセプト

ここまでは、VideoStream が設定されている場合のインフラストラクチャ機能について説明しました。 システムの動作において、より良い相乗効果を実現するために、ビデオ アプリケーション、クライアント デバイスなどがどのように役立っているかを理解することも重要です。 すべてのワイヤレス インストール アプリケーションおよびクライアントは、エンドツーエンド配信で同じ役割を果たすことが確認されています。

アプリケーション

現在、IP ネットワークを使用してビデオをストリーミングするために、さまざまなビデオ アプリケーションが使用できます。 ビデオ ストリーミング ソースは、有線および無線ネットワーク全体でよく利用されています。 コントローラは、マルチキャスト ネットワークの最後のレポータとして、パス上の有線ネットワークのコアまたは配信に存在します。 VideoStream でテストされたビデオ アプリケーションの一部を、次のセクションで紹介します。

  • シスコ メディア エクスペリエンス エンジン

  • Cisco コンテント デリバリ アプリケーション

  • Windows Media Server/Services

  • VBrick:H.264 アプライアンス

  • Video Furnace

  • VLC プレーヤー

シスコ メディア エクスペリエンス エンジン

Cisco Media Experience Engine(MXE)3500 は、簡単に導入できるアプライアンスで、ネットワークに透過的に統合でき、メディア処理の豊富な機能セットを提供しています。 Cisco Media-Ready Network のコア コンポーネントとして設計された Cisco MXE 3500 は、次の機能を提供します。

  • 実質的にあらゆるタイプのエンドポイントに対し、ネットワーク全体でビデオ コンテンツを共有できる包括的なライブおよび Video on Demand(VoD; ビデオ オン デマンド)トランスコーディング サービス

  • 一般的なビデオ コンテンツを驚異的なスタジオ品質の出力に変換する画期的なポストプロダクション機能

  • 最先端の音声テキスト変換サービス

  • シスコのメディア製品スイートで提供されるその他のアプリケーションとの画期的なコラボレーション

この結果、IT 管理者がライブ メディア ストリーミング、メディア作成、および配信に関連する運用コストを大幅に合理化できる、高性能なメディア処理プラットフォームが実現しています。

シスコ コンテント デリバリ アプリケーション

シスコ コンテント デリバリ アプリケーションは、CDS のソフトウェア要素であり、取り込み、保管、キャッシュ、パーソナライズ、およびストリーミングなどの機能を提供するシスコ コンテント デリバリ エンジンの上に、コンテンツ プロセスを実装しています。 TV ストリーミング配信アプリケーションには、次のようなものがあります。

  • Cisco Vault アプリケーション

  • Cisco TV Streamer アプリケーション

  • Cisco TV Playout アプリケーション

  • Cisco Integrated Streamer-Vault アプリケーション

  • シスコ コンテント デリバリ システム マネージャ

インターネット ストリーミング コンテンツ配信アプリケーションには、次のようなものがあります。

  • Cisco Internet Streamer アプリケーション

  • Cisco Content Acquirer アプリケーション

  • Cisco Service Router アプリケーション

  • シスコ コンテント デリバリ システム マネージャ

シスコ コンテント デリバリ システムは、1 つ以上のネットワークに接続したシスコ コンテント デリバリ エンジンで構成されています。各シスコ コンテント デリバリ エンジンは、コンテンツ取り込み、保管、キャッシュ、またはストリーミングなどのタスクのうち、1 つ以上のタスク用に最適化されています。

Windows Media Server

Windows Media Server は、インターネットまたはイントラネットを介して、クライアントにデジタル音声およびビデオ コンテンツをストリーミングします。 これらのクライアントは、Windows Media Player などのプレーヤーを使用してコンテンツを再生する、その他のコンピュータまたはデバイスの場合があります。 または、コンテンツをプロキシ、キャッシュ、または再配布する、Windows Media Service を実行するその他のコンピュータ(Windows Media Server と呼ばれます)の場合もあります。

Windows Media Server によりクライアントにストリーミングされるコンテンツは、ライブ ストリームまたは事前に録画されたデジタル メディア ファイルです。 拡張性および信頼性の高い Windows Media Server を使用してワイヤレス ブロードバンド エンターテイメント サービスを配信するワイヤレス企業は、メディア サーバを使用します。

  • ラジオ、テレビ、ケーブルまたは衛星テレビ向けにコンテンツを配信するインターネット放送局

  • 過度のバッファリングまたはネットワーク輻輳を発生させずに安全な方法で音声およびビデオ コンテンツを配布するフィルムおよび音楽販売業者

  • Local Area Network(LAN; ローカル エリア ネットワーク)上で高品質な IPTV エクスペリエンスを配信する IPTV 専門業者

VideoFurnace

Haivision の Furnace は、エンコーディングを実行してコンピュータおよびセット トップ ボックスにライブ ビデオを配信する、安全で使いやすく、簡単に導入できるエンドツーエンド システムです。これは、企業の TV および看板を再生するスケジュールされた再生チャネルを作成したり、コンテンツを録画したり、ビデオ オン デマンドを配信したりすることに使用されます。

Furnace は、IP ビデオ ソリューション一式を提供します。 ライブ チャネル、録画チャネル、およびオンデマンド コンテンツにアクセスすると、「ゼロ フットプリント」InStream プレーヤーおよび固定モニタによりデスクトップに提供され、Stingray™ のセット トップ ボックスを使用して表示されます。 すべてのビューアおよびディスプレイの粒度を微調整できる Furnace は、企業ビデオの安全な管理および配信、施設全体での HD 看板の作成、オンデマンド マテリアルの提供、およびイベントのキャプチャ、整理、レビューを行うのに理想的なシステムです。

Furnace は、エンドツーエンド H.264 によりシームレスなエンドツーエンド機能を提供します。 Furnace Portal Server は、SD および HD H.264 ビデオと、MPEG-1、MPEG-2、MPEG-4 SD ビデオの InStream プレーヤーと Stingray セット トップ ボックスの両方に直接かつ安全に配信します。 Furnace Playback Manager は、ライブおよび事前に録画された IP ビデオ ブロードキャストおよびデジタル看板用の、スケジュールされたチャネルをサポートしています。 Furnace Media Server を使用することで、ビデオ オン デマンドが可能になります。 H.264 ビデオ圧縮の効率性を利用することで、すべてのユーザが高解像度のメディアを利用できるようになります。 さらに、Furnace では Haivisions の画期的な Barracuda™ および Makito™ H.264 エンコーダが直接サポートされているため、150 kbps ~ 15 Mbps のビット レートで SD および HD ライブ コンテンツが配信されます。

セル計画

セル計画は、ビデオおよび音声を導入する際に考慮する必要のある重要な側面です。 セル計画は、アクセス ポイントを適切なロケーションにマウントし、ワイヤレス接続を提供することよりも複雑です。 これは、広汎性ワイヤレス カバレッジが要件となったため、ここ数年で変更されつつあります。 現在では、適切なセル計画を実行するために、複数のツールを使用できます。 Cisco Wireless Control System には効果的なプランナ ツールがあります。

ビデオのセル計画では、通常のワイヤレス計画基準に加えて、考慮する必要のある追加のパラメータがあります。 そのパラメータは、遅延、ジッタ、およびパケット損失です。 次の表で同一の項目をハイライトし、現実的な値で同一の内容を分類することで、セル計画が非常に有効であることが分かります。

  遅延 ジッタ スループット パケット損失
テレビ会議 中間
HD テレビ会議
ビデオ オン デマンド 中間
ライブ ストリーミング ビデオ 中間 中間 中間

値に関してビデオ アプリケーションを定量化するために、次の表はビデオ アプリケーションでは広く認識されています。

メトリック ビデオ コラボレーション デジタル看板 Telepresence ビデオ サーベイランス
遅延(秒) 150 200 150 300
ジッタ 30 10 10 10
パケット損失(%) 1% .05% .05% .05%

Cisco CAPWAP アクセス ポイントが最新バージョンのコードと一緒にクリーンなテスト環境でインストールされており、オフィス環境に干渉するものが何もないと想定します。 クライアント関連付けレート、信号強度、およびノイズをさまざまなポイントで測定すると、次のようなデータが得られます。 次に示す測定値は、チャネル ボンディングあり、チャネル ボンディングなしでキャプチャされています。 すべてのテスト シナリオで、信号強度およびノイズを確認してください。 これにより、信号およびノイズのばらつきの基本が理解できます。 計画のガイドラインでは、ここで取り上げた 2 つの値だけに基づくものではなく、共用チャネル干渉、クライアント データ レート、クライアント伝送出力レベル、総チャネル キャパシティも考慮されます。 これらは、アクセス ポイントの密度およびクライアント数が増加した場合の計画の検討事項となります。

5 GHz(チャネル ボンディングあり)

アクセス ポイントからの距離(ft) クライアント関連付けレート(Mbps) 信号強度(-dbm) ノイズ(-dbm)
5 276 42 72
20 250 44 75
40 243 47 77
80 216 59 89
100 198 64 90

5 GHz(チャネル ボンディングなし)

アクセス ポイントからの距離 クライアント関連付けレート 信号強度 ノイズ
5 144 41 71
20 144 51 79
40 130 55 81
80 108 60 90
100 87 77 93

2.4 GHz 無線(チャネル ボンディングなし)

アクセス ポイントからの距離 クライアント関連付けレート 信号強度 ノイズ
5 144 30 61
20 144 32 62
40 121 49 77
80 108 53 80
100 84 56 88

Call Admission Control(CAC; コール アドミッション制御)設定は、チャネルのサブスクリプション過多を停止して、設定されているメディア帯域幅を保証します。 また、CAC 設定は新規メディア ユーザも停止します。これにより、サブスクリプション過多が発生したときに、現在のユーザが影響を受けないように保護します。

VideoStream 用の CAC 設定は、Cisco Unified Wireless Network 7.0 を使用するワイヤレス メディア上の音声、ビデオ、およびデータのユーザのバランスを取る重要な調整ポイントです。 この設定は無線固有のもので、2.4 GHz および 5 GHz の両方の無線でイネーブルにできます。 CAC 設定は、[WIRELESS] > [802.11a/n] または [802.11b/g/n] > [Media] をクリックするとイネーブルにできます。

cuwns-vidstrm-guide-10.gif

デフォルトでは、音声およびビデオの CAC 設定は両方ともディセーブルになっています。 ここで行った設定は、すべて音声およびビデオの設定に直接適用されます。 端的に言うと、メディアとは音声 + ビデオです。 デフォルトでは、これは総無線帯域幅の最大 85 % に設定されています。 無線帯域幅の残りの 15 % は、ベスト エフォート トラフィック(データ)に使用されます。データ、音声、およびビデオの使用方法に応じて、この値を変更することをお勧めします。 メディアの設定は、[Media] タブをクリックすることで変更できます。 これらの値は、やむを得ず変更しなければならない場合を除いてデフォルト値を保持することをお勧めします。

音声およびビデオの設定は、提供されているネットワーク サービスのタイプに基づいて調整できます。 ネットワーク内で最も重要なアプリケーションが音声である場合、CAC の値は 5 ~ 85 % の範囲になります。 上記の音声設定には、予約済みのローミング帯域幅も含まれています。 5 GHz 無線で CAC を最大の 85 % に設定した場合、ワイヤレス システムは約 21 個の音声コールに対応できます。 同様に、2.4 GHz 無線で CAC を最大の 85 % に設定した場合、システムは約 13 個の音声コールに対応できます。

また、ビデオ CAC に切り替えて最大の 85 % に設定すると、ワイヤレス システムでは 5 GHz 無線上で約 22 個のクライアントに対応できます。 2.4 GHz 無線で CAC を最大の 85 % に設定した場合、ワイヤレス システムは 10 個のクライアントに対応できます。 次の表に、異なる設定でシステムがどのように動作するかを示します。 これらの値は、5 GHz 無線上で、ビデオ ビット レートを 3 M ビットに設定した場合の、チャネル ボンディングありの状態の値です。

ビデオ CAC 値 ビデオ クライアント 音声コール 音声 CAC 値
85 22 0 0
65 15 6 20
45 10 11 40
25 5 16 60
5 2 20 80

注: これらのテスト結果はクライアントへのビデオパケットの集約、バッファリングおよびスマートなスケジューリングの機能強化の後で CUWN 7.2 のために文書化されています。

ビデオ CAC 値 音声 CAC 値 ビデオ ビットレート クライアント
85 0 1.5 ~2 の M 51
85 0 5M 30
85 0 10M 20

注: テストのクライアント全員は 3X3 802.11a/b/g/n ワイヤレスアダプタとの設定で類似したです。 テスト環境はすべてのワイヤレス干渉およびまた非WiFi 妨害物からクリアです。

無線では、255 個の関連付けに対応できます。 ワイヤレス メディアは共有半二重メディアであるため、クライアントによるコンテンションが発生します。 クライアントが無線から遠ざかるのに従って、スループットが減少します。 セルのエッジの下になると、クライアントのデータ レートは最小まで低下するため、再試行回数が非常に多くなります。 無線では多くの関連付けが可能ですが、通常のデータ アプリケーションの場合は、アクセス ポイントあたりのクライアント数を 60 未満とすることをお勧めします。 ただし、アクセス ポイント上で音声およびビデオ サービスを利用する場合は、クライアント アダプタの信号強度が -60 db 未満または同等のクライアント関連付けレート未満にならないようにアクセス ポイント レイアウトを計画することをお勧めします。 またクライアントがローミングしているとき、です 1 つのアクセス ポイントからの別のものへのビデオアプリケ− ションのスムーズなハンドオフ 15~20% セル重複をそこに確認するために提供することを考えて下さい。

Quality of Service

通常、すべてのビデオ ホストの送信元は、DSCP マーキングが有線側で適切にマークされていることを確認します。 ビデオ サーバがローカルに存在し、ルータ境界を通過することがない場合は、DSCP がマークされたパケットは同一であることが保証されます。 ビデオ パケットがルーティングされた境界を通過するときに、DSCP マーキングはリセットされることが多いです。 CUWN は、ワイヤレス側でビデオ パケットが適切に DSCP マーキングされていることを確認します。 これは、アクセス ポイントでビデオ キュー カウンタが増えることで確認できます。 ビデオ トラフィックが存在せず、ベスト エフォート トラフィックのみの場合は、個別のカウンタが増えます。 ここで説明した操作はすべて、コントローラ上のビデオ プロファイルが 802.1p プロトコルにマップされ、タグ値が 5 に設定された場合のみ有効です。

cuwns-vidstrm-guide-11.gif

設定

VideoStream は、既存の企業全体の有線ネットワークおよびワイヤレス ネットワークに導入できます。 ワイヤレス ネットワークを使用したビデオの実装およびメンテナンス コストの総額は、大幅に削減されます。 前提として、有線ネットワークではマルチキャストが有効になっているものとします。 ディストリビューション スイッチまたはアクセス スイッチがレイヤ 3 ネットワークの一部であることを確認するには、クライアント マシンをスイッチポートに接続して、クライアント マシンがマルチキャスト フィードに参加できるかどうかを確認します。

show run | include multicast は、レイヤ 3 スイッチでマルチキャストがイネーブルになっているかどうかを表示します。 マルチキャストがイネーブルになっていない場合は、スイッチに次のコマンドを追加することで、マルチキャストをイネーブルにできます。

cuwns-vidstrm-guide-conf0.gif

cuwns-vidstrm-guide-conf1.gif

有線ネットワークの Protocol Independent Routing(PIM)設定のタイプに応じて、レイヤ 3 スイッチを PIM スパース モードまたは PIM デンス モードに設定できます。 また、PIM スパース/デンス モードという、広く使用されているハイブリッド モードもあります。

cuwns-vidstrm-guide-conf2.gif

Show ip igmp interfaces は、IGMP メンバーシップに参加している SVI インターフェイスを表示します。 このコマンドは、スイッチまたはルータに設定されている IGMP のバージョンも表示します。 インターフェイス上の IGMP アクティビティは、クライアントからの join および leave の形式でも確認できます。

cuwns-vidstrm-guide-conf3.gif

上記の設定は、レイヤ 3 スイッチ上で show ip mroute コマンドを実行することで確認できます。

cuwns-vidstrm-guide-conf4.gif

上記のキャプチャには、調査する必要のある特定のエントリが含まれています。 特殊表記である(送信元、グループ)は、「S,G」と表されます。ここで送信元の「S」はマルチキャスト サーバの送信元 IP アドレスであり、「G」はクライアントが参加を要求したマルチキャスト グループ アドレスです。 ネットワーク上に複数の送信元が存在する場合は、ルータで各送信元 IP アドレスおよびマルチキャスト グループ アドレスに対して(S,G)が表示されます。 このキャプチャには、発信インターフェイスおよび着信インターフェイスの情報も含まれています。

サポートされているワイヤレス ハードウェアとソフトウェア

VideoStream は、すべてのワイヤレス LAN コントローラでサポートされています。 これには、Cisco 5500 Controller、Cisco 4400 Controller、Cisco 2100 Controller および WiSM が含まれます。 また、VideoStream は Cisco 2504 スタンドアロンおよび Cisco WiSM-2 Controller でもサポートされています。 IGMPv2 はすべてのコントローラでサポートされているバージョンです。

VideoStream は、すべての新しいアクセス ポイントでサポートされています。 これには、Cisco Aironet 3500 シリーズ アクセス ポイント、Cisco Aironet 1260 シリーズ アクセス ポイント、Cisco Aironet 1250 シリーズ アクセス ポイント、Cisco Aironet 1240AG シリーズ アクセス ポイント、Cisco Aironet 1140 シリーズ アクセス ポイント、Cisco Aironet 1130AG シリーズ アクセス ポイントおよび Cisco Aironet 1040 シリーズ アクセス ポイントの各モデルが含まれます。

VideoStream 機能はコントローラ コードの CUWN 7.0 バージョンで導入され、以降のバージョンのコントローラ ソフトウェアでサポートされています。

コントローラの設定

VideoStream 機能を使用するには、コントローラでマルチキャストをイネーブルにする必要があります。 コントローラのマルチキャストは、マルチキャスト ユニキャスト モードとマルチキャスト マルチキャスト モードという 2 つの モードでイネーブルにできます。 IP マルチキャストがイネーブルの場合、コントローラはマルチキャスト パケットのコピーを作成してから、ユニキャストの Lightweight アクセス ポイント プロトコル トンネルを介してコントローラに接続している各アクセス ポイントにパケットを転送することで、マルチキャスト パケットをワイヤレス LAN クライアントに配信しました。 ユニキャスト配信では、アクセス ポイントに対して複製する必要のあるパケットが集中するため、AP およびコントローラのネットワーク処理装置に大きな負荷がかかります。

シスコのマルチキャスト ユニキャスト配信方式は、一般的にワイヤレス ネットワーク上でマルチキャストを提供するだけのお客様と、またはネットワークでマルチキャストがサポートされていないお客様に使用されています。 お客様には、マルチキャスト ユニキャスト配信方式は避けることをお勧めしています。 この方式は、サポート対象のマルチキャスト ストリームの数によってプロセッサに負荷がかかります。 このモードでは、マルチキャスト グループ アドレスを要求しているクライアントが存在するかどうかに関係なく、コントローラに参加したすべてのアクセス ポイントに対してすべてのマルチキャスト パケットを複製する必要があります。

マルチキャストのパフォーマンスは、マルチキャスト マルチキャスト モードの導入により最適化されました。 ユニキャストを使用し、CAPWAP トンネルを介して各アクセス ポイントにそれぞれのマルチキャスト パケットを配信する代わりに、CAPWAP マルチキャスト グループを設定してマルチキャスト パケットを配信します。 これにより、ネットワーク内のルータは標準のマルチキャスト手法を使用してマルチキャスト パケットを複製し、アクセス ポイントに配信できるようになります。 CAPWAP マルチキャスト グループの場合は、コントローラがマルチキャスト送信元になり、アクセス ポイントがマルチキャスト受信側になります。 アクセス ポイントでは、ルータからの IGMP クエリだけと、現在アクセス ポイントと関連付けられているコントローラを送信元 IP アドレスとするマルチキャスト パケットだけを受け入れるようになるため、マルチキャストのパフォーマンスは向上します。

cuwns-vidstrm-guide-12.gif

注: IP マルチキャストは、クラス D の IP アドレス範囲(224.0.0.0 ~ 239.255.255.255)を使用します。 予約済みのアドレス範囲であるリンク ローカル マルチキャスト アドレス(224.0.0.0 ~ 224.0.0.255)は、プロトコルにより使用されるため、ここでは使用できません。 残りのクラス D アドレスである管理スコープ マルチキャスト アドレス(239.0.0.0 ~ 239.255.255.255)は、マルチキャスト用 IP ネットワークの設定に使用できます。

上記の設定は、コマンド ラインを使用して 2 ステップで設定できます。

cuwns-vidstrm-guide-conf5.gif

注: マルチキャスト アドレスとコントローラの組み合わせは、一意のものを使用することをお勧めします。

コントローラ上でのもう 1 つの重要な設定は、IGMP スヌーピングのイネーブル化です。 コントローラで IGMP スヌーピングをイネーブルにすると、ホストからの IGMP レポートの収集と、任意のマルチキャスト グループをリッスンしているホスト リストの各 AP への送信に役立ちます。 次に、AP はこれらのホストのみに対してマルチキャスト パケットを転送します。

IGMP タイムアウトおよび IGMP クエリ間隔を使用すると、IGMP スヌーピングはより効果的になります。 IGMP タイムアウトの有効期限が切れると、コントローラはすべての SSID に対してクエリを送信します。これにより、マルチキャスト グループをリッスンしているクライアントは、パケットをコントローラに送り返します。 IGMP クエリ間隔は、コントローラからすべての SSID に対してクエリを送信する頻度です。 IGMP タイムアウトが 60 秒に設定されていて、IGMP クエリ間隔が 20 に設定されている場合は、クエリは 3 回発生します。

cuwns-vidstrm-guide-13.gif

cuwns-vidstrm-guide-conf6.gif

VideoStream のイネーブル化:グローバル

VideoStream 機能は、機能の実装に応じて、3 つの異なる場所でイネーブルにできます。 これにより、ネットワーク管理者はコントローラでの VideoStream 機能のイネーブル化を制御できるようになります。

この機能は、[Wireless] > [Media Stream] > [General] の下のタブをクリックすることで、コントローラでグローバルにイネーブルにする必要があります。 ここでこの機能をイネーブルにすると、コントローラの VideoStream 用設定パラメータが一部入力されます。

VideoStream 機能は、PHY タイプの下でもイネーブルにできます。 顧客は 5Ghz 無線または 2.4Ghz 無線または両方のだけ VideoStream を有効に する 柔軟性があります。

マルチキャスト直接ボタンはの下の WLAN > QoS 機能がグローバルに 有効に なる場合現われます。 このボタンを使用すると、VideoStream 機能を SSID ごとに柔軟にイネーブルにできるようになります。

cuwns-vidstrm-guide-14.gif

cuwns-vidstrm-guide-conf7.gif

マルチキャスト ストリーム追加の設定

マルチキャスト フィードがコントローラで設定されている場合のみ、マルチキャスト フィードが RRC に参加するようにイネーブルにできます。 マルチキャスト ストリームをコントローラに追加するには、[MediaStream] の下で [Streams] をクリックします。

前述のように、管理者はコントローラを通じてビデオ特性ストリーミングを認識する必要があります。 ストリームの設定が追加されたときに、バランスが取れている必要があります。 たとえば、ストリームのビット レートが 1200 ~ 1500 kbps の範囲で変動する場合は、ストリームの帯域幅は 1500 kbps に設定されている必要があります。 ストリームを 3000 kbps に設定すると、アクセス ポイントでサービスできるビデオ クライアントは少なくなります。 同様に、1000 kbps に設定すると、ピクセリゼーション、低音質、ユーザ エクスペリエンスの低下につながります。

ストリーム設定用に使用できる事前設定されたテンプレートがいくつかあります。 これらのテンプレートを選択する際には、同様の判断を行う必要があります。 いくつかの設定のキャプチャは、このドキュメントで前述されています(「ストリーム アドミッションおよびプライオリティ設定」)。 テンプレートを使用しない場合は、この他にもユーザ エクスペリエンスを向上するために使用できる設定がいくつかあります。 パケットの平均サイズは、ストリーミング ビデオに一致するように変更できます。 リソース予約コントロールをイネーブルにして定期的にアップデートを行い、システムが非常に頻繁に健全性をチェックするようにもできます。 また、RRC をディセーブルにして、RRC がアドミッション時のみ実行されるようにもできます。 ストリームのプライオリティを高い値に設定して、ストリームを優先することもできます。 値を 8 に設定すると、ストリームが優先され、ベスト エフォートにバンピングされることがなくなります。

前のポリシーのあらゆる違反で、ストリームはベストエフォートにダウングレードできましたりまたは廃棄することができます。 ベスト エフォートにダウングレードすることをお勧めします。

cuwns-vidstrm-guide-15.gif

cuwns-vidstrm-guide-conf8.gif

上記のように、マルチキャストの宛先の開始 IP アドレスと終了 IP アドレスは同じアドレスにできます。 また、コントローラでマルチキャスト アドレスの範囲を設定することもできます。 マルチキャスト アドレスのエントリ数またはストリームのエントリ数に制限はありません。 開始 IP アドレスは 239.4.5.1、終了 IP アドレスは 239.4.5.254 に設定できます。

VideoStream の設定は、アクセス ポイント上で両方の無線に対してイネーブルにできます。 無線の設定は、その無線がディセーブルになっているときのみ設定または変更できます。 一部の設定では、WLAN/SSID もディセーブルにしておく必要があります。

注: 無線で必要な設定すべてを、無線がディセーブルになっているときに行っておくことをお勧めします。

VideoStream のイネーブル化:802.11 a/n 無線

cuwns-vidstrm-guide-16.gif

[WIRELESS] > [802.11 a/n] > [Media] > [Media] をクリックして、VideoStream をイネーブルにし、CAC/QOS 設定を追加します。 無線で提供されるサービスのタイプに応じて、同様の設定が 802.11 b/g/n 無線で必要になる場合があります。

デフォルトでは、VideoStream は無線ではディセーブルになっています。 この機能は、[Multicast Direct Enable] ボックスをオンにすることでイネーブルにできます。 また、[Multicast Direct Max Number of Streams] をプルダウンすることで、マルチキャスト ストリームに参加できるクライアントの数を無線に設定できます。 これを [Auto] に設定して、すべてのクライアントがマルチキャスト ストリームに参加できるようにすることもできます。 無線上のクライアントの数は、1 ~ 20 の間で値を設定して制御できます。

cuwns-vidstrm-guide-17.gif

cuwns-vidstrm-guide-18.gif

ユニキャスト ビデオ リダイレクトは、デフォルトでイネーブルになっています。 これにより、ユニキャストのビデオ トラフィックはワイヤレス クライアントに流れます。

合格基準(前述)に達すると、RRC により、クライアントのストリームへの参加が許可されます。 許可されたクライアントの QoS プライオリティは 4 になります。 RRC の基準を満たさないクライアントはドロップされ、ストリームに参加できません。 しかし、ベスト エフォート QoS アドミッションをイネーブルにすると、これを無効にできます。 こうするとストリームへの参加を要求したワイヤレス クライアントはすべてマルチキャスト ストリームへの参加が許可されますが、一部のクライアントの QoS プライオリティは 0 になります。 現在、メディア帯域幅はデフォルトで 85 % に設定されています。

メディア帯域幅は、無線インターフェイス上の音声およびビデオ トラフィックの合計です。 ストリーミング ビデオに参加するために、クライアントが無線でドロップできる最低値は 6000 kbps です。 特定の PHY レート未満でストリームへの参加を制限する必要のあるクライアントが存在する場合は、この値を変更できます。 デフォルトでは、この値は 6000 です。 デフォルトでは、最大再試行パーセントは 80 % に設定されています。 システムは、無線上で実行された再試行をトラッキングしています。 再試行の回数が設定値を上回ると、クライアントはストリームに参加できなくなります。

注: デフォルト値を維持することをお勧めします。

[WIRELESS] > [802.11 a/n] > [Media] > [Video] をクリックして、CAC およびアドミッション制御をイネーブルにします。 ビデオのアドミッション制御をイネーブルにします。

無線でイネーブルにする必要のあるサービスのタイプに応じて、[Max RF Bandwidth] の値を設定します。 ここで追加する値は、無線で設定されているマルチキャスト ストリームへの参加を許可されるビデオ クライアントの数を決定します(音声およびビデオ CAC 値の表を参照)。 たとえば、最大値の 80 % に設定すると、20 個のワイヤレス クライアントによる、ビット レートが 5 M ビットのストリームが許可されます。

cuwns-vidstrm-guide-19.gif

[WIRELESS] > [802.11 a/n] > [Media] > [Voice] をクリックして、音声の CAC およびアドミッション制御をイネーブルにします。 音声のアドミッション制御をイネーブルにします。 ここで追加する値は、無線で許可される音声コールの数を決定します(音声およびビデオ CAC 値の表を参照)。

cuwns-vidstrm-guide-20.gif

VideoStream 設定を追加するために、無線はディセーブルにされています。 802.11a 無線をイネーブルにします。

VideoStream のイネーブル化:802.11b/g/n 無線

802.11b/g/n 無線に対して、上記の設定を繰り返し行います。 変更する前に、まず 802.11b/g/n 無線を無効にします。

cuwns-vidstrm-guide-21.gif

802.11b/g/n で VideoStream 機能をイネーブルにする場合、クライアントの密度が高いため、より注意深く進める必要があります。 ワイヤレス クライアントには十分な帯域幅を割り当てて、マルチキャスト ストリームに参加できるようにする必要があります。 設定を適用した際に大きな問題が起こらないように、802.11b/g/n 無線でのデータ、音声およびビデオ クライアントのバランス調整は、事前に慎重に計画する必要があります。

注: BandSelect および ClientLink は、ワイヤレス クライアントで使用される 2 つの機能で、2.4 GHz 無線上のクライアントを一部削減します。

802.11b/g/n 無線について、上記の 3 つのスクリーンショットに示されているステップを繰り返します。 次に、スクリーンショットを示します。

cuwns-vidstrm-guide-22.gif

デフォルトでは、VideoStream 機能は無線ではディセーブルになっています。 [WIRELESS] > [802.11 b/g/n] > [Media] > [Media] をクリックします。 [Multicast Direct Enable] 機能のボックスをオンにします。 [Multicast Direct Max number of Stream] をプルダウンして、1 ~ 20 の値を設定するか、またはデフォルトのままにします。

ユニキャスト ビデオ リダイレクトは、デフォルトでイネーブルになっています。 これにより、ユニキャストのビデオ トラフィックはワイヤレス クライアントに流れます。

合格基準(前述)に達すると、RRC により、クライアントのストリームへの参加が許可されます。 許可されたクライアントの QoS プライオリティは 4 になります。 RRC の基準を満たさないクライアントはドロップされ、ストリームに参加できません。 しかし、ベスト エフォート QoS アドミッションをイネーブルにすると、これを無効にできます。 こうするとストリームへの参加を要求したワイヤレス クライアントはすべてマルチキャスト ストリームへの参加が許可されますが、一部のクライアントの QoS プライオリティは 0 になります。

現在、メディア帯域幅はデフォルトで 85 % に設定されています。 メディア帯域幅は、無線インターフェイス上の音声およびビデオ トラフィックの合計です。 ストリーミング ビデオに参加するために、クライアントが無線でドロップできる最低値は 6000 kbps です。 特定の PHY レート未満でストリームへの参加を制限する必要のあるクライアントが存在する場合は、この値を変更できます。 デフォルトでは、この値は 6000 です。 デフォルトでは、最大再試行パーセントは 80 % に設定されています。 システムは、無線上で実行された再試行をトラッキングしており、再試行の回数が設定値を上回ると、クライアントはストリームに参加できなくなります。

[WIRELESS] > [802.11 b/g/n] > [Media] > [Video] をクリックして、CAC およびアドミッション制御をイネーブルにします。 ビデオのアドミッション制御をイネーブルにします。

無線でイネーブルにする必要のあるサービスのタイプに応じて、[Max RF Bandwidth] の値を設定します。 ここで追加する値は、無線で設定されているマルチキャスト ストリームへの参加を許可されるビデオ クライアントの数を決定します(音声およびビデオ CAC 値の表を参照)。

cuwns-vidstrm-guide-23.gif

[WIRELESS] > [802.11 b/g/n] > [Media] > [Voice] をクリックして、音声の CAC およびアドミッション制御をイネーブルにします。 音声のアドミッション制御をイネーブルにします。 ここで追加する値は、無線で許可される音声コールの数を決定します(音声およびビデオ CAC 値の表を参照)。

cuwns-vidstrm-guide-24.gif

クライアントが関連付けできるように、無線をイネーブルにします。

VideoStream の有効化:WLAN

設定されている WLAN/SSID の 1 つまたはすべてを、VideoStream を使用したビデオのストリーミング用にイネーブルにできます。 これは、VideoStream 機能の有効化を制御できる、もうひとつの設定手順になります。 VideoStream 機能のイネーブル化またはディセーブル化により、中断は発生しません。 [WLAN] > [<WLAN ID>] > [QoS] をクリックします。

cuwns-vidstrm-guide-25.gif

[Quality of Service] を [Gold(video)] に設定して、ゴールドの QoS 値(4)でワイヤレス クライアントにビデオをストリーミングします。 これは、コントローラで設定されているストリームに参加しているワイヤレス クライアントに対するビデオの Quality Of Service だけをイネーブルにします。 その他のクライアントに対しては、適切な QoS がイネーブルになります。 上記のように、WLAN の [Multicast Direct] チェックボックスをオンにすることでイネーブルにします。 これにより、WLAN のワイヤレス クライアントで VideoStream 機能のサービスが使用できるようになります。

ストリームへの参加を要求しているすべてのワイヤレス クライアントには、アドミッション時にビデオ QoS プライオリティが割り当てられます。 WLAN でこの機能をイネーブルにする前にビデオをストリーミングしていたワイヤレス クライアントは、通常のマルチキャストを使用してストリーミングしています。 この機能をイネーブルにすると、次回の IGMP スヌーピング間隔のときに、クライアントが自動的にマルチキャスト ダイレクトに切り替わります。

[Multicast Direct] チェックボックスをオフにしておくことで、WLAN でレガシー マルチキャストをイネーブルにできます。 これは、ビデオをストリーミングしているワイヤレス クライアントが、通常マルチキャスト モードであることを表します。

VideoStream 機能の確認

ワイヤレス クライアントがアクセス ポイントに関連付けられており、正しいインターフェイスが設定されていることを確認します。 次のキャプチャに示すように、1 つのアクセス ポイントに関連付けられているクライアントは 3 つあります。 これらのクライアントの IP アドレスは、3 つともすべて VLAN124(testclients)から受け取ったものです。

cuwns-vidstrm-guide-26.gif

関連付けられているクライアントは IP アドレスを取得しており、アクセス ポイントとのアップリンク接続は良好です。

cuwns-vidstrm-guide-27.gif

マルチキャスト ストリームに参加したクライアントはありません。 スイッチに登録されているマルチキャスト グループ アドレスが設定されたコントローラのエントリが存在するだけです。

Switch14-1>en
Password:
Switch14-1#sh ip mroute

IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, 
L - Local, P - Pruned, R - RP-bit set, F - Register flag, 
T - SPT-bit set, J - Join SPT, M - MSDP created entry, 
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, 
U - URD, I - Received Source Specific Host Report, 
Z - Multicast Tunnel, z - MDT-data group sender, 
Y - Joined MDT-data group, y - Sending to MDT-data group 
V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.1.2), 01:23:52/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00

(10.10.10.10, 239.100.1.2), 00:01:45/00:01:15, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.192.1.150), 01:23:55/00:02:13, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:23:55/00:00:00

有線ネットワークではビデオ ストリーミングは実行されていないため、(S,G)送信元、グループ アドレスのエントリはありません。 設定されているマルチキャスト アドレス 239.4.5.6 を使用してビデオ サーバに接続して、有線側のストリーミングをイネーブルにします。 スイッチのキャプチャは、前述のものよりも多くなります。

Switch14-1#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, 
L - Local, P - Pruned, R - RP-bit set, F - Register flag, 
T - SPT-bit set, J - Join SPT, M - MSDP created entry, 
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, 
U - URD, I - Received Source Specific Host Report, 
Z - Multicast Tunnel, z - MDT-data group sender, 
Y - Joined MDT-data group, y - Sending to MDT-data group 
V - RD & Vector, v - Vector

Outgoing interface flags: H - Hardware switched, A - Assert winner 
Timers: Uptime/Expires 
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.1.2), 01:23:52/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Vlan122, Forward/Sparse-Dense, 01:22:31/00:00:00

(10.10.10.10, 239.100.1.2), 00:01:45/00:01:15, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null

(*, 239.4.5.6), 01:23:34/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(10.10.10.101, 239.4.5.6), 00:08:26/00:02:58, flags: PT
Incoming interface: Vlan122, RPF nbr 0.0.0.0
Outgoing interface list: Null
Switch14-1#

デバッグ:スイッチ

ワイヤレス クライアントをマルチキャスト ストリーミング ビデオに参加させます。 また、コントローラから debug bcast all enable をキャプチャします。 デバッグのキャプチャには、クライアント要求、グループ アドレス、要求のステータスおよびアップデートの情報が含まれています。

*bcastReceiveTask: Sep 29 13:31:56.913: bcastProcessNPUMsg: received packet  
  (rxTunType 1, dataLen 155)  
*bcastReceiveTask: Sep 29 13:31:56.913: bcastLwappRx: received lwapp packet  
  from STA 0021.5dac.d898 
*bcastReceiveTask: Sep 29 13:31:56.913: IGMP packet received over vlanid = 0  
  from client 00:21:5d:ac:d8:98 
*bcastReceiveTask: Sep 29 13:31:56.913: Recieved Igmp v2 report packet from  
  client 00:21:5d:ac:d8:98 
*bcastReceiveTask: Sep 29 13:31:56.913: report packet recevied for group  
  addr 239.4.5.6 
*bcastReceiveTask: Sep 29 13:31:56.913: join group 239.4.5.6 and vlan = 0  
  is not there adding... 
*bcastReceiveTask: Sep 29 13:31:56.913: 00:21:5D:AC:D8:98 client joining the group:  
  239.4.5.6, with status = 1, qos=0 and valid = 1... 
*bcastReceiveTask: Sep 29 13:31:56.929: Received status Update for  
  client: 00:21:5D:AC:D8:98 , status = 2, qos = 4  
*bcastReceiveTask: Sep 29 13:31:56.929: 00:21:5D:AC:D8:98 client status is updated  
  from 1 to ALLOWED state.  
*bcastReceiveTask: Sep 29 13:31:56.930: IGMP message send succeeded src 10.10.10.10  
  and dst 239.4.5.6, hdr len 32,message type 16 
*bcastReceiveTask: Sep 29 13:31:56.930: update ap for status = 2

MAC アドレスが 00:21:5d:ac:d8:98 のワイヤレス クライアントがストリーム アドレス 239.4.5.6 に対して IGMP v2 join をレポートの形式で送信しました。 クライアントは qos=4 のグループに参加しました。状態は ALLOWED に変わりました(フロー図を参照)。

[MONITOR] > [Multicast] をクリックし、ストリーム アドレス 239.4.5.6 の MGID をクリックします。 ワイヤレス クライアントの MAC アドレスが「マルチキャスト ダイレクト許可」状態であることが確認できます。 QoS ユーザ プライオリティは 4 です。 これは、クライアントがビデオ キューにあるビデオ パケットを処理していることを表します。

cuwns-vidstrm-guide-28.gif

cuwns-vidstrm-guide-conf9.gif

デバッグ:コントローラ

コントローラでデバッグをイネーブルにすることにより、コントローラでのワイヤレス クライアント要求の処理を明確に説明しました。 イネーブルにしたデバッグは、コントローラでもキャプチャされています。 MAC アドレスが 0021.5dac.d898 のクライアントに対して、要求 3646 が作成されています。 MAC アドレスが 0021.5dac.d898 のクライアントに関するデータ フローのすべてが、次のデバックに示されています。 RRC が起動し、関連付けられている無線のリソースを検証します。 検証が正常に完了し、検証された値に基づいてクライアントが許可されます。 ストリームが許可されるまで、ストリームはブロックされた状態のままとなり、クライアントは一切ビデオを受信しません。 クライアントは、参加応答を受け取り次第、ビデオのストリーミングを開始します。

同一のクライアントからのその他の要求もすべて検証されます。 クライアントはすでにストリーミングしているため、RRC エンジンは「Already admitted」メッセージで応答します。 これは、ワイヤレス クライアントのパフォーマンスを妨げるものではありません。

(Cisco Controller) >show debug

MAC debugging .............................. disabled

Debug Flags Enabled:
Media-Stream Admission debug enabled.
Media-Stream Config debug enabled.
Media-Stream Errors debug enabled.
Media-Stream Event debug enabled.
Media-Stream Rrc debug enabled.

(Cisco Controller) >
*rrcEngineTask: Sep 29 15:37:13.181: rrcEngineProcessPurgeTimer: table expired
*bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform test AP 1100 type
*bcastReceiveTask: Sep 29 15:37:18.599: msPolicyPlatform not AP 1100
*bcastReceiveTask: Sep 29 15:37:18.599: mStreamWlanMc2ucAllowed allow
*bcastReceiveTask: Sep 29 15:37:18.599: mStreamBand 1 allow mc2uc
*bcastReceiveTask: Sep 29 15:37:18.599: stream policy allow mc2uc
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc update client 0021.5dac.d898
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyGetRrcQosSupport 1 4 1
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc begin check policy
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform test AP 1100 type
*bcastReceiveTask: Sep 29 15:37:18.605: msPolicyPlatform not AP 1100
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc qos admit 1 qos 4 pri 1
*bcastReceiveTask: Sep 29 15:37:18.605: mc2uc submit client client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 mgid 569 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:18.605: start FindRequestByClient
*bcastReceiveTask: Sep 29 15:37:18.605: FindRequestByClient not found  
  dest ef040506 client 0021.5dac.d898 radio c47d.4f53.14f0
*bcastReceiveTask: Sep 29 15:37:18.605: Creating request 3646
*bcastReceiveTask: Sep 29 15:37:18.605: for radio c47d.4f53.14f0
*bcastReceiveTask: Sep 29 15:37:18.605: for client 0021.5dac.d898
*bcastReceiveTask: Sep 29 15:37:18.605: rrcEngineInsertAdmitRequest dest ef040506  
  mgid 569 request 3646
*bcastReceiveTask: Sep 29 15:37:18.606: rrcEngineSendMeasureMetricsRequest  
  sent request 3646 to radio c47d.4f53.14f0, minRate = 6000, maxRetryPercent = 80
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineProcessRadioMetrics  
  start radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest look for request 3646
*rrcEngineTask: Sep 29 15:37:18.607: rrcEngineFindRequest found request 3646
*rrcEngineTask: Sep 29 15:37:18.607: done rrcEngineProcessRadioMetrics  
  radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineProcessClientMetrics  
  radio c47d.4f53.14f0 request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest look for request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineFindRequest found request 3646
*rrcEngineTask: Sep 29 15:37:18.613: rrcEngineRemoveAdmitRequest request 3646
*rrcEngineTask: Sep 29 15:37:18.613: p_video = 0, p_voice = 0, pb = 198, 
  video_qo = 0, video_l_r_ratio = 0, video_no = 0, video_delay_hist_severe = 0,  
  video_pkt_loss_discard = 0, video_pkt_loss_fail = 0,
*rrcEngineTask: Sep 29 15:37:18.613: radio_tx_q_max_size = 1,  
  radio_tx_q_limit = 672, vi_tx_q_max_size = 0, current_rate = 234
*rrcEngineTask: Sep 29 15:37:18.613: msPolicyGetStreamParameters 1500 1200
*rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646  
  radio c47d.4f53.14f0, decision 1
*rrcEngineTask: Sep 29 15:37:18.613: Admit video: client number 0 request 3646  
  radio c47d.4f53.14f0, decision 1
*rrcEngineTask: Sep 29 15:37:18.613: mStreamBandMc2ucAdmit besteffort 0
*rrcEngineTask: Sep 29 15:37:18.613: Approve Admission on radio c47d.4f53.14f0  
  request 3646 vlan 124 destIp ef040506 decision 1 qos 4 admitBest 0
*rrcEngineTask: Sep 29 15:37:18.614: Recording request 3646 destIp ef040506 qos 4  
  vlan 124 violation-drop 0 priority 1
*rrcEngineTask: Sep 29 15:37:18.614: done rrcEngineProcessClientMetrics  
  client 0021.5dac.d898 radio c47d.4f53.14f0 request 3646
*bcastReceiveTask: Sep 29 15:37:19.553: mc2uc update client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124
*bcastReceiveTask: Sep 29 15:37:19.553: Already admitted, mc2uc  
  Update the last IGMP timestamp
*bcastReceiveTask: Sep 29 15:37:20.553: mc2uc update client 0021.5dac.d898  
  radio c47d.4f53.14f0 destIp ef040506 srcIp 0 mgid 569 slot 1 vapId 1 vlan 124

(Cisco Controller) >

Show コマンド:コントローラ

一部の show コマンドのキャプチャは、このドキュメントで前述されています。 このセクションのキャプチャは、参照用のみです。 コマンドの詳細については、『CUWN Release 7.0 コマンド リファレンス ガイド』を参照してください。

(Cisco Controller) >show ap summary

Number of APs.................................... 1

Global AP User Name.............................. Not Configured
Global AP Dot1x User Name.................... Not Configured

AP Name  Slots AP Model Ethernet MAC Location Port Country Priority
------------- ----- -------------------- ----------------- ----------------
CAP3502E 2 AIR-CAP3502E-A-K9 c4:7d:4f:3a:06:86 default location LAG US 1

(Cisco Controller) >

(Cisco Controller) >show client summary

Number of Clients................................ 2

MAC Address AP Name Status WLAN Auth Protocol Port Wired
----------------- - ---------------- ------------- ---------- ---- 
00:1d:e0:00:ab:c7 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No
00:21:5d:ac:d8:98 CAP3502E Associated 1 Yes 802.11n(2.4 GHz) 13 No

(Cisco Controller) >

(Cisco Controller) >show media-stream multicast-direct state
Multicast-direct State........................... enable
Allowed WLANs.................................... 1

(Cisco Controller) >

(Cisco Controller) >show media-stream group summary
Stream Name Start IP End IP Operation Status
------------- -------------- -------------- ----------------
test1.5K 239.4.5.6 239.4.5.6 Multicast-direct

(Cisco Controller) >

(Cisco Controller) >show media-stream group detail test1.5K
Media Stream Name................................ test1.5K
Start IP Address....................................... 239.4.5.6
End IP Address........................................ 239.4.5.6
RRC Parmmeters
Avg Packet Size(Bytes)............................... 1200
Expected Bandwidth(Kbps)........................ 1500
Policy......................................................... Admit
RRC re-evaluation....................................... periodic
QoS............................................. Video
Status................................... ...... Multicast-direct
Usage Priority.............................. 1
Violation...................................... fallback

(Cisco Controller) >

(Cisco Controller) >show network multicast mgid summary
Layer2 MGID Mapping:
-------------------
InterfaceName vlanId MGID
------------------------ ------ ----
data 123 11
management 0 0
testclients 124 12
Layer3 MGID Mapping:
-------------------
Number of Layer3 MGIDs........................... 7
Group address Vlan MGID
--------------- --- ----
224.0.0.251 0 550
224.0.0.255 0 555
224.2.127.254 0 552
239.4.5.6 0 556
239.195.255.255 0 553
239.255.255.250 0 551
239.255.255.255 0 554

(Cisco Controller) >show 802.11b media-stream rrc
Multicast-direct................................. Enabled
Best Effort.......................................... Disabled
Video Re-Direct................................. Enabled
Max Allowed Streams........................ Auto
Max Video Bandwidth....................... 30
Max Voice Bandwidth........................ 55
Max Media Bandwidth....................... 85
Min PHY Rate..................................... 6000
Max Retry Percentage........................ 80

(Cisco Controller) >

結論

より新しいコントローラハードウェアの CUWN 7.2 ソフトウェアサポート VideoStream 機能。 これには下記のものが含まれます。

  • Cisco 5500 シリーズ コントローラ

  • ワイヤレスサービス モジュール- 2

  • Cisco 2500 シリーズ コントローラ*

  • SRE モジュールが付いている Cisco ISR-G2 *

注: * —パフォーマンス 番号は non-802.11n アクセス ポイントで異なります。

CUWN 7.0 ソフトウェアは、新しいコントローラ ハードウェアで VideoStream 機能をサポートしています。 これには下記のものが含まれます。

  • Cisco 5500 シリーズ コントローラ

  • Cisco 4400 シリーズ コントローラ

  • Cisco 2100 シリーズ コントローラ

  • ワイヤレス サービス モジュール

VideoStream はまたスタンドアロンおよび Cisco WiSM-2 コントローラ Cisco 2504 でサポートされます。

すべてのより新しい 802.11n アクセス ポイントおよび少数のレガシー アクセス ポイントの CUWN 7.2 ソフトウェアサポート VideoStream 機能。 これには下記のものが含まれます。

  • Cisco Aironet 3600 シリーズ アクセス ポイント

  • Cisco Aironet 3500 シリーズ アクセス ポイント

  • Cisco Aironet 1260 シリーズ アクセス ポイント

  • Cisco Aironet 1250 シリーズ アクセス ポイント

  • Cisco Aironet 1240AG シリーズ アクセス アクセス・ポイント**

  • Cisco Aironet 1140 シリーズ アクセス ポイント

  • Cisco Aironet 1130AG シリーズ アクセス アクセス・ポイント**

  • Cisco Aironet 1040 シリーズ アクセス ポイント

注: ** —クライアント キャパシティは低価格のコントローラで変わります。

VideoStream 機能は、Cisco Unified Wireless ハードウェアを使用して優れた品質でビデオをストリーミングします。 スタティック CAC 設定により、無線上でワイヤレス クライアントが制御できます。 この機能により、有線クライアントでのマルチキャスト ストリーミングと同等の品質で、無線でのマルチキャスト ストリーミングが可能になります。 IGMP 参加要求のみを使用したワイヤレス クライアントへのマルチキャスト ストリーミングと複製は、アクセス ポイントのみで行われます。これにより、ディストリビューション スイッチおよびアクセス スイッチのアップリンク ポート上の帯域幅を節約しています。

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

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


関連情報


Document ID: 112889