Radio over IPゲートウェイは、オンラインで到達可能で音声を伝送していても、全体的な通信経路のパフォーマンスが依然として低下することがあります。現場での導入において、より困難な問題は、通常、ゲートウェイが接続できるかどうかではなく、遅延がどこで発生しているか、なぜPTT応答がサイト間で変わるか、またはWANが混雑しているときにのみ音声が不安定になる理由です。

RoIPシステムをエンドツーエンドのブラックボックスとしてではなく、一連の測定可能なセクションとして扱うと、これらの障害はより簡単に解決できます。無線キーイング、ゲートウェイ処理、パケット転送、VPN処理、ジッタバッファ、およびリモートRFパスは、それぞれ独自の遅延または障害ポイントに寄与する可能性があります。

導入作業において、有用な疑問は、単にゲートウェイが正しく設定されているかどうかではなく、通信チェーンの各セクションが測定、検証、および文書化されているかどうかです。

1. パラメータを変更する前にRoIPパスをマッピングする

コーデック設定、PTT遅延、またはQoSポリシーを変更する前に、プロジェクトで使用される実際の通信経路を描画します。両方のエンドポイント間の無線機器とネットワークデバイスを含めてください。

典型的なマルチサイトパスは次のようになります。

無線機 → RoIPゲートウェイ → LANスイッチ → ルーター → VPN/WAN → ルーター → ディスパッチプラットフォームまたはリモートゲートウェイ → 無線機

正確なトポロジはさらに複雑になる場合があります。リモートサイトでは、ファイバを主接続とし、4G/5Gをバックアップとして使用する場合があります。コントロールセンターでは、RoIPプラットフォームをファイアウォールの背後に配置する場合があります。一部のプロジェクトでは、無線トラフィックを専用VLANに分離したり、企業VPN経由でルーティングしたりします。

コミッショニング中に重要なのは、あるセクションがどこで終わり、次のセクションがどこで始まるかを知ることです。

有用なテストポイントには通常、以下が含まれます。

• ゲートウェイに入る無線受信音声；

• 無線機に入るゲートウェイ送信音声；

• ゲートウェイからのPTT出力；

• 無線送信の起動；

• ローカルゲートウェイから送信されるIPメディア；

• リモートエンドポイントに到着するIPメディア；

• リモートゲートウェイの音声出力；

• および受信無線機が聞く最終的なRF送信。

このマップは、その後のすべてのテストの基礎となります。オペレータが遅延や途切れのある音声を報告した場合、エンジニアは関連のない複数のパラメータを同時に変更する代わりに、各セクションを個別にチェックできます。

関連RoIPソリューション：Radio Over IPゲートウェイシステム

2. 完全な無線経路の遅延予算を策定する

単一のping結果はRoIP応答時間を表すものではありません。Pingは主にネットワーク到達可能性とIPラウンドトリップ遅延を示します。無線オペレータが経験するのは、PTTが要求されてから有用な音声がリモート無線機に到達するまでに終わる、より長いチェーンです。

トラブルシューティングのために、総遅延を個別のコンポーネントに分割します。

総RoIP応答 = PTT処理 + ローカルゲートウェイ処理 + パケット化 + IPトランスポート + ジッタバッファ + リモート処理 + 無線キーイング + RFシステム遅延

各コンポーネントの正確な寄与は、機器とネットワークに依存します。遅延予算の目的は、すべてのプロジェクトを1つの固定数値に強制することではなく、遅延が実際にどこで追加されているかを特定することです。

ネットワーク遅延と無線遅延を分離する

WANパスが安定しているが、ユーザーが依然としてPTT応答が遅いと報告する場合を想定します。遅延の大部分が無線キーイング時間または大きなジッタバッファに起因する場合、ネットワーク遅延を減らしても問題は解決しない可能性があります。

逆も起こり得ます。両方のサイトで無線キーイングは高速でも、負荷の高いWANまたはVPNパスがゲートウェイ間で変動遅延を導入する場合があります。

これら2つの障害には異なる是正措置が必要であり、そのため総遅延は測定可能なセクションに分割されるべきです。

異なる条件下で同じパスを測定する

ネットワークがアイドル状態のときに遅延を記録し、次に通常のビジネストラフィック中に同じテストを繰り返します。可能であれば、WANに意図的に制御された負荷をかけた状態で再度テストします。

有用な比較は次のとおりです。

• アイドルネットワーク遅延；

• 通常の運用時遅延；

• ピーク負荷時遅延；

• およびセカンダリWANが使用されている場合のバックアップリンク遅延。

アイドル時には許容できるが、運用トラフィック中に不安定になるリンクは、通常、無線インターフェースの問題ではなく、ネットワーク容量、キューイング、またはパス品質の問題を示しています。

3. PTTから音声までのタイミングを推測ではなく測定する

PTTタイミングは試行錯誤で調整されることがよくあります。より信頼性の高い方法は、複数のイベントを順番に測定し、有用な音声がどこから始まるかを正確に特定することです。

例：

• T0： リモートPTTコマンドが発行される；

• T1： ゲートウェイPTT出力が状態を変更する；

• T2： 接続された無線機が送信モードに入る；

• T3： RFキャリアが利用可能になる；

• T4： RFチャネルで有用な音声が始まる。

これらのポイント間の差は、システムを単に「PTT遅延が大きい」と説明するよりもはるかに有用な情報を提供します。

T0とT1の間の遅延が過剰な場合、制御シグナリングまたはゲートウェイ処理を調査します。T1が速く発生するがT2またはT3が遅い場合、無線機器または無線インターフェースをチェックする必要があります。RFキャリアがすでに確立されているが音声が遅れて到着する場合、音声パスとメディアバッファリングを調査します。

リードタイム設定時に実際の無線機を使用する

PTTリードタイムは、接続された無線機またはリピータに合わせる必要があります。異なる機器は、PTT起動と有用な音声の間に異なる間隔を必要とする場合があります。

別のプロジェクトからコピーした値は機能しているように見えても、音声の途切れや不要な遅延を引き起こす可能性があります。

同じ原則がリリースタイミングにも適用されます。最終音声が無線機を離れる前にPTTが解放されると、最後の音節が切り落とされる可能性があります。長く保持しすぎると、音声終了後もチャネルが占有されたままになります。

目標は可能な限り短い遅延ではなく、実際の無線機器で完全で再現可能な送信を実現する最短のタイミングです。

4. 混雑下でのQoSを設定画面ではなく動作で検証する

QoSは設定ページから推測するのではなく、トラフィックの動作によって証明されるべきです。

ゲートウェイはリアルタイムトラフィックを正しくマークする一方で、中間スイッチ、ファイアウォール、VPNデバイス、またはWANサービスがそのマークを変更または無視する場合があります。そのため、両端の設定は正しく見えても、混雑時にRoIPトラフィックが依然としてバルクデータと競合する可能性があります。

実用的なテストは、制御された負荷下でRoIPパスを観察することです。

テストは段階的に実行できます。

1. 通常の無線通話を確立し、遅延、ジッタ、パケットロスを記録します。

2. 同じWANパスにバックグラウンドトラフィックを導入します。

3. PTTおよび音声テストを繰り返します。

4. パケットマークがルート全体で変更されていないか確認します。

5. 混雑が発生するルーターまたはファイアウォールのキューを検査します。

6. 結果をアイドルネットワークのベースラインと比較します。

バックグラウンドトラフィックが増加してもRoIPパスが安定している場合、ネットワークポリシーは機能しています。音声が途切れ始めたり遅延が急激に変動する場合は、ゲートウェイの音声設定や無線設定を変更する前に、利用可能な帯域幅とキューの動作を調査します。

QoSは十分な帯域幅の代わりにはならない

優先処理は競合時にリアルタイムトラフィックを支援しますが、存在しない容量を生み出すわけではありません。恒常的に飽和状態にあるWANリンクには、依然として帯域幅またはトラフィックエンジニアリングのソリューションが必要です。

これは、RoIPがCCTV、ファイル同期、オフィスアプリケーション、またはその他の大容量サービスと同じ接続を共有するネットワークで特に重要です。

バックアップリンクを個別にチェックする

プロジェクトが4G/5Gまたは別のセカンダリ接続を使用する場合、プライマリWANのQoS動作がバックアップパスにも適用されると想定しないでください。

バックアップルートは、異なる遅延、ジッタ、パケットロス特性、またはトラフィックポリシーを持つ可能性があります。したがって、別個の通信パスとして測定する必要があります。

5. セグメントごとに障害を特定する

複数のゲートウェイパラメータを同時に変更すると、元の障害が設定変更の中に埋もれてしまい、トラブルシューティングが困難になります。より良い方法は、パスを分離し、どのセクションで最初に問題が現れるかを特定することです。

既知の正常セクションを使用して検索範囲を絞り込む

ローカルの無線対ゲートウェイ音声がすでに検証されている場合、WAN問題を調査中にそのインターフェースを繰り返し調整しないでください。検証済みの各セクションは変更せず、次のテストポイントに進みます。

同じ方法が逆方向でも機能します。RTPまたは他のIPメディアがパケットロスなくリモートゲートウェイに到達してもRF出力が悪い場合、ネットワーク調整で問題が修正される可能性は低いです。

セグメントベースのテストはマルチサイトシステムで特に有用です。なぜなら、同じゲートウェイモデルが複数の場所で正しく動作する一方で、あるサイトだけが異なる動作をする場合があるからです。正常サイトと異常サイトの測定ポイントを比較することで、違いが無線インターフェース、WANパス、またはローカルネットワークのいずれにあるかを迅速に特定できます。

6. 引き渡し前に導入ベースラインを記録する

RoIPシステムは、最終的な動作値が引き渡し前に記録されている場合、保守が容易になります。ベースラインがないと、後日のルーター交換、無線変更、またはソフトウェアアップグレード時に、現在のパラメータがオリジナルなのか既に変更されたものなのかを技術者が判断できなくなる可能性があります。

導入記録には、比較に有用な値を含めるべきであり、機器設定の全ページを含める必要はありません。

測定値は、ラボ構成からコピーするのではなく、実際の運用パスから記録する必要があります。可能な限り、通常の動作値と、ネットワーク混雑時またはフェイルオーバーテスト中に記録された結果の両方を保持します。

このベースラインは、コンポーネントが変更されるたびに有用になります。新しいルーターが遅延を増加させたり、交換無線機が異なるPTTリードタイムを必要としたり、新しいWANサービスがより高いジッタをもたらしたりした場合、保守チームは比較のための以前の動作状態を持つことになります。

したがって、Radio over IPゲートウェイの導入は、デバイスがオンラインステータスを示したときに完了するわけではありません。通信経路がセクションごとに測定され、PTTタイミングが実際の無線機器で検証され、ネットワーク動作が負荷下でテストされ、最終的な動作値が将来のトラブルシューティングのために記録されたときに完了します。