まず、経路上のどこで障害が発生しているかを図にする
TDM over IPは、従来の回線をIPネットワーク経由で伝送する技術です。障害調査では、ローカルE1インターフェース、パケット伝送、リモート側の回線復元を切り分ける必要があります。これは戦術データのルーティングプロトコルではなく、RIPもすべてのゲートウェイで有効にしなければならない機能ではありません。まず、確認対象の回線、関係する2つのポート、使用するリモートマッピングの組を確認し、同一筐体内の別サービスの状態を、この回線の判断材料にしないようにします。
最小構成の経路は、端末、左側ゲートウェイ、IPネットワーク、右側ゲートウェイ、リモート端末です。実際には、電源、クロック源、管理経路もあります。図は一方向のみを示していますが、障害調査では逆方向も確認する必要があります。工場出荷時設定へのリセットやファームウェアの再インストールから始めるよりも、障害の発生時刻、負荷や経路による変化、同時に異常が発生しているチャネルを記録するほうが、有用な手掛かりを残せます。
管理アクセスとサービスの継続性は同じではない
管理用Webページやpingが正常に機能しても、該当する管理経路とサービスに必要な条件の一部が満たされていることを示すだけです。サービスでは異なるポート、VLAN、宛先マッピングが使われる場合があり、別のルールによる制限も受ける可能性があります。管理できることは、伝送パケットが正しい受信チャネルに到達した証明にはなりません。逆に、管理アクセスができないからといって、すべての回線が停止したとは限りません。端末とサービスの状態を個別に観察してください。
機器の識別情報、現在のアドレス、保守用アクセスポイント、アカウントを確認した後、設定、型番、ファームウェアの記録を保存します。現地作業が必要な場合は、承認済みの保守時間帯とロールバック計画を先に準備してください。接続性を試すためだけに、すべてのセキュリティルールを同時に無効化してはいけません。管理ポート、サービス用Ethernetポート、E1インターフェースは役割が異なります。外観がRJ45であっても、ケーブルやピンを自由に混用できるわけではありません。
ローカルE1では、まず信号、次にサービスモードを確認する
LOSは通常、該当インターフェースで有効な回線信号を検出できないことを意味します。ケーブル、ポート、端末の電源、インターフェースの条件と併せて確認してください。フレーム構造を持つサービスでは、フレーム同期喪失などの状態も発生するため、両端のフレーム構造、シグナリング、設定を確認する必要があります。AISは上流の異常が下流に通知されていることを意味する場合があり、これを見てローカルのネットワークポートが故障していると結論づけてはいけません。アラームの意味と対処方法は、機器の資料と使用中のサービスモードに基づいて判断する必要があります。
E1回線には、平衡120Ω、不平衡75Ωなどのインターフェース条件があります。プラグが接続できるかどうかだけでなく、実際の機器と変換部品を確認してください。回線試験が正常でも、タイムスロットが正しいユーザーに送られている証明にはなりません。非構造化の全回線伝送と、構造化されたチャネルマッピングでは確認対象が異なります。すべてのアラームや設定を、あらゆるモードに適用しないでください。
IP側では、実際にサービスを運ぶパケットを見る
両端の関連アドレス、転送経路、許可されたポート、VLAN、パケット長の条件を確認します。製品が実際に対応するカプセル化方式と設定に従って確認してください。名称だけから、すべてのゲートウェイが同じ伝送プロトコルを使うと推測したり、他社製品のデフォルトポートをそのまま流用したりしてはいけません。サービスを受信できない場合は、送信側でパケットが生成されていないのか、経路途中に制限があるのか、受信側のマッピングが一致していないのかを区別する必要があります。
適切な監視機能を利用できる場合は、送信側と受信側のパケット数、順序、遅着、損失の状態を比較し、測定時刻も確認します。累積カウンターは、2回の読み取り値とその間隔を併せて解釈する必要があります。クリアや再起動を行うと統計が変わります。パケットキャプチャの位置にも限界があります。一方で送信が見えても、対向側で受信した証明にはなりません。また、通常のコンピューターで特定のパケットが見えなくても、ネットワークがそのパケットを一度も転送しなかったと直接証明することはできません。
到着変動と長期的な周波数偏差を分けて見る
パケットネットワークではキューイングが行われるため、パケットの到着間隔が変動することがあります。受信側はデータをバッファに一時保存し、必要なクロックに従って読み出します。パケットが許容時間を超えて遅着したり失われたりした場合、バッファから元の内容を何もない状態で復元することはできません。機器は代替出力や対応するアラームを生成する場合があり、具体的な動作を確認する必要があります。図のキューと波形は一般的な仕組みを示すものであり、実測結果ではありません。
長期的な読み出し速度が書き込み速度より速い場合、水位は徐々に低下する可能性があります。逆に遅い場合は、徐々に上昇する可能性があります。この周波数の関係は、短期的な到着のばらつきとは別の問題です。両端のクロック源、マスター／スレーブ関係、基準信号喪失後の動作を確認してください。管理システムの時刻をNTPで設定しても、E1回線の周波数回復が要件を満たした証明にはなりません。また、単にバッファを増やすだけでは、継続的な周波数偏差を恒久的に解消できません。
パラメーター調整は1つの仮説を検証するにすぎない
まず代表的な負荷条件で基準状態を確立し、マニュアルで許可された範囲内で関連条件を1つずつ変更して、変更前後のアラーム、待ち時間、実際のサービスを記録します。バッファを深くすると到着変動の一部を吸収できる場合がありますが、遅延も増加します。ペイロードの大きいパケットはカプセル化のオーバーヘッド比率をある程度下げられる場合がありますが、データ収集の待ち時間も増加します。両方の値を最大に設定し、偶然の復旧を恒久対策と呼んではいけません。
経路切替、共有出力側の輻輳、セキュリティトンネルの変更はいずれも伝送条件を変える可能性があります。QoSで優先順位を設定することはできますが、出力側の持続的な伝送容量が増えるわけではありません。トンネルによる長さの増加とオーバーヘッドも確認する必要があります。ネットワークが再び到達可能になった後も、E1と実際のサービスの確認を続けてください。無負荷時のping結果1回で、負荷のかかった回線のビットエラー、アラーム、アプリケーション性能の確認を代用してはいけません。
飛暢科技のゲートウェイでループバック機能を活用する
飛暢科技のFCT-E1およびFCT-E4-Mの詳細情報には、クロック回復、設定可能なパケット長、VLAN、E1パケット損失表示、ローカル／リモートE1ループバックなど、保守時の確認に関わる項目が記載されています。FCT-E4-Mは複数の宛先IPとポートマッピングも備えているため、4回線のリモート端を1つずつ確認できます。これらの記述は確認すべき状態を判断する助けになりますが、Webページに記載された標準的な診断カウンターやコマンドがすべて実装されていることを意味するものではありません。
ループバックは対象となる試験範囲に折り返し経路を形成し、確認済みの境界内で障害箇所を絞り込むのに役立ちますが、サービスを占有または中断する可能性があります。試験前にループバックの位置、方向、他のリンクを迂回するかどうかを確認してください。保守時間帯にマニュアルに従って操作し、終了後はループバックを解除して設定を元に戻します。1つのループバック試験に合格しても、その試験が対象とした範囲内の結果を示すだけです。公衆網での伝送、全チャネル、両端の端末が正常であると自動的に証明できるわけではありません。
限定範囲の試験から経路全体へ戻す
切り離した試験環境で、まず1回線と適合する端末を選び、ローカル試験または短経路試験を実施します。インターフェース、フレーム、マッピング、タイミングを確認してから、実際のネットワークに再接続します。無負荷時と目標負荷時を別々に観察し、他のチャネルを追加した後も状態が要件を満たすことを確認します。試験パターンが必要な場合は、適切な測定器と承認された方法を使用してください。電話やデータサービスへの影響を避けるため、運用中の回線に直接注入してはいけません。
実際のネットワークでのみ異常が発生する場合は、その時点のポート、パケット、バッファ、アラームの記録を保存し、経路に沿って区間ごとに範囲を絞り込みます。短経路でも失敗する場合は、端末、インターフェース設定、クロック、ハードウェアを確認します。機器交換やファームウェア更新には、型番の適合確認、変更の根拠、ロールバック手段が必要であり、障害調査の最初の手順にすべきではありません。復旧後は、赤いランプが消えたことだけでなく、双方向の実際のサービスを同時に検証してください。
後から検証できる障害記録を引き継ぐ
エンドツーエンドの構成、チャネルとリモート端、機器のバージョン、設定、時刻、負荷、各変更を記録します。次の保守担当者が判断できるよう、検証済みの範囲、まだ確認していない条件、復旧後の観察結果を明記してください。アラームには発生条件と解除条件がある場合があります。一時的な異常と継続的な障害を同じ統計に混在させず、具体的なしきい値は機器の機能に応じて確認する必要があります。
障害調査の目的は、より高度に聞こえるプロトコルを探すことではなく、ローカル回線、ネットワーク伝送、リモート側の復元のどこに具体的な問題があるかを特定することです。証拠が不十分な場合は疑いを残し、層ごとの検証を続けます。改善策が得られたら、代表的な負荷と許容される変動条件で再試験します。そうして初めて、復旧した理由と、次回の保守で観察すべき点を説明できます。
資料に関する注記：原理図は技術内容との整合性を確認しており、一般的な仕組みを説明するためのものです。製品写真や実測記録ではありません。具体的なインターフェース、モード、能力は、選定した機種、バージョン、現地での確認に従ってください。
検証資料： 飛暢科技 FCT-E1 単一E1回線エミュレーションゲートウェイ
飛暢科技 FCT-E4-M 4回線E1回線エミュレーションゲートウェイ
飛暢科技 TDM Over IP製品カテゴリ
RFC4553：構造に依存しないTDM over Packet
RFC5086：構造を認識する回線エミュレーション
RFC4197：回線エミュレーション、クロック、ネットワークの要件
E1 over IPのカプセル化、バッファリング、クロック回復
TDM over IPの経路変更と復旧時の受入確認
関連技術トピック： TDM over IPで経路切替が発生するとどうなるか：RIPの適用境界、順序入れ替わり、復旧時の受入確認 E1 over IPの仕組みとは？ 回線エミュレーションのカプセル化、バッファリング、クロック回復
中国語の技術記事から翻訳。原文初公開：2024-04-16。原文最終改訂：2026-10-13。 中国語の原文を読む
