TOP

製品・ソリューション
通信テスト製品

通信テスト製品

Performance Testing Not Optional

機器ベンダーは通常、ノード開発の初期段階においてファンクショナル・テストが最も重要な工程であると考えます。プロジェクト全体においても開発リソースの大部分をファンクショナル・テストに費やすことはあっても、パフォーマンス・テストに同等かそれ以上のリソースを費やすことは稀有であり、パフォーマンス・テストをオプションであると考えるベンダーすら散見されます。しかしながら、実際には出荷製品の最終品質を担保する上でパフォーマンス・テストはオプションではあり得ません。パフォーマンス・テストは高負荷時のみ発生する問題だけでなく、ファンクショナル・テストでは見つけることが出来なかった機能的な問題すら発見してくれる「最後の砦」といえるでしょう。したがって、パフォーマンス・テストを実施していない製品は「完全品質を持つ」と呼ぶには程遠いといわざるを得ません。実際にサービスを開始してからフィールドで発生した問題を解決することで必要となるOPEXより、これを回避するために開発工程で十分にパフォーマンス・テストを行うためのCAPEXの方が、はるかに低いことは自明です。したがってパフォーマンス・テストはベンダーだけでなく、加入者の最終的なサービス満足度の極大化を目指すオペレーターにこそ重要な工程であるといわざるを得ません。

Figure 1 :  Positioning of Functional and Performance Testing

Performance Testing Needed at Every Release

ファンクショナル・テストは最初のバージョンの初期工程で集中的に行われますが、パフォーマンス・テストはバージョンアップごとに使用され、長期間にわたって必要となります(Figure 2のVer1)。二番目以降のリリース(Ver2・Ver3・・・)においては、改版部分のみについてファンクショナル・テストが行われるだけですが、パフィーマンス・テストは製品の改版部分が他の機能に性能的な影響を与えていないかを確認する上でより重要となってきます。パフォーマンス・テスターは定期的に継続するバージョナップにおいて最終品質を担保してくれる大変重要なツールであるといえます。

Figure 2 :  Performance Testing at Every Release

Performance Testing Finds More Critical Issues

ファンクショナル・テストは「再現しやすく」かつ「解決しやすい」機能的な問題のみを発見してくれます。開発の初期工程では確かに重要な役割を担いますが、後工程で行うパフォーマンス・テストは性能に関わるより「クリティカル」な問題を高負荷状態で発見してくれます。高負荷状態で発見される問題は解決の難易度が高く、長い時間を要するのが普通です。パフォーマンス・テストで発見されるクリティカルな問題は以下のように分類することができます。

  1. 複数UEの多重化における機能的問題
  2. 要求条件まで達していない限界性能
  3. 限界性能稼動時の各機能ブロック単体の安定性
  4. 機能ブロック間通信におけるクリティカルなタイミングにより発生する問題
  5. 稼働持続性

Figure 3 :  LTE eNB Function Block

Performance Testing Needed at Every Release

Artiza LTE Testersは世界中のベンダーやサービスオペレーターに使用され、サービス開始前において多くのクリティカルな問題を発見しています。Table 1.はArtiza LTE Testersによるパフォーマンス・テストで発見されてきた代表的なLTE eNBの問題例を記載しています。

Typical Problems Found on Performance Testing by Artiza LTE eNB Tester

NoeNB Problem DescriptionDetectedTDD/FDD
1No RACH response on a number of simultaneous RACH preambleDetected by MAC statistics on UE-SIMTDD
2RRCConnectionReject on a number of simultaneous attach sequenceDetected by Message Monitor on UE-SIMTDD
3Teardown on S1 and Uu by UL rate exceeding a thresholdDetected by Message Monitor on UE-SIMTDD
4No radio transmission after 72-hour sustainability testDetected by UE-SIM SIR monitorTDD
5Occasional no return of RAR with multiple UE connectionsDetected by Message Monitor on UE-SIM. eNB shows CPU usage reaches 70%FDD
6Out of sync on DL transmission at 150 MbpsDetected by Message Monitor on UE-SIMFDD
7No retransmission on MAC/RLC layers with massive UE connectionsDetected by MAC/RLC statistics on UE-SIMFDD
8No UL grant assignment for a number of simultaneous UE connectionsDetected by MAC statistics on UE-SIMFDD
9No attach completion with Burst GenerationDetected by Message Trace and MAC statistics on UE-SIMTDD
10eNB halt/reboot during 12-hour sustainability testDetected by statistics on UE-SIM and S1/X2-SIMFDD








NoeNB Problem
Description
Detected
 
TDD/FDD
1No RACH response on a number of
simultaneous RACH preamble
Detected by MAC statistics on UE-SIM
 
TDD
2RRCConnectionReject on a number of
simultaneous attach sequence
Detected by Message Monitor on UE-SIM
 
TDD
3Teardown on S1 and Uu by
UL rate exceeding a threshold
Detected by Message Monitor on UE-SIM
 
TDD
4No radio transmission after 72-hour
sustainability test
Detected by UE-SIM SIR monitor
 
TDD
5Occasional no return of RAR
with multiple UE connections
Detected by Message Monitor on UE-SIM.
eNB shows CPU usage reaches 70%
FDD
6Out of sync on DL transmission at 150 Mbps
 
Detected by Message Monitor on UE-SIM
 
FDD
7No retransmission on MAC/RLC layers
with massive UE connections
Detected by MAC/RLC statistics on UE-SIM
 
FDD
8No UL grant assignment for a number of
simultaneous UE connections
Detected by MAC statistics on UE-SIM
 
FDD
9No attach completion with Burst Generation
 
Detected by Message Trace and MAC statistics
on UE-SIM
TDD
10eNB halt/reboot during 12-hour
sustainability test
Detected by statistics on UE-SIM
and S1/X2-SIM
FDD
・・・・・・
 
・・・
 
・・・