では、テストの観点から見ると、これは何を意味しているのだろうか。簡単に言えば、O-RANが仕様から実装/展開へと移行する際に、相互運用性が重要な課題になることを示している。コンポーネントに相互運用性が必要になるだけでなく、仕様にも準拠する必要性が出てくる。また、O-DUとO-RU間の帯域幅の量を制御する上で、パフォーマンスも重要な領域となるだろう。
現在、多くのエンジニアはDUT(Device Under Test)に頭を抱えている。RFとイーサネットの両方に精通しているエンジニアは非常に少なく、それぞれ仕様の解釈が異なるため、その結果、実装も異なるのだ。
O-RUを担当しているエンジニアはタイミングの問題と、とりわけM-Plane(マネジメントプレーン)のバイパスの問題に対処している。O-RUとO-DU間のクロッキングと同期という課題もある。O-DU担当のエンジニアは、O-RUのエンジニア同様タイミングの課題と、処理関連のボトルネックに対処しなくてはならない。さらに、O-DUを仮想化した基地局でも従来の基地局でもホストできるようにする必要もある。
一方、O-CUでは、各CUがどれだけのDUやUEをサポートできるか、どれだけのスループットがあるかなど、スケーラビリティに関連した課題がある。さらに、中央ユニットのC-Plane(制御プレーン、Cu-CP)とU-Plane(ユーザープレーン、Cu-UP)を分離するには、E1インタフェース上での調整が必要になる。
こうした課題は、時間の経過とともに解決される初期の問題として見なすこともできるが、深刻な結果を招く可能性もある。例えば、特定のプロトコルオプションが欠落している場合や、M-Planeパラメータが満たされていない場合、DUはオプションであっても続行しない。
また、DUは特定のRU機能に対応するよう設計されている。通常、DUは特定のRUカテゴリー、ビームフォーミングモデルおよび圧縮率に対応しており、不一致があると動作を停止する。システム全体が機能するには、DUとRU間で多くの要素が一致している必要がある。こうした課題を克服するためのソリューションが利用でき、また今後もソリューションが増えることは、エンジニアにとって朗報だ。O-RANは複雑だが、これから普及していくだろう。
Copyright © ITmedia, Inc. All Rights Reserved.