無線ネットワークは、異なる時期に、異なる運用チーム向けに構築されることがよくあります。セキュリティ部門は従来型のUHF無線機を使用し、メンテナンス部門はDMRネットワークで作業し、フィールドスタッフは公衆ネットワークのプッシュ・トゥ・トークサービスに依存し、管制室はSIP電話やディスパッチソフトウェアを介して運用する場合があります。各システムは独立して動作しますが、統合レイヤーなしではユーザー間の相互通信はできません。

Radio over IPゲートウェイはその接続を提供します。無線機または基地局をIPネットワークに接続し、無線音声とプッシュ・トゥ・トーク制御をネットワークベースの通信に変換し、無線チャンネルをSIPサーバー、ディスパッチコンソール、録音システム、リモートオペレーターが利用できるようにします。このアプローチにより、既存の無線インフラを交換することなく、その耐用年数を延ばすことができます。

ゲートウェイはRFネットワーク自体を置き換えるものではありません。周波数、リピーター、アンテナ、無線カバレッジは既存の無線インフラの管理下にあります。RoIPはこれらのリソースへのアクセスを拡張し、元々は別々に動作するように設計されたシステムに共通の通信経路を提供します。

無線ネットワークに統合レイヤーが必要な理由

無線システムは、異なる周波数、チャンネル構造、シグナリング方式、ベンダープロトコルを中心に設計されています。従来型のアナログ無線機は、DMR、PDT、TETRAネットワークと直接通信できません。プライベート無線システムがSIP電話やセルラープッシュ・トゥ・トークプラットフォームと音声を交換する必要がある場合、その違いはさらに大きくなります。

無線プロトコルごとにネイティブインターフェースを開発することは、高コストで保守が難しい場合があります。プロプライエタリなシグナリング、ソフトウェア開発キット、無線ネットワークの詳細な知識へのアクセスが必要になる可能性があります。無線プラットフォームの変更も統合に影響を与える可能性があります。

RoIPゲートウェイはより実践的なアプローチを取ります。互換性のある無線機、移動機、または基地局に接続し、その無線機をチャンネルへのアクセスポイントとして使用します。ゲートウェイは音声とPTT状態をIPネットワーク経由で転送し、他の場所のオペレーターやアプリケーションがチャンネルを使用できるようにします。

無線側の接続はエアインターフェース技術からほぼ独立しているため、適切な音声およびPTTインターフェースが利用可能であれば、同じ統合方法を従来型無線、デジタルトランキングシステム、航空無線、海上無線、HF通信機器に適用できます。

無線インターフェースによっては、ゲートウェイはキャリアセンス、スケルチ、またはチャンネルビジー信号を監視することもあります。これらの入力は、有効な無線トラフィックを背景ノイズから区別し、無線チャンネルが既にビジー状態の場合にIPユーザーが送信するのを防ぐのに役立ちます。そのような信号が利用できない場合は、音声アクティビティ検出が使用されることがありますが、ノイズの多い無線環境ではより慎重な調整が必要になるのが一般的です。

オペレーターとアプリケーションが利用可能な中核機能

無線音声とPTTの変換

ゲートウェイは接続された無線機から音声を受信し、IP音声ストリームに変換して、承認されたエンドポイントに送信します。逆方向では、ディスパッチャーまたはSIPユーザーからの音声が無線機に届けられ、ゲートウェイがプッシュ・トゥ・トーク制御を介して送信機を起動します。

PTTの処理は、無線通信が通常半二重であるため、特に重要です。統合は、チャンネルがいつ送信し、いつ受信し、他のユーザーが既にチャンネルを保持しているかを制御する必要があります。PTTタイミングの調整が不十分だと、メッセージの先頭が途切れたり、2つのシステムが同時に送信したりする可能性があります。

エンジニアリングされた導入では、PTT起動、送信機準備、音声送信はタイムシーケンスとして処理されます。音声送信前に短いプリアンブル期間が必要な場合があり、解放遅延はメッセージの終わりを伝えるのに十分な長さである必要がありますが、チャンネルを不必要に占有しないようにする必要があります。これらの値は、汎用設定からコピーするのではなく、実際の無線機でテストする必要があります。

SIPベースの通信

SIPサポートにより、無線チャンネルはIP-PBX、ユニファイドコミュニケーションプラットフォーム、またはディスパッチシステム内の通信リソースとして表示されます。システム設計に応じて、オペレーターは無線チャンネルに発信したり、トークグループに配置したり、会議に含めたり、ディスパッチコンソールから監視したりできます。

これにより、無線ユーザーとSIP電話、ソフトフォン、産業用インターホン、オペレーターコンソールなどのIP通信エンドポイントとの間に制御されたブリッジが作成されます。また、組織は長距離アナログ音声回線を設置する代わりに、既存のIPネットワークを無線拡張に使用できます。

SIPシグナリングと音声メディアは、ネットワーク設計時に別々に検討する必要があります。ゲートウェイはサーバーへの登録に成功しても、RTP音声パスがルーティング、ファイアウォール、またはNATポリシーによってブロックされる可能性があります。コーデックの選択も帯域幅、遅延、音声品質に影響するため、ゲートウェイ、サーバー、ディスパッチクライアント間の不要なトランスコーディングは避けるべきです。

無線リソースへのリモートアクセス

無線機はもはや各ディスパッチャーの隣に配置する必要はありません。無線機器は適切なアンテナカバレッジのある場所に留め、オペレーターは別の建物、都市、または地域の管制室からチャンネルにアクセスできます。

これは、アンテナを屋上、タワー、トンネル、または遠隔地に設置する必要がある場合に役立ちます。また、各オペレーター位置に必要な無線機器の量を減らし、集中管理を簡素化することもできます。

マルチサイトチャンネルネットワーキング

複数のゲートウェイをIPネットワークで接続して、より広範な通信構造を作成できます。指揮センターは複数の施設からの無線リソースを監視でき、承認された地域オペレーターは各無線サイトに物理的に存在しなくても、選択されたチャンネルにアクセスできます。

ネットワークは、必要な呼制御と運用モデルに応じて、SIP登録、SIPトランク、またはディスパッチプラットフォーム接続を使用する場合があります。チャンネル権限は、ユーザーが自分の責任に関連する無線リソースのみを表示できるように、慎重に定義する必要があります。

容量は、携帯無線機の数のみではなく、独立して制御される無線パスに基づいて計算する必要があります。大規模なユーザーグループが1つのチャンネルを共有する一方、小規模な運用では複数のチャンネルを同時に監視または送信する必要がある場合があります。独立した同時アクセスを必要とする各無線リソースには、適切な無線機とゲートウェイパスが必要です。

録音と運用監視

無線音声がIP側で利用可能になると、互換性のある録音プラットフォームに配信できます。これにより、無線通話、電話通話、ディスパッチ通信を同じシステムからレビューする必要がある場合に、より完全な運用記録が提供されます。

ゲートウェイは、接続、PTT、またはチャンネルアクティビティのステータスを管理プラットフォームに報告することもあります。これらのステータス信号は、技術チームが通信障害が無線機、ゲートウェイ、IPネットワーク、または中央アプリケーションのいずれに関連するかを識別するのに役立ちます。

インシデントレビューのために、すべてのゲートウェイ、ディスパッチサーバー、録音システムは共通の時刻ソースを使用する必要があります。正確な時刻同期により、無線トラフィックをアラームイベント、ビデオ映像、オペレーターアクションと関連付けることが可能になります。サポートされている場合、録音にはチャンネル名、呼び出し方向、責任ディスパッチ位置も保持する必要があります。

関連製品：Becke RoIPゲートウェイ 

指揮・ディスパッチセンターの実用的なアーキテクチャ

典型的なソリューションは、4つの機能レイヤーで構成されます。

• 無線レイヤー： 従来型無線、DMR、PDT、TETRA端末、航空無線、HF機器、または無線基地局。

• アクセスレイヤー： 無線音声、PTT、およびサポートされる制御信号に接続されたRoIPゲートウェイ。

• ネットワークおよび制御レイヤー： LAN、WAN、VPN、SIPサーバー、IP-PBX、またはディスパッチ通信プラットフォーム。

• アプリケーションレイヤー： ディスパッチコンソール、SIP電話、ソフトクライアント、録音サーバー、アラームプラットフォーム、管理アプリケーション。

ディスパッチャーがチャンネルを選択してPTTを押すと、ディスパッチプラットフォームは音声ストリームと制御要求を該当するゲートウェイに送信します。ゲートウェイは接続された無線機を起動し、無線ネットワークを介してメッセージを送信します。フィールド無線機からの応答は同じパスを逆方向に進み、オペレーターコンソールで再生されます。

アーキテクチャは集中型または分散型にできます。集中型設計は、呼制御と録音をメイン指揮センターに配置します。分散型設計は、ゲートウェイと選択された通信サービスをローカルサイトに保持し、単一の広域リンクへの依存を減らします。正しい構造は、ネットワーク信頼性、運用責任、および要求される障害動作に依存します。

クリティカルサイトの場合、設計はWAN、SIPサーバー、または主要ディスパッチ位置が故障した場合に何が利用可能かを定義する必要があります。ローカルの無線対無線通信は、可能な限り独立を維持する必要があります。冗長電源、二次ネットワークパス、バックアップディスパッチ位置、ローカルフォールバックサービスは、必要な可用性レベルに応じて追加できます。

プライベート無線、PoC、自動化ワークフローの接続

公衆ネットワークプッシュ・トゥ・トーク（一般にPoCと呼ばれる）は、広域カバレッジを必要とするモバイルチームによってますます使用されています。プライベート無線システムは、専用チャンネルを提供し、公衆モバイルカバレッジが制限されている場所でも動作を継続できるため、工場、公益事業、輸送運用、緊急対応において依然として価値があります。

これら2つの環境を統合することは簡単ではありません。異なる呼制御方法、IDシステム、メディアパスを使用しています。単純なバックツーバック構成は、PoC端末をプライベート無線端末に外部音声インターフェースを介して接続する場合があります。これは一時的な運用には役立つかもしれませんが、追加の音声段階と独立した端末が遅延を増やし、障害ポイントを増やす可能性があります。

恒久的な導入では、サポートされるネットワークインターフェースまたはディスパッチプラットフォームを介してPoCプラットフォームと無線ゲートウェイを接続することが推奨される設計です。統合は、通話許可要求、PTT解放タイミング、ビジーチャンネル動作を調整する必要があります。両側のオペレーターは、2つの別々の端末を手動で制御しなくても通信できる必要があります。

ブリッジは、競合する送信要求がどのように処理されるかも定義する必要があります。無線ユーザーとPoCユーザーがほぼ同時にPTTを押した場合、プラットフォームには明確な調停ルールが必要です。優先順位は、ユーザーロール、緊急ステータス、または要求の到着順序に基づいて割り当てられます。このロジックがないと、重複するコマンドが音声を途切れさせたり、ユーザーが誰がチャンネルを制御しているか不明確になったりする可能性があります。

RoIPは自動応答ワークフローの一部にもなります。火災警報、アクセス制御イベント、機器故障、または緊急ボタンが作動すると、アラームプラットフォームはAPI、MQTTメッセージ、または他のサポートされるインターフェースを介してイベントを送信できます。通信プラットフォームは事前定義されたルールを適用します。例えば：

• 指定された無線トークグループへの発信。

• 選択された無線チャンネルでの録音警告の再生。

• ディスパッチコンソールと責任者への警告。

• 確認のため関連カメラビューを開く。

• 音声セッションとイベント処理プロセスの録音。

このタイプの統合は、無線通信をアラーム、ビデオ監視、指揮アプリケーションに接続します。ゲートウェイはそれ自体で運用上の判断を下すわけではありません。ワークフローが使用する通信経路を提供します。

技術的制限と導入判断

基本的な無線接続は通常、音声、受信音声、PTT制御を伝送します。デジタルトランキング無線システム内で利用可能なすべての機能を自動的に公開するわけではありません。プライベートコール、テキストメッセージング、無線ID、緊急シグナリング、GPS位置、リモートチャンネル選択などの機能には、追加の無線側シグナリング、サポートされる制御インターフェース、または無線ネットワークインフラとの統合が必要です。

この区別は、機器を選択する前に確認する必要があります。プロジェクトが無線ユーザーとディスパッチャー間のグループ音声通信のみを必要とする場合、音声およびPTT統合は実用的で経済的なソリューションを提供できます。指揮センターが個別の無線ID、位置、または緊急ステータスを表示する必要がある場合、より深い統合が必要です。

ソリューション設計中に以下の要素をレビューする必要があります。

• 無線互換性： 各接続無線機で利用可能な音声、PTT、アクセサリ、制御インターフェースを確認します。

• チャンネル要件： 監視が必要なチャンネルと、同時送信アクセスを必要とするチャンネルを特定します。

• 音声品質： 入力および出力レベルを調整して、音量不足、歪み、ノイズ、エコーを防ぎます。

• PTTタイミング： 送信起動および解放遅延をテストし、メッセージが途切れないようにします。

• ネットワークパフォーマンス： 各通信パスのレイテンシー、ジッター、パケットロス、帯域幅を評価します。

• 障害動作： ゲートウェイ、中央サーバー、またはWANリンクが利用不能になった場合の動作を定義します。

• アクセス制御： ユーザー、ロール、場所に基づいてチャンネル監視および送信権限を制限します。

• 統合範囲： プロジェクトが音声のみか、追加の無線シグナリングおよびデータを必要とするかを文書化します。

• 受入テスト： 通常通話、ビジーチャンネル、同時イベント、ネットワーク中断、復旧、録音をテストします。

ネットワーク受入は、単純な接続テストではなく、完全なエンドツーエンドパスに基づいて行う必要があります。エンジニアは、通常のネットワーク負荷時に音声が明瞭であること、ジッターバッファーが過度の遅延を導入しないこと、パケットロスが単語の繰り返しやギャップを引き起こさないことを確認する必要があります。ファイアウォールルールは、SIPシグナリングとネゴシエートされたメディアポートの両方を許可する必要もあります。

成功するRoIPプロジェクトは、既存の無線リソースと運用ワークフローの棚卸しから始まります。その後、必要なインターフェース、呼制御方法、統合深度に応じてゲートウェイを選択する必要があります。これらの要件から始めることで、音声のみの接続を完全なデジタル無線制御と誤認することを防ぎます。

よくある質問

RoIPゲートウェイはVPNを介して動作できますか？

はい。ゲートウェイとディスパッチサーバーが異なるプライベートネットワーク上にある場合、VPNが一般的に使用されます。VPNは、リアルタイム音声およびSIPトラフィックに適したレイテンシー、ルーティング、セキュリティポリシーを提供する必要があります。

無線プロジェクトには何台のゲートウェイが必要ですか？

台数は、独立してアクセスする必要がある無線リソースの数に依存します。同時動作を必要とする各チャンネルまたは無線パスは、通常、独自の制御可能な接続を必要とします。共有または切り替え式無線設計はハードウェア要件を削減できますが、同時アクセスを制限する可能性があります。

WAN接続が故障した場合、システムは動作を続けられますか？

設計にローカルフォールバックが含まれていれば可能です。ローカル無線通信は、中央ディスパッチ接続が失われても利用可能なままである可能性があり、分散サーバーまたはローカルオペレーター位置が追加の回復力を提供できます。

無線トラフィックはIPネットワーク上で暗号化すべきですか？

機密性の高い導入では、システム全体でサポートされるセキュリティ機能を使用して、シグナリング、音声トラフィック、管理アクセスを保護する必要があります。ネットワークセグメンテーション、VPN、強力な認証、制限された管理も重要です。

ゲートウェイの設置は無線カバレッジエリアを変更しますか？

いいえ。無線カバレッジは依然として、接続された無線システム、アンテナ位置、送信電力、地形、周囲の構造に依存します。ゲートウェイはIPネットワークを介して無線リソースへのアクセスを拡張しますが、それ自体でRFカバレッジを増加させることはありません。