JP2023501874A - Ｒｓｐプロセスの検証のためのテスト方法、及びそのようなテスト方法を提供するアクティブテストシステム - Google Patents

Abstract

リモートｅＳＩＭプロビジョニングプロセスの検証のためのテスト方法において、テスト中のＲＳＰプラットフォーム（１）からのｅＳＩＭプロファイルが、注文される（８）。その後、ＲＳＰプラットフォーム（１）から注文されたｅＳＩＭプロファイルのダウンロードがトリガされる（９）。そして、トリガされたｅＳＩＭプロファイルが、ＲＳＰプラットフォーム（１）から無線通信インタフェースを介して、テストプローブ（６）のターゲットｅＳＩＭ又はｅＵＩＣＣ（５）へダウンロードされる（９ａ）。その後、注文され、トリガされ、ダウンロードされたｅＳＩＭプロファイルが正しいかどうかが検証される。テストプローブ（６）は、Ｍ２Ｍデバイス、スマートフォン及び／又は消費者向けＩｏＴデバイスをシミュレートするように構成されてもよい。このようなテスト方法は、ｅＳＩＭのスワッピングによってネットワークの接続性とサービスが継続的に提供される一方で、リモートｅＳＩＭプロビジョニングでモバイルネットワークをテストするためのテストシステムの能力を向上させる。

Description

本願は、ドイツ特許出願ＤＥ １０ ２０１９ ２１４ ９１９．７の優先権を主張し、その内容は、参照により本明細書に組み込まれる。

本発明は、リモートｅＳＩＭプロビジョニング（ＲＳＰ）プロセスの検証のためのテスト方法に関する。また本発明は、そのようなテスト方法を提供するアクティブテストシステムに関する。

モバイルネットワークのためのテストシステムは、例えば、特許文献１、特許文献２、及び特許文献３から知られている。特許文献４は、組み込み型加入者識別モジュール（ＳＩＭ）の監視を開示している。特許文献５は、組み込みＳＩＭプロビジョニングのための方法及びデバイスを開示している。特許文献６は、汎用集積回路カード（ＵＩＣＣ）のリモートアクセスを検出する方法を開示している。

ＵＳ １０，０９７，９８１ Ｂ１ ＵＳ ７，８３１，２４９ Ｂ２ ＷＯ ２００４／０４９７４６ Ａ１ ＵＳ ２０１９／００７５４４８ Ａ１ ＷＯ ２０１６／０１３８２７ Ａ１ ＷＯ ２０１７／０１３１２７ Ａ１

本発明の目的は、リモートｅＳＩＭプロビジョニングを用いてモバイルネットワークをテストするためのそのようなテストシステムの機能を向上させることである。

この目的は、請求項１又は２の特徴を含むテスト方法、及び請求項８の特徴を含むアクティブテストシステムによって満たされる。

組み込み汎用集積回路カード（ｅＵＩＣＣ）、又は組み込みＳＩＭ（ｅＳＩＭ）は、消費者向けＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）及びＭ２Ｍ（Ｍａｃｈｉｎｅ－ｔｏ－Ｍａｃｈｉｎｅ）デバイスに広く普及して使用され、モバイルネットワークに向けてデバイスを識別する。さらに、スマートフォン向けのｅＳＩＭも導入されている。ｅＳＩＭは次世代のＳＩＭ技術であり、物理カードをハードウェアとソフトウェアの組み合わせに置き換え、通信事業者（オペレータ）間でデバイスをリモートで切り替える機能を提供することを目的としている。この技術により、１つのデバイスで複数の接続プロバイダ（プロファイルと呼ばれる）をホストでき、スマートフォン及びＩｏＴモジュールを含むモバイルデバイスの全領域で使用できるように設計されている。

ｅＵＩＣＣカードのハードウェア部分は、主に組み込みフォームファクタ（ＭＦＦ２）で製造されている。ｅＳＩＭのソフトウェア部分は、リモートでダウンロードし、ｅＵＩＣＣカードにインストールできる。このプロセスは、リモートｅＳＩＭプロビジョニング（ＲＳＰ）と呼ばれている。この特許明細書で言及されるｅＵＩＣＣ又はｅＳＩＭという用語は、ダウンロードされるｅＵＩＣＣのソフトウェア部分として、「パーソナライズされた」ｅＵＩＣＣ又はｅＳＩＭと呼ばれる。ｅＵＩＣＣは、容易にアクセス又は交換可能できず、デバイスで取り外されたり交換されたりすることを意図しておらず、サブスクリプションの安全な変更を可能にする。

ＧＳＭＡは、Ｍ２Ｍデバイス及び消費者向けデバイスのそれぞれに対するｅＳＩＭプロビジョニングのための規格、
－ ＧＳＭＡ ＳＧＰ．０２ ｖ４．２， ２０２０年７月７日 － 組み込みＳＩＭのリモートプロビジョニングアーキテクチャ － 技術仕様書、
－ ＧＳＭＡ ＳＧＰ．２２ ｖ２．３， ２０２０年６月５日 － ＲＳＰ技術仕様書、
－ ＧＳＭＡ ＳＧＰ．０２ ｖ４．０， ２０１９年２月２５日 － 組み込みＳＩＭリモートプロビジョニングアーキテクチャ、
を規定している。
本発明によるテスト方法及びアクティブシステムは、移動体通信事業者、又はそれらのｅＳＩＭ対応デバイスのサードパーティに代わって、ｅＳＩＭがプロビジョニングされる際のテスト及び検証の側面をカバーするものである。

ＧＳＭＡによって規定されたさらなる規格は、
－ ＧＳＭＡ ＳＧＰ．２３ ＲＳＰテスト仕様書バージョン１．７， ２０２０年７月７日である。
ＧＳＭＡによって規定されたもう一つの規格は、
－ ＧＳＭＡ ＳＧＰ．２４ ＲＳＰコンプライアンスプロセスバージョン２．２， ２０１９年９月１７日である。

複数のプロファイルをダウンロードし、ｅＵＩＣＣにインストールできる。プロファイルは、事業者に関連付けられ、ｅＵＩＣＣにプロビジョニングされるか、ｅＵＩＣＣ上に存在するファイル構造、データ、及びデータの組み合わせであり、有効化されると、特定のモバイルネットワークインフラストラクチャへのアクセスを可能にする。一度にアクティブ化され動作可能なプロファイルは１つだけである。ｅＵＩＣＣのすべてのプロファイルは、事業者又はサードパーティに代わってｅＳＩＭ ＲＳＰプラットフォームによって、有効化、無効化、削除、又は一方から他方への切り替えを管理できる。

そのテスト方法及びアクティブテストシステムは、ＲＳＰプロセスのコンテキストでモバイルネットワークの接続性及びサービスを検証するエンドツーエンドのテスト方法を適用する。このテスト方法は、テストシステムでＲＳＰを検証し、以下の条件、
－ Ｍ２Ｍデバイス用のＧＳＭＡ ＳＧＰ．０２ ＲＳＰ、
－ 消費者向けデバイス用のＧＳＭＡ ＳＧＰ．２２ ＲＳＰ、
に従って、国内又は国際サービングネットワークでプロビジョニングされたＳＩＭを使用して、モバイルネットワークの接続性をテストする。

ｅＳＩＭプロファイルは、具現化されたユニバーサル集積回路カード（ｅＵＩＣＣ）の、パーソナライズされたソフトウェア部分、すなわち、割り当てられたユーザに与えられたれたソフトウェアである。そのようなソフトウェアは、少なくとも１つのユーザプロファイルを含む。ＲＳＰプロセスは、例えばスマートフォン、スマートウォッチ、ウェアラブルなどの消費者向けデバイス、及び／又はＭ２Ｍ（マシンツーマシン）デバイスに使用してもよい。このテスト方法は、特に、モバイルネットワークの接続性とサービスを検証する。

ＲＳＰプラットフォームからのｅＳＩＭプロファイルの注文は、手動又は自動で行うことができる。注文の送信者は、モバイルネットワークオペレータ（ＭＮＯ）であってもよい。注文の前に、ＲＳＰプロセスを開始してもよい。テスト方法中に、以前の作業プロファイル又はｅＵＩＣＣに最初にインストールされたブートストラッププロファイルを無効にしてもよく、ダウンロードされたｅＳＩＭプロファイルが有効にされる。チェックは、少なくとも１つの失敗した基準の発生を監視することで実行してもよい。そのような失敗した基準は、ＲＳＰプラットフォーム接続タイムアウト及び／又はネットワークアタッチタイムアウトに基づいて、及び／又は注文、トリガ、及び／又はダウンロードの予想される構造に基づいて、及び／又はダウンロードされ、更新されたｅＳＩＭプロファイルを有するデバイスのリアタッチのタイムアウトに基づいて満たしてもよい。

テスト方法中に、ネットワーク接続性とサービスは、ｅＳＩＭスワッピングによって継続的に提供される。

請求項１に記載のテスト方法によれば、テストプローブは、Ｍ２Ｍデバイスをシミュレートする。

テストプローブは、２Ｇ、３Ｇ、４Ｇ及び５Ｇの無線周波数を含む、認可された帯域での大きな周波数スペクトルをサポートしてもよい。テストプローブのこのような構成により、ｅＳＩＭプロファイルを提供するリモートＲＳＰプラットフォームと、ｅＳＩＭプロファイルがダウンロードを介してプロビジョニングされるテストプローブとの間の効率的な通信方法として、ＳＭＳ（ショートメッセージサービス）を展開（デプロイ）できる。テストプローブは、４Ｇ及び５Ｇ技術用のＳＭＳｏＮＡＳ（ＳＭＳ ｏｖｅｒ ＮＡＳ （非アクセス・ストレータム））をサポートする場合がある。テストプローブは、ＩＭＳ（ＩＰマルチメディア・サブシステム）技術のＳＭＳｏＩＰ（ＳＭＳ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）をサポート場合がある。テストプローブは、通信技術環境に応じて正しい通信プロトコルを選択するように、すなわち、それぞれのＲＳＰプラットフォームのｅＳＩＭ検証に必要な通信プロトコルを適応させるように構成できる。テストプローブは、産業用ＩｏＴアプリケーションと通信するように構成してもよい。そのような産業用ＩｏＴアプリケーションの例は、ＬＴＥ－Ｍ（Ｌｏｎｇ－Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ ｆｏｒ Ｍａｃｈｉｎｅｓ）である。もう１つの例は、ＮＢ－ＩｏＴ（Ｎａｒｒｏｗ Ｂａｎｄ Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）である。テストプローブは、少なくとも１つのＬＰＷＡＮ（低電力ワイドエリアネットワーク）無線技術標準と通信するように構成されてもよい。

請求項２に記載のテスト方法によれば、テストプローブは、スマートフォン及び／又は消費者向けＩｏＴデバイスをシミュレートする。

テストプローブは、ユーザトランザクション関連のテスト基準をテストするように、すなわち、ユーザレベルでＲＳＰ検証プロセスをテストするように構成してもよい。そのようなユーザレベルテスト中に、テストプローブは、主要パラメータ指標（ＫＰＩ）によって定義され得る品質パラメータをチェックすることによって、品質テストステップを開始できる。このようなＫＰＩは、アクセス失敗率、アクセス時間、カットオフ率、ダウンロード開始時間、ダウンロード可用性率などであってもよい。このような品質パラメータは、テストプローブを介してリアルタイムでチェックできる。その点で、テストプローブは、スマートフォン及び／又は消費者向けＩｏＴデバイスのユーザの実際のユーザ動作をエミュレートするように構成してもよい。

消費者ＩｏＴデバイスの例としては、タブレット、スマートウォッチ、ウェアラブルコンピュータがあり、例えば、スマートグラス、家庭用音声コントローラ、ドアベルカム（カメラ）、スマートロック、スマートライトスイッチ、空気品質モニタなどが挙げられる。

請求項３に記載のサブスクリプション要求の送信エンティティは、モバイルネットワーク事業者のプロキシを使用してもよい。サブスクリプション要求は、リンク又はコードを含んでもよい。トリガステップ中に、注文の送信エンティティは、テストプロファイルからのサブスクリプション要求を確認してもよい。確認により、テストプローブをトリガして、注文されたｅＳＩＭプロファイルをダウンロードするためのダウンロードアドレスを検出してもよい。トリガオプションは、ターゲットｅＳＩＭに格納されたＳＭ－ＤＰ＋（サブスクリプションマネージャ・データプレパレーション）デフォルトアドレスを使用してもよく、ＳＭ－ＤＰ＋アドレスのＦＱＤＮ（完全修飾ドメイン名）の検出にルートＳＭ－ＤＳ（サブスクリプションマネージャ・ディスカバリサーバ）を使用してもよく、又はＳＭ－ＤＰ＋アドレスを含むアクティベーションコードを使用してもよい。

請求項４に記載の注文スケジュールは、ＲＳＰプラットフォームによって生成されるｅＳＩＭプロファイルの量を含んでもよく、ＩＭＳＩ値、複数のＩＭＳＩ値、又はＩＭＳＩ範囲を含んでもよく、ＩＣＣＩＤ値、複数のＩＣＣＩＤ値、又はＩＣＣＩＤ範囲を含んでもよく、非個人化プロファイルタイプ、又は複数の非個人化プロファイルタイプを含んでもよく、ターゲットｅＳＩＭ、又は複数のターゲットｅＳＩＭに関する情報、例えばＥＩＤ（ｅＵＩＣＣ－ＩＤ）などを含んでもよい。ＥＩＤは、順序付けられたｅＳＩＭプロファイルＩＤ（ＩＣＣＩＤ）にバインドしてもよい。

請求項５に記載のテスト方法は、その効率が証明されている。

これは、特に、請求項６に記載のテスト方法に適用される。ＨＴＴＰセッションは、ターゲットｅＵＩＣＣとＲＳＰプラットフォームとの間でＴＬＳ（トランスポート・レイヤー・セキュリティ）プロトコルを介してｅ２ｅ（エンドツーエンド）接続を確立してもよい。テストプローブは、テストプローブとターゲットｅＵＩＣＣとの間の通信用にＢＩＰ（Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ）チャネルを確立してもよい。ＣＡＴ＿ＴＰセッションは、２つのコマンド、すなわちｅ２ｅ ＣＡＴ＿ＴＰリンクの再要求及び／又はＢＩＰチャネル開設のためのデータを含んでもよい。このようなＨＴＴＰｓセッション、又はＣＡＴ＿ＴＰセッションは、特にＬＴＥ／ＥＰＳを介して、テスト方法中に維持されてもよい。

請求項７に記載のテスト方法において、ゲートウェイ識別は、特にトリガＳＭＳにおいて与えられるＡＰＮ（アクセスポイント名）を介して実行されてもよい。

請求項８に記載のアクティブテストシステムの利点は、テスト方法に関して上記したものに相当する。テストプローブは、スマートフォンとして具現化してもよい。

請求項９に記載のアクティブテストシステムは、特にＭ２Ｍアプリケーションに適している。ＳＭ－ＤＰ（サブスクリプションマネージャ・データプレパレーション）モジュールは、注文を受信してもよく、ＳＭ－ＳＲ（サブスクリプションマネージャ・セキュアルーティング）モジュールは、パーソナライズされたｅＳＩＭプロフィールを管理してもよい。

請求項１０に記載の注文モジュールは、ウェブインタフェース、又はアプリケーションプログラムインタフェース（ＡＰＩ）を介して、ＲＳＰプラットフォームと通信してもよい。

請求項１１に記載のＲＳＰプラットフォームは、特にスマートフォン及び／又は消費者向けＩｏＴデバイスに適している。ＳＭ－ＤＰ＋モジュールは、パーソナライズされたｅＳＩＭプロファイルを管理してもよい。ＳＭ－ＤＳモジュールは、テストプローブに適したＳＭ－ＤＰ＋アドレスを識別してもよい。

請求項１２に記載のＳＩＭサーバとテストプローブとの間の信号接続は、ＬＡＮ／ＷＡＮを介して確立されてもよい。請求項１２に記載のＳＩＭマルチプレクサは、テストプローブとターゲットｅＵＩＣＣ／ｅＳＩＭの地理的分離を提供する。

請求項１３に記載のクラウドベースのシステムにより、快適で費用対効果の高いクライアント接続が可能となる。

本発明の実施形態を、添付図面を参照して以下に説明する。

Ｍ２Ｍ（マシンツーマシン）デバイスのリモートｅＳＩＭプロビジョニング（ＲＳＰ）プロセスを検証するためのテスト方法を提供する、アクティブテストシステムの主要コンポーネントの概略図である。 図１と同様の概略図において、消費者デバイス、例えばスマートフォン又は異なる消費者ＩｏＴデバイスのための、それぞれのＲＳＰ検証プロセステスト方法を提供するアクティブテストシステムのさらなる実施形態を示す図である。 ＳＩＭマルチプレクサを含むテストシステム構成を示す図である。 クラウドを介して通信を行うテストシステム構成を示す図である。

Ａ．Ｍ２Ｍ用のｅＳＩＭ ＲＳＰのテスト
ｅＵＩＣＣリモートプロビジョニング及びマネージメントプラットフォーム（ＲＳＰ（リモートＳＩＭプロビジョニング）プラットフォーム１として知られる）は、リモートｅＳＩＭプロビジョニングを担当する。これは、ＳＭ－ＤＰ（サブスクリプションマネージャ・データプレパレーション）モジュール２と、ＳＭ－ＳＲ（サブスクリプションマネージャ・セキュリティルーティング）モジュール３の互いに安全に接続された２つの２つのエンティティを成立する。ＳＭ－ＤＰモジュール２は、モバイルネットワークオペレータ（ＭＮＯ）４の代理として作動する。ＳＭ－ＳＲモジュール３は、組み込み汎用集積回路カード（ｅＵＩＣＣ）、又は組み込みＳＩＭ（ｅＳＩＭ）のパーソナライズされたソフトウェア部分への安全で認証されたトランスポートチャネルを確立する。そのようなソフトウェア部分は、割り当てられたユーザ又は特にインターネットオブシングス（ＩｏＴ）の一部として、接続されたデバイスに割り当てられてもよい。ＳＭ－ＳＲモジュール３は、さらに、ダウンロードされるか、又は相互に切り替えられる、ｅＵＩＣＣにおけるパーソナライズされたプロファイルを管理する。

任意の適切なフォームファクタのｅＳＩＭカード５は、一実施形態によればＭ２Ｍデバイスをシミュレートし、別の実施形態によればスマートフォン及び／又は消費者ＩｏＴデバイスをシミュレートするテストプローブ６に挿入される。複数のインスタンスを有することができるテストプローブ６は、アクティブテストシステム７の一部であり、テスト中のＲＳＰプラットフォーム１からダウンロードされる少なくとも１つの必要なｅＳＩＭプロファイルを受信するように構成される。挿入されたｅＳＩＭカード５は、注文されプロビジョニングされる必要なプロファイルとは異なる、現在機能しているプロファイルを含む。

このテスト方法でテストされるテストシナリオは、テストプローブ６によって表されるユーザ側を含む。

図１は、必要なｅＳＩＭプロファイルのダウンロードを検証するためのテスト手順の３ステップ「注文－トリガ－ダウンロード」を示している。

１．ｅＳＩＭプロファイルの注文（注文ステップ８）
Ｍ２ＭデバイスのためのＲＳＰは、ＭＮＯ４の代表者によって開始され、ＲＳＰプラットフォーム１のＳＭ－ＤＰモジュール２で識別されたターゲットｅＵＩＣＣの特定のｅＳＩＭプロファイルを注文する。２つの例示的なテストシナリオが扱われる。

ａ）テスト中のＲＳＰプラットフォーム１にて手動で注文されたｅＳＩＭプロファイル
人間のテスターが、ＭＮＯ４に代わって、テストされるＲＳＰプラットフォーム１に接続し、テストプローブ６のｅＳＩＭカードをターゲットとして、ｅＳＩＭダウンロード注文８をＲＳＰプラットフォーム１へ手動で送信し、ＲＳＰプラットフォーム１からのプロビジョニングメッセージを待つ。

ｂ）テスト中のＲＳＰプラットフォーム１で自動的に注文されるｅＳＩＭプロファイル
アクティブテストシステム７は、ＭＮＯ４に代わって、１つ又は複数のｅＳＩＭプロファイルを注文するための注文トークンを用いて、Ｗｅｂインタフェース又はＡＰＩ（アプリケーションプログラミングインタフェース）を介してテスト対象のＲＳＰプラットフォーム１と情報交換する。ＲＳＰプロセスは、自動的に開始され得る。テストシステム７は、ＲＳＰプラットフォーム１からのプロビジョニングメッセージを待機している。

注文トークンは、以下を含むことができる。
－ ＳＭ－ＤＰモジュール２によって生成されるｅＳＩＭプロファイルの数量
－ ＩＭＳＩ値（複数可）又は範囲（国際移動体加入者識別番号）
－ ＩＣＣＩＤ値又は範囲（ＩＣカードＩＤ）
－ パーソナライズされていないプロファイルタイプ（複数可）
－ ＥＩＤ（ｅＵＩＣＣ－ＩＤ）などのターゲットｅＵＩＣＣ（複数可）に関する情報

２．トリガステップ９
テスト中のＲＳＰプラットフォーム１のＳＭ－ＳＲモジュール３は、ＯＴＡ（無線）インタフェースを介して、テストプローブ６のターゲットｅＳＩＭカード５に必要なｅＳＩＭプロファイルのダウンロードをトリガする。ＳＭ－ＳＲモジュール３は、ｅＳＩＭカード５をアドレス指定するトリガＳＭＳを送信する。ｅＳＩＭカード５の現在のプロファイルを有するテストプローブ６がモバイルネットワークに接続されると（例えば、４Ｇ／５ＧネットワークでのＥＰＳアタッチ、又は２Ｇ／３ＧネットワークでのＧＰＲＳアタッチ）、ＳＭ－ＳＲモジュール３によって送信されたトリガＳＭＳが、テストプローブ６を介してターゲットｅＳＩＭカード５に配信され、ｅＵＩＣＣサポートに応じてＨＴＴＰｓセッション、又はＣＡＴ＿ＴＰセッション（カードアプリケーションツールキットトランスポートプロトコル）をトリガする。トリガＳＭＳにカプセル化されたＡＰＮ（アクセスポイント名）に基づいて、テストプローブは、ＡＰＮで指名されたゲートウェイへのＰＤＮ（パケットデータネットワーク）接続を確立する。

テストプローブ６は、ｅＳＩＭカード５へのトリガ９を受信し、処理する。ＨＴＴＰｓが使用される場合、トリガＳＭＳは、ＨＴＴＰセッショントリガコマンドを含み、これにより、ｅＳＩＭカード５とＲＳＰプラットフォーム１のＳＭ－ＳＲモジュール３との間にＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを介したｅ２ｅ（エンドツーエンド）ＨＴＴＰセッションが確立される。ＨＴＴＰセッションの下で、テストプローブ６は、ＲＳＰプラットフォーム１へのセッションのためのＴＣＰ／ＩＰトランスポート接続を確立し、テストプローブ６とｅＳＩＭカード５との間の通信用にＢＩＰ（Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ）チャネルを確立する。

ＣＡＴ＿ＴＰが使用される場合、トリガＳＭＳは２つのコマンドを含む。
－ ｅＳＩＭカード５とＳＭ－ＳＲモジュール３との間に確立されるｅ２ｅ ＣＡＴ＿ＴＰリンクの要求
－ テストプローブ６とｅＳＩＭカード５との間のＢＩＰチャネル開放のデータ

同様に、ＣＡＴ＿ＴＰセッションの下で、テストプローブ６は、セッションのためのＵＤＰ／ＩＰ接続を確立し、テストプローブ６とｅＳＩＭカード５との間の通信用のＢＩＰ（Ｂｅａｒｅｒ Ｉｎｄｅｐｅｎｄｅｎｔ Ｐｒｏｔｏｃｏｌ）チャネルを確立する。

３．ダウンロード及びインストールステップ９ａ
必要なｅＳＩＭプロファイルのダウンロード及びインストール手順の操作は、一方ではｅＳＩＭカード５とテストプローブ６との間で実施され、もう一方ではテスト中のＲＳＰプラットフォーム１の間で実施され、４つの主要ステップで実行できる。

－ ｅＳＩＭカード５にダウンロードされる必要なｅＳＩＭプロファイルごとに、セキュアドメインのプロファイルエンティティを作成し、
－ キーエスタブリッシュメントと呼ばれる、第１のセキュアキーセットでエンティティをパーソナライズし、
－ 必要なｅＳＩＭプロファイルをＳＭ－ＤＰモジュール２からダウンロードし、ＲＡＭ（リモートアプリケーションマネージメント）付きｅＳＩＭプロファイルをｅＳＩＭカード５へインストールし、
－ 新しくインストールされたｅＳＩＭプロファイルを有効にし、ｅＳＩＭカード５で以前に使用されていたワーキングプロファイルを無効にする（これは、プロファイルスイッチングと呼ばれる）。

動作中、テストプローブ６は、ＬＴＥ／ＥＰＳ（Ｅｖｏｌｖｅｄ Ｐａｃｋａｇｅ Ｓｙｓｔｅｍ）上で信頼性の高いＨＴＴＰｓセッション又はＣＡＴ＿ＴＰセッションを維持する。

トリガステップと、注文及びトリガされたｅＳＩＭプロファイルが正しくダウンロードされたかどうかを確認するステップは、ユーザ側から、すなわちテストプローブ６を介して開始される。

Ｂ．消費者向けデバイス用のｅＳＩＭ ＲＳＰのテスト
図２に関して、スマートフォン又は消費者向けＩｏＴデバイスのＲＳＰプロセスをそれぞれ検証するテスト方法を提供するアクティブテストシステムのさらなる実施形態を説明する。図１の実施形態に関して既に議論されたコンポーネント及び機能には、同じ参照番号を付し、再び詳細に議論しない。

スマートフォン及び／又は消費者向けＩｏＴデバイスのｅＳＩＭ ＲＳＰのためのテスト中のＲＳＰプラットフォーム１は、それぞれ、サブスクリプションマネージャ・データプレパレーション＋（ＳＭ－ＤＰ＋）モジュール１０と、サブスクリプションマネージャ・ディスカバリサーバ（ＳＭ－ＤＳ）モジュール１１との、２つの部分から成る。ＳＭ－ＤＰ＋モジュール１０は、プロファイルパッケージを準備し、それらをプロファイル保護キーで保護し、各保護プロファイルパッケージをそれぞれのＥＩＤにバインドし、これらのバインドされたプロファイルパッケージをそれぞれのｅＳＩＭカード５に安全にダウンロードする。ＳＭ－ＤＰ＋アドレスがテストプローブ６に不明である場合は、ＳＭ－ＤＳモジュール１１が必要である。

ｅＳＩＭカード５は、消費者向けデバイスをシミュレート又は代表するテストプローブ６に挿入される。テストプローブ６は、アクティブテストシステム７に接続され、テスト中のＲＳＰプラットフォーム１からダウンロードされる必要なｅＳＩＭプロファイルを受信するように構成されている。挿入されたｅＳＩＭカード５には、注文されプロビジョニングされるプロファイル（複数可）とは異なる、現在機能しているプロファイルが含まれている。ＳＭ－ＤＰ＋から必要なｅＳＩＭプロファイルをダウンロードするため、又はＳＭ－ＤＳモジュール１１を介してＳＭ－ＤＰ＋アドレスを検出するために、テストプローブはＨＴＴＰｓセキュアプロトコルを使用する。

図２は、必要なｅＳＩＭプロファイルのダウンロードを検証するためのテスト手順の例示的な４つのステップ「リクエスト－注文－トリガ－ダウンロード」を示している。

１．サブスクリプションのリクエスト１２
テストシステム７は、ＲＳＰプロセスを開始し、サブスクリプションを要求する。

２．ｅＳＩＭプロファイルの注文１３
ＭＮＯ４は、ＳＭ－ＤＰ＋モジュール１０で要求されたｅＳＩＭプロファイルを注文する。準備されたｅＳＩＭプロファイルは、ＳＭ－ＤＰ＋モジュール１０で安全に保管される。ＥＩＤが、ｅＳＩＭプロファイルＩＤ（ＩＣＣＩＤ）にバインドされる。

３．トリガ１４－サブスクリプションの確認
ＭＮＯ４は、テストプローブ６をトリガして、必要なｅＳＩＭプロファイルをダウンロードするための適切なアドレスを見つけるサブスクリプションをテストプローブ６に確認する。この手順は、オペレータに依存しており、ＵＲＬへのアクセス、ローカルプロファイルアシスタント（ＬＰＡ）の使用、又はデバイスのファームウェアのネイティブ機能によって実行してもよい。消費者向けデバイス又はスマートフォンを代表するテストプローブ６をトリガするために、例えば、３つのオプションがある。

－ ｅＳＩＭカード５に格納されているデフォルトのＳＭ－ＤＰ＋アドレスの使用
－ ＳＭ－ＤＰ＋アドレス（ＦＱＤＮ）の検出のための、ルートＳＭ－ＤＳの使用
－ アクティベーションコード（ＡＣ）の使用

テストプローブ６は、以下の順序でいずれかの手順を選択する。

－ デフォルトのＳＭ－ＤＰ＋アドレスの使用。
このオプションは、電源投入時のプロファイル検出としてよく使用される。テストプローブ６は、事前に設定されてｅＳＩＭカード５に保存されているデフォルトのＳＭ－ＤＰ＋アドレスを取得する。

－ プロファイル検出のためのルートＳＭ－ＤＳの使用。
テストプローブ６は、事前に設定されてｅＳＩＭカード５に保存されているＳＭ－ＤＣアドレスを取得し、ＳＭ－ＤＣサーバとＴＬＳ接続を確立し、ＨＴＴＰｓでＳＭ－ＤＣとの相互認証を確立し、イベントＩｄ無しでイベントリクエストを送信する。ＳＭ－ＤＣは、ＡＣ（＝ＳＭ－ＤＰ＋アドレス＋マッチングＩＤ）、すなわちアクティベーションコードを用いて、イベントリクエストをテストプローブ６に回答する。

－ ＡＣの使用。
アクティブテストシステム７は、ＭＮＯ４から任意の手段、例えば電子メール又はＡＰＩを介して、アクティベーションコード（ＡＣ）を受け取っている。そのＡＣは、少なくとも、
－ ＳＭ－ＤＰ＋アドレス、
－ ＡＣトークン（マッチングＩｄ）、
を含む。

そのＡＣは、手入力、又はＱＲコード（登録商標）のスキャンによってテストプローブ６に入力できる。

４．ダウンロード、及びインストールステップ１５
ｅＳＩＭプロファイルダウンロード手順１５の操作が、テストプローブ６とテスト中のＲＳＰプラットフォーム１のＳＭ－ＤＰ＋モジュール１０との間で実行される。動作中、テストプローブ６は、ＬＴＥ／ＥＰＳ又は固定ケーブルを介して、ＴＣＰ／ＩＰ上の信頼性の高いｅ２ｅＨＴＴＰｓセッションを維持する。テストプローブ６は、パラメータＥＩＤと、マッチングＩＤとを用いて、必要なｅＳＩＭプロファイルのダウンロードを開始し、バインドされたプロファイルパッケージを識別する。そのプロファイルがデフォルトのＳＭ－ＤＰ＋アドレスからダウンロードされる場合、マッチングＩＤは空である。

バインドされたプロファイルパッケージ全体を受信した後、テストプローブ６は、安全かつ保護された方法で、必要なｅＳＩＭプロファイルのｅＳＩＭカード５へのインストールを開始する。

さらなる実施形態では、スマートフォンをテストプローブ６として使用してもよい。

スマートフォンのｅＳＩＭ ＲＳＰは、テストプローブ６のｅＳＩＭカード５に関して、上記したｅＳＩＭダウンロード手順と同様に実行される。スマートフォンは、テストプローブ６の特定の実施形態として見なされ、すなわち、モバイルアプリケーションへの同じユーザアクセスインターフェースを有するテストモバイルデバイスとして機能する。

企業向け（エンタープライズ）スマートフォンの場合、必要なｅＳＩＭプロファイルの注文のためにＥＩＤリストが使用される。アドレス検出にルートＳＭ－ＤＳを使用する上記のアプローチは、トリガステップ１４で適用される。

図３に示す更なる実施形態では、アクティブテストシステムは、ＳＩＭマルチプレクサ１６を含む。ＳＩＭマルチプレクサ１６は、ＳＩＭサーバ１７と、多数のｅＳＩＭカード５とを含む。ＳＩＭサーバ１７は、この実施形態では、携帯電話又はスマートフォンとして具現化され得るテストプローブ環境１９と信号接続されるＳＩＭエミュレーションモジュール１８を含むテストプローブ６と信号接続されている。

ＳＩＭエミュレーションモジュール１８のＳＩＭエミュレーションは、ｅＳＩＭカード５のターゲットｅＳＩＭ、又はｅＵＩＣＣを表し、かつ、そのように動作する。

ＳＩＭマルチプレクサ１６は、テストプローブ６とｅＳＩＭカード５（ｅＵＩＣＣ）とを地理的に分離して、複数のｅＳＩＭのプロビジョニングと、その後のプロビジョニングされたｅＳＩＭのディスパッチとを行うことができる。テストシステム７は、ＳＩＭマルチプレクサ１６を使用して、ｅＳＩＭカード５（ｅＵＩＣＣ）とＳＭ－ＳＲモジュール３（Ｍ２Ｍデバイスの場合、上記図１と比較のこと）、又はテストプローブ６のテストプローブ環境１９によって提供されるモバイル接続を使用して、ＳＭ－ＤＰ＋モジュール１０（スマートフォン及び／又は消費者向けＩｏＴデバイスの場合、上記図２と比較のこと）の間のメッセージをブリッジすることになる。図４を参照して、それぞれの実施形態を以下に説明する。

ｅＳＩＭ ＲＳＰの検証は、２つのテストシーケンス部分から構成される。
（ａ）テストプローブがネットワークに正常に再接続されていることを確認し、新しいＩＭＳＩ値をｅＳＩＭ ＲＳＰの前の値と比較することにより、ｅＳＩＭプロファイルがプロビジョニングされ、ブートストラップからターゲットオペレータにスワップされていることを検証する。
（ｂ）基本的なモバイルサービス（例えば、ＨＴＴＰｓダウンロード、Ｐｉｎｇ、ＳＭＳ ＭＯ ＭＴ、及び音声ＭＯ ＭＴなどの）のテストプローブでプロビジョニングされたｅＳＩＭを使用することによるＲＳＰ後のネットワークサービス保証のテスト。このようなＲＳＰ後のネットワークサービス保証テストは、これ以上詳細に説明しない。

テストシステムは、従来のサーバ／クライアントモデルベースの分散テストシステムにすることができる。最近では、クラウドベースのテストシステムが主に展開されている。テストプローブは、どちらのタイプのテストシステムにも接続できる。

テストシステム７の主要コンポーネント間の通信は、クラウドベースのテストサーバ２０を介して実行してもよい。（図４参照）

このようなクラウド化されたテストシステム７は、ｅＳＩＭ ＲＳＰプロセスの検証（図４参照）に適用され、また、ＬＴＥ／ＥＰＳを介してＨＴＴＰ（ｓ）経由のＳＭＳ及び／又はＲＡＭ（リモートアプリケーション管理）をサポートする。

図４では、テストプローブ６の異なる実施形態が描かれており、コアネットワークインターフェース経由、又は無線インタフェース経由で通信している。

クラウド化されたテストシステム７を使用したＲＳＰテスト手順は、上記したものと同じである。ＥＰＳ ＡＴＴＡＣＨ及びトリガ－ＳＭＳからなる標準的なテストシーケンス実行してもよい。

以下では、手動でトリガされるＲＳＰプロセスの検証に関する主要な側面について説明する。

一方向のアクティブテストが実行される。このシナリオでは、ユーザがテストを開始し、プロビジョニングプラットフォーム（クライアント２１）からＲＳＰプロセスを手動でトリガする。テストシーケンスは以下のとおりである。

－ ネットワーク（ＭＮＯ４、上記の図１と図２を比較）に接続し、
－ ＡＣトークンで、プロビジョニングＳＭＳ－ＭＴ、又はＳＭ－ＤＰ＋アドレスの受信を待ち、
－ ｅＳＩＭカード５とＲＳＰプラットフォーム１（ＳＭ－ＳＲモジュール３又はＳＭ－ＤＰ＋ １０を含む）の間のｅＳＩＭプロビジョニングＨＴＴＰｓセッションが完了するまで待ち、
－ 新しくプロビジョニングされたｅＳＩＭプロファイルでネットワークの再接続が成功するのを待ち、
－ ネットワークから切り離す。

トリガステップと、注文及びトリガされたｅＳＩＭプロファイルが正しくダウンロードされたかどうかを確認するステップは、ユーザ側から、すなわちテストプローブ６を介して開始される。

入力パラメータ
標準のテストパラメータを含めるべきである。また、タイムアウトパラメータを含めるべきであり、これによりユーザは、ＳＭ－ＳＲモジュール３からのプロビジョニングトリガＳＭＳを待機する時間のタイムアウトを設定できる。以下の表に例を示す。

主要なパラメータ指標（ＫＰＩ）
以下のＫＰＩを提供すべきである。

検証結果は、結果ファイルに記録されてもよい。このようなファイルは、ＰＣＡＰ（パケットキャプチャ）形式であってもよい。

ＲＳＰ検証中に、以下の不合格（フェイル）基準を設定してもよい。

－ ＳＭ－ＳＲから、（ユーザが設定したタイムアウト期間中）ＳＭＳを受信しないか、又はサブスクリプション確認（ＡＣ）を受信しない。
－ ＨＴＴＰｓセッションが、ｅＳＩＭカード５又はＳＩＭエミュレーションモジュール１８のＳＩＭエミュレーションと、ＲＳＰプラットフォーム（ＳＭ－ＳＲ又はＳＭ－ＤＰ＋）の間でオープンされない。
－ 終了時のＩＭＳＩが、開始時のＩＭＳＩと同じである。
－ ＩＭＳＩ変更後の新しいＡＰＮへのネットワーク再接続が成功しない。

自動的にトリガされるＲＳＰの場合（上記の図２に関して説明した実施形態と比較のこと）、図４によるアクティブテストシステム７は、ＲＳＰのために２つのインタフェースを使用することが望ましい。

－ ＲＳＰプロセス自体のための１つのモバイルインタフェース。
－ テスト中のＲＳＰプラットフォーム１のＡＰＩと対話するための１つのＬＡＮインタフェース。

このテストシーケンスは、顧客が使用しているテスト対象のプラットフォームに応じてカスタマイズする必要がある。

モバイルインタフェース部分は、上記の手動でトリガされたシナリオと同じ動作をする必要がある。

－ ネットワークに接続する（ＭＮＯ４、上記の図１と図２を比較のこと）。
－ プロビジョニングトリガ－ＳＭＳを待つ。
－ ｅＳＩＭカード５とＲＳＰプラットフォーム１（ＳＭ－ＳＲモジュール３又はＳＭ－ＤＰ＋ １０）の間のＨＴＴＰｓセッションが完了するまで待機する。
－ ネットワークから切り離す。

ＬＡＮインタフェースは、プロビジョニングプラットフォーム２１へのＡＰＩコマンドの送信に使用することが望ましい。コマンドは、例えば、プロファイルのダウンロード、プロファイルの削除、又はプロファイルのアクティベートのように、ユーザが設定可能であるべきである。

入力パラメータ
手動シナリオと同様に、タイムアウトパラメータが含まれるべきで、ユーザは、ＳＭ－ＳＲモジュール３からのプロビジョニングトリガ－ＳＭＳを待機する時間のタイムアウトを設定できる。

ＡＰＩと対話するための追加のパラメータ（操作タイプ、ＡＰＩへの認証、ｅＳＩＭ／ｅＵＩＣＣ ＩＤ（ＥＩＤ）－プロビジョニングが必要な要求されたｅＳＩＭプロファイルのＩＤ、ＩＭＳＩ）を含める必要がある。パラメータの完全なリストは、特定のＲＳＰプラットフォームＡＰＩドキュメントに基づいて指定できる。

主要なパラメータインジケータ
以下のＫＰＩを提供すべきである。
－ テスト開始時のＩＭＳＩ。
－ テスト終了時のＩＭＳＩ。
－ ＰＣＡＰファイルからのＩＰセッション存続期間－ｅＳＩＭカード５とＳＭ－ＳＲモジュール３の間のＩＰセッションの存続期間－これは、プロファイルのダウンロード、有効化、無効化などのＲＳＰ操作の完了に要した時間を反映する。
－ ＰＣＡＰファイルからのＳＭ－ＳＲモジュール３、又はＳＭ－ＤＰ＋モジュール１０のＩＰアドレス。
－ ＩＰセッション開始の存続期間－可能な場合－プロビジョニングＳＭＳの受信又はＡＣの受信と、ＩＰセッションの開始（モバイルからＲＳＰプラットフォーム１（ＳＭ－ＳＲ又はＳＭ－ＤＰ＋）へのＴＣＰ ＳＹＮ）との間の存続時間として測定される。
－ 総プロビジョニング存続期間－ＡＰＩ１トリガを送信してからＩＰセッションが完了するまでの時間。
－ ＳＭＳ受信存続期間－ＡＰＩトリガを送信してから、プロビジョニングＳＭＳが受信されるまでの存続期間。
－ サブスクリプション存続期間－サブスクリプション要求からサブスクリプション確認までの存続期間

ＰＣＡＰファイルが、結果ファイルとして提供されてもよい。

ＲＳＰ検証の間、以下の不合格（フェイル）基準を設定してもよい。

－ ＳＭ－ＳＲから、（ユーザが設定したタイムアウト期間中）ＳＭＳを受信しないか、又はサブスクリプション確認（ＡＣ）を受信しない。
－ ＨＴＴＰｓセッションが、ｅＳＩＭカード５又はＳＩＭエミュレーションモジュール１８のＳＩＭエミュレーションと、ＲＳＰプラットフォーム（ＳＭ－ＳＲ又はＳＭ－ＤＰ＋）の間でオープンされない。
－ 終了時のＩＭＳＩが、開始時のＩＭＳＩと同じである。
－ ＲＳＰプラットフォームが、ＡＰＩ経由で到達できない。

注文スケジュールに従って、必要なｅＳＩＭプロファイルのシーケンスを自動的に注文するために、アクティブテストシステムはまた、注文モジュールを含んでもよく、それはテストプローブ６の一部であってもよい

１ ＲＳＰプラットフォーム
２ ＳＭ－ＤＰモジュール
３ ＳＭ－ＳＲモジュール
４ モバイルネットワークオペレータ（ＭＮＯ）
５ ｅＳＩＭカード
６ テストプローブ
７ アクティブテストシステム
８、１３ 注文ステップ
９、１４ トリガステップ
９ａ ダウンロード及びインストールステップ
１０ ＳＭ－ＤＰ＋モジュール
１１ ＳＭ－ＤＳモジュール
１２ リクエスト（要求）ステップ
１５ ｅＳＩＭプロファイルダウンロード手順
１６ ＳＩＭマルチプレクサ
１７ ＳＩＭサーバ
１８ ＳＩＭエミュレーションモジュール
１９ テストプローブ環境
２０ クラウドベースのテストサーバ
２１ プロビジョニングプラットフォーム（クライアント）

Claims (13)

1. リモートｅＳＩＭプロビジョニング（ＲＳＰ）プロセスの検証のためのテスト方法であって、
   テスト中のＲＳＰプラットフォーム（１）からｅＳＩＭプロファイルを注文する（８；１３）ステップと、
   前記ＲＳＰプラットフォーム（１）から注文された前記ｅＳＩＭプロファイルのダウンロードをトリガする（９；１４）ステップと、
   トリガされた前記ｅＳＩＭプロファイルを前記ＲＳＰプラットフォーム（１）から、無線（ＯＴＡ）インタフェースを介して、テストプローブ（６）のターゲットｅＳＩＭ、又はｅＵＩＣＣ（５）にダウンロードする（９ａ；１５）ステップと、
   注文、及びトリガされた前記ｅＳＩＭプロファイルが正しくダウンロードされたかどうかを確認するステップと、を含み、
   前記テストプローブ（６）は、Ｍ２Ｍ（マシンツーマシン）デバイスをシミュレートするように構成される、テスト方法。
2. リモートｅＳＩＭプロビジョニング（ＲＳＰ）プロセスの検証のためのテスト方法であって、
   テスト中のＲＳＰプラットフォーム（１）からｅＳＩＭプロファイルを注文する（８；１３）ステップと、
   前記ＲＳＰプラットフォーム（１）から注文された前記ｅＳＩＭプロファイルのダウンロードをトリガする（９；１４）ステップと、
   トリガされた前記ｅＳＩＭプロファイルを前記ＲＳＰプラットフォーム（１）から、無線（ＯＴＡ）インタフェースを介して、テストプローブ（６）のターゲットｅＳＩＭ、又はｅＵＩＣＣ（５）にダウンロードする（９ａ；１５）ステップと、
   注文、及びトリガされた前記ｅＳＩＭプロファイルが正しくダウンロードされたかどうかを確認するステップと、を含み、
   前記テストプローブ（６）は、スマートフォン及び／又は消費者向けＩｏＴデバイスをシミュレートするように構成され、
   前記テスト方法を用いてテストされるテストシナリオが、前記テストプローブ（６）によって代理されるユーザ側を含み、
   前記トリガするステップ（９；１４）、及び前記確認するステップは、前記ユーザ側から開始される、テスト方法。
3. 注文の前に、サブスクリプション要求（１２）が、前記テストプローブ（６）から前記注文の送信エンティティ（４）に送信されることを特徴とする、請求項１又は２に記載のテスト方法。
4. 注文スケジュールに従って、一連のｅＳＩＭプロファイルを自動的に注文することを含むことを特徴とする、請求項１乃至３のいずれか一項に記載のテスト方法。
5. トリガ中に、前記ＲＳＰプラットフォーム（１）は、前記ターゲットｅＵＩＣＣ（５）をアドレス指定して、テストプローブ（６）にトリガＳＭＳを送信することを特徴とする、請求項１乃至４のいずれか一項に記載のテスト方法。
6. 前記トリガＳＭＳがＨＴＴＰｓセッション、又はＣＡＴ＿ＴＰ（Ｃａｒｄ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）セッションをトリガすることを特徴とする、請求項５に記載のテスト方法。
7. トリガ中に、前記テストプローブ（６）は、トリガＳＭＳで指定されたゲートウェイへのＰＤＮ（パケットデータネットワーク）接続を確立することを特徴とする、請求項１乃至６のいずれか一項に記載のテスト方法。
8. 請求項１乃至７のいずれか一項に記載のテスト方法を提供するアクティブテストシステム（７）であって、
   初期作業プロファイルがインストールされた少なくとも１つのターゲットｅＳＩＭ、又はｅＵＩＣＣ（５）を含む少なくとも１つのテストプローブ（６）と、
   前記初期作業プロファイルとは異なるｅＳＩＭプロファイルをリモートで提供するためのＲＳＰプラットフォーム（１）へのインタフェースと、
   前記ＲＳＰプラットフォーム（１）と前記テストプローブ（６）の間の通信を提供するためのＯＴＡインタフェースと、
   を有することを特徴とする、アクティブテストシステム（７）。
9. 前記ＲＳＰプラットフォーム（１）は、
   サブスクリプションマネージャ・データプレパレーション（ＳＭ－ＤＰ）モジュール（２）と、
   サブスクリプションマネージャ・セキュリティルーティング（ＳＭ－ＳＲ）モジュール（３）と、を含むことを特徴とする、請求項８に記載のアクティブテストシステム。
10. 注文スケジュールに従って、一連のｅＳＩＭプロファイルを自動的に注文するための注文モジュールを備えることを特徴とする、請求項８又は９に記載のアクティブテストシステム。
11. 前記ＲＳＰプラットフォーム（１）は、
    サブスクリプションマネージャ・データプレパレーション＋（ＳＭ－ＤＰ＋）モジュール（１０）と、
    サブスクリプションマネージャ・ディスカバリサーバ（ＳＭ－ＤＳ）モジュール（１１）と、を含むことを特徴とする、請求項８乃至１０のいずれか一項に記載のアクティブテストシステム。
12. ＳＩＭサーバ（１７）及び多数のｅＵＩＣＣ（５）を含むＳＩＭマルチプレクサ（１６）を備え、前記ＳＩＭサーバ（１７）は前記テストプローブ（６）と信号接続されていることを特徴とする、請求項８乃至１１のいずれか一項に記載のアクティブテストシステム。
13. クラウドベースサーバ（２０）を備えることを特徴とする、請求項８乃至１１のいずれか一項に記載のアクティブテストシステム。

Images