For the purposes of the present document, the following terms and definitions apply: Elementary Procedure: Prepared Reconfiguration: UE Context: Distant RNC Context: Signalling radio bearer 2: UE Link: URA Link: MBMS Bearer Service: MBMS session: MBMS session start: MBMS session stop: MBMS Selected Services: PUESBINE feature:

Void.

For the purposes of the present document, the following abbreviations apply: A-GPS ALCAP APN ASN.1 BDS BER BLER BSS CBSS CCCH CCPCH CCTrCH CFN C-ID CM CN CPICH CRNC CLTD DBDS DBSS C-RNTI CS CTFC DGANSS DGPS DL DPC DPCCH DPCH DPDCH DRNC DRNS D-RNTI DRX DSCH Ec E-AGCH E-DCH E-HICH E-PUCH E-RNTI E-RUCCH E-TFCI E-UCCH E-UTRA EDSCHPC EGNOS EP FACH FDD F-DPCH FN FP F-TPICH GANSS GERAN GA GAGAN GAI GLONASS GNSS GPS GRA GSM GWCN HSDPA HW IB ICD ID IE IMSI IP IPDL ISCP LAC LCR LCS MAC MBMS MDT MOCN MRNC MS MSAS NACC NAICS NAS No NRT O&M P(-)CCPCH PCH OTD P(-)CPICH PCS PDSCH PDU PhCH PICH PLCCH Pos PRACH PTP PTM PS PUESBINE QE QZSS RAC RACH RAN RANAP RB RL RLC RLS RM RNC RNS RNSAP RNTI RRC RT RSCP SBAS SBSS Rx Sat SCCP S(-)CCPCH SCH SCTD S-DPCCH SDU SF SFN SHCCH SIR SNA SRB2 SRNC SRNS S-RNTI STTD TDD TF TFCI TFCS TFS TGCFN TMGI ToAWE ToAWS TPC TrCH TS TSG TSTD TTI TX UARFCN UDP UC-ID UE UL UMTS URA U-RNTI USCH UTC UTRA UTRAN WAAS

The principle for specifying the procedure logic is to specify the functional behaviour of the DRNC/CRNC exactly and completely. The SRNC functional behaviour is left unspecified. The Physical Channel Reconfiguration procedure, [TDD - the UE Measurement Inititation, the UE Measurement Reporting, UE Measurement Termination, UE Measurement Failure,] and the Reset procedure are an exception from this principle. The following specification principles have been applied for the procedure text in subclause 8:

• The procedure text discriminates between:
  1. Functionality which "shall" be executed
     The procedure text indicates that the receiving node "shall" perform a certain function Y under a certain condition. If the receiving node supports procedure X but cannot perform functionality Y requested in the REQUEST message of a Class 1 EP, the receiving node shall respond with the message used to report unsuccessful outcome for this procedure, containing an appropriate cause value.
  2. Functionality which "shall, if supported" be executed
     The procedure text indicates that the receiving node "shall, if supported," perform a certain function Y under a certain condition. If the receiving node supports procedure X, but does not support functionality Y, the receiving node shall proceed with the execution of the EP, possibly informing the requesting node about the not supported functionality.

Any required inclusion of an optional IE in a response message is explicitly indicated in the procedure text. If the procedure text does not explicitly indicate that an optional IE shall be included in a response message, the optional IE shall not be included. For requirements for including Criticality Diagnostics IE, see section 10. For examples on how to use the Criticality Diagnostics IE, see Annex C.

The forwards and backwards compatibility of the protocol is assured by a mechanism in which all current and future messages, and IEs or groups of related IEs, include ID and criticality fields that are coded in a standard format that will not be changed in the future. These parts can always be decoded regardless of the standard version.

The sender of an RNSAP messages shall include the Source Signalling Address, i.e. the Signalling Address of the sending node.

For the purposes of the present document, the following notations apply: [FDD] [TDD] [3.84Mcps TDD] [1.28Mcps TDD] [7.68Mcps TDD] [FDD - …] [TDD - …] [3.84Mcps TDD - …] [1.28Mcps TDD - …] [7.68Mcps TDD - …] Procedure Message IE Value of an IE

The Iur interface RNSAP procedures are divided into five modules as follows:

1. RNSAP Basic Mobility Procedures;
2. RNSAP Dedicated Procedures;
3. RNSAP Common Transport Channel Procedures;
4. RNSAP Global Procedures;
5. RNSAP MBMS Procedures.

The Basic Mobility Procedures module contains procedures used to handle the mobility within UTRAN, within GERAN and between UTRAN and GERAN. The Dedicated Procedures module contains procedures that are used to handle DCHs, [FDD - F-DPCH,] [TDD - DSCHs, USCHs], HS-DSCH and E-DCH between two RNSs. If procedures from this module are not used in a specific Iur, then the usage of DCH, [FDD - F-DPCH,] [TDD - DSCH, USCH,] HS-DSCH and E-DCH traffic between corresponding RNSs is not possible. The Common Transport Channel Procedures module contains procedures that are used to control common transport channel data streams (excluding the DSCH, HS-DSCH and USCH) over Iur interface. The Global Procedures module contains procedures that are not related to a specific UE. The procedures in this module are in contrast to the above modules involving two peer CRNCs/CBSSs. The MBMS Procedures module contains procedures that are specific to MBMS and used for cases that cannot be handled by other modules.

Unless explicitly indicated in the procedure specification, at any instance in time one protocol peer shall have a maximum of one ongoing RNSAP Dedicated procedure related to a certain UE.