LTE および EPC テストテストの概念および試験用ネットワーク全体および IRAT ハンドオーバー (HO) のパフォーマンスの把握 − ノード・ロギング機能の統合

アプリケーション・ノート

Web サイト : www.jdsu.com/test

LTE および EPC テストテストの概念および試験用ツールの概要

アプリケーション・ノート

具体的な LTE テスト領域 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

より深い理解のために . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

パフォーマンス・テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

シングルユーザー・スループット・テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

マルチユーザー・スループット・テストによるセルのパフォーマンス検証 . . . . . . . . . . . . . . . . . . . . . . 6

現実的なマルチユーザー・スループット・テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

アイドル・モードからアクティブ・モードへの遷移時間. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

遅延テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

KPI の検証と計算. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

LTE の音声の検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

シグナリングの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

音声の QoS と QoE (MOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

LTE のストリーミング・ビデオの QoS と QoE のテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

LTE の MIMO および周波数選択スケジューリングの評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ネットワーク・サービスエリアのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

LTE のハンドオーバーのテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

LTE バックホールの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

LTE 端末の IOT の検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

デバイス・コンフィグレーションの検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

目次

アプリケーション・ノート : LTE および EPC テスト - テストの概念および試験用ツールの概要 2

付録 : 基本フェーズ 1 LTE テスト計画の概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

実現可能なデータ転送速度と遅延 : UL/DL および TCP/UDP のシングルユーザー・スループット . . . . 20

実現可能なデータ転送速度と遅延 : UL/DL および TCP/UDP のセル・スループットと MU (マルチユーザ) スループット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

実現可能なデータ転送速度と遅延 : 遅延 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

LTE 内のモビリティ (移動性) : 移動性とハンドオーバーのパフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . 21

実現可能なデータ転送速度と遅延 : アプリケーションのパフォーマンス . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

サービスエリアおよび容量 : 無線機能の有効性と利得の評価 : リンク・バジェット . . . . . . . . . . . . . . . . . 22

サービスエリアおよび容量 : 無線機能の有効性と利得の評価 : スケジューラ . . . . . . . . . . . . . . . . . . . . . . . . 22

アンテナ構成オプションの評価 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

自己構成および SON (自己管理ネットワーク) 機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

周波数再利用の評価 : 1 つの展開シナリオ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

基本的な QoS : QCI が異なる非 GBR ユーザーの区別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

基本的な QoS : GBR ユーザーと非 GBR ユーザーの区別 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

基本的なアプリケーションのパフォーマンス : Web ブラウジング、ストリーミング、音声電話、電子メール、VPN、オンライン・ゲーム . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

EPS 仕様の参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3GPP の参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

NGMN の参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

ETSI の参考資料 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

用語集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29


具体的な LTE テスト領域

概要

LTE/SAE のテスト、評価、および最適化のための全体的なフレームワークの作成は、広範囲で複雑なトピックです。このアプリケーション・ノートは、1 つの出発点として、ある程度高いレベルからこのトピックを取り上げています。

LTE/SAE のようなテクノロジのライフサイクル全体を検討する場合、ライフサイクルの特定の時期における組織の優先度に合わせて、ツール、プロセス、および試験を調整する必要があります (図 1)。JDSU では、ライフサイクル全体にわたり資産の有効活用を可能にする、コスト効率に優れた一連のソリューションを提供しています。これにより、ライフサイクル全体をカバーするだけでなく、得られた結果と資産の再利用も可能になるため、確実な投資収益率 (ROI) を実現できます。

以下に示す各例は、LTE/SAE のサービス展開の各段階におけるテストのさまざまな側面に対応しています。これらは、LTE 展開におけるライフサイクルの主要要素となります。

• テクノロジ・フィールド試験

− NGMN または他の業界要件と比較したテクノロジの評価

− テクノロジ実装の試験と検証

− クローズされた 2 者間のフィールド試験ではなく、よりオープンなプロセスによる試験の実施• ラボ試験

− eNodeB のスケジューリング・パフォーマンスの評価

− セキュリティ・ポリシーと課金ポリシーの評価

− 制御された環境でのサービス・パフォーマンスの評価

− UE のパフォーマンスの評価

− MIMOによるパフォーマンス向上評価

• フィールド試験とベンダ評価

− エンド・ツー・エンド (E2E) パフォーマンス評価

− ネットワーク・カバレッジの評価

− 負荷条件下でのセルとノードのパフォーマンスの評価

− 自己管理ネットワーク (SON) 機能の評価

− IRAT の機能とパフォーマンスの評価

− KPI の監視とベンチマークの実行

図 1. LTE 展開におけるライフサイクルの単純なモデル

テクノロジ・フィールド試験ラボ試験

フィールド試験と

ベンダ評価

特定顧客による試験商用化開始

最適化とより広範囲な展開


• 特定顧客による試験

− エンド・ユーザーの QoE/QoS の把握

− 障害発生時のトラブルシューティング機能の確認

− 端末の IOT、コンフォーマンス、およびプレコンフォーマンス試験

− 端末パフォーマンスの監視

− 傾向、統計、および VIP レポートの組み込み• 商用化開始

− サービスおよびアクセス・テクノロジに即した監視機能の運用 − E2E (エンド・ツー・エンド) の可視性とトラブルシューティング機能の検証

− 加入者の振る舞いパターンの検証と把握 − ネットワーク全体および IRAT ハンドオーバー (HO) のパフォーマンスの把握 −ノード・ロギング機能の統合

• 最適化とより広範囲な展開

− SON 機能の動作の検証と保証

− 拡張するエリアの特定

− エンド・ユーザー QoE に対するバックホール・パフォーマンスの影響の監視

−マクロとフェムトの展開における両者のサービス・パフォーマンスのベンチマーク

このドキュメントの以降のセクションは、上記プロセスの "フィールド試験" の部分に焦点を合わせています。各セクションでは、ほとんどの通信事業者が実施すると思われるテスト・ケースについて説明します。また、これらのテストを効果的に行うためのツールの概要についても説明します。すべての通信事業者がすべての手順を実施するわけではないため、テスト・ケース (および考えられるソリューション) は、各々のニーズに合わせて変更を加える必要があります。

より深い理解のために

長年にわたり、アジレント・テクノロジー社の社員は、LTE/SAE のテクノロジの標準化とテスト開発に携わってきました。アジレント社では、2008 年以降、開発者による LTE/SAE の市場投入を支援するためのツールを積極的に提供してきました。2009 年 4 月に、同社は『LTE and the Evolution to 4G Wireless: Design and Measurement Challenges』 (ISBN: 978-0-470-68261-6) という包括的な書籍を刊行しました。この本は、ワイヤレス業界で好評を博し、幅広く支持されてきました。JDSU は、2010 年 5 月にアジレント社のネットワーク・ソリューション部門を買収しました。この買収により、この LTE に関する本に寄稿した数名の著者 (このアプリケーション・ノートの著者を含む) が、アジレント社から JDSU に移籍しました。この本は、アジレント社 (現在は JDSU) が、LTE/SAE

業界全体にどのように貢献しているかを示す一例にすぎません。この本のガイドとして、このアプリケーション・ノートでは、関連する参考資料を記載しています。LTE テストに関係するさまざまなトピックや概念について理解を深めたい場合は、これらの参考資料をご参照ください。


パフォーマンス・テスト

LTE では、エンド・ユーザーのスループット、遅延、アイドル・モードからアクティブ・モードへの遷移などの領域におけるシステム・パフォーマンスの強化に重点が置かれてきました。これらの機能改善は、高速なシングルユーザー・データ転送速度の実現という観点でマーケティング上重要ではありますが、商用展開された LTE ネットワークでの実際のユーザー利用形態においては、それ自体が果たす役割は限られています。そのため、実際にはシングルユーザーのピーク時の転送速度と同様にマルチユーザー環境でのスループットの測定をする必要があります。マルチユーザーのスループットとセルの能力を分析するときには、セル内の実際のユーザー分布の影響、およびそれらのユーザーの移動性と利用パターンを把握することが重要です。

シングルユーザー・スループット・テスト理論的には、シングルユーザー・スループット・テストは非常に単純です。ただし、実際には、このテストはかなり込み入っていることがわかります。一例として、まず、何を測定し、測定結果をどのようにベンチマークするかという点について理解しておく必要があります。

LTE SAE Trial Initiative (LSTI) の PoC (Proof of Concept : 概念実証) グループの公表結果を見ると、(たとえば、20 MHz の 2x2 MIMO システムで) ピーク時の転送速度は、セル端での数百 Kbps から、非常に良好な無線状態での 150 Mbps以上までさまざまであることがわかります。実際には、このような広範囲にわたる転送速度は、パフォーマンスが保証され、設定されたトラフィック・プロファイルに従ってトラフィックを正確に生成する、専用のハードウェア・トラフィック・ジェネレータを使用することで測定できます。このようなプロファイルには、さまざまなデータ転送速度、各種トラフィック、およびジッタなどの遅延特性が含まれます。他の代替方法としては、ソフトウェアベースのトラフィック・ジェネレータ (iperf など) や、FTP またはビデオ・ストリーミングに使用する既存の標準アプリケーション・サーバーからのトラフィックの生成などがあります。

ソフトウェアベースのトラフィック・ジェネレータを使用する場合は、信頼できる結果が得られる条件を理解しておくことが重要です。一般に、現在入手できるソフトウェアベースのトラフィック・ジェネレータでは、平均スループットは正しく生成されますが、瞬間的な変動がかなり大きい場合があります。また、高い転送速度を生成するには、ジェネレータで常に専用の CPU リソースを使用できる必要があります。一部のオペレーティング・システムではよくあることですが、トラフィック用 PC で他のプロセスが開始されてしまいバッファリングが予期せず発生することがあります。このような場合、EPC または eUTRAN において複雑な副次的影響が生じることがあります。結果として、生成されたトラフィックでギャップが生じ、エア・インターフェイスにおいて、所定の TTI 内で何も送信されない場合があります。

適切に管理されていない場合、既存のアプリケーション・サーバー (FTP サーバーなど) を使用してトラフィックを生成した場合にも、予期しない副次的影響が生じる可能性があります。たとえば、通常、FTP サーバーではハード・ディスクからファイルにアクセスします。複数のユーザーが同じファイルを同時にダウンロードしようとした場合、LTE エア・インターフェイス (良好な無線状態で) ではなく、FTP サーバーに起因するボトルネックが発生する可能性があります。適切に対処し、適切なディスク・システムを使用すれば、これをうまく処理するように FTP サーバーを設定できますが、ディスクが適切に構成されていないといった単純なミスがあると、全体的な結果にゆがみが生じるおそれがあります。

パフォーマンスの測定に関して言えば、必須の経験則の 1 つとして、結果に影響する基本的な事項を理解しておくことが挙げられます。たとえば、基盤となる無線層の伝送設定を理解しておくことが非常に重要です。HARQ を例にとってみましょう。HARQ が有効になっていない場合、HARQ を有効にしたときと比べて、良好な無線状態でのリンクのスループットが実際には向上します。一方、HARQ が有効になっていないと、信頼性のある伝送と呼ぶことはできません。HARQ が有効でない場合、大量の TCP 再送信などの問題が発生するため、実効スループットが大幅に低下します。HARQ を有効


にした場合でも、HARQ の再送信の量を構成できます。これを非常に小さな値に設定すると、瞬間的なスループットは向上しますが、理想的ではない無線状態では実効スループットが低下します。

ベアラのスループットを詳しく理解するには、適切な再送信の実行後に、プロトコル・スタックの各層 (MAC 層、IP 層、および UDP または TCP 層) で測定を行う必要があります。これらの測定時に、MAC 層と TCP 層での実際の設定、およびサービス層またはアプリケーション層における特定の設定が適用されているかどうか (たとえば、TCP を使用するアプリケーションが一つの TCP フローを利用するのか複数利用するのか) を把握し、記録しておくことが重要です。

一部の極めて特殊なケースでは、LTE エア・インターフェイスで提供できる最高ビット・レートの測定が役立つ場合があります。この測定を行う場合、推奨される方法は、持続的な UDP ストリームにおいて無損失状態での測定 (パケット損失のないスループットなど) をすることです。このような場合、MAC 層の具体的な設定をUDP パケット・サイズと共に記録する必要があります。LTE 接続で RFC 2544 テストを実施すると、大きな付加価値が得られます。RFC 2544 テストでは、数種類のパケット・サイズとスループット速度で順次テストを行うことによって、各パケット・サイズにおける無損失スループットを特定することが可能です。

さまざまな環境でその時々にスループットが変化する理由を理解するには、スループット・テストの実行時に、一連の LTE 関連パラメータを記録しておくのが最良の方法です。これらのパラメータには、eNodeB によるスケジューリング決定のための情報 (すべてのランク (ワイドバンド (全帯域) とサブバンド) の CQI、PMI、ランク・インジケータなど)、および eNodeB で実施されたスケジューリング決定に関する情報 (選択された変調とコーディング、MIMO モードなど) が含まれます。アップリンクのパフォーマンスをテストする場合は、関連するパワー制御情報も記録する必要があります。

JDSU では、シングルユーザーおよびマルチユーザー・スループット・テストの計画、実施、結果の評価、およびレポートの提供に必要なすべてのツールとプロセスを提供しています。これには、E2E のトラフィックを生成するツールと、端末および関連するネットワーク・インターフェイスのデータを記録するツールの両方が含まれています。フィールドでテストする場合は、他のベンダから提供される信号源で、アップリンク干渉および他のセルのユーザーによって生じる負荷をエミュレートします。負荷はスループット速度に大きな影響を及ぼすため、現実的な評価の一部として含める必要があります。生成される干渉は、UL と DL の両方で、LTE エア・インターフェイスの典型的なものであるのが理想的です。ノイズ的な CDMA エア・インターフェイスを使用する UMTS では、白色雑音が許容されていましたが、白色雑音では LTE の OFDM および SC-FDMA 変調方式を特徴付ける周波数および時間におけるパワー変動を表現できません。急激な変動があると、スケジューラが錯覚を起こし、確実に伝送できるチャネル条件およびその後の変調とコーディング方式について、楽観的または悲観的な間違った予測を立てる可能性があります。JDSU のツールを使用すると、ネットワークの負荷が高まる前にこの影響を評価できます。

マルチユーザー・スループット・テストによるセルのパフォーマンス検証シングルユーザー・ケースで LTE システムのパフォーマンスを測定すると、マルチユーザー・ケースについてのより実際的な分析を行う際の基本的な知識を得ることができます。多くの場合、シングルユーザーのピーク時スループットのパフォーマンスは、複数ユーザーによるダウンロード実行中のセルの総スループットよりもかなり高くなることを理解しておく必要があります。LSTI その他によって実施された業界調査によると、セル全体に 10 人のユーザーが存在し、すべてのユーザーがフルバッファ・ダウンロードと比例公平スケジューラを使用する場合、セルの DL のスループットは、約 35 ～ 40 Mbps と予想されます (20 MHz の 2x2 MIMO を前提とした場合)。1、2

1. これらの予想値は、3GPP による以前のシミュレーションと比較的一致しています。2. "フルバッファ" という用語は、eNodeB が常に S1 インターフェイスからデータをスケジューリングしているという考え方を表しています。完全な RF 環境であり、スループット速度が最高である場合でも、リンクを完全に飽和状態にできるだけの十分なデータがバッファに常に格納されている必要があります。


基本的なマルチユーザー・テストを実行すると、予想数値を下回る値から、シングルユーザーのピーク時のパフォーマンスに近い転送速度まで、結果が大きく異なる場合があります。この大きな差は、eNodeB のスケジューリングの全体的な動作と、個々のユーザーの環境が主な要因となって生じます。したがって、再現可能な方法でテストを設定し、結果の有用性を確保し、同じネットワーク内の隣接セルや、別ベンダのネットワーク機器を使用した同様のテストと、比較することができるようにすることが重要となります。

複数のユーザーが存在するセルのパフォーマンスを検証するテストの設定プロセスは、手順が非常に多いためここでは詳しく説明できません。以下に、主な手順の概要を示します。

1. 徹底的な走行テストまたは歩行テストによりネットワークの信号品質の分布を評価し、CDF (累積分布関数) を構築する。a. 各セルの CDF が大きく異なる場合は、最終結果も大きく異なります。

b. CDF は、カバーされる地形の種類と、歩行または走行テストを実施した場所によって異なります。たとえば、屋内の場所が含まれている場合、屋外限定の走行テストに比べ、信号品質は低下します。

c. LTE データ・トラフィックの約 80% が屋内で生成されると予想されます。

2. 信号品質の CDF に従って適切なトラフィック・プロファイルを取得できるようUE を分散配置します。a. 分散配置の方法は、測定済みの CDF だけでなく、実ネットワークにおけるユーザーの予想分布にも一致している必要があります。たとえば、公共の場所 (空港やカフェなど) で、1 つのグループに複数のユーザーが配置されることが予想される場合は、一部のユーザーを同じパターンで配置することをお勧めします。

b. この種の分布により、さまざまな MIMO 条件がストレスを受けることがあります (マルチユーザー MIMO による利得など)。

3. 実際のネットワークで、計画された分布に従ってユーザーを配置します。a. 計画と完全に一致させることはほぼ不可能であると思われるので、指定されたエリアと類似する場所にユーザーを配置することが重要です。テスト期間全体を通じて、選択した場所の実際の無線状態が記録および保存されていることを確認します。

b. 一部のユーザーが移動環境に存在する場合は、制御可能な方法でこれを管理できることを確認します。

4. セルの DL 負荷を作成するために、隣接セルの DL で OCNG (OFDMA Channel-Noise Generation) が有効になっていることを確認します。

5. 隣接セルの UE から、現実的な UL 負荷が生成されていることを確認します。6. テスト用 UE へのトラフィックを生成し、各 UE がフルバッファでトラフィックを受信または送信するように設定されていることを確認します。

7. 各 UE の場所 (緯度と経度) など、試験開始時に確認された関連パラメータをすべて記録します。a. ネットワーク・インターフェイスからの関連トラフィックをすべて記録して、あらゆる条件ですべての UE にフルバッファが存在していることを確認します。

b. すべての UE がアクティブであり、個々の UE のスループット速度が予想値と比較して現実的なものであることを確認します。

8. UE の MAC 層、IP 層、および UDP または TCP 層の個々のスループットをすべて関連付けます。a. 1 つまたは複数の UE が移動中であった場合、各デバイスの環境のスケジューリングと特定の無線パフォーマンスに応じて、総スループットが時間と共に変化することがあります。


バッファが常に満杯であるとは限らない実際のネットワーク・シナリオでは、これはセルの実際のパフォーマンスをテストする現実的な方法とはいえません。代わりに、非常に特殊なシナリオで eNodeBがどのように振舞うかをテストすることになります。通常これは、ユーザーの特定分布時の最悪ケース・シナリオと見なすことできます。

現実的なマルチユーザー・スループット・テスト複雑であるにもかかわらず、フルバッファ・ダウンロード/アップロードを使用するマルチユーザー・テストには制限もあります。現実的なトラフィック・シナリオでは、ユーザーは、多くの場合 HTTP、音声、FTP、IM、電子メールなどから構成されるバースト的なトラフィック・プロファイルを持つことが予想されます。フルバッファの場合、接続が良好なユーザーはデータ転送速度が低いユーザーよりも多くのデータをダウンロードするため、結果に偏りが生じます。これはある程度は真実で、接続が高速になるほど、ユーザーが実行する操作が増加する傾向はあります。ですが、フルバッファの場合、極端に増加しすぎると考えられます。そこで問題となるのは、より現実に即したトラフィック・モデルとはどのようなものかということです。このテストを進める価値はあるのでしょうか？あるとすれば、どのような付加価値があるのでしょうか?この答えは、特定の通信事業者がその時点でテクノロジのどのフェーズにあるかによって異なります。通信事業者がベンダの選択を行おうとしている場合は、スケジューリング、必要な QoS を提供する能力、およびさまざまなユーザーに対する全体的な公平さの観点で機器が適切に動作することを確認するために、これは不可欠なテストであると言えます。

また、期待される QoS の提供やシステムにおける公平さの実現は、eNodeB にとって必ずしも困難なタスクではないことを理解しておくことも重要です。実際の難題は、期待される QoS を実現しつつ、セルの容量に影響するオーバーヘッド要因を最小限に抑えることです。

システムに存在する可能性がある特定の問題点を明確にするためのテスト案を以下に示します。

1. QoS のオーバーヘッド・プロビジョニング分析a. 6 ～ 10 人の静的なマルチユーザー・セルにおけるフルバッファ・ダウンロードの実行を設定します。

b. セルの全容量を測定します。

c. フルバッファ・ダウンロードで実現された転送速度 (Mbps) と同じ固定転送速度の UDP ストリームを使用するモバイル・ユーザーとして、1 人のユーザーを再割り当てします。

i. UDP ストリームの固定転送速度と一致するように、このユーザーの QoS パラメータを設定します。

ii. スループット速度が 2 ～ 5 Mbps の範囲内であることを確認します。

d. セルの全容量を測定します。

e. 5 つの手順で中程度の無線状態から劣悪な無線状態にユーザーを移動し、手順ごとにセルの容量測定を繰り返します。

f. プロビジョニングされた特定のデータ転送速度のセル端にユーザーを移動します。

g. セルの全容量を測定します。

まず、セル容量に影響を及ぼさずに提供できる帯域幅向けにプロビジョニングされた QoS を使用して測定し、さらに、この QoS を使用せずに測定したセルの容量との比較を行います。次に、セルの容量および保証された QoS に対するユーザーの移動による全体的影響を順に比較します。


2. 全体的なスケジューリングに対する現実的なトラフィックの振る舞いの影響をテストします。a. LTE ネットワーク用に想定されたユーザーの種類に対応する現実的なトラフィック・プロファイルを持つユーザーのグループ (6 ～ 10 人) を設定します。使用シナリオの例を以下に示します。

i. 30 秒間隔で 5 つの Web ページをダウンロードします。各ページには、ページあたり合計 1.4 MB の 20 個のオブジェクトが含まれています。

ii. サイズの大きいファイル (10 MB など) が添付された電子メールを受信します。

iii. 10 通の電子メール・メッセージを送信します。4 通には 2 MB のファイルを添付し、残りの 6 通にはそれぞれ 50 KB のデータだけを含めます。

iv. インターネット・ラジオ (256 Kbps) を聴きます。

v. FTP でサイズの大きい 7 つのファイル (合計 100 MB。オペレーティング・システムの毎月の更新プログラムと同様) のダウンロードをバックグラウンドで実行します。

vi. 保証された QoS ベアラで 12.2 Kbps を使用して、VoIP コールを 1 つ作成します。

テストの実行中に特定の条件で無線インターフェイスで輻輳が発生するように、テスト条件を設定する必要があります。以前に測定したセルの予想容量値を使用して、適切なテスト・ケース・パラメータを選択します。

b. ユーザーごとに一連のイベントを並行して発生させます。ただし、ユーザーには、それぞれ 10 秒ずつ時間のずれを持たせます。

c. 各ユーザーは、特定のセルの CDF で定義された特定の無線環境に配置されます。

d. UE によるトレースとネットワーク・ベースのプローブによりすべてのデータを記録して、テストを完了します。可能であれば、LTE の Uu インターフェイスのデータも記録します。

このデータを分析して、輻輳状態での実際の動作を明らかにする必要があります。保証された QoS トラフィック (VoIP) とインターネット・ラジオの静的 RTP ストリームは、品質が低下する可能性が最も高いため、この 2 つのサービスに対するスケジューラの影響を特に調査する必要があります。

簡単な基本測定は、テスト・シーケンス (無期限に実行できるインターネット・ラジオ・ストリームと VoIP セッションを除く) の完了に要した合計時間のベンチマークを実行することです。最小完了時間は、マルチユーザーのフルバッファ・ダウンロード・シナリオで以前に測定したパフォーマンスに基づいて、比較的簡単に計算されます。システムの全体効率を把握するには、この最小時間との差を分析する必要があります。

このテスト・ケースに移動性を追加すると、さらに詳しい分析を行うことができます。ただし、この分析はかなり複雑になる可能性が高いため、基本ケースとしては妥当とは言えません。

各プロセスにおける各レイヤの効率を把握するには、無線環境のスケジューリングとパフォーマンスのあらゆる側面を分析する必要があります。この分析は、スケジューリングを成功させる条件と、スケジューリングの問題を発生させる条件を明らかにするうえでも役立ちます。

JDSU では、これらの種類のテストを実施し、結果を分析するためのツールとプロセスを用意しています。JDSU のツールは、動作の特性を明らかにすることを助け、供給業者に対する、特性リストの取得・維持のための、競合ベンチマークおよび回帰テストを実行することが可能になります。

アイドル・モードからアクティブ・モードへの遷移時間LTE で期待される主な事項の 1 つに、エンド・ユーザーへの "常時接続" の提供があります。これは、アイドル・モードとアクティブ・モード間の迅速な遷移を保証することによって部分的に実現されます。RRC ステート・マシン全体が最適化され、発生し得る状態の数が最小限に抑えられるため、複雑さの低減、消費電力の削減、および遷移時間の短縮が実現されます。


アイドル・モードからアクティブ・モードへの遷移時間を測定するには、トラフィック全体のデータを測定に使用できるように、UE の動作を完全に制御できるか、関連するすべてのシグナリングを記録できる必要があります。

JDSU のツールでは、アイドル・モードからアクティブ・モードへの遷移時間、および他の関連するトランザクション時間とプロシージャ時間を測定できます。これらの測定は、モバイルによるトレース・データだけを使用して実行することも、LTE および EPC ネットワークのデータの組み合わせを使用して実行することもできます。後者の場合、統合された E2E 測定を行うことができます。

遅延テスト全体的なユーザー・エクスペリエンスは、エンド・ユーザーが受信できる帯域幅や、ネットワークでのアイドル・モードとアクティブ・モード間の迅速な切り替えの実現だけではありません。ユーザー・エクスペリエンスは、EPC および eUTRAN を通過するパケットの E2E の遅延にも依存しています。

KPI の検証と計算

JDSU の書籍『LTE and the Evolution to 4G Wireless: Design and Measurement Challenges』には、KPI、計算方法、および全体の手順について詳しく説明している節があります (Chapter 6 を参照してください)。そのため、ここでの KPI の説明は最小限に留めています。

残念ながら、"主要性能指標" および "KPI" という言葉は、一般に誤解され、誤用されるようになっています。最も基本的なレベルでは、KPI は統計値または測定値にすぎません。ただし、特定の統計値または測定値をパフォーマンスの重要指標と見なすことが可能な特定のサービスでは、KPI は試験目標や市場要求として扱われます。

"パフォーマンス" という用語も、テストのコンテキストによってまったく異なるものを意味する場合があります。たとえば、VoIP のサービス・パフォーマンスは、ジッタ、遅延、および破棄されたパケットという観点で測定できます。ネットワーク・パフォーマンスは、許容範囲内のジッタ、遅延、およびパケット損失でサービス提供可能な VoIP の同時使用ユーザー数で測定できます。したがって、品質またはパフォーマンスを測定する場合、重要な課題の 1 つは、結果を矛盾なく解釈できるような定義の共通認識を持つことです。

3GPP によると、一般に KPI は、アクセシビリティ (接続性)、リテイナビリティ (保持性)、インテグリティ (整合性)、可用性、およびモビリティ (移動性)の 5 つのカテゴリのいずれかに分類されます。このカテゴリが拡張されて、利用率およびユーザビリティの 2 つのカテゴリが含まれる場合もあります。

3GPP による KPI 標準化への取り組みでは、エンド・ユーザーが受ける品質 (QoS) に関する測定に重点を置いています。これらの測定基準は、顧客のネットワークへの接続、接続の維持、サービス利用に関する性能測定に特に関係しているため、通信事業者中心になる傾向があります。

KPI を正しく理解するためには、実際の測定対象の理解が欠かせません。ネットワークの各部分は、1 つのサービスの提供に関してそれぞれ異なる責任を担います。したがって、LTE 固有の KPI は eUTRAN 自体に焦点を合わせており、多くの場合、実際にはeNodeB によるそれ自身のパフォーマンス測定に依存しています。NEM (ネットワーク機器メーカー) の課題は、特に高負荷または最大容量で動作している場合に、eNodeB によって計算された KPI が正しいことを検証する方法を定義することです。NEM と WSP (無線サービス・プロバイダ) のもう 1 つの課題は、KPI の単なる監視から、問題のトラブルシューティングと原因の特定に移行することです。


各サービスは、KPI のカテゴリごとに、それぞれ別の QoS プロファイルまたは QCI ラベルを使用する場合があります。アクセス対象の各種サービスのパフォーマンスを識別するには、QCI ごとに測定を行います。サービスのエンド・ツー・エンドのユーザビリティと管理容易性を評価するために、これらの各カテゴリに追加の KPI を検討する必要があります。

適切に設計されたエンド・ツー・エンドのテスト・システムの重要な側面として、データ・ソース、および LTE/SAE ネットワークに存在する使用可能な監視ポイントが挙げられます。ここで説明する一部のトピックは、業界標準に既に含まれています。他の領域については、3GPP、ETSI、またはその他の業界団体による標準化への今後の取り組みに含まれるかどうかは未定です。

データ・ソースと監視ポイントのトピックでは、測定理論、基本的な物理法則、および LTE/SAE テクノロジの仕組みと展開方法に関する知識が必須となります。LTE/SAE と UMTS に共通する次の例を考えてみましょう。この例では、2 人のエンジニアがネットワークにおける RRC 接続の成功率を測定する必要があるとします。

• 走行テストの経験を積んだ 1 人目のエンジニアは、広いエリアでの RRC 接続設定の成功率を測定する、対象を絞った走行テストの依頼を受けました。測定点の数は、テスト期間と単位時間あたりの実際の試行回数に直接関係することは明らかです。この例では、エンジニアは RRC 接続の成功率を 98.5% と結論付けました。

• 2 人目のエンジニアは、ネットワーク・カウンタとリンク監視ツールを使い慣れています。そのため、このエンジニアはシステムからログを抽出しました。これにより、ネットワーク全体のすべての RRC 接続試行のレポートを入手できました。このエンジニアは、RRC 接続の成功率を 99.5% と判定しました。

1 パーセント・ポイントの差が生じているのはなぜでしょうか? この答えは、この説明の残りの部分の基礎となります。

結果のこの差は、データ・ソース (走行テスト、ネットワーク・カウンタ、またはリンク監視ツール) の不備によるものではありません。この差異は、2 人のエンジニアがそれぞれ別の角度から、異なるネットワーク手順を測定したことが原因で生じたものです。

• 走行テストの方法では、特定の時点でネットワーク内の特定の物理ポイントにおいて、単一の携帯電話から確認したネットワーク・パフォーマンスが分析されます。

• ネットワーク・カウンタとリンク監視ツールでは、すべてのトラフィックが対象となり、これらのツールの本来の監視対象であるシグナリングとユーザー・トラフィックがすべて記録されます。これが異なる基準枠となっています。つまり、ネットワーク上およびネットワーク監視ポイントで確認されたネットワーク・パフォーマンスが分析されることになります。

走行テストの場所が目的のネットワーク・サービスエリア外の場合、差が累積されていきます。結果として、ネットワーク・サービスエリアの外部で行われた RRC 接続要求は、走行テスト・システムでは記録されますが、ネットワーク・カウンタまたはリンク監視ソリューションでは記録されません。これは、ある重要な点を明示しています。つまり、広範囲に及ぶ走行テストでは、ネットワーク・カウンタやリンク監視ツールが提供できる情報以外の追加情報が提供されるということです。

最適化コミュニティでは、KPI を相互に比較するのは、KPI が同じデータ・ソースから取得されている場合か、KPI が正規化され、取得方法またはデータ・ソースに起因する偏りが排除されている場合に限られるということで、一般に合意を得ています。これは、比較が予期しない結果を示している場合に特に当てはまります。今日、比較が適切に行われていないことが、モバイル業界で最適化に関して根拠のない決定が下される最大要因の 1 つとなっています。有効な比較と意味のある最適化を実現できるのは、データ・ソースと監視ポイントに関する厳密で一貫性のある理解が事前に得られている場合に限られます。3

3. これは単に、基礎となる測定理論の問題であることに注意してください。特定の測定ツールが定義どおりに動作しないために、正しい結果が得られないという潜在的なリスクについて説明しようとしているわけではありません。


研究開発プロセスまたは最適化フェーズのどちらに関与している場合でも、LTE テスト計画を策定するときには、多くの場合、数種類の方法の中から選択する必要があります。コスト効率と結果の有効性が最も高い方法を選択することは、作業の各フェーズの初期に行う最も重要な意思決定の 1 つです。方法を選択したら、その方法の適用範囲に関する条件を定める必要があります。作業のあるフェーズに適している方法が、別のフェーズでは重大な欠点を持つ可能性が高いことに注意してください。つまり、データ・ソースから得られる結果は、ネットワークの展開フェースおよび保守の各フェーズでそれぞれ異なるため、基礎となる同じ KPI を使用するのが適切であることはほとんどありません。

この概念をわかりやすく説明するために、QoS と QoE を対比した場合について考えてみましょう。モバイル・ネットワークでエンド・ユーザーの IP トラフィックを監視することにより、トラフィック・フロー (TCP または UDP)、アプリケーション (音声、ビデオ、HTTP、電子メールなど)、および場合によってはパフォーマンスについて詳しく理解できます。UDP または TCP フローだけを監視すれば、エンド・ユーザーの QoE の近似値の推定に必要なエンド・ユーザーの QoS に関する十分な情報を得られると考える人もいます。次のシナリオに示すように、これはストリーミング・ビデオなどのアプリケーションには当てはまりません。

• あるユーザーが携帯電話でストリーミング・ビデオを観ていますが、エア・インターフェイスを介して全帯域幅を提供するには無線品質が不十分です。コア・ネットワークで UDP ストリームを測定したところ、RTP/UDP ストリームの品質低下は観測されませんでした。品質低下の観測に適した他の場所としては、エア・インターフェイス、ユーザーの携帯電話、および RLCの 2 つのエンド・ポイント間 (UE と RNC 間の UTRAN、または UE と eNodeB 間の LTE eUTRAN にある) の 3 か所があります。コアのネットワーク監視ツールでは、安定した高ビット・レート (良好な QoS) がレポートされましたが、エンド・ユーザーからは QoE が低いとの報告がありました。

• このシナリオを変更して、エンド・ユーザーのアプリケーションが品質を認識し、無線状態が不十分であるため、ビデオ・ストリーミング・サーバーがコーデックのビット・レートを変更する必要があることを信号で通知したと仮定します。この新しい RTP/UDP ビット・ストリームがネットワーク上に出現すると、ネットワーク監視ツールは、QoS ストリームのビット・レートが低下していることから、この変化を低い QoS ストリームとして位置づけます。一方、無線状態はこの調整されたビット・ストリームを配信するには十分であり、エンド・ユーザーの QoE が向上することになります。

このシナリオは、QoE の重要な要素がコア・ネットワークで測定されたビット・レートではなく、エンド・ユーザーに特定のサービスを提供するエンド・ツー・エンド機能であることを示しています。この場合、アプリケーション・ドメインによって、考えられる最高の QoE の実現が保証されます。したがって、エンド・ユーザーの QoE の正確な推定につながる適切な QoS 測定を行うには、アプリケーションを認識する監視ツールを使用する必要があります。

LTE の音声の検証

EPS の定義すべき項目の 1 つに、音声、CS UDI ビデオ、SMS、LCS、USSD などの回線交換サービスを管理する方法があります。通常、次の 4 つの代替方法が考えられます。

• CS フォールバック (CSFB)

• Voice over LTE Generic Access (VoLGA)

• Voice over IMS (VoIMS)

• 独自仕様

CSFB と VoLGA はどちらも標準化されているので、すぐにでも実装できます。その後、VoIMS が追随すると考えられ、長期的ソリューションとして一般に普及すると予想されます。これらの中で、EPS の CS フォールバックについては、以下に詳しく説明します。その他のオプションは簡単に取り上げます。


3GPP R8 でまだ仕様化されていない 1 つの側面は、音声コーデックの使用です。数種類のオプションが用意されていますが、合意が得られていないため、標準化のこの部分は R10 まで持ち越されると考えられます。先延ばしになっている主な理由の 1 つは、目的が明確ではないことです。つまり、品質を向上させる必要があるのか、あるいはコーデックの選択によって容量を改善する必要があるのかという点が明確になっていません。EPS の初期展開時のコーデックの選択は、UE ベンダ、通信事業者、および EPS プロバイダの三者間の合意に基づくことになると考えられます。初期展開時に AMR と AMR-WB を使用するという選択はめずらしいことではありません。

ITU では、G718 コーデックの定義を既に進めていることを理解しておくことが非常に重要です。 G.718 は AMR-WB を基盤としており、ほとんどの場合、AMR 7.95 Kbps と同じ容量で 12.65 Kbps の AMR-WB の品質が提供されます。つまり、G.718 では、通話遅延にほとんど影響を及ぼさずに回線容量を 57% 増加させることができるということです。詳しい説明はこのホワイト・ペーパーの範囲外であるため、このトピックの理解を深めるために、ITU-T Rec. G.718 の全文を調べることをお勧めします。

シグナリングの検証図 2 は、SS7 ネットワークとやり取りする LTE の IMS コール・フローの標準的な例を示しています。図に示すように、これは "SIP 限定" とは言えません。また、この簡略化された図では、一部の非常に重要な側面を把握することはできません。たとえば、ベアラの選択状況や、ベアラを特定の QCI にマップする方法などが示されていません。

標準に準拠しようとする意図があったとしても、Voice-over-LTE 実装の短期的分析が、1 つまたは複数のショートカットによる影響を受けることはほぼ間違いありません。分析を実行し、結論を下すときには、この点を考慮する必要があります。考慮すべき重要な点は、エア・インターフェイスでの ROHC の利用、E2E の通話でのコーデックの利用、UE がアイドル・モードの時の、ページング手順の統合、およびアクセス・テクノロジ間での移動性を管理する方法です。

呼設定

アイドル・モードからアクティブ・モードへの遷移

発 UE eNB MME 着 UEPSTNコア IMS

RACH スケジューリング時間の遅延

RACH プリアンブル

セキュリティ・モード・コマンド + RRC 接続

再設定

RRC 接続再設定完了

接続要求

接続設定

SIP INVITE

IAMIAM

COTCOT

ACM/CPGACM/CPG

SIP 183 Session Progress

SIP PRACKSIP 200 OK

SIP 200 OK

SIP 180 Ringing

SIP UPDATE

RRC 接続要求

RRC 接続設定

RRC 接続設定完了 +

NAS サービス要求

TA + スケジューリング

図 2. LTE の標準的な IMS コール・フロー (SS7 と接続)


音声の QoS と QoE (MOS)

音声の QoS とその結果である QoE については、多くの優れた出版物で取り上げられているため、このセクションでは詳しくは触れません。

全体としては、どのような条件下で何をテストするのかについて注意する必要があります。また、結果に影響する管理要素を理解しておくことも必要です。特定の QoS を提供するベアラを使用して特定の音声サービスをテストする場合、結果として生じる音声品質は、ベアラが提供する品質によって制限されることになります。

これは理論的には簡単に思われますが、E2E の構造を十分に理解していないと、ほぼすべての新しいテクノロジで重大かつ現実的な問題の原因となります。UMTS では、通常は BLER 目標が 1% の無線リンクを使用して、音声が配信されていました。一部の実装では、1% を最低限の品質目標として使用し、リソースが利用可能な場合には、これを上回る品質で配信していました。つまり、(利用可能なリソースの有無に関係なく) 設定された BLER 目標で BLER が常に維持される状況と、他の部分に対して品質を低下させることなく、実現可能な最高のサービスを提供するように BLER が調整される状況を比べた場合、無負荷状態のネットワークでの結果は、常に "柔軟性のある" 実装に有利に働くことになります。これは意図したテストの目的と一致するとは限らないため、音声品質テストの価値が下がり、場合によっては無用と見なされるおそれがあります。したがって、音声サービスに影響する基礎となる諸条件を理解し、それらの条件を完全に制御するか、使用されるパラメータを記録しておくことが非常に重要となります。これにより、変更や別の実装との間で結果のベンチマークを実行するときに、公正な比較を行うことできます。

JDSU では、E2E の音声品質テストの実行および、ネットワーク内部でのパッシブ測定による音声品質のベンチマークを実行できるツールを提供しています (図 3)。

eNB eNB

EPC

JDSU VoIP Office End

UE UE

Serving/PDN GW

EMS/NMS

JDSU J6804A DNA HD

JDSU J7830A シグナリング・アナライザおよび J6900A トリプルプレイ・アナライザ

JDSU E6474A ドライブテスト・システム JDSU E6474A ドライブテスト・システム

図 3. E2E の音声品質テストのネットワーク・アーキテクチャ


LTE のストリーミング・ビデオの QoS と QoE のテスト

ビデオ・サービスの QoS と QoE の監視は、既に説明した KPI の場合と同様です。つまり、これらの測定には、KPI のセクションで示した方法と問題点がすべて適用されます。ここでの説明は省略しますので、以前の説明を参照してください。

重要な点を 1 つ付け加えます。ビデオの QoS とその結果である QoE は、LTE および EPC の関連するすべての側面にわたって把握するようにしてください。対象ネットワークのトラフィック・フローが適切であれば、あるポイントでの実際の QoS を特定できるだけでなく、そのポイントよりもアップストリームのサービスも保証できます。一方、モニタポイントでのトラフィック・フローに問題がある場合は、アップストリームをさらに調査する必要があります。多くの場合、クライアントはジッタ・バッファを使用して、一定の量および種類の QoS 低下を補償できます。したがって、QoS の低下によって、必ずしも QoE が低下するわけではありません。

JDSU では、パッシブおよびアクティブ両方の観点で、ビデオの QoS と QoE を監視するさまざまな関連ツールを用意しています (図 4)。標準の IPTV と MSTV の両方がサポートされます。

LTE の MIMO および周波数選択スケジューリングの評価

HSPA システムに比べ、LTE の価値の多くは、MIMO と周波数選択スケジューリング(FSS) の有効活用によってもたらされます。多くの側面において、これらが実際のフィールド環境で実感できる付加価値を顧客にもたらすかという観点では、まだ実証されていないテクノロジです。これらのテクノロジの実質的な価値は、実際の展開シナリオ、トラフィック全体のモデリング、およびシステムの具体的な実装と構成の 3 つの要素で決まります。

理論的には、FSS などの機能により、システムのパフォーマンスを大幅に向上させることができます。ただし、実際には、スケジューリングの制御に使用するアルゴリズムによってパフォーマンスが制限されます。これは、サブバンド CQI レポートによるアップリンク・トラフィックの減少といった運用上のトレードオフや、eNodeB で実利用できるパフォーマンスなどの技術的要素に起因します。

Evolved Node B

Evolved UTRAN (E-UTRAN)

UE’s

Uu

Evolved Packet Core (EPC)

MME

S-GWP-GW

コア、サービス、IMS

PCRFMRF

インターネット

CSCFHSS

図 4. LTE のエンド・ツー・エンドの QoS/QoE (VoIP、IPTV、データ) 監視ツール


MIMO に関する限り、ある TTI 内でユーザーに提供される特定の MIMO 構成/伝送における測定や MIMO 使用状況は、通常、安定していないことを理解しておく必要があります。さらに、いくつかの測定を行うことだけで、MIMO の制御、モデリング、把握ができると期待するのは、一般に現実的とは言えません。結論として、2 つの重要な要素があることを知っておく必要があります。テクノロジーの面から、評価は統計的性質の観点からなされなければならないということ、そしてこれらのパラメータは大規模なサンプルを利用せず、1 つの離散測定から分析できるということです。

セルのサイズ設定、バックホール、および QoS プロビジョニングを適切に行うには、MIMO と FSS の実際の振る舞いの特性を把握することが不可欠となります。MIMO と FSS の統計的性質を詳細な TTI レベルで把握できるのは、適切なツールとプロセスを使用している場合に限られます。JDSU のツールと方法を使用すると、これらのことが全て可能になります。JDSU のツールにより、詳細な分析と特性評価を行うことができるため、実際の動作を明確に理解できます。

ネットワーク・サービスエリアのテスト

ネットワークの計画時には、モデリングを行い仮説を立てます。これらが不正確であると、計画外のカバレッジ・ホールや隣接セルへの不要な信号リークなどの望ましくない結果を招きます。計画/チューニング・プロセスの早期に、実際のネットワーク・サービスエリアと計画されているネットワーク・レイアウトを明確に理解しておくことで、計画/エンジニアリング・チームは、コスト効果の高いネットワークの展開/チューニングのための手法を作成できます。また、サービスエリアを早期に検証することにより、ネットワーク・パフォーマンスの CDF を作成できると共に、セルのパフォーマンスについての適切なテストを実施できるようになります。

JDSU では、RSSI、RSRP、RSRQ、RS_CINR など、詳細な RF サービスエリア測定機能を提供しています。これらの機能により、非常に複雑なネットワーク・トポロジにおいて多数の帯域を効率的に測定可能です。測定結果は、カスタム・ソフトウェアまたは業界標準のポスト処理・アプリケーションを使用して後処理できます。

LTE のハンドオーバーのテスト

サービスエリアのテストは、HO 検証とパフォーマンスの特性評価に密接に関係しています。HO のパフォーマンスを十分に把握するには、LTE でのハンドオーバーの基礎となる全体的な手順とプロセスをあらかじめ調べて、理解しておかなければなりません。一般に知られているようにに、LTE にはソフト・ハンドオーバーは存在しません。したがって、ハンドオーバーは常に、"Break-Before-Make" 方式 (移動前に通信が中断される方式) のハード・ハンドオーバーになります。この結果として生じるエンド・ユーザーの QoE への影響を把握し、最適化する必要があります。また、LTE のハンドオーバーを、エリアでのプロアクティブなサービス負荷管理に利用することが可能なので、ハンドオーバーのオーバーヘッドが eNodeB に及ぼす影響を理解しておくことも重要です。

ハンドオーバーには、同一 eNodeB 配下のセル間でのハンドオーバー、X2 データ転送のない異なる eNodeB のセル間でのハンドオーバー、および X2 データ転送によってデータ・トラフィックの中断を最小限に抑えることができるハンドオーバーの 3 種類があります。X2 データ転送機能は、eUTRAN ソフトウェアの今後のリリースで実装されると一般に認識されていますが、一部のベンダは、最初からこの機能を利用できるようにする可能性があります。

通常、UE は、HO 時に SFN を監視し、SFN が非連続か連続かを確認することでハンドオーバーの種類を区別します。

図 5 は、単一 eNodeB 配下の 2 つのセル間でのハンドオフのわかりやすい例を示しています。このプロットは、HO の前に BLER が増加し続けており、その結果として MAC 層のスループットが低下したことを示しています。HO の実行後 (RRC 接続再設定など)、MAC 層のスループットが増加し、BLER はレポートされていません。


シグナリングの観点から、コール・トレース (図 6) では、結果として生じた HO の中断時間 (約 12 ～ 35 ms) が明らかになっています。この分析では、UE (あるいは Uu プローブ（エアモニタ)または eNodeB フィード) のプロトコル・ログと、ネットワーク・リンク (S1、X2 など) のプロトコル・ログの両方をモニタする必要があります。

図 5. MAC のスループット(緑色の線) : RRC イベント前に低下、イベント直後に回復

図 6. コール・トレースによるHO 中断時間の解析


すべてのモバイル・テクノロジに言えることですが、ハンドオーバーを正常に完了させるのは比較的簡単です。ただし、最適化されたハンドオーバー/ネットワークを実現するためには、深い洞察力と最適化の優れた技術が必要です。

LTE バックホールの検証

LTE では、エンド・ユーザーに提供する帯域幅が大幅に増加します。したがって、ネットワークのあらゆる部分から、この帯域幅を利用できることが非常に重要となります。このために焦点となる大きな領域の 1 つは、セル・サイト (eNodeB) とコア・ネットワーク間のモバイル・バックホール・ネットワーク (通常はイーサネット) です。

JDSU がこれまでに立ち会ってきた LTE フィールド試験では、LTE 固有のテスト・ケース実施のために、モバイル・バックホール・ネットワークが利用されていました。LTE フィールド試験をスケジュールどおりに進めるには、イーサネット・バックホールを迅速かつ簡単に立ち上げることが不可欠となります。「JDSU NetCompleteサービス・アシュアランス・ソリューション - モバイル・バックホール」は、LTE 試験の実施に先立って、試験用セル・サイトでのイーサネット・サービスの検証を行うことができます。RFC-2544 標準に準拠した試験、および試験コストの削減は、複数セル・サイトでの試験の自動化やエンジニアの効率的な配備によって実現することができます。ただし、このようなテストは、LTE フィールド試験に固有のものではないため、このアプリケーション・ノートの範囲外となります。一般情報は、イーサネット・ネットワーク・インターフェイス・デバイスのテスト方法およびパフォーマンス監視方法を定義している、IETF の RFC 2544 (1999)、IEEE、ITU などから入手できます。

LTE 端末の IOT の検証

LTE の市場投入の初期フェーズにある各通信事業者にとって、LTE の端末やデータ・カードの適切な相互運用性を確保することが不可欠となります。これらは初期のデバイスですが、今後も急速に進化し続けると考えられます。したがって、これらの機能を理解し、端末と関連するネットワーク要素間の相互運用性を確保することが重要です。ユーザーの実際の動作やネットワーク展開の初期フェーズで見つかった問題が、プレコンフォーマンス・テストまたはコンフォーマンス・テストの結果に反映されることはほとんどないため、これらの結果に単純に依存することはできません。

LSTI などの業界フォーラムでは、最小限の機能セットおよび対応する IoDT/IOT テスト計画を定義しています。これらは、LSTI のメンバだけが LSTI の目的にのみ使用できます。そのため、メンバ以外が端末の相互運用性を確保するには、他の方法に依存しなければなりません。アジレント社は、LSTI のメンバとして、IoDT および IOT フェーズに大きく貢献してきました。この経験を通じて、アジレント社と JDSU の社員は、業界に対してより有効に貢献できます。

JDSU は、各インターフェイスの情報を分析して相互に関連付け、シグナリング・レベルでの期待される動作との相違点を解析する機能を備えた、シグナリング・アナライザなどの監視ツールを提供しています。JDSU ドライブテストアプリケーションでは、さまざまなアプリケーションやタスクを実行する端末を制御できます。これを、該当する RF パラメータ (フェージィング、MIMO プロファイルなど) の制御と関連付けることにより、効果的な LTE 端末相互運用環境を提供できます。適切かつ効果的に自動化すると、コスト効率の高い信頼性のあるテストが確実に実行されるので、資産を最大限に活用できます。


デバイス・コンフィグレーションの検証

LTE の一部は、まだ完全には標準化されておらず、デバイス・コンフィグレーションの有効な実行方法に関して、幅広い合意が得られているわけではありません。相互運用性テストが実施され後であったとしても、LTE サービスを早期に立ち上げた通信事業者は、ネットワーク設定、ソフトウェア、ネットワーク運用時の他の関連パラメータなど、端末と各パラメータをリモートで更新する必要があります。4

コンフィグレーション前・中・後の各フェーズでデバイスの動作を完全に把握できるようにし、コンフィグレーション環境を提供するために必要な E2E のすべてのシグナリングを理解することが非常に重要です。JDSU のツールを使用すると、コンフィグレーション前の状態を定性的に (すべての運用サービスのパフォーマンスなど) 分析することも、単純な良否判定テスト (どのサービスが動作しているか、または動作していないか) で分析することもできます。正しく構成されていないデバイスが存在する場合のネットワークの振る舞いを分析し、後にネットワーク全体の監視システムで使用するために文書化することができます。コンフィグレーション手順の実行中に、さまざまな種類のポジティブ/ネガティブ・テストを実施して、エラー状態をシミュレートしたり、特定の条件が満たされた場合にコンフィグレーションが成功することを確認したりできます。実際のネットワークでエンド・ユーザーのデバイスの状態を評価するのは難しいことが多いため、ネガティブな条件は特に重要です。

4. 従来の OTA システムの多くは、ショート・メッセージ・サービス (SMS) を基盤としていますが、LTE 環境で SMS を簡単に提供するには、CSFB IMS または VoLGA を使用する必要があります。ただし、これらはいずれも、相対的に複雑でエラーが発生しやすいテクノロジです。


付録 : 基本フェーズ 1 LTE テスト計画の概要

概要

このセクションでは、テクノロジとしての LTE の評価と、LTE インフラストラクチャ・ベンダの基本パフォーマンスの評価の 2 とおりに使用できるテスト・ケースの基本セットを示します。

ここで説明する基本テスト計画は、ほとんどのインフラストラクチャ・ベンダ向けに適合するよう考えられています。また、各ベンダの詳細テスト計画にも適合します。したがって、このセクションは通信事業者にとっても役立ちます。通信事業者は、テストの実施方法を示した詳細仕様の作成をベンダに依頼するときに、この計画を使用できます。その後、詳細なテスト計画がこの計画の目的と期待事項に適合しているかどうかを検証できます。整合性を維持しながら、全テストの実施、データ収集、分析、およびレポートを管理できるため、有効な評価を確保できます。

通信事業者がベンダの選択およびネットワーク展開に移行できるように、後に続くテスト・フェーズを提供できます。

このテスト計画案は、次の 8 つの主要な項目で構成されています。

• 実現可能なデータ転送速度と遅延• LTE 内のモビリティ (移動性)

• サービスエリアおよび容量• アンテナ構成オプションの評価• 自己構成およびSON (自己管理ネットワーク) 機能• 周波数再利用の評価• 基本的な QoS

• 基本的なアプリケーションのパフォーマンス

以下の「実現可能なデータ転送速度と遅延」には 4 つの項があり、「サービスエリアおよび容量」には 2 つの項があります。合計 13 個の各項目には、テスト計画の作成に簡単に活用できる基本テストの概要が示されています。

実現可能なデータ転送速度と遅延 : UL/DL および TCP/UDP のシングルユーザー・スループット

基本テストの概要 • さまざまな無線状態でのシングルユーザー・スループットを評価します。隣接セルとの間の UL および DL で 70% の負荷を生成します。

• TCP および UDP で UL と DL のスループット・テストを個別に実施します。静止状態で 30 秒間の平均スループットを測定します。TCP と UDP のテストでは、単純なスループットではなく、無損失 (lossless) スループットを測定する必要があります。

• ネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。

• テストの共通仕様に従って、未処理の結果と正規化された結果を提供します。


実現可能なデータ転送速度と遅延 : UL/DL および TCP/UDP のセル・スループットと MU (マルチユーザ) スループット

基本テストの概要 • テストの共通仕様に従って、セルの CDF を生成します。CDF 分布に従って、10 台の UE を配置します。• 10 台の UE が適切かつ典型的な場所に配置されていることを確認します。• 隣接セルとの間の UL および DL で 70% の負荷を生成します。• TCP および UDP で UL と DL のスループット・テストを個別に実施します。静止状態で 30 秒間の平均スループットを測定します。TCP と UDP のテストでは、単純なスループットではなく、無損失 (lossless) スループットを測定する必要があります。


• テストの共通仕様に従って、未処理の結果と正規化された結果を提供します。

実現可能なデータ転送速度と遅延 : 遅延

基本テストの概要 • さまざまな無線状態と負荷のシナリオで、エンド・ツー・エンドの遅延を評価します。• 負荷なしのシナリオ

− 場所およびパケット・サイズ (32、1000、1500 バイト) ごとに最低 100 サンプルについて、さまざまな無線状態でエンド・ツー・エンドの ping を実行します。

• 負荷ありのシナリオ − 隣接セルとの間の UL および DL で 70% の負荷を生成します。 − UDP 完全ダウンロードを使用して、良好な無線状態で 1 台の UE から同一セルの DL 負荷を生成します。 − UDP 完全アップロードを使用して、劣悪な無線状態で 1 台の UE から同一セルの UL 負荷を生成します。 − 場所およびパケット・サイズごとに最低 100 サンプルについて、さまざまな無線状態でエンド・ツー・エンドの ping (32、1000、1500 バイト) を実行します。


• RAN および EPC 遅延と、バックホール伝送遅延 (該当する場合) を提供します。

• 無線状態およびパケット・サイズごとに、未処理の結果と最小値、最大値、および平均値を提供します。

LTE 内のモビリティ (移動性) : 移動性とハンドオーバーのパフォーマンス

基本テストの概要• S1 単独と X2 転送の両方に基づいて、ハンドオーバーをテストし、結果を比較します。負荷状態と無負荷状態の同じセルをテストします。

− 両方 (S1 と X2) のテスト・ケースに同じ手順を使用 º 種類ごとに最低 20 回の HO のテストを繰り返します。 º DL と UL の TCP および UDP トラフィックでテストを順次実行します。 º HO の成功率を測定し、レポートします。 º コントロール・プレーンの HO 時間を測定し、レポートします。 º ユーザー・プレーンの HO 中断時間とパケット損失を測定し、レポートします。



• 負荷状態の HO のパフォーマンスについては、フルバッファの DL および UL を実行する両方のセルに、良好な無線状態で 2 台の UE を追加します。

• 他のセルの負荷は、DL で 70% にする必要があります。移動性ケースでは、UL 負荷は実用上の問題により不要です。

実現可能なデータ転送速度と遅延 : アプリケーションのパフォーマンス

基本テストの概要• アイドル・モードから、テストの共通仕様に基づき、Web サイトに接続してダウンロードし、さまざまな無線状態でダウンロード時間を測定します。各場所で最低 5 回は繰り返す必要があります。良好な無線状態からセル端の状態まで、最低 5 種類の無線状態 (10 種類を推奨) を対象にする必要があります。

• その他のセルの負荷は、UL と DL で 70% にする必要があります。• ネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。

サービスエリアおよび容量 : 無線機能の有効性と利得の評価 : リンク・バジェット

基本テストの概要• まず、静止状態でテストします。

− UE をセル中央付近に配置します。フルバッファを使用した UDP DL 転送を開始します。 − ユーザーを基地局から離します。これにより、経路損失が増加します。新しい場所で測定を繰り返します。 − セル全体にわたり、最低 10 か所でこれを繰り返します。大部分の場所で、無線状態が悪くなります。サービスエリアが失われるまで続行します。

• 移動状態で同じテストを繰り返します。セル中央からセル端まで走行し、テストを数回繰り返します。• ネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。

サービスエリアおよび容量 : 無線機能の有効性と利得の評価 : スケジューラ

基本テストの概要• 良好な無線状態の 4 台の UE を同等の無線状態のできるだけ近くに配置します。すべての UE の優先度と QoS の設定が同じであることを確認します。

• トラフィック特性として UE1=X、UE2=2*X、UE3=3*X、UE4=4*X を使用して、UDP の DL 負荷を設定します。ユーザーの総スループットがセルの容量を上回るように、X が選択されていることを確認します。

• 結果の特性を測定します。• UE を 4 か所に配置し、各 UE に対して同じ UDP ストリームのスループットを生成します。ユーザーの総スループットがセルの容量を上回っていることを確認します。

• 結果の動作を記録します。 − ネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。


アンテナ構成オプションの評価

基本テストの概要• 次のアンテナ構成で、シングルユーザー・スループット・テストケースと、マルチユーザー・セル容量テストケースを実行します。

− SIMO

− 2x2 MIMO

− 4x4 MIMO (オプション : ベンダで可能であれば実行)

自己構成および SON (自己管理ネットワーク) 機能

基本テストの概要• 最低 2 つの eNodeB が運用されており、対象のセルに隣接セルが存在しないことを確認します。

• O&M システムで、隣接セルまたは X2 インターフェイスが構成されていないことを確認します。

• eNodeB で ANR (Automatic Neighbour Relation) をアクティブにします。

• 隣接セルが定義されていないセルで、UE の電源を入れます。UE から周囲のセクタの信号強度がレポートされると、ANR 機能により、隣接セル・リストに隣接セルが追加されます。

• ハンドオーバーを実行します。

• O&M システムで、適切な隣接セルと X2 インターフェイスがすべて追加されていることを確認します。

• 新しい隣接セルとの間で HO を実行します。


周波数再利用の評価 : 1 つの展開シナリオ

基本テストの概要• セル端に UE を配置し (他のセルの負荷は 100%)、フルバッファ・ダウンロードを準備します。

− 他のセルの負荷がない状態で、TCP と UDP の 30 秒間の平均スループットを測定します。 − 他のセルの負荷が 50% の状態で、TCP と UDP の 30 秒間の平均スループットを測定します。 − 他のセルの負荷が 70% の状態で、TCP と UDP の 30 秒間の平均スループットを測定します。 − 他のセルの負荷が 100% の状態で、TCP と UDP の 30 秒間の平均スループットを測定します。


• さまざまな負荷条件下でセル端のパフォーマンスを比較し、同じ物理的な場所で負荷条件ごとに測定された SINR を比較します。


基本的な QoS : QCI が異なる非 GBR ユーザーの区別

基本テストの概要• 優先度が最も低い QCI を持つ UE (A) では、良好な無線状態で UDP トラフィックのフルバッファ・ダウンロードを実行します。

• 優先度が 2 番目に低い QCI を持つ UE (B) を中程度の無線状態に配置し、10 Mbps の UDP ストリームのダウンロードを実行します。

• 優先度が最も高い QCI を持つ UE (C) を中程度の無線状態に配置し、10 Mbps の UDP ストリームのダウンロードを実行します。

• (UE B と C で) 結果のスループットとパケット損失を測定し、実際の受信スループットと S1 および SGi のスループットをレポートします。

• 他のセルの負荷は、UL と DL で 70% にする必要があります。• ネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。

メモ : 輻輳の発生を確認するために、UE B と C のスループットを正規化することが必要な場合があります。

基本的な QoS : GBR ユーザーと非 GBR ユーザーの区別

基本テストの概要

前提 : N1 > N2 > N3 > N4 (ユーザー 1 の優先度が最も高く、ユーザー 4 の優先度が最も低い)

• 良好な無線状態で 4 台の UE を配置します。UE1、UE2、UE3、UE4 の GBR 値を使用して DL ベアラを構成します。すべての UE の場所で、X1、X2、X3、X4 の DL のスループットの総計がセルの容量を上回っており、X1、X2、X3 の総計はセルの容量に達していないことを確認します。

• UE1、UE2、UE3、UE4 の各クライアントへの UDP DL トラフィックを生成します。• 各 UE クライアントへのデータ転送を最低 30 秒間実行したら、DL 転送を停止します。• DL のスループットを測定します。• UE1、UE2、および UE3 の DL 転送速度が、定義済みの GBR 値 (それぞれ X1、X2、X3) 以上であることを確認します。

• UE4 (優先度が最も低いトラフィック) が最も悪影響を受けている (DL ビット・レートが UE4 の必要な DL-GBR である X4 に達しなかった) ことを確認します。

• UE4 の ARP 設定を変更して、最も高い優先度 (N1) を指定します。• 全 4 台の UE クライアントへの DL 転送の同時実行を繰り返します。• (すべての UE の中で優先度が最も低い) UE3 への DL データ転送速度が最も悪影響を受けている (データ転送速度が必要な DL-GBR に達していない) ことを確認します。

ユーザー UE1 UE2 UE3 UE4

GBR DL (Mbps) X1 X2 X3 X4

GBR UL (Mbps) Y1 Y2 Y3 Y4

MBR DL (Mbps) A1 A2 A3 A4

MBR UL (Mbps) B1 B2 B3 B4

ARP (各フローの Allocation and Retention Priority はすべて異なる)

N1 N2 N3 N4


• RF セルの容量を下回り、X1、X2、X3 の総計を上回るレベルで輻輳を発生させるために、S1 のダウンリンクのパフォーマンスを制限して同じテストを実行します。スループットが S1 のピーク時のスループット限界に達していないことを確認します。

− 限界は、VLAN チューニングによって実現できます。

基本的なアプリケーションのパフォーマンス : Web ブラウジング、ストリーミング、音声電話、電子メール、VPN、オンライン・ゲーム

基本テストの概要• 各ローカル環境の関連サービスを特定します。

−トラフィック量の多いローカル Web サイトを選択します。 º メイン・ページの容量 (画像を含む) が 1 ～ 5 MB。

− 通信事業者とローカル環境でサポートされている VoIP アプリケーション (Skype、Google チャット、MSN など) を選択します。

− モバイル環境で VPN を使用するローカルの法人顧客を選択します。VPN 接続のデータ転送速度は、エンド・ツー・エンドで約 2 ～ 10 Mbps であることが必要です。

− よく知られた次の 3 つのローカル・サービスを特定します。 º 要件の高い (低遅延) のオンライン・ゲーム º 高パフォーマンスの固定回線インターネット・サービス (xDSL、パケット・ケーブルなど)

º ストリーミング・ビデオ (RTP/UDP) サービス• 次のアクセス・テクノロジでアプリケーションを実行し、パフォーマンスを比較します。

− HSPA (最高のローカル商用サービス)

− 固定回線インターネット・サービス − 良好、中程度、および劣悪な無線状態の LTE

• LTE、および可能であれば HSPA と固定回線インターネット・サービスのネットワーク側および UE 側の、コントロール・プレーンとユーザー・プレーンの完全トレースを含め、適切なパラメータと条件をすべて記録します。

− 音声サービスの場合は、MOS を測定して比較します。 − ストリーミング・ビデオ・サービスの場合は、ビデオの MOS を測定して比較するか、親しいユーザーと主観的な品質比較を行います。

− オンライン・ゲームの場合は、経験豊富なゲーマーに主観的な意見を求め、E2E の遅延を測定します。• 各種アクセス・テクノロジ間での絶対的パフォーマンスと相対的パフォーマンスをレポートします。


参考資料

EPS 仕様の参考資料

3GPP の参考資料

3GPP TS 23.272: Circuit Switched Fallback in Evolved Packet System; Stage 2

3GPP TS 24.301: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3

3GPP TS 29.118: Mobility Management Entity (MME) – Visitor Location Register (VLR) SGs interface specification

TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

3GPP TS 21.905: Vocabulary for 3GPP specifications

3GPP TS 22.278: Service requirements for the Evolved Packet System (EPS)

3GPP TS 43.318: Generic Access Network (GAN); Stage 2


TS 24.301: Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3

TS 29.272: Evolved Packet System; MME and SGSN related interfaces based on Diameter protocol

TS 33.102: 3G Security; Security architecture

TS 33.203: Access security for IP-based services

3GPP TS タイトルプロトコルインターフェイス24.301 Non-Access-Stratum (NAS) Protocol for Evolved Packet System

(EPS); Stage 3EPS NAS S1-C

36.413 E-UTRAN: S1 Application Protocol (S1AP) S1-AP S1-C

36.423 E-UTRAN: X2 Application Protocol (X2AP) X2-AP X2-C

29.118 Mobility Management Entity (MME) -Visitor Location Register (VLR) SGs Interface Specs.

SGsAP SGs

29.168 Cell Broadcast Center Interfaces with the Evolved Packet Core; Stage 3

SBc-AP SBc

29.272 MME Related Interfaces Based on Diameter Protocol Diameter+ S6a, S6d, S13

29.274 Evolved General Packet Radio Service (GPRS)Tunneling Protocol for Control plane (GTPv2-C);

GTPv2-C S3-C、S4-C、S5/8-C、S10、S11-C

29.275 Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunneling Protocols; Stage 3

PMIPv6 S5, S8 (PMIP)

29.276 Optimized Handover Procedures and Protocols between EUTRAN Access and cdma2000 HRPD

S101-AP S101

29.277 Optimized Handover Procedures and Protocols between EUTRAN Access and 1xRTT Access

S102-AP S102

29.280 3GPP EPS Sv Interface (MME to MSC) for SRVCC Sv Sv

29.281 GPRS Tunneling Protocol User Plane (GTPv1-U) GTPv1-U S1-U、X2-U、S4-U、S5/8-U、S12-U


TS 33.210: 3G Security; Network Domain Security; IP network layer security

TS 33.401: 3GPP System Architecture Evolution (SAE): Security Architecture;

TS 36.300: Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2



TS 29.272: Evolved Packet System; MME and SGSN related interfaces based on Diameter protocol

TS 33.102: 3G Security; Security architecture

TS 33.203: Access security for IP-based services

TS 33.210: 3G Security; Network Domain Security; IP network layer security

TS 33.401: 3GPP System Architecture Evolution (SAE): Security Architecture;


TS 36.420: X2 layer 1 general aspects and principles

TS 36.421: X2 layer 1

TS 36.422: X2 signalling transport

TS 36.423: X2 Application Protocol (X2AP)

TS 36.424: S2 data transport

TS 29.281: GPRS Tunneling protocol for user plane (GTPv1-U)



TS 29.305: Interworking Function (IWF) between MAP-based and Diameter-based interfaces

TS 29.274: Tunneling protocol for Control plane (GTPv2-C); Stage 3

TS 23.060: General Packet Radio Service (GPRS); service description; Stage 2

TS 36.410: S1 layer 1 general aspects and principles

TS 36.412: S1 signalling transport

TS 36.413: S1 Application protocol (S1AP)

TS 36.414: S1 data transport


TS 29.281: GPRS Tunneling protocol for user plane (GTPv1-U)


3GPP TR 22.968: Study for requirements for a Public Warning System (PWS)

3GPP TS 22.168: Earthquake and Tsunami Warning System (ETWS) requirements; Stage 1

3GPP TR 23.828: Earthquake and Tsunami Warning System (ETWS), requirements and solutions

TS 23.060: General Packet Radio Service (GPRS); service description; Stage 2

TS 23.107: Quality of Service (QoS) concept and architecture

TS 23.203: Policy and Charging Control Architecture



TS 23.002: Network architecture

TS 23.003: Numbering, addressing and identification

NGMN の参考資料

www.ngmn.org/uploads/media/White_Paper_NGMN_Beyond_HSPA_and_EVDO.pdf

ETSI の参考資料

ETSI TS 102 250-1: Speech Processing, Transmission and Quality Aspects (STQ); QoS aspects for popular services in GSM and 3G networks: Part 1: Identification of Quality of Service aspects


用語集

AAA 認証 (Authentication)、権限付与 (Authorization)、およびアカウンティング (Accounting)

AMR 適応マルチレート (Adaptive Multi-Rate)

AMR-WB 広帯域適応マルチレート (Adaptive Multi-Rate WideBand)

APN アクセス・ポイント名 (Access Point Name)

ASP アプリケーション・サービス・プロバイダ (Application Service Provider)

BICC ベアラ非依存呼制御 (Bearer-Independent Call Control)

BLER ブロック・エラー・レート (Block Error Rate)

BSC 基地局コントローラ (Base Station Controller)

BTS 基地局 (Base Transceiver Station)

CAPEX 設備投資

CDF 累積分布関数 (Cumulative Distribution Function)

CDMA 符号分割多元接続 (Code Division Multiple Access)

CLID 発呼回線 ID (Calling Line Identification)

CLIP 発信者番号表示 (Calling Line Identification Presentation)

CS UDI Circuit-Switched Unrestricted Digital Information

CSFB 回線交換フォールバック (Circuit-Switched Fallback)

DL ダウンリンク (DownLink)

DMT データ・マイニング・ツールキット (Data Mining Toolkit)

E2E エンド・ツー・エンド (End-to-End)

eNodeB evolved NodeB。Node B は UMTS 基地局 (BTS) です。

EPC Evolved Packet Core

EPS Evolved Packet System

ESN 電子シリアル番号 (Electronic Serial Number)

ETSI 欧州電気通信標準化機構 (European Telecommunications Standards Institute)

eUTRAN evolved UMTS Terrestrial Radio Access Network。E-UTRAN または EUTRAN とも略されます。

FSS 周波数選択スケジューリング (Frequency-Selective Scheduling)

GGSN Gateway GPRS Support Node

GPRS 汎用パケット無線サービス (General Packet Radio Service)

GUI グラフィカル・ユーザー・インターフェイス (Graphical User Interface)

HA ホーム・エージェント (Home Agent)

HARQ ハイブリッド自動再送要求 (Hybrid Automatic Repeat Request)

HLR ホーム・ロケーション・レジスタ (Home Location Register)

HO ハンドオーバー

HTTP ハイパーテキスト転送プロトコル (HyperText Transfer Protocol)

IM インスタント・メッセージング (Instant Messaging)

IMS インスタント・メッセージング・サービス (Instant Messaging Service)

IMSI 国際移動電話加入者識別番号 (International Mobile Subscriber Identity)


IP-TV インターネット・プロトコル・テレビ (Internet Protocol Television)

IOT 相互運用性試験 (Inter-Operability Test)

IP インターネット・プロトコル (Internet Protocol)

IRAT Inter-Radio Access Technology

KPI 主要性能指標 (Key Performance Indicator)

LCS ロケーション・サービス (Location Services)

LSTI LTE SAE Trial Initiative

LTE Long Term Evolution

MGW メディア・ゲートウェイ (Media Gateway)

MIMO マルチ入力/マルチ出力 (Multiple-Input/Multiple-Output)

MSC 移動通信交換局 (Mobile Switching Center)

MSC-S 移動通信交換局サーバー (Mobile Switching Center Server)

MSS モバイル・ソフトスイッチ (Mobile Softswitch)

MSTV Maximum Service Television

NAI ネットワーク・アドレス・インジケータ (Network Address Indicator)

NE ネットワーク要素 (Network Element)

NEM ネットワーク機器メーカー (Network Equipment Manufacturer)

NGMN 次世代モバイル・ネットワーク (Next-Generation Mobile Networks)

OCNG OFDMA Channel-Noise Generation

OFDM 直交周波数分割多重方式 (Orthogonal Frequency-Division Multiplexing)

OPEX 運用費 (Operating Expenses)

OLAP オンライン分析処理 (Online Analytical Processing)

PCF パケット制御機能 (Packet Control Function)

PDSN-FA パケット・データ・サービシング・ノード-外部エージェント (Packet Data Serving Node, Foreign Agent)

PDSN-HA パケット・データ・サービシング・ノード-ホーム・エージェント (Packet Data Serving Node, Home Agent)

PoC 概念実証 (Proof of Concept)

PSTN 公衆交換電話網 (Public Switched Telephone Network)

QCI QoS Class Identifier

QoE 体感品質 (Quality of Experience)

QoS サービス品質 (Quality of Service)

QoSM サービス品質マネージャ (Quality of Service Manager)

RNC 無線ネットワーク・コントローラ (Radio Network Controller)

ROHC Robust Header Compression

RRC 無線リソース制御 (Radio Resource Control)

SAE System Architecture Evolution

SC-FDMA 単一搬送波周波数分割多元接続 (Single-Carrier Frequency-Division Multiple Access)

SCTP Standard Control Transmission Protocol

SFN 単一周波数ネットワーク (Single-Frequency Network)

SGSN Serving GPRS Support Node


SIP セッション開始プロトコル (Session Initiation Protocol)

SMS ショート・メッセージング・サービス (Short Messaging Service)

SON 自己管理ネットワーク (Self-Organizing Network)

STP 信号中継局 (Signaling Transfer Point)

TDR Transaction Detail Record

TTI 伝送時間間隔 (Transmission Time Interval)

UE ユーザー端末 (User Equipment)

UMTS ユニバーサル・モバイル・テレコミュニケーション・システム (Universal Mobile Telecommunications System)

UL アップリンク (Uplink)

URI Uniform Resource Indicator

USSD Unstructured Supplementary Service Data

VIP 重要人物 (Very Important Person)

VoIMS Voice over Instant Messaging Service

VoLGA Voice over LTE Generic Access

WAP ワイヤレス・アプリケーション・プロトコル (Wireless Application Protocol)

WSP 無線サービス・プロバイダ (Wireless Service Provider)


ジェイディーエスユー・ティーアンドエム株式会社 (JDSU T&M)

東京都新宿区西新宿 6-22-1 新宿スクエアタワー 7F 〒 163-1107 お問い合わせ先: 電話: 03-5339-6886 Fax: 03-5339-6889 Email: [email protected]

当社ホームページ: www.jdsu.com/jp をご覧ください。このドキュメントに記載されている製品仕様および説明は予告なしに変更されることがあります。© 2010 JDS Uniphase Corporation 30168200 500 0810 LTE EPCTEST.AN.NSD.TM.AE 2010 年 8 月

Documents

LTE および EPC テスト テストの概念および試験用 ネットワーク全体および IRAT ハンドオーバー (HO) のパフォーマンスの把握 − ノード・ロギング機能の統合

LTE および EPC テストテストの概念および試験用ネットワーク全体および IRAT ハンドオーバー (HO) のパフォーマンスの把握 − ノード・ロギング機能の統合