OTUCn（フレキシブルOTN）

概要

OTUCn（Optical channel Transport Unit Cn）は、ITU‑T G.709で定義されるフレキシブルなOTNトランスポート単位で、「n本の100Gレーン」を束ねて400G / 800G などの大容量信号を運ぶために使われます。従来の固定レートOTU4と比べて、レートの拡張性・柔軟性に優れていますが、トリビュタリスロット設計、ODUflexとの整合、FEC・遅延・保護方式の設計など、押さえるべきポイントも増えます。

平たく言うと、「100G単位の“レーン”を必要な本数だけ束ねたOTN用の“太いチューブ”」です。400Gサービスには n=4 のOTUC4、800Gサービスには n=8 のOTUC8 といった形で使い分け、ODUflexなどの可変帯域サービスを柔軟に収容できるようにしたのがOTUCnの特徴です。

• 400G / 800G クラスのサービスをOTNで収容したいとき
• OTU4中心の旧構成から、フレキシブルOTNへ移行する中長期ロードマップを検討するとき
• ODUflexやスライスされた帯域を、複数のOTUCn上にどう割り当てるかを設計したいとき
• マルチベンダ環境でOTUCnの相互接続試験（FEC/FlexO/マッピング）を行うとき
• L1仮想化やスライシングと組み合わせて、OTNレイヤで柔軟な帯域提供を行いたいとき

OTUCnは、100G単位のレーンを束ねることで高レート化を実現します。ここでは構造をイメージしやすくするための整理をします。

• レーン構造：OTUCnはn本の「100Gレーン」で構成され、それぞれのレーンが部分的なトラフィックを運びます。
• ODUflexとの関係：ODUflexは必要帯域に応じて複数レーンに分割されてマッピングされ、合計でサービスのビットレートを満たすように組み立てられます。
• FECとOAM：OTUCnにもFECとOAMフィールドがあり、誤り訂正と監視を行います。FEC方式やレーン間の同期は、ベンダ間の相互接続試験で重要なポイントになります。

• トリビュタリスロット設計：サービスの帯域とSLAに応じて、何スロットをどのOTUCnレーンに割り当てるかを決めます。将来の拡張やスライスの再配置も考慮します。
• ODUflexとの整合：ODUflexの粒度とOTUCn側のスロット粒度を揃え、余りが出にくい構成を検討します。収容効率（%）を意識するのがポイントです。
• FEC・遅延・オーバヘッド：高レートほどFECの影響が大きくなります。FEC利得と遅延（ms）、オーバヘッド（%）のトレードオフを評価し、アプリケーション要件に合う構成を選びます。
• 保護方式との組み合わせ：OTUCn上での保護（1+1、スライス単位の保護など）と、ROADMやIP/MPLSレイヤの保護が二重にならないよう、アーキテクチャ全体で整理します。
• マルチベンダ相互接続：OTUCnの実装差分（FEC方式、FlexOの扱い、OAM）を意識し、ベンダ間PoCで詳細な相互接続試験を行うことが重要です。

運用側では、「OTUCn上にどのサービスがどのように載っているか」が把握できるかどうかが、トラブルシュートやSLA管理のしやすさを左右します。

• サービスとスロットの対応表：どのOTUCnのどのスロットに、どのODU/ODUflex（どのサービス）が乗っているかを一覧にしておきます。
• スループットと収容効率：実際に利用しているスロット数とOTUCnの総スロット数から、収容効率（%）を定期的に確認します。
• エラーカウンタ／BER監視：pre/post‑FEC BER、ES/SES/UASなどのカウンタをOTUCn単位・スロット単位で監視し、区間ごとの品質や劣化傾向を把握します。
• 保守・増設時の影響範囲：スロット再配置やOTUCnの増設・削減が、どのサービスに影響するかを事前にシミュレーションし、作業手順に反映します。
• ログとテレメトリの連携：光テレメトリ（OSNR・パワー）やL1 OAMとOTUCnスロット情報を紐付けて可視化すると、トラブルシュートがしやすくなります。

典型例として、400Gクラスのサービス（例えば400G Ethernet）をOTUC4で収容するケースを簡単に整理します。

• 設計：サービス要件（遅延・可用性・SLA）とトポロジをもとに、OTUC4上のトリビュタリスロットをどのように割り当てるかを決めます。必要なFECとOSNRマージンを確認します。
• 実装：FlexOなどを用いて400Gサービスを複数レーンに分割し、OTUC4上のスロットにマッピングします。
• 運用：OTUC4単位・スロット単位でBERやES/SESを監視し、ラマン/EDFA構成や保護方式との整合を確認します。
• 拡張：将来800Gサービスを追加する計画がある場合、初期段階からOTUC8まで拡張可能な構成を検討しておきます。

• 誤解：OTUCnは従来OTUとまったく同じ感覚で運用できる実際：スロット設計やODUflexとの整合、FECの選択など、追加で検討すべき点が多くあります。
• 誤解：相互接続は規格に従っていれば自動的にうまくいく実際：実装差分やベンダ独自拡張により、FECやOAMの扱いが異なる場合があります。事前の相互接続試験が重要です。
• 誤解：スロットやODUflexの設計は後から柔軟に変えられる実際：変更にはサービス停止や大規模な再配置が伴うことがあります。初期設計である程度の将来拡張を見込むことが大切です。

• ITU‑T G.709（OTNフレーム規格）
• OTU4（100G OTNフレーム）
• FEC（Forward Error Correction）
• L1 OAM（OTN/OTUの運用監視）
• 光テレメトリ（OSNR・パワー監視）
• L1仮想化（Layer-1 Virtualization）
• Open Line System（OLS）

ここでは、OTUCnをネットワークに導入するときの検討フローと、設計・運用チームで共有しておくと便利なチェック項目をまとめます。実際には、ベンダとのPoC（概念検証）やラボ試験、限定商用トライアル、本格展開という段階を踏むことが多く、それぞれの段階で確認すべきポイントが少しずつ異なります。

• ターゲットサービスの整理：400G/800Gといった高レート伝送を何年スパンでどの程度まで増やす想定か、L2/L3サービスやDCIなど、用途ごとに帯域需要を洗い出します。
• スロット設計方針の確認：「OTUC4を基本単位にするのか」「OTUC2/OTUC3をどこまで使うのか」「将来OTUC8以上を前提にするのか」といった方針を整理します。
• 保護方式の選択：1+1保護・共有保護・パス保護など、既存OTU4ベースの設計ポリシーと整合が取れるかを確認します。
• マルチベンダ前提の有無：1社完結か、将来的にマルチベンダ相互接続が前提なのかによって、FEC方式やFlexO対応状況のチェックの細かさが変わります。

• OTUCnフレーム・FECの確認：G.709/G.798に基づき、OTUCnフレーム構造・FEC方式・オーバヘッドをラボ環境で確認します。
• ODUflexマッピングの再現：想定する代表的なサービス（100G/400G/800Gなど）をODUflex＋トリビュタリスロットでどのようにマッピングするかを試験します。
• 遅延・ジッタの測定：レーン数やFEC方式による遅延増分、保護切替時の一時的なジッタや誤り特性を測定し、上位レイヤのSLAと整合が取れるかを確認します。
• 障害シナリオテスト：レーン単位の障害、光レベル劣化、FEC限界近傍での振る舞いなどを再現し、アラームと保護動作が期待どおりかを検証します。

• 対象区間の選定：トラフィックが重要だがバックアップパスも確保できる区間を選び、最初のOTUCn導入区間とします。
• 監視項目の確定：OTUCnレベルの誤り率・FECマージン・レーン毎の状態・ODUflexのエラーカウンタなど、日次・週次で見るべき指標を整備します。
• アラート閾値・運用フロー：どのレベルのFECマージン低下やエラー発生で「注意喚起」「計画保守」「即時切替」を行うか、運用フロー図にまとめます。
• SLA/契約への反映：OTUCnを用いた区間に固有の制約（最大遅延・保護切替時間など）があれば、SLAや社内のサービス仕様書に反映します。

• 標準スロット構成の定義：「都市間バックボーンはOTUC4を標準」「DCI専用ルートはOTUC8」など、設備計画に使える標準構成を決めます。
• 運用ドキュメントの整備：故障対応手順・増設時の注意点・ラボ試験で得られたナレッジを運用マニュアルに反映し、新任メンバーでも追えるようにします。
• 可視化・ダッシュボード化：OTUCn関連のKPIを監視システムやダッシュボードに組み込み、トラフィックやエラーマージンの傾向を一目で確認できるようにします。
• 定期レビュー：半年〜1年ごとに、「スロット設計はうまく機能しているか」「ODUflexの使われ方は想定とずれていないか」をレビューし、次期計画に反映します。

• OTUCn導入の目的（容量拡張・柔軟な帯域提供・DCI高速化など）が明文化されているか。
• 対象サービスのレート・想定流量・SLA（遅延・可用性）が整理されているか。
• OTUCnレーン構成・スロット設計・保護方式の方針が合意されているか。
• マルチベンダを想定する場合、FEC・FlexO・OAMについて相互接続試験計画があるか。
• ラボ試験で確認すべきシナリオ（正常・障害・保護切替）が洗い出されているか。
• 監視項目とアラート閾値、運用フローがドキュメント化されているか。

この付録をたたき台として、実際のネットワーク規模やサービスポートフォリオに合わせて項目を追加・削除していくと、OTUCn導入プロジェクト全体の抜け漏れを減らしつつ、設計・運用・営業の関係者間で共通認識を持ちやすくなります。

• ITU‑T G.709（OTUCn 定義）
• ITU‑T G.798（OTN機器の機能ブロック）
• OpenROADM MSA（OTN/ROADMノードとトランスポートモデル）

OTUCnは、100Gレーンをn本束ねたOTNトランスポート単位で、400G/800Gなどの高レートサービスを柔軟に収容するために使われます。ODUflexやトリビュタリスロットと組み合わせることで、帯域を細かく切り分けて提供できます。

最大のメリットは、100G単位のレーンを組み合わせることで、400G/800Gなどの高レートサービスを柔軟に収容できることです。将来レートの拡張にも対応しやすく、ODUflexと組み合わせて帯域をスライスして提供することもできます。

トリビュタリスロットやODUflexの設計、FECと遅延・オーバヘッドのバランス、保護方式との整合、マルチベンダ相互接続でのFEC/FlexO/OAMの扱いなどに注意が必要です。初期段階からPoCやラボ試験で挙動を確認し、将来拡張を見込んだスロット設計を行うことが重要です。

最終改定：2025-12-01