17 Specific features

34.123-13GPPPart 1: Protocol conformance specificationRelease 15TSUser Equipment (UE) conformance specification

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

17.1 Test of autocalling restrictions

17.1.1 General

It is essential that all autocalling apparatus is prevented from continuously dialling a given number, to avoid machines repeatedly disturbing PSTN subscribers in error, or numerous repeat attempts to unobtainable numbers which cause waste of valuable network resources. Therefore autocalling restrictions are defined by TS 22.001.

The tests shall be performed using all of the call methods specified by the supplier in the IXIT statement TS 34.123-2. The supplier shall state any autocalling procedures implemented and how many times they can be repeated to a single number and the minimum re-attempt interval(s), i.e. the complete re-try schedule or algorithm with parameter values. The supplier shall further describe any automatic methods for making repeated calls to a single number. The supplier shall also state in the IXIT statement the number of B-party numbers that can be stored on the list of blacklisted numbers as described in TS 22.001, annex E.

For an external R-interface the supplier shall state in the IXIT statement the procedure for autocalling restrictions for that interface and the possible parameter settings for the number of times the LTE can make a re-attempt and the minimum accepted time between re-attempts accepted by the UE. The conditions for clearing the autocalling constraints shall be stated in the IXIT statement.

For external interfaces the LTE must be programmed so that it clearly attempts to violate the autocalling constraints.

For all the tests in this clause the call setup procedure uses the Generic Setup Procedure for Circuit Switched connection as specified in TS 34.108 clause 7. A Radio Access Bearer to set up shall be selected from one of the speech or CS data bearers within the capability of the UE as specified in the ICS statement. Unless otherwise indicated, this procedure shall only run to the transmission by the SS or UE of the SETUP message (CC).

17.1.2 Constraining the access to a single number (TS 22.001 category 3)

17.1.2.1 Definition

This test checks that when an auto-dialled call to a B-party number fails due to a category 3 cause, only one retry to that number is permitted.

During this test the SETUP messages shall contain the same B-party number.

No manual intervention shall be performed except to initiate and end the test.

17.1.2.2 Conformance requirement

A repeat call attempt may be made when a call attempt is unsuccessful for the reasons listed below (as defined in TS 24.008).

These reasons are classified in three major categories:

1. "Busy destination";

2. "Unobtainable destination – temporary";

3. "Unobtainable destination – permanent/long term".

NOTE: Cause values for each category are defined in TS 22.001, annex E.

The table below describes a repeat call restriction pattern to any B number. This pattern defines a maximum number (n) of call repeat attempts; when this number n is reached, the associated B number shall be blacklisted by the UE until a manual re-set at the UE is performed in respect of that B number. When a repeat attempt to any one B number fails, or is blacklisted, this does not prevent calls being made to other B numbers.

For the categories 1 and 2 above, n shall be 10; for category 3, n shall be 1.

Call attempt	Minimum duration between call attempts
Initial call attempt	–
1st repeat attempt	5 s
2nd repeat attempt	1 min
3rd repeat attempt	1 min
4th repeat attempt	1 min
5th repeat attempt	3 min
.
.
nth repeat attempt	3 min

Reference:

3GPP TS 22.001 annex E.

17.1.2.3 Test purpose

To ensure the correct behaviour of the UE to TS 22.001 Category 3.

17.1.2.4 Method of test

Initial condition.

There shall be no numbers in the list of blacklisted numbers in the UE. The time set between the first re-attempt and the next re-attempt is set to the minimum value possible. The number of re-attempts is set to the lowest possible number, greater than 1, that is supported by the UE. The autocalling function is invoked for the B-party number to be used during the test.

Related ICS/IXIT Statement(s)

ICS: TBD.

IXIT: Description of auto calling management:

– selection of the auto calling;

– indication that the call failed and a re-try is attempted;

– indication that a call finally failed.

Test Procedure

Step	Direction		Message	Comments
	UE	SS
1	UE			"called number" entered
2			GENERIC SETUP PROCEDURE MOBILE ORIGINATED, CS (Up to SETUP)	Establishment cause indicates "originating call".
3			RELEASE COMPLETE	Cause value from category 3 of TS 22.001, Annex E.
4			RRC CONNECTION RELEASE
5			RRC CONNECTION RELEASE COMPLETE	The signalling link is released
6				The UE is invoking the auto calling function. The time between step 4 and 7 must be minimum 5 sec.
7			GENERIC SETUP PROCEDURE MOBILE ORIGINATED, CS (Up to SETUP)	Establishment cause indicates "originating call".
8			RELEASE COMPLETE	Cause value from category 3 of TS 22.001, Annex E.
9			RRC CONNECTION RELEASE
10			RRC CONNECTION RELEASE COMPLETE	The main signalling link is released
11	UE			Clear the auto calling constraint after a minimum of 2 minutes from step 9.

17.1.2.5 Test requirements

The time between step 4 and 7 must be minimum 5 s.

No further call attempt shall be made after step 9.

17.1.3 Constraining the access to a single number (TS 22.001 categories 1 and 2)

17.1.3.1 Definition

This test checks that when an auto-dialled call to a B-party number fails due to a category 2 cause, the time between of retries complies with the requirements, and the number of retries does not exceed that declared by the UE manufacturer, and is never more than 10.

During this test the SETUP messages shall contain the same B-party number.

No manual intervention shall be performed except to initiate and end the test.

17.1.3.2 Conformance requirement

The UE must fulfil the requirements for category 1 and 2, see clause 17.1.2.2.

Reference:

3GPP TS 22.001 annex E.

17.1.3.3 Test purpose

To ensure the correct behaviour of the UE to TS 22.001 Categories 1 and 2.

17.1.3.4 Method of test

Initial condition

There shall be no numbers in the list of blacklisted numbers in the UE. The re-try scheme is set to give the shortest possible intervals between re-tries. The number of re-attempts is set to the maximum possible number (N), that is supported by the UE. The autocalling function is invoked for the B-party number to be used during the test.

Related ICS/IXIT Statement(s)

ICS: TBD

IXIT: Description of auto calling management:

– selection of the auto calling;

– indication that the call failed and a re-try is attempted;

– indication that a call finally failed.

Test Procedure

A, UE originated, generic call setup is performed up to the SETUP message. The SS then releases the establishment with a cause value from category 1 or 2 (TS 22.001, annex E).

The UE is continuously making new generic call setup attempts invoked by the auto calling function after each RRC CONNECTION RELEASE from the SS.

Step	Direction		Message	Comments
Step	UE	SS	Message	Comments
1	UE			"called number" entered
2			GENERIC SETUP PROCEDURE MOBILE ORIGINATED, CS (Up to SETUP)	Establishment cause indicates "originating call".
3			RELEASE COMPLETE	Cause value from category 1 or 2 of TS 22.001, Annex E. This shall be chosen randomly, from both categories. Cause no. 27 shall be excluded if the UE has implemented in category 3 of TS 22.001, as declared in IXIT statement
4			RRC CONNECTION RELEASE
5				The UE is invoking the auto calling function. 1: At the first re-attempt the time between step 4 and 7 must be minimum 5 sec. 2: At the 2^nd, 3^rd and 4^th re-attempt the time between step 4 and 7 must be minimum 1 min. 3: At the 5^th to 10^th re-attempt the time between step 4 and 7 must be minimum 3 min.
6			RRC CONNECTION RELEASE COMPLETE	The signalling link is released
7			GENERIC SETUP PROCEDURE MOBILE ORIGINATED, CS (Up to SETUP)	Establishment cause indicates "originating call".
8			RELEASE COMPLETE	Cause value from category 1 or 2 of TS 22.001, Annex E. This shall be chosen randomly, from both categories. Cause no. 27 shall be excluded if the UE has implemented in category 3 of TS 22.001, as declared in PIXIT statement
9			RRC CONNECTION RELEASE
10			RRC CONNECTION RELEASE COMPLETE	The signalling link is released.
11				The auto calling function shall repeat step 5 to 9 (N‑1) times. The UE shall not make more than maximum 10 re-attempts.
12	UE			Clear the auto calling constraint by manual intervention after a minimum of 4 minutes from step 11. Following the final completion of step 11 the UE initiate a call prior to manual intervention.

17.1.3.5 Test requirements

1: At the first re-attempt the time between step 4 and 7 must be minimum 5 sec. 2: At the 2^nd, 3^rd and 4^th re-attempt the time between step 4 and 7 must be minimum 1 min. 3: At the 5^th to 10^th re-attempt the time between step 4 and 7 must be minimum 3 min.

The UE shall not make more than maximum 10 re-attempts.

17.1.4 Behaviour of the UE when its list of blacklisted numbers is full

17.1.4.1 Definition and applicability

This tests that the UE does not allow autocalling when its list of blacklisted numbers is full.

The number of B-party numbers that can be stored in the list of blacklisted numbers, as stated in the IXIT statement, is M.

This test shall only apply to UE that are capable of autocalling more than M B-party numbers.

17.1.4.2 Conformance requirement

The number of B numbers that can be held in the blacklist is at the manufacturers discretion but there shall be at least 8. However, when the blacklist is full the UE shall prohibit further automatic call attempts to any one number until the blacklist is manually cleared at the UE in respect of one or more B numbers.

Reference

TS 22.001, Annex E.

17.1.4.3 Test purpose

To ensure the correct behaviour of the UE when its list of blacklisted numbers is full.

17.1.4.4 Method of test

Initial condition

The list of blacklisted numbers, in the UE, shall be full. This may be achieved as described in the procedure in clause 17.1.2, applied to M B-party numbers.

Related ICS/IXIT Statement(s)

PICS: TBD.

PIXIT: Description of auto calling management:

– selection of the auto calling;

– indication that the call failed and a re-try is attempted;

– indication that a call finally failed.

Test Procedure

The autocalling function is invoked for a B-party number that is not in the list of blacklisted numbers.

Clear the autocalling constraint by manual intervention after a minimum of 10 s.

17.1.4.5 Test requirements

The UE must not initiate a call.

17.2 Location Services

The test cases for Location Services (LCS) are provided in 3GPP TS 37.571-2 [49], clause 6..

17.2.1 Void

17.2.2 Assisted GPS Network Induced Tests

17.2.2.1 LCS Network Induced location request/ UE-Based GPS/ Emergency Call / with USIM

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.1.1.

17.2.2.2 LCS Network Induced location request/ UE-Based GPS/ Emergency Call / without USIM

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.1.2.

17.2.2.3 LCS Network induced location request/ UE-Assisted GPS/ Emergency call/ With USIM

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.1.3.

17.2.2.4 LCS Network induced location request/ UE-Assisted GPS/ Emergency call/ Without USIM

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.1.4.

17.2.3 Assisted GPS Mobile Originated Tests

17.2.3.1 Void

17.2.3.2 LCS Mobile originated location request/ UE-Based GPS/ Position estimate request/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.1.

17.2.3.3 LCS Mobile originated location request/ UE-Based or UE-Assisted GPS/ Assistance data request/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.2.

17.2.3.4 LCS Mobile originated location request/ UE-Assisted GPS/ Position Estimate/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.3.

17.2.3.5 Void

17.2.3.6 LCS Mobile originated location request/ UE-Based GPS/ Transfer to third party/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.4.

17.2.3.7 LCS Mobile originated location request/ UE-Assisted GPS/ Transfer to third party/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.5.

17.2.3.8 LCS Mobile originated location request/ UE-Based or UE-Assisted GPS/ Assistance data request/ Failure

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.6.

17.2.3.9 LCS Mobile originated location request/ UE-Based GPS/ Position estimate request/ Failure

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.2.7.

17.2.4 Assisted GPS Mobile Terminated Tests

17.2.4.1 LCS Mobile terminated location request/ UE-Based GPS

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.1.

17.2.4.2 LCS Mobile-terminated location request/UE-Based GPS/ Request for additional assistance data/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.2.

17.2.4.3 LCS Mobile-terminated location request/UE-Based GPS/ Failure – Not Enough Satellites

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.3.

17.2.4.4 LCS Mobile terminated location request/ UE-Assisted GPS/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.4.

17.2.4.5 LCS Mobile terminated location request/ UE-Assisted GPS/ Request for additional assistance data/ Success

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.5.

17.2.4.6 LCS Mobile terminated location request/ UE-Based GPS/ Privacy Verification/ Location Allowed if No Response

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.6.

17.2.4.7 LCS Mobile terminated location request/ UE-Based GPS/ Privacy Verification/ Location Not Allowed if No Response

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.7.

17.2.4.8 LCS Mobile terminated location request/ UE-Assisted GPS/ Privacy Verification/ Location Allowed if No Response

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.8.

17.2.4.9 LCS Mobile terminated location request/ UE-Assisted GPS/ Privacy Verification/ Location Not Allowed if No Response

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.9.

17.2.4.10 LCS Mobile terminated location request/ UE-Based or UE-Assisted GPS/ Configuration Incomplete

This test case is provided in 3GPP TS 37.571-2 [49], sub-clause 6.1.3.10.

17.2.5 Void

17.2.6 Void

17.2.7 Void

17.3 Mobility between 3GPP WLAN Interworking and 3GPP Systems

17.3.1 Discovery of the Home Agent via DNS

17.3.1.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems, and discovery of the Home Agent via DNS.

17.3.1.2 Conformance requirement

From TS 24.327 clause 5.1.2.2

The first procedure the UE needs to perform for DSMIPv6 initial attach is the discovery of the node acting as the HA.

The UE discovers the IPv6 address and optionally the IPv4 address of the HA in one of the three following ways:

– via DNS as defined in 3GPP TS 24.303 [3];

– during the PDP context activation procedure in GERAN or UTRAN accesses via the Protocol Configuration Options as defined in 3GPP TS 24.008 [4] if the HA IP address is available in the GGSN; or

– via IKEv2 during tunnel setup with PDG for 3GPP I-WLAN as defined in annex B if the HA IP address is available in the PDG.

From TS 24.303 clause 5.1.2.1.2

A UE performing Home Agent discovery based on DNS shall support the implementation of standard DNS mechanisms.

The UE shall perform DNS Lookup by Home Agent Name as specified in IETF RFC 5026 [10].The QNAME shall be set to the requested HA-APN. The HA-APN shall be constructed as specified in 3GPP TS 23.003 [17]. If a HA has both an IPv4 and an IPv6 address, the corresponding DNS record should be configured with both ‘AAAA’ and ‘A’ records. Accordingly the UE should perform one DNS lookup procedure to retrieve both ‘AAAA’ and ‘A’ records. The DNS server replies with one ‘AAAA’ and one ‘A’ record.

Reference(s)

3GPP TS 24.327 clause 5.1.2.2

3GPP TS 24.303 clause 5.1.2.1.2

17.3.1.3 Test purpose

The purpose of this test case is to verify that when the UE is configured to discover the IP address of the Home Agent via DNS, it transmits a DNS Query with QNAME set to the FQDN of the Home Agent.

17.3.1.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE is configured to discover the Home Agent address via DNS.

– The UE is configured with a DNS server address.

– The UE is configured with the HA-APN Network Identifier.

– The UE has acquired an IP address.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Support for being configured to discover the Home Agent address via DNS

Test procedure

a) The UE transmits a DNS Query message with QNAME set to the FQDN of the Home Agent (derived from HA-APN Network Identifier and PLMN information).

b) The SS transmits a DNS Response message with the IPv6 and IPv4 addresses of the Home Agent.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	à		DNS Query	QNAME set to FQDN of the Home Agent
2	ß		DNS Response	DNS Response message contains IPv6 and IPv4 addresses of the Home Agent

Specific Message Contents

DNS Query (Step 1)

Information Element	Value/remark
QR=	‘0’B
QPCODE=	‘0000’B
QNAME=	Fully Qualified Domain Name of the Home Agent
QTYPE=	A
QCLASS=	IN
QNAME=	Fully Qualified Domain Name of the Home Agent
QTYPE=	AAAA
QCLASS=	IN

DNS Response (Step 2)

Information Element	Value/remark
QR=	‘1’B
QPCODE=	‘0000’B
QNAME=	Same as received in DNS Query (Step 1)
QTYPE=	A
QCLASS=	IN
QNAME=	Same as received in DNS Query (Step 1)
QTYPE=	AAAA
QCLASS=	IN
RR
NAME	Same as received in DNS Query (Step 1)
TYPE	A
CLASS	IN
RDATA	IPv4 address of HA
RR
NAME	Same as received in DNS Query (Step 1)
TYPE	AAAA
CLASS	IN
RDATA	IPv6 address of HA

17.3.1.5 Test requirements

1. At Step 1, UE shall send a DNS Query message with QNAME set to the FQDN of the Home Agent (derived from HA-APN Network Identifier and PLMN information).

17.3.2 Discovery of the Home Agent address and Home Network Prefix during PDP context activation procedure

17.3.2.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.2.2 Conformance requirement

from TS 24.327, subclause 5.1.2.2

The first procedure the UE needs to perform for DSMIPv6 initial attach is the discovery of the node acting as the HA.

The UE discovers the IPv6 address and optionally the IPv4 address of the HA in one of the three following ways:

– via DNS as defined in 3GPP TS 24.303 [3];

– during the PDP context activation procedure in GERAN or UTRAN accesses via the Protocol Configuration Options as defined in 3GPP TS 24.008 [4] if the HA IP address is available in the GGSN; or

– via IKEv2 during tunnel setup with PDG for 3GPP I-WLAN as defined in annex B if the HA IP address is available in the PDG.

If the HA IP address(es) are available in the GGSN, the GGSN shall return the HA IP address(es) in the Protocol Configuration Options during the PDP context activation procedure when attaching to the GERAN or UTRAN accesses. If the HA IP address(es) are not available in the GGSN, the UE shall discover the HA IP address(es) by DNS if the UE wants to perform the handover to 3GPP I-WLAN.

If the UE requests the HA IP address(es) during the IPsec tunnel setup to PDG in 3GPP I-WLAN connection and if the HA IP address(es) are available in the PDG, the PDG shall return the HA IP address(es) in IKEv2 configuration payload attributes as defined in annex B. If the HA IP address(es) are not available in the PDG, the UE shall discover the HA IP address(es) by DNS before performing the H1 PDN attach.

The UE shall support the HA discovery based on DNS and on Protocol Configuration Options. The UE may support the HA discovery based on IKEv2.

The HA IP address(es) may also be pre-configured in the UE.

from TS 24.327, subclause 5.1.2.3

The UE shall perform the security association establishment with the HA as specified in 3GPP TS 24.303 [3]. For this procedure the UE shall support IKEv2 protocol and EAP over IKEv2 as described in IETF RFC 4306 [9]. The detailed procedure and supported extensions for this step are specified in 3GPP TS 24.303 [3]. The UE may use either EAP-SIM or EAP-AKA for authentication purposes.

During the IKEv2 exchange, the UE shall request an IPv6 home network prefix as specified in 3GPP TS 24.303 [3]. The UE shall then auto-configure an IPv6 home address from the received prefix and create child SA as specified in 3GPP TS 24.303 [3].

In the IKEv2 signalling the UE should indicate the target PDN the UE wants to connect to in the IDr payload as specified in 3GPP TS 24.303 [3].

from TS 24.327, subclause 5.1.2.4

The DSMIPv6 home link detection function is used by the UE to detect if, for a specific PDN, an access interface is on the home link from DSMIPv6 perspective. The home link detection function for a specific PDN connection shall be performed whenever the UE receives a new IPv6 prefix, either at initial attach or after a handover.

The UE is informed of the IPv6 prefix associated with a specific access interface. If the UE is connected to GPRS systems, the UE knows the IPv6 prefix via the IPv6 address auto configuration as described in 3GPP TS 29.061 [6]. If UE is connected to the 3GPP I-WLAN, it knows the IPv6 prefix via IPv6 address auto configuration as described in 3GPP TS 29.161 [7].

In the scenarios considered in this specification, the Home Network Prefix associated to the PDN connection can be assigned:

via Protocol Configuration Options from the GGSN in GPRS systems as specified in 3GPP TS 24.008 [4];
via IPsec security associations bootstrap with the PDG in I-WLAN as specified in annex B;
via the establishment of IPsec security associations with the HA as specified in 3GPP TS 24.303 [3] subclause 5.1.2.2; or
the HNP may also be pre-configured in the UE.

NOTE: If a pre-configured HNP is available, the UE can use it for home link detection. However the UE cannot use it for the IPv6 address auto configuration.

The home link detection procedure performed by the UE is specified in 3GPP TS 24.303 [3].

If the UE detects it is in the home link for this specific PDN over the access interface, the UE shall not perform the H1 PDN attach. If the UE detects it is not on the home link, the UE shall perform IKEv2 procedure for security associations setup and IPv6 prefix and optionally IPv4 HA assignment if the UE does not have a valid security association with the HA, and then the UE shall send a Binding Update as specified in 3GPP TS 24.303 [3].

Reference(s)

3GPP TS 24.327 clause 5.1.2.32

3GPP TS 24.327 clause 5.1.2.3

3GPP TS 24.327 clause 5.1.2.4

17.3.2.3 Test purpose

1) To verify that when the UE has sets up PDP context, it requests for Home Agent IPv6 address and optionally for Home Agent IPv4 address and Home Network Prefix

17.3.2.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in GMM-state "GMM-REGISTERED, normal service".

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) UE sets request for a Home Agent address and Home Network Prefix to the GGSN within the Protocol Configuration Options IE in Activate PDP Context Request message. UE initiates an Activate PDP Context procedure.

b) SS responds with an Activate PDP Context Accept including list of HA addresses and Home Network Prefix..

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	à		Activate PDP Context Request
2	ß		Activate PDP Context Accept

Specific Message Contents

Activate PDP Context Request (step 1)

NOTE: Containers can be in any order.

Information Elements	Value/Remarks
Protocol Configuration options
– Additional Parameters
— container 1 Identifier	0007H (DSMIPv6 Home Agent Address);
— Container 1 Length	0 bytes
— container 2 Identifier	0008H (DSMIPv6 Home Network Prefix) (optional);
— Container 2 Length	0 bytes
— container 3 Identifier	0009H (DSMIPv6 IPv4 Home Agent Address) (optional)
— Container 3 Length	0 bytes

Activate PDP Context Accept (step 2)

Information Elements	Value/Remarks
Protocol Configuration options
– Additional Parameters
— container 1 Identifier	0007H (DSMIPv6 Home Agent Address);
— Container 1 Length	16 bytes;
— Container 1 contents	IPv6 HA Address set by SS;
— container 2 Identifier	0008H (DSMIPv6 Home Network Prefix); sent if requested by UE
— Container 2 Length	17 bytes;
— Container 2 contents	Home Network Prefix set by SS;
— container 3 Identifier	0009H (DSMIPv6 IPv4 Home Agent Address); sent if requested by UE
— Container 3 Length	4 bytes;
— Container 3 contents	IPv4 HA Address set by SS;

17.3.2.5 Test requirements

1) In step 1, the UE shall request for HA IPv6 address and optionally HA IPv4 address and Home Network Prefix to the GGSN within the Protocol Configuration Options IE.

17.3.3 Void

17.3.4 Security association establishment

17.3.4.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.4.2 Conformance requirement

From TS 24.327 clause 5.1.2.3

In the IKEv2 signalling the UE should indicate the target PDN the UE wants to connect to in the IDr payload as specified in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.1.2.2

The UE shall support the IKEv2 protocol (see IETF RFC 4306 [14]) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in IETF RFC 4306 [14] to perform authentication with an AAA server. In a case an additional authentication and authorization of the IPSec security association is needed with an external AAA server, then the additional authentication steps during the IKEv2 exchange shall be supported as specified in IETF RFC 4739 [23] and described in 3GPP TS 33.234 [24].

The UE shall support IPsec ESP (see IETF RFC 4303 [11]) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4]. The UE shall support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [23] in order to support authentication with an external AAA server. The UE shall support the redirect mechanism as defined in draft-ietf-ipsecme-ikev2-redirect [30].

The UE shall initiate the security association establishment procedure by sending the IKE_SA_INIT request message defined in IETF RFC 4306 [14] to the HA. The UE shall indicate support for the HA reallocation by including a REDIRECT_SUPPORTED payload in the IKE_SA_INIT request as specified in draft-ietf-ipsecme-ikev2-redirect [30]. On receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message including the MN-NAI in the IDi payload and the Access Point Name (APN) of the target PDN the UE wants to connect to in the IDr payload. The APN shall be formatted as defined in 3GPP TS 23.003 [17]. The username part of the MN-NAI included in "IDi" payload may be an IMSI, pseudonym or re-authentication ID. The UE shall include in the IDi payload the same MN-NAI it includes in the EAP-Response/Identity within the EAP-AKA exchange.

In the very first EAP-Response/Identity within the IKEv2 exchange the UE shall include a NAI whose username is derived from IMSI. In subsequent exchanges the UE should use pseudonyms and re-authentication identities provided by the 3GPP AAA server as specified in IETF RFC 4187 [26].

NOTE: Fast re‑authentication mechanism is optional, and therefore is an implementation option in the UE and operator configuration issue (i.e. it also depends on whether the AAA server sent a re-authentication ID during previous EAP authentication) whether to use it during security association establishment.

EAP-AKA over IKEv2 shall be used to authenticate UE in the IKE_AUTH exchange, while public key signature based authentication with certificates shall be used to authenticate the HA.

During the IKEv2 exchange, the HA may trigger the UE to perform the HA reallocation procedure. If the UE receives as part of the IKE_AUTH response message a REDIRECT payload containing the IP address of a target HA as specified in subclause 5.1.3.1, the UE shall initiate a new IKEv2 security association with the target HA. The UE shall terminate the IKEv2 security association with the initial HA by sending an IKEv2 Informational message with a DELETE payload as specified in IETF RFC 4306 [14].

During the IKEv2 exchange, the UE shall request the allocation of an IPv6 home prefix through the Configuration Payload in the IKE_AUTH. Since in EPS a unique IPv6 prefix is assigned to the UE, the UE shall include a MIP6_HOME_PREFIX attribute in the CFG_REQUEST message as described in IETF RFC 5026 [10]. In addition the UE may include the INTERNAL_IP6_DNS attribute in the CFG_REQUEST as described in IETF RFC 4306 [14] to request the DNS server IPv6 address of the PLMN it is connecting to via DSMIPv6. In the same way the UE may include the INTERNAL_IP4_DNS attribute in the CFG_REQUEST to request the IPv4 address of the DNS server.

The UE shall then auto-configure a Home Address from the IPv6 prefix received from the HA and shall run a CREATE_CHILD_SA exchange to create the security association for the new Home Address. In the CREATE_CHILD_SA exchange the UE shall include the Home Address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate the IPsec security association for protecting the Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4].

Reference(s)

3GPP TS 24.327 clause 5.1.2.3

3GPP TS 24.303 clause 5.1.2.2

17.3.4.3 Test purpose

1. To verify that when the UE has acquired the IP address of the Home Agent, it transmits an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment.

2. To verify that when the UE receives an IKA_SA_INIT response message, it transmits an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX to receive the prefix to use for Home Address configuration.

3. To verify that when the UE receives an IKE_AUTH Response message including an EAP-Request/AKA Challenge, it transmits an IKE_AUTH Request message containing the correct EAP-Response/AKA-Challenge.

4. To verify that when the UE receives an IKE_AUTH Response message including EAP-Success, it transmits an IKE_AUTH Request message with Authentication payload.

5. To verify that when the UE receives an IKE_AUTH Response message with configuration payload MIP6_HOME_PREFIX containing the Home Network Prefix HNP associated to the UE, it transmits a CREATE_CHILD_SA Request message including traffic selectors fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU)/Binding Acknowledgments (BA) messages.

17.3.4.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

– The UE has discovered the IP address of the Home Agent (either via DNS, IKEv2 signalling or during PDP context activation procedure).

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The UE transmits an IKE_SA_INIT message addressed to the Home Agent.

b) The SS transmits an IKE_SA_INIT message.

c) The UE transmits an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX, a MN-NAI derived from UE IMSI in the IDi field and an APN in the IDr field.

d) The SS transmits an IKE_AUTH Response message including an EAP-Request/AKA-Challenge.

e) The UE transmits an IKE_AUTH Request message including the EAP-Response/AKA-Challenge.

f) The SS transmits an IKE_AUTH Response message including EAP-Success.

g) The UE transmits an IKE_AUTH Request message with Authentication payload.

h) The SS transmits an IKE_AUTH Response message with configuration payload MIP6_HOME_PREFIX containing the Home Network Prefix HNP associated to the UE.

i) The UE transmits a CREATE_CHILD_SA Request message including traffic selectors fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU) / Binding Acknowledgments (BA) messages.

j) The SS transmits a CREATE_CHILD_SA Response message.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	à		IKE_SA_INIT	IKE_SA_INIT addressed to the Home Agent
2	ß		IKE_SA_INIT
3	à		IKE_AUTH Request	IKE_AUTH Request message contains the configuration payload MIP6_HOME_PREFIX, a MN-NAI derived from UE IMSI in the IDi field and an APN in the IDr field
4	ß		IKE_AUTH Response	IKE_AUTH Response message includes an EAP-Request/AKA-Challenge
5	à		IKE_AUTH Request	IKE_AUTH Request message includes the EAP-Response/AKA-Challenge
6	ß		IKE_AUTH Response	IKE_AUTH Response message includes EAP-Success
7	à		IKE_AUTH Request	IKE_AUTH Request message with Authentication payload
8	ß		IKE_AUTH Response	IKE_AUTH Response message with configuration payload MIP6_HOME_PREFIX containing the Home Network Prefix HNP associated to the UE
9	à		CREATE_CHILD_SA Request	CREATE_CHILD_SA Request message includes traffic selectors fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU) / Binding Acknowledgments (BA) messages
10	ß		CREATE_CHILD_SA Response

Specific Message Contents

IKE_SA_INIT (Step 1)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Set by the UE
Responder’s IKE_SA SPI	‘0’B (First message in IKE_SA_INIT exchange)
Next Payload	‘00100001’B (SA)
Exchange Type	‘00100010’B (IKE_SA_INIT)
Security Association Payload
Next Payload	’00100010’B (KE)
More Proposal Proposal # Protocol ID SPI size Number of transforms More transform Transform type Transform ID More transform Transform type Transform ID More transform Transform type Transform ID Last transform Transform type Transform ID Last proposal Proposal # Protocol ID SPI size Number of transforms More transform Transform type Transform ID More transform Transform type Transform ID More transform Transform type Transform ID Last transform Transform type Transform ID Key Exchange Payload Next Payload DH Group # Key Exchange Data Nonce Payload Next Payload Nonce data REDIRECT_SUPPORTED Notify Payload Next Payload Protocol ID SPI size Notify Message Type	‘00000010’B ‘00000001’B ‘00000001’B (IKE) ‘00000000’B ‘00000010’B ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00000011’B (3DES in CBC mode) ‘00000011’B (This is the transform for prf) ‘00000010’B (PRF) ‘00000010’B (PRF_HMAC_SHA1) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000010’B (HMAC-SHA1-96) ‘00000000’B (This is the transform for DH) ‘00000100’B (DH) ‘00000010’B (Diffie-Hellman group 2) ‘00000000’B ‘00000010’B (Second cryptographic suite) ‘00000001’B (IKE) ‘00000000’B ‘00000010’B ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00001011’B (AES with 128-bit keys in CBC mode) ‘00000011’B (This is the transform for prf) ‘00000010’B (PRF) ‘00000100’B (PRF_AES128_XCBC) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000101’B (AES-XCBC-MAC-96) ‘00000000’B (This is the transform for DH) ‘00000100’B (DH) ‘00000010’B (Diffie-Hellman group 2) ‘00101000’B (Nonce) ‘0000000000000010’B (DH group 2) Set by the UE ‘00101001’B (Notify REDIRECT_SUPPORTED) Random number set by the UE ‘00000000’B (No Next Payload) ‘00000000’B (Notification not specific to a particular SA) ‘00000000’B (SPI field not present) ‘0100000000010110’B (REDIRECT_SUPPORTED)

IKE_SA_INIT (Step 2)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Set by the SS
Next Payload	‘00100001’B (SA)
Exchange Type	‘00100010’B (IKE_SA_INIT)
Security Association Payload
Next Payload	’00100010’B (KE)
Proposal Key Exchange Payload Next Payload DH Group # Key Exchange Data Nonce Payload Next Payload Nonce data	One of the 2 proposals included in IKE_SA_INIT at Step 1 ‘00101000’B (Nonce) ‘0000000000000010’B (DH group 2) Set by the SS ‘00000000’B (No Next Payload) Set by the SS

IKE_AUTH Request (Step 3)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00100011’B (IDi)
Initialization Vector Encrypted IKE Payloads Identification – Initiator Payload Next Payload ID Type ID Configuration Payload Next Payload CFG Type Configuration Attribute Length Security Association Payload Next Payload Proposals Traffic Selector – Initiator Payload Next Payload Traffic selector data Traffic Selector – Responder Payload Next Payload Traffic selector data Identification – Responder Payload Next Payload ID Type ID Padding Pad Length Integrity checksum data	Random value set by the UE ‘00101111’B (CP) ‘00000010’B Set to MN-NAI ‘00100001’B (SA) ‘00000001’B (Request) ‘00010000’B (MIP6_HOME_PREFIX attribute) ‘0000000000000000’B ‘00101100’B (TSi) Any set of allowed values ‘00101100’B (TSr) Any set of allowed values ‘00100100’B (IDr) Any set of allowed values ‘00000000’B (No Next Payload) ‘00000010’B APN Set by the UE Set by the UE Set by the UE

IKE_AUTH Response (Step 4)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00100100’B (IDr)
Initialization Vector Encrypted IKE Payloads Identification – Responder Payload Next Payload ID Type ID Certificate Payload Next Payload Cert encoding Certificate data Length Extensible Authentication Payload Next Payload Code Type Subtype Attribute Type AT_RAND Attribute Type AT_AUTN Padding Pad Length Integrity checksum data	Set by the SS ‘00100101’B (CERT) ‘00000010’B APN ‘00110000’B (EAP) ’00000100’B (X.509 certificate – signature) Set by the SS (DER encoded X.509 certificate) ‘0000000000000000’B ‘00000000’B (No Next Payload) ‘00000001’B (Request) ‘00010111’B (AKA) AKA-Challenge ’00000001’B (AT_RAND) An arbitrarily selected 128 bits value ‘00000010’B (AT_AUTN) See TS 24.301 subclause 9.9.3.2 Set by the SS Set by the SS Set by the SS

IKE_AUTH Request (Step 5)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00110000’B (EAP)
Initialization Vector Encrypted IKE Payloads Extensible Authentication Payload Next Payload Code Type Subtype Attribute Type AT_RES Padding Pad Length Integrity checksum data	Random value set by the UE ‘00000000’B (No Next Payload) ‘00000010’B (Response) ‘00010111’B (AKA) AKA-Challenge ’00000011’B (AT_RES) See TS 24.301 subclause 9.9.3.4 Set by the UE Set by the UE Set by the UE

IKE_AUTH Response (Step 6)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00110000’B (EAP)
Initialization Vector Encrypted IKE Payloads Extensible Authentication Payload Next Payload Code Padding Pad Length Integrity checksum data	Set by the SS ‘00000000’B (No Next Payload) ‘00000011’B (Success) Set by the SS Set by the SS Set by the SS

IKE_AUTH Request (Step 7)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00100111’B (AUTH)
Initialization Vector Encrypted IKE Payloads Authentication Payload Next Payload Auth Method Auth Data Padding Pad Length Integrity checksum data	Random value set by the UE ‘00000000’B (No Next Payload) ’00000010’B (Shared Key Integrity code) Derived from the MSK obtained from AKA exchange Set by the UE Set by the UE Set by the UE

IKE_AUTH Response (Step 8)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00100011’B (IKE_AUTH)
Encrypted Payload
Next Payload	‘00100111’B (AUTH)
Initialization Vector Encrypted IKE Payloads Authentication Payload Next Payload Auth Method Auth Data Configuration Payload Next Payload CFG Type Configuration Attribute Length Prefix lifetime Home Prefix Prefix length Security Association Payload Next Payload Proposal Traffic Selector – Initiator Payload Next Payload Traffic Selector data Traffic Selector – Responder Payload Next Payload Traffic Selector data Padding Pad Length Integrity checksum data	Set by the SS ‘00101111’B (CP) ’00000010’B (Shared Key Integrity code) Derived from the MSK obtained from AKA exchange ‘00100001’B (SA) ‘00000010’B (Reply) ‘00010000’B (MIP6_HOME_PREFIX attribute) ‘0000000000010101’B Any allowed value IPv6 prefix – 16 bytes ‘10000000’B ‘00101101’B (TSi) One of the 2 proposals included in IKE_AUTH Request at Step 3 ‘00101100’B (TSr) Any allowed set of values ‘00000000’B (No Next Payload) Any allowed set of values Set by the SS Set by the SS Set by the SS

CREATE_CHILD_SA Request (Step 9)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100100’B (CREATE_CHILD_SA)
Encrypted Payload
Next Payload Initialization Vector	‘00100001’B (SA) Random value set by the UE
Encrypted IKE Payloads Security Association Payload Next Payload More proposal Proposal # Protocol ID SPI size Number of transforms SPI More transform Transform type Transform ID Last transform Transform type Transform ID Last proposal Proposal # Protocol ID SPI size Number of transforms SPI More transform Transform type Transform ID Last transform Transform type Transform ID Nonce Payload Next Payload Nonce data Traffic Selector – Initiator Payload Next Payload Traffic Selector data Traffic Selector – Responder Payload Next Payload Traffic Selector data Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Padding Pad Length Integrity checksum data	‘00101000’B (Ni) ‘00000010’B ‘00000001’B (First cryptographic suite) ‘00000011’B ‘00000100’B ‘00000010’B Set by the UE ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00000011’B (3DES in CBC mode) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000010’B (HMAC-SHA1-96) ‘00000000’B ‘00000010’B (Second cryptographic suite) ‘00000011’B (ESP) ‘00000100’B ‘00000010’B Set by the UE ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00001011’B (AES with 128-bit keys in CBC mode) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000101’B (AES-XCBC-MAC-96) ‘00101100’B (TSi) Random number set by the UE ‘00101101’B (TSr) Any set of values containing the traffic selector of the CREATE_CHILD_SA Response at Step 10 ‘00000000’B (SPI field not present) ‘00101001’B (Notify – Use transport mode) Any set of values containing the traffic selector of the CREATE_CHILD_SA Response at Step 10 ‘00101001’B (Notify – Use transport mode) ‘00000011’B (ESP) ‘00000100’B ‘1000000000000111’B (Use transport mode) Same as that set by the UE in SA proposal #1 ‘00000000’B (No Next Payload) ‘00000011’B (ESP) ‘00000100’B ‘1000000000000111’B (Use transport mode) Same as that set by the UE in SA proposal #1 Set by the UE Set by the UE Set by the UE

CREATE_CHILD_SA Response (Step 10)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA_INIT as Step 1
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA_INIT as Step 2
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100100’B (CREATE_CHILD_SA)
Encrypted Payload
Next Payload Initialization Vector	‘00100001’B (SA) Set by the SS
Encrypted IKE Payloads Security Association Payload Next Payload Last proposal Proposal # Protocol ID SPI size SPI First transform Transform type Transform attribute type Last transform Transform type Transform attribute type Nonce Payload Next Payload Nonce data Traffic Selector – Initiator Payload Next Payload Number of traffic selectors TS type IP protocol Start port End port Starting address Ending address TS type IP protocol Start port End port Starting address Ending address Traffic Selector – Responder Payload Next Payload Number of traffic selectors TS type IP protocol Start port End port Starting address Ending address TS type IP protocol Start port End port Starting address Ending address Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Padding Pad Length Integrity checksum data	‘00101000’B (Nr) ‘00000000’B One of the 2 proposals included in the CREATE_CHILD_SA Request at Step 9 ‘00000011’B (ESP) ‘00000100’B Set by the SS ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) The corresponding value of the chosen proposal ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) The corresponding value of the chosen proposal ‘00101100’B (TSi) Set by the SS ‘00101101’B (TSr) ‘00000010’B ‘00001000’B (IPv6 range) ‘10000111B (Mobility header) ‘0000010100000000’B (BU) ‘0000010100000000’B (BU) HoA address derived from HNP HoA address derived from HNP ‘00001000’B (IPv6 range) ‘10000111B (Mobility header) ‘0000011000000000’B (BA) ‘0000011000000000’B (BA) HoA address derived from HNP HoA address derived from HNP ‘00101001’B (Notify – Use transport mode) ‘00000010’B ‘00001000’B (IPv6 range) ‘10000111B (Mobility header) ‘0000010100000000’B (BU) ‘0000010100000000’B (BU) HA address HA address ‘00001000’B (IPv6 range) ‘10000111B (Mobility header) ‘0000011000000000’B (BA) ‘0000011000000000’B (BA) HA address HA address ‘00000000’B (No Next Payload) ‘00000011’B (ESP) Set by the SS ‘1000000000000111’B (Use transport mode) Same as that set by the SS in the accepted proposal Set by the UE Set by the UE Set by the UE

17.3.4.5 Test requirements

At Step 1, UE shall send an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment.
At Step 3, UE shall send an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX.
At Step 5, UE shall send an IKE_AUTH Request message containing the correct EAP-Response/AKA-Challenge.
At Step 7, UE shall send an IKE_AUTH Request message with Authentication payload.
At Step 9, UE shall send a CREATE_CHILD_SA Request message including traffic selectors fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU)/Binding Acknowledgments (BA) messages.

17.3.5 Registration of a new IPv6 CoA (Binding Update/Acknowledgment procedure in IPv6 network)

17.3.5.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.5.2 Conformance requirement

From TS 24.327 clause 5.1.2.5

After establishing the security association and obtaining the IPv6 home network prefix and after performing the home link detection, if not on the home link, the UE shall send a Binding Update message as specified in 3GPP TS 24.303 [3] to register its IPv6 home address with its care-of address.

The UE may also request in the Binding Update an IPv4 home address based on the procedure specified in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.1.2.3

The DSMIPv6 Home Link Detection Function is used by the UE to detect if an access interface is on the home link for a PDN from a DSMIPv6 perspective. The Home Link Detection function shall be performed before sending DSMIPv6 Binding Update via the same access interface.

To perform the Home Link Detection procedure, the UE shall compare the assigned Home Network Prefix for a PDN with the IPv6 prefix or prefixes included in the Prefix Information Option in the Router Advertisements received on the local link. The Home Network Prefix can be assigned in a 3GPP access via PCO, as specified in 3GPP TS 24.301 [15], or via IKEv2 as specified in subclause 5.1.2.2. If there is a match between the Home Network Prefix and one of the local prefixes, the UE is attached on the home link over the respective access interface and shall not send a Binding Update to the HA unless the UE currently has a valid DSMIPv6 Binding Update list entry. If the UE has a valid DSMIPv6 Binding Update list entry, the UE shall proceed to perform the action specified in subclause 5.2.2.4. If there is not any match, the UE shall proceed as specified in subclause 5.1.2.4.

NOTE: The UE does not need to run IKEv2 for home link detection if the Home Network prefix is dynamically received in a PCO Information Element.

From TS 24.303 clause 5.1.2.4

After establishing the security association and obtaining the IPv6 Home Address, the UE shall send a Binding Update message as specified in IETF RFC 3775 [6] and IETF RFC 5555 [2] in order to register its Home Address and Care-of Address at the HA, if it detects it is in the foreign network.

If both IPv4 and IPv6 Care-of Address are received at the foreign network, the UE shall first attempt to use the IPv6 Care-of Address for its binding registration. The UE shall not register both IPv4 and IPv6 Care-of Address to its HA.

If IPv6 Care-of Address is used for initial binding registration, the UE shall send the Binding Update message to the IPv6 address of the HA. In this Binding Update message the H (home registration) and A (acknowledge) bits shall be set. If the UE needs an IPv4 Home Address, the UE shall include the 0.0.0.0 address in the IPv4 Home Address option to request a dynamic IPv4 Home Address.

When IPv6 Care-of Address is used for initial binding registration, the Alternate Care-of Address option shall be used by the UE to carry the Care-of Address inside a Mobility Header which is protected by ESP. If this option is present, the address included in this option is the same address present in the source address of the IPv6 packet.

If IPv4 Care-of Address is used for initial binding registration, the UE shall send the Binding Update as follows (see IETF RFC 5555 [2]):

– The IPv6 packet, with the IPv6 Home Address as the Source Address field of the IPv6 header, shall be encapsulated in UDP.

– The UE shall include the IPv4 Care-of Address as the Source Address field of the IPv4 header and the HA IPv4 address as the Destination Address field of the IPv4 header.

– The UE shall include the IPv4 Care-of Address option containing the IPv4 Care-of Address.

– The UE shall set the H (home registration) and A (acknowledge) flags.

– The UE shall set the F (UDP encapsulation required) flag to 0.

– The UE shall set the R (Mobile Router Flag) flag to 1.

– If the UE needs an IPv4 Home Address, the UE shall include an IPv4 Home Address option with the 0.0.0.0 address in the Binding Update message, as defined in IETF RFC 5555 [2].

When the UE receives the Binding Acknowledgement from the HA, it shall validate it based on the rules described in IETF RFC 3775 [6] and IETF RFC 5555 [2]. If the Binding Acknowledgement contains the successful status code 0 ("Binding Update Accepted"), the UE shall create an entry for the registered Home Address in its Binding Update List and may start sending packets containing its IPv6 Home Address or other IPv6 addresses auto-configured from the assigned home network prefix.

If the Binding Acknowledgement contains a value of 128, the UE may re-send the BU as specified in IETF RFC 3775 [6]. If the Binding Acknowledgement contains a value from 129 to 133 as specified in IETF RFC 3775 [6] or a value from 140 to 143 as specified in IETF RFC 3963 [29], the UE shall not send the BU to the HA and should discover another HA.

If the Binding Acknowledgment contains an IPv4 Address Acknowledgement option with status code value from 0 to 127 (indicating success), the UE shall create two entries in its Binding Update List, one for the IPv6 Home Address and another for the IPv4 Home Address. If the Binding Acknowledgement contains an IPv4 Address Acknowledgment option with status code indicating error (i.e. 128 or higher), the UE shall create an entry only for the IPv6 HoA in its binding update list. Moreover, if the status code is 129 ("Administratively prohibited") or 132 ("Dynamic IPv4 home address assignment not available"), the UE shall not re-send the Binding Update and it shall use only the IPv6 HoA. If the Binding Acknowledgement contains an IPv4 Address Acknowledgement option with status 128 ("Failure, reason unspecified"), 130 ("Incorrect IPv4 home address"), 131 ("Invalid IPv4 address") or 133 ("Prefix allocation unauthorized") it shall re-send the Binding Update including the 0.0.0.0 address in the IPv4 Home Address option. If the Binding Acknowledgement does not contain an IPv4 Address Acknowledgment option, the UE shall create an entry only for the IPv6 HoA in its binding update list.

NOTE: The value to be used to identify the IPv4 address acknowledgement option in the mobility header is 30;

The UE may then send data traffic either with the IPv6 Home Address or with the IPv4 Home Address. If the UE is located on an IP6-enabled link, it shall send IPv6 packets as described in IETF RFC 3775 [6]; IPv4 traffic shall be encapsulated in IPv6 packets as described in IETF RFC 5555 [2]. If the UE is located on an IPv4-only link and the Binding Acknowledgement contains the NAT detection option with the F flag set, the UE shall send IPv6 and IPv4 packets following the vanilla UDP encapsulation rules specified in IETF RFC 5555 [2]. Otherwise the UE shall send IPv6 and IPv4 packets encapsulated in IPv4 as specified in IETF RFC 5555 [2].

Once the DSMIPv6 tunnel is established, the UE may build a DHCPv4 or DHCPv6 message as described in IETF RFC 4039 [26] or IETF RFC 3736 [13] respectively and send it via the DSMIPv6 tunnel as described in IETF RFC 3775 [6] in order to retrieve additional parameters, e.g. Vendor-specific options.

From TS 24.303 clause 5.2.2.3

If the access network supports IPv6, as soon as the UE has received via a Router Advertisement at least an IPv6 prefix which is not present in its Prefix List, the UE shall perform the Home Link detection as specified in subclause 5.1.2.3.

If the UE detects it is not attached to the home link, the UE shall send a Binding Update to the HA including the newly configured IP address as the Care-of Address in the Source IP address of the packet and optionally in the Alternate Care-of Address Option [6]. The UE build the Binding Update message as specified in IETF RFC 3775 [6].

If the UE has been assigned also an IPv4 Home Address and wants to update also the binding for it, the UE shall include the IPv4 Home Address option including the assigned IPv4 Home Address in the same Binding Update message.

If the UE has been assigned also an IPv4 Home Address and wants to release it, the UE shall not include any IPv4 Home Address option in the same Binding Update.

If the UE does not have an IPv4 Home Address but wants to configure one, the UE shall include the IPv4 Home Address option with the 0.0.0.0 address as specified in subclause 5.1.2.4.

If the access network supports only IPv4, as soon as the UE has configured an IPv4 Care-of Address which is different from the previous Care-of Address, the UE shall send a Binding Update tunnelled in UDP as specified in IETF RFC 5555 [2]. The UE shall set the F flag to "0". The UE shall set the R flag to "1".

Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the Binding Update message.

Reference(s)

3GPP TS 24.327 clause 5.1.2.5

3GPP TS 24.303 clauses 5.1.2.3, 5.1.2.4 and 5.2.2.3

17.3.5.3 Test purpose

To verify that when the UE has established a security association with the Home Agent and received the IPv6 Home Address, upon detecting that it is not on the Home Link, it transmits a Binding Update message in order to register it Home Address and Care-of-Address at the Home Agent.

17.3.5.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE’s Prefix List has been cleared.

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 17.3.4 with the following exception: the IPv6 home prefix assigned to the UE by the SS shall be the same as the prefix used during IP address acquisition by the UE.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS broadcasts a Router Advertisement with a Prefix Information Option containing an IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble.

b) The UE transmits a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP destination Address field of the IP header.

c) The SS transmits a Binding Acknowledgement accepting the Binding Update.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	ß		Router Advertisement	The Prefix Information Option in the Router Advertisement contains an IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble
2	à		Binding Update	Binding Update contains UE’s IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP destination Address field of the IP header
3	ß		Binding Acknowledgement	Binding Acknowledgement accepting the Binding Update

Specific Message Contents

Router Advertisement (Step 1)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element	Value/remark

Prefix	IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble

Binding Update (Step 2)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

IPv4 Home Address option

Alternate Care-of Address option

Optional: Set to the value "0.0.0.0" to request allocation for the UE. The "P" flag is set to ‘0’B.

The Prefix Length is set to the requested prefix length of ’32’.

Same IPv6 address as that inserted in the IP Source Address field

Binding Acknowledgement (Step 3)

Use the default message contents found in TS 34.108, clause 9.1.4.

17.3.5.5 Test requirements

At Step 2, UE shall send a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP destination Address field of the IP header.

17.3.6 Registration of a new IPv4 CoA (Binding Update/Acknowledgment procedure in IPv4 network)

17.3.6.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.6.2 Conformance requirement

From TS 24.327 clause 5.1.2.5

The UE may also request in the Binding Update an IPv4 home address based on the procedure specified in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.1.2.3

NOTE: The UE does not need to run IKEv2 for home link detection if the Home Network prefix is dynamically received in a PCO Information Element.

From TS 24.303 clause 5.1.2.4

If IPv4 Care-of Address is used for initial binding registration, the UE shall send the Binding Update as follows (see IETF RFC 5555 [2]):

– The IPv6 packet, with the IPv6 Home Address as the Source Address field of the IPv6 header, shall be encapsulated in UDP.

– The UE shall include the IPv4 Care-of Address as the Source Address field of the IPv4 header and the HA IPv4 address as the Destination Address field of the IPv4 header.

– The UE shall include the IPv4 Care-of Address option containing the IPv4 Care-of Address.

– The UE shall set the H (home registration) and A (acknowledge) flags.

– The UE shall set the F (UDP encapsulation required) flag to 0.

– The UE shall set the R (Mobile Router Flag) flag to 1.

– If the UE needs an IPv4 Home Address, the UE shall include an IPv4 Home Address option with the 0.0.0.0 address in the Binding Update message, as defined in IETF RFC 5555 [2].

NOTE: The value to be used to identify the IPv4 address acknowledgement option in the mobility header is 30;

From TS 24.303 clause 5.2.2.3

If the UE has been assigned also an IPv4 Home Address and wants to release it, the UE shall not include any IPv4 Home Address option in the same Binding Update.

If the UE does not have an IPv4 Home Address but wants to configure one, the UE shall include the IPv4 Home Address option with the 0.0.0.0 address as specified in subclause 5.1.2.4.

Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the Binding Update message.

Reference(s)

3GPP TS 24.327 clause 5.1.2.5

3GPP TS 24.303 clauses 5.1.2.3, 5.1.2.4 and 5.2.2.3

17.3.6.3 Test purpose

17.3.6.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE’s Prefix List has been cleared.

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 17.3.4.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The UE transmits a Binding Update with its IPv4 CoA in the IP Source Address field of the IP Header and the IPv4 Home Agent address in the IP destination Address field of the outer IP header.

b) The SS transmits a Binding Acknowledgement accepting the Binding Update.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	à		Binding Update	Binding Update contains UE’s IPv4 CoA in the IP Source Address field of the IP Header and the IPv4 Home Agent address in the IP destination Address field of the outer IP header
2	ß		Binding Acknowledgement	Binding Acknowledgement accepting the Binding Update

Specific Message Contents

Binding Update (Step1)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

IPv4 Home Address option

Alternate Care-of Address option

Optional: Set to the value "0.0.0.0" to request allocation for the UE. The "P" flag is set to ‘0’B.

The Prefix Length is set to the requested prefix length of ’32’.

Not present

Binding Acknowledgement (Step 2)

Use the default message contents found in TS 34.108, clause 9.1.4.

17.3.6.5 Test requirements

At Step 1, UE shall send a Binding Update with its IPv4 CoA in the IP Source Address field of the IP Header and the IPv4 Home Agent address in the IP destination Address field of the IP header.

17.3.7 Re-registration of IPv6 CoA

17.3.7.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.7.2 Conformance requirement

From TS 24.303 clause 5.3.2

As specified in IETF RFC 3775 [6], if the UE wants to extend the validity of an existing binding at the HA, the UE shall send a new Binding Update to the HA before the expiration of the lifetime indicated in the received Binding Acknowledgement, even if it is not changing its primary Care-of Address. This Binding Update is usually referred as periodic Binding Update.

The UE shall follow the rules described in IETF RC 3775 [6], IETF RFC 5555 [2] and in subclause 5.1.2.4 to send a periodic Binding Update and handle the associated Binding Acknowledgement. As the UE has not performed any handover, the UE shall confirm the already registered Care of Address and shall indicate the desired lifetime value. In a periodic Binding Update the UE may request an IPv4 Home Address.

Reference(s)

3GPP TS 24.303 clause 5.3.2

17.3.7.3 Test purpose

To verify that when the registration of the UE’s Care-of-Address is about to expire, the UE initiates the re-registration procedure to extend the lifetime of the registration of its Care-of-Address.

17.3.7.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE’s Prefix List has been cleared.

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a – c) The UE registers its IPv6 Home Address and IPv6 Care-of-Address at the Home Agent by performing steps a – c) defined in test case 17.3.5.

d) Within 10 min of Step c), the UE transmits a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP Destination Address field of the IP header.

e) The SS transmits a Binding Acknowledgement accepting the Binding Update.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1-3			Steps defined in test case 17.3.5	The same messages as in test case 17.3.5 Steps 1-3 are used.
4	à		Binding Update	Binding Update contains UE’s IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP Destination Address field of the IP header. Message shall be sent within 10 min of Step 3.
5	ß		Binding Acknowledgement	Binding Acknowledgement accepting the Binding Update

Specific Message Contents

Binding Update (Step 4)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

IPv4 Home Address option

Alternate Care-of Address option

Optional: If an IPv4 Home Address was included in the Binding Acknowledgement sent by the SS at Step 3, field should be set to this IPv4 Home Address.

Else, set to the value "0.0.0.0" to request allocation for the UE. The "P" flag is set to ‘0’.

The Prefix Length is set to the requested prefix length of ’32’.

Same IPv6 address as that inserted in the IP Source Address field

Binding Acknowledgement (Step 5)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element	Value/remark
P	Not present

17.3.7.5 Test requirements

Within 10 min of Step 3, UE shall send a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP Destination Address field of the IP header.

17.3.8 Re-registration of Ipv4 CoA

17.3.8.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.8.2 Conformance requirement

From TS 24.303 clause 5.3.2

Reference(s)

3GPP TS 24.303 clause 5.3.2

17.3.8.3 Test purpose

17.3.8.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE’s Prefix List has been cleared.

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 17.3.4.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a – b) The UE registers its IPv6 Home Address and IPv4 Care-of-Address at the Home Agent by performing steps a –b) defined in test case 17.3.6.

c) Within 10 min of Step b), the UE transmits a Binding Update with its IPv4 CoA in the IP Source Address field of the outer IP Header and the IPv4 Home Agent address in the IP Destination Address field of the outer IP header.

d) The SS transmits a Binding Acknowledgement accepting the Binding Update.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1-2			Steps defined in test case 17.3.6	The same messages as in test case 17.3.6 Steps 1-2 are used.
3	à		Binding Update	Binding Update contains UE’s IPv4 CoA in the IP Source Address field of the outer IP Header and the IPv4 Home Agent address in the IP Destination Address field of the outer IP header. Message shall be sent within 10 min of Step 2.
4	ß		Binding Acknowledgement	Binding Acknowledgement accepting the Binding Update

Specific Message Contents

Binding Update (Step 3)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

IPv4 Home Address option

Alternate Care-of Address option

Optional: If an IPv4 Home Address was included in the Binding Acknowledgement sent by the SS at Step 2, field should be set to this IPv4 Home Address.

Else, set to the value "0.0.0.0" to request allocation for the UE. The "P" flag is set to ‘0’.

The Prefix Length is set to the requested prefix length of ’32’.

Not present

Binding Acknowledgement (Step 4)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element	Value/remark
P	Not present

17.3.8.5 Test requirements

Within 10 min of Step 2, UE shall send a Binding Update with its IPv4 CoA in the IP Source Address field of the outer IP Header and the IPv4 Home Agent address in the IP Destination Address field of the outer IP header.

17.3.9 Return to home link

17.3.9.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.9.2 Conformance requirement

From TS 24.327 clause 5.2.2.1

When the UE is connected to the GPRS systems and wants to move to 3GPP I-WLAN, the UE shall initiate the tunnel establishment procedure towards the PDG as described in 3GPP TS 24.234 [5] and shall then perform the home link detection as described in subclause 5.1.2.4:

…

– If the UE is on the home link, the UE shall send a Binding Update with lifetime set to 0 to remove the binding at the HA as specified in 3GPP TS 24.303 [3].

From TS 24.327 clause 5.2.3.1

Once the UE is attached to the GPRS system and after performing the PDP context activation procedure, it will receive a new PDP address as a Care-of-Address. The UE shall then perform the home link detection procedure as specified in subclause 5.1.2.4:

….

– If the UE is on the home link, the UE shall send a Binding Update with lifetime set to 0 to remove the binding at the HA as specified in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.2.2.4

If the access network supports IPv6, as soon as the UE has received via a Router Advertisement message at least an IPv6 prefix which is not present in its Prefix List, the UE shall perform the Home Link detection as specified in subclause 5.1.2.3 to detect if the UE is attaching to the home link. If the UE detects it is attached to the home link and there is a valid DSMIPv6 Binding Update list entry at the UE, the UE shall send a Binding Update with the Lifetime field set to "0" in order to remove the binding at the HA, as specified in IETF RFC 3775 [6]. If an IPv4 home address was assigned to the UE, as an optimization the UE may not include the IPv4 home address option as the binding for the IPv4 home address will be removed by the HA. Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the de-registration Binding Update message. The UE may preserve the IKEv2 session in order to avoid re-establishing the session when the next handover occurs. If there is not a safe assumption that the UE will remain in the home link (e.g. switching off the non-3GPP radio interface in case of a dual radio terminal), the UE should preserve the IKEv2 session.

Reference(s)

3GPP TS 24.327 clauses 5.2.2.1 and 5.2.3.1

3GPP TS 24.303 clause 5.2.2.4

17.3.9.3 Test purpose

To verify that when the UE detects it is attached to the home link, it transmits a Binding Update message with the lifetime field set to “0”.

17.3.9.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv6 address) at the Home Agent, by executing the steps in test case 17.3.5.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS broadcasts a Router Advertisement with a Prefix Information Option containing an IPv6 prefix matching the Home Network Prefix assigned to the UE during the preamble.

b) The UE transmits a Binding Update message with the lifetime field set to “0”.

c) The SS transmits a Binding Acknowledgement accepting the Binding Update with the lifetime field set to “0”.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	ß		Router Advertisement	The Prefix Information Option in the Router Advertisement contains an IPv6 prefix matching the Home Network Prefix assigned to the UE during the preamble
2	à		Binding Update	Lifetime field is set to “0”
3	ß		Binding Acknowledgement	Binding Acknowledgement accepting the Binding Update with the lifetime field set to “0”

Specific Message Contents

Router Advertisement (Step 1)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element	Value/remark

Prefix	IPv6 prefix equal to Home Network Prefix assigned to the UE during preamble

Binding Update (Step 2)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

Lifetime

IPv4 Home Address option

Alternate Care-of Address option

‘0000000000000000’B

Not present

Binding Acknowledgement (Step 3)

Use the default message contents found in TS 34.108, clause 9.1.4, with the following exceptions:

Information Element

Value/remark

Lifetime

IPv4 Address Acknowledgement option

Binding Refresh Advice option

‘0000000000000000’B

Not present

17.3.9.5 Test requirements

At Step 2, UE shall send a Binding Update message with the lifetime field set to “0”.

17.3.10 Security association establishment

17.3.10.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.10.2 Conformance requirement

Reference(s)

3GPP TS 24.327 clause 5.4.1

UE and HA may create a child security association using the IKEv2 session established as described in subclause 5.1.2.3. This child security association is used to cipher or integrity protect, or both, all data traffic exchanged within the DSMIPv6 tunnel. The profiles for tunnel mode IPsec ESP are defined in 3GPP TS 33.234 [19]. The procedure is initiated by the HA and may be initiated at any time after the security association between UE and HA has been set up. The support of this procedure is optional for both the HA and the UE.

3GPP TS 24.327 clause 5.4.2

When the UE receives a CREATE_CHILD_SA request from the HA with selectors indicating the DSMIPv6 tunnel traffic, the UE should reply with a CREATE_CHILD_SA response selecting the preferred transform proposed by the HA as specified in IETF RFC 4306 [9].

If the child SA is created successfully, the UE shall start ciphering or integrity protecting, or both, all the uplink packets in the DSMIPv6 tunnel as negotiated with the HA during the CREATE_CHILD_SA procedure.

The UE may stop ciphering or integrity protecting, or both, the DSMIPv6 tunnel traffic. In order to do that, the UE shall delete the respective child security association by sending an INFORMATIONAL request message including the DELETE payload as specified in IETF RFC 4306 [9]. The protocol ID shall be set to 3 in order to indicate that only the ESP SA shall be removed.

3GPP TS 24.327 clause 5.4.3

After establishing the IPsec security association with the UE as described in subclause 5.1.3.3, the HA may optionally trigger the creation of a child security association to protect the traffic send via the DSMIPv6 tunnel.

In order to activate the protection of DSMIPv6 tunnel traffic, the HA shall initiate the creation of a child security association sending a CREATE_CHILD_SA request message to the UE. In the CREATE_CHILD_SA message the HA shall request for an ESP security association; the HA shall also set the SA payload depending if integrity protection or ciphering, or both, are needed as described in IETF RFC 4306 [9]. The traffic selectors shall be set as described in subclause 5.2.4 of IETF RFC 3776 [11].

If the child security association is created successfully, the HA shall start ciphering or integrity protecting, or both, all the downlink packets in the DSMIPv6 tunnel as negotiated with the UE during the CREATE_CHILD_SA procedure.

At any time the HA may stop ciphering or integrity protecting, or both, the DSMIPv6 tunnel traffic. In order to do that, the HA shall delete the respective child security association by sending an INFORMATIONAL request message including the DELETE payload as specified in IETF RFC 4306 [9]. The protocol ID shall be set to 3 in order to indicate that only the ESP SA shall be removed.

17.3.10.3 Test purpose

To verify that when the HA sets up a Child SA by sending a CREATE_CHILD_SA Request the UE replies with a CREATE_CHILD_SA Response.

17.3.10.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

– The UE has discovered the IP address of the Home Agent (either via DNS, IKEv2 signalling or during PDP context activation procedure).

– The UE has set up a Security Association with the Home Agent

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS transmits a CREATE_CHILD_SA Request message including traffic selectors fields (TSi and TSr) that contain the parameters identifying the data traffic to be encrypted.

b) The UE transmits a CREATE_CHILD_SA Response message.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	à		CREATE_CHILD_SA Request	CREATE_CHILD_SA Request message includes traffic selectors fields (TSi and TSr) that contain the parameters identifying the data traffic to be encrypted
2	ß		CREATE_CHILD_SA Response

Specific Message Contents

CREATE_CHILD_SA Request (Step 1)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the SS in IKE_SA exchange
Responder’s IKE_SA SPI	Same as that set by the UE in IKE_SA exchange
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100100’B (CREATE_CHILD_SA)
Encrypted Payload
Next Payload Initialization Vector	‘00100001’B (SA) Random value set by the UE
Encrypted IKE Payloads Security Association Payload Next Payload More proposal Proposal # Protocol ID SPI size Number of transforms SPI More transform Transform type Transform ID Last transform Transform type Transform ID Last proposal Proposal # Protocol ID SPI size Number of transforms SPI More transform Transform type Transform ID Last transform Transform type Transform ID Nonce Payload Next Payload Nonce data Traffic Selector – Initiator Payload Next Payload Number of traffic selectors TS type Starting address Ending address Traffic Selector – Responder Payload Next Payload Traffic Selector data Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Padding Pad Length Integrity checksum data	‘00101000’B (Ni) ‘00000010’B ‘00000001’B (First cryptographic suite) ‘00000011’B ‘00000100’B ‘00000010’B Set by the SS ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00000011’B (3DES in CBC mode) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000010’B (HMAC-SHA1-96) ‘00000000’B ‘00000010’B (Second cryptographic suite) ‘00000011’B (ESP) ‘00000100’B ‘00000010’B Set by the SS ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) ‘00001011’B (AES with 128-bit keys in CBC mode) ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) ‘00000101’B (AES-XCBC-MAC-96) ‘00101100’B (TSi) Random number set by the SS ‘00101101’B (TSr) ‘00000001’B ‘00001000’B (IPv6 range) HoA address derived from HNP HoA address derived from HNP ‘00101001’B (Notify – Use transport mode) Any value ‘00101001’B (Notify – Use tunnel mode) ‘00000011’B (ESP) ‘00000100’B ‘1000000000000111’B (Use tunnel mode) Same as that set by the SS in SA proposal #1 ‘00000000’B (SPI field not present) ‘00000000’B (No Next Payload) ‘00000011’B (ESP) ‘00000100’B ‘1000000000000111’B (Use transport mode) Set by the SS Set by the SS Set by the SS Set by the SS

CREATE_CHILD_SA Response (Step 2)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA exchange
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA exchange
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100100’B (CREATE_CHILD_SA)
Encrypted Payload
Next Payload Initialization Vector	‘00100001’B (SA) Set by the SS
Encrypted IKE Payloads Security Association Payload Next Payload Last proposal Proposal # Protocol ID SPI size SPI First transform Transform type Transform attribute type Last transform Transform type Transform attribute type Nonce Payload Next Payload Nonce data Traffic Selector – Initiator Payload Next Payload Traffic Selector – Responder Payload Next Payload Use transport mode Notify Payload Next Payload Protocol ID SPI size Notify Message Type SPI Padding Pad Length Integrity checksum data	‘00101000’B (Nr) ‘00000000’B One of the 2 proposals included in the CREATE_CHILD_SA Request at Step 1 ‘00000011’B (ESP) ‘00000100’B Set by the UE ‘00000011’B (This is the transform for confidentiality) ‘00000001’B (Encryption) The corresponding value of the chosen proposal ‘00000011’B (This is the transform for integrity) ‘00000011’B (Integrity) The corresponding value of the chosen proposal ‘00101100’B (TSi) Set by the SS ‘00101101’B (TSr) ‘00101001’B (Notify – Use transport mode) ‘00000000’B (No Next Payload) ‘00000011’B (ESP) Set by the UE ‘1000000000000111’B (Use transport mode) Set by the UE Set by the UE Set by the UE Set by the UE

17.3.10.5 Test requirements

At Step 2, UE shall send a CREATE_CHILD_SA response addressed to the Home Agent to initiate data traffic tunnelling.

17.3.11 Termination of protection of DSMIPv6 tunnel traffic by Home Agent

17.3.11.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.11.2 Conformance requirement

From TS 24.327 clause 5.4.1

From TS 24.327 clause 5.4.2

From TS 24.327 clause 5.4.3

Reference(s)

3GPP TS 24.327 clauses 5.4.1, 5.4.2 and 5.4.3

17.3.11.3 Test purpose

To verify that when the Home Agent terminates the previously set up Child SA by sending an INFORMATIONAL Request, the UE replies with an INFORMATIONAL Response.

17.3.11.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IP address.

– The UE has discovered the IP address of the Home Agent (either via DNS, IKEv2 signalling or during PDP context activation procedure).

– The UE has set up a Security Association with the Home Agent.

– The Home Agent has set up a child Security Association to protect data traffic.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS transmits an INFORMATIONAL Request message including a DELETE payload with the SPI value of the security association set up during preamble to protect data traffic.

b) The UE transmits an INFORMATIONAL Response message including a DELETE payload with the SPI value of the security association set up during preamble to protect data traffic..

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	ß		INFORMATIONAL Request	INFORMATIONAL Request message includes a DELETE payload indicating the SPIs of the CHILD_SA to be removed
2	à		INFORMATIONAL Response

Specific Message Contents

INFORMATIONAL Request (Step 1)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the SS in IKE_SA exchange
Responder’s IKE_SA SPI	Same as that set by the UE in IKE_SA exchange
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100101’B (INFORMATIONAL)
Encrypted Payload
Next Payload	‘00101010’B (DELETE payload)
Encrypted IKE Payloads Delete Payload Next Payload Protocol ID SPI size SPI Padding Pad Length Integrity checksum data	‘00000000’B (No Next Payload) ‘00000011’B (ESP) ‘00000100’B Same as the one set by SS when creating the CHILD_SA Set by the SS Set by the SS Set by the SS

INFORMATIONAL Response (Step 2)

Information Element	Value/remark
IKE Header
Initiator’s IKE_SA SPI	Same as that set by the UE in IKE_SA exchange
Responder’s IKE_SA SPI	Same as that set by the SS in IKE_SA exchange
Next Payload	‘00101110’B (E)
Exchange Type	‘00 100101’B (INFORMATIONAL)
Encrypted Payload
Next Payload	‘00101010’B (DELETE payload)
Encrypted IKE Payloads Delete Payload Next Payload Protocol ID SPI size SPI Padding Pad Length Integrity checksum data	‘00000000’B (No Next Payload) ‘00000011’B (ESP) ‘00000100’B Same as the one set by UE when creating the CHILD_SA Set by the UE Set by the UE Set by the UE

17.3.11.5 Test requirements

At Step 2, the UE shall send an INFORMATIONAL response addressed to the Home Agent to stop data traffic encryption.

17.3.12 Dual-Stack Mobile IPv6 detach in IPv6 network

17.3.12.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.12.2 Conformance requirement

From TS 24.327 clause 5.3.2.1

The network-initiated detach is based on the usage of the Binding Revocation Indication (BRI) message. When the UE receives a BRI, it shall proceed as described in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.4.2.1

Upon receiving a Binding Revocation Indication (BRI) message according to draft-ietf-mext-binding-revocation [19] from the HA, the UE first shall perform the required validity checks on the BRI according to draft-ietf-mext-binding-revocation [19].

The UE shall send a Binding Revocation Acknowledgement (BRA) as specified in draft-ietf-mext-binding-revocation [19]. In this message the UE shall set the status field to ‘Success’ to reflect that it has received the BRI message. The BRA message may be tunnelled in UDP or IPv4 as specified in subclause 5.1.2.4 for Binding Update messages.

The UE then shall remove the entry identified in the BRI as deregistered from its binding update list and shall use the procedures defined in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration as described in subclause 5.4.2.2.

From TS 24.303 clause 5.4.2.2

To detach from a specific PDN to which it is connected through a DSMIPv6 session, the UE shall send a Binding Update with the Lifetime field set to 0 as specified in IETF RFC 3775 [6].

The UE shall use the procedures defined in the IKEv2 protocol in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration. The UE shall close the security associations associated with the DSMIPv6 registration and instruct the HA to do the same by sending the INFORMATIONAL request message including a DELETE payload. The Protocol ID in the DELETE payload shall be set to "1" (IKE) to indicate that all IPsec ESP security associations that were negotiated within the IKEv2 exchange shall be deleted.

Reference(s)

3GPP TS 24.327 clause 5.3.2.1

3GPP TS 24.303 clauses 5.4.2.1 and 5.4.2.2

17.3.12.3 Test purpose

To verify that when the UE receives a Binding Revocation Indication message from the HA, it transmits a Binding Revocation Acknowledgement message with the status field set to ‘Success’, and removes the IPsec security associations associated with the DSMIPv6 registration.

17.3.12.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IPv6 address.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv6 address) at the Home Agent, by executing the steps in test case 17.3.5.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS transmits a Binding Revocation Indication message to the UE.

b) The UE transmits a Binding Revocation Acknowledgement message with the status field set to ‘Success’.

c) The UE transmits an IKEv2 INFORMATIONAL message containing a DELETE payload.

d) The SS transmits an IKEv2 INFORMATIONAL message containing a DELETE payload back to the UE.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	ß		Binding Revocation Indication
2	à		Binding Revocation Acknowledgement	Status field is set to ‘Success’
3	à		IKEv2 INFORMATIONAL	Message contains a DELETE payload
4	ß		IKEv2 INFORMATIONAL	Message contains a DELETE payload

Specific Message Contents

Binding Revocation Indication (Step 1)

Use the default message contents found in TS 34.108, clause 9.1.4.

Binding Revocation Acknowledgement (Step 2)

Use the default message contents found in TS 34.108, clause 9.1.4.

IKEv2 INFORMATIONAL (Step 3)

Information Element

Value/remark

IKE Header

Initiator’s IKE_SA SPI
Responder’s IKE_SA SPI
Next Payload
Exchange Type

Encrypted Payload

Next Payload

Delete Payload

Next Payload
Protocol ID

Padding

Pad Length

Integrity checksum data

The one identifying the UE in the SA set up during the preamble

The one identifying the HA in the SA set up during the preamble

‘00101110’B (E)

‘00100101’B (INFORMATIONAL)

‘00101010’B (DELETE)

‘00000000’B (No Next Payload)

‘00000001’B (IKE_SA)

Set by the UE

IKEv2 INFORMATIONAL (Step 4)

Information Element

Value/remark

IKE Header

Initiator’s IKE_SA SPI
Responder’s IKE_SA SPI
Next Payload
Exchange Type

Encrypted Payload

Next Payload

Delete Payload

Next Payload
Protocol ID

Padding

Pad Length

Integrity checksum data

Same as that set by the UE at Step 3

Same as that set by the SS at Step 3

‘00101110’B (E)

‘00100101’B (INFORMATIONAL)

‘00101010’B (DELETE)

‘00000000’B (No Next Payload)

‘00000001’B (IKE_SA)

Set by the SS

17.3.12.5 Test requirements

At Step 2, UE shall send a Binding Revocation Acknowledgement message with the status field set to ‘Success’.
At Step 3, UE shall send an IKEv2 INFORMATIONAL message containing a DELETE payload.

17.3.13 Dual-Stack Mobile IPv6 detach in IPv4 network

17.3.13.1 Definition and applicability

This test case is applicable for all UEs which support mobility between 3GPP WLAN Interworking and 3GPP Systems.

17.3.13.2 Conformance requirement

From TS 24.327 clause 5.3.2.1

The network-initiated detach is based on the usage of the Binding Revocation Indication (BRI) message. When the UE receives a BRI, it shall proceed as described in 3GPP TS 24.303 [3].

From TS 24.303 clause 5.4.2.1

From TS 24.303 clause 5.4.2.2

Reference(s)

3GPP TS 24.327 clause 5.3.2.1

3GPP TS 24.303 clauses 5.4.2.1 and 5.4.2.2

17.3.13.3 Test purpose

17.3.13.4 Method of test

Initial Conditions

– System simulator:

– 1 cell, default parameters.

– User Equipment:

– The UE shall be in MM-state "Idle, updated".

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 17.3.4.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv4 address) at the Home Agent, by executing the steps in test case 17.3.6.

Related ICS/IXIT Statements

Support of mobility between 3GPP WLAN Interworking and 3GPP Systems

Test procedure

a) The SS transmits a Binding Revocation Indication message with the A flag set to the UE.

b) The UE transmits a Binding Revocation Acknowledgement message with the status field set to ‘Success’.

c) The UE transmits an IKEv2 INFORMATIONAL message containing a DELETE payload.

d) The SS transmits an IKEv2 INFORMATIONAL message containing a DELETE payload back to the UE.

Expected sequence

Step	Direction		Message	Comments
	UE	SS
1	ß		Binding Revocation Indication	A flag is set
2	à		Binding Revocation Acknowledgement	Status field is set to ‘Success’
3	à		IKEv2 INFORMATIONAL	Message contains a DELETE payload
4	ß		IKEv2 INFORMATIONAL	Message contains a DELETE payload

Specific Message Contents

Binding Revocation Indication (Step 1)

Use the default message contents found in TS 34.108, clause 9.1.4.

Binding Revocation Acknowledgement (Step 2)

Use the default message contents found in TS 34.108, clause 9.1.4.

IKEv2 INFORMATIONAL (Step 3)

Information Element

Value/remark

IKE Header

Initiator’s IKE_SA SPI
Responder’s IKE_SA SPI
Next Payload
Exchange Type

Encrypted Payload

Next Payload

Delete Payload

Next Payload
Protocol ID

Padding

Pad Length

Integrity checksum data

The one identifying the UE in the SA set up during the preamble

The one identifying the HA in the SA set up during the preamble

‘00101110’B (E)

‘00100101’B (INFORMATIONAL)

‘00101010’B (DELETE)

‘00000000’B (No Next Payload)

‘00000001’B (IKE_SA)

Set by the UE

IKEv2 INFORMATIONAL (Step 4)

Information Element

Value/remark

IKE Header

Initiator’s IKE_SA SPI
Responder’s IKE_SA SPI
Next Payload
Exchange Type

Encrypted Payload

Next Payload

Delete Payload

Next Payload
Protocol ID

Padding

Pad Length

Integrity checksum data

Same as that set by the UE at Step 3

Same as that set by the SS at Step 3

‘00101110’B (E)

‘00100101’B (INFORMATIONAL)

‘00101010’B (DELETE)

‘00000000’B (No Next Payload)

‘00000001’B (IKE_SA)

Set by the SS

17.3.13.5 Test requirements

At Step 2, UE shall send a Binding Revocation Acknowledgement message with the status field set to ‘Success’.
At Step 3, UE shall send an IKEv2 INFORMATIONAL message containing a DELETE payload.