Fronthaul Monitor
![](img/FHMonitor_Logo_BK.png)
![](img/FH_MONITOR_1920.png)
フロントホールパケットをキャプチャ/解析することでO-RUのデバッグを加速化
デジタル信号とアナログ信号を変換する無線ユニットは、相互接続性や柔軟なネットワーク構成を得る代わりに、ネットワーク処理やベースバンド信号処理を含む複雑な処理をする装置へと変化しました。これはRFの開発者にとっては喜ばしくないことです。なぜなら、自分の開発した装置の無線特性は、その複雑なネットワーク処理なしでは試験できないからです。
これは昔から存在する問題ですが、不具合を意図的に再現させるのは困難です。発生条件が分かったとしても、そのわずかな異常を時々刻々処理されるデータの中から拾い上げるのは困難です。もしキャプチャできたとしても、フロントホールのIQ信号の解析は容易ではありません。パケット単位に分割と圧縮され、C-PlaneやM-Planeと密接に連携して伝送されているからです。
我々のFH MONITORはこれらの課題を解決し、デバッグを助けるソリューションです。
![](img/FH_composition_2300x660.png)
特長
フロントホールパケットを長時間キャプチャ
キャプチャ時間を気にすることなく、毎試験のエビデンスを取得することができます。
予期しなかった不具合も漏れなくキャプチャし、不具合を再現させる労力が要らなくなります。
フロントホールパケットの異常検出と解析
本製品はFHの異常検出と解析機能を有します。
目視や自作スクリプトを使った干し草の中で縫い針を探すような作業から解放されます。
1つのサーバで実現されるソリューションにより巨大なキャプチャファイルの受け渡しが不要になります。
背景
各ベンダーはこれまで、独自の内部テスト手順を用いて、自社のサブシステムを組み合わせたE2Eのパフォーマンスをテストしていました。
これにより、パフォーマンスと相互運用性の課題が最小限に抑えられていました。
しかし、RANのOpen化によって新参者の参入、Best of Breed、Time To Marketの最適化、サプライチェーンリスクの軽減といった恩恵が得られる一方で、O-RAN テストは 3 つの重要なポイントに直面します。
1. ネットワークの複雑さの増加
O-RANの導入により、ネットワークの複雑さが増大し、テストとデバッグの課題が増大します。
2. マルチベンダーによる相互運用性
さまざまなベンダーが提供するコンポーネントとインターフェイスの相互運用性のテストが必要になります。
3. テスト戦略
ネットワークのトラブルシューティングと問題解決は困難なタスクとなり、適切なテスト戦略とデバッグ ツールの開発の必要性が浮き彫りになっています。
ネットワークの複雑性が増し、ネットワークがMulti vender化する中で問題解決を行っていくためには、次に述べる3つのstepでテストを実行し、各々のステップにおいて重要な段階を経ていく必要があります。
Conformance Testing
![](img/Step_1.png)
Step1:
ノード単体の評価を行い、機能担保を得ます。
Interoperability Testing
![](img/Step_2.png)
Step2:
隣接する2つのノード間を取り上げ、密接かつ複雑に接続するインターフェイスを接続し相互接続性を確認します。
End-to-End Testing
![](img/Step_3.png)
Step3:
ネットワーク全体の機能および可用性を負荷試験まで含めて確認を行っていく方法をとります。
仕様
ラインナップ | FH MONITOR |
---|---|
外観 | ![]() |
構成 | 1U |
ポート数 | 10GbE x 4ポート or 25GbE x 2ポート or 40GbE x 2ポート (オプション) or 100GbE x 2ポート (オプション) |
キャプチャ対応I/F | 10G Base-SR/LR 25G Base-SR/LR 40G Base-SR4/LR4 100G Base-SR4/LR4 |
キャプチャ性能 | 50Gbps |
キャプチャパケット | 64byte - 9600byte |
キャプチャ分解能 | 1ns |
ストレージ容量(実効) | 60TB |
RAID構成 | RAID 5 |
OS | Linux |
消費電力 | 550W |
寸法(W×H×D mm) | 437x43x597 |
重量(kg) | 約15kg |