3 Definitions of terms, symbols and abbreviations
31.1273GPPnon-removable Universal Subscriber Identity Module (nrUSIM) application behavioural test specificationRelease 17TSUICC-terminal interaction
3.1 Terms
For the purposes of the present document, the terms given in TR 21.905 [1], TS 31.121 [2] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1].
nrUSIM: non-removable Universal Subscriber Identity Module, i.e. a USIM application or equivalent functionality embedded or integrated into a ME.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
bx Bit x of byte (leftmost bit is MSB)
Bn Byte No. n
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1], TS 31.121 [2] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1].
CR Conformance Requirement
EUT Equipment Under Test
SA Suitability Assessment
TT Test Tool
3.4 Coding Conventions
For the purposes of the present document, the following coding conventions apply:
All lengths are presented in bytes, unless otherwise stated. Each byte B is represented by eight bits b8 to b1, where b8 is the most significant bit (MSB) and b1 is the least significant bit (LSB). In each representation, the leftmost bit is the MSB.
In the UICC, all bytes specified as RFU shall be set to ’00’ and all bits specifies as RFU shall be set to ‘0’. If the GSM and/or USIM application exists on a UICC or is built on a generic telecommunications card, then other values may apply for the non- GSM or non-USIM applications. The values will be defined in the appropriate specifications for such cards and applications. These bytes and bits shall not be interpreted by a Terminal in 3GPP session.
The coding of all data objects in the present document is according to ETSI TS 102 221 [8]. All data objects are BER-TLV except if otherwise defined.
3.5 Generic procedures for 5G‑NR, E‑UTRAN, NB‑IoT, UTRAN and IMS
If a test case contains the statement "This test applies to Terminals accessing 5G-NR", the procedures defined in TS 38.508‑1 [3] shall be the basis for all performed procedures during the test. The procedures in TS 38.508‑1 [3] clause 4.5 describe the default behaviour of a conformant UE regarding the specified protocols to be used for 5G-NR and the required procedures from the NAS.
If a test case contains the statement "This test applies to Terminals accessing NB", the procedures defined in TS 36.508 [4] shall be the basis for all performed procedures during the test. The procedures in TS 36.508 [4] clause 8.1.5 describe the default behaviour of a conformant UE regarding the specified protocols to be used for NB-IoT and the required procedures from the NAS.
If a test case contains the statement "This test applies to Terminals accessing E-UTRAN", the procedures defined in TS 36.508 [4] shall be the basis for all performed procedures during the test. The procedures in TS 36.508 [4], clause 4.5 describe the default behaviour of a conformant UE regarding the specified protocols to be used for E-UTRAN and the GH
3.6 Table of optional features
Support of several features is optional or release dependent for the user equipment. However, if a UE states conformance with a specific 3GPP release, it is mandatory for the UE to support all mandatory functions of that release, as stated in table A.1.
The supplier of the implementation shall state the support of possible options in table A.1.
Table A.1: Options
Item |
Option |
Status |
Support |
Mnemonic |
---|---|---|---|---|
1 |
Support of CS |
O |
O_CS |
|
2 |
Support of a feature requiring PIN2 entry (such as e.g. AoC or FDN) |
O |
O_PIN2_ENTRY_FEAT |
|
3 |
Support of UTRAN access |
O |
O_UTRAN |
|
4 |
Support of GERAN access |
N/A |
O_GERAN |
|
5 |
Support of Fixed Dialling Numbers |
O |
O_FDN |
|
6 |
Support of Advice of Charge Charging |
O |
O_AoCC |
|
7 |
Support of Higher Priority PLMN selector with Access Technology service |
O |
O_HPLMNwACT |
|
8 |
Support of local phonebook |
O |
O_LOCAL_PB |
|
9 |
Support of global phonebook |
C001 |
O_GLOBAL_PB |
|
10 |
Support of storing received Class 2 Short Messages in the USIM |
O |
O_STORE_CLASS2_SMS |
|
11 |
Support of MMS |
O |
O_MMS |
|
12 |
Support of usage of MMS related data stored on the USIM |
C002 |
O_MMS_USIM_DATA |
|
13 |
Supported of unselected user MMS connectivity parameters |
O |
O_NO_USER_MMS_CONF_SELEC |
|
14 |
Support of MMS notification storage on the USIM |
O |
O_MMS_NOTIF_STORAGE |
|
15 |
Support of ACL |
O |
O_ACL |
|
16 |
Support of SDN |
O |
O_SDN |
|
17 |
Support of numerical entry of PLMN codes in EF PLMNwACT |
O |
O_EFPLMNwACT_NUM_ENTRY |
|
18 |
Terminal does support speech call |
O |
O_SPEECH_CALL |
|
19 |
Terminal support PIN MMI strings |
O |
O_PIN_MMI_STRING |
|
20 |
Terminal does support eFDD |
O |
O_eFDD |
|
21 |
Terminal does support eTDD |
O |
O_eTDD |
|
22 |
Terminal does support CSG list handling (for E-UTRA) |
O |
O_CSG_LIST |
|
23 |
Terminal supports SM-over-IP-receiver |
O |
O_SM-OVER-IP_RECEIVER |
|
24 |
Terminal supports reading SMS’ stored in EF SMS on the USIM if USIM and ISIM are present |
O |
O_READ_USIM-EF_SMS_IF_USIM+ISIM |
|
25 |
Terminal supports reading SMS’ stored in EF SMS on the ISIM if USIM and ISIM are present |
O |
O_READ_ISIM-EF_SMS_IF_USIM+ISIM |
|
26 |
Terminal can store more than 1000 text messages |
O |
O_LARGE_SMS_STORAGE |
|
27 |
Support for multiple PDN connections |
O |
O_MULTIPLE_PDN |
|
28 |
Terminal does support CSG (for UTRA) |
O |
O_CSG |
|
29 |
Support of manual CSG selection |
O |
O_MANUAL_CSG_SELECTION |
|
30 |
Support of PS |
O |
O_PS |
|
31 |
Terminal does support display |
O |
O_DISPLAY |
|
32 |
Terminal does support keypad |
O |
O_KEYPAD |
|
33 |
Terminal supports E-UTRA Disabling Allowed for EMM cause #15 |
O |
O_DISABLE_EUTRA_EMM_CAUSE#15 |
|
34 |
Terminal supports Override NAS Signalling Low Priority |
O |
O_OVERRIDE_NAS_SLP |
|
35 |
Terminal supports T3245 timer |
O |
O_T3245 |
|
36 |
Terminal supports Override Extended Access Barring |
O |
O_OVERRIDE_EAB |
|
37 |
Terminal does support NB-IoT |
O |
O_NB-IoT |
|
38 |
MS maintains a list of PLMN-specific attempt counters |
O |
O_PLMN_ATTEMPT_COUNTER |
|
39 |
Terminal does support deactivation of the UICC in PSM. |
O |
O_PSM_DEAC_UICC |
|
40 |
Terminal does support deactivation of the UICC during extended DRX |
O |
O_eDRX_DEAC_UICC |
|
41 |
Terminal does support the UICC suspension mechanism in PSM. |
O |
O_PSM_SUSPEND_UICC |
|
42 |
Terminal does support the UICC suspension mechanism during extended DRX |
O |
O_eDRX_SUSPEND_UICC |
|
43 |
Support of 5G Core Network |
O |
O_5G_CN |
|
44 |
Support of 5G New Radio access |
O |
O_5G_NR |
|
45 |
Support of URSP by USIM |
O |
O_URSP_BY_USIM |
|
46 |
Terminal supports SUPI as Network Access Identifier (NSI, GLI or GCI) |
O |
O_SUPI_NAI |
|
47 |
Support of E-UTRAN access |
O |
O_E-UTRAN |
|
48 |
Support of RSP(SGP.22) |
O |
O_RSP22 |
|
49 |
Support of AT+CSIM |
O |
O_AT+CSIM |
|
50 |
ME supports non-removable UICC only (see NOTE 1) |
M |
O_NON-REMOVABLE_UICC_ONLY |
|
51 |
Support of UICC and USIM API for Java Card (see NOTE 2) |
O |
O_JAVA_CARD_API |
|
52 |
Support of USAT functionality (see NOTE 3) |
O |
O_USAT |
C001 |
If ((A.1/18 is supported) AND (A.1/31 is supported) AND (A.1/32 is supported)) THEN M, ELSE O |
C002 |
If (A.1/11 is NOT supported) THEN N/A, ELSE M |
NOTE1: |
‘ME supports non-removable UICC only’ means that access to the physical card interface as defined in ETSI TS 102 221 is not available |
NOTE 2: |
The UE shall claim to support the Java Card API if test relevant functions as defined in Annex A, clause A.2 are supported. |
NOTE 3: |
The support of the USAT functionalities as expected here requires the support of the UICC API defined in ETSI TS 102 241 [23] and the USIM API defined in TS 31.130 [17] |
3.7 Applicability
3.7.1 Applicability to user equipment
The applicability to user equipment supporting the non-removable USIM is specified in table B.1.
Test cases where no verification of APDUs or transferred data, timing, or checks on file (DF/EF) content is required, may refer to tests defined in TS 31.121 [2]. Regardless of references to complete tests, test purposes, conformance requirements or test methods from TS 31.121 [2] the applicability of the individual test cases is defined within the present document.
Tests where the implicit verification of conformance requirements is not considered sufficient on its own require additional (explicit) verification methods. The support of additional verification methods by the EUT has to be declared in accordance to table A.2 (see clause 3.7.2). Test sequence specific declarations of methods required to be supported are listed in the Applicability table – Table B.1.
3.7.2 Supported additional explicit verification methods
The support of additional verification methods is optional for an nrUICC operated device (EUT). As the implicit verification of test results is not sufficient in some test cases the support of an explicit testing option and the provisioning of an interface for file contents verification improves test coverage. The UE manufacturer shall declare the support of possible testable options listed in Table A.2. This declaration is used for the suitability assessment of the conformance requirement (CR) per test case.
Table A.2: Test Options Declaration
Item |
Option |
Status |
Support |
Mnemonic |
1 |
Support of Toolkit Test Events |
O |
O_Toolkit_Test_Events |
|
2 |
Support of seamless test APDU logging via Baseband |
O |
O_Seamless_APDU_Logging |
|
3 |
Interface for file contents verification |
O |
O_File_Contents_Verification |
|
4 |
Support of a test tool interface in accordance to ETSI TS 103 834 |
O |
O_SSP_TTI |
For details on these options see clauses 4.1.3, to 4.1.6 of the present document.
3.7.3 Applicability of the individual tests
Table B.1 lists the optional, conditional or mandatory features for which the supplier of the implementation states the support. As pre-condition the supplier of the implementation shall state the support of possible options in table A.1.
The "Release XY ME" columns shows the status of the entries as follows:
The following notations, defined in ISO/IEC 9646‑7 [7], are used for the status column:
M mandatory – the capability is required to be supported.
O optional – the capability may be supported or not.
N/A not applicable – in the given context, it is impossible to use the capability.
X prohibited (excluded) – there is a requirement not to use this capability in the given context.
O.i qualified optional – for mutually exclusive or selectable options from a set. "i" is an integer which identifies a unique group of related optional items and the logic of their selection which is defined immediately following the table.
Ci conditional – the requirement on the capability ("M", "O", "X" or "N/A") depends on the support of other optional or conditional items. "i" is an integer identifying an unique conditional status expression which is defined immediately following the table. For nested conditional expressions, the syntax "IF … THEN (IF … THEN … ELSE…) ELSE …" shall be used to avoid ambiguities.
The "Additional test case execution recommendation" column shows the status of the entries as follows:
A applicable – the test is applicable according to the corresponding entry in the "Rxx ME" column
R redundant – the test has to be considered as redundant when the corresponding E-UTRAN/EPC related test of the present document has been validated and successfully executed. In that case the requirement may be verified by means of the E-UTRAN/EPC functionality only.
AERi Additional test case Execution Recommendation – with respect to the above listed definitions of ("A") and ("R") the test is applicable ("A") or redundant ("R") depending on the support of other optional or conditional items. "i" is an integer identifying a unique conditional status expression which is defined immediately following the table. For nested conditional expressions, the syntax "IF … THEN (IF … THEN … ELSE…) ELSE …" shall be used to avoid ambiguities.
References to items
For each possible item answer (answer in the support column) there exists a unique reference, used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item number in the table. If there is more than one support column in a table, the columns shall be discriminated by letters (a, b, etc.), respectively.
EXAMPLE: A.1/4 is the reference to the answer of item 4 in table A.1.
3.8 Applicability table
The table for the applicability of tests, Table B.1: is available in a separate file (please follow the link)