公衆網プッシュツートークサービスは、4Gおよび5Gモバイルネットワークの拡大に伴い急速に発展してきました。PoCとも呼ばれるこれらのシステムは、組織が独自の無線基地局ネットワークを構築することなく、グループ通信およびブロードバンド機能を提供できます。同時に、専門的な私有無線システムは、公共安全、空港、港湾、工場、交通、エネルギー運用における重要な通信のために引き続き不可欠です。したがって、実際の課題は一方のネットワークを選択して他方を置き換えることではなく、ユーザー、カバレッジエリア、および運用タスクがネットワーク境界を越える場合に両方が通信できるようにすることです。

公共・私有無線統合ソリューションは、これら2つの通信環境間に相互運用レイヤーを作成します。すでに導入されているシステムに応じて、統合はバックツーバック無線接続またはPoCプラットフォームへの直接プロトコルレベルアクセスを通じて実装できます。各方法には、互換性、音声品質、遅延、導入の複雑さ、および将来の拡張に対する異なる要件があります。

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

両方のネットワークが依然として重要である理由

公共および私有無線システムは、異なる技術的および運用上の優先事項に基づいて発展してきました。PoC通信は、移動体通信事業者が提供するカバレッジを活用します。端末は、組織が各運用エリアに専用の無線インフラストラクチャを導入することなく、利用可能な4Gまたは5G接続を介して通信できます。

これにより、迅速な展開、広い地理的カバレッジ、および低いインフラ投資が重要である場合に、公衆網プッシュツートークが魅力的になります。PoC端末は、基本的な狭帯域音声を超えたブロードバンドサービスもサポートできるため、通信ニーズが支店、リモートワーカー、または地理的に分散したサイトに広がる場合に、企業により大きな柔軟性をもたらします。

私有トランク無線は異なる役割を果たします。PDT、DMR、TETRAなどの技術に基づくシステムは、重要な通信のために引き続き広く使用されています。それらの低遅延、高信頼性、およびセキュリティ特性は、通信の可用性が運用または緊急対応に直接影響するアプリケーションにおいて、それらを置き換えることを困難にしています。

したがって、公共安全組織、空港、港湾、産業プラント、交通事業者、およびエネルギー企業は、私有無線を運用の核として使用し、PoCをカバレッジの拡張または追加の通信レイヤーとして導入する場合があります。

このタイプの環境では、2つのシステムを独立して運用すると通信の孤立が生じます。私有無線ユーザーは、両方が同じインシデントまたは運用タスクをサポートしている場合でも、PoCユーザーと直接話すことができない場合があります。公共・私有統合は、ネットワーク間に制御された音声パスを作成することにより、このギャップに対処します。

主な相互運用性の課題

2つの環境を接続することは、単にそれらを同じIPネットワーク上に配置する問題ではありません。私有トランク無線技術にはすでにいくつかの異なる標準が含まれており、PoC市場はさらに細分化されています。

単一の標準化された無線環境とは異なり、公衆網プッシュツートークプラットフォームはサプライヤー間で大幅に異なる場合があります。多くのシステムは、ベンダー独自のプラットフォームアーキテクチャ、シグナリングロジック、およびアプリケーション要件に従って開発されています。その結果、端末インターフェースとソフトウェアインターフェースは、あるPoCシステムから別のシステムへと必ずしも一貫しているわけではありません。

この完全に統一されたインターフェースの欠如が、統合プロジェクトにおける主な困難を生み出します。あるPoCプラットフォームで機能する統合方法が、別のプラットフォームでも自動的に機能するとは限りません。アーキテクチャを選択する前に、既存の私有無線機器、ゲートウェイインターフェース、プラットフォームソフトウェア、および相互接続に必要なチャネル数をすべて考慮する必要があります。

現在、2つの統合アプローチが最も実用的です。1つ目は、ゲートウェイの両側で物理的な無線端末を使用します。2つ目は、プライベートネットワーク側で無線ベースのアクセスを維持しながら、ゲートウェイをプロトコルインターフェースを介してPoCソフトウェアプラットフォームに直接接続します。

幅広い互換性のためのバックツーバックアクセス

2つのシステムが異なる標準を使用している場合、または直接のソフトウェアインターフェースが利用できない場合、バックツーバック統合がより汎用的なアプローチです。

このアーキテクチャでは、1つのゲートウェイインターフェースがPoC無線端末に接続され、別のインターフェースが私有無線端末に接続されます。ゲートウェイは、2つのポート間にオーディオおよび制御パスを作成します。一方の側で通信を受信すると、他方の側に転送できるため、両方のネットワークのユーザーが同じ音声チャネルに参加できます。

単一チャネルの場合、構造は次のように簡略化できます：

PoC無線機 → 相互運用ゲートウェイ → 私有無線機

複数のチャネルを相互接続する必要がある場合は、同じ概念を拡張できます。必要な各チャネルに対してPoC無線機と私有ネットワーク無線機がペアリングされ、複数のペアが個別のゲートウェイポートに接続されます。その後、ゲートウェイの設定により、どのポートが相互に通信するかが決定されます。

この設計には重要な実用的な利点があります。2つの専有プラットフォーム間での深いソフトウェア開発を必要とする代わりに、主に無線端末自体に依存します。したがって、システムインターフェースが利用できない場合、プロトコルが互換性がない場合、またはプロジェクトが既存の機器を接続するための比較的直接的な方法を必要とする場合に使用できます。

両方の無線ネットワークがすでに運用されており、いずれかのプラットフォームを交換することが非現実的な改造プロジェクトに特に役立ちます。

端末ベースのブリッジの限界

バックツーバック方式の広い互換性にはトレードオフがあります。通信は物理端末を通過するため、最終結果は部分的にそれらの端末の動作およびオーディオパフォーマンスに依存します。

私有無線側では、プロフェッショナルな携帯型および車載無線機は、一般的にアクセサリおよび外部通信機器との統合向けに設計されています。成熟した私有無線製品は、通常、ゲートウェイ接続に比較的適したインターフェースを提供します。

PoC側は予測が難しい場合があります。公衆網プッシュツートーク製品は多くのプラットフォーム設計と端末タイプをカバーしており、それらすべてに共通する単一の外部アクセス実装はありません。したがって、端末ベースの接続の品質は、特定のPoC無線機がオーディオ、プッシュツートーク制御、および外部インターフェースをどのように処理するかに依存する可能性があります。

遅延も別の考慮事項です。バックツーバック構成では、通信は一方のシステムの端末を介して転送され、ゲートウェイで処理され、その後もう一方のシステムの別の端末を介して送信されます。この追加のリレープロセスは、直接のソフトウェアレベル接続よりも多くの遅延をもたらします。

この方法はその互換性のために価値がありますが、プロジェクトはすべてのPoC端末が同じように動作すると仮定するのではなく、実際の音声パフォーマンスを評価する必要があります。

直接プラットフォームアクセスによるリレーステップの削減

PoCプラットフォームが統合ゲートウェイと直接統合できるインターフェースを提供する場合、2番目のアプローチが利用可能です。

公衆網プッシュツートークシステムはソフトウェアベースのプラットフォームであり、多くはSIPに由来するまたは関連するシグナリングアーキテクチャを使用しています。したがって、SIPおよびAPI統合機能を備えた統合ゲートウェイは、相互接続された各チャネルに物理的なPoC無線機に依存する代わりに、互換性のあるPoCプラットフォームに直接接続できます。

アーキテクチャは次のように変わります：

PoCプラットフォーム ↔ SIP/API ↔ 統合ゲートウェイ ↔ 私有無線機または移動無線機

私有無線側では、ゲートウェイは無線機器が提供するインターフェースを使用して、既存の携帯型または車載無線機への接続を続けることができます。公衆網側では、シグナリングと音声がPoCソフトウェアプラットフォームと直接交換されます。

リレーパスからPoC無線機を削除すると、システムのいくつかの側面を改善できます。通信チェーンにおける端末依存の段階が少なくなり、音声の一貫性が向上し、追加の伝送遅延が減少します。直接プラットフォームアクセスは、物理的なPoC端末を介した外部接続よりも制御された統合ポイントを提供することもできます。

ソースアーキテクチャは、セキュリティと通話品質を直接プロトコル統合の利点として特定しています。通信が無線端末を介して完全にリレーされる代わりにソフトウェアインターフェース間で処理されるため、PoC側はシステムレベルの相互運用性のためのよりクリーンなパスを提供できます。

2つのアプローチの選択

いずれのアーキテクチャも普遍的に優れていると扱うべきではありません。正しい選択は、既存システムで利用可能なインターフェースとプロジェクトの運用目標に依存します。

バックツーバック統合は、互換性が主な関心事である場合に適しています。PoCサプライヤーがアクセス可能なソフトウェアインターフェースを提供しない場合、プラットフォームプロトコルが専有である場合、またはプロジェクトがより深いソフトウェア変更なしに既存システムを相互接続する必要がある場合に役立ちます。

直接プロトコル統合は、互換性のあるSIPまたはAPIインターフェースが利用可能な場合により魅力的です。PoCソフトウェアプラットフォームに直接接続することにより、設計は端末リレーステージを削減し、公衆網側でより低い通信遅延とより良い通話パフォーマンスを実現できます。

チャネル数も決定に影響します。バックツーバックシステムでは、複数の同時または独立したチャネルには通常、対応する端末ペアとゲートウェイポートが必要です。チャネル数が増えるにつれて、ハードウェア構造はより複雑になります。プラットフォームレベルのインターフェースは、PoCシステムが必要なソフトウェア統合をサポートする、よりクリーンなアーキテクチャを提供できます。

したがって、プロジェクト評価では以下を検討する必要があります：

• 使用中の私有無線技術（PDT、DMR、TETRAなど）。

• PoCプラットフォームと、それがSIP、API、またはその他の利用可能なソフトウェアインターフェースを提供するかどうか。

• 相互接続が必要な無線チャネルの数。

• 既存の携帯型または車載無線機が適切なゲートウェイインターフェースを提供するかどうか。

• 許容可能な通信遅延のレベル。

• 必要な音声品質と運用信頼性。

• 将来の拡張で追加のチャネルまたはシステムが追加される予定かどうか。

導入前にこれらの項目をレビューすることで、ゲートウェイが孤立したハードウェアコンポーネントになることを防ぎ、完全な相互運用性アーキテクチャの一部として選択されることを保証します。

完全なプロトコル統合が一般的でない理由

理論的には、公共および私有システムは、より深いプロトコル間開発を通じて相互接続することもできます。無線端末を接続したり、利用可能なSIP/APIインターフェースを使用したりする代わりに、両方のプラットフォームをより深いソフトウェアレベルで変更または統合できます。

ソース資料は、このアプローチを実用的なプロジェクトではあまり一般的でないとしています。深いプロトコル統合には、広範なカスタマイズと異なるシステムサプライヤー間の調整が必要になる場合があります。開発リスクとプロジェクトコストが高くなり、ベンダー間の商業協力が別の障害になる可能性があります。

これらの理由から、完全なカスタムプロトコル統合は、2つのゲートウェイベースのアプローチよりも実際の導入が少なくなっています。

ゲートウェイ統合は、システム間に管理可能な境界を提供します。各ネットワークは元の役割を続けることができ、統合レイヤーがそれらの間で必要な通信パスを処理します。

実用的な統合ソリューションの構築

公共・私有統合は、既存の私有ネットワークの強みを弱めることなく通信機能を拡張する場合に最も価値があります。

私有トランクシステムは、予測可能な低遅延と信頼性の高い無線運用を必要とするユーザーにとって、重要な通信基盤であり続けることができます。PoC通信は、オペレーターの4Gおよび5Gネットワークを介してカバレッジを拡張し、追加のユーザーや遠隔地が私有無線インフラストラクチャをどこにでも必要とせずに参加できるようにします。

相互運用ゲートウェイはこれらの環境の間に位置し、必要な通信ブリッジを作成します。直接プラットフォームインターフェースが利用できない場合、バックツーバック無線アクセスは広く適用可能な接続方法を提供します。PoCプラットフォームがSIPまたはAPI統合をサポートする場合、直接ソフトウェアアクセスは公衆網側を簡素化し、不要なリレーステージを削減できます。

このアプローチは、既存の専門無線ネットワークを維持しながら、ブロードバンドプッシュツートークサービスを段階的に導入する必要がある組織に適しています。あるテクノロジーから別のテクノロジーへの完全な移行を強制する代わりに、このソリューションは公共および私有ネットワークが互いに補完し合うことを可能にします。

結論

公衆網PoCと私有トランク無線は異なる通信問題を解決します。PoCは既存の4Gおよび5Gオペレーターインフラストラクチャを使用して迅速な展開、広いカバレッジ、およびブロードバンド通信機能を提供し、PDT、DMR、およびTETRAシステムは、低遅延、高信頼性、およびセキュリティが不可欠な重要な通信において引き続き重要な役割を果たします。

したがって、実用的な統合ソリューションは、置き換えではなく相互運用性に焦点を当てています。バックツーバックゲートウェイ統合は、ペアリングされたゲートウェイポートを介してPoC無線機と私有無線機を接続することにより、幅広い互換性を提供します。直接SIPまたはAPI統合は、プラットフォームが適切なソフトウェアインターフェースを提供する場合に物理的なPoC端末を通信パスから削除し、音声パフォーマンスを向上させ、リレー遅延を削減します。

ほとんどのプロジェクトでは、これら2つのアーキテクチャは深いカスタムプロトコル開発よりも実用的な道を提供します。最終的な設計は、すでに導入されている無線標準、PoCプラットフォームインターフェース、チャネル要件、遅延の期待値、および通信システムに計画されている将来の拡張の規模に基づくべきです。

よくある質問

組織は既存の私有無線システムをシャットダウンせずにPoCを導入できますか？

はい。ここで説明する統合アプローチは、私有無線インフラストラクチャの即時交換を要求するのではなく、既存の私有トランクネットワークとPoCシステムが共存できるようにすることを目的としています。

単一のゲートウェイチャネルで全ての導入に十分ですか？

常にそうとは限りません。バックツーバック設計では、通信する必要のあるチャネルに対してペアリングされた公共および私有無線端末を使用します。複数の独立したチャネルを必要とするプロジェクトは、それに応じてゲートウェイ接続を計画する必要があります。

すべてのPoCプラットフォームが同じSIPインターフェースを提供しますか？

いいえ。ソース資料は、PoCプラットフォームが単一の統一された実装標準を形成していないことを強調しています。したがって、プロジェクトで使用される特定のソフトウェアプラットフォームとの互換性を確認する必要があります。

携帯型無線機と車載無線機の両方が私有側の統合に参加できますか？

デバイスがゲートウェイ接続に適した外部インターフェースを提供する場合、私有無線の携帯型および車載機器を使用できます。正確な実装は、設置された無線機器で利用可能なインターフェースに依存します。

プロジェクトが完全にカスタマイズされたプロトコル接続を避ける理由は何ですか？

深いプロトコル開発には、より高いカスタマイズ作業、開発リスク、実装コスト、および異なるサプライヤー間の調整が伴う可能性があります。これらの要因により、ゲートウェイベースの統合方法と比較してその使用が制限されています。