KR20220071238A - Test methods for verifying RPS processes and active test systems providing such test methods - Google Patents

Abstract

In the test method for remote eSIM provisioning process verification, an eSIM profile is ordered (8) on the RSP platform under test (1). After that, the download of the ordered eSIM profile in the RSP platform 1 is triggered. Then, the eSIM profile triggered in the RSP platform 1 is downloaded 9a to the target eSIM or eUICC 5 in the test probe 6 via the air interface. It is then verified that the order, trigger and downloaded eSIM profile are correct. The test probe 6 may be configured to simulate an M2M device, a smartphone and/or a consumer IoT device. This test method improves the test system's ability to test mobile networks with remote eSIM provisioning while still providing network connectivity and services through eSIM swapping.

Description

Test methods for verifying RPS processes and active test systems providing such test methods

This application claims priority to the German patent application DE 10 2019 214 919.7, the content of which is hereby incorporated by reference.

The present invention relates to a test method for verification of a remote eSIM provisioning (RSP) process. The invention also relates to an active test system providing such a test method.

Test systems for mobile networks are known from US 10,097,981 B1, US 7,831,249 B2 and WO 2004/049746 A1. US 2019/0075448 A1 discloses monitoring of an embedded subscriber identity module. WO 2016/013827 A1 discloses a method and apparatus for embedded SIM provisioning. WO 2017/013127 A1 discloses a method for detecting remote access of a universal integrated circuit card.

It is an object of the present invention to improve the ability of such a test system for testing mobile networks with remote eSIM provisioning.

This object is met by a test method comprising the features of claim 1 or 2 and an active test system comprising the features of claim 7 .

Embedded Universal Integrated Circuit Card (eUICC), or Embedded SIM (eSIM), is an embedded system for consumer Internet of Things (IoT) and Machine-to-Machine (M2M) devices to identify devices facing mobile networks. widely used eSIMs for smartphones are also being introduced. eSIM is a next-generation SIM technology intended to replace physical cards with a combination of hardware and software that provides the ability to remotely switch devices between operators. This technology enables one device to host multiple connectivity providers (known as profiles) and is designed for use across the entire spectrum of mobile devices, including smartphones and IoT modules.

The hardware part of the eUICC card is mainly manufactured in MFF2 (embedded form factor). The software portion of the eSIM can be downloaded and installed remotely on the eUICC card. This process is referred to as Remote eSIM Provisioning (RSP). The term eUICC or eSIM as referred to in this application refers to a 'personalized' eUICC or eSIM as the software part of the eUICC to be downloaded. The eUICC is not easily accessible or replaceable, it is not removed or replaced from the device, and it enables secure subscription changes.

The GSMA has specified the following standards for eSIM provisioning for M2M devices and consumer devices, respectively.

- 7 July 2020, GSMA SGP.02 v4.2 - Remote Provisioning Architecture for Embedded SIM - Technical Specifications

- 5 June 2020, GSMA SGP.22 v2.3, RSP Technical Specification

- 25 February 2019, GSMA SGP.02 v4.0, - Embedded SIM remote provisioning architecture.

The test method and active system according to the present invention cover the testing and verification aspects when an eSIM is provisioned to an eSIM capable device on behalf of a mobile operator or a third party.

Additional standards specified by the GSMA are

- July 7, 2020, GSMA SGP.23 RSP test specification version 1.7.

Other standards specified by the GSMA are

- As of September 17, 2019, GSMA SGP.24 RSP Compliance Process Version 2.2.

Multiple profiles can be downloaded and installed on the eUICC. A profile is a combination of file structures, data and applications that will be associated with the operator and will be provisioned or presented on the eUICC, which, when activated, allows access to specific mobile network infrastructure. Only one profile can be active and active at a time. All profiles on the eUICC can be managed to be activated, deactivated, removed or switched by the eSIM RSP platform on behalf of the operator or a third party.

These test methods and active test systems apply end-to-end test methods to verify mobile network connectivity and services in the context of the RSP process. This test method is to test the mobile network connectivity by verifying the RSP in the test system and using a SIM that is provisioned in the domestic or international service network according to the rules below.

- GSMA SGP.02 RSP for M2M devices,

- GSMA SGP.22 RSP for consumer devices.

The eSIM profile is the personalized software portion of the embodied universal integrated circuit card (eUICC), ie the software assigned to the assigned user. Such software includes at least one user profile. The RSP process may be used, for example, in consumer devices such as smartphones, smartwatches, wearables, and/or Machine to Machine (M2M) devices. This test method specifically verifies mobile network connections and services. Ordering of an eSIM profile from the RSP platform can be done manually or automatically. The sender of the order may be a mobile network operator (MNO). Prior to ordering, the RSP process may be initiated. During the test method, the previous working profile or the bootstrap profile initially installed in the eUICC may be deactivated and the downloaded eSIM profile may be activated. Verification may be performed by monitoring the occurrence of at least one failure criterion. These failure criteria may be based on RSP platform connection timeout and/or network connection timeout and/or based on expected order structure, triggers and/or download, and/or download, reconnection of device with updated eSIM profile. may be satisfied based on a timeout.

During the test method, network connectivity and services are continuously provided by eSIM swapping.

According to claim 1, the test probe simulates an M2M device.

The test probe can support a large frequency spectrum in licensed bands, including 2G, 3G, 4G and 5G radio frequencies. This configuration of the test probe allows the deployment of Short Message Service (SMS) as an efficient communication method between the remote RSP platform that provides the eSIM profile and the test probe where the eSIM profile must be provisioned via download. The test probe can support SMSoNAS (SMS over Non-Access Stratum (NAS)) for 4G and 5G technologies. The test probe may support SMS over Internet Protocol (SMSoIP) for IP Multimedia Subsystem (IMS) technology. The test probe may be configured to adapt itself to select the correct communication protocol according to the communication technology environment, ie to adapt the requested communication protocol for eSIM verification of the individual RSP platform. The test probe may be configured to communicate with an industrial IoT application. An example of such an industrial IoT application is Long-Term Evolution for Machines (LTE-M). Another example is the Narrow Band Internet of Things (NB-IoT). The test probe may be configured to communicate with at least one low power wide area network (LPWAN) radio technology standard.

According to the test method of claim 2, the test probe simulates a smart phone and/or a consumer IoT device.

The test probe may be configured to test user transaction related test criteria, ie to test the RSP verification process at the user level. During such user level testing, the test probe may initiate the quality testing phase by identifying quality parameters that may be defined by key parameter indicators (KPIs). These KPIs may be connection failure rate, connection time, cutoff rate, download start period, download available rate, and the like. These quality parameters can be checked in real time through the test probe. In that regard, the test probe may be configured to emulate a real user aspect of a user of a smartphone and/or consumer IoT device.

Examples of consumer IoT devices are tablets, smart watches, wearable computers such as eg smart glasses, home voice controllers, doorbell cameras, smart locks, smart light switches, air quality monitors, and the like.

The sending entity of the subscription request according to claim 3 may use a proxy of the mobile network operator. A subscription request may include a link or code. During the trigger phase, the sending entity of the order may confirm the subscription request from the test profile. This verification can trigger a test probe to find a download address to download the ordered eSIM profile. The trigger option can use the Subscription Manager Data Preparation (SM-DP+) default address stored in the target eSIM, or use the root Subscription Manager Discovery Server (SM-DS) for discovery of the Fully Qualified Domain Name (FQDN) of SM-DP+. Alternatively, you can use an activation code that includes an SM-DP+ address.

The order schedule according to claim 4 may include a quantity of eSIM profiles to be created by the RSP platform, may include an IMSI value or an IMSI value or an IMSI range, and may include an ICCID value or an ICCID value or an ICCID range. and may include a non-personalized profile type or non-personalized profile types or may include information about the target eSIM or target eSIMs, such as an EID (eUICC-ID). The EID may be bound to an ordered eSIM Profile ID (ICCID).

The test method according to claim 5 has proven to be effective.

This applies in particular to the test method according to claim 6 . The HTTP session may establish an end to end (e2e) connection over the TLS (Transport Layer Security) protocol between the target eUICC and the RSP platform. The test probe may establish a Bearer Independent Protocol (BIP) channel for communication between the test probe and the target eUICC. The CAT_TP session may include two commands, namely, a request for an e2e CAT_TP link and/or data for opening a BIP channel. This HTTPs session or CAT_TP session may be maintained during the test method, in particular via LTE/EPS.

In the test method according to claim 7, the gateway identification may be performed in particular via the APN (Access Point Name) given in the trigger SMS.

The advantages of the active test system according to claim 8 are consistent with those mentioned above with respect to the test method. The test probe may be implemented as a smartphone.

The active test system according to claim 9 is particularly suitable for M2M applications. A Subscription Manager Data Preparation (SM-DP) module can receive orders and a Subscription Manager Secure Routing (SM-SR) module can manage personalized eSIM profiles.

The ordering module according to claim 10 may communicate with the RSP platform via a web interface or via an API (application program interface).

The RSP platform according to claim 11 is particularly suitable for smartphones and/or consumer IoT devices. The SM-DP+ module can manage personalized eSIM profiles. The SM-DS module can identify a suitable SM-DP+ address for the test probe.

The signal connection between the SIM server and the test probe according to claim 12 may be established via LAN/WAN. A SIM multiplexer according to claim 12 provides for geographic separation of the test probe and the target eUICC/eSIM.

A cloud-based system according to claim 13 enables a comfortable and cost-effective client connection.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Embodiments of the present invention are described below with reference to the accompanying drawings. In these drawings:
1 schematically shows the main components of an active test system for providing a test method for validation of a remote eSIM provisioning (RSP) process for a Machine to Machine (M2M) device;
Fig. 2 shows in a schematic diagram similar to Fig. 1 another embodiment of an active test system that provides a respective RSP verification process test method for a consumer device such as, for example, a smartphone or other consumer IoT device;
3 shows a test system configuration including a SIM multiplexer;
4 is a diagram showing the configuration of a test system communicating via a cloud.

A. eSIM RSP test for M2M

The eUICC remote provisioning and management platform or so-called RSP (Remote SIM Provisioning) platform 1 is responsible for remote eSIM provisioning. This concludes an agreement between two entities securely connected to each other, a Subscription Manager Data Preparation (SM-DP) module (2) and a Subscription Manager Security Routing (SM-SR) module (3). The SM-DP module 2 operates on behalf of a mobile network operator (MNO) 4 . The SM-SR module 3 establishes a secure and authenticated transport channel to the personalized software part of the eUICC (Embedded Universal Integrated Circuit Card) or Embedded SIM (eSIM). This software part may be assigned to a connected device or user assigned in particular as part of the Internet of Things (IoT). The SM-SR module 3 further manages personalized profiles to be downloaded from the eUICC or switched to each other.

An eSIM card 5 of any suitable form factor is inserted into a test probe 6 which simulates an M2M device according to one embodiment and a smartphone and/or consumer IoT device according to another embodiment. . The test probe 6 , which may have multiple instances, is part of the active test system 7 and is configured to receive at least one requested eSIM profile to be downloaded from the RSP platform 1 under test. The inserted eSIM card 5 contains a currently working profile that is different from the profile required for ordering and provisioning.

The test scenario to be tested with this test method includes the user side represented by the test probe 6 .

Figure 1 shows a three-step 'order-trigger-download' of the test procedure to verify the download of the requested eSIM profile.

1. Order eSIM Profile (Order Step (8))

The RSP for the M2M device is initiated by the indication of the MNO 4 to order a specific eSIM profile for the target eUICC identified in the SM-DP module 2 of the RSP platform 1 . Two illustrated test scenarios are described:

a) Manually ordered eSIM profile on the RSP platform under test (1)

A human tester connects to the RSP platform under test (1) on behalf of the MNO (4) and manually sends an eSIM download order (8) to the RSP platform (1) targeting the eSIM card within the test probe (6) and RSP It will wait for a provisioning message from the platform 1 .

b) Auto-ordered eSIM profile on the RSP platform under test (1)

The active test system 7 interacts with the RSP platform 1 under test via a web interface or API (application programming interface) using the ordering token to order one or more eSIM profiles on behalf of the MNO 4 . The RSP process may be started automatically. The test system 7 waits for a provisioning message from the RSP platform 1 . Spell tokens may include:

- the amount of eSIM profile to be generated by the SM-DP module (2);

- International Mobile Subscriber Identity (IMSI) value(s) or range;

- Integrated Circuit Card ID (ICCID) value(s) or range;

- non-personalized profile type(s);

- Information on target eUICC(s), such as EID (eUICC-ID).

2. Trigger Step (9)

The SM-SR module 3 in the RSP platform 1 under test triggers the download of the requested eSIM profile to the target eSIM card 5 in the test probe 6 via an Over The Air (OTA) interface. The SM-SR module 3 sends a trigger-SMS specifying the address of the eSIM card 5 . When the test probe 6 with the current profile on the eSIM card 5 is connected to the mobile network (eg EPS connects to 4G/5G network or GPRS connects to 2G/3G network), SM-SR module 3 ) is transmitted to the target eSIM card 5 via the test probe 6 and triggers an HTTPs session or a Card Application Toolkit Transport Protocol (CAT_TP) session according to eUICC support. Based on the access point name (APN) encapsulated in the trigger-SMS, the test probe establishes a packet data network (PDN) connection to the gateway named in the APN.

The test probe 6 receives and processes the trigger 9 for the eSIM card 5 . HTTP to establish an end-to-end (e2e) HTTP session over the TLS (Transport Layer Security) protocol between the SM-SR module (3) and the eSIM card (5) within the RSP platform (1) when HTTPs are used Contains session trigger commands. Under the HTTP session, the test probe (6) establishes a TCP/IP transport connection for the session towards the RSP platform (1) and establishes a Bearer Independent Protocol (BIP) channel for communication between the test probe and the eSIM card (5). establish

When CAT_TP is used, the trigger-SMS is sent with the following two commands:

- a request for an e2e CAT_TP link to be established between the eSIM card (5) and the SM-SR module (3);

- Data for opening BIP channel between test probe (6) and eSIM card (5)

includes

Similarly, under the CAT_TP session, the test probe 6 establishes a UDP/IP connection to the session and establishes a Bearer Independent Protocol (BIP) channel for communication between the test probe 6 and the eSIM card 5. .

3. Download and Install Step (9a)

The operation of the requested eSIM profile download and installation procedure is carried out between the test probe 6 on the one hand and the RSP platform 1 under test and the eSIM card 5 on the other hand and can be performed in four main steps. have.

- creating a profile entity in the secure domain for each requested eSIM profile to be downloaded on the eSIM card (5);

- a so-called key establishment step, personalizing the entity using a first set of security keys;

- downloading the requested eSIM profile from the SM-DP module (2) and installing the eSIM profile with RAM (Remote Application Management) on the eSIM card (5);

- a so-called profile switching step, activating the newly installed eSIM profile and deactivating the previously used working profile on the eSIM card 5 .

In operation, the test probe 6 maintains a stable HTTPs session or CAT_TP session across LTE/EPS (Evolved Package System).

The triggering step and checking whether the ordered and triggered eSIM profile has been downloaded correctly is initiated from the user side, ie via the test probe 6 .

B. eSIM RSP Testing for Consumer Devices

2 , a further embodiment of an active test system that provides a test method for verification of the RSP process for a smartphone or consumer IoT device, respectively, is described. Components and functions already discussed with respect to the embodiment of FIG. 1 have the same reference numerals and are not discussed in detail again.

The RSP platform (1) being tested for the eSIM RSP of smartphones and/or consumer IoT devices (1) each has two parts: a Subscription Manager Data Preparation+ (SM-DP+) module (10) and a Subscription Manager Discovery Server (SM-DS) module. Consists of modules (11). The SM-DP+ module 10 prepares a profile package, protects it with a profile protection key, binds each protected profile package to an individual EID and securely downloads these bound profile packages to an individual eSIM card 5 . The SM-DS module 11 is required if the SM-DP+ address is not known to the test probe 6 .

The eSIM card 5 is inserted into a test probe 6 which simulates or displays a consumer device. The test probe 6 is connected to the active test system 7 and is configured to receive the requested eSIM profile to be downloaded from the RSP platform 1 under test. The inserted eSIM card 5 contains the currently working profile different from the profile(s) to be ordered and provisioned. To download the requested eSIM profile from the SM-DP+ or discover the SM-DP+ address through the SM-DS module 11, the test probe uses the HTTPs security protocol.

Figure 2 shows an exemplified 4 step 'Request-Order-Trigger-Download' of the test procedure for verifying the download of the requested eSIM profile.

1. Join Request (12) Step

The test system 7 initiates the RSP process and requests a subscription.

Step 2. Order eSIM Profile (13)

The MNO 4 orders the requested eSIM profile from the SM-DP+ module 10 .

The prepared eSIM profile is safely stored in the SM-DP+ module 10 . The EID is bound to the eSIM profile id (ICCID).

3. Trigger (14) - Subscription Confirmation Step

The MNO 4 confirms the subscription to the test probe 6 to find a suitable address for downloading the requested eSIM profile, which triggers the test probe 6 . This procedure is operator-dependent and can be performed by accessing a URL, using the Local Profile Assistant (LPA), or by a native function within the device's firmware. There are three options for triggering the test probe 6 representing for example a consumer device or smartphone:

- Use the default SM-DP+ address stored on the eSIM card (5)

- Discover SM-DP+ address (FQDN) using root SM-DS

- Use Activation Code (AC)

The test probe 6 selects one of the procedures in the following order.

- Use the default SM-DP+ address

This option is often used as power-on profile discovery. The test probe 6 retrieves the default SM-DP+ address preconfigured and stored in the eSIM card 5 .

- Use root SM-DS for profile discovery

The test probe (6) retrieves the preconfigured and stored SM-DC address in the eSIM card (5), establishes a TLS connection with the SM-DC server, establishes mutual authentication with the SM-DC over HTTPs, and event ID Send the event request without The SM-DC responds to the event request with AC (= SM-DP + address + matching ID) to the test probe 6, ie an activation code.

- using AC

The active test system 6 received the activation code from the MNO 4 by any means, for example via email or API. AC is at least

- SM-DP + address

- AC token (matching ID)

includes

AC can be input to the test probe 6 by manual input or by scanning a QR code (Quick Response).

4. Download and Install Steps (15)

The operation of the eSIM profile download procedure 15 is performed between the test probe 6 and the SM-DP+ module 10 of the RSP platform 1 under test. In operation, the test probe 6 maintains a stable e2e HTTPs session over TCP/IP via LTE/EPS or fixed cable. The test probe 6 initiates the requested eSIM profile download using the parameter EID and matching ID to identify the bound profile package. If the profile is downloaded from the default SM-DP+ address, the matching ID is empty.

After receiving the full bound profile package, the test probe 6 starts the installation of the requested eSIM profile on the eSIM card 5 in a safe and protected manner.

In a further embodiment, the smartphone can be used as the test probe 6 .

The eSIM RSP of the smartphone is performed like the eSIM download procedure described above for the eSIM card 5 of the test probe 6 . A smartphone is considered as a specific embodiment of the test probe 6 , ie it acts as a test mobile device with the same user access interface to the mobile application.

For enterprise smartphones, the EID list is used for the requested eSIM profile order. The above-described approach of using the root SM-DS for address discovery applies to the trigger step 14 .

In a further embodiment shown in FIG. 3 , the active test system comprises a SIM multiplexer 16 . The SIM multiplexer 16 comprises a SIM server 17 and a plurality of eSIM cards 5 . The SIM server 17 is in signal connection with a test probe 6 comprising a SIM emulation module 18 in signal connection with a test probe environment 19 , which in this embodiment may be implemented as a mobile or smart phone.

The SIM emulation of the SIM emulation module 18 represents and acts as an eUICC or target eSIM of the eSIM card 5 .

SIM multiplexer 16 allows geographic separation of test probe 6 and eSIM card 5 (eUICC) for multiple eSIM provisioning and thereafter provisioned eSIM dispatching. The test system 7 uses a SIM multiplexer 16 to test either the SM-SR module 3 (for M2M devices, compare Fig. 1 above) or the SM-DP+ module 10 (smartphone and/or consumer IoT). In the case of the device, it will mediate messages between the eSIM card 5 (eUICC) and the eSIM card 5 (compared to FIG. 2 above), which uses the mobile connection provided by the test probe environment 19 of the test probe 6 . . Each embodiment is described below with reference to FIG. 4 .

The eSIM RSP verification consists of two test sequence parts.

a) Verify that the test probe has successfully reconnected to the network and verify that the eSIM profile has been provisioned and replaced from the bootstrap to the target operator by comparing the new IMSI value with the IMSI value before the eSIM RSP.

b) Test post-RSP network service assurance by using the eSIM provisioned in the test probe for basic mobile services such as HTTPs Download, Ping, SMS MO MT and Voice MO MT as examples. These post-RSP network service assurance tests are not discussed further in detail.

The test system may be a distributed test system based on an existing server/client model. More recently, most cloud-based test systems are being deployed. Test probes can be connected to two types of test systems.

Communication between the main components of the test system 7 may be performed via a cloud-based test server 20 (see FIG. 4 ).

This clouded test system 7 not only applies to validation of the eSIM RSP process (see Fig. 4), but also supports SMS and/or RAM (remote application management) over HTTP(s) via LTE/EPS.

In Fig. 4 different embodiments of a test probe 6 communicating via a core network interface or via a radio interface are shown.

The RSP test procedure using the cloudized test system 7 is as described above. A standard test sequence consisting of EPS ATTACH and trigger-SMS can be performed.

Below, key aspects related to the validation of manually triggered RSP processes are discussed.

A one-sided active test is performed. In this scenario the user initiates the test and then manually triggers the RSP process from their provisioning platform (the client 21). The test sequence is as follows:

- connect to the network (MNO(4), compare Figures 1 and 2 above);

- Wait until receiving provisioning SMS-MT or SM-DP+ address with AC token;

- wait for the eSIM provisioning HTTPs session between the eSIM card (5) and the RSP platform (1) (including the SM-SR module (3) or SM-DP+ (10)) to complete;

- Waiting for successful network reconnection using the newly provisioned eSIM profile;

- Isolation from the network.

The triggering step and checking whether the ordered and triggered eSIM profile has been downloaded correctly is initiated from the user side, ie via the test probe 6 .

input parameters

Standard test parameters should be included. In addition, a timeout parameter should be included so that the user can set a time limit to wait for provisioning trigger-SMS from the SM-SR module 3 . Examples are given in the table below:

Key Parameter Indicators (KPIs)

The following KPIs should be provided:

The verification result may be recorded in a result file. These files may be in Packet Capture (PCAP) format.

During RSP validation, the following failure criteria may be established:

- No SMS or subscription confirmation (AC) received from SM-SR (during user configured timeout period)

- HTTPs session not opened between RSP platform (SM-SR or SM-DP+) and SIM emulation or eSIM card (5) within SIM emulation module (18)

- The IMSI at the end is the same as the IMSI at the start

- Network reconnection to new APN after unsuccessful IMSI change.

In the case of an automatically triggered RSP (compared to the embodiment described in relation to FIG. 2 above), the active test system 7 according to FIG. 4 must use two interfaces for the RSP:

- One mobile interface for the RSP process itself

- One LAN interface to interact with the API of the RSP platform (1) under test.

These test sequences will have to be customized according to the platform under test being used by the customer.

The mobile interface part should have the same aspect as the manual trigger scenario discussed above:

- Connect to the network (MNO(4), compared to Figures 1 and 2 above)

- Wait for provisioning trigger - SMS

- Wait for HTTPs session between eSIM card (5) and RSP platform (1) (SM-SR module (3) or SM-DP+ (10)) to complete;

- Isolation from the network.

A LAN interface should be used to send API commands to the provisioning platform 21 . Commands such as download profile, delete profile or activation profile, for example, should be user configurable.

input parameters

As in the manual scenario, a timeout parameter must be included so that the user can set a time limit for the time to wait for provisioning trigger-SMS from the SM-SR module 3 .

Additional parameters for interacting with the API will have to be included, such as operation type, authentication to API, eSIM/eUICC ID (EID) - ID of the requested eSIM profile that needs to be provisioned, IMSI. A complete list of parameters may be specified based on a specific RSP platform API document.

Key parameter indicators

The following KPIs should be provided:

- IMSI at the start of the test

- IMSI at the end of the test

- IP session duration from PCAP file: duration of IP session between eSIM card (5) and SM-SR module (3) - This reflects the time taken to complete RSP operation i.e. profile download, activation, deactivation something to do.

- IP address of SM-SR module (3) or SM-DP+ module (10): from PCAP file

- IP Session Start Duration: If possible - Measured as the period between receiving a provisioning SMS or AC and starting an IP session (TCP SYN from mobile to RSP platform (1) (SM-SR or SM-DP+))

- Total provisioning period: period from sending API(1) trigger to completion of IP session

- SMS Receive Period: The period from sending the API trigger until the provisioning SMS is received.

- Subscription period: period from request for subscription to confirmation of subscription

A PCAP file may be provided as a result file.

During RSP validation, the following failure criteria may be established:

- No SMS or subscription confirmation (AC) received from SM-SR (during user configured timeout period)

- HTTPs session not opened between RSP platform (SM-SR or SM-DP+) and SIM emulation or eSIM card (5) within SIM emulation module (18)

- The IMSI at the end is the same as the IMSI at the start

- Unable to reach RSP platform via API.

For automatic ordering of the requested eSIM profile sequence according to the ordering schedule, the active test system may also include an ordering module, which may be part of the test probe 6 .

Claims (13)

A test method for verifying a remote eSIM provisioning (RSP) process, comprising:
- ordering (8; 13) an eSIM profile on the RSP platform under test (1);
- triggering (9; 14) the download of the ordered eSIM profile in the RSP platform (1);
- downloading (9a; 15) the eSIM profile triggered in the RSP platform (1) to the target eSIM or eUICC (5) in the test probe (6) via an over-the-air (OTA) interface;
- checking whether the order and triggered eSIM profile have been downloaded correctly;
- the test probe (6) is configured to simulate a Machine to Machine (M2M) device. A test method for verifying a remote eSIM provisioning (RSP) process, comprising:
- ordering (8; 13) an eSIM profile on the RSP platform under test (1);
- triggering (9; 14) the download of the ordered eSIM profile in the RSP platform (1);
- downloading (9a; 15) the eSIM profile triggered in the RSP platform (1) to the target eSIM or eUICC (5) in the test probe (6) via an over-the-air (OTA) interface;
- checking whether the order and triggered eSIM profile have been downloaded correctly;
- the test probe 6 is configured to simulate a smartphone and/or a consumer IoT device,
- the test scenario to be tested with the test method comprises a user side represented by the test probe (6),
- the triggering step (9; 14) and the confirming step are initiated from the user side. 3. The method of claim 1 or 2,
A test method, wherein, prior to placing an order, a subscription request (12) is sent from the test probe (6) to the sending entity (4) of the order. 4. The method according to any one of claims 1 to 3,
wherein the method comprises automatic ordering of an eSIM profile sequence according to an ordering schedule. 5. The method according to any one of claims 1 to 4,
During triggering, the RSP platform (1) sends a trigger SMS to the test probe (6) addressing the target eUICC (5).
6. The method of claim 5,
The triggering SMS triggers an HTTPs session or a Card Application Toolkit Transport Protocol (CAT_TP) session. 7. The method according to any one of claims 1 to 6,
During triggering, the test probe (6) establishes a Packet Data Network (PDN) connection to the gateway named in the triggering SMS. An active test system (7) providing a test method according to any one of claims 1 to 7, comprising:
- at least one test probe (6) comprising at least one target eSIM or eUICC (5) on which an initial working profile is installed;
- an interface to the RSP platform 1 for the remote provision of an eSIM profile different from the initial working profile;
- an active test system with an OTA interface for providing communication between the RSP platform (1) and the test probe (6). 9. The method of claim 8,
The RSP platform 1 is
- Subscription Manager Data Preparation (SM-DP) module (2);
- Subscription Manager Secure Routing (SM-SR) Module (3)
comprising, an active test system. 10. The method according to claim 8 or 9,
An active test system, characterized by an ordering module for automatic ordering of an eSIM profile sequence according to an ordering schedule. 11. The method according to any one of claims 8 to 10,
The RSP platform 1 is
- Subscription manager data preparation+ (SM-DP+) module (10);
- Subscription Manager Discovery Server (SM-DS) Module (11)
comprising, an active test system. 12. The method according to any one of claims 8 to 11,
An active test system, characterized by a SIM multiplexer (16) comprising a SIM server (17) and a plurality of eUICCs (5) in signal connection with the test probe (6). 12. The method according to any one of claims 8 to 11,
An active test system, characterized by a cloud-based server (20).

Images