Content for TS 23.402 Word version: 18.3.0

0… 4… 4.2… 4.2.2 4.2.3 4.3… 4.4… 4.5… 4.5.7… 4.6… 4.7… 4.7.2… 4.8… 4.8.2a… 4.9… 5… 5.2… 5.4… 5.5 5.6… 5.7… 5.8… 6… 6.2… 6.3 6.4… 6.4.3… 6.5… 6.6… 6.7… 6.8… 6.10… 6.13… 6.15… 7… 7.2… 7.3 7.4… 7.5… 7.6… 7.8… 7.10… 8… 8.2.1.2 8.2.1.3… 8.2.2 8.2.3… 8.2.6… 8.3… 8.4… 8.5… 9… 9.3… 9.4… 10… 13… 16… 16.1.2… 16.1.6… 16.2… 16.2.1a… 16.3… 16.4… 16.7… 16.8… 16.10… 17… A… C… E…

16.2.1a Initial Attach in WLAN for Emergency Service on GTP S2a 16.2.2 Initial Attach in WLAN on PMIP S2a 16.2.3 HSS retrieval of information about an UE from the TWAN serving that UE
...

16.2.1a Initial Attach in WLAN for Emergency Service on GTP S2a |R14| p. 269

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 16.2.1a-1: Initial attachment for Emergency Service in WLAN on GTP S2a for roaming, LBO and non-roaming scenarios

Figure 16.2.1a-1: Initial attachment for Emergency Service in WLAN on GTP S2a for roaming, LBO and non-roaming scenarios
(⇒ copy of original 3GPP image)

This procedure applies when the UE needs to establish an IMS emergency session over Trusted WLAN access:

in SCM mode, the UE shall start initial attach procedure for emergency service. If the UE has already active PDN connection, the UE shall detach and start initial attach procedure for emergency service;
in MCM mode, the UE shall perform initial attach for emergency services and triggers the UE Initiated PDN connectivity request procedure in WLAN on S2a procedure. If the UE has already active PDN connection and the TWAN does not supports emergency service, the UE shall detach and start selection of a WLAN supporting Emergengy service and perform initial attach procedure for emergency service;
The emergency service is not supported in TSCM.

The scenario (A) is only applicable for single-connection mode.

The Initial Attach for emergency session follows the same steps that the Initial Attach for a non emergency session, so only the differences with regard to the procedures described in clauses 16.2.1 are documented.

Step 2.

As in step 2 of Figure 16.2.1-1 with the following modifications:

The behaviour defined in clause 4.5.7.2.1 shall apply;
In the EAP authentication procedure, the UE shall add in EAP-AKA' an indication that the authentication is performed for emergency service;
The TWAN shall add in signalling over STa an indication whether it supports emergency service;
The 3GPP AAA server uses this indication to give precedence to this session in case of signalling congestion (over SWx), and for authenticated UE without roaming permission to not carry out roaming and location checks for this UE;
The 3GPP AAA server forwards the indication for emergency service to the TWAN via STa interface.

During the EAP-AKA' Authentication, the identity provided by the UE is defined in clause 4.6.3.

When local policies (related with local regulations) allow unauthenticated emergency sessions, the TWAN forwards the EAP payload received from the UE to the 3GPP AAA Server in the VPLMN serving the specific domain for unauthenticated emergency access;
If the UE includes an identity based on IMEI and the 3GPP AAA server is not configured to support Unauthenticated Emergency Attach (i.e for supporting cases c and d as defined in clause 4.3.12 of TS 23.401), the 3GPP AAA server shall reject the Emergency Attach Request;
If the UE did not include the IMEI in the identity and the 3GPP AAA server is configured for supporting Unauthenticated Emergency Attach (per cases c and d as defined in clause 4.3.12 of TS 23.401), the 3GPP AAA Server shall request the UE to provide its IMEI(SV). In that case the UE shall signal its IMEI(SV) to the 3GPP AAA Server. The 3GPP AAA Server forwards IMEI(SV) received from the UE to the TWAN (over STa);

If the 3GPP AAA server is configured for IMSI required and authentication optional (case c in clause 4.3.12 of TS 23.401) and IMSI is not provided, the 3GPP AAA shall reject the authentication request;

For an Emergency Attach, the IMEI check to the EIR may be performed (step 2a or step 2b). Dependent upon the result, the 3GPP AAA server or 3GPP AAA proxy in roaming case decides whether to continue or to stop the authentication and authorization procedure is based on operator policies.

In attach for emergency service NSWO is not allowed.

The TWAN may provide to the 3GPP AAA server the location information defined in clause 16.1.7 via STa.

During the negotiation between the UE and the AAA server, if the network supports emergency session with unauthenticated UEs and if the UE has not been successfully authenticated by the network, the network shall use the single-connection mode.

If the Transparent Single-Connection Mode is selected by the network (because e.g. it does not support single-connection mode), and the UE supports emergency service, the UE shall abort the authentication.

Upon a successful authorization by the 3GPP AAA server, the TWAN stores subscription information if they are received from the 3GPP AAA, but does not use this information for the emergency PDN connection. It instead uses Emergency Configuration Data to get information on the APN and possibly PDN-GW and / or QoS (APN-AMBR, default QoS) to use for the emergency PDN connection.

The following steps 3-7 are only performed in scenario (A):

Step 3.

The TWAN sends a Create Session Request message to the PGW as described in step 3 of clause 16.2.1 but with following specificities:

No parameter in the Create Session Request message is related with the user subscription. Parameters in the Emergency Configuration Data are used instead;
No Additional Parameters are provided for additional authentication and authorisation with an external AAA Server;
The PDN-GW derives the emergency related policies to apply from the APN received in the Create Session Request message;
For emergency attached UEs, if the IMSI cannot be authenticated or the UE has not provided it (according to cases c) and d) as defined in clause 4.3.12 of TS 23.401), then the IMEI shall be used as UE identifier. It also indicates that the identity has been not authenticated;
The indication for emergency service is used by the TWAN to give precedence to this session in case of signalling congestion reported via GTP-c;
Any APN received by the TWAN from the UE in MCM in WLCP signalling and in SCM from 3GPP AAA server is ignored as the TWAN uses its Emergency Configuration Data to determine the APN to be associated with the emergency PDN connection and possibly to determine the PDN-GW to use. The TWAN shall not check whether this APN is part of UE subscription;
If PDN connection request is for emergency service and the TWAN is not configured to support PDN connections for emergency services the TWANshall reject the PDN Connectivity Request with an appropriate reject cause;
If PDN connection request is for emergency service, the TWAN derives a PDN-GW as defined in clause 4.5.7.2.3.

Step 4.

As Step 4 of clause 16.2.1, with the following specificities:

The PCRF deduces the emergency related policies to apply from the APN received in the IP-CAN Session Establishment message.

Step 5.

As in step 5 of clause 16.2.1, with the following specificities:

The PDN-GW sends an Emergency indication over S6b in order for the 3GPP AAA server to be able to apply specific policies for emergency services. For authenticated UE, the 3GPP AAA server updatesthe HSS with the identity of the PDN-GW.

Step 6.

As in step 6 of clause 16.2.1.

Step 7.

As in step 7 of clause 16.2.18.

Step 8.

As in step 8 of clause 16.2.1 with following modification:

In single-connection mode, if the UE requested EPC access without indicating a requested APN, then the network indicates the selected APN for emergency service. If the requested connectivity feature is not possible, the 3GPP AAA server rejects the request with a relevant authorization failure cause code.

Step 9.

As in step 9 of clause 16.2.1.

Step 10-14.

These steps are not applicable for Initial Attach for emergency service.

Step 15.

As in step 15 of clause 16.2.1.

Step 16.

In multi-connection mode, the procedure "UE initiated Emergency Service PDN connectivity request procedure in WLAN on S2a" in clause 16.8.3 is performed to establish aEmergency PDN connection.

16.2.2 Initial Attach in WLAN on PMIP S2a p. 272

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 16.2.2-1: Initial attachment in WLAN on PMIP S2a for roaming, LBO and non-roaming scenarios

Figure 16.2.2-1: Initial attachment in WLAN on PMIP S2a for roaming, LBO and non-roaming scenarios
(⇒ copy of original 3GPP image)

The home routed roaming, LBO and non-roaming scenarios are depicted in the figure 16.2.2-1:

In the LBO case, the 3GPP AAA Proxy acts as an intermediary, forwarding messages from the 3GPP AAA Server in the HPLMN to the PDN-GW in the VPLMN and vice versa. Messages between the PDN-GW in the VPLMN and the hPCRF in the HPLMN are forwarded by the vPCRF in the VPLMN.
In the home routed roaming and non-roaming cases, the vPCRF is not involved. In the non-roaming cases, the 3GPP AAA Proxy is not involved. In home routed roaming case, the 3GPP AAA Proxy is not involved in steps 5 and 12.

This procedure is also used to establish the first PDN connection over a trusted WLAN with S2a when the UE already has active PDN connections only over a 3GPP access and wishes to establish simultaneous PDN connections to different APNs over multiple accesses.

This procedure is based on clause 16.2.1 with the following key differences:

In step 3 and 10 the TWAN selects S2a protocol variant, PMIPv6. The TWAN sends a Proxy Binding Update message. The details of the Proxy Binding Update message are described in step 5 in clause 6.2.1. Additionally, Proxy Binding Update includes the current TWAN Identifier as described in clause 16.1.7 and the UE Time Zone. The TWAN shall also provide also the IMEI(SV) in Proxy Binding Update when it has received this information from the AAA server
Step 5 and 12 is the same as described in step 7 in clause 6.2.1, except that the Proxy Binding Update message shall contain the Serving Network parameter, which identifies the selected PLMN used for 3GPP-based access authentication i.e. the VPLMN in roaming case, and the HPLMN in non-roaming case.
In step 6 and 13 the PDN-GW sends a Proxy Binding Acknowledgement message. The details of the Proxy Binding Acknowledgement message are described in step 8 in clause 6.2.1.
In step 7 and 14 the established tunnel between the TWAN and PDN-GW is a PMIPv6 tunnel.

16.2.3 HSS retrieval of information about an UE from the TWAN serving that UE |R12| p. 273

The procedure described in this clause supports the HSS retrieval of information about an UE from the TWAN serving that UE.

The information that the HSS can fetch corresponds to user location (TWAN ID) and/or UE Time Zone information (this information may e.g. be provided to an IMS AS that has requested the information as detailed in Annex R of TS 23.228). The User location information sent to the HSS contains information on the last known time of radio contact.

The TWAN ID is defined in clause 16.1.7.

Copy of original 3GPP image for 3GPP TS 23.402, Fig. 16.2.3: HSS retrieval of information about an UE from the TWAN

Figure 16.2.3: HSS retrieval of information about an UE from the TWAN
(⇒ copy of original 3GPP image)

Step 1.

The HSS determines that it needs to get from the TWAN access Information about the UE (defined above the Figure). The HSS sends an UE Information Request (UE Identity (IMSI), Nature of the Information to fetch) via the 3GPP AAA server supporting this UE.

Step 2.

The 3GPP AAA server determines the TWAN supporting an UE and transfers the request to the TWAN. In case of roaming a 3GPP AAA proxy is used.

Step 3.

The TWAN answers by an UE Information Response (UE Identity (IMSI), Information requested). In case of roaming a 3GPP AAA proxy is used

Step 4.

The UE Information Response is relayed from 3GPP AAA server to HSS.