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

エンタープライズ向け Video over WLAN の最適化

ホワイト ペーパー





エンタープライズ向け Video over WLAN の最適化



概要


ビデオがビジネス コラボレーションを大きく変化させています。IPTV を利用した経営陣と従業員とのコミュニケーション、販促会議やトレーニング セッションのオンデマンド再生、テレビ会議など、リッチメディア アプリケーションはさまざまな用途で活用されており、分散したグループ間のコミュニケーション効率の向上に役立っています。また、コラボレーションの速度と信頼性を高め、出張費用の削減や、ビジネスの俊敏性と競争力の向上にも効果をもたらします。一方で、モバイル ワーカーの数と IP ネットワークを利用する Wi-Fi エンドポイントの数も増え続けており、ワイヤレス LAN 上でのビデオ伝送(Video over WLAN)をサポートすることが、IT 担当者に新たな課題をもたらしています。

音声やデータと同様に、ビデオ アプリケーションがビジネス プロセスに統合されることが増えるにしたがって、エンド ユーザは、場所やデバイスに関係なく、同じレベルのサービスとユーザ エクスペリエンスでこのようなアプリケーションにアクセスできる柔軟性を望むようになります。従来のワイヤレス ネットワークでは、エンドツーエンドの接続性、帯域幅、および一貫した高品質のユーザ エクスペリエンスを柔軟に提供するという課題に、費用効率よく対応できないという問題に直面する組織も多く見られます。

このドキュメントの前半では、Wi-Fi 上でビジネス ビデオを配信する場合の課題を検討し、リアルタイム ビデオ アプリケーションのための高度で柔軟なプラットフォームを提供する主な技術要素について説明します。また、新しい Cisco® VideoStream テクノロジーも紹介します。このテクノロジーをエンドツーエンド メディアネット フレームワークと統合することで、有線とワイヤレスのネットワークを介して配信されるメディアリッチ アプリケーションを最適化し、ビジネスに必要なパフォーマンス、品質、およびスケーラビリティを実現する方法について説明します。

エンタープライズ向け Video over WLAN に対するニーズの進化


経済が回復しつつある今、ネットワーク インフラストラクチャの既存の投資を活用してコストを削減し、競争優位性を取り戻すことは、IT 担当者にとって重要な作業です。Video over Wi-Fi などのリッチメディア アプリケーションをサポートすることで、出張コストを削減し、分散しているモバイル ワーカーがネットワークにアクセスできるだけでなく、新しい収益の機会が増え、市場の変化に対するビジネスの俊敏性と応答性も向上します。仮想の対面コミュニケーションによってビジネス関係を構築し、信頼性を高め、成果へと導くことができるかどうかは、競争の勝敗を分ける要素になりうると、多くの企業が認識しています。

その一方で、ビデオはネットワークの弱点が即時に影響する要件の厳しいアプリケーションです。Wi-Fi 上で配信されるビデオはエンタープライズクラスの体感品質で提供される必要があります。つまり、信頼性が高く同期がとれる方法で、中断することなく、複数のビデオ、音声、およびデータ ストリームをサポートできなければなりません。遅延、パケット損失、およびジッタによって目に見えるほど品質が劣化すると、ビデオの実用性はすぐにゼロになります。クリアに伝達できないビデオには実用性はありません。2012 年までにインターネット トラフィックの 90% 近くをビデオが占めると予想されていますが、企業がビデオを活用するには、まずエンタープライズ クラスのビデオを Wi-Fi ネットワーク上で展開することの要件と複雑さを理解する必要があります。

ビデオの複雑さの理解


Video over Wi-Fi の拡張には、有線ネットワークとは異なる課題があります。その課題の理由は、一定しないデータ レート、パケット損失、マルチキャストの信頼性の低さなど、Wi-Fi 固有のネットワーク パフォーマンスの特性がもたらされるためです。このような特性は、保証された Quality Of Service(QoS)に対する従来のアプローチの一部に反して作用します。Video over Wi-Fi の基本的な課題を理解するために、このような各要因の特性を理解することが重要です。

一定しないデータ レート

Wi-Fi と有線 LAN の大きな違いは、まず Wi-Fi 上のデータ送信レートが、時間や、アクセス ポイントからクライアントまでの距離によって変わることです。これは従来の有線システムとは対照的です。有線の場合、今日 100 Mbps で接続できれば、明日も 100 Mbps で接続できます。データ レートが変化するため、個々のビデオ フローのスループットと全体的なネットワークの容量が時間によって変わります。

お分かりのとおり、スループットと容量が可変であることは、帯域幅の予約とアドミッション コントロールという従来の QoS アプローチはうまく機能しません。たとえば、54 Mbps で運用しているクライアントがあり、10 Mbps のビデオ ストリームが必要だとします。システムでは、新しいストリームに必要な通信時間に対応できると判断され、そのストリームを受け入れます。ところが、クライアントはそのアクセス ポイントから離れ、クライアントのデータ レートは 6 Mbps まで低下します。そのため、ビデオ ストリームをサポートできなくなります。このように、Wi-Fi ネットワーク上でビデオを送信することは、パブリック インターネット上でビデオを送信することと類似点があります。パブリック インターネットの場合は、スループットとユーザのエクスペリエンスは時間によって大きく変わります。

パケット損失

Wi-Fi が有線 LAN と大きく違う点として、基礎となるレイヤ 2 トランスポートの信頼性が相対的に低いこともあります。簡単に言うと、Wi-Fi は有線よりもパケットが多く損失します。

パケット損失の第 1 の理由は衝突です。つまり、2 つの Wi-Fi デバイスが同時に送信を試みることです。Wi-Fi では共有の半二重メディアを使用しています。このような Listen-Before-Talk のメディア アクセス方法では衝突を避けようとしますが、完全には回避できません。Wi-Fi 非対応デバイスがあると、この状況はさらに悪くなります。Wi-Fi デバイスと同じ帯域で使用されることがあるためです。ほとんどのデバイスは Listen-Before-Talk アルゴリズムにすら従っていません。そのため、衝突はよく起こります。

パケット損失の第 2 の理由は、Wi-Fi 伝送では短期の信号損失(フェードと呼ばれます)が発生しやすいことです。このような損失は、環境に介在する物体(人など)に電波が吸収されたり、環境内で電波が反射することで誤って信号がキャンセルされるために発生します。

前の 2 つよりも小さな問題ですが、パケット損失の第 3 の要因は Wi-Fi システムがさまざまなレートを試行して最適な伝送データ レートを探すことです。その結果、検索プロセス中に一部のパケットが損失します。

衝突、信号損失、およびデータ レート選択が組み合わされた結果、Wi-Fi 環境のパケット損失率が 5% に達することも珍しくはありません。この問題を緩和するために、Wi-Fi では、受信と確認応答に失敗したパケットを再送信するメカニズムを使用しています。一般的に、このメカニズムを使用すると、最終的なパケット損失率は 0.1% 未満まで減ります。ただし、このような再送信はジッタの原因になり、全体的なネットワーク スループットを低下させ、QoS に影響を与えてしまいます。また、再送信を行っても、最終的なパケット損失率は有線接続の場合よりもはるかに高くなります。

マルチキャストの信頼性の低さ

基盤となるパケット損失率は、Wi-Fi マルチキャスト トラフィックの場合にさらに顕著に影響します。(受信者が複数いる)マルチキャスト送信の場合、Wi-Fi に再送信メカニズムは用意されていません。そのため、マルチキャスト トラフィックのパケット損失率(PLR)は PER と同等になります。つまり、Wi-Fi マルチキャスト トラフィックで 5% のパケット損失率が発生することは珍しいことではありません。1 パケットの損失でも多数のビデオ フレームに影響が及ぶエラーになりうるため、ビデオにとってこのようなパケット損失は重大な問題です。そのため、有線ネットワークで機能するマルチキャスト ビデオ アプリケーションが、Wi-Fi ネットワークでは完全に失敗することはよくあります。

このような要因がビデオに影響を及ぼす一方で、アプリケーション側でもこれらの要因に対処する方法を考慮する必要があります。ビデオは、複数の異なる用途で利用されます。いくつかの一般的なアプリケーション モデルを理解することで、対応する必要がある固有の要件を判断できます。

一般的な Video over Wi-Fi アプリケーション モデル


多くの場合、エンタープライズでのビデオの一般的な使用方法は、インタラクティブ テレビ会議、ビデオ オンデマンド、およびライブ ストリーミング ビデオという 3 つのアプリケーション カテゴリにグループ化できます。これらのカテゴリの QoS 要件(および対応するネットワーク要件)は大きく異なります。図 1 は、3 種類の Video over Wi-Fi アプリケーション モデルの特性をまとめたものです。

図 1 エンタープライズ ビデオ アプリケーション モデル

図 1 エンタープライズ ビデオ アプリケーション モデル

図 1 エンタープライズ ビデオ アプリケーション モデル
※画像をクリックすると、大きな画面で表示されますpopup_icon


インタラクティブ テレビ会議

テレビ会議アプリケーションはエンドツーエンドの遅延を少なくする必要があります。遅延が多いと、リアルタイムの対話でユーザが中断に気付くことになります。そのため、電話会議アプリケーションは再生バッファの使用サイズを小さくする必要がありますが、その結果、遅延とジッタの影響を受けやすくなります。デスクトップの電話会議のビデオ ストリームは一般的にデータ レートが低い(1 Mbps)ため、スループットは大きな問題ではありません。ただし、ストリームは大幅に圧縮され、User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ベースの伝送が使用される場合もあるため、当然ながら、パケット損失の影響も受けやすくなります。

Cisco TelePresence™ などの高解像度のテレビ会議アプリケーションでも同様に、遅延とジッタを極力抑える必要があります。HD ビデオ ストリームのように、非常に高い圧縮率で圧縮されるビデオでは、パケット損失は大きな問題になります。また、圧縮後でも HD ストリームは 5 〜 10 Mbps にもなるため、スループットも重大な問題です。

ビデオ オンデマンド

ビデオ オンデマンド アプリケーションでは、一般的にユニキャスト ファイル転送メカニズムとプログレッシブ再生を併用しています。このようなアプリケーションは再生バッファ サイズを大きくすることができるため、遅延とジッタは大きな問題ではありません。さらに、TCP ユニキャストの用法では再送信を考慮しているため、パケット損失も主要な問題ではありません。ただし、ストリームはかなり高いビット レートになる可能性があるため(一部のオンデマンド ビデオは HD 品質に近づいています)、スループットは重要です。

ストリーミング ビデオ

ライブ イベントのストリーミング ビデオ アプリケーションには、IPTV(企業イベントのブロードキャスト、IP 上で提供されるケーブル テレビのサービスなど)やビデオ監視が含まれます。このような一方向のアプリケーションは、QoS 要件を制限するために一般的にかなり大きな再生バッファを使用する可能性があります。ただし、一部のアプリケーションでは、高速なチャネル変更の要件や他のリアルタイムの制約(たとえば、ユーザがリアルタイムの動きを見られるように、複数のカメラ アングルからのスタジアムの映像を配信するストリーミング ビデオなど)によって、再生バッファのサイズが制限されます。そのため、一般的に IPTV アプリケーションでは、遅延とジッタは中程度の問題です。効率性のためにマルチキャストが使用される場合、UDP が使用されるため、パケット損失はとても重要な問題になります。ライブ ストリーミング アプリケーションのビット レートはさまざまですが、場合によっては、スループットも重要です。

表 1 は、各種アプリケーションが受ける影響度を、QoS パラメータごとに表したものです。

表 1 ビデオ アプリケーションが受ける QoS 要件別影響度

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

Video over Wi-Fi を配信するための主な要素


組織がこのように多様なビデオ アプリケーションの利点を認識し、高まる需要に対処し始めるにつれて、当然ながら既存のインフラストラクチャでの対応可能性に関する疑問と懸案事項が上がり始めています。高品質のビデオ パフォーマンスを可能にするために必要なネットワーク要素は、802.11n テクノロジーに基づく広範なプラットフォームなど、複数あります。802.11n は、遅延の影響を受けやすいマルチメディア アプリケーションに必要な、スループット、信頼性、および予測可能性を実現します。

ここでは、ネットワークの物理レイヤ、MAC レイヤ、およびアプリケーション レイヤの機能強化が、どのように Video over Wi-Fi のパフォーマンス、品質、および拡張性を向上させるかについて説明します。

物理レイヤの強化

信頼性の高い Video over Wi-Fi を実現するための強化の第一段階は、基礎となる物理レイヤの接続の品質です。簡単に言うと、物理レイヤを改善(信頼性を高く)することで、データ レートが高くなり、再送信が減るため、ビデオを(他のすべてのアプリケーションも同じ)スムーズに利用できるようになります。

802.11n には、Wi-Fi 物理レイヤの品質の点でいくつかの重要な利点があります。802.11n では Multiple-Input Multiple-Output(MIMO)アンテナ テクノロジーを使用することで、基本的に以前のバージョンの 802.11 よりも高レベルの 信号対雑音比を実現します。信号対雑音比の改善によって、高データ レート(高スループット)が可能になり、リンクの信頼性が向上します(信号損失とレート選択のための再送信が少なくなります)。

802.11n インフラストラクチャには、古い 802.11ag クライアントと連携する場合でも利点があります。一般的に、アップリンク方向の通信にこのような利点があります(802.11n のアクセス ポイントは複数のレシーバを使用することで、より多くのクライアント通信を受信できます)。そのため、ビデオ サーベイランスやテレビ会議などのアップリンク コンポーネントを持つアプリケーションに有効です。ただし、通常はダウンリンク方向(802.11n アクセス ポイントから古い 802.11ag クライアントにビデオをダウンリンクする場合)には同様の利点がありません。Cisco 802.11n アクセス ポイントには、Cisco ClientLink という独自の機能があります。ClientLink では、802.11n アクセス ポイントから 802.11ag クライアントに対してダウンリンク ビームフォーミングを使用して、クライアントが受信できる信号を引き上げます。ClientLink テクノロジーを使用すると、ダウンリンク コンポーネントがある IPTV やテレビ会議などのビデオ トラフィック アプリケーションに大きな利点があります。

MAC レイヤの強化

Wi-Fi プロトコル レベルでも、ビデオのパフォーマンスを改善できる機能が複数あります。MAC レイヤでまず最も基本的な強化は、Wi-Fi Multimedia(WMM)拡張です。WMM には、音声、ビデオ、ベスト エフォート(BE)、およびバックグラウンドという 4 つの優先キューイングがあります。WMM を利用することで、ビデオ アプリケーションは他の BE トラフィックよりも高い優先度でビデオ トラフィックを実行できます。優先度が高いと、基本的に、あるデバイスのキューにビデオと BE パケットがあるとき、ビデオ パケットが最初に送信されることを意味します。さらに、ビデオ パケットには優先的なアクセスが与えられます。結果として、共有メディアが他のデバイスと競合している場合、ビデオ パケットが優先される可能性が高くなります。

また、WMM には TSPEC というリソース予約メカニズムが用意されています。WMM クライアントから TSPEC 要求を発行することで、アクセス ポイントとの通信時間を予約できます。アドミッション コントロールに TSPEC を使用すると、多数のビデオ クライアントがアクセス ポイントに殺到してユーザ操作性が悪くなる状況を回避できます。

WMM 実装の一部の詳細については、ベンダーが独自に実装できる領域として残されています。また、これにはとても重要な詳細も含まれます。たとえば、WMM は、データ レートと再試行などの MAC パラメータに関して、ビデオ パケットの詳細な処理を規定していません。ただし、ビデオ データの QoS 要件があるため、ビデオ パケットは特別に考慮する必要があります。再試行は望ましくないため、ビデオ パケット用に選択されたデータ レートの場合、システムの処理はやや緩くする必要があります。また、再試行の回数とビデオ パケットがキューに保存される時間を制限する必要があります。最新の受信データが無駄になる可能性があるためです (多くの場合、古いフレームを送信し、ネットワークの通信時間を不必要に利用し続けるよりも、古いフレームをドロップする方が望ましい方法です)。さらに、デフォルトの WMM バックオフ パラメータ(伝送を再試行する前の時間を制御します)は、ビデオ トラフィック用に最適化されていません。WMM を実装する場合、このようなパラメータのシミュレーションと調整が必要です。

WMM 仕様に規定されていない詳細事項の例として、新しい TSPEC 要求を許可または拒否するタイミングをインフラストラクチャで決定する方法があります。前述のように、Wi-Fi およびビデオが持つ課題の 1 つは、データ レートと容量の可変性です。そのため、新しいストリームを適応できるタイミングを決定する高度なアドミッション コントロール アルゴリズムをインフラストラクチャで利用することが重要です。

アドミッション コントロール アルゴリズムで重要なのは、既存のトラフィックと実行方法を分析するためのデータを集めることです。個々のビデオ フローの測定を続ける必要があります。このような測定によって、アドミッション コントロール用のデータが作成されるだけでなく、管理システムで特定のトラフィック ストリームをデバッグするときにも役立ちます。アドミッション コントロール アルゴリズムの初期設定が完了したら、フローの測定を使用して、予想よりも低いパフォーマンスのフローを監視します(セルのエッジに移動したクライアントなど)。パフォーマンスが低いフローの場合、他のクライアントのパフォーマンスを確保するためにフローを無効にすることもあります。

また、アドミッション コントロール アルゴリズムでは、ある形式のトラフィック(ビデオ、音声、データ)が空き帯域幅を使い切らないように、管理者が複数のトラフィックに優先度を付けることができるようにします。たとえば、データ アプリケーションが少なくとも一定レベルのサービスを受けられるように、ベスト エフォート トラフィック用に 20% 以上の帯域幅を予約するとします。また、帯域幅の 80% を音声とビデオのトラフィックに使用できるようにします。管理者は 60% を超える帯域幅をいずれかのトラフィックに使用しないように指定することを考えています。これは、ビデオ トラフィックが音声トラフィックを(またその反対についても)締め出さないようにするためです。このように柔軟性のある設定にすると、すべての種類のアプリケーションが適切に共存することができます。

また、アドミッション コントロール アルゴリズムでは、隣接するアクセス ポイント間のローミングについても考慮する必要があります。それによって、ビデオ クライアントがフロア ペース内を移動したときに別のアクセス ポイントに移動する状況を処理できるようになります。アドミッション コントロール アルゴリズムをシステムのロード バランシング機能に対応させる必要もあります。通常、クライアントは輻輳を最小限に抑えるために複数のアクセス ポイントに分散しているためです。さらに、クライアントの新しいフロー要求が拒否された場合、そのフローを処理する可能性がある隣接するアクセス ポイントに関する情報を与える必要があります。

最後に、ビデオのアドミッション コントロールは、個々の Wi-Fi ホップだけでなく、エンドツーエンド ベースで実行するのが理想的です。たとえば、Wi-Fi ホットスポットのクライアントが、インターネット上のサーバからビデオ ストリームを受信することを要求しているとします。Wi-Fi リンクで通信時間を要求することは、大した問題ではありません。ホットスポットからインターネットまでのバックホールの帯域幅でビデオ トラフィック フローを処理できない場合、ユーザ エクスペリエンスは低質になります。エンドツーエンドのアドミッション コントロールを実現するには、リソース予約プロトコルなどのメカニズムを採用する必要があります。基本的に、クライアントは高品質のストリームを実現するために、TSPEC 要求とリソース予約プロトコル要求の両方を発行して、必要なリソースをすべて使用できるように確保します。または、クライアントは TSPEC 要求のみを発行し、インフラストラクチャがプロキシとしてエンドツーエンドの RSVP 要求を実行するという方法もあります。

MAC レイヤのマルチキャスト固有の強化

前述のように、Wi-Fi 上のマルチキャスト ビデオには固有の課題が複数あります。第 1 の課題は、Wi-Fi 上のマルチキャスト トラフィックには確認応答が送信されないため、パケット損失率が 5 〜 10% に達する可能性があることです。さらに、その他の課題もあります。たとえば、すべてのクライアントでパケットを受信できるように、マルチキャストに適した伝送データ レートが選択されることなどです(ただし、セルのすべての通信時間を使い切るほど伝送速度が遅くならないようにします)。Wi-Fi マルチキャストのもう 1 つの課題は、マルチキャスト グループの任意のメンバーが省電力モードで操作している場合、そのグループのすべてのトラフィックは Delivery Traffic Indication Message(DTIM)インターバルを開始する必要があることです。

Wi-Fi 上のマルチキャスト ビデオの問題を解消する効率的な方法として、マルチキャスト トラフィックをユニキャストに変換する方法があります。この機能は、信頼できるマルチキャストまたはマルチキャスト ダイレクトと呼ばれます。基本的に、IP レイヤのパケットはマルチキャストのままです。ただし、Wi-Fi レイヤ(レイヤ 2)では、マルチキャスト グループにサブスクライブしている各クライアントに対するパケットはユニキャストです。この方法はとても効率的ですが、クライアントの数だけ通信時間が長くなるという短所があります。つまり、このアプローチは、限られた数のクライアントが同じストリームにサブスクライブしている場合にのみ有効です。そのため、多数のサブスクライバが参加して過度な輻輳が発生しないように、信頼できるマルチキャスト機能にアドミッション コントロールを含めることが重要です。

アプリケーション レイヤの強化

Video over Wi-Fi を強化するためのおそらくほとんどの高度な機能には、アプリケーション、コーデック レイヤ、またはその両方の点でビデオに対応するインフラストラクチャが必要です。

ビデオ ストリームの識別

すべてのクライアントが、WMM TSPEC 要求を介してストリームをビデオと識別するのが理想的です。ただし現実問題として、将来のある時点で、この機能を持たないクライアントが混在することになります。たとえば、ノート PC ベースのクライアントで実行される Web アプリケーションは、TSPEC 要求を発行するための Wi-Fi ドライバの必要なフックにアクセスできない可能性があります。そのため、Wi-Fi インフラストラクチャは、ビデオ トラフィックを伝送するストリームを識別する代替手段をいくつか用意しています。

ビデオ ストリームを識別するほとんどの一般的な代替手段は、Differentiated Services Code Point(DSCP)マーキングを IP ヘッダーに使用しています。DSCP マーキングによって、パケットをビデオの優先度で扱う必要があるとインフラストラクチャに知らせることができます。DSCP のみを使用することの短所は、アドミッションを明示的に要求する仕組みがないため、インフラストラクチャにアドミッション コントロールを採用しにくいことです。

ビデオ フローであることを暗黙的に示すもう 1 つの方法は、複数の Basic Service Set Identifier(BSSID)をサポートする機能をインフラストラクチャに持たせ、ビデオ トラフィックに 1 つの BSSID を指定する方法です。この場合、Video over Wi-Fi を使用したいクライアントは、ビデオ用の BSSID と関連付けることによって、クライアントの要求を宣言することができます。このアプローチは用途が固定されたデバイス(たとえば、テレビ会議ユニットやデジタル サイネージ システムなど)の場合は非常に便利ですが、ノート PC のように多様なトラフィック タイプを同時に使用する汎用的なクライアントには適していません。

暗黙的にビデオ ストリームを示すその他の方法として、ビデオに使用されることがわかっている特定の IP アドレスとポートの組み合わせを持つ設定を、インフラストラクチャがサポートする方法があります。たとえば、ある企業に社内のコミュニケーションやトレーニングに使用する社内ビデオ サーバがあり、管理者が、そのサーバから送信されるトラフィックを常にビデオとして設定することができるとします。このようなシナリオでは、設定済みアドレスの使用は単純で効率的です。

暗黙的なビデオ ストリーム検出の高度な方法として、パケットをスヌーピングし、ストリームにビデオが含まれているかどうかを独自に判断する機能をインフラストラクチャに持たせる方法があります。たとえば、Session Initiation Protocol(SIP)や Internet Group Management Protocol(IGMP)などのコール設定プロトコルをシステムでスヌーピングすることで、新しいビデオ ストリームが開始されたことを検出できます。また、インフラストラクチャで実際のデータ パケットをスヌーピングし、ストリームにビデオが含まれていることを認識することもできます。たとえば、プロトコルのヘッダーやデータ自体のエンコード形式(MPEG-4 コーデックなど)に基づいて、Real Time Streaming Protocol(RTSP; リアルタイム ストリーミング プロトコル)や User Datagram Protocol(UDP; ユーザ データグラム プロトコル)ビデオ ストリームを検出できます。

コーデック対応の機能

背景として、最近の多くの(すべてではありませんが)ビデオ圧縮スキームでは、ビデオ ストリームをベース フレーム(基本的に、単一の固定フレーム)と差分フレーム(あるフレームと前のベース フレームの違いをエンコードするフレーム)のセットとしてエンコードする方法を採用しています。この圧縮方法がとても効率的な理由は、ビデオ ストリームはフレーム間であまり変わらない傾向があるためです。想像できるように、ベース フレームは差分フレームよりも重要です。ベース フレームが損失すると、次のベース フレームを受信するまでデコーダは有効なビデオを表示できません。これは何フレームも後になり、障害の時間が長くなる可能性があります。対照的に、差分フレームが損失しても障害は単一のフレームでしか発生しないので、ユーザが気付かないこともあります。

ビデオ コーデック レイヤを理解し、ベース フレームと差分フレームを認識する機能がインフラストラクチャにあれば、多くの点を強化できます。最もわかりやすい強化は、輻輳が発生し、バッファ オーバーランによってアクセス ポイントでパケットをドロップする場合、ベース フレームより先に差分フレームをドロップする方法です。2 番目の強化は、低いデータ レートで送信するか最大再試行回数を増やすことで、ベース フレームの優先度を高くする方法です。この方法で、ベース フレームの受信に成功する確率が高くなります。また、3 番目の強化は、ベース フレームをドロップする必要がある場合(たとえば、パケットの最大再試行回数を超えたためなど)、エラーの伝播を制限するために以降のパケットを記録する方法です。つまり、損失したベース フレーム以降の差分フレームを新しいベース フレームとして記録します。こうすることで、デコーダのエラーは複数のフレームではなく単一のフレームの間だけ継続します。

インフラストラクチャのより高度な機能として、ビデオ エンコーディングの種類を変更する機能(「トランスコーディング」と呼ばれます)があります。たとえば、パケット損失に対する耐性が低い MPEG-2 ストリームをインフラストラクチャで認識できれば、エラー耐性オプションを有効にした H.264 にストリームをトランスコーディングできます。H.264 はパケット損失に対するパフォーマンスに優れています。このアプローチが複雑な点は、クライアント デバイスに関する何らかの情報とサポートできるビデオ フォーマットの種類をインフラストラクチャが把握している必要があることです。

インフラストラクチャによって、データ ストリームのフォーマットは変えずにストリームの解像度またはアップデート レートを変更する方法もあります。これは「トランスレーティング」と呼ばれ、あまり効率的な機能ではありませんが、ワイヤレス インターフェイスの多様な機能に合わせてデータ ストリーム レートを調整するために使用できるため、強力な機能にもなります。つまり、接続速度が低いセル エッジにいるクライアントは場合によっては低品質(低データ レート)のストリームを受信し、アクセス ポイントに近いクライアントは高品質(高データ レート)のストリームを受信できます。これは魅力的な機能ですが、ビデオ ストリームをトランスレーティングする作業には重い負荷がかかる可能性があります。このような場合に利用可能な、Scalable Vector Coding(SVC)と呼ばれる機能を備えたコーデックのクラスがあります。SVC コーデックは、レイヤ内でエンコードが実行されるように設計されているため、適切なパケット(レイヤ)をドロップすることで、ストリームのデータ レートを簡単に変更できます。SVC コーデックが広く使用されるようになれば、Wi-Fi インフラストラクチャで多数のクライアントに対応できるようにトランスレーティングを実装しやすくなります。

もう 1 つの重要なアプリケーション認識機能は、「リップシンク」とも呼ばれるもので、ビデオと音声を個別のストリームとして送信し、エンド ユーザが再生するときに同期する場合に適用されます。前述のように、Wi-Fi WMM には音声トラフィックとビデオ トラフィックに異なる優先度が用意されています。そのため、音声ストリームとビデオ ストリームは同期しない可能性があります。このような場合、Wi-Fi インフラストラクチャで 2 つのストリームを認識し、同期させる機能があると有効です。これを行うには、たとえば音声パケットをビデオ キューに移動するなどして、2 つのストリームを同じ優先度で送信する必要があります。

最後のアプリケーション機能は、Wi-Fi インフラストラクチャでキャッシュを使用してビデオのパフォーマンスを強化する方法です。キャッシュの一例として、Cisco Visual Quality of Experience(VQE)キャッシュを保持する方法があります(VQE はビデオ再送信用のシスコの標準です)。このキャッシュによって、ビデオ パケットを再送信するアプリケーション要求が発行されても、送信元サーバまで戻らずにインフラストラクチャで直接対応できます。キャッシュのもう 1 つの例として、ストリーミング HTTP を使用するビデオをサポートするために、統合的な HTTP キャッシュ機能をインフラストラクチャに持たせる方法があります。この方法で、複数のクライアントが同じユニキャスト ビデオ ストリームをリッスンする場合、最初のクライアント HTTP 要求は送信元サーバに送られますが、2 番目以降の要求はローカル キャッシュを使って対応されます。

このように、Video over Wi-Fi の配信に影響を与える重要な技術要件は多数あります。シスコは、ビジネスで利用される Video over Wi-Fi のエクスペリエンスをさらに強化する新しいテクノロジーを導入することで、こうした要件に対処してきました。

Cisco VideoStream テクノロジーの導入


Cisco VideoStream テクノロジーは、Cisco Unified Wireless Network の新しいシステム全体で使用される機能です。これまでに説明した主要な強化点のいくつかを組み込むことで、高品質のビデオを実現します。Cisco VideoStream にはシスコの RF とビデオの専門知識が結集しており、あらゆる種類のビデオに対応する、信頼性が高く一貫したプラットフォームを実現できます。また、前述したワイヤレス LAN の物理、MAC、およびアプリケーションの各レイヤが考慮されています。ここでは、VideoStream の一部の機能と、Video over Wi-Fi の配信とエンド ユーザのエクスペリエンスを強化する独自の方法について取り上げます。

ストリームのアドミッションと優先順位付け

前述のように、ビデオは効率的で高い効果を得られる通信手段ですが、帯域幅を多く使用します。また、すべてのビデオ コンテンツが同じ優先度とは限りません。上記で説明したように、企業がビジネスにビデオを活用する場合、ビジネスに不可欠なメディアがネットワーク帯域幅を先に使用するように優先順位をつける必要があります。

ストリームのアドミッションを使用すると、ネットワーク管理者は組織内の重要度に基づいてさまざまな優先順位をメディア ストリームに設定できます。また、この機能は無線レベル(2.4 GHz および 5 GHz)と WLAN または SSID レベルで利用できます。管理者は、優先的に QoS を確保するビデオ ストリームを指定できるようになります。たとえば、CEO からの全社向けあいさつは、前夜のスポーツ イベントの再生よりも優先されます(図 2)。

図 2 ストリームの優先順位付け - QoS の優先度がストリームに指定される

図 2 ストリームの優先順位付け - QoS の優先度がストリームに指定される

図 2 ストリームの優先順位付け - QoS の優先度がストリームに指定される
※画像をクリックすると、大きな画面で表示されますpopup_icon


ビデオ ストリームの優先度は、音声よりも低く、ベスト エフォート トラフィックよりも高く設定されます。その他すべてのマルチキャスト トラフィックは、ビデオの QoS の優先度が指定されていても、ベスト エフォート トラフィックとして受け入れられます。

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

Wi-Fi エンドポイントのワークスペースでビデオを利用するユーザは増えていくため、時間や場所に関係なく、分散するユーザ グループに高品質のエクスペリエンスを継続的に提供できるよう、適切に管理し、拡張できることが重要です。Resource Reservation Control(RRC; リソース予約コントロール)には、MAC レイヤの項で説明した強化機能が用意されており、アドミッション コントロールおよびポリシー コントロールを管理できます。アドミッションおよびポリシーの決定は、無線周波数の測定、トラフィックの統計情報、およびシステム設定に基づいて行われます(図 3)。RRC には、加入過多を引き起こす要求を拒否するというビデオ クライアント向け帯域幅保護機能があります。チャネル使用率は、容量を判断し、アドミッション コントロールを実行するメトリックとして使用されます。図 4 は RRC の機能を示しています。

図 3 RRC エンジン

図 3 RRC エンジン

図 3 RRC エンジン
※画像をクリックすると、大きな画面で表示されますpopup_icon


マルチキャストからユニキャストへ

Cisco VideoStream のマルチキャストからユニキャストへの変換機能は、MAC レイヤの項で説明したように、802.11n データ レートを有効にし、パケット エラーを修正できます。その結果、Wi-Fi 上でストリーミング ビデオを配信する信頼性は、従来のワイヤレス ネットワークのベスト エフォート機能よりも向上します。

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

モニタリング

モニタリング機能でチャネルの加入過多に対して RRC イベントのログを記録することで、リソースを効率的に使用できるようになります。ビデオ ストリームを使用できないというユーザ通知は、必要に応じて管理し、効率化します。

クライアント数に関するビデオの拡張性

Video over Wi-Fi にアクセスするクライアント数の増加は、ネットワークに対するプレッシャーと要求の増加にもつながり、パフォーマンスと品質に影響があります。ビデオの拡張性は、有線ネットワークからワイヤレス ネットワークへのトラフィック フローを最適な状態に保ちながら、各コントローラがサポートできるクライアント数で測定されます。Cisco VideoStream テクノロジーを使用すると、すべてのレプリケーションは(アクセス ポイントの)エッジで実行されるため、ネットワーク全体を効率的に使用できます。どの時点でも、ネットワークを通過する設定済みメディア ストリームは 1 つだけです。ビデオ ストリームはクライアントが開始した IGMP 要求に基づいてアクセス ポイントでユニキャストに変換されるためです。他のベンダーでもマルチキャストからユニキャストに変換する同様の処理を行っていますが、ストリームをサポートする有線ネットワークにかかる負荷が高いため、非効率的です。テスト結果の詳細については、『Meircom Competitive Test Report』を参照してください。Wi-Fi ネットワークでビデオ アプリケーションに本当に必要な拡張性を実現するには、ネットワーク全体を理解することが重要です。このエンドツーエンド アプローチは、ビジネス品質のビデオを配信する費用効率がよいソリューションを達成するために重要です。

まとめ


イントラネットからエクストラネット、インターネット、さらには最新のメディアネット(リッチ メディア用に最適化されたインテリジェント ネットワーク)まで、新しい要件に対応するためにネットワークは常に進化を続けてきました。シスコのメディアネット フレームワークはルーティング、スイッチング、セキュリティ、モビリティ、アプリケーション パフォーマンス、およびゲートウェイ の各テクノロジーが連携しているため、あらゆる形式の通信を統合する理想的なエンドツーエンド プラットフォームとして機能します。同時に、信頼性、スケーラビリティ、モビリティ、セキュリティ、および管理可能性が高いメディア リッチ エクスペリエンスを複数のネットワーク、オペレーティング システム、アプリケーション、およびデバイスにわたって実現できます。

シスコのビデオ戦略の背景にある主な原動力の 1 つとして、メディアネットは、広く展開されている Cisco Unified Wireless Network ソリューションと VideoStream テクノロジーの長所に基づいて構築されています。VideoStream テクノロジーはメディアネットによって実現する利点を利用し、ビデオに必要なリッチ サービス機能を発展させています。たとえば、トラフィックの優先順位付け、保護、モニタリング、適応性などです。これらの機能で、拡張性があり高いパフォーマンスで高品質のエンタープライズ ビデオ エクスペリエンスを Wi-Fi で提供できます。

メディアネットは、ネットワーク、メディア、およびエンドポイントに対応しているため、エンド ユーザのエクスペリエンスが向上し、動的に変化するネットワーク条件にも自動的に対応できます。シスコは、既存のネットワークとメディアネット フレームワークを利用する新しい技術に基づき、さらに IT 組織の複雑さを軽減するコラボレーション アプリケーションを実現するという独自の立場を確立しています。