13 General Tests
34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification
13.1 Emergency call / general
In this clause, the emergency call service is tested for user equipment that support Emergency speech call in the following cases:
– emergency call initiated in the MM idle state with authentication and with security mode procedure applied;
– emergency call initiated in the MM idle, no IMSI state (hence without authentication and without security mode procedure applied), the network accepting the call;
– emergency call initiated in the MM idle, no IMSI state (hence without authentication and without security mode procedure applied), the network rejecting the call.
13.2 Emergency call
Emergency call establishment can be initiated by an UE whether location updating has been successful or not and whether a USIM is inserted into the UE or not; but only if the UE is equipped for speech.
If the procedures tested in this clause are not correctly implemented in the UE, establishment, maintenance and clearing of connections might fail in the essential case of emergency calls.
13.2.1 Emergency call / with USIM
13.2.1.1 Emergency call / with USIM / accept case
13.2.1.1.1 Definition
When a USIM is present, subscriber specific emergency call set-up MMI shall be provided. The operator shall specify preferred emergency call MMI(s) (e.g. 911 for US citizens or 110, 118 and 119 for Japanese citizens) for use in any (i.e. home or visited) PLMN. This shall be stored in the USIM and the UE shall read this and use any entry of these digits to set up an emergency call. It shall be possible to store more than one instance of this field.
When a USIM containing stored emergency numbers is present, only those numbers are identified as emergency numbers, i.e. default emergency numbers stored in the UE are ignored.
13.2.1.1.2 Conformance requirement
1) A MM connection for an emergency call may be established in all states of the mobility management sublayer which allow MM connection establishment for a normal originating call.
When a user requests an emergency call establishment the UE will send a CM SERVICE REQUEST message to the network with a CM service type information element indicating emergency call establishment.
2) Having entered the "MM connection pending" state, upon MM connection establishment, the call control entity of the UE sends a setup message to its peer entity. This setup message is
– a SETUP message, if the call to be established is a basic call; and
– an EMERGENCY SETUP message, if the call to be established is an emergency call.
3) Upon receiving an indication that the call has been accepted, the call control entity of the network shall: through connect the traffic channel (including the connection of an interworking function, if required) and send a CONNECT message to its peer entity at the calling UE; start timer T313 and enter the "connect indication" state.
This message indicates to the call control entity of the calling UE that a connection has been established through the network.
4) The call control entity of the network shall initiate clearing by: sending a DISCONNECT message; and entering the "disconnect indication" state.
Reference(s):
– For conformance requirement 1: TS 24.008 clause 4.5.1.5, TS 22.101 clause 8.
– For conformance requirement 2: TS 24.008, clause 5.2.1.
– For conformance requirement 3: TS 24.008, clause 5.2.1.6.
– For conformance requirement 4: TS 24.008, clause 5.4.4.
13.2.1.1.3 Test purpose
1) To verify that an UE supporting speech in the state "MM idle", when made to call the emergency call number, sends a CM SERVICE REQUEST message specifying the correct CKSN and TMSI, with CM service type IE "emergency call establishment".
2) To verify that after security mode setting by the SS, the UE sends an EMERGENCY SETUP message.
3) To verify that, the SS having sent a CALL PROCEEDING message and then an ALERTING message the correct performance of a connect procedure and that the UE has through connected the DTCH in both directions.
4) To verify that the call is cleared correctly.
13.2.1.1.4 Method of test
Initial Conditions
– System Simulator:
– 1 cell, default parameters.
– User Equipment:
– the UE is in state "MM idle" with valid TMSI and CKSN.
Related ICS/IXIT Statement(s)
– Emergency speech call yes/no
Test procedure
The UE is made to initiate an emergency call. Having reached the active state, the call is cleared by the SS.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The "emergency number" is entered. Number shall be one programmed in test USIM EFECC (Emergency Call Codes), ref. 34.108 clause 8.3.2.21. |
||
2 |
–> |
UE establishes RRC procedure for emergency call. Establishment cause: Emergency Call |
||
3 |
Void |
|||
4 |
Void |
|||
5 |
–> |
CM SERVICE REQUEST |
The CM service type IE indicates "emergency call establishment". |
|
6 |
<– |
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
7 |
–> |
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
8 |
SS starts security procedure. |
|||
9 |
Void |
|||
10 |
Void |
|||
11 |
–> |
EMERGENCY SETUP |
If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. If the emergency category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 is not set to 1 |
|
12 |
<– |
CALL PROCEEDING |
||
13 |
<– |
ALERTING |
||
14 |
<– |
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
15 |
Void |
|||
16 |
<– |
CONNECT |
||
17 |
–> |
CONNECT ACKNOWLEDGE |
||
18 |
UE |
The DTCH is through connected in both directions. |
||
19 |
<– |
DISCONNECT |
SS disconnects the call and associated radio bearer. |
Specific Message Contents
None.
13.2.1.1.5 Test requirements
In step 2 of the Expected Sequence the UE shall establish RRC procedure with establishment cause Emergency Call.
In step 5 of the Expected Sequence the UE shall send a CM SERVICE REQUEST message with CM service type emergency call establishment.
In step 11 of the Expected Sequence the UE shall send an EMERGENCY SETUP message.
In step 18 of the Expected Sequence the UE has through connected the DTCH in both directions.
In step 19 of the Expected Sequence the call is cleared correctly.
13.2.2 Emergency call / without USIM
13.2.2.1 Emergency call / without USIM / accept case
13.2.2.1.1 Definition
The following emergency numbers shall be stored in the UE for use without USIM: 000, 08, 112, 110, 118, 119, 911 and 999.
13.2.2.1.2 Conformance requirement
1) A MM connection for an emergency call may be established in all states of the mobility management sublayer which allow MM connection establishment for a normal originating call.
When a user requests an emergency call establishment the UE will send a CM SERVICE REQUEST message to the network with a CM service type information element indicating emergency call establishment.
Normally, the UE will be identified by an IMSI or a TMSI. However, if none of these identifiers is available in the UE, then the UE shall use the IMEI for identification purposes.
2) As a serving network option, emergency calls may be established without the network having to apply the security mode procedure as defined in TS 24.008.
The following are the only cases where the "security procedure not applied" option may be used:
a) Authentication is impossible because the USIM is absent.
3) Having entered the "MM connection pending" state, upon MM connection establishment, the call control entity of the UE sends a setup message to its peer entity. This setup message is:
– a SETUP message, if the call to be established is a basic call; and
– an EMERGENCY SETUP message, if the call to be established is an emergency call.
4) Upon receiving an indication that the call has been accepted, the call control entity of the network shall: through connect the traffic channel (including the connection of an interworking function, if required) and send a CONNECT message to its peer entity at the calling UE; start timer T313 and enter the "connect indication" state.
This message indicates to the call control entity of the calling UE that a connection has been established through the network.
5) The call control entity of the network shall initiate clearing by: sending a DISCONNECT message; and entering the "disconnect indication" state.
Reference(s):
– For conformance requirement 1: TS 24.008 clause 4.5.1.5, TS 22.101 clause 8.
– For conformance requirement 2: TS 33.102, clause 6.4.9.2.
– For conformance requirements 3: TS 24.008, clause 5.2.1.
– For conformance requirement 4: TS 24.008, clause 5.2.1.6.
– For conformance requirement 5: TS 24.008, clause 5.4.4.
13.2.2.1.3 Test purpose
1) To verify that the UE in the "MM idle, no IMSI" state (no USIM inserted) when made to call the emergency call number, sends a CM SERVICE REQUEST message in which the ciphering key sequence number IE indicates "no key is available", the CM service type IE indicates "emergency call establishment" and the mobile identity IE specifies the IMEI of the UE.
2) To verify that after receipt of a CM SERVICE ACCEPT message without security mode procedure applied from the SS, the UE sends an EMERGENCY SETUP message.
3) To verify that the SS having sent a CALL PROCEEDING message and then an ALERTING message the correct performance of a connect procedure and that the UE has through connected the DTCH in both directions.
4) To verify that the call is cleared correctly.
13.2.2.1.4 Method of test
Initial Conditions
– System Simulator:
– 1 cell, default parameters.
– User Equipment:
– the UE is in MM-state "MM idle, no IMSI", no USIM inserted.
Related ICS/IXIT Statement(s)
– Emergency speech call yes/no
Test procedure
The UE is made to initiate an emergency call. The call is established without authentication and security. Having reached the active state, the call is cleared by the SS.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The "emergency number" is entered. One of the following emergency numbers shall be used: 000, 08, 112, 110, 118, 119, 911 or 999. |
||
2 |
–> |
UE establishes RRC procedure for emergency call. Establishment cause: Emergency Call |
||
3 |
Void |
|||
4 |
Void |
|||
5 |
–> |
CM SERVICE REQUEST |
The CM service type IE indicates "emergency call establishment". The mobile identity IE specifies the IMEI of the UE. The cipher key sequence number IE indicates "no key is available". |
|
6 |
<– |
CM SERVICE ACCEPT |
||
7 |
–> |
EMERGENCY SETUP |
If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. If the emergency category IE is included, then SS verifies that the Emergency Service Category IE bit 6 and bit 7 is not set to 1 |
|
8 |
<– |
CALL PROCEEDING |
||
9 |
<– |
ALERTING |
||
10 |
<– |
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
11 |
Void |
|||
12 |
<– |
CONNECT |
||
13 |
–> |
CONNECT ACKNOWLEDGE |
||
14 |
UE |
The DTCH is through connected in both directions. |
||
15 |
<– |
DISCONNECT |
SS disconnects the call and associated radio bearer. |
Specific Message Contents
None.
13.2.2.1.5 Test requirements
In step 2 of the Expected Sequence the UE shall establish RRC procedure with establishment cause Emergency Call.
In step 5 of the Expected Sequence the UE shall send a CM SERVICE REQUEST message with CM service type emergency call establishment, mobile identity IMEI and cipher key sequence number no key is available.
In step 7 of the Expected Sequence the UE shall send an EMERGENCY SETUP message.
In step 14 of the Expected Sequence the UE has through connected the DTCH in both directions.
In step 15 of the Expected Sequence the call is cleared correctly.
13.2.2.2 Emergency call / without USIM / reject case
13.2.2.2.1 Definition
The following emergency numbers shall be stored in the UE for use without USIM: 000, 08, 112, 110, 118, 119, 911 and 999.
13.2.2.2.2 Conformance requirement
1) A MM connection for an emergency call may be established in all states of the mobility management sublayer which allow MM connection establishment for a normal originating call.
When a user requests an emergency call establishment the UE will send a CM SERVICE REQUEST message to the network with a CM service type information element indicating emergency call establishment.
Normally, the UE will be identified by an IMSI or a TMSI. However, if none of these identifiers is available in the UE, then the UE shall use the IMEI for identification purposes.
2) If the network does not accept the emergency call request, e.g., because IMEI was used as identification and this capability is not supported by the network, the network will reject the request by returning a CM SERVICE REJECT message to the UE.
Reference(s):
– For conformance requirement 1: TS 24.008 clause 4.5.1.5, TS 22.101 clause 8.
– For conformance requirement 2: TS 24.008 clause 4.5.1.5.
13.2.2.2.3 Test purpose
1) To verify that the UE in the "MM idle, no IMSI" state (no USIM inserted) when made to call the emergency call number, sends a CM SERVICE REQUEST message in which the ciphering key sequence number IE indicates "no key is available", the CM service type IE indicates "emergency call establishment", and the mobile identity IE specifies the IMEI of the UE.
2) To verify that after receipt of a CM SERVICE REJECT message from the SS, the UE abandons the emergency call establishment.
13.2.2.2.4 Method of test
Initial Conditions
– System Simulator:
– 1 cell, default parameters.
– User Equipment:
– the UE is in state "MM idle, no IMSI", no USIM inserted.
Related ICS/IXIT Statement(s)
– Emergency speech call yes/no
Test procedure
The UE is made to initiate an emergency call. The call is established without authentication, and security. The SS responds to the CM SERVICE REQUEST from the UE with a CM SERVICE REJECT message specifying in the reject cause IE the reject cause value "IMEI not accepted". The SS then verifies for during 5 seconds that the UE does not send a layer 3 message. Then the call is cleared by the SS. The SS verifies during 20 seconds after disconnection of the main signalling link that the UE does not initiate a RRC connection establishment.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The "emergency number" is entered. One of the following emergency numbers shall be used: 000, 08, 112, 110, 118, 119, 911 or 999. |
||
2 |
–> |
UE establishes RRC procedure for emergency call. Establishment cause: Emergency Call |
||
3 |
Void |
|||
4 |
Void |
|||
5 |
–> |
CM SERVICE REQUEST |
The CM service type IE indicates "emergency call establishment". The mobile identity IE specifies the IMEI of the UE. The cipher key sequence number IE indicates "no key is available". |
|
6 |
<– |
CM SERVICE REJECT |
The reject cause IE specifies reject cause value #5, "IMEI not accepted". |
|
7 |
SS |
During 5 seconds, the SS verifies that the UE does not send L3 messages. |
||
8 |
Void |
|||
9 |
Void |
|||
10 |
SS |
During 20 seconds, the SS verifies that the UE does not initiate a RRC connection establishment |
Specific Message Contents:
None.
13.2.2.2.5 Test requirements
In step 2 of the Expected Sequence the UE shall establish RRC procedure with establishment cause Emergency Call.
In step 5 of the Expected Sequence the UE shall send a CM SERVICE REQUEST message with CM service type emergency call establishment, mobile identity IMEI and cipher key sequence number no key is available.
In step 6 of the Expected Sequence the UE shall abandon the emergency call establishment.
13.3 eCall Emergency Call Procedures
Conformance testing of eCall modem shall be performed per 3GPP TS 26.269 and is used for conformance testing of eCall modem core requirements. The test cases in clause 13.3 are for conformance testing of the eCall non-modem procedures.
13.3.1 eCall / with USIM
Two types of USIMs are used in performing the tests described below:
a) Type 1 USIM is one which has only subscription for eCall only service. UEs that contain this type of USIM are identified below as eCall Only capable UE.
b) Type 2 USIM is one which has subscription for eCall and other services. UEs that contain this type of USIM are identified below as eCall Capable UE.
13.3.1.1 Void
13.3.1.2 Test eCall using eCall capable UE with eCall only subscription
13.3.1.2.1 Definition and applicability
Applicable for all UEs supporting eCall with eCall only subscription and capable of triggering a Test eCall.
13.3.1.2.2 Conformance Requirement
The eCall inactivity procedure is applicable only to an eCall only mobile station (as determined by information configured in USIM).
[..]
While in eCALL INACTIVE state, the mobile station maintains awareness of a potential serving cell in a potential serving network but initiates no MM signalling with the network and ignores any paging requests.
The mobile station shall leave eCALL INACTIVE state only when one of the following events occur:
[..]
– if there is a CM request for a call to an HPLMN designated non-emergency MSISDN for the purpose of accessing test and terminal reconfiguration services: the mobile station attempts normal location updating. Once this is complete, further MM and CM procedures are used to establish the non-emergency call.
Reference(s)
TS24.008 clause 4.4.7
13.3.1.2.3 Test purpose
1. Verify that the eCall capable UE with an ‘eCall only’ enabled USIM is capable of making a test eCall.
13.3.1.2.4 Method of test
Initial conditions
The eCall capable UE is equipped with ‘eCall only’ enabled USIM
UE is powered on and in MM IDLE eCALL INACTIVE state. In this state the UE with an ‘eCall only’ subscription shall not be registered on a network but may perform a background scan to identify available PLMNs.
System Simulator
1 cell, default parameters
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°2 Service Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Display two FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting ‘eCall only’ support on the USIM yes/no
UE providing a means to trigger a Test eCall yes/no
Test Procedure
a) The UE is made to initiate a test eCall in accordance with manufacturer’s instructions. Upon successful completion of the test eCall, the call is cleared by the SS. (steps 1 – 27).
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. |
||
2 |
|
A test eCall is initiated using the number located in the EFFDN portion of the test USIM. Establishment cause: registration UE performs RRC procedure for network registration, LOCATION UPDATING |
||
3 |
|
LOCATION UPDATING REQUEST |
“Location Updating Type” = Normal Location Updating |
|
4 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
5 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
6 |
SS starts security procedure. |
|||
7 |
|
LOCATION UPDATING ACCEPT |
||
8 |
|
TMSI REALLOCATION COMPLETE |
||
9 |
SS releases the RRC Connection. |
|||
10 |
UE establishes RRC procedure for conversational call. Establishment cause: originating conversational call. |
|||
11 |
|
CM SERVICE REQUEST |
The CM service type IE indicates "originating conversational call". |
|
12 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
13 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
14 |
SS starts security procedure. |
|||
15 |
|
SETUP |
If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the test number is sent in the SETUP message. |
|
16 |
|
CALL PROCEEDING |
||
17 |
|
ALERTING |
||
18 |
|
SS sets up the radio bearer with the rate indicated by the SETUP message. |
||
19 |
|
CONNECT |
||
20 |
|
CONNECT ACKNOWLEDGE |
||
21 |
UE |
The DTCH is through connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
22 |
Void |
|||
23 |
|
DISCONNECT |
||
24 |
|
RELEASE |
||
25 |
|
RELEASE COMPLETE |
||
26 |
SS |
The SS releases the RRC connection |
||
27 |
|
CALL C.1 |
If the test result of C.1 indicates that UE is in idle Mode state, the test passes, otherwise it fails. |
Specific Message Contents
13.3.1.2.5 Test requirements
a) In step 2 UE shall make a test eCall to a number stored in the EFFDN portion of the test USIM. UE shall establish RRC procedure with establishment cause “Registration”.
b) In step 3 UE shall send a LOCATION UPDATING REQUEST message.
c) In step 15 UE shall send a SETUP message.
d) In step 21 UE has through connected the DTCH in both directions.
e) In step 24 UE shall send a RELEASE message.
f) In step 27 UE returns to Idle Mode.
13.3.1.3 Manually initiated eCall using eCall capable UE with “eCall only” subscription on USIM
13.3.1.3.1 Definition and applicability
Applicable for all UEs supporting eCall and support eCall only subscription and capable of initiating manual eCall.
13.3.1.3.2 Conformance Requirement
[..]
If eCall only calls are supported, then EFFDN shall only contain two entries. The first entry shall contain the eCall test number and the second entry shall contain the eCall reconfiguration number. A terminal in eCall only mode performs the FDN related procedures.
[…]
Reference(s)
TS31.102 clause 5.3.40.1
13.3.1.3.3 Test purpose
1 Verify that the eCall capable UE is able to make Emergency Call – USIM has capability for eCall only subscriptions
13.3.1.3.4 Method of test
Initial conditions
The eCall capable UE is equipped with ‘eCall only’ enabled USIM. If an eCall is to be established using emergency short codes, as specified in 24.008, then EFecc shall contain emergency short codes and associated Emergency Service Category bit 6 (MIeC) and bit 7 (AIeC) set to 1. Alternatively, AT+CECALL, as specified in TS27.007, commands may be used for eCall initiation.
UE is Switched OFF.
System Simulator
1 cell, default parameters
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°2 Fixed Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Display two FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting ‘eCall only’ support on the USIM yes/no
UE providing a means to trigger a manual eCall yes/no
Test procedure
a) The UE is made to initiate an eCall in accordance with manufacturer’s instructions. Upon successful completion of the eCall, the call is cleared by the SS. (steps 1 – 29)
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. UE is Switched ON. |
||
2 |
SS |
The SS verifies that the UE does not send RRC CONNECTION REQUEST message with the IE "Establishment cause" set to "Registration" for a period of 60 seconds. |
||
3 |
UE |
UE is made to initiate a manual eCall in accordance with manufacturer’s instructions |
||
4 |
|
UE performs RRC procedure for network registration and LOCATION UPDATING |
||
5 |
|
LOCATION UPDATING REQUEST |
“Location Updating Type” = Normal Location Updating |
|
6 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
7 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
8 |
SS starts security procedure. |
|||
9 |
|
LOCATION UPDATING ACCEPT |
||
10 |
|
TMSI REALLOCATION COMPLETE |
||
11 |
SS releases the RRC Connection. |
|||
12 |
UE establishes RRC procedure for emergency call. Establishment cause: emergency call. |
|||
13 |
|
CM SERVICE REQUEST |
The CM service type IE indicates "emergency call". |
|
14 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
15 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
16 |
SS starts security procedure. |
|||
17 |
|
EMERGENCY SETUP |
Emergency category set to Manually Initiated eCall. If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the Emergency Service Category IE bit 6 is set to 1 and all other bits are set to 0. |
|
18 |
|
CALL PROCEEDING |
||
19 |
|
ALERTING |
||
20 |
|
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
21 |
|
CONNECT |
||
22 |
|
CONNECT ACKNOWLEDGE |
||
23 |
UE |
The DTCH is through connected in both directions. Traffic channel is kept alive for at least 5 seconds. |
||
24 |
Void |
|||
25 |
|
DISCONNECT |
||
26 |
|
RELEASE |
||
27 |
|
RELEASE COMPLETE |
||
28 |
SS |
The SS releases the RRC connection |
||
29 |
|
CALL C.1 |
If the test result of C.1 indicates that UE is in MM IDLE state, the test passes, otherwise it fails. |
Specific Message Contents
EMERGENCY SETUP (Step 17)
Information Element |
Value/remark |
Emergency Service Category |
Bit 1 Police Bit 2 Ambulance Bit 3 Fire Brigade Bit 4 Marine Guard Bit 5 Mountain Rescue Bit 6 manually initiated eCall Bit 7 automatically initiated eCall Bit 8 Spare and set to "0" Manually initiated eCall: Bit 6 = 1 and all other bits set to 0 |
13.3.1.3.5 Test requirements
a. In step 1 UE is powered on.
b. In step 2 the UE shall remain in the eCALL INACTIVE state and shall not perform RRC procedures for network registration until an eCall is initiated.
c. In step 4 UE shall perform RRC procedures for network registration and Location Updating.
d. In step 5 UE shall send a LOCATION UPDATING REQUEST message.
e. In step 17 UE shall send an EMERGENCY SETUP message with the Emergency Service Category IE bit 6 = 1 and all other bits set to 0.
f. In step 23 UE has through connected the DTCH in both directions.
g. In step 26 UE shall send a RELEASE message.
h. In step 29 UE returns to Idle Mode.
13.3.1.4 Reconfiguration eCall using eCall capable UE with an ‘eCall only’ subscription on USIM
13.3.1.4.1 Definition and applicability
Applicable for all UEs supporting eCall and support ‘eCall only’ subscription and capable of triggering a reconfiguration eCall.
13.3.1.4.2 Conformance Requirement
The eCall inactivity procedure is applicable only to an eCall only mobile station (as determined by information configured in USIM).
[..]
While in eCALL INACTIVE state, the mobile station maintains awareness of a potential serving cell in a potential serving network but initiates no MM signalling with the network and ignores any paging requests.
The mobile station shall leave eCALL INACTIVE state only when one of the following events occur:
[..]
– if there is a CM request for a call to an HPLMN designated non-emergency MSISDN for the purpose of accessing test and terminal reconfiguration services: the mobile station attempts normal location updating. Once this is complete, further MM and CM procedures are used to establish the non-emergency call.
Reference(s)
TS24.008 clause 4.4.7
13.3.1.4.3 Test purpose
1. Verify that the eCall capable UE with an ‘eCall only’ subscription is capable of making a reconfiguration eCall, to facilitate removal of the ‘eCall only’ restrictions on the USIM and permit access to additional subscription services.
13.3.1.4.4 Method of test
Initial conditions
The eCall capable UE is equipped with ‘eCall only’ USIM
UE is powered on and in MM IDLE eCALL INACTIVE state. In this state the UE with an ‘eCall only’ subscription shall not be registered on a network but may perform a background scan to identify available PLMNs.
System Simulator
1 cell, default parameters,
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°2 Service Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Display two FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting ‘eCall only’ support on the USIM yes/no
UE providing a means to trigger a reconfiguration eCall yes/no
Test Procedure
a) The UE is made to initiate a reconfiguration eCall in accordance with manufacturer’s instructions. Upon successful completion of the reconfiguration eCall, the call is cleared by the SS. (steps 1 – 20)
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. |
||
2 |
|
UE establishes RRC procedures for network registration and a reconfiguration eCall using number located in the EFFDN portion of the test USIM. Establishment cause: registration |
||
3 |
|
LOCATION UPDATING REQUEST |
“Location Updating Type” = Normal Location Updating |
|
4 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
5 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
6 |
SS starts security procedure. |
|||
7 |
|
LOCATION UPDATING ACCEPT |
||
8 |
|
TMSI REALLOCATION COMPLETE |
||
9 |
SS releases the RRC Connection. |
|||
10 |
UE establishes RRC procedure for conversational call. Establishment cause: originating conversational call. |
|||
11 |
|
CM SERVICE REQUEST |
The CM service type IE indicates "originating conversational call". |
|
12 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
13 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
14 |
SS starts security procedure. |
|||
15 |
|
SETUP |
If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the reconfiguration number is sent in the SETUP message. |
|
16 |
|
CALL PROCEEDING |
||
17 |
|
ALERTING |
||
18 |
|
SS sets up the radio bearer with the rate indicated by the SETUP message. |
||
19 |
|
CONNECT |
||
20 |
|
CONNECT ACKNOWLEDGE |
||
21 |
UE |
The DTCH is through connected in both directions. Traffic channel is kept alive for at least 5 seconds. |
||
22 |
Void |
|||
23 |
|
DISCONNECT |
||
24 |
|
RELEASE |
||
25 |
|
RELEASE COMPLETE |
||
26 |
SS |
The SS releases the RRC connection |
Specific Message Contents
None.
13.3.1.4.5 Test requirements
a) In step 2 UE shall make a reconfiguration eCall to a number stored in the EFFDN portion of the test USIM. The UE shall establish RRC procedures for network registration and with establishment cause “Registration”.
b) In step 3 UE shall send a LOCATION UPDATING REQUEST message.
c) In step 15 UE shall send a SETUP message.
d) In step 21 UE has through connected the DTCH in both directions.
e) In step 24 UE shall send a RELEASE message.
13.3.1.5 Manually initiated eCall using eCall capable UE with eCall and non eCall subscriptions on USIM
13.3.1.5.1 Definition and applicability
Applicable for all UEs supporting eCall and support emergency speech call and eCall subscription and capable of initiating manual eCall.
13.3.1.5.2 Conformance Requirement
[..]
If eCall and normal calls are supported, then the last two entries of EFSDN shall contain the eCall test number and the eCall reconfiguration number respectively. A terminal in eCall and normal mode performs the SDN related procedures.
Reference(s)
TS31.102 clause 5.3.40.2
13.3.1.5.3 Test purpose
1. Verify that the eCall capable UE with both eCall and non eCall subscriptions on the USIM is able to make a manually initiated eCall.
13.3.1.5.4 Method of test
Initial conditions
The eCall capable UE is equipped with eCall Capable USIM that permits access to eCall and non-eCall subscription services. If an eCall is to be established using emergency short codes, as specified in 24.008, then EFecc shall contain emergency short codes and associated Emergency Service Category bit 6 (MIeC) and bit 7 (AIeC) set to 1. Alternatively, AT+CECALL, as specified in TS27.007, commands may be used for eCall initiation.
UE is switched on, is registered on a PLMN and is in MM IDLE state.
System Simulator
1 cell, default parameters
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°4 Service Dialling Numbers (SDN) and Service n°89 eCall Data available |
EFSDN |
Last two entries of SDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting eCall Capable support on the USIM yes/no
UE providing a means to trigger a manual eCall yes/no
Test Procedure
a) The UE is made to initiate an eCall in accordance with manufacturer’s instructions. Upon successful completion of the eCall, the call is cleared by the SS. (steps 1 – 20).
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. UE is made to initiate a manual eCall in accordance with manufacturer’s instructions. |
||
2 |
|
UE performs RRC procedure with cause “Emergency call”. |
||
3 |
|
CM SERVICE REQUEST |
The CM service type IE indicates "emergency call establishment". |
|
4 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
5 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
6 |
SS starts security procedure. |
|||
7 |
Void |
|||
8 |
Void |
|||
9 |
|
EMERGENCY SETUP |
Emergency category set to Manually Initiated eCall. If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the Emergency Service Category IE bit 6 is set to 1 and all other bits are set to 0. |
|
10 |
|
CALL PROCEEDING |
||
11 |
|
ALERTING |
||
12 |
|
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
13 |
|
CONNECT |
||
14 |
|
CONNECT ACKNOWLEDGE |
||
15 |
UE |
The DTCH is through connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
16 |
Void |
|||
17 |
|
DISCONNECT |
||
18 |
|
RELEASE |
||
19 |
|
RELEASE COMPLETE |
||
20 |
SS |
The SS releases the RRC connection |
Specific Message Contents
EMERGENCY SETUP (Step 9)
Information Element |
Value/remark |
Emergency Service Category |
Bit 1 Police Bit 2 Ambulance Bit 3 Fire Brigade Bit 4 Marine Guard Bit 5 Mountain Rescue Bit 6 manually initiated eCall Bit 7 automatically initiated eCall Bit 8 Spare and set to "0" Manually initiated eCall: Bit 6 = 1 and all other bits set to 0 |
13.3.1.5.5 Test requirements
a. In step 1 UE is made to initiate a manual eCall in accordance with manufacturer’s instructions.
b. In step 2 UE shall perform RRC procedure for Emergency Call.
c. In step 3 UE shall send a CM SERVICE REQUEST message.
d. In step 9 UE shall send an EMERGENCY SETUP message with the Emergency Service Category IE bit 6 = 1 and all other bits set to 0.
e. In step 15 UE has through connected the DTCH in both directions.
f. In step 18 UE shall send a RELEASE message.
13.3.1.6 eCall Inactivity State after T3242 expires
13.3.1.6.1 Definition and applicability
Applicable for all UEs supporting eCall and ‘eCall only’ subscription and capable of initiating manual eCall.
13.3.1.6.2 Conformance Requirement
[..]
The eCall inactivity procedure is applicable only to an ‘eCall only’ mobile station (as determined by information configured in USIM). The procedure shall be started when timer T3242 or timer T3243 expires or is found to have already expired in any MM Idle state except NO IMSI, NO CELL AVAILABLE or PLMN SEARCH. The mobile station shall then stop other running timers (e.g. T3211, T3212, T3213) and shall perform the IMSI detach procedure if required by the serving network and if the update state is U1. The mobile station then enters MM Idle eCALL INACTIVE state and the mobile station shall delete any LAI, TMSI, ciphering key sequence number stored in the SIM/USIM and set the update state to U4 Updating Disabled.
While in eCALL INACTIVE state, the mobile station maintains awareness of a potential serving cell in a potential serving network but initiates no MM signalling with the network and ignores any paging requests.
The mobile station shall leave eCALL INACTIVE state only when one of the following events occur:
– if the SIM or USIM is removed, the mobile station enters the NO IMSI state;
– if coverage is lost, the mobile station enters PLMN SEARCH state;
– if the mobile station is deactivated (e.g. powered off) by the user: the mobile station enters the NULL state;
– if there is a CM request for an emergency services call: the MS uses the MM and CM procedures to establish the emergency call; or
– if there is a CM request for a call to an HPLMN designated non-emergency MSISDN for the purpose of accessing test and terminal reconfiguration services: the mobile station attempts normal location updating. Once this is complete, further MM and CM procedures are used to establish the non-emergency call.
Reference(s)
TS24.008 clause 4.4.7
13.3.1.6.3 Test purpose
1 Verify that ‘eCall only’ capable UE enters eCall inactivity state after T3242 expires and leaves this state only when specified events occur.
13.3.1.6.4 Method of test
Initial conditions
The ‘eCall only’ capable UE is equipped with ‘eCall only’ enabled USIM. If an eCall is to be established using emergency short codes, as specified in 24.008, then EFecc shall contain emergency short codes and associated Emergency Service Category bit 6 (MIeC) and bit 7 (AIeC) set to 1. Alternatively, AT+CECALL, as specified in TS27.007, commands may be used for eCall initiation.
UE is in eCall inactive eCALL INACTIVE state
System Simulator
- 1 cell, default parameters,
- the T3212 time-out value is 252 minutes.
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°2 Service Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Last two entries of FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting ‘eCall only’ enabled USIM yes/no
UE providing a means to trigger a manual eCall yes/no
Test Procedure
a) The UE is made to initiate an eCall in accordance with manufacturer’s instructions. Upon successful completion of the eCall, the call is cleared by the SS. (steps 1 – 48).
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. UE is made to initiate a manual eCall in accordance with manufacturer’s instructions. |
||
2 |
|
UE performs RRC procedures for network registration and Location Updating. |
||
3 |
|
LOCATION UPDATING REQUEST |
“LOCATION UPDATING TYPE”= Normal Location Updating |
|
4 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
5 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
6 |
SS starts security procedure. |
|||
7 |
|
LOCATION UPDATING ACCEPT |
||
8 |
|
TMSI REALLOCATION COMPLETE |
||
9 |
SS releases the RRC Connection. |
|||
10 |
UE establishes RRC procedure for emergency call. Establishment cause: emergency call. |
|||
11 |
|
CM SERVICE REQUEST |
The CM service type IE indicates " emergency call". |
|
12 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
13 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
14 |
SS starts security procedure. |
|||
15 |
|
EMERGENCY SETUP |
Emergency category set to Manually Initiated eCall. If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the Emergency Service Category IE bit 6 is set to 1 and all other bits are set to 0. |
|
16 |
|
CALL PROCEEDING |
||
17 |
|
ALERTING |
||
18 |
|
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
19 |
|
CONNECT |
||
20 |
|
CONNECT ACKNOWLEDGE |
||
21 |
UE |
The DTCH is connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
22 |
Void |
|||
23 |
|
DISCONNECT |
||
24 |
|
RELEASE |
||
25 |
|
RELEASE COMPLETE |
||
26 |
SS |
The SS releases the RRC Connection |
||
27 |
SS |
For next 12 hours SS verifies that UE sends Location Update Request periodically every 252 minutes and remains registered until T3242 expires |
||
27A |
|
IMSI DETACH INDICATION |
The UE performs IMSI Detach after timer T3242 expires |
|
28 |
SS |
The SS releases the RRC connection |
||
29 |
UE |
UE is made to initiate a manual eCall in accordance with manufacturer’s instructions. |
||
30 |
|
UE performs RRC procedure for Location Updating. |
||
31 |
|
LOCATION UPDATING REQUEST |
“LOCATION UPDATING TYPE”= Normal Location Updating |
|
32 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
33 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
34 |
SS starts security procedure. |
|||
35 |
|
LOCATION UPDATING ACCEPT |
||
36 |
|
TMSI REALLOCATION COMPLETE |
||
37 |
|
EMERGENCY SETUP |
Emergency category set to Manually Initiated eCall. If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the Emergency Service Category IE bit 6 is set to 1 and all other bits are set to 0. |
|
38 |
|
CALL PROCEEDING |
||
39 |
|
ALERTING |
||
40 |
|
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
41 |
|
CONNECT |
||
42 |
|
CONNECT ACKNOWLEDGE |
||
43 |
UE |
The DTCH is connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
44 |
Void |
|||
45 |
|
DISCONNECT |
||
46 |
|
RELEASE |
||
47 |
|
RELEASE COMPLETE |
||
48 |
SS |
The SS releases the RRC Connection |
Specific Message Contents
EMERGENCY SETUP (Steps 15 and 37)
Information Element |
Value/remark |
Emergency Service Category |
Bit 1 Police Bit 2 Ambulance Bit 3 Fire Brigade Bit 4 Marine Guard Bit 5 Mountain Rescue Bit 6 manually initiated eCall Bit 7 automatically initiated eCall Bit 8 Spare and set to "0" Manually initiated eCall: Bit 6 = 1 and all other bits set to 0 |
13.3.1.6.5 Test requirements
a. In step 1 UE is made to initiate a manual eCall in accordance with manufacturer’s instructions.
b. In step 2 UE shall perform RRC procedure for network registration and Location Updating.
c. In step 3 UE shall send a LOCATION UPDATING REQUEST message.
d. In step 15 UE shall send an EMERGENCY SETUP message with Emergency Service Category IE bit 6 = 1 and all other bits set to 0.
e. In step 21 UE has through connected the DTCH in both directions.
f. In step 24 UE shall send a RELEASE message.
g. In steps 27 UE shall remain registered on the network for a duration of T3242 following completion of eCall. UE shall detach from network upon expiry of T3242.
h. In step 29 UE is made to initiate a manually initiated eCall in accordance with manufacturer’s instructions.
i. In step 31 UE shall send a LOCATION UPDATING REQUEST message with “Location Updating Type” = Normal Location Updating.
j. In step 37 UE shall send an EMERGENCY SETUP message with Emergency Service Category IE bit 6 = 1 and all other bits set to 0.
k. In step 43 UE has through connected the DTCH in both directions.
l. In step 46 UE shall send a RELEASE message.
13.3.1.7 Automatically initiated eCall
13.3.1.7.1 Definition and applicability
Applicable for all UEs supporting eCall and support emergency speech and eCall only subscription and capable of initiating automatic eCall.
13.3.1.7.2 Conformance Requirement
[..]
If eCall only calls are supported, then EFFDN shall only contain two entries. The first entry shall contain the eCall test number and the second entry shall contain the eCall reconfiguration number. A terminal in eCall only mode performs the FDN related procedures
Reference(s)
TS31.102 clause 5.3.40.2
13.3.1.7.3 Test purpose
Verify that while making eCall automatically, eCall capable UE provides appropriate Service Category information to the network.( Bit 7 should be set).
13.3.1.7.4 Method of test
Initial conditions
The eCall capable UE is equipped with an eCall only enabled USIM. If an eCall is to be established using emergency short codes, as specified in 24.008, then EFecc shall contain emergency short codes and associated Emergency Service Category bit 6 (MIeC) and bit 7 (AIeC) set to 1. Alternatively, AT+CECALL, as specified in TS27.007, commands may be used for eCall initiation.
UE is in eCall Inactive State.
System Simulator
1 cell, default parameters.
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°4 Service Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Last two entries of FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting eCall Only Capable support on the USIM yes/no
UE providing a means to trigger an automatic eCall yes/no
Test Procedure
a) The UE is made to initiate an eCall in accordance with manufacturer’s instructions. Upon successful completion of the eCall, the call is cleared by the SS. (steps 1 – 26)
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. UE is made to initiate an automatic eCall in accordance with manufacturer’s instructions. |
||
2 |
|
UE performs RRC procedure for Location Updating |
||
3 |
|
LOCATION UPDATING REQUEST |
“Location Updating Type” = Normal Location Updating |
|
4 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
5 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
6 |
SS starts security procedure. |
|||
7 |
|
LOCATION UPDATING ACCEPT |
||
8 |
|
TMSI REALLOCATION COMPLETE |
||
9 |
SS releases the RRC Connection. |
|||
10 |
UE establishes RRC procedure for emergency call. Establishment cause: emergency call. |
|||
11 |
|
CM SERVICE REQUEST |
The CM service type IE indicates " emergency call". |
|
12 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
13 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
14 |
SS starts security procedure. |
|||
15 |
|
EMERGENCY SETUP |
Emergency category set to Automatic Initiated eCall. If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the Emergency Service Category IE bit 7 is set to 1 and all other bits are set to 0. |
|
16 |
|
CALL PROCEEDING |
||
17 |
|
ALERTING |
||
18 |
|
SS sets up the radio bearer with the rate indicated by the EMERGENCY SETUP message. |
||
19 |
|
CONNECT |
||
20 |
|
CONNECT ACKNOWLEDGE |
||
21 |
UE |
The DTCH is through connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
22 |
Void |
|||
23 |
|
DISCONNECT |
||
24 |
|
RELEASE |
||
25 |
|
RELEASE COMPLETE |
||
26 |
SS |
The SS releases the RRC connection |
Specific Message Contents
EMERGENCY SETUP (Step 15)
Information Element |
Value/remark |
Emergency Service Category |
Bit 1 Police Bit 2 Ambulance Bit 3 Fire Brigade Bit 4 Marine Guard Bit 5 Mountain Rescue Bit 6 manually initiated eCall Bit 7 automatically initiated eCall Bit 8 Spare and set to "0" Automatically initiated eCall: Bit 7 = 1 and all other bits set to 0 |
13.3.1.7.5 Test requirements
a) In step 1 UE is made to initiate an automatic eCall in accordance with manufacturer’s instructions.
b) In step 2 UE shall perform RRC procedure for network registration and Location Updating.
c) In step 3 UE shall send a LOCATION UPDATING REQUEST message.
d) In step 15 UE shall send an EMERGENCY SETUP message with the Emergency Service Category IE bit 7 = 1 and all other bits set to 0..
e) In step 21 UE has through connected the DTCH in both directions.
f) In step 24 UE shall send a RELEASE message.
13.3.1.8 Void
13.3.1.9 Void
13.3.1.10 eCall Inactivity State after T3243 expires
13.3.1.10.1 Definition and applicability
Applicable for all UEs supporting eCall and ‘eCall only’ subscription and capable of triggering a Test eCall.
13.3.1.10.2 Conformance Requirement
[..]
The eCall inactivity procedure is applicable only to an ‘eCall only’ mobile station (as determined by information configured in USIM). The procedure shall be started when timer T3242 or timer T3243 expires or is found to have already expired in any MM Idle state except NO IMSI, NO CELL AVAILABLE or PLMN SEARCH.
[..]
While in eCALL INACTIVE state, the mobile station maintains awareness of a potential serving cell in a potential serving network but initiates no MM signalling with the network and ignores any paging requests.
The mobile station shall leave eCALL INACTIVE state only when one of the following events occur:
[..]
— if there is a CM request for a call to an HPLMN designated non-emergency MSISDN for the purpose of accessing test and terminal reconfiguration services: the mobile station attempts normal location updating. Once this is complete, further MM and CM procedures are used to establish the non-emergency call.
Reference(s)
3GPP TS 24.008 clause 4.4.7
13.3.1.10.3 Test purpose
1 Verify that ‘eCall only’ capable UE enters eCall inactivity state after T3243 expires and leaves this state only when specified events occur.
13.3.1.10.4 Method of test
Initial conditions
The ‘eCall only’ capable UE is equipped with ‘eCall only’ enabled USIM. If an eCall is to be established using emergency short codes, as specified in 24.008, then EFecc shall contain emergency short codes and associated Emergency Service Category bit 6 (MIeC) and bit 7 (AIeC) set to 1. Alternatively, AT+CECALL, as specified in TS27.007, commands may be used for test eCall initiation.
UE is in eCALL INACTIVE state
System Simulator
- 1 cell, default parameters,
- the T3212 time-out value is 252 minutes.
The UE is equipped with a USIM containing default values except for those listed below.
USIM field |
Value/Remark |
EFUST |
Service n°2 Service Dialling Numbers (FDN) and Service n°89 eCall Data available |
EFFDN |
Last two entries of FDNs, eCall Test Number (123456) and eCall reconfiguration number (345678) |
EFEST |
Enabled Services Table |
Related ICS/IXIT statement(s)
UE supporting ‘eCall only’ support on the USIM yes/no
UE providing a means to trigger a test eCall yes/no
Test Procedure
- The UE is powered on. SS monitors to verify that UE does not attempt to register for a period of 120 seconds.
- The UE is made to initiate a test eCall in accordance with manufacturer’s instructions. SS checks that UE performs registration before starting test eCall.
- The UE, having reached the ACTIVE state, call is cleared by the SS. SS monitors to verify that UE remains registered for the duration of T3243 (12 Hours) and sends periodic LAU messages as T3212 timer is set to 252 minutes.
- Upon expiry of timer T3243, the UE shall perform IMSI detach.
Expected sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE contains test USIM with data specified under initial conditions. The UE is switched on. |
||
2 |
SS |
The SS verifies for 120 sec that the UE does not send RACH or any other message. |
||
3 |
UE |
UE is made to initiate a test eCall in accordance with manufacturer’s instructions. |
||
4 |
|
UE performs RRC procedures for network registration and Location Updating. |
||
5 |
|
LOCATION UPDATING REQUEST |
“LOCATION UPDATING TYPE”= Normal Location Updating |
|
6 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
7 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
8 |
SS starts security procedure. |
|||
9 |
|
LOCATION UPDATING ACCEPT |
||
10 |
|
TMSI REALLOCATION COMPLETE |
||
11 |
SS releases the RRC Connection. |
|||
12 |
UE establishes RRC procedure for conversational call. Establishment cause: originating conversational call. |
|||
13 |
|
CM SERVICE REQUEST |
The CM service type IE indicates " originating conversational call". |
|
14 |
|
AUTHENTICATION REQUEST |
IE Authentication Parameter AUTN shall be present in the message. |
|
15 |
|
AUTHENTICATION RESPONSE |
SRES specifies correct value. |
|
16 |
SS starts security procedure. |
|||
17 |
|
SETUP |
If the Bearer capability IE is not included the default UMTS AMR speech version shall be assumed. SS verifies that the test number is sent in the SETUP message. |
|
18 |
|
CALL PROCEEDING |
||
19 |
|
ALERTING |
||
20 |
|
SS sets up the radio bearer with the rate indicated by the SETUP message. |
||
21 |
|
CONNECT |
||
22 |
|
CONNECT ACKNOWLEDGE |
||
23 |
UE |
The DTCH is connected in both directions. Traffic channel is kept active for at least 5 seconds. |
||
24 |
|
DISCONNECT |
||
25 |
|
RELEASE |
||
26 |
|
RELEASE COMPLETE |
||
27 |
SS |
The SS releases the RRC Connection |
||
28 |
SS |
For next 12 hours SS verifies that UE sends Location Update Request periodically every 252 minutes and remains registered until T3243 expires UE performs IMSI Detach after timer T3243 expires |
||
29 |
|
IMSI DETACH INDICATION |
"mobile identity" contains IMSI of UE. |
|
30 |
SS |
The SS releases the RRC connection |
13.3.1.10.5 Test requirements
a. In step 3 UE is made to initiate a test eCall in accordance with manufacturer’s instructions.
b. In step 4 UE shall perform RRC procedure for network registration and Location Updating.
c. In step 5 UE shall send a LOCATION UPDATING REQUEST message.
d. In step 17 UE shall send a SETUP message.
e. In step 23 UE has through connected the DTCH in both directions.
f. In step 25 UE shall send a RELEASE message.
g. In step 28 UE shall remain registered on the network for a duration of T3243 following completion of test eCall. UE shall detach from network upon expiry of T3243.
h. In step 29 UE shall send a IMSI DETACH INDICATION message.
13.4 Emergency calls over IMS
13.4.1 Emergency bearer services over IMS / NORMAL-SERVICE / Success
13.4.1.1 Definition
13.4.1.2 Conformance requirement
1) The MS initiates the Service request procedure by sending a SERVICE REQUEST message. The timer T3317 shall be started after the SERVICE REQUEST message has been sent and state GMM-SERVICE-REQUEST-INITIATED is entered. The message SERVICE REQUEST shall contain the P-TMSI and the Service type shall indicate either "data", "signalling", "paging response", "MBMS multicast service reception" or "MBMS broadcast service reception". The MS shall not issue another Service request when the MS is in state GMM-SERVICE-REQUEST-INITIATED.
2) In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts timer T3380. The message contains the selected NSAPI, PDP type, requested QoS and, if the MS requests a static address, the PDP address. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. The MS may indicate the support of Network Requested Bearer Control procedures in the protocol configuration options information element. The MS supporting S1 mode shall include interactive or background traffic class in the QoS requested. The MS not supporting S1 mode should include interactive or background traffic class in the QoS requested. If there is a subscribed QoS profile available for the MS, the network may ignore the requested QoS and apply the subscribed QoS profile (see 3GPP TS 23.060 [74]).
The MS shall set the request type to "initial request" when the MS is establishing connectivity to an additional PDN for the first time, i.e. when it is an initial attach to that PDN. The MS shall set the request type to "handover" when the connectivity to a PDN is established upon handover from a non-3GPP access network and the MS was connected to that PDN before the handover to the 3GPP access network. If the MS is establishing connectivity for emergency bearer services it shall set the request type to "emergency" and not include an APN in the ACTIVATE PDP CONTEXT REQUEST message.
3) In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the network enters the state PDP-INACTIVE-PENDING and starts timer T3390. The message contains the transaction identifier (TI) in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes:
# 25: LLC or SNDCP failure (A/Gb mode only);
# 26: insufficient resources;
# 36: regular deactivation; or
# 37: QoS not accepted.
Reference
3GPP TS 24.008 clause 4.7.13, 6.1.3.1 and 6.1.3.4
13.4.1.3 Test purpose
To test the behaviour of the UE When a user requests an emergency call establishment the mobile station.
13.4.1.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
– the UE is in MM-state "GMM-REGISTERED.NORMAL-SERVICE",
– the emergency number list was send to UE with ATTACH ACCEPT message during the UE register in the cell.
Related ICS/IXIT statements
– PS Supported yes/no
– Auto Attach supported yes / no
– Method of context activation
Test procedure
1) Call the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure.
2) The UE sends a DEACTIVATE PDP CONTEXT REQUEST message to the network, The SS shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1-21 |
– |
Steps 1 to 21 of the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure. |
||
22 |
UE |
After the Emergency bearers service completed, the UE Initiate a context deactivation |
||
23 |
|
DEACTIVATE PDP CONTEXT REQUEST |
Request deactivation of the emergency PDP context. |
|
24 |
|
DEACTIVATE PDP CONTEXT ACCEPT |
SS accepts the emergency PDP context deactivation. |
Specific message contents
None.
13.4.1.5 Test requirements
At Step 9, the UE shall transmit an ACTIVATE PDP CONTEXT REQUEST with Request type set to “emergency”.
13.4.2 Emergency bearer services over IMS / LIMITTED-SERVICE / Success
13.4.2.1 Definition
13.4.2.2 Conformance requirement
1) In state GMM-DEREGISTERED, the MS initiates the GPRS attach procedure by sending an ATTACH REQUEST message to the network, starts timer T3310 and enters state GMM-REGISTERED-INITIATED.
If the MS is configured for "AttachWithIMSI" as specified in 3GPP TS 24.368 [135] and the selected PLMN is neither the registered PLMN nor in the list of equivalent PLMNs, the MS shall include the IMSI in the Mobile identity IE in the ATTACH REQUEST message.
…
If the MS is attaching for emergency bearer services and does not hold a valid GUTI, Mobile identity as described above, the IMEI shall be included in the Mobile identity IE.
The MS shall also indicate within the DRX parameters whether it supports the split pg cycle option on CCCH. The optional support of the split pg cycle on CCCH by the network is indicated in SI13 or PSI1. Split pg cycle on CCCH is applied by both the network and the MS when the split pg cycle option is supported by both (see 3GPP TS 45.002 [32]).
In Iu mode, if the MS wishes to prolong the established PS signalling connection after the GPRS attach procedure (for example, the MS has any CM application request pending), it may set a follow-on request pending indicator on (see subclause 4.7.13).
An MS attaching for emergency bearer services shall set the follow-on request pending indicator.
2) During an attach for emergency bearer services, if not restricted by local regulations, the network shall not check for mobility and access restrictions, regional restrictions, subscription restrictions, or perform CSG access control when processing the ATTACH REQUEST message. The network shall not apply APN based congestion control during an attach procedure for emergency bearer services.
3) In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts timer T3380. The message contains the selected NSAPI, PDP type, requested QoS and, if the MS requests a static address, the PDP address. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. The MS may indicate the support of Network Requested Bearer Control procedures in the protocol configuration options information element. The MS supporting S1 mode shall include interactive or background traffic class in the QoS requested. The MS not supporting S1 mode should include interactive or background traffic class in the QoS requested. If there is a subscribed QoS profile available for the MS, the network may ignore the requested QoS and apply the subscribed QoS profile (see 3GPP TS 23.060 [74]).
The MS shall set the request type to "initial request" when the MS is establishing connectivity to an additional PDN for the first time, i.e. when it is an initial attach to that PDN. The MS shall set the request type to "handover" when the connectivity to a PDN is established upon handover from a non-3GPP access network and the MS was connected to that PDN before the handover to the 3GPP access network. If the MS is establishing connectivity for emergency bearer services it shall set the request type to "emergency" and not include an APN in the ACTIVATE PDP CONTEXT REQUEST message.
4) In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the network enters the state PDP-INACTIVE-PENDING and starts timer T3390. The message contains the transaction identifier (TI) in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes:
# 25: LLC or SNDCP failure (A/Gb mode only);
# 26: insufficient resources;
# 36: regular deactivation; or
# 37: QoS not accepted.
5) The GPRS detach procedure is used:
– to detach the IMSI for GPRS services only. Independent of the network operation mode, this procedure is used by all kind of GPRS MSs;
– as a combined GPRS detach procedure used by GPRS MSs operating in MS operation mode A or B to detach the IMSI for GPRS and non-GPRS services or for non-GPRS services only, if the network operates in network operation mode I and no circuit-switched transaction is ongoing;
– in the case of a network failure condition to indicate to the MS that a re-attach with successive activation of previously active PDP contexts shall be performed. In this case, the MS may also perform the procedures needed in order to activate any previously active multicast service(s); or
– to detach the IMSI or IMEI for emergency bearer services.
Reference
3GPP TS 24.008 clause 4.5.1.1, 4.7.3.1, 4.7.4, 6.1.3.1 and 6.1.3.4.
13.4.2.3 Test purpose
To test the behaviour of the UE When a user requests an emergency call establishment the mobile station.
13.4.2.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
– the UE is in MM-state "GMM-DEREGISTERED.LIMITED-SERVICE",
Related ICS/IXIT statements
– PS Supported yes/no
– Method of context activation
Test procedure
- The UE is made to initiate a emergency call, and call generic procedure in TS 34.108 subclause 7.2.5.2.3 are performed to complete Generic IMS Emergency call set up procedure.
2) The UE sends a DEACTIVATE PDP CONTEXT REQUEST message to the network, The SS shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message.
3) The UE sends a DETACH REQUEST message to the SS.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1-23 |
Steps 1 to 23 of the generic test procedure in TS 34.108 subclause 7.2.5.2.3 are performed to complete Generic IMS Emergency call set up procedure . |
|||
24 |
UE |
After the emergency bearers service, the UE Initiate a context deactivation |
||
25 |
|
DEACTIVATE PDP CONTEXT REQUEST |
Request a deactivation of a PDP context. |
|
26 |
|
DEACTIVATE PDP CONTEXT ACCEPT |
SS accepts the PDP context deactivation. |
|
27 |
|
DETACH REQUEST |
The UE send a Detach Request. |
|
28 |
|
DETACH ACCEPT |
SS responds with DETACH ACCEPT message as a Detach Request was transmitted by the UE. |
Specific message contents
None.
13.4.2.5 Test requirements
At Step 5, the UE shall transmit an ATTACH REQUEST with Request type set to “emergency”
At Step 12, the UE shall transmit an ACTIVATE PDP CONTEXT REQUEST with Request type set to “emergency” to SS.
13.4.3 Emergency bearer services over IMS / NO-IMSI / Success
13.4.3.1 Definition
13.4.3.2 Conformance requirement
1) In state GMM-DEREGISTERED, the MS initiates the GPRS attach procedure by sending an ATTACH REQUEST message to the network, starts timer T3310 and enters state GMM-REGISTERED-INITIATED.
If the MS is configured for "AttachWithIMSI" as specified in 3GPP TS 24.368 [135] and the selected PLMN is neither the registered PLMN nor in the list of equivalent PLMNs, the MS shall include the IMSI in the Mobile identity IE in the ATTACH REQUEST message.
…
If the MS is attaching for emergency bearer services and does not hold a valid GUTI, Mobile identity as described above, the IMEI shall be included in the Mobile identity IE.
The MS shall also indicate within the DRX parameters whether it supports the split pg cycle option on CCCH. The optional support of the split pg cycle on CCCH by the network is indicated in SI13 or PSI1. Split pg cycle on CCCH is applied by both the network and the MS when the split pg cycle option is supported by both (see 3GPP TS 45.002 [32]).
In Iu mode, if the MS wishes to prolong the established PS signalling connection after the GPRS attach procedure (for example, the MS has any CM application request pending), it may set a follow-on request pending indicator on (see subclause 4.7.13).
An MS attaching for emergency bearer services shall set the follow-on request pending indicator.
2) During an attach for emergency bearer services, if not restricted by local regulations, the network shall not check for mobility and access restrictions, regional restrictions, subscription restrictions, or perform CSG access control when processing the ATTACH REQUEST message. The network shall not apply APN based congestion control during an attach procedure for emergency bearer services.
3) In order to request a PDP context activation, the MS sends an ACTIVATE PDP CONTEXT REQUEST message to the network, enters the state PDP-ACTIVE-PENDING and starts timer T3380. The message contains the selected NSAPI, PDP type, requested QoS and, if the MS requests a static address, the PDP address. The MS shall ensure that the selected NSAPI is not currently being used by another Session Management entity in the MS. The MS may indicate the support of Network Requested Bearer Control procedures in the protocol configuration options information element. The MS supporting S1 mode shall include interactive or background traffic class in the QoS requested. The MS not supporting S1 mode should include interactive or background traffic class in the QoS requested. If there is a subscribed QoS profile available for the MS, the network may ignore the requested QoS and apply the subscribed QoS profile (see 3GPP TS 23.060 [74]).
The MS shall set the request type to "initial request" when the MS is establishing connectivity to an additional PDN for the first time, i.e. when it is an initial attach to that PDN. The MS shall set the request type to "handover" when the connectivity to a PDN is established upon handover from a non-3GPP access network and the MS was connected to that PDN before the handover to the 3GPP access network. If the MS is establishing connectivity for emergency bearer services it shall set the request type to "emergency" and not include an APN in the ACTIVATE PDP CONTEXT REQUEST message.
4) In order to deactivate a PDP context, the MS sends a DEACTIVATE PDP CONTEXT REQUEST message to the network enters the state PDP-INACTIVE-PENDING and starts timer T3390. The message contains the transaction identifier (TI) in use for the PDP context to be deactivated and a cause code that typically indicates one of the following causes:
# 25: LLC or SNDCP failure (A/Gb mode only);
# 26: insufficient resources;
# 36: regular deactivation; or
# 37: QoS not accepted.
5) The GPRS detach procedure is used:
– to detach the IMSI for GPRS services only. Independent of the network operation mode, this procedure is used by all kind of GPRS MSs;
– as a combined GPRS detach procedure used by GPRS MSs operating in MS operation mode A or B to detach the IMSI for GPRS and non-GPRS services or for non-GPRS services only, if the network operates in network operation mode I and no circuit-switched transaction is ongoing;
– in the case of a network failure condition to indicate to the MS that a re-attach with successive activation of previously active PDP contexts shall be performed. In this case, the MS may also perform the procedures needed in order to activate any previously active multicast service(s); or
– to detach the IMSI or IMEI for emergency bearer services.
Reference
3GPP TS 24.008 clause 4.5.1.1, 4.7.3.1, 4.7.4, 6.1.3.1 and 6.1.3.4
13.4.3.3 Test purpose
To test the behaviour of the UE When a user requests an emergency call establishment the mobile station.
13.4.3.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
– the UE is in MM-state "GMM-DEREGISTERED.NO-IMSI",
Related ICS/IXIT statements
– PS Supported yes/no
– Method of context activation
Test procedure
1. The UE is made to initiate a emergency call. And call the generic test procedure in TS 34.108 subclause 7.2.5.2.3 are performed to complete Generic IMS Emergency call set up procedure .
2) The UE sends a DEACTIVATE PDP CONTEXT REQUEST message to the network, The SS shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message.
3) The UE sends a DETACH REQUEST message to the SS.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1-23 |
Steps 1 to 23 of the generic test procedure in TS 34.108 subclause 7.2.5.2.3 are performed to complete Generic IMS Emergency call set up procedure . |
|||
24 |
UE |
After the emergency bearers service, the UE Initiate a context deactivation |
||
25 |
|
DEACTIVATE PDP CONTEXT REQUEST |
Request a deactivation of a PDP context. |
|
26 |
|
DEACTIVATE PDP CONTEXT ACCEPT |
SS accepts the PDP context deactivation. |
|
27 |
|
DETACH REQUEST |
The UE send a Detach Request. |
|
28 |
|
DETACH ACCEPT |
SS responds with DETACH ACCEPT message as a Detach Request was transmitted by the UE. |
Specific message contents
None.
13.4.3.5 Test requirements
At Step 5, the UE shall transmit an ATTACH REQUEST with Request type set to “emergency” and Mobile identity IE is set to IMEI.
At Step 12, the UE shall transmit an ACTIVATE PDP CONTEXT REQUEST with Request type set to “emergency” to SS.
13.4.4 Emergency bearer services over IMS / NORMAL-SERVICE / Authentication not accepted by the UE and Timer 3318 expires
13.4.4.1 Definition
13.4.4.2 Conformance requirement
(f) Authentication failure (GMM cause #18 "MAC failure" or #21 "GSM authentication unacceptable")
The MS shall send an AUTHENTICATION & CIPHERING FAILURE message, with GMM cause ‘MAC failure’ or ‘GSM authentication unacceptable’ according to subclause 4.7.7.5.1, to the network and start timer T3318. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3310, T3321, T3330 or T3317). Upon the first receipt of an AUTHENTICATION & CIPHERING FAILURE message from the MS with GMM cause ‘MAC failure’ or ‘GSM authentication unacceptable’ the network may initiate the identification procedure described in subclause 4.7.8. This is to allow the network to obtain the IMSI from the MS. The network may then check that the P-TMSI originally used in the authentication challenge corresponded to the correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the MS shall send the IDENTITY RESPONSE message.
…
If an MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection when timer T3318 or T3320 expires, the MS shall not deem that the network has failed the authentication check and not behave as described in subclause 4.7.7.6.1. Instead the MS shall continue using the current security context, if any. The MS shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. If there is an ongoing session management procedure, the MS shall deactivate all non-emergency PDP contexts upon completion of the session management procedure. The MS shall consider itself to be attached for emergency bearer services only.
Reference
3GPP TS 24.008 clause 4.7.7.6
13.4.4.3 Test purpose
To test the behaviour of the UE When a user requests an emergency call establishment the mobile station and the authentication procedure fails due to MAC failure.
13.4.4.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
– the UE is in MM-state "PDP-ACTIVE" state,
– the emergency number list was send to UE with ATTACH ACCEPT message during the UE register in the cell.
Related ICS/IXIT statements
– PS Supported yes/no
– Auto Attach supported yes / no
– Method of context activation
Test procedure
1) The UE initiates an IMS emergency call, and call the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure.
2) The Emergency bearers service completed.
3) The network send AUTHENTICATION REQUEST with AUTN having an incorrect MAC value
4) The UE sends and AUTHENTICATION FAILURE
5) Wait until timer T3318 expires.
6) After T3318 expires the UE sends a DEACTIVATE PDP CONTEXT REQUEST message to the network.
7) The SS shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1-21 |
Steps 1 to 21 of the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure. |
|||
22 |
UE |
The Emergency bearers service completed. |
||
23 |
|
AUTHENTICATION REQUEST |
With AUTN parameter having a MAC value different from what is calculated in 34.108 clause 8.1.2.1 step 4. |
|
24 |
|
AUTHENTICATION FAILURE |
With reject cause "MAC failure". UE starts T3318. |
|
25 |
Wait until T3318 expires than the UE initiates a context deactivation. |
|||
26 |
|
DEACTIVATE PDP CONTEXT REQUEST |
Request deactivation of the emergency PDP context. |
|
27 |
|
DEACTIVATE PDP CONTEXT ACCEPT |
SS accepts the emergency PDP context deactivation. |
Specific message contents
None.
13.4.4.5 Test requirements
At Step 26, the UE shall transmit a DEACTIVATE PDP CONTEXT REQUEST.
13.4.5 Authentication not accepted by the UE / Synch failure / Authentication not accepted by the UE and Timer 3320 expires
13.4.5.1 Definition
13.4.5.2 Conformance requirement
(g) Authentication failure (GMM cause #19 "Synch failure"):
The MS shall send an AUTHENTICATION & CIPHERING FAILURE message, with the GMM cause "Synch failure", to the network and start the timer T3320. Furthermore, the MS shall stop any of the retransmission timers that are running (e.g. T3310, T3321, T3330 or T3317). Upon the first receipt of an AUTHENTICATION & CIPHERING message from the MS with the GMM cause "synch failure", the network shall use the returned AUTS parameter from the authentication & ciphering failure parameter IE in the AUTHENTICATION & CIPHERING FAILURE message, to re-synchronise. The re-synchronisation procedure requires the SGSN to delete all unused authentication vectors for that IMSI and obtain new vectors from the HLR. When re-synchronisation is complete, the network shall initiate the authentication & ciphering procedure. Upon receipt of the AUTHENTICATION & CIPHERING REQUEST message, the MS shall stop timer T3320, if running.
…
If an MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection when timer T3318 or T3320 expires, the MS shall not deem that the network has failed the authentication check and not behave as described in subclause 4.7.7.6.1. Instead the MS shall continue using the current security context, if any. The MS shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. If there is an ongoing session management procedure, the MS shall deactivate all non-emergency PDP contexts upon completion of the session management procedure. The MS shall consider itself to be attached for emergency bearer services only.
Reference
3GPP TS 24.008 clause 4.7.7.6
13.4.5.3 Test purpose
To test the behaviour of the UE When a user requests an emergency call establishment the mobile station and the authentication procedure fails due to SQN failure.
13.4.5.4 Method of test
Initial condition
System Simulator:
1 cell, default parameters.
User Equipment:
– the UE is in MM-state "PDP-ACTIVE" state,
– the emergency number list was send to UE with ATTACH ACCEPT message during the UE register in the cell.
Related ICS/IXIT statements
– PS Supported yes/no
– Auto Attach supported yes / no
– Method of context activation
Test procedure
1) The UE initiates an IMS emergency call, and call the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure.
2) The Emergency bearers service completed.
3) The network send AUTHENTICATION REQUEST with AUTN having an incorrect SQN value
4) The UE sends and AUTHENTICATION FAILURE
5) Wait until timer T3320 expires.
6) After T3320 expires the UE sends a DEACTIVATE PDP CONTEXT REQUEST message to the network.
7) The SS shall then reply with a DEACTIVATE PDP CONTEXT ACCEPT message.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
1-21 |
Steps 1 to 21 of the generic test procedure in TS 34.108 subclause 7.2.5.1.3 are performed to complete Generic IMS Emergency call set up procedure . |
|||
22 |
UE |
The Emergency bearers service completed. |
||
23 |
|
AUTHENTICATION REQUEST |
with the AMF information field set to AMFRESYNCH value to trigger SQN re-synchronisation procedure in test USIM, see TS 34.108 clause 8.1.2.2. |
|
24 |
|
AUTHENTICATION FAILURE |
including the AUTS parameter and with the reject cause set to ‘Synch failure’. UE starts T3320. |
|
25 |
Wait until T3320 expires than the UE initiates a context deactivation. |
|||
26 |
|
DEACTIVATE PDP CONTEXT REQUEST |
Request deactivation of the emergency PDP context. |
|
27 |
|
DEACTIVATE PDP CONTEXT ACCEPT |
SS accepts the emergency PDP context deactivation. |
Specific message contents
None.
13.4.5.5 Test requirements
At Step 26, the UE shall transmit a DEACTIVATE PDP CONTEXT REQUEST.
13.4.6 Handling of Local Emergency Numbers List provided during Attach procedure
13.4.6.1 Definition
13.4.6.2 Conformance requirement
1) If the GPRS attach procedure is accepted by the network, an ATTACH ACCEPT message is sent to the MS. With this message the network may send a list of local emergency numbers, by including the Emergency Number List IE. The mobile equipment shall store the list, as provided by the network, except that any emergency number that is already stored in the SIM/USIM shall be removed from the list before it is stored by the mobile equipment. If there are no emergency numbers stored on the SIM/USIM, then before storing the received list the mobile equipment shall remove from it any emergency number stored permanently in the ME for use in this case (see 3GPP TS 22.101 [8]). The list stored in the mobile equipment shall be replaced on each receipt of a new Emergency Number List IE
2) The emergency number(s) received in the Emergency Number List IE are valid only in networks with the same MCC as in the cell on which this IE is received. If no list is contained in the ACCEPT message, then the stored list in the mobile equipment shall be kept, except if the mobile equipment has successfully registered to a PLMN with an MCC different from that of the last registered PLMN.
3) The list of emergency numbers shall be deleted at switch off and removal of the SIM/USIM. The mobile equipment shall be able to store up to ten local emergency numbers received from the network.
Reference
3GPP TS 24.008 clauses 4.7.3.1.3.
13.4.6.3 Test purpose
To verify the core requirements in the scope of the present test case:
1) Verify that with UE having Emergency numbers stored in the USIM and a Local Emergency Numbers List which were provided during the initial Attach procedure when the UE attaches again and the new network provides a new Local Emergency Numbers List then the UE replaces the old Local Emergency Numbers List with the new one.
2) Verify that when the UE needs to attach again to a network with the same MCC which does not provide Local Emergency Numbers List then the UE does not delete the old Local Emergency Numbers List.
3) Verify that when the UE needs to attach again to a network this time with a different MCC which does not provide a new Local Emergency Numbers List then the UE considers the old Local Emergency Numbers List as invalid.
13.4.6.4 Method of test
Initial condition
System Simulator:
Three cells, one from them with different MCC: cell A MCC1, cell B in MCC1, cell C in MCC2.
User Equipment:
The UE has a valid IMSI.
– USIM contains at least 1 Emergency Number (see TS 22.101 clause 10.1.1).
The UE has performed a successful attach on Cell A and then has been configured to perform GPRS detach procedure; during the attach the SS has provided a Local Emergency Numbers List with 3 numbers EN1, EN2 and EN3 different to the number(s) on the USIM (see TS 22.101 clause 10.1.1).
Related ICS/IXIT statements
Automatic PS attach procedure at switch on or power on Yes/No
Test procedure
1) Cell A is shut down, Cell B is powered up. The UE is configured to perform GPRS attach procedure. The UE attaches to cell B – during the attachment the SS provides a Local Emergency Numbers List with 10 numbers different to the numbers EN1, EN2 and EN3 provided during the initial attach in the preamble. The UE is checked that it can start emergency call when any of the 10 numbers is chosen by the user, and, start a normal call if the user dials any of the numbers EN1, EN2 or EN3.
2) The UE is configured to perform GPRS detach procedure. Cell B is shut down, Cell A is powered up (same MCC as cell B). The UE is set to enable GPRS service. The UE attaches to cell A – during the attachment the SS does not provide a Local Emergency Numbers List. The UE is checked that it can start emergency call when any of the 10 numbers provided during the attachment on cell B is chosen by the user.
3) The UE is configured to perform GPRS detach procedure. Cell A is shut down, Cell C is powered up (different MCC in comparison to cell A). The UE is set to enable GPRS service. The UE attaches to cell C – during the attachment the SS does not provide a Local Emergency Numbers List. The UE is checked that it starts a normal call when any of the 10 numbers provided during the attachment on cell B is chosen by the user.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
The following messages are sent and shall be received on cell B. |
||||
1 |
SS |
Set the cell type of cell B to the "Serving cell". Set the cell type of cell A to the "non-suitable "Off" cell". (see note) |
||
2 |
UE |
The UE is configured to initiate GPRS attach, via MMI or AT command. |
||
3 |
-> |
ATTACH REQUEST |
||
4 |
<- |
AUTHENTICATION AND CIPHERING REQUEST |
||
5 |
-> |
AUTHENTICATION AND CIPHERING RESPONSE |
||
6 |
SS |
The SS starts integrity protection. |
||
7 |
<- |
ATTACH ACCEPT |
SS provides a Local Emergency Numbers List with 10 numbers different to the numbers EN1, EN2 and EN3 provided during the initial attach in the preamble |
|
8 |
-> |
ATTACH COMPLETE |
||
9 |
SS |
The SS releases the RRC connection. |
||
Steps 10 to 14 are repeated 10 times – each time with a different call number (in step 10) |
||||
10 |
UE |
The UE is made to initiate a call using a number from the last sent by the SS local emergency list. |
||
11 |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to “emergency call". |
||
12 |
-> |
SERVICE REQUEST |
||
13 |
<- |
SERVICE REJECT |
||
14 |
SS |
The SS releases the RRC connection. |
||
Steps 15 to 18 are repeated 3 times – each time with a different call number (in step 15) |
||||
15 |
UE |
The UE is made to initiate a call using a number from the local emergency list sent in the ATTACH ACCEPT message in the preamble. |
||
16 |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is NOT set to “emergency call". |
||
16 |
-> |
SERVICE REQUEST |
||
17 |
<- |
SERVICE REJECT |
||
18 |
SS |
The SS releases the RRC connection. |
||
19 |
UE |
The UE is configured to initiate GPRS detach, via MMI or AT command. |
||
20 |
-> |
DETACH REQUEST |
Detach type = ‘normal detach, GPRS detach’ |
|
21 |
SS |
The SS releases the RRC connection. If no RRC CONNECTION RELEASE COMPLETE message have been received within 1 second then the SS shall consider the UE as switched off. |
||
The following messages are sent and shall be received on cell A. |
||||
22 |
SS |
Set the cell type of cell A to the "Serving cell". Set the cell type of cell B to the "non-suitable "Off" cell". (see note) |
||
23-35 |
Steps 2 to 14 are repeated with 1 difference: – the ATTACH ACCEPT message in step 7 does not provide Local Emergency Numbers List. The UE is expected to have retained the Local Emergency Numbers provided when it attached on cell B |
|||
The following messages are sent and shall be received on cell C. |
||||
36 |
SS |
Set the cell type of cell C to the "Serving cell". Set the cell type of cell A to the "non-suitable "Off" cell". (see note) |
||
37-49 |
Steps 2 to 14 are repeated with 2 difference: – the ATTACH ACCEPT message in step 7 does not provide Local Emergency Numbers List. – in step 11 the SS verifies that the IE "Establishment cause" is NOT set to “emergency call" – the UE is expected to have deleted the Local Emergency Numbers List. |
|||
NOTE: The definitions for "non-suitable "Off" cell" and "Serving cell" are specified in TS34.108 clause 6.1 in the relevant to the RAT of the cells "Reference Radio Conditions" subclauses. |
Specific message contents
ATTACH ACCEPT (in the preamble)
Information Element |
Value/remark |
Emergency number list |
3 numbers (TS 24.008, 10.5.3.13) The numbers shall be different than any of those indicated in TS 22.101 clause 10.1.1 AND the numbers stored in the USIM |
Network feature support information element |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
ATTACH ACCEPT (Step 7)
Information Element |
Value/remark |
Emergency number list |
10 numbers (TS 24.008, 10.5.3.13) The numbers shall be different than any of those indicated in TS 22.101 clause 10.1.1 AND the numbers stored in the USIM |
Network feature support information element |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
ATTACH ACCEPT (Steps 28 and 42)
Information Element |
Value/remark |
Emergency number list |
Not present |
Network feature support information element |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
SERVICE REJECT (all steps)
Information Element |
Value/remark |
GMM cause |
‘00010110’B – Congestion |
13.4.6.5 Test requirements
At step 11 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set to "emergency call".
At step 16 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set NOT to "emergency call".
At step 32 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set to "emergency call".
At step 46 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set NOT to "emergency call".
13.4.7 UE has PDN connection only for emergency bearer services / Normal routing area update / Accepted / Handling of the equivalent PLMNs list when PLMN is member of the "forbidden PLMN" list
13.4.7.1 Definition
13.4.7.2 Conformance requirement
1) If the network sends a list of "equivalent PLMNs" in the ROUTING AREA UPDATE ACCEPT message when there is a PDN connection for emergency bearer services established, the MS shall not remove from the list of "equivalent PLMNs" any PLMN code that is already in the "forbidden PLMN" list and even such. PLMNs shall be regarded as equivalent to the others for PLMN selection, cell selection/re-selection and handover.
2) If the network sends a list of "equivalent PLMNs" in the ROUTING AREA UPDATE ACCEPT message when there is a PDN connection for emergency bearer services established, the MS shall remove from the list of "equivalent PLMNs" any PLMN code present in the "forbidden PLMN" list when the PDN connection for emergency bearer services is released.
Reference
3GPP TS 24.008 clause 4.7.5.1.3.
13.4.7.3 Test purpose
To verify the core requirements in the scope of the present test case:
1) Verify that with UE having established a PDN connection for emergency bearer services when the UE moves to another routing area and receives a list of equivalent PLMNs in the ROUTING AREA UPDATE ACCEPT message which includes a PLMN which is on the UE list with forbidden PLMNs then the UE stores the received list of equivalent PLMNs not removing from the list the forbidden PLMN and being capable to move to this PLMN if it becomes the strongest (or the only one available).
2) Verify that after the PDN connection for the emergency bearer services is released then the UE removes from the list of equivalent PLMNs any PLMN code present in the list of forbidden PLMNs.
13.4.7.4 Method of test
Initial condition
System Simulator:
Three cells, cell A in MCC1/MNC1/LAC1/RAC1 (RAI-1), cell B in MCC1/MNC1/LAC1/RAC2 (RAI-4), cell C in MCC2/MNC1/LAC1/RAC2 (RAI-7).
The PLMN of cell C is equivalent to the PLMN of cell A and cell B.
NB: i) Cell C will be mapped to Cell 4 as found in TS 34.108 clause 6.1.4.1.
User Equipment:
The UE has a valid IMSI.
– USIM contains at least 1 Emergency Number (see TS 22.101 clause 10.1.1).
– PLMN of cell C is in the UE’s list with forbidden PLMNs
The UE has PDN connection only for emergency bearer services.
Related ICS/IXIT statements
–
Test procedure
1) The UE moves to cell B and sends a ROUTING AREA UPDATE REQUEST message. The SS returns ROUTING AREA UPDATE ACCEPT message with a list with equivalent PLMNs which contains the cell C PLMN – this PLMN being set as forbidden PLMN in the UE’s list with forbidden PLMNs. The UE stores the new list without altering it.
2) Cell C is made as the only suitable cell. Although the cell C PLMN is in the list of forbidden PLMNs the UE moves to cell C and does RAU.
3) Cell A is made available as a "Suitable cell", cell C is not changed. The UE is requested to disconnection (release) from the emergency PDN. The UE is expected to camp on cell A although cell C is stronger – this proving that after the release the PLMN of cell C was removed from the list with equivalent PLMNs.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
The following messages are sent and shall be received on cell B. |
||||
1 |
SS |
Set the cell type of cell B to the "Serving cell". Set the cell type of cell A to the "non-suitable "Off" cell". (see note) |
||
2 |
-> |
ROUTING AREA UPDATE REQUEST |
||
3 |
<- |
ROUTING AREA UPDATE ACCEPT |
Equivalent PLMNs = MCC2, MNC1 |
|
4 |
-> |
ROUTING AREA UPDATE COMPLETE |
||
5 |
SS |
The SS releases the RRC connection. |
||
The following messages are sent and shall be received on cell C. |
||||
6 |
SS |
Set the cell type of cell C to the "Serving cell". Set the cell type of cell B to the "non-suitable "Off" cell". (see note) |
||
7 |
-> |
ROUTING AREA UPDATE REQUEST |
||
8 |
<- |
ROUTING AREA UPDATE ACCEPT |
||
9 |
SS |
The SS releases the RRC connection. |
||
10 |
SS |
Set the cell type of cell A to the "Suitable neighbour cell". Keep the cell type of cell C to the "Serving cell". (see note) |
||
11 |
UE |
Cause the UE to request disconnection from the emergency PDN |
||
12 |
-> |
DEACTIVATE PDP CONTEXT REQUEST |
||
13 |
<- |
DEACTIVATE PDP CONTEXT ACCEPT |
||
The following messages are sent and shall be received on cell A. |
||||
The UE needs time to realise that the Emergency PDN was deactivated, to remove the PLMN code of the PLMN on Cell C from its equivalent PLMNs list and look for another PLMN although the Cell C has the better signal |
||||
14 |
Verify that the result from generic procedure C.1 shows that UE has camped on cell A |
|||
NOTE: The definitions for "Suitable neighbour cell", "non-suitable "Off" cell" and "Serving cell" are specified in TS34.108 clause 6.1 in the relevant to the RAT of the cells "Reference Radio Conditions" subclauses. |
Specific message contents
ROUTING AREA UPDATE ACCEPT (step 3)
Information Element |
Value/remark |
Equivalent PLMNs |
Includes MCC2 and MNC1 digits for the cell C PLMN |
13.4.7.5 Test requirements
At step 7 the UE shall send the ROUTING AREA UPDATE REQUEST on cell C.
At step 14 the UE shall camp on cell A.
13.4.8 Handling of Local Emergency Numbers List provided during normal Routing area update procedure
13.4.8.1 Definition
13.4.8.2 Conformance requirement
1) If the GPRS normal Routing area update procedure is accepted by the network, a ROUTING AREA ACCEPT message is sent to the MS. With this message the network may send a list of local emergency numbers, by including the Emergency Number List IE. The mobile equipment shall store the list, as provided by the network, except that any emergency number that is already stored in the SIM/USIM shall be removed from the list before it is stored by the mobile equipment. If there are no emergency numbers stored on the SIM/USIM, then before storing the received list the mobile equipment shall remove from it any emergency number stored permanently in the ME for use in this case (see 3GPP TS 22.101 [8]). The list stored in the mobile equipment shall be replaced on each receipt of a new Emergency Number List IE
2) The emergency number(s) received in the Emergency Number List IE are valid only in networks with the same MCC as in the cell on which this IE is received. If no list is contained in the ROUTING AREA ACCEPT message, then the stored list in the mobile equipment shall be kept, except if the mobile equipment has successfully registered to a PLMN with an MCC different from that of the last registered PLMN.
3) The list of emergency numbers shall be deleted at switch off and removal of the SIM/USIM. The mobile equipment shall be able to store up to ten local emergency numbers received from the network.
Reference
3GPP TS 24.008 clauses 4.7.5.1.3.
13.4.8.3 Test purpose
To verify the core requirements in the scope of the present test case:
1) Verify that with UE having Emergency numbers stored in the USIM and a Local Emergency Numbers List which were provided during the initial Attach procedure when the UE performs a normal RAU and the new network provides a new Local Emergency Numbers List then the UE replaces the old Local Emergency Numbers List with the new one.
2) Verify that when the UE performs a normal RAU to a network with the same MCC which does not provide Local Emergency Numbers List then the UE does not delete the old Local Emergency Numbers List.
3) Verify that when the UE performs a normal RAU to a network this time with a different MCC which does not provide a new Local Emergency Numbers List then the UE considers the old Local Emergency Numbers List as invalid.
13.4.8.4 Method of test
Initial condition
System Simulator:
Three cells with different RAI, one from them with different MCC: cell A in MCC1/RAC1 (RAI-1), cell B in MCC1/RAC2 (RAI-4), cell C in MCC2/RAC2 (RAI-7).
– NMO I
NB: i) Cell C will be mapped to Cell 4 as found in TS 34.108 clause 6.1.4.1.
User Equipment:
The UE has a valid IMSI.
– USIM contains at least 1 Emergency Number (see TS 22.101 clause 10.1.1).
The UE has performed a successful attach on Cell A; during the attach the SS has provided a Local Emergency Numbers List with 3 numbers EN1, EN2 and EN3 different to the number(s) on the USIM (see TS 22.101 clause 10.1.1).
Related ICS/IXIT statements
–
Test procedure
1) Cell B is set to "Serving cell", Cell A is set to "non-suitable "Off" cell". The UE performs normal RAU to cell B – during the LAU the SS provides a Local Emergency Numbers List with 10 numbers different to the numbers EN1, EN2 and EN3 provided during the initial attach in the preamble. The UE is checked that it can start emergency call when any of the 10 numbers is chosen by the user, and, start a normal call if the user dials any of the numbers EN1, EN2 or EN3.
2) Cell A is set to "Serving cell", Cell B is set to "non-suitable "Off" cell". The UE performs normal RAU to cell B – during the LAU the SS does not provide a Local Emergency Numbers List. The UE is checked that it can start emergency call when any of the 10 numbers provided during the attachment on cell B is chosen by the user.
3) Cell C is set to "Serving cell", Cell A is set to "non-suitable "Off" cell". The UE performs normal RAU to cell C – during the LAU the SS does not provide a Local Emergency Numbers List. The UE is checked that it starts a normal call when any of the 10 numbers provided during the attachment on cell B is chosen by the user.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
---|---|---|---|---|
UE |
SS |
|||
The following messages are sent and shall be received on cell B. |
||||
1 |
SS |
Set the cell type of cell B to the "Serving cell". Set the cell type of cell A to the "non-suitable "Off" cell". (see note) |
||
2 |
-> |
ROUTING AREA UPDATE REQUEST |
||
3 |
SS |
The SS starts integrity protection. |
||
4 |
<- |
ROUTING AREA UPDATE ACCEPT |
SS provides a Local Emergency Numbers List with 10 numbers different to the numbers EN1, EN2 and EN3 provided during the initial attach in the preamble |
|
5 |
SS |
The SS releases the RRC connection. |
||
Steps 6 to 10 are repeated 10 times – each time with a different call number (in step 6) |
||||
6 |
UE |
The UE is made to initiate a call using a number from the local emergency list sent in the ROUTING AREA UPDATE ACCEPT message in step 4. |
||
7 |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is set to “emergency call". |
||
8 |
-> |
SERVICE REQUEST |
||
9 |
<- |
SERVICE REJECT |
||
10 |
SS |
The SS releases the RRC connection. |
||
Steps 11 to 15 are repeated 3 times – each time with a different call number (in step 11) |
||||
11 |
UE |
The UE is made to initiate a call using a number from the local emergency list sent in the ATTACH ACCEPT message in the preamble. |
||
12 |
SS |
SS checks that the IE "Establishment cause" in the received RRC CONNECTION REQUEST message is NOT set to “emergency call". |
||
13 |
-> |
SERVICE REQUEST |
||
14 |
<- |
SERVICE REJECT |
||
15 |
SS |
The SS releases the RRC connection. |
||
The following messages are sent and shall be received on cell A. |
||||
16 |
SS |
Set the cell type of cell A to the "Serving cell". Set the cell type of cell B to the "non-suitable "Off" cell". (see note) |
||
17-25 |
Steps 2 to 10 are repeated with 1 difference: – the ROUTING AREA UPDATE ACCEPT message in step 4 does not provide Local Emergency Numbers List. The UE is expected to have retained the Local Emergency Numbers provided when it attached on cell B |
|||
The following messages are sent and shall be received on cell C. |
||||
26 |
SS |
Set the cell type of cell C to the "Serving cell". Set the cell type of cell A to the "non-suitable "Off" cell". (see note) |
||
27-35 |
Steps 2 to 10 are repeated with 2 differences: – the ROUTING AREA UPDATE ACCEPT message in step 4 does not provide Local Emergency Numbers List. – in step 7 the SS verifies that the IE "Establishment cause" is NOT set to “emergency call" – the UE is expected to have deleted the Local Emergency Numbers List. |
|||
NOTE: The definitions for "non-suitable "Off" cell" and "Serving cell" are specified in TS34.108 clause 6.1 in the relevant to the RAT of the cells "Reference Radio Conditions" subclauses. |
Note: The present TC’s expected sequence is very similar to the expected sequence of TC 13.4.6 with the difference being that the ATTACH procedure in TC13.4.6 is replaced in the present TC with normal RAU procedure.
Specific message contents
ATTACH ACCEPT (in the preamble)
Information Element |
Value/remark |
Emergency number list |
3 numbers (TS 24.008, 10.5.3.13) The numbers shall be different than any of those indicated in TS 22.101 clause 10.1.1 AND the numbers stored in the USIM |
Network feature support information element |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
the ROUTING AREA UPDATE ACCEPT (Step 4)
Information Element |
Value/remark |
Emergency number list |
10 numbers (TS 24.008, 10.5.3.13) The numbers shall be different than any of those indicated in TS 22.101 clause 10.1.1 AND the numbers stored in the USIM |
the ROUTING AREA UPDATE ACCEPT (Steps 19 and 29)
Information Element |
Value/remark |
Emergency number list |
Not present |
Network feature support information element |
Emergency bearer services supported in Iu mode, but not supported in A/Gb mode |
SERVICE REJECT (all steps)
Information Element |
Value/remark |
GMM cause |
‘00010110’B – Congestion |
13.4.8.5 Test requirements
At step 7 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set to "emergency call".
At step 12 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set NOT to "emergency call".
At step 22 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set to "emergency call".
At step 32 the UE shall send the IE "Establishment cause" in the RRC CONNECTION REQUEST message set NOT to "emergency call".
13.4.9 Attach for emergency bearer services / Rejected / No suitable cells in location area / Emergency call using the CS domain
13.4.9.1 Definition
This test case is applicable to Rel-9 or later UEs that support IMS emergency services and establishing the emergency call using the CS domain in case the attach request for emergency bearer services cannot be accepted by the network.
13.4.9.2 Conformance requirement
If the attach request for emergency bearer services cannot be accepted by the network, an ATTACH REJECT message is transferred to the MS. The ATTACH REJECT message includes GMM cause #5 "IMEI not accepted" or one of the GMM cause values as described in subclause 4.7.3.1.4.
Upon receiving the ATTACH REJECT message including GMM cause #5, the MS shall enter the state GMM-DEREGISTERED.NO-IMSI.
Upon receiving the ATTACH REJECT message including one of the other GMM cause values, the MS shall perform the actions as described in subclause 4.7.3.1.4 with the following addition: upon request from upper layers a CS voice capable MS may establish the emergency call using the CS domain.
Reference
TS 24.008 clause 4.7.3.1.4a
13.4.9.3 Test purpose
To verify that the UE will establish the emergency call using the CS domain after its attach request for emergency bearer services was rejected with GMM cause “No Suitable Cells in Location Area".
13.4.9.4 Method of test
Initial condition
System Simulator:
– 1 cell, default parameters.
User Equipment:
– The UE is in state “MM idle” with valid TMSI and CKSN.
– The UE is not attached for emergency bearer services.
Related ICS/IXIT statements
– UE supports IMS emergency services yes/no
– UE supports establishing the emergency call using the CS domain if the attach request for emergency bearer services cannot be accepted by the network yes/no
Test Procedure
a) The UE is caused to originate a call to send user data related to emergency call.
b) The UE transmits an ATTACH REQUEST message for emergency bearer services.
c) The attach request for emergency bearer services is rejected by the SS with cause #15 “No Suitable Cells In Location Area”.
d) The RRC Connection is released.
e) If the UE supports establishing the emergency call using the CS domain upon receiving the ATTACH REJECT message with cause #15, the UE initiates a CS emergency call.
f) The CS emergency call is set up.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
UE |
The UE is caused to originate a call to send user data related to Emergency call. |
||
2 |
–> |
ATTACH REQUEST |
The UE transmits an ATTACH REQUEST message to attach for emergency bearer services. |
|
3 |
<– |
ATTACH REJECT |
The SS transmits an ATTACH REJECT message, EMM cause = “No Suitable Cells In Location Area”. |
|
4 |
<– |
RRC CONNECTION RELEASE |
||
5 |
–> |
RRC CONNECTION RELEASE COMPLETE |
||
6 |
–> |
RRC CONNECTION REQUEST |
Within [60] sec of Step 5, the UE transmits an RRC CONNECTION REQUEST message with Establishment cause: Emergency Call. |
|
7 |
<– |
RRC CONNECTION SETUP |
||
8 |
–> |
RRC CONNECTION SETUP COMPLETE |
||
9 |
–> |
CM SERVICE REQUEST |
The UE transmits a CM SERVICE REQUEST with CM service type IE indicating “Emergency call establishment”, |
|
10 |
<– |
AUTHENTICATION REQUEST |
||
11 |
–> |
AUTHENTICATION RESPONSE |
||
12 |
–> |
EMERGENCY SETUP |
||
13-17 |
– |
– |
Steps 11 to 15 of the generic test procedure in TS 34.108 subclause 7.2.3.2.3 are performed to complete the CS call setup. |
Specific Message Contents
None.
13.4.9.5 Test requirements
Within [60] sec of Step 5, the UE shall transmit an RRC CONNECTION REQUEST with Establishment cause: Emergency Call.
At Step 9, the UE shall transmit a CM SERVICE REQUEST with CM service type IE indicating “Emergency call establishment”.
At Step 12, the UE shall transmit an EMERGENCY SETUP message.
13.4.10 Emergency bearer services / CSG cell / LIMITED-SERVICE / Attach / Security mode control procedure without prior authentication / PDN connect / Service request / PDN disconnect / Detach upon UE switched off / Temporary storage of GMM information
13.4.10.1 Definition
This test case is applicable to Rel-9 or later UEs that support IMS emergency services.
13.4.10.2 Conformance requirement
When the GPRS capability in an activated MS has been enabled, the selection of the GMM-DEREGISTERED substate depends on the MM state and the GPRS update status.
The substate chosen after PLMN-SEARCH, in case of power on or after enabling of the GPRS capability is:
– if the cell is not supporting GPRS, the substate shall be NO-CELL-AVAILABLE;
– if no SIM/USIM is present the substate shall be NO-IMSI;
– if a suitable cell supporting GPRS has been found and the PLMN or LA is not in the forbidden list, then the substate shall be NORMAL-SERVICE;
– if the selected cell supporting GPRS is in a forbidden PLMN, is in a forbidden LA, or is a CSG cell with a CSG ID that is not in Allowed CSG list or in the Operator CSG list stored in the MS , then the MS shall enter the substate LIMITED-SERVICE;
– if the MS is in manual network selection mode and no cell supporting GPRS of the selected PLMN has been found, the MS shall enter the substate NO-CELL-AVAILABLE.
…
The MS:
– shall initiate GPRS attach when a cell is entered which may provide normal service (e.g. location area is not in one of the forbidden lists); and
– may initiate GPRS attach for emergency bearer services (UTRAN Iu mode only).
…
After the completion of application for which the emergency services were invoked, in order to regain normal services, an MS attached for emergency bearer services may perform a detach procedure, followed by a subsequent re-attach, if the MS moves to a new cell that provides normal service.
In A/Gb mode, if the GPRS detach procedure is performed, the PDP contexts and the MBMS contexts, if any, are deactivated locally without peer to peer signalling between the SM and LLC entities in the MS and the network.
In Iu mode, if the GPRS detach procedure is performed, the PDP contexts and the MBMS contexts, if any, are deactivated locally without peer to peer signalling between the SM entities in the MS and the network.
…
If the SERVICE REQUEST message was sent in PMM-CONNECTED mode, then the reception of the SERVICE ACCEPT message shall be treated as a successful completion of the procedure. The timer T3317 shall be stopped and the MS remains in PMM-CONNECTED mode.
If the SERVICE REQUEST message was sent in a CSG cell and the CSG subscription has expired or was removed for a MS, but the MS has a PDN connection for emergency bearer services established, the network shall accept the SERVICE REQUEST message and deactivate all non-emergency PDP contexts by initiating PDP context deactivation procedure. The PDP contexts for emergency services shall not be deactivated.
…
The last GPRS attach or routing area updating attempt was correctly performed, but the answer from the network was negative (because of roaming or subscription restrictions).
In this case, the SIM/USIM may contain the RAI of the routing area (RA) to which the subscriber was attached, and possibly also a valid P-TMSI, GPRS GSM ciphering key, GPRS UMTS ciphering key, GPRS UMTS integrity key or GPRS ciphering key sequence number. For compatibility reasons, all these fields shall be set to the value "deleted" if the RAI is deleted. However, the presence of other values shall not be considered an error by the MS. Furthermore, if the ME supports any GEA ciphering algorithm that requires a 128-bit ciphering key and a USIM is in use, then the ME shall delete the GPRS GSM Kc128 stored if the RAI is deleted.
If the MS is attached for emergency bearer services, the MS shall not store the GMM parameters described in this subclause on the SIM/USIM or in non-volatile memory. Instead the MS shall temporarily store these parameters locally in the ME and the MS shall delete these parameters when the MS is detached.
…
For emergency call establishment and re-establishment the mobile station shall select the mobile identity type with the following priority:
1- TMSI: The TMSI shall be used if it is available and if the location update status is UPDATED, and the stored LAI is equal to the one received on the BCCH from the current serving cell.
2- IMSI: The IMSI shall be used in cases where no TMSI is available or TMSI is available but either the update status is different from UPDATED, or the stored LAI is different from the one received on the BCCH from the current serving cell.
3- IMEI: The IMEI shall be used in cases where no SIM/USIM is available or the SIM/USIM is considered as not valid by the mobile station or no IMSI or TMSI is available.
…
If an MS has a PDN connection for emergency bearer services established or is establishing such a PDN connection when timer T3318 or T3320 expires, the MS shall not deem that the network has failed the authentication check and not behave as described in subclause 4.7.7.6.1. Instead the MS shall continue using the current security context, if any. The MS shall deactivate all non-emergency PDP contexts, if any, by initiating a PDP context deactivation procedure. If there is an ongoing session management procedure, the MS shall deactivate all non-emergency PDP contexts upon completion of the session management procedure. The MS shall consider itself to be attached for emergency bearer services only.
Reference
TS 24.008 clauses 4.2.4.1.1, 4.2.4.2.3, 4.7.4, 4.7.13.3, 4.1.3.2, 10.5.1.4, 10.5.1.4
13.4.10.3 Test purpose
To verify that when the user originates a call to send user data related to Emergency call:
1) the UE performs an Attach for emergency bearer on non-Allowed CSG cell if only suitable cell is non-allowed CSG cell,
2) the UE transmits a SERVICE REQUEST on the non-allowed CSG cell.
3) Upon detach, the UE deletes the GMM parameters stored temporarily while attached for emergency bearer services.
13.4.10.4 Method of test
Initial condition
System Simulator:
– Cell 1, Serving non CSG cell, default parameters
– Cell 2, CSG cell
User Equipment:
– The UE is in state “MM idle” with valid TMSI and CKSN.
– The UE is not attached for emergency bearer services.
– If pc_CSG, then UE has Allowed CSG list empty.
Related ICS/IXIT statements
– UE supports IMS emergency services yes/no
Test Procedure
a) The serving cell Cell 1 is switched off and Cell 2 is set as Serving cell.
a) After [2] min the UE is caused to originate a call to send user data related to emergency call on the CSG cell.
c) The UE transmits an ATTACH REQUEST message for emergency bearer services.
d) The attach request procedure for emergency bearer services is completed.
e) The RRC Connection is released.
f) The UE transmits a SERVICE REQUEST.
g) The UE transmits an ACTIVATE PDP CONTEXT REQUEST with Request type set to “emergency”.
h) Radio Access Bearer is set up.
i) The SS transmits an ACTIVATE PDP CONTEXT ACCEPT.
j) The UE is switched off.
k) The UE transmits a DETACH REQUEST
l) Cell 2 is switched off and Cell 1 is set as Serving cell.
m) The UE is switched on.
n) The UE transmits an ATTACH REQUEST message.
Expected Sequence
Step |
Direction |
Message |
Comments |
|
UE |
SS |
|||
1 |
SS |
Set the cell type of Cell 1 to the "Non-suitable off cell". Set the cell type of Cell 2 to the "Serving cell". |
||
2 |
SS |
SS waits for [2] min to ensure the UE is in limited service on Cell 2. |
||
3 |
UE |
The UE is caused to originate a call to send user data related to Emergency call. |
||
4 |
–> |
ATTACH REQUEST |
The UE transmits an ATTACH REQUEST message to attach for emergency bearer services. |
|
5 |
<– |
ATTACH ACCEPT |
||
6 |
–> |
ATTACH COMPLETE |
||
7 |
SS |
The SS releases the RRC connection. |
||
8 |
–> |
SERVICE REQUEST |
||
9 |
–> |
ACTIVATE PDP CONTEXT REQUEST |
The UE transmits an ACTIVATE PDP CONTEXT REQUEST message with Request type set to “emergency” |
|
10 |
SS |
Radio Access Bearer is set up. |
||
11 |
<– |
ACTIVATE PDP CONTEXT ACCEPT |
||
12 |
UE |
The UE is switched off or power is removed |
||
13 |
–> |
DETACH REQUEST |
The UE transmits a DETACH REQUEST containing cause "power off". |
|
14 |
SS |
Set the cell type of cell 1 to the "Serving cell". Set the cell type of cell 2 to the "Non-suitable off cell". |
||
15 |
UE |
The UE is switched on. |
||
16 |
–> |
ATTACH REQUEST |
The UE transmits an ATTACH REQUEST message |
Specific Message Contents
None.
13.4.10.5 Test requirements
At Step 4, the UE shall transmit an ATTACH REQUEST with Request type set to “emergency” on Cell 2.
At Step 8, the UE shall transmit a SERVICE REQUEST on Cell 2.
At Step 9, the UE shall transmit an ACTIVATE PDP CONTEXT REQUEST with Request type set to “emergency” on Cell 2.
At Step 16, the UE shall transmit an ATTACH REQUEST on Cell 1 with GMM parameters not reflecting previous ATTACH on cell 2.