SIMC Tab
In AMF Nodal, MME Nodal, UE Node , UMTS and Wifi Offload Gateway Nodal testing, the SIMC tab provides a means for adding SIM Clients. Up to 416 physical SIMs can be mapped to Landslide emulated UEs.
Landslide TAS & Test Cases act as Client and communicate with Implementa SimArrayllx through the proprietary interface(Extended SIMCP over TCP/IP) defined by Implementa. https://www.implementa.com/products/sim-array.
The TAS retrieves the information(such as IMSI) of SIM Cards inserted in Implementa SimArrayllx and manages the resources for each test-run. The Test Case such as AMF Nodal or MME Nodal communicates with Implementa SimArrayllx during the test-run to get the 3gpp authentication result from SIM card in Implementa SimArrayllx.
The Basic SIM Server system consists of three main components: SIM Array(s) and SIM Client(s) and SIM Emulators. SIM Array is a hardware unit that holds up to 13 hot-pluggable SIM Boards. Each SIM Board has a capacity of 32 SIM cards. Virtually any number of SIM Arrays can be combined to build huge “SIM farms”.
SIM Client is a software component that acts as a gateway between SIM Emulators and SIM Arrays. Each mobile device is equipped with a SIM Emulator inserted into its SIM Holder thereby replacing the physical SIM card. Different versions of SIM Emulators are available. Each mobile device connected to the system by means of a SIM Adapter is represented by a Channel entity in the application software and APIs.
SIM Arrays are typically placed in one or more central locations, while SIM Clients and Emulators are located remotely along with distributed mobile devices (e.g. GSM/UMTS terminals).
The assignment of SIM Cards to the Channels is managed by an external user supplied component.
The purpose of using SIM Server in AMF Nodal, MME Nodal and UE Node test cases is to use IMSI stored in USIM and execute LTE authentication by remotely accessing USIM card in SIM Server.
To communicate with SIM Server and access USIM card remotely, TAS and TS (AMF Nodal, MME Nodal, UE Node) use TCP/IP connection via eth0 (management network).
A single TAS can support up to 64 SIM servers connected to it thus the maximum SIM Cards supported is 64x412 = 26,368.
We added the ability to reuse the SIM card within the same Test Session. If there is a conflict, the user may see "SIM Slot already in use within this Test Session".
Retrieval of slot data queries to the SIM Server will be limited to once per 30 second window (if successful). We do not expect updates on the SIM Server that often and will keep the number of connections and request to a minimum. To protect the TAS from issues related to out of reach or misconfigured SIM Servers, if additional requests to the same SIM Array are within that 30 second window, all subsequent requests will return the latest cached slot information. If there are two consecutive failures, then the delay window will double to 60 seconds and continue to double after each consecutive failure until the delay window reaches a maximum of 15 minutes (6 or more consecutive failures). Once a successful query occurs the delay window will be reset to 30 seconds.
Here is example of the Real-Time logs you will see upon failures. Clearly identifying the next time a full query will be attempted:
General Settings - Add SIM (s)
|
|
General Settings
| Add SIM (s) |
Select to add a SIM to SIM Clients. SIMs are added via Admin vSIM Administration. Enter Filter search selection : SIM Array Name, SIM Array IP, Has SUPI (True or False), PLMN 1, 2, 3 (MCC, MNC) Table displays : SIM Array Name, SIM Array IP, SIM Array Port, SIM Slot, IMSI, MCC, MNC and iccid (each SIM is internationally identified by its integrated circuit card identifier), Has SUPI.
Has SUPI - Identifies whether a SIM card can be used for 5G core network testing - vSIM Administration. A new attribute “hasSupi” added to REST API response for “./api/simArrays/[#]. The new Boolean attribute Has SUPI is only retrievable with new version of SIM Server via command reportsims. Older versions of SIM Server will continue to retrieve slot data via command listsims (in this scenario – Has SUPI will be false) - Using the RESTFul API contains reference information about the Landslide RESTFul API system. Refer to Swagger UI on Landslide Home Page, it contains the latest most accurate information for anything it covers.
|
| SIMCP Command Response Time (ms) |
Enter the SIMCP Command response time in milliseconds. Range: 1000 to 30000 Default: 5000 Tcl Parameter: SimClnSimcpCmdRspTime |
| TCP Connection Timeout (ms) |
Enter the TCP Connection Timeout in milliseconds. Range: 100 to 30000 Default: 5000 Tcl Parameter: SimClnTcpConnTimeout |
| Retries |
Enter the number of Retries in case of connection failure Range: 0 to 5 Default: 2 Tcl Parameter: SimClnTcpConnRetries |
| ISim Aka Auth Fallback to USim |
If the SIM does not support ISIM AKA AUTH then by selecting this checkbox allow fallback to USIM AKA AUTH. Tcl Parameter: SimClnISimAkaAuthFallbackToUSimEn |
| Default Routing Indicator |
Available on AMF Nodal test case. This parameter is used as the default Routing Indicator only when UE can’t get Routing Indicator value in SUCI context because SIM in SimServer doesn’t provide SUCI context (e.g 4G SIM). Enter Routing Indicator. Per 3GPP 24.501, 9.11.3.4. (Should be in Binary-Coded decimal (BCD) format). Options: Enter 1 to 4 Hex characters (0 to 9, or F) in BCD format with padded F (s) Default : F0FF Example: If the input value is “ABCD”, Routing indicator digit1-4 described in 9.11.3.4 TS24.501 will be set as below: Routing indicator digit 1 is B Routing indicator digit 2 is A Routing indicator digit 3 is C Routing indicator digit 4 is D Tcl Parameter: SimClnDefaultRoutingInd |
| Apply Test Data File to Subscribers |
Available on AMF Nodal test case. The way the SIM table works, without the TDF option, is that the first entry is used by the first subscriber, the second entry used by the second subscriber, and so forth. With the SIM TDF the user can assign which SIM table entry a subscriber uses. An example – SIM TDF file: CustomKey Client ID 1234987 Client#6 1234984 Client#0 1234995 Client#1 1234979 Client#2 1234988 Client#4 1234989 Client#3 1234980 Client#5 If we sort the above based on CustomKey column we end up with: 1234979 Client#2 1234980 Client#5 1234984 Client#0 1234987 Client#6 1234988 Client#4 1234989 Client#3 1234995 Client#1 The first subscriber (1234979) will use Client#2, the second subscriber (1234980) will use Client#5, etc. This TDF option offers a quick way to make changes from run to run by using a different TDF file. Tests via automated scripts allow you to have multiple TDF files instead of multiple test cases. See sample TDF file used in the example above. Example file : simTDF.csv Tcl Parameter: SimClnTdfEn Tcl Parameter: SimClnTdf |
See the Landslide Tcl API Object and Perform Function Reference, go to the Parameter Class SimClient section for additional information.