4 General Aspects

25.4103GPPRelease 17TSUTRAN Iu interface: General aspects and principles

4.1 UTRAN Architecture

4.1.1 Iu Interface Architecture

The overall UMTS architecture and UTRAN architectures are described in TS 25.401 [1]. This subclause specifies only the architecture of the Iu interface, and shall not constrain the network architecture of either Core or Radio Access Networks.

The I_u interface is specified at the boundary between the Core Network and UTRAN. Figure 4.1 depicts the logical division of the I_u interface. From the Iu perspective, the UTRAN access point is an RNC.

Figure 4.1: I_u Interface Architecture

The Iu interface towards the PS-domain of the core network is called Iu-PS, and the Iu interface towards the CS-domain is called Iu-CS. The differences between Iu-CS and Iu-PS are treated elsewhere in the present document. The Iu interface to the Broadcast domain is called Iu-BC.

There shall not be more than one Iu interface (Iu-PS) towards the PS-domain from any one RNC– except where the NNSF is used, see subclause 4.1.3, or in MOCN configuration – see TS 23.251 [26]. Each RNC shall not have more than one Iu interface (Iu-CS) towards its default CN node within the CS domain, but may also have further Iu interfaces (Iu-CS) towards other CN nodes within the CS domain. (See [6] for definition of Default CN node.) These further Iu interfaces (Iu-CS) shall only be used as a result of intra-MSC inter-system handover or SRNS relocation, in the case the anchor CN node directly connects to the target RNC. There may also be more than one Iu interface towards the CS-Domain if the NNSF is used – see subclause 4.1.3, or in MOCN configuration – see TS 23.251 [26]. There shall not be more than one Iu interface (Iu-BC) from an RNC towards the Broadcast domain.

In the separated core network architecture, this means that there shall be separate signalling and user data connections towards the PS and CS domains – this applies in both transport and radio network layers.

In the combined architecture, there shall be separate connections in the user plane towards the PS and CS domains (in both transport and radio network layers). In the control plane, there shall be separate SCCP connections to the two logical domains.

In either architecture, there can be several RNCs within UTRAN and so UTRAN may have several I_u access points towards the Core Network. As a minimum, each Iu access point (in UTRAN or CN) shall independently fulfil the requirements of the relevant Iu specifications (25.41x series – see clause 7).

4.1.2 I_u connection principles

The Iu interface has a hierarchical architecture where one higher layer entity controls several lower layer entities. The hierarchy for the CN – UTRAN signalling connection end points is described below:

– Each CN Access Point may be connected to one or more UTRAN Access Points.

– For the PS domain, each UTRAN Access Point shall not be connected to more than one CN Access Point – except where the NNSF is used, see subclause 4.1.3, or when RNC is shared in MOCN configuration..

– For the CS domain, each UTRAN Access Point may be connected to one or more CN Access Points.

– For the BC domain, each UTRAN Access Point may be connected to one CN Access Point only.

4.1.3 Implementation of the NAS Node Selection Function

The optional NAS Node Selection Function (NNSF) is described in TS 23.236 [25].

If the NAS Node Selection Function is used by an RNC:

– There may be more than one Iu interface (Iu-CS) towards the CS domain and/or more than one Iu interface (Iu-PS) towards the PS-domain from this RNC.

4.1.4 Implementation of MOCN configuration support

The MOCN configuration is described in TS 23.251 [26]. When the RNC is shared in MOCN configuration:

– There may be more than one Iu interface (Iu-CS) towards the CS domain of different CN operators and/or more than one Iu interface (Iu-PS) towards the PS-domain of different CN operators from this RNC.

– The MOCN Rerouting Function shall be supported.

4.2 I_u Interface General Principles

From a UTRAN perspective, maximising the commonality of the various protocols that flow on the Iu interface is desirable. This means at the minimum that:

– A common set of radio access bearer services will be offered by UTRAN to the Core Network nodes, regardless of their type (e.g. 3G-MSC or 3G-SGSN).

There will be a common functional split between UTRAN and the Core Network nodes, regardless of their type (e.g. 3G-MSC or 3G-SGSN).

Signalling in the radio network control plane shall not depend on the specific choice of transport layers.

4.3 I_u Interface Specification Objectives

The following objectives are partly derived from TR 23.930 [2].

The I_u interface shall be specified such that it can support:

– the interconnection of RNCs with Core Network Access Points within a single PLMN, and within several PLMNs in case of network sharing, as described in TS 23.251 [26].

– the interconnection of RNCs with Core Network Access Points irrespective of the manufacturer of any of the elements.

– all UMTS services.

The I_u interface shall facilitate the use of the same RNC, MSC or SGSN in all PLMNs.

The I_u interface shall facilitate the sharing of transport technology between Iu-PS and Iu-BC.

The I_u interface shall allow interworking to the GSM Core Network.

Independence between the protocol layers and between control and user planes shall be maintained on the Iu interface.

The I_u interface shall allow independent evolution of technologies within the Core, Radio Access and Transport Networks.

The I_u interface shall allow separate evolution of O&M facilities.

The I_u interface shall be standardised as an open and multi-vendor interface.

The Iu interface specifications shall facilitate the migration of some services from the CS-domain to the PS-domain. In particular, the RANAP protocol shall be common to both PS and CS domains, and the I_u user plane protocol(s) shall be independent of the core network domain (PS or CS), except where a specific feature is only required for one domain.

4.4 I_u Interface Capabilities

The following capabilities are derived from the requirements described in TR 23.930 [2].

The I_u interface supports:

– procedures to establish, maintain and release Radio Access Bearers;

– procedures to perform SRNS relocation, intra-system handover, inter-system handover and inter-system change;

– procedures to support the Cell Broadcast service;

– a set of general procedures, not related to a specific UE;

– the separation of each UE on the protocol level for user specific signalling management;

– the transfer of NAS signalling messages between UE and CN;

– location services by transferring requests from the CN to UTRAN, and location information from UTRAN to CN. The location information may comprise a geographical area identifier or global co-ordinates with uncertainty parameters;

– simultaneous access to multiple CN domains for a single UE;

– mechanisms for resource reservation for packet data streams;

– procedures to support MBMS bearer services;

– mechanisms to support SIPTO at Iu-PS for a specific UE (optional);

– mechanisms to support SIPTO at the Local Network with standalone GW for a specific UE (optional).

4.5 I_u Interface Characteristics

4.5.1 Use of Transport Network User Plane as Signalling Bearer

4.5.1.1 Use of SCCP

4.5.1.1.1 General

The SCCP (ITU-T Rec. Q.711 [9] /ITU-T Rec. Q.712 [10]/ITU-T Rec. Q.713 [11]/ITU-T Rec. Q.714 [12]) is used to support signalling messages between the CNs and the RNC. One user function of the SCCP, called Radio Access Network Application Part (RANAP), is defined. The RANAP uses one SCCP signalling connection per active UE and CN for the transfer of layer 3 messages. RANAP also uses one SCCP signalling connection per MBMS bearer service.

Both connectionless and connection-oriented procedures are used to support the RANAP. TS 25.413 [6] explains whether connection oriented or connectionless services should be used for each layer 3 procedure.

RANAP may use SSN, SPC and/or GT and any combination of them as addressing schemes for the SCCP. Which of the available addressing scheme to use for the SCCP is an operator matter.

When GT addressing is utilised, the following settings shall be used:

– SSN Indicator = 1 (RANAP SSN as defined in TS 23.003 [13] shall always be included).

– Global Title Indicator = 0100 (GT includes translation type, numbering plan, encoding scheme and nature of address indicator).

– Translation Type = 0000 0000 (not used).

– Numbering Plan = 0001 (E.163/4).

– Nature of Address Indicator = 000 0100 (International Significant Number).

– Encoding Scheme = 0001 or 0010 (BCD, odd or even).

– Routing indicator = 0 or 1 (route on GT or PC/SSN).

When used, the GT shall be the E.164 address of the relevant node.

The following subclauses describe the use of SCCP connections for RANAP transactions. Subclause 4.5.1.2 describes the connection establishment procedures. Subclause 4.5.1.3 describes the connection release procedures. Subclause 4.5.1.4 describes abnormal conditions.

4.5.1.1.2 SCCP Connection Establishment procedure

A new SCCP connection is established when information related to the communication between a UE and the network has to be exchanged between RNC and CN, and no SCCP connection exists between the CN and the RNC involved, for the concerned UE. A new SCCP connection is also established for MBMS service purpose between the RNC and CN.

Various SCCP connection establishment cases have to be distinguished:

i) RNC Initiated SCCP Signalling Connection for a UE;

ii) CN Initiated SCCP Signalling Connection for a UE;

iii) CN Initiated SCCP Signalling Connection for an MBMS Service.

The above cases are the only cases currently identified for SCCP connection establishment. Others may emerge in the future.

4.5.1.1.2.1 Establishment procedure in case i

The SCCP signalling connection establishment is initiated, by the RNC, at the reception of the first layer 3 non access stratum message from the UE or at the execution of the enhanced relocation or at the initiation of the UE Registration Query procedure.

Initiation

The RNC sends SCCP CONNECTION REQUEST message to the Core Network. A RANAP message shall be included in the user data field of the SCCP CONNECTION REQUEST message when the RANAP message size is less than or equal to the maximum size of the user data field in the SCCP CONNECTION REQUEST message. When the RANAP message is longer than the maximum size, the user data field shall not be included in the SCCP CONNECTION REQUEST message.

If the Core Network receives an SCCP CONNECTION REQUEST message for a UE for which an SCCP connection already exists, or if the Core Network receives an SCCP CONNECTION REQUEST message that does not include a user data field, and later finds out that the SCCP CONNECTION REQUEST message was for a UE for which an SCCP connection already exists, the Core Network shall ensure that the new SCCP connection and the already existing SCCP connection are for the same UE, e.g. by security functions, and if so, release the already existing SCCP connection via the normal Iu Release procedure and all UTRAN resources allocated to it.

Termination

– successful outcome

– The SCCP CONNECTION CONFIRM message, which may optionally contain a connection oriented RANAP message in the user data field, is returned to the RNC.

– unsuccessful outcome

– If the SCCP signalling connection establishment fails, an SCCP CONNECTION REFUSAL message will be sent back to the RNC. This message may contain a RANAP message in the user data field.

For more information on how the RANAP procedures Initial UE Message, Enhanced Relocation Complete and UE Registration Query are handled, please see the elementary procedures Initial UE Message, Enhanced Relocation Complete and UE Registration Query in TS 25.413 [6].

RNC CN

CR {SSN=RANAP, a1=x, RANAP message or no user data}
——————————————->

CC {a1=y,a2=x, RANAP message or no user data}
<——————————————

or
CREF{a2=x, RANAP message or no user data}
<——————————————

a1 = source local reference,
a2 = destination local reference,

x = SCCP connection reference at the RNC,

y = SCCP connection reference at the CN.

Figure 4.2: Setting-up of RNC Initiated SCCP Signalling Connection

4.5.1.1.2.2 Establishment procedure in case ii

The SCCP signalling connection establishment is initiated, by the Core Network, in connection with performing a Relocation.

Initiation

The Core Network initiates the connection establishment by sending an SCCP CONNECTION REQUEST message to the RNC. Optionally, a RANAP message may be included in the user data field of the SCCP CONNECTION REQUEST message.

Termination

– successful outcome

– The SCCP CONNECTION CONFIRM message, which may optionally contain a connection oriented RANAP message in the user data field, is returned to the Core Network.

– unsuccessful outcome

– If the SCCP signalling connection establishment fails, an SCCP CONNECTION REFUSAL message will be sent back to the Core Network. This message may contain a RANAP message in the user data field.

RNC CN

CR {SSN=RANAP, a1=y,RANAP message or no user data}
<—————————————–

CC {a1=x, a2=y, RANAP message or no user data}
——————————————>

or
CREF{a2=y, RANAP message or no user data}
——————————————>

a1 = source local reference,
a2 = destination local reference,

x = SCCP connection reference at the RNC,

y = SCCP connection reference at the CN.

Figure 4.3: Setting-up of CN Initiated SCCP Signalling Connection

4.5.1.1.2.3 Establishment procedure in case iii

The SCCP signalling connection establishment is initiated, by the Core Network, to establish a new SCCP connection between the RNC and the CN for an MBMS service at the start of an MBMS session and when no SCCP connection already exists between the CN and the RNC involved, for the concerned MBMS service.

Initiation

The Core Network initiates the connection establishment by sending an SCCP CONNECTION REQUEST message to the RNC. Optionally, a RANAP message may be included in the user data field of the SCCP CONNECTION REQUEST message.

Termination

– successful outcome

– The SCCP CONNECTION CONFIRM message, which may optionally contain a connection oriented RANAP message in the user data field, is returned to the Core Network.

– unsuccessful outcome

– If the SCCP signalling connection establishment fails, an SCCP CONNECTION REFUSAL message will be sent back to the Core Network. This message may contain a RANAP message in the user data field.

4.5.1.1.3 SCCP Connection Release procedure

This procedure is always initiated at the Core Network side in normal release case.

An SCCP connection is released when the CN realises that a given signalling connection is no longer required.

The CN sends a SCCP RELEASED message.

The procedure may be initiated at the Core Network side and the RNC side in any abnormal release case.

4.5.1.1.4 General SCCP Abnormal Conditions

If a user-out-of-service information or signalling-point-inaccessible information is received by the RANAP, no new attempt to establish SCCP connections towards the affected point code will be started until the corresponding user-in-service information or signalling-point-accessible information is received.

When a user-out-of-service information or signalling-point-inaccessible is received by the RNC, an optional timer may be started. When the timer expires, all the SCCP connections towards the affected point code will be released. When the user-in-service or signalling-point-accessible is received, the timer is stopped.

If for any reason an SCCP connection is released, the optional timer expires or a connection refusal is received while any of the RANAP procedures are being performed or while a dedicated resource is still allocated, the following actions are taken:

At RNC:

– Any RNC procedure relating to that connection is abandoned.

– The UTRAN resources allocated to the connection are released.

At Core Network:

– The resources associated with the SCCP connection are cleared as soon as possible.

4.5.1.2 Use of MTP3b

– For a given MSC, the RNC shall be able to access RANAP and ALCAP either under the same MTP3b (IETF RFC 3332 [18]) destination point code, or under different point codes;

– For a given RNC, the MSC shall be able to access RANAP and ALCAP either under the same MTP3b destination point code, or under different point codes.

4.5.2 Use of Transport Network User Plane as User Data Bearer

4.5.2.1 Use of AAL2

In the ATM transport option AAL2 is used as the user data bearer towards the CS domain.

Q.2630.2 is used as the protocol for dynamically setup AAL-2 connections over Iu towards the CS domain. Q.2630.2 adds new optional capabilities to Q.2630.1.

4.5.2.2 Use of GTP-U

GTP-U is used as the user data bearer towards the PS domain.

RANAP Signalling is used to establish, modify and release the GTP-U tunnels towards the PS domain.

4.5.2.3 Use of RTP

RTP/UDP/IP (IETF RFC 1889 [19]/ IETF RFC 768 [20]/ IETF RFC 791[22]) is used as the user data bearer towards the CS domain in the IP transport option. The use of RTCP (IETF RFC 1889 [19]) is optional.

RANAP Signalling is used to establish, modify and release RTP sessions towards the CS domain.

4.5.3 Use of Transport Network User Plane on Iu-BC

TCP/IP (IETF RFC 793[21]/ IETF RFC 791[22]) is used as the bearer for the radio network layer protocol over I_u-BC.

The TCP connection is normally established by the CN using standard TCP procedures.

A new TCP connection is established by the RNC only when there is information (e.g. failure or restart indications) that needs to be sent from RNC to the CN, and there is no existing TCP connection. The RNC shall establish the connection using standard TCP procedures.

The node that established the connection shall release the TCP connection.