<<

. 77
( 132 .)



>>


byte 4
Payload CRC

no. of subflows
spare TI CI
per RFCI

LRI LI First RFCI

Length of subflow 1

Length of subflow 2 to N

LRI LI Second RFCI

Length of subflow 1

Length of subflow 2 to N

...

IPTI first RFCI IPTI second RFCI

IPTI third RFCI ...

Iu UP versions supported

byte n
Data PDU type spare


Figure 6.96 Initialization procedure frame format


The frame format of the initialization procedure is shown in Figure 6.96. It contains
the RFCI and the format of each of the sub¬‚ows.
The header follows the PDU type 14 format. The ¬elds in the payload are de¬ned as:

• Timing information (TI, 1 bit): indicates if the frame contains timing information, con-
tained in the optional IPTI ¬elds. A 1 indicates that the IPTI ¬eld is present for
each RFCI.
• Chain indicator (CI, 1 bit): indicates whether this is the last control procedure frame
related to a particular control procedure, 0 for last frame.
• Last RFCI indicator (LRI, 1 bit): a value of 1 indicates that this is the last RFCI de¬ned.
• Length indicator (LI, 1 bit): a value of 0 indicates that the length values are 1 byte,
whereas 1 indicates a 2-byte length ¬eld.
370 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM


• Inter PDU transmission interval (IPTI, 4 bits): this is the interval at which Iu UP
PDUs can be sent at a given time for a particular RAB sub¬‚ow combination (RFC). It
is calculated according to:

IPTI = RFC size/RFC bit rate

If unde¬ned, it is equal to the Iu Timing Interval (ITI), which is de¬ned as:

ITI = Max SDU size/Max bit rate

• Iu UP versions supported: indicates which of the Iu UP versions are supported. Cur-
rently there is only one version de¬ned.
• Data PDU type (4 bits): indicates which PDU type (0 or 1) will be used for the
data transfer.

Returning to the previous example, an initialization message for the RAB sub¬‚ows
would look as shown in Figure 6.97.


RNC -> CN
AAL2
HEX
UUI: 0 (00h)
SSSAR-PDU: E0 00 DF C5 16 00 51 67
E0 14 0 1
3C 81 27 00 00 11 01 00
PDU 14 INITIALIZATION 00 0 0
Cont./ACK/NACK : 0 (Control procedure frame)
P
PDU 14 Frame Number : 0 (00h) Header CRC
DF
CRC
Iu UP Mode Version : 1 (01h)
Procedure Indicator : 0 (Initialization procedure Payload CRC
C5
Frame Checksums :
- Header CRC: 55 (37h) 16 0 0 3 0
- Payload CRC: 965 (3C5h)
Initialization : 00 0 0 0
- TI: 1 (01h)
- Number of subflows per RFCI: 3 (03h) 51 81
- Chain Ind: 0 (Procedures last frame)
67 103
- LRI: 0 (00h)
- Length Indicator: 0 (1 oct. subflow size info)
3C 60
- 1.RFCI: 0 (00h)
- Length of subflow 1: 81 (51h)
81 1 0 1
- Length of subflow 2: 103 (67h)
- Length of subflow 3: 60 (3Ch)
27 39
- LRI: 1 (01h)
- Length Indicator: 0 (1 oct. subflow size info)
00 0
- 2.RFCI: 1 (01h)
- Length of subflow 1: 39 (27h)
00 0
- Length of subflow 2: 0 (00h)
- Length of subflow 3: 0 (00h)
IPTI RFCI 0 IPTI RFCI 1
11
- IPTI of 1.RFCI: 1 (01h)
- IPTI of 2.RFCI: 1 (01h)
Iu UP versions supported
01
Versions Supported : 01
- Version 1: Supported
00 0 spare
Data PDU Type 0 (PDU Type 0)


Figure 6.97 Example initialization PDU. Reproduced by permission of NetHawk Oyj
6.19 UMTS TERRESTRIAL RADIO ACCESS NETWORK (UTRAN) 371


Table 6.33 Error causes
Error in CRC of frame header Unexpected PDU type
Error in CRC of frame payload Unexpected procedure
Unexpected frame number Unexpected RFCI
Frame loss Unexpected value
PDU type unknown Initialization failure
Unknown procedure Rate control failure
Unknown reserved value Error event failure
Unknown ¬eld Time alignment not supported
Frame too short Requested time alignment not possible
Missing ¬elds Iu UP mode version not supported


6.18.5.2 Error handling
The error handling procedure is invoked in response to either error detection by another
Iu UP procedure, such as receipt of a malformed or erroneous frame, or by request from
an upper layer. The procedure contains an indication of the cause of the error, as listed
in Table 6.33.



6.19 UMTS TERRESTRIAL RADIO ACCESS
NETWORK (UTRAN)

Figure 6.98, shows the general protocol model for the interfaces within the UTRAN. It
is divided into two horizontal layers, the radio network layer and the transport network
layer. This separation is explicitly made so as to de¬ne clearly the role of each. The
transport layer is a generic layer that offers bearer services to the radio network layer.
This transport layer is currently implemented using ATM technology, but its separation
and de¬nition of primitives between the layer allows for the use of alternative transport
technologies.
The radio network layer consists of a control plane and a user plane. The control plane
is an application protocol, which de¬nes the mechanisms used for establishing, releasing
and managing bearers, as well as ancillary control procedures. The radio network user
plane consists of the user data streams, and will be a UMTS transport channel plus a
frame protocol for a given interface. It should be noted that ˜user data™ at this layer also
encompasses control data for higher layers. As an example, on the Iub interface, the radio
network user plane transports both RRC and NAS signalling messages.
The transport network layer offers the service of transport bearers for both signalling
and data streams, where the signalling is the application protocol of the upper layer. These
two bearer services are considered to be user plane at the transport network layer. In turn,
the transport network layer needs its own control plane and protocols to establish, manage
and release its own bearers. The generic name for this control plane component is the
access link control application protocol (ALCAP). Again, in the context of UMTS, this is
currently a protocol that is part of the ATM family, AAL2 signalling, which is discussed
in Section 7.14.2.
372 UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM


Radio Transport User
Network Network Plane
Control Plane Control Plane
Radio
Network
Layer
Application User
Protocol Data




ALCAP




Transport
Signalling Signalling Data
Network
Bearer Bearer Bearer
Layer




Physical Layer




Figure 6.98 General protocol model for UTRAN interfaces


The ALCAP has its own signalling bearer to transport its control messages. A sim-
ple example of how these different protocol stacks may interact with each other is
now listed:

1. A NAS message such as a CM service request would be sent from the higher layers
of the user plane of the UE.
2. This would request that the network instruct the radio network control plane to set up
a radio bearer.
3. The radio network control plane would then ask the transport network control plane
to actually do this.

It would be possible to have only two planes laid out within the speci¬cation pro-
cess, the user plane and the radio network control plane. However, although introducing
a separate transport network control plane adds considerable complexity, it does enable
¬‚exibility of the underlying network, giving an operator the option of ATM or IP in later
releases.
6.19 UMTS TERRESTRIAL RADIO ACCESS NETWORK (UTRAN) 373


6.19.1 Iub interface
The Iub interface connects the BTS to the RNC. As previously mentioned, this is
point-to-point in nature and is therefore a UNI interface. Its structure is shown in
Figure 6.99.
The naming convention for the application parts is based on the node or subsystem to
which they are connecting. So for the Iub, the interface connects to the BTS or Node B,
so the application part is Node B application part (NBAP). The radio network user plane
consists of the transport channels, for example, the FACH and RACH, DCH etc. In the
transport network layer, the radio network user plane is offered the AAL2 adaptation layer
for transport of user data. It has been seen that the user data across the Uu air interface has
been fragmented into small segments by the RLC layer. The fragments continue across
the Iub and the reassembly of these only takes place at the RNC, and not at the BTS.
AAL2 is used to transport these small segments in its CPS-PDU, and allows them to
be multiplexed together across a single virtual circuit. A channel ID is used to identify
each individual AAL2 channel stream. For signalling transport, in this case NBAP, the
only requirement is a bearer that can provide robust, in-sequence delivery of signalling


Radio Transport User
Network Network Plane
Control Plane Control Plane
Radio
Network
Layer
NBAP User Data




Q.2630.1

Q.2150.2

SSCF-UNI SSCF-UNI

Transport SSCOP SSCOP
Network
AAL5 AAL5 AAL2
Layer


ATM

<<

. 77
( 132 .)



>>