. 76
( 132 .)


communicating entities, such as rate control and error control. An example of the use of
support mode is for the transfer of AMR speech PDUs. Transparent mode
As mentioned, the transparent mode is very simple in structure as it adds no overhead to
the data, and simply provides the following services:

• user data transfer;
• in-sequence delivery of user data, if required by the RAB being transferred, as de¬ned
at RAB establishment.

The frame format is shown in Figure 6.90. There is no restriction on the length, which
is dependent on the nature of the user data being conveyed. The transparent mode does
not carry a length ¬eld and this information will be supplied by a higher layer.

byte 1


byte n

Figure 6.90 Transparent mode
6.18 FRAME PROTOCOLS 365 Support mode for prede¬ned SDU sizes

The support mode adds a frame protocol overhead to the data and also offers a number
of control functions to provide the necessary support. The functions provided by support
mode are:

• user data transfer, in-sequence if required
• initialization
• rate control
• time alignment
• error handling
• frame quality classi¬cation.

For user data transfer, there are two frame formats de¬ned:

• data transfer with error detection (PDU type 0)
• data transfer with no error detection (PDU type 1).

The frame format for type 0 is shown in Figure 6.91(a) below. It has a ¬xed 4-byte
header and a variable length payload, which is padded to a byte boundary. There is also
a spare extension at the end (not shown) to allow for the addition of extra ¬elds in future
versions. It is not currently used.
The header ¬elds are de¬ned as follows:

• PDU type (4 bits): this indicates the type of PDU, in this case, 0.
• Frame number (4 bits): this acts as a sequence number and allows a destination to
check the PDU order and check for lost frames.

byte 1
PDU Type (0) Frame No

byte 2 byte 1
FQC RFCI PDU Type (1) Frame No
Payload byte 3 byte 2
byte 4 byte 3
Payload CRC Header CRC Spare

Payload Payload


byte n byte n
Payload PAD Payload PAD

(a) (b)

Figure 6.91 Support mode PDU type (a) 0 and (b) 1

• Frame quality classi¬cation (FQC, 2 bits): this is used to indicate to the destination the
state of frames received. This parameter is valid if the RAB has been established with
the attribute ˜Delivery of erroneous SDUs™ set to YES. If this attribute has been set to
NO, then SDUs that contain errors are discarded. The possible values for the FQC are
listed in Table 6.31.
In the uplink direction, the FQC chosen is dependent on whether the radio frame quality
classi¬cation has been set to ˜good™ or ˜bad™, which will be assessed on the basis of
whether the frame received at the RNC on the Iub interface has achieved its required
QoS based on BER/BLER. If the RAB attribute ˜Delivery of erroneous SDUs™ is set to
no-error detection-consideration, the FQC is irrelevant. If at least one of the sub¬‚ows
in the payload has ˜Delivery of erroneous SDUs™ set to YES or NO, Table 6.32 shows
the actions of the RNC and how the FQC is chosen.
In the downlink direction, the same rules apply for setting of the FQC, except that
˜bad™ is used instead of ˜bad radio™ since the quality classi¬er will be a CRC check.
Considering an AMR voice call, the class A part will have the ˜Delivery of erroneous
SDUs™ attribute set to YES, since actions need to be taken if this section contains
errors; however the class B and C bits will be set to no-error detection-consideration.
• RAB sub¬‚ow combination indicator (RFCI, 6 bits): the RFCI is used to indicate to the
destination the structure of the payload data. The payload may contain one or more
RAB sub¬‚ows. The de¬nition of the allowed sub¬‚ow combinations is de¬ned by the
initialization procedure, described shortly.
• Header CRC (6 bits): this provides error protection for the frame protocol header.
• Payload CRC (10 bits): this provides error protection for the frame protocol payload,
including the padding section, if present.

The format of PDU type 1 is almost the same (Figure 6.91(b)). The only differences
are that the PT ¬eld will be ˜1™ to indicate PDU type 1, and the payload CRC is absent.

Table 6.31 FQC values
Value Indication

0 Frame good
1 Frame bad
2 Frame bad due to radio
3 Not used

Table 6.32 FQC actions
Delivery of Radio frame quality Action
erroneous SDUs classi¬cation
YES Good FQC set to ˜good™
Bad FQC set to ˜bad radio™
NO Good FQC set to ˜good™
Bad Frame is discarded

6.18.5 Control procedures
To support the data transfer function, there are a number of control procedures de¬ned.
These procedures use a PDU type 14 (PT = 14), the general format of which is shown
in Figure 6.92.
Several of the ¬elds are the same as for the preceding PDU types; however, there are
a few different ¬elds:

• Ack/nack (2 bits): the control procedures require a reliability mechanism to ensure
correct operation. Therefore each control procedure exchange is acknowledged, and
the acknowledgement indicates successful or unsuccessful operation, as shown in
Figure 6.93. This ¬eld indicates whether the PDU type 14 is a control frame, a positive
(ACK) or negative (NACK) acknowledge, as shown.
• Frame number (2 bits): for control frames, the frame number is again to allow the
destination to check for missing frames. It is also used in the acknowledgement mech-
anism, and the same frame number is used in the ack/nack as was used in the control
frame being acknowledged.

ACK/ Frame
byte 1
PDU Type (14)
byte 2
Iu UP Mode ver.
byte 3
Header CRC

byte 4
Payload CRC

Procedure Data

byte n
Procedure Data

Figure 6.92 Control PDU general format

RNC or CN CN or RNC Procedure
ACK/NACK Indication 0 Initialization
0 Control frame 1 Rate control
control procedure
1 Positive ack 2 Time alignment
2 Negative ack 3 Error event
3 Not used 4-15 Currently unused

Figure 6.93 Acknowledge procedure

• Iu UP mode version (4 bits): this indicates the version of the UP mode being transferred.
There can be up to 16 mode version available at the same time. This parameter is to
allow new UP mode versions in the future. Currently the mode version is 1.
• Procedure indicator (4 bits): this indicates which control procedure is contained within.
Permitted values are shown in Figure 6.93. Initialization procedure
For RABs that are using the support mode, prior to the transfer of user data, the destination
must know the format of the RAB sub¬‚ows contained within the UP frame. The initial-
ization procedure originates at, and is controlled by, the SRNC. An RFCI is allocated by
the SRNC to each sub¬‚ow combination that may occur within the payload. For example,
consider that a RAB is established to transport GSM enhanced full-rate speech (EFR,
12.2 kbps). In accordance with the speci¬cation, EFR consists of three RAB sub¬‚ows
with different QoS requirements and hence different BERs. Also, accompanied with EFR
are two other rates, one for SID (silence descriptor) in silence suppression mode, where
comfort noise is transferred, and one for DTX. The sub¬‚ows are as shown in Figure 6.94.
The SRNC will allocate the RFCIs for each sub¬‚ow combination, and this information
is passed on during the initialization procedure (Figure 6.95).
RAB subflow combination

RFCI Total
subflow 1 subflow 2 subflow 3

0 81 103 60 244

1 39 0 0 39

2 0 0 0 0

Figure 6.94 Example RAB sub¬‚ows


initialisation (RFCI)


user data transfer

Figure 6.95 Initialization procedure

byte 1
PDU Type (14) ACK/NACK Frame No.

byte 2
Iu UP Mode ver. Procedure Indicator

byte 3
Header CRC


. 76
( 132 .)