The present document specifies the standards for Signalling Transport to be used across Iur Interface. Iur Interface is a logical interface between the two RNC of the UMTS Terrestrial Radio Access Network (UTRAN) for the UMTS system. The present document describes how the RNSAP signalling messages are transported between the two RNCs.
The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
References are either specific (identified by date of publication, edition number, version number, etc.) or non specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
ITU-T Recommendation Q.2140 (1995-02): "B-ISDN ATM adaptation layer - Service Specific Co-ordination Function for signalling at the Network Node Interface (SSCF AT NNI)".
ANSI T1.645-1995 (R2003): "B-ISDN Signaling ATM Adaptation Layer - Service Specific Coordination Function for Support of Signaling at the Network Node Interface (SSCF at the NNI)".
ATM shall be used in the radio network control plane according to ITU-T Rec. I.361 [5]. The structure of the cell header used in the UTRAN Iur interface is the cell header format and encoding at NNI (see figure 3 of ITU-T Rec. I.361 [5]).
A UTRAN Node supporting IP transport option shall support PPP protocol with HDLC framing IETF RFC 1661 [18], IETF RFC 1662 [19].
An RNC using IP transport option having interfaces connected via slow bandwidth PPP links like E1/T1/J1 shall also support IP Header Compression IETF RFC 2507 [20] and the PPP extensions ML/MC-PPP IETF RFC 1990 [21], IETF RFC 2686 [22]. In this case, negotiation of header compression IETF RFC 2507 [20] over PPP shall be performed via IETF RFC 2509 [23].
This subclause specifies the Signalling Bearer protocol stack that supports the RNSAP signalling protocol.
The following requirements on the RNSAP signalling bearer can be stated:
provide reliable transfer of control plane signalling messages in both connectionless mode and
connection-oriented mode;
provide separate independent connections for distinguishing transactions with individual UEs;
supervise the "UE connections" and provide connection status information to the Upper Layers for individual UEs;
This subclause refers to specifications of the Signalling Bearer for the Radio Network Layer protocols. As shown in figure 1, the standard allows operators to choose one out of three protocol suites for transport of SCCP messages.
SCCP ITU-T Rec. Q.711 [7] /ITU-T Rec. Q.712 [8]/ ITU-T Rec. Q.713 [9]/ ITU-T Rec. Q.714 [10]/ ITU-T Rec. Q.715 [11]/ ITU-T Rec. Q.716[12] or ANSI T1.112-2001 [32] provides connectionless service, class 0, connection oriented service, class 2, separation of the connections mobile by mobile basis on the connection oriented link and establishment of a connection oriented link mobile by mobile basis.
MTP3-B ITU-T Rec. Q.2210 [4] or ANSI T1.111-2001 [31] provides message routing, discrimination and distribution (for point-to-point link only), signalling link management load sharing and changeover/back between link within one link-set. The need for multiple link-sets is precluded.
SAAL-NNI ITU-T Rec. Q.2100 [1] consists of the following sub-layers: - SSCF ITU-T Rec. Q.2140 [3] or ANSI T1.645-1995 [33], - SSCOP ITU-T Rec. Q.2110 [2] and - AAL5 ITU-T Rec. I.363.5 [6]. The SSCF maps the requirements of the layer above to the requirements of SSCOP. Also SAAL connection management, link status and remote processor status mechanisms are provided. SSCOP provides mechanisms for the establishment and release of connections and the reliable exchange of signalling information between signalling entities. Adapts the upper layer protocol to the requirements of the Lower ATM cells.
M3UA refers to the SCCP adaptation layer "SS7 MTP3 - User Adaptation Layer"IETF RFC 3332 [17] also developed by the Sigtran working group of the IETF. An RNC equipped with the M3UA stack option shall support both the client and the server functionality towards another RNC. This enables the RNC to report to another RNC when it is a newly introduced entity in the network.
SCTP refers to the Stream Control Transmission Protocol IETF RFC 2960 [16] developed by the Sigtran working group of the IETF for the purposes of transporting various signalling protocols over IP networks. The checksum method specified in RFC 3309 IETF RFC 3309 [30] shall be used instead of the method specified in IETF RFC 2960 [16].
SCTP. See subclause 5.2.2. In addition, Multi-homing is a way to achieve redundancy with SCTP between two endpoints, of which one or both is assigned with multiple IP addresses. SCTP endpoints shall support a multi-homed remote SCTP endpoint.
IP. An IP UTRAN Node shall support IPv6 IETF RFC 2460 [24]. The support of IPv4 IETF RFC 791 [13] is optional.
IP dual stack support is recommended for the potential transition period from IPv4 to IPv6 in the transport network
IP Differentiated Services code point marking IETF RFC 2474 [25] shall be supported. The Diffserv code point may be determined from the application parameters.
When considering the requirements that the upper layers, i.e. RNSAP, have on the Signalling Bearer, there are a number of services it has to provide and a number of functions to perform. These numbers of services that the signalling bearer shall provide, to the upper layers, are stated in the references ITU-T Rec. Q.711 [7] /ITU-T Rec. Q.712 [8]/ ITU-T Rec. Q.713 [9]/ ITU-T Rec. Q.714 [10]/ ITU-T Rec. Q.715 [11]/ ITU-T Rec. Q.716 [12] or ANSI T1.112-2001 [32].