Radio Bearers Description (2008!05!30)

Huawei Proprietary and Confidential
Copyright Huawei Technologies Co., Ltd

RAN

Radio Bearers Description

Issue 01
Date 2008-05-30

Huawei Proprietary and Confidential

Huawei Technologies Co., Ltd. provides customers with comprehensive technical support and service. For
any assistance, please contact our local office or company headquarters.

Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com

Copyright Huawei Technologies Co., Ltd. 2008. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute the warranty of any kind, express or implied.

RAN
Radio Bearers Description Contents

Issue 01 (2008-05-30) Huawei Proprietary and Confidential
i

Contents
1 Radio Bearers Change History ................................................................................................1-1
2 Radio Bearers Introduction......................................................................................................2-1
3 Radio Bearers Principles...........................................................................................................3-1
3.1 Service Specifications ...................................................................................................................................3-1
3.1.1 SRB Specifications ..............................................................................................................................3-1
3.1.2 TRB Specifications ..............................................................................................................................3-1
3.1.3 Combined Service Specifications ........................................................................................................3-4
3.1.4 MBMS Service Specifications .............................................................................................................3-5
3.2 Transport Channel Selection .........................................................................................................................3-5
3.2.1 Mapping of Signaling and Traffic onto Transport Channels ................................................................3-5
3.2.2 Mapping of Combined Services onto Transport Channels...................................................................3-8
3.3 RLC Configuration........................................................................................................................................3-9
3.3.1 RLC Modes..........................................................................................................................................3-9
3.3.2 RLC Parameters in Different Modes.................................................................................................. 3-11
3.3.3 Default RLC Parameters for Different Services.................................................................................3-13
3.4 Control of HS-DSCH Transmission and Reception ....................................................................................3-24
3.4.1 Data Transmission..............................................................................................................................3-24
3.4.2 Data Reception...................................................................................................................................3-25
3.5 Control of E-DCH Transmission and Reception.........................................................................................3-26
3.5.1 Data Transmission..............................................................................................................................3-26
3.5.2 Data Reception...................................................................................................................................3-26
3.5.3 Serving Grant .....................................................................................................................................3-27
3.5.4 HSUPA TTI Selection Algorithm.......................................................................................................3-28
3.5.5 HSUPA Service Scheduling Modes ...................................................................................................3-29
4 Radio Bearers Reference Documents .....................................................................................4-1

RAN
Radio Bearers Description 1 Radio Bearers Change History

1-1

1 Radio Bearers Change History
Radio Bearers Change History provides information on the changes between different
document versions.
Document and Product Versions
Table 1-1 Document and product versions
Document Version RAN Version RNC Version NodeB Version
01 (2008-05-30) 10.0 V200R010C01B051 V100R010C01B049
V200R010C01B040
Draft (2008-03-20) 10.0 V200R010C01B050 V100R010C01B045

There are two types of changes, which are defined as follows:

Feature change: refers to changes in the radio bearers feature of a specific product
version.

Editorial change: refers to changes in information that has already been included, or the
addition of information that not provided in the previous version.
01 (2008-05-30)
This is the document for the first commercial release of RAN10.0.
Compared with draft (2008-03-20) of RAN10.0, issue 01 (2008-05-30) of RAN10.0
incorporates the changes described in the following table.
Change
Type
Change Description Parameter Change
Feature
change
HSUPA TTI Selection Algorithm is
added. For detailed information, see
3.5.4 HSUPA TTI Selection
Algorithm.
The parameters than are changed to
non-configurable are listed as
follows:

SRB over HSPA periodic Retry
timer length

Explicit-ind slide RX window
RAN

1-2 Huawei Proprietary and Confidential
Issue 01 (2008-05-30)

Change
Type
timing

Explicit-ind SDU discard timing

Explicit-ind MRW command
max re-TX number

No-explicit-ind SDU discard

Discard PDU max TX

Discard slide RX window timing

Discard MRW command max
re-TX number

No-Discard PDU max TX

UM-TM RLC discard mode
selection

UL RLC segment indication

DL RLC segment indication

UM-TM RLC discard mode
selection

TX window size

TX window size limit

RX window size

RX window size limit

Last TX PDU poll indication

Last re-TX PDU poll indication

PDU poll frequency

SDU poll frequency

Poll window

Poll prohibit timer

re-TX poll timer

Periodical poll interval

Missing PDU indication

Status report prohibit timer

State report period transmission
timer

Reset timer duration

Max resetting times

Deliver data by sequence order
on RNC side

The Number of HS-DSCH
MAC-D PDU Size

HS-DSCH MAC-D PDU size1


RAN

1-3

Change
Type






MAC-hs window size

The Number of E-DCH MAC-D
PDU Size

E-DCH MAC-D PDU size1












MAC-ES window size
Editorial
change
General documentation change:

The Radio Bearers Parameters is
removed because of the creation of
RAN10.0 parameter Reference.

The structure is optimized.
None.

Draft (2008-03-20)
This is the draft of the document for first commercial release of RAN10.0.
Compared with issue 03 (2008-01-20) of RAN 6.1, this issue incorporates the changes
described in the following table.
Change
Type
Feature
change
In Service Specifications:

The SRB index of the 3.4 kbit/s signaling
is changed to 1.

is changed to 2.
None.
RAN

Issue 01 (2008-05-30)

Change
Type

is changed to 3.

The TRB parameters of the 38.8 kbit/s
conversational service are added.


The TRB parameters of the 40 kbit/s


The maximum number of MBMS sessions
supported by the 64 kbit/s streaming
service is changed to 16.

MBMS streaming service are added.

MBMS streaming service are added.

The description of the MBMS background
service is added.

The description of the capability of a cell
to support the MBMS service is added.
In Mapping of Signaling and Traffic onto
Transport Channels:

Signaling can be carried on the HS-DSCH
or E-DCH. The mapping of signaling onto
transport channels is added.

The MBMS service can be carried on the
DCH or HS-DSCH.

If an SRB fails to be admitted to an HSPA
channel, it is carried on the DCH. The
corresponding description and parameters
are added.

The mapping of the PS conversational
service to transport channels is changed.

The command including the following
parameters is changed to SET
FRCCHLTYPEPARA:
- DL streaming threshold on HSDPA
- UL streaming traffic threshold on
HSUPA
- DL BE traffic DCH decision threshold
- UL BE traffic DCH decision threshold
- DL BE traffic threshold on HSDPA
- UL BE traffic threshold on HSUPA

The mapping of the IMS signaling to
The added parameters are listed
as follows:

Srb channel type

Srb channel type RRC
effect flag

SRB over HSPA periodic
Retry timer length

Voip channel type

IMS channel type

H Retry timer length
The deleted parameters are
listed as follows:

DL conversation threshold
on HSDPA

PS_CONVERSATION_ON
_HSDPA_SWITCH

UL conversation traffic
threshold on HSUPA

PS_CONVERSATION_ON
_E_DCH_SWITCH
RAN

1-5

Change
Type
transport channels is added.

If a service fails be admitted to an HSPA
channel, it is carried on the DCH. The
corresponding description and parameters
are added.
In Default RLC Parameters for Different
Services:

The default RLC parameters of the PS
conversational service with an RAB index
of 16 are added.

of 17 are added.

of 18 are added.

of 19 are added.
None.
In 3.4 Control of HS-DSCH Transmission
and Reception:

The description of the number of
HS-DSCH MAC-d PDUs is added.

The description of the size of HS-DSCH
MAC-d PDU is changed.
as follows:

The Number of HS-DSCH
MAC-D PDU Size

HS-DSCH MAC-D PDU
size1

HS-DSCH MAC-D PDU
size2

HS-DSCH MAC-D PDU
size3

HS-DSCH MAC-D PDU
size4

HS-DSCH MAC-D PDU
size5

HS-DSCH MAC-D PDU
size6

HS-DSCH MAC-D PDU
size7

HS-DSCH MAC-D PDU
size8
The parameter HSUPA service
rate augment scale is changed
to HSUPA service rate extend
scale.
The deleted parameter is
HS-DSCH MAC-D PDU size.
RAN

Issue 01 (2008-05-30)

Change
Type
In 3.5 Control of E-DCH Transmission and
Reception:

The description of the number of E-DCH
MAC-d PDUs is added.

The description of the size of E-DCH
MAC-d PDU is changed.

The description of whether a service
requires scheduling is added.
as follows:

The Number of E-DCH
MAC-D PDU Size













Streaming traffic
transmission mode on
HSUPA
The deleted parameter is
E-DCH MAC-D PDU size.
In Reconfiguring Radio Bearers Parameters:

The SET FRCCHLTYPEPARA
command can be used to set service rate
thresholds on different transport channels.
The related description is added.

An example of refreshing a script by using
the ADD TYPRABHSPA command is
added.
None.
Editorial
change
General documentation change:
Implementation information has been moved
to a separate document. For information on
how to implement radio bearers, see
Configuring Radio Bearers in RAN Feature
Configuration Guide.
None.

RAN
Radio Bearers Description 2 Radio Bearers Introduction

2-1

2 Radio Bearers Introduction
Different types of traffic and signaling require different bearing modes, mapping modes, and
parameter settings. Appropriate bearer configurations can help increase the capacity and
guarantee the QoS.
Based on the transferred data, the Radio Bearers (RBs) are of two types:

Signaling Radio Bearer (SRB)

Traffic Radio Bearer (TRB)
The Radio Bearers refer to all the radio resources allocated by the UTRAN for a service. The
Radio Bearers feature involves RAB mapping and layer 2 (L2) parameter configuration.

RAB mapping is used to assign an RAB to a typical service and allocate a suitable
transport channel to the service.

L2 parameters affect the quality and rate of data transmission.
The RAB mapping and L2 parameter configuration are oriented to each typical service.
If an RAB is carried on HSDPA or HSUPA, some special parameters are available to control
data transmission and reception.
Impact

Impact on System Performance
None.

Impact on Other Features
When receiving a message from the CN to set up a RAB, the RNC determines the
maximum bit rate first. Then, the RNC configures the RB resource and parameters based
on the maximum bit rate.
Network Elements involved
Table 2-1shows the Network Elements (NEs) involved in radio bearers.
Table 2-1 NEs involved in radio bearers
UE NodeB RNC MSC Server MGW SGSN GGSN HLR

2 Radio Bearers Introduction
RAN

Issue 01 (2008-05-30)

UE NodeB RNC MSC Server MGW SGSN GGSN HLR
NOTE

: not involved

: involved
UE = User Equipment, RNC = Radio Network Controller, MSC Server = Mobile Service Switching
Center Server, MGW = Media Gateway, SGSN = Serving GPRS Support Node, GGSN = Gateway
GPRS Support Node, HLR = Home Location Register

RAN
Radio Bearers Description 3 Radio Bearers Principles

3-1

3 Radio Bearers Principles
The principles of Radio Bearers cover the technical aspects of the feature:

Service Specifications

Transport Channel Selection

RLC Configuration

Control of HS-DSCH Transmission and Reception

Control of E-DCH Transmission and Reception
3.1 Service Specifications
This describes the SRB, TRB, combined service, and Multimedia Broadcast and Multicast
Service (MBMS) service specifications supported by Huawei RNC.
3.1.1 SRB Specifications
Table 3-1 describes the SRB specifications supported by Huawei RNC.
Table 3-1 SRB specifications
SRB Index Maximum Bit Rate (kbit/s) Direction
1 3.4 DL/UL
2 13.6 DL/UL
3 27.2 DL/UL

3.1.2 TRB Specifications
The RNC searches for the RAB indexes of TRBs according to the attributes such as the CN
domain, traffic class, source statistics descriptor, and maximum bit rate. Then, the RNC
configures the parameters for each service on the basis of RAB indexes.
The RNC automatically checks the identity of the CN domain from which the services come.
The RAB ASSIGNMENT REQUEST message from the CN contains the information of
traffic class, source statistics descriptor, and maximum bit rate.
RAN

Issue 01 (2008-05-30)

Table 3-2 describes the TRB specifications supported by Huawei RNC.
Table 3-2 TRB specifications
RAB
Index
CN Domain Traffic Class
Source Statistics
Descriptor
Maximum Bit Rate
(kbit/s)
Direction
0 CS Conversational Speech 12.2 DL/UL
1 CS Conversational Speech 23.85 DL/UL
2 CS Conversational Unknown 28.8 DL/UL
3 CS Conversational Unknown 32 DL/UL
6 CS Streaming Unknown 57.6 DL/UL
11 PS Conversational Unknown 8 DL/UL
16 PS Conversational Unknown 38.8 DL/UL
21 PS Streaming Unknown 8 DL/UL
40 PS Interactive Unknown 0 DL/UL
RAN

3-3

RAB
Index
Source Statistics
Descriptor
Maximum Bit Rate
(kbit/s)
Direction
49 PS Interactive Unknown 608 UL
50 PS Interactive Unknown 768 DL
70 PS Background Unknown 0 DL/UL
79 PS Background Unknown 608 UL
80 PS Background Unknown 768 DL
RAN

Issue 01 (2008-05-30)

RAB
Index
Source Statistics
Descriptor
Maximum Bit Rate
(kbit/s)
Direction

The NodeB of the current version does not support multi-code operations on the UL and DL
dedicated physical channels. The services with the maximum bit rate higher than 384 kbit/s
are carried on the HS-DSCH or E-DCH.
3.1.3 Combined Service Specifications
Table 3-3 describes the combined service specifications.
Table 3-3 Combined service specifications
Index Type of Combined Service
0 Signaling 3.4 kbit/s
3 Signaling 3.4 kbit/s + CS service
4 Signaling 3.4 kbit/s + PS service
5 Signaling 3.4 kbit/s + PS service + PS service
6 Signaling 3.4 kbit/s + PS service + PS service + PS service (carrying the IMS
signaling)
7 Signaling 3.4 kbit/s + CS service + PS service
8 Signaling 3.4 kbit/s + CS service + PS service + PS service
9 Signaling 3.4 kbit/s+ CS service + PS service + PS service + PS service
(carrying the IMS signaling)
10 Signaling 3.4 kbit/s + CS service + CS service
11 Signaling 3.4 kbit/s + CS service + CS service + PS service
RAN

3-5

3.1.4 MBMS Service Specifications
The MBMS service, a special TRB, is supported by this version. The MBMS is a single point
to multipoint service that is transmitted in broadcast mode on the common channel. The
MBMS service specifications are cell-oriented and RNC-oriented.
Table 3-4 describes the MBMS service specifications supported by Huawei RNC.
Table 3-4 MBMS service specifications
Traffic
Class
Maximum Bit
Rate (kbit/s)
Direction
Maximum Number of Sessions
for a Cell
Streaming 256 DL 4
Streaming 128 DL 4
Streaming 64 DL 16
Streaming 32 DL 16
Streaming 16 DL 16
Background 256 DL 4
Background 128 DL 4
Background 64 DL 16
Background 32 DL 16
Background 16 DL 16

In a cell, a maximum of 16 MBMS sessions can be supported at the same time and a
maximum of five S-CCPCHs can be used to carry the MBMS Point-to-Multipoint Traffic
Channel (MTCH).
For an RNC, the maximum throughput for the MBMS sessions on the Iu interface is 8192
kbit/s, and the maximum number of MBMS sessions supported at the same time is 128.
3.2 Transport Channel Selection
This describes the mapping of signaling, traffic, and combined services onto transport
channels.
3.2.1 Mapping of Signaling and Traffic onto Transport Channels
This describes the mapping of signaling and traffic onto transport channels.
Overview
Table 3-5 describes the mapping of signaling and traffic onto transport channels.
RAN

Issue 01 (2008-05-30)

Table 3-5 Mapping of signaling and traffic onto transport channels
CN Domain Signaling/Traffic Class Transport Channel
Signaling DCH/CCH/HS-DSCH/E-DCH
Conversational CS
Streaming
DCH
Conversational
Streaming
DCH/HS-DSCH/E-DCH
Interactive
PS
Background
DCH/CCH/HS-DSCH/E-DCH
MBMS Session Streaming FACH/DCH/HS-DSCH

Mapping of Signaling onto the Transport Channel
During the setup of an RRC connection, the single SRB can be carried on the CCH, DCH,
HS-DSCH, or E-DCH, as described below:

If the selected channel type is FACH, the SRB is carried on the CCH in both the uplink
and the downlink.

If the selected channel type is DCH, then
In the downlink, if Srb channel type RRC effect flag is set to TRUE and Srb
channel type is set to HSDPA or HSPA, the SRB is carried on the HS-DSCH;
otherwise, on the DCH.
In the uplink, if Srb channel type RRC effect flag is set to TRUE and Srb channel
type is set to HSPA, the SRB is carried on the E-DCH; otherwise, on the DCH.
During the setup of TRBs, the SRB can be carried on the CCH, DCH, HS-DSCH, or E-DCH,
as described below:

If the selected channel type is FACH, the SRB is carried on the CCH in both the uplink
and the downlink.

If the selected channel type is not FACH, then
In the downlink, if the channel types selected by all the TRBs are HS-DSCH and Srb
channel type is set to HSDPA or HSPA, the SRB is carried on the HS-DSCH;
otherwise, on the DCH.
In the uplink, if the channel types selected by all the TRBs are E-DCH and Srb
channel type is set to HSPA, the SRB is carried on the E-DCH; otherwise, on the
DCH.
If the bearing policy is SRB over HSPA but the SRB fails to be set up, then the SRB is carried
on the DCH, the timer for periodic retries is started, and the bearing policy is considered again.
If the bearing policy is still SRB over HSPA, the SRB is carried on the HSPA channel;
otherwise, on the DCH. The SRB over HSPA periodic retry timer length is 5s.
RAN

3-7

Mapping of Traffic onto the Transport Channel
The services in the CS domain have high transmission quality requirements and are always
mapped onto the DCHs.
The conversational services in the PS domain can be mapped onto the DCH, HS-DSCH, or
E-DCH. VoIP stands for Voice over IP, a PS conversational service. It uses IP data packets to
encapsulate voice data and transports them on the IP network to implement the conversational
services.

In the downlink, if Voip channel type is set to HSDPA or HSPA, the PS conversational
service is carried on the HS-DSCH; otherwise, on the DCH.

In the uplink, if Voip channel type is set to HSPA, the PS conversational service is
carried on the E-DCH; otherwise, on the DCH.
The streaming services in the PS domain can be mapped onto the DCH, HS-DSCH, or
E-DCH.

If the maximum DL service rate is higher than or equal to DL streaming traffic
threshold on HSDPA, the cell supports HSDPA, and the
PS_STREAMING_ON_HSDPA_SWITCH is selected, then the service is carried on
the HS-DSCH. Otherwise, the service is carried on the DCH.

If the maximum UL service rate is higher than or equal to UL streaming traffic
threshold on HSUPA, the cell supports HSUPA, and the
PS_STREAMING_ON_E_DCH_SWITCH is selected, then the service is carried on
the E-DCH. Otherwise, the service is carried on the DCH.
The interactive and background services in the PS domain can be mapped onto the CCH,
DCH, HS-DSCH, or E-DCH.
Low-rate PS services have relatively small amount of data. Therefore, such PS services can be
carried on the CCH to save radio resources.
If the maximum DL service rate is lower than DL BE traffic DCH decision threshold, the
maximum UL service rate is lower than UL BE traffic DCH decision threshold, and the
RRC connection is set up on the CCH, then the service is carried on the CCH. Otherwise,
further decision need to be made as follows:

If the maximum DL service rate is higher than or equal to DL BE traffic threshold on
HSDPA, then the service is carried on the HS-DSCH. Otherwise, the service is carried
on the DCH.

If the maximum UL service rate is higher than or equal to UL BE traffic threshold on
HSUPA, then the service is carried on the E-DCH. Otherwise, the service is carried on
the DCH.
The IMS signaling can be mapped on the DCH, HS-DSCH, or E-DCH.

In the downlink, if IMS channel type is set to HSDPA or HSPA, the IMS signaling is
carried on the HS-DSCH; otherwise, on the DCH.

In the uplink, if IMS channel type is set to HSPA, the IMS signaling is carried on the
E-DCH; otherwise, on the DCH.
If a service fails to be set up on an HSPA channel in the case that both the cell and the UE
support HSPA, then the service is carried on the DCH. Here, the setup failure may be due to
an admission failure. At the same time, the retry timer is started for periodic retries to access
the HSPA channel. The timer length is specified by H Retry timer length.
RAN

Issue 01 (2008-05-30)

3.2.2 Mapping of Combined Services onto Transport Channels
This describes the mapping of combined services onto transport channels.
Principles of Mapping Combined Services onto Transport Channels
The combined services are mapped onto and carried by their respective transport channels
when the conditions described in 3.2.1 Mapping of Signaling and Traffic onto Transport
Channels are met.
The combined services to be mapped onto the CCH must meet the following criteria:

According to the criteria of single service described in 3.2.1 Mapping of Signaling and
Traffic onto Transport Channels, the combined services are all mapped onto the CCH.

The mapping of combined services onto the CCH is applied to both UL and DL.
If the combined services do not meet the criteria or only one direction meet the criteria, they
are carried on the DCH/HS-DSCH/E-DCH.
Examples of Selecting Transport Channels for UL/DL Combined Services
Assume that the related DL parameters are configured as follows:

DL BE traffic DCH decision threshold = 16 kbit/s

UL BE traffic DCH decision threshold = 16 kbit/s

DL BE traffic threshold on HSDPA = 32 kbit/s

PS_STREAMING_ON_HSDPA_SWITCH = 1

DL streaming traffic threshold on HSDPA = 128 kbit/s
Table 3-6 describes an example of transport channel selection for the DL combined services.
Table 3-6 Example of transport channel selection for the DL combined services
Service Combination Transport Channel Selection
Signaling 3.4 kbit/s + CS + PS interactive
8 kbit/s
DCH (signaling) + DCH (CS) + DCH (PS
interactive 8 kbit/s)
Signaling 3.4 kbit/s + PS interactive 8
kbit/s + PS interactive 64 kbit/s
DCH (signaling) + DCH (PS interactive 8
kbit/s) + HS-DSCH (PS interactive 64 kbit/s)
kbit/s) + DCH (PS interactive 16 kbit/s)
CCH (signaling) + CCH (PS interactive 8
kbit/s) + CCH (PS interactive 8 kbit/s)
kbit/s + PS streaming 128 kbit/s
DCH (signaling) + HS-DSCH (PS interactive
64 kbit/s) + HS-DSCH (PS streaming 128
kbit/s)

Assume that the related UL parameters are configured as follows:

UL BE traffic DCH decision threshold = 16 kbit/s
RAN

3-9

UL BE traffic threshold on HSUPA = 64 kbit/s

PS_STREAMING_ON_E_DCH_SWITCH = 1

UL streaming traffic threshold on HSUPA = 256 kbit/s
Table 3-7 describes an example of transport channel selection for the UL combined services.
Table 3-7 Example of transport channel selection for the UL combined services
Service Combination Transport Channel Selection
Signaling 3.4 kbit/s + CS + PS interactive
8 kbit/s
DCH (signaling) + DCH (CS) + DCH (PS
interactive 8 kbit/s)
kbit/s) + E-DCH (PS interactive 64 kbit/s)
kbit/s) + DCH (PS interactive 16 kbit/s)
CCH (signaling) + CCH (PS interactive 8
kbit/s) + CCH (PS interactive 8 kbit/s)
kbit/s + PS streaming 256 kbit/s
DCH (signaling) + E-DCH (PS interactive 64
kbit/s) + E-DCH (PS streaming 256 bit/s)

3.3 RLC Configuration
This describes the RLC modes and the RLC parameters in different modes.
3.3.1 RLC Modes
This describes the features of three RLC modes and the discard parameters of the RLC.
Features of Different RLC Modes
The RLC layer consists of RLC entities in the following three modes:

Acknowledged Mode (AM)

Transparent Mode (TM)

Unacknowledged Mode (UM)
Each RLC mode has its own impact on the correctness and delay of data transmission.
Table 3-8 describes the features of the three RLC modes.
Table 3-8 Features of three RLC modes
Item TM UM AM
Head N Y Y (larger than UM head)
Cache N Y Y
RAN

Issue 01 (2008-05-30)

Item TM UM AM
Ciphering N Y Y
SDU size limit Integer of predefined
TB size

Retransmission N N Y
Feature

No additional delay

No overhead caused
by a larger head

Not assured
correctness

Low delay

Not assured
correctness

Assured correctness

High delay

Overhead of RLC head
reduces the
transmission efficiency.
Application Services with strict
delay requirement,
such as CS
conversational service
Services such as
VoIP have the
following
features:

Low delay
requirement

Insensitive to
packet loss

Pending SDU
size
Services such as web
browsing and FTP
download have the
following features:

Not insensitive to delay

High or very high
requirement for
transmission quality

Figure 3-1 PDUs of the three RLC modes

When the RLC parameters are configured for different services, the RLC modes are chosen
on the basis of the QoS attributes (mainly delay and BER) of the services.

The TM mode is configured for a service with the lowest delay requirement, a low BER,
and an RLC SDU size that is known.

The UM mode is configured for a service with low delay, a low BER, and an RLC SDU
size that is unknown.

The AM mode is configured for a service with high delay, the lowest BLER, and an RLC
SDU size that is unknown.
RAN

3-11

Discard Parameters of the RLC
The SDUs at the RLC layer are discarded in the following four ways:

Timer based SDU discard with explicit signaling

Timer based SDU discard without explicit signaling

SDU discard after the Max DAT number of transmissions

No discard
SDU discard is mandatory for the AM mode, whereas it is optional for the TM and UM
modes.

In TM mode, if the transmission RLC discard parameters are not configured, the RLC
discards the SDUs that are received but not sent during the last TTI after receiving new
SDUs.

In UM mode, if the transmission RLC discard parameters are not configured, all SDUs
are reserved until the RLC buffer is fully filled.
The parameters related to timer based SDU discard with explicit signaling are as follows:

Explicit-ind slide RX window timing

Explicit-ind SDU discard timing

Explicit-ind MRW command max re-TX number
The parameter related to timer based SDU discard without explicit signaling is as follows:

No-explicit-ind SDU discard
The parameters related to SDU discard after the Max DAT number of transmissions are as
follows:

Discard PDU max TX

Discard slide RX window timing

Discard MRW command max re-TX number
The parameter related to no discard is as follows:

No-Discard PDU max TX

The above parameters are not configurable, and the values of them please refer to 3.3.3 Default RLC
Parameters for Different Services.
3.3.2 RLC Parameters in Different Modes
This describes the RLC parameters in the following three modes: TM, UM, and AM.
TM Parameters
The TM parameters are as follows:

UM-TM RLC discard mode selection

UL RLC segment indication

DL RLC segment indication
RAN

Issue 01 (2008-05-30)

UM Parameters
The only UM parameter is UM-TM RLC discard mode selection.
It is a switch-type parameter.
AM Parameters
In RLC AM mode, the data is transferred as follows:
1. At the sender, the upper layer data is sent to the RLC that buffers, segments, and
concatenates the data.
2. The sender sends the data at the request of the MAC.
3. The receiver checks whether the received data is correct or not and returns the ACK or
NACK message about each PDU.
4. Upon reception of the NACK message, the sender sends the PDU again.
5. The receiver reassembles all the PDUs of an SDU after they are correctly received, and
deliver the SDU to the higher layer.
The AM parameters are as follows:

Transmit window and receive window

Poll parameters at the Sender: triggers the receiver to send status reports.

Status reporting parameters at the receiver: restricts or triggers the sending of status
reports.

Discard parameters at the Sender: controls the ways to discard RLC PDUs.

Reset parameters

Delivery order
To configure the AM parameters, adhere to the following rules:

Obtain status reports to be sent in time to trigger the RLC transmit window to slide.

Prevent redundant retransmissions caused by too many status reports.
The transmit window and receive window are described as follows:

TX window size

TX window size limit

RX window size

RX window size limit
The poll parameters at the sender are as follows:

Last TX PDU poll indication

Last re-TX PDU poll indication

PDU poll frequency

SDU poll frequency

Poll window

Poll prohibit timer

re-TX poll timer

Periodical poll interval
RAN

3-13

The status reporting parameters at the receiver are as follows:

Missing PDU indication

Status report prohibit timer

State report period transmission timer
The reset parameters are as follows:

Reset timer duration

Max resetting times
The delivery order parameter is as follows:

Deliver data by sequence order on RNC side

The above parameters are not configurable, and the values of them please refer to 3.3.3 Default RLC
Parameters for Different Services.
3.3.3 Default RLC Parameters for Different Services
This describes the default RLC parameters for different services.
Default RLC Parameters for CS Services
Table 3-9 Default RLC parameters for CS services (1)
RAB
Index
TRAFFIC CLASS MAXBITRATE
(kbit/s)
RLCMODE ULSEGIND
0 CONVERSATIONAL 12.2 TM FALSE
3 CONVERSATIONAL 32 TM FALSE
6 STREAMING 57.6 TM FALSE

Table 3-10 Default RLC parameters for CS services (2)
RAB
Index
DLSEGIND DISCARDMODE NOEXPLICIT
TIMERDISCA
RD
0 FALSE
1 FALSE
2 FALSE TIMER_BASED_WITHOUT_EXPLICI
T_SIGNALLING
D100
RAN

Issue 01 (2008-05-30)

RAB
Index
DLSEGIND DISCARDMODE NOEXPLICIT
TIMERDISCA
RD
T_SIGNALLING
D100
T_SIGNALLING
D100
T_SIGNALLING
D100
6 FALSE

Default RLC Parameters for PS Conversational Services
Table 3-11 Default RLC parameters for PS conversational services
RABInd
ex
MAXBITRATE
(kbit/s)
RLCMODE UM-TM RLC discard
mode selection
11 8 UM Not used
12 16 UM Not used
13 32 UM Not used
15 64 UM Not used
16 38.8 UM Not used
17 39.2 UM Not used
18 40 UM Not used
19 42.8 UM Not used

Default RLC Parameters for PS Streaming Services
Table 3-12 Default RLC parameters for PS streaming services (1)
RABIndex 21 22 23 24
TRAFFICCLASS streaming streaming streaming streaming
MAXBITRATE (kbit/s) 8 16 32 64
RLCMODE AM AM AM AM
AMRLCDISCARDMODE NO_DISCARD NO_DISCARD NO_DISCARD
NO_DISCA
RD
NODISCARDMAXDAT D10 D10 D10 D10
RAN

3-15

TXWINDOWSIZE D32 D64 D128 D256
TXWINDOWSIZELIMIT D16 D32 D64 D128
TIMERRST D150 D150 D150 D150
MAXRST D32 D32 D32 D32
INSEQUENCEDELIVERYORDER TRUE TRUE TRUE TRUE
RXWINDOWSIZE D32 D64 D128 D256
RXWINDOWSIZELIMIT D16 D32 D64 D128
MISSINGPDUIND TRUE TRUE TRUE TRUE
TIMERSTATUSPROHIBIT D240 D240 D240 D200
LASTTXPDUPOLL TRUE TRUE TRUE TRUE
LASTRETXPDUPOLL TRUE TRUE TRUE TRUE
TIMERPOLLPROHIBIT D100 D100 D100 D100
TIMERPOLL D270 D270 D270 D270
POLLPDU D16 D16 D16 D16
POLLSDU D1 D1 D1 D1
POLLWINDOW D50 D50 D50 D50

Table 3-13 Default RLC parameters for PS streaming services (2)
TRAFFICCLASS streaming streaming streaming streaming
MAXBITRATE (kbit/s) 128 144 256 384
RLCMODE AM AM AM AM
AMRLCDISCARDMODE NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCARD
RAN

Issue 01 (2008-05-30)

POLLSDU D1 D1 D1 D1

Default RLC Parameters for PS Interactive and Background Services
Table 3-14 Default RLC parameters for PS interactive and background services carried on the DCH (1)
RABIndex 40/70 41/71 42/72 43/73 44/74
TRAFFICCLASS I/B I/B I/B I/B I/B
MAXBITRATE
(kbps)
0 8 16 32 64
RLCMODE AM AM AM AM AM
AMRLCDISCAR
DMODE
NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCARD
NODISCARDMA
XDAT
D20 D20 D20 D20 D20
TXWINDOWSIZ
E
D32 D32 D64 D128 D256
TXWINDOWSIZ
ELIMIT
D16 D16 D32 D64 D128
TIMERRST D150 D150 D150 D150 D150
MAXRST D32 D32 D32 D32 D32
INSEQUENCED
ELIVERYORDE
R
TRUE TRUE TRUE TRUE TRUE
RXWINDOWSIZ
E
D32 D32 D64 D128 D256
RXWINDOWSIZ
ELIMIT
D16 D16 D32 D64 D128
RAN

3-17

RABIndex 40/70 41/71 42/72 43/73 44/74
MISSINGPDUIN
D
TIMERSTATUSP
ROHIBIT
D240 D240 D200 D200 D200
LASTTXPDUPO
LL
LASTRETXPDU
POLL
TIMERPOLLPR
OHIBIT
D100 D100 D100 D100 D100
TIMERPOLL D300 D300 D270 D270 D270
POLLPDU D2 D2 D4 D8 D16
POLLSDU D1 D1 D1 D1 D1
POLLWINDOW D50 D50 D50 D50 D50

Table 3-15 Default RLC parameters for PS interactive and background services carried on the DCH (2)
RABIndex 45/75 46/76 47/77 48/78
TRAFFICCLASS I/B I/B I/B I/B
MAXBITRATE (kbps) 128 144 256 384
RLCMODE AM AM AM AM
RAN

Issue 01 (2008-05-30)

RABIndex 45/75 46/76 47/77 48/78
POLLSDU D1 D1 D1 D1

Table 3-16 Default RLC parameters for PS interactive and background services carried on the HS-DSCH (1)
RABIndex 40/70 41/71 42/72 43/73 44/74
MAXBITRATE
(kbps)
0 8 16 32 64
AMRLCDISCAR
DMODE
NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCAR
D
NODISCARDMA
XDAT
D20 D20 D20 D20 D20
TXWINDOWSIZ
E
D256 D256 D256 D256 D256
TXWINDOWSIZ
ELIMIT
D1 D1 D1 D1 D1
TIMERRST D450 D450 D450 D450 D450
INSEQUENCED
ELIVERYORDE
R
RXWINDOWSIZ
E
D256 D256 D256 D256 D256
RXWINDOWSIZ
ELIMIT
D1 D1 D1 D1 D1
MISSINGPDUIN
D
TIMERSTATUSP
ROHIBIT
D120 D120 D120 D120 D120
LASTTXPDUPO
LL
LASTRETXPDU
POLL
RAN

3-19

RABIndex 40/70 41/71 42/72 43/73 44/74
TIMERPOLLPR
OHIBIT
D20 D20 D20 D20 D20

RABIndex 45/75 46/76 47/77 48/78
MAXBITRATE (kbps) 128 144 256 384
RLCMODE AM AM AM AM

RABIndex 50/80 51/81 53/83 54/84 55/85
MAXBITRATE
(kbps)
768 1024 1536 1800 2048
RAN

Issue 01 (2008-05-30)

RABIndex 50/80 51/81 53/83 54/84 55/85
AMRLCDISCARD
MODE
NO_DISCARD NO_DISCARD NO_DISCARD NO_DISCARD
NO_DISCAR
D
NODISCARDMA
XDAT
D20 D20 D20 D20 D20
TXWINDOWSIZE D1024 D1024 D1024 D2047 D2047
TXWINDOWSIZE
LIMIT
D1 D1 D1 D1 D1
TIMERRST D450 D450 D450 D450 D450
INSEQUENCEDE
LIVERYORDER
RXWINDOWSIZE D1024 D1024 D1024 D2047 D2047
RXWINDOWSIZE
LIMIT
D1 D1 D1 D1 D1
MISSINGPDUIND TRUE TRUE TRUE TRUE TRUE
TIMERSTATUSP
ROHIBIT
D120 D120 D120 D120 D120
LASTTXPDUPOL
L
LASTRETXPDUP
OLL
TIMERPOLLPRO
HIBIT
D20 D20 D20 D20 D20

RABIndex 57/87 59/89 60/90 61/91
MAXBITRATE (kbps) 3648 7200 10100 14400
RLCMODE AM AM AM AM
RAN

3-21

RABIndex 57/87 59/89 60/90 61/91

Table 3-20 Default RLC parameters for PS interactive and background services carried on the E-DCH (1)
RABIndex 40/70 41/71 42/72 43/73 44/74
MAXBITRATE
(kbps)
0 8 16 32 64
AMRLCDISCAR
DMODE
NODISCARDMA
XDAT
D20 D20 D20 D20 D20
TXWINDOWSIZ
E
D32 D32 D64 D128 D256
TXWINDOWSIZ
ELIMIT
D1 D1 D1 D1 D1
TIMERRST D150 D150 D150 D150 D150
INSEQUENCED
ELIVERYORDE
R
RXWINDOWSIZ
E
D32 D32 D64 D128 D256
RXWINDOWSIZ
D1 D1 D1 D1 D1
RAN

Issue 01 (2008-05-30)

RABIndex 40/70 41/71 42/72 43/73 44/74
ELIMIT
MISSINGPDUIN
D
TIMERSTATUSP
ROHIBIT
D240 D240 D200 D200 D200
LASTTXPDUPO
LL
LASTRETXPDU
POLL
TIMERPOLLPR
OHIBIT
D100 D100 D100 D100 D100

RABIndex 45/75 46/76 47/77 48/78 49/79
MAXBITRATE
(kbps)
128 144 256 384 711
AMRLCDISCAR
DMODE
NODISCARDMA
XDAT
D20 D20 D20 D20 D20
TXWINDOWSIZ
E
D512 D512 D768 D1024 D2047
TXWINDOWSIZ
ELIMIT
D1 D1 D1 D1 D1
TIMERRST D150 D150 D150 D150 D150
INSEQUENCED
ELIVERYORDE
R
RXWINDOWSIZ
E
D512 D512 D768 D1024 D2047
RAN

3-23

RABIndex 45/75 46/76 47/77 48/78 49/79
RXWINDOWSIZ
ELIMIT
D1 D1 D1 D1 D1
MISSINGPDUIN
D
TIMERSTATUSP
ROHIBIT
D180 D180 D130 D130 D100
LASTTXPDUPO
LL
LASTRETXPDU
POLL
TIMERPOLLPR
OHIBIT
D100 D100 D100 D100 D20

RABIndex 52/82 55/85 56/86 58/88
MAXBITRATE (kbps) 1450 2048 2890 5760
RLCMODE AM AM AM AM
INSEQUENCEDELIVERYORDE
R
TRUE TRUE TRUE TRUE
RAN

Issue 01 (2008-05-30)

RABIndex 52/82 55/85 56/86 58/88
POLLSDU D1 D1 D1 D1

3.4 Control of HS-DSCH Transmission and Reception
This describes the data transmission and reception on the HS-DSCH.
3.4.1 Data Transmission
If services are mapped onto the HS-DSCH, the service data is encapsulated into an RLC PDU
in the RLC layer, and then reaches the MAC-d entity. If multiplexing on MAC is applied, the
MAC-d entity adds an MAC header to the RLC PDU to make an MAC-d PDU. The sizes of
MAC-d PDUs are determined by the traffic classes on the HS-DSCH.

For all the traffic classes except the PS conversational service, the HS-DSCH MAC-d
PDU size is 336 bit.

For the VoIP service, a PS conversational service, supports up to eight MAC-d PDU
sizes which are 112, 144, 160, 176, 192, 224, 296 and 344.
The MAC-d entity then assembles MAC-d PDUs with the same MAC-d flow ID and
CmCH-PI into the same HS-DSCH data frame, and sends them to the MAC-hs entity on the
NodeB. The PDUs are buffered in the corresponding queue and wait to be sent. Figure 3-2
shows the procedure of the data transmission on the HS-DSCH.
RAN

3-25

Figure 3-2 Procedure of the data transmission on the HS-DSCH

An MAC-d PDU buffered in the NodeB MAC-hs queue can be discarded if the MAC-hs
Discard timer option parameter is set to TRUE. In this case, the MAC-hs Discard timer is
started when each MAC-d PDU reaches the MAC-hs queue. If the MAC-d PDU is not sent
before the MAC-hs Discard timer expires, the MAC-d PDU is discarded. MAC-hs Discard
timer option is set to TRUE to prevent the timeout MAC-d PDUs from congestion in the
queue and thus reducing the delay of a subsequent MAC-d PDU.
3.4.2 Data Reception
The MAC-hs entity on the UE side has a reordering entity that reorders the disordered
MAC-hs PDUs. The reordered PDUs are transferred to the higher layer in sequence.
For the reordering entity, the UE maintains a receive window. The receive window defines the
Transmission Sequence Numbers (TSNs) of the MAC-hs PDUs that can be received by the
receiver without causing the receive window to slide. The size of the receive MAC-hs
window is 16, and the TSNs range from (RcvWindow_UpperEdge MAC-hs window siz + 1)
to RcvWindow_UpperEdge included.
The RcvWindow_UpperEdge represents the TSN, which is at the upper edge of the receive
window. After the first MAC-hs PDU has been received successfully, it also corresponds to
the MAC-hs PDU with the highest TSN of all received MAC-hs PDUs.
It is likely that an MAC-hs PDU at the TX end may be retransmitted and that the PDUs with
larger TSNs may be correctly received prior to the PDUs with smaller TSNs. In this situation,
a PDU with a larger TSN is buffered in the reordering entity and waits for PDUs with smaller
TSNs to be sent. The MAC-hs T1 timer is started for the PDU and the TSN of the PDU is
recorded as T1_TSN. If the MAC-hs PDUs with TSNs that are smaller than T1_TSN are not
correctly received when the MAC-hs T1 timer expires, the following PDUs are sent to the
disassembly entity and then the TSN range and T1_TSN of the receive window are updated:

All correctly received MAC-hs PDUs with TSN smaller than or equal to T1_TSN
RAN

Issue 01 (2008-05-30)

All correctly received MAC-hs PDUs that are smaller than the next but not received
MAC-hs PDU
After the previous actions, the PDUs that meet the following requirement are discarded:
TSN < RcvWindow_UpperEdge - MAC-hs window size + 1
3.5 Control of E-DCH Transmission and Reception
This describes the data transmission and reception on the E-DCH.
3.5.1 Data Transmission
The traffic data mapped onto the E-DCH will be encapsulated into an RLC PDU in the RLC
layer. Then, the RLC PDU is delivered to the MAC-d entity that will add a header to the RLC
PDU including the multiplexing information. In this way, the RLC PDU becomes an MAC-d
PDU. After that, the MAC-d PDU is delivered to the MAC-es entity. The number of MAC-d
PDU sizes and the sizes of MAC-d PDUs are determined by the traffic classes on the
HS-DSCH.

For all the traffic classes except the PS conversational service, the E-DCH MAC-d PDU
size is 336.

For the VoIP service, a PS conversational service, supports up to 12 MAC-d PDU sizes
which are 96, 112, 144, 160, 176, 192, 208, 224, 288, 296, 312 and 344.
When the MAC-d PDUs are delivered to the MAC-e/es entity, they are encapsulated into
MAC-es PDUs and then into MAC-e PDUs. The MAC-e PDUs are transmitted to the NodeB
on the air interface.
The number of MAC-d PDUs to be transmitted in each TTI is determined by the following
factors:

Traffic volume in the RLC buffer

Maximum number of channelization codes configured by the RNC

Serving Grant (SG) indicated by the NodeB
3.5.2 Data Reception
The NodeB provides the function of de-multiplexing of MAC-e PDUs. The MAC-es PDUs
are forwarded to the associated MAC-d flow to the RNC. The RNC MAC-es sublayer
reorders the MAC-es PDUs based on the Transmission Sequence Number (TSN) and the
Connection Frame Number (CFN) tagged by the NodeB.
The reordering entity is a part of the MAC-es sublayer in the Serving RNC (SRNC). There is
one reordering entity for each UE. The reordering entity maintains a receive window. The
receive window defines the TSNs of those MAC-es PDUs that can be received by the receiver
without causing the receive window to slide. The size of the receive MAC-ES window is 32,
and the TSNs range from (RcvWindow_UpperEdge MAC-ES window size + 1) to
RcvWindow_UpperEdge.
The function of the MAC-es RX window is similar to that of the MAC-hs RX window.
The RcvWindow_UpperEdge represents the TSN, which is at the upper edge of the receive
window. After the first MAC-es PDU has been received successfully, it also corresponds to
the MAC-es PDU with the highest TSN of all received MAC-es PDUs.
RAN

3-27

It is likely that an MAC-es PDU at the TX end may be retransmitted and that PDUs with
larger TSNs may be correctly received prior to those with smaller TSNs. In this situation, a
PDU with a larger TSN is buffered in the reordering entity and waits for PDUs with smaller
TSNs to be sent. The MAC-es T1 timer is started for the PDU, and the TSN of the PDU is
recorded as T1_TSN. If MAC-es PDUs with TSNs that are smaller than T1_TSN are not
correctly received yet when the MAC-es T1 timer expires, the following PDUs are sent to
the disassembly entity and then the TSN range and T1_TSN of the receive window are
updated:

All correctly received MAC-es PDUs with TSN smaller than or equal to T1_TSN

All correctly received MAC-es PDUs that are smaller than the next but not received
MAC-es PDU
After the previous actions, the PDUs that meet the following requirement are discarded:
TSN < RcvWindow_UpperEdge MAC-ES window size + 1
3.5.3 Serving Grant
The NodeB controls the user UL rate by transmitting signals to adjust Serving Grant (SG). SG
is the maximum power ratio of the E-DPDCH to the DPCCH, which is used by the UE in the
next transmission. SGs are a series of discrete ratio figures, as listed in Table 3-23.
Table 3-23 Serving Grant table (SG-table)
Index Serving Grant Index Serving Grant Index Serving Grant
0 (5/15)
2
13 (27/15)
2
26 (119/15)
2

1 (6/15)
2
14 (30/15)
2
27 (134/15)
2

2 (7/15)
2
15 (34/15)
2
28 (150/15)
2

3 (8/15)
2
16 (38/15)
2
29 (168/15)
2

4 (9/15)
2
17 (42/15)
2
30 (95/15)
2
x 4
5 (11/15)
2
18 (47/15)
2
31 (150/15)
2
x 2
6 (12/15)
2
19 (53/15)
2
32 (119/15)
2
x 4
7 (13/15)
2
20 (60/15)
2
33 (134/15)
2
x 4
8 (15/15)
2
21 (67/15)
2
34 (150/15)
2
x 4
9 (17/15)
2
22 (75/15)
2
35 (168/15)
2
x 4
10 (19/15)
2
23 (84/15)
2
36 (150/15)
2
x 6
11 (21/15)
2
24 (95/15)
2
37 (168/15)2
2
x 6
12 (24/15)
2
25 (106/15)
2

The signals used to adjust the SG include Absolute Grants (AGs) and Relative Grants (RGs).
The AGs are carried on the AGCH and define the SG values. The RGs are carried on the
RGCH and indicate that the SG should be increased, held, or decreased. When the SG needs
to be determined due to the RGCH signaling, the UE shall do as follows:
RAN

Issue 01 (2008-05-30)

Determine the lowest power ratio in the SG-table that is equal to or higher than the
reference_ETPR (This variable is set to the E-DPDCH to DPCCH power ratio used for
the E-TFC in the previous TTI in this HARQ process), and determine the corresponding
index in the SG-table as SGLUPR.

If the UE received an RG UP, based on E-RGCH 3-Index-Step Threshold and
E-RGCH 2-Index-Step Threshold configured by the higher layers, the UE shall
determine the SG as follows:
If SGLUPR < E-RGCH 3-Index-Step Threshold, then SG = SG[MIN(SGLUPR + 3,
37)].
If E-RGCH 3-Index-Step Threshold SGLUPR < E-RGCH 2-Index-Step
Threshold, then SG = SG[MIN(SGLUPR + 2, 37)].
If E-RGCH 2-Index-Step Threshold SGLUPR, then SG = SG[MIN(SGLUPR + 1,
37)].

If the UE received a Serving Relative Grant DOWN, the UE shall determine the SG as
follows: SG = SG[MAX(SGLUPR -1, 0)].
The UE reports the scheduling information and happy bit to the NodeB to request the SG. The
information is used in the NodeB HSUPA scheduling algorithm. For details of the HSUPA
scheduling algorithm, refer to HSUPA Description..
3.5.4 HSUPA TTI Selection Algorithm
E-DCH channel supports both 2ms TTI and 10ms TTI. For the different types of service, the
principle of TTI selection is as follows:
Service Type The value of TTI that the RNC sends to UE
VOIP When both UE and NodeB support 2ms TTI and
HSUPA_TTI_2MS_SWITCH is set to ON, if the value of HSUPA
TTI type of VOIP traffic is set to EDCH_TTI_2ms, the value of TTI
should be 2ms. Otherwise, the value of TTI should be 10ms.

Streaming When both UE and NodeB support 2ms TTI and
HSUPA_TTI_2MS_SWITCH is set to ON, if MBR is higher than Rate
threshold of Streaming on 2ms TTI of HSUPA, the value of TTI
should be 2ms. Otherwise, the value of TTI should be 10ms.

Interactive

During the initial setup of service:
When both UE and NodeB support 2ms TTI and
threshold of BE on 2ms TTI of HSUPA, the value of TTI should be
2ms. Otherwise, the value of TTI should be 10ms.

After the initial setup of service is completed:
If BE_EDCH_TTI_RECFG_SWITCH is set to ON, TTI is adjusted
according to the flow of service. If
BE_EDCH_TTI_RECFG_SWITCH is set to OFF, TT1 is
unchangeable.
Background

During the initial setup of service:
When both UE and NodeB support 2ms TTI and
RAN

3-29

Service Type The value of TTI that the RNC sends to UE
threshold of BE on 2ms TTI of HSUPA, the value of TTI should be
2ms. Otherwise, the value of TTI should be 10ms.

After the initial setup of service is completed:
If BE_EDCH_TTI_RECFG_SWITCH is set to ON, TTI is adjusted
according to the flow of service. If
BE_EDCH_TTI_RECFG_SWITCH is set to OFF, TT1 is
unchangeable.

3.5.5 HSUPA Service Scheduling Modes
When a service is carried on the E-DCH, it may or may not require scheduling, as listed in
Table 3-24. For details on the scheduling algorithms, refer to HSUPA Description.
Table 3-24 Scheduling modes for different services
Service Type Scheduling Mode
SRB Requires scheduling
IMS Requires scheduling
VoIP Does not require scheduling
Streaming Determined by the parameter Streaming traffic transmission mode on
HSUPA
Interactive Requires scheduling
Background Requires scheduling

RAN
Radio Bearers Description 4 Radio Bearers Reference Documents

4-1

4 Radio Bearers Reference Documents
Radio Bearers Reference Documents lists the reference documents related to the feature.

3GPP TS 25.322, "Radio Link Control (RLC) protocol specification"

3GPP TS 25.331, "Radio Resource Control (RRC)"

Radio Bearers Description (2008!05!30)

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Radio Bearers Description (2008!05!30)

Enviado por

Direitos autorais:

Formatos disponíveis

Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd

Você também pode gostar