8.7 Relocation Resource Allocation

25.4133GPPRelease 17TSUTRAN Iu interface Radio Access Network Application Part (RANAP) signalling

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

8.7.1 General

The purpose of the Relocation Resource Allocation procedure is to allocate resources from a target RNS for a relocation of SRNS. The procedure shall be co-ordinated over all Iu signalling connections existing for the UE. The procedure uses connection oriented signalling.

NOTE: In case of SRVCC operation, the procedure shall be co-ordinated in the domains which the source RNC decides to involve in the SRVCC operation.

8.7.2 Successful Operation

Figure 7: Relocation Resource Allocation procedure. Successful operation.

The CN initiates the procedure by generating a RELOCATION REQUEST message. In a UTRAN to UTRAN relocation, the message shall contain the information (if any) required by the UTRAN to build at least the same set of RABs as existing for the UE before the relocation, except the relocation due to SRVCC operation. The CN may indicate that RAB QoS negotiation is allowed for certain RAB parameters and in some cases also which alternative values to be used in the negotiation.

The RELOCATION REQUEST message may also include an alternative RAB configuration for a RAB specified in the Alternative RAB configuration IE in the Alternative RAB Parameter Values IE. If Alternative RAB configuration IE for a RAB is included in the RELOCATION REQUEST message, the target RNC is allowed after the successful relocation to request the CN to trigger the execution of this alternative RAB configuration. No negotiation is allowed during the Relocation Resource Allocation procedure between the requested RAB configuration and this alternative RAB configuration.

When the CN transmits the RELOCATION REQUEST message, it shall start the timer T_RELOCalloc.

When a RELOCATION REQUEST message is sent from a CN node towards an RNC for which the sending CN node is not the default CN node, the Global CN-ID IE shall be included.

Upon reception of the RELOCATION REQUEST message, the target RNC shall initiate allocation of requested resources.

The RELOCATION REQUEST message shall contain the following IEs:

– Permanent NAS UE Identity IE (if available);

– Cause IE;

– CN Domain Indicator IE;

– Source RNC To Target RNC Transparent Container IE;

– Iu Signalling Connection Identifier IE;

– Integrity Protection Information IE (if available);

– SNA Access Information IE (if available);

– UESBI-Iu IE (if available);

– Selected PLMN identity IE if in MOCN or GWCN configuration;

– CN MBMS Linking Information IE (if available);

– UE Aggregate Maximum Bit Rate IE (if available);

– Anchor PLMN Identity IE (if available).

For each RAB requested to relocate (or to be created e.g. in the case of inter-system handover), the message shall contain the following IEs:

– RAB-ID IE;

– NAS Synchronisation Indicator IE (if the relevant NAS information is provided by the CN);

– RAB parameters IE;

– User Plane Information IE;

– Transport Layer Address IE;

– Iu Transport Association IE;

– Data Volume Reporting Indication IE (only for PS);

– PDP Type Information IE (only for PS).

The RELOCATION REQUEST message may include the following IE:

– Encryption Information IE (shall not be included if the Integrity Protection Information IE is not included);

– CSG Membership Status IE (shall be included in cases of relocation of CSG capable UEs to hybrid cells);

PDP Type Information extension IE (may be included if PDP Type Information IE is included).

For each RAB requested to relocate the message may include the following IEs:

– Service Handover IE;

– Alternative RAB Parameter Values IE;

– E-UTRAN Service Handover IE.

The following information elements received in RELOCATION REQUEST message require the same special actions in the RNC as specified for the same IEs in the RAB Assignment procedure:

– RAB-ID IE;

– User plane Information IE (i.e. required User Plane Mode and required User Plane Versions);

– Priority level IE, Pre-emption Capability IE and Pre-emption Vulnerability IE;

– Service Handover IE;

– E-UTRAN Service Handover IE.

The SDU Format Information Parameter IE in the RAB Parameters IE shall be present only if the User Plane Mode IE is set to "support mode for pre-defined SDU sizes" and the Traffic Class IE is set to either "Conversational" or "Streaming".

For a RAB setup, the RAB Parameters IE may contain the Signalling Indication IE. The Signalling Indication IE shall not be present if the Traffic Class IE is not set to "Interactive" or if the CN Domain Indicator IE is not set to "PS domain".

If the RELOCATION REQUEST message includes the Permanent NAS UE identity (i.e. IMSI), the RNC shall associate the permanent identity to the RRC Connection of that user and shall save it for the duration of the RRC connection.

If the RELOCATION REQUEST message includes the PDP Type Information IE or PDP Type Information extension IE, the UTRAN may use this IE to configure any compression algorithms.

If the CSG Id IE is received in the RELOCATION REQUEST message, the UTRAN shall validate it by comparing it with the CSG ID broadcast by the target cell. If it is valid and if the CSG Membership Status IE is received set to "member", the target RNC may apply appropriate handling to the UE.

If the CSG Membership Status IE and the CSG Id IE are received in the RELOCATION REQUEST message and the CSG Id does not correspond to the CSG Id broadcast by the target cell, the RNC may provide the QoS to the UE as for a non member and shall send back in the RELOCATION REQUEST ACKNOWLEDGE message the actual CSG Id broadcast by the target cell.

If the target RNC receives the CSG Id IE and the CSG Membership Status IE is set to "non-member" in the RELOCATION REQUEST message and the target cell is a CSG cell and at least one of the RABs has some particular ARP values (see TS 23.060 [21]) the RNC shall send back the RELOCATION REQUEST ACKNOWLEDGE to the CN accepting those RABs and failing the other RABs,

The Cause IE shall contain the same value as the one received in the related RELOCATION REQUIRED message.

The Iu Signalling Connection Identifier IE contains an Iu signalling connection identifier which is allocated by the CN. The value for the Iu Signalling Connection Identifier IE shall be allocated so as to uniquely identify an Iu signalling connection for the involved CN node. The RNC shall store and remember this identifier for the duration of the Iu connection.

The RNC shall, if supported, use the UESBI-Iu IE when included in the RELOCATION REQUEST message. If UESBI-Iu IE contains an IMEISV the RNC may use this information to determine the characteristics of the UE for subsequent handling.

If the CN MBMS Linking Information IE is included in the RELOCATION REQUEST message, the RNC shall, if supported, use the CN MBMS Linking Information IE to perform suitable UE linking as described in TS 25.346 [42].

The algorithms within the Integrity Protection Information IE and the Encryption Information IE shall be ordered in preferred order with the most preferred first in the list.

The Permitted Encryption Algorithms IE within the Encryption Information IE may contain "no encryption" within an element of its list in order to allow the RNC not to cipher the respective connection. This can be done either by not starting ciphering or by using the UEA0 algorithm. In the absence of the Encryption Information IE, the RNC shall not start ciphering.

The Source To Target Transparent Container IE is encoded as the Source RNC To Target RNC Transparent Container IE. The following applies for the Source RNC To Target RNC Transparent Container IE:

– In case of intra-system relocation, if no Integrity Protection Key IE (Ciphering Key IE respectively) is provided within the Source RNC to Target RNC Transparent Container IE, the target RNC shall not start integrity protection (ciphering respectively).

– In case of intra-system relocation, when an Ciphering Key IE is provided within the Source RNC to Target RNC Transparent Container IE, the target RNC may select to use a ciphering alternative where an algorithm is used. It shall in this case make use of this key to cipher its signalling data whatever the selected algorithm. The Encryption Key IE that is contained within the Encryption Information IE of the RELOCATION REQUEST message shall never be considered for ciphering of signalling data.

– In case of intra-system relocation, when an Integrity Protection Key IE is provided within the Source RNC to Target RNC Transparent Container IE, the target RNC shall select one integrity algorithm to start integrity and shall in this case make use of this key whatever the selected algorithm. The integrity protection key that is contained within the Integrity Protection Information IE of the RELOCATION REQUEST message shall never be considered.

– In case of intra-system relocation, when a Trace Recording Session Information IE is provided within the Source RNC to Target RNC Transparent Container IE, the Target RNC should store that information to include it in a potential future Trace Record for that UE.

– If the Subscriber Profile ID for RAT/Frequency priority IE is contained in the Source RNC to Target RNC Transparent Container IE, the target RNC shall store the received Subscriber Profile ID for RAT/Frequency priority and use it as defined in TS 36.300 [52].

– If the CSFB Information IE is contained in the Source RNC to Target RNC Transparent Container IE, the target RNC may apply special treatment.

– The RELOCATION REQUEST message may contain the Cell Load Group Information IE in the Source RNC to Target RNC Transparent Container IE.

– If the Management Based MDT Allowed IE only or the Management Based MDT Allowed IE and the Management Based MDT PLMN List IE, is contained in the Source RNC to Target RNC Transparent Container IE, the target RNC shall use it, if supported, to allow subsequent selection of the UE for management based MDT as defined in TS 32.422 [38].

– If the Last E-UTRAN PLMN Identity IE is contained in the Source RNC to Target RNC Transparent Container IE, the target RNC may store the received last E-UTRAN PLMN Identity and use it as defined in TS 23.272 [67].

– If the SRVCC Source IE is contained in the Source RNC to Target RNC Transparent Container IE, the target RNC may store and consider that the SRVCC is from 5G to 3G.

In case of inter-system relocation, the integrity protection and ciphering information to be considered shall be the ones received in the Integrity Protection Information IE and Encryption Information IE of the RELOCATION REQUEST message.

The Global CN-ID IE contains the identity of the CN node that sent the RELOCATION REQUEST message, and it shall, if included, be stored together with the Iu signalling connection identifier. If the Global CN-ID IE is not included, the RELOCATION REQUEST message shall be considered as coming from the default CN node for the indicated CN domain.

The following additional actions shall be executed in the target RNC during the Relocation Resource Allocation procedure:

If included in the RELOCATION REQUEST ACKNOWLEDGE message, the Target to Source Transparent Container IE shall be encoded as the Target RNC to Source RNC Transparent Container IE.

If the Relocation Type IE is set to "UE involved in relocation of SRNS":

– except the relocation due to SRVCC operation, the target RNC should not accept a requested RAB if the RAB did not exist in the source RNC before the relocation. In case of SRVCC operation, the target RNC may accept CS RAB even if it did not exist in the source RNC before the relocation.

– The target RNC may accept a requested RAB only if the RAB can be supported by the target RNC.

– Other RABs shall be rejected by the target RNC in the RELOCATION REQUEST ACKNOWLEDGE message with an appropriate value in the Cause IE, e.g. "Unable to Establish During Relocation".

– The target RNC shall include information adapted to the resulting RAB configuration in the target to source RNC transparent container to be included in the RELOCATION REQUEST ACKNOWLEDGE message sent to the CN. If the target RNC supports triggering of the Relocation Detect procedure via the Iur interface, the RNC shall assign a d-RNTI for the context of the relocation and include it in the container. If two CNs are involved in the relocation of SRNS, the target RNC may, however, decide to send the container to only one CN.

– If d-RNTI for No IuCS UP IE is contained in the RELOCATION REQUEST message, the target RNC shall use this information to configure the resource for the UE over Iur during the relocation.

If the Relocation Type IE is set to "UE not involved in relocation of SRNS":

– The target RNC shall not accept a requested RAB if the RAB did not exist in the source RNC before the relocation.

– The target RNC may accept a RAB only if the radio bearer(s) for the RAB either exist(s) already and can be used for the RAB by the target RNC, or do(es) not exist before the relocation but can be established in order to support the RAB in the target RNC.

– If existing radio bearers are not related to any RAB that is accepted by the target RNC, the radio bearers shall be ignored during the relocation of SRNS and the radio bearers shall be released by the radio interface protocols after completion of relocation of SRNS.

– If any alternative RAB parameter values have been used when allocating the resources, these RAB parameter values shall be included in the RELOCATION REQUEST ACKNOWLEDGE message within the Assigned RAB Parameter Values IE. It should be noted that the usage of alternative RAB parameter values is not applicable to the UTRAN initiated relocation of type "UE not involved in relocation of SRNS".

If the UE History Information IE is included in the RELOCATION REQUEST message and the target RNC is configured to collect the information, the target RNC shall, if supported, collect information defined in the UE History Information IE.

The target RNC shall, if supported, include the UE Application layer measurement configuration supported in the RELOCATION REQUEST ACKNOWLEDGE message sent to the CN. It sets the bitmap to indicate its support for the measureemnt(s) indicated in the UE Application layer measurement configuration for relocation.

After all necessary resources for accepted RABs including the initialised Iu user plane, are successfully allocated, the target RNC shall send a RELOCATION REQUEST ACKNOWLEDGE message to the CN.

For each RAB successfully setup the RNC shall include the following IEs:

– RAB ID

– Transport Layer Address (when no ALCAP has been used)

– Iu Transport Association (when no ALCAP has been used)

Two pairs of Transport Layer Address IE and Iu Transport Association IE may be included for RABs established towards the PS domain.

For each RAB the RNC is not able to setup during the Relocation Resource Allocation procedure, the RNC shall include the RAB ID IE and the Cause IE within the RABs Failed To Setup IE. The resources associated with the RABs indicated as failed to set up shall not be released in the CN until the relocation is completed. This is in order to make a return to the old configuration possible in case of a failed or cancelled relocation.

The RELOCATION REQUEST ACKNOWLEDGE message sent to the CN shall, if applicable and if not sent via the other CN domain, include the Target RNC To Source RNC Transparent Container IE. This container shall be transferred by the CN to the source RNC or the external relocation source while completing the Relocation Preparation procedure.

If the target RNC supports cell load-based inter-system handover, then in the case of inter-system handover, the New BSS to Old BSS Information IE may be included in the RELOCATION REQUEST ACKNOWLEDGE message. This information shall include, if available, the current traffic load in the target cell assuming a successful completion of the handover in progress.

In case of inter-system relocation, the RNC shall include the Chosen Integrity Protection Algorithm IE (Chosen Encryption Algorithm IE respectively) within the RELOCATION REQUEST ACKNOWLEDGE message, if, and only if the Integrity Protection Information IE (Encryption Information IE respectively) was included in the RELOCATION REQUEST message.

In case of intra-system relocation, the RNC shall include the Chosen Integrity Protection Algorithm IE (Chosen Encryption Algorithm IE respectively) within the RELOCATION REQUEST ACKNOWLEDGE message, if, and only if the Integrity Protection Key IE (Ciphering Key IE respectively) was included within the Source RNC-to-Target RNC transparent container IE.

If one or more of the RABs that the target RNC has decided to support cannot be supported by the CN, then these failed RABs shall not be released towards the target RNC until the relocation is completed.

If the NAS Synchronisation Indicator IE is contained in the RELOCATION REQUEST message, the target RNC shall pass it to the UE.

If the SNA Access Information IE is contained in the RELOCATION REQUEST message, the target RNC shall store this information and use it to determine whether the UE has access to radio resources in the UTRAN. The target RNC shall consider that the UE is authorised to access only the PLMNs identified by the PLMN identity IE in the SNA Access Information IE. If the Authorised SNAs IE is included for a given PLMN (identified by the PLMN identity IE), then the target RNC shall consider that the access to radio resources for the concerned UE is restricted to the LAs contained in the SNAs identified by the SNAC IEs.

If the SNA Access Information IE is not contained in the RELOCATION REQUEST message, the target RNC shall consider that no access restriction applies to the UE in the UTRAN.

Transmission and reception of a RELOCATION REQUEST ACKNOWLEDGE message terminate the procedure in the UTRAN and in the CN respectively.

Before reporting the successful outcome of the Relocation Resource allocation procedure, the RNC shall have executed the initialisation of the user plane mode as requested by the CN in the User Plane Mode IE. If the RNC cannot initialise the requested user plane mode for any of the user plane mode versions in the UP Mode Versions IE according to the rules for initialisation of the respective user plane mode versions, as described in TS 25.415 [6], the RAB Relocation shall fail with the cause value "RNC unable to establish all RFCs".

If the Selected PLMN identity IE is contained in the RELOCATION REQUEST message, the target RNC shall use this information to send it to the UE.

If the UE Aggregate Maximum Bit Rate IE is included in the RELOCATION REQUEST message, the UTRAN shall, if supported, store the received UE Aggregate Maximum Bit Rate parameters to control the aggregate data rate of non-GBR traffic for this UE.

In case SIPTO at Iu-PS functionality is supported by the UTRAN, the following applies in addition for the successful operation of the Relocation Resource Allocation procedure:

– If the MSISDN IE is present in the RELOCATION REQUEST message, then the UTRAN may offload the RAB(s) where the Offload RAB Parameters IE is present in the RABs To Be Setup Item IEs IE. The Access Point Name IE and the Charging Characteristics IE within the Offload RAB Parameters IE and the MSISDN IE may only be used for the SIPTO at Iu-PS function and according to the description in TS 23.060 [21].

If the Power Saving Indicator IE is included in the RELOCATION REQUEST message the RNC shall if supported, store this information and use it when determining to send the UE back to the PSM mode if the value is "PSM Configured" or to send the UE back to the eDRX mode in Idle if the value is "eDRX Configured", as defined in TS 23.682 [68].

If the UE Application layer measurement configuration for relocation IE is included in the RELOCATION REQUEST message the RNC shall if supported, store this information and use it for QoE function (see TS 25.300 [72]).

Interactions with Uplink Information Exchange procedure:

In case of UTRAN to UTRAN CS only relocation, if the RELOCATION REQUEST message includes the MBMS Linking Information IE in the Source RNC To Target RNC Transparent Container IE, the RNC shall, if supported, initiate the Uplink Information Exchange procedure to retrieve the Multicast Service list for the UE, create relevant MBMS Service Context, store this information and perform the relevant UE linking as defined in TS 25.346 [42].

8.7.2.1 Successful Operation for GERAN Iu-mode

The relocation between UTRAN and GERAN Iu-mode shall be considered in the Relocation Resource Allocation procedure as intra-system relocation from RANAP point of view.

For GERAN Iu-mode and to support Relocation towards a GERAN BSC in Iu mode the following shall apply in addition for the successful operation of the Relocation Resource Allocation procedure:

– In case of GERAN Iu-mode, for RAB requested to be relocated from the CS domain, the RELOCATION REQUEST message may contain the GERAN BSC Container IE in order to provide GERAN specific information to the target BSC (see TS 43.051 [27]).

8.7.3 Unsuccessful Operation

Figure 8: Relocation Resource Allocation procedure: Unsuccessful operation.

If the target RNC cannot even partially accept the relocation of SRNS or a failure occurs during the Relocation Resource Allocation procedure in the target RNC, the target RNC shall send a RELOCATION FAILURE message to the CN. The RELOCATION FAILURE message shall contain the Cause IE with an appropriate value.

If the target RNC cannot support any of the integrity protection (ciphering respectively) alternatives provided in the Integrity Protection Information IE or Encryption Information IE, it shall return a RELOCATION FAILURE message with the cause "Requested Ciphering and/or Integrity Protection algorithms not supported".

If the target RNC cannot support the relocation due to PUESBINE feature, it shall return a RELOCATION FAILURE message with the cause "Incoming Relocation Not Supported Due To PUESBINE Feature".

If the target RNC does not receive the CSG Membership Status IE but does receive the CSG Id IE in the RELOCATION REQUEST message and the CSG Id IE is not valid, it shall send the RELOCATION FAILURE message to the CN with an appropriate cause value.

If the CSG Id IE is not received in the RELOCATION REQUEST message and the access control for the relocation to a CSG cell is unsuccessful and if none of the RABs has some particular ARP values (see TS 23.060 [21]), the target RNC shall return a RELOCATION FAILURE message with an appropriate cause value, e.g. "Relocation Target not allowed".

Transmission and reception of a RELOCATION FAILURE message terminate the procedure in the UTRAN and in the CN respectively.

When the CN receives a RELOCATION FAILURE message from the target RNC, it shall stop timer T_RELOCallocand shall assume possibly allocated resources within the target RNC completely released.

In case of inter-system handover, and if the target RNC supports cell load-based inter-system handover, then

– the NewBSS to Old BSS Information IE may be included in the RELOCATION FAILURE message. This information shall include, if available, the current traffic load in the target cell.

– the RELOCATION FAILURE message shall contain the Cause IE with an appropriate value, e.g. "No Radio Resources Available in Target Cell" or "Traffic Load In The Target Cell Higher Than In The Source Cell".

– If the Cause IE received in the RELOCATION REQUEST message contains the value "Reduce Load in Serving Cell" and the load in the target cell is greater than in the source cell then, if the target cell is not in a congested or blocked state, the RNC shall return a RELOCATION FAILURE message which may include the cause "Traffic Load In The Target Cell Higher Than In The Source Cell".

– When the RNC returns a RELOCATION FAILURE message with the cause "Traffic Load In The Target Cell Higher Than In The Source Cell", it shall also include the NewBSS to Old BSS Information IE. This information shall include the current traffic load in the target cell.

8.7.3.1 Unsuccessful Operation for GERAN Iu-mode

For GERAN Iu-mode and to support Relocation towards a GERAN BSC in Iu mode the following shall apply in addition for the unsuccessful operation of the Relocation Resource Allocation procedure:

– In case a Relocation to GERAN Iu-mode fails (only for CS), because the Target BSC cannot provide an appropriate RAB corresponding to the content of the GERAN BSC Container IE (if received), the Target BSC shall report the unsuccessful Relocation Resource Allocation by indicating the cause value "GERAN Iu-mode Failure" within the RELOCATION FAILURE message and shall include the GERAN Classmark IE.

8.7.4 Abnormal Conditions

If after reception of the RELOCATION REQUEST message, the target RNC receives another RELOCATION REQUEST message on the same Iu connection, then the target RNC shall discard the latter message and the original Relocation Resource Allocation procedure shall continue normally.

If the target RNC receives a Source RNC to Target RNC Transparent Container IE containing Chosen Integrity Protection (Encryption respectively) Algorithm IE without Integrity Protection (Ciphering respectively) Key IE, it shall return a RELOCATION FAILURE message with the cause "Conflict with already existing Integrity protection and/or Ciphering information".

Interactions with Iu Release procedure:

If the CN decides to not continue the Relocation Resource Allocation procedure (e.g. due to T_RELOCalloc expiry) before the Relocation Resource Allocation procedure is completed, the CN shall stop timer T_RELOCalloc(if timer T_RELOCallochas not already expired) and the CN shall, if the Iu signalling connection has been established or later becomes established, initiate the Iu Release procedure towards the target RNC with an appropriate value for the Cause IE, e.g. "Relocation Cancelled".

NOTE: In case two CN domains are involved in the Relocation Resource Allocation procedure, the target RNC may check whether the content of the two Source RNC to Target RNC Transparent Container IEs or the two SNA Access Information IEs is the same. In case the target RNC receives two different Source RNC to Target RNC Transparent Container IEs or two different SNA Access Information IEs, the RNC behaviour is left implementation specific.

8.7.5 Co-ordination of Two Iu Signalling Connections

Co-ordination of two Iu signalling connections during Relocation Resource Allocation procedure shall be executed by the target RNC when the Number of Iu Instances IE received in the Source RNC to Target RNC Transparent Container IE in the RELOCATION REQUEST message indicates that two CN domains are involved in relocation of SRNS.

When both the CS and PS user data Chosen Encryption Algorithm IE are received within the Source RNC to Target RNC Transparent Container IE and if these two received Chosen Encryption Algorithm IE are not the same, the target RNC shall fail the Relocation Resource Allocation procedure by sending back a RELOCATION FAILURE message.

The integrity protection (ciphering respectively) alternatives provided in the Integrity Protection Information IE (Encryption Information IE respectively) of the RELOCATION REQUEST messages received from both CN domains shall have at least one common alternative, otherwise the Relocation Resource Allocation shall be failed by sending back a RELOCATION FAILURE message.

If two CN domains are involved, the following actions shall be taken by the target RNC:

– The target RNC shall utilise the Permanent NAS UE Identity IE, received explicitly from each CN domain within the RELOCATION REQUEST messages, to co-ordinate both Iu signalling connections.

– The target RNC shall generate and send RELOCATION REQUEST ACKNOWLEDGE messages only after all expected RELOCATION REQUEST messages are received and analysed, except for the case where there is at least one of the RABs that has a particular ARP value (see TS 23.060 [21]).

– In case the SRVCC operation is performed and the source system is E-UTRAN, the target RNC shall generate and send RELOCATION REQUEST ACKNOWLEDGE message to the CN in CS domain if the relocation of SRNS is accepted for the CS domain but not accepted for the PS domain.

– If the relocation is to a target CSG cell where the UE is a non-member of the target CSG, and where there is at least one of the RABs that has a particular ARP value (see TS 23.060 [21]) in one domain, the target RNC shall accept those RABs with a particular ARP value (see TS 23.060 [21]) and fail the other RABs, and send RELOCATION REQUEST ACKNOWLEDGE messages without waiting for the RELOCATION REQUEST message in the other domain.

– If the target RNC decides to send the Target RNC to Source RNC Transparent Container IE via the two CN domains, the target RNC shall ensure that the same Target RNC to Source RNC Transparent Container IE is included in RELOCATION REQUEST ACKNOWLEDGE messages transmitted via the two CN domains and related to the same relocation of SRNS.

If the target RNC receives the UESBI-Iu IE on the Iu-CS but not on the Iu-PS interface (or vice versa), the RNC shall, if supported, use the UESBI-Iu IE for both domains.