13.4.2 Inter-system mobility packet

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

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

13.4.2.1 Inter-system mobility / E-UTRA to UTRA packet

13.4.2.1.1 Test Purpose (TP)

(1)

with { UE has a default EPS bearer context }

ensure that {

when { UE receives downlink data on the radio bearer associated with the default EPS bearer context }

then { UE delivers the downlink data to upper layers }

}

(2)

with { UE has a default EPS bearer context }

ensure that {

when { uplink data are submitted for transmission }

then { UE transmits the uplink data on the radio bearer associated with the default EPS bearer context }

}

(3)

with { UE has a radio access bearer context and successful completion of the inter-system handover }

ensure that {

when { UE receives downlink data on the radio bearer associated with the radio access bearer context }

then { UE delivers the downlink data to upper layers }

}

(4)

with { UE has a radio access bearer context and successful completion of the inter-system handover }

ensure that {

when { uplink data are submitted for transmission }

then { UE transmits the uplink data on the radio bearer associated with the radio access bearer context }

}

13.4.2.1.2 Conformance requirements

References: The conformance requirements covered in the current TC are those listed in TC 8.4.1.2, plus those specified in: TS 23.401, clauses 5.5.2.1.2, 5.5.2.1.3.

[TS 23.401, clause 5.5.2.1.2]

Figure 5.5.2.1.2-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, preparation phase

1. The source eNodeB decides to initiate an Inter-RAT handover to the target access network, UTRAN Iu mode. At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and source eNodeB, GTP tunnel(s) between source eNodeB, Serving GW and PDN GW.

NOTE 1: The process leading to the handover decision is outside of the scope of this specification.

2. The source eNodeB sends a Handover Required (S1AP Cause, Target RNC Identifier, Source eNodeB Identifier, Source to Target Transparent Container) message to the source MME to request the CN to establish resources in the target RNC, target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see step 7 below).

3. The source MME determines from the ‘Target RNC Identifier’ IE that the type of handover is IRAT Handover to UTRAN Iu mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification, MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to Target Transparent Container, RAN Cause, MS Info Change Reporting Action (if available), ISR Supported, TI(s)) message to the target SGSN. The information ISR Supported is indicated if the source MME is capable to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. This message includes all PDN Connections active in the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts. RAN Cause indicates the S1AP Cause as received from source eNodeB.

The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of an EPS bearer to the pre-Rel-8 QoS parameter values of a bearer context as defined in Annex E

Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.

The MM context contains security related information, e.g. supported ciphering algorithms as described in TS 29.274 [43]. Handling of security keys is described in TS 33.401 [41].

The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer context in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value.

4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8) per PDN connection to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.

The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates the EPS Bearer contexts which cannot be established.

4a. The target Serving GW allocates its local resources and returns a Create Session Response (Serving GW address(es) for user plane, Serving GW UL TEID(s) for user plane, Serving GW Address for control plane, Serving GW TEID for control plane) message to the target SGSN.

5. The target SGSN requests the target RNC to establish the radio network resources (RABs) by sending the message Relocation Request (UE Identifier, Cause, CN Domain Indicator, Integrity protection information (i.e. IK and allowed Integrity Protection algorithms), Encryption information (i.e. CK and allowed Ciphering algorithms), RAB to be setup list, Source RNC to Target RNC Transparent Container, Service Handover related information). If the Access Restriction is present in the MM context, the Service Handover related information shall be included by the target SGSN for the Relocation Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction.

For each RAB requested to be established, RABs To Be Setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the Serving GW Address for user plane (if Direct Tunnel is used) or the SGSN Address for user plane (if Direct Tunnel is not used), and the Iu Transport Association corresponds to the uplink Tunnel Endpoint Identifier Data in Serving GW or SGSN respectively.

Ciphering and integrity protection keys are sent to the target RNC to allow data transfer to continue in the new RAT/mode target cell without requiring a new AKA (Authentication and Key Agreement) procedure. Information that is required to be sent to the UE (either in the Relocation Command message or after the handover completion message) from RRC in the target RNC shall be included in the RRC message sent from the target RNC to the UE via the transparent container. More details are described in TS 33.401 [41].

In the target RNC radio and Iu user plane resources are reserved for the accepted RABs. Cause indicates the RAN Cause as received from source MME. The Source RNC to Target RNC Transparent Container includes the value from the Source to Target Transparent Container received from the source eNodeB.

5a. The target RNC allocates the resources and returns the applicable parameters to the target SGSN in the message Relocation Request Acknowledge (Target RNC to Source RNC Transparent Container, RABs setup list, RABs failed to setup list).

Upon sending the Relocation Request Acknowledge message the target RNC shall be prepared to receive downlink GTP PDUs from the Serving GW, or Target SGSN if Direct Tunnel is not used, for the accepted RABs.

Each RAB in the RABs setup list is defined by a Transport Layer Address, which is the target RNC Address for user data, and the Iu Transport Association, which corresponds to the downlink Tunnel Endpoint Identifier for user data.

Any EPS Bearer contexts for which a RAB was not established are maintained in the target SGSN and the UE. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.

6. If ‘Indirect Forwarding’ and relocation of Serving GW apply and Direct Tunnel is used, the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target RNC Address and TEID(s) for data forwarding) to the Serving GW. If ‘Indirect Forwarding’ and relocation of Serving GW apply and Direct Tunnel is not used, then the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (SGSN Address and TEID(s) for data forwarding) to the Serving GW.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for data forwarding) message to the target SGSN.

7. The target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, Cause, RAB Setup Information, Additional RAB Setup Information, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to the source MME. Serving GW change indication indicates a new Serving GW has been selected. The Target to Source Transparent Container contains the value from the Target RNC to Source RNC Transparent Container received from the target RNC.

The IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ defines the destination tunnelling endpoint for data forwarding in target system, and it is set as follows:

– If ‘Direct Forwarding’ applies, or if ‘Indirect Forwarding’ and no relocation of Serving GW apply and Direct Tunnel is used, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the addresses and GTP-U tunnel endpoint parameters to the Target RNC received in step 5a.

– If ‘Indirect Forwarding’ and relocation of Serving GW apply, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the addresses and GTP-U tunnel endpoint parameters to the Serving GW received in step 6a. This is independent from using Direct Tunnel or not.

– If ‘Indirect Forwarding’ applies and Direct Tunnel is not used and relocation of Serving GW does not apply, then the IE ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the addresses and GTP-U tunnel endpoint parameters to the Target SGSN.

8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)), EPS Bearer ID(s)) to the Serving GW used for indirect forwarding.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.

8a. The Serving GW returns the forwarding parameters by sending the message Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn’t support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not be included in the message.

[TS 23.401, clause 5.5.2.1.3]

Figure 5.5.2.1.3-1: E-UTRAN to UTRAN Iu mode Inter RAT HO, execution phase

NOTE: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF interaction in the case of PMIP-based S5/S8. Steps 8 and 8a concern GTP based S5/S8

The source eNodeB continues to receive downlink and uplink user plane PDUs.

1. The source MME completes the preparation phase towards source eNodeB by sending the message Handover Command (Target to Source Transparent Container, E-RABs to Release List, Bearers Subject to Data Forwarding List). The "Bearers Subject to Data forwarding list" IE may be included in the message and it shall be a list of ‘Address(es) and TEID(s) for user traffic data forwarding’ received from target side in the preparation phase (Step 7 of the preparation phase) when ‘Direct Forwarding’ applies, or the parameters received in Step 8a of the preparation phase when ‘Indirect Forwarding’ applies.

The source eNodeB initiates data forwarding for bearers specified in the "Bearers Subject to Data Forwarding List". The data forwarding may go directly to target RNC or alternatively go via the Serving GW if so decided by source MME and or/ target SGSN in the preparation phase.

2. The source eNodeB will give a command to the UE to handover to the target access network via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the target RNC has set-up in the preparation phase. The details of this E-UTRAN specific signalling are described in TS 36.300 [5].

Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective RABs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.

3. Void.

4. The UE moves to the target UTRAN Iu (3G) system and executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 and 8 in clause 5.2.2.2 in TS 43.129 [8] with the additional function of association of the received RABs and existing Bearer Id related to the particular NSAPI.

The UE may resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target RNC.

The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer context activated after the ISR was activated in the UE exists.

13.4.2.1.3 Test description

13.4.2.1.3.1 Pre-test conditions

System Simulator:

Cell 1 and Cell 5
System information combination 4 as defined in TS 36.508 [18] clause 4.4.3.1 is used in E-UTRA cells.

UE:

None.

Preamble:

– The UE is in state Generic RB Established (state 4) on Cell 1 according to [18] using the UE TEST LOOP MODE B.

13.4.2.1.3.2 Test procedure sequence

Table 13.4.2.1.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. Row marked "T0" denotes the initial conditions after preamble, while columns marked "T1" is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.1.3.2-1: Time instances of cell power level and parameter changes

	Parameter	Unit	Cell 1	Cell 5	Remark
T0	Cell-specific RS EPRE	dBm/15kHz	-85	–	The power level values are such that entering conditions for event B2 are not satisfied.
	CPICH_Ec (UTRA FDD)	dBm/3.84 MHz	–	-82
	PCCPCH_Ec (UTRA LCR TDD)	dBm/1.28 MHz	–	-82
T1	Cell-specific RS EPRE	dBm/15kHz	-100	–	The power level values are such that entering conditions for event B2 are satisfied.
	CPICH_Ec (UTRA FDD)	dBm/3.84 MHz	–	-72
	PCCPCH_Ec (UTRA LCR TDD)	dBm/1.28 MHz	–	-72

Table 13.4.2.1.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message	–	–
1	The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context on Cell 1.	<–	IP packet	–	–
2	Check: Does the UE loop back the IP packet on the DRB associated with the default EPS bearer context on Cell 1?	–>	IP packet	1,2	P
3	The SS transmits an RRCConnectionReconfiguration message on Cell 1 to setup inter RAT measurement and reporting for event B2.	<–	RRCConnectionReconfiguration	–	–
4	The UE transmits an RRCConnectionReconfigurationComplete message on Cell 1.	–>	RRCConnectionReconfigurationComplete	–	–
5	The SS changes the power level for Cell 1 and Cell 5 according to the row "T1" in table 13.4.2.1.3.2-1	–	–	–	–
6	The UE transmits a MeasurementReport message on Cell 1 to report event B2 for Cell 5.	–>	MeasurementReport	–	–
6A	The SS transmits a UECapabilityEnquiry message to request UE radio access capability information for E-UTRA and UTRA.	<–	UECapabilityEnquiry	–	–
6B	The UE transmits a UECapabilityInformation message on Cell 1. NOTE: The start-PS values received, should be used to configure ciphering on cell 5.	–>	UECapabilityInformation	–	–
7	The SS transmits an MobilityFromEUTRACommand message on Cell 1 to order the UE to perform inter system handover to Cell 5.	<–	MobilityFromEUTRACommand	–	–
8	The UE transmits a HANDOVER TO UTRAN COMPLETE message on Cell 5 to confirm the successful completion of the inter system handover.	–>	HANDOVER TO UTRAN COMPLETE	–	–
–	EXCEPTION: The behaviour in table 13.4.2.1.3.2-3 may occur in parallel with steps 8A-8D.	–	–	–	–
8A	The SS transmits a SECURITY MODE COMMAND message on Cell 5 in order to activate integrity protection. Note: Ciphering has already been activated in steps 7/8	<–	SECURITY MODE COMMAND	–	–
8B	The UE transmits a SECURITY MODE COMPLETE message on Cell 5.	–>	SECURITY MODE COMPLETE	–	–
8C	The SS transmits a UTRAN MOBILITY INFORMATION message to notify CN information on Cell 5.	<–	UTRAN MOBILITY INFORMATION	–	–
8D	The UE transmits an UTRAN MOBILITY INFORMATION CONFIRM message on Cell 5.	–>	UTRAN MOBILITY INFORMATION CONFIRM	–	–
9-11	Void	–	–	–	–
12	The SS transmits a ROUTING AREA UPDATE ACCEPT message.	<–	ROUTING AREA UPDATE ACCEPT	–	–
13	The UE transmits a ROUTING AREA UPDATE COMPLETE message.	–>	ROUTING AREA UPDATE COMPLETE	–	–
14	The SS transmits one IP packet to the UE on the DRB associated with the RAB context on Cell 5.	<–	IP packet	–	–
15	Check: Does the UE loop back the IP packet on the DRB associated with the RAB context on Cell 5?	–>	IP packet	3,4	P

Table: 13.4.2.1.3.2-3: Parallel behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE transmits a ROUTING AREA UPDATE REQUEST message.	–>	ROUTING AREA UPDATE REQUEST	–	–

13.4.2.1.3.3 Specific message contents

Table 13.4.2.1.3.3-0: Conditions for specific message contents
in Table 13.4.2.1.3.3-3

Condition	Explanation
Band > 64	If band > 64 is selected

Table 13.4.2.1.3.3-1: ACTIVATE TEST MODE (preamble)

Derivation Path: 36.508, Table 4.7A-1, condition UE TEST LOOP MODE B

Table 13.4.2.1.3.3-2: RRCConnectionReconfiguration (step 3, Table 13.4.2.1.3.2-2)

Derivation Path: 36.508 clause 4.6.1 table 4.6.1-8 with condition MEAS

Table 13.4.2.1.3.3-3: MeasConfig (step 3, Table 13.4.2.1.3.2-2)

Derivation path: 36.508 clause 4.6.6 table 4.6.6-1 with condition UTRAN
Information Element	Value/Remark	Comment	Condition
measurementConfiguration ::= SEQUENCE {
measObjectToAddModifyList SEQUENCE (SIZE (1..maxObjectId)) OF SEQUENCE {	2 entries
measObjectId[1]	IdMeasObject-f1	Serving frequency
measObject[1]	MeasObjectEUTRA-GENERIC(f1)
measObject[1]	MeasObjectEUTRA-GENERIC(maxEARFCN)		Band > 64
measObjectId[2]	IdMeasObject-f8
measObject[2]	MeasObjectUTRA-GENERIC(f8)
}
reportConfigToAddModifyList SEQUENCE (SIZE (1..maxReportConfigId)) OF SEQUENCE {	1 entry
reportConfigId[1]	IdReportConfigInterRAT-B2-UTRA
reportConfig[1]	ReportConfigInterRAT-B2-UTRA (-90, -78)
}
measIdToAddModifyList SEQUENCE (SIZE (1..maxMeasId)) OF SEQUENCE {	1 entry
measId[1]	1
measObjectId[1]	IdMeasObject-f8
reportConfigId[1]	IdReportConfigInterRAT-B2-UTRA
}
quantityConfig SEQUENCE {
quantityConfigUTRA SEQUENCE {
measQuantityUTRA-FDD	cpich-RSCP		UTRA-FDD
measQuantityUTRA-TDD	pccpch-RSCP		UTRA-TDD
}
}
measObjectToAddModList-v9e0 ::= SEQUENCE (SIZE (1..maxObjectId)) OF SEQUENCE {			Band > 64
measObjectEUTRA-v9e0[1] SEQUENCE {
carrierFreq-v9e0	Same downlink EARFCN as used for f1
}
measObjectEUTRA-v9e0[2] SEQUENCE {}
}
}

Table 13.4.2.1.3.3-4: MeasurementReport (step 6, Table 13.4.2.1.3.2-2)

Derivation Path: 36.508, table 4.6.1-5
Information Element	Value/remark	Comment	Condition
MeasurementReport ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE{
measurementReport-r8 SEQUENCE {
measResults SEQUENCE {
measId	1
measResultServCell SEQUENCE {
rsrpResult	(0..97)
rsrqResult	(0..34)
}
measResultNeighCells CHOICE {
measResultListUTRA SEQUENCE (SIZE (1..maxCellReport)) OF SEQUENCE {	1 entry
physCellId[1]	PhysicalCellIdentity of Cell 5
cgi-Info[1]	Not present
measResult[1] SEQUENCE {
utra-RSCP	(-5..91)
}
}
}
}
}
}
}
}

Table 13.4.2.1.3.3-5: MobilityFromEUTRACommand (step 7, Table 13.4.2.1.3.2-2)

Derivation Path: 36.508 table 4.6.1-6
Information Element	Value/remark	Comment	Condition
MobilityFromEUTRACommand ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE{
mobilityFromEUTRACommand-r8 SEQUENCE {
purpose CHOICE {
handover SEQUENCE {
targetRAT-Type	utra
targetRAT-MessageContainer	HANDOVER TO UTRAN COMMAND
Nas-SecurityParamFromEUTRA	The 4 least significant bits of the NAS downlink COUNT value
systemInformation	Not present
}
}
}
}
}
}

Table 13.4.2.1.3.3-6: HANDOVER TO UTRAN COMMAND (Table 13.4.2.1.3.3-5)

Derivation Path: 36.508 table 4.7B.1-1, condition UTRA PS RB

Table 13.4.2.1.3.3-7: UECapabilityEnquiry (step 6A, Table 13.4.2.1.3.2-2)

Derivation path: 36.508 clause 4.6.1 table 4.6.1-22
Information Element	Value/Remark	Comment	Condition
UECapabilityEnquiry ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE {
ueCapabilityEnquiry-r8 SEQUENCE {
ue-CapabilityRequest SEQUENCE (SIZE (1..maxRAT-Capabilities)) OF SEQUENCE {	2 entry
RAT-Type[1]	Eutra
RAT-Type[2]	Utra
}
}
}
}
}

Table 13.4.2.1.3.3-8: MeasObjectUTRA-GENERIC(f8) (Table 13.4.2.1.3.3-3)

Derivation path: 36.508 table 4.6.6-3 MeasObjectUTRA-GENERIC(f8)
Information Element	Value/remark	Comment	Condition
cellsToAddModList CHOICE {
cellsToAddModListUTRA-FDD ::= SEQUENCE (SIZE (1.. maxCellMeas)) OF SEQUENCE {			UTRA-FDD
cellIndex [1]	1
physCellId [1]	physicalCellIdentity – Cell 5
}
cellsToAddModListUTRA-TDD ::= SEQUENCE (SIZE (1..maxMeasId)) OF SEQUENCE {			UTRA-TDD
cellIndex [1]	1
physCellId [1]	physicalCellIdentity – Cell 5
}
}

Table 13.4.2.1.3.3-9: UTRAN MOBILITY INFORMATION (step 8C, Table 13.4.2.1.3.2-2)

Derivation Path: 34.108 clause 9.1.1 (UTRAN MOBILITY INFORMATION message)
Information Element	Value/remark
CN information info
– PLMN identity
– MCC	001
– MNC	01
– CN common GSM-MAP NAS system information	00 01H
– CN domain information list full
– CN domain identity	PS
– CN domain specific NAS system information	01 00H
– DRX cycle length coefficient	7
– CN domain identity	CS
– CN domain specific NAS system information	1E 01H
– DRX cycle length coefficient	7

13.4.2.2 Inter-system mobility / E-UTRAN to GPRS packet

13.4.2.2.1 Test Purpose(TP)

(1)

with { UE has a default EPS bearer context}

ensure that {

when { UE receives downlink data on the radio bearer associated with the default EPS bearer context }

then { UE delivers the downlink data to upper layers }

}

(2)

with { UE has a default EPS bearer context }

ensure that {

when { uplink data are submitted for transmission }

then { UE transmits the uplink data on the radio bearer associated with the default EPS bearer context }

}

(3)

with { UE has a radio access bearer context and successful completion of the inter-system handover }

ensure that {

when { UE receives downlink data on the radio bearer associated with the radio access bearer context }

then { UE delivers the downlink data to upper layers }

}

(4)

with { UE has a radio access bearer context and successful completion of the inter-system handover }

ensure that {

when { uplink data are submitted for transmission }

then { UE transmits the uplink data on the radio bearer associated with the radio access bearer context }

}

13.4.2.2.2 Conformance requirements

References: The conformance requirements covered in the current TC are those listed in TC 8.4.1.2,plus those specified in TS 23.401, clauses 5.5.2.3.2,5.5.2.3.3.

[TS 23.401, clause 5.5.2.3.2]

Figure 5.5.2.3.2-1: E-UTRAN to GERAN A/Gb Inter RAT HO, preparation phase

1. The source eNodeB decides to initiate an Inter RAT Handover to the target GERAN A/Gb mode (2G) system. At this point both uplink and downlink user data is transmitted via the following: Bearer(s) between UE and Source eNodeB, GTP tunnel(s) between Source eNodeB, Serving GW and PDN GW.

If the UE has an ongoing emergency bearer service the source eNodeB shall not initiate PS handover to GERAN.

NOTE 1: The process leading to the handover decision is outside of the scope of this specification

2. The source eNodeB sends a Handover Required (S1AP Cause, Target System Identifier, Source eNodeB Identifier, Source to Target Transparent Container) message to the Source MME to request the CN to establish resources in the Target BSS, Target SGSN and the Serving GW. The bearers that will be subject to data forwarding (if any) are identified by the target SGSN in a later step (see step 7 below).

The ‘Target System Identifier’ IE contains the identity of the target global cell Id.

3. The Source MME determines from the ‘Target System Identifier’ IE that the type of handover is IRAT Handover to GERAN A/Gb mode. The Source MME initiates the Handover resource allocation procedure by sending a Forward Relocation Request (IMSI, Target Identification (shall be set to "empty"), MM Context, PDN Connections, MME Tunnel Endpoint Identifier for Control Plane, MME Address for Control plane, Source to Target Transparent Container, Packet Flow ID, XID parameters (if available), Target Cell Identification, MS Info Change Reporting Action (if available), CSG Information Reporting Action (if available), UE Time Zone, ISR Supported, RAN Cause) message to the target SGSN. If the information ISR Supported is indicated, this indicates that the source MME and associated Serving GW are capable to activate ISR for the UE. When ISR is activated the message should be sent to the SGSN that maintains ISR for the UE when this SGSN is serving the target identified by the Target Identification. This message includes all PDN Connections active in the source system and for each PDN Connection includes the associated APN, the address and the uplink Tunnel endpoint parameters of the Serving GW for control plane, and a list of EPS Bearer Contexts.

The target SGSN maps the EPS bearers to PDP contexts 1-to-1 and maps the EPS Bearer QoS parameter values of an EPS bearer to the Release 99 QoS parameter values of a bearer context as defined in Annex E.

Prioritization of PDP Contexts is performed by the target core network node, i.e. target SGSN.

If the Source MME supports IRAT Handover to GERAN A/Gb procedure it has to allocate a valid PFI during the bearer activation procedure. RAN Cause indicates the S1AP Cause as received from the source eNodeB. The Source to Target Transparent Container includes the value from the Source to Target Transparent Container received from the source eNodeB.

The MM context contains security related information, e.g. supported ciphering algorithms, as described in TS 29.274 [43]. Handling of security keys is described in TS 33.401 [41].

The target SGSN selects the ciphering algorithm to use. This algorithm will be sent transparently from the target SGSN to the UE in the NAS container for Handover (part of the Target to Source Transparent Container). The IOV-UI parameter, generated in the target SGSN, is used as input to the ciphering procedure and it will also be transferred transparently from the target SGSN to the UE in the NAS container for Handover. More details are described in TS 33.401 [41].

When the target SGSN receives the Forward Relocation Request message the required EPS Bearer, MM, SNDCP and LLC contexts are established and a new P-TMSI is allocated for the UE. When this message is received by the target SGSN, it begins the process of establishing PFCs for all EPS Bearer contexts.

When the target SGSN receives the Forward Relocation Request message it extracts from the EPS Bearer Contexts the NSAPIs and SAPIs and PFIs to be used in the target SGSN. If for a given EPS Bearer Context the target SGSN does not receive a PFI from the source MME, it shall not request the target BSS to allocate TBF resources corresponding to that EPS Bearer Context. If none of the EPS Bearer Contexts forwarded from the source MME has a valid PFI allocated the target SGSN shall consider this as a failure case and the request for Handover shall be rejected.

If when an SAPI and PFI was available at the source MME but the target SGSN does not support the same SAPI and PFI for a certain NSAPI as the source MME, the target SGSN shall continue the Handover procedure only for those NSAPIs for which it can support the same PFI and SAPI as the source MME. All EPS Bearer contexts for which no resources are allocated by the target SGSN or for which it cannot support the same SAPI and PFI (i.e. the corresponding NSAPIs are not addressed in the response message of the target SGSN), are maintained and the related SAPIs and PFIs are kept. These EPS Bearer contexts may be modified or deactivated by the target SGSN via explicit SM procedures upon RAU procedure.

The source MME shall indicate the current XID parameter settings if available (i.e. those XID parameters received during a previous IRAT Handover procedure) to the target SGSN. If the target SGSN can accept all XID parameters as indicated by the source MME, the target SGSN shall create a NAS container for Handover indicating ‘Reset to the old XID parameters’. Otherwise, if the target SGSN cannot accept all XID parameters indicated by the source MME or if no XID parameters were indicated by the source MME, the target SGSN shall create a NAS container for Handover indicating Reset (i.e. reset to default parameters).

The target SGSN shall determine the Maximum APN restriction based on the APN Restriction of each bearer context received in the Forward Relocation Request, and shall subsequently store the new Maximum APN restriction value.

4. The target SGSN determines if the Serving GW is to be relocated, e.g., due to PLMN change. If the Serving GW is to be relocated, the target SGSN selects the target Serving GW as described under clause 4.3.8.2 on "Serving GW selection function", and sends a Create Session Request message (IMSI, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control plane, PDN GW address(es) for user plane, PDN GW UL TEID(s) for user plane, PDN GW address(es) for control plane, and PDN GW TEID(s) for control plane, the Protocol Type over S5/S8, Serving Network) per PDN connection to the target Serving GW. The Protocol Type over S5/S8 is provided to Serving GW which protocol should be used over S5/S8 interface.

5. The target SGSN establishes the EPS Bearer context(s) in the indicated order. The SGSN deactivates, as provided in step 9 of the execution phase, the EPS Bearer contexts which cannot be established.

The Target SGSN requests the Target BSS to establish the necessary resources (PFCs) by sending the message PS Handover Request (Local TLLI, IMSI, Cause, Target Cell Identifier, PFCs to be set-up list, Source RNC to Target BSS Transparent Container and NAS container for handover). The target SGSN shall not request resources for which the Activity Status Indicator within a EPS Bearer Context indicates that no active bearer exists on the source side for that PDP context. The Cause indicates the RAN Cause as received from the source MME. The Source RNC to Target BSS Transparent Container contains the value from the Source to Target Transparent Container received from the source MME. All EPS Bearer Contexts indicate active status because E-UTRAN does not support selective RAB handling.

Based upon the ABQP for each PFC the target BSS makes a decision about which PFCs to assign radio resources. The algorithm by which the BSS decides which PFCs that need resources is implementation specific. Due to resource limitations not all downloaded PFCs will necessarily receive resource allocation. The target BSS allocates TBFs for each PFC that it can accommodate.

The target BSS shall prepare the ‘Target to Source Transparent Container’ which contains a PS Handover Command including the EPC part (NAS container for Handover) and the RN part (Handover Radio Resources).

5a. The Target BSS allocates the requested resources and returns the applicable parameters to the Target SGSN in the message PS Handover Request Acknowledge (Local TLLI, List of set-up PFCs, Target BSS to Source RNC Transparent Container, Cause). Upon sending the PS Handover Request Acknowledge message the target BSS shall be prepared to receive downlink LLC PDUs from the target SGSN for the accepted PFCs.

Any EPS Bearer contexts for which a PFC was not established are maintained in the target SGSN and the related SAPIs and PFIs are kept. These EPS Bearer contexts shall be deactivated by the target SGSN via explicit SM procedures upon the completion of the routing area update (RAU) procedure.

6. If indirect forwarding and relocation of Serving GW applies the target SGSN sends a Create Indirect Data Forwarding Tunnel Request message (Target SGSN Address(es) and TEID(s) for DL data forwarding) to the Serving GW used for indirect packet forwarding.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.

6a. The Serving GW returns a Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW DL Address(es) and TEID(s) for data forwarding) message to the target SGSN.

7. The Target SGSN sends the message Forward Relocation Response (Cause, SGSN Tunnel Endpoint Identifier for Control Plane, SGSN Address for Control Plane, Target to Source Transparent Container, RAN Cause, List of set-up PFIs, Address(es) and TEID(s) for User Traffic Data Forwarding, Serving GW change indication) to the Source MME. Serving GW change indication indicates a new Serving GW has been selected. RAN Cause indicates the Cause as received from the target BSS. The Target to Source Transparent Container includes the value from the Target BSS to Source RNC Transparent Container received from the target BSS.

If ‘Indirect Forwarding’ and relocation of Serving GW applies, then the IEs ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contain the DL GTP-U tunnel endpoint parameters received in step 6a. Otherwise the IEs ‘Address(es) and TEID(s) for User Traffic Data Forwarding’ contains the DL GTP-U tunnel endpoint parameters to the Target SGSN.

The target SGSN activates the allocated LLC/SNDCP engines as specified in TS 44.064 [23] for an SGSN originated Reset or ‘Reset to the old XID parameters’.

8. If "Indirect Forwarding" applies, the Source MME sends the message Create Indirect Data Forwarding Tunnel Request (Address(es) and TEID(s) for Data Forwarding (received in step 7)) to the Serving GW used for indirect packet forwarding.

Indirect forwarding may be performed via a Serving GW which is different from the Serving GW used as the anchor point for the UE.

8a. The Serving GW returns the forwarding user plane parameters by sending the message Create Indirect Data Forwarding Tunnel Response (Cause, Serving GW Address(es) and TEID(s) for Data Forwarding). If the Serving GW doesn’t support data forwarding, an appropriate cause value shall be returned and the Serving GW Address(es) and TEID(s) will not be included in the message.

[TS 23.401, clause 5.5.2.3.3]

Figure 5.5.2.3.3-1: E-UTRAN to GERAN A/Gb mode Inter RAT HO, execution phase

NOTE 1: For a PMIP-based S5/S8, procedure steps (A) and (B) are defined in TS 23.402 [2]. Step (B) shows PCRF interaction in the case of PMIP-based S5/S8. Steps 10 and 10a concern GTP based S5/S8

The source eNodeB continues to receive downlink and uplink user plane PDUs.

1. The Source MME completes the preparation phase towards Source eNodeB by sending the message Handover Command (Target to Source Transparent Container (PS Handover Command with RN part and EPC part), E‑RABs to Release List, Bearers Subject to Data Forwarding List), S1AP Cause. The "Bearers Subject to Data forwarding list" may be included in the message and it shall be a list of ‘Address(es) and TEID(s) for user traffic data forwarding’ received from target side in the preparation phase (Step 7 of the preparation phase for Direct Forwarding, else parameters received in Step 8a of the preparation phase). S1AP Cause indicates the RAN Cause as received from the target SGSN.

Source eNodeB initiate data forwarding for the bearers specified in the "Bearers Subject to Data Forwarding List". The data forwarding may go directly i.e. to target SGSN or alternatively go via the Serving GW if so decided by source MME and/or target SGSN in the preparation phase.

2. The Source eNodeB will give a command to the UE to handover to the Target Access System via the message HO from E-UTRAN Command. This message includes a transparent container including radio aspect parameters that the Target BSS has set-up in the preparation phase (RN part). This message also includes the XID and IOV-UI parameters received from the Target SGSN (EPC part).

Upon the reception of the HO from E-UTRAN Command message containing the Handover Command message, the UE shall associate its bearer IDs to the respective PFIs based on the relation with the NSAPI and shall suspend the uplink transmission of the user plane data.

3. Void.

4. The UE moves to the Target GERAN A/Gb (2G) system and performs executes the handover according to the parameters provided in the message delivered in step 2. The procedure is the same as in step 6 in clause 5.3.2.2 in TS 43.129 [8] with the additional function of association of the received PFI and existing Bearer Id related to the particular NSAPI.

The UE locally deactivates ISR by setting its TIN from "RAT-related TMSI" to "GUTI", if any EPS bearer context activated after the ISR was activated in the UE exists.

5. After accessing the cell using access bursts and receiving timing advance information from the BSS in step 4, the UE processes the NAS container and then sends one XID response message to the target SGSN via target BSS. The UE sends this message immediately after receiving the Packet Physical Information message containing the timing advance or, in the synchronised network case, immediately if the PS Handover Access message is not required to be sent.

Upon sending the XID Response message, the UE shall resume the user data transfer only for those NSAPIs for which there are radio resources allocated in the target cell. For NSAPIs using LLC ADM, for which radio resources were not allocated in the target cell, the MS may request for radio resources using the legacy procedures.

If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in the HO from E-UTRAN Command message, and to avoid collision cases the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ADM, but wait for the SGSN to do so (see step 12). In any case the mobile station may avoid triggering XID negotiation for any LLC SAPI used in LLC ABM, but wait for the SGSN to do so (see step 12a).

This step is the same as specified in clause 5.3.2.2 in TS 43.129 [8].

6. Upon reception of the first correct RLC/MAC block (sent in normal burst format) from the UE to the Target BSS, the Target BSS informs the Target SGSN by sending the message PS Handover Complete (IMSI, and Local TLLI, Request for Inter RAT Handover Info). The target BSS that supports inter-RAT PS handover to UTRAN shall, when the INTER RAT HANDOVER INFO was not included in the Source BSS to Target BSS transparent container received in the PS HANDOVER REQUEST message as specified in TS 48.018 [42], request the INTER RAT HANDOVER INFO from the target SGSN by setting the ‘Request for Inter RAT Handover Info’ to ‘1’.

7. The Target BSS also relays the message XID Response to the Target SGSN. Note, the message in step 6 and 7 may arrive in any order in the Target SGSN.

8. Then the Target SGSN knows that the UE has arrived to the target side and Target SGSN informs the Source MME by sending the Forward Relocation Complete Notification (ISR Activated, Serving GW change) message. If ISR Activated is indicated, the source MME shall maintain the UE’s contexts and activate ISR, which is only possible when the S‑GW is not changed. The Source MME will also acknowledge that information. A timer in source MME is started to supervise when resources in Source eNodeB and Source Serving GW (for Serving GW relocation) shall be released.

Upon receipt of the Forward Relocation Complete Acknowledge message the target SGSN starts a timer if the target SGSN allocated S‑GW resources for indirect forwarding.

9. The Target SGSN will now complete the Handover procedure by informing the Serving GW (for Serving GW relocation this will be the Target Serving GW) that the Target SGSN is now responsible for all the EPS Bearer Context(s) the UE has established. This is performed in the message Modify Bearer Request (SGSN Tunnel Endpoint Identifier for Control Plane, NSAPI(s), SGSN Address for Control Plane, SGSN Address(es) and TEID(s) for User Traffic for the accepted EPS bearers and RAT type, ISR Activated) per PDN connection. If the PDN GW requested UE’s location and/or User CSG information (determined from the UE context), the SGSN also includes the User Location Information IE and/or User CSG Information IE in this message. If the UE Time Zone has changed, the SGSN includes the UE Time Zone IE in this message. If indicated, ISR Activated indicates that ISR is activated, which is only possible when the S‑GW was not changed. When the Modify Bearer Request does not indicate ISR Activated and S‑GW is not changed, the S‑GW deletes any ISR resources by sending a Delete Bearer Request to the other CN node that has bearer resources on the S‑GW reserved.

The SGSN releases the non-accepted EPS Bearer contexts by triggering the EPS Bearer context deactivation procedure. If the Serving GW receives a DL packet for a non-accepted bearer, the Serving GW drops the DL packet and does not send a Downlink Data Notification to the SGSN.

10. The Serving GW (for Serving GW relocation this will be the Target Serving GW) may inform the PDN GW the change of, for example, for Serving GW relocation or the RAT type, that e.g. can be used for charging, by sending the message Modify Bearer Request per PDN connection. The S‑GW also includes User Location Information IE and/or UE Time Zone IE and/or User CSG Information IE if they are present in step 9. Serving Network should be included if it is received in step 4. For Serving GW relocation, the Serving GW allocates DL TEIDs on S5/S8 even for non-accepted bearers. The PDN GW must acknowledge the request with the message Modify Bearer Response. In the case of Serving GW relocation, the PDN GW updates its context field and returns a Modify Bearer Response (Charging Id, MSISDN, etc.) message to the Serving GW. The MSISDN is included if the PDN GW has it stored in its UE context.

If PCC infrastructure is used, the PDN GW informs the PCRF about the change of, for example, the RAT type.

11. The Serving GW (for Serving GW relocation this will be the Target Serving GW) acknowledges the user plane switch to the Target SGSN via the message Modify Bearer Response (Cause, Serving GW Tunnel Endpoint Identifier for Control Plane, Serving GW Address for Control Plane, Protocol Configuration Options). At this stage the user plane path is established for all EPS Bearer contexts between the UE, Target BSS, Target SGSN, Serving GW (for Serving GW relocation this will be the Target Serving GW) and PDN GW.

If the Serving GW does not change, the Serving GW shall send one or more "end marker" packets on the old path immediately after switching the path.

12. If the Target SGSN indicated XID Reset (i.e. reset to default XID parameters) in the NAS container included in the HO from E-UTRAN Command message, then on receipt of the PS Handover Complete the Target SGSN initiates an LLC/SNDCP XID negotiation for each LLC SAPI used in LLC ADM. In this case if the Target SGSN wants to use the default XID parameters, it shall send an empty XID Command. If the Target SGSN indicated ‘Reset to the old XID parameters’ in the NAS container, no further XID negotiation is required for LLC SAPIs used in LLC ADM only.

12a. The Target SGSN (re-)establishes LLC ABM for the EPS Bearer contexts which use acknowledged information transfer. During the exchange of SABM and UA the SGSN shall perform LLC/SNDCP XID negotiation.

These steps (12 and 12a) are the same as specified in clause 5.3.2.2 in TS 43.129 [8].

13. After the UE has finished the reconfiguration procedure the UE shall initiate the Routing Area Update procedure.

NOTE 1: The RAU procedure is performed regardless if the UE has this routing area registered or not, as specified by TS 43.129 [8]. This is needed e.g. to update the START-PS value stored in the 2G-SGSN. The START_PS is delivered to SGSN in INTER RAT HANDOVER INFO parameter of RAU Complete message when requested by SGSN in RAU Accepted.

The target SGSN knows that an IRAT Handover has been performed for this UE as it received the bearer context(s) by handover messages and therefore the target SGSN performs only a subset of the RAU procedure, specifically it excludes the context transfer procedures between source MME and target SGSN.

13a. Upon reception of the PS Handover Complete message with the ‘Request for Inter RAT Handover Info’ set to ‘1’, the SGSN should send then PS Handover Complete Acknowledge (TLLI, INTER RAT HANDOVER INFO) to the target BSS.

NOTE 2: An SGSN that does not recognize the "Request for Inter RAT Handover Info" in the PS Handover Complete message will not send the PS Handover Complete Acknowledge message back to the BSS.

The target BSS receiving the PS Handover Complete Acknowledge message shall set the ‘Reliable INTER RAT HANDOVER’ to ‘1’ in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb mode. The target BSS failing to receive the PS Handover Complete Acknowledge message shall set the ‘Reliable INTER RAT HANDOVER’ to ‘0’ in the PS Handover Required message in any subsequent PS handover to GERAN A/Gb mode. The Target BSS shall, upon receipt of the INTER RAT HANDOVER INFO in the PS Handover Complete Acknowledge message, overwrite its current INTER RAT HANDOVER INFO with this new one.

14. When the timer started at step 8 expires, the source MME sends a Release Resources message to the source eNodeB. The Source eNodeB releases its resources related to the UE.

When the timer started in step 8 expires and if the source MME received the Serving GW change indication in the Forward Relocation Response message, it deletes the EPS bearer resources by sending Delete Session Request (Cause) messages to the Source Serving GW. Cause indicates to the Source Serving GW that the Serving GW changes and the Source Serving GW shall not initiate a delete procedure towards the PDN GW. The Source Serving GW acknowledges with Delete Session Response (Cause) messages. If ISR has been activated before this procedure, the cause also indicates to the Source S‑GW that the Source S‑GW shall delete the bearer resources on the other old CN node by sending Delete Bearer Request message(s) to that CN node.

15. If indirect forwarding was used then the expiry of the timer at source MME started at step 8 triggers the source MME to send a Delete Indirect Data Forwarding Tunnel Request message to the S‑GW to release the temporary resources used for indirect forwarding.

16. If indirect forwarding was used and the Serving GW is relocated, then the expiry of the timer at target SGSN started at step 8 triggers the target SGSN to send a Delete Indirect Data Forwarding Tunnel Request message to the target S‑GW to release temporary resources used for indirect forwarding.

13.4.2.2.3.1 Pre-test conditions

System Simulator:

– Cell 1 and Cell 24

– System information combination 5 as defined in TS 36.508[18] clause 4.4.3.1 is used in E-UTRA cell;

UE:

None.

Preamble:

– The UE is in state Loopback Activated (state 4) on Cell 1 according to [18] using the UE TEST LOOP MODE B.

13.4.2.2.3.2 Test procedure sequence

Table 13.4.2.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. Row marked “T0” DENOTES THE INITIAL CONDITIONS AFTER PREAMBLE WHILE COLUMNS MARKED “T1” is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.2.3.2-1: Time instances of cell power level and parameter changes

	Parameter	Unit	Cell 1	Cell 24	Remark
T0	Cell-specific RS EPRE	dBm/15kHz	-60	–	The power level values are such that entering conditions for event B2 are not satisfied.
T0	RSSI	dBm	–	-85
T1	Cell-specific RS EPRE	dBm/15kHz	-80	–	The power level values are such that entering conditions for event B2 are satisfied.
T1	RSSI	dBm	–	-65

Table 13.4.2.2.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message	–	–
1	The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context on Cell 1.	<–	IP packet	–	–
2	Check: Does the UE loop back the IP packet on the DRB associated with the default EPS bearer context on Cell 1?	–>	IP packet	1,2	P
3	The SS transmits an RRCConnectionReconfiguration message on Cell 1 to setup inter RAT measurement and reporting for event B2.	<–	RRCConnectionReconfiguration	–	–
4	The UE transmits an RRCConnectionReconfigurationComplete message on Cell 1.	–>	RRCConnectionReconfigurationComplete	–	–
5	The SS changes the power level for Cell 1 and Cell 24 according to the row "T1" in table 13.4.2.2.3.2-1	–	–	–	–
6	The UE transmits a MeasurementReport message on Cell 1 to report event B2 for Cell 24.	–>	MeasurementReport	–	–
7	The SS transmits a MobilityFromEUTRACommand message on Cell 1 to order the UE to perform inter system handover to Cell 24.	<–	MobilityFromEUTRACommand	–	–
8	The UE transmits a HANDOVER ACCESS message on Cell 24 to switch to GSM cell.	–>	HANDOVER ACCESS	–	–
9	The SS transmits a PHYSICAL INFORMATION message on Cell 24 to indicate parameters	<–	PHYSICAL INFORMATION	–	–
10-18	Steps 3 to 11 of the Routing Area Update procedure described in TS 36.508 subclause 6.4.2.9 are performed on Cell 24. NOTE: The UE performs RAU procedure.	–	–	–	–
19	The SS transmits one IP packet to the UE on the DRB associated with the RAB context on Cell 24.	<–	IP packet	–	–
20	Check: Does the UE loop back the IP packet on the DRB associated with the RAB context on Cell 24?	–>	IP packet	3,4	P

13.4.2.2.3.3 Specific message contents

Table 13.4.2.2.3.3-1: ACTIVATE TEST MODE (preamble)

Derivation Path: 36.508, Table 4.7A-1, condition UE TEST LOOP MODE B

Table 13.4.2.2.3.3-2: RRCConnectionReconfiguration (step 3, Table 13.4.2.2.3.2-2)

Derivation Path: 36.508 clause 4.6.1 table 4.6.1-8 with condition MEAS

Table 13.4.2.2.3.3-3: MeasConfig (step 3, Table 13.4.2.2.3.2-2)

Derivation Path: 36.508, Table 4.6.6-1, condition GERAN
Information Element	Value/remark	Comment	Condition
MeasConfig ::= SEQUENCE {
measObjectToAddModList SEQUENCE (SIZE (1..maxObjectId)) OF SEQUENCE {	2entry
measObjectId[1]	IdMeasObject-EUTRA
measObject[1]	MeasObjectEUTRA-GENERIC(f1)
measObject[1]	MeasObjectEUTRA-GENERIC(maxEARFCN)		Band > 64
measObjectId[2]	IdMeasObject-f11
measObject[2]	MeasObjectGERAN-GENERIC(f11)
}
reportConfigToAddModList SEQUENCE (SIZE (1..maxReportConfigId)) OF SEQUENCE {	2entry
reportConfigId[1]	IdReportConfig-A2
reportConfig[1]	ReportConfigEUTRA-A2(-95)
reportConfigId[2]	IdReportConfig-B2-GERAN
reportConfig[2]	ReportConfigInterRAT-B2-GERAN(-69, -79)
}
measIdToAddModList SEQUENCE (SIZE (1..maxMeasId)) OF SEQUENCE {	2 entry
measId[1]	1
measObjectId[1]	IdMeasObject-EUTRA
reportConfigId[1]	IdReportConfig-A2
measId[2]	2
measObjectId[2]	IdMeasObject-f11
reportConfigId[2]	IdReportConfig-B2-GERAN
}
quantityConfig SEQUENCE {
quantityConfigGERAN SEQUENCE {
measQuantityGERAN	rssi
filterCoefficient	fc0
}
}
measObjectToAddModList-v9e0 ::= SEQUENCE (SIZE (1..maxObjectId)) OF {	2 entries		Band > 64
measObjectEUTRA-v9e0[1] ::= SEQUENCE {
carrierFreq-v9e0	Same downlink EARFCN as used for f1
}
measObjectEUTRA-v9e0[2] ::= SEQUENCE {}
}
}

Condition	Explanation
Band > 64	If band > 64 is selected

Table 13.4.2.2.3.3-4: MeasurementReport (step 6, Table 13.4.2.2.3.2-2)

Derivation Path: 36.508, table 4.6.1-5
Information Element	Value/remark	Comment	Condition
MeasurementReport ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE{
measurementReport-r8 SEQUENCE {
measResults SEQUENCE {
measId	1
measResultServCell SEQUENCE {
rsrpResult	(0..97)
rsrqResult	(0..34)
}
measResultNeighCells CHOICE {
measResultListGERAN SEQUENCE (SIZE (1..maxCellReport)) OF SEQUENCE {	1 entry
physCellId[1]	PhysicalCellIdentity of Cell 24
cgi-Info[1]	Not present
measResult[1] SEQUENCE {
rssi	(0..63)
}
}
}
}
}
}
}
}

Table 13.4.2.2.3.3-5: MobilityFromEUTRACommand (step 7, Table 13.4.2.2.3.2-2)

Derivation Path: 36.508 table 4.6.1-6
Information Element	Value/remark	Comment	Condition
MobilityFromEUTRACommand ::= SEQUENCE {
criticalExtensions CHOICE {
c1 CHOICE{
mobilityFromEUTRACommand-r8 SEQUENCE {
csFallbackIndicator	false
purpose CHOICE {
handover SEQUENCE {
targetRAT-Type	geran
targetRAT-MessageContainer	PS HANDOVER COMMAND
nas-SecurityParamFromEUTRA	Not present
systemInformation	Not present
}
}
}
}
}
}

Table 13.4.2.2.3.3-6: PS HANDOVER COMMAND (step 7, Table 13.4.2.2.3.2-2)

Derivation Path from TS 36.508, Table 4.7D.1-1.

13.4.2.3 Void

13.4.2.4 Inter-system mobility / Service based redirection from UTRA to E-UTRA

13.4.2.4.1 Test Purpose (TP)

(1)

with { UE in UTRA RRC idle state and pdp-active state }

ensure that {

when { UE is requested to initiate uplink data traffic. }

then { UE includes in the RRC CONNECTION REQUEST the IE Pre-Redirection info and the IE Domain indicator is set to PS Domain }

}

(2)

with { UE has a default EPS bearer context upon redirection }

ensure that {

when { UE receives downlink data on the radio bearer associated with the default EPS bearer context }

then { UE delivers the downlink data to upper layers }

}

(3)

with { UE has a default EPS bearer context upon redirection }

ensure that {

when { uplink data are submitted for transmission }

then { UE transmits the uplink data on the radio bearer associated with the default EPS bearer context }

}

13.4.2.4.2 Conformance requirements

References: The conformance requirements covered in the current TC are those listed in TC 8.1.3.7, plus those specified in: TS 24.008, clause 4.7.13.5.

[TS 24.008, clause 4.7.13.5]

The following abnormal cases can be identified:

a) Access barred because of access class control

The Service request procedure shall not be started. The MS stays in the current serving cell and applies normal cell reselection process. The Service request procedure may be started by CM layer if it is still necessary, i.e. when access is granted or because of a cell change.

b) Lower layer failure before the security mode control procedure is completed, SERVICE ACCEPT or SERVICE REJECT message is received

The procedure shall be aborted except in the following implementation option cases b.1, b.2 and b.3.

b.1) Release of PS signalling connection in Iu mode (i.e. RRC connection release) before the completion of the service request procedure

The service request procedure shall be initiated again, if the following conditions apply:

i) The original service request procedure was initiated over an existing PS signalling connection; and

ii) No SECURITY MODE COMMAND message and no Non-Access Stratum (NAS) messages relating to the PS signalling connection were received after the SERVICE REQUEST message was transmitted.

b.2) RR release in Iu mode (i.e. RRC connection release) with cause different than "Directed signalling connection re-establishment", for example, "Normal", or "User inactivity" (see 3GPP TS 25.331 [32c] and 3GPP TS 44.118 [111])

The service request procedure shall be initiated again, if the following conditions apply:

i) The original service request procedure was initiated over an existing RRC connection and,

ii) No SECURITY MODE COMMAND message and no Non-Access Stratum (NAS) messages relating to the PS signalling connection were received after the SERVICE REQUEST message was transmitted.

NOTE: The RRC connection release cause different than "Directed signalling connection re-establishment" that triggers the re-initiation of the service request procedure is implementation specific.

b.3) RR release in Iu mode (i.e. RRC connection release) with cause "Directed signalling connection re-establishment" (see 3GPP TS 25.331 [32c] and 3GPP TS 44.118 [111])

The routing area updating procedure shall be initiated followed by a rerun of the service request procedure if the following condition applies:

i) The service request procedure was not due to a rerun of the procedure due to "Directed signalling connection re-establishment".

13.4.2.4.3 Test description

13.4.2.4.3.1 Pre-test conditions

System Simulator:

Cell 1 and Cell 5
System information combination 4 as defined in TS 36.508 [18] clause 4.4.3.1 is used in E-UTRA cells.

UE:

None.

Preamble:

– The UE is in Registered, Idle mode, Test Mode Activated (State 2A) according to [18] and then moved to RRC idle state, GMM-Registered and pdp-active State on Cell 5

13.4.2.4.3.2 Test procedure sequence

Table 13.4.2.4.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. Row marked "T0" denotes the initial conditions after preamble, while columns marked "T1" is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.4.3.2-1: Time instances of cell power level and parameter changes

	Parameter	Unit	Cell 1	Cell 5	Remark
T1	Cell-specific RS EPRE	dBm/15kHz	-75	–
	CPICH Ec (UTRA FDD)	dBm/3.84 MHz	–	-70
	PCCPCH Ec (UTRA LCR TDD)	dBm/1.28 MHz	–	-72

Table 13.4.2.4.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message	–	–
1	The SS sends a PAGING TYPE 1 message.	<–	PAGING TYPE 1	–	–
2	Check: does the UE include the IE include the IE Pre-redirection info with Support of E-UTRA set to TRUE and the Domain indicator is set to PS domain?	–>	RRC CONNECTION REQUEST	1	P
3	The SS transmit a RRC CONNECTION SETUP on SRB1 on Cell 5.	<–	RRC CONNECTION SETUP	–	–
4	The UE transmits an RRC CONNECTION SETUP COMPLETE message	–>	RRC CONNECTION SETUP COMPLETE	–	–
5	The UE transmits the SERVICE REQUEST message for Paging Response	–>	RRC: INITIAL DIRECT TRANSFER NAS: SERVICE REQUEST	–	–
6	The SS transmits an RRC CONNECTION RELEASE message (IE E-UTRA target info including DL Carrier frequency of Cell 1).	<–	RRC CONNECTION RELEASE	–	–
7	The UE transmits a RRC CONNECTION RELEASE COMPLETE message	–>	RRC CONNECTION RELEASE COMPLETE	–	–
8	The UE transmits a RRC CONNECTION RELEASE COMPLETE message	–>	RRC CONNECTION RELEASE COMPLETE	–	–
9-15	Steps 1 to 7 of the generic test procedure in TS 36.508 [18] subclause 6.4.2.7A-1 are performed on Cell 1. Note: The UE performs a TAU procedure.	–	–	.	–
15A1	The SS starts timer Timer_1 = 1 s	–	–	–	–
–	EXCEPTION: Steps 15Ba1 to 15Bb1 describe a transaction that depends on the UE behaviour; the "lower case letter" identifies a step sequence that takes place if a specific behaviour happens.	–	–	–	–
15Ba1	The UE transmits a SERVICE REQUEST message.	–>	RRC: ULInformationTransfer NAS: SERVICE REQUEST	–	–
15Bb1	The SS waits for Timer_1 expiry	–	–	–	–
15C	The SS transmits a SecurityModeCommand message to activate AS security.	<–	SecurityModeCommand	–	–
15D	The UE transmits a SecurityModeComplete message and establishes the initial security configuration.	–>	SecurityModeComplete	–	–
15E	The SS transmits an RRCConnectionReconfiguration message to establish the default bearer with condition SRB2-DRB(1, 0) according to 4.8.2.2.1.1.	<–	RRCConnectionReconfiguration	–	–
15F	The UE transmits an RRCConnectionReconfigurationComplete message to confirm the establishment of default bearer.	–>	RRCConnectionReconfigurationComplete	–	–
16	The SS closes the UE test loop mode using the UE Test Loop Mode B.	–	–	–	–
17	The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context.	<–	IP packet	–	–
18	Check: Does the UE loop back the IP packet on the DRB associated with the default EPS bearer context?	–>	IP packet	2, 3	P

13.4.2.4.3.3 Specific message contents

Table 13.4.2.4.3.3-0: Conditions for specific message contents
in Table 13.4.2.4.3.3-1

Condition	Explanation
Band > 64	If band > 64 is selected

Table 13.4.2.4.3.3-1: System Information Block type 19 for Cell 5 (preamble and all steps, Table 13.4.2.4.3.2-2)

Derivation Path: 36.508 table Table 4.4.4.1-1
Information Element	Value/remark	Comment	Condition
SysInfoType19 ::= SEQUENCE {
utra-PriorityInfoList SEQUENCE {
utra-ServingCell SEQUENCE {
Priority	4
}
eutra-FrequencyAndPriorityInfoList SEQUENCE (SIZE (1..maxNumEUTRAFreqs)) OF SEQUENCE	1 entry
earfcn[1]	Downlink EARFCN of Cell 1
priority[1]	3
}
v920NonCriticalExtensions SEQUENCE {			Band > 64
va80NonCriticalExtensions SEQUENCE {
vb30NonCriticalExtensions SEQUENCE {
vb50NonCriticalExtensions SEQUENCE {
sysInfoType19-vb50ext SEQUENCE {
eutra-FrequencyAndPriorityInfoExtensionList SEQUENCE (SIZE (1..maxNumEUTRAFreqs)) OF SEQUENCE {
earfcn [n]	Same downlink EARFCN as used for Cell 1
priority [n]	3
}
}
}
}
}
}
}

Table 13.4.2.4.3.3-2: PAGING TYPE 1 (step 1, Table 13.4.2.4.3.2-2)

Derivation path: 34.108 default PAGING TYPE 1 in section 9.1.1 for UTRA FDD or 9.1.2 for UTRA TDD
Information Element	Value/Remark	Comment	Condition
Paging record list	1 Entry
Paging record	Present
Paging cause	Terminating High Priority Signalling,
CN domain identity	PS domain

Table 13.4.2.4.3.3-3: RRC CONNECTION REQUEST (step 2, Table 13.4.2.4.3.2-2)

Derivation path: 34.108 default RRC CONNECTION REQUEST in section 9.1.1 for UTRA FDD or 9.1.2 for UTRA TDD
Information Element	Value/Remark	Comment	Condition
Establishment cause	Terminating High Priority Signalling
Domain indicator	PS domain
Pre-redirection info	Present	The presence of this IE indicates the UE support of radio access technologies that the UE could be directed to
Support of E-UTRA FDD	TRUE		E-UTRA-FDD
Support of E-UTRA TDD	TRUE		E-UTRA-TDD

Table 13.4.2.4.3.3-4: SERVICE REQUEST (step 5, Table 13.4.2.4.3.2-2)

Derivation path: 24.008 table 9.4.20
Information Element	Value/Remark	Comment	Condition
Service Type	010 (Paging Response)

Table 13.4.2.4.3.3-5: RRC CONNECTION RELEASE (step 6, Table 13.4.2.4.3.2-2)

Derivation path: 34.108 default RRC CONNECTION RELEASE in section 9.1.1 for UTRA FDD or 9.1.2 for UTRA TDD
Information Element	Value/Remark	Comment	Condition
N308	1
Release cause	Directed signalling connection reestablishment
Redirection info
Frequency info	Omitted
Inter-RAT info	E-UTRA
E-UTRA target info
E-UTRA Target Frequency Info List	1 Entry
FDD			E-UTRA-FDD
DL Carrier frequency	The DL Carrier frequency of Cell 1
Blacklisted cells per freq list	Omitted
DL Carrier frequency	65535		Band > 64
TDD			E-UTRA-TDD
DL Carrier frequency	The DL Carrier frequency of Cell 1
Blacklisted cells per freq list	Omitted
DL Carrier frequency	65535		Band > 64
E-UTRA Target Frequency Info extension List			Band > 64
EARFCN extension	EARFCN of the downlink Cell 1 carrier frequency

13.4.2.5 Inter-system mobility / Service based redirection from GSM/GPRS to E-UTRA

13.4.2.5.1 Test Purpose (TP)

(1)

with { UE in GPRS Registered state }

ensure that {

when { UE is requested to initiate a service based redirection to E-UTRA }

then { UE performs service based redirection to E-UTRA cell }

}

13.4.2.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 44.060 section 7.4.2

[TS 44.060, section 7.4.2]

The network may initiate the cell change order procedure by sending an IMMEDIATE ASSIGNMENT message for single block assignment in a CCCH block monitored by the mobile station. No TBF shall be established. The single block assignment procedure is specified in 3GPP TS 44.018.

The network shall then send the PACKET CELL CHANGE ORDER message in the assigned downlink block to the mobile station. The PACKET CELL CHANGE ORDER message contains:

– the characteristics of the new cell that are necessary to identify it (i.e. BSIC + BCCH frequency);

– the NC measurement parameters valid for the mobile station in the new cell (NETWORK_CONTROL_ORDER and optionally: NC_NON_DRX_PERIOD, NC_REPORTING_PERIOD_I and NC_REPORTING_PERIOD_T).

For a multi-RAT mobile station supporting UTRAN, the PACKET CELL CHANGE ORDER message may contain information on a UTRAN target cell; in this case, the establishment of channel(s) and subsequent measurement reporting are defined in 3GPP TS 25.331.

For a multi-RAT mobile station supporting “CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell reselection to E-UTRAN”, the PACKET CELL CHANGE ORDER message may contain information on an E-UTRAN target cell; in this case, the establishment of channel(s) and subsequent measurement reporting are defined in 3GPP TS 36.331.

Upon receipt of the PACKET CELL CHANGE ORDER message, the mobile station shall stop all relevant RLC/MAC timers except for timers related to measurement reporting and start timer T3174. The mobile station shall then switch to the specified new cell and obey the relevant RLC/MAC procedures on this new cell. If a valid RRBP field was received in the PACKET CELL CHANGE ORDER message then the MS shall send a PACKET CONTROL ACKNOWLEDMENT message in the reserved uplink radio block specified by the RRBP field before switching to the new cell. If the timers related to measurement reporting expire while the reselection procedure has not yet been completed, these timers shall be restarted so that the mobile station resumes the measurement reporting procedures once camped on the new cell. A UTRAN capable mobile station ordered to a UTRAN cell shall obey the PACKET CELL CHANGE ORDER message irrespective of whether or not the target cell is known (see 3GPP TS 25.133 and 3GPP TS 25.123); an E-UTRAN capable mobile station ordered to an E-UTRAN cell shall obey the PACKET CELL CHANGE ORDER message irrespective of whether the target cell is known or not known (see 3GPP TS 36.133).

13.4.2.5.3 Test description

13.4.2.5.3.1 Pre-test conditions

System Simulator:

– Cell 24 is serving GERAN Cell

– Cell 1 is suitable E-UTRAN Cell

UE:

None.

Preamble:

The UE is in state Generic RB Established, UE test mode activated (state3A 3A) according to [18] and then moved to GPRS packet idle state, with power levels as in Table 13.4.2.5.3.2-1 T0, on Cell 24.

13.4.2.5.3.2 Test procedure sequence

Table 13.4.2.5.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.5.3.2-1: Time instances of cell power level and parameter changes for E-UTRA cell

	Parameter	Unit	Cell 1	Cell24	Remark
T0	Cell-specific RS EPRE	dBm/15kHz	off	-60	Camping on Cell 24 is guaranteed
T1	Cell-specific RS EPRE	dBm/15kHz	-60	-60	The power level is such that SrxlevCell 1 > 0
Note: Srxlev is calculated in the UE

Table 13.4.2.5.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	The SS changes Cell 1 levels according to the row "T1" in table 13.4.2.5.3.2-1.
2	SS sends IMMEDIATE ASSIGNMENT	<–	IMMEDIATE ASSIGNMENT	–	–
3	The SS sends PACKET CELL CHANGE ORDER for cell 1 as the target cell on cell 24	<–	PACKET CELL CHANGE ORDER	–	–
4	Steps 1 to 7 of the generic test procedure in TS 36.508 [18] subclause 6.4.2.7A-1 are performed on Cell 1. Note: The UE performs a TAU procedure and a default EPS Bearer is setup.	–	–	.	–
4A	The SS closes the UE test loop mode using the UE Test Loop Mode B	–	–	–	–
5	The SS transmits one IP packet to the UE on the DRB associated with the default EPS bearer context.	<–	IP packet	–	–
6	Check: Does the UE loop back the IP packet on the DRB associated with the default EPS bearer context?	–>	IP packet	1	P

13.4.2.5.3.3 Specific message contents

Table 13.4.2.5.3.3-2: PACKET CELL CHANGE ORDER (step 5, Table 13.4.2.5.3.2-2)

Information element	Value/remark	Condition
< PAGE_MODE : bit (2) >	00 (Normal Paging)
0 \| 10	0
< GLOBAL_TFI : Global TFI IE >	<5 bit Uplink TFI>
0 \| 1	1
Message Escape < IMMEDIATE_REL > 0\|1<UTRAN FDD Target cell IE> 0\|1<UTRAN TDD Target cell IE> Additions in Rel-5 0 \| 1 < G-RNTI extension Additions in Rel-8 0\|1<E-UTRAN Target cell IE> 0\|1<E-UTRAN Target cell IE> EARFCN 0 \| 1 < Measurement Bandwidth Physical Layer Cell identity 0 \| 1 < Individual Priorities Additions in Rel-11 0 \| 1 <E-UTRAN Target cell with extended EARFCN IE > EARFCN_extended 0 \| 1 < Measurement Bandwidth Physical Layer Cell Identity 0 \| 1 <E-UTRAN IPP with extended EARFCNs IE>	00 1 (Immediate abort of operation in the old cell is required) 0 (not present ) 0 (not present ) 1 0 (not present )1 0 1 EARFCN of the cell 1 0 (not present ) PCID of the cell 1 0 (not present ) 1 1 EARFCN of the cell 1 0 (not present ) PCID of the cell 1 0 (not present )	Band>64 Band>64

Condition	Explanation
Band > 64	If band > 64 is selected

Table 13.4.2.5.3.3-3: Message ROUTING AREA UPDATE REQUEST (Preamble)

Derivation Path: Table 4.7B.2-1/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
MS Radio Access capability
GERAN to E-UTRA support in GERAN packet transfer mode	‘10’B or ‘11’B	CCN towards E-UTRAN, E-UTRAN Neighbour Cell measurement reporting and Network controlled cell reselection to E-UTRAN supported
E-UTRA FDD support	‘0’B or ‘1’B		C1
E-UTRA TDD support	‘0’B or ‘1’B		C1
Note C1: At least one of these fields shall be set to ‘1’B

Table 13.4.2.5.3.3-4: Message ROUTING AREA UPDATE ACCEPT (Preamble)

Derivation Path: Table 4.7B.2-2/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
PDP context status	Same value as the one received in the RAU request message

13.4.2.6 Inter-RAT PS Handover / from GPRS Packet_transfer to E-UTRA cell

13.4.2.6.1 Test Purpose (TP)

(1)

with { UE in GPRS Registered state with active packet data transfer in NC2 mode }

ensure that {

when { UE receives a PS HANDOVER COMMAND message configured for a EUTRAN Cell.Blind PS HANDOVER sceanrio }

then { UE transmits a RRCConnectionReconfigurationComplete message and performs Tracking Area update on EUTRAN cell to continue the data transfer }

}

13.4.2.6.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 43.129, clause 5.3a.

[TS 43.129, clause 5.3a.1]

For performing the inter-RAT handover from GERAN A/Gb mode to E-UTRAN the pre-conditions are:

– The MS is in packet transfer mode (GERAN A/Gb mode);

– The MS has at least one PDP Context established;

– The BSS supports PFM (Packet Flow Management) procedures.

[TS 43.129, clause 5.3a.2]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.2.

[TS 43.129, clause 5.3a.3]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.3.

13.4.2.6.3 Test description

13.4.2.6.3.1 Pre-test conditions

System Simulator:

– 2 cells, one GSM and one E-UTRA cell:

– Cell 24 GSM serving cell

– Cell 1 suitable neighbour E-UTRA Cell 1 is off.

UE:

None.

Preamble:

The UE is in state Generic RB Established, UE test mode activated (state 4) according to [18] using the UE TEST LOOP MODE B and then moved to GPRS packet idle state with PDP context 2 activated State according to [23], on Cell 24.

13.4.2.6.3.2 Test procedure sequence

Table 13.4.2.6.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.6.3.2-1: Time instances of cell power level and parameter changes for E-UTRA cell

Parameter	Unit	Cell 1	Remark
Cell-specific RS EPRE	dBm/15kHz	-70
Srxlev*	dB	36
Note: Srxlev is calculated in the UE

Table 13.4.2.6.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
St	Procedure	U – S	Message	TP	Verdict
1	UE is brought into downlink packet transfer mode according to TS 51.010 clause 40.4.3.14 Note: The delay timer for the Test Loop in the preamble is set so that the UE would not loop any packets back before the UE camps on E-UTRA	–	–	–	–
2	SS transmits 1 IP Packet	–	–	–	–
–	EXCEPTION: In parallel to steps 3 to 5 the events described in Table 13.4.2.6.3.2-3 take place	–	–	–	–
3	SS adjusts power level for Cell 1 according to table 13.4.2.6.3.2-1	–	–	–	–
4	The SS transmits PS HANDOVER COMMAND on Cell24	<–	PS HANDOVER COMMAND	–	–
5	Check: Does the UE transmit a RRCConnectionReconfigurationComplete message on cell 1?	–>	RRCConnectionReconfigurationComplete	1	P
6	The UE transmits a TRACKING AREA UPDATE REQUEST message to update the registration of the actual tracking area.	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE REQUEST	–	–
7	The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security (mapped security context)	<–	RRC: DLInformationTransfer NAS: SECURITY MODE COMMAND	–	–
8	The UE transmits a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration.	–>	RRC: ULInformationTransfer NAS: SECURITY MODE COMPLETE	–	–
9	SS responds with TRACKING AREA UPDATE ACCEPT message.	<–	RRC: DLInformationTransfer NAS: TRACKING AREA UPDATE ACCEPT	–	–
10	Check: Does the UE send a TRACKING AREA UPDATE COMPLETE on the cell specified in the test case?	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE COMPLETE	–	–
11	The SS transmits an RRCConnectionRelease message to release RRC connection and move to RRC_IDLE.	<–	RRC: RRCConnectionRelease	–	–
12	Check: Does the UE loop back the IP packets received when on GERAN on the DRB associated with the default EPS bearer context?	–>	IP Packet	1	P

Table 13.4.2.6.3.2-3: Parallel behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is in downlink packet transfer mode and transmits 3 IP Packets	–	–	–	–

13.4.2.6.3.3 Specific message or IE contents

Table 13.4.2.6.3.3-1: PS HANDOVER COMMAND [Table 13.4.2.6.3.2-1, Step 5]

Derivation Path: 44.060, Table 11.2.43.1
Information Element	Value/remark	Comment	Condition
PAGE MODE	‘00’B	Normal Paging
Global TFI	TFI of the downlink TBF
CONTAINER_ID	0
PS Handover to E-UTRAN Payload	‘10’B
RRC Container IE
RRC_CONTAINER_LENGTH	Length of the container data
RRC_CONTAINER_DATA
RRCConnectionReconfiguration message			HO-TO-EUTRA
RRCConnectionReconfiguration ::= SEQUENCE {			Derivation Path: 36.331 clause 6.2.2
rrc-TransactionIdentifier	RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
rrcConnectionReconfiguration-r8 SEQUENCE {
measConfig	Not present
mobilityControlInfo	MobilityControlInfo		HO-TO-EUTRA Ref Table 13.4.2.6.3.3-2
dedicatedInfoNASList	Not present
radioResourceConfigDedicated	RadioResourceConfigDedicated-HO-TO-EUTRA(n, m)		HO-TO-EUTRA(n,m)
securityConfigHO	SecurityConfigHO		HO-TO-EUTRA Ref Table 13.4.2.6.3.3-3
nonCriticalExtension SEQUENCE {}	Not present
}
}
}
}

Table 13.4.2.6.3.3-2: MobilityControlInfo (Table 13.4.2.6.3.3-1)

Derivation Path: 36.508, Table 4.6.5-1
Information Element	Value/remark	Comment	Condition
MobilityControlInfo
targetPhysCellId	PhysicalCellIdentity of Cell 1.
carrierFreq
dl-CarrierFreq	Same downlink EARFCN as used for Cell 1.
ul-CarrierFreq	Not present
	Same uplink EARFCN as used for Cell 1.		Band 24 High range
carrierFreq	Not present		Band > 64
carrierBandwidth
dl-Bandwidth	Downlink system bandwidth under test.
ul-Bandwidth	Uplink Bandwidth under test.		FDD
ul-Bandwidth	Not present		TDD
additionalSpectrumEmission	1
carrierFreq-v9e0			Band > 64
dl-CarrierFreq-v9e0	Same downlink EARFCN as used for Cell 1

Condition	Explanation
FDD	FDD cell environment
TDD	TDD cell environment
Band > 64	If band > 64 is selected
Band 24 High range	If Band 24 high frequency range is selected for the target cell

Table 13.4.2.6.3.3-3: SecurityConfigHO (Table 13.4.2.6.3.3-1)

Derivation Path: 36.508, Table 4.6.4-1
Information Element	Value/remark	Comment	Condition
SecurityConfigHO
handoverType
interRAT
securityAlgorithmConfig
cipheringAlgorithm	Set according to PIXIT parameter for default ciphering protection algorithm
integrityProtAlgorithm	Set according to PIXIT parameter for default integrity algorithm
nas-SecurityParamToEUTRA	Octets 1 to 4 are arbitrarily selected. Bits 1 to 3 of octet 5 are set according to PIXIT parameter for default integrity protection algorithm. Bits 5 to 7 of octet 5 are set according to PIXIT parameter for default ciphering algorithm. Bits 1 to 3 of octet 6 are arbitrarily selected between ‘000’B and ‘110’B, different from the valid NAS key set identifier of the UE if such a value exists. Bit 4 of octet 6 is set to 1.	Octets 1 to 4 include the NonceMME value. Bits 1 to 3 of octet 5 include the Type of integrity protection algorithm Bits 5 to 7 of octet 5 include the Type of ciphering algorithm. Bits 1 to 4 of octet 6 include the NAS key set identifier.

Table 13.4.2.6.3.3-3: ACTIVATE TEST MODE (preamble, Table 13.4.2.6.3.2-2)

Derivation Path: 36.508, Table 4.7A-1, condition UE TEST LOOP MODE B

Table 13.4.2.6.3.3-4: CLOSE UE TEST LOOP (preamble, Table 13.4.2.6.3.2-2)

Derivation Path: 36.508, Table 4.7A-3, condition UE TEST LOOP MODE B
Information Element	Value/remark	Comment	Condition
UE test loop mode B LB setup
IP PDU delay	0 0 0 0 0 1 0 1	5 seconds

Table 13.4.2.6.3.3-5: Message ROUTING AREA UPDATE ACCEPT (Preamble)

Derivation Path: Table 4.7B.2-2/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
PDP context status	Same value as the one received in the RAU request message

13.4.2.7 Inter-RAT PS Handover / Synchronised / From GPRS Packet_transfer to E-UTRA cell (CCN mode)

13.4.2.7.1 Test Purpose (TP)

(1)

with { UE in GPRS Registered state with active packet data transfer in NC1 mode }

ensure that {

when { UE enters CCN mode by transmitting Packet Cell Change Notification message and subsequently receives PS HANDOVER COMMAND message configured for already synchronised Target EUTRAN Cell,indicating CCN support}

then { UE performs Tracking Area update on EUTRAN cell and continues data transfer }

}

13.4.2.7.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 43.129, clause 5.3a, TS 44.060, clause 5.5.1.1a.2 and TS 45.008, clause 10.1.4.

[TS 43.129, clause 5.3a.1]

For performing the inter-RAT handover from GERAN A/Gb mode to E-UTRAN the pre-conditions are:

– The MS is in packet transfer mode (GERAN A/Gb mode);

– The MS has at least one PDP Context established;

– The BSS supports PFM (Packet Flow Management) procedures.

[TS 43.129, clause 5.3a.2]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.2.

[TS 43.129, clause 5.3a.3]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.3.

[TS 44.060, section 5.5.1.1a.2]

A mobile station, which has CCN Enabled, can enter CCN Mode.

The mobile station shall enable CCN when the following criteria are fulfilled:

– the mobile station is camping on a cell (see 3GPP TS 45.008); and

– the network indicates CCN ACTIVE/3G CCN ACTIVE/E-UTRAN CCN ACTIVE either in system information to all mobile stations in the cell or in an individual order to a certain mobile station; and

– the mobile station is neither in dedicated mode nor Dual Transfer Mode; and

– the mobile station is in NC0 or in NC1 mode; and

– the mobile station is in Packet Transfer mode.

The CCN procedures and the criteria for entering and leaving CCN mode are specified in sub-clauses 8.8.2 and 8.8.3.

[TS 45.008, clause 10.1.4]

The network may request measurement reports from the MS and control its cell re‑selection. This is indicated by the parameter NETWORK_CONTROL_ORDER. The meaning of the different parameter values is specified as follows:

…

NC1 MS control with measurement reports
The MS shall send measurement reports to the network as defined in subclause 10.1.4.1.
The MS shall perform autonomous cell re-selection.

13.4.2.7.3 Test description

13.4.2.7.3.1 Pre-test conditions

System Simulator:

– 2 cells, one GSM and one E-UTRA cell:

– Cell 24 GSM serving cell

– Cell 1 is suitable neighbour E-UTRAN Cell

UE:

None.

Preamble:

The UE is in state Generic RB Established, UE test mode activated (state 4) according to [18] using the UE TEST LOOP MODE B and then moved to GPRS packet idle state with PDP context 2 activated State according to [23], on Cell 24.

13.4.2.7.3.2 Test procedure sequence

Table 13.4.2.7.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.7.3.2-1: Time instances of cell power level and parameter changes for E-UTRA cell

	Parameter	Unit	Cell 1	Cell24	Remark
T1	Cell-specific RS EPRE	dBm/15kHz	-60	No change	The power level is such that SrxlevCell 1 > 0
Note: Srxlev is calculated in the UE

Table 13.4.2.7.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
St	Procedure	U – S	Message	TP	Verdict
1	UE is brought into downlink packet transfer mode according to TS 51.010 clause 40.4.3.14 Note: The delay timer for the Test Loop in the preamble is set so that the UE would not loop any packets back before the UE camps on E-UTRA	–	–	–	–
2	SS transmits 1 IP Packet	–	–	–	–
–	EXCEPTION: In parallel to steps 3 to 7 the events described in Table 13.4.2.7.3.2-3 take place	–	–	–	–
3	UE continues data transfer and send measurement reports for cell 1 in PACKET MEASUREMENT REPORT in parallel to data transfer.	–	–	–	–
4	SS adjusts power level for Cell 1 according to table 13.4.2.7.3.2-1	–	–	–	–
5	UE transmits PACKET CELL CHANGE NOTIFICATION to E_UTRA cell on cell 24. PCCN message should be received with in 15 s after step 3. In parallel the UE continues data transfer and send measurement reports for cell 1 in PACKET MEASUREMENT REPORT.	–>	PACKET CELL CHANGE NOTIFICATION	–	–
6	The SS transmits PS HANDOVER COMMAND on Cell24, with CCN enabled towards target cell.	<–	PS HANDOVER COMMAND	–	–
7	Check: Does the UE transmit a RRCConnectionReconfigurationComplete message on cell 1?	–>	RRCConnectionReconfigurationComplete	1	P
8	The UE transmits a TRACKING AREA UPDATE REQUEST message to update the registration of the actual tracking area.	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE REQUEST	–	–
9	The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security (mapped security context)	<–	RRC: DLInformationTransfer NAS: SECURITY MODE COMMAND	–	–
10	The UE transmits a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration.	–>	RRC: ULInformationTransfer NAS: SECURITY MODE COMPLETE	–	–
11	SS responds with TRACKING AREA UPDATE ACCEPT message.	<–	RRC: DLInformationTransfer NAS: TRACKING AREA UPDATE ACCEPT	–	–
12	Check: Does the UE send a TRACKING AREA UPDATE COMPLETE on the cell specified in the test case?	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE COMPLETE	–	–
13	The SS transmits an RRCConnectionRelease message to release RRC connection and move to RRC_IDLE.	<–	RRC: RRCConnectionRelease	–	–
14	Check: Does the UE loop back the IP packets received when on GERAN on the DRB associated with the default EPS bearer context?	–>	IP Packet	1	P

Table 13.4.2.7.3.2-3: Parallel behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is in downlink packet transfer mode and transmits 3 IP Packets	–	–	–	–

13.4.2.7.3.3 Specific message or IE contents

Table 13.4.2.7.3.3-1: Repeated E-UTRAN Neighbour Cells structure of SI2Quater for Cell 24[Preamble]

Derivation Path: 36.508 table 4.4.5-1
Information Element	Value/remark	Comment	Condition
E-UTRAN Parameters Description	1	Present
E-UTRAN_CCN_ACTIVE	1	CCN is enabled in the cell

Table 13.4.2.7.3.3-2: Message ROUTING AREA UPDATE REQUEST(Preamble)

Derivation Path: Table 4.7B.2-1/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
MS Radio Access capability
GERAN to E-UTRA support in GERAN packet transfer mode	‘11’B	PS Handover to E-UTRAN supported

Table 13.4.2.7.3.3-3: PS HANDOVER COMMAND [Table 13.4.2.7.3.2-2, Step 5]

Derivation Path: 44.060, Table 11.2.43.1
Information Element	Value/remark	Comment	Condition
PAGE MODE	‘00’B	Normal Paging
Global TFI	TFI of the downlink TBF
CONTAINER_ID	0
PS Handover to E-UTRAN Payload	‘10’B
RRC Container IE
RRC_CONTAINER_LENGTH	Length of the container data
RRC_CONTAINER_DATA
RRCConnectionReconfiguration message			HO-TO-EUTRA
RRCConnectionReconfiguration ::= SEQUENCE {			Derivation Path: 36.331 clause 6.2.2
rrc-TransactionIdentifier	RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
rrcConnectionReconfiguration-r8 SEQUENCE {
measConfig	Not present
mobilityControlInfo	MobilityControlInfo		HO-TO-EUTRA Ref Table 13.4.2.7.3.3-4
dedicatedInfoNASList	Not present
radioResourceConfigDedicated	RadioResourceConfigDedicated-HO-TO-EUTRA(n, m)		HO-TO-EUTRA(n,m)
securityConfigHO	SecurityConfigHO		HO-TO-EUTRA Ref Table 13.4.2.7.3.3-5
nonCriticalExtension SEQUENCE {}	Not present
}
}
}
}

Table 13.4.2.7.3.3-4: MobilityControlInfo (Table 13.4.2.7.3.3-3)

Derivation Path: 36.508, Table 4.6.5-1
Information Element	Value/remark	Comment	Condition
MobilityControlInfo
targetPhysCellId	PhysicalCellIdentity of Cell 1.
carrierFreq
dl-CarrierFreq	Same downlink EARFCN as used for Cell 1.
ul-CarrierFreq	Not present
	Same uplink EARFCN as used for Cell 1.		Band 24 High range
carrierFreq	Not present		Band > 64
carrierBandwidth
dl-Bandwidth	Downlink system bandwidth under test.
ul-Bandwidth	Uplink Bandwidth under test.		FDD
ul-Bandwidth	Not present		TDD
additionalSpectrumEmission	1
carrierFreq-v9e0			Band > 64
dl-CarrierFreq-v9e0	Same downlink EARFCN as used for Cell 1

Condition	Explanation
FDD	FDD cell environment
TDD	TDD cell environment
Band > 64	If band > 64 is selected
Band 24 High range	If Band 24 high frequency range is selected for the target cell

Table 13.4.2.7.3.3-5: SecurityConfigHO (Table 13.4.2.7.3.3-3)

Derivation Path: 36.508, Table 4.6.4-1
Information Element	Value/remark	Comment	Condition
SecurityConfigHO
handoverType
interRAT
securityAlgorithmConfig
cipheringAlgorithm	Set according to PIXIT parameter for default ciphering protection algorithm
integrityProtAlgorithm	Set according to PIXIT parameter for default integrity algorithm
nas-SecurityParamToEUTRA	Octets 1 to 4 are arbitrarily selected. Bits 1 to 3 of octet 5 are set according to PIXIT parameter for default integrity protection algorithm. Bits 5 to 7 of octet 5 are set according to PIXIT parameter for default ciphering algorithm. Bits 1 to 3 of octet 6 are arbitrarily selected between ‘000’B and ‘110’B, different from the valid NAS key set identifier of the UE if such a value exists. Bit 4 of octet 6 is set to 1.	Octets 1 to 4 include the NonceMME value. Bits 1 to 3 of octet 5 include the Type of integrity protection algorithm Bits 5 to 7 of octet 5 include the Type of ciphering algorithm. Bits 1 to 4 of octet 6 include the NAS key set identifier.

Table 13.4.2.7.3.3-6: ACTIVATE TEST MODE (preamble, Table 13.4.2.7.3.2-2)

Derivation Path: 36.508, Table 4.7A-1, condition UE TEST LOOP MODE B

Table 13.4.2.7.3.3-7: CLOSE UE TEST LOOP (preamble, Table 13.4.2.7.3.2-2)

Derivation Path: 36.508, Table 4.7A-3, condition UE TEST LOOP MODE B
Information Element	Value/remark	Comment	Condition
UE test loop mode B LB setup
IP PDU delay	0 0 0 0 0 1 0 1	5 seconds

Table 13.4.2.7.3.3-8: Message ROUTING AREA UPDATE ACCEPT (Preamble)

Derivation Path: Table 4.7B.2-2/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
PDP context status	Same value as the one received in the RAU request message

13.4.2.8 Inter-RAT PS Handover / Synchronised / From GPRS Packet_transfer to E-UTRA cell (NC2 mode)

13.4.2.8.1 Test Purpose (TP)

(1)

with { UE in GPRS Registered state with active packet data transfer in NC2 mode }

ensure that {

when { UE receives a PS HANDOVER COMMAND message configured for already synchronised EUTRAN Cell }

then { UE performs Tracking Area update on EUTRAN cell and continues data transfer }

}

13.4.2.8.2 Conformance requirements

References: The conformance requirements covered in the current TC are specified in: TS 43.129, clause 5.3a and TS 45.008 clause 10.1.4.

[TS 43.129, clause 5.3a.1]

For performing the inter-RAT handover from GERAN A/Gb mode to E-UTRAN the pre-conditions are:

– The MS is in packet transfer mode (GERAN A/Gb mode);

– The MS has at least one PDP Context established;

– The BSS supports PFM (Packet Flow Management) procedures.

[TS 43.129, clause 5.3a.2]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.2.

[TS 43.129, clause 5.3a.3]

The detailed signalling flows are specified in 3GPP TS 23.401 [33] in sub-clause 5.5.2.4.3.

[TS 45.008, clause 10.1.4]

…

NC2 Network control
The MS shall send measurement reports to the network as defined in subclause 10.1.4.1.
The MS shall only perform autonomous cell re-selection when the reselection is triggered by a downlink signalling failure as defined in subclause 6.5 or a random access failure as defined in 3GPP TS 44.018 and 3GPP TS 44.060 or if the cell is barred or the C1 criterion falls below zero. The MS shall only determine whether the cell is barred once camped on the cell.

13.4.2.8.3 Test description

13.4.2.8.3.1 Pre-test conditions

System Simulator:

– 2 cells, one GSM and one E-UTRA cell:

– Cell 24 GSM serving cell

– Cell 1 suitable neighbour E-UTRA Cell 1.

UE:

None.

Preamble:

– The UE is in state Generic RB Established, UE test mode activated (state 4) according to [18] using the UE TEST LOOP MODE B and then moved to GPRS packet idle state with PDP context 2 activated State according to [23], on Cell 24.

13.4.2.8.3.2 Test procedure sequence

Table 13.4.2.8.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at various time instants of the test execution. The exact instants on which these values shall be applied are described in the texts in this clause.

Table 13.4.2.8.3.2-1: Time instances of cell power level and parameter changes for E-UTRA cell

	Parameter	Unit	Cell 1	Cell24	Remark
T1	Cell-specific RS EPRE	dBm/15kHz	-60	No change	The power level is such that SrxlevCell 1 > 0
Note: Srxlev is calculated in the UE

Table 13.4.2.8.3.2-2: Main behaviour

St	Procedure	Message Sequence		TP	Verdict
St	Procedure	U – S	Message	TP	Verdict
1	UE is brought into downlink packet transfer mode according to TS 51.010 clause 40.4.3.14 Note: The delay timer for the Test Loop in the preamble is set so that the UE would not loop any packets back before the UE camps on E-UTRA	–	–	–	–
2	SS transmits 1 IP Packet	–	–	–	–
–	EXCEPTION: In parallel to steps 3 to 6 the events described in Table 13.4.2.8.3.2-3 take place	–	–	–	–
3	MS continues data transfer and send measurement reports for cell 1 in PACKET MEASUREMENT REPORT in parallel to data transfer.	–	–	–	–
4	SS adjusts power level for Cell 1 according to table 13.4.2.8.3.2-1	–	–	–	–
5	The SS transmits PS HANDOVER COMMAND on Cell24	<–	PS HANDOVER COMMAND	–	–
6	Check: Does the UE transmit a RRCConnectionReconfigurationComplete message on cell 1?	–>	RRCConnectionReconfigurationComplete	1	P
7	The UE transmits a TRACKING AREA UPDATE REQUEST message to update the registration of the actual tracking area.	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE REQUEST	–	–
8	The SS transmits a NAS SECURITY MODE COMMAND message to activate NAS security (mapped security context)	<–	RRC: DLInformationTransfer NAS: SECURITY MODE COMMAND	–	–
9	The UE transmits a NAS SECURITY MODE COMPLETE message and establishes the initial security configuration.	–>	RRC: ULInformationTransfer NAS: SECURITY MODE COMPLETE	–	–
10	SS responds with TRACKING AREA UPDATE ACCEPT message.	<–	RRC: DLInformationTransfer NAS: TRACKING AREA UPDATE ACCEPT	–	–
11	Check: Does the UE send a TRACKING AREA UPDATE COMPLETE on the cell specified in the test case?	–>	RRC: ULInformationTransfer NAS: TRACKING AREA UPDATE COMPLETE	–	–
12	The SS transmits an RRCConnectionRelease message to release RRC connection and move to RRC_IDLE.	<–	RRC: RRCConnectionRelease	–	–
13	Check: Does the UE loop back the IP packets received when on GERAN on the DRB associated with the default EPS bearer context?	–>	IP Packet	1	P

Table 13.4.2.8.3.2-3: Parallel behaviour

St	Procedure	Message Sequence		TP	Verdict
		U – S	Message
1	UE is in downlink packet transfer mode and transmits 3 IP Packets	–	–	–	–

13.4.2.8.3.3 Specific message or IE contents

Table 13.4.2.8.3.3-1: Message ROUTING AREA UPDATE REQUEST (Preamble)

Derivation Path: Table 4.7B.2-1/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
MS Radio Access capability
GERAN to E-UTRA support in GERAN packet transfer mode	‘11’B	PS Handover to E-UTRAN supported

Table 13.4.2.8.3.3-2: PS HANDOVER COMMAND [Table 13.4.2.8.3.2-2, Step 5]

Derivation Path: 44.060, Table 11.2.43.1
Information Element	Value/remark	Comment	Condition
PAGE MODE	‘00’B	Normal Paging
Global TFI	TFI of the downlink TBF
CONTAINER_ID	0
PS Handover to E-UTRAN Payload	‘10’B
RRC Container IE
RRC_CONTAINER_LENGTH	Length of the container data
RRC_CONTAINER_DATA
RRCConnectionReconfiguration message			HO-TO-EUTRA
RRCConnectionReconfiguration ::= SEQUENCE {			Derivation Path: 36.331 clause 6.2.2
rrc-TransactionIdentifier	RRC-TransactionIdentifier-DL
criticalExtensions CHOICE {
c1 CHOICE{
rrcConnectionReconfiguration-r8 SEQUENCE {
measConfig	Not present
mobilityControlInfo	MobilityControlInfo		HO-TO-EUTRA Ref Table 13.4.2.8.3.3-3
dedicatedInfoNASList	Not present
radioResourceConfigDedicated	RadioResourceConfigDedicated-HO-TO-EUTRA(n, m)		HO-TO-EUTRA(n,m)
securityConfigHO	SecurityConfigHO		HO-TO-EUTRA Ref Table 13.4.2.8.3.3-4
nonCriticalExtension SEQUENCE {}	Not present
}
}
}
}

Table 13.4.2.8.3.3-3: MobilityControlInfo (Table 13.4.2.8.3.3-2)

Derivation Path: 36.508, Table 4.6.5-1
Information Element	Value/remark	Comment	Condition
MobilityControlInfo
targetPhysCellId	PhysicalCellIdentity of Cell 1.
carrierFreq
dl-CarrierFreq	Same downlink EARFCN as used for Cell 1.
ul-CarrierFreq	Not present
	Same uplink EARFCN as used for Cell 1.		Band 24 High range
carrierFreq	Not present		Band > 64
carrierBandwidth
dl-Bandwidth	Downlink system bandwidth under test.
ul-Bandwidth	Uplink Bandwidth under test.		FDD
ul-Bandwidth	Not present		TDD
additionalSpectrumEmission	1
carrierFreq-v9e0			Band > 64
dl-CarrierFreq-v9e0	Same downlink EARFCN as used for Cell 1

Condition	Explanation
FDD	FDD cell environment
TDD	TDD cell environment
Band > 64	If band > 64 is selected
Band 24 High range	If Band 24 high frequency range is selected for the target cell

Table 13.4.2.8.3.3-4: SecurityConfigHO (Table 13.4.2.8.3.3-2)

Derivation Path: 36.508, Table 4.6.4-1
Information Element	Value/remark	Comment	Condition
SecurityConfigHO
handoverType
interRAT
securityAlgorithmConfig
cipheringAlgorithm	Set according to PIXIT parameter for default ciphering protection algorithm
integrityProtAlgorithm	Set according to PIXIT parameter for default integrity algorithm
nas-SecurityParamToEUTRA	Octets 1 to 4 are arbitrarily selected. Bits 1 to 3 of octet 5 are set according to PIXIT parameter for default integrity protection algorithm. Bits 5 to 7 of octet 5 are set according to PIXIT parameter for default ciphering algorithm. Bits 1 to 3 of octet 6 are arbitrarily selected between ‘000’B and ‘110’B, different from the valid NAS key set identifier of the UE if such a value exists. Bit 4 of octet 6 is set to 1.	Octets 1 to 4 include the NonceMME value. Bits 1 to 3 of octet 5 include the Type of integrity protection algorithm Bits 5 to 7 of octet 5 include the Type of ciphering algorithm. Bits 1 to 4 of octet 6 include the NAS key set identifier.

Table 13.4.2.8.3.3-5: ACTIVATE TEST MODE (preamble, Table 13.4.2.8.3.2-2)

Derivation Path: 36.508, Table 4.7A-1, condition UE TEST LOOP MODE B

Table 13.4.2.8.3.3-6: CLOSE UE TEST LOOP (preamble, Table 13.4.2.8.3.2-2)

Derivation Path: 36.508, Table 4.7A-3, condition UE TEST LOOP MODE B
Information Element	Value/remark	Comment	Condition
UE test loop mode B LB setup
IP PDU delay	0 0 0 0 0 1 0 1	5 seconds

Table 13.4.2.8.3.3-7: Message ROUTING AREA UPDATE ACCEPT (Preamble)

Derivation Path: Table 4.7B.2-2/3GPP TS 36.508
Information Element	Value/remark	Comment	Condition
PDP context status	Same value as the one received in the RAU request message