For the purposes of the present document, the following term and definition applies: ALCAP:

For the purposes of the present document, the following abbreviations apply: AAL2 AESA ATM CPCS CPS DCH E-DCH HDLC HS-DSCH IP LC M3UA ML/MC MPLS MTP NNI NSAP PPP PT SAAL SAR SCTP SSCF SSCOP SSCS SSSAR STC UDP UNI

ATM shall be used in the transport network user plane and transport network control plane according to ITU-T Rec. I.361 [2].

A UTRAN node supporting IP transport option shall support PPP protocol IETF RFC 1661 [23] with HDLC framing (IETF RFC 1662 [24]). A UTRAN node supporting IP transport option and having interfaces connected via low bandwidth PPP links like E1/T1/J1 shall also support IP Header Compression (IETF RFC 2507 [25]) and the PPP extensions ML/MC-PPP (IETF RFC 1990 [26], IETF RFC 2686 [27]). In this case the negotiation of header compression (ITU-T Rec. I.630 [20]) over PPP shall be performed via IETF RFC 2509 [28].

The Frame Protocol for DCH and E-DCH data streams (TS 25.427) is the user of the transport layer specified in the present document. There are two options for the transport layer of the DCH and E-DCH data streams in Iur and Iub:

1. ATM based transport (ATM Transport Option)
2. IP based transport (IP Transport Option)

The following figure shows the protocol stacks of the two options.

Asynchronous Transfer Mode (ATM) (ITU-T Rec. I.361 [2]) and ATM Adaptation Layer type 2 (AAL2) (ITU-T Rec. I.363.2 [3], ITU-T Rec. I.366.1 [4]) are used as a transport layer for DCH and E-DCH data streams on Iur and Iub interfaces. Service Specific Segmentation and Reassembly (SSSAR) sublayer for AAL2 is used for the segmentation and reassembly of AAL2 SDUs.

UDP (IETF RFC 768 [17]) over IP shall be supported as the transport for DCH and E-DCH data streams on Iub and Iur interfaces. The data link layer is as specified in chapter 4.2. An IP UTRAN Node shall support IPv6 (IETF RFC 2460[29]). The support of IPv4 (IETF RFC 791[14]) is optional. IP dual stack support is recommended for the potential transition period from IPv4 to IPv6 in the transport network. The transport bearer is identified by the UDP port number and the IP address (source UDP port number, destination UDP port number, source IP address, destination IP address). The source IP address and destination IP address exchanged via Radio Network Layer on the Iur/Iub interface shall use the NSAP structure. See sub clause 6.1.8.2 of TS 25.401. IP Differentiated Services code point marking (IETF RFC 2474 [30]) shall be supported. The mapping between traffic categories and Diffserv code points shall be configurable by O&M. Traffic categories are implementation-specific and may be determined from the application parameters.

This chapter specifies the ALCAP protocol(s) to be used in Iur and Iub interfaces for DCH data streams.

AAL2 signalling protocol Capability Set 2 (ITU-T Rec. Q.2630.2 [22]) is the signalling protocol to control AAL2 connections on Iub and Iur interfaces. ITU-T Rec. Q.2630.2 [22] adds new optional capabilities to ITU-T Rec. Q.2630.1 [5]. Binding ID provided by the radio network layer shall be copied in SUGR parameter of ESTABLISH.request primitive of ITU-T Rec. Q.2630.2 [22]. User Plane Transport bearers for Iur interface are established, in all normal cases released and optionally modified by the ALCAP in the Serving RNC. The binding identifier shall already be assigned and tied to a radio application procedure when the Establish Request message is received over the Iur interface in the Drift RNC. User Plane Transport bearers for Iub interface are established, in all normal cases released and optionally modified by the ALCAP in the Controlling RNC. Binding identifier shall already be assigned and tied to a radio application procedure when the Establish Request message is received over the Iub interface in the Node B. In case of a Reset initiated by the CRNC, the ALCAP in the Node B shall release the transport bearers involved in the impacted Node B Communication Contexts. The Node B shall also initiate release of the user plane transport bearers for the removed dedicated channels that were remaining within the cell when the cell is deleted. AAL2 transport layer addressing is based on embedded E.164 or other AESA variants of the NSAP addressing format (ITU-T Rec. E.191 [6], ITU-T Rec. X.213 [7]). Native E.164 addressing (ITU-T Rec. E.164 [36]) shall not be used. The Link Characteristics parameter (LC) shall be included in the Establish Request message and in the Modification Request message of AAL2 signalling protocol. If there is an AAL2 switching function in the transport network layer of the interface, the Path Type parameter (PT) may be included in the Establish Request message of AAL2 signalling protocol for prioritisation at ATM level. If the value in either the Maximum CPS-SDU Bit Rate or the Average CPS-SDU Bit Rate of the Link Characteristics(LC) in AAL2 signalling messages as specified in reference ITU-T Rec. Q.2630.2 [22] is 2048 Kbit/s, it shall be interpreted as bit rate 2048 Kbit/s or higher.

An ALCAP protocol is not required in case both UTRAN nodes are using the IP transport option. Application of ALCAP in IP to ATM interworking case is defined in chapter 9 of this Technical Specification.

This clause specifies the signalling bearer for the ALCAP on Iub interface.

SAAL-UNI (ITU-T Rec. Q.2110 [8], ITU-T Rec. Q.2130 [9]) is used as the signalling bearer for the AAL Type 2 Signalling protocol on Iub interface. Signalling Transport Converter for SSCOP is applied ITU-T Rec. Q.2150.2 [10]. The following figure shows the signalling bearer protocol stack for the ALCAP on Iub interface.

An ALCAP protocol is not required in case both UTRAN nodes are using the IP transport option.

This clause specifies the signalling bearer for the ALCAP on the Iur interface.

There are two protocol stacks specified for Iur ALCAP Signalling Bearer in ATM option - one based on MTP-3B (ITU-T Rec. Q.2210 [11], ITU-T Rec. Q.Imp2210 [21]) and SAAL-NNI (ITU-T Rec. Q.2140 [12], ITU-T Rec. Q.2110 [8]) and the other based on SCTP (IETF RFC 2960 [18]). Signalling Transport Converter for MTP-3B is applied (ITU-T Rec. Q.2150.1 [13]). MTP-3 User Adaptation Layer (M3UA) for SCTP is applied in IETF RFC 3332 [19]. Classical IP over ATM is specified in IETF RFC 2225 [16]. Multiprotocol Encapsulation over AAL5 is specified in IETF RFC 1483 [15].The checksum method specified in IETF RFC 3309 [37] shall be used instead of the method specified in IETF RFC 2960 [18]. The following figure shows the signalling bearer protocol stacks for the ALCAP on Iur interface.

An ALCAP protocol is not required in case both UTRAN nodes are using the IP transport option.

This clause specifies the interworking between IP and ATM transport options. A UTRAN node supporting IP transport option shall provide interworking to a UTRAN node supporting only ATM transport option.

For interworking with a UTRAN node supporting only ATM option, the UTRAN node supporting IP option shall additionally support at least one of the following interworking mechanisms:

1. ATM&IP dual stack. An ALCAP protocol is not required in this interworking solution.
   Annex A of TS 25.414 shows an example of protocols for the case the ATM&IP RNC/CN-node has no ATM connectivity.
2. An Interworking Function (IWF), either internal or external to the UTRAN node. AAL2 signalling protocol Capability Set 2 (ITU-T Rec. Q.2630.2 [22]) shall be supported as ALCAP protocol between the Interworking Function and the UTRAN node supporting ATM transport option.

Annex A of TS 25.414 shows an example of a protocol stack for the bearer control protocol between the RNC/CN IP Node and its IWF for the case when the IWF is an external unit to the RNC/CN node. Other protocol stacks for this case are not precluded.