Content for TS 23.167 Word version: 19.0.0

1… 4… 5… 7… 7.5… 7.7… 7.7.8… C… D… E… H… I… K… L… M… N…

N.1 General N.2 Test eCall over IMS Session Establishment to a Test Point N.3 Callback from a Test Point with transfer of updated MSD

N (Normative) Procedures for a Test eCall over IMS |R19| p. 69

N.1 General p. 69

The purpose of a test eCall over IMS is to provide a high level of assurance that an eCall capable UE and particularly a UE configured for eCall Only Mode (which may be used very rarely) can reliably support a real eCall over IMS when an actual emergency occurs.

Test eCalls could be used during

the initial deployment to see whether devices are working properly, e.g. product acceptance tests;
product conformity testing and car type-approval in certification labs;
periodic technical inspection over the lifetime of a vehicle (e.g. once every 1-2 years).

A test eCall over IMS includes all features of a real eCall over IMS except for features that are specific to an emergency services call. A test eCall over IMS thus excludes for example the use of an emergency indication at the RRC level, an emergency PDU session or emergency PDN connection, IMS emergency registration and an emergency service indication or eCall type of emergency service indication in a SIP INVITE. However, it includes other aspects of an eCall over IMS as described in clause 7.7, including MSD transfer, MSD update and call back with MSD update.

NOTE:

A test eCall over IMS is a normal IMS session and not an emergency IMS service and thus is established either using the home IMS alone when not roaming or when roaming with IMS home routing or using both the home and visited IMS when roaming with IMS local breakout. Support for a test eCall over IMS is thus always needed from the home IMS. This support is assumed to be enabled through a IMS roaming agreement when the UE is roaming. However, support by a visited IMS is only needed when roaming with IMS local breakout. Because visited IMS support may not always be provided (e.g. in a VPLMN that does not support a real eCall over IMS), HPLMN operators can choose to enforce use of IMS home routing via a roaming agreement that use the architecture in clause 4.15b of TS 23.228 (Roaming Architecture for Voice over IMS with home routed traffic), for any UE that is eCall capable and would require support for a test eCall over IMS.

N.2 Test eCall over IMS Session Establishment to a Test Point p. 69

Figure N.2-1 illustrates a high level call flow for a Test eCall over IMS session establishment to a test point which may either be NG capable and accessible in the PS domain or non NG capable and accessible only in the CS domain. The UE is assumed to be either already attached to or registered on the PS domain if the UE is not in eCall only mode or camped on the PS domain if the UE is in eCall only mode.

Reproduction of 3GPP TS 23.167, Fig. N.2-1: Test eCall over IMS Session Establishment to a Test Point

Figure N.2-1: Test eCall over IMS Session Establishment to a Test Point

Step 1.

The user requests a test eCall. If the UE is not in limited service state and not already attached to or registered on the PS domain, the UE attaches to or registers on the PS domain. The UE performs a normal IMS registration if not already IMS registered. If the UE is in limited service state, the user request is denied and remaining steps are skipped.

Step 2.

The UE sends a SIP INVITE to the IMS core. The Request-URI in the SIP INVITE includes a non-emergency service identity that is defined by a national regulator, PSAP or eCall test provider for testing purposes. The UE also includes initial MSD and an indication of support for transfer of updated MSD. The initial MSD indicates a test eCall.

Step 3a.

If the public user identity for the test point indicates that the test point is accessible in the PS domain, the IMS core routes the SIP INVITE towards the test point.

Step 3b.

If the public user identity for the test point indicates that the test point is accessible in the CS domain, the SIP INVITE is sent to an MGCF/MGW for interfacing to the CS domain.

Step 3c.

If step 3b occurs, the MGCF sends an IAM towards the test point.

Step 4a.

If step 3a occurs, the test point verifies the correctness of the initial MSD and returns a SIP 200 OK to the IMS core. The SIP 200 OK explicitly includes a positive or negative acknowledgement for the initial MSD and an indication of support for transfer of updated MSD.

Step 4b.

If step 3c occurs, the test point returns an ANM to the IMS core.

Step 4c.

If step 4b occurs, the MGCF returns a SIP 200 OK to the IMS core.

Step 5.

The IMS core returns the 200 OK received in step 4a or step 4c to the UE.

Step 6.

The test call establishment is completed with a voice path only.

Steps 7 and 8 apply only when the test point is accessible in the CS domain:

Step 7.

If the UE did not receive a positive or negative acknowledgement for the initial MSD in the 200 OK at step 5, the UE shall attempt to transfer the MSD to the test point via the eCall Inband Modem, as defined in TS 26.267.

Step 8.

The test point may optionally request an updated MSD from the UE. If step 4a occurred, the test point and UE use the procedure defined in clause 7.7.3 to request and transfer the updated MSD. If step 4c occurred, the test point and UE use the eCall Inband Modem procedure, as defined in TS 26.267.

N.3 Callback from a Test Point with transfer of updated MSD p. 71

Figure N.3-1 illustrates a high level call flow for callback to a UE from test point with transfer of updated MSD.

This scenario may occur immediately after a test eCall over IMS has been established to a test point as defined in Annex N.2 and has been released. Successful completion of the procedure in Figure N.3-1 would provide some assurance that a UE would support a PSAP callback with transfer of updated MSD for a real eCall over IMS.

Reproduction of 3GPP TS 23.167, Fig. N.3-1: Callback from a Test Point with transfer of updated MSD

Figure N.3-1: Callback from a Test Point with transfer of updated MSD

Step 1.

The UE performs steps 1 to 8 of the procedure shown in Figure N.2-1 followed by a later call release. The UE remains in the PS domain with a normal IMS registration.

Step 2a.

If steps 3a and 4a had occurred in Figure N.2-1 as part of step 1, the test point sends a SIP INVITE to the IMS Core and includes a public user identity of the UE obtained in step 1. The INVITE also includes an indication that the test point supports transfer of an updated MSD.

Step 2b.

If steps 3c and 4b had occurred in Figure N.2-1 as part of step 1, the test point sends or instigates an IAM to an MGCF/MGW in the HPLMN for interfacing to the CS domain. The IAM contains a public telephone identity of the UE as obtained by the test point at step 1.

Step 2c.

If step 2b occurs, the MGCF sends a SIP INVITE to the IMS core in the HPLMN.

Step 4.

The IMS core forwards the SIP INVITE from step 2a or step 2c to the UE, after the UE has been paged if IDLE.

Step 5.

Voice call establishment is completed with a voice path only.

Step 6a.

If step 2a occurred, the test point may instigate the procedure in Figure 7.7.3-1 to request and obtain an updated MSD. The UE shall reject the request for MSD if not received within a configurable time period of release of the test eCall in step 1.

Step 6b.

If step 2b occurred, the test point may request and obtain an updated MSD via the eCall Inband Modem, as defined in TS 26.267. The UE shall reject the request for MSD if not received within a configurable time period of release of the test eCall in step 1 or if the SIP INVITE in step 4 did not identify the calling party using the same non-emergency service identity that was used by the UE to establish the test eCall over IMS at step 2 in Figure N.2-1.