4.2 Iu Interface

23.1213GPPArchitectural requirements for Release 1999Release 1999TS

– Transport protocol across the Iu interface for UTRAN shall be according to 23.930.

– The UTRAN shall support two logically separate signalling flows via Iu to combined or separate network nodes of different types (MSC and SGSN).

– The UTRAN shall contain a "domain distribution function" to route transparent application-level control signalling from the UE to the correct core network domain. The UE shall indicate the type of application being addressed (e.g. via a protocol discriminator). The UTRAN shall map this on to the correct Iu instance to forward the signalling.

– UTRAN-services (including radio access bearers) shall be independent from the core network domain used to access them. Either core network domain can access any appropriate UTRAN-service (e.g. it should be possible to access a "speech" radio access bearer from the PS-domain).

– The protocol architecture for the User Plane of the Iu interface towards the IP domain shall be based on the same principles as for the (evolved) Gn interface, i.e. the user plane part of GTP over UDP/IP shall be used for 9ignalling of end user data packets over the Iu interface. If the Iu data transport bases on ATM PVCs then the Iu IP layer provides the Iu network layer services, e.g. routing, addressing, load sharing and redundancy. In this case an IP network may be configured to transfer Iu data units between RNSs and 3G-SGSNs.

– One or several AAL5/ATM Permanent VCs may be used as the common layer 2 resources between the UTRAN and the ‘IP domain’ of the CN. The reason for usage of several permanent AAL5/ATM VCs may e.g. be for load sharing and redundancy. It is also possible to use one switched VC per user flow (PDP context or radio access bearer). Switched VCs may be used, however the standardization of the procedures and protocols for use of Switched VCs is outside the scope of the 3GPP. If operators use switched VC, the specification of procedures and protocol for switched VCs are up to operators and out of scope of the UMTS/IMT-2000 specification.

Figure 4.1: Protocol Architecture for the Iu user plane towards the IP domain

– Charging functionality is located at the 3G-SGSN. On the other hand, only RNC can identify the actual packet volume successfully transferred to a UE. In order for 3G-SGSN to provide the volume based charging for IP domain, the standard shall support the following procedures over Iu interface.

– The RNC indicates the volume of all not transferred downlink data (discarded or forwarded to 2G-SGSN) to the 3G-SGSN so that the 3G-SGSN can correct its counter. Partially transferred packets are handled as not transferred.

– The RNC delivers to the 3G-SGSN the discarded or forwarded volume accumulated over an implementation dependent time and not per discarded or forwarded packet.

– The 3G-SGSN can ask the RNC to provide the volume of buffered downlink data to correct its counter at any time the 3G-SGSN wants.

4.2.1 Iu Control Plane

For transport of RANAP messages over Iu an SCCP protocol shall be used for both packet and circuit switched domains. The SCCP protocol shall fully comply with ITU-T white book. RANAP protocol shall be designed to use this service according to the ITU-T standard. Iu shall be designed so that RANAP is not impacted by alternatives for SCCP message transport on layers below SCCP.

In the circuit switched domain SCCP messages shall be transported on a broadband SS7 stack comprising MTP3b on top of SAAL-NNI. In this domain no other alternatives are standardised in release 99.

In the packet switched domain the UMTS standard shall allow operators to chose one out of two standardised protocol suites for transport of SCCP messages.

1) Broadband SS7 stack comprising MTP3b on top of SAAL-NNI.

2) IETF/Sigtran CTP protocol suite for MTP3 users with adaptation to SCCP. The protocol suite shall fully comply with the IETF standards developed by the Sigtran working group. No UMTS specific adaptations shall be standardised below the SCCP protocol.

The grey colour denotes protocols being developed by the IETF sigtran group.

Figure 4.2: RANAP protocol stack options

4.2.2 Iu User plane

– The standard shall support that the user data flows transported over the Iu reference point to/from the ‘IP domain’ shall be multiplexed on top of common layer 2 resources.

– If the Iu data transport bases on ATM PVCs then the Iu IP layer provides the Iu network layer services, e.g. routing, addressing, load sharing and redundancy. In this case an IP network may be configured to transfer Iu data units between RNSs and 3G-SGSNs.

– One or several AAL5/ATM Permanent VCs may be used as the common layer 2 resources between the UTRAN and the ‘IP domain’ of the CN. The reason for usage of several permanent AAL5/ATM VCs may e.g. be for load sharing and redundancy. It is also possible to use one switched VC per user flow (PDP context or radio access bearer).

– A tunnelling protocol is used on top of this common layer 2. This tunnelling protocol corresponds to an evolution of the user plane part of the GTP protocol used in GPRS put on top of UDP/IP.

– The user data plane in the UMTS network is made up of two tunnels:

– a first IP/UDP/GTP tunnel between RNC and 3G SGSN on Iu;

– a second IP/UDP/GTP tunnel between GGSN and 3G SGSN on Gn.

This architecture:

– provides hierarchical mobility;

– allows having the RNC directly connected on the IP domain backbone;

– ensures that all traffic is routed through 3G-SGSN that may perform functions such as charging and Lawful Interception;

– would allow to have different protocols (or protocol version) on Gn and Iu if needed in the future.

The protocol stack is shown in figure 4.3.

Figure 4.3: Protocol Architecture for IP domain user plane

4.2.2.1 Principles of User Data Retrieve in UMTS and at GSM-UMTS Hand-Over for PS Domain

4.2.2.1.1 Requirements for Data retrieve at GPRS/UMTS handover

The same reliability as in inter 2G-SGSN RA update case has to be provided at GPRS to/from UMTS handover. Therefore, the data retrieval should be ensured between 2G-SGSN and SRNC as it is ensured between two 2G-SGSNs.

Between two 2G-SGSNs, data retrieve is carried out via the Gn interface i.e. via GTP-u[1]/UDP/IP. In order that the 2G‑SGSN is not modified for data retrieve with the SRNC, the 2G-SGSN should keep the same protocol stack.

4.2.2.1.2 Adopted solution for data retrieve at GPRS-UMTS handover

For Control Plane: Since some parameters transported by GTP-c are CN related only (e.g. CN classmark,…), it is necessary to terminate GTP-c signalling exchanged with the 2G-SGSN in the 3G-SGSN, and to use RANAP signalling on Iu between 3G-SGSN and SRNC.

For User plane: As Charging of the retrieved data is to be carried out at 3G-SGSN, data exchanged between SRNC and 2G-SGSN are handled by the 3G-SGSN (two GTP pipes: SRNC – 3G-SGSN and 3G-SGSN – 2G-SGSN). This ensures that:

– 3G-SGSN can increment charging counters for user data sent from 2G-SGSN to SRNC;

– 3G-SGSN can decrement charging counters for user data sent from SRNC to 2G-SGSN avoiding that such data are charged twice (in 3G-SGSN and in 2G-SGSN).

Figure 4.4: Data retrieve between GPRS and UMTS

4.2.2.1.3 Requirements for data retrieve in UMTS

NOTE: This subclause deals with the case of SRNS relocation and of UMTS hard hand-over (when this hard hand-over involves also the CN i.e. involves a change of Serving RNC).

Since:

– there is no buffering in the 3G-SGSN;

– there is an ARQ mechanism in the Serving RNC (the RLC layer) similar to the LLC layer in the 2G-SGSN;

– the data reliability is ensured by the transfer of non-acknowledged user data from the Source RNC to the Target RNC. This transfer ("data retrieve") can be performed with a mechanism similar to the one used between 2G-SGSNs in GPRS;

– the Data retrieve between two RNCs belonging to the same UTRAN is required for non real-time data services during a SRNS relocation procedure;

– regarding the SRNS Relocation procedure Control Plane, SRNS relocation procedure uses both RANAP signalling over the Iu and RNSAP signalling over the Iur.

Regarding the user plane, some requirements can be listed:

Synchronisation:

Since the 3G-SGSN does not buffer downstream data, the source RNC may have to buffer all GTP frames that are not yet transmitted or acknowledged at RLC layer. It also has to buffer all GTP frames that continue to arrive from the GGSN (the GGSN continues to send them to the source RNC as long as its PDP context has not been updated by the SGSN. Furthermore, data that are sent by the GGSN may take a certain time to get to the source RNC).

This means that:

The target RNC has to start as Serving RNC just after having received SRNS Relocation Commit message from the source RNC even if all downstream data have not been retrieved yet.

The user data retrieve may last a relatively long time. A timer is armed in the Source SRNC at the beginning of the data transfer phase. The contexts related to the UE in the Source SNRC will be released when the timer expires, i.e. when downstream data from GGSN is considered as finished.

Data reliability:

Depending upon the required reliability, there could be a need for a layer 2 protocol or not. In the GPRS, the user data is transfer via GTP/UPD/IP if the user-to-user data is IP-based, and via GTP/TCP/IP if the user-to-user data is X25-based. Here, only GTP/UDP/IP is considered.

Multiplexing of PDP contexts during data retrieve:

Several SRNS Relocation procedures for different users and/or different bearers may be carried out simultaneously and independently. GTP is used to differentiate the data retrieve contexts.

Associated signalling:

Considering signalling, there are two kinds of signalling:

Signalling linked with transmission of CN parameters. This corresponds to signalling exchanged on Gn between 3G-SGSNs during the (first) phase of resources for the SRNS relocation.

Signalling linked with the transmission of the sequence numbers of the acknowledged protocol (RLC) between SRNC and UE. This can be done over Iur when the source SRNC actually hands-over the role of SRNC (when sending the RNSAP "Relocation commit" to the target SRNS).

4.2.2.1.4 Adopted solution for data retrieve in UMTS

Data Retrieve procedure at SRNS relocation shall be carried out through the Iu interface: data exchanged between source and target SRNC are carried over Iu at ATM layer. They are routed at IP layer towards the target SRNC and there is one single GTP tunnel between the source SRNC and the target SRNC.

Figure 4.5: User data Retrieve in UMTS

4.2.2.1.5 User plane protocol stacks for UMTS data retrieve

The user plane for data retrieve between two RNCs is based on GTP-u/UDP/IP. The GTP connections are terminated in the source SNRC and the target SRNC as described in figure 4.6.

Figure 4.6: User plane protocol stack for data retrieve in UMTS

4.2.2.1.6 User plane protocol stacks for data retrieve between UTRAN and 2G-SGSN

The user plane for data retrieve between UTRAN and 2G-SGSN is based on GTP-u/UDP/IP. The protocol stack and the GTP connections termination points are described in figure 4.7.

Figure 4.7: User plane protocol stack for data retrieve between GPRS and UMTS

4.2.2.2 Packet buffering in SRNC and transmission of not yet acknowledged downstream packets at SRNC relocation

Due to the bursty nature of IP traffic and due to the limited amount of downstream radio resources, some (large) buffering capacity is needed in the network to absorb the traffic peaks that arrive as there are not enough radio resources to send them to the UE(s). Only this kind of buffering is considered in the rest of this subclause.

Large buffering capacity in both CN and SRNC would add to the:

– cost of the network (duplication of memory resources);

– transit delay (packets may have to stay in 2 large queues);

– complexity of the system (coordination between CN and SRNC for buffer management and associated packet scheduling according to QoS).

As a consequence such (large) buffers should only be put in one place (CN or SRNC).

RNC-UE procedures (ARQ RLC) ensure data reliability as long as SRNS relocation or GSM <-> UMTS Hand-Over are not needed. Large buffering capacities as well as procedures to ensure data reliability at SRNS relocation and GSM <-> UMTS Hand-Over (transmission between old and new nodes of downstream packets not yet acknowledged by the UE) should be put where ARQ procedures are located.

Hence the acknowledgement layer LLC that is needed in GSM/GPRS is not needed between CN and UE in UMTS because data reliability is provided between UE and SRNC. In case of SRNS relocation or GSM <-> UMTS Hand-Over, transmission of not yet acknowledged downstream packets between (old and new) SRNC or between SRNC and 2G-SGSN provide the necessary reliability.

Hence large buffers to absorb peaks of downstream traffic as well are not needed in the CN and no flow control between CN and UTRAN needs to be defined in order to control the IP domain user plane flow.

4.2.2.3 Load sharing

To ensure the necessary load sharing on the Iu_PS interface.

When the CN requests the establishment of a Radio Access Bearer (associated with a PDP context) or at SRNS relocation for all Radio Access Bearers (associated with PDP contexts) of an UE, the CN specifies the IP address of the packet processing function allocated to this / each of these PDP context(s) in the CN.

In the response to the CN request, the RNC specifies the IP address of the packet processing function allocated to this / each of these Radio Access Bearer(s) in the RNC.

When it sends downstream traffic in a RAB, the packet processing function in the CN sends the packet to the RNC IP @ received from the SRNC at RAB establishment or at SRNS relocation.

When it sends upstream traffic in this RAB, the packet processing function in the RNC sends the packet to the CN IP @ received from the CN at RAB establishment or at SRNS relocation.