Ethernet TSN の QoS（8）全体動作検証

Ethernet TSN は、制御データを確実に伝送する「CDT 専用時間帯」と、プロトコル制御データ(gPTP、SRP 等)、映像ストリームやファイルなどの Best Effort データを伝送する「その他時間帯」に分割している(図1)。制御データを伝送する「CDT 専用時間帯」と「その他時間帯」を一定サイクルで繰り返すことで、性質の異なる2種類のデータを共存させる仕組みだ。

「CDT専用時間帯」には特別な仕組みはない。gPTP 時刻同期で、時間帯の始まりと終わりがドメイン内の全ての機器でほぼ同時に切り替わるだけだ。切り替わり時間の誤差は、±1マイクロ秒とかなり精度が高い。この領域のデータ量は、従来のフィールドバスと同じように厳密に設計する必要がある。データ量が少ないと無駄が発生し、データ量が多すぎると時間帯に収まらず大きな遅延やデータ廃棄につながる。従来のフィールドバスは、1本のバス線に全てのノードを接続するため、遅延時間は伝搬遅延のみ考慮すれば済む。しかし、Ethernet TSN では伝搬遅延に加え経由するスイッチ(AV Bridge)の挿入遅延とシリアル化遅延が発生する。しかも、フィールドバスは通常固定長フレームだが Ethernet TSN は可変長フレームだ。この点は特に注意が必要だ。

「その他時間帯」には様々な性質のデータが混在する。この領域は優先制御と帯域制御を使い、データの種類ごとに処理を変えることでバランスを取っている。ストリームの配信経路を設定する IEEE802.1Qat と優先制御と帯域制御を組み合わせて使用する IEEE802.1Qav が主な規格になる。

図1 の動作検証モデルは、各1台の送受信ノードを4台の AV Bridge で直列につないでいる。全ての機器は SRP クラウド内にあり、gPTP ドメイン(時刻同期領域)と SRP ドメイン(経路予約領域) は一致している。ホップ数は5段だ。

Ethernet TSN の動作検証では、パケット長やパケット数をあらかじめ決める必要がある。かつて、 IEEE802 委員会が提案した事例に基づいて作成したモデルが図2 で、青字部は筆者が追加・修正した部分だ。図2 では3つのモデルケースを設定している。CDT 専用時間帯では、CDT 動作1 で正常動作モデルを、CDT 動作2 では不適切な動作モデルを設定した。その他時間帯では、設定時間内に収 まらないモデルを設定している。また、前提条件として AV Bridge は全て Store & Forward 方式で、 Cut Through 方式には触れていない。図2 で規定したサイクル時間や時間割り付けイメージは、図3 を参照いただきたい。

図2 モデルの「ペイロード長」は第3層データの長さを指す。イーサネットでの動作を検証するためには、第2層と第1層で付加される領域を加算する必要がある。イーサネットOH がこれに相当し 42 バイト長になる（図4 参照）。

図2 モデルの「Bridge 挿入遅延」は、当時市販されていた機器の挿入遅延を調査した結果を反映している。当時の市販機器の挿入遅延は、0.04マイクロ秒～5.12マイクロ秒であったため、最大値に近い5マイクロ秒に設定されている。しかし、筆者の感覚では当時（10年程度前）でも精々1マイクロ秒ではないかと思う。

パケット動作モデル

図5 は、全体のキュー構造・優先制御・帯域制御・時刻同期によるゲート開閉のイメージ図だ。厳密な処理は考慮していないため、参考程度にご覧いただきたい。動作検証の中では特に触れていないが、全ての機器の切り替え時刻には±1マイクロ秒の誤差がある。 実際の設計ではこの誤差を含めた設計が必要になる。

パケット動作モデル各部の概要

CDT 動作1:CDT専用時間帯

このモデルは、当時 IEE802 に提案された「正常動作モデル」だ。送信ノードは 170 バイトのイーサネットフレームを連続して8個送信し、4台の Store & Forward ブリッジを経由して、受信ノードに届く。全ての送受信が、予め設定した「CDT 専用時間」内に収まり、End to End 遅延時間が 100μ秒以内に収まることを検証するモデルだ。

検証結果が図6 になる。End to End 遅延時間は 76.9マイクロ秒で、100マイクロ秒に収まっ ている。CDT 専有時間も 185.7マイクロ秒で、250マイクロ秒に収まっている。遅延時間等の計算は次にようになっている。

正常に動作する条件は、実際にパケットを送信している時間(Flow-span)が設定時間 (Scheduled-length)以下でなければならない。更に、時刻精度誤差があり、開始時と終了時に誤差の影響を受けるため注意が必要だ。

CDT 動作2:CDT専用時間帯

このモデルは、CDT 動作1 のパケット数を 8から14に増やしたモデルだ。検証結果が図7 に なる。End to End 遅延時間は 76.9マイクロ秒と変わらず 100マイクロ秒に収まっている。CDT 専有時間(Flow-span)は 267.3マイクロ秒となり 250マイクロ秒を超えている。

正常に動作する条件である Flow-span ≦ Scheduled-length の条件を明らかに満たしていない。時刻精度誤差±1マイクロ秒を考慮しても結果は変わらない。

この結果、P13 は CDT 時間内に送信を開始しているため、時間帯を超過し送信される。P14 は時間内に送信権を確保できないため、次のサイクル迄待たされることになる。この動作が繰り返され、いずれキュー溢れを引き起こしパケット廃棄につながる。CDT 専用時間帯では、確実に送信できるパケット長とパケット数を設定しなければならない。遅延時間等の計算は「CDT 動作1」と同じだ。安全かつ確実な運用を目指すならば、P12 までの送信でとどめるべきだ。

実際の運用では、「サイクル時間」「CDT 専有時間」「ペイロード長」「パケット数」の4つのパラメータから、運用時の設定を決めることになる。

その他時間帯動作

様々なデータが混在する「その他時間帯」は、従来のイーサネットと同じ動きをすることが重要だ。しかし、制御データが使用する「CDT 専用時間帯」の邪魔をしてはいけない。そこで、その他時間帯末尾の125マイクロ秒の領域には「ガードバンド」が設定されている。ガードバンドでは新たにフレーム送信を開始することができない。ガードバンドの125マイクロ秒は、最大長フレーム(123.36マイクロ秒)より少し長い時間が設定されている。もちろん、Preemption 機能を使用すれば、ガードバンド内での新たなフレーム送信開始や有効活用は可能だ。 Preemption は既に掲載済のため、ここでは説明を省力するとともに、Preemption を使用しない前提で話を進めたい。

この領域では、経路制御・優先制御・帯域制御を使い異なる性質を持つデータを共存させる仕組みがあるが、これもすでに解説済のためここでは触れない。ごく一般的なフレームが「ガードバンド」と「CDT 専用時間帯」と共存し、いかに動作するかを例を挙げて説明したい。

ドメイン構成や遅延時間の設定は、CDT 動作モデルと全く同じだ。CDT とは異なり、ペイロードを最大長に設定しているのは図を簡略化するためだ。CDT とその他時間帯での大きな違いは、 End to End の遅延時間にある。SR クラスA/B ストリームの遅延時間は、それぞれ 2ミリ秒/50 ミリ秒と CDT の 100 マイクロ秒に比べ非常に大きい。gPTP/SRP プロトコルデータや Best Effort データには、遅延時間や帯域などの制約は無い。遅延時間等の計算は次にようになっている。

送信ノードは 1542 バイトの SR クラスA のイーサネットフレームを連続して6個送信し、4台の Store & Forward ブリッジを経由して、受信ノードに届く。全ての送受信が、予め設定した「その他時間帯」内に収まり、End to End 遅延時間が 2 ミリ秒以内に収まることを検証するモデルだ。このモデルは、SR クラス帯域が全体の 75% 以下に制限されるルールに違反しているが、ご容赦いただきたい。

検証結果が図8 になる。End to End 遅延時間は 515.94マイクロ秒だ。パケット長が長いためシリアル化遅延が大きくなることで遅延時間も大きくなっている。送信ノードから AV Bridge1 までは、ガードバンドに入り込んでいるが時間帯内に収まっている。しかし、AB Bridge1 以降は「その他時間帯」に収まらず、次のサイクル迄遅延している。最終段の受信ノードには約 1 ミリ秒遅れている。

この検証結果から、ガードバンドで新たなフレームを送信開始しないことで、CDT 専用時間帯 を守れることが分かる。また、CDT 専用時間帯を回避するため、この領域のデータはキューに滞留し待たされることになる。特に、AV ストリームA は総遅延時間が 2ミリ秒に制限されてい る。サイクル時間が 1 ミリ秒のこの例でも約 1 ミリ秒の遅れが発生する。サイクル時間の設定にっては 2 ミリ秒の制限(SR クラスA)を超える可能性がある。2 ミリ秒の遅延時間を守るためには注意が必要だ。

サイクル時間設定やCDT とその他への時間割当は、時間に厳しい制御データを優先する必要があるが、ストリームの遅延にも注意を払う必要がある。