支社のある月曜日の朝を想像してください。経理チームは月末レポートをアップロードしており、ソフトウェア展開が全ワークステーションにパッチを配布しており、奥では誰かが誰もスケジュールしていないクラウドバックアップを開始しています。その一方で、営業部長は顧客と通話中です。どのパケットが最も重要かをネットワークに伝える手段がなければ、その通話はすべてのバックグラウンド転送と対等に競合することになり、通話者は途切れ、ロボットのような音節、そして気まずい遅延を聞き始めます。
これこそ、QoS 優先度マーキングが解決するために作られた問題です。これは、スイッチ、ルーター、ファイアウォール、ワイヤレスコントローラーが、リソースが逼迫したときにどのトラフィックがより高速で予測可能な転送に値するかを認識できるように、パケットにラベルを付ける方法です。音声ネットワークでは、通常、リアルタイム音声と通話制御メッセージをバルク転送から分離し、タイミングに敏感なパケットが大きなファイルダウンロードの後ろに滞留しないようにすることを意味します。
これが重要である理由は、ひとつの単純な事実に帰着します。音声品質は帯域幅だけでなく、タイミングによって左右されます。電話通話は、誰にも気づかれない程度の少量のパケット損失には耐えられます。しかし、レイテンシが上昇したり、ジッターが不安定になったり、パケットが再生するには遅すぎるタイミングで到着したりすると、会話は崩壊します。QoS マーキングは、ネットワーク機器に、それらの時間的に重要なパケットを動かし続けるために必要な信号を提供します。
最初に言っておくべきことは、マーキングだけでは完全な解決策ではないということです。適切に設計された音声ネットワークには、依然として十分な帯域幅、安定したスイッチング、適切な VLAN 構成、理にかなった信頼境界、そして適切なキューイングポリシーが必要です。マーキングが行うのは、それらの他のメカニズムが依存する情報を提供することです。スーツケースの荷物タグのようなものだと考えてください。タグが荷物を運ぶわけではありませんが、航空会社に荷物の行き先と緊急度を伝えます。
ネットワークが混雑すると音声通話が途切れる理由
音声パケットには独自の性格があります。小さく、一定のリズムで到着し、遅延に対して非常に寛容ではありません。大きなソフトウェアダウンロードははるかに多くの帯域幅を消費するかもしれませんが、数百ミリ秒一時停止しても、誰も気にせずに再開できます。音声はそうはいきません。あまりにも多くの音声パケットがキューに留まると、聞き手は途切れた音声、文の間の長い間、または人々がすぐに悪い通話と認識するあの特徴的な水中のような歪みを聞くことになります。
これが、企業設計において音声メディアトラフィックがほぼ常に一般的なアプリケーショントラフィックから分離される理由です。RTP で運ばれる実際の音声メディアは高い優先度のマーカーを受け取り、通話シグナリングは別の、しかし同様に保護されたクラスを受け取ります。ネットワークはそれにより、会話を円滑に流し続けると同時に、通話の設定、登録、終了メッセージが確実に到着することを保証できます。
多くのチームが驚くのは、音声が実際に使用する帯域幅がいかに少ないかということです。単一の G.711 通話は、オーバーヘッドを含めておよそ 80～100 kbps を消費します。問題は量ではなく、タイミングです。ギガビットリンクであっても、数メガビットのバースト的なトラフィックが、通話を劣化させるのに十分なキューイング遅延をもたらす可能性があります。音声パケットは、生のスループットではなく、一貫した低レイテンシの転送を必要とするからです。
QoS 優先度マーキングがリアルタイム音声を保護する方法
QoS は、あたかも押すボタンがひとつあるかのように説明されることがよくありますが、実際には一連の決定です。まず、トラフィックが識別・分類されます。これは音声メディアか、シグナリングか、それとも別のものか。次に、優先度値でマークされます。その後に初めて、下流のデバイスは、それを優先キューに入れるか、シェーピングするか、ポリシングするか、輻輳時に保護するかを決定できます。
このチェーンが重要なのは、誰にも尊重されないマーキングは、ほこりをかぶったラベルにすぎないからです。電話で正しくタグ付けされたパケットが、次のスイッチで無視されれば、ほとんど何も得られません。逆に、そのマーキングを一貫して信頼し、それに基づいて行動するネットワークを通過する、適切にマークされたパケットは、エンドツーエンドで劇的に優れた処理を受けることができます。価値はチェーンにあり、個々のリンクにはありません。
レイヤー 3 では、最も一般的なメカニズムは DSCP（Differentiated Services Code Point）で、IP ヘッダーで運ばれます。音声メディアの場合、標準的な推奨は EF（Expedited Forwarding）で、これは DSCP 値 46 に対応します。EF 自体が帯域幅を予約するわけではなく、トラフィックが低遅延・低ジッターの処理を受けるべきであることを示します。ポリシーが正しく設定されている場合、EF パケットは低レイテンシキューまたは厳密優先スケジューリングに送られ、輻輳したリンクを最小限の妨害で通過できます。
レイヤー 2 では、スイッチドイーサネットドメイン内で、802.1Q タグの Class of Service 値を使用してトラフィックをマークすることもできます。これはしばしば 802.1p 優先度マーキングと呼ばれます。多くの IP テレフォニー環境では、音声トラフィックはアクセスレイヤーで CoS 5 に関連付けられます。これにより、ルーティングの決定が下される前に、スイッチに即時の信号が与えられます。アクセススイッチはその後、そのマーキングを保持するか、DSCP 値に変換するか、キャンパスまたは WAN ポリシーに従って書き換えることができます。
デバイスが着信マーキングを受け入れるか上書きするかを決定するポイントは信頼境界と呼ばれ、音声 QoS 設計において最も重要な決定のひとつです。すべてのエンドポイントが自分のパケットをミッションクリティカルだと宣言できるようにすべきではありません。どのノート PC も自分のクラウド同期を最優先にマークできれば、分類システム全体が崩壊します。音声展開では、ネットワークは通常、既知の IP 電話からのマーキングを信頼し、その背後に接続された PC にはより厳格なルールを適用します。スイッチは多くの場合、CDP または LLDP-MED を使用して電話ポートを識別し、その音声マーキングを信頼し、ワークステーショントラフィックを個別に分類します。
マーキングが最も大きな違いを生む場所
最も馴染み深いのは、企業の IP 電話環境です。デスク電話は音声およびシグナリングトラフィックをマークし、キャンパススイッチとルーテッドアップリンクはそれらのマーキングを尊重することが期待されます。このユースケースは、通話フローが予測可能で、通話品質に対するビジネス上の期待が高いため、よく理解されています。IP PBX プラットフォーム、SIP サーバー、音声ゲートウェイは、ネットワークがトラフィックを一貫して扱うとき、すべてより良く機能します。
見落とされがちなのは、電話が正しくマークすることが最初のステップにすぎないということです。アクセススイッチは、その利点をデスクポートを越えて維持するために、正しい信頼状態、VLAN 設定、キューイングポリシー、アップリンク動作を依然として必要とします。電話は完璧にマークされたパケットを送信できますが、スイッチポートがそれらを無視するように設定されていれば、その努力は無駄になります。
音声がローカル LAN を離れると、マーキングはさらに重要になります。ブランチルーターは、データセンター、ホスト型 IP PBX プラットフォーム、または SIP トランクプロバイダーに向けて、マークされたメディアを分類して保持します。輻輳が例外ではなく日常的なものである低速な WAN リンクでは、トラフィックが明確に定義されたクラスで到着するとき、キューイングおよびシェーピングポリシーははるかにうまく機能します。正しいマーキングにより、音声はクラウドバックアップ、ソフトウェア配布、ビデオストリーム、通常のビジネスアプリケーションフローと公平に競争できます。
デスク電話以外にも、同じ原則が SIP ページングシステム、IP インターホン端末、緊急ヘルプポイント、産業用電話、指令コンソールに適用されます。これらのシステムは常時トラフィックを運ばないかもしれませんが、起動されると、音声パスはしばしば即時かつ明瞭な配信を必要とします。交通ハブ、学校キャンパス、産業プラント、医療施設、公共安全環境では、遅延または歪んで届くページングアナウンスや緊急通話は、単なる不便を超えて、調整、安全、対応速度に影響を与える可能性があります。
QoS を損なうよくある間違い
最も頻繁な誤りは、パケットを EF または CoS 5 にマークすれば問題が解決すると想定することです。それは違います。マーキングは信頼され、保持され、正しいキューにマッピングされなければなりません。アップリンクがオーバーサブスクライブされ、低レイテンシキューが存在しない場合、タグは本質的に装飾です。適切な音声最適化は、マーキングとキューイング、スケジューリング、キャパシティプランニング、継続的な検証を組み合わせます。マーキングはプロセスの始まりであり、ゴールラインではありません。
第二の落とし穴は、境界でマーキングに何が起こるかを追跡しないことです。トラフィック動作は、ルーティングエッジ、WAN ハンドオフ、ファイアウォール、SD-WAN オーバーレイ、Wi-Fi コントローラー、クラウド接続でしばしば変化します。DSCP を忠実に保持するデバイスもあれば、書き換えるデバイス、明示的に設定しない限り削除または無視するデバイスもあります。音声フローは、電話から正しくマークされて出て、WAN に予想よりも弱いクラスで到着する可能性があります。これが、エンドツーエンドの検証が重要である理由です。チームは、電話が何を送信するかだけでなく、アクセススイッチが何を信頼し、ルーターが何をキューに入れ、サービスプロバイダーが実際に何を尊重するかを検証する必要があります。
第三のよくある間違いは、過剰なマーキングです。メディア、シグナリング、ビデオ、管理、バックアップ、アプリケーション同期がすべてプレミアム優先度でラベル付けされると、優先キューは意味を失います。過剰なマーキングは、ポリシーが保護しようとしたトラフィック自体を実際に害する可能性があります。なぜなら、高優先度キューがそれを必要としないトラフィックで輻輳するからです。規律ある QoS 設計は、真に低遅延・低ジッターに依存するトラフィックのために最上位の処理を確保し、その他すべてをビジネス価値と技術的感度に基づいて適切なクラスに割り当てます。
よくある質問
QoS マーキングは、完全に飽和したリンクで音声品質を改善できますか？
マーキングは、利用可能なキャパシティ内で優先順位を付けるのに役立ちますが、存在しない帯域幅を作り出すことはできません。完全に飽和したリンクでは、提供される総負荷がリンク容量を超えると、EF マーク付きの音声でさえ最終的に劣化します。QoS は、音声が他のトラフィックによって遅延するのを防ぐときに最も効果を発揮します。それ自体で基本的なキャパシティ不足を克服することはできません。
ワイヤレスアクセスポイントは、有線スイッチと同じように DSCP マーキングを尊重しますか？
必ずしもそうとは限りません。Wi-Fi は WMM と呼ばれる独自の QoS メカニズムを使用し、DSCP 値をアクセスカテゴリ（音声、ビデオ、ベストエフォート、バックグラウンド）にマッピングします。マッピングは常に 1 対 1 ではなく、一部のアクセスポイントやコントローラーは、別途設定されない限りトラフィックを再分類する場合があります。Wi-Fi で音声を展開するチームは、有線ネットワークを反映していると想定するのではなく、コントローラーレベルで DSCP から WMM へのマッピングを検証する必要があります。
マーキングがエンドツーエンドで保持されていることをどのように検証しますか？
最も信頼性の高い方法は、パスに沿った複数のポイント（電話、アクセススイッチの後、ルーター出口、可能であれば WAN ハンドオフ）でパケットキャプチャを取得することです。各キャプチャの DSCP 値を比較すると、再マーキングまたは削除がどこで発生するかが明らかになります。多くのベンダーは、各クラスに一致したトラフィック量を示す QoS ポリシーヒットカウンターやインターフェイス統計も提供しており、キャプチャが示す内容を裏付けることができます。
ビデオ会議トラフィックは音声と同じマーキングを使用すべきですか？
一般的には、いいえ。ビデオもリアルタイムですが、音声と比較して異なる特性（より大きなパケット、可変ビットレート、時折の遅延に対するより高い耐性）を持っています。ほとんどの企業モデルは、ビデオを音声と同じ EF キューではなく、別のクラス（多くの場合 AF41 または類似）に配置します。高ビットレートのビデオを音声と同じ厳密優先キューに混在させると、ビデオバーストが音声パケットから保証された低レイテンシ処理を奪う可能性があります。
同じネットワークパス上で 2 つの QoS ポリシーが競合するとどうなりますか？
競合するポリシーは通常、一貫性のない動作を生み出します。あるデバイスはマーキングを保持し、次のデバイスはそれを書き換えるかもしれません。あるいは、キューがあるリンクでは帯域幅の 30 パーセント、別のリンクでは 10 パーセントに設定されるかもしれません。結果はしばしば微妙です。通話は機能しますが、トラフィックがたどるパスに応じて品質が変動します。競合を解決するには、意図したポリシーをエンドツーエンドで文書化し、各デバイスの実際の設定をそのベースラインと照合して監査する必要があり、デバイスを個別にチェックするだけでは不十分です。
