Loading article…
サービス品質（QoS ）とは、電話やコンピュータネットワーク、クラウドコンピューティングサービスなどのサービスの全体的なパフォーマンス、特にネットワークのユーザーが感じるパフォーマンスを記述または測定したものです。サービス品質を定量的に測定するために、パケット損失、ビットレート、スループット、伝送遅延、可用性、ジッターなど、ネットワークサービスのいくつかの関連側面が考慮されることがよくあります。
コンピュータネットワークやその他のパケット交換通信ネットワークの分野では、サービス品質とは、達成されるサービス品質ではなく、トラフィックの優先順位付けやリソース予約制御メカニズムを指します。サービス品質とは、異なるアプリケーション、ユーザー、またはデータフローに対して異なる優先順位を提供したり、データフローに対して一定レベルのパフォーマンスを保証したりする能力のことです。
サービス品質は、 VoIPやその他のオーディオネットワーク技術、プロフェッショナルビデオオーバーIP、カードベースの決済[ 1 ]、リアルタイムコンピューティングなど、特別な要件を持つトラフィックの伝送にとって特に重要です。
電話通信の分野では、サービス品質は1994 年にITUによって定義されました。 [ 2 ]サービス品質は、サービス応答時間、損失、信号対雑音比、クロストーク、エコー、割り込み、周波数応答、音量レベルなど、接続のあらゆる側面に関する要件を含みます。電話通信の QoS のサブセットとして、サービス等級(GoS) 要件があり、これは、ネットワークの容量とカバレッジに関連する接続の側面を含みます。たとえば、保証された最大ブロッキング確率と停止確率などです。[ 3 ]
コンピュータネットワークやその他のパケット交換通信ネットワークの分野では、テレトラフィックエンジニアリングとは、達成されるサービス品質ではなく、トラフィックの優先順位付けとリソース予約制御メカニズムを指します。サービス品質とは、異なるアプリケーション、ユーザー、またはデータフローに異なる優先順位を提供したり、データフローに対して一定レベルのパフォーマンスを保証したりする能力のことです。たとえば、必要なビットレート、遅延、遅延変動、パケット損失、またはビットエラー率が保証される場合があります。サービス品質は、VoIP、マルチプレイヤーオンラインゲーム、IPTVなどのリアルタイムストリーミングマルチメディアアプリケーションにとって重要です。これらのアプリケーションは、多くの場合、固定ビットレートを必要とし、遅延に敏感だからです。サービス品質は、容量が限られたリソースであるネットワーク、たとえばセルラーデータ通信において特に重要です。
QoSをサポートするネットワークまたはプロトコルは、アプリケーションソフトウェアとトラフィック契約を締結し、例えばセッション確立フェーズ中にネットワークノードの容量を予約することができます。セッション中は、データレートや遅延などの達成されたパフォーマンスレベルを監視し、ネットワークノードのスケジューリング優先順位を動的に制御することができます。セッション終了フェーズでは、予約した容量を解放することができます。
ベストエフォート型のネットワークやサービスでは、サービス品質（QoS）はサポートされません。複雑なQoS制御メカニズムに代わる方法として、ベストエフォート型ネットワーク上で高品質な通信を実現するには、想定されるピーク時のトラフィック負荷に十分な容量を確保することで、ネットワークの混雑を回避し、QoSメカニズムの必要性を軽減または排除する方法があります。
QoSは、リソースを予約する能力を指すのではなく、品質の尺度として使用されることもあり、多くの代替定義があります。サービス品質は、サービス品質のレベル、つまり保証されたサービス品質を指すことがあります。[ 4 ]高いQoSは、高いビットレート、低いレイテンシ、低いビットエラー率などの高いレベルのパフォーマンスと混同されることがよくあります。
QoSは、電話やストリーミングビデオなどのアプリケーション層サービスにおいて、主観的に体験される品質を反映または予測する指標を表すために用いられることがあります。この文脈において、QoSとは、サービスに影響を与えるあらゆる不具合が加入者の満足度に及ぼす許容可能な累積効果を指します。同様の意味を持つ用語としては、体験品質（QoE）、平均意見スコア（MOS）、知覚音声品質測定（PSQM） 、知覚ビデオ品質評価（PEVQ）などがあります。
過去には、データにQoSタグを追加するレイヤ2技術が数多く開発され、人気を博しました。例えば、フレームリレー、非同期転送モード（ATM）、マルチプロトコルラベルスイッチング（MPLS）（レイヤ2とレイヤ3の中間技術）などが挙げられます。これらのネットワーク技術は現在も使用されていますが、イーサネットネットワークの登場以降、注目度は低下しました。現在、レイヤ2技術としてはイーサネットが圧倒的に普及しています。従来のインターネットルーターやネットワークスイッチは、ベストエフォート方式で動作します。これらの機器は、QoSメカニズムを提供する以前の複雑な技術よりも安価で、構造も単純で、高速であるため、より広く普及しています。
イーサネットは、オプションとして802.1pを使用してフレームの優先度を通知します。
当初、各IPパケットヘッダーには4種類のサービスビットと3種類の優先順位ビットが用意されていましたが、これらは一般的に尊重されていませんでした。これらのビットは後に、差別化サービスコードポイント（DSCP）として再定義されました。
IPTVやIP電話の登場により、QoS（サービス品質）メカニズムはエンドユーザーにとってますます利用しやすくなっている。
パケット交換ネットワークでは、サービス品質はさまざまな要因によって影響を受け、それらは人的要因と技術的要因に分類できます。人的要因には、サービス品質の安定性、サービスの可用性、待ち時間、ユーザー情報などが含まれます。技術的要因には、信頼性、拡張性、有効性、保守性、ネットワークの混雑などが含まれます。[ 5 ]
パケットが送信元から宛先へ移動する過程で、様々な事象が発生する可能性があり、送信側と受信側の視点から見ると、以下のような問題が生じる。
同じネットワークリソースを共有する様々なユーザーからの負荷が変動するため、特定のデータストリームに提供できる最大スループットは、リアルタイムマルチメディアサービスには低すぎる可能性があります。
ネットワークの混雑により、一部のパケットが配信されない（破棄される）場合があります。受信側のアプリケーションは、この情報の再送信を要求する可能性があり、その結果、ネットワークの混雑による崩壊や、全体の送信における許容できない遅延が発生する可能性があります。
ノイズや干渉、特に無線通信や長距離銅線通信では、ビットエラーによってパケットが破損することがあります。受信側はこれを検知し、パケットが破棄された場合と同様に、情報の再送信を要求する場合があります。
パケットが長いキューに滞留したり、混雑を避けるために遠回りな経路を通ったりすると、各パケットが宛先に到達するまでに時間がかかる場合があります。場合によっては、過度の遅延によってVoIPやオンラインゲームなどのアプリケーションが使用不能になることもあります。
送信元からのパケットは、宛先に到達するまでにそれぞれ異なる遅延を伴います。パケットの遅延は、送信元と宛先間の経路上のルーターのキューにおけるパケットの位置によって変化し、この位置は予測不可能に変動する可能性があります。遅延の変動は受信側で吸収できますが、その分ストリーム全体の遅延が増加します。
関連するパケットの集合がネットワークを通過する際、パケットごとに異なる経路をたどる可能性があり、その結果、遅延時間も異なります。そのため、パケットは送信時とは異なる順序で到着します。この問題に対処するには、順不同になったパケットを並べ替えるための特別な追加プロトコルが必要です。この並べ替え処理には受信側で追加のバッファリングが必要となり、パケット遅延の変動と同様に、ストリーム全体の遅延時間を増加させます。
特定の種類のネットワークトラフィックに対しては、定義されたサービス品質が望ましい、あるいは必要とされる場合がある。例えば、以下のような場合である。
こうしたサービスは非弾性型と呼ばれ、機能するには一定の最小ビットレートと一定の最大遅延時間が必要となります。一方、弾性型アプリケーションは、利用可能な帯域幅の大小に関わらず、柔軟に対応できます。TCPを使用する大量ファイル転送アプリケーションは、一般的に弾性型です。
回線交換ネットワーク、特にATMやGSMなどの音声伝送を目的としたネットワークでは、コアプロトコルにQoS（サービス品質）が組み込まれています。ネットワーク上の各ステップで通話確立時にリソースが確保されるため、必要なパフォーマンスを実現するための追加手順は不要です。短いデータ単位と組み込みのQoSは、ビデオオンデマンドなどのアプリケーションにおけるATMの独自のセールスポイントの一つでした。
QoSを提供するための仕組みにかかる費用が正当化される場合、ネットワークの顧客とプロバイダーは、相互に合意した基準に基づいて、スループットまたは遅延に関して保証されたパフォーマンスを提供できる接続能力を保証するサービスレベル契約（SLA）と呼ばれる契約を締結することができる。
複雑なQoS制御メカニズムに代わる方法として、ピーク時のトラフィック負荷予測に基づいてネットワーク容量を過剰に確保することで、高品質な通信を実現する方法があります。この方法は、ピーク負荷が予測可能なネットワークでは簡単です。ただし、帯域幅や遅延の変動を大きな受信バッファで補償できる要求の厳しいアプリケーションを考慮する必要がある場合もあります。これは、例えばビデオストリーミングなどではしばしば可能です。
トランスポートプロトコル（ TCPなど）は、時間の経過とともにネットワーク上に送信されるデータ量を増加させ、最終的に利用可能な帯域幅をすべて消費してパケットを破棄してしまうため、過剰な帯域幅の確保は限定的な効果しか発揮しない場合があります。このような貪欲なプロトコルは、すべてのユーザーのレイテンシとパケット損失を増加させる傾向があります。
QoSを代替するために必要な内部リンクの過剰プロビジョニングの量は、ユーザー数とそのトラフィック需要によって異なります。このため、過剰プロビジョニングの実用性は制限されます。より帯域幅を多く消費する新しいアプリケーションやユーザー数の増加は、過剰プロビジョニングされたネットワークの損失につながります。そうなると、関連するネットワークリンクの物理的な更新が必要となり、これはコストのかかるプロセスです。したがって、インターネット上で過剰プロビジョニングを安易に想定することはできません。
商用VoIPサービスは、ユーザーのISPへの接続とVoIPプロバイダの別のISPへの接続でQoSメカニズムが使用されていなくても、通話品質の点で従来の電話サービスと競争力があることが多い。しかし、高負荷状態では、VoIPは携帯電話の品質以下に低下する可能性がある。パケットトラフィックの数学によれば、保守的な仮定の下では、ネットワークにはわずか60%多くの生容量が必要であることが示されている。[ 6 ]
単一所有者のネットワークとは異なり、インターネットはプライベートネットワークを相互接続する一連の交換ポイントです。[ 7 ]そのため、インターネットの中核は単一の組織ではなく、多数の異なるネットワークサービスプロバイダーによって所有および管理されています。その動作ははるかに予測不可能です。
現代のパケット交換型IPネットワークにおけるQoSには、主に2つのアプローチがあります。1つは、アプリケーション要件をネットワークと交換することに基づくパラメータ化システム、もう1つは、各パケットがネットワークに対して希望するサービスレベルを識別する優先順位付けシステムです。
初期の研究では、ネットワーク リソースを予約する統合サービス (IntServ) の理念が採用されていました。このモデルでは、アプリケーションは RSVP を使用してネットワークを介してリソースを要求および予約します。IntServ メカニズムは機能しますが、大規模なサービス プロバイダに典型的なブロードバンド ネットワークでは、コア ルータが数千、場合によっては数万の予約を受け入れ、維持し、破棄する必要があることが認識されました。このアプローチはインターネットの成長に合わせて拡張できないと考えられており、[ 8 ]いずれにしても、コア ルータが可能な限り最高の速度でパケットを交換することだけを行うようにネットワークを設計するというエンド ツー エンドの原則に反していました。
DiffServでは、パケットはトラフィックの送信元自身、またはトラフィックがネットワークに入るエッジデバイスによってマーキングされます。これらのマーキングに応じて、ルータとスイッチはさまざまなキューイング戦略を使用して、要件に合わせてパフォーマンスを調整します。IPレイヤでは、DSCPマーキングはIPパケットヘッダーの6ビットDSフィールドを使用します。MACレイヤでは、VLAN IEEE 802.1Qを使用して、実質的に同じ情報を3ビット伝送できます。DiffServをサポートするルータとスイッチは、帯域幅が制限された（広域）インターフェイスからの送信を待つパケット用に複数のキューを使用するようにネットワークスケジューラを設定します。ルータベンダーは、サポートされるキューの数、キューの相対的な優先順位、各キューに予約される帯域幅など、この動作を設定するためのさまざまな機能を提供します。
実際には、キューイング機能を持つインターフェースからパケットを転送する必要がある場合、ジッターの少ないパケット（VoIPやビデオ会議など）が他のキューのパケットよりも優先されます。通常、ネットワーク制御パケット（インターネット制御メッセージプロトコルやルーティングプロトコルなど）にはデフォルトで一定の帯域幅が割り当てられ、ベストエフォート型のトラフィックには残りの帯域幅が割り当てられます。
メディアアクセス制御（MAC）レイヤでは、 VLAN IEEE 802.1QとIEEE 802.1pを使用してイーサネットフレームを区別し、分類することができます。MACレイヤプロトコルのパフォーマンス分析とQoSについては、キューイング理論モデルが開発されています。[ 9 ] [ 10 ]
Cisco IOS NetFlowとCisco Class Based QoS (CBQoS)管理情報ベース(MIB)はCisco Systemsによって販売されています。 [ 11 ]
インターネットにおけるQoSの必要性を示す説得力のある例の一つは、輻輳崩壊に関するものです。インターネットは、輻輳崩壊につながるような状況下でトラフィックを削減するために、主に伝送制御プロトコル（TCP）に組み込まれた輻輳回避プロトコルに依存しています。VoIPやIPTVなどのQoSアプリケーションは、ほぼ一定のビットレートと低遅延を必要とするため、TCPを使用できず、輻輳を防ぐためにトラフィックレートを削減することもできません。サービスレベル契約は、インターネットに提供できるトラフィックを制限し、それによって過負荷を防ぐトラフィックシェーピングを強制するため、リアルタイムトラフィックと非リアルタイムトラフィックが混在する環境を崩壊することなく処理するインターネットの能力にとって不可欠な要素となっています。
IPネットワークには、いくつかのQoS（サービス品質）メカニズムと方式が存在する。
QoS機能は、以下のネットワーク技術で利用可能です。
エンドツーエンドのサービス品質を実現するには、自律システム間でリソース割り当てを調整する方法が必要になる場合があります。インターネット技術タスクフォース(IETF) は、 1997 年に帯域幅予約のためのリソース予約プロトコル(RSVP) を提案標準として定義しました。 [ 13 ] RSVP は、エンドツーエンドの帯域幅予約およびアクセス制御プロトコルです。RSVP は拡張性の制限により広く採用されませんでした。[ 14 ]より拡張性の高いトラフィックエンジニアリング版であるRSVP-TEは、トラフィックエンジニアリングされたマルチプロトコルラベルスイッチング(MPLS) ラベルスイッチパスを確立するために多くのネットワークで使用されています。[ 15 ] IETF はまた、 QoS シグナリングをターゲットとしたNext Steps in Signaling (NSIS) [ 16 ]も定義しました。NSIS は RSVP の開発と簡素化です。
「異種ネットワークにおけるエンドツーエンドのサービス品質サポート」（EuQoS、2004年から2007年）[ 17 ]などの研究コンソーシアムや、 IPsphere Forum [ 18 ]などのフォーラムは、QoS呼び出しをあるドメインから次のドメインへハンドシェイクするためのメカニズムをさらに開発しました。IPsphereは、ネットワークサービスを確立、呼び出し、保証するために、サービス構造化ストラタム（SSS）シグナリングバスを定義しました。EuQoSは、セッション開始プロトコル、Next Steps in Signaling、およびIPsphereのSSSを統合するための実験を約1560万ユーロの費用で実施し、書籍を出版しました。[ 19 ] [ 20 ]
研究プロジェクト Multi Service Access Everywhere (MUSE) は、2004 年 1 月から 2006 年 2 月までの第 1 フェーズと 2006 年 1 月から 2007 年までの第 2 フェーズで、別の QoS コンセプトを定義しました。[ 21 ] [ 22 ] [ 23 ] PlaNetS という別の研究プロジェクトは、2005 年頃に欧州の資金提供のために提案されました。[ 24 ] 4WARD として知られる「将来のインターネットのアーキテクチャと設計」と呼ばれるより広範な欧州プロジェクトは、2340 万ユーロの予算が見積もられ、2008 年 1 月から 2010 年 6 月まで資金提供されました。[ 25 ] このプロジェクトには「サービス品質のテーマ」が含まれており、書籍が出版されました。[ 26 ] [ 27 ] WIDENS (Wireless Deployable Network System) と呼ばれる別の欧州プロジェクトは、モバイル無線マルチレート アドホック ネットワークの帯域幅予約アプローチを提案しました。[ 28 ] [ 29 ]
Secure Sockets Layer、I2P、仮想プライベートネットワークなどの強力な暗号化ネットワークプロトコルは、それらを使用して転送されるデータを秘匿します。インターネット上のすべての電子商取引はこのような強力な暗号化プロトコルの使用を必要とするため、暗号化されたトラフィックのパフォーマンスを一方的に低下させることは、顧客にとって容認できない危険を生み出します。しかし、暗号化されたトラフィックは、 QoSのためのディープパケットインスペクションを受けることができません。
ICAやRDPのようなプロトコルは、さまざまな要件を持つ他のトラフィック（印刷、ビデオストリーミングなど）をカプセル化することがあり、最適化を困難にする可能性がある。
Internet2プロジェクトは2001年に、当時の機器ではアビリーンネットワーク内でQoSプロトコルを展開することは恐らく不可能であると結論付けた。 [ 30 ] [ a ]同グループは、 QoSを目的としたプロトコル変更による帯域幅保証は「物流、財務、組織上の障壁によって阻まれる」と予測した。[ 31 ] 彼らは、経済的な観点から、ネットワークプロバイダーが顧客をより高価なQoSサービスに誘導するために、ベストエフォートトラフィックの品質を意図的に低下させるだろうと考えた。その代わりに、当時としては容量の過剰供給の方が費用対効果が高いと提案した。[ 30 ] [ 31 ]
アビリーン・ネットワークの研究は、 2006年初頭に米国上院商業委員会のネットワーク中立性に関する公聴会でゲイリー・バチュラが行った証言の基礎となった。彼は、帯域幅を増やすことは、検討したQoSを実現するためのさまざまなスキームよりも効果的であるという意見を表明した。[ 32 ]バチュラの証言は、サービス品質を禁止する法律の支持者によって、そのような提供には正当な目的がないという証拠として引用されている。この議論は、過剰プロビジョニングがQoSの一形態ではなく、常に可能であるという前提に基づいている。コストやその他の要因は、通信事業者が恒久的に過剰プロビジョニングされたネットワークを構築および維持する能力に影響を与える。
携帯電話サービスプロバイダーは、有線公衆交換電話網サービスプロバイダーやインターネットサービスプロバイダーがQoSを提供するのと同様に、顧客にモバイルQoSを提供する場合があります。QoSメカニズムは回線交換サービスでは常に提供されており、ストリーミングマルチメディアなどの非弾力的なサービスにとって不可欠です。
モビリティはQoSメカニズムを複雑化させる。新しい基地局が過負荷状態になると、ハンドオーバー後に通話やその他のセッションが中断される可能性がある。予測不可能なハンドオーバーにより、セッション開始フェーズ中に絶対的なQoS保証を提供することは不可能となる。
電話分野におけるサービス品質は、 1994年にITU-T勧告E.800で初めて定義されました。この定義は非常に広範で、サポート、操作性、アクセス性、保持性、完全性、セキュリティの6つの主要コンポーネントが挙げられています。[ 2 ] 1998年にITUは、データネットワーク分野におけるQoSについて議論した文書を公開しました。X.641は、QoSに関連する標準を開発または強化する手段を提供し、関連する標準の一貫性を維持するのに役立つ概念と用語を提供します。[ 33 ]
QoS関連のIETFリクエスト・フォー・コメント（RFC）には、Baker, Fred; Black, David L.; Nichols, Kathleen; Blake, Steven L. (1998年12月)、「IPv4およびIPv6ヘッダーにおける差別化サービスフィールド（DSフィールド）の定義」、doi : 10.17487/RFC2474、RFC 2474などがあります。 、およびBraden, Robert T.、Zhang, Lixia、Berson, Steven、Herzog, Shai、Jamin, Sugih (1997 年 9 月)、Braden, R. (編)、Resource ReSerVation Protocol (RSVP)、doi : 10.17487/RFC2205、RFC 2205 これら両方については上記で説明しました。IETFはQoSに関する背景情報を提供する2つのRFCも公開しています。Huston , Geoff (2000年11月)、「IP QoSアーキテクチャの次のステップ」、doi : 10.17487/RFC2990、RFC 2990 、およびFloyd, S.、Kempf, J. (2004)、Kempf, J. (編)、インターネットにおける音声トラフィックの輻輳制御に関する IAB の懸念、doi : 10.17487/RFC3714、RFC 3714 。
IETFはまた、Baker, Fred; Babiarz, Jozef; Chan, Kwok Ho (2006年8月)、「DiffServサービスクラスの構成ガイドライン」、doi : 10.17487/RFC4594、RFC 4594を公開している。 この文書は、 DiffServネットワーク向けQoSソリューションの設計における実践的な側面について、情報提供やベストプラクティスを示す資料として作成されました。IPネットワーク上で一般的に実行されるアプリケーションを特定し、トラフィッククラスに分類し、これらのクラスに対してネットワーク側で必要とされる処理を検討し、ルーターで一般的に利用可能なQoSメカニズムのうち、どのメカニズムを使用してこれらの処理を実装できるかを提案しています。
経路に沿ってフローベースのリソース予約を設定するには膨大な労力が必要となる。さらに、ルーターにおける制御信号の送受信や状態管理が必要となるため、このアプローチの拡張性は制限される。
{{citation}}: CS1 maint: 複数の名前: 著者リスト (リンク)