- ナレッジセンター
- 匠コラム
スマートデバイスでのVoIPの難しさ 4.アプリケーションに応じたQoS設計
- 匠コラム
- ネットワーク
ビジネス推進本部 応用技術部
エンタープライズSDNチーム
田中 政満
今回はこれまでの内容のまとめとして、実際にスマートデバイスで音声アプリケーションを利用する際の設計を解説したいと思います。
連載インデックス |
---|
1.はじめに
前回の連載において、スマートデバイスを音声用デバイスとして利用する場合の難しさについて書きましたが、今回はこれまでの内容のまとめとして、実際にスマートデバイスで音声アプリケーションを利用する際の設計を解説したいと思います。
2.アプリケーションに応じた設計
2.1設計を行う場合に考慮するポイント
スマートデバイスで音声通信を利用する場合、以下のような点に注意しながらネットワーク設計を行う必要があります。
●スマートデバイスから送出されるトラフィック種別
第3回で解説した、
・音声トラフィック
・音声以外のトラフィック種別
という複数のトラフィック種別が混在する環境になるため、各トラフィック種別の特性を理解し、音声トラフィックを可能な限り保護できる設計とする必要があります。
●無線LAN区間でのQoSの設計
音声トラフィックが通る伝送媒体のうち、最も帯域が狭く不安定な部分が無線LAN部分であること、および第3回で解説した
・途中の有線LAN区間でリマークは可能
・無線区間のダウンリンクトラフィックのQoS値の制御は可能
であることから、
・無線区間のアップリンクトラフィック
が最も考慮が必要なポイントとなります。
この区間はQoS値を付与できるデバイスがトラフィックの発デバイスのみ、すなわちスマートデバイスのみとなることから、無線LAN区間のアップリンクトラフィックのQoSの動作については、スマートデバイスの作り(=動作仕様)がそのまま現れてきます。
●スマートデバイスのQoSパターン分類
1)スマートデバイスが音声トラフィックにQoS値を付与でき、その値が推奨する値である
2)スマートデバイスが音声トラフィックにQoS値を付与できるが、その値が推奨する値ではない
3)スマートデバイスが音声トラフィックにQoS値を付与できない
スマートデバイスでの音声通信を考える上では、当然1)のような設計が理想ですが、現実には2)の対応となっているものや3)の対応とのどちらかになります。
また利用しようとしているスマートデバイス・OSがどのような対応となるかは事前の検証で確認するしかなく、非常に注意が必要な事項となります。
勿論、有線LAN、無線LANを含めたネットワーク全体のQoSポリシーをどうするかの考慮が必要なのは言うまでもありません。
●デバイス・利用アプリケーションあたりのトラフィック制御
無線LANはシェアードメディアのため、1台の無線LANアクセスポイントに接続しているすべての端末で帯域を共有します。
そのため、特定の端末・アプリケーションが帯域を専有してしまう事を避けるために、端末当たり、アプリケーションあたりのトラフィック量を制限することも検討する必要があります。
しかしながら、無線LANシステム側で制御できるのはダウンリンクトラフィックのみとなるため、端末から多量のアップロードトラフィックが流れているような場合は、この方法では制御が不可能です。MDMとの組み合わせにより、スマートデバイス上で実行できるアプリケーションを制御する方法などもありますが、個人所有のデバイスをBYODとして利用するような環境だと難しいため、利用想定デバイスを会社貸与のものに限定する等の運用上の対策が必要になります。
2.2スマートデバイスが音声トラフィックにQoS値を付加して送出する場合の考慮事項と制限
スマートデバイス・アプリケーションがQoS値を付けて音声トラフィックを送出する動作仕様の場合、無線区間のアップリンクトラフィックを含め、通常のWebアクセス等のトラフィック(802.11e=ベストエフォート(AC_BE)、802.1p=0、DSCP=0のQOS値が付与されているトラフィック)よりは優先されて送出されることが期待できます。
通常、VoWLANの無線区間では
・802.11e=Voice(AC_VO)、DSCP=EF
のQoS値を付けて送出することが推奨とされていますが、広く利用されているiOS/Android OSを搭載したスマートデバイスでは802.11eの値はVoiceではなくVideo(AC_VI)で送出されることを確認しています。(Apple iPhone5s+Cisco Jabberの場合※)
また、これらのOSでは本稿執筆時点(2016/3/31時点)では、802.11eの値をユーザ(管理者)が手動で設定する手段が存在せず、
・アプリケーション側によって設定されるDSCP値に対応して802.11eの値が決定される
という性質を持つことがNetOne社内の検証で判明しています。一例としては、Apple iOSデバイスにおいて、アプリケーション側でDSCP値をEFに設定した場合、802.11eの値がビデオ(AC_VI)として送出されることを確認しています。
この場合でも、802.11eの値は無線LAN区間で音声トラフィックに設定されるべき値であるVoice(AC_VO)ではないため、無線LAN区間のQoSとしては「他のトラフィックよりは優先されるが、適切な設計ではない」状態のため設計ポリシーの検討が必要な状況となります。
●推奨されるべきQOS値とならない場合の設計方針
このような状況の場合、有線LAN区間と無線LAN区間(ダウンリンク)のリマークポリシーとして、以下2つの方法がります。
パターン1)無線LAN区間、無線LAN区間(ダウンリンク)のポリシーを無線LAN区間(アップリンク)と同じ優先度になるようにリマークを行う
パターン2)有線LAN区間、無線LAN区間(ダウンリンク)を音声トラフィックに推奨されるべきQoSの値となるようリマークを行う
パターン1では無線LAN区間(アップリンク)にポリシーを合わせるため、すべての区間でQoSのポリシーは統一されますが、無線区間(アップリンク)のポリシーが推奨より低いため、他に優先度が高いトラフィックがある場合音声トラフィックより優先して処理されることから、音声トラフィックの遅延を招く可能性があります。
パターン2ではリマークされた後は、「無線LANのアップリンクトラフィック以外は」推奨されるべきQoSの値でやり取りされます。しかしながら、無線区間に着目をすると、アップリンクトラフィックとダウンリンクトラフィックのQoSが不一致となるため、混雑時にダウンリンクトラフィックがより優先されてしまう状態となり、片通話などの現象が出る可能性があります。
上記のどちらのパターンを設計として採用するべきなのかは、既にQoSを利用しているアプリケーションの有無により変わります。既にQoSを利用されているアプリーションがある場合、そのアプリケーションが利用しているQoSの値、設計方針と整合性が取れるように行う必要があります。
※検証結果は一例であり、デバイスのハードウェア、OSの種類。バージョン、およびアプリケーションのバージョン等の要因により、結果が異なる場合があります
2.3スマートデバイスがQoS値を付加せず音声トラフィックを送出する場合の考慮事項と制限
2.2.のように、QoS値を付加された音声トラフィックであればまだ対策が可能ですが、QoS値を付加しないような動作仕様の場合、より状況は深刻になります。
音声トラフィックが他のトラフィックと同じ優先度でスマートデバイスから送出されるため、音声トラフィックを保護する手段が存在しません。その結果として、音声パケットの到達性が悪くなり、音声品質の劣化が避けられない状況となります。
また集中制御型無線LANシステムによっては、スマートデバイスの音声トラフィックの保護を謳っている機器は存在しますが、無線LANシステムが介在できる余地があるのはダウンリンクトラフィックのみです。
無線区間のダウンリンクトラフィックに対しては無線LANシステム側で対処が可能な場合がありますが、アップリンクに対してはこれらの機能は動作しないため、注意が必要です。
3.音声トラフィックをスマートデバイスで扱う上でユーザに周知が必要な事項
これまではQoS値の付与や設計ポリシーを述べてきましたが、VoWLANを利用する際に、設計ポリシーと同じレベルで重要なのが、ユーザのVoWLANに対する理解となります。
具体的には以下の2点が、公衆回線網を利用した通話(3G/LTE/PHS回線での通話)と大きく異なるVoWLANの特徴であり、音声品質は公衆回線網を利用した場合より低下するのが一般的です。この点を導入前にユーザに対して説明をしておかないと、導入後に大きなトラブルになります。
●音声品質は公衆回線網を利用した通話と同じではない
音声トラフィックにQoS値がつかない場合や、付いていても推奨されるべき値とは別の値が付いている場合、本来の音声トラフィックより優先度が低い状態であるため、輻輳時にはフレームが遅延・破棄される可能性が存在します。
そのため、無線LANネットワークの混雑度によっては通話が困難な程度まで音声品質が劣化する場合があることを、利用者に対して説明する必要があります。これは無線LANの通信方式からくる宿命であり、避けることのできない現象となります。
●伝送媒体(無線LAN)の特性上、基地局(無線LANアクセスポイント)の切り替え時には通信断が発生する
これはスマートデバイスに限った事項ではありませんが、無線通信を行っている以上、デバイスのローミング(接続している基地局の変更)という問題は避けられません。無線LANではデバイスがローミングしている間、ローミング処理により必ず瞬断以上の無通信時間が発生します。
よって当然ローミング処理中は音声通信も停止し、ローミング時間はデバイスや環境によって大きく異なるため、人によっては通話断を知覚する場合があります。通信をし続けながら基地局を切り替える方式である3G/LTE/PHSとは、動作の仕組みそのものが違いますので、ローミング時の通話断についても利用者に対して説明が必要となります。
まとめ
全4回にわたってスマートデバイスでのVoIPの難しさについて書いてきましたが、スマートデバイスでVoIPを行う際の設計の難しさは、突き詰めていくとQoSのポリシーをどう考えるか、利用者に品質を説明し理解してもらう、という2点に集約されます。
ここの所をうまく設計することが全体の音声品質を左右する要になります。
また利用するユーザに対しての説明も非常に重要な要素となります。既存の公衆回線網とは違う音声通信の形であることをユーザに意識させ、公衆回線網の音声品質よりは確実に低下するという点をユーザに意識させることが重要です。
そしてこれらの音声品質の低下要因をユーザが許容できない場合、取りうる道は一つしかなく、VoIPの撤廃、FMCへの移行以外にはありません。
執筆者プロフィール
田中 政満
ネットワンシステムズ株式会社 ビジネス推進本部
応用技術部 エンタープライズSDNチーム
所属
入社以来無線LANの製品担当SEとして製品や技術の調査、検証評価、及び、提案や導入を支援する業務に従事。
現在はキャンパスセキュリティや自動化に力を入れるなど、エンタープライズSDNのエンジニアとして邁進中。
- 第1回 シスコ テクノロジー論文コンテスト 最優秀賞
Webからのお問い合わせはこちらから
ナレッジセンターを検索する
カテゴリーで検索
タグで検索