Content for TS 25.471 Word version: 18.0.0

3.1 Definitions 3.2 Abbreviations 4.1 Procedure Specification Principles 4.2 Forwards and Backwards Compatibility 4.3 Specification Notations 5.1 General 5.2 Parallel Transactions
...

1 Scope p. 6

The present document specifies the RNSAP User Adaption (RNA) supporting Iurh-connectivity between HNBs as specified in TS 25.467 by adapting the services made available by the Iurh signalling transport layer to the needs of RNSAP. It provides transparent transport for RNSAP messages in connection-oriented and connectionless mode and an Iurh setup function.

2 References p. 7

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.

[1] Void

[2] Void

[3]

TS 25.467: "UTRAN architecture for 3G Home NodeB"

[4]

TS 25.423: "UTRAN Iur interface Radio Network Subsystem Application Part (RNSAP) signalling"

[5]

TR 25.921: (version.7.0.0) "Guidelines and Principles for Protocol Description and Error Handling".

[6]

TR 21.905: "Vocabulary for 3GPP Specifications".

[7]

ITU-T Recommendation X.691 (2002-07): "Information technology - ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)".

[8]

ITU-T Recommendation X.680 (2002-07): "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation".

[9]

ITU-T Recommendation X.681 (2002-07): "Information technology - Abstract Syntax Notation One (ASN.1): Information object specification".

[10] Void

[11] Void

[12]

TS 25.331: "Radio Resource Control (RRC) Protocol Specification".

3 Definitions and abbreviations p. 7

3.1 Definitions p. 7

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

Elementary Procedure:

RNA consists of Elementary Procedures (EPs). An Elementary Procedure is a unit of interaction between HNBs. These EPs are defined separately and are intended to be used to build up complete sequences in a flexible manner. If the independence between some EPs is restricted, it is described under the relevant EP description. Unless otherwise stated by the restrictions, the EPs may be invoked independently of each other as stand alone procedures, which can be active in parallel.

An EP consists of an initiating message and possibly a response message. Two kinds of EPs are used:

Class 1: Elementary Procedures with response (success or failure).
Class 2: Elementary Procedures without response.

For Class 1 EPs, the types of responses can be as follows:

Successful

A signalling message explicitly indicates that the elementary procedure successfully completed with the receipt of the response.

Unsuccessful

A signalling message explicitly indicates that the EP failed.
On time supervision expiry (i.e. absence of expected response).

Class 2 EPs are considered always successful.

3.2 Abbreviations p. 8

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

Elementary Procedure

HNB

Home Node B

PDU

Protocol Data Unit

RNA

RNSAP User Adaption

RNS

Radio Network Subsystem

RNSAP

Radio Network Subsystem Application Part

SCTP

Stream Control Transmission Protocol

4 General p. 8

The protocol described in the present document is the protocol between Iurh-connected HNBs providing adaptation of services of the Iurh signalling transport layer to the needs of RNSAP and an Iurh setup function.

4.1 Procedure Specification Principles p. 8

The principle for specifying the procedure logic is to specify the functional behaviour of the HNBs exactly and completely.

The following specification principles have been applied for the procedure text in clause 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.

4.2 Forwards and Backwards Compatibility p. 9

The forwards and backwards compatibility of the protocol is assured by mechanism where 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.

4.3 Specification Notations p. 9

For the purposes of the present document, the following notations apply:

Procedure

When referring to an elementary procedure in the specification the Procedure Name is written with the first letters in each word in upper case characters followed by the word "procedure", e.g. Direct Transfer procedure.

Message

When referring to a message in the specification the MESSAGE NAME is written with all letters in upper case characters followed by the word "message", e.g. DIRECT TRANSFER message.

When referring to an information element (IE) in the specification the Information Element Name is written with the first letters in each word in upper case characters and all letters in Italic font followed by the abbreviation "IE", e.g. HNB Identity IE.

Value of an IE

When referring to the value of an information element (IE) in the specification the "Value" is written as it is specified in subclause 9.2 enclosed by quotation marks, e.g. "Abstract Syntax Error (Reject)".

5 RNA Services p. 9

5.1 General p. 9

RNA provides the signalling service between Iurh-connected HNBs that is required to fulfil the RNA functions described in Clause 7.

5.2 Parallel Transactions p. 9

Unless explicitly indicated in the procedure description, at any instance in time one protocol peer shall have a maximum of one ongoing RNA procedure related to a specific connection-oriented signalling Context.

6 Services expected from the Transport layer p. 9

Following service is expected from the transport layer:

Reliable and in sequence delivery of Signalling data.

7 Functions of RNA p. 9

The RNA has the following functions:

Transparent transfer of RNSAP messages
Setup of an Iurh connection
Error Handling. This function allows the reporting of general error situations, for which function specific error messages have not been defined.

These functions are implemented by one or several RNA elementary procedures described in the following clauses.