8.2 RAB Assignment

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

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

8.2.1 General

The purpose of the RAB Assignment procedure is to establish new RABs and/or to enable modifications and/or releases of already established RABs for a given UE. The procedure uses connection oriented signalling.

8.2.2 Successful Operation

Figure 1: RAB Assignment procedure. Successful operation.

The CN initiates the procedure by sending a RAB ASSIGNMENT REQUEST message. When sending the RAB ASSIGNMENT REQUEST message, the CN shall start the T _RABAssgt timer.

The CN may request the UTRAN to:

– establish,

– modify,

– release

one or several RABs with one RAB ASSIGNMENT REQUEST message.

The CN shall include in the RAB ASSIGNMENT REQUEST message at least one request to either establish/modify or release a RAB.

The message shall contain the information required by the UTRAN to build the new RAB configuration, such as:

– list of RABs to establish or modify with their bearer characteristics;

– list of RABs to release;

– UE Aggregate Maximum Bit Rate (if available).

For each RAB requested to be established, the message shall contain:

– RAB ID;

– NAS Synchronisation Indicator (only when available);

– RAB parameters (including e.g. Allocation/Retention Priority);

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

– Transport Layer Information;

– PDP Type Information (only for PS) or PDP Type Information extension (only for PS);

– Data Volume Reporting Indication (only for PS);

– DL GTP-PDU sequence number (only when GTP-PDU sequence number is available in cases of intersystem change from GPRS to UMTS or when establishing a RAB for an existing PDP context or in some further cases described in TS 23.060 [21]);

– UL GTP-PDU sequence number (only when GTP-PDU sequence number is available in cases of intersystem change from GPRS to UMTS or when establishing a RAB for an existing PDP context or in some further cases described in TS 23.060 [21]);

– DL N-PDU sequence number (only when N-PDU sequence number is available in case of intersystem change from GPRS to UMTS or in some further cases described in TS 23.060 [21]);

– UL N-PDU sequence number (only when N-PDU sequence number is available in case of intersystem change from GPRS to UMTS or in some further cases described in TS 23.060 [21]).

The RAB ASSIGNMENT REQUEST message shall, if supported, include the Correlation ID IE for each RAB established towards a L-GW collocated with the RNC for LIPA operation.

If the SIPTO Correlation ID IE is included in the RAB ASSIGNMENT REQUEST message towards the RNC with L-GW function for SIPTO@LN operation, the RNC shall use it for SIPTO@LN operation for the concerned RAB.

For each RAB requested to be modified, the message may contain:

– RAB ID (mandatory);

– NAS Synchronisation Indicator;

– RAB parameters;

– Transport Layer Information;

– User Plane Information.

If the UE Aggregate Maximum Bit Rate IE is present in the RAB ASSIGNMENT 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.

The Transport Layer Information IE may be present at a RAB modification except in the case when the only other present IE, besides the RAB ID IE, is the NAS Synchronisation Indicator IE.

At a RAB modification that does not include transfer of the NAS Synchronisation Indicator IE, the RAB Parameters IE shall be present in the RAB ASSIGNMENT REQUEST message only when any previously set value for this IE is requested to be modified.

At a RAB modification, the User Plane Information IE shall be present in the RAB ASSIGNMENT REQUEST message only when any previously set value for this IE is requested to be modified.

For a RAB setup, 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 or modification, when the maximum bit rate (respectively the guaranteed bit rate when applicable) to be signalled for the RAB exceeds the maximum value of the Maximum Bit Rate IE (respectively Guaranteed Bit Rate IE), either the Extended Maximum Bit Rate IE (respectively Extended Guaranteed Bit Rate IE) shall be included together with the Maximum Bit Rate IE (respectively Guaranteed Bit Rate IE) set to its maximum value or the Supported Maximum Bit Rate IE (respectively Supported Guaranteed Bit Rate IE) shall be used.

For a RAB setup or modification, if the Extended Maximum Bit Rate IE (respectively Extended Guaranteed Bit Rate IE) is present, the RNC shall consider it and ignore the Maximum Bit Rate IE (respectively Guaranteed Bit Rate IE).

For a RAB if Extended Maximum Bit Rate IE (respectively Extended Guaranteed Bit Rate IE when applicable) is signalled in one direction RNC shall use the Extended Maximum Bit Rate IE (respectively Extended Guaranteed Bit Rate IE) also for the other direction for this RAB. If the Supported Maximum Bit Rate IE (respectively Supported Guaranteed Bit Rate IE) is present, it shall be used in both directions.

For a RAB setup or modification, if the Supported Maximum Bit Rate IE (respectively Supported Guaranteed Bit Rate IE) is present, the RNC shall consider it and ignore the Maximum Bit Rate IE (respectively Guaranteed Bit Rate IE).

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 RAB Parameters IE is present for a RAB modification, the SDU Format Information Parameter IE in the RAB Parameters IE shall be present only if the Traffic Class IE is set to either "Conversational" or "Streaming" and if

– either the User Plane mode is currently "support mode for pre-defined SDU sizes" and the User Plane Mode IE is not contained in the RAB ASSIGNMENT REQUEST message

– or if the User Plane Mode IE optionally contained within the RAB ASSIGNMENT REQUEST message is set to "support mode for pre-defined SDU sizes".

If, for a RAB requested to be modified, one (or more) of these IEs except RAB ID IE are not present in the RAB ASSIGNMENT REQUEST message the RNC shall continue to use the value(s) currently in use for the not present IEs.

If, for a RAB requested to be modified, the Signalling Indication IE is not present and the Traffic Class IE is set to "interactive", this indicates that the signalling nature of the RAB is not changed by the modification.

For each RAB requested to be released, the message shall contain:

– RAB ID;

– Cause.

Upon reception of the RAB ASSIGNMENT REQUEST message, the UTRAN shall execute the requested RAB configuration. 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 in the Alternative RAB parameters values IE.

If some of the alternative maximum bit rates (respectively alternative guaranteed bit rates when applicable) to be signalled for the RAB exceed the maximum value of the Alternative Maximum Bit Rate IE (respectively Alternative Guaranteed Bit Rate IE), they shall be included either in the Extended Alternative Maximum Bit Rate IE (respectively Extended Alternative Guaranteed Bit Rate IE, or in the Supported Alternative Maximum Bit Rate IE (respectively Supported Alternative Guaranteed Bit Rate IE). If the Supported Alternative Maximum Bit Rate IE (respectively Supported Alternative Guaranteed Bit Rate IE) is used it shall be used for all alternative bitrate definitions for the RAB.

For a RAB setup or modification, if the Extended Alternative Maximum Bit Rate IE (respectively Extended Alternative Guaranteed Bit Rate IE) is present, the RNC shall consider these rates together with the bit rates signalled within the Alternative Maximum Bit Rate IE (respectively Alternative Guaranteed Bit Rate IE) if present.

For an entry in the list or for a discrete value if the Extended Alternative Maximum Bit Rate IE (respectively Extended Alternative Guaranteed Bit Rate IE when applicabale) is signalled in one direction RNC shall use the Extended Alternative Maximum Bit Rate IE (respectively Extended Alternative Guaranteed Bit Rate IE) also for the other direction of this entry or discrete value. If the Supported Alternative Maximum Bit Rate IE (respectively Supported Alternative Guaranteed Bit Rate IE) is present it shall be used in both directions for all entries in the list or discrete values.

For a RAB setup or RAB requested to be modified, the RAB ASSIGNMENT REQUEST message may also include an alternative RAB configuration 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 RAB ASSIGNMENT REQUEST message, the RNC is allowed after the successful RAB setup or RAB modification to request the CN to trigger the execution of this alternative RAB configuration. No negotiation is allowed during the RAB Assignment procedure between the requested RAB configuration and this alternative RAB configuration.

If the RAB ASSIGNMENT REQUEST message contains a request of a RAB configuration with Extended Maximum Bit Rate IE and/or Extended Guaranteed Bit Rate IE respectively if Supported Maximum Bit Rate IE and/or Supported Guaranteed Bit Rate IE are greater than 16 Mbps in RAB parameters IE, the CN should indicate that RAB QoS negotiation is allowed. If this RAB Configuration is for a UE that is not able to support the requested bit rates according to the Access Stratum Release Indicator IE in TS 25.331 [10]:

– The UTRAN shall, if supported, perform RAB QoS negotiation.

– If RAB QoS negotiation is performed, the RNC shall signal the assigned bit rate indications within the Assigned RAB Parameter Values IE in the following way:

– Extended Assigned Maximum Bit Rate IE and Extended Assigned Guaranteed Bit Rate IE shall not be set in Assigned RAB Parameter Values IE;

– if the Supported Assigned Maximum Bit Rate IE and Supported Assigned Guaranteed Bit Rate IE are used, they shall be set to a value less than or equal to 16 Mbps.

The same RAB ID shall only be present once in the whole RAB ASSIGNMENT REQUEST message.

The RAB ID shall uniquely identify the RAB for the specific CN domain and for the particular UE, which makes the RAB ID unique over the Iu connection on which the RAB ASSIGNMENT REQUEST message is received. When a RAB ID already in use over that particular Iu instance is used, the procedure is considered as modification of that RAB.

The RNC shall pass the contents of the RAB ID IE to the radio interface protocol for each RAB requested to be established or modified.

The RNC shall establish or modify the resources according to the values of the Allocation/Retention Priority IE (priority level, pre-emption indicators, queuing) and the resource situation as follows:

– The RNC shall consider the priority level of the requested RAB, when deciding on the resource allocation.

– If the requested RAB is allowed for queuing and the resource situation requires so, the RNC may place the RAB in the establishment queue.

– The priority levels and the pre-emption indicators may (singularly or in combination) be used to determine whether the RAB assignment has to be performed unconditionally and immediately. If the requested RAB is marked as "may trigger pre-emption" and the resource situation requires so, the RNC may trigger the pre-emption procedure which may then cause the forced release of a lower priority RAB which is marked as "pre-emptable". Whilst the process and the extent of the pre-emption procedure is operator-dependent, the pre-emption indicators, if given in the RAB ASSIGNMENT REQUEST message, shall be treated as follows:

1. The values of the last received Pre-emption Vulnerability IE and Priority Level IE shall prevail.

2. If the Pre-emption Capability IE is set to "may trigger pre-emption", then this allocation request may trigger the pre-emption procedure.

3. If the Pre-emption Capability IE is set to "shall not trigger pre-emption", then this allocation request shall not trigger the pre-emption procedure.

4. If the Pre-emption Vulnerability IE is set to "pre-emptable", then this connection shall be included in the pre-emption process.

5. If the Pre-emption Vulnerability IE is set to "not pre-emptable", then this connection shall not be included in the pre-emption process.

6. If the Priority Level IE is set to "no priority" the given values for the Pre-emption Capability IE and Pre-emption Vulnerability IE shall not be considered. Instead the values "shall not trigger pre-emption" and "not pre-emptable" shall prevail.

– If the Allocation/Retention Priority IE is not given in the RAB ASSIGNMENT REQUEST message, the allocation request shall not trigger the pre-emption process and the connection may be pre-empted and considered to have the value "lowest" as priority level. Moreover, queuing shall not be allowed.

– The UTRAN pre-emption process shall keep the following rules:

1. UTRAN shall only pre‑empt RABs with lower priority, in ascending order of priority.

2. The pre-emption may be done for RABs belonging to the same UE or to other UEs.

If the NAS Synchronisation Indicator IE is contained in the RAB ASSIGNMENT REQUEST message, the RNC shall pass it to the radio interface protocol for transfer to the UE.

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

If included, the Service Handover IE tells if the requested RAB

– should be handed over to GSM, i.e. from a NAS point of view, the requested RAB should be handed over to GSM as soon as possible although the final decision whether to perform a handover to GSM is still made in the UTRAN.

– should not be handed over to GSM, i.e. from a NAS point of view, the requested RAB should remain in UMTS as long as possible although the final decision whether to perform a handover to GSM is still made in the UTRAN.

– shall not be handed over to GSM, i.e. the requested RAB shall never be handed over to GSM. This means that the UTRAN shall not initiate handover to GSM for the UE unless the RABs with this indication have first been released with the normal release procedures.

The value of the Service Handover IE is valid throughout the lifetime of the RAB or until changed by a RAB modification.

The Service Handover IE shall only influence decisions made regarding UTRAN-initiated inter-system handovers.

If the Service Handover IE is not included during RAB Setup and all subsequent RAB Modifications, the decision whether to perform an inter-system handover to GSM is only an internal UTRAN matter.

If included, the E-UTRAN Service Handover IE tells if the requested RAB is allowed to be handed over to E-UTRAN.

If the E-UTRAN service handover function is supported,

– The RNC shall not trigger handover or redirection to E-UTRAN for a UE with a signalling connection only;

– The RNC shall not trigger handover or redirection to E-UTRAN for a UE if all established RABs have E-UTRAN Service Handover IE set to “Handover to E-UTRAN shall not be performed”.

The value of the E-UTRAN Service Handover IE is valid throughout the lifetime of the RAB or until changed by a RAB modification.

If the E-UTRAN Service Handover IE is not included during RAB Setup and all subsequent RAB Modifications, the decision whether to perform an inter-system mobility to E-UTRAN, e.g., handover or redirection, is only an internal UTRAN matter.

The UTRAN shall report to the CN, in the first RAB ASSIGNMENT RESPONSE message, the result for all the requested RABs, such as:

– List of RABs successfully established or modified.

– List of RABs released.

– List of RABs queued.

– List of RABs failed to establish or modify.

– List of RABs failed to release.

The same RAB ID shall only be present once in the whole RAB ASSIGNMENT RESPONSE message.

For each RAB successfully established towards the PS domain or towards the CS domain when an ALCAP is not used, the RNC shall include the Transport Layer Address IE and the Iu Transport Association IE in the RAB ASSIGNMENT RESPONSE message.

For each RAB successfully released towards the PS domain, for which data volume reporting had been requested when the RAB was established, the RNC shall include the DL Data Volumes IE in the RAB ASSIGNMENT RESPONSE message. The DL Data Volumes IE shall contain in the Unsuccessfully Transmitted DL Data Volume IE the total amount of unsuccessfully transmitted DL data for the RAB since its establishment and may contain the Data Volume Reference IE.

For each RAB successfully released towards the PS domain, the RNC shall include in the RAB ASSIGNMENT RESPONSE message the DL GTP-PDU Sequence Number IE and the UL GTP-PDU Sequence Number IE, if available and if the release was initiated by the UTRAN.

The RNC shall report in the RAB ASSIGNMENT RESPONSE message at least one RAB:

– setup/modified or

– released or

– queued or

– failed to setup/modify or

– failed to release.

If any alternative RAB parameter values have been used when establishing or modifying a RAB, these RAB parameter values shall be included in the RAB ASSIGNMENT RESPONSE message within the Assigned RAB Parameter Values IE.

If any alternative RAB parameter values have been used from the Extended Alternative Maximum Bit Rate IE (respectively Extended Alternative Guaranteed Bit Rate IE), these RAB parameter values shall be included in the RAB ASSIGNMENT RESPONSE message within the Extended Assigned Maximum Bit Rate IE (respectively Extended Assigned Guaranteed Bit Rate IE).

For a RAB if the Extended Assigned Maximum Bit Rate IE (respectively Extended Assigned Guaranteed Bit Rate IE when applicable) is signalled in one direction RNC shall signal the Extended Assigned Maximum Bit Rate IE (respectively Extended Assigned Guaranteed Bit Rate IE) also in the other direction for this RAB. If the Supported Assigned Maximum Bit Rate IE (respectively Supported Assigned Guaranteed Bit Rate IE) is used it shall be used in both directions.

If any alternative RAB parameter values have been used from the Supported Alternative Maximum Bit Rate Information IE (respectively Supported Alternative Guaranteed Bit Rate Information IE), these RAB parameter values shall be included in the RAB ASSIGNMENT RESPONSE message within the Supported Assigned Maximum Bit Rate IE (respectively Supported Assigned Guaranteed Bit Rate IE).

For the CS domain, when an ALCAP is used, UTRAN shall report the successful outcome of a specific RAB to establish or modify only after the Iu user plane at RNL level is ready to be used in UL and DL. At a RAB establishment, the transport network control plane signalling required to set up the transport bearer shall use the Transport Layer Address IE and Iu Transport Association IE. At a RAB modification when Transport Layer Address (IE) and Iu Transport Association IEs are included, the RNC shall establish a new transport bearer. The transport network control plane signalling shall then use the included Transport Layer Address IE and Iu Transport Association IE. Then the switch over to this new transport bearer shall be done immediately after transport bearer establishment and initialisation of the user plane mode. If Transport Layer Address (IE) and Iu Transport Association IEs are not included, then the RNC may modify the already existing transport bearer.

For the PS domain or for the CS domain when an ALCAP is not used, when they are present at a RAB modification, the RNC shall use the embedded Transport Layer Address IE and Iu Transport Association IEs as the termination point of the new transport bearer.

For the PS domain or for the CS domain when an ALCAP is not used, for each RAB successfully modified, if the RNC has changed the Transport Layer Address IE and/or the Iu Transport Association IE, it shall include the new value(s) in the RAB ASSIGNMENT RESPONSE message.

Before reporting the successful outcome of a specific RAB to establish or modify, the RNC shall have executed the initialisation of the user plane, if necessary.

Re-initialisation of the user plane shall not be performed if:

– the RAB Parameters IE is not included, for example during transfer of NAS Synchronisation Indicator IE;

– the RAB Parameters IE is included but the SDU Format Information Parameter IE is not changed for the existing RAB and the NAS Synchronisation Indicator IE is not included.

Re-initialisation of the user plane shall be performed if the RAB Parameters IE and NAS Synchronisation Indicator IE are included.

If the RNC can not 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 Assignment shall fail with the cause value "RNC unable to establish all RFCs".

In case of establishment of a RAB for the PS domain, the CN must be prepared to receive user data before the RAB ASSIGNMENT RESPONSE message has been received.

If none of the RABs have been queued, the CN shall stop timer T _RABAssgt and the RAB Assignment procedure terminates. In that case, the procedure shall also be terminated in the UTRAN.

When the request to establish or modify one or several RABs is put in a queue, the UTRAN shall start the timer T_QUEUING. This timer specifies the maximum time for queuing of the request for establishment or modification. The same timer T_QUEUING supervises all RABs of the request being queued.

For each RAB that is queued the following outcomes are possible:

– successfully established or modified;

– failed to establish or modify;

– failed due to expiry of the timer T_QUEUING.

For RABs indicated as queued in the first RAB ASSIGNMENT RESPONSE message, the UTRAN shall report the outcome of the queuing for every RAB individually or for several RABs in subsequent RAB ASSIGNMENT RESPONSE message(s). This is left to implementation. The UTRAN shall stop T_QUEUING when all RABs have been either successfully established or modified or failed to establish or modify. The RAB Assignment procedure is then terminated both in the CN and the UTRAN when all RABs have been responded to.

When the CN receives the response that one or several RABs are queued, it shall expect the UTRAN to provide the outcome of the queuing function for each RAB before expiry of the T _RABAssgt timer. In case the timer T _RABAssgt expires, the CN shall consider the RAB Assignment procedure terminated and the RABs not reported shall be considered as failed.

In case the timer T_QUEUING expires, the RAB Assignment procedure terminates in the UTRAN for all queued RABs, and the UTRAN shall respond for all of them in one RAB ASSIGNMENT RESPONSE message. The RAB Assignment procedure shall also be terminated in the CN.

In case a request to modify or release a RAB contains the RAB ID of a RAB being queued, the RAB shall be taken out of the queue and treated according to the second request. The first request shall be responded to as a RAB failed to setup or modify with the cause value "Request superseded".

If the UTRAN failed to modify a RAB, it shall keep the RAB as it was configured prior to the modification request.

When UTRAN reports unsuccessful establishment/modification of a RAB, the cause value should be precise enough to enable the core network to know the reason for unsuccessful establishment/modification. Typical cause values are: "Requested Traffic Class not Available", "Invalid RAB Parameters Value", "Requested Maximum Bit Rate not Available", "Requested Maximum Bit Rate for DL not Available", "Requested Maximum Bit Rate for UL not Available", "Requested Guaranteed Bit Rate not Available", "Requested Guaranteed Bit Rate for DL not Available", "Requested Guaranteed Bit Rate for UL not Available", "Requested Transfer Delay not Achievable", "Invalid RAB Parameters Combination", "Condition Violation for SDU Parameters", "Condition Violation for Traffic Handling Priority", "Condition Violation for Guaranteed Bit Rate", "User Plane Versions not Supported", "Iu UP Failure", "Iu Transport Connection Failed to Establish", "T_QUEUING Expiry".

If the RAB ID of a RAB requested to be released is unknown in the RNC, this shall be reported as a RAB failed to release with the cause value "Invalid RAB ID".

The RNC may indicate an impending directed retry attempt to GSM by sending a RAB ASSIGNMENT RESPONSE message with a RAB ID included in the list of RABs failed to setup and a cause value of "Directed Retry".

The RNC shall be prepared to receive a RAB ASSIGNMENT REQUEST message containing a RABs To Be Released IE at any time and shall always reply to it. If there is an ongoing RAB Assignment procedure for a RAB indicated within the RABs To Be Released IE, the RNC shall discard the preceding RAB Assignment procedure for that specific RAB, release any related resources and report the released RAB within the RAB ASSIGNMENT RESPONSE message.

After sending a RAB ASSIGNMENT RESPONSE message containing RAB ID within the RABs Released IE, the RNC shall be prepared to receive a new establishment request for a RAB identified by the same RAB ID.

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

– If the MSISDN IE is present in the RAB ASSIGNMENT REQUEST message, then the UTRAN may offload the RAB(s) where the Offload RAB Parameters IE is present in the RABs To Be Setup Or Modified 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].

8.2.2.1 Successful Operation for GERAN Iu-mode

For GERAN Iu-mode the following shall apply in addition for the successful operation of the RAB Assignment procedure:

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

– In case of GERAN Iu-mode (only for CS), if the BSC cannot provide an appropriate RAB corresponding to the content of the GERAN BSC Container IE (if received), the BSC shall report unsuccessful RAB establishment/modification indicating the cause value "GERAN Iu-mode Failure" and the GERAN Classmark IE in the GERAN Iu mode specific RABs Failed To Setup Or Modify List IE within the RAB ASSIGNMENT RESPONSE message.

8.2.3 Unsuccessful Operation

The unsuccessful operation for this Class 3 Elementary procedure is described under the Successful Operation chapter.

8.2.4 Abnormal Conditions

For a RAB requested to be modified, if only the RAB ID IE, the NAS Synchronisation Indicator IE and the Transport Layer Information IE are included in the First Setup or Modify Item IE, the RAB shall not be modified, and the corresponding RAB ID IE and Cause IE shall be included in the "RABs Failed To Setup Or Modify List" in the RAB ASSIGNMENT RESPONSE message.

If, for a RAB requested to be setup towards the PS domain, any of the following IEs:

– PDP Type Information.

– PDP Type Information extension.

– Data Volume Reporting Indication.

is not present, the RNC shall continue with the procedure.

Interactions with Relocation Preparation/Enhanced Relocation procedure:

If the relocation or enhanced relocation becomes necessary during the RAB Assignment procedure, the RNC may interrupt the ongoing RAB Assignment procedure and initiate the Relocation Preparation or Enhanced Relocation procedure as follows:

1. The RNC shall terminate the RAB Assignment procedure indicating unsuccessful RAB configuration modification:

– for all queued RABs;

– for RABs not already established or modified, and

– for RABs not already released;

with the cause "Relocation triggered".

2. The RNC shall terminate the RAB Assignment procedure indicating successful RAB configuration modification:

– for RABs already established or modified but not yet reported to the CN, and

– for RABs already released but not yet reported to the CN.

3. The RNC shall report the outcome of the procedure in one RAB ASSIGNMENT RESPONSE message.

4. The RNC shall either invoke relocation by sending a RELOCATION REQUIRED message to the active CN node(s) or enhanced relocation by sending the Iur ENHANCED RELOCATION REQUEST message to the target RAN node.

5. The CN shall terminate the RAB Assignment procedure at reception of the RAB ASSIGNMENT RESPONSE message.

Directed retry from UMTS to GSM (CS domain only):

In the case where the RNC has no RAB configuration for a particular UE in the CS domain, and the RNC receives a RAB ASSIGNMENT REQUEST message for that UE requesting the establishment of one RAB only, a directed retry to perform inter-system handover to GSM may be initiated. In this case the RNC may interrupt the ongoing RAB Assignment procedure and initiate the Relocation Preparation procedure as follows:

1. The RNC shall terminate the RAB Assignment procedure indicating unsuccessful RAB configuration modification of that RAB with the cause "Directed retry".

2. The RNC shall report the outcome of the procedure in one RAB ASSIGNMENT RESPONSE message.

3. The RNC shall invoke relocation by sending a RELOCATION REQUIRED message to the active CN node, with the cause "Directed Retry".

4. The CN shall terminate the RAB Assignment procedure at reception of the RAB ASSIGNMENT RESPONSE message.

For a RAB setup or modification, if the Supported Maximum Bit Rate IE (respectively Supported Guaranteed Bit Rate IE) is present in the RAB Parameters IE, the RNC shall ignore the corresponding bitrate and/or extended bitrate definition in this IE.

For a RAB setup or modification, if the Supported Alternative Maximum Bit Rate IE (respectively Supported Alternative Guaranteed Bit Rate IE) is present in the Alternative RAB Parameter Values IE, the RNC shall ignore the corresponding alternative bitrate and/or extended alternative bitrate definitions in this IE.

For a RAB setup or modification, if both the Correlation ID IE and the SIPTO Correlation ID IE are present for the same RAB, the RNC shall consider the establishment of the corresponding RAB as failed.