5 RANAP Signalling Bearer

25.4123GPPRelease 17TSUTRAN Iu interface signalling transport

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

5.1 Introduction

This subclause specifies the Signalling Bearer protocol stack that supports the RANAP signalling protocol.

The following requirements on the 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 UE’s;

– supervise the ‘UE connections’ and provide connection status information to the Upper Layers for individual UE’s;

– provide networking and routing functions;

– provide redundancy in the signalling network;

– provide load sharing.

5.2 Signalling Bearer for Circuit Switched Domain

5.2.1 Protocol Stack for the CS Domain

The protocol stacks for the CS Domain are shown in figure 1. The standard allows operators to choose one out of two standardised protocol suites for transport of SCCP messages.

Figure 1 shows, for the Iu IP CS domain, the point at which the service primitives are invoked. A single SAP is defined independently of the signalling bearer. The SAP provides the SCCP primitives. The figure is not intended to constrain the architecture.

The following figure 1 also illustrates the protocol model having Broadband Signalling System No.7 as the signalling bearer for RANAP over the Iu interface that fulfils the requirements. Figure 1 shows, for the CS domain, the point at which the service primitives are invoked. The SAP provides the SCCP primitives.

Protocol stack for ATM transport option Protocol stack for IP transport option

Figure 1: SAP between RANAP and its transport for Iu – CS Domain

5.2.2 ATM Transport Option

1. SCCP (ITU-T Rec. Q.711 [7] 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. SCCP shall be used as specified in TS 25.410 [18].

2. 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. MTB3-B shall comply with ITU-T Rec. Q.2210 [4] or ANSI T1.111-2001 [31].

3. 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 (R2003) [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. It shall be possible to use SAAL-NNI connections pre-configured as PVCs for signalling transport on the Iu-Interface.

4. ATM (ITU-T Rec. I.361 [5]).

5.2.3 IP Transport Option

1. SCCP, see subclause 5.2.2.

2. 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 have client functionality. This enables the RNC to report to the MSC when it is a newly introduced entity in the network.

3. SCTP refers to the Stream Control Transmission Protocol (IETF RFC 2960 [16]) developed by the Sigtran working group of the IETF for the purpose of transporting various signalling protocols over IP networks. The checksum method specified in IETF RFC 3309 [30] shall be used instead of the method specified in IETF RFC 2960 [16]. 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.

4. IP. IPv6 shall be supported according to IETF RFC 2460 [25]. IPv4 support (IETF RFC 791 [13]) is optional.

Note: This does not preclude the single implementation and use of Ipv4.

Due to the possible transition from IPv4 to IPv6 the IP dual stack support is recommended.

An RNC/CN using IP transport option shall support Diffserv code point marking IETF RFC 2474 [26]. The Diffserv code point may be determined from the application parameters.

5.3 Signalling Bearer for Packet Switched Domain

5.3.1 Protocol Stack for the PS Domain

The protocol stacks for the PS Domain is shown in figure 2. The standard allows operators to choose one out of three standardised protocol suites for transport of SCCP messages.

Protocol stacks for ATM transport options Protocol stack for IP transport option

Figure 2: SAP between RANAP and its transport for the Iu –IP domain

Figure 2 shows, for the Iu IP domain, the point at which the service primitives are invoked. A single SAP is defined independently of the signalling bearer. The SAP provides the SCCP primitives. The figure is not intended to constrain the architecture.

5.3.2 ATM Transport Option 1

1. 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. The SCCP shall be used as specified in TS 25.410 [18].

3. SAAL-NNI (ITU-T Rec. Q.2100 [1]) consists of the following sub-layers: – SSCF-NNI (ITU-T Rec. Q.2140 [3] or ANSI T1.645-1995 (R2003) [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. It shall be possible to use SAAL-NNI connections pre-configured as PVCs for signalling transport on the Iu-interface.

4. ATM (ITU-T Rec. I.361 [5]).

5.3.3 ATM Transport Option 2

1. SCCP, see subclause 5.3.2.

2. 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 have client functionality. This enables the RNC to report to the SGSN when it is a newly introduced entity in the network.

3. SCTP refers to the Stream Control Transmission Protocol (IETF RFC 2960 [16]) developed by the Sigtran working group of the IETF for the purpose of transporting various signalling protocols over IP networks. The multi-homing services of SCTP shall be required at both ends of an SCTP-association to enable transport redundancy and reliability. M3UA. An implementation of SCTP to this document shall utilise the new checksum method specified in IETF RFC 3309 [30] instead of the method specified in IETF RFC 2960 [16].

4. IP (IETF RFC 791 [13]) over ATM is defined in IETF RFC 2684 [14] and IETF RFC 2225 [15].

5. AAL5 refers to ITU-T Rec. I.363.5 [6]. It shall be possible to use AAL5 connections pre-configured as PVCs for signalling transport on the Iu-interface.

5.3.4 IP Transport Option

1. SCCP , see subclause 5.3.2.

2. 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 have client functionality. This enables the RNC to report to the SGSN when it is a newly introduced entity in the network.

3. SCTP, refers to the Stream Control Transmission Protocol (IETF RFC 2960 [16]) developed by the Sigtran working group of the IETF for the purpose of transporting various signalling protocols over IP networks. An implementation of SCTP to this document shall utilise the new checksum method specified in IETF RFC 3309 [30] instead of the method specified in IETF RFC 2960 [16]. 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.

4. IP. IPv6 shall be supported according to IETF RFC 2460 [25]. IPv4 support (IETF RFC 791 [13]) is optional.

Note: This does not preclude the single implementation and use of IPv4.

Due to the possible transition from IPv4 to IPv6, the IP dual stack support is recommended.

An RNC/CN using IP transport option shall support Diffserv code point marking (IETF RFC 2474 [26]). The Diffserv code point may be determined from the application parameters.

5.4 Services Provided by the Signalling Bearer

When considering the requirements that the upper layers, i.e. RANAP, 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 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].

Annex A (informative):
Change History

Date / TSG	TSG Doc.	CR	Rev	Subject/Comment	New
12/2008	–	–	–	Creation of Rel-8 version based on v7.1.0	8.0.0
12/2009	–	–	–	Creation of Rel-9 version based on v8.0.0	9.0.0
03/2011	SP-100629			Clarification on the use of References (TS 21.801 CR#0030)	9.0.1
03/2011				Creation of Rel-10 version based on v9.0.1	10.0.0
06/2011	RP-110685	0026		Correction to the References in 25.412	10.1.0
09/2012				Update to Rel-11 version (MCC)	11.0.0
09/2014				Update to Rel-12 version (MCC)	12.0.0
12/2015				Update to Rel-13 version (MCC)	13.0.0

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
2017-03	SA#75					Promotion to Release 14 without technical change	14.0.0
2018-06	SA#80	–	–	–	–	Promotion to Release 15 without technical change	15.0.0
2020-07	SA#88-e	–	–	–	–	Update to Rel-16 version (MCC)	16.0.0
2022-03	SA#95-e					Promotion to Release 17 without technical change	17.0.0